See
comments inline
David
-----Original Message-----
From: Arvola Chan
[mailto:]
Sent: Monday, July 30, 2001 2:08
PM
To: Burdett, David; ebXML Msg
Cc:
Subject: Re: T2: ackRequested attribute in Via
element
David:
Please see my comments inline.
Thanks,
-Arvola
----- Original Message -----
From:
Burdett, David
To: 'Arvola Chan' ; ebXML Msg
Cc:
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?
[David
B] I think there are several use cases which are all equally
valid:
1. The MSH looks up the
CPA
2. The Application tells the MSH to send the
data reliably
3. The MSH infers what to do by looking at the
service and action (or other data) in the header and looking up what to do
in some type of rules
database.
Once the CPA knows what to do it should set the
QualityOfService 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?
[David B] As currently
specified I think that you have to use the Via element if you are doing
reliable messaging as you need ackRequest to be set even if you are
doing a single hop. The reason that ackRequested is in the Via element is
because the need for ackRequested is removed if you are doing multiple
hops and one of the hops is using a proprietary "reliable messaging
protocol" e.g IBM MQ Series. This really indicates thatr the Via element is
wrongly named IMO. What are your thoughts about changing it
...
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?
[David B] I think that what you say is
correct.
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.
[David B] Any
volunteers?
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?
[David
B] Yes if the messages are being sent
synchronously.
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.
[David B] Perhaps. Even if
he did not then the rules say that any errors in an error message are
not responded to so it would not make much
difference.
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.
[David B] In example 1, suppose the ErrorMessage was
lost, then, as the original message was sent reliably, the sender would
resend it which would cause the Error Message to be resent. This means that
the ErrorMessage does not need to be sent reliably as the sender of the
Error Message knows that they will receive the original message again if the
error message is lost
In example 2, the Error Message
needs to be sent reliably as the sender wants to make sure that it was
received. If it is not sent reliably then there will be no
acknowledgement.
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
-----Original Message-----
From: Arvola Chan
[mailto:]
Sent: Friday, July 27, 2001 7:40
PM
To: ebXML Msg
Cc:
Subject: T2: ackRequested attribute in Via
element
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
