Contribution on Interworking Scenarios for WS-Rel and WS-RM

[Tom Rutt <tom@coastin.com>]

This contribution fulfills my action item from the Feb TC meeting.

We should discuss this contribution before considering new features for 
WS-Reliability Specificaiton.

Tom Rutt

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Title: WS-Reliability Sender Interworking with WS-RM Destination

WS-Reliability and WS-RM interworking scenarios

 

Author: Tom Rutt, Fujitsu

 

Terms:

IU – Interworking Unit

Sending RMP – WS-Reliability sending entity

Receiving RMP – WS-reliability receiving entity

RMD -: WS-RM Receiving entity

RMS -   WS-RM sending entity.

1         Introduction

1.1      Scenarios outlined in contribution

Two interworking scenarios are outlined in this contribution. 

• RMS interwoking with Receiving RMP, using an Interworking unit (IU) such as that outlined in section 2 of this contribution.
• SendingRMP interworking with RMD, using an interworking unit such as that outlined in section 3 of this contribution.

1.2      High Level Simplifying Assumptions

• Interworking requires non singleton groups on WS-Reliability Side (efficiency concerns)
• Ws-rel side must engage guaranteed delivery, in this manner the IU does no retransmission of messages from its own timeouts, (the only messages retransmissions from IU to RMD are those it receives retransmitted from SourceRMS)
• The IU does not have to buffer messages, since they are buffered at the source.
• The IU does need to keep memory of messages which have been sent to its destination, and messages which have been acknowledged by its destination.  This is needed to translate the acknowledgement messages from one side to another ( since ws-rel only acks a message once per receipt, wsrm acks the entire sequence history with each ack response).
• Interworking facilitated by always mapping from Qos requested on one side, to greater Qos supported on other side.
• Interworking simplified by requiring callback Reply pattern for WS-Reliability
• These scenarios do not include sequence termination.  While straightforward, these interworking mappings are not shown in this version of the scenarios.

2         WS-RM Sender Interworking with WS-Rel Destination

2.1      CreateSequence Received by IU from RMS for a Sequence

(as wsRM:RMD)

1. IU inspects wsrm:CreateSequence message to determine wsrm:acksTo, and Sequence ID.  IU retains wsrm:AcksTo and the SequenceID for the sequence. IU may use special mechanisms to determine the agreed DA required for this sequence, otherwise it will rely on the default of asserting all ws-rel DAs (guranteed delivery, duplicate elimination, ordered delivery)  as True.

2.2      Message Received by IU from RMS for a Sequence

(as wsrm:RMD)

1. IU applies GroupID=SequenceID identity, sets all wsrel Qos indications (default or otherwise). IU places wsRel:SequenceNo as ws-rm:Number in ws-rel:Request header, and places received soap body in message to be sent.
2. IU sends “translated” message to ws-rel:ReceivingRMP, and updates memory of sent SequenceNo values which have not been acknowledged.

2.3      Response header Received by IU from ReceivingRMP

(as wsrel:SendingRMP for a GroupID)

1. IU applies GroupID=SequenceID identity, and updates its memory of non acked message number values to include new messages acked for sequence, and places received soap body in message to be sent to wsrm:RMS.
2. IU sends sequenceAck header to ws-rm:RMS, using AcksTo epr...

2.4      Retransmitted Message Received by IU from RMS for a Sequence

1. If the original message number has not yet been acknowledged, use the same process as that for normal messages received. 
2. If the original message number shows as already acknowledged in the sequence History buffer, IU sends sequenceAck header to wsrm:RMS, using AcksTo epr (not forwarding retransmitted message to ReceivingRMD)

2.5      AckRequested received by IU from RMS

IU responds with ackRequested Response, using its memory of message numbers sent to RMD and message numbers acknowledged by RMD.

3         WS-Rel Sender Interworking with WS-RM Destination

3.1      First Message Received by IU from SendingRMP for a Group

(as wsRel:Receiving RMP)

1. IU inspects ws-rel:request header to determine DA expected by Sender for the group (perhaps using application specific mechanisms to convey to RMD)  Reject group if guaranteed delivery not asserted for GroupID.
2. IU invokes wsrm:createSequence on wsrm:RMD.

·        Use WS-rel:ReplyTo address to construct wsrm:AcksTo EPR. 

·        Create mapping from sequenceID returned in CreateResponse to the GroupID from Sending RMP.

3. IU applies GroupID-SequenceID translation, and places ws-rel:SequenceNo as ws-rm:Number in ws-rm:Sequence header, and places received soap body in message to be transmitted to RMD..
4. IU sends “translated” message to ws-rm:RMD,  and updates memory of sent SequenceNo values which have not been acknowledged.

3.2      Subsequent Message Received by IU from S-RMP for a Group

(as wsRel:Receiving RMP)

1. IU applies GroupID-SequenceID translation, and places wsRel:SequenceNo as ws-rm:Number in ws-rm:Sequence header, and places received soap body in message to be sent.
2. IU sends “translated” message to ws-rm:RMD, and updates memory of sent SequenceNo values which have not been acknowledged.

3.3      SequenceAck header Received by IU from RMD

(as RMS for a sequenceID)

1. IU applies GroupID-SequenceID translation in reverse, and updates its memory of message numbers sent and acknowledged, placing those message numbers which were acked for the first time by this SequenceAck header as acknowledgements in a wsrel:ResponseHeader for that GroupID..
2. IU sends “translated” ack message to ws-rel:SendingRMP (using ws-rel:ReplyTo address), with only those message numbers which were acked for the first time.

3.4      Retransmitted Message Received by IU from S-RMP for a Group

1. If the original message number has not yet been acknowledged, use the same process as that for normal messages received. 
2. If the original message number shows as already acknowledged in the sequence History buffer, IU sends ws-Rel:Response header to sendingRMP, acknowledging the already acknowledged message number (not forwarding retransmitted message to RMD)..

3.5      WsRel:PollRequest received by IU from S-RMP

IU responds with wsrel:Response using its memory of message numbers sent to RMD and message numbers acknowledged by RMD.