WESB（WebShpere Enterprise Service Bus）是 IBM 为了满足企业服务总线（Enterprise Service Bus，ESB）的基本需求，以全面支持面向服务的体系结构（service-oriented architecture，SOA）而提出的解决方案之一。WESB 实现 ESB 的核心就是构建一个基于 Mediation Flow 的 SCA Service。本文将对 WESB 进行简单介绍，并结合实例，指导如何利用 WID（WebShpere Integration Developer）构建满足业务需求的 Mediation Module 和 Mediation Flow。

本文的第一部分将围绕 SOA 以及 ESB 的基本概念和原则，对 WESB 以及 SCA 等相关概念进行简要的介绍。并且对 WESB 如何对 ESB 进行支持和 WESB 的基本功能加以说明。

本文的第二部分将介绍 Mediation Flow 的基本概念，组成部分和工作模式，它是运行于 WESB 中的 SCA Service 所必需的核心部分。

本文的第三部分将结合实例，详细介绍如何利用 WID 开发工具构建 Mediation Module 以及其中的 Mediation Flow，并会结合我们目前进行的项目，给出一些开发经验和需要注意以的地方。最后将介绍如何将开发好的SCA应用部署到 WESB 服务器上。

本文的目标读者是具有一定开发 J2EE 编程开发经验，需要进行 SOA 和 ESB 相关开发的程序开发人员。对于那些需要了解 WESB，SOA 和 ESB 的开发人员，本文也可以作为一篇参考资料。

在现代企业集成环境中，许多企业都具有不同种类的信息技术（IT）环境，这些环境由许多不同的应用程序组成，这些应用程序位于不同硬件和操作系统上，并且是用不同的编程语言编写的。如果没有正确的中间件基础结构，要将它们集成在一起是很复杂的，并且难以维护。

为了跟上业务更改的步伐，可能需要反复修改现有应用程序，以便与新的应用程序集成或者对新的业务情况做出反应。这通常要求具备旧应用程序的技能和知识，以及它们在曾经非常复杂的体系结构中的实现。这样做的成本很高并且很浪费时间，降低了稀缺的 IT 人员的效率，并且延长了评估 IT 投资的时间。

通过使用"面向服务的体系结构"（SOA），将使应用程序集成变得更简单、更快速并且成本更低。

Enterprise Service Bus（ESB）是一种通用体系结构模式，它提供了灵活而快速地集成这些服务所需要的基础结构。可以使用多种中间件技术和编程模型来实现此模式。ESB 的值可以适用于多种情况 － 从部门集成到整个企业集成。

Enterprise Service Bus 上的集成逻辑将执行许多功能：

• 路由（routing）
• 数据库查询（Database lookup）
• 数据库日志记录（Database logging）
• 结构变换（Structure transformation）

通过动态地添加或替换服务，可以减少系统停机时间和满足不断变化的业务需要。可以将服务插入总线中并与现有服务进行集成，且无须更改现有服务。

IBM WebSphere Enterprise Service Bus（ESB）目前的最新版本是 6.0.1。它是从 WebSphere Application Server Network Deployment 的基础上发展而来的。WebSphere ESB 提供了基于标准的 Enterprise Service Bus 的功能，是一种灵活的连接器中间结构，可以用于集成企业级应用和服务，全面支持面向服务架构的开发。WebSphere ESB 是 SOA 的核心部分，并大大降低了接口的复杂度。它通过支持工业标准的 Web 服务，JMS（Java Messaging Service），SOAP 技术，为基于标准的业务集成提供了一个便捷的平台。

WebSphere ESB 可以与多种不同的应用或服务协同工作：

• Common applications（such as SAP）
• Applications with other protocols
• IBM WebSphere Adapters
• Other industry-standard J2C Adapters

