Re: reliable messaging

[christopher ferris <chris.ferris@east.sun.com>]

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
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard