連載
スキルアップのための分散オブジェクト入門
| 日本アイオナテクノロジーズ 主席 コンサルタント 小野沢 博文 2002/4/4 |
本連載について |
| 前回は、分散オブジェクト技術を使用することで、通信相手のネットワーク上の位置や通信プロトコルに煩わされずに、システムの機能分割や分散配置が可能になります、というお話をしました。しかし、そうはいっても、分散オブジェクトのプログラミングが、ローカルのJava やC++のプログラミングとまったく同じというわけではありません。分散オブジェクト技術を使いこなすためには、分散オブジェクト技術の仕組みと考え方を理解し、さらにプログラミング手法をマスタする必要があります。今回は、このうちの「仕組みと考え方」を解説します。 |
 |
分散オブジェクト技術は何をしてくれるのか |
| ■リモート呼び出しの仲介役 ― ORB |
|
今回の内容
|
 分散オブジェクト技術は何をしてくれるのか分散のメカニズム |
分散オブジェクト技術が実現する最も重要な機能は、分散環境でのオブジェクト呼び出しの実現です。クライアント側は、オブジェクトのネットワーク上での位置を意識することなく、そのメソッドを呼び出すことができます。一方、サーバ側は、あたかもローカルなオブジェクトを実装するかのように、外部から呼び出し可能なオブジェクトを実装することができます。その舞台裏では、サーバに到達するためのネットワーク・アドレスの解決とコネクション確立、要求や応答メッセージの組み立てと送受信といった複雑な処理が行われています。これらの処理を行っているのがオブジェクト呼び出しの仲介役（ブローカ）であるORB（用語解説1）です。
| 用語解説1 ORB（Object Request Broker） |
| ORBは、オーアールビーまたはオーブと読みます。ネットワーク環境に分散するオブジェクトへのアクセスを実現するメカニズムのことを一般にORBと呼びます。CORBA、JavaRMI、COM+、HORＢなどは、すべてORBの機能を含んでいます。 |
| ■オブジェクト・サービス |
ほとんどの分散オブジェクト技術は、このような単なるリモート・オブジェクトの呼び出しを実現するだけではなく、より高度なアプリケーションを開発するためのさまざまな付加サービスを提供しています。これらのうちの代表的なものに、セキュリティ、ネーミング、トランザクション、イベント等のサービスがあります。ただし、サービスの分類方法やサービス名は、それぞれの分散オブジェクト技術によって異なります。
|
分散のメカニズム |
これまでの説明のように、分散オブジェクト技術を使用することで、クライアントは、あたかも通常のJavaやC++のローカル・オブジェクトを呼び出すようにリモート・オブジェクトを呼び出し、サーバは、あたかもJavaやC++のローカル・オブジェクトを作成するイメージで分散オブジェクトを実装することが可能になります。これを実現するための基本的な仕組みは、ほとんどの分散オブジェクト技術で共通しており、歴史的にはリモート手続き呼び出し（RPC: Remote Procedure Call）に代表される分散コンピューテイング技術から引き継がれたものです。以下では、この共通の仕組みについて解説することにします。
| ■インターフェイス定義 |
アプリケーション開発者は、クライアントとサーバの実装を始める前に、サーバがクライアントにアクセスを許すオブジェクトのインターフェイスを定義する必要があります。CORBAでは、このためにIDL（Interface Definition Language）と呼ばれる専用の言語を使用します。マイクロソフトのCOM+では、CORBAで使うIDL（OMG IDLと呼ぶこともあります）とは別物ですが、やはりIDLと呼ばれる言語を使用してインターフェイスを定義します。ただし、COM+ではIDLの使用は必須ではありません。JavaRMIでは、Javaのインターフェイス定義を使用してインターフェイスを定義します。HORBでは、Javaのインターフェイス定義またはクラス定義を使用します。
| ■スタブとスケルトン |
このようにして作成したインターフェイス定義をコンパイルして、クライアント側で使用するスタブと呼ばれるコードと、サーバ側で使用するスケルトンと呼ばれるコードを生成します。
 |
