JP2010504591A - 共通コンポーネントフレームワーク - Google Patents

Abstract

共通コンポーネントフレームワーク（ＣＣＦ）は多階層ソフトウエアアプリケーションにおける通信用のコンテナインターフェース及びコンポーネントインターフェースを提供する。コンポーネントコンテキストデータは、コンテナ内で実行するコンポーネントの最新の状態を記述するコンテナへ及び該コンテナから送信され得る。コンテキストデータはコンポーネントと相互作用するユーザーによって確認した特殊なエンティティ（例えば会社又は株券）に相当し得る。コンテナは、コンポーネントの振舞いを同期化しかつコーディネートするために異なったコンポーネント間でコンテキストデータを通信し得、比較的頑丈で一貫したユーザー経験をもたらす。コンポーネントコンテキストデータに加えて、特性、メニューオプション及びデータフィールドのような他の情報がコンテナとコンポーネントとの間で送信され得、ウェブに基づくコンポーネントをコンテナにより完全に結合するのをサポートする。
【選択図】 図２

Description

本発明は、総括的にはソフトウエアアプリケーションにおけるオブジェクト間の通信方法に関するものである。さらに特に、本発明はコンテナアプリケーションとコンテナ内のコンポーネントソフトウエアオブジェクトとの間に確立されたジェネリック通信フレームワークに関する。

ソフトウエアアプリケーションは、普通、ソフトウエアコンテナアプリケーション内で実行するモジュラコンポーネントに基づく多段アプリケーションとして実行される。これらのコンテナ・コンポーネントアプリケーションは、開発、可搬性及び拡張性において利点がある。コンテナアプリケーションは、トランザクション、セキュリティ、及びコンポーネント管理機能を処理でき、コンポーネントの開発者は自分のコンポーネントによって実行される特定の機能性に集中できる。さらに、コンテナは多数のコンポーネント間でコーデイネートでき、コンポーネントの各々と同時に通信することによって振舞いを同期化できる。

これらの利点が実現され得る前に、コンテナアプリケーションとそのコンポーネントとの間で有効な通信標準が確立されなければならない。これは、コンポーネント及びコンテナの両方が多数の異なるオブジェクトタイプの任意の一つであり得るので、努力目標であり得る。例えば、コンポーネントは、単一HTMLページ、ウェブに基づくオブジェクト、或いはアプリケーションオブジェクトの例として実行され得る。任意のウェブに基づくオブジェクトの場合、コンテナは別のウェブページ、或いはディスクトップコンテナアプリケーションである。通信の困難性を解消する先行技術の一つの方法では、固有のコンポーネントを備えたコンテナの使用が伴う。ディスクトップコンテナアプリケーションが、特にそのコンテナ内で使用するように設計した固有のコンポーネントを含んでいる場合、これらのいわゆる“スマート”コンポーネントはコンテナ環境内に密に一体化され得る。例えば、スマートコンポーネントは別個のポップアップウインドウで始まるよりむしろコンテナ例の柔軟なシート（例えばコンテナウインドウにおけるタイル又はタブのような）内に直接配置され得る。同様に、コンポーネントは比較的頑丈な機能性をサポートし、そしてコンテナの柔軟なパラダイム内に完全に一体化され得る。

しかし、ウェブに基づくコンポーネントは、固有のスマートコンポーネントのようにコンテナに密に一体化され得ない。従って、典型的なコンテナアーキテクチュアにおけるウェブに基づくコンポーネントは、しばしば限定された機能をサポートし、論理的なユーザー経験を殆どもたらさない。さらに、上述のように、コンテナ内でランする固有のスマートコンポーネントはしばしば特定のコンテナアプリケーションに対して特別に設計されなければならない。その結果、スマートコンポーネントはしばしば他のコンテナ内では動作できず、コンテナ・コンポーネントソフトウエアアプリケーションの主要な利点の多くを無にしている。

従って、多段ソフトウエアアプリケーションにおいてはコンテナとコンポーネントとの間の通信システムの必要性が残っている。

上記の課題に鑑みて、本発明は、多段ソフトウエアアプリケーションにおけるコンテナとコンポーネントソフトウエアオブジェクトとの間の通信用共通コンポーネントフレームワーク(CCF)を提供する。

本発明の一つの特徴において、コンポーネントはコンテナにおける登録機能の呼び出しを行う。この機能を用いることにより、コンテナ及びコンポーネントは、ジェネリック機能の呼び出し及びその他におけるデータ要求を実行するのに用いたCCFインターフェースポインターを交換し得る。ある実施形態では、インターフェースポインターのこの交換はコンポーネントの具体例の近くで生じ得るので、第2の機能呼び出しはコンポーネントがコンテナから呼び出し及びデータ要求を受ける準備ができていることを知らせるために登録機能の幾分後に用いられ得る。コンテナ及びコンポーネントによってこれらのインターフェースが一度確立されると、いずれかの側で範囲内で行われている他のユーザーアクション或いはその他の状態変化を通知し、通知したコンテナ又はコンポーネントが変化に基いてそれの振舞いをコーディネートする適切なアクションを取り得るようにする。

別の特徴において、CCFインターフェースポインターの交換の後、ユーザーは、例えばコンポーネントにおけるユーザーインターフェースコントロールをクリック又は選択することによってそのコンポーネントにおいてコンテキスト変化を生じさせる。例として、コンテキスト変化は財務データ又はニュース及び分析を行うコンポーネントにおいて財務上の実体（例えば会社、株券、債券、市場など）の選択に相当し得る。コンテキストの変化に応じてコンポーネントは、コンテナの変化を知らせる事象を送り、新しいコンテキストを提供する。コンテナは、必要ならばコンテキストデータを変換して、新しいコンテキストデータを、コンテナ内でランしている一つ以上の他のコンポーネントへ伝送する。従って、異なる機能を行うように別個に設計され開発されたコンポーネントでもCCFインターフェースを通してコンテナによってコーディネートされそして同期化され得、それによりユーザーに、より途切れない固有の経験をもたらす。

さらに別の特徴によれば、コンテキスト変化は、コンポーネントにおける一つのユーザーインターフェースコントロールの、同一コンテナでランしている別のコンポーネントへのユーザードラッグアンドドロップ操作によって生じ得る。コンポーネント間のドラッグアンドドロップサポートは、ユーザーにユーザーの選択の特定のコンポーネントへコンテキストをドラッグさせ得、或いは一つのコンポーネントのユーザーインターフェースから別のコンポーネントへ特殊なデータフィールドをユーザーにドラッグさせ得る。この機能の例として、財務データ検索コンポーネントによって戻されたサーチ結果は、同じコンテナ内でランしている近くのスプレッドシートコンポーネント（例えばマイクロソフトエクセルオブジェクトインスタンス）内へドラッグされ得る。

本発明のこれらの特徴並びにその他の輪転及び特徴は本発明の以下の詳細な説明、特許請求の範囲及び添付図面から明らかであり理解される。

本発明は例として添付図面に例示されるがそれらに限定されず、添付図面において同じ参照番号は同様な要素を示している。

本発明の特徴による計算環境のブロック線図を示す。 本発明の特徴によるソフトウエアコンポーネントアーキテクチャのブロック線図を示す。 本発明の特徴によるコンポーネントとコンテナとの間の通信を例示しているフロー線図である。 本発明の特徴による共通コンポーネントフレームワーク（ＣＣＦ）機能の実行を例示しているフロー線図である。 本発明の特徴によるＣＣＦコンテナ内のＣＣＦ作動型コンポーネントとのユーザー相互作用を説明しているスクリーン画面を示す。 本発明の特徴によるＣＣＦコンテナ内のＣＣＦ作動型コンポーネントとのユーザー相互作用を説明しているスクリーン画面を示す。 本発明の特徴によるＣＣＦコンテナ内のＣＣＦ作動型コンポーネントとのユーザー相互作用を説明しているスクリーン画面を示す。 本発明の特徴によるＣＣＦコンテナ内のＣＣＦ作動型コンポーネントとのユーザー相互作用を説明しているスクリーン画面を示す。 本発明の特徴によるＣＣＦコンテナ内のＣＣＦ作動型コンポーネントとのユーザー相互作用を説明しているスクリーン画面を示す。

以下の種々の実施形態の説明において、本発明の一部を成す添付図面が参照され、添付図面には本発明を実施し得る種々の実施形態を例示している。他の実施形態を利用でき、そして本発明の範囲から逸脱することなしに構造及び機能を変更できることは理解されるべきである。

本発明はソフトウエアオブジェクト通信に関するものであるので、最初に適当な汎用計算システム環境について説明する。一つ以上の特徴を実施し得るコンピュータ１００は、適当な計算環境のほんの一例にすぎず、明細書で説明する使用の範囲又は特徴の機能性に関していかなる限定も提示するものではない。

