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

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

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

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

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