特許 6906771 アプリケーション実行のための公開−加入フレームワーク

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】6906771

(24)【登録日】2021年7月2日

(45)【発行日】2021年7月21日

(54)【発明の名称】アプリケーション実行のための公開−加入フレームワーク

(51)【国際特許分類】

   G06F 9/54 20060101AFI20210708BHJP

【ＦＩ】

   G06F9/54 A

【請求項の数】15

【全頁数】33

(21)【出願番号】特願2020-560169(P2020-560169)

(86)(22)【出願日】2019年4月26日

(86)【国際出願番号】EP2019060728

(87)【国際公開番号】WO2019207104

(87)【国際公開日】20191031

【審査請求日】2020年12月24日

(31)【優先権主張番号】62/663,422

(32)【優先日】2018年4月27日

(33)【優先権主張国】US

(31)【優先権主張番号】16/394,109

(32)【優先日】2019年4月25日

(33)【優先権主張国】US

【早期審査対象出願】

(73)【特許権者】

【識別番号】508364093

【氏名又は名称】ナスダック テクノロジー エービー

(74)【代理人】

【識別番号】100076428

【弁理士】

【氏名又は名称】大塚 康徳

(74)【代理人】

【識別番号】100115071

【弁理士】

【氏名又は名称】大塚 康弘

(74)【代理人】

【識別番号】100112508

【弁理士】

【氏名又は名称】高柳 司郎

(74)【代理人】

【識別番号】100116894

【弁理士】

【氏名又は名称】木村 秀二

(74)【代理人】

【識別番号】100130409

【弁理士】

【氏名又は名称】下山 治

(72)【発明者】

【氏名】アドルフソン， ロバート

(72)【発明者】

【氏名】ヒルトン， ダニエル

【審査官】 漆原 孝治

(56)【参考文献】

【文献】 米国特許第７８２２７２８（ＵＳ，Ｂ１）

【文献】 米国特許出願公開第２００９／０１３２６７１（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１２／０２８４３３１（ＵＳ，Ａ１）

【文献】 欧州特許出願公開第３１２８４２３（ＥＰ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／４５５ − ９／５４

Ｇ０６Ｆ １５−１６ − １５／１７７

(57)【特許請求の範囲】

【請求項1】

電子取引所システムであって、
共有メモリと、
通信インフラストラクチャと、
前記通信インフラストラクチャによって前記共有メモリに結合された複数の処理リソースを備える処理システムと、
を備え、前記処理システムは、
前記処理リソースのそれぞれにおいて、ゲートウェイアプリケーションの処理パイプラインの複数のパイプラインステージのうちの少なくとも１つのパイプライン処理ステージを実行することと、
前記共有メモリを使用して公開−加入メッセージを介して前記複数のパイプラインステージのうちのいずれか２つの間の通信を提供することと、
受信したデータメッセージに応じて、前記ゲートウェイアプリケーションにおいて前記データメッセージを処理するためのセッションを作成することと、
前記セッションを作成することに応じて、
前記セッションに、前記ゲートウェイアプリケーションの前記処理パイプラインの前記複数のパイプラインステージのそれぞれをパブリッシャおよび／またはサブスクライバとして登録することと、
出力メッセージを生成するために、前記ゲートウェイアプリケーションの前記処理パイプラインの前記複数のパイプラインステージのそれぞれにおける前記データメッセージを処理することによって前記ゲートウェイアプリケーションの前記データメッセージの処理を完了することと、
前記出力メッセージをマッチングエンジンに送信することと、
を含み、前記データメッセージを処理している間の前記複数のパイプラインステージ間の通信は、前記セッション内の前記パブリッシャおよび／またはサブスクライバ登録に従って発生する、動作を実行するように構成される電子取引所システム。

【請求項2】

請求項１に記載の電子取引所システムであって、前記処理システムはさらに、
前記複数のパイプラインステージのそれぞれをスレッドとして実行し、
前記パイプラインステージのそれぞれについて、前記セッション、サブスクライバ、および／またはパブリッシャに関連付け、
関連付けられた前記パブリッシャおよび関連付けられた前記サブスクライバの間でパブリッシャとサブスクライバとの個別のペアの間でメッセージが交換されるようにすることによって、前記データメッセージを処理する、
ように構成される電子取引所システム。

【請求項3】

請求項２に記載の電子取引所システムであって、前記処理システムはさらに、
制御セッションをインスタンス化し、
前記パイプラインステージのそれぞれを前記制御セッションに加入させ、
前記制御セッションに公開することによって、シグナリングのために１つ以上の所定のイベントを前記複数のパイプラインステージに提供する、
ように構成される電子取引所システム。

【請求項4】

請求項２に記載の電子取引所システムであって、前記処理システムはさらに、パブリッシャとサブスクライバとの個別のペアの間でメッセージの前記交換を実行させることであって、前記メッセージのうちの１つを前記共有メモリ内の領域に格納し、前記領域へのポインタを前記サブスクライバのうちの少なくとも１つに提供することによって、メッセージの前記交換を実行させる、ように構成される電子取引所システム。

【請求項5】

請求項４に記載の電子取引所システムであって、前記処理システムはさらに、前記領域をロックフリーキューとして構成するように構成される電子取引所システム。

【請求項6】

請求項２に記載の電子取引所システムであって、前記処理システムはさらに、
プログラムコードを受信し、
それぞれがイングレス・メッセージ・インタフェースおよびエグレス・メッセージ・インタフェースを備える前記複数のパイプラインステージを取得するために前記プログラムコードを分解する、ように構成される電子取引所システム。

【請求項7】

請求項６に記載の電子取引所システムであって、前記処理システムはさらに、１つ以上の設定パラメータに従って前記分解を実行するように構成される電子取引所システム。

【請求項8】

請求項６に記載の電子取引所システムであって、前記処理システムはさらに、前記複数の処理リソースへの前記複数のパイプラインステージの配置を決定するように構成される電子取引所システム。

【請求項9】

請求項８に記載の電子取引所システムであって、前記処理システムはさらに、前記パイプラインステージの前記イングレス・メッセージ・インタフェースおよび前記エグレス・メッセージ・インタフェースに基づいて前記配置を決定するように構成される電子取引所システム。

【請求項10】

請求項１に記載の電子取引所システムであって、前記処理システムはさらに、前記データメッセージに関してマッチングエンジンにアクセスすることによって、前記データメッセージの前記処理を実行するように構成される電子取引所システム。

【請求項11】

請求項１０に記載の電子取引所システムであって、前記処理システムはさらに、トレードリクエストと別のトレードリクエストとに対して並行して前記マッチングエンジンに前記アクセスすることによって、複数の前記パイプラインステージにおいて前記データメッセージの前記処理を実行するように構成される電子取引所システム。

【請求項12】

請求項１１に記載の電子取引所システムであって、前記処理システムはさらに、前記マッチングエンジンに前記アクセスするためのパイプラインステージのインスタンスの数を動的に決定するように構成される電子取引所システム。

【請求項13】

共有メモリと、通信インフラストラクチャと、前記通信インフラストラクチャによって前記共有メモリに結合された複数の処理リソースを備える処理システムとを有する電子取引所システム上でデータメッセージを処理する方法であって、
前記処理リソースのそれぞれにおいて、ゲートウェイアプリケーションの処理パイプラインの複数のパイプラインステージのうちの少なくとも１つのパイプライン処理ステージを実行することと、
前記共有メモリを使用して公開−加入メッセージを介して前記複数のパイプラインステージのうちのいずれか２つの間の通信を提供することと、
受信したデータメッセージに応じて、前記ゲートウェイアプリケーションにおいて前記データメッセージを処理するためのセッションを作成することと、
前記セッションを作成することに応じて、
前記セッションに、前記ゲートウェイアプリケーションの前記処理パイプラインの前記複数のパイプラインステージのそれぞれをパブリッシャおよび／またはサブスクライバとして登録することと、
出力メッセージを生成するために、前記ゲートウェイアプリケーションの前記処理パイプラインの前記複数のパイプラインステージのそれぞれにおける前記データメッセージを処理することによって前記ゲートウェイアプリケーションの前記データメッセージの処理を完了することと、
前記出力メッセージをマッチングエンジンに送信することと、
を含み、前記データメッセージを処理している間の前記複数のパイプラインステージ間の通信は、前記セッション内の前記パブリッシャおよび／またはサブスクライバ登録に従って発生する、方法。

【請求項14】

請求項１３に記載の方法であって、
前記複数のパイプラインステージのそれぞれをスレッドとして実行することと、
前記パイプラインステージのそれぞれについて、セッション、サブスクライバ、および／またはパブリッシャに関連付けることと、
関連付けられた前記パブリッシャおよび関連付けられた前記サブスクライバの間でパブリッシャとサブスクライバとの個別のペアの間でメッセージが交換されるようにすることで前記データメッセージを処理することと、
をさらに含む方法。

【請求項15】

請求項１３に記載の方法であって、パブリッシャとサブスクライバとのそれぞれのペアの間でメッセージを交換させることであって、前記メッセージのうちの１つを前記共有メモリ内の領域に格納し、前記サブスクライバのうちの少なくとも１つへの前記領域へのポインタを提供することによってメッセージを交換させることをさらに含む方法。

【発明の詳細な説明】

【技術分野】

【0001】

［関連出願の相互参照］
本出願は２０１８年４月２７日に出願された米国仮特許出願第６２／６６３，４２２号の優先権を主張し、その全内容は、参照により本明細書に組み込まれる。

【0002】

［技術概要］
記載される技術は例えば、株式および他の取引可能な商品のための電子取引所アプリケーションのような、アプリケーションの構成要素の非同期同時実行を容易にする公開−加入フレームワークに関する。

【発明の概要】

【0003】

［背景］
アプリケーションの高速化は、アプリケーションアーキテクト、プログラマ、ハードウェアエンジニアにとって常に存在する目標である。アプリケーションが最初から最後まで実行を完了できる速度が速いほど、アプリケーションとハードウェアリソースの効率が向上する。コンピュータ上での命令実行を高速化することを目的として、多くのハードウェア改良が行われている。ソフトウェア設計、コンパイル、および実行はすべて、実行を高速化するために進歩した。あるレベルのスピードアップを達成するために、アプリケーションを設計するための多くの技術が知られている。

【0004】

アプリケーションプログラムのためのソフトウェアを設計するいくつかの周知の技術ではアプリケーションがいくつかの処理段階に分解され、そこでは各段階がメッセージのセット（入口（イングレス）メッセージ）を入力として受け取り、受け取った入力メッセージを用いて何らかの処理を行い、出力として別のメッセージのセット（出口（エグレス）メッセージ）を生成する。このタイプの処理はアプリケーションが「メインループ」を有するように設計され、「イベント」の関連する待ち行列が通常待ち行列に入れられた順序で処理されるイベントまたはメッセージ駆動システムにおけるアプローチに類似しているが、「メインループ」は状況によっては最良のスピードアップを提供しないことがある。

【0005】

したがって、アプリケーション実行を高速化するためのより新しい有用な技法が求められている。
欧州特許出願公開第３１２８４２３号明細書には、イベント処理に適合されたデータ処理システムおよび方法が開示されている。開示された例は、サーバ計算デバイス間でのデータ処理動作の分散のために提供される。一例では、複数の処理ステージがサーバ計算デバイス上の計算インスタンスを使用して実施される。この場合、計算インスタンスは少なくとも１つのデータ処理動作を並行して実行するためにサーバ計算デバイスへ割り当てられる。

【0006】

［著作権通知］
本特許文書の開示の一部は、著作権保護の対象となるデータを含む。著作権所有者は特許商標局の特許ファイルまたは記録に記載されている、特許文献および特許開示については誰でも自由にファクシミリにより複写することに異論はないが、その他の場合にはすべての著作権を保有する。

【0007】

［発明の概要］
本発明は、複数の処理段階に分解されたアプリケーションがアプリケーションの各処理段階を非同期かつ同時に実行することによって実行される、公開−申込（パブリッシュ−サブスクライブ）メッセージ・フレームワークに関するものである。それぞれの処理ステージ間の通信は、パブリッシュ−サブスクライブ実行モデルに排他的に従うことができる。記載されたパブリッシュ−サブスクライブ・フレームワークはマルチプロセッサ／マルチコア処理環境におけるそれぞれの処理リソースへの処理ステージの分散を可能にしながら、マルチプロセスおよび／またはマルチスレッド方式で実行されるべき処理ステージを提供する。
一態様によれば、請求項１で定義される電子取引所システムが提供される。別の態様によれば、請求項１２で定義される電子取引所システム上でのデータメッセージの処理方法が提供される。さらに別の態様によれば、請求項１４で定義される非一時的なコンピュータ可読記憶媒体が提供される。