実例としての計算環境
図１には、本明細書に記載した一つ以上の特徴が実施され得る計算環境を示している。コンピュータ１００のような計算装置は、データを入力し、出力し、記憶し及び処理する種々のコンポーネントを内蔵し得る。例えば、プロセッサ１０５は、一つ以上のアプリケーションを実行し、記憶装置１１５のような記憶装置からデータを検索し、及び／又はディスプレイ１２０のような装置へデータを出力する種々のタスクを行い得る。プロセッサ１０５は、ランダム・アクセス・メモリ（ＲＡＭ）モジュール１１０に接続され得、このＲＡＭモジュール１１０にはアプリケーションデータ及び／又は命令が一時的に記憶され得る。ＲＡＭモジュール１１０は任意の順序で記憶され、アクセスされ得、ＲＡＭモジュール１１０における記憶場所に等しくアクセス可能である。コンピュータ１００はさらに読取り専用メモリ（ＲＯＭ）１１２を備え得、このＲＯＭ１１２は、そこに記憶されたデータをコンピュータ１００の作動停止後に残存又は提供できる。ＲＯＭ１１２は、コンピュータ１００の基本入出力システム（ＢＩＯＳ）を記憶することを含めて種々の目的のために用いられ得る。ＲＯＭ１１２は、さらに、動作停止及び再起動時でも情報を残存するようにデータ及び時間情報を記憶し得る。さらに、記憶装置１１５は、アプリケーション及びデータファイルを含めた種々のデータについて長期記憶できる。一つの例では、プロセッサ１０５は記憶装置１１５からアプリケーションを検索でき、そしてアプリケーションを実行しながらアプリケーションＲＡＭモジュール１１０に関連した命令を一時的に記憶できる。

コンピュータ１００は、種々のコンポーネント及び装置を通してデータを出力できる。上述のように、一つのかかる出力装置はディスプレイ１２０であり得る。別の出力装置は、スピーカー１２５のような音響出力装置を含み得る。各出力装置１２０、１２５はディスプレイアダプター１２２及び音響アダプター１２７のような出力アダプターと組合わされて、プロセッサ命令を相応した音響及びビデオ信号に変換する。出力システムに加えて、コンピュータ１００は、キーボード１３０、記憶メディアドライブ１３５及び／又はマイクロホン（図示していない）のような種々の入力装置からの入力を受信及び／又は許容し得る。出力装置１２０、１２５の場合には、入力装置１３０、１３５の各々は、入力をコンピュータで読取り可能／認識可能なデータに変換するアダプター１４０と組合わされ得る。一つの例では、マイクロホン（図示していない）を通して受信した音声入力はデジタルフォーマットに変換されて、データファイルに記憶され得る。一つ以上の例では、メディアドライブ１３５のような装置は、入力及び出力装置の両方として作用でき、それにより、ユーザーはデータを記憶メディア（例えばＤＶＤ−Ｒ、ＣＤ−ＲＷなど）に書き込んだり、かかる記憶メディアからデータを読み出したりできる。

コンピュータ１００はさらに、ネットワークを通してデータを送受信するための一つ以上の通信コンポーネントを備えることができる。種々の形式のネットワークは、セルラネットワーク、デジタル同報ネットワーク、インターネットプロトコル（ＩＰ）ネットワークなどを含む。コンピュータ１００はこれらのネットワークの一つ以上を通して通信する用にされたアダプターを備えることができる。特に、コンピュータ１００は、ＩＰネットワーク１６０（例えばＬＡＮ、ＷＡＮ又はインターネット）を通して一つ以上の他のコンピュータすなわち計算装置と通信するネットワークアダプター１５０を備えることができる。一つの例では、アダプター１５０は会社又は組織のネットワーク１６０を通しての電子メールメッセージ及び／又は財務データのようなデータの伝送を容易にさせることができる。別の例では、アダプター１５０はインターネット１６０のような国際ネットワークからの情報の受信又は伝送を容易にすることができる。アダプター１５０は、一つ以上のネットワークプロトコルに関連する一組以上の命令を備え得る。例えば、アダプター１５０は、ＩＰネットワークパケットを処理するための第１組の命令と、セルラネットワークパケットの処理に関連した第２組の命令とを備え得る。一つ以上の構成では、ネットワークアダプター１５０はコンピュータ１００に対して無線ネットワークアクセスを行い得る。

当業者には認められるように、コンピュータ１００のような計算装置は種々のその他のコンポーネントを備えることができ、図1に示す装置及びシステムに限定されない。

実例の特徴
共通コンポーネントフレームワーク（ＣＣＦ）のソフトウエアアーキテクチャ及びインターフェースの詳細について説明する前に、はじめに以下の説明を行う。ＣＣＦは、一つ以上のウェブに基づくソフトウエアコンポーネントとこれらコンポーネントに関連したコンテナとの間の通信を標準化するために用いられ得るインターフェースである。ウェブに基づくソフトウエアコンポーネントは、例えば単純なＨＴＭＬウェブページ或いはアクティブＸオブジェクトやジャワアプレットのような比較的複雑なウェブに基づくオブジェクトであり得る。コンテナはまたウェブページ或いはウェブに基づく親オブジェクトであり得るが、代わりにコンピュータ１００上でランするディスクトップソフトウエアアプリケーションでもよい。例として、ルータのエクストラ・ディスクトップ・ソフトウエアアプリケーションは、ＣＣＦ作動型コンテナとして機能するように実行され得る。ディスクトップアプリケーションＣＣＦコンテナの一つの潜在的利点は、ディスクトップコンテナ内に取り込まれたネイティブコンポーネントのものと同様な振舞いを示す操作可能なＨＴＭＬコンポーネントに関するものである。これらのネイティブ名いわゆる“スマート”コンポーネントは通常コンテナアプリケーション及び従ってしばしば特定のコンテナアプリケーションによって規定される。

図２を参照すると、ソフトウエアコンポーネントアーキテクチャのブロック線図が例示されている。図２において、コンテナアプリケーション２１０の単一実例は、一つ以上のＣＣＦ作動型コンポーネント（例えばコンポーネント２４０）及び非ＣＣＦコンポーネント（他のオブジェクト２５０〜２８０）を含めた多くの種々のコンポーネントを収容し得る。上述のように、他のオブジェクト２５０〜２８０は、コンテナ内に特定の機能をもたらすように設計したネイティブな（固有の）コンテナ・特定コンポーネントであり得る。コンテナ２２０はこの例では、コンテナアプリケーション２１０内でランし、ＣＣＦインターフェースのコンテナ側を実行するクライアント・アプリケーション・オブジェクトであり得る。コンテナ２２０は、アプリケーション２１０に収納した全ての他のコンポーネント２５０〜２８０と同じ又は同様な仕方でコンテナアプリケーション２１０と通信し得る。

コンテナ２２０と通信するウェブに基づくＣＣＦコンポーネント２４０は、マイクロソフト・インターネット・エクスプローラ（ＩＥ）・ブラウザのようなインターネット・ブラウザ・アプリケーション２３０のインスタンス内でランし得る。当然、代わりに他のブラウザ・アプリケーションを用いることができる。ブラウザ・アプリケーション２３０はＩＥ組み込み可能なオブジェクトの組み込みコピーである。以下に詳しく説明するように、コンポーネント２４０はＣＣＦコンテナ２２０と直接通信するので、コンポーネント２４０は任意の特定の銘柄又は形態のブラウザ・アプリケーション２３０に依存する必要はない。

コンテナ２２０が多数のＣＣＦコンポーネント２４０を収納している場合には、付加的な専用の記憶装置及び多数のコンポーネント２４０との同時通信を調整（管理）する論理装置が必要とされ得ることが認められる。この調整を行う一つの方法は、各収納したコンポーネント２４０に対してＣＣＦインターフェースの別個のインスタンスを維持することによる。

図２に示すものと僅かに異なる形態では、コンポーネント２４０のような多数のＣＣＦコンポーネントは、同じブラウザオブジェクト２３０内でランする。かかる形態では、ブラウザ２３０においてランする親ウェブページはそれ自体単一コンポーネントとしてコンテナ２２０に供給され得ると共に、またそれ自体コンテナとして多数の内部ＣＣＦコンポーネント２４０に供給され得るようにＣＣＦインターフェースのコンテナ側をサポートする。コンテナとコンポーネントとの間を通過するオブジェクト及びデータは、ブラウザ２３０で実行されるジャワスクリプト・インタープリタ―のネイティブオブジェクト及びデータであり得る。例えば、インターネット・エクスプローラ・ブラウザでは、ＩＥは、ＩＤイズパッチオブジェクト及びＶＡＲＩＡＮＴＳをジャワスクリプトタイプにかつジャワスクリプトタイプから自動的に変換する。こうしてＣＣＦコンポーネントはこのブラウザ機能を高めるように実行され得る。

