Justin Smith - Inside Windows Communication Foundation

Services are a major part of modern software architecture, and Microsoft Windows Communication Foundation (WCF) is the platform for building services for Microsoft Windows. Services written in WCF are able to interoperate with services from other vendors (for example, IBM, BEA, and Novell), and WCF is extensible enough to keep pace with the inevitable evolution of industry standards. Regarding transports, WCF supports TCP/IP, HTTP, Microsoft Message Queuing (MSMQ), and named pipes. WCF also supports a full array of WS-* (pronounced "WS-star") protocols like WS-Addressing, WS-ReliableMessaging (WS-RM), WS-AtomicTransaction (WS-AT), WS-Security, WS-SecureConversation, WS-Trust, and WS-Federation. Applications that use WCF can send and receive SOAP messages and Plain Old XML (POX) messages. In the future, Microsoft will undoubtedly broaden the capabilities of WCF to include new transports, protocols, and message structures. Microsoft views WCF as the I/O system for services. Although the future is never certain, it is safe to say that Microsoft is not going to replace WCF with another product in the foreseeable future. Consider as evidence the fact that many products like Microsoft BizTalk Server and Microsoft Windows Live Server are fully embracing WCF.

The goal of this book is to equip the reader with the information necessary to design, develop, and maintain services using WCF. In my opinion, these tasks require more than just having a working knowledge of the WCF programming model. Success with WCF requires an understanding of the principles behind services, the WCF programming model, and the WCF infrastructure.

This sort of coupling is not a new idea; it comes from past experience. When object orientation was gaining popularity, developers and architects making the transition from procedural programming to an object-oriented language needed to know more than just the new syntax of the language. If procedural programmers began using a more modern language without understanding how to design objects, they simply created procedural applications in the new language. Although these applications could be compiled and run, they did not take advantage of the functionality offered through object orientation. It is my view that the same will be true of developers who start to use WCF without a clear picture of how to leverage the power of service-oriented application designs.

Some think that this approach is a waste of time. In their opinion, the WCF team has successfully abstracted the messaging infrastructure away from the normal programming model, and as such, there is no need to address the underlying service-oriented paradigms or how the WCF infrastructure implements these paradigms. I completely disagree with this viewpoint. The level of abstraction attained by the WCF team allows applications to be developed more quickly. It does not, however, completely release the developer or architect from the responsibility of making the shift to service orientation or understanding how a WCF application works internally. In much the same way that successful adoption of an object-oriented language like C++ or Java required developers to shift their thinking from procedural programming to object orientation, successful adoption of WCF requires developers to evolve from a component-oriented mindset to a service-oriented mindset. If we fail to make this shift, we run the risk of missing out on many of the features offered through service orientation. Simply writing a WCF application and getting it to compile and run is only part of the battle. Understanding what's inside as well as understanding the new programming paradigm are equally (if not more) important in the long run.

Even if we do not care about the features offered by service-oriented architectures, we should understand the WCF infrastructure. In other words, we should know our platform. The common language runtime (CLR) offers supporting evidence for this stance. The CLR team did a great job abstracting the garbage collector and the JIT compiler away from the developer. As a result, it is technically possible for us to write Microsoft .NET Framework applications with little or no knowledge of how these subsystems work. Failing to understand these concepts, however, increases the risk that we will write inefficient applications. For example, a C++ developer moving to C# without any knowledge of the garbage collector will instinctively add a finalizer to all type declarations. Unknowingly, this developer will have increased the time required to allocate these objects and increased the lifetime of these objects. For most C++ developers, simply saying "don't do it" isn't enough. They want to know why. Technically, adding a finalizer to a type is not a bug, but it is certainly an inefficiency that could have been averted through a couple of hours spent with a book or in a good training course.