【0008】

一実施形態によれば、電子取引所システムが提供される。電子取引所システムは、共有メモリと、通信インフラストラクチャと、通信インフラストラクチャによって共有メモリに結合された複数の処理リソースを備える処理システムとを備える。処理システムはアプリケーションの処理パイプラインの複数のパイプライン処理ステージの少なくとも１つのパイプライン処理ステージを処理リソースのそれぞれで実行し、データメッセージを非同期かつ同時に複数のパイプラインステージで処理して出力メッセージを生成し、アプリケーション内のデータメッセージの受信データメッセージ完了処理に応答して、共有メモリを使用してパブリッシュ−サブスクライブ・メッセージを介して複数のパイプラインステージのいずれか２つのパイプラインステージ間の通信を提供し、出力メッセージを送信するように構成される。

【0009】

別の実施形態によれば、電子取引所システム上でデータメッセージを処理する方法が提供される。電子取引所システムは、共有メモリと、通信インフラストラクチャと、通信インフラストラクチャによって共有メモリに結合された複数の処理リソースを備える処理システムとを有する。本方法は、アプリケーションの処理パイプラインの複数のパイプライン処理ステージの少なくとも１つのパイプライン処理ステージを、処理リソースの各々で実行することと、共有メモリを用いてパブリッシュ−サブスクライブ・メッセージを介して複数のパイプラインステージのうちの任意の２つのパイプラインステージ間で通信することと、受信データメッセージに応答して、出力メッセージを生成するために複数のパイプラインステージの非同期かつ同時実行でデータメッセージを処理することによってアプリケーション内のデータメッセージの処理を完了することと、出力メッセージを送信することと、を含む。

【0010】

別の実施形態によれば、非一時的なコンピュータ可読記憶媒体が提供される。記憶媒体は通信インフラストラクチャによって共有メモリに結合された複数の処理リソースを備える処理システムによって実行されると、電子取引所システムの処理システムに、処理リソースのそれぞれにおいて、アプリケーションの処理パイプラインの複数のパイプラインステージのうちの少なくとも１つのパイプラインステージを実行することと、共有メモリを使用してパブリッシュ−サブスクライブ・メッセージを介して複数のパイプラインステージのうちのいずれか２つの間で通信を提供することと、受信されたデータメッセージに応答して、出力メッセージを生成するために非同期かつ同時に実行している複数のパイプラインステージのデータメッセージを処理することによってアプリケーション内のデータメッセージの処理を完了することと、出力メッセージを送信することとを備える動作を実行させる命令を記憶する。

【0011】

この概要は、以下の「発明を実施するための形態」でさらに説明されるコンセプトの選択を簡略化された形態で紹介するために提供される。本発明の概要はクレームされた主題の主要な特徴又は必須の特徴を特定することも、クレームされた主題の範囲を限定するために使用することも意図されておらず、むしろ、本発明の概要は本明細書に記載された主題の概要を提供することを意図している。したがって、上記の特徴は単なる例であり、本明細書で説明される主題の他の特徴、態様、および利点は、以下の詳細な説明、図、および特許請求の範囲から明らかになることが理解されるであろう。

【図面の簡単な説明】

【0012】

【図1】図１は、いくつかの例示的な実施形態に係る、アプリケーションコンポーネントの非同期および同時実行のためにパブリッシュ−サブスクライブ・フレームワークが使用される例示的なコンピューティング環境を示す。

【0013】

【図2】図２は、いくつかの例示的な実施形態に係る、アプリケーションの高レベル図、図１に示されるような環境で使用するための複数のステージへのアプリケーションの分解、およびマルチコアおよび／またはマルチプロセッサ処理環境で展開されているステージを示す。

【0014】

【図3】図３は、いくつかの例示的な実施形態に係る、例示的なアプリケーションのステージを実行するためのオブジェクトまたはエンティティのいくつかのデータ構造、およびデータ構造間のいくつかの関係の概略図を示す。

【0015】

【図4】図４は、いくつかの例示的な実施形態に係る、公開および加入を表す例示的なアクティビティフローを示す。

【0016】

【図5】図５は、いくつかの例示的な実施形態に係る、新しいパブリッシャを追加することを表す例示的なアクティビティフローを示す。

【0017】

【図6】図６は、いくつかの例示的な実施形態に係る、パブリッシュ−サブスクライブ・フレームワークにおいて展開されている、図１に示されるゲートウェイアプリケーションなどの例示的なアプリケーションを示す。

【0018】

【図7】図７は、いくつかの例示的な実施形態に係る、セッションの初期接続および許可のための動作の例示的なシーケンスを示す。

【0019】

【図8】図８は、いくつかの例示的な実施形態に係る、図６に示されるゲートウェイアプリケーションにおけるユーザセッションの確立のための動作の例示的なシーケンスを示す。

【0020】

【図9】図９は、いくつかの例示的な実施形態に係る、図６に示されるゲートウェイアプリケーションにおけるゲートウェイ・トランザクション・イングレス・パイプラインのための動作の例示的なシーケンスを示す。

【0021】

【図10】図１０は、いくつかの例示的な実施形態に係る、図６に示されるゲートウェイアプリケーションにおけるゲートウェイ・トランザクション・エグレス・パイプラインのための動作の例示的なシーケンスを示す。

【0022】

【図11】図１１は、いくつかの例示的な実施形態に係る、パブリッシュ−サブスクライブ・フレームワークにおいて展開されている、図１に示されるような電子取引所アプリケーションなどの例示的なアプリケーションを示す。

【0023】

【図12】図１２は、いくつかの例示的な実施形態に係る、図１１の電子取引所アプリケーションにおけるマッチング・エンジン・パイプラインのための動作の例示的なシーケンスを示す。

【0024】

【図13】図１３は、いくつかの例示的な実施形態に係る、図１１の電子取引所アプリケーションにおける動的マッチング・エンジン・パイプラインのための動作の例示的なシーケンスを示す。

【0025】

【図14】図１４は、いくつかの例示的な実施形態に係る、パブリッシュ−サブスクライブ・フレームワークを実施するために使用され得るコンピュータを概略的に示す。

【発明を実施するための形態】

【0026】

以下の説明では、説明および非限定の目的のために、説明された技術の理解を提供するために、特定のノード、機能エンティティ、技法、プロトコルなどのような特定の詳細が記載される。以下に記載される特定の詳細とは別に、他の実施形態が実践されてもよいことは、当業者には明らかであろう。他の例では周知の方法、デバイス、技術などの詳細な説明は不必要な詳細で説明を不明瞭にしないように省略される。

【0027】

この詳細な説明では各セクションの一般的な主題に関して読者を向けるためにのみセクションが使用され、以下に見られるように、多くの特徴の説明は複数のセクションにわたり、見出しは任意のセクションに含まれる説明の意味に影響を及ぼすものとして読まれるべきではない。

【0028】

＜概要＞
本明細書で説明される技術は、とりわけ、複数の処理ステージに分解されたアプリケーションがアプリケーションのそれぞれの処理ステージを互いに非同期にかつ同時に実行することによって実行され得る、公開−加入（パブリッシュ−サブスクライブ）メッセージ・フレームワーク（本明細書では「パブリッシュ−サブスクライブ・フレームワーク」と呼ばれることもある）に関する。処理ステージの非同期および同時実行は、多くの場合、例えば純粋に手続き型のフレームワークなど、別のタイプのフレームワークで実行されている同じアプリケーションと比較して、アプリケーションの完了までの時間を短縮することになる。それぞれの処理ステージ間の通信は、公開−加入実行モデルに排他的に従うことができる。記載されたパブリッシュ−サブスクライブ・フレームワークはマルチプロセッサ／マルチコア処理環境におけるそれぞれの処理リソースへの処理ステージの分散を可能にしながら、マルチプロセスおよび／またはマルチスレッド方式で実行されるべき処理ステージを提供する。

【0029】

本明細書で説明されるシステムおよび技法は、株式および／または他の取引可能な証券を取引するための電子取引所など、取引速度が非常に重要である高取引量のアプリケーションに特によく適し得る。そのようなアプリケーションは、多数のユーザから同時に受信され得る要求に応答して、リアルタイムまたはほぼリアルタイムで実質的な処理を必要とする。例示的な実施形態では、そのようなアプリケーションで必要とされる処理が複数のパイプライン処理ステージに分解することができる処理パイプラインとして特徴付けることができる。各ステージが１つ以上の機能領域のための処理ロジックを有するパイプライン処理ステージはその後、パイプラインステージのグループ間の相互通信を提供するパブリッシュ−サブスクライブ・フレームワークを用いて、互いに対して非同期かつ同時の方法で実行されることができ、それによって、取引活動の実質的な高速化をもたらす。本明細書で説明される電子取引所アプリケーションおよび関連するゲートウェイアプリケーションは例として提供され、実施形態は電子取引所および／またはゲートウェイのアプリケーションに限定されないことが理解されるのであろう。

【0030】

図１は、パブリッシュ−サブスクライブ・フレームワークに従って実施される電子取引所アプリケーションが例えば、ユーザから受け取った注文（オーダ）を含むデータメッセージのようなサービス・クライアント要求を行う実施形態におけるコンピュータ環境を示す。ユーザは実施形態のパブリッシュ−サブスクライブ・フレームワークに従って実装されてもよいゲートウェイに、データメッセージのストリーム、例えば、電子取引所エンジン上で取引するためのオーダを提供してもよい。ゲートウェイは要求を電子取引所アプリケーション（「取引所エンジン」と呼ばれることもある）に転送する前に、クライアント要求を集約および／または前処理することができる。図２は、図１の電子取引所アプリケーションまたはゲートウェイアプリケーションのようなアプリケーションプログラムを、各々がそれ自体のイングレス／エグレス・メッセージ・インタフェースのセットを有する複数の処理ステージに分解した例を概略的に示す。また、図２は処理ステージを同時に非同期的に実行するために、分解された処理ステージをそれぞれの処理コアに分配する例を示す。図３は図１の図４および図５のようなアプリケーションを実行する際に使用することができるパブリッシュ−サブスクライブ・フレームワーク内のいくつかのオブジェクト、およびオブジェクト間の関係を示し、パブリッシュ−サブスクライブ・フレームワーク内のパブリッシャ、サブスクライバ、およびセッション・構成要素間の例示的なパブリッシュ−サブスクライブ・メッセージ交換を示す。図６は図１に示されるゲートウェイアプリケーションのような例示的なゲートウェイアプリケーションにおける例示的なメッセージフローを示す。図７〜図１０が図６のゲートウェイアプリケーションの分解された処理ステージの間の様々なメッセージ交換シーケンスを示す。図１１は、図１のアプリケーションのような例示的な電子取引所アプリケーションにおける例示的なメッセージフローを示す。図１２、図１３は、電子取引所アプリケーションの分解された処理ステージの間の様々な例示的なメッセージ交換シーケンスを示す。図１４は、図１のクライアントデバイス、ゲートウェイ、またはサーバのいずれかを実施するために使用することができるコンピュータを示す。

【0031】

図１の説明
図１は、特定の例示的な実施形態によるコンピューティング環境を示す。非限定的なコンピューティング環境１００は、サーバインフラストラクチャ１０２内の１つ以上のサーバ、ネットワーク１０６によってサーバインフラストラクチャに接続された１つ以上のゲートウェイシステム１０４、およびクライアントデバイス１０８および１１０を含むクライアントシステムを含む。サーバインフラストラクチャ１０２内のサーバはゲートウェイシステム１０４およびクライアントデバイス１０８および１１０と通信することができ、その結果、クライアントデバイス１０８および１１０上のユーザは、サーバインフラストラクチャ１０２内で実行される電子取引所アプリケーション１１６と相互に作用することができる。

【0032】

