Having completed the WCF service, you can now update the AMM client application to use it.
private void button1_Click(object sender, EventArgs e)
ChopstickBuilderService.ChopstickBuilderClient csBuilder =
int count = csBuilder.GetChopsticksUnderConstruction();
Again, notice there is no code specific to reliable sessions. WCF handles the work for you. The last step for the client is making sure reliable sessions are enabled. Just as in the service, this is handled via a reliableSession
element in the binding configuration:
Now that the client is complete, the code can be tested. Using an HTTP proxy such as Fiddler, you can examine the HTTP traffic to see exactly how the reliable sessions are handled. There are actually 11 exchanges that take place between the client and the service. The first three and last one involve WS_Trust
negotiations, which are outside the scope of this article. Those middle seven exchanges are the most pertinent to this discussion. Taking some key data out of the actual SOAP messages, you see the following exchange in Listing 1
In plain English, the conversation from Listing 1
looks something like this:
Request: Can I please start a new sequence?
Response: Yes, here is a Sequence Identifier you can use.
Request: Here is message 1 for this sequence.
Response: Thanks, I received message 1 and have received 1 message so far.
Request: Here is message 2 for this sequence.
Response: Thanks, I received message 2 and have received 2 messages so far.
Request: Here is message 3 for this sequence.
Response: Thanks, I received message 1 and have received 3 messages so far.
Request: Here is message 4 for this sequence.
Response: Thanks, I received message 1 and have received 4 messages so far.
Request: Here is the last message.
Response: Thanks, I received message 5 and have received 5 messages so far.
Request: OK, I’m done with this sequence.
Response: I received 5 messages. Thank you, come again!
The back and forth exchange of the message number and message number acknowledgements allows WCF to ensure messages are in the proper order and, in the case of a failure to acknowledge, can be resent.
Finally, it is worth discussing a few more configuration settings that can have an effect on reliable sessions. These specific attributes appear on the reliableSession element for a custom binding:
<reliableSession maxTransferWindowSize="8" flowControlEnabled="true" acknowledgementInterval="8"
Table 2 outlines these values.
|Table 2. reliableSession Element Custom Bindings: Attributes and Descriptions for reliableSession element custom bindings.|
| maxTransferWindowSize || This setting controls how many messages can be held for transfer at any given time. The default value is 8.|
| flowControlEnabled || Enables a Microsoft proprietary implementation of flow control for WS-ReliableMessaging. The default is true.
| acknowledgementInterval || Specifies the maximum wait time before a message acknowledgement is sent. The reasoning here is that acknowledgements are not always sent immediately but can sometimes be batches to improve network performance. This value is a timespan and the default is 00:00:0.2.|
|maxPendingChannels|| Specifies the number of reliable sessions that can be waiting for acceptance. The default value is 4.|
|maxRetryCount||Indicates how many times a message should be retried when no acknowledgment is received. The default is 8.|
|reliableMessagingVersion|| Specifies the version of WS-ReliableMessaging used.|
In most cases, the default values for the above settings are fine. It is, however, useful to be aware of their presence and understand their purpose.
Thanks to WCF and Reliable Sessions, ACME IT quickly integrated a new application that was only reachable via an unreliable HTTP connection. WCF ensures messages are delivered properly and in a specific sequence so that the application behind those services can operate as expected. The ACME Manufacturing Manager is ready for whatever changes may come.