WID（IBM WebSphere Integration Developer）6.0 版本是最新发布的使用SCA模型来开发和集成应用的工具，它基于 Eclipse 技术，并面向 IBM WebSphere Process Server V6 和WebSphere ESB Server V6 运行时环境。和传统的在 WebSphere 应用服务器版本 6 中绑定到特定目的地的 Mediation 不同，从 WID 的 6.0.1 版本开始支持一种特殊 SCA 模块—— Mediation 模块，该模块在 SCA 的模块之间，以及 SCA 和非 SCA 之间建立了交流的桥梁。本文将重点介绍的 Mediation Flow 就是该模块所引入的一种全新组件。

WID 的6.0.1版本中，引入了一种全新的 module，称为 Mediation module。一个 Mediation 模块实际上是 WID 中可以创建的一种 WebSphere 业务集成工程，它可以被部署到 WebSphere ESB 或者 WebSphere Process Server 上。这个模块中包含了一种全新的 SCA 组件，称为 Mediation Flow。在一个 Mediation module 中，必须包含且仅能包含一个 Mediation Flow。否则WID会报出编译上的错误。

Mediation 模块的主要功能就是将处理服务请求者（service requester）与服务提供者（service provider）之间存在的不匹配情况，包括协议或交互样式的不匹配以及接口的不匹配。在整个基于 SCA 的解决方案中，Mediation 模块是一种用于执行特殊任务的 SCA 模块，因此，它与在企业级别运行的其他组件的特征稍微有所不同。Mediation 模块提供的 Mediation 服务由 MediationFlow 形成，该 MediationFlow 可以截取、修改服务请求者（SCA Export）和服务提供者（SCA Import）之间传递的消息。用户可以向一个 Mediation 模块中添加依赖库、Java 工程和 J2EE 工程，并选择将它们和 Mediation 模块一起进行部署。

Mediation Flow 能够对在服务端点之间进行交换的消息执行操作。与常规的业务应用程序组件比较起来，Mediation Flow 关心的是通过基础结构的消息流，而不仅仅是关心消息的业务内容。它们将对消息执行路由、变换和日志等操作，而不仅仅是执行业务功能。用于管理它们的行为的信息通常保存在与业务消息一起流动的消息头中。IBM SOA 编程模型引入了 SDO 的服务消息对象（SMO）模式以支持此模式。

从 SCA 编程模型的角度来看，Mediation Flow 与其它的 SCA 服务组件并无很大不同，也需要具备以下4个要素：

• 需要存在，且仅能存在于一个 Mediation module 中。
• 具有一个接口，通常为一个 Java 接口或 WSDL 描述文件。
• 可以通过导出（export）暴露给客户端进行调用。
• 可以通过导入（import）调用其它服务组件，导入中需要包含绑定协议的信息。

Mediation Flow 是由一个或多个 mediation primitive 构成，各个 primitive 可以在 WID 的图形化编辑工具中方便的进行拖拽和连接。这些 primitive 更多是用来进行消息流转的控制，而不是执行业务功能。

事实上，每个节点都可以含有一个失败的端子（terminal），因此当发生错误时，开发者可以选择在任意环节捕捉这个错误并进行处理（handle）。另外，如果表格中的各种 mediation primitive 都不能满足开发者的需求，那么开发者可以选择直接用 Java 代码来创建一个定制的 mediation primitive。不过这种定制的 mediation primitive 具有很大的限制，在本文的后面会提到。

上文提到的各种 mediation primitive 在 WID 开发环境中均有一一对应。一个 mediation primitive 自身可以有多个端子（terminal）。所有的 mediation primitive 都有一个输入端子用于接收输入的消息。而多数 mediation primitive 有一个或者多个输出端子用于消息的传递。输出端子可以分为两种：失败（fail）端子和成功（successful）端子。根据 mediation primitive 自身的需要，它最多可以有一个失败端子，而成功端子则数目不限。如果在对输入消息的处理过程中产生异常，失败端子将原有输入和一场信息一起传出。如果一个 mediation primitive 的输出端子无任何连接，WID 会产生一个警告。在执行期间，无任何连接的输出端子将会停止信息的路由而不会抛出任何异常，从而使得信息浪费掉，因此推荐开发者尽量对失败情况进行捕捉。

