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

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:]
Sent: Sunday, July 22, 2001 6:54 
  PM
To: ; 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 ()
TIBCO Software 
  (on loan to RosettaNet)
+1-650-846-5046 
(US-Pacific)