例示的なコンピューティング環境１００は、サーバインフラストラクチャ１０２内の電子取引所アプリケーション１１６を実行することによって、株式、デリバティブ、または他の金融商品もしくは商品の電子取引のための電子取引所を提供する。少なくともいくつかの実施形態では、電子取引所アプリケーション１１６が少なくともいくつかのタイプの取引可能な商品の取引が進行中のリアルタイムベースで試みられる電子連続取引を提供することができる。例えば、クライアントデバイス１０８および１１０および／またはゲートウェイシステム１０４からの着信クライアント要求のストリーム内のオーダ（例えば、買い注文または売り注文）を含む各データメッセージは、受信時に、オーダブックと照らし合わせて、即座に（例えば、リアルタイムまたはほぼリアルタイムで、非本質的な処理および／またはメモリ／ストレージアクセスアクティビティを介さずに）一致を判定する。例示的な実施形態は大量（例えば、毎秒数百または数千のオーダ、毎秒数十万のオーダ）およびリアルタイム制約（例えば、１秒以内に入ってくるオーダの大部分を処理する、第１の所定数のマイクロ／ナノ秒を超えない、およびオーダのいずれもが第２の所定数のマイクロ／ナノ秒処理時間を超えない平均処理時間を有するようにオーダを処理する、所定の分数秒以内に特定のタイプのすべてのオーダを処理する、など）で複数の同種および／または異種属性を含む取引可能な商品レコードを効率的に処理することができるデータ構造およびマッチング技術などを使用するように構成される。サーバインフラストラクチャ１０２は在庫（インベントリ）レコードの更新、および実行されたオーダに関する他のシステムへの通知など、他の関連するタスクを実行するように動作することもでき、その結果、配送などを追跡することができる。注文書サーバ、オーダマッチングエンジン（単に「マッチングエンジン」と呼ぶ）、オーダ管理サーバ、ポジション管理サーバ、フルフィルメント管理サーバのうちの１つ以上が、電子取引所アプリケーション１１６に含まれてもよく、またはこれらと相互作用して、サーバインフラストラクチャ１０２上で電子取引所の機能を提供してもよい。

【0033】

電子取引所アプリケーション１１６、またはアプリケーション１１６の一部であるマッチングエンジン（別個には図示せず）は、各入ってくるオーダを注文書（オーダーブック）データベース（「スタンディングオーダ・データベース」とも呼ばれる）からのオーダとマッチングさせるように動作することができる。例えば、マッチングエンジンは受信した買い注文をオーダーブック・データベースに記憶された１つ以上の売り注文とマッチングさせたり、受信した売り注文をオーダーブック・データベースに記憶された１つ以上の買い注文とマッチングさせたりするように動作してもよい。マッチングは、マッチングルールデータベースからの１つ以上の所定または動的に決定されたマッチングルールに従って実行されてもよい。いくつかの実施形態では、１つ以上のサーバがサーバインフラストラクチャ１０２内の他のサーバおよび／または外部コンピュータがそれと相互作用するために使用できるインタフェース（たとえば、アプリケーション・プログラミング・インタフェースＡＰＩ）を提供してもよい。例えば、リアルタイムオーダマッチング処理で使用されるオーダマッチングエンジンおよびオーダーブック・サーバの一方または両方が、ＡＰＩを介してサーバインフラストラクチャ１０２および／または外部コンピュータ内の他のサーバのそれぞれと通信してもよい。

【0034】

マッチング処理がそれぞれのオーダが受信される時間順序を厳密に遵守し、オーダがユーザによって送信された後の最小時間間隔でオーダを処理することに依拠することができるように、入ってくるオーダを高速で処理する（例えば、１秒間に数千または数十万のマッチ）サーバインフラストラクチャ１０２の能力は非常に重要であり、システム上で行われる取引の正確さおよび有効性を下支えすることができる。

【0035】

サーバインフラストラクチャ１０２はネットワークおよび／またはポイントツーポイント接続を介して互いに通信可能に接続された１つ以上の物理的サーバコンピュータ（例えば、コンピュータ１１２および１１４）を含んでもよい。物理サーバコンピュータは、地理的に併設または分散していてもよい。サーバインフラストラクチャ１０２内のサーバ間の相互接続はインターネットを介して、または互いにローカル・エリア・ネットワーク、ワイドエリアネットワークまたはポイントツーポイント接続（例えば、接続１２５）などの他のネットワークを介してもよい。いくつかの実施形態では、複数のサーバが高速ポイントツーポイント接続および／または高速ブロードキャストバスと相互接続される。

【0036】

コンピュータ１１２および１１４の各々は少なくとも１つの単一コアまたはマルチコアプロセッサ（例えば、プロセッサ１１８および１２２）を有する処理システムを含み、システムソフトウェア（例えば、システムソフトウェア１２０および１２４）を含む。いくつかの実施形態では、コンピュータ１１２および１１４が対称マルチプロセッサ（ＳＭＰ）内のそれぞれの処理部とすることができる。いくつかの実施形態では、コンピュータ１１２および１１４が高速接続で相互接続されたスタンドアロン・コンピュータとすることができる。

【0037】

システムソフトウェア１２０はコンピュータ１１２のためのオペレーティングシステムを含むことができ、システムコールなどを提供することができ、これにより、アプリケーション１１６などのアプリケーションは、オペレーティングシステムからプロセッサ１１８および／または周辺装置を制御するサービスを要求することができる。システムソフトウェア１２０は同じまたは異なるプロセッサ／プロセッサコア上で実行されるプロセスおよび／またはスレッド間のプロセス間通信を提供することもでき、また、１つ以上のネットワークインタフェース上で別々のコンピュータ間の通信を提供することもできる。したがって、システムソフトウェア１２０はプロセス内、プロセス間、スレッド間、および／またはホスト間通信を必要に応じて実行するために、システムリソース（例えば、プロセッサ、プロセッサコア、メモリ、ストレージ、通信インタフェースなど）にアクセスするための実行カーネル（例えば、アプリケーション１１６を実行する実行カーネル）を提供する。システムソフトウェア１２４は、システムソフトウェア１２０に類似していてもよく、システムソフトウェア１２０の上述の能力を有してもよい。

【0038】

実施形態によれば、アプリケーション１１６は、パブリッシュ−サブスクライブ・メッセージ交換フレームワークに基づくパブリッシュ−サブスクライブ実行カーネルを備えるか、またはパブリッシュ−サブスクライブ実行カーネルとして動作する。アプリケーション１１６はシステムソフトウェア１２０（および／または１２４）を使用して、メモリ（図１には別個には示されていない）およびプロセッサ１１８および１２２などのシステムリソースにアクセスまたは制御することができ、その結果、アプリケーション１１６の個々のコンポーネントを、最適な（または改善された）並列度、速度、および／または信頼性を提供する方法で、特定の処理リソース上に配置することができる。

【0039】

実行カーネル（しばしば単に「カーネル」）が実施形態によるパイプライン化されたデータ駆動アプリケーションアーキテクチャの基礎を形成する。実行カーネルがイベント／メッセージ駆動システムにおけるアプローチのような同様のパラダイムのために意図され、アプリケーションは典型的には待ち行列に入れられる順番で処理される「イベント」の関連する待ち行列を有する「メインループ」を有するように設計されるが、異なるアプリケーションステージを非同期かつ同時に処理する複数のスレッドを有する。これを可能にするために、メッセージベースのパラダイムが実行カーネルによって使用され、スレッド、プロセス、およびホスト間の実行およびメッセージングの受け渡しを可能にする。少なくともいくつかの実施形態では、２つ以上の処理ステージ間のすべての通信がトピックを公開し、トピックに加入するものとして表現される。少なくともいくつかの実施形態では、２つ以上の処理ステージ間のすべての通信がトピックを公開し、加入するものとして表現される。すなわち、特定の例示的な実施形態では、情報が１つの処理ステージから別の処理ステージに交換される唯一の方法がパブリッシュ−サブスクライブ・フレームワークを介するものであり、そのような情報を取得することができるサイドチャネルは存在しない。

【0040】

例示的な実施形態の実行カーネルにおけるメッセージングトポロジは、論理的には複数の加入者（サブスクライバ）が同じメッセージに加入することができるブロードキャストアーキテクチャである。これにより、必要に応じて複数のエンドポイントまたは単一のエンドポイントにメッセージを分岐できる論理的なバスに似たアーキテクチャが可能になる。トポロジは公開エンドポイントおよび加入エンドポイントとして表現されるため、アプリケーションは所望の通信経路を間接的に表現するためにのみ必要な場合があり、加入エンドポイントには公開エンドポイントに関する直接的な知識はない。

【0041】

フレームワーク内のパブリッシャおよびサブスクライバは、部分的な順序付けの要件および損失のない通信の要件の両方をそれらに課している可能性がある。すなわち、少なくともいくつかの実施形態では、メッセージが公開者（パブリッシャ）によって公開される順序が、メッセージがサブスクライバにおいて受信されなければならない順序である。これは、加入エンドポイントでメッセージの確定的な処理を可能にするために必要である。

【0042】

メッセージングトポロジの動的作成を可能にするには、特定の保証が必要である。したがって、セッション、パブリッシャなどの作成は、実行カーネル内で信号の生成を引き起こす可能性がある。すなわち、新規のパブリッシャが作成されると、同じセッションに参加しているすべてのサブスクライバは新しいトピックが存在する（たとえば、各パブリッシャがトピックに関連付けられている）という通知を受信し、通知に応答して、特定のサブスクライバの要件に従ってそのトピックに加入することができる。いくつかの実施形態では、パブリッシャが少なくとも１つのサブスクライバがそのトピックに加入した後にのみ、トピックのためのメッセージを公開することが可能にされる。

【0043】

単一プロセス内でのそのようなメッセージングの使用を含む、パブリッシュ−サブスクライブ・メッセージングを使用するための特定の実施形態におけるアプローチは、高度に効率的なポイントツーポイント伝送として使用されるハードウェアのメモリ・サブシステムを利用することを可能にするＳＭＰベースのシステムにおけるロックフリー・データ・パッシングを利用することによって、いくつかの実施形態において可能となる。適切なロックフリーキューとのポイントツーポイント通信、１つのＣＰＵコアから別のＣＰＵコアへのメッセージの通信はメモリブロックにポインタを渡すときに、パイプライン処理された数個のＣＰＵ命令で実行できる。これは、たとえば、同じポインタを複数のＣＰＵコアキューにプッシュすることによって、ブロードキャストバスを表すように拡張できる。受信側ＣＰＵコアはポインタを読み取り、送信元ＣＰＵ が送信したメモリブロックにアクセスする。

【0044】

この基本的な通信モードにより、パブリッシュ−サブスクライブ・メッセージングはプロセス内通信のための高度に効率的な方法で表現でき、共有メモリマッピングを用いたホストローカル通信のためにも表現できる。パブリッシュ−サブスクライブ・フレームワークがメモリブロックの交換を伴う一連の管理されたＣＰＵコア内のキューとして実施されるという事実は、アプリケーションロジックには隠されている。さらに、メモリブロックの管理は、パブリッシュ・サブスクライブを使用するアプリケーションに対して透過的である。

【0045】

アプリケーションは公開と加入の両方のエンドポイント（すなわち、パブリッシャとサブスクライバ）を作成する動作によって、フレームワークと基盤となるインフラストラクチャへの必要な接続性を間接的に表現する。次に、通信インフラストラクチャは、物理通信パスを形成する必要なスレッド間キューを作成する。低レベル・トランスポート・レベルでの結果は、すべての加入エンドポイントと公開エンドポイントとが接続された接続メッシュになる。

【0046】

追加のキューおよび制御実行カーネルを使用するシグナリングは例えば、プロセス、ホストまたはネットワーク通信領域のような通信領域の動的作成を可能にするために使用されてもよい。メッセージ公開のシグナリングおよび順序付けの保証は、特定の実施形態ではデータフローをモデル化するために使用することができる新しい通信セッションの決定論的な作成および立ち上げを可能にするために必要とされる。

【0047】

ゲートウェイ１０４はサーバインフラストラクチャ１０２から地理的に遠隔で配置されていてもよいし、サーバインフラストラクチャ１０２とローカルに配置されていてもよい。ゲートウェイ１０４は、少なくとも１つの単一又はマルチコアプロセッサ１２８及びシステムソフトウェア１３０を含むことができる。プロセッサ１２８およびシステムソフトウェア１３０は、少なくともいくつかの実施形態ではコンピュータ１１２に関連して説明されるプロセッサ１１８およびシステムソフトウェア１２０にそれぞれ類似していてもよい。ゲートウェイ１０４は、クライアント要求がサーバインフラストラクチャ１０２に送信される前に、クライアント要求を集約および／または事前に処理するために動作するゲートウェイアプリケーション１２６を実行することができる。集約には、サーバインフラストラクチャへの１つのメッセージに、ユーザが開始した２つ以上の注文をバンドルすることが含まれる場合がある。前処理には、ヘッダの変更、認証、および／または暗号化が含まれる場合がある。いくつかの実施形態によれば、ゲートウェイアプリケーション１２６は、パブリッシュ−サブスクライブ実行カーネルとして実装される。

【0048】

