WCF服务编程
WCF原理揭秘篇5
本系列先后通过《实例篇》、《概念篇》、《协议篇》和《编程篇》对WCF的可靠会话进行了详细探讨。
作为本系列的最后一片，我们将深入到WCF的可靠会话体系的最底层，对实现可靠会话的实现原理进行深入剖析。
如果读者仔细阅读本系列博文，相信会使读者对可靠会话的理解提升到一定的高度。
从《编程篇》中，我们不难看出可靠会话的编程仅仅围绕着一个对象，那就是绑定。
绑定在整个WCF架构模型具有重要的地位。
WCF整个架构模型由两部分构成，即服务模型（Service Model）层和信道（C hannel）层，而绑定是信道层的缔造者，同时也是连接两个层次的纽带。
对可靠会话的实现，是完全在信道层实现的。
绑定是由一系列绑定元素的有序组合，不同的保定元素具有各自的目的，而实现可靠会话的是一个叫做R eliableSessionBindingElement的绑定元素。
在《WCF技术剖析（卷1）》的第3章对绑定模型的介绍中我们知道，绑定元素的主要任务是用于对信道管理器（Channel Manager）的创建。
具体来说，在客户端和服务端分别创建信道工厂（Channel Factory）和信道监听器（Channel Listener）。
由所有信道工厂和信道监听器创建的信道按照其创建者的顺序构建起一个消息处理的通道。
WCF通过最终通过ReliableSessionBindingElement创建可靠会话信道（Reliable Session Channe l，以下简称RS信道），提供对可靠消息传输的实现。
在WS-RM定义的可靠消息传输模型中，可靠消息传输是在RM源和RM目的地之间进行的，在这里，你可以将客户端和服务端的RS信道看成是RM源和RM目的地。
一、可靠会话信道层模型图1反映的是可靠会话在信道层的实现模型，从中我们可以看出可靠会话建立在客户端和服务端的RS信道之间。
作为客户端或者服务端信道栈中的一员，RS信道在信道栈中位置由ReliableSessionBindingEl ement在绑定元素集合中的位置决定。
在VS2024里建立一个最简单的WCF服务
在VS2024里建立一个最简单的WCF服务在Visual Studio 2024中创建一个最简单的WCF服务，需要完成以下步骤：第一步，创建新的项目：1. 打开Visual Studio 20242.点击“文件”->“新建”->“项目”。
3. 在“项目类型”中选择“Visual C#”->“WCF”。
4.在“模板”中选择“WCF服务应用程序”。
5.输入项目名称和位置，点击“确定”按钮。
第二步，定义服务契约：1. 在“解决方案资源管理器”中，找到“IService1.cs”文件。
2.打开这个文件，删除其中的所有代码。
3.定义一个简单的服务契约，例如：```csharpusing System.ServiceModel;[ServiceContract]public interface IService1[OperationContract]string GetData(int value);```第三步，实现服务契约：1. 在“解决方案资源管理器”中，找到“Service1.svc.cs”文件。
2.打开这个文件，删除其中的所有代码。
3.实现定义的服务契约，例如：```csharppublic class Service1 : IService1public string GetData(int value)return string.Format("You entered: {0}", value);}```第四步，配置服务：1. 在“解决方案资源管理器”中，找到“Web.config”文件。
2.打开这个文件，删除其中的所有代码。
3.配置服务绑定和终结点，例如：```xml<system.serviceModel><services><service name="WcfService1.Service1"><endpoint address="" binding="basicHttpBinding" contract="WcfService1.IService1" /><endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /></service></services><bindings><basicHttpBinding><binding name="defaultBinding" /></basicHttpBinding></bindings><behaviors><serviceBehaviors><behavior><serviceDebug includeExceptionDetailInFaults="false" /> </behavior></serviceBehaviors></behaviors><serviceHostingEnvironment multipleSiteBindingsEnabled="true" /></system.serviceModel>```第五步，启动服务：1.点击“调试”->“开始调试”或者按下F5键，启动WCF服务应用程序。
一个完整的WCF服务的发布与测试过程
使用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服务契约上。
这一步是可选的，我们再为此WCF服务站点添加一个终结点，配置如下图下面我们将试着使用不同的终结点与WCF服务进行交互，查看运行情况。
当我们使用IIS5或IIS6发布WCF服务的时候一般只创建Http绑定的终结点，而不能创建使用TCP绑定、管道绑定的终结点。
WCF配置详解
WCF配置详解服务端的配置⽂件主要是对services、bindings、behaviors的配置。
在默认的App.config中，使⽤的是WCF Framework定义好的wsHttpBinding默认配置，所以看不到binding配置节。
配置节展开如下图：BTW： "元数据端点”通过WS-MetadataExchange帮我们实现了对服务的描述，提供了WSDL，启动Host之后我们可以通过<http://localhost:8732/Design_Time_Addresses/WcfServiceLib/Service1/?wsdl> 查看到公开的服务描述。
配置节展开如下图：关于WCF中的地址和绑定，需要补充⼀下。
WCF中⽀持的传输协议包括HTTP、TCP、Peer network(对等⽹)、IPC(基于命名管道的内部进程通信)以及MSMQ(微软消息队列)，每个协议对应⼀个地址类型：HTTP地址：<http://localhost:8080/>TCP地址： net.tcp://localhost:8080/IPC地址： net.pipe://localhost/ （适⽤于跨进程，不能使⽤于不同机器间）MSMQ地址： net.msmq://localhost/对等⽹地址： net.p2p://localhost/WCF中提供的绑定有：BasicHttpBinding: 最简单的绑定类型，通常⽤于 Web Services。
使⽤ HTTP 协议，Text/XML 编码⽅式。
WSHttpBinding: ⽐ BasicHttpBinding 更加安全，通常⽤于 non-duplex 服务通讯。
WSDualHttpBinding: 和 WSHttpBinding 相⽐，它⽀持 duplex 类型的服务。
WSFederationHttpBinding: ⽀持 WS-Federation 安全通讯协议。
精通C# 3.0与.NET 3.5高级编程——LINQ、WCF、WPF、WF
作者简介丁士锋 毕业于国防科技大学计算机学院。
有多年的大型软件系统开发经验，有近8年的.NET软件项目研发经验，擅长C#语言，对.NET框架及其底层机制有深入的理解。
曾经任职于三星电子、诺基亚等公司，从事软件项目开发。
对企业软件的设计与架构有深入的研究和大量经验，主导过多个大型的企业分布式项目的开发。
朱毅 毕业于上海交通大学，获信息工程、计算机科学双学士学位。
之后又获得了复旦大学软件工程硕士学位。
有6年多的.NET研发经验，涉及分布式系统、B/S体系结构系统、C/S体系结构系统的架构和开发。
曾任职于西门子移动通信有限公司，担任项目经理，致力于企业ERP系统的架构。
现任职于惠普有限公司ISEE项目组进行项目开发。
长期活跃于各大技术社区，曾著有《.NET程序员面试指南》一书。
业余时间喜欢阅读和旅游。
杨明羽 毕业于浙江大学计算机科学与技术专业，高级软件工程师。
多年来一直从事软件开发和项目管理类工作，有近10年的软件开发经验。
擅长C#语言，深入理解.NET框架底层机制，长期追踪.NET框架的最新技术。
曾任职于263在线、阿里巴巴等网络公司。
现任职于上海某大型网络科技公司，担任技术总监一职。
编辑推荐随书附赠微软Visual Studio 2008学习版安装光盘 6小时多媒体视频讲解 资深.NET程序员，全新视角，解读.NET 3.5框架的最新技术趋势 深入剖析.NET 3.5框架的四大开发技术及.NET 3.5框架的底层机制本书简介本丛书5种荣获“全国优秀畅销书奖”（科技类），本丛书累计销售超过100万册，本丛书先后被400余所培训机构选作参考书。
C#是微软推出的一种面向对象开发语言，其能让已有经验的开发人员轻松上手，并在很短的时间内就可以使用C#高效地进行工作。
这是读者选择C#的原因。
目前最新的C#版本就是.NET 3.5框架上的C# 3.0。
本书借助Visual Studio 2008开发工具，详细介绍了.NET框架中的4大开发利器：LINQ、WPF、WF和WCF。
wcf原理
wcf原理
WCF是Windows Communication Foundation的简称，它是一种用于构建分布式系统的编程框架。
WCF基于.NET Framework，提供了一种统一的、可扩展的编程模型来使用各种分布式技术。
WCF的原理基于拦截机制，通过通道（Channel）来传递和拦截消息。
在客户端对服务端服务进行调用时，首先会通过一个服务代理对象将调用方提供的对象序列化到消息中，然后该消息通过通道进行传递。
这些通道包括传输通道、消息编码通道、管理会话通道和传播事务通道等，形成了一个通道堆栈。
由于对象已经被序列化，消息可以跨进程或机器进行传递，利用传输通道传递到服务端。
在服务端，消息通过最底层的传输通道接收，然后解析消息编码，并一层层地往上传输。
在服务端的通道栈之上，有一个分发器（Dispatcher），它会首先对消息进行检查，然后选择一个客户端要调用的操作。
在这个过程中，消息会被反序列化。
此外，WCF的体系架构包括契约、服务运行时、消息和寄宿四个方面。
契约描述了服务的功能和作用，告诉SOA系统中的其它节点这个服务是“做什么”的；服务运行时定义了服务在运行时的具体行为；消息用于在客户端和服务端之间传递数据；寄宿则是指将服务部署到特定的环境中，并负责服务的生命周期管理。
总之，WCF通过拦截机制、通道和契约等概念，提供了一种灵活、可扩展的分布式系统开发方式。
WCF分布式开发步步为赢(10)请求应答(Request-Reply)、单向操作(One-Way)、回调操作(Call Back)
WCF分布式开发步步为赢(10):请求应答（Request-Reply）、单向操作(One-Way)、回调操作(Call Back).所属分类: WCF分布式开发步步为赢, SOA and EAIWCF除了支持经典的请求应答（Request-Reply）模式外，还提供了什么操作调用模式，他们有什么不同以及我们如何在开发中使用这些操作调用模式。
今天本节文章里会详细介绍。
WCF分布式开发步步为赢(10):请求应答（Request-Reply）、单向操作(One-Way)、回调操作(Call Back).本文结构：【1】请求应答（Request-Reply）、【2】单向操作(One-Way)、【3】回调操作(Call Back)、【4】示例代码分析、【5】总结。
最后上传本文的示例代码。
WCF除了支持经典的请求/应答模式意外，还提供了对单向操作、双向回调操作模式的支持，此外还有流操作（后者与WSE3.0提供的优化传输机制类似，我曾经在这个文章里进行过讲解WSE3.0构建Web 服务安全(4):MTOM消息传输优化和文件上传、下载）。
今天我们会介绍几种操作调用模式的概念，区别，实现机制，以及如何在代码中实现他们，最后给出的要注意的细节问题。
【1】请求应答（Request-Reply）：请求应答模式是默认的操作模式。
这与经典的C/S编程类似，客户端发送请求，阻塞客户端进程，服务端返回操作结果。
请求应答模式与绑定对应关系：1.绑定协议名称支持可靠性默认可靠性支持有序传递请求应答模式2.BasicHttpBinding No N/A No YesTcpBinding Yes Off Yes YesPeerTcpBinding No N/A No NoNamedPipeBinding No N/A (On) Yes Yes6.WSHttpBinding Yes Off Yes Yes7.WSFederationHttpBinding Yes Off Yes Yes8.WSDualHttpBinding Yes On Yes YesMsmqBinding No N/A No No10.MsmqIntegrationBinding No N/A No Yes除了NetPeerTcpBinding和NetMsmqBinding绑定，所有的绑定均支持请求-应答操作。
wcf operationcontract详解
WCF OperationContract详解一、引言在WCF（Windows Communication Foundation）中，OperationContract是一个非常重要的特性，它用于定义服务契约中的操作。
在本文中，我们将深入探讨OperationContract的概念、用法、属性和相关注意事项，帮助读者更好地理解和应用这一特性。
二、OperationContract的概念在WCF中，OperationContract用于定义服务契约（Service Contract）中的操作（Operation）。
它告诉WCF服务端和客户端哪些操作可以被调用，以及它们的参数、返回值和其他属性。
三、OperationContract的用法1. 基本用法OperationContract特性是应用于服务契约接口中的方法上的。
例如：```csharp[ServiceContract]public interface IMyService{[OperationContract]string GetData(int value);}```在上面的代码中，GetData方法使用了OperationContract特性，表示这是一个可以被调用的操作。
在客户端调用该操作时，WCF会根据OperationContract的定义来处理请求和响应。
2. 参数和返回值OperationContract还可以定义方法的参数和返回值。
例如：```csharp[ServiceContract]public interface IMyService{[OperationContract]string GetData(int value);[OperationContract]void ProcessData(string data);}```在上面的代码中，GetData方法有一个int类型的参数和一个string 类型的返回值，而ProcessData方法则没有返回值。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
序序 (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<T>类 (39)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<T>类 (65)元数据浏览器 (71)客户端编程 (71)生成代理 (72)管理方式配置客户端 (76)绑定配置 (78)生成客户端配置文件 (78)进程内托管配置 (79)SvcConfigEditor编辑器 (80)创建和使用代理 (81)关闭代理 (82)调用超时 (84)编程方式配置客户端 (85)编程方式配置与管理方式配置 (86)WCF体系架构 (87)宿主体系架构 (88)使用通道 (89)InProcFactory<T>的实现 (94)可靠性 (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），而不考虑它与我们的行业合作伙伴以及竞争者之间的互操作性。
设计同样如此，对于那些具有分布式系统开发经验的客户而言，他们花费了大量时间学习以及掌握了我们之前提供的分布式系统技术，包括服务、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专家，而且还要成为一名优秀的软件工程师。