RE: reliable messaging

[David Fischer <david@drummondgroup.com>]

If RM includes a signed DR with ds:Reference, this becomes NRR.  Why wouldn't
this constitute (1)?  Without the above, then RM is just for convenience.

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: jacques durand [mailto:jacques@savvion.com]
Sent: Friday, August 24, 2001 7:00 PM
To: Burdett, David
Cc: 'christopher ferris'; ebxml-msg@lists.oasis-open.org;
ebxml-cppa@lists.oasis-open.org
Subject: Re: reliable messaging




"Burdett, David" wrote:

> Chris said ...
>
> >>>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.)<<<
>
> Note that there is an edge case where all the acknowledgements that were
> sent failed to be delivered, e.g. maybe a MSH can receive messages but not
> send them. This means that even though no acknowledgement was received, the
> message was actually delivered.

That is indeed a point we have demonstrated in past POC.
Clearly, RM cannot be substituted to a message-based transaction service, which
is the right
level to guarantee consistency across parties' apps. But it can be the basis for
such a service.
By NOT receiving an ack, the sender should not infer that the receiver has not
received the message:
only that the reception has not been confirmed, and that it is OK to resend it
(the duplication check doing the cleanup job on receiver side).

Regardless of what RM can or can't do, the question raise dby Martin W Sachs
( the requirement to notify sending party) is interesting in that it depends on
the definition
of RM:
(1) if RM is a contract between sending party, receiving party, and MSH
transport layer, then
these sender notifications (as well as elimination of duplicate for receiver)
are part of the contract.
(2) if RM is a contract between two end-point MSHs, then these notifications
have no normative
value.

My understanding is that (2) is currently applies (so SHOULD should remain
SHOULD...)
However, once an formal MS API is specified, the MS spec will have to address
the
"contract" value of such API, with regard to sender and receiver...

My two cents...

Jacques Durand
Savvion

>
>
> David
> PS Catching up on emails and logging them into the change request database
> ;)
>
> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: Friday, August 03, 2001 7:36 AM
> To: ebxml-msg@lists.oasis-open.org; ebxml-cppa@lists.oasis-open.org
> Subject: Re: reliable messaging
>
> Marty,
>
> Please see below.
>
> Chris
>
> 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
> cases.
>
> >
> > Regards,
> > Marty
> >
> >


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>