OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: Multi-hop reliable messaging

we made some major progress on allowing the ebxml mhs to connect to workflow
in the meeting last week. most people don't seem to understand the
differences between workflow and routing at this time. this will be resolved
over the next few months. it is interesting that the ack delivered from the
mhs to show it was received by the mhs is like and email delivery receipt
and that the ack you are discussing showing the workflow system or another
application is exactly like the email (rfc822) read receipt. we implemented
a tenitive delivery receipt last week. it looks to me that we will have to
implement a read receipt type ack later. i have contacted the workflow
coalition about tying their stuff into our stuff. positive first response. i
will be working that as we go forward.... best regards, rik

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Thursday, November 02, 2000 6:19 PM
To: MKudela@uc-council.org; Burdett, David
Cc: ebxml-transport@lists.ebxml.org; mona@mail2.commerceone.com
Subject: RE: Multi-hop reliable messaging


See comments below.


-----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

Melanie Kudela
EC Technical Manager
UCC, Inc.
Princeton Pike Corporate Center
1009 Lenox Dr., Suite 202
Lawrenceville, NJ 08648, USA

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC