Be careful. If the goal is to reliably deliver a message from the From
party to a To party through one or more intermediaries, the only ACK that
matters is the one from the To party's MSH when that MSH has placed the
message in a persistent store. ACKs from the intermediaries, when they
receive the message, do not accomplish anything useful because the message
may be lost at or upstream of any intermediary.
Regards,
Marty
*************************************************************************************
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
*************************************************************************************
David Fischer <> on 08/07/2001 01:01:45 AM
To: "Burdett, David" <>, "'Arvola Chan'"
<>, ebXML Msg <>
cc:
Subject: RE: T2: ackRequested attribute in Via element
David,
In your example about an intermediate hop being different, how would the
AckRequested be passed through? Each intermediary must recreate the Via
for the next hop based upon values it receives. Let's say we have 6 hops
and the middle hop (3-4) is MQseries so it doesn't need AckRequested. Hop
1 sends to Hop 2 with the Via element including AckRequested=signed
(sign/unsigned doesn't matter here) and actor=next. Hop 2 consumes the
Via header and recreates a Via with AckRequested=signed and actor=next
because that's what came to it and sends to Hop 3. Hop 3 creates a Via
with AckRequested=none and actor=next because its hop doesn't need it and
sends to Hop 4. How does Hop 4 know to reset AckRequested=signed before
it sends to Hop 5? Am I missing something here?
I don't think this works. I understand the desire to have things change
on a per hop basis but I don't think it works the way we have it now. We
always have to leave AckRequested to the same value even if we don't need
it for some hop -- so, it doesn't need to go in Via. This goes back to
the question of what is the difference between an Ack and a
DeliveryReceipt for single-hop? IMO the answer is Via should not be passed
to the end and DeliveryReceipt should be the end-to-end Ack.
Why do we need AckRequested at all? All we have to do is have
intermediate hops send back an Ack to the previous hop based on the value
of DeliveryReceiptRequested.
PROPOSAL
1. Get rid of AckRequested.
2. Intermediate hop sends an Ack to the previous hop based upon the value
of DeliveryReceiptRequested unless overridden by a local CPA.
3. End node sends a DeliveryReceipt, which acts the same as an Ack, to
the sender based upon the value of DeliveryReceiptRequested.
On the problem with unlimited messages, IMO the observation is correct.
We should not allow an Ack to an Error. We should also not allow an Ack
to an Ack or an Error to an Error. We should still allow an Error to an
Ack(we can only allow one or the other).
David.
-----Original Message-----
From: Burdett, David [mailto:]
Sent: Monday, August 06, 2001 8:59 PM
To: 'Arvola Chan'; ebXML Msg
Cc:
Subject: RE: T2: ackRequested attribute in Via element
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
