JP7360395B2 - 入力および出力スキーママッピング - Google Patents

Description

本願発明の一実施例は、例えば、入力および出力スキーママッピングに関する。

[0001]コンピューティングシステムの相互接続は、いわゆる“クラウド”コンピューティングシステムなどの分散コンピューティングシステムを促進してきた。本説明において、“クラウドコンピューティング”は、管理努力またはサービスプロバイダ相互作用の低減を伴ってプロビジョニングおよびリリースされ得る構成可能なコンピューティングリソース（例えば、ネットワーク、サーバ、ストレージ、アプリケーション、サービスなど）の共有プールへのユビキタスで便利なオンデマンドのネットワークアクセスを可能にするためのシステムまたはリソースであり得る。クラウドモデルは、様々な特徴（例えば、オンデマンドセルフサービス、幅広いネットワークアクセス、リソースの共有、迅速な拡張性、サービスが計測可能など）、サービスモデル（例えば、Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ（“ＳａａＳ”）、Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ（“ＰａａＳ”）、Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ（“ＩａａＳ”））、および実装モデル（例えば、プライベートクラウド、コミュニティクラウド、パブリッククラウド、ハイブリッドクラウドなど）から構成され得る。

[0002]クラウドおよびリモートベースのサービスアプリケーションは、広く行き渡っている。そのようなアプリケーションは、パブリックおよびプライベートリモートシステム（クラウドなど）上でホストされ得、通常、クライアントと通信のやり取りをするためのウェブベースのサービスのセットを提供する。

[0003]コンピューティングシステム（例えば、クラウド内）を相互接続する１つの利益は、一部のエンティティが、特定のイベントが起こったときに通知され得ることである。例えば、システムは、現状では、人間のサブスクライバーがニュースなどの情報を自動的に受信することを可能にする体制を有する。いくつかの通知システムが現在利用可能であるが、これらのシステムは多くの欠点および不備を有する。例えば、サービスおよびアプリケーションは、多くの場合、独自のフォーマットまたは通信プロトコルを使用することから、複数のアプリケーションおよびサービスを相互接続することは非常に時間がかかりかつ労力を要するプロセスであり得る。したがって、これらのアプリケーションおよびサービスを結び付けるための従来の技術は、非常に厳正であり、拡張のための柔軟性、スケーラビリティ、および将来的な相互接続を提供することができない。さらには、多くの従来のイベント通知方法論は、主に人間のサブスクライバーのために構成される。その結果、任意のタイプのサブスクライバーに通知するための、およびスケーラビリティ機能を含むための柔軟かつ信頼性の高いシステムを提供する大きな必要性がある。

[0004]本明細書において特許請求される主題は、任意の不利益を解決する実施形態、または上に説明されるものなどの環境においてのみ動作する実施形態に限定されない。むしろ、この背景技術は、本明細書に説明されるいくつかの実施形態が実践され得る１つの例示的な技術を例証するためだけに提供される。

本願発明の一実施例は、例えば、入力および出力スキーママッピングに関する。

[0005]開示された実施形態は、イベントを管理するためのシステムおよび方法、ならびにさらにより詳細には、アプリケーション、サービス、およびエンティティを相互接続するためのシステムおよび方法を対象とする。いくつかの場合において、これは、準拠しないデータを準拠するようにプログラムで処理することを含む。他の場合において、これは、１つまたは複数のパブリッシングサービスからのイベントデータを１つまたは複数のサブスクライバーにプッシュすることを含む。

[0006]例えば、いくつかの実施形態において、方法およびシステムは、準拠しないデータを処理するために提供される。これらの実施形態は、イベントグリッドサービスを通じて登録情報を受信するという初期行為など、様々な行為を含む。この情報は、パブリッシングサービスとイベントグリッドサービスとの間の関係（すなわち、登録）を確立するのに有用である。登録プロセスを支援するため、登録情報は、パブリッシングサービスがそのデータをどのようにフォーマットするか（すなわち、フォーマットのためにそれが使用するスキーマ）に関する詳細を含む。この情報はまた、サブスクライバーが聞いているトピックと関連付けられる。次いで、イベントグリッドサービスは、パブリッシングサービスのイベントスキーマを分析して、そのスキーマがトピックのために使用されるデフォルトのスキーマに相関するかどうかを決定する。相関がない場合、または部分的な相関のみがある場合、イベントグリッドサービスは、パブリッシングサービスのスキーマをトピックのデフォルトのスキーマにマッピングすることを試みるマッピングを自動的に導出することができる。このマッピングが導出された後、イベントグリッドサービスは、パブリッシングサービスからイベント発行を受信する。その後、イベントグリッドサービスは、このマッピングを使用して、発行内のデータを、データがトピックのデフォルトのイベントスキーマに含まれるイベントフィールドに正しくマッピングするような様式で翻訳する。このプロセスは、パブリッシングサービスおよびサブスクライバーが結び付けられることを、パブリッシングサービスが準拠していないコンテンツをサブスクライバーフォーマットに発行するときにさえ、および、それらのエンティティのいずれかが自らのネイティブフォーマット技術を変更または修正する必要なしに、可能にする。

[0007]いくつかの実施形態において、システムおよび方法は、イベントグリッドサービスを通じて、１つまたは複数のパブリッシングサービスからのイベントデータを、そのイベントデータの１つまたは複数のサブスクライバーにプッシュするために提供される。具体的には、トピックと関連付けられたイベント発行を受信した後、そのトピックに関心のあるサブスクライバーが識別され得る。いくつかの場合において、（１）サブスクライバーは、イベントグリッドサービスとのサブスクリプションを有し、（２）サブスクリプションは、サブスクライバーが通知されることを希望するイベントデータのタイプを識別し、（３）発行に含まれるイベントデータは、サブスクライバーのための関連情報を実際に含む。いくつかの場合において、イベントデータがサブスクライバーのための準拠するスキーマにあるかどうかに関して決定がなされる。そうである場合、マッピングは実施されない。そうでない場合、マッピングプロセスがイベントデータに対して実施される。次いで、関連データが、イベントデータの他の部分からフィルタリング／抽出され、次いでそれは、サブスクライバーにプッシュされる。

[0008]いくつかの実施形態において、システムおよび方法は、パブリッシングサービスからイベント発行を受信するため、および特定の情報をその情報のサブスクライバーにプッシュするために利用可能である。最初に、イベントグリッドサービスは、確立されたトピックに対応し、かつイベントデータを含むイベント発行を（例えば、パブリッシングサービスから）受信する。マッピングの使用により、イベントグリッドサービスは、イベントデータのうちのいくつかを、それがトピックのために確立されているイベントスキーマ内のフィールドに位置対応するようにマッピングすることができる。このマッピングが完了した後、この情報のサブスクライバーは、関連イベントデータ（上に説明されるデータなど）が受信されるときに通知され得る。ここでは、サブスクライバーは、イベントグリッドサービスとのサブスクリプションを有し、このサブスクリプションが、サブスクライバーがどのタイプのデータを通知されることを望むかを識別する。マッピングされたデータは、サブスクライバーが受信することを望む情報に対応する特定のデータを含む。続いて、関連データは、非関連データから隔離され、その後サブスクライバーにプッシュされ得る。

[0009]本概要は、発明を実施するための形態において以下にさらに説明されるいくつかの概念を簡略化した形式で紹介するために提供される。本概要は、特許請求された主題の主な特徴または必須の特徴を識別することが意図されるものではなく、特許請求された主題の範囲を決定することを助けるものとして使用されることが意図されるものでもない。

[0010]追加の特徴および利点は、以下に続く説明において明記され、また部分的には説明から明白であり、または、本明細書内の教示の実践により学習され得る。本発明の特徴および利点は、添付の特許請求の範囲において具体的に指摘される機器および組み合わせを用いて実現および獲得され得る。本発明の特徴は、以下の説明および添付の特許請求の範囲からより完全に明らかになるものとし、または、以後明記されるような本発明の実践により学習され得る。

[0011]上に列挙した利点および特徴ならびに他の利点および特徴が獲得され得る様式を説明するために、上に簡単に説明される主題のより具体的な説明が、添付の図面に例証される特定の実施形態への参照により提供される。これらの図面は典型的な実施形態を描写するにすぎず、したがって範囲を限定するものと見なされるべきではないという理解で、実施形態は、添付の図面の使用を通じて追加的な具体性および詳細を伴って説明される。

[0012]クライアントがとり得る様々な形態を実証する図である。 [0013]どのようにしてクライアントがサービス（例えば、クラウドベースのサービス）と対話することができるかを例証し、さらに、サービスが独自の入力／出力スキーマを使用して動作し得ることを示す図である。 [0014]サービスの入力／出力スキーマのフォーマットに関する追加の詳細を提供する図である。 [0015]異なるクライアントがサービスを集中型イベントグリッドサービスに登録している例示的なアーキテクチャを例証する図である。 [0016]準拠しないスキーマであり得るサービスのスキーマを、準拠しており、かつイベントグリッドサービスおよび／または特定のサブスクライバーによって動作可能である新規スキーマへと翻訳／相関／マッピングするために、どのようにしてマッピングが導出され得るかを実証する図である。 [0017]サブスクライバーが、任意の数のサービスによって発行されるイベント発行を受信するために、イベントグリッドサービスとのサブスクリプションを確立することができる例示的なアーキテクチャを示す図である。 [0018]マッピングおよびトピック管理に関連したプロセスを提供するために連携して働く計算およびストレージリソースのクラスタのセットを提供することによって、ユーザーのための透過的なスケールアウトおよびフェイルオーバー能力を提供する例示的なアーキテクチャを示す図である。 [0019]サービスがイベントグリッドサービスにイベント発行を発行しており、イベント発行が、特定のトピックに特有であり、サブスクライバーが、それらのイベント発行に関する情報を受信している、例示的なアーキテクチャを示し、さらに、イベントグリッドサービスがフロントエンド翻訳／相関プロセスを実施することができることを示す図である。 [0020]サービスが、イベント発行をイベントグリッドサービスにプッシュする前に、翻訳プロセスを実施している例示的なアーキテクチャを示す図である。 [0021]イベントグリッドサービスが、イベントデータをサブスクライバーにプッシュする前に、バックエンド翻訳プロセスを実施することができる例示的なアーキテクチャを示す図である。 [0022]イベントグリッドサービスが、フロントエンド翻訳プロセスおよびバックエンド翻訳プロセスの両方を実施することができることを示す図である。 [0023]単一のサブスクライバーが、複数の異なるトピックに対応するイベントデータを受信することができることを実証する図である。 [0024]複数の異なるサービスが、同じトピックのためのイベントデータを発行することができること、および、複数の異なるサブスクライバーが、その同じトピックのためのイベントデータを受信することができることを例証する図である。 [0025]準拠しないデータスキーマでコンパイルされる受信したデータを、準拠するデータスキーマに含まれるイベントフィールドにマッピングするための例示的な方法のフローチャートを例証する図である。 [0026]１つまたは複数のパブリッシングサービスから受信されるイベントデータを、イベントデータに対応するトピックの１つまたは複数のサブスクライバーにプッシュするための例示的な方法のフローチャートを例証する図である。 [0027]１つまたは複数のパブリッシングサービスからイベント発行を受信するため、およびイベント発行内に含まれる情報を１つまたは複数のサブスクライバーにプッシュするための例示的な方法のフローチャートを例証する図である。 [0028]本明細書に説明される動作のいずれかを実施するように構成される例示的なコンピューターシステムを例証する図である。

