Spring Dynamic Modules for OSGi: simplified development of OSGi applications

Posted by Ryan Slobojan on Jan 25, 2008

Sections

Operations & Infrastructure,

Enterprise Architecture,

Development,

Architecture & Design

Topics

Java ,

Enterprise Architecture ,

Open Source

Tags

Open Source Project Releases ,

JSR 277 ,

OSGi

The Spring Dynamic Modules for OSGi project, formerly known as Spring OSGi, released version 1.0 today. InfoQ spoke with SpringSource CTO Adrian Colyer and Spring Dynamic Modules project lead Costin Leau to learn more about this release and what it provides for the Spring community.

Adrian Colyer described the philosophy behind the Spring Dynamic Modules project:

The fundamental goal is to enable application developers to take advantage of the benefits of the OSGi platform (modularity, versioning support, module lifecycle / operations) when writing an enterprise application. Contrast this with the approach taken by some vendors that use OSGi in the construction of their product offerings, but don't pass any of the benefits of OSGi onto the applications that are deployed on those offerings. We want to make it as easy as possible to exploit OSGi without needing to write code that is coupled to the OSGi Service Platform (retaining for example the ability to easily unit test) and without needing to deal explicitly. Spring Dynamic Modules brings together the simplicity and power of Spring with the sophistication of the OSGi Service Platform.

Costin Leau said the main goal of the 1.0 release was the creation of a stable and robust foundation for working with Spring applications inside of an OSGi environment. Leau identified the major features of this release as:

• Automatic discovery of Spring bundles - an application context is automatically created for each Spring bundle as it starts by the OSGi-aware OsgiServiceFactoryBean, and the current application context is exported as an OSGi service
• Import and export of Spring services - exporting a Spring service as an OSGi bundle is one line of XML, as is importing an OSGi-based service
• Dynamic handling through service references and collections - if a service is updated or redeployed, services which refer to it will automatically get the new version without the requirement for an application restart -- this includes collections of services which match a given interface, with services being added/removed as they are registered/unregistered
• Listener mechanisms for event notifications - beans can register for OSGi bind/unbind and register/unregister events with any given OSGi service with one line of XML
• Comprehensive integration testing framework - integration testing is facilitated by the org.springframework.osgi.test package, which contains many OSGi-enabled JUnit test classes

Leau also indicated that a detailed explanation of all of the features in version 1.0 was available in the reference documentation.

Since the origin of the OSGi specification is in the mobile space, InfoQ asked Colyer whether there were plans to create a mobile version of Spring Dynamic Modules. Colyer responded that, due to dependencies upon Spring 2.5, which in turn depends upon JDK 1.4, it is not currently possible and that there were no current plans to create a mobile version of the Spring Framework. However, Colyer did indicate that there is a large amount of interest from current OSGi developers who are seeking to simplify application development, and that although most of those developers are in the enterprise realm, if demand increased for a mobile version then that would justify the investment needed to create it.

When asked about plans for the future of Spring Dynamic Modules, Colyer said:

The 1.0 release provides a solid foundation for creating Spring-powered OSGi based applications. The critical next step and the focus of the 1.1 release will be on making it easy to use common enterprise libraries in the OSGi Service Platform - with an emphasis on making web applications under OSGi much easier to build than they are today. SpringSource is also an active participant in the OSGi Enterprise Expert Group and we hope to help many of the ideas found in the Spring Dynamic Modules project to make their way into the OSGi R5 specification. Spring Dynamic Modules would obviously seek to support any such standards at that point in time.

Colyer also added that there were no plans to support other dynamic module frameworks such as JSR 277, and said "The industry momentum seems to be clearly behind OSGi".

1. Back to top

   EAR support?

   by Steven Devijver

   Are there options available to use OSGi in applications deployed as EAR files?

   Reply

2. Back to top

   good material

   by Erik Bengtson

   A nice comparison between spring osgi, eclipse extensions and osgi service component
   neilbartlett.name/downloads/extensions_vs_servi...

   Reply

3. Back to top

   Re: EAR support?

   by Neil Bartlett

   Steven,
   
   Yes, take a look at the Eclipse Equinox server-side support: www.eclipse.org/equinox/server/
   
   Ideally in the future, OSGi will permeate the entire JEE container rather than just being a small subsystem accessed through a "bridge" servlet (this has already happened to some of them). Using OSGi would then be a simple matter of deploying your bundle to the server just like any other. However, the bridge mechanism is a useful stopgap while JEE servers still exist on the market that are not OSGi-based.
   
   Regards,
   Neil

   Reply

4. Back to top

   Re: EAR support?

   by Stuart McCulloch

   There's also Pax-Web (wiki.ops4j.org/confluence/x/AYAz) which provides a Jetty 6 based HttpService and adds support for filters, etc. Alin has also written an extender bundle (wiki.ops4j.org/confluence/x/OQJN) that lets you deploy WAR files onto an OSGi framework using Pax-Web, it's pretty cool stuff.

   Reply

• Older >