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软件基金成员。