In our previous blogs, we talked about the new releases of the Nuxeo Platform, the latest features and enhancements and implementation details. Today, let’s dive deeper and start looking at the Nuxeo Platform from the ground up.
The Nuxeo Architecture
The Nuxeo runtime provides the fundamental services to all layers, starting with storage. It is the functional basis for managing a content repository and interacting with content objects.
OSGI
At the core of the Nuxeo Platform is the repository for storing content and associated metadata. We store metadata in a SQL database structure while the content binaries are usually on a file system. This corresponds to the Document Store and Blob Store.
The Document Store is implemented by our Visible Content Store (VCS) and any SQL database. While we prefer PostgreSQL for performance reasons any SQL database can be plugged in at the convenience of the user. All metadata is kept in the VCS and what we refer to as a Document is a collection of metadata, with the binary or blob being just one field of a Nuxeo document.
The Blob Store is normally based in a file system and a simple structure where binary content is renamed with a unique ID. This is the only reference to the VCS. Keeping it flat and simple like this removes the need for any expensive file system operations, makes backups and restores easy, and also allows switching to other Blob Managers such as Amazon S3.
On top of the storage structures and the runtime, there is a layer of configuration for defining content types and fields. This is done with XML structured definitions which, as we will see, allow extending and deploying customizations in the same way as the default way. It’s all done in a very pluggable way and defines the static structure of the repository.
There are operations that define all capabilities and actions within the Nuxeo Platform. Again these are all pluggable and configured and consist of classes implementing an operation type and using the runtime to interact with the repository. These are also exposed to all higher layers and this is the key to the extensibility of the Nuxeo Platform. They can be chained together into what we call Automation Chains to define specific behavior. They are exposed to external calls through different APIs, which I will discuss shortly, and can also be custom defined and plugged into the Nuxeo Platform to create additional custom functionality. Since the framework by design is modular and pluggable, customization is made easy and in line with the system goals.
There are concepts of Workflows, Lifecycles, Events and Listeners, which are also pluggable and customizable in the same way. Extension of Nuxeo capabilities is just a matter of adding a definition in an XML format and a possible custom Java class extension.
At this point we have the Nuxeo system defined functionally. Now we can look at the different ways to interact with the system. Normally, there would be a UI and an application designed for a particular set of use cases. Out of the box, the Nuxeo Platform provides Document Management and Digital Asset Management system (DAM) applications. DAM is just an additional set of content definitions and different UI components focused on working with digital assets, such as images and videos. The application is a set of UI components and associated behavior designed and laid out for a set of use cases, but uses the same set of underlying operations available to any other application.
The Nuxeo UI is based on JSF/Seam and a collection of templates and configurations for the UI look and feel as well as the behavior. This again is modular and the pieces of the UI can be configured. By having behavior and layout defined like this, it’s possible to extend, modify and add changes as an “add-on plug-in” without having to modify any sort of fixed design. In short, you’re adding not changing.
Extending
At this point we have a working Nuxeo Platform with all capabilities and out of the box application for Document Management and Digital Asset Management. This brings us to making the Nuxeo model a work process rather than making the users adept to understanding how to work with Nuxeo. Let’s start customizing the platform. As described earlier, the Nuxeo Platform is built with extensibility in mind from the ground up. We not only provide an Explorer tool to browse all the extension points and operations to identify default and customizable configurations but also provide the Nuxeo Studio development and configuration tool to make this visual and easy.
Nuxeo Studio
Rather than manually identifying and writing XML formatted code, Nuxeo Studio is a visual and centralized method to make customizations in the Nuxeo Platform. All the configurations possible in the Nuxeo Platform mentioned earlier can be done easily with this online application. Rather than fitting your Content Management practices to the Enterprise Content Management software, you can model and adapt the platform to your business process using Studio, thereby maximizing the efficient and usability. Studio is a one-stop place for configuring the static content, such as metadata schemas, document types and associated view layouts.
Next you would configure workflows with a visual editor, lifecycles, and events or user actions. Finally all available Nuxeo operations mentioned earlier can be grouped into chains, which can be called by events, user actions or through the APIs from external applications.
A Studio project is a set of configurations, which are deployed onto a Nuxeo instance directly with one click. It fits into the modular nature of the Nuxeo Platform.
WebEngine
Rather than being just a Content Management application, Nuxeo is a platform, which means it’s supposed to support your applications in various ways and itself being extensible by nature. I’ve described the latter already - it’s because of the modular pluggable nature and the Studio tool.
The next step in providing more control over your UI and application is a WebEngine framework that the Nuxeo Platform provides to build your own UI and front end that runs on the Nuxeo server. This method gives you direct access to the Nuxeo runtime while allowing you to build your own UI using HTML and Freemarker templating.
API
Nuxeo also supports external apps just as much as internal configurations, through a set of APIs, and exposure to operations and Rest calls. You can call all Nuxeo operations and automation chains through a Java client, REST calls, and JavaScript enabling any application to take advantage of the Nuxeo Platform.
Finally, to ensure version compatibility and version control, Nuxeo provides an IDE plugin for Eclipse where almost any point can be extended with custom Java code for a truly extensible system without any modification to Nuxeo code.
Learn more about content services architecture best practices in this paper.