The WCF Run-Down

Windows Communication Foundation (WCF) is a framework for building service-oriented applications. Using WCF, you can send data as asynchronous messages from one service endpoint to another.

Great… Lets try it out…

So how do you go about getting something up and running? We have to start somewhere… so let’s start by covering some of the basic concepts.

Service Contract
The bulk of the work in setting up WCF is achieved by the most simplest of attribute placement on an interface (or class). Best practice is to apply it to an interface.

[ServiceContract]
public interface IMyServiceContract
{
    [OperationContract]
    string GetData(int value);
}

Bindings

Define the configuration of the way messages will be communicated, transported and encoded. The examples being Synchronous vs Asynchronous, HTTP vs TCP, compression vs interoperability. This list and set of comparisons is by no means exhaustive. But for the majority of cases of you’re likely to choose either NetTCP or MSMQ (queued) if both systems (client+server) are using WCF. Otherwise you have an ASMX based client and your choice really should be WSHttpBinding (otherwise you’re supporting a legacy system and you have no choice but to use BasicHttpBinding.

Endpoints

The address to which clients can connect to the service. The key things to note are the protocol type in this case net.tcp, the port (anything high up will do), the bindingConfiguration that allows you to further define the communication method, and the reference to the contract defined earlier. The service can and expose multiple endpoints, and they can each be of varying type and configuration.

<system.serviceModel>
  <services>
    <service name="MyService">
      <endpoint
        address="net.tcp://localhost:8001/MyService" 
        binding="netTcpBinding"
        bindingConfiguration="myNetTcpBinding"
        contract = "IMyServiceContract" />
    </service>
    <bindings>
      <netTcpBinding>
        <binding name="myNetTcpBinding" 
          transactionFlow="true" />
        </netTcpBinding>
    </bindings>
  </services>
</system.serviceModel>

Just a tip if you find yourself debugging calls from a client application and if you’re anything like me and like to edit code live while continuing to debug you will cop a lot of timeout exceptions. It’s therefore handy to setup extra bindings you can use them in development naming them something obviously not required for production like ‘DevExtendedTimeouts’ (hopefully so someone remembers to remove them before shipping) the length of the name itself makes them stand out. This way you have a few more minutes before you get hit with a timeout – alter length to your own taste. In a future post I will cover how this can also be achieved programmatically including the use of compiler directives.

<bindings>
   <netTcpBinding>
      <binding name="myNetTcpBinding_DevExtendedTimeouts" 
         transactionFlow="true"
         sendTimeout="00:05:00" />
   </netTcpBinding>
</bindings>

Client Application

Once the service contract has been imported a proxy responsible for managing the life-cycle and connection to the service is what the client application can invoke to make calls. The client end configuration needs to list all the endpoints exposed by the service that it intends to use. A key thing to note is the client calls via the proxy should always perform a close action, to free up resources on the service. This can simply be achieved via a using() statement, your service implementation should also implement IDisposable.

    using ( IMyServiceContract proxy = new MyClient() )
    {
        proxy.SomeMethod();
    }

Client configuration leads onto the topic of hosting the WCF service which will be the next post “Being a Good Host“.

Advertisements