用WESB 7.0新功能便捷实现服务综合网关

日期: 2010-06-09 作者:翟小东梁睿高忠涛 来源:TechTarget中国 英文

  随着企业规模的不断发展,越来越多的企业希望能够快速架设多种业务,以满足内部和外部客户不断增长的应用需求,提高企业的整合能力和客户满意度。引入服务综合网关(SIG,Service Integration Gateway),目的是实现业务的互通 / 融合,提供统一的业务能力和业务平台的接入。各业务平台间不再需要分别建设互通网关,只需一个统一的接口接入综合网关,即可调用各种开放的业务能力,构建更丰富的业务特征;不再需要关注被调用者的组网、业务部署、业务控制及与其它业务的紧密相关情况,只需要按照综合网关定义的标准要求接入综合网关,利用综合网关统一实现业务能力调用。

  本文首先给出一个服务综合网关的模拟应用场景,然后结合WESB 7.0产品的新功能进行场景分析,最后使用WebSphere Integration Developer(以下简称 WID)7.0给出一套完整的解决方案。目的是通过对这一模拟实际应用场景的实现,一方面揭示WESB 7.0产品的强大新功能,另一方面告诉用户如何在实际应用中使用这些功能。

  本文假设您熟悉服务组件体系结构(Service Component Architecture,SCA)编程模型,并具有使用WID和WESB或WebSphere Process Server(以下简称 WPS)开发应用程序的经验。

  基础知识

  ServiceGateway是WESB产品的一个重要功能,它的作用是为了能够处理各种不同格式的接入和调用消息,实现一个通用的消息处理网关。其开放的ServiceGateway接口不仅支持基于SOAP的Web Service协议,还支持HTTP、MQ、JMS等主流协议。最重要的是,在WESB 7.0版本中对ServiceGateway的功能进行了重大完善,引入了ProxyGateway的概念,支持通过虚拟服务(Virtual Service)名称进行动态路由,实现了一个真正意义上服务网关的功能。而且新开发的Native Data Data Handler、Gateway BodyAware、SOAP异常处理等功能大大提高了ServiceGateway的健壮性和易用性,利用这些新功能用户可以方便快速的部署一个综合网关。

  服务综合网关应用场景

  综合网关主要包括业务能力调用、业务控制功能、业务能力接入、通用管理功能和管理控制接口集合 5 个功能模块。为了更清楚的描述问题,下面 图 1 给出一个模拟的服务综合网关应用场景,本文将围绕这个应用场景展开说明。

图 1. 服务综合网关应用场景