上述のアプリケーションのいずれも、ユーザ認証を管理するためのエンタープライズ・サービス・アプリケーション（別個には図示せず）と、入ってくるオーダを受信し、オーダ／取引確認を送信するためのクライアント１０８および１１０と、処理に使用されるための、またはオーダ、取引およびポジション、ならびに市場統計に関する情報を報告するための情報を取得するためのデータベース管理システムおよび／または外部サーバと相互に作用することができる。サーバ１０２上の任意のアプリケーションなどのアプリケーションは、１つ以上のクライアント側コンポーネントと、１つ以上のサーバ側コンポーネントとを備えることができる。アプリケーションのクライアント側コンポーネントはユーザインタフェースデバイス上で情報の提示（例えば、表示）を実行すること、ユーザ入力を受信することなどによって、ユーザインタフェースを処理することを提供するように動作することができる。サーバ側コンポーネントは、受信されたユーザ入力に従ってユーザに提示される情報を認証、サービスメータリング、生成、または取得することを提供することができる。

【0049】

例のクライアントデバイス１０８および１１０は、それぞれ、同一または異なるクライアントアプリケーション１３２および１３４を実行するように構成することができる。クライアントデバイスアプリケーションは、電子取引所アプリケーションのクライアント側部分を含むことができる。図１に示す例ではクライアントデバイス１０８が取引アプリケーションを実行しており（例えば、クライアントアプリケーション１３２は電子取引所と相互に作用するためのクライアント側取引アプリケーションである）、その取引アプリケーションを介して買い注文を送信する。クライアントデバイス１１０は同じ又は異なる取引アプリケーションを実行することができ、売り注文をサーバ１０２に送信することができる。クライアントデバイス１０８および１１０は、パーソナルコンピュータ、モバイルコンピュータ、タブレット、スマートフォン、および他の電子デバイスのいずれかを含むことができる。ある実施形態では、少なくともディスプレイ、ユーザ入力のための入力装置、およびサーバデバイスと通信するための通信インタフェースを含む任意の電子計算デバイスがクライアントデバイスとして動作してもよい。２つのクライアントシステムが示されているが、任意の数のクライアントシステムがサーバインフラストラクチャ１０２と相互に作用することができる。クライアントリクエストは、人間のユーザインタラクションおよび／またはコンピュータプログラムによって生成されてもよい。

【0050】

図１に示すソフトウェアモジュールはハードウェアコンポーネント（プロセッサやメモリなど）に格納されて実行されることが理解されるべきであり、ソフトウェアモジュールが説明を容易にするためにのみ実行される何らかのアクションを実行することが本明細書に記載されているときはいつでも、そのアクションは、実際にはソフトウェアモジュールを構成する命令およびデータに従って基盤となるハードウェアによって実行されるものであることが理解されるべきである。本明細書で説明される特徴を実装するために使用され得る例示的なハードウェア構成要素に関するさらなる詳細は、図１４を参照して、ならびに本明細書の他の場所で以下に提供される。

【0051】

図１の上記説明を含むがこれに限定されない、本明細書の多くの箇所では、ソフトウェアモジュールおよびソフトウェアモジュールによって実行されるアクションが説明される。これは説明を容易にするために行われる。ソフトウェアモジュールが何らかのアクションを実行することが本文書に記載されているときはいつでも、そのアクションはソフトウェアモジュールを構成する命令に従って、基盤となるハードウェア要素（プロセッサやメモリデバイスなど）によって実行される実際のものであることが理解されるべきである。これに関するさらなる詳細は、他の場所の中でも、図１４の説明において以下に提供される。

【0052】

図２の説明
図２は、いくつかの実施形態による、アプリケーションのためのプログラムコード、図１に示されるような処理環境で使用するための複数の処理ステージへのアプリケーションプログラムコードの分解、およびマルチコアおよび／またはマルチプロセッサ処理環境で展開される処理ステージを示す高レベルフローを示す。

【0053】

特定のアプリケーションのための実行カーネルフレームワークの使用は最初に、非同期かつ同時に実行可能な分離可能な処理段階の設定を発見することを含む。これは各機能が潜在的な候補である機能基底で実行することができるが、より高い効率を達成するために、分解を機能領域の周りに向けることができる。機能領域は、参照データに対する静的検証、ロジック処理、出力生成などのようなものとすることができる。アプリケーションを複数の処理ステージに分解するための例示的なガイド原理は再利用可能な機能、または他のものと重複しない機能を、好ましくはそれ自体の処理ステージに分離すべきであることであり得る。

【0054】

いくつかの処理ステージが分解されるべきであると特定されるとき、それらのステージのそれぞれのメッセージＡＰＩは、イングレスとエグレスの両方で定義される可能性がある。次いで、メッセージの名前は、分解によって得られた個々のコンポーネントにおいてパブリッシャおよびサブスクライバを作成するときにトピックとして使用することができる。このアプローチは分離され自己宣言されたコンポーネントを生成し、クラシックな垂直手続き呼び出しをとり、それらを、水平パイプラインを形成するメッセージに変換するものと考えることができる。

【0055】

例示的な実施形態では、例えば、図１に示されるゲートウェイアプリケーション１２６または電子取引所アプリケーション１１６などのアプリケーションのためのプログラムコード２０２は複数のコンポーネントまたはモジュール２０４（例えば、モジュール−１ ２０４ａ、モジュール−２ ２０４ｂ、・・・、モジュール−ｎ ２０４ｎ）に分解され得る。プログラムコード２０２はセットからの１つ以上のプログラミング言語またはスクリプト言語を使用して指定することができ、１つ以上の入力、処理ロジック命令、および１つ以上の出力を指定することができる。プログラムコード２０２内の処理ロジック命令は、プロシージャコールを有する少なくとも一部の命令を含む命令のシーケンスとして指定することができる。少なくともいくつかの実施形態によれば、分解は完全に宣言的に指定されたプログラムコード２０２などのプログラムコードを入力として受け取り、メッセージを交換することによってパブリッシュ−サブスクライブ・パラダイム内で完全に相互作用する処理ステージのセットを出力する。

【0056】

プログラムコード２０２の分解は自動的に、手動で、またはそれらの組み合わせによって実行されてもよい。（例えば、分解プログラム２１８によって）自動的に実行される分解の任意の部分について、分解プロセスは、１つ以上のユーザ構成可能構成パラメータ２２０に従って制御され得る。部分分解は例えば、処理のメタレベル記述のより多くが記述される高レベルドメイン固有言語（ＤＳＬ）に基づくことができる。これは、このＤＳＬのコンパイラへの入力であり、結果としてパブリッシュ−サブスクライブ・モジュールの構成を生成することができる。コンパイラは各機能の複雑さの記述に基づいて決定を行い、関数が単純な場合には手続き呼び出しを作成し、複雑さが高い場合にはパブリッシュ−サブスクライブリンクを作成することを選択することができる。また、非同期処理を利用するために、１つの関数の出力が複数の他の関数への入力として使用される場合、必要なトポロジに基づいて決定することもできる。

【0057】

いくつかの実施形態によれば、分解はプログラムコード２０２内の別個の関数（例えば、プログラムコードのいくつかの部分によって使用されるモジュールなど）を識別することと、その識別された別個の関数のすべて（または実質的にすべて）のインスタンスをプログラムコード２０２から抽出することと、抽出された部分とプログラムコード２０２の残りの部分との間のメッセージインタフェースを定義することとを含む。コード２０２の様々な機能は、関数／クラス名、クラス属性名、関数／クラス内から行われる呼び出しなどの特性に従ってグループ化することができる。

【0058】

自動分解プロセスを制御することができるユーザ構成可能な設定パラメータは抽出されるモジュールの１つ以上の識別情報（例えば、機能、プロシージャまたはクラスの名前）、許容される分解されたモジュールの最大個数、モジュールを分散させることができるプロセッサの数、モジュールを分散させることができるプロセッサコアの数などを含むことができる。

【0059】

次いで、モジュール２０４は１つ以上の性能特性および／または性能メトリックが改善されるように、複数のプロセッサおよび／または処理コアに分散される。図２に示す例示的な実施形態では、モジュール２０４がコンピュータ２０８の処理コア２１０（２１０ａ、２１０ｂ、および２１０ｃ）の間で分散される。いくつかの実施形態では、分散が実質的に等しい数のモジュールを各プロセッサまたは処理コアに分散すること（またはワークロードの実質的に均一な分散を達成しようと試みる方法で）を含むことができる。モジュールを分散させる際に、データを共有する可能性および／または頻繁な対話を有する可能性がある場合、２つ以上のモジュールを特定の処理コア上に配置することができる。共有データのレベル、またはコロケーションされるモジュールを限定する頻繁な相互作用のレベル（例えば、２つのモジュールのエグレス／イングレスＡＰＩ間のマッチ、期待されるメッセージ数／メッセージ頻度）に対する閾値は構成可能である可能性がある。

【0060】

図示の実施形態ではコンピュータ２０８がそれぞれのコアがそれ自身のローカルメモリを有するＳＭＰコンピュータであってもよく、すべてのコア２１０ａ〜２１０ｃは共有メモリ２１４、およびオプションとしてメモリデバイス２１６へのアクセスを有する通信バス複合体（通信インフラストラクチャ）２１２に接続されている。それぞれのコア上に配置されたモジュール２０４は、バス複合体２１２を介して共有メモリ２１４および／またはメッセージ交換を介して互いに通信することができる。同じコア上に配置されたモジュール２０４は、そのコアのローカルメモリ（またはローカルキャッシュ）を介して相互作用することもできる。例えば、上述したように、共有メモリ内のロックフリーキュー（例えば、異なるコア上の処理ステージ間、および／または、同一コア上で実行される処理ステージまたは関連スレッド間で情報を交換するためのコアのローカルメモリ内の情報を交換するための共有メモリ２１４内）がそれぞれの処理ステージ間で情報を使用してもよい。図示の実施形態では、分解されたモジュール１〜ｎがモジュール１、２、およびｎがコア２１０ａに配置され、モジュール４およびｎ−２がコア２１０ｂに配置され、モジュール３およびｎ−１がコア２１０ｃに配置されるように、コンピュータ２０８の処理コアに分散される。メモリデバイス２１６には、分解器（デコンポーザ）２１８、プログラムコードを分解するためのロジック２０２、および設定パラメータ２２０も記憶されている。

【0061】

図３の説明
図３は、いくつかの例示的な実施形態によるパブリッシュ−サブスクライブ・フレームワークを実装するためのあるプリミティブに対応するオブジェクトと、パブリッシュ−サブスクライブ・フレームワークに従ってアプリケーションを実行する実行カーネル内のオブジェクト間の関係との概略図を示す。

【0062】

図３は、特定の実施形態による実行カーネル内のオブジェクトの階層関係を示す。「カーネル」または「カーネルオブジェクト」３０２は他のすべてのプリミティブに関する知識を有する中央の断片であり、他のプリミティブを作成するためのルートである。実行カーネルオブジェクト３０２は、マルチスレッド、マルチコア、マルチプロセス、およびマルチホストアプリケーションの構築を容易にするパブリッシュ−サブスクライブ・フレームワークをインスタンス化することができる。実行カーネルは、マルチプロセッシング・アプリケーションのための同期の実装を容易にする。

【0063】

セッションオブジェクト３０４はメッセージのストリームを記述し、関連メッセージのグループ化を制御するためにアプリケーションに提供する。実行カーネルオブジェクト３０２は、マルチスレッド、マルチコア、マルチプロセス、およびマルチホストアプリケーションの構築を容易にするパブリッシュ−サブスクライブ・フレームワークをインスタンス化することができる。パブリッシャとサブスクライバが特定のセッションに結び付けられると、新しいセッションを作成し、新しいセッションで同じパブリッシャとサブスクライバのセットを作成すると、同じパイプラインの新しいインスタンスが作成され、他のインスタンスから分離されたメッセージフローが生成される。メッセージトランスポートの異なるドメイン、例えば、プロセスドメイン、ホストドメイン、ネットワークドメインに対して、セッションオブジェクトの異なる実装が存在する可能性がある。図２の説明はプロセス領域内のユーザセッションによって容易にされる同一プロセス通信領域内の複数の処理コアに関するものであるのに対し、ホスト領域およびネットワーク領域内のユーザチャネルをインスタンス化する能力は、複数のプロセッサおよびネットワークを介した複数のホストへのパイプライン処理ステージの分散を可能にする。ホストローカルドメインの場合、同じまたは類似の共有メモリモデルを使用して、ホストメモリサブシステムを使用して同じホスト上の異なるプロセス間の通信を可能にするメッセージングプリミティブを定式化することができる。主な違いは、実行カーネルのオーケストレーションおよびシグナリングが複数のプロセス間のこの相互作用を容易にするために、アウト・オブ・プロセス・デーモンとして実装されることを必要とし得ることであり得る。ネットワーク領域においては、いくつかの実施形態において、米国特許第９，７１２，６０６号（その内容は本文書全体に盛り込まれている）に記述されているような、信頼できる順序付けられたストリームが各セッションに対して使用される場合の実施形態に類似する実施が用いられるのであろう。セッションオブジェクトは、名前属性３４６によって識別されてもよい。セッションオブジェクトはセッション参加者に、セッションに参加する新しいパブリッシャおよび／または新しいサブスクライバなどのイベントを通知するようにシグナリングするための方法３４８を含むことができる。

【0064】

コンテキストオブジェクト（例えば、実行コンテキスト３０６および３０８）はアプリケーションがメッセージの受信および送信を制御し、拡張によってアプリケーションの実行を制御することを可能にする。コンテキストオブジェクト３０６および３０８は、実行スレッドを記述する。各コンテキストオブジェクトは、個々のオブジェクトについて読取り可能および書込み可能なステータスを監視することができるマルチプレクサ・オブジェクト（セレクタ）でもある。各クライアントが特定のコンテキストにバインドされ、公開および加入が特定のクライアントにバインドされると、クライアントのメッセージの受信および送信は、アプリケーション定義のコンテキスト内になる。各コンテキストは、それぞれの実行スレッドにマップすることができるので、アプリケーションはどのコンテキストを特定のクライアントに使用するかを選択することができ、したがって、個々の処理ステージがどのスレッド上でそれが実行されるか、および他のコンポーネントとどのように通信するかに関する特定の知識を有する必要なく、処理ステージのスレッド化を制御することができる。

【0065】

例えば、クライアントオブジェクト３１０および３１６のいずれかのような「クライアント」または「クライアントオブジェクト」は、セッションへの参加を表記する。クライアントは、メッセージのパブリッシュとサブスクライブの両方に使用される。各クライアントオブジェクトは、パブリッシャオブジェクトとサブスクライバオブジェクトをインスタンス化できる。ｃｒｅａｔｅＰｕｂｌｉｓｈｅｒ ３２２およびｃｒｅａｔｅＳｕｂｓｃｒｉｂｅｒ ３２４などの方法は、それぞれ、パブリッシャおよびサブスクライバの作成に使用することができる。メッセージの順序はクライアントごとに保持される。メッセージの順序はクライアントごとに保持される。つまり、１つ以上のサブスクライビングクライアントは、対応するパブリッシングクライアントによって公開されたのと同じ順序でメッセージを受信する。ただし、２つの異なるパブリッシングクライアントの順序は定義されていない場合がある。メッセージの順序付けは、ｍｓｇＯｒｄｅｒｉｎｇ ３２６ などの方法を使用して処理できる。順序付けは、公開されたメッセージをエンキューイングし、公開されたメッセージのキュー内の順序に従ってのみメッセージを各サブスクライバに配布することによって処理することができる。メッセージの損失のない（ロスレス）送信は、ｌｏｓｓｌｅｓｓＴｒａｎｓｍｉｔ３２８のような方法によってクライアントに対して処理されてもよい。ロスレス送信は、各公開されたメッセージに関連付けられた肯定応答および／または再試行メカニズムを実装することによって実行され得る。

【0066】

例えば、パブリッシャオブジェクト３１２および３１８のような「パブリッシャ」または「パブリッシャオブジェクト」は送信されるメッセージのタイプを記述し、すなわち、パブリッシャは、その特定のパブリッシャの「トピック」である名前で作成される。メッセージが（例えば、送信方法３３０を使用して）パブリッシャと一緒に送信されるときはいつでも、それはその特定のトピックとして送信される。

【0067】

「サブスクライバ」または「サブスクライバオブジェクト」（例えば、サブスクライバオブジェクト３１４および３２０のいずれか）は受信されているメッセージのタイプを記述し、すなわち、サブスクライバは、その特定のサブスクライバの「トピック」である名前で作成される。メッセージがサブスクライバに対して（例えば、受信方法３４０を使用して）受信されているときはいつでも、それはその特定のトピックのものである。

【0068】

一実施形態によれば、電子取引所アプリケーション実行カーネル１１６は、カーネルオブジェクト３０２のインスタンス化であってもよく、プロセスに対応してもよい。セッションオブジェクト３０４は、パブリッシュ−サブスクライブ・フレームワークを調整するためにスレッドとしてインスタンス化されてもよい。一実施形態では、セッションオブジェクトがユーザから受信した各オーダリクエストに対してインスタンス化されてもよい。アプリケーション１１６の分解された処理ステージのそれぞれは、クライアントオブジェクト（例えば、クライアントオブジェクト３１０または３１６など）の別個のインスタンス化であってもよく、電子取引所アプリケーション１１６に対応するプロセスの他のスレッドと非同期かつ同時に実行するそれぞれのスレッドに対応してもよい。各クライアントオブジェクトは対応するサブスクライバオブジェクト（例えば、クライアントオブジェクト３１０のサブスクライバオブジェクト３１４）をインスタンス化することによって、そのイングレスメッセージＡＰＩをインスタンス化し、対応するパブリッシャオブジェクト（例えば、クライアントオブジェクト３１０のパブリッシャオブジェクト３１２）をインスタンス化することによって、そのエグレスメッセージＡＰＩをインスタンス化する。上述したように、各パブリッシャおよびサブスクライバは、公開または加入される特定のメッセージを識別する少なくとも１つのトピックに関連付けられる。特定のトピックに対する公開および加入は、処理ステージ間の通信のためのロジックトポロジを定義する。特定の実施形態では、実行カーネルが利用可能な処理リソース上の処理ステージの配置を決定し、異なる処理ステージ間の通信を効率的に容易にするために論理通信インフラストラクチャをセットアップする。分散および論理通信インフラストラクチャは所定のパフォーマンスメトリック（たとえば、オーダを処理するための平均時間などのアプリケーション速度、または所定の時間制約内で処理されることが可能な同時オーダの数などの同時ボリューム）を改善するように構成され得る。決定された分散および論理通信インフラストラクチャに従って、カーネルはシステムソフトウェア（例えば、システムソフトウェア１２０または１２４）に、識別された処理リソース上で特定のスレッドを実行し、共有メモリ内に１つ以上のメッセージキューを作成するように要求してもよい。

【0069】

図４の説明
図４は、いくつかの例示的な実施形態による、実行カーネルにおける公開および加入を表す例示的なアクティビティフロー４００を示す。

【0070】

セッションスレッド４０４、パブリッシャスレッド４０２、およびサブスクライバスレッド４０６および４０８の間のアクティビティフロー４００に示すように、特定の「トピック」のメッセージを受信することを所望サブスクライバは、その「トピック」にサブスクライブする。サブスクライバ（または対応するサブスクライバ−クライアントオブジェクト）４０６および４０８がセッションオブジェクト４０４に「トピック」を指定するサブスクリプションメッセージ４１０および４１２を送信することによって、それぞれのサブスクリプションを登録する。

【0071】

パブリッシャクライアント４０２は、メッセージ４１４をセッションオブジェクト４０４に送信することによって、「トピック」内のメッセージを公開する。次に、公開されたメッセージは、セッションオブジェクト４０４によって、メッセージ４１６および４１８によって、加入しているクライアントに提供される。

【0072】

図５の説明
図５は、いくつかの例示的な実施形態による、セッションへの新しいパブリッシャの追加を表す例示的なアクティビティフロー５００を示す。

【0073】

「トピック」を有する新しいパブリッシャがセッションに参加したことをセッションオブジェクト５０４に通知するメッセージ５０８を送信するパブリッシャまたは対応するクライアントオブジェクト５０２によって、新しいパブリッシャが追加される。セッションオブジェクト５０４は、新しい「トピック」がサブスクリプションに利用可能であることを各クライアントに通知する。セッションオブジェクト５０４が「トピック」を各クライアントに通知するそれぞれのメッセージ５１０を各クライアント５０６に送信することができる。

【0074】

次いで、１つ以上のクライアントはサブスクライバをインスタンス化し、セッションオブジェクトにメッセージ５１２を送信することによって「トピック」に加入することを通知することができ、セッションオブジェクトはメッセージ５１６によって、「トピック」に公開することが可能であることをパブリッシャに通知する。少なくとも１つのクライアントによって「トピック」に加入した後、パブリッシャは図４に示すように「トピック」を公開することができる。

【0075】

具体的には、サブスクリプションはクライアントのコンテキストで作成される。クライアントは、セッションへのアタッチを表す。サブスクリプションが作成されると、クライアントはセッションオブジェクトにメッセージを送信して、トピックへの関心を通知する。その後、セッションは公開するクライアント実装に、受信者エンドポイントが公開されるメッセージに関心があるというメッセージを送信する。クライアント（またはより正確にはアプリケーションロジック）が必要なサブスクリプションを作成したとき、クライアントは必要なサブスクリプション（およびパブリッシャの作成など）のすべてを完了したことをセッションに肯定応答する。特定のセッションに参加するすべてのクライアントがトピック（パブリッシャ）の作成を承認すると、クライアントは特定のトピックのメッセージを公開できるようになる。たとえば、５１６はセッションオブジェクトから受信される。たとえば、５１６はセッションオブジェクトから受信される。要約すると、クライアント上のパブリッシャの作成は５１０をトリガすることができ、それは５１２のうちの１つ以上をトリガし、これはアプリケーション要件に応じて、複数の５１４をもたらす可能性があり、５１２のすべては（例えば、セッションオブジェクトへのメッセージ（図に示されていない）を介して）肯定応答されることを必要とする可能性があり、すべてのメッセージ５１２が肯定応答されると、メッセージ５１６が送信される。

【0076】

図４に関連して説明したように、パブリッシャ（および／または対応するクライアント）、セッション、およびサブスクライバ（および／または対応するクライアント）は、それぞれのスレッドとして実装することができる。

【0077】

図６の説明
図６はいくつかの例示的な実施形態による、例えば、図１に示されるゲートウェイアプリケーション１２６のような、パブリッシュ−サブスクライブ・フレームワークにおいて実装される例示的なアプリケーションを示す。

【0078】

ゲートウェイアプリケーション１１６（例えば、ＮａｓｄａｑのＯＵＣＨ Ｇａｔｅｗａｙ（商標））は、実行カーネル６０２において実行されるいくつかのパイプライン処理ステージに分解されてもよい。分解の例は、クライアント接続、クライアントメッセージフレーミング、インバウンドメッセージロジック、アウトバウンドメッセージロジック、バックエンドメッセージフレーミング、バックエンド接続、ユーザ認証および認可のような機能領域のためのそれぞれの処理段階を含む処理段階をもたらすことがある。図６は、異なる処理コアにおける各処理ステージの配置例を示す図である。

【0079】

分解から生じる処理ステージのそれぞれは、オブジェクト３１０（またはオブジェクト３１６）などのそれぞれのクライアントオブジェクトとしてインスタンス化され得る。各クライアントはそれ自体のコンテキスト（例えば、実行コンテキストオブジェクト３０６または３０８のいずれか）を有することができ、実行カーネル（例えば、オブジェクト３０２）内の別個のスレッドとしてインスタンス化することができる。

【0080】

したがって、クライアントＩ／Ｏ ＴＣＰ／ＵＤＰサービス６３４、ＳＯＵＰ（登録商標）サーバサービス６３２、ＯＵＣＨ（登録商標）イングレスサービス６３６、ＯＵＣＨ（登録商標）Ｇｅｎｉｕｍイングレスサービス６３８、モードＵＳコアサービス６４０、Ｇｅｎｉｕｍ Ｉｎｅｔ（登録商標）プロトコルサービス６４２、ＯＵＣＨ（登録商標）エグレスサービス６４６、ＯＵＣＨ（登録商標）Ｇｅｎｉｕｍ（登録商標）エグレスサービス６４８、およびＲｅｇＮＭＳ ＵＳサービス６５０はそれぞれ、それ自体のコンテキスト内でそれぞれのクライアントオブジェクトとしてインスタンス化される。

【0081】

