OASIS ebXML Messaging Services TC

Scenario:
-------------
Relayed ack 

Summary:
---------------

In this scenario intermediaries only acknowledge a message when they have received the acknowledgement from the next hop, which might be another intermediary or the ultimate destination. By "relaying" the acks an end-to-end reliability is created because a message will only be acknowledged as it is acknowledged by the ultimate destination.
 
Assumptions:
--------------------
 
- The sender does not have to know the ultimate destination (MSH URL) of its messages;
 
- WS-RM is used to support the RM functionality;

- The communicationpath between the two endpoint MSH's contains one or more intermediaries;

Description:
------------------
 
Each intermediary must have a sequence relation table, let's say the SRT,  in which it relates sequence id's for which it receives messages to sequence id's which it uses to send messages. 

Now when a CreateSequence RM signal is received by the intermediary the sequence id for the new sequence is added to the SRT without a related "sending sequence id". The related (sending) sequence id can't be set at this point because we don't know the ultimate destination of this sequence. This will only be known at the arrival of the first ebMS user message. 

So when the first ebMS user message arrives the next hop on the communication path is determined by the intermediary and a new WS-RM sequence is set up with the next hop by sending a CreateSequence signal to it. The resulting sequence id is added to the already created entry in the SRT. Now all WS-RM signals, including the acknowledgments, can be relayed between the two sequences.
 
Evaluation:
----------------
 
Advantage of this solution is that it does not require additional processing on the endpoints to get end-to-end reliability. Because the intermediary relays everything based on its SRT it also works using asynchronous intermediaries
The main drawback is that because the RM path being divided into separate legs there's no end-to-end security on the RM level. 

 
----
Sander Fieten
IT Architect

FIETEN IT
e: sander@fieten-it.com
t:  +31 6 51507886

 

Hello,

A couple of comments / questions:

1)  Does the RSP require WSRM headers to be signed?  

If yes, then Intermediary cannot create its own WSRM responses to requests
from Source, and it needs to copy the WSRM structures on incoming messages
on all outgoing messages.  Intermediary can only respond to Ackrequested by
forwarding this Ackrequested to Destination, and copying the response. But
that is basically the RM-transparent scenario, it goes beyond chaining two
separate RM processors and sequences. 

If no, then this scenario has some additional advantages compared to
RM-transparent:
-  There is no need for all messages on a sequence arriving at an
intermediary to be forwarded on a single sequence or to a single recipient.
All messages can be routed separately, i.e. Intermediary can inspect all
messages to determine the "next ebMS hop".  If it doesn't yet have a
sequence with that hop, it needs to set one up. If it already has a
sequence, it can reuse it.  If Source sends 10 messages to Intermediary it
can dispatch them on separate sequences to different Targets.  It may even
deliver some messages (acting as an Endpoint) and forward others (as an
Intermediary) without Source knowing.  All Source needs to know is that the
messages are all received by Intermediary.  

(This would not be possible if there is a one-to-one mapping between
incoming sequences and outgoing sequences, as Sander's description seems to
assume.)

2) We've discussed a special ebMS signal message that has more information
than other signals.  If that signal is bundled with the CreateSequence
message, it could be forwarded without having to wait for the first ebMS
UserMessage, as in the other scenarios.

3) There is the issue of getting the acknowledgment for the last message of
a sequence.  If the intermediary is asynchronous, some messages may still be
somewhere between sender and recipient.  This may trigger unnecessary
resends (unnecessary because, if Source had waited a bit longer,
Intermediary would have been able to deliver/forward the message and mark it
as received).  
Potential solutions:
-  Find a way to send the Ackrequested on a separate connection, giving the
intermediary time to successfully forward the message.
-  Rely on a WS-RM CloseSequence.  Contrary to the RM-transparent scenario,
there is no need to bundle this with an ebMS signal. 

4) More generally, Intermediary should check for receiptacknowledgments more
often than Source, to prevent unnecessary retries.

Pim