背景
新英格兰大学启动了一个为期多年的基础建设现代化项目，这个项目的目的在于逐步取代已经过时的系统，并在尽量实现所有 IT 投资的回报最大化的同时提供尽可能多的 IT 功能项。这个项目牵涉到硬件升级、购买新软件、开发培训和操作团队的培训等等。这个现代化的战略性项目的中心在于实现一个面向服务架构（Service Oriented Architecture－SOA）。
SOA 是着重于分布式应用设计的总体平台架构方式，而非注重于特定技术。SOA 的关键的在于软件服务的定义和实现，不管服务的位置如何、所有权归谁，这些服务都直接映射到一个系统或若干业务过程服务，包括在运行时管理它们的接口和策略。SOA 的优点包括：相互影响的系统和平台之间的松散耦合、无处不在的基于企业标准的集成机制、支持按需（on-demand）创建复合服务、以及在提高操作效率的同时充分利用已有资产的能力。
图 1 面向服务架构
从传统应用的开发部署到基于服务方法的转变是巨大的，不可能在一夜之间就能完成。新英格兰大学的 IT 部门与凯捷咨询公司通力合作，描绘出了增量采用 SOA 的路线图。增量方式的一个优点是能够立马看到投资的回报，并且可以有目的地选择转换的顺序来最好地适应学校的短期和长期目标。本文将在下面的章节中向大家描述这个为期 6 个月的项目是如何利用 1060 Research 公司的 NetKernel 通过实现面向资源的企业服务总线（Resource Oriented Enterprise Service Bus）来启动 SOA 的采用过程的。
问题领域
高等教育机构不断承受着来自学生、员工以及校友的压力，他们要求高校提供各种各样的在线服务来适应这些用户人群逐渐养成的生活习惯，比如通过直观的用户接口和自动处理流程来提供实时的 7*24 小时的信息访问。同时，来自管理部门、督导委员会（steering committees）和控制开销的理事会的压力也越来越大。因此，像大学这样的高等教育机构的 IT 部门在对新功能进行投资时就必须更加机敏、更加注重实效。
大学 IT 部门支持的应用内容非常广泛，有 PeopleSoft 这样的非定制商业化（Commercial off the Shelf——COTS）产品、有创建于客户信息控制系统（Customer Information Control System——CICS）之上的大型主机遗留系统、以及使用 Oracle 应用服务器 Portal 构建的现代 J2EE Web 应用。另外，这些应用软件中有很多都与第三方应用服务供应商（ASP）交互，以此向数据仓库（DW）提供历史数据。在这个项目中，所有这些应用都必须与新的 SOA 方法进行集成和协调。
该大学之前曾经通过使用 IBM MQ 和 FTP 来集成业务系统。这些传统方式导致的结果是大量的点对点（P2P）集成，所有这些 P2P 集成在维护时需要付出很大的代价，并且导致客户和供应商紧密耦合。然而，现有环境已经使用了轻量级的消息交换状态传输（ message exchange state transfer——MEST）的方式，这给以后的进一步革新留出了空间。企业服务总线（ESB）是消息总线构架的一个子类型，它提供更解耦的环境，但在它的前期部署费用相对较高，ESB 的价值按时间呈指数增长，而扩展系统所需的花销却保持线性增长并且是可以预期的 1 。
该大学的 IT 部门有一个由专门的架构师和软件工程师组成的开发小组，他们中很多人都通过自己的职务成为了在高等教育领域专家。由于这个开发小组比较小，每个成员常常不得不在开发的过程中扮演多个角色，包括对软件的支持和管理。基于这个缘由，IT 部门急切需要一个可以实现以下要点的解决方案：
- 通过利用可复用服务和复合应用来满足日益增长的客户需求
- 减少或避免 P2P 集成
- 充分利用现有资源和技术来提高操作效率
解决方案
1. 总览
SOA 可以通过很多不同的模式和技术来实现。传统方式是选择 WS-* 规范中所列出的模式，而且可以从 Apache ServiceMix 这样的开源解决方案或 Cape Clear 和 Sonic Software 商业套件等广泛的技术产品中任意选择一种。不幸的是， WS-* 规范仍处于不停的修改中，并且开发人员不得不消化 1300 页的文档来得到技术细节，这足以让许多人望而却步。比如说，如果完全坚持遵循所有规范的话，实现一个 SOAP 服务需要以下这些步骤：
- 使用业务流程建模符号（BPMN）来对流程进行建模。
- 使用 WSDL 来定义服务接口，使用 UDDI（Universal Description，Discovery and Integration——统一的描述、发现和集成）库来注册服务。
- 使用从服务注册访问服务的 BPMN 来生成业务流程执行语言（BPEL）。
- 使用 WS-Policy 来定义访问服务的管理策略。
市场上的商业 ESB 套件都已经获得各方的评估，由于这个 IT 团队相对较小，最终团队决定寻找这样一个解决方案：这个解决方案最终在各系统间引起的矛盾或冲突要小；它所需要的创新要在这个较小的 IT 团队人力资源所能承受的范围之内；它不应该迫使团队使用依赖于唯一供应商的中央服务集权式模型。大学的领域是极具流动性的，拥有多变的流程、多变的应用、以及多变的集成，因而，它所需要的是能反映大学正真的自然特性的一个总体构架和策略。
由于消息请求在之前已作为跨大学的中心传输机制，团队决定选择 REST 类型或面向资源（Resource-Oriented）的方式来实现 SOA。 REST 基于一组较小的被广泛接受的标准，比如 HTTP 和 XML，这些标准不需要很多开发步骤、不需要很多工具箱和执行引擎。采用 REST 类型的方式来实现 SOA 的有三个最主要的优点：较低的开销、投入市场较快、灵活的架构。面向资源的方式在 REST 风格方式的基础上提供了更广泛的扩展和独立通信基础。 REST 设计模式提倡使用 HTTP，而面向资源的架构则支持将服务连接到 HTTP 以及诸如 JMS 或 SMTP 这样的通信协议上。
尽管有一些像 Codehaus Mule 那样的 ESB 实现支持 REST，但只有 1060 NetKernel 是建立在在面向资源的计算平台 2 （Resource-Oriented Computing Platform，“ROC”）之上的。面向资源计算的核心是将信息（资源）的逻辑请求从发送请求的物理机制（代码）中分离出来。使用 ROC 建立的服务被证实是小巧、简单、灵活的，并且和传统方式相比较需要实现的代码更少。这些优点决定了它是创建技术平台理想的技术选择。
2. 技术平台
NetKernel 是面向资源的中间件，它提供企业服务总线（ESB）核心功能：寻址、路由和数据转换，而且能够像服务注册编制（orchestration）引擎那样工作。NetKernel 能够提供很多特性，它能提供一些诸如 XML 转化、缓存管理、多线程处理和包括 HTTP 和 JMS 在内的多种传输协议等高级功能，而 SOAP 引擎使它能够提供传统的 web 服务。NetKernel 是异质企业集成的坚实基础。
从概念上来说，NetKernel 提供访问的资源是按统一资源标识符（URI）地址进行识别的。所有 URI 地址在一个逻辑地址空间中统一管理。基于 REST 的微核负责处理所有的资源请求，从地址空间中解析 URI 地址，并且返回该资源的表示。向微核发送的请求也可以被用来创建新的资源、更新或删除现存资源。
从物理上来说，NetKernel 系统是由模块组成的，这些模块通过 URI 地址暴露出公共服务接口和资源。和 Java EAR 类似，每个模块都包含源代码和资源配置。模块可以从逻辑上引入另一个模块的公共服务和资源，将它们包含到地址空间中。由于引入需要指出模块的逻辑名字并能够辨别出版本号，因此多个版本能够在同一个系统中运行和更新。服务请求通过传输器注入到 NetKernel 中，这些传输器是位于系统边缘的事件侦测器。服务的客户可以通过任何可支持的传输器，比如 HTTP 或 JMS 来发送请求。
图 2 技术平台
HTTP 是无状态请求 / 回复应用协议。request 消息结构包括一个命令、头部和体部。response 消息则由状态、头部和体部组成。客户和服务器间使用 TCP socket 交换这些信息。客户 / 服务器传输层可以通过使用 SSL 协议对两者间的交互进行安全保护，而消息本身可以使用加密和数字签名来确保安全。最后，客户可以通过使用 HTTP-Basic 或 HTTP-Digest 的鉴别机制 3 来进行鉴别。
JMS API 为平台提供了实现异步服务的平台。然而，该 API 需要提供者，在这个案例中，这个供应商是 IBM WebSphere MQ。IBM MQ 是面向消息的中间件（MOM），它在各应用软件间提供基于队列的通信信道。信道的使用点对点或 Hub & Spoke 拓扑来实现。除了传输消息，MQ 还能够处理工作流、流程自动化、数据转换、监控和管理。
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 来公布的话，那么同样的信息则可以作为加密的头参数来传递。
面向资源的服务可以使用 Maven 4 来构建，作为 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。
评论