JP7483703B2 - 分散型コンピューティングのためのメッシュベースのイベントブローカー - Google Patents

Description

リアルタイムのイベント駆動型アプリケーションが次世代のビジネスアプリケーションとして注目の的になりつつあり、デジタル事業へと向かう事業の移行を支えている。パーソナライズされた最適な体験を提供する次世代の計画、運用および顧客エンゲージメントアプリケーションは、リアルタイムの感知と、ほぼリアルタイムの決定とに依存する。このようなアプリケーションは、現代的なイベント駆動型アプリケーションプラットフォームに構築されなければならない。

ある特定の要素または行為の考察を特定しやすくするために、参照符号における最上位の１つまたは複数の桁は、その要素が最初に紹介される図面の番号を示す。
一実施形態による、サービスとしてのプラットフォーム（PaaS : Platform‐as‐a‐Service）を示す。 一実施形態による、アーキテクチャを示す。 一実施形態による、デプロイメントを示す。 一実施形態による、デプロイメント環境を示す。 一実施形態による、デプロイメント環境を示す。 一実施形態による、デプロイメント環境を示す。 一実施形態による、分散型コンピューティング環境を示す。 一実施形態による、ルールシステムを示す。 一実施形態による、方法を示す。 一実施形態による、動作を示す。 一実施形態による、分散型コンピューティング環境を示す。 一実施形態による、メッシュイベントブローカーを示す。 一実施形態による、方法を示す。 一実施形態による、動作を示す。 一実施形態による、動作を示す。 一実施形態による、動作を示す。 一実施形態による、方法を示す。 一実施形態による、動作を示す。 いくつかの例示的な実施形態による、本開示を実施することのできるソフトウェアアーキテクチャを示すブロック図である。 いくつかの例示的な実施形態による、本明細書に述べられる方法論のうちの任意の１つまたは複数を機械に行わせるための命令セットを実行することのできるコンピュータシステムの形態の機械の図表示である。

用語集
この文脈における「搬送波信号（Carrier Signal）」とは、機械（machine）により実行するための命令を格納、符号化または搬送することが可能な任意の無形媒体をいい、当該命令の通信を可能にするためのデジタルもしくはアナログの通信信号または他の無形媒体を含む。命令は、ネットワークインターフェースを介して伝送媒体を使用してネットワークで送受信されてもよい。

この文脈における「通信ネットワーク」とは、アドホックネットワーク、イントラネット、エクストラネット、仮想プライベートネットワーク（VPN : virtual private network）、ローカルエリアネットワーク（LAN : local area network）、無線ＬＡＮ（WLAN : wireless LAN）、ワイドエリアネットワーク（WAN : wide area network）、無線ＷＡＮ（WWAN : wireless WAN）、メトロポリタンエリアネットワーク（MAN : metropolitan area network）、インターネット、インターネットの一部、公衆交換電話網（PSTN : Public Switched Telephone Network）の一部、基本電話サービス（POTS : plain old telephone service）網、携帯電話ネットワーク、無線ネットワーク、Ｗｉ‐Ｆｉ（登録商標）ネットワーク、別のタイプのネットワーク、または２以上のこのようなネットワークの組合せとしてもよい、ネットワークの１つまたは複数の部分をいう。例えば、ネットワークまたはネットワークの一部は、無線またはセルラーネットワークを含んでもよく、結合（coupling）は、符号分割多元接続（CDMA : Code Division Multiple Access）接続、グローバル移動体通信システム（GSM : Global System for Mobile）接続、または他のタイプのセルラーもしくは無線結合としてもよい。この例では、結合は、シングルキャリア無線伝送技術（1xRTT : Single Carrier Radio Transmission Technology）、エボリューション・データ・オプティマイズド（EVDO : Evolution‐Data Optimized）技術、汎用パケット無線サービス（GPRS : General Packet Radio Service）技術、ＧＳＭ進化型高速データレート（EDGE : Enhanced Data rates for GSM Evolution）技術、３Ｇなどの第三世代パートナーシッププロジェクト（3GPP : third Generation Partnership Project）、第四世代無線（４Ｇ）ネットワーク、ユニバーサル移動体通信システム（UMTS : Universal Mobile Telecommunications System)、高速パケットアクセス（HSPA : High Speed Packet Access）、マイクロ波アクセスの世界的な相互運用性（WiMAX : Worldwide Interoperability for Microwave Access）、ロングターム・エボリューション（LTE : Long Term Evolution）規格、様々な標準化団体が定義する他のもの、その他長距離通信プロトコル、またはその他データ転送技術など、多様なタイプのデータ転送技術のいずれかを実施してもよい。

この文脈における「構成要素（Component）」とは、機能もしくはサブルーチンの呼出し、分岐点、ＡＰＩ、または特定の処理もしくは制御機能の分割もしくはモジュール化を供する他の技術によって画定される境界を有するデバイス、物理的エンティティ、またはロジックをいう。機械プロセスを遂行するために、構成要素は、そのインターフェースを介して他の構成要素と組み合わせてもよい。構成要素は、他の構成要素とともに用いられるように設計されるパッケージ化された機能的ハードウェアユニット、および通常は関連機能のうちの特定の機能を果たすプログラムの一部であってもよい。構成要素は、ソフトウェア構成要素（例えば、機械可読媒体上に具現されるコード）またはハードウェア構成要素のいずれを構成してもよい。「ハードウェア構成要素」とは、一定の動作を行うことが可能な有形ユニットであり、一定の物理的な形で構成または配置されてもよい。様々な例示的な実施形態において、１つもしくは複数のコンピュータシステム（例えば、独立型コンピュータシステム、クライアントコンピュータシステム、もしくはサーバコンピュータシステム）またはコンピュータシステムの１つもしくは複数のハードウェア構成要素（例えば、プロセッサもしくはプロセッサのグループ）は、ソフトウェア（例えば、アプリケーションまたはアプリケーションの一部／構成要素）により、本明細書で説明される一定の動作を行うように作動するハードウェア構成要素として構成してもよい。ハードウェア構成要素は、機械的、電子的、またはその任意の適した組合せで実施されてもよい。例えば、ハードウェア構成要素は、一定の動作を行うように永久的に構成された専用回路系（dedicated circuitry）またはロジックを含んでもよい。ハードウェア構成要素は、フィールドプログラマブルゲートアレイ（FPGA : field-programmable gate array）または特定用途向け集積回路（ASIC : application specific integrated circuit）などの専用プロセッサとしてもよい。ハードウェア構成要素は、ソフトウェアにより、一定の動作を行うように一時的に構成されたプログラマブルロジックまたは回路系を含んでもよい。例えば、ハードウェア構成要素は、汎用プロセッサまたはその他プログラマブルプロセッサによって実行されるソフトウェアを含んでもよい。このようなソフトウェアによって構成されれば、ハードウェア構成要素は、構成された機能を果たすように特異的に誂えられた（uniquely tailored）特殊な機械（または機械の特殊構成要素）になり、汎用プロセッサではなくなる。ハードウェアを機械的に、専用の永久的に構成された回路系、または一時的に構成された回路系（例えば、ソフトウェアによって構成される）に実装するという決定が、費用および時間を考慮して推進されうることは認識されるであろう。したがって、「ハードウェア構成要素」（または「ハードウェア実装構成要素」）という語句は、本明細書に説明される一定の態様で動作するように、または一定の動作を行うように物理的に構築され、永久的に構成され（例えば、ハードウェアに組み込まれ）、または一時的に構成される（例えば、プログラミングされる）エンティティである、有形のエンティティを包含すると理解されるべきである。ハードウェアが一時的に構成される（例えば、プログラミングされる）実施形態を考えてみると、ハードウェア構成要素のそれぞれを一度に構成またはインスタンス化する必要はない。例えば、ハードウェア構成要素が、専用プロセッサになるようにソフトウェアによって構成された汎用プロセッサを備える場合、汎用プロセッサは、異なる時にそれぞれ異なる専用プロセッサとして構成されてもよい（例えば、異なるハードウェア構成要素を備える）。それに応じて、ソフトウェアは、例えば、ある時点で特定のハードウェア構成要素を構成し、異なる時点では異なるハードウェア構成要素を構成するように、特定の１つまたは複数のプロセッサを構成する。ハードウェア構成要素は、他のハードウェア構成要素に情報を提供するとともに、他のハードウェア構成要素から情報を受信することができる。したがって、説明されるハードウェア構成要素は、通信可能に結合されているとみなすこともできる。複数のハードウェア構成要素が同時に存在する場合、通信は、２以上のハードウェア構成要素間での信号伝送によって（例えば、適切な回路およびバスで）実現してもよい。複数のハードウェア構成要素が異なる時に構成またはインスタンス化される実施形態では、当該ハードウェア構成要素間の通信は、例えば、複数のハードウェア構成要素がアクセスできるメモリ構造内での情報の格納および探索により実現してもよい。例えば、１つのハードウェア構成要素が動作を行い、それが通信可能に結合されているメモリデバイスにその動作の出力を格納してもよい。それから、別のハードウェア構成要素が、後の時点で、メモリデバイスにアクセスして、格納された出力を探索して処理してもよい。ハードウェア構成要素は、入力デバイスまたは出力デバイスとの通信を開始してもよく、リソース（例えば、情報の集合体）に働きかけることができる。本明細書で説明される例示的な方法の様々な動作は、少なくとも部分的には、関連動作を行うように、（例えば、ソフトウェアによって）一時的に構成された、または永久的に構成された１つまたは複数のプロセッサによって行ってもよい。一時的に構成されるか永久的に構成されるかを問わず、当該プロセッサは、本明細書で説明される１つもしくは複数の動作または機能を行うように作動するプロセッサ実装構成要素を構成してもよい。本明細書で使用されるとき、「プロセッサ実装構成要素（processor-implemented component）」とは、１つまたは複数のプロセッサを用いて実装されるハードウェア構成要素をいう。同様に、本明細書で説明される方法は、少なくとも部分的にプロセッサに実装されてもよく、特定の１つまたは複数のプロセッサは、ハードウェアの例である。例えば、方法の動作の少なくともいくつかは、１つもしくは複数のプロセッサまたはプロセッサ実装構成要素によって行ってもよい。さらに、１つまたは複数のプロセッサは、「クラウドコンピューティング」環境で、または「サービスとしてのソフトウェア（software as a service）」（ＳａａＳ）として関連動作の遂行をサポートするように作動してもよい。例えば、動作の少なくともいくつかは、コンピュータのグループによって（プロセッサを含む機械の例として）行ってもよく、これらの動作は、ネットワーク（例えば、インターネット）を介して、および１つまたは複数の適切なインターフェース（例えば、ＡＰＩ）を介してアクセス可能である。一定の動作の遂行は、１台の機械の中に常駐しているだけでなく、多数の機械にデプロイされている（deployed）プロセッサ間に分散してもよい。いくつかの例示的な実施形態において、プロセッサまたはプロセッサ実装構成要素は、１つの地理的な場所に所在してもよい（例えば、家庭環境、オフィス環境、またはサーバファーム内）。他の例示的な実施形態では、プロセッサまたはプロセッサ実装構成要素は、多数の地理的な場所にわたって分散していてもよい。

この文脈における「コンピュータ可読媒体」とは、機械記憶媒体および伝送媒体の両方をいう。したがって、この用語は、記憶装置／媒体と、搬送波／変調されたデータ信号の両方を含む。「機械可読媒体」、「コンピュータ可読媒体」および「デバイス可読媒体」という用語は同じものを意味し、本開示において交換可能に使用することができる。

この文脈における「機械記憶媒体」とは、実行可能な命令、ルーチンおよび／またはデータを格納する、１台もしくは複数の記憶装置および媒体または記憶装置もしくは媒体（例えば、集中型もしくは分散型データベースと、関連のキャッシュおよびサーバと、の両方または一方）をいう。したがって、この用語は、プロセッサの内部または外部のメモリを含め、固体メモリ、ならびに光学媒体および磁気媒体を含むが、これだけに限定されないと解釈されるものとする。機械記憶媒体、コンピュータ記憶媒体および／またはデバイス記憶媒体の具体的な例には、例として半導体メモリデバイスを含む不揮発性メモリ、例えば、消去可能プログラマブル読み取り専用メモリ（EPROM : erasable programmable read-only memory）、電気的に消去可能なプログラマブル読み取り専用メモリ（EEPROM : electrically erasable programmable read-only memory）、ＦＰＧＡ、およびフラッシュメモリデバイス、内部ハードディスクおよびリムーバブルディスクなどの磁気ディスク、光磁気ディスク、ならびにＣＤ‐ＲＯＭおよびＤＶＤ‐ＲＯＭディスクが含まれる。「機械記憶媒体」、「デバイス記憶媒体」、「コンピュータ記憶媒体」という用語は同じものを意味し、本開示において交換可能に使用することができる。「機械記憶媒体」、「コンピュータ記憶媒体」および「デバイス記憶媒体」という用語は、特に、搬送波、変調されたデータ信号および他のこのような媒体を除外し、そのうちの少なくともいくつかは、「信号媒体（signal medium）」という用語でカバーされる。

この文脈における「信号媒体」とは、機械によって実行するための命令を格納、符号化または搬送することが可能な任意の無形媒体をいい、ソフトウェアまたはデータの通信を可能にするデジタルもしくはアナログの通信信号またはその他の無形媒体を含む。「信号媒体」という用語は、任意の形態の変調されたデータ信号、搬送波などを含むと解釈されるものとする。「変調されたデータ信号」という用語は、信号内の情報を符号化するようなことで設定または変更される１つまたは複数の特性を有する信号を意味する。「伝送媒体（transmission medium）」および「信号媒体」という用語は同じものを意味し、本開示において交換可能に使用することができる。

この文脈における「メッシュネットワーク（Mesh Network）」とは、計算ノードができるだけ多くの他のノードに、例えば、直接、動的におよび非階層的に接続する分散型コンピューティング環境のためのネットワークトポロジ（network topology）をいう。そのため、ノードが協力し合って、そのソースからその宛先までのネットワークトラフィックの経路を指定してもよい。メッシュネットワークは、動的に自己組織化し、自己設定してもよい。他のすべてのピアノードに各ノードが接続しているメッシュネットワークは、フルメッシュネットワーク（full mesh network）として知られる。大きいけれども潜在的に選択的なピアノードの集合に各ノードが接続しているメッシュネットワークは、パーシャルメッシュ（partial mesh）として知られる。

説明
分割（PARTITIONING）
「アプリケーション分割（application partitioning）」という用語は、アプリケーションロジックをネットワーク内の２以上のコンピュータに分散するアプリケーション開発プロセスをいう。最も単純なケースでは、アプリケーションは、リモートサービスとして１台のＰＣ上で動作し、実行するためのタスク要求をサーバに送信する。より高度なケースでは、アプリケーションロジックは、数台のサーバに分散することができる。

現在のアプリケーション分割システムは、ローカルエリアネットワークに分散されるオブジェクト指向型アプリケーションの小分け（portioning）に集中する（focus）。このような分割システムは、ユーザが特定のオブジェクトインスタンスを特定し、さらにそれを手動で特定の計算ノードに配置することに依存する。本明細書で説明されるように、手動アサイン（manual assignments）が実施されると、分割システムは、手動アサインを考慮せずに、続いて残りの構成要素をパーティションに割り当て、さらに、いくつかの例示的な実施形態によると、分散型テクノロジーおよびメカニズムでのアクセスのために各ノードを表すオブジェクトをバインドして（binds）、イベントベースのアプリケーションを分割する。具体的には、サービスとしてのプラットフォーム（Platform-as-a-Service : ＰａａＳ）１００が説明され、これは、分散型コンピューティング環境内のノードセットを特定し、さらにイベントベースのアプリケーションにおいてイベントの識別を使用して、当該イベントベースのアプリケーションの自動分割を行うように作動するデプロイメントマネージャ（deployment manager）を含む。このために、デプロイメントマネージャ、より具体的には、デプロイメントマネージャの一部を形成する分割システムがイベント駆動型アプリケーションのソースコードを分析して、イベント駆動型アプリケーションの構成要素間の関係を推定する。分割システムは、次いで、ルールシステム（例えば、アサインルール）を介して、既知の関係のナレッジベース（knowledge base）を適用して、分割作業を行う。次いで、分割システムは、１つまたは複数の設定ファイルとして、自動分割を反映する設定（configurations）を出力する。