上述のように、コンポーネント２４０は、ブラウザ２３０の任意の特定の銘柄又は形態に依存する必要はない。しかし、一つの形態では、ＣＣＦコンテナ２２０インターフェースは、コンポーネント２４０がマイクロソフト・インターネット・エクスプローラ・ブラウザのインスタンス、及び特にＩＥ ＣＯＭ組み込み可能なオブジェクトのインスタンス内に存在していると仮定する。この例では、ＣＣＦコンポーネント２４０は、コンテナ２２０を位置決めするためにインターネット・エクスプローラ特定オブジェクト“外部ウインドウ”をアクセスし得る。しかし、コンポーネント２４０がこのオブジェクトをアクセスできない場合には、結果として“外部ウインドウ”コンテナ２２０を備えず、それでブラウザ（例えばＨＴＭＬ）コンテナ２２０を位置決めするように試みされ得ることになる。ブラウザコンテナ２２０を位置決めするには、コンポーネント２４０は、ブラウザコンテナ２２０を備えていることを表すグローバルなジャワスクリプト機能について検索し得る。代わりに、コンポーネント２４０は、まず、“外部ウインドウ”コンテナ２２０にアクセスすることをする前に、ブラウザコンテナ２２０にアクセスすることを試みてもよい。当然、ＣＣＦ通信は、コンテナ２２０とコンポーネント２４０との間に少なくともある通信経路が存在する限り、コンテナ又はコンポーネントを位置決め（特定）しかつアクセスする他の技法を用いてコンテナ２２０とコンポーネント２４０との間で可能である。コンポーネント２４０がコンテナ２２０との通信を確立しない場合には、コンポーネント２４０のタイプ及び手段に関連してある特定のコンポーネントが低減した機能をもたらし得るが、それでもランし続け得る。

ＣＣＦインターフェースはまた、単にＣＯＭオブジェクトが、普通に知られた技法を用いてコンテナ２２０とコンポーネント２４０との間で通過されるように構成される。これらのＣＯＭオブジェクトはＩＤイズパッチンターフェースを実行し、ＶＡＲＩＡＮＴデータタイプのデータを通し得る。“外部ウインドウ”インターフェースはこのＣＯＭ／ＩＤイズパッチ通信を要求し得るが、他の通信方法では駄目であることが認識されるべきである。例えば、ブラウザコンテナ２２０はインターフェースを実行するのにネイティブなジャワスクリプトオブジェクト及び機能を使用し得る。

図３を参照すると、コンテナ２２０とコンポーネント２４０との間の通信のステップを例示しているフロー線図が示されている。ステップ３０１においては、コンポーネント２４０は、コンテナ２２０との登録機能すなわちいわゆるハンドシェーク（初期接続）機能を開始する。可能なハンドシェーク機能規定の例を以下に示す。

この例では、機能は新しいコンポーネント２４０によってCCFコンテナ２２０において呼び出される。コンポーネント２４０に戻されるナルでない値は、ハンドシェーク・プロセスが成功したことを表している。さらに、コンテナ２２０がウェブに基づくオブジェクト（例えば、図２に示すようにＩＥブラウザにおいてランするＨＴＭＬコンテナ）内でランしている場合には、レジスタ・ウイズ・ＣＣＦコンテナハンドシェーク機能はブラウザ内でグローバルである。しかし、コンテナ２２０がブラウザオブジェクトでランしない場合には、レジスタ・ウイズ・ＣＣＦコンテナハンドシェーク機能は、代わりに、外部ウインドウ・レジスタ・ウイズ・ＣＣＦコンテナを用いて行われ得る。

上記に示したように、レジスタ・ウイズ・ＣＣＦコンテナ機能は、その機能をＣＣＦ作動型コンポーネント２４０で呼び出すことができ、ＣＣＦ作動型コンテナ２２０はインターフェース・ポインタを交換するためにかかる呼び出しを受信できる。さらに、このハンドシェーク機能を処理している間に、コンテナ２２０は、例えば、コンポーネント・セションＸＭＬパラメータを解析することによってコンポーネント２４０でランしているＣＣＦバージョンを決めることができる。ある特定のインプリメンテーション（処理系）においては、バージョン・ナンバー（版数）は、ピリオド（期間）で区切られた三つの別個のパーツ（例えば数）から成り得る。例えば、コンテナ２２０は、コンポーネント２４０がＣＣＦインターフェース・バージョン“３．４．５”でランしていることを決めるために、コンポーネント・セションＸＭＬパラメータを解析する。この例では、最初の数（“３”）は、新しいＣＣＦインプリメンテーションが前のバージョンと互換性がない時に変わるだけである主バージョンである。第２の数（“４”）は、ＣＣＦインプリメンテーションにおける前のバージョンからのバックワード（逆方向）互換性変化を表している副（従）バージョンを表している。第３の数（“５”）は、ＣＣＦインターフェース自体を変えるものではないが、バグを修正したり特定の構成の意味をリファインし得るインプリメンテーションの変化を反映するのに用いられる。ＣＣＦバージョンが自体のＣＣＦインプリメンテーションによってサポートされないコンポーネント２４０でランしていることをコンテナ２２０が決めると、コンテナ２２０はナル値をコンポーネント２４０に戻すことによってハンドシェーク要求を単純に断り得る。

できれば、ＣＣＦインターフェースの新しいバージョンは、前のバージョンと逆方向互換性であるように設計され得る。ＣＣＦコンテナ及びコンポーネント・インターフェースの新しいバージョンにおけるバックワード及びフューチャ互換性を比較的良好に可能にするために、機能は、予期していない或いは認識していない入力がＣＣＦインターフェースの比較的最近のバージョンと通信することになりそうなので、かかる入力を取り消すように設計され得る。

図３に戻って、ハンドシェーク機能を満足に完了すると、コンテナ２２０はコンポーネント２４０からＣＣＦ呼出しを受信するように用意がなされる。従って、ステップ３０２において、コンポーネント２４０は、ＣＣＦコンテナ・インターフェースにおいて規定した機能を呼び出すことにより、コンテナ２２０における機能を呼び出す。利用可能なＣＣＦ機能呼出しについては以下で図４を参照して詳細に説明する。

ステップ３０３においては、コンポーネント２４０は“オンロード事象”をコンテナ２２０へ伝送する。以下で詳細に説明するオンロード事象は、呼出しコンポーネント２４０が現在ＣＣＦ機能呼出しを受信する用意ができていることをコンテナ２２０に指示する。従って、ステップ３０４において、コンテナ２２０内のコンポーネント２４０又は別のコンポーネントによる呼出しについてコンテナ・インターフェース機能を受信しサポートし続けながら、コンテナ２２０は、ＣＣＦコンポーネント・インターフェースにおいて規定した機能を呼出し得る。そして、ステップ３０５において、コンポーネント２４０はコンテナ２２０に“オンロード”事象を伝送し、コンポーネント２４０がもはやＣＣＦ呼出しを許可していないことをコンテナ２２０に指示することによりかかるコンポーネントを登録しない。オンロードがそれの消去中にコンポーネント２４０によって典型的に伝送されている間に、コンポーネント２４０はコンテナ２２０との通信を再確立するように繰り返し試み続ける。しかし、ある特定のインプリメンテーションにおいては、コンポーネント２４０は、ステップ３０１で得られたコンテナ・インターフェース・ポインタを再使用するようにはされない。かかる場合には、コンポーネント２４０は、コンポーネント２２０との通信を再開する前に、再び、コンテナのハンドシェーク機能（例えばレジスタ・ウイズ・ＣＣＦコンテナ）を呼び出すように要求され得る。

図４を参照すると、ＣＣＦ機能の実施を例示しているフロー線図が示されている。ステップ４０１において、機能呼出しは、ＣＣＦコンテナ２２０でか或いはＣＣＦ作動型コンポーネント２４０において受信される。上述のように、ＣＣＦコンテナ２２０は、ＣＣＦコンポーネント・インターフェースにおいて規定した、コンポーネント２４０でサポートされた機能と異なる、ＣＣＦコンテナ・インターフェースにおいて規定した、機能セットをサポートし得る。

ステップ４０２において、受信装置は、どのＣＣＦ機能が呼出しによって引き出されたかを決める。この例では、コンテナ２２０とコンポーネント２４０との両方によって単に二つだけの可能なＣＣＦ機能すなわち“ＧｅｔＤａｔａ（）”及び“ＰｒｏｃｅｓｓＥｖｅｎｔ（）”機能がサポートされる。コンテナ・インターフェース及びコンポーネント・インターフェースは、同じ機能規定（すなわち同じ数及びデータタイプの入出力パラメータ）をもち得る同一セットのＣＣＦ機能を規定し得るので、これは、コンポーネント・インターフェースでサポートされた実際の機能性がコンテナ・インターフェースでサポートされたものと同じであること意味していない。例えば、ＣＣＦ ＰｒｏｃｅｓｓＥｖｅｎｔ（）”機能は、事象名称に相応するストリング（文字列）入力パラメータを許容し得、種々のセットの事象はコンテナ２２０及びコンポーネント２４０によってサポートされる。ＣＣＦコンテナ・インターフェース及びＣＣＦコンポーネント・インターフェースで潜在的にサポートされた事象のリストを以下に説明する。ＣＣＦインターフェースに対してこの事象及びデータ回復機能を実行する一つの仕方は以下のインターフェース規定で例示される。

