連載

スキルアップのための分散オブジェクト入門

第5回　分散オブジェクト技術としてのHORBとCOM＋

日本アイオナテクノロジーズ
主席 コンサルタント
小野沢 博文
2002/8/21		 本連載について

今回は、その他の分散オブジェクト技術としてHORBとCOM＋を紹介します。HORBは、日本で誕生した分散オブジェクト技術で、非常にシンプルで扱いやすい点が特徴です。COM+は、説明するまでもなくマイクロソフトが開発した分散オブジェクト技術です。本連載で、CORBAからCOMまで幅広く理解していただくことで、分散オブジェクト技術の基礎と全体像を把握してください。
次回最終回は「分散オブジェクト技術とWebサービス」と題して、分散オブジェクトとWebサービスが共存する将来のコンピューティングモデルについて解説する予定です。（編集局）


HORBの特徴

　HORBは、1995年に電子総合技術研究所（現在は「産業技術総合研究所」） で誕生した世界初のJava ORBです。その後、オープンソースとして多くのボランティアによって支えられて発展してきました。

　正直に打ち明けると、筆者はこの連載を開始するまではHORBを使ったことがありませんでした。そこで急きょ、豆蔵の萩本氏に相談し、HORBのホームページから最新版をダウンロードして試してみることになりました。そこで一番感じたのは、何て敷居が低いのだろうということでした。このページからダウンロードできる「HORB Flyer's Guide」というチュートリアルに従ってサンプル・プログラムを一通り動かして、その概要を理解するのにわずか数時間しかかかりませんでした。ここではHORBの概要しかご紹介できませんが、HORBを理解する最短の近道として、実際にダウンロードして、「HORB Flyer's Guide」または「HORBと遊ぼう」（Java Solution）を参考にしながら、実際にHORBと遊んでみることをお勧めします。

■ローカルJavaとの親和性

　まず次のコード例を見てください。これは、remote_host.co.jpという架空のリモート・ホスト上にオブジェクトを作成して、そのgreetingメソッドを呼び出すクライアント・プログラムです。

Hello_Proxy hello = new Hello_Proxy("horb://remote_host.co.jp");
String result = hello.greeting("こんにちは、Clientです。");

　ここで、Hello_Proxyはリモート・オブジェクトに対するプロキシ・クラスです。プロキシ（代理）というのは、リモート・オブジェクトに代わってクライアントから呼び出され、ORBと協力してリモート・オブジェクトに要求メッセージを発行するローカル・オブジェクトです（詳細は連載第2回を参照してください）。

　上のコードで特徴的な点は、クライアントが直接プロキシ・オブジェクトをnewオペレータで作成している点です。その結果、リモート・ホスト上にターゲット・オブジェクトが作成されます。つまり、HORBでは、あたかもローカルなJavaオブジェクトを作成する感覚で、リモート・オブジェクトをインスタンス化することができるのです。これはCORBAにもJavaRMIにもないHORB独特の機能で、生成モデル（用語解説1）と呼ばれています。

　この例のように、HORBはローカルJavaと極めて親和性の高いプログラミング・モデルをサポートしています。

図1　生成モデル

■特定のOSに依存しないピュアJavaのための
  分散オブジェクト技術

　HORBは純粋にJavaで書かれており、しかも特定のプラットフォームに依存したネイティブ・メソッドを使用していないため、J2SEが使える環境にHORBをインストールするだけで、どこでも利用できます。この特徴は、JavaRMIやEJBと同様です。

■オブジェクト・コンテナ

　連載第4回で、CORBAやJavaRMIではアプリケーション開発者がサーバのメイン・プログラムを必ず書かなければならないのに対して、EJBではアプリケーション開発者はメイン・プログラムを書く必要もないし書くこともできない、という話をしました。つまり、EJBでは、アプリケーション開発者が作成するのは、オブジェクト（Enterprise Bean）のインターフェイスと実装だけで、そのインスタンスを作成して実行するのはコンテナの役割でした。これによって、アプリケーション開発者はビジネス・ロジックの開発に専念することができる半面、アプリケーション構造の柔軟性が制限されることになります。

　HORBでは、CORBAやJavaRMI流の手法とEJB流の手法の両方がサポートされています。つまり、アプリケーション構造を自由に設計したい場合には、メイン・メソッドを持つスタンドアロン・プログラムとしてサーバを作成すればよいし、面倒なことを一切省略したい場合には、オブジェクトの実装クラスだけを作成して、そのインスタンス作成と実行をコンテナに一任することができます。HORBでは「オブジェクト・コンテナ」という用語は使用していませんが、基本的な考え方はEJBコンテナと同じです。

