當(dāng)我在看EDA時(shí)候

知識(shí)準(zhǔn)備

關(guān)鍵詞解釋：

iBPM：代表智能業(yè)務(wù)流程管理(Intelligent Business Process Management)
SOA：面向服務(wù)的架構(gòu)（SOA）是一個(gè)組件模型，它將應(yīng)用程序的不同功能單元（稱為服務(wù)）通過(guò)這些服務(wù)之間定義良好的接口和契約聯(lián)系起來(lái)。接口是采用中立的方式進(jìn)行定義的，它應(yīng)該獨(dú)立于實(shí)現(xiàn)服務(wù)的硬件平臺(tái)、操作系統(tǒng)和編程語(yǔ)言。這使得構(gòu)建在各種各樣的系統(tǒng)中的服務(wù)可以以一種統(tǒng)一和通用的方式進(jìn)行交互。
CEP:復(fù)雜事件處理 (CEP) 處理同時(shí)發(fā)生的不同事件，以確定這些事件對(duì)應(yīng)的操作。事件通道中的事件可以有不同的事件類型，并且可以長(zhǎng)期發(fā)生。可以根據(jù)內(nèi)容、時(shí)間或位置來(lái)關(guān)聯(lián)事件。因此，CEP 通常用于檢測(cè)異常、風(fēng)險(xiǎn)，甚至業(yè)務(wù)機(jī)會(huì)，旨在利用相比傳統(tǒng)報(bào)告解決方案更具現(xiàn)時(shí)性的信息的優(yōu)勢(shì)，最終在競(jìng)爭(zhēng)中占據(jù)上風(fēng)。
EDA：一個(gè)事件驅(qū)動(dòng)框架（EDA）定義了一個(gè)設(shè)計(jì)和實(shí)現(xiàn)一個(gè)應(yīng)用系統(tǒng)的方法學(xué)，在這個(gè)系統(tǒng)里事件可傳輸于松散耦合的組件和服務(wù)之間。一個(gè)事件驅(qū)動(dòng)系統(tǒng)典型地由事件消費(fèi)者和事件產(chǎn)生者組成。事件消費(fèi)者向事件管理器訂閱事件，事件產(chǎn)生者向事件管理器發(fā)布事件。當(dāng)事件管理器從事件產(chǎn)生者那接收到一個(gè)事件時(shí)，事件管理把這個(gè)事件轉(zhuǎn)送給相應(yīng)的事件消費(fèi)者。如果這個(gè)事件消費(fèi)者是不可用的，事件管理者將保留這個(gè)事件，一段間隔之后再次轉(zhuǎn)送該事件消費(fèi)者。這種事件傳送方法在基于消息的系統(tǒng)里就是:儲(chǔ)存（store）和轉(zhuǎn)送（forward）。
ESP:在事件流處理 (ESP) 中，除了“相關(guān)”事件以外，“通常的”事件（如所有一般指令或 RFID 事件）也會(huì)發(fā)布到事件通道中。這對(duì)事件處理提出了更高的要求，同時(shí)也提供了更多評(píng)估選項(xiàng)。
SEP:在簡(jiǎn)單事件處理 (SEP) 中，只有“相關(guān)”事件才會(huì)被放入事件通道中進(jìn)行處理。比如“XY 類別的汽車已售罄”或“冬季輪胎庫(kù)存緊張”。這非常類似于基于消息的系統(tǒng)。處理邏輯評(píng)估事件類型和內(nèi)容，然后相應(yīng)地做出反應(yīng)。
MDM:MDM 提供通用組件（或服務(wù)）以確保數(shù)據(jù)維護(hù)和分發(fā)的一致性。
FP
FRP
10.RP
11.ESB:Gartner 于 2002 年創(chuàng)造了術(shù)語(yǔ)“企業(yè)服務(wù)總線”，分析師 Roy Schulte 進(jìn)一步引入這個(gè)術(shù)語(yǔ)來(lái)描述當(dāng)時(shí)市場(chǎng)上的一類軟件產(chǎn)品。10 年后，關(guān)于 EBS 到底是什么或者它應(yīng)該提供什么依然沒(méi)有達(dá)成共識(shí)。根據(jù)制造商和來(lái)源的不同，有很多不同的定義。其中，ESB 的定義包括：
“一種集成架構(gòu)樣式，支持提供者和服務(wù)用戶之間通過(guò)由各種點(diǎn)對(duì)點(diǎn)連接構(gòu)成的公共通信總線進(jìn)行通信”
“企業(yè)用來(lái)集成應(yīng)用程序環(huán)境中服務(wù)的基礎(chǔ)架構(gòu)。”
“一種架構(gòu)模式，使用面向服務(wù)支持異構(gòu)環(huán)境之間的互操作性。”

一、EDA

1.1 EDA定義

Gartner在2003年引入了一個(gè)新術(shù)語(yǔ)事件驅(qū)動(dòng)架構(gòu)（Event Driven Architecture，EDA), 主要用于描述一種基于事件的范例。EDA 是一種用于進(jìn)行設(shè)計(jì)和實(shí)現(xiàn)應(yīng)用和系統(tǒng)的方法—在這些應(yīng)用和系統(tǒng)里, 事件所觸發(fā)的消息可以在獨(dú)立的、非耦合的組件和服務(wù)之間傳遞，這些模塊彼此并不知曉對(duì)方。這些應(yīng)用程序中的EDA極大地改進(jìn)了企業(yè)或政府響應(yīng)不同的、表面上毫無(wú)關(guān)聯(lián)事件的能力。通過(guò)提供瞬時(shí)過(guò)濾、聚合和關(guān)聯(lián)事件的能力，EDA可以快速地檢測(cè)出事件并判斷它的類型，從而幫助組織機(jī)構(gòu)快速、恰當(dāng)?shù)仨憫?yīng)和處理這些事件。通常事件可以采用發(fā)布/訂閱機(jī)制。

1.2 事件驅(qū)動(dòng)架構(gòu)概述

一個(gè)事件驅(qū)動(dòng)框架（EDA）定義了一個(gè)設(shè)計(jì)和實(shí)現(xiàn)一個(gè)應(yīng)用系統(tǒng)的方法學(xué)，在這個(gè)系統(tǒng)里事件可傳輸于松散耦合的組件和服務(wù)之間。一個(gè)事件驅(qū)動(dòng)系統(tǒng)典型地由事件消費(fèi)者和事件產(chǎn)生者組成。事件消費(fèi)者向事件管理器訂閱事件，事件產(chǎn)生者向事件管理器發(fā)布事件。當(dāng)事件管理器從事件產(chǎn)生者那接收到一個(gè)事件時(shí)，事件管理把這個(gè)事件轉(zhuǎn)送給相應(yīng)的事件消費(fèi)者。如果這個(gè)事件消費(fèi)者是不可用的，事件管理者將保留這個(gè)事件，一段間隔之后再次轉(zhuǎn)送該事件消費(fèi)者。這種事件傳送方法在基于消息的系統(tǒng)里就是:儲(chǔ)存（store）和轉(zhuǎn)送（forward）。

