David Nuescheler 谈 JCR 和 REST

InfoQ: 您能向大家快速地概括一下什么是 JCR/JSR-170 吗？

David Nuescheler (DN): 我认为这个问题可归结为对内容仓库特性集的解释。

通常如果用一句话描述，我总是将内容仓库说成是，“关系数据库”和“文件系统”的“集大成者”，外加所有那些我们一直没有但不得不内建在我们自己应用中的好东西。

这包括如事务、伸缩性、数据库端的查询、使用超大文件带来的真正好处、流、访问控制和文件系统端的层次结构，以及诸如版本标定、全文检索，以及两者都不支持但非常重要的“数据优先”方法。

JCR 是描述所有这些特性的 Java API。

InfoQ: 您对当今市场中的 JCR 采用情况怎么看？

DN: 当它开始被采用时，我总是认为，从 API 的实现者和使用者两方面进行思考很重要。

首先据我了解，在 JCR 初始版本发布后的仅仅两年间，就有超过一打的仓库与 JCR v1.0（即 JSR-170）相兼容，我为此而感到激动。尽管某些仓库如预料的那样是通过第三方连接器实现这种兼容，但是大多数已经具备了直接与 JCR 兼容的能力。这既包括主要的仓库厂商，也包括一些刚刚面世、革命性的新仓库。另一个非常鼓舞人心的事实是，现在已经有 4 个 JCR 的开源实现，我认为这表明了实现者对规范的极大支持，同时也表明该规范已具备跟其他在 Java 领域内被广泛大量采用的规范相提并论的资格。

更重要的是，在 API 使用者中的采用情况超出想象，而且我认为这是采用过程中更重要的一部分。在很多方面，它真正推动了人人都期待的仓库合并。每个新的内容管理项目如今可以依赖基于标准现成可用的内容仓库，而不是从头构建另一个“他们自己的”内容仓库。这对开发者意味着，他们可以从项目开始就拥有可信赖的诸如访问控制、功能齐全的版本标定或全文检索等特性。每周我们都可以看到大量建构在 Apache Jackrabbit 上的新应用，它是访问最多的内容仓库实现，我认为你可以毫不夸张地说，假如没有 JCR，那些应用的每个开发者可能都已在 Hibernate 这类工具之上构建自己的专用内容仓库了。

InfoQ: 您的雇主， Day 公司如何从中获利呢？

DN: 回到 2001 年，我们是在那时启动的这个 JCR 规范进程。我们这么做是因为缺少行业标准，而且我们认为自己主要是一个必须自行开发内容仓库的应用提供商。我们完成了它。但是我们的客户非常不满意，因为他们所有有价值的内容被锁定到了一个专有的贮窖中。因此我们想确保我们为我们的所有内容应用（包括 Web 内容管理、数字资产管理和社会协作软件）都提供了一个基于标准的开放平台。既然缺少这样的标准，我们就有责任为我们的客户做这方面的事情。

因此，总的来说，开放和与标准兼容是我们内容应用的关键卖点。

同时，籍由我们介入 JCR 和我们以 Apache Jackrabbit 为中心的开源活动，我们开始销售名为 CRX 的高伸缩性和企业级商业全兼容内容仓库。

CRX 是一个在很多方面都非常令人震惊的产品，比方说，它允许仓库中全部细粒度内容以事务的方式被持久化成简单、老式的 tar 文件，在我们的压力测试中，这种方式要胜过传统关系数据库支持的持久化层好几倍。

InfoQ: 最近，有很多关于 Atom 和 AtomPub 的宣传，而且甚至有人声称它们要淘汰JCR 。您对此怎么看？

DN: 坦白说，我依旧很费解为什么人们认为这些协议和 API 是相互竞争的。回想起人们对比 WebDAV 和 JCR（顺便说一句，从特性集的角度看，我认为它是非常中肯的对比）的日子，当时我们在比较 HTTP 和 Servlet API。你不会听到有人说这样的话，“现在我有了 HTTP，为什么我还需要 API？”。程序员使用的是 API，而不是协议。

