.Net Remoting(应用程序域) - Part.1
引言
在互联网日渐普及,网络传输速度不断提高的情况下,分布式的应用程序是软件开发的一个重要方向。在.Net中,我们可以通过Web Service 或者Remoting 技术构建分布式应用程序(除此还有新一代的WCF,Windows Communication Foundation)。本文将简单介绍Remoting的一些基本概念,包括 应用程序域、Remoting构架、传值封送(Marshal by value)、传引用封送(Marshal by reference)、远程方法回调(Callback)、分别在Windows Service和IIS中寄宿宿主程序,最后我们介绍一下远程对象的生存期管理。
理解Remoting
1.应用程序域基本概念
.Net中的很多概念都是环环相扣的,如果一个知识点没有掌握(套用一下数据结构中“前驱节点”这个术语,那么这里就是“前驱知识点”),就想要一下子理解自己当前所直接面临问题,常常会遇到一些障碍而无法深入下去,或者是理解的浅显而不透彻(知道可以这样做,不知道为什么会是这样。如果只是应急,需要快速应用,这样也未尝不可)。为了更好地理解Remoting,我们也最好先了解一下Remoting的前驱知识点 -- 应用程序域。
我们知道所有的.Net 应用程序都运行在托管环境(managed environment)中,但操作系统只提供进程(Process)供程序运行,而进程只是提供了基本的内存管理,它不了解什么是托管代码。所以托管代码,也可以说是我们创建的.Net程序,是无法直接运行在操作系统进程中的。为了使托管代码能够运行在非托管的进程之上,就需要有一个中介者,这个中介者可以运行于非托管的进程之上,同时向托管代码提供运行的环境。这个中介者就是 应用程序域(Application Domain,简写为App Domain)。所以我们的.Net程序,不管是Windows窗体、Web窗体、控制台应用程序,又或者是一个程序集,总是运行在一个App Domain中。
如果只有一个类库程序集(.dll文件),是无法启动一个进程的(它并非可执行文件)。所以,创建进程需要加载一个可执行程序集(Windows 窗体、控制台应用程序等.exe文件)。当可执行程序集加载完毕,.Net会在当前进程中创建一个新的应用程序域,称为 默认应用程序域。一个进程中只会创建一个默认应用程序域,这个应用程序域的名称与程序集名称相同。默认应用程序域不能被卸载,并且与其所在的进程同生共灭。
那么应用程序域是如何提供托管环境的呢?简单来说,应用程序域只是允许它所加载的程序集访问由.Net Runtime所提供的服务。这些服务包括托管堆(Managed Heap),垃圾回收器(Garbage collector),JIT 编译器等.Net底层机制,这些服务本身(它们构成了.Net Runtime)是由非托管C++实现的。
在一个进程中可以包含多个应用程序域,一个应用程序域中可以包含多个程序集。比如说,我们的Asp.Net应用程序都运行在aspnet_wp.exe(IIS5.0)或者w3wp.exe(IIS6.0)进程中,而IIS下通常会创建多个站点,那么是为每个站点都创建一个独立的进程么?不是的,而是为每个站点创建其专属的应用程序域,而这些应用程序域运行在同一个进程(w3wp.exe或aspnet_wp.exe)中。这样做起码有两个好处:1、在一个进程中创建多个App Domain要比创建和运行多个进程需要少得多系统开销;2、实现了错误隔离,一个站点如果出现了致命错误导致崩溃,只会影响其所在的应用程序域,而不会影响到其他站点所在的应用程序域。
2.应用程序域的基本操作
在.Net 中,将应用程序域封装为了AppDomain类,这个类提供了应用程序域的各种操作,包含 加载程序集、创建对象、创建应用程序域 等。通常的编程情况下下,我们几乎从不需要对AppDomain进行操作,这里我们仅看几个本文会用到的、有助于理解和调试Remoting的常见操作:
1.获取当前运行的代码所在的应用程序域,可以使用AppDomain类的静态属性CurrentDoamin,获取当前代码所在的应用程序域;或者使用Thread类的静态方法GetDomain(),得到当前线程所在的应用程序域:
AppDomain currentDomain = AppDomain.CurrentDomain;
AppDomain currentDomain = Thread.GetDomain();
NOTE:一个线程可以访问进程中所包含的所有应用程序域,因为虽然应用程序域是彼此隔离的,但是它们共享一个托管堆(Managed Heap)。
2.获取应用程序域的名称,使用AppDomain的实例只读属性,FriendlyName:
string name = AppDomain.CurrentDomain.FriendlyName;
3.从当前应用程序域中创建新应用程序域,可以使用CreateDomain()静态方法,并传入一个字符串,作为新应用程序域的名称(亦即设置FriendlyName属性):
AppDomain newDomain = AppDomain.CreateDomain("New Domain");
4.在应用程序域中创建对象,可以使用AppDomain的实例方法CreateInstanceAndUnWrap()或者CreateInstance()方法。方法包含两个参数,第一个参数为类型所在的程序集,第二个参数为类型全称(这两个方法后面会详述):
DemoClass obj = (DemoClass)AppDomain.CurrentDomain.CreateInstanceAndUnWrap("ClassLib", "ClassLib.DemoClass");
ObjectHandle objHandle = AppDomain.CurrentDomain.CreateInstance("ClassLib", "ClassLib.DemoClass");
DemoClass obj = (DemoClass)objHandle.UnWrap();
5.判断是否为默认应用程序域:
newDomain.IsDefaultAppDomain()
3.在默认应用程序域中创建对象
开始之前我们先澄清一个概念,请看下面一段代码:
class Program{
static void
Main
(string[] args) {
MyClass obj = new MyClass();
obj.DoSomething();
}
}
此时我们说obj 是服务对象,Program是客户程序,而不管obj位于什么位置。
接下来我们来看一个简单的范例,我们使用上面提到基于AppDomain的操作,在当前的默认应用程序域中创建一个对象。我们先创建一个类库项目ClassLib,然后在其中创建一个类DemoClass,这个类的实例即为我们将要创建的对象:
namespace ClassLib {
public class DemoClass {
private int count = 0;
public DemoClass() {
Console.WriteLine("/n======= DomoClass Constructor =======");
}
public void ShowCount(string name) {
count++;
Console.WriteLine("{0},the count is {1}.", name, count);
}
// 打印对象所在的应用程序域
public void ShowAppDomain() {
AppDomain currentDomain = AppDomain.CurrentDomain;
Console.WriteLine(currentDomain.FriendlyName);
}
}
}
接下来,我们再创建一个控制台应用程序,将项目命名为ConsoleApp,引用上面创建的类库项目ClassLib,然后添加如下代码:
class Program {
static void
Main
(string[] args) {
Test1();
}
// 在当前AppDomain中创建一个对象
static void Test1() {
AppDomain currentDomain = AppDomain.CurrentDomain; // 获取当前应用程序域
Console.WriteLine(currentDomain.FriendlyName); // 打印名称
DemoClass obj;
// obj = new DemoClass() // 常规的创建对象的方式
// 在默认应用程序域中创建对象
obj = (DemoClass)currentDomain.CreateInstanceAndUnwrap("ClassLib", "ClassLib.DemoClass");
obj.ShowAppDomain();
obj.ShowCount("Jimmy");
obj.ShowCount("JImmy");
}
}
运行这段代码,得到的运行结果是:
ConsoleApp.exe
======= DomoClass Constructor =======
ConsoleApp.exe
Jimmy,the count is 1.
Jimmy,the count is 2.
现在运转良好,一切都没有什么问题。你可能想问,使用这种方式创建对象有什么意义呢?通过CreateInstanceAndUnwrap()创建对象和使用new DemoClass()创建对象有什么不同呢?回答这个问题之前,我们再来看下面另一种情况:
4.在新建应用程序域中创建对象
我们看看如何 创建一个新的AppDomain,然后在这个新的AppDomain中创建DemoClass对象。你可能会想,这还不简单,把上面的例子稍微改改不就OK了:
// 在新AppDomain中创建一个对象
static void Test2() {
AppDomain currentDomain = AppDomain.CurrentDomain;
Console.WriteLine(currentDomain.FriendlyName);
// 创建一个新的应用程序域 - NewDomain
AppDomain newDomain = AppDomain.CreateDomain("NewDomain");
DemoClass obj;
// 在新的应用程序域中创建对象
obj = (DemoClass)newDomain.CreateInstanceAndUnwrap("ClassLib", "ClassLib.DemoClass");
obj.ShowAppDomain();
obj.ShowCount("Jimmy");
obj.ShowCount("Jimmy");
}
然后我们在Main()方法中运行Test2(),结果却是得到了一个异常:类型“ClassLib.DemoClass”未标记为可序列化。在把ClassLib.DemoClass标记为可序列化(Serializable)之前,我们想一想为什么会发生这个异常。我们看看声明obj类型的这行代码:DemoClass obj,这说明了obj是在当前的默认应用程序域,也就是AppConsole.exe中声明的;然后我们在往下看,类型的实例(对象本身)却是通过 newDomain.CreateInstanceAndUnwrap() 在新创建的应用程序域 -- NewDomain中创建的。这样就出现了一种尴尬的情况:对象的引用(类型声明)位于当前应用程序域(AppConsole.exe)中,而对象本身(类型实例)位于新创建的应用程序域(NewDomain)。而上面我们提到默认情况下AppDomain是彼此隔离的,我们不能直接在一个应用程序中引用另一个应用程序域中的对象,所以这里便会引发异常。
那么如何解决这个问题呢?按照异常提示:"ClassLib.DemoClass"未标记为可序列化。那我们将它标记为可序列化是不是就解决了这个问题呢?我们可以试一下,先将ClassLib.DemoClass标记为可序列化:
[Serializable]
public class DemoClass { /*略*/ }
然后再次运行程序,发现程序果然正常运行,并且和上面的输出完全一致:
ConsoleApp.exe
======= DomoClass Constructor =======
ConsoleApp.exe
Jimmy,the count is 1.
Jimmy,the count is 2.
根据输出,我们发现在应用程序域NewDomain中创建的对象位于ConsoleApp.exe,也就是当前应用程序域中了。这就说明了一个问题:当我们将对象标记为可序列化时,然后进行上面的操作时,对象本身已经由另一应用程序域(远程)传递到了本地应用程序域中。因为其要求将对象标记为可序列化,所以不难想到,具体的方法是 先在远程创建对象,接着将对象序列化,然后传递对象,在本地进行反序列化,最后还原对象。
5.代理(Proxy)和封送(Marshaling)
5.1 代理(Proxy)
现在我们在回到第3小节中 在默认应用程序域中创建对象 的例子,通过上面Test2()的例子,很容易理解为什么Test1()没有抛出异常,因为obj对象本身就位于当前应用程序域ConsoleApp.exe,所以不存在跨应用程序域访问的问题,自然不会抛出异常。那么在当前应用程序域中使用下面两种方式创建对象有什么不同呢?
DemoClass obj = new DemoClass(); // 方式一
DemoClass obj = (DemoClass)newDomain.CreateInstanceAndUnwrap("ClassLib", "ClassLib.DemoClass"); // 方式二
当我们使用第一种方式时,我们在托管堆中创建了一个对象,并且直接引用了这个对象;采用第二种方式时,我们实际上创建了两个对象:我们在newDomain中创建了这个对象,然后将对象的状态进行拷贝、串行化,然后进行封送,接着在ConsoleApp.exe(客户端应用程序域)重新创建这个对象、还原对象状态,创建对象代理。最后,我们通过这个代理访问这个对象,此时,因为代理访问的是在本地重新创建的对象而非远程对象,所以当我们在对象上调用ShowDomain()时,显示的是ConsoleApp.exe。
上面的说明中出现了两个新名称,代理和封送。现在先来解释一下代理,代理(Proxy) 提供了和远程对象(本例中是在NewDomain中创建的DemoClass对象)完全相同的接口(属性和方法)。.Net需要在客户端(本例中是ConsoleApp.exe)基于远程对象的元信息(metadata)创建代理。因此客户端必须包含远程对象的元信息(简单来说就是只包含名称及接口定义,但可以不包含实际的代码实现)。因为代理有着和远程对象完全一样的接口和名称,所以对于客户程序来说,代理就好像是远程对象一样;而代理实际上又并不包含向客户程序提供服务的实际代码(比如说方法体),所以代理仅仅是将自己与某一对象相绑定,然后把客户程序对自己的服务请求发送给对象。对于客户程序来说,远程对象(服务端对象)就好像是在本地;而对远程对象来说,也好像是为其本地程序提供服务。
NOTE:有的书本讲到这里,会提到透明代理、真实代理,以及Message Sink等概念,这些我们留待后面再说。
5.2 传值封送、传引用封送
在上面的例子中,当位于ConsoleApp.exe的obj引用NewDomain中创建的对象时,.Net将NewDomain中对象的状态进行复制、序列化,然后在ConsoleApp.exe中重新创建对象,还原状态,并通过代理来对对象进行访问。这种跨应用程序域的访问方式叫做 传值封送(Marshal by value),有点类似于C#中参数的按值传递:
![](http://www.tracefact.net/graph/Remoting/Part1/01.jpg)
NOTE:上面这种通过调用CreateInstanceAndUnWrap()方法这种方式进行传值封送是一种特例,仅仅作为示范用。在Remoting通常的情况下,传值封送发生在远程对象的方法向客户端返回数值,或者客户端向远程对象传递方法参数的情况下。后面会详细解释。
由图上可以看出,传值封送时,因为要将整个对象传递到本地,对于大对象来说很显然是低效的。所以还有一种方式就是让对象依然保留在远程(本例为NewDomain中),而在客户端仅创建代理,上面已经说了代理的接口和远程对象完全相同,所以客户端以为仍然访问的是远程对象,当客户端调用代理上的方法时,由代理将对方法的请求发送给远程对象,远程对象执行方法请求,最后再将结果传回。这种方式叫做 传引用封送(Marshal by reference)。
![](http://www.tracefact.net/graph/Remoting/Part1/02.jpg)
对象或者对象引用在传递的过程中,是以一种包装过的状态(warpper state)进行传递(所以才会称为封送吧,仅为个人猜测)。所以在创建对象时,要解包装,因此在CreateInstanceAndUnWrap()方法后多了一个AndUnWrap后缀,实际上UnWrap还包含一个创建代理的过程。
6.传引用封送范例
上面的例子中我们已经使用了传值封送,那么如何实现传引用封送呢?我们只要让对象继承自MarshalByRefObject基类就可以了,所以修改DemoClass,去掉Serializable标记,然后让它继承自MarshalByRefObject:
public class DemoClass:MarshalByRefObject {/*略*/}
接下来我们再次运行程序:
ConsoleApp.exe
======= DomoClass Constructor =======
NewDomain
Jimmy,the count is 1.
Jimmy,the count is 2.
发现obj.ShowDomain()输出为NewDomain,说明DemoClass的类型实例obj没有传值封送到ConsoleApp.exe中,而是依然保留在了NewDomain中。有的人可能想那我既标记上Serializable,又继承自MarshalByRefObject程序怎么处理呢?当我们让一个类型继承自MarshalByRefObject后,它就一定不会离开自己的应用程序域,所以仍会以传引用封送的方式进行。声明为Serialzable只是说明它可以被串行化。
继续进行之前,我们看看上面的结果还能说明什么问题:对象的状态是保留着的。这句话是什么意思呢?当我们两次调用ShowCount()方法时,第二次运行的值(count的值)是基于第一次的运行结果的。
我们再对上面Test2()的进行一下修改,多创建一个DemoClass的实例,看看会发生什么:
static void Test2() {
AppDomain currentDomain = AppDomain.CurrentDomain;
Console.WriteLine(currentDomain.FriendlyName);
// 创建一个新的应用程序域 - NewDomain
AppDomain newDomain = AppDomain.CreateDomain("NewDomain");
DemoClass obj, obj2;
// 在新的应用程序域中创建对象
obj = (DemoClass)newDomain.CreateInstanceAndUnwrap("ClassLib", "ClassLib.DemoClass");
obj.ShowAppDomain();
obj.ShowCount("Jimmy");
obj.ShowCount("Jimmy");
// 再创建一个obj2
obj2 = (DemoClass)newDomain.CreateInstanceAndUnwrap("ClassLib", "ClassLib.DemoClass");
obj2.ShowAppDomain();
obj2.ShowCount("Zhang");
obj2.ShowCount("Zhang");
}
运行Test2(),可以得到下面的输出:
ConsoleApp.exe
======= DomoClass Constructor =======
NewDomain
Jimmy,the count is 1.
Jimmy,the count is 2.
======= DomoClass Constructor =======
NewDomain
Zhang,the count is 1.
Zhang,the count is 2.
这次我们又发现什么了呢?对于obj和obj2,在NewDomain中分别创建了两个对象为其服务,且这两个对象仅创建了一次(注意到只调用了一次构造函数)。这种方式称为客户端激活对象(Client Activated Object,简称为 CAO)。请大家再次看看上面第二张传引用封送的示意图,是不是可以推出这里的结果?关于客户激活对象,后面我们会再看到,这里大家先留个印象。
7.客户应用程序(域)、服务端程序集、宿主应用程序(域)
看到Remoting这个词,我们通常所理解的可能只是本地客户机与远程服务器之间的交互。而实际上,只要是跨越AppDomain的访问,都属于Remoting。不管这两个AppDomain位于同一进程中,不同进程中,还是不同机器上。对于Remoting,可能大家理解它就包含两个部分,一个Server(服务器端)、一个Client(客户端)。但是如果从AppDomain的角度来看,服务端的AppDomain仅仅是提供了一个实际提供服务的远程对象的运行环境。所以提起Remoting,我们应该将其视为三个部分,这样在以后操作,以及我下面的讲述中,概念都会更加清晰:
- 宿主应用程序(域),服务程序运行的环境(服务对象所在的AppDomain),它可以是控制台应用程序,Windows窗体程序,Windows 服务,或者是IIS的工作者进程等。上例中为 NewDomain。
- 服务程序(对象),响应客户请求的程序(或对象),通常为继承自MarshalByRefObject的类型,表现为一个程序集。上例中为 DemoClass。
- 客户应用程序(域),向宿主应用程序发送请求的程序(或对象)。上例中为 ConsoleApp.exe。
在文中,有时我可能也会用到 客户端(Client Side) 和 服务端(Server Side)这样的词,当提到客户端时,仅指客户应用程序;当提到服务端的时候,指服务程序 和 宿主应用程序。
可以看出,在我们上面的例子中,客户端 与 宿主应用程序 位于同一个进程的不同应用程序域当中,尽管大多数情况下,它们位于不同的进程中。
而我们本章第三节,在当前应用程序域的实例上调用CreateInstanceAndUnwrap()方法创建DemoClass对象时,则是一个极端情况:即 客户程序域、宿主应用程序域 为同一个应用程序域 ConsoleApp.exe 。
NOTE:在应用程序域中底部,还有一个代码执行领域,称为环境(Context)。一个AppDomain中可以包含多个环境,跨越环境的访问也可以理解成Remoting的一个特例。但是本文不涉及这部分内容。