構(gòu)建一個(gè)包含事件驅(qū)動(dòng)構(gòu)架的應(yīng)用程序和系統(tǒng)，會(huì)使這些應(yīng)用程序和系統(tǒng)響應(yīng)更靈敏，因?yàn)槭录?qū)動(dòng)的系統(tǒng)更適合應(yīng)用在不可預(yù)知的和異步的環(huán)境里。

事件驅(qū)動(dòng)架構(gòu)在具體實(shí)現(xiàn)中是指由一系列相關(guān)組件構(gòu)成的應(yīng)用，而組件之間通過(guò)事件機(jī)制完成一定的業(yè)務(wù)功能。由于在一個(gè)EDA系統(tǒng)中各個(gè)組件都只專注于處理輸入的消息與發(fā)布輸出的消息，因而EDA系統(tǒng)能夠更有加效地對(duì)管道化（pipelined）的、由多軟件模塊鏈接而成的并發(fā)事件流（concurrent processing of events）進(jìn)行處理。

1.3 EDA特點(diǎn)

EDA系統(tǒng)中各組件以異步方式響應(yīng)事件，在本質(zhì)上是可以并行的，因而在政府部門的電子政務(wù)應(yīng)用中具有極大的優(yōu)勢(shì)。其具備以下特點(diǎn):

◆ 并發(fā)執(zhí)行

◆ 事件觸發(fā)/數(shù)據(jù)觸發(fā)/時(shí)間規(guī)則觸發(fā)

◆ 實(shí)時(shí)/增量響應(yīng)

◆ 分布式事件系統(tǒng)處理

上述特點(diǎn)能很好地滿足政府部門應(yīng)用需求，如跨部門的應(yīng)急聯(lián)動(dòng)系統(tǒng)或聯(lián)合監(jiān)管協(xié)同服務(wù)等應(yīng)用。

從目前情況來(lái)看，EDA系統(tǒng)還只是處理簡(jiǎn)單事件的系統(tǒng)，對(duì)于復(fù)雜事件的處理還有待進(jìn)一步的研究。但是，EDA仍然能作為SOA系統(tǒng)的一個(gè)有效補(bǔ)充，彌補(bǔ)SOA系統(tǒng)的一些不足，如實(shí)時(shí)響應(yīng)度不夠。

1.4 事件驅(qū)動(dòng)架構(gòu)優(yōu)勢(shì)

事件驅(qū)動(dòng)設(shè)計(jì)和開(kāi)發(fā)所提供的優(yōu)勢(shì)如下所示:

◆ EDA提高了對(duì)不斷變化的業(yè)務(wù)需求的響應(yīng)，最大限度地減少了對(duì)現(xiàn)有業(yè)務(wù)應(yīng)用的影響，也常消除了對(duì)新打包應(yīng)用的需要。如果采用特有的粗顆粒服務(wù)模型可以基于業(yè)務(wù)目標(biāo)快速確定可控的業(yè)務(wù)變更，并直接、迅速、有效地實(shí)施變更以達(dá)到業(yè)務(wù)敏捷性和完整性。

◆ 可以更容易開(kāi)發(fā)和維護(hù)大規(guī)模分布式應(yīng)用程序和不可預(yù)知的服務(wù)或異步服務(wù);

◆ 可以很容易，低成本地集成、再集成、再配置新的和已存在的應(yīng)用程序和服務(wù)。

◆ 促進(jìn)遠(yuǎn)程組件和服務(wù)的再使用，擁有一個(gè)更靈敏、沒(méi)有Bug的開(kāi)發(fā)環(huán)境。

從時(shí)間維度來(lái)看EDA的優(yōu)勢(shì):

◆ 短期利益:更容易定制，因?yàn)樵O(shè)計(jì)對(duì)動(dòng)態(tài)處理有更好的響應(yīng);

◆ 長(zhǎng)期利益:系統(tǒng)和組織的狀態(tài)變得更精準(zhǔn)，對(duì)實(shí)時(shí)變化的響應(yīng)接近于同步。

1.5 EDA和SOA之間的關(guān)系：

SOA和EDA是平等和互補(bǔ)的。所以，我不認(rèn)同那些努力傳播SOA的同學(xué)們所說(shuō)的“EDA只是SOA的一個(gè)子集”的論斷。一個(gè)更廣泛的事件驅(qū)動(dòng)架構(gòu)概念，不僅是超越事件驅(qū)動(dòng)SOA的，還應(yīng)該包括實(shí)時(shí)信息流和分析，以及復(fù)雜事件處理。

當(dāng)EDA認(rèn)為事件是系統(tǒng)中最重要的組成時(shí)，你最好注意那些組件或者服務(wù)，以及組件之間的‘通道’”

與Request/Response系統(tǒng)不同的是，要求請(qǐng)求者必須明確發(fā)送請(qǐng)求信息，而事件驅(qū)動(dòng)架構(gòu)提供一個(gè)機(jī)制去動(dòng)態(tài)響應(yīng)事件。在一個(gè)EDA系統(tǒng)里，事件產(chǎn)生者發(fā)布事件，事件消費(fèi)者接受事件。

業(yè)務(wù)系統(tǒng)可以從SOA和EDA中受益匪淺，因?yàn)槭录l(fā)生時(shí)EDA系統(tǒng)能觸發(fā)事件消費(fèi)者，SOA服務(wù)可以快速地從相同的消費(fèi)者中訪問(wèn)、查詢。系統(tǒng)要求有最高的響應(yīng)性，當(dāng)事件被觸發(fā)時(shí)這個(gè)系統(tǒng)必須能快速?zèng)Q定必須的動(dòng)作。到事件結(jié)束，事件應(yīng)該被發(fā)布和消費(fèi)，而且事件要穿越SOA所有的邊界，包括整個(gè)體系結(jié)構(gòu)和物理層。

系統(tǒng)要有最高的響應(yīng)性，當(dāng)事件觸發(fā)時(shí)這個(gè)系統(tǒng)必須能快速?zèng)Q定必須的動(dòng)作。到事件結(jié)束，事件應(yīng)該被發(fā)布和消費(fèi)，而且事件要穿越SOA所有的邊界，包括整個(gè)體系結(jié)構(gòu)和物理層。

1.6 ESB連接EDA和SOA

企業(yè)服務(wù)總線(Enterprise Service Bus，ESB)在異類平臺(tái)和環(huán)境間建立聯(lián)系，充當(dāng)允許不同應(yīng)用程序進(jìn)程之間進(jìn)行通信的中間層。部署到企業(yè)服務(wù)總線的服務(wù)可以由使用者或事件觸發(fā)。它同時(shí)支持同步方式和異步方式，可促進(jìn)一個(gè)或多個(gè)參與者之間的交互。因此 ESB 可提供 SOA 和 EDA 范例的所有功能。“ESB提供了消息的傳輸，格式的轉(zhuǎn)換等關(guān)鍵功能，為服務(wù)的請(qǐng)求者和服務(wù)提供者之間架設(shè)了溝通的橋梁，是企業(yè)應(yīng)用基礎(chǔ)架構(gòu)的粘合劑。” 甲骨文公司大中華區(qū)高級(jí)技術(shù)經(jīng)理黃建勇說(shuō)。

