This chapter covers an assortment of facilities that the Windows Communication Foundation provides for making systems more robust. Those features are Reliable Sessions, session management, queued delivery, and transaction flow. Besides introducing each feature, this chapter shows how to use them together to properly implement distributed, transactional systems.

The Windows Communication Foundation’s Reliable Sessions facility is for providing assurances at the binding level that messages will be delivered exactly once, and in order. When communicating with the Transmission Control Protocol (TCP), a measure of reliability is ensured by the protocol itself. However, those assurances are strictly at the packet level and between just two points. The Windows Communication Foundation’s Reliable Sessions feature provides assurances against the possibility of messages being lost in transmission, duplicated, or received out of order, and it provides those assurances at the message level, across any number of intermediate nodes, and independent of the transport protocol. Furthermore, with Reliable Sessions enabled, the Windows Communication Foundation will attempt to re-establish dropped connections, and free the resources associated with a session if attempts at reconnection fail. It will also attempt to compensate for network congestion by adjusting the rate at which messages are sent.

To use the Windows Communication Foundation’s Reliable Sessions facility, one must select a binding that supports it. The predefined bindings that support the feature are the WSHttpBinding, the WSDualHttpBinding, the WSFederationBinding, the NetTcpBinding, and the NetNamedPipesBinding. In the case of the WSHttpBinding, the WSDualHttpBinding, and the WSFederationBinding, the option of using Reliable Sessions is turned off by default, whereas it is turned on by default on the other bindings. Toggling reliable sessions on or off is done by customizing the binding in the usual way:

<system.serviceModel>
        <services>
          <service
                <endpoint
                        binding="wsHttpBinding"
                        bindingConfiguration="MyReliableConfiguration"
                         [...]
                        />
          </service>
        </services>
        <bindings>
          <wsHttpBinding>
                <binding name="MyReliableConfiguration">
                  <reliableSession
                        enabled="true"
                        ordered="true" />
                </binding>
          </wsHttpBinding>
        </bindings>
</system.serviceModel>

The Reliable Sessions facility can also be added to custom bindings by including the binding element, System.ServiceModel.Channels.ReliableSessionBindingElement:

<system.serviceModel>
        <services>
                <service name="[...]">
                        <endpoint
                              [...]
                             binding="customBinding"
                             bindingConfiguration="MyReliableCustomBinding">
                        </endpoint>
                </service>
        </services>
        <bindings>
                <customBinding>
                        <binding name="MyReliableCustomBinding">
                                <reliableSession ordered="false" />
                                <httpTransport />
                        </binding>
                </customBinding>
        </bindings>
</system.serviceModel>

Windows Communication Foundation developers can indicate that their code relies on some assurances about the delivery of messages. In particular, they can specify that they are assuming that the messages will be delivered in the order in which they were sent:

[ServiceContract(SessionMode = SessionMode.Required)]
[DeliveryRequirements(RequireOrderedDelivery = true)]
public interface IMyServiceContract

Adding this specification to a service contract will cause the Windows Communication Foundation to confirm that, for any endpoint that includes the service contract, a binding that supports Reliable Sessions has been selected and appropriately configured to ensure ordered delivery.

The session management capabilities of the Windows Communication Foundation are different from the Reliable Sessions feature. Reliable Sessions are for providing assurances of messages being delivered. Session management allows a Windows Communication Foundation application to treat a message that it receives as part of a session—as part of a unified sequence of messages exchanged with another application.

Therefore, developers of Windows Communication Foundation applications can write the code for processing one message in such a way that it depends on information from an earlier message. If they find themselves having to do that, they can indicate that they are doing so by assigning the value System.ServiceModel.SessionMode.Required to the SessionMode parameter of the System.ServiceModel.ServiceContract attribute:

[ServiceContract(SessionMode=SessionMode.Required)]
public interface IMyServiceContract

