イベント駆動型メッセージング

イベント駆動型メッセージングは​​、サービスプロバイダーの周辺で発生するイベントに関心のあるサービスコンシューマーが、従来の非効率的なポーリングベースのメカニズムに頼ることなく、イベントが発生したときにそのイベントに関する通知を受け取ることができるようにするための設計パターンです。^[1]

イベント駆動型サービスとメッセージ駆動型（キュー駆動型とも呼ばれる）サービスを区別することが重要です。イベント駆動型サービス（ AWS SNSなど）は消費者から切り離されています。一方、キュー/メッセージ駆動型サービス（AWS SQSなど）は消費者と結合されています。^[2]

サービス コンシューマーとサービス プロバイダー間のインタラクションは、通常、サービス コンシューマーがサービス コンシューマー自身の境界内で発生するイベントに応答する必要があるため、サービス コンシューマーによって開始されます。たとえば、ユーザーが実行したアクションに応答して、その結果をユーザー インターフェイスに中継する必要がある計算を実行するために、外部リソース (つまり、サービス プロバイダー) からのデータが必要な場合などです。 ^[3]ただし、サービス コンシューマーがサービス プロバイダー自身の境界内でイベントが発生するのを待つ必要がある状況もあります。このような状況では、サービス コンシューマーは、イベントが発生したときに、何らかの方法でそのイベントについて通知される必要があります。1 つの方法は、サービス コンシューマーがサービス プロバイダーを定期的にポーリングして、イベントが発生したかどうかを確認できるようにプログラムすることです。このアプローチは、非効率性だけでなく、動作の予測不可能性も示します。非効率性は、サービス コンシューマーとサービス プロバイダーが非生産的なインタラクションに従事しているためであり、信頼性が低いのは、サービス コンシューマーがサービス プロバイダーをポーリングする前に、イベントが実際に複数回発生し、以前のイベントとその関連データが失われる可能性があるためです。これらの問題以外にも、このような手法では、サービス コンシューマーがポーリングを実行する間隔が固定されているため、イベント データが取得されるのはその時点のみであり、イベントが実際に発生したときではないため、遅延も発生します。複数のサービス コンシューマーが特定のサービス プロバイダーに依存している場合、このシナリオ全体がさらに悪化します。

この問題に対処するために、イベント駆動型メッセージング設計パターンは、イベント関連データをサービス消費者にタイムリーに通知することを保証するパブリッシャー-サブスクライバー通信メカニズムを提案し、 ^[4]従来のポーリングベースの通信メカニズムに関連する非効率性を排除します。

イベント駆動型メッセージング設計パターンを適用するには、サービス プロバイダーがイベントを登録するイベント マネージャーが必要です。サービス コンシューマーは、広告されたイベントの一部またはすべてに関心があるかどうかを登録します。イベントが発生すると、サービス プロバイダーはイベント マネージャーに通知し、イベント マネージャーは登録されているすべてのサービス コンシューマーに即座に通知します。^{[5]この通信メカニズムは、}オブジェクト指向の世界で従来適用されているObserver パターンと根底を共有しています。^[5]この設計パターンは、イベントに応答することが基本的な原理であるため、イベント駆動型アーキテクチャからいくつかの概念も借用しています。 ^[6]

このようなパブリッシャー・サブスクライバーベースの通信メカニズムを実際に実装するには、複雑なメッセージ追跡および転送メカニズムを提供するためのアーキテクチャ拡張が必要です。成熟したESB製品は通常、このような機能を提供できるはずです。このパターンを適用すると、サービス コンシューマーとサービス プロバイダーをさらに分離^[7]し、サービス構成の全体的な信頼性を高めることができます。

• Erl et al. 、 (2009)。SOA デザイン パターン。Prentice Hall。ISBN 0-13-613516-1。 
• Michael Stal. サービス指向アーキテクチャのためのアーキテクチャパターンとブループリントの使用[オンライン]。アクセス日: 2010 年 5 月 1 日。

• SOA パターン