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

　CORBAを使って分散オブジェクトを呼び出す方法は、非常に簡(jiǎn)単です。Javaで自分のプロセス內(nèi)のオブジェクトを呼び出すのと、さして変わりません。ただし、そのオブジェクトに対する?yún)⒄铡ⅳ膜蓼辚芝弗Д?リファレンスをあらかじめ何らかの方法で取得しておく必要があります。この連載は、CORBAのプログラミング講座ではありませんが、抽象的な説明だけでは、分かりにくいでしょうから、ここでは簡(jiǎn)単なサンプル?プログラムで説明していきます。次のコードは、CORBAを使ったオブジェクト呼び出しを行うクライアント?プログラムの一部です。

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

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

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

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

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

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

CORBAの非同期呼び出し

MOMの機(jī)能も包含

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

CORBAの特長(zhǎng)「ポータビリテ?！?/b>

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

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

CORBAの特長(zhǎng)「インターオペラビリテ?！?/b>

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

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

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

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

CORBAのSOAPマッピングの標(biāo)準(zhǔn)化が進(jìn)む

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

プロトコル?プラグインでプロトコルに非依存を?qū)g現(xiàn)

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

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

CORBAサービスの概要

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

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

次回のテーマはEJBとCORBA

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

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

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