Asynchronous Message Exchange, cont.
Adding Message Correlation
As noted in the introduction in order to properly run more than one instance of this process we will need to add message correlation to our project. This ensures that if multiple process instances are running simultaneously the message sent by the Responder will be routed to the proper instance of the Requester process. We are going to correlate messages based on the contents of the InstanceID element which is included in the messages exchanged between the Requester and Responder processes.
An overview of the steps required for adding message correlation are:
- Define a Correlation Set
- Apply the Correlation Set on the asynchronous interaction activities in the Requester process
Define a Correlation Set
The first thing that we need to do is to create a correlation set. A correlation set is a set of properties (see below) shared by messages. The purpose of the correlation set is to act as a conversation identifier: it keeps together all messages intended for the same conversation.
A property is an element within a message identified by a query. In order to extract the value of the property from a message, a property alias is required. The property alias identifies how to extract the value of the property from by specifying the message part and optionally a query.
In a production environment it would not be uncommon for multiple Requester process instances to be waiting on the asynchronous receipt of the message sent by the Responder process. Our goal is to make sure that running Requester process receives the message intended for it. We will accomplish this by creating a message property and identifying the message properties that will make up the correlation set.
The messages that we want to correlate in the Requester process are on the (outbound)invoke (getAsyncResponse operation) activity and the subsequent (inbound) receive (invokeResponderCallback operation) activity. The respective message definitions for these activities are getAsyncResponseRequest and invokeResponderCallbackRequest which are defined in the Responder.wsdl file. We need to identify a piece of data in both these messages that can uniquely distinguish one set of message exchanges from another. For this purpose we will use the InstanceID element.
So lets get started.
| Open Requester.bpel in the editor. In the Outline view, navigate the hierarchy into the Correlation Sets branch and right-click and select Add / Declaration / Correlation Set. | |||||||||
Select the New... button and complete the Property Definition dialog with the following
values:
Click OK. |
|||||||||
| Select the ns2:InstanceID from the list of Available Properties and click the Property Aliases... button. | |||||||||
Click the New... button and complete the Define Property
Alias Details dialog for the getAsynchResponseRequest message with the following
values:
Click OK. |
|||||||||
Click the New... button and complete the Define Property
Alias Details dialog for the invokeResponderCallbackRequest message with the following
values:
Click OK. Click OK again. |
|||||||||
|
Select the ns2:InstanceID from the list of Available
Properties and click the >> button to add the property to the Selected Correlation
Set Properties. Click OK to complete the definition of the correlation set's message property and property aliases. |
|||||||||
| Select the CS1 correlation set in the Outline view then select the Properties view and change the name of the correlation set to ResponderCS. | |||||||||
Apply the Correlation Set
We now have to apply the correlation set in the Requester process to the activities representing the asynchronous interaction with the Responder process. Implement this as follows.
| Select the Invoke activity on the process canvas. | |||||||||
| In the Properties view, click the elipsis to the right of the Correlations property text box. | |||||||||
On the Correlation Sets dialog click the Add button and set the following properties:
Click OK. |
|||||||||
| Select the second Receive activity (after the DoSomethingInterestingWhileWaiting activity) on the process canvas. | |||||||||
| In the Properties view, click the elipsis to the right of the Correlations property text box. | |||||||||
|
On the Correlation Sets dialog click the Add button and
set the following properties:
Click OK. |
|||||||||
| Save the Requester process. Ensure that there are no errors remaining. |
Now that we've created a correlation set and applied it to the two asynchronous interaction activities we need to re-deploy our our Requester process. After the process is deploy you can test the changes as described in the next section.
Testing Your Changes
With our modified processes redeployed, we can test the changes using InitiatorClient.
| Switch to the Java perspective and right-click on the IniatorClient.java file. Select from the cascading pop-up menu. |
After a moment, the following message appears in the console (again, you can ignore warnings about attachment support, if present):
Success! Requester returned: 'Initiated AME from thread 'main' - Requester #7 - Responder: Process 8 - Requester out: Process 7'
As before, the message displayed reflects the journey of the data, in this case from the InitiatorClient's main() method, to an instance (process #7, in the instance above) of the Requester process, to an instance (process #8) of the Responder process, back to the Requester process (process #7) and then to the InitiatorClient, which displays the message in the console.
After our changes have been applied we are ensured that the messages sent by the Responder process to the Requester contains the InstanceID of the Requester process, thus ensuring that multiple process instances can run simultaneously.
Summary
This completes our sample which provided an exhaustive discussion of asynchronous message exchange and the use of ActiveVOS to design, implement, deploy and troubleshoot a composite application--all from within a single IDE.
Copyright © 2004–2008 Active Endpoints, Inc.