How Does a WCF Service Work?

Functionally, a WCF service is just an object that exposes a set of operations that client applications can invoke. When building a service, you describe the operations for a service by using a service contract and then create a class that implements this contract. To execute the service, you have to provide a runtime environment for this object and then make the object available to client applications. The runtime environment for an object implementing a service is provided by a host application. You have already seen that you can use IIS to provide such a runtime environment. You can also create your own application to act as a host.

A host application has to perform a number of tasks, including:

• Starting and stopping the service

• Listening for requests from a client application and directing them to the service

• Sending any responses from the service back to the client applications

To understand more about how a host application works, it is helpful to look in more detail at service endpoints and the way in which the WCF runtime uses the binding information specified in endpoints to enable client applications to connect to the service.

Service Endpoints

A host application makes a service available to client applications by providing an endpoint to which clients can send requests. An endpoint contains three pieces of information:

1. The address of the service. The form of a service address depends on several factors, including the transport protocol being used. Different transport mechanisms use different address spaces. For example, in Chapter 1, “Introducing Windows Communication Foundation,” you deployed a service to IIS using the address http://localhost/ProductsService/ProductsService.svc. This address specifies the virtual directory and the service definition (.svc) file. If you build your own custom host application, you can use a different transport mechanism, and you must specify an address that is appropriate to your chosen transport mechanism.

2. The binding supported by the service. The binding for a service describes how a client can connect to the service and the format of the data expected by the service. A binding can include the following information:

   • The transport protocol. This must conform to the requirements of the service address. For example, if you are using IIS to host the service, you should specify the HTTP or HTTPS transport protocol. WCF also has built-in support for the TCP protocol, named-pipes, and message queues. You will see examples of addresses specified by using some of these transport schemes later in this chapter.

   • The encoding format of messages. In many cases, request and response messages will be transmitted in XML format, encoded as ordinary text. However, in some cases you might need to transmit data using a binary encoding, especially if you are transmitting images or handling streams. You will learn more about using an appropriate encoding for messages in Chapter 12, “Implementing a WCF Service for Good Performance.”

   • The security requirements of the service. You can implement security at the transport level and at the message level, although different transport protocols have their own limitations and requirements. You will learn more about specifying the security requirements for a service in Chapter 4, “Protecting an Enterprise WCF Service,” and in Chapter 5, “Protecting a WCF Service over the Internet.”

   • The transactional requirements of the service. A service typically provides access to one or more resources. Client applications update these resources by sending requests to the service. If a client makes multiple requests of a service that result in multiple updates, it can be important to ensure that all of these updates are made permanent. In the event of a failure, the service should undo all of these updates. This is the definition of a transaction. You will learn more bout building WCF services that support transactions in Chapter 8, “Supporting Transactions.”

   • The reliability of communications with the service. Clients usually connect to services across a network. Networks are notoriously unreliable and can fail at any time. If a client application is performing a conversation (an ordered exchange of several messages) with a service, information about the reliability of the service is important. For example, the service should try and ensure that it receives all messages sent by the client and receives them in the order that the client sent them. A service can ensure the integrity of conversations by implementing a reliable messaging protocol. You will learn more about reliable messaging in Chapter 9, “Implementing Reliable Sessions.”

3. The contract implemented by the service. A WCF service contract is an interface stored in a .NET Framework assembly and annotated with the [ServiceContract] attribute. The service contract describes the operations implemented by the service by tagging them with the [OperationContract] attribute. Any data passed to and from operations must be serializable. A service can define data contracts describing the structure of complex data and how this data should be serialized. The service can publish the description of its service contract, which a client application can use to ascertain the operations that the service implements and send messages that are correctly formatted.

Processing a Client Request

A service can respond to requests from multiple client applications simultaneously. To achieve this feat, the application hosting the service must be able to accept multiple incoming requests and direct service responses back to the appropriate client. Additionally, the host application must ensure that messages being sent between the client and service conform to the security, reliability, and transactional requirements of the binding being used. Fortunately, you don’t have to write this functionality yourself. The WCF runtime environment provides a collection of channel objects that can perform this processing for you.

A channel is responsible for handling one aspect of message processing, as specified by the bindings of a service. For example, a transport channel manages communications by using a specific transport protocol, and a transaction channel controls the transactional integrity of a conversation. The WCF runtime provides built-in channels for each of the supported transport protocols. The WCF runtime also provides channels that handle the different ways that WCF can encode data, manage security, implement reliability, and perform transactions. The WCF runtime composes channels into a channel stack. All messages passing between the client and the service go through each channel in the channel stack. Each channel in the channel stack transforms the message in some way, and the output from one channel is passed as input to the next. The channel stack operates in two directions–messages received from clients across the network proceed up the channel stack to the service, and response messages sent back from the service traverse the channel stack in the opposite direction back to the network and then to the client. If a channel cannot process a message, it reports an error, an error message is sent back to the client, and the message is not processed any further.

Note 

There is an order to the channels in the channel stack. A transport channel always resides at the bottom of the stack and is the first channel to receive data from the network. On top of the transport channel will be an encoding channel. These two channels are mandatory. The remaining channels in a stack are optional.

When you start a service running, the WCF runtime uses the endpoint information specified as part of the service configuration and creates a listener object for each address specified for the service. When an incoming request is received, the WCF runtime constructs a channel stack by using the bindings specified for the address and routes the incoming data from the client through the stack. If a message successfully traverses all the channels in the channel stack, the transformed request is passed to an instance of the service for processing.

Note 

The channel model used by WCF makes the WCF framework very flexible. If you need to add a new transport protocol or implement an additional piece of functionality, you can write your own channel to perform the processing required and link it into the channel stack by adding it to the binding description of the service. However, this task is beyond the scope of this book.

The WCF runtime creates an InstanceContext object to control the interaction between the channel stack and the service instance. You can modify the way in which the WCF runtime instantiates the service through the InstanceContext object by specifying the [ServiceBehavior] attribute of the class implementing the service contract. The ServiceBehavior attribute has a property called InstanceContextMode, which can take the values shown in Table 2-1.

Table 2-1: InstanceContextMode Values
Open table as spreadsheet

Value	Description
InstanceContextMode.PerCall	A new instance of the service will be created every time a client calls an operation. When the call completes, the service instance is recycled.
InstanceContextMode.PerSession	If the service implements sessions, a new instance of the service will be created at the start of the session and recycled when the session completes. A client can call the service several times during a session. However, the service instance cannot be used across more than one session. For more information about using sessions, see Chapter 7, “Maintaining State and Sequencing Operations.”
InstanceContextMode.Single	Only one instance of the service is created and is shared by all clients and all sessions. The instance is created when the first client attempts to access it.

You can specify the InstanceContextMode property for a service like this:

 [ServiceBehavior (InstanceContextMode=InstanceContextMode.PerSession)] public class ProductsServiceImpl : IProductsService {   … }

A WCF client application can communicate with a WCF service by using a proxy class. You can generate this proxy class by using Visual Studio 2005 (as you did in Chapter 1) or by using the svcutil utility from the command line. This proxy class implements a channel stack on the client side. You configure this channel stack in the same way that you do for a service, by using bindings. All responses received from a service pass through the channels in this stack. To communicate successfully, the client and the service should use an equivalent channel stack containing a compatible set of bindings.