[译文] 实现类Web应用灵活性的RESTful核心——第4部分——模式（下）

原文：A RESTful Core for Web-like Application Flexibility - Part 4 - Patterns

作者：Randy Kahle和Tom Hicks

出处：http://www.theserverside.com/news/1363803/A-RESTful-Core-for-Web-like-Application-Flexibility-Part-4-Patterns

 

[译文] 实现类Web应用灵活性的RESTful核心——第4部分——模式（上）

 

 

分层的应用

 

 

1060 Research（http://www.1060.org/forum/）上的论坛就是一个ROC应用的例子，其用到了三个层次，顶层完成表述的“聚合”（构造）；中间层理解诸如“主题（topic）”、“分组（group）”、“用户（user）”等等之类的领域概念；最低层访问关系数据库，持久化论坛内容。

让我们通过跟踪诸如论坛这样的应用的一个请求来看看分层工作是如何进行的[6].外部请求http://www.1060.org/forum/topic/374/1是对某个特定主题的一个RESTful请求，该请求到达HTTP传输器，接着该传输器向位于地址“resource:/forum/topic/374/1”上的资源发出了一个根请求，有几个应用都被托管在这一站点上，因此论坛的顶层模块使用了一个导出语句来声明所有以“resource:/forum/”开始的请求都应该传送给它：

 

<export>

      <uri>resource:/forum/.*</uri>

</export>

 

论坛应用的表述层映射请求地址以除去“forum/”部分：

 

<map>

      <match>resource:/forum/(.*)</match>

      <to>resource:/$1</to>

</map>

 

该请求随后被映射到一个模板化服务上，该服务使用的资源地址有一个“operand”参数：

 

<map>

      <match>(resource:/topic/.*)</match>

      <to>active:template-service+operand@$1</to>

</map>

 

该模板化服务创建HTML表述框架，然后向其通过参数“operant”接收到的地址“resource:/topic/374/1”上的资源发出请求，在解析这一请求时，解析过程进入包含了论坛应用层的模块中。在这一中间层中，请求解析得到一个微服务，其工作是处理与主题（topic）相关的请求：

<map>

      <match>(resource:/topic/.*)</match>

      <to>active:topic-service+operand@$1

</map>

 

主题微服务解析RESTful URI，然后发出一个访问数据库获取存储的主题信息的请求，数据库访问请求有可能看起来类似以下的这一串内容[7]：

 

active:sqlQuery+operand@resource:/topic-query+topic@374+entry@1

 

该请求最终在应用的最底层中解析，该层由返回被请求主题的表述的持久模块实现。重要的是要注意到，论坛应用纯粹在逻辑层面中使用逻辑层的结构来设计和组合而成，并没有Java对象、数据类型、缓存查找、传输协议或是数据库驱动程序被暴露在逻辑层面上，但他们确实存在于ROC系统中，当然，只是存在于物理层内部。

 

层之间的映射

 

位于应用各层之间的映射可以由位于地址空间之间的微服务来处理。例如，以下这一逻辑到逻辑映射的定义

 

<map>

      <match>(.*)</match>

      <to>active:mapper+operand@resource:/map-definitions+uri@$1</to>

</map>

 

把所有请求路由给一个“映射”微服务，为了完成它的映射功能，这一映射服务用到了一个包含了映射定义的资源（其地址是“operand”参数的值）。映射微服务会把请求的URI地址（作为“uri”参数传入）映射到另一个URI地址上，该地址由映射定义来指定。使用映射微服务而不是微内核的基于映射的正则表达式，就几方面的原因来说是有好处的：

Ÿ 请求到映射服务的路由的配置简单且易于理解，只需要一个映射规则，

Ÿ 映射微服务能够完成更具体和更多样化的转换，且

Ÿ 映射定义被包含在逻辑编址的资源中。

 

最后一点对于应用设计来说有着很有意义的作用，因为其意味着应用代码可以动态地设定一组映射定义。在这个例子中，逻辑地址“resource:/map-definitions”可以被映射到一个端点上，该端点依据当时的时间、操作模式、用户数或是其他的想要的条件返回不同的一组映射。而且，同样因为资源会被缓存，因此系统会全速运行直到资源包含的映射定义发生改变。

 

模式

 

除了分层之外，在逻辑层的内部还有许多令人感兴趣的架构模式可供选择。

模式（Pattern）是一组相关的架构概念的命名描述，是解决重复出现在许多不同语境中的问题的模板。在面向对象的系统设计中，模式是简明扼要地描述应用的整个设计的一种有力手段。模式在ROC应用设计的逻辑层中的作用也是明显的，有些ROC模式会为OO编程者所熟悉，有些则是ROC体系结构独有的。

在本节中，我们将说明在ROC应用设计中常见的几种模式：映射器（Mapper）、门卫（GateKeeper）、工具箱（Toolbox）和金线（Golden Thread）。

 

映射器和门卫

 

我们已经见过映射器（Mapper）模式，该模式使用微服务来把一个地址空间映射到另一个地址空间上，映射器模式的一个变体是门卫（GateKeeper）模式，该模式并不会改变请求的URI地址，而是确定是否允许请求进入第二个地址空间。例如，可以通过以下的映射来使用一个安全门卫服务：

 

<map>

      <match>(.*)</match>

      <to>active:gatekeeper+operand@resource:/policy.xml+uri@$1+credentials@...</to>

</map>

 

门卫服务通过或者重新发送传入的请求到映射地址空间（“接受”），或者因安全策略由于某种原因被违反（例如错误的当日时间、证书等等）而抛出异常（“拒绝”）来工作。在这个例子中，证书作为由“credentials”参数引用的资源而被传入。

 

工具箱

 

工具箱（Toolbox）模式是很有意思的，因为它只用到了地址空间映射。工具箱把微服务、资源和其他逻辑层的功能组合到了单个模块中，然后把他们作为一个“标准的”工具集暴露给用户。工具箱模块通过导入包含了各种各样的工具的模块，然后把它们的功能导出到一个单一的、组合在一起的地址空间中来完成这一工作。

工具箱模式的一个变体是筛选工具箱（Filtered Toolbox），其有着更严格的导出语句，可能不会“放行”所有到其导入的工具和服务的访问。

 

金线

 

另一种模式：金线（Gold Thread）利用了微内核所管理的依赖缓存。在正常的运作中，所有的资源表述都可以被缓存，并且只要它的依赖性保持有效的话（没发生改变且没有过期），那么就会一直保留在内存中。通常情况下，依赖机制在其应该重新检查依赖的资源时跟踪物理层发生的变化（例如文件修改），并通知缓存。

对于基本的依赖性来说，在逻辑的虚拟资源上跟踪也是有可能的。金线通过创建命名的虚拟资源并与把它们其他逻辑资源关联在一起来利用这一功能。例如，可以创建一个名为goldenthread:customer-table的虚拟资源，然后把它与所有由查询客户表的数据库查询创建的资源关联在一起；之后，当有对客户表的更新发生时，更新过程会简单地使这一goldenthread:customer-table虚拟资源失效，而这将会导致所有与golderthread:customer-table资源相关联的缓存资源被从缓存中冲刷掉。

黄线模式在所有的数据库访问都通过ROC系统进行的系统内运作良好，不过，在其他应用更新数据库的情况下，也有一个基于相同模式的优雅的解决方案。在这种情况下，触发器或者存储过程可以向系统发回一个RESTful请求（例如“http://www.mycomp.com/gt/customer-table”），该请求会被映射到一个内部端点上，然后该端点会使正在讨论的这一虚拟资源（本例中中是“goldenthread:customer-table”）失效。

金线模式还可以跨多台运了ROC应用的计算机工作，诸如日期时间这样的共享信息有可能会导致资源失效，不过一种高速、轻量级的消息协议能够明显地协调多台计算机之间的缓存信息。

 

