RE: Stateful Web Services...

Mark --

I'm just not getting your point.  The article you refer to says state is
hell, yes, and I don't think there is a single contributor to this thread
who would disagree.  We are all familiar with the problems cited -- the
complexities of caching, SPOFs, the difficulties of replication, resource
management, etc.  But even this article says there are times when there must
be state behind the server.  In our case everything we do involves state
behind the server.  And I have not seen anything in this thread that
explains how we can relieve servers of the burden of maintaining
(persisting, if you want reliability) state short of passing all of the
information required for an interaction back and forth between client and
server, which I know you have said you do not mean.

So -- servers will have state.  And we (meaning the IT side of my firm) do a
lot of work specifically to address issues such as reliability and
scalability because servers have state.  We do use caching.  We do use
replication.  We explicitly manage resources.

But -- we a lot of this happens because there is no standard way of
maintaining a reference to the state between client and server.  If there
was such a way then it would be possible to develop standard mechanisms in
the infrastructure to help with caching, replication, resource lifetimes,
etc.  (BTW -- I think this all is about the architectural property of
visibility you are such a strong proponent of -- I think it might fair to
say that defining a standard means for identifying resources required by a
stateful server is a way of giving visibility to that dependency.)

As it is, only our implementations can interpret the references we use.  So
it is up to us to develop solutions to these problems -- and I rather be
building trading systems, myself.

As an example -- there was a reference earlier in this thread to stateless
session beans.  There is another kind of session bean -- a stateful session
bean.  Now, stateful session beans run into the problems you've talked
about, and it is very accurate to say that they are not used as often as
stateless session beans.  But not for the reason you might think -- the
reason is that vendors have indeed provided solutions to many of these
problems (replicating state, for example), but these solutions are
non-standard and vendor-proprietary.  So IT shops are afraid of vendor
lock-in.  So they don't use these features.  Instead, they use stateless
session beans, but wind up implementing all of the facilities of a stateful
session bean behind those stateless session beans.  But it's their own
solution, and they are not locked into a vendor.

What I think WS-RF *(and OGSI before it) is about is defining a standard
convention for providing these references to state.  And, yes, that could be
passed in a WS-Context, so WS-Contest is relevant, it's just not a complete
answer.  You need a way to talk about what WS-RF calls Resources.  And then
the vendors can go to work on soft state management, caching, replication,
and the like (actually, they're working on it and in some cases delivering
it already).

Chalon Mullins
Technical Director, Infrastructure Strategy and Architecture
Charles Schwab & Co., Inc.
SF211MN-08-472
101 Montgomery St
San Francisco, CA 94104
phone:  (415) 667-1117


-----Original Message-----
From: www-ws-request@w3.org [mailto:www-ws-request@w3.org] On Behalf Of Mark
Baker
Sent: Wednesday, November 03, 2004 6:11 PM
To: Walden Mathews
Cc: www-ws@w3.org
Subject: Re: Stateful Web Services...


Hey Walden,

On Wed, Nov 03, 2004 at 06:55:48PM -0500, Walden Mathews wrote:
> That is certainly confusing, but the underlying concepts are not
> that clear either, and there's a bigger problem there, I think, in terms
> of understanding scaleability tradeoffs.
> 
> Here's a stateful interaction:
> 
> C: How much is a ticket from NYC to Boston on the 20th?
> S: $50.
> C: How much is it round trip?
> 
> The "stateless server" principle says that for the server to be able
> to answer the client's second question, it has to sacrifice some
> ability to service larger numbers of clients.
>
> However, if instead of the above, the client posts an incomplete
> order for a ticket, the server creates a resource
> from that, and the client can then complete the order via reference
> to that resource, you technically have a "stateless interaction",

No, you wouldn't, because as you say, the second message would contain a
reference to the resource, but the semantics of that message - if it's
to provide the same expectation as the second message above - would be a
function of the state of that resource.

Who said "State is hell"[1]?  Easy as pie. 8-)

 [1] http://www.artima.com/intv/distrib4.html

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Received on Thursday, 4 November 2004 15:52:19 UTC