[ebxml-msg] 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).

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.

(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.

(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):

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.

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!

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.