在 WID 提供的图形化开发 Mediation Flow 模型视图中，对各种 mediation primitive 提供了良好的支持，如图1所示，表1给出了 WID 编辑器中除了 custom mediation primitive 之外所对应的组件。

对于 custom mediation primitive 将在下文结合实例进行介绍。

3.2.1 实例场景介绍

这里假设的场景是基于某航空公司对于业务集成的需求。航班的延误或者取消是两个独立的应用，现在由于需要把航班更改或延误的消息及时传递给乘客，因此，需要开发全新的模块对两个应用进行集成。本文将给出两种实现方式：基本的 Mediation Flow 和 Custom Mediation Flow。

3.2.2 基本 Mediation Flow 开发

首先我们在 WID 中创建一个 mediation module，命名为 FlightNotifyUser，在 WID 中选择"File->New->Project"，并在弹出的 New Project 对话框中选择"Mediation Module"，如图3所示。WID 默认将切换至 business integration 视图下的 assembly view。

我们把系统已有的延误航班和取消航班作为 Service Component 引入，通过把它们和我们开发的 Mediation Flow 集成，向外界提供唯一的 FlightNotifyUsers 服务。其整体视图如图4所示，其中 NotifyCancelImport 和 NotifyDelayImport 分别为当航班取消、当航班延误两种服务。

下面我们具体介绍我们开发的 FlightNotifyUserMediation，它就是一个 Mediation Flow 其整体流程如图5所示：

结合图5，当请求消息进入 mediation flow 后，会经过如下步骤。

1） 首先请求消息会流到 Database Lookup 元素，该元素根据请求消息中所带的航班号和航班原定起飞日期，从数据库中查询出已订了该航班的所有乘客的信息（名称和电话号码），然后把所有的乘客信息填充到请求消息中的预设字段。经过了这一步，消息流中已经包含了乘客的信息。

2） 消息经过 MessageLogger 元素，该元素进行一些消息日志的记录

3） 当消息流到 MessageFilter 元素的时候进行分流，分离出到底是应该是调用延误航班的服务还是取消航班的服务。我们在请求信息中包含了一个字段flag，默认情况下我们规定都流向调用取消航班服务。如果这个字段的值是 delay 的话，流向延误航班。MessageFilter 的配置如图6所示：

输出有两个，default 默认流向取消航班服务，notifyDelay 流向延误航班服务。我们使用 XPath 对消息内容中 flag 的值进行判断：

/body/notifyFlightInfo2Users/notifyCondition/flag [self: node ()='delay']

如图7所示。

4） 经过过滤后，延误航班消息和取消航班消息分别流向各自的服务，由于我们的请求消息的格式和航班服务本身所要求的格式不一致，所以我们必须要对消息的格式进行匹配，使之符合航班服务要求的格式，这个时候 XSLTransformation 可以起作用了，我们以取消航班服务为例，如图8：

Target 一栏是航班服务的消息格式，它需要用户名称（userId）和提示信息（notifyInfo）两个信息，而 Source 一栏是请求消息的格式。通过把请求消息中的信息和目标消息中的信息进行匹配，我们能够得到被航班服务接受的消息格式。

5） 最后当航班服务处理完之后，我们也需要使用 XSLTransformation 把服务返回的结果信息转化成 FlightNotifyUserMediation 能够接受的信息格式。如图9：

以上便是我们利用 MediationFlow 各个组件完成的关于航空公司应用场景 FlightNotifyUser 中介流的开发。

3.2.3 Custom Mediation Flow 开发