图 1. 服务综合网关应用场景

  本文将利用WESB 7.0的新功能实现 图 1 所示的服务综合网关,包括业务能力调用、业务控制功能和业务能力接入。其中,业务控制部分将实现消息校验、路由控制和SLA控制功能,通用管理功能部分将实现日志记录功能。此外,还包括整个系统的业务异常、运行时异常处理等功能。

  场景分析

  根据 图 1 所示的应用场景,由于要实现的是一个综合服务网关,不得不提到 WESB 产品的一个重要功能 ServiceGateway。它作用就是为了能够处理各种不同格式的接入和调用消息,实现一个通用的消息处理网关。而且在 WESB 7.0 版本中对 ServiceGateway 的功能进行了重大完善,引入了 ProxyGateway 的概念,实现了一个真正意义上服务网关的功能。本文将演示如何使用该功能方便快速的部署一个综合网关。

  业务能力调用:从 图 1 可以看到业务平台通过综合网关调用业务能力,这里使用基于SOAP的Web Service接口协议供自有的业务平台或者第三方应用调用。提供开放的接口是WESB产品的基本功能,同时ServiceGateway接口具有通用消息处理能力,能够处理各种不同格式的调用消息,因此这里只需要创建两个ServiceGateway的Export来分别覆盖SOAP 1.1和SOAP 1.2两种协议即可。

  业务能力接入:从 图 1 可以看到综合网关通过定义的业务能力接入接口实现业务接入功能,同样使用的是基于SOAP的Web Service接口。由于综合网关面向各种开放的业务能力,为了实现接入不同的服务,类似的只需要创建两个ServiceGateway的Import来分别覆盖SOAP 1.1和SOAP 1.2两种协议即可。

  业务控制功能:该部分完成综合网关的核心处理功能,包括消息校验、路由控制、SLA 控制等核心功能。WESB 提供了一系列的中介原语(Mediation Primitive),借助于 WID 工具可以方便的对中介流(Mediation Flow)进行操作。例如,MessageValidator 中介原语用来实现消息校验功能;GatewayEndpointLookup 中介原语可以基于 WSRR 和 Built-in Configuration Store 进行可用服务查找,进而实现动态路由功能;SLACheck中介原语可以实现SLA(Service Level Agreement)相关的功能。

  此外,对于通用管理模块中的日志记录功能可以采用MessageLogger中介原语实现。运行时异常处理可以采用CustomMediation中介原语通过Java代码方便的实现,业务异常只需要把封装好的异常消息返回,Fault Flow可以自动处理。其中用到的SOAP异常处理功能是WESB 7.0产品在异常处理方面的一个重要增强。它不仅真正意义上支持业务异常(Business Fault)处理,而且增强了对运行时异常(Runtime Fault)处理的支持。

  具体实现

  基于上面的场景分析,需要利用WESB的ServiceGateway功能来构建服务综合网关。同时,为了方便实现和说明问题,本实现中仅选取手机邮箱,下载和铃声 3 个应用服务作为业务示例。本节使用WID 7.0分步骤给出具体的实现过程,并对其中用到的WESB功能点进行简要的描述。

  第一步,创建Library并定义接口(Interface)。

  这一步需要定义传输消息使用的数据类型和各个业务能力提供者使用的接口。根据综合网关协议的通用原则,综合网关只解析消息头(SOAP Header)来进行各种控制,消息体(SOAP Body)中的信息由各业务平台 / 能力定义,综合网关不做解析。综合分析本示例中使用的数据类型,给出其定义如下 图 2 所示:

图 2. 接口数据类型定义

图 2. 接口数据类型定义

图 2. 接口数据类型定义

  另外,对于手机邮箱、下载、铃声 3 个应用服务分别定义 3 个接口MailBoxInterface、DownloadInterface和RingtoneInterface,具体的接口定义比较常规,请参见下载中附件,这里不做赘述。

  第二步,创建综合服务网关模块。

  根据前面的场景分析,本文采用 ProxyGateway 来实现综合网关模块。为了便于说明综合网关的具体实现,这里有必要先简要介绍一下 ProxyGateway 的原理。ProxyGateway 是一种特殊的 ServiceGateway,它支持通过虚拟服务(Virtual Service)名称进行动态路由。其工作流程如下 图 3 所示。

图 3. ProxyGateway 工作流程示例

图 3. ProxyGateway 工作流程示例

  首先,客户端发送一个请求消息,目的URL为http://zzz/Gold,这里http://zzz是ProxyGateway的地址,Gold是Virtual Service的名字;然后,消息进入Mediation Flow,GatewayEndpointLookup中介原语从该URL中提取出Virtual Service的名字,到基于BusinessSpace的Built-in Configuration Store中进行查找,发现Gold这个服务映射的真实服务地址是http://aaa/premiumservice,返回并按此地址进行路由;最后动态调用该服务。

  这里,可以明显的看到,相比之前的版本,ProxyGateway 实现了真正业务层面的动态路由,实现了真正意义上的服务网关的概念。下面介绍 ProxyGateway 在 WID 7.0 中的具体实现。

  首先,导入ServiceGateway接口,因为该Interface是预定义的接口,需要在WID中GatewayModule/Dependencies/Predefined Resources 下勾选相应的Interface和DataHandler选项才能使用,如下 图 4 所示:

图 4. 配置 Predefined Resources

图 4. 配置 Predefined Resources

    其次,创建ProxyGateway 模块,其装配图如下 图 5 所示:

图 5. ProxyGateway 模块装配图

