Resource Oriented Architecture - Part 2 (Statelessness)

The idea of writing a web service was that you should have a contract to work against. The policy, address etc. to invoke the implementation of this contract can be figured out at runtime. A component on remote machine will process my input and get back to me with some output based on the design time contract which i programmed against.

Now this works great once i take a look at the tools which are available to me as off today ... I've a WCF framework based on which i can define my operation contracts, message contracts, data contracts etc. in the code and the security policy, binding and address on which i want to expose my contract can be decided at the time of deployment in a configuration file. The best part is that in most cases i do not even need to care that i am writing a service which would be used from a remote client.. since even the things likes session management etc. can easily be handled by the framework. I feel like i am almost doing OOPS based programming. However if i do use the Session in my service an additional overhead has been added to the service infrastructure of maintaining this session. Which means that i put the scalability challenges in my code. Because to support Session i've to use Session Affinity or and Out of Process Session Management both of which are not very bright ideas for scaling out the application.


The World Wide Web is a very scalable architecture and one of the reasons for that is its statelessness.
Let's try to understand what statelessness means for an application....
In any application we write there are 2 states i.e. state of the client and the state of the resource which the client is asking for. When we walk about statelessness we mean that the server should only be concerned about the state of the resource it is serving to the client. It should not be concerned about the state of the client. e.g. when i type a url http://www.google.co.in/search?q=ROA&start=80 in my browser google returns me the result for my query ROA starting with result no. 80 i.e. page 9. It doesn't care whether i clicked on last 8 pages or not because that is the state of the client. The state of the resource is present on the server and is being served no matter what is the state of the client querying for it is.

While designing a resource oriented application we should be very clear in defining what is the resource that we're exposing, what is the state of the resource and what can be classified as client state. Then we should ensure that the client state is maintained by the client and sent to the server when needed in some form (most as part of URL. Wait till my post on addressability and uniform interface).

~Abhishek