OSGi and SCA come together in the WebSphere OSGi Application Feature Pack

28 May 2010: The WebSphere V7 OSGi Application and JPA 2.0 feature pack is now generally available (and free!) and supported for production use. This is something we're pretty excited about in the WebSphere team as it offers some truly powerful techniques to simplify the development, management and maintenence of complex enterprise applications. I described some of the primary use cases for enterprise OSGi applications in a previous post about the early program we've been running since the end of 2009. Some significant additional capabilities have been added since then.

The first one I'd like to talk about is SCA. If you install both the OSGi Application feature pack and SCA feature pack then you'll find not only do you have the ability to assemble SCA composites and OSGi applications but you can also include OSGi applications as components in SCA composites - the combination of these two feature packs is greater than the sum of the parts. So what does it mean to use SCA with OSGi? The two technologies are used for quite different purposes but are extremely complimentary.

OSGi provides a means to break down your enterprise application into (i) modules (bundles) that are specific to the applicaton and (ii) bundles that are common across applications. The latter can be separated out from the application archive and placed in a common OSGi bundle repository that WebSphere is configured to use during application deployment. Immediate benefits include smaller applications, a standard mechanism for using shared libraries in enterprise applications and a smaller memory footprint when two or more enterprise applications share common libraries. And you haven't needed to write any new or different Java code to take advantage of this. Another feature OSGi brings is a standard extensibility model - through OSGi services. You can design your application to take advantage of OSGi's rich and dynamic service-based model to consume services from the OSGi service registry. Service interfaces then become extension points that you can design into your application and extend it in the future via service provider implementations introduced through separate bundles with no change to the original application code. OSGi defines Java APIs for registering and discovery OSGi services but a declarative approach to use OSGi services is much simpler. This is where the OSGi Blueprint container comes in - the Blueprint container (which is added to the WebSphere runtime when the feature pack is installed) manages the lifecycle and dependency injection of POJO bean components and is configured through an  application-level XML bean definition file which is a standards-based evolution of the Spring bean definition XML. Blueprint provides a fine-grained bean assembly model for OSGi applications and simple declarative means to publish a service provided by a POJO bean component. For example, the following bean definition snippet defines a bloggingServiceComponent bean, implemented by the BloggingServiceImpl class for which a BloggingService service is registered to the OSGi service registry.

<blueprint>
  <bean id="bloggingServiceComponent" class="com.ibm.ws.eba.example.blog.BloggingServiceImpl">
    <property name="blogEntryManager" ref="blogEntryManager"/>
    <property name="blogAuthorManager" ref="blogAuthorManager"/>
    <property name="blogCommentManager" ref="blogCommentManager"/>
  </bean>
  <service ref="bloggingServiceComponent" interface="com.ibm.ws.eba.example.blog.api.BloggingService"/>
</blueprint>

So now we can build a modular, extensible application assembled from POJO components described by a standardized XML bean definition file. No SCA so far - when does that become interesting?

Say you wanted to remotely publish the BloggingService and make is available over an ATOM binding. Or you wanted to compose your OSGi application into a coarse-grained composite with other non-OSGi components. These two scenarios are where SCA comes in. The WebSphere OSGi and SCA feature packs support both these patterns through the introduction of a new SCA implementation type, impl.osgiapp. By defining an SCA component for your OSGi application you can assemble it into an SCA composite with any other SCA implementation type - for example an EJB component (impl.ejb). And by promoting the OSGi <service> definition into an SCA component definition, the service becomes remotable with a choice of any of the standard SCA bindings to determine how the service invocation and parameters should be serialized. Thats a pretty powerful extension to raw OSGi applications and enables OSGi applications to be used as part of a SOA application deployed to WebSphere.

And then there's the tooling. The second major addition to our OSGi Application support that I wanted to mention is our Eclipse-based tooling to simplify the development and deployment of OSGi Applications. Integrated into the new RAD Beta are new project types for OSGi Applications, graphical tools for editing OSGi Application and OSGi bundle manifests and a Blueprint XML editor for blueprint module definition files. These offer familiar design and source views so you can choose to edit the metadata directly or through a form-based editor. And of course there's all the content assist, validation and re-factoring productivity tools familiar in RAD. The RAD Beta also integrates a test server environment augmented with the OSGi feature pack to enable simple run-on-server testing.

RAD Beta OSGi Blueprint XML Editor


The feature pack contains a number of comprehensive samples that illustrate the primary use cases. Try it out - and if you have any questions or comments, visit the OSGi Application feature pack technical discussion forum.