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

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

<JD> Unless the ultimate MSH URL is always explicit on the wire, an intermediary would need config data at least for doing the routing. It will also need config data for the wait / no behavior, as I do not see this info on the wire, unless we decide to (i) use wsa header ReplyTo, (ii) to give it a wait / no semantics at intermediary level. The problem here, would be that this does not work for non-reliable one-ways... (ReplyTo not supposed to be used in such case)

</JD>

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.

<JD> also, each segment could have its own push or pull mode. E.g. Sender pushes to Intermediary, and Receiver pulls from Intermediary. Another question is: is the explicit identification of Intermediaries a major aspect of an MEP binding, or could an MEP binding concentrate mostly on the Sender and Receiver behaviors, and leave the use of intermediaries to a more dynamic decision process (e.g. routing decided more dynamically) and routing info that is separately determined from MEPs? </JD>

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}

<JD> right - but not sure how pathlength wouldbe used.</JD>

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.

<JD> sounds fair to me.</JD>

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.

<JD> the problem - at least for the routing of ebMS messages - does not seem to be much different for an intermediary and for a Sender MSH: a P-mode is resolved for each message based on [non-encrypted] header data (could be the explicit @pmode, or just @mpc). In practice, I'd suspect P-modes will not be used directly by intermediaries, but rather compiled in routing rules or so. </JD>

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

<JD> Not necessarily Pull: a "decoupled Pull" as in 2nd scenario on slide #2 could work with waitlist(none) all the way, relying on the same MPC all along with itnermediary storage. That would be one of the roles of the Intermdiary to be able to use an MPC as a queue, filled by an MSH and pulled by abother. </JD>

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.

<JD> these cases only make sense with waitlist(all), except for cases 1 and 5, which should work with waitlist(none), in which case the only kind of SOAP Fault the Sender would get on the back channel, is in case the Intermediary cannot process the ebMS header (or cannot process an RM or Security header, if the Intermediary is the RM endpoint). Other signals (RM. Errors) would need be routed by other means.

NOTE: besides waitlist(all) and waitlist(none), I see some advantage in having something like waitlist(last), in case we don't want to keep connections open except for last segment, and in case we don't want to constrain in any way the ultimate receiver, e.g. do not want him to have to know the Intermediary address. COmmunication over the last segment could use any of the cases in table below - these P-mode parameters are for the ultimate receiver behavior. This can be seen as a relaxed waitlist(none).</JD>

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

ebxml-msg message