この例では、ＩＣＣＦオブジェクトはｇｅｔＤａｔａか又はｐｒｏｃｅｓｓＥｖｅｎｔ機能をサポートする。機能規定に示されるように、ＩＣＣＦＯｂｊに対するポインターは両方のＩＣＣＦ方法によって要求された入力パラメータである。パラメータとしてパスした参照ＩＣＣＦＯｂｊは、（ｐｒｏｃｅｓｓＥｖｅｎｔ機能によって）伝送される事象或いは（ｇｅｔＤａｔａ事象によって）要求されるデータに相応した“名称”ストリング（例えばＢＳＴＲ）を含んでいる。参照ＩＣＣＦＯｂｊはまた、事象又は要求を処理するためにコンテナ２２０又はコンポーネント２４０によって解析され用いられ得るＸＭＬ（拡張マーク付け言語）文書の形態の付加的な情報を提供するために、“ｘｍｌｄａｔａ（拡張マーク付け言語データ）”ストリング（文字列）を含んでいる。

事象及び回復可能なデータの種々の形態が可能であり、以下ある起こり得る事象及び要求名称について詳細に説明する。しかし、ある形態では、ＣＣＦ機能呼び出しで通過したＩＣＣＦＯｂｊにおける名称識別子はナルすなわち空値にできない。すなわち、事象名称又は要求されるデータを特定することなしにデータを要求し或いは事象を伝送するあらゆる試みは、結果として呼ぶ側に戻されるエラーとなる。これに対して、ｘｍｌｄａｔａ識別子は、多くの事象又はデータ要求が事象又は要求をうまく処理するためにＣＣＦコンテナ２２０又はコンポーネント２４０に対して付加的なデータを全く要求し得ないので、しばしばナル又は空値であり得る。

従って、機能呼び出しに関係なく、名称及びｘｍｌｄａｔａパラメータは、ステップ４０３において呼び出しを受信するＣＣＦオブジェクトによって解析され、それで所望の事象又はデータ要求は処理され得る。ステップ４０４において、要求された機能性は実施され、そしてステップ４０５において、機能戻り値及び／又はデータは機能呼び側に戻される。

図３及び図４に参照して上記で説明したように、コンテナ２２０及びコンポーネント２４０は、それぞれのＣＣＦインターフェースを介して事象を伝送しそしてデータ要求を行うことにより相互作用し得る。これらの事象及び／又はデータ要求がなされる時に、データは、ＣＣＦスキーマ・ファイルによって特に規定された複合顧客データタイプ（例えば情報タイプ）にパスされる。ＣＣＦスキーマ・ファイルは普通、ＸＭＬ文書（例えばＸＭＬスキーマ定義（ＸＳＤ）ファイル）として実施され、そしてＣＣＦコンテナ及びコンポーネント機能性を実行するＪａｖａＳｃｒｉｐｔファイルと共にコンピュータ１００にダウンロードされる。普通に知られているように、ＸＳＤファイルは、ＸＭＬ要素及び属性の項目で、いかなるデータ値及びタイプに基いて要素及び属性が記憶し得る条件と共に情報タイプを規定できる。他のＸＭＬ文書と同様に、ＸＳＤは、受信するソフトウエアコンポーネントによって解析されそして適切なタイプのオブジェクト実例（インスタンス）を生成するのに用いられ得る。

情報タイプを規定するサンプルＸＳＤファイルは以下に含まれる。この例では、コンテキストデータ情報タイプを、コンテキストデータＸＳＤファイルによって十分に説明する。タイプ名称はｘｓ：ｃｏｍｐｌｅｘＴｙｐｅ要素の“名称”属性で指定され、またタイプの構造はこのｘｓ：ｃｏｍｐｌｅｘＴｙｐｅタグ内に含まれるもので規定される。従って以下の例では、

反復記号はコンテキストデータタイプの構造を表し、数字やストリングのような簡単なデータタイプのセットを含み得、そしてまたさらに複雑な埋め込みデータタイプも含み得る。以下のコンテキストデータＸＳＤファイルでは、コンテキストデータタイプは一連の実体オブジェクト（＜ｘｓ：ｓｅｑｕｅｎｃｅ ｍａｘＯｃｃｕｒｓ＝“ｕｎｂｏｕｎｄｅｄ”＞ｔａｇ内の＜ｘｓ：ｅｌｅｍｅｎｔ ｒｅｆ＝“Ｅｎｔｉｔｙ”＞ｔａｇで表された）及び任意のストリング属性名称付きｓｅａｒｃｈＩＤ（＜ｘｓ：ａｔｒｉｂｕｔｅ ｎａｍｅ＝“ｓｅａｒｃｈＩＤ”ｔｙｐｅ＝“ｘｓ：ｓｔｒｉｎｇ”ｕｓｅ＝“ｏｐｔｉｏｎａｌ”＞ｔａｇで表された）を含む。さらに、コンテキストデータＸＳＤファイルでは、実体オブジェクトタイプは同様にして定義される。従って、送信側からＸＭＬデータを受信するソフトウエアコンポーネントは、ＸＭＬを解析してタイプ“コンテキストデータ”のオブジェクトを表しているかを決め、そしてコンテキストデータＸＳＤファイルにアクセスして受信したデータの妥当性を確認し、コンテキストデータソフトウエアオブジェクトを構築しそしてＸＭＬファイルから解析した値をもつオブジェクトを生成することができる。

本明細書に記載した多くの可能なＣＣＦ事象及びデータ要求において、“コンテキストデータ”データタイプの実体は、ＣＣＦコンテナとコンポーネントとの間の最も頻繁にパスした情報である。その最も単純な形式では、コンテキストデータ実体は、単一エンティティ（例えば、財務上の実体（例えば会社、株券、債券、市場、土地など）を、そのエンティティの一つ以上の識別子（例えばＲＩＣ、ＣＵＳＩＰ、ＩＳＩＮなど）を記憶することにより記載し得る。他の場合には、コンテキストデータ実体は、主エンティティと関連するフィールド（すなわち名称値対）及び／又はサブエンティティオブジェクトを表す多くの複合データを保持し得る。コンテキストデータ実体は、またエンティティのフラット・リストか又は階層木構造として記憶したエンティティのリストから成り得る。

コンポーネント２４０はコンテナ２２０内でランしている間に、コンポーネント２４０は典型的には、コンポーネント２４０のユーザーインターフェース内に与えられるデータのフォーカスに基いて設定され得る主コンテキストを備えている。コンポーネント２４０ユーザーが例えばコンポーネントＵＩにおいて異なるエンティティ項目をクリックすることにより新しいフォーカスを設定すると、それに応じてコンポーネント２４０はそれの主コンテキストを更新すべきであり、こうしてコンテナ２２０は最新のコンテキストを得ることができ、そして他のコンポーネントとディスプレイ／アクティビィティを同期化できる。コンポーネント２４０は、それ自体の主コンテキストを単純に維持する他に、コンテキストメニュー選択のためにユーザーマウスクリック、ダブルクリック、ドラッグ或いは右クリックの形式で付加的なコンテキストをコンテナ２２０に出力し得る。これらの付加的なコンテキストは他のコンポーネントに入力するためにコンテナ２２０によって用いられ得る。

コンテナ・コンポーネントＣＣＦ通信に適合した情報タイプの幾つかの付加的な例は、ＸＳＤファイルとして記載され、下記に参考として挙げられる。

上記で説明したように、コンテナ２２０及びコンポーネント２４０がＣＣＦインターフェースポインターを交換すると、それらはそれらのそれぞれのインターフェースを介して相互作用し得る。この相互作用は、図４において例示したように一方から他方へ伝送した事象及び要求の形式を取り得る。以下のセクションは、ＣＣＦインターフェースに含まれ得るある特定の事象及びデータ要求についての情報を提供する。同じセットの事象及びデータ要求は両方向において（すなわち、コンテナインターフェース及びコンポーネントの両方において）実行され得るが、単に一方向においてのみ実行される他の事象及び／又はデータ要求があり得る。例えば、コンポーネント対コンテナ事象は、相応したコンテナ対コンポーネント事象がサポートされない場合に、コンポーネント２４０の最新の状態の表示としてそれのコンテナ２２０へ伝送され得る。以下の多くのコンポーネント対コンテナ事象はコンポーネントに置けるあるユーザー作用によってトリガーされる。

コンポーネント対コンテナ事象の例
１． オンロード この例では、オンロード事象は、ハンドシェーク作用の後コンテナ２２０に伝送される最初の事象である。この事象は、コンポーネント２４０が目下初期化され、そしてコンテナ２２０からの事象及び要求を許容するように準備されることを表している。この事象で伝送される該データはＸＭＬ文書としてコンテナ２２０に伝送されるコンポーネント２４０の記述である。
２． オンアンロード オンアンロード事象は、コンポーネント２４０の実体からコンテナ２２０に伝送される最後の事象である。この事象では、データは伝送されない。この事象に対するプロセス事象作用呼び戻しの後、コンポーネント２４０はもはやコンテナ２２０から事象及び要求を受け入れない。しかし、コンテナ２２０は、この事象の処理中にコンポーネント２４０へ要求及び／又は事象を伝送し得る。
３． オンクリック オンクリック事象は、コンポーネント２４０のユーザーインターフェースにおいてコンテナ２２０のユーザーマウスクリック作用が行われていることを通知する。この事象は、コンテナ２４０がデータリンクのためにこのデータを使用したい場合に、別のコンポーネントにデータリンクする（すなわちコンポーネント２４０の出力が別のコンポーネントに対する入力として用いられる）コンポーネント２４０に対する機構である。この事象に対するデータは、ユーザーがクリックオンしたコンポーネント内のエンティティ（例えば、ユーザーインタフェース制御ボタン、ドロップダウンメニューなど）を記述し、そしてコンテキストデータＸＳＤファイルにおける上述で定義したコンテキストデータ実体の形式を取り得る。
４． オンダブルクリック オンダブルクリック事象は、オンクリック事象と同様であるが、コンテナ２２０がコンポーネント２４０のユーザーインターフェースにおいてユーザーダブルクリックを行うことを通知する。
５． オンコンテキストドラッグスタート オンコンテキストドラッグスタート事象は、ユーザーがコンポーネント２４０に表示されたあるエンティティをドラッグしようとしていることをコンテナ２２０に通知する。オンクリック事象と同様に、この事象に対するデータは、ユーザーがドラッグしているエンティティを記述する（例えばエンティティコンテキストを記述する）コンテキストデータ データ構造であり得る。オンクリック事象と同様に、この事象は、コンポーネント２４０から別のコンポーネント内へデータ出力を供給するのに用いられ得る。
６． オンコンポーネントドラッグスタート オンコンポーネントドラッグスタート事象は、ユーザーが全体コンポーネントをドラッグするように試みていることをコンテナ２２０に通知するためにコンポーネント２４０によって伝送される。このコンポーネントはコンポーネント２４０であり得、或いは別のコンポーネント（例えばコンポーネント２４０のサブディスプレイ）であり得る。ある特定のコンポーネントは、例えばユーザーインターフェースにおいてクロック・アンド・ドラッグについてユーザーのドラッグ“ハンドル”表示することによってドラッグ操作をサポートし得る。この事象は、コンポーネントの最新の状態を記述するデータ構造を提供し、そしてコンテナ２２０における別の場所においてコンポーネント２４０を複製することによって用いられ得る。
７． オンコンテキストメニュー オンコンテキストメニュー事象は、ユーザーがコンポーネント２４０内で右クリックしていることをコンテナ２２０に通知する。この事象を受信した後、コンテナ２２０はコンポーネント２４０のユーザーインターフェースにコンテキストを表示することで応答し得る。この事象は右クリックの位置のスクリーン関連座標のようなデータを、コンポーネント２４０がコンテキストメニューに加えたいメニューオプションを表す情報と共に提供し得る。さらに、ユーザーの右クリックがユーザーインターフェースエンティティにおいてなされた場合には、データは、エンティティが該事象で伝送され得ることを記述している。
８． オン更新コマンドバー オン更新コマンドバー事象は、ユーザー作用に応じて伝送され得る。事象データは、コンテキストメニュー、ツールバー及び／又はサービスメニューを記述している。この事象を用いて、コンポーネント２４０は、コンポーネント２４０がランしている間にこれらのメニュー又はツールバーを顧客対応し得る。例えば、コンポーネント２４０は、オンコンテキストメニュー事象において特化された値を変えるためにオン更新コマンドバーに新しい値を提供し得る。
９． オンコンテキスト変更 オンコンテキスト変更事象は、コンポーネント２４０が現在主フォーカスを変更したことをコンテナ２２０に通知する。事象データは新しいコンテキストを記述している。
１０． オン特性変更 オン特性変更事象は、一つ以上の特性の値が変更したことをコンテナ２２０に通知する。この事象のデータは、変更した特性を記述し、新しい値を含み得る。
１１． オンポップアップ オンポップアップ事象は、コンテナ２２０がコンポーネント２４０のユーザーインターフェースにＣＣＦ作動オンポップアップウインドウを備えたい場合にコンテナ２２０によってコンポーネントへ伝送される。該事象でコンテナ２２０によって伝送されるデータは、ポップアップウインドウの好ましいサイズ及び場所に相当し得る。データはまたポップアップウインドウにロードされることになるＣＣＦコンポーネント２４０の記述も含み得る。
１２． オンログ オンログ事象は、コンテナ２２０のログファイルにおけるエントリーが一つであることを要求するようにコンポーネント２４０によって伝送される。コンポーネント２４０はこの事象を用いてコンポーネントの重大な出来事（ハプニング）（例えばエラーの発生、ユーザートランザクションなど）を記録し得る。事象データは、ログすべきメッセージのテキスト及び重大度（例えば臨界、高い、警告、情報、デバッグなど）を含んでいる。ある特定のログしたメッセージは、例えばＣＣＦコンポーネント２４０におけるエラーをデバッグするため、ユーザーによって読取られることなる場合に付加的なユーザー便宜のためにローカライズされ得る。

コンポーネント対コンテナデータ要求の例
１． 永続データ 永続データ要求は、例えばコンテナ２２０が保存コピー、コンポーネントドロップ、コンポーネントペーストから、或いはポップアップ事象に応じてコンポーネント２４０を作る際に用いられ得る。このデータ要求でコンポーネント２４０によってデータは伝送されない。この要求の戻り値は、コンポーネント２４０の必要な全ての状態情報を含み得、それでコンポーネントはそれの状態を回復できる。例えば、コンポーネント２４０は、ハンドシェーク機能呼び出しを首尾よくした後でしかもオンロードを伝送する前にこの要求を行い得る。コンテナ２２０は、コンポーネント２４０の寿命を通してこの状態データのコピーを保持し得る。
２． 探索 コンポーネント２４０は探索データを伝送し、コンポーネント２４０に代わってコンテナ２２０が探索を行うようにする。この要求で供給されるデータは実行されることになる探索を記述している。

コンテナ対コンポーネント事象の例
下記は、コンテナ２２０が上記で述べたオンロードとオンアンロードとの間で、コンポーネント２４０に伝送し得る事象の例である。
１． オンコンテキスト変更 オンコンテキスト変更事象は、コンテナ２２０で伝送されたコンテキストでコンポーネント２４０の実体を提供する。事象でパスしたコンテキストデータがコンポーネント２４０の現在の存在するコンテキスト情報と整合しない場合には、この事象はコンテキストを変更するようにコンポーネント２４０における要求として機能し得る。事象は別のＣＣＦ作動コンポーネントで生じ得、そしてコンテナ２２０で変換される必要なしに、コンテナ２２０を介して意図したコンポーネント２４０へ伝送され得る。他のオンコンテキスト変更事象呼び出しにおいては、コンテナ２２０はコンテキストをコンポーネント２４０に伝送する前にこのコンテキストを変換する必要があり得る。或いはそれは未知のタイプの識別子でコンテキストを構成し得そしてその識別子をコンポーネント２４０へ通して解釈させ得る。
２． オン特性変更 オン特性変更事象は、コンテナ２２０にコンポーネント２４０の一つ以上の特性の値を変更させ得る。変更すべき特性に相応したデータはこの事象で伝送され得る。コンポーネント２４０は、コンポーネント２４０に対する読み取り専用特性又は非存在特性を変更するコンテナ２２０による試みを無効にするように構成され得る。
３． オンコマンド オンコマンド事象は、ユーザーがメニュー又はツールバー（例えばＲｅｕｔｅｒｓツールバー、サービスメニュー、またはコンテキストメニュー）から選択したことをコンポーネント２４０へ通知する。この事象で提供されるデータはユーザーの選択を記述している。

