JP2008527538A - メッセージング・システム内のキャッシング・エンジン - Google Patents

Abstract

より低減された待ち時間、およびパフォーマンスのネックで大きいメッセージ量を処理するメッセージ・パブリッシュ／サブスクライブ・システムが、要求される。本発明によって提案される終端間ミドルウェア・アーキテクチャは、大量の、待ち時間の少ないメッセージング向けに設計され、ストレージおよびストレージ・サービスを有するキャッシング・エンジン（ＣＥ）を使用するデータ・キャッシングを介する保証された配信サービス品質を有する。メッセージングにおいて、メッセージング・アプライアンス（ＭＡ）は、メッセージを受信し、ルーティングするが、まず、コピーをＣＥに送ることによって、ルーティングされるメッセージのすべてまたはサブセットを記録する。次に、所定の期間にわたって、記録されたメッセージが、メッセージング・システム内の任意の構成要素による要求時の再送に使用可能であり、これによって、保証接続および保証切断の配信サービス品質ならびに部分的データ・パブリケーション・サービスが実現される。

Description

関連出願

（先行出願の引用）
本願は、「Ｅｖｅｎｔ Ｒｏｕｔｅｒ Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ」という名称の２００５年１月６日に出願した米国特許仮出願第６０／６４１９８８号、および「Ｈｙｂｒｉｄ Ｆｅｅｄ Ｈａｎｄｌｅｒｓ Ａｎｄ Ｌａｔｅｎｃｙ Ｍｅａｓｕｒｅｍｅｎｔ」という名称の２００５年６月８日に出願した米国特許仮出願第６０／６８８９８３号の利益を主張し、以上の仮出願を参照により組み込む。

本願は、「Ｅｎｄ−Ｔｏ−Ｅｎｄ Ｐｕｂｌｉｓｈ／Ｓｕｂｓｃｒｉｂｅ Ｍｉｄｄｌｅｗａｒｅ Ａｒｃｈｉｔｅｃｔｕｒｅ」という名称の２００５年１２月２３日に出願した米国特許仮出願第１１／３１６７７８号（弁理士整理番号５０００３−００００４）に関連し、これを参照により組み込む。

本発明は、データ・メッセージングに関し、より詳細には、パブリッシュとサブスクライブ（以下では「パブリッシュ／サブスクライブ」）ミドルウェア・アーキテクチャを有するメッセージング・システム内のキャッシング・エンジンに関する。

データ・メッセージング・インフラストラクチャによって要求されるパフォーマンス・レベルがますます高くなっていることが、ネットワーキング・インフラストラクチャやネットワーキング・プロトコルの進歩の抗し難い根本的な理由となっている。基本的に、データ配信には、データの様々な送信元と宛先だけでなくデータ送信元とデータ宛先の間における様々なタイプの相互接続アーキテクチャや通信モードがかかわる。既存のデータ・メッセージング・アーキテクチャの例には、ハブ・アンド・スポーク、ピア・ツー・ピア、ストア・アンド・フォワードが含まれる。

ハブ・アンド・スポーク・システム構成では、すべての通信は、ハブ経由でトランスポートされ、しばしば、非常に多くの量を処理する際、パフォーマンスのネックを生じさせる。したがって、このメッセージング・システム・アーキテクチャは、待ち時間をもたらす。このネックを回避する１つのやり方は、より多くのサーバを展開し、それらの異なるサーバにわたってネットワーク負荷を分散させることである。しかし、そのようなアーキテクチャは、スケーラビリティの問題や、動作上の問題をもたらす。ハブ・アンド・スポーク構成を有するシステムと比較して、ピア・ツー・ピア構成を有するシステムは、データを処理し、フィルタリングするアプリケーション群に不要なストレスをかけ、そのシステムの最も遅いコンシューマまたはノードが速度の限界である。次に、ストア・アンド・フォワード・システム構成では、永続性を与えるために、システムは、データを格納してから、パスにおける次のノードに、そのデータを転送する。格納オペレーションは、通常、メッセージに索引を付けて、ディスクに書き込むことによって行われ、これにより、パフォーマンスのネックが生じる可能性がある。さらに、メッセージ量が増加すると、インデキシングのタスクや書き込みのタスクは、さらに遅くなる可能性があり、このため、さらなる待ち時間を生じさせる可能性がある。

データ整合性を与えるために、これらのストア・アンド・フォワード・システムは、論理的であれ物理的であれ、すべての災害からデータ損失なしで回復する能力を実現しなければならない。これは、通常、リモート・ディスク・ミラーリング技術またはデータベース・レプリケーション技術を用いて実現される。そのような実装に関する課題は、常時少ない待ち時間で１次サイトと２次サイトとの間のデータ整合性を保証することである。１つのオプションは、同期式ソリューションを実装することであり、この場合に、１次サイトに書き込まれるデータの各ブロックは、２次サイトにミラーリングされた後に、完全と考えられる。そのような同期式実装に関する問題は、これがメッセージング・レイヤの全体的パフォーマンスに影響することである。代替オプションは、非同期式アプローチを実装することである。しかし、このアプローチに関して、データ損失または破壊を避けるという課題は、災害が発生している間にデータ整合性を維持することである。もう１つの課題は、データ更新の順序を保証することである。

既存のデータ・メッセージング・アーキテクチャは、いくつかの欠点を共有している。１つの共通の欠点は、既存のアーキテクチャにおけるデータ・メッセージングが、アプリケーション・レベルに存在するソフトウェアに依拠することである。このことは、メッセージング・インフラストラクチャが、ＯＳ（オペレーティング・システム）キューイングやネットワークＩ／Ｏ（入力／出力）を経験し、これにより、パフォーマンスのネックが生じる可能性があることを意味する。別の共通の欠点は、他のプロトコルが、状況下で、より適切である場合でさえ、既存のアーキテクチャは、データ・トランスポート・プロトコルを、動的にではなく、静的に使用することである。一般的なプロトコルのいくつかの例には、ルーティング可能なマルチキャスト、ブロードキャスト、またはユニキャストが含まれる。実際、既存のアーキテクチャにおけるＡＰＩ（アプリケーション・プログラミング・インタフェース）は、複数のトランスポート・プロトコルの間で、リアルタイムで切り換えを行うように設計されていない。

また、ネットワーク構成決定は、通常、展開時に行われ、通常、特定の想定の下で、ネットワーク条件とメッセージング条件の１つのセットを最適化するように定義される。静的（固定の）構成に関連する限界は、リアルタイムの動的なネットワーク再構成を除外する。つまり、既存のアーキテクチャは、すべてのネットワーク・データ・トランスポート負荷条件に必ずしも適しているわけではない特定のトランスポート・プロトコル向けに構成され、したがって、既存のアーキテクチャは、しばしば、変化、または、より高い負荷容量要件をリアルタイムで扱うことができない。

さらに、データ・メッセージングが、特定の受信者、または特定の受信者グループを宛先としている場合、既存のメッセージング・アーキテクチャは、いくつかのネットワークにわたってデータをトランスポートするために、ルーティング可能なマルチキャストを使用する。しかし、マルチキャスト向けにセットアップされたシステムには、データを配信するのに使用できるマルチキャスト・グループの数に限界があり、その結果、メッセージング・システムは、システムにサブスクライブしていない宛先（すなわち、サブスクライバではないコンシューマ）にデータを送信してしまうことになる。これにより、コンシューマのデータ処理負荷、およびデータ・フィルタリングによる破棄率が高まる。すると、何らかの理由で過負荷になり、データのフローについて行くことができないコンシューマは、結局は、着信データをドロップし、後に、再送を求める。再送は、すべてのコンシューマが、繰り返しの伝送を受信し、コンシューマのすべてが、着信データを再処理するという点で、システム全体に影響を及ぼす。したがって、再送は、マルチキャスト・ストームを生じさせて、ついには、ネットワーク化されたシステム全体をダウンさせる可能性がある。

システムが、破棄率を低減する策としてユニキャスト・メッセージング向けにセットアップされた場合、メッセージング・システムは、データ重複のために帯域幅が飽和する可能性がある。例えば、複数のコンシューマが、関心対象の所与のトピックにサブスクライブした場合、メッセージング・システムは、データを各サブスクライバに配信しなければならず、実際、システムは、そのデータの異なるコピーを各サブスクライバに送信する。また、これにより、コンシューマが、サブスクライブ対象でないデータをフィルタリングして除く問題が解決されるものの、ユニキャスト伝送は、スケーラブルではなく、このため、ある特定のデータにサブスクライブする相当に大きいコンシューマ・グループ、または消費パターンの相当な重複に適合可能ではない。

既存のアーキテクチャの１つのより一般的な欠点は、それらのアーキテクチャのプロトコル変換が遅く、回数が多いことである。このことの理由は、ますます多くの新たな技術が、レガシー・システムと統合される、ＥＡＩ（Ｅｎｔｅｒｐｒｉｓｅ Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｔｅｇｒａｔｉｏｎ）ドメインにおけるＩＴ（情報技術）応急処置戦略である。

したがって、いくつかの領域でデータ・メッセージング・システム・パフォーマンスを向上させる必要性が存在する。パフォーマンスが向上を必要とする可能性がある例が、速度、リソース割り当て、待ち時間などである。

本発明は、ある程度、以上の所見と、そのような欠点に、異なるアプローチを使用して、より良い結果で対処することができるという考えとに基づく。以上の所見は、大量の、待ち時間が少ないメッセージングのための、およびデータ・キャッシングを介して保証された配信サービス品質を有する、終端間メッセージ・パブリッシュ／サブスクライブ・アーキテクチャを生み出した。その目的で、そのようなアーキテクチャ（パブリッシュ／サブスクライブ・ミドルウェア・システム）を有するメッセージング・インフラストラクチャは、後でより詳細に説明するインデクシング・サービスとストレージ・サービスを有するキャッシング・エンジン（ＣＥ）をも含む。

一般に、メッセージング・アプライアンス（ＭＡ）は、メッセージを受信し、ルーティングする。ＣＥに緊密に結合された時に、ＭＡは、ＣＥにコピーを送ることによって、ルーティングされるメッセージのすべてまたはサブセットをまず格納する。次に、所定の期間にわたって、記録されたメッセージが、メッセージング・システム内の任意の構成要素による要求時の再送に使用可能であり、これによって、融合された接続中保証と切断中保証の配信サービス品質が実現され、かつ部分的データ・パブリケーション・サービスが実現される。

そのようなサービスをサポートするために、ＣＥは、ＭＡの転送レートについて行くように設計される。例えば、ＣＥは、できる限り高速にメッセージをプッシュするためのＭＡとＣＥとの間の高スループット接続と、バック・エンドＣＥデータベースからのメッセージを挿入し再生するための高スループットでスマートなインデクシング機構と、高スループット永続ストレージ・デバイスとを用いて設計される。この設計での考慮事項の１つは、再生要求の待ち時間を減らすことである。

