Re: reliable messaging

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

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.

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

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