I want to deploy an event processing stack, based on WSO2, but can't figure the Feature installation process.
I've downloaded latest Carbon (4.0.2) and want to install probably ESB, BRS, CEP, BAM and maybe later API Management.
I've connected to the Turing feature repository
2 questions:
in the available features list I don't see BAM or BRS, although ESB, CEP and API are there. What do I need to see these other parts ?
when I select CEP and ESB for installation I get a "install modified" and no features are selected.I imagine this is something to do with feature version incompatibility
if I just select ESB, the installation seems to proceed but the server won't restart (hangs waiting for one of the Synapse services.
It feels like I have the wrong process to determine what set of features/versions I need. How should I proceed ?
Carbon does not like to play well with it's other components. I've never been able to successfully use Carbon to manage any WSO2 stack. Each time I've setup/deployed a WSO2 stack I've ended up manually configuring the separate components config files individually. Usually starting with the ESB first, then adding in the CEP then the BAM.
You must also make sure they start in the correct order and that the config files don't stomp on each other (make sure your port offsets are set).
You don't need Carbon to run any instance of the WSO2 stack, simply 'install' it (unzip the wso2X.zip file) then make sure the service starts (call wso2X/bin/wso2server.sh start) and that's about it for the general setup, after that you need to configure each component to play nice with each other component (meaning you need to hook your BAM and CEP into your ESB, etc.) there isn't a lot of 'auto' config or discovery so it's usually easier to go the manual route with WSO2.
Also note that WSO2 products are Java extensions (essentially wrappers) around other Apache products (like Tomcat/Synapse) so usually if you are having a problem with WSO2, its because the underlying system (Tomcat/Synapse) was not properly configured (though that is no fault of your own as the WSO2 documentation does not make any mention of ensuring the base system is configured properly).
Also note that in my testing of WSO2 products, they consume huge amounts of memory (could not run more than the ESB and BAM on one machine because of the 8GB+ memory eaten by each) and a trouble ticket had to be put in to rectify a memory leak found in WSO2's Java modules, not sure if that was ever fixed.
Not trying to negate WSO2, but just be warned that it's not a pretty undertaking and you might fare better with other 'cloud' options if you have a choice.
edit: I've had to test out different 'cloud' stacks (with different types of 'plugins' or web services if you will) and how interoperable they were; as it turns out, they're pretty interoperable if YOU have total control over the individual stacks, otherwise the biggest downfall of any of the stacks that I found was simply documentation ... I don't care if a program has bugs or issues, as long as they are properly documented with possible workarounds (if any) so that I am aware of what is happening on my stack. Since WSO2's products were just Java wrappers for the Apache versions of their offerings (i.e. WSO2's ESB == Apache Synapse), any problems that occurred where usually solved in Apache's documentation (what little they had for certain problems) while WSO2's documentation had a lot of copy/paste issues (if they had any documentation beyond version 1). It was usually easier to just download and install the actual Apache offerings over WSO2's offerings then afterwards install WSO2's products and point them to the valid Apache configs/installs.
I did some testing with the Microsoft stack with Azure and general IIS/.NET offerings of equivalent services (The IIS/.NET equivalents of an ESB/CEP/BAM/etc. for what could be found). On the MS side, the documentation was enough (and there's enough people buying into the hype of cloud right now) that I could stand up most of the services semi-easy. I say semi-easy because of the misnomer (or my misunderstanding) of the 'ease of use' of 'cloud' services. I also found a product called Neuron ESB which is a .NET ESB offering, though I didn't do any thing with it during my testing so I can't speak to it.
Testing Amazon's offerings turned out the be some of the easier to setup and configure; the biggest issue with what I was testing for AWS was general internet latency.
Most of this is personal conjecture and I highly recommend you evaluate each as the 'cloud' space is constantly changing and each cloud platform has something slightly different to offer.
TLDR: the cloud space has a lot to offer and one should really consider what it is they are trying to achieve in the long run then evaluate each platforms offerings to see which fits. That being said, documentation and internal vendor interoperability (i.e. the vendor's products ability to easily communicate with each other) definitely help a product's 're-usability' factor.
Turing feature repository is not compatible with Carbon kernel 4.0.2. You can download Carbon kernel 4.2.0 and connect to Turing feature repository.
Related
I want to deploy only one carbon product (one JVM) containing the ESB component and the api gateway component.
Is it possible to build this kind of application ? Is there any reference documentation explaining how to do that ?
Thanks.
Every Carbon-based product comprise of a set of installable/uninstallable features. You can get an ESB pack and install API manager features on it (can do this via the management console UI). However you won't be able to put together mismatching versions of the features (features released for different carbon platform versions/components) so this is subject to availability of matching components. This documentation on feature management will give you some insights on how to do it. (There can be cases where components may be in total conflict though)
But if your requirement is just running two products on the same machine, you can consider running them with port offsets, which is easier.
From what I know, Parse offers convenient communication stacks for various platforms such as iOS, so it is easy to build clients that use your web app.
But Parse also seems to be tightly integrated with Facebook. If you were to build a web app that does not need Facebook, but that may integrate with Facebook in the long term, is Parse the clear winner over deploying directly to AWS, or are there important disadvantages to consider?
As far as I understand their page Parse is a PaaS (platform as a service) provider like Heroku and others while AWS is a IaaS (infrastructure as a service) provider.
Pros for PaaS:
They care about the infrastructure
You build your app on an existing platform
For the start you don't need "ops-guys" as you don't do ops
You can take their knowledge and prebuilt tools for your advance
Pros for IaaS:
You have full control about the underlaying infrastructure
You can start with a greenfield and build what ever you want
You can use tools like Puppet / Chef / ... to control your servers
You don't have to pay for the additional stuff you get when using PaaS
(but have to pay your people for it)
So there is not a winner of this "battle" but you have to decide whether you want to use prebuilt tooling and give some independence for this or whether you want to have the absolute control over everything (nearly as you can't touch the hardware) and invest time and manpower into building your own tooling.
"Better, Faster, Cheaper.."
If you are pursuing mobile first strategy, Parse is a great tool for bootstrapping a mature, full web-presence from nothing more than an original beta app.
I dont have direct experience with AWS.
I have used Heroku/Parse integrating (very quickly) a stand alone mobile app with the back-end where the back end needs to cover following:
DB/persistence/noSql
Workflow - async tasks
REST API interface HTTP
Once the mobile app existed with only stubbed local data , Parse allowed a single engineer to build out ALL infrastructure mentioned above very quickly, taking the app from single user to multi-user with full DB and workflow that backs client side events with considerable server-side and cloud side business logic and process. Scaling related startup stuff that used to take weeks took only days.
The compression (time&money) when scaling up an app stack is really something. The Parse API did almost everything that i needed with one small exception (remuxing UGC media).
Personally, i abandoned the parse/android SDK in favor of a more robust REST API (threading on client-side and heavy HTTP activity ).
Developers used to Curl/REST dev stacks will take to Parse.
Why would anyone use WSO2 Application Server instead of other application servers?
I rather encountered only problems with it, mainly due to class loading issues, so I would appreciate if someone could point out what are the advantages or the use cases when using WSO2-AS really makes a difference.
I can see the benefits of other standalone WSO2 products, but as far as the AS is concerned, I would rather rely on more lightweight servers and just package the libraries I need.
There are number of advantages on WSO2 Application Server.
1.) It provides in-built support for multi-tenancy, in case if you have isolated departments like organization there is no real need to have number of server instances you could simply create a new tenant.
2.) Automatic lazy loading support for tenants, web applications and web services. In a production system a particular tenant/web application/web service can be ideal for sometime it's a waste to allocate hardware resources continuously to such ideal applications specially if you use IaaS. WSO2 application server can detect such ideal tenant/web application/web service and release their resources and tenant/web application/web service will load again when a new request dispatch to the particular tenant/web application/web service.
3.) Wide range of deployment options, support to deploy on-premise, public or private IaaS , public or private PassS such as Apache Stratos. An an example one can deploy his application into WSO2 App Cloud (http://wso2.com/cloud/app-cloud/) instantly without downloading anything, later he can get same experience one of above platforms.
4.) Deployment synchronization feature, a clustered environment you may have very large number of nodes and upgrading application version and configuration changes across the cluster can be headache. Using Deployment synchronization feature you can modify only one node labeled as manger node and Deployment synchronization will take care about synchronize changes across the cluster automatically and consistently.
5.) When developing applications on WSO2 Application Server you can leverage carbon platform level features such as identity, registry, logging, distributed caching, multi-tenancy etc. As an example one can use identity features provided by the platform to mange users, roles permissions also for authentication and authorization without write something own.
6.) Inbuilt support for security standards such SSO among other WSO2 products.
7.) In-build monitoring capability for web services and web application through WSO2 BAM.
8.) Enhanced and rich dashboard for applications and services which facilitate to basic statistics, application management, security wizards, code generations, Try -It tools, run time logging configurations etc.
9.) Enhanced classloading mechanism (starting from AS 5.1.0), within one Application server instance you can have number of virtual server environments per application level. As an example one can specify an application run on minimal Tomcat mode or can assign to run Carbon mode which is ( Tomcat + Carbon platform).
When it come to your specific issue if you can specify your Application Server version and elaborate more on your classloading issue I can provide you more specific answer.
Having said above I want to mention that I'm from WSO2.
I'm trying to install and configure a highly availability setup for the WSO2 API Manager. I've been reading through this document: http://docs.wso2.org/wiki/display/Cluster/Clustering+API+Manager and in there it explains to break up the 4 components of the application into separate folders and that these 4 components can run on a single server. I'm not sure why this is needed. All I really want to do is take 2 servers, install the full application on both of them (without breaking the application up into 4 different pieces) and cluster them together between two servers with an Elastic Load Balancer in front of them.
What is the purpose of splitting up the multiple components on the same server if they all run out of a single installation? I'm looking for the simplest way to provide fail over capability to this application if one server goes down. Any insight into their methodology would be greatly appreciated.
Thanks.
The article you've linked describes on distributing different components of API Manager. If you look at the very end of that article there's a link to clustering configuration doc. In a production deployment usually it is encouraged that the 4 components are run on different nodes rather than having everything in a node and having multiple such nodes. That's why it goes on explaining breaking it down to separate components. The official AM doc below has a page on different deployment patterns.
You can go through the following articles to get a better understanding on clustering API Manager.
http://docs.wso2.org/wiki/display/AM140/Clustered+Deployment
http://sanjeewamalalgoda.blogspot.com/2012/09/how-do-clustering-and-enable-replicate.html
My 2cts:
The documentation mentioned in the remarks, explains how WSO2 sees the world of clustering. Spread the different functionality over different JVM's. This sounds logical from architectural point of view. A dis-advantages is that the diffent applications need to me administrated as well by operations. This makes the technical architecture rather complex.
In our situation, we defined 2 different servers with extra CPU and memory, on these servers we have installed the full WSO2 API Manager and defined the cluster configuration. Everything provisioned via Puppet.
Just a straightforward install, all data-source pointing to one schema in an Oracle database.
And...it is working; Our Developers happy, Operations happy, Architect department happy
I have been fighting with this for a while now. I need to prototype SOA, and with it, the registry. I have been fiddling with jUDDIv3 on JBoss SOA Platform 5, but there don't appear to be any tools that allow me to publish to a v3 jUDDI registry. See my related questions here and here.
I realize after reading comments on those questions, and some articles on the internet (like this one) that UDDI is failing or dead, however my organization has some legacy tech we need to work with.
Also, my supervisor (I'm an intern) is adamant about sticking to standards. In principle, I agree with this, but perhaps a dead standard really isn't a much of a standard if nobody uses it.
In short, I need to provide the registry component of Service Oriented Architecture. It probably needs to be UDDI, so that it fits with the legacy tech, and satisfies the standard. Whatever the solution, it would be best if there were tools available that allow me to publish web services to that registry.
This problem has dragged on much longer than I would have liked. Any small piece of advice is really appreciated.
You may use WS-Discovery. WS-Discovery is a standard protocol for discovering services and service endpoints. This enables service clients to search for services based on a given criteria and bind with the discovered services. There are tow modes of WS-Discovery,
ad-hoc - servers advertise the services they have using a UDP multicast protocol
managed mode - servers and clients use an intermediary known as the discovery proxy for all service discovery purposes.
You can simply try this out with WSO2 Platform (free and open source under apache2 license). Please follow [1] to see a simple scenario of WS-Discovery in managed mode.
[1] http://charithaka.blogspot.com/2010/04/ws-discovery-with-wso2-carbon.html