このため、本明細書で示され、広く説明される本発明の目的によれば、１つの例示的なシステムは、キャッシング・エンジン、メッセージング・アプライアンス、インタフェース媒体を含む。キャッシング・エンジンは、メッセージを送信し、受信するように機能するメッセージ・レイヤと、まず受信されたメッセージをインデクシングし、受信された部分的にパブリッシュされたメッセージのイメージを維持するように機能するインデクシング・サービスを有するキャッシング・レイヤと、ストレージされ、受信されたメッセージのすべてまたはサブセットをストレージに格納するように機能するストレージ・サービスと、受信されたメッセージと送信されたメッセージをトランスポートする１つまたは複数の物理インタフェースと、１つまたは複数の物理インタフェースのそれぞれを介するメッセージの送信と受信を制御するチャネル管理を有するメッセージング・トランスポート・レイヤとを含む。メッセージング・アプライアンスとキャッシング・エンジンとの間の物理媒体は、ファブリックにこだわらず、イーサネット（登録商標）、メモリ・ベースの直接接続、またはＩｎｆｉｎｉｂａｎｄとして構成される。

さらに、前述のシステムは、インタフェース媒体を介してリンクされ、各メッセージング・アプライアンスと管理メッセージを交換するように構成されたプロビジョニング−マネージメント・システムを用いても実現される。キャッシング・エンジン構成は、管理メッセージを介して、Ｐ＆Ｍシステムから、キャッシング・エンジンに直接に接続されたＭＡを介して通信される。効果的に、キャッシング・エンジンは、近隣ベースのメッセージ・アーキテクチャ内でもう１つの近隣として働く。

上で説明したキャッシング・エンジンを使用する様々な方法は、メッセージングにおいてサービス品質を提供することができる。１つのそのような方法は、メッセージング・トランスポート・レイヤと管理メッセージ・レイヤを有し、さらに、インデクシング・サービスとストレージ・サービスならびに関連するストレージを備えたキャッシング・レイヤを有するキャッシング・エンジン内で行われる。この方法は、データと管理メッセージをメッセージ・トランスポート・レイヤによって受信するステップと、管理メッセージを管理メッセージ・レイヤに、データ・メッセージをキャッシング・レイヤに転送するステップとを含み、管理メッセージ・レイヤに転送されたメッセージ取得要求メッセージは、キャッシング・レイヤにルーティングされる。この方法は、さらに、インデクシング・サービス内でデータ・メッセージを、トピック・ベースでインデクシングするステップと、インデクシングに基づいて、データ・メッセージをストレージ・デバイス内に格納するステップとを含み、データ・メッセージは、メッセージ取得要求メッセージに応答する再送に使用可能である所定の期間ストレージ・デバイス内で維持される。

データ・メッセージは、完全なデータ・メッセージまたは部分的にパブリッシュされたデータ・メッセージのいずれかであり、各データ・メッセージは、関連するトピックを有するので、インデクシング・サービスは、各完全なデータ・メッセージのマスタ・イメージを維持する。次に、部分的に完全なメッセージである受信されたデータ・メッセージについて、インデクシング・サービスは、受信されたデータ・メッセージを、その部分的にパブリッシュされたメッセージの関連トピックに類似する関連トピックを有する完全なメッセージの最も最近のマスタ・イメージと比較して、マスタ・イメージをどのように更新しなければならないかを決定する。部分的にパブリッシュされたメッセージとマスタ・イメージは、両方がインデクシングされ、再送に使用可能である。

これらのキャッシング・エンジンは、１次ＣＥ、２次ＣＥからなるフォールト・トレラントペアとして、または３つ以上のＣＥノードからなるフォールト・トレラント・グループとして、構成され展開されることが可能である。３つ以上のＣＥが互いに論理的にリンクされる場合に、これらは、同一のデータにサブスクライブし、したがって、サブスクライブされたデータの固有の一貫したビューを維持する。データへのＣＥのサブスクライブが、アプリケーション・プログラミング・インタフェース（ＡＰＩ）と同様に、トピック・ベースであることに留意されたい。データ損失の場合に、ＣＥは、フォールト・トレラント・グループの他のＣＥメンバに、失われたデータの再生を要求する。同一のフォールト・トレラント・グループのＣＥの間でのデータの同期化は、メッセージング・ファブリックによって並列化され、このメッセージング・ファブリックは、ＭＡを介して、サブスクライブされたメッセージング・トラフィックのコピーをすべてのキャッシング・エンジン・インスタンスにインテリジェントにまた効率的に転送する。その結果、これは、フォールト・トレラント展開および災害復旧（ｄｉｓａｓｔｅｒ ｒｅｃｏｖｅｒｙ）展開に関する非同期データ整合性を可能にし、ここで、データ同期化が実行され、永続性は、ストレージ／ディスク・ミラーリング技術またはデータベース・レプリケーション技術を活用することによるのではなく、メッセージング・ファブリックによって保証される。

要するに、本発明の以上、およびその他の特徴、態様、および利点は、本明細書の説明、添付の特許請求の範囲、および後段で説明する添付の図面から、より良く理解されるようになろう。

本明細書に組み込まれ、本明細書の一部を構成する添付の図面は、本発明の様々な態様を例示し、説明と一緒に、本発明の諸原理を説明する役割をする。好都合な場合はいつでも、同一の符号が、すべての図面で、同一の要素、または同様の要素を指すのに使用される。

本発明の諸態様と諸原理による様々な実施形態の詳細の概要を述べる前に、以下は、この説明の全体で使用されるいくつかの用語の簡単な説明である。この説明は、単に、そのような用語がどのように使用される可能性があるかについて、明確にし、読者に理解を与えることを、ただし、それらの用語が使用される文脈に、それらの用語を限定することなく、特許請求の範囲を限定することなしに、意図していることに留意されたい。

「ミドルウェア」という用語が、２つの別個の、しばしば、既に存在するプログラムの間を仲介する任意のプログラミングを表す一般的な用語として、コンピュータ業界で使用されている。通常、ミドルウェア・プログラムは、様々なアプリケーションが通信することができるように、メッセージング・サービスを提供する。異種のアプリケーションを、しばしば、ミドルウェアの使用を介して、一緒に系統立って結び付けることは、ＥＡＩ（Ｅｎｔｅｒｐｒｉｓｅ Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｔｅｇｒａｔｉｏｎ）として知られる。しかし、この文脈において、「ミドルウェア」は、送信元と宛先の間におけるメッセージングの文脈で使用される、より広い用語であり、そのようなメッセージングを可能にするように展開される機構であることが可能であり、このため、ミドルウェア・アーキテクチャは、以下に説明するとおり、個々に、または組合せで、効果的なデータ・メッセージングを円滑にするネットワーキング、およびコンピュータのハードウェア構成要素やソフトウェア構成要素をも範囲に含む。さらに、「メッセージング・システム」または「ミドルウェア・システム」という用語が、パブリッシャとサブスクライバの間におけるメッセージのルーティングをメッセージング・サーバが管理する、パブリッシュ／サブスクライブ・システムの文脈において使用されることが可能である。実際、メッセージング・ミドルウェアにおけるパブリッシュ／サブスクライブのパラダイムは、スケーラブルな、したがって、強力なモデルである。

「コンシューマ」という用語が、クライアント−サーバ・アプリケーションなどの文脈において使用される。１つの実例では、コンシューマは、ＡＰＩ（アプリケーション・プログラミング・インタフェース）を使用して、ミドルウェア・システムに登録し、情報にサブスクライブし、ミドルウェア・システムによって配信されたデータを受信するシステムまたはアプリケーションである。ミドルウェア・アーキテクチャ境界内のＡＰＩは、コンシューマであり、外部コンシューマは、ＡＰＩを使用せず、メッセージが、プロトコル変換を経る（以下に説明するとおり）通信相手である、任意のパブリッシュ／サブスクライブ・システム（または外部データ宛先）である。

「外部データ送信元」という用語が、データ配信システムとメッセージ・パブリッシュ／サブスクライブ・システムの文脈において使用される。１つの実例では、外部データ送信元は、一般的なプロトコルの１つで、または独自のメッセージ・プロトコルでメッセージをパブリッシュする、企業プライベート・ネットワークの内部または外部に配置された、システムまたはアプリケーションと見なされる。外部データ送信元の例は、ミドルウェア・システムを介してトレーダに配信される株式市場の取引値をパブリッシュする市場データ・エクスチェンジである。外部データ送信元の別の例は、トランザクション・データである。本発明の通常の実装では、以下により詳細に説明するとおり、ミドルウェア・アーキテクチャは、外部データ送信元からのデータが、ミドルウェア・システム・ドメインに入ると、変換される、固有のネイティブ・プロトコルを採用し、従来のシステムによくある複数のプロトコル変換を回避することに留意されたい。

また、「外部データ宛先」という用語も、データ配信システムとメッセージ・パブリッシュ／サブスクライブ・システムの文脈において使用される。外部データ宛先は、例えば、ローカル／グローバル・ネットワークを介してルーティングされる情報にサブスクライブする、企業プライベート・ネットワークの内部または外部に配置されたシステムまたはアプリケーションである。外部データ宛先の一例は、トレーダによってパブリッシュされたトランザクション注文を扱う市場データ・エクスチェンジである。外部データ宛先の別の例が、トランザクション・データである。以上のミドルウェア・アーキテクチャでは、外部データ宛先を宛先とするメッセージは、ネイティブ・プロトコルから、外部データ宛先に関連する外部プロトコルに変換されることに留意されたい。

本明細書の説明から確認することができるとおり、本発明は、ミドルウウェア・アーキテクチャ内で様々な構成で実装されるキャッシング・エンジン（ＣＥ）を用いて様々な仕方で実施されることが可能である。したがって、この説明は、図１に示された終端間ミドルウェア・アーキテクチャの例から始まる。

この例示的なアーキテクチャは、以下を含むいくつかの有益な特徴を併せ持つ。すなわち、メッセージング一般的概念、ＡＰＩ、フォールト・トレランス、Ｐ＆Ｍ（プロビジョニング−マネージメント）、ＱｏＳ（サービス品質−融合型、ベスト・エフォート型、接続中保証型、切断中保証型など）、保証された配信ＱｏＳのための永続キャッシング、名前空間とセキュリティ・サービスの管理、パブリッシュ／サブスクライブ・エコシステム（コア構成要素、イングレス構成要素、イグレス構成要素）、トランスポート・トランスペアレント・メッセージング、近隣ベースのメッセージング（ハブ・アンド・スポーク、ピア・ツー・ピア、ストア・アンド・フォワードの間の混成であり、必要に応じて、サブスクリプションをすべての近隣に広めることができるサブスクリプション・ベースのルーティング・プロトコルを使用するモデル）、レイト・スキーマ・バインディング、部分的パブリッシング（データ全体ではなく、パブリッシングによって変更された情報だけ）、ネットワーク・リソースとシステム・リソースの動的割り当てである。後段で説明するとおり、パブリッシュ／サブスクライブ・システムは、ミドルウェア・アーキテクチャのフォールト・トレラント設計を有利に組み込む。パブリッシュ／サブスクライブ・エコシステムのコアＭＡ部分は、前述したネイティブ・メッセージング・プロトコル（ミドルウェア・システムに固有の）を使用するのに対して、イングレス部分とイグレス部分、エッジＭＡは、そのネイティブ・プロトコルへの変換や、そのネイティブ・プロトコルからの変換をそれぞれ行うことに留意されたい。

