Windows Communication Foundation (WCF) is the latest service execution environment from Microsoft that enables you to seamlessly expose CLR types as services and consume services as CLR types. WCF is a unified programming model that combines the best of breed features from XML Web Services, .NET Remoting, MSMQ, and COM+ into an integrated platform that is completely based on a set of open industry standards. Because of that, WCF provides interoperability between services, and it promotes productivity, including the essential off-the-shelf plumbing required by almost any application. Here we will discuss the essential building blocks of WCF describing the concepts and architecture of WCF
Key Components of a WCF Service
A WCF service program contains four elements:
- Contract definitions - A service must have at least one service contract, and it might contain multiple service contracts, data contracts, or message contracts
- Endpoint definitions - One or more address-binding-contract endpoints must be declared
- Hosting code - Some code is needed to create and start the service
- Implementation code - The service contracts in a service need code to implement their service operations
Let us look at each of these components in detail.
Understanding Contracts
Contracts are one of the fundamental concepts in WCF. They allow clients and services to have a common understanding of available operations, data structures, and message structures while remaining loosely coupled and platform independent. WCF includes four kinds of contracts:
- Service contract - Describes the operations a service can perform. A service contract is defined with the [ServiceContract] and [OperationContract] attributes. Binding requirements can be specified for the contract with a [BindingRequirements] attribute.
- Data contract - Describes a data structure. A data contract is defined primarily with the [DataContract] and [DataMember] attributes.
- Message contract - Defines what goes where in a message. A message contract is defined primarily with the [MessageContract], [MessageBodyMember], and [MessageHeader] attributes.
- Fault contract - Allows you to document the errors that WCF code is likely to produce. A fault contract is specified along with the operation contract at the time of declaring the method. A fault contract is defined using the [FaultContract] attribute.
All four types of contracts translate between Microsoft .NET types used internally and the XML representations shared externally:
- A service contract converts between the CLR and Web Services Description Language (WSDL)
- A data contract converts between the CLR and XML Schema Definition (XSD)
- A message contract converts between the CLR and Simple Object Access Protocol (SOAP)
- A fault contract converts the CLR exceptions and to SOAP faults
You define contracts by using familiar object-oriented constructs: interfaces and classes. By decorating interfaces and classes with attributes, you create contracts.
Understanding Service Contracts
A service contract describes the operations a service can perform. A service must have at least one service contract, and it can have more than one. You can think of a service contract as follows:
- It describes the client-callable operations (functions) exposed by the service
- It maps the interface and methods of your service to a platform-independent description
- It describes message exchange patterns that the service can have with another party. Some service operations might be one-way; others might require a request-reply pattern
- It is analogous to the
element in WSDL
You define a service contract by annotating an interface (or class) with the [ServiceContract] attribute. You identify service operations by placing [OperationContract] attributes on the methods of the interface. The following service contract defines only one service operation.
[ServiceContract]
public interface IHelloWorldService
{
[OperationContract]
string HelloWorld (string input);
}
Once you define a service contract using an interface, you can write a class to implement the interface. For example:
public class HelloWorldService : IHelloWorldService
{
public string HelloWorld(string input)
{
return "Hello " + input;
}
}
It is also possible for you to define the service contract directly against the implementation class and skip the interface altogether. The following class both defines and implements a service contract.
[ServiceContract]
public class HelloWorldService
{
[OperationContract]
public string HelloWorld(string input)
{
return "Hello " + input;
}
}
Although this approach works, it is not a recommended way to create services as interfaces allow you to separate the implementation from the definition of a service.
Understanding Endpoints
Services expose one or more endpoints where messages can be sent. Each endpoint consists of an address, a binding, and a contract. The address specifies where to send messages. The binding describes how to send messages. And the contract describes what the messages contain. Clients need to know this information before they can access a service. The below picture demonstrates how the components of end point play a key role in communication between a client and a service.
Services can package up endpoint descriptions to share with clients, typically by using Web Services Description Language (WSDL). Then clients can use the provided service description to generate code within their environment capable of sending and receiving the proper messages .
One of the key components of an end point is bindings, which will be the topic of focus in the next section.
Understanding Bindings
The bindings of a WCF service define how an endpoint will communicate with an external client. A binding has several characteristics, including the following:
- Transport protocols - Some of the choices include HTTP, Named Pipes, TCP, and MSMQ.
- Encoding - Three types of encoding are available-Text, Binary, or Message Transmission Optimization Mechanism (MTOM). MTOM is an interoperable message format that allows the effective transmission of attachments or large messages (greater than 64K).
- Security - Includes wire security (SSL) or schema-defined security (WS-Security).
Bindings can also determine if you are using sessions or a transacted communications channel. You have the choice of creating custom channels or using prebuilt bindings. WCF comes shipped with nine built-in bindings. The following table lists the WCF build-in bindings and their associated features.
Binding | Description |
---|---|
BasicHttpBinding | Basic Web service communication. No security by default |
WSHttpBinding | Web services with WS-* support. Supports transactions |
WSDualHttpBinding | Web services with duplex contract and transaction support |
WSFederationHttpBinding | Web services with federated security. Supports transactions |
MsmqIntegrationBinding | Communication directly with MSMQ applications. Supports transactions |
NetMsmqBinding | Communication between WCF applications by using queuing. Supports transactions |
NetNamedPipeBinding | Communication between WCF applications on same computer. Supports duplex contracts and transactions |
NetPeerTcpBinding | Communication between computers across peer-to-peer services. Supports duplex contracts |
NetTcpBinding | Communication between WCF applications across computers. Supports duplex contracts and transactions |
You can choose the right binding to use by mapping the features they support to your requirements.
Hosting WCF Services
As for where to put your code and what it compiles to, you have some choices. You can host your service in Internet Information Services (IIS), or you can write a small amount of extra code to host a service yourself. You can self-host a service from just about any environment that supports managed code, including a WinForms application, console application, library assembly (DLL), or Windows Service controlled through SCM (Service Control Manager). The following lists show the common hosting mechanisms for WCF services.
IIS (Internet Information Services) - IIS provides a number of advantages if the service uses HTTP as its transport. The nice thing about using IIS is that you don't have to write any hosting code as part of the application since IIS automatically activates service code as required. Services also benefit from IIS features such as process lifetime management and automatic restart after configuration changes. To run services using IIS, you create the service code along with its configuration file and simply save them in an IIS virtual directory.
WAS (Windows Activation Service) - (WAS) is the new process activation mechanism that ships with IIS 7.0. WAS builds on the existing IIS 6.0 process and hosting models, but is no longer dependent on HTTP. In addition to HTTP based communication, WCF can also use WAS to provide message-based activation over other protocols, such as TCP and named pipes. This helps WCF applications to take advantage of WAS features, such as process recycling, rapid fail protection, and the common configuration system, which were previously available only to HTTP-based applications.
Self-hosting - WCF services can be hosted inside any managed application, such as console applications and Windows Forms or Windows Presentation Foundation (WPF) graphical applications. To accomplish this, you need to create a class that implements a WCF service contract interface, and specify binding information in the application configuration file. The application code can then use an instance of System.ServiceModel.ServiceHost to make the service available at a particular location. To start the service, you call the ServiceHost.Open() method.
- Managed Windows Service - A WCF service can be registered as a Windows Service, so that it is under control of the Service Control Manager (SCM). This is suitable for long-running WCF services that are hosted outside of IIS in a secure environment and are not message-activated. By hosting a WCF service with Windows Services, you take advantage of Windows service features such as automatic start at start time and control by the SCM. To host a WCF service in this way, the application must be written as a Managed Windows Service by inheriting from System.ServiceProcess.ServiceBase. It must also implement a WCF service contract interface and then create and open a ServiceHost to manage the WCF service.