[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: T2: ackRequested attribute in Via element
Comments embedded. Cheers, Chris Martin W Sachs wrote: <snip/> > ----- Original Message ----- > From: Burdett, David > To: 'Arvola Chan' ; ebXML Msg > Cc: mwang@tibco.com > 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. Surprisingly, I agree with David;-) This is one of the aspects that makes it difficult to prescribe a canonical MSI, because there are so many valid ways of achieving the desired result. My take is that the CPA defines the rules to which the parties have agreed by which they will exchange messages. Whether an MSH/MSI uses the CPA directly, or whether the "application" (whatever that means) instructs the MSH (e.g. by constructing the message header itself) is in my mind irrelevant SO LONG AS the rules of engagement as prescribed in the CPA are followed. > > 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 > ... I disagree (whew! ;-) There is adequate information in the message header as well as in the CPA without abusing the Via element which is used exclusively for multi-hop message paths. > > 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 The Acknowledgment element is used EXCLUSIVELY for RM. The DeliveryReceipt is what has been provided for NR and other related business signals. > 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. Oh ohhh... I have to agree again;-) Looks like the cited reference is incorrect. At a minimum, an acknowledgment message (for RM) MUST also include the Acknowledgment header. > > 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. Possibly. As has been done for other specifications, possibly a tutorial or primer is something that the TC should consider. I would shy away from incorporating it in the specification since it would have to be non-normative. No sense in adding to the confusion by adding a treatise on how to construct a business message. > > 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. I'd say that if the messages are being delivered reliably that *application* errors would be delivered reliably as well unless it were specified otherwise. However, for MSH-level errors, this may not be the case. I would think that these would be treated just as acknowledgment messages, e.g. not sent reliably since they would constitute a negative ack. > > 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. Right. > > 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: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? > > Thanks, > -Arvola > > ------------------------------------------------------------------ > To unsubscribe from this elist send a message with the single word > "unsubscribe" in the body to: ebxml-cppa-request@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC