Reliable Messaging Locate
Reliable messaging is accessed in WSO2 SOA Enablement Server via the Sequence API and is implemented by the WS-ReliableMessaging provider. It is used in the same way for both dynamic proxy invocations and JAX-RPC dynamic calls. Required delivery assurances are configured using WS-RM Policy. WSO2 SOA Enablement Server supports persistent sequences with minimal programming changes required in the application.
WS-ReliableMessaging Locate
WSO2 SOA Enablement Server for Java implements the WS-Reliable Messaging (WS-RM) protocol. WS-RM guarantees the delivery of messages from Source to Destination regardless of software component, system, or network failures. WS-ReliableMessaging by itself does not define all the features required for a complete messaging solution. This building block is used in conjunction with the WS-Addressing and WS-Policy families of specifications, which are also implemented in WSO2 SOA Enablement Server for Java. WS-Addressing can be used for request/response correlation and transferring an endpoint policy from Destination to Source (please see WS-Addressing). The WS-RM specification is used for expressing the capabilities, requirements, and general characteristics of endpoints or other entities in an XML Web Services-based system.
![[Note]](images/note.gif) | Note |
|---|---|
WSO2 SOA Enablement Server for Java currently implements the February 2005 version of the WS-RM protocol. | |
WS-Reliable Messaging provides an interoperable protocol that a Source and Destination use to provide application source and destinations a guarantee that a message that is sent will be delivered. The guarantee is specified as a delivery assurance. It is the responsibility of the WS-RM Source and WS-RM Destination to fulfill the delivery assurances, or raise an error, as shown in Figure 20.
The WS-RM protocol allows endpoints to meet this guarantee for these delivery assurances:
- AtMostOnce
Messages will be delivered at most once without duplication or an error will be raised. It is possible that some messages in a sequence may not be delivered.
- AtLeastOnce
Every message sent will be delivered or an error will be raised. Some messages may be delivered more than once.
- ExactlyOnce
Every message sent will be delivered without duplication or an error will be raised. This delivery assurance is the logical "and" of the two prior delivery assurances.
- InOrder
Messages will be delivered in the order that they were sent. This delivery assurance may be combined with any of the above delivery assurances. It requires that the sequence observed by the destination be non-decreasing. It says nothing about duplications or omissions.
![[Important]](images/important.gif) | Important |
|---|---|
To use WS-ReliableMessaging, wsrm.jar must be added to the client classpath. Please see WSO2 SOA Enablement Server Client Packages. | |
WS-RM Scenarios Locate
Asynchronous vs. Synchronous Invocation Locate
Reliable communication can be established on the client side using either the WSO2 SOA Enablement Server asynchronous (non-blocking) or synchronous (blocking) invocation API together with Sequence API. The asynchronous API will be symbolized by beginXXX and endXXX methods in the following text. The Synchronous API can be much more straightforward for a user but it has some limitations:
The nature of synchronous invocation disallows the invocation or a response delivery to continue after restart. This means that when a synchronous invocation is interrupted (the application is shut down or crashes) the client application must create the request message again for it to continue in the sequence of unfinished requests.
A reliable response should be explicitly confirmed because the client WS-RM destination does not know when a response is delivered to the application destination.
The asynchronous API is much more suitable for reliable communication. It is also recommended to use a callback listener (see org.systinet.wasp.async.AsyncCallback and org.systinet.wasp.async.GenericAsyncCallback). Otherwise, explicit confirmation is required for the endXXX method, as with the synchronous API. With callback listeners, responses are confirmed implicitly by default when a callback invocation is finished.
| Note |
|---|---|
The current version of WSO2 SOA Enablement Server for Java does not implement the persistent AsyncConversation from the asynchronous invocation API, so responses can not be delivered after WSO2 SOA Enablement Server client restart. This will be fixed soon. | |
| Note |
|---|---|
If an invocation is made against a nonexistent endpoint, WS-RM will continue trying to deliver the message until the sequence invocation timeout is reached. This timeout can be specified in a policy. This means that the synchronous invocation or endXXX is blocked for this interval. Using asynchronous invocation with a callback listener does not block the application in this case. | |
| Note |
|---|---|
A received WS-RM message is always confirmed regardless the client or server side. On the client side, however, we recommend using explicit confirmation as implicit confirmation cannot ensure reliability between WSO2 SOA Enablement Server processing and the application code. For details, see setExplicitConfirmation(boolean) in org.systinet.wasp.wsrm.sequence.InputSequence and confirmCurrentMessage() in org.systinet.wasp.wsrm.sequence.InputSequence. | |
One-Way vs. Request/Response Invocation Locate
One-way invocation is shown in Figure 20. The semantics of one-way invocation methods follows:
Synchronous invocation: It tries to deliver a message multiple times (depending on policy) and waits until the message is acknowledged.
Asynchronous beginXXX: It returns immediately when an AsyncConversation is created and the message is queued.
Asynchronous endXXX: It waits until the message is acknowledged.
Request/response is more complicated because two reliable channels are used, one for request(s) and the second one for response(s), as shown in Figure 21. These two channels are also called as a duplex sequence. For details, see org.systinet.wasp.wsrm.sequence.DuplexSequence.
The semantics of request/response invocation methods is similar as those for one-way invocation above:
Synchronous invocation: It tries to deliver a request multiple times (depending on policy) and waits until the request is acknowledged and for a response.
Asynchronous beginXXX: It returns immediately when an AsyncConversation is created and the request is queued.
Asynchronous endXXX: It waits until the request is acknowledged and for a response.
Anonymous vs. Non-Anonymous Clients Locate
A service client can be anonymous (by default) or non-anonymous. Non-anonymous clients have a public 'callback' endpoint and are able to receive a response or WS-RM acknowledgment in a different transport channel than they used for the request. Figure 21 shows request/response communication using a non-anonymous client where each arrow can be a different transport channel. Non-anonymous clients are created in WSO2 SOA Enablement Server by setting a callback transport and a callback endpoint path on the ServiceClient:
serviceClient.setAsyncTransport("http");
serviceClient.setAsyncEndpointPath("/myservice/callback");When the callback endpoint path is not set up from the application, a transient unique path is generated automatically. However, if the application uses persistent WS-RM sequences, the callback endpoint path must remain the same after restart, which can only be done if the path is set by the application.
When creating a new instance of sequence (see createSequence(org.systinet.wasp.webservice.ServiceClient) in org.systinet.wasp.wsrm.sequence.OutputSequenceRegistry, loadSequence(java.lang.String,%20org.systinet.wasp.webservice.ServiceClient) in org.systinet.wasp.wsrm.sequence.OutputSequenceRegistry, createSequence(org.systinet.wasp.webservice.ServiceClient) in org.systinet.wasp.wsrm.sequence.DuplexSequenceRegistry or loadSequence(java.lang.String,%20org.systinet.wasp.webservice.ServiceClient) in org.systinet.wasp.wsrm.sequence.DuplexSequenceRegistry), make sure that the callback service has been published prior to this sequence instantiation.
Anonymous clients have no true URL (location) but can have symbolic URIs. For example, WS-Addressing '2004/08' uses http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous. Messages can be sent to the anonymous client only as responses using a request/response transport like HTTP. It is not possible to use a one-way transport like the mail transport with anonymous clients. When an invocation from an anonymous client is one-way, the acknowledgement must be sent as an HTTP response. When the invocation is request/response, the acknowledgment must be 'piggybacked' to the response, as shown in Figure 22.
It is much more effective to use non-anonymous clients but this is not possible in all situations. One typical situation when an anonymous client must be used is when the client is behind a firewall and it cannot have a visible endpoint.
Persistence Locate
A client or server application can be interrupted at any moment either correctly (shutdown) or incorrectly (application crash, electric failure etc.). A reliable application must be resistant to such interruptions. When it is started again it must have exactly the same state as before the interruption. The state of the WSO2 SOA Enablement Server reliable application contains:
ServiceClient(s) A client processing. It can contain a callback endpoint when the client is non-anonymous. It can be persistent (as a whole or in part) and can be changed transiently at runtime. The application must create the same ServiceClients regardless of whether it is restarting after a crash or a correct shutdown.
ServiceEndpoint(s) An endpoint processing. When they are deployed persistently into the WSO2 SOA Enablement Server they are loaded and instantiated automatically by the WSO2 SOA Enablement Server service container. When runtime publishing is used it must be set in the bootstrap application that the same ServiceEndpoints are always created and published.
ServiceClientContext(s), ServiceEndpointContext(s) These are usually configurations of processings. They are not persistent and the application must create the same contexts when it is started.
Endpoint policy The policy of a client destination (anonymous endpoint or callback endpoint) or a service destination (service endpoint) merged with a default policy. It can be deployed persistently or at runtime but in the latter case it is not stored by WSO2 SOA Enablement Server and the application must always publish the policy the same way when it is started.
Client, endpoint configuration Configuration using WSO2 SOA Enablement Server configuration API. The WSO2 SOA Enablement Server configuration framework is very lightweight and has no transactional capabilities. It is not recommended to use it in persistent reliable applications.
Application own state It the application has its own persistent state it should use a transactional storage such as databases offer and commit the transactions before the message delivery is confirmed. Please also see Delivery Confirmation.
Output reliable sequences Output sequences created by the application logic. Only the client output sequences must be loaded by the application logic when WSO2 SOA Enablement Server is started. There are usually some incomplete sequences on restart and the client application must continue in them. A service output sequence is loaded automatically when the particular endpoint is published. It assumes that the service output sequence's responses are related to requests and only when a new request is delivered is a response sent.
Input reliable sequences Input (received) sequences created by the WS-RM reliability provider. They are loaded by the WS-RM provider when a given endpoint is published.
Both input and output sequences are persistent by default. The sequence's messages are also persistent. To ensure persistence, the SequenceStore module is deployed to WSO2 SOA Enablement Server together with the WS-RM provider (you can see this in the deployment descriptor wsrm.jar#WASP-INF/package.xml). It uses relational database storage in this version of WSO2 SOA Enablement Server for Java and it stores all sequence changes immediately when necessary. When WSO2 SOA Enablement Server starts, it rolls back all unfinished (uncommitted) transactions if any exist.
| Important |
|---|---|
Persistent reliable messaging requires a JDBC database server. Please see Database Configuration. | |
Delivery Confirmation Locate
Delivery confirmation makes sense for a request delivery on the service side or for a response delivery on the client side. If the message delivery is not confirmed it is delivered to the application again after restart. Delivery confirmation can be either explicit or implicit. Explicit confirmation is performed by the application and is useful for the service in the following situations:
One-way invocation
Reliable request and non-reliable response
Reliable request and reliable response but the request processing is asynchronous and long-term
Explicit confirmation can be used on the client side with:
Synchronous request/response invocation
Asynchronous request/response invocation without AsyncCallback
Asynchronous request/response invocation with AsyncCallback when the response processing is asynchronous and long-term
In all cases on the client as well as on the server side, implicit confirmation is used by default. However, it is recommended to use explicit confirmation, as implicit confirmation cannot ensure reliability between WSO2 SOA Enablement Server processing and the application code.
For an application to confirm a message delivery explicitly, it must call sequence.setExplicitConfirmation(true). This sequence attribute is persistent so it should be called in SequenceListener.onCreate. For example, on the service side:
public class MyService implements MyServiceIface, ServiceEndpointListener {
private SequenceListener listener = new GenericSequenceListener() {
public void onCreate(OneWaySequence sequence) {
if(!sequence.isOutput()) {
// for input sequences only
try {
((InputSequence)sequence).setExplicitConfirmation(true);
} catch (SequenceException e) {
System.out.println("Exception thrown when setting explicit confirmation: "+e);
}
}
}
};
public void onPublish(ServiceEndpoint serviceEndpoint) {
SequenceRegistry.addSequenceListener(this.listener, serviceEndpoint);
}
public void onUnpublish(ServiceEndpoint serviceEndpoint) {
SequenceRegistry.removeSequenceListener(this.listener, serviceEndpoint);
}
...
}The application logic must count with repeated delivery of responses on the client side or requests on the service side. It is possible that WSO2 SOA Enablement Server will be interrupted after a message is processed by the application logic and before the message delivery is confirmed. Such a message is delivered to the application again when WSO2 SOA Enablement Server is started and delivery is repeated until confirmed. The application logic can discriminate that the message was already delivered by the sequence ID and the message number.
| Note |
|---|---|
We plan to add support for JTA in the next release. This will allow WS-RM delivery transaction to be joined with a user transaction (for example, storing request data in the database). | |
Logging and Debugging in WS-RM Locate
In the WSO2 SOA Enablement Server for Java implementation of WS-ReliableMessaging, messages are resent until receipt of an acknowledgment of successful delivery or notification of another state described in the WS-RM specification (such as sequence expiration, etc.).
By default, log4j does not log individual unsuccessful delivery attempts to the console or elsewhere. For example, when the server is not running and the client sends a message, WS-RM stores the message in the message store and tries to resend the message periodically, at a specified interval, without recording the failed attempts.
When you want to log debug messages about individual unsuccessful delivery attempts, you have to reconfigure log4j. In this case the following lines need to be added to the log4j.config file or to your custom log4j configuration:
log4j.category.com.systinet.wasp.wsrm.feb2005=DEBUG,stderr log4j.additivity.com.systinet.wasp.wsrm.feb2005=false
You must also set log4j as your WSO2 SOA Enablement Server logger, by setting the property idoox.debug.logger to log4j (please see Logging and Debug Messages).
For example, when a client cannot send a message because the server is not running, ClientInvocation will log the following message:
DEBUG: provider.ClientInvocation - Can't send message, will try later Caused by: java.net.ConnectException: Connection to localhost:6060 refused
WS-RM Policy Locate
WS-RM policy consists of WS-Policy enhanced by special WS-RM policy assertions. WS-RM specification leverages the WS-Policy family of specifications to enable a destination endpoint to describe and advertise its capabilities and/or requirements, and to enable a source endpoint to communicate to the destination the selected characteristics that apply for a given sequence. The endpoint capabilities and/or requirements are described in policy document and can be attached to an individual sequence, to sequences in general, to particular ServiceEndpoint etc. WSO2 SOA Enablement Server for Java now supports a policy attachments per:
EndpointReference: Policy attachment per WS-Addressing endpoint reference as defined in the WS-PolicyAttachment specification.
ServiceEndpointReference: Policy attachment per WSO2 SOA Enablement Server ServiceEndpoint. It's similar to the previous one but a policy is attached to particular endpoint path only. You can see the difference in the following example:
Example 227. EndpointReference vs. ServiceEndpointReference Policy Attachment
<wsp:PolicyAttachment> <wsp:AppliesTo> <wsa:EndpointReference> <wsa:Address>http://localhost:6060/demo/basic/HelloService</wsa:Address> </wsa:EndpointReference> </wsp:AppliesTo> <wsp:Policy> ... </wsp:Policy> <wsp:PolicyAttachment> <wsp:PolicyAttachment> <wsp:AppliesTo> <wasp:ServiceEndpointReference> <wasp:Path>/demo/basic/HelloService</wasp:Path> </wasp:ServiceEndpointReference> </wsp:AppliesTo> <wsp:Policy> ... </wsp:Policy> <wsp:PolicyAttachment>Global policy attachment (DefaultDomainExpression): A policy attachment for all endpoints in given WSO2 SOA Enablement Server. You can see such policy attachment in WASP_HOME/conf/policy.xml or in the WS-RM component in WASP-INF/policy.xml. It looks like:
| Note |
|---|---|
The model of policy assertions used in WSO2 SOA Enablement Server for Java to set up reliable messaging is not final and may become a subject of change in future releases. | |
The set of policy assertions for reliable delivery supported by WSO2 SOA Enablement Server for Java is defined in the following sections.
Delivery Assurance Locate
This assertion establishes well-known names for application level delivery assurances between the initial sender and the ultimate receiver. The delivery assurance is an informational policy assertion, as it does not affect the WS-RM transmission protocol.
The following pseudo schema defines this assertion in XML:
<wsrm:DeliveryAssurance Value="[QName]" ...> ... </wsrm:DeliveryAssurance>
This attribute contains one aspect of a sequence's reliability guarantee. Its value is a QName. QNames and their specific meanings are in Table 37, “Delivery Assurances and their QNames”.
Table 37. Delivery Assurances and their QNames
| QName | Delivery Assurance |
|---|---|
| wsrm:AtMostOnce | Messages will be delivered only one time or an error will be raised on at least one endpoint. It is possible that some messages in a sequence may not be delivered. |
| wsrm:AtLeastOnce | Every message sent will be delivered or an error will be raised on at least one endpoint. Some messages may be delivered more than once.. |
| wsrm:ExactlyOnce | Every message sent will be delivered without duplication or an error will be raised on at least one endpoint. This delivery assurance is the logical "and" of AtMostOnce and AtLeastOnce. |
| wsrm:InOrder | Messages will be delivered in the order that they were sent. This delivery assurance may be combined with any of the above delivery assurances. It requires that the sequence observed by the ultimate receiver be non-decreasing. It says nothing about duplications or omissions. |
At runtime, the delivery assurance assertion is represented by the class org.systinet.wasp.wsrm.feb2005.policy.DeliveryAssuranceAssertion.
Inactivity Timeout Locate
This assertion specifies (in milliseconds) a period of inactivity for a Sequence. If an endpoint receives no application or control messages for this period, the endpoint considers the Sequence to have terminated due to inactivity.
The following pseudo schema defines this assertion in XML:
<wsrm:InactivityTimeout Milliseconds="[unsignedLong]" ...> ... </wsrm:InactivityTimeout>
The milliseconds attribute carries the value of the inactivity timeout duration, specified in milliseconds, expressed as an unsignedLong.
At runtime, the inactivity timeout assertion is represented by the class org.systinet.wasp.wsrm.feb2005.policy.InactivityTimeoutAssertion.
Retransmission Interval Locate
A source may optionally specify a base retransmission interval for a sequence. If no acknowledgement has been received for a given message within the interval, the source will retransmit the message. The retransmission interval may be modified at the source's discretion during the lifetime of the sequence. This assertion does not alter the formulation of messages as transmitted, only the timing of their transmission. The retransmission interval assertion can be combined with the ExponentialBackoff, which is adjusted using the exponential backoff algorithm.
The following pseudo schema defines these assertions in XML:
<wsrm:BaseRetransmissionInterval Milliseconds="[unsignedLong]" ...> ... </wsrm:BaseRetransmissionInterval> <wsrm:ExponentialBackoff ...> ... </wsrm:ExponentialBackoff>
The milliseconds attribute specifies the interval in milliseconds the source will wait after transmitting a message and before retransmitting the message.
At runtime, the retransmission interval and exponential back off assertions are represented by the classes org.systinet.wasp.wsrm.feb2005.policy.RetransmissionIntervalAssertion and org.systinet.wasp.wsrm.feb2005.policy.ExponentialBackoffAssertion.
| Note |
|---|---|
The exponential backoff algorithm is not implemented in the current version of WSO2 SOA Enablement Server for Java and thus the appropriate value in the policy makes no difference. | |
Acknowledgement Interval Locate
Acknowledgements can be sent on return messages or sent stand-alone. In the event that a return message is not available to send an acknowledgement, a destination sends a stand-alone acknowledgement when the acknowledgement interval has passed. If there are no unacknowledged messages, the destination may choose not to send an acknowledgement.
This assertion does not alter the formulation of messages or acknowledgements as transmitted. Its purpose is to communicate the timing of acknowledgements so that the source may tune itself appropriately. It does not alter the meaning of the <AckRequested> directive.
The following pseudo schema defines this assertion in XML:
<wsrm:AcknowledgementInterval Milliseconds="[unsignedLong]" ...> ... </wsrm:AcknowledgementInterval>
The milliseconds attribute specifies the Acknowledgement interval in milliseconds.
At runtime, the acknowledgement interval assertion is represented by the class org.systinet.wasp.wsrm.feb2005.policy.InactivityTimeoutAssertion.
Default Configuration of WS-RM Assertions Locate
The default configuration of the WS-RM assertions is included in the WS-RM component in WASP-INF/policy.xml. This component can be found in WASP_HOME/lib/wsrm.jar on the client side and WASP_HOME/app/system/wsrm.jar on the server side.
The default configuration contains WS-RM assertions as given in Example 229.
Example 229. Initial Default Configuration of WS-RM Assertions
<wsp:Policy Name="DefaultProfile" TargetNamespace="http://systinet.com/wasp/app/ws_rm_feb2005"> <wsrm:DeliveryAssurance Value="wsrm:InOrder" wsp:Usage="wsp:Observed"/> <wsrm:DeliveryAssurance Value="wsrm:ExactlyOnce" wsp:Usage="wsp:Observed"/> <wsrm:InactivityTimeout Milliseconds="86400000" wsp:Usage="wsp:Observed"/> <wsrm:BaseRetransmissionInterval Milliseconds="3000" wsp:Usage="wsp:Observed"/> <wsrm:ExponentialBackoff wsp:Usage="wsp:Observed"/> <wsrm:AcknowledgementInterval Milliseconds="1000" wsp:Usage="wsp:Observed"/> </wsp:Policy>
If you want to change this default configuration, you can do so either at runtime or persistently in a custom deployment descriptor.
Change Default Configuration at Runtime Locate
Example 230 shows how to change delivery assurance at runtime for a service endpoint published using Registry. Delivery assurance is changed from the default value InOrder, ExactlyOne to InOrder, AtLeastOnce.
Example 230. Changing Default Configuration at Runtime
// create service endpoint
ServiceEndpoint endpoint = ServiceEndpoint.create("demo/basic/HelloService",
HelloService.class);
// create policy
Policy policy = PolicyManager.createPolicy();
policy.add(new DeliveryAssuranceAssertion(DeliveryAssurance.AtLeastOnce),
PolicyUsage.OBSERVED);
// attach policy to appropriate service endpoint reference
PolicyManager.attachPolicy(new ServiceEndpointReference(endpoint), policy);
// publish endpoint
Registry.publish(endpoint);
Example 231 shows how to change the retransmission interval at runtime for a service endpoint published using Registry:
Example 231. Changing Retransmission Interval at Runtime
ServiceClient client = ServiceClient.create("http://localhost:6060/demo/basic/HelloService");
Policy policy = PolicyManager.createPolicy();
policy.add(new RetransmissionIntervalAssertion(1000), PolicyUsage.OBSERVED);
PolicyManager.attachPolicy(new EndpointReference(
"http://localhost:6060/demo/basic/HelloService"), policy);
Changing Default Configuration Persistently in the Policy File Locate
The Policy file defines the persistent configuration of a policy. WSO2 SOA Enablement Server for Java contains a default policy file at WASP-INF/policy.xml. The schema of the policy file is presented in WASP_HOME/conf/policy10.xsd.
A Policy file is an XML document with policyDocument as the root element. The policyDocument can contain either PolicyAttachment or Policy elements. Their schemas correspond to the schemas from the WS-PolicyAttachment and WS-Policy specifications respectively.
The PolicyAttachment element The PolicyAttachment element associates a particular policy with a policy subject - domain expression. As written in WS-RM Policy, WSO2 SOA Enablement Server for Java supports the attachment of a policy to EndpointReference, ServiceEndpointReference and globally throughout a server to DefaultDomainExpression.
| Note |
|---|---|
The current implementation does not support the attachment of a policy to an individual sequence or sequence prefix by SequenceRef as defined in the WS-RM specification. Also the PolicyReference element is not currently supported, meaning that a policy definition cannot be shared across policy expressions. | |
The Policy element A Policy that is defined outside the PolicyAttachment is not directly attached to a domain expression. Instead it can be attached at runtime on the basis of the Policy attributes Name and TargetNamespace. Example 232 shows how to attach a policy persistently defined in a policy.xml to a ServiceEnpointReference but not as part of a PolicyAttachment.
Example 232. Attaching a Policy Outside of a PolicyAttachment Element
<?xml version="1.0" encoding="UTF-8"?>
<wasp:PolicyDocument xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy"
xmlns:wasp="http://systinet.com/wasp/policy/1.0">
<wsp:Policy Name="HelloServicePolicy"
TargetNamespace="http://systinet.com//demo/basic/HelloService ">
</wsp:Policy>
</wasp:PolicyDocument>
Policy policy = PolicyManager.getPolicy(new QName("HelloServicePolicy",
"http://systinet.com/demo/basic/HelloService"));
PolicyManager.attachPolicy(new ServiceEndpointReference("/demo/basic/HelloService"),
policy);
Policy assertions can also be changed persistently. The policy file in Example 233 shows how to change delivery assurance and retransmission interval for your service persistently. Delivery assurance is changed from the default value InOrder, ExactlyOne to the AtLeastOnce. (InOrder is set as Ignored in this case).
Example 233. Changing Delivery Assurances Persistently
<?xml version="1.0" encoding="UTF-8"?>
<wasp:PolicyDocument xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy"
xmlns:wasp="http://systinet.com/wasp/policy/1.0"
xmlns:wsrm="http://schemas.xmlsoap.org/ws/2003/03/rm">
<wsp:PolicyAttachment>
<wsp:AppliesTo>
<wasp:ServiceEndpointReference>
<wasp:Path>/demo/basic/HelloService</wasp:Path>
</wasp:ServiceEndpointReference>
</wsp:AppliesTo>
<wsp:Policy>
<wsrm:DeliveryAssurance wsp:Preference="100"
Value="wsrm:InOrder"
wsp:Usage="wsp:Ignored"/>
<wsrm:DeliveryAssurance wsp:Preference="100"
Value="wsrm:ExactlyOnce"
wsp:Usage="wsp:Observed"/>
<wsrm:BaseRetransmissionInterval wsp:Preference="100"
Milliseconds="3500"
wsp:Usage="wsp:Observed"/>
</wsp:Policy>
</wsp:PolicyAttachment>
</wasp:PolicyDocument>Clustering Locate
It is possible to use clustering with reliable messaging. For information on setting up WS-RM support in clustering, please see WS-ReliableMessaging Support.