![閉じる [x]](http://dw1.s81c.com/i/c.gif){kind=small}
CORBAについての議論を、過去から将来に移しましょう。これまでは、CORBAプログラミングの基礎的な面について説明してきましたが、CORBAまたはCORBA Serviceの中心的機能を一通りつかんだと言える前には、まだまだ紹介しなければならない細かい内容がたくさんあります。この広範な機能性が抱える問題は、複雑度が高いことで、これこそ、多くの人がCORBA環境での開発を恐れる理由です。分散アプリケーション開発でおもしろいのは、ほとんどの開発者が同様の基本サービスを数多くだれかに提供またはだれかから取得することに関心を示すことです。これらの基本サービスには、セキュリティー、イベント通知、永続性、トランザクションなどが含まれます。そしてこれらは、分散アプリケーションに長期的な価値を与えるために欠かすことができません。そこで、使いやすく、覚えやすく、分散しやすくするには、これらのサービスをどのようにパッケージするのか、という質問に対する答えが必要です。
CORBA Component Model (CCM) の仕様は、CORBAオブジェクト・モデルにおける上記のまたはその他の複雑性に対処できるようにすることを目的としたものです。CCMは、今年リリースが予定されているCORBA 3.0仕様の一部です。CCMは、CORBAアプリケーションを作成および配置するサーバー側のコンポーネント・モデルです。一般に受け入れられているデザインパターンを使用し、その使用を促し、大量のコードを生成することができる点では、Enterprise Java Beans (EJB) に非常によく似ています。また、これにより、システム・サービスはアプリケーション開発者ではなくコンテナー・プロバイダーが実装できます。これらのタイプのコンテナーのメリットとニーズは、アプリケーション・サーバー・ソフトウェアの成長を通して見ることができます。CCMは、標準環境として機能とサービスを定義することにより、CORBAオブジェクト・モデルを拡張します。その標準環境でアプリケーション開発者は共通に使われるCORBA Serviceと統合するコンポーネントを実装 、管理、構成、および配置することができます。これらのサーバー側のサービスには、トランザクション、セキュリティー、永続性、イベントなどがあります。
Object Management Group (OMG) のオープン方針に従い、CCMは言語に依存していません。つまり、OMGは、EJB標準よりも厳密にテクノロジーをパッケージしなければなりません。これは、バイナリー実行可能ファイルを記述するための完全な用語を提供するW3Cで策定中のソフトウェア・パッケージ・アーキテクチャーに基づいて実現されます。
すでにEJBを取り上げたので、CCM仕様の重要な部分は、EJBビーンをホストするためのCORBAコンテナーであるということもここで付け加えておきます。これにより、Javaで書かれたEJBビーンとすべてのCORBAプログラミング言語で書かれたCCMコンポーネント間の双方向相互運用性が提供されます。
CCM仕様では、コンポーネントの概念と、コンポーネントの実装、パッケージ、配置を指定するための総合的な一連のインターフェースおよびテクニックの定義が記述されています。他のOMGの仕様と同様に、新しい用語の一覧も記載されています。では、紹介しましょう。
- ファセット(Facets)
- ファセットを持つインターフェースというのを考えてみてください。コンポーネントのファセットとは、あるコンポーネントが公開する複数のインターフェースです。
- リセプタクル (Receptacles)
- これにより、コンポーネント同士が「つながり」合うことができます。コンポーネント・システムには、互いに協力することでクライアントに機能を提供する数多くのコンポーネントが収められています。リセプタクルにより、あるコンポーネントは、使用しなければならない依存しているオブジェクトへの参照を宣言することができます。リセプタクルは、コンポーネントが正しく機能するために必要なインターフェースを指定する仕組みを提供します。
- イベント・ソース/ シンク(Event sources/Sinks)
- これにより、コンポーネントは密接にリンクすることなく互いに協調動作することができます。これは、Observerデザインパターンによって提供される緩やかな結合です。コンポーネントがイベントをパブリッシュまたはエミットする関心があることを宣言した場合、これはイベント・ソースになります。パブリッシャーがイベントの排他的供給者であるのに対し、エミッターはイベント・チャネルを他のイベント・ソースと共用します。他のコンポーネントは、イベント・シンクを宣言することにより、これらのイベントのサブスクライバーまたは消費者になります。
- 属性(Attributes)
- コンポーネント値を構成時に指定することができる従来のCORBAインターフェースの属性の概念を拡張した CCMバージョンの属性では、値を利用したり変更したりする操作は例外を発生させることができます。これは、構成が完了した後で属性を利用したり変更した時に、構成上の例外を発生させる便利な機能です。
これらの新しい用語については、図1を参照してください。
図1. コンポーネント・モデル
コンポーネント実装定義言語 (Component Implementation Definition Language: CIDL)
前述の機能をすべてサポートするため、CCMはCORBAインターフェース定義言語 (CIDL) を「新しい宣言言語を導入する」ところまで拡張しています。CIDLは、IDLと同様、コンポーネントをコンテナーに取り込むために必要な 「配管工事」の多くを提供しなければならない仕事から開発者を解放してくれます。厳密に言うと、CIDLは、IDLのスーパーセットである、永続状態定義言語 (Persistent State Definition Language: PSDL) のスーパーセットです。OMG IDLはモーフィングであることに注意してください。CIDLは、コンポーネントの記述に強調点を置いた言語なので、新しいキーワードがたくさんあります。これらのキーワードはすべて、前述の機能をサポートするために追加されたものです。リスト1に例を示します。
リスト1. 例
interface VideoPlayer {
VideoStream play();
int fastForward(in
Speed spd);
int rewind(in Speed spd);
};
component VCR supports VideoPlayer{
provides AudioStream audioPort;
provides VideoStream videoPort;
};
component DVD supports VideoPlayer{
provides AudioStream audioPort;
provides VideoStream videoPort;
};
|
この例には、component、supports、provides というキーワードがあります。コンポーネントについてよく考えると、1つの考えが浮かび上がります。複数のインターフェースの必要性です。コンポーネントは、指定されたコンテナーにおける「適切な振る舞い」を実現するための一連のインターフェースを持ち、また、クライアントがビジネス・ロジックを実行するために呼び出すインターフェースを1つ以上持たなければなりません。前者のインターフェースのことを管理インターフェースと言い、後者のインターフェースのことをサービス・インターフェースと言います。OMG IDLでは、一連のインターフェースを、すべてのインターフェースを継承する1つの新しいインターフェースとして表現できるようにしました。この結合されたインターフェースは、たいてい長く、複雑なものでした。これに代わる方法としては、エントリー・ポイント・インターフェースというそのオブジェクトの他のインタフェースへとナビゲートするインターフェースを定義します。
OMGは、かなり前から複数インターフェースのギャップに気付いていました。実際、1996年に、このトピックに関するRequest for Proposal (RFP) が発行されています。このRFPは、文書で具体的に記述されたものではありませんでしたが、CCMは、このRFPの要件を満たしているものと考えることができます。CIDLで記述されているコンポーネント・タイプでは、継承として関係付けられるわけではない各種インターフェースの組み合わせが可能です。
コンポーネント・タイプ名はcomponent キーワードを使って定義します。コンポーネントには、コンポーネント定義で暗黙的に定義された、「同等(equivalent)」インターフェースと名づけられたインターフェースがあります。コンポーネントVCRとDVDの同等インターフェースはVideoPlayerです。その関係は、supports キーワードを用いて宣言します。
コンポーネントのファセットは、クライアントに公開するビジネス・ロジックを提供します。コンポーネントのこれらの「ファセット」は、キーワードprovides を用いて宣言します。提供されたインターフェースは、クライアントやその他のコンポーネントが接続できる「ポート」です。CIDLに導入されたもう1つのキーワードはuses キーワードであることとあわせて、このことは重要です。uses 宣言では、別のコンポーネントまたはCORBAオブジェクトによって提供されたインターフェースに対するそのコンポーネントの依存性を定義します。これで、クライアントは、provides 宣言から生成されたナビゲーション操作を使用して、実行時に指定インターフェースにナビゲートすることができます。
分散コンピューティングがソフトウェア・テクノロジーの向かう方向であることは、言うまでもありません。それはビジネスにも家庭にも適合します。コンポーネント製造方式は、自動車、ステレオ、台所でも利用されています。分散コンピューティングとソフトウェア・エンジニアリングが行き着くところは、覚えやすく、使いやすいパッケージとして必要な数多くのサービスを最終的に提供する、アーキテクチャー・モデルでしょう。CCMは、市販のコンポーネントや商品開発ツールに大きなチャンスを提供するだけでなく、市場化までの時間を最終的に短期化することにもつながります。これらをすべて組み合わせることで、ソフトウェアの長期的価値はさらに高まるのです。
次回からは、CCMのさまざまな性質を詳しく紹介します。新しいので、幅広く実装されていませんが、数か月、数年後には、CORBA 3.0とCCMについてもっと多くのことを見たり聞いたりするようになるはずです。
-
CORBA 3.0 Eases Object Development、TechWeb記事、1998年
-
The CORBA & CORBA Component Model (CCM) Page
-
The CORBA Component Model (CCM)
-
CORBA Component Model Will Help Developers Quickly Design and Implement Mission Critical Distributed Systems
米国ペンシルベニア州のBerwynに在住するDave Bartlett氏は、コンサルタント、著作家、講演者として活躍中です。「Hands-On CORBA with Java」という 5日間のコースの主催者であり、このコースは公開セッションの形でも、組織内のセミナーの形でも開催されています。現在は、このコースの資料をThinking in CORBA with Java という本にまとめる作業を行っています。Dave氏はペンシルベニア州立大学でエンジニアリングおよびビジネスの修士号を取得しました。ご質問、または特定のトピックに関する興味をお持ちの読者は、dbartlett@pobox.com でDave氏に連絡することができます。
