BPEL4WS基础知识
一、为什么选择BPEL4WS
-
可以使用行业范围内的规范来广告、发现和调用Web服务
-
开发人员和用户可以通过组合和订购可用的基本服务来解决复杂问题
-
服务组合允许服务重用并加速复杂的服务开发
-
提供一种表示法,用于将Web服务的交互描述为业务流程
-
编写使用Web服务的程序,通过组合一组现有服务来定义新的Web服务
-
编写作为Web服务的程序,组合服务的接口被描述为任何其他Web服务
二、BPEL4WS过程的结构
<process ...>
<partners> ...
</partners> <!--流程与之交互的Web服务-->
<containers> ...
</containers> <!--流程使用的数据-->
<correlationSets> ... <!--用于支持异步交互-->
</correlationSets>
<faultHandlers> ... <!--代替执行路径已处理错误条件-->
</faultHandlers>
<compensationHandler> ... <!--undo动作时执行的代码-->
</compensationHandler>
(activities)* <!--该过程实际是做什么的-->
</process>
三、BPEL的基本元素
-
BPEL流程主要包括对其他服务的调用或从其他服务接收调用
-
Partner:与流程交互的其他服务
-
invoked partner:流程调用的服务,作为其算法的组成部分
-
client partner:调用流程
-
第三方partner:流程调用的服务 和 调用流程
-
-
Partner(Service) Link Type (SLT)
-
表示第三方声明两个(或更多潜在Web服务之间的关系)
-
定义角色集合,其中每个角色都表示<portTypes>的列表
-
当两个服务交互时,伙伴链接类型是它们如何交互的声明
-
定义了角色以及角色需要支持的端口类型
-
<partnerLinkType name=“...”>
<role name=“...">
<portType name=“...” />*
</role>
<role name=“...”>
<portType name=“...”/>*
</role>
</partnerLinkType>
<partner name=“...” partnerLinkType=“...” partnerRole=“...” myRole=“...”/>
-
在纯被调用的伙伴和纯客户伙伴的情况下 伙伴链接类型只有一种作用
<partnerLinkType name="inventoryServiceSLT">
<role name="inventoryService">
<portType name=“InventoryServicePT"/>
</role>
</partnerLinkType>
<partner
name="inventoryServicePL"
partnerLinkType="inventoryServiceSLT"
partnerRole="inventoryService"/>
四、活动
-
BPEL流程基本上是流程图,类似于算法的表达,该过程中每个步骤都称为活动。
-
原始活动:过程中的原始步骤
-
<invoke>
-
<receive>
-
<reply>
-
<wait>
-
<assign>
-
-
结构活动:可以使用原始活动组合为更复杂的算法
-
<sequence>
-
<while>
-
<flow>
-
-
主要活动:
- <receive>等待用于外部调用服务接口操作的消息
<receive partner=“...” portType=“...” operation=“...” container=“...” [createInstance=“...”] />
- <invoke>在某些Web服务上调用操作
<invoke partner=“...” portType=“...” operation=“...” inputContainer=“...” outputContainer=“...”/>
- <reply>生成输入/输出操作的响应,在伙伴调用中发送回复消息
<reply partner=“...” portType=“...” operation=“...” container=“...”/>
- <assign>将数据从一个地方复制到另一个地方
<assign>
<copy> … </copy>+
</assign>
-
原始活动
-
<wait>等待一段时间
-
<throw>表示出了一点问题
-
<terminate>终止整个服务实例
-
<empty>或不执行任何操作
-
-
结构活动
-
<sequence>定义步骤的有序序列
-
<switch>使用现在常见的“案例陈述”方法进行分支
-
<while>定义循环
-
<pick>执行几种替代路径之一
-
<flow>指示应并执行步骤集合
-
-
基本结构
<sequence>
<receive .../>
<flow>
<sequence>
<invoke ... />
<while ... >
<assign> ... </assign>
</while>
</sequence>
<sequence>
<receive ... />
<invoke ... />
</sequence>
</flow>
<reply ... />
</sequence>
五、BPEL数据模型
-
<Countainer>提供用于保存构成业务流程状态的消息的方法
-
定义变量的语法已更改为使用三个互斥属性messageType type和element
六、消息相关性
-
BPEL中的异步交互
-
BPEL可以对多种类型的交互进行建模
-
无状态互动
-
有状态的异步交互
-
-
消息关联是BPEL机制,它允许流程参与有状态会话
-
在许多分布式对象系统中,消息路由涉及检查消息中是否有用于标识目标的显式实例ID
-
BPEL实例由交换的消息中一组或多组关键数据字段标识
-
举例:
采购订单/发票业务情景中,发票可能包含相应的采购订单编号
Purchase Order:
<PurchaseOrder>
<PurchaseOrderNumber>
<PurchaseOrderDate>
........
</PurchaseOrder>
Invoice:
<Invoice>
<InvoiceNumber>
<InvoiceDate>
<PurchaseOrderNumber>
........
</Invoice>
-
相关集:标识流程实例的数据字段的集合
-
一组捕获交互状态的业务数据字段
-
每组初始化一次
-
在交互过程中值不变
-
-
使用相关集
-
集合被receive reply invoke pick活动引用
-
由于receive和pick提供了流程的入口点,因此相关集通常会出现在他们上以启用消息到实例的路由
-
reply和invoke活动上的相关集通常用于验证传出消息
-
<correlationSet name=“PurchaseOrder” properties=“cor:customerID cor:orderNumber”/>
<correlationSet name=“Invoice” properties=“cor:vendorID cor:invoiceNumber”/>
<invoke partnerLink=“Buyer” portType=“SP:BuyerPT” operation=“AsyncPurchaseResponse” inputVariable=“POResponse”>
<correlations>
<correlation set=“PurchaseOrder” initiate=“no” pattern=“out”>
<correlation set=“Invoice” initiate=“yes” pattern=“out”>
</correlations>
</invoke>
<receive partnerLink=“Buyer” portType=“SP:PurchasePT” operation=“AsyncPurchase” variable=“PO”>
<correlations>
<correlation set=“PurchaseOrder” initiate=“yes” pattern=“in”>
</correlations>
</receive>
七、BPEL处理程序
-
错误情况的处理通常会影响相互关联的一组活动。
-
BPEL在范围结构化活动中包含一组相关活动。
-
范围为嵌套在其中的活动提供了上下文,并且在此定义了故障和补偿处理程序。
-
每个范围可以具有两种关联的处理程序
-
故障处理程序:可以针对不同的故障类型附加很多
-
补偿处理程序:每个范围一个补偿处理程序
-
八、错误处理程序
-
在执行BPEL流程时,在调用的服务或流程本身内部可能会发生错误
-
BPEL提供了一种机制,可以通过执行<fault handles>中指定的子例程来显式捕获错误并进行处理
-
当范围内发生故障时,故障处理程序定义备用执行路径
九、补偿处理程序
-
业务流程通常持续时间很长,这意味着在业务流程进行许多事务之后,可能需要取消业务流程。
-
允许流程的创建者定义某些操作,这些操作应用来撤消工作单元并将数据恢复到完成该工作之前的状态。
十、可执行BPEL&抽象BPEL
-
BPEL4WS支持两种不同的使用场景:
-
可执行流程——实施可执行业务流程
-
抽象过程——描述不可执行的抽象过程
-
-
抽象过程:
-
抽象过程是部分指定的过程,通常不打算执行
-
抽象流程是格式完整的流程,具有完整的表达能力,可用于指定具有不同程度的操作细节的流程。
-
能够抽象出操作细节,使用BPEL的概念应能反映描述业务协议公共方面所需的抽象级别。
-
仅处理与协议相关的数据
-
使用不确定的数据值隐藏行为的私人方面
-
-
抽象过程的使用
-
导出模式:可执行流程到抽象流程
-
导入模式:抽象过程到可执行过程
-
协议匹配模式:构造一个与抽象过程中描述的预期行为相匹配的过程
-
十一、总结
-
BPEL是一种XML语言,支持面向流程的服务组合
-
BPEL4WS定义了一个模型和一个语法,用于基于流程及其合作伙伴之间的交互来描述业务流程的行为