6.2. CORBA, ORBit, Baboon

 GNOME はミドルネームからしてネットワークオブジェクトだ。これがその仕組み。

6.2.1. CORBA ってなに?

 CORBA っていうのは、共有オブジェクト要求ブローカーアーキテクチャ(Common Object Request Broker Architecture)だ。 Open Management Group (OMG、CORBA を仕切ってる標準化団体)が出している What is CORBA? という文書にはこう説明してある:

共有オブジェクト要求ブローカーアーキテクチャ (CORBA) は、今日出回っている、急速に増殖するハードとソフト製品に相互運用性を持たせるニーズに対し、OMG なりの答えを出したものです。一言で、 CORBA はアプリケーション同士が、それぞれどこにあろうとも、だれが設計したものであろうとも、相互にやりとりできるようにするものです(中略)。

 オブジェクト同士のクライアント・サーバ関係を確立するミドルウェアが (ORB) です。ORB を使うと、クライアントはサーバオブジェクトのメソッドを透過的に呼び出せます。しかもそのサーバオブジェクトは、同じマシン上でもネットワークを介していてもかまいません。ORB はコールをインターセプトして、その要求を実装できるオブジェクトを責任喪って探し、パラメータを渡して、メソッドを呼び出し、結果を返します。クライアントは、そのオブジェクトがどこにあるか、どんな言語でプログラムされたか、その OS はなにか、といった、オブジェクトのインターフェース以外のシステム面については一切知る必要がありません。こうすることで、 ORB は多様なマシンの混在する分散環境で、異なるマシン上にあるアプリケーション間の相互運用を提供し、複数のオブジェクトシステムをシームレスに相互接続します。

 一般のクライアント・サーバアプリケーションを配備するとき、開発者たちは装置間のプロトコルを決めるのに、独自の設計を使ったり、よく知られた規格を使ったりします。プロトコルの定義は、実装の言語やネットワーク・トランスポートなど、さまざまな要因に左右されます。 ORB はこのプロセスをすっきりさせます。 ORB では、プロトコルはアプリケーションのインターフェースを通じ、実装言語とは独立した単一の仕様として定義されています。これが IDL (編註: Interface Description Language、インターフェース記述言語)です。そして ORB は柔軟性をも提供します。プログラマたちは、作りかけのシステムのそれぞれのコンポーネントについて、いちばん適切な OS や実行環境、そしてプログラミング言語まで自由に選べるわけです。もっと大事なことは、既存のコンポーネントの統合もできるということです。 ORB を使ったソリューションでは、開発者たちは単に、昔のコンポーネントを、新しいオブジェクト用に使った IDL を使ってモデル化して、標準バスと既存のインターフェースを結ぶ「ラッパー」コードを書けばいいだけです。

 はい、これはもういいでしょ。こんどはトッドの説明ね。

 RPC っておぼえてる? ほら、リモートプロシージャコールってやつ。Sun が NFS や NIS の基盤として使ってたよね。マイクロソフトも DCOM の下敷きとして、 Distributed Computing Environment の RPC 規格を使っている。

 リモートプロシージャコールってのは、実はかなり簡単な話だ。まず、なにか標準的な形式をでプロシージャを定義しておく。プロシージャの定義ってなにかって? まずはそのプロシージャの名前でしょ、そこにわたす引数でしょ、そして帰ってくる結果だわな。それからクライアントサイドをつくって、こっちはつまりクライアントに、引数をどうやってわたして、結果をどう受け取るかを考えればいい。それからサーバ側をやって、こっちは引数を受け取って結果を返せばいいわけだ。

 このモデルを使うと、なかなか強力なシステムがつくれる。たとえばふつうの Unix ファイルシステムのインターフェースをもってきて、それを RPC にすると、あら不思議、NFS になっちゃった。入出力さえ標準的に始末されてれば、プロシージャを呼び出すクライアントと、そのプロシージャをサービスするサーバとは、同じ言語で書く必要はないし、同じマシン上になくてもいいし、同じ OS やハードである必要すらないってことに注意。これがまさに、RPC の必殺技ってやつだ。

 でも、プロシージャ型プログラミング(C, Perl)はオブジェクト指向プログラミング(Objective C, Java, C++)にとってかわられつつあるので、RPC でもプロシージャだけではもう足りなくなってる。なにかオブジェクトをサポートしたものが必要だ。オブジェクトをつくって、オブジェクトデータをアクセスして、オブジェクトメソッドをアクセスして、オブジェクトを壊すようなことをサポートするものがほしい。そこで出てくるのが CORBA だ。だから CORBA は、次世代 RPC だと思ってもらえればいい。オブジェクト指向プログラミングをサポートするように拡張されてるってことだ。たとえば RPC のもとではこんなふうになるものがある:

