(57)【要約】  低減された待ち時間およびパフォーマンスのネックで大きいメッセージ量を処理するメッセージ・パブリッシュ／サブスクライブ・システムが、要求される。本発明によって提案されるハードウェア・ベースのメッセージング・アプライアンスは、大量の、待ち時間の少ないメッセージング向けに設計される。このハードウェア・ベースのメッセージング・アプライアンスは、パブリッシュ／サブスクライブ・ミドルウェア・システムの一部である。そのハードウェア・ベースのメッセージング・アプライアンスを使用して、このシステムは、とりわけ、近隣ベースのルーティングで中間ホップを減らし、効率的なネイティブ−外部プロトコル変換および外部−ネイティブ・プロトコル変換を導入し、待ち時間を含め、システム・パフォーマンスをリアルタイムで監視し、トピック・ベースの通信およびチャネル・ベースの通信を使用し、システム相互接続構成およびメッセージ伝送プロトコルを動的に最適化するように動作する。
2008527848.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は、チャネル５に向かわせられる。
【００６９】
ルーティング・テーブル構造の選択は、ルーティング・ルックアップ・テーブルを最適化するように意図されているが、ルックアップのパフォーマンスは、着信メッセージ・トピックと一致する１つまたは複数のトピック・サブスクリプションを見出すためのサーチ・アルゴリズムにも依存する。したがって、ルーティング・テーブル構造は、そのようなアルゴリズムを受け容れることができなければならず、その逆も同様である。ルーティング・テーブルのサイズを小さくする１つの仕方は、ルーティング・アルゴリズムが、パブリッシュ／サブスクライブ・ネットワーク全体にわたってサブスクリプションを選択的に広めることを可能にすることによってである。例えば、あるサブスクリプションが、既に広められている別のサブスクリプションのサブセット（例えば、ストリング全体の一部分）であるように見える場合、ＭＡは、そのサブスクリプションのスーパーセットに関する情報を既に有しているので、そのサブセット・サブスクリプションを広める必要は、全くない。
【００７０】
以上に基づき、好ましいメッセージ・ルーティング・プロトコルは、トピック・ベースのルーティング・プロトコルであり、資格は、サブスクライバと、それぞれのトピックとの間のマッピングにおいて示される。資格は、サブスクライバごとに、またはサブスクライバのグループ／クラスごとに指定され、サブスクライバが、どのようなメッセージを消費する権利を有するか、またはいずれのメッセージが、そのようなパブリッシャによって作成（パブリッシュ）されてもよいかを示す。それらの資格は、Ｐ＆Ｍマシンにおいて定義され、パブリッシュ／サブスクライブ・ネットワークにおけるすべてのＭＡに通信され、その後、ＭＡによって、ＭＡのルーティング・テーブルを作成し、更新するのに使用される。
【００７１】
各ＭＡは、そのＭＡのルーティング・テーブルを、誰が、どのようなトピックに関心があるか（サブスクライブを要求しているか）を常に把握しておくことにより、更新する。しかし、ＭＡは、経路をＭＡのルーティング・テーブルに追加する前に、パブリッシュ／サブスクライブ・ネットワークの資格に照らしてサブスクライブをチェックしなければならない。ＭＡは、近隣のＭＡ、Ｐ＆Ｍシステム、ＣＥ、またはＡＰＩであることが可能な、サブスクライブするエンティティが、サブスクライブすることを許可されていることを検証する。サブスクリプションが有効である場合、経路は、作成され、ルーティング・テーブルに追加される。その場合、一部の資格は、あらかじめ知られていることがあるため、システムは、事前定義された資格を伴って展開されることが可能であり、それらの資格が、起動時に自動的に読み込まれることが可能である。例えば、構成更新のような、一部の特定の管理メッセージは、ネットワーク全体にわたって既に転送されていることが可能であり、したがって、始動時に自動的に読み込まれることが可能である。
【００７２】
パブリッシュ／サブスクライブ・ミドルウェア・アーキテクチャを有するメッセージング・システムの以上の説明から、メッセージング・アプライアンス（ＭＡ）は、そのようなシステムにおいて相当な役割を有することを理解することができる。したがって、我々は、次に、本発明の諸原理に従って構成されたハードウェア・ベースのメッセージング・アプライアンス（ＭＡ）の詳細を説明することにする。本発明の一実施形態では、ＭＡは、スタンドアロン・アプライアンスである。本発明のさらに別の実施形態では、ＭＡは、ルータまたはスイッチなどの任意のネットワーク物理構成要素内の組み込まれた構成要素（例えば、ラインカード）を定義する。図６ａ、図６ｂ、図６ｃ、図６ｄは、ハードウェア・ベースのＭＡを、様々な詳細の度合いで示すブロック図である。図６ｅは、機能の点からＭＡを示す。
【００７３】
一般に、ＭＡのアーキテクチャは、様々なハードウェア・モジュールが接続された高速相互接続バス上で見られる。図６ａと図６ｂは、高速相互接続バス５０８が、様々なハードウェア・モジュール５０２、５０４、５０６を互いに接続する、エッジＭＡ１０６とコアＭＡ１０８の基本的アーキテクチャを示す。エッジＭＡ（図６ａ、１０６）が、プロトコル変換エンジン（ＰＴＥ）モジュール５１０を有して構成されているのが示されているのに対して、コアＭＡ（図６ｂ、１０８）は、ＰＴＥモジュールなしで構成されているのが示されている。さらに図示されるとおり、一実施形態では、高速相互接続バスは、ハードウェア・モジュールが、ＰＣＩ／ＰＣＩ−Ｘ周辺装置である、ＰＣＩ／ＰＣＩ−Ｘバス・ツリーとして構造化される。ＰＣＩ（ｐｅｒｉｐｈｅｒａｌ  ｃｏｍｐｏｎｅｎｔ  ｉｎｔｅｒｃｏｎｎｅｃｔ）は、コンピュータ高速オペレーションのための相互接続システムとして一般的に知られている。ＰＣＩ−Ｘ（ｐｅｒｉｐｈｅｒａｌ  ｃｏｍｐｏｎｅｎｔ  ｉｎｔｅｒｃｏｎｎｅｃｔ  ｅｘｔｅｎｄｅｄ）は、より高速のコンピュータ・オペレーションのためのコンピュータ・バス技術（コンピュータの部品間の「データ・パイプ」）である。代替の諸実施形態では、高速相互接続バスは、Ｉｎｆｉｎｉｂａｎｄまたは直接メモリ接続媒体として構造化される。さらに別の実施形態では、ハードウェア・モジュールは、ＡＴＣＡ（Ａｄｖａｎｃｅｄ  Ｔｅｌｅｃｏｍ  Ｃｏｍｐｕｔｉｎｇ  Ａｒｃｈｉｔｅｃｔｕｒｅ）などの、交換ファブリック・バックプレーンを介して接続されたブレードである。
【００７４】
各ＭＡの様々なハードウェア・モジュールは、基本的に３つのグループ、制御プレーン・モジュールのグループ５０２、データ・プレーン・モジュールのグループ５０４、サービス・プレーン・モジュール５０６のグループに分割される。制御プレーン・モジュールのグループは、構成と監視を含むＭＡ管理機能を扱う。ＭＡ管理機能の例には、ネットワーク管理サービスの構成、高速相互接続バスに接続されたハードウェア・モジュールの構成、それらのハードウェア・モジュールの監視が含まれる。データ・プレーン・モジュールのグループは、データ・メッセージ・ルーティング機能とメッセージ転送機能を扱う。このモジュール・グループは、パブリッシュ／サブスクライブ・ミドルウェア・システムによってトランスポートされるメッセージを扱い、かつ管理メッセージを扱うが、管理メッセージは、制御プレーン・モジュール・グループにも伝送される。サービス・プレーン・モジュールのグループは、制御プレーン・モジュールとデータ・プレーン・モジュールによってシームレスに使用されることが可能な、その他のローカル・サービスを扱う。一実施形態では、ローカル・サービスは、ＧＰＳカード、または定期的にマイクロ秒の細分性の信号を受信する任意の外部で同期されるデバイスを使用して提供される待ち時間測定に関する時刻同期サービスであることが可能である。この３つのモジュール・グループを、図６ｃ、図６ａ、図６ｂに関連して以下にさらに詳細に説明する。
【００７５】
制御プレーン・モジュール５０２のグループは、管理モジュール５１２を含む。通常、管理モジュールは、Ｌｉｎｕｘ、Ｓｏｌａｒｉｓ、Ｗｉｎｄｏｗｓ（登録商標）、または他の任意のＯＳなどのオペレーティング・システム（ＯＳ）を実行する１つまたは複数のＣＰＵを組み込む。代替として、管理モジュールは、高速相互接続シャーシの中に設置されたブレード（サーバ）に１つまたは複数のＣＰＵを組み込む。さらに別の構成では、管理モジュールは、高性能のラック・マウント型ホスト・サーバにおいて実行される１つまたは複数のＣＰＵを組み込む。
【００７６】
加えて、管理モジュール５１２は、１つまたは複数の論理構成パスを含む。第１の構成パスは、システム管理者が、構成コマンドを入力することができるシリアル・インタフェースまたはネットワーク接続を介するコマンド・ライン・インタフェース（ＣＬＩ）を介して、確立される。ＣＬＩを介する論理構成パスは、ＭＡが、Ｐ＆Ｍシステムに対する接続を確立することを可能にする初期構成情報をＭＡに提供するために、通常、確立される。そのような初期構成は、ローカル管理ＩＰアドレス、デフォルト・ゲートウェイ、ＭＡが接続されるＰ＆ＭシステムのＩＰアドレスなどの、ただし、以上には限定されない情報を提供する。起動プロセスの一環として、この構成のすべて、またはサブセットが、ＭＡにおける様々なハードウェア構成要素を初期設定するのに使用されることが可能である。
【００７７】
第２の構成パスは、パブリッシュ／サブスクライブ・ミドルウェア・システムを介してルーティングされる管理メッセージによって確立される。ＭＡは、Ｐ＆ＭシステムまたはＰ＆Ｍシステム群に対する接続を有するとすぐに、少なくとも１つのＰ＆Ｍシステムに登録し、そのＭＡの構成を取り出す。その構成は、管理モジュール５１２にローカルで伝送される管理メッセージを介してＭＡに送信される。
【００７８】
Ｐ＆Ｍシステムから取り出されたＭＡ構成情報は、パラメータ、アドレスなどを含む。ＭＡ構成が含む可能性がある情報の例には、Ｓｙｓｌｏｇ構成パラメータ、ネットワーク・タイム・プロトコル（ＮＴＰ）構成パラメータ、ドメイン・ネーム・サーバ（ＤＮＳ）情報、ＳＳＨ／Ｔｅｌｎｅｔおよび／またはＨＴＴＰ／ＨＴＴＰＳを介するリモート・アクセス・ポリシー、認証方法（Ｒａｄｉｕｓ／Ｔａｃａｃｓ）、パブリッシュ／サブスクライブ資格、近隣のＭＡまたはＡＰＩに対する接続を示すＭＡルーティング情報、その他が含まれる。
【００７９】
ＭＡ構成全体を、管理モジュールに関連する１つのメモリ・リソース、またはメモリ・リソースの組合せの中に、管理モジュール上でキャッシュすることができる。ＭＡ構成は、例えば、管理モジュールにおけるメモリ空間の中に、揮発性ストレージ領域（ルート・ファイル・システムのために使用されるＲＭＡディスクなどの）の中に、不揮発性ストレージ領域（メモリ・フラッシュ・カードまたはハードドライブなどの）の中に、または以上の任意の組合せの中にキャッシュされる。再ブートの後に永続する場合、このキャッシュされた構成は、始動時にＭＡによって読み込まれることが可能である。
【００８０】
１つの実装では、キャッシュされる構成は、Ｐ＆Ｍシステムによって提供される構成識別子（ＩＤ）も含む。この構成ＩＤは、比較のために使用される。ただし、ＭＡ上にローカルでキャッシュされたＭＡ構成ＩＤは、Ｐ＆Ｍシステム上に現在、存在するＭＡ構成ＩＤと比較される。ＭＡとＰ＆Ｍの両方における構成ＩＤが同一である場合、ＭＡは、構成転送段階をとばして、ローカルでキャッシュされた構成を適用することができる。また、Ｐ＆Ｍシステムと連絡をとることができない場合、ＭＡは、全く構成なしに始動を行うのではなく、その構成が、最新の構成であるか否かにかかわらず、前回の既知の構成に、戻ることができる。
【００８１】
ＭＡが、立ち上って機能していると、制御プレーン・モジュール・グループ（管理モジュール１５２）は、ＭＡのハードウェア・モジュール内の様々な論理構成要素に関連する健全性、およびステータス変化（ステータス変化イベント）の兆候を監視する。例えば、ステータス変化イベントは、ＡＰＩ登録、ＭＡ登録を示すことが可能であり、あるいはサブスクライブ／アンサブスクライブ・イベントであることが可能である。以上、およびその他のステータス変化イベントは、生成され、ある期間にわたってＭＡにおいてローカルで格納される。ＭＡは、それらのイベントをシステム監視ツールに報告する。
【００８２】
ＭＡは、簡易ネットワーク管理プロトコル（ＳＮＭＰ）を介して、またはＭＡからＰ＆Ｍにストリーミングされる生の統計データを追跡するＰ＆Ｍリアルタイム監視モジュールおよび／または履歴トレンディングＵＩ（ユーザ・インタフェース）モジュールを介して、リモートで監視される。その生の統計データは、生成される監視トラフィックの量を減らすために、期間ごとにバッチ処理されるる。代替として、その生の統計データは、期間ごとに集約されて、処理される（例えば、計算を介して）。
【００８３】
ＭＡの制御プレーン・モジュールは、新たなファームウェア・バージョン、または古いファームウェア・バージョンを特定のハードウェア・モジュール上にロードすることも担う。１つの実例では、ファームウェア・イメージは、更新を介してＭＡにオーバーザワイヤで提供される。それらのメンテナンス枠中、新たなファームウェア・イメージはまず、Ｐ＆ＭシステムからＭＡにダウンロードされる。ファームウェア・イメージの受信と検証の後、ＭＡは、そのイメージをターゲット・ハードウェア・モジュール上にアップロードする。アップグレードが完了すると、ハードウェア・モジュールは、アップグレードが有効になるのに、再起動されなければならないであろう。ソフトウェア・イメージを検証するいくつかのやり方が存在し、そのやり方の１つは、埋め込まれた署名を含む。例えば、ＭＡは、イメージに、システム・ベンダによって、または許可されたライセンシーまたは加入者（例えば、Ｔｅｒｖｅｌａ（商標）技術のＴｅｒｖｅｌａライセンシーまたは任意のライセンシー）の一方によって署名が行われているかどうかをチェックする。
【００８４】
好ましくは、システム管理メッセージのトラフィックは、専用の物理インタフェースを介してルーティングされる。このアプローチは、管理メッセージ・トラフィックとデータ・メッセージ・トラフィックに関して異なる仮想ＬＡＮ（ＶＬＡＮ）を作成することを可能にする。これは、特定の物理インタフェースに接続されたスイッチ・ポートを、すべてのシステム管理メッセージ・トラフィックに関するＶＬＡＮに、そのインタフェースを専用にするように構成することによって行われる。次に、残りの物理インタフェースのすべて、またはサブセットが、データ・メッセージに関するＶＬＡＮに専用にされる。基礎をなすネットワーク・ファブリックにおける様々なタイプのトラフィックを区別し、分離することにより、各タイプのメッセージ・トラフィックのパフォーマンスを独立に管理することが、より容易になる。
【００８５】
制御プレーン・モジュール・グループの別の機能は、サブスクリプション・テーブルのステータス、およびＭＡとＡＰＩの間のメッセージ・トランスポート・チャネルに関する統計を監視する機能である。この情報に基づき、ＭＡにおけるプロトコル最適化サービス（ＰＯＳ）は、例えば、ユニキャスト・チャネルからマルチキャスト・チャネルに、またはその逆に切り替えるか否かについての決定を行うことができる。同様に、遅いコンシューマが発見されたケースでは、ＰＯＳは、マルチキャスト・チャネルのオペレーション上の完全性を保つために、その遅いコンシューマをマルチキャスト・チャネルからユニキャスト・チャネルに移すか否かを決定することができる。
【００８６】
データ・プレーン・モジュールの前述したグループ（図６ａ、図６ｂの５０２）は、高速イーサネット、ギガビット・イーサネット、１０ギガビット・イーサネット、ギガビット速度メモリ相互接続などの、１つまたは複数の物理インタフェース・カード（ＰＩＣ、図６ａ〜図６ｃ、５１４）を含む。それらのデータ・プレーンＰＩＣは、１つまたは複数のメッセージ・プロセッサ・ユニット（ＭＰＵ）によって論理的に制御される。ＭＰＵは、ネットワーク・プロセッサ・ユニット５１６、ＦＰＧＡ、ＭＩＰＳベースのネットワーク処理カード、カスタムＡＳＩＣ、または任意のプラットフォーム上の組み込まれたソリューションとして実施される。
【００８７】
ＰＩＣ５１４は、１つまたは複数のメッセージを含むフレームを扱う。フレームは、媒体固有の処理を制御する１つまたは複数のチップセットを含むイングレスＰＩＣを介してＭＡに入る。一構成では、ＰＩＣは、ＴＣＰ終端またはＵＤＰ終端などの、チャネル・トランスポート固有の終端に対応する、ＯＳＩレイヤ４終端をさらに担う。その結果、ＰＩＣからＭＰＵに転送されるデータは、着信フレームからのメッセージのストリームだけを含むことが可能である。別の構成では、ＰＩＣは、ＭＰＵ上で実行されるチャネル・エンジン５２０にネットワーク・パケットを送信する。チャネル・エンジンは、ＯＳＩレイヤ３−レイヤ４処理を実行してから、ネットワーク・パケットの中に含まれるメッセージを送る。
【００８８】
さらに別の構成では、ＰＩＣ５１４は、チャネル固有のトランスポート・プロトコルを使用して、メッセージをチャネル・エンジン５２０に転送するメモリ相互接続インタフェースである。そのケースでは、チャネル・エンジンは、メッセージを解析して、着信データから抽出するチャネル固有の処理アダプタを有する。
【００８９】
ＰＩＣは、さらに別の構成では、メッセージ・フレームの高速転送を、それらのフレームを、メッセージ・ルーティング・エンジン５１８によってルーティングされるようにＰＭＵに送るのではなく、実行する専用のチップセットや、オンボード・メモリを有することが可能である。そのような高速転送アプローチを実施するため、グローバル・ルーティング（サブスクリプション）テーブルが、全体として、または、好ましくは、部分的に、ＰＭＵから、ＰＩＣにおける転送キャッシュに配信される。そのルーティング・テーブルが、転送キャッシュの中にある状態で、イングレスＰＩＣは、着信メッセージ・フレームを検査して、それらのフレームの中で、１つまたは複数のトピック、またはトピックの任意のサブセットを識別し、そのようなトピックに基づき、それらのフレームをイグレスＰＩＣに直接に転送することができる。ＰＩＣの転送キャッシュに配信されるサブスクリプション・テーブルが、グローバル・サブスクリプション・テーブルのサブセットに過ぎない場合、引き出される利点は、より迅速なルーティング・ルックアップであり、その結果、より迅速なメッセージ転送であることに留意されたい。
【００９０】
前述したＭＰＵ５１６は、ＭＰＵ５１６のチャネル・エンジン５２０を介して、ＰＩＣとメッセージ・ルーティング・エンジン５１８の間の通信インタフェースを管理することを担う。ＭＰＵは、ＭＰＵのメッセージ・ルーティング・エンジン５１８を介して、サブスクリプション・テーブルを保持し、着信メッセージをサブスクリプションとチャネルにマッチさせることをさらに担う。以上のファンクションは、いくつかの形で実現されることが可能であり、それらの形の１つでは、それらのファンクションは、様々なマイクロ−エンジンまたはマイクロチップの上で実行されるように構成され、それらの形の別の形では、それらのファンクションは、別々のＣＰＵコア上で実行されるように構成される。第２のケースでは、各コアは、標準のネットワーク・スタック、またはカスタム・ネットワーク・スタックを使用する。さらに別の実装では、それらのファンクションは、リアルタイムＯＳの上のマルチコアＣＰＵ上で実行されるように構成される。
【００９１】
また、好ましいＭＰＵは、組み込まれた媒体スイッチ・ファブリック５２２も有する。メッセージ・トランスポート・チャネルは、ファブリックにこだわらないため、ＭＰＵは、任意のタイプの物理媒体５２４とインタフェースをとることができる。ＰＩＣから転送されるメッセージ、およびオプションとして、媒体スイッチ・ファブリックから転送されるメッセージは、チャネル・エンジン５２０によって受信され、その後、メッセージ・ルーティング・エンジン５１８に転送される。
【００９２】
チャネル・エンジン５２０は、メッセージ・トランスポート・チャネル・キューを管理する。図６ｄは、一時メッセージ・キャッシュ５２４を使用したメッセージ・キューイング、およびチャネル・エンジン５２０を使用したメッセージ転送を示す。
【００９３】
受信側で、メッセージは、チャネル・キューから取り出される。一部の実例では、メッセージ・トランスポート・チャネルは、特別な優先順位を有することが可能である。メッセージ・トランスポート・チャネル優先順位付けは、複数のチャネルが、待ち状態のメッセージを有する場合に役立つ。例えば、メッセージ再送要求は、最初に転送されなければならず、このため、再送要求のために異なるチャネルを作成することが、理にかなっているであろう。再送要求を遅延させることは、より多くの再送要求をもたらすことがあり、これは、ブロードキャスト／マルチキャスト・ストームで、通常、生じる。
【００９４】
エッジＭＡ１０８に関して、チャネル・エンジン５２０におけるプロトコル・スイッチ５２６は、メッセージが、プロトコル変換を要求するかどうかをチェックする。変換が必要な場合、メッセージは、プロトコル変換エンジン５１０に送信される。メッセージが、プロトコル変換エンジンによってネイティブ・プロトコル（例えば、Ｔｅｒｖｅｌａ（商標）プロトコル）フォーマットに変換されると、メッセージは、キャッシング構成要素５２８に転送される。キャッシング構成要素は、メッセージを一時メッセージ・キャッシュ５２４の中に入れ、キャッシュ５２４の中で、メッセージは、再送のために一時的に利用可能である。メッセージは、メッセージの期間が経過した後、削除され、または別のメッセージによって上書きされる。一構成では、一時メッセージ・キャッシュは、メッセージ・ルーティング・エンジン５１８と共有される単純なメモリ・リング・バッファとして実装される。好ましくは、一時メッセージ・キャッシュ・ルックアップは、例えば、メッセージ・シリアル番号を、キャッシュの中の実際のメッセージにマップする索引を保持することにより、再送プロセスを速めるために、最適化される。メッセージ・ルーティング・エンジン５１８は、一時メッセージ・キャッシュ５２４からメッセージを取り込み、サブスクリプション・ルックアップを実行し、そのメッセージのコピーを転送するためのチャネルのリストを戻す。
【００９５】
管理メッセージの一部は、共有バス５０８（図６ａ、図６ｂ、図６ｃ）を介して管理モジュール５１２にローカルで伝送されなければならないことがある。ローカルで伝送されるメッセージは、パブリッシュ／サブスクライブ・ミドルウェア・システム全体にわたって転送されることもある。１つの実装では、メッセージ・ルーティング・エンジン５１８は、メッセージのコピーを、各チャネルのキュー上にプッシュする。別の実装では、メッセージ・ルーティング・エンジン５１８は、メッセージに対するリファレンスまたはポインタだけをキューに入れ、ただし、メッセージ自体は、一時メッセージ・キャッシュの中に留まる。このアプローチは、複数のキューが、同一のメッセージを参照することが可能であるので、ＭＰＵ上のメモリ使用を最適化するという利点を有する。また、メッセージ・ルーティング・エンジン５１８は、サブスクリプション・メッセージ・キュー５３２の中で、メッセージにリファレンス（例えば、ポインタ）を付加することができ、ただし、サブスクリプションＳ１、Ｓ２に関するサブスクリプション・キューは、一時メッセージ・キャッシュ５２４の中のメッセージをポイントする。
【００９６】
次に、各チャネルは、そのチャネルに関連付けられたすべてのサブスクリプションへの参照のリストを保持する。このアプローチは、単にチャネル・レベルのメッセージ処理ではなく、サブスクリプション・レベルのメッセージ処理を可能にするという利点を有する。事実上、それらのサブスクリプション・キューは、サブスクリプションごとにだけでなく、チャネルごとにもメッセージに索引付けを行う方法をもたらし、このため、メッセージが、所与のサブスクリプションに関して処理される必要がある場合に、ルックアップ時間を短縮する。例えば、一実施形態では、リアルタイム構成ロジックが、サブスクリプションごとに使用される。また、これにより、ＭＰＵが、付加価値計算、例えば、株式市場取引値メッセージに関するボリューム加重平均価格（ＶＷＡＰ）計算を実行することも可能になる。
【００９７】
送信側で、メッセージ・ルーティング・エンジン５１８は、待ち状態のキューに入れられたメッセージを有するチャネルにマークを付け、またはフラグを付ける。これにより、チャネル・スケジューラ５３０が、いずれのチャネルまたはチャネル群が、注意を要する、または特別な優先順位を有するかを知ることが可能になる。チャネル優先順位は、サービス品質（ＱｏＳ）機能を提供するようにシャッフルされる。例えば、ＱｏＳ機能は、メッセージ・ヘッダ・フィールドだけに基づいて、またはメッセージ・トピックと組合せで実施される。その時点で、メッセージ・ルーティング・エンジン５１８は、メッセージ・キャッシュ・リング・バッファの中の次のメッセージに移る。
【００９８】
チャネル・スケジューラ５３０は、キューに入れられたメッセージを有するすべてのチャネルを調べて、チャネル固有の通信ポリシーを使用して、待ち状態のメッセージを転送する。ポリシーは、いずれのタイプの伝送プロトコルが使用されるか、ユニキャスト、マルチキャスト、またはその他を決定する。通信ポリシーは、チャネルが作成される際に、ネゴシエートされることが可能であり、あるいはネットワーク帯域幅利用率、メッセージ、パケット遅延、ジッタ、損失などのリソース利用パターンに基づき、リアルタイムで更新されることが可能である。チャネル固有の通信ポリシーは、近隣のＭＡまたはＡＰＩなどの、１つまたは複数のチャネル宛先とネゴシエートされるメッセージ・フロー制御パラメータにさらに基づくことが可能である。例えば、すべてのメッセージを送信する代わりに、通信ポリシーは、Ｎ個のメッセージの中から１つのメッセージをドロップすることが可能である。このため、そのポリシーに関連する一態様は、メッセージ・フロー制御である。
【００９９】
図７は、リアルタイムのメッセージ・フロー制御（ＭＦＣ）アルゴリズムの効果を示す。そのアルゴリズムによれば、チャネル・キューのサイズは、閾値パラメータとして動作することが可能である。例えば、ある特定のチャネルを介して伝送されるメッセージが、受信アプライアンス側でチャネル・キューの中に蓄積し、そのチャネル・キューが成長するにつれ、キューのサイズは、チャネルが、場合により、着信メッセージのフローについて行くことができなくなることなしに、キューが安全に超えることができない、高い閾値に達する可能性がある。チャネルが、チャネルの最大容量に達する危険性がある、その状況に近づくと、受信側メッセージング・アプライアンスは、チャネル・キューがあふれる前に、ＭＦＣを起動することができる。ＭＦＣは、キューが縮小して、キューのサイズが、低い閾値より小さくなると、オフにされる。高い閾値と低い閾値の差は、このいわゆるヒステリシスの振る舞いを生じさせるのに十分であるように設定され、ただし、ＭＦＣは、ＭＦＣがオフにされるキュー・サイズ値より高いキュー・サイズ値でオンにされる。この閾値差により、さもなければ、キュー・サイズが、高い閾値を挟んで上下するにつれて生じることになる、メッセージ・フロー制御の頻繁なオン−オフの変動が回避される。このため、メッセージング受信機側でキューがあふれるのを回避するのに、着信メッセージのレートは、そのレートを最大チャネル容量未満に保つ、リアルタイムの動的なＭＦＣを使用して抑制されることが可能である。
【０１００】
チャネル・キューが、キューの容量に近づくと、メッセージがドロップされるヒステリシス・ベースのＭＦＣアルゴリズムの代替として、リアルタイムの動的なＭＦＣは、データを混合するように、またはサブスクリプション・キュー上で何らかの融合アルゴリズムを適用するように動作することが可能である。しかし、このオペレーションは、さらなるメッセージ変換を要求する可能性があるため、高速の転送パス上に留まるのではなく、遅い転送パスに戻る可能性がある。これにより、メッセージ変換が、メッセージング・スループットに悪影響を及ぼすことが防止される。このさらなるメッセージ変換は、プロトコル変換エンジンと同様のプロセッサによって実行される。そのようなプロセッサの例には、ＮＰＵ（ネットワーク処理ユニット）、セマンティック・プロセッサ、ＭＰＵ上の別個のマイクロ−エンジンなどが含まれる。
【０１０１】
より高い効率のため、リアルタイムの融合またはサブスクリプション・レベルのメッセージ処理は、送信側と受信側の間で分散されることが可能である。例えば、サブスクリプション・レベルのメッセージ処理が、１つだけのサブスクライバによって要求されたケースでは、その処理を、送信側で実行するのではなく、下流に、受信側にプッシュする方が、理にかなう。しかし、データの複数のコンシューマが、同一のサブスクリプション・レベルのメッセージ処理を要求している場合、その処理を上流で、送信側で実行する方が、理にかなう。チャネルの送信側と受信側で作業負荷を分散させることの目的は、利用可能な組み合わされた処理リソースを最適に使用することである。
【０１０２】
トランスポート・チャネル自体は、トランスポート固有の処理を扱う。この処理は、受信側におけるのと同様に、システム・オン・チップを有するＭＰＵ上、またはＰＩＣ上で行われる。チャネルは、複数のメッセージを単一のフレームの中にパックする際、メッセージ待ち時間を最大の許容可能な待ち時間未満に抑えることができ、いくつかの処理リソースを解放することにより、受信側のストレスを和らげる。時として、多くの小さいフレームを処理するより、より少ない大きいフレームを受信する方が、より効率的である。このことは、ＣＰＵ、メモリ、ＮＩＣを含む、一般的なコンピュータ・ハードウェア構成要素を使用して、通常のＯＳ上で実行される可能性のあるＡＰＩに関して、特によく当てはまる。通常のＮＩＣは、受信される各フレームに対してＯＳ割り込みを生成するように設計され、これにより、ＡＰＩが、サブスクライブするアプリケーションにメッセージを伝送するのに利用できるアプリケーション・レベル処理時間が少なくなる。
【０１０３】
前述したとおり、エッジＭＡだけが、プロトコル変換エンジン（ＰＴＥ）を有する。エッジＭＡでは、データ・プレーン・モジュールが、着信メッセージをＰＴＥ５１０（図６ａ、図６ｃ、図６ｄ）に着信メッセージを転送することができる。この転送決定は、チャネル・エンジン５２０の一部として実行されるプロトコル・スイッチ５２６によってＭＰＵ５１２で行われる。着信メッセージ・プロトコルまたは送信メッセージ・プロトコルが、ネイティブ・メッセージ・プロトコルとは異なる場合、そのメッセージは、ＰＴＥに転送される。
【０１０４】
ＰＴＥは、例えば、セマンティック・プロセッサ、ＦＰＧＡ、ＮＰＵ、あるいはネットワーク指向のシステム・オン・チップ・プロセッサ上、またはＭＩＰＳベースのプロセッサ上で実行されるリアルタイムの組み込み型ＯＳの下で実行される組み込み型ソフトウェア・モジュールを使用することを含め、ハードウェアとソフトウェアを任意の組合せで使用して、いくつかの形で実施されることが可能である。図６ｃの例に示されるとおり、ＰＴＥは、メッセージ解析エンジン、メッセージ規則ルックアップ・エンジン、メッセージ規則適用エンジン、メッセージ・フォーマット・エンジンを含む、パイプライン型のタスク指向のマイクロエンジン群を有する。そのようなハードウェア・モジュールを構築する際のアーキテクチャ上の制約は、プロトコル間で複数の複雑な文法変換を可能にしながら、メッセージ変換待ち時間を少なく保つことである。別の制約は、プロトコル変換構文（文法）のファームウェア・アップグレードを、非常に柔軟性があり、基礎をなすハードウェアとは独立であるようにすることである。
【０１０５】
最初に、パイプラインにおいて、メッセージ解析エンジン５４０が、ＰＴＥイングレス・キュー５４８から出されたメッセージを取り込み、次に、そのメッセージを解析し、識別し、トークン化する。メッセージ解析エンジンは、その結果をメッセージ規則ルックアップ・エンジン５４２に転送する。メッセージ規則ルックアップ・エンジンは、メッセージ内容に基づいて規則ルックアップを実行し、適用される必要がある、合致する規則を取得する。メッセージ内容と合致する規則は、次に、メッセージ規則適用エンジン５４４に送られる。規則適用エンジンは、合致する規則に従ってメッセージのトークンを変換し、もたらされたトークン化されたメッセージが、メッセージ・フォーマット・エンジン５４６に転送される。メッセージ・フォーマット・エンジンは、ネイティブまたは外部のメッセージ・プロトコルに従ってメッセージ本文とヘッダを再構築して、ＰＴＥイグレス・キュー５５０に送り返す。処理された（変換された）メッセージは、共有バス５０８上でチャネル・エンジン５２０に送り返される。
【０１０６】
図６ａ、図６ｂに示されるとおり、各ＭＡの様々なハードウェア・モジュールは、基本的に３つのグループに分けられ、それらのグループのうち、前述した制御プレーン・モジュール・グループ５０２とデータ・プレーン・モジュール・グループ５０４が、サービス・プレーン・モジュール・グループ５０６とインタフェースをとり、サービス・プレーン・モジュール・グループ５０６によって提供されるサービスを使用する。この目的のために、サービス・プレーン・モジュール・グループは、制御プレーン・モジュール・グループとデータ・プレーン・モジュール・グループの両方によって使用されるためのサービス・モジュールの集合を含む。サービス・モジュールの例は、ＧＰＳ（グローバル・ポジショニング・システム）カードなどの、外部時刻源である。このサービス・モジュールを、他の任意のハードウェア・モジュールは、正確なタイムスタンプを獲得するのに使用できる。例えば、データ・プレーン経由でルーティングされる各フレームと各メッセージがＭＡに入る際、および／またはＭＡを出る際に、そのメッセージにスタンプが付けられる。この埋め込まれたタイムスタンプ情報は、後に、待ち時間測定を実行するのに使用できる。
【０１０７】
その結果、外部待ち時間計算は、例えば、データ・ストリームからの埋め込まれたタイムスタンプを、フレームがＭＡに入った際の測定されたタイムスタンプと互いに関係付けることを含む。次に、時とともに、この外部待ち時間を追跡することにより、ＭＡは、待ち時間トレンドを確立し、外部待ち時間の任意のドリフトを検出することができるとともに、その情報をデータ・ストリームの中に再び埋め込むことができる。その待ち時間ドリフトは、その後、メッセージング・パス上の下流のノードによって、またはサブスクライブするアプリケーションによって、ビジネス・レベルの決定を行い、競争上の優位を得るのに使用されることが可能である。
【０１０８】
待ち時間統計や、その他のメッセージング・システム統計を追跡するため、ＭＡは、１つまたは複数のストレージ・デバイスを有する。ストレージ・デバイスは、様々なハードウェア構成要素、ネットワーキングとメッセージング・トラフィックのプロファイル、その他から獲得された統計データなどの、一時データを保持する。１つの実装では、１つまたは複数のストレージ・デバイスは、ＭＡ始動（起動または再起動）のための初期設定データを保持するフラッシュメモリ・デバイスを含む。この目的のために、この不揮発性メモリ・デバイスは、管理モジュールの起動オペレーションのために必要なカーネルとルート・ラムディスクを含み、好ましくは、デフォルトの始動構成と実行構成も含む。
【０１０９】
この不揮発性メモリは、メッセージのセキュリティで保護された伝送を管理するための暗号化キー、デジタル署名、証明書をさらに保持することが可能である。一実施例では、ＳＳＬ（セキュア・ソケット・レイヤ）プロトコルが、公開キーと秘密キー（非対称）暗号化システムを使用し、このシステムは、デジタル証明書の使用も含む。同様に、ＰＫＩ（公開キー・インフラストラクチャ）は、インターネットなどの公共ネットワークのユーザが、信頼される機関を介して獲得され、共有される公開暗号キーと秘密暗号キーのペアの使用を介して、データを、セキュリティで保護された、プライベートな形で交換することができるようにもする。
【０１１０】
ハードウェア・モジュールは、図６ｅに示されるとおり、それらのモジュールが提供する機能の点で説明されることが可能である。メッセージング・アプライアンスの機能的態様のなかには、ネットワーク管理スタック６０２、物理インタフェース管理６０６、システム管理サービス６１４、タイムスタンピング・サービス６２４、メッセージング・レイヤ６０８があり、エッジ・メッセージング・アプライアンスにおいて、プロトコル変換エンジン６１８がある。以上の機能的態様は、以下に説明するハードウェア・モジュールと再び関連する。
【０１１１】
例えば、ネットワーク管理スタック（６０２）は管理モジュール（５１２）上で実行される。ＴＣＰ／ＵＤＰ／ＩＰスタック（６０４）は管理モジュールのＣＰＵ上で実行されるオペレーティング・システムの一部である。ＮＴＰサービス、ＳＮＭＰサービス、Ｓｙｓｌｏｇサービス、ＨＴＴＰ／ＨＴＴＰＳＷｅｂサーバ・サービス、Ｔｅｌｎｅｔ／ＳＳＨ  ＣＬＩサービスは、ＯＳの上で実行される標準のネットワーク・サービスである。
【０１１２】
また、システム管理サービス（６１４）も、同様に、管理モジュール（５１２）上で実行される。以上のシステム管理サービスは、システムの構成と監視を含む、ネットワーク管理スタックとメッセージング構成要素の間のインタフェースを管理する。
【０１１３】
タイムスタンピング・サービス（６２４）は、複数のハードウェア構成要素に分散されることが可能である。正確なタイムスタンプを要求する任意のハードウェア構成要素（管理モジュールを含め）は、サービス・プレーン・ハードウェア・モジュール時刻源とインタフェースをとるタイムスタンピング・サービスを含む。
【０１１４】
バス６１６ａとバス６１６ｂは論理バスであり、ハードウェア・モジュール群またはソフトウェア・モジュール群を接続するハードウェア・バスまたはソフトウェア・バスとは異なり、論理／機能モジュール群を接続する。
【０１１５】
ＴＶＡメッセージ・レイヤ（６１０）は、管理モジュールと、メッセージ処理ユニット（５１６）上で実行されるメッセージ・ルーティング・エンジン（５１８）との間で分散される。管理メッセージは、管理モジュール（５１２）上で実行される管理メッセージ・エンジンにローカルで配信される。メッセージ・ルーティング・エンジン（６２０）は、メッセージ処理ユニット（５１６）上のメッセージ・ルーティング・エンジン・マイクロ−エンジン上で実行される。メッセージング・トランスポート・レイヤ（６１２）は、チャネル・エンジン・マイクロ−エンジン（５２０）上で主に実行される。一部のケースでは、チャネル・トランスポート・ロジックの一部は、何らかのトランスポート認識型のＰＩＣ５１４ａ〜ｄ上で実施される。本発明の一実施形態では、このトランスポート認識型のＰＩＣは、ＴＣＰ終端を実行するＴＣＰオフロード・エンジン・インタフェースであることが可能である。その結果、チャネル・トランスポート・ロジックの一部は、チャネル・エンジン上で実行されるのではなく、ＰＩＣ上で実行される。メッセージＲｘとメッセージＴｘは、チャネル・エンジンとメッセージ・ルーティング・エンジンの間で配信される。というのは、２つのマイクロ−エンジンが、互いに通信しているからである。プロトコル変換エンジン（６１８）は、エッジＭＡに関するオプションのＰＴＥ（５１０）によって代表される。
【０１１６】
要するに、本発明は、メッセージングの新たなアプローチを提供し、より具体的には、メッセージング・システムの有効性を向上させるのに重要な役割を有するハードウェア・ベースのメッセージング・アプライアンスを有する、新たなパブリッシュ／サブスクライブ・ミドルウェア・システムを提供する。本発明を、本発明のいくつかの好ましいバージョンに関連してかなり詳細に説明してきたが、その他のバージョンも可能である。したがって、添付の特許請求の範囲の趣旨および範囲は、本明細書に含まれる好ましいバージョンの説明に限定されるべきではない。
【図面の簡単な説明】
【０１１７】
【図１】本発明の諸原理による終端間ミドルウェア・アーキテクチャを示す図である。
【図１ａ】オーバーレイ・ネットワークを示す図である。
【図２】本発明の諸原理による終端間ミドルウェア・アーキテクチャで実施される企業インフラストラクチャを示す図である。
【図２ａ】ネットワーク・バックボーン・ディスインターメディエーションを作成するＭＡ群（メッセージアプライアンス群）を有する、企業インフラストラクチャの物理的展開を示す図である。
【図３】チャネル・ベースのメッセージング・システム・アーキテクチャを示す図である。
【図４ａ】１つの可能なトピック・ベースのメッセージ・フォーマットを示す図である。
【図４ｂ】１つの可能なトピック・ベースのメッセージ・フォーマットを示す図である。
【図５】トピック・ベースのメッセージ・ルーティングおよびルーティング・テーブルを示す図である。
【図６ａ】ハードウェア・ベースのメッセージング・アプライアンスの様々な態様の図である。
【図６ｂ】ハードウェア・ベースのメッセージング・アプライアンスの様々な態様の図である。
【図６ｃ】ハードウェア・ベースのメッセージング・アプライアンスの様々な態様の図である。
【図６ｄ】ハードウェア・ベースのメッセージング・アプライアンスの様々な態様の図である。
【図６ｅ】ハードウェア・ベースのメッセージング・アプライアンスの機能上の態様を示す図である。
【図７】適応型メッセージ・フロー制御の影響を示す図である。
【図１】
2008527848.tif 000003
【図１ａ】
2008527848.tif 000004
【図２】
2008527848.tif 000005
【図２ａ】
2008527848.tif 000006
【図３】
2008527848.tif 000007
【図４ａ】
2008527848.tif 000008
【図４ｂ】
2008527848.tif 000009
【図５】
2008527848.tif 000010
【図６ａ】
2008527848.tif 000011
【図６ｂ】
2008527848.tif 000012
【図６ｃ】
2008527848.tif 000013
【図６ｄ】
2008527848.tif 000014
【図６ｅ】
2008527848.tif 000015
【図７】
2008527848.tif 000016
【手続補正書】
【提出日】平成19年7月9日(2007.7.9)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】００３０
【補正方法】変更
【補正の内容】
【００３０】
第３の論理機能は、例えば、接続中保証タイプや切断中保証タイプを含め、様々なタイプの保証配信サービス品質のためにメッセージを格納することである。これは蓄積転送機能の追加で達成される。第４の機能は、サブスクライバに、それらのメッセージを配信することである（図示されるとおり、ＡＰＩ １１０ａ〜ｂは、サブスクライブするアプリケーション１１２1〜nにメッセージを配信する）。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００４３
【補正方法】変更
【補正の内容】
【００４３】
ＭＡで「登録」（ログイン）することにより、ＡＰＩは、そのＭＡに論理的に接続されるようになることに留意されたい。ＡＰＩは、登録（「ログイン」要求）メッセージをＭＡに送信することにより、ＭＡに対する接続を開始する。登録の後、ＡＰＩは、ＡＰＩのサブスクリプション・メッセージをＭＡに送信することにより、関心対象の特定のトピックにサブスクライブする。トピックは、パブリッシュ／サブスクライブ・メッセージングに関して、共有アクセス・ドメインとメッセージに関するターゲットとを定義するのに使用され、したがって、１つまたは複数のトピックへのサブスクリプションにより、そのようなトピック表記を有するメッセージの受信と送信が可能になる。Ｐ＆Ｍは、ネットワークにおけるＭＡに定期資格更新を送信し、各ＭＡは、そのＭＡ独自のテーブルを、それに相応して更新する。したがって、ＡＰＩが、ある特定のトピックにサブスクライブする資格があることが、ＭＡに分かった場合（ＭＡは、ルーティング資格テーブルを使用して、ＡＰＩの資格を検証する）、ＭＡは、そのＡＰＩに対する論理接続をアクティブにする。次に、ＡＰＩが、コアＭＡ１０８ｃに適切に登録されている場合、コアＭＡ１０８ｃは、図示されるとおり、データを第２のＡＰＩ １１０にルーティングする。その他の実例では、そのコアＭＡ１０８ｃは、さらなる１つまたは複数のＭＡ（図示せず）経由でメッセージをルーティングすることができ、それらのＭＡは、それらのメッセージをＡＰＩ １１０ｂにルーティングし、ＡＰＩ １１０ｂは、それらのメッセージを、サブスクライブするアプリケーション１１２1〜nに配信する。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００７４
【補正方法】変更
【補正の内容】
【００７４】
各ＭＡの様々なハードウェア・モジュールは、基本的に３つのグループ、制御プレーン・モジュールのグループ５０４、データ・プレーン・モジュールのグループ５０２、サービス・プレーン・モジュール５０６のグループに分割される。制御プレーン・モジュールのグループは、構成と監視を含むＭＡ管理機能を扱う。ＭＡ管理機能の例には、ネットワーク管理サービスの構成、高速相互接続バスに接続されたハードウェア・モジュールの構成、それらのハードウェア・モジュールの監視が含まれる。データ・プレーン・モジュールのグループは、データ・メッセージ・ルーティング機能とメッセージ転送機能を扱う。このモジュール・グループは、パブリッシュ／サブスクライブ・ミドルウェア・システムによってトランスポートされるメッセージを扱い、かつ管理メッセージを扱うが、管理メッセージは、制御プレーン・モジュール・グループにも伝送される。サービス・プレーン・モジュールのグループは、制御プレーン・モジュールとデータ・プレーン・モジュールによってシームレスに使用されることが可能な、その他のローカル・サービスを扱う。一実施形態では、ローカル・サービスは、ＧＰＳカード、または定期的にマイクロ秒の細分性の信号を受信する任意の外部で同期されるデバイスを使用して提供される待ち時間測定に関する時刻同期サービスであることが可能である。この３つのモジュール・グループを、図６ｃ、図６ａ、図６ｂに関連して以下にさらに詳細に説明する。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００７５
【補正方法】変更
【補正の内容】
【００７５】
制御プレーン・モジュール５０４のグループは、管理モジュール５１２を含む。通常、管理モジュールは、Ｌｉｎｕｘ、Ｓｏｌａｒｉｓ、Ｗｉｎｄｏｗｓ（登録商標）、または他の任意のＯＳなどのオペレーティング・システム（ＯＳ）を実行する１つまたは複数のＣＰＵを組み込む。代替として、管理モジュールは、高速相互接続シャーシの中に設置されたブレード（サーバ）に１つまたは複数のＣＰＵを組み込む。さらに別の構成では、管理モジュールは、高性能のラック・マウント型ホスト・サーバにおいて実行される１つまたは複数のＣＰＵを組み込む。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００８１
【補正方法】変更
【補正の内容】
【００８１】
ＭＡが、立ち上って機能していると、制御プレーン・モジュール・グループ（管理モジュール５２１）は、ＭＡのハードウェア・モジュール内の様々な論理構成要素に関連する健全性、およびステータス変化（ステータス変化イベント）の兆候を監視する。例えば、ステータス変化イベントは、ＡＰＩ登録、ＭＡ登録を示すことが可能であり、あるいはサブスクライブ／アンサブスクライブ・イベントであることが可能である。以上、およびその他のステータス変化イベントは、生成され、ある期間にわたってＭＡにおいてローカルで格納される。ＭＡは、それらのイベントをシステム監視ツールに報告する。
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】００８９
【補正方法】変更
【補正の内容】
【００８９】
ＰＩＣは、さらに別の構成では、メッセージ・フレームの高速転送を、それらのフレームを、メッセージ・ルーティング・エンジン５１８によってルーティングされるようにＰＭＵに送るのではなく、実行する専用のチップセットや、オンボード・メモリを有することが可能である。そのような高速転送アプローチを実施するため、グローバル・ルーティング（サブスクリプション）テーブルが、全体として、または、好ましくは、部分的に、ＭＰＵから、ＰＩＣにおける転送キャッシュに配信される。そのルーティング・テーブルが、転送キャッシュの中にある状態で、イングレスＰＩＣは、着信メッセージ・フレームを検査して、それらのフレームの中で、１つまたは複数のトピック、またはトピックの任意のサブセットを識別し、そのようなトピックに基づき、それらのフレームをイグレスＰＩＣに直接に転送することができる。ＰＩＣの転送キャッシュに配信されるサブスクリプション・テーブルが、グローバル・サブスクリプション・テーブルのサブセットに過ぎない場合、引き出される利点は、より迅速なルーティング・ルックアップであり、その結果、より迅速なメッセージ転送であることに留意されたい。
【手続補正７】
【補正対象書類名】明細書
【補正対象項目名】０１０３
【補正方法】変更
【補正の内容】
【０１０３】
前述したとおり、エッジＭＡだけが、プロトコル変換エンジン（ＰＴＥ）を有する。エッジＭＡでは、データ・プレーン・モジュールが、着信メッセージをＰＴＥ５１０（図６ａ、図６ｃ、図６ｄ）に着信メッセージを転送することができる。この転送決定は、チャネル・エンジン５２０の一部として実行されるプロトコル・スイッチ５２６によってＭＰＵ５１６で行われる。着信メッセージ・プロトコルまたは送信メッセージ・プロトコルが、ネイティブ・メッセージ・プロトコルとは異なる場合、そのメッセージは、ＰＴＥに転送される。
【手続補正８】
【補正対象書類名】明細書
【補正対象項目名】０１０６
【補正方法】変更
【補正の内容】
【０１０６】
図６ａ、図６ｂに示されるとおり、各ＭＡの様々なハードウェア・モジュールは、基本的に３つのグループに分けられ、それらのグループのうち、前述した制御プレーン・モジュール・グループ５０４とデータ・プレーン・モジュール・グループ５０２が、サービス・プレーン・モジュール・グループ５０６とインタフェースをとり、サービス・プレーン・モジュール・グループ５０６によって提供されるサービスを使用する。この目的のために、サービス・プレーン・モジュール・グループは、制御プレーン・モジュール・グループとデータ・プレーン・モジュール・グループの両方によって使用されるためのサービス・モジュールの集合を含む。サービス・モジュールの例は、ＧＰＳ（グローバル・ポジショニング・システム）カードなどの、外部時刻源である。このサービス・モジュールを、他の任意のハードウェア・モジュールは、正確なタイムスタンプを獲得するのに使用できる。例えば、データ・プレーン経由でルーティングされる各フレームと各メッセージがＭＡに入る際、および／またはＭＡを出る際に、そのメッセージにスタンプが付けられる。この埋め込まれたタイムスタンプ情報は、後に、待ち時間測定を実行するのに使用できる。
【手続補正９】
【補正対象書類名】明細書
【補正対象項目名】０１１１
【補正方法】変更
【補正の内容】
【０１１１】
例えば、ネットワーク管理スタック（６０２）は管理モジュール（５１２）上で実行される。ＴＣＰ／ＵＤＰ／ＩＣＭＰ／ＩＰスタック（６０４）は管理モジュールのＣＰＵ上で実行されるオペレーティング・システムの一部である。ＮＴＰサービス、ＳＮＭＰサービス、Ｓｙｓｌｏｇサービス、ＨＴＴＰ／ＨＴＴＰＳＷｅｂサーバ・サービス、Ｔｅｌｎｅｔ／ＳＳＨ  ＣＬＩサービスは、ＯＳの上で実行される標準のネットワーク・サービスである。
【国際調査報告】
2008527848.tif 000017