Java内容仓库的繁荣期 2.0的公众评测版

现在正是Java内容仓库（Java Content Repositories）的繁荣期。第二版JCR API已经发布了公众评估版（JSR-283），与此同时，第一版（JSR-170）进展良好： Jackrabbit现在是顶级Apache项目，正准备收编对象内容映射工具，开始超越单纯的内容管理系统转而在其它开发成果中充当相应的角色，比如JBoss Rules' BRMS中的业务规则持久化库，以及artifactory，它是一个Maven 2 仓库。

JSR-283 旨在从以下几个方面改进JCR 1.0：

访问控制和节点类型的管理

通过新的标准节点类型（包括元信息和国际化）改进互操作性

扩展内容建模能力

联邦、交叉仓库和交叉工作区（Workspace）功能

积极发展现有查询语言、版本标定和观察

Remoting和客户/服务器协议映射（译者注：Remoting是采用分布式进行编程的一种技术，主要用于管理跨应用程序域的同步和异步RPC会话。默认情况下，Remoting使用HTTP或TCP协议，并使用XML编码的SOAP或本机二进制消息格式进行通信。）

InfoQ有机会就Java内容仓库和API第二版的公众评测版等问题，对David Nuescheler进行了采访，他是Day Software的首席技术执行官和JSR283及JSR170规范的领导者。关于实现者采纳JCR的话题：

用户对API两边的采纳程度都已经超出了我的期望。在内容仓库实现这一边，可能有二十多个实现。

我发现，尤其值得一提的是，我们已经有了4个独立的开源JCR实现，在如此短的时间内达到这样结果，这对v1.0标准来说是最好的成绩。我不记得其它任何JSR曾这么快被采用。

关于被开发者采纳的话题：

更重要的是在API的另一边，应用一边，我们已经看到有大量的使用JCR的项目和产品。我们试图在（jackrabbit wiki）[http://wiki.apache.org/jackrabbit/JcrLinks]上维护一个列表，虽然这只是冰山一角，但是却很难做到。

在这方面，JCR的确超出了其它内容仓库技术。我认为大量的独立应用开发者已经丧失了对任何私有的内容仓库API的兴趣。

当被问及什么样的应用适合使用Java内容仓库时，尤其与使用传统数据库对比：

那种认为内容仓库仅限于使用于任何形式或形态（DM, DAM, WCM, SCM）的“内容管理系统” 的论断，我称之为公众误解。我认为JCR不仅对基于Web的CMS来说是一个理想的存储层，而且对其它许多应用来说也是理想的存储层，理解这一点很重要。

我认为内容仓库是几乎所有现代应用理想的存储场所，这些应用意欲使用版本标定、细粒度访问控制、全文检索、大二进制和所有内容仓库所暴露的其它服务。

在我的应用中，与JDBC接口相比，我个人总是更喜欢丰富的JCR接口，但这主要是因为使用JCR让我很舒服。

对那些以前没有使用JCR经历的人，我推荐他们采用现成的应用（我是这么称呼的）。该应用将成为利用内容仓库的额外服务如版本标定、访问控制或层级结构的应用。

谈及JCR2.0的总体话题：

对于JSR-283，我们确实与大的ECM厂商一起付出了很多努力，以接近通常已使用的ECM实践，因此使得厂商更容易与该规范兼容。

David还罗列了其个人的JCR2.0十大特征：

查询扩展主要围绕对SQL，尤其是JOIN的扩展支持；我们还为查询对象模型引入了Java绑定，这让“查询向导”以及“Prepared”查询（它虽是最后提及，但也很重要）更加容易。

访问控制管理，已经超越JCR v1.0指定的自省（introspection）。

保管策略 & 持有支持（Retention Policy & Hold Support），使记录管理应用能在JCR仓库之上以标准的方式进行设置。

对只支持线性版本标定的仓库，提供简单版本支持。版本标定的扩展围绕“基线”和“活动”展开，以全面覆盖整个配置管理。

生命周期管理，允许容易地装配内容到一个过程引擎。

标准节点注册，允许应用使用仓库去注册和管理它们的节点类型。

新属性类型和新节点类型，增强应用围绕公共元数据的互操作性。

工作区管理，允许创建和删除仓库中的工作区。

可共享节点，允许内容仓库工作区中的树型结构变成更含蓄的网络结构。

定期观察，允许离线/轮询应用，以发现自上次检查之后内容仓库发生了什么。