WCF概述.docx
- 文档编号:9850091
- 上传时间:2023-05-21
- 格式:DOCX
- 页数:19
- 大小:61.71KB
WCF概述.docx
《WCF概述.docx》由会员分享,可在线阅读,更多相关《WCF概述.docx(19页珍藏版)》请在冰点文库上搜索。
WCF概述
什么是WindowsCommunicationFoundation?
Web服务中包含了用于应用程序间通信的标准协议,它在全球范围内的广泛采纳改变了软件开发。
例如,如今Web服务提供的功能包括安全性、分布式事务协调和可靠的通信。
Web服务所发生的这些改变的效益应反映在开发人员所使用的工具和技术方面。
设计WindowsCommunicationFoundation(WCF)的目的是为分布式计算提供可管理的方法,提供广泛的互操作性,并为服务定位提供直接的支持。
WCF通过一种面向服务的新型编程模型简化了关联应用程序的开发。
通过提供分层的体系结构,WCF支持多种风格的分布式应用程序开发。
WCF通道体系结构在底层提供了异步的非类型化消息传递基元。
而建立在此基础之上的是用于进行安全可靠的事务处理数据交换的各种协议功能,以及广泛的传输协议和编码选择。
类型化编程模型(称为“服务模型”)设计用来降低分布式应用程序的开发难度,并为ASP.NETWeb服务、.NETFramework远程处理和企业服务领域的专业开发人员,以及将要从事WCF开发的人员提供熟悉的开发体验。
该服务模型的特点在于它将Web服务的概念直接映射到.NETFramework公共语言运行库(CLR)中的对应内容,包括将消息灵活且可扩展地映射到用诸如VisualC#或VisualBasic等语言实现的服务。
该服务模型提供支持松散耦合和版本管理的序列化功能,并提供与诸如消息队列(MSMQ)、COM+、ASP.NETWeb服务、Web服务增强(WSE)等现有.NETFramework分布式系统技术以及很多其他功能的集成和互操作性。
问题示例
下面的示例阐释了WCF处理的一些问题。
一家汽车租赁公司决定创建一个新的应用程序,用于汽车预定。
该租车预定应用程序的创建者知道,应用程序所实现的业务逻辑必须能够让公司内外运行的其他软件访问。
因此,他们决定以面向服务的方式来创建此应用程序,并通过定义完善的一组服务,将此应用程序的逻辑公开给其他软件。
为了实现这些服务并使之与其他软件进行通信,这一新应用程序将使用WCF。
在租车预定应用程序的生存期内,可能会有一系列其他应用程序访问此应用程序。
但是在设计期间设计者知道,将有其他三种软件访问该租车预定应用程序的业务逻辑(如上图所示):
∙运行在Windows桌面上的呼叫中心客户端应用程序,它由该组织的呼叫中心员工使用。
此应用程序是专门针对新的预定系统创建的,也可以使用Microsoft.NETFramework和WCF来构建。
此应用程序与新的租车预定应用程序并不泾渭分明,因为它的唯一用途是作为该新系统的客户端。
从面向服务的角度来看,它只是该预定系统的业务逻辑的另一个客户端。
∙基于J2EE服务器构建、在非Windows系统上运行的现有预定应用程序。
由于最近与另一家汽车租赁公司合并,此现有系统必须能够访问新应用程序的逻辑,以便为合并后公司的客户提供一致的体验。
∙运行在各种平台上的合作伙伴应用程序,每个应用程序分别位于一个与该汽车租赁公司有业务合作的公司内。
合作伙伴可能包括旅行社、航空公司,以及具有租车预定业务需求的其他组织。
处理好对新租车预定应用程序的众多通信要求并非易事。
例如,为了与呼叫中心客户端应用程序进行交互,性能十分重要,而互操作性则较为简单,因为二者都是建立在.NETFramework之上。
然而,要与基于J2EE的现有预定应用程序以及各种合作伙伴应用程序进行通信,互操作性又成为最重要的目标。
而从基于Windows的本地应用程序,到基于J2EE的运行在另一种操作系统上的应用程序,再到Internet上的各种合作伙伴应用程序,它们对安全性的要求也大为不同。
甚至事务性要求也可能不同,例如只允许内部应用程序发出事务性请求。
业务和技术要求如此繁杂,新应用程序的创建者在满足这些要求时何以避免难以处理的复杂性?
WCF就是针对这种繁杂却又切实存在的情况而设计的,是公开和访问服务的Windows应用程序的首选技术。
本主题将对WCF进行介绍,讲解它提供的功能并演示它的用法。
介绍全文将以前面描述的应用场景为例。
目的在于阐明什么是WCF,指出它所解决的问题,并演示它如何解决这些问题。
处理问题
基于Windows的新应用程序的基础是.NETFramework。
因此,WCF主要作为.NETFrameworkCLR上面的一组类来实现。
WCF扩展了开发人员熟悉的开发环境,这让目前使用.NETFramework创建面向对象的应用程序的开发人员也能够以自己熟悉的方式创建面向服务的应用程序。
该图显示了WCF客户端和服务。
二者使用SOAP(WCF本机消息表示形式)进行交互,因此虽然该图显示二者都是建立在WCF之上,但这并不是必需的。
WCF建立在.NETFramework2.0之上。
如前述应用场景所指出的,WCF能够解决应用程序通信所面临的一系列挑战。
而其中发挥最重要作用的是WCF的三个突出特点:
∙对多种现有.NETFramework通信技术的统一。
∙对跨供应商互操作性的支持,包括可靠性、安全性和事务。
∙显式的服务定位。
对Microsoft分布式计算技术的统一
如果没有WCF,实现租车应用程序的开发团队将需要从.NETFramework提供的多种选项中选择合适的分布式技术。
然而考虑到此应用程序的复杂要求,没有一种单独的技术能够满足这些要求。
因而,应用程序可能要使用多种现有的.NETFramework技术,例如下列技术:
∙ASP.NETWeb服务(ASMX)。
这种技术用于与基于J2EE的现有预定应用程序,以及与Internet上的合作伙伴应用程序进行通信。
因为目前大多数平台都支持基本的Web服务,所以在WCF发布之前,这是实现跨供应商互操作性的最直接的方法。
∙.NETFramework远程处理。
这种技术可用于与呼叫中心应用程序进行通信,因为二者都是建立在.NETFramework之上的。
远程处理专门为紧密耦合的.NET到.NET通信而设计,因此它为本地网络中的应用程序提供了无缝而直接的开发体验。
∙企业服务。
租车预定应用程序使用该技术来管理对象生存期和定义分布式事务。
在与此应用场景中的任何其他应用程序通信和集成时,这些功能会很有用,但是企业服务仅支持有限的一组通信选项。
∙WSE。
可与ASMX一起使用,以便与基于J2EE的预定应用程序以及合作伙伴应用程序进行通信。
它实现了最新定义的一些Web服务协议(统称WS-*规范),因此只要相关所有应用程序都支持这些新规范的兼容版本,WSE就可提供更加灵活的Web服务安全性。
∙Microsoft消息队列(MSMQ)。
用于与基于Windows的合作伙伴应用程序进行通信,这些应用程序对数据传送、工作量分离以及应用程序生存期均要求有保证。
消息队列提供持久稳定的消息传送,这通常是间歇式连接的应用程序的最佳解决方案。
由于建立在.NETFramework之上,该租车预定应用程序必须使用这些通信技术中的多种技术才能满足其要求。
尽管这在技术上是可行的,但最终的应用程序实现起来将会很复杂,而且维护起来也很困难。
使用WCF,该解决方案的实现就容易得多了。
如图中所示,WCF可用于前述所有情况。
因此,租车预定应用程序使用这一种技术就可以实现其所有应用程序间的通信。
下面说明WCF是如何满足所有这些要求的:
∙WCF可使用Web服务进行通信,因此与同样支持SOAP的其他平台(例如基于J2EE的主流应用程序服务器)间的互操作性就变得简单明了。
∙还可以对WCF进行配置和扩展,以便与使用并非基于SOAP的消息(例如像RSS这种简单的XML格式)的Web服务进行通信。
∙性能是大多数业务中至关重要的考虑事项。
开发WCF的目标就是要使之成为Microsoft所开发的速度最快的分布式应用程序平台之一。
有关WCF和其他Microsoft.NET分布式通信技术之间的高级性能比较,请参见
∙当通信双方都建立在WCF上时,为获得最理想的性能,本例中使用的线上编码是XML信息集的一个优化的二进制版本。
消息仍遵循SOAP消息的数据结构,但其编码使用该数据结构的二进制表示形式,而不是XML1.0文本编码的标准尖括号加文本格式。
使用此选项的意义体现在与呼叫中心客户端应用程序的通信中,因为该应用程序也是建立在WCF上,并且性能是一个重要的考虑事项。
∙管理对象生存期、定义分布式事务以及企业服务的其他方面的功能现在可以由WCF来提供。
任何基于WCF的应用程序都可以使用这些功能,这意味着租车预定应用程序可以针对与之通信的任何其他应用程序使用这些功能。
∙WCF支持一个大的WS-*规范集,因此可在与同样支持这些规范的任何其他平台进行通信时帮助提供可靠性、安全性和事务。
∙建立在消息队列上的WCF排队消息选项使应用程序能够使用持久的排队,而无需使用另外一组应用程序编程接口。
这种统一性的结果是获得了更强的功能,并显著降低了复杂性。
与使用其他技术构建的应用程序的互操作性
WCF不仅为分布式应用程序引入了新的开发环境,它的设计使其同样能够与非WCF应用程序进行良好的互操作。
WCF互操作性有两个重要方面:
与其他平台的互操作性,以及与WCF之前的Microsoft技术的互操作性。
下面一节将介绍这两种互操作性。
与其他Web服务平台的互操作性
如今,企业的系统和应用程序通常是从不同的供应商那里购买的。
例如,在租车应用程序中,需要与其他各种使用不同语言编写、运行在各种操作系统上的软件应用程序进行通信。
WCF的基本通信机制是基于SOAP的Web服务,因此基于WCF的应用程序可以与运行在各种不同环境中的软件进行通信。
构建于WCF上的应用程序可以与下列应用程序进行交互:
∙运行在同一台Windows计算机上的不同进程中、基于WCF的应用程序。
∙运行在另一台Windows计算机上的基于WCF的应用程序。
∙基于J2EE应用程序服务器等其他技术构建的、支持标准Web服务的应用程序。
这些应用程序可以运行在Windows计算机上,也可以运行在采用其他操作系统的计算机上。
为实现基本通信以外的功能,WCF还实现WS-*规范所定义的Web服务技术。
所有这些规范最初都是由Microsoft、IBM和其他供应商共同制定的。
随着规范趋于稳定,所有权通常会移交给标准机构,例如万维网联合会(W3C)或结构化信息标准促进组织(OASIS)。
这些规范所处理的问题包括以下一些方面:
基本消息传送、安全性、可靠性、事务以及使用服务的元数据等。
有关更多信息,请参见互操作性和集成。
有关高级Web服务规范的更多信息,请参见
将这些规范按功能分组,包括以下几组:
∙消息传递:
SOAP是Web服务的基础,它定义包含标头和正文部分的基本信封。
WS-Addressing定义在SOAP标头上附加的用于对SOAP消息进行寻址的内容,这部分附加内容使SOAP无需依赖基础传输协议(例如HTTP)就可以传送寻址信息。
消息传输优化机制(MTOM)根据XML二进制优化打包(XOP)规范,为具有大量二进制数据内容的SOAP消息定义一种优化的传输格式。
∙元数据:
Web服务描述语言(WSDL)定义一种标准语言,用于指定服务和有关如何使用这些服务的各个方面。
WS-Policy提供了一套规范,描述服务行为中无法用WSDL表达的更为动态的方面,例如首选安全选项。
WS-MetadataExchange允许客户端使用SOAP直接请求关于服务的描述性信息,例如服务的WSDL和服务策略。
∙安全性:
WS-Security、WS-SecureConversation、WS-Trust和WS-Federation都定义SOAP消息的附加部分,用来提供身份验证、数据完整性、数据保密和其他安全功能。
∙可靠性:
WS-ReliableMessaging定义SOAP标头的附加部分,它能够实现可靠的端对端通信,即使在必须穿越一个或多个Web服务媒介的情况下也是如此。
∙事务:
WS-AtomicTransaction建立在WS-Coordination之上,它允许在Web服务对话的上下文中协调两阶段提交事务。
租车预定应用程序将很可能使用这些更高级的技术中的一些技术。
例如,只要在不是HTTP的传输机制中使用SOAP,那么WS-Addressing就是必不可少的,与基于.NETFramework的呼叫中心客户端应用程序进行通信可能就属于这种情况。
WCF依靠WS-Policy和WS-MetadataExchange来发现与之通信的系统是否也在使用WCF以及其他方面的信息。
大多数情况下,可靠的通信都是十分重要的,因此很可能需要使用WS-ReliableMessaging来与此应用场景中的诸多其他应用程序进行交互。
同样,您可能还要使用WS-Security和相关规范来保证与一个或多个应用程序通信的安全,因为所有通信都要求具有某种保护,以防止XX的访问或消息修改及侦听。
对于需要与租车预定系统进行事务集成的应用程序,WS-AtomicTransaction是必需的。
最后,如果必须为二进制数据使用优化的连网格式(例如舰队图片示例),并且通信的双方都支持MTOM,那么就可能需要使用MTOM。
关键之处在于,WCF实现了可互操作的Web服务,同时提供了跨平台安全性、可靠性、事务和其他服务。
为了获得最大的吞吐量,可以对WCF到WCF的通信进行大幅度优化,但让所有其他通信使用标准的Web服务协议。
事实上,一个应用程序可以将其服务同时公开给这两种客户端。
与Microsoft技术的互操作性
许多Microsoft客户在WCF所包含的.NETFramework技术方面投资巨大。
因而保护这些投资就成了WCF设计者的重要目标。
安装WCF不会破坏现有的技术,因此组织不需要改变现有的应用程序就可以使用它。
但是,提供了一个明确的升级途径,并且只要可能,WCF都会与那些早期的技术进行互操作。
例如,WCF和ASMX都使用SOAP,因此基于WCF的应用程序可以直接与使用ASMX构建的应用程序进行互操作。
现有的企业服务应用程序也可以与WCF接口一起包装,从而可以与在WCF上构建的应用程序进行互操作。
因为WCF中的持久排队依赖于MSMQ,所以基于WCF的应用程序可以直接与使用本机MSMQ接口构建的非基于WCF的应用程序进行互操作。
在租车预定应用程序中,使用任何这些早期技术构建的软件都可以直接连接到新系统的基于WCF的服务并使用这些服务。
但是,并不是在任何情况下都可实现互操作性。
例如,虽然WSE1.0和WSE2.0实现的某些WS-*规范与WCF相同,但这些早期技术所实现的是这些规范的早期版本。
WSE的3.0版的确允许与WCF进行互操作,但早期版本则不允许。
有关互操作性的更多信息,请参见将WSE3.0Web服务迁移到WCF。
与其他XML协议的互操作性
Internet的未来是无法预言的,今天使用的技术也许会不断发展,也许会被替代。
目前,构建以Web为中心的应用程序有一个流行的趋势(许多人称之为“Web2.0”),就是采用一种应用程序模型:
该模型基于仅使用简单XML格式的通信,而这种简单的XML格式不基于SOAP,而只依赖于HTTP作为传输协议和应用程序协议。
例如,“表现性状态传输”(REST)体系结构样式不会使用用户定义的操作来处理数据。
而是应用程序状态与HTTPURL和HTTP方法(例如PUT、POST、DELETE和GET)关联。
这种方法与企业环境中多数开发人员所熟知的创建用户定义的过程或函数形成对照。
但是,在服务必须作为Web2.0应用程序后端的情况下,REST方法仍是有价值的。
REST只是Web2.0技术演进的一个示例。
在这个试验性的编程模型以及不断重新诠释和改进标准的环境中,需要以灵活性来应对不可预见的变化。
WCF是灵活的。
例如,当WCF使用SOAP作为基础结构时,并不一定要将SOAP用于网络通信。
事实上,可以对WCF进行配置,使其处理不包装在SOAP信封中的“明文”XML数据。
还可以对WCF进行扩展,以支持特定的XML格式,例如ATOM(一种广泛使用的RSS标准),甚至还可以支持非XML格式,例如JavaScript对象符号(JSON)。
这种灵活性可以确保即便协议发生了改变或被替代,当前编写的代码在将来同样有效。
可以说,WCF是为今天和将来而设计的。
WindowsCommunicationFoundation基础概念
本文档高度概括了WindowsCommunicationFoundation(WCF)体系结构。
本文档旨在解释关键概念以及这些概念之间的关系。
有关创建最简单版本的WCF服务和客户端的教程,请参见入门教程。
若要了解WCF编程,请参见基本WCF编程。
WCF基础知识
WindowsCommunicationFoundation(WCF)是一个运行库和一组API,用于创建在服务与客户端之间发送消息的系统。
它使用相同的基础结构和API来创建应用程序,这些应用程序可与同一计算机系统上或驻留在另一家公司内并通过Internet访问的系统上的其他应用程序进行通信。
消息和终结点
WCF建立在基于消息的通信这一概念基础之上,可以建模为消息(如HTTP请求或MSMQ消息)的任何内容都可以在编程模型中按照统一方式进行表示。
这样,就可以在不同传输机制间提供一个统一的API。
该模型对“客户端”(即启动通信的应用程序)和“服务”(即等待客户端与其进行通信并响应该通信的应用程序)加以区分。
单个应用程序既可以充当客户端,也可以充当服务。
消息在终结点之间发送。
终结点是发送或接收消息(或执行这两种操作)的场所,它们定义消息交换所需要的所有信息。
服务公开一个或多个应用程序终结点(以及零个或更多个基础结构终结点),而客户端生成一个与服务的其中一个终结点兼容的终结点。
“终结点”以基于标准的方式描述消息应发送到的位置、消息应如何发送以及消息应具有的形式。
服务可以将这些信息作为元数据加以公开,而客户端可以处理这些元数据以生成适当的WCF客户端和通信堆栈。
通信协议
通信堆栈的一个必要元素是传输协议。
可以使用常用传输协议(如HTTP和TCP)通过Intranet和Internet发送消息。
也可以使用其他支持与Microsoft消息队列(MSMQ)应用程序和对等网络网格上的节点进行通信的传输协议。
使用WCF的内置扩展点可以添加更多传输机制。
通信堆栈中的另一个必要元素是指定如何将任意给定消息格式化的编码。
WCF提供了下列编码:
∙文本编码,一种可互操作的编码。
∙消息传输优化机制(MTOM)编码,该编码是一种可互操作的方法,用于高效地将非结构化二进制数据发送到服务或从服务接收这些数据。
∙用于实现高效传输的二进制编码。
使用WCF的内置扩展点可以添加更多编码机制(如压缩编码)。
消息模式
WCF支持多种消息模式,包括请求-回复、单向和双工通信。
不同传输协议支持不同的消息模式,因而会影响它们所支持的交互类型。
WCFAPI和运行库还能帮助您安全而可靠地发送消息。
WCF术语
WCF文档中使用的其他概念和术语包括:
消息
消息是一个独立的数据单元,它可能由几个部分组成,包括消息正文和消息头。
服务
服务是一个构造,它公开一个或多个终结点,其中每个终结点都公开一个或多个服务操作。
终结点
终结点是用来发送或接收消息(或同时执行这两种操作)的构造。
终结点包括一个定义消息可以发送到的目的地的位置(地址)、一个描述消息应如何发送的通信机制规范(绑定),以及对可以在该位置发送或接收(或同时执行这两种操作)的一组消息的定义(服务协定,用于描述可以发送哪些消息)。
WCF服务作为一个终结点集合向外界公开。
应用程序终结点
一个终结点,由应用程序公开并对应于该应用程序实现的服务协定。
基础结构终结点
一个终结点,由基础结构公开,以便实现与服务协定无关的服务需要或提供的功能。
例如,服务可能拥有一个提供元数据信息的基础结构终结点。
地址
地址指定接收消息的位置。
地址以统一资源标识符(URI)的形式指定。
URI架构部分指定用于到达地址的传输机制,如HTTP和TCP。
URI的层次结构部分包含一个唯一的位置,其格式取决于传输机制。
使用终结点地址可以为服务中的每个终结点创建唯一的终结点地址,或者在某些条件下在终结点之间共享一个地址。
下面的示例演示了一个将HTTPS协议和一个非默认端口结合使用的地址:
复制代码
HTTPS:
//cohowinery:
8005/ServiceModelSamples/CalculatorService
绑定
绑定定义终结点与外界进行通信的方式。
它由一组称为绑定元素的要素构造而成,这些元素“堆叠”在一起以形成通信基础结构。
绑定最起码应定义传输协议(如HTTP或TCP)和所使用的编码(如文本或二进制)。
绑定可以包含指定详细信息(例如,用于保护消息的安全机制或终结点所使用的消息模式)的绑定元素。
有关更多信息,请参见配置服务。
绑定元素
绑定元素表示绑定的特定部分,如传输协议、编码、基础结构级协议(如WS-ReliableMessaging)的实现以及通信堆栈的其他任何要素。
行为
行为是控制服务、终结点、特定操作或客户端的各种运行时特性的要素。
行为按照范围进行分组:
常见行为在全局范围内影响所有终结点,服务行为仅影响与服务相关的方面,终结点行为仅影响与终结点相关的属性,操作级行为影响特定操作。
例如,有一种服务行为是遏制,它指定当过多的消息可能超出服务的处理能力时,服务应该如何反应。
另一方面,终结点行为仅控制与终结点相关的方面,如查找安全凭据的方式和位置。
系统提供的绑定
WCF包含许多系统提供的绑定。
这些绑定是针对特定方案进行优化的绑定元素的集合。
例如,WSHttpBinding是为了与实现各种WS*规范的服务进行互操作而专门设计的。
通过仅提供那些可以正确应用于特定方案的选项,这些预定义的绑定可以节省时间。
如果预定义的绑定不能满足您的要求,则可以创建您自己的自定义绑定。
配置与编码
可以通过代码编写、配置或将两者结合在一起对应用程序进行控制。
配置的优点在于,它使非开发人员(如网络管理员)可以在代码编写完成后直接对客户端和服务参数进行设置,而不必重新进行编译。
使用配置不仅可以设置值(如终结点地址),还可以
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- WCF 概述