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
|