詳見： http://blog.yemou.net/article/query/info/tytfjhfascvhzxcytp58
一般來說，基於CS（client-server)軟件架構的開發技術有很多種。比較常用的有：基於socket的網絡編程、RPC、基於Java技術的RMI（當然C#也有類似技術）、CORBA等。在這裏我們只是對基於socket的網絡編程與RMI作個對比，有助於我們瞭解它們各自的應用領域，幫助我們在面對一個具體問題的時候選用適合的技術。另外，本文所做的討論可以認爲是脫離了語言層面的東西，只是對技術的本身做一個討論，無關乎你是用C++、C#或Java 在開發。
一、RMI技術簡介
本文就以Java爲例，簡單介紹一下RMI技術。
從Java1.1開始，遠程方法調用作爲Java分佈式對象技術成爲Java核心的API之一(在java.rmi.* 包)。RMI的引入，使得Java程序之間能夠實現靈活的，可擴展的分佈式通信。RMI允許Java對象存在於多個不同的地址空間，分佈在不同的Java虛擬機上。每一個地址空間可以在同一臺主機上或者網絡上不同的計算機上。由於遠程方法調用跨越不同的虛擬機邊界到不同的指定的地址空間，所以沒有對象共享的全局變量，這就需要對象序列化(Object Serialization)API，它使得Java對象能夠在不同的JVM之間傳遞。對象序列化是特別爲Java的對象設計的，這就意味着Java程序中的對象可以作爲對象參數存取（可序列化的對象必須實現Serializable接口）。結合RMI和對象序列化機制，就可以訪問越過本地Java虛擬機邊界的對象以及數據。通過RMI，可以調用遠程對象的遠程方法，而通過Java對象序列化機制可以將對象傳遞給這些方法。
最基本的Java模型並沒有提供將遠程主機上的Java對象看作本地Java程序地址空間一部分的能力，而RMI禰補了這一不足。另外，由於Java與硬件平臺無關的特性，無論是同構的系統還是異構的系統，RMI不需移植就可以順利運行。
RMI爲Java平臺的分佈式計算提供了一個簡單而直接的模型。因爲Java的RMI技術是基於Java平臺的，所以它將Java平臺的安全性和可移植性等優點帶到了分佈式計算中。RMI大大擴展Java的網絡計算能力，它爲編寫基於分佈式對象技術的企業級Internet/Intranet應用提供了強大的系統平臺支持。
Java RMI體系結構如下圖：
二、基於socket的網絡編程
當你使用socket進行網絡應用開發的時候，一般的思路是“消息驅動邏輯”，即這樣的軟件系統一般具有以下特點：
(1) 客戶端與服務器端依靠消息進行通訊。
(2) 客戶端或者服務器端都需要一個消息派遣器，將消息投遞給具體的massage handler
(3) 客戶端或者服務器端利用massage handler進行邏輯事務處理
見下圖：
使用socket開發的軟件系統，從技術的本質上來講，有以下幾個特點：
(1) 基於TCP協議的通訊
(2) 應用程序本身需要提供對消息的序列化處理（所謂的序列化指的是將消息輸出到網絡流中)
(3) 客戶端與服務器端需要事先商議好它們之間的通訊協議即它們交互的消息格式
(4) 由於是消息驅動邏輯，從本質上決定了這樣的編程模式很難面向對象化
三、RMI Vs Sochet
RMI技術比較socket的網絡編程主要有以下幾個方面：
第一、.RMI是面向對象的，而後者不是。
第二、.RMI是與語言相綁定的。比如當你使用Java RMI技術的時候，客戶端與服務器端都必須使用Java開發。而socket的網絡編程是使用獨立於開發語言的，甚至獨立於平臺。基於socket的網絡編程，客戶端與服務器端可以使用不同開發語言和不同的平臺。
第三、從網絡協議棧的觀點來看，RMI與socket的網絡編程處於不同層次上。基於socket的網絡編程位於TCP協議之上，而RMI在TCP協議之上，又定義了自己的應用協議，其傳輸層採用的是Java遠程方法協議(JRMP)。可見，在網絡協議棧上，基於RMI的應用位置更高一些，這也決定了，與socket的網絡編程相比，RMI會喪失一些靈活性和可控性，但是好處是它帶給了應用開發者更多的簡潔，方便和易用。比如：如果你用的是RMI,你不需要關心消息是怎麼序列化的，你只需要像本地方法調用一樣，使用RMI。代價是：應用開發者無法很好地控制消息的序列化機制。
第四、這是最後一點不同，我認爲也是比較重要的一點，就是兩種方法的性能比較，其往往決定着你將使用那種技術來開發你的應用。以下引用Adrian Reber在Network-programming with RMI文中對TCP和RMI所做的一個比較，其做的實驗主要是對兩者在網絡傳輸的帶寬上作的對比： 在網絡上傳輸2 byte的有效數據，對於TCP而言，總共有478 byte被額外傳輸，而對於RMI, 1645byte被額外傳輸。
以下是兩者的trace結果：
TCP:
46037 > 12345 [SYN] Seq=801611567 Ack=0 Win=5840 Len=0
12345 > 46037 [SYN, ACK] Seq=266515894 Ack=801611568 Win=10136 Len=0
46037 > 12345 [ACK] Seq=801611568 Ack=266515895 Win=5840 Len=0
12345 > 46037 [PSH, ACK] Seq=266515895 Ack=801611568 Win=10136 Len=1
46037 > 12345 [ACK] Seq=801611568 Ack=266515896 Win=5840 Len=0
12345 > 46037 [FIN, PSH, ACK] Seq=266515896 Ack=801611568 Win=10136 Len=1
46037 > 12345 [RST, ACK] Seq=801611568 Ack=266515898 Win=5840 Len=0
RMI:
42749 > rmiregistry [SYN, ECN, CWR]
Seq=3740552479 Ack=0 Win=32767 Len=0
rmiregistry > 42749 [SYN, ACK, ECN]
Seq=3749262223 Ack=3740552480 Win=32767 Len=0
42749 > rmiregistry [ACK] Seq=3740552480 Ack=3749262224 Win=32767 Len=0
JRMI, Version: 2, StreamProtocol
rmiregistry > 42749 [ACK] Seq=3749262224 Ack=3740552487 Win=32767 Len=0
JRMI, ProtocolAck
42749 > rmiregistry [ACK] Seq=3740552487 Ack=3749262240 Win=32767 Len=0
Continuation
rmiregistry > 42749 [ACK] Seq=3749262240 Ack=3740552506 Win=32767 Len=0
JRMI, Call
rmiregistry > 42749 [ACK] Seq=3749262240 Ack=3740552556 Win=32767 Len=0
JRMI, ReturnData
42749 > rmiregistry [ACK] Seq=3740552556 Ack=3749262442 Win=32767 Len=0
JRMI, Ping
JRMI, PingAck
42749 > rmiregistry [ACK] Seq=3740552557 Ack=3749262443 Win=32767 Len=0
JRMI, DgcAck
42749 > rmiregistry [FIN, ACK]
Seq=3740552572 Ack=3749262443 Win=32767 Len=0
rmiregistry > 42749 [FIN, ACK]
Seq=3749262443 Ack=3740552573 Win=32767 Len=0
42749 > rmiregistry [ACK] Seq=3740552573 Ack=3749262444 Win=32767 Len=0
實驗的結果是：RMI與TCP based socket相比，傳輸相同的有效數據，RMI需要佔用更多的網絡帶寬（protocol overhead）。從這裏，我們可以得出一個一般性的結論：RMI主要是用於遠程方法的”調用“（RMI是多麼的名符其實:)），其技術內涵強調的是“調用”，基於此，我能想到的是：移動計算，和遠程控制，當你的應用不需要在client與server之間傳輸大量的數據時，RMI是較好的選擇，它簡潔、易於開發。但是，一旦你的應用需要在client與server之間傳輸大量的數據，極端的，比如FTP應用，則RMI是不適合的，我們應該使用socket。