[0029]開示された実施形態のうちのいくつかは、１つのフォーマットで整理されるイベントデータが異なるフォーマットに翻訳され得るように、イベントグリッドサービスがマッピングをインテリジェントに生成することを可能にするシステムおよび方法に関する。この点に関して、イベントグリッドサービスは、異なるタイプの入力フォーマットを識別して、多くの異なるタイプの出力フォーマットに変換することができる。これらの動作を実施することによって、任意の数の異なるアプリケーションおよびサービスは、それらのサービスおよびアプリケーションが自らのネイティブフォーマット方法論を変更または修正することを必要とせずに相互接続され得るため、かなりの利点が実現される。

[0030]いくつかの実施形態において、イベントグリッドサービスは、特定のフォーマットで整理されるイベントデータが受信されるときを検出し、次いで、そのフォーマットが既存のフォーマットに準拠するかどうかを決定する。それが既存のフォーマットに準拠する場合、イベントグリッドサービスは、導出されたマッピングを使用して翻訳プロセスを実施する必要はない。しかしながら、特定のフォーマットが、準拠しない、または部分的にしか準拠しない場合、イベントグリッドサービスは、マッピングをインテリジェントに導出し、このマッピングは次いで、イベントデータを、それが既存のフォーマット内のデータフィールドに対応するように翻訳するために使用される。後に説明されるように、このマッピングを導出し、この翻訳を実施することは共に、インテリジェントなやり方で実施され、多くの異なる因子に基づき得る。

[0031]いくつかの実施形態において、イベントデータは、そのイベントデータのサブスクライバーにプッシュされ得る。例えば、特定のトピックのためのイベントデータが受信され得る。トピックおよびデータを識別した後、適切なサブスクライバー（すなわち、登録プロセスを通じてこのトピックに関心があることを表明しているサブスクライバー）は、このイベントデータに関して通知され得る。イベントデータが、サブスクライバーに好適なスキーマで配置される場合、マッピングは実施されない。しかしながら、そうでない場合は、マッピングプロセスがイベントデータに対して実施されて、データがサブスクライバーの要件に従ってフォーマットされることを確実にする。その後、いくつか（またはすべて）の関連データは、次いでサブスクライバーにプッシュされる。

[0032]いくつかの実施形態において、システムおよび方法は、パブリッシングサービスからイベント発行を受信するため、および特定の情報をその情報のサブスクライバーにプッシュするために利用可能である。最初に、イベントグリッドサービスは、確立されたトピックに対応し、かつイベントデータを含むイベント発行を（例えば、パブリッシングサービスから）受信する。マッピングの使用により、イベントグリッドサービスは、イベントデータのうちのいくつかを、それがトピックのために確立されているイベントスキーマ内のフィールドに位置対応するようにマッピングすることができる。このマッピングが完了した後、この情報のサブスクライバーは、関連イベントデータ（上に説明されるデータなど）が受信されるときに通知され得る。ここでは、サブスクライバーは、イベントグリッドサービスとのサブスクリプションを有する。このサブスクリプションは、（後により詳細に説明されるように）サブスクライバーが、どのタイプのデータを通知されることを望むかを識別する。マッピングされたデータは、サブスクライバーが受信することを望む情報に対応する特定のデータを含む。続いて、関連データは、非関連データから隔離され、その後サブスクライバーにプッシュされ得る。

[0033]先に説明されるように、従来の通知およびマッピング技術は、それらが他のアプリケーションおよびシステムとの相互運用を促進することができない厳密なスキーマを必要とすることから、非常に厳正で柔軟性がない。対照的に、開示された実施形態は、非常に動的であり、サブスクライバーをパブリッシングサービスと相互接続するための柔軟な選択肢を提供する。その結果、任意の数のエンティティが、シームレスな様式で、およびそれらのエンティティが変更または修正される必要なしに、相互接続され得る。さらには、イベントグリッドサービスは以前のマッピングを格納することができるため、イベントグリッドサービスは、新規のマッピングを導出するときに、それらの既存のマッピングから学習することができる。この点に関して、イベントグリッドサービスは、マッピング導出プロセスを向上させるため、あるいは改善するために、マシン学習を利用し得る。

[0034]実施形態のいくつかおよび利点のいくつかを高水準で説明したが、これより、クライアントがとり得る様々な形態のうちのいくつかを例証する図１に注目する。その説明の後、パブリッシングサービスの属性のうちのいくつかを説明する図２および図３に注目する。次いで、図４～図１２が論じられる。これらの図は、どのようにしてイベントグリッドサービスが動作するかに関して、様々なアーキテクチャおよび補助的な例証を説明する。その議論の後、どのようにしてイベントグリッドがイベント発行を処理し得るかについての様々な例示的な方法を説明する図１３～図１５に注目する。最後に、図１６が提示される。この図は、開示された動作のいずれかを実施するように構成され得る例示的なコンピューターシステムを説明する。
クライアントおよびサービス
[0035]クラウド動作は、典型的には、複数の異なるサービスまたはアプリケーションを構成する、または相互接続することによって、構築される。例として、アプリケーションは、ファイルを格納するため、高速のキー値ルックアップを実施するため、および特定のビジネスロジックをホストするためにサービスを使用するように構成され得る。いくつかの状況では、任意の数のこれらのサービスまたはアプリケーションは、独自のカスタムアプリケーションロジック、データフォーマット技術、または通信プロトコルを有し得る。これらの異なる構成が理由で、多くの場合、これらのエンティティを相互に結び付けるのは非常に労力を要しかつ時間のかかる取り組みである。開示された実施形態は、任意の数のサービスおよびアプリケーション間の高い相互運用性を提供することが可能な柔軟かつ非常に動的なイベント駆動型アーキテクチャをもたらすことによって、これらのニーズ（ならびに他のニーズ）を満足する。

[0036]これらのサービスおよびアプリケーションが作業を実施するとき、それらは、多くの場合、イベントの作成をトリガする。イベントは、システム内で起こっている何らかのアクションまたは動作を完全に説明する最小量の情報である。イベントの例としては、限定されるものではないが、ファイル、テーブル、ディレクトリ、もしくはデータベースの作成（例えば、コンピューター上、内部ネットワーク内、またはクラウド内）、それらの構築物（すなわち、ファイル、テーブルなど）の修正、それらの構築物のいずれかの削除、またはハードウェアもしくはソフトウェアによって認識可能である任意の他の検出可能な出来事（例えば、クラウド内で実行するサービスは、イベントを実行および／または検出することができる）が挙げられる。イベントは、典型的には、限定されるものではないが、イベントを生成したソースの識別、イベントが起こった時間もしくは作成された時間、またはイベントのための固有の識別子などの情報を含む。

[0037]いくつかの実施形態において、イベントはまた、イベントを引き起こした特定のアクションまたは動作にのみ関連する特定の情報を含む。例えば、イベントが、新規ファイルがファイルディレクトリまたはストレージ内に作成されるときにトリガされる場合、そのイベントは、ファイルに関する特定の詳細事項、ファイルのメタデータ、ファイルの場所などを含み得る。イベントが、仮想マシン（ＶＭ）がリブートする（または何らかの他のタイプの動作を実施する）ときにトリガされる場合、そのイベントは、問題のＶＭに関する特定の情報（例えば、アドレス、ソフトウェア情報、ハードウェア情報など）、リブートの理由、および／または他の関連情報を含み得る。

[0038]クラウド・ファーストおよびサーバレスの世界では、イベントは、１つのアプリケーションまたは複数のアプリケーションの様々な異なる態様を接続する象徴的な“糊”である。イベントは、マイクロサービス、クラウドサービスから、ネットワークエッジから、またはインターネット・オブ・シングス（“ＩｏＴ”）デバイスからさえも生じ得る。イベントは、インフラストラクチャ自動化から、またはアプリケーション通信からファイアする。イベントは、データプラットフォームからのトリガとして、または複雑な分析および人工知能（“ＡＩ”）サービスを接続するための手段としてファイアされ得る。イベントのソースおよびコンシューマ（すなわち、サブスクライバー）は、クラウド（例えば、パブリックおよびプライベート）およびネットワークエッジに広がっていて、非常に数多く多様である。

[0039]“イベントソース”は、典型的には、アクション、動作、または他のタイプの出来事（すなわち、“イベント”）が起こるところの、というよりも、イベントが発生するところのシステムである。後でより詳細に説明されるように、イベントは、イベントサブスクライバーが、興味のあるイベントのタイプに基づいてどのトピックをサブスクライブすべきかを適切に決めることができるように、トピックに分類され得る。トピックはまた、サブスクライバーが、イベントをコンシュームする仕方を発見することができるようにイベントスキーマを提供する。

[0040]先に説明されるように、関心のあるエンティティ（すなわち、サブスクライバーまたはコンシューマ）がイベントに関する情報を受信することを望むという状況が存在し得る。イベントサブスクライバーは、それらがイベントに関する通知を受信したときに、それらのイベントに反応することに関心のある他のアプリケーションまたはサービスである。例として、イベントサブスクライバーは、最初、それが、特定のタイプのストレージファイルが特定のエンドポイントにおいて作成されるときに発行を受信することに関心があることを示すことができる。その後、サブスクライバーは、後でより詳細に説明されるように、それがそのイベントに関する通知を受信した後に特定の様式で反応し得る。イベントは、典型的には、非同期様式で生成されることから、イベントのサブスクライバーは、イベントが正確にいつ発生するかについて知ることはできない。本明細書で使用される場合、イベントハンドラー、ハンドラー、イベントサブスクライバー、およびサブスクライバーという用語は、同義に使用されるものとする。

[0041]開示された実施形態によると、イベントグリッドは、ソースをサブスクライバーと相互接続する構成概念である。イベントグリッドの観点から、サブスクライバーは、イベントが向かっているところの、およびイベントを首尾よく処理するために何らかのさらなるアクションが発生し得るところの最終の地である。基本的な導入として、イベントグリッドは、複数のサブスクライバータイプをサポートし、（サブスクライバーに応じて）イベントグリッドは、イベントの配信を保証するために異なる機序に従う。例えば、イベントを配信することは、ハンドラーが状態コード（例えば、状態コード２００－ＯＫ）を返すまで、繰り返しリトライされ得る。ストレージキューイングの場合、イベントは、キューサービスがメッセージを首尾よく処理することができるまでリトライされ得る。

[0042]そのイベントを外部の第三者に知らせるため、イベントのソースは、イベント発行を介してそのイベントと発行し得る。イベント発行は、１つまたは複数のエンティティにブロードキャスト送信される。上に論じられる例を使用すると、イベント発行は、ファイルが作成されたことを示す発行であり得る。イベント発行は、例えば、イベントがいつ発生したか、もしくは発行がいつ作成されたか、発生したイベントのタイプは何であるか、どのエンティティがイベントを開始したのか（すなわち、パブリッシングサービスの識別、またはイベント発行が関連付けられるカスタマアカウントがどれであるかの識別）、どのエンティティがイベントにより影響を受けるか、イベント発行のタイプ、および／またはイベントと関連付けられた任意の他の情報を含む、イベントに関する詳細を含み得る。イベント発行は、イベント自体、またはイベントの要約版であり得る。

[0043]この点に関して、外部エンティティは、イベントに関する詳細または細目を提供するイベント発行を受信することによって、イベントについて学習することができる。例として、クラウド内で実行するファイルサービスについて検討する。新規ファイルがファイルサービスによって作成されると、イベントが発生し（すなわち、新規ファイルの作成）、ファイルサービスは、そのイベントに関するイベント発行を生成することができる。このファイルサービスは、イベント発行を、ファイル作成について学習することに関心があり得る任意の他のサービス、アプリケーション、またはエンティティに伝送することができる。

