Follow-up on the
action item "pick a multi-hop case to discuss":
Let us pick the
first one(s) from the F2F notes:
- 1-way push across
intermediary.
I suggest we look at
all three 1-way / push subcases in the first ppt slide, because it is hard to
discuss a single subcase in isolation from others:
http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/document.php?document_id=25786
I suggest we use
terminology from Pim in its Intermediary requiremetns (September
9th):
- synchronous
intermediary: keeps the requestor connection open to forward the back-channel
response.
- transparent
intermediary: does not modify the eb:Messaging SOAP header nor any payload at
all.
So here are (some)
issues to discuss about this case:
issue
#1: the "transparent" behavior. Should an intermediary
NEVER change the ebMS headers? Note that this does not apply to the Reliability
or Security headers: the intermediary could still be configured to be a
reliability endpoint, or a security endpoint. But if transparent, that means the
MPC will not change end-to-end, because it is indicated in the ebMS header. So
the following case would NOT be possible: the Intermediary gets a message on MPC
#1, and forward it to next MSH on MPC#2 or MPC #3 depending on
routing.
my opinion:
transparency is attractive: not only makes security simpler, but also the MPC
can be seen as an end-to-end channel, might be used as the routing function in
many cases (or as one invariant of the routing function).
issue #2: the "synchronous"
behavior. In the ppt slide, the two first subcases are
"asynchronous", the third subcase ("robust" push) is synchronous. Should the
synchronous behavior be supported? Advantage: makes the Intermediary really
invisible for the initial sender: all modes of error reporting and Acks, etc.,
that are possible without intermediary, are still possible with this
intermediary. Issue: keeping a connection open for a time that is unknown. That
makes it even harder to consider a chain of several intermediaries. If we give
up on the transparency property, some modes of backchannel use will simply not
be possible with intermediaries.
my opinion: the synchronous intermediary does not have
much value for 1-way MEPs, might be an item to discuss again for 2-way /
sync. In addition, total "invisibility" of the intermediary may not be
achievable: it is still an MSH and as such can generate its own ebMS
Errors.
issue #3: Mixing
sync-async. In case of "asynchronous" Intermediary, can we still have
the last leg of 1-way be synchronous? (this would be a fourth subcase to add to
the 3 previous ones). So we could have a 1-way end-to-end reliable with
communication between MSH A and Intermediary same as subcase #2, but from
Intermediary to MSH B, the RM Ack would be obtained synchronously. In other
words, the last leg Intermiediary-ultimateMSH is not restricted at all for RM
modes, and Error reporting modes.
my opinion: I see no inconvenient in allowing this.
That seems to remove some of the restrictions of pure async behavior. E.g. the
communication Intermediary-ultimateMSH is unrestricted. Consider the case
where MSH A used to send directly to MSH B in a synchronous manner. Now we
add an (async) intermediary between both. MSH B can still function as
before - no need to change its configuration or P-mode, in case B is only a
receiver.
Jacques
