级别： 初级 鹏 刘昕 (xinpengl@cn.ibm.com), IBM软件工程师，IBM中国软件开发实验室
传峰 李 (lichuanf@cn.ibm.com), IBM软件工程师，IBM中国软件开发实验室
2006 年 3 月 06 日 本文主要向读者介绍了在WID所提供的集成环境中的设计中介模块的基本流程和方法。以及中介模块如何在其中介流中记录消息日志，依据消息内容进行消息过滤，基于XSL变换消息格式以及按需定制自己的中介行为。
在最近的SOA概念和编程框架浪潮中，SCA（Service Component Architecture）已经成为新兴的面向业务服务的组件模型。SCA组件对业务数据进行操作，并使用统一的数据格式--SDO。WID（IBM WebSphere Integration Developer）6.0版本是最新发布的使用SCA模型来开发和集成应用的工具，它基于Eclipse技术，并面向IBM WebSphere Process Server V6 和WebSphere ESB Server V6运行时环境。和传统的在WebSphere应用服务器版本6中绑定到特定目的地的中介不同，从WID的6.0.1版本开始支持一种特殊SCA模块--中介模块，该模块在SCA的模块之间，以及SCA和非SCA之间建立了交流的桥梁。本文主要向读者介绍了在WID所提供的集成环境中的设计中介模块的基本流程和方法。通过本文，读者可以了解中介模块如何在其中介流中记录消息日志，依据消息内容进行消息过滤，基于XSL变换消息格式以及按需定制自己的中介行为。
1 WID中的中介模块
一个中介模块实际上是WID中可以创建的一种WebSphere业务集成工程，它可以被部署到WebSphere ESB或者WebSphere Process Server上。中介模块提供的中介服务由中介流形成，该中介流可以截取、修改服务请求者（SCA Export）和服务提供者（SCA Import）之间传递的消息。用户可以向一个中介模块中添加依赖库、Java工程和J2EE工程，并选择将它们和中介模块一起进行部署。
一个中介服务被建模为通过中介模块的模块集成图（Assembly Diagram）中关联起来的一组SCA组件。模块可以包含服务中用到的所有资源，但是这些资源都是私有的，并且只能在模块内部使用。如果想在其他模块中重用该模块的逻辑，必须将相关的接口从模块中导出（Export）。
一个中介模块和普通的SCA模块一样，可以有自己的实现。它的实现通常有以下两种类型：
1.1 中介模块的实现--中介流
中介模块中使用最主要的实现类型是上一节中介绍的前一种：中介流。在WID中，用户可以使用中介流编辑器来根据自己的业务需求定义、配置和修改可定制的中介流。
如图1所示，在使用中介流编辑器进行编辑时，用户可以看到两个视图。在上部的视图中，用户可以添加源接口和目标接口，它们将作为中介流的入口和出口。接下来，用户需要使用箭头在两个接口之间连接相应的操作对，它意味着中介操作所作用的实际服务调用路径。注意，每个中介流都被定义在一个操作对链接上。如图1所示，只有当"getQuote"操作被选中时，相应的中介流才被显示在下部的视图中。
下部视图给出了两个选择卡，分别用于表示从源服务请求者到目标服务提供者的服务调用过程中请求、回应消息路径上的中介流。初始情况下，在每个选择卡上只有流的端点（起点和终点）被显示出来。用户可以在端点之间添加中介行为，并把这些行为和流的端点关联起来。在中介模块中，中介行为被称作中介元素（mediation primitive）。WID内置提供了数个典型的预定义元素，以及一个扩展框架供用户定义自己的定制中介元素。在编辑器中，这些元素显示为工具条上的按钮（在图1中用红色矩形标出），它们可以被拖进中介流编辑面板进行关联、配置和定制。
图1 中介流编辑器中的中介流快照
1.2 用于组合中介流的预定义中介元素
一个中介流可以包含一个中介元素，一系列中介元素或者不包含中介元素。当使用多个中介元素时，用户可以创建更为复杂的中介。
一个中介元素自身可以有多个终端（terminal）。所有的中介元素都有一个输入终端用于接收输入的消息。而多数中介元素有一个或者多个输出终端用于传播消息。输出终端可用于两种类型的流：失败流（fail flow）和成功流（successful flow）。根据中介元素自身的需要，它最多可以有一个失败终端，而成功终端则数目不限。
如果在对输入消息的处理过程中产生异常，失败终端将传播原有的输入消息，并附加相关的异常信息。如果一个中介元素的输出终端没有被关联，WID会对此产生一个警告（但并不是错误）。在运行时刻，没有被关联的输出终端将会停止该条路径上的流而不产生异常，从而使得流中传递的消息被消费掉。
目前WID中预定义的中介元素包括：
- 终止中介元素（stop mediation primitive，图标为
 ）：用于终止中介流中的一个特定路径。它拥有一个输入终端，没有输出终端。输入终端被关联到输入消息，该消息在元素内部被终止而不产生任何异常。因此该中介元素的典型用途是于缄默中消费掉异常，就如同在Java语言中的一个空的catch语句一样；
