3. 基于资源的服务
基于资源的服务提供与传输无关的无状态的资源访问。资源是信息的抽象。例如，一个学生的注册是可以用web页面、XML文档或PDF文件方式来表示的抽象。服务使用资源标识符（resource identifier）或地址来表示每个资源。资源标识符实际上是相对于统一资源标识符（URI）的。每个URI包含两部分：机制（比如HTTP和 FTP）和地址。URI的第二个部分是相对的。地址/domain/account/45322是相对的，除非它直接关联到一个机制，比如http，http://domain/account45322。
图3 面向资源的服务概念模型
服务定义了一系列在资源上可能发生的动作：创建、读取、更新和删除。此外，还有一些特定的动作可能会触发规则或者业务逻辑。当资源被请求的的时候，一个物理的、无法被修改的该资源的抽象表示会被返回。基于业务逻辑，比如客户的类型，返回的资源表示类型会因条件各异。比如，大部分后端处理需要XML文档，而前端处理则可能要求JSON对象。服务也能够接收到关于创建资源或更新现有资源的表示。最后，服务也能够接收删除资源的请求。
图4 面向资源的服务交互模型
传输通常存在于系统边界，当它侦测到事件发生的时候，它会发送一个对应的内部请求。例如，HTTP传输监听来自客户请求的URL，该URL会明确访问方式（比如，GET、PUT、POST和DELETE）。URL会被转换成内部相对URI，而访问方式则会被解析为一个动作。在通过JMS传输请求的情况下，URI和动作被当作消息头参数传递。另外，如果一个资源表示需要被返回，在回复的消息头部中会申明一个返回队列参数。
在REST风格的系统中，对资源的访问是无状态的，也就是说每个请求必须能够将内容作为元信息（meta-information）传递。总体来说，传输定义了一个包含头部和体部的消息结构。头部被用来传递元信息，而体部则被用来传递资源的表示。例如，如果一个面向资源的服务通过HTTP公布，那么鉴别信息可以在头部中传递；如果服务通过JMS来公布的话，那么同样的信息则可以作为加密的头参数来传递。
面向资源的服务可以使用Maven4来构建，作为NetKernel模块来打包。Maven是用来在一个“项目”的范畴内构建和管理软件的工具。Maven项目由项目对象模型（POM）XML定义。POM定义了软件的依赖性、构建流程和部署结构（比如JAR、WAR、EAR）。另外，Maven项目还能够被用来生成项目的网站和部署软件。在这种情况下，Maven在NetKernel模块中将服务打包，并将这些服务的相关信息发布到注册项中。
图5 面向资源的服务开发
4. 面向资源的企业服务总线（ESB）
面向资源的企业服务总线（ESB）是使用NetKernel来实现的。NetKernel的中心是一个REST风格或面向资源的微核，专门负责为物理代码解析逻辑URI请求并在空闲的CPU上安排执行请求。逻辑地址和物理代码的映射在应用结构中定义，实际的逻辑地址和物理代码的捆绑仅在请求处理的过程中发生，之后该捆绑被会自动废弃。
由于每个发送给微核的请求都会建立新的捆绑，所以系统管理人员可以在系统运行并激活了类似实时代码更新功能的环境下自由地修改逻辑地址和物理代码之间的关联。实际的性能似乎不会因为这样的迂回和捆绑而降低，但是当把URI地址作为NetKernel内部缓存的主键时确实可以提高性能。如果有资源被再次请求，并且依赖性没有受到任何修改的话，那么缓存的资源表示会直接被返回，系统无须再重新对其进行计算。
使用面向资源微核有几个主要的优点。首先，服务间交互在逻辑层而非物理层进行，这决定了松散的耦合交互，也因此减小了在物理层实现所做的修改对客户和服务供应方之间的影响。其次，请求结果是被缓存的，因而可以减低合成服务和编制的总体开销。比如，如果一组编制好的服务依赖于同一个服务，那么该服务背后的物理代码将很少被执行。最后，所有向微核发送的内部请求都是异步的，因此随着主机服务器CPU个数的增加，其处理能力也会线性增长。
ESB主要负责服务的供应和安全性。服务供应包括将面向资源的服务通过HTTP或JMS等传输协议公布给用户。传输层负责将外部URI和访问方法映射到一个内部的面向资源的服务和动作。略去传输不看，以XML文档或JSON对象形式构建的请求体会作为名为“param”的参数传递。带来的结果是，面向资源的服务从传输特定逻辑的细节中解耦，实际上，在任何时候添加额外的协议都不会影响到现存的代码。
图6 面向资源的服务供应
面向资源的服务依次去委托一组定制的基础服务和NetKernel提供的核心服务。NetKernel可以提供大量的核心服务，比如一些核心服务可以处理 XML和SOAP，CRON任务调度以及SMTP交互。核心服务可以极大地减少实现一个面向资源的服务所需要的代码量。定制基础服务则可以用来服务于高等教育领域。
每个向ESB发送的请求首先会加以认证，然后授权，有时候还需经过审计。传输器基于用户名密码组合认证一个输入请求，然后再将认证和审计委托给安全服务。授权的过程涉及到验证经过确认的用户拥有正确的权限，每个权限都包含一个相对URI和动作。举例来说，一个用户可以拥有读的权限，但没有更新和删除可以通过相对URI /domain/student/identifier/profile来标识的学生档案资源的权限。未授权的请求可以自动被审计，基于已认证用户或权限的审计也是有选项的。帐号、权限和审计信息存储于一个嵌入式Hypersonic数据库中。
图7 面向资源的服务安全
总结
和Actional或ManagedMethods等运行时服务管理解决方案不同的是，实现ESB所用到的中间件是任何SOA成功的必要条件。如果没有 ESB，机构只能单纯地通过使用web服务不断地添加P2P交互。然而对于ESB的组成和目的方面有很多不同意见，但得到大部分人肯定的是它的一组核心功能，包括服务寻址、消息转换和消息路由。使用NetKernel中间件实现的ESB不仅能够提供这些功能，还能提供一些像服务注册和服务编制等高级功能。
NetKernel产品使得大学能够实现一个面向资源的ESB。面向资源的ESB本质上来说是一个开放的基于标准的企业集成框架。该框架使得企业能够降低或者避免P2P交互的代价，减少向市场引入新功能的时间。再进一步来看，该框架比传统的基于WS-*标准的企业集成框架所需要的启动资金要少的多。此外，由于NetKernel和ROC提供的集成以每个服务为基础单位，该大学因此可以将集成功能推到网络边缘（比如URI），使其能够转化为更好的服务管理和更好的扩展性。简单来说，该框架为组织机构提供了比较独特的灵活的企业架构。
在六个月之内，由三个软件构架师组成的团队实现了一个面向资源的ESB，以及一些使用NetKernel中间件的初始面向资源服务。这个成功的ESB实现为大学启动了向SOA转化的步伐。面向资源的方式使得整个团队能够充分利用了现存的资源和技术。今后，该大学的IT部门已经有能力通过利用可复用服务和组合应用来应付日益增长的用户需要，同时也减少或避免了P2P的集成。
关于作者
Jeremy Deane是凯捷咨询公司的技术构架师。他拥有12之年多的软件工程领导经验。他的精通的领域包括企业架构（Enterprise Architecture）、性能工程（ Performance Engineering ）和软件过程改进（Software Process Improvement）。另外，他从Drexel大学获得了信息系统硕士，并在最近发布了一本白皮书——Document Centric SOA。
