JP2016001502A - クライアント‐サーバ・ブリッジを使用したオブジェクト管理 - Google Patents

Abstract

【課題】クライアントとサーバとの間の通信をサポートする。
【解決手段】本方法は、クライアント（２０２）から第１のメッセージを受信するステップ（３０２、２１０）を含む。本方法は、第１のメッセージに応答してオブジェクトを作成するステップ（３１２）も含む。本方法は、第１のメッセージに対する応答をクライアントに送信するステップ（３２０、２１２）も含む。本方法は、サーバからオブジェクトに対する変更を受信するステップ（２２４、４０６）も含む。本方法は、オブジェクトに対する変更を記憶するステップ（４０８）も含む。本方法は、クライアントから第２のメッセージを受信するステップ（３０２、２１０、４１０）も含む。本方法は、記憶された変更を第２のメッセージに対する応答と共にクライアントに送信するステップ（３２０、２１２、４１４）も含む。
【選択図】 図７Ｂ

Description

（関連出願の相互参照）
本願は、２００９年１２月１４日に出願した米国仮出願第６１／２８６，２９３号の優先権を主張する。当該仮出願の内容を参照により本明細書に援用するものとする。

本明細書は、クライアント‐サーバ・ブリッジを使用したオブジェクト管理に関する。

いくつかのクライアント‐サーバ・システムは２つの動作方法のうちの１つを採用する。いくつかのシステムは「シン」・クライアントを有する。シン・クライアントは、サーバと独立して動作を実行する能力が極めて低いベニヤをユーザに提供するインターフェース（例えばＨＴＭＬウェブページ）を提示する。いくつかのシステムは、クライアント・ハードウェアのリソース（例えばMicrosoft（登録商標） Foundation Classに基づくユーザ・インターフェース）を利用して複雑な動作を実行することが可能なインターフェースを提供する「ファット」クライアントを有する。いくつかの「ファット」・クライアントはサーバ・アプリケーションと同じ又は同様のプログラミング言語で記述され、したがってクライアントとバックエンド・サーバとを緊密に結合することができる（例えばJava（登録商標） RMI又はMicrosoft社のＣＯＭ＋技術）。

一態様では一般に、クライアントとサーバとの間の通信をサポートする方法は、クライアントから第１のメッセージを受信するステップを含む。本方法は、第１のメッセージに応答してオブジェクトを作成するステップも含む。本方法は、第１のメッセージに対する応答をクライアントに送信するステップも含む。本方法は、サーバからオブジェクトに対する変更を受信するステップも含む。本方法は、オブジェクトに対する変更を記憶するステップも含む。本方法は、クライアントから第２のメッセージを受信するステップも含む。本方法は、記憶された変更を第２のメッセージに対する応答と共にクライアントに送信するステップも含む。

各態様は以下の特徴のうちの１つ又は複数を含む可能性がある。

変更を記憶するステップは、変更ログを作成するステップを含むことができ、記憶された変更をクライアントに送信するステップは、変更ログを送信するステップを含むことができる。変更を記憶するステップは、オブジェクトの現在の状態を更新するステップを含むことができ、記憶された変更を送信するステップは、オブジェクトの現在の状態を送信するステップを含むことができる。クライアントから第１のメッセージを受信するステップは、クライアント・オブジェクト用の一時識別子を受信するステップを含むことができ、オブジェクトを作成するステップは、オブジェクト用の永続識別子を取得するステップを含み、第１のメッセージに対する応答を送信するステップは、一時識別子と永続識別子との間のマッピングを送信するステップを含む。永続識別子を取得するステップは、サーバにサーバ・メッセージを送信するステップを含むことができる。サーバ・メッセージを送信するステップは、サーバ・メッセージを他のサーバ・メッセージでインターリーブするステップを含むことができる。

本方法は、オブジェクトへの関連（interest）をサーバに登録するステップも含むことができる。オブジェクトに対する変更を受信するステップは、サーバによって生成されたイベントに関連するオブジェクトに対する変更を受信するステップを含むことができる。第１のメッセージを受信するステップは、第１のプロトコルを利用するステップを含むことができ、変更を受信するステップは、第１のプロトコルと異なる第２のプロトコルを利用するステップを含む。本方法は、複数のクライアントのために複数のオブジェクトに関する変更を記憶するステップも含むことができる。

オブジェクトは、データフロー・グラフの各種コンポーネントを表す複数のノードと、コンポーネント間のデータの流れを表すノード間のリンクとを含むデータフロー・グラフの一部に対応させてもよい。クライアントから第１のメッセージを受信するステップは、データフロー・グラフのコンポーネントの少なくとも１つの特徴を定義するパラメータの値を受信するステップを含むことができる。本方法は、データフロー・グラフのコンポーネントの特徴をそれぞれ定義する１つ又は複数のパラメータを受信するインターフェースを提供するステップを含むことができる。インターフェースは複数のユーザ・インターフェース要素を表示することができ、ユーザ・インターフェース要素間の関係はデータフロー・グラフのコンポーネント間の依存度に基づくようにしてもよい。これらの関係はサーバ上に記憶された仕様（specification）によって定義可能である。

第１のメッセージを受信するステップは、中間データの要求を受信するステップを含むことができ、オブジェクトを作成するステップは、データフロー・グラフの一部をコンパイルするステップと、データフロー・グラフのコンパイルされた一部を実行することによって出力データセットに対する出力を生成するステップとを含むことができる。オブジェクトを作成するステップは、中間データの生成に必要な第１のコンポーネントセットを判定するステップと、第１のコンポーネントセットに含まれない、データフロー・グラフ内のコンポーネントを無効にするステップと、出力データセットを格納するためにデータフロー・グラフに結合される中間データ・シンクを作成するステップとを含むことができる。第１のコンポーネントセットを判定するステップは、データ・ソースを中間データ・シンクに接続しないリンクを識別するステップを含むことができる。中間データ・シンクを作成するステップは、中間データ・シンクへのリンクが並列データフローを表すことを判定するステップと、中間データ・シンクとして並列データ・シンクを作成するステップとを含むことができる。

別の態様では一般に、コンピュータ可読媒体にクライアントとサーバとの間の通信をサポートするコンピュータ・プログラムが記憶される。コンピュータ・プログラムはコンピュータに、クライアントから第１のメッセージを受信させ、第１のメッセージに応答してオブジェクトを作成させ、第１のメッセージに対する応答をクライアントに送信させ、サーバからオブジェクトに対する変更を受信させ、オブジェクトに対する変更を記憶させ、変更を受信させた後に、クライアントから第２のメッセージを受信させ、記憶された変更を第２のメッセージに対する応答と共にクライアントに送信させる命令を含む。

別の態様では一般に、クライアントとサーバとの間の通信をサポートするシステムは、少なくとも１つのプロセッサを含むサーバと、該システム内のオブジェクトを管理するように構成された少なくとも１つのプロセッサを含むブリッジとを備える。管理は、クライアントから第１のメッセージを受信するステップと、第１のメッセージに応答してオブジェクトを作成するステップと、第１のメッセージに対する応答をクライアントに送信するステップと、サーバからオブジェクトに対する変更を受信するステップと、オブジェクトに対する変更を記憶するステップと、クライアントから第２のメッセージを受信するステップと、記憶された変更を第２のメッセージに対する応答と共にクライアントに送信するステップとを含む。

