RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Configuring WCF Services and Getting Them Ready to Ship

Get your WCF services production ready by learning all the configurable entities that make a WCF service rock solid and ready to ship.

ervices built on the Windows Communication Foundation (WCF) platform provide a lot of flexibility to the developer. The premise of WCF is that a developer can build a service once and then deploy it as different endpoints simply by changing the configuration files. In essence, WCF is all about how you configure your services, but manipulating a configuration file involves a lot of details that developers can easily overlook. Whenever developers in large teams change configuration files, for example, unexpected errors surface. The teams get better as they learn the patterns in the configuration files, but that takes a while.

This article will save you some pain in deploying WCF services. Based on experience with a number of real projects that use WCF, this article walks you through the most essential elements of a WCF configuration—elements that you need to understand to make a stable release. A TCP endpoint is used to illustrate the WCF configuration concepts, but these concepts can apply to most other endpoints.

Reading this article and working with its sample configuration entries will give you a good understanding of all the necessary configurable entities that make a WCF service rock solid and ready to ship. The accompanying code sample shows both a bare-bones version and a ready-to-ship version.

You will need to be familiar with WCF to follow along. For an introduction to WCF, please refer to the DevX article "The Windows Communication Foundation: A Primer."

Basic, Bare-Bones Configuration
When you create a WCF library in Visual Studio, Visual Studio tries to help you create the App Config file by anticipating and providing everything you need (see Sidebar 1. Differences in Config Files Created by Dynamic Proxy and by Static Proxy). But not all the sections created by Visual Studio are required to launch a bare-bones configuration (See the downloadable code for a bare bones example).

Let's start at the very top of the config file:


This article uses the example of an order-processing service (IOrderService) that supports two methods (ProcessOrder(); and GetAllOrdersForUser();) . Here is the contract for OrderService:

public interface IOrderService
        bool ProcessOrder(List<Order> orderList);

        List<Order> GetAllOrdersForUser(int userId);

        // TODO: Add your service operations here

The service is implemented by a class (OrderService):

public class OrderService : IOrderService
        public bool ProcessOrder(List<Order> orderList)
            Console.WriteLine("Your order is processed");
            return true;

        public List<Order> GetAllOrdersForUser(int userId)
             List<Order> orderList = new List<Order>();
   Console.WriteLine("came to                 GetAllOrdersForUser");
            return orderList;        }

These methods are not fully implemented at this point, but this code is enough to get the service exposed and reachable.

You need to add a service section to the <Services> node in the config file. The service requires an element called name, which has to be the fully qualified class name of the class that implements the interface:

      <service name="OrderService.OrderService"></service>

Instead of depending on the fully qualified name, you could specify a human-readable name and use it on the Service class, in this case OrderService:

[ServiceBehavior ( ConfigurationName = "OrderProcessingService")]

The benefit of this approach is that it explicitly maps the section to the code.

In order to reach the service from outside, you need to specify an endpoint. This endpoint will have the following address:

<endpoint address="net.tcp://localhost:1973/orderservice" binding="netTcpBinding" 

The endpoint requires, at the bare minium, an address, a binding, and a contract (the ABC of a service). The Address is where someone can call the service. In this case, the Net.TCP service is running in port 1973 and has a Binding, which is Net.TCP. This service is exposing a Contract called IOrderService. (See Sidebar 2. Securing Service Endpoints.)

This is all you need to make a service usable. Note that there is no metadata exchange (MEX) binding or any way to discover WSDL. All you need to do in the client is share the contract and you should be able to consume the service. The client section of the App Config file looks like this:

<endpoint address="net.tcp://localhost:1973/orderservice" binding="netTcpBinding"
                bindingConfiguration="" contract="OrderService.IOrderService"

The next section explains how to get the order service ready to ship.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date