Next in thread →
Next in month →
RE: [ebxml-msg] Re: [ebxml-cppa] Comments on reliable messaging inthe1.0.5 draft
Yes, I think this answers the question.
I suppose you could have an application level retry which could be either
a new message or a signal to the MSH to retry a previous message -- but I don't
think we are talking about that.
This is an MSH level retry -- same Message, same MessageId same exact bytes pulled out of "storage" where it is saved
until the appropriate Ack is returned.
I guess we are down to what happens if syncReply is true but the
connection closes unexpectedly. There will be a Message (with this
MessageId) in persistent storage but no Acknowledgment will have been sent
back. When the retry arrives, it will find the previous message in
persistent storage but no connection waiting and no Acknowledgment
returned. The current spec says to ignore the message since a previous
message is already waiting but now I think that is wrong. Sounds like the
connection needs to be persisted at this point and the message needs to be
presented to the Application (again). This presents a problem since the
Application will now have duplicate messages. Am I getting this
right? Do we need a new signal to the Application in this
case?
Regards,
David Fischer
Drummond Group.
-----Original Message-----
From: Dale Moberg
[mailto:]
Sent: Tuesday, October 16, 2001
7:40 PM
To: David Fischer; Arvola Chan;
;
Subject: RE: [ebxml-msg] Re:
[ebxml-cppa] Comments on reliable messaging in the1.0.5
draft
Whew. A lot of TCP connection questions today. Is this the
issue:
If a
sender MSH is waiting for a HTTP Reply, and meanwhile the sender MSH is
told
to
do an application level retry, should the sender drop the initial
connection? If so,
what
happens at the Receiver end?
(Basically, dropping the TCP connection at the sender end
will cause an IO exception
at
the other end, that will in production code
lead
to some clean up procedures being run that should
probably
include forgetting about doing any HTTP reply--
no
point to reply on a closed connection
obviously. A lot of stuff about FIN and ACK
and
TIMEWAIT2 omitted-- see Stevens.)
If
this is the question, I have some other questions and
remarks.
Is
the application level retry to be a new message (with a new message id, and so
on)?
Or
is retrying a message an implicit service that a MSH offers the application
level, so
that
the same message (with same message id) is pulled out of an archive
or
cache or queue and resent?
If
the same message is resent, why can't the currently pending wait for a
response
continue? Why put on more load, scrap an underway handling of the
request, just to
adhere to an additional retry request? Something sounds funny in what
is being
done in this case by
scrapping an already underway service in order to start again and
encounter the processing overhead
anew.
If this is a way to try to deal with "hangs," and to
distinguish hangs from slow response,
"good luck!" No good way to sort that one out without
humans--even adding
a forward progress indicator every 10 seconds ("100
Continue" or something like it)
only gets you so far. I really get the feeling that
we are adding level 2.0 or beyond
exception handling for situations that, if they are
to be dealt with at a protocol level,
need some really new state machines.
Checkpoint/restart, rendezvous logic, forward
progress--
is not the kind of stuff for a 1.1 spec. Wait until
SOAP over BEEP
and add on a BEEP Channel with all those
embellishments..
HTTP is just not general purpose enough to bother
trying to put all
this stuff on top of
it.
Also, mixing retry of RM with application level retry seems to be an
area for new tangles.
Is
application level retry something that can be mixed with RM or should an
application
choose best effort if it is doing A.L. retry? I realize RosettaNet has
application level retries.
Is
this functionality something beyond what RM can provide? Couldn't moving to
RM,
using PIP parameter values in the RM parameters,
satisfy RosettaNet retry requirements?
(If
a new MessageId is to be used when doing application level retries,
then
that would be another story.)
Finally, why is this on a blue-greenish background?!!?
-----Original Message-----
From: David Fischer
[mailto:]
Sent: Tuesday, October 16, 2001
4:39 PM
To: Arvola Chan;
Cc:
Subject: RE: [ebxml-msg] Re:
[ebxml-cppa] Comments on reliable messaging in the1.0.5
draft
OK, I agree. How do we tell the MSH to use this new sync
connection instead of the old one which is holding? Just because the
Sender decides to drop the connection, does not mean the Receiver actually
realizes that. I am not a packet expert but, isn't the the Receiving end
still waiting? I don't think there is anything like a "keep-alive"
packet going back and forth. The connection is literally doing
nothing.
Regards,
David.
-----Original Message-----
From: Arvola Chan
[mailto:]
Sent: Tuesday, October 16, 2001 2:43
PM
To:
Cc:
Subject: [ebxml-msg] Re:
[ebxml-cppa] Comments on reliable messaging in the 1.0.5
draft
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.
Next in thread →
Next in month →