企業(yè)服務(wù)總線可連接各個(gè)異類節(jié)點(diǎn)并作為中介傳遞其間的所有通信和交互，這些節(jié)點(diǎn)可分散在面向服務(wù)的體系結(jié)構(gòu)(同步一對(duì)一方法)和事件驅(qū)動(dòng)的體系結(jié)構(gòu)(異步多對(duì)多方法)中。ESB 是目前處理集成挑戰(zhàn)的最有效方法，是可提供最大業(yè)務(wù)靈活性和不同應(yīng)用程序間的高效連接技術(shù)解決方案。

EDA應(yīng)用在很多ESB（企業(yè)服務(wù)總線）產(chǎn)品中，比如FiornaoESB中間件產(chǎn)品支持同步、異步和請(qǐng)求響應(yīng)事件，事件處理和傳輸實(shí)用不同的技術(shù)例如JMS，HTTP，電子郵件和基于XML的RPC等。比如“政府網(wǎng)上監(jiān)察系統(tǒng)”通過(guò)對(duì)被監(jiān)察對(duì)象（系統(tǒng)）數(shù)據(jù)的實(shí)時(shí)采集，通過(guò)EDA技術(shù)的事件觸發(fā)，事件過(guò)濾，實(shí)現(xiàn)對(duì)違規(guī)、違法、越權(quán)行政、超時(shí)限行政等問(wèn)題進(jìn)行通知和督辦等。

1.7 EDA應(yīng)用方向

事件驅(qū)動(dòng)架構(gòu)(EDA)是分布式應(yīng)用程序的普遍架構(gòu)形式，非常典型的是:分布式應(yīng)用程序都被設(shè)計(jì)成為模塊化的、封裝的、可共享事件服務(wù)的組件。能夠通過(guò)應(yīng)用程序、適配器以及無(wú)入侵性的代理操作來(lái)創(chuàng)建這些服務(wù)。

由于EDA的特點(diǎn)，在金融貿(mào)易、能源貿(mào)易、電信以及欺詐檢測(cè)這些行業(yè)中，一直都在采用事件驅(qū)動(dòng)架構(gòu)(EDA)技術(shù)。近期在我國(guó)政府的電子政務(wù)建設(shè)中

利用EDA分布式處理架構(gòu)的優(yōu)勢(shì)構(gòu)建共享交換平臺(tái)，實(shí)現(xiàn)跨部門、跨平臺(tái)、跨應(yīng)用系統(tǒng)的政務(wù)信息資源的共享與交換，并對(duì)政府應(yīng)急系統(tǒng)和跨委辦局之間的業(yè)務(wù)協(xié)同辦公提供支撐和保障。

EDA

Martin Fowler

二、響應(yīng)式編程和響應(yīng)式系統(tǒng)（EP&&ERP）

響應(yīng)式技術(shù)目前成功的標(biāo)志之一是“響應(yīng)式reactive”成為了一個(gè)熱詞，并且跟一些不同的事物與人聯(lián)系在了一起——常常伴隨著像“流streaming”、“輕量級(jí)lightweight”和“實(shí)時(shí)real-time”這樣的詞。

2.1 FRP

FRP定義

2.2 響應(yīng)式編程Reactive programming，

不要把它跟函數(shù)響應(yīng)式編程混淆了，它是異步編程下的一個(gè)子集，也是一種范式，在這種范式下，由新信息的有效性availability推動(dòng)邏輯的前進(jìn)，而不是讓一條執(zhí)行線程a thread-of-execution去推動(dòng)控制流control flow。

響應(yīng)式編程一般是事件驅(qū)動(dòng)event-driven，相比之下，響應(yīng)式系統(tǒng)則是消息驅(qū)動(dòng)message-driven的

響應(yīng)式編程的基本好處是：提高多核和多 CPU 硬件的計(jì)算資源利用率；根據(jù)阿姆達(dá)爾定律以及引申的 Günther 的通用可伸縮性定律Günther’s Universal Scalability Law 腳注3 ，通過(guò)減少序列化點(diǎn)serialization points來(lái)提高性能。

另一個(gè)好處是開(kāi)發(fā)者生產(chǎn)效率，傳統(tǒng)的編程范式都盡力想提供一個(gè)簡(jiǎn)單直接的可持續(xù)的方法來(lái)處理異步非阻塞式計(jì)算和 I/O。在響應(yīng)式編程中，因活動(dòng)(active)組件之間通常不需要明確的協(xié)作，從而也就解決了其中大部分的挑戰(zhàn)。

響應(yīng)式編程真正的發(fā)光點(diǎn)在于組件的創(chuàng)建跟工作流的組合。為了在異步執(zhí)行上取得最大的優(yōu)勢(shì)，把反壓back-pressure加進(jìn)來(lái)是很重要，這樣能避免過(guò)度使用，或者確切地說(shuō)，避免無(wú)限度的消耗資源。

2.4 事件驅(qū)動(dòng) && 消息驅(qū)動(dòng)

響應(yīng)式編程——專注于短時(shí)間的數(shù)據(jù)流鏈條上的計(jì)算——因此傾向于事件驅(qū)動(dòng)，而響應(yīng)式系統(tǒng)——關(guān)注于通過(guò)分布式系統(tǒng)的通信和協(xié)作所得到的彈性和韌性——?jiǎng)t是消息驅(qū)動(dòng)的腳注4 （或者稱之為消息式messaging 的）。

一個(gè)擁有長(zhǎng)期存活的可尋址long-lived addressable組件的消息驅(qū)動(dòng)系統(tǒng)跟一個(gè)事件驅(qū)動(dòng)的數(shù)據(jù)流驅(qū)動(dòng)模型的不同在于，消息具有固定的導(dǎo)向，而事件則沒(méi)有。消息會(huì)有明確的（一個(gè)）去向，而事件則只是一段等著被觀察observe的信息。另外，消息式messaging更適用于異步，因?yàn)橄⒌陌l(fā)送與接收和發(fā)送者和接收者是分離的。

一條消息就是一則被送往一個(gè)明確目的地的數(shù)據(jù)。一個(gè)事件則是達(dá)到某個(gè)給定狀態(tài)的組件發(fā)出的一個(gè)信號(hào)。在一個(gè)消息驅(qū)動(dòng)系統(tǒng)中，可尋址到的接收者等待消息的到來(lái)然后響應(yīng)它，否則保持休眠狀態(tài)。在一個(gè)事件驅(qū)動(dòng)系統(tǒng)中，通知的監(jiān)聽(tīng)者被綁定到消息源上，這樣當(dāng)消息被發(fā)出時(shí)它就會(huì)被調(diào)用。這意味著一個(gè)事件驅(qū)動(dòng)系統(tǒng)專注于可尋址的事件源而消息驅(qū)動(dòng)系統(tǒng)專注于可尋址的接收者。

