您现在的位置是：网站首页> 编程资料编程资料

Microsoft .Net Remoting系列教程之三:Remoting事件处理全接触_自学过程_

2023-05-24 410人已围观

简介 Microsoft .Net Remoting系列教程之三:Remoting事件处理全接触_自学过程_

　　前言：在Remoting中处理事件其实并不复杂，但其中有些技巧需要你去挖掘出来。正是这些技巧，仿佛森严的壁垒，让许多人望而生畏，或者是不知所谓，最后放弃了事件在Remoting的使用。关于这个主题，在网上也有很多讨论，相关的技术文章也不少，遗憾的是，很多文章概述的都不太全面。我在研究Remoting的时候，也对事件处理发生了兴趣。经过参考相关的书籍、文档，并经过反复的试验，深信自己能够把这个问题阐述清楚了。

　　本文对于Remoting和事件的基础知识不再介绍，有兴趣的可以看我的系列文章，或查阅相关的技术文档。

本文示例代码下载：

Remoting事件(客户端发传真)

Remoting事件(服务端广播)

Remoting事件(服务端广播改进)

　　应用Remoting技术的分布式处理程序，通常包括三部分：远程对象、服务端、客户端。因此从事件的方向上看，就应该有三种形式：

1、服务端订阅客户端事件
2、客户端订阅服务端事件
3、客户端订阅客户端事件

　　服务端订阅客户端事件，即由客户端发送消息，服务端捕捉该消息，然后响应该事件，相当于下级向上级发传真。反过来，客户端订阅服务端事件，则是由服务端发送消息，此时，所有客户端均捕获该消息，激发事件，相当于是一个系统广播。而客户端订阅客户端事件呢？就类似于聊天了。由某个客户端发出消息，其他客户端捕获该消息，激发事件。可惜的是，我并没有找到私聊的解决办法。当客户端发出消息后，只要订阅了该事件的，都会获得该信息。

　　然而不管是哪一种方式，究其实质，真正包含事件的还是远程对象。原理很简单，我们想一想，在Remoting中，客户端和服务端传递的内容是什么呢？毋庸置疑，是远程对象。因此，我们传递的事件消息，自然是被远程对象所包裹。这就像EMS快递，远程对象是运送信件的汽车，而事件消息就是汽车所装载的信件。至于事件传递的方向，只是发送者和订阅者的角色发生了改变而已。

一、 服务端订阅客户端事件

　　服务端订阅客户端事件，相对比较简单。我们就以发传真为例。首先，我们必须具备传真机和要传真的文件，这就好比我们的远程对象。而且这个传真机上必须具备“发送”的操作按钮。这就好比是远程对象中的一个委托。当客户发送传真时，就需要在客户端上激活一个发送消息的方法，这就好比我们按了“发送”按钮。消息发送到服务端后，触发事件，这个事件正是服务端订阅的。服务端获得该事件消息后，再处理相关业务。这就好比接收传真的人员，当传真收到后，会听到接通的声音，此时选择“接收”后，该消息就被捕获了。

现在，我们就来模拟这个流程。首先定义远程对象，这个对象处理的应该是一个发送传真的业务：
首先是远程对象的公共接口（Common.dll）：

 public delegate void FaxEventHandler(string fax); public interface IFaxBusiness { void SendFax(string fax); }

注意，在公共接口程序集中，定义了一个公共委托。

然后我们定义具体处理传真业务的远程对象类（FaxBusiness.dll），在这个类中，先要添加对公共接口程序集的引用：

 public class FaxBusiness:MarshalByRefObject,IFaxBusiness { public static event FaxEventHandler FaxSendedEvent; #region public void SendFax(string fax) { if (FaxSendedEvent != null) { FaxSendedEvent(fax); } } #endregion public override object InitializeLifetimeService() { return null; } }

　　这个远程对象中，事件的类型就是我们在公共程序集Common.dll中定义的委托类型。SendFax实现了接口IFaxBusiness中的方法。这个方法的签名和定义的委托一致，它调用了事件FaxSendedEvent。
特殊的地方是我们定义的远程对象最好是重写MarshalByRefObject类的InitializeLifetimeService()方法。返回null值表明这个远程对象的生命周期为无限大。为什么要重写该方法呢？道理不言自明，如果生命周期不进行限制的话，一旦远程对象的生命周期结束，事件就无法激活了。
接下来就是分别实现客户端和服务端了。服务端是一个Windows应用程序，界面如下：

//img.jbzj.com/file_images/article/201605/201605301033455.gif

我们在加载窗体的时候，注册通道和远程对象：

 private void ServerForm_Load(object sender, System.EventArgs e) { HttpChannel channel = new HttpChannel(8080); ChannelServices.RegisterChannel(channel); RemotingConfiguration.RegisterWellKnownServiceType( typeof(FaxBusiness),"FaxBusiness.soap",WellKnownObjectMode.Singleton); FaxBusiness.FaxSendedEvent += new FaxEventHandler(OnFaxSended); }

　　我们采用的是SingleTon模式，注册了一个远程对象。注意看，这段代码和一般的Remoting服务端有什么区别？对了，它多了一行注册事件的代码：

 FaxBusiness.FaxSendedEvent += new FaxEventHandler(OnFaxSended);

这行代码，就好比我们服务端的传真机，一直切换为“自动”模式。它会一直监听着来自客户端的传真信息，一旦传真信息从客户端发过来了，则响应事件方法，即OnFaxSended方法：

 public void OnFaxSended(string fax) { txtFax.Text += fax; txtFax.Text += System.Environment.NewLine; }

这个方法很简单，就是把客户端发过来的Fax显示到txtFax文本框控件上。

而客户端呢？仍然是一个Windows应用程序。代码非常简单，首先为了简便其见，我们仍然让它在装载窗体的时候，激活远程对象：

 private void ClientForm_Load(object sender, System.EventArgs e) { HttpChannel channel = new HttpChannel(0); ChannelServices.RegisterChannel(channel); faxBus = (IFaxBusiness)Activator.GetObject(typeof(IFaxBusiness), "http://localhost:8080/FaxBusiness.soap"); }

呵呵，可以说客户端激活对象的方法和普通的Remoting客户端应用程序没有什么不同。该写传真了！我们在窗体上放一个文本框对象，改其Multiline属性为true。再放一个按钮，负责发送传真：

 private void btnSend_Click(object sender, System.EventArgs e) { if (txtFax.Text != String.Empty) { string fax = "来自" + GetIpAddress() + "客户端的传真:" + System.Environment.NewLine; fax += txtFax.Text; faxBus.SendFax(fax); } else { MessageBox.Show("请输入传真内容!"); } } private string GetIpAddress() { IPHostEntry ipHE = Dns.GetHostByName(Dns.GetHostName()); return ipHE.AddressList[0].ToString(); }

　　在这个按钮单击事件中，只需要调用远程对象faxBus的SendFax()方法就OK了，非常简单。可是慢着，为什么你的代码有这么多行啊？其实，没有什么奇怪的，我只是想到发传真的客户可能会很多。为了避免服务端人员犯糊涂，搞不清楚是谁发的，所以要求在传真上加上各自的签名，也就是客户端的IP地址了。既然要获得计算机的IP地址，请一定要记得加上对DNS的命名空间引用：
using System.Net;

　　因为我们严格按照分布式处理程序的部署方式，所以在客户端只需要添加公共程序集(Common.dll)的引用就可以了。而在服务端呢，则必须添加公共程序集和远程对象程序集两者的引用。

OK，程序完成，我们来看看这个简陋的传真机：
客户端：

//img.jbzj.com/file_images/article/201605/201605301033456.gif

嘿嘿，做梦都想放假啊。好的，传真写好了，发送吧！再看看服务端，great，老板已经收到我的请假条传真了！

//img.jbzj.com/file_images/article/201605/201605301033457.gif

二、 客户端订阅服务端事件

　　嘿嘿，吃甘蔗要先吃甜的一段，做事情我也喜欢先做容易的。现在，好日子过去了，该吃点苦头了。我们先回忆一下刚才的实现方法，再来思考怎么实现客户端订阅服务端事件？

　　在前一节，事件被放到远程对象中，客户端激活对象后，就可以发送消息了。而在服务端，只需要订阅该事件就可以。现在思路应该反过来，由客户端订阅事件，服务端发送消息。就这么简单吗？先不要高兴得太早。我们想一想，发送消息的任务是谁来完成的？是远程对象。而远程对象是什么时候创建的呢？我们仔细思考Remoting的几种激活方式，不管是服务端激活，还是客户端激活，他们的工作原理都是：客户端决定了服务器创建远程对象实例的时机，例如调用了远程对象的方法。而服务端所作的工作则是注册该远程对象。

回忆这三种激活方式在服务端的代码：

SingleCall激活方式：

 RemotingConfiguration.RegisterWellKnownServiceType( typeof(BroadCastObj),"BroadCastMessage.soap", WellKnownObjectMode.Singlecall);

SingleTon激活方式：

 RemotingConfiguration.RegisterWellKnownServiceType( typeof(BroadCastObj),"BroadCastMessage.soap", WellKnownObjectMode.Singleton);

客户端激活方式：

 RemotingConfiguration.ApplicationName = “BroadCastMessage.soap” RemotingConfiguration.RegisterActivatedServiceType(typeof(BroadCastObj));

请注意Register这个词语，它表达的含义就是注册。也就是说，在服务端并没有显示的创建远程对象实例。没有该实例，又如何广播消息呢？

或许有人会想，在注册远程对象之后，显式实例该对象不就可以了吗？也就是说，在注册后加上这一段代码：

 BroadCastObj obj = new BroadCastObj();

　　然而，我们要明白一个事实：就是服务端和客户端是处于两个不同的应用程序域中。因此在Remoting中，客户端获得的远程对象实际是服务端注册对象的代理。如果我们在注册后，人工去创建一个实例，而非Remoting在激活后自动创建的对象，那么客户端获得的对象与服务端人工创建的实例是两个迥然不同的对象。客户端获得的代理对象并没有指向你刚才创建的obj实例。所以obj发送的消息，客户端根本无法捕捉。

　　那么，我们只有望洋兴叹，束手无策了吗？别着急，别忘了在服务器注册对象方法中，还有一种方法，即Marshal方法啊。还记得Marshal的实现方式吗？

 BroadCastObj Obj = new BroadCastObj(); ObjRef objRef = RemotingServices.Marshal(Obj,"BroadCastMessage.soap");

　　这个方法与前不一样。前面的三种方式，远程对象是根据客户端调用的方式，来自动创建的。而Marshal方法呢？则显式地创建了远程对象实例，然后将其Marshal到通道中，形成ObjRef指向对象的代理。只要生命周期没有结束，这个对象就一直存在。而此时客户端获得的对象，正是创建的Obj实例的代理。

OK，这个问题解决了，我们来看看具体实现。
公共程序集和远程对象与前相似，就不再赘述，只附上代码：
公共程序集：

 public delegate void BroadCastEventHandler(string info); public interface IBroadCast { event BroadCastEventHandler BroadCastEvent; void BroadCastingInfo(string info); }

远程对象类：

 public event BroadCastEventHandler BroadCastEvent; #region IBroadCast 成员 //[OneWay] public void BroadCastingInfo(string info) { if (BroadCastEvent != null) { BroadCastEvent(info); } } #endregion public override object InitializeLifetimeService() { return null; }

　　下面，该实现服务端了。在实现之前，我还想罗嗦几句。在第一节中，我们实现了服务端订阅客户端事件。由于订阅事件是在服务端发生的，因此事件本身并未被传送。被序列化的仅仅是传递的消息，即Fax而已。现在，方向发生了改变，传送消息的是服务端，客户端订阅了事件。但这个事件是放在远程对象中的，因此事件必须被序列化。而在.Net Framework1.1中，微软对序列化的安全级别进行了限制。有关委托和事件的序列化、反序列化默认是禁止的，所以我们应该将TypeFilterLevel的属性值设置为Full枚举值。因此在服务端注册通道的方式就发生了改变：

 private void StartServer() { BinaryServerFormatterSinkProvider serverProvider = new BinaryServerFormatterSinkProvider(); BinaryClientFormatterSinkProvider clientProvider = new BinaryClientFormatterSinkProvider(); serverProvider.TypeFilterLevel = TypeFilterLevel.Full; IDictionary props = new Hashtable(); props["port"] = 8080; HttpChannel channel = new HttpChannel(props,clientProvider,serverProvider); ChannelServices.RegisterChannel(channel); Obj = new BroadCastObj(); ObjRef objRef = RemotingServices.Marshal(Obj,"BroadCastMessage.soap"); }

注意语句serverProvider.TypeFilterLevel = TypeFilterLevel.Full；此语句即设置序列化安全级别的。要使用TypeFilterLevel属性，必须申明命名空间：
using System.Runtime.Serialization.Formatters;

而后面两条语句就是注册远程对象。由于在我的广播程序中，发送广播消息是放在另一个窗口中，因此我将该远程对象声明为公共静态对象：

 public static BroadCastObj Obj = null;

然后在调用窗口事件中加入：

 private void ServerForm_Load(object sender, System.EventArgs e) { StartServer(); lbMonitor.Items.Add("Server started!"); }

来看看界面，首先启动服务端主窗口：

//img.jbzj.com/file_images/article/201605/201605301033458.gif

我放了一个ListBox控件来显示一些信息，例如显示服务器启动了。而BroadCast按钮就是广播消息的，单击该按钮，会弹出一个对话框：

//img.jbzj.com/file_images/article/201605/201605301033459.gif

BraodCast按钮的代码：

 private void btnBC_Click(object sender, System.EventArgs e) { BroadCastForm bcForm = new BroadCastForm(); bcForm.StartPo
                
                

                

                                            
上一篇：Microsoft .Net Remoting系列教程之二:Marshal、Disconnect与生命周期以及跟踪服务_自学过程_

                                                                
下一篇：ASP.NET中Webservice安全 实现访问权限控制_实用技巧_

相关内容

点击排行

本栏推荐

猜你喜欢

-六神源码网