まずはCORBAの基礎を復習しよう：いまなぜCORBAなの?（1）

CORBAは分散オブジェクト呼び出しの基盤

　CORBAの役割を一言で表現すると、「クライアントが、ネットワーク上に存在するオブジェクト（分散オブジェクト）を呼び出すための基盤を提供する」ことです。CORBAは、あくまでも基盤を提供するだけですから、この基盤の上にアプリケーションを構築しなければ何の役にも立ちません。

　CORBAを使って分散オブジェクトを呼び出す方法は、非常に簡単です。Javaで自分のプロセス内のオブジェクトを呼び出すのと、さして変わりません。ただし、そのオブジェクトに対する参照、つまりオブジェクト・リファレンスをあらかじめ何らかの方法で取得しておく必要があります。この連載は、CORBAのプログラミング講座ではありませんが、抽象的な説明だけでは、分かりにくいでしょうから、ここでは簡単なサンプル・プログラムで説明していきます。次のコードは、CORBAを使ったオブジェクト呼び出しを行うクライアント・プログラムの一部です。

Account account = accountHome.findAccount(accountNumber);
int balance = account.balance();

　上のコードでは、最初にAccountHomeオブジェクトのfindAccountメソッドを呼び出して、自分がアクセスしたいAccountオブジェクトのオブジェクト・リファレンスを取得します。AccountHomeオブジェクトは、Accountオブジェクトの作成や検索をサポートするファクトリ・オブジェクトだと思ってください。このオブジェクトのオブジェクト・リファレンスは、あらかじめネーミング・サービスなどで取得しておきます。findAccountメソッドは戻り値としてAccountオブジェクトのオブジェクト・リファレンスを返却します。もちろん、サーバ側でそのようにAccountHomeオブジェクトを実装しておくことが必要です。

　2行目では、得られたAccountオブジェクトのオブジェクト・リファレンスを使って、Accountオブジェクトのbalanceメソッドを呼び出しています。CORBAでは、通常のJavaのメソッド呼び出しとほとんど同じように、分散オブジェクトを呼び出すことができるのです。

　このようにCORBAを使うことで、簡単に分散アプリケーションを作成することができます。しかも、特定のプログラム言語に縛られないため、あらゆる言語のプログラムをCORBAで接続することが可能です（もちろん、その言語をサポートするCORBA製品が必要です）。

オブジェクト呼び出しのさまざまなスタイル

　CORBAで実現されるリモート・メソッド呼び出しには、2つのスタイルがあります。1つは、同期呼び出しです。これは、Javaの通常のメソッド呼び出しと同じで、メソッド側の処理が終了するまで、呼び出し元が待たされるタイプです。リモート・メソッドを1つ1つ順番に呼び出して、処理を行っていくクライアントに向いています。圧倒的に多くのクライアント・アプリケーションでは、この同期呼び出しが使用されています。

　これに対して、サーバからの応答をじっと待つのではなく、多くのメソッドを一度に呼び出して、その応答を非同期に受け取りたいというニーズもあります。CORBAでは、このために非同期呼び出しと呼ばれるスタイルもサポートしています。この場合、クライアントは、応答を受け取るためのコールバック・オブジェクトをあらかじめ作成しておきます。そして、サーバからの応答が到着すると、CORBAのランタイムから自動的にこのコールバック・オブジェクトのメソッドが呼び出されて、クライアントに結果が通知されます（下の図を参照）。非同期呼び出しが便利なのは、サーバからの応答をトリガに次の処理を開始できる点です。しかも、ありがたいことに、同期呼び出しの場合と非同期呼び出しの場合で、サーバ・プログラムを書き換える必要はありません。

CORBAの非同期呼び出し

MOMの機能も包含

　非同期呼び出しをもう少し発展させた起動方法に、Time Independent Invocation（TII）と呼ばれるスタイルがあります。TIIでは、CORBAのランタイムがメッセージをキューイングすることにより、ネットワーク・パスや通信相手が一時的にダウンしていても、要求や応答を受け取り可能にしてくれます。しかも、メッセージをトランザクショナルに保存し、転送することができるため、高い信頼性が実現されます。また、さまざまなレベルでタイム・アウト値や優先順位を設定することも可能です。これらの機能により、CORBAは、従来のメッセージ指向ミドルウェア（MOM）の機能を包含することになります。

CORBAの特長「ポータビリティ」

　CORBAの特長の1つは、アプリケーションのポータビリティです。あるCORBA製品上に構築したアプリケーションを、修正することなく別のCORBA製品上に移植することができます。これは、Javaプログラマーからすれば当たり前に聞こえますが、意外にもこのポータビリティは、最初から実現されていたわけではありません。CORBAのバージョン2.1までは、基本オブジェクト・アダプタ（BOA）と呼ばれるサーバ側の仕様が採用されていましたが、この仕様は、あいまいな点が多く、しかも重要な点の多くを製品の実装者に任せていたため、CORBA製品によってAPIに差ができてしまいました。

　これを解決したのが、1998年に採択されたCORBA 2.2のポータブル・オブジェクト・アダプタ（POA）仕様です。ベンダ固有のAPIを使わないで、この仕様に忠実にコーディングすることで、100％ポータブルなアプリケーションを開発することが可能です。

CORBAの特長「インターオペラビリティ」