| 図1 インターフェイス定義からのコード生成 |
●スタブの役割
先ほど、クライアント・アプリケーションは、あたかもローカル・オブジェクトであるかのようにリモート・オブジェクトのメソッドを呼び出すという話をしましたが、実はここでクライアントが呼び出していたのは、代理（プロキシ）オブジェクトと呼ばれるローカル・オブジェクトなのです。代理オブジェクトは、リモート・オブジェクトとまったく同じメソッドとパラメータを持っており、クライアントからのメソッド呼び出しをターゲットのリモート・オブジェクトに中継するという役割を持っています。
代理オブジェクトは、必要に応じてサーバとのトランスポート・コネクションを確立し、送信パラメータのマーシャリング（用語解説2）、要求メッセージの組み立てと送信、応答メッセージの受信と解析、受信パラメータのアンマーシャリング（用語解説2）を行ってくれます。つまり、リモート呼び出しの詳細をクライアント・アプリケーションから隠ぺいしているのが、代理オブジェクトなのです。もちろん、これらの処理は代理オブジェクトとORBが協力して行います。また、代理オブジェクトの実装コードは、インターフェイス定義から生成されるスタブ・コードの中に含まれています。
 |
| 図2 スタブとスケルトンの役割 |
 |
TIPS1 スタブとスケルトン
|
|
本文で説明したスタブとスケルトンの仕組みは、プロキシ・パターンと呼ばれるデザイン・パターンを実践したものです。この基本的な仕組みはすべての分散オブジェクト技術でほぼ共通しているのですが、用語と実際のコード生成方法が少し異なります。 まず用語ですが、CORBAとJavaRMIでは、本文中の説明のとおり、クライアント側の生成コードをスタブ、サーバ側の生成コードをスケルトンと呼んでいます。HORBでは、クライアント側の生成コードをプロキシ、サーバ側の生成コードをスケルトンと呼んでいます。一方、COM+では、クライアント側の生成コードをプロキシ、サーバ側の生成コードをスタブと呼んでいます。 次に、コードの生成方法の違いについてです。CORBAでは、IDL定義をIDLコンパイラでコンパイルすることで、プログラミング言語（JavaやC++）のソース・ファイルとしてスタブとスケルトンが生成されます。JavaIDLでは、オブジェクトの実装クラス（インターフェイスを実装したJavaクラス）をrmicコンパイラでコンパイルし、スタブとスケルトンのクラス・ファイルを生成します。このため、先にサーバ側でオブジェクトを実装しておかないと、クライアント側でスタブが利用できないというジレンマがあります。HORBでは、Javaのインターフェイス定義またはクラス定義をhorbcコンパイラでコンパイルし、プロキシとスケルトンのコード（ソース・ファイルとクラス・ファイル）を生成します。一方、COM+では、IDLでのインターフェイス定義は必ずしも必要ありませんが、MIDL（Microsoft IDL）コンパイラを使用して、IDL定義からCあるいはC++用のプロキシとスタブ、あるいはタイプライブラリを生成することができます（COM+の詳細については第4回で説明します）。 |
|
●スケルトンの役割
逆に、サーバ・アプリケーションからリモート呼び出しの詳細を隠ぺいしているのがスケルトンです。スケルトンは、クライアントから受信した要求メッセージをアンマーシャリングし、アプリケーション開発者が作成した実装オブジェクトのメソッドを呼び出してくれます。そして、メソッドの実行結果を応答メッセージにマーシャリングして、クライアントに返却します。
| ■オブジェクト・リファレンス |
同一プロセス内でオブジェクトのメソッドを呼び出す場合、つまりクライアントとサーバが同じプロセスに存在する場合には、クライアントはオブジェクトに対する参照またはポインタを使用してメソッドを呼び出すことができます。しかし、プロセスやマシンをまたがってメソッドを呼び出すにはどうしたらよいのでしょうか。この質問に対する答えの半分は、前項のスタブとスケルトンについての説明でお分かりいただけると思います。つまり、クライアントは同一プロセス内の代理オブジェクトを呼び出すことで、その舞台裏でリモート呼び出しが起動されるわけです。それでは、代理オブジェクトはどのようにしてリモート・オブジェクトの身元やネットワーク・アドレスを特定できるのでしょうか。これを解くカギがオブジェクト・リファレンスです。
オブジェクト・リファレンスは、分散環境でオブジェクトを一意に特定して、そのオブジェクトにアクセスするのに必要なすべての情報が格納されているデータです。どのような情報が含まれているのかは、それぞれの分散オブジェクト標準に依存していますが、一般的にサーバに到達するためのプロトコルやアドレス情報、そしてサーバ内でオブジェクトを特定するための情報が含まれています。
|
TIPS2 位置の透過性
|
|
分散オブジェクト技術のメリットの1つが位置の透過性です。位置の透過性とは、クライアントはオブジェクトがネットワーク上のどこに存在するのかを意識することなく、そのメソッドを呼び出せるということです。これにより、クライアントはプロセス内のオブジェクトでもリモートのオブジェクトでも、まったく同一のプログラムで扱うことができるようになります。しかも、トランザクションやセキュリティに関しても同様の扱いを適用することが可能になります。この位置の透過性を実現しているのが、 （1）オブジェクト・リファレンスへのプロトコルやアドレス情報のカプセル化と の2つのカプセル化なのです。 |
|
●オブジェクト・リファレンス取得方法
オブジェクト・リファレンスは、基本的にはオブジェクトを実装するサーバ側で作成するのですが、それでは、クライアントはこのオブジェクト・リファレンスをどのようにして入手するのでしょうか。この方法は、それぞれの分散オブジェクト標準によって若干異なります。
COM+の場合には、COM+ライブラリが提供するファクトリAPIを使用して、クライアントがオブジェクトの作成とオブジェクト・リファレンスの返却を依頼します。こうして返却されたオブジェクト・リファレンスが代理オブジェクトに対するインターフェイス・ポインタとしてメソッド呼び出しで使用されます。これについては、第4回連載で解説します。
JavaRMIでは、JNDI （Java Naming and Directory Interface）、または簡易版のネーミング・サービスであるRMIレジストリ（いずれも第５回で解説します）を使用してオブジェクト・リファレンスをサーバからクライアントに配布します。
これに対して、CORBAでは、オブジェクト・リファレンスの取得方法が多岐にわたり、アプリケーション開発者はこの中から最適な方法を選択することができるようになっています。この選択が性能とスケーラビリティに影響することもしばしばですので、どの方法を選択するかは設計者の腕の見せどころでもあります。選択肢としては、CORBAネーミング・サービス、CORBAトレーディング・サービス、ファイル渡し、オブジェクトURL（いずれも第3回で解説します）などがあります。どの方法を選択すべきかについては、最終回に詳しく説明します。
 |
