JP2011513825A - 膨大な数の処理命令のリアルタイム処理に関する改良 - Google Patents

Abstract

極めて多数の処理命令を処理セッション中にリアルタイムに処理及び操作するシステム（１５０）が開示される。各処理命令は２つの異なるエンティティ（１４，１６）に関するリソースアカウントデータファイル（３０）及びこれらのファイル（３０）間で交換されるリソースの量（額）及びタイプを指定するものである。本システムは、前記処理命令に関連するリファレンスデータを取得するプリローダ（１５２）を備え、前記リファレンスデータは指定されたリソースアカウントデータファイルの各々の現在値を示し、前記プリローダはマスタデータベースから複数のそれぞれの受信処理命令に対するリファレンスデータを並列に読み出すように構成され、更に複数の前記処理命令をそれらのそれぞれプリロードされたリファレンスデータと一緒にキューイングするエンリッチ命令キュー（１６６）と、受信した前記リファレンスデータを用いて、各受信処理命令を関連するリソースアカウントファイルの現在値に基づいて実行できるかどうかをシーケンシャルに決定し、各実行可能な処理命令に対して更新コマンドを発生するように構成された実行エンジン（１５４）と、前記実行エンジン（１５４）からの前記更新コマンドに応答して、前記マスタデータベース（２４）を各実行可能な命令の結果で更新する複数のアップデータ（１５８）とを備え、前記複数のアップデータの動作が前記実行エンジンの動作から分離されている。

Description

本発明は、膨大な数の処理命令のリアルタイム処理の改良に関するものである。より詳しくは、本発明は、毎秒何百もの命令の処理を最適化するように特別に設計されたコンピュータ処理アーキテクチャに関するものであるが、これに限定されない。

膨大な数の処理命令をリアルタイムに処理する問題に取り組む様々なアプローチが存在している。これらのアプローチのすべては膨大な数の命令の処理に成功しており、この成功の大半はより高速でよりパワフルな演算を使用する処理システムに依存している。しかし、このようなアプローチに基づくアーキテクチャは、このようなシステムの最大可能なスループットを制限するなど、いろいろの点で制限を受ける。

このような技術にはいくつかの応用分野があり、例えばマスデータ通信システム及びデータ処理システムなどがある。このようなデータ処理システムの一つの非限定的な例は取引決済システムであり、このシステムでは異なるパーティ間の契約(agreement)を表すデータ命令メッセージを、当該契約の実際の決済又は実行を達成するために実行することができる。その一例が以下に詳細に記載されるこのような契約においては、信頼できる決済エンティティコンピュータへの命令(又はコマンド)は、決済エンティティコンピュータにより決定される条件（規則）がこれらの命令の実行を許す場合にのみ処理され得る。従って、プロセスの第１の部分として、リソースに対する電子データファイルの現在状態について検査を行う必要があり、これは和解契約の主部である。これらの検査は、命令の実行が電子データアカウントファイルに与える影響を許容し得るかどうかを決定する。

プロセスの第２の部分において、命令は、実行が許可される（「コミット」という）か、実行が拒否される（「ロールバック」という）かのいずれかである。もっと具体的にいうと、この非限定的例では、命令を電子データアカウントファイルに許容し得ないポジションを生じることなく実行できるかどうかを決定するために、両パーティのリソースアカウントファイルのポジションが決済エンティティコンピュータにより評価される。条件が適合する場合には、データレコード内に含まれる命令（コマンド）が実行され、次いでリソースアカウントの現在のポジションを格納するデータファイルが更新される（コミット）。条件が適合しない場合には、命令はこの時点で実行されずに電子データアカウントファイルはそのまま維持される。また、第１段階が、電子データアカウントファイル上の結果ポジションが許容し得ないことを示す場合には、すべてのアカウントをデフォルトとして更新し、更新を無効にすることもできる（ロールバック）。これは、高いスループットシステムに対して好適なオプションである。条件が失敗した命令に対して変化したら、ロールバックされたデータ命令を再利用し、関連するコマンドをその後の段階で再試行することができる。更に、そのすべてを契約に関係するパーティのコンピュータに、多くの場合リアルタイムに、報告する必要がある。

このようなデータ処理の実行の特性の一つは、これまで、提案されている解決方法のスケーラビリティを制限しており、それはこれらの命令を実行するために評価する必要がある異なるリソースの数が多くの場合命令の増加する数とともに増加しなくなることにある。これは、多くの場合、命令の数の増加とともに命令の実行が所定数のリソースに集中するためである。この集中は、リソースアカウントファイルの値に影響を与える各命令が、次の命令の前に、当該アカウントを処理できることを指定する値を更新する必要があるために問題になる。典型的には、これは、プロセスが所定のリソースアカウントファイルの値の検査及び更新である間に、所定のアカウントファイルの一時的独占性（ロッキング）を取る特定の命令によって達成される。次の命令を処理できる前の所要の更新は、これらの増加した数の命令を処理できる最大速度への直接影響を有する。これは、多くの異なるタイプの命令に共通のエンティティのリソースにとって厳しい問題となる。これは、特に、命令の５０％がリソースアカウントの５％のみを更新する場合（高い集中状態とみなせる）に、特に厳しい問題となる。

この非限定的な例は、実行すべき命令に対してファンドが有効であるかどうかを確かめるためにエンティティに対するキャッシュアカウントを格納するデータファイルを検査する必要があるときに、理解することができる。各命令に対するこのリソースのアカウントの検査は、前命令がその命令の実行の結果としてキャッシュアカウントポジションを更新した後に実行する必要がある。それゆえこれらのプロセスはシーケンシャルにする必要があり、さもなければ当該アカウントのバランス（残高）を変化させるかもしれない一つの命令の実行の作用が当該アカウントへのアクセスを必要とする次の命令を無効にし得る。従来のアーキテクチャ（以下に記載する）の最大処理速度はすべてこの問題により制限される。

同時処理アーキテクチャが使用されている従来のシステムに生じる別の問題は「デッドロック」である。この問題を含む状態は、２つの同時の命令が同じ２つのアカウントにアクセスする場合に生じ、一方の命令が一方のリソースアカウントをロックし、他方の命令が他方のリソースアカウントをロックする。これは、各命令に対して、その命令を実行すべく、検査のために他方のアカウントにアクセスすることを阻止する。両命令が待ち状態になり、両命令が命令の処理のためにコミット(実行)操作を実行するのを阻止する。一方の命令のロールバックは他方の命令の処理を開放し、常に可能であるが、この解決方法は命令処理のスループットを大幅に減少する。

電子アカウントファイルを検査し更新する基本プロセスは単一の命令に対してはあまり重要でないように思われるが、１日につき何百万ものこのような命令の処理はこの解決方法を重要なものとする。決済エンティティにより使用される如何なるシステムの目的も、リアルタイムに可能な最高のスループットを達成することにある。いかなる解決方法のスケーラビリティも、任意の処理ステップの如何なる小さな時間の節約も大量の命令処理のために多数倍に増大されるので、極めて重要である。

このような決済プロシージャを実施する多くの従来のシステムが開発され、このようなシステムの典型的な例が図１〜図５を参照して以下に記載される。

図１を参照すると、１日につき何百万もの命令データメッセージを取り扱うように構成された従来の汎用中央リソース管理システム１０が示されている。システム１０は、専用リース通信ライン又は他のタイプのセキュア通信チャネルとし得る種々の通信チャネル１２に結合される。システム１０はこれらのチャネルを介して多くの異なるパーティのサーバに接続される。この実施例では、説明を容易とするために、システム１０はパーティＡのサーバ１４及びパーティＢのサーバ１６に接続される。パーティＡのサーバ１４及びパーティＢのサーバ１６はそれぞれのデータベース１８，２０のレコードにアクセスすることができ、各レコードは別のパーティとの契約を記述する。

中央リソース管理システム１０は、典型的には命令実行サーバ２２を備え、該サーバはすべてのパーティ（即ち本例ではＡ及びＢ）のリソースアカウントを表すデータレコードを含むマスタリソースデータベース２４にアクセスすることができる。

図２を参照すると、各パーティに対するマスタリソースデータベースの構造の概略的表現が示されている。データベース２４は、各パーティに対する複数の異なるタイプのリソースアカウントファイル３０と、当該パーティに対する集計（aggregated）リソース値のインジケータ３２とを備える。この特定の実施例では、命令データメッセージの各々は、これらのアカウントファイル３０にコマンド又は命令を実行するように指示し、典型的には一つのパーティのアカウントから別のパーティのアカウントへリソースを移動させ、これに応じて集計リソース値インジケータ３２を更新するように指示する。アカウントはパーティ１４，１６の実際のリソースを表すデータファイルである。リソースはパーティの任意のリソースとすることができる。本例では、それらのリソースはパーティが所有するものであって該パーティが取引したいものである。

次に図３を参照すると、命令データメッセージ４０の一般構造又はフォーマットが示されている。命令データメッセージ４０は、本質的に、命令を実行するために必要な６個の基本フィールドを有する。命令データメッセージ４０は命令に対するパーティを識別するためのパーティＩＤフィールド４２を有する。本例では、命令データメッセージ４０はパーティＡ及びパーティＢを識別することができる。この命令メッセージ４０を実行すべき日時を規定するために実行日フィールド４４が付与される。残りの４つのフィールドは命令の主部であり、リソースの詳細を特定する。第１リソースタイプフィールド４６及び対応する第１リソース数量フィールド４８は、第１パーティ（例えば、パーティＡ）のリソース及び命令に含まれる当該リソースの数量（額）を特定するために付与される。第２リソースタイプフィールド５０及び対応する第２リソース数量フィールド５２は第２パーティ（例えば、パーティＢ）のリソース及び命令に含まれる当該リソースの数量（額）を特定するために付与される。

２つのパーティ間の各契約に対して、２つの命令データメッセージ４０（各パーティに対して一つずつ）が存在する。

図４は、図１の従来の命令実行サーバ２２のコンポーネントを示す。これらのコンポーネントは、受信した命令データメッセージ４０の妥当性を検証するように構成された命令検証器６０と、同じ契約に関連する２つの異なる命令データメッセージ４０を照合する命令照合器モジュール６２とを含む。命令照合器はまた、合致した命令データメッセージ４０に対して決済命令を生成する。更に、現在時間を新たに生成された決済命令と関連する時間と比較するためにタイミングモジュール６４が設けられる。タイミングモジュール６４は、更に、各パーティのリソースアカウントファイルへのアクセスのための時間窓が開いているか閉じているかを決定することができる。決済命令を今後の実行のために格納するために命令データベース６６も設けられる。命令実行サーバ２２は、更に、情報メッセージを関連するパーティへ通信する報告モジュール６８を備える。最後に、命令実行サーバの心臓部として、命令検査、実行及び更新エンジン７０が設けられる。報告モジュール６８は命令検証器６０、命令照合器６２及び命令検査、実行及び更新エンジン７０に結合される。命令が処理される手順は命令検査、実行及び更新エンジン７０の特定のデータ処理アーキテクチャにより決まり、これは（以下に記載するように）様々な従来の装置の間で相違する。

次に、命令実行サーバ２２の動作が図５のフローチャートについて説明される。ポジショニングエンジン７０において命令（決済命令）を実行することにより命令データメッセージ４０を受信し、検証し、照合し、更新し、更新の結果を報告するステップが以下に詳細に説明される。もっと正確にいうと、従来の命令実行サーバ２２の一般的な操作７８はステップ８０で開始し、サーバ２２は通信チャネル１２に接続され、命令データメッセージ４０の受信が可能である。次にパーティＡがステップ８２においてパーティＢとの契約を記述する命令データメッセージ４０をサーバ２２に送る。同様に、パーティＢがステップ８４においてパーティＡとの契約を記述する命令データメッセージ４０をサーバ２２に送る。サーバ２２において、メッセージ４０が受信され、命令検証器６０がステップ８６において、受信された各命令を検証しようと試みる。この検証がステップ８６において失敗すると、この失敗はステップ９０において報告モジュール６８に通知され、報告メッセージ（図示せず）がステップ９０において無効とされた命令データメッセージ４０の発信元に送付される。

反対に、有効な命令データメッセージ４０に対しては、報告モジュール８６はステップ９２において有効な命令メッセージ４０の発信元に、命令データメッセージ４０の受信及び検証有効を示す肯定メッセージを返送するように命令する。

有効な命令メッセージ４０は命令照合器６２へ渡され、ステップ９４において同じ契約を記述する対応する２つの命令データメッセージ４０を照合する試みが行われる。

命令照合器６２は、ステップ９６において、異なるメッセージ４０を照合しようと試みる。ステップ９６における照合検査が失敗すると、この失敗はステップ９８において報告モジュール６８に通知され、ステップ９８において報告メッセージ(図示せず)が合致しない命令データメッセージ４０の発信元に送られ、プロセスはステップ１００で終了する。この失敗は従来のシステムの説明を簡単にするために極めて簡単に示されている。しかし、実際には照合の失敗は多くの試みの後、おそらく数日かもしれない設定照合期間の満了後にのみ到達する結論である。

ステップ９６において決定された合致した命令メッセージ４０は報告モジュール６８に通知され、このモジュールが次いでステップ１０２において合致した命令データメッセージ対の存在を合致した命令データメッセージの発信元（本例ではパーティＡ及びパーティＢ）に報告する。更に、命令照合器６２はステップ１０２において実行日を有する実効命令（決済命令）を生成する。この実行日はステップ１０４において合致した命令データメッセージ４０のいずれか一方の実行フィールドの日時（両方とも同じであるため）から得られる。決済命令の実行日は次にステップ１０４において現在時間および（タイミングモジュールにより決定される）実行時間窓の有効性と比較される。

ステップ１０６で決定される比較の結果が、決済命令は現在実行不可能である場合には、決済命令はステップ１０８において命令データベース６６に格納される。データベース６６は定期的に検査され、プロセス７８はステップ１１０において、実行日になるまで待ち、実行時間窓を開く。典型的には、実行時間窓は毎日数時間開くことができる。

また、ステップ１０６で決定される比較の結果が、決済命令は今実行可能である場合には、決済命令は格納されない。

命令実行サーバ２２の一般的な操作７８の次の段階は、ステップ１１２において、決済命令を命令検査、実行及び更新エンジン７０（ポジショニングエンジンともいう）に送る。ポジショニングエンジン７０は一組の実行規則７２と関連する。これらの規則７２は、決済命令を実行できるかどうか、つまり、リソースアカウントファイル３０及び集計リソース値３２に対する決済命令の結果を受諾できるかどうかを決定する。受諾できない条件の一例は、特定のリソースアカウントファイル３０又は集計リソース値３２がコマンドの実行の結果として所定額より低い値になる場合である。上述した非限定的な取引決済システムの実施例では、リソースアカウントは現金及び担保アカウントとすることができ、集計リソース値はクレジットライン（貸付限度額）とすることができ、この場合リソースは与えられるクレジット（貸付金額）に対する保証として作用するので、リソースの現在値は所定の貸付金額を提供する。

