XPCOMとは何だろう? とお尋ねになることでしょう。XPCOMは、Cross Platform Component Object Modelの略で、クロス・プラットフォームのモジュラー・ソフトウェアを作成するためのフレームワークです。1つのアプリケーションとして、XPCOMは、一式のコアXPCOMライブラリーを使用してXPCOMコンポーネントを選択的にロードおよび操作します。XPCOMコンポーネントは、C、C++、およびJavaScriptで記述できます。そして、C、C++、およびJavaScript (開発中のPerlとPythonの拡張機能(参考文献を参照) が必要) から、XPCOMコンポーネントを利用できます。
XPCOMは、モジュール性のほかに、プラットフォームをまたがる軽快さも提供します。しっかりしたC++ コンパイラーが提供されているどのプラットフォームもサポートするのです。たとえば、次のとおりです。
- Microsoft Windows (全バージョン)
- Linux
- HP-UX
- AIX
- Solaris
- OpenVMS
- MacOS
- BSD
XPCOMソフトウェアを作成するのに必要なツールは、C++ コンパイラー、Perlインタープリター、およびいくつかのGNUツールです。
XPCOMを利用しているアプリケーションには、たとえば、次のようなものがあります。
- Komodo (IDE)
- Chatzilla (IRCクライアント)
- Games (MozInvaders、Xultris、その他)
- Jabberzilla (インスタント・メッセージ)
- NS6 (Netscapeブランドのブラウザー)
- Mozilla (ブラウザー)
さらに、これはXPCOMアプリケーションではありませんが、Adobe Acrobatは、XPCOMにバンドルされている同じJavaScriptエンジンの修正版を使用しています。要するに、XPCOMのコード・ベースは、十分にテストされ、広く利用されているということです。
Microsoft COMとXPCOM
読者の中には、XPCOMは、MicrosoftのCOMのようなものなのだろうかと考える方もおられるでしょう。その質問に対する簡潔な答えは「はい」でもあり「いいえ」でもあります。両者が違っている1つの分野は、コンポーネント・プロキシーです。コンポーネント・プロキシーとは、あるコンポーネントを利用したいコードが何かの理由で直接にはそのコンポーネントにアクセスできない場合に使用される、そのコンポーネントになりすます目的を持った仮装コンポーネントのことです。たとえば、アクセスしたいコンポーネントが別のプロセス、または別のマシンにあるために、コードから直接にはアクセスできない場合があります。
MicrosoftのCOMは、さまざまな種類のアプリケーションがコンポーネント (別のプログラムとして実行されているものや、別のマシン上で実行されているものさえ含む) とどのように通信するかを調整するための手の込んだプロキシー・メカニズムをサポートしています。MSCOMでは、さまざまなスレッド化モデルを用いてコンポーネントを作成することも、コンポーネントを特定のスレッド化モデルに限定することもできます。また、コンポーネントは、イン・プロセス (アプリケーション内で実行される) として作成することも、アウト・プロセス (別個のアプリケーションとして実行される) として作成することもできます。シングル・スレッド型のコンポーネントはそのコンポーネント専用のスレッドを持つ必要があるため、他のスレッドからそのコンポーネントにアクセスするためには、プロキシー・メカニズムを使用しなければなりません。アパートメント・スレッドのコンポーネントはスレッドを共用できますが、それでもプロキシーを必要とします。フリー・スレッドのコンポーネントは、同じプロセス内であれば、プロキシー・メカニズムを必要としません。スレッド化に関してそれぞれ特有の制約を持つコンポーネントに適切な程度のスレッドの安全性を提供するのが、MSCOMに組み込まれたこのプロキシー・メカニズムです。
XPCOMは、アプリケーション・レベルでのモジュラー・コンポーネントのサポートを提供するように調整されているため、プロキシー・サービスがサポートしているのは、通常なら再入不能なコンポーネントを複数のスレッドで共有することだけです。リモートからコンポーネントにアクセスしたい場合には、リモート・オブジェクトの間でデータをやり取りするための独自のプロキシーを自分で作成する必要があります。そのために役立つ既存のコンポーネントがいくつか用意されていますので、その作業は思ったほど難しくはありません。
顕微鏡的なレベルで見ると、XPCOMとMSCOMは同等なものに思えます。どちらもインターフェース・ベースであり、すべてのインターフェースを同じ基本インターフェースから派生させる必要があります。この基本インターフェースでは、3つのメソッド、つまりQueryInterface、AddRef、およびRelease が定義されています。このような観念的な共通点を受け継いでいるとはいえ、MSCOMおよびXPCOMのコンポーネントに互換性はなく、データ交換も可能ではありません。この2種類のコンポーネントを一緒に動作させるためには、何らかの種類のラッパーかグルー・コード (glue code) が必要です。Mozilla用の組み込みラッパーは、その好例です。それによって、ブラウザー・エンジンはMSCOMのActiveXコントロールのように見えるようになりますが、内部的にはそのブラウザー・エンジンはXPCOMコンポーネントに基づいて動作しています。
XPCOMとMSCOMで最も対照的な点は、XPCOMテクノロジーはオープン・ソースであるということです。MSCOMソフトウェアを開発している場合に、MSCOMライブラリーが自分のコンポーネントをロードする方法やコンポーネントを作成する方法の違いについて理解しようとしていて疑問が生じたとすると、それが解決されるかどうかは、どんな参考資料を入手できるかによって左右されてしまいます。幸いなことに、Microsoftは、自社のアーキテクチャーを広めるために労を惜しまず努力し、優れた資料を提供しています。とはいえ、もし仮にMicrosoftがこれらのシステム・レベルのライブラリーの振る舞いを変更したとすると、その変更があなたの作成したコンポーネントの振る舞いに影響を与える可能性があり、さらには、そのコンポーネントを使用するアプリケーションの振る舞いに影響を与える可能性もあります。
それとは対照的に、XPCOMアーキテクチャーを構成しているライブラリーのソース・コードはすべて入手可能なので、あなた自身のアプリケーション・コードと一緒に検査したり、トレースしたり、デバッグしたりできます。さらには、コード・ベースを変更して、自分でアーキテクチャーを拡張することさえ可能です。Microsoftがアーキテクチャーを拡張してくれるのを待つ必要はないのです (MSCOMは、単純なCOMから、DCOMを経て、COM+ まで進化してきました)。
オープン・ソースのソフトウェアにまだ馴染みのない読者は、まず他の有名なオープン・ソース・プロジェクトをいくつか調べてみるとよいでしょう。たとえば、GNUプロジェクトのFree Software Foundationファミリー、OpenBSD、Linux、OpenLDAP、OpenSSL、Apacheなどがあります(参考文献を参照)。
XPCOM、スレッド、CORBA、その他
さらに理解する必要がある事柄として、XPCOMがリモート・オブジェクト、スレッド、およびスクリプトをどのように処理するかという点があります。一部のXPCOMテクノロジーは、OMGのCORBAから継承されました。CORBAは、Object Management Group (OMG) によって標準化された、プラットフォームにも言語にも依存しないコンポーネント・テクノロジーです。それには、リモート・オブジェクトに対するプロシージャー呼び出しのための全体的なアーキテクチャー、インターフェース定義言語 (IDL。COMやXPCOMのIDLに似ている)、そして広範な共通オブジェクト・サービス群が含まれています。
厳密に言えば、XPCOMは、CORBAのようにリモート・オブジェクトをサポートしてはいません。しかし、XPCOMでも、別のコンポーネントと通信するためにソケットまたはその他の手段を使用するコンポーネントを記述できないことはありません。多くのXPCOMアプリケーションは、リモート・プロシージャー呼び出しを発行する手段としてHTTPを利用して、Webサーバーをホストとする他のコンポーネントと通信しています。さらに、SOAPをサポートするいくつかのコンポーネントも用意されています。CORBAとの別のつながりとして、XPCOMのIDL (インターフェース定義言語)コンパイラーがあります。それはXPIDLという名前で、オープン・ソースのCORBA IDLコンパイラーから派生したものです。
XPCOMは、確かにスレッドをサポートしています。ただし、スレッド・セーフなコンポーネントは標準的なものではなく、むしろ例外的です。ほとんどのコンポーネントは、メイン・アプリケーションと同じスレッド内に共存するように記述されるからです。もちろん、コンポーネントをスレッド・セーフとしてコーディングすることも可能であり、XPCOMでは、コンポーネントが自らをスレッド・セーフとして通知しているかどうかを判別するのにシンプルな方式を使用しています。
スレッドをほとんどあるいはまったくサポートしていないプラットフォーム上でも、スレッドのサポートはXPCOMによって十分に表現されます。XPCOMは、XPConnectと呼ばれる追加の層を介してスクリプトをサポートします。その層には、JavaScriptエンジンと、タイプ・ライブラリーのメカニズムが含まれます。これによって、JavaScriptコードからXPCOMコンポーネントを操作できるようになり、JavaScriptでインプリメントされたコンポーネントをC++コードからアクセスすることさえ可能になります。
Mozillaの歴史
XPCOMの使用例として最も有名なのは、Netscapeのブラウザー・パッケージであるCommunicatorです。約3年前、Netscapeは、自社のブラウザー・エンジンのソース・コードを、オープン・ソース・プロジェクトMozillaとしてリリースしました。他のソフトウェア・デベロッパーは、Mozillaフレームワークの調査を開始し、ある場合には、WebブラウザーやEメール・クライアントからはかけ離れたアプリケーションのコードやアイデアを研究するに至ったこともあります。NetscapeがXPCOMモデルを作成することにしたそもそもの動機は、モジュール式のクロス・プラットフォーム・ソフトウェアを作成するという自社の目標をサポートすることでした。ソフトウェアの大半は、CとC++ で記述されていました。
この記事の趣旨からすると、Mozillaとは、mozilla.orgというWebサイトのことでもあります。このサイトは、XPCOMのホーム・ページとしての役割を果たすとともに、コードや情報の優れたソースとなっています。1998年1月までさかのぼると、時はまさにブラウザー戦争の真っ只中でしたが、Netscapeは、自社のソース・コードをパブリックにリリースする計画を発表しました。同じ年の2月、mozilla.orgというWebサイトが開設され、Netscapeは当初の発表通り、3月の終わりまでにソース・ファイルを掲載しました。詳細については、「Mozilla open source FAQ」、「Mozilla free FAQ」、「Mozilla FAQ」をお調べください (参考文献を参照)。
Mozilla.orgは、単に人々が最新のtarファイルをダウンロードできるFTPサーバーであるだけではありません。次のような情報も掲載されています。
- Bugzillaと呼ばれる、Webベースのバグ追跡データベース
- Webベースのソース・コード相互参照システム
- Mozillaデベロッパー向けのさまざまなディスカッション・グループを主催するニュース・サーバー
- オンライン資料を検索するためのキーワード検索エンジン
- たくさんのHTMLベースの資料
ライセンスの問題
多くの会社は、オープン・ソース・ライセンスに慣れておらず、ソフトウェアを無料で提供することと、ソフトウェアとサービスを営利目的で提供することの間に、明らかな対立が見られます。ここで持ち上がる大きな疑問は、「XPCOMを使って作成したソフトウェアを販売することはできるのか?」ということでしょう。その答えは「はい」です。各種のオープン・ソース・ライセンスのほとんどは、"集約された" 作品 という考え方をサポートしています。
基本的に、XPCOMライブラリーを使用する別個のプログラムを作成した場合に行う必要があるのは、そのプログラムの一部がMozillaから取られていることを顧客に知らせることだけです (たとえば、そのプログラムの「バージョン情報」ダイアログに「Mozilla Powered」というロゴを置くという方法があります)。さらに、XPCOMのソース・コードを顧客が入手できるようにする必要もあります。ほとんどの人々は、MozillaのWebサイトへのリンクを提供することによって、その条件を満たしています。
あなたが作成したオリジナルのXPCOM対応アプリケーションのソース・コードについては、それを公開したり提供したりする必要はありません。ただし、XPCOMソースのどこかに編集を加えた場合は別です。その場合は、加えた改良をコミュニティーで共有する必要があります。
Mozillaで使用されているさまざまなソフトウェア断片の出所は、多岐に渡ります。一部のソフトウェアは、デュアル・ライセンスになっています。つまり、どのライセンス条件を満たすことにするかを、自分で選んでよいということです。Netscapeパブリック・ライセンス (NPL)、Mozillaパブリック・ライセンス (MPL)、およびGNUパブリック・ライセンス (GPL) を読む必要があるでしょう。また、標準以外のパブリック・ライセンスの下に自分のソフトウェアをリリースすることにした人たちのソフトウェアを使う場合には、その他のライセンスも読む必要があります。
注意しないと、自分の会社を巻き込んだ厄介な物語を生み出してしまうことがあります。その一例は、NVIDIAが偶然にもGPLに違反してしまったという事例です (参考文献を参照)。他の法的文書の場合と同じように、ライセンス・ソフトウェア (それがオープン・ソース・ライセンスであっても、そうでなくても) が関係するプロジェクトを立ち上げる計画がある場合には、弁護士に相談するべきです。
XPCOMを使い始めるには
あなたの会社の最高技術責任者 (CTO) から、XPCOMプロジェクトの開発リーダーになってほしいと頼まれたとしましょう。その場合、あなたと、あなたのチームのメンバーになる見込みのある人たちが、そのプロジェクトに適任であるためには、次のような知識が必要です。チームに所属するプログラマーは、CとC++ のことを十分に知っている必要があります。XPCOMでは、Cスタイルのマクロと、スマート・ポインター用のC++ のテンプレートを活用します。それらの知識が不足している人は、Mozillaのコード・ベースを理解するのにかなり苦労することでしょう。しかも、そのコード・ベースは、すぐに活用できるサンプル・ソース・コードの宝庫なのです。
COMに関する何らかの経験を持っていれば、それは大きなプラスになります。しかし、そのような経験があるとしても、土台部分 (テンプレートとマクロ) のコーディングと、実際の開発ツールの両方において、学習曲線が見られることになるでしょう。コード本体は、平均的なプログラマーがこれまで見たことがないほど堅固なものです。運がよければ、XPCOMの経験者 (外部のコンサルタントであってもよい) を見つけられるかもれません。そうすれば、新しいプロジェクト・メンバーの手助けをする指導役になってもらい、彼らの熟達を早めることができるでしょう。
そのような経験者がいないとしても、mozilla.orgのWebサイトが優れた情報源になります。また、Mozillaのニュースグループも利用できます。そのニュースグループでは、私たちのようなデベロッパーが技術的な質問を投稿したり、コード断片を投稿してレビューしてもらったり、XPCOMの将来の方向付けについて意見を求めたりできます。近いうちにニュースグループが再編成されますので、ご注意ください。具体的な変更内容は、必要な時点でWebサイトに掲載されるはずです。
たいへん役立つサイトをいくつかご紹介します。
- www.mozdev.org
- www.mozilla.org
- ftp.mozilla.org
- lxr.mozilla.org
- tinderbox.mozilla.org
- bugzilla.mozilla.org
C++ の知識に加えて、あなたと、あなたのチームのデベロッパーは、IDLコンパイラーの使い方を知っていることと、コアXPCOMインターフェースについて理解していることが必要です。さらに、あなたは、QueryInterface、AddRef、およびRelease というインターフェース・メソッドの目的について説明できなければなりません (寝ながらでも、詳細に)。
また、集約 (aggregation) という、コンポーネントに関連した難しい概念についても理解する必要があります。集約とは、あるコンポーネントを別の大きいコンポーネントの内側に配置する手段のことで、その大きいコンポーネントは、内側のコンポーネントへのインターフェース作業の一部を代行します。これは、オブジェクト指向プログラミングの概念の1つである情報の隠蔽と何ら変わりありません。集約という問題が持ち上がった理由は、すべてのXPCOMインターフェースにはQueryInterface メソッドを組み込まなければならないという事実にあります。これは、コードからコンポーネントを使用する際に、1つのインターフェースから別のインターフェースに切り替えることができるという意味です。このことから、別の既存のコンポーネントを拡張して新しいコンポーネントを作成しようとするときに問題が起きます。既存のコンポーネントのQueryInterface メソッドは、新しく派生したコンポーネントによって導入された新しい追加のインターフェースに対する要求に、何とかして応答できなければならないのです (しかも、新しいコードの内容を事前に知らない状態で)。これはなかなか厄介なことに思えますが、まさにそのとおりです。
最後に、あなたのプロジェクトのテストおよびQAチームのメンバーは、シェル・スクリプトとJavaScriptの書き方を知っている必要があります。さらに、クロス・プラットフォームのプロジェクトでサポートすることを計画しているオペレーティング・システムに関する実務的な知識も必要です。そのメンバーがスクリプトに習熟していれば、テスト用のスクリプトを素早く作成できるでしょうし、レグレッション・テストを自動化するのにも役立つでしょう。
もちろん成功の保証になるわけではありませんが、ここで紹介したようなスキルがあれば、あなたのチームは (一人のチームであれ、大人数のチームであれ)、XPCOMの提供している機能を活用して生産性を上げることができるはずです。
結論
この記事では、XPCOMという "新天地" を少し離れたところから調査して、XPCOMによって何ができるのか、そしてXPCOMを活用するために何が必要なのかについて、概要をつかむことができました。今後の記事では、実際に上陸してさらに調査を続け、土壌サンプルを採取します。全体として、コーディングする私たちの手が土まみれになることでしょう。具体的には、適切な開発環境をセットアップする方法、コンポーネントを使用できるようにアプリケーションにXPCOM対応機能を追加する方法、自分でコンポーネントを作成する方法を調べます。さらに、現実に即したやり方でテストする方法や、JavaScriptを使用して体系的にレグレッション・テストを実施する方法についても学びます。
参考文献
- この記事で言及された技術資料へのリンクは次のとおりです。
- Mozilla.orgにあるXPCOMのホーム・ページ
- 現在開発中の、PerlとPython用のXPCOM機能拡張
- XPCOMは、XPConnect と呼ばれる追加の層を介してスクリプトをサポートします。
- Microsoft COM の詳細情報。
- Adobe Acrobat は、XPCOMにバンドルされている同じJavaScriptエンジンの修正版を使用しています。
- フリー・ソフトウェアやオープン・ソース・ソフトウェアにあまり馴染みがない読者は、次のような進行中のプロジェクトについてもお調べください。
- オープン・ソース・ソフトウェアとフリー・ソフトウェアに関するMozillaのFAQとして、次のようなサイトがあります。
- 非常の多くのライセンスは次のいずれかに基づいています。
- NetscapeおよびMozillaパブリック・ライセンス (NPLおよびMPL)
- その他のフリーおよびオープン・ソースのライセンスとして、次のものがあります。
コメント
IBM PureSystems
IBM がどのように IT に革命をもたらしているのかをご自身でお確かめください
Knowledge path
developerWorks の Knowledge path シリーズでは、テーマ別の学習資料をご提供しています
ソフトウェア評価版: ダウンロード
developerWorksでIBM製品をお試しください！