Mediation Flow 还提供了一种供开发人员自定义的元素组件，那就是 Custom Mediation Flow。通过使用这种组件，开发人员可以自己实现需要的功能，这样提高了开发的灵活性。本文所示例的 Custom Mediation Flow 仍然采用前面的业务场景，因此构建 module 的过程不再赘述。由于 custom mediation primitive 只能有一个输出端子，我们将采用一个 Java component 来替换 Filter 和 XSLT 的消息匹配。图10 为利用这种方式画出的流程图。

实现 Custom Mediation Flow 首先要定义一个实现功能的接口，你可以选择已有的一个接口，或者自己新增加的接口，如图11：

在我们的例子中选择 Create a new interface with implementation，在创建一个新增接口后，又有两种方式选择去产生具体的实现，如图12：

如果选择第一种方式，我们可以直接在 snippet editor 中写入我们的 JAVA 代码完成实现，如果是第二种方式，我们可以在 Assembly Editor 上通过 Java Component 或者 import 的方式实现。作为简单的示例，我们选择第一种方式。可以在如图13的 Snippet Editor 中写入代码：

如果选择了 Visual，可以使用它提供的功能控件完成基本功能，如图14，如果需要获得详细的控件定义，可以参阅信息中心，本文不再赘述。

3.2.4 Mediation Flow 的部署

上文利用 WID 完成了服务的开发，现在将描述将应用部署到 WESB 服务器上。首先把我们写好的 FlightNotifyUser 中介流模块，导出成 ear 包，这里我们命名为 FlightNotifyUserApp.ear，通过 ESB Server 的控制台界面进行部署。WESB 会根据业务的复杂程度自动的为部署需要的步骤进行计算并做出调整。我们可以在 WESB 控制台中修改 JNDI 映射，修改应用在服务器上的节点等等。默认值通常已经可以满足需要，如图15。

按下 Finish 按钮，直到出现图16所示的信息。

当看到上面的信息时说明部署已经成功了，单是还要点击下面的 save to master configuration 来保存设置，所作的部署才会真正应用于服务器。如果不保存，服务器会将前面的部署回滚。完成部署之后，服务默认的状态是停止，这时候还需要到WESB的应用程序列表中将它启动，如图17，如果右边的状态变成了绿色的箭头，就表示启动成功。

3.2.4 Mediation Flow 的测试

WID 中集成了测试 SCA 应用的工具。首先将 WID 切换到 business integration 视图的 physical Resources view，在这个视图下，我们能够看到所有的配置部署文件。进行测试时，只要点中提供服务的WSDL文件，然后右键选中 Web Services -> Test with Services Explorer，如图18 所示。

接下来就会出现测试工具的窗口，如图所示。可以方便的在测试工具中填写测试数据：单击 add 可以增加数据；单击 remove 可以删除数据。然后点击"go"按钮，在下面结果输出窗口中就会得到测试结果，如图19。

在本文中，我们首先对WESB所支持的 mediation module 进行了简要介绍，然后重点介绍了在这个模块中最重要的组件 mediation flow。本文详细介绍了该组件的各个组成部分及定义，并且结合实例详细介绍了如何利用WID和WESB构建基于 Mediation Flow 的 ESB SCA 服务组件。

Mediation Flow 是在 WESB 平台上进行业务集成的核心模块，它可以通过部署的方式灵活的进行查询，日志，消息路由，消息适配等操作。对于比较复杂的业务逻辑，还允许编程人员自定义中间过程。WID 个功能强大的业务集成工具，提供了可以开发 Mediation Flow 的友好编辑器和测试环境。WESB 的核心是基于成熟的 WebShpere Application Server，也使得这种全新的 SCA 组件可以很方便的进行部署。

目前 SOA 和 ESB 已经成为业界关注的焦点，未来的企业应用软件开发必然会越来越趋向于面向服务的业务集成。IBM 公司的 WESB 和 WID 无疑为 SOA 编程模型提供了有力的支持工具。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14789789/viewspace-426907/，如需转载，请注明出处，否则将追究法律责任。