he WCF is an incremental, yet evolutionary technology that brings all the formerly distinct and separate Microsoft connectivity technologies together under a single umbrella within the System.ServiceModel namespace. Included in WCF are Web services (ASMX), the Web service Extensions (WS*), Microsoft Message Queuing (MSMQ), Enterprise Services, COM+, and .NET Remoting.

Having a single namespace that subsumes all of these into a coherent package is enormously useful, and makes designing, developing, and deploying applications that require connectivity far simpler. With WCF you won’t have to choose between implementations in a variety of different namespaces and coding types to create a connected application. Whether your application connects via loosely coupled Web services, or tightly coupled Enterprise Services, the coding model will be consistent and the transition between different communication types will be much smoother?because they will all be using the same programming namespace.

Using the WCF
WCF follows the “software as a service” model, where all units of functionality are defined as services. Rather than concentrating on how the communications work, developers need to focus on the service locations, how the services talk to each other, and how to describe what they do. So, for any service, you need to know the answer to these three groups of questions:

1. The Service Address. Where is the service? Is it on the internet, on a machine on my network, or on the same machine as my process?
2. The Service Binding. How do I talk to it? Do I use SOAP? MSMQ?
3. The Service Contract. What does it do for me? What kind of data should I expect to pass to it, and what does it return?

If you’re familiar with Web services, you probably already understand these three aspects in terms WSDL. And you’d be right. WCF takes this popular and successful methodology for defining how services work and extends it to work with the other forms of communication: Microsoft Message Queuing (MSMQ), Enterprise Services, COM+, and .NET Remoting.

Your First WCF Application: Creating the Service
If you aren’t already familiar with the WCF terminology, such as binding, contracts, addressing, and the like, don’t worry; such terms are best learned by example. For the rest of this article, you’ll build your first Indigo application, and then you’ll be off and running. To build the application, there are a few steps that you’ll have to follow.

Before starting, create a physical directory on your hard drive to contain the application at C: convert and then map that to an IIS virtual directory called “Temperatures.” Make sure that the ASPNET process has access to this directory if you are using Windows Server 2003.

The first step is to create the Windows Communication Foundation service contract. This is basically an interface that is marked up to show that it is a service contract. You can see it in Listing 1.

Note the markup through attribution. The ServiceContract() attribute indicates the ITemperatures interface will be a service contract in WCF, and the OperationContract() indicates that ftoc and ctof will be defined as operations in the contract. So far, the process is simple.

The second step expands on this to create the code that implements the interface defined in Listing 1. The following code creates the Service class.

   using System;   using System.ServiceModel;      namespace Devx.Indigo.Samples   {      [ServiceContract()]      public interface ITemperatures      {           [OperationContract]           double ftoc(double n1);           [OperationContract]           double ctof(double n1);       }       public class TemperatureService : ITemperatures       {          public double ftoc(double f)          {             double dReturn = 0.0;             dReturn = ((f - 32) * 5) / 9;           ??return dReturn;          }             public double ctof(double c)          {             double dReturn = 0.0;             dReturn = ((c + 32) * 9) / 5;           ??return dReturn;          }       }   }

You compile this code using the following command, issued on a single line from a command prompt. You’ll need a PATH set up to the .NET framework if you don’t already have it.

   csc /r:System.ServiceModel.dll       /out:TemperatureService.dll /t:library       TemperatureService.cs

Create a BIN subdirectory under tconvert and copy the resulting DLL file to it.

Next, you need a web.config file (see Listing 2). The web.config file contains all the information that WCF needs to hold everything together. It’s worth looking over in some detail. Note that the syntax for this file seems to change drastically with every release, and even differs between Microsoft’s online documentation and the documentation that comes with the download. That’s the fun of living on the beta edge.

It’s a good idea to get to know the web.config file in Listing 2 well when writing WCF apps, particularly if you aren’t using Visual Studio .NET. The tag holds all the information for a WCF service.

