(57)【要約】  より低減された待ち時間およびパフォーマンスのネックで大きいメッセージ量を処理するメッセージ・パブリッシュ／サブスクライブ・システムが、要求される。本発明によって導入されるインテリジェント・メッセージング・アプリケーション・プログラミング・インタフェース（ＡＰＩ）は、大量の、待ち時間の少ないメッセージング向けに設計される。このＡＰＩは、パブリッシュ／サブスクライブ・ミドルウェア・システムの一部である。このＡＰＩを用いて、このシステムは、とりわけ、待ち時間を含め、システム・パフォーマンスをリアルタイムで監視し、トピック・ベースのメッセージ通信およびチャネル・ベースのメッセージ通信を使用し、システム相互接続構成およびメッセージ伝送プロトコルを動的に最適化するように動作する。【特許請求の範囲】
【請求項１】
アプリケーションとパブリッシュ／サブスクライブ・ミドルウェア・システムとの間の通信のためのアプリケーション・プログラミング・インターフェースであって、
前記アプリケーションと、そのアプリケーションにトランスペアレントに、動的に選択されたメッセージ・トランスポート・プロトコルを使用し、リアル・タイムでトランスポート・チャネル・リソースとフローとを監視し、かつ動的に制御するように機能する通信エンジンを有するパブリッシュ／サブスクライブ・ミドルウェア・システムとの間の通信のためのゲートウェイとして機能するように構成された通信エンジンと、
前記アプリケーションと前記通信エンジンとの間の通信のための１つまたは複数のスタブと、
前記１つまたは複数のスタブと前記通信エンジンとの間の通信のためのバスと
を含む、アプリケーション・プログラミング・インターフェース。
【請求項２】
前記バスは、プロセス間通信バスまたはプロセス内通信バスである請求項１に記載のアプリケーション・プログラミング・インターフェース。
【請求項３】
前記通信エンジンは、さらに、フレーム内にパックされるメッセージの数を動的に調整するように機能する請求項１に記載のアプリケーション・プログラミング・インターフェース。
【請求項４】
前記通信エンジンは、さらに、セッション・ベースのフォールト・トレラントのために機能する請求項１に記載のアプリケーション・プログラミング・インターフェース。
【請求項５】
前記通信エンジンは、さらに、メッセージの一時的キャッシングのために機能する請求項１に記載のアプリケーション・プログラミング・インターフェース。
【請求項６】
前記通信エンジンは、さらに、値追加メッセージ処理のために機能する請求項１に記載のアプリケーション・プログラミング・インターフェース。
【請求項７】
前記値追加メッセージ処理は、内容ベースのアクセス制御リストの展開を含み、前記リスト内の各エントリは、アクセス条件とアクションに関連する請求項６に記載のアプリケーション・プログラミング・インターフェース。
【請求項８】
前記通信エンジンは、さらに、パブリッシュ／サブスクライブ・ミドルウェア・システム内のメッセージング・アプライアンスに登録し、これに論理的に接続されるようになるように機能する請求項１に記載のアプリケーション・プログラミング・インターフェース。
【請求項９】
前記登録は、ロギング要求であり、サブスクリプションは、トピック・ベースであり、トピックは、前記アプリケーション・プログラミング・インターフェースがそれに対するパブリッシュ／サブスクライブ資格を有する共有アクセス・ドメインを定義する請求項８に記載のアプリケーション・プログラミング・インターフェース。
【請求項１０】
前記通信エンジンは、さらに、レイト・スキーマ・バインディングのために機能する請求項１に記載のアプリケーション・プログラミング・インターフェース。
【請求項１１】
前記通信エンジンは、さらに、部分的メッセージ・パブリッシングのために機能する請求項１に記載のアプリケーション・プログラミング・インターフェース。
【請求項１２】
前記通信エンジンは、さらに、前記アプリケーションによる格納されたメッセージへの直接メモリ・アクセスのために機能する請求項１に記載のアプリケーション・プログラミング・インターフェース。
【請求項１３】
前記通信エンジンは、さらに、バルク・メッセージングを扱うように機能する請求項１に記載のアプリケーション・プログラミング・インターフェース。
【請求項１４】
前記バルク・メッセージングを扱うことは、キュー・オーバーフローと通信待ち時間を防ぐための制限を伴うメッセージ・キューイングを用いる請求項１２に記載のアプリケーション・プログラミング・インターフェース。
【請求項１５】
リアル・タイム・メッセージ・トランスポート・リソースとフロー制御は、古いメッセージの識別と無視またはメッセージのブレンディングのいずれかのポリシを使用する請求項１に記載のアプリケーション・プログラミング・インターフェース。
【請求項１６】
前記ポリシは、前記アプリケーション・プログラミング・インターフェースに関連するすべてのメッセージ・トランスポート・パスにグローバルに適用される請求項１５に記載のアプリケーション・プログラミング・インターフェース。
【請求項１７】
前記ポリシは、ユーザ定義される請求項１５に記載のアプリケーション・プログラミング・インターフェース。
【請求項１８】
前記ポリシは、アプリケーション・サブスクリプション時に定義され、実施される請求項１５に記載のアプリケーション・プログラミング・インターフェース。
【請求項１９】
前記通信エンジンは、さらに、メッセージを生の圧縮フォーマットで扱い、前記生のデータをそのスキーマにバインドするように機能する請求項１に記載のアプリケーション・プログラミング・インターフェース。
【請求項２０】
前記値追加メッセージ処理は、アプリケーション登録中に定義される請求項６に記載のアプリケーション・プログラミング・インターフェース。
【請求項２１】
前記通信エンジンは、さらに、メッセージ処理をインターフェース・カードにオフロードするように機能する請求項１に記載のアプリケーション・プログラミング・インターフェース。
【請求項２２】
前記パブリッシュ／サブスクライブ・ミドルウェア・システムは、メッセージング・アプライアンスを含み、プロトコル最適化は、前記メッセージング・アプライアンスと前記アプリケーション・プログラミング・インターフェースとの間で、前記アプリケーション・プログラミング・インターフェースがスレーブであるマスタ−スレーブ・ベースの構成で分散される請求項１に記載のアプリケーション・プログラミング・インターフェース。
【請求項２３】
前記プロセス間通信バスは、使用される場合に、ソケットまたは共有メモリを使用して実施され、前記プロセス内通信バスは、使用される場合に、関数呼出しを使用して実施される請求項２に記載のアプリケーション・プログラミング・インターフェース。
【請求項２４】
アプリケーションとパブリッシュ／サブスクライブ・ミドルウェア・システムとの間の通信のためのアプリケーション・プログラミング・インターフェースであって、
アプリケーションとパブリッシュ／サブスクライブ・ミドルウェア・システムとの間の通信のためのゲートウェイとして機能するように構成された通信エンジンであって、前記通信エンジンは、メッセージ・レイヤとメッセージ・トランスポート・レイヤを含む論理レイヤを有し、前記メッセージ・レイヤは、アプリケーション配信ルーティング・エンジン、管理メッセージ・レイヤ、メッセージ・ルーティング・エンジンを含み、前記メッセージ・トランスポート・レイヤは、システム・リソース使用に基づいてリアル・タイムで前記メッセージ・レイヤによって扱われるメッセージのトランスポート・パスを制御するチャネル管理部分を含む、通信エンジンと、
前記アプリケーションと前記通信エンジンとの間の通信のための１つまたは複数のスタブと、
前記１つまたは複数のスタブと前記通信エンジンとの間の通信のためのバスと
を含む、アプリケーション・プログラミング・インターフェース。
【請求項２５】
前記通信エンジンは、オペレーティング・システムの上で展開される請求項２４に記載のアプリケーション・プログラミング・インターフェース。
【請求項２６】
前記オペレーティング・システムは、前記チャネル管理部分が前記アプリケーションとの間でメッセージをトランスポートするためにそれを介して物理媒体とインターフェースするインターフェース・カードのドライバを含む請求項２４に記載のアプリケーション・プログラミング・インターフェース。
【請求項２７】
前記インターフェース・カードは、メモリ相互接続またはメッセージ処理オフロードのために機能するネットワーク・インターフェース・カードである請求項２６に記載のアプリケーション・プログラミング・インターフェース。
【請求項２８】
前記インターフェース・カードは、ハードウェア・ベースのネットワーキングＩ／Ｏ（入出力）スタックを含み、直接メモリ・アクセスと送信向けのキャッシングのために機能する請求項２６に記載のアプリケーション・プログラミング・インターフェース。
【請求項２９】
前記メッセージ・ルーティング・エンジンは、トランスポート・プロトコル最適化サービス部分を含む請求項２４に記載のアプリケーション・プログラミング・インターフェース。
【請求項３０】
前記アプリケーション配信ルーティング・エンジンは、アプリケーションをトピック・サブスクリプションにマッピングするように機能する請求項２４に記載のアプリケーション・プログラミング・インターフェース。
【請求項３１】
前記チャネル管理部分が複数のチャネルを制御し、前記アプリケーション配信ルーティング・エンジンは、前記マッピングに基づいてメッセージをアプリケーションに配信する請求項２４に記載のアプリケーション・プログラミング・インターフェース。
【請求項３２】
前記管理メッセージ・レイヤが管理メッセージを扱い、ルーティングとアプリケーション配信ルーティング・エンジンは、データ・メッセージを扱う請求項３０に記載のアプリケーション・プログラミング・インターフェース。
【請求項３３】
前記通信エンジンと前記１つまたは複数のスタブとがコンパイルされ、かつ、前記パブリッシュ／サブスクライブ・ミドルウェア・システムと通信するのに前記アプリケーション・プログラミング・インターフェースを使用するアプリケーションにリンクされる請求項２３に記載のアプリケーション・プログラミング・インターフェース。
【請求項３４】
前記通信エンジンは、さらに、レート・バインディング・スキーマのために機能する請求項２３に記載のアプリケーション・プログラミング・インターフェース。
【請求項３５】
前記アプリケーション配信ルーティング・エンジンは、スキーマを生のメッセージ・データにバインドし、これによって、前記アプリケーションがメッセージ情報にトランスペアレントにアクセスすることを可能にするように機能する請求項３４に記載のアプリケーション・プログラミング・インターフェース。
【請求項３６】
前記アプリケーションとの間のイングレス・メッセージとイグレス・メッセージについてアプリケーション・フォーマットとメッセージング・データ・スキーマとの間で変換するように機能するプレゼンテーション・エンジンをさらに含む請求項１に記載のアプリケーション・プログラミング・インターフェース。
【発明の詳細な説明】
【関連出願】
【０００１】
（先行出願の引用）
本願は、「Ｅｖｅｎｔ  Ｒｏｕｔｅｒ  Ｓｙｓｔｅｍ  ａｎｄ  Ｍｅｔｈｏｄ」という名称の２００５年１月６日に出願した米国特許仮出願第６０／６４１９８８号、および「Ｈｙｂｒｉｄ  Ｆｅｅｄ  Ｈａｎｄｌｅｒｓ  Ａｎｄ  Ｌａｔｅｎｃｙ  Ｍｅａｓｕｒｅｍｅｎｔ」という名称の２００５年６月８日に出願した米国特許仮出願第６０／６８８９８３号の利益を主張し、以上の仮出願を参照により組み込む。
【０００２】
本願は、「Ｅｎｄ−Ｔｏ−Ｅｎｄ  Ｐｕｂｌｉｓｈ／Ｓｕｂｓｃｒｉｂｅ  Ｍｉｄｄｌｅｗａｒｅ  Ａｒｃｈｉｔｅｃｔｕｒｅ」という名称の２００５年１２月２３日に出願した米国特許仮出願第＿＿＿＿＿＿＿＿号（弁理士整理番号５０００３−０００４）に関連し、これを参照により組み込む。
【技術分野】
【０００３】
本発明は、データ・メッセージング・ミドルウェア・アーキテクチャに関し、より詳細には、パブリッシュとサブスクライブ（以下では「パブリッシュ／サブスクライブ」）ミドルウェア・アーキテクチャを有するメッセージング・システム内のアプリケーション・プログラミング・インタフェースに関する。
【背景技術】
【０００４】
データ・メッセージング・インフラストラクチャによって要求されるパフォーマンス・レベルがますます高くなっていることが、ネットワーキング・インフラストラクチャやネットワーキング・プロトコルの進歩の抗し難い根本的な理由となっている。基本的に、データ配信には、データの様々な送信元と宛先だけでなくデータ送信元とデータ宛先の間における様々なタイプの相互接続アーキテクチャや通信モードがかかわる。既存のデータ・メッセージング・アーキテクチャの例には、ハブ・アンド・スポーク、ピア・ツー・ピア、ストア・アンド・フォワードが含まれる。
【０００５】
ハブ・アンド・スポーク・システム構成では、すべての通信は、ハブ経由でトランスポートされ、しばしば、非常に多くの量を処理する際、パフォーマンスのネックを生じさせる。したがって、このメッセージング・システム・アーキテクチャは、待ち時間をもたらす。このネックを回避する１つのやり方は、より多くのサーバを展開し、それらの異なるサーバにわたってネットワーク負荷を分散させることである。しかし、そのようなアーキテクチャは、スケーラビリティの問題や、動作上の問題をもたらす。ハブ・アンド・スポーク構成を有するシステムと比較して、ピア・ツー・ピア構成を有するシステムは、データを処理し、フィルタリングするアプリケーション群に不要なストレスをかけ、そのシステムの最も遅いコンシューマまたはノードが速度の限界である。次に、ストア・アンド・フォワード・システム構成では、永続性を与えるために、システムは、データを格納してから、パスにおける次のノードに、そのデータを転送する。格納オペレーションは、通常、メッセージに索引を付けて、ディスクに書き込むことによって行われ、これにより、パフォーマンスのネックが生じる可能性がある。さらに、メッセージ量が増加すると、索引付けのタスクや書き込みのタスクは、さらに遅くなる可能性があり、このため、さらなる待ち時間を生じさせる可能性がある。
【０００６】
既存のデータ・メッセージング・アーキテクチャは、いくつかの欠点を共に有している。１つの共通の欠点は、既存におけるデータ・メッセージングが、アプリケーション・レベルに存在するソフトウェアに依拠することである。このことは、メッセージング・インフラストラクチャが、ＯＳ（オペレーティング・システム）キューイングとネットワークＩ／Ｏ（入力／出力）を経験し、これにより、パフォーマンスのネックが生じる可能性があることを意味する。別の共通の欠点は、他のプロトコルが、状況下で、より適切である場合でさえ、既存のアーキテクチャは、データ・トランスポート・プロトコルを、動的にではなく、静的に使用することである。一般的なプロトコルのいくつかの例には、ルーティング可能なマルチキャスト、ブロードキャスト、またはユニキャストが含まれる。実際、既存のアーキテクチャにおけるＡＰＩ（アプリケーション・プログラミング・インタフェース）は、複数のトランスポート・プロトコルの間で、リアルタイムで切り換えを行うように設計されていない。
【０００７】
また、ネットワーク構成決定は、通常、展開時に行われ、通常、特定の想定の下で、ネットワーク条件とメッセージング条件の１つのセットを最適化するように定義される。静的（固定の）構成に関連する限界は、リアルタイムの動的なネットワーク再構成を除外する。つまり、既存のアーキテクチャは、すべてのネットワーク・データ・トランスポート負荷条件に必ずしも適しているわけではない特定のトランスポート・プロトコル向けに構成され、したがって、既存のアーキテクチャは、しばしば、変化、または、より高い負荷容量要件をリアルタイムで扱うことができない。
【０００８】
さらに、データ・メッセージングが、特定の受信者、または特定の受信者グループを宛先としている場合、既存のメッセージング・アーキテクチャは、いくつかのネットワークにわたってデータをトランスポートするために、ルーティング可能なマルチキャストを使用する。しかし、マルチキャスト向けにセットアップされたシステムには、データを配信するのに使用されることが可能なマルチキャスト・グループの数に限界があり、その結果、メッセージング・システムは、システムにサブスクライブしていない宛先（すなわち、この特定のデータのサブスクライバではないコンシューマ）にデータを送信してしまうことになる。これにより、コンシューマのデータ処理負荷、およびデータ・フィルタリングによる破棄率が高まる。すると、何らかの理由で過負荷になり、データのフローについて行くことができないコンシューマは、結局は、着信データをドロップし、後に、再送を求める。再送は、すべてのコンシューマが、繰り返しの伝送を受信し、コンシューマのすべてが、着信データを再処理するという点で、システム全体に影響を及ぼす。したがって、再送は、マルチキャスト・ストームを生じさせて、ついには、ネットワーク化されたシステム全体をダウンさせる可能性がある。
【０００９】
システムが、破棄率を低減する策としてユニキャスト・メッセージング向けにセットアップされた場合、メッセージング・システムは、データ重複のために帯域幅が飽和する可能性がある。例えば、複数のコンシューマが、関心対象の所与のトピックにサブスクライブした場合、メッセージング・システムは、データを各サブスクライバに配信しなければならず、実際、システムは、そのデータの異なるコピーを各サブスクライバに送信する。また、これにより、コンシューマが、サブスクライブ対象でないデータをフィルタリングして除く問題が解決されるものの、ユニキャスト伝送は、スケーラブルではなく、このため、ある特定のデータにサブスクライブする相当に大きいコンシューマ・グループ、または消費パターンの相当な重複に適合可能ではない。
【００１０】
さらに、パブリッシャとサブスクライバとの間のパスにおいて、メッセージは、アプリケーション間のホップで伝搬され、各ホップは、アプリケーションとオペレーティング・システム（ＯＳ）の待ち時間を導入する。したがって、全体的な終端間待ち時間は、ホップの数が増えるときに増加する。また、パブリッシャからサブスクライバへメッセージをルーティングする時に、そのパスに沿ったメッセージ・スループットは、そのパス内の最も遅いノードによって制限され、既存のシステムでは、この制限を克服するために終端間メッセージング・フロー制御を実施する方法はない。
【００１１】
既存のアーキテクチャの１つのより一般的な欠点は、それらのアーキテクチャのプロトコル変換が遅く、回数が多いことである。このことの理由は、ますます多くの新たな技術が、レガシー・システムと統合される、ＥＡＩ（Ｅｎｔｅｒｐｒｉｓｅ  Ａｐｐｌｉｃａｔｉｏｎ  Ｉｎｔｅｇｒａｔｉｏｎ）ドメインにおけるＩＴ（情報技術）応急処置戦略である。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
したがって、いくつかの領域でデータ・メッセージング・システム・パフォーマンスを向上させる必要性が存在する。パフォーマンスが向上を必要とする可能性がある例が、速度、リソース割り当て、待ち時間などである。
【課題を解決するための手段】
【００１３】
本発明は、ある程度、以上の所見と、そのような欠点に、異なるアプローチを使用して、より良い結果で対処することができるという考えとに基づく。以上の所見は、大量の、待ち時間が少ないメッセージング向けの終端間メッセージ・パブリッシュ／サブスクライブ・ミドルウェア・アーキテクチャと、特にインテリジェント・メッセージング・アプリケーション・プログラミング・インタフェース（ＡＰＩ）を生み出した。したがって、アプリケーションとの通信に関して、本発明の原理によるインテリジェント・メッセージングＡＰＩを含む終端間メッセージ・パブリッシュ／サブスクライブ・ミドルウェア・アーキテクチャを有するデータ配信システムは、相当に大きいメッセージ量を、大幅に少ない待ち時間で有利にルーティングすることが可能である。これを達成するために、本発明は、例えば、信頼性があり利用可能性が高いセッション・ベースのフォールト・トレラント設計を介し、レイト・スキーマ・バインディング、部分的パブリッシング、プロトコル最適化、リアルタイム・チャネル最適化、値追加計算定義言語（ｖａｌｕｅ−ａｄｄｅｄ  ｃａｌｃｕｌａｔｉｏｎｓ  ｄｅｆｉｎｉｔｉｏｎ  ｌａｎｇｕａｇｅ）、インテリジェント・メッセージング・ネットワーク・インタフェース・ハードウェア、アプリケーション向けのＤＭＡ（直接メモリ・アクセス）、システム・パフォーマンス監視、メッセージ・フロー制御、一時的キャッシングを伴うメッセージ・トランスポート・ロジック、値追加メッセージ処理の様々な組合せを導入することによる、ＡＰＩとメッセージング・アプライアンスの間の通信の改善を企図する。
【００１４】
このため、本明細書で示され、広く説明される本発明の目的によれば、アプリケーションとパブリッシュ／サブスクライブ・ミドルウェア・システムとの間の通信向けの１つの例示的なＡＰＩは、通信エンジンと、１つまたは複数のスタブと、プロセス間通信バス（単にバスと呼ぶ）とを含む。一実施態様で、通信エンジンは、例えば複数のアプリケーションが単一の通信エンジンを活用してメッセージを受信し、送信する時に、デーモン・プロセスとして実装されてもよい。もう１つの実施態様で、通信エンジンは、余分なデーモン・ホップを除去するために、スタブとともにアプリケーションにコンパイルされることが可能である。そのような実例では、通信エンジンとスタブとの間のバスは、プロセス内通信バスと定義される。
【００１５】
この実施態様では、通信エンジンは、アプリケーションとパブリッシュ／サブスクライブ・ミドルウェア・システムとの間の通信向けのゲートウェイとして機能するように構成される。通信エンジンは、アプリケーションにトランスペアレントに、動的に選択されたメッセージ・トランスポート・プロトコルを使用して、これによってプロトコル最適化をもたらし、また、リアルタイムでトランスポート・チャネル・リソースとフローを監視し、動的に制御するように機能する。１つまたは複数のスタブは、アプリケーションと通信エンジンとの間の通信に使用される。バスは、１つまたは複数のスタブと通信エンジンとの間の通信向けである。
【００１６】
さらに本発明の目的によれば、ＡＰＩの第２の例も、通信エンジン、１つまたは複数のスタブ、およびバスを含む。この実施態様の通信エンジンは、メッセージ・レイヤとメッセージ・トランスポート・レイヤを含む論理レイヤを用いて構築され、メッセージ・レイヤは、アプリケーション配信ルーティング・エンジン、管理メッセージ・レイヤ、メッセージ・ルーティング・エンジンを含み、メッセージ・トランスポート・レイヤは、メッセージ・レイヤによって取り扱われるメッセージのトランスポート・パスを制御するチャネル管理部分を含む。
【００１７】
前述の実施態様は、ＡＰＩを実施する例のうちの２つであり、他の例は、図面と以下の説明から明白になる。要するに、本発明の以上、およびその他の特徴、態様、利点は、本明細書の説明、添付の特許請求の範囲、後段で説明する添付の図面から、より良く理解されるようになろう。
【００１８】
本明細書に組み込まれ、本明細書の一部を構成する添付の図面は、本発明の様々な態様を例示し、説明と一緒に、本発明の諸原理を説明する役割をする。好都合な場合はいつでも、同一の符号が、すべての図面で、同一の要素、または同様の要素を指すのに使用される。
【発明を実施するための最良の形態】
【００１９】
本明細書の説明は、メッセージ・パブリッシュ−サブスクライブ・システムの終端間ミドルウェア・アーキテクチャの詳細、特に本発明の様々な実施形態によるインテリジェント・メッセージング・アプリケーション・プログラミング・インタフェース（ＡＰＩ）の詳細を提供する。しかしながら、これらの様々な実施形態の詳細の概要を述べる前に、以下は、この説明で使用される用語の簡単な説明である。この説明は、単に、そのような用語がどのように使用される可能性があるかについて、明確にし、読者に理解を与えることを、ただし、それらの用語が使用される文脈に、それらの用語を限定することなく、特許請求の範囲を限定することなしに、意図していることに留意されたい。
【００２０】
「ミドルウェア」という用語が、２つの別個の、しばしば、既に存在するプログラムの間を仲介する任意のプログラミングを表す一般的な用語として、コンピュータ業界で使用されている。このミドルウェアを追加する目的は、とりわけ、ネットワーク内のすべての参加者（パブリッシャやサブスクライバ）の間の通信インタフェースを定義することによって、情報交換に関連する複雑さの一部をアプリケーションからオフロードすることである。通常、ミドルウェア・プログラムは、メッセージング・サービスを提供し、その結果、様々なアプリケーションが通信できるようになる。ミドルウェア・ソフトウェア・レイヤを用いると、アプリケーション間の情報交換が、シームレスに実行される。異種のアプリケーションを、しばしば、ミドルウェアの使用を介して、一緒に系統立って結び付けることは、ＥＡＩ（Ｅｎｔｅｒｐｒｉｓｅ  Ａｐｐｌｉｃａｔｉｏｎ  Ｉｎｔｅｇｒａｔｉｏｎ）として知られる。しかし、この文脈において、「ミドルウェア」は、送信元と宛先の間におけるメッセージングとともに使用される、より広い用語であり、そのようなメッセージングを可能にするように展開される機構であり、このため、ミドルウェア・アーキテクチャは、以下に説明するとおり、個々に、または組合せで、効果的なデータ・メッセージングを円滑にするネットワーキング、およびコンピュータのハードウェア構成要素とソフトウェア構成要素を範囲に含む。さらに、「メッセージング・システム」または「ミドルウェア・システム」という用語が、パブリッシャとサブスクライバの間におけるメッセージのルーティングをメッセージング・サーバが管理する、パブリッシュ／サブスクライブ・システムの文脈において使用される。実際、メッセージング・ミドルウェアにおけるパブリッシュ／サブスクライブのパラダイムは、スケーラブルな、したがって、強力なモデルである。
【００２１】
「コンシューマ」という用語が、クライアント−サーバ・アプリケーションなどの文脈において使用される。１つの実例では、コンシューマは、ＡＰＩ（アプリケーション・プログラミング・インタフェース）を使用して、ミドルウェア・システムに登録し、情報にサブスクライブし、ミドルウェア・システムによって配信されたデータを受信するか、またはミドルウェア・システムに配信されたデータを送信するシステムまたはアプリケーションである。パブリッシュ／サブスクライブ・ミドルウェア・アーキテクチャ境界内のＡＰＩは、コンシューマであり、外部コンシューマは、ＡＰＩを使用せず、メッセージが、プロトコル変換を経る（以下に説明するとおり）通信相手である、任意のパブリッシュ／サブスクライブ・システム（または外部データ宛先）である。
【００２２】
「外部データ送信元」という用語が、データ配信システムとメッセージ・パブリッシュ／サブスクライブ・システムの文脈において使用される。１つの実例では、外部データ送信元は、一般的なプロトコルの１つで、または独自のメッセージ・プロトコルでメッセージをパブリッシュする、企業プライベート・ネットワークの内部または外部に配置された、システムまたはアプリケーションと見なされる。外部データ送信元の例は、ミドルウェア・システムを介してトレーダに配信される株式市場の取引値をパブリッシュする市場データ・エクスチェンジである。外部データ送信元の別の例は、トランザクション・データである。本発明の通常の実装では、以下により詳細に説明するとおり、ミドルウェア・アーキテクチャは、外部データ送信元からのデータが、ミドルウェア・システム・ドメインに入ると、変換される、固有のネイティブ・プロトコルを採用し、従来のシステムによくある複数のプロトコル変換を回避することに留意されたい。
【００２３】
また、「外部データ宛先」という用語も、データ配信システムとメッセージ・パブリッシュ／サブスクライブ・システムの文脈において使用される。外部データ宛先は、例えば、ローカル／グローバル・ネットワークを介してルーティングされる情報にサブスクライブする、企業プライベート・ネットワークの内部または外部に配置された、システムまたはアプリケーションである。外部データ宛先の一例は、トレーダによってパブリッシュされたトランザクション注文を扱う市場データ・エクスチェンジであることが可能である。外部データ宛先の別の例が、トランザクション・データである。以上のミドルウェア・アーキテクチャでは、外部データ宛先を宛先とするメッセージは、ネイティブ・プロトコルから、外部データ宛先に関連する外部プロトコルに変換されることに留意されたい。
【００２４】
「バス」という用語は、通常、相互接続を説明するのに使用され、ハードウェア相互接続またはソフトウェア・ベースの相互接続とすることが可能である。例えば、バスという用語は、ソケットと共有メモリを使用するものなどのプロセス間通信リンクを説明するのに使用することができ、関数呼出しなどのプロセス内リンクを説明するのに使用することも可能である。本明細書の説明から確認することができるとおり、本発明は、ミドルウェア・アーキテクチャ内で様々な構成で実現されるインテリジェント・メッセージング・アプリケーション・プログラミング・インタフェース（以下では「ＡＰＩ」）を用いて様々な形で実施可能である。したがって、この説明は、図１に示された終端間ミドルウェア・アーキテクチャの例から始まる。
【００２５】
この例示的なアーキテクチャは、以下を含むいくつかの有益な特徴を併せ持つ。すなわち、メッセージング一般的概念、ＡＰＩ、フォールト・トレランス、Ｐ＆Ｍ（プロビジョニング−マネージメント）、ＱｏＳ（サービス品質−融合型、ベスト・エフォート型、接続中保証型、切断中保証型など）、保証された配信ＱｏＳのための永続キャッシング、名前空間とセキュリティ・サービスの管理、パブリッシュ／サブスクライブ・エコシステム（コア構成要素、イングレス構成要素、イグレス構成要素）、トランスポート・トランスペアレント・メッセージング、近隣ベースのメッセージング（ハブ・アンド・スポーク、ピア・ツー・ピア、ストア・アンド・フォワードの間の混成であり、必要に応じて、サブスクリプションをすべての近隣に広めることができるサブスクリプション・ベースのルーティング・プロトコルを使用するモデル）、レイト・スキーマ・バインディング、部分的パブリッシング（データ全体ではなく、パブリッシングによって変更された情報だけ）、ネットワーク・リソースとシステム・リソースの動的割り当てである。後段で説明するとおり、パブリッシュ／サブスクライブ・ミドルウェア・システムは、ミドルウェア・アーキテクチャのフォールト・トレラント設計を有利に組み込む。すべてのパブリッシュ／サブスクライブ・エコシステムには、少なくとも１つの、しばしば複数のメッセージング・アプライアンス（ＭＡ）があり、これらのＭＡのそれぞれは、エッジ（イグレス／イングレス）ＭＡまたはコアＭＡとして機能するように構成される。パブリッシュ／サブスクライブ・エコシステムのコアＭＡ部分は、前述したネイティブ・メッセージング・プロトコル（ミドルウェア・システムに固有の）を使用するのに対して、イングレス部分とイグレス部分、エッジＭＡは、そのネイティブ・プロトコルへの変換と、そのネイティブ・プロトコルからの変換をそれぞれ行うことに留意されたい。
【００２６】
パブリッシュ／サブスクライブ・ミドルウェア・システム構成要素に加えて、図１の図は、論理接続と、それらの論理接続間の通信も示す。分かるように、図示されるミドルウェア・アーキテクチャは、分散システムのアーキテクチャである。このアーキテクチャを有するシステムにおいて、２つの別個の物理構成要素の間の論理通信は、メッセージ・ストリーム、および関連するメッセージ・プロトコルで確立される。メッセージ・ストリームは、２つのカテゴリのメッセージ、管理メッセージとデータ・メッセージのいずれかを含む。管理メッセージは、様々な物理構成要素の管理と制御、データへのサブスクリプションの管理、その他のために使用される。データ・メッセージは、送信元と宛先の間でデータをトランスポートするために使用され、通常のパブリッシュ／サブスクライブ・メッセージングでは、データ・メッセージの複数の送信者と複数の受信者とが存在する。
【００２７】
例示される構造上の構成、および論理通信で、パブリッシュ／サブスクライブ・ミドルウェア・アーキテクチャを有する分散メッセージング・システムは、いくつかの論理機能を実行するように設計される。１つの論理機能は、エッジＭＡ（メッセージング・アプライアンス）構成要素において有利に実行されるメッセージ・プロトコル変換である。これは、パブリッシュ／サブスクライブ・ミドルウェア・システムの境界内の通信が、基礎をなすトランスポート・ロジックとは独立のメッセージ向けのネイティブ・プロトコルを使用して行われるからである。このことが、このアーキテクチャを、トランスポート・トランスペアレントなチャネル・ベースのメッセージング・アーキテクチャと呼ぶ理由である。
【００２８】
第２の論理機能は、パブリッシャからサブスクライバにメッセージをルーティングすることである。メッセージは、パブリッシュ／サブスクライブ・ネットワーク全体でルーティングされることに留意されたい。このため、ルーティング機能は、メッセージが伝搬される、例えば、エッジＭＡ１０６ａ〜ｂ（またはＡＰＩ）からコアＭＡ１０８ａ〜ｃまで、または１つのコアＭＡから別のコアＭＡまで、さらに、最終的に、エッジＭＡ（例えば、１０６ｂ）またはＡＰＩ １１０ａ〜ｂまで、各ＭＡによって実行される。ＡＰＩ １１０ａ〜ｂは、プロセス間通信バス（ソケット、共有メモリなど）を介してメッセージのパブリッシングとメッセージへのサブスクライビングのために、または関数呼出しなどのプロセス間通信を介してアプリケーション１１２1〜nと通信する。
【００２９】
第３の論理機能は、例えば、接続中保証タイプと切断中保証タイプを含め、様々なタイプの保証配信サービス品質のためにメッセージを格納することである。これは蓄積交換機能の追加で達成される。
【００３０】
第４の機能は、サブスクライバに、それらのメッセージを配信することである（図示されるとおり、ＡＰＩ １０６ａ〜ｂは、サブスクライブするアプリケーション１１２1〜nにメッセージを配信する）。
【００３１】
このパブリッシュ／サブスクライブ・アーキテクチャでは、システム構成機能や、その他の管理機能とシステム・パフォーマンス監視機能は、Ｐ＆Ｍシステムによって管理される。構成は、パブリッシュ／サブスクライブ・ミドルウェア・システムのネットワークおよび構成要素の物理構成と論理構成との両方を含む。監視と報告は、すべてのネットワークとシステムの構成要素の健全性を監視し、要求に応じて、またはログに、結果を自動的に報告することを含む。Ｐ＆Ｍシステムは、管理メッセージを介して、構成機能、監視機能、報告機能を実行する。加えて、Ｐ＆Ｍシステムは、システム管理者が、パブリッシュ／サブスクライブ・ネットワーク全体にわたってルーティングされるメッセージのそれぞれに関連するメッセージ名前空間を定義することを可能にする。したがって、パブリッシュ／サブスクライブ・ネットワークは、名前空間ベースのサブネットワークに物理的および／または論理的に分割されることが可能である。
【００３２】
Ｐ＆Ｍシステムは、１つまたは複数のＭＡを有するパブリッシュ／サブスクライブ・ミドルウェア・システムを管理する。これらのＭＡは、システムにおけるＭＡの役割に応じて、エッジＭＡまたはコアＭＡとして展開される。エッジＭＡは、メッセージを、外部プロトコルからネイティブ・プロトコルに、またネイティブ・プロトコルから外部プロトコルに変換するプロトコル変換エンジンを含むこと以外は、ほとんどの点でコアＭＡと同様である。このため、一般に、メッセージング・システムにおけるパブリッシュ／サブスクライブ・システム・ミドルウェア・アーキテクチャの境界（すなわちエンドツーエンド・パブリッシュ／サブスクライブ・ミドルウェア・システム境界）は、エッジＭＡ１０６ａ〜ｂとＡＰＩ １１０ａ〜ｂが存在するエッジを特徴とし、それらの境界内に、コアＭＡ１０８ａ〜ｃが存在する。
【００３３】
システム・アーキテクチャは、特定の限られた地理的区域に限定されず、実際、地域的境界または国境を越えるように、さらに、大陸間にわたるようにさえ設計されることに留意されたい。そのようなケースでは、１つのネットワークにおけるエッジＭＡは、別の地理的に遠隔のネットワークにおけるエッジＭＡと、既存のネットワーキング・インフラストラクチャを介して通信することができる。
【００３４】
通常のシステムでは、コアＭＡ１０８ａ〜ｃは、パブリッシュされたメッセージをパブリッシュ／サブスクライブ・ミドルウェア・システム内で、エッジＭＡまたはＡＰＩ（例えば、ＡＰＩ １１０ａ〜ｂ）に向けて内部でルーティングする。特にコアＭＡにおけるルーティング・マップは、最大容量、少ない待ち時間、効率的なルーティングのために設計される。さらに、コアＭＡ間のルーティングは、リアルタイムで動的に変化することが可能である。いくつかのノード（コアＭＡ）を横断する所与のメッセージング・パスに関して、ルーティングのリアルタイムの変更は、ネットワーク利用率、全体的な終端間待ち時間、通信量、ネットワークおよび／またはメッセージ遅延、損失、ジッタを含め、１つまたは複数のメトリックに基づく。
【００３５】
代替として、２つ以上の異なるパスから最良のパフォーマンスを示すパスを動的に選択する代わりに、ＭＡは、メッセージ・レプリケーションに基づき、マルチパス・ルーティングを実行することができ、このため、すべてのパスにわたって同一のメッセージを送信することができる。異なるパスの収束点に位置するすべてのＭＡは、重複メッセージをドロップして、最初に着信したメッセージだけを転送する。このルーティング・アプローチは、少ない待ち時間のためにメッセージング・インフラストラクチャを最適化するという利点を有する。ただし、このルーティング方法の欠点は、そのインフラストラクチャが、重複トラフィックを伝送するのに、より多くのネットワーク帯域幅を必要とすることである。
【００３６】
エッジＭＡは、着信メッセージのいずれの外部メッセージ・プロトコルも、ミドルウェア・システムのネイティブ・メッセージ・プロトコルに変換し、送信メッセージに関してネイティブ・プロトコルから外部プロトコルに変換する能力を有する。つまり、外部プロトコルは、メッセージが、パブリッシュ／サブスクライブ・ネットワーク・ドメインに入る際に（イングレス）、ネイティブ（例えば、Ｔｅｒｖｅｌａ（商標））メッセージ・プロトコルに変換され、ネイティブ・プロトコルは、メッセージが、パブリッシュ／サブスクライブ・ネットワーク・ドメインを出る際に（イグレス）、外部プロトコルに変換される。エッジＭＡはまた、パブリッシュされたメッセージを、サブスクライブする外部データ宛先に配信するように動作する。
【００３７】
さらに、エッジＭＡ１０６ａ〜ｂとコアＭＡ１０８ａ〜ｃはともに、メッセージを格納してから、それらのメッセージを転送する。これが行われることが可能な１つの形は、ＣＥ（キャッシング・エンジン）１１８ａ〜ｂを使用して行うことである。１つまたは複数のＣＥが、同一のＭＡに接続されることが可能である。理論上、ＡＰＩは、このストア・アンド・フォワード能力を有さないと言われているが、現実には、ＡＰＩ １１０ａ〜ｂは、メッセージを格納してから、それらのメッセージをアプリケーションに配信することができ、アプリケーションから受信された（すなわちアプリケーションによってパブリッシュされた）メッセージを格納してから、それらのメッセージをコアＭＡ、エッジＭＡ、または別のＡＰＩに配信することができる。
【００３８】
ＭＡ（エッジＭＡまたはコアＭＡ）は、ＣＥに対する能動的な接続を有する場合、ルーティングされるメッセージのすべて、またはサブセットをＣＥに転送し、ＣＥは、それらのメッセージを、保存のためにストレージ領域に書き込む。すると、所定の期間にわたって、それらのメッセージは、要求されると、再送に利用可能である。以上のフィーチャが実施される例は、データ再生、部分的パブリッシュ、様々なサービス品質レベルである。部分的パブリッシュは、すべての情報の伝送ではなく、更新された情報だけの伝送しか要求しないため、ネットワーク負荷とコンシューマ負荷を減らすのに有効である。
【００３９】
ルーティング・マップが、ルーティングにどのように影響を与えるかを例示するように、パブリッシュ／サブスクライブ・ルーティング・パスのいくつかの例が、図１に示されている。この例示では、パブリッシュ／サブスクライブ・ネットワークのミドルウェア・アーキテクチャが、パブリッシャとサブスクライバの間で５つ以上の異なる通信パスを提供する。
【００４０】
第１の通信パスは、外部データ送信元を外部データ宛先にリンクする。外部データ送信元１１４1〜nから受信された、パブリッシュされたメッセージは、ネイティブ（例えば、Ｔｅｒｖｅｌａ（商標））メッセージ・プロトコルに変換され、次に、エッジＭＡ１０６ａによってルーティングされる。ネイティブ・プロトコル・メッセージが、エッジＭＡ１０６ａからルーティングされることが可能な１つの形は、外部データ宛先１１６ｎに対してである。そのパスは、通信パス１ａとして呼び出される。そのケースでは、ネイティブ・プロトコル・メッセージは、外部データ宛先に適した外部プロトコル・メッセージに変換される。ネイティブ・プロトコル・メッセージが、エッジＭＡ１０６ｂからルーティングされることが可能な別の形は、内部でコアＭＡ１０８ｂを経由してである。そのパスは、通信パス１ｂとして呼び出される。そのパスに沿って、コアＭＡ１０８ｂは、ネイティブ・メッセージをエッジＭＡ１０６ａにルーティングする。しかし、エッジＭＡ１０６ａは、ネイティブ・プロトコル・メッセージを外部データ宛先１１６１にルーティングする前に、それらのメッセージを、その外部データ宛先１１６１に適した外部メッセージ・プロトコルに変換する。分かるように、その通信パスは、ＡＰＩが、メッセージをパブリッシャからサブスクライバにルーティングすることを要求しない。したがって、パブリッシュ／サブスクライブ・ミドルウェア・システムが、外部送信元−宛先通信のために使用される場合、システムは、ＡＰＩを含まなくてもよい。
【００４１】
通信パス２として呼び出される別の通信パスは、外部データ送信元１１４ｎを、ＡＰＩ １１０ｂを使用するアプリケーションにリンクする。外部データ送信元から受信された、パブリッシュされたメッセージは、エッジＭＡ１０６ａにおいて、ネイティブ・メッセージ・プロトコルに変換され、次に、エッジＭＡによってコアＭＡ１０８ａにルーティングされる。第１のコアＭＡ１０８ａから、メッセージは、別のコアＭＡ１０８ｃ経由でＡＰＩ １１０ｂにルーティングされる。ＡＰＩから、メッセージは、サブスクライブするアプリケーション（例えば、１１２２）に配信される。通信パスは、双方向であるため、別の実例では、メッセージは、サブスクライブするアプリケーション１１２1〜nから外部データ宛先１１６ｎまで、逆方向のパスをたどることも可能である。各実例において、コアＭＡは、ネイティブ・プロトコル・メッセージを受信して、ルーティングするのに対して、エッジＭＡは、外部プロトコル・メッセージまたはネイティブ・プロトコル・メッセージを受信し、ネイティブ・プロトコル・メッセージまたは外部プロトコル・メッセージをそれぞれルーティングする（エッジＭＡは、そのような外部メッセージ・プロトコルに／から、ネイティブ・メッセージ・プロトコルに／から変換を行う）。各エッジＭＡは、このイングレス・メッセージがネイティブまたは外部プロトコル・メッセージとして入ってくるかどうかにかかわらず、イングレス・メッセージを、ネイティブ・プロトコル・チャネルと外部プロトコル・チャネルの両方に同時にルーティングすることができる。その結果、各エッジＭＡは、イングレス・メッセージを、外部コンシューマと内部コンシューマの両方に同時にルーティングすることができ、ただし、内部コンシューマは、ネイティブ・プロトコル・メッセージを消費し、外部コンシューマは、外部プロトコル・メッセージを消費する。この能力により、メッセージング・インフラストラクチャが、レガシー・アプリケーションやレガシー・システムをシームレスに、円滑に一体化することが可能になる。
【００４２】
通信パス３として呼び出される、さらに別の通信パスは、ＡＰＩ １１０ａ〜ｂをともに使用する、２つのアプリケーションをリンクする。それらのアプリケーションの少なくとも１つは、メッセージをパブリッシュするか、またはメッセージにサブスクライブする。パブリッシュされたメッセージの、サブスクライブする（パブリッシュする）アプリケーションへの（またはからの）配信は、パブリッシュ／サブスクライブ・ネットワークのエッジ上に位置するＡＰＩを介して行われる。アプリケーションが、メッセージにサブスクライブすると、コアＭＡまたはエッジＭＡの１つが、それらのメッセージをＡＰＩに向けてルーティングし、ＡＰＩは、データが、サブスクライブするアプリケーションに配信される用意ができると、それらのアプリケーションに通知する。アプリケーションからパブリッシュされたメッセージは、ＡＰＩを介して、ＡＰＩが「登録」されているコアＭＡ１０８ｃに送信される。
【００４３】
ＭＡで「登録」（ログイン）することにより、ＡＰＩは、そのＭＡに論理的に接続されるようになることに留意されたい。ＡＰＩは、登録（「ログイン」要求）メッセージをＭＡに送信することにより、ＭＡに対する接続を開始する。登録の後、ＡＰＩは、ＡＰＩのサブスクリプション・メッセージをＭＡに送信することにより、関心対象の特定のトピックにサブスクライブすることができる。トピックは、パブリッシュ／サブスクライブ・メッセージングに関して、メッセージに関する共有アクセス・ドメインやターゲットを定義するのに使用され、したがって、１つまたは複数のトピックへのサブスクリプションにより、そのようなトピック表記を有するメッセージの受信と送信が可能になる。Ｐ＆Ｍは、ネットワークにおけるＭＡに定期資格更新を送信し、各ＭＡは、そのＭＡ独自のテーブルを、それに相応して更新する。したがって、ＡＰＩが、ある特定のトピックにサブスクライブする資格があることが、ＭＡに分かった場合（ＭＡは、ルーティング資格テーブルを使用して、ＡＰＩの資格を検証する）、ＭＡは、そのＡＰＩに対する論理接続をアクティブにする。次に、ＡＰＩが、コアＭＡ１０８ｃに適切に登録されている場合、コアＭＡ１０８ｃは、図示されるとおり、データを第２のＡＰＩ １１０にルーティングする。その他の実例では、そのコアＭＡ１０８ｂは、さらなる１つまたは複数のＭＡ（図示せず）経由でメッセージをルーティングすることができ、それらのＭＡは、それらのメッセージをＡＰＩ １１０ｂにルーティングし、ＡＰＩ １１０ｂは、それらのメッセージを、サブスクライブするアプリケーション１１２1〜nに配信する。
【００４４】
見て取ることができるとおり、通信パス３は、外部データ・メッセージ・プロトコルが全くかかわらないため、エッジＭＡの存在を要求しない。その種の通信パスを例示する一実施形態では、企業システムは、様々なトピックに関する最新ニュースを従業員にパブリッシュするニュースサーバを有して構成される。ニュースを受信するのに、従業員は、ＡＰＩを使用するニュース・ブラウザ・アプリケーションを介して、従業員の関心対象のトピックにサブスクライブする。
【００４５】
ミドルウェア・アーキテクチャは、１つまたは複数のトピックへのサブスクリプションを可能にすることに留意されたい。さらに、このアーキテクチャは、トピック表記においてワイルドカードを許すことにより、単一のサブスクリプション要求で、一群の関連するトピックへのサブスクリプションを可能にする。
【００４６】
通信パス４として呼び出される、さらに別のパスが、Ｐ＆Ｍシステム１０２と１０４に関連する多くのパスの１つであり、それらのパスのそれぞれは、Ｐ＆Ｍを、パブリッシュ／サブスクライブ・ネットワーク・ミドルウェア・アーキテクチャにおけるＭＡの１つにリンクする。Ｐ＆Ｍシステムと各ＭＡの間で行き来するメッセージは、そのＭＡを構成し、監視するのに使用される管理メッセージである。１つのシステム構成では、Ｐ＆Ｍシステムは、ＭＡ群と直接に通信する。別のシステム構成では、Ｐ＆Ｍシステムは、ＭＡ群と、他のＭＡ群を介して通信する。さらに別の構成では、Ｐ＆Ｍシステムは、ＭＡ群と直接に通信することも、間接的に通信することもできる。
【００４７】
通常の実装では、ミドルウェア・アーキテクチャは、スイッチ、ルータ、その他のネットワーキング・アプライアンスを有するネットワークにわたって展開され、任意のタイプの物理媒体を介して通信することができるチャネル・ベースのメッセージングを使用する。このファブリックにこだわらないチャネル・ベースのメッセージングの１つの例示的な実装が、ＩＰベースのネットワークである。その環境では、すべてのパブリッシュ／サブスクライブ・物理構成要素間のすべての通信は、ＵＤＰ（ユーザ・データグラム・プロトコル）を介して実行され、トランスポートの信頼性は、メッセージング・レイヤによって提供される。この原理によるオーバーレイ・ネットワークが、図１ａに示される。
【００４８】
図示されるとおり、オーバーレイ通信１、２、３が、スイッチ２１４ａ〜ｃ、ルータ２１６、サブネット２１８ａ〜ｃを介して、３つのコアＭＡ２０８ａ〜ｃの間で行われる。つまり、それらの通信パスは、サブネット、スイッチ、ルータなどのネットワーキング・インフラストラクチャから成る、基礎をなすミドルウェア・ネットワークの上に確立されることが可能であり、前述したとおり、そのアーキテクチャは、広い地理的区域に（異なる国、または異なる大陸にさえ）わたることが可能である。
【００４９】
とりわけ、本発明の諸原理による以上、およびその他の終端間ミドルウェア・アーキテクチャは、様々なビジネス環境における様々な企業インフラストラクチャにおいて実施されることが可能である。１つのそのような実装が、図２に示される。
【００５０】
この企業インフラストラクチャでは、市場データ配信プラント１２が、様々な市場データ・エクスチェンジ３２０1〜nからの株式市場取引値をトレーダ（図示されていないアプリケーション）にルーティングするために、パブリッシュ／サブスクライブ・ネットワークの上に構築される。そのようなオーバーレイ・ソリューションは、例えば、ＭＡ間や、そのようなＭＡ群とＰ＆Ｍシステムの間で相互接続を提供するために、基礎をなすネットワークに依拠する。ＡＰＩ ３１０1〜nへの市場データ配信は、アプリケーション・サブスクリプションに基づく。このインフラストラクチャでは、アプリケーション（図示せず）を使用するトレーダが、パブリッシュ／サブスクライブ・ネットワークを介して（コアＭＡ３０８ａ〜ｂとエッジＭＡ３０６ｂ経由で）ＡＰＩ ３１０1〜nから市場データ・エクスチェンジ３２０1〜nに戻るようにルーティングされるトランザクション注文を行うことができる。
【００５１】
基礎をなす展開の実例が、図２ａに示される。図示されるとおり、ＭＡは、互いに直接に接続され、メッセージング・トラフィックのコンシューマとパブリッシャが物理的に接続されたネットワークとサブネットに直接につながれる。このケースでは、相互接続は、例えば、ＭＡ間、およびそれらのＭＡとＰ＆Ｍシステムの間の直接接続である。これにより、ネットワーク・バックボーン・ディスインターメディエーションと、メッセージング・トラフィックの、その他の企業アプリケーション・トラフィックからの物理的分離とが可能になる。事実上、ＭＡは、メッセージング・トラフィックに関して、従来のルーティング・ネットワークへの依拠を除くのに使用される。
【００５２】
物理的展開のこの例では、市場データ・エクスチェンジなどの外部データ送信元または宛先は、エッジＭＡに、例えば、エッジＭＡ１に直接に接続される。取引アプリケーションなどの、メッセージング・トラフィックの消費側アプリケーションまたはパブリッシュ側アプリケーションが、サブネット１〜１２に接続される。それらのアプリケーションは、サブスクライブする、パブリッシュする、または他のアプリケーションと通信する、少なくとも２つの仕方を有する。アプリケーションは、限定はしないが、メッセージング・トラフィックなどの、すべての企業アプリケーション・トラフィックを伝送する、冗長なルータやスイッチの複数のレイヤから成る企業バックボーンを使用する、または統合スイッチを介して互いに直接に相互接続されたエッジＭＡ群とコアＭＡ群から成るメッセージング・バックボーンを使用する。
【００５３】
代替のバックボーンを使用することは、メッセージング・トラフィックを、その他の企業アプリケーション・トラフィックから分離し、そのため、メッセージング・トラフィックのパフォーマンスをより良く制御するという利点を有する。１つの実装では、コアＭＡ３に論理的、または物理的に接続された、サブネット６内に位置するアプリケーションが、Ｔｅｒｖｅｌａ  ＡＰＩを使用して、ネイティブ・プロトコルでメッセージング・トラフィックにサブスクライブする、またはメッセージング・トラフィックをパブリッシュする。別の実装では、エッジＭＡ１に論理的、または物理的に接続された、サブネット７内に位置するアプリケーションが、外部プロトコルでメッセージング・トラフィックにサブスクライブし、またはメッセージング・トラフィックをパブリッシュし、ただし、ＭＡは、統合されたプロトコル変換エンジン・モジュールを使用して、プロトコル変換を実行する。論理的に、パブリッシュ／サブスクライブ・ネットワークの物理構成要素は、ＯＳＩ（Ｏｐｅｎ  Ｓｙｓｔｅｍｓ  Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）参照モデルのレイヤ１ないし４に類似したメッセージング・トランスポート・レイヤ上に構築される。ＯＳＩモデルのレイヤ１ないし４は、物理レイヤ、データリンク・レイヤ、ネットワーク・レイヤ、トランスポート・レイヤである。
【００５４】
このため、本発明の一実施形態では、パブリッシュ／サブスクライブ・ネットワークは、例えば、１つまたは複数のメッセージング・ライン・カードを、ネットワーク・スイッチとルータのすべて、またはサブセットに挿入することにより、基礎をなすネットワーク／ファブリックの中に直接に展開されることが可能である。本発明の別の実施形態では、パブリッシュ／サブスクライブ・ネットワークは、メッシュ・オーバーレイ・ネットワーク（すべての物理構成要素が、相互接続された）として展開されることが可能である。例えば、４つのＭＡの完全メッシュ・ネットワークは、それらのＭＡのそれぞれが、そのＭＡの３つのピアＭＡのそれぞれに接続されたネットワークである。通常の実装では、パブリッシュ／サブスクライブ・ネットワークは、１つまたは複数の外部データ送信元および／または宛先、１つまたは複数のＰ＆Ｍ（プロビジョニング−マネージメント）システム、１つまたは複数のＭＡ（メッセージング・アプライアンス）、１つまたは複数のオプションのＣＥ（キャッシング・エンジン）、１つまたは複数のオプションのＡＰＩ（アプリケーション・プログラミング・インタフェース）のメッシュ・ネットワークである。
【００５５】
上記のように、各パブリッシュ／サブスクライブ・ネットワークの境界内での通信は、基礎をなすトランスポート・ロジックとは独立であるメッセージ用のネイティブ・プロトコルを使用して行われる。このことが、このアーキテクチャを、トランスポート・トランスペアレントなチャネル・ベースのメッセージング・アーキテクチャと呼ぶ理由である。
【００５６】
図３は、チャネル・ベースのメッセージング・アーキテクチャ３２０をより詳細に示す。一般に、メッセージング送信元とメッセージング宛先の間の各通信パスは、メッセージング・トランスポート・チャネルと定義される。各チャネル３２６1〜nは、チャネル送信元とチャネル宛先の間にインタフェース３２８1〜nを有して、物理媒体を介して確立される。それぞれのそのようなチャネルは、ネイティブ（例えば、Ｔｅｒｖｅｌａ（商標））メッセージ・プロトコルなどの、特定のメッセージ・プロトコル向けに確立される。エッジＭＡ群（パブリッシュ／サブスクライブ・ネットワークのイングレスとイグレスを管理するＭＡ群）だけが、チャネル・メッセージ・プロトコル（外部メッセージ・プロトコル）を使用する。チャネル・メッセージ・プロトコルに基づき、チャネル管理レイヤ３２４は、着信メッセージと送信メッセージが、プロトコル変換を要求するかどうかを判定する。各エッジＭＡにおいて、着信メッセージのチャネル・メッセージ・プロトコルが、ネイティブ・プロトコルとは異なる場合、チャネル管理レイヤ３２４は、プロセスのためにメッセージを、ＰＴＥ（プロトコル変換エンジン）３３２を通るように送ってから、ネイティブ・メッセージ・レイヤ３３０に転送することにより、プロトコル変換を実行する。また、各エッジＭＡにおいて、送信メッセージのネイティブ・メッセージ・プロトコルが、チャネル・メッセージ・プロトコル（外部メッセージ・プロトコル）とは異なる場合、チャネル管理レイヤ３２４は、プロセスのためにメッセージを、ＰＴＥ（プロトコル変換エンジン）３３２を通るように送ってから、トランスポート・チャネル３２６1〜nにルーティングすることにより、プロトコル変換を実行する。したがって、チャネルは、物理媒体を有するインタフェース３２８1〜nを管理するだけでなく、その物理媒体に関連する特定のネットワーク−トランスポート・ロジックや、メッセージ再組立てまたはメッセージ・フラグメンテーションを管理する。
【００５７】
つまり、チャネルは、ＯＳＩトランスポート・レイヤ３２２を管理する。チャネル・リソースの最適化は、チャネルごとに行われる（例えば、帯域幅、メッセージ・サイズ分布、チャネル宛先リソース、チャネル健全性統計を含め、消費パターンに基づく、物理媒体に関するメッセージ密度最適化）。その場合、通信チャネルは、ファブリックにこだわらないため、特定のタイプのファブリックは、全く要求されない。実際、任意のファブリック媒体、例えば、ＡＴＭ、Ｉｎｆｉｎｉｂａｎｄ、またはＥｔｈｅｒｎｅｔ（登録商標）でよい。
【００５８】
ところで、例えば、単一のメッセージが、複数のフレームにわたって分割される場合、または複数のメッセージが、単一のフレーム・メッセージ・フラグメンテーションにパックされる場合、または再組立てが、メッセージをチャネル管理レイヤに送るのに先立って行われる場合、メッセージ・フラグメンテーションまたはメッセージ再組立てが、必要とされる可能性がある。
【００５９】
図３は、ミドルウェア・アーキテクチャを有するネットワークにおける、いくつかの可能なチャネル実装をさらに示す。１つの実装３４０では、通信は、イーサネット（登録商標）交換ネットワークを介するマルチキャストを使用して、ネットワーク・ベースのチャネルを介して行われ、イーサネット交換ネットワークは、そのような通信のための物理媒体の役割をする。この実装では、送信元は、送信元のＵＤＰポートを介して、送信元のＩＰアドレスから、それぞれのＩＰアドレス（したがってマルチキャスト）でそれぞれのＵＤＰを有する宛先のグループにメッセージを送信する。この実装３４２のバリエーションでは、送信元と宛先の間の通信は、ＵＤＰユニキャストを使用して、イーサネット交換ネットワークを介して行われる。送信元は、送信元のＩＰアドレスから、ＵＤＰポートを介して、それぞれのＩＰアドレスにおいてＵＤＰポートを有する選定された宛先にメッセージを送信する。
【００６０】
別の実装３４４では、チャネルは、ネイティブのＩｎｆｉｎｉｂａｎｄトランスポート・プロトコルを使用するＩｎｆｉｎｉｂａｎｄ相互接続を介して確立され、ただし、Ｉｎｆｉｎｉｂａｎｄファブリックは、物理媒体である。この実装では、チャネルは、ノード・ベースであり、送信元と宛先の間の通信は、それぞれのノード・アドレスを使用して、ノード・ベースである。さらに別の実装３４６では、チャネルは、ＲＤＭＡ（Ｒｅｍｏｔｅ  Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）などの、本明細書でＤＣ（直接接続）と呼ばれる、メモリ・ベースのチャネルである。このタイプのチャネルでは、メッセージは、送信元マシンから、宛先マシンのメモリの中に直接に送信され、このため、ＮＩＣからアプリケーション・メモリ空間へのメッセージを扱うＣＰＵ処理を回避し、場合により、メッセージをカプセル化して、ネットワーク・パケットにするネットワーク・オーバーヘッドを回避する。
【００６１】
ネイティブ・プロトコルに関して、１つのアプローチは、前述したネイティブのＴｅｒｖｅｌａ（商標）メッセージ・プロトコルを使用する。概念上、Ｔｅｒｖｅｌａ（商標）メッセージ・プロトコルは、ＩＰベースのプロトコルと同様である。各メッセージは、メッセージ・ヘッダと、メッセージ・ペイロードとを含む。メッセージ・ヘッダは、いくつかのフィールドを含み、フィールドの１つは、コンシューマによって、共有情報ドメインにサブスクライブするのに使用されるトピックを示すトピック情報用である。
【００６２】
図４は、１つの可能なトピック・ベースのメッセージ・フォーマットを示す。図示されるとおり、メッセージは、ヘッダ３７０、ならびにペイロードを含む本文３７２、３７４を含む。２つのタイプのメッセージ、データ・メッセージと管理メッセージが、異なるメッセージ本文、および異なるペイロード・タイプを有して示されている。ヘッダは、送信元名前空間ＩＤと宛先名前空間ＩＤ、送信元セッションＩＤと宛先セッションＩＤ、トピック・シーケンス番号、ホップ・タイムスタンプに関するフィールドを含み、さらに、ヘッダは、トピック表記フィールド（好ましくは、可変長の）を含む。トピックは、ＩＢＭ株のリアルタイムの取引値を含むメッセージに関するトピック・ストリングであるＮＹＳＥ．ＲＴＦ．ＩＢＭ３７６のような、トークン・ベースのストリングとして定義されることも可能である。
【００６３】
一部の実施形態では、メッセージの中のトピック情報は、１つまたは複数の整数値であるキーに符号化される、またはマップされることも可能である。その場合、各トピックは、一意のキーにマップされ、トピックとキーの間のマッピング・データベースは、Ｐ＆Ｍシステムによって保持され、オーバーザワイヤで、すべてのＭＡに更新が行われる。その結果、ＡＰＩが、１つのトピックにサブスクライブする、またはパブリッシュすると、ＭＡは、メッセージのトピック・フィールドのために使用された、関連する一意のキーを戻すことができる。
【００６４】
好ましくは、サブスクリプション・フォーマットは、メッセージ・トピックと同一のフォーマットに従う。しかし、サブスクリプション・フォーマットは、トピック・サブストリングとのワイルドカード一致をサポートし、トピック・ストリングとの通常の表現パターン一致もサポートする。実際のトピックに対するワイルドカードのマッピングは、Ｐ＆Ｍサブシステムに依存すること、あるいはワイルドカードまたはパターン一致要求の複雑さに依存して、ＭＡによって扱われることが可能である。
【００６５】
例えば、そのようなパターン一致は、以下のような規則が可能である。すなわち、
例＃１  Ｔ１．＊．Ｔ３．Ｔ４という、ワイルドカードを有するストリングが、Ｔ１．Ｔ２ａ．Ｔ３．Ｔ４およびＴ１．Ｔ２ｂ．Ｔ３．Ｔ４と一致するが、Ｔ１．Ｔ２．Ｔ３．Ｔ４．Ｔ５とは一致しない。
例＃２  Ｔ１．＊．Ｔ３．Ｔ４＊という、ワイルドカードを有するストリングが、Ｔ１．Ｔ２ａ．Ｔ３．Ｔ４およびＴ１．Ｔ２ｂ．Ｔ３．Ｔ４とは一致しないが、Ｔ１．Ｔ２．Ｔ３．Ｔ４．Ｔ５とは一致する。
例＃３  Ｔ１．＊．Ｔ３．Ｔ４．［＊］（オプションの第５の要素）という、ワイルドカードを有するストリングが、Ｔ１．Ｔ２ａ．Ｔ３．Ｔ４、Ｔ１．Ｔ２ｂ．Ｔ３．Ｔ４、およびＴ１．Ｔ２．Ｔ３．Ｔ４．Ｔ５とは一致するが、Ｔ１．Ｔ２．Ｔ３．Ｔ４．Ｔ５．Ｔ６とは一致しない。
例＃４  Ｔ１．Ｔ２＊．Ｔ３．Ｔ４という、ワイルドカードを有するストリングが、Ｔ１．Ｔ２ａ．Ｔ３．Ｔ４およびＴ１．Ｔ２ｂ．Ｔ３．Ｔ４と一致するが、Ｔ１．Ｔ５ａ．Ｔ３．Ｔ４とは一致しない。
例＃５  Ｔ１．＊．Ｔ３．Ｔ４．＞（任意の数の末尾要素）という、ワイルドカードを有するストリングが、Ｔ１．Ｔ２ａ．Ｔ３．Ｔ４、Ｔ１．Ｔ２ｂ．Ｔ３．Ｔ４、Ｔ１．Ｔ２．Ｔ３．Ｔ４．Ｔ５、およびＴ１．Ｔ２．Ｔ３．Ｔ４．Ｔ５．Ｔ６と一致する。
【００６６】
図５は、Ｔ１．Ｔ２．Ｔ３．Ｔ４のような、しばしばトークン・ベースのストリングと定義されるトピックをもつトピック・ベースのメッセージ・ルーティングを示す。ただし、Ｔ１、Ｔ２、Ｔ３、Ｔ４は、可変長のストリングである。分かるように、特定のトピック表記４００を有する着信メッセージが、通信チャネル４０４に選択的にルーティングされ、ルーティング決定は、ルーティング・テーブル４０２に基づいて行われる。チャネルに対するトピック・サブスクリプションのマッピングにより、経路が定義され、パブリッシュ／サブスクライブ・ネットワーク全体にわたってメッセージを伝えるのに使用される。それらすべての経路のスーパーセット、またはサブスクリプションとチャネルの間のマッピングにより、ルーティング・テーブルが定義される。ルーティング・テーブルは、サブスクリプション・テーブルとも呼ばれる。ストリング・ベースのトピックを介するルーティングのためのサブスクリプション・テーブルは、いくつかの仕方で構造化されることが可能であるが、好ましくは、テーブルのサイズや、ルーティングのルックアップ速度を最適化するように構成される。１つの実装では、サブスクリプション・テーブルは、動的ハッシュ・マップ構造として定義されることが可能であり、別の実装では、サブスクリプション・テーブルは、図５の図に示されるとおり、ツリー構造で構成されることが可能である。
【００６７】
ツリーは、エッジによって結び付けられたノード（例えば、Ｔ1，．．．Ｔ10）を含む。ただし、トピック・サブスクリプションの各サブストリングは、ツリーにおけるノードに対応する。所与のサブスクリプションにマップされたチャネルは、そのサブスクリプションのリーフ・ノード上に格納されて、各リーフ・ノードに関して、トピック・サブスクリプションが由来する（すなわち、受信されたサブスクリプション要求が経由した）チャネルのリストを示す。そのリストは、トピック表記がサブスクリプションと一致するメッセージのコピーを、いずれのチャネルが受信すべきかを示す。図示されるとおり、メッセージ・ルーティング・ルックアップは、メッセージ・トピックを入力として取り込み、そのトピックの各サブストリングを使用して、ツリーを解析して、その着信メッセージ・トピックに関連する、様々なチャネルを探し出す。例えば、Ｔ1、Ｔ2、Ｔ3、Ｔ4、Ｔ5は、チャネル１、２、３に向かわせられ、Ｔ1、Ｔ2、Ｔ3は、チャネル４に向かわせられ、Ｔ1、Ｔ6、Ｔ7、Ｔ*、Ｔ9は、チャネル４と５に向かわせられ、Ｔ1、Ｔ6、Ｔ7、Ｔ8、Ｔ9は、チャネル１に向かわせられ、Ｔ1、Ｔ6、Ｔ7、Ｔ*、Ｔ10は、チャネル５に向かわせられる。
【００６８】
ルーティング・テーブル構造の選択は、ルーティング・ルックアップ・テーブルを最適化するように意図されているが、ルックアップのパフォーマンスは、着信メッセージ・トピックと一致する１つまたは複数のトピック・サブスクリプションを見出すためのサーチ・アルゴリズムにも依存する。したがって、ルーティング・テーブル構造は、そのようなアルゴリズムを受け容れることができなければならず、その逆も同様である。ルーティング・テーブルのサイズを小さくする１つの仕方は、ルーティング・アルゴリズムが、パブリッシュ／サブスクライブ・ネットワーク全体にわたってサブスクリプションを選択的に広めることを可能にすることによってである。例えば、あるサブスクリプションが、既に広められている別のサブスクリプションのサブセット（例えば、ストリング全体の一部分）であるように見える場合、ＭＡは、そのサブスクリプションのスーパーセットに関する情報を既に有しているので、そのサブセット・サブスクリプションを広める必要は、全くない。
【００６９】
以上に基づき、好ましいメッセージ・ルーティング・プロトコルは、トピック・ベースのルーティング・プロトコルであり、資格は、サブスクライバと、それぞれのトピックとの間のマッピングにおいて示される。資格は、サブスクライバごとに指定され、サブスクライバが、どのようなメッセージを消費する権利を有するか、またはどのメッセージが、そのようなパブリッシャによって作成（パブリッシュ）されてもよいかを示す。それらの資格は、Ｐ＆Ｍマシンにおいて定義され、パブリッシュ／サブスクライブ・ネットワークにおけるすべてのＭＡに通信され、その後、ＭＡによって、ＭＡのルーティング・テーブルを作成し、更新するのに使用される。
【００７０】
各ＭＡは、そのＭＡのルーティング・テーブルを、誰が、どのようなトピックに関心があるか（サブスクライブを要求しているか）を常に把握しておくことにより、更新する。しかし、ＭＡは、経路をＭＡのルーティング・テーブルに追加する前に、パブリッシュ／サブスクライブ・ネットワークの資格に照らしてサブスクライブをチェックしなければならない。ＭＡは、近隣のＭＡ、Ｐ＆Ｍシステム、ＣＥ、またはＡＰＩであることが可能な、サブスクライブするエンティティが、サブスクライブすることを許可されていることを検証する。サブスクリプションが有効である場合、経路は、作成され、ルーティング・テーブルに追加される。その場合、一部の資格は、あらかじめ知られていることがあるため、システムは、事前定義された資格を伴って展開されることが可能であり、それらの資格が、起動時に自動的に読み込まれることが可能である。例えば、構成更新のような、一部の特定の管理メッセージは、ネットワーク全体にわたって既に転送されていることが可能であり、したがって、始動時に自動的に読み込まれることが可能である。
【００７１】
パブリッシュ／サブスクライブ・ミドルウェア・アーキテクチャを有するメッセージング・システムの上の説明を与えられれば、アプリケーション向けのメッセージングを扱う際に、インテリジェント・メッセージング・アプリケーション・プログラミング・インタフェース（以下では単にＡＰＩと称する）が、そのようなシステムにおいてかなりの役割を有することを理解することが可能である。アプリケーションは、登録、パブリッシング、サブスクライビングのためのものを含むすべてのメッセージングについて、このＡＰＩに頼る。登録は、管理登録要求を１つまたは複数のＭＡに送信することを含み、これらのＭＡは、ＡＰＩとアプリケーションの、そのように登録される資格を確認する。登録が妥当性検査されたならば、アプリケーションは、そのアプリケーションが資格を与えられている任意のトピックに関する情報にサブスクライブし、その情報をパブリッシュすることが可能である。したがって、これから、本発明の原理に従って構成されたＡＰＩの詳細の説明に移る。図６は、ＡＰＩを示すブロック図である。
【００７２】
この図では、ＡＰＩは、ＡＰＩ通信エンジン６０２とＡＰＩスタブ６０４の組合せである。通信エンジン６０２は、一般に、コンピュータ・システムが受信することを期待する周期的サービス要求を扱うためにオペレーティング・システムの下で実行されるプログラムとして知られるが、いくつかの実例では、アプリケーション自体の中に組み込まれ、したがって、プロセス内通信バスである。通信エンジン・プログラムは、適宜、要求を他のプログラム（またはプロセス）に転送する。この実例では、ＡＰＩ通信エンジンは、アプリケーションとパブリッシュ／サブスクライブ・ミドルウェア・システムとの間のゲートウェイとして働く。したがって、ＡＰＩ通信エンジンは、とりわけ、トランスポート・プロトコルを動的に選択することと、単一フレーム内にパックすべきメッセージの数を動的に調整することとによって、ＭＡとのアプリケーション通信を管理する。単一フレームにパックされるメッセージの数は、ＭＡとＡＰＩホストとの両方のメッセージ・レートやシステム・リソース利用率などの要因に依存する。
【００７３】
ＡＰＩスタブ６０４は、ＡＰＩ通信エンジンと通信するのに、アプリケーションによって使用される。一般に、リモート・プロシージャ・コール（ＲＰＣ）を使用するアプリケーション・プログラムは、そのプログラムのために、要求されたリモート・プロシージャの代わりになるスタブとともにコンパイルされる。スタブは、ＲＰＣを受け入れ、これをリモート・プロシージャに転送し、このリモート・プロシージャは、完了時に、ＲＰＣを行ったプログラムに結果を渡すためにスタブに結果を返す。いくつかの実例で、ＡＰＩスタブとＡＰＩ通信エンジンとの間の通信は、ソケットまたは共有メモリなどの機構を使用して実施されるプロセス間通信バスを介して行われる。ＡＰＩスタブは、Ｃ、Ｃ＋＋、Ｊａｖａ（登録商標）、．ＮＥＴを含む様々なプログラミング言語で使用可能である。ＡＰＩ自体は、その全体を複数の言語で使用可能とすることが可能であり、ＭＳ  Ｗｉｎｄｏｗｓ（商標）、Ｌｉｎｕｘ（商標）、およびＳｏｌａｒｉｓ（商標）を含む様々なオペレーティング・システム上で動作することが可能である。
【００７４】
ＡＰＩ通信エンジン６０２とＡＰＩスタブ６０４は、コンパイルされて、そのＡＰＩを使用しているすべてのアプリケーション６０６にリンクされる。ＡＰＩスタブとＡＰＩ通信エンジンの間の通信は、ソケットまたは共有メモリなどの機構を使用して実施される、プロセス間通信バス６０８を介して行われる。ＡＰＩスタブ６０４は、Ｃ、Ｃ＋＋、Ｊａｖａ、．ＮＥＴを含め、様々なプログラミング言語で利用可能である。一部の実例では、ＡＰＩ自体、複数の言語で利用できることが可能である。ＡＰＩは、様々なオペレーティング・システム・プラットフォーム上で実行され、プラットフォームの３つの例が、Ｗｉｎｄｏｗｓ（商標）、Ｌｉｎｕｘ（商標）、Ｓｏｌａｒｉｓ（商標）である。
【００７５】
ＡＰＩ通信エンジンは、メッセージング・トランスポート・レイヤ６１０などの論理レイヤ上に構築される。物理媒体インタフェース群と直接に対話するＭＡとは異なり、ＡＰＩは、ほとんどの実装において、オペレーティング・システムの上に位置し（Ｐ＆Ｍシステムの場合にそうであるように）、そのメッセージング・トランスポート層はＯＳを介して通信する。様々なタイプのチャネルをサポートするために、ＯＳは、さもなければ、デフォルトでＯＳによってサポートされない、各物理媒体に関する特定のドライバを要求する可能性がある。また、ＯＳは、ユーザが、特定の物理媒体カードを挿入することを要求することも可能である。例えば、ＤＣ（直接接続）またはＩｎｆｉｎｉｂａｎｄなどの物理媒体は、メッセージング・トランスポート・レイヤが、チャネルを介してメッセージを送信することができるようにするのに、特定のインタフェース・カード、および関連するＯＳドライバを要求する。
【００７６】
また、ＡＰＩにおけるメッセージング・レイヤ６１２は、ＭＡにおけるメッセージング・レイヤと多少、似通ってもいる。しかし、主な違いは、着信メッセージが、ＡＰＩとＭＡにおいて、それぞれ、異なるパスをたどることである。ＡＰＩでは、データ・メッセージは、アプリケーション配信ルーティング・エンジン６１４に送信され（スキーマ・バインディングを除き）、管理メッセージは、管理メッセージ・レイヤ６１６に送信される。アプリケーション配信エンジンは、チャネルをサブスクリプションにマップする代わりに、アプリケーション（６０６）をサブスクリプションにマップすること以外は、メッセージ・ルーティング・エンジン６１８と同様に振舞う。このため、着信メッセージが着信すると、アプリケーション配信ルーティング・エンジンは、すべてのサブスクライブするアプリケーションに関して調べ、次に、そのメッセージのコピー、またはそのメッセージへの参照を、それらのアプリケーションのすべてに送信する。
【００７７】
一部の実装では、アプリケーション配信ルーティング・エンジンは、レイト・スキーマ・バインディング・フィーチャを担う。前述したとおり、ネイティブ（例えば、Ｔｅｒｖｅｌａ（商標））メッセージング・プロトコルは、基礎をなすデータの構造と定義を含まない、生の、圧縮されたフォーマットで情報を提供する。その結果、メッセージング・システムは、システムの帯域幅利用率を有利に低減し、より大きいメッセージ量とスループットを可能にする。データ・メッセージが、ＡＰＩによって受信されると、ＡＰＩは、その生のデータを、ＡＰＩのスキーマにバインドして、アプリケーションが、情報にトランスペアレントにアクセスすることを可能にする。スキーマは、フィールド名、フィールドのタイプ、メッセージ本文におけるフィールドのオフセット位置の間のマッピングを提供することにより、メッセージの内容構造を定義する。したがって、アプリケーションは、ある特定のフィールド名を、メッセージにおけるそのフィールドの位置を知ることなしに、求めることができ、ＡＰＩは、オフセットを使用して、その情報を探し出し、アプリケーションに戻す。一実施形態では、スキーマは、アプリケーションがＭＡとの間でサブスクライブまたはパブリッシュすることを要求したときにＭＡによって提供される。
【００７８】
かなりの程度、発信メッセージは、ＭＡにおける場合と同一のアウトバウンド論理に従う。実際に、ＡＰＩは、ＭＡと同様に、プロトコル最適化サービス（ＰＯＳ）６２０を有することが可能である。しかし、パブリッシュ／サブスクライブ・ミドルウェア・システムは、ＭＡとＡＰＩ通信エンジンとの間でマスタ−スレーブ・ベースの構成で分散されるＰＯＳを用いて構成される。しかし、チャネル構成をいつ変更するかに関してそれ自体で判断するＭＡ内のＰＯＳと異なって、ＡＰＩ内のＰＯＳは、それがリンクされるＭＡ内のマスタＰＯＳのスレーブとして働く。マスタＰＯＳとスレーブＰＯＳとの両方が、システム・リソースとネットワーク・リソースの経時的な消費パターンを監視する。スレーブＰＯＳは、これらのリソース消費パターンのすべて、サブセット、または要約をマスタＰＯＳに通信し、これらのパターンに基づいて、マスタＰＯＳは、トランスポート・プロトコルを選択することによるものを含めて、メッセージをＡＰＩ通信エンジンにどのように配信するかを決定する。例えば、ユニキャスト、マルチキャスト、またはブロードキャストのメッセージ・トランスポート・プロトコルの中から選択されたトランスポート・プロトコルは、必ずしもその状況に適切ではない。したがって、ＭＡ上のＰＯＳは、チャネル構成を変更すると判断する時に、ＡＰＩにあるスレーブＰＯＳをリモートから制御する。
【００７９】
メッセージング・パブリッシュ／サブスクライブ・ミドルウェア・システムで役割を実行する際に、ＡＰＩは、アプリケーション要求を扱うためのシステム・リソースの利用率を最小にするという点で、アプリケーションにトランスペアレントであることが好ましい。１つの構成で、ＡＰＩは、ゼロ・コピー・メッセージ受信を実行すること（すなわち、ネットワークから受信されたメッセージのアプリケーション・メモリ空間へのコピーを省略すること）によって、メモリ・コピーの回数を最適化する。例えば、ＡＰＩ通信エンジンは、着信メッセージをＡＰＩ通信エンジン・メモリ空間に直接に書き込むために、ネットワーク・インタフェース・カードにバッファ（メモリ空間）を導入する。これらのメッセージは、共有メモリを介してアプリケーションからアクセス可能になる。同様に、ＡＰＩは、アプリケーション・メモリ空間からネットワークへ直接にゼロ・コピー・メッセージ送信を実行する。
【００８０】
もう１つの構成では、ＡＰＩは、メッセージ受信タスクとメッセージ送信タスクを実行するのに必要なＣＰＵ処理の量を減らす。例えば、あるメッセージをその時点で受信または送信するのではなく、ＡＰＩ通信エンジンは、バルク・メッセージ受信タスクとバルク・メッセージ送信タスクを実行し、これによって、ＣＰＵ処理サイクル数を減らす。そのようなバルク・メッセージ転送は、しばしば、メッセージ・キューイングを伴う。したがって、終端間待ち時間を最小にするために、バルク・メッセージ転送は、メッセージをキューイングされたままに保つ時間を、許容可能な待ち時間閾値未満に制限することを必要とする。
【００８１】
前述のトランスペアレンシを維持するために、ＡＰＩは、アプリケーションによってパブリッシュされたまたはサブスクライブされたメッセージを処理する。システム帯域幅利用率を減らし、これによってシステム・スループットを高めるために、メッセージ情報が、生フォーマットと圧縮フォーマットで通信される。したがって、ＡＰＩがデータ・メッセージを受信した時に、ＡＰＩは、生のデータをそのスキーマにバインドし、アプリケーションがその情報にトランスペアレントにアクセスすることを可能にする。スキーマは、フィールド名、フィールドのタイプと、メッセージ本文におけるフィールド・インデックスの間のマッピングを与えることによって、メッセージの内容構造を定義する。その結果、アプリケーションは、ある特定のフィールド名を、メッセージ内のフィールドの位置を知ることなしに、求めることができ、ＡＰＩは、フィールド・インデックスとそれに関連するオフセットを使用して、その情報を探し出し、アプリケーションに返す。ところで、帯域幅をより効率的に利用するために、アプリケーションは、トピックにサブスクライブし、メッセージ・ストリームから更新された情報だけを受信することを要求することが可能である。そのようなサブスクリプションの結果として、ＭＡは、新しいメッセージを前に配信されたメッセージと比較し、更新だけをアプリケーションにパブリッシュする。
【００８２】
もう１つの実装は、受信されたデータまたはパブリッシュされたデータを、サブスクライブするアプリケーションとＡＰＩとの間で事前に合意されたフォーマットで提示する能力を提供する。この内容の変換は、プレゼンテーション・エンジンによって実行され、アプリケーションによって与えられるデータ・プレゼンテーション・フォーマットに基づく。データ・プレゼンテーション・フォーマットは、基礎をなすデータ・スキーマとアプリケーション・データ・フォーマットとの間のマッピングと定義される。例えば、アプリケーションは、データをＸＭＬフォーマットでパブリッシュし、消費することが可能であり、ＡＰＩは、このＸＭＬフォーマットを、基礎をなすメッセージ・フォーマットとの間で変換する。
【００８３】
ＡＰＩは、さらに、リアルタイム・チャネル最適化のために設計される。具体的には、ＭＡとＡＰＩ通信エンジンとの間の通信は、１つまたは複数のサブスクリプションまたはパブリケーションに対応するメッセージをそれぞれがトランスポートする１つまたは複数のチャネルを介して実行される。ＭＡとＡＰＩ通信エンジンとの両方が、通信パスのそれぞれを常に監視し、使用可能なリソースを動的に最適化する。これは、データ・パブリケーション／サブスクリプションに関連する処理オーバーヘッドを最小にするために、ならびにパブリッシュするアプリケーションおよびサブスクライブするアプリケーションに関する必要なシステム・リソースおよび期待されるシステム・リソースを予約するために行われる。
【００８４】
１つの実装で、ＡＰＩ通信エンジンは、１つまたは複数のアプリケーションが使用可能システム・リソースを使い果たさないように保護するリアルタイム・チャネル・メッセージ・フロー制御フィーチャを可能にする。このメッセージ・フロー制御フィーチャは、サブスクライブされたＱｏＳ（サービス品質）によって支配される。例えば、最後の既知の値またはベスト・エフォートＱｏＳについて、しばしば、低い品質のより多くのデータよりも、良い品質のより少ないデータを処理することが、より重要である。データの品質が、例えばその年齢によって測定される場合に、最も最新の情報だけを処理することが、より良い可能性がある。さらに、キューがオーバーフローするのを待ち、古いデータを処理することと、最も最近のデータを捨てること、という重荷をアプリケーションに委ねるのではなく、ＡＰＩ通信エンジンは、チャネル・キューの現在の状態についてＭＡに通知する。
【００８５】
図７に、リアルタイム・メッセージ・フロー制御（ＭＦＣ）アルゴリズムの影響を示す。このアルゴリズムによれば、チャネル・キューのサイズは、閾値パラメータとして動作することができる。例えば、特定のチャネルを介して配信されるメッセージは、受信するアプライアンスの側のチャネル・キューに累積し、このチャネル・キューがそのサイズを増大させる時に、そのチャネルがおそらくは着信メッセージのフローについて行けなくなることなしには安全に超えられない高閾値に達する場合がある。チャネルがその最大容量に達する危険がある、この状況に近づいた時に、受信するメッセージング・アプライアンスは、チャネル・キューをオーバーランする前にＭＦＣをアクティブにすることが可能である。ＭＦＣは、キューが縮小し、そのサイズが低閾値未満になる時に、オフにされる。高閾値と低閾値との間の差は、ＭＦＣが、それがオフにされるキュー・サイズ値より大きいキュー・サイズ値でオンにされる、このいわゆる履歴挙動を作るのに十分になるようにセットされる。この閾値差は、そうでなければキュー・サイズが高閾値前後でふらつく時に発生するはずのメッセージ・フロー制御の頻繁なオン−オフ発振を防ぐ。したがって、メッセージング・レシーバ側でのキュー・オーバーランを防ぐために、着信メッセージのレートを、このレートを最大チャネル容量未満に保つリアルタイム動的ＭＦＣを用いて抑制することができる。
【００８６】
チャネル・キューがその容量に近い時にメッセージが捨てられる履歴ベースのＭＦＣアルゴリズムに対する代替案として、リアルタイム動的ＭＦＣは、データをブレンドするか、ある融合（ｃｏｎｆｌａｔｉｏｎ）アルゴリズムをサブスクリプション・キューに適用することが可能である。しかし、このオペレーションは、追加のメッセージ変換を必要とする場合があるので、ＭＡは、高速転送パスに留まるのではなく、低速転送パスにフォール・バックすることが可能である。これは、メッセージ変換がメッセージング・スループットに悪影響を与えるのを防ぐ。追加のメッセージ変換は、プロトコル変換エンジンに似たプロセッサによって実行される。そのようなプロセッサの例は、ＮＰＵ（ネットワーク処理ユニット）、セマンティック・プロセッサ、ＭＡ上の別々のマイクロエンジン、類似物を含む。
【００８７】
より高い効率のために、リアルタイム融合またはサブスクリプション・レベル・メッセージ処理を、送信者と受信者との間で分散させることが可能である。例えば、サブスクリプション・レベル・メッセージ処理が、１つのサブスクライバだけによって要求される場合には、それを送信者側で実行するのではなく、下流の受信者側に押しやることが意味をなす。しかし、データの複数のコンシューマが、同一のサブスクリプション・レベル・メッセージ処理を要求している場合には、それを上流の送信者側で実行することが意味をなす。あるチャネルの送信者側と受信者側との間で作業負荷を分散することの目的は、使用可能な組み合わされた処理リソースを最適に使用することである。
【００８８】
チャネルが、複数のメッセージを単一フレームにパックする時には、そのチャネルは、メッセージ待ち時間を最大の許容できる待ち時間未満に保ち、ある処理リソースを開放することによって受信側のストレスを緩和することが可能である。多数の小さいフレームを処理することよりも、少数の大きいフレームを受信することが、時としてより効率的である。これは、ＣＰＵ、メモリ、ＮＩＣを含む総称的コンピュータ・ハードウェア構成要素を使用して通常のＯＳ上で実行することのできるＡＰＩに特にあてはまる。通常のＮＩＣは、受信したフレームごとにＯＳ割込みを生成するように設計され、このＯＳ割込みは、ＡＰＩがサブスクライブするアプリケーションにメッセージを配信するのに使用可能なアプリケーション・レベル処理時間を減らす。
【００８９】
図７にさらに示されているように、チャネル・キューの現在のレベルが最大閾値と交差する場合に、ＭＡは、この特定のチャネルでのメッセージ・レートをスロットリングして、ＡＰＩ通信エンジンに対する負荷を減らし、アプリケーションが定常状態に戻ることを可能にする。このスロットリング・プロセス中に、サブスクライブされているサービス品質に応じて、最も最近のメッセージが、古いメッセージより高い優先準位を与えられる。キューが通常の負荷レベルに戻った場合に、ＡＰＩは、チャネル・メッセージ・フロー制御をディスエーブルするようにＭＡに通知する。
【００９０】
前述の実装の１つのバリエーションでは、メッセージ・フロー制御フィーチャは、メッセージ・ルーティング・パス（アプリケーションへ／からの）のＡＰＩ側で実施される。メッセージを、サブスクライブするアプリケーションに配信する必要がある時には、必ず、ＡＰＩ通信エンジンが、サブスクライブされているサービス品質によって許容される場合に、続くより最新のメッセージを優先してメッセージを捨てる判断を行うことが可能である。
【００９１】
ＡＰＩ内またはＭＡ内のどちらの形であれ、メッセージ・フロー制御は、異なるスロットリング・ポリシを適用することが可能であり、この場合に、新しいメッセージを優先して古いメッセージを捨てるのではなく、ＡＰＩ通信エンジンまたはこのＡＰＩ通信エンジンに接続されたＭＡが、データ・ブレンディングとも称するサブスクリプション・ベースのデータ融合を実行することが可能である。言い換えると、捨てられるデータは、完全に失われるのではなく、最も最近のデータとブレンドされる。一実施形態で、そのようなメッセージ・フロー制御スロットリング・ポリシは、所与のＡＰＩとそのＭＡとの間のすべてのチャネルについてグローバルに決められ、融合されたサービス品質としてＰ＆Ｍシステムから構成される。このＱｏＳは、融合されたＱｏＳにサブスクライブするすべてのアプリケーションに適用される。もう１つの実施形態では、このスロットリング・ポリシを、アプリケーションからのＡＰＩ関数呼出しを介してユーザ定義されるものとし、ある柔軟性を実現することが可能である。その特定のケースでは、ＡＰＩ通信エンジンは、ＭＡとのチャネルを確立する時にスロットリング・ポリシを通信する。チャネル構成パラメータは、ＡＰＩ通信エンジンとＭＡとの間で、そのフェーズ中にネゴシエートされる。
【００９２】
このユーザ定義のスロットリング・ポリシが、メッセージ・レベルではなくサブスクリプション・レベルで実施されるときに、アプリケーションが、所与のトピックにサブスクライブする時にポリシを定義することが可能であることに留意されたい。サブスクリプション・ベースのスロットリング・ポリシが、次に、この特定のサブスクリプションのチャネル構成に追加される。
【００９３】
ＡＰＩ通信エンジンは、値追加メッセージ処理をもたらすように構成されることが可能であり、ＡＰＩが接続されるＭＡも同様である。値追加メッセージ処理に関して、アプリケーションは、所与のサブスクリプションまたはサブスクリプションのセットについてインライン値追加メッセージ処理サービスにサブスクライブすることが可能である。このサービスは、サブスクライブされたメッセージ・ストリームに対して実行されるか、これに適用される。さらに、アプリケーションは、メッセージ内の参照するフィールドについて高水準メッセージ処理言語を使用して、ある擬似コードを登録することが可能である（例えば、ＮＥＷＦＩＥＬＤ＝（ＦＩＥＬＤ（Ｎ）＋ＦＩＥＬＤ（Ｍ））／２、これは、フィールドＮとＭの算術平均と等しい値を有する新しいフィールドの、メッセージの末尾での作成を定義する）。これらの値追加メッセージ処理サービスは、新しいメッセージが処理される時に、サービス固有の状態が維持され、更新されることを必要とする場合がある。これらの状態は、フィールドが定義されるのと同一の形で定義され、擬似コード内で再利用される（例えば、ＳＴＡＴＥ（０）＋＝ＦＩＥＬＤ（Ｎ）、これは、状態番号０が、ＦＩＥＬＤ（Ｎ）の累積合計であることを意味する）。そのようなサービスは、システム内でデフォルトで定義されることが可能であり、アプリケーションは、特定のトピックにサブスクライブする時にそれらをイネーブルすることだけを必要とし、あるいは、そのようなサービスは、ユーザ定義されることが可能である。どちらの形であれ、そのようなインライン値追加メッセージ処理サービスは、ＡＰＩ通信エンジンまたはそのＡＰＩに接続されたＭＡによって実行されることが可能である。
【００９４】
インライン値追加メッセージ処理サービスに似て、内容ベースのアクセス制御リスト（ＡＬＣ）を、実装に応じて、ＡＰＩ通信エンジンまたはＭＡもしくはその両方で展開することができる。例えば、株売買人が、ＩＢＭ社の建値を伴うメッセージに、ＩＢＭ価格が５０ドルを超える時に限って関心を持ち、それ以外の場合には、その値未満の建値を有するすべてのメッセージを捨てることを好むと仮定する。これに関して、ＡＰＩ（またはＭＡ）は、さらに、内容ベースＡＣＬを定義することが可能であり、アプリケーションは、サブスクリプション・ベースのＡＣＬを定義する。サブスクリプション・ベースのＡＣＬは、メッセージ内のフィールドを使用して表されたＡＣＬ条件と、ＲＥＪＥＣＴ（拒否）、ＡＣＣＥＰＴ（受入）、ＬＯＧ（ログ）、または別の適切な形で表されたＡＣＬアクションとの組合せとすることが可能である。そのようなＡＣＬの例が、（ＦＩＥＬＤ（ｎ）＜ＶＡＬＵＥ，ＡＣＣＥＰＴ，ＲＥＪＥＣＴ｜ＬＯＧ）である。
【００９５】
効率をさらに改善するために、ＡＰＩ通信エンジンは、メッセージ処理の一部をインテリジェント・メッセージング・ネットワーク・インタフェース・カード（ＮＩＣ）にオフロードするように構成される。このインテリジェント・メッセージングＮＩＣは、ネットワーク・スタック全体をハードウェアで実行することによってネットワーキングＩ／Ｏをバイパスするため、Ｉ／Ｏカードから直接にアプリケーション・メモリ空間へのＤＭＡを実行するため、さらには再送と一時的キャッシングを含むメッセージング信頼性を管理するために設けられる。インテリジェント・メッセージングＮＩＣは、さらに、上で説明した、メッセージ・フロー制御、値追加メッセージ処理、内容ベースＡＣＬを含むチャネル管理を実行することが可能である。そのようなインテリジェント・メッセージングＮＩＣの２つの実装を、それぞれ図８ａ、８ｂに示す。図８ａは、メモリ相互接続カード８０８を示し、図８ｂは、メッセージング・オフロード・カード８１０を示す。両方の実装が、ホストＣＰＵ  ８０２、ホスト・メモリ８０４、およびＰＣＩホスト・ブリッジ８０６を含む。
【００９６】
周知のとおり、信頼性、利用可能性、整合性が、企業オペレーションにおいて、必要名ことが多い。その目的で、パブリッシュ／サブスクライブ・ミドルウェア・システムは、フォールト・トレラント・システムとして展開される構成要素のいくつかを使用して、フォールト・トレランスのために設計される。例えば、ＭＡは、第１のＭＡが、１次ＭＡと呼ばれ、第２のＭＡが、２次ＭＡまたはフォールト・トレラントＭＡ（ＦＴ  ＭＡ）と呼ばれる、フォールト・トレラントＭＡペアとして展開される。やはり、ストア・アンド・フォワード・オペレーションのために、ＣＥ（キャッシュ・エンジン）が、１次コア／エッジＭＡまたは２次コア／エッジＭＡに接続される。１次ＭＡまたは２次ＭＡは、ＣＥに対する能動的な接続を有するときに、ルーティングされるメッセージのすべてまたはサブセットをそのＣＥに転送し、そのＣＥは、それらのメッセージを、保存のためにストレージ領域に書き込む。所定の期間にわたって、これらのメッセージは、要求時の再送に利用可能である。
【００９７】
フォールト・トレラント設計の例を、図１０に示す。この例では、システムは、セッション・ベースのフォールト・トレラントである。もう１つの可能な構成は、完全なフェイルオーバであるが、この実例では、我々は、セッション・ベースのフォールト・トレラントを選択した。セッションは、２つのＭＡの間または１つのＭＡとＡＰＩとの間の通信と定義される。セッションは、２つのＭＡの間、または１つのＭＡとＡＰＩ（例えば、９１０）との間の通信を包含し、能動的または受動的であることが可能である。障害が生じた場合に、ＭＡまたはＡＰＩは、１次ＭＡ９０６から２次ＭＡ９０８にセッションを切り換えることを決定することができる。障害は、セッションが、接続および／またはＣＰＵ、メモリ、インタフェースなどのシステム・リソースの障害を経験すると、生じる。接続問題は、基礎をなすチャネルとして定義される。例えば、ＩＰベースのチャネルは、時とともに、損失、遅延、および／またはジッタが異常に増加すると、接続問題を経験する。メモリ・ベースのチャネルに関して、接続問題は、メモリ・アドレス衝突などとして定義される。ＭＡまたはＡＰＩは、セッションがある接続問題および／またはシステム・リソース問題を経験する時に、必ず、このセッションを１次ＭＡから２次ＭＡに切り換えると判断する。
【００９８】
一実施形態では、１次ＭＡと２次ＭＡは、何らかのチャネル・ベースの論理を使用して、論理チャネル・アドレスを物理チャネル・アドレスにマップする単一のＭＡと見なされる。例えば、ＩＰベースのチャネルに関して、ＡＰＩまたはＭＡは、ＭＡ論理アドレスのＡＰＲキャッシュ・エントリを、２次ＭＡの物理ＭＡＣアドレスをポイントするように更新することにより、問題のあるセッションを、２次ＭＡに向けてリダイレクトすることができる。
【００９９】
全体的に、セッション・ベースのフォールト・トレラント設計は、すべてのセッションの１つだけに、またはサブセットに問題が生じた場合に、すべてのセッションには影響を与えないという利点を有する。つまり、あるセッションが、何らかのパフォーマンス問題を経験すると、そのセッションは、１次ＭＡ（例えば、９０６）から２次ＦＴ（フォールト・トレラント）ＭＡ９０８に、その１次ＭＡ９０６に関連する、その他のセッションに影響を与えることなしに、移される。したがって、例えば、ＡＰＩ1〜4は、１次ＭＡ９０２に対して（能動的なＭＡとして）、依然として、それぞれの能動的なセッションを有していることが示されているのに対して、ＡＰＩ5は、ＦＴ  ＭＡ９０８に対して、能動的なセッションを有する。
【０１００】
めいめいのＭＡと通信する際に、ＡＰＩは、１つまたは複数の日用品のＮＩＣまたはインテリジェント・メッセージング・オフロードＮＩＣを介してインタフェースされた物理媒体を使用する。図１０に、ＡＰＩとＭＡとの間の通信向けのインタフェースを示す。
【０１０１】
要するに、本発明は、メッセージングの新たなアプローチを提供し、より具体的には、インテリジェント・メッセージング・アプリケーション・プログラミング・インタフェースを有する新しいパブリッシュ／サブスクライブ・ミドルウェア・システムを提供する。本発明を、本発明の、いくつかの好ましいバージョンに関連して、相当に詳細に説明してきたが、他のバージョンも可能である。したがって、添付の特許請求の範囲の趣旨および範囲は、本明細書に含まれる好ましいバージョンの説明に限定されてはならない。
【図面の簡単な説明】
【０１０２】
【図１】本発明の諸原理による終端間ミドルウェア・アーキテクチャを示す図である。
【図１ａ】オーバーレイ・ネットワークを示す図である。
【図２】本発明の諸原理による終端間ミドルウェア・アーキテクチャで実施される企業インフラストラクチャを示す図である。
【図２ａ】ネットワーク・バックボーン・ディスインターメディエーションを作成するＭＡ群（メッセージアプライアンス群）を有する、企業インフラストラクチャの物理的展開を示す図である。
【図３】チャネル・ベースのメッセージング・システム・アーキテクチャを示す図である。
【図４ａ】１つの可能なトピック・ベースのメッセージ・フォーマットを示す図である。
【図４ｂ】１つの可能なトピック・ベースのメッセージ・フォーマットを示す図である。
【図５】トピック・ベースのメッセージ・ルーティングおよびルーティング・テーブルを示す図である。
【図６】インテリジェント・メッセージング・アプリケーション・プログラミング・インタフェース（ＡＰＩ）を示す図である。
【図７】適応メッセージ・フロー制御の影響を示す図である。
【図８】インテリジェント・ネットワーク・インタフェース・カード（ＮＩＣ）構成を示す図である。
【図９】セッション・ベースのフォールト・トレラント設計を示す図である。
【図１０ａ】メッセージング・アプライアンス（ＭＡ）からＡＰＩへのインタフェースを示す図である。
【図１０ｂ】メッセージング・アプライアンス（ＭＡ）からＡＰＩへのインタフェースを示す図である。
【図１】
2008537612.tif 000002
【図１ａ】
2008537612.tif 000003
【図２】
2008537612.tif 000004
【図２ａ】
2008537612.tif 000005
【図３】
2008537612.tif 000006
【図４ａ】
2008537612.tif 000007
【図４ｂ】
2008537612.tif 000008
【図５】
2008537612.tif 000009
【図６】
2008537612.tif 000010
【図７】
2008537612.tif 000011
【図８】
2008537612.tif 000012
【図９】
2008537612.tif 000013
【図１０ａ】
2008537612.tif 000014
【図１０ｂ】
2008537612.tif 000015
【国際調査報告】
2008537612.tif 000016