【文章內(nèi)容簡介】 括了TcpChannel通道類型和Http通道類型。它們分別對應(yīng)Remoting通道的這兩種類型。Tcp通道提供了基于Socket 的傳輸工具，使用Tcp協(xié)議來跨越Remoting邊界傳輸序列化的消息流。TcpChannel類型默認(rèn)使用二進(jìn)制格式序列化消息對象，因此它具有更高的傳輸性能。它提供了一種使用 Http協(xié)議，使其能在Internet上穿越防火墻傳輸序列化消息流。默認(rèn)情況下，HttpChannel類型使用Soap格式序列化消息對象，因此它具有更好的互操作性。通常在局域網(wǎng)內(nèi)，我們更多地使用TcpChannel；如果要穿越防火墻，則應(yīng)該使用HttpChannel比較好。 .NET Remoting的激活方式在訪問遠(yuǎn)程類型的一個對象實(shí)例之前，必須通過一個名為Activation的進(jìn)程創(chuàng)建它并進(jìn)行初始化。這種客戶端通過通道來創(chuàng)建遠(yuǎn)程對象，稱為對象的激活。在Remoting中，遠(yuǎn)程對象的激活分為兩大類：服務(wù)器端激活和客戶端激活。服務(wù)器端激活，又叫做WellKnow方式。服務(wù)器應(yīng)用程序在激活對象實(shí)例之前會在一個眾所周知的統(tǒng)一資源標(biāo)識符(URI)上來發(fā)布這個類型。然后該服務(wù)器進(jìn)程會為此類型配置一個WellKnown對象，并根據(jù)指定的端口或地址來發(fā)布對象?？蛻舳思せ?。與WellKnown模式不同， Remoting在激活每個對象實(shí)例的時候，會給每個客戶端激活的類型指派一個URI?？蛻舳思せ钅Ｊ揭坏┇@得客戶端的請求，將為每一個客戶端都建立一個實(shí)例引用。SingleCall模式和客戶端激活模式是有區(qū)別的：首先，對象實(shí)例創(chuàng)建的時間不一樣?？蛻舳思せ罘绞绞强蛻粢坏┌l(fā)出調(diào)用的請求，就實(shí)例化；而SingleCall則是要等到調(diào)用對象方法時再創(chuàng)建。其次，SingleCall模式激活的對象是無狀態(tài)的，對象生命期的管理是由GC管理的，而客戶端激活的對象則有狀態(tài)，其生命周期可自定義。其三，兩種激活模式在服務(wù)器端和客戶端實(shí)現(xiàn)的方法不一樣。尤其是在客戶端，SingleCall模式是由 GetObject()來激活，它調(diào)用對象默認(rèn)的構(gòu)造函數(shù)。而客戶端激活模式，則通過CreateInstance()來激活，它可以傳遞參數(shù)，所以可以調(diào)用自定義的構(gòu)造函數(shù)來創(chuàng)建實(shí)例。 .NET Remoting的對象定義前面講到，客戶端在獲取服務(wù)器端對象時，并不是獲得實(shí)際的服務(wù)端對象，而是獲得它的引用。因此在Remoting中，對于遠(yuǎn)程對象有一些必須的定義規(guī)范要遵循。由于Remoting傳遞的對象是以引用的方式，因此所傳遞的遠(yuǎn)程對象類必須繼承MarshalByRefObject。MSDN對 MarshalByRefObject的說明是：MarshalByRefObject 是那些通過使用代理交換消息來跨越應(yīng)用程序域邊界進(jìn)行通信的對象的基類。不是從 MarshalByRefObject 繼承的對象會以隱式方式按值封送。當(dāng)遠(yuǎn)程應(yīng)用程序引用一個按值封送的對象時，將跨越遠(yuǎn)程處理邊界傳遞該對象的副本。因為您希望使用代理方法而不是副本方法進(jìn)行通信，因此需要繼承MarshallByRefObject。在Remoting中能夠傳遞的遠(yuǎn)程對象可以是各種類型，包括復(fù)雜的DataSet對象，只要它能夠被序列化。遠(yuǎn)程對象也可以包含事件，但服務(wù)器端對于事件的處理比較特殊，我將在本系列之三中介紹。 補(bǔ)充 注冊多個信道 在Remoting中，允許同時創(chuàng)建多個通道，即根據(jù)不同的端口創(chuàng)建不同的通道。但是，Remoting要求通道的名字必須不同，因為它要用來作為通道的唯一標(biāo)識符。雖然IChannel有ChannelName屬性，但這個屬性是只讀的。因此前面所述的創(chuàng)建通道的方法無法實(shí)現(xiàn)同時注冊多個通道的要求。 客戶端訂閱服務(wù)器事件實(shí)際上，我們可以用一個trick，來欺騙Remoting。這里所說的替代類就是這個trick了。既然是提供服務(wù)，Remoting傳遞的遠(yuǎn)程對象其實(shí)現(xiàn)的細(xì)節(jié)當(dāng)然是放在服務(wù)器端。而要在客戶端放對象的副本，不過是因為客戶端必須調(diào)用構(gòu)造函數(shù)，而采取的無奈之舉。既然具體的實(shí)現(xiàn)是在服務(wù)器端，又為了能在客戶端實(shí)例化，那么在客戶端就實(shí)現(xiàn)這些好了。至于實(shí)現(xiàn)的細(xì)節(jié)，就不用管了。如果遠(yuǎn)程對象有方法，服務(wù)器端則提供方法實(shí)現(xiàn)，而客戶端就提供這個方法就OK了，至于里面的實(shí)現(xiàn)，你可以是拋出一個異常，或者return 一個null值；如果方法返回void，那么里面可以是空。關(guān)鍵是這個客戶端類對象要有這個方法。這個方法的實(shí)現(xiàn)，其實(shí)和方法的聲明差不多，所以我說是一個trick。方法如是，構(gòu)造函數(shù)也如此。 小結(jié)本章從 .NET Remoting技術(shù)的定義、 .NET Remoting技術(shù)的主要元素、通道及激活方式對這個 .NET Remoting技術(shù)進(jìn)行了詳細(xì)的介紹，最后補(bǔ)充說明注冊信道方法，有利于理解這個技術(shù)， Remoting技術(shù)構(gòu)建框架，解決實(shí)際的復(fù)雜問題。第4章 .NET Remoting框架的構(gòu)建第4章 .NET Remoting框架的構(gòu)建 Remoting技術(shù)有了一定的了解之后， Remoting框架的構(gòu)建了。 創(chuàng)建遠(yuǎn)程對象類客戶端在獲取服務(wù)器端對象時，并不是獲得實(shí)際的服務(wù)端對象，而是獲得它的引用。因此在Remoting中，對于遠(yuǎn)程對象有一些必須的定義規(guī)范要遵循。由于Remoting傳遞的對象是以引用的方式，因此所傳遞的遠(yuǎn)程對象類必須繼承MarshalByRefObject。MarshalByRefObject 是那些通過使用代理交換消息來跨越應(yīng)用程序域邊界進(jìn)行通信的對象的基類。不是從 MarshalByRefObject 繼承的對象會以隱式方式按值封送。當(dāng)遠(yuǎn)程應(yīng)用程序引用一個按值封送的對象時，將跨越遠(yuǎn)程處理邊界傳遞該對象的副本。這里我需要使用代理方法而不是副本方法進(jìn)行通信，因此需要繼承MarshallByRefObject。public delegate void MyDelegate(string msg)。public class NetRmtObject : MarshalByRefObject { public event MyDelegate SubscribeAtServer。//在客戶端觸發(fā),在服務(wù)器訂閱的事件 public event MyDelegate SubscribeAtClient。//在服務(wù)器觸發(fā),在客戶端訂閱的事件//無限生命周期public override object InitializeLifetimeService() { return null。}//服務(wù)器觸發(fā)事件public void TriggerAtClient(string msg) { if (SubscribeAtServer != null) SubscribeAtServer(msg)。}//客戶端觸發(fā)事件public void TriggerAtServer(string msg) { if (SubscribeAtClient != null) SubscribeAtClient(msg)。}//獲取委托列表public Delegate[] GetServerEventList() { return ()。}} 服務(wù)器端 確定使用的信道 .NET Remoting提供了三種預(yù)定義的信道：TCP、HTTP、IPC，他們各有自己的特點(diǎn)，根據(jù)自己需要進(jìn)行選擇。對于每個信道，都有一些可以配置的信息。 注冊信道 注冊信道就是把已經(jīng)創(chuàng)建的信道，使用ChannelServices類的RegisterChannel方法來“向信道服務(wù)注冊信道”。//信道端口IDictionary idic = new Dictionarystring, int()。idic[port] = 8080。//注冊信道TcpChannel tcpchannel = new TcpChannel(idic, clientProvider, serverProvider)。(tcpchannel, false)。 注冊遠(yuǎn)程對象服務(wù)器端打算發(fā)布一個可以被客戶端調(diào)用的遠(yuǎn)程對象，那它必須以某種方式“告訴”系統(tǒng)：我這里有一個這樣的服務(wù)可供你使用。這里的“告訴”的過程，就是注冊遠(yuǎn)程對象。CityObject marshal_city_obj。NetRmtObject marshal_obj。//服務(wù)器獲取遠(yuǎn)程對象marshal_obj = new NetRmtObject()。//傳輸string類型變量的對象ObjRef objRef = (marshal_obj, url)。marshal_city_obj = new CityObject()。//傳輸DataTable類型變量的對象ObjRef cityObjRef = (marshal_city_obj, url1)。 注銷信道 在程序關(guān)閉時，或者清理資源時，要關(guān)閉調(diào)已經(jīng)注冊的信道，這樣好讓出服務(wù)所使用的計算機(jī)端口。 客戶端 創(chuàng)建、注冊信道客戶端的信道注冊，跟服務(wù)器端的注冊基本相同，差別在于它不必指定端口，和服務(wù)器端對應(yīng)的，則使用TcpClientChannel、HttpClientChannel類等，當(dāng)然也可以使用TcpChannel、HttpChannel類來注冊。在創(chuàng)建了信道后，也是使用ChannelServices類的RegisterChannel方法來完成信道的注冊。//信道端口IDictionary idic = new Dictionarystring, int()。idic[port] = 0。//注冊信道TcpChannel tcpchannel = new TcpChannel(idic, clientProvider, serverProvider)。(tcpchannel, false)。 客戶端的端口號不能與服務(wù)器一致，否則將出現(xiàn)通常每個套接字地址(協(xié)議/網(wǎng)絡(luò)地址/端口)只允許使用一次的異常，將其設(shè)置為0，則客戶端自動選擇可用的端口。 發(fā)現(xiàn)URL客戶端要激活服務(wù)器上的遠(yuǎn)程對象，也就是說要獲得一個遠(yuǎn)程對象的本地代理，則必須首先獲得遠(yuǎn)程對象的URL。該URL和Web瀏覽器的URL具有一樣的含義，具有如下的格式：Protocol://server:port/URI這里的協(xié)議，也就是信道的格式，如tcp、ipc。不過，由于IPC機(jī)制只能使用在單個機(jī)器上，因此，不需要使用服務(wù)器地址。 創(chuàng)建對象與獲取遠(yuǎn)程對象代理創(chuàng)建對象，也就是在客戶端激活服務(wù)器上的對象，并獲得這個遠(yuǎn)程對象的一個本地代理（透明代理）。在客戶端創(chuàng)建遠(yuǎn)程對象，有兩種方法，一種是使用new方法來創(chuàng)建，另外一種方法則是使用激活類的Activator的創(chuàng)建方法。//獲取代理try { obj = (NetRmtObject)(typeof(NetRmtObject), tcp:// + + :8080/url)。 city_obj = (CityObject)(typeof(CityObject), tcp:// + + :8080/url1)。 if (obj == null || city_obj == null) { (連接失敗!!)。 return。 } } catch (Exception ex) { ()。 } 注銷信道 客戶端的信道注銷和服務(wù)器端是一樣的，這里就不再做過多說明。 事件調(diào)用 服務(wù)器注冊客戶端事件服務(wù)器注冊客戶端事件，相對客戶端注冊服務(wù)器事件來說，是比較簡單的。因為，客戶端在調(diào)用服務(wù)器上的遠(yuǎn)程對象時，代碼都在服務(wù)器上執(zhí)行，服務(wù)器很容易截獲這一事件，從而進(jìn)行自己的處理。具體的實(shí)現(xiàn)思路是，在遠(yuǎn)程對象中定義一個事件，然后在某方法內(nèi)部，調(diào)用該事件的處理函數(shù)，這樣，在客戶端調(diào)用該方法時，就觸發(fā)了事件。//服務(wù)器綁定客戶端觸發(fā)的事件 += new MyDelegate(marshal_obj_SubscribeAtServer)。 客戶端注冊服務(wù)器事件客戶端注冊服務(wù)器上的事件，是個畢竟復(fù)雜的過程。剛開始的時候，以為和服務(wù)器注冊客戶端事件是一樣的，但是實(shí)踐的時候發(fā)生錯誤，再仔細(xì)思考一下，發(fā)現(xiàn)客戶端注冊服務(wù)器事件和服務(wù)器端注冊客戶端事件是完全不同的。在服務(wù)器注冊客戶端事件時，只要客戶端激活了遠(yuǎn)程對象，就可以發(fā)送消息，而只要服務(wù)器訂閱了此事件，就可以處理客戶端的消息了。在激活遠(yuǎn)程對象前，服務(wù)所做必須做的是“注冊”該遠(yuǎn)程對象類以給客戶端提供服務(wù)，然后由客戶端決定何時來創(chuàng)建一個遠(yuǎn)程對象，也就是說，服務(wù)器端沒有顯式的創(chuàng)建過遠(yuǎn)程對象，這樣，既然服務(wù)器端沒有顯式的對象，那么又如何來顯式的操作之以傳遞消息呢？客戶端的使用的遠(yuǎn)程對象只是一個代理，和服務(wù)器上的遠(yuǎn)程對象處于完全不同的應(yīng)用程序域，或者說，服務(wù)器上的對象和客戶端的對象是具有相似性但完全不同的兩個“物體”，因此，在服務(wù)器端，或者是在客戶端對各自對象所做的操作，是不會互相影響的。這同樣也說明了在服務(wù)器端注冊對象后顯式創(chuàng)建一個對象的思路也并不可行?？蛻舳艘嗛喎?wù)器事件，那么事件處理程序向?qū)ο蟮淖詣幼?，也就?yīng)該在客戶端完成，而服務(wù)器端還需逐個調(diào)用各個客戶端注冊的處理程序，這就要求客戶端和服務(wù)器端所操作的對象是“同一個”。這樣，為了實(shí)現(xiàn)客戶端注冊客戶端事件，必須讓遠(yuǎn)程對象具有的特征也就很明顯了：客戶端得到的遠(yuǎn)程對象實(shí)際上是服務(wù)器上對象的代理。也就是說：客戶端獲取的那個代理對象，用它來訂閱服務(wù)器的事件是訂閱不到的。服務(wù)器端觸發(fā)事件是遠(yuǎn)程對象里的事件，遠(yuǎn)程對象想要被客戶端訪問就必須被序列化，原因就在于事件是基于委托的。