In Chapters 5 through 7, we’ve looked at the Message type and how Microsoft Windows Communication Foundation (WCF) sends and receives Message objects. In Chapter 8, “Bindings,” you saw how a binding, a channel manager, and a channel stack work together to send and receive messages (Message objects). Channel managers, channels, and to some extent the Message type and bindings are part of the channel layer. By using the channel layer exclusively, it is possible to create a fully functional messaging application, but doing so is tedious, error prone, and time consuming. WCF makes developers’ lives easier via the ServiceModel layer. The ServiceModel layer manages the creation and lifetime of channel layer objects. Its tasks also include pumping Message objects into and out of the channel layer, serializing and deserializing Message contents into meaningful objects, dispatching those objects to objects that contain business logic, and managing the lifetime of the objects that contain business logic. (See Chapter 4, “WCF 101,” for more information about the boundary between the channel layer and the ServiceModel layer.) Chapter 9, “Contracts,” addresses a few of these tasks by describing the roles that contracts play in abstracting the structure of the messaging application and the messages that the application interacts with. In essence, contracts serve as a blueprint to the ServiceModel layer during the creation of the messaging application.
This chapter discusses the parts of the ServiceModel layer responsible for the lifetime of channel layer constructs, how Message objects and parts of Message objects are dispatched to objects containing business logic, and the management of the lifetime of the objects that contain business logic. There is no single ServiceModel type responsible for these tasks; instead, the WCF type system broadly categorizes these ServiceModel types on the sender and the receiver. On the sender, this category of types is known as the client, but it is also known as the proxy. Pre-beta versions and several beta versions of WCF used proxy, and the name was changed in later versions to client. Even though I am not a fan of this naming convention because of its close association with client/server architectures, I will refer to this category of types on the sender as the client. On the receiver, this category of types is known as the dispatcher. Like other parts of the WCF infrastructure, there is a symmetry between the ServiceModel infrastructures on the sender and the receiver, so the client and the dispatcher have much in common. It is not a perfect symmetry, however, because the tasks of the client and the dispatcher are so different.
The client and the dispatcher have numerous extensibility points that allow for a seemingly countless number of different run-time characteristics. Many of these extensibility points are called behaviors. WCF provides an abundance of behaviors, and developers can quickly choose from these behaviors cafeteria-style. With an appropriately fatalistic view of functionality, WCF also allows developers to create custom behaviors and insert them into the client or dispatcher at run time.
Much has been written elsewhere about the default and custom WCF behaviors (check the Windows SDK code samples). In this chapter, we’ll focus on how the client and the dispatcher manage the lifetime of the channel layer, how messages and message contents are routed, and how user code is invoked. For completeness, I will also discuss behavior anatomy, but that is not the primary focus of this chapter. In my experience, once you understand the major parts of the client and the dispatcher, understanding behaviors is a relatively simple affair. On the other hand, trying to understand behaviors before understanding the client and the dispatcher is often a confusing and frustrating task. Thus, this chapter begins with a description of the roles the client and the dispatcher play in the lifetime of a messaging application and then moves into the anatomy of the dispatcher, the ServiceHost type, and the client.