The disruptive transition in the Enterprise Java world from the old, monolithic thinking to the new way of thinking modular is not a smooth one though, and takes time. I am writing this blog to highlight the developments in Enterprise Java and especially OSGi juggernaut that is on its way.
For Enterprise developers, the major news is that the first Enterprise OSGi specification is reaching finalization. Although the OSGi Enterprise Expert Group (EEG) website doesn’t give much details about the specs, you can find draft v4 on the Apache Aries, more on that project later. This draft specification also contains interesting annotations from reviewers by the way, recommended to do a quick scan of this document.
The new specification defines how several JEE specs should work in a dynamic OSGi environment. The JEE specs that are chosen are for example the JPA spec (Java Persistence API), JMX (Java Management Extensions), JDBC (Java Database Connectivity), the JTA (Java Transaction API) and JNDI (Java Naming and Directory Interface). Although the OSGi Enterprise specification doesn’t cover all of the JEE APIs, it does cover the most important ones, more than enough for most Enterprise applications.
On top of the OSGi-ified JEE APIs, there are some new concepts introduced in the Enterprise OSGi specs. The most important one is the standardization of .wab files, which are OSGi versions of .war files. You need to add some descriptors, and then you can deploy those .wab files like regular OSGi bundles, including life cycle and dependency management. Regular .war files are also supported, they need to be transformed transparently and on the fly by the OSGi container to .wab files. Last year there were several vendors already experimenting with server side bundles, and using different APIs and even different file extensions (like .par and regular .jar), it’s great to see a standard here.
Another new feature is remote OSGi, which enables you to use exported services from an OSGi bundle in a remote Virtual Machine. This gives new possibilities for distributed solutions, for example to solve scalability or redundancy issues. As a bundle developer you already need to develop with the possibility in mind of not available services, in effect a poor mans ‘design by failure’ approach, which works great in a distributed environment.
To facilitate, experiment and learn from the new specs and its uses, two projects are started: Apache Aries and Eclipse Gemini. Both projects have approximately the same goal: provide implementations of the Enterprise OSGi specifications, create examples and create a community. Apache Aries is in incubation and sponsored by IBM and SAP, Eclipse Gemini is sponsored by Oracle and SpringSource.
To top it all of, SpringSource is in the process of donating its open source OSGi container to Eclipse, and renamed it from SpringSource DM to Eclipse Virgo. This container serves as the reference implementation for the Enterprise OSGi specification. This also means that the license is moved from the restrictive GPL to a more open EPL license.
Almost all Enterprise container vendors like JBoss, Glassfish, Oracle and IBM were already building the application server on top of OSGi, but didn’t expose OSGi to the enterprise application developer, or did expose it, but with proprietary APIs, therefore locking in the developer and hindering further adoption in the larger Java EE space. With the new Enterprise OSGi specification, developers can use the power of OSGi, without being locked in, which is great.
So all new specifications to get rid of vendor lock in, various implementations of these standards, open and closed source, community to work with, is this all good news then? No, sadly it’s not.
Adoption from ‘old’ Java EE users is slow. In part because of the technical challenge: Java has been monolithic of nature from the very beginning, and adding modularization to a very stable, mature platform is hard. It will take time and determination to solve all the problems while in the mean time keeping an upgrade path for JEE users.
Another problem is that the Java industry has been taught for 15 years to think in monolithic architectures. Thinking in components and services architectures is a revolutionary, disruptive trend, which will take time and effort for those affected to learn and understand.
And the last issue is of more political nature: There is still tension between the JCP and the OSGi consortium. Both are defining standards, and are not necessarily in agreement of each others approach. With the takeover of Sun by Oracle, this might change. There is a real risk that new JEE specifications are defined without taking OSGi into account, and that would create the possibility of forking the Enterprise standards.
But even with the above remarks it’s clear that modularization is on the brink of a breakthrough in Java Enterprise Development. Especially for architects, this means thinking in complete new ways about their work and responsibilities.
Filed under: SDLC
