The Life Cycle of the Reliable Message Sequence and Failure Recovery Scenarios.

The Life Cycle of the Reliable Message Sequence

The following figure shows a one-way reliable message exchange.

Figure 5-1 Web Service Reliable Message Exchange

Description of "Figure 5-1 Web Service Reliable Message Exchange"

A reliable message sequence is used to track the progress of a set of messages that are exchanged reliably between an RM source and RM destination. A sequence can be used to send zero or more messages, and is identified by a string identifier. This identifier is used to reference the sequence when using reliable messaging.
The Web service client application sends a message for reliable delivery which is transmitted by the RM source to the RM destination. The RM destination acknowledges that the reliable message has been received and delivers it to the Web service application. The message may be retransmitted by the RM source until the acknowledgement is received. The RM destination, if configured to buffer requests, may redeliver the request to the Web service if the Web service fails to process the request.
A Web service client sends messages to a target Web service by invoking methods on the client instance (port or Dispatch instance). A port is associated with the port type of the reliable Web service and represents a programmatic interface to that service. The port is created by the <clientgen> child element of the jwsc Ant task. A Dispatch instance is a loosely-typed, general-purpose interface for delivering whole messages from the client to the Web service. For more information about Dispatch clients, see Developing a Web Service Dispatch Client..
WebLogic stores the identifier for the reliable message sequence within this client instance. This causes the reliable message sequence to be connected to a single client instance. All messages that are sent using a given client instance will use the same reliable messaging sequence, regardless of the number of messages that are sent. (Unless you using batching, as described in Grouping Messages into Business Units of Work (Batching).)
Because WebLogic Server retains resources associated with the reliable sequence, it is recommended that you take steps to release these resources in a timely fashion. this can be done by managing the lifecycle of the client instance itself, or by using the weblogic.wsee.reliability2.api.WsrmClient API. Use the WsrmClient API to perform common tasks such as set configuration options, get the sequence id, and terminate a reliable sequence. For more information, see Managing the Life Cycle of a Reliable Message Sequence.

Reliable Messaging Failure Recovery Scenarios

The following sections outline reliable messaging failure recovery for various scenarios.

• RM Destination Down Before Request Arrives
  
• RM Source Down After Request is Made
  
• RM Destination Down After Request Arrives
  
• Failure Scenarios with Non-buffered Reliable Web Services
  

The first three scenarios assume that buffering is enabled on both the Web service and client. The last scenario describes reliable messaging failure recovery for non-buffered Web services. Buffering is enabled on Web service client by default. To configure buffering on the Web service, see Chapter 7, "Configuring Message Buffering for Web Services."

RM Destination Down Before Request Arrives

Table 5-3 describes the reliable messaging failure recovery scenario when an RM destination is unavailable before a request from the RM source arrives.
It is assumed that Web service buffering is enabled on both the Web service and client. Buffering is enabled on Web service client by default. To configure buffering on the Web service, see Chapter 7, "Configuring Message Buffering for Web Services."

Table 5-3 Reliable Messaging Failure Recovery Scenario—RM Destination Down Before Request Arrives

Transport Type	Scenario Description
Asynchronous Transport	Client invokes an asynchronous method. Reliable messaging runtime accepts the request; client returns to do other work. Reliable messaging runtime attempts to deliver the request and fails because the RM destination is down. Reliable messaging runtime waits for the retry interval and tries to send the request again. The request delivery fails again. RM destination comes up. Reliable messaging runtime waits for the retry interval and tries to send the request again. The request delivery succeeds. Acknowledgement is sent to the client which includes the message number of the request. The reliable messaging runtime removes the message from the retry list. Response arrives and the client processes it. Note: At any time, the client can check acknowledgement status, access information about a message, and so on, as described in Managing the Life Cycle of a Reliable Message Sequence.
Synchronous Transport	Client invokes a synchronous method. Reliable messaging runtime accepts the request and blocks the client thread. Reliable messaging runtime attempts to deliver the request and fails because the RM destination is down. Reliable messaging runtime waits for the retry interval and tries to send the request again. The request delivery fails again. RM destination comes up. Reliable messaging runtime waits for the retry interval and tries to send the request again. The request delivery succeeds. Response and acknowledgement are sent to the client via the transport back-channel. The acknowledgement includes the message number of the request. The reliable messaging runtime removes the message from the retry list. Reliable messaging runtime unblocks the client thread and returns the response. Client receives the response as the return value of the method invocation, and processes the response. Note: At any time, the client can check acknowledgement status, access information about a message, and so on, as described in Managing the Life Cycle of a Reliable Message Sequence. Note: To achieve true reliability with synchronous transport, it is recommended that you use MakeConnection. For more information, see Using Asynchronous Web Service Clients From Behind a Firewall (MakeConnection).

RM Source Down After Request is Made

Table 5-4 describes the reliable messaging failure recovery scenario when an RM source goes down after a request is made.
It is assumed that Web service buffering is enabled on both the Web service and client. Buffering is enabled on Web service clients by default. To configure buffering on the Web service, see Chapter 7, "Configuring Message Buffering for Web Services."

Table 5-4 Reliable Messaging Failure Recovery Scenario—RM Source Down After Request is Made