コンテナ対コンポーネントデータ要求の例
１． コンテキスト コンテナ２２０はコンポーネント２４０の最新のコンテキストを検索するためにコンテキストデータ要求を用い得る。このデータ要求ではデータは供給されない。コンテナ２２０は、コンテナ２２０が同時に表示し得る他のコンポーネントとコンポーネント２４０を同期化するために、コンポーネントスタートアップ中にこの情報を用い得る。
２． 記述 記述データ要求はコンポーネント２４０の記述をコンテナ２２０へ戻す。これはコンポーネント２４０で伝送したオンロード事象でパスされた同じ記述であり得る。従ってコンテナ２２０がこの値をキャッシュしていない場合には、このデータ要求でそれを得ることはできない。
３． 永続データ 永続データ データ要求は、コンテナ２２０にコンポーネント２４０の最新の状態のコピーを検索させ得る。永続データ データ要求は、ユーザーがコンポーネント２４０を保存したい場合に用いられ得る。
４． 特性 特性データ要求はコンポーネント２４０の全ての特性の最新の値を検索するためコンテナ２２０によって伝送される。
５． ヘルプｕｒｌ ヘルプｕｒｌデータ要求は、コンテナ・レベルヘルプ機能性を作成する際に、コンテナ２２０の便宜性のために設けられたヘルプ汎用リソース・ロケータ（ＵＲＬ）のコピーを戻す。
６． インプットオーナー インプットオーナーデータ要求はストリング（文字列）“コンポーネント”か又は“コンテナ”を戻し、そしてユーザー入力を制御するためにコンテナ２２０によって用いられる。値は、入力フォーカスがコンポーネント２４０内のユーザーインターフェースコントロールにある際には“コンポーネント”に設定され、そしてその他の全ての時間では“コンテナ”である。コンテナ２２０はこの値を用いて、ユーザー入力（例えばキーボード及びメニュー入力）を処理するか或いはコンポーネント２４０で処理すべきユーザー入力を通すかどうかを決めることができる。

コンテナとコンポーネントの両方についての上記のＣＣＦ機能性は、ウェブページに埋め込まれそしてブラウザ２３０で実行され得るスクリプト言語、例えばＮｅｔｓｃａｐｅ ＪａｖａＳｃｒｉｐｔで書き込まれた顧客側フレームワークとして構成され得る。このような構成では、ＣＣＦ ＪａｖａＳｃｒｉｐｔファイルは各コンポーネントに含まれるように要求され得る。しかし、コンポーネントクリエータはまた、他の技術、例えばマイクロソフト・ビジュアル・ベースを用いてＪａｖａＳｃｒｉｐｔ事象供給及びアプリケーションプログラムインターフェース（ＡＰＩ）を潜在的に作成し得る。さらに、コンポーネントクリエータはＪａｖａＳｃｒｉｐｔにおいてそれら自体のインターフェースを作成し得る。

次に図５及び図６を参照すると、コンポーネント・コンテナ通信のために上記のＣＣＦ作動機能を用いてサポートされ得るユーザー機能性を例示する例が示されている。

図５において、ＣＣＦ作動ストック・トラッカーコンポーネント２４０はコンポーネントユーザーインターフェースディスプレイペイン５１０に表示される。同時に、ニュースヘッドラインを表示するように構成した別のコンポーネント２４１は、同一コンテナ２２０内でランし、コンポーネント２４０に隣接したブラウザに表示される。この例では、コンテナ２２０はルータの３０００Ｘｔｒａコンテナアプリケーションの実例であり、またストック・トラッカーコンポーネント２４０は３０００Ｘｔｒａ引用符オブジェクトである。図５に示すように、コンポーネント２４１のディスプレイペイン５２０は、ニュースを表示するために目標会社が選択しなかったので、空である。言い換えれば、コンポーネント２４１はランするが、最新のコンテキストを備えていない。また図５に示すように、ストック・トラッカーコンポーネント２４０の最新のコンテキストはＩＢＭコーポレーションに相当する“ＩＢＭ．Ｎ”である。

この例では、ストック・トラッカーコンポーネント２４０は、上記のオンコンテキストドラッグスタート事象を用いてコンテキストのドラッグ及びドロップをサポートするＣＣＦ作動コンポーネントである。従って、ユーザーは、最新のコンポーネント２４０外のディスプレイペイン５１０における強調した“ＩＢＭ．Ｎ”をクリックしドラッグし得、そして図５に例示するように、隣接したコンポーネント２４１のディスプレイペイン５２０に入れられる。ユーザーがコンポーネント２４０内のエンティティをドラッグする時、ドラッグされるエンティティはコンテナ２２０に出力として伝送され得、それでコンテナ２２０はコンテキストを記憶でき、そしてエンティティがドロップされる時該コンテキストを使用できる。

ユーザーが異なるＣＣＦ作動コンポーネント２４１におけるエンティティをドロップすると、新しいコンテキストがコンテナ２２０から目標コンポーネント２４１にパスされる。それに応答して、コンポーネント２４１は、コンテナ２２０によって提供される新しいコンテキストと整合するように主コンテキストを変更するのに必要な（しばしばコンポーネント特有の）作用を行う。新しいコンテキストがこの例の場合のように別のＣＣＦ作動コンポーネントで生じる場合には、事象は通常変更なしのコンテキストをパスする。しかし、新しいコンテキストが非ＣＣＦ作動コンポーネントのような別のソースから生じる場合には、コンテナ２２０は入力を適切なコンテキストに変換するように試み得る。コンテナ２２０は、供給された入力をそれ自体においてコンテキストデータに（例えば探索機能性を用いて）変換するように試み得、或いは目標コンポーネントがコンテキストを理解するという見込みにおいて、未知のタイプの識別子をもつ非ＣＣＦ作動コンポーネントから目標コンポーネントへコンテキストを単純にパスし得る。

この例では、ソースコンポーネント２４０及び目標コンポーネント２４１の両方はＣＣＦ作動されるので、コンテキストパスプロセスは相当に容易であり得る。目標コンポーネント２４１は、例えばオンロード事象でパスした記述データを用いて、許容できるコンテキストデータのタイプをコンテナ２２０に記述し得る。そうである場合には、コンテナ２２０はコンポーネント２４０とコーディネートして、目標コンポーネント２４１に対するコンテキストの正しいタイプを得ることができる。さらに、必要ならば、コンテナ２２０は、コンテキストを目標コンポーネント２４１に許容できる形式及びデータタイプに変換し得る。

次に図６を参照すると、新しいコンテキストはニュースヘッドラインコンポーネント２４１にパスし、そしてコンポーネント特有の機能性はＩＢＭに関連したニュース事象を示すディスプレイペイン５２０を更新するために新しいコンテキストに応じて引き出される。

次に、図７及び図８を参照すると、ＣＣＦ作動コンポーネント及びコンテナを用いてサポートされ得るユーザー機能性を例示する別の例が示されている。図７において、ＣＣＦ作動コンポーネント２４０はユーザーの選択した発行者に関連した評定を表示するように構成される。ユーザーがコンポーネント２４０内のドロップ・ダウン・ユーザーインターフェースコントロールから発行者名称（例えばＧｅｎｒａｌ Ｍｏｔｏｒｓ）を入力又は選択すると、コンポーネント２４０は、関連した評定データを検索し、ディスプレイペイン７３０にそれを表示する。コンポーネント２４０の基本機能性は、コンポーネント２４０に対して全体として内部にあり、そしてコンテナ２２０と相互作用することなしに生じ得る。しかし、コンポーネント２４０で行われる基本機能性及びユーザーインターフェースコントロールに加えて、マイクロソフトエクセルアイコン７２０で顧客対応した標準のツールバー７１０もコンポーネント２４０内に組み込まれる。エクセルアイコン７２０は、ＣＣＦ作動コンポーネント２４０がコンポーネントディスプレイペイン７３０からエクセルスプレッドシートへのデータの移出をサポートすることを指示している。この例では、コンポーネント２４０は、オンロード事象でコンテナ２２０に伝送した記述においてこの情報（及び可能ならばアイコン７２０自体）をパスすることによってエクセルアイコン７２０がツールバー７１０に表示されることになることをコンテナ２２０に指示し得る。

ユーザーがディスプレイペイン７３０において評定データでアイコン７２０をクリックする時、新しいマイクロソフトエクセルアプリケーションウインドウ２４１は、図８に示すように、具体化されてユーザーに表示される。この例では、ユーザークリックを検知した後、コンテナ２２０は、エクセルアイコン７２０がクリックされたことを表すオンコマンド事象をコンポーネント２４０へ伝送し得る。この事象を受信した後、コンポーネント２４０は、ディスプレイペイン７３０における評定データに相応したエクセルワークシートを検索するために遠隔データサーバに要求を伝送し得、そして既存のＩＥ機能性を用いて新しいポップアップウインドウ２４１におけるワークシートでエクセルのインスタンスをスタートし得る。従って、この例では、コンテナ２２０は、ツールバー項目又はメニューオプションの選択をコンポーネント２４０へ簡単に通知して、コンポーネントにいかなる別のコンテナ・コンポーネント通信なしに選択を処理させ得る。当然、他のコンポーネント・コンテナ構成において、二つの間の通信はデータ検索や提示などのための種々の技法をサポートし続け得る。例えば、ＣＣＦ通信を用いて、コンテナ・コンポーネントは、コンテナ内の新しいコンポーネントの創作とコーディネートし、そして遠隔サーバから検索したデータ又は直接コンポーネントディスプレイペイン７３０におけるデータで新しいコンポーネントを生成し得る。

