Windows Communication Foundation

Web Services, communication between applications is very important. Web services provide an efficient way of facilitating communication between applications. But there are limitations with web services too. The major limitation with web services is that the communication can happen over HTTP only. A second limitation with web services is that it provides simplex communication and there is no way to have half duplex or full duplex communication using web services. 

Windows Communication Foundation (WCF) comes to the rescue when we find ourselves not able to achieve what we want to achieve using web services, i.e., other protocols support and even duplex communication. With WCF, we can define our service once and then configure it in such a way that it can be used via HTTP, TCP, IPC, and even Message Queues. We can consume Web Services using server side scripts (ASP.NET), JavaScript Object Notations (JSON), and even REST (Representational State Transfer).

The following table illustrates the differences between a web service and a WCF service:

Web Service	WCF Service
Communication can happen over HTTP only	Communication can happen over HTTP, TCP, IPC, or even MSMQ.
Only simplex and request-response communication is possible	It can be configured to have simplex, request-response, or even full duplex communication.
They work in an stateless fashion over HTTP and are hosted inside a web server like IIS	These can be hosted in many ways inside IIS, inside a Windows service, or even self hosted.

A service is a unit of functionality exposed to the world.

WCF is a software development kit for developing and deploying services on Windows.

WCF is Microsoft’s implementation

of a set of industry standards defining service interactions, type conversions,

marshaling, and the management of various protocols.

Address:

In WCF, every service is associated with a unique address. The address provides two

important elements: the location of the service and the transport protocol, or transport

scheme, used to communicate with the service. The location portion of the address indicates the name of the target machine, site, or network; a communication port, pipe,

or queue; and an optional specific path, or URI (Universal Resource Identifier). A URI

can be any unique string, such as the service name or a globally unique identifier

(GUID).

WCF supports the following transport schemes:

• HTTP/HTTPS

• TCP

• IPC

• Peer network

• MSMQ

• Service bus

Addresses always have the following format:

[base address]/[optional URI]

The base address is always in this format:

[transport]://[machine or domain][:optional port]

Here are a few sample addresses:

http://localhost:8001

http://localhost:8001/MyService

net.tcp://localhost:8002/MyService

net.pipe://localhost/MyPipe

net.msmq://localhost/private/MyQueue

net.msmq://localhost/MyQueue

Contracts

In WCF, all services expose contracts. The contract is a platform-neutral and standard

way of describing what the service does. WCF defines four types of contracts:

Service contracts

Describe which operations the client can perform on the service.

Data contracts

Define which data types are passed to and from the service. WCF defines implicit

contracts for built-in types such as int and string, but you can easily define explicit

opt-in data contracts for custom types

Fault contracts

Define which errors are raised by the service and how the service handles and

propagates errors to its clients.

Message contracts

Allow the service to interact directly with messages. Message contracts can be typed

or untyped and are useful in interoperability cases when another party has already

dictated some explicit (typically proprietary) message format.

Hosting

The WCF service class cannot exist in a void. Every WCF service must be hosted in a

Windows process called the host process. A single host process can host multiple services,

and the same service type can be hosted in multiple host processes.

A WCF service can be hosted in following ways:

1.        Hosting in Internet Information Services(IIS).

2.        Hosting in Windows Activation Services(WAS).

3.        Hosting in a Console or Desktop application(Self hosting).

4.        Hosting in a Windows Service.

Bindings

There are multiple aspects of communication with any given service, and there are many

possible communication patterns. Messages can follow a synchronous request-reply or

asynchronous fire-and-forget pattern, messages can be bidirectional, messages can be

delivered immediately or queued, and the queues can be durable or volatile. As discussed

previously, there are many possible transport protocols for the messages, such

as HTTP (or HTTPS), TCP, IPC, and MSMQ. There are also a few possible message

encoding options. You can choose plain text to enable interoperability, binary encoding

to optimize performance, or the Message Transport Optimization Mechanism

(MTOM) for large payloads.

The Common Bindings

WCF defines five frequently used bindings:

Basic binding

Offered by the BasicHttpBinding class, basic binding is designed to expose a WCF

service as a legacy ASMX web service so that old clients can work with new services.

The basic binding makes your service look, on the wire, like a legacy web service

that communicates over the basic web service profile. When used by clients, this

binding enables new WCF clients to work with old ASMX services.

TCP binding

Offered by the NetTcpBinding class, TCP binding uses TCP for cross-machine communication

on the intranet. It supports a variety of features, including reliability,

transactions, and security, and is optimized for WCF-to-WCF communication. As

a result, it requires both the client and the service to use WCF.

IPC binding

Offered by the NetNamedPipeBinding class, IPC binding uses named pipes as a

transport for same-machine communication. It is the most secure binding, since it

cannot accept calls from outside the machine. The IPC binding supports a variety

of features similar to the TCP binding. It is also the most performant binding, since

IPC is a lighter protocol than TCP.

The NetNamedPipeBinding class is inconsistently named, since the

binding naming convention is to refer to the protocol, not the communication

mechanism (thus, we have NetTcpBinding rather than

NetSocketBinding). The correct name for this binding should have

been NetIpcBinding. Throughout this book, I will refer to the Net

NamedPipeBinding as the IPC binding.

Web Service (WS) binding

Offered by the WSHttpBinding class, the WS binding uses HTTP or HTTPS for

transport and offers a variety of features (such as reliability, transactions, and security)

over the Internet, all using the WS-* standards. This binding is designed to

interoperate with any party that supports the WS-* standards.

MSMQ binding

Offered by the NetMsmqBinding class, the MSMQ binding uses MSMQ for transport

and offers support for disconnected queued calls.

Name                                      Transport                              Encoding                                Interoperable

BasicHttpBinding                    HTTP/HTTPS                         Text, MTOM                          Yes

NetTcpBinding                         TCP                                         Binary                                     No

NetNamedPipeBinding             IPC                                          Binary                                     No

WSHttpBinding                        HTTP/HTTPS                         Text, MTOM                          Yes

NetMsmqBinding                     MSMQ                                  Binary                                     No

Endpoints

Every service is associated with an address that defines where the service is, a binding

that defines how to communicate with the service, and a contract that defines what the

service does.

To invoke operations on a service, a client first needs to import the service contract to

the client’s native representation. If the client uses WCF, the common way of invoking

operations is to use a proxy. The proxy is a CLR class that exposes a single CLR interface

representing the service contract.    

MTOM(Message Transmission Optimization mechanism

The purpose for using MTOM is to optimize the transmission of large binary payloads. Sending a SOAP message using MTOM has a noticeable overhead for small binary payloads, but becomes a great savings when they grow over a few thousand bytes. The reason for this is that normal text XML encodes binary data using Base64, which requires four characters for every three bytes, and increases the size of the data by one third. MTOM is able to transmit binary data as raw bytes, saving the encoding/decoding time and resulting is smaller messages. The threshold of a few thousand bytes is small when compared to today's business documents and digital photographs.