説明される実施形態は、分割作業を駆動するためにオブジェクトインスタンスを前もって生成することを必要としないことから、説明される実施形態は、公知の解決策を上回る多数の技術的な利点を提供する。また、説明される実施形態は構成要素の配置を最適化するのに対し、多くの現在の解決策は、コンピューティング環境内のすべての計算ノード上に実行可能なコードをすべて配置するように作動する。さらに、説明される実施形態は、オブジェクトがただ単に必要ないためにオブジェクトを一緒にバインドせず、バインディング（bindings）は、イベントベースのアプリケーションのアーキテクチャの機能として動的である。

イベントブローカー（EVENT BROKER）
イベント駆動型アーキテクチャ（EDA : event-driven architecture）とは、イベントの発生、検出、消費およびイベントに対する反応に基づくソフトウェアアーキテクチャである。イベントは、技術的観点からは状態の変化とみなされ、それに応答してイベント通知が発生される。イベント通知は、イベント通知の伝送をトリガした状態変化の通知である。ＥＤＡは、イベント通知を疎結合ソフトウェア構成要素およびサービス間で伝送するアプリケーションおよびシステムによって実装されてもよい。ＥＤＡは、イベントトランスミッタ、イベントコンシューマ、およびイベントチャネルを含んでもよい。あるＥＤＡは、イベントブローカーを採用することがあり、当該イベントブローカーは、イベントを取得および配信する中央メディエータ（centralized mediators）として使用される。メディエータは、分散型コンピューティング環境内の単一の論理ノードに常駐するプロセスとしてもよい。イベント通知（またはメッセージ）がメディエータに送信され、拡張されてから、メディエータを介してイベントコンシューマ（event consumer）（例えば、イベントサブスクライバ（event subscriber））に配信される。このアプローチは、レガシーアーキテクチャに基づいており、最初にメッセージブローカーで始めてから、後でイベントブローカーによって採用される。

いくつかの例示的な実施形態によると、メッシュイベントブローカーが提供され、当該メッシュイベントブローカーは、１つまたは複数のイベントエコシステムに参加する分散ノードにイベントの取得、拡張および配信を分散し、当該分散ノードは、イベント発行者、イベントサブスクライバおよび仲介者を含む。いくつかの実施形態では、メッシュイベントブローカーは、メディエータを単一障害点（single point of failure）として除き、スケーリングを単純化および拡大するために作業負荷を分散し、異なるネットワーク内のイベント発行者とイベントサブスクライバとの相互接続を提供することを図る。

いくつかの例示的な実施形態によると、協働するエージェントの集合体が「メディエータ」として作用し、直接的な２点間通信をサポートするメッシュネットワークを形成する。協働する各エージェントは、拡張をサポートするとともに、サポート対象の発行者によって発行されるイベントに発行者とサブスクライバとの特定のセットの配信を行うためにプロビジョニングされる（provisioned）。同様に、サブスクライバは、自身がローカルサブスクライバであるイベントを拡張および配信するためにプロビジョニングされてもよい。加えて、協働するエージェントは、メッシュとして、メッセージをメッシュに転送して、イベント伝送の効率を改善するとともに、異なるネットワーク上に設定されるエージェント間の橋渡しをすることができる。

イベント駆動型アプリケーション（EVENT-DRIVEN APPLICATIONS）
いくつかの例示的な実施形態によると、イベント駆動型アプリケーションは、応答性、ロバストネスおよびセキュリティを改善するために、分散されるようにデプロイしてもよい。本明細書で説明されるとき、イベント駆動型アプリケーションは、１つのクラウドロケーションで開発されてから、自動的に分割されてもよく、その結果、アプリケーションの構成要素は、ノードがクラウドホスト型か、データセンターホスト型か、エッジのインテリジェントデバイスか、またはそれらの組合せかどうかを問わず、実行のために最適なノードに分散されることになる。ロジックは、それが最も効果的なところに配置される。星型、階層型およびピアツーピア型などの広範囲のシステムトポロジがサポートされる。これらのネットワークのプロビジョニングと管理は、自動化されて、本明細書で説明するサービスとしてのプラットフォーム（ＰａａＳ）１００のインテリジェント機能によって管理される。アプリケーション構成要素は、システムが動作している間、何千または何万のノードのための分散型環境のどこでも動的に変更することができる。

説明される例示的な実施形態は、システムの開発がビジネスロジックに集中することができ、必ずしも基盤となるインフラストラクチャに集中しなくてよいように、リアルタイムのイベント駆動型アプリケーションの設計、プロビジョニングおよび管理の自動化も図る。このために、サービスとしてのプラットフォーム（ＰａａＳ）１００は、イベント駆動型ビジネスアプリケーションを構築し、デプロイしおよび作動させることのできる、速度と効率の改善を図る能力および統合を提供する。

いくつかの例示的な実施形態によるイベント駆動型アプリケーションは、以下のフローを組み込んでもよい。
・入力は、例えば長期間かけて、多数のセンサから受信する。センサは、例えば、物理的センサ、他のエンタープライズシステムによって生成されるデータストリームまたは公開データストリームとしてもよい。
・センサデータを分析して、情報およびコンテキストからなるイベントを発生させ、それに対して自動化、推奨（recommendation）および協調の決定が行われる。追加のコンテキストを他のシステムから抽出して、センサデータを拡張してもよい。
・イベントは、リアルタイムで評価して、取る必要のあるアクションを決定する。例えば、リアルタイム評価を行うために、個別的ルールおよび機械学習戦略のうちの少なくとも一方を使用してもよい。
・アクションを、実施を担当するシステムに伝送するか、または担当者によって人間と機械の協調を開始し、現状に対して最も適切な応答を決定する。

リアルタイムのイベント駆動型ビジネスアプリケーションでは、処理は、制御下のデバイスにローカルに行ってもよいので、応答時間および信頼性が改善される。例えば、工業的な環境では、材料取扱いシステムの位置を管理するには、数百ミリ秒内のほぼリアルタイムの応答をする必要がある。ネットワークに問題があれば数千ミリ秒の遅れが生じうる遠隔意思決定システムでは、当該応答時間を保証することはできない。状況データへのアクセスおよび制御アクションを開始する能力を慎重に管理するセキュアな環境で、処理が行われる。

高レベルでは、本明細書に説明されるようなイベント駆動型アプリケーションは、データ取得、状況分析および検出された状況に対する応答アクションなどの動作を行うように作動してもよい。

まずデータ取得または感知に対処して、イベント駆動型アプリケーションは、多数のセンサのうちの任意のものからデータを受信してもよい。センサには、例えば、以下のものを含めてもよい。
・センサの生データから導出されるロケーション、加速度、音声、映像および行動パターンを含むセンサデータをホストする携帯機器
・腕時計、活動量計、ヘルスモニタ、音声および映像ヘッドセットなどのウェアラブルデバイス
・産業機械、陸上および航空輸送機関、家電、ならびに感知と制御のうちの少なくとも一方ができる任意の機械的または電子的機器を含む機械。例えば、様々な破砕点（crush points）を有しうる物体にかかる圧力を変えるために圧力センサを装備されているロボットのマニピュレータを想像されたい。
・数多くデプロイされる独立型センサ。例えば、作物の成長率を最大化しながら、水消費量を最小化するために、農場中に分散される水分センサ。
・センサデータと考えることができるものを大量に生成する映像および音声フィード。認識ソフトウェアを使用して映像が表すものを決定し、映像をより個別的なイベントに翻訳して、自動化の決定がそれに依存できるようにする。
・トランザクションのストリームを生成する既存のエンタープライズアプリケーション。

このようなセンサは、それ自体のＩＰ通信スタックでインターネットに直接接続することができ、またはエッジノードを介して間接的にインターネットに接続してもよい。後者の場合、センサ自体は、ＭｏｄｂｕｓまたはＺｉｇＢｅｅなどのより特化したプロトコルでプロトコル変換をもたらすエッジノードと通信してもよいので、センサは、ＩｏＴに参加する仮想ノードのように見える。

ここで状況分析に移ると、データが取得されてしまえば、リアルタイムのイベント駆動型アプリケーションが、データの分析と、応答を要するビジネスまたは、技術的な条件を表すイベントまたは状況の発生とを担ってもよい。イベント駆動型アプリケーションは、次いで、機械もしくは顧客の現状に対する自動応答、および適切なオペレーションスタッフとシステムとの間の協調、の両方また一方を開始して、最適な応答を発生させてもよい。

イベントおよび状況は、ルール、統計手法、および機械学習を用いて、データストリームおよびそのコンテキストを分析することによって検出してもよい。
分析中に検出されうるイベントまたは状況の例には、単なる例として、以下のものが含まれる。
・高温または低速などの条件があり予想通りに機能していない機器。
・店舗または施設内の関心のある場所に到着した顧客。例えば、顧客がレジまたは特定の商品ディスプレイのところに立っている。
・ユーザが安全ではないエリアにいて、助けが必要である。
・製品管理の注意を要する注文の配送が変更された。

状況が検知されたら、その状況に対する応答をイベント駆動型アプリケーションによって生成してもよい。その応答は、自動化システムによって自動的に開始される応答であっても、または自動化システムと担当者との協調によって決定される応答であってもよい。応答には、以下のものを含んでもよい。
・コンシューマの現在の状況に基づいて、コンシューマに関連のある応答を与えること（例えば、セール中のアイテム、施設の地図、緊急時対応の推奨）。
・異常な状態に対してインテリジェントに応答すること（例えば、弁を閉じる、スプリンクラーをオンにする、誤作動するロボットを停止する）。
・現在の状況に基づいて、機会／問題をスタッフに早めに警告すること（例えば、利用可能な追加の配送トラック、サプライチェーンの一部の不足）。
・生産性と顧客満足度とのうちの少なくとも一方を上げるために、ユーザまたはビジネスリソースを最適化すること（例えば、組立ラインのスピードアップ、スポーツ参加者に自家用車までの最短経路を知らせる）。

状況に応じて、自動化された応答は、リアルタイムのイベント駆動型ビジネスアプリケーションによって直接受けてもよく、または実施するためにより特化されたシステムに転送してもよい。例えば、機械を停止させるアクションは、アプリケーションに停止コマンドを機械へ直接送信させるのではなく、機械を直接管理する制御システムに転送してもよい。

最適な応答がやや曖昧になりうる状況、または最適な応答の決定がシステムの能力を超えている状況では、システムと担当者とを巻き込んだ協調作業で最適な応答を引き出す。例えば、センサの読取値は、機械に潜在的な問題があることを示している可能性があるが、自動的に機械の停止を決定するほどには十分な情報がないことがある。代わりに、オペレーションチームがシステムと協調して、現在のデータを検証し、例えば、機械の目視点検により追加情報を得て、その状況が機器の停止を必要とするかどうかを判断する。

協調が最適な結果を生み出すことのできるいくつかのケースは、以下の通りである。
・データストリームが、根本原因を一意に明らかにして最善なアクションの方針を決定するには十分ではない例外状況。
・オペレーションチームが、システムには入手できない追加情報を知りうる立場にある状況。
・システムの側に、オンラインで制御できない手動アクションを取らなければならない状況。
・アクションを行えるようになる前に、ポリシーまたは規制により、より徹底的な状況分析が要求される状況。

別の重要な協調のクラスは、取られるアクションと、その結果としてのシステムの新たな状態とを関係者に通知する。通知は、他の自動化システムに配信して、かかる他の自動化システムが独立して状況に応答できるようにすることができ、または、デスクトップＰＣ、携帯機器およびウェアラブルデバイスを介して担当スタッフに配信することができる。通知は、推奨されるアクションおよび未解決の問題の状況認識も含むことができる。

リアルタイムのイベント駆動型ビジネスアプリケーションを分散させてもよい。例えば、製造環境において、プログラマブルロジックコントローラ（PLC : Programmable Logic Controller）は、エリアコントローラおよびエッジノードと通信し、これらがデータを、より集中化されたＩＴシステムに転送する。コンシューマ環境では、データは、ローカルに処理される多数の位置センサから、即座の自動決定が行われる論理的な場所に集められ、コンシューマの体験を最適化するリモートシステムに転送してもよい。このような多様な分散型アプリケーションは、中央サイトに直接報告するデバイスから、階層的構造にされた自動化システム、組織またはビジネスの集合体を改善するために協調する連合ピア（federated peers）までに及ぶ、同様に幅広い分散型トポロジのセットのサポートを必要とする。

単純なアーキテクチャは、センサが中央サイトに報告する。例えば、携帯電話からセンサデータを収集して、そのデータをクラウドサービスに報告するシステムは、集中型アーキテクチャの例を表す。

より高度なアーキテクチャは、追加の処理および接続性レベルを含む。階層型システムは、より複雑で、多くの既存の物理的および組織的な構造体に似ている。例えば、ローカルコントローラに報告するセンサからなり、そのローカルコントローラがプラント全体のコントローラに報告し、それが部門本部に報告し、それが企業本社に報告する、産業用ＩｏＴシステムは、木トポロジ（tree topology）を表す。これらのシステムは、集中型および非集中型両方の監視および制御を提供する。このようなシステムは、リアルタイムまたはほぼリアルタイムの状況において応答性が高い。例えば、データを収集し、データを企業本社に伝送し、企業本社のシステムに機械の次のアクションを判断させることによって、工場設備をリアルタイムで制御することは最適ではないことがある。ローカルコントローラでこのような分析を行い、状況と取るアクションとを工場全体のコントローラに、その後地域および企業本社に報告するだけだと、より効果的となりうる。応答時間の迅速化、可用性の改善およびローカル制御により、状況評価、協調的な意思決定、および応答処理を階層型トポロジに分散させることは、すべてを本社に移動して、すべての決定を集中的に行うよりも効率的である。

階層型リアルタイムのイベント駆動型ビジネスアプリケーションの別の例は、センサおよび制御点の集合体のためのローカルプロセッサとして機能するエッジノードを使用することであり、エッジノードは、さらに、より集中化されたシステムと対話する。

高度な分散型リアルタイムのイベント駆動型ビジネスアプリケーションの例は、ピアツーピアシステムであり、そこでピアは、個別の組織によって管理される。例えば、電力需要応答システムでは、システム全体は電力会社が管理するセンサと電力需要家（utility customers）が管理するセンサとからなるが、システムの制御は、電力会社およびその需要家に分散される。リアルタイムの需要応答を提供するために、電力会社システムと需要家システムとは協調しなければならない。これは、各システムがローカルな決定を行い、ローカルな状況とローカルな決定との両方を相手側に伝送し、さらに互いからのフィードバックに基づいてそれぞれのリアルタイムの行動を修正することに合意することによって実現される。

サービスとしてのプラットフォーム（PLATFORM-AS-A-SERVICE : ＰａａＳ）
図１は、説明される技術の例示的な実施形態をデプロイしてもよいサービスとしてのプラットフォーム（ＰａａＳ）１００の高レベルの機能性を示すブロック図である。サービスとしてのプラットフォーム（ＰａａＳ）１００は、リアルタイムのビジネスアプリケーションの開発、デプロイメントおよび動作をサポートするように設計され、構築される。具体的には、サービスとしてのプラットフォーム（ＰａａＳ）１００は、開発者ポータル１０２を含み、それを使用して開発者は、イベント駆動型アプリケーション１０４を開発し、これをさらに分散型ランタイムノード１０６にデプロイする。システムモニタ１０８は、分散型ランタイムノード（distributed run-time nodes）１０６上のイベント駆動型アプリケーション１０４の動作を監視し、開発者がイベント駆動型アプリケーション１０４を進化させることができるように、開発者ポータル１０２にフィードバックをする。

イベント駆動型アプリケーション１０４は、イベント駆動されてもよい（例えば、データを格納して、最新のステータスチェックを行うのではなく、イベントに対して瞬時に反応する）。サービスとしてのプラットフォーム（ＰａａＳ）１００はさらに、リアクティブフレームワーク（Reactive framework）に実装してもよいので、非同期のノンブロッキングプラットフォーム（non-blocking platform）を提供することにより、リアルタイムの機能性をサポートする。高度に分散され大規模な環境でのイベントストリーム（例えば、もののインターネット（IoT : Internet‐of‐Things）環境からイベントを受信する場合）は、従来の三層アーキテクチャから、イベントベースのモデルに移行する技術的な動機になる。

