The Java Content Repository(JCR) API allows developers to use a common API for accessing different content islands spread through an organization. However, a recent patent filing by BEA may prove to be a 'wrinkle' in the typical standardization process for Java API's, or the JSR process.
Another important aspect of JCR that bears remembering is that it's silent on the subject of federation. JCR is an API for talking to a content repository (a repository, singular). JSR-170 may enable federation, but it doesn't in any way specify it. A recent patent filing by BEA Systems speaks to the federation issue as well as the language issue. It proposes the notion of a Virtual Content Repository (VCR), which is a federation of JCR and non-JCR repositories hidden behind a Service Provider Interface (capable of being implemented in any language). The SPI is kind of a meta-API layer (think ODBC). You talk to the VCR through the SPI. Of course, the problem with this approach (if BEA gets the patent) is that it's patented. It becomes a kind of anti-standard. If BEA does get the patent, it could be bad news for JCR, precisely because the VCR+SPI approach outlined by BEA is a natural one for achieving federation of JCR-compliant repositories in a heterogeneous IT environment. It's an architectural approach many big ECM vendors would probably want to take with JCR. If that approach is suddenly unavailable, JCR repository integration becomes problematic. And "problematic" is not a word JCR needs to be associated with, at this point.
Read Kas Tomas complete post: http://www.cmswatch.com/Trends/1104-BEA,-the-Patent-Office,-and-the-Future-of-JCR?source=RSS