共用方式為


.NET Framework 遠端處理架構

本主題專門說明一項為了在現有應用程式中提供回溯相容性而保留的舊有技術,不建議用於新的開發工作。分散式應用程式應使用 Windows Communication Foundation (WCF) 進行開發。

.NET 遠端處理基礎結構是一種抽象的處理序通訊方式。可以經由值傳遞或複製的物件,會自動傳遞到不同的應用程式定義域或不同的電腦上的應用程式之間。請讓您的自訂類別可序列化,以便讓此功能順利運作。

然而,遠端處理系統的真正優勢在於它能夠讓位於不同應用程式定義域或處理序的物件,透過不同的傳輸通訊協定、序列化格式、物件存留期結構描述,與物件建立模式彼此進行通訊。此外,遠端處理功能幾乎在所有的通訊處理序階段中都可以介入運作。

不管您是否實作了許多分散式應用程式,還是對將元件移動到其他電腦以增加程式延展性比較感興趣,您很容易了解遠端處理系統是一種處理序之間的泛型通訊系統,而且只要實作一些預設設定,就可以輕鬆處理大部分的情況。下列將優先討論透過遠端處理在處理序之間進行通訊的基本概念。

複本和參考的比較

要進行跨處理序通訊時,必須將伺服器物件的功能提供給其處理序以外的呼叫端、讓用戶端呼叫伺服器物件,並啟用傳輸機制以將呼叫在兩者之間互相傳遞。伺服器方法的位址為邏輯位址,只能在單一處理序中正常運作,而無法在不同的用戶端處理序中運作。用戶端可以呼叫伺服器物件來減輕這個問題的影響,方法是製作物件的完整複本並將其移至用戶端處理序中,讓複本的方法能夠直接叫用。

然而,您無法亦不應該將許多物件複製並移至其他的處理序中加以執行。您不應該將包含許多方法的超大型物件複製或使用值傳遞到其他處理序中。一般來說,用戶端只需要具備伺服器物件上一或少數方法所傳回的資訊。複製整個伺服器物件,包括可能與用戶端需求無關的大量內部資訊或可執行結構,不只浪費頻寬與用戶端記憶體,也會浪費一些處理時間。此外,許多物件會公開公共功能,但是需要私人資料來進行內部執行作業。複製這些物件會導致未授權的用戶端能夠檢查內部資料而產生潛在的安全問題。最後,有些物件會透過任何可理解的方式,使用無法複製的資料。例如,FileInfo 物件包含了作業系統檔案的參考,且內含對伺服器處理序之記憶體的唯一位址。您可以複製此位址,但是將無法用於其他處理序中。

在這些情況中,伺服器處理序會將伺服器物件參考 (而不是物件複本) 傳遞至用戶端處理序中。用戶端可以使用此參考來呼叫伺服器物件。這些呼叫不會在用戶端處理序中執行。反之,遠端處理系統會收集與呼叫有關的所有資訊並傳遞給伺服器處理序,在經過解譯後找到正確的伺服器物件,之後就會以用戶端物件的身份對伺服器物件進行呼叫。然後,呼叫的結果會傳送到用戶端處理序,以便接著傳回到用戶端。只有在傳遞重要資訊時才會用到頻寬,比如說呼叫、呼叫引數,以及任何傳回的值或是例外。

簡化的遠端處理架構

遠端處理的最重要任務,就是在伺服器物件與用戶端之間使用物件參考來進行通訊。然而,遠端處理架構卻提供程式設計人員一個較為基本的程序。如果您已經妥善設定好用戶端,只需使用 new (或是來自 Managed 程式設計語言中的執行個體建立函式) 來建立遠端物件的新執行個體。您的用戶端會收到伺服器物件的參考,而您只需呼叫其方法 (就像物件已經位於處理序中),而不用在另一部電腦上個別執行。遠端處理系統會使用 Proxy 物件來建立伺服器物件好像位於用戶端處理序中的印象。Proxy 物件會將自己當成其他某些物件。當您的用戶端建立遠端型別的執行個體,遠端處理基礎結構會建立一個看起來與用戶端遠端型別一模一樣的 Proxy 物件。您的用戶端會呼叫該 Proxy 的方法,而遠端處理系統會收到該呼叫並將其送到伺服器處理序中,接著叫用伺服器物件並將傳回值傳回用戶端 Proxy,並透過此 Proxy 將結果傳回用戶端。

遠端呼叫必須以某種方式在用戶端與伺服器處理序之間互相傳達。如果您想要自行建置遠端處理系統,可以先從網路程式設計、廣泛的通訊協定,以及序列化格式規格等項目開始著手學習。在 .NET 遠端處理系統中,結合開啟網路連線所需的各項基礎技術,以及使用特定通訊協定來傳送位元組給接收方應用程式,統稱為傳輸通道。

通道這種型別可接收資料流、依據特定網路通訊協定建立套件,並將套件傳送至另一部電腦上。某些通道只能接收資訊,其他通道則只能傳送資訊,但是仍舊有一些通道 (例如預設的 TcpChannelHttpChannel 類別) 可以雙向進行接收與傳送。

儘管伺服器處理序熟悉每個唯一型別的所有內容,用戶端只知道它想要參考另一個應用程式定義域 (也許位於另一部電腦上) 中的物件。URL 會從伺服器應用程式定義域以外的世界找到物件。啟動 URL 就是代表外界唯一型別的 URL,用來確保您已對適當型別進行遠端呼叫。如需詳細資訊,請參閱啟動 URL

完整的遠端處理系統設計

假設您在某部電腦上執行應用程式,而您想要使用儲存在另一部電腦上的型別所公開的功能。下圖顯示泛型遠端處理序。

.NET 遠端處理架構

如果兩邊的關係都設定妥當,則用戶端只需建立伺服器類別的新執行個體。遠端處理系統會建立用來表示類別的 Proxy 物件,並將該 Proxy 的參考傳回給用戶端物件。當用戶端呼叫方法,遠端處理基礎結構會處理呼叫、檢查型別資訊,並透過通道將呼叫傳送到伺服器處理序中。接聽通道收到要求後,會將其轉送給伺服器遠端處理系統,讓其找到 (必要時建立) 並呼叫要求的物件。這時處理序會逆轉,而且伺服器遠端處理系統會將回應全部放到訊息中,並經由伺服器通道將此訊息傳送到用戶端通道。最後,用戶端遠端處理系統會將呼叫結果經由 Proxy 傳回到用戶端物件上。

雖然這項作業所需的程式碼內容實際上非常簡單,還是得注意一下關係的設計與組態。只要當中有任何一項 URL 或通訊埠編號不正確,就算程式碼本身完全正確,執行時還是會失敗。如需詳細資訊,請參閱組態

雖然這項高階的遠端處理序概述非常簡單扼要,較低階的詳細資料卻可能相當複雜。我們將於下列「請參閱」各節中提供有關主要遠端處理項目的進一步討論。

另請參閱

概念

界限:處理序和應用程式定義域
可遠端處理和不可遠端處理的物件
通道
遠端處理中的安全性
遠端應用程式的組態

其他資源

.NET Framework 遠端處理概觀
物件啟動與存留期