现在，将 Atom 与 AtomPub 和 JCR 作对比，从功能的角度看有点搞笑。尽管 Atom 与 AtomPub 提供了读写能力，但是 JCR 肯定在许多不同方面都超越了它们（搜索、锁、版本标定、访问控制等）。从技术的角度看，我认为 Atom 与 AtomPub 是 WebDAV 集合处理的轻量级（可能正是所需要的）替代品，但是仅此而已。

InfoQ: 但是，API 标准将解决方案绑定到了一门特殊的编程语言上（这次是 Java），这难道不是一个普遍的问题吗？难道我不想让内容可以被其他平台访问？

DN: 我并不认为这是个问题。它是一个特性。前面提到的协议允许以一种“平台中立的方式”来访问，不幸的是，这对开发者来说没有任何意义，因为他们将不得不自行编写封装解析器的 API。前面所说的 Servlet API 就是绑定到了 Java 平台，使得 Java 开发者能用 Http 进行访问。现在说 Servlet API 存在“普遍的问题”，就因为它被绑定到了一门特殊语言上，是不公平的说法。在内容仓库的世界里（与 HTTP 和 Servlet 的例子不同），我们缺少被广泛采纳的内容仓库协议。WebDAV 和 Atom 可能是最佳候选，但我确信将来在协议级别上会有被更广泛采纳的规范。我个人并不明白缺少优秀、被很好采纳的协议规范怎么就能被认为是 API 规范的缺陷。

我得高兴地说 JCR 已经被移植到了很多不同的语言环境，包括.NET、PHP、Perl，其中还包括 JavaScript。

InfoQ: 鉴于 REST 发明者 Roy Fielding 是 Day 的首席科学家，您对 REST 是怎么看的？

DN: 我认为我自己是“从小玩 Web 长大的”，某种程度上，我很早就开始使用 Web 了，在我学习传统应用开发技术之前，我就已经开始学习去理解和热爱 Web 架构。所以，我从未遇到过一般应用开发者碰到的问题，即让 Web 去适应他们有状态的应用开发范式。我是遇到的是问题的另一面，让应用去适应我的 Web 世界。

所以，当我初次见到 Roy 的时候，我就意识到我们已经将我们的应用按照 restful 架构构建了，只是不知道或正式地称之为 REST。只是觉得它是当时唯一自然的架构风格，当然，到现在也是一样。因此，你可以把我认为是一个“REST 的忠实信徒”或起个其他什么时髦的外号，亦或只是把我叫做“Web 小子” 以区别于“App 小子”。当然，Roy 在 2001 年发表的博士论文中对 REST 架构风格所做的形式化工作是 Web 社区非常重要的资产，我对大众花了如此长的时间来认识到它价值感到惊讶。

InfoQ: 如果可能的话，JCR 是如何与 REST 联系的？

DN: 在我看来，JCR 和 REST 在很多不同方面有关联。首先，两者都是以信息为中心的，而且都支持按层次方式处理信息。因此，JCR 的路径可以很直观地与 URL 对应，就像文件系统中的路径一样。我们首先进行的尝试之一就是将所有 JCR API 调用映射到 WebDAV，提供一个远程、RESTful 方式的 JCR API。

这样做不仅确保了从特性角度看我们在向 WebDAV 靠齐——这很重要，而且也表明我们没有违反 REST 架构风格所施加的任何约束。

对基于静态文件系统的网站来说，URL 到文件系统的映射非常自然。只要我看看 URL，我就非常清楚发生了什么。这是由于层次型的文件系统路径到 URL 的映射非常自然、直观。内容仓库令支持层次结构的存储得到了回归，并允许这种非常直观的映射。

我认为，JCR 是以 Web 为中心、面向 REST 应用的理想信息存储方式。

