[ebxml-msg] RE: [ebxml-cppa] Comments on reliable messaging in the1.0.5 draft

Arvola, I think I need some clarification.

 

<<comments inline>>

 

David.

  
-----Original Message-----
From: Arvola Chan 
  [mailto:]
Sent: Tuesday, October 16, 2001 12:39 
  PM
To: 
Cc: 
  
Subject: [ebxml-cppa] Comments on 
  reliable messaging in the 1.0.5 draft

  
David:

  
 

  
Here are some inlined comments on section 7.5 
  ebXML Reliable Messaging Protocol.

  
 

  
Regards,

  
-Arvola

  

  7.5.2       
  Receiving Message Behavior
  
If this is an Acknowledgment Message as defined in section 7 
  then:

  
1         
  Look for a message in persistent 
  storage that has a MessageId that is the same as the 
  value of RefToMessageId on the received 
  Message

  
2         
  If a message is found in persistent storage then mark the 
  persisted message as delivered

  
If an AckRequested element is present 
  that is targeted to a role in which the Receiving MSH is acting (see section 
  2.2.10 and 2.2.11) then do the following:

  
1         
  If the message is a duplicate (i.e. there is a MessageId held in persistent storage that was received 
  earlier that contains the same value as the MessageId in the received 
  message)  generate an Acknowledgment Message (see section 7).  
  The Receiving MSH 
  MUST NOT deliver the message to the application interface.

  
      The above paragraph does not 
  clearly explain how duplicate request messages are to be handled. The pointer 
  to section 7 is imprecise. The section 7.5.3 Generating an Acknowledgment 
  Message also does not provide information on how Acknowledgment messages for 
  duplicate messages should be generated. The required information is actually 
  included in section 7.5.2 but in a rather convoluted form (see 
  below). 

  
<<The second paragraph is 
  section 7 defines what an Acknowledgment Message is -- which is the intention 
  of this link.>> 

  
2         
  If the message is not a duplicate (there is 
  no MessageId held in persistent storage that corresponds to 
  the MessageId in the received message) 
  then do the following:

  
a         
  Save the MessageId of the received message 
  in persistent storage. As an 
  implementation decision, the whole message MAY be stored if there are other 
  reasons for doing so

  
b         
  Generate an Acknowledgment 
  Message in response (this may be as part of another message).  The Receiving MSH MUST NOT send an Acknowledgment Message until the message has be 
  safely stored in persistent 
  storage.  Delivery of an Acknowledgment Message constitutes an 
  obligation by the Receiving MSH to 
  deliver the message to the application or forward to the next MSH in the 
  message path as appropriate.  
  Look in persistent storage for the first response 
  to the received message (i.e. it contains a RefToMessageId that matches the MessageId of the received 
  message).

  
(1)     If a response message was found in persistent storage then resend the 
  persisted message back to the MSH that sent the received message

  
      The above discussions (in red) are really in the wrong place as the enclosing 
  item #2 indicates that the message is not a duplicate. 

  
<<we 
  are not looking for a duplicate here.  We are looking to see if a 
  response (Acknowledgment Message) has previously been sent.  If so, send 
  the same one again.  If not, do the following.  Maybe it would help 
  to say "Acknowledgment Message" instead of 
  "response".>> 

  
(2)     If no 
  response message was found in persistent storage, 
  then:

  
(a)    if syncReply is set to true and if the CPA indicates an 
  application response is included, ignore the received message (i.e. no message 
  was generated in response to the received message, or the processing of the 
  earlier message is not yet complete)

  
