The idea behind OSGi (formally standing for Open Services Gateway initiative, now simply OSGi) is a framework for...
creating modular Java components which can be installed and managed remotely as part of a larger service. The idea appears to have started with a Java Community Process proposal JSR 8 in 1999, but it quickly got turned over to the independent non-profit OSGi Alliance. Supported by numerous industry leaders, the OSGi Alliance maintains the specifications and manages the creation of new ones. OSGi has found applications in numerous areas, starting with embedded network devices and now extending to enterprise scale.
The OSGi Service Platform specification Release 4 (OSGi R4) is the present specification. The top level entity manipulated by the OSGi framework is the "bundle." A bundle corresponds to a Java "jar" package containing Java classes and other resources, including OSGi specific information. The framework can download and install a bundle, manage its life cycle, and remove it as necessary. Inside a bundle, OSGi recognizes one or more "services" defined by a Java interface plus accompanying properties. A service registry keeps track of all loaded service code and provides access to the services. OSGi can be used to completely handle all parts of an application or it can be used only for selected services.
In addition to the Service Platform specification, the OSGi Alliance has released a number of specifications for specific application areas to make it easier for developers to get started. I think the following will be of greatest interest to Web services developers:
- HTTP Service defines services supporting the Java servlet API.
- Log Service provides for general purpose logging functions.
- User Admin Service defines a service for user authentication.
- XML Parser Service defines how standard XML parser implementations can be made available as an OSGi service.
OSGi and the Java Community Process
Sun started the Java Community Process in 1998 to provide a formal setting for collections of interested parties to evaluate proposed improvements to the language and specifications. Formally numbered Java Specification Requests (JSRs) go through an extended process which may or may not result in a final specification. The quick conversion of JSR 8 into OSGi in less than two months is rather anomalous, as most JSRs live for years. Since JSR 8, many developers have considered the problem of creating and managing collections of Java code larger than a single class but smaller than an application, and many JSRs overlap to some degree with OSGi functions.
The official position of Sun and the Java Community Process (JCP) on OSGI seems to me to be rather confusing. The JCP published JSR 232, "Mobile Operational Management," based on the OSGi "Service Platform" specification but limited it to application in the J2ME environment. For Java SE (Standard Edition) we have JSR 291, which builds on JSR 232 and OSGi. Apparently the real development work has been done by the OSGi Alliance, which has many of the same people and companies as the related JSR group. Some announcements have said that the release of Java 7 sometime in 2010 will contain direct support for the OSGi framework but I dont see it in the early drafts. JSR 294, titled "Improved Modularity Support in the Java Programming Language," is supposedly under active development as a candidate for inclusion in Java 7.
In any case, OSGi has been adopted with increasing enthusiasm in a number of significant products. One of the most widespread is the Eclipse IDE (Integrated Development Environment) which uses the Equinox OSGi implementation. The Glassfish v3 preview release includes the Felix OSGi framework, and Apache CXF has implemented Distributed OSGi.
Eclipse and the Equinox OSGi Implementation
Starting with version 3.0 in 2004, the popular open source Eclipse IDE uses OSGi to organize the plug-ins which provide the runtime functionality. When you start Eclipse it loads plug-ins according to their OSGi descriptions. The high degree of independence between plug-ins provided by the OSGi framework makes it feasible for many different versions of Eclipse for different languages to be supported by the same framework and for independent update of components. The specific implementation is called Equinox which is also available as an independent download. The Equinox site has information on adding OSGi capability to a server so that OSGi bundles can handle HTTP requests.
The Apache Felix OSGi Implementations
Felix is one of several active OSGi related projects hosted by the Apache Software Foundation. Felix is intended to be incorporated into other projects for management of plug-in architecture in addition to standalone capabilities. The "Jetty" HTTP server is available to provide Http Service functionality. The current Glassfish v3 preview comes with Felix as the OSGi framework.
Distributed OSGi and the Apache CXF Project
OSGi has a proposed extension for the next release called "Distributed OSGi." One purpose of this extension is to provide web service style access from a bundle running on one computer to services managed as OSGi bundles on a separate server. The Apache CXF open source Web services framework, which supports a number of Web services standard APIs, has implemented Distributed OSGi as a sub-project.
There have been many different efforts to improve Java's facility for handling groups of Java classes as components which can be flexibly managed and dynamically connected to form complete applications. The OSGi approach, building on initial sucess with embedded devices followed by larger scale sucess with the Eclipse IDE, appears to have become the dominant approach with the greatest developer mind-share.