パブリッシュ／サブスクライブ・システム構成要素に加えて、図１は、論理接続、およびそれらの論理接続間の通信も示す。見て取ることができるとおり、図示されるミドルウェア・アーキテクチャは、分散システムのアーキテクチャである。このアーキテクチャを有するシステムにおいて、２つの別個の物理構成要素の間の論理通信は、メッセージ・ストリームと、関連するメッセージ・プロトコルで確立される。メッセージ・ストリームは、メッセージ２つのカテゴリの１つ、すなわち管理メッセージとデータ・メッセージのいずれかを含む。管理メッセージは、様々な物理構成要素の管理と制御、データへのサブスクリプションの管理、その他のために使用される。データ・メッセージは、送信元と宛先の間でデータをトランスポートするために使用され、通常のパブリッシュ／サブスクライブ・メッセージングでは、データ・メッセージの複数の送信者と複数の受信者とが存在する。

ミドルウェア・アーキテクチャを有する分散パブリッシュ／サブスクライブ・システムは、例示される構造上の構成と論理通信で、いくつかの論理機能を実行するように設計される。１つの論理機能は、エッジＭＡ（メッセージング・アプライアンス）構成要素において有利に実行されるメッセージ・プロトコル変換である。第２の論理機能は、パブリッシャからサブスクライバにメッセージをルーティングすることである。メッセージは、パブリッシュ／サブスクライブ・ネットワーク全体でルーティングされることに留意されたい。このため、ルーティング機能は、メッセージが伝搬される、例えば、エッジＭＡ１０６ａ〜ｂ（またはＡＰＩ）からコアＭＡ１０８ａ〜ｃまで、または１つのコアＭＡから別のコアＭＡまで、さらに、最終的に、エッジＭＡ（例えば、１０６ｂ）またはＡＰＩ １１０ａ〜ｂまで、各ＭＡによって実行される。ＡＰＩ １１０ａ〜ｂは、プロセス間通信バス（ソケット、共有メモリなど）を介して、アプリケーション１１２_1〜nと通信する。

第３の論理機能は、例えば、接続中保証タイプや切断中保証タイプを含め、様々なタイプの保証配信サービス品質のためにメッセージを格納することである。第４の機能は、サブスクライバに、それらのメッセージを配信することである。図示されるとおり、ＡＰＩ １０６ａ〜ｂは、サブスクライブするアプリケーション１１２_1〜nにメッセージを配信する。

このパブリッシュ／サブスクライブ・ミドルウェア・アーキテクチャでは、システム構成機能は、他の管理機能やシステム・パフォーマンス監視機能と同様にＰ＆Ｍシステム１０２、１０４によって管理される。構成には、パブリッシュ／サブスクライブ・ミドルウェア・システムのネットワークおよび構成要素の物理的構成と論理的構成との両方が含まれる。監視と報告には、すべてのネットワークやシステムの構成要素の健全性の監視と、要求に応じてまたはログに結果を自動的に報告することが含まれる。Ｐ＆Ｍシステムは、管理メッセージを介して、構成機能、監視機能、報告機能を実行する。加えて、Ｐ＆Ｍシステムによって、システム管理者は、パブリッシュ／サブスクライブ・ネットワーク全体にわたってルーティングされるメッセージのそれぞれに関連するメッセージ名前空間を決めることができる。したがって、パブリッシュ／サブスクライブ・ネットワークは、名前空間ベースのサブネットワークに物理的および／または論理的に分割されることが可能である。

Ｐ＆Ｍシステムは、１つまたは複数のＭＡを有するパブリッシュ／サブスクライブ・ミドルウェア・システムを管理する。ＭＡは、ネットワークにおけるＭＡの役割に応じて、エッジＭＡまたはコアＭＡとして展開される。エッジＭＡは、メッセージを、外部プロトコルからネイティブ・プロトコルに、またネイティブ・プロトコルから外部プロトコルに変換するプロトコル変換エンジンを含むこと以外は、ほとんどの点でコアＭＡと同様である。このため、一般に、パブリッシュ／サブスクライブ・システム・ミドルウェア・アーキテクチャの境界は、エッジＭＡ１０６ａ〜ｂとＡＰＩ １１０ａ〜ｂが存在するエッジを特徴とし、それらの境界内に、コアＭＡ１０８ａ〜ｃが存在する。

システム・アーキテクチャは、特定の限られた地理的区域に限定されておらず、実際、地域的境界または国境を越えるように、さらに、大陸間にわたるようにさえ設計されることに留意されたい。そのようなケースでは、１つのネットワークにおけるエッジＭＡは、別の地理的に遠隔のネットワークにおけるエッジＭＡと、既存のネットワーキング・インフラストラクチャを介して通信することができる。

通常のシステムでは、コアＭＡ１０８ａ〜ｃは、パブリッシュされたメッセージをシステム内で、エッジＭＡまたはＡＰＩ（例えば、ＡＰＩ １１０ａ〜ｂ）に向けて内部でルーティングする。特にコアＭＡにおけるルーティング・マップは、最大容量、少ない待ち時間、および効率的なルーティングのために設計される。さらに、コアＭＡ間のルーティングは、リアルタイムで動的に変化することが可能である。いくつかのノード（コアＭＡ）を横断する所与のメッセージング・パスに関して、ルーティングのリアルタイムの変更は、ネットワーク利用率、全体的な終端間待ち時間、通信量、ネットワーク遅延、損失、ジッタを含め、１つまたは複数のメトリックに基づく。

代替として、２つ以上の異なるパスから最良のパフォーマンスを示すパスを動的に選択する代わりに、ＭＡは、メッセージ・レプリケーションに基づき、マルチパス・ルーティングを実行することができ、このため、すべてのパスにわたって同一のメッセージを送信することができる。異なるパスの収束点に位置するすべてのＭＡは、重複メッセージをドロップして、最初に着信したメッセージだけを転送する。このルーティング・アプローチは、少ない待ち時間のためにメッセージング・インフラストラクチャを最適化するという利点を有する。ただし、このルーティング方法の欠点は、そのインフラストラクチャが、重複トラフィックを伝送するのに、より多くのネットワーク帯域幅を必要とすることである。

エッジＭＡは、着信メッセージのいずれの外部メッセージ・プロトコルも、ミドルウェア・システムのネイティブ・メッセージ・プロトコルに変換し、送信メッセージに関してネイティブ・プロトコルから外部プロトコルに変換する能力を有する。つまり、外部プロトコルは、メッセージが、パブリッシュ／サブスクライブ・ネットワーク・ドメインに入る際に（イングレス）、ネイティブ（例えば、Ｔｅｒｖｅｌａ（商標））メッセージ・プロトコルに変換され、ネイティブ・プロトコルは、メッセージが、パブリッシュ／サブスクライブ・ネットワーク・ドメインを出る際に（イグレス）、外部プロトコルに変換される。エッジＭＡの別の機能は、パブリッシュされたメッセージを、サブスクライブする外部データ宛先に配信することである。

さらに、エッジＭＡ１０６ａ〜ｂとコアＭＡ１０８ａ〜ｃはともに、メッセージを格納してから、それらのメッセージを転送することができる。これが行われることが可能な１つの形は、ＣＥ（キャッシング・エンジン）１１８ａ〜ｂを使用して行うことである。１つまたは複数のＣＥが、同一のＭＡに接続されることが可能である。理論上、ＡＰＩは、このストア・アンド・フォワード能力を有さないと言われているが、現実には、ＡＰＩ １１０ａ〜ｂは、メッセージを格納してから、それらのメッセージをアプリケーションに配信することができ、アプリケーションから受信されたメッセージを格納してから、それらのメッセージをコアＭＡ、エッジＭＡ、または別のＡＰＩに配信することができる。

ＭＡ（エッジＭＡまたはコアＭＡ）は、ＣＥに対する能動的な接続を有する場合、ルーティングされるメッセージのすべて、またはサブセットをＣＥに転送し、ＣＥは、それらのメッセージを、保存のためにストレージ領域に書き込む。記録されたメッセージは、所定の期間にわたって、要求に基づく再送が可能である。このアーキテクチャを活用する例は、データ再生、部分的パブリッシュ、様々なサービス品質レベルである。部分的パブリッシュは、すべての情報の伝送ではなく、更新された情報だけの伝送しか要求しないため、ネットワーク負荷およびコンシューマ負荷を減らすのに有効である。

ルーティング・マップが、ルーティングにどのように影響を与えるかを例示するように、パブリッシュ／サブスクライブ・ルーティング・パスのいくつかの例が、図１に示されている。この例示では、パブリッシュ／サブスクライブ・ネットワークのミドルウェア・アーキテクチャが、パブリッシャとサブスクライバの間で５つ以上の異なる通信パスを提供する。

第１の通信パスは、外部データ送信元を外部データ宛先にリンクする。外部データ送信元１１４_1〜nから受信された、パブリッシュされたメッセージは、ネイティブ（例えば、Ｔｅｒｖｅｌａ（商標））メッセージ・プロトコルに変換され、次に、エッジＭＡ１０６ａによってルーティングされる。ネイティブ・プロトコル・メッセージが、エッジＭＡ１０６ａからルーティングされることが可能な１つの形は、外部データ宛先１１６ｎに対してである。そのパスは、通信パス１ａとして呼び出される。そのケースでは、ネイティブ・プロトコル・メッセージは、外部データ宛先に適した外部プロトコル・メッセージに変換される。ネイティブ・プロトコル・メッセージが、エッジＭＡ１０６ｂからルーティングされることが可能な別の形は、内部でコアＭＡ１０８ｂを経由してである。そのパスは、通信パス１ｂとして呼び出される。そのパスに沿って、コアＭＡ１０８ｂは、ネイティブ・メッセージをエッジＭＡ１０６ａにルーティングする。しかし、エッジＭＡ１０６ａは、ネイティブ・プロトコル・メッセージを外部データ宛先１１６₁にルーティングする前に、それらのメッセージを、その外部データ宛先１１６₁に適した外部メッセージ・プロトコルに変換する。見て取ることができるとおり、その通信パスは、ＡＰＩが、メッセージをパブリッシャからサブスクライバにルーティングすることを要求しない。したがって、パブリッシュ／サブスクライブ・システムが、外部送信元−宛先通信のために使用される場合、システムは、ＡＰＩを含まなくてもよい。

通信パス２として呼び出される別の通信パスは、外部データ送信元１１４ｎを、ＡＰＩ １１０ｂを使用するアプリケーションにリンクする。外部データ送信元から受信された、パブリッシュされたメッセージは、エッジＭＡ１０６ａにおいて、ネイティブ・メッセージ・プロトコルに変換され、次に、エッジＭＡによってコアＭＡ１０８ａにルーティングされる。第１のコアＭＡ１０８ａから、メッセージは、別のコアＭＡ１０８ｃ経由でＡＰＩ １１０ｂにルーティングされる。ＡＰＩから、メッセージは、サブスクライブするアプリケーション（例えば、１１２₂）に配信される。通信パスは、双方向であるため、別の実例では、メッセージは、サブスクライブするアプリケーション１１２_1〜nから外部データ宛先１１６ｎまで、逆方向のパスをたどることも可能である。各実例において、コアＭＡは、ネイティブ・プロトコル・メッセージを受信して、ルーティングするのに対して、エッジＭＡは、外部プロトコル・メッセージまたはネイティブ・プロトコル・メッセージを受信し、ネイティブ・プロトコル・メッセージまたは外部プロトコル・メッセージをそれぞれルーティングする（エッジＭＡは、そのような外部メッセージ・プロトコルに／から、ネイティブ・メッセージ・プロトコルに／から変換を行う）。エッジＭＡのそれぞれは、イングレス・メッセージを、ネイティブ・プロトコル・チャネルと外部プロトコル・チャネルの両方に同時にルーティングすることができる。その結果、各エッジＭＡは、イングレス・メッセージを、外部コンシューマと内部コンシューマの両方に同時にルーティングすることができ、ただし、内部コンシューマは、ネイティブ・プロトコル・メッセージを消費し、外部コンシューマは、外部プロトコル・メッセージを消費する。この能力により、メッセージング・インフラストラクチャが、レガシー・アプリケーションとレガシー・システムに、シームレスにかつ円滑に一体化されることが可能になる。