图 5. ProxyGateway 模块装配图

  这里使用的是WebService Binding,Export和Import都采用ServiceGateway的Interface,这也是我们通常所说典型的Dynamic ServiceGateway。需要注意的是,Data fomat 采用Native Data Data Handler取代了以前版本中的Service Gateway Text Data Handler。这是WESB 7.0的一个新功能,它终结了以前每一个协议接口(MQ,JMS,HTTP,Web Service)都使用单独的Data Binding的历史,整合为统一的 Native Data Data Handler,而且在使用WID 7.0创建ServiceGateway的过程中自动设置为默认值,大大增强了ServiceGateway的易用性。

  其次,实现中介流组件(MFC),包括Request Flow和Response Flow。其中,Request Flow的设计如下 图 6 所示。

图 6. Request Flow 的设计

图 6. Request Flow 的设计

图 6. Request Flow 的设计

    可以看到,消息通过Input节点流入Request Flow,先用SetMessageType中介原语把headers/SOAPHeader[1]/value设定为前面自定义的 SOAPHeader 类型 HeaderType,以便于WID识别;然后用MessageLogger中介原语记录日志,Promoted“Enabled”属性,使用PolicyResolution中介原语在运行时控制,作为是否记录日志的开关;之后到达MessageValidator中介原语根据设定的Xpath对消息进行校验,如果校验失败,进入 ValidatorFault 中介原语对错误信息进行封装,经InputFault点返回客户端;校验通过则继续进入 GatewayEndpointLookup中介原语根据设置进入Built-in Configuration Store或者WSRR查找可用的服务,如果没有找到服务,进入 noMatchFault 中介原语对错误信息进行封装,经InputFault节点返回客户端;如果找到服务,返回其地址并设置为 SMOHeader/Target/Address 属性的值;之后使用MessageFilter中介原语过滤消息,如果是SOAP 1.1消息,那么流入SLACheck中介原语进行SLA校验;如果是SOAP 1.2消息,那么直接从ServiceGatewayPartner1流出动态调用该服务(这是因为目前的SLACheck中介原语还不能支持SOAP 1.2 协议);对于SOAP 1.1消息,如果SLA校验失败,那么流入rejectFault中介原语对错误信息进行封装,经InputFault节点返回客户端;如果 SLA 校验通过,那么OK从ServiceGatewayPartner流出并动态调用该服务。

  这里大多数的中介原语使用都比较简单,详细信息请参见下载中的附件。但是有一些中介原语是 WESB 7.0 上新开发的,还有一些 ServiceGateway 增强的新功能,这里对 Request Flow 的配置过程中需要注意的地方说明如下:

  (1) 对于 Input 节点,勾选“Automatically convert the ServiceGateway message”属性,流入的gateway消息就会序列化为 Business Object,在中介流中就可以实现对SMO Body的访问。这是WESB 7.0 上 ServiceGateway 的一个新功能,称之为Gateway BodyAware。如下 图 7 所示:

图 7. 配置 Input 节点

图 7. 配置 Input 节点

  (2) 对于GatewayEndpointLookup中介原语本文选用基于 URL 的查找方法,只需要添加一个ProxyGroup的名字,那么在Server上部署之后,便会自动在BSpace的ProxyGateway Widget中创建该ProxyGroup。之后需要登录BSpace Console,通过ProxyGateway Widget添加Virtual Service和真实地址之间的映射。如下 图 8 和 图 9 所示:

图 8. 配置 GatewayEndpointLookup 中介原语

图 8. 配置 GatewayEndpointLookup 中介原语

图 9. 在 ProxyGateway widget 中配置 Virtual Service

图 9. 在 ProxyGateway widget 中配置 Virtual Service
 
图 9. 在 ProxyGateway widget 中配置 Virtual Service

  (3) 对于SLACheck中介原语,需要指定Endpoint、Consumer ID和Context ID存放的Xpath路径来作为SLA的限制条件,同时在WSRR服务器上进行SLA相关的配置,这样在运行时SLACheck中介原语才能在WSRR服务器上查找到匹配这些条件的服务。本例的配置如下 图 10 所示:

图 10. 配置 SLA Check 中介原语

图 10. 配置 SLA Check 中介原语

  接下来是Response Flow的设计,这一部分相对比较简单,如下 图 11 所示:

图 11. Response Flow 的设计图 11. Response Flow 的设计

