级别： 初级 Kim J. Clark, IT 专家, IBM
Brian M. Petrini, 高级 IT 架构师, IBM
2009 年 9 月 28 日 本文介绍了如何使用 WebSphere® Process Server 和 WebSphere Enterprise Service Bus（WebSphere ESB）设计基于面向服务架构 (SOA) 的解决方案。本文是系列文章的第 1 部分，探讨了随着 SOA 的不断成熟，设计技术出现的新变化。
简介
 | |
关于 WebSphere Process Server 和 WebSphere ESB 的更多技术资源，请参考：
|
|
本文是讨论如何使用 WebSphere Process Server（以下简称为 Process Server）和 WebSphere Enterprise Service Bus（WESB）设计解决方案的系列文章中的第 1 部分。本文侧重介绍在面向服务架构不断成熟过程中的不同阶段，如何以不同的方式使用 Process Server。为了展示设计的高层视图，我们使用了
WebSphere Integration Developer 内的这些新的 解决方案视图。
本文是涵盖 Process Server 解决方案的关键设计方面的系列文章的一个部分。本系列其他文章的内容预告在本文末尾处给出。
当架构不断向 SOA 的方向演进，“集成” 是如何随之改变的？
创建一个面向服务的体系架构（SOA）从来都不是一蹴而就的，而是一个逐步成熟的过程，其中每一级别的成熟度均建立在上一级别之上。之所以如此，有几个原因十分关键：
- 您很少甚至基本不会从头创建一个架构，不可能在一次实现中就得到一个理想的架构。实际上，有现成的基础设施、包和遗留应用程序可供您使用。
- 没有任何一个项目能够负担显著 完善一个架构所需的成本和时间。它需要一个长期项目的广泛影响。
- 此应用程序架构中并非每个部分都具有一个被良好治理的 SOA 所需的严密性。有些部分转变为成熟 SOA 的过程会更慢一些。在任何一个给定点，架构都将是新老风格的混合体。
我们并非创建一个 SOA，而是逐步演变得到一个 SOA。演变过程中的每一个阶段都需要经历漫长的时间来变得更加成熟和稳定。
所有这些与 Process Server 有何关系呢？很多产品在 SOA 成熟过程的特定阶段都发挥着各自的作用。在这方面，Process
Server 尤显特殊，因它具有与开发的很多阶段都相关的一系列宽泛的功能。为了理解如何有效使用 Process Server，需要理解在成熟的每个级别，产品的哪些部分以及使用哪些风格才是适当的。
接下来，我们来看看度量一个企业当前成熟度和目标成熟度级别的标准机制，然后再讨论在各个级别如何使用 Process
Server。
Service Integration Maturity Model
Service Integration Maturity Model (SIMM)，如图 1 所示，是一种广为接受的用来表示架构以及更宽泛的业务向 SOA 转变的各进展阶段的方式。
图 1. SIMM 的图示
在决定使用什么举措（实际上，就是软件）来影响更改之前，非常有必要理解组织在这种场景内的位置以及其目标在哪里。
让我们来看看在 Process Server
解决方案中的情景。
有关 SIMM 还有最后一点需要说明，即本文只着重探讨 SIMM 的一小部分 - 架构层和应用程序层 - 尤其是集成中间件方面。SIMM 的范畴远比此宽泛。更为全面的介绍，请参见本文末尾的 参考资料 部分。
Process Server 及 WESB 在成熟模型中的作用
理解了成熟度的不同进展级别后，我们来探讨 Process Server 的核心功能以及这些功能与 SIMM 模型的关系。表 1 给出了在成熟度的不同级别所使用的不同类型的解决方案。
表 1. 不同的解决方案类型
|
解决方案类型
|
描述
|
与 SIMM
的关系
|
相关的 Process Server
组件？
| | 低层的连接性 | 本地端口、数据格式、API | Level 2 |
| | 基于 Hub 的集成 | 改进的弹性、可消费性以及粒度。中心辐射（Hub and spoke）。 | Level 3 | 中介流组件 | | 服务公开 | 标准化协议、数据格式、服务协议和策略 | Level 4 |
| | 复合服务和业务流程自动化 | 成熟服务的安排和编排 | Level 5 | Business Process Choreographer (BPC) -
比如，Process Server 内的 Business Process Execution Language (BPEL) 引擎。 | | 工作流和基于任务的解决方案 | 通过任务分发作业 | 多种，详情见后。 | Human Task 和 BPC |
让我们逐一看看这些成熟等级以及各个解决方案。
Process
Server 解决方案中的各个不同的成熟度等级
接下来的几节将讨论在试图实现各成熟度等级的目标时，Process Server 解决方案是何样子。
低层连接性 - SIMM 级别
2
这些解决方案借助本地端口、API 以及数据格式使用额外的代码或配置提供了与后端系统的连接性。各组织纷纷开始在 SIMM 级别
2 构建这种能力。起初，它们将连接性代码写入其后端应用程序。后来，它们逐渐开始采用打包的适配器。人们现在对这个领域的技术已经有很好的理解了，比如，由被打包的系统提供的 API、面向常用后端平台的产品化了的适配器以及面向已被确立的数据格式（比如 COBOL
copybook）的数据处理程序。
图 2. 点对点连接
所有这些通信都是点对点的，如图
2 所示。随着引入的请求者和提供者的增多，所需编写的连接性代码就会呈指数增长，进而很快就会变得很难维护。
基于 Hub 的集成（基本）-
较低的 SIMM 级别 3
Process Server 或 WESB 的一种最为简单的应用就是在无现成的常见连接技术时，作为一个 hub 来连接请求者和提供者。hub 的出现标志着
SIMM 级别 3 的开始。
这完全可以在 WESB 内实行，因为它只涉及了一个中介流组件和几个 WebSphere Adapter，如图 3 所示。在这个成熟等级，通常在每一端都会有适配器，前提是请求者和提供者均不能隐式地执行基于通用标准的连接性。这意味着这个解决方案特定于此请求者和提供者，而重用又需要更多的适配器和映射。
图 3. 面向基本集成场景的解决方案 - 一个单一的中介流组件
对于在左侧导出上所发出的给定请求，只有一个请求被成功送至导入并继续被送至右侧的提供者。Process Server 在这里惟一的作用是提供低层的连接性以便请求者可与提供者进行通信。由适配器负责进行大多数艰苦的集成工作。
图 4. 图 3 所示中介流的内部
此中介流组件（图 4）执行请求者数据模型与提供者数据模型间的映射，并且还可以针对诊断或审计的目的进行进一步的日志记录。
注意：虽然我们这里进行的是一对一的连接，但是我们并不能将此描述为 “点对点”（比如，SIMM 级别 2）。这里有 hub 出现的事实恰恰表明了这是 SIMM 级别 3，因为我们已经有了某种机会来重用这个集成。Pure
级别 2 是一些位于请求者/提供者应用程序之内或者靠近这些请求者/提供者应用程序的定制代码。
基于 Hub 的集成（高级）-
较高的 SIMM 级别 3
简单的集成很快就显得不够了。额外的集成模式需要被应用到低层的连接性，以使通向后端系统的接口更具重用所需的弹性、可消费性和合适的粒度。
通过 hub 连接起来的多个请求者和提供者的出现，会导致中心辐射 架构模型（图 5），这对更高级的 SIMM 级别 3 解决方案来讲十分典型。这主要由中介流执行，虽然在某些情况下，可能还会使用 BPEL 过程。通常，请求者和提供者经适配器连接。
图 5. 中心辐射解决方案
有人很可能会顺理成章地想如果公开给请求者所用的协议是一种标准协议，比如 HTTP/SOAP 或 HTTP/REST，我们通过提供一种明显可重用的公开服务就可立即升级到 SIMM 级别 4。在有关
服务公开 一节，我们将会看到事情并非如此简单。
这个看似简单的图（图 5）隐藏了很多变数。让我们逐一考虑：
-
路由器：对于给定的一个请求，每个请求者被路由到一个特定的提供者。
-
转换器：设置多个请求者以将它们的请求路由到特定的提供者。
-
低层复合：每个请求者使用多个提供者进行请求。注意这不同于我们后面将要讨论的服务复合。在这里，我们使用传统的连接后端系统的低层接口而不是成熟的服务来创建复合解决方案。
上述这些因素的综合也是可能和常见的。多个请求者可以将其调用转换 后，再路由 到不同的组件，由这些组件执行一个适当的低层复合 以完成这种交互。
请考虑对于上述这些不同的情况，解决方案应如何被相应分解。让我们先来看看图 6 中所示的路由器。
图 6. 基本的路由器解决方案
假如，我们有不止一个提供者，并且我们可以使用一个中介流组件来在它们之间进行选择。中介流可以使用一个消息过滤器来执行，比如，基于内容或头的路由，如图 7 所示。一旦提供者选定，就会完成一个特定的数据转换以便转换为提供者的数据模型。
图 7. 基本路由器 - 图 6 所示的中介流组件内的中介原语
现在，让我们将之与转换器（图 8）进行对比。它处理来源不同的两个请求并转换它们以便它们能调用同一个后端提供者。
图 8. 基本的转换器
注意到，我们为两个不同路由使用了两个不同的中介流组件。实际上，完全可以使用一个中介流组件。由于这两个不同的入向路由通常具有不同的特征，所以最好将二者分离开。这样一来，二者就可被分别开发和维护，而且各自的责任也会十分清晰。正如您稍后将要看到的，如果它们的交互较为复杂，甚至可以让它们拥有自己的模块。
现在，有意思的是我们一并添加了转换器 和路由器 样式（图 9）。记住，这些请求者各自都有其自己的数据模型，提供者也是如此。如果我们过于简单地处理这一点，那么对于每个请求者，您都需要将请求者的数据模型直接映射到每个提供者。如果有多个提供者，要创建的映射的数量将会呈指数增长 - 类似于我们之前在 SIMM 级别 2 内竭力避免的混乱情况。我们没有很好地利用具备中心 hub 的种种好处，因为我们还未引入中心或标准 数据模型。
图 9. 综合的转换器/路由器解决方案（参见图 9 的放大图）
在上述示例中，入向中介流组件转换成我们的标准 数据模型，然后，路由器中介流组件执行针对每个提供者数据模型的可重用转换。标准数据模型意味着所需编写的映射将更少，并且如果请求者或提供者的数据模型要更改，它只会影响到与这个标准模型的特定映射。
让我们继续讨论复合（图 10）。我们需要能够将几个请求集中起来提供给后端系统。
图 10. 利用
BPEL 过程进行复合（参见图 10 的放大图）
使用一个中介流组件和一个或多个服务调用原语可以执行某种程度的对提供者调用的聚合，并且对于简单的情况，这可能就是正确的解决方案。如果要执行的逻辑明显是集成逻辑，比如数据充实或简单聚合，这将十分合乎情理。如果您能够将数据格式保留为 XML 并在无需解析对象的情况下就获得 XSLT 转换的益处，那么使用中介可能会带来性能上的优势。然而，即便是向复合内引入了少量复杂性也会突然让人更愿意转而使用
BPEL。比如，如果需要较复杂的条件逻辑、循环流程、补偿功能、状态的一致或是过程中的人机交互。在这些情况下，可以为解决方案使用 BPEL，尤其是当从监控的角度看，过程本身也与业务有关系时。
如果使用 BPEL，重要的是 BPEL 要控制高级步骤，而不是被用作一种可视编码语言来执行低层逻辑。这也是我们将中介流组件保留在图 10 中的适配器旁边的原因。这就确保了所有可能的集成逻辑均从 BPEL 过程中提出。BPEL 的一个优势是它的开发时和运行时的可视性。如果在使用 BPEL 时发现事情有变复杂的迹象，那么可能需要将该细节推出给中介或是提供者应用程序。
使用 BPEL 的这个解决方案不同于在 SIMM 级别 5 内使用 BPEL 的那些解决方案，在 SIMM 级别 5，服务更为成熟。其中的一个主要问题是面向提供者的这些接口并未被恰当成熟化和公开，所以要执行的集成逻辑将会明显复杂很多。由于这个低层集成很复杂，所以很有可能该解决方案实现起来要比一个对等的级别 5 解决方案更为昂贵和耗时。当然，这也是为何您想要在下个阶段，在架构内成熟化服务的原因所在。
注：我们一直在讨论服务成熟性，但我们几乎未曾提及术语服务。这非常重要，并且完全是有意安排的。在改进集成以及理解业务有哪些核心重用功能方面，有很多基础工作要做，之后我们才能开始讨论公开服务。
服务公开 - SIMM 级别 4
当 SOA 到达 SIMM 级别 4 这一级时，一组关键的业务和技术功能便可以开始进行重用。最初，它们只可在 IT 部门重用，随后逐渐在企业级别，甚至 Internet 上获得了更多的重用机会。SIMM 级别 4 所关乎的是如何找到这些服务（这超出了本文的讨论范围，详情参见
面向服务的建模和架构），以及技术上如何公开此服务，本节将重点对此加以介绍。这里，服务公开 的含义是使用标准协议、数据格式、服务协议以及策略来公开接口以实现面向各种用户应用程序的重用。
那么，为了重用而公开一个服务为何如此具有挑战性呢？我们已经提到过选择一种标准协议，比如
SOAP/HTTP 或 REST/HTTP，这只是我们所说的 “公开” 服务的一个方面。那么，还有什么其他的要做呢？
要有效地公开一个服务，此服务必须至少是：有价值的、强壮的、可靠的、可执行的、可用的、可监测的、可维护的和安全的。在本系列后续文章中将对这些特性要求做更详细的介绍。现在，我们需要认识到此阶段之前的大多数接口都是针对特定的用途和特定的请求者开发的，所以我们只提供了上述特性要求中的一小部分。它们只顾及了特定解决方案所要求的那些特性，而并未完全考虑到该服务的所有可能顾客。而对于服务公开，进而对于 SIMM 级别 4，至关重要的正是这些特性的标准化。
接下来，让我们看看这些额外的功能如何被设计到一个解决方案中，并被置于解决方案中的什么位置。
图 11. 服务公开
从之前的中心辐射架构到现在的服务公开，发生了四个变化，通过对比之前的图和图 11，我们可以看出其中的三个变化。
-
标准化了的公开：请求者不再需要一个连接器 来与 hub 通话，因为我们采用的是可互操作的协议和传输，比如 SOAP/HTTP
或 REST/HTTP。
-
标准化了的请求处理：我们已经专门用此 hub 的 ESB Gateway 部分来执行成熟的服务公开所要求的虚拟化、安全性、可视性以及流量管理的面向方面的功能。
-
服务注册表：由于我们需要发布服务以便请求者们可以找到，所以在这里引入了服务注册表。虚线表示这个注册表最初可能只用于开发时而不是运行时。
-
特定于操作的集成来提高可消费性：第 4 个改变在图 11 中看不出来，因为这是 hub 行为方面的改变，而 hub 已经实现了。hub 的 “非-ESB Gateway” 部分进行的是更深一些的特定于操作的 集成逻辑。之前它只执行已知请求者要求的最少逻辑，现在它却要执行能让此服务更容易被任何 请求者消费的所有合理逻辑，比如错误处理、重复请求的管理、重试的处理、预先安排的宕机、连接共享等等。这些都与我们在 SIMM 级别 3 中使用的集成模式相同。关键的一点是现在所面向的顾客更多，所以要求就会更多，也就有更多的集成工作要做。
让我们来看看这在 Process Server 解决方案中是如何实现的。
图 12. 通过服务网关公开接口的解决方案图（参看图 12 的放大图)
那么，图 12 有何不同呢？此解决方案的每个部分在内部都是不同的，所以让我们从左至右地详细分析一下。
注：对 ESB 的用途和界限的定义很难统一。ESB 是一个架构概念，因而不独立存在于图 12 所示的任何一个具体组件内。其中的一个具体功能就是服务网关 组件，它对于 ESB 模式非常关键。正是这个服务网关使得以一种标准化的、受控的方式来公开成熟的企业服务成为了可能。它是扩展和区分服务公开（SIMM
级别 4）和更传统的集成（比如 SIMM 级别 3 中的中心辐射）的主要因素之一。
复合服务和业务处理自动化 - SIMM 级别 5
通过之前的阶段，您现在已经获得了一些完全成熟和可消费的服务（图 13）。下一个步骤应该是看看这些服务在您日常处理中通常被用在何处。这样的话，您就可以将这些服务包装成新的复合服务 来安排和编排较低级的服务。这进一步提高了 SOA 的成熟度，为顾客带来了功能更强大的服务。
图 13. 基于复合的解决方案
为了简便起见，现在，我们将复合服务分成两种：
- 一种是基本的复合服务，即一个被包装成单个服务请求的常用服务请求的集合。所有的服务请求可能同步并在合理的时间范围内（比如，数秒或更少）完成。通常使用一个简短运行的 BPEL 过程实现这些服务。
- 必须创建一些复合服务来管理可在更长一段时间（可能数天，甚至数个星期）延展的过程。很有可能在这些情况下，您在请求的各步骤中的具体位置对于业务将非常重要。因而，它们常常被标记为业务流程。它们通常在较长时间运行的 BPEL 过程中实现，并可能在过程中以 Human Task 的形式涉及人员交互。
无论是何类型，解决方案都会类似图 14。
图 14. 基于过程或复合的模块
有关不同类型的过程解决方案，可讲的很多。但这里，我们把这个问题留在后面的有关过程实现类型 的文章中再做讨论。
让我们看一个较高级的 Process Server 解决方案，它涉及了通过一个服务网关被正确公开的几个操作，这几个操作本身就是对后端系统的复合 调用。
图 15. 涉及几个公开了的复合服务操作的解决方案图（参见图 15 的放大图）
在图 15 中，可以看到两个不同的服务操作由一个服务网关公开。这个网关执行我们前面提到的所有面向方面的功能来公开服务操作，然后基于被调用的操作将这些请求路由到不同的模块。这些基于流程的模块执行复合服务，并通过使用 BPEL 来将多个调用安排给潜在的多个后端系统。您会注意到这些流程模块右侧的导入不再是适配器了，因为我们正在调用成熟的服务，而且很可能是通过 Web 服务。您还会注意到在这些流程模块中已经没有了中介流组件。但这并不是由于它们不能存在于同一个模块内。自 WebSphere Process Server v6.2 以后，在同一个模块中可以同时有流程和中介流组件。其原因还是因为我们假设您编排的是成熟服务，所以这里不需要任何复杂的集成逻辑。我们有一个具有基础业务对象映射的简单接口映射，以便对流程中使用的数据模型与我们正在编排的服务的数据模型进行相互转换。
所以，理想情况下，只编排成熟服务来避免集成逻辑的堆积及对业务流程的约束。这就需要流程自动化所带来的种种好处，这也是为什么 SIMM 级别 5 最好是构建在级别 4 的成熟服务上的原因。请注意，当我们刚刚达到这个成熟级别时，一个流程所要求的所有交互很少是成熟的、良好公开的服务。因此，执行对成熟服务和传统接口的混合请求的流程是很常见的。这里我们要确保这些传统接口已经被从业务流程中恰当地去耦以便提高业务流程的可维护性和可重用性。
工作流和基于任务的解决方案
在讨论服务集成成熟度时，工作流是一个特殊类别，这是因为它们原本与集成不相干。工作流是指通过将整个工作分解成若干任务并自动化这些任务的分配与进展，以在不同团队间有效地分配工作的系统（图 16）。
图 16. 纯任务解决方案 - 没有集成需求
这并不适用于 SIMM。首先，它根本就不需要任何与后端系统的直接集成，因为用户任务可能只是打个电话或派发一些工作文件。虽然后端系统通常用于这样的任务，但工作流系统并不一定要与这些后端集成。用户可能会把他们的桌面切换到一个主机终端来执行此任务，然后再切换回来。当很多公司还处在 SIMM 级别 1 时，像 IBM MQ Workflow 这样的产品及其以前的产品已经作为独立系统存在几十年了，现在这些产品与 SOA 这样的架构概念一样已经发展得非常复杂了。
然而，向面向服务的架构的演进为工作流带来了新的可能性，并且，通过允许一些任务成为 “系统” 任务（服务）而非 “人工” 任务的方法，其中一些可能性已经逐渐向流程自动化迈进。换个角度说，您可以把一个工作流看作是一个进行很多服务请求的流程，由人与后端系统混合执行。最初，这些任务的绝大多数是由人工完成的，但渐渐地，它们中的一些被服务调用所代替，进而最终实现完全的自动化。图 17 比较了一个纯粹的人工任务与一个除个别情况外几乎完全自动化的任务。
图 17. 纯任务解决方案- 没有集成需求（参见
图 17 的放大图）
Process Server 允许人工任务被分散到 DPEL 流程中或周边，因此您通常不能在第一天就自动化流程中的每一个步骤。不过，也不要限制人工任务在基于集成的流程中的这些个别步骤中的使用，另外也不要忽略长期以来对工作流系统的知识积累。您还要意识到很多流程从本质上还是面向人的，而且在将来的一段时期内仍然会是这样。
Process Server 为构建基于人工任务的流程提供了很多途径。这些流程会在后续的流程实现类型 一文中做更详尽的讨论。
结束语
本文介绍了针对通常用 WebSphere Process Server 和 WebSphere Enterprise Service Bus 解决的流程和集成问题的典型高级解决方案的概貌。
在本系列文章中，我们还会更深入地研究集成和流程解决方案。另外，我们还将教您如何捕捉和转换关键解决方案的特征并在设计中将它们转换为模式。在每篇文章中都会引入一个最新加入到产品的关键新特性。以下是后续文章内容的汇总：
-
WebSphere Process Server 内的解决方案介绍（本文）介绍使用解决方案视图 从较高级别考虑设计。
-
集成特征、模式及 Enterprise Service
Bus 将介绍新的服务网关 模式。
-
流程实现类型 将探讨如何扩展基于流程和任务的解决方案的宽泛能力，例如 协作流。
-
用版本化和动态性将灵活性构建到解决方案 将展示面向流程和模块版本化 的已有和新加的选项，以及让流程更加灵活的一些选项。
-
在解决方案中使用模式 将揭示如何使用 JET2 提高生产率和改进一致性。
致谢
本文中的结论来自于我们与相关人员对设计、项目经验的讨论，也有部分结论来自于我们与参与产品创建人员的对话。特别感谢以下人员：Andy Garratt、Bobby Woolf、
Eric Herness、Geoff Hambrick、Greg Flurry、Helen M Wylie、Jonathan
Adams、Joseph (Lin) Sharpe、Rob Phippen、Stephen Cocks、Paul
Verschueren、Werner Fuehrich，在实际中，还有很多人值得感谢。
参考资料
作者简介 | 
| | Kim Clark 是一名来自英国的 IT 专家，目前在
IBM
Software Services for WebSphere
(ISSW) 工作。他在 1993 年开始从事 IT 行业，自 WebSphere
Process Server 第一次实现后，就一直担任各种项目的技术主管，并经常撰写和发表有关 SOA 设计的文章。他拥有伦敦大学的物理学学位。 |
| 
| | Brian Petrini 是 IBM Software Services for WebSphere (ISSW) 的一名集成架构师和顾问。他在 WebSphere Process Server、WebSphere Enterprise Service Bus、WebSphere Adapters 和 WebSphere InterChange Server 方面有很深的造诣。他自 1999 年以来一直致力于集成产品的客户实现，并且经常撰写和发表最佳实践方面的文章。他的专业是电子与计算机工程。 |
对本文的评价
| 
