CodingAndBeyond

Project Troika

In today’s software mindfield, OSGi becomes a kind of buzzword. The popularity of this platform has increased significantly after the first publication of R4 specifications and their first implementation by ProSyst, Equinox and Knopflerfish. Since then, the software community not only adopted OSGi platform as the de-facto standard for modular and later service-oriented development in Java, but also has been offered several approaches aiming to alleviate developer’s efforts in building OSGi-based applications. Perhaps, the most popular among such offerings today are OSGi Declarative Services (OSGi DS), Spring Dynamic Modules (Spring DM) and Apache iPOJO. All the three approaches had been demonstrated in comparison to the ‘raw’ OSGi Platform API by Neil Bartlett and Heiko Seeberger in their comprehensive tutorial at OSGi DevCon 2009 (see Neil&Heiko@OSGi DevCon 09). Inspired mostly by this tutorial, I decided to start a small research project with the following goals: (1) gaining hands-on practical experience, (2) understanding the capabilities of each solution in dealing with certain aspects of OSGi application in comparison with the ‘native’ OSGi solution, (3) developing code patterns that may be useful in the future. In particular, I’d like to focus on the following aspects:

• selecting required service from a set of different services providing the same interface;
• developing application that may continue running when one of the required services is updated;
• realizing differencies between different approaches in handling service dependencies;
• using AOP features in Spring DM.

The name of the project is derived from the number of approaches in focus, and it also emphasizes the dynamic nature of the OSGi platform. Actually, this project represents slightly modified and expanded to include 3 different approaches task that was given to me as a coding test at one of the Silicon Valley start-up companies.

Before we delve into the project details, I would like to make a brief excursion around the technologies. My experience with the OSGi Platform started in March 2006 when I began developing OSGi adapter for IBM’s UIMA Framework together with Yurdaer Doganata and Mirko Jahn, who had just arrived from Germany to join our team at IBM Research. Our OSGi adapter (see DME for UIMA) did not reach production stage, but it was an exciting experience for us, and we learned some useful lessons in the area of Java modularization (see our paper @JDJ). One of the consequences of this first acquaintance is my today’s attachment to OSGi and related technologies.

Declarative Services (DS) exist in OSGi Service Compendium specifications since release 4 and continue evolving in later releases. Perhaps, the earliest practical introduction to DS can be found in Neil Bartlett’s ‘point-free blog’ (see Getting Started with OSGi, parts 7, 8). Reference implementation of DS provided by Equinox OSGi (see Equinox bundles) utilizes XML descriptors, as specified in the OSGi Service Compendium document. There are also early attempts to introduce annotations for OSGi DS (see Kai’s Blog), but in this project, I use standard Equinox implementation.

Spring Dynamic Modules (Spring DM) started as Spring OSGi back in 2006 when Adrian Colyer and Peter Kriens started talking about adding OSGi support in Spring Framework (see Peter Kriens at InfoQ and Adrian Colyer at InfoQ). The first release of Spring DM came in January 2008 (see Spring DM timeline) and later the framework had been presented at EclipseCon 2008 (see Spring DM tutorial). Today, several publications covering Spring DM are available (see Daniel Rubio’s book, Craig Walls’ book), and developers can use a comprehensive Reference Guide. In this project, I use Spring DM release 1.2.0.

The name iPOJO stands for injected POJO. iPOJO was presented in 2007 by Clement Escoffier and Richard S. Hall (see Clement&Richard @SC 2007) as a part of the Apache Felix OSGi implementation. The first release of Apache Felix iPOJO became available in October 2008 (see Clement’s blog). Today’s developers can find a lot of useful documentation, tutorials and references at the iPOJO web site. In this project, I use iPOJO release 1.4.0.

The last thing I would like to mention in this section is Eclipse PDE. I use it for all my coding needs in this project. Eclipse PDE has a lot of useful tools and integrates smoothly with both Spring DM and iPOJO, well … almost. One important moment is configuring plugins required by different versions of my application. I recommend setting-up different target platforms for different versions. Eclipse PDE provides the Target Definition editor making this process really easy. I’ll add more details on setting-up concrete target platform in corresponding sections. In this project, I use Eclipse PDE release 3.5.0 (Galileo) and run all versions of the application in Equinox OSGi console, which is a part of Eclipse.

Contents

1. Specifications
2. Design
3. Shared components
4. Native OSGi version
5. OSGi DS version
6. Spring DM version
7. Apache iPOJO version
8. Conclusion

This entry was posted on Tuesday, July 14th, 2009 at 5:18 am and is filed under Projects. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.