IIOP上のRMI

RMI over IIOPとは何ですか?

IBMとSunが共同で開発したRMIover IIOP(以下、RMI-IIOP)は、RMIの簡単なプログラミング機能とCORBAの相互運用性を組み合わせた、IIOP(Internet Inter-ORB Protocol)用のRMI(Remote Method Invocation)の新しいバージョンです。この新しいバージョンのRMIは、6月に正式にリリースされ、SunのWebサイトから無料で入手できるようになりました(ダウンロードできる場所については、以下の「リソース」セクションを参照してください)。Sunリファレンス実装は、Windows 9x / NTおよびSolarisで実行されます。これは、JDK1.1.6とJava2プラットフォームの両方をサポートする標準の拡張機能です。

RMIとCORBAは、分散オブジェクトプログラミングモデルとして独自に開発されました。EJBおよびJiniテクノロジーの基盤であるRMIは、分散オブジェクト用のJavaベースの使いやすいプログラミングモデルとして導入されました。OMG(Object Management Group)によって定義されたCORBA(Common Object Request Broker Architecture)は、多くの言語をサポートするよく知られた分散オブジェクトプログラミングモデルです。IIOPプロトコルは、さまざまなベンダーのCORBA製品を接続し、それらの間の相互運用性を保証します。RMI-IIOPは、ある意味でRMIとCORBAの融合です。

この記事では、CORBAの基本に既に精通していることを前提としています。理解するためにさらに支援が必要な場合は、以下の「リソース」セクションに役立つリンクがあります。

RMI-IIOPの前

下の図1を見てください。中央の水平線の上のスペースは、RMIの元のドメインを表します。下の領域は、CORBAとIIOPの世界を表しています。独立して発展したこれらの2つの別々の世界は、歴史的に互いに通信することができませんでした。たとえば、RMIのネイティブプロトコルであるJRMP(Java Remote Method Protocol)は、他のプロトコルと接続できません。

新しいプロジェクトで必要なプログラミング言語がJavaだけの場合、RMIとJRMP この記事の残りの部分ではRMI(JRMP)と呼ばれる組み合わせ)の使用が伝統的に最良の選択でした。かなり複雑なインターフェース定義言語(IDL)の使用を必要とするCORBAとは異なり、RMI(JRMP)はJava愛好家に簡単なプログラミングを提供します。一方、CORBAを使用すると、さまざまなプラットフォームやさまざまなプログラミング言語にまたがる分散オブジェクトプログラミングが可能になります。開発者は、新しいプロジェクトだけでなく、レガシーソフトウェアリソースを利用するための分散オブジェクトプログラミングを必要としています。もちろん、レガシーソフトウェアはほとんどの場合Java以外の言語でプログラムされています。このような状況では、開発者はRMI(JRMP)ではなくCORBAを必要とします。

したがって、中心的なジレンマがあります。RMI(JRMP)にはプログラミングが簡単であるという利点がありますが、CORBAは、さまざまなプラットフォームにわたる複数のプログラミング言語間の相互運用性を提供します。しかし残念ながら、これらの優れたテクノロジーの両方を使用する方法は伝統的にありませんでした。これは、図2のグラフに示されています。ここで、円はクライアントがサーバーを呼び出すことができる状況を表し、Xはこれが不可能な場合を表します。

両方の長所

新しいプロジェクトを開始するときに、RMI(JRMP)とCORBAのどちらかを選択するのは以前は困難でした。 RMI(JRMP)を選択した場合、プログラミングは簡単になりましたが、複数の言語間の相互運用性が失われました。 CORBAを選択した場合、相互運用性は得られますが、より困難なプログラミング作業に直面しました。この決定にうんざりしているRMI(JRMP)とCORBAの両方のユーザーは、「2つを接続してください」と1つの声で言いました。

下の図3では、上のセクションはRMI(JRMP)モデル、中央のセクションはRMI-IIOPモデル、下のセクションはCORBAモデルを表しています。矢印は、クライアントがサーバーを呼び出すことができる状況を表します。 RMI-IIOPは、水平線より下のIIOPの世界に属しています。奇妙に見えるかもしれないのは、JRMPワールドとIIOPワールドの境界を横切る斜めの矢印です。これは、RMI(JRMP)クライアントがRMI-IIOPサーバーを呼び出すことができることを意味します。読者がこれらの斜めの矢印が間違っていると考えるのは自然なことです-結局のところ、異なるプロトコルは互いに通信することはできませんよね?ただし、これらの矢印は実際には正しい場所にあります。 RMI-IIOPは、JRMPプロトコルIIOPプロトコルの両方をサポートします。

RMI-IIOP APIを使用して作成されたサーバーバイナリ(つまり、クラスファイル)は、JRMPまたはIIOPのいずれかとしてエクスポートできます。Javaソースコードを書き直したり、JRMPからIIOPに、またはその逆に変更するときに再コンパイルしたりする必要はありません。実行時に変更する必要があるのは、Javaシステムプロパティなどのパラメータのみです。または、Javaソースコードで指定して、使用するプロトコルを決定することもできます。同じ柔軟性がRMI-IIOPクライアントコードにも当てはまります。

