Qualities of service for WS-ReliableMessaging
We can get different qualities of service with WS-ReliableMessaging, depending on the level of durability and transaction support provided by the store used to manage the reliable messaging state. These qualities of service range from protecting against loss of messages across a network, through to protecting against server failure.
WebSphere Application Server provides the following three qualities of service for WS-ReliableMessaging when using a SOAP over HTTP binding. All three qualities of service are supported when applications are deployed to the application server. Thin client and client container applications use the first option only.
- Unmanaged non-persistent
- We can configure web service applications to use WS-ReliableMessaging with a default in-memory store. This quality of service requires minimal configuration. However it is non-transactional and, although it allows for the resending of messages that are lost in the network, if a server becomes unavailable we will lose messages. This quality of service is for single server only and does not work in a cluster. (ZOS) This quality of service is not supported on the z/OS platform.
- Managed non-persistent
- This in-memory quality of service option uses a messaging engine to manage the sequence state, and messages are written to disk if memory is low. This quality of service allows for the re-sending of messages that are lost in the network, and can also recover from server failure. However, state is discarded after a messaging engine restart so in this case we will lose messages. This option supports clusters as well as single servers.
- Managed persistent
- This quality of service for asynchronous web service invocations is recoverable. This option also uses a messaging engine and message store to manage the sequence state. Messages are persisted at the web service requester server and at the web service provider server, and are recoverable if the server becomes unavailable. Messages that have not been successfully transmitted when a server becomes unavailable can continue to be transmitted after the server restarts.
- The quality of service we get when using WS-ReliableMessaging is a direct result of the durability of the store managing the messages.
- When we use in-order delivery and either of the managed qualities of service, if the service causes an error then the message is re-dispatched to the service.
- We must ensure that when interacting with other vendors implementations of WS-ReliableMessaging, the other implementations provide the quality of service you require.
How the different qualities of service are implemented
When the web service application invokes the web service, the SOAP message is added into the WS-ReliableMessaging store. For the Managed qualities of service, the sending application transaction is used to put the message into the message store. After the transaction commits, the message is eligible for delivery. The other quality of service option is not transactional, so it considers the message eligible for delivery immediately.
The WS-ReliableMessaging protocol is used to reliably deliver the message to the target server where it is stored and acknowledged.
The message is read from the store and dispatched to the receiving application. For the Managed Persistent quality of service, a transaction is used to read the message and then dispatch the application.
For more information about using WS-ReliableMessaging transactions, see Providing transactional recoverable messaging through WS-ReliableMessaging.
Figure 1. Using stores to exchange web services messages reliably.
The managed qualities of service, managed persistent and managed non-persistent, are supported by the service integration bus. For each attachment between an application and a policy set, we can select the bus and messaging engine to use for the reliable messaging protocol state.