A BPEL process can engage in various forms of asynchronous activity. We have seen how the process can wait for the callback message that is effectively the reply from an asynchronous partner [link]. Such a callback message is expected – even though we do not know when – and even if – it will arrive.
Another asynchronous activity we can introduce into the BPEL process is a background timer that runs for a certain period or until a certain deadline. When the timer fires, specified action is taken. The AircraftServiceOrchestrator will be made to wait no longer than until the deadline for deciding on a service provider arrives.
And in a similar way, we can have background message listeners that listen for request messages – not callback responses in reaction to previous service invocations from the BPEL process but unexpected new messages.
In this section, we will allow the airline carrier that initially called the AircraftServiceOrchestrator composite to invoke a cancel operation on the AircraftServiceOrchestrator service to stop the RFP proceedings. This should result in a similar message being sent to all aircraft service providers to inform them of the cancellation of the RFP. This last call however is outside the scope of this chapter.
Along similar lines we could have the carrier ask for the status of the proposal and even provide additional information such as an updated number of passengers or a changed slot time.
Supporting Resources
The starting point sources are in the folder AircraftServices-step2. The final situation for this section is found in folder AircraftServices-step5. Step 3 has the deadline timer and step 4 the support for the cancel operation. Step 5 adds the status retrieval.
AMIS Technology Blog – Batch Aggregation of files in BPEL process instances based on correlation
Tom Hofte on Making Integration Architectures Work – SOA Suite 11g: Coordination between two BPEL processes
Random Cerebrations on SOA - Implementing Correlation sets – issues and workarounds
