使用SCA Web服务绑定传递SOAP Header

日期: 2008-01-22 来源:TechTarget中国

  1. 引言

  随着SCA (Service Component Architecture)规范的广泛推广, SCA编程模型和IBM 支持SCA的产品系列如WebSphere Process Service(WPS),IBM WebSphere Enterprise Service Bus(WESB)越来越多的应用于实际的大型IT生产环境和业务集成中。SCA组件对业务数据进行操作,并使用统一的数据格式——SDO(Service Data Object)来表达业务数据,并在SCA组件之间进行传递。

  但是在许多实际项目运营过程中,搭建单纯的符合SCA规范的IT架构一般难以实现,基于SOA可重用理念,很多情况下需要实现SCA组件和外部非SCA模块之间的集成,而这些模块往往是基于已有的J2EE平台实现的EJB、JMS终端或者能够接受SOAP消息的Web Service。IBM WebSphere Integration Developer(WID)在集成图(Assembly Diagram)上提供了SCA导入组件来引用外部的各种类型的服务组件,以及SCA导出组件来将内部的SCA组件暴露为可以和外部多种模块交互的服务接口,而所有这些交互类型都通过导入、导出组件上的绑定(Binding)类型来指定。截止到2007年初IBM发布的WID V6.0.2,用户可以指定的绑定类型包括:

  1)SCA 绑定

  2)Web服务绑定

  3)无状态Session Bean绑定

  4)消息绑定,包括JMS 绑定,MQ 绑定,MQ JMS 绑定

  本文侧重于SCA导入、导出组件中对Web Service Binding的应用。该绑定能够在标准SOAP消息和SDO之间进行格式转换。SDO在进入SCA世界后被包装了相关的SCA协议头而成为在SCA组件之间传递的SMO(Service Message Object)。理论上来讲,SMO应该有完整的元数据格式以映射到SOAP的Schema,其中除了用于传递功能性调用的SOAP Body外,用于携带QoS以及非功能需求的SOAP Header也是重要的组成部分。WID的实现也确实做到了这一点,但是笔者在组内的项目中经历了一番挫折才认识到WPS运行时环境对实现SOAP Header在SOAP和SMO之间传递的特殊配置要求。本文就是想共享这方面的经验,希望无论是从事实际项目开发的软件工程师,还是在实验室中从事相关课题技术探索的研究人员能够从中获益,节省宝贵的研发时间。

  2. 一个典型场景

  笔者通过对所从事的项目进行技术抽象,得出以下的典型场景:

 
  图1 一个典型的使用SCA中间模块基于SOAP Header进行服务选取的场景

  如图1所示,假设一个Web服务请求客户端需要请求两个Web服务:Echo Web服务1和Echo Web 服务2。这两个Web服务虽然都提供了回应请求字符串的功能,但是他们的接口描述不同。该场景希望对服务请求进行中介,并选取了SCA中介模块来实现服务请求的路由、请求消息转换,面向服务请求客户端屏蔽中介细节,提供统一的服务调用界面。并且,服务请求客户端可以通过在Web服务请求的SOAP Header中嵌入路由信息,来标明每次请求所希望调用的远程Web服务。

  该场景虽然只是一个技术抽象,但是可以被赋予多种IT内涵和业务语义,比较典型的有:

  基于WS-Policy服务非功能属性的服务匹配和选取。在这种情况下,每个被选取的Web服务都通过WSDL绑定声明了不同的WS-Policy断言。只有客户端SOAP请求中所携带的非功能性需求与当前服务的WS-Policy断言能力相符,该服务才可以被匹配从而进行调用。而一般情况下这种动态服务选取会将备选的Web服务元数据(包括WSDL,XSD以及WS-Policy)发布到一个元数据注册中心(目前IBM推荐的主流产品是WebSphere Registry & Repository),由请求中介在运行时进行查询匹配(WID V6.0.2已经有中介组件支持对WSRR的查询)。已有的基于WS-Policy框架的服务策略规范(如WS-RM, WS-Security等)都将每次服务调用中的非功能需求嵌在SOAP Header中,在这种情况下,服务中介必须实现基于SOAP Header的服务匹配;

  WebSphere Business Services Fabric(WBSF)是IBM新近推出的支持业务领域服务及服务策略建模、开发和运行时支持的新款产品。该产品已经在保险业得到广泛应用,并且成为IBM在SOA监管(Governance)方向的核心产品之一。基于该产品开发的业务策略也和每个备选的Web服务关联,并要求服务请求的SOAP Header中嵌入相应的与业务相关的选择条件,从而由WSBF做运行时策略使能,完成服务的选取。WSBF在未来也将架构于WPS/WESB之上,因而也面临本文所提及的问题。

  本文的目的不是介入以上对相关IBM产品和Web服务规范应用的讨论,因而采用图1的简单的技术抽象来说明如何解决使用SCA Web服务绑定来传递SOAP Header这一问题。以下在第3节中将给出通常情况下使用WID来实现满足图1要求的SCA中介模块的基本做法,并说明问题所在;在第4节中将对第3节的配置进行修改,从而解决问题。

  3. 初配SCA 中介模块——SOAP Header丢失

  3.1 安装供选择的Web服务

  从文章的“下载”一节中下载得到两个Echo Web服务的EAR文件EchoEJB1EAR.ear和EchoEJB2EAR.ear,并依照以下步骤安装并启动两个Echo Web服务:

  启动WID后,切换到“J2EE” 视图,在Servers子窗口中选择“WebSphere ESB Server V6.0”并启动该服务器;

  选择“File->Import->EAR file”,并导入以上两个Echo Web服务的EAR文件到当前的工作台中;

  在Servers子窗口中右键点击“WebSphere ESB Server V6.0”,选择“Add and remove projects…”,并在弹出的窗口中选择添加“EchoEJB1EAR”和“EchoEJB2EAR”到WESB中。

  至此,两个Echo Web服务已经成功完成了在WESB服务器中的安装和启动。

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

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

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

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

相关推荐