我是靠谱客的博主 陶醉耳机,最近开发中收集的这篇文章主要介绍wcf学习高级篇,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

     代码中的所有例子都可在hi.csdn.net/heroyuchao中下载

WCF 高级篇
一、 WCF 的可靠性

首先我们得明确一点那就是网络上传送数据报是不可靠的,丢报现象时有发生,因此在WCF中对数据报传送的可靠性有特别的配制。实现可靠性的传输在WCF中是非常简单的,我们只需要在配制文件中作一些配制就行如下:

 

注意<reliableSession enable=true>,使得enable=true就行了,但是要记住不是所有的binding都可以的,目前只有三种绑定可以实现可靠传输
分别是:netTcpBindig,wsHttpBindig,wsDualHttpBinding。netTcpBindig与wsHttpBinding是默认关闭的要配制<reliableSession enable=true>
而wsDualHttpBinding是默认打开的不需要这样配制。(这种可靠性是100%的吗?学过《网络工程》的人就会知道,没有绝对可靠的协议,我相信这才是绝对的真理,呵呵)
 
一、 脱机调用服务端方法

MSMQ微软消息队列能实现一种脱机调用,因为客户端能够将信息发送到消息队列中,服务端在有空的时候再去读取消息队列中的信息,也就是说客户端的信息不必让服务端即时的处理。那么我们现在就看看在WCF中如何使用MSMQ的。还记得上一篇中的下订单的例子吗?我们继续使用这个例子,不过我要做一个小小的改动,上一篇的这个例子中,客户端调用PushOrder方法后,服务端就要马上处理把OrderID输出到控制台上。这篇中服务端不会马上处理,因为客户端可以在服务没有启动的时候调用PushOrder。只有服务在启动完才会把OrderID输出。由于我用的系统是XP,而XP默认是没有安装MSMQ的,所以我们可以在“添加删除程序中安装”方法与安装IIS是一样的。安装完成后我们在计算机管理找到消息队列。

安装一个专用队列如下所示:

前面的private$表示这个是专用队列,这里我们创建一个myprivatequeue队列并在事务性那打个勾,因为这样我们就能保证发送信息与接收信息的顺序是一样的,完成这个工作后我们再来看看服务端的代码:

代码与上一篇中基本上是一样的,唯一不同点是我们的pushorder方法上多了个IsOneWay=true,在默认情况下IsOneWay是为false的,也就是说默认情况下是双工通信,为什么我们在这里将它设为true呢?设为true后双工就变成单向了,因为客户端在调用方法时服务端是可以没有启用的,如果是双向通信,客户端在服务端没有启动时调用方法会抛出异常,但是设为true后我们就是告诉程序,我们不需求要知道调用的结果,因此客户端就能正常调用没有启动的服务器方法了。下面我们再看看配制文件:

这个配制文件有点多但是不复杂,先看看第一个endpoint,由于我们要使用MSMQ,所以我们就只使用netMsmqBinding,所以address就变成了:

net.msmq://localhost/private/myprivatequeue,其中private表示是专有队列,myprivatequeue是队列的名字,localhost是本机,如果队列是其它计算机中的,只要把localhost改成装有队列的计算机IP或计算机名就行。那第二个endpoint与第三个endpoint的作用呢?我们知道服务端只有将contract暴露后客户端才能下载到,暴露元数据我们必须用mex系列的绑定,而mex是成队使用的如第二个endpoint中的wsHttpBindingmexHttpBinding就是一对。而netMsmqBinding没有与它对应的mex绑定,所以我就加了后两个endpoint,这样客户端就能通过http下载到代理了。

再看看客户端的调用代码:

 

为什么我们的构造函数中有个“NetMsmqBinding_MyService”呢?在上一篇中我们知道如果有多个endpoint时我们就要选一个endpoint而完成调用。而netmsmqbinding_myservice就是选用MSMQ绑定的endpoint的,大家看看客户端的下载到代理后的配制文件就知道了。
我们可以在不启动服务端时调用方法,后启动服务就能看到刚刚客户端的调用结果了。
 
一、 回调客户方法
回调客户方法我们在WebService是很难实现的,但是Remoting是很容易实现的,因为在Remoting中可以引用传递对象。下面我们看看如何在WCF中实现回调客户方法的。
回调的方法一定是在客户实现的,在服务端声明的,因为我们可以把回调方法的声明放到一个接口的定义中,因此这个接口就是回调契约,那么这个回调方法就是方法契约了。有了这点说明后,我们再看看代码:

首先我们定义了一个回调接口ICallback,在接口中我定义了回调方法Notify,但是我们的服务部分并没有实现,因为这个方法的实现会在客户端完成。Service Contract中我们只有一个方法Login,这个方法会向服务端的控制台输出有新客户端登录的信息,同时调用调用登录后的所有以登录后的客户端回调方法,其中所以回调方法的调用通道都放到了list中。看看配制文件:

在这里我们使用了netTcpBinding,这有没有它的必有性呢,使用Tcp是很必要的,因为服务端要回调客户端方法就要求通道是双向通信的。

这个客户端代码:

 