　CORBAの特長のもう1つが、インターオペラビリティです。GIOP（General Inter-ORB Protocol）とIIOP（Internet Inter-ORB Protocol）と呼ばれる共通プロトコルを使用することで、異なるCORBA製品上のアプリケーションを相互に接続することができます。このCORBAとして当然の機能も、ポータビリティと同様最初から実現されていたわけではありません。CORBA 1.2までは、通信プロトコルの仕様は各CORBA製品に任されていました。1996年のCORBA 2.0でようやくGIOPとIIOPの仕様が規定され、異なるCORBA製品間のインターオペラビリティが実現しました。

　ところで、GIOPは、特定のトランスポート・プロトコルに依存しない上位レベルの共通プロトコルです。この中には、各メッセージの役割とフォーマット、エンコーディング規則、コネクション管理などの規則が規定されています。GIOPは、さまざまなコネクション指向のトランスポートにマッピングすることが原理的に可能です。このGIOPをTCP/IPにマッピングしたのが、IIOPなのです。

CORBAのプロトコル・スタック

　CORBAのありがたい点は、このIIOPを通じてCORBA以外の代表的な分散システムと接続できる点です。OMG（Object Management Group: CORBAをはじめとするオブジェクト指向技術の標準化を推進しているコンソーシアム）では、「COM-CORBAインタワーキング」および「Java-IDLマッピング」の仕様を規定しています。これらの仕様に準拠した製品を使うことで、COM、CORBA、Java RMI（EJB）にまたがって、簡単にシステムを連携させることができます。

CORBAのSOAPマッピングの標準化が進む

　CORBAはアプリケーションから見ると、特定のネットワーク・プロトコルに一切依存していません。従って、CORBAをGIOP／IIOP以外のプロトコルにマッピングすることも原理的に可能です。実際、OMGはCORBAのSOAP（Simple Object Access Protocol）マッピングの標準化作業を行っています。SOAPは、XMLドキュメントをHTTPなどのトランスポート上で送受信するためのプロトコルで、オブジェクト呼び出しの要求と応答メッセージをXMLで記述することで、分散オブジェクト呼び出しのプロトコルとして使用することができます。トランスポートとしてHTTPやHTTPSを使用できることから、既存のファイアウォールを変更することなく、それらを越えてオブジェクト呼び出しを実現することが可能になります。

プロトコル・プラグインでプロトコルに非依存を実現

　ネットワーク・プロトコルに依存しないというCORBAの特長を最大限に生かそうとすると、トランスポート・プラグインという発想が生まれてきます。これは、アプリケーションの再コンパイルを伴わずに、プラグインを交換するだけで、プロトコルを使い分けようという発想です。例えば、IONAのOrbix 2000では、使用するプラグインをコンフィグレーションで指定するだけで、実行時にプロトコルを選択することが可能です。実際、Orbix 2000のカーネル部分には、特定のネットワーク・プロトコルに依存するコードは一切含まれておらず、さまざまなプロトコルがプラグインとして実行時に選択される仕組みになっています。これによって、アプリケーションの再コンパイルを伴わずに、IIOP、IIOP/SSL、共用メモリ・トランスポート、SOAP、さらにはユーザー作成のプロトコル・プラグインを使用することが可能になります。

Orbix 2000のプラグイン・アーキテクチャ
POA（portable Object Adapter）：ポータブル・オブジェクト・アダプタ
PSS（Persistent State Service）：永続状態サービス
OTS（Object Transaction Service）：オブジェクト・トランザクション・サービス

CORBAサービスの概要

　CORBAは、基本的なオブジェクト呼び出し機能を提供するだけではなく、次の表のような、分散アプリケーションを構築するうえで便利な共通サービスを提供しています。これらのサービスの中には、製品としてまったく実装されていなかったり、現在ではほとんど使用されていないものも含まれています。現在、比較的よく使われているサービスは、ネーミング・サービス、イベント・サービス、トランザクション・サービス、コンカレンシー・コントロール・サービス、セキュリティ・サービス、トレーダ・サービス、ノーティフィケーション・サービス、パーシステント・ステート・サービスの8つのサービスでしょうか。

　これらの基本サービスは、多くのCORBA製品上で提供されているため、アプリケーション・プログラマーは、トランザクション機能やセキュリティ機能を備えた高度なアプリケーションを実装することができます。

次回のテーマはEJBとCORBA

　さて、ここまでお読みいただいて、CORBAの基本的な機能と特徴は理解していただけたと思います。さて、次回以降のストーリーは、いよいよ「いまなぜCORBAなの？」の真髄に触れていきます。

　はじめはCORBAとEJBについてです。CORBAとEJBは、多くの共通した機能を提供しています。機能的には似ているのですが、決定的に違うのは、EJBアプリケーションはEJBコンテナの中で実行されるという点なのです。このため、EJBアプリケーションは、リモート・メソッドの実装だけからなり、自分自身のmainメソッドを持ちません。これに対して、CORBAアプリケーションは、自分自身でmainメソッドを持ち、スタンド・アロンで実行されます。

　この違いは非常に重要で、ここにCORBAとEJBのそれぞれの長所と短所が潜んでいるのです。次回は、EJBとCORBAに焦点をあてながら、CORBAとEJBの使い分け、CORBAはどんなシステムに向いているのかついて解説します。