Implicit Correlations

• Introduction
• Process to Process Interaction Use Case
• Process to Service Interaction Use Case

Introduction¶

BPEL process instances are stateful --- therefore, a client interacting with the BPEL engine must identify the particular instance with which it intends to interact in all of its communications. The BPEL specification defines a mechanism --- correlation --- which allows the process designer to specify which parts of an incoming message (i.e. a message going from a client to the BPEL server) should be used to identify the target process instance. Correlation is a powerful mechanism --- however it is a bit complicated and relies on "in-band" message data to associate a messages with a process instance.

To keep simple cases simple, ODE provides an alternative correlation mechanism --- implicit correlation --- that automatically handles correlation through "out-of-band" session identifiers. The mechanism is simple: a unique session identifier is associated with every every partner link instance. When a message is sent on a partner link, the session identifier is sent along with the message. The recipient is then able to use the received session identifier in subsequent communications with the process instance. Messages received by the BPEL engine that have a session identifier are routed to the correct instance (and partner link) by that session identifer.

There are two major use cases for the implicit correlation mechanism requiring different levels of familiarity with the mechanism's details: process to process and process to service interactions. The former case deals with situations where the ODE BPEL process instance is communicating with another ODE process instance. The latter deals with situations where a ODE BPEL process instance is communicating with an external (non-ODE) service.

Process to Process Interaction Use Case¶

When an ODE process needs to communicate with other ODE processes, using implicit correlations is quite simple. Simply omit the <correlations> element from the <receive>, <pick>, and <invoke> activities. The following is an example showing one process (processA) starting another (processB) and then being called back:

• ProcessA

  .
  .
  .
  <invoke name="initiate" partnerLink="responderPartnerLink" portType="test:MSResponderPortType"
          operation="initiate" inputVariable="dummy"/>
  <receive name="callback" partnerLink="responderPartnerLink"
           portType="test:MSMainPortType" operation="callback" variable="dummy"/>
  .
  .
  .
  

• ProcessB

  .
  .
  .
  <receive name="start" partnerLink="mainPartnerLink" variable="dummy"
               portType="resp:MSResponderPortType" operation="initiate" createInstance="yes"/>
  <invoke name="callback" partnerLink="mainPartnerLink"
             portType="resp:MSMainPortType" operation="callback" inputVariable="dummy"/>
  .
  .
  .
  

In the above example, ODE will use the implicit correlation mechanism because no explicit correlations are specified. Communication between the two processes will reach the correct instance as long as the same partner link is used.

For a complete example check MagicSession.

Process to Service Interaction Use Case¶

See the Stateful Exchange Protocol.