Introducing Windows Communication Foundation (WCF)

Microsoft and others saw the universal requirement of connectedness and the universal concept of service orientation in the 1990s. At the time, there were no widely accepted messaging standards, and as a result, there was no platform, application programming interface (API), or runtime that allowed developers to easily write service-oriented applications. Technically, it was possible to author service-oriented applications, but the capability of the developer tools and application runtimes made that a daunting undertaking. Luckily, Microsoft and others began defining an infrastructure that would ultimately result in a universal message structure. The end result of these efforts is the WS-* family of specifications. In parallel with these efforts, Microsoft also planned a technology roadmap that would ultimately give developers the tools and the runtime they needed to build and deploy service-oriented applications that leveraged WS-* specifications. The waypoints on this roadmap include the Microsoft .NET Framework, ASP.NET Web Services (ASMX), Web Services Enhancements (WSE), Windows Vista, and of course, WCF.

Not Just Another API

Over time, the developer community has seen many new APIs, each promising all sorts of new and wonderful functionality. Often, these new APIs were wrappers around other functionality. As a result, you might instinctively treat WCF as just another API. Resist this temptation. Jackie Gleason says it best in Smokey and the Bandit (one of my all-time favorite movies): “Boy, … don’t do it… You can think about it, but don’t do it.” WCF is not just a wrapper around existing functionality or just another whiz-bang API. WCF is the evidence that a tectonic shift has occurred in distributed software development. Microsoft made huge investments in this technology because it enables true service-oriented application development and, as a result, provides greater reach for applications built on the Microsoft platform. IBM, BEA, SAP, and others have made similar moves, each fueled by the drive to connect applications residing on different platforms.

WCF from 10,000 Feet

WCF is a set of types built on the Microsoft .NET Framework, and ultimately on the Microsoft Windows operating system, that act as a bridge between the service-oriented world and the object-oriented world. In general, working with objects is more productive and less error prone than working directly in the service-oriented world, even when those objects might ultimately send, receive, and process service-oriented messages. WCF gives us the ability to work in either world, but it is geared toward allowing us to program in the object-oriented world with which many developers are familiar.

Beneath It All: Windows

Distributed applications need to communicate most commonly across process boundaries. Distributed applications also need to be hosted, and as a result, they depend on services like Windows Activation Services (WAS), Internet Information Services (IIS), and Microsoft Windows NT services. Operating systems like Windows XP with Service Pack 2, Windows Server 2003, and of course Windows Vista are part of the roadmap that enables connected applications. These operating systems have built-in support for services, and as such, they are an important part of distributed computing.

At the lowest level, WCF applications send and receive messages through the operating system I/O mechanisms (sockets, named pipes, and so on). WCF developers, however, are shielded from many of the gory details by common layers of abstraction.

Helpful Products: The Windows Server System

Microsoft has many products that automate and simplify the tasks associated with distributed computing:

• BizTalk Server

• Commerce Server

• Application Center

• Internet Security and Acceleration Server

• SQL Server

• Exchange Server

• Host Integration Server

Over time, I expect that these products will communicate, in some form or fashion, via WCF.

In the future, expect to see support that allows WCF applications to interact directly with some of these servers. For example, there will be support for leveraging the Transaction Broker in SQL Server 2005 directly from WCF applications.

The Development Platform: The Microsoft .NET Framework

Since 2002, the Microsoft .NET Framework has been the platform of choice for Windows development. It is built on four pillars: automatic memory management, JIT compilation, metadata, and code access security. These pillars support a platform that enables rapid component development, a type-safe execution environment, language choices, simplified deployment scenarios, and component security. (I could go on.) WCF is built entirely on the .NET Framework and was written entirely in C#.

The .NET Framework abstracts operating system I/O mechanisms through types like System.Net.Sockets.Socket and System.Messaging.MessageQueue (to name a few). These types are used by the WCF infrastructure to send and receive messages. As you will see later in this book, it is also possible to interact with these types directly through WCF extensibility points.

The Distributed Platform: WCF