Services, Behaviors, and Bindings
When using WCF, there are three things that you need to configure in web.config: Services, Behaviors, and Bindings.

Services
The Service setting is important for two things: First, the location of the behavior (explained more in the next bullet), and second, the type of service, defined using its namespace, in this case Devx.Indigo.Samples.TemperatureService.

The service element has a child element where you specify the binding (more on this later) and the contract. The contract is defined by the interface (from Listing 1) using its fully qualified name.

Behaviors

	?
Figure 1. Running the WCF Service: After creating the service, when you access it from a browser, you will see a screen similar to this that shows how to use the service.

The behaviors element lets you configure how the service should react under particular circumstances. It needs a configurationName attribute so that the service can map to it. In Listing 2, the service has been configured to return any unknown exceptions as faults.

Bindings
You define the bindings and the binding types within the bindings element. In this case, the element is simple, specified as an HTTP type binding, identified as Binding1. Check the MSDN documentation and the schema (defined at the top of this config file) for more options.

Save the web.config file in the same directory as your application, and you’re almost ready to go.

The final thing you need is the service mapper. Create a text file in the tconvert directory and call it “service.svc.” It should contain the following single line of code:

   <@Service language=c# Debug="true"       class="Devx.Indigo.Samples.TemperatureService" %>

Your Indigo service is now ready to go. You access it via the URL: http:///TemperatureService/service.svc. You can see the results of this in Figure 1.

Your First Indigo Application: Creating the Client
The Windows Communication Foundation SDK offers a tool called svcutil.exe that creates proxy code for your client. To use it with this service, issue the following command from the command prompt, changing the URL to match your server:

   svcutil /language:C# /config:app.config       http://192.168.0.1/Temperatures/service.svc?wsdl

As the namespace for the service wasn’t specified, the WSDL generated by .NET uses the tempuri.org Web services namespace by default. Don’t confuse this with the namespace for the code (called a package in Java parlance) which is Devx.Indigo.Samples. As such, the code generated by svcutil will be called tempuri.org.cs. This is your proxy class.

To use this proxy class, you consume it within an application class as follows:

   using System;   using System.ServiceModel;   namespace Devx.Indigo.Samples   {     class TemperatureClient     {       static void Main()       {         using (TemperaturesProxy proxy =            new TemperaturesProxy("default"))         {           double c = 0.0;           double f = 0.0;                                 c = 22.2;           f = proxy.ctof(c);           Console.WriteLine(             "{0} degrees C = {1} degrees F", c, f);           f = 93.7;           c = proxy.ftoc(f);           Console.WriteLine(              "{0} degrees C = {1} degrees F", c, f);                              proxy.Close();         }         Console.WriteLine();         Console.WriteLine(            "Press  to terminate client.");         Console.ReadLine();       }     }   }

You can then compile the class shown above into an executable application using the following command:

   Csc /r:System.ServiceModel.dll /t:exe       TemperatureClient.cs tempuri.org.cs

When you execute the application, it calls the Indigo service, performing a Fahrenheit-to-Centigrade (FtoC) and Centigrade-to-Fahrenheit (CtoF) conversions and returning the results.

The Windows Communication Foundation is extremely powerful and flexible technology, and will become a huge part of many developers’ toolboxes in the coming years. It solves two major problems: diverse communications frameworks and proliferating standards. It’s a one-stop shop for all types of communication built on well-known, industry-accepted standards?and it does all that using a paradigm already familiar to most Visual Studio.NET developers. At first it might seem difficult to grasp the meanings of terms such as binding, contracts and the like, but with a little practice and a little hands-on work those soon become second nature.

The WCF application discussed in this article?a very simple service/client pairing that uses the ServiceModel framework to communicate?didn’t do anything beyond what you can do with a common Web service, but it should have given you a taste of what is to come with WCF. Over the next few months the upcoming articles in this WCF series will empower you to hit the ground running in building Service Oriented Applications and software as a service on demand.