通信パス３として呼び出される、さらに別の通信パスは、ＡＰＩ １１０ａ〜ｂをともに使用する、２つのアプリケーションをリンクする。それらのアプリケーションの少なくとも１つは、メッセージをパブリッシュするか、またはメッセージにサブスクライブする。パブリッシュされたメッセージの、サブスクライブする（パブリッシュする）アプリケーションへの（またはからの）配信は、パブリッシュ／サブスクライブ・ネットワークのエッジ上に位置するＡＰＩを介して行われる。アプリケーションが、メッセージにサブスクライブすると、コアＭＡまたはエッジＭＡの１つが、それらのメッセージをＡＰＩに向けてルーティングし、ＡＰＩは、データが、サブスクライブするアプリケーションに配信される用意ができると、それらのアプリケーションに通知する。アプリケーションからパブリッシュされたメッセージは、ＡＰＩを介して、ＡＰＩが「登録」されているコアＭＡ１０８ｃに送信される。

ＭＡに「登録」（ログイン）することにより、ＡＰＩは、そのＭＡに論理的に接続されるようになることに留意されたい。ＡＰＩは、登録（「ログイン」要求）メッセージをＭＡに送信することにより、ＭＡに対する接続を開始する。登録の後、ＡＰＩは、ＡＰＩのサブスクリプション・メッセージをＭＡに送信することにより、関心対象の特定のトピックにサブスクライブすることができる。トピックは、パブリッシュ／サブスクライブ・メッセージングに関して、メッセージに対する共有したアクセス・ドメインとターゲットを定義するのに使用され、したがって、１つまたは複数のトピックへのサブスクリプションにより、そのようなトピック表記を有するメッセージの受信と送信が可能になる。Ｐ＆Ｍは、ネットワークにおけるＭＡに定期資格更新を送信し、各ＭＡは、そのＭＡ独自のテーブルを、それに相応して更新する。したがって、ＡＰＩが、ある特定のトピックにサブスクライブする資格があることが、ＭＡに分かった場合（ＭＡは、ルーティング資格テーブルを使用して、ＡＰＩの資格を検証する）、ＭＡは、そのＡＰＩに対する論理接続をアクティブにする。次に、ＡＰＩが、コアＭＡ１０８ｃに適切に登録されている場合、コアＭＡ１０８ｃは、図示されるとおり、データを第２のＡＰＩ １１０にルーティングする。その他の実例では、そのコアＭＡ１０８ｂは、さらなる１つまたは複数のＭＡ（図示せず）経由でメッセージをルーティングすることができ、それらのＭＡは、それらのメッセージをＡＰＩ １１０ｂにルーティングし、ＡＰＩ １１０ｂは、それらのメッセージを、サブスクライブするアプリケーション１１２_1〜nに配信する。

見て取ることができるとおり、通信パス３は、外部データ・メッセージ・プロトコルが全くかかわらないため、エッジＭＡの存在を要求しない。その種の通信パスを例示する一実施形態では、企業システムは、様々なトピックに関する最新ニュースを従業員にパブリッシュするニュースサーバを有して構成される。ニュースを受信するのに、従業員は、ＡＰＩを使用するニュース・ブラウザ・アプリケーションを介して、従業員の関心対象のトピックにサブスクライブする。

ミドルウェア・アーキテクチャは、１つまたは複数のトピックへのサブスクリプションを可能にすることに留意されたい。さらに、このアーキテクチャは、トピック表記においてワイルドカードを許すことにより、単一のサブスクリプション要求で、一群の関連するトピックへのサブスクリプションを可能にする。

通信パス４として呼び出される、さらに別のパスが、Ｐ＆Ｍシステム１０２と１０４に関連する多くのパスの１つであり、それらのパスのそれぞれは、Ｐ＆Ｍを、パブリッシュ／サブスクライブ・ネットワーク・ミドルウェア・アーキテクチャにおけるＭＡの１つにリンクする。Ｐ＆Ｍシステムと各ＭＡの間で行き来するメッセージは、そのＭＡを構成し、監視するのに使用される管理メッセージである。１つのシステム構成では、Ｐ＆Ｍシステムは、ＭＡ群と直接に通信する。別のシステム構成では、Ｐ＆Ｍシステムは、ＭＡ群と、他のＭＡ群を介して通信する。さらに別の構成では、Ｐ＆Ｍシステムは、ＭＡ群と直接に通信することも、間接的に通信することもできる。

通常の実装では、ミドルウェア・アーキテクチャは、スイッチ、ルータ、その他のネットワーキング・アプライアンスを有するネットワークにわたって展開され、任意のタイプの物理媒体を介して通信することができるチャネル・ベースのメッセージングを使用する。このファブリックにこだわらないチャネル・ベースのメッセージングの１つの例示的な実装が、ＩＰベースのネットワークである。その環境では、すべてのパブリッシュ／サブスクライブ・物理構成要素間のすべての通信は、ＵＤＰ（ユーザ・データグラム・プロトコル）を介して実行され、トランスポートの信頼性は、メッセージング・レイヤによって提供される。この原理によるオーバーレイ・ネットワークが、図１ａに示される。

図示されるとおり、オーバーレイ通信１、２、３が、スイッチ２１４ａ〜ｃ、ルータ２１６、サブネット２１８ａ〜ｃを介して、３つのコアＭＡ２０８ａ〜ｃの間で行われることが可能である。つまり、それらの通信パスは、サブネット、スイッチ、ルータなどのネットワーキング・インフラストラクチャから成る、基礎をなすネットワークの上に確立されることが可能であり、前述したとおり、そのアーキテクチャは、広い地理的区域に（異なる国、または異なる大陸にさえ）わたることが可能である。

とりわけ、本発明の諸原理による以上、およびその他の終端間ミドルウェア・アーキテクチャは、様々なビジネス環境における様々な企業インフラストラクチャにおいて実施されることが可能である。１つのそのような実装が、図２に示される。

この企業インフラストラクチャでは、市場データ配信プラント１２が、様々な市場データ・エクスチェンジ３２０_1〜nからの株式市場取引値をトレーダ（図示されていないアプリケーション）にルーティングするために、パブリッシュ／サブスクライブ・ネットワークの上に構築される。そのようなオーバーレイ・ソリューションは、例えば、ＭＡ間や、そのようなＭＡ群とＰ＆Ｍシステムの間で相互接続を提供するために、基礎をなすネットワークに依拠する。ＡＰＩ ３１０_1〜nへの市場データ配信は、アプリケーション・サブスクリプションに基づく。このインフラストラクチャでは、アプリケーション（図示せず）を使用するトレーダが、パブリッシュ／サブスクライブ・ネットワークを介して（コアＭＡ３０８ａ〜ｂとエッジＭＡ３０６ｂ経由で）ＡＰＩ ３１０_1〜nから市場データ・エクスチェンジ３２０_1〜nに戻るようにルーティングされるトランザクション注文を行うことができる。

論理的に、パブリッシュ／サブスクライブ・ネットワークの物理構成要素は、ＯＳＩ（Ｏｐｅｎ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）参照モデルのレイヤ１ないし４に類似したメッセージング・トランスポート・レイヤ上に構築される。ＯＳＩモデルのレイヤ１ないし４は、物理レイヤ、データリンク・レイヤ、ネットワーク・レイヤ、トランスポート・レイヤである。

このため、本発明の一実施形態では、パブリッシュ／サブスクライブ・ネットワークは、例えば、１つまたは複数のメッセージング・ライン・カードを、ネットワーク・スイッチとルータのすべて、またはサブセットに挿入することにより、基礎をなすネットワーク／ファブリックの中に直接に展開されることが可能である。本発明の別の実施形態では、パブリッシュ／サブスクライブ・ネットワークは、メッシュ・オーバーレイ・ネットワーク（すべての物理構成要素が、相互接続された）として展開されることが可能である。例えば、４つのＭＡの完全メッシュ・ネットワークは、それらのＭＡのそれぞれが、そのＭＡの３つのピアＭＡのそれぞれに接続されたネットワークである。通常の実装では、パブリッシュ／サブスクライブ・ネットワークは、１つまたは複数の外部データ送信元および／または宛先、１つまたは複数のＰ＆Ｍ（プロビジョニング−マネージメント）システム、１つまたは複数のＭＡ（メッセージング・アプライアンス）、１つまたは複数のオプションのＣＥ（キャッシング・エンジン）、１つまたは複数のオプションのＡＰＩ（アプリケーション・プログラミング・インタフェース）のメッシュ・ネットワークである。

とりわけ、パブリッシュ／サブスクライブ・ネットワーク全体の通信は、基礎をなすトランスポート・ロジックとは独立であるネイティブ・プロトコル・メッセージを使用して行われる。このことが、このアーキテクチャを、トランスポート・トランスペアレントなチャネル・ベースのメッセージング・アーキテクチャと呼ぶ理由である。

図３は、チャネル・ベースのメッセージング・アーキテクチャ３２０を、より詳細に示す。一般に、メッセージング送信元とメッセージング宛先の間の各通信パスは、メッセージング・トランスポート・チャネルと考えられる。各チャネル３２６_1〜nは、チャネル送信元とチャネル宛先の間にインタフェース３２８_1〜nを有して、物理媒体を介して確立される。それぞれのそのようなチャネルは、ネイティブ（例えば、Ｔｅｒｖｅｌａ（商標））メッセージ・プロトコルなどの、特定のメッセージ・プロトコル向けに確立される。エッジＭＡ群（パブリッシュ／サブスクライブ・ネットワークのイングレスとイグレスを管理するＭＡ群）だけが、チャネル・メッセージ・プロトコル（外部メッセージ・プロトコル）を使用する。チャネル・メッセージ・プロトコルに基づき、チャネル管理レイヤ３２４は、着信メッセージと送信メッセージが、プロトコル変換を要求するかどうかを判定する。各エッジＭＡにおいて、着信メッセージのチャネル・メッセージ・プロトコルが、ネイティブ・プロトコルとは異なる場合、チャネル管理レイヤ３２４は、プロセスのためにメッセージを、ＰＴＥ（プロトコル変換エンジン）３３２を通るように送ってから、ネイティブ・メッセージ・レイヤ３３０に転送することにより、プロトコル変換を実行する。また、各エッジＭＡにおいて、送信メッセージのネイティブ・メッセージ・プロトコルが、チャネル・メッセージ・プロトコル（外部メッセージ・プロトコル）とは異なる場合、チャネル管理レイヤ３２４は、プロセスのためにメッセージを、ＰＴＥ（プロトコル変換エンジン）３３２を通るように送ってから、トランスポート・チャネル３２６_1〜nにルーティングすることにより、プロトコル変換を実行する。したがって、チャネルは、物理媒体を有するインタフェース３２８_1〜nを管理し、さらにその物理媒体に関連する特定のネットワークとトランスポート・ロジックを管理し、さらにメッセージ再組立てまたはメッセージ・フラグメンテーションを管理する。

