OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 1-way push across intermediaries


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]