剛剛搬來這個溫暖的C++大家庭，就已經發現有高手在開發C++的RMI了。

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

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

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

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