RE: Proposed text on reliability in the web services architecture

I'll try.

So far the biggest conclusion I have drawn from the discussion is that
there's a bit of confusion and clearing up that confusion would be the first
task to address. In particular, the term "reliable" may lead to confusion.
It relates specifically to messaging and by itself does not guarantee
reliability of the application.

I got interested in RM because if offers a form of synchronization in an
asynchronous world. Without a doubt if you can determine whether the message
has been delivered, or don't care if it was lost, then RM is redundant. But
for asynchronous delivery you would need some extra measures to be "in
synch" and RM can achieve that.

RM attempts to reduce message loss. Message loss is very generic, a message
that is delivered too late is also considered to have been lost (and will
not be processed). A transport mechanism that does RM may have more
efficient means to combat message loss than the application,

RM does not mean that a message will absolutely get there. RM only means
that it the message got there you will know about it. You still need other
mechanisms to attain reliability, coordination protocols are important. RM
doesn't replace them, but coordination protocols are not the most efficient
means to solve the RM problem.

By abstracting the RM you can use any number of delivery mechanisms with a
reliable messaging guarantee without having to delve into the details. For
example, acking or resending a message would be different whether you use
TCP or UDP, talk to the service directly or use a MOM, do one-on-one or have
an intermediary.

IMO opinion RM should be something that the WS should always offer. Whether
it gets it for free by using TCP (as some pointed out), or needs to employ
some devious mechanism (e.g. a MOM) is immaterial. But when you do use
intermediaries, being able to achieve interoperability would be helpful.

There is a lot of literature about the subject. MOMs do RM, so I am sure the
MOM vendors in the working group can contribute text that would be helpful.
Or we can all just read Distributed Algorithms and try to make sense of it
;-)

Mostly you will find that the definition of RM does not involve knowing
whether the receiver exists or is properly working, or ensuring the messages
will be processed in any particular order. However, most applications of RM
impose this requirement and all the solutions I know of have a way of
verifying the operation of the receiver (aka fault detection) and a way of
ordering messages (aka virtual synchronisity).

arkin


> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Cutler, Roger (RogerCutler)
> Sent: Monday, January 20, 2003 4:05 PM
> To: Champion, Mike; www-ws-arch@w3.org
> Subject: RE: Proposed text on reliability in the web services
> architecture
>
>
>
> Amen to that, brother.  By which I mean your statement, "Deep down in
> this thread there is a lot of good stuff, but it's really hard for the
> editors to mine it out."  As you know I made some efforts to summarize
> the RM threads -- a long time ago when they were a lot simpler.  I
> wouldn't even THINK about trying it now.  ("Don't try this at home, kids
> ...")
>
> It seems to me that the people who have been participating in these
> threads could do everyone a big favor by proposing simple and concise
> statements of one or more points of view that might be starting points
> for verbiage for the architecture document -- or a note from the WG or
> whatever might be most appropriate.
>
> -----Original Message-----
> From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com]
> Sent: Monday, January 20, 2003 5:48 PM
> To: 'www-ws-arch@w3.org '
> Subject: RE: Proposed text on reliability in the web services
> architecture
>
>
>
>  Recall that the SOAP and WSA attempt to be protocol-neutral. There is
> no assumption that RM *is* atop a TCP connection; there may be different
> protocols, there may be unreliable intermediary processes, there may be
> caches that expire and authentications that fail and transactions that
> are rolled back and on and on and on.  Clearly by making enough
> assumptions or adding enough constraints we could come up with a
> scenario where RM is
> pointless.  We can also come up with plenty in where it is useful.
>
> Again, it would be much more useful to identify alternative scenarios
> and assess their architectural strengths and weaknesses than to propose
> one's favorite scenario and argue that the others aren't strictly
> necessary, or to argue that its' upsides outweigh its downsides, etc.
> Deep down in this thread there is a lot of good stuff, but it's really
> hard for the editors to mine it out.
>
>
>
> -----Original Message-----
> From: Walden Mathews
> To: Assaf Arkin; Peter Furniss; Champion, Mike; www-ws-arch@w3.org
> Sent: 1/20/2003 6:38 PM
> Subject: Re: Proposed text on reliability in the web services
> architecture
>
>
> The reason I quibble about this is that if you need RM atop a TCP
> connection, and RM and TCP are congruent* as processes dealing with
> ordered segments on a network, then by a sort of crude induction, you
> can justify an arbitrary number of "needed" layers of this sort of
> thing.  Do you see my concern?  And an architecture's job is to sort out
> this kind of tangle.
>
> * meaning that structurally and operationally they are doing
>    the same job, perhaps under different names
>
>
> > > Is the ordering constraint optional?
> >
> > The ordering constraint should be imposed by the application based on
> the
> > application needs. Otherwise you get an RM that is really good for
> some
> > things, but a bit too heavy for others. That's actually a point I
> raised
> > regading WS-Reliability, I think it offers strict ordering and that's
> too
> > heavy for some applications.
>
> I agree with you.
>
> > But to get that service the client can't get into the details of the
> > protocol. All it could know is how to open a connection, how to close
> the
> > connection, how to determine if the connection is open, and receive
> errors
> > when the connection dies in the middle of sending a message (unless
> the
> > stack recovers so there's no application error).
>
> Interestingly, you're coming close to a point I was trying to make
> earlier.  That our intention is to reduce the complexity the client has
> to deal with.  The reality is that much of that just gets pushed off
> into another bubble, like "how to determine if the connection is open",
> deciding whether it's in a state that will support "connect", or one
> that will support "send" or "recv".  Et Cetera.  The intention to hide
> complexity and the reality of it being different things.  I don't doubt
> the intention, ever.
>
> >
> >
> > >
> > > Or even twenty or thirty.  I've developed lots of frameworks,
> probably
> > > so many because of the fact that one size did not fit all. 8-(
> >
> > Ever heard of one-size baseball hats?
> >
> > Think of RM as a baseball hat. It protects you from the sun, so you
> probably
> > want to wear it on a sunny afternoon baseball game, but you don't
> really
> > need it at night or when you're sitting at home watching TV. And if
> you
> wear
> > just a baseball hat you won't be allowed into any baseball stadium, in
> fact
> > you will be arrested for indicent exposure.
> >
> > It's probably not a good allegory, but I'm trying to look at different
> ways
> > to express the fact that an RM is a solution not "the solution", so
> judging
> > it as "the solution" is not a good approach to evaluating its
> benefits.
>
> You know, you just made me realize that "one size" products, if that's
> really what they were, could only work if the client was willing to
> change to fit them. ;-)
>
> I'm assuming you have a collection of problem cases you're using for
> this evaluation?
>
> > There are three ways to prove that a solution is worthless:
> >
> > 1. Look at the problem and discover that the solution does not solve
> it
> > 2. Look at a different problem and discover that the solution does not
> solve
> > it
> > 3. Look at a bigger problem and discover that the solution does not
> solve
> > all of it
>
> Point taken.  What about the flip side of the coin?  What are some of
> the ways of asserting, incorrectly, that X is "a solution"?  In terms of
> an architecture, what should be the criteria for disallowing these?
>
> Thanks,
> Walden
>
>

Received on Tuesday, 21 January 2003 07:34:17 UTC