Re: discussion priorities

[Henry Lowe <hlowe@omg.org>]

David,

You've missed some of the TRP discussions some didn't realize 
that what I'm talking about is multi-hop routing where each 
leg has a different transport, e.g., HTTP from a browser to 
a Portal and MQSeries from the Portal to Sear Roebuck.  As 
one of the goals of ebXML is to support SMEs, we assumed that 
many of the SMEs would have nothing but SMTP or HTTP.  Thus, 
a typical scenario would be as above -- browser to Portal 
which forwards on to Sears based on routing information in 
the Header.  The problem is, the current document doesn't 
have this routing info.

For single transport systems, you're right, the network (in 
particular TCP) takes care of this for you (you really don't 
even need the QoS you mention (probably to appease me -- thanks 
for trying :-).

I raised this isssue as either something has to be added to deal 
with it or the routing is somewhere else and I just missed it 
(as I don't have a product riding on ebXML, I must admit that I 
haven't been paying as much attention to these specs as I should 
have been -- I apologize).

Henry
----------------------------------- 
At 12:26 PM 08/23/2000 -0400, David RR Webber wrote:
>Message text written by Henry Lowe
>>For my dime, I'd rather have something like a reference to 
>subheaders containing the routing info when you have a multi-hop.
>That way, the usual simple 1-hop case uses the current "To" 
>field (efficiently) and multi-hops point to an extended route 
>in the message somewhere (no network accesses for routing info 
>so efficiency isn't lost).  Of course, this needs to be extended 
>a bit to cover routing failures and alternative routes.
>
>Of course, there may be a better scheme as I haven't researched 
>this topic or consulted with colleagues who are real routing 
>gurus.  Anyone have a better wheel?
>
>Hey, David, you didn't even need the steel vest :-)
>
>Best regards,
>Henry<
>
>>>>>>>>>>>>>>>>>
>
>Henry - today this routing stuff is handled by the network - it
>figures out the beter route if a leg goes down.
>
>Now that kind of PROFILE QoS is what you need - so I'd 
>know what legs to use - presumably if you want totally
>secure and authenticated this would limit the pathways.
>
>I thkn this is all you REALLY care about - the QoS level,
>so maybe this is the answer - exposing that in the header
>and then letting the network delivery folks do the rest.
>
>If you demand top level QoS that would presumably include
>full tracking so if you need to you could audit where your message
>went.
>
>We could add this QoS stuff to the spec's - which is what I think
>I hear others saying anyway.
>
>DW.