Monday, January 26, 2009

OSGi and SCA

I am pretty sure you have heard about SCA (Service Component Architecture) by now. It is hosted by OSOA at http://www.osoa.org.
Since pretty much the same players that are working on SCA are also members of the OSGi Alliance, it seems natural to find common grounds between the two.

At the inception of the Enterprise Expert Group (EEG) in January 2007, we already discussed the possibilities in combining the two technologies somehow. We started RFP 81 to capture the requirements and use cases. For some reason, the RFP was never really paid as much attention to as other EE related RFPs. Given the fact that several companies are bringing out SCA based or supporting products (TIBCO with ActiveMatrix, IBM, Oracle, etc.) the RFP deserves another close look and some tender love and care.

I, myself, am not particularly an expert in SCA, but I begin to grasp the differences in the modular, dynamic, and service oriented architecture of OSGi versus the more deployment oriented, static service composition model of SCA. Candidly, I would summarize this as 'SCA wants to rule the world in large', while OSGi is happy in ruling the services and modularization in context of a single technology and JVM process. SCA is technology independent, OSGi by all means of current practice is JAVA bound.

What do they have in common that is worth specifying?

Well, for one thing, there are more and more customers out there that understand and like the OSGi service programming model. Thanks to component technologies like Spring it becomes very easy to structure a big hairy and complex application as a collection of small beans, which are packaged up as bundles. In the EEG we specified Blueprint Service as part of the EE Edition of OSGi, which will come out some time later this year. For those who don't know or forgot, the RI of Blueprint is the version 2.0 of Spring Dynamic Modules.

Now, if I use SCA to describe my big scary application deployment or domain in SCA terms, can I make my OSGi bundled application part of that SCA domain? I think, it should be as simple as modeling my application as a SCA composite, define the implementation type as implementation.osgi, promote my references as services via the OSGi service registry, and use Configuration Admin to configure the application at runtime. Sounds easy, doesn't it?

Turns out, not so much. I recently discussed this with one of my fellow EEG members during our last face-2-face meeting in Bedford, MA. Apparently, SCA doesn't like the constraint so much that services and references are bound to a particular binding type (OSGi service registry). Their ability to function depends on the fact that those other services are co-deployed with the application in the same OSGi framework.

However, there are a few things that can be done about this.
* the SCA runtime could start a framework dedicated to the OSGi application and wire the external services and references using SCA means. In case the SCA runtime is built itself as an OSGi application, the new RFC 138 Multiple Frameworks specification in OSGi comes in very handy. It allows an OSGi framework to efficiently manage a child framework.
* remove the restriction of having OSGi services only available to the local OSGi framework. This is the power of RFC 119 Distributed OSGi scheduled to be released as part of the EE Edition later this year. When services are now distributable or at least accessible across the JVM process boundaries, then the OSGi binding type becomes interesting for SCA applications again. One of the advantages of RFC 119 is that this scenario has native support for the SCA intent model. So, matching services and references based on intents with the option of additional metadata for policies makes the integration of SCA and OSGi look natural and seamless.

Join our talk about Distributed OSGi at EclipseCon 2009 to hear exactly how this is going to work for you.

As you were...