[0044]実践的な例として、クライアントが自分の自動車が損傷したときに自分の自動車の写真をアップロードすることを可能にするように構成される自動車保険アプリケーションについて検討する。これらの写真は、支払請求の際に役に立つ。自動車保険アプリケーションは、ユーザーのモバイルデバイス上で実行可能であるフロントエンドクライアントアプリケーションを有し得る。ユーザーが自分の自動車の写真を撮り、次いでフロントエンドクライアントアプリケーションを使用してそれらの写真をアップロードするとき、フロントエンドクライアントアプリケーションは、写真ファイルがクラウド内に作成される写真アップロードイベントを実行する。自動車保険アプリケーションに未決請求を通知するため、写真アップロードイベントに対応するイベント発行が、自動車保険アプリケーションに配信され得る。この様式では、自動車保険アプリケーションは、請求が未決であるときに通知され、“請求処理”フェーズを開始することができる。

[0045]それでは、これより、サービス（後の図に示される）を、サービスがイベント発行を生成することができるように構成することができるクライアント１００の例を示す図１に注目する。図１に示されるように、クライアント１００は、多くの異なる形態をとり得る。例えば、クライアント１００は、人間のユーザーがサービスを構成するために対話することができるユーザーポータル１０５（すなわち、ユーザーインタフェース）であり得る。クライアント１００はまた、コマンドラインツール１１０であり得る。代替的に、クライアント１００は、独立して通信すること、およびサービスを構成することができるソフトウェアアプリケーション１１５であり得る。省略記号１２０は、クライアント１００が他の形態をとり得ること、および単に図１に示される形態に限定されないことを実証する。

[0046]図２は、図１のクライアント１００の例示的な実装形態であるクライアント２００を示す。ここでは、クライアント２００は、サービス２０５と通信している。サービス２０５は任意のタイプのサービスであり得ることを理解されたい。単に例として、サービス２０５は、Ｅメールサービス、カレンダーサービス、データストレージサービス、ソーシャルネットワーキングサービス、ドキュメントサービス、バックアップサービス、金融サービス、ヘルスケアサービス、政府サービス、または任意の他のタイプのサービスであり得る。

[0047]示されるように、サービス２０５は、独自のデータフォーマットスキーマ（すなわち、スキーマ２１０）を含む。本明細書で使用される場合、“スキーマ”（例えば、スキーマ２１０）は、エンティティ（例えば、サービス２０５）が、それが操作するデータをどのように整理およびフォーマットするかを表す。例えば、スキーマ２１０は、サービス２０５のデータ設計図またはデータベース構造を象徴的に表す。

[0048]図３は、スキーマ（別名フォーマット技術）についてより詳細に示す。具体的には、図３は、図２のサービス２０５の例示的な実装形態であり得るサービス３００、およびスキーマ２１０の例示的な実装形態であり得るスキーマ３０５を示す。示されるように、スキーマ３０５は、いくつかのデータフィールド（例えば、“ｎａｍｅ”、“ｔｙｐｅ”、および“ｔｉｍｅ”）を含む。省略記号３１０は、スキーマ３０５が任意の数のデータフィールドを有し得ること、および単に図３に示されるものに限定されないことを実証する。

[0049]この例示的なシナリオでは、サービス３００は、“ｎａｍｅ”データフィールドに名前“Ｆｏｏ”が入っており、“ｔｙｐｅ”データフィールドにタイプ“Ｆｉｌｅ Ｃｒｅａｔｉｏｎ”が入っており、“ｔｉｍｅ”データフィールドに時間“５－２１－２０１８＠１３：５１：２３”が入っているデータに対して動作する。当然ながら、これらは例示的なデータ値であり、限定するものとして見なされるべきではない。サービス３００は、スキーマ３０５の多くの異なるインスタンスを使用して、各インスタンスが隔離されたデータを含むが、それにもかかわらず、スキーマ３０５によって要求される様式でフォーマットされるように、動作し得る。
サービスの登録
[0050]多くの場合において、イベント発行を集中型サービス（すなわち、イベントグリッド）にプッシュすることが望ましく、その結果として、集中型サービスは次いで、（１）それらのイベント発行を整理し、（２）任意の特に関連した情報をフィルタリングして取り出し、（３）その関連した情報を関心のあるエンティティにプッシュすることができる。そのような構成は、図４においてアーキテクチャ４００により示される。

[0051]具体的には、アーキテクチャ４００は、クラウド４０５、およびクラウド４０５において動作する集中型イベントグリッドサービス４１０を含む。イベントグリッドサービス４１０は、任意の数のアプリケーションプログラムインターフェース（ＡＰＩ）、例えば、ＡＰＩ４１５およびＡＰＩ４２０などを含む。ＡＰＩ４１５および４２０は、以下により詳細に説明されるように、クライアントが最初にパブリッシングサービスをイベントグリッドサービス４１０に登録することを可能にするためにクライアントに対して公開され得る動作構成概念（例えば、ツール、ルーチン、プロトコルなど）である。

[0052]イベントグリッドサービス４１０はまた、サブスクリプションデータベース４２５と関連付けられる。サブスクリプションデータベース４２５は、イベントグリッドサービス４１０を動作させている同じノードに含まれ得るか、またはサブスクリプションデータベース４２５は、異なるノードに位置し得るが、イベントグリッドサービス４１０によりアクセス可能である。サブスクリプションデータベース４２５がどこに位置するかにかかわらず、イベントグリッドサービス４１０は、格納のために登録データ４３０をサブスクリプションデータベース４２５に渡すことができる。簡単な導入として、サブスクリプションは、サブスクライバーが受信することに関心があるトピックのためのイベントがどれであるかについて命令を提供する。サブスクリプションはまた、どのようにしてイベントがサブスクライバーに配信されるべきかに関する構成データを保持するアーチファクトである。

[0053]アーキテクチャ４００はまた、クライアント４３５およびクライアント４４０を含む。クライアント４３５および４４０は、図２のクライアント２００の例示的な実装形態であり得る。アーキテクチャ４００はまた、サービス４４５を、その対応するスキーマ４５０と共に、およびサービス４５５を、その対応するスキーマ４６０と共に含む。これらのサービスおよびスキーマは、図３のサービス３００およびスキーマ３０５の例示的な実装形態であり得る。

[0054]先に説明されるように、多くの場合、サービスがイベント発行を外部エンティティに伝送するようにサービスを構成することが望ましい。この場合、サービス４４５および４５５は、サービス４４５および４５５がイベント発行をイベントグリッドサービス４１０に“プッシュ”または伝送するように、それぞれクライアント４３５および４４０によって構成されている。それをするために、イベントグリッドサービス４１０は、最初、そのＡＰＩ４１５および４２０をクライアント４３５および４４０にそれぞれ公開し、その結果として、トピックがイベント発行を整理するために作成され得る。

[0055]開示された実施形態によると、サービスは、確立された“トピック”に基づいてイベント発行をイベントグリッドサービス４１０にプッシュする。本明細書で使用される場合、“トピック”は、どんなイベントが関連するのかを理解するための初期基盤を提供する構成可能な主題領域である。トピックの例は、限定されるものではないが、いくつか例を挙げてみると、特定のサービスのためのトピック（例えば、そのサービスのためのすべてのイベントがそのトピックに分類される（または属する））、特定のカスタマのためのトピック（例えば、カスタマからのすべてのイベントがそのトピックに分類される）、特定のタイプのイベントのためのトピック（例えば、特定のタイプのすべてのイベントが、それらのイベントがいつまたはどこで生じるかにかかわらず、そのトピックに分類される）、サービス、カスタマ、および／またはイベントのグループのためのトピックを含む。これらは単に例であり、より広範な原則が適用されるものとする。

[0056]例としてクライアント４３５を使用すると、サービス４４５のイベントグリッドサービス４１０への初期登録の間、クライアント４３５は、ＡＰＩ４１５を使用して、イベントグリッドサービス４１０がどのように動作するかを学習することができる。例えば、クライアント４３５は、イベントグリッドサービス４１０が特定のトピックのためにどのタイプのスキーマを使用するかを学習することができる。サービス４４５がどのようにしてそのスキーマ４５０を含むかに類似して、イベントグリッドサービス４１０もまた、トピックごとに１つまたは複数の異なるスキーマを使用して動作するように構成される。イベントグリッドサービス４１０は集中型サービスであるため、イベントグリッドサービス４１０が多くの異なるスキーマ（例えば、トピックごとに１つ（ただしそれ以上の可能性もある）を使用して動作することを可能にすることが望ましい。この様式では、イベントグリッドサービス４１０は、異なる準拠するスキーマ、例えば、クラウドイベントスキーマ、イベントグリッドスキーマ、または任意の他のタイプのスキーマなどを使用して動作し得る。

[0057]いくつかの場合において、イベントグリッドサービス４１０によって使用されるスキーマは、サービス４４５のスキーマ４５０とは異なり得る。このような場合には、クライアント４３５は、サービス４４５からスキーマ情報４６５を獲得して、スキーマ情報４６５をイベントグリッドサービス４１０に伝送することができる。クライアント４４０は、スキーマ情報４７５をイベントグリッドサービス４１０に伝送することによって同様の動作を実施し得る。

[0058]イベントグリッドサービス４１０がスキーマ情報４６５および／または４７５を獲得すると、イベントグリッドサービス４１０は、スキーマ４５０および４６０をイベントグリッドサービス４１０によって使用されるスキーマのうちの１つ（あるいは新規スキーマさえ）にマッピングするためにいくつかの異なる動作を実施することができる。

[0059]第１の例では、人間の開発者が、サービスによって使用されるスキーマをイベントグリッドサービス４１０によって使用されるスキーマにマッピングする、または相関させるために、手動でマッピングを実施することができる。例として図３を使用すると、人間の開発者は、“ｎａｍｅ”、“ｔｙｐｅ”、および“ｔｉｍｅ”データフィールドをイベントグリッドサービス４１０によって使用される同等のフィールドにマッピングすることができる。

[0060]別の例では、イベントグリッドサービス４１０は、サービスのスキーマ内のデータフィールドをインテリジェントに分析して、プログラムで／自動的にマッピングを導出することができ、これは、人間の開発者がこの相関を実施し得るやり方と同様である。いくつかの実施形態において、マッピングを自動的に導出することは、パブリッシングサービスの１つまたは複数の属性を分析し、次いでマッピングを、それが少なくとも部分的にこれらの属性に基づくように構築することによって実施され得る。そのようなプロセスは、それが非常に効率的であることから特に有益である。イベントグリッドサービス４１０が、そのインテリジェントマッピングを実施するとき、それはまた、マッピングされたデータフィールドの各々について信頼性メトリックのレベルを生成し得る。これらの確率メトリック（すなわち、信頼性メトリックのレベル）は、おそらくはマッピングの正確性を検証または認証するためのレビューのために、人間の開発者に提供され得る。

[0061]別の例では、イベントグリッドサービス４１０は、データフィールドのサブセットのために初期マッピングを実施し得る。次いで、イベントグリッドサービス４１０が、（１）マッピングすることができなかったデータフィールド、または（２）マッピングを行ったが、確率メトリックが予め定められた許容しきい値未満であったデータフィールドについて、イベントグリッドサービス４１０は、マッピングプロセスを完了させるためにそれらのデータフィールドを人間の開発者に配信することができる。そのようなものとして、イベントグリッドサービス４１０は、追加の協議が必要とされるときを決定するために確率メトリックに依存し得る。

[0062]さらに別の例では、イベントグリッドサービス４１０は、任意の既存のスキーマに対する、ならびにそれが獲得する任意の新規スキーマに対するマシン学習を実施することができる。言い換えると、マッピングを自動的に導出することは、（１）１つまたは複数の既存のマッピングが使用のために現在利用可能である（前回導出された）と決定すること、（２）それらの既存のマッピングの属性を学習すること、次いで（３）学習した情報に基づいて新規マッピングを導出することによって実施され得る。

