MHonArc v2.5.2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: [ebxml-msg] reliable messaging
Jacques,
You definitely have the right idea of how the message status service should
be used. The service SHOULD be "more explicitly integrated
in a reliability policy, at MSH level." In other words, the reliable
messaing specification must prescribe how the message status service SHALL
be used.
Regarding the status request, another possiblity is no response at all, if
the other MSH is still down. There should be some words about that case. I
suggest a recommendation to retry the status request with some periodicity
appropriate to system failures, and eventually to make human contact.
Should the status request be sent reliably?
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
*************************************************************************************
Jacques Durand
<JDurand@fsw.fuji To: Martin W Sachs/Watson/IBM@IBMUS, Christopher B Ferris/Waltham/IBM@IBMUS
tsu.com> cc: ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] reliable messaging
10/16/2002 04:46
PM
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