ユーザ６５０、６５２、および６５４のそれぞれのための処理パイプラインに含まれるメッセージ交換は、処理ステージ間パブリッシュ−サブスクライブ交換のシーケンスによって表すことができる。ユーザ６５０、６５２、６５４ごとに個別のセッションが作成され、各ユーザのセッションは、パブリッシュ−サブスクライブ・シーケンスで、そのユーザの異なるパイプライン処理ステージを結び付ける。ユーザ６５０のパブリッシュ−サブスクライブ・シーケンスは、メッセージ交換６０４〜６０６〜６０８（イングレス）および６１０〜６１２〜６１４（エグレス）、ユーザ６５２、６１６〜６１８〜６２０（イングレス）および６２６〜６２８〜６３０（エグレス）、ならびにユーザ６５４、６１６〜６１８〜６２２〜６２４（イングレス）および６２６〜６２８〜６３０（エグレス）によって表すことができる。

【0082】

図６に示されている他のすべての処理ステージがユーザセッションに関連付けられるのに対し、ステージ６４０および６４２はさらに、バックエンド取引サーバへの接続を表すセッションに加入している。したがって、ステージ６４０および６４２は、ユーザセッションのためのクライアントおよびバックエンドセッションのためのクライアントを、各クライアント上のサブスクライバおよびパブリッシャと共にインスタンス化する。次いで、ステージ６４０および６４２は、ユーザセッションとバックエンドセッションとの間のルーティングを実行する。

【0083】

ゲートウェイアプリケーション１２６に関連した重要な観点は、ゲートウェイは、新しいユーザが接続を確立するときに、典型的には既にユーザが接続されている（したがって、セッションが確立されている）ことである。これは、処理パイプライン内のすべての処理ステージが新しいユーザに関連付けられたメッセージを受け入れて処理することができ、また、新しいユーザを他のユーザから区別することができることを要求される可能性があるため、困難な同期問題をもたらす可能性がある。

【0084】

したがって、新しいユーザ接続のセットアップは、分散パイプラインが適切なサブスクリプションを発見し登録することを可能にする実行カーネルアナウンス（シグナリング）メカニズムを使用することによって達成することができる。アナウンスメカニズムはユーザ固有のパイプラインを確立するために、複数のレベルで使用されてもよい。

【0085】

オーダを含むデータメッセージなどのユーザからのリクエストを受信すると、クライアントＩ／Ｏサービス６３４は、ユーザのための新しい実行カーネルセッションを作成する。これにより、すべての実行カーネルコンテキストへのアナウンスが生成され、新しく作成されたセッションでクライアントを開くことができる。そして、クライアントＩ／Ｏサービス６３４は新しい実行カーネルセッション上に新しい実行クライアントを作成してもよく、実行カーネルクライアントのための新しい実行カーネルパブリッシャも作成する。これにより、実行カーネルセッションに登録されているすべての実行カーネルクライアントへのアナウンスが発生する。パイプライン内の各サービスは新しく作成されたパブリッシャに関する知識を使用して、一致する実行カーネルサブスクライバを作成し、公開されたメッセージをリッスンする。

【0086】

すべての実行カーネルクライアントがパブリッシャの作成を確認したら、クライアントＩ／Ｏ ６３４内のパブリッシャを使用してメッセージを公開することができる。

【0087】

図７の説明
図７は、いくつかの例示的な実施形態による、セッションの初期接続および許可のための動作の例示的なシーケンス７００を示す。ユーザセッションの初期作成のための操作は、パイプライン処理ステージ間のパブリッシュ−サブスクライブ・メッセージ交換のシーケンスとして示される。

【0088】

ゲートウェイ（例えば、ゲートウェイ１０４）が立ち上がる際に、いくつかの新しいセッションが開始されうる。制御セッションが作成され、そこにすべての処理ステージが加入される。ユーザ（例えば、ユーザ６５０、６５２、または６５４のいずれか１つ）が例えば、ゲートウェイにオーダを提出すること（７０２）によってコネクションを開始すると、クライアントＩ／Ｏサービス６３４は、最初にリクエストを受信することができる。パイプライン処理ステージ６３４は、Ｉ／Ｏ接続サービス７０４およびＩ／Ｏソケットサービス７０６のためのそれぞれのスレッドを含むことができる。Ｉ／Ｏ接続サービス７０４は接続要求を受信し、制御セッション上の新規ユーザリクエストについて信号を送る。その後、Ｉ／Ｏソケットサービスはユーザとハンドシェイクを実行し、ユーザのための新規セッションの作成を開始する。リクエストがＩ／Ｏサービス７０４〜７０６によって処理された後、当該リクエストは、新規セッションのためのサブスクライバを作成することによってＳＯＵＰフレーミングサービス７０８によって処理される。フレーミングサービス７０８は、認証処理ステージ７１０で認証リクエストを提出してもよい。認証パイプラインステージ７１０で認証が成功すると、フレーミングサービス７０８に通知され、ユーザセッションが操作７１２で作成され、実行カーネル内の対応するセッションアナウンスが進行する。

【0089】

図８の説明
図８は、いくつかの例示的な実施形態による、図６に示されるゲートウェイアプリケーションにおけるユーザセッション確立のための操作８００の例示的なシーケンスを示す。操作８００は、図７に示されるユーザセッションアナウンスメントに応答して、パイプラインの残りの部分におけるシグナリングおよびセッションアタッチメントを示す。パイプライン処理ステージは、新しいセッションが作成されたことを示すシグナリングをリッスンする。パイプラインステージはイングレスメッセージの適切なサブスクライバ、エグレスメッセージのパブリッシャをセットアップし、これが行われると、構成要素はユーザセッションの作成を確認する。例えば、セッションが確立されると、７１２、ＯＵＣＨ（登録商標）デコード８０２、イングレスビジネスロジック８０４、バックエンドストリームエグレス８０６、バックエンドストリームイングレス８０８、エグレスビジネスロジック８１０、およびＯＵＣＨ（登録商標）エンコード８１２処理ステージは、必要に応じて、対応するクライアントオブジェクトおよび／または対応するサブスクライバおよびパブリッシャをインスタンス化することによってセットアップされ得る。パイプラインが完全にセットアップされると、ユーザに関連するメッセージの処理をＩ／Ｏサービスで送信できる。

【0090】

図９の説明
図９は、いくつかの例示的な実施形態に従って、図６に示されるゲートウェイアプリケーションにおけるゲートウェイ取引イングレスパイプラインのための動作シーケンス９００の一例を示す。いくつかの例示的な実施形態による完了インバウンド（および図１０のアウトバウンド）パイプラインは、フロー９００および図６に詳述されている。パイプラインは、特定のユーザ特異性およびバックエンド特異性に依存する多数のバリエーションを示す。任意の所与の構成およびユーザに対して、直線的な流れのみが使用されてもよい。例えば、第１のユーザの場合、ストレートフローは、パイプライン処理ステージＩ／Ｏソケットサービス９０２、ＳＯＵＰ（登録商標）フレーミングサービス９０４、ＯＵＣＨ（登録商標）プロトコル・デコード・サービス９０６、ビジネス・ロジック・イングレス・サービス９０８、およびストリームサービス９１０〜９１４のいずれか１つのシーケンスを含むことができる。第２のユーザの場合、ストレートフローは、Ｉ／Ｏソケットサービス９０２、ＦＩＸ（登録商標）セッションサービス９１６、ＦＩＸ（登録商標）プロトコル・デコード・サービス９１８、ビジネス・ロジック・イングレス・サービス９０８、およびストリームサービス９１０〜９１４のいずれか１つを含むことができる。ＳＯＵＰフレーミングサービス９０４は、ユーザ毎に状態を維持する。イングレスビジネスロジックは、特定のリスク等を低減するように指示されてもよく、特定の順序に応じて変化してもよい。処理レベルでは、パイプラインのすべての組合せを同時にアクティブにすることができ、異なるユーザ固有プロトコルおよびバックエンドプロトコルを同時に使用することができる。

【0091】

図１０の説明
図１０は、いくつかの例示的な実施形態による、図６に示されるゲートウェイアプリケーションにおけるゲートウェイ取引エグレスパイプラインのための操作１０００の例示的なシーケンスを示す。任意のフロー１０００は、フロー９００と共通の１つ以上の処理ステージインスタンスを有することができる。図９に関連して上述した第１のユーザのためのエグレス・ストレート・フローは、ストリームサービス１００２〜１００６、ビジネス・ロジック・エグレス・サービス１００８、ＯＵＣＨ（登録商標）プロトコル・デコード・サービス１０１０、ＳＯＵＰ（登録商標）フレーミングサービス１０１２、およびＩ／Ｏソケットサービス１０１４のうちの任意の１つのパイプライン処理ステージのシーケンスを含むことができる。第２のユーザの場合、エグレス・ストレート・フローは、ストリームサービス１００２〜１００６、ビジネス・ロジック・エグレス・サービス１００８、ＦＩＸ（登録商標）プロトコル・エンコード・サービス１０１６、ＦＩＸ（登録商標）セッションサービス１０１８、およびＩ／Ｏソケットサービス１０１４のうちの任意の１つを含むことができる。ゲートウェイは、バックエンド・サーバ・インフラストラクチャへの単一の接続しか持たない可能性があるので、すべてのユーザのためにバックエンドへの発信ユーザ・トラフィックを処理するＩ／Ｏソケットサービス１０１４の単一のインスタンスが存在する可能性がある。ＳＯＵＰフレーミングサービス１０１２はユーザ毎にバッファリングとフレーミングを実行し、ＳＯＵＰフレーミングサービス９０４とユーザ毎に（ユーザ毎のイングレスとエグレスとの間の状態を維持するために）同じインスタンスであってもよい。

【0092】

図１１の説明
図１１は、いくつかの例示的な実施形態による、パブリッシュ−サブスクライブ・フレームワークにおいて実行される、図１に示される電子取引所アプリケーション１１６などの例示的なアプリケーションを示す。

【0093】

電子取引所アプリケーションのマッチングエンジンを図１１に示す。マッチングエンジンは、異なる処理ステージが実行カーネル１１０２上で実行されるように分離され、パイプラインの一部が並列化されてパイプライン処理ステージの非同期および同時実行を可能にするパイプラインとしてモデル化することができる。特に、注文書処理ステージはパイプラインの残りの部分から切り離すことができ、複数のユーザおよび／またはゲートウェイをそのステージで同時にサービスすることができるように並列化することができる。

【0094】

マッチングエンジンは、取引を受け入れ、応答を送信するストリームＩ／Ｏ処理ステージ、メッセージデコーディング（復号）ステージ、静的検証およびロジックステージ、分割型注文書ロジックステージ、およびメッセージエンコーディング（符号化）ステージに分解することができる。ユーザを多重化し、したがってユーザ接続のレベルで並列化することができる図６のゲートウェイアプリケーションとは対照的に、マッチングエンジンは複数の注文書または注文書セクションを処理し、注文書処理ステージで並列化することができる。これらの分解されたステージに対応して、ストリームＩ／Ｏサービス１１５０、メッセージ・デコーダ・サービス１１５２、およびメッセージ・エンコーダ・サービス１１５４のためのクライアントスレッドはＣＰＵコア１内に位置することができ、静的検証サービス１１５６および静的ロジックサービス１１５８はＣＰＵコア２内に位置することができ、注文書ロジックサービスのインスタンス１１６０〜１１６６はＣＰＵコア４、５、６、・・・上でインスタンス化することができ、図１１Ｎは、実行リソースにマッピングされた共通および分離データフローの両方を有するマッチング・エンジン・パイプライン・ステージの割り当てを示す。

【0095】

各ユーザ（例えば、図６に示すユーザ６５０、６５２、６５４など）のための処理パイプラインに含まれるメッセージ交換は、処理ステージ間の一連のパブリッシュ−サブスクライブ交換によって表すことができる。ユーザ６５０のパブリッシュサブスクライブシーケンスは、１１０４−１１０６−１１０８−１１３２−１１１２−１１３４（および／または１１１６−１１３６、１１２０−１１３８、１１２４−１１４０のうちの任意の１つ以上）−１１４２−１１３０；ユーザ６５２の場合、１１０４−１１０６−１１０８−１１１０−１１１２−１１１４（および／または１１１６−１１１８、１１２０−１１２２、１１２４−１１２６のうちの任意の１つ以上）−１１２８−１１３０であってもよい。

【0096】

セッション、クライアント、パブリッシャおよびサブスクライバのような実行カーネルオブジェクトのパイプライン構築および関連するセットアップは実行リソースの動的プロビジョニングが不要な単純な場合に、静的な方法で実行することができる。一方、注文書ロジックは分割され、注文書グループの処理は並列に行われる。

【0097】