2.5 響應(yīng)式系統(tǒng)

響應(yīng)式系統(tǒng)的基石是消息傳遞message-passing，消息傳遞為兩個(gè)組件之間創(chuàng)建一條暫時(shí)的邊界，使得它們能夠在時(shí)間上分離——實(shí)現(xiàn)并發(fā)性——和空間space ——實(shí)現(xiàn)分布式distribution與移動(dòng)性mobility。這種分離是兩個(gè)組件完全隔離isolation以及實(shí)現(xiàn) 彈性resilience和韌性elasticity基礎(chǔ)的必需條件。

2.6 響應(yīng)式系統(tǒng)&&響應(yīng)式編程

響應(yīng)式編程是一種管理內(nèi)部邏輯internal logic和數(shù)據(jù)流轉(zhuǎn)換dataflow transformation的好技術(shù)，在本地的組件中，做為一種優(yōu)化代碼清晰度、性能以及資源利用率的方法。響應(yīng)式系統(tǒng)，是一組架構(gòu)上的原則，旨在強(qiáng)調(diào)分布式信息交流并為我們提供一種處理分布式系統(tǒng)彈性與韌性的工具。

響應(yīng)式編程是一個(gè)非常有用的實(shí)現(xiàn)技術(shù)，可以用在響應(yīng)式架構(gòu)當(dāng)中。但是記住這只能幫助管理一部分：異步且非阻塞執(zhí)行下的數(shù)據(jù)流管理——通常只在單個(gè)結(jié)點(diǎn)或服務(wù)中。當(dāng)有多個(gè)結(jié)點(diǎn)時(shí)，就需要開(kāi)始認(rèn)真地考慮像數(shù)據(jù)一致性data consistency、跨結(jié)點(diǎn)溝通cross-node communication、協(xié)調(diào)coordination、版本控制versioning、編制orchestration、錯(cuò)誤管理failure management、關(guān)注與責(zé)任concerns and responsibilities分離等等的東西——也即是：系統(tǒng)架構(gòu)。

三、CEP

3.1 關(guān)鍵概念

事件指在業(yè)務(wù)里發(fā)生的事情，包括業(yè)務(wù)活動(dòng)、流程狀態(tài)、網(wǎng)絡(luò)或IT條件，或者其他任何東西。很多事件只要能夠識(shí)別出來(lái)就可以進(jìn)行處理，通常會(huì)伴隨著發(fā)送警報(bào)。當(dāng)無(wú)法可靠處理單個(gè)事件而必須在上下文里分析時(shí)，就會(huì)使用CEP。幾乎所有場(chǎng)景里，CEP分析都要求事件能夠實(shí)時(shí)關(guān)聯(lián)，并且要求帶有準(zhǔn)確時(shí)間戳的一定格式。

CEP應(yīng)用大致分為兩大類：事件關(guān)聯(lián)和根本原因分析。通常來(lái)說(shuō)，事件關(guān)聯(lián)用來(lái)識(shí)別不是單個(gè)事件，而是多個(gè)事件組合起來(lái)觸發(fā)的條件.

比如“如果你打噴嚏并且發(fā)燒了，那么你感冒了。”根本原因分析用來(lái)解釋一系列事件—通常是錯(cuò)誤—的底層原因，確保補(bǔ)救措施并不僅僅針對(duì)癥狀，而是能夠真正解決問(wèn)題。

所有CEP都應(yīng)該是實(shí)時(shí)的，或者和事件同時(shí)發(fā)生，但是，當(dāng)然這里的同時(shí)發(fā)生意味著很多種情況。CEP處理的關(guān)系越復(fù)雜，就越難保證實(shí)時(shí)性。

3.2 從事件驅(qū)動(dòng)編程（Event-driven Programming)開(kāi)始

如果你寫過(guò)GUI程序，對(duì)事件處理一定不陌生。事實(shí)上，事件驅(qū)動(dòng)編程已經(jīng)成為一種設(shè)計(jì)模式。大多數(shù)的GUI庫(kù)都會(huì)采用這一模式。

簡(jiǎn)單的說(shuō)，事件驅(qū)動(dòng)模式包括三個(gè)參與者：事件產(chǎn)生者，事件分發(fā)器和事件處理器。

事件產(chǎn)生者（Events Generator）決定是否需要產(chǎn)生事件。比如，GUI上的每個(gè)組件都是一個(gè)事件產(chǎn)生者，可以根據(jù)用戶操作產(chǎn)生鼠標(biāo)事件或者鍵盤事件。
事件分發(fā)器（Events Dispatcher）收集所有事件產(chǎn)生者發(fā)出的事件放入事件隊(duì)列(Events Queue)，并根據(jù)事件的類型將事件分發(fā)給已經(jīng)注冊(cè)的事件處理器。事件分發(fā)器通常由GUI框架實(shí)現(xiàn)。
事件處理器（Events Handler)根據(jù)接收到的事件進(jìn)行處理，需要GUI框架的使用者自行編寫。

事件驅(qū)動(dòng)編程的核心價(jià)值在于：程序的執(zhí)行流程不是預(yù)先定義好的，而是由程序的使用者決定的。這將極大增強(qiáng)程序的交互性。

就好像DVD與RPG游戲的區(qū)別：前者的劇情是設(shè)定好的，你只能進(jìn)行開(kāi)始、暫停、快進(jìn)、回退等有限的交互；后者可以決定主角的行為從而影響故事的結(jié)局。

3.3 事件驅(qū)動(dòng)業(yè)務(wù)（Event-driven Business)

代碼的世界不可能是現(xiàn)實(shí)世界的完整鏡像，但一定是對(duì)現(xiàn)實(shí)世界的某種抽象，這種抽象能夠簡(jiǎn)化代碼世界中對(duì)問(wèn)題的分析和處理。同時(shí)，這種抽象還可以反向映射到現(xiàn)實(shí)世界，為我們解決現(xiàn)實(shí)問(wèn)題提供思路。

現(xiàn)代企業(yè)生存的外部環(huán)境處于劇烈的變化之中，“敏捷企業(yè)”已經(jīng)成為生存之道，而事件驅(qū)動(dòng)業(yè)務(wù)是敏捷企業(yè)的一個(gè)基本要求。

事件驅(qū)動(dòng)業(yè)務(wù)（Event-driven Business)，是在連續(xù) 的業(yè)務(wù)過(guò)程中進(jìn)行決策的一種業(yè)務(wù)管理方式，即根據(jù)不同時(shí)點(diǎn)上出現(xiàn)的一系列事件觸發(fā)相關(guān)的任務(wù)，并調(diào)度可用的資源執(zhí)行任務(wù)。如果說(shuō)事件驅(qū)動(dòng)編程能夠?yàn)檐浖?lái)更靈活的交互性和強(qiáng)大的功能，那么企業(yè)中的事件驅(qū)動(dòng)業(yè)務(wù)能夠大幅度提高業(yè)務(wù)的效率和靈活性。

