.Net中Remoting通信機制
阿新 • • 發佈：2018-05-17
方法參數 並不是 原因 語句 ces dll 存儲 system cal 
原文:.Net中Remoting通信機制
-
Remoting通信機制
-
Remoting介紹
-
主要元素
-
通道類型
-
激活方式
-
對象定義
-
Remoting介紹
什麽是Remoting，簡而言之，我們可以將其看作是一種分布式處理方式。 從微軟的產品角度來看，可以說Remoting就是DCOM（分布式組件對象模型,分布式組件對象模式）的一種升級，它改善了很多功能，並極好的融合到.Net平臺下。Microsoft .NET Remoting 提供了一種允許對象通過應用程序域與另一對象進行交互的框架。這也正是我們使用Remoting的原因。為什麽呢？在Windows操作系統中，是將應用程序分離為單獨的進程。這個進程形成了應用程序代碼和數據周圍的一道邊界。如果不采用進程間通信（IPC）機制，則在一個進程中執行的代碼就不能訪問另一進程。這是一種操作系統對應用程序的保護機制。然而在某些情況下，我們需要跨過應用程序域，與另外的應用程序域進行通信，即穿越邊界。 Remoting通信框架圖：主要元素
- 遠程對象——遠程對象是運行在服務器上的對象。客戶端不能直接調用遠程對象上的方法，而要使用代理。使用.NET，很容易把遠程對象和本地對象區分開：即任何派生自 MarshalByRefObject 的類從來都不會離開它的應用程序域。客戶端可以通過代理調用遠程對象的方法。
- 信道——信道用於客戶端和服務器之間的通信。信道包括客戶端的信道部分和服務器的信道部分。.NET Framework 4 提供了 3 種信道類型，它們分別通過 TCP、HTTP 和IPC 進行通信。此外，還可以創建自定義信道，這些信道使用其他協議通信。
- 消息——消息被發送到信道中。消息是為客戶端和服務器之間的通信而創建的。消息包含遠程對象的信息、被調用方法的名稱以及所有的參數。
- 格式化程序——格式化程序用於定義消息如何傳輸到信道中。.NET 4 有SOAP 格式化程序和二進制格式化程序。使用 SOAP 格式化程序可以與不是基於.NET Framework 的Web 服務通信。二進制格式化程序速度更快，可以有效地用在內部網環境中。當然，也可以創建自定義格式化程序。
- 格式化程序提供程序——格式化程序提供程序用於把格式化程序與信道關聯起來。通過創建信道，可以指定要使用的格式化程序提供程序，格式化程序提供程序則定義把數據傳輸到信道中時所使用的格式化程序。
- 代理——客戶端調用代理的方法，而不是遠程對象的方法。代理分為兩種：透明的代理和真實的代理。對於客戶端，透明代理看起來與遠程對象類似。在透明代理上，客戶端可以調用遠程對象實現的方法。然後，透明代理調用真實代理上的 Invoke()方法。Invoke()方法使用消息接收器把消息傳遞給信道。
- 消息接收器——消息接收器是一個偵聽器(interceptor)對象，簡稱接收器。在客戶端和服務器上都有偵聽器。接收器與信道相關聯。真實的代理使用消息接收器把消息傳遞到信道中，因此，在消息進入信道之前，接收器可以進行截獲工作。根據接收器所處的位置，可以把接收器稱為特使接收器(envoy sink)、服務器上下文接收器、對象上下文接收器等。
- 激活器——客戶端可以使用激活器在服務器上創建遠程對象，或者獲取一個被服務器激活的對象的代理。
- RemotingConfiguration 類——該類是用於配置遠程服務器和客戶端的一個實用程序類。它可以用於讀取配置文件或動態地配置遠程對象。
- ChannelServices 類——該類是一個實用程序類，可用於註冊信道並把消息分配到信道中
通道類型
Remoting的通道主要有兩種：Tcp和Http。 在.Net中，System.Runtime.Remoting.Channels中定義了 IChannel接口。IChannel接口包括了TcpChannel通道類型和Http通道類型。 它們分別對應Remoting通道的這兩種類型。TcpChannel
TcpChannel類型放在名字空間System.Runtime.Remoting.Channels.Tcp中。Tcp通道提供了基於Socket 的傳輸工具，使用Tcp協議來跨越Remoting邊界傳輸序列化的消息流。TcpChannel類型默認使用二進制格式序列化消息對象，因此它具有更高的傳輸性能。HttpChannel
HttpChannel類型放在名字空間System.Runtime.Remoting.Channels.Http中。它提供了一種使用 Http協議，使其能在Internet上穿越防火墻傳輸序列化消息流。默認情況下，HttpChannel類型使用Soap格式序列化消息對象，因此它具有更好的互操作性。通常在局域網內，我們更多地使用TcpChannel；如果要穿越防火墻，則使用HttpChannel。激活方式
在訪問遠程類型的一個對象實例之前，必須通過一個名為Activation的進程創建它並進行初始化。這種客戶端通過通道來創建遠程對象，稱為對象的激活。 在Remoting中，遠程對象的激活分為兩大類：服務器端激活和客戶端激活。 服務端激活： 服務器端激活，又叫做WellKnow方式，很多又翻譯為知名對象。為什麽稱為知名對象激活模式呢？是因為服務器應用程序在激活對象實例之前會在一個眾所周知的統一資源標識符(URI)上來發布這個類型。然後該服務器進程會為此類型配置一個WellKnown對象，並根據指定的端口或地址來發布對象。 . Net Remoting把服務器端激活又分為SingleTon模式和SingleCall模式兩種。 SingleTon模式：此為有狀態模式。如果設置為SingleTon激活方式，則Remoting將為所有客戶端建立同一個對象實例。當對象處於活動狀態時， SingleTon實例會處理所有後來的客戶端訪問請求，而不管它們是同一個客戶端，還是其他客戶端。SingleTon實例將在方法調用中一直維持其狀態。舉例來說，如果一個遠程對象有一個累加方法（i=0；++i），被多個客戶端（例如兩個）調用。如果設置為SingleTon方式，則第一個客戶獲得值為1，第二個客戶獲得值為2，因為他們獲得的對象實例是相同的。如果熟悉Asp .Net的狀態管理，我們可以認為它是一種Application狀態。 SingleCall模式：SingleCall是一種無狀態模式。一旦設置為SingleCall模式，則當客戶端調用遠程對象的方法時， Remoting會為每一個客戶端建立一個遠程對象實例，至於對象實例的銷毀則是由GC自動管理的。同上一個例子而言，則訪問遠程對象的兩個客戶獲得的都是1。我們仍然可以借鑒Asp .Net的狀態管理，認為它是一種Session狀態。 客戶端激活： 客戶端激活。與WellKnown模式不同， Remoting在激活每個對象實例的時候，會給每個客戶端激活的類型指派一個URI。客戶端激活模式一旦獲得客戶端的請求，將為每一個客戶端都建立一個實例引用。 SingleCall模式和客戶端激活模式是有區別的：首先，對象實例創建的時間不一樣。客戶端激活方式是客戶一旦發出調用的請求，就實例化；而SingleCall則是要等到調用對象方法時再創建。其次，SingleCall模式激活的對象是無狀態的，對象生命期的管理是由GC管理的，而客戶端激活的對象則有狀態，其生命周期可自定義。其三，兩種激活模式在服務器端和客戶端實現的方法不一樣。尤其是在客戶端，SingleCall模式是由 GetObject()來激活，它調用對象默認的構造函數。而客戶端激活模式，則通過CreateInstance()來激活，它可以傳遞參數，所以可以調用自定義的構造函數來創建實例。對象定義
前面講到，客戶端在獲取服務器端對象時，並不是獲得實際的服務端對象，而是獲得它的引用。因此在Remoting中，對於遠程對象有一些必須的定義規範要遵循。 由於Remoting傳遞的對象是以引用的方式，因此所傳遞的遠程對象類必須繼承MarshalByRefObject。MSDN對 MarshalByRefObject的說明是：MarshalByRefObject 是那些通過使用代理交換消息來跨越應用程序域邊界進行通信的對象的基類。不是從 MarshalByRefObject 繼承的對象會以隱式方式按值封送。當遠程應用程序引用一個按值封送的對象時，將跨越遠程處理邊界傳遞該對象的副本。因為您希望使用代理方法而不是副本方法進行通信，因此需要繼承MarshallByRefObject。 在Remoting中能夠傳遞的遠程對象可以是各種類型，包括復雜的DataSet對象，只要它能夠被序列化。遠程對象也可以包含事件，但服務器端對於事件的處理比較特殊，我將在本系列之三中介紹。服務器
根據第一部分所述，根據激活模式的不同，通道類型的不同服務器端的實現方式也有所不同。大體上說，服務器端應分為三步： 1、註冊通道 要跨越應用程序域進行通信，必須實現通道。如前所述，Remoting提供了IChannel接口，分別包含TcpChannel和HttpChannel兩種類型的通道。這兩種類型除了性能和序列化數據的格式不同外，實現的方式完全一致，因此下面我們就以TcpChannel為例。 註冊TcpChannel，首先要在項目中添加引用“System.Runtime.Remoting”，然後using名字空間：System.Runtime.Remoting.Channels.Tcp。 比如：using System.Runtime.Remoting; using System.Runtime.Remoting.Channels; using System.Runtime.Remoting.Channels.Tcp;代碼如下：
1 TcpChannel channel = new TcpChannel(8080); 2 ChannelServices.RegisterChannel(channel);在實例化通道對象時，將端口號作為參數傳遞。然後再調用靜態方法RegisterChannel()來註冊該通道對象即可。 2、遠程對象 註冊了通道後，要能激活遠程對象，必須在通道中註冊該對象。根據激活模式的不同，註冊對象的方法也不同。 (1) SingleTon模式 對於WellKnown對象，可以通過靜態方法RemotingConfiguration.RegisterWellKnownServiceType()來實現：
1 RemotingConfiguration.RegisterWellKnownServiceType( 2 typeof(ServerRemoteObject.ServerObject), 3 "ServiceMessage",WellKnownObjectMode.SingleTon);(2)SingleCall模式 註冊對象的方法基本上和SingleTon模式相同，只需要將枚舉參數WellKnownObjectMode改為SingleCall就可以了。
1 RemotingConfiguration.RegisterWellKnownServiceType( 2 typeof(ServerRemoteObject.ServerObject), 3 "ServiceMessage",WellKnownObjectMode.SingleCall);
(3)激活模式 對於客戶端激活模式，使用的方法又有不同，但區別不大，看了代碼就一目了然。
1 RemotingConfiguration.ApplicationName = "ServiceMessage"; 2 RemotingConfiguration.RegisterActivatedServiceType( 3 typeof(ServerRemoteObject.ServerObject));為什麽要在註冊對象方法前設置ApplicationName屬性呢？其實這個屬性就是該對象的URI。對於WellKnown模式，URI是放在RegisterWellKnownServiceType()方法的參數中，當然也可以拿出來專門對ApplicationName屬性賦值。而RegisterActivatedServiceType()方法的重載中，沒有ApplicationName的參數，所以必須分開。 3、註銷通道 如果要關閉Remoting的服務，則需要註銷通道，也可以關閉對通道的監聽。在Remoting中當我們註冊通道的時候，就自動開啟了通道的監聽。而如果關閉了對通道的監聽，則該通道就無法接受客戶端的請求，但通道仍然存在，如果你想再一次註冊該通道，會拋出異常。
1 //獲得當前已註冊的通道； 2 IChannel[] channels = ChannelServices.RegisteredChannels; 3 //關閉指定名為MyTcp的通道； 4 foreach (IChannel eachChannel in channels) 5 { 6 if (eachChannel.ChannelName == "MyTcp") 7 { 8 TcpChannel tcpChannel = (TcpChannel)eachChannel; 9 //關閉監聽； 10 tcpChannel.StopListening(null); 11 //註銷通道； 12 ChannelServices.UnregisterChannel(tcpChannel); 13 } 14 }代碼中，RegisterdChannel屬性獲得的是當前已註冊的通道。在Remoting中，是允許同時註冊多個通道的，這一點會在後面說明。
客戶端
客戶端主要做兩件事，一是註冊通道。這一點從通信框架圖中就可以看出，Remoting中服務器端和客戶端都必須通過通道來傳遞消息，以獲得遠程對象。第二步則是獲得該遠程對象。 1、註冊通道：1 TcpChannel channel = new TcpChannel(); 2 ChannelServices.RegisterChannel(channel);註意在客戶端實例化通道時，是調用的默認構造函數，即沒有傳遞端口號。事實上，這個端口號是缺一不可的，只不過它的指定被放在後面作為了Uri的一部分。 2、獲得遠程對象。 與服務器端相同，不同的激活模式決定了客戶端的實現方式也將不同。不過這個區別僅僅是WellKnown激活模式和客戶端激活模式之間的區別，而對於SingleTon和SingleCall模式，客戶端的實現完全相同。 (1) WellKnown激活模式 要獲得服務器端的知名遠程對象，可通過Activator進程的GetObject()方法來獲得：
1 ServerRemoteObject.ServerObject serverObj = (ServerRemoteObject.ServerObject)Activator.GetObject( 2 typeof(ServerRemoteObject.ServerObject), "tcp://localhost:8080/ServiceMessage");首先以WellKnown模式激活，客戶端獲得對象的方法是使用GetObject（）。 其中參數第一個是遠程對象的類型 第二個參數就是服務器端的uri 如果是http通道，自然是用了。因為我是用本地機，所以這裏是localhost，你可以用具體的服務器IP地址來代替它。端口必須和服務器端的端口一致。後面則是服務器定義的遠程對象服務名，即ApplicationName屬性的內容。 (2)客戶端激活模式 如前所述，WellKnown模式在客戶端創建對象時，只能調用默認的構造函數，上面的代碼就說明了這一點，因為GetObject()方法不能傳遞構造函數的參數。而客戶端激活模式則可以通過自定義的構造函數來創建遠程對象。 客戶端激活模式有兩種方法： 1) 調用RemotingConfiguration的靜態方法RegisterActivatedClientType()。這個方法返回值為Void，它只是將遠程對象註冊在客戶端而已。具體的實例化還需要調用對象類的構造函數。
1 RemotingConfiguration.RegisterActivatedClientType( 2 typeof(ServerRemoteObject.ServerObject), 3 "tcp://localhost:8080/ServiceMessage");
1 ServerRemoteObject.ServerObject serverObj = new ServerRemoteObject.ServerObject();2) 調用進程Activator的CreateInstance()方法。這個方法將創建方法參數指定類型的類對象。它與前面的GetObject()不同的是，它要在客戶端調用構造函數，而GetObject()只是獲得對象，而創建實例是在服務器端完成的。CreateInstance()方法有很多個重載，我著重說一下其中常用的兩個。 a、 public static object CreateInstance(Type type, object[] args, object[] activationAttributes); 參數說明： type：要創建的對象的類型。 args ：與要調用構造函數的參數數量、順序和類型匹配的參數數組。如果 args 為空數組或空引用（Visual Basic 中為 Nothing），則調用不帶任何參數的構造函數（默認構造函數）。 數組。 這裏的參數args是一個object[]數組類型。它可以傳遞要創建對象的構造函數中的參數。從這裏其實可以得到一個結論：WellKnown激活模式所傳遞的遠程對象類，只能使用默認的構造函數；而Activated模式則可以用戶自定義構造函數。activationAttributes參數在這個方法中通常用來傳遞服務器的url。 假設我們的遠程對象類ServerObject有個構造函數：
1 ServerObject(string pName,string pSex,int pAge) 2 { 3 name = pName; 4 sex = pSex; 5 age = pAge; 6 }那麽實現的代碼是：
1 object[] attrs = {new UrlAttribute("tcp://localhost:8080/ServiceMessage")}; 2 object[] objs = new object[3]; 3 objs[0] = "wayfarer"; 4 objs[1] = "male"; 5 objs[2] = 28;1 ServerRemoteObject.ServerObject = Activator.CreateInstance( typeof(ServerRemoteObject.ServerObject),objs,attrs); 可以看到，objs[]數組傳遞的就是構造函數的參數。 b、public static ObjectHandle CreateInstance(string assemblyName, string typeName, object[] activationAttribute); 參數說明： assemblyName ：將在其中查找名為 typeName 的類型的程序集的名稱。如果 assemblyName 為空引用（Visual Basic 中為 Nothing），則搜索正在執行的程序集。 typeName：首選類型的名稱。 activationAttributes ：包含一個或多個可以參與激活的屬性的數組。 參數說明一目了然。註意這個方法返回值為ObjectHandle類型，因此代碼與前不同：
1 object[] attrs = {new UrlAttribute("tcp://localhost:8080/EchoMessage")}; 2 ObjectHandle handle = Activator.CreateInstance("ServerRemoteObject", 3 "ServerRemoteObject.ServerObject",attrs); 4 ServerRemoteObject.ServerObject obj = (ServerRemoteObject.ServerObject)handle.Unwrap();
這個方法實際上是調用的默認構造函數。ObjectHandle.Unwrap()方法是返回被包裝的對象。 說明：要使用UrlAttribute，還需要在命名空間中添加：using System.Runtime.Remoting.Activation;
基礎補充
通過上面的描述，基本上已經完成了一個最簡單的Remoting程序。這是一個標準的創建Remoting程序的方法，但在實際開發過程中，我們遇到的情況也許千奇百怪，如果只掌握一種所謂的“標準”，就妄想可以“一招鮮、吃遍天”，是不可能的。 1、註冊多個通道 在Remoting中，允許同時創建多個通道，即根據不同的端口創建不同的通道。但是，Remoting要求通道的名字必須不同，因為它要用來作為通道的唯一標識符。雖然IChannel有ChannelName屬性，但這個屬性是只讀的。因此前面所述的創建通道的方法無法實現同時註冊多個通道的要求。 這個時候，我們必須用到System.Collection中的IDictionary接口： 註冊Tcp通道：1 IDictionary tcpProp = new Hashtable(); 2 tcpProp["name"] = "tcp9090"; 3 tcpProp["port"] = 9090; 4 IChannel channel = new TcpChannel(tcpProp, 5 new BinaryClientFormatterSinkProvider(), 6 new BinaryServerFormatterSinkProvider()); 7 ChannelServices.RegisterChannel(channel);註冊Http通道：
1 IDictionary httpProp = new Hashtable(); 2 httpProp["name"] = "http8080"; 3 httpProp["port"] = 8080; 4 IChannel channel = new HttpChannel(httpProp, 5 new SoapClientFormatterSinkProvider(), 6 new SoapServerFormatterSinkProvider()); 7 ChannelServices.RegisterChannel(channel);
在name屬性中，定義不同的通道名稱就可以了。 2、遠程對象元數據相關性 由於服務器端和客戶端都要用到遠程對象，通常的方式是生成兩份完全相同的對象Dll，分別添加引用。不過為了代碼的安全性，且降低客戶端對遠程對象元數據的相關性，我們有必要對這種方式進行改動。即在服務器端實現遠程對象，而在客戶端則刪除這些實現的元數據。 由於激活模式的不同，在客戶端創建對象的方法也不同，所以要分離元數據的相關性，也應分為兩種情況。 (1) WellKnown激活模式： 通過接口來實現。在服務器端，提供接口和具體類的實現，而在客戶端僅提供接口：
1 public interface IServerObject 2 { 3 Person GetPersonInfo(string name,string sex,int age); 4 }
1 public class ServerObject:MarshalByRefObject,IServerObject 2 { ......}註意：兩邊生成該對象程序集的名字必須相同，嚴格地說，是命名空間的名字必須相同。 (2) 客戶端激活模式： 如前所述，對於客戶端激活模式，不管是使用靜態方法，還是使用CreateInstance()方法，都必須在客戶端調用構造函數實例化對象。所以，在客戶端我們提供的遠程對象，就不能只提供接口，而沒有類的實現。實際上，要做到與遠程對象元數據的分離，可以由兩種方法供選擇： a、利用WellKnown激活模式模擬客戶端激活模式： 方法是利用設計模式中的“抽象工廠”，下面的類圖表描述了總體解決方案： 我們在服務器端的遠程對象中加上抽象工廠的接口和實現類：
1 public interface IServerObject 2 { 3 Person GetPersonInfo(string name,string sex,int age); 4 } 5 public interface IServerObjFactory 6 { 7 IServerObject CreateInstance(); 8 } 9 public class ServerObject:MarshalByRefObject,IServerObject 10 { 11 public Person GetPersonInfo(string name,string sex,int age) 12 { 13 Person person = new Person(); 14 person .Name = name; 15 person.Sex = sex; 16 person.Age = age; 17 return person; 18 } 19 } 20 public class ServerObjFactory:MarshalByRefObject,IServerObjFactory 21 { 22 public IServerObject CreateInstance() 23 { 24 return new ServerObject(); 25 } 26 }
然後再客戶端的遠程對象中只提供工廠接口和原來的對象接口：
1 public interface IServerObject 2 { 3 Person GetPersonInfo(string name,string sex,int age); 4 } 5 public interface IServerObjFactory 6 { 7 IServerObject CreateInstance(); 8 }
我們用WellKnown激活模式註冊遠程對象，在服務器端： //傳遞對象；
1 RemotingConfiguration.RegisterWellKnownServiceType( 2 typeof(ServerRemoteObject.ServerObjFactory), 3 "ServiceMessage",WellKnownObjectMode.SingleCall);註意這裏註冊的不是ServerObject類對象，而是ServerObjFactory類對象。 客戶端：
1 ServerRemoteObject.IServerObjFactory serverFactory = 2 (ServerRemoteObject.IServerObjFactory) Activator.GetObject( 3 typeof(ServerRemoteObject.IServerObjFactory), 4 "tcp://localhost:8080/ServiceMessage"); 5 ServerRemoteObject.IServerObject serverObj = serverFactory.CreateInstance();為什麽說這是一種客戶端激活模式的模擬呢？從激活的方法來看，我們是使用了SingleCall模式來激活對象，但此時激活的並非我們要傳遞的遠程對象，而是工廠對象。如果客戶端要創建遠程對象，還應該通過工廠對象的CreateInstance()方法來獲得。而這個方法正是在客戶端調用的。因此它的實現方式就等同於客戶端激活模式。 b、利用替代類來取代遠程對象的元數據 實際上，我們可以用一個trick，來欺騙Remoting。這裏所說的替代類就是這個trick了。既然是提供服務，Remoting傳遞的遠程對象其實現的細節當然是放在服務器端。而要在客戶端放對象的副本，不過是因為客戶端必須調用構造函數，而采取的無奈之舉。既然具體的實現是在服務器端，又為了能在客戶端實例化，那麽在客戶端就實現這些好了。至於實現的細節，就不用管了。 如果遠程對象有方法，服務器端則提供方法實現，而客戶端就提供這個方法就OK了，至於裏面的實現，你可以是拋出一個異常，或者return 一個null值；如果方法返回void，那麽裏面可以是空。關鍵是這個客戶端類對象要有這個方法。這個方法的實現，其實和方法的聲明差不多，所以我說是一個trick。方法如是，構造函數也如此。 還是用代碼來說明這種“陰謀”，更直觀： 服務器端：
1 public class ServerObject:MarshalByRefObject 2 { 3 public ServerObject() 4 { 5 } 6 public Person GetPersonInfo(string name,string sex,int age) 7 { 8 Person person = new Person(); 9 person .Name = name; 10 person.Sex = sex; 11 person.Age = age; 12 return person; 13 } 14 }
客戶端：
1 public class ServerObject:MarshalByRefObject 2 { 3 public ServerObj() 4 { 5 throw new System.NotImplementedException(); 6 } 7 public Person GetPersonInfo(string name,string sex,int age) 8 { 9 throw new System.NotImplementedException(); 10 } 11 }
比較客戶端和服務器端，客戶端的方法GetPersonInfo()，沒有具體的實現細節，只是拋出了一個異常。或者直接寫上語句return null，照樣OK。我們稱客戶端的這個類為遠程對象的替代類。 3、利用配置文件實現 前面所述的方法，於服務器uri、端口、以及激活模式的設置是用代碼來完成的。其實我們也可以用配置文件來設置。這樣做有個好處，因為這個配置文件是Xml文檔。如果需要改變端口或其他，我們就不需要修改程序，並重新編譯，而是只需要改變這個配置文件即可。 (1) 服務器端的配置文件： <configuration> <system.runtime.remoting> <application name="ServerRemoting"> <service> <wellknown mode="Singleton" type="ServerRemoteObject.ServerObject" objectUri="ServiceMessage"/> </service> <channels> <channel ref="tcp" port="8080"/> </channels> </application> </system.runtime.remoting> </configuration> 如果是客戶端激活模式，則把wellknown改為activated，同時刪除mode屬性。 把該配置文件放到服務器程序的應用程序文件夾中，命名為ServerRemoting.config。那麽前面的服務器端程序直接用這條語句即可： RemotingConfiguration.Configure("ServerRemoting.config"); (2)客戶端配置文件 如果是客戶端激活模式，修改和上面一樣。調用也是使用RemotingConfiguration.Configure()方法來調用存儲在客戶端的配置文件。 配置文件還可以放在machine.config中。如果客戶端程序是web應用程序，則可以放在web.config中。 4、啟動/關閉指定遠程對象 Remoting中沒有提供類似UnregisterWellKnownServiceType()的方法，也即是說，一旦通過註冊了遠程對象，如果沒有關閉通道的話，該對象就一直存在於通道中。只要客戶端激活該對象，就會創建對象實例。如果Remoting傳送的只有一個遠程對象，這不存在問題，關閉通道就可以了。如果傳送多個遠程對象呢？要關閉指定的遠程對象應該怎麽做？關閉之後又需要啟動又該如何？ 我們註意到在Remoting中提供了Marshal()和Disconnect()方法，答案就在這裏。Marshal()方法是將MarshalByRefObject類對象轉化為ObjRef類對象，這個對象是存儲生成代理以與遠程對象通訊所需的所有相關信息。這樣就可以將該實例序列化以便在應用程序域之間以及通過網絡進行傳輸，客戶端就可以調用了。而Disconnect()方法則將具體的實例對象從通道中斷開。 方法如下： 首先註冊通道： TcpChannel channel = new TcpChannel(8080); ChannelServices.RegisterChannel(channel); 接著啟動服務： 先在服務器端實例化遠程對象。 ServerObject obj = new ServerObject(); 然後，註冊該對象。註意這裏不用RemotingConfiguration.RegisterWellKnownServiceType()，而是使用RemotingServices.Marshal()： ObjRef objrefWellKnown = RemotingServices.Marshal(obj, "ServiceMessage"); 如果要註銷對象，則： RemotingServices.Disconnect(obj); 要註意，這裏Disconnect的類對象必須是前面實例化的對象。正因為此，我們可以根據需要創建指定的遠程對象，而關閉時，則Disconnect之前實例化的對象。 至於客戶端的調用，和前面WellKnown模式的方法相同，仍然是通過Activator.GetObject()來獲得。但從實現代碼來看，我們會註意到一個問題，由於服務器端是顯式的實例化了遠程對象，因此不管客戶端有多少，是否相同，它們調用的都是同一個遠程對象。因此我們將這個方法稱為模擬的SingleTon模式。 客戶端激活模式 我們也可以通過Marshal()和Disconnect()來模擬客戶端激活模式。首先我們來回顧“遠程對象元數據相關性”一節，在這一節中，我說到采用設計模式的“抽象工廠”來創建對象實例，以此用SingleCall模式來模擬客戶端激活模式。在仔細想想前面的模擬的SingleTon模式。是不是答案就將呼之欲出呢？ 在“模擬的SingleTon”模式中，我們是將具體的遠程對象實例進行Marshal，以此讓客戶端獲得該對象的引用信息。那麽我們換一種思路，當我們用抽象工廠提供接口，工廠類實現創建遠程對象的方法。然後我們在服務器端創建工廠類實例。再將這個工廠類實例進行Marshal。而客戶端獲取對象時，不是獲取具體的遠程對象，而是獲取具體的工廠類對象。然後再調用CreateInstance()方法來創建具體的遠程對象實例。此時，對於多個客戶端而言，調用的是同一個工廠類對象；然而遠程對象是在各個客戶端自己創建的，因此對於遠程對象而言，則是由客戶端激活，創建的是不同對象了。 當我們要啟動/關閉指定對象時，只需要用Disconnet()方法來註銷工廠類對象就可以了。
.Net中Remoting通信機制