18th of November, 2009
I recently came across a blog post about an Apache project called Aries, currently in incubator status. You can check out the details here. It looks like enterprise developers are in for a real treat: the missing secret sauce that allows enterprise application developers to harness the goodness of OSGi.
Aries will offer an enterprise OSGi application programming model that enables applications to leverage Java EE and other enterprise technologies and to benefit from the modularity, dynamism and versioning capabilities of OSGi.
This is fantastic news! OSGi is quite an amazing technology, and while OSGi is mature it lacks support in the enterprise due to a lack of application server support. The support for enterprise OSGi looks to be increasing, especially when you see the organizations represented in the committer list: LinkedIn, IBM, SAP, and so forth. One of the remaining issues affecting the adoption rate of OSGi is the inability to hot-deploy an OSGi bundle in your favourite app server.
A significant feature of Aries will be a container for OSGi Blueprint components - an implementation of the new OSGi v4.2 Blueprint component model that defines a standard dependency injection mechanism for Java components, which is derived from the Spring framework and extended for OSGi to declaratively register component interfaces as services in the OSGi service registry.
It looks like the functionality provided by Spring DM (Dynamic Modules) is part of the official spec now. This is nice, because one of the challenges with plain old OSGi is managing the availability and injection of service references. The interesting thing is that this functionality will be offered by the container in a standard way — for portability between runtimes. Excellent.
Message-driven Blueprint components.
This is very interesting, because one of the challenges with OSGi is the dynamic nature of services. Dealing with dynamic services synchronously with no guarantee a bundle is running can be challenging. Even with Spring as a proxy to the real OSGi service, there’s always the dilemma of how long is a reasonable amount of time to wait for an unavailable service. For operations that aren’t critical, handling them asynchronously is the way to go; fire, forget, call me back later.
Federation of lookup mechanisms between local JNDI and the OSGi service registry.
Either I’m misinterpreting what they mean by federation, or it sounds like they’re building a layer of abstraction on top of the OSGi service registry and the JNDI registry. What I’m not quite clear on is if they’re providing a new API, or if OSGi lookups will be done via the JNDI API. I’m hoping it’s the latter.
The Geronimo blueprint sandbox .. contains an implementation of the OSGi Blueprint container which will be moved to Aries ..
The OSGi Blueprint container being moved from Geronimo to Aries is significant in the fact that, theoretically, Aries can be run on any Java EE app server. This would be huge and take away a major roadblock to OSGi adoption for most people. Simply put, deploying OSGi applications to productive is either too complicated (if you want to embed and make use of Java EE features), or too limiting (running natively and losing out on EE + container managed everything).