RE: [ebxml-msg] reliable messaging

[Dave Elliot <david.elliot@xmlglobal.com>]

Presumably the first step would then be to remove the following
statement (lines 1783 & 1784) from the successor to the 2.0
specification.  Although one wonders as to the original reasoning behind
explicitly including this statement?

"A Message Service SHOULD NOT use the Message Status Request Service to
implement Reliable Messaging."

Dave Elliot
XML Global Technologies



On Wed, 2002-10-16 at 13:46, Jacques Durand wrote:
> 
> A more detailed definition of Reliability might answer this,
> so that expectations remain reasonable... 
> The spec may have to distinguish two aspects, somewhat orthogonal:
> 
> - the quality of the delivery, e.g "at-least-once" and "at-most-once", which
> we know cannot be always enforced, for the same reasons Chris mentioned.
> The number of retries states the limits of the effort. Probably the scope of
> the duplicate check should also be specified somehow - e.g. in CPA .
> (e.g. while duplicate elimination may not be guaranteed over a long time,
> it may be critical for a business to know that an MSH guarantees the
> elimination 
> of duplicates over a 1 week period.)
> 
> - the quality of the sender-receiver synchronization, where several [if not
> all]
>  out-of-sync scenarios can be addressed.
> The message status service gives primarily a way to resynchronize
> at application level. This service could be more explicitly integrated
> in a reliability policy, at MSH level, where status values such as
> "received", 
> "processed" make more sense.
> (For example, a refined policy could be that an MSH not receiving any Ack
> after 
> all retries timeout, will send a status request... and notify a delivery
> failure to 
> the app only if the status response is "NotRecognized", and will not if
> status is "Received" or "Processed". ) 
> 
> Regards,
> 
> Jacques
> 
> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: Monday, October 14, 2002 10:32 AM
> To: Christopher B Ferris
> Cc: ebxml-msg@lists.oasis-open.org
> Subject: Re: [ebxml-msg] reliable messaging
> 
> 
> 
> 
> 
> 
> Chris,
> 
> Yes, as I told Komal, the message status services seems to be just what is
> needed. However, its presence is not enough.  Reliable Messaging has its
> own interoperability matters and prescribing the use of the message status
> service along with prescribing minimal state to be persisted is still
> necessary.
> 
> Of course, it's impossible to close the loop completely. However, people
> who view that the important reason for reliable messaging is to cover
> (most) cases of system failure and recovery view absence of system failure
> coverage as a major omission.
> 
> Identifying and stating the known limitations is also part of a
> specification writer's responsibilities.
> 
> 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 B
> 
>                       Ferris                   To:      Martin W
> Sachs/Watson/IBM@IBMUS                                             
>                                                cc:
> ebxml-msg@lists.oasis-open.org                                              
>                       10/14/2002 12:27         Subject: Re: [ebxml-msg]
> reliable messaging(Document link: Martin W. Sachs)          
>                       PM
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> 
> 
> Marty,
> 
> ebMS *does* indeed provide such a status query. Granted that its required
> use in the
> failure mode you articulate is not specified (it could easily be). I do not
> believe that
> the protocol is necessarily broken in this regard, however it could
> certainly be reinforced
> and made more clear.
> 
> I should also point out that no matter how hard one tries, it is impossible
> to close the
> loop entirely. If B never recovers, then A and B are permanently and
> unreconcilably
> out of synch w/r/t their shared understanding of the state of the exchange.
> 
> Further comments below.
> 
> Cheers,
> 
> Christopher Ferris
> Architect, Emerging e-business Industry Architecture
> email: chrisfer@us.ibm.com
> phone: +1 508 234 3624
> 
> Martin W Sachs/Watson/IBM@IBMUS wrote on 10/14/2002 11:46:01 AM:
> 
> >
> >
> >
> >
> > It has been pointed out to me that ebXML reliable messaging is not
> reliable
> > under system failure.  At least one person who mentioned it considers
> ebXML
> > messaging to be broken as a result.  Here is a scenario:
> >
> > Party A send a message reliably to Party B.
> >
> > Party B's MSH receives and persists the message.
> >
> > Party B's MSH attempts to send the reliable-messaging acknowledgment but
> > Party B's system goes down before the acknowledgment gets on the wire.
> >
> > Party A exhausts its retries and concludes that the message was not
> > delivered.
> >
> > Party B eventually comes up and the destination application processes the
> > persisted message as prescribed in the MSG specification.
> >
> > Parties A and B are now out of sync with respect to that transaction and
> do
> > not know they are out of sync. Party A believes that the transaction
> > failed. Party B has in fact processed the message that it received from
> > Party A. Reliable messaging has failed to deliver on its promise.
> >
> > The solution to this problem is not trivial and the MSG team needs to
> give
> > it a lot of thought.  At a minimum, the following are needed in the spec:
> >
> > 1.  Both parties to the message exchange MUST persist enough state to
> allow
> > recovery and getting back in sync. Specific state variables must  be
> 
> This is already prescribed in the spec.
> 
> > prescribed.  They are at least those variables needed to restore the
> state
> > of the transaction and conversation after system recovery, such as the
> > conversation ID, CPA Id, service, action, and perhaps other parts of the
> > message header.
> >
> > 2. Timeouts and retries, as prescribed in the MSG spec, are not
> sufficient
> > to cover system failures since the failure could last a very long time.
> > Instead, if the party that sent the message doesn't receive a reply in a
> > reasonable time, it must be able to send a status query to the other
> party
> > and keep requesting status periodically until it receives a response.
> The
> > status query protocol must be defined in the MSG specification. If the
> 
> The protocol is defined, see section 7.
> 
> > appropriate state information is persisted at both ends, when party B
> comes
> > up, it will receive and respond properly to the status query.  The
> timeouts
> > could be retained in the spec but their main use would be to signal the
> > "attached human" to make a phone call.
> 
> That is always an option:)
> 
> >
> > The MSG team should consider this a work item for version 3. Should the
> > team not wish to solve this problem, at the very least, a caveat should
> be
> > added to the MSG specification that messaging reliability under
> conditions
> > of system failure is outside the scope of the MSG team.
> 
> Again, I believe that much of your concerns are already addressed. There is
> no
> doubt in my mind that they could be reinforced, making it abundantly clear
> to the reader.
> 
> >
> > 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 subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> 
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>