Should you wish to use a service offered by a particular service provider in a service-oriented world, you are not normally supplied with any DLLs or other binaries. Instead, the WDSL document, which is provided by the service provider, is all the client and server have in common. This document contains all the requisite details, such as service operations, structure of the data being exchanged, as well as any policies such as security and reliability about how the service deals with extended functionalities.

This variant makes sense and is recommended in a loosely coupled system. The client does not require any knowledge of the internal implementation, but relies solely on the WDSL document supplied. Because the client does not share any code with the service, it does not necessarily have to be a .NET client either. It might, for example, also be a PHP or Java application.

If you use a .NET application as a client, you generally don't program directly contrary to the service offered; you rely on the functionalities of a generated proxy. The proxy takes on such tasks as sending SOAP messages to the service, receiving the response, and making it available as an object. In addition to the service operations provided, the WCF proxy also features additional functions such as opening and closing, or other properties such as the endpoint or the inner channel to read out the session ID or endpoint-specific information.

The proxy is normally generated by using Add Service Reference, as shown in Figure 4-1, or the svcutil.exe tool. If you are in Visual Studio, it is definitely simpler and more convenient to proceed via the Add Service Reference menu. If when you create the proxy, however, you require options other than those offered by the Add Service Reference dialog box shown in Figure 4-2, or you wish to export service metadata from an assembly, you can also use svcutil.exe directly.

Figure 4.1. FIGURE 4-1

Figure 4.2. FIGURE 4-2

If you add a service reference, you will essentially receive two files:

The code which is generated by svcutil.exe extends the base class System.ServiceModel.ClientBase<T> and implements the service interface and, thus, the service operations which are provided. The service data classes are also replicated on the client side and are assigned the attributes [DataContract] and [DataMember]. In principle, the ClientBase<T> class is nothing other than a wrapper for the ChannelFactory<T> class and is a quick and easy way of communicating with the service.

For example, the service code in Listing 4-1 would lead to the following client artifacts displayed in Listings 4-2 through 4-4.

using System;
using System.ServiceModel;

namespace Wrox.CarRentalService.Contracts
{
    [ServiceContract(
     Namespace = "http://wrox/CarRentalService/2009/10",
     Name = "RentalService")]
    public interface ICarRentalService
    {
        [OperationContract()]
        PriceCalculationResponse CalculatePrice
            (DateTime pickupDate, DateTime returnDate,
            string pickupLocation, string returnLocation);

        [OperationContract]
        Guid  Confirm(Guid requestID);

        [OperationContract()]
        void  ReportCrash
           (DateTime date, String location, Guid  confirmationID);
    }
}