別の態様では一般に、クライアントとサーバとの間の通信をサポートするシステムは、データ供給手段と、システム内のオブジェクトを管理する手段とを備える。前記管理は、クライアントから第１のメッセージを受信するステップと、第１のメッセージに応答してオブジェクトを作成するステップと、第１のメッセージに対する応答をクライアントに送信するステップと、データ供給手段からオブジェクトに対する変更を受信するステップと、オブジェクトに対する変更を記憶するステップと、クライアントから第２のメッセージを受信するステップと、記憶された変更を第２のメッセージに対する応答と共にクライアントに送信するステップとを含む。

各態様は以下の特徴のうちの１つ又は複数を含む可能性がある。クライアントとサーバとの間の通信を単純化することができること。ロバスト・クライアント向けに開発したサーバを、スクリプティング・クライアントをサポートするように適合することができる。ブリッジとクライアントとの間の連続した接続を必ずしも維持する必要なく、オブジェクトに対する変更を追跡し、クライアントを更新することができる。

以下の説明及び添付の特許請求の範囲を読めば、本発明の他の特徴及び利点が明らかとなるであろう。

ブリッジ接続型クライアント・サーバ・システムの概略図である。 クライアント、ブリッジ、サーバ間の例示的な通信パターンの概略図である。 システムによって実行される例示的な動作のフローチャートである。 システムによって実行される例示的な動作のフローチャートである。 システムによって実行される例示的な動作のフローチャートである。 例示的なデータフロー・グラフの図である。 データフロー・グラフをカスタマイズするインターフェース部分を示す図である。 データフロー・グラフをカスタマイズするインターフェース部分を示す図である。 インターフェース内の例示的な結果表示を示す図である。 例示的なデータフロー・グラフの図である。 ブリッジ接続型クライアント・サーバ・システムの概略図である。

ブラウザを利用して典型的なシン・クライアントで利用可能な機能よりも多くの機能をクライアント・システムで利用することを可能にするツールがいくつか存在する。これらのツールの中には、サーバ・アプリケーションの作成に使用する言語と異なるプログラミング言語で構築されるものもある。異なる技術を使用して構築されたクライアントとサーバとの間の通信を円滑にするために、クライアント・システムとサーバ・システムとの間に、図１に示すような「ブリッジ」通信レイヤが確立される。クライアント１０２ａ、１０２ｂ、１０２ｃは、それぞれサーバ１０４側で実行中の対応するサーバ・セッション１１６ａ、１１６ｂ、１１６ｃとブリッジ１１０を介して通信している。クライアント１０２ａ、１０２ｂ、１０２ｃからブリッジ１１０に送られたメッセージはメッセージ・プロセッサ１０８に送信され、メッセージ・プロセッサ１０８はクライアント１０２ａ、１０２ｂ、１０２ｃのステートレス・プロトコル、例えばハイパーテキスト・トランスポート・プロトコル（ＨＴＴＰ）をサーバ１０４から提供されるプロトコル・コレクションに翻訳する。いくつかの構成では、コード生成を使用して転換を自動化することができる。いくつかの構成において、各クライアント、ブリッジ１１０及びサーバ１０４は、それぞれ別個のプロセッサ又はコンピュータ・システム上で実行され、ネットワークを介して通信する。クライアント１０２ａ、１０２ｂ、１０２ｃはブリッジ１１０を利用してサーバ１０４との通信を行うシン・クライアントであってよく、サーバ１０４と直接通信することが可能な他のファット・クライアント（図示せず）が存在してもよい。

一般には、ブリッジ１１２を介して単一のクライアント１０２ａが単一のクライアント・セッション１１４ａに接続される。ブリッジは同時に複数のクライアントと対話することもできる。また、単一のクライアント・セッション１１４ａが単一のサーバ・セッション１１６ａに接続される。メッセージ・プロセッサ１０８は、クライアントからのメッセージに対するサーバからの応答を含めた交換情報をパッケージ化する応答オブジェクトを作成し、応答オブジェクトを適切なクライアント１０２ａ、１０２ｂ、１０２ｃに送信する。しかしながら、いくつかの例では他の構成を使用することもできる。例えば、ブリッジ１１０又はサーバ１０４との間の通信をロード・バランサによってロード・バランシングしてパフォーマンスを改善することもできる。

矢印１２０ａ、１２０ｂ、１２０ｃで示したように、クライアント１０２ａ、１０２ｂ、１０２ｃとブリッジ１１０との間の通信は要求と応答を含む可能性がある。クライアント１２０ａ、１０２ｂ、１０２ｃはブリッジ１１０に対して要求を行い応答を待つことができる。ブリッジ１１０は、クライアント１０２ａ、１０２ｂ、１０２ｃに関するクライアント・セッション１１４ａ、１１４ｂ、１１４ｃを作成しても、セッションが既に存在する場合は既存のセッションを使用してもよい。ブリッジ１１０は、入力メッセージをサーバ１０４によって理解されるプロトコルに翻訳する。ブリッジ１１０とサーバ１０４との間では、リモート・プロシージャ・コール（ＲＰＣ）、データ（例えば「バイト・ストリーム」や「オブジェクト・ストリーム」）及びイベント（例えば一方向メッセージ）を含めた様々なタイプのメッセージがメッセージ・ストリーム１２４ａ、１２４ｂ、１２４ｃの形で送信され得る。

ＲＰＣの動作は一般に要求の送信と応答の受信である。この基本パターンには以下の３つのバリエーションがある。暗黙的な完了又は失敗通知なしに応答があるまで待機する又は応答をポーリングするプロセス・スレッドによって特徴付けられる「スタンド・アロン」ＲＰＣ；成功又は失敗を示す応答が受信されるまでブロッキングを行うプロセス・スレッドによって特徴付けられる「同期」ＲＰＣ；及び手続きが完了したときにトリガされるコールバックを登録することによって特徴付けられる「非同期」ＲＰＣである。いくつかの例において、特定のスレッドによって作成されるＲＰＣは、それらの呼び出し順に実行されることが保証される。

ブリッジ１１０とサーバ１０４との間の通信は、ＲＰＣを含むメッセージ・ストリームをインターリーブすることを可能にする。複数の異なるＲＰＣメッセージング・ストリームを同時に処理し、メッセージが互いにオーバーラップしてブリッジに到着するようにしてもよい。ブリッジ１１０は各メッセージを個別に受け入れ処理する。ブリッジ１１０はキャンセル又は中止（abort）メッセージの送信も可能にする。中止メッセージを受信した場合、ブリッジ１１０は現在実行中の手順を終了する、又は現在実行中の手続きを終了するようサーバ１０４に通知する。

ブリッジ１１０及びサーバ１０４は、データ・ストリームを使用して通信することができる。データ・ストリームは、ウィンドウ・プロトコルを利用して一時に送信可能なデータ量を制限する論理的なバイト・ストリームである。データ・ストリームは、ブリッジ１１０とサーバ１０４との間でＲＰＣ要求もしくは応答メッセージ、平文メッセージ又は経過メッセージの一部として受け渡し可能である。データ・ストリームがブリッジ又はサーバに受け渡されると、ストリーム・オブジェクトと共にフロー制御パラメータを受信した接続側のストリームを識別するハンドシェイク手続きにより、データ・ストリームが確立される。ストリーム上で伝送されるデータの量は、サーバ１０４又はブリッジ１１０によって規定される制約に基づいて制限することができる。

