［技術講座］

目次

1. はじめに

CORBA Component Model の仕様にはコンポーネントのライフサイクルとして、コンポーネント の作成・実装、コンポーネントの接続・結合、コンポーネントの分散配置、コンポーネントの 実行というサイクルがあり、それぞれ、コンポーネントモデル、パッケージングモデル、 分散配置モデル、コンテナモデルという対応するモデルが規定されています。第一回目の記事では、 コンポーネントモデルを取り上げ、CCM で扱われるコンポーネントの外観について解説しました。 コンポーネントモデルは、CCM でアプリケーションを開発する上で重要な部分ですので、本記事を読まれる方は 第一回目の内容も見てみてください。

さて、第二回目では、CCM コンポーネントの実装に焦点を当てた コンポーネント実装フレームワーク ( Component Implementaion Framework : CIF ) とコンテナモデルについて見ていきます。今回のテーマは、CCM で扱われるコンポーネント の振る舞いです。

※ 当初、第二回目では CCM を実装した製品を用いて、CCM による開発の流れを EJB と 対比させながら解説しようと考えていましたが、予定していた CCM 製品が使用できなくなったため内容を変更しました(^^;)。次回は CCM を実装した製品を用いて解説を行います。 また、本記事の最後に現在 ( 2002 年 5 月 24 日 ) 使用できる CCM 仕様を実装した製品の機能についてまとめています。 いち早く CCM 製品を利用したい方は参考にしてください。

2. CCM アプリケーションの開発プロセス

CCM で扱われるコンポーネントの振る舞いについて説明する前に、CCM アプリケーションを開発する場合 の開発プロセスについて見てみましょう。CCM アプリケーションを開発する場合は、図 1 のような開発プロセス に沿って開発することになります。EJB の仕様でロール [9] が規定されているように、CCM においても開発 プロセスに応じたロールが存在します。

図 1： CCM の開発プロセス

まず、コンポーネント設計者が拡張 IDL と CIDL ( Component Implementation Definition Language ) を 用いて、コンポーネントが提供するインターフェースとコンポーネントの振る舞いを定義します。CIDL は コンポーネント実装フレームワークで規定されている言語であり、コンポーネントの永続化やトランザク ション管理などのインフラに関する機能を定義することになります。CIF と CIDL については、第 4 章で説明します。

次に、拡張 IDL で定義されたサービスをコンポーネント開発者が実装します。この時、コンポーネント開発者は、 拡張 IDL ファイルから拡張 IDL コンパイラによって生成されるスタブ、スケルトンを使用します。 また、CIDL コンパイラが CIDL ファイルに基づいてコンポーネントの実装に必要なインフラ部分の スケルトンを自動生成してくれるので、コンポーネント開発者はビジネスロジックだけに集中した開発 が行えるようになっています。

コンポーネントの実装が完了すると、コンポーネントプロバイダによっていくつかのファイルを パッケージングする形で再利用可能なコンポーネントが作成されます。このパッケージングされた コンポーネントは、CAR ( Component ARchive ) ファイルと呼ばれ、 ZIP 形式で圧縮したアーカイブ ファイル( 拡張子は .car ) となります。CAR ファイルは、コンポーネントの実装、及び、 拡張 IDL ファイル、CCD ( CORBA Component Descriptor ) ファイル ( 拡張子は .ccd )、 CSD ( CORBA Software Descriptor ) ファイル ( 拡張子は .csd )、 さらに PFD ( Property File Descriptor ) ファイル( 拡張子は .cpf ) から構成されています。 CCD はコンポーネントの振る舞いを記述した XML ベースのファイル になります。これは、CIDL コンパイラによって自動的に生成されるので、コンポーネント開発者が直接記述する必要はありません。 CSD はコンポーネントを実行する上で必要な環境情報等を記述した XML ベースファイル になります。例えば、コンポーネント実装への参照 ( ファイル名や URL ) や CCD ファイルへの参照、実装言語やオペレーティングシステムに依存した情報などが CSD に記述されることになります。また、PFD は コンポーネントやホームがもつ属性に対して値を設定するためのプロパティファイルになります。

