| CORBAは分散オブジェクト呼び出しの基盤(pán) |
CORBAの役割を一言で表現すると、「クライアントが、ネットワーク上に存在するオブジェクト(分散オブジェクト)を呼び出すための基盤(pán)を提供する」ことです。CORBAは、あくまでも基盤(pán)を提供するだけですから、この基盤(pán)の上にアプリケーションを構築しなければ何の役にも立ちません。
CORBAを使って分散オブジェクトを呼び出す方法は、非常に簡(jiǎn)単です。Javaで自分のプロセス內のオブジェクトを呼び出すのと、さして変わりません。ただし、そのオブジェクトに対する參照、つまりオブジェクト?リファレンスをあらかじめ何らかの方法で取得しておく必要があります。この連載は、CORBAのプログラミング講座ではありませんが、抽象的な説明だけでは、分かりにくいでしょうから、ここでは簡(jiǎn)単なサンプル?プログラムで説明していきます。次のコードは、CORBAを使ったオブジェクト呼び出しを行うクライアント?プログラムの一部です。
Account account = accountHome.findAccount(accountNumber); |
上のコードでは、最初にAccountHomeオブジェクトのfindAccountメソッドを呼び出して、自分がアクセスしたいAccountオブジェクトのオブジェクト?リファレンスを取得します。AccountHomeオブジェクトは、Accountオブジェクトの作成や検索をサポートするファクトリ?オブジェクトだと思ってください。このオブジェクトのオブジェクト?リファレンスは、あらかじめネーミング?サービスなどで取得しておきます。findAccountメソッドは戻り値としてAccountオブジェクトのオブジェクト?リファレンスを返卻します。もちろん、サーバ側でそのようにAccountHomeオブジェクトを実裝しておくことが必要です。
2行目では、得られたAccountオブジェクトのオブジェクト?リファレンスを使って、Accountオブジェクトのbalanceメソッドを呼び出しています。CORBAでは、通常のJavaのメソッド呼び出しとほとんど同じように、分散オブジェクトを呼び出すことができるのです。
このようにCORBAを使うことで、簡(jiǎn)単に分散アプリケーションを作成することができます。しかも、特定のプログラム言語(yǔ)に縛られないため、あらゆる言語(yǔ)のプログラムをCORBAで接続することが可能です(もちろん、その言語(yǔ)をサポートするCORBA製品が必要です)。
![]() | オブジェクト呼び出しのさまざまなスタイル |
CORBAで実現されるリモート?メソッド呼び出しには、2つのスタイルがあります。1つは、同期呼び出しです。これは、Javaの通常のメソッド呼び出しと同じで、メソッド側の処理が終了するまで、呼び出し元が待たされるタイプです。リモート?メソッドを1つ1つ順?lè )撕簸映訾筏?、処理を行っていくクライアントに向いています。圧倒的に多くのクライアント?アプリケーションでは、この同期呼び出しが使用されています。
これに対して、サーバからの応答をじっと待つのではなく、多くのメソッドを一度に呼び出して、その応答を非同期に受け取りたいというニーズもあります。CORBAでは、このために非同期呼び出しと呼ばれるスタイルもサポートしています。この場(chǎng)合、クライアントは、応答を受け取るためのコールバック?オブジェクトをあらかじめ作成しておきます。そして、サーバからの応答が到著(zhù)すると、CORBAのランタイムから自動(dòng)的にこのコールバック?オブジェクトのメソッドが呼び出されて、クライアントに結果が通知されます(下の図を參照)。非同期呼び出しが便利なのは、サーバからの応答をトリガに次の処理を開(kāi)始できる點(diǎn)です。しかも、ありがたいことに、同期呼び出しの場(chǎng)合と非同期呼び出しの場(chǎng)合で、サーバ?プログラムを書(shū)き換える必要はありません。
![]() |
| CORBAの非同期呼び出し |
![]() | MOMの機能も包含 |
非同期呼び出しをもう少し発展させた起動(dòng)方法に、Time Independent Invocation(TII)と呼ばれるスタイルがあります。TIIでは、CORBAのランタイムがメッセージをキューイングすることにより、ネットワーク?パスや通信相手が一時(shí)的にダウンしていても、要求や応答を受け取り可能にしてくれます。しかも、メッセージをトランザクショナルに保存し、転送することができるため、高い信頼性が実現されます。また、さまざまなレベルでタイム?アウト値や優(yōu)先順位を設定することも可能です。これらの機能により、CORBAは、従來(lái)のメッセージ指向ミドルウェア(MOM)の機能を包含することになります。
![]() | CORBAの特長(cháng)「ポータビリテ?!?/b> |
CORBAの特長(cháng)の1つは、アプリケーションのポータビリティです。あるCORBA製品上に構築したアプリケーションを、修正することなく別のCORBA製品上に移植することができます。これは、Javaプログラマーからすれば當たり前に聞こえますが、意外にもこのポータビリティは、最初から実現されていたわけではありません。CORBAのバージョン2.1までは、基本オブジェクト?アダプタ(BOA)と呼ばれるサーバ側の仕様が採用されていましたが、この仕様は、あいまいな點(diǎn)が多く、しかも重要な點(diǎn)の多くを製品の実裝者に任せていたため、CORBA製品によってAPIに差ができてしまいました。
これを解決したのが、1998年に採択されたCORBA 2.2のポータブル?オブジェクト?アダプタ(POA)仕様です。ベンダ固有のAPIを使わないで、この仕様に忠実にコーディングすることで、100%ポータブルなアプリケーションを開(kāi)発することが可能です。
![]() | CORBAの特長(cháng)「インターオペラビリテ?!?/b> |
CORBAの特長(cháng)のもう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のありがたい點(diǎn)は、このIIOPを通じてCORBA以外の代表的な分散システムと接続できる點(diǎn)です。OMG(Object Management Group: CORBAをはじめとするオブジェクト指向技術(shù)の標準化を推進(jìn)しているコンソーシアム)では、「COM-CORBAインタワーキング」および「Java-IDLマッピング」の仕様を規定しています。これらの仕様に準拠した製品を使うことで、COM、CORBA、Java RMI(EJB)にまたがって、簡(jiǎn)単にシステムを連攜させることができます。
![]() | CORBAのSOAPマッピングの標準化が進(jìn)む |
CORBAはアプリケーションから見(jiàn)ると、特定のネットワーク?プロトコルに一切依存していません。従って、CORBAをGIOP/IIOP以外のプロトコルにマッピングすることも原理的に可能です。実際、OMGはCORBAのSOAP(Simple Object Access Protocol)マッピングの標準化作業(yè)を行っています。SOAPは、XMLドキュメントをHTTPなどのトランスポート上で送受信するためのプロトコルで、オブジェクト呼び出しの要求と応答メッセージをXMLで記述することで、分散オブジェクト呼び出しのプロトコルとして使用することができます。トランスポートとしてHTTPやHTTPSを使用できることから、既存のファイアウォールを変更することなく、それらを越えてオブジェクト呼び出しを実現することが可能になります。
![]() | プロトコル?プラグインでプロトコルに非依存を実現 |
ネットワーク?プロトコルに依存しないというCORBAの特長(chá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は、基本的なオブジェクト呼び出し機能を提供するだけではなく、次の表のような、分散アプリケーションを構築するうえで便利な共通サービスを提供しています。これらのサービスの中には、製品としてまったく実裝されていなかったり、現在ではほとんど使用されていないものも含まれています?,F在、比較的よく使われているサービスは、ネーミング?サービス、イベント?サービス、トランザクション?サービス、コンカレンシー?コントロール?サービス、セキュリティ?サービス、トレーダ?サービス、ノーティフィケーション?サービス、パーシステント?ステート?サービスの8つのサービスでしょうか。
これらの基本サービスは、多くのCORBA製品上で提供されているため、アプリケーション?プログラマーは、トランザクション機能やセキュリティ機能を備えた高度なアプリケーションを実裝することができます。
| ||||||||||||||||||||||||||||||||||||
| CORBAサービスの一覧 |
![]() | 次回のテーマはEJBとCORBA |
さて、ここまでお読みいただいて、CORBAの基本的な機能と特徴は理解していただけたと思います。さて、次回以降のストーリーは、いよいよ「いまなぜCORBAなの?」の真髄に觸れていきます。
はじめはCORBAとEJBについてです。CORBAとEJBは、多くの共通した機能を提供しています。機能的には似ているのですが、決定的に違うのは、EJBアプリケーションはEJBコンテナの中で実行されるという點(diǎn)なのです。このため、EJBアプリケーションは、リモート?メソッドの実裝だけからなり、自分自身のmainメソッドを持ちません。これに対して、CORBAアプリケーションは、自分自身でmainメソッドを持ち、スタンド?アロンで実行されます。
この違いは非常に重要で、ここにCORBAとEJBのそれぞれの長(cháng)所と短所が潛んでいるのです。次回は、EJBとCORBAに焦點(diǎn)をあてながら、CORBAとEJBの使い分け、CORBAはどんなシステムに向いているのかついて解説します。
聯(lián)系客服