(57)【要約】  シンクライアントユーザインターフェースは、ユーザインターフェースおよびアプリケーションサーバを含む。ユーザインターフェースは、ディスプレイを有するパーソナルコンピュータなどのクライアントデバイス上で実行される。ユーザインターフェースは、データを表示するためのクライアントアプリケーションを含む。アプリケーションサーバは、電子データネットワークを介してユーザインターフェースと、リモートデータベースとに結合されており、データを求める要求をユーザインターフェースから受信し、データを求めるその要求に基づいてクエリー要求を作成し、データベースにアクセスしてそのクエリー要求をデータベースに提示し、そのクエリー要求に応答したデータベースからの結果を受信し、そしてその結果の一部分をユーザインターフェースに送信するように構成されている。
2009512947.tif 000002
【特許請求の範囲】
【請求項１】
a)ディスプレイを有するクライアントデバイス上で実行されるユーザインターフェースであって、前記クライアントデバイス上でユーザにデータを表示するためのユーザインターフェースと、
b)電子データネットワークを介して前記ユーザインターフェースと、リモートデータベースとに結合されているアプリケーションサーバであって、データを求める要求を前記ユーザインターフェースから受信し、データを求める前記要求に基づいてクエリー要求を作成し、前記データベースにアクセスして前記クエリー要求を提示し、前記クエリー要求に応答した前記データベースからの結果を受信し、そして前記結果の一部分を前記ユーザインターフェースに送信するように構成されているアプリケーションサーバと
を含むことを特徴とするシンクライアントユーザインターフェース。
【請求項２】
前記ユーザインターフェースが、前記アプリケーションサーバによって提供されたデータの前記一部分のサブセットであるデータの第1の範囲のみを表示するように構成されており、そしてさらなるデータの表示を要求するユーザの操作に応答して、前記アプリケーションサーバによって提供されたデータの前記一部分のサブセットであるデータの第2の範囲を表示する
ことを特徴とする請求項1に記載のシンクライアントユーザインターフェース。
【請求項３】
データの前記第1および第2の範囲が連続している
ことを特徴とする請求項2に記載のシンクライアントユーザインターフェース。
【請求項４】
前記クライアントインターフェースが、前記アプリケーションサーバによって提供されたデータの前記一部分の範囲外にあるデータの表示を要求するユーザの操作に応答して、さらなるデータを求める要求を前記アプリケーションサーバへ送信するようにさらに構成されており、
前記アプリケーションサーバが、データを求める前記要求に基づいてクエリー要求を作成し、前記データベースにアクセスして前記クエリー要求を提示し、前記クエリー要求に応答した前記データベースからの結果を受信し、そして前記結果の一部分を前記ユーザインターフェースに送信するようにさらに構成されている
ことを特徴とする請求項2に記載のシンクライアントユーザインターフェース。
【請求項５】
前記クライアントインターフェースが、前記データに対する分析機能を実行して、前記分析機能の結果を表示するように構成されており、
前記アプリケーションサーバが、前記データベース内のデータに対する更新が前記クライアントインターフェースにおける前記分析機能の前記結果に影響を与える場合を識別し、前記データベースにアクセスして前記クエリー要求を再提示し、前記クエリー要求に応答した前記データベースからの結果を受信し、そして前記結果の一部分を前記ユーザインターフェースに送信するように構成されている
ことを特徴とする請求項1に記載のシンクライアントユーザインターフェース。
【請求項６】
前記電子データネットワークを介して前記クライアントインターフェースと前記アプリケーションサーバとに結合されているリモートアプリケーションリポジトリをさらに含み、
前記アプリケーションリポジトリが、前記クライアントインターフェースの構成、前記データベースの構成、および前記クライアントインターフェースの構成と前記データベースの構成との間における相互関係に関連するデータを保持するように構成されている
ことを特徴とする請求項5に記載のシンクライアントユーザインターフェース。
【請求項７】
真のシンクライアントグラフィカルユーザインターフェースを容易にするためのシステムであって、
リモートデータベースからのデータをクライアントデバイスのディスプレイ上に表示するためのインターフェース手段と、
表示構成の定義を離れた場所に保持するためのリポジトリ手段と、
前記データベースにクエリーを行って、前記表示構成の定義に従ってクエリーの結果を前記インターフェース手段に提供するためのサーバ手段と
を含むことを特徴とするシステム。
【請求項８】
前記サーバ手段がさらに、前記データベース内のデータに対する更新が前記ディスプレイデバイス上のデータの前記表示に影響を与える場合を識別し、前記更新を反映するために前記表示を修正することができるように前記インターフェース手段に前記更新を通知するように機能する
ことを特徴とする請求項7に記載のシステム。
【請求項９】
前記サーバ手段がさらに、さらなるデータを前記データベースに要求するオペレーションが前記インターフェース手段において行われる場合を識別するように機能し、前記データベースにクエリーを行い、前記表示構成の定義およびさらなるデータに関する前記識別に従ってクエリーの結果を前記インターフェース手段に提供する
ことを特徴とする請求項7に記載のシステム。
【請求項１０】
前記インターフェース手段が、データをページ単位で表示すると共に、
オペレータがデータのさらなるページを要求すると、前記サーバ手段が、さらに、前記要求を識別するように機能し、前記データベースにクエリーを行い、前記表示構成の定義および前記要求に従ってデータのさらなるページを前記インターフェース手段に提供する
ことを特徴とする請求項7に記載のシステム。
【請求項１１】
前記インターフェース手段が、データを集約することができるグリッドコンポーネントを含み、
前記クエリーの結果が、前記グリッドコンポーネントに対応するデータセット全体の一部分から構成される
ことを特徴とする請求項7に記載のシステム。
【請求項１２】
前記リポジトリ手段がさらに、クライアントデバイスの構成、データベースの構成、および前記クライアントデバイスの構成と前記データベースの構成との間における相互関係に関連するデータを保持するように機能する
ことを特徴とする請求項7に記載のシステム。
【請求項１３】
シンクライアント上にデータをレンダリングする方法であって、
クライアントインターフェースを提供するステップと、
前記インターフェースの表示構成を定義して、前記構成の定義を前記クライアントインターフェースから離れた場所に保存するステップと、
前記構成の定義に基づいてデータベースに対するクエリーを動的に作成するステップと、
前記動的なクエリーの結果を表示用として前記クライアントインターフェースへ送信するステップとを含み、
前記クエリーの結果が、前記クライアントインターフェースに対応するデータセット全体のサブセットから構成される
ことを特徴とする方法。
【請求項１４】
前記データベース内のデータに対する更新が前記クライアントインターフェース上のデータの前記表示に影響を与える場合を識別し、前記更新を反映するためにデータの前記表示を修正することができるように前記インターフェースに前記更新を通知するステップをさらに含む
ことを特徴とする請求項13に記載の方法。
【請求項１５】
さらなるデータを前記データベースに要求するオペレーションが前記インターフェースにおいて行われる場合を識別し、前記データベースにクエリーを行い、前記表示構成の定義およびさらなるデータに関する前記識別に従ってクエリーの結果を前記インターフェース手段に提供するステップをさらに含む
ことを特徴とする請求項13に記載の方法。
【請求項１６】
前記クエリーの結果を前記クライアントインターフェース上にデータのページ単位で表示するステップと、
ユーザの操作がデータのさらなるページを要求した場合に、前記要求を識別して、前記データベースに動的にクエリーを行い、前記表示構成の定義および前記要求に従ってデータのさらなるページを前記インターフェースに提供するステップと
をさらに含むことを特徴とする請求項13に記載の方法。
【請求項１７】
前記インターフェースが、データを集約することができるグリッドコンポーネントを含み、
前記クエリーの結果が、前記グリッドコンポーネントに対応するデータセット全体の一部分から構成される
ことを特徴とする請求項13に記載の方法。
【請求項１８】
前記インターフェースの表示構成を定義して、前記構成の定義を前記クライアントインターフェースから離れた場所に保存するステップと、
前記構成の定義に基づいてデータベースに対するクエリーを動的に作成するステップと、
前記動的なクエリーの結果を表示用として前記クライアントインターフェースへ送信するステップとを含むオペレーションを実行することによってシンクライアント上にデータをレンダリングするためのコンピュータ実行可能命令を格納しているコンピュータ可読媒体であって、
前記クエリーの結果が、前記クライアントインターフェースに対応するデータセット全体のサブセットから構成される
ことを特徴とするコンピュータ可読媒体。
【請求項１９】
前記データベース内のデータに対する更新が前記クライアントインターフェース上のデータの前記表示に影響を与える場合を識別し、前記更新を反映するためにデータの前記表示を修正することができるように前記インターフェースに前記更新を通知するためのコンピュータ実行可能命令をさらに含む
ことを特徴とする請求項18に記載のコンピュータ可読媒体。
【請求項２０】
さらなるデータを前記データベースに要求するオペレーションが前記インターフェースにおいて行われる場合を識別し、前記データベースにクエリーを行い、前記表示構成の定義およびさらなるデータに関する前記識別に従ってクエリーの結果を前記インターフェース手段に提供するためのコンピュータ実行可能命令をさらに含む
ことを特徴とする請求項18に記載のコンピュータ可読媒体。
【請求項２１】
前記クエリーの結果を前記クライアントインターフェース上にデータのページ単位で表示し、ユーザの操作がデータのさらなるページを要求した場合に、前記要求を識別して、前記データベースに動的にクエリーを行い、前記表示構成の定義および前記要求に従ってデータのさらなるページを前記インターフェースに提供するためのコンピュータ実行可能命令をさらに含む
ことを特徴とする請求項18に記載のコンピュータ可読媒体。
【請求項２２】
前記インターフェースが、データを集約することができるグリッドコンポーネントを含み、前記クエリーの結果が、前記グリッドコンポーネントに対応するデータセット全体の一部分から構成される
ことを特徴とする請求項18に記載のコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にグラフィカルユーザインターフェースに関する。より詳細には、本発明は、多大なローカルメモリ、処理リソース、あるいはネットワーク回線容量を必要とせずに堅牢なクライアント機能を可能にするクライアントインターフェース上にデータを表示するためのシステムおよび方法に関する。
【背景技術】
【０００２】
「関連特許文書の相互参照」
本出願は、2005年10月18日に出願された米国特許出願第11/253273号の一部継続出願であり、その内容の全体が、参照によって本明細書に組み込まれている。
【０００３】
ムーアの法則は、計算能力が時と共に指数関数的に高まるであろうと正確に予測し、ソフトウェア会社は、利用可能な高まりゆくコンピュータ処理能力を活用するアプリケーションを熱心に開発してきた。処理能力と同様に、市販のコンピューティングデバイス内で提供されるデータストレージおよび回線容量の価格および性能も、急速に改善している。同時に、パーソナルコンピュータなどのフロントエンドデバイスの性能を活用するために、ソフトウェアアプリケーションアーキテクチャーは、データ処理能力のない端末を伴う大型のメインフレームシステムから分散型アーキテクチャーへと移り変わっている。
【０００４】
ほとんどの企業が、ビジネスアプリケーションを実行するために自分たちの従業員の机上に専用のパーソナルコンピュータを提供するほど、パーソナルコンピュータは、非常に随所に見られるようになっている。しかし、コンピューティングデバイスがより普及し、コンピューティングアーキテクチャーがより分散していくにつれて、企業にとっては、自分たちのインストールしたソフトウェアアプリケーションを維持することが、ますます複雑になり、高くつくようになっている。
【０００５】
より最近では、進化したネットワーキングによって、集中化されたアーキテクチャーが復活できるようになっており、これらの集中化されたアーキテクチャーは、人によっては、管理しやすく、管理費用が安くすみ、エンドユーザデバイスに対してあまり多くを求めないものとみなされてきた。皮肉なことに、メインフレームと、「データ処理能力のない」端末とによって特徴付けられるアーキテクチャーなどの古いアーキテクチャーは、今日のウェブサーバアーキテクチャーへと生まれ変わっている。しかし今日のユーザは、データ処理能力のない端末がこれまで提供することができた機能よりも多くの機能を自分のアプリケーションに期待しており、したがって、堅牢なフロントエンド機能に欠けるシステム案は、ユーザによって拒否されてきた。
【０００６】
この問題に対応して、堅牢なユーザ経験を提供できるいわゆる「スマートクライアント」のコンセプトによって、標準的なウェブアプリケーションアーキテクチャーが広まっている。スマートクライアントアーキテクチャーでは、アプリケーション機能の一部が、ローカルに実行するためにエンドユーザデバイスへ移されており、これは、PCデスクトップの処理能力を活用する。起動時にクライアントプログラムをロードすることができるために、スマートクライアントアーキテクチャーを中央で管理することができる場合が多いので、スマートクライアントアーキテクチャーは、展開しやすい場合がある。理論的には、そのプログラムをシャットダウンして再起動するだけで、そのようなアプリケーションの新たなバージョンを展開することができる。しかし、クライアントをより高性能にするだけでは、展開およびアップグレードに伴う問題は解決しない。
【０００７】
コンピュータアプリケーションがより高性能になるにつれて、さらなるメモリ消費量、ネットワーク回線容量、および待ち時間が必要とされるために、それらのプログラムを実装するにはますます強力なクライアントデバイスおよびインフラストラクチャーが必要となるので、ハードウェアのアップグレードは、依然として高くつく。
【０００８】
投資および金融業界向けのアプリケーションは、(スプレッドシートのような)グリッドコンポーネントを中心にして設計されている場合が多く、このグリッドコンポーネントによって、ユーザは、階層的な表形式で情報を分析できるようになる。このようなグリッドは、株式ポートフォリオに関連するデータなどの膨大な量のデータを蓄積して集約するために使用されている。その結果、投資アプリケーションにとっては、「グリッド」が、コンピューティングリソースを最も消費する元となっており、したがって、高性能なシンクライアントを設計する際の最大の難題に他ならない。したがって、上述の問題を解決し、真にシンだが高性能なクライアントアプリケーションインターフェースを提供することができる新たな改良されたシステムおよび方法が必要とされている。
【特許文献１】米国特許出願第11/253273号
【発明の開示】
【発明が解決しようとする課題】
【０００９】
本発明は、ますます複雑になっている投資分析ソフトウェアを展開してアップグレードすることに伴う問題を解決する。多くの組織は、より強力な新たなアプリケーションを急に採用することはできない。というのは、それらの新たなアプリケーションによって要求されるさらなる情報処理リソースを提供する目的で自分たちの現在のインフラストラクチャーをアップグレードするために必要とされる機器および労働力のコストを賄うことができないためである。本発明には、サーバに基づく情報をクライアント側のデータグリッド上へ効率よく提供してリアルタイムなデータ分析を行うことを可能にするための斬新なメカニズムが含まれる。
【課題を解決するための手段】
【００１０】
本発明のいくつかの好ましい実施形態によれば、シンクライアントインターフェースシステムが提供される。このシステムは、アプリケーションサーバに結合されている1つまたは複数のインターフェースアプリケーションを含む。このインターフェースアプリケーションは、リモートクライアントデバイスとして実行され、データを編集および集約するためのグリッドコンポーネントまたはオブジェクトを含む。アプリケーションサーバは、クライアントによる要求に応じてインターフェースにデータを提供するためにクエリー要求を動的に作成し、その一方で、グリッド内のインターフェース上に表示されるデータの分量を制限する。アプリケーションサーバは、データベース内のデータが更新される場合に通知を受信し、その更新が、インターフェースアプリケーション内に表示されているデータに影響を与えるかどうかを判定し、そうである場合には、グリッドがデータの更新を反映するようにインターフェースアプリケーションにその更新を通知するように構成されている。
【００１１】
いくつかの好ましい実施形態によれば、このシステムは、インターフェースアプリケーションの構成およびデータベーススキーマに関する定義を保持するためのアプリケーションリポジトリをさらに含むことができる。インターフェースアプリケーションは、ユーザが、適切なフォームを介してなど、その表示構成を修正可能にするように構成されており、ユーザによる修正を反映するためにリポジトリを更新する。アプリケーションサーバは、インターフェースおよびグリッドにデータを投入するために、インターフェースアプリケーションの構成の定義およびデータベースの定義に基づいて、アプリケーションリポジトリにアクセスすると共に、動的なクエリーを作成するように構成されている。
【００１２】
本発明のいくつかの好ましい実施形態によれば、アプリケーションリポジトリは、データベースのモデルを含み、アプリケーションサーバは、データベースの更新がインターフェースの現在の表示に影響を与える場合をそのデータベースのモデルに基づいて判断するように構成されている。
【００１３】
本発明のいくつかの好ましい実施形態によれば、データベースは、リレーショナルデータベース管理システム（relational database management system：RDBMS)を含み、データベースに対する更新をリアルタイムにアプリケーションサーバへ通知するためにデータベーストリガーが利用される。したがってデータベースに対する更新は、それらの更新がどこから生じたかにかかわらず、アプリケーションサーバに通知される。
【００１４】
本発明のいくつかの好ましい実施形態によれば、インターフェースアプリケーションは、メモリ内に保存して表示グリッド内に表示することができる行の数をユーザが定義できるようにするように構成されている。表示グリッド内に表示される行の数は、メモリ内にローカルに保存される行の数よりも少ないことが好ましい。表示インターフェース上におけるデータの表示をコントロールするために、そしてメモリ内に保存されていないデータをインターフェースが要求した場合に新たなクエリーが提示されるようにするために、ページングアルゴリズム(paging algorithm)が提供される。
【００１５】
本発明のさまざまな実施形態のさらなる応用例および利点について、以降で図面を参照して論じる。
【発明を実施するための最良の形態】
【００１６】
本発明は、多くの異なる形態で具体化することができるが、本開示は、本発明の原理の例を提供するものとみなされるべきであり、そのような例は、本明細書で説明されているおよび/または本明細書に図示されている好ましい実施形態に本発明を限定することを意図するものではないという理解のもとで、複数の例示的な実施形態が本明細書に記載されている。
【００１７】
本発明は、この文書の全体を通じて「真の」シンクライアントとして参照されている。というのは、本発明のクライアントインターフェースは、その他のn階層のアーキテクチャーとは異なり、対象のデータセットがいかに大きくても、依然として「シン」であるためである。
【００１８】
本発明は、単一のユーザや複数のユーザによって共有されているデータベース環境内で任意の大きさのデータセットをモニタして分析するために使用することができる。シンクライアントアーキテクチャーに対する従来のアプローチとは異なり、本発明は、非常に大きなデータセットを操作する際の反応のよい豊かなユーザ経験を、それに比例した大きなメモリリソースや回線容量リソースをクライアントフロントエンドデバイス(たとえばユーザデスクトップ)内に必要とせずにサポートする。
【００１９】
従来のクライアント/サーバアプリケーションは、そのクライアントアプリケーションをホストしているユーザデバイスが、処理のほとんどをローカルで(すなわち、ユーザデスクトップの中央処理装置上で)実行するため、「ファット」クライアントを有していると考えられる。詳細には、クライアント/サーバアプリケーションは、クライアントコンピュータ上にロードされて実行され、必要とされるデータセットを、(通常はリレーショナルデータベース管理システム（relational database management system：RDBMS)をホストしている)サーバコンピュータから検索する。クライアントが、自分の機能を正しく実行するために多大な(すなわち「大きな」)クライアント側のプログラムおよび/またはデータセットをロードして保持する必要がある場合に、それらのクライアントは「ファット」とみなされる。クライアント/サーバの世界においては、プログラムの複雑さが増すにつれて、あるいはデータセットのサイズが増大すると、クライアントデバイス上のメモリフットプリントは増大する(すなわち、より「ファット」になる)。
【００２０】
クライアント/サーバのファットクライアントのアプローチには、2つの重大な欠点がある。1つめの欠点としては、より強力な新しいアプリケーションが展開される際に、増大するプログラムおよびデータのサイズをサポートするために、ネットワークインフラストラクチャーだけでなく、クライアントデバイス(ユーザデスクトップ)もアップグレードしなければならない。大きな組織の場合には、これによって、もしかすると何百あるいは何千ものPCデスクトップを取り替えることになる可能性があり、2つめの欠点としては、たとえ1つのアプリケーションにとってのメモリ要件が変わらなくても、そのアプリケーションの新たなバージョンでは、その新たなバージョンを使用するために個々のデスクトップを構成し直すことが必要となる。したがって、タイムリーに実施するためには、IT(information technology)リソースの多大な投資が必要となるおそれがある。
【００２１】
インターネットウェブブラウザの普及によって、従来の「ファットクライアント」アプリケーションに代わるものとして、n階層の「シンクライアント」アプリケーションアーキテクチャー(たとえば、ウェブ対応型のアプリケーション)の開発が促進された。このようなn階層の「シンクライアント」アプリケーションアーキテクチャーは、「ファット」クライアント/サーバのアプローチにおける欠点のうちのいくつかに対処する。n階層のシンクライアントのアプローチにおいては、プログラムが分散されて中央で管理され、それによって、アプリケーションプログラムのわずかな一部分だけが、クライアントデバイス上にロードされ、実行される。多くの場合、このアプローチでは、クライアント側のコンポーネントをアプリケーションの起動時にロードすることができる。さらに、いくつかのアプリケーションは、HTMLやJAVA(登録商標)などを使用してユーザインターフェースを提供することができる可能性があり、結果として、クライアントデスクトップ上で必要とされるプログラムは、ウェブブラウザだけとなる。しかし、このアプローチには問題がある。それは、アプリケーション「スクリーン」が、通常は普通のインターネットコンテンツと同様の静的な「ドキュメント」として提供され、多くのビジネスアプリケーションは、静的な「ドキュメント」を提供するアプローチにはあまり役に立たないということである。たとえば、リアルタイム分析アプリケーションは、ユーザの複雑な行動に対応するだけの十分に高性能な動的なインターフェースおよびクライアントデバイスを必要とする。
【００２２】
n階層のスマートクライアントアプリケーションは、ランタイムにデスクトップ上へロードされた時点では小さいと主張することによって、それらのクライアントプログラムをシンクライアントアプリケーションとして通用させようという試みがなされている。しかし、その後にそのアプリケーションが何事かを行えるようになる前に、大量のデータをロードしなければならない。これらのアプリケーションは、たしかに最初はシンだが、クライアント/サーバ時代のいかなる「ファット」クライアントとも同じぐらいファットになる可能性がある。
【００２３】
本発明は、従来のインターフェースとは異なり、インターフェースの対象のデータセットのサイズを問わずに「シン」であり続ける「真の」シンクライアントインターフェースを提供する。すなわち、上述のように、以前のインターフェースは通常、従来のGUI機能を提供するために、インターフェースのための対象のデータセットの全体をローカルメモリ内にキャッシュする。結果として、従来技術の「シンクライアント」は、使用する際に「ファット」になる。しかし本発明によれば、インターフェースのための「シン」なメモリフットプリントを保持しながら、クライアントがデータターゲットから所望のデータを表示して分析できるようにし、堅牢なGUI表示機能を提供する斬新なシステムおよび方法が提供される。
【００２４】
本発明は、膨大な量のデータを編集して集約するグリッドなどの堅牢なGUI機能を提供することができるクライアントアプリケーション層と、クライアント層に提供されるデータの分量を管理するために、およびリアルタイムの更新およびそれに対するページ付けを提供するためにクエリー要求を動的に作成するアプリケーションサーバ層と、データベース/アプリケーションリポジトリ層とを含む複数の層からなるアーキテクチャーを提供することによって、これらおよびその他の目的を達成する。データベースサーバは、データベーストリガーやストアドプロシージャーなどを利用してアプリケーションサーバ層と通信することが好ましく、それによってアプリケーションサーバは、データに対する更新がいつ行われたかをリアルタイムに、あるいはほぼリアルタイムに特定することができる。アプリケーションリポジトリは、クライアント層構成情報ならびにデータソース情報を保持し、クライアント層およびアプリケーションサーバの双方が、これにアクセスすることができ、これによって、動的なクエリーおよびデータ更新の決定の基礎が形成される。本発明によって提供される斬新なシステムおよび方法の結果として、クライアントデバイス上の小さなメモリフットプリントを保持するグリッドを含む堅牢なGUI機能を有することができる「真の」シンクライアントインターフェースが提供される。本発明は、金融コンピュータアプリケーションなど、膨大な量のデータを集約して分析するアプリケーションにおいて特に有用だが、本発明は、そのようなアプリケーションに限定されるものではない。
【００２５】
図1は、「グリッド」を含む例示的なGUIインターフェースのスクリーンショットである。このスクリーンショットは、MACGREGOR'S XIP(登録商標) ENTERPRISE COMPLIANCEアプリケーションから取られたものである。このようなコンプライアンスモニタリングアプリケーションによって、取引機関は、ルールを設定して、取引がそれらのルールに準拠しているかを取引前や取引後にモニタすることができる。もちろん、クライアントインターフェース内でのグリッドの使用は、随所で見られ、本発明は、そのような金融アプリケーションに限定されることを意図するものではない。
【００２６】
図示されている例示的なGUIインターフェース100は、ポートフォリオマネージャー(PM: portfolio manager)102によってアカウントを表示するための表示グリッドを含む。それぞれのポートフォリオマネージャー102の見出しの下には、そのポートフォリオマネージャーに関するそれぞれのアカウントに対応する情報102a、102b、102cの詳細ブロックが表示されている。それぞれの詳細ブロック102a〜102cは、そのアカウントに関するコンプライアンスルールのリストを含む。詳細ブロック内に表示されているデータは、リレーショナルデータベースから直接引き出されたデータ、および集約されたデータや計算されたデータを含む。たとえば「market value」のフィールドは、非常に大きなデータセットから集約されている。以降でさらに詳しく説明するように、集約されたデータは、すべてのデータをローカルにロードすることなく表示される。
【００２７】
GUIインターフェース100は、WINDOWS(登録商標) FORMSおよびFLEX GRIDなどの任意の数のツールを用いて実装することができる。さらに、.NETコントロールを使用して、表示に機能を追加することもできる。標準的なコントロールを「裏側で」修正して、豊かなコントロールを達成することもできる。このようなコントロールによって、スクリーン上でデータを操作すること、ブロックを拡大すること、およびデータをスクロールすること、データの全体にページ番号を振ることなどが可能になる。
【００２８】
この特定のフォーム100は、ユーザが、「+」や「-」の標示をマウスでクリックすることによって、それぞれの詳細ブロックを拡大したり縮小したりできるようにする。この機能は、公知のグリッドオブジェクトにとって標準的なものである。このようなグリッドコンポーネントは通常、集約フィールドを作成するために必要な表示できるすべてのデータをプリフェッチして、そのデータセットの全体を、ユーザの対話を処理する際に使用されることになるクライアント側のメモリ内に保持することになり、このことによって、場合によっては非常に大きなメモリフットプリントを伴うクライアントアプリケーション(すなわち「ファット」クライアント)が生み出されるおそれがある。この問題を回避するために、本発明は、完全なデータセットをメモリ内へプリフェッチする必要なく、堅牢な表示およびユーザ経験をサポートするのに十分なデータをクライアント側に保持するための効率のよいメカニズムを利用する。さらに本発明は、複数のユーザによってデータセットを共有する環境においてさえ、表示内でリアルタイムな更新を反映するためのメカニズムを提供する。
【００２９】
図2は、本発明の一実施形態による真のシンクライアントインターフェースシステムのためのアーキテクチャー200のコンポーネントレベルの図である。3つの層からなるアーキテクチャーが、クライアントアプリケーション202(たとえば100)と、中間層のアプリケーションサーバ204と、アプリケーションリポジトリ206およびデータベースサーバ208を含む第3の層とを含んでいる。
【００３０】
アプリケーション202は、ローカルに、たとえばパーソナルコンピュータなどのユーザデスクトップ上に存在する。アプリケーション202は、中間層のアプリケーションサーバ110を介してデータベースサーバ208からのデータにアクセスし、それらのデータを表示し、分析するように構成されており、また、インタラクティブな表示および分析のための複数のGUIフォームを含むことが好ましい。図1に示されているように、このアプリケーションは、集約されたデータなどを表示するための標準的なグリッド機能を有するGUIフォームを含むことができる。それらのGUIフォームの数および構成は、本発明にとって重要ではない。
【００３１】
アプリケーションサーバ204は、表示および分析のためにアプリケーション202へデータを提供する目的から、データベース208に対する動的なクエリーを作成するために、アプリケーション202と共にアプリケーションリポジトリ206内の情報を利用するように構成されている。以降でさらに詳しく説明するように、アプリケーションサーバ204は、アプリケーション202がGUI機能を損なうことなく小さなメモリフットプリントだけですむように(すなわち、「シン」のままでいるように)データセットをアプリケーション202へ効率よく提供するための、そしてユーザの操作(たとえば、スクロール、ページアップ、あるいはページダウン)に応答した更新やデータベースの更新をリアルタイムに提供するためのアルゴリズムおよびオブジェクトを利用する。
【００３２】
アプリケーションリポジトリ206は、アプリケーション202に関連する構成情報(たとえば、グリッドプロファイルの設定やフィールドの選択などのユーザの表示設定)、データベース208のデータベースソース定義、およびデータベースとそれぞれのユーザの表示(たとえば、それぞれのアプリケーションおよびグリッドオブジェクト)との間における相互関係を保持する。リポジトリ206は、電子データネットワークによって、クライアントアプリケーション202およびアプリケーションサーバ204の双方と結合されている。情報は、任意の適切な様式で保存することができる。一実施形態においては、定義を保存する3つのXMLドキュメント、すなわちアプリケーションテンプレート206a、グリッドテンプレート206b、およびデータベーススキーマのモデル206cが保持される。もちろん、さらなるテンプレートを提供することもできる。
【００３３】
アプリケーションサーバ204、データベースサーバ208、およびアプリケーションリポジトリ206は、クライアントアプリケーション100から離れた場所に、たとえば、好ましくは集中化されている適切なサーバプラットフォーム上に存在して、LANや、インターネット等の開かれたまたは安全なIPネットワークなどの電子データネットワークを介してアクセスできることが好ましい。アプリケーション202と、アプリケーションサーバ204と、データベースサーバ208およびアプリケーションリポジトリ206との間における通信およびメッセージングは、任意のフォーマットで、あるいはIPやHTTPなどの任意の標準に従って実施することができる。
【００３４】
単一のクライアントアプリケーションのみが示されているが、本発明は、多くのクライアントと共に実装することを意図したものであり、実際にクライアントの数は、本発明を実装するために使用されるハードウェアおよびネットワークの性能上の限界によって制限されるだけであるということを当業者なら理解するはずである。
【００３５】
本発明のシステムは、2つの主要な機能、すなわちデータの検索、表示、ページ付けなどを管理する(クライアント側コンポーネントおよびサーバ側コンポーネントを有する)動的なグリッドサブシステムと、データベース208内のデータに対するリアルタイムな更新を識別し、そのような更新がクライアント上の現在の表示に影響を与えるかどうかを判定し、必要な場合にはクライアントの表示をリアルタイムに更新してデータの更新を反映する通知サブシステム202cとによって特徴付けられる。
【００３６】
動的なグリッドサブシステムは、ページングアルゴリズムを実装しており、サーバ側サービスと、それらのサーバ側サービスに関するクライアント側コンポーネントとから構成される。これらのサービスが連携して、潜在的にはいかなるサイズのいかなるデータソースにも接続することができる一般的なグリッドのようなコンポーネントをサポートする。通知サブシステムは、データの変化に関するリアルタイムなメッセージングの通知を提供し、動的なグリッドのデータを、共有されているデータベースの変化と同期化する。
【００３７】
これらの2つのサブシステムのコンポーネントは、クライアントアプリケーション202をできるだけシンにするために、そしてシステム全体を拡張可能かつ保守しやすくするために、クライアントアプリケーション202(クライアント側)とアプリケーションサーバ204(サーバ側)との間で効率よく分散されることが好ましい。図示されているように、アプリケーション202は、クライアント側のグリッドの動的なグリッドコンポーネント202bおよび202cを含み、アプリケーションサービスは、ページマネージャーコンポーネント204aおよびサーバ側通知ネットワーク204bを含む。
【００３８】
アプリケーションの起動時に、クライアントアプリケーション202は、WINDOWS(登録商標) FORMS、FLEX GRID、あるいは.NETコントロールを用いたものなどの市販のプログラムコンポーネントであり得る自分のグリッド202aに、アプリケーションリポジトリ206内に保存されている構成設定に従い、データベース208からのデータを投入する。しかしクライアントアプリケーション202は、自分のグリッドへの投入を行うためにデータベース208に自分自身で直接クエリーを行うことはなく、この結果、そのグリッドに関するすべてのデータがフェッチされることになる。その代わりに、どのようにしてグリッドへの投入を行うかに関する情報は、離れた場所に保存される。このようなクライアントの構成設定は、ユーザによって構成できることが好ましい。
【００３９】
アプリケーション202は、複数のモジュール、すなわち、グリッドに関するフロントエンドユーザインターフェースコンテナであるグリッドベースのコンポーネント202aと、グリッドをコントロールするためのモデルビューコントローラ(MVC: Model-View-Controller)フレームワーク202bと、データ更新の通知を処理するためのクライアント側通知フレームワーク202cとを含む。MVCフレームワーク202bは、動的なグリッドコントロール(2)を含み、この動的なグリッドコントロール(2)は、グリッド機能を実装し、また、COMPONENTONE FLEX GRIDコントロールなどの市販のコントロールに基づくことができる。動的なグリッドコントローラ(3)は、MVCパターンにおけるコントローラの役割を果たす。グリッドがデータの1ページ分に対応し、ページ付けがコントロールされることが好ましい。
【００４０】
動的なグリッドコントローラ(3)は、アプリケーションリポジトリ206内のグリッドテンプレート206bを読み込み、動的なグリッドコントロール(2)をアプリケーションサーバへ接続し、データソースサービスとの相互運用性を提供するように構成されている。動的なグリッドコントローラは、通知の更新を得るために通知サブシステム202cの通知コンポーネント(6)および通知コンポーネントプロキシ(7)を使用する。
【００４１】
フロントコントローラ(4)は、アプリケーション202の範囲内における一枚札のオブジェクトであり、複数のアプリケーションコンポーネントにわたる相互運用性を提供するように構成されている。フロントコントローラ(4)は、アプリケーションの要求をサーバ側のサービスへ動的に結び付ける。フロントコントローラ(4)は、ランタイムに特定のサービスをそのサービスの場所へ動的に結び付けるためにアプリケーションテンプレート206aをロードする。
【００４２】
ページマネージャープロキシ(5)は、通常のC#クラスに相当し、アプリケーションサーバ204のページマネージャー204aのページマネージャーリモートコンポーネント(8)のAPIと通信し、ページマネージャーリモートコンポーネント(8)のためのプロキシとして機能する。このプロキシは、電子ネットワーク(たとえば、HTTPチャネル(III))を通じてクライアントの要求を適切なリモートサービスへ転送する役割を果たす。
【００４３】
アプリケーションサーバ204は、ページマネージャーモジュール204a、サーバ側通知フレームワーク204b、および持続層(ORM)204cを含む。ページマネージャーモジュール204aは、処理状態を把握しないコンポーネントを実装しているページマネージャーリモートコンポーネント(8)を含み、そのコンポーネントは、動的なグリッドに関するデータ読み取り/書き込み用APIを提供する。ページマネージャーリモートコンポーネント(8)は、持続層(14)へのデータを求める要求をSQLなどの実行可能なクエリーフォーマット言語で作成するために内蔵のクエリージェネレータ(9)を使用する。持続層(14)は、基礎をなすデータベース208とのORMのような相互運用性を定義するクラスのセットである。
【００４４】
図2に示されているように、動的なグリッドサブシステム202bのページマネージャープロキシ(5)は、表示したいデータを要求するためにアプリケーションサーバ204のページマネージャーコンポーネント204aと通信する。グリッドテンプレート206は、データソース名(データベーステーブルまたはビュー)、フィールド(列)、グループ分け、集約およびその他の機能、フィールドビジビリティー、ならびにその他の表示情報を定義する。作成されるクエリーは、どんなデータを表示したいか(タイプ)、ならびに対応するデータセットから必要とされる行の数(範囲)を定義する。範囲をランタイムに動的に設定することができ、現時点で見えている範囲の外側にあるさらなる行をプリフェッチすることができ、それによって、クライアント側で利用できるメモリの分量に応じてクライアントのメモリフットプリントが調整されることが好ましい。
【００４５】
クエリージェネレータは、アクティブなグリッドに関するテンプレート206bに基づいて、データベース208に対するクエリーを動的に実行する。グリッドコンポーネント202aが、そのクエリーの結果を表示する。
【００４６】
さらなるデータを事前にロードすることができ、それによって、ユーザがグリッド内のデータのスクロールなどの表示操作を実行したときに、それらのデータにアクセスして表示を更新することができる。事前にロードされるか、またはコード化されるデータの分量は、表示したい分量を大幅に超えないことが好ましい。スクロール操作が、事前にロードされていないデータを要求すると、動的なグリッドコントローラ(3)は、この要求を認識し、アプリケーションサーバ204のページマネージャー204aと通信して、次なる一式の該当するデータをロードするための動的なローディングオペレーションを実行する。以降で図3を参照して、この機能について示し、説明する。
【００４７】
表示したい集約されたデータをセットでフェッチすることもできる。たとえば、データのフェッチサイズが60行に設定されている場合、これには、集約レベルが最も低いデータの行(未加工の行)と、すべてが集約された行とが含まれる。したがって、データソースからフェッチされるデータの実際の分量は、フェッチサイズ以下となる可能性がある。というのも、集約された行は、「オンザフライ」で作成されるためである。表示されるデータのセットを、クライアントの「見えている範囲」と呼び、クライアントによってプリフェッチされたデータの全体を、「実際の」範囲と呼ぶ。見えている範囲は、作成されたクエリーに基づいてフェッチされた「実際の範囲」とは異なることがある。
【００４８】
「実際の範囲」は、グリッドテンプレート206bを通じて設定することができ、場合によってはデータを再び問い合わせなくても見えるようにすることができるデータのセットである。実際の範囲が、見えている範囲に等しくなるように定義されている場合には、サーバからフェッチされるすべてのデータが、グリッド内で見えるようになる。もしいずれかの集約された行が折り畳まれた(collapsed)場合には、システムは、その集約を構成する個々の行をフェッチしない。グリッドは、集約された行を表示して、適切な視覚的効果を提供する。したがって、折り畳まれた集約された行は、クライアント側でそれに比例したメモリフットプリントを消費しない。ユーザが集約行を広げたときには、さらなるクエリーを動的に作成して実行することができる。
【００４９】
ユーザによって開始される設定の変更によって、結果として現在のグリッドコンテンツにつながる動的なクエリーに対する修正が必要となることがある。たとえば、追加のデータや更新されたデータを必要とする表示エリア内の集約レベルまたはフィールドを追加したり削除したりすることができる。そのようなユーザによって開始される設定の変更が行われると、動的なグリッドコントローラ(3)は、ページマネージャー202と通信して、グリッドによってキャッシュされたデータをコントロールするクエリーを動的に更新し、そしてクエリーの結果を新しくする。
【００５０】
ページングメカニズムについて、一例として図3を参照して説明する。現在のページ302は、データベース208からフェッチされてメモリ内にアクティブに保持されているデータの実際の範囲に相当する。データ302aの見えている範囲は、フェッチされたデータのサブセットにすぎず、グリッドビューアの構成によって定義されている。スクロールアップ操作およびスクロールダウン操作などのよく知られているGUI機能によって、データの見えている範囲が移り変わることになる。見えている範囲の外側にあるが、実際の範囲内にあるデータは、データベースにアクセスすることなくグリッド機能によってすぐに表示することができる。しかしGUIの操作によって、実際の範囲の外側にあるデータを表示する必要が生じると、その要求に基づいて実際の範囲を新たなデータセットと取り替えるクエリー要求が作成される。
【００５１】
図3に示されているように、グリッドに関する対象のデータセットの全体であるクエリーセットの全体300の点から見ると、グリッド表示上で実際の範囲の最も上の行の先へスクロールアップすると、データの前のページ304の一部分が、動的なクエリーの実行によって現在のページ302に設定される。同様に、実際の範囲の最も下の行の先へスクロールダウンすると、データの次なるページ306の一部分がフェッチされて、現在のページ306に設定されることになる。
【００５２】
クライアントグリッドに関するデータの実際の範囲は、見えている範囲よりも広く設定されることが好ましい。データを表示用としてグリッドへロードするためには、結果として生じるセット内の最初の行の位置を特定しなければならない。実際の範囲は、行の数、スクロールの方向(ダウン/アップ)、および、該当する場合には、折り畳まれた行の定義(集約)として表すことができる。
【００５３】
たとえば、例示的なクライアントグリッドが、はじめに実際の範囲のサイズとして50行を有しており、折り畳まれた行を有していない場合を取り上げる。グリッドオペレーションは、下記のように処理することができる。
【００５４】
・初期設定- 開始位置= 0、実際の範囲= 50、スクロール=ダウン。
○ すべてのデータの行を削除する。
○ 行の数=実際の範囲に設定する。
○ 上から下へデータを投入していく。
【００５５】
・次のページを読み込む- 開始位置=見えている範囲内の最後の行のID、実際の範囲=50、スクロール=ダウン。
○ 2つの実際の範囲(古い範囲および新たな範囲)を用いて操作する。
○ 見えている範囲内の見えている最後の行から上のすべての行を切り捨てる。
○ 見えている範囲のうちの残りをグリッドエリアの一番上へ移動する。
○ 見えている範囲の一番下に新たな実際の範囲を追加する。
○ 実際の範囲のサイズよりも下の行を切り捨てる。
○ 見えている範囲は、実際の範囲の最初の行から開始する。
【００５６】
・前のページを読み込む- 開始位置=見えている範囲内の最初の行のID、実際の範囲=50、スクロール=アップ。
○ 2つの実際の範囲(古い範囲および新たな範囲)を用いて操作する。
○ 見えている範囲内の見えている最初の行から下のすべての行を切り捨てる。
○ 見えている範囲のうちの残りをグリッドエリアの一番下へ移動する。
○ 見えている範囲の一番上に新たな実際の範囲を逆の順で追加する。
○ 実際の範囲のサイズよりも上の行を切り捨てる。
○ 見えている範囲は、実際の範囲の最後の行で終了する。
【００５７】
・見えている範囲内でのスクロールダウン。
○ 見えている範囲内の最後の行よりも下に実際の範囲内のデータがある場合には、見えている範囲を下へ移動する。
○ 見えている範囲の一番下が、実際の範囲よりも「下にはみ出す」場合には、次のページを読み込む(上記を参照)。
【００５８】
・見えている範囲内でのスクロールアップ。
○ 見えている範囲内の最初の行よりも上に実際の範囲内のデータがある場合には、見えている範囲を上へ移動する。
○ 見えている範囲の一番上が、実際の範囲よりも「上にはみ出す」場合には、前のページを読み込む(上記を参照)。
【００５９】
・折り畳む。
○ 折り畳むデータをグリッドの折り畳んだ集まりに追加する。
○ 折り畳まれたノードよりも下の実際の範囲からすべての行を削除する。
○ 下の折り畳まれた行からデータをロードする(スクロールダウン)。
○ 実際の範囲の一番下に新たなデータを追加する。これは、折り畳まれたノードのシミュレーションを必要とすることがある。結果として生じるセットには、途切れがあり、これらの途切れには、折り畳まれたデータが存在しているはずである。というのは、ページマネージャーが、見えていない(折り畳まれた)行を除外しているためである。
○ 実際の範囲のサイズよりも下のすべての行を切り捨てる。
【００６０】
・広げる。
○ 広げるノードのデータをグリッドの折り畳んだ集まりから削除する。
○ 広げられたノードよりも下の実際の範囲からすべての行を削除する。
○ 下の広げられた行からデータをロードする(スクロールダウン)。
○ 実際の範囲の一番下に新たなデータを追加する。
○ 実際の範囲のサイズよりも下のすべての行を切り捨てる。
【００６１】
それぞれのレコードが一意の番号によって入力されている1つの大きなレコードセットというシンプルな例において、そのレコードセットが10,000個のレコードを有する場合に、最初の行は1という番号を有し、最後のレコードは10,000という番号を有するものとする。50行からなる第1のページをフェッチするために、ページングシステムは、次のようなクエリーを作成するであろう。
【００６２】
SELECT TOP 50* FROM <データソース> WHERE RowID > 0
ORDER BY RowID
【００６３】
ユーザが、50という番号を有する行よりも下にスクロールダウンすると、システムは、レコードセットの第2のページをフェッチすることになり、それは、次のようなクエリーによって行うことができる。
【００６４】
SELECT TOP 50* FROM <データソース> WHERE RowID > 50
ORDER BY RowID
【００６５】
次いでユーザは、51から100までの行の実際の範囲を有するページ2の上にいる際に、100という番号を有する行よりも下にスクロールダウンすることができ、そしてシステムは、同じクエリーを使用して、データの第3のページをフェッチする。たとえば、グリッドが101から150までの行の実際の範囲(第3のページ)を有していて、ユーザが、101という番号を有する行よりも上にスクロールアップする場合には、システムは、第2のページをフェッチすることになる。これは、次のようなクエリーによって行うことができる。
【００６６】
SELECT TOP 50* FROM <データソース> WHERE RowID < 101
ORDER BY RowID DESC
【００６７】
(Microsoft SQL Server 2000などの)いくつかのリレーショナルデータベースシステムは、一般的なクエリーに関する一意の番号を提供しない。したがって一意の番号は、SQLを使用している際に「オンザフライ」で提供しなければならない。さらに、このような番号付けは、集約(グループ分け)および並べ替えという2つのさらなる要素を統合するために必要とされる。
【００６８】
上述の例におけるすべてのクエリーは、未加工のデータをデータソースからどのようにして選択するかを示しているが、集約されたデータの取り扱いについては示していない。ほとんどの投資分析アプリケーションにおいては、集約は、任意選択とすることができ、したがって、集約データを単にあらかじめ計算してデータソース内に保持しておくことはできない。システムは、必要な情報をグリッド構成テンプレートから抽出して、集約データを「オンザフライ」で作成することができる特別なクエリーを作成しなければならない。たとえば、集約されたデータ(値、行)を計算するためにGROUP BY節(clause)を使用することができる。また、ロールアップ行を作成するためにWITH ROLLUP節を使用することができる。
【００６９】
データセットが、2つのレベルの集約を有する(第1のレベルがアカウントコードであり、第2のレベルがセキュリティーコードである)と想定される場合には、定義された階層は、2つのレベルを有し、そして集約されたデータを作成するために、次のようなクエリーが構築されることになる。
【００７０】
SELECT <いくつかのフィールド> FROM <データソース>
GROUP BY Account Code, Security Code WITH ROLLUP
【００７１】
データセットが、Account1およびAccount2という名前を有するポートフォリオと、Account1:Security1、Account1:Security2、およびAccount2:Security3のような対応するポートフォリオポジションとを含む場合には、上記のクエリーは、次のような階層を作成することができる。
【００７２】
● Account1
○ Security1
○ Security2
● Account2
○ Security3
【００７３】
GROUP BY WITH ROLLUPを使用することによって、双方のレベル(アカウントおよびセキュリティー)が作成される。このアプローチを使用することによって、いかなる集約レベルに関する階層も作成することができる。
【００７４】
オンザフライで作成できる一意のRowIDをすべての集約の行に提供することもできる場合には、集約のRow IDがデータソースのRow IDに対して正しい順序であることが重要となる。グリッド内のデータを使用するためには、最後のレコードセットは、下記のように表示されるべきである。
【００７５】
● Account1
○ Security1
◆ Account1, Security1, <1次ID>, <いくつかの値>
◆ Account1, Security1, <1次ID>, <いくつかの値>
○ Security2
◆ Account1, Security2, <1次ID>, <いくつかの値>
◆ Account1, Security2, <1次ID>, <いくつかの値>
◆ Account1, Security2, <1次ID>, <いくつかの値>
● Account2
○ Security3
◆ Account2, Security3, <1次ID>, <いくつかの値>
◆ Account2, Security3, <1次ID>, <いくつかの値>
【００７６】
この階層における第3のレベルは、データソースからの未加工のレコードによって表すことができる。結果として生じるセットが、すべての行に対して連番を有する場合には、上述のクエリースキームを使用することができる。いくつかのRowIDを上述の階層に追加すると、下記の結果となる。
【００７７】
● Account1                                                  100000
○ Security1                                           101000
◆ Account1, Security1, <1次ID>, <いくつかの値>   101010
◆ Account1, Security1, <1次ID>, <いくつかの値>   101020
○ Security2                                           102000
◆ Account1, Security2, <1次ID>, <いくつかの値>   102030
◆ Account1, Security2, <1次ID>, <いくつかの値>   102040
◆ Account1, Security2, <1次ID>, <いくつかの値>   102050
● Account2                                                  200000
○ Security3                                           203000
◆ Account2, Security3, <1次ID>, <いくつかの値>   203060
◆ Account2, Security3, <1次ID>, <いくつかの値>   203070
【００７８】
見て取ることができるように、行コード(RowID)は順番になっており、つまり、下記のクエリーが使用されると、ID=2030の行よりも後の50行が返されることになる。
【００７９】
SELECT TOP 50 FROM <データソース> WHERE RowID > 2030
ORDER BY RowID
【００８０】
上に示されている所望の結果は、2つの異なるクエリーを結合することによって生み出すこともできる。第1のクエリーは、データソースから未加工のデータを返し、第2のクエリーは、(グループ化された)集約されたデータを返す。UNION SQLオペレータを使用して、これらの2つの結果を動的にマージすることができる。下記のクエリーは、例を使用して、未加工のデータと、集約されたデータとをマージする。
【００８１】
SELECT TOP 50 [SOURCE].* FROM
(
SELECT RowID, <いくつかのフィールド> FROM <データソース>
UNION
SELECT RowID, <いくつかのフィールド> FROM <データソース>
GROUP BY Account Code, Security Code WITH ROLLUP
)AS SOURCE
ORDER BY 1
【００８２】
TOP属性を適用してクエリーの結果をマージすることができるという点に注意が必要である。RowIDの列は、データソースから検索されないという点に注意が必要である。それらのRowIDは、それぞれのフィールドごとに別々のアルゴリズムを通じてクエリーの一部分として作成される。未加工のデータを返すクエリーに関して、下記のアルゴリズムを使用することによって、RowIDが作成された。
【００８３】
CONVERT(binary, isnull(AccountCode, 0x0)) +
CONVERT(binary, isnull(SecurityCode, 0x0)) +
CONVERT(binary, -1)
【００８４】
第2のクエリーに関して、下記の関数によって、IDが作成された。
【００８５】
CONVERT(binary, isnull(AccountCode, 0x0)) +
CONVERT(binary, isnull(SecurityCode, 0x0)) +
CONVERT(binary,
CASE WHEN GROUPING(AccountCode) = 0 THEN 1
ELSE 0 END +
CASE WHEN GROUPING(SecurityCode) = 0 THEN 1
ELSE 0 END)
【００８６】
本発明の一実施形態によれば、シンクライアントグリッドの鍵となる特徴は、ユーザによる「オンザフライの変更」を含む任意のデータセットおよびグリッド表示構成をサポートすることができるという点である。本発明においては、動的なグリッドのプロパティーは、データソースおよびグリッドテンプレートという2つの要素を通じて決定される。データソースは、SELECTクエリー(FROM節)の内容を決定する。有効なデータソースは、レコードセットを返す任意のデータベーステーブル、データベースビュー、あるいはユーザ定義関数を含む。すべてのデータソースタイプは、タイプBINARYおよび列名UKeyの一意の行IDを返すこと(作成すること)ができなければならない。
【００８７】
下記のものは、2つのテーブルを結合して一意の行IDを作成するデータベースビューの一例である。
【００８８】
SELECT
CONVERT(binary(15), b.TaxLotID) AS UKey,
a.AccountCode, a.ShortName,
b.TaxLotID, b.SecurityCode, b.Quantity
FROM Account a
INNER JOIN TaxLot b ON a.AccountCode = b.AccountCode
【００８９】
この例においては、TaxLotIDが、基礎をなすTaxLotテーブルの1次キーであり、これは、このレコードセットの全体にわたって一意である。
【００９０】
グリッドテンプレート206bは、適切に形成された(1つまたは複数の)XMLファイルを含むことが好ましく、このXMLファイルは、データソースを参照し、最初の列順と、読み取り可能な列ヘッダと、列幅と、最初の並べ替えと、グループ分けおよび集約計算のようにシステムがオンザフライで実行しなければならない任意のさらなるオペレーションとを定義する。
【００９１】
このテンプレートのシンタックスの例は、下記のようなものとすることができる。
【００９２】
<?xml version="1.0" encoding="utf-8" ?>
<GridView table="<table｜view｜: ユーザ定義関数>">
<Fields>
<Field name="<データソース内の列名>"
type="<varchar｜int｜float｜...>"
function="<count｜avg｜sum｜min｜max>"
group="<on>"
header="<列ヘッダ>"
width="<幅(単位はピクセル)>"
tlb="<オブジェクト名>" fld"<オブジェクトプロパティー>"
readOnly="<false｜true>"
visible="<false｜true>"
sort="<false｜true>" />
...
</Fields>
</GridView>
【００９３】
上記の式では、
GridView要素は、データソースへの参照を定義する。
table-テーブル名、ビュー名、あるいは関数名。
それぞれのField要素は、動的なグリッド内の1つの列を定義する。
name-データソース内のフィールドへの参照。
type-列のデータタイプ。認識されているいかなるデータベースタイプとすることもできる。
function-集約関数。count、avg、sum、min、およびmaxという5つの集約関数のうちのいずれか1つ。この属性は、空とすることもでき、あるいは省略することもできる。
group-グループ分けのフラグ。この属性は、空とすることもでき、あるいは省略することもできる。
header-文字列のヘッダ。
width-最初の列幅(単位はピクセル)。
tlb-この列に関する値を提供するテーブル名(編集可能な列に関してのみ必要とされる)。
fld-この列に関する値を提供するフィールド名(編集可能な列に関してのみ必要とされる)。
readOnly-編集可能なフラグ。この属性が真であるか、空であるか、あるいは省略されている場合には、その列は、読み取り専用である。
visible-ビジビリティーフラグ。
sort-デフォルトの並べ替えフラグ(1つの列しか、このフラグを真にすることはできない)。
【００９４】
たとえば上記のSQLステートメントによって定義された、AccountMonitorという名前を有するデータベースビューが提供される場合には、適切なグリッドテンプレートは、下記の形式を有することができる。
【００９５】
<?xml version="1.0" encoding="utf-8"?>
<GridView table="AccountMonitor">
<Fields>
<Field name="AccountCode"
type="varchar" function=""
group="on" header="Account" visible="false"
tlb="Account" fld="AccountCode" />
<Field name="TaxLotID"
type="int" function="count"
group="" header="TaxLot ID" visible="true"
tlb="TaxLot" fld="TaxLotID" />
<Field name="SecurityCode"
type="varchar" function=""
group="" header="Security ID" visible="true"
tlb="TaxLot" fld="SecurityCode" />
<Field name="Quantity"
type="float" function=""
group="" header="QTY" visible="true"
tlb="TaxLot" fld="Quantity"/>
</Fields>
</GridView>
【００９６】
グリッドテンプレート206bは、どのようにデータを表示するか、およびどんな計算が行わなければならないかを記述することが好ましい。
【００９７】
また、アプリケーションテンプレート206a内にGridsセクションがあることが好ましく、そのGridsセクションでは、グリッドコンポーネントをアクティブにするために新たな参照を追加しなければならない。上述のテンプレートをアプリケーションリポジトリ内のファイルAccountMonitor.xmlと仮定する。
【００９８】
<Grids>
<Grid name="AccountMonitorGrid." そしてAcountMonitorGridを、下記のようにアプリケーションテンプレート(16)内のAccountMonitor.xmlと関連付けるべきである:
"xml="AccountMonitor.xml"/>
...
</Grids>
【００９９】
そしてグリッドコンポーネントコントローラ内のメソッドの初期化によって、下記のようにテンプレートがロードされることになる:
【０１００】
ViewUrl = FrontController.GetGridUrl("AccountMonitorGrid");
【０１０１】
ほとんどの投資分析アプリケーションは、データベースを複数のユーザによって共有している環境内で展開されなければならない。そのような環境においては、別々のユーザが、同じデータベースとの間で書き込みおよび読み取りを行っている可能性があり、重なっているデータセットを修正および分析している場合が多い。そのようなデータ更新は、さまざまなフロントエンドツールから生じる可能性がある。クライアントインターフェースアプリケーションによって提供される分析の整合性を維持するために、システムは、クライアントインターフェースアプリケーションに影響を与える基礎をなすデータに対する変更がいつ行われるかを把握して、その特定のクライアントインターフェースアプリケーションに、その特定のクライアントインターフェースアプリケーションの基礎をなすデータセットに対する当該更新について知らせることができなければならない。本発明は、通知サブシステムを介してリアルタイムにコンテンツの整合性を保持する。
【０１０２】
通知サブシステムは、一式のオブジェクトおよびアルゴリズムを含み、これらのオブジェクトおよびアルゴリズムは、基礎をなすデータがクライアントインターフェースに影響を与える場合に通知データを効率よく作成することができ、その通知データをクライアントインターフェースに伝達する。
【０１０３】
通知システムの構造およびオペレーションについて説明する際には、図2を参照する。
【０１０４】
通知システムは、複数のコンポーネントから構成されている。通知フレームワーク(202cおよび204b)は、クライアントの接続性、チャネルの移送、承諾および通知メッセージングのための一式のコンポーネントを定義する。通知コンポーネント(6)は、アプリケーションを通知システムに接続する。通知コンポーネントプロキシ(7)は、通知インターフェースを実装し、クライアントのコールをリモートオブジェクトへ転送する。
【０１０５】
通知リモートコンポーネント(10)は、通知システムとクライアントとの接続ポイントをサーバ側で確立する。このオブジェクトは、たとえば.NET REMOTINGを通じて利用可能とすることができる。通知コネクタ(11)は、メイン通知インターフェースを実装し、公開する。パブリッシャー(12)の通常のクラスは、非同期的な発行サイクルを提供する。
【０１０６】
通知モデル206cは、パブリッシャーが作成された時点での承諾およびデータベース通知のスナップショットを含む。これは、一式のオブジェクトおよびアルゴリズムであり、これらのオブジェクトおよびアルゴリズムは、通知データを効率よく作成することができ、その通知データをサブスクライバーに伝達する。通知モデル206cは、グリッドとデータベーステーブルとの間における相互関係を定義するXMLファイルを含むことが好ましい。
【０１０７】
データベース発行メカニズム(図示せず)は、通知システムに関連するデータベーステーブル、トリガー、およびストアドプロシージャーのセットである。このメカニズムによって、データの変更についてデータベースコンポーネントの外部に知らせることができる。
【０１０８】
データベーステーブルは、データベーストリガーを通じてプリミティブ通知を送信することができ、このデータベーストリガーは、変更されたレコードの1次キーデータをNSMessageテーブル内に反映する役割を果たす。このトリガーは、いくつかの修正されたデータをNSMessageテーブルへコピーするだけである。
【０１０９】
NSMessageテーブルは、下記のフォーマットを有することができる。
【０１１０】
【表１】
2009512947.tif 000003
【０１１１】
上記のテーブルで、MessageIDは、IDフィールドである。
【０１１２】
Activeは、1というデフォルト値を有する。レコードが作成されたとき、この値は、メッセージを発行する準備が整っているということを示す。パブリッシャー(12)は、1に等しいActiveフラグを有するメッセージをピックアップし、このフラグを0に更新する。これは、そのメッセージが発行の過程で保留中であるということを意味する。パブリッシャーは、発行されたプリミティブ通知メッセージを削除したり、あるいは発行プロセスが失敗した場合にはActiveフラグを1に戻したりする役割を果たす。
【０１１３】
DbObjectは、データベーステーブル名を含む。
【０１１４】
DbActionは、どんなデータベースオペレーションがこのレコードに対応するかを定義する。
【０１１５】
PrimaryKeyは、下記のようなコンマで区切られた1次キーデータを含む。
【０１１６】
<フィールド名>, <フィールドタイプ>, <フィールド値>
[,<フィールド名>, <フィールドタイプ>, <フィールド値>]
【０１１７】
PublisherIDは、ランダムに作成されたIDであり、パブリッシャーの識別子である。パブリッシャーインスタンスは、そのパブリッシャーが発行したプリミティブメッセージを認識することができる。
【０１１８】
通知トリガーは、INSERT/UPDATE/DELETEタイプとして定義することができ、下記のように実装することができる。
【０１１９】
CREATE TRIGGER [<テーブル名> Notification] ON [<テーブル名>]
FOR INSERT, UPDATE, DELETE
AS
DECLARE
<1次キーのための変数>
SELECT @action = <トリガータイプを定義する>
<トリガーが削除オペレーションによってコールされた場合には>
DECLARE Delta_<テーブル名>
CURSOR FOR Select <1次キー> FROM deleted
<トリガーが挿入または更新オペレーションによってコールされた場合には>
DECLARE Delta _<テーブル名>
CURSOR FOR Select <1次キー> FROM inserted
OPEN Delta _<テーブル名>
<loop through cursor>
<コンマで区切られた1次キーを作成する>
INSERT INTO NSMessage(DbObject, DbAction, PrimaryKey)
values( <テーブル名>, @action, <コンマで区切られた1次キー> )
<loop end>
CLOSE Delta_<テーブル名>
DEALLOCATE Delta <テーブル名>
【０１２０】
通知モデル206cの1つの目的は、データベーステーブルとグリッドデータソースとの間における相互関係を一般的に定義することである。通知モデル206cによって、グリッド通知要素に関して1対多の関係を築くことができる。グリッド定義に関する通知モデルのシンタックスは、たとえば下記のようにすることができる。
【０１２１】
<?xml version="1.0" encoding ="utf-8" ?>
<NotificationSchema notificationCheck="<通知期間>">
<NSObjects>
<NSObject name="<グリッドデータソース>">
<DomObjects>
<DomObject><データベース
テーブル名></DomObject>
<DomObject><データベース
テーブル名></DomObject>
<DomObject>... </DomObject>
</DomObjects>
<INSObject>
</NSObjects>
</NotificationSchema>
【０１２２】
NotificationSchema要素は、整数タイプの単一の属性を定義することができる。NotificationSchema要素は、システムがプリミティブデータベース通知をチェックするために強制する時間(秒)がどれぐらいかを判定する。
【０１２３】
NSObjects要素は、一式の通知オブジェクト(グリッド)を定義することができ、その場合、それぞれのNSObjectは、1つの通知オブジェクト(グリッド)を定義することができる。それぞれのNSObjectに関して一式の入れ子になったDomObjectsが存在することができ、これは、グリッドが関連しているデータベースオブジェクト(テーブル)の集まりを列挙する。下記のものは、グリッドの例に関する通知モデル定義の例である。
【０１２４】
<?xml version="1.0" encoding="utf-8" ?>
<NotificationSchema notificationCheck="20">
<NSObjects>
<NSObject name="AccountMonitor">
<DomObjects>
<DomObject>Account</DomObject>
<DomObject>TaxLot</DomObject>
</DomObjects>
</NSObject>
</NSObjects>
</NotificationSchema>
【０１２５】
この例は、AccountMonitorデータベースビューに基づくグリッドを定義する。このグリッドには、AccountテーブルおよびTaxLotテーブルの双方における変更が通知されることになる。
【０１２６】
本発明の一実施形態においては、通知コンポーネント(6)は、通知コンポーネントプロキシ(7)をホストするクライアント側での通知APIの実装とすることができる。通知コンポーネントオブジェクトは、フロントコントローラによって一枚札としてインスタンス化することができる。通知コンポーネントは、コンポーネントの観点からクライアント側での承諾APIを実装することができ、そしてまた、入ってくる通知メッセージを最終的な受け手(グリッドコンポーネント)へ回送することができる。
【０１２７】
通知コンポーネント(6)は、クライアント側での複数プロトコルの双方向の移送チャネルを実装することもできる。この通知コンポーネントは、サーバ側の当事者へ接続するために標準的なHTTPやTCPのチャネル(IV)を使用することができる。
【０１２８】
通知リモートコンポーネント(10)は、標準的なHTTPやTCPのチャネルプロトコルを使用して、サーバ側での複数プロトコルの双方向のチャネルを実装することができる。
【０１２９】
通知コネクタ(11)は、サブスクライバーおよびパブリッシャーによって、相互に通信するために使用されることができる。通知コネクタは、発行サイクルを実行するためにパブリッシャーオブジェクト(12)を(タイマに基づいて)インスタンス化する。通知コネクタは、通知システムへの最初の要求時に作成され、その通知コネクタの単一のインスタンスが終了した後に、すべての要求によって共有される。通知コネクタは、通常のHTTP要求(V)を使用して、通知モデル(206c)をロードする。
【０１３０】
通知モデル(206c)は、XMLファイルを通じて実装することができ、これは、データベーステーブル(プリミティブオブジェクト)とグリッド(ビジネスオブジェクト)との間における相互関係を定義する。通知モデルは、ドメインモデル内で「通知可能な」オブジェクトを動的に定義できるようにする。
【０１３１】
パブリッシャー(12)は、通知スナップショット(13)を使用して通知サイクルを決定するオブジェクトである。パブリッシャーは、パブリッシャーが最後に呼び出されてからシステムが収集したメッセージを作成する(パブリッシャーは、通知コネクタによってタイマに基づいてインスタンス化される)。データベースから更新を検索するために、パブリッシャーは、持続層オブジェクト(14)をインスタンス化する。
【０１３２】
パブリッシャーインスタンスによって通知スナップショット(13)を構築することができ、その目的は、プリミティブデータベースデータの変更と、そのスナップショットが作成される時点までにはシステム内に存在している承諾との間における相関関係を見つけ出すことである。このスナップショットはまた、更新されたデータをデータベースからロードするための、および通知メッセージをクライアントへ押し出すための効率のよいアルゴリズムを提供する。通知スナップショットは、一方の側では通知モデルから生じるデータおよび承諾スナップショット(システム内で定義されている承諾)と、別の側からはプリミティブデータベース更新メッセージとによって提供される。これらのデータエンティティーどうしの間における相関関係を見つけ出すことが、通知スナップショットの目的である。持続層(14)は、状態の更新をデータベース(15)からロードする。
【０１３３】
図4は、グリッド構成設定画面400のスクリーンショットであり、このグリッド構成設定画面400によって、グリッドの表示に関する設定パラメータを使用できるようになる。たとえば、設定画面400は、一般的な設定構成402と、フィールド構成404と、フィルタリングパラメータ406と、アカウント情報408とを使用しない。図示されているように、このフォームは、設定サブスクリーン402〜408の間におけるナビゲートを行うためのタブスタイルのナビゲーションを含む。FIELDSサブスクリーン404が、図4に示されている。ブロック404a内に列挙されている利用可能なフィールドは、表示ボックス404cへ、あるいはグループ分けを可能にする表示ブロック404bへ、ドラッグアンドドロップすることができる。個々の属性も、調整することができる。ユーザ構成情報は、アプリケーションリポジトリ内の1つまたは複数のテンプレート内に保存されることが好ましい。
【０１３４】
図5は、本発明の一実施形態によるシステムのブロック図である。このシステムは、既に上述したようにユーザアプリケーションを実行する1つまたは複数のユーザクライアントデバイス202を含むことができる。それぞれのクライアント202は、電子データネットワークに結合されている。アプリケーションサーバ204、リポジトリ206、およびデータベース208も、電子データネットワークに結合されており、既に上述したように機能する。この電子データネットワークは、任意の数の安全なまたは独自仕様のデータネットワーク、インターネットなどの公開されたネットワーク、あるいはそれらの組合せを含むことができる。
【０１３５】
デバイス202、204、206、および208のそれぞれは、適切なオペレーティングシステムと、本明細書に記載されている機能を実行するためのその他のソフトウェアとを装備したコンピュータプロセッサ、パーソナルコンピュータ、スタッカブルプロセッシングユニット、サーバデバイスなどの1つまたは複数の物理的なデバイスによって実装することができる。通信デバイスは、HTTPメッセージングやイーサネット(登録商標)プロトコルなどの公知のネットワーキング手段によって促進され得る。本発明は、いかなる形であれ、図5に示されている構成に限定されることを意図するものではない。
【０１３６】
このように、複数の好ましい実施形態について、図面を参照して十分に上述した。本発明について、これらの好ましい実施形態に基づいて説明したが、本発明の趣旨および範囲内でこれらの説明した実施形態に対して特定の修正形態、変形形態、および代替構成を作成することができるということは、当業者にとって明らかであろう。
【図面の簡単な説明】
【０１３７】
【図１】本発明の一実施形態によるグリッドを有するクライアントGUIインターフェースを示すスクリーンショットである。
【図２】グリッドアーキテクチャーと、基礎をなす通知メカニズムとを詳細にコンポーネントレベルで示す図である。
【図３】本発明の一実施形態によるページングアルゴリズムを示す図である。
【図４】ユーザ駆動型の構成パラメータを収集する設定画面を示す図である。
【図５】本発明の一実施形態によるシステムを示すブロック図である。
【符号の説明】
【０１３８】
1    グリッドベースのコンポーネント
2    動的なグリッド
3    動的なグリッドコントローラ
4    フロントコントローラ
5    ページマネージャープロキシ
6    通知コンポーネント
7    通知コンポーネントプロキシ
8    ページマネージャーリモートコンポーネント
9    クエリージェネレータ
10    通知リモートコンポーネント
11    通知コネクタ
12    パブリッシャー
13    通知スナップショット
14    持続層(ORM)
15    データベース
202    アプリケーション
202a    アプリケーション
202b    MVCフレームワーク
202c    クライアント側通知フレームワーク
204    アプリケーションサーバ
204a    ページマネージャー
204b    サーバ側通知フレームワーク
206    アプリケーションリポジトリ
206a    アプリケーションテンプレート
206b    グリッドテンプレート
206c    通知モデル
208    データベースサーバ
【図１】
2009512947.tif 000004
【図２】
2009512947.tif 000005
【図３】
2009512947.tif 000006
【図４】
2009512947.tif 000007
【図５】
2009512947.tif 000008
【国際調査報告】
2009512947.tif 000009