ポジショニングエンジン７０は、ステップ１４１において、もしコマンドが実行された場合に実行規則７２が依然として満足されるかどうか、即ち２つのパーティのリソースアカウントファイル３０及び集計リソース値３２に対して得られる結果が許容できるかどうかを検査する。

実行規則がステップ１１６において満足されないと決定されると、プロンプトが報告モジュールに送られ、ステップ１１８において報告モジュールは、失敗した決済命令に対して不成功結果を両パーティ（例えば、本例ではパーティＡ及びパーティＢ）に報告するメッセージを生成し送付する。次に、失敗した決済命令はステップ１２０においてポジショニングエンジン７０にとどまり、決済のために後刻／後日に再試行される（ステップ１１４−１２６を反復する）。

実行規則７２がステップ１１６において満足されると決定されると、決済命令はステップ１２２で実行される。このとき、ポジショニングエンジン７０はステップ１２４において、リソースアカウントファイル３０の現在のポジションを実行された決済命令の結果で更新する。つまり、リソースアカウントファイル３０及び集計リソース値３２はリソースの移動が行われた後に正しいバランスで更新される。最後に、報告モジュール６８がステップ１２６において、成功決済命令に対して決済の成功結果を両パーティ（例えば、本例ではパーティＡ及びパーティＢ）に報告するメッセージを生成し、送付するように命令される。

決済命令の成功した実行は、従来の命令実行サーバ２２の一般的な操作７８を当該単一命令に対して閉じる。しかし、何百万もの命令が毎日処理されているので、プロセス７８は多くの異なるパーティのサーバから絶えず受信される他の命令データメッセージ４０に対して継続する。

以上述べたように、決済命令が処理される手順は命令検査、実行及び更新エンジン７０の特定のデータ処理アーキテクチャにより決まり、これは従来の異なるシステムの間で変化する。本質的に、２つの異なるアプローチ、即ちバッチプロセス及び並列入力照合プロセスが存在し、次に両プロセスがそれぞれ図６及び図７を参照して説明される。

バッチプロセスは標準のシーケンシャル更新アプローチであり、このアプローチでは実効命令がシーケンシャル処理のために格納され、自動的に連続的に実行される。このプロセス１３０は図６に概略的に示され、新命令（決済命令）のバッチ（シーケンシャルセット）を含む新命令ファイル１３２が、すべてのリソースアカウントファイル３０の現在のポジション及び任意の集計ポジション３２を格納するマスタファイル１３４と一緒に与えられる。

各決済命令は、図３につき述べたように、契約に関係する２つのパーティ、リソースアカウントファイル３０、パーティ間の契約の主部であるリソースの数量及び実行時刻／日を特定する。このタイプの処理アーキテクチャの重要な特徴は、これらの決済命令をそれらが関連するリソースアカウントの順にリストアップする必要があることである。典型的には、各命令に相互参照を助けるシーケンスキーが付与される。

マスタファイル１３４もまた上述のシーケンスキーを用いてリソースデータアカウント３０を順にリストアップする。このマスタファイルと入力データファイルとの間の順序の一致はバッチ処理にとって極めて重要である。

シーケンシャル更新プログラム１３６は、各契約が対応する命令の決済により実行され得るか同化を決定するために設けられている。処理エンジン（図示せず）で実行されるシーケンシャル更新プログラムは、照合アルゴリズムと呼ばれる標準のアルゴリズムを用いる。上述したように、照合アルゴリズムは、両入力ファイル（現存するマスタポジションファイル１３４及び新命令ファイル１３２）が同じ順序のシーケンスキーで格納されていることを要求する。命令ファイル１３２で使用されるキーは「トランザクション」キーと呼ばれ、現存するマスタファイル１３４に格納されるキーは「マスタ」キーと呼ばれる。

シーケンシャル更新プログラム１３６は両ファイル１３２，１３４を両ファイルの終わりまで順に読み取るようにロジックを定義する。シーケンシャル更新プログラムの結果は新マスタファイル１３８に格納され、このファイルはパーティのすべてのリソースアカウントファイル３０及び集計ポジション３２の更新されたポジションを保持する。

シーケンシャル更新プログラム１３６は、各ファイル１３２，１３４の第１の命令又はレコードを読み込むことによって開始する。所定のリソースアカウントファイル３０に関連する命令のすべてがシーケンシャルに実行され、リソースアカウントファイル３０の値の各変化が照合アルゴリズムを実行する処理エンジンのメモリにおいて更新される。特定のリソースアカウントファイル３０に対する更新が完了すると（次の命令に対するトランザクションキーの変化により検知される）、当該リソースアカウントファイル３０に対して得られた値が任意の更新された集計ポジション３２と一緒に新マスタファイル１３８に書き込まれる。このプロセスは異なるリソースアカウントファイル３０ごとに、トランザクションファイル１３２の終わりに到達するまで、繰り返される。

一つの命令を実行するために多数のリソースアカウントを更新する必要がある場合、もっと洗練されたアプローチが使用される。多数のアカウントの更新を処理するために、更新は複数の段階に分解される。この解決法は、リソースアカウント値のデビットを最初のランでのみ実行し、デビットが成功した場合命令をリソースアカウントのクレジットの順に、クレジットを対応するリソースアカウントに供給する前に、報告する。リソースアカウントのクレジット支払いが遅れたために失敗した命令によって問題が生じるが、これは多数のランを行うことで解決される。

シーケンシャル更新プログラム１３６は、典型的には、次のケースを処理するようにロジックを定義する。
トランザクションキー＝マスタキー→現在の命令をリソースアカウントファイルの現在のマスタデータレコードに適用する
→現在のリソースアカウントの新ポジションを更新されたマルチレコードとしてメモリに格納する
→次の命令を読み込む
トランザクションキー＞マスタキー→更新されたマスタデータレコードを新マスタファイル１３８に書き込む。
→マスタデータレコード（有効であれば）を回復させる、または、次のマスタデータレコードに対してマスタファイルを読み込む
トランザクションキー＜マスタキー→現在のマスタレコードを格納する
→デフォルトマスタレコードを生成する
→トランザクションファイルから次の命令を読み込む、または、
→対応するマスタファイル情報が存在しない、即ちアカウントリソースファイル３０がマスタファイル１３４に見つからないために命令を除去する
→次の命令を読み込む

これが行われると、次の命令レコードがトランザクションファイル１３２から読み込まれ、トランザクションキーが現在のマスタキーより大きくなるまで同じプロセスが繰り返される。

このアルゴリズムでは、メモリ内の単一のプロセスが多数の更新を新マスタファイル１３８に収集するので、命令の高速処理を提供すること明らかである。制限は、プロセスを実行する前に、すべての命令をグループ化し、ソーティングする（バッチ）必要があることである。更に、命令の実行を確認する第１の応答メッセージをパーティに返送する前にすべての命令が処理されなければならない。更に、バッチプロセスにおいては、照合アルゴリズムを実行しながらデータを他のプロセスのために使用することはできない。データへのリアルタイムアクセスを提供するために、データベースの更新が必要とされる。これらのデータベースの更新は、直接実行すると、プロセスの総合スループットを大きく損なう。実行後に追加のステップで実行される場合（例えばＤＢ２ロードユティリティ）、この時間中データへのすべてのアクセスが阻止される不利がある。この結果として、バッチ処理は実行中極めて効率的であるが、実行前にグループ化及びソーティングを必要とするためにリアルタイムに実行することはできない。

別の代替アプローチ、即ち上述した並列入力照合アプローチが図７に示されている。このアプローチにおいては、命令照合器６２により生成される決済命令は複数の個々の命令操作コンピュータ又はプロセス１４０，１４２により操作される。シーケンシャルファイル操作プロセス１４４は命令データベース６６に格納されている命令のバッチを操作することができる。各プロセス１４０，１４２，１４４は直接更新プログラム１４６の自己バージョンを有し、該プログラムは現在のリソースアカウント３０及び集計リソース値３２の値を読み込み、マスタデータベース２４内のパーティのリソースアカウントに対する直接更新命令を生成する。単一命令実行マネージャ１４８は、プロセス１４０，１４２，１４４からの受信命令によってデータベース２４の更新について最終判断を行うために設けられている。命令実行マネージャ１４８は一組の実行規則７２（図４参照）を用いて更新命令の実行をコミットするか後の実行のためにロールバックを行う。

命令実行マネージャ１４８が実行しなければならない実行規則７２の一つはロックアウトの問題に対処するものである。前述したように、ロックアウトは、リソースアカウントファイル３０へのアクセスが別の更新命令に対して使用されている最中であるために阻止される場合である。実際には、これは、特定のリソースアカウント３０を更新する競争が、リソースアカウントファイル３０が前更新命令から開放されるまで、即ち前更新が完了するまで待ち状態の挿入によって処理されることを意味する。このようにすると、命令実行マネージャ１４８は２つの異なる更新命令が同じリソースアカウントファイル３０を並列に変更することを阻止する。

各プロセス１４０，１４２，１４４は並列にランし、単一プロセスより広い帯域幅を提供し、より大きな潜在的スループットをもたらす。もっと詳しく言うと、更新が多数の異なるリソースアカウントファイル３０に分散される場合、並列システムはスケーラブルになる。このような環境の下では、多数の更新プロセス１４０，１４２，１４４を並列にランさせることによってシステムのスループットを増大することができる。しかし、更新が十分に分散されない場合、データ完全性を保証するためのロックアウトプロセスの実行はシステムが到達し得る最大スループットを急速に制限する。この限界に到達すると、使用不能（ロックされた）リソースアカウントファイル３０に対する他の更新命令の待ち時間が増大するため、一つ以上の更新プロセスのランは総合スループットを増大しなくなる。

このアプローチはリアルタイム更新のために優れているが、多くの状態の下でスループットの低下を被る。これは、通常、更新は多数の異なるリソースファイル３０に分散されないためである。むしろ、多くのアプリケーションにおいては、一般に所定のリソースアカウントが多くの異なる命令により頻繁に使用されている。例えば、取引決済の分野では、一般に命令の５０％が利用可能なリソースアカウントファイルの５％に集中している。これらの状況の下では、図７のリアルタイム処理技術は性能不足である。

考慮すべき別の問題は、失敗した命令を再利用する問題である。リソースアカウントが実行規則を満足する所要の値を持たないために特定の瞬時に実行できなかった命令は後刻の別の実行試みのために単に格納される。一時的失敗の各々は命令装置に報告し、いったんリソースアカウント状態が変化すればその命令はまもなく実行できることを指示することができる。

この従来の再使用プロセスは実行エンジンへの新命令の提出の数を減少させるのに有用である。命令を「ペンティング」として保持することによって、状態の変化時にそれが処理されるチャンスが大きくなる。処理する命令の量を考えると、殆どの再使用命令が最終失敗として報告する必要なしに実行される確率が高くなる。

しかし、再使用は実行エンジンのスループットが再使用プロセスにより低下される問題をもたらす。特に、並列入力である場合、多数のリソースアカウント移動を記述する命令は、多くの場合、再使用期間（タイムアウトの発生前）内にそれらの実行条件にならないので、失敗する。シーケンシャル入力の場合には、失敗は、失敗した命令を操作するために必要とされる多数のランをもたらすことになり得る。

これらの問題を克服しようと多くの努力がなされている。また、これらの問題を解決するために多大なお金と資源が費やされている。これらの努力にもかかわらず、命令処理アーキテクチャにおけるスループット対リアルタイム処理の問題はそのままである。

これらの問題を明らかにするのに役立つ様々な従来の技術が下記の文献に開示されており、これらの文献が公知になってから長い時間たつが実行可能な解決手段は見つかっていない。

KAl LI ET AL'Multiprocessor Main Memory Transaction Processing" 19881205; 19881205-19881207, 5 December 1988, pages 177-187, XP010280434. GARCIA-MOLINA H ET AL: 'MAIN MEMEORY DATABASE SYSTEM:AN OVERVIEW<1> IEEE TRANSACTIONS ON KNOWEDGE AND DATA ENGINEERING, IEEE SERVICE CENTRE, LAS ALAMITOS, CA, US, vol. 4, no.6, 1 December 1992, pages 509-516, XP001 167057 ISSN: 1041 -4347. GRAY J ET AL: "Transaction processing: concepts and techniques, PASSAGE' 1 January 1993, TRANSACTION PROCESSING: CONCEPTS AND TECHNIQUES, PAGE(S) 249 - 267, 301 , XP002323530. GRAY J ET AL: "Transaction processing: concepts and techniques' 1 January 1993, TRANSACTION PROCESSING: CONCEPTS AND TECHNIQUES, PAGE(S) 333 - 347, 496, XP002207245.

本発明は、上述した問題の少なくともいくつかを克服し、極めて多数の処理命令をリアルタイムに処理及び操作する改善されたシステムを提供しようとするものである。

本発明の目的を更に詳細に考察する前に、任意の命令処理アーキテクチャのいくつかの重要な特性を理解することが重要であり、それらを以下に示す。

新システムの各々は特定のスループット要件を有する。スループットはシステムの目的を達成するためにシステムが所定の期間内に実行すべき命令の数を表す。スループットは１日、１時間、１分間又は１秒間当たりの命令処理数で表される。スループットは、１００命令／秒より大きいとき、「高スループット」と規定される。

処理アーキテクチャを命令プロセッサのシングルインスタンスで実現するシステムにおいては、プロセッサは所要のスループットを達成できる必要がある。しかし、シングルプロセッサでこれを達成できない場合、目的を達成できるように複数インスタンスのプロセッサで命令を並列に処理する必要がある。後者の場合には、総合スループットは各インスタンスにより達成されるスループットの和である。命令実行プロセスが複数の順次のステップからなる場合、総合命令実行プロセスのスループットは最も弱い（最も遅い）ステップ（例えばボトルネック）のスループットにより決まる。

新システムの応答時間は、第３パーティのサーバからの入力命令実行要求の受信と該サーバへの関連する応答の返送との間の経過時間を表す。５秒未満の平均応答時間を有する命令処理システムはリアルタイムシステムと規定することができる。命令プロセッサのシングルインスタンスをランしているとき、応答時間は要求を処理する時間（要求を読み込み、命令を実行する時間）及び応答を送る時間（応答を生成し,それを送る時間）として測定することができる。要求がシステムのスループットより高いレートで到来する場合、要求の待機が起こる。この場合には、要求がキューで費やす時間を該要求に対する総合システム応答時間の一部分とみなす必要がある。命令プロセッサが複数の処理ステップからなる場合、システムの総合応答時間は複数のステップの各々の応答時間の和として計算される。

