We're currently working/testing/experimenting on WSO2. My question is that does WSO2 provides any service if the physical server itself (on which WSO2 is hosted) shuts down for any possible reason?
I know there may be several MANUAL alternatives for that but does WSO2 have a particular feature for physical server migration?
Note: Please let me know of what you think before down voting.
This can be achieved by clustering which is supported by WSO2 products, please refer clustering documentation for more information [1]. Fail over and Switch over can be configured automatically. Also you can achieve High Availability (HA) with multiple redundant nodes.
[1] https://docs.wso2.com/display/CLUSTER44x/Overview
Related
When clustering WSO2 products, you create a database for the registry and other items that WSO2 product use for operations. With the combined WSO2 Enterprise Integrator, it consist of multiple elements (ESB, Business Process Manager, Message Broker, Analytics, and MSF4J).
Do you create different registry database for each sub-product or you use only one that is created for the first?
OPTION #1: WSO2_USER_DB, REGISTRY_DB, REGISTRY_LOCAL1, REGISTRY_LOCAL2
OPTION #2: ESB_WSO2_USER_DB, ESB_REGISTRY_DB, ESB_REGISTRY_LOCAL1, ESB_REGISTRY_LOCAL2, MB_WSO2_USER_DB, MB_REGISTRY_DB, MB_REGISTRY_LOCAL1, MB_REGISTRY_LOCAL2 ... etc.
I understand that user database can be shared since the authentication manager is similar. But is it the case with the registry database?
I'm new to clustering so this question might be a little not appropriate for advanced users.
WSO2 EI can offer various services, usually separately. For example WSO2 EI for integration or WSO2 EI for process automation.
When you install this product in clustering you do it under a specific role and not combined.
In essence you have local registry for each node and one shared for the synchronization of artifacts.
I hope it helps you.
Each of the profiles included in the EI is separate runtimes. You need to configure the profiles only according to your use case.
For example: If you are using Integrator profile (ESB) and MB profile (MB) you need to maintain two different registry data sources for ESB and MB as defined in your second option.
OPTION #2: ESB_WSO2_USER_DB, ESB_REGISTRY_DB, ESB_REGISTRY_LOCAL1, ESB_REGISTRY_LOCAL2, MB_WSO2_USER_DB, MB_REGISTRY_DB, MB_REGISTRY_LOCAL1, MB_REGISTRY_LOCAL2.
If you want to share the users across both applications, you can use one USER_DB instead of using two separate USER_DBs for ESB_WSO2_USER_DB and MB_WSO2_USER_DB.
EI clustering guide can be found from https://docs.wso2.com/display/EI610/Clustered+Deployment
We are working on setting up the wso2 production environment and the question came up about the importance of having high availability databases on the identity server side. We have concerns regarding access tokens. Does the IDS manage all that information or is it shared among the other DBs? Also, if the DB happens to go down on the IDS side, will it case all of wso2 to crash? Will APIs no longer be available for use? I can't seem to find much documentation on the matter.
Thanks you.
Database high availability is needed for WSO2 products.Tokens will be saved in the database. If database goes down, Identity server will not function properly.
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.
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 choose one of forgerock identity management solution (openAM, openIDM) and wso2 identity server for implementing Identity and Access Management solution.
I'm interested in using following features:
Single Sign-On (SSO)
Policy based access control
Managing user identities
Connecting to central repository like Active Directory, OpenLdap, Oracle Internet Directory etc.
Etc..
Both open source products looks viable. I'm interested in having all of the above features along with good API to implement these features, along with active community support.
Which one would be the best amongst two ?
Thanks.
I am an architect from WSO2 - mostly leading WSO2 Identity Server. I am trying to be not bias as much as possible :-)
Both products bring you a comprehensive Identity Management platform - having support for SAML2, OpenID, XACML 3.0, OAuth 2.0, SCIM, WS-Security standards.
Few unique features that I would like to highlight on WSO2 Identity Server are...
Decentralized Federated SAML2 IdPs (http://blog.facilelogin.com/2012/08/security-patterns-decentralized.html)
Distributed XACML PDPs
User friendly XACML PAP wizard
High scalability (We have a middle-east customer using WSO2 IS over an user base of 4 million for OpenID support.)
Cassandra based User Store ( To be used over 800 Million user base by one of our production customers)
Light-weight and Very low memory footprint. The stripped down version of WSO2 IS can be started with 64MB Heap Size and the standard versions runs with 96MB Heap.
Highly extensible. The architecture behind WSO2 IS is highly extensible. You can easily plugin your authenticators, user store, etc...
Support for multi-tenancy.
Suport for multiple user stores (AD, LDAP, JDBC)
Interoperability.
Part of a proven SOA product platform provided by WSO2.
Also, we are planning to add support for OpenID Connect this year with a set of improved Identity Management capabilities.
You can also read more about WSO2 Identity Server from http://blog.facilelogin.com/2012/08/wso2-identity-server-flexible.html
You will not get an unbiased answer from me for your question :-) "Which one would be the best amongst two ?". You will aso get answers from Forgerock and other folks here. Best would be to evaluate and decide.
I'm a product manager at ForgeRock, but not for the products you're mentioning (OpenAM, OpenIDM).
ForgeRock Open Identity Stack has complete support for all your requirements, based on existing standards such as the ones mentioned by Prabath. It presents a single, common REST API to interact across the platform.
It's easy to deploy, modular, lightweight and yet highly extensible.
But in my opinion the key point is that it's a proven solution, deployed by hundreds of organizations, with built-in internet scale. The solution has been chosen by telecom service providers, medium and large enterprises for internal or customer facing services.
And I agree with Prabath, now that you've got answers from ForgeRock and WSO2, best would be to evaluate and make your own decision.
Regards.
Ludovic.
I am currently evaluating WSO2. It has a more permissive APACHE LICENSING Model and a more friendly management model from my having met with ForgeRock people.
Abdul, please share your findings as I am looking at both as well. We implemented OpenSSO in production a couple years ago just prior to its transition to OpenAM. It was an excellent product with thought leadership and decent execution. Unfortunately the pending transition to OpenAM was too unnerving for some of us and we switched to another product at great, unnecessary cost and continue to look over our shoulder. Some downsides at the time were ability to migrate policy through lanes from dev-test-stage-prod, keeping configurations in sync, and issue resolution. Also, fine-grained policy was very new. So my info is a bit dated and I know they have matured since then.
Just starting with WSO2. It has strong thought leadership and good execution with several platforms per other reviews. Their base architecture looks solid and it's allowing them to create and consume/improve open source technology very quickly into integrated, commercially supported solutions.