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


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?

Message (with error)(AckRequested=S/U)---------------------->
<---------------ErrorMessage (Includes Acknowledgment element)
Acknowledgement message (without Acknowledgement element) -------->

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.


"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
-----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

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

Powered by eList eXpress LLC