[0063]例えば、サブスクリプションデータベース４２５は、イベントグリッドサービス４１０が以前に使用した、または知っていた過去のスキーマのすべてに関する情報を有するテーブルを含み得る。この情報に対するマシン学習を実施することによって、イベントグリッドサービス４１０は、サービスのスキーマとイベントグリッドサービス４１０によって使用されるスキーマとのより直感的および／またはより正確なマッピングを提供することができる場合がある。この様式では、生成される任意の新規マッピングは、将来のアクションおよび／または将来の学習状況のためのテンプレートとしての役割を果たし得る。

[0064]図４に示されるシナリオは、イベントグリッドサービス４１０と特定のエンドポイントサービス（例えば、サービス４４５および４５５）との間の仲介として作用するクライアント（例えば、クライアント４３５および４４０）を例証するが、常にこうであるわけではない。例えば、いくつかの状況では、サービスは、マッピングが導出され得るようにこの初期登録プロセスを実施するためにイベントグリッドサービス４１０と直接通信することができる場合がある。したがって、そのようなシナリオにおいては、仲介クライアントは回避され得、登録プロセスは、さらに最適化され得る。

[0065]登録プロセス（図４に全体的に説明される）の最終結果は、サービスによって使用されるスキーマをイベントグリッドサービスによって使用されるスキーマにマッピングするマッピングである。当然ながら、サービスのスキーマがイベントグリッドサービスのスキーマに準拠する場合、このマッピング導出プロセスは回避され得るということを理解されたい。いずれにせよ、図５は、この最終結果の例を示す。

[0066]具体的には、図５は、トピック５００ごとのエンドマップを示す。登録プロセスの間、新規トピックが生成され得、イベントグリッドサービスは、その新規トピックのために特定のスキーマを使用し得るということを理解されたい。そのようなものとして、登録プロセスの間、新規マッピングが、その新規トピックのために形成され得、その結果として、サービスのスキーマが、その特定のトピックのためにイベントグリッドサービスによって使用されるスキーマに正しく位置対応する。

[0067]代替的に、登録プロセスの間、既存のトピックが、（例えば、いくつかの既存のトピックを列挙するドロップダウンボックスを介して）選択され得、その結果として、イベントグリッドサービスは、その既存のトピックのための特定のスキーマを既に有する。新規サービスがそのトピックのためのイベント発行を発行するとき、登録プロセスの間、新規または既存のマッピングが、サービスのスキーマがイベントグリッドのスキーマに正しく位置対応することを確実にするために作成または選択され得る。

[0068]トピックごとのエンドマップ５００は、“ｎａｍｅ”データフィールドが“ｉｄ”データフィールドにマッピングされており、“ｔｙｐｅ”データフィールドが“ｅｖｅｎｔＴｙｐｅ”データフィールドにマッピングされており、“ｔｉｍｅ”データフィールドが“ｔｉｍｅ”データフィールドにマッピングされていることを示す。“ｎａｍｅ”、“ｔｙｐｅ”、および“ｔｉｍｅ”データフィールドは、サービスの特定のスキーマに対応し、“ｉｄ”、“ｅｖｅｎｔＴｙｐｅ”、および“ｔｉｍｅ”データフィールドは、イベントグリッドサービスによって使用されるスキーマに対応する。示されるように、これらのデータフィールドは、“ｎａｍｅ”データフィールドを割り当てられた実際のイベントデータがここでは“ｉｄ”データフィールドにマッピングされるように、互いに相関（すなわち、マッピング）される。省略記号５０５および５１０は、任意の数のマッピングまたは相関が起こり得ることを実証する。さらには、これらのデータフィールドをマッピングするプロセスは、先に説明されるように、様々なやり方のうちのいずれかで実施され得る。
ルーティングアーキテクチャ
[0069]これより、イベント発行を関心のある外部エンティティにプッシュするために使用され得る例示的なアーキテクチャ６００を示す図６Ａに注目する。アーキテクチャ６００は、図４のイベントグリッドサービス４１０の例示的な実装形態であり得るイベントグリッドサービス６０５、およびサブスクリプションデータベース４２５の例示的な実装形態であり得るサブスクリプションデータベース６１０を含む。アーキテクチャ６００はまた、サービス６１５をスキーマ６２０と共に含み、これは、それぞれサービス４４５およびスキーマ４５０の例示的な実装形態であり得る。

[0070]それらのエンティティ／構成概念に加えて、アーキテクチャ６００はまた、サブスクライバー６３０（すなわち、イベントデータのエンドコンシューマ）を含む。ここでは、サブスクライバー６３０は、１つまたは複数のトピックに関する情報を受信することに関心のあるエンティティである。サービス６１５は、イベント発行６２５をイベントグリッドサービス６０５にプッシュし、このイベント発行６２５は、確立されたトピックと関連付けられる。この例では、サブスクライバー６３０は、このトピックに対応する特定のイベントデータを獲得することに関心がある。

[0071]言い換えると、サブスクライバー６３０は、トピックのためのサブスクリプションを有する。イベントデータをサブスクライバー６３０にプッシュするプロセスを促進するため、イベントグリッドサービス６０５は、サブスクリプションデータベース６１０内にサブスクリプションに関する情報を維持する。この様式では、イベントグリッドサービス６０５は、関連するイベントデータのみをサブスクライバー６３０にプッシュすることができる。本明細書で使用される場合、“関連する”イベントデータは、サブスクライバー６３０が学習することに関心のある特定のイベントデータタイプに準拠するデータである。明白にするため、サブスクライバー６３０は、そのトピックのために発行されるイベントデータのすべてを受信することには関心がない場合がある。むしろ、サブスクライバー６３０は、イベントデータのサブセットのみを望む場合がある。そのようなものとして、サブスクライバー６３０のサブスクリプションは、サブスクライバー６３０がどのタイプのイベントデータが通知されることを望むかを指定することができ、これらの基準は、サブスクリプションデータベース６１０に格納される。

[0072]後でより詳細に説明されるように、イベント発行６２５内のイベントデータは、その特定のトピックのためにイベントグリッドサービス６０５によって使用されるスキーマに準拠するように、サービス６１５によって、あるいはイベントグリッドサービス６０５によってさえも翻訳され得る。いずれにしても、イベントグリッドサービス６０５は、最終的に、対応するトピックのために選択された適切なフォーマット／スキーマでイベントデータを受信する。

[0073]続いて、受信したイベントデータ６２５の１つまたは複数の部分は、次いで、データ６３５によって示されるようにサブスクライバー６３０にプッシュされる。この様式では、イベントグリッドサービス６０５は、イベント発行（イベントデータを含む）を受信し、それらの発行を処理し、次いでそれらの発行からの関連する情報を、特定のトピックに対応するイベントデータを受信することに関心がある１つまたは複数のサブスクライバーに配信することができる集中型イベント発行レポジトリとして作用する。

[0074]図６Ａは、任意の数のサブスクライバーのためのサブスクリプション情報を維持することができる焦点を絞ったアーキテクチャを提示した。図６Ｂは、図６Ａのアーキテクチャを表す、全体的なアーキテクチャの拡張した、というよりも拡大したバージョンを提示する。具体的には、図６Ｂのアーキテクチャは、ソースをサブスクライバーと相互接続することだけではなく、サブスクリプションデータが、障害があってもサブスクリプション情報が失われることがないように適切に守られる／保護されることを確実にすることに焦点を合わせる。

[0075]示されるように、図６Ｂは、図６Ａに示されるアーキテクチャ６００に対する代替的な構成を備え、アーキテクチャ６００によって提供される機能と同様の機能を提供することができる局地的なイベントグリッド６４０を含む。この点に関して、局地的なイベントグリッド６４０は、図６Ａのイベントグリッドサービス６０５と同様であるか、またはそれに類似する。

[0076]示されるように、局地的なイベントグリッド６４０は、トラフィックマネージャー層６４５、第１の局地的なクラスタ６５０Ａ、および第２の局地的なクラスタ６５０Ｂなど、様々な異なる構成要素を含む。第１の局地的なクラスタ６５０Ａは、エッジ層６５５Ａ、ローカルメタデータキャッシュ６６０Ａ、およびクラスタリソースガバナ６５５Ａを含む。第２の局地的なクラスタ６５０Ｂは、エッジ層６５５Ｂ、ローカルメタデータキャッシュ６６０Ｂ、およびクラスタリソースガバナ６６５Ｂなど、同様の構成要素を含む。局地的なイベントグリッド６４０は、局地的なイベントグリッド６４０の一部として含まれる、および／または別個／遠隔のエンティティ内に組み込まれるメタデータストア６７０と通信することができる。

[0077]メタデータストア６７０は、以下の情報のうちのいずれか：（１）トピックのためのスキーマを含むトピック情報、（２）イベントソースのための認証情報、ならびに／または（３）サブスクリプションおよびそれらの構成を公式に格納する構成要素である。いくつかの実装形態において、メタデータストア６７０は、すべてのそのデータが任意の数の他の領域において複製された状態にある完全に区分された分散サービスであり得る。

[0078]いくつかの実施形態において、局地的なクラスタ６５０Ａおよび６５０Ｂは、自律的／非相互依存的である複製データベースを含むシェアード・ナッシング・アーキテクチャを利用する。その結果、局地的なクラスタ６５０Ａおよび６５０Ｂは各々、独自のそれぞれのローカルメタデータキャッシュ６６０Ａおよび６６０Ｂをそれぞれ有し得る。これらのキャッシュは、いくつかの実施形態において、それぞれエッジ層６５５Ａおよび６５５Ｂと共同設置されるメタデータストア６７０のフルキャッシュを有する。この永続性のキャッシュ（すなわち、ローカルメタデータキャッシュ６６０Ａおよび６６０Ｂ）は、メタデータストア６７０と継続的に同期され得る。ローカルメタデータキャッシュ６６０Ａおよび６６０Ｂはまた、エッジ層６５５Ａおよび６５５Ｂが発行し得る任意の数のクエリにスケールアウトするように区分けされ得る。加えて、ローカルメタデータキャッシュ６６０Ａおよび６６０Ｂは、イベントルーティングが、大量（例えば、数百万）のサブスクリプションが確立されるときにさえ、できる限り高速であるように、インデックスされ得るか、または別途整理され得る。

[0079]エッジ層６５５Ａおよび６５５Ｂは、いくつかの実施形態において、イベントソース（例えば、イベントソース６８０Ａ、６８０Ｂ、６８０Ｃ、および６８０Ｄ）からイベントを受信し、そのイベントを任意の関心のあるサブスクライバーに確実に配信することに関与する。いくつかの実施形態において、エッジ層６５５Ａおよび６５５Ｂは、以下の動作の任意の組み合わせ：（１）イベントをディスクに安全に格納し、そのイベントを複製してイベント損失を防ぐこと、（２）システム内に存在するサブスクリプションに基づいてイベントをルーティングもしくはフィルタリングすること、および／または、（３）イベントを関心のあるサブスクライバーに配信すること、を実施することによってイベントを処理する。

[0080]いくつかの場合において、トラフィックマネージャー層６４５は、イベントソース（例えば、イベントソース６８０Ａ、６８０Ｂ、６８０Ｃ、および６８０Ｄ）が局地的なクラスタ（例えば、局地的なクラスタ６５０Ａおよび６５０Ｂ）に直接発行しない場合などに、通信をルーティングするために使用される。むしろ、そのような場合には、イベントソースは、トラフィックマネージャー層６４５を通じて通信する。このレベルの間接性は、要求に応じて、または必要に応じて、局地的なイベントグリッド６４０において追加クラスタを追加および除去するという柔軟性を可能にする。

