OSGi for application modularity - one company's design choice

Posted by Floyd Marinescu on May 01, 2007

Sections

Architecture & Design,

Development,

Enterprise Architecture

Topics

Design ,

Modeling ,

Java

Tags

OSGi

OSGi is a specification of a Java based service platform targeted for use by systems that require long running times, dynamic updates, and minimal disruptions to the running environment. Much has been written about the the adoption of OSGi by tools vendors (Eclipse being the first) and application server vendors (IBM, BEA, Oracle) who have used OSGi to create micro-kernal & plugin architectures to enable good modularizatoin and dynamic assembly at run time.  However, one of the areas OSGi may have the most impact for developers in the future is as a better component model for application development.  JSR 291 (OSGi core spec R4.1), strives to: 

...define a dynamic component framework including component lifecycle for existing Java SE platforms. The dynamic component model will support assembly of applications from components and support implementation detail hiding between components as well as lifecycle management of those components.

Will OSGi become a tool of choice for enabling component development for Java development?  InfoQ spoke to a company who has decided to build the next version of their application architecture around OSGi to learn more about why they decided on OSGi.   BPS is an ISV who sells risk management software that helps organizations comply with internal audit and compliance related business processes (e.g. The Sarbanes-Oxley 404 act). Their products are predominantly used by large financial institutions with stringent constraints and demanding IT environments. InfoQ spoke to BPS Chief Architect Gavin Terrill about why they chose OSGi for their next architecture. According to Gavin:

An interesting problem we have been struggling with for some time now is how to run multiple versions of a service simultaneously, in the same VM. The scenario is that two applications, A and B, have been integrated with our application, C. After the initial deployment of C, features are added to support the next release of A. Now the fun starts, as we need to update our deployed application with the new code, but without a server restart, and without breaking anything that B depends on. OSGi helps us solve this type of problem through the ability to dynamically provision and version software components (bundles).
 
Another of our goals is to adopt more of a service oriented approach to our codebase. Note the use of little 'S' and 'O' here - we want the goodness of loose coupling, separation of concerns and localized testing, but we don't want the inherent complexities that accompany doing this out-of-process, ala Jini or DPWS (nee UPnP). We have already built our product with these ideals in mind, taking full advantage of Java's interfaces, and corresponding implementations that can be plugged in using dependency injection courtesy of the Spring Framework. OSGi takes it to the next level by making services more modular, but still doing it in a lightweight manner.

On why OSGi was a better option than the typical EAR/WAR file approach, Gavin suggested:

While there is nothing wrong with the existing mechanism per se, I think the level of granularity for EAR/WAR deployment is too high to be practical. If I have only touched one jar file, why do I need to reload the entire application?
 
Deployment of Java applications has generated a lot of discussion in the Java community, beginning with the introduction of the .jar file, through to JSR 277/294. The "Java Module System" (JSR 277), coming down the pipe for Java SE 7, is interesting. At first glance, it looks like it was conceived in response to the .Net assembly idea. However, the fact that OSGi has been proven through Eclipse (and others) speaks volumes to us. It is hard to argue with something that has already been through the trials and tribulations of dealing with deployment problems encountered in the wild.

The design center for OSGi matches our requirements: a lightweight, in-process, service container framework with full lifecycle support

As BPS is already building a Spring-based application, they intend to make use of Spring-OSGi during the re-architecture. Spring OSGi first milestone was recently released.  

Re-architecting around OSGi is a major bet for BPS, Gavin reflected: "Back in 2004, when BPS made the bet to re-architect the product, The Spring Framework was seen as a relatively risky choice compared to the more conventional EJB approach. That bet paid off big time, based on feedback from our developers and customers. OSGi is a similar type of bet for us in that it is still early days, but I believe that in a couple of years time it will also be seen as the de facto standard when architecting IT friendly, service oriented enterprise-scale Java apps."

OSGi can also be an architectural asset to promote component oriented software development in organizations, as InfoQ reported in November about Piero Campanelli's analysis found the following benefits:

• True Component Development - While simple in concept, componentized software can be difficult in practice. The structure of OSGi addresses issues such as dependency tracking, version tracking, and service binding.
• Secure Development Across Teams - The OSGi microkernel style inforces rules to keep components and extensions isolated and controlled.
• Standard Management of Company Projects - If all projects are broken down into OSGi components they are easily reused. The example of the the Eclipse repository is given.
• Version Tracking - OSGi provides versioning support to address the question of Can I integrate with this library? Does it conflict with this version of another library?
• Architect Designer Assistance - The rules in OSGi allow architects to easily determine if build dependencies are broken without having to run the entire build

 InfoQ has covered OSGi quite closely, see InfoQ.com/OSGi. 

1. Back to top

   JSR 277 (not 177)

   by Alex Miller

   That should be JSR 277 (Java Module System), not JSR 177 as mentioned in the article several times.
   
   If you're interested in more info on JSR 277 and 294, check out the resources on my Java 7 page.

   Reply

2. Back to top

   Re: JSR 277 (not 177)

   by Floyd Marinescu

   fixed, thanks.

   Reply

• Older >