现在正是 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 仓库之上以标准的方式进行设置。
- 对只支持线性版本标定的仓库,提供简单版本支持。版本标定的扩展围绕“基线”和“活动”展开,以全面覆盖整个配置管理。
- 生命周期管理,允许容易地装配内容到一个过程引擎。
- 标准节点注册,允许应用使用仓库去注册和管理它们的节点类型。
- 新属性类型和新节点类型,增强应用围绕公共元数据的互操作性。
- 工作区管理,允许创建和删除仓库中的工作区。
- 可共享节点,允许内容仓库工作区中的树型结构变成更含蓄的网络结构。
- 定期观察,允许离线 / 轮询应用,以发现自上次检查之后内容仓库发生了什么。
想了解更多信息,你可以阅读 JSR-283 公众评测版、David 的幸福内容建模的简单规则以及关注InfoQ 的有关 Java 内容仓库的内容。
评论