Potential Benefits and Drawbacks of JBoss OSGi
The goal of this post is to provide a high-level discussion of JBoss OSGi and to increase awareness of its potential benefits and drawbacks to a Java enterprise architect/developer.
A March Toward Modular Architectures
First mentioned by Douglas McIlroy in 1968 as a way to deal with the growing “software crisis” of the time, the steady march towards modular, component-based architectures continues. Today’s Service Oriented Architecture (SOA) patterns make use of components to provide the functionality behind the services. In my opinion, these architectures, along with widespread use of design patterns, are a sign of the maturation of the software industry.
We find the component concept everywhere we look in software. At the operating system level, we are comfortable with the concept of installing, starting and stopping various services (aka. components) in order to provide additional capabilities to the server. Also, we benefit greatly from the “modularization” of the Java EE services provided by the JBoss application server. In Java web development, we might use JSF components in the UI layer, EJB components in the business layer, and any number of “components” in the data layer, e.g., JPA to access a SQL database. So, we can see that components play a vital role in today’s enterprise architectures.
Unfortunately, the word “component” is used in many contexts and for different purposes, so let me clarify my meaning as it relates to this post.
What Is a Software Component?
Simply put, a component can be thought of as a self-contained unit of software that encapsulates a set of related functionality.
The drawback in the past has been the lack of a standardized way to build, deploy and run a component in Java (apart from the EJB component spec). That is the reason the OSGi specification was created.
What Is OSGi?
According to the OSGi website, OSGI is a specification that “defines a dynamic component framework including component lifecycle for existing Java SE platforms.” It provides a standardized way of building, deploying and running Java-based components.
Many implementations of the OSGi standard are widely used, e.g., Equinox used by Eclipse, and Apache Felix which is used in the JBoss OSGi implementation. JBoss OSGi, which was introduced as part of JBoss7, and is built upon the JBoss Modules project, provides JBoss developers with a fully compliant OSGi container in which to run their components.
OSGi Bundles
In OSGi nomenclature, a component is known as a “bundle.” In Java terms, a bundle is a plain old jar file. However, where in standard Java everything in a jar is completely visible to all other jars on the CLASSPATH, OSGi hides everything in that jar unless explicitly exported. A bundle that wants to use another jar must explicitly import the parts it needs. By default, there is no sharing. OSGi also provides a services layer that connects bundles dynamically via a publish-find-bind model for POJOs. You can think of the services layer as “SOA for the JVM.”
Another key piece of the architecture is lifecycle management, which also supports the dynamic publish-find-bind model (see diagram below). These features provide developers an environment in which to deploy applications as a composition of components that are assembled dynamically and can be started, stopped and replaced individually at runtime.
What Does OSGi Mean for Developers?
These capabilities open a new world of construction, deployment and runtime options for the enterprise Java architect/developer. Also, a growing number of Java EE specs have been mapped to OSGi, so we have the ability to use OSGi in conjunction with familiar Java EE technologies such as JBDC, JNDI, and JTA. We can even deploy a web application in an OSGi runtime via a web application bundle (WAB).
The reverse is also true; we can use OSGi bundles in our existing Java EE applications. The drawback to these new capabilities, however, is the complexity that is introduced, particularly with the introduction of the lifecycle concepts. I believe that frameworks created on top of OSGi, like Apache Aries or Blueprint, will be used to hide most of these complexities from the average enterprise developer.
There will, of course, still be a learning curve involved in using any new framework. Also, since many of the same things can be done in either an OSGi container or a Java EE container, there may be some difficulty in creating a clear demarcation of when to use OSGi versus pure JavaEE.
Final Thoughts
What does all this mean to me, an enterprise developer? Right now, I believe it simply means that we have an additional tool in our tool chest. As mobile, cloud, and social applications gain in their use and popularity, I believe use cases and patterns will evolve that will make these tools valuable in helping to create the next generation of enterprise applications geared toward these areas. As OSGi is still relatively new in its use in enterprise development, it will be interesting to see the impact and to what extent it will be utilized in enterprise Java applications going forward.
Additional Resources
In this free white paper from Forrester, they weigh available options for Java support.
