Web服务组合标准规范的研究，本文主要内容关键词为：组合论文,标准规范论文,Web论文，此文献不代表本站观点，内容供学术参考，文章仅供参考阅读下载。
【分类号】TP393 G250
1 引言
Web服务是一种部署在网络上的应用程序。它的出现代表了分布式计算的最新要求，从而实现信息的共享、数据交换和系统集成。近年来Web服务技术得到快速发展和应用，成为实现互操作的一种主要机制，得到产业界和学术界的广泛认可。
单个的Web服务功能单一，不能提供完整的解决方案，为了实现复杂的业务逻辑，就必须对Web服务进行组合和集成，Web服务只有通过组合成为更大粒度的服务，才能充分发挥Web服务的潜力和作用。Web服务组合的目标就是解决Web服务之间的集成和协作问题，服务组合现已成为国内外工业界和学术界的研发热点。
2 服务组合标准规范及其发展
Web服务技术的核心标准SOAP(Simple Object Access Protocol)、WSDL(Web Service Definition Language)和UDDI(Universal Description,Discovery and Integration)都是基于XML和Internet技术的，并且是构建Web服务的基础。Web服务组合技术的标准是建立在Web服务技术的核心标准之上的。由于Web服务组合的基础是对服务逻辑(包括服务过程、包含的基本服务、基本服务之间的交互机制等)的描述，所以人们开发了一系列服务组合标准规范，支持对服务逻辑进行有效和规范的描述。
Web服务组合技术的标准规范包括WSFL(Web Service Flow Language)、XLANG、BPML(Business Process Modeling language)、WSCI(Web Service Choreography Lnterface)、WS-CDL(Web Services Choreography Description Language)和WS-BPEL(Web Services Business Process Execution Language)等。
2.1 服务组合技术演变过程
Web服务组合标准规范在近几年的发展过程可以用Web服务组合标准的演化过程图描述，如图1所示。
2002年6月，BEA、Intalio、SAP和Sun发布了基于XML的Web服务协作接口WSCI。WSCI描述了在特殊流程中通过Web服务实现消息流的交流，并描述了集合性信息在互动的Web服务间的交流，提出了一种涉及到多种Web服务的复杂流程的观点。随着参与WSCI的几个厂商如BEA、SAP和SUN加入到WS-BPEL的制定工作中，WSCI基本上没有了发展空间。WS-CDL[2] 是通过万维网联盟(Word Wide Web Consortium,W3C)标准过程来实现其功能的，它将为多服务交互作用提供更为整体的编排组合。尽管WS-CDL现在还不成熟，工具也欠缺，但WS-CDL有可能成为下一代SOA中服务编排组合的关键技术。WS-CDL和WSCI属于Web服务业务协作层次的集成，BPML利用WSCI来描述公用接口和编排方法。目前，由于推动以上标准制定工作的主要参与者基本都已加入了WS-BPEL标准规范的制定工作，所以，WS-BPEL标准规范的发展最为迅速。
WS-BPEL由WSFL和XLANG演变而来。WSFL是由IBM提出的，运用流程将多个Web服务组合成新的具有工作流性质的Web服务，并且支持业务过程描述的XML语言。XLANG是由微软(Microsoft)提出的基于Web服务的业务过程自动化规范，定义了参与业务过程的各Web服务之间行为的消息交换准则。2002年8月，IBM、Microsoft和BEA联合提交发布了BPEL4WS(Business Process Execution Language for Web Services)的第一个版本，以取代WSFL和XLANG。2003年4月，为了进行BPEL4WS的标准化工作，OASIS组建了专门的技术委员会。2003年5月，SAP和Siebel Systems加入并共同推出BPEL4WS1.1版。其后，BPEL4WS改名为WS-BPEL，SUN和ORACLE也加入了制定WS-BPEL标准的行列。随着众多参与者的加入，WS-BPEL得到了很大的发展。目前，WS-BPEL2.0的草案已被提交OASIS等待批准。
2.2 BPML
BPML[3，4]是由BPMI.org(Business Process Management Initiative)所发展的一个Web服务组合标准，最初是用于建立基于标准的e-Business过程管理，目前主要应用于EAI和Web服务组合。BPML包括对控制流、数据流和事件流的全面支持。它利用以下组件来进行服务组合：过程(Processes)、活动(Activities)、上下文(Contexts)、特性(Properties)和信号(Signals)。BPML从2002年11月发布以后再没有较大的进展。
一个过程是一个复杂活动。一个过程如果能独立于其它过程而定义，被称为顶层过程(Top-level Process)；一个过程如果被定义在其它过程中执行，被称为嵌套的过程(Nested Process)。此外，BPML中还有两种特殊过程：例外过程(Exception Processes)和补偿过程(Compensation Processes)。
活动是执行特殊功能的组件，若干个活动组成一个过程。BPML定义了简单活动(AtomicActivity)和复杂活动(ComplextActivity)，简单活动是一种元活动，而复杂活动能拆分成更小的简单活动。上下文在BPML中非常重要，它定义了相关活动执行的环境，可以用来交换信息和调整活动执行方式。
特性是用来交换信息的，它只存在一个上下文中。一个特性定义有一个名称和一个类型，每个特性实例都有一个对应定义类型范围内的值。
2.3 WSCI
WSCI[5] 是由BEA Systems和BPMI.org等在2002年6月提交给W3C，作为一种基于XML的接口描述语言，描述了一个Web服务与其它Web服务组合时所导致的被交换的消息流。通过复用被定义为一个静态接口的操作，WSCI描述了参与一个给定消息交换的Web服务的动态接口。
WSCI在2002年8月作为一个草案递交给W3C。此后W3C成立了一个被称为Web服务工作组的新工作组开展Web服务活动。WSCI规范是WS-CDL形成的基本输入之一，WS-CDL是W3C工作组当前的运行基础。
WSCI位于WSDL的上层，它定义了包括WSCI活动在内的Web服务操作。动作经常用于定义一个基本的请求和回复消息。外部服务通过调用来实现。WSCL也支持约束与例外情况的处理。WSCI对一个Web服务看得见的行为的描述，是根据在被交换消息、特征化先后顺序规则、相互关系、例外处理和事务处理中临时的和逻辑的依赖性来表示的。WSCI也描述了相互作用的Web服务中集体的消息交换。因此，它提供了一个全局的、面向消息的相互作用观。
WSCI不从事实际驱动消息交换的内部过程的定义和实现。更确切地说，WSCI的目标是通过面向接口的消息流来描述一个Web服务看得见的行为。这种描述使得开发者、构建者和工具通过理解与Web服务的相互作用，从而能描述和组成动态消息交换的全局观。
WSCI与BPML两者之间存在实质性的重叠。WSCI支持的简单活动有：call、delay、empty、fault和spawn，支持的复杂活动有：all、choice、foreach、sequence、switch、until和while。WSCI是对BPML的一种补充。WSCI定义了在多个系统部署的服务之间的相互作用，而BPML定义了每个服务后面的业务过程并把业务活动映像到了消息交换。
2.4 WS-CDL
WS-CDL[2] 是一种基于XML的Web服务组合编排语言，通过定义Web服务参与者的一般行为，描述了Web服务参与者之间P2P的合作。WS-CDL不是一种可执行的业务过程描述语言，因此，它不依赖于任何特殊的业务过程执行语言和支撑平台，能用来定义各种类型Web服服务参与者之间的可互操作的P2P合作，使参与者各自由完全不同的语言来实现。第一个WS-CDL规范说明在2004年4月发布。目前，WS-CDL只是W3C提出的一个工作草案。
在WS-CDL描述的主体——流程编排模型(Choreography Model)中，一个服务组合中有若干个参与者(Participants)，它们各自在这个服务组合中担当一定的角色(Roles)，而这些角色之间存在一定的关系(Relationships)。一个参与者可能担当两个或更多不同的角色，因而与担当其它角色的其它参与者之间构成了复杂的关系。
WS-CDL描述服务组合的基本工具是组合流程(Choreography)，每个流程由一个基本流程(Base Choreography)和可能的若干个子流程(Sub-choreographies)组成，描述业务过程之间的合作过程。一个流程包含一个或若干个工作单元(Work Units)，实际完成流程规定的工作任务。每个工作单元中必须包含一个(且只包含一个)活动(Activities)，活动定义执行实际的操作逻辑，包括：交互(Interaction)，执行参与者间的消息交换，可以是单向方式(One-way)，也可以是请求/应答方式(Request/Response)；执行(Perform)，执行一个已被定义的流程；赋值(Assign)，在一个角色中给一个变量赋值；暂停(No Action)，在该流程点不采取任何行动。
控制结构(Control Structures)则把各种活动按照服务逻辑排序，说明流程中各个活动的顺序关系，包括线性顺序(Sequence)、并行(Parallel)和选择(Choice)。控制结构可以嵌套。
WS-CDL定义了一系列工具来描述有关信息，例如类型(Types)，描述在一个流程中使用的信息的类型；变量(Variables)，用以捕获一个流程中关于对象的信息，有信息交换变量(Information Exchange Variables)、状态变量(State Variables)和通道变量(Channel Variables)之分；记号(Tokens)，一个变量或消息中的一块数据的别名。
为了处理例外情况，WS-CDL还设置了流程恢复机制，它由流程例外模块(Choreography Exception Block)和流程终结模块(Choreography Finalizer Block)构成。流程例外模块描述了当一个流程遭遇故障(Faults)、以至无法继续执行时应该采取的恢复行为；流程终结模块描述了当一个流程遭遇故障，必须抵消前面已成功完成的流程时所应采用的逆向终结行为。
2.5 WS-BPEL
由IBM、BEA和Microsoft共同推出Web服务的业务过程执行语言BPEL4WS1.0版，2003年4月6日交给OASIS组织审查并正式公布1.0版本，并且成立BPEL4WS技术委员会，决定未来规范的发展方向。该委员会致力于产生一种用于编写Web服务控制逻辑的，独立于平台的、基于XML的编程语言。2003年5月3日由BEA、IBM、Microsoft、SAP及Siebel Systems五家公司完成BPEL4WS1.1[6] 的版本。
BPEL4WS是为组合Web Services而制定的规范标准。本质上来说，是IBM公司WSFL和Microsoft的XLANG的结合，WSFL支持图形化的流程，微软的XLANG在结构化构造方面有独到的方法，BPEL4WS吸取两者的优点，同时摒弃复杂繁琐的部分，形成较为自然的描述业务流程的抽象程度较高的流程描述语言。BPEL4WS语言规范中没有任何与底层网络协议相关的部分，所有的信息传输都是基于SOAP协议来完成的。
BPEL4WS1.1版本推出后，技术委员会又对BPEL4WS1.1做了大量的修改工作，使之得到全面的提高。随后，推出Web服务业务流程执行语言2.0规范草案，把BPEL4WS语言改称为WS-BPEL[7](Web Services Business Process Execution Language)。根据网上公示得到的评论以及反馈回来的广泛的意见，技术委员会又对WS-BPEL规范进行了进一步的修改。2007年1月，WS-BPEL技术委员会把经过批准修改后的规范作为委员会草案，提交给OASIS组织，要求批准成为正式的OASIS标准。下面重点讨论WS-BPEL。
3 WS-BPEL技术规范
WS-BPEL是为组合Web服务而制定的一项规范，它能够描述由Web服务参与的复杂业务流程，同时又能将Web服务组合而进一步包装成为更高级别的Web服务并发布出去。WS-BPEL定义了用来描述基于流程及其相关方之间互操作的业务流程行为的模型和语法。WS-BPEL流程定义了这些相关方之间的多重服务互操作是怎样被协调起来达成业务目标的，以及这种协调所需的状态和逻辑。
3.1 WS-BPEL活动介绍
业务流程通过〈receive〉活动和相应的〈reply〉活动把服务提供给它的伙伴。〈receive〉活动是让业务流程等候匹配信息到来。〈receive〉活动指定了它期望从哪个伙伴那里接收，还指定了它期望伙伴调用的端口类型和操作。
〈receive partnerLink=" ncname" portType=" qname" operation=" ncname" variable=" ncname" ? createInstance=" yes｜no" ? standard-attributes〉
standard-elements
〈correlations〉?
〈correlation set=" ncname" initiate=" yes｜no" ? 〉+
〈/correlations〉
〈/receive〉
〈reply〉活动被用来发送对先前通过〈receive〉活动被接受的请求的响应。〈reply〉活动是让业务流程在内部信息活动，即〈receive〉、〈onMessage〉或〈onEvent〉收到信息后，发出一条信息作为回答。
〈reply partnerLink=" ncname" portType=" qname" operation=" ncname" variable=" ncname" ? faultName=" qname" ? standard-attributes〉
standard-elements
〈correlations〉?
〈correlation set=" ncname" initiate=" yes｜no" ? 〉+
〈/correlations〉
〈/reply〉
限于文章篇幅，下面仅介绍3项活动的功能。
(1)基本活动。〈invoke〉活动是让业务流程在相关方给出的portType上调用单向操作或请求-应答操作。〈assign〉活动是用于使用新数据更新变量的值。〈validate〉活动用于使针对其相关的XML和WSDL数据定义的变量值生效。〈throw〉活动用于在业务流程内部生成故障。〈wait〉活动用于等候一段给定的时间，或是等到达到某一特定时间点。〈empty〉允许您在业务流程中插入“no-op”指令。〈exit〉活动是用于当某业务流程实例中包含〈exit〉活动时，立即终止它。〈rethrow〉活动是用来将原来被立即装入的faultHandler抓到的故障再次弃除。〈extensionActivity〉元素是用来通过引入新的活动类型来扩展WS-BPEL。
(2)结构化活动。〈sequence〉活动是用来定义一组活动按词法顺序执行。〈if〉活动是用来在一组选择中确切地选出一个活动来执行。〈while〉活动是用来定义当指定的条件为真时重复子活动。〈repeatUntil〉活动是用来定义重复子活动，直到指定条件为真。〈repeatUntil〉活动至少用来执行子活动一次。〈forEach〉活动将子范围活动恰好重复N+1次。〈pick〉活动是用来阻塞等待某一个合适的消息的到达或超时警报响起。〈flow〉活动允许指定一个或多个被并行执行的活动。〈scope〉活动是用来定义嵌套活动。
(3)补偿活动。〈compensateScope〉活动是用来对一个已经成功完成的指定的内部范围启动补偿。〈compensate〉活动是用来按照默认的顺序，对所有已经成功完成的内部范围启动补偿。
3.2 伙伴链接(Partner Links)、伙伴链接类型(Partner Link Types)和终端引用(Endpoint References)
业务流程与伙伴的关系通常是对等的，这需要在服务级别上有双向的相关性。换句话说，伙伴表示由业务流程提供的服务的消费者，同时，对于业务流程来说，伙伴又表示服务的提供者。伙伴链接这个概念被用来直接模拟对等伙伴关系。为了定义与伙伴的关系形式，伙伴链接定义了在交互的两个方向上用到的消息和端口类型。然而，实际的伙伴服务可以在流程中被动态地确定。为了表示描述伙伴服务终端所需的动态数据，WS-BPEL定义了终端引用这个概念。
(1)伙伴链接类型。为了描述两个服务间的关系，伙伴链接类型定义了关系中每个服务所扮演的“角色”并指定每个角色所提供的端口类型(portType)。如果伙伴链接类型声明链接了两个不同服务的portType，那么伙伴链接类型声明可以被放在单独的WSDL文档中。
下面举例说明伙伴链接类型声明的基本语法：
〈partnerLinkType name=" BuyerSellerLink"
xmlns=" http:// schemas.xmlsoap.org/ws/2003/05/partner-link/" 〉
〈role name=" Buyer" 〉
〈portType name=" buy:BuyerPortType" /〉
〈/role〉
〈role name=" Seller" 〉
〈portType name=" sell:SellerPortType" /〉
〈/role〉
〈/partnerLinkType〉
定义伙伴链接类型的语法如下：
〈definitions name=" ncname" targetNamespace=" uri"
xmlns=" http:// schemas.xmlsoap.org/wsdl/"
xmlns:plnk=" http:// schemas.xmlsoap.org/ws/2003/05/partner-link/" 〉
〈plnk:partnerLinkType name=" ncname" 〉
〈plnk:role name=" ncname" 〉
〈Plnk:portType name=" qname" /〉
〈/plnk:role〉
〈plnk:role name=" ncname" 〉?
〈plnk:portType name=" qname" /〉
〈/plnk:role〉
〈/plnk:partnerLinkType〉
〈/definitions〉
(2)伙伴链接。在WS-BPEL中，与业务流程交互的服务被模拟成伙伴链接。伙伴链接由partnerLinkType来描述。同一个partnerLinkType可以描述多个伙伴链接。例如，某个采购流程可以在它的事务中使用多个供应商，但是对于所有的供应商都使用相同的partnerLinkTyp。
〈partnerLinks〉
〈partnerLink name=" ncname" partnerLinkType=" qname" myRole=" ncname" ? partnerRole=" ncname" ? 〉+
〈/partnerLink〉
〈/partnerLinks〉
当一个伙伴链接表达两个伙伴流程之间的会话关系时，通常业务伙伴的关系需要建立多个会话关系。为了表示业务伙伴的性能，WS-BPEL使用partner元素。一个partner被定义为流程的伙伴链接的一个子集。定义伙伴的语法如下：
〈partners〉
〈partner name=" ncname" 〉+
〈partnerLink name=" ncname" /〉+
〈/partner〉
〈/partners〉
(3)终端引用。终端引用的基本用途是作为一种机制，用于服务的特定于端口的数据的动态通信。可以使用终端引用在WS-BPEL中动态地为某个服务类型选择提供者和调用它们的操作。
3.3 WS-BPEL特点
(1)从总体上看，WS-BPEL 2.0的可扩展性变得更强了，WS-BPEL 2.0加入了新的活动，并且在流程中增加了新的属性，使得流程的表达更加灵活，此外，一些元素包括属性的命名也更加规范。
(2)在修改业务流程和Web服务时不会影响应用程序中的其他业务流程或Web服务。
(3)应用程序的开发和测试可以分为两个阶段，业务流程的开发和测试与单个Web服务的开发和测试是分开的。在创建和修改应用程序时，这种方法提供了很大的灵活性。
(4)WS-BPEL可以在不影响应用程序自身的情况下调整已部署的应用程序，能够快速适应应用环境变化的需要。
4 结语
数字图书馆作为由众多分布、异构和自主的资源与服务组成的开放环境，需要灵活适应具体问题环境或具体业务流程，动态发现、调用和组合相关资源与服务，提供能满足用户需求的服务。Web服务技术为数字图书馆提供了一种公共机制，在开放环境下发现和调用所需要的资源或服务。但是，用户所需要的服务可能不能直接为某个Web服务所满足，这时，需要利用Web服务组合技术，将若干Web服务按照一定逻辑组合后满足用户需求。因此，Web服务组合技术对数字图书馆具有重要的应用价值[8，9]。