----- Original Message -----
Sent: Monday, July 30, 2001 12:11
PM
Subject: RE: T2: ackRequested attribute
in Via element
Arvola
Setting the ackRequested to Signed or Unsigned is a
decision that the designer (and/or implementer) of the business process makes
when they design or build a business process collaboration or business process
transaction. Factors that need to be considere include
(IMO):
- The
natuure of the business process/transaction - e.g. payments probably need to
be secure
- The
requirements of the individual trading partners
This
brings up a Messaging Service Interface question. Does the application (i.e.,
whatever software is above the MSI layer) instruct the MSH to send a message
reliably, and/or to specify the use of MSH level acknowledgement, or is it the
responsibility of the MSH to infer from the CPA and such message header
elements as Service, Action, CPAId, etc. the quality of service that should be
used for sending a message, and then set the QualityOfServiceInfo and Via
elements accordingly?
I
have always thought that the ackRequested attribute should be set if reliable
messaging is being used. Is it allowable to set deliverySemantics to
OnceAndOnlyOnce and to either omit the Via element or to include a Via element
but set ackRequested to None?
The
concept of an Acknowledgement message to support reliable messaging seems
muddled with the concept of the Acknowledgement element which is primarily
used to provide non-repudiation of receipt. My colleagues at TIBCO have
pointed out to me that it seems possible to send an Acknowledgement message
that does not carry an Acknowledgement element, and that only the
RefToMessageId is required. (See lines 1816 and 1817 in Section
10.3.3.) Can you please confirm that this indeed is the
case?
I
think what would be really useful is to have a guide that describes how to
design a business process/transaction using ebXML Messaging. Do you agree? If
so hould it be in the 1.1 spec or something separate.
Either way is fine with me, as long as the guide is
available around the time the 1.1 spec is published.
I
think that if an error is dicovered then including the ackRequested set to
true on the error message runs the risk of a never ending series of messages.
The only use cases to consider are where a message is being sent reliably in
which case ...
My
question was whether the error message should be sent reliably. I was under
the impression that the CPA determines the role played by the receiver and the
delivery channel that it will use for receiving messages. If the delivery
channel uses a doc exchange that calls for the use of reliable messaging, then
shouldn't the error message be sent reliably?
- If
the message that was in error has ackRequested set to Signed/Unsigned and
the error message sent in return is lost, then the sender of the original
message will resend it which will cause the error message to be resent - see
example 1 below
- If
the message that was in error has ackRequested set to None (e.g. it is a
synchronous resposne) then sending the error message with Ack Requested set
to Signed/Unsigned makes sense otherwise the sender of the error message
will not know if the message was delivered - see example 2
below
EXAMPLE 1
Message (with
error)(AckRequested=S/U)---------------------->
<---------------ErrorMessage (Includes
Acknowledgment element)
If
the message is in error, I doubt if the responder is obligated to include an
Acknowledgement element in the error message, even if AckRequested has been
asked for.
EXAMPLE 2
Message (no
errors)(AckRequested=S/U)------------------------>
<-------Message (with error) (Includes
Acknowledgment element)
Error Message
(AckRequested=S/U)----------------------------->
<---------------Message (Includes Acknowledgment
element only)
I still don't
see why in example 1 the sender of the error message does not set AckRequested
to S/U while in example 2 the sender of the error message sets AckRequested to
S/U. Perhaps the design guide you suggested earlier should clearly define the
error scenarios when reliable messaging and/or AckRequested are to be
used.
A general rule
(it's somewhere in the spec but I can't immediately find where) says that if
you find an error in an error message then you don't respond with another
error message and sort out the problem by some other
means.
Regards
David
Section 8.7 does not clearly indicate the
circumstances under which the ackRequested attribute should be set (to
Signed or Unsigned). Is this governed by the ReliableMessaging and
NonRepudiation element for the DocExchange associated with the
DeliveryChannel that is being used?
In particular, when an error is encountered in
processing a message, what should be the strategy for setting the
ackRequested attribute in the error message? In other words, under what
circumstances, if any, are error messages to be sent reliably?
Thanks,
-Arvola