さらに、コンテナ２２０は新しいコンポーネントを作り、そしてそれらの間の直接コンポーネント対コンポーネント通信をセットアップし得る。例えば、コンポーネントは、オンポップアップ又はオンコンポーネントドラッグスタート事象で伝送した永続データの一部と同じコンテナ内でランする別のコンポーネントに任意のデータをパスし得る。他の構成では、一つのコンポーネントは別のコンポーネントを含み得、二つはＣＣＦインターフェースを拡張してそれら自体のプライベートデータフォーマットに対する事象を提供するように相互に一致し得る。

図７及び図８に示すエクセル機能性への移行に加えて、ＣＣＦ作動コンポーネント及びコンテナは幾つかの異なるユーザー相互作用特徴をサポートできる。これらの潜在的な特徴の幾つかを挙げている表は以下に含まれる。

次に図９を参照すると、維持し通信する特性値に関連した、ＣＣＦコンテナ２２０内でランするＣＣＦ作動コンポーネント２４０とのユーザー相互作用の別の変形例が示されている。上述のように、コンポーネント２４０は特性情報をそれのコンテナ２２０へ及びその逆に供給し得、コンポーネント２４０でサポートしたユーザー機能性に基いてコンテナ２２０にタイトルバー９１０、ツールバー９２０及びメニュー９３０を顧客対応させることができる。当然、特性名称、値、タイプ及びコンポーネント２４０でサポートした特性のアクセス許可は特有のコンポーネント２４０に関連し得る。しかし、ある特定の実施形態では、コンポーネント２４０は特性の予定の最少セットを維持するように要求され得る。図９において、例えばコンポーネント２４０はルータの３０００Ｘｔｒａコンテナ２２０内でランし、そして少なくとも三つの特性をコンテナ２２０に露呈するように要求される。第１の、“タイトル”特性は、コンテナ２２０がタイトルバー９１０においてラベルを設定するのに用いる読取り専用のストリング（文字列）値である（すなわちコンポーネント２４０自体で単に設定され得る）。この例では、コンポーネント２４０は“発行情報”のタイトルを設定し、従ってコンテナ２２０に値を検索させそしてタイトルバー９１０を更新させ得る。第２の特性“ヘルプＵＲＬ”は、コンポーネント２４０で設定されそしてコンテナ２２０で検索される別の読取り専用特性である。ヘルプＵＲＬ特性は非ＮＵＬＬ値をもつ場合には、コンテナ２２０は、コンポーネント２４０に設けたヘルプコンテンツにユーザーをリダイレクトする、設けたＵＲＬに対して結合し得る（例えばツールバー９２０におけるヘルプボタン又はヘルプメニュー項目のような）。従って、コンポーネント・特殊ユーザーヘルプはコンテナ２２０のメニュー及びツールバー内に設けられ得る。この例における第３の要求された特性は、論理“セレクタビジュアル”特性である。セレクタビジュアル特性は、コンテナメニュー９３０におけるショウコンポーネント処理項目９４０のユーザー選択に応じてコンテナ２２０によって設定される。この特性がＴＲＵＥに設定される時、コンポーネント２４０はその処理を露呈し、コンポーネント２４０がドラッグするために利用できる場合に、コンテナ２２０内のコンポーネント２４０を選択及びドラッグさせ得る。従って、ある特定の特性はコンテナ２２０によってか又はコンポーネント２４０によって或いはそれら両方によって設定され得て、コンテナ２２０のフレームワーク内でコンポーネント特有サポートを提供し、ユーザーには比較的継ぎ目のない論理的な経験をもたらす。

一つのアレンジメントでは、図３及び図４を参照して上記の技法と同様なコンポーネントソフトウエアオブジェクトとソフトウエアコンテナオブジェクトとの間の電子通信用の方法がサポートされる。この方法は、コンテナオブジェクト２２０において登録作用を開始すること、コンテナオブジェクト２２０内のコンポーネントオブジェクト２４０でサポートされた一般的なコンポーネント・インターフェースに相応した第１のインターフェースポインターを上記作用内に通すことを含む。本方法は、コンテナ２２０から、コンテナ（コンポーネントの誤りでは）２４０でサポートされた一般的なコンテ・ナインターフェースに相応した第２のインターフェースポインターを受信することを含み、第１及び第２のインターフェースは、コンポーネント２４０とコンテナ２２０との間の一般的な通信のための機能の予定のセットをサポートする。本方法はまた、コンポーネント２４０内でランするユーザーインターフェースコントロールにおいてユーザー入力を受信すること、受信したユーザー入力に関連したコンテナインターフェースによってサポートされた機能を決めること、及び第２のインターフェースポインターを用いてコンテナインターフェースにおける機能を呼び出すことを含む。ある特定の実施形態では、コンテナ２２０及び第１のコンポーネント２４０は、ブラウザ・アプリケーション２３０のインスタンス内で実行し得る。さらに、本方法は、第２のインターフェースを介してコンテナ２２０から、エンティティ識別子を含むコンポーネントコンテキストデータを受信することを含み得る。エンティティ識別子は会社、株券、債券、市場又は土地のような財務上のエンティティ（実体）と組み合わされ得る。さらに本方法は、コンテナ２２０からのコンポーネントコンテキストデータの受信に応じてコンポーネントコンテキストデータに基づく遠隔データ記憶部からデータを検索すること、検索したデータを用いてコンポーネント・特有の機能性を実行すること、及び実行したコンポーネント・特有の機能性に基きコンポーネント２４０のユーザーインターフェースを更新することを含み得る。

別のアレンジメントにおいて、図３及び図４を参照して上記の技法と同様な多数のコンポーネントソフトウエアオブジェクト２４０、２４１とコンテナソフトウエアオブジェクト２２０との間の電子通信用の第２の方法が提供される。この第２の方法は、コンテナ２２０から第１のコンポーネント２４０へ、第１のコンポーネント２４０に関してコンテナ２２０でサポートされた多数の機能を定義する第１のインターフェースポインターを送信すること、及びコンテナ２２０で第２のコンポーネントオブジェクトから、コンテナ２２０に関して第２のコンポーネント２４１でサポートされた多数の機能を定義する第２のインターフェースポインターを受信することを含む。本方法はさらに、第１のユーザー作用が第１のコンポーネント２４０内で生じていることを表し、コンポーネントコンテキストデータを含む指示を第１のインターフェースから受信すること、第２のコンポーネント２４１と関連した第２のユーザー作用を検知すること、及び第２のインターフェースを介してコンポーネントコンテキストデータを第２のコンポーネント２４１に送信することを含み得る。

第２の方法はまた、コンポーネントコンテキストデータが第２のコンポーネント２４１に適合できるかどうかを決めること、及びコンポーネントコンテキストデータが第２のコンポーネント２４１に適合できない場合に、第２のコンポーネント２４１を記述する記憶情報に基いてコンポーネントコンテキストデータを変換することを含み得る。ある特定の実施形態では、第１のユーザー作用は、会社、株券、債券、市場又は土地のような第１のコンポーネント２４０内のユーザーインターフェースからエンティティ（実体）の選択に相応し得る。第１のユーザー作用はまた、第１のコンポーネント２４０内のユーザーインターフェースにおけるエンティティと関連したドラッグ事象、或いは該エンティティに関連したドロップ事象に相応し得、ドロップ事象はユーザーインターフェースにおいて第２のコンポーネント２４１内で生じる。さらに、第１のユーザー作用は、第１のコンポーネット２４０のユーザーインターフェース内の一つ以上のデータフィールドを指定し得、また第２のユーザー作用は、第２のコンポーネント２４１のユーザーインターフェースへの指定したデータフィールドに対するドロップ事象に相応し得る。第１又は第２のユーザー作用はまた、スプレッドシートソフトウエアアプリケーションへ選択したデータフィールドを移行するユーザーコマンドに相応し得る。一つの実施形態では、コンテナ２２０及び第１のコンポーネント２４０はブラウザアプリケーション２３０のインスタンス内で実行し得る。

本明細書で説明した方法、モデル及びアーキテクチャの種々の特徴はコンピュータで読取り可能な命令の形態でコンピュータで読取り可能な媒体に記憶され得る。コンピュータで読取り可能な媒体のタイプは、磁気テープドライブ、光学記憶装置、フラッシュドライブ、ランダムアクセスメモリー（ＲＡＭ）、読取り専用メモリー（ＲＯＭ）などを含み得る。さらに、本明細書で説明した方法、モデル及びアーキテクチャの特徴はまたその他の産業及びアプリケーションでも用いられ得る。

本発明は好ましい例示の実施形態について説明してきた。本明細書の記載から特許請求の範囲の範囲及び精神の範囲内で多数の他の実施形態、変更及び変形が当業者によって行われる。

付 録
コンテキストデータ情報タイプは上記で詳細に説明しそして上記のコンテキストデータＸＳＤスキーマ・ファイルにおいて定義してきた。しかし、本明細書で記載したＣＣＦインターフェース及び他の特徴を用いたコンテナ・コンポーネント通信は、コンテナとコンポーネントとの間のコンテキストデータをパスすることに限定されない。多くの他の情報タイプも通信され得、またかかるタイプの幾つかの例は以下に記載し、この付録においてはＸＳＤとして記載する。例えば、以下の特性ＸＳＤファイルは、特性についてのコンテナ２２０の要求に応じてコンポーネント２４０によって作られコンテナ２２０に伝送されるＸＭＬインスタンスに相応する“特性”情報タイプについてのスキーマを定義している。

