Stuart Williams

Subscribe to Stuart Williams: eMailAlertsEmail Alerts
Get Stuart Williams: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: SOA & WOA Magazine

SOA & WOA: Article

ASP.NET (SOA) Web Services - Windows Communication Foundation Services

Use tomorrow's messaging system today! A Guide for MORT

This article attempts to explain and demo, at the simplest level, how developers can consume Windows Communication Foundation (WCF) services. It's helpful to understand ASP.NET Web services and have used them before reading this article.

What Is WCF Anyway?
WCF is Microsoft's name for its technology that unifies the programming model for interoperability. By using WCF we can connect to SOAP services (such as .NET, ASMX, or WebSphere). WCF also allows developers, especially front-end developers, to consume such services easily. Furthermore it allows service developers to leverage a number of useful WS* standards such as transactions, security, reliable delivery, messaging, etc. - but that's another article.

See Figure 1

And Why Do I Care?
If you're working by yourself or in a small shop that does mostly tactical applications, you may not care. For those developers working in enterprise environments, WCF, like SOAP Web services, will be created for use by user interfaces by others in your organization and increasingly, by third parties.

The 100,000-Foot View
In theory, consuming a WCF service is like consuming a Web service, as Figure 2 shows. There are some differences, however, as Table 1 describes.

Contract First
WCF encourages "contract first" development, e.g., both sides agree on what the interface should be and what the interface elements do, and then it is implemented. For WCF services, WSDL provides this description - the contract between the two sides. WinFX provides tools for building an outline of a WCF service based on a WSDL or for writing code and configuration for consuming the service (as we will see in a bit). Contract-first development has the advantage that (in theory) the implementation is transparent to both ends. In addition to a contract about what the service exposes (and hopefully what it means semantically), an agreement has to be reached about how the two ends will communicate, for example: Do we need transactions? What protocol? etc. WCF services can expose multiple "endpoints" that each represents an agreement about what protocols and facilities (like transactions or reliable delivery) will be used. For this example, however, we choose to take a class that implemented an interface and turn it into a WCF service. As we'll see below in the service code, using an interface to define the contract allows us to build any number of services that all implement the contract.

On a side note, even though a WCF service can expose multiple endpoints, a client must choose what endpoint they are connecting to. In the sample client code, the client is connecting to a service with only one endpoint, so that endpoint is assumed. (Note: This may change in future releases where the name of the endpoint must be specified.)

See Figure 3

In WCF, services can be thought of by using the ABC mnemonic:

  • Address: Where is the service?
  • Binding: How will we interact with it?
  • Contract: What does it do?
Three Reasons to Love WCF
  1. The things that are the most volatile, Address and Binding, are in configuration where they can be changed/configured at deployment or as part of an operational process
  2. The amount of code developers have to write to leverage WS* features such as security, transactions, reliable delivery, etc. is greatly reduced or is transparent (or nearly so), thus dramatically reducing the amount of code that developers have to write, testers have to test, and so on
  3. It's easier to consume SOAP services written on other platforms (like IBM WebSphere) because of the great interoperability and tools support provided by WCF
A Quick Look at the Service Code
For the purposes of this article, we wrote (as much as possible) a simple implementation of a WCF service that we are hosting as an IIS Web site. Until the next generation of Windows O/S comes out (Longhorn), IIS will be the most common host of WCF services. http://localhost/cookie is the default location for the sample service.

The service generates a funny saying from a list (for simplicity, it's a small array hard coded into the service) and exposes two methods:

  • string GetCookieMessage() - This returns a random message
  • int GetCookieCount() - This gets the number of messages
The entire service looks like Listing 1.

The code in the method GetCookie-Message() is a bit verbose but it's easier to step through. Also, if we were getting the list of messages from somewhere else, we would want to check to make sure the array is not null or empty before executing.

One of the things that leaps out is that there isn't much code to make it a service and that the programming model is a little different. This article is about how to use a service someone has written, but it's worth highlighting a few interesting code artifacts.

To make our service work we need to define a web.config, which (among other things) exposes the available connections (endpoints in WCF).

<?xml version="1.0" encoding="utf-8" ?>
<service serviceType="CookieQuoteService" >
<endpoint address="" bindingSectionName="basicProfileBinding"
It's worth looking at some of the new configuration sections and items.

Consuming the Web Service
Assuming code for the article is downloaded, configured, and installed, we can now make a client to consume it. Make sure you can browse to your Web service and get a screen that looks like Figure 4.

More Stories By Stuart Williams

Stuart Williams is a principal consultant architect for Magenic Technologies ( and a dual-certified Microsoft Gold Partner based in the San Francisco Bay Area. In his spare time he does geeky stuff, runs Blitzkrieg Software (, and plays cards.

Comments (2)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.