RE: [ebxml-msg] 1-way push across intermediaries

["Moberg Dale" <dmoberg@axway.com>]

- 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.

 

Additional issues about this first case.

 

How will an intermediary “tell” how it is to behave with respect to, for example, HTTP status values, with respect to the next hop, and with respect to reliability acks?

    a. Is there some information “on the wire” that enables it to tell what its behavior is to be? What information?

    b. Is there additional information in a configuration table that combines with information on the wire that tells the intermediary what its behavior is to be?

Note 1: We assume that the XMLP processing model with respect to SOAP header and body processing is operative.

Note 2:  We assume that a MEP binding value will distinguish MEPs with intermediaries from MEP values where intermediaries are missing. Parameters that

 distinguish the MEP binding with intermediary are SOAP path length and some way of indicating that the HTTP reply it produces involves “waiting for” a response from its next hop.

 

Discussion:

 

In the core the MEP and MEP binding discussion states

An MEP that is associated with a particular transport channel binding is also called a transport-channelbound

MEP. A transport-channel-bound MEP is identified by a pair <MEP name / transport-channelbinding

name>. For example, a Two-Way ebMS MEP that executes over a single request-response

exchange of the underlying transport (e.g. HTTP), is called a Two-Way/Sync MEP.

 

There were 3 distinguished transport-channelbinding names. In introducing SOAP paths of length greater than 2, and waiting behavior we introduce a lot of new combinations

 

Abstractly each new channel can be push, pull or sync (to indicate user message mappings) and then can be

pathlength{3} waitlist{2} to indicate how many SOAP nodes are involved and which nodes (counting from initial sender as 1) wait for a response before producing a response.

 

Pure cases can be indicated by pathlength{n} waitlist{all} or waitlist{none}

 

I expressed the hope that we not deal with cases other than waitlist{all} and waitlist{none}, so that the mixed cases are not treated.

 

An intermediary can then have a PMode MEP binding value that tells it whether to wait or not. (In the mixed case, it would have to know which node it was on the path…)

 

Still figuring out which PMode applies to a given message needs some information on the wire to be consulted. I am still waiting for information on how this is supposed to work.

 

I assume also that both Sync and Pull will need a waitlist{all} to work

 

But even for a pure ebMS MEP of Push, the appendix E table notes that the backchannel is in use for Case 1 through 6. This makes me wonder about whether any MEP binding other than the One-Way/Push pathlength{ThreeOrMore} waitlist{all} can be supported unless we use ws-addressing to control information return flow. I hope this represents some of the questions I raised in our first session on this MEP and maybe a little of the concerns and reasoning that underlies these questions.

 

 

 

MEP: One-way / Push	Case 1	Case 2	Case 3	Case 4	Case 5	Case 6
Reliability.AtLeastOnce.Contract:	False	False	True	True	True	True
Reliability.AtLeastOnce.ReplyPattern	N/A	N/A	Response	Response	Callback	Callback
ErrorHandling.Report.AsResponse	False	True	False	True	False	True
HTTP Request (pushed message)	UserMessage	UserMessage	UserMessage + RM header (with AckRequested element if WS-Reliability)	UserMessage + RM header (see case 3)	UserMessage + RM header (see case 3)	UserMessage + RM header (see case 3)
HTTP Response	No SOAP envelope except if SOAP Fault.[a]	No SOAP envelope except if ebMS error on the UserMessage: an ebMS header for Error SignalMessage.[a],[b]	SOAP header with RM Ack[a],[c]	SOAP header with RM Ack[c], plus an ebMS header for Error SignalMessage, if any.[a],[b]	Same as Case 1	Same as Case 2

 

[a]A SOAP Fault may be included if the request was in error. This Fault is combined with an ebMS error message (eb:Messaging/eb:SignalMessage/eb:Error) unless it is generated by the Security or Reliability module.

[b]The ebMS error message may or may not be combined with a SOAP Fault, depending on its severity.

[c]Acks may be grouped so that an Ack is not sent back for every UserMessage.

 

 

 

 

 

 

 

 

 

 

 

 

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