事件驅(qū)動(dòng)業(yè)務(wù)依托于比較成熟的信息化建設(shè)。各個(gè)業(yè)務(wù)應(yīng)用系統(tǒng)在產(chǎn)生連續(xù)不斷的數(shù)據(jù)流的同時(shí)，根據(jù)定義好的條件產(chǎn)生一些業(yè)務(wù)事件，按照策略對(duì)這些業(yè)務(wù)事件進(jìn)行分析處理，觸發(fā)新的業(yè)務(wù)事件或者業(yè)務(wù)流程，即實(shí)現(xiàn)了業(yè)務(wù)的事件驅(qū)動(dòng)。

從上面的描述可以看出，事件驅(qū)動(dòng)業(yè)務(wù)要求能夠快速（毫秒級(jí)）、不間斷的處理連續(xù)、海量的數(shù)據(jù)，具備靈活的規(guī)則或策略設(shè)置，從而具備迅速識(shí)別、捕獲、響應(yīng)實(shí)時(shí)業(yè)務(wù)數(shù)據(jù)的能力。而傳統(tǒng)的企業(yè)IT架構(gòu)通常采用：

在業(yè)務(wù)應(yīng)用系統(tǒng)中處理業(yè)務(wù)操作
遵循固定的業(yè)務(wù)流程（Business Process）處理跨系統(tǒng)事務(wù)，并且這些流程很少變化基于數(shù)據(jù)倉(cāng)庫(kù)進(jìn)行海量數(shù)據(jù)的存儲(chǔ)及事后分析
這種IT架構(gòu)遠(yuǎn)遠(yuǎn)達(dá)不到事件驅(qū)動(dòng)業(yè)務(wù)的要求。

事件驅(qū)動(dòng)業(yè)務(wù)能夠應(yīng)用的業(yè)務(wù)領(lǐng)域很多，凡是需要快速處理連續(xù)性數(shù)據(jù)、需要能夠靈活制定策略的業(yè)務(wù)，都可以采用事件驅(qū)動(dòng)的業(yè)務(wù)模式。如證券行業(yè)常見(jiàn)的風(fēng)險(xiǎn)分析預(yù)警（事前及事中風(fēng)控）、投資決策（程序化交易）、經(jīng)紀(jì)人績(jī)效計(jì)算等。

3.2.1 業(yè)務(wù)事件處理的幾個(gè)層次

其實(shí)在傳統(tǒng)的IT架構(gòu)中，我們已經(jīng)實(shí)現(xiàn)了業(yè)務(wù)事件的處理。比如在傳統(tǒng)的業(yè)務(wù)應(yīng)用系統(tǒng)中，我們通常將業(yè)務(wù)數(shù)據(jù)存儲(chǔ)在數(shù)據(jù)庫(kù)中，通過(guò)應(yīng)用系統(tǒng)的操作界面由人工發(fā)現(xiàn)和處理業(yè)務(wù)事件。

這樣的處理方式存在兩個(gè)不足，一是速度慢，二是對(duì)于復(fù)雜的情況只靠人腦難以處理。于是有了兩個(gè)技術(shù)方向：

消息隊(duì)列（MQ）對(duì)于速度慢的解決辦法是用機(jī)器代替人工，為了在多個(gè)系統(tǒng)之間傳遞消息，發(fā)展出了消息隊(duì)列（MQ）的技術(shù)
商業(yè)智能（BI）為了應(yīng)對(duì)復(fù)雜性，通過(guò)數(shù)據(jù)倉(cāng)庫(kù)將數(shù)據(jù)整合到一起，并用專門的工具在數(shù)據(jù)模型的基礎(chǔ)上進(jìn)行分析
但是上述兩個(gè)方向是正交的：MQ不適合處理復(fù)雜性，而B(niǎo)I主要適應(yīng)于對(duì)結(jié)構(gòu)化的歷史數(shù)據(jù)的分析，無(wú)法處理“現(xiàn)在”的情況。

3.4 CEP：魚與熊掌可以兼得

CEP（Complex Event Processing）的出現(xiàn)解決了上述兩個(gè)方面的問(wèn)題，在實(shí)時(shí)性和復(fù)雜性方面都得到了很好的解決。

3.4.1 處理數(shù)據(jù)流

不管是單獨(dú)的應(yīng)用系統(tǒng)，還是數(shù)據(jù)倉(cāng)庫(kù)，都是先將數(shù)據(jù)存儲(chǔ)到數(shù)據(jù)庫(kù)/數(shù)據(jù)倉(cāng)庫(kù)，然后再處理或查詢。而CEP與MQ類似的將數(shù)據(jù)看作是數(shù)據(jù)流 。在連續(xù)數(shù)據(jù)的快速移動(dòng)過(guò)程中進(jìn)行分析處理。這樣的方式不需要很大的數(shù)據(jù)加載，完全可以在內(nèi)存中進(jìn)行，從而能夠快速產(chǎn)生結(jié)果。

3.4.2 處理復(fù)雜性

業(yè)務(wù)事件可能很復(fù)雜，在各種不同的數(shù)據(jù)流中源源不斷產(chǎn)生各種類型的事件。需要對(duì)這些業(yè)務(wù)事件進(jìn)行復(fù)雜的計(jì)算，如過(guò)濾、關(guān)聯(lián)、聚合等，同時(shí)還需要考慮這些也是事件出現(xiàn)的時(shí)間序列。最終才能產(chǎn)生有意義的事件，或觸發(fā)業(yè)務(wù)流程。同時(shí)，這些計(jì)算的規(guī)則可能還會(huì)經(jīng)常變化。

這一類的問(wèn)題通常通過(guò)基于規(guī)則的推理機(jī)（即規(guī)則引擎）來(lái)實(shí)現(xiàn)。

綜上所述，CEP在邏輯上應(yīng)該包括：

事件發(fā)生器通過(guò)應(yīng)用系統(tǒng)、文件系統(tǒng)、數(shù)據(jù)庫(kù)、互聯(lián)網(wǎng)、人工、以及傳感器產(chǎn)生事件
事件處理器模式的匹配、驗(yàn)證和改進(jìn)，路由，轉(zhuǎn)換以及編排
事件消費(fèi)者與事件發(fā)生器類似，也可以是應(yīng)用系統(tǒng)、文件系統(tǒng)、數(shù)據(jù)庫(kù)、互聯(lián)網(wǎng)、人工界面等

3.5 CEP的三個(gè)基本模型及其特性，以及CEP的限制

CEP的最簡(jiǎn)單方案是觸發(fā)或者閾值激活處理。該模型里，事件要么直接導(dǎo)致一些操作的發(fā)生，要么是當(dāng)事件達(dá)到某個(gè)閾值時(shí)會(huì)執(zhí)行某個(gè)操作。CEP能夠在從源到目的地的事件流里引入事件處理，比如在線事務(wù)處理，因?yàn)樯傻难訒r(shí)很小。雖然觸發(fā)或閾值CEP能夠通過(guò)單個(gè)類型事件實(shí)現(xiàn)，但是也可以使用多個(gè)不同權(quán)重的不同事件來(lái)提供對(duì)條件更為深入的理解。

