《WCF技术内幕》翻译2：《WCF技术内幕》绪论
绪论
总述
服务是现代软件架构的一个主要部分，WCF是构建基于Microsoft Windows系统的服务程序平台。WCF编写的服务可以与其它供应商的服务交互（例如， IBM, BEA, and Novell），WCF为行业标准的演化提供了足够的空间。对于传输，WCF支持TCP/IP、HTTP、 Microsoft消息队列 (MSMQ)、命名管道。WCF同样支持一系列WS-*规范（读作WS-星）协议，比如WS-Addressing, WS-ReliableMessaging (WS-RM), WS-AtomicTransaction (WS-AT), WS-Security, WS-SecureConversation, WS-Trust, 和WS-Federation。使用WCF的应用可以收发SOAP消息和朴素的旧XML消息。将来，微软会扩展WCF支持新的传输、协议、和消息结构。微软把WCF当做服务的IO系统。尽管将来无法确定，但是可以肯定地说
总述
服务是现代软件架构的一个主要部分，WCF是构建基于Microsoft Windows系统的服务程序平台。WCF编写的服务可以与其它供应商的服务交互（例如， IBM, BEA, and Novell），WCF为行业标准的演化提供了足够的空间。对于传输，WCF支持TCP/IP、HTTP、 Microsoft消息队列 (MSMQ)、命名管道。WCF同样支持一系列WS-*规范（读作WS-星）协议，比如WS-Addressing, WS-ReliableMessaging (WS-RM), WS-AtomicTransaction (WS-AT), WS-Security, WS-SecureConversation, WS-Trust, 和WS-Federation。使用WCF的应用可以收发SOAP消息和朴素的旧XML消息。将来，微软会扩展WCF支持新的传输、协议、和消息结构。微软把WCF当做服务的IO系统。尽管将来无法确定，但是可以肯定地说
在可预见的将来微软不会使用其它技术取代WCF。许多产品象微软BizTalk Server和 Windows Live Server都兼容了WCF就是很好的证明。
这本书的目标就是是读者具备使用WCF设计、开发、和维护服务必要的知识。在我看来，这些任务超出了单独的WCF编程模型。成功需要理解服务背后的原则、WCF服务编程模型、和WCF底层架构。
这本书的目标就是是读者具备使用WCF设计、开发、和维护服务必要的知识。在我看来，这些任务超出了单独的WCF编程模型。成功需要理解服务背后的原则、WCF服务编程模型、和WCF底层架构。
这种组织并不是新的理念；它来自于过去的经验。当面向对象变的流行以后，从面向过程到面向对象转变的开发者和架构师需要了解远不止编程语言的语法。如果面向过程的开发者在不了解面向对象情况下开始使用现代的编程语言，他们只能使用新语言来创建面向过程的应用。虽然这些代码可以编译和运行，但是他们不可能使用面向对象语言的许多特性。这个就是我关于不能体会面向服务的优势而去学习WCF开发者的看法。
有些人认为这种方法是在浪费时间。换句换说，WCF团队已经从正常的编程模型里成功抽象出消息底层架构，这样就没有必要去学习底层的面向服务的模式，或者WCF如何实现这些模式。我完全不认同这个观点。这种抽象可以使得WCF团队更快地开发。但是它绝对没有完全解放开发者和架构师转到面向服务和理解WCF内部如何工作的重任。成功的接受象C++或者JAVA面向对象语言需要开发者从面向过程到面向对象转变他们的思维，相同的是，WCF的学习者也需要从面向组件到面向服务去提升自己的认知。如果我们转变失败，我们将会遇到许多缺少面向服务特征的风险。简单编写WCF程序和编译、运行只是万里长征的一小步。从长远来看理解WCF技术内幕和理解新的编程模式同等重要。
虽然我们不理解面向服务架构的特征，但是我们应该知道WCF的底层架构。换句话说，我们应该了解我们的平台。通用语言运行时（CLR）对于这种情况提供了支持性的事实。CLR团队干的很漂亮，他们从开发者那里抽象出垃圾收集器和JIT编译器。结果，在不懂或者很少知道这些子系统如何工作的情况下，我们就可以写出Microsoft .NET Framework应用程序。比如，迁移到C#的C++开发者，在不知道垃圾收集器的情况下，会本能地为每个声明的类型增加一个finalizer 。不知不觉地，这个开发者就会增加分配的时间和这些对象的声明周期。对于大多数C++开发者来说，简单说一句“不要这样做”是不够的。他们想知道为什么。技术上来说，为一个类型增加一个finalizer不是个bug,单身它确实是许多书籍和培训课程耗费许多时间要强调的东西。
同理，知道WCF底层架构可以避免在WCF上浪费不必要的精力，并且开发者可以调整他们的程序功能去满足业务需求。例如，在构造函数里改变绑定的可靠消息参数可以动态地调节各个终结点之间的消息编排。WCF团队已经抽象去这些功能并部分通过绑定暴露出来。这种消息编排有时是必要的，并且只有理解消息编排的开发者才能正确决定何时使用这个特性。进一步讲，想调试一个使用可靠消息的程序就必须掌握可靠消息的配置。
我希望此书可以在面向服务的关键概念、WCF服务编程模型、和WCF底层架构之间取得平衡。本书将给你一个了解WCF技术内幕的严谨视野，你可以设计、构建、调试、维护可扩展和可靠的分布式应用。。
1.面向的读者：
这本书适合那些想学习如何设计、编写、或者测试WCF分布式应用的架构师、开发人员、和测试人员。本书的前面一些章节对想学习更多或者评估WCF的业务决策者也有帮助。这本书不适合初级开发者或刚学习.NET Framework编程的开发者。倘若如此，我推荐你在阅读本书之前先阅读Jeffrey Richter的CLR via C# (Microsoft Press, 2006)或者Jeff Prosise的Microsoft .NET 编程(Microsoft Press, 2002)。如果你是熟悉一些分布式应用开发的阅读者，将会有所帮助。但是不是必须的。
2.本书结构：
本书分为3部分。第一部分，“介绍WCF”，描述了面向服务应用的原则，介绍了主要的WCF子系统，并且描述了这些子系统之间如何交互。第一部分包括一个关于面向服务的章节，另外一个是关于消息的概念，最后一个是关于WCF架构。从高层次来说，WCF由两个基本的层组成：通道层和服务模型层。第二部分，WCF通道层和第三部分WCF服务模型层分别描述了通道层和服务模型层。第二部分开始一章描述了消息类型，然后是通道和通道管理器。第三部分章节涵盖绑定、契约、分发器和客户端。第二和第三部分的每个章节剖析了各自相关主题的重要类型。并且提供了例子代码去阐述这些知识。总体来说，本书带领读者由基本概念到WCF核心机制，然后是WCF主要的编程接口（API）。换句话说，这本书作了对WCF彻底的剖析。
3.例子代码和系统需求：
所有本书讨论的例子都可以在本书附录的网址里下载：
http://www.microsoft.com/mspress/companion/9780735623064
微软出版社在下列地址提供了书籍的后续支持服务：
http://www.microsoft.com/learning/support/books/
本书展示的代码是.NET Framework 3.0所写。安装.NET Framework 3.0及其需求在此网址：
有些人认为这种方法是在浪费时间。换句换说，WCF团队已经从正常的编程模型里成功抽象出消息底层架构，这样就没有必要去学习底层的面向服务的模式，或者WCF如何实现这些模式。我完全不认同这个观点。这种抽象可以使得WCF团队更快地开发。但是它绝对没有完全解放开发者和架构师转到面向服务和理解WCF内部如何工作的重任。成功的接受象C++或者JAVA面向对象语言需要开发者从面向过程到面向对象转变他们的思维，相同的是，WCF的学习者也需要从面向组件到面向服务去提升自己的认知。如果我们转变失败，我们将会遇到许多缺少面向服务特征的风险。简单编写WCF程序和编译、运行只是万里长征的一小步。从长远来看理解WCF技术内幕和理解新的编程模式同等重要。
虽然我们不理解面向服务架构的特征，但是我们应该知道WCF的底层架构。换句话说，我们应该了解我们的平台。通用语言运行时（CLR）对于这种情况提供了支持性的事实。CLR团队干的很漂亮，他们从开发者那里抽象出垃圾收集器和JIT编译器。结果，在不懂或者很少知道这些子系统如何工作的情况下，我们就可以写出Microsoft .NET Framework应用程序。比如，迁移到C#的C++开发者，在不知道垃圾收集器的情况下，会本能地为每个声明的类型增加一个finalizer 。不知不觉地，这个开发者就会增加分配的时间和这些对象的声明周期。对于大多数C++开发者来说，简单说一句“不要这样做”是不够的。他们想知道为什么。技术上来说，为一个类型增加一个finalizer不是个bug,单身它确实是许多书籍和培训课程耗费许多时间要强调的东西。
同理，知道WCF底层架构可以避免在WCF上浪费不必要的精力，并且开发者可以调整他们的程序功能去满足业务需求。例如，在构造函数里改变绑定的可靠消息参数可以动态地调节各个终结点之间的消息编排。WCF团队已经抽象去这些功能并部分通过绑定暴露出来。这种消息编排有时是必要的，并且只有理解消息编排的开发者才能正确决定何时使用这个特性。进一步讲，想调试一个使用可靠消息的程序就必须掌握可靠消息的配置。
我希望此书可以在面向服务的关键概念、WCF服务编程模型、和WCF底层架构之间取得平衡。本书将给你一个了解WCF技术内幕的严谨视野，你可以设计、构建、调试、维护可扩展和可靠的分布式应用。。
1.面向的读者：
这本书适合那些想学习如何设计、编写、或者测试WCF分布式应用的架构师、开发人员、和测试人员。本书的前面一些章节对想学习更多或者评估WCF的业务决策者也有帮助。这本书不适合初级开发者或刚学习.NET Framework编程的开发者。倘若如此，我推荐你在阅读本书之前先阅读Jeffrey Richter的CLR via C# (Microsoft Press, 2006)或者Jeff Prosise的Microsoft .NET 编程(Microsoft Press, 2002)。如果你是熟悉一些分布式应用开发的阅读者，将会有所帮助。但是不是必须的。
2.本书结构：
本书分为3部分。第一部分，“介绍WCF”，描述了面向服务应用的原则，介绍了主要的WCF子系统，并且描述了这些子系统之间如何交互。第一部分包括一个关于面向服务的章节，另外一个是关于消息的概念，最后一个是关于WCF架构。从高层次来说，WCF由两个基本的层组成：通道层和服务模型层。第二部分，WCF通道层和第三部分WCF服务模型层分别描述了通道层和服务模型层。第二部分开始一章描述了消息类型，然后是通道和通道管理器。第三部分章节涵盖绑定、契约、分发器和客户端。第二和第三部分的每个章节剖析了各自相关主题的重要类型。并且提供了例子代码去阐述这些知识。总体来说，本书带领读者由基本概念到WCF核心机制，然后是WCF主要的编程接口（API）。换句话说，这本书作了对WCF彻底的剖析。
3.例子代码和系统需求：
所有本书讨论的例子都可以在本书附录的网址里下载：
http://www.microsoft.com/mspress/companion/9780735623064
微软出版社在下列地址提供了书籍的后续支持服务：
http://www.microsoft.com/learning/support/books/
本书展示的代码是.NET Framework 3.0所写。安装.NET Framework 3.0及其需求在此网址：
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=10CC340B-F857-4A14-83F5-25634C3BF043
4.问题和评论：
如果你有任何关于此书的不能在前面网站解决的评论，问题，或想法，请通过EMail发送到微软出版社： mspinput@microsoft.com 或者通过信件直接与微软出版社《WCF技术内幕》的编辑：Redmond, WA 98052-6399。请注明哪个软件产品在之前的网站中未能提供支持服务。
4.问题和评论：
如果你有任何关于此书的不能在前面网站解决的评论，问题，或想法，请通过EMail发送到微软出版社： mspinput@microsoft.com 或者通过信件直接与微软出版社《WCF技术内幕》的编辑：Redmond, WA 98052-6399。请注明哪个软件产品在之前的网站中未能提供支持服务。
本文转自 frankxulei 51CTO博客，原文链接：http://blog.51cto.com/frankxulei/318648，如需转载请自行联系原作者
