Last week saw the first OSGi DevCon London, held in conjunction with JAX London in Hammersmith's Novotel.
The keynote by Kirk Knoernschild available beforehand as a preview, packed the room to standing room only. Kirk's presentation (slides) did not focus on OSGi directly, but rather on complexity of software and what projections the future holds. Analysis of the past growth of source code suggests that the number of lines of code ever written doubles every seven years; to put it another way, by 2017, the world will have as much new code again as ever existed up until 2010.
As software grows, the complexity of the system increases. Furthermore, most code is read many more times than it is written; so to address complexity, a system must be arranged in an understandable way. Kirk's main takeaway was that there is a continuum of modularity in the Java space at the moment; at the least granular, services, and at the most granular, packages and classes. Modularity fits neatly in between these two groups; it is a way of aggregating packages into a more modular unit and then allowing multiple modules to work together to provide an end-level service. Kirk's example was of a number of different combinations of services that may be required (each as their own module) and then composed into a higher level service for an end user application.
Peter Kriens gave an extended presentation and tutorial on Advanced OGSi topics; the discussion mostly focussed on service-oriented design. In other words, once you have gone from understanding the modularisation aspects of OSGi, and followed the next step to OSGi services, then the logical conclusion is to focus your system by understanding its services and their interrelationships.
He presented an example of how OSGi services can be exposed as JMX beans. The goal was to think of the service(s) that would be involved, and how they would be published (and consumed) by listeners. Interestingly, when discussing the designs of the LogReaderService, Peter felt that using the whiteboard pattern was probably something that was a mistake, when it would have been much simpler to use a service dependency such that a log message could be broadcast to all listener services which met a particular interface. Perhaps the rise of Declarative Services (and the Blueprint model) have made it so easy to set up and wire services together that registering services is the right way forward for anything that wants to receive feedback from another module.
OSGi tooling made a couple of appearances during the day; first, Chris Aniszczyk gave a few demonstrations of the tooling built-in to PDE (such as the baseline API checking), and later in the day, a panel discussed the various tooling options available to OSGi developers. Bnd, used by the maven-bundle-plugin, was mentioned a number of times as a way of building OSGi bundles; and SpringSource's bundlor was brought up as well. With the approval of the recent Eclipse Virgo project, focussing on the build train is something which is likely to occur for more developers. Meanwhile, the Maven Tycho project (which allows bundles to be built Manifest-first or POM-first) has been making strides, and is being used by two Eclipse projects at the moment. Bringing up the rear was an Ant-Ivy based Sigil, which has recently become self-hosting. One outcome of the talks was that binary Eclipse OSGi bundles will now have a Maven SCM URL which will permit them to be checked out from source as required.
Shaun Smith from Oracle gave a presentation on OSGi and the Java Persistence API. The upcoming OSGi 4.2 enterprise specs include a JPA service, which allows objects to be persisted to a database in an OSGi environment. In addition, programs written to the (non-OSGi) JPA will have a (static) factory that will obtain the services in an OSGi fashion if running in an appropriate environment. And whilst the JPA reference implementation is EclipseLink, the OSGi JPA Service reference implementation will be developed by the same team.
Stepping in at the last minute for a presenter who wasn't able to make it, Robert Dunne of Paremus gave an impromptu demonstration of POSH and Nimble. The former is a shell which allows you to start, list, and configure bundles in a portable way, whilst the Nimble resolver allows you to acquire applications on demand by loading them (and their dependencies) automatically. (David Savage had earlier tweeted an install command which brought an entire Spring-based web application down into a shell using 86 characters.)
Cloud computing using OSGi made a couple of appearances; firstly using Apache Felix Karaf to create and deploy instances on Amazon EC2, and secondly using Pax Exam to test OSGi applications on the cloud. There's a OSGi Cloud Computing workshop during EclipseCon/OSGi DevCon which will be discussing issues and lessons learned whilst using OSGi in a grid mode.
There were a couple of presentations on the newer OSGi features, like the Spring-inspired Blueprint Service as well as what to expect with the upcoming OSGi 4.2 Enterprise Expert Group, which will include database access, web applications, JMX control of bundles and safe ways of accessing JDNI, JDBC and Transactions in a ClassLoader safe way.
With the success of OSGi DevCon in London, the OSGi DevCon in Santa Clara should be even better. The publication of the OSGi Enterprise Expert Group is expected during OSGi DevCon, which will bring the above-mentioned JPA, as well as Web Containers (which will allow OSGi engines to host web applications) and other features such as JMX and database access. You can sign up for EclipseCon/OSGi DevCon to learn more.