典型的には、各命令処理システムは何百ものパーティで動作し、各パーティに対して局所的に格納された対応するリソースアカウントを有する。各パーティは多数のリソースアカウント（数十及び数百も珍しくない）を持ち得るので、命令が関係するリソースアカウントは多数のリソースアカウントファイルに均等に広がる。しかし、命令処理システムのいくつかの特定のアプリケーションにおいては、要求は、小さな組のリソースアカウントファイルが命令に頻繁に含まれ、それらが高い周波数で更新されることになる。命令処理システムにおける命令の集中により、小さな組のリソースアカウントファイルが処理された命令に含まれる頻度が決まる。５０％の命令が５％のリソースアカウントファイルを更新する命令処理システムは高い集中を有すると規定される。

上記の特性を前提にすると、本発明の別の特定の目的は、リアルタイム（上で定義済み）に動作し、高いスループット（上で定義済み）を有し、高い集中（上で定義済み）を操作しうる命令処理システムを提供することにある。

本発明は、高い命令の集中を処理しうるリアルタイム命令処理システムにおいて極めて高速のスループットを達成しようとする際に、従来のアプローチの制限をある程度評価することにある。本発明者等は、高い集中を処理でき且つリアルタイムに動作できる、膨大な数の命令に対する最適化されたデータ処理アーキテクチャを提供するために、普段はシーケンシャル処理が必要且つ必然である場合に、分散処理の速度を利用する新しいハイブリッドデータ処理アーキテクチャを開発した。

本発明の一つの態様によれば、極めて多数の処理命令をリアルタイムに処理及び操作するシステムが提供され、各処理命令は２つの異なるエンティティに関するリソースアカウントデータファイル及びこれらのファイル間で交換されるリソースの量（額）及びタイプを指定するものであり、該システムは、
複数のプリローダを備え、各プリローダは前記処理命令に関連するリファレンスデータを取得するように構成され、前記リファレンスデータは指定されたリソースアカウントデータファイルの各々の現在値を示し、前記複数のプリローダは並列に動作して複数のそれぞれの受信処理命令に対する前記リファレンスデータをマスタデータベースから読み出すように構成され、更に、
複数の前記処理命令をそれらのプリロードされたリファレンスデータとそれぞれ一緒にキューイングするエンリッチ命令キュー、
受信した前記リファレンスデータを用いて、各受信処理命令を関連するリソースアカウントファイルの現在値に基づいて実行できるかどうかをシーケンシャルに決定し、各実行可能な命令に対して更新コマンドを発生するように構成された実行エンジン、及び
前記実行エンジンからの前記更新コマンドに応答して、前記マスタデータベースを各実行可能な命令の結果で更新する複数のアップデータを備え、前記複数のアップデータの動作が前記実行エンジンの動作から分離されていることを特徴とする。

本発明の到達時に、本発明者は最初に下記の点を評価した。

リアルタイム応答を提供するために、本発明の命令処理システムは個別の要求を処理し応答できる必要がある。従って、純粋な「バッチ向け」解決策は極めて効率的であるが、このような解決策を実現することはできない。

本発明の命令処理システムは極めて高いスループットに到達しなければならず、この理由のために、十分な数の更新を格納リソースアカウントファイルに対して短い期間内に実行する必要がある。伝統的な従来の並列入力照合アプローチ（図７に示されている）では、リアルタイム処理が可能で、命令プロセッサの多数のインスタンスを並列にランさせることによって増加したスループットを達成できる。しかしながら、システムは高い命令の集中に対処する必要があるため、命令プロセッサの多数インスタンスの並列ランは命令のロッキングを増加するのみとなり、スループットを不都合に低下する。

本発明者は、従来のアプローチに対して新しい特定の特徴の組み合わせが本発明の目的を満足する改善された解決策をもたらすことができることを認識した。新しいハイブリッド解決策によれば、命令をシーケンシャル処理することによって命令へのロッキング影響が阻止される。通常生じるスループットの低下は、実際の処理を最小限に縮小することによって、即ち命令プロセッサは命令それ自体を実行できるかどうかに関する決定を行う必要があるだけとすることによって、防止される。アカウントリソースファイルの更新は命令プロセッサが行う判断から分離され、それから外注されるため、命令プロセッサのスループットが増大する。更に命令を処理決定を行うのに必要なすべてのデータとともにプリロードすることによって、時間を要するデータベースアクセスが命令プロセッサにより避けられる。

本発明は単一のシーケンシャル実行エンジンのランに基づくものであるから、処理命令に対するリファレンスデータのプリローディングを必要とする。これなしでは、（プリローダの下流で実行される）単一のシーケンシャル実行エンジンは所望の高スループットに到達できない。これは、実行エンジンは命令を処理するために多くのリファレンスデータの値を読み取る必要があり、読み取り動作がマスタデータベースに対して実行される場合、多数のプロセッササイクルが費やされることになるからである。所望の全体スループットを達成するために、プリローディング機能がマルチインスタンスコンポーネントとして実現され、好ましくは複数のプリローダがマスタデータを複数の命令の各々に対して一つずつ並列に読み取るように設けられる。更に、プリローダはボトルネックを緩和するのに役立つ複数の入力キュー（インスタンス）を有することができ、これらの入力キューの各々は複数のプリローダの対応する一つへの専用の入力を提供するように配置される。並列処理のスケーラビリティはロッキング問題により損なわれない。これは、プリローダ動作は読み取りのみであり、ロッキング問題を生じないためである。

マスタデータベースはアップデータによってのみリアルタイムに更新される。従って、プリローダのリードオンリプロセスはデータベースロッキングを発生しない利点をもたらす。プリローダは、アップデータのアップデートプロセスにより既にロックされているリファレンスアカウントファイルを読み取ろうとするとき、ちょうど遅延される。プリローダ性能も、有利なことに、並列にランするデータ読み取り機能の新しいインスタンスを追加することによって拡張可能である。

本システムは、実行エンジンに格納された現在状態テーブルを更に備え、前記現在状態テーブルは、更新されたリソースアカウントファイルの各々の更新されたリアルタイム値を表すように、前記リソースアカウントファイルに対して実行された命令の結果で更新されるように構成され、実行エンジンは、後続の命令のシーケンシャル処理のために、特定のリソースアカウントファイルに対して、前記現在状態テーブル内の情報を前記プリローダからのリファレンス情報に優先して使用するように構成される。

各プリローダはマスタデータコレクタを備え、各マスタデータコレクタはマスタデータベースからデータを読み取るように構成される。この読み取りは非同期プロセスであるため、リファレンスデータの読み取り値は古い可能性がある。しかし、このことは、実行エンジンは、それが初めて情報を受信し、それを現在状態テーブルに格納するとき、マスタデータが正確であることを知っているので、問題にならない。最初の命令が実行される場合、現在状態テーブル内のリソースアカウントファイルの値に対する更新が行われる。しかし、同様に同じリソースアカウントファイをリファレンスする後続の命令も、特定のリソースアカウントファイルに対してマスタデータベースの古い値ではなく正確な更新値を有する現在状態テーブル内の値を有利に用いることができる。

現在状態テーブルの可能な最速の実施を確実にするために、実行エンジンは現在状態テーブルを格納する高速ローカルデータメモリを備えるのが好ましい。

本システムは、複数の異なるソースからリアルタイム命令及びバッチ命令を受信し、これらの命令を前記複数のプリローダへの入力のためにキューイングするように構成された初期入力キューを更に備えることができる。更に、スループットを助けるために初期入力キューの複数のインスタンスを設けることもできる。初期入力キューは各入力命令に優先順位を指定するように構成するのが好ましい。

命令の処理結果が一組の実行規則の違反になるとき処理命令の失敗が生じる。これらの規則は受諾し得ない処理結果の定義又はしきい値を与えるものとし得る。例えば、リソースアカウントの量（額）がゼロより低くなる場合には命令は受諾されない。所定のリソースアカウントに対して、集計リソース値が所定のレベルより低くなるとき、しきい値に達したものとし得る。

実行エンジンは各命令の優先順位に従って命令を処理するように構成される。優先順位制御は失敗した命令にも適用し、再利用することができる。そうするために、実行エンジンは、命令が関連する一つのリソースアカウントファイルのバランス（残高）に変化（典型的には増加）が発生したときにサクセスフルに実行可能となる失敗命令の再処理を含む。

本システムは処理セッションの間、典型的には１日につき１回のセッションの間動作する。運転可能日の点からすると、セッションの開始は、システムが運転可能でなかった間に処理できなかったプリロードされた命令の実行をトリガする。この初期期間においては、システム動作はバッチ向きである。しかし、処理のために命令のバッチがシステムにより受信されるセッション開期間中でも、システムは新たに入力する非バッチ処理命令をリアルタイムに処理し、それらに優先順位を指定し、それらを関連する優先順位に従って処理するために順序付けることができる。

好ましくは、実行エンジンは、失敗した処理命令を高速のローカルメモリに格納し、前記失敗した処理命令により特定されるリソースアカウントファイルの更新が起こった後に、前記失敗した処理命令を再実行のために提示する再利用モジュールを備える。これらの失敗した処理命令は、好ましくは、再利用中おけるにサクセスフルな実行の確率を向上させるために優先順位付けすることができる。より好ましくは、本システムは、小さいリソースアカウントクレジット又はデビットの移動よりも大きな移動を有する命令に高い優先順位を与えるように構成することができる。

セッション開によりトリガされた命令の大半が完了すれば、システムの動作は純粋にリアルタイムになる。この時間中は、特定のリソースアカウントファイルの値又は特定の集計リソース値の如何なる増加も、当該リソースアカウントファイルの値又は当該集計リソース値が低すぎたために決済に失敗したすべての前命令の再利用をもたらす。この再利用は、上述したように再利用のために格納された命令の各々の予め決められた優先順位に従って実行するのが好ましい。

再利用モジュールは、再利用プロシージャ中に、失敗命令をそれらの優先順位の順に格納し、最も高い優先順位の命令を再実行のために供給するように構成するのが好ましい。

実行エンジンはすべての失敗命令をそのメモリ内に保持するため、リソースアカウントファイルのレベル又は集計リソースレベルの増加により、その増加を待っているすべての失敗命令の再利用を誘発することができるようにするのが好ましい。実行エンジンはリファレンスデータの増加（変化）を待つそのローカルメモリにこの失敗命令のリストを保持するのが好ましく、このリストの命令を優先順位順に処理することは比較的容易である。

再利用モジュールは、前記リスト内の命令に関連するリソースアカウントファイルの現在値を留保し、この留保された量を再利用プロシージャ中に命令の要件をかなえるために使用するように構成されている

大きな命令に対するリソースアカウント内の利用可能なリソースを留保してこの量を用いる小さい命令を避けることは、再利用における決済効率を高める。例えば、ある命令は５０を要求し（出金）、バランス（残高）は３０である。その決済は、２０の不足のために失敗する。３０の留保は２０を要求する小さい命令の決済の実行を阻止する。目的は、２０の受領（入金）が起こった場合（別の命令の実行により与えられる）、５０の大きな命令を実行するチャンスを与えることにある。この留保オプションは失敗命令に対して維持される。再利用エンジンは、所定のリソースアカウントファイルの残高に増加が発生するとき留保額を増大し得る命令を実行するように試みる。

前述したように、命令の再利用は従来の実行エンジンでは実行エンジンの全体性能の低下をもたらすが、上記の動的再利用は効率を大幅に向上するため、実行エンジンの全体性能は、実際上、再利用機能がまったく設けられていない場合より速くなる。

実行エンジンはそのメモリに、リソースアカウントファイルおよび集計リソース値の現在値の更新された正確なイメージを保持するので、どのような留保の必要性もローカルメモリ自体内で比較的容易に具体化することができる。実行エンジンの動作は並列処理でないため、命令は優先順位順に受信され、最高優先順位の命令を最初に留保することができる。

再利用モジュールは、失敗処理命令を再実行のために所定の最大回数にわたり提示し、この失敗命令が依然として実行されなかった場合に、この失敗命令をキャンセルするように構成することができる。

本発明を具体化するシステムは所望の目的を達成するように構成されている。使用アーキテクチャの観点からすると、システムは以下の技術的特徴を有する。

本システムはリアルタイムに動作する。エンティティが命令を送ると、フィードバック（命令の成功又は失敗）が典型的には３秒以内に受信される。この経過時間は、受信命令及び応答メッセージをエンティティの通信インフラストクチャとシステムプラットフォームとの間で伝送するのに要する時間と、命令の処理を実行するのに要する時間とを含む。この経過時間は、メッセージを処理プラットフォームまで伝送するための１秒間と、処理プラットフォーム内における実行のための１秒間と、応答メッセージをインフラストラクチャに返送するための１秒間に分けられる。伝送時間は、ネットワークの伝送負荷及び動作状態に依存するので、僅かに変化し得ることもちろんである。従って、上記の時間は一つの命令に関するＳＳＥへの往復に要する平均伝送時間を表す。

本発明を具体化するシステムは高いスループットを達成する。具体的には、本システムは、典型的には処理セッションの開始時に起こるピーク時間に、５００命令／秒のスループットを達成できる。

本発明を具体化するシステムはいわゆる「シンクロナスファイナリティ」を達成する。これは、実行エンジンが命令を処理しているときに、関連するエンティティの結果のリソースアカウント及び集計リソース値のすべてに対する更新が同じ論理作業単位の一部分として実行されることを意味する。

本発明を具体化するシステムは、他のアプリケーションによるマスタデータベースのリソースアカウント値へのアクセスを可能にするように構成される。この能力は、本システムがアクティブである間、同じくマスタデータベースを参照する必要がある外部システムの動作にも有益である。

本発明のアーキテクチャの設計は非ロック親和性を有するシステムをもたらす。マスタデータベースに対して実行される更新は、実行エンジンが同じリソースアカウントファイルを高いレートで更新するときに性能が影響されないように管理される。本発明のこの特徴は、更新の集中がある場合、例えば特定の集計リソース値が毎秒５０回更新される場合に真価を発揮する。

本システムは、処理命令のローディング速度を実行エンジンのスループット未満に減速するために、実行エンジンの処理命令スループットを決定し、命令注入プロセス（キュー）に待ち状態を与えるペーシングモジュールを更に備える。更に、実行エンジンが数個の処理モジュールを有し、各処理モジュールが命令をローディングする複数のインスタンスキューを有する場合、ペーシングモジュールは、命令ローディング速度を実行エンジンのスループット未満に減速するために、実行エンジン内の任意の処理モジュールの任意のキューに待ち状態を与えるように構成される。

メッセージキュー設計において、本システムは如何なる命令キューにも多すぎる命令を格納しないようにする必要がある。実際上、メッセージキューシステムは、命令をデータコンテナのように保持することなく転送するように設計される。データ保持機能はデータベースに留保すべきである。多くの命令をキューイングするとき、命令キューはそれらをメモリに直接保持することはできない。むしろ、この場合には、命令キューはそれらをディスクにアンロードしなければならない。その結果、スループットが大幅に低下する。

