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: [ebxml-msg] Re: [ebxml-cppa] Comments on reliable messaging in the1.0.5 draft

My new comments are in green.
Arvola, I think I need some clarification.
<<comments inline>>
-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Tuesday, October 16, 2001 12:39 PM
To: ebxml-msg@lists.oasis-open.org
Cc: ebxml-cppa@lists.oasis-open.org
Subject: [ebxml-cppa] Comments on reliable messaging in the 1.0.5 draft

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

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

      My point is that if the message is a duplicate, then you don't regenerate an Acknowledgement message. Rather, you have to look for the "first response message".

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

      Since we already know that the message is not a duplicate (item 2 above), there cannot possibly be a response/Acknowledgment message. The discussion should really go to item 1 above (not item (1)) where we have determined that the incoming message is a duplicate message that has an AckRequested element.

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

The reason for getting the duplicate is because the sender is retrying. It is quite possible that the sender closes the HTTP connection for the previous attempt before retrying. Therefore, the response from the application when it becomes available must be returned over the connection used to carry the duplicate message.

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

My point is that section 7.4.6 defines PersistDuration as something that applies to a reliably sent message by a receiving MSH. I recommend to add the clarification that the "first response message" also needs to be kept persistently until the incoming message has been garbage collected. I think we can compute an expiration time for both the incoming message and the "first response message" by adding the PersistDuration to the timestamp of the incoming 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...">> 

Even if there is no real CPA, the CPAId must resolve to a set of configuration parameters and they better contain information on how a standalone Acknowledgment message should be returned.

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

      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.  

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

Powered by eList eXpress LLC