この連載の読者の皆さんは、アプリケーションサーバといえば、J2EE/EJBをまず思い浮かべることでしょう。しかし、J2EE/EJBだけがアプリケーションサーバではありません。CORBAやCOM+（MTS）を忘れていませんか。
「ちょっと、待ってください。MTS（Microsoft Transaction Server）は、確かにアプリケーションサーバだけど、CORBAがアプリケーションサーバというのは何かの間違いじゃないの？」
これはもっともな疑問ですが、実はCORBAもアプリケーションサーバなのです。もう少し正確にいうと、CORBAはアプリケーションサーバの機能を包含した分散ミドルウェアの基盤なのです。 J2EE/EJBとCORBAを対立的にとらえる人がいるかもしれませんが、この2つの技術を考えるうえで重要（と筆者が考える）なのは、この2つを適材適所で使い分けていくことです。
CORBAはすでに10年以上の歴史を持つ成熟した技術です。「いまさら人に聞けない」という方も多いと思います。この連載では、「いまさらCORBAなんか」という方も想定して、CORBAで何ができるのか、EJBとCORBAの長所・短所、使い分けは、どんなところで行われているのか、CORBAは今後どうなっていくのか、といった内容を解説していきます。
なお、この連載はCORBAのプログラミング講座ではありません。プログラミングの詳細については、拙著『CORBA完全解説 基礎編』および『CORBA完全解説 応用編』（いずれもソフト・リサーチ・センター）をご一読いただければ幸いです。
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のランタイムから自動的にこのコールバック・オブジェクトのメソッドが呼び出されて、クライアントに結果が通知されます（下の図を参照）。非同期呼び出しが便利なのは、サーバからの応答をトリガに次の処理を開始できる点です。しかも、ありがたいことに、同期呼び出しの場合と非同期呼び出しの場合で、サーバ・プログラムを書き換える必要はありません。
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のありがたい点は、この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製品上で提供されているため、アプリケーション・プログラマーは、トランザクション機能やセキュリティ機能を備えた高度なアプリケーションを実装することができます。
| サービス | 機能 |
|---|---|
| ネーミング・サービス | オブジェクト・リファレンスの登録と検索のためのサービスを提供。トレーダ・サービスと異なり、名前で登録／検索を行う |
| イベント・サービス | 基本的なイベント通信機能を提供 |
| パーシステント・オブジェクト・サービス（POS） | 永続オブジェクトのデータをデータベースに格納するための機能を提供。パーシステント・ステート・サービスに置き換えられ、現在は使用されていない |
| ライフサイクル・サービス | オブジェクトのライフサイクルを管理するためのサービスを提供 |
| リレーションシップ・サービス | オブジェクト間の関係を管理するためのサービスを提供 |
| エクターナリザーション・サービス | オブジェクトの状態をストリームに書き出す（エクターナライズ）ためのサービスと、ストリームからオブジェクトの状態を読み込む（インターナライズ）ためのサービスを提供 |
| オブジェクト・トランザクション・サービス（OTS） | 分散トランザクション機能を提供 |
| コンカレンシー・コントロール・サービス | オブジェクトの排他制御をサポート |
| セキュリティ・サービス | 分散セキュリティ機能を提供 |
| タイム・サービス | 時刻同期、時刻問い合わせの機能を提供 |
| ライセンシング・サービス | ソフトウェアのライセンス管理の機能を提供 |
| クエリー・サービス | オブジェクトの検索機能を提供 |
| プロパティ・サービス | 実行時にオブジェクトに対してプロパティ値を設定するためのサービスを提供 |
| コレクション・サービス | オブジェクトを集合として操作するためのサービスを提供 |
| トレーダ・サービス | オブジェクトをサービス内容で登録あるいは検索するサービスを提供 |
| ノーティフィケーション・サービス | イベント・サービスの上位互換サービス。基本的なイベント通信に加えて、フィルタリングなどの機能を提供 |
| パーシステント・ステート・サービス（PSS） | オブジェクトの状態を永続的に保存するためのサービス |
| CORBAサービスの一覧 | |
次回のテーマはEJBとCORBA
さて、ここまでお読みいただいて、CORBAの基本的な機能と特徴は理解していただけたと思います。さて、次回以降のストーリーは、いよいよ「いまなぜCORBAなの？」の真髄に触れていきます。
はじめはCORBAとEJBについてです。CORBAとEJBは、多くの共通した機能を提供しています。機能的には似ているのですが、決定的に違うのは、EJBアプリケーションはEJBコンテナの中で実行されるという点なのです。このため、EJBアプリケーションは、リモート・メソッドの実装だけからなり、自分自身のmainメソッドを持ちません。これに対して、CORBAアプリケーションは、自分自身でmainメソッドを持ち、スタンド・アロンで実行されます。
この違いは非常に重要で、ここにCORBAとEJBのそれぞれの長所と短所が潜んでいるのです。次回は、EJBとCORBAに焦点をあてながら、CORBAとEJBの使い分け、CORBAはどんなシステムに向いているのかついて解説します。
筆者プロフィール
小野沢 博文（おのざわ ひろふみ）
日本アイオナテクノロジーズ株式会社
主席 コンサルタント
現在、日本アイオナテクノロジーズ株式会社にて分散オブジェクト・システムの技術コンサルタントを務める。
1991年まで富士通株式会社にてプラズマ実験データ処理システムの開発やシステム運用に携わった後1996年以前は日本DECにてCORBA準拠のObjectBrokerおよびDCEの開発を担当。また、MIA、NMF SPIRITなどの標準化活動にも参加する。 1997年1月から1999年8月までは、TCSIにて分散オブジェクト技術を適用したテレコム向けの大規模ネットワーク管理システムの開発に携わる。
[著書一覧] 『CORBA完全解説 基礎編』（ソフト・リサーチ・センター）、『CORBA完全解説 応用編』（ソフト・リサーチ・センター）、『分散オブジェクト指向技術CORBA』（ソフト・リサーチ・センター）、『イントラネットのためのオブジェクト指向データベース技術』（共著、ソフト・リサーチ・センター）、『分散コンピューティング環境 DCE』 （監著、共立出版）、『トランザクション処理システム入門』（共訳、日経BP）
Copyright © ITmedia, Inc. All Rights Reserved.