(57)【要約】  より低減された待ち時間、およびパフォーマンスのネックで大きいメッセージ量を処理するメッセージ・パブリッシュ／サブスクライブ・システムが、要求される。本発明によって提案される終端間ミドルウェア・アーキテクチャは、とりわけ、近隣ベースのルーティングで中間ホップを減らすこと、効率的なネイティブ−外部プロトコル変換および外部−ネイティブ・プロトコル変換を導入すること、待ち時間を含め、システム・パフォーマンスをリアルタイムで監視すること、トピック・ベースのメッセージ通信、およびチャネル・ベースのメッセージ通信を使用すること、ならびにシステム相互接続構成およびメッセージ伝送プロトコルを動的に最適化することにより、大量の、待ち時間の少ないメッセージング向けに設計される。
2008527847.tif 000002
【特許請求の範囲】
【請求項１】
メッセージを受信し、ルーティングするように構成された１つまたは複数のメッセージング・アプライアンスと、
相互接続と、
前記相互接続を介してリンクされ、各メッセージング・アプライアンスと管理メッセージを交換するように構成されたプロビジョニング−マネージメント・システムとを含むミドルウェア・アーキテクチャとを有するシステムであって、
各メッセージング・アプライアンスは、さらに、メッセージ伝送プロトコルとメッセージ・ルーティング・パスをリアルタイムで動的に選択することにより、メッセージのルーティングを実行するように構成されるシステム。
【請求項２】
前記プロビジョニング−マネージメント・システムは、システム構成を含み、健全性とパフォーマンスの監視と報告を含む、前記管理メッセージに関連する諸機能を実行するように構成された請求項１に記載のシステム。
【請求項３】
前記プロビジョニング−マネージメント・システムは、１つまたは複数のデータ・メッセージ・トピックに対するコンシューマと外部データ宛先のサブスクリプション、および管理メッセージ・トピックに対するメッセージング・アプライアンスのサブスクリプションを含む、サブスクリプションを管理するように構成された請求項１に記載のシステム。
【請求項４】
各メッセージング・アプライアンスは、エッジ・メッセージング・アプライアンスまたはコア・メッセージング・アプライアンスとして構成された請求項１に記載のシステム。
【請求項５】
各エッジ・メッセージング・アプライアンスは、着信メッセージを、外部プロトコルからネイティブ・プロトコルに変換するため、およびルーティングされたメッセージを、前記ネイティブ・プロトコルから前記外部プロトコルに変換するためのメッセージ変換エンジンにリンクされた請求項４に記載のシステム。
【請求項６】
前記メッセージ伝送プロトコルは、ユニキャスト・プロトコル、マルチキャスト・プロトコル、またはブロードキャスト・プロトコルのいずれかであるように選択される請求項１に記載のシステム。
【請求項７】
１つまたは複数のアプリケーションと、前記メッセージング・アプライアンスのそれぞれとの間でインタフェースをとるように構成された１つまたは複数のアプリケーション・プログラミング・インタフェースをさらに含む請求項１に記載のシステム。
【請求項８】
前記それぞれのメッセージング・アプライアンスと前記１つまたは複数のアプリケーション・プログラミング・インタフェースは、１つまたは複数のメッセージを単一のフレームに組み込むことにより、互いに通信するように動作する請求項７に記載のシステム。
【請求項９】
前記アプリケーションのそれぞれは、登録要求とサブスクリプション要求を含む要求を、前記メッセージング・アプライアンスのそれぞれに送信するように構成され、前記プロビジョニング−マネージメント・システムは、それぞれのメッセージング・アプライアンスが、さらに、それぞれのメッセージング・アプライアンスに対して登録しようと、またはサブスクライブしようと試みているアプリケーションが、そうする資格を有するかどうかを確認して、前記プロビジョニング−マネージメント・システムに報告する、デジタル権利管理を扱うように構成された請求項７に記載のシステム。
【請求項１０】
前記アプリケーション・プログラミング・インタフェースのそれぞれは、前記メッセージング・アプライアンスのそれぞれに論理的にリンクされ、前記メッセージング・アプライアンスの前記それぞれは、トピック・ベースのサブスクリプションを介して、前記アプリケーション・プログラミング・インタフェースに登録されている請求項７に記載のシステム。
【請求項１１】
前記メッセージング・アプライアンスは、前記アプリケーション・プログラミング・インタフェースが登録する、１つまたは複数のコア・メッセージング・アプライアンスを含む請求項７に記載のシステム。
【請求項１２】
前記トピック・ベースのサブスクリプションはそれぞれ、サブスクリプション要求を介して確立され、単一のサブスクリプション要求は、関連するトピックのグループに対するサブスクリプションを確立することができる請求項１０に記載のシステム。
【請求項１３】
前記相互接続は、前記１つまたは複数のメッセージング・アプライアンスと前記プロビジョニング−マネージメント・システムが展開される相互接続ネットワークであり、かつ任意の数のルータ、スイッチ、サブネットを有して構成された相互接続ネットワークである請求項１に記載のシステム。
【請求項１４】
前記相互接続は、チャネル・ベースの、ファブリックにこだわらない物理媒体である請求項１に記載のシステム。
【請求項１５】
前記１つまたは複数のメッセージング・アプライアンス、前記プロビジョニング−マネージメント・システム、前記相互接続は、トランスポート・ロジックを組み込む請求項１に記載のシステム。
【請求項１６】
前記トランスポート・ロジックとは独立のネイティブ・プロトコル・フォーマットでメッセージが通信される、トランスポート・トランスペアレントなチャネル・ベースのメッセージング向けに構成された請求項１５に記載のシステム。
【請求項１７】
１つまたは複数の外部送信元と、１つまたは複数の外部宛先とをさらに含む請求項１に記載のシステムであって、
前記メッセージング・アプライアンスは、プロトコル変換エンジンにそれぞれが関連し、外部プロトコルとネイティブ・プロトコルの間でメッセージを変換する１つまたは複数のエッジ・メッセージング・アプライアンスと、前記ネイティブ・プロトコルでメッセージの通信をそれぞれが行う、１つまたは複数のコア・メッセージング・アプライアンスとを含み、前記外部送信元と前記外部宛先は、前記エッジ・メッセージング・アプライアンスと通信し、前記エッジ・メッセージング・アプライアンスは、近隣ベースのメッセージ・ルーティングを使用して、前記コア・メッセージング・アプライアンスと通信する、システム。
【請求項１８】
各エッジ・メッセージング・アプライアンスは、着信メッセージを、ネイティブ・プロトコル・コンシューマと外部プロトコル・コンシューマの両方に同時にルーティングするように動作する請求項１７に記載のシステム。
【請求項１９】
前記メッセージは、そのメッセージがシステムに入る際に互いに分離され、前記メッセージが、システムを離れる際に、組み合わされるスキーマとペイロードで構築される請求項１に記載のシステム。
【請求項２０】
前記プロビジョニング−マネージメント・システムは、デジタル権利管理を含む名前空間管理機能を実行する請求項１に記載のシステム。
【請求項２１】
前記名前空間管理で、ある特定の名前空間に関連するトピックにサブスクライブしているコンシューマまたは外部宛先は、そのようなトピックで識別されたメッセージをパブリッシュし、サブスクライブする資格を有する請求項２０に記載のシステム。
【請求項２２】
各メッセージング・アプライアンスは、各メッセージング・アプライアンスが、そのアプライアンスのチャネルの１つを介して、そのチャネルを介して伝送されるメッセージのすべて、またはサブセットにサブスクライブしている近隣に、メッセージをルーティングするように構成される近隣ベースであり、かつ、各メッセージング・アプライアンスが、メッセージング・アプライアンス間におけるメッセージのルーティングを有するルーティング・テーブルを有し、各メッセージング・アプライアンスは、前記メッセージのサブセットだけにサブスクライブする近隣における破棄率を低減するために、そのアプライアンスのサブスクライブとチャネルの間のマッピングを最適化するようにさらに構成された請求項１に記載のシステム。
【請求項２３】
前記ルーティング・テーブルは、複数の構造を有し、それらの構造の２つは、ツリー構造および動的マップ構造である請求項２２に記載のシステム。
【請求項２４】
前記メッセージと前記管理メッセージがトピック・ベースのフォーマットを有し、各メッセージはヘッダとペイロードとを有し、そのヘッダが、送信元名前空間ＩＤフィールドと宛先名前空間ＩＤフィールドに加えて、トピック・フィールドを含むする請求項１に記載のシステム。
【請求項２５】
前記トピック・フィールドは、可変長ストリングまたはキーを含み、そのキーが唯一の値を有し、そのキーに対して、前記プロビジョニング−マネージメント・システムが、さらに、それぞれのそのようなキーと、それぞれのトピックとの間のマッピングを保持するためのデータベースを有するように構成され、前記プロビジョニング−マネージメント・システムは、そのマッピングのあらゆる変更について、前記メッセージング・アプライアンスのそれぞれを更新するようにさらに構成された請求項２４に記載のシステム。
【請求項２６】
前記メッセージは、サブスクリプション・メッセージを、任意のトピック・サブストリングと一致させることを、そのようなトピックと、前記サブスクリプション・メッセージとが、同一の数のトピック・サブストリングを有するという条件付きで、行うための、任意の数のワイルドカード・キャラクタを有する可変長ストリングを有するトピック・フィールドを有する前記サブスクリプション・メッセージを含む請求項１に記載のシステム。
【請求項２７】
前記メッセージ伝送プロトコルと前記メッセージ・ルーティング・パスの動的選択は、システム・トポロジ、前記プロビジョニング−マネージメント・システムからの健全性レポートとパフォーマンス・レポートに基づき、動的リソース割り当て、動的チャネル作成、動的チャネル選択、または以上の任意の組合せが関与する請求項１に記載のシステム。
【請求項２８】
地域の境界、国の境界、または大陸の境界を越える境界を有し、各地域、各国、または各大陸に１つまたは複数のサブシステムを有する請求項１に記載のシステムであって、
前記サブシステムは、ネットワーキング・インフラストラクチャを介してリンクされ、各サブシステムは、プロビジョニング−マネージメント・システム、相互接続、１つまたは複数のメッセージング・アプライアンスを含む、システム。
【請求項２９】
前記プロビジョニング−マネージメント・システムは、前記メッセージング・アプライアンスの１つに組み込まれる、またはスタンドアロンのアプライアンスとして実装される請求項１に記載のシステム。
【請求項３０】
各メッセージング・アプライアンスは、
物理インタフェース管理機能ブロックにリンクされたネットワーク管理スタックと、
ネットワーク管理内部通信論理バスを介して前記ネットワーク管理スタックにともにリンクされているシステム管理サービス機能ブロックとタイムスタンピング・サービス機能ブロックとを含むサービス・ブロックと、
メッセージング内部通信論理バスを介して前記サービス・ブロックにともにリンクされているメッセージング・トランスポート・レイヤと通信しているネイティブ・メッセージ・レイヤとを含む請求項１に記載のシステム。
【請求項３１】
前記ネイティブ・メッセージ・レイヤは、管理メッセージ・レイヤと、メッセージ・ルーティング・エンジンと、メッセージ送受信ロジックと、マスタ・プロトコル最適化サービスとを含む請求項３０に記載のシステム。
【請求項３２】
前記メッセージング・トランスポート・レイヤがチャネル管理を含み、メッセージ・ルーティング・パスの動的選択が、チャネルの選択と作成の１つまたは複数を含む請求項３０に記載のシステム。
【請求項３３】
各チャネルは、ネットワーク・ベースの伝送プロトコル向け、ノード・ベースの伝送プロトコル向け、またはメモリ・ベースの伝送プロトコル向けに構成され、ファブリックにこだわらない物理媒体に対する物理インタフェースに関連付けられた請求項３２に記載のシステム。
【請求項３４】
前記物理媒体は、イーサネット向け、メモリ・ベースの直接接続向け、またはＩｎｆｉｎｉｂａｎｄ向けに構成された請求項３３に記載のシステム。
【請求項３５】
前記プロビジョニング−マネージメント・システムは、構成機能ブロックと監視機能ブロックにリンクされたメッセージ・トランスポート・レイヤとネイティブ・メッセージ・レイヤとを含み、前記監視機能ブロックは、プロセス間通信バスを介して、構成管理機能ブロック、リアルタイム監視機能ブロック、履歴トレンディング機能ブロック、アプリケーション・ビジネス報告機能ブロックを含む管理ブロックに接続された請求項１に記載のシステム。
【請求項３６】
前記プロビジョニング−マネージメント・システムは、
一方の側で、前記監視機能ブロックに接続され、他方の側で、前記オペレーティング・システムのネットワーク・スタックに接続されたネットワーク管理サービスと、
前記管理ブロックに接続されたユーザ・インタフェースのいずれか、または両方をさらに含む請求項３５に記載のシステム。
【請求項３７】
前記相互接続は、前記メッセージング・アプライアンスが、前記プロビジョニング−マネージメント・システムと通信するトランスポート・チャネルと前記物理媒体を含む請求項３３に記載のシステム。
【請求項３８】
メッセージ・データ・ストア・アンド・フォワード機能を含め、サービス品質機能を提供するためにそれぞれのメッセージング・アプライアンスに動作上、それぞれ接続された１つまたは複数のキャッシング・エンジンをさらに含む請求項１に記載のシステム。
【請求項３９】
各キャッシング・エンジンは、メッセージ・トランスポート・レイヤに接続されたネイティブ・メッセージ・レイヤに接続されたキャッシング・レイヤを含み、前記キャッシング・レイヤは、ストレージ、ストレージ・サービス、索引付けサービスを含む請求項３８に記載のシステム。
【請求項４０】
前記メッセージング・アプライアンスの１つまたは複数は、そのようなメッセージング・アプライアンスに登録されたアプリケーション・プログラミング・インタフェースを介して、アプリケーションに動作上、接続され、前記アプリケーションと前記メッセージング・アプライアンスの間でメッセージを伝送する請求項１に記載のシステム。
【請求項４１】
各メッセージング・アプライアンスはマスタ・プロトコル最適化サービスを含み、各アプリケーション・プログラミング・インタフェースは、そのアプリケーション・プログラミング・インタフェースのそれぞれのマスタ・プロトコル最適化サービスに応答するスレーブ・プロトコル最適化サービスを含む請求項４０に記載のシステム。
【請求項４２】
各アプリケーション・プログラミング・インタフェースは、通信エンジンと、その通信エンジンにリンクされた１つまたは複数のアプリケーション・スタブを含む請求項４０に記載のシステム。
【請求項４３】
前記通信エンジンがデーモンである請求項４２に記載のシステム。
【請求項４４】
各アプリケーション・プログラミング・インタフェースは、前記クライアント・アプリケーション・ホストにおけるオペレーティング・システムの上に展開される請求項４０に記載のシステム。
【請求項４５】
各アプリケーション・プログラミング・インタフェースは、
前記アプリケーションにメッセージを伝送するためのアプリケーション配信エンジンと、
管理メッセージを扱うための管理メッセージ・レイヤとを含む請求項４０に記載のシステム。
【請求項４６】
前記メッセージング・アプライアンスのそれぞれ、および前記プロビジョニング−マネージメント・システムは、フォールト・トレランス向けに構成された請求項１に記載のシステム。
【請求項４７】
前記メッセージング・アプライアンスはフォールト・トレラント・ペアで構成され、各ペアは、１次メッセージング・アプライアンスと２次メッセージング・アプライアンスとを含み、前記２次メッセージング・アプライアンスが、前記１次メッセージング・アプライアンスからのセッションを引き継ぐことを、そのようなセッションの障害が生じた際、前記１次メッセージング・アプライアンス上の他の能動的なセッションを妨げずに行う請求項４６に記載のシステム。
【請求項４８】
１つまたは複数の名前空間ドメインと、
複数の空間ドメインが存在する場合、前記名前空間ドメインの間で接続を行うためのドメイン相互接続媒体とを含む
パブリッシュ／サブスクライブ・ミドルウェア・アーキテクチャを有するシステムであって、
各名前空間ドメインは、
メッセージを受信し、ルーティングするように構成された１つまたは複数のメッセージング・アプライアンスと、
相互接続と、
前記相互接続を介してリンクされ、各メッセージング・アプライアンスと管理メッセージを交換するように構成されたプロビジョニング−マネージメント・システムとを含み、
各メッセージング・アプライアンスは、メッセージ伝送プロトコルとメッセージ・ルーティング・パスとを動的に選択することにより、メッセージのルーティングを実行するようにさらに構成される、システム。
【請求項４９】
市場データ・メッセージを受信して、ルーティングするための１つまたは複数のメッセージング・アプライアンスを有する市場データ配信インフラストラクチャと、
トランザクション注文メッセージを受信して、ルーティングするための１つまたは複数のメッセージング・アプライアンスを有する市場注文ルーティング・インフラストラクチャと、
前記市場データ配信インフラストラクチャと前記市場注文ルーティング・インフラストラクチャとにそれぞれ通信リンクしている中間インフラストラクチャと
を含むパブリッシュ／サブスクライブ・ミドルウェア・アーキテクチャを有する企業システムであって、
前記中間インフラストラクチャが、
前記市場データ・メッセージと前記トランザクション注文メッセージを受信して、ルーティングするように構成された１つまたは複数のメッセージング・アプライアンスと、
相互接続と、
前記相互接続を介してリンクされ、前記市場データ配信インフラストラクチャと、前記市場注文ルーティング・インフラストラクチャにおける前記メッセージング・アプライアンスを含め、各メッセージング・アプライアンスと管理メッセージを交換するように構成されたプロビジョニング−マネージメント・システムとを含み、
前記メッセージング・アプライアンスのそれぞれが、さらに、メッセージ伝送プロトコルとメッセージ・ルーティング・パスとを動的に選択することにより、そのメッセージング・アプライアンスが受信するメッセージのルーティングを実行するように構成される、企業システム。
【請求項５０】
前記市場データ・メッセージをパブリッシュするための市場データ送信元と、
前記市場データ・メッセージを受信するための、および前記トランザクション注文メッセージをパブリッシュするための、１つまたは複数のアプリケーションを含む市場データ・コンシューマとをさらに含む請求項４９に記載の企業システムであって、
前記中間インフラストラクチャは、前記アプリケーションのそれぞれと、アプリケーション・プログラミング・インタフェースが登録されている前記中間インフラストラクチャにおけるメッセージング・アプライアンスの１つとの間に前記アプリケーション・プログラミング・インタフェースを含み、前記アプリケーション・プログラミング・インタフェースは、前記アプリケーションに前記市場データ・メッセージを伝送し、前記アプリケーションから前記トランザクション注文メッセージを伝送するように動作する、企業システム。
【請求項５１】
プロトコル変換エンジンをさらに含み、前記市場データ配信インフラストラクチャと前記市場注文ルーティング・インフラストラクチャにおけるメッセージング・アプライアンスがエッジ・メッセージング・アプライアンスとして構成され、かつ、前記中間インフラストラクチャにおけるメッセージング・アプライアンスがコア・メッセージング・アプライアンスとして構成された請求項４９に記載の企業システムであって、
各エッジ・メッセージング・アプライアンスは、そのエッジ・メッセージング・アプライアンスのそれぞれのプロトコル変換エンジンを使用して、外部プロトコルとネイティブ・プロトコルの間でメッセージを変換し、各コア・メッセージング・アプライアンスは、前記ネイティブ・プロトコルでメッセージを扱うように構成された、企業システム。
【請求項５２】
前記メッセージング・アプライアンスは、ネットワーク・ディスインターメディエーションをもたらすように相互接続された請求項４９に記載のシステム。
【請求項５３】
前記メッセージング・アプライアンスの１つまたは複数は、スイッチング・デバイス内、またはルーティング・デバイス内の組み込まれた構成要素である請求項４９に記載のシステム。
【請求項５４】
パブリッシュ／サブスクライブ・ミドルウェア・アーキテクチャを有するシステムにおいてメッセージをルーティングする方法であって、
１つまたは複数のメッセージング・アプライアンスを有するメッセージング・ファブリックを提供し、構成するステップと、
前記メッセージング・アプライアンスの特定の１つにおいて、リアルタイムで、メッセージ伝送プロトコルとメッセージ・ルーティング・パスとを動的に選択するステップと、
前記特定のメッセージング・アプライアンスから宛先まで少なくとも１つのメッセージをルーティングするステップとを含む方法。
【請求項５５】
前記宛先は、前記メッセージング・アプライアンスの別の１つか、あるいは前記特定のメッセージング・アプライアンスに論理的にリンクされたアプリケーション・プログラミング・インタフェース、またはその両方を含む請求項５４に記載の方法。
【請求項５６】
前記メッセージング・アプライアンスのそれぞれをプロビジョニング−マネージメント・システムに相互接続するステップと、
前記プロビジョニング−マネージメント・システムと、前記メッセージング・アプライアンスの少なくとも１つとの間で、システム構成、健全性、パフォーマンス監視、報告、名前空間管理の１つまたは複数に関連する少なくとも１つの管理メッセージを交換するステップをさらに含む請求項５４に記載の方法。
【請求項５７】
前記少なくとも１つのメッセージを、前記ルーティングするステップに先立って、外部プロトコルからネイティブ・プロトコルに変換するステップをさらに含む請求項５４に記載の方法。
【請求項５８】
前記少なくとも１つのルーティングされるメッセージを、ネイティブ・プロトコルから外部プロトコルに変換するステップをさらに含む請求項５４に記載の方法。
【請求項５９】
アプリケーション・プログラミング・インタフェースを、前記メッセージング・アプライアンスの特定の１つに論理的にリンクするステップと、
トピック・ベースのサブスクリプションを介して、前記アプリケーション・プログラミング・インタフェースを前記特定のメッセージング・アプライアンスに登録するステップとをさらに含む請求項５４に記載の方法。
【請求項６０】
サービス品質機能を提供するために、前記少なくとも１つのメッセージを、前記１つまたは複数のメッセージング・アプライアンスに動作上、接続されたキャッシング・エンジンの中に格納するステップをさらに含む請求項５４に記載の方法。
【請求項６１】
前記格納されたメッセージを、前記１つまたは複数のメッセージング・アプライアンスの１つに論理的にリンクされたアプリケーション・プログラミング・インタフェースに、前記１つまたは複数のメッセージング・アプライアンスの少なくとも１つに、または以上の組合せに転送するステップをさらに含む請求項６０に記載の方法。
【発明の詳細な説明】
【関連出願】
【０００１】
（先行出願の引用）
本願は、「Ｅｖｅｎｔ  Ｒｏｕｔｅｒ  Ｓｙｓｔｅｍ  ａｎｄ  Ｍｅｔｈｏｄ」という名称の２００５年１月６日に出願した米国特許仮出願第６０／６４１９８８号、および「Ｈｙｂｒｉｄ  Ｆｅｅｄ  Ｈａｎｄｌｅｒｓ  Ａｎｄ  Ｌａｔｅｎｃｙ  Ｍｅａｓｕｒｅｍｅｎｔ」という名称の２００５年６月８日に出願した米国特許仮出願第６０／６８８９８３号の利益を主張し、以上の仮出願を参照により組み込む。
【技術分野】
【０００２】
本発明は、データ・メッセージングに関し、より詳細には、パブリッシュ／サブスクライブ・システムのミドルウェア・アーキテクチャに関する。
【背景技術】
【０００３】
データ・メッセージング・インフラストラクチャによって要求されるパフォーマンス・レベルがますます高くなっていることが、ネットワーキング・インフラストラクチャやネットワーキング・プロトコルの進歩の抗し難い根本的な理由となっている。基本的に、データ配信には、データの様々な送信元と宛先だけでなくデータ送信元とデータ宛先の間における様々なタイプの相互接続アーキテクチャや通信モードがかかわる。既存のデータ・メッセージング・アーキテクチャの例には、ハブ・アンド・スポーク、ピア・ツー・ピア、ストア・アンド・フォワードが含まれる。
【０００４】
ハブ・アンド・スポーク・システム構成では、すべての通信は、ハブ経由でトランスポートされ、しばしば、非常に多くの量を処理する際、パフォーマンスのネックを生じさせる。したがって、このメッセージング・システム・アーキテクチャは、待ち時間をもたらす。このネックを回避する１つのやり方は、より多くのサーバを展開し、それらの異なるサーバにわたってネットワーク負荷を分散させることである。しかし、そのようなアーキテクチャは、スケーラビリティの問題や、動作上の問題をもたらす。ハブ・アンド・スポーク構成を有するシステムと比較して、ピア・ツー・ピア構成を有するシステムは、データを処理し、フィルタリングするアプリケーション群に不要なストレスをかけ、そのシステムの最も遅いコンシューマまたはノードが速度の限界である。次に、ストア・アンド・フォワード・システム構成では、永続性を与えるために、システムは、データを格納してから、パスにおける次のノードに、そのデータを転送する。格納オペレーションは、通常、メッセージに索引を付けて、ディスクに書き込むことによって行われ、これにより、パフォーマンスのネックが生じる可能性がある。さらに、メッセージ量が増加すると、索引付けのタスクや書き込みのタスクは、さらに遅くなる可能性があり、このため、さらなる待ち時間を生じさせる可能性がある。
【０００５】
既存のデータ・メッセージング・アーキテクチャは、いくつかの欠点を共有している。１つの共通の欠点は、既存のアーキテクチャにおけるデータ・メッセージングが、アプリケーション・レベルに存在するソフトウェアに依拠することである。このことは、メッセージング・インフラストラクチャが、ＯＳ（オペレーティング・システム）キューイングやネットワークＩ／Ｏ（入力／出力）を経験し、これにより、パフォーマンスのネックが生じる可能性があることを意味する。別の共通の欠点は、他のプロトコルが、状況下で、より適切である場合でさえ、既存のアーキテクチャは、データ・トランスポート・プロトコルを、動的にではなく、静的に使用することである。一般的なプロトコルのいくつかの例には、ルーティング可能なマルチキャスト、ブロードキャスト、またはユニキャストが含まれる。実際、既存のアーキテクチャにおけるＡＰＩ（アプリケーション・プログラミング・インタフェース）は、複数のトランスポート・プロトコルの間で、リアルタイムで切り換えを行うように設計されていない。
【０００６】
また、ネットワーク構成決定は、通常、展開時に行われ、通常、特定の想定の下で、ネットワーク条件とメッセージング条件の１つのセットを最適化するように定義される。静的（固定の）構成に関連する限界は、リアルタイムの動的なネットワーク再構成を除外する。つまり、既存のアーキテクチャは、すべてのネットワーク・データ・トランスポート負荷条件に必ずしも適しているわけではない特定のトランスポート・プロトコル向けに構成され、したがって、既存のアーキテクチャは、しばしば、変化、または、より高い負荷容量要件をリアルタイムで扱うことができない。
【０００７】
さらに、データ・メッセージングが、特定の受信者、または特定の受信者グループを宛先としている場合、既存のメッセージング・アーキテクチャは、いくつかのネットワークにわたってデータをトランスポートするために、ルーティング可能なマルチキャストを使用する。しかし、マルチキャスト向けにセットアップされたシステムには、データを配信するのに使用できるマルチキャスト・グループの数に限界があり、その結果、メッセージング・システムは、システムにサブスクライブしていない宛先（すなわち、サブスクライバではないコンシューマ）にデータを送信してしまうことになる。これにより、コンシューマのデータ処理負荷、およびデータ・フィルタリングによる破棄率が高まる。すると、何らかの理由で過負荷になり、データのフローについて行くことができないコンシューマは、結局は、着信データをドロップし、後に、再送を求める。再送は、すべてのコンシューマが、繰り返しの伝送を受信し、コンシューマのすべてが、着信データを再処理するという点で、システム全体に影響を及ぼす。したがって、再送は、マルチキャスト・ストームを生じさせて、ついには、ネットワーク化されたシステム全体をダウンさせる可能性がある。
【０００８】
システムが、破棄率を低減する策としてユニキャスト・メッセージング向けにセットアップされた場合、メッセージング・システムは、データ重複のために帯域幅が飽和する可能性がある。例えば、複数のコンシューマが、関心対象の所与のトピックにサブスクライブした場合、メッセージング・システムは、データを各サブスクライバに配信しなければならず、実際、システムは、そのデータの異なるコピーを各サブスクライバに送信する。また、これにより、コンシューマが、サブスクライブ対象でないデータをフィルタリングして除く問題が解決されるものの、ユニキャスト伝送は、スケーラブルではなく、このため、ある特定のデータにサブスクライブする相当に大きいコンシューマ・グループ、または消費パターンの相当な重複に適合可能ではない。
【０００９】
既存のアーキテクチャの１つのより一般的な欠点は、それらのアーキテクチャのプロトコル変換が遅く、回数が多いことである。このことの理由は、ますます多くの新たな技術が、レガシー・システムと統合される、ＥＡＩ（Ｅｎｔｅｒｐｒｉｓｅ  Ａｐｐｌｉｃａｔｉｏｎ  Ｉｎｔｅｇｒａｔｉｏｎ）ドメインにおけるＩＴ（情報技術）応急処置戦略である。
【００１０】
したがって、いくつかの領域でデータ・メッセージング・システム・パフォーマンスを向上させる必要性が存在する。パフォーマンスが向上を必要とする可能性がある例が、速度、リソース割り当て、待ち時間などである。
【発明の開示】
【課題を解決するための手段】
【００１１】
本発明は、ある程度、以上の所見と、そのような欠点に、異なるアプローチを使用して、より良い結果で対処することができるという考えとに基づく。以上の所見は、大量の、待ち時間が少ないメッセージング向けの終端間メッセージ・パブリッシュ／サブスクライブ・アーキテクチャを生み出した。したがって、本発明の諸原理による終端間メッセージ・パブリッシュ／サブスクライブ・アーキテクチャを有するデータ配信システムは、とりわけ、近隣ベースのルーティングとネットワーク・ディスインターメディエーションで中間ホップを減らすこと、効率的なネイティブ−外部プロトコル変換および外部−ネイティブ・プロトコル変換を導入すること、待ち時間を含め、システム・パフォーマンスをリアルタイムで監視すること、トピック・ベースのメッセージ通信とチャネル・ベースのメッセージ通信を使用すること、さらにシステム相互接続構成とメッセージ伝送プロトコルを動的に、インテリジェントな形で最適化することにより、相当により大きいメッセージ量を、大幅に少ない待ち時間で有利にルーティングすることができる。さらに、そのようなシステムは、データ・キャッシングを使用して、保証された配信サービス品質を提供することができる。
【００１２】
リソース割り当てに関連して、本発明によるデータ配信システムは、利用可能なリソースをリアルタイムで動的に割り当てるという利点を発生させる。その目的で、従来の静的構成アプローチの代わりに、本発明は、リソース割り当てについての、リアルタイムの動的な、学習されたアプローチを伴うシステムを企図する。リソース割り当てが、リアルタイムで最適化されることが可能な例には、ネットワーク・リソース（帯域幅、プロトコル、パス／経路の使用）やコンシューマ・システム・リソース（ＣＰＵ、メモリ、ディスク・スペースの使用）が含まれる。
【００１３】
システム・トポロジとシステム・パフォーマンスを監視することに関連して、本発明によるデータ配信システムは、メッセージ・レベルの待ち時間測定と、フレーム・レベルの待ち時間測定とを区別する。いくつかのケースでは、それらの測定の間の相互関係により、ビジネスの競争上の利点がもたらされる。つまり、待ち時間の性質と程度により、最良のデータとデータ送信元が示され、これらは、ビジネス・プロセスにおいて役立ち、競争上の優位性を提供する。
【００１４】
このため、本明細書で示され、広く説明される本発明の目的によれば、パブリッシュ／サブスクライブ・ミドルウェア・アーキテクチャを有する１つの例示的なシステムは、メッセージを受信して、ルーティングするように構成された１つまたは複数のメッセージング・アプライアンスと、相互接続と、相互接続を介してリンクされ、各メッセージング・アプライアンスと管理メッセージを交換するように構成されたプロビジョニング−マネージメント・システムとを含む。そのようなシステムにおいて、メッセージング・アプライアンスは、メッセージ伝送プロトコルとメッセージ・ルーティング・パスを動的に選択することにより、メッセージのルーティングを実行する。
【００１５】
加えて、パブリッシュ／サブスクライブ・システムは、プロビジョニング−マネージメント・システムから中央で監視され、構成されることが可能である。これにより、資格、ユーザ管理、デジタル権利管理、スキーマなどに関する、扱いやすい、スケーラブルな単一ポイント構成がもたらされる。
【００１６】
さらに、以上のシステムは、１つまたは複数の名前空間ドメインを有して実装され、実際、複数の空間ドメインが存在する場合、システムは、名前空間ドメインの間を接続するためのドメイン相互接続媒体をさらに含む。このドメイン相互接続は、例えば、任意のネットワーキング・インフラストラクチャであることが可能である。
【００１７】
さらに別の実施形態では、パブリッシュ／サブスクライブ・ミドルウェア・アーキテクチャを有する企業システムは、市場データ・メッセージを受信して、ルーティングするための１つまたは複数のメッセージング・アプライアンスを有する市場データ配信インフラストラクチャと、トランザクション注文メッセージを受信して、ルーティングするための１つまたは複数のメッセージング・アプライアンスを有する市場注文ルーティング・インフラストラクチャと、市場データ配信インフラストラクチャを含み、さらに市場注文ルーティング・インフラストラクチャとそれぞれ通信リンクしている中間インフラストラクチャを含む。このシステムでは、中間インフラストラクチャは、市場データ・メッセージとトランザクション注文メッセージを受信して、ルーティングするように構成された複数のメッセージング・アプライアンスと、相互接続とを含むと共に、さらに、相互接続を介してリンクされ、市場データ配信インフラストラクチャや市場注文ルーティング・インフラストラクチャにおけるメッセージング・アプライアンスを含め、各メッセージング・アプライアンスと管理メッセージを交換するように構成されたプロビジョニング−マネージメント・システムを含む。この場合も、メッセージング・アプライアンスのそれぞれは、メッセージ伝送プロトコルとメッセージ・ルーティング・パスを動的に選択することにより、そのアプライアンスが受信するメッセージのルーティングを実行するようにさらに構成される。
【００１８】
さらに、そのような企業システムには、市場データ・メッセージをパブリッシュするための市場データ送信元と、市場データ・メッセージを受信するため、およびトランザクション注文メッセージをパブリッシュするための市場データ・コンシューマ（外部データ宛先）とが、存在する。市場データ・コンシューマは、１つまたは複数のアプリケーションを含む。したがって、中間インフラストラクチャは、アプリケーションのそれぞれと、アプリケーション・プログラミング・インタフェースが登録されている中間インフラストラクチャにおけるメッセージング・アプライアンスの１つとの間において、そのようなアプリケーション・プログラミング・インタフェースを含む。アプリケーション・プログラミング・インタフェースは、市場データ・メッセージをアプリケーション群に、トランザクション注文メッセージをアプリケーション群から配信するように機能する。このシステムは、着信メッセージと送信メッセージのネイティブ・メッセージ・プロトコルと外部メッセージ・プロトコルとの間で、それぞれ変換を行うためのプロトコル変換エンジンをさらに含む。
【００１９】
要するに、本発明の以上、およびその他の特徴、態様、および利点は、本明細書の説明、添付の特許請求の範囲、および後段で説明する添付の図面から、より良く理解されるようになろう。
【００２０】
本明細書に組み込まれ、本明細書の一部を構成する添付の図面は、本発明の様々な態様を例示し、説明と一緒に、本発明の諸原理を説明する役割をする。好都合な場合はいつでも、同一の符号が、すべての図面で、同一の要素、または同様の要素を指すのに使用される。
【発明を実施するための最良の形態】
【００２１】
本発明の諸態様と諸原理による様々な実施形態の詳細の概要を述べる前に、以下は、この説明の全体で使用されるいくつかの用語の簡単な説明である。この説明は、単に、そのような用語がどのように使用される可能性があるかについて、明確にし、読者に理解を与えることを、ただし、それらの用語が使用される文脈に、それらの用語を限定することなく、特許請求の範囲を限定することなしに、意図していることに留意されたい。
【００２２】
「ミドルウェア」という用語が、２つの別個の、しばしば、既に存在するプログラムの間を仲介する任意のプログラミングを表す一般的な用語として、コンピュータ業界で使用されている。通常、ミドルウェア・プログラムは、様々なアプリケーションが通信することができるように、メッセージング・サービスを提供する。異種のアプリケーションを、しばしば、ミドルウェアの使用を介して、一緒に系統立って結び付けることは、ＥＡＩ（Ｅｎｔｅｒｐｒｉｓｅ  Ａｐｐｌｉｃａｔｉｏｎ  Ｉｎｔｅｇｒａｔｉｏｎ）として知られる。しかし、この文脈において、「ミドルウェア」は、送信元と宛先の間におけるメッセージングの文脈で使用される、より広い用語であり、そのようなメッセージングを可能にするように展開される機構であることが可能であり、このため、ミドルウェア・アーキテクチャは、以下に説明するとおり、個々に、または組合せで、効果的なデータ・メッセージングを円滑にするネットワーキング、およびコンピュータのハードウェア構成要素やソフトウェア構成要素をも範囲に含む。さらに、「メッセージング・システム」または「ミドルウェア・システム」という用語が、パブリッシャとサブスクライバの間におけるメッセージのルーティングをメッセージング・サーバが管理する、パブリッシュ／サブスクライブ・システムの文脈において使用されることが可能である。実際、メッセージング・ミドルウェアにおけるパブリッシュ／サブスクライブのパラダイムは、スケーラブルな、したがって、強力なモデルである。
【００２３】
「コンシューマ」という用語が、クライアント−サーバ・アプリケーションなどの文脈において使用される。１つの実例では、コンシューマは、ＡＰＩ（アプリケーション・プログラミング・インタフェース）を使用して、ミドルウェア・システムに登録し、情報にサブスクライブし、ミドルウェア・システムによって配信されたデータを受信するシステムまたはアプリケーションである。ミドルウェア・アーキテクチャ境界内のＡＰＩは、コンシューマであり、外部コンシューマは、ＡＰＩを使用せず、メッセージが、プロトコル変換を経る（以下に説明するとおり）通信相手である、任意のパブリッシュ／サブスクライブ・システム（または外部データ宛先）である。
【００２４】
「外部データ送信元」という用語が、データ配信システムとメッセージ・パブリッシュ／サブスクライブ・システムの文脈において使用される。１つの実例では、外部データ送信元は、一般的なプロトコルの１つで、または独自のメッセージ・プロトコルでメッセージをパブリッシュする、企業プライベート・ネットワークの内部または外部に配置された、システムまたはアプリケーションと見なされる。外部データ送信元の例は、ミドルウェア・システムを介してトレーダに配信される株式市場の取引値をパブリッシュする市場データ・エクスチェンジである。外部データ送信元の別の例は、トランザクション・データである。本発明の通常の実装では、以下により詳細に説明するとおり、ミドルウェア・アーキテクチャは、外部データ送信元からのデータが、ミドルウェア・システム・ドメインに入ると、変換される、固有のネイティブ・プロトコルを採用し、従来のシステムによくある複数のプロトコル変換を回避することに留意されたい。
【００２５】
また、「外部データ宛先」という用語も、データ配信システムとメッセージ・パブリッシュ／サブスクライブ・システムの文脈において使用される。外部データ宛先は、例えば、ローカル／グローバル・ネットワークを介してルーティングされる情報にサブスクライブする、企業プライベート・ネットワークの内部または外部に配置された、システムまたはアプリケーションである。外部データ宛先の一例は、トレーダによってパブリッシュされたトランザクション注文を扱う市場データ・エクスチェンジである。外部データ宛先のさらに別の実施形態が、トランザクション・データである。以上のミドルウェア・アーキテクチャでは、外部データ宛先を宛先とするメッセージは、ネイティブ・プロトコルから、外部データ宛先に関連する外部プロトコルに変換されることに留意されたい。
【００２６】
本明細書の説明から確認することができるとおり、本発明は、ミドルウェア・アーキテクチャをそれぞれが実施する、様々な構成で、様々な仕方で実施されることが可能である。本発明の諸原理による終端間ミドルウェア・アーキテクチャの例が、図１に示される。
【００２７】
この例示的なアーキテクチャは、以下を含むいくつかの有益な特徴を併せ持つ。すなわち、メッセージング一般的概念、ＡＰＩ、フォールト・トレランス、Ｐ＆Ｍ（プロビジョニング−マネージメント）、ＱｏＳ（サービス品質−融合型、ベスト・エフォート型、接続中保証型、切断中保証型など）、保証された配信ＱｏＳのための永続キャッシング、名前空間とセキュリティ・サービスの管理、パブリッシュ／サブスクライブ・エコシステム（コア構成要素、イングレス構成要素、イグレス構成要素）、トランスポート・トランスペアレント・メッセージング、近隣ベースのメッセージング（ハブ・アンド・スポーク、ピア・ツー・ピア、ストア・アンド・フォワードの間の混成であり、必要に応じて、サブスクリプションをすべての近隣に広めることができるサブスクリプション・ベースのルーティング・プロトコルを使用するモデル）、レイト・スキーマ・バインディング、部分的パブリッシング（データ全体ではなく、パブリッシングによって変更された情報だけ）、ネットワーク・リソースとシステム・リソースの動的割り当てである。後段で説明するとおり、パブリッシュ／サブスクライブ・システムは、ミドルウェア・アーキテクチャのフォールト・トレラント設計を有利に組み込む。パブリッシュ／サブスクライブ・エコシステムのコアＭＡ部分は、前述したネイティブ・メッセージング・プロトコル（ミドルウェア・システムに固有の）を使用するのに対して、イングレス部分とイグレス部分、エッジＭＡは、そのネイティブ・プロトコルへの変換や、そのネイティブ・プロトコルからの変換をそれぞれ行うことに留意されたい。
【００２８】
パブリッシュ／サブスクライブ・システム構成要素に加えて、図１は、論理接続、およびそれらの論理接続間の通信も示す。見て取ることができるとおり、図示されるミドルウェア・アーキテクチャは、分散システムのアーキテクチャである。このアーキテクチャを有するシステムにおいて、２つの別個の物理構成要素の間の論理通信は、メッセージ・ストリームと、関連するメッセージ・プロトコルで確立される。メッセージ・ストリームは、メッセージ２つのカテゴリの１つ、すなわち管理メッセージとデータ・メッセージのいずれかを含む。管理メッセージは、様々な物理構成要素の管理と制御、データへのサブスクリプションの管理、その他のために使用される。データ・メッセージは、送信元と宛先の間でデータをトランスポートするために使用され、通常のパブリッシュ／サブスクライブ・メッセージングでは、データ・メッセージの複数の送信者と複数の受信者とが存在する。
【００２９】
ミドルウェア・アーキテクチャを有する分散パブリッシュ／サブスクライブ・システムは、例示される構造上の構成と論理通信で、いくつかの論理機能を実行するように設計される。１つの論理機能は、エッジＭＡ（メッセージング・アプライアンス）構成要素において有利に実行されるメッセージ・プロトコル変換である。第２の論理機能は、パブリッシャからサブスクライバにメッセージをルーティングすることである。メッセージは、パブリッシュ／サブスクライブ・ネットワーク全体でルーティングされることに留意されたい。このため、ルーティング機能は、メッセージが伝搬される、例えば、エッジＭＡ１０６ａ〜ｂ（またはＡＰＩ）からコアＭＡ１０８ａ〜ｃまで、または１つのコアＭＡから別のコアＭＡまで、さらに、最終的に、エッジＭＡ（例えば、１０６ｂ）またはＡＰＩ １１０ａ〜ｂまで、各ＭＡによって実行される。ＡＰＩ １１０ａ〜ｂは、プロセス間通信バス（ソケット、共有メモリなど）を介して、アプリケーション１１２1〜nと通信する。
【００３０】
第３の論理機能は、例えば、接続中保証タイプや切断中保証タイプを含め、様々なタイプの保証配信サービス品質のためにメッセージを格納することである。第４の機能は、サブスクライバに、それらのメッセージを配信することである。図示されるとおり、ＡＰＩ １０６ａ〜ｂは、サブスクライブするアプリケーション１１２1〜nにメッセージを配信する。
【００３１】
このパブリッシュ／サブスクライブ・アーキテクチャでは、システム構成機能、ならびに、その他の管理機能とシステム・パフォーマンス監視機能は、Ｐ＆Ｍシステムによって管理される。さらに、ＭＡは、ネットワークにおけるＭＡの役割に応じて、エッジＭＡまたはコアＭＡとして展開される。エッジＭＡは、メッセージを、外部プロトコルからネイティブ・プロトコルに、またネイティブ・プロトコルから外部プロトコルに変換するプロトコル変換エンジンを含むこと以外は、ほとんどの点でコアＭＡと同様である。このため、一般に、パブリッシュ／サブスクライブ・システム・ミドルウェア・アーキテクチャの境界は、エッジＭＡ１０６ａ〜ｂとＡＰＩ １１０ａ〜ｂが存在するエッジを特徴とし、それらの境界内に、コアＭＡ１０８ａ〜ｃが存在する。
【００３２】
通常のシステムでは、コアＭＡ１０８ａ〜ｃは、パブリッシュされたメッセージをシステム内で、エッジＭＡまたはＡＰＩ（例えば、ＡＰＩ １１０ａ〜ｂ）に向けて内部でルーティングする。特にコアＭＡにおけるルーティング・マップは、最大容量、少ない待ち時間、および効率的なルーティングのために設計される。さらに、コアＭＡ間のルーティングは、リアルタイムで動的に変化することが可能である。いくつかのノード（コアＭＡ）を横断する所与のメッセージング・パスに関して、ルーティングのリアルタイムの変更は、ネットワーク利用率、全体的な終端間待ち時間、通信量、ネットワーク遅延、損失、ジッタを含め、１つまたは複数のメトリックに基づく。
【００３３】
代替として、２つ以上の異なるパスから最良のパフォーマンスを示すパスを動的に選択する代わりに、ＭＡは、メッセージ・レプリケーションに基づき、マルチパス・ルーティングを実行することができ、このため、すべてのパスにわたって同一のメッセージを送信することができる。異なるパスの収束点に位置するすべてのＭＡは、重複メッセージをドロップして、最初に着信したメッセージだけを転送する。このルーティング・アプローチは、少ない待ち時間のためにメッセージング・インフラストラクチャを最適化するという利点を有する。ただし、このルーティング方法の欠点は、そのインフラストラクチャが、重複トラフィックを伝送するのに、より多くのネットワーク帯域幅を必要とすることである。
【００３４】
システム・アーキテクチャは、特定の限られた地理的区域に限定されておらず、実際、地域的境界または国境を越えるように、さらに、大陸間にわたるようにさえ設計されることに留意されたい。そのようなケースでは、１つのネットワークにおけるエッジＭＡは、別の地理的に遠隔のネットワークにおけるエッジＭＡと、既存のネットワーキング・インフラストラクチャを介して通信することができる。
【００３５】
エッジＭＡは、着信メッセージのいずれの外部メッセージ・プロトコルも、ミドルウェア・システムのネイティブ・メッセージ・プロトコルに変換し、送信メッセージに関してネイティブ・プロトコルから外部プロトコルに変換する能力を有する。つまり、外部プロトコルは、メッセージが、パブリッシュ／サブスクライブ・ネットワーク・ドメインに入る際に（イングレス）、ネイティブ（例えば、Ｔｅｒｖｅｌａ（商標））メッセージ・プロトコルに変換され、ネイティブ・プロトコルは、メッセージが、パブリッシュ／サブスクライブ・ネットワーク・ドメインを出る際に（イグレス）、外部プロトコルに変換される。エッジＭＡの別の機能は、パブリッシュされたメッセージを、サブスクライブする外部データ宛先に配信することである。
【００３６】
さらに、エッジＭＡ１０６ａ〜ｂとコアＭＡ１０８ａ〜ｃはともに、メッセージを格納してから、それらのメッセージを転送することができる。これが行われることが可能な１つの形は、ＣＥ（キャッシング・エンジン）１１８ａ〜ｂを使用して行うことである。１つまたは複数のＣＥが、同一のＭＡに接続されることが可能である。理論上、ＡＰＩは、このストア・アンド・フォワード能力を有さないと言われているが、現実には、ＡＰＩ １１０ａ〜ｂは、メッセージを格納してから、それらのメッセージをアプリケーションに配信することができ、アプリケーションから受信されたメッセージを格納してから、それらのメッセージをコアＭＡ、エッジＭＡ、または別のＡＰＩに配信することができる。
【００３７】
ＭＡ（エッジＭＡまたはコアＭＡ）は、ＣＥに対する能動的な接続を有する場合、ルーティングされるメッセージのすべて、またはサブセットをＣＥに転送し、ＣＥは、それらのメッセージを、保存のためにストレージ領域に書き込む。すると、所定の期間にわたって、それらのメッセージは、要求されると、再送に利用可能である。以上のフィーチャが実施される例は、データ再生、部分的パブリッシュ、様々なサービス品質レベルである。部分的パブリッシュは、すべての情報の伝送ではなく、更新された情報だけの伝送しか要求しないため、ネットワーク負荷とコンシューマ負荷を減らすのに有効である。
【００３８】
ルーティング・マップが、ルーティングにどのように影響を与えるかを例示するように、パブリッシュ／サブスクライブ・ルーティング・パスのいくつかの例が、図１に示されている。この例示では、パブリッシュ／サブスクライブ・ネットワークのミドルウェア・アーキテクチャが、パブリッシャとサブスクライバの間で５つ以上の異なる通信パスを提供する。
【００３９】
第１の通信パスは、外部データ送信元を外部データ宛先にリンクする。外部データ送信元１１４1〜nから受信された、パブリッシュされたメッセージは、ネイティブ（例えば、Ｔｅｒｖｅｌａ（商標））メッセージ・プロトコルに変換され、次に、エッジＭＡ１０６ａによってルーティングされる。ネイティブ・プロトコル・メッセージが、エッジＭＡ１０６ａからルーティングされることが可能な１つの形は、外部データ宛先１１６ｎに対してである。そのパスは、通信パス１ａとして呼び出される。そのケースでは、ネイティブ・プロトコル・メッセージは、外部データ宛先に適した外部プロトコル・メッセージに変換される。ネイティブ・プロトコル・メッセージが、エッジＭＡ１０６ｂからルーティングされることが可能な別の形は、内部でコアＭＡ１０８ｂを経由してである。そのパスは、通信パス１ｂとして呼び出される。そのパスに沿って、コアＭＡ１０８ｂは、ネイティブ・メッセージをエッジＭＡ１０６ａにルーティングする。しかし、エッジＭＡ１０６ａは、ネイティブ・プロトコル・メッセージを外部データ宛先１１６1にルーティングする前に、それらのメッセージを、その外部データ宛先１１６1に適した外部メッセージ・プロトコルに変換する。見て取ることができるとおり、その通信パスは、ＡＰＩが、メッセージをパブリッシャからサブスクライバにルーティングすることを要求しない。したがって、パブリッシュ／サブスクライブ・システムが、外部送信元−宛先通信のために使用される場合、システムは、ＡＰＩを含まなくてもよい。
【００４０】
通信パス２として呼び出される別の通信パスは、外部データ送信元１１４ｎを、ＡＰＩ １１０ｂを使用するアプリケーションにリンクする。外部データ送信元から受信された、パブリッシュされたメッセージは、エッジＭＡ１０６ａにおいて、ネイティブ・メッセージ・プロトコルに変換され、次に、エッジＭＡによってコアＭＡ１０８ａにルーティングされる。第１のコアＭＡ１０８ａから、メッセージは、別のコアＭＡ１０８ｃ経由でＡＰＩ １１０ｂにルーティングされる。ＡＰＩから、メッセージは、サブスクライブするアプリケーション（例えば、１１２2）に配信される。通信パスは、双方向であるため、別の実例では、メッセージは、サブスクライブするアプリケーション１１２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は、ＦＴ  ＭＡ９０８に対して、能動的なセッションを有する。
【０１０５】
１次ＭＡと２次ＭＡは、何らかのチャネル・ベースの論理を使用して、論理チャネル・アドレスを物理チャネル・アドレスにマップする単一のＭＡと見なされることが可能である。例えば、ＩＰベースのチャネルに関して、ＡＰＩまたはＭＡは、ＭＡ論理アドレスのＡＰＲキャッシュ・エントリを、２次ＭＡの物理ＭＡＣアドレスをポイントするように更新することにより、問題のあるセッションを、２次ＭＡに向けてリダイレクトすることができる。
【０１０６】
要するに、本発明は、メッセージングの新たなアプローチを提供し、より具体的には、メッセージング・システムの有効性を向上させる終端間ミドルウェア・アーキテクチャを提供する。本発明を、本発明の、いくつかの好ましいバージョンに関連して、相当に詳細に説明してきたが、他のバージョンも可能である。したがって、添付の特許請求の範囲の趣旨および範囲は、本明細書に含まれる好ましいバージョンの説明に限定されてはならない。
【図面の簡単な説明】
【０１０７】
【図１】本発明の諸原理による終端間ミドルウェア・アーキテクチャを示す図である。
【図１ａ】オーバーレイ・ネットワークを示す図である。
【図２】本発明の諸原理による終端間ミドルウェア・アーキテクチャで実施される企業インフラストラクチャを示す図である。
【図２ａ】ネットワーク・バックボーン・ディスインターメディエーションを作成するＭＡ群（メッセージアプライアンス群）を有する、企業インフラストラクチャの物理的展開を示す図である。
【図３】チャネル・ベースのメッセージング・システム・アーキテクチャを示す図である。
【図４ａ】１つの可能なトピック・ベースのメッセージ・フォーマットを示す図である。
【図４ｂ】１つの可能なトピック・ベースのメッセージ・フォーマットを示す図である。
【図５】トピック・ベースのメッセージ・ルーティングおよびルーティング・テーブルを示す図である。
【図６】本発明の一実施形態によるＰ＆Ｍ（プロビジョニング−マネージメント）システムを示すブロック図である。
【図７ａ】名前空間ベースのトポロジを有するメッセージング（パブリッシュ／サブスクライブ・）システムを示す図である。
【図７ｂ】名前空間ベースのトポロジを有するメッセージング（パブリッシュ／サブスクライブ・）システムを示す図である。
【図８ａ】Ｐ＆Ｍシステムと、ＭＡ（メッセージ・アプライアンス）の１つとの間の通信を示す図である。
【図８ｂ】Ｐ＆Ｍシステムと、ＭＡ（メッセージ・アプライアンス）の１つとの間の通信を示す図である。
【図９】本発明の諸原理に従って構成されたＭＡを示すブロック図である。
【図１０ａ】ＭＡとＣＥ（キャッシング・エンジン）の間における通信のためのインタフェースを示す図である。
【図１０ｂ】ＭＡとＣＥ（キャッシング・エンジン）の間における通信のためのインタフェースを示す図である。
【図１１ａ】ＭＡとＡＰＩ（アプリケーション・プログラミング・インタフェース）の間における通信のためのインタフェースを示す図である。
【図１１ｂ】ＭＡとＡＰＩ（アプリケーション・プログラミング・インタフェース）の間における通信のためのインタフェースを示す図である。
【図１２】本発明の一実施形態に従って構成されたＣＥを示すブロック図である。
【図１３】本発明の一実施形態に従って構成されたＡＰＩを示すブロック図である。
【図１４】本発明の諸原理によるセッション・ベースのフォールト・トレラント構成で設計されたシステムを示す図である。
【図１】
2008527847.tif 000003
【図１ａ】
2008527847.tif 000004
【図２】
2008527847.tif 000005
【図２ａ】
2008527847.tif 000006
【図３】
2008527847.tif 000007
【図４ａ】
2008527847.tif 000008
【図４ｂ】
2008527847.tif 000009
【図５】
2008527847.tif 000010
【図６】
2008527847.tif 000011
【図７ａ】
2008527847.tif 000012
【図７ｂ】
2008527847.tif 000013
【図８ａ】
2008527847.tif 000014
【図８ｂ】
2008527847.tif 000015
【図９】
2008527847.tif 000016
【図１０ａ】
2008527847.tif 000017
【図１０ｂ】
2008527847.tif 000018
【図１１ａ】
2008527847.tif 000019
【図１１ｂ】
2008527847.tif 000020
【図１２】
2008527847.tif 000021
【図１３】
2008527847.tif 000022
【図１４】
2008527847.tif 000023
【国際調査報告】
2008527847.tif 000024