图 11. Response Flow 的设计

  从Request Flow的设计可以明显看出,在ServiceGateway的Mediation Flow中支持了Fault Flow的路由,对于应用服务中抛出的业务异常(ServiceBusinessException)能够正确的路由到Fault Flow,这是WESB 7.0对业务异常处理的重大完善,以前版本中是不支持这一点的。另外和 Request Flow 一样,所有 Input 节点都需要Enable如上 图 7 所示的Gateway BodyAware属性,这么做主要是为了运行时异常(RuntimeException)处理的方便。如果使用了ServiceGateway的BodyAware功能,运行时异常处理只需要借助于CustomMediation中介原语使用少于 10 行的Java代码即可实现。这里以GatewayEndpointLookup中介原语的noMatchFault为例,其Java代码如下 清单 1所示:

  清单 1. 运行时异常处理Java代码示例
    

以下是引用片段:
 // create newBody 
 ServiceMessageObjectFactory factory = ServiceMessageObjectFactory.INSTANCE; 
 DataObject newBody = factory.createServiceMessageObjectBody(new QName( 
 “http://JAM2010Lib/GenericFaultInterface”, “FaultOp_fault1Msg”)); 
 // create faultBO 
 DataObject exception = DataFactory.INSTANCE.create(“http://JAM2010Lib”, “FaultType”); 
 exception.setString(“name”, “CustomException”); 
 exception.setInt(“msgType”, 1); 
 exception.setInt(“errorCode”, 802); 
 exception.setString(“errorMsg”, “Can not find service in Built-in configuration store of 
     BusinessSpace in GatewayEndpointLookup1 primitive.”); 
 // set SMO 
 newBody.set(0, exception); 
 smo.setBody(newBody); 
 // print SMO 
 System.out.println( com.ibm.wsspi.bo.BOPrinter.INSTANCE.toXMLString(smo) ); 
 out.fire(smo); 

   
  第三步,创建业务能力模块。

  本文中业务能力模块如前面所述,只选取手机邮箱、下载和铃声三个应用服务作为示例,分别创建三个模块,采用Java Componnet实现,创建SOAP 1.1或SOAP 1.2的Export。其原理比较简单,图 12 是手机邮箱业务能力模块的组装图,其它业务模块的详细信息请参见下载中附件。

图 12. 手机邮箱模块的组装图

图 12. 手机邮箱模块的组装图

  第四步,创建业务调用端。

  对于业务调用端,本文采用Web Service Java客户端,使用Axis2的API封装SOAP消息,其详细源代码请参看下载中附件。这里仅给出业务调用端的SOAP请求消息示例,如下 表 2所示:

  清单 2. SOAP 请求消息示例

以下是引用片段:
    
 <?xml version=”1.0″ encoding=”utf-8″?> 
 <soapenv:Envelope > 
 <soapenv:Header > 
  <ns1:HeaderType> 
    <level>Gold</level> 
    <callerUID>caller_01</callerUID> 
    <callerSID>caller_openLog</callerSID> 
    <providerSID>provider_mailbox11</providerSID> 
    <providerEID>provider_mailbox11</providerEID> 
    <timeStamp>3/11/10 17:08:59:903 CST</timeStamp> 
  </ns1:HeaderType> 
 </soapenv:Header> 
 <soapenv:Body> 
  <ns1:getMailSize > 
    <ns1:input1> 
      <id>testMailBox001</id> 
      <msgType>0</msgType> 
      <opName>getMailContent</opName> 
      <msgContent>This is the request content of the mail.</msgContent> 
    </ns1:input1> 
  </ns1:getMailSize> 
 </soapenv:Body> 
 </soapenv:Envelope> 

  总结

  综上所述,本文给出了使用WESB 7.0新功能便捷实现服务综合网关的具体步骤。其中涵盖了业务能力调用、消息检验、动态路由、日志记录、SLA校验和异常处理等重要功能。可以明显看到基于ServiceGateway功能的增强和SOAP异常处理机制的完善,再加上Gateway BodyAware等新功能的协助,原本繁琐的实现步骤变的简单快捷,在完善产品功能的同时大大提高了WESB产品的易用性,同时也增强了用户体验。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

相关推荐