Self Service HRMS and AME

Objective:
In this article we will learn about the Request Response Pattern in SOA.

Request Response Pattern:

The following Request Response Patterns are covered in this appendix:

1. One way message

2. Synchronous Synchronisation

3. Asynchronous Interaction

4. Asynchronous Interaction with Timeout

5. Asynchronous Interaction with Notification Timer

6. One Request, Multiple Responses

7. One Request, One or Two possible Responses

8. One Request, a Mandatory Response, and an Optional Response

Request-response patterns are used to facilitate communication between the components of a Business Process Execution Language (BPEL) process. The request-response operation includes one input element (the request) followed by one output element (the response).

A one-way message interaction pattern is a special type of request-response pattern, where the client sends a message to the service, and the service does not need to reply. This could be used for business updates if the requester trusts the message service and the transaction not to fail.The communication pattern for the one-way message interaction involves:

• A service consumer:The client that invokes the service and supplies the input message

• A service provider:The service that accepts an input message from the service client, and does not provide a response (output message) The diagrams show various implementations of a one-way message interaction pattern, such as:

• A Mediator component with a routing rule to a service

• A BPEL component to a service

In a synchronous interaction, a client sends a request to a service, and receives an immediate reply or fault.The service can be at either end of this interaction, and is implemented based on its role as the client or the service. The image in the slide shows two diagrams of a synchronous interaction between two SOA components.

A BPEL process component client with a BPEL process component service

• The BPEL client contains an Invoke to manage the request-response cycle.

• The BPEL service contains a Receive to obtain the request message, and then after some processing, return a response by using a Reply, or throw a fault condition.

A Mediator component client with a BPEL process service

• The client contains a synchronous route to send the request to a BPEL service, and receive the response or fault.

The BPEL service contains a Receive to obtain the request message, and then after some processing, return a response by using a Reply, or throw a fault condition.

In an asynchronous interaction, a client sends a request to a service and waits until the service replies.The image in the slide shows two diagrams of an asynchronous interaction between two SOA components.

A BPEL process component client with a BPEL process component service

• The BPEL client contains an Invoke to initiate the request and do some processing, and a Receive to obtain the response.

• The BPEL service contains a Receive to obtain the request message, and then after some processing, return a response by using an Invoke to the client callback port.

A Mediator component client with a BPEL process service

• The client contains an asynchronous route to send the request to a BPEL service, and wait for a response.

• The BPEL service contains a Receive to obtain the request message, and then after some processing, return a response by using an Invoke to the client callback port.

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 can be payment confirmation, and the third response can be a notification that the product has been shipped. In this example, the number and types of responses are expected.

• The BPEL Process client: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.

• The BPEL Process service: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 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 to inform the customer. In any case, the service always sends a notification when the item ships.

• The BPEL Process client: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 is 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 Process 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 activity’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 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.The sample implementation in the slide shows:

•A BPEL process client, which uses an Invoke to send an asynchronous request to the service, and a Pick activity with:

-An onMessagebranch to receive the response (callback)

-An onAlarmbranch to manage the timeout condition if it occurs before the response is receivedNote:If the response comes after the time limit has expired, the message goes to the dead letter queue.

•A BPEL Process servicethat contains a Receive to obtain the request message, and then after some processing, return a response by using an Invoke to the client callback port.

In an asynchronous interaction with a notification timer, 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 a reply from the service even after the timer has expired.

•The BPEL Process client: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, and 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 BPEL Process service: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 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. The diagram in the slide provides an overview.

•The BPEL Process client: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, and a second onMessage for the out-of-stock response and instructions on what to do if an out-of-stock message is received

•The BPEL Process service:The BPEL service needs a Receive activity to accept the message from the client. It also needs a Switch activity with two branches: one with an Invoke activity that sends the in-stock message if the item is available, and a second branch with an Invoke activity that sends the out-of-stock message if the item is not available.

In this interaction type, the client sends multiple requests to multiple services and receives multiple responses in return. As shown in the slide, the service client (which is a BPEL process) uses a parallel flow to coordinate the request and response interactions from two different services. In this case, two asynchronous callbacks execute in parallel context, so that each callback does not have to wait for the other to complete. However, the flow does not complete until all responses are received.An example of such request-response pattern is implemented in the purchase order course application where the fulfillment process sends a request to determine stock availability in two different stores, an internal and an online store. The process waits for both responses before it chooses the store that is used to acquire the stock to fulfill the order for shipment purposes. Another example is a loan broker process that requests and retrieves loan offers from multiple loan service providers.

In this interaction type, the client sends multiple requests to different services and expects to receive multiple responses. However, to implement the first message response pattern, a Pick activity is used to receive the first of many possible responses, because a Pick processes only the first message to be received for any of its onMessage branches.

As shown in the slide, the service client (which is a BPEL process) uses a parallel flow to initiate asynchronous requests for two different services. Instead of using two asynchronous callbacks in parallel flow, when the flow is completed, a Pick activity is used to wait for all possible responses, in this case, one of two responses. The first response to arrive is processed, from service 1 (as shown in the diagram), and the other response message is not processed because Pick has completed and the service client process continues without waiting for additional responses.

Varun Kapila

Add comment