Apache Aries: Marrying OSGi with Java EE

DZone recently met up with IBM's Ian Robinson to discuss Apache Aries, a project which aims to deliver a set of pluggable Java components enabling an enterprise OSGi application programming model. In this interview, recorded at IBM Impact 2010, Ian talks about how Apache Aries relates to the OSGi framework, and its support for numerous Java EE specs, including the Java Persistence API (JPA), the Java Transaction API (JTA), and Java Management Extensions (JMX). He also provides a roadmap for the project, which is currently in the Apache incubator. Ian is a Distinguished Engineer at IBM working out of the Hursley Lab in the UK. 

DZone:  Can you tell us a little about your role at IBM?

Ian: My primary interest at the moment is around OSGI technologies and how they can be used in the application programming module in the WebSphere application Server and indeed, beyond the WebSphere application Server as well.

How we can encourage the use of OSGI more globally, across the Java platform and in particular, in the Enterprise Java Space, in the OSGI Enterprise Expert Group and latterly to help set up the Apache Aries Project which focuses on building enterprise OSGI technologies and in particular enterprise OSGI technologies that affect application components.

Aries is about components that can be integrated into enterprise runtime environments but components that are primarily application component facing, like the Blueprint Container.

DZone:  How does Aries differ from the OSGI framework?

Ian:  OSGI is described across a number of different specifications: There is an OSGI core specification and then there are implementations of the OSGI core such as Eclipse Equinox, Apache Felix, Knopflerfish and others.

There's an OSGI compendium specification and generally speaking, most of the compendium services that are defined in the compendium spec are also implemented by Felix and Equinox.

Then there is an enterprise OSGI specification and that's where Apache Aries comes in. So that talks about how Java Enterprise technologies are, if you like, married with OSGI. So technologies like JTA, JNDI, JPA, JMX and so on.

DZone:  What provisions does Aries provide for the JPA spec?

Ian:  In an enterprise JAR and certainly in the enterprise OSGI specification, there is a definition of how persistence should be managed in an enterprise JAR environment. And that definition is to integrate JPA into an enterprise JAR .

So there are essentially, three different aspects of JPA provision in OSGI.

One aspect is the JPA provider.

The second aspect is the application and it's definition of it's access to the database through a JPA persistence XML and the entities that it provides to interact with‑‑to actually represent the data in object form.

Then there is the container integration which can optionally manage how JPA artifacts like entity managers and entity manager factories are provided, are injected into an application.

So JPA has two different usage modules. There is an application usage model where the application essentially finds a JPA provider, interacts with it to create an entity manager factory and then uses the entity manager factory.

In that model, the application is managing the use of the entity manager and it's association with any transaction context, for example.

In a container managed environment, the container that the application component runs it, for example, a Blueprint Container can work with and discover JPA providers and inject entity managers from those JPA providers into an application, in order to process it's persistence units.

And in that model, in the managed model, the container not only manages the life cycle of the entity manager, but it also manages the relationship of the entity manager's persistence context with any transaction that the application happens to be running under.

So from an open source and Aries perspective, there are actually two open source projects that are relevant here. There's Apache OpenJPA, which is the JPA provider. Then within Apache Aries, we have a JPA container component which is part of our Blueprint Container.

So the Blueprint Container is extended with the JPA container so that the Blueprint Components that run inside the Blueprint Container can have their JPA context managed for them by the Blueprint Container. Which is actually, quite an advanced extension to the Blueprint specification that we add as value in the Aries Blueprint implementation.

DZone:  How does Aries'  JTA and JMX integration work?

Ian:  Arie's JTA integration uses the transaction manager in Geronimo. So Geronimo has an implementation of JTA. What we have for the Aries JTA integration is the registration of JTA services in the OSGI service registry.

Aries interacts with Geronimo, gets the transaction manager, puts it into the OSGI service registry, and makes it available for applications. And like JPA, that we were talking about earlier on, we also have an integration of transactions into the Blueprint container as well.

So that the Blueprint Container can understand transaction configuration for Blueprint components, just like the EJB container can, in fact. And can run Blueprint components under JTA global transactions as well.

So that's the transaction side of things. We have JMX integration as well. There are about eight services defined in the OSGI JMX specification.

In the JMX implementation in Apache Aries, we implement MBeans services so that you can use JMX to query aspects of a running OSGI framework. "What is the framework? What applications are running inside that framework? What services do they provide?" All from a remote JMX client. So that's JMX integration.

We have JNDI integration as well. For example, an OSGI service registered in the service registry can also be made available for discovery through JNDI by a JNDI client. Which eases the integration in an enterprise application between components that have been derived from the Java EE side of the universe. Which doesn't know anything about the OSGI, on the one hand. And services which are registered by OSGI‑aware components on the other hand.

So there's a nice integration between essentially loosely coupled components. That's essentially the summary of some of the core aspects.

One of the other things that I think Apache Aries has a very forward‑looking approach to is the assembly and deployment of multi‑bundled applications. So, in that respect, Apache Aries is innovating because we're ahead of any standardization effort in the OSGI alliance at the moment.

But, our objective with doing that is to gain experience and ensure that we have developed an efficient and usable and practical model for deploying multi‑bundled applications in order to inform our work in the OSGI alliance.

DZone:  Can you give us a preview of what we can expect to see in the next three to six months with the Aries project?

Ian:  We're just in the process at the moment of voting on our first release, so that will be about seven months after creating the beta project. I'm hoping, by the end of this week or next week, we'll have our first release out there. And our first release covers things like the application assembly model, JMX, J2EE Blueprint Container, the things I've spoken about already. Beyond that, we've had interest expressed by members of the community to extend the work of the Enterprise Expert Group at the moment with development of some more forward‑looking things, and indeed some things that we are interested in standardizing through the Enterprise Expert Group. Things like provision of asynchronous services, perhaps message‑driven BluePrint endpoints, for example.

But I think, in terms of the work that we set out to do, to build initial implementations of the Enterprise Expert Group specifications, once we've got our first release out there and we've demonstrated that we have a vibrant community, then I think, within the next three or four months, I hope and expect to see Apache Aries actually graduate from incubation.

DZone: Having worked really closely with the OSGi Enterprise Expert Group, and now on Aries, in your opinion, what direction does Java need to evolve to become a truly modular platform?

Ian:  Where does Java need to evolve? It's interesting, looking at the different ways that Java could evolve. I would like to see Java evolve so that it recognizes the 10 years of experience, probably 11 years of experience, that we have in the OSGi Alliance of building modular systems and actually adopt OSGi as THE module system for Java.