WSO2 Carbon (part 1)

I have a feeling I'm going to be blogging a lot about Carbon in the next few weeks, hence calling this "part 1". We are on the verge of releasing the Carbon codebase - the team is just putting the final touches to the download packs, and it seems a great time to talk about Carbon and what the vision is.

Firstly, Carbon isn't a "product". We already have a set of products, and we are launching new Carbon-based revisions of some of those:

• WSO2 Web Services Application Server v3.0
• WSO2 Enterprise Service Bus 2.0
• WSO2 Registry 2.0

Carbon is the framework, the foundation, the model behind all of these. And we aren't just launching new revisions, we are also launching a new product: WSO2 Business Process Server 1.0. Yes, a BPM product, this is our integrated version of Apache Ode, with support for BPEL processes. I know many of you will want to know more about BPS but I'm going to blog separately about the details of that. Let's get back to Carbon.

Firstly, Carbon is based on the Eclipse Equinox OSGi container. Equinox is a great OSGi container and OSGi is providing some key capabilities: modularity, lifecycle and services. Effectively OSGi allows you to build much more componentized systems, where the components have versions, very clear interfaces, and you can support multiple components with the same purpose. Effectively, OSGi brings many of the desirable aims of SOA into the JVM.

If you've ever heard me talk about Web Services and SOA, you will have definitely heard me talk about how the standards were built to be composable. Like Lego blocks, if you need security, plug in the security standard. And when we built Apache Axis2 we built a model that supported that. But composability at the WS-Security and WS-ReliableMessaging level is very low level. So we fixed that. Carbon is a composable server architecture. Effectively our products are now sets of components running on the core framework, and you get to choose which ones you want and need. For example, if you want to add BPEL support to the ESB, simply download the BPS component and install into your existing ESB.

Why? What is good about a composable server architecture. Well, three things:

• You can choose the deployment to suit your architecture: if you need some transformation and Data Service together, you can put together the system that supports this, simply, logically and consistently. And consistency is important. When you configure security on a process, its exactly the same code, UI and model as configuring security on a service. (By the way, we wrote zero new code to secure processes.)
  
• You just use what you need: you don't end up with a monster ESB hub running 4Gb of code because that was what the vendor offered.
• The system can grow, and not just through WSO2's efforts: you can grab OSGi bundles from other places, or simply repackage existing tools.

Now, the composable server architecture isn't just something WSO2 is going on about - Spring dm Server offers a similar model for building webapps, and IBM is promising it will come in WAS.next. But we think we have done something unique. We've figured out how to make it work for SOA.

My analogy is this: when you download Eclipse and start coding, you need know nothing about OSGi. But when you go to the plugin manager and add capabilities to your Eclipse tool, then OSGi becomes something really useful. Why? Because you can add UML support into your existing workplace and integrate it with your existing code. You can download SVN support and start saving all your resources into SVN. This is more than just OSGi - someone figured out what it meant to make a composable tooling platform. And we have done the same for SOA. We've figured out how to make a composable SOA platform.

What is a composable SOA platform? Its a platform where when you add new types of service, you can instantly do many things: secure them, try them out, configure logging, caching, throttling, statistics. Its a platform where every piece of metadata and configuration is stored consistently in a metadata Registry, with full versioning. So when you add new components and features, they fit into your SOA Governance model. Its a platform where you can mediate any service in a consistent way, without having to run a separate costly ESB. And its a platform where the administration UI seamlessly grows and extends to support just the function you need to know and work with.

Ok. You can tell I'm ultra-enthused about this! I am. And this is just the first step. 2009 is going to be an immense year.