Open Source SOA software vendor WSO2, who are are a driving factor behind many of the Apache Software Foundation’s web services projects, recently announced what they claim is “the industry’s first fully componentized service-oriented architecture (SOA) framework”, called WSO2 Carbon . The release of this platform is accompanied by new major releases of WSO2’s registry, ESB, and web service application server (WSAS), as well as a new product for business process automation called WSO2 Business Process Server (BPS). InfoQ spoke to WSO2’s founders, Paul Fremantle and Sanjiva Weerawarana, about the significance of this release.
We first asked about what users actually gain from Carbon. Paul Fremantle argued they gain two big benefits, the first being that developers can choose the right components in the right place for their architecture, and the second being about ease-of-use, adoption and skills portable between different Carbon-based products:
If you have learnt how to configure security in for Java Services, you can add Business Processes and you already know how to configure security for processes, because the same console, the same code and the same UI are shared across all the systems. Even better, you can add new components without having to re-install, just as you add new plugins into an existing Eclipse workbench.
We also asked why WSO2 chose OSGi, apart from buzzword compliance. Paul answered they actually started prototyping their own component model before the benefits of OSGi made them switch:
Firstly, OSGi has solved a lot of hard problems - versioning, lifecycle, service registry, and others. Secondly, being based on OSGi means that we can re-use a lot of existing systemsm, utilities and bundles. Finally, and probably most importantly, it means that developers can use a wide variety of components alongside the ones that come with Carbon.
Sanjiva Weerawarana claims that WSO2 are the first to actually use OSGi as the component model to create an SOA component platform:
That’s like the role Eclipse plays for tooling … it’s a platform with some built-in components and a framework for other components to plug into. For example, we have a very large software company as a customer right now who is OEMing and embedding all of our Carbon based products in their own world and extending our framework with their own OSGi components etc. So while IBM WebSphere may have been talking about OSGi, you can’t buy WebSphere Application Server and just “add” ESB or workflow functionality to it. With our stuff you can, today.
WSO2 has also released the first version of a business process server offering. Asked about the difference to competing products, Paul acknowledged that at version 1 it’s not yet designed to compete on feature ticklists:
It’s designed to be easy to use, simple to deploy and manageable. The biggest benefit of the BPS is the set of shared components it inherits from the rest of Carbon: full security management (including SAML-token support, signatures, and encryption), instant TryIt capability to test processes, logging and tracing, caching and throttling, and of course the ability to co-deploy other Carbon features like the Registry, Data Services, Mediation etc.
Sanjiva added that in his view, BPEL is a way to write (composite) services, and as such is positioned differently:
Unlike e.g. Intalio or ActiveVOS, we don’t treat BPEL as the center of the world. By viewing it as a service execution runtime, we’ve inherited all the supporting infrastructure for service execution – security management, reliable messaging, throttling, caching, etc.
He conceded that there is some more work to do to get clustering to work right. Asked about the view that the WSO2 platform focuses on Web services only, Paul vehemently denies this is the case:
Out-of-the-box we support Mail, File, JMS, FTP, FIX, TCP and HTTP transports, we have mediators to deal with legacy formats such as COBOL records, CSV files and even JSON. We support CORBA connectivity and we have first-class database access. We have a production customers accessing CICS and Mainframe services as well as using Hessian binary services.
From the documentation, as well as from a cursory look at how the products present themselves when started for the first time, WSO2’s story looks quite convincing. It will be interesting to see what experience users gain while using them in their SOA projects.
More information on WSO2’s new products (including download options) is available on their website.