From a runtime point of view it is advantageous to have stateless services. Statelessness - from a conceptual point of view -- means that the service does not "remember" state between consecutive invocations. Of course, the service may still store information in the DB backend. The important point, however, is that this state is not within the service instance or the service volatile memory.
Clearly, stateless services do scale better: Additional instances of the service can be fired up to cope with increased load. They can also deal better with failover situations. A client request may be routed to an alternative instance transparently when the original instance goes down.
However, sometimes stateful services do make sense from a modelling perspective. Nicolai Josuttis, for example, describes a shopping cart service. For this type of service, a client would expect to successively call operations to add new items.
A stateful service may be implemented as a stateless service: either by sending all relevant information (eg the shopping cart contents) with every request or by sending a session ID with every request and keeping the shopping cart contents in the DB. Or a "real" stateful service keeps the shopping cart state in memory - this requires session affinity: ie, each successive request by a given client must be routed to the same service instance. When this instance goes down, the user must start their shopping trip all over again -- possibly an acceptable tradeoff in an eCommerce application. Nicolai Josuttis works out the associated tradeoffs (state in frontend, state in service, state in backend) really nicely in his book (p.195).
6 comments:
State can also be saved in a database or another kind of storage outside the service. It would be considered state if it is not permanent. This is referred to as using a State Repository http://www.soapatterns.org/state_repository.asp
I agree - a "stateful" service could become temporarily "stateless" by swapping out operational state into the DB according to http://www.soaprinciples.com/service_statelessness.asp.
I wonder: would the service then benefit from the failover and scalability advantages of stateless services?
Not as much as a true stateless service, but it scales OK. To scale even more you can scale the state repositories as well - but then you have data in multiple places.
And when that happens you should beware of CAP! http://www.infoq.com/news/2008/01/consistency-vs-availability
Is the output of one state which is given to user can also be used by user again for some other query to service.
Is these state information is reusable by customer?
I stumbled on this piece - very good explanation. I think in the end it might depend on which flavor of statefulness is less expensive - the I/O requirements of using the database as the instance's memory, or allocating enough buffer for the stateful instance that no data hits the external DB until the transaction is complete. Interesting topic, though.
I think it's quality who expresses for your statement. It happens sometimes that the words and the work are not same though it belongs to any reputed company. It's all because we human beings have limited authority to do all. And being human we should realize all the statement very well.
Post a Comment