WCF Gross Anatomy from the Inside

When examining the outside of a WCF application (the address, binding, and contract), it is natural to wonder how WCF uses addresses, bindings, and contracts to send or receive messages. From the code we have seen so far, there has been little code directly related to sending and receiving messages. In fact, an address, a binding, and a contract do little on their own. When we take a closer look at a WCF application, we see another infrastructure that uses addresses, bindings, and contracts to send and receive messages. In large measure, the rest of this book is dedicated to explaining this infrastructure, so I will introduce only the major parts of the infrastructure in this chapter.

When we look through the world of addresses, bindings, and contracts, we see an infrastructure that is split into two major architectural layers. The names of these layers are the ServiceModel layer and the Channel layer. The ServiceModel layer is the bridge between user code and the Channel layer. In other words, it is part of the normal API. The Channel layer, on the other hand, does the real work of messaging. The Channel layer is the layer that understands the details of a particular transport and WS-* message choreographies. WCF ships with rich Channel layer functionality. In general, the Channel layer is the domain of infrastructure developers, so it is entirely possible to write a fully functional WCF application without ever writing code that belongs to the Channel layer.

Note 

Although the division might be a bit simplistic, I am splitting developers into two categories: application developers and infrastructure developers. Application developers write applications, while infrastructure developers write code that will be reused by application developers. An application developer might write a purchase order processing application, while an infrastructure developer may write a reusable component that is consumed by the purchase order processing system. In WCF, the application developer writes a messaging application, but an infrastructure developer writes a custom channel.

Figure 4-2 illustrates how the ServiceModel layer and the Channel layer fit together.

Figure 4-2: The ServiceModel layer and the Channel layer

Notice that the ServiceModel layer is called the Proxy (also called the Client) on the sender and the Dispatcher on the receiver. The Proxy and the Dispatcher have different roles, even though they are part of the same architectural layer. The Proxy is responsible for, among other things, creating messages to send to the Channel layer. The Dispatcher, on the other hand, is responsible for deserializing received messages, instantiating an object, and dispatching the deserialized message contents to that object. Both the Proxy and the Dispatcher serve more functions than these, and we will describe their roles more in Chapter 10.

The ServiceModel layer and the Channel layer are distinct from the simple world of the address, the binding, and the contract. In effect, the address, the binding, and the contract that are a part of the application developer API influence the creation of these two layers. When first approaching the WCF layers, it is often helpful to see which layers the address, binding, and contract influence. On the receiver, the address tells the Channel layer where to listen for incoming addresses. On the sender, the address tells the Channel layer where to connect to the receiving application. Bindings, on the other hand, are collections of factory objects that create the Channel layer. Contracts are used for message serialization and deserialization, and they are also used to determine the MEP of the receiving application. In general, the contract is a ServiceModel construct. Behaviors, on the other hand, can influence both the ServiceModel layer and the Channel layer. Figure 4-3 illustrates.

Figure 4-3: How the ABCs of WCF influence the ServiceModel layer and the Channel layer