[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 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC