Sam Gentile's Blog (if (DeveloperTask == Communication && OS == Windows)

Welcome to the 11th article in the series.  Updated: Nov 23, 2008

In this article, I will take a broad detour from the abstract into the concrete with WCF. The title of this article is "Introduction to WCF: Architecture and the "ABCs" of Indigo." BTW, I have been in the Indigo SDR program for over 4 years and the term Indigo has stuck in my mind, so I will use the terms interchangeably. Plus, as I think Don Box said in a presentation," It's spelled W-C-F and pronounced Indigo. The WCF is silent." :)

What is WCF in Simple Terms?

The focus of this post is to show "Hello Indigo" code in a step-by-step manner. We will dive deep into the Indigo Architecture in the next installment of this series. Simply put, WCF is Microsoft's SDK and platform for creating and deploying Services in both a Service-Oriented Architecture (SOA see Articles 1-10) in the series as well as absorbing and subsuming the feature sets of legacy distributed technologies such as COM, COM+,  Enterprise Services, .NET Remoting, WSE, ASMX and MSMQ.

WCF provides a runtime environment for your services, and deals with exposing CLR types as services, as well as consuming other services as CLR types. I will get into much more detail in future installments, but WCF was also built with Interoperability as a major goal, and as such, is built on top of an implementation of a set of industry standards. The WCF Architecture was also built to be fully extensible. There is no better example of this than the product group itself as full REST and Web programming was rather easily added to WCF 3.5 and 3.5 SP1 with no changes to the programming model. The skills that are learnt in constructing a basic WCF service are very applicable to creating a "REST service."

Let's see how easy it is to get started.

Hello Indigo Step by Step

I am going to show you WCF step by step and make it as easy as possible. To that end, I am put both the Sender and Receiver in the same console application and I am not going to use either generated proxies or config files. You would never do this in the real world, but it makes it easy to describe the "ABCs" of WCF.

So, let's start with a shell console application that should be totally familiar to you. Run VS2008 and Create a new C# Console application and Add a Reference to System.ServiceModel. Then replace the code of the console class with the following:

A Service is a Set of Endpoints

The ABC's of WCF

A is For Address, the "Where"

The first concept is that of the Address. The Address is where our application will hang its hat, waiting and listening for incoming messages. It's unique and a combination  of the location of the service and the transport protocol or schema. For now, we will keep it simple and stick with the HTTP transport and URIs. We need to use the System.Uri type to do this:

B is For Binding, the "How"

The next thing we need is a Binding. Bindings can get complicated with their shaping of channel stacks but for now, lets leave it as a binding defines the channel used to communicate with an endpoint. A channel is combined of a series of binding elements which are a combination of a transport, Message Exchange Pattern, and a message encoder. We will use bacicHttpBinding which directs WCF to implement the WS-I Basic Profile 1.1, the lowest common denominator of interoperability.

C is For Contract, the "What"

The Contract is the heart and soul of WCF, and I would say Service-Orientation. It is a syntactic description of what operations the service responds to and what shape the messages take going in and out.

Can You Hear Me Now?

So, we have our ABCs of WCF but our Service is lacking an Endpoint to listen on and it's lacking a host. Remember, that a Service has one or more Endpoints that listen for messages. Each Endpoint is made up of an Address, Binding, and Contract. We will use the AddServiceEndpoint method on the ServiceHost class to do this. Say what? We haven't talked about ServiceHost. The System.ServiceModel.ServiceHost type builds and hosts endpoints, along with the rest of the receiving architecture. We'll have a lot more to say about this class later.

Send Me!

At this point, you would normally create the separate client project, would generate the proxy with svcutil.exe or Add Service Reference. But since we are after simplicity, as I mentioned, we will put the sender in the same application. It is the sender's responsibility to use an address, binding, contract that is compataible with the receiver/service.

However, the types are a bit different on the sender side. Instead of a URI type, we have a System.ServiceModel.EndpointAddress which is a WCF abstraction for a WS-Addressing endpoint. Also, instead of ServiceHost, we are the client and we use the ChannelFactory<T> type. Now, normally one would put the address, binding and contract in a config file and use a proxy, but what I am showing you here avoids the need to generate a proxy altogether. So we have:

If we now run the complete program we get our desired result:

Where the Heck are the Messages?

So, this doesn't look at all like a messaging system! To the WCF developer, looks, feels, smells like any other OO or component object program. Be assured, that at run time, however, that the Indigo architecture is configuring channel stacks and dealing with messages. How can I show that? If I change the implementation of the of the SaySomething method to the following, we can see the messages:

What About WS-* Messages?

If we comment out one line and change the binding, we see the WS-* messages: