Spring Framework - the de factor standard IoC container of Java world promotes loose coupling among layers/components. Osgi - also be the de factor standard of module management platform promotes the module development, that helps application can manage the life cycle of services, dependencies of services with clear and ease. The combination of Spring and Osgi is the great combination and the benefits they bring is greater than sum of benefits of each platform. Here are the main benefits that Spring Dynamic Modules could bring to us (according to Reference document of Spring Dynamic Modules):

• Better separation of application logic into modules, with runtime enforcement of module boundaries (Osgi provides)
• The ability to deploy multiple versions of a module (or library) concurrently (Osgi provides)
• The ability to dynamically discover and use services provided by other modules in the system (Osgi provides)
• The ability to dynamically install, update and uninstall modules in a running system (Osgi provides)
• Use of the Spring Framework to instantiate, configure, assemble, and decorate components within and across modules. (Spring + Osgi)
• A simple and familiar programming model for enterprise developers to exploit the features of the OSGi platform. (Spring + Osgi)

The two most important benefits that Spring Dynamic Modules bring to us is the last two items of above list. Let investigate them with our real example:

We are developing the enterprise application base on SaaS model with many modules such as human resources, project management, timesheet, chat, video conference etc. All public services are exposed via Spring beans. To make the loose coupling among services, we define the rules at services of different component could be use the other services via interface (of course, it is the rules that all
developers are aware but junior developers can eventually break the rules by calling the implementation class). We faced the following problems that encourage us to choose Osgi:

• Our application must integrate with other applications such as forum, wiki, calendar that have many third-party jar files and some of them are conflicted in version (and usage). For example, our main module use lucence (2.3.2 version) for search function. However, jackrabbit module can not work with this version of lucene but the lower version one 2.2.0.
• Each module of engroup application could be installed/updated/removed without requiring application reboot.

Without osgi, you could develop and maintain your own created class loader and meta data to resolve the first one and create the framework that manage your services for the second one. With osgi, you do not need to do anything except modify the manifest file follow osgi rules with the great help of maven osgi plugin (thanks for bnd tool and felix team to provide the community this tool). Ok, we finish the first step that bundle our services into bundles and expose the necessary interfaces for other use.

Another problem is we already developed many services under Spring bean form, and how other bundle can recorgnize the spring bean service locates from other bundle. Spring Dynamic Modules for Osgi solves this issue very well. Just by declaration in spring context file, my spring service can use other spring service of other bundle! Great! I can define the datasource spring bean in shared module and other module could use this datasource in its bundle (not need to use import tag in spring context file) but treat it as exposed service of shared bundle.

And the great consequence that Spring Dynamic Modules can provide to us that we only exposed the service under the Spring bean form, not need to register our service into service registry in bundle activator, if we need to expose our service to other bundle, we define the service in spring osgi context file (we only write the bundle activator for special case only), also we do not manage the life cycle of bundles but we manage the life cycle of spring beans. For example, before starting the human resource module, we need to create the neccessary tables for this module, instead of writing the initializing database in bundle activator, we do it in human resource spring bean (implement the LifeCycle interface). By doing this, we make our business code loose coupling totally with Osgi framework (though we depends our code in spring - but we do not have any plan to use another IoC except Spring!)

With the great features of Spring Dynamic Modules (now we are upgrading our integration test with Spring Module version 1.1.0), it is the natural fit with Spring and Osgi in one platform. Developing application on it is the great interest with the development team. And thanks god, it saves us much effort of integration and use Spring in Osgi environment.

Related posts:

1. Unit test with Spring Dynamic Modules Follow our story about developing services by using Spring Dynamic...
2. How to invoke Spring beans in other osgi bundle Spring Dynamic Modules helps integrating Spring beans to Osgi platform...
3. Osgi – good platform for SaaS model If you are developing the software base on SaaS model...
4. Using Spring Integration in Osgi platform How to use Spring Integration in Osgi platform. This post...
5. Osgi – the first program Here is the simple Osgi application with Equinox framework and...