Tag Archives: WS-RM

WS-ReliableMessaging in webMethods as provider

WS-ReliableMessaging in webMethods as provider
Integration Server uses the WS-ReliableMessaging protocol to reliably send SOAP messages between web service providers and clients even if the destination endpoint is temporarily unavailable or if the network connection fails. The WS-ReliableMessaging protocol defines how messages should be sent again if they are not delivered successfully, thereby ensuring that the messages are delivered to the destination endpoint and that duplicate messages are not delivered.

webMethods 9 Integration Server supports WS-ReliableMessaging Version 1.1 only. Hence the namespace prefix wsrm should use the URI http://docs.oasis-open.org/wsrx/wsrm/200702. For more details about WSRM 1.1, please visit http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01-e1.html

Message exchange example
The following figure illustrates a possible message exchange between two reliable messaging Endpoints A and B.

Create web service provider implement WSRM in webMethods
To use WS-ReliableMessaging, you can attach a pre-defined WS-Policy named ReliableMessaging that Integration Server provides. This policy is available in the following directory: Integration Server_directoryconfigwsspolicies

Integration Server provides pub.soap.wsrm built-in services to create and manage reliable messaging sequences. These services are useful when Integration Server acting as web service client.

One tricky thing here is the flow service attached to this provider descriptor should only have input. This means the web service created in webMethods is in one way (request) mode not a normal request/response mode.

Test WSRM from SOAPUI
Enable WS-RM if desired and set the corresponding version. Now when sending the request SOAPUI will first initiate a WS-RM Sequence with the target service and use that for the request. After completed the WS-RM Sequence will be closed accordingly.

If you switch to http log view, you will find SOAPUI actually make four SOAP requests to the destination. CreateSequence -> ActualWebService -> CloseSequence -> TerminateSequence. With this information, we can build our own version of test cases without using the build-in options in SOAPUI.

Build test cases in SOAPUI test suite

Step1. Add property named Identifier in properties list.

Step2. Add SOAP request named createSequence. This web service will get sequence identifier from Integration Server. Remember to select Skip SOAP Action as true so SOAPUI won’t put SOAP Action in http header.

Step3. Save Identifier from step2 into properties list. This value will be used for the following SOAP request steps.

Step4. Add SOAP request as the first request. Replace Identifier in SOAP request as the value in step3. Set message number to 1 which means this is the first message in sequence. The response in SOAPUI:

<wsrm:AcknowledgementRange Lower=”1″ Upper=”1″/>

Step5. Add a second SOAP request similar to step4. Set message number to 3. The response in SOAPUI:

<wsrm:AcknowledgementRange Lower=”1″ Upper=”1″/>
<wsrm:AcknowledgementRange Lower=”3″ Upper=”3″/>

Step6. Add a third SOAP request similar to step4. Set message number to 2. This is to test when web service client send requests in wrong order, how Integration Server handles them.

<wsrm:AcknowledgementRange Lower=”1″ Upper=”3″/>

Step7. Add SOAP request named closeSequence. The response from Integration Server will be HTTP/202 Accepted.

Step8. Add SOAP request named terminateSequence. The response from Integration Server will be HTTP/202 Accepted.

Delivery assurances: InOrder
Messages from each individual Sequence are to be delivered in the same order they have been sent by the Application Source. The requirement on an RM Source is that it MUST ensure that the ordinal position of each message in the Sequence (as indicated by a message Sequence number) is consistent with the order in which the messages have been sent from the Application Source. The requirement on the RM Destination is that it MUST deliver received messages for each Sequence in the order indicated by the message numbering.

My previous example simulates the 2nd message in sequence lost in transit and resend to destination after the 3rd message transmitted.

For webMethods server log file, you will find webMethods will NOT process the 3rd message until it received the 2nd message in sequence. This is how webMethods guarantee message delivery in order.