OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: T2: ackRequested attribute in Via element

Please see my comments inline.
----- Original Message -----
Sent: Monday, July 30, 2001 12:11 PM
Subject: RE: T2: ackRequested attribute in Via element

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
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.
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.
-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Friday, July 27, 2001 7:40 PM
To: ebXML Msg
Cc: mwang@tibco.com
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?

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC