Loading article…
イベント駆動型SOAは、サービス指向アーキテクチャ（SOA）の一種であり、イベント駆動型アーキテクチャのインテリジェンスとプロアクティブ性を、サービス提供における組織的な機能と組み合わせたものです。イベント駆動型SOAが登場する以前は、一般的なSOAプラットフォームは、事前に定義されたビジネスプロセスを通じてサービスを一元的にオーケストレーションし、既にトリガーされるべき処理はビジネスプロセス内で定義されていることを前提としていました。この従来のアプローチ（SOA 1.0と呼ばれることもあります）では、特定のビジネスプロセス内外で発生するイベントは考慮されていません。そのため、スケジュールされたアクティビティとスケジュールされていないアクティビティの両方を含む一連のアクティビティのパターンによって一連のサービスがトリガーされるような複雑なイベントは、従来のSOA 1.0アーキテクチャでは考慮されていませんでした。
SOA 2.0アーキテクチャ（「イベント駆動型SOA」）では、ビジネスユーザーがイベントを監視、分析、強化して、一見直感的に明らかではないさまざまなイベント間の関連性を確立できます。これにより、強化されたイベントが他のユーザー、特にビジネスアナリストやマーケティングディレクターに可視化され、SOA 2.0システムが特定のパターンに対処するためのアクションを自動化することも可能になります。[ 1 ]
SOA 2.0とは、多数の低レベルなシステムイベントから高レベルのビジネスイベントを生成する機能のことです。イベントは、リアルタイムデータ（例えば、ミドルウェア、アプリケーション、データベース、Webサービスなど）をフィルタリングし、他のイベントを関連付けることで発見された依存関係や因果関係といった定義的な詳細情報を付加することによって生成されます。
SOA 2.0環境によって生成される豊富なイベントを通じて、顧客のショッピングカート放棄率がここ数日で急上昇していることが明らかになった場合、マーケティング部門への通知によって、競合他社が顧客を他社で購入させる原因となった行動について調査を開始することができます。多くのショッピングカートに共通する商品があったでしょうか？もしそうであれば、競合他社はどのような価格でその商品を提供しているのでしょうか？
実際には、ストリーミングされたイベント間のこの関係は、因果ベクトルエンジンによって処理されます。このエンジンは、最近閲覧されたイベントに基づいて検索を実行し、関係が発見された場合はイベントに因果ベクトルを割り当てます。AがBの原因である場合、因果ベクトルエンジンは、Bの因果ベクトルルールインデックスにAへの参照が含まれているかどうかを確認します。エンジンは、異なるトランザクションのイベントを同時に処理する可能性があり、その順序は発生順序と異なる場合があります。
シーケンシャルシステムや手続き型システム（クライアントが変更要求をポーリングする必要がある）とは異なり、イベント駆動型SOAでは、システムやコンポーネントがイベント発生時にリアルタイムで動的に応答できます。SOA 2.0は、長時間実行処理機能を導入することで、SOA 1.0を補完し、拡張しています。
長時間実行処理機能により、アーキテクチャは長期間にわたって様々な非同期イベントを収集し、これらのイベントを因果関係に関連付けることができます。SOA 2.0イベントパターンは、数日、数週間、または数か月にわたるイベント間の関係性を検出するように設計および実装でき、特定の条件が満たされた場合に、イベントパターンに対処するためのビジネスプロセスをトリガーします。
SOA 2.0のイベント駆動型プログラミングは、イベント生成元とイベント消費者の間の疎結合な関係という概念に基づいて構築されています。イベント消費者は、イベントがどこで、なぜ発生するかには関心を持たず、イベントが発生したときに呼び出されることだけを重視します。イベント生成元とイベント消費者を分離するシステムやアプリケーションは、通常、イベントディスパッチャ（チャネル）に依存します。このチャネルには、イベント生成元とイベントハンドラ間の仲介役となるイベントキューが含まれています。
典型的なSOA 2.0パラダイムは、4つの重要な要素から構成されています。
SOA 2.0 Webサービスは、オーケストレーションとコレオグラフィーという2つの方法で構成できます。オーケストレーションでは、中央プロセスが関連するWebサービスを制御し、操作に関係するWebサービス上でのさまざまな操作の実行を調整します。関連するSOA 2.0サービスは、自身が構成の一部または上位のビジネスプロセスの一部であることを知る必要はありません。オーケストレーションの中央コーディネーターのみがこれを認識しているため、オーケストレーションは操作の明示的な定義とSOA 2.0サービスの呼び出し順序によって一元化されます。
一方、コレオグラフィーは中央コーディネーターに依存しません。むしろ、コレオグラフィーに関与する各SOA 2.0サービスは、定義されたトリガー基準に基づいて、いつ操作を実行するか、そして誰とやり取りするかを正確に把握しています。コレオグラフィーは、メッセージの交換に焦点を当てた共同作業です。コレオグラフィーのすべての参加者は、ビジネスプロセス、実行すべき操作、交換すべきメッセージ、およびメッセージ交換のタイミングを把握しておく必要があります。
BPELはオーケストレーションのパラダイムに従っています。コレオグラフィーについては、WSCI （Web Services Choreography Interface）やWS-CDL（Web Services Choreography Description Language）などの他の標準規格で規定されています。
因果関係は私たちの周りの世界に内在しており、意思決定に不可欠な要素です。人間の知能は、現在の人工知能の計算能力よりも速く、これらの関係を処理し、収集します。人工知能における根本的な障害の一つは、人間が直感を用いるときのように、出来事を関連付ける自動的な能力が欠如していることです。
因果ベクトルエンジンを使用することで、エンジンに組み込まれた構造的および時間的ルールに基づき、適切な時空間条件下で因果関係の認識を向上させることができます。加算的因果関係、媒介的因果関係、双方向的因果関係といった複雑な因果意味の認識をコード化することで、エンジンは実際に関連している事象と、関連しているように見えるだけで実際には関連していない事象を区別できるようになります。
このエンジンは、圧倒的な因果ベクトル変化率伝播を用いてイベント間の関係性を符号化し、複数の事象間の因果関係を検証する部分順序を確立します。エンジンは、イベントシーケンスを異なる時間順序で再生・再再生し、関連する可能性のあるトポロジー的接続を推論し、これらの再再生結果をアナリストによって事前にプログラムされたルールと比較します。
複数の低レベルシステムイベントは、因果ベクトルエンジンによって処理され、これらのルールと比較されて、より高レベルのビジネスイベントがトリガーされます。これは、因果ベクトルエンジン（CVE）コンソールアプリケーションを介して行われ、ビジネスアナリストにイベントをリアルタイムで表示します。株価ティッカーのように、イベントのストリームをリアルタイムで監視できるだけでなく、CVEコンソールアプリケーションには、同じイベントを異なるコンテキストで一覧表示する複数のウィンドウがあり、ビジネスアナリストはCVEがイベント間の関係をどのように処理しているかを確認できます。
シーケンシャルウィンドウには、日付とタイムスタンプの順にイベントが表示されます。CVEがルールリストを処理し、イベント間の暗黙的な関係を作成するにつれて、他の1つ以上のウィンドウがさまざまな順序で表示されます。コンソールアプリケーションには、ビジネスアナリストがイベント間の関係をその場で作成し、これらの関係に対応するルールを定義できるさまざまなボタンとコントロールが用意されています。
ビジネスアナリストは、ルールまたはイベントコンテキストに添付された SQL クエリステートメントを通じて、追加の定義の詳細を組み込むことができます。CVE アプリケーションは、投資信託マネージャーがリスク管理に使用する現代の株式取引アプリケーションとよく似ています。CVE アプリケーションとエンジンの例は SILK で見ることができます。[ 2 ]
ほとんどのエンタープライズ サービス バス(ESB) 実装には、「メディエーション」と呼ばれる機能が含まれています。たとえば、メディエーション フローは、WebSphere エンタープライズ サービス バスインターセプトの一部です。Muleもメディエーション フローをサポートしています。メディエーション フローは、既存のサービスとそれらのサービスを使用するクライアントの間で渡されるメッセージを変更します。メディエーション フローは、メッセージのログ記録、データ変換、ルーティングなどの機能を提供するために仲介または介入します。これらの機能は通常、インターセプション デザイン パターンを使用して実装できます。[ 3 ]
ESB をメッセージが通過する際、ESB は高レベルのビジネス イベントを監視しているチャネル宛てのメッセージを強化します。つまり、各メッセージについて、ESB はデータベースにクエリを実行して、メッセージ内のデータ エンティティに関する追加情報を取得する場合があります。たとえば、顧客 ID に基づいて、ESB の仲介フローは顧客の居住地の郵便番号を取得できます。また、エンド ユーザーからのリクエストの発信元 IP アドレスに基づいて、ESB の仲介フローはその IP アドレスがどの国、州、または郡に属するかを調べることができます。
これらの例は、データエンリッチメント、つまり最終的にトリガーされるであろう高レベルのビジネスイベントの意図に基づいて、既存のデータに付加価値を加えるという概念を表しています。
ESBのメディエーション フローは、サービス コンポーネント アーキテクチャ(SCA)のコンポーネント タイプの 1 つです。他の SCA コンポーネントと同様に、プログラムは提供するエクスポートを介してメディエーション フローにアクセスし、メディエーション フローはインポートを介してメッセージを他の外部サービスに転送します。JMS 用の特別なインポートとエクスポート ( JMSバインディングと呼ばれます) により、開発者はバインディング構成を指定し、データ処理コードを記述できます。メディエーション フローは、バスを通過するメッセージを操作する一連のメディエーション プリミティブで構成されています。
開発者がエクスポートとインポートの両方のカスタムバインディングをコーディングしたら、メディエーションフローコンポーネントに集中できるようになります。WebSphere Integration Developerアセンブリエディターでは、これはJMSカスタムバインディングメディエーションコンポーネントによって行われ、フローコンポーネントのインターフェイス上の各操作はリクエストとレスポンスで表されます。
サービスデータオブジェクト（SDO）フレームワークは、データアプリケーション開発のための統一フレームワークを提供します。SDOを使用することで、開発者はデータにアクセスして利用するために特定のAPIに精通する必要がありません。SDOを通じて、開発者はリレーショナルデータベース、エンティティEJBコンポーネント、XMLページ、Webサービス、サービスコンポーネントアーキテクチャ、JavaServer Pagesページなど、複数のデータソースからのデータを簡単に操作できます。
メディエーションフローは、インポートおよびエクスポートで使用されるバインディングとは完全に独立しています。実際、フロー実装の外部でSDO DataObjectインスタンスへの変換を行う目的は、メディエーションモジュールとの間でメッセージが送受信されるプロトコルやフォーマットを知らなくてもメディエーションフローを構築できるようにするためです。
ビジネスレベルのトリガー条件により、SOA 2.0アーキテクチャは、リアルタイムの顧客インテリジェンス、マーケティングオートメーション、顧客ロイヤルティソリューションなどの機能を実現できます。ビジネスオブジェクトは、顧客、アカウント、ローン、旅行日程など、アーキテクチャ内の現実世界のエンティティをモデル化します。これらのオブジェクトのいずれかの状態が変化し、監視エージェントがその変化が（監視対象基準リストと比較して）重要であると判断すると、イベントが作成され、他の監視エージェントに渡されます。
例えば、実際のビジネス上の問題や機会を検出することで、収益の増加につながる可能性があります。顧客が注文をキャンセルした場合、余剰生産能力によって生産ロットの収益性が低下する可能性があります。SOA 2.0イベントによってマーケティング部門に通知され、余剰生産能力を再販するための特別な販売キャンペーンを作成することで、元の収益性の高い単位当たりのコストを取り戻すことができます。
業務プロセスの実行中に発生するイベントを自動的に監視し、企業内外で緊急の対応が必要かどうかを判断します。これらの監視エージェントは、特定の業務状況や業務運営の変化を継続的にテストします。必要に応じて、エージェントは関係者に警告を発したり、推奨事項を提示したり、他のアプリケーションにメッセージを送信したり、業務プロセス全体を呼び出したりします。
トリガー型ビジネスプロセスは、コスト抑制、ビジネス環境への迅速な対応、または新たな市場機会の開拓を通じて、収益成長を直接的に支援するものであるべきです。また、結果として得られるビジネスプロセスは、目標達成に向けた業務進捗状況の測定、必要な情報を必要な人にのみ伝えることによる運用コストの管理、主要プロセスのパフォーマンス状況の主要意思決定者への報告などにも役立ちます。
例えば、「カート放棄」メッセージからCRMイベントを構築できます（トランザクション、顧客ID、および時間を解析します）。他のフィルターを使用してカート内の商品の価値を抽出し、システムの相関分析機能を利用して、ECサイトのパフォーマンス問題が発生していたかどうかなどの因果関係を示す指標を追加できます。CRMイベントには、顧客データベースからの顧客価値やランクを含めることもできます。
別の例として、SOA 2.0プラットフォームは、受信した個別のサービスコールの種類に基づいて、個々の苦情の根本的なパターンを検出することで製品の欠陥を特定し、その可能性のある欠陥についてエンジニアリング部門または製造部門にアラートを発信することができます。
ほとんどのSOA 1.0エンタープライズサービスバス実装で利用できるメカニズムの1つに、パブリッシュ/サブスクライブ機能があります。ESB機能をパブリッシュ/サブスクライブメッセージとして実装することで、SOA 2.0メッセージパターンを作成するためにシステムイベントに関する高度な知識は必要ありません。企業が多数のパブリッシュ機能を実装した後、SOAミドルウェアアナリストは、利用可能なパブリッシュメッセージのうちどれを組み合わせて、SOA 2.0で強化されたトリガーを検出できる独自のパターンを作成する戦略を立てることができます。
因果ベクトルエンジン (CVE) の仕組みは、ストアドプロシージャに記述されたSQL 構造の拡張可能なビューによって簡単に実装されています。[ 4 ] AがB を引き起こし、因果関係がN個のトランザクション内で発生する必要がある場合、 SQL ORDER BY タイムスタンプ句は、時間枠内で発生したすべてのトランザクションのカウンターをインクリメントする結果セットを作成します。これは、発生Aに対するBの一致トランザクションのN個です。追加のストアドプロシージャの作成は、CVE コンソールアプリケーションまたは標準的なデータベース開発者ツールキットを使用して実行できます。[ 5 ]
引用文献にある発熱/インフルエンザ/感染症ドメインロジックなどのドメインアルゴリズムは、選択されたビジネスルールをユースケースに適用するSQLコードを生成するために使用されます。SOA環境でCVEを使用すると、SOA 2.0の原則を適用することで、そうでなければ見逃されたり、ずっと後になってから特定されたりしたであろうビジネスチャンスを特定できるため、ビジネスの俊敏性が向上します。[ 6 ]
グレンジャー因果性分析（GCA）を用いた機能的磁気共鳴画像法（fMRI）は、脳領域間の因果関係を検出します。1サンプルテストの結果、rFICと背側前帯状皮質（dACC）の間に正の因果関係があることが示されました。[ 7 ]
Oracle CVE分析エンジンは、それぞれがデータの一部または全部を評価する一連の理論モデルを使用します。ビジネスアナリストが因果関係の要因を構成する際には、どのモデルがどの因果関係の要因を考慮する必要があるかを示す基準を指定します。[ 8 ]