WCF is Microsoft’s API for creating independently versionable, secure, reliable, and transacted service-oriented applications. It fully embraces the concepts of service orientation, and it can create messages that comply with many WS-* specifications, but it can also be used in the Representational State Transfer (REST) architecture and other distributed architectures that use Plain Old XML (POX) messages. In essence, WCF is the developer’s bridge to the service-oriented world. Before WCF, it was possible to write service-oriented applications by using technologies like WSE and ASMX, but WCF provides more security, reliability, flexibility, and performance options than any previous service-oriented technology from Microsoft. In other words, WCF answers the universal requirement of connectedness, and as such, the moon is blue.

Putting It All Together

Figure 1-3 illustrates how Windows, the .NET Framework, WCF, and WCF applications fit together conceptually.

Figure 1-3: WCF in context

Conceptually and logically, WCF is a set of assemblies that allow developers to quickly write service-oriented applications. Applications that use WCF can communicate using message schemas and choreographies defined in the WS-* specifications, with REST architectures, or POX messages. WCF shields developers from many of the nuances of both the raw communication stacks and the WS-* specifications. Physically, WCF is a set of assemblies that expose a set of types. These WCF types comprise a developer-facing API and an inward-facing set of types. As you might imagine, the developer-facing API is intended to be used in applications written by non-WCF team members, and the internal-facing types interact with the .NET Framework and ultimately the operating system for the purpose of sending, receiving, or otherwise processing messages. WCF was built with its own extensible architecture, so developers can change the out-of-the-box WCF functionality to fit the requirements of a specific application.

WCF Features

Designing, building, maintaining, and versioning distributed applications is a complex undertaking. Factor in the typical requirements of security, reliability, transactional support, and scalability, and the task becomes even more complex. As a result of the complex problems WCF is designed to solve, WCF is a fairly complex technology. In an attempt to provide a clear view of WCF’s features, I have split the major functionality into 10 categories: independent versioning, asynchronous forward-only messaging, platform consolidation, security, reliability, transactional support, interoperability, performance, extensibility, and configurability.

Independent Versioning

Versioning of applications has always been a difficult problem. As I mentioned earlier, component-oriented designs simply didn’t address this problem well in distributed systems. Any technology that hopes to gain acceptance in the distributed applications space must allow independent versioning of the different parts of the distributed application. Adherence to the WS-* specifications, and the focus that WS-* puts on messages, allow WCF services to develop at a different rate from that of service consumers. While this feature is not so much a part of WCF as it is part of the underlying principles that are used to create the WCF applications, I see this as one of the most important byproducts of using WCF.

Asynchronous One-Way Messaging

Many of our applications are written using request-reply calls to functions. Typically, we call a function, wait for it to return, and act based on the return value. This paradigm is reinforced every time we use the Internet. Every time we make a request for a Web page, we have to wait for a reply from that Web page. As a result of our conditioning, the request-reply model is the default way most of us write distributed applications. Even though it might seem uncomfortable at first, asynchronous forward-only messaging is far more efficient for the I/O bound tasks required of a distributed application. WCF is built from the ground up to support asynchronous forward-only messaging. I see this feature as another major benefit to using WCF. Asynchronous forward-only messaging allows for the efficient use of available processing power and facilitates more advanced functionality, reliability, and responsiveness in our applications.

Platform Consolidation

Microsoft has shipped many distributed technologies over the years; some have been part of the roadmap that eventually leads to WCF, and many others are holdovers from previous initiatives. For example, before the WCF release, Microsoft supported five major technology stacks for distributed computing: RPC, WSE, ASMX, Remoting, COM+, and MSMQ. In the past, the best technology choice for a distributed application depended on the requirements for that application. For example, if all nodes in a distributed application were .NET Framework applications, one might choose to use .NET Remoting since it is an efficient means of communication between .NET Framework applications. If, however, an application required guaranteed message delivery and durability, MSMQ was the best choice. Both of these technologies have very different APIs, programming paradigms, operational demands, and configuration requirements. As a result, application code has been tightly bound to the technology, and the technology has been tightly bound to a particular set of functionality. A few technologies allowed us to combine features. The prototypical example is the transactional and queued capability of COM+. As long as requirements don’t change or combine in a way that won’t work for the technology, this model is workable.

What if your application requires efficient communication with other .NET Framework applications and non–.NET Framework applications and support for transactional processing? Before WCF, there were no good options. Essentially, this combination of requirements forced developers to either ignore one of the requirements or write their own distributed technology. In contrast with the old technologies, WCF combines features from different technologies and unifies them under one programming model, as shown in Table 1-1.

Table 1-1: WCF Feature Comparison
Open table as spreadsheet

Feature	WSE	ASMX	Remoting	COM+	MSMQ	WCF
WS-* support	X			X		X
Basic Web service interoperability		X		X		X
.NET -to-.NET communication			X			X
Distributed transactions				X	X	X
Queued messaging					X	X

In fairness, WCF does not provide us with unlimited combinations of features, but it does provide many more feature combinations than we had before.

Security

No one sets out to build an application full of security holes. Quite the contrary, we typically go to great lengths to ensure that our applications are secure. If we don’t do this, we certainly should. In the past, it has been up to us, the developer, the architect, or the tester, to know how to configure our application in such a way that it is secure. When we see the myriad of available technologies that provide security in our applications, it is often difficult to know which technology or combination of technologies is right for securing our application.

Out of the box, WCF supports many different security models, and makes it easy to implement widely accepted security measures. Since WCF has an extensible architecture, it is also relatively easy to extend WCF security to meet the needs of a particular application. The default security options range from the traditional transport-centric security to the more modern, message-based security, as dictated in WS-Security and related specifications. It’s also very important to note that WCF is secure by default in many scenarios.

Reliability

Distributed applications often require reliable messaging. In distributed computing, reliable messaging is often described in terms of assurances. An assurance is like a guarantee. There are four assurances that apply to distributed computing scenarios:

• At Most Once   A message is guaranteed to arrive at the destination no more than one time. If a message arrives at a destination more than once, it is ignored or considered an error.

• At Least Once   A message is guaranteed to arrive at the destination at least one time. If a message does not arrive at a destination at least once, it is considered an error.

• Exactly Once   The combination of At Most Once and At Least Once, this is a guarantee that a message will arrive at a location one time.

• In Order   One logical set of information can be physically distributed in many messages. As these messages are sent, they are sent in a particular order. The In Order assurance guarantees that the messages will be processed in the same order they were sent.

Experience has taught us that networks and applications that generate network traffic are unreliable. In general, if an application sends two messages through the network to another application, assurances that the messages arrived at their destination have traditionally come from the transport. It is certainly possible that one or both of the messages were lost in transmission. It is also possible that the arrival order of the messages is different from the sending order, and even that messages arrive more times than they were sent. Many factors contribute to this unreliability, including excessive network traffic, network connectivity loss, application bugs, and environmental changes.

An unreliable network is annoying when you’re trying to check e-mail or surf the Web, but it is particularly troublesome when factored into distributed computing scenarios. For example, if an order processing application loses messages during transmission between processing nodes, the problem can materialize as missed ship dates and angry customers. If, however, an application can learn when a failure has occurred, the application can take some remedial action.

In the past, an application’s reliability requirements dictated the technology used in the application. For example, MSMQ provides, among other things, reliable delivery. If an application required reliable message delivery, MSMQ was the logical technology choice. Implementing MSMQ, while fairly straightforward, required MSMQ-specific knowledge and MSMQ-specific code. Writing this code and setting up the correct environments required MSMQ-specific knowledge that was unique and nontransferable to other technologies. In essence, the decision to send a message reliably from one application to another application has had, in the past, a dramatic impact on the code in the applications and the knowledge required to write it.

WCF contains mechanisms that provide At Most Once, At Least Once, Exactly Once, and In Order delivery assurances. WCF can provide these assurances with little or no modification to the application. Even better, the delivery assurance mechanisms are decoupled from the transport, thereby opening the door for delivery assurances even when messages are sent over traditionally unreliable transports.

