互聯網內部對象請求代理協議（IIOP）是一個實現互操作性的協議，它使得由不同語言編寫的分佈式程序在因特網中可以實現彼此的交流溝通。它是行業戰略性標準，也即公用對象請求代理程序結構（Common Object Request Broker Architecture，CORBA）中至關重要的一個部分。採用公用對象請求代理程序結構（CORBA）中的互聯網內部對象請求代理協議（IIOP），企業將能夠將自己編寫的程序和其他公司的程序進行交流，不論這個程序是不是已經寫出來了，或者在那個地方寫的，這都無關緊要。公用對象請求代理程序結構（CORBA）和互聯網內部對象請求代理協議（IIOP）正在面臨着微軟公司推出的分佈式COM（DCOM）協議的競爭。（不過，微軟公司和提出CORBA協議的對象管理組織已經達成意向，他們將共同努力創建一種橋樑性的軟件，使得在CORBA協議和DCOM協議背景下編寫的程序可以實現彼此的無限溝通。） CORBA和IIOP協議假定在計算機的客戶端/服務器端模式中，客戶端的程序總是提出各種請求，服務器端的程序則處於等待和接受客戶端請求的狀態。在編寫程序的時候，常常需要用到一個叫做通用ORB間協議（GIOP）的界面。通用ORB間協議（GIOP）可以實現網絡傳輸層之間的映射，而IIOP就是其中最重要的映射之一，它應用傳輸控制協議（TCP）藉助因特網的傳輸層來傳遞請求或者接收答覆。 如果客戶端需要在網絡中傳送一個程序命令，就必須提供爲程序提供一個目標地址。這個地址就是交換可互操作對象引用（IOR）。應用IIOP協議，目標地址由服務器端口數據和IP地址共同構成。
1997 年，IBM 和 Sun Microsystems 啓動了一項旨在促進 Java 作爲企業開發技術的發展的合作計劃。兩家公司特別着力於如何將 Java 用作服務器端語言，生成可以結合進現有體系結構的企業級代碼。所需要的就是一種遠程傳輸技術，它兼有 Java 的 RMI（Remote Method Invocation，遠程方法調用）較少的資源佔用量和更成熟的 CORBA（Common Object Request Broker Architecture，公共對象請求代理體系結構）技術的健壯性。出於這一需要，RMI-IIOP 問世了，它幫助將 Java 語言推向了目前服務器端企業開發的主流語言的領先地位。
在本文中，我將簡要介紹 RMI-IIOP，目標是使您能開始在企業開發解決方案中使用這一技術。要解釋 RMI-IIOP 究竟是什麼，我認爲提供一些關於 CORBA 和 RMI 的信息是重要的，這些信息您在各個技術的典型介紹中可能找不到。如果您對 CORBA 或 RMI 的基礎知識不熟悉，我建議您在往下讀之前先閱讀一些介紹性信息。，那裏挑選了一些文章和教程。
在我具體討論 RMI-IIOP 之前，我們將先看一下 CORBA 和 RMI 用來對請求進行數據編入的機制。CORBA 將是我們的主要示例，因爲 RMI-IIOP 數據編入是建立在 CORBA 傳輸協議（IIOP）的基礎上的。我們將回顧一下該傳輸協議和 ORB（object request broker，對象請求代理）在網絡上發送請求、定位遠程對象和傳輸對象方面的基本功能。
對 CORBA 請求進行數據編入是通過使用 IIOP 協議做到的。簡言之，IIOP 將以標準化格式構造的任何 IDL（Interface Definition Language，接口定義語言）的元素表示爲一系列字節。那就假設有一個 Java 客戶機正在將一個 CORBA 請求分派到 C++ 服務器吧。客戶機應用程序以 Java 接口的形式擁有遠程對象的引用，並調用該接口的一個操作。本質上是，接口調用它對該操作的相應實現，這個實現將位於存根（stub）（存根是您將已經用 idlj 從 IDL 生成了的）。
存根把方法調用分派到 ORB 中，ORB 由兩部分組成：客戶機 ORB 和服務器 ORB。客戶機 ORB 的職責是對請求進行數據編入，放到網絡上，傳往特定位置。服務器 ORB 的職責是偵聽從網絡上傳下來的請求，並將這些請求轉換成語言實現能夠理解的方法調用。要了解對 CORBA ORB 的角色的更深入討論
存根分派了方法調用之後，客戶機 ORB 將請求和所有參數轉換成標準化字節格式，在這種情況中是 IIOP。接着，請求通過導線被髮送到服務器 ORB，服務器 ORB 應該正在偵聽傳入請求。服務器端 ORB 將讀進數據的字節並將請求轉換成對 C++ 服務器實現有意義的東西。C++ 服務器方法將執行它的功能（即調用所請求的方法）並使用相同的機制通過 IIOP 將結果返回給客戶機。
RMI 以類似的方式處理請求，但是它使用 JRMP（Java Remote Messaging Protocol，Java 遠程消息傳遞協議）作爲其傳輸協議。當然，RMI 傳輸還涉及 Java 對象的序列化。
 |
