Microsoft's Windows Communication Foundation is a new loosely coupled tool for building distributed systems. The idea is that a better messaging system leads to improved architecture, faster data processing and greater scalability.
WCF replaces five existing Microsoft technologies -- ASP.NET Web Services (ASMX), .NET Remoting, Enterprise Services/COM+, Web Services Enhancements and the Microsoft Message Queue -- and stands as one of the major pillars of .NET 3.0. It is no surprise, then, that developers everywhere have been playing with WCF for months and developed best practices for working with it. Here we offer a sampling of tutorials and blog posts about Windows Communication Foundation that we have seen in recent weeks. As always, if there are resources that you would like to share, send us an e-mail and we will add it to the list.
Messaging basics: A good start is MSDN's Introduction to Reliable Messaging with WCF by Clemens Vasters, a community program manager on the WCF team. Vasters focuses on how Windows Communication Foundation allows application developers to align their messaging sessions with the WS-ReliableMessaging specification.
"[T]he implementation of reliable messaging [is] a mere matter of picking the right binding configuration for a service and service client, [but] it is certainly useful to have a bit of an idea of what's going on behind the scenes and on the wire," he writes. From there, Vasters describes the characteristics of a reliable messaging session, lists the configuration properties of a session's binding elements and covers the types of bindings that Windows Communication Foundation provides for reliable messaging. (The binding is one element of WCF's "ABC" messaging model, in which developers write a contract, define a service binding and bind the contract to an address.)
Versioning: Another WCF group member, Craig McMurtry, has posted a handy tutorial called Versioning WCF Services. Here McMurtry covers what developers should keep in mind if they plan to modify a service. The plan varies depending on whether modification means adding a new operation, changing an existing operation or changing the data contract that is part of an existing operation, McMurtry notes.
The only breaking change involved in modifying services is retiring old endpoints. "To make it easier to retire endpoints, you should include a default operation for every service contract that you ever define, and you should specify that operation can throw a fault indicating that the endpoint has been retired," McMurtry notes. "The information provided with the fault can direct the client to the metadata for the replacement endpoints."
Serialization: Along with versioning, serialization is a key consideration when working with Windows Communication Foundation. Serialization, the process of mapping between .NET objects and XML Infosets, should be familiar to ASMX users, Aaron Skonnard writes in the MSDN article Serialization in WCF. One major difference, though, is that WCF offers three serializers. In addition to the XmlSerializer that is included in ASMX, there is the DataContractSerializer, which can operate on any .NET type annotated with either the [DataContract] or [Serializable] attributes, and the NetDataContractSerializer, which serializes .NET type information into XML. Each serializer has a proper place, Skonnard writes:
You should use DataContractSerializer whenever possible in Windows Communication Foundation. Its constrained mapping improves interoperability when starting with code. NetDataContractSerializer should only be used when you absolutely need type fidelity across the wire. Alternatively, you should use XmlSerializer when you need backwards compatibility with ASMX types, you need more flexibility in the XML representations, or you're starting with existing schemas that don't meet the [DataContract] mapping constraints.
Security: Any time information is going across the wire, security is a concern. The model for securing bindings in Windows Communication Foundation is based on confidentiality (encrypted messages), integrity (a check on a message's content) and authentication, Keith Brown writes in the MSDN article Security in WCF. First, developers must decide whether to provide security at the transport level or at the message level. Then the credential level for client and service must be considered. There are five options for credentials -- None, UserName, Windows, Certificate and IssueToken, the latter of which incorporates Windows CardSpace identity management technology. These considerations, in part, will determine which of the three WCF binding types should be used, Brown notes.
Cancelling streams: No system is perfect, so there will be times when a message has to be cancelled mid-transmission. There are several ways to do this -- some good and some not so good -- Nicholas Allen of the WCF team writes in the blog entry Cancelling Streams. Aborting the stream is quick, but it's not painless, since a connection needs to be reestablished and there is no record of why the message was aborted. Sending a fault message does not help either, since the client creates that after the original message has been sent. Ultimately, Allen says, developers should use both a data channel and a control channel: "Using a layered channel would allow you to remove the logic for establishing the control connection from the application and would eliminate the need to define the control operation contracts by hand."