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: RE: [ebxml-msg] Groups - Multi-hop Section Draft 0.5 (ebMS3-Multihop V05.doc) uploaded


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


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


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

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


[1] MPC:  
This is an intermediary configuration if MPC "remapping" is allowed, see
2008 message thread "Multihop and Pull".

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


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

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