InfoQ: 您能给我们提供一些关于 Apache Sling 的背景资料吗？为什么这个世界需要另一个 Java Web 框架？

DN: 要是唱反调，我会假设这一立场，我还没看到一个 Java“Web”框架。

我认为，这个世界充满了那种将它们的服务暴露给“Web”的 Java“应用”框架，但是我真不愿意把它们称为“Web 框架”。

我一般认为，缺少一种并不把 Web 的无状态架构视为异端或不仅仅将 URL 认为“只是一个字符串”的框架。Sling 真的不是另一个“Java 应用框架”，而且也并不想成为它们中的一员。Sling 是首个我所看到的不仅遵循 Web 的基本原则和约束，而且实际上对它们“感觉良好”的“Web 框架”。

我们喜欢 Web 方式，并不想只要有可能就通过注入会话或延续（continuation）来绕过这些基本原则。我认为 Sling 和现有应用框架最大的一个区别就是它们和 URL 的关系。在象 J2EE 或 Struts 这样的现有应用框架中，URL 主要用来表示你的脚本或控制器（.jsp、.php、.do），并传入执行某个操作的参数。因此，你最终会得到一个丑陋的 URL，如…/view.jsp?id=123465，这当然不是面向资源的。在更加现代的框架中，人们开始更灵活地应用 URL，将它“视为一个字符串”，如允许使用正则表达式分割 URL。

虽然这支持一个更面向资源或甚至是 RESTful 架构，但是它绝对没有让人们按正确方式办事。它只是给人们更多的选择，而且在很多情况下，选择或让我们说缺乏好的缺省行为，都是不好的。

Sling 非常特别，因为 Sling 背靠内容仓库，暴露的层次名字空间可以非常自然的映射到通过一个 URL 暴露的名字空间，同时人们仍然能完全控制 URL，它还非常清楚地指导人们如何将他们的内容节点以一个设计良好的资源暴露出来。Sling 使“Web”回归了“Web 框架”。

InfoQ: 我必须承认，我还未曾看到非层次 URL 就是一个非 RESTful 的论点。Sling 对 REST 的其他方面支持如何，比如超媒体？

DN: 本质上，URL 的层次结构和 RESTful 没任何关系。回到网站还仍然是文件系统的日子里，URL“/news/newsitem.html”表示 “newsitem.html”位于文件系统某处的“news”文件夹显得很合理。增加一个归档文件夹或另一个新闻项目非常直接，因为层次 URL 的映射非常透明。当然，Web 服务器虽然给你所有可能去进行疯狂的映射，但是这种简单活被以非常简单直观的方式解决了。Sling 采用了和这完全相同的做法，其中 URL 的路径缺省被映射到内容仓库中的一个节点。当然，Sling 允许你去部分或完全控制 URL，但是我认为提供一个简单、直观和非常强大的缺省映射（一种验证过、伸缩性和拥护最佳“Web”实践的做法）是非常重要的。只是提供给开发者完成自己的 URL 空间映射的能力根本没什么用处，因为这将是我在项目启动时必须解决的第一件事，而且每个开发者的映射方式都千奇百怪。

大体上，我愿意说，Sling 在鼓励使用构成 REST 架构的 4 个约束方面干得非常好。这可能是最重要的区别，尽管其他应用框架可能允许你构建 RESTful 应用（如果你真的花时间的话），但 Sling“建造”的目的就是为开发 RESTful 仓库支持的 Web 应用提供完全开箱即用的支持，而且使得想忽略 REST 架构都难。

InfoQ: 非常感谢接受采访！

David Nuescheler 是位于瑞士的 Day 软件公司的技术战略和产品开发负责人。他是 JSR 170 和 JSR 283（Java 技术的内容仓库 API）规范的组长。他的小组已经为标准化内容仓库市场奋战了超过 4 年的时间。David 还是 Apache Jackrabbit 项目的提交者和 Apache 软件基金成员。