Re: T2: ackRequested attribute in Via element

David:

 

Sorry for the delayed response. My comments are inline in 
green.

 

-Arvola

  
-----Original Message-----
From: 
  Burdett, David <>
To: 
  'Arvola Chan' <>; ebXML Msg <>
Cc: 
   <>
Date: Monday, 
  August 06, 2001 6:59 PM
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 see. The Message Service Interface will 
      have to be designed to support the different use cases. Perhaps you mean 
      "Once the MSH knows" in your above sentence.

      
 

      
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 way I read 
      from the current spec, the sender only needs to set ackRequested 
      if it is expecting to get back an Acknowledgement message that 
      actually contains the Acknowledgement element (which carries non 
      repudiation information). Otherwise, it seems rather redundant to require 
      both deliverySemantics set to OnceAndOnlyOnce and ackRequested set to 
      something other than None in order to elicit Reliable Messaging 
      behavior.

      
 

      
In general, I am 
      of the opinion that the Via element should be used only when an 
      intermediary is involved. Therefore, I don't think that the ackRequested 
      and syncReply attributes belong only in the Via element. Perhaps the 
      QualityOfServiceInfo element is a more appropriate home for these. Why 
      should ackRequested be different from hop to hop 
      anyway?

      
 

      
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 will be happy to contribute to an effort 
      headed up by some experienced veteran of the MSG spec.

      
 

      
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