[System.ServiceModel.ServiceContractAttribute(
Namespace="http://wrox/CarRentalService/2009/10",
ConfigurationName="CarRentalProxy.RentalService")]
public interface RentalService {

[System.ServiceModel.OperationContractAttribute(
Action="http://wrox/CarRentalService/2009/10/RentalService/CalculatePrice",ReplyAction="http://wrox/CarRentalService/2009/10/RentalService/
CalculatePriceResponse")]
Wrox.CarRentalService.ConsoleClient.CarRentalProxy.PriceCalculationResponse
       CalculatePrice(
            System.DateTime pickupDate, System.DateTime returnDate,
            string pickupLocation, string returnLocation);

[System.ServiceModel.OperationContractAttribute(AsyncPattern=true,
Action="http://wrox/CarRentalService/2009/10/RentalService/CalculatePrice",

ReplyAction="http://wrox/CarRentalService/2009/10/RentalService/
CalculatePriceResponse")]
System.IAsyncResult BeginCalculatePrice
                   (System.DateTime pickupDate, System.DateTime returnDate,
                    string pickupLocation, string returnLocation,
                    System.AsyncCallback callback, object asyncState);

Wrox.CarRentalService.ConsoleClient.CarRentalProxy.PriceCalculationResponse
                 EndCalculatePrice(System.IAsyncResult result);

public partial class RentalServiceClient :
          System.ServiceModel.ClientBase
             <Wrox.CarRentalService.ConsoleClient.CarRentalProxy.RentalService>,
             Wrox.CarRentalService.ConsoleClient.CarRentalProxy.RentalService
{

<configuration>
    <system.serviceModel>
        <client>
            <endpoint address="http://localhost:9876/WroxCarRentalService"
                binding="basicHttpBinding"
                contract="CarRentalProxy.RentalService" />
        </client>
    </system.serviceModel>
</configuration>

When you use the proxy as shown in Listing 4-5, you must remember to close it if you no longer require it. Or you may also use the proxy within a using statement to guarantee that the Dispose method is called up automatically at the end and valuable resources are released.

namespace Wrox.CarRentalService.ConsoleClient
{
    class Program
    {
        static void Main(string[] args)
        {

            using (CarRentalProxy.RentalServiceClient
                  rentalServiceClient = new
                  CarRentalProxy.RentalServiceClient())
            {
                 CarRentalProxy.PriceCalculationResponse resp = null;

resp = rentalServiceClient.CalculatePrice
                      (DateTime.Now, DateTime.Now.AddDays(5),
                       "Graz", "Vinna");
                      Console.WriteLine("Price to Vienna {0}",
                                         resp.Price);
            }
            Console.WriteLine("Proxy closed");
        }
    }
}

If you are responsible both for the server and for the client implementation and have complete control of the code which is created, it may make sense under certain circumstances to prevent new data classes from being created every time the service reference is added, which would cause it to be duplicated and therefore require multiple maintenance. Shared data contracts can also be used to prevent your code from looking different on the server side and on the client side. For example, List<string> on the server side would become a string array on the client side. Some aspects could be controlled by the Add Service Reference - Advanced dialog box as well.

In these cases you can assign the parameter /r to svcutil.exe as an instruction to use data classes from a referenced DLL and not to create any new data classes. Another advantage of shared data classes is that you can use data classes of any complexity provided they can be serialized.

The service class is still supplied to your client code in the form of a proxy which is inherited by System.ServiceModel.ClientBase<T>, and which the service interface implements. However, the service data classes are no longer simulated on the client side. They are loaded directly from the shared assembly.

The narrowest form of binding between the client and server generally involves dispensing with a WSDL document and making direct reference instead to the ServiceContract or DataContract assemblies. Of course, this is only possible and worthwhile in a very closely coupled system in which you have absolute control of the client and server code. The ChannelFactory class is used for communication with the service, not the proxy which is created, as shown in Listing 4-6. ChannelFactory objects are used primarily in middle-tier scenarios, where the aim is to increase performance where there is no need to instantiate a new proxy for every client every time. The ChannelFactory object, however, is simply used to open a separate channel for each client. Furthermore, in environments in which frequent changes are made to the service contract (most notably at the start of a project), it may make perfectly good sense and be helpful not to create a new proxy code every time, but to use the server assembly directly.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ServiceModel;
using Wrox.CarRentalService.Contracts;

namespace Wrox.CarRentalService.ConsoleClient
{
    class Program
    {
        static void Main(string[] args)
        {
            ChannelFactory<ICarRentalService> factory = null;
            try
            {
                BasicHttpBinding binding = new BasicHttpBinding();
                EndpointAddress address = new
                  EndpointAddress("http://localhost:9876
                                           /WroxCarRentalService");

                factory = new
                  ChannelFactory<ICarRentalService>(binding, address);

                ICarRentalService channel = factory.CreateChannel();

                PriceCalculationResponse resp =
                     channel.CalculatePrice
                          (DateTime.Now, DateTime.Now.AddDays(5),
                           "Graz", "Wien");
                Console.WriteLine("Price to Wien {0}", resp.Price);

                factory.Close();
            }
            catch (CommunicationException)
            {
                if (factory != null)
                {
                    factory.Abort();
                }
            }
            catch (TimeoutException)
            {
                if (factory != null)
                {
                    factory.Abort();
                }
            }
            catch (Exception ex)
            {
                if (factory != null)

{
                    factory.Abort();
                }
                Console.WriteLine(ex.ToString());
            }

            Console.WriteLine("Proxy closed");
        }
    }
}

In the sample displayed in Figure 4-3, the client makes direct reference to the service assembly and to the DataContract assembly.

However, there is no need for a reference to specific implementation of the service class because communication between the client and the server still takes place via the standard WCF route.

WCF not only provides a platform for SOAP messages, it is also a means of offering RESTful services.

The essential components that allow you to create a REST application can be found in System.ServiceModel.Web.dll. The most important elements of a REST application include the [WebGet] and [WebInvoke] attributes and the new binding webHttpBinding in connection with the webHttp endpoint behavior.

Should you wish to create a RESTful solution from your SOAP-based solution, theoretically you would simply have to change the binding to webHttpBinding and configure the endpoint with the webHttp behavior.

This binding has the following effect: If you send a SOAP message to an endpoint in a classical SOA environment, the content of the message will normally be checked first. The correct operation will be called up depending on the content of the message.

In REST, however, the method which is called up is dependent on the URL and on the verb used. This altered dispatch behavior is made possible by the binding webHttpBinding and the webHttp endpoint behavior. Furthermore, the WebHttpBehavior class or the endpoint behavior also enables you to choose from two different serialization formats:

The service contract shown in Listing 4-7 in connection with the changed configuration displayed in Listing 4-8 would, for example, prompt you to make a POST at http://localhost:1234/HelloWorld, resulting in a receipt of an XML document with "Hello World".

[ServiceContract()]
    public interface ICarRentalService
    {
        [OperationContract]
        string HelloWorld();

<configuration>
  <system.serviceModel>
      <services>
      <service name="Wrox.CarRentalService">
        <endpoint

address="http://localhost:1234/"
             contract="Wrox.ICarRentalService"
             binding="webHttpBinding"
             behaviorConfiguration="web"/>
      </service>
    </services>
    <behaviors>
      <endpointBehaviors>
        <behavior name="web">
          <webHttp/>
        </behavior>
      </endpointBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

Instead of the configuration entries in the config file, you can also use the new WebServiceHost class. The WebServiceHost class inherits from ServiceHost and automatically assigns the correct binding and behavior to your endpoint. Consequently, you no longer need to be concerned about the content of your configuration file and you can host your service without a config file. Alternatively, if you are hosting your service in IIS, you can use the WebServiceHostFactory class. For example:

<% @ServiceHost Factory= "System.ServiceModel.Web.WebServiceHostFactory"

The configuration file could remain blank with the server code shown in Listing 4-9.

namespace Wrox.ConsoleHost
{
    class Program
    {
        static void Main(string[] args)
        {
            WebServiceHost webHost = null;
            try
            {
                webHost = new WebServiceHost(
                       typeof(Wrox.CarRentalService),
                       new Uri("http://localhost:1234")
                       );
                webHost.Open();
                Console.ReadLine();
            }
            catch (Exception ex)
            {
                if (webHost != null)

webHost.Abort();
            Console.WriteLine(ex.ToString());
            }
        }
    }
}

However, the disadvantage of this standard webHttpBinding behavior in conjunction with enableWeb is that, firstly, POST is used as a standard verb and, secondly, the URL used is simply the name of the method. However, this does not reflect the idea behind REST. In contrast to SOA, it is not the messages which are of prime importance; instead it is the resources, the URLs, and the verbs used.

You can obtain complete control of the URL being used by using the two attributes [WebGet] and [WebInvoke] in combination with your OperationContract attribute (the OperationContract attribute is obsolete).

Use [WebGet] whenever you require read-access to the resource, i.e., when you wish to use the HTTP verb GET.

Use [WebInvoke] for all other scenarios (POST, PUT, DELETE).

[WebGet] and [WebInvoke] also give you the opportunity to use a URI template with constant and variable parts. Furthermore, these two attributes also allow you to determine the serialization format (XML or JSON).

Listing 4-10 shows examples of how [WebGet] and [WebInvoke] are used (assumption of the base address http://localhost:1234).

namespace Wrox
{
    public class Car
    {
        public string Name { get; set; }
        public string Make { get; set; }
        public string Type { get; set; }
        public int Seats { get; set; }
    }

    [System.Runtime.Serialization.CollectionDataContract(Name="Cars")]
    public class CarPool: List<Car>
    {
        private CarPool()

{
            this.Add(new Car() { Name = "Dakota",
                 Make = "Dodge", Type = "Pickup Truck", Seats = 8 });
            this.Add(new Car() { Name = "TT",
                 Make = "Audi", Type = "Sport Car", Seats = 2 });
        }
        private static CarPool AllCars = null;

        public static CarPool GetCarPark()
        {
           if (AllCars ==null)
               AllCars = new CarPool();

            return AllCars;
        }

    }

    [ServiceContract()]
    public interface ICarRentalService
    {
        [OperationContract]
        string HelloWorld();

        [OperationContract]
        [WebGet(UriTemplate = "/CarPool")]
        CarPool GetAllCars();

        [OperationContract]
        [WebGet(UriTemplate = "/CarPool/{carName}")]
        Car GetCar(string carName);

        [OperationContract]
        [WebGet(UriTemplate="/CarPool/{carName}?format=xml",
        ResponseFormat = WebMessageFormat.Xml)]
        Car GetCarXML(string carName);

        [OperationContract]
        [WebGet(UriTemplate = "/CarPool/{carName}?format=json",
        ResponseFormat = WebMessageFormat.Json)]
        Car GetCarJSON(string carName);

        [OperationContract]
        [WebInvoke(UriTemplate = "CarPool/{carName}", Method = "PUT")]
        Car AddCar(string carName, Car car);

        [OperationContract]
        [WebInvoke(UriTemplate = "/CarPool/{carName}",
        Method = "DELETE")]
        void DeleteCar(string carName);

    }

[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single)]
    public class CarRentalService: ICarRentalService
    {
        public string HelloWorld()
        {
            WebOperationContext.Current.OutgoingResponse.StatusCode =
                System.Net.HttpStatusCode.OK ;
            return "Hello World";
        }
        public CarPool GetAllCars()
        {
            return CarPool.GetCarPark();
        }

        public Car  GetCar(string carName)
        {
            return CarPool.GetCarPark().Find(e => e.Name == carName);
        }
        public Car GetCarXML(string carName)
        {
            return GetCar(carName);
        }
        public Car GetCarJSON(string carName)
        {
            return GetCar(carName);
        }
        public void DeleteCar(string carName)
        {
            Car found = CarPool.GetCarPark().Find
               (e => e.Name == carName);
            if (found == null)
                WebOperationContext.Current.OutgoingResponse
                   .SetStatusAsNotFound();
            else
                CarPool.GetCarPark().Remove(found);

        }

       public Car AddCar(string carName, Car car)
        {
            WebOperationContext.Current.OutgoingResponse
                .SetStatusAsCreated
             (
                new Uri("http://localhost:1234/CarPool/" + car.Name)
             );
            CarPool.GetCarPark().Add(car);
            return car;
        }

    }
}

In the following example, the HTTP GET URL is fixed text and does not contain a variable element.

[OperationContract]
[WebGet(UriTemplate = "/CarPool")]
CarPool GetAllCars();

This is how the operation GetAllCards can be invoked (Sending a HTTP GET to the address below).

GET http://loalhost:1234/CarPool
[OperationContract]
[WebGet(UriTemplate = "/CarPool/{carName}")]
Car GetCar(string carName);

When the following line is invoked, Leon is passed as the variable {carName} to the operation GetCar (Sending an HTTP GET to the address below):

GET http://localhost:1234/CarPool/Leon

The following example is similar to the previous example. {carName} is written to the variable carName. Furthermore, a fixed query string is also stated, and the response format is set to JSON.

[OperationContract]
[WebGet(UriTemplate = "/CarPool/{carName}?format=json", ResponseFormat =
WebMessageFormat.Json)]
Car GetCarJSON(string carName);

As shown in the following example, in contrast to WebGet, the verb can be specified in WebInvoke. The variable carName is taken from the URL and the content of the car object is taken from the request body.

[OperationContract]
[WebInvoke(UriTemplate = "CarPool/{carName}", Method = "PUT")]
Car AddCar(string carName, Car car);

You previously saw how the new webHttpBinding is used together with webHttp and [WebGet] or [WebInvoke] to assist in creating a RESTful application. The addressable resources are defined with the aid of URI templates, and you can use the RequestFormat or ResponseFormat properties to determine whether to use XML or JSON as the format. The intuitive API is made possible by using HTTP verbs.

Use HTTP status codes and HTTP headers to determine whether an operation was successful or whether, for example, a resource has limited accessibility and can be retrieved only with a username and password. Access to these HTTP-specific elements is obtained via the WebOperationContext.

If a call was successful, for example, the status code returned would be 200, whereas 403 would be returned if a resource was not found. To help you to work with these status codes, you can either use the enum System.Net.HttpStatusCode or auxiliary methods from the OutgoingWebResponseContext class.

The following line would return a status code 200 from the service.

WebOperationContext.Current.OutgoingResponse.StatusCode =
System.Net.HttpStatusCode.OK ;

On the contrary, the following line would return a status code 403 (Resource not found):

WebOperationContext.Current.OutgoingResponse.SetStatusAsNotFound();

In contrast to WCF with SOAP, the REST variant does not provide any means of creating a WSDL document. Therefore, the quick and easy variant Add Service Reference is not available.

However, this isn't altogether disadvantageous; it also brings with it certain advantages. As the use of the REST API is limited to a few verbs and avoids the exchange of complicated SOAP messages, a separate proxy is relatively easy to create with a suitable stack which supports HTTP, verbs, and status codes.

For example, you could use System.Net.WebRequest and System.Net.WebResponse for this purpose or leverage the WebChannelFactory class from the System.ServiceModel.Web.dll. In this case you also have absolute control over communication between the server and client and do not have to worry about any hidden activities and functionalities in the proxy you create.

In contrast to SOAP, REST is also interoperable to a higher degree because it is theoretically sufficient if the client has a command of HTTP and XML or JSON. Therefore, there is no need for an extensive SOAP stack with the support of all the WS* protocols to communicate with the REST service.

Because support for REST has only been available since .NET Framework 3.5 and there is still a lack of support in some areas (error handling, hosting, client, caching), you can also revert to using the REST Starter Kit. The REST Starter Kit is available as a download in CodePlex and offers a wide range of classes and extension methods for programming with REST on the server side and for REST calls on the client side.

The server-side functionality which can be found in the Microsoft.ServiceModel.Web.dll assembly includes, for example, simplified working with status codes, intuitive error handling with throw, ASP.NET-based caching support, and a separate service host which saves you having to create a documentation page manually. The generated help page is created similar to WSDL on the basis of your service code and can be adapted further by using [WebHelp].

HttpClient is surely the most important class on the client side. This class simplifies how REST operations are called up and supports GET, PUT, DELETE, and POST. The entire client functionality is located in the Microsoft.Http.dll assembly and in Microsoft.Http.Extensions.dll.

Listing 4-11 illustrates how the HttpClient class is used to send a GET request for a readout of all available cars. Furthermore, the use of the PUT method is also demonstrated in this example.

namespace Wrox.RestClient
{
    class Program
    {
        static void Main(string[] args)
        {
            using (HttpClient restClient = new HttpClient())
            {
                HttpResponseMessage resp =
                restClient.Get("http://localhost:1234/CarPool");
                    resp.EnsureStatusIsSuccessful();
                Console.WriteLine(resp.Headers.ToString());

                var result = resp.Content.ReadAsString();

                Console.WriteLine(result);

                string newCar = "<Car
                xmlns="http://schemas.datacontract.org/2004/07/Wrox">
                <Make>Seat</Make><Name>Leon</Name>
                <Seats>5</Seats><Type>Sport Car</Type></Car>";

                restClient.Put("http://localhost:1234/CarPool/Leon",
                    "application/xml",
                    HttpContent.Create(newCar));
                Console.WriteLine(resp.StatusCode);

            }
        }
    }
}

Therefore, the REST Starter Kit provides you with an extensive collection of classes and methods which is worth taking a look at. However, the starter kit not only contains the assemblies, it also contains the entire code from which you can also get a wide range of ideas for implementing your REST application.