以下の探索目標ＸＳＤファイルは、探索エンジンに対する引き数（パラメタ）及び探索結果に加えられることになる変換を供給するために用いた“探索目標”情報タイプを定義する。探索目標データは、コンポーネント２２０に対する入力についての探索において、特定の探索エンジンの少なくとも一つをサポートするコンテナ２２０をアシストする。

以下の記述ＸＳＤファイルは、コンポーネント２４０でサポートした機能性にコンテナ２２０にアクセスさせ得るようにするためコンテナ２２０によって作られたＸＭＬインスタントについてのスキーマを定義する。

最後に、更新コマンドバーＸＳＤファイルは、コンポーネント２４０がコンテナ２２０において現在表示されているツールバー、サービスメニュー、及び／又はコンテキストメニューを更新又は変更する必要がある時に、コンテナ２２０に伝送される、コンポーネント２４０で作られたＸＭＬインスタンスについてのスキーマを定義する。ある特定の実施形態では、コンポーネントは単にコンテナ２２０におけるそれ自体のコンポーネント・特定のメニューを変更する許可を提供する。

Claims (23)

1. コンポーネントソフトウエアオブジェクトとソフトウエアコンテナオブジェクトとの間の電子通信のコンピュータ実行方法であって、
   コンテナオブジェクトにおいて登録作用を開始し、コンテナオブジェクト内のコンポーネントオブジェクトでサポートされた一般的なコンポーネント・インターフェースに相応した第１のインターフェースポインターを上記作用内に通すこと；
   コンテナオブジェクトから、コンテナオブジェクトでサポートされた一般的なコンテ・ナインターフェースに相応した第２のインターフェースポインターを受信し、第１及び第２のインターフェースが、コンポーネントとコンテナとの間の一般的な通信のための機能の予定のセットをサポートすること；
   コンポーネント内でランするユーザーインターフェースコントロールにおいてユーザー入力を受信すること；
   受信したユーザー入力に関連したコンテナインターフェースによってサポートされた機能を決めること；及び
   第２のインターフェースポインターを用いてコンテナインターフェースにおける機能を呼び出すこと
   を含むことを特徴する方法。
2. コンテナオブジェクト及び第１のコンポーネントが、ブラウザ・アプリケーションのインスタンス内で実行することを特徴とする請求項１記載の方法。
3. さらに、第２のインターフェースを介してコンテナオブジェクトから、エンティティ識別子を含むコンポーネントコンテキストデータを受信することを含むことを特徴とする請求項１記載の方法。
4. エンティティ識別子が、会社名、株券名、債券名、市場名及び土地名の一つに関連されることを特徴とする請求項３記載の方法。
5. さらに、コンテナオブジェクトからのコンポーネントコンテキストデータの受信に応じて、コンポーネントコンテキストデータに基いて遠隔データ記憶部からデータを検索すること；
   検索したデータを用いてコンポーネント・特有の機能性を実行すること；及び
   実行したコンポーネント・特有の機能性に基きコンポーネントオブジェクトのユーザーインターフェースを更新すること
   を含むことを特徴とする請求項３記載の方法。
6. コンポーネントソフトウエアオブジェクトとコンテナソフトウエアオブジェクトとの間の電子通信のコンピュータ実行方法であって、
   コンテナから第１のコンポーネントオブジェクトへ、第１のコンポーネントに関してコンテナでサポートされた多数の機能を定義する第１のインターフェースポインターを送信すること；
   コンテナで第２のコンポーネントオブジェクトから、コンテナに関して第２のコンポーネントでサポートされた多数の機能を定義する第２のインターフェースポインターを受信すること；
   第１のユーザー作用が第１のコンポーネント内で生じていることを表し、コンポーネントコンテキストデータを含む指示を第１のインターフェースを介して受信すること；
   第２のコンポーネントと関連した第２のユーザー作用を検知すること；及び
   第２のインターフェースを介してコンポーネントコンテキストデータを第２のコンポーネントに送信すること
   を含むことを特徴とする方法。
7. コンポーネントコンテキストデータが第２のコンポーネントに適合できるかどうかを決めること；及び
   コンポーネントコンテキストデータが第２のコンポーネントに適合できない場合に、第２のコンポーネントを記述する記憶情報に基いて上記コンポーネントコンテキストデータを変換すること
   を含むことを特徴とする請求項６記載の方法。
8. 第１のユーザー作用が、第１のコンポーネント内のユーザーインターフェースからのエンティティの選択から成ることを特徴とする請求項６記載の方法。
9. 選択したエンティティが、会社名、株券名、債券名、市場名及び土地名の一つから成ることを特徴とする請求項８記載の方法。
10. 第１のユーザー作用が、第１のコンポーネント内のユーザーインターフェースにおけるエンティティと関連したドラッグ事象から成ることを特徴とする請求項６記載の方法。
11. 第２のユーザー作用が、エンティティに関連したドロップ事象から成り、ドロップ事象が第２のコンポーネント内でユーザーインターフェースにおいて生じることを特徴とする請求項１０記載の方法。
12. 第１のユーザー作用が、第１のコンポーネットのユーザーインターフェース内の一つ以上のデータフィールドを指定し、また第２のユーザー作用が、第２のコンポーネントのユーザーインターフェースへの指定したデータフィールドに対するドロップ事象から成ることを特徴とする請求項６記載の方法。
13. 第１及び第２のユーザー作用の一方が、スプレッドシートソフトウエアアプリケーションへ選択したデータフィールドを移行するユーザーコマンドから成ることを特徴とする請求項６記載の方法。
14. コンテナ、第１のコンポーネント及び第２のコンポーネントがブラウザアプリケーションのインスタンス内で実行することを特徴とする請求項６記載の方法。
15. コンピュータシステムにおいて実行した際に、
    第１のコンポーネントオブジェクトへ、第１のコンポーネントに関してサポートされた多数の機能を定義する第１のインターフェースポインターを送信すること；
    第２のコンポーネントオブジェクトから、第２のコンポーネントでサポートされた多数の機能を定義する第２のインターフェースポインターを受信すること；
    第１のユーザー作用が第１のコンポーネント内で生じていることを表し、コンポーネントコンテキストデータを含む指示を第１のインターフェースを介して受信すること；
    第２のコンポーネントと関連した第２のユーザー作用を検知すること；及び
    第２のインターフェースを介してコンポーネントコンテキストデータを第２のコンポーネントに送信すること
    を含む方法を実行するコンピュータ実施可能な命令を記憶する一つ以上のコンピュータで読取り可能な媒体。
16. 方法はさらに、
    コンポーネントコンテキストデータが第２のコンポーネントに適合できるかどうかを決めること；及び
    コンポーネントコンテキストデータが第２のコンポーネントに適合できない場合に、第２のコンポーネントを記述する記憶情報に基いて上記コンポーネントコンテキストデータを変換すること
    を含むことを特徴とする請求項１５記載のコンピュータで読取り可能な媒体。
17. 第１のユーザー作用が、第１のコンポーネント内のユーザーインターフェースからのエンティティの選択から成ることを特徴とする請求項１５記載のコンピュータで読取り可能な媒体。
18. 選択したエンティティが、会社、株券、債券、市場及び土地の一つから成ることを特徴とする請求項１７記載のコンピュータで読取り可能な媒体。
19. 第１のユーザー作用が、第１のコンポーネント内のユーザーインターフェースにおけるエンティティと関連したドラッグ事象から成ることを特徴とする請求項１５記載のコンピュータで読取り可能な媒体。
20. 第２のユーザー作用が、エンティティに関連したドロップ事象から成り、ドロップ事象が第２のコンポーネント内でユーザーインターフェースにおいて生じることを特徴とする請求項１９記載のコンピュータで読取り可能な媒体。
21. 第１のユーザー作用が、第１のコンポーネットのユーザーインターフェース内の一つ以上のデータフィールドを指定し、また第２のユーザー作用が、第２のコンポーネントのユーザーインターフェースへの指定したデータフィールドに対するドロップ事象から成ることを特徴とする請求項１５記載のコンピュータで読取り可能な媒体。
22. 第１及び第２のユーザー作用の一方が、スプレッドシートソフトウエアアプリケーションへ選択したデータフィールドを移行するユーザーコマンドから成ることを特徴とする請求項１５記載のコンピュータで読取り可能な媒体。
23. ブラウザアプリケーションのインスタンス内で方法が実行され、第１のコンポーネント及び第２のコンポーネントが同一インターネットブラウザアプリケーションのインスタンス内で実行することを特徴とする請求項１５記載のコンピュータで読取り可能な媒体。

Images