システムに多すぎるメッセージを格納しないように、ページングモジュールは新しい命令がシステムにローディングされる速度を制御する。ローディング速度がキュー設計の最も弱いリンクのスループットより高い場合にキューイングが起こる。ローディング速度を制御するために「ペーシング」というスリープタイムが各コミット後に実行され、所定のレートを超えるロードスループットが防止される。

実行エンジンは、受信命令の実行の結果を報告する報告モジュールを備え、前記報告モジュールは、実行できると決定された各命令に対して更新命令を出力し、各失敗命令に対して通知命令を出力するように構成される。

本システムは、報告モジュールから更新命令及び通知命令を受信し、キューイングするように構成されたファイナリティキューを更に備えることができる。

実行エンジンの実行決定とマスタデータベースの更新との分離は本発明のアーキテクチャにおける従来技術からの主要な変化である。ファイナリティキューへの更新命令の入力により、その命令がファイナルとして宣言される。殆どの従来のバッチシステムは「オール・オア・ナッシング」に基づいて動作する。従って、バッチの終了時にファイナリティに達する。殆どの従来のリアルタイムシステムは、マスタデータベースの変化をコミットすることによりそれらの命令をファイナルとする。本発明では、実行エンジンが更新命令をファイナリティキューへコミットすると同時にファイナリティになる。これは、実行された命令とマスタデータベース内のリソースアカウントファイルの関連値との間にリアルタイム同期がないことを意味する。

処理アーキテクチャのこの分離特徴は、複数のプリローダにより読み取られたリファレンスデータが期限切れになり得ることを意味する。本発明は、最初にリファレンスデータが実行エンジンに与えられ、リファレンスデータの値がリファレンスアカウント及び集計リファレンス値の実際の現在状態を正確に反映するようにする。そうするために、好ましくは、システムは、処理セッションを開始する前、即ちプリローダ及び実行エンジンの動作を開始する前に、命令の実行を反映するすべての更新コマンドがマスタデータベースに反映されるようにする必要がある。換言すれば、すべてのキューが処理セッションの開始前に空になるようにする必要がある。

報告モジュールは、実行エンジンによる一つの物理的作業単位の完了を表すコミットイベントが起こるまで、複数の更新命令を一時的に格納し、コミットイベントの発生時に複数の格納された更新コマンドを出力するように構成するのが好ましい。

設計によって、システム処理ステップは複数のステップを備える。システムの全体スループットは最も弱いリンクにより制限される。プロセスのステップが並列処理によるスケーラビリティを有するとき、それは最も弱いリンクになり得ない（性能は他のステップを同時にランさせることにより常に高めることができる）。その結果、システムの最も弱いリンクはシーケンシャル実行エンジンである。というのは、並列処理をサポートしないシステム内の唯一のコンポーネントが実行エンジンでからである。

実行エンジン、ひいてはシステムの性能を改善するためには、不必要な外部データアクセスを避けることによって実行エンジンの操作をできる限りＣＰＵバウンドとして維持するようにすべてのことを実行しなければならない。複数のプリローダを用いることによって、実行エンジンにより必要とされるすべての読み取りデータが命令とともにプリロードされ、出力において、実行すべきすべての更新命令が単一の命令メッセージに束ねられる。結局、実行エンジンの外部データアクセスは入力において一つの永続的メッセージに限定され、出力において一つの永続的メッセージに限定される。他のデータアクセスの付加が可能であるが、システムの全体スループットを低下する不利がある。

性能を改善するためには、実際の命令実行以外のロジックを実行するＣＰＵサイクルの活動を避けるようにすべてのことを実行しなければならない。例えば、ＣＰＵサイクルはコミット時間中活動する。従って、実行エンジンは（コミットプロセスを実行する前に（ローカルメモリ内の）複数の入力命令を実行する）一組の論理的作業単位を束ねる一つの物理的作業単位を実行する。５０のコミット周波数の場合、５００命令／秒のスループットは５００コミット／秒の代わりに１０コミット／秒をもたらす。コミットプロセスは実行エンジンに対する物理的作業単位を表す。５０のコミット周波数は５０の処理命令が実行され、報告されることを意味し、それは、実行されたすべての更新の最後（入力する命令の物理的除去及び報告メッセージの物理的書き込み）を与える技術的コミットフェーズがエンタリングされるためである。

本システムは、好ましくは、ルーティングフレームワークを更に備え、このルーティングフレームワークは、命令を同時に動作する複数の初期入力キュー又は更新インスタンスキューに分散するように構成される。これにより、命令を均等に分散することができ、複数の異なるキュー又は処理素子を例えばプリローダ及びアップデータに使用することができる。

ルーティングフレームワークは、好ましくは、命令が関連する情報のタイプを記述する命令名及び命令を特定する一意のキーを提供するワークロードバランサキーを命令に指定するように構成することができる。この場合には、ルーティングフレームワークは、受信した命令及びワークロードバランサキーを用いて複数の入力キュー又は更新インスタンスのうちの一つを選択するように構成することができる。

ルーティングフレームワークは、前記ルーティングフレームワークと共同して、前記受信命令名及びワークロードバランサキーを用いて、前記複数の初期入力キュー又は分離入力キューのうちの一つの選択するように構成されているワークロードバランサを備えるのが好ましい。

所望のスループットを達成するために並列処理を用いるシステムの各コンポーネント（例えばプリローダ及びアップデータ）に対して、ワークロード（作業負荷）はワークロードバランサ及びルーティングフレームワークによってこれらのコンポーネントの各々に正しく分散される。しかしながら、この分散は、有利なことに、入力命令を実行すべき順序を規定する順序付けルールの違反を生じない。

ルーティングフレームワーク及びワークロードバランサは、ワークロードを一組のキュー（例えばマスタデータ分離キュー）に分散し、同じ順序付けキーを有する命令が同じキューに経路指定されることを保証することができる。ルーティングフレームワークは、使用可能なインスタンスの数を分析し出力メッセージを順序付け制約を破ることなく分散させることによって、それ自体を目標プロセスの構成に直接適応させることができる。

換言すれば、ワークロードバランサは、特定のリソースアカウントデータファイルに関連するすべての命令が常に複数のキューのうちの同じ一つに経路指定されるようにするために、所定のワークロードバランサキーを同じ特定の宛先にリンクするように構成される。

好ましくは、本システムは、所定の時刻における処理セッションの終了に応答して、メッセージを実行エンジンの出力に設けられたキューの入力に送り、その応答を待ち、更なるメッセージを複数のアップデータの一つの入力キューに送り、その応答、即ち処理セッションの終了前に実行された処理命令のすべての結果によるマスタデータベースの更新を示すシーケンシャル応答の受信を待つように構成されたデリミタフレームワークを更に備える。

本システムが各処理命令の結果を報告するディスパッチャモジュールを備える場合には、デリミタフレームワークは、処理セッションの終了前に実行された処理命令に対する報告メッセージがすべて送られたことを確認するために、メッセージをディスパッチャの入力キューにも送り、それぞれのフィードバックを待つように構成するのが好ましい。

換言すれば、デリミタフレームワークは、実行エンジンの出力部、即ちファイナリティキューにメッセージを送る。デリミタフレームワークがこのメッセージに対する応答を受信すると同時に、それはデリミタメッセージの到達前にファイナリティキューに格納された命令のすべてが処理されたことを示す。その後、デリミタフレームワークはディスパッチャの各インスタンスにメッセージを送り、各インスタンスからの対応するフィードバックを待つ。ディスパッチャのすべてのインスタンスからそれらの関連するフィードバックがデリミタフレームワークに送られたとき、デリミタフレームワークは、すべてのディスパッチプロセス（命令、実行、結果及び報告）が終了したことを知る。このとき、デリミタフレームワークはデリミタプロセスをアップデータに対して開始することができる。これは、マスタデータアップデータの各インスタンスにメッセージを送り、すべてからの関連するフィードバックを待つことにより行われる。

マスタデータアップデータのすべてのインスタンスからのフィードバックが受信されると、デリミタは、期限前にポジショニングエンジンにより実行された処理命令に関連するすべての命令の更新が今マスタデータベースに反映されたことを知る。デリミタのワークフローは終了し、セッション活動報告がディスパッチャにより発生される。

本発明は、極めて多数の処理命令を処理セッション中にリアルタイムに処理及び操作するコンピュータ実行方法にも及び、各処理命令は２つの異なるエンティティに関するリソースアカウントデータファイル及びこれらのファイル間で交換されるリソースの量及びタイプを指定するものであり、該方法は、
複数のプリローダから処理命令に関連するリファレンスデータを取得するステップを備え、各プリローダは前記処理命令に関連するリファレンスデータをそれぞれ取得するように構成され、前記リファレンスデータは指定されたリソースアカウントデータファイルの各々の現在値を示し、前記取得ステップは、複数のそれぞれの受信処理命令に対してマスタデータベースから前記リファレンスデータを読み出すために前記複数のプリローダを並列に動作させるステップを含み、更に、
複数の前記処理命令をそれらのプリロードされたリファレンスデータと一緒にエンリッチ命令キューにてキューイングするステップ、
実行エンジンによって、受信した前記リファレンスデータを用いて、各受信処理命令を関連するリソースアカウントファイルの現在値に基づいて実行できるかどうかをシーケンシャルに決定し、各実行可能な命令に対して更新コマンドを発生するステップ、及び
前記実行エンジンからの前記更新コマンドに応答する複数のアップデータを用いて、前記マスタデータベースを各実行可能な命令の結果で更新するステップを備え、前記複数のアップデータの動作が前記実行エンジンの動作から分離されていることを特徴とする。

本発明の更に別の態様によれば、極めて多数の処理命令メッセージを処理セッション中にリアルタイムに処理及び操作するシステムが提供され、各処理命令は２つの異なるエンティティに関するデータファイル及びこれらのファイル間で交換されるリソースの量及びタイプを指定するものであり、該システムは、
複数のプリローダを備え、各プリローダは前記処理命令に関連するリファレンスデータを取得するように構成され、前記複数のプリローダは並列に動作して複数のそれぞれの受信処理命令に対してマスタデータベースから前記リファレンスデータを読み出すように構成され、更に、
複数の前記処理命令メッセージをそれらの取得されたリファレンスデータと一緒にキューイングする命令メッセージキュー、
各命令メッセージをシーケンシャルに実行する実行エンジンであって、任意のマスタデータベースアクセスを用いる代わりに前記プリロードされたリファレンス情報を用いて、前記命令メッセージを当該ファイルの現在状態の下で実行できるかどうかを決定するように構成されている実行エンジン、及び
関連するファイルの更新されたリアルタイムポジションを確定するためにファイルに対して実行された命令の結果で更新されるように構成された現在状態テーブルを備え、
前記実行エンジンは、特定のデータファイルが処理セッション中に実行エンジンにより更新された場合に、後続の命令のシーケンシャル処理のために、当該データファイルに対して、現在状態テーブル内の情報を前記複数のプリローダからのリファレンス情報に優先して使用するように構成されていることを特徴とする。

本発明のこの態様は、最新のリソースアカウント値のリアルタイム更新可能コピーを実行エンジンのメモリに持たせることによってマスタデータベースの更新を避けることを目的としている。これは、膨大な数の命令をリアルタイムに処理する従来技術の問題の大半を克服する重要な設計上の特徴である。

本発明の更に別の態様は、異なるレートで非同期的に受信される極めて多数の処理命令メッセージを処理セッション中にリアルタイムに処理及び操作するシステムが提供され、該システムは、
命令メッセージに対して異なるタイプの処理を実行する複数の処理モジュールを備え、各処理モジュールは命令メッセージをシーケンシャルに処理するように構成された実行エンジンを備え、更に
各組がそれぞれのデータ処理モジュールへの入力をキューイングするように設けられた複数組の命令キュー、及び
実行エンジンの処理命令スループットを決定し、処理命令のローディング速度を実行エンジンのスループット未満に減速するために任意の命令キューに待ち状態を与えるペーシングモジュールを備えることを特徴とする。

前述したように、異なるレートで非同期的に受信される極めて多数の処理命令メッセージを処理セッション中にリアルタイムに処理及び操作するシステムは、任意の命令キューに多すぎる命令が格納されるのを避ける必要がある。メッセージは格納（データベースの機能）されるよりも転送されることになる。キューイングされる命令の数が多くなると、それらをディスクからアンロードしなければならず、これは時間のかかる処理であり、スループットを直接低下させる。

システムに多すぎるメッセージが格納されるのを避けるために、ペーシングモジュールがシステムにロードされる新しい命令の速度を好都合に制御する。ローディング速度がキュー設計の最も弱いリンクのスループットより高い場合にキューイングが起こる。ローディング速度を制御するために、「ペーシング」というスリープ時間が各処理時間単位後に実行され、所定のレートを超えるロードスループットが防止される。

本発明の更に別の態様によれば、極めて多数の処理命令メッセージを処理セッション中にリアルタイムに処理及び操作するシステムが提供され、各処理命令は２つの異なるエンティティに関するリソースアカウントデータファイル及びこれらのファイル間で交換されるリソースの量及びタイプを指定するものであり、該システムは、
複数のプリローダを備え、各プリローダは前記処理命令に関連するリファレンスデータを取得するように構成され、前記リファレンスデータは指定されたリソースアカウントデータファイルの現在値を示し、前記複数のプリローダは並列に動作してマスタデータベースから前記リファレンスデータを読み取り、前記リファレンスデータを前記処理メッセージと一緒に実行エンジンに出力するように構成され、
前記実行エンジンは、各命令メッセージをシーケンシャルに実行するように構成され、任意のマスタデータベースアクセスを用いる代わりに前記プリロードされたリファレンス情報を用いて、前記命令メッセージを当該ファイルの現在状態の下で実行できるかどうかを決定するように構成され、更に
関連するファイルの更新されたリアルタイムポジションを確定するためにファイルに対して実行された命令の結果で更新されるように構成された現在状態テーブルを格納する高速ローカルメモリ、及び
失敗した処理命令のリストを高速のローカルデータストアに格納し、前記失敗した処理命令により特定されるリソースアカウントファイルの更新が起こった後に、前記失敗した処理命令が再実行のために提示される場合に、再利用プロシージャを実行する再利用モジュールを備えることを特徴とする。

好ましくは、前記再利用モジュールは、前記失敗命令をそれらの優先順位の順に格納し、再利用プロシージャ中に最高優先順位の命令を再実行のために最初に提示するように構成される。この構成は、異なる特性の命令を最大のスループットで効率よく操作する最適な操作法を提供する。

前記再利用モジュールは、前記リスト内の命令に関連するリソースアカウントファイルの現在値を留保し、この留保された量を再利用プロシージャ中に命令の要件をかなえるために用いるように構成することができる。この構成により、リソースに対して起こり得るデマンドが重要な期限の失敗を防止するために早い段階で識別されるようになる。