サービスとしてのプラットフォーム（ＰａａＳ）１００はさらに、数多くのイベントを提示するイベント駆動型アプリケーション１０４の設計およびランタイムをサポートする。このために、サービスとしてのプラットフォーム（ＰａａＳ）１００は、分散型環境に大量の数の分散型ランタイムノード１０６のトポロジを使用可能にする。分散型ランタイムノード１０６は、追加の処理能力を提供するために、水平にピア接続され（peered horizontally）てもよい。収集されるデータ（または生成されるイベント）の量が中央プロセッサへのアップロードの限界を超える場合、または低レイテンシが要求される場合、分散型ランタイムノード１０６は、トポロジのエッジのデータの近くに処理を移動させるために、木構造で配置されてもよい。

さらに、分散型ランタイムノード１０６は、ミッションクリティカルな可用性（mission-critical availability）を確保するために水平にクラスタ化されてもよい。

イベント駆動型アプリケーション１０４は、イベントベースのアーキテクチャ、およびリアクティブプログラミングの利点をもたらす一方で、開発者ポータル１０２は、「ローコード（low-code）」開発ツールの提供によりＪａｖａＳｃｒｉｐｔおよびＳＱＬを理解するだけでよい。開発ツールは、イベント駆動型アプリケーション１０４のより複雑な要素のための高生産性かつ高水準の、スクリプティングがビジュアル開発に向かない構成要素のビジュアル宣言をサポートする。具体的には、開発者ポータル１０２は、ルール、タイプ、ソース、協調、トピックおよび設定のためのビジュアルエディタと、ルールおよびプロシージャのためのスクリプトエディタと、既存のスキルを活用するためにＳＱＬおよびＪａｖａＳｃｒｉｐｔに基づいてドメイン固有言語（domain-specific language : ＤＳＬ）とを提供してもよい。加えて、開発者ポータル１０２は、ルール及びプロシージャデバッガ（rule and procedure debugger）による検査能力、トレーシングおよびロギングファシリティ（tracing and logging facilities）、リアルタイムのサブスクリプションサポートおよびデータ視覚化、合成データ生成器、および増分デプロイメントを提供する。さらに、開発者ポータル１０２は、分散型構成によるデプロイメント（例えば、クラウド、プライベートクラウド、オンプレミス、ハイブリッドおよびエッジ）と、ビジュアルデプロイメントツールとをサポートする。

イベント駆動型アプリケーション
図２は、いくつかの例示的な実施形態による、サービスとしてのプラットフォーム（ＰａａＳ）１００のイベント駆動型アプリケーション１０４のアーキテクチャ２００に関するさらなる詳細を示すブロック図である。

サービスとしてのプラットフォーム（ＰａａＳ）１００は、以下のものからなる高性能分散型リアルタイムのイベント駆動型ビジネスアプリケーション（例えば、イベント駆動型アプリケーション１０４）の開発、デプロイメントおよび作動を行うプラットフォームサポートを提供する。
１．データ取得：ＩｏＴおよびエンタープライズソースからデータを取得し、データをフィルタリングして、それを自動決定エンジンに利用できるようにする技術。
２．イベントおよび状況分析：データをリアルタイムで分析し、その結果に基づいて決定を行う決定エンジン。
３．アクション：制御情報をデバイスに送信し、自動化ソリューションによって行うその後のアクションに関する決定または推奨を外部システムおよびユーザに通知するための技術。複雑な状況に対する最適な応答を引き出すために、自動化システムと担当者との協調を管理する技術。

このために、図２は、イベント駆動型アプリケーション１０４が、データアダプタ（data adapters）２０２と制御アダプタ２０４とを含むいくつかのアダプタ（adapters）を含むことを示す。イベント駆動型アプリケーション１０４は、多数のルール、具体的にはデータインジェスト・エンリッチ化ルール（data ingestion and enrichment rules）２０６、状況識別ルール２１０および協調ルール２１２も含む。

データインジェスト・エンリッチ化ルール２０６は、データアダプタ２０２が受信するデータのインジェストおよびエンリッチ化を担う。データアダプタ２０２およびデータインジェスト・エンリッチ化ルール２０６は、データ取得サブシステムの一部を形成し、いくつかのエンタープライズシステム、公開データソース、ソーシャルデータソース（例えば、メッセージングシステム、またはＲＥＳＴインターフェースを備える任意のシステム）との統合を可能にする。データインジェスト・エンリッチ化ルール２０６は、データアダプタ２０２が受信するデータのインジェストおよびエンリッチ化を担う。

大まかにいうと、データ取得サブシステムは、例えば、ＲＥＳＴ、ＭＱＴＴおよびＡＭＱＰなどの標準的なプロトコルを使用することによって、幅広いデータソース群からデータを取得する。データソースは、例えば、ＩｏＴデバイスおよびエンタープライズシステムを含んでもよく、これらは、センサから流れ、センサデータを適切なコンテキストに配置するデータを評価するために必要なコンテキストを保持する。例えば、イベント駆動型アプリケーションが顧客のロケーションを追跡することによって顧客を支援している場合、顧客のプロファイル情報を取得し、ユーザをその現在のロケーションで支援する機会を評価するには、顧客リソース管理（CRM : Customer Resource Management）システム内の情報へのアクセスが必要となりうる。このため、アプリケーションの一部としての既存システムの統合が非常に重視される。サービスとしてのプラットフォーム（ＰａａＳ）１００は、既存のエンタープライズシステムをリアルタイムのイベント駆動型ビジネスアプリケーションに組み込むことを可能にする広範囲の宣言型統合（declarative integrations）を提供する。

サービスとしてのプラットフォーム（ＰａａＳ）１００は、以下のことをサポートしてもよい。
・プッシュおよびプル（push and pull）の両モデル
・同期モデルおよび非同期モデル
・ＲＰＣ（Remote Procedure Call : 遠隔手続き呼出し）、ならびに蓄積交換式メッセージングシステム
・ソースは、文書化された指定フォーマットをマッチングしてデータを送信する選択をしてもよく、またはＰａａＳ１００にネイティブソースフォーマットを受け入れさせて、フィルタリングシステムを使用してそれを内部処理用に適切なフォーマットに変換する選択をすることができる。

これらの能力を備えるデータ取得サブシステムは、サービスとしてのプラットフォーム（ＰａａＳ）１００のメッセージングモデルにソースをマッチングさせることを要するのではなく、対話モデルとソースのメッセージプロトコルとをマッチングするだけでソース統合（source integration）を行う。

また、サービスとしてのプラットフォーム（ＰａａＳ）１００は、外部システムにデータソースとの直接的な通信を許さないファイヤウォールの背後でホストされるデータを管理するためのモデルをサポートする。

データ取得サブシステムの柔軟な性質により、ファイヤウォールを通して配信することのできない外部要求に対する応答をソースに要求するのではなく、当該ソースがその裁量でデータを提供することが可能になる。

ピアノード内のデータにアクセスするには、サービスとしてのプラットフォーム（ＰａａＳ）１００にユーザ指定のクレデンシャルを使用するよう要求することによって、セキュリティを維持してもよい。したがって、すべてのノードは、どのピアノードがローカルノードへのアクセスが許可されているかを判定するにあたり完全な制御を有する。

イベントおよび状況の識別および分析は、状況識別ルール２１０によって行う。具体的には、状況識別ルール２１０は、単純な設定および複雑な設定の両方で、ストリーミングデータを処理してもよい。
・複数のストリームからのデータを、状況分析を助けるために相関付けることができる。開発者は、ＳＱＬから導出される単純なドメイン固有言語を使用して、あるストリームで検出されたイベントを別のストリームのイベントの前か後にこなければならない、または両方のイベントがどちらの順序で起こっても特定の時間枠内に生じなければならないと指定する。イベントが起こらない場合でも、一般的なエラーインジケータを単純なやり方で指定することができる。複雑な条件の指定を単純にするイベント制約をどのレベルにも構成することができる。例えば、自動化システムは、機械的デバイスの２つのセンサストリームを監視してもよく、第１のストリームが速度を報告し、第２のものが位置を報告する。自動化システムがデバイスに停止要求を送る場合、第１センサで読み取られるデバイスの速度がゼロになり、速度ゼロの読み取りが確認されたら、デバイスの位置は変わらないままであることが確認されると予想する。速度ゼロになった「後」の位置変化が報告された場合、警告が発せられる。また、速度ゼロが報告されてから３０秒以内に位置が報告され「なけれ」ば、デバイス制御システムの故障の可能性を示す警告が発せられる。
・あるストリーミングデータは、即座に処理されるか、または短時間のみ保持されて、時系列構造を促進する一方、他のデータは、より長期間維持されなければならない長期的な時系列または履歴データを表してもよい。ＰａａＳ１００は、連続データおよび集合データをその一時的および永続的形式の両方で表すために使用される抽象化を一元化することによって、一時的および永続的データの両方の使用を単純にする。
・データは、ルールの個別的な集合体により、または機械学習システムによって生成されるアルゴリズムにより分析され、その後アプリケーションに統合される。
・データをＳＱＬベースのドメイン固有言語を使用して分散型トポロジの他のノードに転送し、分散型環境全体でリアルタイム処理を容易にサポートするための完全なサービスセットが利用できる。

自動化および協調は、制御アダプタ２０４および協調ルール２１２によってサポートされる。
協調ルール２１２は、人間のユーザとサービスとしてのプラットフォーム（ＰａａＳ）１００の構成要素との間に、人間と機械との協調を実施するために使用される。協調ルール２１２は、人間のユーザとサービスとしてのプラットフォーム（ＰａａＳ）１００内の機械とが、状況に応じて、できるだけ独立してまたは協調的に働き、互いの要求を調整することを可能にすることを図る（例えば、システムが反応しているときに人間のユーザが動作（operations）を駆動する（drives）、またはユーザが反応しているときにシステムが動作を駆動する）。

アクションは、システムの内部状態に直接適用してもよい。アクションをＲＥＳＴ、ＭＱＴＴ、ＡＭＱＰその他などの標準的な統合、またはカスタム統合を使用して外部デバイスまたはエッジノードに配信するソース統合（例えば、制御アダプタ２０４）を使用して、アクションを外部デバイスに適用してもよい。

サービスとしてのプラットフォーム（ＰａａＳ）１００は、アプリケーションとそのユーザとの間の協調を必要とするアクションまたは応答を作成するモデルを提供する。協調モデルは、開発者ポータル１０２のグラフィカルエディタを使用して、高レベルの協調パターンを構成することにより、協調の開発をサポートする。例えば、協調ルール２１２は、以下を含む多数の協調パターンをサポートしてもよい。
・通知－ＳＭＳ、ＥＭＡＩＬ、プッシュ通知およびメッセージングシステムを介して通知および応答を処理する。
・アサイン－タスクへのユーザのアサインをネゴシエートする。
・ロケーション追跡－ユーザが指定目的地に到着するとき、およびその目的地に向かって移動中のユーザの現在のロケーションを知るタスクを大幅に簡素化する。
・会話－サードパーティメッセージングシステムによりユーザ間の会話を媒介する。
・エスカレーション－タスク完了の重大な遅延に応答する。

サービスとしてのプラットフォーム（ＰａａＳ）１００は、協調的な意思決定プロセス全体に人を統合しやすくするために使用することのできるモバイルクライアントもサポートする。クライアントは、自然で効率的な対話をサポートするように設計される。ユーザには、注目する必要のある状況が自動的に通知され、各通知のカスタムインターフェースが、ユーザに必要な情報を供給する。ユーザは、携帯機器のデータキャプチャ機能（映像、写真、音声、ロケーション、加速度、自然言語処理による音声、および従来のテキスト入力）を使用することによって応答することができる。

多くのシステムは、アプリケーションの分散性を明確にプログラミングし、設定し、デプロイすることを強いるが、サービスとしてのプラットフォーム（ＰａａＳ）１００は、アプリケーションの論理的な定義をその物理的なデプロイメントから分離することによって、これらの動作を簡素化する。開発者ポータル１０２を使用して、開発者は、アプリケーションをそれが１台のシステムで動作するものであるかのように定義することができる一方で、アプリケーションの構成要素は、ベイルルール（vail rules）２１４を使用して自動的にノードにプロビジョニングされる。ランタイムに、サービスとしてのプラットフォーム（ＰａａＳ）１００の分散型ランタイムノード１０６は、一緒に動作して、分散型コンピューティング環境２１６内で１つのリアルタイムビジネスアプリケーションとして機能し、そのアプリケーションに関連するイベントは、イベントブローカー２０８によって処理される。

トポロジ
サービスとしてのプラットフォーム（ＰａａＳ）１００は、分散型および連合型のトポロジの一般的モデルをサポートする。分散型アプリケーション（例えば、イベント駆動型アプリケーション１０４）は、各ノードが設備（installation）を表す２以上のノードからなってもよい。設備は、１つのサービスインスタンスまたはサービスインスタンスのクラスタを含むことができる。設備がメッセージ交換を望む少なくとも１つの「ピア」ノードを設備が宣言すると、設備は、分散型トポロジにアセンブルされる。

設備は、デフォルトでは、独立して管理されると考えられる。別のノードＢをピアとして宣言するノードＡは、ノードＢにアクセスするのにクレデンシャル（credentials）を有していなければならない。このように、サービスとしてのプラットフォーム（ＰａａＳ）１００は、自然に連合される。ノードがピアノードで所望の動作を実行する十分な権利を付与されていた場合にのみ、ノードは、別のノードとメッセージを交換できるからである。ピアリング（Peering）は、対称性である。ノードＢがノードＡとメッセージの交換を望む場合、ノードＢは、ノードＡをピアとしてプロビジョニングし、ノードＡにアクセスする十分な権利をもたなければならない。

ピアリング関係は、任意の２つのノード間で定義することができるため、サービスとしてのプラットフォーム（ＰａａＳ）１００は、任意の分散型トポロジをサポートすることができる。また、認証および許可は、各ノードで独立して管理されるため、トポロジは暗黙的に連合される。

一定の使用パターンが、分散型システム内の全ノードを１つの当局によって管理するトポロジを必要としてもよい（または優先してもよい）。このようなシステムは、星型および木型のトポロジに組織化されてもよい。
・星型－１つの親ノードと任意の数の子ノードとからなる。
・木型－根ノードと任意の数の子ノードとからなり、各子ノードが任意の数の子ノードの親として機能してもよい。

デプロイされたシステムがより協調的になってくるにつれ、より全体的に連合したピアツゥピアネットワークが構築される。このようなネットワークトポロジでは、任意のノードは任意の他のノードとピアリングしてもよいので、ノード間の接続を表す一般グラフ構造（general graph structure）になる。ネットワークモデルは、非常に複雑になりがちである。グラフのサイクルが起こりうるが、サイクルは、グラフ内の２以上のノードに作用する任意の機能によって扱われなければならないからである。

また、各ノードは、個別のクレデンシャルを要しうる独立システムを表すため、サービスとしてのプラットフォーム（ＰａａＳ）１００は、協調する組織間の連合に当然一般化する。

デプロイメント（DEPLOYMENT）
図３は、一例示的な実施形態による、イベント駆動型アプリケーション１０４のデプロイメント３００を示す図表示である。具体的には、サービスとしてのプラットフォーム（ＰａａＳ）１００はデプロイメントマネージャ３０４を含み、これが、分散型コンピューティング環境２１６などのターゲット環境へのイベント駆動型アプリケーション１０４のデプロイメントを操作管理する。図３は、デプロイメントマネージャ３０４が動作しているノードから直接的または間接的のいずれかで到達可能な多数のノードからなるものとして、分散型コンピューティング環境２１６を示している。分散型コンピューティング環境２１６内の物理ノードは、ノードセットに組織化してもよく、そこで、ノードセットについて確立された基準を満たす記述的特性を有することに基づいて、ノードは、特定のノードセットのメンバーとなる。

分散型コンピューティング環境２１６内の各ノードは、特定のデバイスまたは構成要素に関連付けられている計算リソースとしてもよい。したがって、分散型コンピューティング環境２１６内のノードのネットワークを使用して、もののインターネット（ＩｏＴ）を実装してもよく、その場合、イベント駆動型アプリケーション１０４は、ＩｏＴアプリケーションを備えてもよい。例えば、図３は、ノード３１２、ノード３０８およびノード３２０（これらは、特定のノードセットまたはパーティションを構成してもよい）は、それぞれが各カメラ３２４、カメラ３２８およびカメラ３２６に関連付けられていることを示す。同様に、ノード３１６、ノード３１４およびノード３１０は、これらもやはりノード３１８とともに特定のパーティションを構成してもよく、各ＲＦＩＤタグ３３２、ＲＦＩＤタグ３３６およびＲＦＩＤタグ３３４に関連付けられている。

