RE: [ebxml-msg] scenario: relaying acks

["Pim van der Eijk" <pvde@sonnenglanz.net>]

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