Doing so will cause the Windows Communication Foundation to verify that the binding chosen for any endpoint in which that contract is included can support a session and can support incorporating information into the messages to identify the session. The predefined bindings that do so are WSHttpBinding, WSDualHttpBinding, WSFederationBinding, NetTcpBinding, NetNamedPipesBinding, and NetMsmqBinding.

Developers can store and retrieve data pertaining to a session in instance context sessions:

public class MyExtension: IExtension<InstanceContext>
{
        public string sessionIdentifier = null;
        public MyDataType MyData = null;
}
public void FirstRequest(MyDataType myData)
{
        MyExtension extension = new MyExtension();
        extension.sessionIdentifier = OperationContext.SessionId;
        extension.MyDataType = myData;
        OperationContext.InstanceContext.Extensions.Add(myData);
}

public MyDataType SubsequentRequest()
{
        Collection<MyExtension> extensions =
          OperationContext.InstanceContext.Extensions.FindAll<MyExtension>();
        foreach(MyExtension extension in extensions)
        {
                if(string.Compare(
             extension.sessionIdentifier,OperationContext.SessionId,true)==0)
                        return extension.MyData;
        }
        return null;
}

To better manage the resources associated with a session, developers can stipulate which operation may be invoked to initiate a session and which operations signal the end of a session:

[ServiceContract(SessionMode=SessionMode.Required)]
public interface IMyServiceContract
{
        [OperationContract(IsInitiating=true)]
        void StartSession();
        [OperationContract(IsTerminating=true)]
        void StopSession();
}

The assurances provided by Reliable Sessions extend only to the lifetime of the host application domain. If a message is lost en route to its destination but the application domain from which the message was sent terminates before the loss of the message is detected, when the application domain is restored, it will be unaware of the message having been lost. In fact, it will have lost the context of the session in which the message went missing.

The Windows Communication Foundation’s capability of sending messages via Microsoft Message Queuing (MSMQ) queues provides message delivery guarantees that are independent of the lifetime of the sending and receiving application domains. The queues store messages from a sending application on behalf of a receiving application. At some point after the message has been placed on the queue, the receiving application gets the message.

Using queues to convey messages yields a considerable number of benefits. First, if the receiving application is unavailable, perhaps because of an issue with that application or possibly due to a breakdown in connectivity, the sending application can still transmit messages and continue its work. The messages will be held on the queue until the receiving application is ready to accept them. Second, the speed and capacity of the network between the sending and the receiving application is mostly of no consequence, the sole limitation being that MSMQ can only accommodate messages up to 4MB in size. Third, the receiving application cannot be overwhelmed by unanticipated spikes in the frequency and volume of requests. It can consume them from the inbound queue at its own rate. Finally, MSMQ is a familiar technology for most administrators, and a Microsoft Management Console Snap-In is provided with Windows operating systems for them to use in managing MSMQ.

Queues can be used for communication between two Windows Communication Foundation applications, as well as between a Windows Communication Foundation application and a non–Windows Communication Foundation application that uses MSMQ. This chapter focuses on the case in which queues are used for exchanging messages between two Windows Communication Foundation applications. Exchanging messages between Windows Communication Foundation applications and other MSMQ applications is covered in Chapter 11, “Legacy Integration.”

To have a message go from one Windows Communication Foundation application to another via an MSMQ queue, select the predefined NetMsmqBinding:

<services>
        <service name="Fabrikam.TradeRecorder">
                <host>
                        <baseAddresses>
                          <add baseAddress="net.msmq://localhost/private/"/>
                        </baseAddresses>
                </host>
                <endpoint
                        address="EndpointAddress"
                        binding="netMsmqBinding"
                        [...]/>
      </service>
</services>

The absolute address of the endpoint in this example is net.msmq://localhost/private/EndpointAddress. For an endpoint that uses the predefined NetMsmqBinding, the net.msmq scheme is mandatory. The next segment of the address, which in this case is localhost, identifies the host on which the queue resides. The segment private is mandatory if the queue is a private one. The last segment, which is the address of the endpoint itself, must be the name of a transactional MSMQ queue on the specified host.

