復雜事件處理技術是推動SOA發展的引擎

復雜事件處理技術是推動SOA發展的引擎

作者：東緣　來源：IT專家網

　　在過去的幾年里，IT團體已經認識到了SOA的益處，毫無保留地支持從單獨的應用程序向根據松散耦合的服務系統制作的應用程序過渡?，F在，我們處在擁有集成的復雜事件處理(CEP)技術的SOA新時代的邊緣。復雜事件處理技術通過引進耦合的服務把SOA提高到了一個新的水平。這是超越松散耦合的服務的一大步。復雜事件處理技術能夠搜集在企業中運行的任何服務的數據以及有關這些服務的數據。它還允許把商務邏輯應用到那個數據以便深入了解情況，對變化的情況做出合適的實時反應。在SOA環境中，事件驅動模型的力量在于它允許更大的靈活性，因為服務完全是完全獨立的，不知道誰在制造他們在操作的這些事件或者誰在消費他們制造的事件。它還允許更好地了解當前的狀況，能夠在事件發生時立即做出反應。

　　這是如何工作的?

　　在一個“傳統的”基于要求-反應范例的SOA架構中，它有許多分布式組件，其中大多數組件向其它組件提供服務。這些組件一直處于“待機”狀態，等待包含額外數據的服務請求。這種做法對于滿足大多數商業需求來說要比單獨的應用程序優越得多。這種做法允許重復利用應用程序，實現業務的靈活性。一個單個的服務能夠被多個應用程序使用。一個服務能夠在不影響任何其它服務的情況下進行修改。

　　盡管有上述優點，它仍有很多局限性。SOA要求應用程序知道有什么服務和如何與這些應用程序互動。它還意味著除非一個應用程序提出一個服務請求，否則什么事情都不會發生。采用請求-回應范例，每一個服務都必須知道需要通知哪一個其它的服務發生了什么事情。這種應用的含義之一是為了增加一個新功能，現有的服務必須要修改。

　　在復雜事件處理中輸入“事件”。一個事件是發生的某個事情：一項處理、系統事件、一筆股票交易、一個網頁的請求等等。在目前的企業中，事件的可能性是數不盡的。每一個事件產生一個消息。在一個事件驅動的架構中，這個消息要發送給一切相關的應用程序。采用事件，一項服務不需要知道哪一項服務關心它做了什么，只需要知道那個服務是什么。因此，它發出一個事件。任何其它有關的服務都能夠訂閱任何相關的事件傳送信息。這是一個解耦合系統的性質：一個事件數據發射程序不需要知道接收者是誰。事件是在不知道其的重要性是什么的情況下產生的，使用這些事件的服務需要了解這些事件。

　　明確地說，以pub/sub消息方式解耦合已經出現很長時間了。然而，卻少的東西是實時分析事件數據的工具以及把商務邏輯應用到監視和回應變化的情況的工具。這是復雜事件處理技術的功能。孤立地處理一個單個的事件一種例行性的任務，與傳統的交易處理沒有區別，盡管是以異步處理為基礎的。但是，分析其它事件環境中即將出現的事件的需求或者分析過去的事件的需求是怎樣的呢?例如,找出趨勢或者方式或者對一些事件的綜合信息做出反應。這就是復雜事件處理技術向一個事件驅動的架構中增加的智能。

　　然而，一個常見的錯覺是事件驅動的架構是一種替代SOA的技術。人們必須在這兩種技術中做出選擇?，F實是，這兩種技術是互補的，因此有“事件驅動的SOA”這個詞匯。使用事件驅動的方式執行全部應用程序互動顯然是沒有意義的。確實，有許多處理需要請求-回應方式。但是，對于不使用這種方式的處理來說，事件驅動方式的優勢是很明顯的。在SOA架構中部署事件處理器可以作為一種附加功能，而不是取代SOA。事實上，如果現有的服務正在產生事件信息，事件處理器甚至可以沒有任何影響地應用，不需要對現有的組件進行任何修改。

　　在一個SOA架構中，復雜事件處理也許會扮演許多角色：

　　·搜集有關單個服務的信息;正?；?、過濾和匯聚信息;把信息提供給只需要摘要信息的其它服務。

　　·監視服務以發現機會或者威脅(也就是需要回應的情況);自動啟動回應或者發送一個需要得到回復的警告。

　　·同步分布式服務以保證一個服務狀態中的變化根據需要傳送給其它服務。

　　·捕捉各種服務中的事件數據，記錄這個事件的歷史或者提供一個確定當前系統狀態的一個單一的點。

　　最后，這不是在SOA和EDA之間做出選擇。SOA架構的優勢在過去的幾年里已經變得越來越明顯了。然而，隨著目前的企業設法利用這個優勢更快地做出反應以保持競爭的領先地位，同時努力匯聚、分析和應對大量的數據，向SOA架構中增加實時自動化和智能的能力能夠提供巨大的價值。復雜事件處理技術能夠實現這個目的。

原文轉自：http://www.anti-gravitydesign.com