WCF stands for "Windows Communication Foundation".

It is that part of .NET 3.0, which is the newest coolest way of establishing communication between two pieces of executing computer code.

Now, we have had DDL, DCOM, Remoting, Web Services, WSE, .. why .. YET ANOTHER .. way of communication? Why oh why do I have to learn YET another thing?

Well, I hear ya.

WCF is fundamentally different from previous communication technologies. Another common "jargon-phrase" you will hear thrown around a lot is "SOA" or Service Oriented Architecture. Extremely simplified, think of SOA has different pieces of code/services running around the world and clients can make use of those services. These service hosts take care of internal complexities, and the communication infrastructure allows for things such as versioning and the communication infrastructure.

Thus, a big tenet of SOA is isolation. Let me explain with an example.

Say, you are consuming a web service, that accepts a zipcode, and returns you a weather forecast. All you, the client, ever cares about is .. the zipcode (input), and the forecast (output). Beyond the input/output .. or request/response .. the service host .. never talks to the client. There is an isolation between the client and server, and they interoperate on only what they had agreed to interoperate upon, i.e. the contract. So, this brings me to the first important piece in WCF, "The Contract".

Contract: This is the heart of your service - what does your service do!

In WCF, a contract is usually implemented as an interface decorated by the [ServiceContractAttribute]. For instance, in this particular case, your contract would look like this -

   1: [ServiceContract]

   2: public interface IWeatherService

   3: {

   4:     [OperationContract]

   5:     public WeatherForecast GetForeCast(int zipCode);

   6: }

But is a contract all I need? Well no .. because I need to know atleast 3 peices of information before I can use such a service -

• Where can I find this service - The Address.
• What protocol will I use in using this service - The Binding.
• And of course the contract - when I know where the service is (address), and how I will technologically speaking use it (binding) - what the heck will I do with it .. the Contract.

So, in WCF, you have ABC's -

The Basics

Address: Address is where your service can be found. Usually in the format of scheme://domaon[:port]/path. Example http://localhost:8080/MyService

Binding: A binding refers to specific protocols used by a particular endpoint. Example, http, tcp, msmq etc.

Contract: This is the heart of your service - what does your service do!

These 3 together, form an "EndPoint".

EndPoint: EndPoint is how a ServiceHost, exposes a service, so clients can invoke it's operations defined in the contract. (Read that again!).  So, how is an EndPoint different from an Address? An EndPoint have 3 peices - Address, Binding, and Contract.

Now, note that in the contract I showed above, I am using a return type called "WeatherForecast". The "WeatherForecast" is a class I wrote, that represents a business object which lets me conveniently hold the details of the data I am accepting or sending. This along with all details of the endpoint constitute, the "MetaData" for the service.

Also, for "WeatherForecast" to go over the wire, it must be Serializable. Being Serializable means, the object can be hydrated, dehydradted from a stream/bunch of bytes, into a living class instance. Thus, if the human body was serializable, teleportation like Star Wars shows us all the time, would be possible. The business object "Human Body" would be dehydrated into "information" - sent over a communication channel(s), and then rehydrated at the other side - to produce a human being on the other side. Sure beats my commute.

And given the MetaData for a service, a consumer of the service, can now create a Proxy - which is an empty shell, or a type, that exposes all details of the service.

Proxies: A client communicates with a host using a proxy. A proxy is an empty type that exposes all operations in a service contract, and hides serialization/sending over wire details. A single proxy, uses a single endpoint.

Finally, the client, and the host, talk to each other through various channels. And around these channels, you may have various behaviors associated with the service.

Channels: Channels, is what a message goes through when it goes between a client and a host. Usually you have multiple stacked channels.

Behavior: Behaviors modify the message as they flow through a channel stack. A good example of a behavior is authorization.

So .. overall ..

You have a host, and a client, both agree on a contract. The host exposes EndPoints which are a combination of Address, Binding and Contract. The client uses a proxy, that is tied to a particular endpoint - thus tied to a particular contract. And the actual communication related details are abstracted in Channels and Behaviors.

That one line above, summarizes WCF.

So, what makes WCF different?

• You first think of the Contract - What am I trying to get done!?
• Then you think of where will I host it, and what technology will I use to host it.
• Then you worry about the nitty gritties such as authentication etc.

For the very first time, you have a communication technology, that lets you first focus on what you're trying to get done, and worry about communication later.

I say, time to write a quick application huh?