As we've seen in stage 1 of this Tour de Nuxeo, Nuxeo EP is a platform that implements all the major services that are expected nowadays to manage content at an enterprise scale.
In today's stage, we're going to dive deeper into the technology that powers the Nuxeo platform, and show how its architecture was carefully chosen to answer the common needs of our customers and user community.
However, since Thierry Delprat, our fearless CTO, has already written extensively about the Nuxeo EP architecture, let me focus here on the points that I think need to be highlighted and refer you to his writings and slides (see below) for more details.
Overview
Nuxeo EP is an open source Java platform that provides building blocks to create sophisticated and robust ECM applications:
Core ECM services, such as: storage, lifecycle, security, audit, metadata, etc.
High level ECM services, such as workflow, search, document transformation / rendering, collaboration, etc.
Interfaces, especially web user interfaces.
To make it possible, and easy, for developers and systems integrators to create their applications, we have chosen an architecture where the building blocks are extremely decoupled, and can be easily assembled to address the specific needs of each project.
The Nuxeo runtime and component framework
How does it work in practice? Each of the independent services that comprises the platform is implemented as a set of Java classes and supporting files (e.g. config and templates), bundled together in a JAR file, which is a physical manifestation of what is generally called a "component", and in our case, a "bundle".
When the application server (such as JBoss) or web container (such as Tomcat or Jetty) starts, it scans the JARs that it has access to and starts up the services that are contained in these JARs. Upon activation, these components can register information in several registries, in other words, "extend" existing components. They can also define ways they can be extended by other components, using what we call "extension points".
This way, for the application developer, an important part of his work is already covered just by choosing the services he needs from the generic "off the shelf" components that are provided by the platform, or available as add-ons on the Nuxeo Marketplace.
If you are familiar with modern Java technologies, you might have recognized here the principles of the OSGi module system and service platform, and Eclipse's extension points.
As an example, a new OCR service (whose role would be to extract text from images) could be added to a platform and then register itself into the transformation engines registry. This way, an application that manages documents scanned from paper copies can be configured with no specific code to leverage this OCR service to index the full text content of these documents, as extracted by the OCR service.
As another example, a JAR can be comprised of only configuration files for the various services that the Nuxeo platform provides, to enable customization (or overriding) of the default parameters of a standard application built on top of Nuxeo EP (for instance, Nuxeo DM for Document Management), with customer-specific document types, life cycles, metadata, indexes, actions, or look and feel.
More info: OSGi Bundles, Components & Extension Points from the Nuxeo Tutorial.
Pre-built applications
The end-game of our development effort is to create great applications that answer the needs of real users.
Providing great building blocks and an assembly manual to create these applications is a way to achieve this goal, but it would be time consuming to build an application from scratch using a bottom-up approach.
This is the reason why we also provide ready-to-use content applications, such as Nuxeo DM (for document management) or Nuxeo DAM (for digital asset management), which cover most, if not all, the needs for basic document management and digital asset management with no customization at all.
But wait, it gets even better! Since these applications are based on the modular Nuxeo EP platform, they are easy to customize using just configuration files (no code), or by using Nuxeo Studio, our configuration "IDE" that is available as a service to our customers, that spits out the config file from high-level descriptions that can be modeled graphically by business consultants.
Why did we choose this model?
This model is great but comes with a price (mostly for us, developers of the platform): developing software as decoupled components imposes the need to be extra careful in the way software is developed, in order to isolate the different functionalities in different components and ensure that all the components can work together in every combination that makes sense.
Most of our competitors (including the big vendors in the Gartner magic quadrant) don't make this effort, or have a technology that is too old and inflexible to move into this direction: they are happy to provide products as big monolithic pieces of software that look ok out of the box, but that are so impervious to change beyond the basic configuration that they offer that it can take 10 times longer (when it's possible at all) to adapt their software to real-life customer needs.
Integration costs skyrocket, while the architecture of the end result looks more like a plate of spaghetti than a cleanly layered cake.
Worse, when a new version comes out, all the customization has to be thrown away and restarted from scratch.
With our model, on the other hand, you can cleanly isolate your customization and extensions into independent components, and be sure that the cost for upgrading to a new version stays very reasonable.
Open source Java
Nuxeo is an open source Java project. As such, we try to leverage as much as possible existing open source Java technologies, as long as they have licenses compatible with our project's license, and to focus our efforts on the parts that are not already served by the open source Java ecosystem.
It takes a lot of discipline to do so: we need to carefully assess each of the external libraries we are using, for license compatibility, of course, but also for their quality and long-term viability.
As good citizens of the open source Java ecosystem, accustomed to working within our own open source project, we also work with the communities or companies that develop the open source libraries we are using, when we find they need fixes or enhancements.
Further information
Presentations
Article and white papers
- Lessons learned developing the Nuxeo EP open source, component-based, ECM platform, a research paper that was presented during the ICSSEA 2010 conference.
- Technology Audit of Nuxeo EP by Ovum Research (2010).
- Overview and Architecture on the Nuxeo Documentation site.