Enterprise Specifications

I am currently in Southampton where we are finalizing the specifications for the 4.2 Enterprise release in an EEG meeting. It looks like we will be able to actually release this work during EclipseCon in Santa Clara, March 22-26. It is a sizable body of work, again. The last 8 weeks have been spent editing, editing, editing, and editing for 10-12 hours a day. Yesterday we did an (almost) final review so a few more days and then I am going to take some time off, trying to get my shoulder muscles back in a state where they can move again.

So what is likely going to be in that specification? Though I cannot give any hard guarantees, the following paragraphs give an overview of the intended content.

We had a few errata in Blueprint and some other specs, but all very minor. So most new specifications for the Enterprise release are about Java EE APIs and make them usable in OSGi. These specifications work very hard to preserve the semantics of the Java EE APIs but map them to OSGi services and defines life cycle issues. At the same time, we're trying very hard to be as compatible as possible with existing JEE code.

The hardest problem being that Java has nothing like a service registry; unfortunately most Java EE specs use the factory pattern with class loading tricks in slightly different ways. Working on the OSGi specifications has taught me a lot of things I never wanted to know about these Java EE specs.

The most "Java EEish" spec in this aspect is I guess JNDI. JNDI is a registry that has become part of Java SE. It is a surprisingly complex design for a rather simple problem (registry). This was the first design ever where I ran into a factory of factories, and JNDI even has two: InitialContextFactoryBuilder and ObjectFactoryBuilder. JNDI had to be supported because a lot of Java EE code is using JNDI to link to other subsystems and get configuration information. Key problem was that people tend to use new InitialContext(). The constructor of the InitialContext class then has to work surprisingly hard to find some Context implementation that was intended by the caller or the container.

The Initial Context design is a variation of a static factory pattern, something that does not work well with OSGi because of the dynamic life cycle. Static factories ignore dependencies, putting a huge burden on the deployer to get the ordering right. We did map the different factories to OSGi services and allow the usage of the new InitialContext(). If JNDI is really needed then depending on the JNDI Context Manager service will keep deployments simple because dependencies are managed.

For JDBC we created a Data Source Factory service that can be registered by database drivers. This service can then provide a surprisingly large number of Data Source variations: Data Source, Pooled Connection, XA Data Source, etc.

The OSGi JPA specification leverages this Data Source Factory service. JPA has become a very popular specification very quickly. The core access point for this specification the Entity Manager Factory

Transactions have been added by registering the Java Transaction Architecture (JTA) interfaces as services and allowing them to be used by applications and containers. The enlistment strategy of the resources is up to the container or by the applications themselves.

The WAR specification introduces WABs: Web Application Bundles. These bundles have the same purpose as WARs: serving web content. Part of the specification is a URL Handler that can install a WAR; the URL Handler will convert a WAR to a WAB by adding the appropriate manifest headers for OSGi. This will likely be a very popular way to get started with OSGi for developers that have a lot of experience with WARs.

This release will also support JMX (Java Management Extension). We've defined a number of MBeans that allow management of the OSGi framework and a number of the key services.

Last but definitely not least. My favorite specification is Remote Service Admin. In the previous release we specified a number of properties that enable the distribution of OSGi services. Services are very well suited to distribution; not because they were designed for distribution, but because dynamics are an intrinsic part of their design. The Remote Service Admin specification uses the distribution properties and allows a topology manager (another bundle) to manage a distributed topology of services. Topology managers can be simple like managing a number of key services in a cluster or implement fail-over or load balancing. Included in the specification is an abstraction to discover services from many different sources. This specification is leveraging OSGi to the hilt and by doing so it enables applications to be largely unaware of their distribution. This specification might be the "killer spec" for OSGi.

A key concept in OSGi remote services is configuration types. A configuration type specifies how to configure the remoting of a service to create a communications endpoint. For example, you could have a configuration type for web services. In the coming release, you will likely find an SCA configuration type. SCA being the Service Component Architecture, a specification at OASIS. SCA is a comprehensive specification to create distributed applications in many different technology. The SCA configuration type allows OSGi frameworks to play a role in SCA.

So lots of new stuff! I really hope to see a lot of people at EclipseCon when this specification will be introduced.

Peter Kriens