BPEL: some magic behind async miracles

As a lot of people wrote in to ask on async processes, I thought to publish a note, on using them - and some code along with it.

First of all what is async messaging?
In comparison to a synchronous call, that is blocking, and "waits" until a message comes back, an asynchronous call, is first of all a one-way call. This means, a message is sent to the service provider, and one might come back to you. This implies that the client needs to be able to correlate request and response. With one thread this is rather easy (as it is a one2one mapping), but given more than one thread sends a messages concurrently - this can become challenging. The solution for this - a unique identifier for each message (in BPEL PM's case the conversationId)

In a technical nutshell (based on a wsdl):
on the initiating operation just an input message is defined, as shown in the code here:

  <operation name="initiate">
     <input message="tns:HelloWorldRequestMessage"/>
  </operation>

on the other side a callback could be defined in the same manner

  <operation name="onResult">
     <input message="tns:HelloWorldResponseMessage"/>
  </operation>

and that's it.

With knowing this, it soon becomes clear, that dependend on the technology being used to invoke this service - it could be quite hard to get a callback (e.g calling back into a browser session over http, or calling back into a java thread from a server :-D) - As you see, this is a technical boundary (as for the callback, the roles are switched, the client becomes the server..)

So what are the bindings offered by BPEL to initiate a process?

• SOAP - this is the perfect case, due to WS-Addressing usage for asynchronous messaging, and the BPEL PM engine is able to correlate a callback from a process into the right instance


• HTTP invocation - unfortunately there is no way, if an async call is intiated, this is a call and forget


• Java API, after invoking your process (DeliveryService:post), you can query the instance (Locator:lookupInstanceByConversationId) and on the IInstanceHandle you can examine status (getState()) and field values (getField(String))

While blogging this article, I am on the way creating a little sample for the java case, to demonstrate some real async behaviour (through threads and a listener) - watch out the next days..

Having questions? send your feedback on async miracles here