Transport Type	Scenario Description
Asynchronous Transport	Client invokes an asynchronous method. Reliable messaging runtime accepts the request; client returns to do other work. Client (RM source) goes down. Client comes up. Client must re-initialize the client instance using the same client ID. The runtime will use this client ID to retrieve the reliable sequence ID that was active for the client. For more information, see Managing the Client ID. Reliable messaging runtime detects the reliable sequence ID that was in use prior to the client going down and recovers the accepted requests. Note: This step is accomplished only after the client re-initializes the client instance that was used to send the request because delivery of the request depends on resources provided by the client instance. It is recommended that clients initialize the client instance in a static block, or use a @PostConstruct annotation or other mechanism to ensure early initialization of the client instance. For more information, see the best practices examples presented in Roadmaps for Developing Web Service Clients. Reliable messaging runtime sends the request and succeeds. Acknowledgement is sent to the client which includes the message number of the request. The reliable messaging runtime removes the message from the retry list. Response arrives and the client processes it. Note: At any time, the client can check acknowledgement status, access information about a message, and so on, as described in Managing the Life Cycle of a Reliable Message Sequence.
Synchronous Transport	Client invokes a synchronous method. Reliable messaging runtime accepts the request and blocks the client thread. Reliable messaging runtime attempts to deliver the request. The request delivery succeeds. Before response can be sent, the client (RM source) goes down. Client thread is lost as the VM exits, along with the invocation state and calling stack of the client itself. Client (RM source) comes up. Client must re-initialize the client instance (port or Dispatch) using the same client ID. For more information, see Managing the Client ID Reliable messaging runtime detects the previous sequence ID for the client, and sees that the last request was made synchronously. Reliable messaging runtime delivers a permanent failure notification for this request, and fails the entire RM sequence associated with the client instance. Any ReliabilityErrorListener associated with the client instance will be called at this point. Client is responsible for retrieving the original request (via some client-specific mechanism) and resending it by re-invoking the client instance with the request. Note: At any time, the client can check acknowledgement status, access information about a message, and so on, as described in Managing the Life Cycle of a Reliable Message Sequence. Note: To achieve true reliability with synchronous transport, it is recommended that you use MakeConnection. For more information, see Using Asynchronous Web Service Clients From Behind a Firewall (MakeConnection).

RM Destination Down After Request Arrives

Table 5-5 describes the reliable messaging failure recovery scenario when an RM destination is unavailable after a request has been accepted from the RM source.
It is assumed that Web service buffering is enabled on both the Web service and client. Buffering is enabled on Web service client by default. To configure buffering on the Web service, see Chapter 7, "Configuring Message Buffering for Web Services."

Table 5-5 Reliable Messaging Failure Recovery Scenario—RM Destination Down After Request Arrives

Transport Type	Scenario Description
Asynchronous Transport	Client invokes an asynchronous method. Reliable messaging runtime accepts the request; client returns to do other work. Reliable messaging runtime attempts to deliver the request and succeeds. The RM destination accepts the request and send an acknowledgement on the back channel. Reliable messaging runtime sees the acknowledgement and removes the message from the retry list. RM destination goes down. Reliable messaging runtime on RM source retries any pending requests during this time. RM destination comes up. RM destination recovers the stored request, processes it, and sends the response. Response arrives and the client processes it. Note: At any time, the client can check acknowledgement status, access information about a message, and so on, as described in Managing the Life Cycle of a Reliable Message Sequence.
Synchronous Transport	Note: If you attempt to invoke a buffered Web service using synchronous transport, one of following will result: If this is the first request of the sequence, the destination sequence will be set to be non-buffered (as though the Web service configuration was set as non-buffered). If this is not the first request of the sequence (that is, the client sent a request using asynchronous transport previously), then the request is rejected and a fault returned. The following describes the sequence of this scenario: Client invokes a synchronous method. Reliable messaging runtime accepts the request and blocks the client thread. Reliable messaging runtime attempts to deliver the request. The request delivery succeeds. RM destination accepts the request and sends an acknowledgement via the transport back channel. Client (RM source) detects the acknowledgement and removes the request from the retry list. RM destination goes down. Client thread remains blocked. RM Destination comes up, recovers, and processes the request, and sends the response to the client. Reliable messaging runtime unblocks the client thread and returns the response. Client receives the response as the return value of the method invocation, and processes the response. Note: At any time, the client can check acknowledgement status, access information about a message, and so on, as described in Managing the Life Cycle of a Reliable Message Sequence.

Failure Scenarios with Non-buffered Reliable Web Services

A non-buffered Web service operates differently than a buffered Web service in that it does not buffer a request to hardened storage before acknowledging it and attempting to process it. A non-buffered Web service will not attempt to reprocess a request if the service logic fails, whereas a buffered Web service will attempt to reprocess the request. In both cases, buffered or non-buffered, any response generated by the Web service will be buffered before it is sent back to the client.
A non-buffered Web service may be useful in the following cases:

• Web service operates against non-transactional resources and should not process any request more than once (because rolling back the transaction that dequeued the buffered request cannot roll back the side effects of the non-transactional service).
  
• Web service is relatively light weight, and does not take very long to process requests.
  
• Web service performance is of paramount importance and risk of losing request or response is acceptable. Non-buffered Web services will not incur the overhead of buffering the request to a store, and thus can deliver better throughput than a buffered Web service. The performance gain is dependent on how much time and resources are required to buffer the requests (for example, very large request messages may take significant time and resources to buffer).
  

A non-buffered Web service is operationally similar to a buffered Web service in most failure scenarios. The exceptions are cases where the service (RM destination) itself fails. For example, in all the RM source failure scenarios described, the behavior is the same for a buffered or a non-buffered Web service (RM destination). For non-buffered Web services the failure window is open between the following two points:

• The request is accepted for processing.
  
• The response from the Web service is registered for delivery to the client (RM source).
  

If the Web service (RM destination) fails between these two points, the RM source will assume the request has been successfully processed (since it has been acknowledged) but will never receive a response, and the request may never have been processed.
Carefully consider this failure window before configuring a Web service to run as non-buffered.