Correlation Sets

An application must maintain data integrity when messages are exchanged between services. A manufacturer that receives orders, for example, must not mix data for one order with the data for another.

A BPEL process addresses this issue with correlation sets, each of which is a list of properties whose values are expected to remain constant throughout a process or throughout a specific scope, even as data is transmitted to and from partner services.

As Figure 7.5 illustrates, the BPEL process PurchaseOrder is maintaining a long-term conversation with a purchasing service. The process maintains a correlation set that includes two properties: customer ID and order number. The correlation set is initiated (assigned constant values) when a new order arrives. The process keeps those constant values separate from values that are received from any message or are transmitted as part of any message.

Figure 7.5: Correlation in BPEL

You reference a correlation set only in activities that receive or transmit data:

• in each inbound activity that may require the BPEL engine to direct a message to a specific service instance

• in an outbound activity, if you want to verify that the property values at the time of transfer are correct

• in any inbound or outbound activity that initiates the correlation set

In the third case, the values must remain unchanged in later inbound or outbound activities throughout the scope to which the correlation set applies or (outside a scope) throughout the process.

In the PurchaseOrder process example, an inbound activity initiates the correlation set. In an example that involves an outbound activity, the PurchaseOrder process exchanges order-specific data with another service (not shown in the figure). That secondary service checks the availability of parts and invokes the PurchaseOrder service with a callback that may provide only a partial response.

Correlation in this case involves not only the customer ID and order number but also a tracking code. When the BPEL process submits the initial request to the secondary service, the BPEL process initiates the new correlation set. The constant values that are assigned for that second correlation set are maintained separately from the constant values that were assigned for the first.

As suggested by this example, a BPEL process might use a variety of different correlation sets.

Initiation Attributes

Whenever you reference a correlation set in an activity, you indicate whether the activity is initiating the correlation set. In particular, you assign one of the following values to the initiate attribute that is specific to the correlation set: no, yes, or join.

The attribute's default value, no, means that the activity must not initiate the correlation set. In our example, a request to update an existing order does not assign new constant values. Instead, the BPEL engine uses the values in the inbound message to direct processing to a service instance associated with a correlation set that was already initiated. BPEL throws a fault if the activity determines that the inbound message has unexpected values or that the correlation set was not initiated previously.

If you set the initiate value to no for an outbound message, the BPEL process verifies that the values being sent are consistent with what was received or transmitted earlier.

An initiate value of yes means that the activity must initiate the correlation set. In our example, the receipt of a new order (probably in the first receive activity) causes initiation. BPEL throws a fault if the activity determines that the correlation set was initiated previously.

The third value possible initiate value is join. That value is used (for example) if you issue multiple receive activities concurrently and the same correlation set is required for each activity. The effect of join is that the first-running activity initiates the correlation set, and the BPEL engine directs the other messages to the correct service instance. If the activity determines that the correlation set has unexpected values, BPEL throws a fault.

In an invoke activity that invokes a service synchronously, you use the pattern attribute in addition to the initiate attribute. The need arises because the correlation sets referenced for the outbound message of the invoke activity may be different from the correlation sets referenced for the message returned to the BPEL process.

For each correlation set referenced in the synchronous invoke activity, you specify one of three values for the pattern attribute. A request value means that the correlation-set initiate attribute refers to the message sent to the partner service. A response value means that the correlation-set initiate attribute refers to the message returned to the BPEL process. A request-response value means that the correlation-set initiate attribute refers to both messages.

Effect of Correlation Errors

During synchronous invocation, if the message returned to the BPEL process has unexpected values, the values are received into one or more variables for use in fault processing. A transfer is not completed in other cases of correlation fault, regardless of the activity.