Fremantle and Weerawarana on WSO2's New OSGi-based SOA Platform

Posted by Stefan Tilkov on Feb 16, 2009

Sections

Architecture & Design,

Enterprise Architecture

Topics

SOA Platforms ,

ESB ,

SOA Appliance ,

Workflow / BPM ,

Web Services ,

SOA

Tags

Web services ,

OSGi

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.

1. Back to top

   first Component based SOA

   by Christopher Brind

   Sanjiva Weerawarana claims that WSO2 are the first to actually use OSGi as the component model to create an SOA component platform.

   
   
   That's a bit of a claim, since OSGi is a component model and SOA component platform. Besides, what about Spring Application Server or even Solstice ( www.arum.co.uk/solstice.php/ ).
   
   Any platform that uses OSGi becomes a component based SOA platform out of the box.

   Reply

2. Back to top

   OSGi 4.2

   by Christopher Brind

   This actually looks like a pretty good product. My question would be how it complies with OSGi 4.2? Granted it hasn't be officially released yet, OSGi 4.2 is going to add some pretty interesting features that might overlap the functionality provided out of the box with WSO2.

   Reply

3. Back to top

   Re: first Component based SOA

   by Paul Fremantle

   Christopher
   
   The claim we are making is that Carbon goes beyond just the plain OSGi plug model and defines important models for SOA, just as Eclipse defines how to plug components into a tool architecture. For example, the Security component protects any service, whether its a POJO Service, Data Service, BPEL-based service, ESB Proxy Service etc. Similarly our Caching module offers caching against any service. This requires work around the interfaces and the plug-points.
   
   In particular, compared to other OSGi systems, this is a full SOA platform including Registry/Governance, ESB, Business Process Manager and Data Services.
   
   You could also read my blog entry about this for more information:
   pzf.fremantle.org/2009/02/wso2-carbon-part-1.html
   
   Paul

   Reply

4. Back to top

   Re: OSGi 4.2

   by Paul Fremantle

   Christopher
   
   Can you outline which features of OSGi 4.2 you think overlap? I'd be interested in exploring that.
   
   Paul

   Reply

5. Back to top

   Re: OSGi 4.2

   by Christopher Brind

   You tell me :)
   
   www.osgi.org/download/osgi-4.2-early-draft.pdf
   
   But seriously, perhaps not that much. However, transactions will be an optional part of the OSGi 4.2 framework so it would be good is WSO2 could support these ahead of time. To be honest, I'm still sketchy on the details as I've not had much time really read up on the new features yet.
   
   With regards to your 'clustering', why do you think that is so important to get right? Martin Fowler's first law of distributed object design is "Don't distribute your objects". I realise that clustering is important for scalability, but I've started to come to the opinion that clustering VMs should be a last resort. Another interesting (optional) feature of OSGi 4.2 is the Distributed OSGi specification. If you really needed to scale up by using multiple VMs it might be better to segment services across containers (probably on their own hardware nodes) rather than just cluster the VM?
   
   Also, the distributed OSGi specification also accommodates external none-OSGi processes, Apache CFX have demonstrated this with Web Services. Give you're association with Apache (I hope I'm right to make that association), you're probably aware of this project, but anyway here's the URL:
   cxf.apache.org/
   
   Regards,
   Chris

   Reply

• Older >