When working with policy sets in the administrative console,
you can customize some policies.
Before you begin
This task assumes that you are working with a policy set
to which the WS-ReliableMessaging policy has been added.
Do not edit the policies associated with the provided
default policy sets. If you have to modify the reliable messaging
policy settings, use a copy of a default policy set or create a new
policy set.
At any stage - that is, before or after you have built your reliable web service application, or configured your policy sets - you can set a property that configures endpoints to only support clients that use reliable messaging. This setting is reflected by WS-Policy if engaged.
About this task
To configure the WS-ReliableMessaging policy for a given
policy set, use the administrative console to complete the following
steps:
Procedure
- In the navigation pane, click .
- Modify one or more of the following properties:
- Standard
Select the WS-ReliableMessaging specification to use for reliable transmission of your messages. WS-ReliableMessaging Version 1.1 is the default value. Select the WS-ReliableMessaging specification to use for reliable transmission of your messages. WS-ReliableMessaging Version 1.1 is the default value. Details of the supported WS-ReliableMessaging specifications are available at the following web addresses:
Note: If you plan to invoke a .NET-based web service, you must select WS-ReliableMessaging Version 1.0.
- Deliver messages in the order that they were sent
- Select this option if the sender of a request has to receive a response before it sends the next request, or if
you want to enable transaction support for inbound (provider) message
exchanges as described in Providing transactional recoverable messaging through WS-ReliableMessaging, or if you want
to marginally increase reliability as described in A message is not recovered after a server becomes unavailable.
Tip: When you enable this option, WS-ReliableMessaging ensures
that the messages are made available to the requester application
in the order that they were sent. That is, if WS-ReliableMessaging
cannot make a given message available, it will not make any subsequent
messages available. However, the requester application must also poll
for the messages in the order in which it is to receive them. For
example:
- WS-ReliableMessaging makes message 1 available, then message 2,
then message 3.
- The requester application uses asynchronous polling to deliberately
poll for message 2, then message 3, then message 1. All three messages
are available, so this polling out of order is successful.
Even though WS-ReliableMessaging is delivering the messages in
the order that they were sent, the requester application is choosing
to receive them out of order.
- Quality of service
- Select the radio button for your required quality of service.
The three choices are:
- Unmanaged non-persistent
- You 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 you will lose messages. This quality of service is for single server only and does not work in a cluster. 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 you 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 default is unmanaged non-persistent.Note: 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.
Note: In
WebSphere® Application Server Version
6.1, you could also configure whether to use
the WS-MakeConnection
protocol. This configuration option has now been removed from
the administrative console panel, because the product now automatically
determines whether WS-MakeConnection is used, based on the following
criteria:
- Whether you are using WS-ReliableMessaging Version 1.0 or Version
1.1.
- Whether the requester supports WS-MakeConnection.
- Whether the message exchange protocol is synchronous or asynchronous.
- Click OK.
- Save your changes to the master configuration.
Results
After you have customized the reliable messaging policy, the
associated policy set uses this policy to help ensure reliable delivery
of messages.