If the incoming message message is a duplicate and syncReply is 
  true but no message has been returned in response to the received message, 
  then it must be the case that processing of the earlier message is not yet 
  complete. In that case, the received message cannot be ignored. Instead, it is 
  necessary to wait for completion of the earlier message and then return the 
  response synchronously. (By the way, this clarification does not belong in 
  this section because of the inconsistency (cited in red) above. 

  
<<Somehow just saying ignore seems wrong, I know.  
  However, we certainly do not need to contact the Application and request a 
  business reply again.  Either the first message is still doing that or 
  the whole thing is hung and there is nothing the MSH can do.  I 
  don't know what else to do besides ignore the resent message and wait for 
  the completion of the old -- which will send an Acknowledgment when it is 
  finished (if it ever finishes).>>

  
(b)    Otherwise, 
  generate an Acknowledgment Message 
  .

  
A Receiving MSH 
  node is NOT participating in the reliable messaging protocol for a received 
  message if that message either; does not contain an AckRequested element, or does 
  contain an AckRequested element that is not 
  targeted at the Receiving MSH, 
  because it is acting in a role other than that specified in the SOAP 
  actor attribute of the received message. If the Receiving MSH node is operating as an 
  intermediary along the message's message path, then it MAY use 
  store-and-forward behavior. However, it MUST NOT filter out perceived 
  duplicate messages from their normal processing at that node. (see section 
  11.2)

  7.5.3       
  Generating an Acknowledgment Message
  
An Acknowledgment 
  Message MUST be generated whenever a message is received with an AckRequested element that has a 
  SOAP actor URI which targets the Receiving MSH node.

  
As a minimum, it MUST contain a MessageData element with a RefToMessageId that contains the 
  same value as the MessageId element in the message 
  being acknowledged and an Acknowledgment element.

  
The above paragraph contradicts an 
  earlier statement in section 7.5 (before 7.5.1): 

  
<<agreed.  Actually, the RefToMessageId is now 
  in the Acknowledgment element.>> 

  
An Acknowledgment Message MUST contain a 
  MessageData element with a RefToMessageId that contains the 
  same value as the MessageId element in the message being acknowledged and an Acknowledgment element as 
  described in section 7.3.1.

  
It is important to reiterate that 
  the Acknowledgment message must be persisted before being sent. Need to say 
  something about the persist duration for this message. Presumably, this can be 
  the same as the persist duration for the incoming message. In fact, the 
  definition of PersistDuration in section 7.4.6 needs to be expanded to cover 
  "first response" messages. 

  
<<PersistDuration on the response message should be 
  the same as on the First Message.  OK, persistDuration is an 
  interval.  Is this since the original timestamp or since the timestamp on 
  the response message?>> 

  
Depending on the value of the syncReply parameter, the Acknowledgment Message can be sent at 
  the same time as the response to the received message. In this case, the 
  values for the MessageHeader elements of the Acknowledgment Message are determined 
  by the Service and Action associated with the 
  business response.

  
If syncReply is not specified in 
  the incoming message or is not applicable to the delivery channel being used, 
  then the CPA must be consulted to determine the delivery channel that is 
  suitable for the Acknowledgment action. This delivery channel must not specify 
  the use of Reliable Messaging! 

  
<<OK, 
  what if there is no CPA?  Can I change the above to say "if there is a 
  CPA, then...">> 

  
If an Acknowledgment 
  Message is being sent on its own, then the value of the MessageHeader elements MUST be set 
  as follows:

  
·      
  The Service element MUST be set to: uri:www.oasis-open.org/messageService/

  
·      
  The Action element MUST be set to Acknowledgment.

  
·      
  The From element MAY be populated with 
  the To element extracted from the 
  message received and all child elements from the To element received SHOULD be 
  included in this From element.

  
·      
  The To element MAY be populated with 
  the From element extracted from the 
  message received and all child elements from the From element received SHOULD be 
  included in this To element.

  
·      
  The RefToMessageId element MUST be set 
  to the MessageId of the message 
  received.

  7.5.6       Failed 
  Message Delivery
  
If 
  a message sent with an AckRequested element cannot be 
  delivered, the MSH or process handling the message (as in the case of a 
  routing intermediary) SHALL send a delivery failure notification to the From Party. The delivery failure 
  notification message contains:

  
·      
  a From element that identifies the 
  Party who detected the 
  problem

  
·      
  a To element that identifies the From Party that created the message 
  that could not be delivered

  
·      
  a Service element and Action element set as described in 
  4.2.3.3.

  
·      
  an Error element with a severity 
  of:

  
-          
  Error if the party who detected 
  the problem could not transmit the message (e.g. the communications transport 
  was not available)

  
-          
  Warning if the message was 
  transmitted, but an Acknowledgment 
  Message was not received. This means the message probably was not 
  delivered.

  
·      
  an ErrorCode of DeliveryFailure

  
It is possible that an error message with an Error element with an ErrorCode set to DeliveryFailure cannot be 
  delivered successfully for some reason.  
  If this occurs, then the From 
  Party that is the ultimate destination for the error message MUST be 
  informed of the problem by other means.  
  How this is done is outside the scope of this 
  specification

  
Note:  If the From Party MSH receives 
  an Acknowledgment Message from the To Party MSH, it SHOULD 
  ignore all other DeliveryFailure or Acknowledgment 
  Messages.

  
If syncReply is in use, then the error 
  message should be returned synchronously. Otherwise, the CPA needs to be 
  consulted to determine the appropriate delivery channel for the MessageError 
  action.