CORBA 使用 CosNaming 命名服務定位遠程對象。CosNaming 爲名稱服務器保存對 CORBA 服務器進程的綁定（或引用）提供了一個框架。當 CORBA 客戶機向名稱服務發送 CosNaming 請求，請求給定名稱的服務器進程時，名稱服務返回該進程的 可互操作對象引用（interoperable object reference（IOR））。接着，客戶機使用該 IOR 直接與服務器進程通信。
IOR 包含關於服務器進程的信息，例如服務器進程的位置。CosNaming 服務的缺點之一是，IOR 對人類而言是難以看懂的 ― 至少對我們這些沒有電子大腦的人來說是這樣。相反地，RMI 對用戶則要友好一些。它使用運行在 JNDI 之上的 註冊中心（與命名服務極爲相似）來定位遠程對象。RMI 註冊中心使用 Java Reference 對象（它由若干個 RefAddr 對象組成）來識別和定位遠程對象。這些 Java 對象比 IOR 對用戶更加友好。
不久前，COBRA 將可互操作命名服務（Interoperable Naming Service（INS））結合進了它的對象-定位（object-location）模式。INS 在 CosNaming 上運行，使用人類可以閱讀的 URL 作它的對象位置。INS 不使用命名服務；相反地，它將調用直接發送到指定的 URL。
那麼，哪一個更好呢：是 CORBA 還是 RMI？答案取決於您想做什麼。CORBA 是一個運行在業界標準的第三或第四代協議上的、經過試驗和測試的大體系結構。如果考慮到 CORBA 提供的所有附件（例如：事務處理、安全攔截器、事件通道，還有更多）的話，則 CORBA 看來是企業應用程序的解決方案。CORBA 的最大缺點是它很複雜。要熟練使用 CORBA，開發者通常要經歷陡峭的培訓曲線。
相反地，RMI 相當容易學習。創建一個客戶機／服務器實現，綁定到註冊中心和遠程對象，使用 RMI 調用和／或接收請求都相當簡單。RMI 的資源佔用量也比 CORBA 小得多，因爲 JRMP 是開銷比 IIOP 小得多的協議。但是，RMI 缺乏 CORBA 的工業級的附件，而且是純基於 Java 的機制。那麼，我們真正需要的就是 RMI 的靈活性和易用性以及 CORBA 的企業就緒性，對嗎？那就開始討論 RMI-IIOP 吧。
|
RMI-IIOP 讓您僅需極少修改就可以在 IIOP 上運行 RMI 調用。藉助於 RMI-IIOP，您可以編寫簡單易懂的 Java 代碼，同時使用 CORBA 提供的豐富的企業功能套件。而且，代碼的靈活性足夠大，可以運行在 RMI 或IIOP 上。這意味着，您的代碼可以在純 Java 環境中運行（當小的資源佔用量和靈活性很關鍵時），或者對代碼作少量修改後集成到現有的 CORBA 基礎架構中。
RMI-IIOP 很強大的功能之一是，它讓您編寫純 Java 客戶機／服務器實現而不喪失 RMI 類序列化的靈活性。RMI-IIOP 通過覆蓋 Java 序列化並在導線上將 Java 類轉換成 IIOP 做到這一點。在另一端，Java 類被作爲 IIOP 從導線上讀下來，接着創建這個類的一個新實例（使用反射），類的所有成員的值都完整無缺 ― 瞧：這就是 IIOP 上的 Java 序列化！
爲了讓 RMI-IIOP 實現透明的對象定位，ORB 供應商歷史上曾經使用 Java CosNaming 服務提供者（或用外行人的話說，是 插件）。該插件在 JNDI API 之下工作，訪問 CORBA 命名服務。儘管我沒有在這裏花篇幅來說明原因，但這種命名解決方案並不理想。其結果是，許多供應商 ― 尤其是應用服務器供應商 ― 爲 RMI-IIOP 開發了專門的對象定位機制。
RMI-IIOP 也支持作爲 Java CosNaming 服務的一個擴展的 INS。因爲我相信 INS 將確定對象定位的未來方向，所以我們在本文將討論的代碼示例使用 INS。
說得夠多了，讓我們來編寫代碼吧！在以下幾部分中，我們將構建一個簡單的、基於 Java 的客戶機／服務器 RMI-IIOP 應用程序。這個應用程序由三個部分組成：RMI 接口、服務器應用程序和客戶機應用程序。示例以在 IIOP 之上的 Java 序列化爲特色，所以您可以看到 Java 類如何被客戶機實例化，如何傳遞到服務器，由服務器更改，然後將所有修改完整地回傳到客戶機。