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

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

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?document
_id=28269):

- MEP Binding
- Protocol (though we could profile this to always be HTTP 1.1)
- Protocol.Address
- Transport security protocol (none, SSL/TLS, version)
- Transport security protocol client certificate
- Transport security protocol server certificate
- MPC (see below [1])
- Maxsize
- Report.SenderError.AddressTo
- Report.ReceiverErrorsTo
- ErrorHandling.Report.AsResponse 
- Report.ProcessErrorNotifyConsumer
- Report.ProcessErrorNotifyProducer
- Report.ProcessErrorDeliveryFailuresNotifyProducer
- AtLeastOnce.ReplyPattern 
- Transport retries (see below [2])
- "Streaming" [3]

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. 

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

Pim