序
序 (1)
前言 (8)
第1章WCF基础 (13)
什么是WCF (14)
服务 (15)
服务的执行边界 (16)
WCF与位置透明度 (17)
地址 (18)
TCP地址 (19)
HTTP地址 (20)
IPC地址 (20)
MSMQ地址 (20)
对等网地址 (21)
契约 (21)
服务契约（Service Contract） (21)
数据契约（Data Contract） (21)
错误契约（Fault Contract） (22)
消息契约（Message Contract） (22)
服务契约 (22)
应用ServiceContract特性 (25)
名称与命名空间 (28)
托管 (30)
IIS托管 (30)
使用Visual Studio 2005 (31)
Web.Config文件 (32)
自托管 (32)
使用Visual Studio 2005 (35)
自托管与基地址 (35)
托管的高级特性 (38)
ServiceHost
WAS托管 (41)
绑定 (41)
标准绑定 (42)
基本绑定（Basic Binding） (43)
TCP绑定 (43)
对等网绑定 (43)
IPC绑定 (43)
WS联邦绑定（Federated WS Binding） (44)
WS双向绑定（Duplex WS Binding） (44)
MSMQ绑定 (44)
格式与编码 (44)
选择绑定 (45)
使用绑定 (47)
终结点 (47)
管理方式配置终结点 (48)
绑定配置 (52)
编程方式配置终结点 (53)
绑定配置 (56)
元数据交换 (56)
编程方式启用元数据交换 (59)
元数据交换终结点 (62)
编程方式添加MEX终结点 (64)
简化ServiceHost
元数据浏览器 (71)
客户端编程 (71)
生成代理 (72)
管理方式配置客户端 (76)
绑定配置 (78)
生成客户端配置文件 (78)
进程内托管配置 (79)
SvcConfigEditor编辑器 (80)
创建和使用代理 (81)
关闭代理 (82)
调用超时 (84)
编程方式配置客户端 (85)
编程方式配置与管理方式配置 (86)
WCF体系架构 (87)
宿主体系架构 (88)
使用通道 (89)
InProcFactory
可靠性 (98)
绑定与可靠性 (99)
有序消息 (100)
配置可靠性 (100)
必备有序传递 (103)
第2章 服务契约 (107)
操作重载 (107)
契约的继承 (112)
例 2-3：服务端契约层级 (112)
客户端契约层级 (114)
恢复客户端层级 (116)
例2-6：代理链 (121)
服务契约的分解与设计 (123)
契约分解 (123)
分解准则 (127)
契约查询 (130)
编程处理元数据 (130)
MetadataHelper类 (135)
第6章错误 (144)
错误与异常 (145)
异常与实例管理 (146)
单调服务与异常 (146)
会话服务与异常 (146)
单例服务与异常 (146)
错误 (147)
错误与异常 (151)
对于分布式系统，或者说业界不断提及的互联系统的设计与构建，我与本书作者Juval L歸y可谓志同道合。我们经历了相似的技术历程，虽然我们效力于不同的公司，负责不同的项目，工作在不同的地方，但我们却有着共同的目标。
20世纪90年代早期，我们开始了对一种新技术理念的探索，即实现计算机之间的通信与交互。这种被称为分布式系统应用程序的平台技术也逐渐为世人所了解。随着工作站与服务器硬件的逐渐普及，经济因素不再成为制约发展的瓶颈，构建不依赖于单事务网络中心的大型系统就成为了技术热点。对于大范围的数据交换系统而言，同样如此。在过去，我的电话公司如果要求每秒钟传递超过1200位的数据几乎是不可能的，而在如今看来连这都达不到简直不可思议。在同样的线路上，今天的传输速度已经达到了6Mbit/s。这真是一个激动人心的时代啊。
随着分布式计算技术的逐渐成熟，在90年代早期分属两大阵营的大型分布式系统技术渐露峥嵘，即数字设备公司（最终被康柏兼并，并入惠普）主导的DCE技术，以及OMG组织（主要由IBM支持）倡导的CORBA技术。然而在1996~1997期间，所有这些杰出的工程学成果却突然停滞不前。因为此时是互联网的世界，整个世界都疯迷于HTML、HTTP、风险投资以及IPO（Initial Public Offerings，首次公开募股）。整个行业花费了整整10年的时间才逐渐从泡沫经济带来的崩溃中恢复过来。不仅是经济的复苏，技术的发展也重新走回正轨。随之获益的是分布式系统技术由此打破了过去由两大阵营各占半壁江山的局面，多达数十种新的分布式技术如雨后春笋一般展现在人们眼前，使我们拥有了更多的抉择权。直到2007年，整个行业仍然在为分布式系统的正确编码方式争论不休。Sun公司或者BEA 力主Java；而我在微软的同事（包括我）则坚定地主张C#或者Visual Basic才是最佳的实现方式。无论是Sun、BEA、IBM还是微软，都希望机器之间的通信标准能够达成一致。试想昔日的DCE与CORBA之争，正是因为达成了一致的标准规范才为如今的SOAP 1.1奠定了基础，从而开创了分布式技术的盛大场面。
自从SOAP 1.1作为技术说明（Technical Note）被提交给W3C，到现在已有超过6年的历史。期间，多家行业合作商共同开发与协定了众多基于SOAP的规范，从包括寻址以及众多安全选项的基础规范，到诸如原子事务协作的企业协议。我在微软的团队，仍然非正式地称呼我们的产品为“Indigo”，它代表了整个开发与协商过程中耗费的所有心血。如果没有IBM、微软以及其他合作伙伴对创建通用标准集的大力支持，在竞争如此激烈的企业领域几乎不可能存在开放标准的框架，更不可能具有支持多个开发商以及各种平台的多种实现。
诚然，WCF的实现超出了预计需要花费的时间。标准的协定耗费了大量时间，毕竟我们不能只顾着发布自己的软件（Windows Communication Foundation, WCF），而不考虑它与我们的行业合作伙伴以及竞争者之间的互操作性。设计同样如此，对于那些具有分布式系统开发经验的客户而言，他们花费了大量时间学习以及掌握了我们之前提供的分布式系统技术，包括https://www.doczj.com/doc/178839272.html,服务、Web服务增强（WSE）、.NET Remoting、消息传输/MSMQ 以及企业服务/COM+，我们在发布软件的同时必须考虑这些客户。
在我刚才引用的技术清单中，包含了五种技术。如果使用非托管代码，则还有更多的技术平台。WCF的其中一个最重要的设计目标就是通过简单的方式将这些技术集合起来，以一种方式进行编程。不管是构建一个队列应用程序、事务型的N层应用程序、P2P客户端、RSS 种子服务器，还是构建自己的企业服务总线，都不再需要掌握那些只能解决部分问题的多种技术。我们只需要学习和使用WCF即可。这就是以一种方式编程的魅力所在。
本书展示了大量微软已经构建好的技术细节，它们可以作为您的应用程序与服务的基础。在本书中，作者以享有盛誉的写作技巧，深入浅出而又准确细致地介绍了WCF的体系架构。作为微软互联框架团队成员的我们，也为自己构建的这一产品深感自豪。我们为开发者提供了一个统一的分布式技术体系架构，它具有广泛的互操作性，全面提升了面向服务的特性。同时它还是易于学习的，有利于提高构建面向服务应用程序的生产力。作为当今最杰出的分布式系统专家之一，Juval愿意倾尽心血全力介绍WCF，我们不禁深感荣幸。我们有足够的信心相信，Juval的著作能够帮助您理解人们为什么会对这一产品的问世以及它将创造的新的机遇而激动不已。这些人也包括我们、Juval以及早期的用户社区。享受本书，开始构建您的第一个WCF服务吧。
前言
2001年8月，我在微软首次了解到使用托管代码重写COM+的技术细节。随后一切如常，直到2002年7月，在对C#2.0作战略性设计评审期间，负责Remoting的程序经理提出了一个宏伟的计划，试图将Remoting重写为开发者真正能够使用的技术。同时，微软也在寻求合作，共同为ASMX中的Web服务制定全新的安全规范，起草一系列附加的Web 服务规格说明书。
到了2003年7月，我有机会体验了一个全新的事务型体系架构，它能够改善.NET编程中关于事务处理的相关缺陷。当时，并没有一个稳定的编程模型能够统一那些独立的技术。直到2003年末，我有幸获邀参加一个由同行专家组成的小型团队，对代号为Indigo的开发平台进行战略性的设计评审。就我所知，这个开发团队可谓人才济济，汇聚了许多世界上最优秀的天才。在接下来的2~3年时间内，Indigo一共经历了三代编程模型版本的演变。就在2005年早期发布了基于终结点驱动对象模型的版本之后，终于在当年8月逐渐稳定为一个固定的版本，同时更名为Windows Communication Foundation（WCF）。要想得到开发者的众口称赞，可谓难于上青天，然而WCF却给了我们不同的诠释。对于Web服务的开发者而言，WCF就是最终的应对互操作性的解决方案，实现了大多数行业标准。分布式应用程序的开发者则认为它简化了远程调用以及队列调用。系统开发者认为它具备下一代面向产品的特征，诸如事务与宿主，为应用程序提供了现成的基础功能模块。至于应用程序的开发者，WCF则为他们构建应用程序提供了声明式的编程模型。而对于架构师，WCF则是构建面向服务应用程序的最终选择。一言以敝之，WCF涵盖了以上所有的一切，因为设计WCF的目的就是为了能够统一微软的下一代全新的技术。
对我而言，WCF就是下一代开发者平台，它在很大程度上包容了最初的.NET编程理念。任何.NET开发者都可以使用WCF，而不用考虑应用程序的类型、规模或者行业领域。WCF 是一门基础技术，它提供了生成服务与应用程序的“终南捷径”，完全符合我所认同的良好的设计准则。WCF从一开始就是工程化的，能够简化应用程序的开发与部署，降低开发成本。WCF服务用于构建面向服务的应用程序，不管这些程序是独立的桌面应用程序，还是Web应用程序和服务，还是高端的企业应用程序。
本书的结构
本书涵盖了所有设计开发基于WCF的面向服务应用程序所需的知识与技能。通过本书，你可以看到如何利用WCF内建的特性，例如服务托管、实例管理、并发管理、事务、离线队列调用以及安全。本书会为你展示如何使用这些特性并探究它们在这种特定的设计思路下的实现原理。你不仅能够了解到WCF编程技术，以及相关的系统知识，同时还包括了相应的设计方案、诀窍、最佳实践以及存在的缺陷。我之所以站在软件工程的立场阐述本书的每个主题与特征，是因为我期望它能够帮助读者不仅要成为一名WCF专家，而且还要成为一名优秀的软件工程师。本书带给您的这种认知能够使你如虎添翼，让你的应用程序在可维护性、可扩展性、可重用性以及高效性方面，更加符合软件工程的理念。
本书回避了许多WCF的实现细节，更多的是注重使用WCF的实用性与可行性：如何应用WCF技术？如何选择可行的设计原则与编程模型？本书大量使用了.NET 2.0技术，从某种角度来说，本书也可以算是一本高级的C#技术书籍。除此之外，本书包含了大量我所编写的套件类、工具类以及辅助类。这些内容可以提高你的开发效率，保障开发的WCF服务的质量。我还开发了一个基于WCF技术的小型框架，用以弥补一些设计缺陷，或者简化确切
的任务，使其能够自动化实现。在书中，我像介绍WCF技术那样，详细地介绍了这些工具、理念与技术。同时，我开发的框架则为你演示了如何对WCF进行扩展。
在过去的两年中，我在MSDN杂志上发表了大量关于WCF的文章。目前，我还在为杂志的基础专栏（Foundations Column）撰写WCF技术文章。我要感谢杂志社能够允许我将这些文章收录到本书中。如果你曾经阅读过这些文章，或许能够从本书的相关章节中发现它们的影子。比较而言，本书的章节更加全面，提供了WCF的多种视角、技术与实例，而且这些主题也与书中的其他章节紧密相连。
我在每一章中都系统地讲解了一个专题，深入探讨了这些专题的内容。然而，每一章又都依赖于前一章的内容，因此，我建议你最好按照先后顺序阅读本书。
以下是书中各章节以及附录的摘要。
第1章，WCF基础
该章首先阐释了WCF的技术原理，并描述了WCF的基础概念和构建模块，例如地址、契约、绑定、终结点、托管以及客户端。在该章最后还讨论了WCF体系架构，它将是帮助我们理解后面章节的关键。该章假定读者已经了解面向服务的思想与优势。如果你不具备这方面的知识，可以首先阅读附录A的内容。即使你已经熟悉了WCF的基础概念，我仍然建议你至少能够快速地浏览该章的内容，它不仅能够巩固你已有的知识，更在于该章介绍的一些辅助类与技术术语有助于阅读全书。
第2章，服务契约
该章致力于介绍服务契约的设计与开发。首先，你会了解到一些有用的技术，包括服务契约的重载与继承以及其他高级技术。然后，该章深入探讨了如何设计以及分解契约，以利于服
务的重用、可维护性以及可扩展性。最后，展示如何通过公开契约元数据完成运行时的交互编程。
第3章，数据契约
如果没有实际存在的可共享的数据类型本身，如果没有使用相同的开发技术，应该如何处理客户端与服务之间的数据交换？在该章，你可以看到如何处理某些有趣的现实问题，例如数据版本控制，以及传递元素项集合的方式。
第4章，实例管理
究竟是哪一种服务实例处理哪一种客户端的请求？该章给出了问题之钥。WCF支持多种服务实例管理、激活以及生命周期管理技术，这些技术与系统规模和性能息息相关。该章给出了每一种实例管理模式之间的关系，指导读者何时以及如何有效地使用它们。该章还介绍与之相关的主题，例如限流。
第5章，操作
随着对各种类型操作的处理，客户端能够调用服务，遵循相关的设计原则，例如如何改善和扩展基础功能，以支持回调的安装与销毁，管理回调端口与通道，提供类型安全的双向代理。第6章，错误
该章全面介绍了服务将错误与异常返回给客户端的方式，毕竟，诸如异常与异常处理的构建都是一门特定的技术，无法穿越服务边界。该章介绍了错误处理的最佳实践，使开发者能够解除客户端错误处理与服务的耦合度。该章还演示了如何扩展以及改善WCF基础的错误处理机制。
第7章，事务
首先，该章从整体上介绍了使用事务的目的，然后讨论了事务服务的众多特征：事务管理架构、事务传播配置、WCF提供的声明性事务支持，以及客户端创建事务的方式。最后，该
章讨论了与事务相关的设计原则，例如事务服务状态管理与实例模式。
第8章，并发管理
WCF提供了一种强大而简单的声明方式，用来管理客户端与服务的并发与同步。该章展现了诸多高级技术，例如回调、重入、线程关联度、同步上下文以及避免死锁的最佳实践与原则。
第9章，队列服务
该章描述了客户端如何通过队列调用服务，从而支持异步与离线工作。该章首先介绍如何创建与配置队列服务，然后，重点讲解诸如事务、实例管理、故障以及它们对服务业务模型与实现造成的影响。
第10章，安全
通过将多个方面的任务分解为一些基本的要素，如消息传递、认证和授权，就可以揭开面向服务安全神秘的面纱。该章演示了如何为局域网和互联网应用程序等关键场景提供安全保障。最后，你可以看到我为声明式的WCF安全所编写的框架，设计为自动实现安全的设置，从而极大地简化对安全的管理。
附录A，面向服务概述
附录A为那些希望了解面向服务的读者提供，介绍了我在面向服务的具体应用。附录定义了面向服务应用程序（而非通常所谓的架构）以及服务自身，检验了它在方法学方面的优势。附录还给出了面向服务的原则，通过大多数应用程序所需要的实用要点，强化了面向服务的抽象原则。
附录B，服务发布与订阅
附录B展现了我定义的框架，它实现了发布-订阅事件管理的解决方案。框架可以使你只需要编写一两行代码就能发布和订阅服务。发布-订阅模式属于第5章的内容，之所以将它放
入到附录中，是因为它使用了其他章节的内容，例如事务与队列调用。
附录C，WCF编码规范
基本上，附录C涵盖了全书提及的甚至于没有提及的最佳实践。规范在于阐释应该“如何做”以及“怎么做”，而不阐明其原因。隐藏在规范之中的基础原理可以在本书的其余部分找到。该规范同时还使用了本书讨论的辅助类。
对于读者的要求
本书假定读者是一名经验丰富的开发者，熟悉诸如封装与继承等面向对象的概念。我会利用读者现有的对对象和组件技术以及术语的认知，巩固对WCF知识的了解。读者应该对于.NET以及C# 2.0的基础知识（包括泛型与匿名方法）有着清晰的了解。虽然本书大部分内容使用的是C#语言，然而对于Visual Basic 2005的开发者而言，仍然具有参考价值。 怎样使用本书
若要使用本书，需要安装.NET 2.0、Visual Studio 2005、.NET 3.0的发布组件，以及.NET 3.0开发的SDK和Visual Studio 2005的.NET 3.0扩展版。除非特别提示，本书适用的操作系统包括Windows XP、Windows Server 2003和Windows Vista。同时，你还需要安装一些附加的Windows组件，如MSMQ和IIS。
第1章WCF基础
本章主要介绍WCF的基本概念、构建模块以及WCF体系架构，以指导读者构建一个简单的WCF服务。从本章的内容中，我们可以了解到WCF的基本术语，包括地址（Address）、绑定（Binding）、契约（Contract）和终结点（Endpoint）；了解如何托管服务，如何编写客户端代码；了解WCF的相关主题，诸如进程内托管（In-Proc Hosting）以及可靠
性的实现。即使你已经熟知WCF的基本概念，仍然建议你快速浏览本章的内容，它不仅能够巩固你的已有知识，而且本章介绍的一些辅助类与技术术语也将有助于你阅读全书。
什么是WCF
Windows通信基础（Windows Communication Foundation，WCF）是基于Windows 平台下开发和部署服务的软件开发包（Software Development Kit，SDK）。WCF为服务提供了运行时环境（Runtime Environment），使得开发者能够将CLR类型公开为服务，又能够以CLR类型的方式使用服务。理论上讲，创建服务并不一定需要WCF，但实际上，使用WCF却可以使得创建服务的任务事半功倍。WCF是微软对一系列产业标准定义的实现，包括服务交互、类型转换、封送（Marshaling）以及各种协议的管理。
正因为如此，WCF才能够提供服务之间的互操作性。WCF还为开发者提供了大多数应用程序都需要的基础功能模块，提高了开发者的效率。WCF的第一个版本为服务开发提供了许多有用的功能，包括托管（Hosting）、服务实例管理（Service Instance Management）、异步调用、可靠性、事务管理、离线队列调用（Disconnected Queued Call）以及安全性。同时，WCF还提供了设计优雅的可扩展模型，使开发人员能够丰富它的基础功能。事实上，WCF自身的实现正是利用了这样一种可扩展模型。本书的其余章节会专注于介绍这诸多方面的内容与特征。WCF的大部分功能都包含在一个单独的程序集System.ServiceModel.dll 中，命名空间为System.ServiceModel。
WCF是.NET 3.0的一部分，同时需要.NET 2.0的支持，因此它只能运行在支持它的操作系统上。目前，这些操作系统包括Windows Vista（客户端和服务器）、Windows XP SP2和Windows Server 2003 SP1以及更新的版本。
服务
服务（Services）是公开的一组功能的集合。从软件设计的角度考虑，软件设计思想经历了从函数发展到对象，从对象发展到组件，再从组件发展到服务的几次变迁。在这样一个漫长的发展旅程中，最后发展到服务的一步可以说是最具革新意义的一次飞跃。面向服务（Service-Orientation，SO）是一组原则的抽象，是创建面向服务应用程序的最佳实践。如果你不熟悉面向服务的原则，可以参见附录A，它介绍了使用面向服务的概况与目的。本书假定你对这些原则已经了然于胸。一个面向服务应用程序（SOA）将众多服务聚集到单个逻辑的应用程序中，这就类似于面向组件的应用程序聚合组件，或者面向对象的应用程序聚合对象，如图1-1所示。
图1-1：面向服务应用程序
服务可以是本地的，也可以是远程的，可以由多个参与方使用任意技术进行开发。服务与版本无关，甚至可以在不同的时区同时执行。服务内部包含了诸如语言、技术、平台、版本与框架等诸多概念，而服务之间的交互，则只允许指定的通信模式。
服务的客户端只是使用服务功能的一方。理论上讲，客户端可以是任意的Windows窗体类、https://www.doczj.com/doc/178839272.html,页面或其他服务。
客户端与服务通过消息的发送与接收进行交互。消息可以直接在客户端与服务之间进行传递，也可以通过中间方进行传递。WCF中的所有消息均为SOAP消息。注意WCF的消息与传输协议无关，这与Web服务不同。因此，WCF服务可以在不同的协议之间传输，而不仅限于HTTP。WCF客户端可以与非WCF服务完成互操作，而WCF服务也可以与非WCF客户端交互。不过，如果需要同时开发客户端与服务，则创建的应用程序两端都要求支持WCF，这样才能利用WCF的特定优势。
因为服务的创建对于外界而言是不透明的，所以WCF服务通常通过公开元数据（Metadata）的方式描述可用的功能以及服务可能采用的通信方式。元数据的发布可以预先定义，它与具体的技术无关（Technology-Neutral），例如采用基于HTTP-GET方式的WSDL，或者符合元数据交换的行业标准。一个非WCF客户端可以将元数据作为本地类型导入到本地环境中。相似的，WCF客户端也可以导入非WCF服务的元数据，然后以本地CLR类与接口的方式进行调用。
服务的执行边界
WCF不允许客户端直接与服务交互，即使它调用的是本地机器内存中的服务。相反，客户端总是使用代理（Proxy）将调用转发给服务。代理公开的操作与服务相同，同时还增加了一些管理代理的方法。
WCF允许客户端跨越执行边界与服务通信。在同一台机器中（参见图1-2），客户端可以调用同一个应用程序域中的服务，也可以在同一进程中跨应用程序域调用，甚至跨进程调用。
图1-2：使用WCF实现相同机器通信
图1-3则展示了跨机器边界的通信方式，客户端可以跨越Intranet或Internet的边界与服务交互。
图1-3：使用WCF实现不同机器通信
WCF与位置透明度
过去，诸如DCOM或.NET Remoting等分布式计算技术，不管对象是本地还是远程，都期望为客户端提供相同的编程模型。本地调用时，客户端使用直接引用；处理远程对象时，则使用代理。因为位置的不同而采用两种不同的编程模型会导致一个问题，就是远程调用远比本地调用复杂。复杂度体现在生命周期管理、可靠性、状态管理、可伸缩性（scalability）以及安全性等诸多方面。由于远程对象并不具备本地对象的特征，而编程模型却力图让它成
为本地对象，反而使得远程编程模型过于复杂。WCF同样要求客户端保持一致的编程模型，而不用考虑服务的位置。但它的实现途径却大相径庭：即使对象是本地的，WCF仍然使用远程编程模型的实例化方式，并使用代理。由于所有的交互操作都经由代理完成，要求相同的配置与托管方式，因而对于本地和远程方式而言，WCF都只需要维持相同的编程模型。这就使得开发者不会因为服务位置的改变影响客户端，同时还大大地简化了应用程序的编程模型。
地址
WCF的每一个服务都具有一个唯一的地址（Addresses）。地址包含两个重要元素：服务位置与传输协议（Transport Protocol），或者是用于服务通信的传输样式（Transport Schema）。服务位置包括目标机器名、站点或网络、通信端口、管道或队列，以及一个可选的特定路径或者URI。URI即统一资源标识（Universal Resource Identifier），它可以是任意的唯一标识的字符串，例如服务名称或GUID。
WCF 1.0支持下列传输样式：
?HTTP
?TCP
?Peer network（对等网）
?IPC（基于命名管道的内部进程通信）
?MSMQ
地址通常采用如下格式：[基地址]/[可选的URI]
基地址（Base Address）通常的格式如下：[传输协议]://[机器名或域名][:可选端口]
下面是一些地址的示例：
http://localhost:8001
http://localhost:8001/MyService
net.tcp://localhost:8002/MyService
net.pipe://localhost/MyPipe
net.msmq://localhost/private/MyService
net.msmq://localhost/MyService
可以将地址http://localhost:8001读作：“采用HTTP协议访问localhost机器，并在8001端口等待用户的调用。”
如果URI为http://localhost:8001/MyService，则读作：“采用HTTP协议访问localhost 机器，MyService服务在8001端口处等待用户的调用。”
TCP地址
TCP地址采用net.tcp协议进行传输，通常它还包括端口号，例如：
net.tcp://localhost:8002/MyService
如果没有指定端口号，则TCP地址的默认端口号为808：
net.tcp://localhost/MyService
两个TCP地址（来自于相同的宿主，具体内容将在本章后面介绍）可以共享一个端口： net.tcp://localhost:8002/MyService
net.tcp://localhost:8002/MyOtherService
本书广泛地使用了基于TCP协议的地址。
注意：我们可以将不同宿主的TCP地址配置为共享一个端口。
HTTP地址
HTTP地址使用http协议进行传输，也可以利用https进行安全传输。HTTP地址通常会被用作对外的基于Internet的服务，并为其指定端口号，例如：
http://localhost:8001
如果没有指定端口号，则默认为80。与TCP地址相似，两个相同宿主的HTTP地址可以共享一个端口，甚至相同的机器。
本书广泛地使用了基于HTTP协议的地址。
IPC地址
IPC地址使用net.pipe进行传输，这意味着它将使用Windows的命名管道机制。在WCF 中，使用命名管道的服务只能接收来自同一台机器的调用。因此，在使用时必须指定明确的本地机器名或者直接命名为localhost，为管道名提供一个唯一的标识字符串：
net.pipe://localhost/MyPipe
每台机器只能打开一个命名管道，因此，两个命名管道地址在同一台机器上不能共享一个管道名。
本书广泛地使用了基于IPC的地址。
MSMQ地址
MSMQ地址使用net.msmq进行传输，即使用了微软消息队列（Microsoft Message
跟我一起从零开始学WCF(1)
WCF概述
徐长龙 MSDN 特邀讲师 vsts_china@https://www.doczj.com/doc/178839272.html,
加速企业解决方案部署尽在
资源和利益
? 用于解决方案开发的集中资源 用于解决方案开发的集中资源：资源包括指向测试工具、开发 资源包括指向测试工具 开发 人员 SDK、技术论坛、联机培训等的链接，微软全球技术支持 中心( (GTSC) )的邮件技术支持。 ? 对市场调查的访问权限：您可以使用这些宝贵信息来识别您当 前的客户或未来客户的特定需求。 ? 认证徽标计划：该徽标可以向客户证明您所具有的优秀技术。 ? 市场营销和销售支持
https://www.doczj.com/doc/178839272.html, h O
Metro – ISV领航计划
最先应用微软最新技术 提升ISV 提升 ISV竞争优势和商业价值 竞争优势和商业价值
? Metro 提供了结构化的支持来帮助ISV进行新技术的评估和 部署 部署： Discover – 参与前沿技术培训 – 评估最新的微软技术及产品 Release Learn – 获取微软Beta版产品的技术支持 – 联络全球开发人员和架构师社区 – 与世界级的商务和技术社区分享最先 Develop 部署的经验
收听本次课程需具备的条件
? 熟悉Web Service编程 ? 熟悉Visual Studio 2005/2008 ? 熟悉分布式应用程序开发
Level 200
本次课程内容包括 ? 什么是WCF? ? WCF背景介绍
序 序 (1) 前言 (8) 第1章WCF基础 (13) 什么是WCF (14) 服务 (15) 服务的执行边界 (16) WCF与位置透明度 (17) 地址 (18) TCP地址 (19) HTTP地址 (20) IPC地址 (20) MSMQ地址 (20) 对等网地址 (21) 契约 (21) 服务契约（Service Contract） (21) 数据契约（Data Contract） (21) 错误契约（Fault Contract） (22) 消息契约（Message Contract） (22) 服务契约 (22) 应用ServiceContract特性 (25)
名称与命名空间 (28) 托管 (30) IIS托管 (30) 使用Visual Studio 2005 (31) Web.Config文件 (32) 自托管 (32) 使用Visual Studio 2005 (35) 自托管与基地址 (35) 托管的高级特性 (38) ServiceHost
使用绑定 (47) 终结点 (47) 管理方式配置终结点 (48) 绑定配置 (52) 编程方式配置终结点 (53) 绑定配置 (56) 元数据交换 (56) 编程方式启用元数据交换 (59) 元数据交换终结点 (62) 编程方式添加MEX终结点 (64) 简化ServiceHost
8.2Hello, World实例 本实例与传统入门教材相同，仍然以输出一个“Hello，World”字符串开始。实例将新建2个项目，第一个项目名为“HelloWorldService”，它提供WCF服务，并且以开发环境方式暴露一个端口供客户端调用；另外一个项目叫“HelloWorldClient”，它调用WCF服务方法，并输出返回值。 本实例的运行结果如图所示： 8.2.1创建WCF服务端程序 1）打开Microsoft Visual Studio 2010； 2）选择菜单>文件>新建>项目； 3）在弹出的“新建项目”对话框中展开左边的“已安装的模板”>Visual C#； 4）选择“WCF”； 5）在对话框右边选择“WCF Service Application“； 6）在对话框下部的“项目名“中输入”HelloWorldService“，在位置中输入” d:\Exercise “，在解决方案名称输入”WcfSample“，确保选中”Create directory for solution “，确保未选中”Add to source control“，设置后的界面如下：
7）点击“OK“按钮，VS2010已自动建立了一个WCF Service Application，并且为我们自动打开了Service1.svc.cs文件； 8）打开“Solution Explorer”；（VS2010默认打开，位置在VS2010桌面的右边，如果VS2010没有打开，请使用快捷键Ctrl + W，S打开） 9）在“Solution Explorer”中展开“HelloWorldService”； 10）双击“IService1.cs”文件； 11）用下面的代码 ///
七步通使用WCF Service流程 Service对于编程人来说并不陌生，学习了很长时间的WCF，我们现在就WCF Service 一起来和大家分析探讨一下。熟悉Web Service开发的程序员对添加服务引用应该并不陌生。在创建某个服务的客户端程序时，并不需要从头开始编写客户端的底层通信和交互代码，可以通过输入服务地址来添加服务来让Visual Studio生成客户端代理，这样访问服务就像访问本地组件一样，而不需要去关心通信的细节。 如果创建的客户端程序项目和服务程序项目处在同一个解决方案里（很多开发者在开发服务时，也会同步开发客户端程序），还可以通过Visual Studio来帮助我们“发现（Discovery）”服务，并添加服务引用。现在开发WCF Service的程序员也可以得益于这些功能了。如果从WCF Service Library (或者WCF 节点下的Sequential Workflow Service Library 和 State Machine Workflow) 项目模板创建一个项目，那么这些功能就已经具备。 下面我们来看一下如何使用： 1.创建一个客户端程序，可以是一个Windows Console程序。 2.在同一解决方案里添加一个WCF Service Library。如图： 3.Build WcfServiceLibrary1。 4.右键ConsoleApplication1，在上下文菜单中选择“添加服务引用“(Add Service Reference). 5.此时可以看到一个对话框:
6.如果已经知道服务的地址，可以直接在Address栏输入地址来添加服务，单击“Go”。可以找到这个地址对应的服务。 7.如果想添加同一个解决方案里的服务，可以先单击“发现”来寻找服务。找到服务后，选中需要在客户端程序生成引用的服务，然后单击确定，这个时候WcfSvcHost就会自动启动来HOST服务。几秒以后，可以看到客户端自动生成了服务代理代码： 通过上面的步骤在客户端完成了添加服务引用，现在可以访问服务了，只需要通过下面两行代码就可以调用服务端的一个方法： 1.ServiceReference1.Service1Client client = new ServiceReference1.Serv ice1Client(); 2.client.GetData(0);
Win7下使用IIS托管WCF服务 第一步，确保Win7正确安装了IIS。 操作步骤： 1.打开控制面板-程序和功能-点击左侧“打开或关闭Windows功能”，在弹出框中选中 “Internet信息服务”，需要注意的是有的需要将其展开，选中相关项。 2.在浏览器中输入http://localhost，如果出现了IIS启动界面，即表示IIS安装成功。 第二步，在进行IIS托管WCF服务之前，先建立一个https://www.doczj.com/doc/178839272.html,程序试下。 由于Win7+VS2010使用的是.Net 4.0，所以需要确保注册了https://www.doczj.com/doc/178839272.html, 4.0。 操作步骤： 1.进入C:\Windows\System32找到cmd.exe，右键“以管理员身份运行”，然后在控制台输 入：cd C:\Windows\https://www.doczj.com/doc/178839272.html,\Framework\v4.0.30319切换到该目录 2.然后输入：aspnet_regiis.exe –i，就会看到正在注册，以及注册成功的提示信息。 备注：最好使用控制台来进行https://www.doczj.com/doc/178839272.html,的注册，其实也可以直接以管理员身份运行aspnet_regiis.exe，但是会看不到是否成功的提示！ 第三步：创建解决方案，并发布https://www.doczj.com/doc/178839272.html,网站 操作步骤： 1.创建一个默认的https://www.doczj.com/doc/178839272.html,网站，不用更改其中任何东西。 2.在项目上，右键“属性页”，在“启动选项”中的“特定页”和服务器，进行如下设置： 需要注意的是，这时如果你在项目上右键-在浏览器中查看，会发现不能访问。 3.鼠标右键-发布网站，出现如下图所示对话框：
点击“目标位置”进入如图对话框： 选择“文件系统”，即表示你要将你的网站发布到的本地计算机的位置，在第四步建立网站的时候会引用。 备注：由于，我们没有修改代码，应该发布会很顺利。
作者: 风尘浪子来源: 博客园发布时间: 2011-04-12 11:07 阅读: 3121 次原文链接全屏阅读 [收藏] SOA本身就是一种面向企业级服务的系统架构，简单来说，SOA就是一种进行系统开发的新的体系架构，在基于SOA架构的系统中，具体应用程序的功能是由一些松耦合并且具有统一接口定义方式的组件（也就是service）组合构建起来的。因此，基于SOA的架构也一定是从企业的具体需求开始构建的。但是，SOA和其它企业架构的不同之处就在于SOA提供的业务灵活性。业务灵活性是指企业能对业务变更快速和有效地进行响应、并且利用业务变更来得到竞争优势的能力。对企业级架构设计师来说，创建一个业务灵活的架构意味着创建一个可以满足当前还未知的业务需求的IT架构。使用WCF实现SOA，正好可以利用WCF的灵活性，把业务层封装，发布为Web服务。这样可以降低系统的耦合度，加大对未知业务的扩展性。
Web服务本来就是没有区分代码的，在这个例子里在下多开发了一个Service Interface目的是为了使系统更易于管理。在开发期间，Service是不断更改的，如果在UI层上直接调用服务层，那更改将会是频密的，所以在这里在下开发一个Service Interface层目的是为了把WSDL集成在同一个DLL程序集里面，进行统一修改。最后UI层只要直接调用Service Interface，就可以对系统直接进行操作。要以不同开发工具来实现Service Interface，这个的代价并不大，开销是可以承担的。下面附上最简单的例子，希望有经验的高手给予点评，有不妥的地方请多加指教。
本文和大家讲下WCF服务如何获取客户端在线用户数量？你没有关注过这个问题吧，一起来看下本文的实现方法。【1】问题分析: 这个问题，在WCF服务编程中也非常的常见，以下是对于这个问题的不同描述形式，但是本质基本类似：WCF如何获取在线客户端数量？ WCF如何获取在线用户列表？ WCF服务如何知道客户端离线？ 如何判断WCF离线客户端？ 或许还有别的提法，但是基本都是差不多的。 此类问题出现在回调、双工通信的场景中比较多，有的程序具备类似聊天室的功能，就比较在乎客户端的离线事件。 【2】解决办法: 这里服务端对于客户端在线的判断，也是固定的，基本是基于对通道状态的判断，来实现对于客户端在线状态的判断。 实现的思路基本就是，在服务端维护一个在线客户端Channel的列表List，然后每次通道关闭（Closed）或者出错（Faulted）调用特定的方法来移调通道。 这里另外一个需要注意的地方就是多线程并发的问题。 因为在线用户通道list是一个静态变量，多线程访问的时候，需要注意互斥操作的问题。 【3】示例代码： 这里的代码页比较简单，基本思路： //回调通道列表，也可以用来保持 private static List
使用VS自带的WCFSVCHost(WCF服务主机)发布WCF服务，时刻开发人员测试使用。下面我们来看一下如何在IIS中部发布一个WCF服务。 环境是VS 2008 （公司电脑没有安装VS2010）^_^ 我们从头开始，不写代码，完全的配置，会收获不小。 新建一个WCF 服务库 建立一个WCF服务应用程序
结果如下 删除掉WCF程序中不需要的默认文件，如下图
为WcfService1项目添加WcfServiceLibrary1的引用，如下图。 修改声明指示内容，让这个Service.svc文件的后台代码指向我们创建的WCF服务库项目--WcfServiceLibrary1项目中的服务类，改后的代码如下： <%@ ServiceHost Language="C#" Debug="true" Service="WcfServiceLibrary1.Service1" %> Ctrl+Shift+B 编译一下解决方案，配置工具用的反射，先编译才行 此时我们的WCF服务站点并不能把WCF服务库中的服务和终结点发布出来，还需要我们对web.config进行一系列的配置工作。 右键我们要配置的Web.Config文件,编辑WCF配置
在弹出的服务配置窗口中，把Service1服务指定到WCF服务库的WcfServiceLibrary1.dll 中的WcfServiceLibrary1.Service1服务类上。
再把其中的一个对外终结点的Contract设为WCF服务库的WcfServiceLibrary1.dll中的WcfServiceLibrary1.IService1服务契约上。
一、开发环境 操作系统：Windows 7 开发环境：VS2013 编程语言：C# IIS版本：10.0.0.0 二、添加WCF服务、Internet Information Services(IIS) 1、进入“控制面板”，打开“程序和功能”，点击左上角的“启用或关闭Windows功能”后，在“.NET Framework 4.6 高级服务”中的子节点选中“WCF 服务”，如下图所示： 2、再找到“Internet Information Services”，同样选中该节点，如下图所示：
3、点击“确定”按钮以便安装这些服务与组件，等待完成安装即可。 三、新建一个WCF服务库 1、使用VS2015新建一个WCF服务库，并将项目名称改为“MyWCFService”，如下图所示： 3、将鼠标移到解决方案资源管理器中项目“MyWCFService”上并右击鼠标，弹出上下文菜单，在菜单中选中“发布”后，弹出下图所示的“发布WCF服务”对话框，如下图所示： 在目标位置选择“D:\WCF”，其他按默认，点击“发布”按钮，即可在“D:\WCF”文件夹里生成
如下图所示的文件： 四、新建一个WCF服务网站 1、打开控制面板-管理工具
2.点击打开IIS，右键点击网站，新建一个网站，网站名称设置为“MyWCFService”，物理地址选择“D:\WCF”，端口从默认的80改为81，如下图所示：
3点击确定后，即新建一个WCF服务网站。 五、服务器程序编辑（编辑完成后需要再次发布） 1、点击解决方案下的server1.Cs—GeteData 2、在此处添加程序 六、创建客户端 1、新建一个Windows窗口客户端 2、在解决方案下的引用点击右键，添加服务器引用
WCF客户端动态设置WCF服务器主机的地址的方法参考，可以连接多个相同WCF主机的方法 最近做一个项目，需要在客户端灵活配置连接到哪个服务器的功能，例如客户端是一个，现在想连接A服务器就连A服务器，想连接B服务器就连接B服务器，当然不需要手动修改配置文件，直接通过程序来实现WCF目标主机的配置功能。 参考核心代码如下： //-------------------------------------------------------------------- // All Rights Reserved , Copyright (C) 2011 , Hairihan TECH, Ltd. //-------------------------------------------------------------------- using System.ServiceModel; namespace DotNet.WCFClient { using DotNet.IService; using DotNet.Utilities; ///
///修改纪录 /// /// 2011.07.03 版本：2.0 JiRiGaLa 可以动态指定服务器地址的调用方法。 /// 2009.09.20 版本：1.0 JiRiGaLa 创建。 /// ///版本：2.0 /// ///
WCF教程系列(1)-创建第一个WCF程序 作为微软技术.net 3.5的三大核心技术之一的WCF虽然没有WPF美丽的外观 但是它却是我们开发分布式程序的利器 但是目前关于WCF方面的资料相当稀少 希望我的这一系列文章可以帮助大家尽快入门 下面先介绍一下我的开发环境吧 操作系统：windows vista business版本 编译器：Visual Studio 2008(英文专业版) WCF的三大核心是ABC 也就是A代表Address-where（对象在哪里） B代表Binding-how（通过什么协议取得对象） C代表Contact（契约）-what（定义的对象是什么，如何操纵） 其他的理论知识大家可以参见《Programming WCF Service》 或者今年3月份刚刚出版的《Essential Windows Commmunication Foundation》 现在用In Action的方式来手把手教大家创建第一个WCF程序
首先如下图所示创建一个空的解决方案 接下来右键点击解决方案HelloWCF选择Add->New Project并选择Console Application模板并选择名为项目名为Host（服务器端）
接下来右键点击Host项目选择Add->New Item并选择Webservice模板（文件命名为HelloWCFService） 将创建三个文件IHelloWCFService.cs,HelloWCFService.cs以及 App.config文件 IHelloWCFService.cs代码如下 using System.ServiceModel; namespace Host { [ServiceContract] public interface IHelloWCFService
导语： 前一段时间开始学习WCF，尽管MSDN和网上的资料很多，但是由于刚开始接触WCF 且学习资料不够详尽，所以弄的一头雾水，不知其中所表达的思想，经过这段时间的学习，终于搞明白了WCF常用的宿主。现在把学习到的知识记录下来，供以后参考，也希望能为WCF初学者带来一些帮助。 步骤： 一、定义消息 消息的语义是指：服务中使用的数据对象。 创建类库项目WCFMessage：开始-程序-Microsoft Visual Studio 2010-Microsoft Visual Studio 2010-文件-新建-项目-VisualC#-Windows-类库，解决方案名称：WCFHost，名称：WCFMessage。 引入新的类库：System.Runtime.Serialization.dll 创建类Person：删除项目自动生成的Class1.cs，新建一个Person类，代码如下： using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Runtime.Serialization; namespace WCFMessage { [DataContract] public class Person { [DataMember] public string Id; [DataMember] public string Name; [DataMember] public int Age; } } 二、定义服务协定 服务协定的语义是指：定义服务的接口。
WCF 服务编程（第三版）学习笔记 一、第一章WCF基础 (一)什么是WCF（What Is WCF?） WCF（之前的版本名为“Indigo”）是使用托管代码建立和运行面向服务（Service Oriented）应用程序的统一框架。它使得开发者能够建立一个跨平台的安全、可信赖、事务性的解决方案， 且能与已有系统兼容协作。WCF是微软分布式应用程序开发的集大成者，它整合了.Net平台 下所有的和分布式系统有关的技术，例如.Net Remoting、ASMX、Enterprise Service、WSE、 和MSMQ。以通信（Communication）范围而论，它可以跨进程、跨机器、跨子网、企业网 乃至于Internet；以宿主程序而论，可以以https://www.doczj.com/doc/178839272.html,，EXE，WPF，Windows Forms，NT Service，COM+作为宿主（Host）。WCF可以支持的协议包括TCP，HTTP，跨进程以及自定义，安全 模式则包括SAML，Kerberos，X509，用户/密码，自定义等多种标准与模式。也就是说，在 WCF框架下，开发基于SOA的分布式系统变得容易了，微软将所有与此相关的技术要素都包 含在内，掌握了WCF，就相当于掌握了叩开SOA大门的钥匙。 WCF绝大部分功能都包含在一个单独的程序集System.ServiceModel.dll中，命名空间：System.ServiceModel。 (二)服务（Service） 服务是一组公开功能的集合。服务是不透明的，客户端并不知道服务的内部实现细节；通过公开元数据的方式描述可用的功能及服务采用的通信。元数据可以预先定义，它与具体的技 术无关（Technology-Neutral），如采用基于HTTP-GET方式的WSDL或符合元数据的任何交 换协议。 (三)地址（Addresses） WCF中每一个服务都有一个地址。地址包含两个重要元素：服务位置与传输协议（Transport-Protocol）或用于服务通信的传输样式（Transport-Scheme）。服务位置包含目 标主机名、站点（或者是网站）、通信端口、管道（或者是队列），以及一个可选的特定路径或 URI（Universal Resource Identifie 统一资源标识）。WCF支持下列传输协议： ●HTTP/HTTPS ●TCP ●IPC ●Peer network ●MSMQ ●Service bus 基地址格式： 【传输协议】：//【机器或域名】【：可选端口】 例：net.tcp://localhost:8000/MyService （可以将地址net.tcp://localhost:8000/MyService读做“采用TCP协议访问 localhost机器，MyService服务在8000端口处等待用户的调用） TCP地址（默认端口808）： TCP地址采用net.tcp协议进行传输，通常它还包括端口。 例：net.tcp://localhost:8002/MyService
WCF服务以控制台程序为宿主时的跨域访问问题 前几天研究SilverLight时碰到了这个问题，本以为很轻松的试验结果很不顺利，查了很多资料才解决了这个问题，在此把解决问题的方法写出来，也方便其它朋友借鉴。 问题是这样产生了，我在测试SilverLight时为了测试与WCF的通讯，创建了一个控制台的应用程序做为WCF服务的宿主程序。 同时创建了一个SilverLight应用程序和一个承载SilverLight的Web程序. 解决方案如图:
控制台程序: 1.添加WCF服务 命名为WCFService.cs,并添加服务,代码如下: namespace WCFBase { // 注意: 如果更改此处的类名"WCFService"，也必须更新App.config 中对"WCFService" 的引用。 public class WCFService : IWCFService
{ public int DoWork(int a,int b) { return a + b; } public int DoWork2(int a, int b) { return a - b; } } } 系统会自动添加App.config文件和相关配置节信息内容如下:
一、快速搭建WCF程序 1、ABC的概念 A:address：服务地址。访问网页时请求的地址 B:Binding: Client和Service的通道，例如访问web时，使用Http通道 WCF支持的通道有：BasicHttpBinding[WSHttpBinding],NetTcpBinding,netMSMQBinding. C:Contract:契约，包括定义的接口，参数，返回值，方法名 2、定义WCF项目 (1) 在新建项目中添加新建项，找到"WCF服务"这个模板。 (2) 步骤 Service：服务端 定义一个接口 PS：接口名可以随意改：例如在IFlyService 首先在接口名上面加一个ServiceContract特性 其次在方法名上面加一个OperationContract特性
●定义一个实现类 把接口中的方法改为String是想有返回值，方法名改为Fly，实现类中重写该方法。 ●定义配置文件 app.config中所有的定义都应该在System.serviceModel这个配置节点中。 ●承载WCF服务，一般可用IIS，Console，winform承载 Client：建立客户端连接Service （1）建立一个控制台应用程序 （2）然后添加服务引用，服务地址就是配置app.Config中host节点中的服务地址（可随意更改），注意一定要启动服务实例，才能访问服务 （3）下一步之后在Main方法启动代码如下： （4）然后启动实例可以看到控制台中打印出“Hello,World!”，启动成功。
注意：一定要以管理员身份打开VS。
1.概念 Windows Communication Foundation(WCF)是由微软发展的一组数据通信的应用程序开发接口，可以翻译为Windows通讯接口。它是.NET框架的一部分，由 .NET Framework 3.0 开始引入。 WCF的终结点有三个要素组成，分别是地址（Address）、绑定（Binding）和契约（Contract），简记可写成Endpoint = ABC。 地址：地址决定了服务的位置，解决了服务寻址的问题。 绑定：绑定实现了通信的所有细节，包括网络传输、消息编码，以及其他为实现某种功能对消息进行的相应处理。绑定的类型包括BasicHttpBinding、WsHttpBinding、NetTcpBinding 等。 契约：契约是对服务操作的抽象，也是对消息交换模式以及消息结构的定义。 2.契约 WCF 的基本概念是以契约(Contract) 来定义双方沟通的协议，契约必须要以接口的方式来体现，而实际的服务代码必须要由这些合约接口派生并实现。契约分成了四种： 数据契约 (Data Contract)，订定双方沟通时的数据格式。服务契约 (Service Contract)，订定服务的定义。操作契约 (Operation Contract)，订定服务提供的方法。消息契约 (Message Contract)，订定在通信期间改写消息内容的规范。 如下图，解释了契约：
3.绑定 由于WCF 支持了HTTP，TCP，Named Pipe，MSMQ，Peer-To-Peer TCP 等协议，而HTTP 又分为基本HTTP 支持(BasicHttpBinding) 以及WS-HTTP 支持(WsHttpBinding)，而TCP 亦支持NetTcpBinding，NetPeerTcpBinding 等通信方式，因此，双方必须要统一通信的协议，并且也要在编码以及格式上要有所一致。 基本绑定(BasicHttpBinding) 对应BasicHttpBinding类，能够将WCF服务公开为传统的ASMX Web服务，是以前就的程序能够使用现在的WCF服务。在实际开发中一个WCF服务可能会给不同的程序调用，如给Java的程序调用，给Flex的程序调用等，那么采用BasicHttpBinding最合适不过了 TCP绑定(NetTcpBinding)
不要在using语句中调用WCF服务 如果你调用WCF服务时，像下面的代码这样在using语句中进行调用，需要注意一个问题。using (CnblogsWcfClient client = new CnblogsWcfClient()) { client.Say("Hello, https://www.doczj.com/doc/178839272.html,!"); } 上面这段代码看上去没问题，CnblogsWcfClient是一个自动生成的WCF客户端代理，继承自System.ServiceModel.ClientBase。using语句结束时，会调用ClientBase实现的System.IDisposable.Dispose接口，实际就是调用ClientBase的Close()方法。用.NET Refector打开C:\Windows\https://www.doczj.com/doc/178839272.html,\Framework\v4.0.30319\System.ServiceModel.dll，可以看到这样的代码，见下图： 不仅看上去没问题，似乎就是没问题。但是...问题就出在ClientBase.Close()上，Close()要关闭的是一个网络连接，如果这时网络连接出现问题，不能正常关闭会引发异常（ClientBase的Close方法就是这样设计的，引发异常，而不是强制关闭），问题就来了。本来我们使用using的目的就是不管出现什么状况，即使天塌下来，也给我关闭掉；结果，关是关了，却没有闭，天还是塌下来了。 也许我们可以用“不可抗拒力”回避这个问题，但程序员的天性是解决问题。代码中任何一个小问题都不能忽视，因为我们很难预料这个小问题会不会带来大问题。 那如何解决这个问题呢？MSDN中有答案（去MSDN看看），代码如下：CnblogsWcfClient client = new CnblogsWcfClient(); try
为了使读者对基于WCF的编程模型有一个直观的映像，我将带领读者一步一步地创建一个完整的WCF应用。本应用功能虽然简单，但它涵盖了一个完整WCF应用的基本结构。对那些对WCF不是很了解的读者来说，这个例子将带领你正式进入WCF的世界。 在这个例子中，我们将实现一个简单的计算服务（CalculatorService），提供基本的加、减、乘、除的运算。和传统的分布式通信框架一样，WCF本质上提供一个跨进程、跨机器以致跨网络的服务调用。在本例中，客户端和服务通过运行在相同的同一台机器上不同进程模拟，图1体现了客户端和服务端进程互相调用的关系。 图1 计算服务应用运行环境 WCF的服务不能孤立地存在，需要寄宿于一个运行着的进程中，我们把承载WCF服务的进程称为宿主，为服务指定宿主的过程称为服务寄宿（Service Hosting）。在我们的计算服务应用中，采用了两种服务寄宿方式：通过自我寄宿（Self-Hosting）的方式创建一个控制台应用作为服务的宿主（寄宿进程为Hos ting.exe）；通过IIS寄宿方式将服务寄宿于IIS中（寄宿进程为IIS的工作进行W3wp.exe）。客户端通过另一个控制台应用模拟（进程为Client.exe）。接下来，我们就一步一步来构建这样的一个WCF应用。 步骤一：构建整个解决方案 通过VS 2008创建一个空白的解决方案，添加如下四个项目。项目的类型、承载的功能和相互引用关系如下，整个项目在VS下的结构如图2所示。 Contracts：一个类库项目，定义服务契约（Service Contract），引用System.ServiceMode程序集（W CF框架的绝大部分实现和API定义在该程序集中）；
免费试读章节 （非印刷免费在线版） 如果你喜欢本书，请购买印刷版以支持作者和InfoQ中文站 向O’Reily和机械工业出版社致谢 本图书节选由InfoQ中文站免费发放，如果你从其他渠道获取此摘选，请注册InfoQ 中文站以支持作者和出版商 本摘选主页为 https://www.doczj.com/doc/178839272.html,/cn/articles/programming-wcf-services
序 言 对于分布式系统，或者说业界不断提及的互联系统的设计与构建，我与本书作者Juval Lowy可谓志同道合。我们经历了相似的技术历程，虽然我们效力于不同的公司，负责不同的项目，工作在不同的地方，但我们却有着共同的目标。 20世纪90年代早期，我们开始了对一种新技术理念的探索，即实现计算机之间的通信与交互。这种被称为分布式系统应用程序的平台技术也逐渐为世人所了解。随着工作站与服务器硬件的逐渐普及，经济因素不再成为制约发展的瓶颈，构建不依赖于单事务网络中心的大型系统就成为了技术热点。对于大范围的数据交换系统而言，同样如此。在过去，我的电话公司如果要求每秒钟传递超过1200位的数据几乎是不可能的，而在如今看来连这都达不到简直不可思议。在同样的线路上，今天的传输速度已经达到了6Mbit/s。这真是一个激动人心的时代啊。 随着分布式计算技术的逐渐成熟，在90年代早期分属两大阵营的大型分布式系统技术渐露峥嵘，即数字设备公司（最终被康柏兼并，并入惠普）主导的DCE技术，以及OMG 组织（主要由IBM支持）倡导的CORBA技术。然而在1996~1997期间，所有这些杰出的工程学成果却突然停滞不前。因为此时是互联网的世界，整个世界都疯迷于HTML、HTTP、风险投资以及IPO（Initial Public Offerings，首次公开募股）。整个行业花费了整整10年的时间才逐渐从泡沫经济带来的崩溃中恢复过来。不仅是经济的复苏，技术的发展也重新走回正轨。随之获益的是分布式系统技术由此打破了过去由两大阵营各占半壁江山的局面，多达数十种新的分布式技术如雨后春笋一般展现在人们眼前，使我们拥有了更多的抉择权。 直到2007年，整个行业仍然在为分布式系统的正确编码方式争论不休。Sun公司或者BEA力主Java；而我在微软的同事（包括我）则坚定地主张C#或者Visual Basic才是最佳的实现方式。无论是Sun、BEA、IBM还是微软，都希望机器之间的通信标准能够达成一致。试想昔日的DCE与CORBA之争，正是因为达成了一致的标准规范才为如今的SOAP 1.1奠定了基础，从而开创了分布式技术的盛大场面。 自从SOAP 1.1作为技术说明（Technical Note）被提交给W3C，到现在已有超过6年的历史。期间，多家行业合作商共同开发与协定了众多基于SOAP的规范，从包括寻址以及众多安全选项的基础规范，到诸如原子事务协作的企业协议。我在微软的团队，仍然非正式地称呼我们的产品为“Indigo”，它代表了整个开发与协商过程中耗费的所有心血。如果没有IBM、微软以及其他合作伙伴对创建通用标准集的大力支持，在竞争如此激烈的企业领域几乎不可能存在开放标准的框架，更不可能具有支持多个开发商以及各种平台的多种实现。 诚然，WCF的实现超出了预计需要花费的时间。标准的协定耗费了大量时间，毕竟我们不能只顾着发布自己的软件（Windows Communication Foundation, WCF），而不考虑它与我们的行业合作伙伴以及竞争者之间的互操作性。设计同样如此，对于那些具有分布式系统开发经验的客户而言，他们花费了大量时间学习以及掌握了我们之前提供的分布式系统技术，包括https://www.doczj.com/doc/178839272.html,服务、Web服务增强（WSE）、.NET Remoting、消息传输/MSMQ以及企业服务/COM+，我们在发布软件的同时必须考虑这些客户。