Re: reliable messaging

[Martin W Sachs <mwsachs@us.ibm.com>]

I believe that the point is not that the originating MSH doesn't receive
the ACK but that the originating MSH has exhausted the specified number of
retries without receiving an ACK.   Manual inquiry may be the right answer
but this has to be clearly stated in the specification in the hopes that it
will be propagated up to where the people who have to make the inquiries
will see it.

Someone else suggested making the RM protocol transactional, presumably
with the idea that the received message would not be given to the
application unless the RM transaction completed successfully.  I don't know
what that protocol would be but I would guess that it would have extra
messages back and forth, so it might slow things down for the normal cases.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



christopher ferris <chris.ferris@east.sun.com>@Sun.COM on 08/27/2001
08:59:05 AM

Sent by:  Chris.Ferris@Sun.COM


To:   "Burdett, David" <david.burdett@commerceone.com>
cc:   ebxml-msg@lists.oasis-open.org, ebxml-cppa@lists.oasis-open.org
Subject:  Re: reliable messaging



David,

I'm not sure I understand your point here. Are you saying that
the originating MSH doesn't receive the ack from the receiving
MSH in which case it believes that the message hasn't been delivered
when in fact it has?

If that's the case, I agree that this is possible. That's why it
requires manual intervention (you call to find out what's going
on so that the problem can be fixed).

Cheers,

Chris

"Burdett, David" wrote:
>
> Chris said ...
>
> >>>If no acknowledgment has been received, the sender continues to retry
> delivery, using the Retries and RetryInterval to govern processing. When
the
> number of retries identified by Retries is exceeded, the sending MSH
> SHOULD notify the sending "party" by some means that is unspecified
> (e.g. notify the application through some API that it provides, log
> something
> useful in an error log, etc.)<<<
>
> Note that there is an edge case where all the acknowledgements that were
> sent failed to be delivered, e.g. maybe a MSH can receive messages but
not
> send them. This means that even though no acknowledgement was received,
the
> message was actually delivered.
>
> David
> PS Catching up on emails and logging them into the change request
database
> ;)
>
> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: Friday, August 03, 2001 7:36 AM
> To: ebxml-msg@lists.oasis-open.org; ebxml-cppa@lists.oasis-open.org
> Subject: Re: reliable messaging
>
> Marty,
>
> Please see below.
>
> Chris
>
> Martin W Sachs wrote:
> >
> > Chris,
> >
> > I think I may have been unclear.  I specifically am not after an
> > application-level response for this purpose.
> >
> > The question is:  when can a sending party conclude that his message
> either
> > was or wasn't delivered?  That time is not relevant to the performance
of
> > the application function.  If the service provider site goes down
before
> > processing the message, but the message has been persisted ( a key
> > requirement of reliable messaging), knowing that the message was
persisted
> > at the application is important information because it tells the
sending
> > party not to resend.
>
> Then receipt of the reliable messaging acknowledgment is the answer to
> your question. That is the point at which the sender knows that the
message
> has been received and persisted.
>
> >
> > Yes, receipt of the RM acknowledgment tells the party that the message
got
> > there but how long does the sending party wait to decide that it won't
be
> > receiving a guaranteed delivery failure notification?  The answer, in
my
>
> If the sender receives an acknowledgment, it won't be receiving a
guaranteed
> delivery failure notification because the message HAS been received. Once
> this acknowledgment has been received it SHOULD cease all reliable
messaging
> retries, etc. as any subsequent retries would place an unnecessary burden
> on both party's MSHs.
>
> If no acknowledgment has been received, the sender continues to retry
> delivery, using the Retries and RetryInterval to govern processing. When
the
> number of retries identified by Retries is exceeded, the sending MSH
> SHOULD notify the sending "party" by some means that is unspecified
> (e.g. notify the application through some API that it provides, log
> something
> useful in an error log, etc.)
>
> It isn't at all clear to me that the sender needs anything more than
> Retries and RetryInterval to achieve its mission. Again, persistDuration
> is NOT a sending MSH parameter, it is a receiving MSH parameter.
>
> > mind, is long enough for all the allowable reliable-messaging retries
to
> be
> > completed.  I believe that persistDuration is the right answer as long
as
> > it is prescribed that it be set long enough to cover the time to
complete
> > the allowed number of retries plus a little for propagating the
delivery
> > failure notification back to where the sending application can find it.
> > Alternately, a worst case time to recognize a delivery failure could be
> > defined.
> >
> > The sending application cannot determine if the message is relevant
unless
> > it knows that delivery did or did not succeed.  Receiving or not
receiving
> > a delivery failure notification within a defined time is crucial.
> >
> > Yes, what I described covers several layers in the stack and maybe
several
> > middleware "modules".  However, unless all the reliable messaging rules
> are
> > set down in one place, they will never be understood.
> >
> > ...and let me reiterate again:  The messaging service must guarantee
that
> a
> > delivery failure notification will be sent by the sending MSH to the
> > sending application in all cases where delivery could not be made.
> Without
> > this, reliable messaging is utterly broken because the key requirement
of
> > reliable messaging is that the state of the business transaction not be
in
> > doubt if the application-level acknowledgment is not received.  If the
> > message sender is not notified of delivery failure, reliable messaging
> > fails because the sending application does not know if the message got
to
> > the other party and therefore doesn't know how to recover.  People
outside
> > of the ebXML teams are starting to notice this failure and conclude
that
> > reliable messaging is no good.  Changing those SHOULDs to SHALLs is
> > essential to the business future of the ebXML specifications because
> > reliable messaging is a major component of the value of the ebXML
message
> > service.
>
> The MS specification cannot dictate to implementation vendors anything
> of this nature. How they notify the sending "party" (application or
> person) is strictly within their prerogative. The MS spec deals
exclusively
> with the details of the wire protocol, not the implementation details
> of how an MSH is integrated with some application.
>
> I don't see how this can be perceived as a failure of the specification
> when it is clearly (IMO) outside the scope of our work.
>
> If we change all of these SHOULDs to SHALLs then everyone would be
> asking "how?" to which there is no possible answer that covers all
possible
> cases.
>
> >
> > Regards,
> > Marty
> >
> >
>
****************************************************************************

