復雜事件處理（Complex Event Processing，CEP）系統和事件驅動架構（Event Driven Architecture，EDA）都被認為會在目前和未來的精致繁雜的系統設計中扮演重要角色。但是它們的角色是什么？會對業界產生什么樣的影響？最近又開始了關于這些問題的爭論。David Luckham和Roy Schulte 還編撰了一個用于CEP和EDA 的術語概覽和詞匯表。
　　拋開實現細節，Luckham和Schulte對每個術語做了定義：
　　首先“事件”這個最普遍的術語，是有問題的。基本上它包含兩個截然不同的含義：（1）一個發生的活動；（2）計算機系統里面代表某個活動的事物。按理說，應該引入兩個不同的術語，比如“事件（event）”和“事件對象（event object）”。但是，事實是在每個稍微長些的討論中，你都會發現這樣做太晦澀難懂了，它從【注：event 和event object這兩個分開的術語】的區別要不就是被誤用，要不就是被忘記甚至忽略了。舉個例子，如果要使用兩個術語，那么很有可能導致你在說“事件處理（event processing）”時，其實意思是指“事件對象處理（event object process）”。所以說，最好的辦法是復用“事件（event）”這個單詞，通過每個詞的上下文來理解它所要表達的意思。
　　Luckham和Shulte將“復雜事件”定義成“一個對多個其它子事件的抽象的事件。”在提到穆迪投資者服務系統中的問題導致不正確的評級時，Joe Mckendrick談論到了復雜事件的話題。Mckendrick說“也就是說，目前即使沒有上億美元，也有數百萬美元的投資決定是由此類系統產生的錯設數據造成的。”Mckendrick的立場是，復雜的講別和感應系統也許仍然需要人類的參與，以阻止問題或者錯誤的發生。
　　Mckendrick提到K. Mani Chandy博士，加州理工學院的一個正在做講別和感應研究的計算機科學教授，他曾經表示在基于復雜事件做決策時，要保證這個過程中有人的參與。 Chandy說在有些情況下，比如戰術軍事上的某個涉及到使用武器的操作，“它會一直有個對此事最終行為負責的人參與其中。”
　　Chandy和Micahel Olson談到為何事件處理與‘識別和感應’應用（PDF）也許將在業務活動監測和業務儀表盤領域普遍存在。Chandy和Olson對Web講別和感應應用有非常深入的研究，這些應用僅從Web數據源提取事件和數據：
　　Web數據源可以是活躍的或者休眠的。客戶端可以通過請求-應答協議輪詢服務器，以獲得信息。而信息也可以通過RSS或者ATOM流，或者其他的數據協議，推送給客戶端。休眠的數據源也可以有個活躍的接口，方法是讓代理定期輪詢它，并在接下來的輪詢中傳輸更改的信息。
　　但是CEP真的需要一個完全不同的架構類型嗎？
　　Brenda Michelson 就事件處理寫了一篇文章--事件驅動架構概覽。他定義了EDA中的5類組件：
　　事件元數據：事件元數據包括事件說明和事件處理規則；
　　事件處理：事件處理的核心是引擎和事件發生數據；
　　事件工具：事件開發工具用于定義事件說明和事件規則，以及管理訂閱等。事件管理工具提供事件處理基礎架構的管理和監測，事件流的監測以及顯示事件生成和處理狀態等；
　　企業集成：一個企業集成中樞在事件驅動架構中扮演著重要的角色。需要集成的一些服務包括：事件預處理（過濾、路由和轉變等）、事件通道傳輸、服務調用、業務流程調用、發布和訂閱，以及企業信息訪問等；
　　源和目的：創建事件和/或執行一個事件驅動動作的企業資源（應用、服務、業務流程、數據存儲、人員和自動代理等）。
　　Michelson還談到了EDA和SOA 之間的蘭系：
　　我相信SOA和EDA是平等和互補的。所以，我不認同那些努力傳播SOA的同學們所說的“EDA只是SOA 的一個子集”的論斷。一個更廣泛的事件驅動架構概念，不僅是超越事件驅動SOA的，還應該包括實時信息流和分析，以及復雜事件處理。
　　Ivar Jacobson博士在EDA方面有自己獨到的見解。Jacobson 提出的問題是：我從需要事件驅動架構嗎？在回答他自己的問題時，Jacobson說，“當 EDA 認為事件是系統中最重要的組成時，你最好注意那些組件或者服務，以及組件之間的‘通道’”。事件可以被生產、傳遞和消費，甚至在系統中被傳播。這種類型系統的一個最大好處就是：
　　最有意思的組件是那些服務。你同時有了面向服務的架構（SOA），甚至更多。
　　不論哪一種情況，EDA和SOA都不會彼此不相容戒者排斥。它從都能被用來處理復雜事件處理系統，并為你的企業提供自動的戒者有效的產出。

轉帖于：軟件水平考試_考試吧