中科院分区和jcr分区_David Nuescheler关于JCR和REST

中科院分区和jcr分区

InfoQ：您能给我们快速介绍一下JCR / JSR-170吗？

David Nuescheler（DN）：我认为这可以归结为解释内容存储库的功能集。

通常，在一个句子的描述中，我总是将“内容存储库”描述为“关系数据库”和“文件系统”中的“两全其美”，再加上我们一直错过并必须构建到我们自己的应用程序中的所有好东西。

这包括事务，可伸缩性，数据库方面的查询，非常适合大型文件，流，访问控制和文件系统方面的层次结构，以及版本控制，全文搜索以及最重要的“数据优先”方法，这两个支持。

JCR是描述所有这些功能的Java API。

InfoQ ：您如何看待当今市场上的JC​​R？

DN ：在采用时，我始终认为重要的是要考虑API的双方，实现者和用户。

首先，令我兴奋的是，我知道在最初发布JCR两年后，就有十几个符合JCR v1.0（又名JSR-170）的存储库。 正如预期的那样，某些存储库通过第三方连接器兼容，但大多数已经开箱即用地交付了JCR兼容。 这包括主要的存储库供应商，以及新兴的创新存储库。 另一个令人鼓舞的事实是，已经有四个JCR的开源实现，我认为从实现方面来看，它显示了对规范的大力支持，并且可以与Java领域最广泛采用的规范相提并论。

更重要的是，在API用户之间的采用非常棒，我认为这是采用中更为重要的部分。 在许多方面，这才是真正推动每个人都希望的存储库合并的原因。 如今，每个新的内容管理计划都可以依靠基于标准的随时可用的内容存储库，而不是从头开始构建另一个“自己的”内容存储库。 对于应用程序开发人员来说，这意味着他们可以从项目开始就依靠访问控制，完整版本控制或全文搜索等功能。 我们每周都会在Apache Jackrabbit之上构建大量新应用程序，这是最易访问的内容存储库实施，我认为您不能夸大事实是，对于每个这些应用程序，人们都可能会构建新的专有内容在没有JCR的情况下，诸如Hibernate之类的资源库。

InfoQ ：您的老板Day如何将其货币化？

DN ：当我们在2001年开始JCR的规范过程时，我们这样做是因为没有行业标准，我们主要考虑自己是一家必须提供自己专有内容存储库的应用程序供应商。 我们做到了。 但是，对于我们的客户而言，将所有最有价值的内容锁定在专有的筒仓中是非常不令人满意的，因此我们希望确保为所有内容应用程序（包括Web内容管理，数字资产管理和社交网络）提供一个开放的平台。基于标准的协作软件）。 鉴于缺乏这样的标准，我们欠我们的客户一些帮助。

因此，通常来说，开放和符合标准是我们内容应用程序的主要销售功能。

同时，通过参与JCR和围绕Apache Jackrabbit的开源活动，我们开始出售称为CRX的高度可扩展且符合企业需求的商业性完全兼容内容存储库。

CRX在许多方面都是令人惊讶的产品，例如，它允许存储库中的所有细粒度内容以事务处理方式保存在简单的老式tar文件中，在我们的负载测试中，其性能优于传统的RDBMS支持的持久化层。因素。

InfoQ ：最近有很多关于Atom和AtomPub的嗡嗡声，甚至有人声称它们已经淘汰了JCR 。 您对此有何想法？

DN ：坦率地说，我仍然很难理解为什么人们认为协议和API在竞争。 我记得当人们比较WebDAV和JCR的时候（从功能集的角度来看，我认为这是更合适的比较），我们将比较与HTTP和Servlet API进行了比较。 您不会看到有人说“现在我有了HTTP，为什么需要Servlet API”之类的东西。 程序员使用API​​而不是协议。

现在从功能角度比较Atom和AtomPub与JCR有点开玩笑。 尽管Atom和AtomPub提供了读取和写入JCR的能力，但它肯定以许多不同的方式（搜索，锁定，版本控制，访问控制等）超越了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适应他们的有状态应用程序开发范例。 我来自另一端，必须使应用适合我的网络世界。

