複合イベント処理（CEP）システムとイベント駆動型アーキテクチャ（EDA）は、現在および将来の高性能システムにおいて重要な役割を果たすものとして認識されており、その役割と適用方法が議論されている。David LuckhamとRoy SchulteがCEPおよび EDAで使用される用語の概要(リンク)と解説をまとめている。
LuckhamとSchulteは、インプリメンテーションの特性とは別個に各用語を定義して、次のように語っている。
最も基本的な用語、「イベント」には問題があります。本来、明確に異なる 2 つの意味があり、(1) 発生するアクティビティ、および (2) あるコンピュータシステム内のアクティビティを表すものを示します。そのため、「イベント」と「イベントオブジェクト」など､2つを区別する用語が導入される傾向があります。しかし、論議が1つまたは2つのパラグラフより長くなると、わかりにくくなり、2つを混同したり、用語の忘却、脱落が起きることになります。たとえば、2つの異なる用語を使用すると、（下記に示すとおり）「イベント処理」を「イベントオブジェクト処理」と記述する必要があるでしょう。最適の解決策は、「イベント」という語にさまざまな意味を持たせることです。それぞれが使用される文脈は、意図する意味の指標となります。
LuckhamとShulteは、複合イベントを「メンバを呼び出す他のイベントの抽象であるイベント」として定義した。複合イベントは、不正な格付けの割当てが発生した Moody’s Investors Service のシステムの問題(リンク)に言及したときにJoe McKendrick(リンク)が選択したトピックである。McKendrickは、「何億ドルと言わないまでも、何百万ドルもの資金が、システムによって生成された不正なデータに基づいて投資決定されることを意味する」と言っている。彼は、複雑なSense and Respondシステムには、問題やエラーを防止するために依然として人手の介入が必要であるという立場を取っていた(リンク)。
McKendrickは、Sense and Respond (S&R)システム周辺の研究を行っているカリフォルニア工科大学コンピュータサイエンス科教授K. Mani Chandy博士が(リンク)、複合イベントに基づいて意思決定を行う際にループ内に人手を介在させる必要性について語ったことを指摘した。Chandyは、武器を使用するための意思決定が行われる戦術的な軍事作戦などの状況下では、「最終的な行動に責任を持つのは、常に人間である」と述べている。
ChandyはMicahel Olson(リンク)とともに、イベント処理およびSense and Respondアプリケーション(リンク) (PDF・英語)が、ビジネスアクティビティ監視およびビジネスダッシュボードの領域に定着する（ユビキタスになる）までの過程について語った。ChandyとOlsonは、さらにWeb S&Rアプリケーションの領域に踏み込み、これらはWebデータソースからイベントおよびデータを取得するS&Rアプリケーションであると述べている。
Webデータソースは、活動的にすることも受動的にすることもできます。クライアントは、情報を抽出するために要求応答プロトコルを使用して、サーバをポーリングすることができます。あるいは、RSSまたはATOMストリーム、その他のデータプロトコルを使用してクライアントに情報を送信することができます。受動的データソースにアクティブなインターフェイスを連携させて、エージェントにより、定期的にポーリングして後続のポーリングでの変更に関する情報をアクティブに送信することができます。
しかし、CEPには、完全に異なるタイプのアーキテクチャが必要だろうか?
Brenda Michelson(リンク)は、イベント処理の関連においてイベント駆動型アーキテクチャの概要(リンク)を示している。Michelsonは、EDAのコンポーネントを次の5つのカテゴリに分類している。
- イベントメタデータ: イベントメタデータには、イベント仕様とイベント処理ルールが含まれている。
- イベント処理: イベント処理の中核は、エンジンとイベントオカレンスデータである。
- イベントツーリング: イベント開発ツールは、イベント仕様と処理ルールの定義、予約管理のために必要となる。イベント管理ツールは、イベント処理インフラストラクチャの管理および監視、イベントフローの監視、イベント生成および処理統計の可視性を提供する。
- エンタープライズ統合: エンタープライズ統合バックボーンは、イベント駆動型アーキテクチャにおいて重要な役割を果たす。必要な統合サービスには、イベント処理（フィルタ、ルート、変換）、イベントチャネルトランスポート、サービス呼出し、ビジネスプロセス呼出し、発行および予約、エンタープライズ情報アクセスなどがある。
- ソースおよびターゲット: アプリケーション、サービス、ビジネスプロセス、データストア、人員、自動化されたエージェントなど、イベントを生成し、イベント駆動型アクションを実行するエンタープライズのリソース。
Michelsonは、EDAとSOAの関係についても論じている。
わたしは、SOA と EDA は同格（ピア）であり補完する関係にあると考えています。ですから、EDA は SOA のたんなるサブセット（子）にすぎないとする SOA 信奉者には賛成できません。広義のイベント駆動型アーキテクチャは、イベント駆動型 SOA を超えて、リアルタイム情報フローおよび分析、複合イベント処理を含みます。
Ivar Jacobson博士は(リンク) 、EDAについて異なる見方を示している。Jacobsonは、「イベント駆動型アーキテクチャは必要か?(リンク)」という問いを投げかけている。Jacobsonは自身の問いかけに、EDAではシステムの最重要エレメントとしてイベントを重視するが、「コンポーネントまたはサービスと、これら一部のコンポーネント間のある種の "チャネル" を重視した方がよい」と回答している。イベントは、このようにシステム内で生成、伝達、消費、ブロードキャストされる。このタイプのシステムの大きな利点の1つは、次のとおりである。
最も興味深いコンポーネントはサービスです。同時にサービス指向アーキテクチャ（SOA）と、それ以上のものが得られます。
いずれの場合も、EDAとSOAは他方を妨害または排除しない。この2つは、企業に自動的または実用的成果をもたらす複合イベント処理システムを提供するために使用できる。