■本格的な分散オブジェクト機能のサポート

　HORBは簡単だからといって侮ってはいけません。次のようなORBとしてのかなり高度な機能をサポートしています。

●HorbURL
　CORBAのオブジェクトURLと同様に、URLでオブジェクトを指定して利用することができます。HORBでは、これをHorbURLと呼んでいます。次はその例です。

horb://remote_host.co.jp:8887/MyCustomer

　HorbURLには、ホスト名、ポート番号、およびサーバ内でオブジェクトを一意に特定するオブジェクト・キーを指定することができます。シンタックスはCORBAのオブジェクトURLと非常によく似ています。

●非同期呼び出し
　通常のJavaのメソッド呼び出しでは、処理が完了するまで呼び出し元はその場でじっと待たされてしまいます。これはいわゆる、同期呼び出しと呼ばれる方式です。HORBでは、この同期呼び出しとともに非同期呼び出しがサポートされています。非同期呼び出しでは、メソッド呼び出しを実行すると直ちにクライアント・アプリケーションに制御が戻ってきます。その後、クライアントはポーリングまたはコールバックでサーバからの応答を受け取ります。非同期呼び出しを使うことで、クライアントは複数の処理を並行して実行することができます。

●オブジェクトの永続化
　HORBでは、オブジェクトの状態を永続化するための簡単な仕組みが提供されています。

●ネーミング・サービス
　CORBAのネーミング・サービスと同じように、オブジェクト・リファレンスに名前を付けて登録し、クライアントから参照することができます。

●分散アクセス制御リスト
　リモート・オブジェクトのクラスやメソッドごとに、アクセスを許すクライアント・ホストやユーザーを指定することができます。

●プロトコル・プラグイン
　通信プロトコルを実装してプラグインとして追加することができます。HORBでは、HORB基本プロトコル以外にIIOPやSOAPがサポートされていますが、基本プロトコルも含めてこれらはすべてプロトコル・プラグインとして実装されています。この仕組みを利用して、例えば、組み込みシステム向けに最適化されたプロトコルを独自に実装することも可能です。

用語解説1　生成モデルと接続モデル
HORBでは、クライアント側にプロキシ・オブジェクトを作成すると、その結果として自動的にサーバ側にリモート・オブジェクトを作成するといった芸当ができます。この方式は生成モデルと呼ばれています。これに対して、あらかじめサーバ側でオブジェクトを作成しておき、これを複数のクライアントから共有する方式を選択することもできます。こちらの方式は接続モデルと呼ばれています。前者はCOM+に近い方式で、後者はCORBAやJavaRMIに近い方式です。HORBではこの両者がサポートされています。

開発手順からHORBを知る

　それでは、HORBを使用したアプリケーションの開発手順を追いながら、その特徴をもう少し詳しく見ていくことにしましょう。

■インターフェイス定義

　ほかの分散オブジェクト技術と同じように、まずはリモート・オブジェクトのインターフェイスを定義します。このためにHORBではJavaのインターフェイスを使用します。ただし、通常のJavaプログラミングと同じように、インターフェイス定義をスキップして直接実装クラスを作成してしまうこともできます。ここでは、実装とインターフェイスの分離というオブジェクト指向の鉄則を守り、次のようなインターフェイス定義から出発します。

リスト1 インターフェイス定義例
public interface Customer {
  String getId();
  String getMailAddress();
  void ChangeMailAddress(String address);
  void SendMail(String text);
}

　このインターフェイスは、第4回で説明したJavaRMIのインターフェイスとよく似ていますが、JavaRMIのようにjava.rmi.Remoteインターフェイスを継承したり、java.rmi.RemoteException例外を返却したり、といった面倒な制約はありません。

■サーバ・プログラムの作成

　ここでは、HORBの使いやすさを強調するために、CORBAやJavaRMIのようにサーバ・アプリケーションを自分で作成する方法ではなく、オブジェクトの実装クラスだけを作成して、それをコンテナで実行する方法を取ります。そのために必要なコーディングは、Customerインターフェイスを実装するクラスを次のように作成するだけです。