更に、前記再利用モジュールは、失敗処理命令を再実行のために所定の最大回数にわたり提示し、この失敗命令が依然として実行されなかった場合に、この失敗命令をキャンセルするように構成するのが有利である。この構成によれば、実行しようとしていないトランザクションによりシステムが停滞する問題を防ぐことができる。

この動的再利用発明の利点は上で再利用モジュールに関連して既に説明されているため、ここでは繰り返さない。

本発明の特定の実施例を添付図面を参照して以下に説明する。

パーティＡ及びパーティＢ間で契約を実行する基本的な従来の命令処理構造を示す概略図である。 マスタデータベースに格納されるリソースアカウントファイルを示す概略ブロック図である。 パーティからのデータメッセージ命令の構成を示す概略ブロック図である。 図１の命令実行サーバの主なコンポーネントを示す概略ブロック図である。 従来の命令処理プラットフォームの一般的な動作を示すフローチャートである。 従来の命令処理プラットフォームの一般的な動作を示すフローチャートである。 バッチ入力に対する標準的な従来の照合プロセスを示す概略図である。 並列複数入力プロセスに対する標準的な従来の照合プロセスの概略図である。 本発明の一実施例による処理プロセスラットフォームを示す概略ブロック図である。 図８の処理プラットフォームの動作を示すフローチャートである。 図８の処理プラットフォームのプリローダの動作を示すフローチャートである。 図８の処理プラットフォームのポジショニングエンジンの概略ブロック図である。 図１１のポジショニングエンジンの動作を示すフローチャートである。

本発明の一実施例による処理プラットフォーム１５０を図８−図１２を参照して以下に説明する。処理プラットフォーム１５０は図２及び図４につき述べたものと同様の命令実行サーバ２２内に存在し、一般に従来の命令実行サーバ２２に機能的に等価である。もっと正確にいうと、以下に記載する本実施例の処理プラットフォーム１５０は図４に示される従来の命令検査、実行及び更新エンジン７０にとって代わるものである。

図８から明らかなように、処理プラットフォーム１５０は４つの主なコンポーネント、即ち複数のプリローダ１５２、ポジショニングエンジン１５４、ディスパッチャ１５６及びアップータ１５８からなる。これらは、図８に示されるように、以下に記載するキュー及び他の機能モジュールと一緒に構成される。

プリローダ１５２は、全パーティのリソースアカウントファイル３０及び集計リソース値３２のマスタデータベース２４へのリードオンリーアクセスを有する。図８では、便宜上、マスタデータベース２４はプリローダ１５２の一部分として示されている点に留意されたい。しかし、一つのマスタデータベース２４がシステム内にあるのみであるときは、プリローダ１５２はマスタデータベース２４を含まない点に留意されたい。各プリローダ１５２は、自分専用の初期入力キュー１６４からの命令にアクセスするように機能し、所要の情報をマスタデータベース２４から取得するマスタデータコレクタ１８２（後記される）を備え、結果をエンリッチド命令キュー１６６に出力するように機能する。各プリローダ１５２はマスタデータコレクタ１８２を備える（しかし、図８は簡潔のために全部で２つしか示していない）。データコレクタ１８２は入力決済命令を操作するモジュールであり、各入力コマンドが単一のマスタデータコレクタ１８２に指定される。マスタデータコレクタ１８２の機能は、マスタデータベース２４から該コマンドに対して適切なマスタデータを読み出し、これらをもとの決済命令と一緒に組み合わせてエンリッチドメッセージ命令（図示せず）を形成し、これを各プリローダ１５２から出力する。これらのプリローダ１５２はすべてそれらの動作を並列に実行し、データベースコンフリクト、例えばロッキングを少しも生じず、またリードオンリーデータベース動作を実行するのみであるから、プリローダ１５２（従ってマスタデータコレクタ１８２）の数はスケーラブルである。マスタデータベース２４は絶えず更新されるが、マスタデータベースの更新機能と読み出し機能を分離することによってこれらの従来の問題が回避され、また処理セッションにおける最初の読み出し後に読み取られるリソースアカウント値３０は正確である必要もなくなる。

ポジショニングエンジン１５４はシングルインスタンス論理プロセッサ１８４及び更新されたマスタデータレコードテーブル１８６を備え、該レコードテーブルはプロセッサのメモリに格納される。更新されたマスタデータレコードテーブル１８６はマスタデータベース内のリソースアカウントファイルに対応する複数のファイル３０ａを備える。しかし、図１１から明らかなように、また後で説明されるように、リソースアカウントファイル３０のすべてが対応するファイル３０ａを有するとは限らない。

シングルインスタンス論理プロセッサ１８４はプリローダ１５２で生成されたエンリッチ命令を受信し、これらの命令を一つずつ処理して、それが基づく決済命令をコミットすべきかロールバックすべきかを決定する。基本的には、各パーティに対するリソースアカウントファイル３０の値及び集計リソース値３２が、決済命令の実行後に、受入可能である（即ち実行規則７２を満足する）場合、決済命令は受け入れられる。この決定を行うために、シングルインスタンス論理プロセッサ１８４は、更新済みマスタレコードメモリテーブル１８６の対応するファイル３０ａを、受入可能な決済命令に由来するリソースアカウントファイル３０の各々の最後に更新された値（最新の更新値）で連続的に更新する。リソースアカウントファイル３０ａのこれらの更新値はその後受信されるエンリッチ命令に含まれる対応する値に優先して使用される。ポジショニングエンジン１５４の出力は、ポジショニングエンジン１５４に入力された決済命令とその命令が受入可能、即ちコミットすべきか、受入不能、即ちロールバックすべきかどうかの指示のリストである。更に、ロールバックされる命令は保持され、再利用することができ、この点については後に詳述する。命令の主部でないリソースアカウントファイル３０はマスタレコードメモリテーブル１８６に対応する写しを持たないので、メモリのサイズはデータベースのサイズより小さくなる。

ディスパッチャ１５６はディスパッチャモジュール１８８を備える。ディスパッチャモジュール１８８は、ポジショニングエンジン１５４から出力される、処理された決済命令のリストを受け取り、処理の結果（コミット又はロールバック）を決済命令と関連するパーティに報告する。ロールバックされる命令に対しては、失敗の理由が応答メッセージに記述される。コミットされる命令は、サクセスフルに処理される決済命令として報告され、それらはアップデータ１５８に渡される。

アップデータ１５８は、マスタデータベース２４の固有の部分にそれぞれアクセスすることができる複数のマスタデータアップデータ１９０を備える。簡潔のために、図８はマスタデータベースの３つの部分２４ａ，２４ｂ，２４ｃにアクセスする３つのマスタアップデータ１９０を示す。しかし、本例では、これはプラットフォーム１５０のスケーラブル部分であり、マスタアップデータ１９０及び関連する固有の部分２４ａ，２４ｂ，２４ｃの多数倍が設けられる。成功決済命令がマスタアップデータにどのように分散されるかは後に詳述される。

処理プラットフォーム１５０への入力は、決済命令のバッチ１６０を入力としてそれぞれ供給する複数のシーケンスファイル操作プロセス１６０およびリアルタイムに受信しリアルタイムに処理すべき決済命令を操作する一つ以上の個別命令操作コンピュータ又はプロセス１６２から与えられる。

処理プラットフォーム１５０の主なコンポーネントの間にはキューモジュールが設けられる。これらのキューは、場合により、同時プロセス領域をシーケンシャルプロセス領域へ及びその逆に変換する手段として作用する。もっと正確に言うと、複数のシーケンスファイル操作プロセス１６０及び個別命令操作プロセス１６２から受信し得る非同期の決済命令をキューイングするために複数の初期入力キュー１６４が複数のプリローダ１５２の入力として設けられる。プリローダ１５２のマスタデータコレクタの同時動作の結果を照合し、これらをポジショニングエンジン１５４へ入力すべくシーケンシャル領域に変換するために、エンリッチ命令キュー１６６が設けられる。ポジショニングエンジン１５４の出力はファイナリティキュー１６８に接続され、これはディスパッチャ１５６への入力としても作用する。最後に、複数のマスタデータ分離キュー１７０がディスパッチャ１５６の出力とアップデータ１５８の複数の入力との間に設けられる。ディスパッチャ１５６の別の出力はリプライキュー１７２に接続され、リアルタイムメッセージを命令操作プロセス１６２に供給する。

誤解を避けるために、初期入力キュー１６４、エンリッチ命令キュー１６６、ファイナリティキュー１６８、マスタデータ分離キュー１７０及びリプライキュー１７２は、図８に明瞭に示されているように、すべて複数のインスタンスで与えられ、即ち複数のキューが並列に動作する点に留意されたい。

処理プラットフォーム１５０中の命令の流れを助けるために３つの他のモジュールが設けられる。ペーシングモジュール１７４は、バッチプロセス１６０からの命令がキューイングされるレートをプラットフォーム１５０中の最も弱いリンクより低いレートに調整する。こうすると、プラットフォーム１５０内のキューは常に殆どからになる。

ルーティングフレームワーク１７５はワークロードバランサ１７６を介して命令をキューへ経路指定するために使用される。ルーティングフレームワークはフレキシブルであって、経路指定の種々の態様を受信命令の順序付けを変えることなく変えることができる。

ワークロードバランサ１７６は、命令のワークロードを一組のキューへ分散させ、同じキューイングキー（後述する）を有する命令／コマンドが同じキューに経路指定されるようにするために使用される。

デリミタフレームワークモジュール１７８は、ポジショニングエンジン１５４により実行され、所定の期限日までにファイナリティキュー１６８に書き込まれた全処理がマスタデータベース２４及び更新を確認するリアルタイムメッセージに反映されるようにするために使用される。

次に図９を参照して、処理プラットフォーム１５０の全操作プロセス２００が説明される。プロセス２００は、決済命令がステップ２０２において非リアルタイムのバッチファイル１６０又はリアルタイムの個別命令操作プロセス１６２のいずれかから受信される状態で開始する。非リアルタイムバッチファイルは、例えば特定の未来の実行日を有する命令を繰り返し格納することにより生成することができ、バッチは特定の実行日の到達時に実行されるように生成される。ここで使用される語「バッチ」は、レコードを特定の順序に配列する必要があることを意味しない。本例にとって、バッチ内の決済命令の順序は問題にならない。むしろこの語は単に一群の決済命令を示すために使用される。

プロセス２００は、ステップ２０４において、受信命令を次にそれぞれのプリローダ１５２に入力するために初期入力キュー１６４においてキューイングする。このキューイング２０４は決済命令のフローを非同期並列入力領域から同期シーケンシャル領域へ変換する。次にこれらの命令は、各命令に対するリファレンスデータをマスタデータベース２４から取得するために、ステップ２０６において複数のプリローダ１５２により処理される。このプロセスは複数のマスタデータコレクタ１８２（各プリローダにつき一つ）を用いて並列に実行される。

各決済命令について、ステップ２０８において、取得した情報を照合して、決済命令自体と、該命令を実行規則７２に違反することなく実行できるかどうかを決定するためにポジショニングエンジンにより必要とされるマスタデータベースのリファレンスデータとを含むエンリッチ実行命令を生成する。エンリッチ実行命令のすべては、同様にステップ２０８において、エンリッチ命令キュー１６６内に置かれる。ここでも、エンリッチ命令キュー１６６は、並列に動作する複数のマスタデータコレクタ１８２の出力を処理すべきシーケンシャルエンリッチ決済命令のリストに変換するように機能する。

次に、ポジショニングエンジン１５４がステップ２１０においてキューイングされたエンリッチ決済命令の各々を順番にシーケンシャル処理する。このプロセスの詳細は後に記載される。しかしながら、ステップ２１２において決済命令を規則７２に違反しないで実行できるかどうかの決定が行われる。答えが否定の場合、決済命令はステップ２１４において再利用され、ステップ２１６においてディスパッチャ通知メッセージが生成される。このメッセージは、決済命令は不成功であったが将来再利用可能であることを示す。

ステップ２１２において答えが肯定の場合には、決済命令はステップ２１８において実行され、局所的に格納されている更新されたマスタレコードメモリテーブル１８６の対応するファイル３０ａが当該決済命令に含まれるパーティに対するリソースアクセスファイル３０及び集計リソース値３２の新しい値で更新される。次に、実行された決済命令は、ステップ２２０において、ディスパッチャ１５６への供給及び次のアップデータ１５８への転送のために、ファイナリティキュー１６８に更新実行命令として格納される。図９には示されていないが、再利用される命令もファイナリティキューに入力される。これらの失敗した命令もファイナリティキューに置かれるが、報告のためのみであり、これらはアップデータ１５８に渡されない。

ディスパッチャ１５６はファイナリティキューに格納された命令を読み出し、ステップ２２２において、命令が成功したかどうかを示す報告メッセージを生成し、該メッセージは決済命令により特定されるパーティに送られる。これらのメッセージは更に、ステップ２２２において、決済命令のパーティの命令操作プロセス１６２へのリアルタイム出力のためにリプライキュー１７２にも送られる。その後、リプライキュー内のメッセージがステップ２２４において出力される。

ファイナリティキュー１６８内のサクセスフルに実行された更新実行命令に対して、ディスパッチャ１５６は更にステップ２２６においてこれらの更新命令を複数のマスタデータ分離キュー１７０に渡す。このプロセスは、後に詳述されるように、ワークロードバランサ１７６及びデリミタフレームワーク１７８からの入力を含む。

最後に、各マスタデータアップデータ１９０に割り当てられたマスタデータベース２４の部分２４ａ，２４ｂ，２４ｃがステップ２２８においてアップデータ１５８により更新される。

処理プロセス１５０の重要なコンポーネント及びそれらの機能は以下に詳細に説明される。
初期入力キュー１６４はプラットフォーム１５０の公衆インタフェースである。これにより個別命令操作プロセス１６２から到来する入力フロー（この入力フローに対してはリアルタイムのリプライが期待される）を複数のシーケンシャルファイル操作プロセス１６０からのバッチフロー（このフローに対しては極めて高いスループットが期待される）と融合することができる。ペーシングモジュール１７４は初期入力キュー１６４への入力を制御する。ペーシングモジュール１７４はバッチ命令のローディング速度をプラットフォームの最低スループットのコンポーネント（典型的にはポジショニングエンジン１５４）より低い速度に制限する。バッチ命令の場合、初期入力キューにおけるバックログの生成を避けるためにローディング速度を制限する必要がある。個別命令操作プロセス１６２からのローディング速度は、新しい命令を入力するユーザコンピュータのリアルタイム性能により制限される。初期入力キュー１６４のこのローディング制御はプラットフォーム１５０内のすべてのキューに適用される。