第二種模型是上下文模型，該模型假定一個(gè)事件或者事件集在某個(gè)特定的上下文里才有意義，因此需要維護(hù)這個(gè)上下文。可以通過(guò)模式匹配來(lái)完成，意味著查找滿足某個(gè)模式的特定事件集，或者當(dāng)事件改變某個(gè)顯式上下文或狀態(tài)時(shí)通過(guò)狀態(tài)事件處理，隨后在上下文理解事件。后一種方案很廣泛地用于網(wǎng)絡(luò)管理，這里上下文示例可能包括初始化，激活或者錯(cuò)誤。

對(duì)于更為復(fù)雜的CEP，可以使用級(jí)聯(lián)分析模型，這里的事件流包括使用某個(gè)CEP模型處理的一種或者多種類型的事件。它們并不是直接采取操作加以處理，而是生成其他事件或者事件上下文，隨后注入CEP的其他階段，直到能夠最終決定采取什么操作。

綜上所述,需要關(guān)注的點(diǎn)是：

觸發(fā)或者閾值激活處理
上下文模型
級(jí)聯(lián)分析模型

四、iBPM

iBPM 代表智能業(yè)務(wù)流程管理(Intelligent Business Process Management)。Gartner 認(rèn)為iBPM在 BPM 的基礎(chǔ)上增強(qiáng)了復(fù)雜事件處理(CEP)、智能機(jī)器人和云服務(wù)的能力，并在案例管理以及流程協(xié)調(diào)能力上更為卓越。

Gartner的Jim Sinur最早提出了“iBPM”的概念。實(shí)際上，當(dāng)業(yè)務(wù)流程管理系統(tǒng)（BPMS）與其他智能工具融合, iBPM便應(yīng)運(yùn)而生。這些智能工具包括機(jī)器學(xué)習(xí)、云服務(wù)、移動(dòng)社交、復(fù)雜事件處理(CEP)、物聯(lián)網(wǎng)集成、業(yè)務(wù)活動(dòng)監(jiān)控（BAM)。

把事件技術(shù)跟操作聯(lián)系在一起，讓分析結(jié)果跟應(yīng)用集成及有用的商業(yè)活動(dòng)關(guān)聯(lián)，這些對(duì)于業(yè)務(wù)流程管理（BPM）的實(shí)踐者來(lái)說(shuō)是重要的。

4.1 特點(diǎn)

iBPM有以下一些特點(diǎn)：

更智能的自動(dòng)化

更智能的路由，由流程機(jī)器人自動(dòng)完成流程工作；

更智能的移動(dòng)工作

云服務(wù)，支持任何地方的流程工作；

更智能實(shí)時(shí)的分析能力

復(fù)雜事件處理（CEP）能力；

4.2 iBPM與BPM的區(qū)別

BPM是以規(guī)范標(biāo)準(zhǔn)的方式對(duì)業(yè)務(wù)流程進(jìn)行建模以及執(zhí)行的一組工具，而iBPM 是BPM的智能提升。從流程發(fā)現(xiàn)、設(shè)計(jì)、建模、執(zhí)行、監(jiān)控以及分析優(yōu)化的流程全生命周期的各個(gè)階段，融合了人工智能、復(fù)雜事件處理、云服務(wù)和移動(dòng)技術(shù)。

4.3 iBPM 特點(diǎn)

根據(jù)Pega System，iBPM中的智能（i）體現(xiàn)在以下幾個(gè)方面：

動(dòng)態(tài)案例管理：

iBPM支持傳統(tǒng)的預(yù)設(shè)計(jì)劃和結(jié)構(gòu)化的BPM流程，也支持創(chuàng)建關(guān)聯(lián)知識(shí)工作者的動(dòng)態(tài)流程案例。這些動(dòng)態(tài)流程案例反映出融合社交、協(xié)作、響應(yīng)式的新型工作模式，包括異常處理。動(dòng)態(tài)案例可以由多層級(jí)的任務(wù)組成，也可以響應(yīng)或觸發(fā)事務(wù)。

社交iBPM：

iBPM在流程生命周期的各階段融入社交工具。最重要的是，iBPM提供了社交網(wǎng)絡(luò)在規(guī)則協(xié)作下的應(yīng)用場(chǎng)景。

移動(dòng)iBPM：iBPM允許組織通過(guò)移動(dòng)設(shè)備無(wú)縫啟動(dòng)和完成端到端的自動(dòng)化流程工作。流程狀態(tài)、流程工作和通過(guò)移動(dòng)流程合作的即時(shí)性使得全新的移動(dòng)工作成為可能。
云iBPM：

通過(guò)云端的iBPM平臺(tái)，可以安全建立企業(yè)應(yīng)用程序，也就是iBPM平臺(tái)即服務(wù)（PaaS）；而最終BPM解決方案構(gòu)建和部署后，iBPM成為可以在云上執(zhí)行或運(yùn)行的服務(wù):iBPM軟件即服務(wù)（SaaS）；

iBPM中的業(yè)務(wù)規(guī)則：

業(yè)務(wù)規(guī)則實(shí)現(xiàn)業(yè)務(wù)決策邏輯和業(yè)務(wù)策略，這些規(guī)則驅(qū)動(dòng)iBPM的解決方案。業(yè)務(wù)規(guī)則有許多類別和類型，如決策樹(shù)、決策表、約束和表達(dá)式。業(yè)務(wù)規(guī)則的重點(diǎn)是使業(yè)務(wù)邏輯盡可能接近業(yè)務(wù)，而不必?fù)?dān)心執(zhí)行時(shí)間、執(zhí)行方法或執(zhí)行順序。業(yè)務(wù)規(guī)則是聲明式的，可以使用預(yù)測(cè)建模技術(shù)來(lái)檢測(cè)業(yè)務(wù)模式，然后在iBPM的場(chǎng)景中調(diào)用或操作已發(fā)現(xiàn)的規(guī)則；

iBPM用于實(shí)時(shí)決策的分析和自適應(yīng)：

行業(yè)中最重要的趨勢(shì)之一是數(shù)據(jù)科學(xué)的出現(xiàn)，特別是大數(shù)據(jù)分析。預(yù)測(cè)分析可以通過(guò)解開(kāi)隱藏在大量數(shù)字信息中的規(guī)律，為組織帶來(lái)實(shí)實(shí)在在的好處。 iBPM通過(guò)預(yù)測(cè)和自適應(yīng)（自學(xué)習(xí)）分析，使得探尋某些決策具有可操作性。在iBPM中，可執(zhí)行模型中用以挖掘的數(shù)據(jù)來(lái)源和類型多種多樣，涵蓋社交網(wǎng)絡(luò)、事務(wù)數(shù)據(jù)和數(shù)據(jù)倉(cāng)庫(kù)。iBPM運(yùn)用預(yù)測(cè)和自適應(yīng)數(shù)據(jù)分析模型，在各種動(dòng)態(tài)案例交互中提供更智能化的執(zhí)行方案。

