Our inaugural Get started with Windows Communication Foundation development tip, published in September 2006, provided an overview of WCF messaging basics, versioning, serialization, security and cancelling message streams. This time around, we take a look at service factories, using WCF with IIS and setting up queued calls.
As stated in our previous tip, Windows Communication Foundation is the tool in the .NET Framework 3.0 for building distributed systems. It is a loosely coupled system, which means that its service endpoints can communicate with the rest of the world through a variety of different transport protocols. Information on what Web Services protocols are supported by WCF are available in two documents -- Web Services Protocols Interoperability Guide and Web Services Protocols Supported by System-Provided Interoperability Bindings. (If this seems daunting to you, you are not alone, Harry Pierson writes in Mastering WCF.)
Those developers interested in using IIS, Microsoft's Internet Information Server protocol, should head over to Dan Wahlin's blog. Wahlin's Getting Started with Windows Communication Framework demonstrates how to create a WCF services that is hosted using IIS. "While it could be argued that ASMX services [one of the five messaging technoligies replaced by WCF] are easier to create…" Wahlin notes, "I really like the fact that creating WCF services encourages developers to follow contract-first design principles (designing the data contract, service interface and then the service)."
One way to get acquainted with WCF is by using the Web Service Software Factory for Windows Communication Foundation. Microsoft's patterns & practices group has put together several of these factories -- a mix of code, reference material and documentation -- as a means of giving architects and developers guidance throughout the development life cycle.
Aaron Skonnard, a noted .NET trainer and contributor to MSDN, has put together a tutorial, The Service Factory for WCF, which explains what is to be found inside the factory. In this case, you will find templates for generating contracts of the data, message, fault and service variety, a "recipe" for service implementation, and a guidance package for implementing Web services security.
"Being able to leverage the common recipes produced by [patterns & practices] along with your own domain-specific recipes makes for a compelling combination," Skonnard concludes. "Automating as many of your common tasks as possible will ultimately result in improved productivity and better quality, consistency, and predictability throughout your organization."
One task that can be automated is a process called queued calls. In this scenario, messages are sent to an MSMQ queue and wait for the service to process them. This can be helpful for situations like load leveling, in which messages are sent out over a period of time instead of all at once.
The MSDN article Build a Queued WCF Response Service by Juval Lowy covers the basics of this process. For queued calls to work properly, the client sending the message as well as the service receiving the message each need their own queue -- after all, by the time the service gets the message, the client may be offline. Lowy discusses how to do this while also provides hints for keeping plumbing-level and business-level parameters separate and for properly structuring client- and service-side programming.
The techniques, "such as interacting with message headers, replacing the operation context, writing custom proxy base classes and custom contexts," Lowy concluded, "are useful in many other cases, especially with custom frameworks."