A service that is configured to receive messages via an MSMQ queue must be deployed on the same machine as the queue itself. That restriction is due to MSMQ allowing remote reads only from nontransactional queues, and the Windows Communication Foundation allowing services to receive messages only via the NetMsmqBinding from transactional queues.

Multiple instances of a service can be configured to receive messages from the same queue. In that case, the most available application will receive the next available message.

When an endpoint is configured with a predefined binding by which messages are received from a queue, the Windows Communication Foundation will confirm that all the operations of the endpoint’s contract are explicitly one-way:

public interface IMyServiceContract
{
    [OperationContract(IsOneWay=true)]
    void FirstOperation(string input);
    [OperationContract(IsOneWay = true)]
    void SecondOperation(string input);
}

The developers of a Windows Communication Foundation application can add an attribute to a service contract to indicate that the developer expects the application to receive messages via a queue:

[ServiceContract(SessionMode=SessionMode.Required)]
[DeliveryRequirements(QueuedDeliveryRequirements
    = QueuedDeliveryRequirementsMode.Required)]
public interface IMyServiceContract

If the developer does so, the Windows Communication Foundation will confirm that the binding of any endpoints that include those service contracts is a binding by which messages are delivered to the service via a queue.

<client>
       <endpoint
                 address="net.msmq://localhost/private$/EndpointAddress"
                 binding="netMsmqBinding"
                 bindingConfiguration="QueuedBinding"
                 [...]/>
</client>
<bindings>
  <netMsmqBinding>
    <binding
     name="QueuedBinding"
     deadLetterQueue="Custom"
     customDeadLetterQueue="net.msmq://localhost/private$/myDeadLetterQueue">
    </binding>
  </netMsmqBinding>
</bindings>

<services>
        <service name="Fabrikam.TradeRecorder">
                <host>
                        <baseAddresses>
                         <add baseAddress="net.msmq://localhost/private/"/>
                         </baseAddresses>
                </host>
                <endpoint
                     address="EndpointAddress"
                     binding="netMsmqBinding"
                     bindingConfiguration="QueuedBinding"
                     [...]/>
      </service>
</services>
<bindings>
  <netMsmqBinding>
    <binding
          name="QueuedBinding"
          receiveRetryCount="0"
      receiveErrorHandling="Fault">
    </binding>
  </netMsmqBinding>
</bindings>

The Windows Communication Foundation implements both the standard WS-AtomicTransaction (WS-AT) protocol and Microsoft’s proprietary OleTx protocol in certain predefined bindings. Those protocols are for conveying information about the state of transactions in messages. Windows Communication Foundation developers can indicate that the code for a given operation is written so as to execute within the scope of a transaction:

[ServiceContract]
public interface IMyServiceContract
{
    [OperationContract(IsOneWay = false)]
    [TransactionFlow(TransactionFlowOption.Required)]
    void MyMethod();
}

public class MyServiceType: IMyServiceConract
{
    [OperationBehavior(TransactionScopeRequired=true)]
    void MyMethod()
    {
      [...]
    }
}

Any operation that the developer indicates must execute within the scope of a transaction cannot also be marked as a one-way method because information about the state of the transaction at the end of the operation must be transmitted back to the caller.

The developer can also indicate that the Windows Communication Foundation should automatically vote on behalf of the operation to commit the transaction if no exception occurs:

public class MyServiceType
{
    [OperationBehavior(TransactionScopeRequired=true,TransactionAutoComplete=true)]
    void MyMethod()
    {
      [...]
    }
}

If the developer would rather vote to commit the transaction deliberately, it can be done via the Windows Communication Foundation’s static System.ServiceModel.OperationContext object:

public class MyServiceType
{
    [OperationBehavior(
      TransactionScopeRequired=true,
      TransactionAutoComplete=false)]
    void MyMethod()
    {
     //Work gets done here
     OperationContext.Current.SetTransactionComplete();
    }
}

