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

Why WCF

UPDATE 9-July-2010:
This entry gets a lot of random hits, so I thought I would update the information as of July 2010, just to give links to newer areas relating to WCF.

WCF – Windows Communication Foundation, has become in fact more of a foundation for a larger set of abstractions on top it. Simply put WCF is a set of fundamental plumbing components with powerful extensibility features. But is not the easiest of things to use and configure.

The options now for more out of the box ready solutions that wrap and exist on top of WCF are:

These frameworks/abstractions/concepts are intended to simplify creating and deploying your web accessible service offerings.

Original post as it was 24-Feb-2009…

To quote the MSDN front page for WCF:

“It unifies the capabilities in ASMX, WSE, Remoting, COM+, and MSMQ; therefore developers need to learn only one programming model.”

Simply put “it’s where we are with Microsoft.NET framework”, if you’re going to build .NET applications it’s the right choice. Service Oriented Architecture is currently the most practical approach to build robust, distributed and maintainable applications. WCF allows you to simply and easily build such services according to an industry standard, with the intention to achieve a high level of interoperability. WCF takes care of: service interactions, marshalling, type conversions and other protocols allowing the developer to focus less on plumbing and more on delivering application value.

Key WCF notes:

  • Most messages are SOAP messages.
  • Not only for HTTP (can have: TCP, NamedPipes).
  • Can therefore communicate:
    • same machine
      • same app domain
      • cross process
    • cross machine
      • intranet
      • internet
  • Interoperable with other non-WCF services.

What I will attempt to demonstrate in subsequent posts is how simple it is to get the application plumbing working right and smoothly. Also down the track demonstrate some of the more complex scenarios you can setup with WCF especially the capabilities to further extend the framework.

Next up is “The WCF Run-Down“.