[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Need to change Service and Action for Errors,Delivery Receipts etc.
David:
I am of the opinion that the DeliveryReceipt element should be
used by the ToParty MSH to inform the FromParty MSH that a reliable message has
been received. Therefore, it is moot as to which application needs to be
notified when a standalone message is received containing a single
DeliveryReceipt element (because it is really intended for the sending MSH). It
is the non-arrival of a DeliveryReceipt that requries the MSH to notify the
application. In this case, it must rely on persistent information to determine
the application service that must be notified. This is one point that the spec
needs to clarify.
By the way, I find the reliable messaging section in 0.93
version of the TRP spec
much more logical than the one in the 1.0 spec. At least, it
explicitly covers the scenario of multi-hop reliable messaging and talks about
the possibility of reliable messaging with or without intermediary acks. In
particular, it distinguishes two types of acknowledgements, one used by
intermediary MSHs to the previous hop MSH and the other used by the ToParty MSH
to the FromParty MSH. I am curious as to how RM ends up in the current broken
state in the 1.0 spec.
I think end to end acknowledgement is always needed to support
reliable messaging, so it is unnecessary to explicitly set
deliveryReceiptRequested to true, it should always be implied by
deliverySemantics of OnceAndOnlyOnce. On the other hand, if intermediary acks
are optional, then ackRequested needs to be an explicit attribute at the QOS
level and it should apply to all intermediaries. When an intermediary uses non
ebXML reliable messaging methods that still guarantees delivery, then
ackRequested simply does not apply to such intermediaries.
I agree with you that the problem is more serious for error
messages. In the case of the RosettaNet message header, both the from service
and the to service are included. Therefore, in case of errors, it is easy to
figure out which service at the sender should be notified. I am in favor of your
proposal to add the from service to the ebXML message header.
Thanks,
-Arvola
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC