Re: Multi-hop reliable messaging

[MKudela@uc-council.org]

Dave,

EAN.UCC and GCI are working on a pilot utilizing AS2 standards and an XML
payload. We are finding that there is much opportunity left in the area of
defining workable  routing standards for multi-hop.

If you want to make your scenarios even more useful you should consider
that these messages have to make it through several applications at several
partner sites. For example, a message has to get through a firewall, to a
communication server which might be inside a DMZ. Then it has to get
through the second firewall and get routed to another application inside
the network at which point that application has to examine the header to
decide what needs to be done with it. It may get to an internal application
or it may have to have a new header populated with data to route to yet
another recipient as part of the hop.

At each step there are different security,  routing,  transport and
processing needs.  The routes are not known in advance so a canned routing
table or routing profile  may not be the answer. Also the applications may
check certain elements or attributes of the payload to see if the payload
was not corrupted and if they do not match the expectations the message
gets sent back to the sender - a kind of quality of service check. The
response will not always follow the same route as the original message.


My suggestions for you to enhance your slides would be to consider that
there are a number of applications in the process all of which need to
handle the workflow scenario in an automatic manner. Your slides would be
helpful if they showed us 1.  what is the responsibility of the hub; is the
hub an outside entity or does it sit somewhere inside a company's firewall;
does the hub contain routing tables? does the hub know only of the next hop
or all the possible routes? if there are no routing tables then do all the
sender ids get sent in the message headers? or perhaps the sender ids get
added on at each hop? or do we need a combination of both? does the final
user application see the headers if the message or part of it needs to be
resent? If not, how does it communicate the resend of a message (versus the
resend of one payload inside the envelope) to the sender?

I'm sure you have touched on this in the T&R publications, however, very
explicit scenarios with the above level of detail would be useful to those
of us that are trying to implement this in a real-world environ.

Thanks,


Melanie Kudela
EC Technical Manager
UCC, Inc.
Princeton Pike Corporate Center
1009 Lenox Dr., Suite 202
Lawrenceville, NJ 08648, USA
609-620-4514
mkudela@uc-council.org


                                                                                               
                    "Burdett, David"                                                           
                    <david.burdett@commer        To:     "ebXML Transport (E-mail)"            
                    ceone.com>                   <ebxml-transport@lists.ebxml.org>             
                                                 cc:                                           
                    10/30/00 09:41 PM            Subject:     Multi-hop reliable messaging     
                                                                                               
                                                                                               



Folks

I've been doing some thinking around the use-cases needed to support
multi-hop reliable messaging. The attached PDF file contains a set of Use
Cases, a couple of failure analyses and a summary of what I think the
requirements are that arise as a result.

I'd like to go through these use cases as part of the Reliable messaging
discussions next week at the F2F.

In the mean time comments are really welcome.

David
 <<Multi-Hop Reliable Messaging Requirements.pdf>>

Product Management, CommerceOne
4400 Rosewood Drive 3rd Fl, Bldg 4, Pleasanton, CA 94588, USA
Tel: +1 (925) 520 4422 (also voicemail); Pager: +1 (888) 936 9599
mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com





Melanie Kudela
EC Technical Manager
UCC, Inc.
Princeton Pike Corporate Center
1009 Lenox Dr., Suite 202
Lawrenceville, NJ 08648, USA
609-620-4514
mkudela@uc-council.org