学习如何为企业开发面向服务的体系结构（Service Oriented Architecture，SOA）移植策略，该企业的 IT 基础架构包括业务筒仓（silo）的单独业务线，并拥有许多集成的遗留应用程序来支持业务目标。本文包括开发成功的 SOA 移植策略所需行为的工作细化结构范例，最终生成符合 IBM 客户合约中 SOA 原则的实际应用程序。
SOA 介绍
自从 Gartner Group [1]提出面向服务的体系结构（Service Oriented Architecture，SOA）和企业服务总线（Enterprise Service Bus，ESB）以来，这些术语已经用了好几年了。然而，应用 SOA 解决方案的实际细节仅仅是最近才出现的。
那么，准确地说面向服务的体系结构是什么呢？“SOA 是一种组件模型，它通过应用程序功能单元（称为服务）之间定义完善的接口和契约，来联系应用程序中的不同服务。”[2]。通过以上的定义，当提取应用程序作为服务时，SOA 是在应用程序之间构建企业级集成层的模式集。SOA 解决方案提倡使用开放标准，然而当集成应用程序时，在某些地方还是需要使用专有技术。
SOA 依赖于将应用程序功能发布为服务，这些服务可被外部各方调用。通常，对 SOA 服务定义的一致观点是[3]：
- 服务通过明确的、与实现无关的接口来定义。
- 服务被松散绑定，并且可以通过强调位置透明性和互操作性的通信协议进行调用。
- 服务封装了可重用的业务功能。
服务可存在于不同的级别上，并提供不同的粒度。通常认为有以下服务级别[4]：
- 技术功能（例如，日志记录）
- 业务功能（例如，getCustomerInfo）
- 业务事务（例如，openAccount）
- 业务流程（例如，processOrder）
每一个粒度级别可能都需要一些合成度。在每个粒度级别上，服务定义以可复用的方式封装其功能是很重要的。
将应用程序功能发布成服务使应用程序可以高效解耦，这是 SOA 的一种需求。通过接口将功能发布成服务，该接口将针对这项功能创建会话虚包（faÇade）。可以通过直接修改应用程序或者通过创建适配器（将请求转换成特定于应用程序的调用）来创建这样的接口。
当应用程序功能作为服务公开时，创建服务消费者和提供者之间路由消息的机制是很重要的。SOA 解决方案通过使用企业服务总线（Enterprise Services Bus，ESB）来满足此需求。企业服务总线是为各种服务请求者和服务提供者提供连接层的一种消息代理，它确保二者之间合适的消息路由。服务请求者是组件，它调用由服务提供者发布的服务来实现内部逻辑。
虽然 ESB 最重要的任务是提供连接框架，但它也提供现代 IT 所需要的合适的服务级别和可管理性。实质上，ESB 允许在基于 SOA 的架构中集成服务，并提供“服务请求者和服务提供者之间使用分布式中介功能的单一管理点”[4]。
ESB 在服务请求者和提供者之间提供松耦合，允许用一个服务实现来替换另一个，而且不会对该服务的消费者造成影响。
在 ESB 提供了服务之间连接性的同时，其他 SOA 组件也提供了对发布、发现和调用服务的支持。这些组件包括业务服务目录、业务服务编排和 ESB 网关。然而，这些组件的部署需要根据实际的业务需求来决定。举个例子，许多较小的企业可能发现他们实际上并不需要 ESB 网关，因此，将不必建立这些网关，导致架构过于复杂。
业务服务目录提供 ESB 所依赖的服务路由信息，同时支持服务请求者和提供者之间的通信。然而，业务服务目录的主要任务是提供服务细节，这些服务细节可用于执行基础架构所支持的业务功能。实质上，业务服务目录是服务消费者寻找支持他们操作的服务的地方。
在业务服务目录提供关于现有服务的信息的同时，业务服务编排组件允许通过现有的低级服务组成新的服务。例如，可以通过定义包含几个较低级别业务功能的工作流来创建新的业务事务。这样的工作流成为新的服务，并发布在业务服务目录中。
开发 SOA 移植策略
许多提供多种服务的大企业如今发现，他们的 IT 已经被严重拆分。主要是因为许多企业选择允许每个业务部门维护它自己的 IT 需求，而不是依赖于集中管理的 IT 组织。因此，许多部门只创建与自身相关的应用程序。通常，公司可能有一些账单、帐目管理以及类似的支持不同业务方面的系统。而且，许多公司希望安装“最佳”软件，而不考虑同其它应用程序的集成。后来他们发现，将新的应用程序加入 基础架构时经常需要特定的方案。下面的图 1 正是目前一些企业中 IT 基础架构的例子：
图 1.常见的遗留企业 IT 基础架构
从上图中可以注意到一个 IT 难题，那就是大多数应用程序之间直接相互通信。当应用程序需要修改或淘汰时，这种依赖便成为一个实际问题。任何修改都可能会按其自身的方式更新每条唯一的通信线路。因此，这种变更可能代价高昂。这种情况被称为应用程序间的紧耦合，也逐渐成为让一些企业头疼的问题。
另一方面，SOA 将松耦合作为成功的企业级应用程序集成的一个主要原则。与紧耦合相反，松耦合是：
限制请求者应用程序代码和提供者应用程序代码的相互了解。如果耦合的服务任何方面有所变化，那么，请求者或提供者的应用程序代码（更可能是两者同时）必须改变。如果任何一方（请求者、提供者或中介基础架构）对解耦的服务任何方面作出改变，那么其它几方不必随之改变。[5]
图 1
也示例了当在几个业务区域内部署具有所需功能的应用程序时（例如，应用程序 1 和应用程序 1'），一些企业所采用的实践行动。通常，用每个部署稍微修改应用程序以满足特定业务区域的独特需求。虽然让多个应用程序具有相同功能并没有明显的缺点，但它们的存在可能表明：
- 企业中可能存在数据副本，这会影响操作数据的准确性。这是由以下原因造成的：大部分此种应用程序依赖于相同的数据源， 且为了性能或其他原因，一部分数据被本地存储。
- 维护多个应用程序比支持单个解决方案需要更高的花费。
- 当对这些应用程序进行合并，以减少对那些与被淘汰的方案互相依赖的应用程序的影响时，需要特别注意。
通过采用 SOA 原则在企业级别上成功集成应用程序可解决这些问题。
值得注意的是，当企业还未被深入划分时，应用 SOA 是合理的。然而，当公司内 IT 部门的数量很多，而且它们托管的应用程序数量更多时，实现基于 SOA 的企业体系结构将是一项具有挑战性的工作，需要精心规划。
将复杂的深入划分的企业分割成一些单独的域，事情可能会变得容易很多。第一，通过 ESB 发布特殊的应用程序服务，每一个域可以与企业其余部分解耦。第二，以后域内的应用程序可以启用 SOA，而不会影响企业其余部分。
按照业务功能（例如，销售、账户管理、客户服务等等）或实现（比如大型机和 Unix 服务器）来对域的划分进行组织。然而，实质上，域将包含更紧密连接的应用程序，因此，相比它们与企业的其余部分的关系，这些应用程序彼此之间将具有更严重的依赖性。
如果一组服务属于单独的域，那么可用下列准则来定义：
-
功能域是基于业务功能选择的。这些域中的服务消费域外部的有限数量的服务，并对外部公开有限数量的服务。
-
基于技术的域根据所利用的一系列技术来选择。这些可能包括大型机应用程序、分布式应用程序等等。
-
基于应用程序的域是紧耦合的应用程序集合。共享相同数据库的电子商务应用程序或大型机应用程序的集合是这种划分的一个例子。
域的初始划分也可以是纯概念上的，对那些需要作为服务向企业其余部分公开的应用程序功能进行确认。
一旦确认了服务，需要通过使用网关和防火墙建立明确的边界，从而使域彼此分离。这种分离提供了对应用程序交互的更好的控制，并可进一步对应用程序进行灵活的变更，而不会对企业其余部分产生重大影响。这种分离可通过几种不同的方法实现：
- 将公开域功能的业务功能定义为粗粒度服务：业务功能由企业需求驱动，而并非内部的实现细节。业务功能可以在域内部调用细粒度的技术服务，对外部消费者提供服务。定义业务功能的主要目的是限制域之间的交互。
- 添加网关可以将一个域设定转换为另一个域设定：通过添加更好的控制功能，网关也允许在外部实体间（例如业务伙伴）建立明确的界限。通常，网关可与业务功能合成为一个逻辑实体。然而，添加网关是由业务需求决定的，如果域共享相同的设定就不需要添加网关。使用下列方法之一可以实现网关：
- 透明/代理网关以消费者认为能直接与业务功能进行交互的方式公开域服务。这种网关也可以基于企业基础架构需求对输入和输出的消息进行转换。当域数据以非常特殊的格式（与企业级约定完全不同）存储时，需要进行转换。例如，按照企业策略，特定于域的二进制数据可能需要转换成 XML。
- 防火墙允许增强对域的封装。尽管，防火墙不去执行任何转换，但是它们限制消费者仅能访问域边界内预先定义的点。而且，防火墙的引入提供了对不遵循域的封装规则的服务进行检测。
分析发布到域外部的应用程序功能时，会发现实际的服务是细粒度功能的结合。将应用程序功能编制为业务服务的一种机制是引入本地服务总线（Local Service Bus，LSB），将服务编排组件添加到这些域。
本地服务总线是为单个域提供连接支持的企业服务总线的实例。通过服务编排组件进行扩展，使域可以组成 ESB 可消费的更高级别的业务功能。
下面，图 2 演示了以上步骤生成的基础架构：
图 2.已定义并分离的 IT 域
一旦封装了所有的域并公开了业务功能，通过 ESB 对其集成，并采用业务编排来创建更高级别的业务流程和事务就变得更加容易。一旦 ESB 是到位并且企业正在使用，就可以对域内遗留应用程序进行移植，且对企业其余部分影响很小。
下面（表 1）的工作细化结构范例描述了企业将遗留基础架构移植到基于 SOA 的企业体系结构所需要采取的主要步骤。尽管实际的任务清单是特定于对具体企业的，但是下面的清单为需要考虑的内容提供了一种思路。
表 1. 工作细化结构
|
ID
|
任务名称
|
| 1 |
SOA 移植规划 |
| 2 |
管理 |
| 3 |
项目管理 |
| 4 |
技术管理 |
| 5 |
实现活动 |
| 6 |
收集信息 |
| 7 |
协商 |
| 8 |
文档分析 |
| 9 |
创建文档 |
| 10 |
评审 |
| 11 |
分析 |
| 12 |
功能方面 |
| 13 |
收集信息 |
| 16 |
创建信息 |
| 17 |
评审 |
| 18 |
技术方面 |
| 19 |
收集信息 |
| 22 |
创建文档 |
| 23 |
评审 |
| 24 |
应用程序方面 |
| 25 |
收集信息 |
| 26 |
协商 |
| 27 |
文档分析 |
| 28 |
创建文档 |
| 29 |
评审 |
| 30 |
域方面 |
| 31 |
信息分析 |
| 32 |
创建文档 |
| 33 |
评审 |
| 34 |
规划变更 |
| 35 |
ESB 规划 |
| 36 |
开发 ESB 组织原则 |
| 37 |
工作量估计 |
| 38 |
创建文档 |
| 39 |
评审 |
| 40 |
LSB 规划 |
| 41 |
开发 LSB 组织原则 |
| 42 |
工作量估计 |
| 43 |
创建文档 |
| 44 |
评审 |
| 45 |
相关性规划 |
| 46 |
相关性分析 |
| 47 |
创建文档 |
| 48 |
评审 |
| 49 |
接口规划 |
| 50 |
接口开发 |
| 51 |
创建文档 |
| 52 |
评审 |
结束语
基于 SOA 的企业体系结构的方法使得在对企业 IT 基础架构进行变更时，相关的移植风险更小。通常，公司认识到支持旧的基础架构是代价高昂的；然而，剧烈的变化是很有风险的。将企业划分为多个域，并引入本地服务总线（Local Service Bus）的概念可以减轻风险，并可用良好可控制步骤来将其移植到新的基础架构中。
请记住解决方案只可以被有效地应用于不同类的环境中，这点非常有用。同类环境不太可能从这种策略中获益。