8

I have a need for a stateful webservice in our organization. However, everywhere I read online says that building a stateful webservice is bad programming but nothing ever says why. I guess I don't understand what is so bad about it. I also don't really understand why they would give a work around to allow you to have state in a webservice.

So I guess that my question is, why is it bad programming to use a stateful webservice and why would it be allowed?

Cœur
  • 37,241
  • 25
  • 195
  • 267
Justin Balvanz
  • 1,186
  • 3
  • 12
  • 19
  • 2
    I'd look at this in a different way--what does this service need to do that is stateful? Can that be creativly smoke and mirror'd? – Wyatt Barnett Jun 12 '09 at 20:16

3 Answers3

17

The whole purpose of a web service is to deliver a piece of functionality in one transaction in a way that is highly scalable. This means keeping things simple and atomic.

When you have to make multiple calls to perform the operation, you have a great potential of leaving transactions hanging. Is the client coming back? Are they done? How long should the transaction remain open? Did they crash? How should rollbacks be handled?

The answers to these questions could have a radical impact on the resources necessary to run your service. Which is why everyone recommends doing it all in one swoop.

NotMe
  • 87,343
  • 27
  • 171
  • 245
  • 3
    Excellent answer! Also, if your operation is stateful, what happens if the server fails? (And it will. That's why we run clusters of servers.) All state will be lost. Stateless allows you to resubmit the request to the next server in the cluster as if nothing happened. – Devon_C_Miller Mar 16 '12 at 10:48
  • 2
    Not at all true. Web Services are about a common market-wide integration technology between remote applications. Most of them are stateless because most of operations we deal with are stateless... Your answer may mislead people in using multiple stateless services when actually a stateful approach is the correct one even considering the non-functional aspects inherited with it. – Evandro Pomatti Oct 29 '15 at 17:25
9

Here are some reasons I can think of:

  1. The cost of maintaining state will have to be borne server side only - service consumers are rarely web browsers, so have no cookies. This brings down your server performance and increases your design complexity.

  2. A service consumer is an intelligent program, rather than a dumb browser. As such the program will (almost always) maintain its own state. In other words, when you provide a service, your consumer will request precisely the data it wants. Maintaining state on the server becomes obsolete and unnecessary.

  3. Transactions - a service is a dangling point in your system because its clients are mostly intelligent, and they decide when to inform you of changes in their state. This means that if you maintain state, you might have to wait between service calls to finish a transactional operation. And there's absolutely no guarantee the client will ever make that next service call.

There are a lot of reasons, but these are the ones I can think of off the top of my head :)

Metro Smurf
  • 37,266
  • 20
  • 108
  • 140
Sudhir Jonathan
  • 16,998
  • 13
  • 66
  • 90
-2

I think it is a kind of myth

If google can make their stateful web application scalable, then why cant we scale a stateful webservice. It is all about the app server which reduces the scalability.

Even with a website or webservice, ultimate aim is to serve better. If a "stateful" is to improve your service, then don't hesitate to go with that.

Webservice guy
  • 5
  • 1
  • 2
    You might want to clarify on which part of google you are talking about. The main google.com is not "stateful". – NotMe Jul 10 '12 at 21:51