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)
- 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)
- 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.
- 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)
- 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.
- IU
sends sequenceAck header to ws-rm:RMS, using AcksTo epr...
2.4
Retransmitted Message Received by IU from RMS
for a Sequence
- If
the original message number has not yet been acknowledged, use the same
process as that for normal messages received.
- 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)
- 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.
- 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.
- 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..
- 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)
- 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.
- 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)
- 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..
- 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
- If
the original message number has not yet been acknowledged, use the same
process as that for normal messages received.
- 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.
|