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...

2 comments:

Unknown said...

Interesting blog, Tim!

I do however believe the question is not what OSGi and SCA have in common, but rather how SCA can complement OSGi to make it an even more attractive platform (and vice versa).
Instead of wrapping OSGi in SCA, make use of SCA assembly ON OSGi following an Extender Model approach - just like other frameworks extend OSGi. In order to make bundles part of an SCA domain, you would enrich them with SCA assembly meta-data and be done.

After all, OSGi's deployment and management model is one of its strongest selling points. Why would one want to hide this behind another model, such as SCA's? SCA's notions of assembly, policy, and its ability to go cross technology should extend the OSGi platform rather than encapsulating it.

Thanks,
Henning

Richard Nicholson said...

Tim

You forgot to mention the Paremus Service Fabric - which as you well known was the first distributed OSGi / SCA platform and was first released in 2006! Well before the vendors you mention.

Cheers

Richard