デュアルエクスポート

JRMPプロトコルとIIOPプロトコルのどちらを使用するかを決定する際に留意すべきもう1つの重要な事実があります。サーバーにRMI-IIOPオブジェクトをエクスポートする場合、必ずしもJRMPとIIOPのどちらかを選択する必要はありません。 JRMPクライアントとIIOPクライアントの両方をサポートする単一のサーバーオブジェクトが必要な場合は、RMI-IIOPオブジェクトをJRMPとIIOPの両方に同時にエクスポートできます。 RMI-IIOPの用語では、これはデュアルエクスポートと呼ばれます。

RMI-IIOP APIはJRMPプロトコルとIIOPプロトコルの両方をサポートしているため、図3の斜めの矢印が可能です。これは、RMI(JRMP)オブジェクトのソースコードを書き直すことなく、新しいRMI-IIOPクライアントから呼び出すことができることを意味します。同様に、RMI(JRMP)クライアントのソースコードを書き直すことなく、RMI(JRMP)サーバーオブジェクトを、CORBAクライアントも呼び出すことができる新しいRMI-IIOPオブジェクトに置き換えることができます。したがって、RMI-IIOPは、ソースコードの変更や再コンパイルなしでRMI(JRMP)バイナリと通信できるため、RMI(JRMP)バイナリへの既存の投資を維持します。

このRMI(JRMP)との相互運用性は、RMI-IIOPの設計原則の1つでした。RMI-IIOP設計者は、CORBAとRMIを3番目のプログラミングモデルに置き換えようとする誘惑を避けました。これは、分散オブジェクトプログラマーを混乱させ、RMI(JRMP)からの移行をさらに困難にするためです。

CORBAとの相互運用性

図3をもう一度見てください。水平線の下のセクションはIIOPワールドであり、RMI-IIOPクライアントがCORBAサーバーを呼び出し、CORBAクライアントがRMI-IIOPサーバーを呼び出します。RMI-IIOPクライアント、我々は、CORBAやIDLについて何も知らないRMIプログラマーによって書かれたクライアントプログラムを意味します。同様に、CORBAクライアントRMIを知らないCORBAプログラマーによって作成されたクライアントプログラムです。インターフェースを実装から分離することは、プログラマーがそれらのリソースがどのように実装されているかを知らなくても、さまざまなリソースにアクセスできるようにするための確立された手法です。この手法に従うと、RMI-IIOPとCORBAの両方のユーザーは、そのインターフェイスにアクセスできれば、他のプロトコルのサービスを使用できます。 RMI JavaインターフェイスファイルはRMI-IIOPユーザーへのインターフェイスであり、IDLはCORBAユーザーへのインターフェイスです。図3のRMI-IIOPとCORBAの間の相互運用性は、実際の実装を隠したまま、各ユーザーに期待されるインターフェイスを提供することによって実現されます。

図3で説明する最後の詳細は、CORBAサーバーを呼び出すRMI-IIOPクライアントを示す点線の矢印です。なぜこの矢印だけが点在しているのですか? RMI-IIOPクライアントは、必ずしもすべての既存のCORBAオブジェクトにアクセスできるとは限りません。 IDLで定義されたCORBAオブジェクトのセマンティクスは、RMI-IIOPオブジェクトのセマンティクスのスーパーセットであるため、既存のCORBAオブジェクトのIDLを常にRMI-IIOPJavaインターフェイスにマップできるとは限りません。 RMI-IIOPクライアントがCORBAオブジェクトを呼び出すことができるのは、特定のCORBAオブジェクトのセマンティクスがRMI-IIOPのセマンティクスと一致する場合のみです。点線の矢印は、接続が可能である場合がありますが、常に可能であるとは限りません。

ただし、ここでの非互換性は誇張されるべきではありません。点線の矢印で示されている制限は、既存のCORBAオブジェクトを処理する場合にのみ適用されます。 RMI-IIOPJavaインターフェイスを使用して新しい分散オブジェクトを設計するとします。この場合、対応するIDLをrmicツール。このIDLファイルから、CORBAオブジェクトとして実装できます(たとえば、C ++)。このC ++オブジェクトは、CORBAクライアントから呼び出すことができる純粋なCORBAオブジェクトであり、RMI-IIOPクライアントからも制限なく呼び出すことができます。 RMI-IIOPクライアントには、このC ++ CORBAオブジェクトは、RMI-IIOP Javaインターフェイスによって定義されているため、純粋なRMI-IIOPオブジェクトとして表示されます。つまり、CORBAオブジェクトとRMI-IIOPオブジェクトの違いは、実装上の問題にすぎません。同様に、オブジェクトがRMI-IIOPに実装されている場合、CORBAクライアントはIDLを介してオブジェクトにアクセスするため、オブジェクトはCORBAクライアントにはCORBAオブジェクトとして表示されます。