| 図3 オブジェクト・リファレンス配布の例 |
今回は、分散オブジェクト技術に共通する考え方と仕組みを解説しました。次回からは、CORBA、COM+、JavaRMIとEJB、HORB、そしてJiniという順番で、各分散オブジェクト技術を詳細に見ていくことにします。
| INDEX | |
| スキルアップのための分散オブジェクト入門 | |
| 第1回 分散オブジェクト技術が必要なわけ（2002/3/19) | |
 |
第2回 分散オブジェクトのしくみを理解する（2002/4/4） |
|
第3回 開発手順からCORBAを理解する（2002/4/25） |
|
| 第4回 開発手順から分かるEJBとJavaRMI（2002/6/25） | |
| 第5回 分散オブジェクト技術としてのHORBとCOM+（2002/8/21） | |
| 第6回 現実モデルはWebサービスとの共存（2002/10/4） | |
 |
Java Solution全記事一覧 |
- 実運用の障害対応時間比較に見る、ログ管理基盤の効果 （2017/5/9）
ログ基盤の構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。今回は、実案件を事例とし、ログ管理基盤の有用性を、障害対応時間比較も交えて紹介 - Chatwork、LINE、Netflixが進めるリアクティブシステムとは何か （2017/4/27）
「リアクティブ」に関連する幾つかの用語について解説し、リアクティブシステムを実現するためのライブラリを紹介します - Fluentd＋Elasticsearch＋Kibanaで作るログ基盤の概要と構築方法 （2017/4/6）
ログ基盤を実現するFluentd＋Elasticsearch＋Kibanaについて、構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。初回は、ログ基盤の構築、利用方法について - プログラミングとビルド、Androidアプリ開発、Javaの基礎知識 （2017/4/3）
初心者が、Java言語を使ったAndroidのスマホアプリ開発を通じてプログラミングとは何かを学ぶ連載。初回は、プログラミングとビルド、Androidアプリ開発、Javaに関する基礎知識を解説する。
 |
|
|
|
|
