Title: RE: [ebxml-msg] reliable messaging
Agree this statement still applies to the notion of reliability
as we know it today (at-mot-once, at-least-once, or both).
If we "extend" the notion of Reliability to synchronization aspects,
this restriction may be reconsidered...
(so the kids-in-back will be allowed to poll after all,
but only in case the car breaks-down :)
Some case may never resolve, like long-lasting crash and no status response.
Note in that case the current delivery failure / warning to application still applies:
its meaning is not assertive anyway ("...message *probably* was not delivered...")
Maybe rewording needed here to underline uncertainty.
Then each scenario needs be looked at independently.
Jacques
-----Original Message-----
From: Dale Moberg [mailto:]
Sent: Wednesday, October 16, 2002 2:16 PM
To: Dave Elliot; Jacques Durand
Cc:
Subject: RE: [ebxml-msg] reliable messaging
I recall that the sentence was included to discourage
RM implementation by _solely_ checking on status.
The fear was that of the
"trip-with-kids-in-back syndrome"--
in which there is persistent and constant
polling whether we are there yet...
I don't think it was intended to preclude use of
the status inquiry entirely to find out about status.
I agree, though, that the sentence
would need to be
qualified if we explicitly
require use of status
inquiries to treat
the system crash
recovery issues that have
been mentioned.
Dale Moberg
-----Original Message-----
From: Dave Elliot [mailto:]
Sent: Wednesday, October 16, 2002 2:08 PM
To: Jacques Durand
Cc:
Subject: RE: [ebxml-msg] reliable messaging
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:]
> Sent: Monday, October 14, 2002 10:32 AM
> To: Christopher B Ferris
> Cc:
> 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:
>
> 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:
> 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>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
