連載

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

第4回　開発手順から理解するJavaRMIとEJB

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

今回は、JavaRMIとEJBを扱います。JavaRMI（Java Remote Method Invocation）は、Javaオブジェクトのリモート・メソッド呼び出し機能で、J2SEに含まれています。一方、EJB（Enterprise JavaBeans）は、Javaによるコンポーネント開発のためのフレームワークで、J2EEに含まれています。EJBは、リモート・メソッド呼び出しのためにJavaRMIを使用しています。


JavaRMIとEJB

今回の内容
JavaRMIとEJBの特徴
開発手順からJavaRMIを知る
開発手順からEJBを知る

　それでは、JavaRMIとEJBの特徴を見ていきましょう。EJBは、COM+と同様に、単なる分散オブジェクト技術にとどまらず、コンポーネント開発のためのフレームワークを提供しています。しかし、ここではEJBの分散オブジェクトとしての側面だけに焦点を当てていきます。

■JavaRMIとEJBの特徴

　最初にJavaRMIとEJBの特徴を簡単にまとめておきます。

●特定のOSに依存しないピュアJavaのための分散オブジェクト技術
　JavaRMIとEJBが特定のOSに依存しないのは、JavaのOS非依存性のおかげです。従って、J2SEが使える環境であれば、どこでもJavaRMIのご利益にあずかることができますし、製品がサポートする環境であれば、どこでもEJBを使うことができます。

　 JavaRMIとEJBは、JavaのJavaによるJavaのための分散オブジェクト技術です。当然ながら、非分散Javaプログラムとの相性が良く、従来のJavaアプリケーションをほんのわずか修正するだけで、JavaRMIベースの分散アプリケーションに変更することができてしまいます。

●Javaのインターフェイスでリモート・インターフェイスを定義する
　これは1つ目の特徴と関連しますが、JavaRMIとEJBではJavaインターフェイスでリモート・オブジェクトのインターフェイス定義を行います。このため、CORBAのIDLのような新たなインターフェイス定義言語を習得する必要がありません。

●RMI over IIOPによる相互運用性
　JavaRMIとEJBはピュアJavaソリューションですが、決して閉鎖的ではなく、ほかの分散オブジェクト技術と接続することができます。その場合、RMI over IIOPが使用されます。

TIPS1 JRMPとRMI over IIOP
　JavaRMIには2つの通信プロトコルがあります。正確にいうと、これ以外のベンダ固有プロトコルを実装している製品もありますが、ここでは2つの標準プロトコルだけを考えます。

 　第1のプロトコルは、JRMP（Java Remote Method Protocol）と呼ばれるJavaRMIのネイティブなプロトコルです。これはJavaRMIでしかサポートされていないため、このプロトコルで通信する場合には、相手もJavaRMIに限定されます。

　JavaRMIのもう1つのプロトコルは、EJBでも採用されているRMI over IIOPです。こちらのプロトコルを使うことで、Java以外の相手との通信が可能になります。一方、JavaRMIではローカル・オブジェクトをリモート・メソッドの引数として受け渡しすることができますが、その場合、引数として渡されたオブジェクトのコピーが相手に送り届けられることになります。一般に、このような引数の渡し方を「値渡し」と呼んでいます。ところが、もともとのCORBAにはオブジェクトの値渡しという概念がありませんでした。そこで、RMI over IIOP仕様を策定する際に「値型」と呼ばれる新たな型がCORBAのIDLに追加されて、これによってオブジェクトの値渡しが実現されました。

　この値オブジェクトがJavaのローカル・オブジェクトに相当するのですが、CORBAプログラマから見ると複雑怪奇で扱いにくいデータ型が導入されるはめになってしまったわけです。この辺りの注意点は、連載第１回のTIPS3をご覧ください。


■開発手順からJavaRMIを知る

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

●インターフェイス定義

　JavaRMIのアプリケーションを作成する場合、まずJavaインターフェイスでオブジェクトのインターフェイスを定義します。 リスト1がインターフェイス定義の例です。通常のローカル・オブジェクトのJavaインターフェイスと異なる点は、java.rmi.Remoteインターフェイスを拡張している（extends）点と、各メソッドがjava.rmi.RemoteException例外をスローする点だけです。

