DEVELOPER: Industry Standard
Working Around Silos
By Marta Bright
The Java Content Repository provides access to content silos.
There's ample commentary dedicated to the perils of siloed content—that dreaded state of existence wherein there's no integration of the content between a company's various channels. Among the net results are content on the Web that conflicts with print materials, and different information presented by telephone support specialists and event field sales staff. Customers, of course, get mixed messages and, at times, inaccurate information between the various channels.
Consolidation seems the logical solution, but in many cases it's not an option, for organizational or infrastructure reasons. "In most cases, those content silos were an integral part of larger applications and would sometimes have required massive reorganization and rewrites to switch from one content system to the other," says Philipp Weckerle, principal product manager for content integration at Oracle. "Migration brings a lot of other content-related problems, such as differences in taxonomy." There are also recent legal considerations, such as Sarbanes-Oxley, that actually support the premise of silos.
JCR to the Rescue
The Java Content Repository (JCR), the result of Java Specification Request (JSR) 170, offers a solution for dealing with content silos and meeting compliance requirements. According to Weckerle, the JCR provides a common access layer to content silos. "Existing applications can be changed from using native APIs to the JCR, and the content is stored in the original system. And new applications are now able to access all the different silos by using this common Java Content Repository API, which dramatically reduces development cost. Finally, content migration plans can be put in place and the content can be migrated without significantly affecting the application, because the new content system is accessed through the same Java Content Repository API," he says.
The JCR provides a flexible interface that allows for development against a common set of APIs, with the added benefit of connection capabilities to virtually any repository that supports the standard via compliant adapters. "You can loosely call the JCR 'JDBC [Java DataBase Connectivity] for content,' because it has a similar goal: a common interface for applications, independent of the back-end infrastructure," Weckerle adds. "At the same time, not all developers need to be trained on the different APIs that come with the different content systems. With the JCR, one API covers it all."
The JCR has not fundamentally changed the content management system (CMS) market, but it has simplified integration of CMSs into business applications. "From the customer's point of view," says Weckerle, "Content management systems are no longer the big unknown where each system has its own way of working. The JCR provides the common thread between them."
Beyond providing a common way to access content, the JCR offers a standards-based solution and choice. "The market demands standards-based mechanisms for accessing information vital to its business," Weckerle says. "This information can be stored in a database, a content management system, or a file system, but with both a standards-based access mechanism such as the JCR or JDBC and highly specialized native APIs, customers can choose whatever fits a particular requirement best."
Looking to the Future
"The JCR, in version 1.0, is at the very beginning of what seems to be a long life, especially given the increasing demand for managed content in more and more areas," Weckerle explains.
A new version of the standard is also being developed—JCR 2.0 (through JSR 283), and Oracle is part of the JSR 283 expert group.
Marta Bright is a senior writer with Oracle Publishing.