Reliability in WCF

In WCF, Reliability can be broken down into two distinct areas of functionality, Reliable Sessions and Queued Messaging. Each of these applies to scenarios with certain characteristics, which we will delve into in the next two sections of the chapter.

Reliable Sessions

In the world of TCP/IP, reliability and the issues discussed earlier in the chapter are handled by the protocol. WCF's Reliable Sessions provide that same functionality for SOAP messages.

Specifically, the reliable channel provides the capability to handle three of the potential scenarios that can lead to unreliability:

• Lost messages

• Duplicated messages

• Messages received out of order

Although WCF and TCP/IP may both handle these reliable messaging challenges, WCF goes about it in a different way. SOAP is defined to allow the use of multiple transportssome of which are not inherently reliable. In addition, between Endpoint A and Endpoint B, WCF messages can travel across multiple intermediaries and across multiple protocols. To accommodate all of this, WCF handles these issues at the message level.

In instances in which a client has gone silent in a session beyond a designated time, the server will free up resources associated with that session. Reliable Sessions will also help manage network congestion, adjusting the rate at which the server sends out messages.

Queued Messaging

The WS-Reliability specification contains specific guarantees that combine to form the requirements of reliable messaging. For those who have read the specification, you'll see that there is something noticeably absent from it, specifically rules around durability. More to the point, the WS-RM specification has no requirements for endpoints to place messages in a durable store at any point in the conversation.

The reality is that the specification as it stands today does not have any requirements in this area. Although the industry will possibly address this in a future iteration of the WS-* specs, this does not necessarily eliminate the need to provide durability in a number of scenarios.

In WCF v1.0 this can be accomplished using queues. Queues store messages from a sending application on behalf of a receiving application. The receiving applicationat some point after the message has been placed on the queuereceives the message. Queues ensure reliable transfer of messages from sending applications to receiving applications. Queuing is supported in WCF through the use of Microsoft Message Queuing (MSMQ) transport.

Queued messaging can be done in scenarios in which WCF integrates with an existing non-WCF MSMQ application, as well as in situations in which client and server are using WCF for communications. This chapter focuses on the WCF-WCF scenario, and integration is handled in a later chapter.

When you remove the need for client and server to communicate in real-time and use a queue as a midpoint, a number of opportunities are provided.

This loose coupling helps avoid issues if the sender or receiver applications fail. When using services in real-time request-response patterns, if the receiver suffers a failure and is offline for a significant period, the client also is offline. New and existing work is stalled as a result. When using queues in this same scenario, the sender will happily send to his queue and business will continue to function. Once the receiver application is back online, she will begin processing messages again. This failure isolation provides increases in availability and reliability.

The same holds true for scenarios in which both the sender and the receiver are online, but network connectivity between the two becomes unavailable. There is no dependency on the server being available, allowing for applications to exist when no connectivity is present. After the connectivity is restored, the receiver happily receives the messages from the queue for processing.

In addition, because the application is not sending messages across the network, potential blocking that might result due to the speed and reliability of connectivity between sender and receiver are limited.

For the receiver, this helps avoid becoming overwhelmed, as a result of being forced to handle large spikes of message traffic. The use of queues provides the capability for the receiver to manage the rate at which it processes messages, regardless of the speed and volume of messages sent from the sender.

The use of queues also provides benefits in the production environment, as the management interface used is the standard MMC snap-in already used by MSMQ. From the perspective of the individuals who need to support a Queued Messaging scenario, this is ideal because it does not require new training and leverages any existing knowledge of MSMQ.

When to Use Reliable Sessions and When to Use Queued Messaging

Both Reliable Sessions and Queued Messaging have compelling features, and you may be wondering which one is right for your particular project. This varies on the requirements of the project, but the intent of this section is to provide some guidance on how to make that determination.

Reliable Sessions should be used in scenarios in which it is likely that client and server will be online and connected to the network at the same time. In that environment, Reliable Sessions provide the functionality to overcome failures at the transport level (that is, loss of network connectivity due to wireless, dial-up, or VPN) and the transport intermediary level (that is, the Web proxy), as well as the SOAP intermediary level (that is, SOAP router).

Queued Messaging really makes sense for those scenarios in which the business does not require real-time interaction with services and it is desirable to be able to work offline. Regarding Reliable Sessions, it was stated that they were ideal for scenarios in which both client and server are online at the same time. When there is no guarantee that the client and server will be online at the same time, and a more loosely coupled approach is desired, Queued Messaging is a good option for you.