一般來說，基于CS（client-server)軟件架構的開發(fā)技術有很多種。比較常用的有：基于socket的網絡編程、RPC、基于Java技術的RMI（當然C#也有類似技術）、CORBA等。在這里我們只是對基于socket的網絡編程與RMI作個對比，有助于我們了解它們各自的應用領域，幫助我們在面對一個具體問題的時候選用適合的技術。另外，本文所做的討論可以認為是脫離了語言層面的東西，只是對技術的本身做一個討論，無關乎你是用C++、C#或Java 在開發(fā)。
一、RMI技術簡介
        本文就以Java為例，簡單介紹一下RMI技術。
        從Java1.1開始，遠程方法調用作為Java分布式對象技術成為Java核心的API之一(在java.rmi.* 包)。RMI的引入，使得Java程序之間能夠實現(xiàn)靈活的，可擴展的分布式通信。RMI允許Java對象存在于多個不同的地址空間，分布在不同的Java虛擬機上。每一個地址空間可以在同一臺主機上或者網絡上不同的計算機上。由于遠程方法調用跨越不同的虛擬機邊界到不同的指定的地址空間，所以沒有對象共享的全局變量，這就需要對象序列化(Object Serialization)API，它使得Java對象能夠在不同的JVM之間傳遞。對象序列化是特別為Java的對象設計的，這就意味著Java程序中的對象可以作為對象參數(shù)存取（可序列化的對象必須實現(xiàn)Serializable接口）。結合RMI和對象序列化機制，就可以訪問越過本地Java虛擬機邊界的對象以及數(shù)據(jù)。通過RMI，可以調用遠程對象的遠程方法，而通過Java對象序列化機制可以將對象傳遞給這些方法。
        最基本的Java模型并沒有提供將遠程主機上的Java對象看作本地Java程序地址空間一部分的能力，而RMI禰補了這一不足。另外，由于Java與硬件平臺無關的特性，無論是同構的系統(tǒng)還是異構的系統(tǒng)，RMI不需移植就可以順利運行。
       RMI為Java平臺的分布式計算提供了一個簡單而直接的模型。因為Java的RMI技術是基于Java平臺的，所以它將Java平臺的安全性和可移植性等優(yōu)點帶到了分布式計算中。RMI大大擴展Java的網絡計算能力，它為編寫基于分布式對象技術的企業(yè)級Internet/Intranet應用提供了強大的系統(tǒng)平臺支持。
      Java RMI體系結構如下圖：

二、基于socket的網絡編程
        當你使用socket進行網絡應用開發(fā)的時候，一般的思路是“消息驅動邏輯”，即這樣的軟件系統(tǒng)一般具有以下特點：
       (1) 客戶端與服務器端依靠消息進行通訊。
       (2) 客戶端或者服務器端都需要一個消息派遣器，將消息投遞給具體的massage handler
       (3) 客戶端或者服務器端利用massage handler進行邏輯事務處理
 見下圖：

        使用socket開發(fā)的軟件系統(tǒng)，從技術的本質上來講，有以下幾個特點：
        (1) 基于TCP協(xié)議的通訊
        (2) 應用程序本身需要提供對消息的序列化處理（所謂的序列化指的是將消息輸出到網絡流中)
        (3) 客戶端與服務器端需要事先商議好它們之間的通訊協(xié)議即它們交互的消息格式
        (4) 由于是消息驅動邏輯，從本質上決定了這樣的編程模式很難面向對象化
三、RMI Vs Sochet
        RMI技術比較socket的網絡編程主要有以下幾個方面：
        第一、.RMI是面向對象的，而后者不是。
        第二、.RMI是與語言相綁定的。比如當你使用Java RMI技術的時候，客戶端與服務器端都必須使用Java開發(fā)。而socket的網絡編程是使用獨立于開發(fā)語言的，甚至獨立于平臺。基于socket的網絡編程，客戶端與服務器端可以使用不同開發(fā)語言和不同的平臺。
       第三、從網絡協(xié)議棧的觀點來看，RMI與socket的網絡編程處于不同層次上。基于socket的網絡編程位于TCP協(xié)議之上，而RMI在TCP協(xié)議之上，又定義了自己的應用協(xié)議，其傳輸層采用的是Java遠程方法協(xié)議(JRMP)。可見，在網絡協(xié)議棧上，基于RMI的應用位置更高一些，這也決定了，與socket的網絡編程相比，RMI會喪失一些靈活性和可控性，但是好處是它帶給了應用開發(fā)者更多的簡潔，方便和易用。比如：如果你用的是RMI,你不需要關心消息是怎么序列化的，你只需要像本地方法調用一樣，使用RMI。代價是：應用開發(fā)者無法很好地控制消息的序列化機制。
      第四、這是最后一點不同，我認為也是比較重要的一點，就是兩種方法的性能比較，其往往決定著你將使用那種技術來開發(fā)你的應用。以下引用Adrian Reber在Network-programming with RMI文中對TCP和RMI所做的一個比較，其做的實驗主要是對兩者在網絡傳輸?shù)膸捝献鞯膶Ρ龋?在網絡上傳輸2 byte的有效數(shù)據(jù)，對于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相比，傳輸相同的有效數(shù)據(jù)，RMI需要占用更多的網絡帶寬（protocol overhead）。從這里，我們可以得出一個一般性的結論：RMI主要是用于遠程方法的”調用“（RMI是多么的名符其實:)），其技術內涵強調的是“調用”，基于此，我能想到的是：移動計算，和遠程控制，當你的應用不需要在client與server之間傳輸大量的數(shù)據(jù)時，RMI是較好的選擇，它簡潔、易于開發(fā)。但是，一旦你的應用需要在client與server之間傳輸大量的數(shù)據(jù)，極端的，比如FTP應用，則RMI是不適合的，我們應該使用socket。

四、參考資料：
Network-programming with RMI， by Adrian Reber, URL:
http://42.fht-esslingen.de/~adrian/master/rmi.pdf