傳統(tǒng)的方法調(diào)用是通過棧實現(xiàn)，調(diào)用方法前將this指針以及方法參數(shù)壓入線程棧中，線程執(zhí)行方法時將棧中的參數(shù)取出作為本地變量，經(jīng)過一番計算后，將方法的返回結(jié)果壓入棧中。這樣我們就完成了一次方法調(diào)用。如下圖所示：

　　基于棧的方法調(diào)用在同一個應(yīng)用程序域中很容易實現(xiàn)，但是如果要調(diào)用的方法所屬的對象位于另一個應(yīng)用程序域或另一個進(jìn)程甚至是另一個機(jī)器，又當(dāng)如何?應(yīng)用程序域之間是無法共享同一個線程棧的，此時我們將轉(zhuǎn)而使用另一種方法調(diào)用機(jī)制——基于消息的方法調(diào)用機(jī)制。在客戶端通過代理對象將原先基于棧的方法調(diào)用信息(定位遠(yuǎn)程對象的信息、方法名、方法參數(shù)等)封裝到一個消息對象中，再根據(jù)需要將這些消息對象轉(zhuǎn)化成某個格式的數(shù)據(jù)流發(fā)送到遠(yuǎn)程對象所在的的應(yīng)用程序域中。

　　當(dāng)經(jīng)過格式化的消息到達(dá)服務(wù)器后，首先從中還原出消息對象，之后在遠(yuǎn)程對象所在的的應(yīng)用程序域中構(gòu)建出相應(yīng)方法調(diào)用棧，此時就可以按照傳統(tǒng)的基于棧的方法調(diào)用機(jī)制完成方法的調(diào)用，而方法返回結(jié)果的過程則按照之前的方法反向重復(fù)一遍。如下圖所示：

　　在基于消息的遠(yuǎn)程方法調(diào)用中主要有以下幾個重要角色：

　　Client Proxy： 負(fù)責(zé)在客戶端處理基于棧的參數(shù)傳遞模式和基于消息的參數(shù)傳遞模式之間的轉(zhuǎn)換。

　　Invoker：與Client Proxy的功能相反。

　　Requestor： 負(fù)責(zé)將消息對象轉(zhuǎn)換成可在網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)流，并將其發(fā)送到服務(wù)器。

　　Marshaller： 負(fù)責(zé)消息對象的序列化與反序列化。

　　Client Request Handle：負(fù)責(zé)以數(shù)據(jù)流的格式發(fā)送客戶端的請求消息。

　　Server Request Handel：負(fù)責(zé)接收來自客戶端的請求消息。

　　那么在.NET Remoting框架下，這些重要角色又各自對應(yīng)了哪些對象呢?下圖是一個Remoting框架的示意圖：

從中我們可以看到客戶端的Transparent Proxy與服務(wù)器端的StackBuilderSink分別扮演了Client Proxy與Invoker的角色。Remoting依靠這兩個對象實現(xiàn)了基于棧的方法調(diào)用與基于消息的方法調(diào)用的轉(zhuǎn)換，并且這一過程對于開發(fā)者是完全隱藏的。