RE: Stateful Web Services...

> 
> I am asserting that stateful services may scale better than stateless
> services.  I'm not making any claim about stateful or stateless
> messages.
> 
> I believe that web applications are regularly built using stateful
> services (where the state resides upon the server) and stateless
> messages (where the the state id is in the message).
> 

By "stateless messages" I guess you refer to "stateless interactions".

> The multi-partner interaction is an example of where stateless service
> won't work at all.   The service will have to coordinate the many
client
> interactions and the state necessary for that is on the server.
Whereas
> Web browsing is typically a single client talking to a single instance
> of a service.
> 

I personally think that it is in multi-partner interactions where
stateless interactions are better than the direct exposure and
management of state beyond service boundaries. WS-Context is an example
of how state can be put on the wire (please note that I am not
suggesting that ALL state is transferred but only the information
necessary for partners to reconstruct their state machine related to a
particular interaction).

Also note that in many cases the above view has been misinterpreted as
suggesting that services are not allowed to internally maintain state.
This is far from the truth. Google and Amazon maintain huge amounts of
state. However, it doesn't matter to which service endpoint you reach to
get access to the Google or Amazon web applications.

As I mentioned in a previous message, businesses around us work and
scale through the implementation of stateless interactions. Our banks
don't give us a personal telephone number at the end of which there is
going to be a single person that remembers our account details. We call
first, a person is allocated to us and we establish a context of
interaction with that person by giving our account number and going
through the security checks.

> On a simple client/server interaction, there may be scenarios where
the
> state size is very large compared to the network.  It may scale better
> to have the state shuffled to disc rather than across the network if
the
> back-side of the state is easier to augment than the front-side.
> 

There is no argument here. No one suggested that the entire state moves
back and forth. However, the state is not directly associated with a
particular service endpoint. When I login in my Amazon account, I don't
have to send them all the information about the products that I have
bought already. They know what I have bought and they can tell me.
However, I first had to establish an interaction context with them. 

> There are many others as Roy mentions.  I could get into the aspects
of
> RM, security token authorization, asynch and how they relate to
> scalability, but the point is that state assignment gets down to the
> trust or care that the server has wrt clients.  The more it dumbs down
> it's client expectations, the more the server will do, such as
managing
> state.
> 

The server/service is of course responsible for managing state. There is
no argument there. It's whether the state is directly exposed and
consumers are allowed to bind to it, which will result into distributed
state management issues.

Regards,
.savas.

Received on Friday, 29 October 2004 23:16:05 UTC