BPM解決方案是動(dòng)態(tài)的、社會(huì)化的、移動(dòng)的、規(guī)則驅(qū)動(dòng)和適應(yīng)性的。這些解決方案可以不斷地分析、學(xué)習(xí)和適應(yīng)外部事件，以及三方成員和參與者的行為。 iBPM為適應(yīng)性企業(yè)提供了平臺(tái)、解決方案、最佳實(shí)踐、方法和管理方式。

iBPM的研究和技術(shù)使得“適應(yīng)性企業(yè)”在商業(yè)環(huán)境中脫穎而出。通過(guò)智能業(yè)務(wù)流程管理，自適應(yīng)的企業(yè)不斷將其經(jīng)營(yíng)目標(biāo)的政策和業(yè)務(wù)流程完全透明，使得業(yè)務(wù)流程管理的能見(jiàn)度更高、控制力更強(qiáng)。在未來(lái)的商業(yè)環(huán)境中，適應(yīng)性企業(yè)在應(yīng)對(duì)變化時(shí)變得更靈活和主動(dòng)。畢竟，商業(yè)中唯一不變的就是改變！

五、MDM

5.1 MDM 的作用

MDM 的作用是組織如何處理公司實(shí)施其業(yè)務(wù)流程所需的主數(shù)據(jù)。

主數(shù)據(jù)管理 — 主數(shù)據(jù)管理 (MDM) 是旨在確保主數(shù)據(jù)質(zhì)量的管理活動(dòng)。其目的是保證主數(shù)據(jù)對(duì)象適用于公司所有增值流程。MDM 包括所有必要的操作和控制流程，這些流程包含質(zhì)量保證定義，并保證對(duì)主數(shù)據(jù)對(duì)象實(shí)施維護(hù)和管理。此外，MDM 還提供 IT 組件來(lái)映射這個(gè)過(guò)程。因此，MDM 起著支撐作用，并以隱含的方式從兩個(gè)方向幫助提高附加值。首先是數(shù)據(jù)質(zhì)量管理不斷提高主數(shù)據(jù)的數(shù)據(jù)質(zhì)量，從而提升信息的價(jià)值；其次是主數(shù)據(jù)對(duì)象對(duì)所有核心流程的適用性，從而通過(guò)優(yōu)化的核心流程提高附加值。

主數(shù)據(jù)對(duì)象 — 主數(shù)據(jù)對(duì)象是正式的基本業(yè)務(wù)對(duì)象，在公司內(nèi)的增值流程中使用。主數(shù)據(jù)對(duì)象描述結(jié)構(gòu)（藍(lán)圖）和質(zhì)量要求（如結(jié)構(gòu)中的驗(yàn)證、允許值）。它們與用戶交互，通常將參考數(shù)據(jù)（值列表）理解為公司的實(shí)際主數(shù)據(jù)。一個(gè)典型的例子是標(biāo)準(zhǔn)化的值列表，如 ISO 國(guó)家/地區(qū)代碼和 ISO 貨幣代碼。主數(shù)據(jù)使用這些列表作為分組、分層和分類的基礎(chǔ)。在本文中，主數(shù)據(jù)不是唯一的參考列表，但都是正式的基本業(yè)務(wù)對(duì)象。

5.2 MDM 系統(tǒng)架構(gòu)

作為業(yè)務(wù)轉(zhuǎn)型，MDM 追求的目標(biāo)是在公司范圍內(nèi)實(shí)施主數(shù)據(jù)管理。要在合理的運(yùn)營(yíng)成本下實(shí)現(xiàn)這個(gè)目標(biāo)，IT 必須支持這個(gè)過(guò)程。一方面，這適用于 MDM 本身的手動(dòng)支持流程，另一方面適用于數(shù)據(jù)處理和分發(fā)的自動(dòng)化流程。

為此，有必要建立一個(gè)清晰的、包括系統(tǒng)相互依賴關(guān)系的系統(tǒng)架構(gòu)。MDM 的系統(tǒng)架構(gòu)描述目前的形勢(shì)和計(jì)劃的目標(biāo)架構(gòu)。以下結(jié)果對(duì) MDM 發(fā)展規(guī)劃非常有意義：

針對(duì) MDM 發(fā)展規(guī)劃的 IT 總體規(guī)劃，以基礎(chǔ)架構(gòu)為重點(diǎn)

包含數(shù)據(jù)模型和數(shù)據(jù)存儲(chǔ)的主數(shù)據(jù)規(guī)劃
跨公司信息流（價(jià)值和商品的流動(dòng)）概述
運(yùn)營(yíng)流程（影響 MDM 發(fā)展規(guī)劃和支持 MDM 所需的 IT 應(yīng)用程序系統(tǒng)）的流程規(guī)劃
設(shè)計(jì)領(lǐng)域包括包含必要的 MDM 特定系統(tǒng)的應(yīng)用程序架構(gòu)、對(duì) IT 組件的支持、主數(shù)據(jù)物流的集成架構(gòu)和基礎(chǔ)系統(tǒng)架構(gòu)。檢查應(yīng)用程序系統(tǒng)和候選 MDM 以確保它們提供相應(yīng)的功能，同時(shí)用相應(yīng)的標(biāo)準(zhǔn)對(duì)其進(jìn)行評(píng)估。應(yīng)用程序和集成組件基于與基礎(chǔ)設(shè)施架構(gòu)相互獨(dú)立的基礎(chǔ)架構(gòu)平臺(tái)。信息架構(gòu)對(duì) MDM 有著特殊意義。除了跨公司信息流（價(jià)值和商品的流動(dòng)）以外，信息架構(gòu)還描述了主數(shù)據(jù)對(duì)象、關(guān)聯(lián)及其屬性。

六、ESB

6.1 定義

ESB 是一個(gè)中間件解決方案，使用面向服務(wù)的模型來(lái)促進(jìn)和支持異構(gòu)環(huán)境之間的互操作性。沒(méi)有規(guī)范準(zhǔn)確定義了什么是 ESB 或者它應(yīng)該提供什么功能。雖然 ESB 主要與“調(diào)節(jié)”和“集成”這類概念相關(guān)，但它還適合作為一個(gè)平臺(tái)以類似于應(yīng)用服務(wù)器的方式提供服務(wù)。ESB 代表被稱作“集成”和“應(yīng)用服務(wù)器”的產(chǎn)品類別的整合。

image

6.2 關(guān)鍵特性

ESB 的一個(gè)關(guān)鍵特性是服務(wù)虛擬化。本文提出的 ESB 藍(lán)圖提供了各種功能的有序排列，構(gòu)成了評(píng)估 ESB 產(chǎn)品的基礎(chǔ)。

6.3 要點(diǎn)