以下の図4は、図3の矢印を要約したマトリックスを示しています。点線の円は、図3の点線の矢印と同じ意味です。図4は、サーバーをRMI-IIOPに実装する場合、最も幅広い選択肢があることを示しています。クライアント。同様に、クライアントをRMI-IIOPに実装すると、最大範囲のサーバーと通信できますが、点線の円で示されているように、既存のCORBAオブジェクトの場合にはいくつかの制限があります。

RMI-IIOP設計ポリシー

RMI-IIOPプロトコルの設計を形作る2つの主要な前提条件がありました。RMIセマンティクスを可能な限りそのままにしておく必要があり、RMIセマンティクスをCORBAインフラストラクチャを使用して実装できるようにCORBAを拡張する必要がありました。これは口で言うほど簡単ではありませんでした。 3番目のプログラミングモデルが導入された場合、それはプログラマーを混乱させるだけです。 RMIとCORBAの幸せな結婚を生み出すには、これらの結婚パートナーのさまざまな背景の間で妥協点に到達する必要がありました。両方のパートナーが妥協案を拒否した場合、結婚はどこにも行きません。幸い、CORBAコミュニティはこれを認識し、RMI-IIOPを実現するために特定の変更を受け入れました。

CORBAが受け入れた2つの主要な変更は、Objects byValueJavaからIDLへのマッピング仕様でした。前者は、Javaオブジェクトのシリアル化の形でRMIユーザーがすでに利用できるものであり、他の言語に同様の機能を実装させることを目的としたCORBA仕様です。後者は、RMIJavaインターフェースをCORBAIDL定義に変換するために使用されるマッピングであり、CORBA2.2ですでに定義されているIDLからJavaへのマッピングと混同しないでください。 (これら2つの新しいCORBA仕様へのリンクについては、「参考文献」を参照してください。)

OMGはすでにCORBA2.3の両方の仕様を正式に受け入れていますが、ここで説明するCORBAとRMIの新しい組み合わせが広く実現する前に、CORBAの実装はこの新しいバージョンに追いつく必要があります。たとえば、CORBA 2.3に準拠するIDL-to-Javaコンパイラは、RMI-IIOP ORB(オブジェクトリクエストブローカ)と組み合わせて使用​​するためにSunから入手できますが、現在、の相互運用性の調査にのみ適した早期アクセスバージョンです。 CORBAおよびRMI-IIOPであり、本番用ではありません。さらに、Java1.2のJavaIDLORBで使用するためにSunによって配布されたIDL-to-JavaコンパイラはCORBA2.3に準拠していないため、RMI-IIOPとの相互運用性をテストするために使用することはできません。この状況は、CORBAベンダーがCORBA 2.3をサポートする製品の新しいバージョンを導入するため、今後数か月で解決される予定です。たとえば、Java 2Platformの次のリリースであるStandardEditionには、RMI-IIOPと、CORBA2.3をサポートする製品品質のIDL-to-Javaコンパイラの両方が含まれます。

開発手順

以下の図5は、RMI-IIOPサーバーとクライアントの両方の開発手順を示しています。RMI(JRMP)とほぼ同じであることがわかります。RMI(JRMP)の場合と同様に、分散オブジェクトの定義はそのRMI Javaインターフェースです(MyObject.java図5)。違いはコンパイラーの-iiopパラメーターですrmic。このオプションはrmic、IIOPプロトコルをサポートするスタブとタイを生成するために使用されます。この-iiopオプションがない場合、rmicJRMPプロトコルのスタブとスケルトンを生成します。RMI-IIOPの開発手順はRMI(JRMP)の開発手順に近いですが、サーバーとクライアント間の通信にIIOPを使用して、CORBA2.3準拠のORBを介して通信が行われるという点でランタイム環境が異なります。

RMI(JRMP)コードをRMI-IIOPに変換することを検討している場合は、IIOP上で実行するときにいくつかの実装の違いがあることに注意する必要があります。分散ガベージコレクションは、透過的なパッシベーションとアクティベーションを伴う明示的な破棄と永続的なオブジェクト参照を使用するCORBAではサポートされていません。RMIレジストリは、CosNamingまたはLDAPサービスプロバイダーを使用するJNDIに置き換えられ、RMIアクティベーションはポータブルオブジェクトアダプターに置き換えられます。リモートオブジェクト参照narrow()は、直接Java言語キャストではなく、プログラムメソッドを使用してダウンキャストする必要があります。オブジェクトのシリアル化などの他のRMIセマンティクスは、IIOPで完全にサポートされています。

CORBAの相互運用性手順

図6は、RMI-IIOPとCORBA間の相互運用性を実現する方法を示しています。説明を簡単にするために、このような相互運用性の2つの側面について考えてみましょう。図6の左端のセクションに示されているRMI-IIOPオブジェクトを使用するCORBAクライアントと、右端のセクションに示されているCORBAオブジェクトを使用するRMI-IIOPクライアントです。図の中央には、両方の形式の相互運用性を機能させる共有プロセスがあります。