
いまなぜCORBAなの?
第1回 まずはCORBAの基礎を復習しよう
日本アイオナテクノロジーズ
主席 コンサルタント
小野沢 博文
2001/3/8
| この連載の読者の皆さんは、アプリケーションサーバといえば、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); |
上のコードでは、最初に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製品上で提供されているため、アプリケーション・プログラマーは、トランザクション機能やセキュリティ機能を備えた高度なアプリケーションを実装することができます。
|
||||||||||||||||||||||||||||||||||||
| CORBAサービスの一覧 |
| 次回のテーマはEJBとCORBA |
さて、ここまでお読みいただいて、CORBAの基本的な機能と特徴は理解していただけたと思います。さて、次回以降のストーリーは、いよいよ「いまなぜCORBAなの?」の真髄に触れていきます。
はじめはCORBAとEJBについてです。CORBAとEJBは、多くの共通した機能を提供しています。機能的には似ているのですが、決定的に違うのは、EJBアプリケーションはEJBコンテナの中で実行されるという点なのです。このため、EJBアプリケーションは、リモート・メソッドの実装だけからなり、自分自身のmainメソッドを持ちません。これに対して、CORBAアプリケーションは、自分自身でmainメソッドを持ち、スタンド・アロンで実行されます。
この違いは非常に重要で、ここにCORBAとEJBのそれぞれの長所と短所が潜んでいるのです。次回は、EJBとCORBAに焦点をあてながら、CORBAとEJBの使い分け、CORBAはどんなシステムに向いているのかついて解説します。
| 連載内容 | |
| いまなぜCORBAなの? | |
| 第1回 まずはCORBAを復習しよう | |
| 第2回 EJBとはどこが違うの? | |
| 第3回 事例とアーキテクチャに学ぶ | |
| 第4回 WebサービスをひらくCORBA | |
| 連載記事一覧 |
ホワイトペーパー(TechTargetジャパン)
- Android NDKでJNIを使用してアプリを高速化するには (2010/3/17)
C/C++やOpenGL ESといったネイティブコードを使うためのNDKとJNIを紹介し、その使い方や注意点を徹底解説します - 調査の難しい「OutOfMemoryError」事例、5選 (2010/3/11)
Java開発者が避けて通れないメモリ不足エラーの基本的な問題切り分け方法と発生につながる事例、対処法を解説 - 究極の問題解析ツール、逆コンパイラJD-Eclipseとは (2010/3/8)
ライブラリ内で例外が発生! そのクラスのソースコードを調べたい!! 自動で逆コンパイルしてくれる無料Eclipseプラグインがあります - いまさら聞けない「Webサービス」の常識 (2010/2/26)
昨今では企業システムでも使われる「Webサービス」の概念やJava標準のJAX-WSを紹介しJBoss WSでサンプルを作成
|
|
スキルアップ/キャリアアップ(JOB@IT)
スポンサーからのお知らせ
- - PR -
| 「いつかは壊れるサーバ」そんな故障に 迅速で安価に手軽に対応する方法とは? New! |
| 「特権ユーザー」の事件を防げ! 万能権限を持つユーザーの管理方法とは? New! |
| 仮想環境の構築とデータ保護の特効薬?! 実績と信頼性の高いパッケージで安心運用 |
| 仮想環境のバックアップもこれまでどおり 「まるごと取ってまるごと戻す」簡単運用 |
| おばかアプリ選手権、第4弾開催中!! ムダにカッコよくてくだらない作品求ム! |
| 社内ファイルサーバを“クラウド”に統合 VPN直結「クラウド型ストレージ」を紹介 |
| その数、なんと400台以上! グループ内 サーバの「統合管理」によるメリットは? |
| 美人!? まあまあ? 気になる いやし系!! PV急増で「美人時計」がとった手段とは? |
| 進化を続ける富士通ストレージETERNUS DX 製品開発者の自信を裏付けるものとは何か |
| 運用管理の課題を“2つの観点”から分析 ユーザー満足度の高い「仮想環境」とは? |
- - PR -
お勧め求人情報

**先週の人気講座ランキング**
〜CCNA編〜
| ◆ | TomcatやJBossなどAPサーバ環境に関する 情報を集約! “業務”用APサーバ大百科 New! |
| ◆ | 一気に解説! 最新のクラスタストレージ 「RAIDを超えたストレージ基準」……など New! |
| ◆ | クラウド的ユーザー体験の変化は脅威か? 仮想化技術を使いこなす運用管理術を紹介 New! |

| ◆ | 上司や部下、部署内メンバーとの情報共有 を“ガラッ”と変えるコラボツールとは? New! |
| ◆ | おばかアプリ選手権、第4弾開催中!! ムダにカッコよくてくだらない作品求ム! |
| ◆ | 社内ファイルサーバを“クラウド”に統合 VPN直結「クラウド型ストレージ」を紹介 |

| ◆ | Twitterのアカウントはなぜ突破された? メールによる新手の攻撃手法とその対策 |
| ◆ | もう仮想化のお試しフェイズは終わりだ! Hyper-V 2.0が基幹システムも仮想化 |
| ◆ | 美人!? まあまあ? 気になる いやし系!! PV急増で「美人時計」がとった手段とは? |

| ◆ | クライアント企業から求められる人材 ⇒IT技術と経営戦略を併せ持つ「戦略家」 |
| ◆ | .NET編集長が実践する「技術情報検索術」 サンプル・コードを簡単に探す“技”は? |
| ◆ | 業務効率と情報セキュリティ対策を両立! 手間なく確実に機密情報を守る方法とは? |

| ◆ | 進化を続ける富士通ストレージETERNUS DX 製品開発者の自信を裏付けるものとは何か |
| ◆ | 運用管理の課題を“2つの観点”から分析 ユーザー満足度の高い「仮想環境」とは? |

| ◆ | 【CTC事例】約30の基幹システムを統合! 膨大なバッジジョブを制御した方法は? |
| ◆ | 仮想化すればコストは削減できるか? 仮想化に必要な「3つの視点」を解説する |
| ◆ | その数、なんと400台以上! グループ内 サーバの「統合管理」によるメリットは? |