ペーシングモジュール１７４は、一群の命令を処理する際（例えば、マスタデータベースからの抽出又はファイルベースのバッチ処理の際）に起動される。図８では、ペーシングモジュール１７４はシーケンシャルファイルと初期入力キュー１６４との間のフローの最上部で使用される。その機能は、クルーズ制御と同様で、初期入力キュー１６４へのバッチ命令の注入速度を(最も弱いリンク段部において)命令フローに待機が生じるのを避けるために制限する。

プラットフォーム１５０におけるキュー入力速度の制御には２つの主な理由がある。第１の理由は、メッセージキュー１６４，１６６，１６８，１７０は実効的にトランスポート層であり、データコンテナでない。キューに格納できるメッセージ又は命令の数は限定されている。バックログの生成はキューの満杯状態をもたらし、キューへの書き込みのためのローディングプロセスを阻止し得る。更に、多数のメッセージをキューに格納するとき、メッセージキューイング性能が低下する。これは、メッセージデータのディスクのアンロードがしばしば要求されるためである。

ローディングプロセスを制御する第２の理由は、個別命令操作プロセス１６２から到来するリアルタイム命令は一群のバッチ命令が滞ってキューイングされないようにする。リアルタイム要求がキューイングされると、個別命令操作プロセス１６２に対する応答時間は２秒の最大応答時間に設定されるリアルタイム応答要件に適合し得ない。

ペーシングは２つの順次のコミット間の最小遅延で規定される。一つのコミットの実行後に、該コミットの実行時刻と前コミットの実行時刻との間の差分時間が計算される。

例： 現在コミット=2007-07-01-09.05.04.224335
前コミット=2007-07-01-09.05.04.100635
２つのコミット間の経過時間(差分)は0.123700である。

２つのコミット間のペーシングが0.5秒である場合、0.3763秒の遅延が達成される。コミット周波数が50で、ペーシングが0.5秒である場合、期待されるスループットは100命令である。

初期入力キュー１６４への入力はメッセージルーティング機能を実行するルーティングフレームワーク１７５及びワークロードバランサ１７６により操作され、メッセージを所定の数の初期入力メッセージキュー１６４に均等に分散するワークロード分散技術フレームワークが提供される。

バッチファイル１６０から到来する命令とリアルタイムチャネル１６２から到来する命令との間には区別はない。プラットフォーム１５０に対する動作時間窓（動作セッション）の開始時に、ペンディング中の格納命令を順序付け、初期入力キュー１６４に注入する必要がある。開始注入が実行される間、リアルタイムに到来する命令に順序付け規則も適用される。リアルタイム命令はそれらの優先順位に基づいて初期入力キュー１６４に注入されなければならない。開始時間窓の開始プロシージャが終了するとき、継続中の順序付けは時間ベースである。同じパーティの同じリソースアカウントファイル３０に関連する２つの命令は（順々に処理するために）同じ初期入力キュー１６４に注入されなければならない。

複数の初期入力キュー１６４に対して、これらのインスタンスを並列に実行することは、例えば処理セッション（動作時間窓）の開始時に供給される大量の初期命令を操作するために重要である。ここでルーティングフレームワーク１７５が命令を複数の初期入力キュー１６４にロードする責任を持ち、ワークロードバランサ１７６がワークロードを初期入力キュー１６４の間で均等に分散させることができる。

プリローダ１５２の各々は初期入力キュー１６４のうちの対応する一つから決済命令を読み出すように構成される。その目的は、入力する決済命令を解析して、該決済命令を実行すべきか否かを決定するためにポジショニングエンジン１５４により必要されるリファレンスデータをマスタデータベース２４から読み出すためである。リファレンスデータは決済命令に含まれるパーティに対する任意のリソースアカウントファイル３０及び集計リソース値の現在値である。次に、この読み出されたデータは入力決済命令のみならずマスタデータベース２４から読み出されたリファレンスデータのすべてを含むエンリッチ命令を生成するのに使用される。

図１０は、複数のプリローダ１５２のうちの一つの動作を詳細に示す。明らかなように、各プリローダ１５２はスループットを大きくするために独立に並列に動作する。

プリローダ１５２の動作プロセス２４０はステップ２４２において開始し、当該プリローダインスタンス１５２に専用の初期入力キュー１６４から決済命令を読み出す。次にステップ２４４において、プリローダインスタンス１５２のマスタデータコレクタ１８２が、各パーティのリソースアカウントファイル３０及び当該パーティに対する集計リソース値３２のデータベース読み取りを決定する。これらの読み取り命令のすべてが計算されたら、データベースの読み取りがステップ２４６において順に実行される。その後、読み取られたデータがステップ２４８においてプリローダインスタンス１５２により処理され、当該命令に対するリファレンスデータが順に配列されたイメージを生成する。次に、このイメージはステップ２５０においてもとの命令と結合されて複合エンリッチ命令を形成する。プリローダ動作プロセス２４０はステップ２５２において各プリローダインスタンス１５２の複合エンリッチ命令を単一のエンリッチ命令キュー１６４に出力して終わる。

ポジショニングエンジン１５４は、本例の革新的な構成の重要な要素の一つを実施するものであり、はっきり言うとポジショニングエンジン１５４のメイン論理プロセッサ１８４は命令を並列に実行しない。メイン論理プロセッサ１８４はシングルインスタンスとしてランするため、それ自身で全体スループットに達しなければならない。これはメイン論理プロセッサ１８４のタイムクリティカル動作の重要性を高める。可能な最大スループットを達成するために適用される所要の制約の一つは、データベースアクセスはスループットの低下をもたらすためにこれを禁止する必要があることである。メイン論理プロセッサ１８４がよく使われる静的リファレンスデータを取り出すことができる初期ローディング後は、プロセッサ１８４への及びからのデータアクセスは一つの命令の入力及び一つの処理結果の出力に制限される。しかし、命令を処理するために必要とされるが、始動フェーズ中にロードされないリファレンスデータが、各エンリッチ命令の一部分として供給されるリファレンスデータが順に配列されたイメージによって使用可能にされる。プリローダ１５２の一つから受信される所定のリソースアカウントファイル３０に対するリファレンスデータの最初のイメージのみがポジショニングエンジン１５４によって、アップロードされたマスタレコードメモリテーブル１８６の対応するファイル３０ａに格納される。この最初のコピーは命令のリアルタイムフローによりまだ変更されてないために常に有効である。

アップロードされたマスタレコードメモリテーブル１８６の対応するファイル３０ａに既に存在するとき、プリローダ１５２の一つにより取り出されたリファレンスデータのイメージは、おそらく期限切れである（ポジショニングエンジン１５４により確認された更新はまだマスタデータベースに反映されていない）ため、単に無視される。従って、リソースアカウントの値に関連するリファレンスデータがアップロードされたマスタレコードメモリテーブル１８６の対応するファイル３０ａにおいて入手可能であるとき、このリファレンスデータがエンリッチ命令とともに供給されるリファレンスデータイメージに優先して使用される。

次に図１１を参照すると、ポジショニングエンジン１５４の構成が詳細に示されている。ポジショニングエンジン１５４は、エンリッチ命令キュー１６６からのエンリッチ命令を受信する命令受信モジュール２６０及び現在のエンリッチ命令をタイムスタンプするタイムスタンプモジュール２６２を備える。ポジショニングエンジン１５４のシングルインスタンス論理プロセッサ１８４は、リファレンスデータ読み出し及び更新モジュール２６４、移動カルキュキレータ及びローカルメモリストアアップデータ２６６及び命令処理ロジック２６８を含む。

リファレンスデータ読み出し及び更新モジュール２６４は、更新されたマスタレコードメモリテーブル１８６の対応するファイル３０ａに格納されているデータを読み出し、該データを更新すべきか決定し、そうであれば該データを更新するように作用する。アップロードされたマスタレコードメモリテーブル１８６はシングルインスタンス論理プロセッサ１８４に対して高速ローカルメモリストア２７０内に与えられ、その結果ポジショニングエンジン１５４に対して速いデータ読み取り及び書き込み時間が得られる。従って、命令の実行の決定は、時間のかかる外部データベースチェックよりもむしろ、高速のローカルメモリ内データチェックのみで実行することができる。データストア２７０は決済を後刻再度試みる必要がある失敗命令の再利用リスト２７２も保持する。

移動カルキュレータ及びローカルメモリストアアップデータ２６６は、アップロードされたマスタレコードメモリテーブル１８６の対応するファイル３０ａ内の格納リファレンスデータを読み出し、命令情報を用いて該データをどのぐらい変化(移動)させる必要があるか決定し、更新されたリファレンスデータをアップロードされたマスタレコードメモリテーブル１８６に書き戻すように作用する。

命令処理ロジック２６８は、リソースアカウントファイル３０及び集計リソース値３２の更新された値が該リソースデータに対する受け入れ可能ポジションになるかどうかを評価するために設けられる。即ち、リソースアカウントファイル３０及び集計リソース値３２の値が規則７２に従うかについて評価される。

再利用モジュール２７４は、失敗した命令を再利用リスト２７２に読み書きするために設けられ、該リストは次に命令処理ロジック２６８により又はから読み出し又は書き込むことができる。シングル命令論理プロセッサ１８４の出力は報告モジュール２７６に出され、該モジュールは命令処理の結果を更新実効命令としてファイナリティキュー１６８に出力する。

再利用は入力する命令の優先順位に基づく。優先順位グループ分け（例えば高優先順位、標準順位及び低優先順位）が各命令に指定される。再利用モジュール２７４は再利用イベントの生起に備えて再利用リストに優先順位順に維持される。その順序は主として各命令に指定された優先順位グループ分けに基づいて決定される。その後、命令のサイズが優先順位付けに利用される。再利用リスト内に優先順位を維持することによって、再利用の実施はランタイム中に比較的簡単に、従って高速に行われる。更に、再利用プロシージャは動的に行われ、受信処理命令を再実行する順序を各処理命令の優先順位を反映するように変えることができる。

再利用モジュール２７４は特定の命令とともに処理するためにリソースアカウントファイル３０の内容を留保する機能も有する。これは、リソースアカウントファイル内の使用可能なリソースの額が格納された処理命令２７２の要求を満たすときに起こる。この額を留保することによって、再利用モジュール２７４は、優先順位が維持されるとともに、大きな高優先順位の命令ではなく小さい低優先順位の命令を実行することができる資金がたとえあっても、大きな高優先順位の命令が小さい低優先順位の命令の前に実行されるようにすることができる。

これは、ポジショニングエンジン１５４内の再利用モジュール２７４が受信処理命令の留保及び優先順位操作をどのように実施するかを示す下記の非限定的実施例に最もよく示されている。

実施例：
リソースアカウントファイルAcc/Sec1は５０の担保（security）を含む。
Acc/Sec1に下記の影響を与える処理命令が順に受信される：
ステップ１ 高優先順位命令１は２００を要求する（出金）
ステップ２ 標準優先順位命令２は１００を要求する（出金）
ステップ３ 標準優先順位命令３は１５０を要求する（出金）
ステップ４ 標準優先順位命令３は６０を持ち込む（入金）
ステップ５ 高優先順位命令４は２９０を持ち込む（入金）

メモリ構造（Acc/Sec1の残高及び再利用リストの内容）はAcc/Sec1の再利用リストを次のように表す：
ステップ１後
Acc/Sec1
−５０を含む
−既に留保
−５０に対して命令１
−失敗リスト＜命令１＞

ステップ２後
Acc/Sec1
−５０を含む
−既に留保
−５０に対して命令１
−失敗リスト＜命令１，命令２＞（ins 2はins1より低い優先順位）

ステップ３後
Acc/Sec1
−５０を含む
−既に留保
−５０に対して命令１
−失敗リスト＜命令１，命令３，命令２＞（ins 3はins 2と同じ優先順位であるがins 3より大きく、重要である）

ステップ４後：Acc/Sec1の残高の増加が失敗命令の再利用を可能にし、新しい６０の担保を命令１の留保に加えることができる。留保は命令２（１００を要求するのみ）がリソースアカウントAcc/Sec1内の使用可能な１１０の担保を使用するのを阻止する。
Acc/Sec1
−１１０を含む
−既に留保
−１１０に対して命令１
−失敗リスト＜命令１，命令３，命令２＞

ステップ５後：Acc/Sec1の残高の増加が再利用プロセスを開始する。
再利用の開始時に、メモリは次のようになる：
Acc/Sec1
−４００を含む
−既に留保
−１１０に対して命令１
−失敗リスト＜命令１，命令３，命令２＞

命令１（再利用リストの１番目）の再利用（及び決済）後：
Acc/Sec1
−２００を含む
−既に留保
−０
−失敗リスト＜命令３，命令２＞

命令３（再利用リスト内の新しい１番目）の再利用（及び決済）後：
Acc/Sec1
−５０を含む
−既に留保
−０
−失敗リスト＜命令２＞

命令２の再利用は失敗する（５０の不足）。留保がない場合、メモリは変化しないままとなる。

次に、ポジショニングエンジン１５４の動作２８０が図１２を参照して以下に詳細に記載される。動作２８０は、ステップ２８２において、エンリッチ命令キュー１６６からのエンリッチ命令の読み出しで始まる。読み出された命令は次にステップ２８４においてタイムスタンプモジュール２６２によりタイムスタンプされる。１秒間に処理される命令の数を前提として、タイムスタンプは高い分解能を有し、典型的には時刻をマイクロ秒まで記録する。

タイムスタンプされたエンリッチ命令が新しいリファレンスデータ、即ちアップロードされたマスタレコードメモリテーブル１８６の対応するファイル３０ａに格納されていない特定のリソースアカウントファイル３０に対する値を含む場合（ステップ２８６において決定される）、未知のリファレンスデータはアップロードされたマスタレコードメモリテーブル１８６に格納される。リファレンスデータが新しくない場合には、動作２８０は単にローカルバランス（残高）更新ステップ２９０に移動し、このステップは移動カルキュレータ及びローカルメモリストアアップデータ２６６で実行される。このステップにおいて、リファレンスデータはローカルメモリデータストア２７０内のアップロードされたマスタレコードメモリテーブル１８６から読み出され、命令に指定されている移動が読み出されたリファレンスデータに加えられ、リファレンスデータの結果値がアップロードされたマスタレコードメモリテーブル１８６の対応するファイル３０ａに書き戻される。

次に、命令処理ロジック２６８が、ステップ２９２において、リファレンスデータの現在値を考察し、リソースアカウントファイル３０及び集計リソース値３２の更新された結果値がリソースデータの受け入れ可能値に関する所定の規則７２に適合するどうかを決定する。適合しない場合には、３つのアクションが取られる。第１に、失敗の理由がステップ２９４において報告モジュール２７６を介して報告される。第２に、リソースデータの前の値がステップ２９６においてリストアされる。第３に、失敗した命令がステップ２９８において後の決済試行のために再利用リスト２７２に格納される。

