Friday, September 25, 2009

Enterprise Expert Group

I am currently sitting in the Kempinski hotel on the Munich airport waiting for my flight home. Very tired but even more satisfied. In the last few weeks we have been struggling in the Enterprise Expert Group about core issues. The last meeting, 8 weeks ago in Dublin, was actually quite heated and a bit depressive, but this meeting turned out highly productive!

The key issue was the focus of the work we're doing in the JEE APIs. Is the focus to make JEE applications run on OSGi unchanged or do we provide a recommended way of using those APIs on OSGi? The problem is that JEE has many built-in assumptions that do not hold in an OSGi world. JEE containers have a application-thread association, a much simpler class loading model with most dependencies contained in the application, and there is no visible life cycle. Especially the creation of providers through static factories is very cumbersome in OSGi.

A good example to highlight these problems is for example the static nature of JNDI. An application performs a new InitialContext() call and expects that a proper context is returned. The environment can influence the returned context via singleton that can only be set once.

The proposal on the table is that an OSGi bundle sets this singleton and then, when called, would get a Context service from the service registry. The real proposal is a bit more complicated, but this is the principle. At first sight, this sound like a viable solution. It allows bundles deliver new Context providers, and it is compatible with normal JSE/JEE code that uses new InitialContext().

Unfortunately, this static factory pattern ignores the dynamic life cycle of bundles. It raises the following concerns:
  • Ordering - When the application does new InitialContext(), is the singleton already set? Is the desired provider already registered?
  • Ownership - On whom's behalf is the Context provider service checked out? It is notoriously hard to determine the caller's bundle context from the stack, if at all possible in a reliable way.
  • Staleness - What happens when the Context provider is stopped? The InitialContext then has a reference to a stale object.
These solutions are solvable if one lowers the bar that we held so far. You can order bundles with start-level ordering and in most cases the stale reference will not crash the system.

The problem we now faced in the last weeks was that many, coming from the JEE world, felt that the portability aspect was more important than the issues raised by this solution. Others felt that though lowering the bar in a product might be acceptable, an OSGi specification should show the right way to do it in OSGi. They felt that expecting that a JSE/JEE application always needed some porting to make it work on OSGi. There seems to be no free lunch for modularity.

During this meeting it was clear that we reached a consensus. The design was changed to be service based. In principle, a bundle would set the singleton and then register a service, allowing bundles to properly synchronized with this singleton. It is then up to containers to implement the correct life cycle handling for OSGi challenged applications. Additionally, the spec will recommend not to use the JEE/JSE static factories but will contain a section that outlines the consequences when they are used, given a proper warning to the deployer.

It was kind of invigorating to see how we have been able to come to a consensus even though the debate was sometimes heated and messy. If we can continue in this spirit, then I think we will see some very interesting specifications coming out of this group in the coming years.

Peter Kriens


  1. You wrote: "If we can continue in this spirit, then I think we will see some very interesting specifications coming out of this group in the coming years."

    Years !?

    How long do you think developers would need to wait in order to replace EAR deployment solution with a OSGi-based packaging solution ?

    Well, unfortunately, there are more and more JavaEE servers supporting OSGi out there, but so far the deployment of server-side apps on top of OSGi has not yet replaced EAR-based deployment.
    It looks like the plate is on the table, and it smells good, there is little average developers could do to eat it...

  2. Well, 4.2 contains the first glimpses with remote services and Blueprint and some serious work will be delivered in the spring next year. However, the EEG is very ambitious and is already eyeing more work.

    I agree that for application developers there could be more, but that is a hard nut to crack. There are two issues. First, their life has been simplified by lots of good tools and there is often some resistance against changes. Either issue takes time to resolve, but we're working hard on both.

    Peter Kriens

  3. Tremendous news Peter! I am only sorry I missed the resulting consensus, and only got to experience all the disagreement and arguing instead. Great stuff.