リスト1 インターフェイス定義例
public interface Customer extends java.rmi.Remote {
    String getId() throws java.rmi.RemoteException;
    String getMailAddress() throws java.rmi.RemoteException;
    void ChangeMailAddress(String address)
        throws java.rmi.RemoteException;
    void SendMail(String text)
        throws java.rmi.RemoteException, MailException;
}

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

　 次にこのインターフェイスをサポートするサーバ・クラスを作成します。これも非常に簡単で、図1のCustomerインターフェイスの各メソッドにアプリケーション・ロジックを実装するだけです。

　さらにメイン・プログラムも作成する必要があります。メイン・プログラムでは、リモート・オブジェクトの作成とオブジェクト・リファレンスの登録を行います。オブジェクト・リファレンスの登録には、JNDI（用語解説1）またはRMIレジストリ（用語解説2）のいずれかを使用します。

用語解説1　JNDI（Java Naming and Directory Interface）
Javaプログラムからネーミング・サービスおよびディレクトリ・サービスにアクセスするための標準インターフェイス。ネーミング・サービスは、「データ」を「名前」付きで格納したり、逆に「名前」から「データ」を検索するためのサービス。ディレクトリ・サービスでは、ネーミング・サービスの機能に加えて、「データ」を記述するためのメタデータも格納することができます。JNDIは、さまざまなネーミング・サービス（CORBAネーミング・サービスなど）やディレクトリ・サービス（LDAPなど）を使って実装することができますが、こうした実装に依存しない標準APIをアプリケーションに提供してくれます。

用語解説2　RMIレジストリ
JavaRMIのオブジェクト・リファレンスを名前付きで登録、検索するための簡易ネーミング・サービス。

●スタブとスケルトンの生成

　上記で作成したサーバの実装クラスから、rmicコンパイラを使用してスタブとスケルトンコードを生成します。JavaRMIでは、インターフェイス定義からではなく実装クラスからスタブとスケルトンを生成する点に注意してください。また、これらはクラス・ファイルとして生成されます（オプションでソース・ファイルを残すことも可能です）。また、rmicコンパイラの引数で、JRMPを使用するのかRMI over IIOPを使用するのかを選択することができます。

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

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

　クライアント・プログラムでは、JNDIまたはRMIレジストリを使用して、リモート・オブジェクトのリファレンスを取得します。そして、リファレンスを使用してリモート・オブジェクトのメソッドを呼び出します。

■開発手順からEJBを知る

　前項で見たように、JavaRMIのサーバ開発者は、メイン・プログラムを作成し、その中でオブジェクトの作成やネーミング・サービスへの登録処理を行う必要がありました。この点はCORBAとまったく同じです。これに対して、EJBのサーバ開発者は、メイン・プログラムを作成しません。そして、オブジェクトの作成やネーミング・サービスへの登録といった定型的な処理は、EJBコンテナがすべて自動的に行ってくれるので、サーバ開発者は、インターフェイス定義とビジネス・ロジックの実装に専念することができます。具体的にサーバ開発者が作成するのは次の4つだけです。

  • リモート・インターフェイス

  • Homeインターフェイス

  • Enterprise Beanの実装クラス

  • デプロイメント・ディスクリプタ

　リモート・インターフェイスはオブジェクト（Enterprise Bean：以下では単にBeanと呼ぶことにします）の外部インターフェイスで、JavaRMIやCORBAのインターフェイス定義と同じ役割を果たします。Homeインターフェイスは、クライアントがBeanインスタンスの作成、検索、あるいは削除を要求するためのファクトリ・インターフェイスです。次の実装クラスは、サーバ・アプリケーションの中心部で、ここでは主にBeanのビジネス・メソッドを実装します。最後のデプロイメント・ディスクリプタでは、Beanの種類、クラス名、トランザクション属性、アクセス制御情報などを設定します。トランザクションやセキュリティの制御は、ここでの設定を基に実行時にEJBコンテナが自動的に行ってくれます。従って、サーバ開発者がこれらの処理をハードコードする必要はありません。

　このように、EJBではサーバ開発者はBeanの実装だけに専念できますので、これをうまく使うことで開発生産性を高めることができます。