更新されたリファレンスデータが所定の規則７２に適合する場合には、決済命令の成功実行がステップ３００において報告モジュール２７６により報告される。この報告は、命令に関連するパーティに対する応答メッセージを生成し、アップデータ１５８にマスタデータベース２４を更新するように命令する作用をなす。次に、この作用の影響がステップ３０２において清算され、即ちマスタアカウントデータに適用可能なリソースアカウント移動データが生成され、一群の残高更新メッセージが生成される。以下に示す実施例では、報告メッセージ及び残高更新メッセージの生成は２つのステップで記述される。

最後に、再利用操作がステップ３０４において実行され、修正されたリファレンスデータが以前失敗した命令のいずれかを実行可能にするかどうかを確かめる。

更新中として報告されるリファレンスデータのすべては、（プリローダの一つにより申請される同じデータの期限切れのものと交換して）再利用される命令を含む後続の決済命令を処理している間再使用するために、ポジショニングエンジン１５４のローカルメモリ（アップロードされたマスタレコードメモリテーブル１８６）に保持されることもちろんである。

ポジショニングエンジン１５４のローカルメモリ２７０のファイル３０ａに保持される更新されたリファレンスデータは単にクリアされるのではない。例えば１日の処理期間の終了時に、ポジショニングエンジン１５４は停止し、メモリの完全リセットを導く。このリセットは、ポジショニング実行中に大きな問題が起こったときにも生じる。すべての最終更新情報がマスタデータベース２４に反映されること及びエンリッチ命令キュー１６６内のすべてのペンディング命令のクリアが複数のプリローダ１５２の再始動前に実行されること（このとき、マスタデータベース２４はすべての残高の最終バージョンを反映する）を保証するために特定の再始動プロセスが導入されている。

複数のプリローダ１５２及びポジショニングエンジンワーク１５４がどのように動作するかの非限定的な例が以下に与えられる。

実施例：
命令１(ins 1)はプリローダインスタンス１（マスタデータコレクタ１）により処理される。この命令は（パーティＡの）acc1と（パーティＢの）acc2との間のリソースアカウントタイプsec1に対する決済命令「Sec１の10担保をSec2の500単位と交換する」である。
命令２(ins 2)はプリローダインスタンス２（マスタデータコレクタ２）により処理される。この命令は（パーティＣの）acc 3と（パーティＢの）acc 2との間のsec1に対する決済命令「Sec１の20担保をSec2の1050単位と交換する」である。

２つの命令は並列に実行される。
インスタンス１により発生されるメッセージは次の通りである。
(命令のイメージ)＋(関連するバランス（残高）のイメージ: acc1/sec1=1000, acc2/sec1=300, acc1/sec2=25000, acc2/sec2=30000…)
インスタンス２により発生されるメッセージは次の通りである。
(命令のイメージ)＋(関連するバランスのイメージ: acc3/sec1=3000, acc2/sec1=300, acc3/sec2=5000, acc2/sec2=30000…)

２つのメッセージはポジショニングエンジンのエンリッチ命令キューに順に書き込まれる。
acc2/sec1及びacc2/sec2は同じ値で２度与えられることが明らかである。これらの値を最初に受信するときこれらの値（正確な値）を考察し、後から受信されるそれらの値は廃棄する（その代わりにメモリコピーを使用する）ことはポジショニングエンジン１５４の務めである。

ポジショニング結果は次の通りである。
インスタンス１から到来する命令を最初に処理する（順序は重要でない）
決済前のローカルメモリ１８６内のバランス：
<エンプティ>
決済後のメモリ内のバランス：
<acc1/sec1> = 990 (1000-10)
<acc2/sec1> = 310 (300+10)
<acc1/sec2 > =25500 (25000+500)
<acc2/sec2> =29500 (3000-500)

インスタンス２から到来する命令を処理する（順序は重要でない）
決済前のローカルメモリ１８６内のバランス（＝前命令に対する決済後のバランス）
<acc1/sec1> = 990 (1000-10)
<acc2/sec1> = 310 (300+10)
<acc1/sec2 > =25500 (25000+500)
<acc2/sec2> =29500 (3000-500)
決済後のメモリ内のバランス：
<acc1/sec1> = 990 (不変)
<acc2/sec1> = 330 (310+20:プリローダにより与えられた値300は廃棄される)
<acc1/sec2 > =25500 (不変)
<acc2/sec2> =28450 (29500-1500:プリローダにより与えられた値30000は廃棄される)
<acc3/sec1 > =2980 (3000-20)
<acc3/sec2> =6050 (5000+1050)

ファイナリティキュー１６８は本発明の重要な部分である。これは、与えられた命令の規則に関連する受諾可能性について行うポジショニングエンジン１５４の判断を命令の結果のリアルタイム報告及びマスタデータベース２４の更新と分離する手段を表す。この分離により、ポジショニングエンジン１５４はその処理タスクを最小にでき、従ってこのように分離されない場合より大きなスループットをもたらす。

ポジショニングエンジン１５４の最終的状態（スタンプはどんなことがあっても決済命令が確認されたことを報告する）には、ポジショニングエンジンのそれぞれの更新をマスタデータベースに反映させることによって到達するのではなく、それぞれの更新をファイナリティキュー１６８において更新実行命令にログすることによって到達する。換言すれば、ファイナリティ命令レコード（更新実行命令）はディスパッチャ１５６の入力キューであるファイナリティキュー１８６に書き込まれる。同時に、もとの処理命令はファイナル、即ち実行されたとみなされる。命令に対するパーティへの通知を発生するとともにそれぞれの更新をアップデータ１５８の異なる入力キュー（マスタデータ分離キュー１７０）に分散させることがディスパッチャ１５６の務めである。主な目的は、同じ論理作業単位内に報告活動とデータベースバランス更新が混在するのを避けることにある。

ポジショニングエンジン１５４により発生される出力は一つの持続性メッセージ（潜在命令を完了させるために実行すべきすべてのマスタデータベース更新を含む）に限定されるため、それらの更新を分散させるとともに命令実行に関する所要の報告（例えばリアルタイム個別命令操作プロセス１６２へのリプライ）を発生する専用のプロセスがディスパッチャ１５６により与えられえる。入力に受信された一つのメッセージに対して、ディスパッチャ１５６は出力（更新されたリソースにつき１つ及び発生される報告につき１つ）を書き込む。全体スループット要件に対処するために、このディスパッチロジックは並列にランする。ディスパッチャ１５６はスケーラブルである（２つ以上のプログラムコピーを実行することによりスループットが大きくなる）。

ディスパッチャ１５６により発生される報告メッセージのフォーマットは簡単には構造化テキストメッセージである。しかし、このフォーマットは、必要に応じ外部フォーマット又はＩＳＯフォーマットに変更することができる。更に、ディスパッチャは、セッション中に起こったすべてのトランザクション及び関連する各エンティティに対するリソースアカウントファイル３０及び集計リソース値３２に与えたそれらの影響の結果を記載する処理セッション報告を発生するように構成される。

ディスパッチャ１５６は、どのマスタデータアップデータ１９０が更新の実行を命令されるべきかを決定しない。むしろ、これは以下に記載するようにルーティングフレームワーク１７５及びワークフローバランサ１７６に任される。

ルーティングフレームワーク１７５はワークフロー分散を助けるために設けられる。初期入力キュー１６４への入力及びディスパッチャプログラム１８８のマスタ分離キュー１７０への出力（アップデータ１５８へと向う）はルーティングフレームワーク１７５及びワークロードバランサ１７６を介して送られる。ディスパッチャプログラム１８８は命令をルーティングフレームワーク１７５に、その命令の正確な宛先（マスタ分離キュー１７０）を知らずに送る。ルーティングフレームワーク１７５の目的は、プラットフォーム上で同時に動作する複数の可能なキューのうちの一つを個別経路指定する命令を生成することにある。本例では、ルーティングフレームワークは必要に応じて複数の初期入力キュー１６４の一つ又はマスタデータ分離キュー１７０のうちの一つへの経路を指定する命令を生成する。ルーティングフレームワーク１７５は２つの技術的なフィールド、メッセージ名及びワークロード分散キー、を付加する。メッセージ名はメッセージに含まれる情報のタイプを記述し、ワークロード分散キーは命令ＩＤに設定され、これにより２つの順次の実行試みが同じ報告順序で報告されることが保証され、例えばシーケンシング問題に起因する「決済された命令」に続いて「失敗した命令」を報告することが避けられる。

ルーティングフレームワーク１７５は、命令の経路指定をプロセス間で変更するために命令フローに新しいプロセスを付加する機能も有する。命令フローに新しい命令を付加して、プロセスからの命令の送出を抑圧し、必要に応じ命令を複製することもできる。メッセージ名及びワークロード分散キーを有する命令はワークロードバランサ１７６により以下に記載されるように操作される。

プラットフォーム１５０の動作において、ルーティングフレームワーク１７５の務めは、処理命令を送出する場合、誰に、どのフォーマットで及びどのインスタンス（並列処理のために）で送出するかを決定することにある。ルーティングフレームワーク１７５を使用して、一つの命令に対する報告は同じ命令に対する前報告の後に順序付けられるようにする。例えば、命令が最終的に受諾される前に数回失敗した場合に、該処理命令がサクセスフルに実行されたことの報告は同じ命令に対する失敗した決済報告メッセージの後に続かなければならない。また、各失敗した命令の報告も、命令送信パーティが失敗命令に正しく反応できるように順番に送出される。

実施例：第１命令の処理試みは失敗する。理由⇒パーティＡのリソースアカウントのレベルが命令をサポートするのに十分でない（パーティＡは何らかのアクションを取り得る）。次に、第２命令の処理試みも失敗する。理由⇒パーティＢのリソースアカウントのレベルが命令をサポートするのに十分でない（パーティＢは何らかのアクションを取り得る）。これを報告する場合、パーティＡのリソースアカウント失敗メッセージにパーティＢのリソースアカウント失敗メッセージが後続することが重要である。ディスパッチャモジュールが並列にランしているとき、一つの命令に対するすべての報告をディスパッチャ１５６の同じインスタンスで送出すること（命令ＩＤに基づくワークロード分散）がルーティングフレームワーク１７５の務めである。

ワークロードバランサ１７６は、命令名及び分散キー（図示せず）に基づいて命令の最終宛先を決定する。命令名及び分散キーは、処理プラットフォーム１５０により、併せて各命令を一意に記述するものとみなされる。メッセージ名は特定のマスタデータアップデータ１９０をフィードするターゲットマスタデータ分離キュー１７０を識別するために使用される（各マスタデータアップデータ１９０がどのように特定のタイプの更新に指示されるかについては後述する）。分散キーは特定のインスタンス（マスタデータ分離キュー１７０）を計算するのに使用される。ワークロードバランサ１７６は、同じ分散キーに対して、常に同じインスタンス（マスタデータ分離キュー１７０）を選択することを保証する（以下の簡単な実施例参照）。

