Fundamentals of Windows Communication Foundation

In this post, we will look at the fundamental concepts behind Windows Communication Foundation or WCF (formally known as Indigo). This is not a walkthrough post rather it emphasis on the concepts which make up WCF. Creating and working with WCF Services will be a topic of future post.


What is Windows Communication Foundation

WCF is Microsoft’s flagship technology for developing Distributed application. It is a development platform which targets Service-Oriented Architecture. WCF provides a loosely coupled and interoperable platform for developing service-oriented applications.

Before the introduction of WCF, technologies such as .NET Remoting, COM, DCOM+ and MSMQ have existed for developing distributed applications. The downfall of these technologies has been coupling to a specific technology. Only a .NET Remoting client can talk to a .NET Remoting server. This means that’s its almost impossible for a Java-based client to talk to a .NET Remoting Server. Although Web Services have addressed the issue of interoperability to a greater extent, the introduction of Enhancement have started yet another race between different vendors.

To overcome the problem of interoperability and tight coupling, Microsoft introduced Windows Communication Foundation with .NET Framework 3.0. The System.ServiceModel assembly provides the core functionality for WCF. WCF provides a single programming model for developing distributed applications. It supports different protocols, behaviors and policies. This means the same WCF Service can be exposed to clients using different protocols. This way the service encompassing the business functionality remains the same but has different interfaces to interact with.



How does a WCF Service Work

Before I proceed to explain the different concepts behind WCF, I want to give you a faint idea of how a WCF application is organized. Basically a WCF application consists of three parts:

Service: The service exposes the business functionality to the rest of the world
Host: Before a service is available, it must be hosted in an environment.
Client: The client is an application or yet another service which accesses the service

Let us now look at the different concepts which make up a WCF application in the following sections.


Service and Contract

A service is a set of business functionality. From a .NET point-of-view, a service represents a CLR type. This type exposes different methods which can be invoked by client. For a type to be WCF Service, it must have a service contract. A service contract is defined by applying the [ServiceContract] attribute on a class or an interface. Any class implementing an interface with associated service contract is also a WCF service. Following listing shows a simple service contract:

[ServiceContract (Namespace="http://myuniquenamespace/")]
public interface IMaths
{
    [OperationContract]
    int AddTwoNumbers (int x, int y);
}

It is quite obvious that a class/interface define methods to be invoked. All methods exposed by a WCF Service must be decorated with the [OperationContract] attribute. A method without this attribute is not a part of the WCF Service. You must keep in mind that the OperationContract can only be applied to methods and not to a property or event. Why, because WCF is about exposing business functionality and business functionality resides in methods. For this reason, the OperationContract is only specific to methods.


Hosting

As I mentioned above, before a service can be accessed, it must be hosted in a host process. A host process can be any Windows Process. We can host multiple services under one host process or vice versa. There are three kinds of hosting available including:

Self Hosting: In self-hosting, the programmer is responsible for providing a hosting environment for the service which can include a Console application, Windows Form, WPF application or Windows NT Service.

IIS Hosting: A service can be hosted like a regular asp.net application. This requires a .svc file to be hosted in IIS

WAS Hosting: The Windows Activation Service (WAS) is only available for Windows Vista. Like IIS Hosting, WAS also requires a .svc file and is available for different protocols.

Under the hood of every host, the WCF Service Model is responsible for handling the communication. The ServiceHost class (a part of the service model) initiates the communication channel. A ServiceHost has an associated service type, address, service contract and communication protocol.


Addresses

Each WCF service has a unique address which a URI (Universal Resource Identifier). The URI has the following syntax:

[scheme]://[domain|machine-name][:port]/[optional [path]

A scheme defines the transport protocol used for communication. These protocols can include HTTP, TCP, name-pipes, MSMQ etc. Each of these protocols has an associated scheme such as http, net.tcp etc. The domain is the name of the machine or domain hosting the service. The port identifies the communication port associated with a specific protocol. A path can be used to avoid ambiguity. For example, we may have two services hosted on the same address. In this case, the optional path will give a separate address for each hosted service. The following shows a few examples of addresses:

http://www.mydomain.com
net.tcp://localhost/servicename
net.pipe://localhost:5500/myservice


Binding

Binding represents the options of choosing from different transport protocols, message encoding formats, security and reliability options for communication. When it comes to using a combination of these features, the options are countless - almost. For example, one may decide to use Http, Https, TCP, MSMQ, Named Pipes etc. as a transport protocol. Message encoding can be based on Binary Serialization or XML formatting. Security is yet another broad area to select from. If we plot a matrix of available options, we will end up with a very long list.

WCF Binding simplifies the above process by grouping together different options. For example HttpBasicBinding supports Http/Https protocols, Text/MTOM encoding format and is interoperable between existing and new web services format. Similarly, NetTcpBinding supports TCP protocol, Binary formatting and is not interoperable with other protocols. Details of different binding options can be found here.


Endpoint

To initiate communication with a service, the service model (ServiceHost) must provide an Endpoint. An endpoint is basically the trilogy of Address, Binding and Contract (commonly known as the ABC of a service). A service must have at least one endpoint, although it can have multiple endpoints. The ServiceHost must be initialized with one or more endpoints before communication commences.

Since a service can expose more than one endpoint, the same service is available with different communication options. For example, Service-A may be available over Http for web services but is also is available over TCP behind a firewall. It all comes down to the user requirements but the options are numerous. Endpoints can be configured using config files or programmatically.


Metadata

A service is attached to an endpoint where each endpoint has associated address, binding and contract. The client communicates with this endpoint to invoke business functionality. But the client needs to know about the endpoint before interacting with the service. Metadata provides information about an endpoint to the clients. Metadata can be generated by the help of a ServiceHost. The ServiceHost can either expose a metadata endpoint (this is different from the service endpoint) or can generate a WSDL file representing the metadata.


Proxy

A client can only communicate with a service using a proxy. A proxy acts on behalf of the service and exposes methods to the client. It also handles the underlying plumbing associated with the communication i.e. it handles message serialization, encoding format etc. A proxy communicates with one endpoint so it’s a one-to-one relationship. Proxies are generated by the help of metadata of a service.

With this we come to the end of this post. Future posts will talk about creating WCF Services. So stay tuned for more…