消息活动

　　BPEL定义了三个消息活动<receive>、<reply>和<invoke>。如何使用这些取决于消息交互是同步的还是异步的以及BPEL流程是服务消费者还是服务提供者。

　　同步消息

　　同步消息中，调用者将受到阻碍直到收到回复（或者超时）；BPEL流程将在转向下个活动之前，等待回复。

　　正如我们在下图中所看到的一样，流程A使用<invoke>活动调用一个同步WEB服务（例子中的流程B）；一旦它发送初始请求，它将阻碍并等待来自流程B的响应回复。

图二

　　流程B使用<receive>活动接受请求；一旦它已经处理请求，就使用<reply>活动发送响应给流程。

　　理论上，流程B将花费何其希望的回复时间一样长的时间，但是实际上流程A在超时之前，只需等待很短的时间（例如30秒），<invoke>运作在假定已经出错。因此如果流程B在回复之前花费大量时间，你应该模拟异步发送和接受。

　　异步消息

　　在异步消息中，关键不同之处是一旦调用者发送请求，发送运行将马上返回，BPEL流程可能继续添加活动直到准备接受回复，在那个点上，流程将阻碍直到接受回复。

　　如果我们看到下面这个图，你可能会注意到就像同步请求流程A使用<invoke>活动调用异步WEB异步服务。虽然，不同是它不阻碍进行等待响应，而是继续添加流程直到真备好接受流程的响应。然后使用<receive>活动接收。

图三

　　相反地，流程B使用<receive>活动接受初始请求，使用<invoke>活动发送回复响应。

　　在逻辑层，在同步和异步消息之间（尤其是如果在流程A中<invoke>和<receive>活动之间没有活动）有一点不同，技术层面上这是个关键的不同之处。

　　这是因为异步消息，我们有两个<invoke>、<receive>配对，每一次响应单独进行WEB服务运行；一个发送请求，另一个用来回复。

　　对如如何选择时间长度来让流程B服务请求，异步消息支持更久一点的处理时间。总之，流程B返回相应的时间超过30秒，就该转向异步消息。

　　单向消息

　　异步消息的一个变种是单向消息。从调用流程中涉及单一消息发送，无需响应。

　　通过下图，我们注意到就像异步求求流程A使用<invoke>活动发送消息给流程B。

　　一旦流程A已经发送消息，它将继续处理直达完成，也就是说从不停下来等待来自来自流程B的响应回复。同样的流程B，在收到消息后，继续处理直到完成，从不发送任何响应给流程A。

图四