RE: [ebxml-msg] Groups - Multi-hop Section Draft 0.5 (ebMS3-Multihop V05.doc) uploaded

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

Hello Jacques,

Unfortunately I can't make tonight's call. A couple of comments:

- I was only referring to Pmodes in a loose sense of "bunch of configuration
parameters relevant to building or sending/forwarding a message".   Due to
assumptions of transparency and end-to-end security and reliability our
intermediaries need less configuration parameters than regular endpoints, by
intention, but still some.

- Transport security details (SSL) are part of any intermediary
configuration. Whether or not they are out of scope for ebMS is debatable.
In some products/deployments transport security is not handled not by the
ebMS MSH but in others it is. An option to configure transport security has
been part of ebXML CPP/CPA OASIS standard ("Transport" element) since the
beginning.  I think the absence of transport security Pmode parameters in
ebMS 3.0 Core is an oversight.

- MEP Binding is a configuration parameter for all intermediaries, not just
for the last. The next MSH node may be an endpoint for some messages, or yet
another intermediary for others (see last assumption in 1.3.1).  So any
intermediary should be able to push or be pulled from based on conditions.  

- We discussed some contrained support for synchronous, and there is some
text on synchronous streaming already.  This could be part of the routing
function: configuration linked to message patterns in rules, of the
intermediaries and the endpoints that connect to them.

Pim


-----Original Message-----
From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com] 
Sent: 04 September 2008 21:13
To: Pim van der Eijk
Cc: ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Groups - Multi-hop Section Draft 0.5
(ebMS3-Multihop V05.doc) uploaded

Pim:

Looking again at this message, for the next iteration of the multihop
draft: comemnts <JD> inline.

Overall my opinion: 
- yes the routing function needs be enhanced but not much,
- some behavior like intermediary error handling should rely on in-message
routing info
- the bottom line, is that node in the I-Cloud do not have to be configured
based on Pmodes, which I believe we have always tried to avoid. 
- So three forms of config will likely apply to an eb Intermediary:
(a) HTTP-level processing (out of scope), e.g. transport retries...
(b) general eb message processing behavior, such as streaming, maxsize.
Should be common to all messages for the intermediary (not Pmode-based).
(c) Routing function. Might be derived from Pmode info, does not have to (an
implementation decision)

Regards,
-J 

-----Original Message-----
From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
Sent: Saturday, June 28, 2008 7:34 AM
To: ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Groups - Multi-hop Section Draft 0.5
(ebMS3-Multihop V05.doc) uploaded



Jacques,

Lines 110-114, "PModes governing message exchanges should only be known
from Endpoint MSHs. The I-Cloud should not have to be aware of PModes,
with an
exception: when an Intermediary has to support message pulling, it must
know which ones of the messages it receives must be pushed and which
ones must be pulled. This requires partial knowledge of PModes
associated with message pulling."

An intermediary needs to know a much larger subset of "nextMSH"
configuration parameters. Here is a list (mostly from
http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/document.php?docu
ment
_id=28269):

- MEP Binding
<JD> if we assume our multi-hop paths are all push (and sometime last
pull) then only the last intermediary needs be configured I believe.
That decision could be seen as part of the routing function.

- Protocol (though we could profile this to always be HTTP 1.1)
- Protocol.Address
<JD> aren't these part of the routing function?

- Transport security protocol (none, SSL/TLS, version)
- Transport security protocol client certificate
- Transport security protocol server certificate
<JD> I believe these are below ebMS level?

- MPC (see below [1])
<JD> the "MPC remapping" case I think is only to be considered with the
"subchannel" feature, because the message header (including @mpc) is not
supposed to change during routing. In that case again, that can be
handled by the extension of the routing function to deal with Pull
cases, and will so far concern only the last hop.

 In general, 

- Maxsize
- Report.SenderError.AddressTo
- Report.ReceiverErrorsTo
- ErrorHandling.Report.AsResponse
- Report.ProcessErrorNotifyConsumer
- Report.ProcessErrorNotifyProducer
- Report.ProcessErrorDeliveryFailuresNotifyProducer
- AtLeastOnce.ReplyPattern
- Transport retries (see below [2])
- "Streaming" [3]

<JD> I see 2 main aspects in the above: 
(a) message processing parameters such as streaming and maxsize. Here
indeed that should be ebMS configuration. But does that have to be Pmode
dependent? I could see a general Intermediary behavior applying
similarly to all messages.
(b) ebMS Error reporting. I would be strongly inclined to rely on
message header data: ref parameters (containing enough about the reverse
routing) or wsa:FaultTo.
As for Transport retries, I see this also as a blanket configuration of
the Intermediary, Pmode-independent.


Notes:

[1] MPC:  
This is an intermediary configuration if MPC "remapping" is allowed, see
May
2008 message thread "Multihop and Pull".
http://lists.oasis-open.org/archives/ebxml-msg/200805/msg00013.html

[2] Transport retries:
Some messaging products support not only ebMS retries but also
separately a lower-level HTTP retries.  EbMS retries are business
process related and a contract among From Party and To Party MSH, with
(Retries*RetryInterval) typically hours or even days. HTTP retries are a
generic transport retry mechanism (also usable with AS2) with retry
intervals of seconds or minutes.
It makes sense for ebMS intermediaries to support (and be configurable
for) HTTP retries even if they do not support WS-* related retries, in
particular with store-and-forward intermediaries. This is the case for
one product that supports ebMS 2.0 multihop. 

<JD> I tend to see this as out of scope? (lower level)


[3] "Streaming"
Perhaps "streaming" behaviour should be a configuration parameters. I'll
comment later in a separate message for easier tracking.

Related comment for lines 163-167, 

"a routing rule can be construed as a pair: (Boolean expression over the
routing input, URL) where [the] URL identifies the next MSH."

This only covers the case where the forwarding is a Push (to this next
URL), not when the next node retrieves the message from the intermediary
a Pull request.  It is also incomplete:  A routing rule should map this
expression to settings for this larger set of "nextMSH" parameters
mentioned above.

<JD> The routing function should indeed cover the pull option, which may
involve assignment to a "subchannel". But besides this, I think tehre is
little more it should do, based on previous comments on the above
nextMSH parameters.


Pim



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php