Foreword
I started working on the Windows Communication Foundation in 2001 (then known as
“Indigo”), when we were a small team—I was perhaps the 20th person to join. In my
tenure on the team, I served as lead program manager for storage, manageability, reliable
messaging, and queuing. The team had a great vision of facilitating the next generation of
Web services by creating a foundation for Web services that could be practically applied to
a breadth of distributing computing problems. We wanted to ensure that Web services
could be implemented for businesses that enable secure communication—confidentiality,
signing, federation—so distributed computing customers could use Web services for
communication in the real world. We wanted to make sure that Web services could partic-
ipate in transactions in the ACID model, ensuring that practical interactions with data-
driven systems, or with which “all or nothing” computing is essential. We wanted to
ensure that Web services could be written in a way that lossiness of the WAN didn’t
inhibit development of meaningful distributed applications—where you could actually
count on messages getting where you sent them, and in the order you sent them. In
retrospect, these “basic plumbing” goals seem almost quaint, but in 2001 we accepted, for
the most part, the need to “do it ourselves” when building distributed systems.
We also understood that most computing environments are heterogeneous, with systems
from many vendors coexisting with each other, so we wanted to ensure interoperability
through great technical web service standards. We made a deep commitment to interoper-
ability, and executed relentlessly on that commitment. WS-Security, WS-
AtomicTransactions, WS-ReliableMessaging, WS-Management, WS-Policy, WS-Transfer,
WS-Eventing and others were essential for broad interoperability at the “basic plumbing”
level—but none existed when we kicked off this project (all were made possible in greater
or lesser part by colleagues on the WCF team). Looking back, we might say “Of course we
want to work with other systems with broadly accepted composable Web service stan-
dards”—but again, in 2001 this was a lofty goal.
We wanted to support a single programming model so developers wouldn’t face a new
learning curve if they wanted to shift from message-oriented to remote procedural para-
digms, or to go from TCP to HTTP or queuing protocols such as MSMQ. In the face of
.Net Remoting, ASMX, Sockets, MSMQ, and other programming models, a unified API to
accomplish what any of its predecessors could seemed difficult—we were trying to forge
one from many. We wanted to support extensibility, so that each new message exchange
pattern, protocol, or encryption mechanism wouldn’t force yet-another programming
paradigm.
For my part as a lead program manager, I helped champion manageability—the idea that
anything that should be left to the IT pro (protocol du jour, encryption mechanisms,
service addresses, monitoring aspects, and so on), could be. Here again we had lofty
goals—we wanted best-of-breed tracing, intrinsic monitoring and control of applications
built with WCF, ease of use through great configuration and tracing tools, and integration
我的内容管理
展开