リスト2　リモート・オブジェクトの実装例
public class CustomerImpl implements Customer {
  public String getId() {　… }
  public String getMailAddress() { … }
  public void ChangeMailAddress(String address) { … }
  public void SendMail(String text) { … }
}

■プロキシとスケルトンの生成

　プロキシとスケルトンは、インターフェイス定義または実装クラスのいずれからでも生成することができます。ここでは、オブジェクトの実装クラスをクライアントから隠ぺいしたいので（TIPS1参照）、インターフェイス定義からプロキシとスケルトンを生成します。プロキシとスケルトンの生成には、次のようにhorbcコマンドを使用します。

horbc Customer.java

　このコマンドは、デフォルトではプロキシとスケルトンをクラス・ファイルとして生成してくれます。

図2　インターフェイス定義、実装クラス、プロキシ、スケルトンの関係

■クライアント・プログラムの作成

　用語解説1で説明したように、クライアントからのオブジェクトへの接続方法には生成モデルと接続モデルの2種類がありました。前章の冒頭では生成モデルのコード例をお見せしましたので、ここでは接続モデルの例を取り上げることにしましょう。

リスト3　クライアントのプログラム例
Customer　customer =
new Customer_Proxy("horb://remote_host.co.jp/customer1013");
customer.SendMail("毎度ありがとうございます。");

　ここでは、プロキシ・クラスのコンストラクタでオブジェクト・キーまで含んだHorbURLを指定することで、既存のリモート・オブジェクトに接続しています。Customer_Proxyのコンストラクタの引数の最後の部分customer1013が、オブジェクトを一意に特定するためのオブジェクト・キーです。

■サーバの実行

　今回は、自分でサーバ・アプリケーションを作成するのではなく、HORBが提供するコンテナでオブジェクトをホスティングする方法を取りました。このオブジェクト・コンテナは次のようにhorbコマンドで起動します。コンテナにどのようなオブジェクトを作成してもらうのかはコンフィグレーション・ファイルに記述しておき、そのファイル名をhorbコマンドの引数で与えます。

horb -conf Customer.conf

　ここで、コンフィグレーション・ファイルCustomer.confは次のような内容です。

object[0].className=Customer
object[0].implementation=CustomerImpl
object[0].objectID=customer1001

object[1].className=Customer
object[1].implementation=CustomerImpl
object[1].objectID=customer1013
...

　作成するオブジェクトごとに、インターフェイス名、実装クラス名、オブジェクト・キーを指定しているのがお分かりいただけると思います。

TIPS1　実装クラス名のクライアントからの分離
　連載第1回のTIPS1で、インターフェイスを実装から分離することの重要性を強調しました。しかし、少なからぬ分散オブジェクト技術ではこの分離が完全には実現されていません。

　連載第4回で取り上げたJavaRMIでは、インターフェイス定義からではなくオブジェクトの実装クラスからスタブとスケルトンを生成しました。このため、クライアント側の実装作業がサーバ側の実装作業に依存してしまうことになるので、これはありがたくありません。

　HORBでは、インターフェイス定義または実装クラスのいずれからでもプロキシとスケルトンを生成することができます。実装クラスからプロキシを生成した場合には、プロキシ・クラス名は実装クラスに依存した名前になってしまい、サーバ側の実装クラス名をクライアントのプログラミングに持ち込んでしまうことになります。例えば、CustomerImpl実装クラスから生成したプロキシはCustomerImpl_Proxyというクラス名になります。この機能は、インターフェイスを使わなくてもクラスだけでオブジェクトを操作できるローカルJavaの簡便さを、そのままリモート・オブジェクトでも享受できるようにしたためでしょう。

　 これに対して、インターフェイス定義からプロキシを生成すれば、サーバ側で実装クラス名を自由に選択できるようになります。今回使った方法がこれです。この方法を使うと、クライアントのコーディングにサーバの実装クラスに関する情報が一切現れてきません。このため、後から実装クラスを別のものに置き換えたり、実行時に複数の実装クラスから1つを選択するといった芸当ができるようになります。これは、クライアントとサーバ間の実装依存度を減らして、変更に強いシステムを開発することにつながります。


　
1/2

　第5回 分散オブジェクト技術としてのHORBとCOM＋
Page1
HORBの特徴
開発手順からHORBを知る
  Page2
COM+に見る分散オブジェクトの特徴
  

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全記事一覧




Java Agile フォーラム 新着記事
＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

注目のテーマ

Java Agile 記事ランキング

本日 月間
＠IT