TIPS2　EJBで本当に生産性が上がるのか？
　上で説明したように、EJBではコンテナがBeanのインスタンス化、ネーミング・サービスへの登録、トランザクション制御、アクセス制御などを自動的に行ってくれるため、サーバ開発者はアプリケーション・ロジックの実装に思い切り専念することができます。これに加えてさらに、一度開発したBeanの再利用によって開発生産性を向上させることができるというのが、EJBの宣伝文句の1つです。

 　この宣伝はうそではありませんが、生産性を向上させるためにはいくつかの条件をクリアしなければなりません。正しい設計、技術者のスキル、適切なプロジェクト管理、適切な適用分野、などなどがクリアしなければならない代表的な条件ですが、ここでは最後の適用分野について考えてみましょう。どんな技術にも得手不得手があり、その技術がぴたりと当てはまる分野で使わなければ、逆に生産性が下がってしまうことになります。EJBの場合がまさにそうです。

 　それでは、EJBが得意とする分野はどこでしょうか。典型的な例は、J2EEのブループリントに載っているようなWebアプリケーション・サーバの開発です。

 　逆に、苦手な分野はどこなのでしょうか。EJBの苦手分野の典型は、複数言語のアプリケーションが混在している環境、単なるアプリケーション間の通信インフラとして使いたい場合、ほかの通信プロトコルを同時に処理しなければならない場合、などなどです。これらのケースでは、EJBのさまざまな制限が顕在化してきます。EJBの制限事項を羅列してみると、次のようなものです。
  • オペレーション呼び出しの引数は、Serializableを実装した型でなければならない（JavaRMIの制限）
  • 読み書き可能なスタティック・フィールドの使用が禁止されている（EJBの制限）
  • ソケットやI/O関連の機能が大幅に制限されている。例えば、ソケットでのリスンが禁止されている（EJBの制限）
  • アプリケーション側でのスレッドの作成や制御が禁止されている（EJBの制限）
  • セッションBeanはnon-reentrantでなければならない。このため、クライアントの複数スレッドから同じセッションBeanのメソッドを同時に呼び出すことができない（EJBの制限）
  • アプリケーション側でのクラス・ローダの作成や取得が禁止されている（EJBの制限）
  • アプリケーション側でのセキュリティ・マネージャの作成が禁止されている（EJBの制限）
  • Bean管理トランザクションのセッションBean以外のEJBからトランザクションを開始することはできない（EJBの制限）
　アプリケーション開発者からスレッドやセキュリティ、あるいはトランザクションの詳細を隠ぺいして開発生産性を高めるというEJBの目的からすると、これらの制限の多くは理にかなったものです。従って、通常のWebアプリケーションを開発する場合には、これらの制限はほとんど問題になりません。しかし、例えば、EJBをアプリケーション間の汎用的な通信インフラとして使いたい場合には、これらの制限は足かせでしかありません。こうした場合には、やはりCORBAのような汎用的な分散オブジェクト技術が最適です。

 　誤解していただきたくないのは、ここでは「EJBよりもCORBAの方が優れている」ということがいいたいわけではありません。ここで声を大にしていいたいのは、「EJBとCORBAを適材適所で使い分けることが重要である」ということです。適材適所で思い出しましたが、Webサービスと従来の分散オブジェクト技術も、適材適所で使い分けないと失敗します。これについては、本連載の最後の方でお話ししたいと思います。

　

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）


筆者プロフィール
小野沢 博文（おのざわ ひろふみ）

現在、日本アイオナテクノロジーズ株式会社にて分散オブジェクト・システムの技術コンサルタントを務める。
1991年まで富士通株式会社にてプラズマ実験データ処理システムの開発やシステム運用に携わった後、1996年以前は日本DECにてCORBA準拠のObjectBrokerおよびDCEの開発を担当。また、MIA、NMF SPIRITなどの標準化活動にも参加する。 1997年1月から1999年8月までは、TCSIにて分散オブジェクト技術を適用したテレコム向けの大規模ネットワーク管理システムの開発に携わる。

[著書一覧]
『CORBA完全解説 基礎編』（ソフト・リサーチ・センター）、『CORBA完全解説 応用編』（ソフト・リサーチ・センター）、『分散オブジェクト指向技術CORBA』（ソフト・リサーチ・センター）、『イントラネットのためのオブジェクト指向データベース技術』（共著、ソフト・リサーチ・センター）、『分散コンピューティング環境 DCE』 （監著、共立出版）、『トランザクション処理システム入門』（共訳、日経BP）


Java Solution全記事一覧




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

注目のテーマ

Java Agile 記事ランキング

本日 月間
＠IT