RE: reliable messaging

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

David,

This case has been mentioned by someone previously.  I agree that it has to
be considered but it is probably a very rare case.  If we let it drive our
decisions regarding delivery failure notification, we could end up having
reliable messaging that isn't reliable.  Unless the sender can be
absolutely certain that the message was or was't received, the sender is as
much in doubt as if reliable messaging were not used.

Let me try this one that just occurred to me:  As part of the text on what
assumptions Reliable Messaging makes on the implementation, we could state
that "A MSH shall have the ability to determine, by means not specified by
this standard, that it is capable of both receiving and sending messages.
A From-party MSH SHOULD verify its receive capability any time it fails to
receive an acknowledgment after exhausting all retries of a message sent
with reliable messaging. A To-party MSH MAY verify its send capability
whenever it receives more than one duplicate of a message that it has
already received."

Another (related) possibility is that if To-party MSH receives a number of
duplicates of a received message that is equal to the number of retries
stated for the From party in the CPA (or other configuration information),
it shall consider that it did not receive the message.  The problem with
this one is that the MSH cannot make the message available to the From
application until the time for the maximum number of retries has passed
without receiving duplicate messages.  I don't think this would be
acceptable to anyone.

Everyone please think about David's case.  We need to be able to rule it
out in some way.

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
*************************************************************************************



"Burdett, David" <david.burdett@commerceone.com> on 08/24/2001 07:22:09 PM

To:   "'christopher ferris'" <chris.ferris@east.sun.com>,
      ebxml-msg@lists.oasis-open.org, ebxml-cppa@lists.oasis-open.org
cc:
Subject:  RE: reliable messaging



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>