デプロイメントマネージャ３０４は、特定のノードまたはノードセットにイベント駆動型アプリケーション１０４の構成要素（またはアーチファクト）の設定（configurations）３３８をデプロイする。１つの設定は、１つのノードセットにデプロイするための構成要素のマニフェストを含む。設定３３８の各々は、対応するパーティション、および特定のパーティションにデプロイされるべきプロジェクトアーチファクトのセット（イベント駆動型アプリケーション１０４の構成要素を含む）を定義してもよい。一実施例において、パーティションは、特定の設定内で特定されるプロジェクトアーチファクトをデプロイするノードセットを論理的に表す。パーティションは、ターゲット環境（例えば、分散型コンピューティング環境２１６）内のノードセットから選択される、適格なノードの属性に対する設定の制約によって定義される。設定３３８は、（図４を参照して以下説明されるように）１つまたは複数のプロジェクト内に含まれてもよい。設定３３８のセットは、各それぞれのプロジェクト内で定義され、プロジェクトのアーチファクトをデプロイするべきパーティションのセットを定義する。

デプロイメントマネージャ３０４は、環境３４０を定義するためにも使用され、各環境は、特定の環境内に含まれるノードのリストからなる（例えば、分散型コンピューティング環境２１６内のノード３０２～ノード３２２）。プロジェクトがデプロイメントマネージャ３０４によって環境にデプロイされるとき、環境内の各ノードは、１つまたは複数のパーティション（例えば、ノードの論理セット）に割り当てられる。各パーティションにアサインされるプロジェクトアーチファクトは、さらに、対応するパーティションの適格なメンバーであるノードにデプロイされる。環境（例えば、分散型コンピューティング環境２１６）にアサインされるノードセットは、デプロイメントマネージャ３０４が実行している名前空間（namespace）内に定義されるノードのサブセットとしてもよいことにも留意されたい。

図３は、デプロイメントマネージャ３０４をデプロイメント３４２にも関連付けられるように示している。デプロイメント３４２の各々は、プロジェクトとそのプロジェクトで定義される環境との間のバインディング（binding）を定義する。デプロイメントアクションは、デプロイメント３４２の特定のデプロイメントをその引数として取り、関連付けられているプロジェクトを環境内にデプロイする。

デプロイメントパラメータを使用して、特定の環境内のデプロイメントについてプロジェクトアーチファクトをカスタマイズしてもよい。例えば、各パラメータがアーチファクトと、そのアーチファクトのプロパティとを特定してもよい。デプロイメント中、パラメータに関連する値が、当該アーチファクトの定義でそのプロパティのデフォルト値に取って代わる。

デプロイメントマネージャ
図４は、いくつかの例示的な実施形態によるデプロイメント環境４００のさらなる詳細を示すブロック図である。デプロイメント環境４００は、デプロイメントマネージャ３０４を含み、これは、プロジェクト（例えば、プロジェクト４０４、プロジェクト４０８およびプロジェクト４１２）のデプロイメントに集中することにより、開発者の開発タスクを簡素化するように作動する。

デプロイメントマネージャ３０４は、以下の機能を含め、多数の機能を行う。
・デフォルトパーティションの自動作成および各パーティションへ開発アーチファクトをアサインすること。
・ターゲット環境３４０で定義されるノードへパーティションを自動的にアサインすること。
・ユーザによる設定３３８、環境３４０およびデプロイメント３４２のカスタマイズを可能にすること。
・プロジェクトをデプロイし、デプロイメント作業のステータスを視覚化すること。
・ＣＬＩを介して、デプロイメント作業をスクリプトツールおよび自動化ツールに利用できるようにすること。

デプロイメントマネージャ３０４は開発者にグラフィカル環境４０２を与え、そこで開発者は、設定３３８、環境３４０（例えば、設定を管理するターゲット環境を定義するデータ構造）、環境３４０（例えば、プロジェクトの設定３３８がデプロイされるターゲット環境を定義するデータ構造）、およびデプロイメント３４２（例えば、プロジェクトの設定３３８と環境３４０との間のバインディング、およびデプロイメント作業を定義するデータ構造）を管理することができる。特定のプロジェクト（例えば、プロジェクト４０４）は、２以上の環境（例えば、デプロイメント環境４０６、テスト環境４１０および本番環境４１４）にデプロイされてもよく、そのため、複数のこのような環境のタイプにデプロイする必要性を満たす。

ここで、設定３３８、環境３４０およびデプロイメント３４２のそれぞれに関して、さらなる詳細を記載する。
設定（CONFIGURATIONS）
設定３３８は、設定の一部であるアーチファクトのマニフェストと、それがデプロイされるパーティションの定義とを含む。設定は、１つのパーティションとそのパーティションにアサインされるアーチファクトとを定義してもよい。プロジェクトは、１つまたは複数の設定を含んでもよく、各設定が一意のパーティションにデプロイされるアーチファクトを記述する。アーチファクトは、２以上の設定のメンバーとしてもよい。設定は、そのマニフェストに他の設定を含んでもよい。このような場合、子設定（child configuration）は、パーティションにデプロイされてもよく、さらにその後、子設定は、デプロイメントマネージャを使用して、ターゲットパーティションにアサインされるノードにデプロイされる。

設定３３８は、含んでいるプロジェクトのメンバーであるアーチファクトのみを含んでもよい。
設定３３８に含まれ、パーティションに配置されるアーチファクトは、以下のものを含む。
・ルール
・ソース
・タイプ
・プロシージャ
・トピック
・ビジュアルルール
・設定
・クライアント
・ＲＣＳ要求
・ＲＣＳペイロード
・協調タイプ
アプリケーションおよび協調は設定３３８に含まれるが、これらは、より根本的な、分割可能なルールおよびプロシージャから構成される。

環境
環境３４０の各々は、環境のメンバーであるノードセットを列挙する。ノードは、環境が定義されるプロジェクトのメンバーであってもよい。

環境３４０は、プロジェクト独立のコンピューティングトポロジを記述し、複数のプロジェクトを１つの環境にデプロイすることを可能にする。環境定義内のノードがパーティションにアサインされる必要はないことから、複数の設定およびプロジェクトにわたる環境３４０の再利用性をさらに改善する。

デプロイメント
デプロイメントは、プロジェクトを環境にデプロイする目的で、開発プロジェクトと環境との間のバインディングを特定する。デプロイメントに適用されるデプロイメント動作の結果は、プロジェクトの設定が環境内で定義されるノードにデプロイされるというアーチファクトである。

デプロイメントパラメータは、プロジェクトおよびその設定を、環境をまたいでポータブルにする（portable）。デプロイメントパラメータは、アーチファクト、そのアーチファクトのプロパティ、およびプロパティにアサインされる値を特定する。デプロイメント時、各デプロイメントパラメータ値は、特定されたアーチファクトのプロパティに代入され、アーチファクトのために当初設定されたデフォルト値に取って代わる。これにより、アーチファクトは、各環境に固有としてもよい物理的リソースにバインドすることが可能となる。

プロジェクト
具体的にプロジェクト（例えば、プロジェクト４０４、プロジェクト４０８、またはプロジェクト４１２）に移ると、各プロジェクトは、名前空間内で定義されるアーチファクトのサブセットを含む。したがって、プロジェクトは、デプロイ可能な機能性の単位を表し、これは、略式にはアプリケーションまたはサービスとして示されることがある。アプリケーションとサービスとの区別に関して、アプリケーションは、そのようなイベントストリームが外部システム（例えば、ＭＱＴＴキュー）によって発生されるか、またはユーザイベントを介してユーザによって発生されるかに関係なく、インバウンドイベントストリーム（inbound event stream）を作動的に受け入れてもよい。他方で、サービスは、ＲＥＳＴインターフェースを介して配信される、またはスクリプトによって直接呼び出されることにより配信される呼出し要求に応答する。サービスは、独立してデプロイされ、透明性をもって管理されるため、「マイクロサービス（micro-services）」と考えてもよい。図４に図示されるように、プロジェクトは、デプロイメントの単位でもあり、デプロイメントの結果は、インバウンド要求に対して実行するアクティブなアプリケーションまたはサービスとなる。

グラフィカル環境
上で述べたように、デプロイメントマネージャ３０４は、設定３３８（設定エディタ４１８構成要素を使用して）、環境３４０（環境エディタ４２０構成要素を使用して）、およびデプロイメント３４２（デプロイメントエディタ４２２構成要素を使用して）を視覚化および編集するためのグラフィカル環境４０２（またはビジュアルエディタ）を開発者に与える。

設定エディタ（configuration editor）４１８は、設定３３８／パーティションを、方形エリアが各設定／パーティションを表す描画パネルに視覚表示する。設定は、パーティションの宣言と考えることができるため、「設定（configuration）」または「パーティション（partition）」のいずれかの使用は、宣言またはその結果としてのパーティションのどちらを強調するかによって、同様に有効である。

各パーティションにアサインされるアーチファクトは、デプロイメントマネージャ３０４の一部を形成する分割システム４１６によってそれがアサインされるパーティション内に配置される。設定エディタ４１８内において、アーチファクトは、プロジェクトのリソースグラフにアーチファクトを表すために使用されるアイコンによって表現され、各アーチファクトアイコンは、そのアーチファクトがアサインされるパーティションを表すエリアに配置される。アーチファクトは、複数のパーティション（または設定３３８）にアサインしてもよいため、アーチファクトは、視覚化内で何度も表されてもよい。

開発者は、アーチファクトを追加することと、異なるパーティションに再アサインしてアーチファクトを設定から取り除くことと、の両方または一方によって、パーティション定義を編集してもよい。追加パーティションを作成することができ、アーチファクトをそれにアサインする。アーチファクトアサインは、分割システム４１６によって実施される正当性の制約を受ける。設定３３８を修正する行為は、分割システム４１６を起動して、開発者のアクションによって要求される任意の再アサインを完了させる。

環境エディタ４２０は、環境のメンバーであるノードを視覚表示する。ユーザは、任意のノードの詳細を見るためにドリルダウンし（drill down）てもよい。ある環境３４０が、非常に多数のノードを含むこともある。このような場合、すべてのノードを必ずしも図形に列挙する必要はなく、ノードの各クラスを、ノードのクラスのメンバーを定義する制約によって表す。

開発者は、これらの制約を使って、名前空間（例えば、仮想環境の抽象化）で定義され、特定の環境のメンバーとするべきノードを特定する。環境、ノードを特定するための制約をいくつもっていてもよい。ノードは、開発者によって個々に環境にアサインされてもよい。

環境の編集は、環境からノードを明確に追加する／取り除くことによって、または環境に含まれるべきノードセットを特定する制約を追加する／取り除く／修正することによって行ってもよい。メンバーシップを規定する制約を開発者が使用している場合、環境エディタ４２０は、各制約によって特定されるノードセットを開発者が見る仕組みを提供する。

環境内のノードの編集は、ノードにドリルダウンすることによって行ってもよい。ノードのプロパティに変更があれば、ノードを異なるノードクラスのメンバーになるようにしてもよい。

デプロイメントエディタ４２２は、デプロイメントで宣言されるバインディングに基づいて、ノードまたはノードクラスへのパーティションのアサインを視覚表示する。デプロイメント環境エディタ４２０は、各パーティションにアサインされたアーチファクト、およびデプロイメント内の各アーチファクトの定義を修正するデプロイメントパラメータの視覚化も可能にする。開発者は、アーチファクトを選択し、そのアーチファクトにバインドされる環境パラメータを変更することによって、デプロイメントパラメータを編集してもよい。アーチファクトが環境パラメータをサポートしていない場合、編集オプションは使用不可にされる。

図形で見える各ノードは、デプロイメントが進行中か、完了済みか、またはエラーを出したかを示すステータスを表示するため、開発者は、視覚化でデプロイメントのステータスを見ることもできる。開発者は、デプロイメント問題を診断するために、示されたエラーにドリルダウンしてもよい。

再び特に図４を参照すると、開発者（または開発チーム）は、デプロイメントマネージャ３０４を使用して、各ターゲット環境のプロジェクトを定義してもよい（これが今度はノードの集合体を含む）。例えば、プロジェクト４０４は開発環境４０６のために開発されてもよく、プロジェクト４０８はテスト環境４１０のために開発されてもよく、プロジェクト４１２は本番環境（production environment）４１４のために開発されてもよい。このように、デプロイメントマネージャ３０４は、イベント駆動型アプリケーションの複数のインスタンスの個別環境へのデプロイメントを促しながら、以下の課題に取組む。アプリケーションは、ターゲット環境（例えば、開発環境４０６、テスト環境４１０、および本番環境４１４）の各々内の異なる物理的リソースにバインドされてもよい。例えば、ターゲットノードは、すべて共通の論理パーティションに属してもよいが、本番ノード（production nodes）は、テストノードとは物理的に別のものとしてもよい。同様に、ソースは、異なる環境内の異なる物理的リソースにバインドされる。図４は、各設定ファイルとしての設定３３８が、分割システム４１６から各プロジェクトにデプロイされていることも示す。

図５および図６は、ターゲット環境への設定ファイルのデプロイメントに関する各シナリオを示す。特に図５を参照すると、デプロイメント環境５００において、ノード５０２上で動作するデプロイメントマネージャ３０４は、２つの設定ファイル、すなわち設定ファイル５２０および設定ファイル５２２を、ネットワーク５２４を介してターゲット環境５０４に出力する。設定ファイル５２０は、ノード５１０～ノード５１６を含むノードセット５０６の第１設定（またはパーティション）を定義する。設定ファイル５２２は、ノード５１６およびノード５１８を含むノードセット５０８の第２設定（またはパーティション）を定義する。したがって、特定のノードが複数のノードセット間で共有されてもよいことは認識されるであろう。例えば、ノード５１６は、ノードセット５０６およびノードセット５０８によって共有される。

ここで図６を参照すると、設定ファイル６１８によって表される特定の親設定（parent configuration）がそのマニフェスト内に他の子設定（例えば、設定ファイル６２０によって表される）を含む別のデプロイメント環境６００が示されている。図６は、親設定ファイル６１８が、ノード６０２上で実行する第１デプロイメントマネージャ３０４から、ネットワーク６２２を介してターゲット環境６０６にまでデプロイされていることを示す。ターゲット環境６０６は、ノードセット６１０およびノードセット６１４などの複数のノードセットを含む。親設定ファイル６１８を使用して、ノードセット６１４のノード６０４上の別の子デプロイメントマネージャ３０４をインスタンス化する。こうして、子デプロイメントマネージャ３０４は、子設定ファイル６２０によって表される子設定を、ノードセット６１２およびノードセット６１６などの別のノードセットを含む別のターゲット環境６０８にデプロイすることを担う。

図７は、いくつかの例示的な実施形態による、分割システム４１６に関するさらなる詳細を示す図表示である。具体的には、分割システム４１６は、いくつかのソースコードアナライザ７２０を含むように示されており、これがイベント駆動型アプリケーション１０４のソースコードを作動的に分析して、イベント駆動型アプリケーション１０４の構成要素間の関係を推定するとともに、さらに当該構成要素によりリモート参照（remote references）を検出する。ソースコードアナライザ７２０によって行われるようなソースコード分析に関するさらなる詳細を以下に述べる。

イベント駆動型アプリケーション１０４を考えると、当該アプリケーションは、イベント駆動型アプリケーション１０４がデプロイされる分散型コンピューティング環境２１６内のイベントの報告に応答して実行される。このような各イベントは、イベント駆動型アプリケーション１０４にとって関心のある作業の完了を示してもよい。イベントは、通信ネットワーク７２２により多様なソースから特定のイベント駆動型アプリケーション１０４に到着し、例えば、分散型コンピューティング環境２１６内のセンサからの値の読み取りから、イベント駆動型アプリケーション１０４のユーザオペレータによる新たな戦略的イニシアティブ（strategic initiative）の特定まで多岐にわたってもよい。