図２を参照すると、いくつかの構成において、クライアント２０２は、サーバ１０４上で実行しサーバ１０４上に記憶することが可能なプロセス及び情報の表現（representation）を維持することができる。クライアント２０２は、サーバ１０４上のプロセス及び情報に生じた変化に気付くことができる。矢印２１０、２１２で示したように、クライアント２０２はブリッジ１１０と通信することができる。いくつかの構成において、この通信は、クライアント２０２上に記憶されているデータの表現との間のプログラム的な相互作用によって発生する可能性がある。要求を受信したブリッジ１１０は、プロセス矢印２１４、２１６で示したようにサーバ１０４と通信することができる。上述のとおり、ブリッジ１１０とサーバ１０４との間の通信では、クライアント２０２とブリッジ１０４との間の通信よりも強固なプロトコル・セットが利用可能である。矢印２２４で示したように、メッセージが現在処理中でないとき、サーバ１０４は基礎となるオブジェクトに対する変更をブリッジ１１０に通知することができる。例えば、ブリッジ１１０は所与のオブジェクトへの関連（interest）を登録することができ、サーバ１０４はオブジェクトの改変時期又はアクセス時期をブリッジ１１０に通知することができる。いくつかの構成では、クライアント２０２とブリッジ１１０との間のステートレス性の通信により、ブリッジ１１０がクライアント２０２に直ちに変更を通信することが防止される。このような状況では、情報をブリッジ１１０上に記憶し、後続の要求に対する応答の一部としてクライアント２０２に配信することができる。他の構成では、クライアントとサーバとの間で継続的な更新を可能にするデータ・ストリームを確立することができる。

いくつかの構成において、クライアント２０２は、サーバ１０４上に存在しない情報の表現を作成すること、例えば新しい顧客オブジェクトを作成することができる。新たに作成されるこの情報には一時識別子を付与することができる。その後、クライアント２０２は新しい情報を用いていくつかのアクションを実行することができる。いくつかの構成において、クライアント２０２は、サーバからアクセスされる新しい情報と既存の情報を共に利用する動作を実行することができ、一時識別子を使用して既存の情報を更新することもある。クライアント２０２は、サーバ１０４に対して通知を行う前に、この情報を使用して様々な動作を実行することができる。最終的に、クライアント２０２は、サーバ１０４上で動作を実行するよう要求する１つ又は複数の要求をブリッジ１１０に送信することができる。ブリッジ１１０は、サーバ１０４上に存在しない新しい情報を特定する。これにより、ブリッジはサーバ上の情報を表すレコードを作成することができ、永続識別子を取得することができる。次いで、ブリッジ１１０は、メッセージに関して提供される一時識別子と永続識別子との間の調停を行う。応答の一部として、ブリッジ１１０は、一時識別子と永続識別子との間のマッピングをクライアント２０２に提供する。

ブリッジ１１０上では、メッセージ・プロセッサ１０８によって管理されるメッセージ・サービスが入力メッセージを受信する。いくつかの構成において、メッセージは、複数のオブジェクトを使用して実行可能な複数の動作を特定することができる。既存のオブジェクトもあれば新しいオブジェクトもある。一般には、すべてのオブジェクトが識別子を使用して識別される。既存のオブジェクトは永続識別子を使用して識別され、新たに作成されるオブジェクトは一時識別子を使用して識別される。メッセージ・サービスはどの動作を実行する必要があるかを識別する。

ブリッジ１１０上のオブジェクト・サービスは、どのオブジェクトが既にサーバ１０４上に存在するかを識別し検索する。新しい情報に関しては、サーバ１０４にデータが追加され、永続識別子が割り当てられ、オブジェクト・サービスから永続識別子と一時識別子との間のマッピングが提供される。

図３を参照すると、フローチャート３００は、ブリッジ１１０によって実行される動作の例示的な構成を示す。典型的には、各動作はブリッジが存在するコンピュータ・システムの１つ又は複数のプロセッサによって実行される。動作は典型的には単一の電子デバイスによって実行されるが、いくつかの構成では、動作の実行を２つ以上の電子デバイス（例えばコンピュータ・システム）に分散させてもよい。

動作は、参照を有するメッセージを受信するステップ３０２を含む。参照は、メモリに記憶されるオブジェクトを指すポインタであっても、例えばオブジェクトの位置を特定する識別子を指すポインタであってもよい。メッセージは複数のオブジェクトを参照可能である。参照は別個のリストの形で提供することも、メッセージ内部でネスト化させることもできる。

動作は、オブジェクトが存在するかどうかを判定するチェック・ステップ３０４も含む。場合によっては、ブリッジは、オブジェクトが存在するかどうかを確認するメッセージをサーバに送信することができる。他の場合では、動作３０４と他の動作を組み合わせてもよい。例えば、ブリッジは、サーバ３０６からのオブジェクトのフェッチを試行する動作を実行することができる。特定の識別子を使用して新しいオブジェクトを識別することもできる。例えば、メッセージに関する特定の範囲のキー、特定のキー・プレフィックス又は別のフィールドを用いてそのオブジェクトが新しいことを示すことができる。ブリッジは、各オブジェクトがメッセージによって参照されるたびに上記の動作を複数回実行してもよい。

動作は、オブジェクトをフェッチするステップ３０６も含む。場合によっては、ブリッジはサーバからのメッセージ内で識別されるオブジェクトをフェッチすることができる。他の場合では、ブリッジはローカル・ストレージ内のオブジェクトのローカル・コピーをキャッシュすることができる。サーバにメッセージを送信する前に、ブリッジはそれ自体のローカル・ストレージをチェックしてオブジェクトの有無を確認し、オブジェクトが発見された場合はクライアントに直接応答を返す。上述のとおり、オブジェクトのローカル・コピーは、バック・チャネル通信を介してサーバ上のコピーと同期状態を維持することができる。いくつかの実装環境では、ブリッジはいくつかのサーバと相互作用することができ、また、ルーティング・テーブルを使用してオブジェクトがどのサーバ上に位置するかを判定することができる。

動作は、何らかの更新が保留状態にあるかどうかを判定するチェック・ステップ３０８も含む。いくつかの構成において、ブリッジはオブジェクトのローカル・コピーに加えられた変更をキャッシュすることができる。これらの変更は特定のメモリ・ロケーション、テーブル又は他の記憶装置に記憶可能である。これらの変更はオブジェクト・タイプ及び一次キーに基づいて識別可能であり、オブジェクトはグローバル・ユニーク識別子に基づいて識別可能である。

動作は、更新を結果に追加するステップ３１０も含む。あるオブジェクトについて更新が保留状態にあることがブリッジによって識別されると、ブリッジはそれらの更新のリストをコンパイルし、それらをクライアントに配信すべき応答メッセージに添付することができる。

動作は、オブジェクトを作成するステップ３１２も含む。場合によってはオブジェクトが存在しないこともあり、その場合はブリッジが新しいオブジェクトを作成する。この処理は一般にサーバにメッセージを送信することによって達成される。新たに作成されるオブジェクトは一般に、クライアントによって使用される識別子と異なる新しい識別子を含む。

動作は、マッピングを作成するステップ３１４も含む。例えば、ブリッジは、クライアント識別子とオブジェクト作成時に提供される永続識別子とをペアにするマッピングを作成する。クライアントがマッピングに気付くと、クライアントはそれ自体の元の識別子の使用を停止し、その代わりに後続のすべての通信につき永続識別子を利用することができる。

動作は、マッピングを結果に追加するステップ３１６も含む。いくつかの構成では、クライアントにマッピングを通信するために、ブリッジはマッピングを応答メッセージに追加する。

動作は、メッセージを処理するステップ３１８も含む。ブリッジは、すべての必要なオブジェクトを同定しフェッチし作成した後に、要求されている動作を実行する。いくつかの実装環境において、この動作は１つ又は複数のメッセージをサーバに送信するステップを含むことができる。いくつかの実装環境において、ブリッジによってサポートされるメッセージはサーバによってサポートされるメッセージと同一である。この場合は、クライアントとサーバとの間のメッセージの翻訳をサポートするのに必要なプログラミングを自動的に生成してもよい。

動作は、結果をクライアントに送信するステップ３２０も含む。例えば、メッセージが処理されると、そのメッセージの結果が更新及びマッピングと組み合わされ、クライアントに返される。

図４を参照すると、フローチャート４００は、ブリッジ１１０によって実行される動作の他の例示的な構成を示す。典型的には、動作は、ブリッジが存在するコンピュータ・システムの１つ又は複数のプロセッサによって実行される。動作は典型的には単一の電子デバイスによって実行されるが、いくつかの構成では、動作の実行を２つ以上の電子デバイス（例えばコンピュータ・システム）に分散させてもよい。

動作は、クライアントから第１の要求を受信するステップ４０２を含む。クライアントから受信された要求により１つ又は複数のオブジェクトが作成され、又はサーバがそれらのオブジェクトにアクセスする可能性がある。これらのオブジェクトは、後のアクセスの性能を改善するためにブリッジ上にキャッシュしてもよい。

動作は、結果をクライアントに送信するステップ４０４も含む。場合によっては、要求に対する応答がクライアントに送信される。要求の処理中に作成又はアクセスされたオブジェクトをブリッジ上のローカル・データ・ストア、例えばメモリ又はデータベースに保持することもできる。いくつかの構成では、オブジェクトにアクセスすることを望むすべてのクライアントに共通する、オブジェクトの１つの共通コピーを記憶することもできる。他の構成では、各クライアントがブリッジ上に記憶される個々のコピーを有するように、オブジェクトをクライアント識別子と共に記憶することができる。他の構成では、クライアントがオブジェクトを修正しない限り共通のコピーがブリッジ上に記憶され、変更を含むオブジェクトの個々のバージョンがクライアントのために維持される。

動作は、オブジェクトに対する更新を受信するステップ４０６も含む。例えば、ブリッジはサーバからオブジェクトの更新を受信する可能性がある。更新は、データ・ストリーム又はイベントベース通信を介してサーバから送信することができる。

動作は、更新を記憶するステップ４０８も含む。いくつかの構成では、オブジェクトに関して受信された更新を特定のロケーションに記憶することができる。いくつかの構成において、変更は、変更されたフィールド及び値並びに変更発生時間を列挙した監査証跡（audit trail）として記憶することができる。他の構成において、変更は、ブリッジが変更の通知を受けた時期に基づいて追跡することができる。また他の構成では、単一の値しか変更されていない場合でも全体のオブジェクトが更新される可能性がある。動作は、やはりブリッジによって処理される任意の数の付加的な要求をクライアントから受信するステップも含むことができる。それらの要求の結果をクライアントに返す際は、オブジェクトに対する更新を含めてもよい。本例は、クライアントから第２の要求を受信するステップ４１０と、更新を結果に追加するステップ４１２とを含む。ブリッジは、サーバから受信された、サーバ上に記憶されているオブジェクトに対する変更を、クライアントに送信される応答メッセージに追加することができる。場合によっては、ブリッジは、クライアントのメッセージを処理した結果オブジェクトに対して発生した変更を追加することもできる。動作は、結果をクライアントに送信するステップ４１４も含む。

図５を参照すると、フローチャート５００は、ブリッジ１１０と相互作用するクライアント（図１では１０２ａ、１０２ｂ、１０２ｃ）によって実行される動作の例示的な構成を示す。典型的には、動作は、クライアントが存在するコンピュータ・システムの１つ又は複数のプロセッサによって実行される。動作は典型的には単一の電子デバイスによって実行されるが、いくつかの構成では、動作の実行を２つ以上の電子デバイス（例えばコンピュータ・システム）に分散させてもよい。

動作は、ブリッジにメッセージを送信するステップ５０２を含む。例えば、クライアントは、ブリッジに対してサーバ上に記憶されているオブジェクトに関するアクションを実行するよう要求するメッセージを送信することができる。

動作は、ブリッジから応答を受信するステップ５０４も含む。例えば、クライアントは、要求されたアクションを実行した結果を含む応答をブリッジから受信する。

動作は、マッピングをチェックするステップ５０６も含む。場合によっては、クライアントがブリッジから応答を受信したときに、クライアントは更新されたマッピングがメッセージに添付されているかどうかをチェックする。

更新されたマッピングが存在する場合、動作は、参照を更新するステップ５０８を含む。例えば、クライアントは、一時識別子で作成した新しいオブジェクトを更新し、オブジェクト作成時に割り当てられた一時識別子をサーバによって割り当てられた永続識別子に置き換える。

動作は、オブジェクト更新の有無をチェックするステップ５１０も含む。例えば、クライアントは応答をチェックして既存のオブジェクトがサーバ側で更新されたかどうかを確認する。更新された場合には、動作は、クライアント側でオブジェクトを更新するステップ５１２を含む。例えば、クライアントは、メッセージに含まれている変更を、クライアント側に現時点で記憶されているオブジェクトの任意のローカル・コピーに適用することができる。

動作は、結果を処理するステップ５１４も含む。例えば、サーバからの応答メッセージは、クライアントが結果に基づいて所定の措置をとることを可能にする情報をクライアントに伝達することができる。応答メッセージは、要求された動作が成功したのかそれとも失敗したのかを示すことができる。応答メッセージは、要求に関連するオブジェクト及び他の情報も含むことができる。例えば、特定の顧客オブジェクトに対するアクセス要求に対しては、応答時に顧客オブジェクトを返すことができる。

ブリッジを利用するシステムの一例は、非専門家ユーザがパラメータ化されたデータフロー・グラフを構成することを可能にするユーザ・インターフェースを生成するシステムである。データフロー・グラフは、１つ又は複数のデータ・ソースに由来するデータを処理するデータフロー・グラフ実行環境内で実行されるコンピュータ・プログラムである。データ・ソースに由来するデータはデータフロー・グラフに従って操作及び処理され、１つ又は複数のデータ・シンクにエクスポートされる。データ・ソース及びシンクとしては、例えばファイル、データベース、データ・ストリーム又はキューを挙げることができる。データフロー・グラフは、それぞれ少なくとも１つのデータ入力に由来するデータを処理し、少なくとも１つのデータ出力にデータを提供するコードを含むデータ処理コンポーネントを表すノードと、データ・ソース及び／又はシンクにアクセスするデータ・セット・オブジェクトを表すノードとを含む有向グラフとして表現される。これらのノードは、データ・ソースを起点としデータ・シンクを終点とする、コンポーネント間のデータの流れを表す有向リンクで接続される。上流のコンポーネントのデータ出力ポートが下流のコンポーネントのデータ入力ポートに接続される。データフロー・グラフは、データ・セット・オブジェクトによって表される異なるデータ・ソース及び異なるデータ・シンクに再生利用可能である。データフロー・グラフの実装に使用されるデータ構造及びプログラムコードは、例えば異なるソース及びシンクを容易に置き換え得るようにパラメータ化することにより、複数の異なる構成をサポートすることができる。さらに、いくつかの構成では、パラメータを利用することによりあるコンポーネント又は一連のコンポーネントを迂回することができるようにデータフロー・グラフの流れを改変することもできる。

実行環境は、ＵＮＩＸ（登録商標）オペレーティング・システムのような適切なオペレーティング・システムの制御下で、１つ又は複数の汎用コンピュータ上でホストすることができる。例えば、実行環境としては、複数の中央処理装置（ＣＰＵ）を、ローカル（例えばＳＭＰコンピュータのようなマルチ・プロセッサ・システム）もしくはローカル分散（例えばクラスタ又はＭＰＰとして結合された複数のプロセッサ）、又はリモートもしくはリモート分散（例えばローカル・エリア・ネットワーク（ＬＡＮ）及び／もしくはワイド・エリア・ネットワーク（ＷＡＮ）を介して結合された複数のプロセッサ）、又はこれらの任意の組み合わせにおいて使用するコンピュータ・システム構成を含めた複数ノード並列計算環境（multiple-node parallel computing environment）を挙げることができる。

データフロー・グラフの構成は、その性質上場合によっては高度に専門的であることもある。特定のビジネス目的を達成するために作成されるが、グラフの基本的な構造及び構成は技術的な考慮事項に基づいて決定される。例えば、グラフ・コンポーネントは、再利用性を最大化する又は並列処理をサポートするものが選択される可能性がある。一方、グラフの使用方法及び使用場所はビジネス決定に大きく左右される可能性がある。パラメータ化されたデータフロー・グラフに関連するいくつかのパラメータを使用して、ビジネス・ユーザは、データフロー・グラフの実装環境に隠された技術的な複雑さを理解する必要なく、データフロー・グラフをカスタマイズすることが可能となる。パラメータ化されたデータフロー・グラフは、カスタマイズを単純化し再利用を容易にする。

データフロー・グラフを構築するパラメータ値を識別するためのインターフェースをクライアント・マシン上に提示することができる。いくつかの実装環境において、クライアントは、パラメータ・インターフェースを提供するクライアント上のウェブ・ブラウザを使用して、また一定のクライアント・サイド処理能力を提供するスクリプト言語を使用して、サーバ上で実行中の開発環境にアクセスすることができる。スクリプト言語は、サーバと通信してパラメータを更新し、他の必要な動作を実行することができる。この通信はブリッジ・マシンを介して行うことができ、ブリッジ・マシンは、クライアントと、構築対象のグラフに関するオブジェクト及び関連パラメータ値が記憶される開発環境を実行するサーバとの間の通信を翻訳する。

例えば、図６Ａを参照すると、データフロー・グラフ６０２は、データ・ソース６０６ａ、６０６ｂ、コンポーネント６０８ａ〜６０８ｃ、６１０及びデータ・シンク６１２を含むことができる。各ソース、コンポーネント及びシンクはそれぞれ一組のパラメータ６０４ａ〜６０４ｇと関連付けることができる。あるソース、コンポーネント又はシンクのパラメータを使用して他のソース、コンポーネント又はシンクのパラメータを評価することができる。ソース６０６ａ、６０６ｂは、コンポーネント６０８ａ、６０８ｃの入力ポートに接続されている。コンポーネント６０８ａの出力ポートは、コンポーネント６０８ｂの入力ポートに接続されている。コンポーネント６１０の出力ポートはデータ・シンク６１２に接続されている。これらのソース、コンポーネント及びシンク間の接続によってデータフローが定義される。

いくつかのデータ・ソース、コンポーネント又はシンクは、グラフの挙動の一部を定義可能な入力パラメータ６０４ａ〜６０４ｇを有することができる。例えば、あるパラメータはデータ・ソース又はシンクの物理ディスク上のロケーションを定義することができる。また、あるパラメータは例えばコンポーネントの挙動を定義することができ、あるパラメータはソート・コンポーネントが入力をどのようにソートするか（例えば郵便番号でソート）を定義することができる。いくつかの構成では、あるパラメータの値を別のパラメータの値に依存させることができる。例えば、ソース６０６ａを特定のディレクトリ内のファイルに格納することができる。パラメータ・セット６０４ａは、「DIRECTORY」と称するパラメータと、「FILENAME」と称する別のパラメータとを含むことができる。この場合、FILENAMEパラメータはDIRECTORYパラメータに依存する（例えばDIRECTORYを「/usr/local/」とし、FILENAMEを「/usr/local/input.dat」とすることができる）。また、パラメータを他のコンポーネントのパラメータに依存させることもできる。例えば、シンク６１２の物理的位置をソース６０６ａの物理的位置に依存させることができる。本例では、シンク６１２は、ソース６０６ａのDIRECTORYパラメータに依存するFILENAMEパラメータが含まれる一組のパラメータ６０４ｇを含む（例えばセット６０４ｇ内のFILENAMEパラメータが「/usr/local/output.dat」であるとすると、値「/usr/local/」はセット６０４ａ内のDIRECTORYパラメータから取得可能となる）。

クライアント上のユーザ・インターフェース内では、パラメータ・セット６０４ａ〜６０４ｇの各パラメータを組み合わせ、技術的な考慮事項ではなくビジネス上の考慮事項が反映された、ユーザと相互作用する異なるグループに再編成することができる。ユーザ入力に基づいて各パラメータの値を受け取るユーザ・インターフェースは、パラメータ間の関係に従って、サーバ上の開発環境の諸側面に必ずしも制約されない柔軟な手法で様々なパラメータを表示することができる。例えば、図６Ｂを参照すると、アイコンがパラメータ間の依存度を表す関係と共に表示されるユーザ・インターフェースを提示することができる。本例では、パラメータは、第１のソース・データセットのパラメータを表す第１のソース・アイコン６２４と、第２のソース・データセットのパラメータを表す第２のソース・アイコン６２６と、シンク・データセットのパラメータを表すシンク・アイコン６３０と、構成対象のデータフロー・グラフの１つ又は複数のコンポーネントのパラメータを表し、それらとソース・データセット及びシンク・データセットとの関係を示す変換アイコン６２８とで表される第１のパラメータ群に分割される。このパラメータのグループ化は、ユーザがクライアント上のユーザ・インターフェース内でデータフロー・グラフのパラメータとどのように相互作用するか、及びアイコン６２４、６２６、６２８、６３０のようなユーザ・インターフェース要素同士をどのように相関付け、ユーザ・インターフェース内における提示のために配置するかを定義する格納済みの仕様６２２に基づいて行うことができる。いくつかの実装環境において、仕様はＸＭＬドキュメントである。仕様は、データフロー・グラフ・コンポーネントを識別することもでき、また、後で詳述するようにユーザがグラフを構成している間、例えばサンプル・データを閲覧している間にいくつかの機能を実行可能な特定のコンポーネントを識別することもできる。

場合によっては、仕様は、パラメータをどのように表示すべきかに関する命令を含むことができる。例えば、図６Ｂ及び図６Ｃを参照すると、仕様６２２は、ソース・データセットアイコン６２４との相互作用に応答して、あるパラメータはユーザが入力可能なテキスト・ボックス７０２として表示すべきであり、別のパラメータは事前に追加された値（例えば仕様において提供される値のリスト又はルックアップ・テーブルにおいて提供される値）を有するドロップ・ダウン・リスト７０４とすべきであり、また別のパラメータはラジオ・ボタン７０６として表示すべきこと等を示すことができる。したがって、仕様は、データフロー・グラフを、ビジネス・ユーザ及び／又は非専門家ユーザに合わせて調整可能となるようにカスタマイズするために、パラメータをどのようにユーザに提示すべきかに関して柔軟性をもたらす。例えば、ユーザ・インターフェースは、データベースに対して実行されるクエリ（例えばＳＱＬクエリ）に基づく値、又はファイル・システム上に位置するファイルに由来する値を入力することができる。場合によっては、仕様は、ユーザがアプリケーションに関するデータのソースを選択することを可能にすることができる。例えば、仕様は、ユーザがデータベース、テーブル又はファイルを選択することを可能にすることができる。１つ又は複数のパラメータをグループ単位で一緒に表示してもよい。例えば、仕様は、複数のパラメータをユーザ・インターフェース上のボックス内に一緒に提示すべきことを定めることができる。いくつかの実施態様では、ユーザ・インターフェースを列及び行に分割することができる。仕様は、パラメータを表示すべきユーザ・インターフェースのセクションに基づいて、パラメータ又はパラメータのコレクションの位置を識別することができる。

場合によっては、仕様は、ユーザがコンポーネントによって処理されるフィールドを選択するための能力を含むこともできる。利用可能なフィールドをユーザ・インターフェース内に表示することができ、ユーザはパラメータ・セットに含めるための１つ又は複数のフィールドを選択することができる。仕様は、ユーザが特定の（例えばステートが「FL」である）フィールドの値を選択することによってデータセットをフィルタリングすることを可能にすることができる。

場合によっては、仕様は、ビジネス・ユーザがパラメータ値を入力する順序を制約することもできる。点線で示したように、ユーザがいくつかの事前定義条件を満足するまでシンク６３０に関連するパラメータがユーザに見えないようにしてもよい。例えば、ユーザが特定のパラメータ値を提供するまで、又はパラメータ・セットを入力するまで、データ・シンク・パラメータ・セットがユーザに見えないようにしてもよい。必要に応じて、パラメータに値を割り当てなければならないことを示すパラメータを定義することもできる。

場合によっては、仕様はユーザの権限に基づいて異なるパラメータを提示することもできる。例えば、ユーザの権限が「管理者」でない限り、テンプレートは一群のテキスト入力コントロール及びリンクを隠蔽又は無効にすることができる。いくつか実装環境において、システムは、ユーザがユーザ・インターフェース内部からサーバ上のグラフの実行を開始することにより、パラメータ値によって構成されるとおりサンプル・データをグラフを介して実行し、サンプル実行の結果７０２をユーザ・インターフェースにおいてユーザに表示することを可能にすることができる（図７Ａ参照）。結果７０２は、どのようなタイプのデータが結果７０２に含まれるかに応じて、ユーザ・インターフェースの適切なブラウザ又はエディタで閲覧することができる。本例において、結果７０２は、サンプル・データ内のレコードに対応する行と、異なるフィールドのレコード内の値に対応する列とを含む。テストデータを使用したサーバ上のグラフの実行は、クライアントの様々なアクションのいずれかに応答して、例えばユーザがパラメータの値を供給したことに応答してトリガすることができる。

図７Ｂを参照すると、いくつかの実装環境において、システムはウォッチャーを追加することによりシステム内を流れるデータをキャプチャすることができる。例えば、データフロー・グラフ７１０は、データ・ソース７１２、７２６、コンポーネント７１４、７２０、７２８、７３０及びデータ・シンク７３２を含む。ユーザは、データフロー・グラフ内の任意のリンクにウォッチポイントを追加することができる。例えば、ユーザは、コンポーネント７２０とコンポーネント７３０との間のリンクにウォッチポイント７２２を追加することができる。システムは、ウォッチポイント７２２を検出しグラフの修正バージョンを生成して、コンポーネント７２０からのデータの流れを、ウォッチポイントに関するデータが格納される中間データ・シンク７２４にリダイレクトする。いくつかの実装環境において、ウォッチポイント７２２は、中間データ・シンク７２４及びデータ・コンポーネント７３０にデータを流すリプリケータとして実装される。

いくつかの実装環境において、システムは、コンポーネント７２８、７３０並びにデータ・ソース７２６及びデータ・シンク７３２がウォッチポイント７２２に関するデータを生成する必要がないことを判定する。システムはシステム・リソースを節約するために、これらの不必要なコンポーネントを無効にすることを選択することができる。さらに、不必要なコンポーネントを無効にすることにより、使用されていないコンポーネント（例えばコンポーネント７２８）の下流のコンポーネント（例えばコンポーネント７３０）について実装又は構成を完了させなくてもよくなるため、開発が単純化されるという付加的な利点がもたらされる可能性がある。これらのコンポーネントを無効にする際は、開発者がグラフ全体を完全に構成する必要なしにシステムがグラフの一部を実行することが可能となる。

いくつかの実装環境において、システムはウォッチポイントに関するデータを生成する必要がないリンクを識別する。例えば、システムは、任意のソース（例えばデータ・ソース７１２）を中間データ・シンク７２４に接続しないリンクを識別することができる。これらのリンクにデータを提供するコンポーネントを除外することができる。

いくつかの実装環境において、システムは、先行するウォッチポイントからのデータを利用して後続のウォッチポイントに関するデータを判定することができる。例えば、グラフの以前の実行時に、開発者がコンポーネント７１４とコンポーネント７２０との間のリンクにウォッチポイント７１６を追加したものとする。ウォッチポイント７１６に関するデータはデータ・シンク７１８に格納する。後続の実行時に、開発者は、データ・ソース７１２又はデータ・コンポーネント７１４を変更又は修正せずにウォッチポイント７２２を追加し、システムは、コンポーネント７２０のデータ・ソースとしてデータ・シンク７１８内のデータを使用することができ、その結果データ・ソース７１２及びコンポーネント７１４を無効にすることができる。

システムは、データフローが通常フローであるのかそれとも並列フローであるのかを検出することができる。並列フローとは、区画化されたデータフローである。並列フロー上のウォッチポイントは、データフロー毎に別々のデータ・シンクを使用する。例えば、６つの別々の区画に区画化された並列データフローは、６つの別々のデータ・シンクにおいてウォッチデータを生成する。