void foo(int bar); void baz(){return(-1);}

これが CORBA だと、こうなるわけだ:

interface bubba{ void foo(in int bar); void baz() raises (InValidContext); } 

 で、教訓をまとめるとどうなるか? CORBA はソフトウェアコンポーネント間で、特定のプログラム言語にしばられない、場所の透過的な、オブジェクト指向インターフェースをプログラミングできるんだ。クールじゃん。

6.2.2. CORBA コンポーネントって、たとえばどんなの?

 ここでちょっと変わった CORBA 用語の定義をしておこう。そうしたほうが、みんな CORBA の「ノリ」を理解しやすいだろうし、そこに出てくるコンポーネントについても、おおざっぱに理解できるだろうから。読んだだけじゃわからない CORBA 用語を使うときは、ここで定義しておくつもり。

6.2.3. CORBA サービスってなに?

 さらにいうと、実は CORBA は 2 つの部分にわけられる。一つは、ぼくがいままで説明してきた部分で、オブジェクト化した RPC がどうの、引数をマーシャリングしてどうの、IDL ファイルを書いてどうの、GIOP がどう動くの、というような部分。残りが「CORBA サービス」。これは CORBA の基本インフラ上に構築したサービスで、分散オブジェクトプログラミングを楽にしてくれる。

 中でもいちばんだいじなところというと、ネーミングサービスかな。たとえば、あなたがプログラムで、なぜかスペルチェックサービスがいるとしよう。するとあなたにとって実にありがたいことに(ただしあなたの CORBA 実装がそれなりにまともである場合に限るけれど)、ORB を呼んで「ねえねえ、スペルチェックサービスがいるんだ。見つけてきて!」と言うだけでいいんだ。すると ORB はネーミングサービスを使って、スペルチェックサービスを提供するものとして登録されているオブジェクトを調べてくれる。そして ORB は、呼びつけたプログラムに電話をかけてたたき起こして、「スペルチェックサービスなら #867-5309 ですよ」てなことを言う。で、あなたは 867-5309 に電話をかけると、あらびっくり、ちゃんとそこにスペルチェックサービスがある。さて、そのサービスは、共有ライブラリで、あなたのアドレス空間にマッピングされてあなたがそこに直接関数コールをするのかもしれないし、モンゴルで、モンゴル FreeBSD ユーザグループが公共サービスとして、IIOP 経由でインターネットを通じて提供するご町内スペルチェックサービスかもしれない。あなたにはどっちかわからないし、モンゴルだとモンゴルの往復分でちょっと遅れが出るかもしれない以外は、どっちでもかまわないわけだ。ね、クールでしょ?

 ネーミングサービスはつまり、オブジェクトが将来使えるように登録しておく場所なわけだ。ほかにも CORBA サービスがあって、取引サービス(transaction service)、セキュリティサービス、時間サービス、「交際サービス(relationship service)」(というのはあなたが想像したようなしろものかもしれないし、そうでないかも)など、いろいろある。ぼくの手元にある CORBA サービス文書は 1997 年 3 月づけのもので、14 個が挙がってる。

 CORBA サービスの仕様は、http://www.omg.org/corba/csindx.htmの OMG web サイトにある。 もしこのどれかを実装してみたいなと思ったら、ORBit 開発者たちが喜んで声をかけてくれるはずだよ(ORBitを見てね)。

6.2.4. GNOME は CORBA のどのバージョンを使ってるの?

 OMG 内部では、いまバージョン 3.0 の CORBA をつくる作業が進行中だけれど、いまのところ GNOME は CORBA version 2.2 を使っている。これが現時点の規格だ。3.0 がいつ出るのかは聞いてない。