Note 

Do not confuse reliable messaging with durable messaging. At a high level, durable messages persist in a nonvolatile store as they are being processed. If the application exits unexpectedly and volatile memory is cleared, the messages are still available in the persistent store.

Transactional Support

In the connected world, the work performed upon receipt of a message involves subsequent message sends to other applications. Sometimes this work needs to be performed in the scope of a transaction. Simply stated, a transaction is a way to ensure that all or none of the work is done. WCF allows transactional scopes to flow across multiple applications.

Interoperability

WCF is designed from the ground up to interoperate with other systems. This includes applications that run on different operating systems and platforms. It is WCF’s inherent ability to focus on the message that makes this capability possible. Out of the box, applications built on WCF can communicate with other applications that understand WS-*, Basic Profile (BP), and XML messages over TCP, HTTP, Named Pipes, and MSMQ. Developers are free to write components that extend the default WCF capabilities, and this includes writing custom extensions that allow WCF to communicate with applications that require proprietary binary message encodings (like legacy mainframe applications).

Traditionally, the requirements to interoperate with another platform (like Java) have dictated much of our application design. In the past, if we wanted to communicate with another platform, we would either use ASMX or write our own interoperability layer. WCF is much different. From an interoperability perspective, WCF is a single technology that has interoperability features previously spread across several different technologies. WCF achieves the promise of true interoperability by embracing WS-* and also by supporting REST architectures and POX messaging styles.

Performance

Distributed technologies usually have a fixed performance cost; this cost is usually balanced with the features that technology provides. For example, .NET Remoting is a relatively efficient way for two .NET Framework applications to communicate, but it cannot easily interoperate with non–.NET Framework applications. ASMX, on the other hand, is not as highly performing as Remoting, but it can interoperate with non–.NET Framework applications. MSMQ is not highly performing from an end-to-end perspective, but the very nature of queuing helps the efficiency of the sending application. To put it another way, the total time required to generate, send, deliver, and receive an MSMQ message is not trivial, but the durability and reliability of MSMQ gives the sending application the assurance that it can generate and send the message and not wait for delivery or receipt of the message. The net effect in the sending application is an overall increase in throughput. The downside to this technology is that it does not, by default, interoperate with other queuing systems. (There is, however, a bridge between MSMQ and IBM’s MQSeries.) When viewed as a whole, the distributed technology used by a distributed application has traditionally impacted the performance of that application.

In contrast, WCF applications can provide different levels of interoperability and performance. For example, WCF applications can be more efficient when communicating with other WCF applications than they are when communicating with a Java-based Web service.

Extensibility

The common language runtime (CLR) contains magic. For example, the JIT compiler, the verification subsystem, and the garbage collector are nearly impossible to replicate. Microsoft has published partial information about how these subsystems work, but these subsystems cannot be replaced by third parties. For example, all .NET Framework applications are subject to the garbage collector. We can and should be intelligent about how we write our code to take advantage of the features of the garbage collector. However, no one outside Microsoft can write a .NET Framework application that uses the CLR, with his or her version of the garbage collector instead of the CLR’s garbage collector.

In contrast, WCF contains no magic. Don’t let this detract from your impression of the power of the platform. Quite to the contrary, WCF is extremely powerful, due in large measure to its extensible design. WCF is designed to work with custom transports, channels, bindings, encodings, and architectural paradigms. Chapter 4, “WCF 101,” describes many of these WCF extensibility points.

Configurability

One of the touted WCF features is its rich configuration support through XML configuration files. Using this feature, it is possible to configure transports, addresses, behaviors, and bind-ings in an XML file. When making these configuration changes, it is possible to radically alter the behavior of a WCF application without modifying any source code and without having to recompile the application. This is attractive from an administrative perspective, because it allows nondevelopers to move, maintain, and alter the behavior of the application without the involvement of the development team. I see this as a blessing and a curse. When used wisely, this feature can greatly reduce the pressure and workload on development teams. When abused, it will create unpredictable results.