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.testpackage, 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".