Back to Article List

Originally published January 2006 [ Publisher Link ]

WCF: Microsoft's 'newest' services way

Every major language or platform that makes use of Web services groups all of its related features under one name, Java open source developers use Axis, the PHP camp makes use of PEAR and now Microsoft based developments will have access to WCF (Windows Communication Foundation).

WCF -- once known as Indigo -- actually set out to be more than just a Web services initiative, its aim is to provide an all encompassing umbrella under which to place all distributed system technologies, in essence, a service-orientated suite of APIs.

Currently, the .NET framework, which offers the most modern approach to developing applications in the Microsoft world, has provisions for solving a series of client-server communication scenarios.

For example, ASP.NET Web Services (ASMX) offer the simplest form of exposing application interfaces through Web services, while .NET Remoting proves essential to achieving .NET to .NET application communication.

At the other end of the spectrum, many systems are either built beyond the context of the .NET framework or simply require special handling through some other means.

For those applications requiring Web services standard support -- the WS-* kind -- Microsoft came up with Web Services Enhancements (WSE). And for what could be considered legacy systems, yet another combination of distributed technologies is often used, such as Microsoft Messaging for asynchronous communication, COM+ or Microsoft's Host Integration Server.

You will notice that the common theme among all these scenarios is one thing: Achieving distributed application communication. However, it should also be obvious that each one requires a different approach -- technology -- for arriving at a solution. And it is precisely the intent behind WCF to offer developers a one-stop approach for all the communication interfaces needed by an application.

WCF is a complementary set of .NET technologies -- not a substitute for the current .NET framework -- but if you ponder what is actually achieved by unifying Microsoft's distributed technologies under the same roof, you will grasp why WCF/Indigo is such an important part for creating service-oriented designs with more ease and is slated to be one of the cornerstones to the upcoming Microsoft operating system, Vista.

Using WCF, not only are you guaranteed that acquiring knowledge on a single approach is enough to expose many applications as a service, but you are also guaranteed that this same process takes care of the underlying details inherent in current techniques.

The actual concepts for service-enabling an application using WCF are not that different from those used to design run of the mill Web services, but the approach does differ somewhat as we will now see.

Lets assume you already have an application that produces weather forecasts. Independently of whatever interfaces it may already have – browser HTML, wireless WML, Web service SOAP/WSDL -- somewhere in its structure it will have an Interface and Class that will provide the hooks necessary to get the required weather forecast. The following listings illustrate what this Interface and Class would look like in WCF.

// Interface using WCF
using System.ServiceModel;

[ServiceContract]
interface IWeather
{
 [OperationContract]

 double Celsius(String city, int time);

 [OperationContract]
 double Farenheit(String city, int time);
}

The first declaration indicates the WCF namespace -- using System.ServiceModel -- while the interface and method statements just describe the application's actions. This is straightforward .NET syntax so there should be no surprise there. On the other hand, the bracketed statements, or attributes as they are known in .NET, represent the heart of WCF.

The [ServiceContract] bracket indicates that the interface will form the basis for a serviceable application through WCF, while the [OperationContract] declaration preceding each method specifies that the method will exposed as a service.

In services speak, the [OperationContract] is used to mark which methods will eventually become an operation described in the services WSDL contract. These WCF attributes are the most basic of its kind, however, you can specify a whole gamut of service-related behaviors to eventually make their way in a services contract. For example, for transactional support an attribute such as [OperationBehavior(RequireTransaction=true, AutoCompleteTransaction=true)] could have also been used.

Next we can put this interface to good use, designing an implementation class which is illustrated in the following listing.

// Implementation class 
class Weather : IWeather
{

 public double Celsius(String city, int time) 
 {                            
   // Perform logic, return temperature 
   // for specific city and time 
 }
      
 public double Farenheit(String city, int time)
 {
   // Perform logic, return temperature 
   // for specific city and time 
 }

 // Private method 
 private double FarenheitToCelsius(double degrees) 
 { 
   // Perform logic, return temperature in Celsius 
 }  

 // Private method 
 private double CelsiusTpFarenheit(double degrees) 
 { 
   // Perform logic, return temperature in Farenheit
 }  


}

Before we delve into the details of the implementation class using the WCF Interface you should realize that the use of this Interface/Class combo design is simply good OO practice. The use of WCF and its attributes could have just as easily been incorporated into the actual class directly.

Getting back to implementation class, the code has little if any difference from a typical .NET class, but being that the class inherits from the WCF Interface, the WCF attributes are taking effect on each of the implementation methods.

Now lets move on to where it is you actually deploy this code and what is produced by it. WCF can be deployed in one of two forms, either through Windows Activation Service (WAS), which is very similar to how you deploy ASP.NET Web Services (ASMX) in IIS, or directly in any internal application classes that need to make use of the service.

For simplicity, we will take the more familiar road through ASP.NET. In this scenario, a WCF service can either be placed entirely in a .svc file just as with ASP.NET Web services .asmx file or the WCF class could be referenced using a code-behind type declaration for DLL assemblies, like <%@Service language=c# class="Weather"%>

Finally, the WCF service needs to be bound to a particular address, a process which is done in the web.config file of the ASP.NET application. Listing 1.3 shows what this file would look like.

<?xml version="1.0" encoding="utf-8" ?>
<configuration 
    xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
   <system.serviceModel>
      <services>
         <service serviceType="SelfHostedService.Weather">
            <endpoint address="http://localhost:8080/weather" 
                   bindingSectionName="basicProfileBinding" 
                   contractType="SelfHostedService.IWeather"/>

         </service>
      </services>
   </system.serviceModel>
</configuration>

By accessing this last address specified in the web.config file, you gain access to the weather data provided by the WCF service.

In a similar fashion and for client-side purposes WCF also has utilities that allow you to generate the necessary .NET skeletons from services contracts that are needed to create a consumer application, but we will leave the details for another occasion.

With this we conclude our overview of the Windows Communication Framework, a suite that within the coming years will surely evolve into the mainstream when building service-orientated applications with Microsoft technology.

Originally published January 2006 [ Publisher Link ]

Back to Article List