実施例：
メッセージ名＝SECURITY_BALANCE_UPDATE⇒担保残高更新
分散キー＝担保id＝13
並列にランする担保アップデータの総数= 3
選択されるインスタンス= 13 - (整数(13/3*3) + 1
= 13 - (4*3) + 1
= 13 - 12 + 1 = 2
⇒担保id 13に対して更新を行う必要がある度に、インスタンス番号２が選択される。

マスタデータ分離キュー１７０の各々は、ルーティングフレームワーク１７５及びワークロードバランサ１７６により当該キュー１７０に明確に経路指定されたディスパッチャプログラム１８８からの命令を単に受信する。各マスタデータ分離キュー１７０は特定のマスタデータアップデータ１９０に関連し、このアップデータはマスタデータベース２４の特定の部分２４ａ，３４ｂ，２４ｃにのみ作用する。

アップデータ１５８は、マスタデータベース２４の一つの特定部分２４ａ，２４ｂ，２４ｃに、ポジショニングエンジン１５４によりファイナルとして宣言された更新命令を反映させるために設けられている。各マスタデータアップデータは固有のデータベース部分に独立に作用するため、他の更新プロセスにより発生される潜在的なロックにより影響されない。更に、各アップデータ１９０はそれが管理する一組のリファレンスデータを更新するだけであるため、更新命令のネッティング（相殺決算）を実行することができる。アップデータの各インスタンスは、（該インスタンスが経路指定されるアップデータを識別するために使用される）固有の一連のキーに基づいて働き、それらのキーがマスタデータベースの特定の部分に対して孤立しているかいないかはとはない。

アップデータ１５８を具体的にどのように実施するかについては２つの異なる実施例がある。一つの実施例では、更新命令（更新）はデルタ（差額）、即ちリソースアカウントファイルの値に対する変化により文書化される。別の実施例では、更新はリソースアカウントファイルの最終値で文書化される。これらの実施例はネッティングを実行するものとして以下に説明される。

更新がデルタで文書化される場合、マスタデータアップデータ１９０により実行されるネッティングアルゴリズム（図示せず）は、所定のリソースアカウントファイルに対する各命令の移動を、当該リソースアカウントファイル３０に対する一つの単一の更新を実行する前に合計するステップを含む。更新が最終値で文書化される場合、ネッティングはより高い更新タイムスタンプを有する値を維持し、更新メッセージの「〜の場合」節においてタイムスタンプ検証を加えるステップを含む。

更に正確に言うと、最終値モデルでは、ネッティングプロセスはポジショニングエンジン１５４により実行された最終更新を維持しようとする。更新順序は保証されないので、ネッティングアルゴリズムは、１２：４５：０３における最終値が既に受信された後に例えば１２：４５：０１における最終値を受信する可能性がある。更新を実施するためには、１２:４５:０３における最終値のみを考慮する必要がある。例えば１２：４５：０６における最終値が既にデータベースに反映されている場合には、１２：４５：０３における最終値は無視しなければならない。これは、マスタデータを更新する際にタイムスタンプを用いて以下に記載するように行うことができる。

EXEC SQL UPDATE PP_SEC_BAL
SET BLANCE_VALUE＝入力に受信される最終値
バランスタイムスタンプ＝最終値ポジショニングタイムスタンプ
バランスＩＤ＝更新要求からのバランスＩＤ及び
バランスタイムスタンプ（ＤＢ内）＜最終値ポジショニングタイムスタンプの場合

アップデータにより受信されるアップデータメッセージはファイナル（どこへでも供給可能）である。これは、これらのメッセージは、同じキーに対する２つの順次の更新命令が単一の物理的更新に変換されるようにグループ化することができることを意味する。

最終値実施例及びデルタ値実施例がどのように動作するかを以下に例示する。
最終値に対する実施例
アップデータは次の入力を順に受信する。
バランス1 10000 2007-08-01-09.01.01.112335(マイクロ秒単位)
バランス1 12500 2007-08-01-09.01.02.100475
バランス1 25000 2007-08-01-09.01.01.875221
バランス1 12500 2007-08-01-09.01.02.077054

マスタデータアップデータ１９０はすべての最新情報を順に読み出す。
第１の値に対して、アップデータはその値を維持する（最初に現在の論理作業単位においてバランスが参照される）。
第２の値に対して、アップデータはそのメモリ内の前値を上書きする（その要求は第１のものに比較して未来である）。
第３の値に対して、その要求は第２の値より前に発生されたため、アップデータはその値を廃棄する。
第４の値に対して、その要求も第２の値より前に発生されたため、アップデータはその値を廃棄する。

コミットタイム（コミット周波数）で、物理的更新が発生する：
EXEC SQL UPDATE SETバランス値＝12500
タイムスタンプ＝2007-08-01-09.01.02.100475

バランスid＝バランス１及びタイムスタンプ＜2007-08-01-09.01.02.100475の場合
データベース内のイメージが申請されたものに比較して既に未来である場合、タイムスタンプ条件が更新要求を中止する。

デルタに対する実施例
マスタデータアップデータ１９０は次の入力を順に受信する。
バランス1 10000 2007-08-01-09.01.01.112335(マイクロ秒単位)
バランス1 12500 2007-08-01-09.01.02.100475
バランス1 25000 2007-08-01-09.01.01.875221
バランス1 12500 2007-08-01-09.01.02.077054

マスタデータアップデータ１９０はすべての最新情報を順に読み出す。
第１の値に対して、アップデータはその値を維持する（最初に現在の論理作業単位においてバランスが参照される）。
第２の値に対して、アップデータはデルタ10000+12500=22500の加算を行う。
第３の値に対して、アップデータはデルタ22500+25000=47500の加算を行う。
第４の値に対して、アップデータはデルタ47500+12500=60000の加算を行う。

コミットタイム（コミット周波数）で、物理的な更新が発生する：
EXEC SQL UPDATE SETバランス値＝バランス値＋60000
バランスid＝バランス１の場合

キューがペーシングモジュール１７４を介して通常空にされることは、プラットフォームを通る命令のフローに実施される唯一の制御ではない。リアルタイム処理中、デリミタフレームワーク１７８は、処理セッションの終了時にディスパッチャ１５６内の活動の報告を開始するために処理セッションの終了前に実行されたすべての更新がマスタデータベース２４に正しく反映されるようにする。

ファイナリティキュー１６８への更新実効命令の書き込みは、マスタデータベースの更新がまだ実行されていない場合でも、プラットフォーム１５０による命令の最終実行とみなすことができる。しかし、技術的観点からすると、依然として、更新実行命令はマスタデータベースリソースアカウント３０の値に依存する前にマスタデータベース２４において実際に実行されるようにする必要がある。

この目標制約を達成するために、デリミタフレームワーク１７８は要求／応答メッセージをファイナリティキューのトップに書き込む基本的な機能を提供する。これは、応答が受信されるとき、ファイナリティキューに先に書き込まれたすべての命令が実行されたことを意味する。

プラットフォーム１５０における命令処理フローは順に実行される一連のプロセスからなる。特に、マスタデータ分離キュー１７０は更新実行命令を、それらがファイナリティキューを通過した後にのみ操作する。従って、ファイナリティキューから応答が受信されると同時に、新しい要求／応答メッセージが次のキュー、即ちマスタデータ分離キュー１７０に順に送られる。各キューはＦＩＦＯシーケンス動作する。

デリミタフレームワーク１７８の機能は、マスタデータベースが更新された正しいデータを有するかを検査するのではなく、すべての更新実効命令が実行されたかを検査するものであり、この検査はシステムの種々の処理段階を通してシーケンシャルに実行される。

並列処理が実行されるとき、プロセスは複数のキューで並列に実行することができる。すべてのキューがそれらのバックログを処理したことを確かめるために、要求／応答メッセージをそれらの一つのみならず全部に書き込まなければならない。このメッセージをプロセスのｎ個のインスタンスに送るのがルーティングフレームワーク１７５の務めであり、ｎ個の応答が次のプロセスのデリミトを開始する前に受信されるまで待つのがデリミタフレームワークの務めである。

下記の例は、アップデータ１５８による更新実行命令の実行を処理セッションの終了後に行わせるためにデリミタフレームワーク１７８がどのように動作するかを示す。

実施例
プラットフォーム１５０は命令実行の（最終）期限を特定の時刻、例えば午後４時に規定する。期限に達すると同時に、報告プロセスが処理セッション活動に関連するパーティに送るべきシーケンシャル報告ファイルを形成するためにマスタデータベースから実行された命令のすべてを抽出する。

午後４時に、スケジューラが報告プロセスを開始する。
このプロセスの第１のステップとして、デリミタユーティリティ（図示してないがデリミタフレームワーク１７８の一部である）が使用され、デリミタメッセージを生成し、デリミタカーネル（図示してないがデリミタフレームワーク１７８の一部である）に送る。受信メッセージに基づいて、デリミタカーネルは、ポジショニングエンジン１５４によりファイナルと宣言されたすべての更新情報がマスタデータベースに反映される（ディスパッチャ１８８及びアップデータ１９０）ようにデリミトすべき種々のプロセスへのメッセージの書き込みを開始する。

報告プロセスの第２のステップとして、デリミタ終了検査ユーティリティ（図示してないがデリミタフレームワーク１７８の一部である）が実行される。このユーティリティはデリミタプロセスがデリミタカーネルにより終了と宣言されるまで報告プロセスを保留する。これが行われると、報告プロセスの実行は次のステップで再開される。

報告プロセスの第３のステップとして、ディスパッチャ１８８内の報告ビジネスロジックがマスタデータに含まれる正確なデータに基づいて実行される。

抽出報告タスクはデリミタフレームワーク１７８に、午後４時の期限前に到来した更新実行命令が報告目的のためにディスパッチャ１５６により処理されように要求するとともに、それらの更新実行命令がマスタデータベース２４にも供給されるように要求する。これが行われると、マスタデータベース２４の状態が期限前に確認されたすべての活動を反映し、抽出報告が上述したように正確に発生される。

図８−図１２の実施例に関連して上述した特徴は添付の請求項に記載されている。上述した特徴の一部分を用いて本発明の他の実施例を生成することができることに留意されたい。例えば、他の実施例は上述した再利用技術を使用しないで、既知の代替技術を使用してもよい。同様に、ペーシングモジュールは異なる可決をもたらすべく変更又は除去してもよい。しかし、代替で処理構造の選択にあたっては、スループットへの影響を考慮する必要がある。本発明の場合には、請求の範囲に記載された処理構造は最大可能なスループットを提供する最適構造である。ペーシングモジュールなどの特徴部はとにかくスループットを高める。

本発明を特定の好適実施例について説明したが、これらの実施例は例示にすぎず、特許請求の範囲に記載された本発明の範囲から離れることなく種々の変更及び変形が当業者に明らかである。

Claims (27)

1. 極めて多数の処理命令をリアルタイムに処理及び操作するシステムであって、各処理命令は２つの異なるエンティティに関するリソースアカウントデータファイル及びこれらのファイル間で交換されるリソースの量及びタイプを指定するものであり、該システムは、
   複数のプリローダを備え、各プリローダは前記処理命令に関連するリファレンスデータを取得するように構成され、前記リファレンスデータは指定されたリソースアカウントデータファイルの各々の現在値を示し、前記複数のプリローダは並列に動作して複数のそれぞれの受信処理命令に対する前記リファレンスデータをマスタデータベースから読み出すように構成され、更に
   複数の前記処理命令をそれらのそれぞれのプリロードされたリファレンスデータと一緒にキューイングするエンリッチ命令キューと、
   受信した前記リファレンスデータを用いて、各受信処理命令を関連するリソースアカウントファイルの現在値に基づいて実行できるかどうかをシーケンシャルに決定し、各実行可能な処理命令に対して更新コマンドを発生するように構成された実行エンジンと、
   前記実行エンジンからの前記更新コマンドに応答して、前記マスタデータベースを各実行可能な命令の結果で更新する複数のアップデータと、
   を備え、前記複数のアップデータの動作が前記実行エンジンの動作から分離されている、システム。
2. 複数の異なるソースからリアルタイム命令及びバッチ命令を受信し、これらの命令を前記複数のプリローダへの入力のためにキューイングするように構成された初期入力キューを更に備える、請求項１記載のシステム。
3. 前記初期入力キューは複数の初期入力キューを備え、前記複数の初期入力キューの一つが前記複数のプリローダの対応する一つへの専用の入力を提供する、請求項２記載のシステム。
4. 前記初期入力キュー叉は前記複数の初期入力キューの各々は入力する各命令に優先順位を指定するように構成されている、請求項２又は３記載のシステム。
5. 前記実行エンジンに格納された現在状態テーブルを更に備え、前記現在状態テーブルは、更新されたリソースアカウントファイルの各々の更新されたリアルタイム値の表現が得られるように、前記リソースアカウントファイルに対して実行された命令の結果で更新されるように構成され、前記実行エンジンは、後続の命令のシーケンシャル処理のために、特定のリソースアカウントファイルに対して、前記現在状態テーブル内の情報を前記プリローダからのリファレンス情報に優先して使用するように構成されている、請求項１−４のいずれかに記載のシステム。
6. 各プリローダはマスタデータコレクタを備え、各マスタデータコレクタは、前記マスタデータベースから、前記命令に指定されるリソースアカウントファイルの値及び集計リソース値を読み出し、前記マスタデータベースから読み出されたデータを含むエンリッチ処理命令を編集し出力するように構成されている、請求項１−５のいずれかに記載のシステム。
7. 前記実行エンジンは前記現在状態テーブルを格納する高速ローカルデータメモリを備える、請求項１−６のいずれかに記載のシステム。
8. 前記実行エンジンは、格納されている一群の所定の規則を参照することによって現在命令を関連するリソースアカウントファイルの現在値に基づいて実行できるかどうかを決定するように構成されている、請求項１−７のいずれかに記載のシステム。
9. 前記実行エンジンは、前記処理命令の一つの受信時刻を決定し、タイプスタンプを生成し、これを前記処理命令に付与するように構成されたタイムスタンプモジュールを備える、請求項１−８のいずれかに記載のシステム。
10. 前記実行エンジンは、失敗した処理命令のリストを高速のローカルデータストアに格納し、前記失敗した処理命令により特定されるリソースアカウントファイルにおいて更新が起こった後に、前記失敗した処理命令が再実行のために提示される場合に再利用プロシージャを実行する再利用モジュールを備える、請求項１−９のいずれかに記載のシステム。
11. 前記再利用モジュールは、前記失敗命令をそれらの優先順位の順に格納し、再利用プロシージャの間最高優先順位の命令を再実行のために最初に提示するように構成されている、請求項１０記載のシステム。
12. 前記再利用モジュールは、前記リスト内の命令に関するリソースアカウントファイルの現在値を留保し、この留保された量を再利用プロシージャ中に命令の要件をかなえるために利用するように構成されている、請求項１０又は１１記載のシステム。
13. 前記再利用モジュールは、失敗処理命令を再実行のために所定の最大回数にわたり提示し、この失敗命令が依然として実行されなかった場合に、この失敗命令をキャンセルするように構成されている、請求項１０又は１２記載のシステム。
14. 前記実行エンジンは、前記受信命令の一つの実行の結果を報告する報告モジュールを備え、前記報告モジュールは、実行できると決定された各命令に対して更新コマンドを出力し、各失敗命令に対して通知命令を出力するように構成されている、請求項１−１３のいずれかに記載のシステム。
15. 前記報告モジュールは、コミットイベントが発生するまで複数の更新コマンドを一時的にストアし、コミットイベントの発生時に前記ストアされている複数の更新コマンドを出力するように構成され、前記コミットイベントは前記実行エンジンによる一つの物理的作業単位の終了を表す、請求項１４記載のシステム。
16. 前記報告モジュールからの前記更新コマンド及び前記通知命令を受信するように構成されたファイナリティキューを更に備える、請求項１−１５のいずれかに記載のシステム。
17. 各アップデータは並列に動作する複数の更新インスタンスを備え、各インスタンスは前記マスタデータベースの特定の部分で動作する、請求項１−１６のいずれかに記載のシステム。
18. 各更新インスタンスに対して分離入力キューを更に備え、各分離入力キューは対応する更新インスタンスにより更新される前記マスタデータベースの特定の部分に関係する複数の更新コマンドを受信するように構成されている、請求項１７記載のシステム。
19. 各分離入力キューは、更新コマンドが同じリファレンスアカウントファイルに関係する場合に、更新コマンドのネッティングを実行するように構成されている、請求項１８記載のシステム。
20. 各更新コマンドの特定の分離入力キューへの経路を決定し、実効命令の失敗又は成功を記述する、前記異なるエンティティのための報告メッセージを生成するように構成されたディスパッチャを更に備える、請求項１８又は１９記載のシステム。
21. ルーティングフレームワークを更に備え、前記ルーティングフレームワークは、命令を同時に動作する複数の初期入力キュー又は分離入力キューに分配するように構成されている、請求項３に従属する請求項１８又は２０記載のシステム。
22. 前記ルーティングフレームワークは、命令が関連する情報のタイプを記述する命令名及び命令を特定する一意のキーを提供するワークロードバランサキーを命令に指定するように構成されている、請求項２１記載のシステム。
23. 前記ルーティングフレームワークは、当該ルーティングフレームワークと共同して、受信した前記命令名及びワークロードバランサキーを用いて、前記複数の初期入力キュー又は分離入力キューのうちの一つを選択するように構成されているワークロードバランサを備える、請求項２２記載のシステム。
24. 前記ワークロードバランサは、特定のリソースアカウントデータファイルに関連するすべての命令が常に前記複数のキューのうちの同じ一つに経路指定されるようにするために、所定のワークロードバランサキーを同じ特定の宛先にリンクするように構成されている、請求項２３記載のシステム。
25. 所定の時刻における処理セッションの終了に応答して、メッセージを前記実行エンジンの出力に設けられたキューの入力に送り、その応答を待ち、更なるメッセージを前記複数のアップデータの一つの入力キューに送り、その応答、即ち前記処理セッションの終了前に実行された処理命令のすべての結果による前記マスタデータベースの更新を示すシーケンシャル応答の受信を待つように構成されたデリミタフレームワークを更に備える、請求項１−２４のいずれかに記載のシステム。
26. 前記デリミタフレームワークは、更に、メッセージを前記ディスパッチャモジュールの入力キューに送り、前記処理セッションの終了前に実行された処理命令に対する報告メッセージがすべて送信されたことを確認するためにそれぞれのフィードバックを待つように構成されている、請求項２５記載のシステム。
27. 前記実行エンジンの処理命令のスループットを測定し、処理命令のローディング速度を前記実行エンジンのスループットより低くするために任意のキューに待ち状態を与えるペーシングモジュールを更に備える、請求項１−２６のいずれかに記載のシステム。

Images