As systems become more and more service-oriented, the importance of the connections between services and consumers...
of those services rises. Addressing that need, Windows Communication Foundation (WCF) is the generalized programming framework for communications for Windows-based applications. Released in November 2006 as part of the Microsoft .NET Framework 3.0, WCF can be used within client or server applications built on Windows, to enable them to connect to just about anything else.
Some background on WCF
The .NET Framework was initially introduced in 2002. It provides a common programming framework, a common runtime and a common base class library for developers working on Windows-based systems, regardless of the types of applications they were writing. The initial release of .NET included several different programming models for interapplication communications. For basic interprocess communications between .NET applications with a highly efficient binary transport, developers would use the .NET Remoting programming interfaces. For queued communications, .NET 1.0 applications would use the System.Messaging classes, which enabled Put/Get access to the Microsoft Message Queuing component of Windows. For transactional communications, .NET applications would use the Enterprise Services programming model, which was predicated on a COM-based communications implementation (COM+ Services and DCOM Communications). And finally for SOAP-based interapplication communication, .NET 1.0 applications could use the ASP.NET Web Services classes.
Developers of distributed systems told us they wanted fewer programming interfaces for communications, while keeping all of the communications capabilities in the platform. They asked for a single generalized communications stack.
The Windows Communication Foundation, originally code-named "Indigo," was conceived as an answer to that developer need. It is a unifying programming model for communications, providing all the capabilities of the disparate existing communications models in one common model. WCF originally shipped as part of the .NET Framework 3.0, in December 2006. The .NET 3.0 runtime, required for applications built on .NET, is included in Windows Vista and is a free download for other Windows-based platforms. The .NET 3.0 SDK, used by developers who build .NET applications, is a free download for Windows Vista, Windows Server or Windows XP. Of course, many developers use higher-level graphical tools for building applications; the Visual Studio family from Microsoft fits that bill. If you are a developer building a distributed application for Windows, whether you use the free .NET SDK or a commercial developer tool such as Visual Studio, WCF is the programming interface you should use to create the communications layer of your application components.
Key capabilities of WCF
WCF provides developers of service-based applications with WS-* compliance and interoperability, extensibility to add new capabilities, and flexibility to connect to just about anything.
Developers familiar with ASP.NET Web services, or with popular WS libraries in Java, will find WCF to be familiar. For the service interface, and for the messages or data exchanged over that interface, contracts are a key metaphor in WCF. The metadata for these contracts can either be defined in Web Services Description Language (WSDL) or by using code attributes in Visual Basic, C# and other .NET languages, a programming experience that is familiar to business application developers.
For Web services developers, WCF provides a great deal of flexibility in controlling how data is serialized — for example which data goes in a SOAP header and which goes in the body, which XML namespaces should be used, whether data items should serialize as attributes or elements, or whether to use a "wrapper" element. Regarding performance, dealing with angle brackets is always expensive, but Microsoft has done a ton of optimization and performance work on the XML serialization and we think you'll get good results in high-throughput scenarios.
With WCF we wanted to provide a "future-proof" communication framework, and the extensibility of the programming model supports this. We didn't know what form the new, evolving Web services standards might take, but we knew that developers would want to take advantage of them, when they solidified. We knew that developers would want to employ disparate queuing and serialization technologies. We expected that developers would want to inject custom behaviors such as message filtering or auditing into the message processing pipeline. In short, we knew that out of the box Microsoft would not be able to address all communications requirements for all developers. Because of this, whatever your communication requirements might be, there is an extensibility point in WCF that enables you to incorporate them.
Using the extensibility in WCF, for example, people have built a service host for WCF services that detects changes in a policy repository, and if and when the policy for those services changes, the host stops and re-starts services with the new policy information. As another example, by default a WCF service will expose a modular WSDL, with XSD factored out into external documents. But some tools and Web services runtimes don't deal well with this, and work better with a "flattened" WSDL. A custom service host in WCF can dynamically flatten the WSDL that is generated for a service, to support those tools. Other examples of extensibility: Endpoint behaviors in WCF can be used to implement the injection of custom behaviors into the endpoints of WCF services, and custom serialization logic, for example, to use a binary serialization format can be applied to any operation with an operation behavior. The extensibility of WCF enables all this flexibility.
WCF in practice
WCF is being adopted by companies large and small for building apps that run within services-oriented architectures. A subset of WCF is available for devices that run Windows Mobile. There are a variety of third-party projects that rely on or extend WCF, for example the ESB Guidance from Microsoft available as open source or the custom WCF channel for IBM MQ, available from IBM Corp. as an incubation project.
The future for WCF
First, in .NET 3.5, WCF will update its WS-* protocol support, adding support for the latest OASIS standards including WS-ReliableMessaging, WS-AtomicTransaction and WS-Trust/WS-SecurityPolicy. WCF adds support for REST-style services with a new attribute for a service operation. This allows a simple HTTP request to be dispatched to a WCF operation, keying on the URI in the request. REST-style service interfaces can be included in the applications that expose WS-* style interfaces. WCF in .NET 3.5 includes new support for JSON encoding. This allows a Web page to very easily connect with WCF services using Ajax. And, .NET 3.5 brings syndication support, including RSS and ATOM. This means you can very easily write WCF apps that serve up syndication feeds. You could do this before, but now with .NET 3.5 it's simpler.
The other big addition to WCF for .NET 3.5 is integration with workflow. In .NET 3.0 it was a common customer scenario to expose a service via WCF and kick off a workflow implemented on Windows Workflow Foundation upon receiving a message. Microsoft is providing better support for that scenario in .NET 3.5. One aspect of this is the WorkflowServiceHost, which, relying on the extensibility mentioned previously, enables WCF services to be implemented declaratively using workflows. Another scenario that is better enabled by the integration of WCF and WF is conversational services — for example a shopping cart that persists across service invocations. WCF now allows dispatching of multiple, related requests into a single workflow instance. All this integration was enabled via the standard extensibility points in WCF.
Beyond framework enhancements, there is new designer support for WCF in Visual Studio 2008, which will be released concurrently with .NET 3.5.
About the author
Dino Chiesa is the director of .NET platform product management, Connected Systems Division, at Microsoft.