[0081]いくつかの実施形態において、局地的なクラスタ６５０Ａおよび６５０Ｂ内のエッジノードは、リソースメトリックおよび／または他の統計をクラスタリソースガバナ６６５Ａおよび６６５Ｂを放出し得る。これらのガバナは、いくつかの実施形態において、サービス品質をできる限り高く保つように、または既存のサービスレベルアグリーメント（Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ：ＳＬＡ）によって指定される予め定められたサービス品質を少なくとも満足するように、受信したメトリックに基づいて、予め定められたルールのセットを適用して、適切な行動をとる（例えば、システム構成要素の性能を変更すること）。例えば、メトリックのいくつかは、限定されるものではないが、いくつか例を挙げると、ＣＰＵ使用量、メモリ使用量、およびイベントキュー長さを含む。クラスタリソースガバナ６６５Ａおよび６６５Ｂがとることができる潜在的な行動のいくつかは、限定されるものではないが、接続の均衡を保つために個々のノードに接続を切るように要請すること、ノードを除去すること、および／または、ノードに新規の仕事を受けさせないもしくは新規トラフィックを処理させないようにすることを含む。

[0082]クラスタリソースガバナ６６５Ａおよび６６５Ｂと同様に、局地的なリソースガバナ６７５は局地的なクラスタ（例えば、局地的なクラスタ６５０Ａおよび６５０Ｂ）のいずれかから凝集したメトリックを受信し、次いで、その凝集したメトリックに基づいて、既存のＳＬＡを満足するために必要とされるように、局地的なクラスタ（例えば、局地的なクラスタ６５０Ａおよび６５０Ｂ）間の負荷の均衡を保つようにトラフィックマネージャー層６４５を構成する。

[0083]複数のシェアド・ナッシングの局地的なクラスタ（例えば、局地的なクラスタ６５０Ａおよび６５０Ｂ）、それに加えてトラフィックマネージャー層６４５の設計では、局地的なイベントグリッド６４０は、任意の地政学的領域における局地的障害のための高い可用性を提供することができる。さらには、局地的なイベントグリッド６４０は、完全な損失の場合に透過的なフェイルオーバーを提供するように設計される。

[0084]いくつかの実施形態において、これは、１つの局地的なイベントグリッドを別の局地的なイベントグリッドとペアリングすることによって達成される。例えば、米国中南部（ＵＳＳＣ）に位置する局地的なイベントグリッドが存在すると仮定し、米国中北部（ＵＳＮＣ）に位置する局地的なイベントグリッドが存在するとさらに仮定する。これら２つの局地的なイベントグリッドをペアリングすることによって、本実施形態は、安全なフェイルオーバーシステムを確実にすることができる。

[0085]１つの局地的なイベントグリッドを別の局地的なイベントグリッドと“ペアリング”するため、以下の動作が実施され得る。１つの動作は、特定のメタデータストア（例えば、メタデータストア６７０）の範囲が、それがもはや単に局所的ではないように地理的ペアリングされる（ｇｅｏ－ｐａｉｒｅｄ）ことである。上の例を使用すると、ＵＳＳＣおよびＵＳＮＣのためのすべての（またはいくつかの）サブスクリプションが組み合わされて、別のバックアップメタデータストアサービス（例えば、メタデータストアＵＳＳＣ＿ＵＳＮＣ）となることができる。

[0086]別の動作は、いくつかの局地的なクラスタからのサブスクリプションを、組み合わされたメタデータストアからの「地理的ペア（ｇｅｏ－ｐａｉｒ）」と同期させることを含む。上の例に関して、ＵＳＳＣおよびＵＳＮＣ内のすべての（またはいくつかの）局地的なクラスタ（例えば、局地的なクラスタ６５０Ａおよび６５０Ｂ）は、メタデータストアＵＳＳＣ＿ＵＳＮＣ内に規定されるサブスクリプションをローカルでキャッシュする。

[0087]別の動作は、イベントソース（例えば、イベントソース６８０Ａ、６８０Ｂ、６８０Ｃ、および６８０Ｄ）が、ソース（例えば、イベントソース６８０Ａ、６８０Ｂ、６８０Ｃ、および６８０Ｄ）と同じ地政学的地域内にある局地的なクラスタ（例えば、局地的なクラスタ６５０Ａおよび６５０Ｂ）と通信するように、トラフィックマネージャー層６４５を構成することを含む。しかしながら、局地的な障害があった場合、トラフィックマネージャー層６４５は、地理的ペア内の利用可能な地域にすべてのトラフィックをリダイレクトするように再構成され得る。この様式では、サブスクライバーのサブスクリプションデータのすべてが保護され得る。

[0088]したがって、図６Ａおよび図６Ｂに示されるイベント駆動のアーキテクチャは、上に概説されるように、および以下にさらに概説されるように、多くの利益を提供する。１つの利益としては、イベントグリッドおよびサブスクライバーの両方とネイティブに統合することができる（すなわち、サービスのネイティブスキーマへの変更の必要がない）サービスのリストまたは可用性を拡大することが挙げられる。別の利益としては、クロス・クラウドおよびクロス・サブスクライバー／パブリッシャー相互運用性を直接的に可能にする任意の数の異なる規格を採用する能力が挙げられる。

[0089]開示された実施形態によって提供されるさらに別の特徴は、配信不能に関する。例えば、細心の注意を払ったとしても、特定の宛先に向けられたイベントを、イベント自体の問題または受信者／サブスクライバーの問題に起因して配信することができないというシナリオが生じ得る。そのような“失われた”イベント（すなわち“配信不能物”）は、この配信に依存するビジネスに不可欠なプロセスが存在する場合には特に懸念となり得る。これを軽減するため、イベントグリッドは、サブスクライバーが、最終的に、それらが関心のあるイベントを受信することを確実にするのを助ける配信不能のためのサポートを提供する。例えば、イベントグリッドが、特定の期間（例えば、分、時間、日など）にわたるリトライの後にイベントを配信することができない場合、そのイベントは、ストレージアカウント内に置かれ得、これは後で分析され得るか、または失敗した配信のライブトラッキングについて監視され得る。

[0090]この様式では、イベントグリッドは、アプリケーションおよびサブスクライバーのためのイベントルーターまたは仲介として作用することができる。例えば、アプリケーションは、（１）イベントを発行するべき１つまたは複数のトピックを作成すること、（２）イベントに反応する必要に応じてサブスクリプションを作成すること、（３）対応するトピックにイベントを発行すること、および（４）適切な場合にイベントハンドラー内のイベントを処理することによって、アプリケーション自体によって生成されるイベントのストリームのためのイベントルーターとしてイベントグリッドを使用することができる。

[0091]アプリケーションはまた、クラウドサービスからのイベントをサブスクライブするためにイベントグリッドを使用することができる。いくつかの実施形態において、これは、（１）関心のあるリソースからイベントを受信するためにトピックをサブスクライブすること、および（２）適切な場合にイベントハンドラー内のイベントを処理することによって達成される。

[0092]上に示されるように、いくつかの実施形態において、イベントグリッドは、ユーザーのための透過的なスケールアウトおよびフェイルオーバー能力を有する局地的なサービスである。一部の領域では、イベントグリッドは、計算およびストレージリソースのクラスタのセットによって表される。これらのクラスタは、透過的なスケールアウトおよびフェイルオーバーモデルを提供するために連携して働く。したがって、図６Ａおよび図６Ｂに示される例示的なアーキテクチャは、ソースをサブスクライバーと相互接続することができるイベントグリッドサービスについて説明する。
フロントエンド翻訳アーキテクチャ
[0093]これより、図６Ａのアーキテクチャ６００と同様であるアーキテクチャ７００を示す図７に注目する。詳細には、アーキテクチャ７００は、イベントグリッドサービス７０５が任意の数のトピックを取り扱い得ることを例証する。例えば、イベントグリッドサービス７０５は、トピック７１０、トピック７１５、およびトピック７２０のためのイベントデータを処理している。省略記号７２５は、イベントグリッドサービス７０５が、任意の数の異なるトピック（例えば、１、２、３、４、５、１０、２０、５０、１００、または１００超のトピック）のための情報を取り扱い得ることを実証する。トピックの概念は先に詳細に説明されているため、繰り返されない。

[0094]イベントグリッドサービス７０５はまた、いくつかのマッピング構成要素、例えば、マッピング構成要素７３０、マッピング構成要素７３５、およびマッピング構成要素７４０を含むものとして示される。本明細書で使用される場合、これらのマッピング構成要素は、イベント発行をサービス７４５（例えば、サービス７４５Ａ、７４５Ｂ、および７４５Ｃ。省略記号７４５Ｄは、任意の数のサービスがイベント発行を発行し得ることを実証する）から受信する。マッピング構成要素は、次いで、サービスおよび／またはトピックごとに初期登録プロセスの間に導出されたマッピングを使用して、発行内に含まれるイベントデータを翻訳する。そのようなものとして、各マッピング構成要素は、特定のトピックと関連付けられ得、その結果として、受信したイベントデータは、その特定のトピックのために使用されるスキーマへと翻訳される。

[0095]例えば、サービス７４５Ａは、イベント発行７５０Ａをマッピング構成要素７３０に伝送しており、サービス７４５Ｂは、イベント発行７５０Ｂをマッピング構成要素７３５に伝送しており、サービス７４５Ｃは、イベント発行７５０Ｃをマッピング構成要素７４０に伝送している。マッピング構成要素がサービスからイベント発行（イベントデータを含む）を受信すると、マッピング構成要素は、受信したイベントデータが、それぞれのトピックごとのスキーマに従って処理またはフォーマットされることを確実にする。

[0096]アーキテクチャ７００はまた、サブスクライバー７５５を示す（例えば、サブスクライバー７５５Ａ、サブスクライバー７５５Ｂ、およびサブスクライバー７５５Ｃ、また、省略記号７５５Ｄは、任意の数のサブスクライバーが、イベントグリッドサービス７０５と通信状態にあり、それをサブスクライブし得ることを実証する）。サービス７４５からイベント発行（イベントデータを含む）を受信した後、イベントグリッドサービス７０５は、それぞれのサブスクライバー７５５ごとにイベントデータの関連する部分を選択的に識別／フィルタリングすることができる。

[0097]示されるように、イベントグリッドサービス７０５は、関連するイベントデータ７６０Ａ、７６０Ｂ、および７６０Ｃを、それぞれサブスクライバー７５５Ａ、７５５Ｂ、および７５５Ｃに渡している。この様式では、イベントグリッドサービス７０５は、イベントデータを受信し、そのイベントデータを特定のトピックのための所望のスキーマへと翻訳し、そのイベントデータをフィルタリングし、その後、フィルタリングしたイベントデータを関心のあるサブスクライバーにプッシュすることができる。さらには、イベントグリッドサービス７０５は、複数の異なるパブリッシングサービスから複数のイベント発行を受信して、それらの発行を所望の様式で取り扱うことができる。例として、イベントグリッドサービス７０５は、各々がイベントグリッドサービス７０５とのサブスクリプションを有する複数のサブスクライバーと関連付けられ得、その結果として、イベントグリッドサービス７０５は、複数のイベントデータを複数のサブスクライバーにプッシュすることができる。

[0098]いくつかの実施形態において、データフィールドの一部は、最初、静的な値が埋め込まれ、後で、正しい値が自動挿入され得る。例えば、“ｔｉｍｅ”フィールドは、最初は静的であり得るが、イベント発行が伝送される準備が整うと、このフィールドは、実際のイベント発行の時間を含めるために自動挿入され得る。追加的に、または代替的に、イベントタイプは、自動的に変更または挿入され得る。この自動挿入は、データフィールドのすべてに対して実施される必要はなく、むしろ、自動挿入のための好適な候補（例えば、固有ＩＤ、時間、アドレスなど）であるデータフィールドに対して実施され得る。

