Why are Web Services Stateless ?

Web Services are not supposed to hold state between calls. Web Services address a branch of architecture which is called the Service Oriented Architecture (SOA). By definition, SOA is based on applications exposing services for other applications or users to consume. When we talk about services, we referrer to an atomic unit of consumable service. In a typical scenario, web services are implemented at a use-case level. A service Façade layer would be introduced over the business layer (sometimes over the business façade). This service façade would be exposed as the service layer (as web service calls). Each service exposed (method in your web service) is meant to be atomic – the service should take in all the details that would be required to invoke the all business functionality in the right sequence. And hence you don’t have the concepts of state sharing. You may now ask how transactions can be maintained across web service calls! Web service transactions is not yet supported – several standards are being proposed but it’s actual implementation is far off.
In conclusion,
1. You should design your web service in such a way that it does not require to share state between calls.
2. In the worst case, your application should take care of data management by persisting data in the database. State sharing should not be considered.

Technically, speaking… Because Web Services uses the stateless HTTP Protocol, Web Services by default does not support state. Yet you can do this by building additional logic in your code.