Archive for the 'Work' Category

WCF gives a very rich set of standard bindings that you can use for your endpoints. However we might need to tweak properties that might not be exposed on the standard bindings. You can handcraft the whole binding or you can start with standard binding as a template. Here are some ways. 

1. Create the BindingElementCollection from the StandardBinding and update properties on it and use the BindingElementCollection to create the CustomBinding. This creates a full clone of binding elements and you can reset values on the elements using Find<BindingElement> on the collection.
2. Create the CustomBinding directly from the StandardBinding by passing the binding into the CustomBinding constructor. The first approach has an issue where properties like SendTimeout/ReceiveTimeout etc don’t get copied onto the CustomBinding since they are held by the Binding and not its child elements & for this simple reason would recommend the second approach.

[code:c#]

BasicHttpBinding httpBinding = new BasicHttpBinding();
httpBinding.SendTimeout = TimeSpan.FromSeconds(123);
Console.WriteLine(httpBinding.ToString());

BindingElementCollection bec = httpBinding.CreateBindingElements();
bec.Find<HttpTransportBindingElement>().KeepAliveEnabled = false;
CustomBinding copy1 = new CustomBinding(bec);
Console.WriteLine("SendTimeout = {0} KeepAliveEnabled = {1}",
    copy1.SendTimeout,
    copy1.Elements.Find<HttpTransportBindingElement>.KeepAliveEnabled);

CustomBinding copy2 = new CustomBinding(httpBinding);
copy2.Elements.Find<HttpTransportBindingElement>.KeepAliveEnabled = false;
Console.WriteLine("SendTimeout = {0} KeepAliveEnabled = {1}",
    copy2.SendTimeout,
    copy2.Elements.Find<HttpTransportBindingElement>().KeepAliveEnabled);

[/code]

This was one was interesting as the service was exposed as a fully typed service, but the client wanted to modify some parts of the xml. Ideally you can plug into any part to perform these operations, but the general requirement here was that they needed a simple pointer to the Body and didn’t care much about anything else.

Here is an example how how you can access the body similar to an XElement by using the Message directly.

[code:c#]

[ServiceContract(Namespace="http://www.sajay.com/")]
public interface IClientProxy
{
    [OperationContract(Action="http://www.sajay.com/getdata",
        ReplyAction="http://www.sajay.com/getdataresponse")]
    Message DoWork();
}

IClientProxy proxy = cf.CreateChannel();
Message msg = proxy.DoWork();
XNode node = XElement.ReadFrom(msg.GetReaderAtBodyContents());

[/code]

So the service can return a typed object, but the client doesn’t have to handle the message in the same way. Understanding the Message class here helps you appreciate how the serializer and encoder is decoupled from the message representation. Basically WCF does not constrain the native format of your message on either the producer’s or the consumer’s side. It merely conforms to some rules of invoking a set of abstract classes which you wire up by virtue of specifying the encoder and the serializer.

Though we have XML semantics around with abstract classes like the XmlReader/XmlDictionaryWriter etc in conjuction with the Message class, this doesn’t actually mean that WCF converts everything to XML before it can process the message. It merely uses these to invoke the required parts to obtain things like the header/body and other properties.  The Message however can be represented natively in any form like binary/json/atom/ or any whacky type as long as you wire them up properly and can retrieve them in some manner.

This should give you some insight into how much more powerful the message model is compared to simple RPC style contracts.  With 4.0 and workflow services, you will see this becoming more and more the default way of thinking about messages and services.

MessageToXElement.cs (2.90 kb)