グラフは複数フェーズに分割することもできる。より前のフェーズのコンポーネントは、より後のフェーズのコンポーネントよりも早くすべての実行を完了させる。例えば、コンポーネント７３０がコンポーネント７２８よりも後のフェーズに存在するとすれば、コンポーネント７２８からのデータフローは、コンポーネント７２８がすべてのデータの処理を完了させるまでキャッシュされることになる。コンポーネント７２８がすべてのデータの処理を完了させると、コンポーネント７３０がデータの処理を開始する。いくつかのシナリオにおいて、データフロー・グラフ７１０は、他のコンポーネント、例えばルックアップ・テーブルに接続されていないコンポーネント７３４のようなコンポーネントを含む。非接続コンポーネントは、当該コンポーネントがウォッチポイントよりも後のフェーズに存在する場合はデータフロー・グラフから除外され、当該コンポーネントがウォッチポイントと同じ又はウォッチポイントよりも前のフェーズに存在する場合はデータフロー・グラフに追加される。

図８を参照すると、クライアント・システム８０２は、上述のユーザ・インターフェース８０４をユーザに表示することができる。ユーザ・インターフェース８０４を通じたユーザとの対話に基づいて生成されるパラメータ・セット８１４はサーバ８０８上に記憶することができる。この結果、ユーザ・インターフェース８０４によって加えられた変更がクライアント８０２からブリッジ８０６を介してサーバ８０８に送信される。矢印８２０で示したように、クライアント８０２は、あるフォーマットのメッセージ、例えば簡易オブジェクト・アクセス・プロトコル（ＳＯＡＰ）を使用して送られるメッセージをブリッジ８０６に送信する。ブリッジ８０６は、このメッセージを新しいフォーマットに翻訳し、必要に応じてサーバ８０８とのクライアント・セッションを開始する。矢印８２２で示したように、ブリッジ８０６は、サーバ８０８によって理解されるフォーマットのメッセージ、例えばＣＯＭ＋メッセージをサーバ８０８に送信する。サーバ８０８はメッセージを受信しパラメータ・セットを更新する。矢印８２４で示したように、サーバ８０８は、入力がクライアント８０２によって受信されたことに起因するパラメータ・セットの変更を含む応答を、ブリッジ８０６に送信する。ブリッジ８０６はこのメッセージを復号化し、クライアント８０２に関する応答メッセージを作成する。矢印８２６で示したように、ブリッジ８０６はクライアント８０２に応答メッセージを送信する。クライアント８０２は、上記の変更を反映するためにユーザ・インターフェース８０４の更新を行う。ユーザ・インターフェースの更新は、上述の前提条件の不成立によって以前に隠蔽されたコンポーネントがあればそれらのコンポーネントを表示すること含む。

ユーザは、完全であることも完全でないこともある現在のパラメータ・セットに基づくサンプル・データを使用して構築されるグラフを実行することを望んでいることをクライアント８０２に示すこともできる。上述のとおり、クライアント８０２はブリッジ８０６を介してサーバ８０８にメッセージを送信する。サーバ８０８は、変更があればそれらをパラメータ・セットに適用し、サーバ上で実行中のプロセス８１６がデータフロー・グラフをコンパイルする。サーバは、コンパイルされたデータフロー・グラフを実行し、サンプル・データセット８１０、８１２からのデータを受け入れる。実行されたデータフロー・グラフは、出力データセット８１８に対して要求された出力を生成する。データフロー・グラフの出力はクライアント８０２から要求されている中間データであって、必ずしもデータフロー・グラフの完全な実行によって生成されるデータとは限らない。

いくつかの実装環境において、サーバ８０８は、例えば定義済みのパラメータが完全なグラフのコンパイルを可能にするには不十分である場合、又はクライアント８０２がクライアント８０２によって構成されているデータフロー・グラフ内の特定のリンクに関する中間データを確認することを要求した場合は、データフロー・グラフのサブセットをコンパイルすることができる。コンパイル及び実行すべきデータフロー・グラフのサブセットを決定するために、サーバは、中間データ・シンクがウォッチポイントではなく構成対象のリンクに関して追加される、図７Ｂに関して上述したプロセスを使用することができる。

上述のとおり、結果データはサーバ８０８からブリッジ８０６を介してクライアント８０２に送信される。

上述のオブジェクト管理手法は、コンピュータ上で実行されるソフトウェアを使用して実施することができる。例えば、ソフトウェアは１つ又は複数のコンピュータ・プログラムの手続きを形成する。これらの手続きは、それぞれ少なくとも１つのプロセッサと、少なくとも１つのデータ記憶システム（揮発性及び不揮発メモリ並びに／又は記憶素子を含む）と、少なくとも１つの入力装置又はポートと、少なくとも１つの出力装置又はポートとを含む１つ又は複数のプログラムされた又はプログラム可能なコンピュータ・システム（分散アーキテクチャ、クライアント／サーバ・アーキテクチャ、グリッド・アーキテクチャのような様々なアーキテクチャであってよい）上で実行される。ソフトウェアは、例えば計算グラフの設計及び構成に関する他のサービスを提供する、より大きいプログラムの１つ又は複数のモジュールを形成することができる。グラフの各ノード及び要素は、コンピュータ可読媒体に記憶されるデータ構造として、又はデータリポジトリに格納されるデータモデルに適合する他の編成データとして実装可能である。

ソフトウェアは、汎用又は専用プログラマブル・コンピュータによって読み取り可能なＣＤ‐ＲＯＭのような記憶媒体上で提供されることも、ネットワークの通信媒体を経てそれ自体が実行されるコンピュータに配信（伝搬信号の形で符号化）されることもある。すべての機能を専用コンピュータ上で実行することも、コプロセッサのような専用ハードウェアを使用して実行することもできる。ソフトウェアは、ソフトウェアによって指定される異なる計算部分を異なるコンピュータが実行する分散形式で実装されることもある。このようなコンピュータ・プログラムは、記憶媒体又は記憶装置がコンピュータ・システムによって読み取られたときに本明細書に記載した手順を実行するようにコンピュータを構成及び操作するために、それぞれ汎用又は専用プログラマブル・コンピュータによって読み取り可能な記憶媒体又は記憶装置（例えば固体メモリもしくは固体メディア又は磁気メディアもしくは光学メディア）に記憶又はダウンロードされることが好ましい。本発明のシステムは、コンピュータ・プログラムによって構成される、コンピュータ読み取り可能な記憶媒体としても実装可能であり、このように構成した記憶媒体により、コンピュータ・システムを事前に定義された特定の形式で動作させ、本明細書に記載した機能を実行させるようにすることができる。

以上、本発明のいくつかの実施形態について説明してきたが、本発明の趣旨及び範囲から逸脱しない様々な修正形態が可能であることが理解されるであろう。例えば、上記で説明したステップの中には順序不同のものも存在する可能性があり、したがって本明細書に記載したのと異なる順序で実行することが可能である。

