When Juval Löwy asked me to write the foreword for the first edition of this book, I was working in a Community Program Manager role for the brand-new Windows Communication Foundation (WCF) framework at Microsoft. WCF was the result of a multiyear effort to write a unified communication framework for Windows. It was also the result of a multiyear effort to create an interoperable messaging standards framework centered around XML and the SOAP envelope model, with a common model for addressing; a transport-independent abstraction for session management and ordered delivery semantics; and a common model for message and session protection, for federated authentication and authorization, and for many more capabilities. This industry-wide standardization effort is still in progress with Microsoft and partners across the industry, refining and updating this common messaging framework (summarily nicknamed “WS-*”), more than 10 years after the SOAP 1.1 specification was submitted as a note to W3C, which started this process.
As I write the foreword to the new edition, I’m filling an Architect role on the Windows Azure AppFabric team at Microsoft. More precisely, I’m contributing to the architecture of the service bus, a service offering that’s part of the Windows Azure Platform and which Juval covers in Chapter 11 and the appendixes of this book. The way I commonly describe the effort of building a commercial web services infrastructure, like the service bus or its sibling service, Windows Azure AppFabric Access Control, is to use the familiar iceberg analogy. The “above the water” features that the customers get to interact with on the public protocol and API surface area make up a relatively small portion of the overall effort. The rest, all the things beneath the waterline, quite closely resembles a large-scale, mission-critical Enterprise application infrastructure—with the special quality and challenge of running on a public cloud-based infrastructure.
When you create a Windows Azure account, your data and the provisioning jobs run through WCF SOAP services. When you create a new service namespace in our system, the messages flow between data centers using WCF SOAP services, creating resources in the places where you ask for them to be created. Monitoring happens via WCF SOAP services; diagnostics happens via WCF SOAP services; billing data collection, consolidation, and handoff happens using WCF SOAP services.
As people providing a public web service infrastructure, we’re looking to provide equally capable messaging-centric and REST protocol heads and resource projections across the infrastructure. Because of concerns about broad reach into browsers and devices, the prioritization often plays out in a way that the REST protocol heads for the public protocol surface area win out and get built first—and mostly on top of the HTTP web programming model provided by WCF. However, there has never been any serious debate or question in cross-team engineering discussions about the interfaces between the various subsystems under the waterline not being SOAP-based endpoints built on WCF. Everyone already went into the room with the assumption that they would be.
Building the backbone systems for a cross-team effort at Microsoft with several hundred engineers and an investment volume the size of the Windows Azure Platform is at or beyond the complexity level of many mission-critical Enterprise systems. Running such a system and upgrading or changing parts of such a system in flight and without downtime is not only complex, it’s an art form. You need loose coupling between subsystems, you need a lot of flexibility and extensibility, and you need to have a clear notion of what that other system is going to accept and return in terms of messages. What I keep finding is that once you confront a “simpler” communications model with real-world requirements of the sort we’ve got on the Windows Azure backbone, you almost inevitably end up reinventing the wheel at the protocol level and you increasingly make the life of implementers harder.
WCF is a great technology because it deals with the complexity of flexibly interconnecting applications. It’s great because you can build SOAP services, building the backbone of your systems that can interoperate with other services on other platforms with similarly capable web services stacks, such as those built by Oracle/Sun, IBM, or the Apache Foundation. It’s great because it allows you to build the “broad-reach” HTTP/REST resource projection surface of your system on the same foundation.
The book you have in your hands is rightfully “the book” about the Windows Communication Foundation. Continuously improving our skills at architecting and building distributed business applications is a passion that Juval and I share.
This book is going to help you learn about the “distributed” part—how to hook stuff together and how to do so securely, reliably, and in a loosely coupled fashion—all from Juval Löwy, one of the most prominent distributed systems experts in the world today.
Programming WCF Services shows you in great detail what we here at Microsoft have built as a foundation for your applications and services, and the book conveys it with the accuracy, teaching skill, and dedication to architecture that Juval is justly renowned for around the globe.
I’ll stop now. Turn the page. Start reading.
Get Programming WCF Services, 3rd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