6.2.5. CORBA についてもっと知りたいんだけど。

 とっかかりとしていいのが、 Linas Vepstas の CORBA ページだ。 http://linas.org/linux/corba.html にある。

 CORBA と COM のちがいにみんなとても興味があるようなので、もう一個だけ論文を挙げておこう。http://www.research.att.com/‾ymwang/papers/HTML/DCOMnCORBA/S.html, DCOM and CORBA Side by Side, Step by Step, and Layer by Layer.

 最後に、セントルイスにあるワシントン大学の TAO プロジェクトは、TAO という独自の ORB を持っている。このグループを率いているのは、Dr. Douglas Schmidt だ。かれの CORBA ページにはいろいろいい情報がある。http://siesta.cs.wustl.edu/‾schmidt/corba.html. ここを見るときには、まわりに ACE と TAO のページもあるからついでに見ておこう。すごくためになる。

6.2.6. CORBA は GNOME でどんな役割を果たしているの?

CORBA は、GNOME のコンポーネントアーキテクチャを可能にしている。Win32 の COM/DCOM と似たような役割だ。

6.2.7. GNOME は CORBA のどの実装を使ってるの?

 はじめは、 ILU を使う予定だったんだ。 ILU はいろいろいいところがあって、なかでも複数の言語をサポートしているのが大きかった。でも、ILU は実にすてきだったんだけれど(いまでもそうだ)、Xerox 社がそれをどうする気なのかがはっきりしなかったし、そのライセンス条項がとどめの一撃だった。 ILU はフリーソフトじゃなかったし、GNOME チームががんばっても、 Xerox はライセンスを変えてくれなかった。 GNOME プロジェクトはフリーソフトでない技術は使わないことになっているので、これはそれでおしまい。

 それからプロジェクトは MICO に目をつけた。 MICO のいちばんいいところは、 Object Adaptor があって、 IIOP 準拠で、GPL になっていること。ただし、いまのところは C++ しかサポートしていないし、とにかくとんでもないメモリ喰いなんだ、これが。

 これじゃダメだということで、GNOMEr たちは、独自の ORB の作業にとりかかった。これが ORBit だ。

6.2.8. ORBit ってなに?

ORBit はマルチリンガルになるはず。これが可能だというのは、ILU が証明してる。いまのところは C しかサポートしていないけれど、将来的にはほかのプログラミング言語もサポートする(ホントホント、マジだよ。いまのところ C だけなのは、これがほんとうに始まったばかりのプロジェクトだからってだけ)。 GIOP/IIOP もサポートしてる。これは OMG の CORBA プロトコルで、異なる ORB 同士がやりとりできるようにするものだ。

 最後に、 ORBit は高性能になるはず。これはつまり、メモリ消費が少なくて、高速だということ。この点で、 ORBit は Flick からいろいろ智恵を拝借してる。ORBit プロジェクトのまとめ役 Elliot Lee は、もし要求されたサービスがローカルに実装されている場合には、CORBA の仕様に反せずに、CORBA コールの負荷をふつうのライブラリコールとほとんど同じところまで持ってこられる、と考えている。まあお手並み拝見といこうか。

6.2.9. なぜ GNOME はもっと CORBA を活かしてないの?

 大きな理由として、MICO が使いものにならず、メモリばかり喰って、C++ しか使えないなど多くの問題があったからだ。GNOME ORBit のが最近になってリリースされたので、 GNOME 内での CORBA の活用もやっとはじめられるようになった。

6.2.10. GNOME はどういうふうに CORBA を使うつもり? または BABOON ってなに?

(この部分はGNOMEr の親玉 Miguel de Icaza の文をほぼそのまま使っている)

 CORBA はいろんなところで使われるはずだ。それを簡単にしてアプリケーションの統合をはかるために、「Baboon」というインターフェースとライブラリルーチンコール群が使われる。

BABOON は、Baboon Allows Baboon Objects Over Networks(Baboon は Baboon オブジェクトをネットワーク上で使わせてくれる)の略だ。