Re: Reliability is really two-phase (was RE: Reliable Web Services)

> Good questions.
>
> If you need instanteneous response than you would use a service that
> provides instanteneous response.

Do you mean a service or a messaging system here?  If you mean service,
there's no such thing as a service that provides instantaneous response,
and even if one purported to, reality stacks the decks against it.  maybe
I misunderstand.

> You would typically use a synchronous
> communication protocol to expedite back & forth communication.

How does waiting for a response expedite it?  Usually when I wait for
things, it doesn't make them happen faster.  Do I understand you?

> If you can
> tolerate waiting for a response for an amount of time that is longer than
> the latency of the protocol, then you would consider using asynchronous
> messaging.

Is this a real "if"?  If I *can't* tolerate the propagation times of the
medium,
should I be using its bandwidth at all?

If I use "asynchronous messaging", then I either need an application that
polls, or I need an application designed to be interruptable.  Either of
these infects the application with networking complexities.  I thought the
goal of this RM layer was to keep that out of the app.  Maybe I don't
understand...

> If you use asynchronous messaging, then you may want to use an
> RM.

That's what I thought we were talking about.  Using an RM.

>
> What you have here are two different timeouts. Let's say that X is the
> amount of time you want to receive a response from the other service, and
Y
> is the maximum latency for getting a request to the service (and an ack
back
> to the sender). You set Y to be significantly smaller than Y, and that
> allows the RM to speed things up depending if you need fast response, or
> take it easy if you can accept a slower response time.

This doesn't fit my experience very well.  Usually X is some limit
approaching
zero.  Who wants to wait longer than absolutely necessary?  Why would I
arbitrarily say "you can get back to me four hours from now"?  It's not
competitive.

As for Y being maximum latency, maximum latency is always infinity as
far as I know.  Did you mean minimum latency?  It sounds oveall as if you're
designing features for patient users.  I wonder if they'd get any use.
But I'm not sure I understand.

>
> For example the maximum time to respond to a purchase order request (X)
> could be 24 hours, and the maximum time to acknowledge a purchase order
> request (Y) would be 4 hours. Let's say that we deem 3 sends as sufficient
> to give us 99.9% reliability. Then the RM would schedule up to three sends
> within 4 hours time frame, give up after 4 hours. The application gives up
> after 24 hours (if it gets ack but no response), so it's never waiting for
> the RM to resend.

I can't think of an application that would be interested in using a service
like that.  Maybe my NYC perspective gives itself away, but this is I-age,
Information, Impatience.  I want service now.

>
> Everything is settable. You can determine what the resend policy is, how
> often to try, what interval, how to escalate, etc. These are all
> implementation details, they depend on the RM you use.

Oh, declarative reliability instead of procedural.  Okay, maybe that
flies.  Sometimes, though, I change my mind about my real-time requirements
mid-transaction...

I don't think these things are *implementation detail* at all!  If I have to
configure them as a client, then they're part of my interface. If I have to
program to accept an interrupt from an asynchronous RM framework,
then once again the constraint is right in the interface.

> > What happens when an application uses an RM framework in order
> > to reduce its complexity, observes and interprets the signs from the
> > RM indicating that messaging was reliable, then discovers that the peer
> > application at the other end is in some unexpected state despite
> > assertions of "reliability"?  Is this impossible?
>
> This could happen even if you use a synchronous protocol with 100%
delivery
> guarantee and you know without a doubt that the message was recieved, but
> the reciever has some software glitch (issue? feature?) that causes it to
> enter this unexpected state.

Precisely.  Restated, "reliability" at the application level is
comprehensive,
inclusive and overarching to "reliability" at the messaging level.  But
since
an application-level result is the only thing my application cares about,
and since my application cannot avoid caring about that and responding
to it, how does it help to "solve 99.9%" of it at a lower level?  In other
words, the empiror was 99.9% clothed, but he was still naked.

>
> Since the same solution applies in either case, it is better if we solve
it
> in a separate layer. You can join the discussion about coordination
> protocols going on in a separate thread and debates these points.

The same solution doesn't apply in either case.  A soft-realtime application
may decide, after waiting X milliseconds for an acknowledgement,
the the business value of that ack has reached zero, based on new
information received by the same application.  The "separate layer"
has no knowledge of that, and so cannot participate, let alone "solve"
the problem.

Where is this other thread?

Thanks,
Walden

Received on Tuesday, 24 December 2002 13:19:07 UTC