Programming WCF Services

Foreword

Juval Löwy, the author of this most excellent book, and I share a passion: designing and building distributed systems—or, as they are increasingly called today, connected systems. Both of us have walked a very similar path on the technology trail, even though we’ve always been working in different companies and on different projects and, for most of our careers, also on different continents.

In the early 1990s when both of us slowly got hooked on the idea of doing something on one computer that would cause something to happen on another computer, the world of distributed systems application platform technologies just began taking shape around us.

As workstations and server hardware became more affordable and increasingly commoditized, building large systems that weren’t dependent on a single transaction hub in the middle became an economically attractive proposition. The same was true for wide-area data exchange options. It’s difficult to believe these days, but my telephone company insisted back then that more than 1,200 bits per second would never be possible over phone lines. Today they run 6 MBps and more over the same copper. These were exciting times.

With the technology for affordable distributed computing coming together, two large distributed systems technology camps emerged in the early ’90s: DCE, led by Digital Equipment Corporation (eventually gobbled up by Compaq, gobbled up by HP) and CORBA, driven by the OMG consortium, with a great dose of IBM backing. In 1996-1997, all of those great engineering efforts came to an effective stop. Here was the Internet and the world started to be obsessed with (a) HTML, (b) HTTP, (c) venture capital, and (d) IPOs.

It took the industry 10 years to recover from the bubble and its bursting. Not only economically, but also from a technology perspective. The good that came from that is that there are no longer two distributed system technology camps, but just one—or several dozen, depending on your perspective.

As of 2007, the industry is still in great disagreement about the “right way” to write code for distributed systems. Someone from Sun Microsystems or BEA will likely tell you that it’s got to be Java; my colleagues here at Microsoft (and I) will most certainly tell you that we believe that C# or Visual Basic is the way to go. What neither Sun, nor BEA, nor IBM, nor we here at Microsoft are disagreeing about anymore is how to talk to each other on the wire. Given the DCE versus CORBA wars of the past, the fact that consensus was reached over the specification that is the foundation of this truce—SOAP 1.1—was quite a spectacular sensation.

More than six years have passed since SOAP 1.1 was submitted as a technical note to the W3C. Since then, a great number of SOAP-based specifications, ranging from fundamentals, such as addressing, and a broad range of security options up to enterprise protocols, such as atomic transaction coordination, have been developed and negotiated between many industry partners.

My team here at Microsoft, which still informally calls itself by its product’s code name, “Indigo,” has been at the heart of these development and negotiation efforts. Without IBM’s, Microsoft’s, and other partners’ strong commitment to creating a common set of standards, even though we are all competing fiercely in the enterprise space, little of this open-standards framework would exist, much less would there be multiple implementations from so many vendors and such a variety of platforms.

Admittedly, it took a year or two longer than it probably should have. Agreement takes time and we would simply not have released our software, the Windows Communication Foundation, without making sure it would interoperate well with our industry partners and competitors. Design also takes time and we would not have released our software without knowing that we have a development experience that feels familiar to our customers who have invested time in learning and adopting our previous distributed systems technology wave, which included ASP.NET Services, the Web Services Enhancements (WSE), .NET Remoting, Messaging/MSMQ, and Enterprise Services/COM+.

The technology list I just cited has five technology names on it, and if you were counting the respective unmanaged code counterparts and underpinnings there would even be more. One of our most important design goals for the Windows Communication Foundation can be summed up in a simple phrase: one way to program. Whether you want to build a queuing application, a transactional N-Tier application, a mesh of P2P clients, an RSS feed server, or your own Enterprise Services Bus, you will no longer have to master a multitude of different technologies that each solve a part of the problem. The Windows Communication Foundation is what you learn and use. One way to program.

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.

We from the Connected Framework team at Microsoft are very satisfied with what we’ve built. We give you an infrastructure that unifies the distributed technology stack, is broadly interoperable, promotes service orientation, is straightforward to learn, and is very productive to build on. Juval Löwy is one of the most prominent distributed systems experts in the world today, and we are very proud that Juval is dedicated to the Windows Communication Foundation. We are quite confident that Juval will help you understand why we, Juval, and our early-adopter community are thrilled about the product and the new opportunities that it creates. Enjoy the book and have fun building your first WCF services.

—Clemens Vasters

Program Manager, Connected Framework Team

Microsoft Corporation