Each installment of Innovations within reach features new information and discussions on topics related to emerging technologies, from both developer and practitioner standpoints, plus behind-the-scenes looks at leading edge IBM® WebSphere® products.
IBM and OSGi
OSGi is described as the dynamic module system for Java. IBM is one of the founding members of the OSGi Alliance which promotes widespread adoption of the OSGi Service Platform to assure interoperability of applications and services delivered and managed via networks. IBM has been using OSGi technology inside IBM Lotus® and WebSphere products for many years. In fact, OSGi has been used in IBM WebSphere Application Server since Version 6.1. This has been largely invisible to users because OSGi was employed to bring modularity to the underlying application server architecture, thus making it both easier to develop and to support. The WebSphere Foundation has been using OSGi to improve IBM products, and now the WebSphere Application Server V7 Feature Pack for OSGi Applications and Java Persistence API (JPA) 2.0 (hereafter referred to as the OSGi feature pack) enables you to use OSGi to improve yours.
One of the key considerations in introducing an enterprise OSGi application programming model was to ensure that it was an accepted standard across the industry. This has been the focus of the Enterprise Expert Group (EEG) within the OSGi Alliance. Many vendors contribute expertise to this group -- representatives from Oracle, SAP, VMWare, RedHat, Progress, and others work along with IBM -- to ensure that any standard will be widely supported.
Why enterprise OSGi?
Before describing the highlights of the OSGi feature pack, it is worth spending a moment outlining the problems that it can help to resolve.
Among other things, organizations use WebSphere Application Server for its ability to deploy and manage large numbers of applications. These applications frequently include common libraries. In such circumstances, it is not unusual for application developers to include a copy of the same library in each application. Although this is a safe way to ensure that each application always gets the library that it expects, this strategy can potentially consume excessive amounts of memory and make updating the application unnecessarily difficult. Software vendors provide workarounds for this problem, but they are vendor specific and still incur cost in system administrator time.
Vendor libraries are sometimes used inside applications and, typically, the developer has little control over the dependencies of these libraries. This can lead to a problem when two libraries used by an application have different and incompatible internal dependencies; for example, one library might require ASM 3.0 and another library used by the same application might require ASM 2.0. To work around this type of issue it is usually necessary to change code.
In summary, both problems can usually be worked or coded around in Java EE, but why tolerate the difficulty of working around an issue that can be resolved by OSGi?
The EEG was formed within the OSGi Alliance in 2007 and has produced the specifications that are implemented in the OSGi feature pack. The purpose of the EEG is to look at the most commonly used Java EE technologies (for example, JPA, JTA, JNDI, JMX, and so on) and establish standard ways of using these technologies from application bundles deployed to an OSGi framework.
Open source and OSGi
Two open source projects providing implementations of the OSGi enterprise specification were started within the last year. The Apache Aries incubator was started in Sept 2009, seeded with a Blueprint implementation developed by the Apache Geronimo community. The Enterprise Modules Project, announced later in 2009 and hosted by the Eclipse Foundation, has broadly similar goals to Aries.
Within a very short space of time, a broad and active community has been established around Apache Aries. Contributors include individuals from IBM, Progress, RedHat, Ericsson, SAP, Prosyst, and LinkedIn. Since the original contribution of Blueprint, components for JTA, JPA, JNDI, and JMX have all been added. Samples that show how to use each of these technologies, including the Blog Sample and Aries Trader applications, are an important part of the project.
Another area of active development in Aries is the "application" concept, which is a way of grouping bundles into a single application or Enterprise Bundle Archive (EBA).
OSGi feature pack
The OSGi feature pack delivers an integrated application framework to help Java EE application developers leverage OSGi enterprise architecture. The feature pack integrates components developed in Apache Aries with the WebSphere Application Server runtime and administration. (Support for JPA 2.0 is also delivered as part of the feature pack, but will not be detailed in this article.)
Specifically, the feature pack delivers open community and standards-based implementations of the OSGi Blueprint Container specification with the ability to assemble, deploy, and manage applications as a collection of versioned OSGi bundles. Common Web application requirements for modular design, simple POJO-based components, and efficient data access can be addressed by using both the OSGi applications and JPA 2.0 components of the feature pack.
Some of the key features of the feature pack are described below. Upcoming articles will describe these and other features in much more detail.
- Enterprise Bundle Archives
The bundles that form an OSGi application can be assembled logically to form a deployable Enterprise Bundle Archive or EBA. When developing Java EE applications, it is typical to place all the module binaries (application contents) inside an EAR file. In contrast, application metadata in the EBA describes the application content, but it is not necessary to include the binary content in the EBA. The EBA can simply refer to bundles that can be obtained at an appropriate stage from a bundle repository. The most common scenario is likely to involve placing some bundles within the EBA and referring to others. For example, Web modules are a key part of an application, and so they would naturally be in the EBA file; non-application specific content (for example, shared libraries) would be better obtained from the bundle repository. Look for a discussion on the bundle repository and exactly how and when it provides bundles in an upcoming article.
- Web applications
As defined by the OSGi Web Container specification, the Web content of an OSGi application is simply a Web module with additional OSGi metadata. The specification defines the metadata required for a Web application bundle to be formed from a WAR file. At deployment time, WebSphere Application Server converts WAR files found in the EBA to OSGi bundles. The advantage of deploying a Web module as a bundle is that the libraries it depends upon can be be moved from the WAR to a centralised, managed, versioned bundle repository that is used by the WebSphere Application Server deployment process.
The OSGi Service Platform Enterprise Specification describes one major additional technology on top of Java EE, known as Blueprint, which is a standardization of the Spring Dependency Injection model. Although the use of Blueprint is not required by enterprise OSGi applications, the WebSphere Application Server implementation provides a number of features that make it an attractive technology for developers.
The OSGI feature pack implementation of Blueprint provides capabilities that users expect from a Dependency Injection (DI) container; for example, the ability to build using POJOs and have the container control the lifecycle of those POJOs. One benefit of Blueprint implementations over DI containers such as the Spring Framework is the OSGi integration. This means that bundles can publish services which can then be injected into other components or even other bundles. This dependency injection model also enables unit tests to be run outside either a Java EE or OSGi runtime.
The Blueprint container implemented in the OSGi feature pack is part of the middleware and no longer part of the application, removing one headache for an application programmer.
- JPA persistence
OpenJPA is the default persistence provider in WebSphere Application Server. The OSGi feature pack includes support for JPA 2.0, so developers can use either the existing JPA 1.0 support in WebSphere Application Server V7 or the new JPA 2.0 support in OSGi applications.
In addition to the JPA model described in the OSGi Service Platform Enterprise Specification, the feature pack includes extended JPA support to provide full container managed JPA to Blueprint components, thus giving a familiar development experience to application developers who currently use JPA within Java EE.
The feature pack also includes extensions to Blueprint so that the container can inject persistence units and contexts into Blueprint beans. The transactional behaviours that application developers are familiar with in EJBs are also available in the OSGi feature pack.
Enterprise Web application developers looking for reliable and proven modularity technology are increasingly turning to OSGi. The IBM WebSphere Application Server V7 Feature Pack for OSGi Applications and Java Persistence API (JPA) 2.0 provides an environment that enables Java EE developers to build applications using OSGi capabilities.
Feedback on the OSGi feature pack, interest in Apache Aries, and interest from existing WebSphere Application Server users suggest that Java EE developers are ready to embrace OSGi technology and look forward to the many benefits it offers.
- WebSphere Application Server V7 Feature Pack for OSGi Applications and Java Persistence API (JPA) 2.0
- OSGi Alliance Specifications
- Apache Aries
- Apache Geronimo
- IBM developerWorks WebSphere