所有WCF开发者必看的一本书
——WCF研发团队项目经理Alex Weinert强烈推荐
我从2001年开始从事WCF（那时称为“Indigo”）的研发工作，当时我们还是一个小团队，我应该是第20位加入该团队的成员。在该团队任职期间，我是存储、可管理性、可靠消息和队列方面的项目经理主管。我们的团队有一个宏伟的愿景：通过为Web服务创建一个基础，使之可以实际应用到广泛的分布式计算问题上，促进下一代Web服务的发展。我们希望确保为各种业务而实现的Web服务可以提供安全的通信——机密性、签名、联合，于是分布式计算客户就可以为现实世界中的通信使用Web服务。我们希望确保Web服务可以融入到ACID模型的事务中，确保其能与数据驱动的系统或那些事务性计算任务进行有效的交互。我们希望确保Web服务可以某种方式编写，从而使广域的松散性不会再约束有意义的分布式应用程序的开发。在这些应用程序中，消息能以发送的次序达到你想发送的地址。这些目标如此涉及底层，现在看起来甚至有点奇怪，但是要知道，在2001年我们都接受这样的事实：当创建分布式系统时，其中的大部分工作都需要自力更生。
我们也知道大部分的计算环境都是异构的，许多厂商的系统同时并存，所以我们希望通过伟大的Web服务技术标准确保互操作性。我们决心实现良好的互操作性，并且全力地实现了目标。要在底层实现广泛的互操作性，WS-Security、WSAtomicTransactions、WS-ReliableMessaging、WS-Management、WS-Policy、WS-Transfer、WS-Eventing等协议都是必需的。但是，在我们开始这个项目时什么都没有，它们都是由WCF团队的同事们后来实现的。回顾以前，我们可能会说：“我们当然希望通过被广泛接受的、可以相互组合的多个Web服务标准使用其他系统。”然而，这在2001年却是一个高不可攀的目标。
我们希望支持一种单一的编程模型，使开发者从面向消息转向远程过程性模式，或者从TCP转向HTTP或MSMQ等队列协议时，不需要从头学起。面对.NET Remoting、ASMX、Socket、MSMQ等众多的编程模型，用一套统一的API完成上述各模型的任务显然很困难，但我们仍然迎难而上。我们希望支持可扩展性，这样再出现新的消息交换模式、协议或加密机制时，也无需另外一种编程模式了。
作为首席项目经理，我帮助贯彻了可管理性这一理念，也就是任何应该交给IT专家决定的信息（当前的协议、加密机制、服务地址、监视，等等）都尽可能交给他们。这又是一个极高的目标：我们希望用WCF创建的应用程序具有最好的跟踪、监控和控制功能，易于通过优秀的配置和跟踪工具使用，而且能通过WMI与所有的Windows管理工具集成。简单地说，这个目标就是让使用WCF创建的应用程序比基于其他框架创建的应用程序更具可管理性，而且管理成本更低。
我们希望为现实世界创建重要的分布式应用程序能变得简单而又有趣，这可能是我们最富雄心的目标。我们希望直观地引导开发者创建符合分布式系统最佳实践的应用程序。正如Steve Swartz（“简单而又有趣”最忠实的倡导者）所告诉我的，我们的目标是创建这样的一个框架，“如果你在山顶放一个球并让它滚下来，它就会自然地在一个地方停下来，这个地方有一个构架优良的服务，它帮你避免了分布式系统开发者在过去20年里犯下的所有错误。”
那我们做得怎么样呢？看看在Vista中和网络上作为.NET 3.0一部分发布的最终产品，我认为我们做得相当不错。WCF是一个统一的、可扩展的框架，它确实可以帮助你以一个统一的框架去创建现实世界中的安全的、可信赖的、互操作的、可管理的分布式应用程序，而且这个过程实际上很有趣（至少对于喜欢编程的人来说是这样的）。这花了我们六年时间，但是我们实现了所有的主要目标。实际上，我非常喜欢这个产品，现在我的“新”工作就是为Microsoft创建完全基于WCF所提供的功能的新产品，以推广WCF（我现在很享受这份工作）。这个团队中的每位开发人员和项目经理的书架上都有这本书，几乎我们所有的人都把这本书作为开发或使用Web服务的必备参考书，其中还包括几位实际上开发了WCF的开发人员和项目经理。
最后说说Craig吧。我和Craig认识的时候，他身为WCF技术的传道者。他的精力和对项目的热情很有感染力，他是WCF的最忠实拥护者。要是有人问起：“我们可以支持这样的场景吗？”在90%的情况下Craig大概会这样回答：“哦，可以的，我上个星期就试过了，这是原型。”站在他的角度，他可以看到我们这些专注于具体功能特性的人所看不到的全貌。WCF能有今天，他直率的反馈、技术深度和热情功不可没。我相信他对WCF的热情和广博的知识会在每一个章节里闪光，我保证你会像我们一样，发现这是一本令人愉快的、有启发性的而且很有用的书。
Alex Weinert
微软公司团队项目经理