[0099]図８は、図７のアーキテクチャ７００といくらか同様である別のアーキテクチャ８００を示す。具体的には、アーキテクチャ８００は、トピック８１０Ａ、８１０Ｂ、および８１０Ｃを有するイベントグリッドサービス８０５を含む。サービス８１５も示される（例えば、サービス８１５Ａ、８１５Ｂ、および８１５Ｃ。省略記号８１５Ｄは任意の数のサービスが存在し得ることを実証している）。イベントグリッドサービス７０５が翻訳プロセスを実施したアーキテクチャ７００とは対照的に、アーキテクチャ８００では、サービス８１５が、翻訳プロセスを実施するように構成される。

[00100]初期登録プロセスの間、マッピングは、サービスのスキーマを特定のトピックのためにイベントグリッドサービス８０５によって使用されるスキーマにマッピングするように開発されていることを思い出してほしい。そのようなものとして、サービス８１５は、マップを生成しておらず、代わりに、サービス８１５は、それらのイベントデータがイベントグリッドサービス８０５によって使用されるスキーマのデータフィールドで正しくタグ付けされるように、翻訳プロセスを単に実施している。したがって、いくつかの実施形態においては、サービス８１５が、翻訳プロセスを実施するように構成され得る一方、他の実施形態においては、イベントグリッドサービスが、翻訳プロセスを実施するように構成され得る。

[00101]イベントデータが翻訳された後、イベントグリッドサービス８０５は、関連するイベントデータをサブスクライバー８３０（例えば、サブスクライバー８３０Ａ、８３０Ｂ、および８３０Ｃ。省略記号８３０Ｄは、任意の数のサブスクライバーが存在し得ることを実証している）に伝送することができる。そのような動作は、関連するイベントデータ８３５Ａ、８３５Ｂ、および８３５Ｃがそれぞれのサブスクライバーに渡されることによって示される。
バックエンド翻訳アーキテクチャ
[00102]上の議論は、フロントエンド翻訳プロセスを実施する実施形態に焦点を合わせていた。フロントエンド翻訳を実施することに加えて、いくつかの実施形態はまた、図９に示されるように、追加のバックエンド翻訳プロセスを実施するように構成される。

[00103]ここでは、アーキテクチャ９００は、ちょうど図８のアーキテクチャ８００のように、トピック９１０Ａ、９１０Ｂ、および９１０Ｃを有するイベントグリッドサービス９０５を含む。サービス９１５（例えば、サービス９１５Ａ、９１５Ｂ、および９１５Ｃ）は、イベント発行９２０Ａ、９２０Ｂ、および９２０Ｃ（それぞれのトピックに対応する）をイベントグリッドサービス９０５にプッシュしている。示されないが、サービス９１５またはイベントグリッドサービス９０５のいずれかが、イベントデータを特定のトピックのためにイベントグリッドサービス９０５によって使用されるスキーマへと翻訳するために、フロントエンド翻訳プロセスを実施していた可能性がある。

[00104]図９は、イベントグリッドサービス９０５が、おそらくはフロントエンド翻訳を実施することに加えて、マッピング構成要素９２５Ａ、９２５Ｂ、および９２５Ｃを使用してバックエンド翻訳を実施することもできることを示す。これらのマッピング構成要素は、ここではこれらのマッピング構成要素が、関連するイベントデータ９３５Ａ、９３５Ｂ、および９３５Ｃによって示されるように、イベントデータがサブスクライバー９３０（例えば、サブスクライバー９３０Ａ、９３０Ｂ、および９３０Ｃ）にプッシュされる前にバックエンドで翻訳プロセスを実施することを除いては、図７のマッピング構成要素７３０、７３５、および７４０と同様である。

[00105]イベントグリッドサービス９０５は、特定のトピックのための特定のスキーマを使用し得るが、いくつかのサブスクライバーは、イベントグリッドサービス９０５、またはサービス９１５のいずれかとは全く異なるスキーマでフォーマットされたイベントデータを受信することを望み得る。そのようなものとして、イベントグリッドサービス９０５は、イベントデータを特定のサブスクライバーが読むことのできるフォーマットへと翻訳するためにバックエンド翻訳プロセスを実施することができる。バックエンドに使用されるマッピングは、フロントエンドマッピングと同様の様式で導出され得る。

[00106]それでは、これより、別の例示的なアーキテクチャ１０００を示す図１０に注目する。ここでは、イベントグリッドサービス１００５は、トピック１０１０Ａ、１０１０Ｂ、および１０１０Ｃを管理している。それはまた、フロントエンドマッピング構成要素１０１５Ａ、１０１５Ｂ、および１０１５Ｃ、ならびにバックエンドマッピング構成要素１０２０Ａ、１０２０Ｂ、および１０２０Ｃを含む。

[00107]ここでは、サービス１０２５（例えば、サービス１０２５Ａ、１０２５Ｂ、および１０２５Ｃ）は、イベント発行１０３０Ａ、１０３０Ｂ、および１０３０Ｃを、それぞれフロントエンドマッピング構成要素１０１５Ａ、１０１５Ｂ、および１０１５Ｃにプッシュしている。そのようなものとして、フロントエンド翻訳プロセスは、各イベント発行内のイベントデータを所望のフォーマット／スキーマへと翻訳するために発生し得る。

[00108]続いて、いくつかのサブスクライバーが、特定のトピックのためにイベントグリッドサービス１００５によって使用されるスキーマとは異なるスキーマで関連データを受信することを望むことが決定され得る。そのようなものとして、バックエンドマッピング構成要素１０２０Ａ、１０２０Ｂ、および１０２０Ｃは、イベントデータを所望のフォーマットへと翻訳するためにバックエンド翻訳プロセスを実施し得る。さらには、イベントグリッドサービス１００５は、特定のサブスクライバーに関連するデータを識別するためにイベントデータを選択的にフィルタリングすることができる。示されるように、イベントグリッドサービス１００５は、関連するイベントデータ１０３５Ａ、１０３５Ｂ、および１０３５Ｃを、サブスクライバー１０４０（例えば、サブスクライバー１０４０Ａ、１０４０Ｂ、および１０４０Ｃ）にプッシュしている。この様式では、フロントエンドおよび／またはバックエンド翻訳は、イベントデータに対して発生し得る。

[00109]したがって、いくつかの状況では、イベントグリッドサービス１００５は、確立されたトピックに対応するイベント発行を受信する。次いで、イベントグリッドサービス１００５は、イベントデータに対してフロントエンド翻訳を実施することができる。さらに、イベントグリッドサービス１００５は、イベントデータが特定のサブスクライバーのための準拠するスキーマにあるかどうかを決定することができる。そうでない場合、イベントグリッドサービス１００５は、イベントデータに対してバックエンド翻訳を実施することができる。この点に関して、任意のフィルタリングされたイベントデータをサブスクライバーにプッシュする前に、イベントグリッドサービス１００５は、イベントデータに対して第２の翻訳を実施することができる。
サブスクリプションのバリエーション
[00110]図１１は、単一のサブスクライバーが複数の異なるトピックに関する情報を受信することができるシナリオを示す。具体的には、図１１は、イベントグリッドサービス１１０５がトピック１１１０Ａ、１１１０Ｂ、および１１１０Ｃを含むアーキテクチャ１１００を示す。ここでは、サービス１１１５（例えば、サービス１１１５Ａ、１１１５Ｂ、および１１１５Ｃ）は、先に説明される原則に従って、イベント発行１１２０Ａ、１１２０Ｂ、および１１２０Ｃをイベントグリッドサービス１１０５にプッシュしている。さらには、イベント発行１１２０Ａ、１１２０Ｂ、および１１２０Ｃの各々は、異なるトピック、具体的には、それぞれトピック１１１０Ａ、１１１０Ｂ、および１１１０Ｃに対応する。

[00111]単一のサブスクライバー１１２５も示される。単一のサブスクライバーだけが例証されるが、本原則は任意の数のサブスクライバーに当てはまるということを理解されたい。ここでは、サブスクライバー１１２５は、トピック１１１０Ａ、１１１０Ｂ、および１１１０Ｃの各々に対して１つのサブスクリプションという、イベントグリッドサービス１１０５との複数のサブスクリプションを有する。したがって、サブスクライバー１１２５が複数のサブスクリプションを有することから、イベントグリッドサービス１１０５は、サブスクライバー１１２５のサブスクリプションに従って関連データを識別するために、イベント発行１１２０Ａ、１１２０Ｂ、および１１２０Ｃ内で受信されるイベントデータを選択的にフィルタリングすることになる。その後、イベントグリッドサービス１１０５は、トピック１１１０Ａのための関連データ１１３０Ａ、トピック１１１０Ｂのための関連データ１１３０Ｂ、およびトピック１１１０Ｃのための関連データ１１３０Ｃを、サブスクライバー１１２５にプッシュすることになる。この様式では、単一のサブスクライバーが、複数の異なるトピックに対応する複数の通知を受信し得る。

[00112]図１２は、複数のサブスクライバーがすべて同じトピックに関する通知（すなわち、イベントデータ）を受信しているアーキテクチャ１２００を示す。具体的には、アーキテクチャ１２００は、イベントグリッドサービス１２０５が、トピック１２１０Ａ、１２１０Ｂ、および１２１０Ｃを含むことを示す。サービス１２１５（例えば、サービス１２１５Ａ、１２１５Ｂ、および１２１５Ｃ）は、イベント発行１２２０Ａ、１２２０Ｂ、および１２２０Ｃを、イベントグリッドサービス１２０５にプッシュしている。ここでは、イベント発行１２２０Ａ、１２２０Ｂ、および１２２０Ｃの各々は、同じトピック、具体的には、トピック１２１０Ａに対応する。

[00113]この例示的なシナリオでは、複数のサブスクライバー１２２５（例えば、サブスクライバー１２２５Ａ、１２２５Ｂ、および１２２５Ｃ）が、トピック１２１０Ａに対応するイベントデータを受信するためにサブスクリプションを有する。いくつかの場合において、この複数のサブスクライバー１２２５は、同じイベントデータを受信することになるが、他の場合では、この複数のサブスクライバー１２２５は各々、トピック１２１０Ａについてのイベントデータの異なる部分を受信することになる。各サブスクライバーがどの部分を受信することになるかを決定することは、サブスクライバーの対応するサブスクリプションに基づく。したがって、２つのサブスクライバーが同じサブスクリプションを有する（すなわち、サブスクリプションが、サブスクライバーが同じ種類の関連するイベントデータを受信するために選ばれていることを示す）場合、それら２つのサブスクライバーが実際に同じデータを受信することになるということである。したがって、イベントグリッドサービス１２０５は、関連するイベントデータ１２３０Ａ、１２３０Ｂ、および１２３０Ｃを、それぞれサブスクライバー１２２５Ａ、１２２５Ｂ、および１２２５Ｃにプッシュする。

[00114]複数のサブスクライバーが同じトピックをサブスクライブしているとき、それらのサブスクライバーはまた、異なるスキーマ（すなわち、サブスクライバーによって使用されるフォーマットに準拠するスキーマ）を使用し得る。そのようなシナリオでは、イベントグリッドサービス１２０５は、それらのサブスクライバーが同じトピックをサブスクライブしているとしても、イベントデータの異なる部分を抽出するために、イベントデータを選択的にフィルタリングすることができる。各部分は、それがサブスクライバーの各々に実際に関連していることを検証するために分析されることになる。その後、イベントグリッドサービス１２０５は、イベントデータの抽出された部分をサブスクライバーにプッシュする。この様式では、任意の数のサブスクライバーが、同じ確立されたトピックをサブスクライブしてもよく、その結果として、それらのサブスクライバーは、受信したイベント発行内に提供された同じイベントデータのうちの一部（またはすべて）を受信することになる。必要な場合、または所望の場合、イベントグリッドサービス１２０５はまた、データが受信側サブスクライバー／コンシューマのいずれかのために正しくフォーマットされることを確実にするために個別化されたマッピングプロセスを実施することができる。

