Remoting技術

一 Remoting技術出現的背景

1)分佈式應用需求的迅速增長(Peer-to-Peer, Grid等技術的出現)

2)原有的C/S, B/S模式和技術已經不能勝任(串口RS232, Socket, RPC, DCOM 技術各有缺點)

二 什麼是Romoting?

採用分佈式進行編程的一種技術,Remoting主要用於管理跨應用程序域的同步和異步RPC 會話。在默認情況下,Remoting使用 HTTP 或 TCP 協議,並使用 XML 編碼的 SOAP 或本機二進制消息格式進行通信。.NET Remoting 提供了非常靈活和可擴展的編程框架,並且他可以管理對象的狀態。

Remoting優點

1) 性能: 如果調優.Net Remoting 的性能,那麼他的性能非常好,速度接近DCOM.

2) 可擴展:.Net Remoting 可供你選擇傳輸通道類型(如Http,Tcp)和格式類型(如Binary,Soap)。

3) 可配置:可以通過配置文件配置應用程序。

4) CLR和CTS的好處:由於.NET Remoting是基於.NET框架的,所以他擁有Common Type System(CTS) 和 Common Language Runtime(CLR)所擁有的易於使用和功能強大的特點。

5)互用性(Interoperability): .NET Remoting 支持開發標準(Http,SOAP,WSDL,XML).

6) 安全性

7) 生命週期管理

三 Remoting架構:

Remoting通過通道(channel)來傳輸消息。.NET Remoting支持兩種默認的協議支持通道(Http和Tcp).

 

 

四 遠程對象的兩個含義

 操作遠程對象:對象運行在遠程,客戶端向他發送消息.

傳遞遠程對象:將遠程的對象拿到本地,或者將本地對象發送過去,然後我們可以對副本進行操作.

五 激活對象的兩種方式:服務器激活和客戶端激活

1 服務器激活:“服務器激活的對象”是由服務器控制生存期的對象。它們只在客戶端調用對象的第一個方法時,根據需要由服務器創建。服務器激活的對象只支持默認的構造函數。

代碼:

None.gif<service>

None.gif  <wellknown mode="SingleCall" type="Hello.HelloService, Hello"

None.gif                    objectUri="HelloService.soap" />

None.gif</service>

None.gif

上面描述了一個服務器激活的 (wellknown) 類型,其激活方式設置爲 SingleCall。

服務器激活的對象有兩種激活模式:Singleton 和 SingleCall.

1) Singleton(單實例):

這些對象遵循傳統的Singleton 設計模式,在這種模式中,任何時候內存中都只有一個實例,所有客戶端都接受該實例提供的服務。

特點:

a.在服務器段只實例化一次,以後每次調用都訪問同一個實例。

b.可以維持狀態

2) SingleCall(單調用)

SingleCall 遠程服務器類型總是爲每個客戶端請求設置一個實例。下一個方法調用將改由其他實例進行服務。從設計角度看,SingleCall 類型提供的功能非常簡單。這種機制不提供狀態管理,如果您需要狀態管理,這將是一個不利之處;如果您不需要,這種機制將非常理想。也許您只關心負載平衡和 可伸縮性而不關心狀態,那麼在這種情況下,這種模式將是您理想的選擇,因爲對於每個請求都只有一個實例。如果願意,開發人員可以向 SingleCall 對象提供自己的狀態管理,但這種狀態數據不會駐留在對象中,因爲每次調用新的方法時都將實例化一個新的對象標識。

特點:

a.每次調用都實例化新的實例

b.更好地支持無狀態編程模型

2 客戶端激活

“客戶端激活的對象”是當客戶端調用 new 或 Activator.CreateInstance() 時在服務器上創建的。

代碼:

None.gif<service>

None.gif  <activated type="Hello.HelloService, Hello"

None.gif              objectUri="HelloService.soap" />

None.gif</service>

None.gif

上面描述了一個客戶端激活的類型。請注意,我們不再需要 URL,因爲對於客戶端激活的類型,類型本身就足以激活了。另外,wellknown 標記已被 activated 標記替代。

六 Remoting VS Web Service

兩者都是基於分佈式的開發,而且.Net Remoting有時也可以配置爲Web Service,兩者有很多的相同之處。一般來講,我把他們的不同之處列爲5個方面。

1) 開發部署

WebService開發和部署比較簡單,Remoting相對WebService開發和部署要稍複雜。

2) 協議的開放性 

     兩者都可支持HTTP,TCP,SMTP等多種協議。

    [一直以爲WebService只支持HTTP協議,經idior指點,原來在Web Services Enhancements已有介紹,WebService也支持TCP,SMTP等協議。微軟最新發布的wse應該是wse 3.0,以前還沒聽說過,真是汗顏!]

   更詳細的內容待續...

3) 支持的類型系統

WebService只支持XSD類型系統,對象的類型的序列化受到限制,而Remoting可以通過序列化爲Binary傳輸數據,支持更爲廣泛的數據類型

4) 安全性

由 於 ASP.NET Web 服務依賴於 HTTP,因此它們與標準的 Internet 安全性基礎結構相集成。ASP.NET 利用 IIS 的安全性功能,爲標準 HTTP 驗證方案(包括基本、簡要、數字證書,甚至 Microsoft .NET Passport)提供了強有力的支持。

一般情況下,.NET Remoting 管線不能確保跨進程調用的安全。使用 ASP.NET 託管於 IIS 中的 .NET Remoting 端點可以利用 ASP.NET Web 服務可用的所有安全性功能,包括對使用 SSL 確保有線通信的安全性的支持。

5) 性能

從原始性能方面來講,使用 TCP 信道和二進制格式化程序時,.NET Remoting 管線能夠提供最快的通信。一般情況下,.NET Remoting的性能要比WebService高。

根據需求,我們的系統必須以C/S方式構建,而且是三層架構,這樣一來,就出現了服務器端和客戶端通信的問題。      



       爲了解決雙方的通信問題,還要考慮效率、性能等方面,經過分析、試驗,我們根據效率、移植、開發難易等幾個因素,捨棄了一開始提出的WebService、消息隊列機制,以及有人建議的基於流I/O自己解析數據的通信方式,在分析了目前主流的RPC方式(DCOM、CORBA、.NET Remoting)及我們的開發平臺後,最終選擇了微軟新推出的.NET Remoting機制。我們的原因如下:

       1、.NET Remoting是目前分佈式對象實現RPC的一種主要方式。

       2、.NET Remtoing在性能上可以達到DCOM,或者與之相差不多。

       3、.NET Remoting建立在.NET定義的公共數據類型CTS及運行環境CLR之上,和.NET框架有着很好的互操作性,因此功能強大切易於使用。

       4、擴展性和安全性方面都比較好。



       從試驗結果來看,該機制可以實現C/S模式下的雙方通信,而且在性能上具有很好的保障。根據我們開發完畢的系統性能來看,Remoting機制很好的實現了我們賦予它的任務,或者說,我們採用Remoting機制達到了我們預期的目標。



       下面,對我們採用Remoting機制進行開發這一從無到有過程中的一些資料、感悟進行整理。


基本概念

       .NET Remoting是微軟隨.NET推出的一種分佈式應用解決方案,被譽爲管理應用程序域之間的 RPC 的首選技,它允許不同應用程序域之間進行通信(這裏的通信可以是在同一個進程中進行、一個系統的不同進程間進行、不同系統的進程間進行)。



       更具體的說,Microsoft .NET Remoting 提供了一種允許對象通過應用程序域與另一對象進行交互的框架。也就是說,使用.NET Remoting,一個程序域可以訪問另外一個程序域中的對象,就好像這個對象位於自身內部,只不過,對這個遠程對象的調用,其代碼是在遠程應用程序域中進行的,例如在本地應用程序域中調用遠程對象上一個會彈出對話框的方法,那麼,這個對話框,則會在遠程應用程序域中彈出。



.NET Remoting框架提供了多種服務,包括激活和生存期支持,以及負責與遠程應用程序進行消息傳輸的通訊通道。格式化程序用於在消息通過通道傳輸之前,對其進行編碼和解碼。應用程序可以在注重性能的場合使用二進制編碼,在需要與其他遠程處理框架進行交互的場合使用 XML 編碼。在從一個應用程序域向另一個應用程序域傳輸消息時,所有的 XML 編碼都使用 SOAP 協議。出於安全性方面的考慮,遠程處理提供了大量掛鉤,使得在消息流通過通道進行傳輸之前,安全接收器能夠訪問消息和序列化流。


一般來說,.NET Remoting包括如下幾點主要元素:

Ø         遠程對象:運行在Remoting服務器上的對象。客戶端通過代理對象來間接調用該對象的服務,如上圖的“通信體系結構”所示。在.NET Remoting體系中,要想成爲遠程對象提供服務,該對象的類必須是MarshByRefObject的派生對象。另外,要說明的是,需要在網絡上傳遞的對象,例如“參數”,則必須是可序列化的。

Ø         信道:信道是服務器和客戶機進行通信用的(這裏的服務器和客戶機並不一定都是計算機,也可能是進程)。在.NET Remoting中,提供了三種信道類型:TCP、HTTP、IPC,另外,也可以定製不同的信道以適應不同的通信協議(至於如何定製,我尚未涉及到,因此,不好說)。

Ø         消息:客戶機和服務器通過消息進行信息交換,消息在信道中傳遞。這裏的消息包括,遠程對象的信息,調用方法名稱,參數,返回值等。

Ø         格式標識符:該標識符標明瞭消息是按照什麼樣的格式被髮送到信道上的,目前.NET 2.0提供了兩種格式標識符:SOAP格式和二進制格式。SOAP格式標識符符合SOAP標準,比較通用,可以和非.NET 框架的Web服務通信。二進制格式標識符,則在速度、效率上面更生一籌,但通用性較SOAP差。另外,Remoting還支持自定義的格式標識符。(順便說一下:TCP信道,默認使用二進制格式傳輸,因爲這個效率更高;Http信道則默認使用SOAP格式;不過在系統中,哪種信道具體使用哪種格式,則是可以根據需要設置的。)。

Ø         格式標識符提供程序:它用於把格式標識符和信道聯繫起來。在創建信道時,可以指定所要使用的標識符提供程序,一旦指定了提供程序,那麼消息被髮送到信道上的格式也就確定了下來。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章