RE: [ebxml-msg] Regrets and a remark on: [ebxml-msg] RE: ebms - Multi-hop Signal Routing (ebMS-Signal-Routing.doc) uploaded

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

Pim:

Thanks for detailed review. Useful coments.

inline <JD>

-----Original Message-----
From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
Sent: Wednesday, March 12, 2008 2:27 AM
To: Durand, Jacques R.; 'Moberg Dale'; 'David RR Webber (XML)'
Cc: ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Regrets and a remark on: [ebxml-msg] RE: ebms - Multi-hop Signal Routing (ebMS-Signal-Routing.doc) uploaded


Hello,

Thanks for a detailed proposal. A couple of comments:

Line 91-99 and below:  when the TC considered (1) and (2) I was not a member, but I indicated via TC comment that this would cause routing issues in multi-hop. The response at the time was that multi hop was not in scope.
Now it is, and now we see why it is an issue .. 

Line 91-100. I think adding more business header information in Signals is a serious option, especially if it results in intermediaries having to implement only one routing mechanism instead of two separate ones. 

<JD> In  both cases the routing mechanism is the same: to use header content (whether from eb header or from wsa header) and have entries for possible values in the routing table of each intermediary that tell where to forward the message. Since there may be several possible such entries that match a message (e.g. several header fields in eb header), enforce a precedence order.</JD>

Those elements could be optional, and a single-hop profile could constrain them to not be used or to ignore them if used. It could then qualify as an erratum.
We've already seen that achieving end-to-end security may require different behaviour from endpoints, and there certainly is no eb:RoutingElements element in the v3.0 Core XSD, so we will need to publish an updated schema anyway.

<JD> yes, schema change for Option 1. But the key point is that endpoint MSHs that are today conforming to Core V3, need not support this to enter the multihop game, unlike if we require insertion of business headers by the endpoints themselves. </JD>

Like your option 1, business header routing would require a "reverse routing" function. For ebMS 2.0 this reverse routing is limited to reversing eb:From and eb:To. An intermediary that forwards user messages with <From, To, {other parameters like Service..}> should be configured to reverse route Signal messages <To, From, {some other parameter values}>.  For most practical use cases (B2B, G2G, SOA), that seems quite acceptable (see separate message).

<JD> In some cases it is not acceptable... (see my multihop use case) and inthese cases it is much more manageable to add the Gateway URL as an entry of the general routing function - since the URL of the initial Gateway is known. That part of the routing function is very stable - would never change as long as the I-Cloud topology doesnot change. Immune to adding new endpoints MSHs.</JD>

Line 188-192:  I see why you propose that the final MSH sends any Signals synchronously.  Assuming we want the configuration for MSH B to be the same (or as similar as possible) whether or not intermediaries are present, the result is that an MSH A will get Signals synchronously when sending directly (not via intermediary) and asynchronously when connecting indirectly (via an intermediary).  OK, but a maximally transparent approach (in my interpretation of "transparent") would allow an MSH to only change the next hop URL and possibly TLS security to send via an intermediary instead of directly.

<JD> then you would preclude the reasonable configuration allowed by multihop, where response Signals are sent back synchronously from the ultimate destination, but for the sake of not keeping connections open too long, the initial sender will expect them asynchronously. All we say, is that this very realistic approach (not possible in peer-to-peer) should be allowed in multihop. We can easily add aPMode parameter that says: "I prefer to get these signals synchronously, but in case of multihop I will also accept asynchronous". The endpoint MSH still does not have to know upfront who it is dealing with...</JD>

Line 255-368:  this proposal has two major advantages: minimal configuration for Router intermediaries, and it can even support dynamic routing (as
opposed to static routing tables at intermediaries).   But it seems to break
a clean distribution of routing at various levels:
Level 1:  HTTP clients and servers, routing based on next hop URLs.
Level 2:  SOAP nodes (ebMS and non-ebMS), routing based on WS-A headers. 
Level 3:  ebMS nodes, routing based on ebMS headers.
For Signal messages, this proposal is somehow "in between" levels 2 and 3.

<JD> your model works cleanly only if an ebMS node is NOT a wsa node. And in Option 2, indeed an ebMS node is also a wsa node. Where we have simply to be more specific, is how to deal with that case. I think it can be simply dealt with by stating that a wsa node takes precedence over the ebMS node: when both routing options are present, wsa takes over. That seems reasonable because a routing where the destination URL (here the initial Gateway) is explicit, is safer and easier than a routing where it is determined by the routing function along the way.</JD>


Line 359-363:  This is about using a wsa IRI not used as next hop URL but as a key for a lookup to find a next WSA hop.  Is this standard WS-A
functionality?    Isn't the ultimate consequence of this that all
intermediaries must know about each other and having intermediary-to-intermediary routing tables?

<JD> maybe that text wasn't explicit enough. The wsa:To always contains the URL of the final Gateway to which the Signal (or any message...) must be sent. Under simple conditions, this is sufficient to directly route the message to this Gateway (using a routing mechanism called the Internet ;-) But there may be cases where Gateways refuse to get incoming requests from everybody and accept input only from a few predefined nodes - hence the need to use this URL just as another entry of the I-Cloud routing function. So the decision what to do with the wsa:To URL, could be simply based on: Is it an entry of teh routing table that leads to another URL? if yes use that other URL. If no (i.e. there is no "wsaTo" entry for this URL value) then you can directly send the message to this URL. That would be the "default" option.</JD>

Reading this section somehow made me think of the "Via" and message trace elements in version 1.0 ..

Pim