因此，当我第一次遇到Roy时，我意识到我们已经根据一个宁静的体系结构构建了我们的应用程序，甚至没有了解或正式引用REST。 感觉就像是当时唯一的自然建筑风格，当然仍然有这种感觉。 因此，可以说我是“全力以赴的RESTafarian”，或者是本赛季的绰号，或者可以说我是“网络专家”，而不是“应用程序专家”。 当然，在2001年Roy的论文中REST架构风格的形式化对于网络社区而言是非常重要的资产，我感到惊讶的是，公众花了多长时间才意识到其价值。

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”框架。

我认为世界上充满了Java“应用程序”框架，这些框架将其服务公开给“ Web”，但实际上我不会将它们称为“ Web框架”。

通常，我认为对于这样一个框架，存在一个空白，即没有将Web的无状态架构视为必然的弊端，或者比“仅仅是字符串”更注重URL。 Sling确实不是另一个“ Java应用程序框架”，也没有尝试成为一个。 Sling是我见过的第一个“ Web框架”，它不仅尊重Web的基本原理和约束，而且实际上对它们“感觉良好”。

我们喜欢网络，并且不要试图通过注入会话或延续来尽快规避基本的主体。 我看到的将Sling与现有应用程序框架进行比较的最大区别之一就是它与URL的关系。 在J2EE或struts等旧式应用程序框架中，URL主要用于寻址脚本或控制器（.jsp，.php，.do）并传递参数以执行某些操作。 因此，最终将出现类似于…/ view.jsp？id = 123465的丑陋URL，这些URL显然甚至都不是面向资源的。 在更现代的框架中，人们开始更加灵活地使用URL，而只是将URL“视为字符串”，例如允许对基于正则表达式的URL进行剖析。

尽管这允许使用更多面向资源的甚至是RESTful的体系结构，但它绝不会引导人们去做正确的事情。 它只是给了他们更多选择，在大多数情况下，这些选择还是让我们说缺少好的默认行为是不好的。

Sling非常不同，因为Sling由内容存储库支持，所以它公开了一个层次结构的名称空间，该名称空间非常自然地映射到通过URL公开的层次结构的名称空间，而这仍然使人们可以完全控制URL，这也为他们提供了非常清晰的指导如何以精心设计的方式将其内容节点公开为资源。 Sling将“网络”放回“网络框架”中。

InfoQ ：我不得不承认，我之前从未见过关于非分层URL不可RESTful的争论。 Sling在其他REST方面（例如超媒体）的表现如何？

DN ： URL的层次结构本身与RESTful-ness无关。 早在网站仍基于文件系统的时代，URL /news/newsitem.html显然是“ newsitem.html”文件，位于“新闻”文件夹中文件系统上。 添加归档文件夹或其他新闻项非常简单，因为分层URL的映射非常透明。 当然，Web服务器为您提供了完成疯狂映射的各种可能性，而简单的情况却以非常简单直观的方式解决了。 Sling采用了非常相同的概念，默认情况下，URL的路径映射到内容存储库中的节点。 当然，吊索允许您部分或完全控制URL，但是我认为提供简单，直观且非常强大的默认映射非常重要，该映射已被证明是可扩展的，并且遵循最佳的“ Web”实践。 仅向开发人员提供进入其自己的URL空间的映射的功能根本没有用，因为这是我开始项目时必须首先想到的事情，并且每个开发人员都将提出完全不同的映射

通常，我认为Sling在鼓励构成REST体系结构的所有四个约束方面做得很好。 这可能是最重要的区别因素，而其他应用程序框架可能允许您在确实花费时间的情况下构建RESTful应用程序，而Sling是“构建”来直接开发RESTful存储库支持的Web应用程序，因此很难忽略它。 REST架构。

InfoQ ：谢谢您的宝贵时间！

David Nuescheler负责瑞士Day Software的技术战略和持续的产品开发。 他是JSR 170和JSR 283（Java技术API的内容存储库）的规范负责人。 他的小组已经致力于标准化内容存储库市场超过4年。 David还是Apache Jackrabbit项目的提交者，也是Apache软件基金会的成员。

翻译自: https://www.infoq.com/articles/nuescheler-jcr-rest/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

中科院分区和jcr分区