客户端我们实现了notify访求,同时在构造client对象是我们要创建一个实例上下文对象,同时向服务端传递实现了notify方法的对象。
运行服务端再启动客户端,我们会看到服务端有新用户登录的通知,但是这个客户端没有任何通知,我们再启动一个客户端,这时上一个客户端就会收到新用户登录的通知了。
注意,回头看看服务端的代码在login方法中我发现一个非常严重的BUG
callback.Notify(); 为什么是BUG,就留给大家思考了。(本示例来自微软中国的WCF培训视频)
 
一、 分布式事务
我们先来看看一个场景:我们从招商银行转500元钱到中国银行中,这里必须完成两步操作,首先从招行的帐号中扣500,其次在中国银行的帐号中加上500,同时这两步的操作必须都完成或都不完成,我们绝对不允许招商的帐号上扣了钱但是中行的帐号上没有加钱,也不允许中行的帐号上加了钱而招行的帐号上没有扣钱,而招行与中行的帐户表一定是放到不同服务器的不同数据库存中,所以这时我们就不能简单的使用本地事务来完成操作,必须使用分布式事务。这个场景将作为本节的例子代码,但是现在我们先来看看.net类库中Transaction的命名空间。
NET Framework 2.0 版包含一个新的事务框架,可以通过 System.Transactions 命名空间访问。此框架公开事务的方式是完全集成在 .NET Framework 中,并包含 ADO.NET。
除了对编程能力的增强之外,System.Transactions 与 ADO.NET 一起使用,可以在处理事务时协调优化。可提升事务是可以根据需要自动提升为完全分布式事务的轻型(本地)事务。
在 ADO.NET 2.0 中,System.Data.SqlClient 增加了在使用 SQL Server 2005 时对可提升事务的支持。除非需要添加系统开销,否则,可提升事务不会调用分布式事务的“添加系统开销”。可提升事务是自动的,不需要开发人员参与。
只有在 SQL Server 2005 中使用 SQL Server .NET Framework 数据提供程序 (SqlClient) 时,才可以使用可提升事务。
分布式事务通常占用大量的系统资源,通过 Microsoft 分布式事务协调程序 (MS DTC) 管理,该协调程序集成了事务中访问的所有资源管理器。可提升事务是 System.Transactions 事务的一种特殊形式,有效地将工作委托给简单的 SQL Server 2005 事务。System.Transactions、System.Data.SqlClient 和 SQL Server 2005 协调在处理事务时涉及到的工作,根据需要将其提升为完全分布式事务。
使用可提升事务的优点是在使用活动 TransactionScope 事务打开某个连接并且不打开任何其他连接时,事务作为轻型事务提交,而不引发完全分布式事务的其他系统开销
使用TransactionScope的一般代码格式是这样的:
Using(TransactionScope cope=new TransactionScope())
{
   …
   cope.Commit();
}
这里我们要讲下TransactionScope的构造函数
public TransactionScope (
    TransactionScopeOptionscopeOption
    )
TransactionScopeOption 是一个枚举类型有下三个值:
Required: 该范围需要一个事务。如果已经存在环境事务,则使用该环境事务。否则,在进入范围之前创建新的事务。这是默认值。
RequiresNew: 总是为该范围创建新事务。
Suppress: 环境事务上下文在创建范围时被取消。范围中的所有操作都在无环境事务上下文的情况下完成。
 
通过这些值我们就知道事务是可以传播的,但是WebSerivce与Remoting都是不支持事务的传播,这种分布是事务只能是在com+中得以实现,但是引入的WCF后我们也能够轻松实现分布式的事务。
 
回到场景

我们先来看看“招行”的服务代码:

 
代码中只有一个 Substract string account,int money
       其中 account 表示帐号 money 表示要扣的金额数 , 扣钱成功后会返回 true 失败会返回 false
在这里我主要介绍下 TransactionFlow (TransactionFlowOption.Allowed)
OperationBehavior (TransactionScopeRequired = true)
TransactionFlow (TransactionFlowOption.Allowed) 表示方法允许事务,其中TransactionFlowOption有三个值:
Allowed: 事务是被允许的
Mandatory: 必须有事务,如果没有事务会抛出异常
NotAllowed: 事务是不允许的
OperationBehavior (TransactionScopeRequired = true): 表示该方法内在操作都会在一个事务中执行。

为了能使事务能传播,我们必须在配制文件中作一些配制:

 

transactionFlow=true 就表示事务是可以传播的。注意:不是所有的绑定都能使用事务的,我们称可以使用事务的绑定为事务敏感,我这里目前没有完全收集所有的事务敏感绑定,在使用分布时我们最好上网查查。
 
再看看“中行”的代码:
 
这段代码就是完成了加钱的操作,至于配制文件与上面的一样,只是绑定的端口不同而已。
客户代码:
 
客户首先定义了一个事务范围,在这个范围内完成扣钱与加钱的操作,只有两个操作都成功后才完成事务的提交,在这里我特别对分布式事务的性能作了一下测试 , 通过 ticks 值我发现使用分布事务后会比不使用分布式事务慢 10 倍以上,所以我们要慎重考虑是否有使用分布式事务的必要性。

最后

以上就是陶醉耳机为你收集整理的wcf学习高级篇的全部内容,希望文章能够帮你解决wcf学习高级篇所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(47)

评论列表共有 0 条评论

立即
投稿
返回
顶部