パッケージングされたコンポーネントは、システム管理者によって実行可能なアプリケーションとしてコンテナ上に配置される場合もありますが、場合によっては、より大きなアプリケーションの部品として使用されることもあります。アプリケーション構築者は、これらの再利用なコンポーネントを組み合わせて一つのまとまったアプリケーションを構築します。例えば、拡張 IDL で定義した Ports の種類に応じて、インターフェースによる接続 ( Facet と Receptacle の接続 ) やイベントを介した接続 ( Event Source と Event Sink の接続 ) を指定することによって、一つの大きなアプリケーションを構築します。そして、AAR ( Assembly ARchive ) と呼ばれる ZIP 形式で圧縮された CCM アプリケーションのファイル ( 拡張子は .aar ) が完成します。AAR ファイルの中には、コンポーネント間の接続に関する情報を記述した XML ベースの CAD ( Component Assembly Descriptor ) ファイル ( 拡張子は .cad ) が含まれることになります。また、AAR ファイルにはコンポーネントやホームがもつ属性に対して値を設定した PFD ファイルも含まれます。

最後にシステム管理者が、完成した CCM アプリケーションをコンテナ上に配置します。この配置の処理は、ほとんどがデプロイメントツール等によって自動的に行われるので、実行環境に関する設定等を行う必要はありません。

以上、CCM コンポーネントの開発プロセスを見てきましたが、この開発プロセスからわかるように CCM によるアプリケーション開発では、拡張 IDL でコンポーネントのインターフェースを定義すること、 CIDL でコンポーネントの振る舞いを定義することが重要 となっています。次の章では、CIDL で定義できるコンポーネントの振る舞いについて見ていきたいと思います。

3. コンテナモデル

コンテナモデルでは、CCM コンポーネントに関する 4 つを要素を規定しています。それは、外部 API タイプ、コンテナ API タイプ、CORBA Usage Model、コンポーネントのカテゴリになります。これらの要素は 図 2 で表されたコンポーネント、及び、コンテナ、従来の CORBA アーキテクチャ （ POA， ORB， CORBA サービスを表しています ) 間がどのように関係しているのかを定めています。

図 2： コンテナモデルのアーキテクチャ

外部 API タイプは、コンポーネント開発者とコンポーネントクライアント間のインターフェースを規定しています。図 2 中に存在する External interfaces が外部 API タイプに該当するインターフェースで、Home インターフェースとコンポーネントインターフェースの 2 つから構成されています。CCM ではこれらのインターフェースを拡張 IDL によって宣言します。また、外部 API タイプの Home インターフェースにプライマリキーが存在するかどうかでコンポーネントの振る舞いに影響があります。なお、EJB では、コンポーネントインターフェースが EJBObject インターフェースに対応し、Home インターフェースが EJBHome インターフェースに対応します。

コンテナ API タイプは、CCM コンポーネントとコンテナ間のインターフェースを規定しています。コンテナ API タイプには、CCM コンポーネントがコンテナの機能を利用するために使用する内部インターフェースと、コンテナによって呼び出されるコンポーネント開発者が実装するコールバックインターフェースの 2 つのインターフェースから構成されています。この 2 つのインターフェースは、同一ホスト内に存在するコンテナと CCM コンポーネント間のインターフェースであるので、 IDL の中では local キーワードを付けたインターフェースとして宣言されています。また、コンテナ API タイプのセットには、 Session タイプ （ SessionContext と SessionComponent ) のインターフェースと Entity タイプ ( EntityContext と EntityComponent ) のインターフェースが存在し、これがコンポーネントの振る舞いに関係しています。なお、EJB では、内部インターフェースが EJB の EJBContext インターフェースに対応し、コールバックインターフェースが SessionBean インターフェース、及び、EntityBean インターフェースに相当します。

CORBA Usage Model は、コンテナと従来の CORBA アーキテクチャの関係を規定しています。具体的には、オブジェクトリファレンスの永続性と、オブジェクト ID とサーバントの対応関係の 2 つの組み合わせによって CORBA Usage Model の種類が決定されます ( 以下の表 )。

例えば、Stateless は TRANSIENT のオブジェクトリファレンスを利用し、サーバントとオブジェクト ID のマッピングを １ 対 多 の関係にします。また、外部 API タイプ、コンテナ API タイプと同様、これらの CORBA Usage Model の種類がコンポーネントの振る舞いに影響を与えます。

残された最後の要素であるコンポーネントのカテゴリは、上記で説明した外部 API タイプ、コンテナ API タイプ、CORBA Usage Model の組み合わせによって定義されます。つまり、以下の表で示されるような組み合わせによって、Service， Session， Process， Entity の 4 つのカテゴリにコンポーネントを分類することができます。

