加入VIP
  • 专属下载特权
  • 现金文档折扣购买
  • VIP免费专区
  • 千万文档免费下载

上传资料

关闭

关闭

关闭

封号提示

内容

首页 WCF服务编程

WCF服务编程.pdf

WCF服务编程

liandie5200
2010-08-13 0人阅读 举报 0 0 暂无简介

简介:本文档为《WCF服务编程pdf》,可适用于IT/计算机领域

VeryGood序序前言第章WCF基础什么是WCF服务服务的执行边界WCF与位置透明度地址TCP地址HTTP地址IPC地址MSMQ地址对等网地址契约服务契约(ServiceContract)数据契约(DataContract)错误契约(FaultContract)消息契约(MessageContract)服务契约应用ServiceContract特性WCF服务编程VeryGood名称与命名空间托管IIS托管使用VisualStudioWebConfig文件自托管使用VisualStudio自托管与基地址托管的高级特性ServiceHost<T>类WAS托管绑定标准绑定基本绑定(BasicBinding)TCP绑定对等网绑定IPC绑定WS联邦绑定(FederatedWSBinding)WS双向绑定(DuplexWSBinding)MSMQ绑定格式与编码选择绑定WCF服务编程VeryGood使用绑定终结点管理方式配置终结点绑定配置编程方式配置终结点绑定配置元数据交换编程方式启用元数据交换元数据交换终结点编程方式添加MEX终结点简化ServiceHost<T>类元数据浏览器客户端编程生成代理管理方式配置客户端绑定配置生成客户端配置文件进程内托管配置SvcConfigEditor编辑器创建和使用代理关闭代理调用超时WCF服务编程VeryGood编程方式配置客户端编程方式配置与管理方式配置WCF体系架构宿主体系架构使用通道InProcFactory<T>的实现可靠性绑定与可靠性有序消息配置可靠性必备有序传递第章服务契约操作重载契约的继承例:服务端契约层级客户端契约层级恢复客户端层级例:代理链服务契约的分解与设计契约分解分解准则契约查询WCF服务编程VeryGood编程处理元数据MetadataHelper类第章错误错误与异常异常与实例管理单调服务与异常会话服务与异常单例服务与异常错误错误与异常对于分布式系统或者说业界不断提及的互联系统的设计与构建我与本书作者JuvalL歸y可谓志同道合。我们经历了相似的技术历程虽然我们效力于不同的公司负责不同的项目工作在不同的地方但我们却有着共同的目标。世纪年代早期我们开始了对一种新技术理念的探索即实现计算机之间的通信与交互。这种被称为分布式系统应用程序的平台技术也逐渐为世人所了解。随着工作站与服务器硬件的逐渐普及经济因素不再成为制约发展的瓶颈构建不依赖于单事务网络中心的大型系统就成为了技术热点。对于大范围的数据交换系统而言同样如此。在过去我的电话公司如果要求每秒钟传递超过位的数据几乎是不可能的而在如今看来连这都达不到简直不可思议。在同样的线路上今天的传输速度已经达到了Mbits。这真是一个激动人心的时代啊。WCF服务编程VeryGood随着分布式计算技术的逐渐成熟在年代早期分属两大阵营的大型分布式系统技术渐露峥嵘即数字设备公司(最终被康柏兼并并入惠普)主导的DCE技术以及OMG组织(主要由IBM支持)倡导的CORBA技术。然而在~期间所有这些杰出的工程学成果却突然停滞不前。因为此时是互联网的世界整个世界都疯迷于HTML、HTTP、风险投资以及IPO(InitialPublicOfferings首次公开募股)。整个行业花费了整整年的时间才逐渐从泡沫经济带来的崩溃中恢复过来。不仅是经济的复苏技术的发展也重新走回正轨。随之获益的是分布式系统技术由此打破了过去由两大阵营各占半壁江山的局面多达数十种新的分布式技术如雨后春笋一般展现在人们眼前使我们拥有了更多的抉择权。直到年整个行业仍然在为分布式系统的正确编码方式争论不休。Sun公司或者BEA力主Java而我在微软的同事(包括我)则坚定地主张C#或者VisualBasic才是最佳的实现方式。无论是Sun、BEA、IBM还是微软都希望机器之间的通信标准能够达成一致。试想昔日的DCE与CORBA之争正是因为达成了一致的标准规范才为如今的SOAP奠定了基础从而开创了分布式技术的盛大场面。自从SOAP作为技术说明(TechnicalNote)被提交给WC到现在已有超过年的历史。期间多家行业合作商共同开发与协定了众多基于SOAP的规范从包括寻址以及众多安全选项的基础规范到诸如原子事务协作的企业协议。我在微软的团队仍然非正式地称呼我们的产品为“Indigo”它代表了整个开发与协商过程中耗费的所有心血。如果没有IBM、微软以及其他合作伙伴对创建通用标准集的大力支持在竞争如此激烈的企业领域几乎不可能存在开放标准的框架更不可能具有支持多个开发商以及各种平台的多种实现。WCF服务编程VeryGood诚然WCF的实现超出了预计需要花费的时间。标准的协定耗费了大量时间毕竟我们不能只顾着发布自己的软件(WindowsCommunicationFoundation,WCF)而不考虑它与我们的行业合作伙伴以及竞争者之间的互操作性。设计同样如此对于那些具有分布式系统开发经验的客户而言他们花费了大量时间学习以及掌握了我们之前提供的分布式系统技术包括ASPNET服务、Web服务增强(WSE)、NETRemoting、消息传输MSMQ以及企业服务COM我们在发布软件的同时必须考虑这些客户。在我刚才引用的技术清单中包含了五种技术。如果使用非托管代码则还有更多的技术平台。WCF的其中一个最重要的设计目标就是通过简单的方式将这些技术集合起来以一种方式进行编程。不管是构建一个队列应用程序、事务型的N层应用程序、PP客户端、RSS种子服务器还是构建自己的企业服务总线都不再需要掌握那些只能解决部分问题的多种技术。我们只需要学习和使用WCF即可。这就是以一种方式编程的魅力所在。本书展示了大量微软已经构建好的技术细节它们可以作为您的应用程序与服务的基础。在本书中作者以享有盛誉的写作技巧深入浅出而又准确细致地介绍了WCF的体系架构。作为微软互联框架团队成员的我们也为自己构建的这一产品深感自豪。我们为开发者提供了一个统一的分布式技术体系架构它具有广泛的互操作性全面提升了面向服务的特性。同时它还是易于学习的有利于提高构建面向服务应用程序的生产力。作为当今最杰出的分布式系统专家之一Juval愿意倾尽心血全力介绍WCF我们不禁深感荣幸。我们有足够的信心相信Juval的著作能够帮助您理解人们为什么会对这一产品的问世以及它将创造的新的机遇而激动不已。这些人也包括我们、Juval以及早期的用户社区。享受本书开始构建您的第一个WCF服务吧。WCF服务编程VeryGood前言年月我在微软首次了解到使用托管代码重写COM的技术细节。随后一切如常直到年月在对C#作战略性设计评审期间负责Remoting的程序经理提出了一个宏伟的计划试图将Remoting重写为开发者真正能够使用的技术。同时微软也在寻求合作共同为ASMX中的Web服务制定全新的安全规范起草一系列附加的Web服务规格说明书。到了年月我有机会体验了一个全新的事务型体系架构它能够改善NET编程中关于事务处理的相关缺陷。当时并没有一个稳定的编程模型能够统一那些独立的技术。直到年末我有幸获邀参加一个由同行专家组成的小型团队对代号为Indigo的开发平台进行战略性的设计评审。就我所知这个开发团队可谓人才济济汇聚了许多世界上最优秀的天才。在接下来的~年时间内Indigo一共经历了三代编程模型版本的演变。就在年早期发布了基于终结点驱动对象模型的版本之后终于在当年月逐渐稳定为一个固定的版本同时更名为WindowsCommunicationFoundation(WCF)。要想得到开发者的众口称赞可谓难于上青天然而WCF却给了我们不同的诠释。对于Web服务的开发者而言WCF就是最终的应对互操作性的解决方案实现了大多数行业标准。分布式应用程序的开发者则认为它简化了远程调用以及队列调用。系统开发者认为它具备下一代面向产品的特征诸如事务与宿主为应用程序提供了现成的基础功能模块。至于应用程序的开发者WCF则为他们构建应用程序提供了声明式的编程模型。而对于架构师WCF则是构建面向服务应用程序的最终选择。一言以敝之WCF涵盖了以上所有的一切因为设计WCF的目的就是为了能够统一微软的下一代全新的技术。WCF服务编程VeryGood对我而言WCF就是下一代开发者平台它在很大程度上包容了最初的NET编程理念。任何NET开发者都可以使用WCF而不用考虑应用程序的类型、规模或者行业领域。WCF是一门基础技术它提供了生成服务与应用程序的“终南捷径”完全符合我所认同的良好的设计准则。WCF从一开始就是工程化的能够简化应用程序的开发与部署降低开发成本。WCF服务用于构建面向服务的应用程序不管这些程序是独立的桌面应用程序还是Web应用程序和服务还是高端的企业应用程序。本书的结构本书涵盖了所有设计开发基于WCF的面向服务应用程序所需的知识与技能。通过本书你可以看到如何利用WCF内建的特性例如服务托管、实例管理、并发管理、事务、离线队列调用以及安全。本书会为你展示如何使用这些特性并探究它们在这种特定的设计思路下的实现原理。你不仅能够了解到WCF编程技术以及相关的系统知识同时还包括了相应的设计方案、诀窍、最佳实践以及存在的缺陷。我之所以站在软件工程的立场阐述本书的每个主题与特征是因为我期望它能够帮助读者不仅要成为一名WCF专家而且还要成为一名优秀的软件工程师。本书带给您的这种认知能够使你如虎添翼让你的应用程序在可维护性、可扩展性、可重用性以及高效性方面更加符合软件工程的理念。本书回避了许多WCF的实现细节更多的是注重使用WCF的实用性与可行性:如何应用WCF技术?如何选择可行的设计原则与编程模型?本书大量使用了NET技术从某种角度来说本书也可以算是一本高级的C#技术书籍。除此之外本书包含了大量我所编写的套件类、工具类以及辅助类。这些内容可以提高你的开发效率保障开发的WCF服务的质量。我还开发了一个基于WCF技术的小型框架用以弥补一些设计缺陷或者简化确切WCF服务编程VeryGood的任务使其能够自动化实现。在书中我像介绍WCF技术那样详细地介绍了这些工具、理念与技术。同时我开发的框架则为你演示了如何对WCF进行扩展。在过去的两年中我在MSDN杂志上发表了大量关于WCF的文章。目前我还在为杂志的基础专栏(FoundationsColumn)撰写WCF技术文章。我要感谢杂志社能够允许我将这些文章收录到本书中。如果你曾经阅读过这些文章或许能够从本书的相关章节中发现它们的影子。比较而言本书的章节更加全面提供了WCF的多种视角、技术与实例而且这些主题也与书中的其他章节紧密相连。我在每一章中都系统地讲解了一个专题深入探讨了这些专题的内容。然而每一章又都依赖于前一章的内容因此我建议你最好按照先后顺序阅读本书。以下是书中各章节以及附录的摘要。第章WCF基础该章首先阐释了WCF的技术原理并描述了WCF的基础概念和构建模块例如地址、契约、绑定、终结点、托管以及客户端。在该章最后还讨论了WCF体系架构它将是帮助我们理解后面章节的关键。该章假定读者已经了解面向服务的思想与优势。如果你不具备这方面的知识可以首先阅读附录A的内容。即使你已经熟悉了WCF的基础概念我仍然建议你至少能够快速地浏览该章的内容它不仅能够巩固你已有的知识更在于该章介绍的一些辅助类与技术术语有助于阅读全书。第章服务契约该章致力于介绍服务契约的设计与开发。首先你会了解到一些有用的技术包括服务契约的重载与继承以及其他高级技术。然后该章深入探讨了如何设计以及分解契约以利于服WCF服务编程VeryGood务的重用、可维护性以及可扩展性。最后展示如何通过公开契约元数据完成运行时的交互编程。第章数据契约如果没有实际存在的可共享的数据类型本身如果没有使用相同的开发技术应该如何处理客户端与服务之间的数据交换?在该章你可以看到如何处理某些有趣的现实问题例如数据版本控制以及传递元素项集合的方式。第章实例管理究竟是哪一种服务实例处理哪一种客户端的请求?该章给出了问题之钥。WCF支持多种服务实例管理、激活以及生命周期管理技术这些技术与系统规模和性能息息相关。该章给出了每一种实例管理模式之间的关系指导读者何时以及如何有效地使用它们。该章还介绍与之相关的主题例如限流。第章操作随着对各种类型操作的处理客户端能够调用服务遵循相关的设计原则例如如何改善和扩展基础功能以支持回调的安装与销毁管理回调端口与通道提供类型安全的双向代理。第章错误该章全面介绍了服务将错误与异常返回给客户端的方式毕竟诸如异常与异常处理的构建都是一门特定的技术无法穿越服务边界。该章介绍了错误处理的最佳实践使开发者能够解除客户端错误处理与服务的耦合度。该章还演示了如何扩展以及改善WCF基础的错误处理机制。第章事务首先该章从整体上介绍了使用事务的目的然后讨论了事务服务的众多特征:事务管理架构、事务传播配置、WCF提供的声明性事务支持以及客户端创建事务的方式。最后该WCF服务编程VeryGood章讨论了与事务相关的设计原则例如事务服务状态管理与实例模式。第章并发管理WCF提供了一种强大而简单的声明方式用来管理客户端与服务的并发与同步。该章展现了诸多高级技术例如回调、重入、线程关联度、同步上下文以及避免死锁的最佳实践与原则。第章队列服务该章描述了客户端如何通过队列调用服务从而支持异步与离线工作。该章首先介绍如何创建与配置队列服务然后重点讲解诸如事务、实例管理、故障以及它们对服务业务模型与实现造成的影响。第章安全通过将多个方面的任务分解为一些基本的要素如消息传递、认证和授权就可以揭开面向服务安全神秘的面纱。该章演示了如何为局域网和互联网应用程序等关键场景提供安全保障。最后你可以看到我为声明式的WCF安全所编写的框架设计为自动实现安全的设置从而极大地简化对安全的管理。附录A面向服务概述附录A为那些希望了解面向服务的读者提供介绍了我在面向服务的具体应用。附录定义了面向服务应用程序(而非通常所谓的架构)以及服务自身检验了它在方法学方面的优势。附录还给出了面向服务的原则通过大多数应用程序所需要的实用要点强化了面向服务的抽象原则。附录B服务发布与订阅附录B展现了我定义的框架它实现了发布订阅事件管理的解决方案。框架可以使你只需要编写一两行代码就能发布和订阅服务。发布订阅模式属于第章的内容之所以将它放WCF服务编程VeryGood入到附录中是因为它使用了其他章节的内容例如事务与队列调用。附录CWCF编码规范基本上附录C涵盖了全书提及的甚至于没有提及的最佳实践。规范在于阐释应该“如何做”以及“怎么做”而不阐明其原因。隐藏在规范之中的基础原理可以在本书的其余部分找到。该规范同时还使用了本书讨论的辅助类。对于读者的要求本书假定读者是一名经验丰富的开发者熟悉诸如封装与继承等面向对象的概念。我会利用读者现有的对对象和组件技术以及术语的认知巩固对WCF知识的了解。读者应该对于NET以及C#的基础知识(包括泛型与匿名方法)有着清晰的了解。虽然本书大部分内容使用的是C#语言然而对于VisualBasic的开发者而言仍然具有参考价值。怎样使用本书若要使用本书需要安装NET、VisualStudio、NET的发布组件以及NET开发的SDK和VisualStudio的NET扩展版。除非特别提示本书适用的操作系统包括WindowsXP、WindowsServer和WindowsVista。同时你还需要安装一些附加的Windows组件如MSMQ和IIS。第章WCF基础本章主要介绍WCF的基本概念、构建模块以及WCF体系架构以指导读者构建一个简单的WCF服务。从本章的内容中我们可以了解到WCF的基本术语包括地址(Address)、绑定(Binding)、契约(Contract)和终结点(Endpoint)了解如何托管服务如何编写客户端代码了解WCF的相关主题诸如进程内托管(InProcHosting)以及可靠WCF服务编程VeryGood性的实现。即使你已经熟知WCF的基本概念仍然建议你快速浏览本章的内容它不仅能够巩固你的已有知识而且本章介绍的一些辅助类与技术术语也将有助于你阅读全书。什么是WCFWindows通信基础(WindowsCommunicationFoundationWCF)是基于Windows平台下开发和部署服务的软件开发包(SoftwareDevelopmentKitSDK)。WCF为服务提供了运行时环境(RuntimeEnvironment)使得开发者能够将CLR类型公开为服务又能够以CLR类型的方式使用服务。理论上讲创建服务并不一定需要WCF但实际上使用WCF却可以使得创建服务的任务事半功倍。WCF是微软对一系列产业标准定义的实现包括服务交互、类型转换、封送(Marshaling)以及各种协议的管理。正因为如此WCF才能够提供服务之间的互操作性。WCF还为开发者提供了大多数应用程序都需要的基础功能模块提高了开发者的效率。WCF的第一个版本为服务开发提供了许多有用的功能包括托管(Hosting)、服务实例管理(ServiceInstanceManagement)、异步调用、可靠性、事务管理、离线队列调用(DisconnectedQueuedCall)以及安全性。同时WCF还提供了设计优雅的可扩展模型使开发人员能够丰富它的基础功能。事实上WCF自身的实现正是利用了这样一种可扩展模型。本书的其余章节会专注于介绍这诸多方面的内容与特征。WCF的大部分功能都包含在一个单独的程序集SystemServiceModeldll中命名空间为SystemServiceModel。WCF是NET的一部分同时需要NET的支持因此它只能运行在支持它的操作系统上。目前这些操作系统包括WindowsVista(客户端和服务器)、WindowsXPSP和WindowsServerSP以及更新的版本。WCF服务编程VeryGood服务服务(Services)是公开的一组功能的集合。从软件设计的角度考虑软件设计思想经历了从函数发展到对象从对象发展到组件再从组件发展到服务的几次变迁。在这样一个漫长的发展旅程中最后发展到服务的一步可以说是最具革新意义的一次飞跃。面向服务(ServiceOrientationSO)是一组原则的抽象是创建面向服务应用程序的最佳实践。如果你不熟悉面向服务的原则可以参见附录A它介绍了使用面向服务的概况与目的。本书假定你对这些原则已经了然于胸。一个面向服务应用程序(SOA)将众多服务聚集到单个逻辑的应用程序中这就类似于面向组件的应用程序聚合组件或者面向对象的应用程序聚合对象如图所示。图:面向服务应用程序服务可以是本地的也可以是远程的可以由多个参与方使用任意技术进行开发。服务与版本无关甚至可以在不同的时区同时执行。服务内部包含了诸如语言、技术、平台、版本与框架等诸多概念而服务之间的交互则只允许指定的通信模式。服务的客户端只是使用服务功能的一方。理论上讲客户端可以是任意的Windows窗体类、ASPNET页面或其他服务。WCF服务编程VeryGood客户端与服务通过消息的发送与接收进行交互。消息可以直接在客户端与服务之间进行传递也可以通过中间方进行传递。WCF中的所有消息均为SOAP消息。注意WCF的消息与传输协议无关这与Web服务不同。因此WCF服务可以在不同的协议之间传输而不仅限于HTTP。WCF客户端可以与非WCF服务完成互操作而WCF服务也可以与非WCF客户端交互。不过如果需要同时开发客户端与服务则创建的应用程序两端都要求支持WCF这样才能利用WCF的特定优势。因为服务的创建对于外界而言是不透明的所以WCF服务通常通过公开元数据(Metadata)的方式描述可用的功能以及服务可能采用的通信方式。元数据的发布可以预先定义它与具体的技术无关(TechnologyNeutral)例如采用基于HTTPGET方式的WSDL或者符合元数据交换的行业标准。一个非WCF客户端可以将元数据作为本地类型导入到本地环境中。相似的WCF客户端也可以导入非WCF服务的元数据然后以本地CLR类与接口的方式进行调用。服务的执行边界WCF不允许客户端直接与服务交互即使它调用的是本地机器内存中的服务。相反客户端总是使用代理(Proxy)将调用转发给服务。代理公开的操作与服务相同同时还增加了一些管理代理的方法。WCF允许客户端跨越执行边界与服务通信。在同一台机器中(参见图)客户端可以调用同一个应用程序域中的服务也可以在同一进程中跨应用程序域调用甚至跨进程调用。WCF服务编程VeryGood图:使用WCF实现相同机器通信图则展示了跨机器边界的通信方式客户端可以跨越Intranet或Internet的边界与服务交互。图:使用WCF实现不同机器通信WCF与位置透明度过去诸如DCOM或NETRemoting等分布式计算技术不管对象是本地还是远程都期望为客户端提供相同的编程模型。本地调用时客户端使用直接引用处理远程对象时则使用代理。因为位置的不同而采用两种不同的编程模型会导致一个问题就是远程调用远比本地调用复杂。复杂度体现在生命周期管理、可靠性、状态管理、可伸缩性(scalability)以及安全性等诸多方面。由于远程对象并不具备本地对象的特征而编程模型却力图让它成WCF服务编程VeryGood为本地对象反而使得远程编程模型过于复杂。WCF同样要求客户端保持一致的编程模型而不用考虑服务的位置。但它的实现途径却大相径庭:即使对象是本地的WCF仍然使用远程编程模型的实例化方式并使用代理。由于所有的交互操作都经由代理完成要求相同的配置与托管方式因而对于本地和远程方式而言WCF都只需要维持相同的编程模型。这就使得开发者不会因为服务位置的改变影响客户端同时还大大地简化了应用程序的编程模型。地址WCF的每一个服务都具有一个唯一的地址(Addresses)。地址包含两个重要元素:服务位置与传输协议(TransportProtocol)或者是用于服务通信的传输样式(TransportSchema)。服务位置包括目标机器名、站点或网络、通信端口、管道或队列以及一个可选的特定路径或者URI。URI即统一资源标识(UniversalResourceIdentifier)它可以是任意的唯一标识的字符串例如服务名称或GUID。WCF支持下列传输样式:•HTTP•TCP•Peernetwork(对等网)•IPC(基于命名管道的内部进程通信)•MSMQ地址通常采用如下格式:基地址可选的URI基地址(BaseAddress)通常的格式如下:传输协议:机器名或域名:可选端口WCF服务编程VeryGood下面是一些地址的示例:http:localhost:http:localhost:MyServicenettcp:localhost:MyServicenetpipe:localhostMyPipenetmsmq:localhostprivateMyServicenetmsmq:localhostMyService可以将地址http:localhost:读作:“采用HTTP协议访问localhost机器并在端口等待用户的调用。”如果URI为http:localhost:MyService则读作:“采用HTTP协议访问localhost机器MyService服务在端口处等待用户的调用。”TCP地址TCP地址采用nettcp协议进行传输通常它还包括端口号例如:nettcp:localhost:MyService如果没有指定端口号则TCP地址的默认端口号为:nettcp:localhostMyService两个TCP地址(来自于相同的宿主具体内容将在本章后面介绍)可以共享一个端口:nettcp:localhost:MyServicenettcp:localhost:MyOtherServiceWCF服务编程VeryGood本书广泛地使用了基于TCP协议的地址。注意:我们可以将不同宿主的TCP地址配置为共享一个端口。HTTP地址HTTP地址使用http协议进行传输也可以利用https进行安全传输。HTTP地址通常会被用作对外的基于Internet的服务并为其指定端口号例如:http:localhost:如果没有指定端口号则默认为。与TCP地址相似两个相同宿主的HTTP地址可以共享一个端口甚至相同的机器。本书广泛地使用了基于HTTP协议的地址。IPC地址IPC地址使用netpipe进行传输这意味着它将使用Windows的命名管道机制。在WCF中使用命名管道的服务只能接收来自同一台机器的调用。因此在使用时必须指定明确的本地机器名或者直接命名为localhost为管道名提供一个唯一的标识字符串:netpipe:localhostMyPipe每台机器只能打开一个命名管道因此两个命名管道地址在同一台机器上不能共享一个管道名。本书广泛地使用了基于IPC的地址。MSMQ地址MSMQ地址使用netmsmq进行传输即使用了微软消息队列(MicrosoftMessageWCF服务编程VeryGoodQueueMSMQ)机制。使用时必须为MSMQ地址指定队列名。如果是处理私有队列则必须指定队列类型但对于公有队列而言队列类型可以省略:netmsmq:localhostprivateMyServicenetmsmq:localhostMyService本书第章将专门介绍队列调用。对等网地址对等网地址(PeerNetworkAddress)使用netpp进行传输它使用了Windows的对等网传输机制。如果没有使用解析器(Resolver)我们就必须为对等网地址指定对等网名、唯一的路径以及端口。对等网的使用与配置超出了本书范围但在本书的后续章节中会简略地介绍对等网。契约WCF的所有服务都会公开为契约(Contract)。契约与平台无关是描述服务功能的标准方式。WCF定义了四种类型的契约。服务契约(ServiceContract)服务契约描述了客户端能够执行的服务操作。服务契约是下一章的主题内容但书中的每一章都会广泛使用服务契约。数据契约(DataContract)数据契约定义了与服务交互的数据类型。WCF为内建类型如int和string隐式地定义了契WCF服务编程VeryGood约我们也可以非常便捷地将定制类型定义为数据契约。本书第章专门介绍了数据契约的定义与使用在后续章节中也会根据需要使用数据契约。错误契约(FaultContract)错误契约定义了服务抛出的错误以及服务处理错误和传递错误到客户端的方式。第章专门介绍了错误契约的定义与使用。消息契约(MessageContract)消息契约允许服务直接与消息交互。消息契约可以是类型化的也可以是非类型化的。如果系统要求互操作性或者遵循已有消息格式那么消息契约会非常有用。由于WCF开发者极少使用消息契约因此本书不会介绍它。服务契约ServiceContractAttribute的定义如下:AttributeUsage(AttributeTargetsInterface|AttributeTargetsClass,Inherited=false)publicsealedclassServiceContractAttribute:Attribute{publicstringName{getset}publicstringNamespace{getset}WCF服务编程VeryGood更多成员}这个特性允许开发者定义一个服务契约。我们可以将该特性应用到接口或者类类型上如例所示。例:定义和实现服务契约ServiceContractinterfaceIMyContract{OperationContractstringMyMethod(stringtext)不会成为契约的一部分stringMyOtherMethod(stringtext)}classMyService:IMyContract{publicstringMyMethod(stringtext){return"Hello"text}publicstringMyOtherMethod(stringtext){WCF服务编程VeryGoodreturn"CannotcallthismethodoverWCF"}}ServiceContract特性可以将一个CLR接口(或者通过推断获得的接口后面将详细介绍)映射为与技术无关的服务契约。ServiceCon

用户评价(3)

关闭

新课改视野下建构高中语文教学实验成果报告(32KB)

抱歉,积分不足下载失败,请稍后再试!

提示

试读已结束,如需要继续阅读或者下载,敬请购买!

文档小程序码

使用微信“扫一扫”扫码寻找文档

1

打开微信

2

扫描小程序码

3

发布寻找信息

4

等待寻找结果

我知道了
评分:

/42

WCF服务编程

仅供在线阅读

VIP

在线
客服

免费
邮箱

爱问共享资料服务号

扫描关注领取更多福利