The WCF address is a specific location for a service. It specifies the path where a particular message will be sent. All WCF services are deployed at a specific address, and they listen at that address for incoming requests.

A WCF address is normally specified as a URL, with its first part specifying the transport mechanism and the next part specifying the unique location of the service. For example, http://www.myweb.com/myWCFServices/SampleService.svc is an address for a WCF service. This WCF service uses HTTP as its transport protocol, and it is located on the server, www.myweb.com, with a unique service path of myWCFServices/SampleService.svc.

Bindings are used to specify the transport, encoding, and protocol details required for clients and services to communicate with each other. Bindings are what WCF uses to generate the underlying representation of the endpoint (an endpoint is a place where clients can communicate with a WCF service; more details will follow). So, most of the details of the binding must be agreed upon by the parties that are communicating. The easiest way to achieve this for clients of a service is to use the same binding that the service uses.

A binding is made up of a collection of binding elements. Each element describes some aspect of how the service communicates with clients. A binding must include at least one transport binding element, at least one message-encoding binding element (which is provided by the transport binding element by default), and any number of other protocol binding elements. The process that builds a runtime out of this description allows each binding element to contribute code to that runtime.

WCF provides bindings that contain common selections of binding elements. These can either be used with their default settings, or the default values can be modified according to user requirements. These system-provided bindings have properties that allow direct control over the binding elements and their settings.

The following are some examples of system-provided bindings: BasicHttpBinding, WSHttpBinding, and NetTcpBinding. Each one of these built-in bindings has the predefined elements required for a common task and is ready to be used in your project. For instance, BasicHttpBinding uses HTTP as the transport to send SOAP 1.1 messages, and it has attributes and elements such as receiveTimeout, sendTimeout, maxMessageSize, and maxBufferSize. You can use the default settings of attributes and elements of BasicHttpBinding, or overwrite them as needed. We will explore all of the three bindings in this book.

A WCF contract is a set of specifications that defines the interfaces of a WCF service. A WCF service communicates with other applications according to its contracts. There are several types of WCF contract, such as service contract, operation contract, data contract, message contract, and fault contract. We define service contract and operation contract in the following sections of this chapter, and define more contracts throughout this book.

Messages are sent between endpoints. Endpoints are places where messages are sent or received (or both), and they define all the information required for the message exchange. A service exposes one or more application endpoints (as well as zero or more infrastructure endpoints). A service can expose this information in the form of metadata that clients process to generate the appropriate WCF clients and communication stacks. When needed, the client generates an endpoint that is compatible with one of the service's endpoints.

A WCF service endpoint has an address, a binding, and a service contract (sometimes referred to as WCF ABCs).

A WCF behavior is a type or setting to extend the functionality of a WCF component. There are many types of behaviors in WCF, such as service behavior, binding behavior, contract behavior, security behavior, and channel behavior. For example, a new service behavior can be defined to specify the transaction timeout of the service, the maximum concurrent instances of the service, and whether the service publishes metadata. Behaviors are configured in the WCF service configuration file. We will configure several specific behaviors in the chapters that follow. We will learn how to extend a WCF service with behaviors in Chapter 13, Extending WCF Services.

The WCF service is a component that can be called by other applications. It must be hosted in an environment in order to be discovered and used by others. The WCF host is an application that controls the lifetime of the service. With .NET 3.0 and higher, there are several ways to host the service. We will explore various WCF hosting options in Chapter 2, Hosting the HelloWorld WCF Service.

As we have seen in previous sections, a WCF service has to be hosted in an application on the server side. On the client side, the client applications have to specify the bindings to connect to the WCF services. The binding elements are interfaces, and they have to be implemented in concrete classes. The concrete implementation of a binding element is called a channel. A binding element represents a configuration and a channel is the implementation associated with that configuration. Therefore, there is a channel associated with each binding element. Channels stack on top of one another to create the concrete implementation of the binding—the channel stack.

The WCF channel stack is a layered communication stack with one or more channels that process messages. At the bottom of the stack is a transport channel that is responsible for adapting the channel stack to the underlying transport (for example TCP, HTTP, SMTP, and other types of transport). Other channels provide a low-level programming model to send and receive messages.

The metadata of a service describes the characteristics of the service that an external entity needs to understand in order to communicate with the service. Metadata can be consumed by the ServiceModel metadata utility tool (SvcUtil.exe) to generate a WCF client proxy and the accompanying configuration that a client application can use to interact with the service.

The metadata exposed by the service includes the XML schema documents that define the data contract of the service and WSDL documents that describe the methods of the service.

Though WCF services always have metadata, it is possible to hide the metadata from outsiders. If you do so, you have to pass the metadata to the client side by other means. This practice is not common but it gives your services an extra layer of security. When enabled through the configuration settings from metadata behavior, metadata for the service can be retrieved by inspecting the service and its endpoints. The following configuration setting in a WCF service configuration file will enable metadata publishing for the HTTP transport protocol:

<serviceMetadata httpGetEnabled="true" />

WCF was first introduced in Microsoft's .NET Common Language Runtime (CLR) Version 2.0. The corresponding framework at that time was .NET 3.0. To develop and run WCF services, Microsoft .NET Framework 3.0 or above is required.

Visual Studio is Microsoft's IDE to develop WCF service applications. Visual Studio 2008 and above support WCF service application development.

The following table shows all of the different versions of the .NET runtimes, .NET frameworks, and Visual Studio versions, along with their relationships: