Constraints on BPEL Correlation in Open ESB

One of the useful features of BPEL as an orchestration language is its built-in support for correlation – the ability to correlate callbacks from asynchronous services with the original invoking process instance. If you´d like an intro to Correlation, the team at Pymma have written a nice tutorial explaining the concepts of BPEL Correlation and how to make use of it in OpenESB.

Correlation works well when BPEL is used as a simple scripting language for basic webservices, but there are things to consider when using it to orchestrate services offered in a JBI-based infrastructure or when combining correlation with webservice standards such as reliable messaging or transactions. This article discusses constraints on BPEL Correlation in the JBI-based infrastructure of OpenESB, GlassfishESB, and JavaCAPS.

The basic Correlation scenario is quite simple:

  1. the process invokes an asynchronous service with an in-only message (i.e., no reply)

  2. the process continues to execute until the service sends a callback response

  3. the process engine receives the response and uses the correlation information to match the response to the original invoking process instance

  4. the process instance receives the callback msg and processes it accordingly

And this is exactly what happens if you implement a bpel process which calls an over-the-wire WS-I Basic Profile compliant webservice using OpenESB.

However, if you include the Asynchronous Service in the same Service Assembly (aka Composite Application) as the BPEL process, then the process fails to continue executing. In fact, the entire process waits endlessly. To understand why this occurs you need to look a bit deeper at what is happening under the covers in the JBI infrastructure.

Here´s how the basic Correlation scenario works again, but this time including more detail about what is happening under the covers. To follow this you should have a basic understanding of JBI concepts. This page and presentation screencast are useful places to start.

  1. the process invokes an asynch service with an in-only message (i.e., no reply)

  • the BPEL Service Engine (SE) wraps the service invocation in a Normalized Message.

  • the Normalized Message (NM) is wrapped in a Message Exchange (ME) object. In this case, it is a “in-only” Message Exchange.

  • the Message Exchange is sent from the BPEL SE to the Normalized Message Router (NMR).

  • the NMR determines that the requested service is offered by the SOAP Binding Component (BC) and routes the NM to that component.

  • the SOAP BC returns an Acknowledgement (ACK) to the NMR

  • the NMR passes the ACK back to the BPEL Engine

  • the BPEL Engine allows the process instance to continue

  1. the process instance continues to execute until the remote service sends a callback response

  • the SOAP BC creates a Normalized Message which is passed back to the BPEL SE with a similar set of steps to those described previously.

  1. the BPEL Engine receives the callback response and uses the correlation information to determine which process instance the response should passed to.

  2. the process instance receives the callback msg and executes accordingly

This more detailed look at what is happening in the JBI infrastructure seems like a lot of overhead but remember that its only Java objects communicating in the same JVM. Performance benchmarks have shown that there is very little overhead for this level of indirection.

So, why does the scenario fail when the Asynch Service is included in the same Composite Application rather than being invoked as a remote webservice? The issue concerns Systemic Qualities which are the non-functional attributes of the JBI Components offered by GlassfishESB.

Systemic Qualities provide for a number of capabilities which allow GlassfishESB to guarantee different Quality of Service delivery types. E.g., once-and-only-once, at-most-once, and at-least-once. For instance, the Recoverability Quality guarantees that Service Engines can recover from a failure without loss of message. To achieve this when two Service Engines are communicating, the provider Service Engine (e.g., the JavaEE SE providing the Asynch Service) will not send the ACK message to the consuming Service Engine (e.g., the BPEL SE) until the EJB has completed processing. That way, if a system failure occurs during the execution of the Asynch Service, it could be reprocessed without violating the one-and-only-once delivery type.

The consequence of this behaviour, i.e., not sending the ACK until the EJB completes, is that the Business Process does not continue executing. The BPEL SE must wait until the ACK is received from the JavaEE SE. Similarly, when the callback msg is sent, the JavaEE SE must wait to receive the ACK from the BPEL SE. The system then goes into an endless wait-state. The Asynch Service tries send the Callback msg to the process, but the JavaEE SE will never receive the ACK that its callback msg has been received by the BPEL SE because the BPEL SE is still waiting for the ACK for the original request.

This situation occurs for any correlation scenario where the Asynch Service´s container (i.e., the Service Engine in which it executes) provides an ACK to the BPEL SE _after_ the Asynch Service satisfies the request (ie., completes) rather than on receipt of the request. In the original scenario, i.e., when the BPEL process invokes an external webservice, the ACK is sent back from the SOAP BC to the BPEL engine on receipt of the service invocation. However, if the SOAP BC was configured to use a standard that required a different Quality of Service, e.g., WS-ReliableMessaging, then the SOAP BC would only send the ACK after receiving an ACK from the remote service. Similarly, if the BPEL process was configured to utilise transactions (i.e., atomic process) then the ACK would not be received upon initial receipt.

This constraint on BPEL Correlation in Glassfish ESB is not as serious a limitation as it may seem. The use of asynchronous communication is usually used in the implementation of long-running business processes where the importance of these Quality of Service features have a different weighting in your analysis of alternative solutions when compared to fast-running processes. Moreover, other design approaches to implement “correlation” can be achieved without relying on the OOTB functionality of the BPEL Engine.

The support for OOTB Correlation is one reason why BPEL can be sometimes be a useful technology for service orchestration. But blindly relying on technology features is never a substitute for good design.


Excellent post,interesting article,thanks for sharing.

Posted by gucci shoes on February 10, 2010 at 02:47 AM CET #

Post a Comment:
Comments are closed for this entry.



« December 2016