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 on reliable messaginginthe1.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.




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


Powered by eList eXpress LLC