David,
Take you example further by taking 'deliverySemantics=OnceAndOnlyOnce'
for both examples, then should the Initiator finally respond with a plain
acknowledgement message to the Responder?
EXAMPLE 1
Message (with
error)(AckRequested=S/U)---------------------->
<---------------ErrorMessage (Includes Acknowledgment element)
Acknowledgement message (without Acknowledgement
element) -------->
EXAMPLE 2
Message (no
errors)(AckRequested=S/U)------------------------>
<-------Message
(with error) (Includes Acknowledgment element)
Error Message
(AckRequested=S/U)----------------------------->
<---------------Message (Includes Acknowledgment element only)
Acknowledgement message (without Acknowledgement
element) -------->
According to the spec (section 10.3.3 line 1811-1813) that acknowledgement
message MUST be generated when 'deliverySemantics=OnceAndOnlyOnce'.
If
this is the case then as you have also pointed out that one runs the risk
of a never ending series of messages (or unnecessary ack messages).
Now, if the final round of ack messages are not required then I think
it would help by clarifing what kind of messages need to be explicitly
acked when 'deliverySemantics=OnceAndOnlyOnce'. e.g. only Request
and Response messages require acks and errors, signals and acks
themselves do not require to be acknowledged.
-mw
"Burdett, David" wrote:
ArvolaSetting 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
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.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
...
- 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 1Message
(with error)(AckRequested=S/U)----------------------><---------------ErrorMessage (Includes
Acknowledgment element)EXAMPLE 2Message (no
errors)(AckRequested=S/U)------------------------><-------Message (with error) (Includes
Acknowledgment element)Error Message
(AckRequested=S/U)-----------------------------><---------------Message (Includes Acknowledgment
element only)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.RegardsDavid
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