剛剛搬來這個(gè)溫暖的C++大家庭，就已經(jīng)發(fā)現(xiàn)有高手在開發(fā)C++的RMI了。

我一直都在留意www.codeproject.com的一個(gè)項(xiàng)目：http://www.codeproject.com/threads/RMI_For_Cpp.asp
作者并在不斷的完善中，但也基本上能用了。
calvin前幾天又提醒過我一次，一個(gè)久違的project：http://acdk.sourceforge.net/ 里面也實(shí)現(xiàn)了類似的RMI技術(shù)。（當(dāng)然是模仿Java的RMI，而且模仿得很像）。

個(gè)人比較討厭類似于ICE那種，需要通過一個(gè)外部工具編譯IDL的做法，不利于集成開發(fā)：老要在IDE上做些手腳，以實(shí)現(xiàn)自動(dòng)預(yù)編譯；要找相應(yīng)的語法解釋器解釋IDL，否則編輯困難；由于不是源代碼的一部分，代碼管理上經(jīng)常會(huì)有些混亂……所以反而比較喜歡類似于RMI for c++這種，把接口的描述也作為源代碼的一部分。而且由于都是C++語言的一部分，不會(huì)有太多的額外工作。

但在本人的實(shí)際工作中，RMI卻不如想象中這么有效。
首先，就是參數(shù)傳遞。很多情況下，調(diào)用一個(gè)函數(shù)，會(huì)傳入一些參數(shù)。既然是面向?qū)ο箝_發(fā)，傳入一個(gè)對(duì)象的情況是不可避免的。例如：
int func(TMyObject & a);
TMyObject可能是一個(gè)很龐大，很復(fù)雜的類，但func里面可能只需要訪問其中80%的成員變量。但是只通過IDL的接口，不可能知道究竟函數(shù)里面需要哪些數(shù)據(jù)，所以一般根據(jù)IDL生成的輔助代碼，都會(huì)是把整個(gè)TMyObject對(duì)象序列化并傳遞。當(dāng)TMyObject相當(dāng)龐大的時(shí)候，這個(gè)浪費(fèi)相當(dāng)厲害。更好的做法只好把func所需要的參數(shù)逐個(gè)排列出來作為func的參數(shù)。但這樣func用起來就變得極為麻煩了。
其次就是數(shù)據(jù)流的處理問題。經(jīng)常會(huì)出現(xiàn)類似于int func(stream & a, stream & b);的函數(shù)調(diào)用。對(duì)于客戶端，缺省的實(shí)現(xiàn)容易理解，按順序把兩個(gè)stream中的數(shù)據(jù)序列化就可以了。但是在服務(wù)器端，代碼就沒有這么好寫了。由于stream一般都是一個(gè)虛類，因此IDL生成的輔助代碼就要想辦法用一種具體stream子類，把網(wǎng)絡(luò)數(shù)據(jù)先收下來，然后再傳給實(shí)際的func函數(shù)。而這個(gè)stream的子類也比較頭疼，應(yīng)該選內(nèi)存還是臨時(shí)文件呢？還是更智能一點(diǎn)，小數(shù)據(jù)內(nèi)存、大數(shù)據(jù)文件呢？但無論是哪種方法，都要考慮數(shù)據(jù)的回收和生存期的問題。另外不爽的地方就是數(shù)據(jù)要接收完畢才能真正執(zhí)行func，從而數(shù)據(jù)是多拷貝了一次了。

當(dāng)然這里所說的問題對(duì)于一般應(yīng)用都無關(guān)痛癢，但對(duì)于一些性能要求比較高的場合，RMI自動(dòng)生成的stub就無能為力了。
RMI往往也和反射、成員序列化等技術(shù)相關(guān)。而且通常還要涉及到通訊版本差異處理、異常處理等等。像ICE還增加了異步處理、對(duì)象發(fā)現(xiàn)等等。所以要做一個(gè)完整的RMI，的確不是容易的事情。