図７は、イベント駆動型アプリケーション１０４が多数の専用構成要素を含んでもよいことを示しており、主な構成要素クラスには、以下のものが含まれる。
・イベント構成要素７０４
・ソース構成要素７０６
・ルール構成要素７０８
・プロシージャ構成要素７１０、および
・タイプ構成要素７１２。

イベント駆動型アプリケーション１０４は、イベント駆動型アプリケーション１０４の構成要素の各々が分散型コンピューティング環境２１６内の１つまたは複数の計算ノード（例えば、ノード７１４、ノード７１６、またはノード７１８）に位置決めされるように、分散型コンピューティング環境２１６内で動作してもよい。

ノード７１４～ノード７１８として計算ノードのセットを含む分散型コンピューティング環境２１６が図７に示されており、各ノードは、コードを実行し、データを格納し、通信ネットワーク７２２経由で他の計算ノードと通信することのできる計算リソースを表す。計算ノードは、パブリッククラウド、プライベートクラウド、データセンターまたはエッジ環境でホストされてもよい。さらに、計算ノードは一意のアドレスを有し、それを使用して他の計算ノードは当該計算ノードと通信することができる。イベント駆動型アプリケーション１０４は、イベント駆動型アプリケーション１０４の構成要素を１つまたは複数の利用できる計算ノードに割り当てることにより、分散型コンピューティング環境２１６内で実行するので、実行は、分散型コンピューティング環境２１６内に参加する計算ノードの協調的アクションにより進行する。

図８は、図７に図示するルールシステム８００の図表示であり、設定ファイルと７０２として設定を作動的に出力し、それに従いイベント駆動型アプリケーション１０４の様々な構成要素が分散型コンピューティング環境２１６内の計算ノードにデプロイされる。具体的には、ルールシステム８００は、イベント駆動型アプリケーション１０４のソースコードを分析してノードセットのアサインを決定するために適用されるルールセットを含む。ノードセットの特定およびこれらのノードセットへのイベント駆動型アプリケーション１０４の構成要素のアサインを、さらに詳細に以下で説明する。

図８に図示するように、ルールシステム８００は、アプリケーション構成要素がアサインされるノードセットとして知られる、計算リソースの抽象集合を定義する多数のルールセットを含む。ルールシステム８００および関連ルールセットは、アサインルールを分析対象のコードに適用して、ノードセットのアサインを決定する。ルールシステム８００は、アサインルールを特定のイベントベースのアプリケーションの特化したニーズに対応するように拡大するためのスキーマも含む。

ルールシステム８００は、大別して３つのカテゴリのルール、すなわち、一般ルール８０２、構成要素タイプ固有ルール８０６、およびカスタムルール８０４を含む。ルールシステム８００は、これらの３つのカテゴリのルールを適用して、イベント駆動型アプリケーション１０４の構成要素をノードセットにアサインする。これは、すべての構成要素タイプに広く適用できる一般ルール８０２を再帰的に適用し、次いで１つの構成要素タイプに適用できる構成要素タイプ固有ルール８０６を適用し、さらにその後にカスタムルール８０４を適用して行われる。

構成要素タイプ固有ルール８０６は、イベント８０８、ルール８１０、タイプ８１２、プロシージャ８１４およびソース８１６を含む。これらのルールの適用に関するさらなる詳細を、図９を参照して以下に述べる。

図９は、いくつかの例示的な実施形態による、分散型コンピューティング環境２１６内でイベント駆動型アプリケーション１０４を分割、デプロイおよび実行する方法９００を示すフローチャートである。

方法９００と対照的に、分散型のイベントベースのアプリケーションの構築のための一定の方法およびツールは、明確なプログラマのアクションを介して、計算ノードへの構成要素の手動アサインを必要としうる。このようなアサイン作業は、労働集約的で、間違いやすく、多くの場合、計算ノードへのアプリケーション構成要素の最適ではない割当てになる。このようなアサインを自動化するための一定の努力は、オブジェクトの特定に集中しており、これはその後、ノード間の分散型通信の基礎として特定の計算ノードに手動でアサインされるが、各ノードへの追加構成要素の最適な割当てへの集中は限られる。

方法９００は、いくつかの例示的な実施形態において、分散型コンピューティング環境２１６の各計算ノードにアサインすることのできる最小コードを正確に決定するためにデプロイされてもよい。このために、方法９００は、プログラミング指令が実行されるべき計算ノードのクラスを指定するためのプログラミングディレクティブ（programming directive）を利用してもよい。

高レベルでは、方法９００は、ノードセットに（および、推定により各ノードセットにアサインされる計算ノードに）イベント駆動型アプリケーション１０４の構成要素を自動的に割り当てるための分割プロセス９２０と、その後のイベント駆動型アプリケーション１０４のデプロイメントプロセス（動作９１４）と、イベント駆動型アプリケーション１０４の実行プロセス（動作９１６）とを含む。分割プロセス９２０は、プログラミングディレクティブを利用して、プログラミング指令が実行されるべき計算ノードのクラスを指定する。

プログラミング記法（PROGRAMMING NOTATION）
分割システム４１６で行われるような分割プロセス９２０は、いくつかの例示的な実施形態において、イベント駆動型アプリケーション１０４の構成要素が分散型コンピューティング環境２１６内のノードに割り当てられる記法に基づくので、イベント駆動型アプリケーション１０４の正当性を確保するとともに、イベント駆動型アプリケーション１０４のパフォーマンスおよび可用性を最適化する。しかし、アプリケーション開発プロセス中に特定のノードにアサインすることは難しい。その理由は、開発者が、アプリケーション開発中にはターゲット分散型コンピューティング環境２１６の最終的なトポロジの抽象観（abstract view）しかもたないことがあるからである。この技術的な課題に対処するため、分割プロセス９２０および分割システム４１６は、いくつかの例示的な実施形態では、特定のノードセットに関連付けられているプロパティを示す１つまたは複数のノードを表すノードセットを特定することにより、分散型コンピューティング技術の抽象モデルを定義する。開発者が、冷蔵ユニットに関連付けられる計算リソース（例えば、計算ノード）がＩｏＴアプリケーション内に存在することはわかっているが、多数の当該ノート（a number of such notes）、そのロケーションおよびアイデンティティ（identities）は、デプロイメントプロセス（動作９１４）の後半まで、さらにイベント駆動型アプリケーション１０４の構成要素の計算リソースへの割当てが完了してからずっと後になるまで不明なままである場合の例を考えてみる。いくつかの例示的な実施形態による分割システム４１６および分割プロセス９２０は、宣言型モデルをサポートすることによりこれらのアサインを抽象化し、そこで開発者は、計算リソースが満たさなければならない論理的な制約を指定することにより、構成要素への参照を指定する。論理的な制約は、その後でノードセットとして正式なものとされ、これは、最終デプロイメントトポロジに１つまたは複数のノードを含んでもよい。冷蔵ユニットの例に戻ると、冷蔵ユニットに関連付けられる計算リソースは、例えば、処理制約によって以下のように指定してもよい。

管理対象機器による処理＝＝「冷蔵」
アプリケーション分析
特に分割プロセス９２０を参照すると、動作１０００で、ソースコードアナライザ７２０は、検出および構成要素アサイン作業のノードセットの準備のために、イベント駆動型アプリケーション１０４を分析する。

図１０は、ソースコードアナライザ７２０がアプリケーションのソースコードを分析するために行う動作１０００のさらなる下位動作を示すフローチャートである。具体的には、動作１０００は、動作１００２から始まり、ここでソースコードアナライザ７２０が特定のイベント駆動型アプリケーション１０４のソースコードにアクセスする。

動作１００４で、ソースコードアナライザ７２０は、アプリケーションのソースコード内で、リモート参照を含むステートメントを特定し、その後、動作１００６で、ソースコードアナライザ７２０は、当該ステートメントで参照される構成要素を特定する。

動作１００８で、ソースコードアナライザ７２０は、参照される構成要素をポストするために必要な計算リソースのクラスに対し、論理的な計算リソース制約を決定する。
決定動作１０１０で、ソースコードアナライザ７２０は、アプリケーションのソースコード内に、リモート参照を含む別のステートメントがあるかどうかを判定する。あれば、動作１０００は動作１００４に戻る。他方で、決定動作１０１０で、プロセスへのリモート参照を含む別のステートメントがないと判定されれば、動作１０００は動作１０１２に進み、ソースコードアナライザ７２０は、イベント駆動型アプリケーションの構成要素間の依存関係を特定するように作動する。

動作１０１４で、ソースコードアナライザ７２０は、次いで、分析メタデータを生成し、これを使用して分割プロセス９２０の別の動作を駆動する。
図９に戻ると、動作９０２で、分割システム４１６のソースコードアナライザ７２０はノードセットの特定に進む。

イベントメッシュブローカー（EVENT MESH BROKER）
図１１は、分散型コンピューティング環境１１００の図表示であり、イベントプロデューサ１１０２、メッシュイベントブローカー１２００、ローカルイベントコンシューマ（local event consumers）１１０４、イベントコンソリデーター（event consolidators）１１０８、および外部イベントコンシューマ１１０６を含む。メッシュエージェント（例えば、メッシュエージェント１１１２～メッシュエージェント１１２０）は、乱れた分散型コンピューティング環境１１００とともにこれらのプロデューサおよびコンシューマ構成要素のそれぞれに関連付けられていて、これらの隣に常駐する。メッシュエージェントは、メッシュイベントブローカー１２００の実装を担い、したがって、図１１に図示されるように、概念的にはメッシュイベントブローカー１２００の一部として考えられるはずである。このように、各メッシュエージェントは、事実上独立型イベントブローカーとして機能しても、またはメッシュイベントブローカー１２００をともに構成するエージェントの集合体の一部として機能してもよい。

協働するメッシュエージェント（例えば、メッシュエージェント１１１２～メッシュエージェント１１２０）の集合体は、「メディエータ（mediator）」（例えば、メディエーション層（mediation layers）１１１０）として動作し、直接の２点間通信をサポートするメッシュネットワークを形成する。協働する各メッシュエージェントは、拡張をサポートし、サポート対象の発行者によって発行されるイベントへのプロデューサ（例えば、発行者）およびコンシューマ（例えば、サブスクライバ）の特定のセットの配信をするためにプロビジョニングされる。同様に、サブスクライバは、それらがローカルサブスクライバであるイベントを拡張および配信するためにメッシュエージェントによってプロビジョニングされてもよい。さらにまた、協働するメッシュエージェントは、メッシュとして、メッセージをメッシュに転送して、イベント伝送の効率を改善し、異なるネットワーク上で構成されるエージェント間の橋渡しをすることができる。

イベントコンソリデーター１１０８は、プロデューサおよびコンシューマが異なるネットワーク上にいるか、またはファイヤウォール（例えば、ファイヤウォール１１２２）によって隔離されているとき、蓄積交換式コンテナ（store-and-forward containers）として機能する。したがって、イベントコンソリデーター１１０８は、第１ネットワークまたはドメイン上のイベントプロデューサ１１０２がイベント通知をローカルイベントコンシューマ１１０４および外部イベントコンシューマ１１０６の両方に伝送するのを可能にすることができ、外部イベントコンシューマ１１０６は、イベントプロデューサ１１０２とは異なるネットワークまたはドメイン上に存在する。

いくつかの例示的な実施形態によるメッシュイベントブローカー１２００は、イベント駆動型で分散型コンピューティング環境１１００のコンテキスト内で、イベントプロデューサ１１０２とローカルイベントコンシューマ１１０４（および遠隔外部イベントコンシューマ１１０６）との対話を可能にし、エンリッチ化する。メッシュイベントブローカー１２００（各メッシュエージェントを含む）は、イベント通知を介して、イベントプロデューサ１１０２からローカルイベントコンシューマ１１０４へのイベントの配信の管理を主に担う。メッシュイベントブローカー１２００は、メッセージ指向のミドルウェアとは対照的に、例えば、リアルタイムのデジタルビジネスで直面するリアルタイムのインテリジェンスおよび状況認識のバインディング要求をサポートするように設計される。このような要求は、例えば、変換、フィルタリング、相関付け、コンテキスト化および分析などの高度なメディエーション作業を、メッシュイベントブローカー１２００に流れるイベントトラフィックに適用するために、複数のメディエーション層１１１０の使用を必要としうる。

図３を参照して上で説明したような分散型コンピューティング環境１１００は、計算ノードのセットからなってもよく、その各々がイベントプロデューサ１１０２またはローカルイベントコンシューマ１１０４のいずれか一方（または両方）をホストし、またはそのように動作してもよい。すると、イベントプロデューサ１１０２またはローカルイベントコンシューマ１１０４は、アプリケーションまたはアプリケーション構成要素としてもよいかもしれない。各ノードは、コードを実行し、データを格納し、通信ネットワークで他のノードと通信することのできる計算リソースを表す。計算ノードは、さらに、パブリッククラウド、データセンターまたはエッジ環境でホストされてもよい。計算ノードは、他の計算ノードが当該ノードと通信することのできる一意のアドレスを有する。

イベント駆動型アプリケーションは、イベント駆動型アプリケーションの構成要素を利用できる計算ノードのうちの１つまたは複数に割り当てることによって、分散型コンピューティング環境１１００で実行してもよいため、実行は、参加する計算ノードの協調的アクションにより進行する。

いくつかの例示的な実施形態によると、完全なまたは部分的なメッシュネットワークとして組織されるノードにメッシュイベントブローカーのメディエーション責任（mediation responsibilities）を分散するメッシュイベントブローカーアーキテクチャが提供される。具体的には、メディエーション責任は、少なくとも部分的にまたは完全にメッシュイベントブローカー１２００を構成するメッシュエージェント間に分散してもよい。アーキテクチャは、さらに、メッシュネットワークの任意の２つのノード間のイベント通知の伝送に関連するコストの動的データベースを管理する。このために、メッシュイベントブローカーアーキテクチャは、イベントプロデューサとイベントコンシューマとの間の取引コスト、およびメッシュネットワーク内のノードの可用性を最小化することによって、メッシュネットワークにおける配信ルートを動的に選択する。

メッシュイベントブローカーアーキテクチャは、さらに、各イベントに適用される変換、フィルタリング、相関付け、コンテキスト化および分析を、分散型コンピューティング環境内の最適なノード（例えば、メッシュエージェント）に分散する。最後に、イベントブローカーアーキテクチャは、要求の認証を求め、各要求に役割ベースのアクセス制御を適用する。したがって、いくつかの例示的な実施形態において、メッシュイベントブローカーアーキテクチャは、分散型トポロジの高度なイベントブローカーに必要な機能性を提供し、それが、集中化されたメディエータを、メッシュネットワークを通して実装される分散型メディエータに置き換える働きをする。

メッシュイベントブローカー１２００は、開発しやすい分散型イベント管理のための高生産性ツールを、動的なメッシュデプロイメントと組み合わせる。メッシュイベントブローカー１２００は、イベント駆動型システムの継続的な認識、インテリジェンスおよびアジリティ（agility）のサポートを図り、どこからでも（例えば、ＩｏＴ、モバイルデバイス、レガシーシステム）イベントを受け入れることによって、エンタープライズ／ビジネス業務の絶え間ない監視を可能にする。メッシュイベントブローカー１２００は、さらに、イベントをリアルタイムで分析し、組合せ、導出して、サブスクライブする（subscribing）アプリケーション／アプリケーション構成要素にイベントを送信し、したがって包括的な状況認識を可能にする。

図１２は、いくつかの例示的な実施形態による、メッシュイベントブローカー１２００のアーキテクチャの図表示である。メッシュイベントブローカー１２００は、メッシュとして（例えば、完全なメッシュネットワークまたは部分的なメッシュネットワーク内に）デプロイされる完全な分散型メディエータとして実装されてもよい。

メッシュイベントブローカー１２００は、接続性カタログ（connectivity catalog）１２０２を維持するように作動し、これは、メッシュイベントブローカー１２００が実装されるメッシュネットワークを通じたイベント通知の動的ルーティングを最適化するために使用されるノード間接続性コストのカタログである。このために、接続性カタログ１２０２は、ノードペア間でのイベント通知の伝送に関連するコストを記録して格納してもよく、これらのコストは、数値として符号化され、最小コスト経路がより小さい数の値を有し、より高いコスト経路は、より大きい数の値を有する。特殊なケースは、メッシュネットワークに参加するノードが互いに接続性をもたないものである。このような場合、接続性カタログ１２０２内に記録されるコストは、直接接続されるノードペアに関連付けることのできるどのコストよりも大きい値に設定される。また、接続性カタログ１２０２は、現在利用できない任意のノードに関する記録（またはデータ）を接続性カタログ１２０２から削除して、これらがルーティングルール１２０６（以下に述べる）によって考慮されないようにすることによって維持されてもよい。

