No jive--Java set to jolt content market
The Java Content Repository is a proposal for a standardized API to address content repositories. It was submitted to the Java Community Process last February, and the JCR expert group, lead by Day Software CTO David Nuescheler, hopes to complete a final draft in the second half of 2003.
JCR is another step in the inevitable evolution of CMS away from the proprietary monoliths of the past, and toward more flexible, interoperable architectures that will allow different layers of the CMS stack to work together regardless of vendor. This is good for companies building their own CMS solutions, good for the developers working on them, and--although it may cause headaches for some companies along the way--good for the CMS industry overall.
The JCR would be a new layer in the CMS stack, sitting between CMS or portal applications and the underlying content storage tool, such as an RDBMS, the file system, an LDAP server, XML, or another data storage mechanism. It is intended to serve a similar role, on an API level, to that performed by standardized SQL within an RDBMS. It would, says Nuescheler, provide "a standard implementation-independent way to access content bi-directionally on a granular level within a content repository." What that means is that rather than accessing storage directly, CMS tools would instead use the JCR access methods, which would then interact with the underlying storage technology. The specification also includes methods for versioning, full text search and filtering, event monitoring, namespaces, and issues of concurrency and transactions.
By providing an abstraction layer, JCR will allow much greater flexibility in mixing and matching CMS products and content storage tools--what Nuescheler calls "swappability." Additionally, it could greatly ease integration between different parts of a distributed application--a single repository could service multiple clients as long as they all use the API and, conversely, a single application could more easily draw from disparate repositories. "Vendors of applications that rely on an underlying repositories will no longer have to integrate dozens of separate content repositories with their own API's, or use proprietary abstraction APIs," says Nuescheler. Integration with legacy technology would also be simplified, since it would take place outside the CMS application itself, through a JCR bridge which may be written in house or purchased.
The key point is that accessing content is divorced from storing content, allowing either the application or the content storage mechanism to change without affecting the other.
A new class of content tools will be made possible by JCR, which Nuescheler calls the "content infrastructure market." Companies might provide standalone JCR-compliant content repositories, which could support any other JCR-compliant application. Another possibility might be JCR-compliant connectors to common enterprise technologies, such as a JCR bridge to Oracle or SLQ Server, or a JCR tool to store content as XML flat files.
JCR will reduce risk for those purchasing CMS related products: Software that is outgrown, or that doesn't meet performance requirements, can be replaced with minimal or no changes to the underlying content repository. And the lifetime of legacy storage solutions might be lengthened, if a JCR bridge to the legacy application can be built or purchased.
For JCR to be adopted in the market, two important steps need to be taken: CMS applications need to be rewritten to request or submit content through the API, and connectors or extensions to common enterprise content storage technologies need to be built.
This could be a chicken-and-egg situation, in which CMS and content storage companies resist the expense of implementing JCR compliance until it's considered a critical technology. But Day Software and other members of the expert group developing JCR are, according to Nuescheler, "already starting to implement previous drafts into their products."
Adoption of JCR might expose CMS vendors to the same conundrum Microsoft is facing in moving to XML file formats: While Microsoft is taking a risk in opening up its formats, it's a risk the company needs to take to drive the upgrade cycle, to meet customer demands, and to allow the extensive integration benefits that flow from standards compliance.
The JCR initiative is the kind of practical building block that can push the enterprise software environment closer to interoperability, and that can make software purchases safer and easier to integrate into the enterprise. All this, of course, requires proper implementation and effective vendor support. Those are rigorous requirements, but the promise is there. We need to keep our eyes on JCR as the technology moves closer to the marketplace, and you can even participate in the process by making your opinions known during the upcoming period of public comment.
Do you think JCR will help you deal with your company's content management challenge? Tell John about it in an e-mail or TalkBack below.