[00115]この時点では、例が役に立つ。先に論じられた保険会社アプリケーションなどの携帯電話アプリケーションがあると仮定する。いくつかの場合において、クライアントは、保険請求のために（例えば、損傷した自動車の）写真をアップロードすることを決定し得る。携帯電話から、画像は、クラウド内で実行するサービス（例えば、クラウドストレージサービス）にアップロードされる。画像のファイルがクラウドストレージ上に作成されると、クラウドストレージサービスは、ファイル（すなわち、イベント）の作成をイベントグリッドサービスに発行することになる。発行は、顧客情報、画像、および他の情報を説明することができる。そのようなものとして、クラウドストレージサービスは、保険会社のメインアプリケーションのバックエンドアプリケーションであり得る。言い換えると、パブリッシングサービス（例えば、クラウドストレージサービス）は、メインアプリケーションのサブ構成要素（すなわち、サブスクライバー）である。

[00116]バックエンドアプリケーションがイベント発行を提出すると、メインアプリケーションは、クライアントが自動車の画像をアップロードしたことを通知され得る。その後、メインアプリケーションは、請求を処理することを開始することができる。そのようなものとして、サービスおよびサブスクライバー（すなわち、メインアプリケーション）は、同じ企業によって、あるいは同じ賃借人によって、所有され得る。

[00117]別の例として、企業が新しい従業員を雇用するシナリオについて検討する。新しい従業員を雇用することは、任意の数の異なるイベントの実行をトリガし得る。例えば、新しい従業員は、新しいイス、デスク、またはコンピューターを必要とし得る。そのようなものとして、サービスは、イベント（例えば、新規イスイベント、新規デスクイベント、新規コンピューターイベントなど）を作成することによって、新しい従業員の雇用に対して反応し得る。この場合、サービスは、イベントを作成する非人間のプログラムであり得る。その後、イスを購入するサブスクライバーは、イスイベントについて聞くことができ、それが受信されると、イスを獲得するプロセスを実施することができる。同様のサブスクライバーが、デスクおよびコンピューターイベントについても利用可能であり得る。したがって、これらは、実施形態の一部がどのように使用され得るかのいくつかの現実的な例である。

[00118]さらには、サービス（例えば、イスサービス）が、それらのデータをフォーマットするための既存のスキーマを既に有する場合、本実施形態は、マッピングを生成することによってその既存のスキーマに動的に反応することができ、その結果として、それらのサービスが再符合化、または別途修正される必要がない。むしろ、単純な登録（例えば、構成更新）が、それらのサービスがそれらの通常の手順／プロトコルに従って動作し続けることを可能にするために発生し得、イベントグリッドサービスは、新しく導出されたマッピングの使用を通じて動的に適合することができる。そのようなものとして、本実施形態は、イベントデータを受信および発行するための非常にスケーラブルなモデルを提供する。
方法
[00119]これより、実施され得るいくつかの方法行為を参照にする図１３～図１５に注目する。方法行為は特定の順序で論じられ得るか、または特定の順序で発生するものとしてフローチャートで例証され得るが、特定の順序は、具体的に記載がない限りは必要とされず、または、ある行為が、その行為が実施される前に完了されている別の行為に依存することが理由で必要とされる。

[00120]図１３は、準拠しないデータスキーマでコンパイルされる受信したイベントデータを、準拠するデータスキーマに含まれるイベントフィールドにマッピングするための例示的な方法のフローチャート１３００を示す。この方法は、本明細書で論じられるイベントグリッドサービスのいずれかによって実施され得る。

[00121]最初に、登録情報が受信される（行為１３０５）。この情報は、パブリッシングサービス（例えば、図１２のサービス１２１５のいずれか、図１１のサービス１１１５、図１０のサービス１０２５のいずれかなど）をイベントグリッドサービスに登録するために使用される。いくつかの状況では、この登録情報は、パブリッシングサービスによって使用される現在のイベントスキーマを含む。さらには、この登録情報は、サブスクライバーが、トピックについて受信されるイベント発行に反応するためにサブスクライブするトピックに対応し得る。

[00122]続いて、パブリッシングサービスの現在のイベントスキーマは、現在のイベントスキーマがトピックによって使用されるデフォルトのイベントスキーマに対応するかどうかを決定するために分析される（行為１３１０）。パブリッシングサービスの現在のイベントスキーマがトピックのデフォルトのイベントスキーマに対応しない場合、パブリッシングサービスの現在のイベントスキーマをトピックのデフォルトのイベントスキーマにマッピングすることを試みるマッピングが、自動的に導出される（行為１３１５）。

[00123]マッピングが導出された後、イベント発行が、パブリッシングサービスから受信される（行為１３２０）。特に、このイベント発行は、サービスが登録されたトピックであって、サブスクライバーが聞いているトピックに対応する。

[00124]次いで、マッピングは、イベント発行に含まれる少なくともいくつかのイベントデータを、イベントデータがトピックのデフォルトのイベントスキーマに含まれるイベントフィールドに位置対応するような様式で翻訳するために使用される（行為１３２５）。この様式では、フロントエンド翻訳は、イベントデータが所望のフォーマットに準拠することを確実にするために実施され得る。

[00125]図１３は、サービスとイベントグリッドサービスとの間で実施され得るいくつかのアクションを紹介したが、図１４は、１つまたは複数のパブリッシングサービスから受信されるイベントデータを、そのイベントデータの１つまたは複数のサブスクライバーにプッシュするための方法のフローチャート１４００を例証する。言い換えると、これらの方法行為は、イベントグリッドサービスと、イベントデータに反応するサブスクライバーとの間で発生する。図１３の方法と同様に、図１４の方法もまた、コンピューターシステム（例えば、図１６において後で説明されるコンピューターシステム）上で実行し得るイベントグリッドサービスによって実施される。

[00126]最初に、少なくとも１つのサブスクライバーが識別される（行為１４０５）。この行為は、確立されたトピックに対応し、かつイベントデータを含むイベント発行を受信した後に実施され得る。このシナリオでは、サブスクライバーは、確立されたトピックに対応する任意のイベント発行内に含まれる特定のタイプのイベントデータが受信されるときに通知されることになる。そのようなものとして、サブスクライバーは、イベントグリッドサービスとのサブスクリプションを有し、サブスクリプションは、特定のタイプのイベントデータを識別する。故に、受信したイベント発行内に提供されるイベントデータが、特定のタイプのイベントデータに対応する特定のイベントデータを含むということである。

[0127]続いて、受信したイベント発行内に提供されるイベントデータがサブスクライバーのための準拠するスキーマにあるかどうかに関して決定がなされる（行為１４１０）。イベントデータが、準拠するスキーマにある場合（行為１４１５Ａ）、そのイベントデータに対してマッピングは実施されない。しかしながら、代替的に、イベントデータが、準拠するスキーマにない（行為１４１５Ｂ）、または部分的にのみ準拠するスキーマにある場合、マッピングが、そのイベントデータをマッピングするために実施される。

[0128]次に、イベントデータは、特定の所望のタイプのイベントデータに対応する任意のイベントデータを抽出するためにフィルタリングされる（行為１４２０）。最後に、抽出したイベントデータ（すなわち、特定の所望のタイプのイベントデータに対応するイベントデータ）が、サブスクライバーにプッシュされる（行為１４２５）。

[0129]これより、１つまたは複数のパブリッシングサービスからイベント発行を受信するため、およびイベント発行内に含まれる情報を１つまたは複数のサブスクライバーにプッシュするための例示的な方法のフローチャート１５００を例証する図１５に注目する。言い換えると、フローチャート１５００において概説される方法行為は、図１３および図１４に説明される方法行為のハイブリッドを構成する。

[0130]最初に、イベント発行が受信される（行為１５０５）。この発行は、確立されたトピックに対応し、パブリッシングサービスから受信される。先の議論と同様に、このイベント発行もまた、イベントデータを含む。

[0131]次いで、マッピングが、イベントデータの少なくともいくつかを翻訳するために使用される（行為１５１５）。このマッピングは、トピックおよびパブリッシングサービスの両方と関連付けられる。この翻訳プロセスを実施することによって、イベントデータはこれで、トピックのためのイベントスキーマ内に含まれるフィールドに位置対応する／相関することになる。

[0132]イベントデータを翻訳した後、サブスクライバーが次いで識別される（行為１５１５）。このサブスクライバーは、確立されたトピックに対応する任意のイベント発行内に含まれる特定のタイプのイベントデータが受信されるときに通知されるために選ばれている。先の議論と同様に、このサブスクライバーは、イベントグリッドサービスとのサブスクリプションを有し、このサブスクリプションが、特定のタイプのイベントデータを識別する。さらには、翻訳されたイベントデータは、線引きされた特定のタイプのイベントデータに対応する特定のイベントデータを含む。

[0133]特定のイベントデータは、次いで、イベントデータからフィルタリングされ（行為１５２０）、次いで、サブスクライバーにプッシュ／ルーティングされる（行為１５２５）。この様式では、イベントグリッドサービスは、イベントデータを受信し、このイベントデータが選択された／所望のフォーマットまたはスキーマに準拠することを確実にすることができる。次いで、イベントグリッドサービスは、特に関連するデータを識別するためにイベントデータを選択的にフィルタリングする。イベントグリッドサービスは、サブスクライバーによって事前に提供される情報を使用して関連データを識別することができ、この情報は、サブスクライバーが重要であるまたは関連するものと見なすイベントデータのタイプを示す。したがって、この情報を使用して、イベントグリッドサービスは、任意の関連するイベントデータを抽出し、次いでそのイベントデータをサブスクライバーに渡す／ルーティングすることができる。
例示的なコンピューターシステム
[0134]開示された実施形態の一部の様々な特徴および機能をまさに説明してきたが、これより、本明細書に説明される動作を促進するために使用され得る例示的なコンピューターシステム１６００を例証する図１６に注目する。コンピューターシステム１６００は、様々な異なる形態をとり得る。例えば、コンピューターシステム１６００は、サーバ、分散システム、デスクトップ、ラップトップ、携帯電話、データセンター、および／または任意の他のコンピューティングデバイスとして具現化され得る。

[0135]その最も基本的な構成において、コンピューターシステム１６００は、様々な異なる構成要素を含む。例えば、図１６は、コンピューターシステム１６００が、少なくとも１つのプロセッサ１６０５（別名“ハードウェア処理ユニット”）、および実行可能な命令１６１５を含み得るストレージ１６１０を含むことを示す。プロセッサ１６０５は、上に説明された方法行為のいずれかを実施するように構成され得る。示されないが、コンピューターシステム１６００は、ＡＳＩＣ、ＧＰＵ、または任意の他のタイプのハードウェア論理ユニットを含み得る。

[0136]ストレージ１６１０は、物理的なシステムメモリであってもよく、これは、揮発性、不揮発性、またはそれら２つの何らかの組み合わせであり得る。用語“メモリ”はまた、物理的なストレージ媒体などの不揮発性マスストレージを指すために本明細書では使用され得る。コンピューターシステム１６００が分散される場合、処理能力、メモリ能力、および／またはストレージ能力も同様に分散され得る。本明細書で使用される場合、用語“実行可能なモジュール”、“実行可能な構成要素”、または“構成要素”さえも、コンピューターシステム１６００上で実行され得るソフトウェアオブジェクト、ルーチン、または方法を指すことができる。本明細書に説明される異なる構成要素、モジュール、エンジン、およびサービスは、コンピューターシステム１６００上で実行する（例えば、別個のスレッドとして）オブジェクトまたはプロセッサとして実施され得る。

