Innovation at your fingertips: Are you ready to use enterprise-level OSGi?

IBM and OSGi

OSGi is a dynamic modular system of the Java language. IBM is one of the initial members of the OSGi Consortium, which aims to promote the widespread adoption of the OSGi service platform to ensure interoperability of applications and services delivered and managed over the network. For years, IBM has been using OSGI technology in IBM Lotus® and WebSphere products. In fact, OSGi has been used since the IBM WebSphere application Server 6.1 version. The user does not see it because OSGi is used to make the underlying application server architecture modular, making it easy to develop and support. WebSphere Foundation has been using OSGi to improve IBM products, and now WebSphere application Server V7 Feature Pack for OSGi applications and Java Persistence API (JPA) 2.0 (hereinafter referred to as the OSGi Feature Pack) enables you to use OSGi to improve your applications and services.

One of the key factors in introducing an enterprise-class OSGi application programming model is to ensure that it is a recognized standard across the industry. This is the focus of the OSGi Consortium's Enterprise Expert Group (EEG). The Expert Group is comprised of representatives from Oracle, SAP, VMWare, Redhat, Progress, and IBM. Many vendors provide the team with professional experience to ensure that any standards are widely supported.

Why is enterprise-level OSGi?

Before you introduce the important content of the OSGi Feature Pack, it is worth taking the time to outline the issues it helps to address.

It is worth mentioning that organizations use the capabilities of WebSphere application Server to deploy and manage a large number of applications. These applications typically contain public libraries. In this case, it is normal for the application developer to include the same library in their application. Although this is a safe way for each application to get the expected library, this policy may consume excess memory and make application updates more difficult. Software vendors provide solutions to this problem, but they are targeted at vendors and can lead to increased management time costs.

Sometimes a vendor library is used in an application, and developers are often unable to control the dependencies of those libraries. So the problem arises when the two libraries that an application uses 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 resolve this problem, you typically need to change the code.

In general, these two problems are usually solved in Java EE, so why endure the problems that OSGi can solve?

The OSGi Federation's EEG (Enterprise Expert Group) was established in 2007 and developed the OSGi Feature Pack implementation specification. The objective of the EEG is to view the most commonly used Java EE technologies (for example, JPA, JTA, JNDI, and JMX) and to build a standard method for using application binding techniques deployed to the OSGI framework.

Open Source and OSGi

Two open source projects were launched last year to provide the OSGi Enterprise specification implementation. The Apache Aries Incubator project was launched in September 2009 and has a Blueprint implementation developed by the Apache Geronimo community. The Enterprise Module project (Enterprise Modules Project), which was launched in 2009, was hosted by Eclipse Foundation, which is roughly the same as the Aries project's objectives.

In a short period of time, a number of active groups related to the Apache Aries have been established. Participants include individuals from IBM, Progress, RedHat, Ericsson, SAP, ProSyst, and LinkedIn. Components of JTA, JPA, JNDI, and JMX have been added due to the initial contribution of Blueprint. Examples of how to use these technologies, including Blog sample and Aries Trader applications, are an important part of the project.

Another area that Aries actively developed is the "application" concept, which is one way to group bundle into a single application or Enterprise bundle Archive (EBA).

OSGi Feature Pack

The OSGi Feature Pack provides a consolidated application framework that helps Java EE application developers take advantage of the OSGi Enterprise architecture. This feature pack consolidates the components that are developed by the Apache Aries and the WebSphere application Server Runtime and management. (JPA 2.0 support is also part of the feature pack, but it is not covered in detail in this article.) ）

Specifically, the feature Pack delivers an open community and standards-based implementation of the OSGi Blueprint Container specification, and has the ability to assemble, deploy, and manage applications as an OSGi bundle version collection. The modular design of common WEB applications, simple POJO components, and efficient data access requirements can be addressed using the OSGi application and the JPA 2.0 components of the Feature pack.

Some of the main features of the feature Pack are described below. These features, along with some other features, are described in detail below.

Enterprise Bundle Archives

The bundle that make up the OSGi application are reasonably assembled to form deployable Enterprise bundle Archive or EBA. When you develop a Java EE application, you typically place all module libraries (application content) in the EAR file. Conversely, although application metadata in the EBA describes application content, there is no need to include binary content in the EBA. The EBA can refer only to bundle obtained from the corresponding phase of the bundle library. The most common scenarios may include placing other bundle in the EBA and containing additional content. For example, WEB modules are a major part of an application, so they are naturally in the EBA file, and not application-specific content, such as shared libraries, can be better obtained from the bundle library. Subsequent articles will explore the bundle library and how and when to provide bundle.

WEB Application

As the OSGi Web Container specification defines, the Web content of an OSGi application is only a Web module with other OSGi metadata. The specification defines the metadata required for WEB application bundle. At deployment time, WebSphere application Server converts the WAR file in the EBA to OSGi bundle. The advantage of using the Web module as a bundle deployment is that you can move the library it relies on from the WAR to a centralized, managed, versioned Bundle library that is used in the WebSphere application Server deployment process.

Blueprint

The OSGi Service Platform Enterprise specification introduces a major technology called Blueprint in Java EE, which is the standardization of the Spring Dependency injection model. Although enterprise-class OSGi applications do not require the use of Blueprint, the WebSphere application Server implementation provides many features that make Blueprint a technology that developers are willing to use.

The Blueprint implementation of the OSGI Feature Pack provides the functionality that users expect the Dependency injection (DI) container to have, for example, the ability to build with POJO, and the ability to control those POJO lifecycle. One benefit of Blueprint implementations through the DI container, such as the Spring Framework, is OSGi consolidation. This means that the bundle of the publishing service can later be injected into other components or even other bundle. This dependency injection model also supports unit testing at times other than Java EE or OSGi runtime.

The Blueprint container that is implemented in the OSGi Feature Pack is part of the middleware and is no longer part of the application, which eliminates a troubling problem for the application programmer.

JPA Persistence

OpenJPA is the default persistence provider for WebSphere application Server. The OSGi Feature Pack includes JPA 2.0 support, so developers can use the new JPA 2.0 support in the existing JPA 1.0 support or OSGi applications in WebSphere application Server V7.

In addition to the JPA model described in the OSGi Service Platform Enterprise specification, the feature Pack also includes extended JPA support to provide the Blueprint component with fully hosted JPA, providing a familiar development experience to the application developers who are currently using Java EE's JPA.

This feature pack also includes extensions to Blueprint, so the container can inject the persistence unit and context into the Blueprint bean. The transactional behavior familiar to application developers in EJBs also exists in the OSGi Feature Pack.

Conclusion

Many of the enterprise Web application developers looking for reliable and validated modular technology have shifted to using OSGi. The IBM WebSphere application Server V7 Feature Pack for OSGi applications and Java persistence API (JPA) 2.0 provides an environment that supports the Ja VA EE Developers build applications using the OSGi feature.

User feedback on the OSGi Feature Pack, interest in Apache Aries, and interest in the existing WebSphere application Server show that Java EE developers are happy to use OSGi technology and look forward to the many benefits it offers.