(57)【要約】  メッセージ・パブリッシュ／サブスクライブ・システムは、少ない待ち時間およびパフォーマンス・ネックで大量メッセージを処理するのに必要である。本発明によって提案された終端間ミドルウェア・アーキテクチャは、とりわけ、構成、プロビジョニングおよび監視システム・パフォーマンスを集中化単一ポイント・プロビジョニング−マネージメントに提供することによって、大量で少ない待ち時間のメッセージングに対して設計されている。この機能性により、近隣ベースのルーティングによる中間ホップを減らすこと、およびシステム相互接続構成およびメッセージ伝送プロトコルの動的リアルタイム最適化が考えられる。
2008527860.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は、チャネル５に向かわせられる。
【００６８】
ルーティング・テーブル構造の選択は、ルーティング・ルックアップ・テーブルを最適化するように意図されているが、ルックアップのパフォーマンスは、着信メッセージ・トピックと一致する１つまたは複数のトピック・サブスクリプションを見出すためのサーチ・アルゴリズムにも依存する。したがって、ルーティング・テーブル構造は、そのようなアルゴリズムを受け容れることができなければならず、その逆も同様である。ルーティング・テーブルのサイズを小さくする１つの仕方は、ルーティング・アルゴリズムが、パブリッシュ／サブスクライブ・ネットワーク全体にわたってサブスクリプションを選択的に広めることを可能にすることによってである。例えば、あるサブスクリプションが、既に広められている別のサブスクリプションのサブセット（例えば、ストリング全体の一部分）であるように見える場合、ＭＡは、そのサブスクリプションのスーパーセットに関する情報を既に有しているので、そのサブセット・サブスクリプションを広める必要は、全くない。
【００６９】
以上に基づき、好ましいメッセージ・ルーティング・プロトコルは、トピック・ベースのルーティング・プロトコルであり、資格は、サブスクライバと、それぞれのトピックとの間のマッピングにおいて示される。資格は、サブスクライバごとに、またはサブスクライバのグループ／クラスごとに指定され、サブスクライバが、どのようなメッセージを消費する権利を有するか、またはいずれのメッセージが、そのようなプロデューサ（パブリッシャ）によって作成（パブリッシュ）されてもよいかを示す。それらの資格は、Ｐ＆Ｍシステムにおいて定義され、パブリッシュ／サブスクライブ・ネットワークにおけるすべてのＭＡに通信され、その後、ＭＡによって、ＭＡのルーティング・テーブルを作成し、更新するのに使用される。
【００７０】
各ＭＡは、そのＭＡのルーティング・テーブルを、誰が、どのようなトピックに関心があるか（サブスクライブを要求しているか）を常に把握しておくことにより、更新する。しかし、ＭＡは、経路をＭＡのルーティング・テーブルに追加する前に、パブリッシュ／サブスクライブ・ネットワークの資格に照らしてサブスクライブをチェックしなければならない。ＭＡは、近隣のＭＡ、Ｐ＆Ｍシステム、ＣＥ、またはＡＰＩであることが可能な、サブスクライブするエンティティが、サブスクライブすることを許可されていることを検証する。サブスクリプションが有効である場合、経路は、作成され、ルーティング・テーブルに追加される。その場合、一部の資格は、あらかじめ知られていることがあるため、システムは、事前定義された資格を伴って展開されることが可能であり、それらの資格が、起動時に自動的に読み込まれることが可能である。例えば、構成更新のような、一部の特定の管理メッセージは、ネットワーク全体にわたって既に転送されていることが可能であり、したがって、始動時に自動的に読み込まれることが可能である。
【００７１】
サブスクリプション・プロセスにおける役割に加えて、Ｐ＆Ｍシステムは、いくつかの他の管理機能も有する。それらのさらなる機能には、パブリッシュ／サブスクライブ・システム構成が含まれ、かつ健全性の監視と報告が含まれる。構成は、パブリッシュ／サブスクライブ・システムのネットワークを含み、かつ構成要素の物理構成と論理構成をともに含む。監視と報告は、すべてのネットワークとシステムの構成要素の健全性を監視して、要求に応じて、またはログに、結果を自動的に報告することを含む。
【００７２】
Ｐ＆Ｍは、パブリッシュ／サブスクライブ・システム用の集中化単一ポイント・プロビジョニング−マネージメント・プラットフォームである。中心位置でのメッセージ・パブリッシュ／サブスクライブ・システム内の全ての構成要素を構成し、監視する能力と、任意選択でシステム内のプロビジョン・ソフトウェアとファームウェアを構成し、監視する能力が提供される。したがって、Ｐ＆Ｍシステムはプロビジョニングと構成管理機能構成要素を有すると言われる。また、Ｐ＆Ｍシステムは既存のソリューションを利用するように、外部のプロビジョニング−マネージメント・システムと統合することができる。
【００７３】
Ｐ＆Ｍシステムのプロビジョニング機能構成要素がイネーブルである場合、各メッセージ・パブリッシュ／サブスクライブ・システム構成要素のプロビジョニング（すなわち、システム構成要素がエッジＭＡ、コアＭＡ、ＡＰＩなどである場合の、各アプライアンス、デバイスまたはサブシステムのプロビジョニング）が管理メッセージを介して行われ、システム・アドミニストレータが、自動的にまたは手動で、機能性を遠隔で入れるまたは切り、ソフトウェアとファームウェア画像アップグレードを遠隔でスケジューリングまたは「プッシュ」することが可能になる。ソフトウェアまたはファームウェア画像の例としては、ソフトウェア・パッケージ、フル・オペレーティング・システム（ＯＳ）ディスク画像、ファームウェア・バイナリ画像などが挙げられる。各システム構成要素は、コア・モジュールと、任意選択で、１つまたは複数のビジネス・モジュールを有する。これらのモジュールは、新たなソフトウェア画像をプッシュすることによって、独立してアップグレードすることができる。
【００７４】
上記のようにプロビジョニング機能性をイネーブルにしたＰ＆Ｍシステムにより、メッセージ・パブリッシュ／サブスクライブ・システムの管理をより制御可能、拡張可能、費用効率良くする、モジュール・アップグレードの自動スケジューリングが可能になる。Ｐ＆Ｍシステムはさらに、ビジネス・モジュールとフィーチャがイネーブルにされたトラック、およびそれぞれ運用しているソフトウェア画像バージョンを保持することによって、ソフトウェア画像バージョン制御を提供する。一実施形態では、ビジネス・モジュールに関連するソフトウェア画像の故障を検出する際、Ｐ＆Ｍシステムはモジュールをソフトウェア画像の最近知られている機能バージョンに自動的にダウングレードするように設計されている。
【００７５】
Ｐ＆Ｍシステムの構成管理機能構成要素は、ユーザ管理とユーザ資格（すなわち、データをサブスクライブし、パブリッシュする権利）のために設計されている。ＡＰＩ、および（そのメッセージがプロトコル変換エンジンによって変換される）全ての外部データ送信元と宛先を使用する全てのアプリケーションは、（例えば、クライアント・アプリケーションを介して）ユーザに関連している。このユーザは、あらゆるパブリケーションおよび／またはサブスクリプション・イベントが可能になる場合に、Ｐ＆Ｍシステムによって認証されなければならない。パスワード、既知共有キーまたはトークン、ＰＫＩ証明書を含む、様々な認証方法が可能である。ユーザが認証されると、ユーザはそのユーザ資格に応じてデータをサブスクライブまたはパブリッシュすることが可能になる。Ｐ＆Ｍシステムからの情報に基づき、ＭＡはパブリッシュ／サブスクライブ・システム・メッセージ・トラフィック内でメッセージをパブリッシュする、またはメッセージにサブスクライブしようと試みる場合に、ユーザ資格を確認する。このようなユーザおよび資格管理フレームワークは、世界的規模で、分散アクセス機能性を可能にする。
【００７６】
加えて、Ｐ＆Ｍシステムによって、システム管理者が、メッセージ・パブリッシュ／サブスクライブ・システム全体にわたってルーティングされるメッセージのそれぞれに関連するメッセージ名前空間を定義することを可能になる。したがって、メッセージ・パブリッシュ／サブスクライブ・システムは、名前空間ベースのサブシステムに物理的、および／または論理的に分割可能である。名前空間ベースのトポロジが、図６に示される。
【００７７】
名前空間は、各パブリッシュ／サブスクライブ・サブシステム１３、１４に対して一意である。したがって、複合メッセージ・パブリッシュ／サブスクライブ・システムでは、各パブリッシュ／サブスクライブ・サブシステムに、一意の名前空間が割り当てられている。この例では、パブリッシュ／サブスクライブ・システムは、２つのパブリッシュ／サブスクライブ・サブシステム、「Ｎａｍｅｓｐａｃｅ１」という名前空間を有する第１のサブネットワークと、「Ｎａｍｅｓｐａｃｅ２」という名前空間を有する第２のサブネットワークから成る。Ｐ＆Ｍシステムの名前空間管理フィーチャ（図７のアイテム５２０、５１２）が、様々な管理ドメインを定義し、それらの様々な管理ドメインにわたって、トピック衝突またはトピック重複を回避しながら、トピック・ベースのメッセージ通信を可能にする機能を提供する。
【００７８】
一例では、パブリッシュ／サブスクライブ・サブシステム「Ａ」が、パブリッシュ／サブスクライブ・サブシステム「Ｂ」に向かってルーティングされるニュース更新をパブリッシュし、サブシステム「Ｃ」が、やはり、サブシステム「Ｂ」に向かってルーティングされるニュース更新をパブリッシュする。しかし、サブシステム「Ａ」と「Ｃ」が、同一のトピックに関する同一のニュース更新をパブリッシュした場合、サブシステム「Ｂ」は、「Ａ」から来るニュースと「Ｃ」から来るニュースを、それらのニュースに関連する名前空間によって、区別することができる。多くの実例では、それらの名前空間ドメインは、様々な組織内ドメインである。他の実例では、それらのドメインは、様々な組織エンティティ・ドメインまたは法的エンティティ・ドメインである。つまり、名前空間フィーチャは、組織によって、組織のデータまたはコンテンツに対する資格を、その組織内、または組織外部の数名のユーザに限定するのに使用することができる。組織内のユーザに関して、これは、それらのユーザに名前空間ライセンスを発行することによって行われ、組織外部のユーザに関して、これは、組織がＭＡを有するという条件付きで、組織に名前空間ライセンスを発行することによって行われる。
【００７９】
前述の例は、名前空間を利用することによってデジタル権利管理（ＤＲＭ）機能をどのように実施するかを示している。さらに、異なる源からデータを消費するユーザは、データ源（例えば、待ち時間）のパフォーマンス・メトリックを見ることによって最良のデータ源を判断することができる。別の方法では、異なる源からのデータのユーザは、これらの異なる源からのデータを比較することによって、データの再結合と検証を行うことができる。
【００８０】
Ｐ＆Ｍシステムはまた、メッセージ・パブリッシュ／サブスクライブ・システム内の展開された物理的構成要素全てのネットワーク管理構成全てを遠隔制御することが可能である。例えば、このようなものとしては、ＮＩＣ構成（ＩＰアドレス／ネットワーク・マスク、速度、双方向、ＭＴＵなど）、ＶＬＡＮインタフェース、ローカルＩＰルーティング、ポーリングに利用可能なＳＮＭＰ  ＭＩＢ、ＳＨＨ、ｔｅｌｎｅｔ、ｈｔｔｐ、ｈｔｔｐｓなどの遠隔アクセス法、ＤＮＳ、ＮＴＰなどの他のネットワーク・サービスなどが挙げられる。
【００８１】
Ｐ＆Ｍシステムは、全てのパブリッシュ／サブスクライブ近隣（例えば、ＭＡ、ＣＥ、ＡＰＩ）やこれらの間の全ての論理接続を備えた、パブリッシュ／サブスクライブ・システム内の仮想完全メッシュ・オーバーレイ・ネットワークの図を提供する。システム・アドミニストレータは、どの論理接続をアクティブまたは非アクティブにするべきであるかを選択することができる。その結果、Ｐ＆Ｍシステムは、オーバーレイ・パブリッシュ／サブスクライブ・ネットワークの正確なトポロジを制御し、かつメッセージがメッセージ・パブリッシュ／サブスクライブ・システム全体を通してどのようにルーティングされるかを制御する。
【００８２】
Ｐ＆Ｍシステムの第３の機能構成要素は、システム構成要素によって生成されるメッセージ・パブリッシュ／サブスクライブ・システムの健全性とイベントのリアルタイム監視である。この態様は、Ｐ＆Ｍシステムのアーキテクチャを検討する際に後でより詳細に説明する。
【００８３】
Ｐ＆Ｍシステムの第４の機能構成要素は、終端間システム・パフォーマンスの制御と監視である。トポロジ情報が利用可能な状態で、メッセージ・パブリッシュ／サブスクライブ・システムを通るビジネス・メッセージ・フローを特定し、このような情報フローに割り当てられるリソースを制御することが可能である。したがって、期待され要求されたパフォーマンス・レベルを予測し保証することが可能である。例えば、Ｐ＆Ｍシステムによって、メッセージ優先順位、サービスの品質、プロトコル最適化サービスなどの適応サービスのリアルタイム挙動、メッセージ・フロー制御、メッセージ融合、インテリジェント・メッセージ・ルーティングなどのメッセージング・トラフィック管理ポリシーをシステム・アドミニストレータが定義することができる。
【００８４】
加えて、Ｐ＆Ｍシステムは、システム終端間視野からのいくつかのメッセージ処理タスクを行うのに必要なＣＰＵサイクルの数、パブリッシュ／サブスクライブ・ネットワークの１つのエッジから別のエッジまで必要な帯域幅の量、メッセージング・ホップ毎の最大許容待ち時間、最大終端間待ち時間などの、リソース予約の仕様を可能にするように設計される。これらのパラメータは、所与のユーザ、所与のサブスクリプション、所与のチャネル、または２つの近隣間の所与の論理接続に対して定義することができる。
【００８５】
Ｐ＆Ｍシステムは、情報によって照会することも、情報をシステム構成要素に押し込むこともできる。押し込み機能は、これらのシステム構成要素のいずれかの挙動を手動で制御するのに有用である可能性がある。キャッシング・エンジン（ＣＥ）とＡＰＩは両方とも、これらに対するプロキシとして働くＭＡを介してＰ＆Ｍシステムとインタフェース接続することに留意されたい。Ｐ＆Ｍシステムと直接通信する唯一の近隣はＭＡである。一時的機能構成要素がイネーブルである場合、押し込み機能はさらに、Ｐ＆Ｍシステムが単一管理ポイントからあらゆるソフトウェアとファームウェア画像をアップグレードすることを可能にする。
【００８６】
Ｐ＆Ｍシステムのアーキテクチャをより詳細に例示するため、図７は本発明の一実施形態によるＰ＆Ｍシステムを示すブロック図である。図示されるとおり、Ｐ＆Ｍシステム５００は、パブリッシュ／サブスクライブ・ネットワークにおける１つまたは複数のＭＡに通信するスタンドアロンのアプライアンスとして展開される。代替の実施形態では、Ｐ＆ＭシステムはＭＡに統合されることが可能である。
【００８７】
Ｐ＆Ｍシステムは、アプライアンス・メッセージ・レイヤ５０２の管理メッセージ・レイヤ５０６から獲得される管理メッセージを介して、構成機能、監視機能、報告機能を実行する。ネットワークにおける他の構成要素との通信は、メッセージング・トランスポート・レイヤ５０４を介して行われ、システムにおける構成要素に一般的な、すべての前述したチャネル管理は、本発明の諸原理に従って構成される。しかし、物理媒体インタフェース群と直接に対話する、ＭＡにおけるメッセージ・トランスポート・レイヤとは異なり、Ｐ＆Ｍシステムは、しばしば、オペレーティング・システム（ＯＳ）５２８の上で実施され、ＯＳ５２８を介して、メッセージング・トランスポート・レイヤは、物理媒体インタフェース群（インタフェース１．．．Ｎ）と通信する。したがって、様々なタイプのチャネルをサポートするために、ＯＳは、さもなければ、ＯＳで提供されない、各物理媒体に関する特定のドライバを要求する可能性がある。また、ＯＳは、媒体に関する特定のインタフェース・カード（例えば、直接接続インタフェース・カードまたはＩｎｆｉｎｉｂａｎｄインタフェース・カード）も要求することができる。
【００８８】
また、Ｐ＆Ｍは、ネットワーク管理スタック５０８を使用して、ネットワーク・ベースの管理サービスと通信することも可能である。そのようなネットワーク・ベースのサービスの例には、ＳＮＭＰ（簡易ネットワーク管理プロトコル）、システム・ログ記録、ＨＴＴＰ／ＨＴＴＰＳ（セキュア・ソケット・レイヤーを介してのハイパーテキスト・トランスファー・プロトコル）、Ｔｅｌｎｅｔ／ＳＳＨ（セキュア・シェル・プロトコル）が含まれる。
【００８９】
Ｐ＆Ｍは、いくつかの機能ブロックの上に構築された、グラフィカル・ユーザ・インタフェース（ＧＵＩ）５１０を備えることが可能である。そのような機能ブロックの例には、構成マネージャ５１２、リアルタイム監視ブロック５１４、履歴トレンディング・ブロック５１６、ビジネス・ロジック／アプリケーション報告ブロック５１８が含まれる。構成マネージャ機能ブロックは、パブリッシュ／サブスクライブ・ネットワークにかかわるすべての物理構成要素の構成を扱う。それらの構成要素のそれぞれの構成５２０には、例えば、セキュリティ、暗号化、認証、資格（いずれのユーザが、いずれのトピックにサブスクライブすることを許されるかについての権利）や、トポロジ（それらの異なる構成要素間の通信パスを含む）を含む、いくつかの態様がかかわる。
【００９０】
リアルタイムの監視機能ブロック５１４が、パブリッシュ／サブスクライブ・ネットワークにおいて生じる様々なイベント５２２をリッスン（スニフィング）する。それらのイベントの例には、ＡＰＩからの新たなサブスクリプション要求、パブリッシュ／サブスクライブ・ネットワークに接続された新たなサブスクライバ、ネットワーク化されたパブリッシュ／サブスクライブ・システムにおける異なるハードウェア構成要素に関するリアルタイムの統計、すべてのＭＡに関するルーティング・テーブルのサイズ、リソース利用のレベルが含まれる。
【００９１】
履歴トレンディング・ブロック５１６は、好ましくは、トレンドが、リアルタイムで監視されたイベントから、時とともに確立されることが可能であるために、リアルタイムの監視サブシステムに緊密にリンクされる。その目的で、履歴トレンディング・ブロックは、リアルタイムの監視サブシステムから入力を取り込み、各データ・ポイントをリアルタイム・データベースの中に格納する。その後、履歴トレンディング・ブロックは、リアルタイム・データベースに照会して、データベースが、時間の関数として受け取ったイベントを表にする。このブロックは、時とともにパブリッシュ／サブスクライブ・ネットワーク挙動パターンを追跡するのにさらに使用されることもある。
【００９２】
ビジネス・ロジック報告ブロック５１８は、ビジネス意思決定プロセスに役立てるために、時とともにイベント・パターンの生のデータを互いに関係付けることにより、別のレベルの報告をもたらす。１つの実装では、ビジネス・ロジック報告ブロックは、低レベル・メッセージとネットワーク・メトリック・データ（通常の生のデータ）をビジネス・メトリックに変換する。その低レベル・メッセージとネットワーク・メトリック・データの例は、メッセージを含み、かつフレーム・レート、ネットワーク遅延、ジッタ、損失データを含む。
【００９３】
また、オプションとして、リアルタイム監視−ビジネス・ロジック報告ブロックが、ＳＬＡ（サービス・レベル合意）を監視し、特定のサービス・レベルが、時が経つなかで満たされていることを検証する。ＳＬＡが、満たされていない場合、そのＳＬＡは、すべての当事者が、そのようなレポートの妥当性について合意しているものと想定して、どこに問題があるか、ＳＬＡが、どのように守られているかについての理解と法的証明を可能にする。さらに、履歴メトリックのトレンドを確立することは、メッセージング・インフラストラクチャの変化を理解することに役立つ可能性があり、長期のメッセージング・トラフィック・パターンへの洞察を与える可能性がある。その結果、履歴メトリックのトレンドを確立することは、ビジネス決定プロセスへの非常に貴重なインプットとなる。
【００９４】
その管理と監視のオペレーションをサポートするため、Ｐ＆Ｍシステムは、バックエンド・データベースにおいて、構成、監視した統計、オプションのソフトウェアとファームウェア画像、オプションのビジネス・モジュールを維持する。また、上で述べたように、システムの利用可能性と信頼性、およびメッセージ・データの整合性と永続性のために、Ｐ＆Ｍシステムをデータベース・レプリケーションまたはデータ同期の形を使用するフォールト・トレラント・システムとして構成することが有利である。
【００９５】
特に、Ｐ＆Ｍシステムはフォールト・トレラント・ペアとして展開され、一次と二次Ｐ＆Ｍシステムは同様のまたは異なる地理的位置に配置することが可能である。Ｐ＆Ｍシステムは同期する必要があるので、バックエンド・データベース・リプリケーション・フィーチャを利用することによって同期を実行することが可能である。別の方法では、Ｐ＆Ｍシステムがバックエンド・データベースにおけるあらゆる変更を二次Ｐ＆Ｍシステムに通知する責任があるメッセージング・レベルで同期を実行することが可能である。これらの通知は、最後の同期から起こったデータベース・デルタ（変更）を含む管理メッセージを送信することによって通信される可能性があり、二次データベースにも行われるべきである。
【００９６】
システム構成要素の構成と監視のため、通信は管理メッセージを介して行われる。したがって、ＭＡと通信するために、Ｐ＆Ｍシステムは、例示した実施形態では、（メッセージ・レイヤ５０２、メッセージ・トランスポート・レイヤ５０４、チャネル・マネージメント５２６とともに）チャネル・ベース・メッセージング・スタック５０８を使用する。図８は、Ｐ＆Ｍシステムと、ＭＡの１つとの間の通信を例示する図である。
【００９７】
しかし、管理トラフィックをデータ・トラフィックから物理的、論理的に分離するために、図９に示すように、各ＭＡを各ＶＬＡＮに物理的に接続した状態で、下層切換ファブリック内に２つの異なるＶＬＡＮ（仮想ＬＡＮ）を構成することが可能である。この方法は、データ・トラフィックの完全性を保持する利点を有する。データ・トラフィックが管理トラフィックによって遅延されるまたは影響を受けないようにさらに保護するため、データＶＬＡＮに必要なサービス品質（ＱｏＳ）を提供するように、異なるスイッチとルータを構成することができる。その結果、構成アップデートと監視分析は両方とも、メッセージ・パブリッシュ／サブスクライブ・ネットワークの全体のパフォーマンスとリアルタイム挙動に影響を与えることなく、管理ＶＬＡＮ上でルーティングされる。さらに、全ての管理トラフィックはＭＡの制御面によって送受信される。また、したがって、データ・トラフィックのルーティングの責任があるデータ面には影響を与えない。図示するように、一実施形態では、全てのＭＡは２つの異なる物理的インタフェースを介して両方のＶＬＡＮに接続され、各Ｐ＆Ｍシステムは管理ＶＬＡＮを介してこれらと通信することによって、全てのＭＡを構成と監視することが可能である。ＣＥはＭＡに直接接続されており、したがって、ＭＡとＣＥの間で交換されるトラフィックはあらゆる他のメッセージング・トラフィックに影響を与えないことに留意すること。加えて、それぞれのＡＰＩを介したアプリケーションはデータＶＬＡＮに接続されている。
【００９８】
要するに、本発明は、メッセージングの新たなアプローチを提供し、より具体的には、メッセージング・システムの有効性を向上させるＰ＆Ｍシステムをもつ終端間ミドルウェア・アーキテクチャを提供する。本発明を、本発明の、いくつかの好ましいバージョンに関連して、相当に詳細に説明してきたが、他のバージョンも可能である。したがって、添付の特許請求の範囲の趣旨および範囲は、本明細書に含まれる好ましいバージョンの説明に限定されてはならない。
【図面の簡単な説明】
【００９９】
【図１】本発明の諸原理による終端間ミドルウェア・アーキテクチャを示す図である。
【図１ａ】オーバーレイ・ネットワークを示す図である。
【図２】本発明の諸原理による終端間ミドルウェア・アーキテクチャで実施される企業インフラストラクチャを示す図である。
【図２ａ】ネットワーク・バックボーン・ディスインターメディエーションを作成するＭＡ群（メッセージアプライアンス群）を有する、企業インフラストラクチャの物理的展開を示す図である。
【図３】チャネル・ベースのメッセージング・システム・アーキテクチャを示す図である。
【図４ａ】１つの可能なトピック・ベースのメッセージ・フォーマットを示す図である。
【図４ｂ】１つの可能なトピック・ベースのメッセージ・フォーマットを示す図である。
【図５】トピック・ベースのメッセージ・ルーティングおよびルーティング・テーブルを示す図である。
【図６ａ】名前空間ベースのトポロジを有するメッセージング（パブリッシュ／サブスクライブ）システムを示す図である。
【図６ｂ】名前空間ベースのトポロジを有するメッセージング（パブリッシュ／サブスクライブ）システムを示す図である。
【図７】本発明の一実施形態によるＰ＆Ｍ（プロビジョニング−マネージメント）システムを示すブロック図である。
【図８ａ】Ｐ＆Ｍシステムと、ＭＡ（メッセージアプライアンス）の１つとの間の通信を示す図である。
【図８ｂ】Ｐ＆Ｍシステムと、ＭＡ（メッセージアプライアンス）の１つとの間の通信を示す図である。
【図９】２つのＶＬＡＮを通したデータおよび管理メッセージ・トラフィックの分離を示す図である。
【図１】
2008527860.tif 000003
【図１ａ】
2008527860.tif 000004
【図２】
2008527860.tif 000005
【図２ａ】
2008527860.tif 000006
【図３】
2008527860.tif 000007
【図４ａ】
2008527860.tif 000008
【図４ｂ】
2008527860.tif 000009
【図５】
2008527860.tif 000010
【図６ａ】
2008527860.tif 000011
【図６ｂ】
2008527860.tif 000012
【図７】
2008527860.tif 000013
【図８ａ】
2008527860.tif 000014
【図８ｂ】
2008527860.tif 000015
【図９】
2008527860.tif 000016
【国際調査報告】
2008527860.tif 000017