Introduction to One Request, One of Two Possible Responses

Introduction to Interaction Patterns in a BPEL Process 5-9 Figure 5–8 One Request, a Mandatory Response, and an Optional Response BPEL Process Service Component as the Client When the BPEL process service component is on the client side of this transaction, it needs a scope activity containing the invoke activity to send the request, and a receive activity to accept the mandatory reply. The onMessage handler of the scope activity is set to accept the optional message and instructions on what to do if the optional message is received for example, notify you that the product has been delayed. The client BPEL process service component waits to receive the mandatory reply. If the mandatory reply is received first, the BPEL process service component continues without waiting for the optional reply. As with all partner activities, the WSDL file defines the interaction. BPEL Process Service Component as the Service The BPEL service needs a scope activity containing the receive activity and an invoke activity to send the mandatory shipping message, and the scope’s onAlarm handler to send the optional delayed message if a timer expires for example, send the delayed message if the item is not shipped in 24 hours.

5.9 Introduction to Partial Processing

In partial processing, the client sends a request to a service and receives an immediate response, but processing continues on the service side. For example, the client sends a request to purchase a vacation package, and the service sends an immediate reply confirming the purchase, then continues on to book the hotel, the flight, the rental car, Client BPEL Process WSDL PartnerLink d1 scope Call service invoke onMessage A Notify User of Delay Wait for Callback receive Msg B Msg B Msg A maybe Service BPEL Process receive When product ships... invokes Msg B Delay? invoke Msg A otherwise switch 5-10 Oracle Fusion Middleware Developers Guide for Oracle SOA Suite and so on. This pattern can also include multiple shot callbacks, followed by longer-term processing. Figure 5–9 provides an overview. Figure 5–9 Partial Processing BPEL Process Service Component as the Client In this case, the BPEL client is simple; it needs an invoke activity for each request and a receive activity for each reply for asynchronous transactions, or just an invoke activity for each synchronous transaction. Once those transactions are complete, the remaining work is handled by the service. As with all partner activities, the WSDL file defines the interaction. BPEL Process Service Component as the Service The BPEL service needs a receive activity for each request from the client, and an invoke activity for each response. Once the responses are finished, the BPEL process service component as the service can continue with its processing, using the information gathered in the interaction to perform the necessary tasks without any further input from the client.

5.10 Introduction to Multiple Application Interactions

In some cases, there are more than two applications involved in a transaction, for example, a buyer, seller, and shipper. In this case, the buyer sends a request to the seller, the seller sends a request to the shipper, and the shipper sends a notification to the buyer. This A-to-B-to-C-to-A transaction pattern can handle many transactions at the same time. Therefore, a mechanism is required for keeping track of which message goes where. Figure 5–10 provides an overview. As with all partner activities, the WSDL file defines the interaction. receive receive receive receive Client BPEL Process WSDL PartnerLink d2 d4 Service BPEL Process receive receive d1 Call service invoke receive d3 invoke receive receive invoke receive