[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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]