Reliable Sessions Overview
Windows Communication Foundation (WCF) SOAP reliable messaging provides end-to-end message transfer reliability between SOAP endpoints. It does this on networks that are unreliable by overcoming transport failures and SOAP message-level failures. In particular, it provides session-based, single, and (optionally) ordered delivery for messages sent across SOAP or transport intermediaries. Session-based delivery groups messages in a session with optional ordering of the messages.
The following discussion discusses what a reliable session is, how and when to use it, and how to secure it.
WCF Reliable Sessions
WCF reliable sessions is an implementation of SOAP reliable messaging as defined by the WS-ReliableMessaging protocol.
WCF SOAP reliable messaging provides an end-to-end reliable session between two endpoints, regardless of the number or type of intermediaries that separate the messaging endpoints. This includes any transport intermediaries that do not use SOAP (for example, HTTP proxies) or intermediaries that use SOAP (for example, SOAP-based routers or bridges) that are required for messages to flow between the endpoints. A reliable session channel supports "interactive" communication so that the services connected by such a channel run concurrently and can exchange and process messages under conditions of low latency, that is, within relatively short intervals of time. This coupling means that these components make progress together or fail together, so there is no isolation provided between them.
A reliable session masks two kinds of failures:
SOAP message-level failures, which includes lost or duplicated messages and messages that arrive in a different order from the order in which they were sent.
Transport failures.
A reliable session implements the WS-ReliableMessaging protocol and an in-memory transfer window to mask SOAP message-level failures and re-establishes connections in the case of transport failures.
A reliable session provides for SOAP messages what TCP provides for IP packets. A TCP socket connection provides a singular, in-order transfer of IP packets between nodes. The reliable channel provides the same type of reliable transfer, but it differs from TCP socket reliability in the following ways:
The reliability is at the SOAP message level, not for an arbitrarily sized packet of bytes.
The reliability is in a transport-neutral manner, not just for transfer over TCP.
The reliability is not tied to a particular transport session (for example, the session a TCP connection provides) and can use multiple transport sessions concurrently or sequentially over the lifetime of the reliable session.
The reliable session is between the sender and receiver SOAP endpoints, regardless of the number of transport connections required for connectivity between them. In short, TCP reliability ends where the transport connection ends, whereas a reliable session provides end-to-end reliability.
Reliable Sessions and Bindings
As mentioned earlier, a reliable session is transport neutral and as such can be implemented over many transports. Also, a reliable session can be established over many message exchange patterns, such as request-reply or duplex. The WCF reliable session is, therefore, exposed as a property of a set of bindings.
You can use a reliable session on endpoints that use:
HTTP-based transport standard bindings:
WsHttpBinding and expose request-reply or one-way contracts.
Can be used when using reliable session over a request-reply or simple one-way service contract.
WsDualHttpBinding and expose duplex, request-reply, or one-way contracts.
WsFederationHttpBinding and expose request-reply or one-way contracts.
TCP-based transport standard bindings:
- NetTcpBinding and expose duplex, request reply, or one-way contracts.
You can also use a reliable session on any other bindings by creating a custom binding, such as HTTPS (for more information about issues, see the "Reliable Sessions and Security" section later in this topic) or a named pipe binding.
A reliable session can be stacked on different underlying channel types and the resulting reliable session channel shape varies. On both the client and the server, the type of reliable session channel supported depends on the type of underlying channel being used. The following table lists the types of session channels supported on the client as a function of the underlying channel type.
| Supported reliable session channel types (supported values of TChannel given an underlying channel type) | IRequestChannel | IRequestSessionChannel | IDuplexChannel | IDuplexSessionChannel |
|---|---|---|---|---|
IOutputSessionChannel |
Yes |
Yes |
Yes |
Yes |
IRequestSessionChannel |
Yes |
Yes |
No |
No |
IDuplexSessionChannel |
No |
No |
Yes |
Yes |
The supported channel types are the values available for the generic TChannel parameter value that is passed into the BuildChannelFactory method.
The following table lists the types of session channels supported on the server as a function of the underlying channel type.
| Supported reliable session channel types (supported values of TChannel given an underlying channel type) | IReplyChannel | IReplySessionChannel | IDuplexChannel | IDuplexSessionChannel |
|---|---|---|---|---|
IInputSessionChannel |
Yes |
Yes |
Yes |
Yes |
IReplySessionChannel |
Yes |
Yes |
No |
No |
IDuplexSessionChannel |
No |
No |
Yes |
Yes |
The supported channel types are the values available for the generic TChannel parameter value that is passed into the BuildChannelListener method.
Reliable Sessions and Security
Securing a reliable session is important to ensure that the communicating parties (service and client) are authenticated and the messages exchanged in the session are not tampered with. Furthermore, it is important to ensure the integrity of each individual reliable session. A reliable session is secured by binding it to a security context that is represented and managed by a security session channel. The security channel provides a security session. Security tokens exchanged during the session establishment are then used to secure the messages in the reliable session.
When reliable session is over TCP-S, the TCP session is tied to the reliable session and, as such, transport security ensures that security is also tied to the reliable session. In this case, connection re-establishment is turned off.
The only exception is when using HTTPS. The Secure Sockets Layer (SSL) session is not bound to the reliable session. This imposes a threat because sessions that are sharing a security context (the SSL session) are not protected from each other; this might or might not be a real threat depending on the application.
Using Reliable Sessions
To use WCF reliable sessions, create an endpoint with a binding that supports a reliable session. Use one of the system-provided bindings that WCF provides with the reliable session enabled, or create your own custom binding that does this. The system-defined bindings that support and enable a reliable session by default include:
The system-provided bindings that support a reliable session as an option but do not enable one by default include:
For an example of how to create a custom binding, see How to: Create a Custom Reliable Session Binding with HTTPS.
For a discussion of WCF bindings that support reliable sessions, see System-Provided Bindings.
When to Use Reliable Sessions
It is important to understand when to use reliable sessions in your application. WCF supports reliable sessions between endpoints that are active and alive at the same time. If your application requires one of the endpoints be unavailable for a duration of time, then you can use queues to achieve reliability.
If the scenario requires two endpoints to be connected over TCP, then TCP may be sufficient to provide reliable message exchange, although it is not necessary to use a reliable session; TCP ensures that the packets arrive in order and only once.
If your scenario has any of the following characteristics, then you must seriously consider using a reliable session:
SOAP intermediaries, such as SOAP routers.
Proxy intermediaries or transport bridges.
Intermittent connectivity.
Sessions over HTTP.