David:
The purpose of a sender retrying is not only to solicit for
acknowledgment from the receiver, but also to solicit for the business level
response. Therefore, if the Acknowledgment message is piggybacked on the
business level response, then the latter compound message must be resent by the
receiver in response to the duplicate message.
Regards,
-Arvola
-----Original Message-----
From:
David Fischer <>
To:
David Fischer <>; Arvola
Chan <>;
<>
Cc:
<>
Date:
Tuesday, October 16, 2001 12:10 PM
Subject: RE: [ebxml-cppa]
Comments on reliable messaging in the 1.0.5 draft
Let me take some of that back. If we find an Acknowledgment
Message in persistent storage, we can only reuse it if it is not
piggybacked on another message. Is this really too much
complexity? Should we just create a new Acknowledgment Message?
This kind of search probably takes more cycles then just creating from
scratch. . .
Regards,
David Fischer
Drummond Group.
-----Original Message-----
From: David Fischer
[mailto:]
Sent: Tuesday, October 16, 2001
1:40 PM
To: Arvola Chan;
Cc:
Subject: RE: [ebxml-cppa] Comments
on reliable messaging in the 1.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.
