當我在看EDA的時候（一）
知識準備
關鍵詞解釋：
- iBPM：代表智慧業務流程管理(Intelligent Business Process Management)
- SOA：面向服務的架構（SOA）是一個元件模型，它將應用程式的不同功能單元（稱為服務）通過這些服務之間定義良好的介面和契約聯絡起來。介面是採用中立的方式進行定義的，它應該獨立於實現服務的硬體平臺、作業系統和程式語言。這使得構建在各種各樣的系統中的服務可以以一種統一和通用的方式進行互動。
- CEP:複雜事件處理 (CEP) 處理同時發生的不同事件，以確定這些事件對應的操作。事件通道中的事件可以有不同的事件型別，並且可以長期發生。可以根據內容、時間或位置來關聯事件。因此，CEP 通常用於檢測異常、風險，甚至業務機會，旨在利用相比傳統報告解決方案更具現時性的資訊的優勢，最終在競爭中佔據上風。
- EDA：一個事件驅動框架（EDA）定義了一個設計和實現一個應用系統的方法學，在這個系統裡事件可傳輸於鬆散耦合的元件和服務之間。一個事件驅動系統典型地由事件消費者和事件產生者組成。事件消費者向事件管理器訂閱事件，事件產生者向事件管理器釋出事件。當事件管理器從事件產生者那接收到一個事件時，事件管理把這個事件轉送給相應的事件消費者。如果這個事件消費者是不可用的，事件管理者將保留這個事件，一段間隔之後再次轉送該事件消費者。這種事件傳送方法在基於訊息的系統裡就是:儲存（store）和轉送（forward）。
- ESP:在事件流處理 (ESP) 中，除了“相關”事件以外，“通常的”事件（如所有一般指令或 RFID 事件）也會發布到事件通道中。這對事件處理提出了更高的要求，同時也提供了更多評估選項。
- SEP:在簡單事件處理 (SEP) 中，只有“相關”事件才會被放入事件通道中進行處理。比如“XY 類別的汽車已售罄”或“冬季輪胎庫存緊張”。這非常類似於基於訊息的系統。處理邏輯評估事件型別和內容，然後相應地做出反應。
- MDM:MDM 提供通用元件（或服務）以確保資料維護和分發的一致性。
- FP
- FRP 10.RP 11.ESB:Gartner 於 2002 年創造了術語“企業服務匯流排”，分析師 Roy Schulte 進一步引入這個術語來描述當時市場上的一類軟體產品。10 年後，關於 EBS 到底是什麼或者它應該提供什麼依然沒有達成共識。根據製造商和來源的不同，有很多不同的定義。其中，ESB 的定義包括： “一種整合架構樣式，支援提供者和服務使用者之間通過由各種點對點連線構成的公共通訊匯流排進行通訊” “企業用來整合應用程式環境中服務的基礎架構。” “一種架構模式，使用面向服務支援異構環境之間的互操作性。”
一、EDA
1.1 EDA定義
Gartner在2003年引入了一個新術語事件驅動架構（Event Driven Architecture，EDA), 主要用於描述一種基於事件的範例。EDA 是一種用於進行設計和實現應用和系統的方法—在這些應用和系統裡, 事件所觸發的訊息可以在獨立的、非耦合的元件和服務之間傳遞，這些模組彼此並不知曉對方。這些應用程式中的EDA極大地改進了企業或政府響應不同的、表面上毫無關聯事件的能力。通過提供瞬時過濾、聚合和關聯事件的能力，EDA可以快速地檢測出事件並判斷它的型別，從而幫助組織機構快速、恰當地響應和處理這些事件。通常事件可以採用釋出/訂閱機制。
1.2 事件驅動架構概述
一個事件驅動框架（EDA）定義了一個設計和實現一個應用系統的方法學，在這個系統裡事件可傳輸於鬆散耦合的元件和服務之間。一個事件驅動系統典型地由事件消費者和事件產生者組成。事件消費者向事件管理器訂閱事件，事件產生者向事件管理器釋出事件。當事件管理器從事件產生者那接收到一個事件時，事件管理把這個事件轉送給相應的事件消費者。如果這個事件消費者是不可用的，事件管理者將保留這個事件，一段間隔之後再次轉送該事件消費者。這種事件傳送方法在基於訊息的系統裡就是:儲存（store）和轉送（forward）。
構建一個包含事件驅動構架的應用程式和系統，會使這些應用程式和系統響應更靈敏，因為事件驅動的系統更適合應用在不可預知的和非同步的環境裡。
事件驅動架構在具體實現中是指由一系列相關元件構成的應用，而元件之間通過事件機制完成一定的業務功能。由於在一個EDA系統中各個元件都只專注於處理輸入的訊息與釋出輸出的訊息，因而EDA系統能夠更有加效地對管道化（pipelined）的、由多軟體模組連結而成的併發事件流（concurrent processing of events）進行處理。
1.3 EDA特點
EDA系統中各元件以非同步方式響應事件，在本質上是可以並行的，因而在政府部門的電子政務應用中具有極大的優勢。其具備以下特點:
◆ 併發執行
◆ 事件觸發/資料觸發/時間規則觸發
◆ 實時/增量響應
◆ 分散式事件系統處理
複製程式碼上述特點能很好地滿足政府部門應用需求，如跨部門的應急聯動系統或聯合監管協同服務等應用。
從目前情況來看，EDA系統還只是處理簡單事件的系統，對於複雜事件的處理還有待進一步的研究。但是，EDA仍然能作為SOA系統的一個有效補充，彌補SOA系統的一些不足，如實時響應度不夠。
1.4 事件驅動架構優勢
事件驅動設計和開發所提供的優勢如下所示:
◆ EDA提高了對不斷變化的業務需求的響應，最大限度地減少了對現有業務應用的影響，也常消除了對新打包應用的需要。如果採用特有的粗顆粒服務模型可以基於業務目標快速確定可控的業務變更，並直接、迅速、有效地實施變更以達到業務敏捷性和完整性。
◆ 可以更容易開發和維護大規模分散式應用程式和不可預知的服務或非同步服務;
◆ 可以很容易，低成本地整合、再整合、再配置新的和已存在的應用程式和服務。
◆ 促進遠端元件和服務的再使用，擁有一個更靈敏、沒有Bug的開發環境。
從時間維度來看EDA的優勢:
◆ 短期利益:更容易定製，因為設計對動態處理有更好的響應;
◆ 長期利益:系統和組織的狀態變得更精準，對實時變化的響應接近於同步。
1.5 EDA和SOA之間的關係：
SOA和EDA是平等和互補的。所以，我不認同那些努力傳播SOA的同學們所說的“EDA只是SOA的一個子集”的論斷。一個更廣泛的事件驅動架構概念，不僅是超越事件驅動SOA的，還應該包括實時資訊流和分析，以及複雜事件處理。
當EDA認為事件是系統中最重要的組成時，你最好注意那些元件或者服務，以及元件之間的‘通道’”
與Request/Response系統不同的是，要求請求者必須明確傳送請求資訊，而事件驅動架構提供一個機制去動態響應事件。在一個EDA系統裡，事件產生者釋出事件，事件消費者接受事件。
業務系統可以從SOA和EDA中受益匪淺，因為事件發生時EDA系統能觸發事件消費者，SOA服務可以快速地從相同的消費者中訪問、查詢。系統要求有最高的響應性，當事件被觸發時這個系統必須能快速決定必須的動作。到事件結束，事件應該被髮布和消費，而且事件要穿越SOA所有的邊界，包括整個體系結構和物理層。
系統要有最高的響應性，當事件觸發時這個系統必須能快速決定必須的動作。到事件結束，事件應該被髮布和消費，而且事件要穿越SOA所有的邊界，包括整個體系結構和物理層。
1.6 ESB連線EDA和SOA
企業服務匯流排(Enterprise Service Bus，ESB)在異類平臺和環境間建立聯絡，充當允許不同應用程式程序之間進行通訊的中間層。部署到企業服務匯流排的服務可以由使用者或事件觸發。它同時支援同步方式和非同步方式，可促進一個或多個參與者之間的互動。因此 ESB 可提供 SOA 和 EDA 範例的所有功能。“ESB提供了訊息的傳輸，格式的轉換等關鍵功能，為服務的請求者和服務提供者之間架設了溝通的橋樑，是企業應用基礎架構的粘合劑。” 甲骨文公司大中華區高階技術經理黃建勇說。
企業服務匯流排可連線各個異類節點並作為中介傳遞其間的所有通訊和互動，這些節點可分散在面向服務的體系結構(同步一對一方法)和事件驅動的體系結構(非同步多對多方法)中。ESB 是目前處理整合挑戰的最有效方法，是可提供最大業務靈活性和不同應用程式間的高效連線技術解決方案。
EDA應用在很多ESB（企業服務匯流排）產品中，比如FiornaoESB中介軟體產品支援同步、非同步和請求響應事件，事件處理和傳輸實用不同的技術例如JMS，HTTP，電子郵件和基於XML的RPC等。比如“政府網上監察系統”通過對被監察物件（系統）資料的實時採集，通過EDA技術的事件觸發，事件過濾，實現對違規、違法、越權行政、超時限行政等問題進行通知和督辦等。
1.7 EDA應用方向
事件驅動架構(EDA)是分散式應用程式的普遍架構形式，非常典型的是:分散式應用程式都被設計成為模組化的、封裝的、可共享事件服務的元件。能夠通過應用程式、介面卡以及無入侵性的代理操作來建立這些服務。
由於EDA的特點，在金融貿易、能源貿易、電信以及欺詐檢測這些行業中，一直都在採用事件驅動架構(EDA)技術。近期在我國政府的電子政務建設中
利用EDA分散式處理架構的優勢構建共享交換平臺，實現跨部門、跨平臺、跨應用系統的政務資訊資源的共享與交換，並對政府應急系統和跨委辦局之間的業務協同辦公提供支撐和保障。
二、響應式程式設計和響應式系統（EP&&ERP）
響應式技術目前成功的標誌之一是“響應式reactive”成為了一個熱詞，並且跟一些不同的事物與人聯絡在了一起——常常伴隨著像“流streaming”、“輕量級lightweight”和“實時real-time”這樣的詞。
2.1 FRP
2.2 響應式程式設計Reactive programming，
不要把它跟函式響應式程式設計混淆了，它是非同步程式設計下的一個子集，也是一種正規化，在這種正規化下，由新資訊的有效性availability推動邏輯的前進，而不是讓一條執行執行緒a thread-of-execution去推動控制流control flow。
響應式程式設計一般是事件驅動event-driven，相比之下，響應式系統則是訊息驅動message-driven的
響應式程式設計的基本好處是：提高多核和多 CPU 硬體的計算資源利用率；根據阿姆達爾定律以及引申的 Günther 的通用可伸縮性定律Günther’s Universal Scalability Law 腳註3 ，通過減少序列化點serialization points來提高效能。
另一個好處是開發者生產效率，傳統的程式設計正規化都盡力想提供一個簡單直接的可持續的方法來處理非同步非阻塞式計算和 I/O。在響應式程式設計中，因活動(active)元件之間通常不需要明確的協作，從而也就解決了其中大部分的挑戰。
響應式程式設計真正的發光點在於元件的建立跟工作流的組合。為了在非同步執行上取得最大的優勢，把 反壓back-pressure加進來是很重要，這樣能避免過度使用，或者確切地說，避免無限度的消耗資源。
2.4 事件驅動 && 訊息驅動
響應式程式設計——專注於短時間的資料流鏈條上的計算——因此傾向於事件驅動，而響應式系統——關注於通過分散式系統的通訊和協作所得到的彈性和韌性——則是訊息驅動的 腳註4 （或者稱之為 訊息式messaging 的）。
一個擁有長期存活的可定址long-lived addressable元件的訊息驅動系統跟一個事件驅動的資料流驅動模型的不同在於，訊息具有固定的導向，而事件則沒有。訊息會有明確的（一個）去向，而事件則只是一段等著被觀察observe的資訊。另外，訊息式messaging更適用於非同步，因為訊息的傳送與接收和傳送者和接收者是分離的。
一條訊息就是一則被送往一個明確目的地的資料。一個事件則是達到某個給定狀態的元件發出的一個訊號。在一個訊息驅動系統中，可定址到的接收者等待訊息的到來然後響應它，否則保持休眠狀態。在一個事件驅動系統中，通知的監聽者被繫結到訊息源上，這樣當訊息被髮出時它就會被呼叫。這意味著一個事件驅動系統專注於可定址的事件源而訊息驅動系統專注於可定址的接收者。
2.5 響應式系統
響應式系統的基石是訊息傳遞message-passing，訊息傳遞為兩個元件之間建立一條暫時的邊界，使得它們能夠在 時間 上分離——實現併發性——和 空間space ——實現分散式distribution與移動性mobility。這種分離是兩個元件完全 隔離isolation以及實現 彈性resilience和 韌性elasticity基礎的必需條件。
2.6 響應式系統&&響應式程式設計
響應式程式設計是一種管理內部邏輯internal logic和資料流轉換dataflow transformation的好技術，在本地的元件中，做為一種優化程式碼清晰度、效能以及資源利用率的方法。響應式系統，是一組架構上的原則，旨在強調分散式資訊交流併為我們提供一種處理分散式系統彈性與韌性的工具。
響應式程式設計是一個非常有用的實現技術，可以用在響應式架構當中。但是記住這隻能幫助管理一部分：非同步且非阻塞執行下的資料流管理——通常只在單個結點或服務中。當有多個結點時，就需要開始認真地考慮像資料一致性data consistency、跨結點溝通cross-node communication、協調coordination、版本控制versioning、編制orchestration、錯誤管理failure management、關注與責任concerns and responsibilities分離等等的東西——也即是：系統架構。
三、CEP
3.1 關鍵概念
事件指在業務裡發生的事情，包括業務活動、流程狀態、網路或IT條件，或者其他任何東西。很多事件只要能夠識別出來就可以進行處理，通常會伴隨著傳送警報。當無法可靠處理單個事件而必須在上下文裡分析時，就會使用CEP。幾乎所有場景裡，CEP分析都要求事件能夠實時關聯，並且要求帶有準確時間戳的一定格式。
CEP應用大致分為兩大類：事件關聯和根本原因分析。通常來說，事件關聯用來識別不是單個事件，而是多個事件組合起來觸發的條件.
比如“如果你打噴嚏並且發燒了，那麼你感冒了。”根本原因分析用來解釋一系列事件—通常是錯誤—的底層原因，確保補救措施並不僅僅針對症狀，而是能夠真正解決問題。
所有CEP都應該是實時的，或者和事件同時發生，但是，當然這裡的同時發生意味著很多種情況。CEP處理的關係越複雜，就越難保證實時性。
3.2 從事件驅動程式設計（Event-driven Programming)開始
如果你寫過GUI程式，對事件處理一定不陌生。事實上，事件驅動程式設計已經成為一種設計模式。大多數的GUI庫都會採用這一模式。
簡單的說，事件驅動模式包括三個參與者：事件產生者，事件分發器和事件處理器。
-
事件產生者（Events Generator）決定是否需要產生事件。比如，GUI上的每個元件都是一個事件產生者，可以根據使用者操作產生滑鼠事件或者鍵盤事件。
-
事件分發器（Events Dispatcher）收集所有事件產生者發出的事件放入事件佇列(Events Queue)，並根據事件的型別將事件分發給已經註冊的事件處理器。事件分發器通常由GUI框架實現。
-
事件處理器（Events Handler)根據接收到的事件進行處理，需要GUI框架的使用者自行編寫。
事件驅動程式設計的核心價值在於：程式的執行流程不是預先定義好的，而是由程式的使用者決定的。這將極大增強程式的互動性。
就好像DVD與RPG遊戲的區別：前者的劇情是設定好的，你只能進行開始、暫停、快進、回退等有限的互動；後者可以決定主角的行為從而影響故事的結局。
3.3 事件驅動業務（Event-driven Business)
程式碼的世界不可能是現實世界的完整映象，但一定是對現實世界的某種抽象，這種抽象能夠簡化程式碼世界中對問題的分析和處理。 同時，這種抽象還可以反向對映到現實世界，為我們解決現實問題提供思路。
現代企業生存的外部環境處於劇烈的變化之中，“敏捷企業”已經成為生存之道，而事件驅動業務是敏捷企業的一個基本要求。
事件驅動業務（Event-driven Business)，是在連續 的業務過程中進行決策的一種業務管理方式，即根據不同時點上出現的一系列事件觸發相關的任務，並排程可用的資源執行任務。 如果說事件驅動程式設計能夠為軟體帶來更靈活的互動性和強大的功能，那麼企業中的事件驅動業務能夠大幅度提高業務的效率和靈活性。
事件驅動業務依託於比較成熟的資訊化建設。各個業務應用系統在產生連續不斷的資料流的同時，根據定義好的條件產生一些業務事件，按照策略對這些業務事件進行分析處理，觸發新的業務事件或者業務流程，即實現了業務的事件驅動。
從上面的描述可以看出，事件驅動業務要求能夠快速（毫秒級）、不間斷的處理連續、海量的資料，具備靈活的規則或策略設定，從而具備迅速識別、捕獲、響應實時業務資料的能力。 而傳統的企業IT架構通常採用：
在業務應用系統中處理業務操作 遵循固定的業務流程（Business Process）處理跨系統事務，並且這些流程很少變化基於資料倉庫進行海量資料的儲存及事後分析 這種IT架構遠遠達不到事件驅動業務的要求。
事件驅動業務能夠應用的業務領域很多，凡是需要快速處理連續性數據、需要能夠靈活制定策略的業務，都可以採用事件驅動的業務模式。如證券行業常見的風險分析預警（事前及事中風控）、投資決策（程式化交易）、經紀人績效計算等。
3.2.1 業務事件處理的幾個層次
其實在傳統的IT架構中，我們已經實現了業務事件的處理。比如在傳統的業務應用系統中，我們通常將業務資料儲存在資料庫中，通過應用系統的操作介面由人工發現和處理業務事件。
這樣的處理方式存在兩個不足，一是速度慢，二是對於複雜的情況只靠人腦難以處理。於是有了兩個技術方向：
訊息佇列（MQ） 對於速度慢的解決辦法是用機器代替人工，為了在多個系統之間傳遞訊息，發展出了訊息佇列（MQ）的技術 商業智慧（BI） 為了應對複雜性，通過資料倉庫將資料整合到一起，並用專門的工具在資料模型的基礎上進行分析 但是上述兩個方向是正交的：MQ不適合處理複雜性，而BI主要適應於對結構化的歷史資料的分析，無法處理“現在”的情況。
3.4 CEP：魚與熊掌可以兼得
CEP（Complex Event Processing）的出現解決了上述兩個方面的問題，在實時性和複雜性方面都得到了很好的解決。
3.4.1 處理資料流
不管是單獨的應用系統，還是資料倉庫，都是先將資料儲存到資料庫/資料倉庫，然後再處理或查詢。 而CEP與MQ類似的將資料看作是資料流 。在連續資料的快速移動過程中進行分析處理。 這樣的方式不需要很大的資料載入，完全可以在記憶體中進行，從而能夠快速產生結果。
3.4.2 處理複雜性
業務事件可能很複雜，在各種不同的資料流中源源不斷產生各種型別的事件。需要對這些業務事件進行復雜的計算，如過濾、關聯、聚合等，同時還需要考慮這些也是事件出現的時間序列。 最終才能產生有意義的事件，或觸發業務流程。同時，這些計算的規則可能還會經常變化。
這一類的問題通常通過基於規則的推理機（即規則引擎）來實現。
綜上所述，CEP在邏輯上應該包括：
- 事件發生器 通過應用系統、檔案系統、資料庫、網際網路、人工、以及感測器產生事件
- 事件處理器 模式的匹配、驗證和改進，路由，轉換以及編排
- 事件消費者 與事件發生器類似，也可以是應用系統、檔案系統、資料庫、網際網路、人工介面等
3.5 CEP的三個基本模型及其特性，以及CEP的限制
CEP的最簡單方案是觸發或者閾值啟用處理。該模型裡，事件要麼直接導致一些操作的發生，要麼是當事件達到某個閾值時會執行某個操作。CEP能夠在從源到目的地的事件流裡引入事件處理，比如線上事務處理，因為生成的延時很小。雖然觸發或閾值CEP能夠通過單個型別事件實現，但是也可以使用多個不同權重的不同事件來提供對條件更為深入的理解。
第二種模型是上下文模型，該模型假定一個事件或者事件集在某個特定的上下文裡才有意義，因此需要維護這個上下文。可以通過模式匹配來完成，意味著查詢滿足某個模式的特定事件集，或者當事件改變某個顯式上下文或狀態時通過狀態事件處理，隨後在上下文理解事件。後一種方案很廣泛地用於網路管理，這裡上下文示例可能包括初始化，啟用或者錯誤。
對於更為複雜的CEP，可以使用級聯分析模型，這裡的事件流包括使用某個CEP模型處理的一種或者多種型別的事件。它們並不是直接採取操作加以處理，而是生成其他事件或者事件上下文，隨後注入CEP的其他階段，直到能夠最終決定採取什麼操作。
綜上所述,需要關注的點是：
- 觸發或者閾值啟用處理
- 上下文模型
- 級聯分析模型
四、iBPM
iBPM 代表智慧業務流程管理(Intelligent Business Process Management)。Gartner 認為iBPM在 BPM 的基礎上增強了複雜事件處理(CEP)、智慧機器人和雲服務的能力，並在案例管理以及流程協調能力上更為卓越。
Gartner的Jim Sinur最早提出了“iBPM”的概念。實際上，當業務流程管理系統（BPMS）與其他智慧工具融合, iBPM便應運而生。這些智慧工具包括機器學習、雲服務、移動社交、複雜事件處理(CEP)、物聯網整合、業務活動監控（BAM)。
把事件技術跟操作聯絡在一起，讓分析結果跟應用整合及有用的商業活動關聯，這些對於業務流程管理（BPM）的實踐者來說是重要的。
4.1 特點
iBPM有以下一些特點：
- 更智慧的自動化
更智慧的路由，由流程機器人自動完成流程工作；
- 更智慧的移動工作
雲服務，支援任何地方的流程工作；
- 更智慧實時的分析能力
複雜事件處理（CEP）能力；
4.2 iBPM與BPM的區別
BPM是以規範標準的方式對業務流程進行建模以及執行的一組工具，而iBPM 是BPM的智慧提升。從流程發現、設計、建模、 執行、監控以及分析優化的流程全生命週期的各個階段，融合了人工智慧、複雜事件處理、雲服務和移動技術。
4.3 iBPM 特點
根據Pega System，iBPM中的智慧（i）體現在以下幾個方面：
- 動態案例管理：
iBPM支援傳統的預設計劃和結構化的BPM流程，也支援建立關聯知識工作者的動態流程案例。這些動態流程案例反映出融合社交、協作、響應式的新型工作模式，包括異常處理。動態案例可以由多層級的任務組成，也可以響應或觸發事務。
- 社交iBPM：
iBPM在流程生命週期的各階段融入社交工具。最重要的是，iBPM提供了社交網路在規則協作下的應用場景。
-
移動iBPM：iBPM允許組織通過移動裝置無縫啟動和完成端到端的自動化流程工作。流程狀態、流程工作和通過移動流程合作的即時性使得全新的移動工作成為可能。
-
雲iBPM：
通過雲端的iBPM平臺，可以安全建立企業應用程式，也就是iBPM平臺即服務（PaaS）； 而最終BPM解決方案構建和部署後，iBPM成為可以在雲上執行或執行的服務:iBPM軟體即服務（SaaS）；
- iBPM中的業務規則：
業務規則實現業務決策邏輯和業務策略，這些規則驅動iBPM的解決方案。業務規則有許多類別和型別，如決策樹、決策表、約束和表示式。業務規則的重點是使業務邏輯儘可能接近業務，而不必擔心執行時間、執行方法或執行順序。業務規則是宣告式的，可以使用預測建模技術來檢測業務模式，然後在iBPM的場景中呼叫或操作已發現的規則；
- iBPM用於實時決策的分析和自適應：
行業中最重要的趨勢之一是資料科學的出現，特別是大資料分析。預測分析可以通過解開隱藏在大量數字資訊中的規律，為組織帶來實實在在的好處。 iBPM通過預測和自適應（自學習）分析，使得探尋某些決策具有可操作性。在iBPM中，可執行模型中用以挖掘的資料來源和型別多種多樣，涵蓋社交網路、事務資料和資料倉庫。iBPM運用預測和自適應資料分析模型，在各種動態案例互動中提供更智慧化的執行方案。
BPM解決方案是動態的、社會化的、移動的、規則驅動和適應性的。這些解決方案可以不斷地分析、學習和適應外部事件，以及三方成員和參與者的行為。 iBPM為適應性企業提供了平臺、解決方案、最佳實踐、方法和管理方式。
iBPM的研究和技術使得“適應性企業”在商業環境中脫穎而出。通過智慧業務流程管理，自適應的企業不斷將其經營目標的政策和業務流程完全透明，使得業務流程管理的能見度更高、控制力更強。在未來的商業環境中，適應性企業在應對變化時變得更靈活和主動。畢竟，商業中唯一不變的就是改變！
五、MDM
5.1 MDM 的作用
MDM 的作用是組織如何處理公司實施其業務流程所需的主資料。
主資料管理 — 主資料管理 (MDM) 是旨在確保主資料質量的管理活動。其目的是保證主資料物件適用於公司所有增值流程。MDM 包括所有必要的操作和控制流程，這些流程包含質量保證定義，並保證對主資料物件實施維護和管理。此外，MDM 還提供 IT 元件來對映這個過程。因此，MDM 起著支撐作用，並以隱含的方式從兩個方向幫助提高附加值。首先是資料質量管理不斷提高主資料的資料質量，從而提升資訊的價值；其次是主資料物件對所有核心流程的適用性，從而通過優化的核心流程提高附加值。
主資料物件 — 主資料物件是正式的基本業務物件，在公司內的增值流程中使用。主資料物件描述結構（藍圖）和質量要求（如結構中的驗證、允許值）。它們與使用者互動，通常將參考資料（值列表）理解為公司的實際主資料。一個典型的例子是標準化的值列表，如 ISO 國家/地區程式碼和 ISO 貨幣程式碼。主資料使用這些列表作為分組、分層和分類的基礎。在本文中，主資料不是唯一的參考列表，但都是正式的基本業務物件。
5.2 MDM 系統架構
作為業務轉型，MDM 追求的目標是在公司範圍內實施主資料管理。要在合理的運營成本下實現這個目標，IT 必須支援這個過程。一方面，這適用於 MDM 本身的手動支援流程，另一方面適用於資料處理和分發的自動化流程。
為此，有必要建立一個清晰的、包括系統相互依賴關係的系統架構。MDM 的系統架構描述目前的形勢和計劃的目標架構。以下結果對 MDM 發展規劃非常有意義：
針對 MDM 發展規劃的 IT 總體規劃，以基礎架構為重點
包含資料模型和資料儲存的主資料規劃
跨公司資訊流（價值和商品的流動）概述
運營流程（影響 MDM 發展規劃和支援 MDM 所需的 IT 應用程式系統）的流程規劃
設計領域包括包含必要的 MDM 特定系統的應用程式架構、對 IT 元件的支援、主資料物流的整合架構和基礎系統架構。檢查應用程式系統和候選 MDM 以確保它們提供相應的功能，同時用相應的標準對其進行評估。應用程式和整合元件基於與基礎設施架構相互獨立的基礎架構平臺。資訊架構對 MDM 有著特殊意義。除了跨公司資訊流（價值和商品的流動）以外，資訊架構還描述了主資料物件、關聯及其屬性。
複製程式碼六、ESB
6.1 定義
ESB 是一箇中間件解決方案，使用面向服務的模型來促進和支援異構環境之間的互操作性。沒有規範準確定義了什麼是 ESB 或者它應該提供什麼功能。雖然 ESB 主要與“調節”和“整合”這類概念相關，但它還適合作為一個平臺以類似於應用伺服器的方式提供服務。ESB 代表被稱作“整合”和“應用伺服器”的產品類別的整合。
6.2 關鍵特性
ESB 的一個關鍵特性是服務虛擬化。本文提出的 ESB 藍圖提供了各種功能的有序排列，構成了評估 ESB 產品的基礎。
6.3 要點
企業服務匯流排應被視為一個架構樣式或模式，而不是一款產品。 ESB 沒有定義或規範，因此也沒有標準。 ESB 可幫助實現系統間的鬆散耦合。 ESB 上的服務是無狀態的。長期執行的流程不屬於 ESB，但是在使用 BPEL 和 BPMN 之類語言的 BPM 系統中受支援。 “誤用”ESB 來執行批處理時應小心謹慎，因為可能會對效能產生負面影響
關係說明
1. ESP && CSP && CEP
ESP 與 CSP 之間的區別到底是什麼？ESP 是流的處理，其中事件流是按時間順序排列的事件序列，如股票行情自動收錄器。而 CEP 工作在稱為“事件雲”的“雲”上。事件雲是來自 IT 系統不同部分的多個事件生成活動的結果。事件雲可能包含多個流。因此，流是雲的一個特殊例項。
在流內使用時間順序有自己的優點：處理速度快，因為只有少數幾個事件需要儲存在緩衝區中。但是，依賴關係在雲中非常重要：發生了哪些依賴事件？或者通常更精彩的是：或許沒有發生哪些事件？
很明顯，事件流處理側重於高速處理，而 CEP 的重點是從事件雲提取資訊。在實踐中，由於 ESP 和 CEP 之間的差別變得模糊，所以更強大的 CEP 佔據了主導地位。
2. SOA && EDA
SOA 識別符號是服務的鬆散耦合、客戶端在提供者與使用者之間發起的 1:1 通訊以及同步響應行為。EDA 的識別符號是分離的互動、n:m 通訊、事件驅動的操作和非同步操作。我們認為沒有必要確定一端或另一端。SOA 為 EDA 提供了非常堅實的基礎，應用程式可以同時採用這兩種風格。在以下情況下，元件應使用 SOA 呼叫服務：
確切知道要呼叫哪個服務
服務將只調用一次
期待得到關於服務完成的應答
期待應答
在以下情況下，元件應使用 EDA 釋出事件：
複製程式碼在某些情況下，通知所有相關接收方
不知道事件的相關接收方
不知道接收方如何對該事件做出反應
不同接收方對同一事件有不同反應
涉及從傳送方到接收方的單向通訊
複製程式碼從這方面來說，“2 + 2 > 4”，因為這兩種架構風格的組合大於各部分之和。SOA 在執行預定義的流程和邏輯時使用“請求-應答”通訊模式（可能是非同步方式，請求與響應之間的時間間隔比較長）。相比之下，ED 應用程式使用典型的“釋出者/訂閱者”模式，在某些情況下可處理大量事件，旨在建立更少的新“可操作”事件。SOA 與 EDA 是相輔相成的：結合使用可以建立按需提供的高商業價值應用程式
2.1 多事件航班
經常乘飛機旅行的人都非常熟悉一個令人不快的問題“我的行李在哪裡?”在值機櫃臺，旅客與行李分離。飛行結束時，旅客需要經過一系列流程才能取回行李，包括：
辦票櫃檯
安檢
行李處理
艙門操作
航班操作
機場運作控制 (BAM) 儀表盤
客戶服務
複製程式碼最好的臨時結果是飛機按時起飛，乘客和行李都在飛機上。然而，我們很多人都知道，可能會發生許多導致事情變得複雜的事件。行李可能在會在辦理登記手續與登機之間丟失。乘客可能因安檢處排隊導致誤機。行李可能包含禁帶物品，需要搜查。航班可能取消，乘客可能改飛其他地方。乘客辦理登記手續後可能決定改簽航班。也可能發生其他複雜情況。
在這種情況下，SOA、EDA 或兩者的組合
在做決定之前，需要考慮的是：所描述的場景並不是單個“登機服務”或流程。而是一系列相互影響的服務/流程。互動非常複雜，取決於多個邊界條件，因此這是一個典型的“感知與響應”場景，或者說是在必要時啟動 SOA 服務的 EDA 技術。試圖將這種場景統一在一個可執行的流程中勢必會陷入一片混亂。
1. 辦票:乘客辦理登記手續、檢查行李
2. 安檢:乘客進入/離開安檢區
3. 行李處理:在安檢站掃描行李、行李裝入集裝箱
4. 艙門操作:艙門開啟、登機、最後登機、關閉
5. 航班操作:登機口、裝載集裝箱、出發、起飛
6. 客戶服務:新航班複查行李
複製程式碼3. SOA 和 MDM
SOA 的一個重要優點是 IT 元件的鬆散耦合。這有利於元件重用，並且元件可以更輕鬆、更靈活地支援新功能或新流程 。
MDM 應基於面向服務的概念，並提供通用元件（或服務）以實現資料維護和主資料檢索的一致性。在這裡，SOA 架構理念再次與 MDM 不謀而合。這一論斷支援了兩個不同的觀點：
MDM 業務服務 — 用於維護和驗證主資料的可重用業務邏輯
MDM 資訊服務 — 業務流程中使用的可重用資訊
複製程式碼4. ESB && EDA && SOA
ESB連線EDA和SOA
企業服務匯流排(Enterprise Service Bus，ESB)在異類平臺和環境間建立聯絡，充當允許不同應用程式程序之間進行通訊的中間層。部署到企業服務匯流排的服務可以由使用者或事件觸發。它同時支援同步方式和非同步方式，可促進一個或多個參與者之間的互動。因此 ESB 可提供 SOA 和 EDA 範例的所有功能。“ESB提供了訊息的傳輸，格式的轉換等關鍵功能，為服務的請求者和服務提供者之間架設了溝通的橋樑，是企業應用基礎架構的粘合劑。” 甲骨文公司大中華區高階技術經理黃建勇說。
企業服務匯流排可連線各個異類節點並作為中介傳遞其間的所有通訊和互動，這些節點可分散在面向服務的體系結構(同步一對一方法)和事件驅動的體系結構(非同步多對多方法)中。ESB 是目前處理整合挑戰的最有效方法，是可提供最大業務靈活性和不同應用程式間的高效連線技術解決方案。
EDA應用在很多ESB（企業服務匯流排）產品中，比如FiornaoESB中介軟體產品支援同步、非同步和請求響應事件，事件處理和傳輸實用不同的技術例如JMS，HTTP，電子郵件和基於XML的RPC等。比如“政府網上監察系統”通過對被監察物件（系統）資料的實時採集，通過EDA技術的事件觸發，事件過濾，實現對違規、違法、越權行政、超時限行政等問題進行通知和督辦等。
5.iBPM && BPM && CEP
BPM是以規範標準的方式對業務流程進行建模以及執行的一組工具，而iBPM 是BPM的智慧提升。從流程發現、設計、建模、 執行、監控以及分析優化的流程全生命週期的各個階段，融合了人工智慧、複雜事件處理、雲服務和移動技術。
把事件技術跟操作聯絡在一起，讓分析結果跟應用整合及有用的商業活動關聯，這些對於業務流程管理（BPM）的實踐者來說是重要的。
附錄：
CEP
倉庫：
參考：
Company
- tibco
- Gartner