|
Oracle® BPEL Process Manager Developer's Guide
10g Release 2 (10.1.2) B14448-03 |
|
 Previous |
 Next |
|
Oracle® BPEL Process Manager Developer's Guide
10g Release 2 (10.1.2) B14448-03 |
|
|
Previous |
Next |
This chapter identifies common interaction patterns between a BPEL process and another application, and shows the best use practices for each.
This chapter contains the following topics:
In a one-way message, or fire and forget, the client sends a message to the service, and the service does not need to reply. Figure 13-1 provides an overview.
As the client, the BPEL process needs a valid partner link and an invoke activity with the target service and the message. As with all partner activities, the WSDL file defines the interaction.
To accept a message from the client, the BPEL process needs a receive activity.
In a synchronous interaction, a client sends a request to a service, and receives an immediate reply. The BPEL process can be at either end of this interaction, and must be coded based on its role as either the client or the service. Figure 13-2 provides an overview.
When the BPEL process is on the client side of a synchronous transaction, it needs an invoke activity. The port on the client side both sends the request and receives the reply. As with all partner activities, the WSDL file defines the interaction.
When the BPEL process is on the service side of a synchronous transaction, it needs a receive activity to accept the incoming request, and a reply activity to return either the requested information or an error message (a fault).
In an asynchronous interaction, a client sends a request to a service and waits until the service replies. Figure 13-3 provides an overview.
When the BPEL process is on the client side of an asynchronous transaction, it needs an invoke activity to send the request and a receive activity to receive the reply. As with all partner activities, the WSDL file defines the interaction.
As with a synchronous transaction, when the BPEL process is on the service side of an asynchronous transaction it needs a receive activity to accept the incoming request, and an invoke activity to return either the requested information or a fault.
In an asynchronous interaction with a timeout, a client sends a request to a service and waits until it receives a reply, or until a certain time limit is reached, whichever comes first. Figure 13-4 provides an overview.
Figure 13-4 Asynchronous Interaction with Timeout
When the BPEL process is on the client side of an asynchronous transaction with a timeout, it needs an invoke activity to send the request and a pick activity with two branches: an onMessage branch and an onAlarm branch. If the reply comes after the time limit has expired, the message goes to the dead letter queue. As with all partner activities, the WSDL file defines the interaction.
The behavior of the service BPEL process is the same as with the asynchronous interaction with the BPEL Process as the service described in "BPEL Process as the Service".
In an asynchronous interaction with a notification time, a client sends a request to a service and waits for a reply, although a notification is sent after a timer expires. The client continues to wait for the reply from the service even after the timer has expired. Figure 13-5 provides an overview.
Figure 13-5 Asynchronous Interaction with a Notification Time
When the BPEL process is on the client side of this transaction, it needs a scope activity containing an invoke activity to send the request, and a receive activity to accept the reply. The onAlarm handler of the scope activity has a time limit and instructions on what to do when the timer expires. For example, wait 30 minutes, then send a warning indicating that the process is taking longer than expected. As with all partner activities, the WSDL file defines the interaction.
The behavior for the service BPEL process is the same as with the asynchronous interaction with the BPEL process as the service described in "BPEL Process as the Service".
In this interaction type, the client sends a single request to a service and receives multiple responses in return. For example, the request can be to order a product online, and the first response can be the estimated delivery time, the second response a payment confirmation, and the third response a notification that the product has shipped. In this example, the number and types of responses are expected. Figure 13-6 provides an overview.
Figure 13-6 One Request, Multiple Responses
When the BPEL process is on the client side of this transaction, it needs an invoke activity to send the request, and a sequence activity with three receive activities, one for each reply. As with all partner activities, the WSDL file defines the interaction.
The BPEL service needs a receive activity to accept the message from the client, and a sequence attribute with three invoke activities, one for each reply.
In an interaction using one request and one of two possible responses, the client sends a single request to a service and receives one of two possible responses. For example, the request can be to order a product online, and the first response can be either an in-stock message, or an out-of-stock message. Figure 13-7 provides an overview.
Figure 13-7 One Request, One of Two Possible Responses
When the BPEL process is on the client side of this transaction, it needs the following:
An invoke activity to send the request
A pick activity with two branches: one onMessage for the in-stock response and instructions on what to do if an in-stock message is received
A second onMessage for the out-of-stock response and instructions on what to do if an out-of-stock message is received
As with all partner activities, the WSDL file defines the interaction.
The BPEL service needs a receive activity to accept the message from the client, and a switch activity with two branches, one with an invoke activity sending the in-stock message if the item is available, and a second branch with an invoke activity sending the out-of-stock message if the item is not available.
In this type of interaction, the client sends a single request to a service and receives one or two responses. Here, the request is to order a product online. If the product is delayed, the service sends a message letting the customer know. In any case, the service always sends a notification when the item ships. Figure 13-8 provides an overview.
Figure 13-8 One Request, a Mandatory Response, and an Optional Response
When the BPEL process 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 waits to receive the mandatory reply. If the mandatory reply is received first, the BPEL process continues without waiting for the optional reply. As with all partner activities, the WSDL file defines the interaction.
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).
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, and so on. This pattern can also include multiple shot callbacks, followed by longer-term processing. Figure 13-9 provides an overview.
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.
The BPEL service needs a receive activity for each request from the client, and a reply activity for each response. Once the responses are finished, the service BPEL process can continue with its processing, using the information gathered in the interaction to perform the necessary tasks without any further input from the client.
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 once, and therefore needs a mechanism for keeping track of which message goes where. Figure 13-10 provides an overview.
As with all partner activities, the WSDL file defines the interaction.
|
See Also: "Managing Multiple Active BPEL Process Instances Using Correlation Methods" for more information about WS-Addressing and Correlation Sets |
