You may have noticed that bindings use two different classes for configuring reliability: ReliableSession and OptionalReliableSession. The only difference between the two is that OptionalReliableSession has an Enabled property that allows the reliable session to be turned off. If you only have a ReliableSession to work with, then there is no way for it to be disabled. The only standard binding that uses ReliableSession is WSDualHttpBinding. All of the other standard bindings that support reliability, such as NetTcpBinding and WSHttpBinding, use OptionalReliableSession. Why is WSDualHttpBinding the only one that has to be reliable? The reason for this is that WSDualHttpBinding has to coordinate together two different connections. The stack of binding elements for WSDualHttpBinding looks like this: TransactionFlowBindingElement ReliableSessionBindingElement SecurityBindingElement (optional) CompositeDuplexBindingElement OneWayBindingElement TextMessageEncodingBindingElement (or MtomMessageEncodingBindingElement) HttpTransportBindingElement Composite duplex splits the binding into separate input and output connections, and relies on a higher-level component to correlate the two. There are many ways to provide that correlation, one of which is a reliable session. Requiring that the reliable session be present matches the most common usage pattern and allows the other potential correlation mechanisms to be omitted without having to validate the resulting binding configuration. That's why WSDualHttpBinding requires a reliable session. If you have a different correlation mechanism that you want to use together with composite duplex, then you can build that with a custom binding. Next time: Context Channel Shapes
Read More...