つまり、チャネルは、ＯＳＩトランスポート・レイヤないし物理レイヤ３２２を管理する。チャネル・リソースの最適化は、チャネルごとに行われる（例えば、帯域幅、メッセージ・サイズ分布、チャネル宛先リソース、チャネル健全性統計を含め、消費パターンに基づく、物理媒体に関するメッセージ密度最適化）。その場合、通信チャネルは、ファブリックにこだわらないため、特定のタイプのファブリックは、全く要求されない。実際、任意のファブリック媒体、例えば、ＡＴＭ、Ｉｎｆｉｎｉｂａｎｄ、またはＥｔｈｅｒｎｅｔ（登録商標）でよい。

ところで、例えば、単一のメッセージが、複数のフレームにわたって分割される場合、または複数のメッセージが、単一のフレーム・メッセージ・フラグメンテーションにパックされる場合、または再組立てが、メッセージをチャネル管理レイヤに送るのに先立って行われる場合、メッセージ・フラグメンテーションまたはメッセージ再組立てが、必要とされる可能性がある。

図３は、ミドルウェア・アーキテクチャを有するネットワークにおける、いくつかの可能なチャネル実装をさらに示す。１つの実装３４０では、通信は、イーサネット交換ネットワークを介するマルチキャストを使用して、ネットワーク・ベースのチャネルを介して行われ、イーサネット交換ネットワークは、そのような通信のための物理媒体の役割をする。この実装では、送信元は、送信元のＵＤＰポートを介して、送信元のＩＰアドレスから、関連するＵＤＰポートを有する宛先のグループ（ＩＰマルチキャスト・アドレスとして定義される）にメッセージを送信する。この実装３４２のバリエーションでは、送信元と宛先の間の通信は、ＵＤＰユニキャストを使用して、イーサネット交換ネットワークを介して行われる。送信元は、送信元のＩＰアドレスから、ＵＤＰポートを介して、それぞれのＩＰアドレスにおいてＵＤＰポートを有する選定された宛先にメッセージを送信する。

別の実装３４４では、チャネルは、ネイティブのＩｎｆｉｎｉｂａｎｄトランスポート・プロトコルを使用するＩｎｆｉｎｉｂａｎｄ相互接続を介して確立され、ただし、Ｉｎｆｉｎｉｂａｎｄファブリックは、物理媒体である。この実装では、チャネルは、ノード・ベースであり、送信元と宛先の間の通信は、それぞれのノード・アドレスを使用して、ノード・ベースである。さらに別の実装３４６では、チャネルは、ＲＤＭＡ（Ｒｅｍｏｔｅ Ｄｉｒｅｃｔ Ｍｅｍｏｒｙ Ａｃｃｅｓｓ）などの、本明細書でＤＣ（直接接続）と呼ばれる、メモリ・ベースのチャネルである。このタイプのチャネルでは、メッセージは、送信元マシンから、宛先マシンのメモリの中に直接に送信され、このため、ＮＩＣからアプリケーション・メモリ空間へのメッセージを扱うＣＰＵ処理を回避し、場合により、メッセージをカプセル化して、ネットワーク・パケットにするネットワーク・オーバーヘッドを回避する。

ネイティブ・プロトコルに関して、１つのアプローチは、前述したネイティブのＴｅｒｖｅｌａ（商標）メッセージ・プロトコルを使用する。概念上、Ｔｅｒｖｅｌａ（商標）メッセージ・プロトコルは、ＩＰベースのプロトコルと同様である。各メッセージは、メッセージ・ヘッダと、メッセージ・ペイロードとを含む。メッセージ・ヘッダは、いくつかのフィールドを含み、フィールドの１つは、トピック情報用である。前述したとおり、トピックは、コンシューマによって、共有情報ドメインにサブスクライブするのに使用される。

図４は、１つの可能なトピック・ベースのメッセージ・フォーマットを示す。図示されるとおり、メッセージは、ヘッダ３７０とペイロードを含む本文３７２、３７４を含む。２つのタイプのメッセージ、データ・メッセージと管理メッセージが、異なるメッセージ本文と異なるペイロード・タイプを持って示されている。ヘッダは、送信元名前空間ＩＤと宛先名前空間ＩＤ、送信元セッションＩＤと宛先セッションＩＤ、トピック・シーケンス番号、ホップ・タイムスタンプに関するフィールドを含み、さらに、ヘッダは、トピック表記フィールド（好ましくは、可変長の）を含む。

トピックは、Ｔ１、Ｔ２、Ｔ３、Ｔ４のような、トークン・ベースのストリングとして定義されることもある。その際、Ｔ１、Ｔ２、Ｔ３、Ｔ４は可変長のストリングである。一例では、トピックはＩＢＭ株のリアルタイムの取引値を含むメッセージに関するトピック表記であるＮＹＳＥ．ＲＴＦ．ＩＢＭ３７６として定義されることも可能である。一部の例では、メッセージの中のトピック表記は、１つまたは複数の整数値であってよいキーに符号化される、またはマップされることも可能である。そのような場合、各トピックは、一意のキーにマップされ、トピックとキーの間でマッピングするデータベースは、Ｐ＆Ｍシステムによって保持され、オーバーザワイヤで、すべてのＭＡに更新が行われる。その結果、ＡＰＩが、１つのトピックにサブスクライブする、またはパブリッシュすると、ＭＡは、メッセージのトピック・フィールドのために使用された、関連する一意のキーを戻すことができる。

好ましくは、サブスクリプション・フォーマットは、メッセージ・トピックと同一のフォーマットに従う。しかし、サブスクリプション・フォーマットは、いずれのトピック・サブストリングとも合うワイルドカード、またはトピック・ストリングに対する通常の表現パターン一致もサポートする。実際のトピックに対するワイルドカード・マッピングを扱うことは、Ｐ＆Ｍシステムに依存すること、あるいはワイルドカードまたはパターン一致要求の複雑さに依存して、ＭＡによって扱われることが可能である。

例えば、パターン一致規則は、以下のような一致規則に従う。すなわち、
例＃１ Ｔ１．＊．Ｔ３．Ｔ４というワイルドカードを有するストリングが、Ｔ１．Ｔ２ａ．Ｔ３．Ｔ４およびＴ１．Ｔ２ｂ．Ｔ３．Ｔ４と一致するが、Ｔ１．Ｔ２．Ｔ３．Ｔ４．Ｔ５とは一致しない。
例＃２ Ｔ１．＊．Ｔ３．Ｔ４＊というワイルドカードを有するストリングが、Ｔ１．Ｔ２ａ．Ｔ３．Ｔ４およびＴ１．Ｔ２ｂ．Ｔ３．Ｔ４とは一致しないが、Ｔ１．Ｔ２．Ｔ３．Ｔ４．Ｔ５とは一致する。
例＃３ Ｔ１．＊．Ｔ３．Ｔ４．［＊］（オプションの第５の要素）というワイルドカードを有するストリングが、Ｔ１．Ｔ２ａ．Ｔ３．Ｔ４、Ｔ１．Ｔ２ｂ．Ｔ３．Ｔ４、およびＴ１．Ｔ２．Ｔ３．Ｔ４．Ｔ５とは一致するが、Ｔ１．Ｔ２．Ｔ３．Ｔ４．Ｔ５．Ｔ６とは一致しない。
例＃４ Ｔ１．Ｔ２＊．Ｔ３．Ｔ４というワイルドカードを有するストリングが、Ｔ１．Ｔ２ａ．Ｔ３．Ｔ４およびＴ１．Ｔ２ｂ．Ｔ３．Ｔ４と一致するが、Ｔ１．Ｔ５ａ．Ｔ３．Ｔ４とは一致しない。
例＃５ Ｔ１．＊Ｔ３．Ｔ４．＞（任意の数の末尾要素）という、ワイルドカードを有するストリングが、Ｔ１．Ｔ２ａ．Ｔ３．Ｔ４、Ｔ１．Ｔ２ｂ．Ｔ３．Ｔ４、Ｔ１．Ｔ２．Ｔ３．Ｔ４．Ｔ５、およびＴ１．Ｔ２．Ｔ３．Ｔ４．Ｔ５．Ｔ６と一致する。

図５は、トピック・ベースのメッセージ・ルーティングを示す。図示されるとおり、トピックは、Ｔ１．Ｔ２．Ｔ３．Ｔ４のような、トークン・ベースのストリングと定義され、ただし、Ｔ１、Ｔ２、Ｔ３、Ｔ４は可変長のストリングである。見て取ることができるとおり、特定のトピック表記４００を有する着信メッセージが、通信チャネル４０４に選択的にルーティングされ、ルーティング決定は、ルーティング・テーブル４０２に基づいて行われる。チャネルに対するトピック・サブスクリプションのマッピングにより、経路が定義され、パブリッシュ／サブスクライブ・ネットワーク全体にわたってメッセージを伝えるのに使用される。それらすべての経路のスーパーセット、またはサブスクリプションとチャネルの間のマッピングにより、ルーティング・テーブルが定義される。ルーティング・テーブルは、サブスクリプション・テーブルとも呼ばれる。ストリング・ベースのトピックを介するルーティングのためのサブスクリプション・テーブルは、いくつかの仕方で構造化できるが、好ましくは、テーブルのサイズと、ルーティング・ルックアップ速度を最適化するように構成される。１つの実装では、サブスクリプション・テーブルは、動的ハッシュ・マップ構造として定義されてもよく、別の実装では、サブスクリプション・テーブルは、図５の図に示されるとおり、ツリー構造で構成される。

ツリーは、エッジによって結び付けられたノード（例えば、Ｔ₁，．．．Ｔ₁₀）を含む。ただし、トピック・サブスクリプションの各サブストリングは、ツリーにおけるノードに対応する。所与のサブスクリプションにマップされたチャネルは、そのサブスクリプションのリーフ・ノード上に格納されて、各リーフ・ノードに関して、トピック・サブスクリプションが由来する（すなわち、受信されたサブスクリプション要求が経由した）チャネルのリストを示す。そのリストは、トピック表記がサブスクリプションと一致するメッセージのコピーを、いずれのチャネルが受信すべきかを示す。図示されるとおり、メッセージ・ルーティング・ルックアップは、メッセージ・トピックを入力として取り込み、そのトピックの各サブストリングを使用して、ツリーを解析して、その着信メッセージ・トピックに関連する、様々なチャネルを探し出す。例えば、Ｔ₁、Ｔ₂、Ｔ₃、Ｔ₄、Ｔ₅は、チャネル１、２、３に向かわせられ、Ｔ₁、Ｔ₂、Ｔ₃は、チャネル４に向かわせられ、Ｔ₁、Ｔ₆、Ｔ₇、Ｔ^*、Ｔ₉は、チャネル４と５に向かわせられ、Ｔ₁、Ｔ₆、Ｔ₇、Ｔ₈、Ｔ₉は、チャネル１に向かわせられ、Ｔ₁、Ｔ₆、Ｔ₇、Ｔ^*、Ｔ₁₀は、チャネル５に向かわせられる。

