Component model overview

In this section:

Nuxeo Bundles

Inside Nuxeo EP, software parts are packaged as Bundles.

A Nuxeo Bundle is a jar archive containing:

• an OSGI-based MANIFEST file,
• Java classes,
• XML Components,
• Resources,
• a deployment descriptor.

The MANIFEST file is used to:

• define an id for the bundle,
• define the dependencies of the bundles (ie: other bundles that should be present for this bundle to run),
• list XML components that are part of the bundle.

Here is an example of a MANIFEST file:

Here we can see that:

• Bundle is named org.nuxeo.ecm.core.convert.
• Bundle depends on 2 other bundles: core.api and convert.api.
• Bundle contains one XML component: convert-service-framework.xml.

Components and Services

The XML components are XML files, usually placed in the OSGI-INF directory, that are used to declare configuration to Nuxeo Runtime.

Each XML component has a unique id and can:

• declare requirement on other components,
• declare a JAVA component implementation,
• contain XML contribution,
• declare a Java contribution.

A Java Component is a simple Java class that is declared as component via an XML file.

Components usually derive from a base class provided by Nuxeo Runtime and will be available as a singleton via a simple Nuxeo Runtime call:

Usually, components are not used directly, they are used via a service interface. For that, the XML components can declare which Service Interfaces are provided by a given component. The component can directly implement the service interface or can delegate service interface implementation to an other class. Once declared the Service will be available via a simple Nuxeo Runtime call:

Extension Points

One of the corner stone of the Nuxeo Platform is to provide components and services that can easily be configured or extended.
For that, we use the Extension Point system from Nuxeo Runtime that is inspired from Equinox (Eclipse platform).

This extension point system allows you to:

• configure the behavior of components (= contribute XML configuration),
• extend the behavior of components (= contribute Java code or scripting).

Basically, inside Nuxeo EP, the pattern is always the same:

• Services are provided by Components,
• Components expose Extension Points.

The same extension point system is used all over the platform:

• inside Nuxeo Runtime itself,
• inside Nuxeo Core (configure and extend Document storage),
• inside Nuxeo Service layer (configure and extend ECM services),
• inside UI layer (assemble building blocks, contribute new buttons or views, configure navigation, ...).

Each Java Component can declare one or several extension points.

These Extension Points can be used:

• to provide configuration,
• to provide additionnal code (i.e. : plugin system).

So most Nuxeo Services are configurable and pluggable via the underlying component.

Declare an extension point

Extension Points are declared via the XML Component that declares the Java Component.

Here is a simple example:

What we can read in this XML component is:

• the declaration of a Java Component (via the component tag) with a unique id (into the name attribute),
• this component declares a new service (via the implementation tag)
• the declaration of the ConvertService interface (used to also fetch it) implemented by ConvertServiceImpl java implementation,
• this service expose 2 extension points:
  • one to contribute configuration,
  • one to contribute java code (new converter plugins).

Each extension point have his own xml structure descriptor, to specify the xml fragment is waiting for into this extension point:

• org.nuxeo.ecm.core.convert.extension.ConverterDescriptor
• org.nuxeo.ecm.core.convert.extension.GlobalConfigDescriptor

This description is define directly into these class by annotations. Nuxeo Runtime instanced descriptors and deliver it to the service each time a new contribution of these extension points is detected.

*Each Nuxeo extension points use this pattern to declare configuration possibilities, service integration, behavior extension, etc...*
You understand this pattern, you will understand all extension points into Nuxeo. And you can use this infrastructure to declare your own business services.

Contribute to an Extension Point

XML component can also be used to contribute to extension points.

For that, the XML component needs:

• to be referenced in a MANIFEST bundle,
• to specify a target extension point,
• to provide the XML content expected by the target extension point.

Expected XML syntax is defined by the XMap object referenced in the extension point declaration.

Here is an exemple contribution to an extension point:

Extension Points everywhere

Nuxeo Platform uses extension Points extensively, to let you extend and configure most of the features provided by the platform.

You can find all extension Points available in the DM distribution here.

Packaging and deployment

The layered architecture impacts the way we package features in Nuxeo EP.

In order to keep as much deployment options as possible and let you choose what you deploy and where, each feature (workflow, relations, conversions, preview ...) is packaged in several separated bundles.

Typically, this means that each feature will possibly be composed of:

• an API Bundle that contains all interfaces and remotable objects needed to access the provided services;
• a Core Bundle that contains the POJO implementation for the components and services;
• a Facade Bundle that provides the JEE bindings for the services (JTA, Remoting, JAAS ...);
• a Core Contrib Bundle that contains all the direct contributions to the Repository (Document types, listeners, security policies ...);
• client bundles.

All the bundles providing the different layers of the same feature are usually associated to the same Maven artifact group and share the same parent POM file.
This is basically a bundle group for a given feature.