500 likes | 684 Views
BPEL4WS. 马殿富 北航计算机学院 200 6-06. 主要内容. BPEL 的基本结构 BPEL 的主要元素 BPEL 基本活动 BPEL 结构化活动. BPEL 简介. 商业流程执行语言 BPEL4WS(Business Process Execution Language For Web Services) 是专为整合 Web Services 而制定的一项规范标准。 描述商业活动的抽象高级语言 IBM 的 WSFL — 支持图形化的流程 Microsoft 的 XLANG — 结构化构造方法 BPEL 描述流程
E N D
BPEL4WS 马殿富 北航计算机学院 2006-06
主要内容 • BPEL的基本结构 • BPEL的主要元素 • BPEL基本活动 • BPEL结构化活动
BPEL简介 • 商业流程执行语言BPEL4WS(Business Process Execution Language For Web Services)是专为整合Web Services而制定的一项规范标准。 • 描述商业活动的抽象高级语言 • IBM的WSFL—支持图形化的流程 • Microsoft的XLANG—结构化构造方法 • BPEL描述流程 • 可执行工作流—描述业务交互中参与者的实际行为; • 抽象流程—描述各方参与者对外可见的消息交换。 • BPEL的作用是将一组现有的服务组合起来,从而定义一个新的Web服务。因此,BPEL基本上是一种实现此种组合的语言。组合服务的接口也被描述为WSDL portType的集合。
内容大纲 • BPEL的基本结构、主要属性、主要元素 • BPEL的活动 • BPEL流程实例的创建与终止 • BPEL流程调用Web服务
业务流程 • 按业务流程之间的协作方式可以分为单工作流模式和多工作流模式; • 单工作流模式把一组相关的服务按一定顺序和条件组合执行,完成某项业务,流程执行过程中涉及的服务不属于其他业务流程; • 多工作流模式是两个或两个以上的工作流程并行执行并进行交互的业务流程模式,多工作流模式侧重于业务流程之间的交互。 单工作流模式 嵌套子流程模式 链型流程模式
BPEL的基本结构 <process name="ncname" targetNamespace="uri" queryLanguage="anyURI"? expressionLanguage="anyURI"? suppressJoinFailure="yes|no"? enableInstanceCompensation="yes|no"? abstractProcess="yes|no"?> <partnerLinks>? ... </partnerLinks> <partners>? ... </partners> <variables>? ... </variables> <correlationSets>? ... </correlationSets> <faultHandlers>? ... </faultHandlers> <compensationHandlers>? ... </compensationHandlers> <eventHandlers>? ... </eventHandlers> activity </process>
BPEL的主要属性 • queryLanguage:指定了在赋值、特性定义和其他使用中用于选择节点的XML查询语言。这个属性的缺省值是XPath 1.0,其代表是XPath 1.0规范的URI:http://www.w3.org/TR/1999/REC-xpath-19991116。 • expressionLanguage:指定了在流程中使用的表达式语言。这个属性的缺省值是XPath 1.0,其代表是XPath 1.0规范的 URI:http://www.w3.org/TR/1999/REC-xpath-19991116。 • suppressJoinFailure:决定是否抑制流程中的所有活动的joinFailure故障。该属性在流程级的作用可以被使用该属性的其他值的活动所覆盖。这个属性的缺省值是“no”。 • enableInstanceCompensation:决定流程实例是否可被作为整体由特定于平台的方式来补偿。这个属性的缺省值是“no”。 • abstractProcess:指定所定义的流程是抽象的(还是可执行的)。这个属性的缺省值是“no”。
BPEL的主要元素 • partnerLinks:合作伙伴链接 • partners:合作伙伴 • variables:变量定义 • correlationSets:相关集定义 • faultHandlers:故障处理程序 • compensationHandlers:补偿处理程序 • eventHandlers:事件处理程序
合作伙伴链接类型 • <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>
伙伴链接类型 • 为了描述两个服务之间的会话关系,伙伴链接类型定义了会话中每个服务所扮演的“角色”,并且指定了每个服务所提供的portType,以便接收会话的上下文中的消息。 • 每个角色的portType可以产生于不同的名称空间,也在产生于相同的名称空间。根据相同名称空间中的portType来定义合作伙伴链接类型的两个角色。 • 伙伴链接类型定义文档可以是独立于任一个服务的WSDL文档的单独构件,也可以被放在定义portType的WSDL文档中,这些portType也被用来定义不同的角色。 • 有些情况下,定义仅包含一个角色的伙伴链接类型是有意义的。在这种伙伴链接情形中,一个服务可以链接任何其他服务。
伙伴链接 • 业务流程交互的服务被描述成伙伴链。每个伙伴链由partnerLinkType来描述。 • 每个伙伴链都被命名。通过该伙伴链的所有服务交互。 • 属性myRole指出了业务流程本身的角色,而属性partnerRole指出了伙伴的角色。如果partnerLinkType仅有一个角色,那么将根据需要省略其中一个属性。 <partnerLinks> <partnerLink name="ncname" partnerLinkType="qname" myRole="ncname"? partnerRole="ncname"?>+ </partnerLink> </partnerLinks>
业务伙伴 • 伙伴链表示两个合作伙伴流程之间会话关系。 • 伙伴partner元素被定义为流程的伙伴链一部分。 • 伙伴定义是可选的,并且不需要包含流程中定义的所有伙伴链。 • 伙伴链绝不可以出现在多个伙伴定义中。 <partners> <partner name="ncname">+ <partnerLink name="ncname"/>+ </partner> </partners>
端点引用 • WSDL的PortType使用抽象消息来定义抽象功能。端口提供实际访问信息,包括通信端点和其他与部署有关的信息。绑定使两者连结在一起。 • 服务的用户必须静态地依赖于由portType定义的抽象接口,但是在通常情况下可以动态地发现和使用端口定义的信息。 • 端点引用的基本用途是作为一种机制,用于服务的特定于端口的数据的动态通信。 • BPEL使用了WS-Addressing中定义的端点引用的概念。流程实例的伙伴链接的每个伙伴角色被分配一个具有惟一性的端点引用,这可以在流程的部署过程中完成,也可以由流程中的某个活动动态地执行。
变量 • 业务流程指定了涉及伙伴之间消息交换的有状态交互。业务流程的状态不仅包括被交换的消息,而且还包括用于业务逻辑和构造发送给伙伴的消息的中间数据。 • 每个变量的类型可以是WSDL消息类型、XML Schema简单类型或XML Schema元素。 • 属于全局流程作用域的变量称为全局变量;属于流程作用域的变量称为局部变量; • 每个变量只有在定义它的作用域和嵌套在它所属于的作用域内的全部作用域中才是可见的 <variables> <variable name="ncname" messageType="qname"? type="qname"? element="qname"?/>+ </variables>
相关集 • 在面向对象领域 • 通过对象引用进行有状态的交互。对象引用本身提供了访问具有合适的交互状态和历史的某个对象(实例)的能力。 • 这种方式适用于紧密耦合的实现。 • Web服务领域 • 引用方式将造成实现之间脆弱的依赖关系; • 需要松散耦合机制实现; • 避免在实例路由中使用特定于实现的标记。 • 在业务流程实例的生存期中,它通常与涉及它的伙伴进行多次会话,相关联的会话涉及的参与者不止两个,常常有必要提供应用程序级的机制,以使消息和会话被匹配到预定的业务流程实例。
相关集 • BPEL提供了声明性机制,以指定服务实例中相关联的操作组。一组相关标记可定义为相关联的组中所有消息共享的一组特性。这样的一组特性称为相关集。 • 每个关联集都在一个作用域中进行声明并属于该作用域。属于全局流程作用域的关联集称为全局关联集;属于局部作用域,这样的关联集称为局部关联集。 • 在流程开始时,全局关联集处于未初始化的状态。在其所属的作用域的执行开始时,本地关联集处于未初始化的状态。 • 相关集在其语义上类似于延迟绑定的常数。相关集的绑定由特别标记的消息发送或接收操作来触发。相关集在其所属的作用域的生存期中只能初始化一次。在初始化之后,它的值就可被认为是业务流程实例的标识的别名。
相关集 • 在多方业务协议中 • 初始者流程发送启动会话的第一个消息,从而定义了标记该对话的相关集中的特性值。 • 所有其他参与者通过接收提供相关集中的特性值的传入消息来绑定会话中的相关集。 • 初始者和其他参与者都必须发送启动会话的第一个消息,从而定义标记会话的相关集中的特性值。 • 相关集的名称用在invoke、receive和reply活动中,也用在pick活动的onMessage分支中,同时还用在事件处理程序的onMessage形式中。 • <correlationSets>? • <correlationSet name="ncname" • properties="qname-list"/>+ </correlationSets>
故障处理程序 • 故障处理是因发生故障而切换到撤销发生故障的作用域中的部分或不成功的工作。 • 故障处理程序提供了定义一组自定义的故障处理活动的方法,句法上定义为catch活动。定义的每个catch活动能拦截某种特定的故障(由全局惟一的故障QName和有与该故障相关联的数据的变量来定义)。如果没有故障名,那么catch将拦截全部有适合类型的故障数据的故障。使用catch处理程序中的faultVariable属性来指定故障变量。 • <faultHandlers>? • <catch faultName="qname"? faultVariable="ncname"?>* • activity • </catch> • <catchAll>? • activity • </catchAll> • </faultHandlers>
故障处理程序 • 对invoke活动的故障响应是故障的来源之一,根据WSDL操作中的故障定义,该故障有显式给出的名称和数据部分。程序化地抛出throw活动是故障的另一个来源,它也有显式给出的名称和数据。
补偿处理程序 • 通过补偿处理程序,作用域可以描述一部分通过应用程序定义的方式可撤销的行为。有补偿处理程序的作用域可不受约束任意深地被嵌套。 • 补偿处理程序仅仅是补偿活动的包装。在许多情况下,补偿处理程序需要接收当前状态的数据并返回关于补偿结果的数据。 • 补偿处理程序的调用方法是使用compensate活动。 • <compensationHandler>? • activity • </compensationHandler>
事件处理程序 • 整个流程以及每个作用域可以与一组在相应的事件发生时并发调用事件处理程序相关联。 • 在事件处理程序中进行任何类型的活动,但是不允许使用<compensate/>调用补偿处理程序。 • 有两种类型的事件: • 与WSDL中请求/响应或单向操作对应的传入消息; • 用户设置的时间过后发出的警报。
事件处理程序 • <eventHandlers>? • <onMessage partnerLink="ncname" portType="qname" • operation="ncname" variable="ncname"?>* • <correlations>? • <correlation set="ncname" initiate="yes|no">+ • </correlations> • activity • </onMessage> • <onAlarm for="duration-expr"? until="deadline-expr"?>* • activity • </onAlarm> • </eventHandlers>
事件处理程序 • onMessage标志表示指定的事件是一个等待消息到达的事件。 • 这个标记及其属性的解释类似于receive活动。partnerLink属性定义请求将到达的合作伙伴链接。portType和operation属性是合作伙伴为引发事件而调用的适当端口类型和操作。变量属性标识包含从合作伙伴接收到的消息的变量。 • onAlarm标志标记超时事件。 • for属性指定该事件发生之前的持续时间。计算持续时间的计时在相关的作用域的执行开始的时刻响起。 • until属性指定发出警报的特定时刻。这两个属性中仅有一个必须出现在任何onAlarm事件中。
内容大纲 • BPEL的基本结构、主要属性、主要元素 • BPEL的活动 • BPEL流程实例的创建与终止 • BPEL流程调用Web服务
BPEL的活动 基本活动 • <receive> • <reply> • <invoke> • <assign> • <throw> • <terminate> • <wait> • <empty> 结构化活动 • <sequence> • <switch> • <while> • <pick> • <flow> • <scope> • <compensate>
receive • <receive>构造业务流程阻塞等待匹配消息的到达 • 实例化业务流程的惟一方法是注解receive活动,把 createInstance属性设置为“yes”。该属性的缺省值是“no”。 <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 • <reply>构造业务流程发送消息以应答通过<receive>接收到的消息。 • receive和reply的组合为流程构成了在WSDL portType上的请求-响应操作。 <reply partnerLink="ncname" portType="qname" operation="ncname" variable="ncname"? faultName="qname"? standard-attributes> standard-elements <correlations>? <correlation set="ncname" initiate="yes|no"?>+ </correlations> </reply>
invoke • <invoke>构造允许业务流程调用由合作伙伴在portType上提供的单向或请求-响应操作。 • 异步调用仅需要操作的输入变量;同步调用既需要输入变量,又需要输出变量。
invoke <invoke partnerLink="ncname" portType="qname" operation="ncname" inputVariable="ncname"? outputVariable="ncname"? standard-attributes> standard-elements <correlations>? <correlation set="ncname" initiate="yes|no"? pattern="in|out|out-in"/>+ </correlations> <compensationHandler>? activity </compensationHandler> </invoke>
assign • <assign>构造的作用是用新的数据来更新变量的值。 • assign可以包括任意数量的基本赋值。 • assign还可把端点引用复制到合作伙伴链接,或把合作伙伴链接复制到端点引用(服务的动态绑定)。 <assign standard-attributes> standard-elements <copy>+ from-spec to-spec </copy> </assign>
assign • from-spec必须是以下形式中的一种: • <from variable="ncname" part="ncname"?/> • <from partnerLink="ncname" endpointReference="myRole|partnerRole"/> • <from variable="ncname" property="qname"/> • <from expression="general-expr"/> • <from> ... literal value ... </from> • to-spec必须是以下形式中的一种: • <to variable="ncname" part="ncname"?/> • <to partnerLink="ncname"/> • <to variable="ncname" property="qname"/>
throw • <throw>构造从业务流程中生成故障。 • 使用throw发出内部故障。每个故障需要有一个全局惟一的QName,还可选提供数据的变量。故障处理程序可以使用这种数据,来分析和处理该故障并植入需被发送到其他服务的所有故障消息。 <throw faultName="qname" faultVariable="ncname"? standard-attributes> standard-elements </throw>
terminate • <terminate>可以用于立即终止该terminate活动在其中运行的业务流程实例。 • 所有当前正在运行的活动必须尽可能快地终止,而没有任何故障处理或补偿行为。 <terminate standard-attributes> standard-elements </terminate> terminate语义 Σ∘s
wait • <wait>构造允许等待一段给定的时间或等到某一时刻。 • 必须确切地指定wait中一个到期条件。 <wait (for="duration-expr" | until="deadline-expr") standard-attributes> standard-elements </wait>
wait语义 • b:= σ(&s, "wait", "for")b=trueΣ∘sΣ∘s • b:= σ(&s, "wait", "for")b=falseΣ∘sΣ • b:= σ(&s, "wait", "until")b=trueΣ∘sΣ • b:= σ(&s, "wait", "until") b=false Σ∘sΣ∘s
empty与语义 • <empty>构造允许在业务流程中插入“no-op”指令。 • empty可用于并行活动的同步。 <empty standard-attributes> standard-elements </empty> Empty语义 Σ∘sΣ
结构化活动 • 结构化的活动规定了一组活动发生的顺序,描述了创建业务流程的基本活动组成的结构,这些结构表达了涉及业务协议的流程实例间的控制形式、数据流程、故障和外部事件的处理以及消息交换的协调。 • BPEL的结构化活动包括: • 顺序控制由sequence、switch和while组成; • 活动之间的并发和同步由flow组成; • 基于外部事件的不确定的选择由pick组成。 • 递归地使用结构化的活动。
sequence • <sequence>构造定义一组按顺序先后执行的活动。 • 执行顺序是sequence元素中被列出活动的先后顺序。 • 当sequence中的最后一个活动完成后,该sequence活动也就完成了。 <sequence standard-attributes> standard-elements activity+ </sequence>
sequence语义 • w:=λ(&s, "sequence\*")w = nil • Σ∘sΣ • w:=λ(&s, "sequence\*")(w = nil) • Σ∘sΣ∘ψ(&s, "sequence\*") • ∘δ(&s, "sequence\*")
switch • <switch>构造允许从一组分支中只选择一个活动分支。 • switch由case元素定义的一个或多个条件分支的有序列表组成,后面可跟也可以不跟一个otherwise分支。 • 以case分支的出现顺序检查,第一个条件是true的分支被选择并被作为被执行的活动。如果有条件的分支都未被选择,那么otherwise分支将被选择。 <switch standard-attributes> standard-elements <case condition="bool-expr">+ activity </case> <otherwise>? activity </otherwise> </switch>
switch语义 • w:= δ(&s, "switch\case") • (w = nil) b:= σ(&w, "condition")b=true • Σ∘sΣ∘λ(&w, "case\*") • w:= δ(&s, "switch\case") • (w = nil) • b:= σ(&w, "condition") • b=false • Σ∘sΣ∘ψ(&s, "switch\case\*")
switch语义 • w:= δ(&s, "switch\case") • w = nil • z:=λ(&w, "switch\otherwise\*") • (z=nil) • Σ∘sΣ∘λ(&s, " switch\otherwise\*") • w:= δ(&s, "switch\case") • w = nil • z:=λ(&w, "switch\otherwise\*") • z=nil • Σ∘sΣ
while <while>构造允许指定反复执行一个活动,直到某个成功条件被满足为止。 <while condition="bool-expr" standard-attributes> standard-elements activity </while>
while语义 • b:= σ(&w, "while", "condition") • b=true • Σ∘sΣ∘s∘λ(&s, "while\*") • b:= σ(&w, "while", "condition") • b=false • Σ∘sΣ
pick • <pick>构造允许阻塞并等待某一个合适的消息的到达或超时警报响起。当其中一个触发器触发后,相关的活动就被执行,pick也随即完成了。 • pick活动等待一组相互排斥事件中的一个事件的发生,然后执行与发生的事件相关联的活动。 • 如果多个事件发生,那么按照时间发生先后或选择原则确定发生事件。 • 当业务流程的实例的创建是由于接收到一组可能的消息中的一个消息而发生的时,可以使用pick的特殊形式。 • 每个pick活动必须至少包括一个onMessage事件。onMessage事件的语义等同于有关变量属性的可选类型的receive活动。
pick <pick createInstance="yes|no"? standard-attributes> standard-elements <onMessage partnerLink="ncname" portType="qname" operation="ncname" variable="ncname"?>+ <correlations>? <correlation set="ncname" initiate="yes|no"?>+ </correlations> activity </onMessage> <onAlarm (for="duration-expr" | until="deadline-expr")>* activity </onAlarm> </pick>
flow • <flow>构造指定一个或多个并行地执行的活动。为了定义任意的控制结构,可以在并行的活动中使用链接。 • flow能进一步表达直接或间接嵌套在其中的活动之间的同步相关性,link构造用来表达这种同步相关性。 • 一个link有一个名称,flow活动的所有链必须在 flow活动中分开定义。活动的标准的source和target元素用来链接两个活动。在flow 活动中声明的每个link必须在该flow中恰好有一个活动作为它的源,恰好有一个活动作为它的目标。 <flow standard-attributes> standard-elements <links>? <link name="ncname">+ </links> activity+ </flow>
scope • <scope>构造允许定义嵌套活动,这个嵌套活动有和自己关联的变量、故障处理程序和补偿处理程序。 • 每个scope有一个定义它的正常行为的主要活动。该主要活动可以是一个复杂的结构化的活动,其中有任意深度的许多嵌套的活动。所有的嵌套的活动都共享该scope。 <scope variableAccessSerializable="yes|no" standard-attributes> standard-elements <variables> ... </variables> <correlationSets> ... </correlationSets> <faultHandlers> ... </faultHandlers> <compensationHandler> ... </compensationHandler> <eventHandlers> ... </eventHandlers> activity </scope>
compensate • <compensate>构造已正常完成执行的内层作用域上调用补偿。 • compensate命名了执行补偿所在的作用域。仅当作用域正常完成执行之后该作用域的补偿处理程序才可被调用。 • 显式地执行compensate活动的能力是BPEL的应用程序控制的错误处理框架的基础所在。该活动只能用于业务流程的以下部分中: • 在作用域的 fault 处理程序中,该作用域直接包括补偿将被执行的作用域。 • 在作用域的补偿处理程序中,该作用域直接包括补偿将被执行的作用域。 • 如果按名称显式地补偿的作用域在循环中被执行,那么在后续的迭代中补偿处理程序的实例将按相反的顺序执行。 <compensate scope="ncname"? standard-attributes> standard-elements </compensate>
compensate • <compensate>构造用来在已正常完成执行的内层作用域上调用补偿。 • compensate命名了执行补偿所在的作用域。仅当作用域正常完成执行之后该作用域的补偿处理程序才可被调用。调用未安装的补偿处理程序等同于empty活动(它是no-op)——这就确保了故障处理程序不必依赖于状态来决定哪个嵌套的作用域已成功地完成。 • 显式地执行compensate活动的能力是BPEL的应用程序控制的错误处理框架的基础所在。该活动只能用于业务流程的以下部分中: • 在作用域的 fault 处理程序中,该作用域直接包括补偿将被执行的作用域。 • 在作用域的补偿处理程序中,该作用域直接包括补偿将被执行的作用域。 • 如果按名称显式地补偿的作用域在循环中被执行,那么在后续的迭代中补偿处理程序的实例将按相反的顺序执行。 <compensate scope="ncname"? standard-attributes> standard-elements </compensate>