How good and/or necessary are Stateful Web Services?

Question

What kind of server do you people see in real projects?

1) Web Services MUST be stateless: Basically you must send username/password with every request, every reques

Answer 1

While it's only a small difference but it should still be mentioned:

It's not state in web services that kill scalability, rather it's state on the App Server that's hosting the web services that will kill scalability. The moment you say that this user needs to access this server (as done in sticky sessions) you are effectively limiting your scalability options. The point you want to get to is that 'Any of your free load-balanced App servers' can handle this web service request and if I add 1 more App Server I should be able to handle % more users.

It's totally fine (and personally recommended) if you want to maintain state to pass in an authentication token and on each request get the service to retrieve your 'state' from a data store (preferably a redundant and partitioned one, e.g. distributed+replicated key/value data store). That's how Amazon does it with SimpleDb and Google with BigTable.

Ebay takes a slightly different approach and stores most of the clients state in a cookie so it gets passed in with every request. Although it generates a lot more traffic, it still scalable as any of their servers can still handle the request.

If you want a scalable data store I would recommend looking at redis it has speed and features that can't be beat in a key/value data store.

You should also check out highscalability.com if you want access to good material on how to build fast and scalable services.

Answer 2

Ideally webservices (and web sites) should be stateless.

Unfortunately this takes very well thought out problem domain, and clear separation of concerns.

I've found that in practice most real-world web sites depend on state even though this limits their scalability.

I've also found that many real-world web-services also rely on state.

Ultimately the 'right' decision is the one that works for the specific problem, so it's probably okay to write a webservice that relies on state, and refactor it later if scalability becomes an issue.

Answer 3

Highly dependent on whether the service is single transaction oriented (say getting stock quotes) or if the output from the service is dependent on a data provided from a particular client across multiple transactions(in that case state must be maintained.)

As far as scalability issues, storing state in a database isn't actually a bad way to go (in fact it's probably the only way to go if you're load balancing your service across a server farm.)

Answer 4

I think with Flex clients the state is moved out of the service and into the client tier. Keep the services stateless and let the clients maintain the state needed. The services stay simple, and the clients are free to mash them together as they wish.

Answer 5

You seem to be equating state and authentication. Perhaps you're accustomed to storing username and password in session state?

This is not necessary, even with old ASMX web services. Simply pass whatever information you need to your "Login" operation. This operation will be defined to return an "Authentication Ticket" header.

All other operations that require authentication will require this "Authentication Ticket" header. They will each check the header to see if it represents a valid, authenticated user. If so, then they will perform their task. If not, then they will return a SOAP Fault indicating that authentication is required.

No state is required. Simply make sure that the authentication ticket can be validated on any server your service runs on (for instance, in a web farm), and you'll be fine.