MHonArc v2.5.2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: 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
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)
|
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC