Windows Communication Foundation (WCF) may not be the flashiest technologies in the current wave of new tools that are being released as part of the .NET 3.0 Framework, but I suspect it will the one technology in .NET 3.0 that most developers start using sooner rather than later. WCF aims to bring a common API to inter-application and inter-machine communication by combining a host of different communications APIs and protocols under a common framework API that abstracts the transport, communication, and service-level protocols. In a nutshell, WCF allows you to publish and consume services using a variety of different protocols and switch between them relatively painlessly. WCF solves some nasty technical problems in a very effective and elegant manner while also managing to stay easy to use.

An Abstraction Layer for Inter Application Communication

Windows uses many vastly different APIs for inter-application and cross-machine communication. Among the more common ways to accomplish this task today are Web Services, low-level TCP/IP sockets, system-level named pipes, or you can use Message Queues to communicate asynchronously. In addition, many developers have built custom schemes based on files, or raw HTTP-based interfaces. On top of that there are different protocols that developers can use from various flavors of XML, to raw binary data, to comma delimited files. In short, there’s a huge mish mash of solutions out there that all work very differently.

The magic of WCF lies in the fact that it provides a very powerful abstraction layer for inter-application communication that makes it considerably easier to build distributed applications that can communicate over a variety of different communication protocols. Using WCF you can communicate over standard HTTP, TCP/IP, named pipes, Message Queues, and use a variety of different protocols like standard SOAP 1.x, WS-* Web services protocols, or use highly-optimized binary representations of the WS-* protocols. Microsoft created the abstraction layer so that there’s a common programming model applied against all of the supported transports and protocols and it’s easy to switch between the different protocols without major changes in the front end code that uses it. This makes it much easier for developers to integrate distributed functionality into the application business layers or-at an even lower level-the application framework level.

So, for example, it’s almost trivial to publish a WCF service that publishes its service contract via HTTP as well as using TCP/IP. It’s nearly as easy to allow a WCF client to consume that same service either over HTTP or TCP/IP. Although the protocol and session semantics of HTTP and TCP/IP communication are vastly different, WCF can provide a common model to access either one of these services. This might not seem like such a big deal-after all, how often do you really need to provide a dual interface? The answer to this is that in the past developers would rarely provide a dual interface to a service-based interface because it was rather difficult to do. But now with WCF, building a client that can choose the optimal protocol to talk to a service is actually easy enough that it makes perfect sense to bake this right into an application.

While WCF to WCF service interfaces can reap the biggest benefits of the framework, WCF firmly supports standards-compliant SOAP 1.x services both for publishing services and for accessing them. WCF as a whole is based solidly on W3C standards or recommendations-all WCF messages are based on SOAP and the SOAP 1.x, WSDL 1.x./2.0 and WS-* protocols, even though some of the transports support using binary representations of these message formats.

Implementing WCF applications is relatively straight forward and provides immediate benefits for any developer who’s using Web services or .NET Remoting in their applications today, without having to completely relearn a new technology. The abstraction in the technology makes it possible to build a service once and publish it to multiple endpoints that can use different wire and/or communication protocols. For example, in a pure Web service environment it’s almost trivial to create a WCF Web service that publishes the service to both a plain SOAP 1.1/1.2 interface and WS-* compliant interface. In fact, it’s as easy as defining and additional endpoint in a configuration file without additional code.

Both WCF services and the client can easily switch between different bindings and access services through different protocols with the same codebase. This makes it much easier to choose an optimal wire protocol and to integrate service-based functionality that’s capable of dynamically switching its service protocol. For example, you can have a data provider that locally uses a named pipe binding, and for remote access uses an HTTP binding. Same code, same logic, all that has to change is a configuration setting or, if you prefer doing it in code, changing the client proxy instantiation code. Once a proxy has been configured from the service the behavior is the same.

This is huge! While both Web services and .NET Remoting were relatively straightforward to use in .NET before, the implementation and configuration of these technologies was significantly different. Switching between the two wasn’t easy due to the difference of implementation. WCF provides a common interface for many communication mechanisms and so it becomes much easier for applications to dynamically choose which type of connection interface to use. This is good news for applications developers, but even more so for framework developers who often need the flexibility to connect to different types of environments.

WCF also provides much more functionality than what was possible with Web services, WSE 3.0, or .NET Remoting, but the base scenarios addressed by these technologies can still be addressed easily and more importantly interchangeably by WCF. It provides higher level protocol management that brings many higher-level features like authentication, encryption, state management, and transactions to the various supported protocols. These kinds of services have been very difficult to implement in the past and WCF provides this functionality as part of the base API in a consistent manner. Microsoft designed WCF entirely based around the SOAP protocol-even for non-text based protocols-and Microsoft based most of the implementation on the WS-* Web service standards. Not all protocols support all features obviously. For example, BasicHttpBinding (SOAP 1.x over HTTP) can’t support any of the WS-* protocols, while the WSHttpBinding can as well as the binary TCP/IP and named pipe transports. But most of the base service functionality is available to all of the supported transports/protocols and there’s a large area of feature overlap to provide a common baseline.

Contract-based Service Implementation

WCF encourages contract-based programming, which means that it tries to push you into defining your service contract interface explicitly with a .NET interface that you then implement explicitly on an implementation class. The contract interface is marked up with a ServiceContract attribute with each exposed service method marked with an OperationContract attribute. This is similar to the WebService and WebMethod attributes in ASMX-style Web services and the overall model of WCF is roughly similar to the ASMX model. WCF defaults to separating out the service interface and implementation and, although it’s not strictly required, it’s highly recommended.

The advantage of this seemingly trivial difference is that by using interfaces you can reuse the service contract and potentially share the contract between client and server. By sharing the contract you can, in many cases, bypass importing and generating of an explicit service proxy class imported from a WSDL file. The interface implementation also allows for better versioning of a service implementation. If you make a change to your implementation that affects the interface, you can create a new interface and implement that on your implementation class. When you do this both the old interface and the new interface can work off a single implementation class.

In addition, you can also define data contracts to explicitly specify how to expose return values and parameters (message types) to the service. You define a data contract on a class with the class marked with a DataContract attribute and each member that is to be published on the class marked with an explicit DataMember attribute. You can then use these types as part of your service method parameters and return values and be guaranteed that your messages published in the WSDL (and correspondingly by any WCF proxies) match the signature of the data contract. Data contracts can be applied explicitly to message object classes, or if you’re using a framework of some sort, you can apply these attributes to business entities directly. For example, in my application framework I generate business entity objects either directly from the database or from an XML schema. I’ve modified the generator so that it can optionally generate the DataContract and DataMember attributes for the generated types, which allows me to directly publish my business entities as DataContracts. This works well and again makes it possible to create a data contract that I can share between client and server. Unfortunately you cannot define data contracts on interfaces so you must define them on implementation classes or structs so there’s a bit more tight coupling in this mechanism than with a service contract.

The data contract makes it possible for you to design your message types declaratively. I think of data contracts as an object data to message mapping approach. It’s an object oriented way to design your messages.

At an even lower level it’s possible to design a message contract using the MessageContract attribute, which makes it possible to explicitly design the layout of the messages that go on the wire. This approach is considerably more low level, but likely appeals to the SOA purists who work in the Message Über Alles mode and want full control over all aspects of the messages. Message contracts are a much more message-oriented approach. This is very powerful, but definitely an advanced feature that I haven’t had much time to look into yet. In fact, I hope I don’t have to: This is the sort of thing I hope that WCF can insulate me from. But if you are working in sophisticated SOA architectures where you need explicit control over messages or you want to create your own custom protocol implementation then this functionality is available to dive very deep into the message stack.

Client Proxies

The normal process to use WCF on the client is to hook up to a WSDL endpoint and then use Generate Service Reference to create a proxy class and its dependent message objects for the service. As I mentioned earlier, WCF uses SOAP protocols all around so it publishes its metadata using WSDL. WCF uses a special metadata exchange (MEX) endpoint to provide the service definition to clients. The MEX endpoint can be accessed by clients over any of the protocols the service supports. One unobvious gotcha is that MEX functionality is not enabled by default, unlike ASMX WSDL which is always accessible. A MEX endpoint must be explicitly configured and it’s easy to forget although you will quickly figure out that it’s missing because you won’t be able to build a proxy from the service without it. The published metadata includes information about each of the endpoints available on the service as well as the actual service definitions and message types.

If you’re using Visual Studio with the .NET 3.0 SDK installed the Generate Service Reference is available in most projects (though not in stock Web projects). This actually runs the SvcUtil.exe utility installed with .NET 3.0 that is responsible for creating the service proxy. SvcUtil.exe is the proxy generator (similar to WSDL.exe) but there are a many more options on this tool to fine tune how the proxy classes are generated. The generated proxy class basically maps the service’s methods and its dependent objects by duplicating them on the client.

Because service contracts are meant as a metadata definition for the service and its dependencies, these contracts can also be shared between the client and server directly by using the contract assemblies both on the client and the server. This means if you control both ends of the WCF connection, you can bypass the proxy generation step on the client and directly instantiate a proxy off the ServiceContracts and DataContracts. This requires a slightly different approach using raw ChannelFactories explicitly and manual configuration, but it’s still very easy to do with just a few lines of code. This removes any ambiguity by avoiding importing and translating of WSDL into a proxy altogether.

It also makes it much easier to load live business objects directly with data returned from a service as opposed to the two-step process of retrieving a message object and then transferring the data into a live business entity. I’m very excited about this particular aspect because this has been a real pain with stock Web service proxies in .NET 2.0 where I haven’t been able to easily get my data into business entities. (I can use Soap Extensions but it’s not very generic). As I mentioned earlier I can now generate a data contract directly on my business entities and then share these entity objects on both ends of the connection. WCF can then use the shared ServiceContract and DataContracts and directly load the service data into instances of my business entities.

If you want even more control over the actual SOAP message format or you want to completely create a SOAP conversation manually you can dig even lower by using a MessageContract which allows defining protocol-level tags using attribute-based class markup. In lieu of an explicit DataContract, WCF can still use default .NET serialization; any class that implements ISerializable can be serialized, but be aware that this uses binary serialization semantics by default rather than XmlSerialization that ASMX uses. This can cause some differences for your service when you upgrade it from an ASMX service. XmlSerialization by default uses public member serialization whereas binary serialization uses private field serialization and these semantics are reflected in the message objects that are exposed in WSDL and are correspondingly picked up by a WCF proxy. While in theory you shouldn’t care how data is serialized and re-hydrated on the other end, it’s no fun to get a proxy object passed to you that has an accessible _InternalLock field, for example. You can, of course, mark fields as [NonSerializable] but the client proxy may still look funky with private fields exposed. If this is a problem you can also tell WCF explicitly to switch to use the XmlSerializerFormat attribute on the service contract.

What all of this amounts to is that WCF is more formal in describing how the service behaves and while it involves more code than an ASMX service did, this contract-based implementation gives you much more control over how the data of the service is published and passed around while at the same time still remaining easy to use. The base concept is the same, but there just many more options that you can apply.

Hosting

Services can be hosted in a variety of different environments. WCF defines its own hosting architecture that runs in a separate AppDomain and provides its own thread management, which means that it is very flexible in how services can be hosted.

Like .ASMX, IIS can host WCF services using a new .SVC extension that is mapped to a custom HttpHandler. IIS hosted services can publish services using any of the support Http bindings like BasicHttpBinding (Soap 1.x) and WSHttpBinding (WS-*). The process of hosting is similar to an ASMX service-the .svc page defines the server address and there’s a code behind file that gets created. Alternately you can assign any class to the .svc file to act as the codebehind which is usually a good idea and allows you to isolate the service implementation and contracts in separate assemblies so they can be reused with different hosting environments.

Microsoft also introduced the Windows Activation Service (WAS), which is a more generic hosting container that’s based on the same concept as IIS Application Pools. WAS allows running any of the supported WCF service protocols rather than just HTTP. WAS works through IIS 7 and is added to IIS as a special binding that is tied to a specific port. WAS takes advantage of the IIS Application Pool architecture and so provides automatic activation and process isolation. Configuring WAS requires using command line tools to add explicit protocol and port bindings to a given Web site (http://tinyurl.com/ykokqt).

Finally you can also host WCF services in any application that can run the .NET runtime or at least one that can host it. Console application, Windows Forms, and Windows Services can all host WCF services. Even non-.NET applications can do it using COM Interop to host a .NET component which in turn hosts a WCF service. This is very powerful as you can dynamically link machines together. This gets even more interesting with the PeerTcp binding that supports broadcast type messages to many clients in a peer mesh simultaneously.

First Impressions

I’ve watched WCF from the sidelines prior to the release of .NET 3.0. I’ve read a number of articles and did some research on the base concepts of WCF during the beta/CTP phase, but I didn’t actually dive in and write any code prior to release. When .NET 3.0 shipped I finally felt compelled to take a look and experiment and implement a handful of small services that were previously implemented using ASMX technology. I spent a few days in immersion mode, reading everything I could get my hands on while building a couple of small sample services and updating a couple of live applications that previously used ASMX services. This is hardly representative of the feature set of WCF, but it gave me a good idea of base features and what it takes to put this stuff into real world use.

What struck me most about the technology when I sat down to build my services was how straightforward the process was. WCF certainly has a high level of complexity under the covers, but the beauty of this technology is that most of this complexity is hidden until you need it. The .NET 3.0 framework provides defaults that make it easy to get started with a minimal tweaking of settings. In the end you can get up and running pretty quickly. So if you’ve built and consumed Web services before you should feel fairly comfortable with the base functionality of WCF because the process is similar.

However, let me also note some differences. WCF is more strict in its implementation of services and tries hard to enforce contract-first design by using explicit service contracts. Using contracts-especially data contracts-can require some extra design considerations that you might have skipped in the past with ASMX-style services. But overall the process is still relatively easy, but a little more work intensive. More up front design is required and that’s probably a good thing.

On the flip side, if you want to go deep and tweak every configuration setting to the lowest level possible you can do that too. You can do everything in code or choose to handle most of the configuration through .config files. It’s really cool how much you can actually accomplish through mere configuration settings. Conveniently the configuration settings also map the actual framework hierarchies so setting properties on a binding object have the same name as the .config file settings in a configuration section with the same name which makes the learning curve much easier as you learn both from code and configuration settings. There’s consistency here that’s been so very rare in Microsoft APIs of the past.

On the downside, at the moment there aren’t any good, current books available for WCF, so finding out about WCF requires you do to a little digging. Early next year there will be several books released for WCF. You can find a lot of information on WCF available on MSDN and on various WCF team member blogs as well as from many independent bloggers, but I think this information is scattered about a bit and not very coherent. The good news is that if you get stuck you can usually find a solution by using your favorite search engine.

If you’re looking for a great technical introduction to WCF in the size of an article, check out “WCF Essentials-A Developer’s Primer” by Juval Lowy in the May/June 2006 issue of CoDe Magazine (www.code-magazine.com/Article.aspx?quickid=0605051). I also found Michelle Leroux Bustamonte’s sample chapters for her forthcoming WCF book very useful and easy to follow. Even the first few chapters cover tons of content and gives great insight into the basic concepts of WCF. (www.thatindigogirl.com).

WCF vs. ASMX

There’s some overlap between WCF and ASMX Web services and the WCF and stock .NET 2.0 Web service client implementations. It’s a valid question to ask: Which should you use? I don’t have a definite answer but here are some things to think about.

I think it’s pretty clear that going forward Microsoft will focus on WCF as its service architecture so Microsoft will make any improvements to implementation and compatibility issues with standard compliance etc., primarily in WCF.

On the client side WCF proxy usage is nearly identical to .NET WS proxy usage while WCF has the clear advantage of supporting much better configurability and the ability operate with multiple protocols with minimal code changes. On the other hand, WCF requires the .NET Framework 3.0 installed so there’s an additional component that you must install on the client. Currently only Vista installs with .NET 3.0 installed and it’s not clear yet whether Microsoft will push .NET 3.0 down to Windows XP via Windows Update or not.

On the IIS server side WCF usage is maybe less of slam dunk in that you probably are limited to using HTTP-based protocols. ASMX works fine for HTTP and SOAP 1.x and it’s slightly easier to build and work with than WCF services. For example, WCF lacks the handy ASMX feature that allows you to quickly test a Web service through an HTML interface. But if you need to implement WCF-based services or possibly even services using more high performance interfaces like TCP/IP then WCF starts to make a lot more sense on the server.

I would argue that using WCF for any new services is probably a good idea even if you stick with pure HTTP and SOAP because by creating your service with WCF you can decide later on to publish this same service using WAS and also provide the more high performance TCP/IP transport. Or you might be asked to provide some of the advanced features of WS-* protocols like transactions, attachments, session management, encryption etc. By using WCF you are building your service with a view to the future so you can easily move up to other protocols-some of which may not even exist today. Certainly new technologies will come along in the future and WCF protects you somewhat through its abstraction layer and common API.

Summary

I’m pretty excited about WCF. I’ve gone through several of my internal applications and have replaced the ASMX services with WCF services. The process has been smooth and I’ve been able to increase the performance of a couple of these services significantly by switching to TCP/IP messaging. But more importantly, I’m excited about the possibilities that WCF offers. In the past I’ve been using Web services technologies on a pretty basic level because doing anything more than basic request and response functionality was rather difficult to do. With WCF it’s going to be much easier to build more complex logic that can span across the network that I wouldn’t even have attempted previously. A lot of opportunities for applications are opening up with this stuff and I’m stoked.