Last week saw London's OSGi Community Event, in conjunction with JAX London. The conference presentations covered a wide range of environments, from Java EE migrations and cloud computing, down to embedded devices and Android.
Enterprise Java on OGSi
There has been a big upswing in using OSGi on the server side in recent years; not only is OSGi being used in the implementation of most Java EE platforms, but the application model is seeping through to run on OSGi runtimes directly. One of the progenitors of this is the release of the Enterprise Specification, which maps some common Java EE services to OSGi services (JTA, JPA, JNDI etc.). This has resulted in commonality between platform providers, with Apache Aries and Eclipse Gemini (used by Eclipse Virgo, formerly Spring DM Server) providing a migration path for those developing Java EE applications. A number of tutorials and presentations were aimed squarely at this audience, such as Ian Robinson's Apache Aries and Glyn Normington's Ecipse Virgo update talks.
There were real-life stories behind migrating towards OSGi runtimes as well, with some advice for those wishing to move. First was Katya Todorova from SAP, who discussed migrating the NetWeaver platform to using OSGi. The initial approach – try to wrap everything and hide OSGi from the higher level – didn't work out, largely because they were trying to crowbar ways of working into the way OSGi is organised. The second attempt was much more successful; use OSGi as it is intended, and then provide OSGi services to interact with the components. (A long held belief, expressed by Peter Kriens, is that OSGi's μServices is the most important part of the specification, more so than modularity, which most focus on.)
Gerd Kachel talked about moving an application from JBoss to OSGi. His observation was that a well structured project (with multiple components) was often easier to migrate to OSGi than the “big ball of mud” components because the work in splitting apart the modules has already been done. However, once you move to OSGi, this migration is enforced at both compile-time and run-time. In Gerd's case, his application was already segregated using MBean services, which lent itself to a simple mapping to OSGi services, using attributes as service properties, methods as methods on the service interface, and dependencies as related services. Both Katya and Gerd summarised their experiences to moving to OSGi with:
- It takes around 1 month for a developer to be proficient with OSGi
- Given an existing module, it can be converted into an OSGi service in around 1 day
- If you fight the OSGi model, you will lose. If you work with it, you will succeed.
- If your application is well structured, then there's an easier mapping to bundles than if it's not well structured.
- If you are using MBeans, then there's a simple mapping strategy to OSGi services.
- If you use classloaders in your application already, migrating to OSGi and fighting its classloaders can be problematic.
- If you use dynamic class loading (class.forName) then these often need to be remediated, but can map to OSGi services.
- If you are using an IOC model already (Guice, Spring etc.) then migrating is usually a lot easier.
At the other end
At the other end of the OSGi spectrum lies the embedded and micro devices. Several presentations focussed on OSGi in industrial or embedded applications, such as Bernhard Dorminger's Experiences with OSGi in Industrial Applications, Dimitar Valtchev's OSGi for Home Automation Systems and Takefumi Yamazaki's i-House experiments on OSGi. These use smaller embedded systems, such as ProSyst's mBS runtime.
The mobile space was covered with a couple of talks on OSGi and Android by Andy Piper, and OSGi ME by Andre Bottaro. These were also focussed on low powered devices, but more formally on the mobile space. Further discussions, prompted also by the Apache Harmony project's modularity, led to informal proposals of having a number of smaller profiles than the J2SE-1.5, where it would be possible to embellish lesser profiles (like Foundation-1.0) with packages from newer runtimes (like java.beans). Since OSGi implicitly doesn't import packages from the java.* namespace, this can't be done easily with Import-Package – but may be possible with the newer OSGi 4.3 Require-Capability header.
Keynotes and Updates
Jim Colson presented The long and winding road, which gave an historical account of the evolution of OSGi, from its inception in 1999 as JSR 8 through to the adoption of OSGi in Eclipse 3.0 and on to its current state today in the enterprise. Whilst those involved with Eclipse and OSGi in those early days found it an interesting walk down memory lane, it shows how far OSGi adoption has come in the last five years. Now, every Java EE vendor bases their runtime on OSGi (well, except for JBoss, who are writing their own OSGi runtime).
Jim also invited Tim Ellison from the Apache Harmony project to present the state of play. With 99% of the Java 5 API complete, and 96% of the Java 6 API complete (and 100% uncertified), the Java runtime is able to run most applications, including Eclipse-based RCP applications and web servers. Importantly, unlike the all-in-one Oracle JDK, the Harmony xDK can be pared down to its minimum of 10Mb class libraries and VM. These are packaged into several groups, known as Harmony Select, Harmony Core, Harmony More and Harmony Out. Only the Harmony Out includes any UI code (and even that is unnecessary for SWT's use) with ever growing sets of dependencies.
James Governor gave an energetic keynote on the significance of OSGi (the general atmosphere of which is reflected in his blog post Java the Unipolar Moment), whilst Peter Kriens gave a talk on the future of OSGi, covering some of the points raised in the previous bundle.update.
Further information on specific talks will be posted subsequently.