BPEL的基本活动介绍

1.Receive(接收)/ Reply(回答)

　　＜receive＞活动从流程的外部伙伴那获取数据，并将其保存到流程变量。通常一个Receive是一个流程的初始点，它会阻塞执行直到匹配的消息的到达。

　　＜reply＞活动发送消息给伙伴来应答通过receive活动所接收到的消息。receive和reply的组合对应着WSDL portType上定义的一个请求-响应操作。如果receive活动对应着一个单向(one-way)操作，则不能在流程中定义对应的reply活动。

 

 

＜bpws:receive createInstance="yes" name="Receive" operation="buy" partnerLink ="StockService" portType="ns0:StockService" /＞ … ＜bpws:reply name="Reply" operation="buy" partnerLink="StockService" portType=" ns0:StockService" /＞

　　上面就是BPEL中包含receive和reply活动的片段。值得注意的是，receive和reply活动中都是通过“partnerLink”来引用预定义伙伴关系的，而且需要设置“portType”和“operation”属性来声明流程实现的WSDL portType和操作。此外，如果将receive活动作为流程的起始点，则需要将receive活动的createInstance属性设置为“yes”，它指明了当流程接收到匹配的消息时会创建新的流程实例来处理该请求。在BPEL流程中我们还可以定义更为复杂的消息响应机制，可以将特定的消息关联到相应的流程实例中。CorrelationSet(关联集合)就是为了解决上述问题而出现的。

 

　　2.Invoke请求

　　＜invoke＞活动允许业务流程同步或异步调用由合作伙伴提供的服务，服务实现可以是单向或请求-响应操作。Invoke活动使用“partnerLink”来引用伙伴服务。同过“portType”和“operation”指定相应的WSDL接口和操作：

 

＜bpws:invoke name="GetStockQuote" operation="getQuote" partnerLink="StockQuote" portType="ns2:net.xmethods.services.stockquote.StockQuotePortType" ＞ ＜/bpws:invoke＞

　　如果在请求服务的过程中发生异常，则可以通过错误响应和补偿机制来加以处理，这对业务流程，特别是长时间运行的流程是非常重要的，我们将在后面的章节进行讲解。

 

　　3.Assign赋值

　　＜assign＞活动的作用是用新的数据来更新变量的值。Assign活动可以包括任意数量的基本复制操作：

 

＜bpws:assign name="Assign"＞   ＜bpws:copy＞     ＜bpws:from＞ China＜/bpws:from＞     ＜bpws:to variable="country"/＞   ＜/bpws:copy＞ ＜/bpws:assign＞

　　assign活动还可把端点引用复制到合作伙伴链接，或把合作伙伴链接复制到端点引用，以实现服务的动态绑定。

 

　　4.Wait等待

　　＜wait＞活动会暂停流程执行，等待一段给定的时间或等到某一时刻才继续运行。在WebSphere Process Server 6.0中，开发者可以非常灵活地指定wait中的到期条件，比如等待多少秒，等到特定的一个日期，或是使用内置的日期表现法。也可以使用Java代码来动态指定等待时间。

　　BPEL也提供了丰富的结构化活动，可以灵活地控制流程执行。

　　5.Sequence顺序

　　＜sequence＞活动定义一组按顺序先后执行的活动。执行顺序是sequence活动中嵌套活动的先后顺序。当sequence中的最后一个活动完成后，该sequence活动也就完成了。

　　6.Flow流程

　　＜flow＞活动可以描述更为复杂的活动执行顺序。我们可以利用flow指定一个或多个并行执行的活动。为了定义任意的控制结构，可以在并行的活动中使用链接。

　　flow能进一步表达直接或间接嵌套在其中的活动之间的同步相关性，link(链接)用来表达这种同步相关性。

　　flow活动出现的所有link必须在flow活动中分开定义，并通过名称进行标识。flow活动中嵌套的活动需要通过source或target属性来标明该活动为哪个链接的源或目标活动。在flow活动中，对于每一个link必须有且仅有一个活动作为它的源活动，同样有且仅有一个活动作为它的目标活动。目标活动会在源活动完成之后执行。这样flow内部的活动就可以通过活动构成一个有向图。

　　我们还可以在link的源上定义transition(变迁)条件，当源活动完成之后，BPEL引擎会检查变迁条件是否满足，如果link的转移条件满足目标活动就会执行。

　　7.Switch分支

　　＜switch＞活动与传统的结构化语言的功能类似，从一组分支情况中选择一个特定的活动分支加以执行。switch由case元素定义的一个或多个条件分支的有序列表组成，后面可跟也可以不跟一个otherwise分支。以case分支的出现顺序检查，第一个条件是true的分支被选择并被作为被执行的活动。如果有条件的分支都未被选择，那么otherwise分支将被选择，如图1所示。

　　

　　图1 分支结构示例

　　在IBM的WPS中，用户可以使用Java代码，内置的数据(true或false等)等定义条件表达式。

　　8.While——While循环

　　＜while＞活动也继承于传统的结构化编程思想，提供了while-do循环结构的支持。它可以包含一个或多个活动。它指定反复执行其内部活动，直到成功条件不被满足为止。在WPS中允许其使用Java代码来描述条件表达式。

　　9.Pick 选取(在WPS中被称为Receive Choice)

　　＜pick＞活动会等待一组相互排斥事件中的一个事件的发生，然后执行与发生的事件相关联的活动。它会阻塞业务流程执行，以等待某一特定的事件发生，比如接收到一个合适的消息或超时警报响起。当其中任何一个事件被触发后，业务流程就会继续执行，pick也随即完成了，不会再等待其他事件的发生。

　　每个pick活动必须至少包括一个onMessage事件。onMessage事件的语义等同于有关变量属性的可选类型的receive活动。pick活动还可以定义onAlarm事件用于指定超时警报。

　　如图2所示描述了一个订单业务流程，它会利用pick活动来等待客户明确地确认或取消订单，并进行下一步处理，如果客户在指定的时间内没有响应，则会触发onAlarm事件并通知客户。

　　
　　　图2 选取活动示例

　　pick活动也可以作为业务流程的起始点，指定流程可以接收多种不同的消息，并让流程在接收到特定消息后创建新的流程实例来处理消息。这里与receive活动类似，我们需要将pick活动的createInstance属性设置为“yes”。当然这时候就不应该定义onAlarm超时事件。这是一个非常方便的特性，比如用户希望能够分别接收并处理来自网页、电子邮件或即时消息发送的请求，就可以通过pick活动非常自然地描述业务流程。