Define Address in WCF Services

Windows Communication Foundation provides a flexible model for exposing service endpoints and communicating with them through a variety of different communication protocols. There are  various addressing details that surround endpoint communication, many of which enable more advanced messaging scenarios.

Endpoints and Addresses

The WCF architecture cleanly separates physical communication details from the underlying service implementation. Developers spend most of their time working with familiar Microsoft.NET Framework code to implement service contracts and to define service behavior. After the implementation is complete, they can decide how to host the service and expose it to consumers.

In order to host a particular service, you create a ServiceHost instance and define a collection of service endpoints. A service endpoint specifies an address, a binding, and a contract to use for communication. Windows Communication Foundation needs this information to build the necessary messaging runtime, also known as the channel stack, and to provide metadata in the form of Web Services Description Language (WSDL) to external consumers upon request.

You can supply service endpoints to a ServiceHost instance through code or through entries in the <system.serviceModel> configuration section. Anything you can accomplish in code, you can also accomplish in configuration and vice-versa. However, supplying endpoints via configuration usually provides greater flexibility for making post-development changes.

The ServiceHost must contain at least one service endpoint before you attempt to open it or the runtime will throw an exception; a service without at least one endpoint wouldn’t be very useful since you’d have no way to interact with it. A service can, however, expose more than one endpoint in order to accommodate multiple contracts or different types of consumers that have a wide range of capabilities or constraints.

When discussing endpoints, most folks tend to focus on the binding and contract while overlooking the endpoint address and the various issues surrounding it.

 Defining Endpoints

To use Your Service, you need to host it in a .NET-based application. The ServiceHost class gives you direct control over the WCF hosting infrastructure. You instantiate ServiceHost based on a particular service type. The following code shows how to do this in a console application:

using System;
using System.ServiceModel;
using ServiceLibrary;

class Program
{
    static void Main(string[] args)
    {
        using (ServiceHost host = new ServiceHost(
            typeof(YourServiceName), new Uri("http://localhost:8080/YourServiceName")))
        {
            ...

In addition to specifying the service type, you also specify the base addresses for the different transports you plan to use. In this example, I've specified a base address of http://localhost:8080/YourServiceName. This will be used as the base for any relative HTTP addresses I might specify when adding endpoints. The base HTTP address is also used as the default for retrieving the service description.

You then add the service endpoints. Again, a service may have one or more endpoints and each endpoint consists of an address, a binding, and a contract. You provide this information to your ServiceHost by calling AddServiceEndpoint. This is where you specify the service contract you defined earlier (IServiceInterface). For the binding, you typically choose from one of the many predefined bindings that ship with WCF and an appropriate address given the binding's transport. Here's an example:




host.AddServiceEndpoint(typeof(IServiceInterface), 
    new BasicHttpBinding(), "svc");
host.AddServiceEndpoint(typeof(IServiceInterface), 
    new NetTcpBinding(), "net.tcp://localhost:8081/echo/svc");


In this particular example, I've specified IServiceInterface as the contract for both endpoints, but with each endpoint using a different binding and address. The first endpoint uses the BasicHttpBinding and a relative HTTP address of svc (which would make its absolute address http://localhost:8080/YourServiceName/svc). The second endpoint uses the NetTcpBinding and an address of net.tcp://localhost:8081/YourServiceName/svc. Therefore, this service allows consumers to communicate with it over either HTTP or TCP using different WS-* protocols, as defined by each binding.