Maintaining state in an Indigo service

re: Maintaining state in an Indigo service

harry — Wed, 31 Aug 2005 10:34:18 GMT

Isn´t it one of the major principles of soa, that services should always be stateless? Therefore: different calls of a service operation should not depend on each other. If there´s state (and I think there´s always some kind of state) the database is the right place for it. The interface of the service operation should care that it contains all the parameters that are necessary to access the state. If there´s a situation where different operations depend on a common session state, try to encapsulate them in a (coarser grained) service.

Serendipitous, Indeed

Message for you, sir! — Sun, 04 Sep 2005 21:19:29 GMT

re: Maintaining state in an Indigo service

Arnon Rotem-Gal-Oz — Mon, 05 Sep 2005 00:28:15 GMT

Also (in addition to Harry's comment)
isn't AddAlbum and (event more so)GetNumberOfAlbums too chatty for a Service interface?

re: Maintaining state in an Indigo service

Eran Sandler — Mon, 05 Sep 2005 09:53:41 GMT

Having state or not having state is more of an implementation decision than a contract decision.

A program that consumes a service of some kind need not to assume anything about the service except the contract the use to communicate.

The sample of sending some kind of an identifier of the session to a web service can be a method that when implemented in the service can actually have state behind it of some kind. Perhaps this state will persist to a database before the method invokation returns and upon the next call (which can get to a different service) will retrieve the state and continue from there on.

You see, this is all about implementation and there is no need for the application consuming the service to assume anything but the contract.

Of course, this doesn't solve the problem of how to build a contract in a right manner that will enable you to switch (if necessary) between a stateful service (of any kind) and a stateless one.