そして、この 4 つのカテゴリが CCM コンポーネントの基本的な振る舞いを決定しています。

コンテナモデルは、これら 4 つの CCM コンポーネントに対して各種 CORBA サービスをどのように関連させるかという CCM コンポーネントに対する細かい設定についても規定しています。こちらの詳細な情報については CCM の仕様の方を参照してください。

さて、これで CCM コンポーネントの振る舞いについて理解できたと思うので、次の章ではコンポーネントの振る舞いを定義するための CIDL について見ていきたいと思います。

4. コンポーネント実装フレームワーク

CIDL はコンポーネントの振る舞いを定義する宣言型の言語であり、コンポーネント実装フレームワークの仕様の中で重要な部分を占めています。コンポーネント実装フレームワークは、コンポーネントのプログラミングモデル（実装手順と方法）と、それに伴った様々な仕様を規定している仕様になります。つまり、従来の CORBA オブジェクトを実装する際に行われる以下の手順と類似した内容を規定しています。

1. IDL によるインターフェースの定義
2. IDL コンパイラによって特定の言語にマッピング
3. ロジック（サーバント）の実装

図 3： コンポーネント実装フレームワークによるプログラミングモデル

さて、CORBA 仕様において、CORBA オブジェクトの実装はサーバント ( Servant ) と呼んでいました。CCM コンポーネントも CORBA オブジェクトの一種であるので、その実装はサーバントとほとんど同じ役割を果たします。しかし、CORBA オブジェクトと CCM コンポーネントは完全に等価ではないので、サーバントと区別するために、CCM では CCM コンポーネントの作成手順における実装のことをエグゼクタ ( Executor ) と呼びます。従って、コンポーネント実装フレームワークでは、Home インターフェースを実装した Home エグゼクタとコンポーネントインターフェースを実装したコンポーネントエグゼクタを実装することになります。

5. CIDL によるコンポーネントの実装定義

CIDL は 拡張 IDL と PSS ( Persistent State Service ) で定義されている PSDL [4] ( Persistent State Definition Language ) のスーパーセットとして仕様化されています。CIDL は拡張 IDL と PSDL に定義されているキーワードに加えて、新しく以下のキーワードを追加しています。

CCM では CIDL によって定義するコンポーネントの実装単位のことをコンポジション ( Composition ) と呼びます。また、このコンポジションの単位を定義するために CIDL では composition というキーワードを使用しています。そして、composition キーワードの中で、コンポーネントのカテゴリを指定する service， session，process，entity の 4 つのキーワードと、インターフェースと実装の関係を記述するのに必要な manages， executor， implements のキーワードを頻繁に使用することになります。

それでは、CIDL の構文について見てみましょう。 CIDL によるコンポジション定義は必ず次のような形式に従います。

composition <category> <composition_name> {
   home executor <home_executor_name> {
     implements <home_type>
     manages    <executor_name>
   };
};  

<composition_name> にはコンポジションの名前を記述します。これはコンポジション定義本体のスコープを表す名前となります。<category> にはコンポジションがサポートする CCM コンポーネントのカテゴリを指定します。<home_executor_name> には CIDL コンパイラによって自動生成される Home エグゼクタのスケルトンのクラス名を、<executor_name> には CIDL コンパイラによって自動生成されるコンポーネントエグゼクタのスケルトンのクラス名を記述します。そして、<home_type> には、IDL ファイルからインポートされるコンポーネントの Home インターフェースを指定します。

さて、上記のようなコンポジション定義から 図 4 のような関係が導出されます。CIDL の中では、コンポーネントインターフェースそれ自体は、コンポジション定義において明示的に指定されていないことに注意してください。それは、コンポジション定義において、コンポーネントエグゼクタとコンポーネントインターフェースの関係と、 Home インターフェースの特定によって暗黙的にコンポーネントインターフェースが何であるか決定されることになります。

図 4： Home と Component と Executor の関係

では、実際の例を挙げて、拡張 IDL によるコンポーネント定義と CIDL によるコンポジション定義がどのように関係しているかを見てみましょう。まず、拡張 IDL には、hello.idl というファイル名で次のような HelloWorld コンポーネントインターフェースと HelloHome インターフェースを定義します。

// hello.idl

interface Hello{
     void sayHello();
};

component HelloWorld supports Hello {
     attribute string message;
};

home HelloHome manages HelloWorld {
     attribute string initial_message;
};

