Clemens' talk was about managing state across multiple layers within a .NET application. His message was that there are many types or state and many approaches to dealing with it. It's not just about the ASP.NET session object! He covered a definitions of services, state and its types as well as how to manage state including transactions.
Statelessness doesn't really exist
Stateless doesn't really exist. Everything is stateful when it runs. Just because a component doesn't remember anything across calls doesn't mean there isn't a state penalty. Keeping information on the stack is a way of maintaining state.
Definition of services
A service is autonomous -lives and can be deployed by itself.
A service has its own store. It might be as system with 20 modules having 20 databases.
A service is not XML and SOAP. This is just one way of talking to services.
Services shouldn't share databases
One of the gems I picked up from the talk was that we shouldn't necessarily tightly couple everything at the database layer by putting it all in one place. Sometimes this is done for speed, but the benefit may disappear if you put it in a cluster.
Martin Fowler posted about this today:
The recent rise of Service Oriented Architecture seems to mean very different things to different people, but one plausible thread is a rise of autonomous applications with their own ApplicationDatabase that communicate through service interfaces - effectively replacing shared database integration with rpc or messaging based integration. I'm very sympathetic to this view, particularly favoring integration through messaging - which is why I encouraged the development of EIP. In this view of the world the integration database is no longer the default assumption.
What is state?
All the data an application needs to remember. It can be:
- volatile (the stack manages volatile state)
- transient (a stock ticker)
- permanent.
Transient state may contain useful data
Clemens mentioned that transient data may contain useful data that is worth storing. An example is the contents of a shopping cart at an online store. Keeping this data can provide useful information about the behaviour of people on a site (how many don't complete an order?).