If a developer specifies that the operations of a service must execute within the context of a transaction, the Windows Communication Foundation will confirm that the service has been configured with a binding that supports sending information about the state of transactions within messages. The predefined bindings that provide that support are WSHttpBinding, the WSDualHttpBinding, WSFederationBinding, NetTcpBinding, and NetNamedPipesBinding. The last two allow one to choose between using the WS-AT protocol and the OleTx protocol, whereas the others use the standard WS-AT protocol only.

<bindings>
  <netTcpBinding>
    <binding
                name="..."
                transactionFlow="true"
                transactionProtocol="OleTransactions"/>
  </netTcpBinding>
  <wsHttpBinding>
    <binding
                name="..."
                transactionFlow="true"/>
  </wsHttpBinding>
</bindings>

Developers of Windows Communication Foundation clients can use the syntax provided by the System.Transactions namespace to include service operations within the scope of a transaction.

ServiceClient client = new ServiceClient("MyServiceEndpointConfiguration");
using(TransactionScope scope =
        new TransactionScope(TransactionScopeOption.RequiresNew))
{
        client.DoSomething([...]);

        scope.Complete();
}
client.Close();

If those service operations support transactions, and the binding is configured to convey information about the state of the transaction, the client’s transaction will not commit unless the service operations vote to commit. Conversely, any actions performed by the service on transactional resources within the scope of the client’s transaction will be rolled back if the client does not vote to commit.

Designing a system in this way is generally unwise, though. The operations of the service and its resources will be tied up while a remote client decides what action to take. Even if the client can be trusted to decide expeditiously, the latency entailed by the very fact that the components are distributed will cause some delay. As a general principle, one should avoid extending transactions across boundaries of trust.

A smarter way of implementing distributed transactions with the Windows Communication Foundation is depicted in Figure 4.1. This approach combines the support for session management, queued delivery, and transactional messaging.

Figure 4.1. Distributed transactions.

The service shown in the diagram is configured to receive messages from clients via a queue. A client initiates a transaction and then a session, and sends a series of messages to the service. The client completes the session, and if and only if the client commits its transaction will the messages that it sent go onto the queue. The separate messages that the client sent will appear on the queue as a single item. On the service’s side, the Windows Communication Foundation detects the item on the queue and initiates a transaction and then a session. It decomposes the single item on the queue into the separate messages that were sent by the client, and delivers each of those messages to the service. If all goes well, the service closes the session and commits the transaction. If something goes awry in processing any of the messages, the transaction can be aborted, in which case anything done in the processing of any of the messages on a transactional resource will be rolled back. The batch of messages is transferred to the poison message queue, where a service charged with compensating for the failure picks up the messages. That service could alert an administrator, or even notify the client application, that processing failed and that action to compensate should be taken.

By virtue of this design, operations on the client and the server are not held up by one another or by the latency of the connection between them. The client’s transaction and the server’s transaction commit independently. The client’s transaction ensures that the client is always in a consistent state, and the server’s transaction ensures that the server is always in a consistent state. If the client fails in the scope of its transaction, the server is unaffected because messages sent by the client as part of that transaction are never delivered to the server’s queue. If the server fails to process messages sent by the client, although the client will be in a consistent state and the server will be in a consistent state, the client’s state and the server’s state will not be mutually consistent. In that case, some actions to compensate for the inconsistency will have to be taken. However, one might be able to confirm that such cases occur only infrequently.

To see an implementation of this design and to witness the Windows Communication Foundation’s support for session management, queued delivery, and transacted messaging in action, follow these steps:

To see the solution in action, do the following:

This chapter covered the Windows Communication Foundation’s Reliable Sessions feature, which provides assurances that messages will be delivered in order and exactly once. The chapter also dealt with the Windows Communication Foundation’s session management, queued delivery, and transacted messaging facilities. It showed how those features can be used together to yield efficient distributed transaction processing.