Enterprise OSGi

For years, OSGi technology has flourished in the embedded systems and networked devices market. Till now, it’s remained a relatively obscure technology for the enterprise developer. Now, in part thanks to Eclipse, OSGi is emerging as a viable and valuable technology in the enterprise.

In 2003, the Eclipse team began looking for ways to make Eclipse a more dynamic Rich Client Platform and increase the platform’s modularity. Eventually, the team settled on the OSGi framework as the run-time component model, codenamed the project Equinox, and in June of 2004 released Eclipse 3.0. This newest version of Eclipse sported a runtime model based on OSGi. OSGi was no longer a technology isolated to use in embedded software and networked devices, but had now become the foundation upon which all Eclipse plug-ins would be developed, and the platform upon which thousands of software developers would use the Eclipse IDE to develop software. Eclipse adoption of OSGi marked a significant milestone for the OSGi Alliance, as adoption by a major product and brand such as Eclipse thrust it into the spotlight for many commercial software companies. Today, several major vendors build on OSGi, and almost all application servers used within the enterprise currently support, or plan to support, OSGi. While OSGi has not yet made significant in-roads to the enterprise, server-side support for OSGi is going to facilitate adoption of OSGi in the enterprise. And this is where it gets interesting for the enterprise Java software developer.

OSGi is a dynamic module system for Java. There is quite a bit of literature discussing OSGi at the OSGi Alliance, specifically the OSGi Technology page. Instead of rehashing what’s already been said, I want to focus on how OSGi is going to influence positive change for the enterprise developer creating server-side software applications.

• Modular Development - The OSGi framework defines a unit of modularization called a bundle. A bundle is nothing more, and nothing less, than a Java .jar file. A .jar file is a valid OSGi bundle if it contains resources that provide functionality, and a Manifest file containing metadata about the bundle. The resources can be Java classes, html, images, Servlets, and even JSP. The metadata is defined using required and optional key/values pairs. Since all developers are familiar with .jar files, creating a valid OSGi bundle is relatively straightforward. OSGi changes the deployment model for enterprise applications. Traditional thinking is centered around web application development, and teams devote valuable resources to identifying functionality contained within webapps, and inter-webapp communication. With OSGi, you won’t develop traditional web applications. Instead, you’ll develop bundles that are assembled into an application, so your development philosophy turns from application-centric to component-centric. While we’ve been attempting to design modular software for a very long time, OSGi enforces the design of modular software through these bundles and managed dependencies.

• Managed Dependencies - OSGi accepts reality that the .jar file is the predominant method of reuse and deployment with Java. OSGi treats a .jar as a first class component. The Manifest within an OSGi bundle defines export packages that other bundles can use, as well as import packages used by the bundle. Think of this as public and private access to the packages within a .jar file. With OSGi, you can now truly establish a component’s published interface simply through how classes are allocated to packages, and the packages made visible through export by a bundle. OSGi offers local transparency for it’s bundles, because you don’t need to include .jar files on the run-time classpath. Instead, exported packages within an OSGi bundle can be used by other bundles running on the OSGi platform. Optionally, some OSGi implementations may provide a Security layer that allows access to a bundle if permission has been granted.

• Component Platform - OSGi is a service platform because it reduces coupling between bundles. Yet viewing OSGi as only a service platform tends to lump it in with all other service (as in SOA) solutions. OSGi is also a true component platform that hits a sweet spot not presently accommodated for in enterprise Java development or SOA. OSGi is not a distributed service technology. Instead, OSGi bundles are deployed and communicate within a single JVM, making inter-bundle communication in-process and lightweight. OSGi bundles are true software components. The OSGi platform contains a framework specification, making it similar to any other specification you’ve worked with in Java, like the Servlet API, JDBC, etc. There will be numerous implementations of the OSGi specification, but your code should only ever refer to the OSGi package structure (org.osgi.*). Additionally, when you compile, you’ll want to compile against the specification, not the specific implementation you choose to use.

• Versioned Bundles - When exporting and importing packages from other bundles, you can specify a version number. Because bundles can be versioned, you can deploy multiple versions of the same bundle on the OSGi platform without experiencing fatal errors, such as a ClassCastException commonly experienced when the same class definition is deployed multipled times within the same JVM.

• Dynamic (Re)Deployment - OSGi allows you to deploy bundles individually, without performing a restart. When functionality within a bundle changes, you simply redeploy that bundle to the appropriate OSGi platform, and clients of that bundle automagically discover it through the packages it exports and it’s version. No need to redeploy entire applications. This offers tremendous flexibility if you separate implementation from specification in your application bundles, by allowing you to completely swap implementation without any interruption to other deployed bundles.

• Environmental Control - Because OSGi is a managed container environment, you have the ability to install, start, stop, update, and uninstall individual bundles.

Let’s take a moment, digest exactly what OSGi entails, and examine what it means for the enterprise developer in the trenches. No longer need we emphasize development and deployment of individual web applications and portals. Instead, we develop enterprise software systems as a composition of software components that can be assembled dynamically to form a complete system. The challenge of inter-application communication is a non-issue, since individual components can expose resources that serve content to the user, and consume behavior exposed by other components. No longer need we redeploy an entire suite of enterprise software systems due to a behavioral change in a single .jar file. Instead, simply update the .jar on the OSGi platform.

Extending the software system to support new processes is as simple as deploying or redeploying only the necessary components, without any interruption to critical processes. An SOA built on web services is also assembled from the same software components by simply building a service protocol layer on top of the appropriate components. It’s possible to assemble a rich client application from the same software components. Additionally, it’s possible to allow separate components within an OSGi container to utilize the behavior of different versions of the same component.

Because component dependencies are explicitly stated, the component structure of the application is well understood. At the very least, this minimzes the risk of change as the ramification of change can be more accurately assessed. Since OSGi bundle collaboration is in-process, granularity of components can be established that allow teams to maximize component reuse without incurring performance degradation due to excessive inter-component collaboration. Overall, OSGi has eliminated many architectural challenges with enterprise software development, and has established more refined techniques for deploying and managing enterprise software.

When you add it all up, OSGi fills an important technology gap between SOA and object-oriented design on the Java platform. For some time, we’ve been able to build flexible and extensible class structures in Java. With technologies such as EJB (primarily Sessions Beans and Message Beans) and web services, we’ve had a service deployment model. But we’ve lacked a robust component model. Today, there are several server-side open source implementations of the OSGi platform, including Server-Side Equinox and Apache Felix, as well as several commercial implementations. The current development release of Spring-OSGi supports building Spring applications that run in an OSGi environment. In typical Spring fashion, Spring managed OSGi bundles eliminate dependencies to OSGi. The Java Open Application Server v. 5 (JOnAS) is designed with an OSGi based architecture. Even Sun is noticing as is evident through the ongoing saga of JSR-291 and JSR-277. And interest in OSGi doesn’t stop there, as a quick Google search reveals.

OSGi is a key technology filling an important void in enterprise software development. While OSGi adoption within the enterprise may be a year or three away, as the platform continues to gain momentum it’s going to offer significant benefits to enterprise software development teams.

Comments