RE: Proposed text on reliability in the web services architecture

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Champion, Mike
> Sent: Thursday, January 16, 2003 8:11 AM
> To: Walden Mathews; Hao He; Assaf Arkin; Peter Furniss; Champion, Mike;
> www-ws-arch@w3.org
> Subject: RE: Proposed text on reliability in the web services
> architecture
>
>
>
> This thread is interesting, but difficult to follow.  What have
> we concluded
> about how to improve the proposed text on reliability in Web services?
> Remember that the objective is to make sure multiple perspectives are
> clarified and their tradeoffs identified .... there is NO CHANCE
> (IMHO) that
> we are going to unconditionally favor either ...
>
> - An RM layer as the solution to all problems;

In my experience RM is a solution to problems relating on how to improve
delivery of messages and reducing dependency between the application and the
delivery protocol.

These are not all the problems we experience when building applications.
There are other problems RM does not try to address, and presuming that RM
would solve all problems is a fallacy.

The only thing it does is simplifies the application by taking one problem
away, and that problem is very narrowly defined. (How to assure a sequence
of messages gets from A to B in time and gets processed in order)

> - Rewriting (or writing adapters to expose) legacay apps to use messages
> that are either safe or idempotent.

RM offers physical idempotent (Hao's term) or idempotent invocation (my
term). Whatever you call it, it can actually address that requirement
without having to write a specific adapter. All you need is a generic
protocol adapter, so it's reusable across a variety of applications.

Rewriting apps to become safe or idempotent is possible, but it's shifting
the problem away. If you have X->Y and Y is not safe and you add X->Z->Y
where Z provides safe semantics, then X is easier to develop. But you still
have non-safe Y. So you still need to deal with Y being not safe at some
point.

You may find that it simplifies X which could be a good thing, but it
doesn't make the problem go away.


> - A business process, transaction processing, or choreography layer that
> handles all reliability issues as well as the application-level
> semantics of
> cooperative distributed processing.

Let's assume it can handle all reliability issues. But if you use these
strategies to detect message loss, you get too many false errors that incurs
a performance penalty on these applications. RM makes message delivery
better by dealing with false errors in a more optimized manner, so your
application experiences less false errors.

I call them false errors because there's always a better way to make them
disappear. But there's also valid cases where if you all them you could get
better performance. For example, TCP may make them disappear, but IP
multicast may be better in some applications. Synchronous delivery may make
them disappear, but asynchronous may be better for some applications. RM
just gives you aquivalence, any protocol appears to be as reliable as the
other one.

arkin

>
> So, what SHOULD we say differently as a result of this thread?
>
>
> > -----Original Message-----
> > From: Walden Mathews [mailto:waldenm@optonline.net]
> > Sent: Thursday, January 16, 2003 9:31 AM
> > To: Hao He; Assaf Arkin; Peter Furniss; Champion, Mike;
> > www-ws-arch@w3.org
> > Subject: Re: Proposed text on reliability in the web services
> > architecture
> >
> >
> > Hao,
> >
> > > I think Walden has made a good point. We don't really care
> > about RM, which
> > > itself has been solved in the TCP/IP layer or other messaging layer
> > already.
> > > The whole RM thing is misleading within Web Services
> > context. What we
> > really
> > > care is a reliable way of coordinating a client and its
> > server, although
> > RM
> > > might be helpful.
> >
> > Agreed.
> >
> > >
> > > Making an operation idempotent seems to be a simple and effective
> > solution.
> >
> > I'm leery of this.  If you mean making it idempotent by enclosing it
> > within a message and giving the message identity, then I'd
> > say you were
> > doing RM.  If you mean recognizing that something like a deposit has
> > identity from the client's perspecitive, and allow the client
> > to set the
> > value of the deposit directly, then fine.  I'd call it "finding", not
> > "making".
> >
> > > What we need to distinguish
> > > is the difference between logical operations and physical
> > operations.
> > >
> > > In the bank account example, depositing money into an
> > account is a logical
> > > operation while sending
> > > a request to the bank's Web Services to achieve such an operation is
> > > physical. A logical operation can
> > > be idempotent or not, but we do want all physical operations to be
> > > idempotent.  More precisely, we mean:
> > > 1. r=f(u,x,t), where f is a physical operation on a Web Services
> > identified
> > > by u, x is a request, and t is time, and r is the results
> > returned by the
> > > WS.
> > > 2. r'=f(u,x',t')
> > > 3. if x eq. x', and r eq. r', then we say that f is
> > idempotent, where eq.
> > > stands for "is equivalent to".
> > > This idempotent def is different than the one in math.
> > >
> > > Is this summary good enough?
> >
> > It's not clear enough.  When you say "sending a request", and having
> > that be idempotent, what is the thing that has identity?  If
> > it's a message,
> > then the above summarizes RM.  If it's a "deposit", then the above
> > summarizes an application level coordination.
> >
> > Thanks,
> >
> > Walden
> >

Received on Thursday, 16 January 2003 16:55:24 UTC