背景
新英格兰大学启动了一个为期多年的基础建设现代化项目，这个项目的目的在于逐步取代已经过时的系统，并在尽量实现所有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 技术平台