JSR-170: What's in it for me? -- CMS Watch

JSR-170: What's in it for me?
byDavid Nuescheler and Janus Boye
20-Apr-2005

With the Content Repository API for Java Technology (akaJSR-170) specification coming to fruition, you might be wondering what this new standard brings to the table.
JSR-170 is a specification developed under the Java Community Process (JCP) program. As of April, 2005, it is in the "Final Proposed Draft" stage which means that the final release of the specification can be expected shortly. The expert group contains more than 60 individual members representing major CMS vendors, but also the Java technology infrastructure players like Apache, IBM, Oracle, BEA, and Sun.
The standard will have a major impact on the content management landscape, separating infrastructural services from application services as has long been prevalent in the data world.
Specifically, over time the introduction of JSR-170 will more readily distinguish technologies focusing on: Content repository infrastructure, getting content under control, in other words compliance and risk management, with scalable and reliable plumbing. Content applications, putting content to work, in other words revenue growth and competitive advantage, with friendly user interfaces and easy-to-measure business value.
 
As you can imagine, JSR-170 is likely to cause a healthy shake-up in the CMS market and beyond. But standards like this can seem very abstract, begging the question, "what's in it for me?"
To answer that question, we'll take a closer look at the repository problem today, the new standard, and then we'll get back to the positive impacts for developers, CIOs, system integrators, editors, and even vendors.
The problem
Today almost every content management application ships with its own (frequently proprietary) "content repository." This repository usually extends a storage layer such as a relational database with the various service facilities that almost any modern content application requires. These "repository services" -- for example versioning, driven by legal compliance -- are implemented differently by nearly every vendor, each exposing different terminologies and different programming interfaces.
The typical distributed enterprise therefore possesses polyglot repositories with a variety of special access methods. Not surprisingly, this drives up the cost and complexity of maintenance and integration.
One common solution to this problem posed by many content management vendors is to sell you on the idea that their content repository should be the center of your organization's content universe, with the promise that you will receive all your critical content applications such as WCM, DAM, Source Code Management, etc., grouped and sitting nicely on top of a single repository.
There are several drawbacks to this approach: It may not really be one repository after all. Many of the ECM vendors have grown by acquiring numerous application vendors. Each acquisition of new software is patched together to their existing product resulting in a pile of software that was never intended to run on a single content repository, and as of today usually does not. Potential vendor lock-in for application services going forward. There are still virtually no independent third parties that develop and sell real applications based on a content management vendor's proprietary interfaces. This is due in part to the fact that the development of the core code base of many content repositories stalled numerous years ago, but perhaps more importantly, in the absence of any clear market leader or industry standard, developing services on top of any single vendor's repository API today is a risky game. You are likely going to live with multiple legacy content repositories in the nearterm regardless, even if you standardize on a single ECM vendor tomorrow. This means gaining access through middleware, or learning proprietary APIs. You may find some new Web Services interfaces, but support is uneven and inconsistent across implementations.
 
