- JSR-170: What's in it for me?
JSR-170: What's in it for me?
by David Nuescheler and Janus Boye, Day
2005-04-20
With the Content Repository API for Java Technology (aka JSR-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:
Day Software
1
1. 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.
2. 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.
3. You are likely going to live with multiple legacy content repositories in the near term
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 vendor’s 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
Day Software
2
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-layers are 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 like PHP.
"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.
Day Software
3
"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
Day Software
4
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.
Day Software
5