> *********
> >
> > Martin W. Sachs
> > IBM T. J. Watson Research Center
> > P. O. B. 704
> > Yorktown Hts, NY 10598
> > 914-784-7287;  IBM tie line 863-7287
> > Notes address:  Martin W Sachs/Watson/IBM
> > Internet address:  mwsachs @ us.ibm.com
> >
>
****************************************************************************

> *********
> >
> > christopher ferris <chris.ferris@east.sun.com> on 08/02/2001 08:52:48
PM
> >
> > To:   Martin W Sachs/Watson/IBM@IBMUS
> > cc:   ebxml-msg@lists.oasis-open.org, ebxml-cppa@lists.oasis-open.org
> > Subject:  Re: reliable messaging
> >
> > Marty,
> >
> > The example you provide is orthogonal to reliable messaging.
> > What you seem to be after here is an application or process-level
> > response(s) which are (I believe) accounted for in the BPSS.
> >
> > You determine if a message was safely delivered by receipt of a
reliable
> > messaging acknowledgment. This is a function of the MSH, not the
> > application
> > that will ultimately process the message. The persistDuration refers
> > to the minimum (not maximum) amount of time that a receiving MSH has
> > committed to keeping the message (or its artifacts) in persistent
> > store such that it can determine a) if a subsequently received
> > message is the same message as one that has already been received
> > and b) respond with the response that it might previously have
> > sent to the original message. This serves to provide for the
> > possibility that the acknowledgment that was sent might not have
> > been received by the sender of the message being acknowledged.
> >
> > As to when the sender knows that the message has been successfully
> > delivered, as before, the acknowledgement message serves this function.
> > Once the sender of a message receives the corresponding acknowledgment,
> > it can cease trying to deliver it.
> >
> > Now, reliable messaging ONLY applies to the MSH, which MAY not be
> > the same software agent that is the intended consumer of a message.
> > The receiving MSH is responsible for delivering the message to the
> > intended application handler. The BPSS defines a set of business,
> > not MSH, level signals (or signal patterns) that apply to a business
> > message. These are the responsibility of the application. Again,
> > persistDuration has nothing to do with this aspect. An MSH that cannot
> > deliver a message to the application software responsible for
processing
> > the message needs to keep trying to deliver it to that software
> > entity until it is successful.
> >
> > IMO, it is the application's responsibility to determine whether
> > the message is still relevant. The MSH should make no such
determination.
> >
> > Cheers,
> >
> > Chris
> >
> > Martin W Sachs wrote:
> > >
> > > Don't the two trading partners have to agree on the maximum time for
a
> > > message to be successfully delivered or a delivery failure
notification
> > > returned?  When can I decide that the message was in fact delivered?
> For
> > a
> > > business process that includes return of a "received" or "received
and
> > > parsed" signal, receipt of such a signal confirms delivery, but when
do
> I
> > > decide that it isn't going to come?  That time should be a lot
shorter
> > than
> > > the time to process the request.  For example, I may request a stock
> > trade
> > > transaction and expect that the trade will take place within, say, 2
> > hours,
> > > but the confirmation might not be posted to the broker's database
until
> > > overnight.  I would want to know quickly that the trade request was
> > > accepted or failed to be delivered.  I could continuously poll for a
> > > delivery failure notification, but how long do I poll?
> > >
> > > One possibility is that persistDuration is in fact the time that I am
> > > looking for, provided we say that it has to be long enough to include
> > > reliable delivery of a delivery failure notification (and maybe
change
> > its
> > > name).
> > >
> > > Regards,
> > > Marty
> > >
> > >
> >
>
****************************************************************************

> *********
> >
> > >
> > > Martin W. Sachs
> > > IBM T. J. Watson Research Center
> > > P. O. B. 704
> > > Yorktown Hts, NY 10598
> > > 914-784-7287;  IBM tie line 863-7287
> > > Notes address:  Martin W Sachs/Watson/IBM
> > > Internet address:  mwsachs @ us.ibm.com
> > >
> >
>
****************************************************************************

> *********
> >
> > >
> > > ------------------------------------------------------------------
> > > To unsubscribe from this elist send a message with the single word
> > > "unsubscribe" in the body to: ebxml-cppa-request@lists.oasis-open.org
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-cppa-request@lists.oasis-open.org

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