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: RE: [ebxml-msg] Re: [ebxml-cppa] Comments onreliablemessaginginthe1.0.5 draft


I agree with what Arvola says here, as long as we
are dealing, as I think we are, with the Ack-from-To
(end-to-end) mode of RM. DF, I did not wish to
indicate that intermediates were to retry in the 
end-to-end RM case (in reply to DF accusation
of reversal)

I think it would be unfortunate to have a retry interval
set so that retries at A began before A got back any
HTTP reply or a communications exception. I think, however,
that the RM protocol will probably allow that misconfiguration.
I do not think we should try to throw up protocol safeguards that
would attempt to prevent this and other misconfigurations, however.
This policy even extends to bad interactions of application-level
retries with MSH RM level retries.

Maybe the IIC group can explore guidelines for this area
of misconfiguration.




-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Wednesday, October 17, 2001 8:13 AM
To: ebxml-msg@lists.oasis-open.org; ebxml-cppa@lists.oasis-open.org
Subject: Re: [ebxml-msg] Re: [ebxml-cppa] Comments on
reliablemessaginginthe1.0.5 draft


David:

The 1.0.5 draft (section 11.2) says that intermediaries are not to
perform
duplicate elimination.

"The use of the duplicateElimination element is not required for
Intermediate nodes.  Since duplicate elimination by an intermediate MSH
can
interfere with End-to-End Reliable Messaging Retries, the intermediate
MSH
MUST know it is an intermediate and MUST NOT perform duplicate
elimination
tasks."

Therefore when A retries, the message will go all the way to D before it
is
determined to be a duplicate. The previous response from the To Party at
D
will be obtained from persistent storage and returned as response to the
retry.

One related question is what should B do when it tries to return the
response the first time and finds that the synchronous connection has
been
dropped. Does it need to report an error to A through a separate
channel? I
think it should just do nothing and expect a retry from A.

-Arvola

-----Original Message-----
From: David Fischer <david@drummondgroup.com>
To: Arvola Chan <arvola@tibco.com>; ebxml-msg@lists.oasis-open.org
<ebxml-msg@lists.oasis-open.org>; ebxml-cppa@lists.oasis-open.org
<ebxml-cppa@lists.oasis-open.org>
Date: Tuesday, October 16, 2001 8:31 PM
Subject: RE: [ebxml-msg] Re: [ebxml-cppa] Comments on reliable
messaginginthe1.0.5 draft


Interesting.  So the connection can actually close at any time.  The
business
reply (with Ack) will be created, placed in persistent store but not
sent.
The
From Party MSH can pick up the reply later by sending a retry?

I suppose then that in a Multi-Hop situation:

A ==> B ==> C ==> D

A sends to B with syncReply but then drops the connection.  B, C & D
proceed
normally.  When the business reply comes back from D through C, it will
make
it
to B but since the connection has been closed, the reply will be put in
persistent storage.  A can then pick up the reply from B by sending a
retry
at a
later time (before persistDuration).  Right?

Regards,

David

-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Tuesday, October 16, 2001 8:46 PM
To: ebxml-msg@lists.oasis-open.org; ebxml-cppa@lists.oasis-open.org
Subject: Re: [ebxml-msg] Re: [ebxml-cppa] Comments on reliable messaging
inthe1.0.5 draft


I don't think the connection needs to be persisted. An implementation
can
simply keep an in-memory table relating synchronous connections (pending
for
replies) with their corresponding RefToMessageIds. When an application
sends
a response message for a synchronous request, its RefToMessageId can be
used
to look up the synchronous connection(s) which should be used for
returning
the response.

If the receiving MSH has not detected that the initial HTTP connection
has
been closed, it will attempt to send using that connection and likely
encounter an error. If it detects the closure at an earlier point, then
presumably the table can be cleaned up earlier and no attempt will be
made
to send the response over the broken connection when the response
becomes
available. By recording the new connection (corresponding to the retry)
in
the in-memory table, the response from the application when it
eventually
arrives can be returned properly.

It is not acceptable to present the retried message to the application a
second time.

-Arvola
  -----Original Message-----
  From: David Fischer <david@drummondgroup.com>
  To: Dale Moberg <dmoberg@cyclonecommerce.com>; Arvola Chan
<arvola@tibco.com>; ebxml-msg@lists.oasis-open.org
<ebxml-msg@lists.oasis-open.org>; ebxml-cppa@lists.oasis-open.org
<ebxml-cppa@lists.oasis-open.org>
  Date: Tuesday, October 16, 2001 6:18 PM
  Subject: 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:dmoberg@cyclonecommerce.com]
    Sent: Tuesday, October 16, 2001 7:40 PM
    To: David Fischer; Arvola Chan; ebxml-msg@lists.oasis-open.org;
ebxml-cppa@lists.oasis-open.org
    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:david@drummondgroup.com]
    Sent: Tuesday, October 16, 2001 4:39 PM
    To: Arvola Chan; ebxml-msg@lists.oasis-open.org
    Cc: ebxml-cppa@lists.oasis-open.org
    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:arvola@tibco.com]
      Sent: Tuesday, October 16, 2001 2:43 PM
      To: ebxml-msg@lists.oasis-open.org
      Cc: ebxml-cppa@lists.oasis-open.org
      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 <david@drummondgroup.com>
        To: David Fischer <david@drummondgroup.com>; Arvola Chan
<arvola@tibco.com>; ebxml-msg@lists.oasis-open.org
<ebxml-msg@lists.oasis-open.org>
        Cc: ebxml-cppa@lists.oasis-open.org
<ebxml-cppa@lists.oasis-open.org>
        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:david@drummondgroup.com]
          Sent: Tuesday, October 16, 2001 1:40 PM
          To: Arvola Chan; ebxml-msg@lists.oasis-open.org
          Cc: ebxml-cppa@lists.oasis-open.org
          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: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


            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.



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>


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


Powered by eList eXpress LLC