[0137]開示された実施形態は、以下により詳細に論じられるように、例えば、１つまたは複数のプロセッサ（プロセッサ１６０５など）およびシステムメモリ（ストレージ１６１０など）など、コンピューターハードウェアを含む特殊用途または汎用コンピューターを備え得るか、または利用し得る。実施形態はまた、コンピューター実行可能な命令および／またはデータ構造を運搬または格納するための物理的なおよび他のコンピューター可読媒体を含む。そのようなコンピューター可読媒体は、汎用または特殊用途コンピューターシステムによってアクセスされ得る任意の利用可能な媒体であり得る。データの形態でコンピューター実行可能な命令を格納するコンピューター可読媒体は、物理的なコンピューターストレージ媒体である。コンピューター実行可能な命令を運搬するコンピューター可読媒体は、伝送媒体である。したがって、限定ではなく例として、現在の実施形態は、コンピューターストレージ媒体および伝送媒体という少なくとも２つの全く異なる種類のコンピューター可読媒体を含み得る。

[0138]コンピューターストレージ媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ－ＲＯＭ、ＲＡＭに基づくソリッドステートドライブ（ＳＳＤ）、フラッシュメモリ、相変化メモリ（ＰＣＭ）、もしくは他のタイプのメモリなどの、ハードウェアストレージデバイス、または他の光学ディスクストレージ、磁気ディスクストレージ、もしくは磁気ストレージデバイス、または、コンピューター実行可能な命令、データ、データ構造の形態で所望のプログラムコード手段を格納するために使用され得、かつ汎用もしくは特殊用途コンピューターによってアクセスされ得る任意の他の媒体である。

[0139]コンピューターシステム１６００はまた、（有線またはワイヤレス接続により）外部センサ（例えば、１つまたは複数のリモートカメラ、加速度計、ジャイロスコープ、音響センサ、磁気計、データ獲得デバイスなど）に接続され得る。さらに、コンピューターシステム１６００はまた、１つまたは複数の有線またはワイヤレスネットワーク１６２０を通じて、コンピューターシステム１６００に関して説明される処理のいずれかを実施するように構成されるリモートシステムに接続され得る。コンピューターシステムはまた、プロセッサ１６０５により、ディスプレイ上で１つまたは複数のユーザーインタフェース要素をレンダリングするように構成されるグラフィックスレンダリングエンジンを含み得る。

[0140]図１６に示されるネットワーク１６２０のような“ネットワーク”は、コンピューターシステム、モジュール、および／または他の電子デバイスの間の電子データの輸送を可能にする１つまたは複数のデータリンクおよび／またはデータスイッチと定義される。情報が、ネットワークを通じて（ハードワイヤード、ワイヤレス、またはハードワイヤードおよびワイヤレスの組み合わせのいずれかで）コンピューターに転送または提供されるとき、コンピューターは、その接続を伝送媒体として正しく見なす。コンピューターシステム１６００は、ネットワーク１６２０と通信するために使用される１つまたは複数の通信チャネルを含む。伝送媒体は、コンピューター実行可能な命令の形態、またはデータ構造の形態でデータまたは所望のプログラムコード手段を運搬するために使用され得るネットワークを含む。さらに、これらのコンピューター実行可能な命令は、汎用または特殊目的コンピューターによってアクセスされ得る。上記の組み合わせもまた、コンピューター可読媒体の範囲内に含まれ得る。

[0141]様々なコンピューターシステム構成要素に達すると、コンピューター実行可能な命令またはデータ構造の形態にあるプログラムコード手段は、伝送媒体からコンピューターストレージ媒体へ自動的に転送され得る（またはその逆）。例えば、ネットワークまたはデータリンクを通じて受信されるコンピューター実行可能な命令またはデータ構造は、ネットワークインターフェースモジュール（例えば、ネットワークインターフェースカード、すなわち“ＮＩＣ”）内のＲＡＭでバッファされ、次いで、コンピューターシステムＲＡＭへ、および／またはコンピューターシステムにおける揮発性の高くないコンピューターストレージ媒体へ、最終的に転送され得る。したがって、コンピューターストレージ媒体は、同じく（あるいは主として）伝送媒体を利用するコンピューターシステム構成要素に含まれ得るということを理解されたい。

[0142]コンピューター実行可能な（またはコンピューター解釈可能な）命令は、例えば、汎用コンピューター、特殊用途コンピューター、または特殊用途処理デバイスに特定の機能または機能のグループを実施させる命令を含む。コンピューター実行可能な命令は、例えば、バイナリ、アセンブリ言語などの中間フォーマット命令、あるいはソースコードであってもよい。本主題は、構造的特徴および／または方法論的行為に特有の言語で説明されているが、添付の特許請求の範囲において規定される主題は、上に説明されるような説明された特徴または行為に必ずしも限定されないということを理解されたい。むしろ、説明された特徴および行為は、請求項を実践する例示的な形態として開示される。

[0143]当業者は、本実施形態が、パーソナルコンピューター、デスクトップコンピューター、ラップトップコンピューター、メッセージプロセッサ、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースもしくはプログラマブル家電機器、ネットワークＰＣ、ミニコンピューター、メインフレームコンピューター、携帯電話、ＰＤＡ、ページャ、ルータ、スイッチ、および同様のものを含む、多くのタイプのコンピューターシステム構成を有するネットワークコンピューティング環境において実践され得ることを理解するものとする。本実施形態はまた、ネットワークを通じて（ハードワイヤードデータリンク、ワイヤレスデータリンク、またはハードワイヤードおよびワイヤレスデータリンクの組み合わせのいずれかによって）リンクされるローカルおよびリモートコンピューターシステムが、各々タスクを実施する（例えば、クラウドコンピューティング、クラウドサービス、および同様のもの）分散システム環境において実践され得る。分散システム環境において、プログラムモジュールは、ローカルおよびリモート両方のメモリストレージデバイスに位置し得る。

[0144]追加的に、または代替的に、本明細書に説明される機能は、少なくとも部分的に、１つまたは複数のハードウェア論理構成要素（例えば、プロセッサ２１０５）によって実施され得る。例えば、限定なしに、使用され得る例証的なタイプのハードウェア論理構成要素としては、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定プログラムまたは特定用途向け集積回路（ＡＳＩＣ）、特定プログラム向け標準製品（ＡＳＳＰ）、システム・オン・チップ・システム（ＳＯＣ）、復合プログラマブル論理デバイス（ＣＰＬＤ）、中央処理装置（ＣＰＵ）、および他のタイプのプログラマブルハードウェアが挙げられる。

[0145]本実施形態は、それらの趣旨または特徴から逸脱することなく他の特定の形態で提示され得る。説明された実施形態は、あらゆる点で、単に例証的であり、制限的ではないと見なされるべきである。したがって、開示された範囲は、先述の説明ではなく添付の特許請求の範囲によって示される。特許請求の範囲の等価の意味および範囲内に入るすべての変更は、それらの範囲内に包含されるべきである。

Claims (9)

1. 準拠しない(non-conforming)データスキーマにコンパイルされる受信したイベントデータを、準拠する(conforming)データスキーマに含まれるイベントフィールドにマッピングするための方法であって、前記方法は、コンピューターシステム上で実行するイベントグリッドサービス(event grid service)によって実施され、
   パブリッシングサービスを前記イベントグリッドサービスに登録するために登録情報を受信するステップであって、前記登録情報が、前記パブリッシングサービスによって使用される現在のイベントスキーマ(event schema)を含み、前記登録情報は、サブスクライバーが、トピックについて受信されるイベント発行(publications)に反応するためにサブスクライブする前記トピックに対応する、ステップと、
   前記現在のイベントスキーマが前記トピックによって使用されるデフォルトのイベントスキーマに対応するかどうかを決定するために、前記パブリッシングサービスの現在のイベントスキーマを分析するステップと、
   前記パブリッシングサービスの現在のイベントスキーマが前記トピックのデフォルトのイベントスキーマに対応しないと決定することに応答して、前記パブリッシングサービスの現在のイベントスキーマを前記トピックのデフォルトのイベントスキーマにマッピングすることを試みるマッピングを自動的に導出する(deriving)ステップと、
   前記マッピングが導出された後、前記パブリッシングサービスからイベント発行を受信するステップであって、前記イベント発行が前記トピックに対応する、ステップと、
   前記イベント発行に含まれる少なくともいくつかのイベントデータを、前記少なくともいくつかのイベントデータが前記トピックのデフォルトのイベントスキーマに含まれるイベントフィールドにマッピングするような様式(manner)で翻訳する(translate)ために前
   記マッピングを使用するステップと
   を含む、方法。
2. 前記マッピングを自動的に導出する前記ステップが、前記パブリッシングサービスの１つまたは複数の属性(attributes)を分析して、前記マッピングが前記１つまたは複数の属性に少なくとも部分的に基づくようにさせることによって実施される、請求項１に記載の方法。
3. 前記パブリッシングサービスを登録するために前記登録情報を受信する前記ステップが、前記パブリッシングサービスを登録することに使用するために１つまたは複数のアプリケーションプログラムインターフェース（ＡＰＩ）を公開することによって実施される、請求項１に記載の方法。
4. 前記イベントグリッドサービスが、前記登録情報を格納するサブスクリプションデータベースを維持する、請求項１に記載の方法。
5. 前記マッピングを自動的に導出する前記ステップが、既存のマッピングが使用のために現在利用可能であることを決定することを含み、前記既存のマッピングが前回導出されている、請求項１に記載の方法。
6. 前記パブリッシングサービスから前記イベント発行を受信する前記ステップが、前記イベント発行を前記イベントグリッドサービスにプッシュする前記パブリッシングサービスによって実施される、請求項１に記載の方法。
7. 前記イベント発行が、ファイルが作成されたことを示す発行である、請求項１に記載の方法。
8. 前記イベントグリッドサービスが、複数の異なるパブリッシングサービスから複数のイベント発行を受信する、請求項１に記載の方法。
9. １つまたは複数のパブリッシングサービスからイベント発行を受信するため、および前記イベント発行内に含まれる情報を１つまたは複数のサブスクライバーにプッシュするための方法であって、前記方法は、コンピューターシステム上で実行するイベントグリッドサービスによって実施され、
   確立されたトピックに対応し、パブリッシングサービスから受信されるイベント発行を受信するステップであって、前記イベント発行がイベントデータを含む、ステップと、
   前記トピックおよび前記パブリッシングサービスの両方と関連付けられたマッピングを使用して、前記イベントデータの少なくともいくつかをマッピングするステップであって、その結果として、前記少なくともいくつかのイベントデータが、前記トピックのためのイベントスキーマ内に含まれるフィールドにマッピングする、ステップと、
   前記少なくともいくつかのイベントデータをマッピングした後、前記確立されたトピックに対応する任意のイベント発行内に含まれる特定のタイプのイベントデータが受信されるときに通知されることになる少なくとも１つのサブスクライバーを識別するステップであって、
   前記少なくとも１つのサブスクライバーが、前記イベントグリッドサービスとのサブスクリプションを有し、
   前記サブスクリプションが、前記特定のタイプのイベントデータを識別し、
   前記マッピングされた少なくともいくつかのイベントデータが、描写された前記特定のタイプのイベントデータに対応する特定のイベントデータを含む、ステップと、
   前記イベントデータから前記特定のイベントデータをフィルタリングするステップと、前記フィルタリングされた特定のイベントデータを前記少なくとも１つのサブスクライバーにプッシュするステップと
   を含む、方法。

Images