メッシュイベントブローカー１２００は、接続性カタログ１２０２を動的に維持するようにも作動し、当該接続性カタログ１２０２は、イベント（例えば、イベント通知によって表されるもの）、各イベントのイベントプロデューサ１１０２、および各イベントのローカルイベントコンシューマ１１０４のリストを含む。プロデューサ／コンシューマカタログ１２０４は、拡張のリスト（例えば、変換、フィルタ、相関付け、コンテキスト化および分析）も維持し、これを、イベントプロデューサ１１０２またはローカルイベントコンシューマ１１０４のいずれかが各イベントに適用してもよい。プロデューサ／コンシューマカタログ１２０４は、各イベントの一意の名称、アイデンティティ、イベントのイベントプロデューサ１１０２各々のロケーション、およびイベントの各ローカルイベントコンシューマ１１０４のロケーションも維持する。ロケーションは、分散型コンピューティング環境のメッシュネットワーク内におけるイベントプロデューサ１１０２の各々とローカルイベントコンシューマ１１０４の各々とに関連付けられているノードの名称として指定される。

メッシュイベントブローカー１２００は、１つまたは複数のイベントプロデューサ１１０２から１つまたは複数のローカルイベントコンシューマ１１０４へのイベント通知の配信に最適な経路を動的に決定するルーティングルール１２０６をさらに含む。図１１に関して述べたように、イベント通知で表されるイベントは、イベントプロデューサ１１０２からメディエーション層１１１０によって提供される拡張を通じて（through augmentations）、ローカルイベントコンシューマ１１０４にルーティングされる。メッシュイベントブローカー１２００は、ルーティングルール１２０６を使用して、イベントプロデューサ・イベントコンシューマの各ペアについて、メッシュネットワークを通る最適な経路を計算して決定する。例示的なルーティングルール１２０６の使用に関するさらなる詳細を、図１３を参照して以下に記載する。

メッシュイベントブローカー１２００は、拡張プロビジョニングルール（augmentation provisioning rules）１２０８をさらに含み、これを使用して、イベントプロデューサ１１０２からローカルイベントコンシューマ１１０４に流れるイベントに対して拡張（例えば、変換、フィルタリング、コンテキスト化、分析など）を行うために、メッシュネットワーク内の最適なロケーションを動的に決定する。別の言い方をすると、メッシュネットワークを通る経路を特定してしまえば、拡張は、その特定された経路に沿って、メッシュネットワークのノードにアサインされる。拡張ルールに関するさらなる詳細を、図１５を参照して以下に述べる。

メッシュイベントブローカー１２００は、イベントブローカーコード生成器１２１０と、ブローカープロビジョニングモジュール１２１２とをさらに含む。イベントブローカーコード生成器１２１０は、各特定のイベントについて、イベントプロデューサ１１０２およびローカルイベントコンシューマ１１０４のセマンティクス（semantics）を実施するために必要な拡張およびルーティングを実施するルールセットを動的に生成するように作動する。より具体的には、プロビジョニングは、イベントメッシュマップをもたらしてもよく、メッシュネットワークイベントプロデューサ１１０２内で、メディエーション層１１１０、コンソリデーター（consolidators）および拡張が位置するべき場所を示す。イベント情報マップに基づいて、イベントブローカーコード生成器１２１０は、メッシュネットワークの各ノードがイベントプロデューサ１１０２、メディエーション層１１１０、コンソリデーター、および拡張のセマンティクスを実施するために必要な命令を生成する。生成されたコードは、これらのルールをプロビジョニングするべきノードのアイデンティティの註釈が付けられた（annotated with the identities）ルールのセットである。

ブローカープロビジョニングモジュール１２１２は、イベントブローカーコード生成器１２１０によって発生されるルールセットを、ルーティングルール１２０６と拡張プロビジョニングルール１２０８とを使用して特定されるノードに動的にデプロイするように作動する。具体的には、コード（例えば、ルールセット）がイベントブローカーコード生成器１２１０によって生成されたら、コードは、メッシュネットワークにプロビジョニングされなければならない。ブローカープロビジョニングモジュール１２１２は、各ノードについて、そのノードにプロビジョニングしなければならないルールセットと、ルールをサポートするために必要な任意のさらなるリソースとを含む設定を作成することによって、この機能を果たす。それから、設定（例えば、設定ファイル）をデプロイメントマネージャに提示して、それが、今度は、設定されたリソースを各ノードに送信し、ルールをインストールしてこれらのルールを実行する準備をするようローカルノードに指示する。

図１２を参照して上で述べたように、イベント通知で表されるイベントは、イベントプロデューサからイベントコンシューマ（例えば、イベントサブスクライバ）にルーティングされる。ここまでで、メッシュイベントブローカー１２００は、ルーティングルール１２０６を使用して、関連イベントの各プロデューサから各コンシューマへの、イベント通知の最適な経路を判定して選択する。図１２は、ルーティングルールがイベントルータ１２１４によって実施されていることを示しており、これもメッシュイベントブローカー１２００の一部を形成する。

イベントルータ１２１４がイベントプロデューサおよびイベントコンシューマの各々についてルーティングルール１２０６を実施する別の方法に移って、まず、イベントプロデューサを考える。イベントルータ１２１４は、各イベントプロデューサを評価し、プロデューサ／コンシューマカタログ１２０４で検索を行ってイベントメッシュ内で関連イベントプロデューサを突き止めて、プロデューサが常駐するメッシュネットワーク内のノードを特定する。

各イベントコンシューマについて、イベントルータ１２１４で実施されるルーティングルール１２０６の実施を、以下、図１３～図１７を参照して説明する。
図１３は、いくつかの例示的な実施形態による、分散型コンピューティング環境内で各イベントコンシューマについてルーティングルール１２０６を実施するために、イベントルータ１２１４によって行われる方法１３００を示すフローチャートである。方法１３００は動作１３０２から始まり、イベントルータ１２１４がプロデューサ／コンシューマカタログ１２０４内の関連サブスクライバを検索して、関連サブスクライバが常駐する分散型コンピューティング環境内のノードを決定することにより、イベントメッシュ内で、評価対象のコンシューマに関連付けられているサブスクライバを突き止める。

動作１３０４で、イベントルータ１２１４は、接続性カタログ１２０２で検索を行うことによってプロデューサ・コンシューマペアを決定し、さらに、関連プロデューサから評価対象のコンシューマに直接イベント通知をルーティングする割当てコストを探索して決定する。

決定動作１３０６で、イベントルータ１２１４は、イベント通知を関連プロデューサから評価対象のコンシューマに直接ルーティングするコストが、設定可能な閾値を逸脱する（例えば、現在適用可能な閾値を上回る）かどうかを判定する。決定動作１３０６で直接ルーティングコストが受け入れ可能である（例えば、設定可能な閾値を下回る）と評価される場合、方法１３００は動作１３０８に進んで、イベントルータ１２１４は各イベント通知を直接ルーティングする決定をし、動作１３１０でルーティングデータを更新して出力する。

他方で、決定動作１３０６で、直接ルーティングコストが受け入れられない（例えば、設定可能な閾値を上回る）とイベントルータ１２１４が判定する場合、イベントルータ１２１４は、決定動作１３１２に進むことによって、代わりの間接経路の決定へと進む。

決定動作１３１２で、イベントルータ１２１４は、直接ルーティングコストが別の最大値閾値を逸脱するかどうかを評価する。関連プロデューサとコンシューマとの間の直接ルーティングコストが、実際に、最大閾値を逸脱する（例えば、最大閾値を超える）という決定動作１３１２での判定に基づいて、プロデューサとコンシューマとは直接接続されないこと、およびメッシュネットワークを通る中間経路を決定するべきだと評価される。したがって、決定動作１３１２での肯定判定の後、方法１３００は動作１４００に進み、イベントルータ１２１４は、図１４を参照して説明するように、中間経路を決定するように作動する。

他方で、決定動作１３１２で、イベントルータ１２１４により、直接ルーティングコストが閾値を逸脱すると判定される（決定動作１３０６）が最大閾値は逸脱しないと判断される（決定動作１３１２）場合、中間ノードを通る、よりコスト効率の高い経路があるかの判定（または評価）がイベントルータ１２１４によって自動的に行われる。したがって、決定動作１３１２での否定判定に基づいて、方法１３００は動作１５００に進み、イベントルータ１２１４は、このようなよりコスト効率の高い経路が存在するかどうかを評価する。動作１５００の下位動作を、図１５を参照して説明する。

動作１４００または動作１５００の完了時、方法１３００は、次いでもう一度動作１３１０に進み、イベントルータ１２１４によりルーティングデータを出力する。
図１４は、プロデューサからコンシューマへの（決定動作１３１２で直接接続されないと評価される）中間経路を決定するための動作１４００の下位動作を示すフローチャートである。

動作１４００は動作１４０２から始まり、プロデューサ・コンシューマペアのコンシューマおよび発行者の各々に直接接続されるノードセットの自動判定と特定を行う。
決定動作１４０４で、イベントルータ１２１４は、コンシューマおよびプロデューサの両方に直接接続している中間ノードが存在するかどうかを判定する。存在すれば、決定動作１４０４での肯定判定後、動作１４０８で、イベントルータ１２１４は、プロデューサから中間ノードへ、および中間ノードからコンシューマへのイベント通知の伝送の接続性コストが、接続性カタログ１２０２に反映されるコスト情報に基づいて最低コストになるノード（またはノードセット）を選択する。

他方で、イベントルータ１２１４が決定動作１４０４で、イベントプロデューサおよびイベントコンシューマの両方に直接接続している単一の中間ノードが存在しないと判定する場合、イベントルータ１２１４は、イベントプロデューサおよびイベントコンシューマの両方を接続している中間ノードの最小セットの探索を開始する。この探索は動作１４０６で始まり、中間ノードのセットの展開（expansion）が評価される（例えば、Ｎ＝２）。

イベントプロデューサとイベントコンシューマとの間を接続していて、評価される必要がある中間ノードのセットが複数存在しうることは認識されるであろう。決定動作１４１０で、イベントルータ１２１４は、プロデューサとコンシューマとに接続している当該ノードセットのすべてを特定する。決定動作１４１０でイベントルータ１２１４が否定判定を行う場合（例えば、プロデューサとコンシューマとに接続している２以上のノードの中間ノードセットが存在しない）、動作１４００は動作１４１２に進み、イベントルータ１２１４はＮの値を（例えば、３に）増やして、決定動作１４１０に戻る。

動作１４００は続いて、決定動作１４１０で肯定判定が行われるまで（すなわち、Ｎ個のノードの中から、関連プロデューサとコンシューマとに接続している１つまたは複数のノードセットが特定される）、決定動作１４１０と動作１４１２との間を繰り返す。決定動作１４１０での肯定判定後、動作１４００は動作１４０８に戻り、イベントルータ１２１４は、決定動作１４１０で決定されたノードセットから、関連イベントプロデューサとコンシューマとの間でイベント通知を伝送するコストが最小のノードセットを選択する。したがって、動作１４００は、決定動作１４１０で、解が見つかるまで中間ノードのセットに追加ノードを１つ加えながら、ノードセットの評価を続ける。ネットワークはメッシュであるため、動作１４００によって解が必ず出され、評価されるプロデューサ・コンシューマペア間に少なくとも１つの経路が存在することになることに留意されたい。

図１５は、いくつかの例示的な実施形態による、直接ルーティングコストが設定可能な閾値を上回る（決定動作１３０６）が、最大コスト値を下回る（決定動作１３１２）場合、イベントプロデューサとイベントコンシューマとの間の最もコスト効率の高い経路を決定するための動作１５００の様々な下位動作を示すフローチャートである。

直接経路は、ほぼ必ず、１つのプロデューサ・コンシューマペア間におけるイベント通知の伝送のコストが最も低くなる。しかし、一定の例示的なシナリオでは、イベントプロデューサが、イベント通知によって、高コスト経路で複数のサブスクライバにイベントを配信することがある。このような場合、イベントプロデューサと中間ノードとの間で高コストが一旦支払われ（paid）てもよく、中間ノードとメッシュネットワーク内のイベントのいくつかのコンシューマとの間で低コスト通信が利用できてもよい。この場合、ルーティングは動作１５００に従い判定することができ、これを、図１５を参照して説明する。

動作１５００はコンソリデーターを参照し、これは、１つまたは複数のイベントコンシューマへのイベント通知を作動的に集約するように動作する中間ノードとしてもよい。
動作１５００は決定動作１５０２で始まり、イベントルータ１２１４がイベントコンシューマとの低コストリンクを有し、イベントにサブスクライブされるコンソリデーター（例えば、中間ノード）が存在するかどうかを判定する。存在する場合、決定動作１５０２での肯定判定後、動作１５０４で、サブスクライブされるコンソリデーターがイベントルータ１２１４によってプロビジョニングされて、関連イベントをイベントコンシューマに転送する。

他方で、決定動作１５０２でのイベントルータ１２１４による否定判定後（すなわち、そのようなコンソリデーターが存在しない）、動作１５００は動作１５０６に進む。
動作１５０６で、関連イベントにサブスクライブされるコンシューマのセットを、イベントルータ１２１４がプロデューサ／コンシューマカタログ１２０４を探索して取得する。さらに、動作１５０６で、特定されたコンシューマセットを検査（または評価）して、メッシュネットワークのコンテキスト内で、現在評価されているコンシューマ（すなわち、評価対象のコンシューマＮ）に近いイベントコンシューマを特定する。決定動作１５０８で、イベントにサブスクライブされる各コンシューマを評価してもよい。具体的には、動作１５０６で特定されたセット内の各コンシューマを、決定動作１５０８で評価して、評価対象のコンシューマＮとの接続性コストの低い（例えば、コスト閾値を下回る）少なくとも１つの追加コンシューマがいるかどうかを判定し、この低コストコンシューマのセットが低コストコンシューマセットとして指定される。

動作１５１２で、イベントルータ１２１４は、次いで、低コストコンシューマセットを評価対象のコンシューマＮと組み合わせることによってコンシューマコホート（consumer cohort）を作成する。

動作１５１４で、動作１５１２で作成されたコンシューマコホートに対し最もコストの低い接続性を有するノードを、コンシューマコホート内のコンシューマすべてと通信するコストを合計し、コストの最も低い接続性を有するノードを選択することにより特定する。

決定動作１５１６で、動作１５１４で選択された低コストノードにコンソリデーターがすでに存在しているかどうかに関して、イベントルータ１２１４が判定を行う。決定動作１５１６から、動作１５００は、コネクタ（connector）１５１８およびコネクタ１５２０を介して、図１６に反映されるさらなる動作に進む。

具体的には、決定動作１５１６での肯定判定後、動作１５００は動作１６０２に進み、イベントルータ１２１４が評価対象イベントのコンソリデーターとして選択されたノードを特定する。

他方で、決定動作１５１６での否定判定後、動作１５００は動作１６１０に進み、評価対象のイベントについて、選択されたノードに対してコンソリデーターがプロビジョニングされる。

動作１６０２の完了後、または動作１６１０の後、動作１５００は動作１６０４に進み、イベントルータ１２１４は、続いてプロデューサ／コンシューマ接続性カタログ１２０２を更新し、イベントプロデューサとイベントコンシューマとに対するコンソリデーターの関係を記録する。

動作１６０６で、関連イベントプロデューサは、次いで、イベント通知を介して、イベントをコンソリデーターに配信するためにプロビジョニングされる。同様に、動作１６０８で、コンソリデーターが、イベント通知を介して、イベントをコンシューマコホートのメンバーに配信するためにプロビジョニングされる。

サブスクリプションが解除されると、プロデューサ／コンシューマカタログ１２０４が更新されることに留意するべきである。しかしコンソリデーターは、このようなサブスクリプションの解除に応答してプロデューサ／コンシューマカタログ１２０４から除去されないので、他のイベントおよび他のサブスクリプションにサービスするのに利用できる状態でコンソリデーターを維持する。上で説明した動作１５００は、イベントメッシュネットワークを使用して、プロデューサおよびコンシューマの総計セットの通信コストが最小になる。

