RE: Multi-hop reliable messaging

["Burdett, David" <david.burdett@commerceone.com>]

Melanie

See comments below.

DAvid

-----Original Message-----
From: MKudela@uc-council.org [mailto:MKudela@uc-council.org]
Sent: Thursday, November 02, 2000 11:17 AM
To: Burdett, David
Cc: ebxml-transport@lists.ebxml.org; mona
Subject: RE: Multi-hop reliable messaging



Thanks for the clarifications. I also see that some of these issues are
addressed in the thread RE: ebxml trp mhs spec and workflow as well and I
probably should have brought them up there.

From my experience working with the EAN.UCC payload which has no msg
routing information in it,   the hub (read, comm server) is  "wrapped"
around the application (let's call it workflow)  that picks up from the hub
and sends the message somewhere to get processed. Because the hub and
workflow  are usually separate apps, from different vendors, and on
different servers,  why isn't it part of the process to acknowledge a
successful message delivery from hub to workflow? 
##I see no reason why this can't be done by TRP provided **the link betwee
the hub/comm server and the application/workflow server both follow the
reliable messaging spec**. However now you are getting "inside" the client
site, when TRP has a focus of reliable messaging **between** TRPs. I also
don't think we can mandate how connections between servers must necessarily
be part of TRP.##


If that is not part of
the multihop scenario it becomes the weak link in the chain. Why should it
not be part of T&R to define the "interface" to workflow, and then business
team can takeover and define the business scenarios. I just don't agree the
hub and workflow boundary are black-and-white but as grey and soft and
fuzzy.



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:
MKudela@uc-council.org                
                    ceone.com>                   cc:
ebxml-transport@lists.ebxml.org       
                                                 Subject:     RE: Multi-hop
reliable messaging 
                    11/02/00 12:45 PM

 

 




Melanie

See answers in-line. I have included some of your comments in a revised
version

David

-----Original Message-----
From: MKudela@uc-council.org [mailto:MKudela@uc-council.org]
Sent: Thursday, November 02, 2000 6:33 AM
To: Burdett, David
Cc: ebxml-transport@lists.ebxml.org
Subject: Re: Multi-hop reliable messaging


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.
##A number of points here:
1. I deliberately excluded identifying separately the various firewalls,
DMZ's etc through which the message goes as none of these would actually
"look" at the ebXML header or process it in anyway. This is just like
sending the message over the Internet. In this case the message will pass
through many servers that won't "touch it" and therefore, from an ebXML
reliable messaging point of view, can be ignored. - I'll add a comment to
the Use Cases.
2. You make a valid point about applications that access the header, for
some reason. The issue, from an ebXML perspective is how far back into, say
a Party's ERP system can ebXML go. The analogy I tend to use is that the
all
you need to do to prove delivery is to get a receipt from the mail room -
this is the equivalent of the Message Service Handler in TRP. On the other
hand if ebXML was used internally at a site between applications (not that
I'm suggesting this) then the final destination could actually be the
application that actually processes the payload of the message. In short
though, multip-hop reliable messaging using TRP can only really work, where
all the hops are either using TRP directly or using some other protocol
that
provides equivalent functionality.##


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.
##I agree. Each hop may need its own routing tables.##

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.
##This is true, but once an application looks and processes the payload,
then I would argue that the message has, as far as TRP reliable messaging
is
concerned, reached its "final" destination. What you describe is beginning
to verge on "workflow" where you want to specify the sequence (set?) of
processes that should handle a message. This requirement, although valid,
is
outside the scope of TRP, but inside the scope of the ebXML Business
Process
Modelling team. IMO workflow can layered on top of basic reliable messaging
protocol.##

The response will not always follow the same route as the original message.
##This is very true. If a response is being sent separately - for example
in
the use cases for the "final" acknowledgement or a "delivery failure", then
it does not need to follow the same route. I'll add a use case for this.

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?
## I think I've answered this earlier. A hub is anything that looks at or
processes the ebXML header and uses the information to forward the
message.##
 does the hub know only of the next hop
or all the possible routes?
## It MUST know the next hop. IMO opinion knowing all possible (or at least
some alternative) routes is an implementation decision.##

if there are no routing tables then do all the
sender ids get sent in the message headers?
##In my opinion no as adding in the complete route significantly adds to
the
complexity. It would be like us telling the post office that they must send
the message in a particular way. As an example, what do you do if you are
given one route by the original sender, and for some reason that route is
not available, should the original sender include alternative routes as
well, or do they say, "give up" if you can't use this route or should the
MSH find another route itself?##

or perhaps the sender ids get
added on at each hop?
##I think this makes sense. Each hub needs to be able to work out where to
next send the message.##
or do we need a combination of both?
##I don't think so as it adds to the complexity.##

does the final
user application see the headers if the message or part of it needs to be
resent?
##This is really part of what we have been calling the "service interface"
spec that we are yet to produce. My view is that this information should be
available, but we should not specify this in the "base" Messaging Service
Spec as this is focusing on the "wire protocol".##

If not, how does it communicate the resend of a message (versus the
resend of one payload inside the envelope) to the sender?
##As said above, I think it should be done but this should be specified in
the service interface spec.##

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.
##Hope my answers help.##

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