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