Beginning with Sakai 2.5, content hosting started down a road of migrating toward JCR and its implementations for content storage. Merely utilizing JCR for content storage, however, does not suffice; bridging code for legacy compatibility is also required for the full migration. What's described below lays out the various stages and deployment options for this broader migration.
JCR Content Roadmap
Up to and including v2.4, Sakai used a Content Hosting Service that stored its content in a DB and on the file system. In 2.5 storage in a Java Content Repository was also enabled, by the addition of the 'Content Hosting Service with JCR Storage'. In addition, 'JCRService' (a minimal shim on JCR) gave direct access to the JCR, but did not implement the whole of legacy Content Hosting Service. Finally, a 'Content Hosting Service Multiplexer' and 'Content Migration Service' were provided to ease migration of data from legacy CHS DB and Filestore storage to JCR storage. Legacy code is shown in blue and 2.5 release additions are shown in green in the diagram below.
The services above were created on the assumption that new tools would be written to use JCRService only where there was no requirement for new tool content to appear in legacy tools. As we move forwards towards wider JCR adoption it has become clear that there needs to be a way in which new tools can store their content in JCR and have that content accessible for both read and write within tools (e.g. Resources) that continue to use the legacy Content Hosting Service. The post 2.5 components (shown in red above), 'JCR Content Hosting Handler', 'JCR Node Factory Service' and 'Content 2 Wrapper' make this possible and easy to achieve.
New Components (post 2.5)
JCR Content Hosting Handler
The JCR Content Hosting Handler builds on the Content Hosting Handler plugin mechanism present in Sakai since v2.4. The CHH plugin mechanism allows external content repositories to be "mounted" within Content Hosting Service so that the content external to Sakai becomes available within resources. We already have read/write content hosting handlers for server filesystems, for DSpace, and for Fedora. A JCR Content Hosting Handler will make it possible to "mount" a JCR Folder as a Folder in Content Hosting Service and consequently makes the content within that folder available to any tool using Content Hosting Service, including the Resources tool.
JCRContentHostingHandler: Technical Details
The JCRContentHostingHandler will use the same mount mechanism as the existing ContentHostingHandler mount specifications. To mount a folder, a small XML file is uploaded to Resources. For JCRContentHostingHandler, this file will contain the connection details to the JCR repository and the path into the repository. A property is set on the ContentResource that contains the XML file specifying the handler, and the XML file becomes a Virtual Content Collection
More detail on Content Hosting Handlers can be found in google
http://www.google.com/search?q=content+hosting+handlers
The JCR Content Hosting Handler is shown connecting direct to JCRService. JCR Content Hosting Handler will need to use more of the standard than is exposed through JCRNodeFactoryService, so it makes sense to go direct. It will still let JCRService manage the jcr transactions. However, this has the potential for JackRabbit dependencies to creep in. The JCR CHH code will be written in such a way as to ensure multiple JCR implementation support. We will not allow Jackrabbit dependencies either by direct binding to Jackrabbit classes, or out-of-band in the JSR170-CHH.
JCRNodeFactoryService
The JCRService provided in Sakai 2.5 is a small wrapper that enables client code to get a javax.jrc.Session object from the Java Content Repository implementation deployed within Sakai. Clients of JCRService then use the standard JSR-170 API to perform all operations, having no more use for the JCRService. The JCR Session that is retrieved from JCRService knows about the Sakai environment and is bound to the request cycle, so that the programmer using JCRService does not have to think about transactions.
This does put extra load on the developer since they now have to understand the JSR-170 API and need to understand how to use that API in a way that will work over most JCR implementations if they wish to preserve substitutability of JCR back-ends (a major business reason for introducing JCR). The reference implementation of JSR-170 is Apache Jackrabbit. In addition to being a RI, it goes much further than the standard, and could be used as a full XML database. Consequently a developer targeting Jackrabbit is likely to create an application that will not run on other JSR-170 compliant implementations.
The CHS-JCR code has been written to target JSR-170 and does run on both Xythos and Jackrabbit. The JCRNodeFactoryService is based on this work.
JCRNodeFactoryService will provide a limited number of simple methods to make it easier to interact with the JSR-170 API, in a way that will work with multiple JCR repositories. It will provide methods to create JCR Files and Folders, find JCR Files and Folders, and stream the content of files both read and write.
This service will also allow the developer to interact with a javax.jcr.Node which is part of the JSR-170 API. As such it will be possible to gain access to all of the JSR-170 API and so a determined developer can still use the JCR in a way that might not work on full compliant JCR implementations like Xythos.
Content2Wrapper
Where the application developer does not want to bind to the standard javax.jcr.* API, there will be a Wrapper that allows the developer to bind to Sakai classes. This wrapper will hide the features of JCR and only expose a limited number of features. The wrapper will also ensure that the developer cannot create content which might not work in an alternative JCR implementation. If you want an API that enforces all the rules then you should use this Wrapper API.
JCR Rules for Sakai
The Rules for using the JSR-170 API in Sakai are relatively simple. They fall into 2 categories, content and functionality.
Content
If you want to be able to run on many different JCR implementations, both commercial and open source you should only use files and folders, and only attach properties to those files and folders and not any other child nodes. In JCR terms this means using JCR Nodes of type nt:folder to represent folders and nt:file to represent files. Nodes of type nt:folder may only contain nt:file nodes or nt:folder nodes. Nodes of type nt:file will contain at single nt:resource node named jcr:content, that will have a standard set of properties as defined in the JSR-170 specification. Properties of the folder or file will be attached to the nt:folder or nt:file nodes. No properties other than those in the JSR-170 specification will be set on ny other node types. For a fuller description of node types and the standard node type schemas please see the JSR-170 specification document. The JCRNodeFactoryService implementation ensures that nodes are created conforming to these rules. By reducing the richness of the Node Type schema, we will be able to support many JCR implementations.
The full RI of JSR-170 allows arbitrary node schemas and types to be created with the same richness as a XML document. Some implementations of the JSR-170 standard do not support this flexibility.
Functionality
Before using any feature of the JCR specification you should check with the JCRService implementation that the underlying JCR Implementation upports the required functionality. Conformance with the JSR-170 standard is defined in levels. As the level of conformance increases, the number of features implemented increases. The license for implementors of the JSR-170 standard stipulates that they must declare their level of conformance and there is an API method that can be used to determine the conformance level supported by the underlying repository. If we find that this API does not supply sufficient granularity we will add extra support in the JCRService APIs.
Deployment Options
Legacy Content Hosting Service Only
This is the deployment of Content Hosting Service and Resources in all versions of Sakai prior to 2.5.
Legacy Content Hosting with Some JCR Tools
In 2.5 with Post-2.5 Components, it will be possible to run with Legacy Content Hosting and to use tools developed on JCR. The content of the tools can be exposed bi-directionally to read-write using the JCRContentHostingHandler. Either a site administrator or the tool itself can perform the mount operation.
This means that content can be uploaded from either the new tool or resources into the space managed by JCRService and content in the new tool can be read, updated and used in legacy tools. However the new tool will not be able to access all content stored under the legacy content hosting service.
Migration of Content to JCR
For content migration, the exposed Content Hosting Service API is replaced with a Multiplexer (CHS MUX), that controls which CHS implementation is active. Initially the Legacy CHS will be active. A Content Migration Service will build a list of content items to migrate, and then migrate those items into the JCR Content service. As content is modified the queue will be added to, resulting in some rework of existing items. When the queue has reached a steady state. An operator will schedule downtime and the CHS-MUX will be switched over. As the app servers come up, the remaining small number of items on the queue will be migrated over and all activity will take place via the CHS JCR implementation. At that point the deployment can move onto full JCR Content Storage.
Content Hosting on JCR
Once the migration is complete, the DB Content Hosting Service can be removed, and all operations can be performed against the JCR Service. This does not reduce the code base supported by Sakai but puts us in a position to move forwards and gain significant functionality with minimal effort or risk
Full JCR Content and Tools
Ultimately we will re implement the Resources tool with input from Fluid and remove all of the legacy content hosting codebase. This reimplementation may break up the Resources tool into other, new tools e.g. a File Manager and a Content Presentation Tool. The Resources Tool in the diagram illustrates that future Resources Tool features will be supported by JCR-provided content and illustrates the third connection option for a new tool - direct to JCRService. Other services and tools (file helpers, OSP use of resources, etc.) will be replaced with off-the-shelf open source components (eg Jackrabbit WebDav) or rebound to one of the 3 JCR-based services.