オーバーラップ処理は少なくとも２つの重要な利点をもたらす。注文書ロジックが高度の計算量を有する場合、注文書を典型的な場合である独立したグループにセグメント化することができる場合、スループットを線形スケーリングで増加させることができ、異なる計算量を有する異なるタイプの注文書がある場合、「単純である」注文書の処理待ち時間は、「複雑である」注文書の処理待ち時間から切り離される。この複雑さの違いは異なるタイプの資産クラスを有するマーケットで観察することができ、この場合、複雑な戦略注文はあるクラスの資産に対しては可能であるが、別のクラスに対しては可能ではない。

【0098】

図１２の説明
図１２は、いくつかの例示的な実施形態による、図１１の電子取引所アプリケーションにおけるマッチング・エンジン・パイプラインのための動作１２００の例示的なシーケンスを示す。

【0099】

このようなモデルは「ラインスキップ」モデルをもたらし、これは、並列であるパイプ線ステージが任意の順序で完了することができる、重なり合った様式での入力メッセージの非同期処理を可能にする。図１２は基本的な静的に構成されたマッチングエンジン（ストリームＩ／Ｏ処理ステージ１２０２、メッセージデコード処理ステージ１２０４、静的検証ステージ１２０６、静的ロジック処理ステージ１２０８、注文書ロジックステージ１２１０〜１２１４のいずれか１つ以上、およびメッセージ符号化処理ステージ１２１６）におけるパイプラインステージを詳細に示し、矢印のいくつかは、検証ステージのために取引が完全なパイプラインを横断しないことにつながり得る決定を示す。

【0100】

図１３の説明
図１３は、いくつかの例示的な実施形態による、図１１の電子取引所アプリケーションにおける動的マッチング・エンジン・パイプラインのための動作１３００の例示的なシーケンスを示す。

【0101】

パイプラインをさらに拡張して、注文書分割（パーティショニング）の動的なスケーリングを可能にすることができる。これは、注文書ロジックグループ１３１０〜１３１４の追加および削除を同期させるガバナ１３１８を追加することによって達成される。ガバナを除いて、シーケンス１３００の他の処理ステージ（ストリームＩ／Ｏ処理ステージ１３０２、メッセージデコード処理ステージ１３０４、静的検証ステージ１３０６、静的ロジック処理ステージ１３０８、注文書ロジックステージ１３１０〜１３１４のうちのいずれか１つ以上、およびメッセージエンコード処理ステージ１３１６）は図１２に示される対応するステージと同じであってもよく、図１３は注文書ロジックグループ１３１０〜１３１４がガバナ１３１８にどのように接続されるかを示す。

【0102】

ガバナ１３１８は、処理トポロジへの変更が必要とされ、ガバナ１３１８とオーダロジックグループ１３１０〜１３１４との間の相互作用およびメッセージが通常のパイプライン取引に関連して分離および分離されたメッセージング・ドメインを可能にする異なるセッション上にある場合の同期点である。

【0103】

注文書ロジックグループを追加または削除する場合、ガバナは必要なグループにサスペンドメッセージを送信する。サスペンドメッセージを受信すると、通常のパイプライン処理が停止し、ガバナに現在保持モードになっていることを示す確認応答が送信される。すべての必要なグループがバリア（サスペンドメッセージで表されるなど）を確認した場合、ガバナは注文書グループトポロジを再設定し、これが完了すると、ガバナはサスペンドグループにレジュームメッセージを送信する。サスペンドグループは、受信時に取引パイプラインの処理を続行する。

【0104】

パイプラインの再構成の間、動作に関与するグループのみが中断される必要があり、これは、他の注文書グループのためのトランザクションのプロセスが中断されずに進行することができることを意味する。

【0105】

図１４の説明
図１４はいくつかの実施形態による、例示的なコンピューティングデバイス１４００（例えば、「コンピューティングデバイス」、「コンピュータシステム」、または「コンピューティングシステム」とも呼ばれ得る）のブロック図である。いくつかの実施形態において、コンピューティングデバイス１４００は、１つ以上のプロセッサ１４０２、１つ以上のメモリデバイス１４０４、１つ以上のネットワークインタフェースデバイス１４０６、１つ以上のディスプレイインタフェース１４０８、および１つ以上のユーザ入力アダプタ１４１０のうちの１つ以上を含む。さらに、いくつかの実施形態では、コンピューティングデバイス１４００がディスプレイデバイス１４１２に接続されるか、またはこれを含む。以下で説明するように、これらの要素（例えば、プロセッサ１４０２、メモリデバイス１４０４、ネットワークインタフェースデバイス１４０６、ディスプレイインタフェース１４０８、ユーザ入力アダプタ１４１０、ディスプレイデバイス１４１２）はコンピューティングデバイス１４００のための様々な異なる機能を実行するように構成されたハードウェアデバイス（例えば、電子回路または回路の組合せ）である。

【0106】

いくつかの実施形態では、プロセッサ１４０２の各々または任意が例えば、シングルコアまたはマルチコアプロセッサ、マイクロプロセッサ（例えば、中央処理装置またはＣＰＵと呼ばれ得る）、デジタル信号プロセッサ（ＤＳＰ）、ＤＳＰコアに関連するマイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、またはシステムオンチップ（ＳＯＣ）（例えば、ＣＰＵと、メモリ、ネットワーキングインタフェースなどの他のハードウェア構成要素とを含む集積回路）であるか、またはそれらを含む。そして／またはいくつかの実施形態では、プロセッサ１４０２のそれぞれまたは任意のものはｘ８６またはＡｄｖａｎｃｅｄ ＲＩＳＣ Ｍａｃｈｉｎｅ（ＡＲＭ）のような命令セットアーキテクチャを使用する。

【0107】

いくつかの実施形態では、メモリデバイス１４０４の各々または任意のものはランダムアクセスメモリ（ＲＡＭ）（ダイナミックＲＡＭ（ＤＲＡＭ）またはスタティックＲＡＭ（ＳＲＡＭ）など）、フラッシュメモリ（例えば、ＮＡＮＤまたはＮＯＲ技術に基づく）、ハードディスク、光磁気媒体、光媒体、キャッシュメモリ、レジスタ（例えば、命令を保持する）、またはデータおよび／または命令の揮発性または不揮発性記憶を実行する他の種類の装置（例えば、プロセッサ１４０２上またはそれによって実行されるソフトウェア）であるか、またはそれらを含む。メモリデバイス１４０４は、不揮発性コンピュータ可読記憶媒体の一例である。

【0108】

いくつかの実施形態では、ネットワークインタフェースデバイス１４０６のそれぞれまたは任意のものは１つ以上の回路（ベースバンドプロセッサおよび／または有線または無線トランシーバなど）を含み、１つ以上の有線通信技術（イーサネット（ＩＥＥＥ ８０２．３など））および／または無線通信技術（ブルートゥース、ＷｉＦｉ（ＩＥＥＥ ８０２．１１）、ＧＳＭ、ＣＤＭＡ２０００、ＵＭＴＳ、ＬＴＥ、ＬＴＥ−Ａｄｖａｎｃｅｄ（ＬＴＥ−Ａ）、および／または他の短距離、中距離、および／または長距離無線通信技術など）のためのレイヤ１、レイヤ２、および／またはより高いレイヤを実施する。トランシーバは、送信機及び受信機のための回路を備えることができる。送信機および受信機は共通の筐体を共有することができ、送受信を実行するために筐体内の回路のいくつかまたはすべてを共有することができる。いくつかの実施形態では、トランシーバの送信機および受信機がいかなる共通の回路も共有しなくてもよく、および／または同じまたは別個の筐体内にあってもよい。

【0109】

いくつかの実施形態では、ディスプレイインタフェース１４０８のそれぞれまたは任意のものはプロセッサ１４０２からデータを受信し、受信したデータに基づいて（例えば、別個ＧＰＵ、統合ＧＰＵ、グラフィカル処理を実行するＣＰＵなどを介して）対応する画像データを生成し、および／または出力し（例えば、Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ（ＨＤＭＩ）、ＤｉｓｐｌａｙＰｏｒｔインタフェース、ビデオグラフィックスアレイ（ＶＧＡ）インタフェース、デジタルビデオインタフェース（ＤＶＩ）など）、生成した画像データをディスプレイデバイス１４１２に表示する１つ以上の回路である。代替的または追加的に、いくつかの実施形態では、ディスプレイインタフェース１４０８の各々または任意のものは例えば、ビデオカード、ビデオアダプタ、またはグラフィックス処理ユニット（ＧＰＵ）であるか、またはそれを含む。

【0110】

いくつかの実施形態では、ユーザ入力アダプタ１４１０のそれぞれまたは任意のものはコンピューティングデバイス１４００に含まれ、それに取り付けられ、またはそれと通信する１つ以上のユーザ入力デバイス（図１４には図示せず）からユーザ入力データを受信し、処理し、受信した入力データに基づいてプロセッサ１４０２にデータを出力する１つ以上の回路であるか、またはそれを含む。代替的にまたは追加的に、いくつかの実施形態では、ユーザ入力アダプタ１４１０の各々または任意のものは例えば、ＰＳ／２インタフェース、ＵＳＢインタフェース、タッチスクリーンコントローラなどであるか、またはそれらを含み、および／またはユーザ入力アダプタ１４１０は例えば、キーボード、マウス、トラックパッド、タッチスクリーンなどのユーザ入力デバイス（図１４には示されていない）からの入力を容易にする。

【0111】

いくつかの実施形態では、ディスプレイデバイス１４１２は液晶表示（ＬＣＤ）ディスプレイ、発光ダイオード（ＬＥＤ）ディスプレイ、または他の種類のディスプレイデバイスであってもよい。ディスプレイデバイス１４１２がコンピューティングデバイス１４００の構成要素である（例えば、コンピューティングデバイスおよびディスプレイデバイスが統一されたハウジングに含まれる）実施形態では、ディスプレイデバイス１４１２はタッチスクリーンディスプレイまたは非タッチスクリーンディスプレイであってもよい。ディスプレイデバイス１４１２がコンピューティングデバイス１４００に接続される（例えば、コンピューティングデバイス１４００の外部にあり、有線および／または無線通信技術を介してコンピューティングデバイス１４００と通信する）実施形態では、ディスプレイ１４１２は例えば、外部モニタ、プロジェクタ、テレビ、ディスプレイスクリーンなどである。

【0112】

様々な実施形態では、コンピューティングデバイス１４００が上述の要素（例えば、プロセッサ１４０２、メモリデバイス１４０４、ネットワークインタフェースデバイス１４０６、ディスプレイインタフェース１４０８、およびユーザ入力アダプタ１４１０）のそれぞれまたは任意の１つ、２つ、または３つ、４つ、またはそれ以上を含む。代替的または追加的に、いくつかの実施形態では、コンピューティングデバイス１４００がプロセッサ１４０２を含む処理システムと、メモリデバイス１４０４を含むメモリまたは記憶システムと、ネットワークインタフェースデバイス１４０６を含むネットワークインタフェースシステムとのうちの１つ以上を含む。

【0113】

コンピューティングデバイス１４００は、様々な実施形態において、多くの異なる方法で構成され得る。一例として、コンピューティングデバイス１４００はプロセッサ１４０２がマルチ（または単一）コアプロセッサと、第１のネットワークインタフェースデバイス（例えば、ＷｉＦｉ、Ｂｌｕｅｔｏｏｔｈ、ＮＦＣなどを実装する）と、１つ以上のセルラー通信技術（例えば、３Ｇ、４Ｇ ＬＴＥ、ＣＤＭＡなど）を実装する第２のネットワークインタフェースデバイスと、メモリまたはストレージデバイス（例えば、ＲＡＭ、フラッシュメモリ、またはハードディスク）とを含むように配置されてもよい。プロセッサ、第１のネットワークインタフェースデバイス、第２のネットワークインタフェースデバイス、およびメモリデバイスは同じＳＯＣ（例えば、１つの集積回路チップ）の一部として統合されてもよい。別の例として、コンピューティングデバイス１４００はプロセッサ１４０２が２つ、３つ、４つ、５つ、またはそれ以上のマルチコアプロセッサを含むように配置されてもよい。ネットワークインタフェースデバイス１４０６はイーサネットを実装する第１のネットワークインタフェースデバイスと、ＷｉＦｉおよび／またはＢｌｕｅｔｏｏｔｈを実装する第２のネットワークインタフェースデバイスとを含み、メモリデバイス１４０４はＲＡＭおよびフラッシュメモリまたはハードディスクを含む。

【0114】

