he ACME Toothpick Company recently implemented two transactional Windows Communication Foundation (WCF) services to integrate their toothpick manufacturing and log inventory applications. A third application, the ACME Manufacturing Manager (AMM), was subsequently developed to utilize the new services and manage the overall manufacturing process. The project was a resounding success and the toothpicks are flying off the shelves. The introduction of WCF based transactions ensured that the log and toothpick inventories stayed accurate and up-to-date.
Now, management presents ACME IT with a new challenge: chopsticks. With the recent acquisition of the Chicago Chopstick Company, ACME Toothpick Company became ACME Toothpick and Chopstick. Unfortunately for ACME IT, the toothpick manufacturing operation is located in Boston while chopstick manufacturing will remain in Chicago. The AMM application needs to communicate with the chopstick-manufacturing manager (CMM) over a potentially unreliable HTTP connection and through multiple proxy servers. ACME IT needs to guarantee messages are delivered properly and consistently between the two applications.
WCF Reliable Sessions are just what ACME IT needs. Reliable Sessions utilize the WS-ReliableMessaging protocol to ensure messages are delivered over unreliable connections. The advantage to using WS-ReliableMessaging is that the reliability is baked in at the message level rather than depending on any specific transport. Reliability is guaranteed over any type of connection and over multiple hops (i.e., through proxy servers). In addition, Reliable Sessions ensure messages are delivered in the appropriate order. You can use Reliable Sessions on HTTP, TCP, and NamedPipe transports. Because ACME IT uses WCF, implementing reliable sessions is a snap (see Figure 1).
|Author's Note: In this scenario, you want to secure your messages (A future article is planned to discuss WCF security).|
Exposing the Functionality
| || |
| Figure 1. ACME’s Proposed System: An ACME employee interacts with a single system and WCF ensures message delivery.
The first task is to expose the functionality of the Chopstick Manufacturing Manager as a WCF-based service. The starting point is the CMM service contract, which is shown below:
public interface IChopstickBuilder
Notice the service contract contains a method named WarmupChopstickMachine
. You must warm up the chopstick system prior to any actual manufacturing. Because of this, you must always call WarmupChopstickMachine
prior to calling ConstructAChopstick
. It is critical that these messages are received in the proper order. Notice there are no reliable session-specific settings on the service contract.
With the contract defined, you can create the actual service implementation:
public class ChopstickBuilderService : IChopstickBuilder
private int chopsticksInProcess = 0;
public int GetChopsticksUnderConstruction()
public void WarmupChopstickMachine()
//TODO - Call to CMM API
public void ConstructAChopstick()
//TODO - Call to CMM API
Notice that there's nothing specific to reliable sessions in the service implementation either.
The final step is to update the binding configuration for the new service in the application configuration file. The key addition is a reliableSession
element, which is added to the binding configuration:
<reliableSession enabled="true" ordered="true" inactivityTimeout="00:10:00" />
The binding configuration takes place in the secure session configuration. The reliableSession
element can contain the following attributes (see Table 1).
|Table 1. reliableSession Element: Attributes and Descriptions for the reliableSession element.|
|enabled||A Boolean that indicates if reliable sessions should be enabled.|
|ordered|| A Boolean that indicates if messages must be delivered in the order they were sent.|
|inactivityTimeout||A timespan that indicates the maximum amount of a time the session can remain inactive (no messages received). The default is 10 minutes.|
Notice you have to set the ordered attribute, meaning that messages must be delivered in the order they are sent. As you will later see, no additional code is necessary because the WCF infrastructure handles the details.
It is also important to understand that there are actually two timeouts. The first is the previously mentioned inactivityTimeout on the reliableSession element. The second is the receiveTimeout on the binding itself. If either of these timers elapse, the session expires. The key difference is that receiveTimeout looks for application messages only while the inactivityTimeout looks for application and infrastructure messages. An example of an application message is a call to an actual WCF service method, such as ConstructAChopstick. An example of an infrastructure message is a request to begin a sequence, as you'll see in the remainder of this article. When using reliable sessions, be aware that you must increase or decrease both values together. The following example shows a binding configuration with both of these timeouts in use:
<binding name="ToothpickBuilder" receiveTimeout="00:10:00">
<reliableSession enabled="true" ordered="true" inactivityTimeout="00:10:00"/>