OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

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

Subject: Re: reliable messaging


Please see below.


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

> 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

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

Powered by eList eXpress LLC