先に述べたように、ソフトウェアモジュールまたはソフトウェアプロセスが何らかのアクションを実行することが本書に記載されている場合、そのアクションは、実際にはソフトウェアモジュールを構成する命令に従って、基盤となるハードウェア要素によって実行される。前述のように、様々な実施形態では、サーバインフラストラクチャ１０２、クライアントデバイス１０８および１１０、ゲートウェイ１０４、コンピュータ１１２および１１４、電子交換アプリケーション１１６、ゲートウェイアプリケーション１２６、システムソフトウェア１２０および１２４、システムソフトウェア１３０、クライアントアプリケーション１３２および１３４、コンピュータ２０８、デコンポーザ２１８、設定２２０、処理ステージ６３２〜６５０、および処理ステージ１１５２〜１１６６の各々または任意の組み合わせは、本明細書の残りの部分では「コンポーネント」として明確にするために個別に参照されるであろうが、図１４のコンピューティングデバイス１４００の例を使用して実施される。そのような実施形態では、各構成要素について以下のことが適用される：（ａ）図１４に示すコンピューティングデバイス１４００のエレメント（すなわち、１つ以上のプロセッサ１４０２、１つ以上のメモリデバイス１４０４、１つ以上のネットワークインタフェースデバイス１４０６、１つ以上のディスプレイインタフェース１４０８、および１つ以上のユーザ入力アダプタ１４１０）、または前記の適切な組み合わせまたはサブセット）は、コンポーネントによって実行されるように、および／またはコンポーネント内に含まれるように本明細書に記載された任意のソフトウェアモジュールによって実行されるように、本明細書に記載された動作、活動、または機能のそれぞれまたは任意の組み合わせを実行するように構成され、適合され、および／またはプログラムされ、ｂ）代替的または追加的に、１つ以上のソフトウェアモジュールがコンポーネント内に存在することが本明細書に記載されている範囲で、いくつかの実施形態では、そのようなソフトウェアモジュール（およびソフトウェアモジュールによって処理および／または使用されるように本明細書に記載されている任意のデータ）は、メモリデバイス１４０４内に格納されている（例えば様々な実施形態では、ＲＡＭまたは命令レジスタなどの揮発性メモリデバイス内、および／またはフラッシュメモリまたはハードディスクなどの不揮発性メモリデバイス内）に格納され、ソフトウェアモジュールによって実行されるように本明細書に記載されているすべての動作は、適宜、コンピューティングデバイス１４００内および／またはコンピューティングデバイス１４００に接続されている他の要素（すなわち、ネットワークインタフェースデバイス１４０６、ディスプレイインタフェース１４０８、ユーザ入力アダプタ１４１０、および／またはディスプレイデバイス１４１２）と連携してプロセッサ１４０２によって実行され、（ｃ）代替的または追加的に、コンポーネントがデータを処理および／または別の方法で処理することが本明細書に記載されている範囲で、いくつかの実施形態では、そのようなデータは、メモリデバイス１４０４（例えば、いくつかの実施形態では、ＲＡＭなどの揮発性メモリデバイス内および／またはフラッシュメモリまたはハードディスクなどの不揮発性メモリデバイス内）および／またはコンピューティングデバイス１４００内および／またはコンピューティングデバイス１４００に接続された他の要素（すなわち、ネットワークインタフェースデバイス１４０６、ディスプレイインタフェース１４０８、ユーザ入力アダプタ１４１０、および／またはディスプレイデバイス１４１２）と適宜連携してプロセッサ１４０２によって処理／処理され、（ｄ）代替的または追加的に、いくつかの実施形態では、メモリデバイス１４０２は、プロセッサ１４０２によって実行されると、プロセッサ１４０２に、コンピューティングデバイス１４００内および／またはコンピューティングデバイス１４００に接続された他の要素（すなわち、メモリデバイス１４０４、ネットワークインタフェースデバイス１４０６、ディスプレイインタフェース１４０８、ユーザ入力アダプタ１４１０、および／またはディスプレイデバイス１４１２）と連携して、コンポーネントによって適宜実行されるように、および／またはコンポーネント内に含まれるように、本明細書に記載された任意のソフトウェアモジュールによって実行されるように、本明細書に記載された動作のそれぞれまたは任意の組み合わせを実行させる命令を記憶する。

【0115】

図１４に示され、上記で説明されたハードウェア構成は例として提供され、本明細書で説明された主題は様々な異なるハードウェアアーキテクチャおよび要素と併せて利用され得る。例えば、本明細書の多くの図では個々の機能／アクションブロックが示され、様々な実施形態ではこれらのブロックの機能が（ａ）個々のハードウェア回路を使用して、（ｂ）記載された機能／アクションを実行するように特に構成された特定用途向け集積回路（ＡＳＩＣ）を使用して、（ｃ）記載された機能／アクションを実行するように特に構成された１つ以上のデジタル信号プロセッサ（ＤＳＰ）を使用して、（ｄ）図１４を参照して上述したハードウェア構成を使用して、（ｅ）他のハードウェア構成、アーキテクチャ、および構成を介して、および／または（ａ）〜（ｅ）に記載された技術の組合せを介して、実施され得る。

【0116】

＜記載された主題の技術的利点＞
特定の例示的な実施形態は、限定はしないが、電子取引所プラットフォームなどの特定のアプリケーションに対して、改善されたアプリケーション実行時間およびより良好なスループットを提供することができる。実施形態によれば、パイプライン処理のボトルネックを軽減することにより、アプリケーションタスクのより迅速な完了及びより高いスループットを達成するために、アプリケーションのパイプライン処理段階を非同期かつ同時実行することにより、単一又はマルチプロセッサプラットフォーム上のマルチプロセス及び／又はマルチスレッドアプリケーションを実行するためのシステム及び方法が提供される。このようにして、実施形態はトランザクションを処理する従来技術とは対照的に、スーパースカラ性能を達成することができる。

【0117】

特定の例示的な実施形態はまた、内部通信インフラストラクチャ上のデータおよびメッセージングトラフィックの量を低減し、それによって、アプリケーション実行およびタスク完了時間をさらに改善する。実際に、例示的な電子取引所アプリケーションのためのいくつかの従来のパブリッシュ−サブスクライブ・フレームワークの使用はネットワークおよびシーケンサレベルの両方で、またオーバーヘッドの観点から、共有媒体上で結果として生じるデータ帯域幅要件のために実現可能ではなかったことが実験で観察された。また、従来のパブリッシュ−サブスクライブ・フレームワークを使用した場合、結果として生じる伝搬遅延およびスループットは適切ではなく、複数処理およびホストが追加された場合にスケーリングされないことも観察された。比較すると、他の態様において、いくつかの実施形態ではメッセージのためのロックフリーキューの使用、および共有メモリ位置へのポインタの複数のプロセッサまたはプロセッサコアへの通過は内部メッセージングのための輻輳を劇的に低減する。

【0118】

現在のオーダ・ゲートウェイ・アプリケーションおよびマッチングエンジンの実施は入力の完全な処理が任意の所与の入力に対する単一のコールチェーンとして実行される従来の命令的アプローチが必要とされるパフォーマンスレベルを満たすための唯一の実施形態であるため、実施においてモノリシックであるが、特定の例示的な実施形態は実質的により高速である（例えば、買い注文／売り注文のためのより速い平均取引完了時間）ことも観察される。この改善は少なくとも部分的には例示的な実施形態とは異なり、異なるフローがそれらの間で共有される処理ステージを有し、したがって並列化することができないので、従来のモノリシック実装が、ゲートウェイまたはマッチングエンジン内の異なるデータフローの同時処理を禁止するという特性によるものであり得る。

【0119】

＜記載された主題の追加申請＞
処理ステップ、アルゴリズムなどは特定の順序で説明または特許請求されてもよいが、そのような処理は異なる順序で動作するように構成されてもよい。言い換えると、明示的に説明または特許請求され得るステップの任意のシーケンスまたは順序は、必ずしも、ステップがその順序で実行されるという要件を示すものではない。本明細書で説明されるプロセスのステップは、可能な任意の順序で実行され得る。さらに、いくつかのステップは（例えば、１つのステップが他のステップの後に記載されるため）非同時発生として記載または暗示されているにもかかわらず、同時に実行されてもよい。さらに、図面におけるその描写によるプロセスの図示は、図示されたプロセスがそれに対する他の変形および修正を排除することを示唆せず、図示されたプロセスまたはそのステップのいずれかが技術に必要であることを示唆せず、図示されたプロセスが好ましいことを示唆しない。

【0120】

コンピュータ可読媒体／伝送の様々な形態がデータ（例えば、命令のシーケンス）をプロセッサに搬送することに関与してもよい。例えば、データは（ｉ）メモリからプロセッサに配信され、（ｉｉ）任意のタイプの伝送媒体（例えば、有線、無線、光など）を介して搬送され、（ｉｉｉ）イーサネット（登録商標）（またはＩＥＥＥ ８０２．３）、ＡＴＰ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、およびＴＣＰ／ＩＰ、ＴＤＭＡ、ＣＤＭＡ、３Ｇなどの多数のフォーマット、規格、またはプロトコルに従ってフォーマットされ、および／または伝送され、および／または（ｉｖ）プライバシーを保証するために、または当技術分野で周知の様々な方法のいずれかで不正を防止するために暗号化され得る。

【0121】

＜選択された用語＞
本書面では、「いくつかの実施形態」、「様々な実施形態」、「特定の実施形態」、「特定の例示的な実施形態」、「いくつかの例示的な実施形態」、「例示的な実施形態」に所定のアイテムが示されることが説明されるときはいつでも、または任意の他の類似の言葉が用いられるときはいつでも、所与のアイテムは少なくとも１つの実施形態に示され、全ての実施形態に示される必要はないことは理解されたい。上述と一致して、本書では、動作が実行され「てもよく」、「ることができ」、もしくは「うる」ことと、機能、エレメント、もしくは構成要素が所与のコンテキストに含まれ「てもよく」、「ることができ」、もしくは「うる」、または適用可能なことと、所与のアイテムが所与の特性を有し「てもよく」、「ることができ」、もしくは「うる」こととが説明されるときはいつでも、または「〜てもよい」、「〜できる」もしくは「〜しうる」という用語を含む任意の類似の語句が使用されるときはいつでも、所与の動作、特徴、エレメント、構成要素、特性、などは少なくとも１つの実施形態に示され、全ての実施形態に示される必要はないことが理解されたい。本書で使用される用語と語句、およびそれらの変形は、特に明記しない限り、限定ではなく自由に解釈されるべきである。先の例としては、「および／または」は、関連して挙げられたアイテムのうちの１つ以上の任意のまたは全ての組み合わせ（例えば、Ａおよび／またはＢは、Ａ、Ｂ、またはＡとＢを意味する）を含み、単数形「ａ」、「ａｎ」および「ｔｈｅ」は「少なくとも１の」、「１つ以上の」、または類似のものを意味するとして読まれるべきであり、「例」という用語は議論中の主題の例を提供するためにもちいられ、包括的または限定的なそれらのリストではなく、「備える」と「含む」（および他の活用とそれらの他の変形）は関連する挙げられたアイテムの存在を特定し、１つ以上の他のアイテムの存在または追加を不可能にするものではなく、アイテムが「随意に」と説明される場合、そのような説明は他のアイテムが随意ではないことを示すものと理解されるべきではない。

【0122】

本明細書で使用される「非一時的コンピュータ可読記録媒体」という用語は、レジスタ、キャッシュメモリ、ＲＯＭ、半導体メモリデバイス（Ｄ−ＲＡＭ、Ｓ−ＲＡＭ、または他のＲＡＭなど）、フラッシュメモリなどの磁気媒体、ハードディスク、光磁気媒体、ＣＤ−ＲＯＭ、ＤＶＤ、またはブルーレイディスクなどの光学媒体、または非一時的電子データ記憶のための他のタイプのデバイスを含む。「非一時的コンピュータ可読記録媒体」という用語には、一時的な伝搬する電磁信号は含まれない。

【要約】

開示される技術は、複数の処理ステージに分解されたアプリケーションが、アプリケーションの個別の処理ステージを互いに非同期かつ同時に実行することによって実行される、公開−加入メッセージ・フレームワークに関する。個別の処理ステージ間の通信は、公開−加入実行モデルに排他的に従うことができる。開示された公開−加入フレームワークは、マルチプロセッサ／マルチコア処理環境におけるそれぞれの処理リソースへの処理ステージの分散を可能にしながら、マルチプロセスおよび／またはマルチスレッド方式で実行されるべき処理ステージを提供する。電子取引所アプリケーションの例と、それに対応する取引所ゲートウェイアプリケーションの例が開示される。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】