We today released (under the EPL and the LGPL) the version 1.0 of Nuxeo Runtime.

Nuxeo Runtime offers a coherent component model for Java applications based on OSGi that makes them runnable on any Java platform with virtually no modifications. Nuxeo Runtime also offers a flexible extension/plugin system for any Java / Java EE application.

We today released (under the EPL and the LGPL) the version 1.0 of Nuxeo Runtime.

The inception

The original idea was born when we were confronted with the problem of deploying several core components of Nuxeo ECM (our ECM platform) to several Java platforms. Our initial goal was to make Nuxeo Core run on JBossAS and Equinox without modification to avoid the burden of maintaining two separate branches of the components.

Working on this issue, we also quickly figured out that nothing like Eclipse extension points was available for Java EE and that this would cause us some troubles since Nuxeo EP needs to be fully extensible, to allow ISV and system integrators to customize and develop new features without doing any code/package change on our certified components. Moreover, we like to think about and design applications as a set of components that extend each other (thanks to the experience of our previous ECM platform).

This approach is a tremendous feature for all business platforms. I believe it’s one of the main reasons of the current Eclipse success.

So we decided to work on a new system that would allow us to deploy our components to any Java platform (Java EE application server and OSGi) without code changes. This new system would also need to provide a flexible extension system allowing component to provide / consume extension points mutually.

We then went to the “Let’s find a name” phase with the usual internal arguments.

Nuxeo Runtime was born…


The requirements for Nuxeo Runtime were pretty simple and quickly defined.

  1. Deploy POJO components to any Java platform (Java EE application servers, Eclipse, etc.)

  2. Offer an extension system usable by any Java component (POJO, EJB, whatever)

  3. Minimize the work required to support new Java platforms (we want to support Glassfish very soon, for example)

  4. Reuse as much as possible from existing standards

Now, the easy part: “how to implement that?”… :-)

OSGi: the Package Model

Because we were familiar with Eclipse RCP, OSGi quickly came to our minds for the package model. After some analysis, we decided to go with it for several reasons:

  1. It is a standard and is gaining momentum in the industry

  2. It provides all the features we required (dependencies, versioning, etc.)

  3. It is simple enough yet powerful and flexible

  4. It is vendor-neutral

Moreover, current activities around OSGi (adoption, extensions, etc.) made us feel confident in its future.

As OSGi is not supported by all Java platforms, we created an adaptation model that allows host adapters to be written. These adapters mimic an OSGi platform using native features of the host platform.

OSGi bundles are, then, seen as native component of the host platform. For example, on JBossAS, your component is seen as a native MBean.

We currently have an adapter for JBossAS, and Eclipse is supported without adapters since it’s an OSGi platform.

Extension System: Everything is a Plugin!

Another very important feature we required was an easy way to make our components pluggable. We wanted to make it easy to write plugins for our components. We like the approach of a set of components extending themselves mutually to form the final application. Furthermore, we strongly believe that easy extensibility is the key factor for a platform’s success.

We started to work on an extension system, inspired by Eclipse extension points and Zope’s component architecture.

So Nuxeo Runtime provides a flexible plugin system based on extension points that allow any component to declare extension points that others can use to extend/configure. Nuxeo Runtime manages the extensions tree and takes care of bindings. Any Java and Java EE component can use this system to become pluggable with almost no change.

The final model is close to OSGi Declarative Services. We plan to fully support this in the next release. We’re also thinking of adding support for Eclipse’s native extension system.

Extensible Java and Java EE applications and Composition

Thanks to Nuxeo Runtime, any Java and Java EE component can offer extension points to become extensible.

This allows an approach based on true composition to build your applications. Take the components you need, let them plug and extend themselves. Then write one (or more) “customization” component and make it bind them all.

I really believe this opens an amazing way to create componentized Java EE applications.

Just forget the pain of specific builds, enjoy composition!

Example: Nuxeo Transformation Service

For a real-life example, let’s take Nuxeo Transforms, our document transformation service for Nuxeo EP.

First, the NXTransform package defines the transformation infrastructure (transformer, transform chain, etc.). It does not implement any real transformation code.

NXTransform, by itself, will never transform your MS-Word document into a nice PDF. Neither will it extract plain text from a PDF. It only defines a couple of Session Beans / Message-Driven Beans that can be called to ask for a transformation, and offers a set of extension points (to plug real transformers and to define transform chains). NXTransform.sar will never change, whatever transformation chain and transformers it needs to offer.

Now, take a look at NXTransformPlugins, the default set of transformers we provide in the platform. You can find in this package the transformers and the transformation code. You can see the JOOConverter transformer as well as the PDFBox transformer. This package just plugs the embedded converters to NXTransform’s extension points to register its transformers.

Want to add transformation capability? Just write a new component to implement the transformation and plug it into the transformation service.
Need a new transform chain? Just add a bundle descriptor that will configure the new transform chain.

Have a look here for an Adobe PDFGenerator integration: Nuxeo Adobe PDFGenerator Transformer.

Before runtime, Nuxeo Transforms has no need to know anything about what transformers will be available. You only need to build it once…

To give some metric, the implementation of the transformer “PDF to plain text”, based on PDFBox, took 30 minutes. Tests included…

Wanna Play?

Just head to Nuxeo Runtime Page, download it, read the documentation and start coding! :-)

Currently JBossAS and Eclipse are supported (in fact, it should run natively on any OSGi platform but it’s untested). We would love to give help if somebody volunteers to support more platforms (e.g.: Glassfish, Geronimo, JOnAS, Websphere, Weblogic, other OSGi platforms, etc.).

If you need support or simply want to discuss just join the mailing-list.

One more thing… If you like it don’t forget to send a postcard to Bogdan Stefanescu (c/o Nuxeo, 18 rue Soleilet, 75020 Paris, France) that made it possible! ;-)

Stay Tuned!

(Post originally written by Eric Barroca on the old Nuxeo blogs.)