ルーティング・テーブル構造の選択は、ルーティング・ルックアップ・テーブルを最適化するように意図されているが、ルックアップのパフォーマンスは、着信メッセージ・トピックと一致する１つまたは複数のトピック・サブスクリプションを見出すためのサーチ・アルゴリズムにも依存する。したがって、ルーティング・テーブル構造は、そのようなアルゴリズムを受け容れることができなければならず、その逆も同様である。ルーティング・テーブルのサイズを小さくする１つの仕方は、ルーティング・アルゴリズムが、パブリッシュ／サブスクライブ・ネットワーク全体にわたってサブスクリプションを選択的に広めることを可能にすることによってである。例えば、あるサブスクリプションが、既に広められている別のサブスクリプションのサブセット（例えば、ストリング全体の一部分）であるように見える場合、ＭＡは、そのサブスクリプションのスーパーセットに関する情報を既に有しているので、そのサブセット・サブスクリプションを広める必要は、全くない。

以上に基づき、好ましいメッセージ・ルーティング・プロトコルは、トピック・ベースのルーティング・プロトコルであり、資格は、サブスクライバと、それぞれのトピックとの間のマッピングにおいて示される。資格は、サブスクライバごとに、またはサブスクライバのグループ／クラスごとに指定され、サブスクライバが、どのようなメッセージを消費する権利を有するか、またはいずれのメッセージが、そのようなプロデューサ（パブリッシャ）によって作成（パブリッシュ）されてもよいかを示す。それらの資格は、Ｐ＆Ｍシステムにおいて定義され、パブリッシュ／サブスクライブ・ネットワークにおけるすべてのＭＡに通信され、その後、ＭＡによって、ＭＡのルーティング・テーブルを作成し、更新するのに使用される。

パブリッシュ／サブスクライブ・ネットワーク内でルーティングされるすべてのメッセージは、特定のチャネルで受信されるか送信される。これらのチャネルを使用して、ＭＡは、パブリッシュ／サブスクライブ・ネットワーク内のすべての他の物理構成要素と通信する。しかし、これらのインタフェースが中断される時があり、あるいは宛先が負荷について行くことができない時がある。これら、およびその他の類似する状況で、メッセージを、ストレージから再び呼び出し、再送することが可能である。したがって、ストア・アンド・フォワード機能が必要な時には、必ず、ＭＡは、キャッシング・エンジン（ＣＥ）に機能的に関連する。さらに、非常にしばしば、信頼性、利用可能性、整合性が、企業オペレーションにおいて必要なので、パブリッシュ／サブスクライブ・システムは、フォールト・トレラント・システムとして展開される構成要素のいくつかを用いて、フォールト・トレランスのために設計される。

例えば、ＭＡは、第１のＭＡが１次ＭＡと呼ばれ、第２のＭＡが２次ＭＡすなわちフォールト・トレラントＭＡ（ＦＴ ＭＡ）と呼ばれる、フォールト・トレラントＭＡペアとして展開される。次に、ストア・アンド・フォワード・オペレーションのために、ＣＥ（キャッシュ・エンジン）が、１次コア／エッジＭＡまたは２次コア／エッジＭＡに接続される。１次ＭＡまたは２次ＭＡは、ＣＥに対する能動的な接続を有するときに、ルーティングされるメッセージのすべてまたはサブセットをそのＣＥに転送し、そのＣＥは、それらのメッセージを、インデクシングし、保存のためにストレージ領域に格納する。記録されたメッセージは、所定の期間にわたって、要求時の再送に利用可能である。さらに、図２に示されているように、ＣＥは、障害の場合に２次ＣＥが１次ＣＥを引き継ぐフォールト・トレラントＣＥペアとして展開されることが可能である。

図６に示されるように、ＣＥは、物理媒体を介して、ＭＡに直接に接続され、大量の、待ち時間が少ないメッセージング環境において、ストア・アンド・フォワード・アーキテクチャのフィーチャを提供するように設計される。次いで図７は、本発明の一実施形態に従って構成されたＣＥを例示するブロック図である。

ＣＥ７００は、いくつかの機能を実行する。メッセージ・データ永続性のために、１つの機能は、ＭＡによって転送されたデータ・メッセージを受信すること、様々なメッセージ・ヘッダ・フィールドを使用して、それらのメッセージに索引を付けること、それらのメッセージをストレージ領域７１０の中に格納することを含む。別の機能は、ＭＡからのメッセージ取得要求に応答すること、失われたまたは受信されなかった（そのため、コンシューマによって再び要求された）メッセージを再送することを含む。

一般に、ＣＥは、ＭＡと同一の論理レイヤ上に構築される。しかし、ＣＥのネイティブ（例えば、Ｔｅｒｖｅｌａ（商標））メッセージング・レイヤは、相当に簡略化される。ルーティング・エンジン・ロジックの必要性は全くない。というのは、パブリッシュ／サブスクライブ・ネットワークにおける別の物理構成要素にルーティングされるのとは異なり、すべてのメッセージは、ＣＥにおいてローカルで扱われて、ＣＥの管理メッセージ・レイヤ７１４に、またはＣＥのキャッシング・レイヤ７０２に送られるからである。前述の場合と同様に、管理メッセージは、キャッシング・レイヤ７０２に転送される取得要求以外は、通常、管理目的で使用されるからである。すべてのデータ・メッセージは、キャッシング・レイヤに転送され、キャッシング・レイヤは、インデキシング・サービス７１２を使用して、トピックベース・インデキシングでそれらのメッセージに最初にインデキシングを行い、次に、ストレージ領域７１０（例えば、ＲＡＩＤ、ディスクなど）の中に、それらのメッセージを格納するために、ストレージ・サービス７０８を使用する。すべてのデータ・メッセージは、しばしば冗長持続性ストレージであるストレージ領域７１０の中に事前定義された期間にわたって保持される。インデキシング・サービス７１２は、「ガーベジ・コレクション」活動を担い、有効期限が切れたデータ・メッセージが、ストレージ領域から破棄される必要がある場合、ストレージ・サービス７０８に通知する。

ＣＥは、ソフトウェア・ベースのソリューションまたは組み込みソリューションとすることが可能である。より具体的には、ＣＥは、ハイ・エンド・サーバ内のオペレーティング・システム（ＯＳ）の上で動作するソフトウェア・アプリケーションとして構成されることが可能である。そのようなサーバは、ＭＡとの間のデータ転送レートを高めるためにハイ・パフォーマンスＮＩＣ（ネットワーク・インタフェース・カード）を含む。もう１つの構成では、ＣＥは、ＭＡとの間のネットワークＩ／Ｏ（入出力）の高速化とストレージ領域との間のストレージＩ／Ｏの加速との両方のための組み込みソリューションである。そのような組込みソリューションは、１つまたは複数のディスクへのデータの効率的なストリーミングのために設計される。したがって、一般的にパフォーマンスを改善するために、ＣＥの実装は、ＭＡ−ＣＥ−ストレージ・データ転送レートを最大にし、要求されたメッセージの取得待ち時間を最小にするために設計される。

例えば、ＭＡとＣＥとの間のデータ転送を最大にするために、ＭＡとＣＥの通信リンクは、直接の１０ギガビット／ｓイーサネット・ファイバ相互接続またはＭｙｒｉｎｅｔなどの任意の他のスループットが高く待ち時間の少ない相互接続として実装される。また、このリンクでのスループットを高めるために、ＣＥは、できる限り多くのメッセージを単一の大きいフレームにパックすることが可能である。さらに、ソフトウェア・ベースのＣＥは、ＣＰＵ（中央処理装置）とＯＳをバイパスし、これによってスループットを最大にし、待ち時間を最小にするｒｅｍｏｔｅ ｄｉｒｅｃｔ ｍｅｍｏｒｙ ａｃｃｅｓｓを介してＭＡと通信する。その場合に、ストレージＩ／Ｏ効率を最大にするために、ＣＥは、ディスクＩ／Ｏを複数のストレージ・デバイスにまたがって分散させる。１つの実装で、ＣＥは、分散データベース・ロジックと分散ハイ・パフォーマンス冗長ストレージ技術の組み合わせを使用する。また、要求されたメッセージの取得待ち時間を最小にするために、ＣＥの１つの実装は、ＲＡＭ（ランダム・アクセス・メモリ）を使用して、インデックスを維持し、最も最近のメッセージまたは最も頻繁に取得されるメッセージをストレージ・デバイスにフラッシュする前にこれらのメッセージを維持する。

ＭＡとインタフェースするときに、ＣＥは、２タイプのメッセージを扱い、一方のタイプは、通常のまたは完全なデータ・メッセージであり、他方のタイプは、不完全なまたは部分的にパブリッシュされたデータ・メッセージである。具体的に言うと、ＣＥ ７００のインデクシング・サービス７１２は、部分的にパブリッシュされたメッセージを受信する時に、そのメッセージを、この部分的にパブリッシュされたメッセージのマスタ・イメージとも呼ばれる、同一トピックに関する最後の既知の完全なメッセージと比較する。インデクシング・サービス７１２は、すべての完全なメッセージについて、マスタ・イメージをＲＡＭ（図示せず）内で維持する。部分的にパブリッシュされたメッセージ（新しい値を伴うメッセージ更新）は、そのメッセージのマスタ・イメージ内の古い値を置換すると同時に、これによって更新されない未変更の値を維持する。任意の他のデータ・メッセージと同様に、部分的にパブリッシュされたメッセージはインデクシングされ、再送に使用可能である。また、ＣＥによって記録される任意の他のメッセージと同様に、マスタ・イメージも、異なるメッセージ・タイプとして供給されることが可能であること、またはそのメッセージ・ヘッダ・フラグがそれがマスタ・イメージであることを示す異なる値を有することが可能であることを除いて、再送に使用可能である。実際に、マスタ・イメージは、アプリケーションに重要である場合があり、それぞれのＡＰＩを使用することによって、そのようなアプリケーションは、任意の所与の時に、部分的にパブリッシュされたメッセージ・ストリームのマスタ・イメージを要求することが可能である。その後に、そのようなアプリケーションは、部分的にパブリッシュされたメッセージ更新を受け取る。

融合された接続中保証サービス品質（ＱｏＳ）と切断中保証サービス品質を実現するために、メッセージング・ファブリックは、常時、データ永続性とデータ保全性を維持しなければならない。フォールト・トレラント永続キャッシング・ソリューションを実現するために、これらのキャッシング・エンジンは、１次ＣＥと２次ＣＥの対からなるフォールト・トレラント・ペアとしてまたは３つ以上のＣＥノードからなるフォールト・トレラント・グループとして構成され、展開されることが可能である。３つ以上のキャッシング・エンジンが、同一トピック・ベースのサブスクリプションを介して互いに論理的にリンクされる場合に、これらは、同一のデータにサブスクライブし、したがって、サブスクライブされたデータの固有の一貫したビューを維持する。データ損失の場合に、キャッシング・エンジンは、フォールト・トレラント・グループの他のキャッシング・エンジン・メンバに、失われたデータの再生を要求することが可能である。同一のフォールト・トレラント・グループのキャッシング・エンジンの間でのデータの同期化は、メッセージング・ファブリックによって並列化され、このメッセージング・ファブリックは、ＭＡを介して、サブスクライブされたメッセージング・トラフィックのコピーをすべてのキャッシング・エンジン・インスタンスにインテリジェントにまた効率的に転送する。その結果、これは、フォールト・トレラント展開と災害復旧展開に関する非同期データ整合性を可能にする。ここで、データ同期化と永続性は、ストレージ／ディスク・ミラーリング技術またはデータベース・レプリケーション技術を活用することによるのではなく、メッセージング・ファブリックによって実行され、保証される。

