前面两部分
Holt Adams 解释了 Web 服务异步操作相关性并讨论了
些构建异步服务模式
现在他要开始讲解 3个新规范标准 ― Web 服务业务流程执行语言(Business Process Execution Language for Web Services)、Web 服务协调(Web Services Coordination)和 Web 服务事务(Web Services Transaction)― 并介绍说明它们如何为 Web 服务开发者提供许多可能性您将看到这 3个规范标准如何支持异步操作并创建个反映实际业务交互可运行编程环境对于想使用 Web 服务来集成他们所在
企业和其伙伴的间业务流程 IT 设计师和业务分析师来说日子只是好过了点点在这个系列第篇文章中我提到过“随着业界进步开发决定如何协调 Web 服务间流以及如何描述实现业务流程 Web 服务间相关性规范标准对异步操作支持将被简化”那么猜下刚刚发生了什么事？8 月 9 日IBM、Microsoft 和 BEA 发布了共同开发组用于向 Web 服务添加业务语义规范标准这 3个规范标准被发布到了整个业界以进行进步开发同时发布还有些逐条列出要满足各项额外功能计划这些计划目是启动满足组非常重要客户流程和事务要求所需标准化过程这些规范标准是 Web 服务业务流程执行语言(BPEL4WS 或 BPEL)、Web 服务协调(WS-Coordination 或 WS-C)和 Web 服务事务(WS-Transaction 或 WS-T)这 3个规范标准确实能使企业用个全面模型来描述他们业务流程并且还提供了个用来执行该模型、协调业务活动和事务行为实现框架本文将概述下 BPEL、WS-C 和 WS-T 规范标准如何简化对异步操作支持更重要是您还将了解这些规范标准如何描述和实现这样企业业务交互这些业务交互通常在涉及到两方或更多方、长时间运行有状态交互中进行系列点对点消息交换企业业务交互在本系列前面
文章中我介绍了异步 Web 服务操作些概念同时还介绍了用来实现双方的间各个异步操作各种集成模式这些模式本质上是被建模为无状态、独立交互在这些模式中我提出了参和应用
或消息传递传输在将请求映射到响应时要创建和管理相关器要求同样解决方案设计者也需要提供种思路方法通过这种思路方法把 回复地址(reply-to address)(响应将被发送到这个地址)提供给服务提供者；这样当响应可用时就可以在分开执行线程上把它们发送到请求客户机所有这些要求以及其他更为重要要求(比如协调组有状态交互和将请求路由到有状态流程例子等要求)都将在新规范标准中得到满足于是我们就可以在 业务流程引擎(business process engine)内对复杂、实际企业流程进行建模和直接执行(更多时候是在引擎上立即执行) 目前
Web 服务描述语言(Web Services Description LanguageWSDL)规范标准版本 1.1 自身(不包括扩展)只支持无状态交互模型按这种模型在两方的间交换同步消息或相互的间无关联异步消息这 3个新规范标准发布使得这样企业业务流程有可能得到支持这些企业业务流程要求涉及到在两方或更多方的间有状态且长时间运行交互中进行点对点消息交换序列(同步和异步)交互模型在进
步学习本文的前您应该对 BPEL、WS-C 和 WS-T 规范标准有个基本理解
我们将在这里探讨来自这些规范标准许多概念异步操作要求:回顾支持实际
企业业务流程本质上要涉及到异步操作这些流程持续时间比较长每个流程各个活动都需要和
请求分开以优化系统资源使用并且需要把处理过程分解为组可恢复事务我在这个系列第篇文章中提到过支持异步操作需要完成下面几个任务:为它们
交换定义个或组相关器和种机制定义
个 回复地址这个地址指定应该把响应发送到何处并确保向服务提供者通知了这个目地 服务提供者生成响应
过程作为个事务和请求分开客户机接收到异步响应
客户机和服务提供者把响应和相应
请求关联在起另外
由于我将在可能涉及到流程及其伙伴间许多交互较大型有状态业务事务范畴内讨论异步操作在异步操作期间交换消息将需要被路由到同个业务流程例子因此我还需要提出先前这个系列第篇文章中没有列入另个要求:把请求路由到有状态业务流程例子
BPEL XML 语法元素
本文将概述 BPEL 如何为长时间运行
业务事务简化集成伙伴间业务流程过程其中个业务事务由流程及其伙伴的间多个交互组成在下面几部分中我将提供可以用来满足上面标识出异步操作要求具体 BPEL XML 语法举例BPEL XML 流语言具有用来对活动和用于控制流程行为
机制进行描述语法在我举例中我将使用这种语法个子集这个子集中包含下面 活动标记(activity token)和 元素(element): 基本活动(Basic activity):用于处理入站请求和响应
接收、数据向全局容器分配以及出站 Web 服务请求生成本文将演示这些活动举例包括 receive 和 invoke 结构化活动(Structured activity):用于管理活动序列
整个流程流、活动并行处理以及在控制流程流时添加条件逻辑本文将演示这些活动举例包括 sequence 和 flow 其他
BPEL XML 元素帮助定义支持业务事务中异步操作所需关系和相关性本文将演示这些元素举例包括 partners 、 serviceLinkTypes 、 role 、 link 、 source 和 target 将业务语义应用于 Web 服务意味着什么？
将业务语义应用于 Web 服务实际上是利用 Web 服务
种思路方法这种思路方法允许企业在个可运行编程环境中复制企业和其伙伴在现实生活中具有角色和关系在这个环境中可以通过把企业伙伴所用来自区别供应商业务应用集成在起使手工任务自动化把业务交互中各参和者的间实际关系和相关性反映到 Web 服务客户机和服务提供者是利用动态电子商务价值取向基础当启动实际流程时就开始了组任务其中些任务是并行完成而其他任务则需要顺序执行在流程进行期间可能要涉及到其他业务伙伴把这些业务伙伴输入结合到业务逻辑中以决定流程整体输出结果这种情况非常典型用 BPEL 很容易描述和实现图 1. 业务事务
作用域 
查看原图(大图)
WebSphere
业务流程引擎目前
IBM 在 WebSphere Application Server 内支持业务流程引擎并支持在 WebSphere Studio Application Developer集成版内进行流程流开发WebSphere Application 服务器版本 5 支持取出即可用流程管理您可以从 IBM alphaWorks 站点下载 BPEL 运行时这个 BPEL 运行时可以部署到 IBM WebSphere Application Server 版本 4.0 和更高版本中IBM 打算在将来提供对业务流程规范标准支持以使企业不仅能够使用开放标准流程流语言描述它们流程还能够运行流程描述使用事务协调协议来协调他们伙伴间行为这些协议将提供它们企业和伙伴所要求适当服务质量级别使用 BPEL XML 语法描述
业务流程模型可以由 业务流程引擎来解释和执行业务流程引擎通常是 Web 应用服务器运行时部分；它管理正执行流程流动和控制权流程中每个步骤都将用个 活动来代表；这种活动被实现为外部伙伴服务上个出站 Web 服务
或对个入站 Web 服务请求处理业务流程引擎执行流程模型时会通过它 Web 服务接口创建个可运行流程例子这些流程接口用于启动流程本身或者用于控制流程各个方面(例如等待(wait)、终止(terminate)和补偿(compensate))流程所公开 Web 服务操作在执行和该流程相关联业务任务时可以聚集其他 Web 服务因此流程流将包含流程自身和内部 Web 服务以及外部伙伴 Web 服务的间组 Web 服务交互 长时间运行
业务事务需要异步 Web 服务支持由于以下几个原因
在分布式环境中运行企业业务流程持续时间般比较长:和伙伴
交互因因特网延迟而变慢批处理通常被推给旧
后端系统来承担B2B 解决方案经常需要常规
数据和传输转换由于处理时间
关系和交互相关联 Web 服务请求和响应将依赖异步操作把这两个事件分开BPEL 既支持同步操作又支持异步操作
对于前者可以使用 <reply> 活动标记把对请求响应定义为在同个执行线程上返回但对于长时间运行业务流程(其中许多活动可能是并行运行并且使用了非阻塞线程以提高效率)BPEL 使得流程可以被描述这样就可以使用 <invoke> 活动标记在分开执行线程上生成响应 流程活动
协调就象 WS-C 和 WS-T 规范标准中所提到
那样除了把参和伙伴角色和职责映射到业务流程描述中外还需要使用组公共基础架构服务把分布式环境中所需活动协调和事务支持所具有可运行特征应用到流程实现中去但协调工具和事务工具使用将由业务流程引擎根据 BPEL 流程描述结构来管理因此流程描述本身将不会显式利用规范标准中列出协调和事务服务WS-C 和 WS-T 规范标准列出
工具将使参和者业务流程引擎能够注册些协调协议这些协议确保就已建模业务流程输出结果达成可靠、相互致出于这个原因在本文中我将不讨论为业务流程提供协调和事务方面支持具体工具这些工具实现和管理将依赖于具体业务流程引擎目前
BPEL 支持 业务活动(Business Activity)协调类型这种协调类型考虑到了对持续时间比较长活动协调并使用业务逻辑来通过基于补偿恢复处理业务异常当需要跨区别供应商实现互操作性时以及用简单流程异常终止不适合处理业务异常时这种级别支持是非常重要通常情况下当个活动运行时间较长并且该活动执行操作需要是可恢复这时就用 scope 活动标记来封装该活动这样在必要时候就可以应用补偿来通过 BPEL 中支持补偿处理器机制在该活动内把操作结果恢复为未执行操作时样子这种思路方法既可以应用于同步操作也可以应用于异步操作当实现和 WS-C 和 WS-T 有关工具来支持可以用 BPEL 描述流程行为时我们希望业务流程引擎使用异步操作 对业务伙伴间
异步交互进行建模作为其 XML 语法
部分BPEL 规范标准包含用于定义活动、伙伴、点对点角色、消息交换协议、活动同步相关性机制用于标识相关器消息属性以及用于在执行业务流程过程中共享业务协议数据和其他上下文数据数据容器BPEL 使企业能够为组成流程流每个业务交互对流程自身和参和伙伴间行为建模交互被看作是点对点消息交换(也就是条有显式响应请求、条无响应请求或者单独条单向通知)根据为每个伙伴分配角色为行为赋予些交互方面特征同时为每个角色发送和接收消息这些角色身份根据和每个角色相关 portTypes 操作加以识别有些情况下可能只发送单独条消息(也就是条无响应请求或者条通知) 您可能会觉得上面这段描述在现阶段有点笼统
所以我将回顾些有关如何使用 BPEL 来满足我在上面列出支持异步操作 6条要求具体举例定义回调机制
流程和给定
伙伴(也就是个单独 Web 服务)的间点对点消息交换被看作是它们双方的间根据它们关系进行交互这两方的间关系被建模为 serviceLinkType 其中最多定义两个角色每个角色都必须至少支持个 portType 以使交互能取得成功 清单 1. serviceLinkType 举例
<serviceLinkType name="BuyerSellerLink"
xmlns="http://schemas.xmlsoap.org/ws/2002/07/service-link/">
<role name="ServiceProvider">
<portType name="Serviceprovider:ServicePortType"/>
</role>
<role name="Client">
<portType name="Client:CallbackmechanismPortType"/>
</role>
</serviceLinkType> 如果希望异步响应成为交互
部分就要为 serviceLinkType 标识两个角色如上面清单 1 所示:个用作服务提供者标识所提供服务 portType 个用作请求客户机标识将处理和请求相关异步响应 回调机制(callback mechanism)服务 portType 业务流程使用
Web 服务被建模为 partners ；因此内部服务和外部业务伙伴服务都要应用 partners 定义交互参和者其中每个参和者角色都根据为 serviceLinkType (它对关系进行建模)定义角色来标识 清单 2. partners 举例
<partners>
<partner name="RequestingClient" serviceLinkType="BuyerSellerLink"
myRole="ServiceProvider"? partnerRole="Client"?>+
</partner>
</partners> 这些机制使 IT 设计师和业务分析师可以满足我在本文开头处列出
异步操作第 2 和第 4 条要求利用相关器
大多数情况下
个服务将被回调机制每个参和伙伴使用因此需要把相关器使用定义为业务流程定义部分通常情况下业务协议信息比如客户标识、订单号、供应商标识和发票号将被用于把请求和响应关联起来；当几个交互需要互相关联起来时有时必须把各个相关器结合起来最初交互可能使用客户标识和订单号相关器组合而响应和后续交互可能也包含个发票号相关器由于业务协议数据在实际交互中被用于把业务任务关联在
起因此自然也是使用这种数据把 Web 服务请求和响应关联起来为把业务协议数据作为相关器使用您需要使用流程定义把消息属性定义为已命名数据类型这样您就可以给现有类型赋予更密切相关意思(例如把 OrderNumber 属性定义为 
eger 类型或者把 VendorID 属性定义为 String 类型)旦定义了个属性您就可以指定个 propertyAlias 来根据消息结构(例如通过标识 WSDL <message> 和 <part> 元素)和 XPATH 查询
串标识出特定业务协议数据位于应用消息何处从本质上来说这是在消息内定义了些字段在这些字段中可以找到相关器值 清单 3. property 和 propertyAlias 举例
targetNamespace="http://example.com/supplyCorrelation.wsdl"
xmlns:tns="http://example.com/supplyMessages.wsdl"
xmlns:bpws=http://schemas.xmlsoap.org/ws/2002/07/business-process/
<!-- 
correlation properties -->
<bpws:property name="customerID" type="xsd:
"/>
<bpws:property name="orderNumber" type="xsd:"/>
<bpws:property name="vendorID" type="xsd:"/>
<bpws:property name="invoiceNumber" type="xsd:"/>
<bpws:propertyAlias propertyName="customerID"
messageType="tns:POMessage" part="PO"
query="/CID"/>
<bpws:propertyAlias propertyName="orderNumber"
messageType="tns:POMessage" part="PO"
query="/Order"/>
<bpws:propertyAlias propertyName="vendorID"
messageType="tns:InvMessage" part="IVC"
query="/VID"/>
<bpws:propertyAlias propertyName="invoiceNumber"
messageType="tns:InvMessage" part="IVC"
query="/InvNum"/> 毫无疑问
被用来定位相关器字段必须在每个抽象 WSDL 消息定义内被定义为正式消息部件同样还必须在请求消息和响应消息中定义同样消息部件和 serviceLinkType 各角色相关联 portTypes 各操作必须使用已为的定义了 propertyAlias 消息类型 当依赖不止
段业务协议数据把请求和响应关联在起时BPEL 使您能够把消息属性归入 correlationSets 中并使用已命名 correlationSets 标识流程例子中应用级会话 清单 4. correlationSet 举例
<correlationSets
xmlns:cor="http://example.com/supplyCorrelation.wsdl">
<!-- Order numbers are particular to a customer, this 
is carried in application data -->
<correlationSet name="PurchaseOrder"
properties="cor:customerID cor:orderNumber"/>
<!-- Invoice numbers are particular to a vendor, this is carried in application data -->
<correlationSet name="Invoice"
properties="cor:vendorID cor:customerID cor:orderNumber"/>
</correlationSets> 这些机制使 IT 设计师和业务分析师可以满足上面列表中
第 1、5 和 6 条异步要求使响应消息同步
当服务提供者 ― 在这个案例中
是正在执行用 BPEL 描述业务流程业务流程引擎 ― 接收到个请求(例如多步骤业务事务中次交互)时在执行被业务流程作为 Web 服务公开业务操作时需要执行个或多个
旦处理完成个响应就会被发送到请求客户机该响应包含业务操作结果或表明操作已完成通知假设被执行操作是长时间运行业务事务部分那么这次交互响应将在单独执行线程上被异步提供管理请求
接收、把请求路由到适当流程例子、执行完成个或多个任务流程逻辑、确保流相关性得到满足并且在所有处理完成后立即生成响应 ― 所有这些都可以很容易地用 BPEL 描述出来、用兼容(compliant)业务流程引擎来处理而无需 IT 编程人员开发复杂同步流-控制逻辑他们也不必管理流程状态数据利用相关器
BPEL 使业务流程引擎能够创建新流程例子来处理入站请求或者根据请求内消息属性值把入站请求路由到现有流程例子在可以并行执行多个活动以优化性能流程流中需要使后继相关活动同步为标识同步相关性BPEL 使用活动定义内 links 来控制活动间同步如果个活动输出结果需要作为另个活动输入(或者换句话说个活动必须在另个活动前执行)那么这个活动将把自身标识为个链接 source 而依赖它活动将把自己标识为 target 有了这些信息业务流程引擎就可以管理流程流相互依赖性来控制整体输出结果从而确保和请求客户机相关响应生成是种致行为 清单 5. link、source 和 target 举例
<flow>
<!--Three synchronization links are d -->
<links>
<link name="ReceiveRequest"/>
<link name="XtoY"/>
<link name="CtoD"/>
</links>
<receive partner="RequestingClient">
<source linkName="ReceiveRequest"/>
</receive>
<sequence name="X">
<target linkName="ReceiveRequest"/>
<source linkName="XtoY"/>
<invoke name="A" .../>
<invoke name="B" .../>
</sequence>
<!--Sequence Y is dependent on Sequence X completing -->
<sequence name"Y">
<target linkName="XtoY"/>
<receive name="C"/>
<source linkName="CtoD"/>
</receive>
<invoke name="E" .../>
</sequence>
<!--Invoke partner Requesting Client is dependent on Sequence X and Sequence Y completing -->
<sequence name"D">
<target linkName="CtoD"/>
<invoke partner="RequestingClient"/>
<invoke name="F" .../>
</sequence>
</flow> 
最新评论