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;
- Rewriting (or writing adapters to expose) legacay apps to use messages
that are either safe or idempotent.
- A business process, transaction processing, or choreography layer that
handles all reliability issues as well as the application-level semantics of
cooperative distributed processing.

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 11:11:19 UTC