Chapter 4: WCF 101

Overview

The Microsoft Windows Communication Framework (WCF) is a complex framework, and its complexity stems from the fact that WCF is, on an abstract level, a messaging framework that must remain relevant and useful against the backdrop of industry standards that are constantly evolving. During the WCF design phase, SOAP and WS-* were viewed as the dominant messaging structures and protocols of the future. It is doubtful that any of the architects responsible for the complexion of WCF knew that JavaScript Object Notation (JSON) would ascend to become as relevant as it is today. They did however, understand that WCF must easily embrace and adapt to message structures and transports that sprout seemingly overnight. As a result, Microsoft designed WCF to be highly extensible and adaptable to meet the messaging requirements of today as well as those unforeseen in the future. The result of these efforts is a complex platform that is easy to use but, from a holistic perspective, somewhat difficult to understand.

As anyone who has tried to build a broad framework can attest, designing, building, testing, and maintaining it is a daunting task. Having designed, consulted on, and built several frameworks, I understand how difficult this can be. When designing a framework, the adage attributed to Alan Kay “Simple stuff should be simple, complex stuff should be possible” must be a primary design rule. When I look at WCF as it stands today, I think Microsoft successfully implemented this adage, and even took it further by making a lot of complex “stuff” simple. This is not to say that I think WCF is perfect or contains no errors, but rather that the product as a whole is well thought out and well designed.

One of the core requirements of WCF is exposing an object model to the developer that is consistent across all transports and protocols. As a concrete example, the architects on the WCF team wanted the code required to send a message over the TCP/IP transport to look very similar to the code required to send a message over the MSMQ transport. This sort of feature has several benefits. First, it means that the platform does not force developers to learn the eccentricities of the wide array of transport and protocol object models. In effect, developers who understand the WCF object and execution model are able to build support for different transports and protocols into their applications. Second, it means that as the WCF infrastructure matures to include new transports, protocols, and functionality, developers don’t necessarily have to learn new ways to incorporate the new features into their applications. Instead, they can rely on the paradigms already implemented in the framework.

As a result of these types of requirements, the WCF architecture is composed of many interwoven layers. Over time, I have found that gaining a full understanding of any particular layer in the WCF infrastructure requires first understanding a little bit about every layer in the WCF infrastructure. The purpose of this chapter is to introduce the major layers in WCF applications and to provide context for the rest of this book, where we will more fully explore many of these layers.