冗長性とデータ整合性にメッセージング・ファブリックを使用することの利点の１つは、データとインデックス（データベース・レプリケーションに関して）および／またはディスク・ストレージ・オーバーヘッド（リモート・ディスク・ミラーリングに関して）ではなく、データだけがキャッシング・エンジンの間で同期化されるので、同期化トラフィックに起因する帯域幅利用率が下がることである。第２の利点は、メッセージング・レイヤが既に任意の所与のサブスクリプションに対するメッセージの順序を保証するので、メッセージ順序付けが解決されることである。

さらに説明するために、図８に、キャッシング・エンジン・フォールト・トレラント・ペア構成を有するメッセージング・アプライアンスを示し、１次ＭＡから２次ＭＡへのＡＰＩのフェイルオーバ・プロセスを説明する。

ＣＥ障害イベントの前すなわちフェーズ＃１で、２つのキャッシング・エンジンの両方は、同一トピックにサブスクライブしているので、同一のサブスクライブされたメッセージング・トラフィックを受信する。１次キャッシング・エンジンが故障する時、すなわちイベント＃２に、ＭＡはその故障を検出し、２次ＭＡ（１次ＭＡを引き継ぐ）にフェイルオーバし、このフェイルオーバは、２次ＭＡへのＡＰＩフェイルオーバも行う。少し後に、１次キャッシング・エンジンは、復旧し、これが、イベント＃３であり、１次キャッシング・エンジンは、そのサブスクリプションを再開始し、データの受信時に、そのサブスクリプションのすべてでデータ損失を検出する。この失われたデータは、サブスクリプションあたり１つまたは複数の再生要求を２次キャッシング・エンジンに送ることによって要求される。データ同期化フェーズは、メッセージング・ロジックを活用して、１次キャッシング・エンジンと２次キャッシング・エンジンとの間で開始される。

本発明の一実施形態では、データ同期化トラフィックは、メッセージング・ファブリックを経るが、図８に示されているように、これが同期化パス＃１である。このパスは、事前定義のメッセージ・レートまたは事前定義の帯域幅を超えないように構成されることが可能である。これは、１次キャッシング・エンジンおよび２次キャッシング・エンジンが、異なる地理的位置に置かれる場合の、ＷＡＮリンクまたは専用ファイバ接続などの帯域幅を減らされたサイト間リンクを使用する災害復旧構成にクリティカルである可能性がある。

その代わりに、本発明のもう１つの実施形態では、データ同期化トラフィックが、ＩｎｆｉｎｉｂａｎｄまたはＭｙｒｉｎｅｔなどの代替の高速相互接続直接リンクまたはスイッチを経て、同期化トラフィックを通常のメッセージング・トラフィックから分離する。そのような代替同期化パス＃２は、同期化トラフィック向けの１次リンクまたはバックアップ・リンクとして使用可能とすることが可能である。このリンクは、専用同期化パスとして静的に構成されることが可能であり、あるいは、全体的なメッセージング・ファブリック負荷に基づいてリアル・タイムで動的に選択されることが可能である。キャッシング・エンジンまたはメッセージング・アプライアンスのいずれかは、同期化トラフィックをメッセージング・ファブリックからこの代替同期化パスに移動することを判断することが可能である。

同期化が終わった時、すなわちイベント＃４の時に、１次ＣＥは、引き継ぎの準備ができている。その時に、１次ＭＡは、アクティブになるか、故障が２次ＣＥおよび／または２次ＭＡで発生するまでインアクティブのままであるかのいずれかであることが可能である。

要するに、本発明は、メッセージングの新たなアプローチを提供し、より具体的には、メッセージング・システムの有効性を改善し、キャッシング・ソリューションの管理しやすさを単純化し、様々なレベルの保証された配信サービス品質に関する回復待ち時間を減らす、フォールト・トレラント永続キャッシング機能を有する終端間パブリッシュ／サブスクライブ・ミドルウェア・アーキテクチャを提供する。本発明を、本発明の、いくつかの好ましいバージョンに関連して、相当に詳細に説明してきたが、他のバージョンも可能である。したがって、添付の特許請求の範囲の趣旨および範囲は、本明細書に含まれる好ましいバージョンの説明に限定されてはならない。

本発明の諸原理による終端間ミドルウェア・アーキテクチャを示す図である。 オーバーレイ・ネットワークを示す図である。 本発明の諸原理による終端間ミドルウェア・アーキテクチャで実施される企業インフラストラクチャを示す図である。 チャネル・ベースのメッセージング・システム・アーキテクチャを示す図である。 １つの可能なトピック・ベースのメッセージ・フォーマットを示す図である。 １つの可能なトピック・ベースのメッセージ・フォーマットを示す図である。 トピック・ベースのメッセージ・ルーティングおよびルーティング・テーブルを示す図である。 ＭＡとＣＥの間における通信のためのインタフェースを示す図である。 ＭＡとＣＥの間における通信のためのインタフェースを示す図である。 本発明の一実施形態に従って構成されたＣＥ（キャッシング・エンジン）を示すブロック図である。 １次キャッシング・エンジンと２次キャッシング・エンジンを有するフォールト・トレラント構成を示し、障害の場合の異なるフェーズを示す図である。

Claims (53)

1. １つまたは複数のアプリケーションと、
   上記アプリケーションへおよび上記アプリケーションからを含むメッセージの受信およびルーティングのために機能する複数のメッセージング・アプライアンスと、
   フォールト・トレラント構成で構成された複数のキャッシング・エンジンであって、１つまたは複数のキャッシング・エンジンは、前記複数のメッセージング・アプライアンスの中からの各指定されたメッセージング・アプライアンスに接続され、前記複数のキャッシング・エンジンのそれぞれは、対応してトピックにサブスクライブし、同一トピックにサブスクライブするキャッシング・エンジンのグループ内のすべてのキャッシング・エンジンが同一のメッセージ・データを受信し、上記トピックに関連するすべてのメッセージ・トラフィックの一貫した同期化されたビューを維持するように冗長性を提供するために、対応して前記同一トピックにサブスクライブするキャッシング・エンジンに接続された前記指定されたメッセージング・アプライアンスのいずれかに論理的にリンクされる、複数のキャッシング・エンジンと
   を含むメッセージング・システム。
2. 前記複数のメッセージング・アプライアンスを含み、メッセージ・ファブリックを介してまたはキャッシング・エンジン間の直接接続が存在する場合に上記直接接続を介して、前記一貫した同期化されたビューを提供するように機能する、前記メッセージ・トラフィックをルーティングするメッセージング・ファブリックであって、リアル・タイム・フェイルオーバが、メッセージング・アプライアンスまたはキャッシング・エンジンのいずれかによって、メッセージング・ファブリック負荷に基づいて判断される、メッセージング・ファブリックを有する請求項１に記載のメッセージング・システム。
3. 前記直接接続は、高速直接接続またはスイッチを含む請求項２に記載のメッセージング・システム。
4. 前記高速直接接続は、Ｉｎｆｉｎｉｂａｎｄ相互接続またはＭｙｒｉｎｅｔ相互接続を含む請求項３に記載のメッセージング・システム。
5. 前記一貫した同期化されたビューを維持するために、各キャッシング・エンジンは、前記メッセージ・データを獲得するのに予め決めた帯域幅および／またはメッセージ・レートを使用するように機能する請求項１に記載のメッセージング・システム。
6. １つまたは複数のキャッシング・エンジンの故障の時に、同一のメッセージング・アプライアンスに接続されているアクティブのままである任意の他のキャッシング・エンジンが前記故障したキャッシング・エンジンを引き継ぎ、アクティブであるものが残っていない場合またはそのメッセージング・アプライアンスを伴う任意の他の故障の時に、前記故障したメッセージング・アプライアンスの前記キャッシング・エンジンに論理的にリンクされたもう１つのメッセージング・アプライアンスが、それを引き継ぐように機能し、すべての引き継ぎが、故障したキャッシング・エンジンおよび／またはメッセージング・アプライアンスに論理的に接続された前記１つまたは複数のアプリケーションに対してトランスペアレントである請求項１に記載のメッセージング・システム。
7. 回復した、任意の故障したキャッシング・エンジンは、失われたデータをそれに送るように、アクティブのままである別のキャッシング・エンジンに要求することによって、前記失われたデータを取得するようにさらに機能する請求項６に記載のメッセージング・システム。
8. 各キャッシング・エンジンは、
   メッセージを送信し、受信するように機能するメッセージ・レイヤと、
   まず受信されたメッセージをインデクシングし、受信された部分的にパブリッシュされたメッセージのイメージを維持するように機能するインデクシング・サービスを有するキャッシング・レイヤと、
   受信されたメッセージのすべてまたはサブセットを前記ストレージに格納するように機能するストレージおよびストレージ・サービスと、
   受信されたメッセージと送信されたメッセージをトランスポートする１つまたは複数の物理チャネル・インターフェースと、
   前記１つまたは複数の物理チャネル・インターフェースのそれぞれを介するメッセージの送信と受信を制御するチャネル管理を有するメッセージ・トランスポート・レイヤと
   を含む請求項１に記載のメッセージング・システム。
