OSGi: An Overview of its Impact on the Software Lifecycle

Written by Scott Cranton, Principle Solutions Engineer, FuseSource

OSGi technology brings a number of much needed benefits to the Jaa enterprise application market, and is disruptive in that it impacts the software development, deployment, and management practices of many organizations. OSGi impacts deployment given the shared, modular nature of OSGi, meaning application code must be written differently to capitalize on the benefits of OSGi. Equally important, application management processes need to be adjusted, given the highly shared nature of OSGi modules across many applications. This article provides a high level overview of OSGi, and the impact this framework is having on the software lifecycle.

What is OSGi?

What started life as an acronym for the Telecommunication industry’s Open Services Gateway initiative (OSGi) has today expanded to cover Java development across industries and enterprises. Originally conceived and designed as a Java software framework to make it easier to build modular applications able to support always on, constrained environments such as a cell tower switch, OSGi is now being adopted by all the major enterprise Java software providers including all the major Java EE application server vendors (e.g. Oracle, IBM, JBoss). But what prompted the evolution of OSGi? Much like telecommunications services providers, most, if not all, enterprises are running applications or infrastructure that must stay “on” and support dynamic updating of new versions.

The OSGi framework covers three major areas: Bundles, Lifecycle, and Services. The Bundle layer is the most visible, and most used part of the OSGi framework. In short, the Bundle layer is represented as a JAR file (Java ARchive) that includes extra information about what parts of its content can be used by other applications, as well as its dependencies. The Lifecycle layer defines a sequence of steps that the bundles (your code) go through when installed, started, updated, stopped, and uninstalled. Having the lifecycle explicitly defined allows the code in the bundle to start managing its own resources. Equally important, the Lifecycle layer helps administrators catch issues early as OSGi mandates that all external dependencies be resolved before a bundle can be used. If the dependencies cannot be resolved, an error is logged BEFORE the bundle starts. Clearly, this is a much better process than getting a phone call in the middle of the night during a critical process run. The Services layer exposes services running code objects that can be called from other code running in the OSGi server. The big difference for OSGi Services is that the framework allows the service implementation to change at runtime – the concept of dynamic updating referenced earlier.

The positive impacts of OSGi on the application development process are clear, but what about application deployment and management? And why is deployment and management even important to the developer?

For more insight into why OSGi (http://www.osgi.org/About/WhyOSGi), and the details of the OSGi specification, you should go to the OSGi Alliance site at http://www.osgi.org.

Impact on developing applications

The most visible OSGi change for Java developers is the OSGi Bundle layer. As indicated earlier, this is extra information that is included with the code that explicitly says which Java packages others can use (export), and which Java packages are needed at runtime from others (imports). This additional information allows a developer to be more explicit in code dependencies than ever before, making it significantly easier for teams of developers to work together, and benefitting the overall code maintenance process. In fact, OSGi has been described as providing true Java application modules.

There is also version information about imports and exports, which allows multiple versions of Java libraries (e.g. hibernate or log4j) to be deployed on the same server at the same time and NOT cause of the traditional conflicts which developers encountered.

As developers get more sophisticated with OSGi, they will better understand the critical importance of the Lifecycle layer. At the most basic, it’s a great place to get (start) and release (stop) external resources such as database connections. This eliminates the need to generate the often complicated code required to safely manage connections in the middle of your code.

Some will eventually look at the OSGi Service layer; most to access existing capabilities such as configuration management and logging. Some will share and consume code in different bundles (modules) using OSGi services to take full advantage to runtime versioning of components. Imagine the ability to install a patch to an application module in a running system without needing to write lots of fancy code into your application. That’s what OSGi services offer the enterprise developer.

Deploying an OSGi application

We’ve already talked about developers putting dependency information into their code bundles, streamlining the deployment process. When you install an OSGi bundle into a server, you can ask the server if all of the dependencies are present, what those dependencies are, and if some are missing, what (and what versions) are missing. All this dependency checking happens before the code is started, so you can catch issues early (before you pager goes off). It also enables the ability to record the full dependency tree, including versions, of an application at any point in time so you can better track changes to your system and how that relates to application changes.

Several OSGi servers, such as Apache ServiceMix (http://servicemix.apache.org) or the productized distribution Fuse ESB (http://fusesource.com), allow OSGi bundles to be installed and upgraded from Apache Maven repositories. Maven is a build system that can keep software artifacts within a set of locations (repositories) with a number of build time advantages for automatically downloading all dependent code libraries such that a code build can run. For deployment teams, this allows for much closer coordination between themselves and the development team as all team members are working against a common repository. This allows deployment teams to update running systems with a single command once a patch has passed all QA tests.

Managing an OSGi application

One of the biggest advantages, and potential challenges, for managing an OSGi-based application is the amount of code (bundle) sharing between applications. This can present a challenge for traditional management processes as extra consideration must be given to updating a bundle. For example, how will one update impact other bundle(s)? The good news is that there are a growing number of tools for OSGi that make it much easier to understand the dependencies, and the potential impact, of updating or removing code bundles from a system.

Another advantage of OSGi-based applications is the capability to leverage the OSGi Configuration Admin service, which allows systems administrators to package, change and audit changes to the configuration of bundle properties. For example, the host name and port of the database that a given bundle should access can be managed as OSGi configuration properties giving the administrator a common way to see those properties, make runtime changes, and audit changes.

Summary

This article provides a high-level overview of the impact of OSGi to the enterprise software development, deployment, and management lifecycle. The impact of OSGi across the software development lifecycle means that applications can be more robust and dynamic than ever before, including to the ability to develop and deploy applications that never, ever are unavailable. Getting ready for OSGi will involve changes to both how you write applications, and to how you deploy and manage those applications, so try to think of both technology and process changes as you learn more about OSGi.

About the Author

Scott Cranton‚
 Principle Solutions Engineer‚ 
FuseSource (http://fusesource.com)Scott is a veteran in the enterprise software field with more than 20 years experience as an architect, consultant, and product manager. Scott has worked with many Fortune 100 enterprises in many industries, including Telecommunications, Financial Services, Energy, and Retail.