Understanding the Data Transfer Architecture

At the heart of the message capabilities of WCF is the Message class. The WCF architecture and runtime are essentially two pillars—the channel stack and the service framework—and the Message class is the bridge between the two. The first pillar (the channel stack) on the "send side" converts a Message instance with some specified action to the act of either sending or receiving data. On the other hand, with the channel stack operating on the receiving side, it is responsible for the reverse—converting an action into some specific message.

Although there is no restriction on using the Message class and channel stack directly, it is not usually recommended because it is fairly expensive (time-wise) and complex. Also, there are runtime issues such as lack of metadata support, lack of strongly typed proxies, and so on. To overcome these restrictions, WCF has the second pillar—the framework that provides a relatively easy programming model for working with Message objects. This framework maps .NET types and services via service contracts and sends messages to operations that are .NET methods that are marked with the [OperationContract] attribute. The framework converts the incoming Message instances into the parameters on the server side. On the client side, it does the reverse and converts the return types to the outgoing Message instance.

Although the Message class is the most fundamental concept of WCF, it is usually not interacted with directly. You should use one of the other WCF service model constructs (such as data contracts, discussed later in the "Introducing Data Contracts" section), message contracts, and operation contracts (both introduced in Chapter 3) to describe the incoming and outgoing messages. You should use Message only when working with some advanced scenarios. We'll discuss all the aforementioned Message classes and WCF constructs a little later in this chapter in the "Introducing Message Contracts" section.

Regardless of which construct you use whenever the message contents are described using message contracts or parameters, the message contents need to be serialized to convert these between the .NET type to the relevant SOAP or binary representation. Before you examine each of the options available in WCF, you need to understand the serialization options available and the advantages and challenges of each of them.