上記の説明は単なる例示であって本発明の範囲を限定するものではないことを理解されたい。本発明の範囲は、添付の特許請求の範囲によって定義されるものである。例えば、全体の処理に実質的に影響を及ぼさない限り、上記のいくつかの機能ステップを異なる順序で実行することも可能である。他の実施形態も特許請求の範囲に含まれる。

Claims (22)

1. クライアントとサーバとの間の通信をサポートする、ブリッジによって実行される方法であり、
   クライアントから第１のメッセージを受信するステップと、
   前記第１のメッセージに応答してオブジェクトを作成するステップと、
   前記第１のメッセージに対する応答を前記クライアントに送信するステップと、
   サーバから前記オブジェクトに対する変更を受信するステップと、
   前記オブジェクトに対する変更を記憶するステップと、
   前記変更を受信するステップに続いて、前記クライアントから第２のメッセージを受信するステップと、
   記憶された前記変更を前記第２のメッセージに対する応答と共に前記クライアントに送信するステップと
   を含む方法。
2. 変更を記憶する前記ステップは、変更ログを作成するステップを含み、記憶された前記変更を前記クライアントに送信する前記ステップは、前記変更ログを送信するステップを含む請求項１に記載の方法。
3. 前記変更を記憶するステップは、前記オブジェクトの現在の状態を更新するステップを含み、記憶された前記変更を前記クライアントに送信する前記ステップは、前記オブジェクトの前記現在の状態を送信するステップを含む請求項１に記載の方法。
4. 前記クライアントから第１のメッセージを受信する前記ステップは、クライアント・オブジェクト用の一時識別子を受信するステップを含み、前記オブジェクトを作成するステップは、前記オブジェクト用の永続識別子を取得するステップを含み、前記第１のメッセージに対する応答を送信する前記ステップは、前記一時識別子と前記永続識別子との間のマッピングを送信するステップを含む請求項１に記載の方法。
5. 前記永続識別子を取得するステップは、前記サーバにサーバ・メッセージを送信するステップを含む請求項４に記載の方法。
6. 前記サーバ・メッセージを送信するステップは、前記サーバ・メッセージを他のサーバ・メッセージでインターリーブするステップを含む請求項５に記載の方法。
7. 前記オブジェクトへの関連を前記サーバに登録するステップをさらに含む請求項１に記載の方法。
8. 前記オブジェクトに対する変更を受信するステップは、前記サーバによって生成されたイベントに関連する前記オブジェクトに対する変更を受信するステップを含む請求項７に記載の方法。
9. 前記第１のメッセージを受信するステップは、第１のプロトコルを利用するステップを含み、前記オブジェクトに対する変更を受信するステップは、前記第１のプロトコルと異なる第２のプロトコルを利用するステップを含む請求項１に記載の方法。
10. 複数のクライアントのために複数のオブジェクトに関する変更を記憶するステップをさらに含む請求項１に記載の方法。
11. 前記オブジェクトは、データフロー・グラフのコンポーネントを表す複数のノードと、コンポーネント間のデータの流れを表すノード間のリンクとを含むデータフロー・グラフの一部に対応する、請求項１に記載の方法。
12. 前記クライアントから第１のメッセージを受信する前記ステップは、前記データフロー・グラフのコンポーネントの少なくとも１つの特徴を定義するパラメータの値を受信するステップを含む請求項１１に記載の方法。
13. 前記データフロー・グラフのコンポーネントのそれぞれの特徴を定義する１つ又は複数のパラメータを受信するインターフェースを提供するステップをさらに含む請求項１１に記載の方法。
14. 前記インターフェースは複数のユーザ・インターフェース要素を表示し、前記ユーザ・インターフェース要素間の関係は前記データフロー・グラフのコンポーネント間の依存度に基づく請求項１３に記載の方法。
15. 前記関係は前記サーバ上に記憶された仕様によって定義される請求項１４に記載の方法。
16. 前記第１のメッセージを受信するステップは、中間データの要求を受信するステップを含み、
    前記オブジェクトを作成するステップは、
    前記データフロー・グラフの前記一部をコンパイルするステップと、
    前記データフロー・グラフの前記コンパイルされた一部を実行することによって出力データセットに対する出力を生成するステップと
    を含む請求項１１に記載の方法。
17. 前記オブジェクトを作成するステップは、
    前記中間データの生成に必要な第１のコンポーネントセットを判定するステップと、
    前記第１のコンポーネントセットに含まれない、前記データフロー・グラフ内のコンポーネントを無効にするステップと、
    前記出力データセットを格納するために前記データフロー・グラフに結合される中間データ・シンクを作成するステップと
    を含む請求項１６に記載の方法。
18. 前記第１のコンポーネントセットを判定するステップは、データ・ソースを前記中間データ・シンクに接続しないリンクを識別するステップを含む請求項１７に記載の方法。
19. 前記中間データ・シンクを作成するステップは、前記中間データ・シンクへのリンクが並列データフローを表すことを判定するステップと、前記中間データ・シンクとして並列データ・シンクを作成するステップとを含む請求項１７に記載の方法。
20. クライアントとサーバとの間の通信をサポートするコンピュータ・プログラムが記憶されたコンピュータ可読媒体であり、前記コンピュータ・プログラムは、ブリッジに、
    クライアントから第１のメッセージを受信させ、
    前記第１のメッセージに応答してオブジェクトを作成させ、
    前記第１のメッセージに対する応答を前記クライアントに送信させ、
    サーバから前記オブジェクトに対する変更を受信させ、
    前記オブジェクトに対する変更を記憶させ、
    前記変更を受信させた後に、前記クライアントから第２のメッセージを受信させ、
    記憶された前記変更を前記第２のメッセージに対する応答と共に前記クライアントに送信させる
    命令を含むコンピュータ可読媒体。
21. クライアントとサーバとの間の通信をサポートするシステムであり、
    少なくとも１つのプロセッサを含むサーバと、
    該システム内のオブジェクトを管理するように構成された少なくとも１つのプロセッサを含むブリッジと
    を備え、
    前記管理は、
    クライアントから第１のメッセージを受信するステップと、
    前記第１のメッセージに応答してオブジェクトを作成するステップと、
    前記第１のメッセージに対する応答を前記クライアントに送信するステップと、
    前記サーバから前記オブジェクトに対する変更を受信するステップと、
    前記オブジェクトに対する前記変更を記憶するステップと、
    前記変更を受信するステップに続いて、前記クライアントから第２のメッセージを受信するステップと、
    記憶された前記変更を前記第２のメッセージに対する応答と共に前記クライアントに送信するステップと
    を含むシステム。
22. ブリッジを使用してクライアントとサーバとの間の通信をサポートするシステムであり、
    データ供給手段と、
    前記システム内のオブジェクトを管理する手段と
    を備え、前記管理は、
    クライアントから第１のメッセージを受信するステップと、
    前記第１のメッセージに応答してオブジェクトを作成するステップと、
    前記第１のメッセージに対する応答を前記クライアントに送信するステップと、
    前記データ供給手段から前記オブジェクトに対する変更を受信するステップと、
    前記オブジェクトに対する変更を記憶するステップと、
    前記変更を受信するステップに続いて、前記クライアントから第２のメッセージを受信するステップと、
    記憶された前記変更を前記第２のメッセージに対する応答と共に前記クライアントに送信するステップと
    を含むシステム。

Images