経路が特定されたら、その経路に沿ったノードに拡張（augmentations）がアサインされる（図１７）。方法１７００は、拡張にロケーション依存関係の註釈を付けられていない限り、すべてのノードがすべての拡張を実装できると仮定する。
１．ロケーション制約を有する拡張をプロデューサが有する場合、拡張は、指定されるノードにアサインされる。
２．ロケーション制約のない関連付けられる拡張をプロデューサが有する場合、それが特定されて、プロデューサが常駐するノードにアサインされる。
３．ロケーション制約を有する拡張をサブスクライバが有する場合、拡張は、指定されるノードにアサインされる。
４．関連付けられている拡張をサブスクライバが有する場合、それが特定されて、サブスクライバが常駐する同じノードにアサインされる。

図１８は、いくつかの例示的な実施形態による、メッシュイベントブローカー１２００の動作に関するさらなる詳細を示す図表示である。
図１９は、本明細書で説明するデバイスの任意の１つまたは複数にインストールすることのできるソフトウェアアーキテクチャ１９０４を示すブロック図１９００である。ソフトウェアアーキテクチャ１９０４は、プロセッサ１９２０、メモリ１９２６およびＩ／Ｏ構成要素１９３８を含む機械１９０２などのハードウェアによってサポートされる。この実施例では、ソフトウェアアーキテクチャ１９０４は、層のスタックとして概念化することができ、各層が特定の機能性を提供する。ソフトウェアアーキテクチャ１９０４は、オペレーティングシステム１９１２、ライブラリ１９１０、フレームワーク１９０８、およびアプリケーション１９０６などの層を含む。作動上、アプリケーション１９０６は、ソフトウェアスタックを通してＡＰＩコール１９５０を呼び出し、ＡＰＩコール１９５０に応答してメッセージ１９５２を受信する。

オペレーティングシステム１９１２は、ハードウェアリソースを管理し、共通のサービスを提供する。オペレーティングシステム１９１２は、例えば、カーネル１９１４、サービス１９１６およびドライバ１９２２を含む。カーネル１９１４は、ハードウェアと他のソフトウェア層との間の抽象化層として機能する。例えば、カーネル１９１４は、特に、メモリ管理、プロセッサ管理（例えば、スケジューリング）、構成要素管理、ネットワーキングおよびセキュリティ設定の機能性を提供する。サービス１９１６は、他のソフトウェア層に他の共通のサービスを提供することができる。ドライバ１９２２は、基盤となるハードウェアの制御またはそれとのインターフェース接続を担う。例えば、ドライバ１９２２は、ディスプレイドライバ、カメラドライバ、ＢＬＵＥＴＯＯＴＨ（登録商標）またはＢＬＵＥＴＯＯＴＨ（登録商標）Ｌｏｗ Ｅｎｅｒｇｙドライバ、フラッシュメモリドライバ、シリアル通信ドライバ（例えば、ユニバーサル・シリアル・バス（ＵＳＢ）ドライバ）、Ｗｉ‐Ｆｉ（登録商標）ドライバ、オーディオドライバ、電力管理ドライバなどを含むことができる。

ライブラリ１９１０は、アプリケーション１９０６によって使用される低レベルの共通インフラストラクチャを提供する。ライブラリ１９１０は、メモリ割当て機能、文字列操作機能、数学機能、および同様なものなどの機能を提供するシステムライブラリ１９１８（例えば、Ｃ標準ライブラリ）を含むことができる。加えて、ライブラリ１９１０は、メディアライブラリ（例えば、ＭｏｖｉｎｇＰｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ‐４（ＭＰＥＧ４）、Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（Ｈ．２６４またはＡＶＣ）、Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ Ｌａｙｅｒ‐３（ＭＰ３）、ＡｄｖａｎｃｅｄＡｕｄｉｏ Ｃｏｄｉｎｇ（ＡＡＣ）、適応マルチレート（ＡＭＲ：Ａｄａｐｔｉｖｅ Ｍｕｌｔｉ‐Ｒａｔｅ）音声コーデック、ジョイント・フォトグラフィック・エキスパート・グループ（ＪＰＥＧまたはＪＰＧ）、またはポータブル・ネットワーク・グラフィックス（ＰＮＧ）などの様々なメディアフォーマットの提示および操作をサポートするライブラリ）、グラフィクスライブラリ（例えば、ディスプレイでグラフィックコンテンツに二次元（２Ｄ）および三次元（３Ｄ）でレンダリングするために使用されるＯｐｅｎＧＬフレームワーク）、データベースライブラリ（例えば、様々なリレーショナルデータベース機能を提供するＳＱＬｉｔｅ）、ウェブライブラリ（例えば、ウェブブラウジング機能性を提供するＷｅｂＫｉｔ）、および同様なものなど、ＡＰＩライブラリ１９２４を含むことができる。ライブラリ１９１０は、アプリケーション１９０６に多くの他のＡＰＩを提供する、多様な他のライブラリ１９２８も含むことができる。

フレームワーク１９０８は、アプリケーション１９０６で使用される高レベルの共通インフラストラクチャを提供する。例えば、フレームワーク１９０８は、様々なグラフィカルユーザインターフェース（GUI : graphical user interface）機能、高レベルリソース管理、および高レベルロケーションサービスを提供する。フレームワーク１９０８は、アプリケーション１９０６によって使用することのできる幅広い範囲の他のＡＰＩを提供することができ、そのうちのいくつかは、特定のオペレーティングシステムまたはプラットフォームに固有のものであってもよい。

例示的な実施形態において、アプリケーション１９０６は、ホームアプリケーション１９３６、連絡先アプリケーション１９３０、ブラウザアプリケーション１９３２、電子書籍リーダアプリケーション１９３４、ロケーションアプリケーション１９４２、メディアアプリケーション１９４４、メッセージングアプリケーション１９４６、ゲームアプリケーション１９４８、およびサードパーティアプリケーション１９４０などの多種多様な他のアプリケーションを含んでもよい。アプリケーション１９０６は、プログラムに定義される機能を実行するプログラムである。多様な方法で構造化された１つまたは複数のアプリケーション１９０６を作成するために、オブジェクト指向型プログラミング言語（例えば、Ｏｂｊｅｃｔｉｖｅ‐Ｃ、Ｊａｖａ、またはＣ＋＋）または手続き型プログラミング言語（例えば、Ｃまたはアセンブリ言語）など、様々なプログラミング言語を採用することができる。特定の実施例において、サードパーティアプリケーション１９４０（例えば、ＡＮＤＲＯＩＤ（商標）またはＩＯＳ（商標）ソフトウェア開発キット（SDK :software development kit）を使用して特定のプラットフォームのベンダ以外のエンティティが開発するアプリケーション）は、ＩＯＳ（商標）、ＡＮＤＲＯＩＤ（商標）、ＷＩＮＤＯＷＳ（登録商標）Ｐｈｏｎｅなどのモバイルオペレーティングシステム、または別のモバイルオペレーティングシステム上で動作するモバイルソフトウェアとしてもよい。この例では、サードパーティアプリケーション１９４０は、本明細書で説明する機能性を促進するために、オペレーティングシステム１９１２によって提供されるＡＰＩコール１９５０を呼び出すことができる。

図２０は、本明細書で述べる任意の１つまたは複数の方法論を機械２０００に行わせる命令２００８（例えば、ソフトウェア、プログラム、アプリケーション、アプレット、アプリ、または他の実行可能コード）を実行してもよい機械２０００の図表示である。例えば、命令２００８は機械２０００に、本明細書で説明する任意の１つまたは複数の方法を実行させてもよい。命令２００８は、汎用のプログラムされていない機械２０００を、説明および図示される機能を説明されるように遂行するようにプログラミングされた特定の機械２０００に変換する。機械２０００は、独立型デバイスとして作動してもよく、または他の機械に結合（例えば、ネットワーク化）してもよい。ネットワーク化されたデプロイメントでは、機械２０００は、サーバ・クライアントネットワーク環境内のサーバマシンまたはクライアントマシンの能力で、またはピアツーピア（または分散型）ネットワーク環境内のピアマシンとして作動してもよい。機械２０００は、サーバコンピュータ、クライアントコンピュータ、パーソナルコンピュータ（ＰＣ）、タブレットコンピュータ、ラップトップコンピュータ、ネットブック、セットトップボックス（ＳＴＢ）、ＰＤＡ、エンターテイメントメディアシステム、携帯電話、スマートフォン、モバイルデバイス、ウェアラブルデバイス（例えば、スマートウォッチ）、スマート家庭用機器（例えば、スマート家電）、その他スマートデバイス、ウェブアプライアンス、ネットワークルータ、ネットワークスイッチ、ネットワークブリッジ、または機械２０００が取るべきアクションを指定する命令２００８を逐次的にまたはその他の方法で実行することの可能な任意の機械を含んでもよいが、これだけに限定されない。さらに、１台の機械２０００しか図示していないが、「機械（machine）」という用語は、本明細書で述べる任意の１つまたは複数の方法論を行うために、命令２００８を個別にまたは共同で実行する機械の集合体を含むとも解釈されるものとする。

機械２０００は、プロセッサ２００２、メモリ２００４およびＩ／Ｏ構成要素２０４２を含んでもよく、これらは、バス２０４４を介して互いに通信するように構成されてもよい。例示的な実施形態において、プロセッサ２００２（例えば、中央処理装置（CPU : Central Processing Unit）、縮小命令セットコンピューティング（RISC : Reduced Instruction Set Computing）プロセッサ、複雑な命令セットコンピューティング（CISC : Complex Instruction Set Computing）プロセッサ、グラフィックス・プロセッシング・ユニット（ＧＰＵ）、デジタル・シグナル・プロセッサ（ＤＳＰ）、ＡＳＩＣ、無線周波数集積回路（RFIC : Radio-Frequency Integrated Circuit）、他のプロセッサ、またはこれらの任意の適切な組合せ）は、例えば、命令２００８を実行するプロセッサ２００６とプロセッサ２０１０とを含んでもよい。「プロセッサ」という用語は、命令を同時に実行してもよい２以上の独立したプロセッサ（「コア」ということもある）を備えてもよいマルチコアプロセッサを含むことが意図されている。図２０は複数のプロセッサ２００２を示しているが、機械２０００は、１つのコアを有する１つのプロセッサ、複数のコアを有する１つのプロセッサ（例えば、マルチコアプロセッサ）、１つのコアを有する複数のプロセッサ、複数のコアを有する複数のプロセッサ、またはこれらの任意の組合せを含んでもよい。

メモリ２００４は、メインメモリ２０１２、静的メモリ２０１４、および記憶装置２０１６を含み、ともにバス２０４４を介してプロセッサ２００２にアクセス可能である。メインメモリ２００４、静的メモリ２０１４および記憶装置２０１６は、本明細書で説明する方法論または機能の中の任意の１つまたは複数を具現する命令２００８を格納する。命令２００８は、機械２０００によるその実行中、完全にまたは部分的に、メインメモリ２０１２の中、静的メモリ２０１４の中、記憶装置２０１６内の機械可読媒体２０１８の中、プロセッサ２００２のうちの少なくとも１つ（例えば、プロセッサのキャッシュメモリ）の中、またはこれらの任意の適切な組合せの中にも常駐してもよい。

Ｉ／Ｏ構成要素２０４２は、入力を受信し、出力を提供し、出力を発生し、情報を伝送し、情報を交換し、測定値を取得するなど、多様な構成要素を含んでもよい。特定の機械に含まれる特定のＩ／Ｏ構成要素２０４２は、機械のタイプに依存することになる。例えば、携帯電話などの移動式機械は、タッチ入力デバイスまたはそのような他の入力メカニズムを含むかもしれないが、ヘッドレスサーバマシンは、おそらくこのような入力デバイスを含まないだろう。Ｉ／Ｏ構成要素２０４２が、図２０に図示していない他の多くの構成要素を含んでもよいことは認識されるであろう。様々な例示的な実施形態において、Ｉ／Ｏ構成要素２０４２は、出力構成要素２０２８および入力構成要素２０３０を含んでもよい。出力構成要素２０２８は、視覚構成要素（例えば、プラズマディスプレイパネル（PDP : plasma display panel）、発光ダイオード（LED : light emitting diode）ディスプレイ、液晶ディスプレイ（LCD : liquid crystal display）、プロジェクタ、またはブラウン管（CRT : cathode ray tube）などのディスプレイ）、音響構成要素（例えば、スピーカ）、ハプティック構成要素（haptic components）（例えば、振動モータ、抵抗メカニズム）、その他信号生成器などを含んでもよい。入力構成要素２０３０は、英数字入力構成要素（例えば、キーボード、英数字入力を受信するように構成されたタッチスクリーン、フォトオプティカルキーボード、またはその他英数字入力構成要素）、ポイントベースの入力構成要素（例えば、マウス、タッチパッド、トラックボール、ジョイスティック、モーションセンサ、または別のポインティング器具）、触覚入力構成要素（例えば、物理的なボタン、接触もしくは接触ジェスチャの位置と力の両方もしくは一方を提供するタッチスクリーン、またはその他触覚入力構成要素）、音声入力構成要素（例えば、マイクロホン）、および同様なものを含んでもよい。

さらなる例示的な実施形態において、Ｉ／Ｏ構成要素２０４２は、多彩な他の構成要素の中でも特に、生体認証構成要素２０２３、モーション構成要素２０３４、環境構成要素２０３６、または位置構成要素２０３８を含んでもよい。例えば、生体認証構成要素２０２３は、表現（例えば、手の表現、顔の表情、声の調子、身振り、または視線追跡）を検出し、生体信号（例えば、血圧、心拍数、体温、発汗または脳波）を測定し、人を識別し（例えば、声の識別、網膜の識別、顔の識別、指紋の識別、または脳波図ベースの識別）、および同様なことを行う構成要素を含む。モーション構成要素２０３４は、加速度センサ構成要素（例えば、加速度計）、重力センサ構成要素、回転センサ構成要素（例えば、ジャイロスコープ）などを含む。環境構成要素２０３６は、例えば、照明センサ構成要素（例えば、光度計）、温度センサ構成要素（例えば、周囲温度を検出する１つまたは複数の温度計）、湿度センサ構成要素、圧力センサ構成要素（例えば、気圧計）、音響センサ構成要素（例えば、背景騒音を検出する１つまたは複数のマイクロホン）、近接センサ構成要素（例えば、付近の物体を検出する赤外線センサ）、ガスセンサ（例えば、安全のため、または大気中の汚染物質を測定するために、有害ガスの検出濃度に対するガス検出センサ）、または周囲の物理的環境に対応する指標、測定値または信号を提供することのできる他の構成要素を含む。位置構成要素２０３８は、ロケーションセンサ構成要素（例えば、ＧＰＳ受信機構成要素）、高度センサ構成要素（例えば、高度計または高度を導ける気圧を検出する気圧計）、方位センサ構成要素（例えば、磁力計）および同様なものを含む。

通信は、多様な技術を使用して実施してもよい。Ｉ／Ｏ構成要素２０４２は、機械２０００をネットワーク２０２０またはデバイス２０２２にそれぞれカップリング２０２４およびカップリング２０２６を介して結合するように作動可能な通信構成要素２０４０をさらに含む。例えば、通信構成要素２０４０は、ネットワークインターフェース構成要素またはネットワーク２０２０とインターフェース接続するのに適した別のデバイスを含んでもよい。さらなる実施例では、通信構成要素２０４０は、有線通信構成要素、無線通信構成要素、セルラー通信構成要素、近距離無線通信（NFC : Near Field Communication）構成要素、Ｂｌｕｅｔｏｏｔｈ（登録商標）構成要素（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）Ｌｏｗ Ｅｎｅｒｇｙ）、Ｗｉ‐Ｆｉ（登録商標）構成要素、および他のモダリティを介して通信を提供する他の通信構成要素を含んでもよい。デバイス２０２２は、別の機械または多様な周辺デバイス（例えば、ＵＳＢを介して結合されている周辺デバイス）のいずれであってもよい。

