RE: Stateful Web Services...

Exactly.  My company's literature says "can" and "where appropriate".
Which is what I am saying.  Now arguably our docs (and probably almost
everybody else's) ought to provide more guidance on "where appropriate".


The argument for using stateless ejbs is the same as stateless web
services.  The container can freely pool instances and allocate
instances as needed.  That increases scalability in some cases but not
others.  

I would say that the keys to the stateful vs stateless component design
wrt scalability is based on the following:
1. cost of sending state to client, which includes network traffic and
process creation/cleanup on server
2. cost of migrating state from one node to another.
3. cost of dispatch to stateful versus stateless node.
4. cost of passivating state to persistent store, which includes network
traffic to back-end and process creation/cleanup on server

Imagine if Amazon were built in a truly stateless manner.  The cost of
sending the entire state of my interactions with amazon (my wishlists,
previous orders, previous viewed, credit card info, etc.) to and from
the client could be very high for large data sets.  In such cases it is
more performant from a client perspective for the server to passivate
the state to a back-end db if it needs.  Reducing the cost to the server
of the network traffic/transmissions, the time the process owns the cpu
etc. can increase scalability.  There's always trade-offs between
scalability because of i/o bound versus cpu bound interactions.  

There have been advances in giving servers the freedom to manage
resources how and when it sees fit.  The notion of state being indelibly
"pinned" to a particular node hasn't been used in most real app servers
for a few years.  The server can dynamically move state from machine to
machine as it sees fit, such as for management or perf reasons.  

Finally, the cost of routing dispatches has dropped significantly.  The
cost of a lookup in a dispatcher based on a session id and then
forwarding to the right node (even if the node has moved for previous
reasons) is now basically statistically insignificant compared to a
stateless invoke.  

So there are trade-offs to be made in the decision, which will
definitely include the particular vendor's implementation of a
container.  One vendors impl of stateful container might be
significantly worse than another's implementation.   Check out the
jAppServer2002 benchmarks for some ejb comparisons.  

Cheers,
Dave

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Tuesday, November 02, 2004 1:49 PM
> To: David Orchard
> Cc: www-ws@w3.org
> Subject: Re: Stateful Web Services...
> 
> On Mon, Nov 01, 2004 at 10:22:37PM -0800, David Orchard wrote:
> > Needless to say, Roy's claim is not backed up by any references so
my
> > claim is just as valid on the face of it.
> 
> I wouldn't say that.  Roy backed up his claim by describing exactly
how
> scalability was negatively impacted; by giving the server more freedom
> to manage its own resources how and when it sees fit.  If you know of
> some means by which that problem can be eliminated (effectively or
> actually) with stateful services, I'd really(!) like to hear it since
> Roy's explanation jives with my experience.
> 
> >  Also, my company does ship
> > software that deals with high reliability and scalability systems so
we
> > do know a thing or to.
> 
> Apparently! 8-)
> 
> "EJB Providers can increase application scalability by using stateless
> session beans wherever appropriate. With stateless
> session beans, the WebLogic Enterprise EJB container can freely pool
> instances, allocate instances as needed, and apply lo
> ad balancing strategies to distribute the load across different
servers
> within the domain."
>  -- http://e-docs.bea.com/wle/tuning/tsejb.htm
> 
> Of course, load balancing can occur even with stateful services, so
long
> as some part of the message uniquely references the shared contextual
> state.  But the other advantages seem specific to stateless services.
> 
> Cheers,
> 
> Mark.
> --
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Received on Tuesday, 2 November 2004 22:09:58 UTC