This session describes the architecture and implementation of an embeddable, extensible enterprise content management core for Java EE and simpler platforms. The presentation starts by describing the general architectural concepts used as building blocks:
• A schema and document model, reusing XML schemas and making good use of XML namespaces, where document types are built with several facets
• A repository model, using hierarchy and versioning, with the Content Repository API for Java (JSR 170) being one of the possible back ends
• A query model, based on the Java Persistence query language (JSR 220) and reusing the path-based concepts from Java Content Repositories (JCR)
• A fine-grained security model, compatible with WebDAV concepts and designed to provide flexible security policies
• An event model using synchronous and asynchronous events, allowing bridging through Java Message Service (JMS) or other systems to other event-enabled frameworks
• A directory model, representing access to external data sources using the same concepts as for documents but taking advantage of the specificities of the data back ends
Suitable abstraction layers are put in place to provide the required level of flexibility. One of the main architectural tasks is to find commonalities in all the systems used (or whose use is planned in the future) so framework users need to learn and use a minimal number of concepts. The result is a set of concepts that are fundamental to enterprise document management and are usable through direct Java technology-based APIs, Java EE APIs, or SOA. The presentation shows, for each of the main components, which challenges have been met and overcome when building a framework in which all components are designed to be improved and replaced by different implementations without sacrificing backward compatibility with existing ones.
The described implementation, Nuxeo Core, can be embedded in a basic Java technology-based framework based on OSGi (such as Eclipse) or in one based on Java EE, according to the needs of the application using it. This means that the core has to function without relying on Java EE services but also has to take advantage of them when they are available (providing clustering, messaging, caching, remoting, and advanced deployment).