ROC应用的例子

 

面向资源的计算系统并不是基于假设的，许多应用已经或者正在使用ROC来构建，其中包括：

商业的和政府应用：

Ÿ DeltaXML构建了一个基于Ajax的XML差异处理的示范站点

http://deltaxml.com/free/sandbox/

Ÿ 下一代的永久性URL系统（PURL）将会基于ROC http://purlz.org/ 和http://zepheira.com/news/releases/20070802.html

Ÿ 一个大型大学的企业服务总线（Enterprise Service Bus）：

http://www.infoq.com/articles/netkernel-casestudy

Ÿ  一个嵌入式的通讯系统：

http://1060research.com/customers/case_studies/edgetechnology/index.html

Ÿ Los Alamos实验室构建的数字图书馆通过ROC来提供服务的发现和资源的实现功能。

 

1060 Research的系列应用：

• 论坛http://www.1060.org/forum/
• 博客http://www.1060.org/blogxter/
• Wiki（beta测试中）
• 错误跟踪系统http://www.1060.org/bugxter/

 

小结

 

本文完成了用于应用软件开发的RESTful内核的研究工作，我们从最低一层（绑定）开始，最终结束于逻辑层，讨论了应用的编程、设计和模式。作者希望这一文章系列提供了足够的信息，能够激发起对这一构建应用软件的创新方法的讨论、思考和探索。

ROC方法目前尚处于早期阶段，不过，到目前为止，来自用户的反馈是非常积极的，现实世界的应用开发项目的结果表明，应用软件能够被迅速组装起来，并且表现出了在万维网中发现的那种理想的经济特性。我们和1060 Research的团队期望着能够找到面向资源的计算可以为软件系统的架构、设计、开发和维护提供的长期效益。

 

进一步了解

 

如上所述，我们所描述的系统并非是基于假设的，最终引向ROC的RESTful系统方面的研究1999年开始于惠普实验室内部，当惠普在2002年决定退出中间件业务的时候，1060 Research成立，继续ROC的研究和开发，NetKernel是这项工作的成果，不前已经发布了3.3.1版本。

如果你有兴趣了解更多关于ROC和NetKernel资料的话，可以从http://www.1060.org/download上下载一个工作系统（包括文档、应用服务器、脚本语言支持、开发工具和许多功能模块）。http://www.1060research.com上提供了可用的详细文档（包括指导性的视频），可以在http://www.1060.org/forum/上查看和参与NetKernel用户的讨论论坛。

今年，第二届NetKernel架构师周末（NetKernel Architects’ Weekend）将于2008年9月27日在美国弗吉尼亚州Fredericksburg的Mary Washington大学举行，在这一盛会上，1060 Research将会揭示下一代的ROC，其过去三年一直在开发中，将作为NetKernel 4.0发布。

 

参考资源

 

[1]      实现类Web应用灵活性的RESTful核心——第1部分

[2]      实现类Web应用灵活性的RESTful核心——第2部分

[3]      实现类Web应用灵活性的RESTful核心——第3部分

[4]      模块的标识符应该是全球唯一的，我们建议使用基于反向的DNS名称（例如urn:com:mycom:project1:workbench）的URN。

[5]      这一远程地址的资源表述也有可能会在本地缓存中找到，只要HTTP的头部指向它的时候它依然是有效的。

[6]      这一请求的跟踪是在一个原型的论坛应用中进行的，真正论坛应用的全部详细内容在1060论坛指南中有说明，该指南包括了NetKernel 3.3的具体细节。

[7]      为了准确起见，active:URI方案的语法要求其参数同样也是URI方案，因此数据库请求更有可能会写成这样：active:sqlQuery+operand@resource:/topic-query+topic@data:text/plain,374+entry@data:text/plain,1

[8]      参见维基百科条目：设计模式最初源自于架构模式的概念