企業(yè)服務(wù)總線應(yīng)被視為一個(gè)架構(gòu)樣式或模式，而不是一款產(chǎn)品。
ESB 沒(méi)有定義或規(guī)范，因此也沒(méi)有標(biāo)準(zhǔn)。
ESB 可幫助實(shí)現(xiàn)系統(tǒng)間的松散耦合。
ESB 上的服務(wù)是無(wú)狀態(tài)的。長(zhǎng)期運(yùn)行的流程不屬于 ESB，但是在使用 BPEL 和 BPMN 之類語(yǔ)言的 BPM 系統(tǒng)中受支持。
“誤用”ESB 來(lái)執(zhí)行批處理時(shí)應(yīng)小心謹(jǐn)慎，因?yàn)榭赡軙?huì)對(duì)性能產(chǎn)生負(fù)面影響

更多詳情

關(guān)系說(shuō)明

1. ESP && CSP && CEP

ESP 與 CSP 之間的區(qū)別到底是什么？ESP 是流的處理，其中事件流是按時(shí)間順序排列的事件序列，如股票行情自動(dòng)收錄器。而 CEP 工作在稱為“事件云”的“云”上。事件云是來(lái)自 IT 系統(tǒng)不同部分的多個(gè)事件生成活動(dòng)的結(jié)果。事件云可能包含多個(gè)流。因此，流是云的一個(gè)特殊實(shí)例。

在流內(nèi)使用時(shí)間順序有自己的優(yōu)點(diǎn)：處理速度快，因?yàn)橹挥猩贁?shù)幾個(gè)事件需要保存在緩沖區(qū)中。但是，依賴關(guān)系在云中非常重要：發(fā)生了哪些依賴事件？或者通常更精彩的是：或許沒(méi)有發(fā)生哪些事件？

很明顯，事件流處理側(cè)重于高速處理，而 CEP 的重點(diǎn)是從事件云提取信息。在實(shí)踐中，由于 ESP 和 CEP 之間的差別變得模糊，所以更強(qiáng)大的 CEP 占據(jù)了主導(dǎo)地位。

2. SOA && EDA

SOA 標(biāo)識(shí)符是服務(wù)的松散耦合、客戶端在提供者與使用者之間發(fā)起的 1:1 通信以及同步響應(yīng)行為。EDA 的標(biāo)識(shí)符是分離的交互、n:m 通信、事件驅(qū)動(dòng)的操作和異步操作。我們認(rèn)為沒(méi)有必要確定一端或另一端。SOA 為 EDA 提供了非常堅(jiān)實(shí)的基礎(chǔ)，應(yīng)用程序可以同時(shí)采用這兩種風(fēng)格。在以下情況下，組件應(yīng)使用 SOA 調(diào)用服務(wù)：

確切知道要調(diào)用哪個(gè)服務(wù)
服務(wù)將只調(diào)用一次
期待得到關(guān)于服務(wù)完成的應(yīng)答
期待應(yīng)答
在以下情況下，組件應(yīng)使用 EDA 發(fā)布事件：

在某些情況下，通知所有相關(guān)接收方
不知道事件的相關(guān)接收方
不知道接收方如何對(duì)該事件做出反應(yīng)
不同接收方對(duì)同一事件有不同反應(yīng)
涉及從發(fā)送方到接收方的單向通信

從這方面來(lái)說(shuō)，“2 + 2 > 4”，因?yàn)檫@兩種架構(gòu)風(fēng)格的組合大于各部分之和。SOA 在執(zhí)行預(yù)定義的流程和邏輯時(shí)使用“請(qǐng)求-應(yīng)答”通信模式（可能是異步方式，請(qǐng)求與響應(yīng)之間的時(shí)間間隔比較長(zhǎng)）。相比之下，ED 應(yīng)用程序使用典型的“發(fā)布者/訂閱者”模式，在某些情況下可處理大量事件，旨在創(chuàng)建更少的新“可操作”事件。SOA 與 EDA 是相輔相成的：結(jié)合使用可以創(chuàng)建按需提供的高商業(yè)價(jià)值應(yīng)用程序

2.1 多事件航班

經(jīng)常乘飛機(jī)旅行的人都非常熟悉一個(gè)令人不快的問(wèn)題“我的行李在哪里?”在值機(jī)柜臺(tái)，旅客與行李分離。飛行結(jié)束時(shí)，旅客需要經(jīng)過(guò)一系列流程才能取回行李，包括：

辦票柜臺(tái)
安檢
行李處理
艙門操作
航班操作
機(jī)場(chǎng)運(yùn)作控制 (BAM) 儀表盤
客戶服務(wù)

最好的臨時(shí)結(jié)果是飛機(jī)按時(shí)起飛，乘客和行李都在飛機(jī)上。然而，我們很多人都知道，可能會(huì)發(fā)生許多導(dǎo)致事情變得復(fù)雜的事件。行李可能在會(huì)在辦理登記手續(xù)與登機(jī)之間丟失。乘客可能因安檢處排隊(duì)導(dǎo)致誤機(jī)。行李可能包含禁帶物品，需要搜查。航班可能取消，乘客可能改飛其他地方。乘客辦理登記手續(xù)后可能決定改簽航班。也可能發(fā)生其他復(fù)雜情況。

在這種情況下，SOA、EDA 或兩者的組合

在做決定之前，需要考慮的是：所描述的場(chǎng)景并不是單個(gè)“登機(jī)服務(wù)”或流程。而是一系列相互影響的服務(wù)/流程。交互非常復(fù)雜，取決于多個(gè)邊界條件，因此這是一個(gè)典型的“感知與響應(yīng)”場(chǎng)景，或者說(shuō)是在必要時(shí)啟動(dòng) SOA 服務(wù)的 EDA 技術(shù)。試圖將這種場(chǎng)景統(tǒng)一在一個(gè)可執(zhí)行的流程中勢(shì)必會(huì)陷入一片混亂。

1. 辦票:乘客辦理登記手續(xù)、檢查行李
2. 安檢:乘客進(jìn)入/離開(kāi)安檢區(qū)
3. 行李處理:在安檢站掃描行李、行李裝入集裝箱
4. 艙門操作:艙門打開(kāi)、登機(jī)、最后登機(jī)、關(guān)閉
5. 航班操作:登機(jī)口、裝載集裝箱、出發(fā)、起飛
6. 客戶服務(wù):新航班復(fù)查行李

3. SOA 和 MDM

SOA 的一個(gè)重要優(yōu)點(diǎn)是 IT 組件的松散耦合。這有利于組件重用，并且組件可以更輕松、更靈活地支持新功能或新流程 。

MDM 應(yīng)基于面向服務(wù)的概念，并提供通用組件（或服務(wù)）以實(shí)現(xiàn)數(shù)據(jù)維護(hù)和主數(shù)據(jù)檢索的一致性。在這里，SOA 架構(gòu)理念再次與 MDM 不謀而合。這一論斷支持了兩個(gè)不同的觀點(diǎn)：

MDM 業(yè)務(wù)服務(wù) — 用于維護(hù)和驗(yàn)證主數(shù)據(jù)的可重用業(yè)務(wù)邏輯
MDM 信息服務(wù) — 業(yè)務(wù)流程中使用的可重用信息

4. ESB && EDA && SOA

ESB連接EDA和SOA

5.iBPM && BPM && CEP

附錄：

CEP