RE: Relationship between Acknowledgement, DeliveryReceipt,and BP SS Business Signals

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

Arvola

 

I think you have two types of software at the recipient of a message:

• business process/transaction UNAWARE - this is typically the MSH which needs to know which application to dispatch a message to but nothing else, and
• business process/transaction AWARE - this is tupically the application that understands the message and knows how to process it.

I think it can be useful to have delivery "receipts" from both as:

• there can be delays between the MSH receiving a message and its hand-off to the application
• once an application receives a message, then there can be delays before the message is processed.
• you could have a legacy application that is unable to produce it's own delivery receipt and therefore the MSH delivery receipt is a useful proxy.

There are probably more.

 

I agree though that the inconsistencies need to be fixed ... sounds like we need a joint CPPA & MSG meeting ...

 

David

-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Sunday, July 22, 2001 6:54 PM
To: ebxml-cppa@lists.oasis-open.org; ebXML Msg
Subject: Relationship between Acknowledgement, DeliveryReceipt, and BPSS Business Signals

According to the Messaging Service spec, the Acknowledgement element is an optional element that is used by one MHS to indicate to another MHS that it has received a message (to support the implementation of reliable messaging). The DeliveryReceipt element is defined as an optional element that is used by the To Party who received a message to let the From Party who sent the original message know that the message was received.

 

The BPSS spec, on the other hand, defines Business Signals as application level documents that 'signal' the current state of the business transaction. "These business signals have specific business purpose and are separate from lower protocol and transport signals." Business signals include receipt acknowledgements, acceptance acknowledgements and exceptions. The structure of signal messages is not application specific and is defined in Section 9 of the BPSS spec.

 

In Section 7.5.11.1 of the CPPA spec, it is pointed out that the syncReplyMode attribute can take on the possible values: signalsOnly, responseOnly, signalsAndResponse, and none. Some how, the CPPA spec is not aware of the Acknowledgment element or the DeliveryReceipt element defined by the Messaging Service. If syncReplyMode is set to signalsOnly, responseOnly, or signalsAndResponse, isn't an Acknowledgement at the MHS level also required to be returned synchronously? In fact, the meaning of responseOnly is is not clearly defined. If only the response is to be returned synchronously, how should the MHS level Acknowledgement and the business level receipt acknowledgement be returned? Should the MHS level Acknowledgement be returned synchronously and the business level receipt acknowledgement be simply omitted?

 

Both the DeliveryReceipt element and the Receipt Acknowledgement signal message supports non repudiation of receipt. Without the clear definition of a Message Service Interface, it is very unclear under what circumstances a To Party will make use of the DeliveryReceipt element to signal receipt of a message. Why isn't this subsumed by the Receipt Acknowledgement signal message?

 

-Arvola

 

Arvola Chan (arvola@tibco.com)
TIBCO Software (on loan to RosettaNet)
+1-650-846-5046 (US-Pacific)