- 失败中介元素（fail mediation primitive，图标为
 ）：用于终止中介流中的一条路径，并产生一个异常。失败中介元素有一个输入终端用于接收输入消息，并触发一个FailFlowException。其他中介元素的输出终端可以被关联到失败中介的输入终端以抛出FailFlowException。通过使用该中介元素的"ErrorMessage"属性，用户可以添加失败信息并在预期的地点以异常的方式将其抛出；
- 可定制中间元素（custom mediation primitive，图标为
 ）：我们将在 2.3节中详细说明该中介元素；
- XSLT中介元素（XSLT mediation primitive，图标为
 ）：用于对消息格式进行转换。它拥有一个输入终端和两个输出终端。一个输出终端用于成功输出，而另一个用于失败输出。输入终端用于接收输入消息并触发转换。如果转换成功，则成功输出终端将传播经过转换的消息；如果在转换过程中产生异常，失败输出终端将传播原消息，并附加相应的异常信息。该元素有3个属性：一个用于指定XSL样式单，一个用于指定消息中被转换部分的根元素的XPath，另一个则用做对输入消息进行验证的布尔开关；
- 消息日志中介元素（MessageLogger mediation primitive，图标为
 ）：用于在一个关系数据库中存储消息，该数据库使用IBM自定义的表模式。该元素通过服务消息对象（Service Message Object，SMO）获取用作记录日志的信息，而将日志本身记录为SMO的XML表达。被用作日志的消息自身被存储在关系数据库的Message列。而其他信息，如时间戳、消息标志符、中介元素实例名称等被存储在其他列中，并被赋予相应的标记头。该元素有一个输入终端和两个输出终端：成功输出终端和失败输出终端。输入终端用于接收消息并触发在数据库中记录日志，而输出终端则用于传播消息。当日志记录成功时，传播原消息；失败时，则附加相应的异常信息；
- 消息过滤中介元素（MessageFilter mediation primitive，图标为
 ）：用于有选择的传播消息。它能够对输入消息进行检查，并让不同的消息通过不同的路径进行传播，从而达到让消息跳过冗余传播步骤的目的。该元素有一个输入终端和多个输出终端。所有的输出终端中有一个用于失败输出，一个用作缺省的成功输出。所有其他的输出终端都各自和一个简单条件表达式相关联。缺省的成功输出终端用于传播那些不满足任何一个条件表达式的消息。该中介元素的属性包括：包含了由XPath定义的消息过滤准则和相应输出终端信息的过滤器；用于过滤的消息部分的根节点的XPath；分发模式，该模式定义了当多个过滤准则满足时消息传递的行为；
- 数据库查询中介元素（DatabaseLookup mediation primitive，图标为
 ）：用于使用数据库中的信息编辑（添加、修改）消息。该元素从数据库中查询相应的值，并将这些值以元素的形式存储到消息中。其中KeyPath属性是必需的，它用来做消息和数据库之间的信息关联。该元素有一个输入终端和3个输出终端。如果KeyPath键在消息和数据库中都被定位到，则使用其中的一个输出终端，这时数据库中的相应信息被存储到消息中，修改后的消息被传播。当KeyPath键在消息中而不在数据库中时，使用另一个输出终端，这时原消息被传播。最后一个输出终端用于失败输出。除了KeyPath外，该元素还拥有其他和数据库相关的属性，以及一个用于控制对属于消息进行有效性验证的布尔开关。
1.3 可定制中介元素构建框架
除了预定义的消息中介外，WID还在中介元素工具条上提供了另外一个按钮，叫做可定制SCA中介元素（CustomSCA mediation primitive，图标为 ）。该元素允许用户在他们的业务应用中扩展中介语义。
可定制中介元素构建框架允许用户使用外部的SCA组件作为该中介元素的实现。目前，WID限定该外部SCA组件的类型为Java，并且不允许使用另外一个中介流组件嵌套地作为它的实现。该框架为用户提供了一个输入终端用于消息介入，以及两个输出终端，分别用于成功输出和失败输出，如同我们在2.2节介绍预定义中介元素时所述的那样。
通常在WID中开发一个可定制SCA中介元素的主要步骤如下：
- 在中介流编辑器中，将一个初始的可定制SCA中介元素由工具条上拖拽到流定义面板上，并将其终端关联到用户想链接的其他终端，从而形成所需的中介流雏形；
- 对新建的元素进行配置，例如，改变它的显示名称，选中该元素并在WID的属性视图中设定其属性；
- 如果用户还没有在当前的工作台中定义适合于该中介元素实现的接口，则为该可定制元素创建一个新的接口；
- 确认该元素处于选中状态。从属性视图选择"Detail"选择卡，点击"Define…"按钮并选择用户需要赋予该元素的接口。改变可定制元素作用的消息根节点，如果缺省的根节点不是用户所需要的；
- 确认该元素处于选中状态。从属性视图中选择"Implementation"选择卡，在多行文本框中填充实现用户所需的中介逻辑的Java代码；或者点击"Open Java Editor…"按钮，在打开的可定制中介元素Java实现文件中完成编码；
- 在中介模块所在的工程中，用集成编辑器打开模块定义，并在模块定义中添加一个Java组件。右键点击该组件，在上下文菜单中点击"Select Implementation"，选择其实现为创建可定制SCA中介元素时生成的Java Class。该组件即为定制SCA中介元素的Java实现所对应的SCA组件。它使用为定制SCA中介元素定义的接口，并被关联到中介组件作为该组件的一个成员引用（partner reference）。
我们将在下一节中提供一个业务场景，以实例研究的方式来进一步详细说明在WID中如何使用中介模块。用户将能够汲取在一个中介模块工程中进行模块创建、接口定义和绑定，以及组件集成的更为细节的步骤和注意事项。另外，用户也能领会如何使用预定义中介元素来构建一个中介流。由于WID的预定义中介元素已经基本覆盖了通常情况下对消息进行中介的主要行为，我们的实例不再特别涉及可定制中介元素的开发。我们相信在多数情况下2.3节所述的步骤已经能够协助用户完成对可定制中介元素的创建和实现。
2 中介模块的一个业务应用场景
现在我们将通过一个业务场景来演示一下如何在WID中对中介模块及内部的中介流进行操作。
在我们的应用场景中，我们假设有一个机械厂商在生产车床时需要定购一批零件。目前网上有两个可用的零件定购服务，一个在该厂商的企业网内部，一个在企业网外部。两个定购服务都接受零件的编号，返回定购的零件成功与否。但两者接受的编号格式不同。如果采用经典的Web Service请求--应答模式，则需要在客户端的代码中添加相关的条件分支，并显式地对零件编号进行转换；或者为这两个Web Service书写两个客户端程序，分别用各自的零件编号发出请求。在这两种解决方式下，Web Service的请求者和提供者耦合性很高，一旦将来Web Service的接口发生改变，客户端要做出相应的修改，对于企业来讲，维护这样的客户端代价很高。
2.1 业务应用场景的技术解决方案
如图2所示，在本文的实例中，我们希望使用中介模块作为客户端和两个Web Service之间的消息中介，将有关消息路由和消息格式转换的工作分离出来。读者可以直接将本文所附资源SupplierSystemSample.zip以Project Interchange的方式导入WID工作台获取完整的中介模块工程。另外，客户端和两个Web服务被打包在剩余的3个EAR文件中。
图2 零件定购业务场景的技术解决方案
零件定购客户端由普通的J2EE客户端工程实现。它的内部逻辑和经典的Web Service客户端请求相同，即按JAX-RPC模式发出SOAP请求，并在请求中加入待定购的零件编号。该客户端程序将被打包为EAR，以企业应用的形式部署到WebSphere ESB上。
两个零件提供商Web Service都被实现为传统的Web Service，以WSDL描述对外发布服务接口。两个Web Service的内部实现逻辑均为接受零件编号，并返回定购的零件成功与否的信息。唯一区别是WSDL中相应的方法和参数名称不同。在用户看来，输入的零件编号似乎有两种格式：以"A*" 打头和没有"A*"打头的。实际上这只是为了区分送往不同零件提供商Web Service的零件。在系统的实际处理过程中，以"A*" 打头的零件编号被截取"A*"之后的部分发送给第2个提供商，而不以"A*"打头的被直接送往第1个提供商完成定购。两个服务最终都将被打包为EAR，并以企业应用的形式部署到WebSphere ESB上。
我们的重点是实现客户端和两个Web Service之间的中介模块，从而使得我们的业务应用中服务请求者和服务提供者之间的交互更加动态、灵活和透明。如图2所示，中介模块的内部逻辑由一个中介组件来实现。另外，由于中介模块自身属于标准SCA模块，为了和传统的Web Service客户端和两个Web Service完成消息交互，一方面需要将两个Web Service的接口导入中介模块，另一方面需要将一个统一的服务接口导出给客户端程序。对于前者，我们在中介模块内部创建两个WS导入组件；对于后者，我们在中介模块内部创建一个WS导出组件。每个WS导入/导出组件都包含一个WS绑定（Web Service Binding）。该绑定能够在中介模块内部的SDO消息格式和外部的标准SOAP协议之间做双向转换。而在中介模块内部，各个组件之间将使用统一的数据格式--SDO进行通信。
2.2 创建中介模块
为了实现如上逻辑，我们必须在WID中创建一个中介模块：
在下一节中，我们将使用WID提供的预定义中介元素来构建本节创建的中介组件的实现--Mediation1中介流的完整定义。
2.3 在场景中应用预定义中介元素
本节我们将实现中介模块的实现--Mediation1中介流。如我们在2.1节所述，中介流由请求中介流和回应中介流组成，表现在中介流编辑器中，就是下部视图中的两个选择卡。在开始编辑中介流前，我们需要在上部视图中为Mediation1添加一个源接口和两个目标接口：
图8 Mediation1中介流的源接口和目标接口
如图8所示，进入Mediation1中介流的消息从接口SupplierSystem1的方法requestOrder调用触发（注意，我们在上一节中将中介组件的接口绑定为SupplierSystem1，并通过一个WS导出组件对外暴露同样的接口）。离开中介流的消息根据具体的中介逻辑可能从SupplierSystem1和SupplierSystem2这两个接口流出。通过中介的请求消息可能由SupplierSystem1接口的requestOrder方法进一步调用第一个零件提供商Web Service，也有可能由SupplierSystem2接口的applyOrder方法进一步调用第二个零件提供商Web Service。相应的，回应消息也可能由对应的零件提供商Web Service接口方法调用中重新进入中介流，并最终由源接口流回客户端。这两个目标接口在中介模块的中介流编辑器中被表示为两个接口成员（Partner）。
图9给出了Mediation1的请求中介流示意：
图9 Mediation1的请求中介流示意
从图9可以看出，请求消息进入中介流后，首先通过一个名为MessageFilter1消息过滤中介元素，来分离出流向不同的零件提供商Web Service的请求。流向零件提供商1的请求消息不需要做进一步的处理就可以直接由SupplierSystem1Partner流出。而流向零件提供商2的请求消息由于目标Web Service支持不同的零件编号格式，需要做一下消息格式转换，因而在进入SupplierSystem2Partner之前，需要流经名为XSLTransformation1的消息格式转换中介元素。
MessageFilter1中介元素的主要功能是对由SDO表示的消息内容中"/body/requestOrder/PartId"这一Xpath所指定的内容做路由。如果消息中该部分的值由"A*"打头，则由终端SupplierSystem2流出，否则由缺省成功终端流出。图10给出了MessageFilter1的终端配置。注意我们添加了SupplierSystem2终端。图11给出了SupplierSystem2终端终端关联的条件表达式。
图10 MessageFilter1中介元素的终端定义
图11 MessageFilter1中介元素的消息路由属性配置
XSLTransformation1中介元素的主要功能是将符合零件提供商1的请求消息格式转换为符合零件提供商2的请求消息格式。具体的转换机制可以通过在WID内定制一个XSLT映射文件来实现。图12给出了转换前后两个SDO消息格式的具体映射，即从源消息的"/body/requestOrder/PartId"XPath映射到目标消息的"/body/applyOrder/PartId"Xpath。图13进一步给出了两个PartId在内容上的转换机理：目标消息中PartId的值是通过截取源消息中PartId值"*"以后部分得到。图14则给出了XSLTransformation1中介元素通过属性配置关联映射文件的方法。
图12 XSLTransformation1中介元素中的消息格式映射
图13 XSLTransformation1中介元素中的XSLT函数定义
图14 XSLTransformation1中介元素的属性配置
在使用上图所示的属性配置时，用户可以先点击"new"按钮，生成图12所示的映射文件并完成编辑，之后点击"Regenerate XSL"来产生相应的XSL文件。
图15给出了Mediation1的回应中介流示意。从图中可以看出，由SupplierSystem1Partner流回的消息不需要做任何格式转换就可以直接由中介流源接口的相应方法调用返回给客户端。而由SupplierSystem2Partner流回的消息仍需要流经名为XSLTransformation1消息格式转换中介元素做如上请求中介流中XSLTransformation1的逆转换后，才可以传回给客户端。需要注意的是，在请求中介流和回应中介流中都有名为XSLTransformation1的中介元素，但是它们为独立的两个元素。
图15 Mediation1的回应中介流示意
综上，我们使用消息过滤和消息格式转换两种预定义中介元素完成了该应用场景中整个中介流的构建和配置。在下一节中我们就可以部署并运行我们的应用了。
2.4 应用场景的部署和运行
我们可以选择WID内置的WebSphere ESB运行时环境作为我们的实例的测试平台。在WID的Business Integration透视图下，选择Server视图，右键点击WebSphere ESB Server V6，选择Start启动WESB运行时环境。
首先，我们必须将零件定购客户端以及两个零件提供商Web Service打包为标准EAR包，并部署到如上启动的运行时环境中。部署过程和经典的WebSphere 应用服务器6.0环境下部署J2EE应用完全相同。用户可以通过右键点击Server视图中的WebSphere ESB Server V6选择打开该运行时环境的管理控制台，点击Enterprise Applications链接，并在弹出的网页界面中安装并启动导出的3个EAR。
对于中介模块的部署，我们可以在Server视图中右键点击WebSphere Application Server 6.0，选择"Add and remove projects…"。在弹出的对话框中，我们在左部的列表框中选中SupplierSystemModule，点击"Add >"按钮，使之出现在右部的列表框中，确定并关闭对话框（如图16所示）。这样，WID将自动将该中介模块部署到当前已经启动的内置WebSphere ESB运行时环境中。
图16 部署中介模块到WID的内置WebSphere ESB运行时环境中
现在我们的业务场景已经可以运行了。我们通过网页浏览器启动客户端程序，输入零件编号并提交，定购系统将返回定购成功与否的回应信息。图17给出了通过第1个Web Service获取零件定购服务的UI，图18则给出了通过第2个Web Service获取零件定购服务的UI。我们可以看到由两个Web Service回应消息拥有不同的格式。
图16 通过第1个Web Service获取零件定购服务的UI
图17 通过第2个Web Service获取零件定购服务的UI
如下为以上两次零件定购过程中系统日志信息，从中我们可以看到不同的服务接口及其方法调用：
[1/3/06 15:52:26:500 CST] 00000066 SystemOut O SupplierSystem2: applyOrder(String PartId)
[1/3/06 15:52:26:500 CST] 00000066 SystemOut O PartId=12345678
[1/3/06 15:53:47:438 CST] 00000082 SystemOut O SupplierSystem1: requestOrder(String PartId)
[1/3/06 15:53:47:438 CST] 00000082 SystemOut O PartId=12345678
|
3 总结
在本文中，我们对WebSphere Integration Developer中的中介模块进行了简要的介绍。我们还使用了一个具体的应用实例来说明了在WID中构建中介模块的方法，以及在该业务环境下该模块的应用。
中介模块中最具技巧性的部分是用来构建中介流的中介元素。至此，用户应该学会了正确使用WID提供的预定义元素，并采用文中所述的步骤来为自己定制符合所需业务逻辑的中介元素。
SCA正在成为未来SOA解决方案中的体系结构参考和应用核心，该趋势也将不断得到加强。因此，WID将成为集成开发人员和应用开发人员手中最普遍的工具之一。对我们来讲，迅速熟悉SCA的相关产品和运行时环境（尤其是WebSphere ESB），是面对未来大规模集成业务的当务之急。
下载
- 下载中介模块：SupplierSystemSample.zip，选择"Project Interchange"导入WID；
- 下载零件定购客户端：PartRequestClientEAR.ear；
- 下载零件定购服务1：SupplierSystem1EAR.ear；
- 下载零件定购服务2：SupplierSystem2EAR.ear：均可通过"EAR file"导入WID。
参考资料
- WID/WPS/WESB 帮助中心, http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/index.jsp
- RedPaper, Technical Overview of WebSphere Process Server and WebSphere Integration Developer, http://www.redbooks.ibm.com/redpapers/pdfs/redp4041.pdf
- IBM developerWorks ,IBM WebSphere Developer Technical Journal: Get started with WebSphere Integration Developer, http://www.ibm.com/developerworks/websphere/techjournal/0512_peterson/0512_peterson.html
- IBM developerWorks（中国），企业服务总线解决方案剖析，第 2 部分：利用 WebSphere 6 中的 SIBus 实现 ESB，周志荣，http://www.ibm.com/developerworks/cn/webservices/ws-esb2/
作者简介  | | | 刘昕鹏：IBM软件工程师，工作在IBM中国软件开发实验室 - SOA Design Center，从事Incubator及SOA方面的工作，对J2EE、SOA、MDA/MDD、AOP、语义网等相关技术有浓厚兴趣。目前主要负责基于WID的SCA和WESB实现扩展的相关开发。
联系方式：xinpengl@cn.ibm.com |
| | | 李传峰：IBM中国软件研发实验室SOA设计中心工程师，多年IT企业工作经验，对软件开发及应用有浓厚兴趣。目前正在从事ESB和SCA的实现工作。
联系方式：lichuanf@cn.ibm.com |
对本文的评价
| 
SupplierSystemModule"，用集成图编辑器（Assembly Diagram Editor）打开组件集成编辑界面；
，并拖拽到集成图面板中。重命名该组件为Import1。选择SupplierSystem1作为Import1的接口，并关联到中介组件Mediation1；右键点击Import1，选择"Generate Binding…->Web Service Binding"；
