事例とアーキテクチャに学ぶ：いまなぜCORBAなの?（3）（2/2 ページ）

CORBAのスケーラビリティと柔軟性の源泉

　連載１回目に、サーバ側の仕様であるポータブル・オブジェクト・アダプタ（POA）によって100％ポータブルなアプリケーション開発が可能になった、という話をしましたが、POAがもたらしたのは、ポータビリティだけではありません。POAではサーバ・アプリケーションを開発する際に、アプリケーション開発者に幅広い選択肢を与えてくれます。具体的には、開発者は最適なPOAポリシーを設定してサーバを開発することができます。このPOAポリシーの選択次第で、効率の悪いアプリケーションにも、スケーラブルなアプリケーションにもなるわけです。

■CORBAオブジェクトとサーバント

　POAのポリシーを理解するためには、その前に「CORBAオブジェクト」と「サーバント」という2つの用語を理解しておくことが必要です。CORBAオブジェクトというのは、クライアントからのメソッド呼び出しの対象になるリモート・オブジェクトです。アイデンティティを持ち、分散環境でほかのCORBAオブジェクトと明確に区別することができます。例えば、特定の口座番号を持った口座オブジェクト、装置IDを持った装置オブジェクトなどです。これに対して、サーバントというのは、CORBAオブジェクトを実装するプログラミング言語のオブジェクトです。例えば、C++やJavaで実装されたサーバ・プロセス内のローカル・オブジェクトがサーバントです。CORBAではこの両者を明確に区別しており、それぞれに対して独自のライフ・サイクルを持たせています（図3）。

図3　CORBAオブジェクトのライフサイクル

　例えば、複数のCORBAオブジェクトを１つのサーバントで同時に活性化したり、あるいは、あるCORBAオブジェクトを、ある時点ではあるサーバントに活性化させ、別の時点では別のサーバントに活性化させることも可能です。場合によっては、サーバントの作成を伴わずにCORBAオブジェクトだけ作成することも可能です。この意味で、CORBAオブジェクトは、抽象的な「魂」のような存在であり、それを実体化する「肉体」がサーバントということになります。実際にPOAの仕様書では、サーバントがCORBAオブジェクトを実体化することを「具現化する（incarnate）」と呼び、逆に、サーバントからCORBAオブジェクトを切り離すことを「霊化する（etherealize）」と呼んでいます。

■POAのサーバ・モデル

　少し話が難しくなりましたが、ここで重要なのは、CORBAオブジェクトとサーバントの関係をアプリケーションがいかようにでも制御できるということです。これによって、次のようなさまざまなニーズに応じたサーバを作成することができます。

すべてのCORBAオブジェクトに対するサーバントをメモリ上に常駐させる小規模サーバ

　このモデルでは、すべてのサーバントをサーバのメモリ上に常駐させることで、クライアントからの要求を高速に処理することができます。このモデルは、メモリに保持できるだけの少数のオブジェクトをサポートする小規模システムに向いています。

図4　すべてのCORBAオブジェクトに対するサーバントをメモリに常駐する小規模サーバ

クライアントからのメソッド呼び出し時にオブジェクトを活性化するサーバ

　1つ目のモデルの欠点は、サーバ・プロセスの生存期間中に必ずしも使われないオブジェクトまでメモリ上に保持しなければならない点と、サーバの初期化時間が比較的大きくなる点です。2つ目のモデルではこれを避けるために、あるオブジェクトに対する最初の呼び出し時にサーバントを作成して、オブジェクトを活性化し、その後はメモリ上に保持するようにします。

図5　クライアントからのメソッド呼び出し時にオブジェクトを活性化するサーバ

サーバントをプール化し、オブジェクトの状態をLRUで管理するサーバ

　このモデルでは、一定サイズのサーバント・プールをあらかじめ作成しておきます。そして、呼び出しのあったオブジェクトの状態を、プールから取り出したサーバントにロードします。いったん、オブジェクトの状態がロードされると、そのオブジェクトに対するその後のメソッド呼び出しはメモリ上で高速に処理することができます。2つ目のモデルとの違いは、サーバント・プールに未使用のサーバントがなくなった場合、最も過去にアクセスされたオブジェクトに対するサーバントを、別のオブジェクトのために再利用する点です。このモデルは、同じオブジェクトに繰り返しアクセスが発生する大規模システムに向いています。

図6　サーバントをプール化し、オブジェクトの状態をLRUで管理する大規模サーバ

単一サーバントですべてのオブジェクトを処理するスケーラブルなサーバ

　このモデルでは、単一のサーバントがすべてのオブジェクトに対する呼び出し要求をマルチスレッドでこなします。サーバントには、特定のオブジェクトの状態を保持しません。つまり、このモデルのサーバはステートレスとなります。このため、わずかなメモリ使用量で膨大な数のオブジェクトをサポートできるため、最もスケーラビリティに富んだサーバ・モデルです。このモデルのもう1つの特長は、DBMSやTPモニタといった既存の非オブジェクト指向のシステムをCORBAオブジェクトとして容易にラッピングできる点です。

図7　単一サーバントですべてのオブジェクトを処理するスケーラブルなサーバ

CORBAの柔軟性は両刃の剣

　これらのサーバ・モデルの幾つかは、EJBでもBeanのタイプ（Stateless Session Bean、Stateful Session Bean、Entity Bean）を選択することにより実現することができます。しかし、EJBではあらかじめモデルが決められているため、これらにうまくマッチしない場合には、アウトです。これに対して、CORBAでは、オブジェクトとサーバントのライフ・サイクルとその関係を完全にアプリケーションから制御できるという点が、スケーラブルで柔軟性の高いアプリケーションサーバを実現する場合の優位点になります。もちろん、これは両刃の剣であり、長所にも短所にもなり得るのです。

次回のテーマは、CORBAのこれから

　さて、次回はいよいよ最終回です。これまでは、すでに製品化されているCORBAの機能について説明してきましたが、次回はCORBAが今後どのように展開していくかについて解説します。特に、XMLやWebサービスをCORBAと統合し、トータルなビジネス・インテグレーションをいかに実現していくかに重点を置きたいと思います。