Understanding the WCF Motivations

Understanding the WCF Motivations
As with any new technology, having a good understanding of WCF begins with having an
appreciation for its underlying motivations. After all, .NET currently has several effective tech-
nologies that enable you to build distributed applications: .NET Remoting, MSMQ, Enterprise
Services, and, of course, Web Services. What is the point of having yet another distributed
technology? In this section, we tackle this all-important question.
Problem: Distributed Technology Soup
In the previous paragraph, we mentioned the many distributed technologies that are already
available to .NET developers. To save syllables and trees, we’ll collectively refer to these four
technologies—.NET Remoting, MSMQ, Enterprise Services, and Web Services—as the “Big
Four.”
1
Although it’s usually nice to have many options, in this case, the number of options
combined with large amounts of overlapping functionality make it extremely difficult to
choose the right technology for the job. Of course, each of the Big Four exhibits distinct advan-
tages and disadvantages relative to the others. But deciding the right technology based on
them may require application and infrastructure knowledge that you may not yet have. For
example, you may choose Web Services to leverage its loose coupling advantage, only to find
out much later that the actual application load requires the performance advantage of Enter-
prise Services. Given that the programming models for each of the Big Four differ greatly,
switching to another technology midstream in the development cycle proves difficult and
costly.
To better understand the nature of the problem, take a look at Table 9-1. This table details
each technology’s characteristics, advantages, and disadvantages. Looking at this, it’s no won-
der that news groups and forums are flush with which, when, where, and why questions
regarding the Big Four.
WCF’s Solution to Distributed Technology Soup
WCF solves the distributed technology soup problem by incorporating the best of each Big
Four technology into one programming model. For developers, this eases the burden of hav-
ing to remember four extremely different models. It also simplifies the task of switching
midstream to another distributed technique.
In terms of a programming model, WCF actually supports three levels of “programming”:
API, declarative attributes, and configuration. The extensive WCF API exposes all of its func-
tionality including low-level plumbing and extensibility points. Although the API is powerful,

WCF also defines many attributes that are much simpler to use and that support most scenar-
ios. Finally, WCF’s configuration support enables you modify many settings without even
touching your source code.
Beyond providing a simple programming mode, WCF’s attribute-based approach also
enables you to expose a component on the wire without deriving from a special base class. In
contrast, .NET Remoting and Enterprise Services require that you derive your remote object
from MarshalByRefObjectand ServicedComponent, respectively. Because .NET allows only one
base class, this makes it difficult to incorporate your own custom base class.