In order to enable a custom management of a WCF session, the service contracts have to be decorated with the following attribute: [ServiceBehavior(AutomaticSessionShutdown=false)]. By default the session will be terminated when the WCF call is completed. When a session is established between a WCF service and a client, all client calls are handled by same WCF instance. WCF supports the following types of sessions behaviors:
- System.ServiceModel.Channels.SecurityBindingElement (supports security based sessions)
- System.ServiceModel.NetTcpBinding (supports TCP/IP sessions)
- System.ServiceModel.Channels.ReliableSessionBindingElement (supports reliable sessions)
- System.ServiceModel.NetMsmqBinding (supposrts MSMQ datagram sessions)

BasicHttpBinding defines a binding used by WCF to configure and expose endpoints which provide compatibility with ASMX based services and clients, or to any other type of services which comply with WS-I Basic Profile 1.1. It makes use of HTTP transport protocol to deliver SOAP 1.1 messages. BasicHttpContextBinding provides same functionality as BasicHttpBinding but with some extras. It ensures that the WCF service exposed through this endpoint biding is compatible with ASP.NET session state features.

Recently I have been involved and project which required a web service layer to allow various clients to communicate with our business end.
For this WCF was as always the perfect candidate :D. The service layer had to support both SOAP and REST protocols; for validation of the requests Microsoft Enterprise Library Validation Block was used, having the DTO object decorated with the appropriate validation attributes. All worked fine for SOAP request, if the wrong data was present or if the data was missing from the DTO sent in the request a fault message was generated and sent to the client. But issues appeared with REST request, no validation being triggered and not exception thrown on the WCF service level to point out the issue. After searching on the internet for couple of minutes the solution popped up:

Microsoft.Practices.ServiceLocation.dll
Microsoft.Practices.Unity.dll
Microsoft.Practices.Unity.Interception.dll

Where missing from the WCF service project references. Adding the above mentioned DLLs solved the issue.