什么是BPEL

　　WS-BPEL是服务编排的OASIS标准。服务编排意味着利用其它服务编写新的服务。这里是对BPEL流程的简约剖析：部署一个BPEL流程为此流程产生一个发布的服务。BPEL流程指定什么服务必须发布，同时也指定了那些服务操作的实现。

　　接下来，我们将解释最典型的BPEL活动，其给出图一的流程上下文中BPEL的本质的一个清晰认识。BPEL流程中每个receive都与一个流程部署时 发布的服务操作相对应。上图的receive活动receiveOrder作为新流程执行的起点。所以，当客户调用左边的order操作时，通过离开初始 的receive活动从而开始产生新的流程执行。

　　下一步是invoke。一个invoke会调用另一个WSDL service并收集流程变量中的响应信息。在我们的案例中，调用supplier的服务上的getQuote服务操作。

　　来自消息的信息可以存储在流程变量中。整个消息可以存储为XML片段或XSD的基本类型。一个assign活动，如extractProductName 可以从一个变量(此变量一般都是基于XML的内容)中获取一些片段并存储到另一个变量中。 该变量可以用于为其它调用或当前接收请求的响应消息合成消息。receive活动的receiveQuote将使得流程执行等待，直到supplier调 用submitQuote服务操作。带有submitQuote操作的服务在BPEL流程的部署时也被发布出来。当supplier发送一个与此定单相关 的报价时，流程执行将继续并离开receiveQuote活动。

　　reply活动为当前的服务请求合成一个响应消息。所以,只有当receive在IN-OUT消息交互的服务操作中接收到一个消息，reply才有意义。

　　注意，当supplier调用submitQuote操作时，消息必须通过离开receive活动触使流程执行继续。这展示了BEPL的另一个特性，称为 “correlation”。在BPEL流程中，correlation意味着发生的服务请求消息与已存在的流程执行的匹配关系，此对应的流程执行等待其 请求消息。如果receive节点被标识为启始，那么该操作的输入消息将产生一个新的流程执行实例。一般来说，输入文档中的某些数据项将被标识为一个唯一 的关联ID，比如一个order ID。那么，流程中后续的receive节点的输入消息就可以与基于order ID的相应的流程执行相关联。现实环境中，关联集合可以由许多属性的众多单独的集合组成，鉴于清晰起见，屏弃了额外的复杂度。

　　Partner link标识BPEL流程与之交互的外部合作者。从BPEL流程到合作者的服务调用以及合作者对BPEL流程的调用都是使用partner link进行关联的。关联的两端称为role(角色)。每个角色都与其方向上跨越partner link的标识通讯接口的一个port type相对应。所以，一个partnerlink可以申明两个角色，且其需要指明两个角色的哪一个表示BPEL流程端。与一个partnerlink的 BPEL流程角色相一致的服务在部署流程时被发布。另一个角色用于服务调用。

　　这里给出了BPEL最本质的部分。其他部分如补偿处理，事件处理，执行的并发路径和定时器等BPEL的高级特性并没有包含在内，因为它们对于后期的讨论很少的关联。