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

Pim: 

Thanks for detailed review. Useful coments.

inline <JD>

-----Original 
Message-----
From: Pim van der Eijk [mailto:]
Sent: 
Wednesday, March 12, 2008 2:27 AM
To: Durand, Jacques R.; 'Moberg Dale'; 
'David RR Webber (XML)'
Cc: 
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