次に、hello.cdl というファイル名で CIDL によるコンポジション定義を行います。今回は Service コンポーネントとして定義するので、コンポーネントの状態に関する記述等は行っていません。

// hello.cdl
#include <hello.idl>

compositon service HelloWorldImpl {
  home executor HelloHomeImpl{
     implements HelloHome;
     manages    HelloWorldSessionImpl;
  };
};

図 4 の関係を頭に置きながら対応関係を見てみましょう。 HelloHomeImpl が HelloHome インターフェースを実装するためのスケルトンのクラスになり、HelloWorldSessionImpl がHelloWorld コンポーネントインターフェースを実装するためのスケルトンクラスになります。従って、コンポーネント開発者は、CIDL から CIDL コンパイラによって生成される HelloHomeImpl クラスと HelloWorldSessionImpl クラスを用いて、Home インターフェースのエグゼクタとコンポーネントインターフェースのエグゼクタを実装することになります。

6. 次回は・・・

本記事では、CCM コンポーネントを実装する上で重要なコンポーネント実装フレームワークとコンテナモデルについて解説しました。次回は CCM 製品を使用して、EJB との開発の違いについて触れながら、実際に CCM の簡単なアプリケーションを動かしてみたいと思います。また、次回以降でパッケージングモデル、分散配置モデルについても焦点をあてて説明したいと思っています。

さて、話は変わりますが 4月の 21 日から 26 日にかけて横浜で OMG のテクニカルミーティングが開催されました。そのミーティングの一つの内容として CCM のチュートリアルが行われたようです。私はそのミーティングに参加しませんでしたので状況を報告することができませんが、CCM のチュートリアルで使用された資料 [3] が OMG のサイトよりダウンロード出来るようになっています。プロセス間通信の問題で有名な「食事をする哲学者の問題」 [10] を取り上げて、CCM 製品を用いて実装したアプリケーションのデモが行われたようです。

7. 参考資料 ・ URL

1. 『 Final CCM FTF specification 』 OMG Document ptc/2001-11-03．
2. 『 CORBA 2.6 specification 』 OMG Document formal/01-12-01．
3. 『 CORBA Component Model Tutorial 』 OMG Document ccm/02-04-01．
4. 『 Persistent State Service 』 OMG Document ptc/01-12-02．
5. 『 Writing and Using CORBA Components 』 Frank Pilhofer 著．
   ( The MICO CORBA Component Project から入手可能です )
6. 『 CORBA Component Model: Discussion and Use with OpenCCM 』 Raphael Marvie, Philippe Merle 著, Special Issue of the Informatica．
   ( The CORBA & CORBA Component Model (CCM) Page から入手可能です )
7. 『 CORBAコンポーネントモデル技術詳細 』 和田 周, 鈴木 純一／著．
   ( OMG ジャパンウェブサイトの技術情報より入手可能です )
8. 『コンポーネントモデリングガイド』 Fondatao Inc.／著, 長瀬 嘉秀, 今野 睦／監訳, ピアソン・エデュケーション．
9. 『 Enterprise JavaBeans 開発ガイド』 Vlada Matena, Beth Stearns ／著, 船切 誠, 松田 慎一 ／訳, ピアソン・エデュケーション．
10. 『オペレーティングシステム 第 2 版 設計と理論および MINUX による実装』 A. S. Tanenbaum, A. S. Woodhull l／著, 千輝 順子 ／訳, 今泉 貴史 ／監修, ピアソン・エデュケーション pp.87-90．
11. The CORBA & CORBA Component Model (CCM) Page
12. 『CCM Implementation Survey』 OMG Document ptc/02-02-03．

8. CCM 製品の実装状況

現在 （ 2002 年 5 月 24日 ）、私が把握している 4 つの CCM 製品の中で、利用可能な CCM の機能についてまとめてみました。以下の表では、第一回目の記事と今回の記事で取り上げた CCM の機能が利用可能かどうかを項目別に表しています。この表を見る限り EJCCM の製品はすべての CCM の機能を実装しているように見えますが、本記事で紹介していない CCM で仕様化されている機能も存在しますので、現在 CCM の仕様として定義された機能がすべて利用できる製品はまだ存在しません。

なお、表の中で使用されている記号は次の意味を表します。 ○ は利用可能であり、×は利用できないことを表します。また、△に関しては不明を表します。

© 2002 OGIS-RI Co., Ltd.

Prev. Index