The information silos that have been generated over the last decade will not easily be consolidated. Communications among information silos are limited and based on proprietary interfaces, even with specialized integration frameworks. Clearly, it's time for a repository access standard.
Enter JSR-170
JSR-170 promises the Java world, and possibly beyond, a unified API that allows accessing any compliant repository in a vendor- or implementation-neutral fashion, leading to the kind of clean separation of concerns that characterizes modern IT architectures.Some people call JSR-170 the "JDBC of Content Repositories."
Moreover, in the longer term, JSR-170 will offer the potential for true content repository infrastructure that independent application developers can use to build their applications on, without any partner fees or commercial association.
The JSR-170 API defines how an application and a content repository interact with respect to a number of content services. For example the versioning facilities of a content repository are clearly defined, so an application knows how to browse the version history, check in and check out content items, or update and merge content in a standard fashion.
Another example is the query service that allows an application to search any compliant repository in a standardized fashion without learning a vendors proprietary search API and possibly proprietary language.
A vendor can reach JSR-170 repository compliance through a variety of different means. The vendor can ship a natively JSR-170-compliant repository, or a third party can build a JSR-170 connector that enables use of the standardized API even on repositories that are not natively compliant. In this latter case, repositories are referred to as "JSR-170- enabled." Similar to the JDBC world, where small, agile "JDBC-driver-vendors" bridged the time gap until the big RDBMS vendors readied bundled JDBC drivers, we will see for JSR-170 a very similar situation where connector vendors "enable" the standardization of existing repositories.
So what's in it for you? Quite a bit, actually, depending on what you do.
"I am a (Java) developer"
As a developer you may take some comfort that most enterprise-tier content management vendors now offer Java-based solutions or Java APIs. However, you must still use proprietary API's to access content repositories. JSR-170 means that you will have a well-designed single API to work from without having to worry about which vendor repository is underneath the application.
Not only does that mean that your skills acquired learning a JSR-170 -compliant or -enabled repository can be applied to all other such repositories, it also means that your code will be portable and you will not have to reinvent the wheel for every implementation that brings a different repository (so long as that repository is compliant).
Additionally that means there will be a rich set of development tools such as Eclipse plug-ins, of which many already exist even before the release of the standard. WebDAV-servers and RMI-layersare already readily available.
Furthermore, since the Apache Software Foundation (one of the most important resources of every Java developer) has taken on the reference (named "Jackrabbit") implementation project for incubation, you will always have access to an open-source based, fully JSR-170 compliant content repository, without having to slog through partnership agreements, NDA's, evaluation licenses, and so forth, enabling you to download and start developing your content application in minutes.
Finally, JSR-170 has already made a leap outside of being strictly Java centric. There are multiple third-party efforts underway to port the JSR-170 spec to other languages and environments likePHP.
"I am a CIO"
Today your organization uses several or even dozens of content repositories. In the first step, JSR-170 provides you with a utility to break out of information silos in a standard driven way. Having the same API on top of your existing repositories will allow your organization to write all applications based on an open standard, allowing your enterprise to harvest information from all its JSR-170-compliant or JSR-170-enabled repositories without having to replicate the application logic.
Once freed from the chains of proprietary API's (and consequent vendor lock-in), the real bonus of repository consolidation kicks in. Over time, you may be able to consolidate your content repositories to become true infrastructure. This allows you to consider purchasing all your repositories from one vendor and centralize, which drastically lowers your TCO with respect to maintenance, support, and other on-going costs -- just as you did with all the other pieces of infrastructure from J2EE appservers, to RDBMS, to server operating systems. At a minimum, you should be able to ratchet down to a limited number of repository vendors, with application portability above them.
Since JSR-170 also proposes a universally-accessible repository, complex discussions between Portal and CMS vendors on how to integrate can become much simpler. Reading and writing from and to the repository will only be limited by access control and therefore possible from any environment.
JSR-170 will also offer a solid platform to tackle the semantic content integration of the different data models directly.. "Data-cleansing" and "harmonization" can be dealt with in the future by highly specialized tools, rather than having functionally limited, repository vendor specific tools.
JSR-170 also allows you to center your future ECM strategy on a standard rather than on a single vendor, a standard that will evolve as a collaborative effort of the content industry.
"I am a systems integrator"
As a systems integrator, you're probably looking to reduce risks, minimize your exposure to the vagaries of vendor channel strategies, and recycle code from project to project. JSR-170 delivers on all these points.
First, using the standard increases the probability of delivering a project on time and on budget, in effect increasing the predictability of each project.
You will be able to hire people with generic JSR-170 knowledge, rather than having to look for vendor specific competences (as you do today, when hiring J2EE developers or database application developers), also allowing you to select from a greater pool of talented people.
Projects will also become more efficient and valuable using JSR-170 as you are able to reuse all those clever tools and slick features developed for previous customer projects.
When you enter into projects with software vendors, you usually have to accept the fact that you will not make a considerable profit on the initial projects. One reason for this is the steep learning curve consultants have to deal with when using a new vendor-specific repository for each project. With JSR-170 this becomes much less an issue, and therefore it will become easier for you to propose solutions across a greater number of content management solutions. In turn this means increased revenue potential.
"I am a web editor"
We all remember demos during the CMS selection process where one vendor met the IT department's requirements with respect to the repository functionality, and the other vendor offered a really good UI but a lousy repository. JSR-170 will allow you to pick the best of both worlds.
In a more standardized world, you can purchase a JSR-170 compliant repository from your preferred infrastructure vendor making your IT department very happy, and then purchase the content management application best suited to provide your editorial team with all the business features and slick interfaces that you like so much.
Beyond that, JSR-170 will even allow you to mix content applications on the same repository. That means that your workflow module can come from Vendor A, while your collaboration features come from Vendor B. Since they are both based on JSR-170 they work hand-in-hand, resulting in minimized integration effort to, say, put your chat or bulletin board conversation into workflow.
The future standard also brooks potentially significant usability improvements. For example, JSR-170 will allow the introduction of in-context editing into your portal. This means that editors will be able to make changes to content directly in the portal, instead of always having to go through a heavy weight CMS user interface. Editors will enjoy having one less interfaces to worry about and also a significantly reduced learning curve.
"I am a vendor"
As mentioned initially, JSR-170 will cause a healthy change for vendors. Some vendors will conclude:
Finally we can focus on our core competencies, namely applications, GUIs, workflows and the like. If we are completely honest with ourselves, our repositories were more of a necessity held over from the previous decade, rather than our core business. Sure, we can claim everything from full-fledged versioning, to distributed transactions, to support of fine-grained unstructured content, to clustering and fail-safeness, but aren't these commodity services now?
Most customers select us because we had application features that suited their business case. JSR-170 allows us to focus our R&D efforts on the application and leave the content repository commodity business to those companies that are good at that, e.g. the huge software infrastructure players or even infrastructure-oriented CMS vendors. Much like we do not develop our own RDBMS or J2EE appserver anymore, JSR-170 enables us to create great applications much quicker without worrying about the content repository plumbing.
For all vendors, applications will become more efficient, developed much faster, and the development cost to build a full-fledged CMS will drop drastically. This paves the way for new vendors with much better functionality, as the huge and inhibiting R&D resource-drain of developing the content-repository is removed. This in turn allows our industry to finally evolve into the advanced state of maturity that solutions buyers seek.
The Future
JSR-170 version 1.0 will be the starting point for a well-balanced, functionally rich API that will be actively developed in the JCP program. The JCP is the community-based process introduced by Sun in 1998 to develop Java binary standards; it has world-wide and industry-wide participation.
Following a general rule for standards that simpler is better, a number of borderline features and functionalities (like for example "system administration" aspects of a content repository) have been left out of the specification to keep it small and to reach consensus more efficiently. In future revisions the Expert Group will explore additional standard features.
As we have illustrated in this article, JSR-170 is not only a future standard, but it is also rapidly finding usage in practical applications. You can download a reference repository today and begin planning for a world of true standardization among content repositories.
 
Next:
Send Feedback
Seeall Web Content Management Channel feature articles.
Need to select a technology vendor, but confused about your choices?See our vendor-neutral technology reports.
Join the conversation

About the Author

David Nuescheler is CTO ofDay Software and Specification Lead for theJSR 170 Spec.
Janus Boye is the managing director ofBoye IT, a vendor-neutral content management consultancy based in Denmark. Janus has previously worked at an enterprise CMS vendor in various roles with clients across Europe.