随笔分类 - .NET(C#) 开发
摘要：WCF 根据服务端源代码中定义的内部类名称和属性来生成外部暴露服务实现。这些实现通过服务中的MEX终结点暴露出来并在设计阶段时被客户端以WSDL形式使用。接下来在客户端，WSDL会被用来写一些代码来建立可以与服务端通信的适当的消息格式。所以你选择的类，方法和参数的名字与服务范围潜在相差很远。
然而，在服务的接口暴露内部名字和外部细节是很不好的形式。比如，你可能有一个叫BurgerMaster的分配算法，你想在外部以Resources名字暴露这个算法。或者可能有内部的编码标准要求你应该命名接口。幸运的是，你可以通过修改[ServiceContract]，[OperationContract], [ServiceBehavior]来控制所有服务暴露的名字。
阅读全文
摘要：一个服务作为一系列终结点被定义的。每个终结点都有一个地址，绑定和契约。契约就是暴露终结点能力的。地址就是这些应用或服务从网络的哪个地址可找到，契约是关于如何访问他们的。
在终结点和契约间有一对多的关系。一个终结点可以只有一个契约，但是一个契约可以被很多终结点引用。尽管一个终结点可以仅仅确认一个契约，接口聚合使能一个单独的契约来暴露多个接口。另外，多个有同样绑定但是不同契约的终结点可以位于同一个地址，给一个单独终结点实现所有契约的假象。
阅读全文
摘要：为了参与到一个双工消息交换模式中，客户端必须实现WCF的ABCs-必须在客户端定义服务要把消息发送到的地址，指导服务端如何把消息发送给客户端的绑定，定义消息内容和格式的契约。幸运的是，当你生成一个客户端代理而且在运行时使用信道结构时，WCF很大程度上考虑到了这些。
阅读全文
摘要：一个双向契约包含服务终结点和客户端终结点的接口实现。在契约类型中，服务端契约在客户端实现。
阅读全文
摘要：你可以通过两个不同消息交换模式来解决双向通信问题。你可以使用两个单向契约，或者你可以使用一个双工契约。
阅读全文
摘要：请求-回复通信是客户端与服务端最普遍的消息交换模式。通信在客户端被初始化，客户端发送一个请求消息给服务端，然后服务端发送一个返回消息给客户端。如果返回消息很快，那么通信过程可以是同步的，所以客户端应用程序阻塞等待反馈。如果请求和回复之间会有延时，请求-回复模式可以在客户端使用标准.NET技术实现异步调用。在那种情况下，WCF会在发送请求给服务端后立即把控制返回给客户端应用程序。当服务接收到反馈以后，一个.NET回调方法被调用来完成WCF回复。
阅读全文
摘要：当一个客户端需要向一个服务端发送消息但是不接受返回消息时，但不消息交换模式很有用。使用这个模式，客户端只需要消息成功传递的确认；它不需要服务端返回一个精确的消息。有时单步模式被错误的称作"发后不理"。在实际应用中，它是"发送和理解"因为调用者接收到一个消息成功提交到通信信道的确认。
阅读全文
摘要：好的设计会降低用户必须等待一个任务结束然后初始化另一个任务之前的情况。例如，当一个e-mail客户端正在下载新邮件，你仍然可以读或者删除已经下载下来的邮件。或者当一个浏览器正在下载一个网页上引用的图片时，你仍然可以拖动网页或者跳转到任何地方。在客户端程序中的多任务形式是通过异步设计模式来完成的。
阅读全文
摘要：WCF使得在客户端和服务端进行请求-回复通信非常容易。在设计阶段，你使用添加服务引用或者svcutil.exe来调用服务元数据终结点而且生成一个客户端代理来模仿服务操作的签名。这允许客户端代码像本地函数调用一样调用代理上的方法。代理把方法名字和参数序列化成一个SOAP消息，然后发送SOAP消息到服务端，然后创建一个.NET类型来表示从服务返回的回复消息。
列表2.1显示一个服务契约定义。一个服务契约和一个操作契约被定义到代码中。操作契约代表一个可以被客户端调用的方法，或者更准确一些的说，一条消息可以被客户端发送并被服务端理解。注意契约在接口中定义，而不是类定义。
阅读全文
摘要：WCF在设计时和运行时使用服务契约。在设计阶段，它们确定应该在WSDL理暴露为终结点的代码的类。一个使用[ServiceContract]标记的类和使用[OperationContract]标记的类中方法在WSDL中暴露以便于它们可以被客户端访问。类以wsdl:service确定，操作以wsdl:operation确定。在运行时，当WCF分开器接收到消息时，它查看wsdl:operation 的名字来确定类中的以[OperationContract]标记的哪个方法需要接受反序列化消息。
阅读全文
摘要：在原子和金钱世界中，契约是两个或多个组织以一个已知的价格提供商品和服务的合同。在比特和服务的世界中，契约有类似的功能:它是两个或多个组织之间确定消息交换和消息条款及条件的合同。
契约是由服务终结点发送或接收的消息的描述。每一个终结点都由ABCs定义:一个消息发送到的网络上的地址，一个描述消息如何发送的绑定，一个描述消息格式的契约。
阅读全文
摘要：在这一章，我们主要讲述WCF的基础内容，简洁的描述了ABCs.一个服务暴露终结点，每个终结点都有ABCs:地址，绑定和契约。服务也有描述它们的操作语义的行为，比如多线程和同步，但是这些将会在接下来的章节里讲述。
阅读全文
摘要：就像调用一个WCF服务，你可以使用添加服务引用(ASR)或者Svcutil.exe来创建代理类和配置文件来调用ASMX服务操作。在这些被创 建以后，客户端通过实例化代理调用方法来与ASMX网络服务通信。同样的，你可以使用添加网络服务引用(AWR)或者wsdl.exe 来生成代理类和配置文件。然后在实例被创建以后，客户端在代理上调用方法来和服务通信。
阅读全文
摘要：一个WCF服务可以在操作系统中运行的任何托管进程中寄宿。服务本身一般并不知道或者关心它是怎么被寄宿的，尽管它可以通过丰富的APIs来找 出来。它可以寄宿到一个不被注意的随机器初始化时启动随机器关闭时关掉的Windows 服务上，或者在一个最小化到Windows系统托盘的客户端应用程序。最普通的用法，就是在IIS里托管一个WCF服务。
阅读全文
摘要：WCF中的元数据是精确描述如何与服务通信的消息。客户端可以向一个运行的服务请求元数据来了解它们要求的终结点和消息格式。在设计时，客户端发送由 WS-MetadataExchange 标准定义的消息并接收返回的WSDL。WSDL可以被客户端用来定义一个将要用来在运行时与服务通信的代理类和配置文件。图片1.4显示了这个交流过程。
阅读全文
摘要：当需要和服务通信时WCF为客户端提供了丰富的API。通过Service.ServiceModel实现的API处理将.NET类型转换成 XML然后从客户端向服务端发送消息。你可以直接用API编程，或者你可以使用工具生成一个代理类和配置文件。在这一部分，我们将首先说明如何使用代码直 接调用服务，然后我们将使用工具实现这个过程。前一种方法使用较少的代码并不使用配置文件。后一种方式有更少的依赖性而且在调用时有更好的微控性。每种解 决方案都有很多最佳适用情况。
阅读全文
摘要：服务控制文件web.config 或是 app.config 依赖于服务是如何被寄宿的，它们必须包含一个节点。在这个节点下，服务，绑定，行为，客户端，诊 断，扩展，寄宿环境和COM+互操作都可以被特殊设置。最低限度必须有一个节点用来包含终结点，也至少有一个非基础架构 的节点在节点下面。在节点内，ABCs会被定义在每 一个终结点上。
阅读全文
摘要：WCF为在配置文件中定义服务属性提供了丰富的支持。你仍然需要为你将要在服务中暴露的特性或者算法编码，但是终结点地址，绑定和行为可以从代码中移动到配置文件中。
阅读全文
摘要：完成一个WCF服务，你要完成一个.NET 类然后使用System.ServiceModel 属性来修饰这个类。System.ServiceModel 命名空间与.NET 3.0 一起安装而且包含了大多数WCF实现。当代码编译时，CLR(公共语言运行库)解释这些属性，使用运行时代码取代它们。对于.NET来说属性并不是新事 物; 在.NET 1.0 时它们已经存在了。WCF，就像.NET 1.0,1.1和2.0 中的ASMX，当写服务时使用属性来提高我们的生产力。
阅读全文
摘要：在一个高的等级里，写一个WCF服务就像写其他服务一样，不考虑内部实现。你首先要写一些代码来实现一个功能；然后你在一个操作系统进程中运行这些代码， 这个进程监听请求回复。WCF将这些步骤正式化而且使程序员能够更加容易的处理每一个节点。比如，使用系统提供的绑定和编码器，WCF 服务将可以与标准的SOAP消息通信。默认情况下，多线程，并发和实时也可以很好的实现而且有可预见的行为。
阅读全文
浙公网安备 33010602011771号