Sessions in Windows Communication Foundation Applications

When a service contract specifies that it requires a session, that contract is specifying that all calls (that is, the underlying message exchanges that support the calls) must be part of the same conversation. If a contract specifies that it allows sessions but does not require one, clients can connect and either establish a session or not establish a session. If the session ends and a message is sent through the same channel an exception is thrown.

WCF sessions have the following main conceptual features:

* They are explicitly initiated and terminated by the calling application.

* Messages delivered during a session are processed in the order in which they are received.

* Sessions correlate a group of messages into a conversation. The meaning of that correlation is an abstraction. For instance, one session-based channel may correlate messages based on a shared network connection while another session-based channel may correlate messages based on a shared tag in the message body. The features that can be derived from the session depend on the nature of the correlation.

* There is no general data store associated with a WCF session.

If you are familiar with the System.Web.SessionState.HttpSessionState class in ASP.NET applications and the functionality it provides, you might notice the following differences between that kind of session and WCF sessions:

* ASP.NET sessions are always server-initiated.

* ASP.NET sessions are implicitly unordered.

* ASP.NET sessions provide a general data storage mechanism across requests.

This topic describes:

* The default execution behavior when using session-based bindings in the service model layer.

* The types of features that the WCF session-based, system-provided bindings provide.

* How to create a contract that declares a session requirement.

* How to understand and control the creation and termination of the session and the relationship of the session to the service instance.