9. 各キャッシング・エンジン内の前記ストレージは、格納された受信されたメッセージが上記キャッシング・エンジンからの要求時の再送信に一時的に使用可能なままであることを可能にするように機能する請求項８に記載のメッセージング・システム。
10. メッセージング・ファブリックと、メッセージング・ファブリックを介して前記メッセージング・アプライアンスにリンクされ、各メッセージング・アプライアンスと管理メッセージを交換するように構成されたプロビジョニング・マネージメント・システムとをさらに含む請求項１に記載のメッセージング・システム。
11. 各メッセージング・アプライアンスは、さらに、メッセージ伝送プロトコルとメッセージ・ルーティング・パスを動的に選択することによってメッセージの前記ルーティングを実行するように機能する請求項１に記載のメッセージング・システム。
12. 前記メッセージング・ファブリックは、チャネル・ベースであり、ファブリックにこだわらない物理媒体である相互接続を含む請求項１に記載のメッセージング・システム。
13. 前記相互接続は、イーサネット（登録商標）、メモリ・ベースの直接接続、またはＩｎｆｉｎｉｂａｎｄとして構成される請求項１２に記載のメッセージング・システム。
14. 前記相互接続は、スループットが高く待ち時間が少ない相互接続のために機能する直接１０ギガビット・イーサネット・ファイバ相互接続またはＭｙｒｉｎｅｔ相互接続としてである請求項１２に記載のメッセージング・システム。
15. 前記メッセージは、前記メッセージが前記メッセージング・システムに入る時に互いから分離され、メッセージが前記メッセージング・システムから出る時に組み合わされる、スキーマとペイロードを用いて構成される請求項１に記載のメッセージング・システム。
16. 前記メッセージと管理メッセージがトピック・ベースのフォーマットを有し、各メッセージがヘッダとペイロードを有し、前記ヘッダが送信元名前空間識別フィールドと宛先名前空間識別フィールドに加えてトピック・フィールドを含む請求項１０に記載のメッセージング・システム。
17. 前記メッセージは、トピック・フィールドを有するサブスクリプション・メッセージを含み、前記トピック・フィールドは、上記トピックと前記サブスクリプション・メッセージが同一の数のトピック・サブストリングを有するという条件付きで前記トピックを任意のトピック・サブストリングと一致させる任意の数のワイルド・カードを有する可変長ストリングを有する請求項１に記載のメッセージング・システム。
18. 前記キャッシング・エンジンは、メッセージ・データ・ストア・アンド・フォワード機能を含むサービス品質機能を提供するように機能する請求項１に記載のメッセージング・システム。
19. 各キャッシング・エンジンに関連する前記ストレージは、メッセージ入出力を分散させるように機能する複数のストレージ・デバイスを含む請求項８に記載のメッセージング・システム。
20. 各キャッシング・エンジン内の前記メッセージ・レイヤは、管理メッセージを扱うように機能する管理メッセージ・レイヤを含む請求項８に記載のメッセージング・システム。
21. 各キャッシング・エンジン内の前記メッセージ・レイヤは、要求されたメッセージを前記キャッシング・レイヤから取得し、ヘッダ・フィールドとペイロードを有する受信されたメッセージをフォーマットするように機能する請求項８に記載のメッセージング・システム。
22. 前記キャッシング・レイヤは、さらに、ランダム・アクセス・メモリ（ＲＡＭ）を含み、前記インデクシング・サービスは、さらに、前記イメージを前記ＲＡＭ内で維持するように機能する請求項８に記載のメッセージング・システム。
23. 前記キャッシング・レイヤによって受け取られ、維持される各部分的にパブリッシュされたメッセージの前記イメージは、更新値および前記更新によって変更されない古い値を含む請求項８に記載のメッセージング・システム。
24. その間に前記メッセージが前記ストレージ内で再送に一時的に使用可能なままである時間は、所定である請求項９に記載のメッセージング・システム。
25. 前記ストレージは、冗長永続メモリ・デバイスである請求項８に記載のメッセージング・システム。
26. ソフトウェア・ベースの構成または組み込みベースの構成として提供される請求項１に記載のメッセージング・システム。
27. オペレーティング・システムの上で動作するソフトウェア・アプリケーション内で実施される請求項１に記載のメッセージング・システム。
28. メッセージング・トラフィックの前記一貫した同期化されたビューは、前記メッセージング・システムが部分的パブリッシュ型、融合型、接続中保証型、切断中保証型のうちの１つまたは組み合わせを含むメッセージング・サービス品質を提供できるようにする請求項１に記載のメッセージング・システム。
29. 複数のメッセージング・アプライアンスを有するメッセージング・ファブリックを構成するステップと、
    １つまたは複数のキャッシング・エンジンが前記複数のメッセージング・アプライアンスの中からの各指定されたメッセージング・アプライアンスに接続されるフォールト・トレラント構成で複数のキャッシング・エンジンを構成するステップと、
    冗長性を与えるために、トピックへのサブスクリプションによって、前記複数のキャッシング・エンジンのそれぞれを、上記キャッシング・エンジンと共通して類似するトピックにサブスクライブされた接続された１つまたは複数の他のキャッシング・エンジンである前記指定されたメッセージング・アプライアンスのうちのいずれかに論理的にリンクするステップと、
    同一のトピックにサブスクライブするキャッシング・エンジンのグループごとに、前記グループ内のすべてのキャッシング・エンジンが、同一のメッセージ・データを受信し、上記トピックに関連するすべてのメッセージ・トラフィックの一貫した同期化されたビューを維持するように、内のすべてのキャッシング・エンジンを同期化するステップであって、上記同期化は、メッセージング・サービス品質の提供を可能にする、同期化するステップと
    を提供することを含む、メッセージング・システム内でサービス品質を提供する方法。
30. メッセージング・サービス品質は、部分的パブリッシュ・メッセージング、融合されたメッセージング、接続中保証メッセージング、切断中保証メッセージングを含む請求項２９に記載の方法。
31. １つまたは複数のキャッシング・エンジンの故障の時に、同一のメッセージング・アプライアンスに接続された、アクティブのままである任意の他のキャッシング・エンジンによって、前記故障したキャッシング・エンジンを引き継ぐステップと、アクティブであるものが残っていない場合またはそのメッセージング・アプライアンスを伴う任意の他の故障の時に、前記故障したメッセージング・アプライアンスの前記キャッシング・エンジンに論理的にリンクされたもう１つのメッセージング・アプライアンスによって、前記故障したメッセージング・アプライアンスを引き継ぐステップとをさらに含む請求項２９に記載の方法。
32. 前記キャッシング・エンジンのそれぞれと１つまたは複数のアプリケーションとの間をそれらのめいめいの指定されたメッセージング・アプライアンスを介してインターフェースするステップをさらに含み、すべての引き継ぎが、故障したキャッシング・エンジンおよび／またはメッセージング・アプライアンスに論理的に接続された前記１つまたは複数のアプリケーションに対してトランスペアレントである請求項２９に記載の方法。
33. 前記一貫した同期化されたビューを維持するステップは、メッセージ・ファブリックを介してまたはキャッシング・エンジン間の直接接続が存在する場合に上記直接接続を介して、達成され、リアル・タイム・フェイルオーバは、メッセージング・アプライアンスまたはキャッシング・エンジンのいずれかによって、メッセージング・ファブリック負荷に基づいて判断される請求項２９に記載の方法。
34. メッセージング・トランスポート・レイヤ、管理メッセージ・レイヤ、キャッシング・レイヤを、インデクシング・サービスと関連するストレージと共に有するキャッシング・エンジン内で
    データと管理メッセージを前記メッセージ・トランスポート・レイヤによって受信するステップと、
    管理メッセージを前記管理メッセージ・レイヤに、データ・メッセージを前記キャッシング・レイヤに転送するステップであって、前記管理メッセージ・レイヤに転送されたメッセージ取得要求メッセージは、前記キャッシング・レイヤにルーティングされる、ステップと、
    前記インデクシング・サービス内で前記データ・メッセージをインデクシングするステップであって、前記インデクシングがトピック・ベースである、ステップと、
    前記インデクシングに基づいて、前記データ・メッセージをストレージ・デバイス内に格納するステップであって、前記データ・メッセージは、メッセージ取得要求メッセージに応答する再送に使用可能である所定の期間の間に前記ストレージ・デバイス内で維持される、ステップと
    を実行するステップ
    を含む、キャッシング・エンジンを用いてサービス品質を提供する方法。
35. 前記データ・メッセージは、完全なデータ・メッセージまたは部分的にパブリッシュされたデータ・メッセージのいずれかである請求項３４に記載のキャッシング・エンジンを用いてサービス品質を提供する方法。
36. 各データ・メッセージは関連するトピックを有し、前記インデクシング・サービスは各完全なデータ・メッセージのマスタ・イメージを維持し、部分的に完全なメッセージである受信されたデータ・メッセージについて、前記インデクシング・サービスは、前記受信されたデータ・メッセージを、前記部分的にパブリッシュされたメッセージの関連トピックに類似する関連トピックを有する完全なメッセージの最も最近のマスタ・イメージと比較して、前記マスタ・イメージをどのように更新しなければならないかを決定する請求項３５に記載のキャッシング・エンジンを用いてサービス品質を提供する方法。
37. 前記部分的にパブリッシュされたメッセージがインデクシングされ、再送に使用可能である請求項３５に記載のキャッシング・エンジンを用いてサービス品質を提供する方法。
38. 前記マスタ・イメージがインデクシングされ、再送に使用可能である請求項３６に記載のキャッシング・エンジンを用いてサービス品質を提供する方法。
39. メッセージを送信し、受信するように機能するメッセージ・レイヤと、
    まず受信されたメッセージをインデクシングし、受信された部分的にパブリッシュされたメッセージのイメージを維持するように機能するインデクシング・サービスを有するキャッシング・レイヤ、ストレージ、受信されたメッセージのすべてまたはサブセットを前記ストレージに格納するように機能するストレージ・サービスであって、前記受信されたメッセージのすべてまたはサブセットは、要求時の再送信に一時的に使用可能なままになる、キャッシング・レイヤ、ストレージ、ストレージ・サービスと、
    受信されたメッセージおよび送信されたメッセージをトランスポートする１つまたは複数の物理チャネル・インターフェースと、
    前記１つまたは複数の物理チャネル・インターフェースのそれぞれを介するメッセージの送信と受信を制御するチャネル管理を有するメッセージング・トランスポート・レイヤと
    を含む、メッセージング・システム内のキャッシング・エンジン。
40. 故障時に２次キャッシング・エンジンが１次キャッシング・エンジンを引き継ぐ、フォールト・トレラント・キャッシング・エンジン・ペアまたはフォールト・トレラント・キャッシング・エンジン・グループの一部としてフォールト・トレラント機能を有して展開される請求項４１に記載のキャッシング・エンジン。
41. 前記メッセージ・レイヤは、管理メッセージを扱うように機能する管理メッセージ・レイヤを含む請求項４２に記載のキャッシング・エンジン。
42. 前記メッセージ・レイヤは、要求されたメッセージを前記キャッシング・レイヤから取得し、ヘッダ・フィールドとペイロードを有する受信されたメッセージをフォーマットするように機能する請求項３９に記載のキャッシング・エンジン。
43. 前記キャッシング・レイヤは、さらに、ランダム・アクセス・メモリ（ＲＡＭ）を含み、前記インデクシング・サービスは、さらに、前記イメージを前記ＲＡＭ内で維持するように機能する請求項３９に記載のキャッシング・エンジン。
44. 前記キャッシング・レイヤによって受け取られ、維持される各部分的にパブリッシュされたメッセージの前記イメージは、更新値および前記更新によって変更されない古い値を含む請求項３９に記載のキャッシング・エンジン。
45. 前記メッセージが前記ストレージ内で再送に一時的に使用可能なままである時間は、所定である請求項３９に記載のキャッシング・エンジン。
46. 前記ストレージは、冗長永続メモリ・デバイスである請求項３９に記載のキャッシング・エンジン。
47. ソフトウェア・ベースの構成または組み込みベースの構成として提供される請求項３９に記載のキャッシング・エンジン。
48. オペレーティング・システムの上で動作するソフトウェア・アプリケーション内に埋め込まれる請求項３９に記載のキャッシング・エンジン。
49. 部分的データ・パブリケーション・サービスと、保証接続と保証切断のメッセージ配信サービス品質とを提供するように機能する請求項３９に記載のキャッシング・エンジン。
50. 前記ストレージは、メッセージ入出力を分散させるように機能する複数のストレージ・デバイスを含む請求項３９に記載のキャッシング・エンジン。
51. 前記キャッシング・エンジンのオペレーションを管理するように機能するプロビジョニング・マネージメント・システムをさらに含む請求項１に記載のメッセージング・システム。
52. 前記アプリケーションがネイティブ・メッセージ・フォーマットでパブリッシュし、サブスクライブするステップを可能にするように機能する１つまたは複数のアプリケーション・プログラミング・インターフェースをさらに含む請求項１に記載のメッセージング・システム。
53. 前記メッセージング・アプライアンスのいずれかに関連し、前記アプリケーションが外部メッセージ・フォーマットでパブリッシュし、サブスクライブするステップを可能にするように機能する、１つまたは複数のプロトコル変換エンジンをさらに含む請求項１に記載のメッセージング・システム。

Images