また、通信構成要素２０４０は、識別子を検出してもよく、または識別子を検出するように作動可能な構成要素を含んでもよい。例えば、通信構成要素２０４０は、無線周波数識別（RFID : Radio Frequency Identification）タグリーダ構成要素、ＮＦＣスマートタグ検出構成要素、光学リーダ構成要素（例えば、ユニバーサル製品コード（UPC : Universal Product Code）バーコードなどの一次元のバーコード、クイック・レスポンス（ＱＲ）コード、アズテックコード、データマトリックス、データグリフ、マキシコード、ＰＤＦ４１７、ウルトラコード、ＵＣＣＲＳＳ‐２Ｄバーコード、および他の光学コードなどの多次元のバーコードを検出する光学センサ）、または音響検出構成要素（例えば、タグ付けされた音声信号を特定するマイクロホン）を含んでもよい。加えて、インターネットプロトコル（ＩＰ）ジオロケーションを介したロケーション、Ｗｉ‐Ｆｉ（登録商標）信号三角測量を介したロケーション、特定のロケーションを示すことのできるＮＦＣビーコン信号の検出を介したロケーションなど、通信構成要素２０４０を介して多様な情報が導出されてもよい。

様々なメモリ（例えば、メモリ２００４、メインメモリ２０１２、静的メモリ２０１４、および／またはプロセッサ２００２のメモリ）と、記憶装置２０１６と、の両方または一方は、本明細書で説明される方法論または機能の中の任意の１つまたは複数を具現する、またはそれによって使用される１つまたは複数の命令セットおよびデータ構造（例えば、ソフトウェア）を格納してもよい。これらの命令（例えば、命令２００８）は、プロセッサ２００２によって実行されるとき、開示される実施形態を様々な動作に実施させる。

命令２００８は、伝送媒体を使用して、ネットワークインターフェースデバイス（例えば、通信構成要素２０４０に含まれるネットワークインターフェース構成要素）を介して、多数の周知の転送プロトコルのうちの任意のもの（例えば、ハイパーテキスト転送プロトコル（HTTP : hypertext transfer protocol））を使用して、ネットワーク２０２０で送受信されてもよい。同様に、命令２００８は、伝送媒体を使用して、カップリング２０２６（例えば、ピアツーピア結合）を介して、デバイス２０２２に送受信されてもよい。

ステートメント
１．分散型コンピューティング環境内のイベント駆動型アプリケーション構成要素のイベントを、メッシュブローカーを使用して仲介する方法であって、
前記方法は、
分散型コンピューティング環境内の複数の計算ノードに関わるメディエーション作業をサポートするためにプロビジョニングされる複数のメッシュエージェントとしてメッシュブローカーをインスタンス化することと、
分散型コンピューティング環境の複数の計算ノード間のメッシュネットワークとして、複数のメッシュエージェントをデプロイすることと、
複数の計算ノードの複数の計算ノードペアの各々の間におけるイベント通知の伝送に関連するコストデータを格納する接続性カタログを維持することと、
複数のメッシュエージェントを使用して、メッシュネットワークでの経路を自動的に選択することと、を備える。自動的な選択は、メッシュネットワークでの低コスト経路を決定するためにコストデータを使用することを含む。

２．複数のメッシュエージェントは、複数の計算ノード間の少なくとも部分的なメッシュネットワークとして分散される、ステートメント１の方法。
３．メディエーション作業は、メッシュネットワーク内のイベントに適用される少なくとも１つの変換、フィルタリング、相関付け、コンテキスト化および分析を含む、前述のステートメントのいずれか１つまたは複数の方法。

４．複数の計算ノード間への複数のメッシュエージェントのデプロイメントは、複数のメッシュエージェントによって行われるメディエーション作業を、分散型コンピューティング環境の複数の計算ノードの中の最適なものに選択的にデプロイすることを含む、前述のステートメントのいずれか１つまたは複数の方法。

５．コンピューティング装置であって、
プロセッサと、
複数の命令を格納するメモリと、を備え、
プロセッサによって実行されたときに、複数の命令は、
分散型コンピューティング環境内の複数の計算ノードに関わるメディエーション作業をサポートするためにプロビジョニングされる複数のメッシュエージェントとして、メッシュブローカーをインスタンス化することと、
分散型コンピューティング環境の複数の計算ノード間にメッシュネットワークとして複数のメッシュエージェントをデプロイすることと、
複数の計算ノードの複数の計算ノードペアの各々の間におけるイベント通知の伝送に関連するコストデータを格納する接続性カタログを維持することと、
複数のメッシュエージェントを使用して、メッシュネットワークでの経路を自動的に選択することと、を実行させるように前記装置を設定する。自動的な選択は、メッシュネットワークでの低コスト経路を決定するためにコストデータを使用することを含む。

６．複数のメッシュエージェントは、複数の計算ノード間の少なくとも部分的なメッシュネットワークとして分散される、前述のステートメントのいずれか１つまたは複数のコンピューティング装置。

７．メディエーション作業は、メッシュネットワーク内のイベントに適用される少なくとも１つの変換、フィルタ、相関付け、コンテキスト化および分析を含む、前述のステートメントのいずれか１つまたは複数のコンピューティング装置。

８．複数の計算ノード間への複数のメッシュエージェントのデプロイメントは、複数のメッシュエージェントによって行われるメディエーション作業を、分散型コンピューティング環境の複数の計算ノードの中の最適なものに選択的にデプロイすることを含む、前述のステートメントのいずれか１つまたは複数のコンピューティング装置。

９．複数の命令を含む非一時的コンピュータ可読記憶媒体であって、
コンピュータによって実行されたときに、複数の命令は、コンピュータに、
分散型コンピューティング環境内の複数の計算ノードに関わるメディエーション作業をサポートするためにプロビジョニングされる複数のメッシュエージェントとしてメッシュブローカーをインスタンス化することと、
分散型コンピューティング環境の複数の計算ノード間にメッシュネットワークとして複数のメッシュエージェントをデプロイすることと、
複数の計算ノードの複数の計算ノードペアの各々の間におけるイベント通知の伝送に関連するコストデータを格納する接続性カタログを維持することと、
複数のメッシュエージェントを使用して、メッシュネットワークでの経路を自動的に選択することと、を実行させる。自動的な選択は、メッシュネットワークでの低コスト経路を決定するためにコストデータを使用することを含む。

１０．複数のメッシュエージェントは、複数の計算ノード間に少なくとも部分的なメッシュネットワークとして分散される、前述のステートメントのいずれか１つまたは複数のコンピュータ可読記憶媒体。

１１．メディエーション作業は、メッシュネットワーク内のイベントに適用される少なくとも１つの変換、フィルタ、相関付け、コンテキスト化および分析を含む、前述のステートメントのいずれか１つまたは複数のコンピュータ可読記憶媒体。

１２．複数の計算ノード間への複数のメッシュエージェントのデプロイメントは、複数のメッシュエージェントによって行われるメディエーション作業を、分散型コンピューティング環境の複数の計算ノードの中の最適なものに選択的にデプロイすることを含む、前述のステートメントのいずれか１つまたは複数のコンピュータ可読記憶媒体。

Claims (20)

1. 分散型コンピューティング環境内のイベント駆動型アプリケーション構成要素のイベントをメッシュブローカーを使用して仲介する方法であって、
   前記分散型コンピューティング環境内のイベント通知の拡張をサポートする複数のメッシュエージェントとして、前記メッシュブローカーをインスタンス化すること、
   前記分散型コンピューティング環境の複数の計算ノード間にメッシュネットワークとして前記複数のメッシュエージェントをデプロイすること、
   前記メッシュネットワーク内で、イベントコンシューマ計算ノードに伝送するべき、前記複数の計算ノードのうちのイベントプロデューサ計算ノードでのイベントを検出すること、
   前記イベントの検出に応答して、前記イベントプロデューサ計算ノードで前記イベント通知を生成すること、
   前記複数の計算ノードの複数対の計算ノードの各対の計算ノード間のイベント通知の伝送に関連するコストデータを格納する接続性カタログを維持すること、
   前記複数のメッシュエージェントを使用して、前記メッシュネットワークにおける複数の経路を自動的に選択することであって、前記コストデータを用いて前記メッシュネットワークにおける複数の低コスト経路を決定することを含む前記複数の経路を自動的に選択すること、
   拡張プロビジョニングルールを使用して、前記複数の低コスト経路のうちの選択された経路に沿ってノードを選択すること、
   前記選択されたノードにおいて前記拡張を前記イベント通知に適用して拡張されたイベント通知を生成すること、
   前記選択された経路を介して前記拡張されたイベント通知を前記イベントコンシューマ計算ノードに配信すること、を備える方法。
2. 前記複数のメッシュエージェントは、前記複数の計算ノード間に部分的なメッシュネットワークとして分散される、請求項１に記載の方法。
3. 前記拡張は、少なくとも変換、フィルタリング、相関付け、コンテキスト化、およびイベントトラフィックフロー分析のうちの１つである、請求項１に記載の方法。
4. 前記拡張を適用する際の制約を示す拡張制約を備える拡張データを取得することをさらに備え、
   前記拡張を適用するために前記選択された経路に沿って前記ノードを選択することは、前記選択されたノードが前記制約を満たすと判断することをさらに含む、請求項１に記載の方法。
5. コンピューティング装置であって、
   プロセッサと、
   複数の命令を格納するメモリと、を備え、
   前記プロセッサによって実行されたときに、前記複数の命令は、
   分散型コンピューティング環境内のイベント通知の拡張をサポートする複数のメッシュエージェントとして、メッシュブローカーをインスタンス化すること、
   前記分散型コンピューティング環境の複数の計算ノード間にメッシュネットワークとして前記複数のメッシュエージェントをデプロイすること、
   前記メッシュネットワーク内で、イベントコンシューマ計算ノードに伝送するべき、前記複数の計算ノードのうちのイベントプロデューサ計算ノードでのイベントを検出すること、
   前記イベントの検出に応答して、前記イベントプロデューサ計算ノードで前記イベント通知を生成すること、
   前記複数の計算ノードの複数対の計算ノードの各対の計算ノード間のイベント通知の伝送に関連するコストデータを格納する接続性カタログを維持すること、
   前記複数のメッシュエージェントを使用して、前記メッシュネットワークにおける複数の経路を自動的に選択することであって、前記コストデータを用いて前記メッシュネットワークにおける複数の低コスト経路を自動的に決定することを含む前記複数の経路を自動的に選択すること、
   拡張プロビジョニングルールを使用して、前記複数の低コスト経路のうちの選択された経路に沿ってノードを選択すること、
   前記選択されたノードにおいて前記拡張を前記イベント通知に適用して拡張されたイベント通知を生成すること、
   前記選択された経路を介して前記拡張されたイベント通知を前記イベントコンシューマ計算ノードに配信すること、を実行させるように前記コンピューティング装置を設定する、コンピューティング装置。
6. 前記複数のメッシュエージェントが、前記複数の計算ノード間に部分的なメッシュネットワークとして分散される、請求項５に記載のコンピューティング装置。
7. 前記拡張は、前記メッシュネットワーク内のイベントに適用される少なくとも変換、フィルタ、相関付け、コンテキスト化、およびイベントトラフィックフロー分析のうちの１つである、請求項５に記載のコンピューティング装置。
8. 前記拡張を適用する際の制約を示す拡張制約を備える拡張データを取得することをさらに備え、
   前記拡張を適用するために前記選択された経路に沿って前記ノードを選択することは、前記選択されたノードが前記制約を満たすと判断することをさらに含む、請求項５に記載のコンピューティング装置。
9. 複数の命令を含むコンピュータ可読記憶媒体であって、
   コンピュータによって実行されたときに、前記複数の命令は、
   分散型コンピューティング環境内のイベント通知の拡張をサポートするように構成された複数のメッシュエージェントとしてメッシュブローカーをインスタンス化すること、
   前記分散型コンピューティング環境の複数の計算ノード間にメッシュネットワークとして前記複数のメッシュエージェントをデプロイすること、
   前記メッシュネットワーク内で、イベントコンシューマ計算ノードに伝送するべき、前記複数の計算ノードのうちのイベントプロデューサ計算ノードでのイベントを検出すること、
   前記イベントの検出に応答して、前記イベントプロデューサ計算ノードで前記イベント通知を生成すること、
   前記複数の計算ノードの複数対の計算ノードの各対の計算ノード間のイベント通知の伝送に関連するコストデータを格納する接続性カタログを維持すること、
   前記複数のメッシュエージェントを使用して、前記メッシュネットワークにおける複数の経路を自動的に選択することであって、前記コストデータを用いて前記メッシュネットワークにおける複数の低コスト経路を決定することを含む前記複数の経路を自動的に選択すること、
   拡張プロビジョニングルールを使用して、前記複数の低コスト経路のうちの選択された経路に沿ってノードを選択すること、
   前記選択されたノードにおいて前記拡張を前記イベント通知に適用して拡張されたイベント通知を生成すること、
   前記選択された経路を介して前記拡張されたイベント通知を前記イベントコンシューマ計算ノードに配信すること、を含む複数の動作を前記コンピュータに実行させる、コンピュータ可読記憶媒体。
10. 前記複数のメッシュエージェントが、前記複数の計算ノード間に部分的なメッシュネットワークとして分散される、請求項９に記載のコンピュータ可読記憶媒体。
11. 前記拡張は、少なくとも変換、フィルタ、相関付け、コンテキスト化、および、イベントトラフィックフロー分析のうちの１つである、請求項９に記載のコンピュータ可読記憶媒体。
12. 前記拡張を適用する際の制約を示す拡張制約を備える拡張データを取得することをさらに備え、
    前記拡張を適用するために前記選択された経路に沿って前記ノードを選択することは、前記選択されたノードが前記制約を満たすと判断することをさらに含む、請求項９に記載のコンピュータ可読記憶媒体。
13. 前記接続性カタログは、イベント、各イベントのイベントプロデューサ、および各イベントのローカルイベントコンシューマのリストを含む、請求項１に記載の方法。
14. 前記接続性カタログとは異なるプロデューサカタログは、各イベントプロデューサのアイデンティティとロケーションとに関連付けられた各イベントの一意の識別子を維持する、請求項１に記載の方法。
15. 前記接続性カタログとは異なるコンシューマカタログは、各イベントコンシューマのアイデンティティとロケーションとに関連付けられた各イベントの一意の識別子を維持する、請求項１に記載の方法。
16. 前記複数の低コスト経路を選択することは、
    直接ルーティングコストが所定の閾値を逸脱するかどうかを判定すること、
    前記直接ルーティングコストが前記所定の閾値を逸脱するという判定に応じて、コスト効率の高い中間経路を判定すること、をさらに含む、請求項１に記載の方法。
17. 前記接続性カタログは、イベント、各イベントのイベントプロデューサ、および各イベントのローカルコンシューマのリストを含み、
    前記コンピューティング装置は、
    前記接続性カタログとは異なり、各イベントプロデューサのアイデンティティとロケーションとに関連付けられた各イベントの一意の識別子を維持するプロデューサカタログと、
    前記接続性カタログおよび前記プロデューサカタログとは異なり、各イベントコンシューマのアイデンティティとロケーションとに関連付けられた各イベントの一意の識別子を維持するコンシューマカタログと、をさらに備える、請求項５に記載のコンピューティング装置。
18. 前記複数の低コスト経路を選択することは、
    直接ルーティングコストが所定の閾値を逸脱するかどうかを判定すること、
    前記直接ルーティングコストが前記所定の閾値を逸脱するという判定に応じて、コスト効率の高い中間経路を判定すること、をさらに含む、請求項５に記載のコンピューティング装置。
19. 前記接続性カタログは、イベント、各イベントのイベントプロデューサ、および各イベントのローカルコンシューマのリストを含み、
    前記複数の動作は、
    前記接続性カタログとは異なり、各イベントプロデューサのアイデンティティとロケーションとに関連付けられた各イベントの一意の識別子を維持するプロデューサカタログを維持すること、
    前記接続性カタログおよび前記プロデューサカタログとは異なり、各イベントコンシューマのアイデンティティとロケーションとに関連付けられた各イベントの一意の識別子を維持するコンシューマカタログを維持すること、をさらに備える、請求項９に記載のコンピュータ可読記憶媒体。
20. 前記複数の低コスト経路を選択することは、
    直接ルーティングコストが所定の閾値を逸脱するかどうかを判定すること、
    前記直接ルーティングコストが前記所定の閾値を逸脱するという判定に従って、コスト効率の高い中間経路を決定すること、をさらに含む、請求項９に記載のコンピュータ可読記憶媒体。