第二部分：動態業務應用構建實踐——兩個自適應系統的故事
生產力提高是生活水平提高的基本組成。美國的經驗表明，長期的生產力強勁增長表現為伴隨組織結構和企業資金安排變化的技術革新，以及人力資本的投
入。但是，支撐這些生產力增長的決定因素的是一個更基本的因素：社會對其自身進行重大轉變的意志，以及對技術進步和隨那個進步而來的經濟機會將使人們改善
其生活的信心。
–Roger W. Ferguson Jr.和William L. Wascher，美國經濟學會在政府中做的經濟專題演講：過去生產力大爆炸的教訓，《經濟學展望雜志》，2004年春季18卷，第2期
“一旦著手自動化這些[企業]流程，技術實現大約占10%，其余90%都是變更和流程管理”
–Mark Evans，Tesoro Petroleum的CIO，管理自動化，2004年3月
第一部分總結
在本文的第一部分，
我們介紹了一種構建新型IT系統的企業架構，我們稱之為動態業務架構（DBA）。這些DBA非常適合支持具有動態操作（包含最新業務的一個分類）的企業。
第一部分還指出，用例是當前系統架構和設計的基本輸入，并描述了依賴通過它收集的需求對當前企業架構方法的種種制約。這一新提出的新框架使用企業事件模型
作為起點，并將企業視為一個具有清晰信息架構的自適應系統。以新的自適應系統和信息理論為基礎，在基礎層級，該框架同時捕捉企業流程和業務變更。用例僅在
設計過程的后期作為一種需求細化方法被引入。這種框架優先的方式受到了傳統工程方法學的啟發，但針對像企業這樣的自適應系統進行了修改。
介紹
告別手工作坊并向軟件工程加入正確工程技術的時候到了。這是將復雜軟件應用（尤其是在企業領域中）構建成高度可靠、易于改變和方便調試的公共標準的
唯一方法。選擇并執行正確的系統架構是使這種方法發揮作用的最重要因素。我們建議的解決方案使得圍繞唯一一個系統架構進行標準化（不考慮軟件應用）并避免
成本高昂的重新構架成為可能。
正如本文第一部分提到的，構架軟件應用和設計其它工程產品之間有一個根本性的區別。因為軟件是和信息打交道，而信息是變更的“載體”，那么必須在最
基礎的級別將變更構建到信息架構之中。此外，業務操作變更的方式和技術團體將變更引入系統的方式走得是完全不同的路徑。它們各自都是對變更反應不同并具有
不同操作的組織（一個是業務和一個是技術）。在構架過程中，可以把這兩個組織作為兩個不同的自適應系統對待。這正是我們選擇“兩個自適應系統的故事”作為
本文第二部分副標題的原因。
在設計企業應用的過程中涉及兩個自適應系統。
本文第一部分提到，能成功應對構建DBA復雜性的唯一方法是使用架構先行的方法論。幾個世紀以來，工程師們一直在使用這種方法論——但總是設計“靜
態”架構。一旦要應用變更，系統極可能必須先停止工作再進行修改。例如，要改變由裝配線組裝的產品必須先停止裝配線，然后應用變更，最后重新啟動裝配線。
當今為業務構建IT系統的軟件工程師們很可能就是遵循的同樣套路。當業務變化提出了修改應用的需求時，它很可能就觸發了一個成本高昂的升級。開發者
必須從頭開始一個新業務需求，并且舊的設計常常經受大量的重新構架。這種升級周期可能需要幾個月。如果企業應用是由外部開發商按照自己的日程構建的，那么
整個過程可能耗時更長而且結果可能達不到業務預期。Mark Evans說得好，超過90%的努力只直接和應用變更相關。
籍由新的自適應系統理論和它們信息架構（參見局外人觀點）的幫助，我們建議的企業應用設計解決方案引入了兩個互補但唯一的框架。這兩個框架讓我們可
以有效地處理和協調業務操作和技術團體操作中的變更。對設計過程而言，業務操作和技術團體操作可以被視為兩個截然不同的自適應系統，它們各自都有自己的需
求。
業務操作可由基礎動態業務平臺的通用概念來表示。根據自適應系統理論，任何企業業務功能均有3類基礎流程。主流程類型支持正常操作，而其他兩個則負
責引入變化：內部決策制訂流程處理管理和其他企業變更決策；業務環境變更流程處理客戶決策和變更的其他外部來源。因此，我們提出的業務流程框架（基本動態
業務平臺）是圍繞著業務操作或價值循環構建起來的，它包含的兩類變更由兩個不同的變更管理平臺來處理。從信息處理觀點來看，實現這些操作的系統可以比作圍
繞事件模型構建的“信息裝配線”（參見第一部分）。企業的業務操作可以按照類似源自豐田精益制造最佳實踐的價值流程圖（Value Stream
Mapping）方法論的方法來識別。結果是，生命周期/事件模型成為系統設計和架構的主要驅動力，不可靠的用例集合不再是系統架構的主要輸入。
技術操作有其自身的挑戰和獨特的動態性。技術操作的主要目標是如何使不同的團隊在引入變更的過程中能最大限度的合作。基礎動態業務應用是具有兩類流程的自適應系統：操作和操作變更。這兩個流程將技術支持（操作）和技術開發（操作變更）與業務用戶聯系在了一起。
圖1. 構建和維護基礎業務動態平臺既需要業務流程框架，也需要業務系統變更管理框架。
兩個框架必須合并到一個既考慮技術團隊操作，又考慮業務用戶活動的獨特系統設計中。這個系統是圍繞服務器端架構設計的。雖然仿效了它們的結構和控制層次，但是這是為不同類型用戶合作提供支持的唯一方法。
設計服務器端基礎設施的復雜性比桌面應用的要高幾個數量級
每個企業軟件的設計者都認識到，實現完整的企業客戶/服務器應用要比構建桌面應用更復雜。對于桌面應用，接口是圍繞一個角色、一個主要任務和一個清
晰接口構建的，整個應用運行在單獨一臺機器之上。接口可以通過一系列函數實現來構建。對于服務器端應用，實現要復雜得多。復雜性的來源之一就是，服務器端
應用要實現包括管理員在內的多個角色。管理員不可能扮演一個被動角色，他需要一個可以在必要時改變操作參數的界面。此外，為了保證正常使用，技術支持必須
對應用進行監測。
要更好地理解實現桌面應用和實現客戶/服務器應用之間的區別，我們可以看看將一個桌面應用變成客戶/服務器應用需要經過哪些步驟。假設我們需要使用
作為服務器端應用實現的MS
Word寫信。首先，你需要一個技術支持負責設置字體、頁面和所有其他設置。每當你需要不同設置的時候，你都必須請求這個技術支持完成變更。在你寫信時，
管理員必須審定字體，信頭等等。一旦完成這些，同一管理員可能還需在它發送前對其進行審核。這個例子雖然看起來簡單，但是它可以幫助我們理解當試圖將桌面
開發過程中獲得的知識外推到客戶/服務器應用時，軟件架構師面臨的挑戰。
事實上，當多個用戶在使用同一個應用時（業務上或技術上），它需要完全不同的方法。架構必須是分布式（用戶可能在不同地點、使用不同機器）、有狀態
（狀態不再由硬編碼到應用中的下一個窗口來定義）、動態性（管理員或外部用戶可能需要一個業務實體能在運行時被改變，類似經理可能要求一個產品或服務不能
再以相同價格出售或客戶可能要求訂單改變的方式）和層次性（所有組織有一個控制層級，這樣不同用戶就能對流程進行不同控制）的任務或流程提供支持。所有這
些新性質都必須被內嵌至應用的基礎之中，否則它就必須在每次進行變更時被重寫。
但是這并非設計服務器端應用的唯一區別。當桌面應用崩潰時，用戶只需重啟它就行了。因為它實現的是簡單任務，重新做一遍即可，即便丟失了大部分數
據。用戶并不需要一個專門的技術團隊來幫助他運行應用程序。對于客戶/服務器應用而言，情況就完全不一樣了。由于多個用戶同時工作，一旦出現問題，只有具
有技術知識和有權使用工具監測應用的技術支持團隊能夠制定如何使應用恢復正常操作的決策。并且技術團隊自己的操作藍圖完全不同于業務操作藍圖。技術團隊有
自己的流程控制層次、自己的分布式環境、自己實現變更的方法和自己的狀態。
結果是，構架一個能在企業級運行的客戶/服務器應用要比構架一個桌面應用復雜幾個數量級。服務器端的主要復雜度源于它必須支持兩個自適應系統，一個
是技術團體，另一個是業務團隊，他們各自又都有自己的操作和控制層次。在構架同時支持管理和技術支持兩個自適應系統的應用時，需要遵守應用于自適應系統及
其相關信息的法則。
在構架這類復雜系統的過程中，如果有一個理想的架構，那么就用不著在每次業務或技術引入變更時重新返工了。理想情形是擁有一個標準組件集合，它具有
用事件模型實現的定義良好的行為。在不同控制級別實現的事件模型將這些組件鏈接到一個控制層次中。在桌面中，一組自身具有事件模型的定義良好的組件由一個
清晰的控制層級鏈接到了一起。服務器端就要落后得多了。使用中的J2EE、.NET或其它現存專有架構都缺少為分布式、動態性、有狀態和層次性環境提供支
持的基本組件。由于Web標準是無狀態、扁平、靜態和只針對單服務器的，它們對單個自適應系統都無法提供很大幫助，更別提兩個了。
根據自適應系統及其關聯信息的法則，一個控制層次總是符合3個模式：
- 初始化過程總是相同的自頂向下順序
- 層級之間的信息傳播總是遵照確定的規則：命令流自頂向下，反饋流自底向上
- 每個層級有其自身的正常操作，它們在收到一個反饋或命令之前不會改變。處理命令或反饋總是需要變更管理的能力。并且由于有兩類交互——命令和反饋——因而需要兩類不同的變更管理
我們將展示如何使用標準組件（它們一起被鏈接在一個動態、有狀態且分布式的控制層次中）為服務器端應用實現一個標準架構。但是首先，我們將先給出另一個任何計算機使用者都熟悉的以事件為中心的平臺。
微軟將它的未來建立在了針對GUI的一系列組件和一個靜態事件模型之上
微軟之所以如此成功有許多原因，但是其中一點非常突出。他們不顧來自Apple和IBM的諸多批評和競爭，將Windows操作系統構建成了一個桌
面標準。一種解釋可能是，微軟是第一家不僅提供與Apple利用Mac完成的工作類似的操作環境，而且還擁有一組最方便的OS和GUI組件的公司。這些組
件被實現成了可供調用的API。利用這個組件模型，包括微軟在內的軟件公司就能夠構建數據庫、辦公應用和類似Visual
Basic這樣的開發工具。這些應用都能利用被構建成結構體和控件的Windows內置層次事件模型。
在開發Windows時，微軟擁有的優勢在于，大多數OS和GUI的主要組件，連同它們的事件模型一起，要么已經是現成的，要么就是可以憑直覺方便
地構建。對于任何桌面應用來說，控制層次看起來異乎尋常的簡單。在GUI棧的頂端是扮演其余GUI組件容器的各個窗口。打開窗口，內嵌的控件也就自動地被
初始化。關閉窗口，每個組件也跟著一起關閉。用API捕獲那些事件以及Windows應用的開發都和一個插件架構十分相稱。
圖2. 微軟Windows控制層次模型——一個用戶、一個應用、一個位置、一組靜態功能
這些API的實現就是Windows操作系統自身。它是控制初始化過程的那個層級，也是最終必須處理錯誤而不是崩潰或丟失數據的層級。在服務器端，
組件、它們的事件和控制層次被一個需求搞復雜了，那就是為有狀態、動態、分布式和層次性任務提供本地支持。這正是自適應企業操作平臺（AEOP）的主要目
標。
圍繞動態結構和控制進行設計，AEOP提高了生產力
一些年前，IBM招募了上千名企業架構師決心降低它們各垂直行業的客戶化解決方案個數。一年多之后，他們將它們的數目由超過60個降低到了不到20
個。付出巨大的努力和不算優秀的結果顯示了問題的巨大。盡管投入了龐大的資源，但IBM確實難以創建能對他們客戶都適用的通用解決方案，不管他們在行業的
深度和公司大小。一種可能令他們努力復雜化的一件事是，他們是以一組不完善的遺留解決方案開始的。
我們的目標是相同的：創建一個幾乎普遍適用于所有行業的通用解決方案。如果有從一個新鮮想法開始的自由，我們一開始就會關注那些我們認為最重要的基
本原則。大多數企業架構雖然依賴現有技術、組件或象SOA這樣的趨勢，但是AEOP架構要優于它們。它從一開始就認識到技術在企業中扮演的根本角色就是提
高生產力。這個角色對所有技術解決方案（不論它是否是IT）都是有效的。在IT情形下，由于業務的動態性和存在于企業系統各用戶之間的復雜關系，架構需要
圍繞企業流程的結構、控制和動態性來構建。
這種方法還提供了一種手段來解決由Nicholas Carr的《IT沒什么大不了的（IT doesn't
matter）》產生的討論，該文發表于2003年5月的《哈佛商業評論》。詢問IT是否是業務相關的，就好像詢問裝配線是否是業務相關的一樣。它不僅對
諸如通用或豐田這樣的公司至關重要，而且是任何一家制造業公司的一部分，包括象Intel這樣的高科技行業明星。裝配線的影響力對那些定制產品或服務無處
不在的行業（如食品或保健領域）來說要小得多。雖然在象通用這樣的公司看來裝配線是重要的，但是它不過是高生產力的促成因素。相同的事實也適用于IT，它
可能對那些依賴信息處理運營的公司來說是一回事，但是對其他公司可能就無關緊要了。IT唯一的不同之處在于，它遠沒有裝配線技術成熟。
要分析IT如何能提高生產力，就要了解那些決定了技術如何被交付和使用的基本商業機制。我們必須看看信息處理的基本角色，并詢問驅動企業運營的核心
信息元素是什么。在工程領域，這一過程得到了相當好的理解，可以從幾個例子看出這一點。當一個工程師開始設計一架飛機時，他從來不會把飛機看作一個諸如螺
母、螺釘、電線、連接器、泵、電動發動機、杠桿、面板等這樣零件的集合。他查看連接它們的方式和它們在交付功能過程中扮演的角色。一架飛機的結構是圍繞機
翼、引擎、座艙和主機身建造的，并采用一種能夠最大化不同參與者間交互的控制層級。建筑師在設計一棟房子時也是這樣。在建筑師清楚房中需要的臥室數目和生
活的家庭人員個數之前，待安裝的空調、器具或電線型號都不重要。
在當今的方法中，企業軟件大多都是圍繞技術組件和標準被構架/設計的。需求是一種評估生產力增長或企業軟件結構、控制和動態性的一種補救方法。事實
上，高級別架構推薦只以表現層、業務層和持久層為中心。當前還沒有一種架構方法提供一個解決方案來支持現實中的動態、分布式、有狀態和層次的業務流程架
構。
為了更好地類比，不妨讓我們看看工程師是如何設計裝配線的。首先，它們以易于維護和維修為設計目標。這就是為什么裝配線架構和設計是圍繞可交換性、
模塊化和標準化組件建造的原因。由于裝配線不會動態變化，那么第二個標準就是要易于針對新模型重新進行配置。這正是機器人在裝配線上如此流行的原因。不管
任務有多復雜，都可以方便地針對范圍廣泛的當前和將來任務重新編程。只有在這兩個標準被滿足之后，設計工程師才會著手努力最優化每個特殊的任務。
為了構架/設計一個通用的AEOP，我們識別出了3個需要在設計中被解決的基本因素，它們對生產力的提高有重大影響。它們幾乎對所有企業都是相同的，不論這些企業涉及的領域或生產規模：
1）通過為技術支持、開發人員和業務用戶之間的合作操作提供支持，提高技術團隊操作的生產力
對整個架構影響最大的是不同技術團隊和業務用戶之間的關系以及需求變更引入的方式。由于IT團隊是在應用上花費時間最多的一個團隊，提高它的生產力應該是架構的首要任務。
在這一背景下，技術團隊正常操作的結構與控制并不復雜。業務用戶打開一個觸發業務事件的應用。這些事件使應用處理信息。技術支持團隊監測應用。應用雖然處于生產環境，但是開發團隊常常要計劃下次升級并實現新的需求變更。
整個處理的控制遵循相同的層次架構：在控制金字塔的頂端是開發者團隊。因為是他們實現未來的功能，他們對實現擁有所有控制權。接下來是技術支持團
隊，因為他們可以停止和重啟服務器或改變部分系統配置。對應用擁有最小控制權的團隊包括業務用戶、經理或工人。他們對應用腳本只能唯命是從。
由于企業是動態的，功能變更的請求可能出現得非常早，甚至在應用安裝和運轉之前。事實上，需求只有在下次開會的時候才生效。結果，在我們查看什么對
生產力有驅動作用的時候就會發現，如何將變更轉換為代碼是一個重要因素。在AEOP中，當發生變更時，你會發現總是存在同樣的用戶組。開發團隊是接受變更
請求的團隊，監測應用的團隊安裝它并接受配置來支持它，接著是業務團隊接受培訓來使用新功能。
作為這個結構和控制層級的結果，企業應用的頂層總是圍繞3個平臺構建的：一個為開發團隊實現功能、一個為技術支持團隊實施它和一個支持業務用戶。它們每個都有自己的主生命周期和驅動設計的事件模型。
因為AEOP主要是支持技術團隊操作的動態性，所以這種“3個平臺”的結構、它們的組件和事件模型都是圍繞變更請求的生命周期而構建的。
2）通過為3類基本業務用戶之間的合作事件提供支持，提高業務操作的生產力
不同類型基本業務用戶間合作是生產力的第二大影響因素。在任何企業流程中最多有3類基本用戶，分別代表了自適應系統的3個方面：代表操作的工人、代
表決策制定流程的經理和代表經濟環境（它使價值循環成為閉環）的客戶。價值循環的其他業務參與者，如供應商和政府代理，都扮演次要角色，并且它們的流程都
可以使用這3種基本流程（操作、管理和環境）中的一個標識。
業務是動態的。業務中最大的生產力杠桿之一是變更引入流程的效率。業務中有兩類變更：經理引入的內部變更和消費者引入的外部變更。這些變更在某個時
間作為更新被引入到企業應用中。一個有效的架構/設計必須解決這種動態性。一種理想的企業應用架構能夠只需最少的代碼和配置改變就能適應大多數變更。由于
業務日益依賴支持它們運營的技術，一個快速而有效的更新應用方法對整個生產力十分重要。
基于這一點，AEOP針對業務操作中的高級合作只定義了3類企業架構：
- 靜態架構：純操作性的——目前所有的企業軟件都屬于此類。除了最簡單的配置變更之外，完成業務流程變更通常都至少要求IT部門停止應用的運轉。靜態架構的行為類似于汽車制造商在引入新模型時停止裝配線。
- 僅
內部（內部決策）驅動的動態架構：提供了對動態操作的支持并實現了經理和工人之間的關系。在這種情況下，在正常操作期間，以及在變更動態應用于當前所有實
例時，經理決策是被自動考慮到的。因為經理和工人在不同的時間線上操作，他們需要處理內部決策的變更管理平臺來嫁接他們的活動。客戶在其中不扮演指導角色
的那些流程都屬于這個類別。
- 擴展的（內部和外部決策）動態架構：提供了對動態操作的支持并使全部3類基本用戶（工人、經理
和客戶）之間的合作自動化。這是最復雜的業務操作架構。它有兩個不同的變更管理平臺，一個針對正常操作應用于內部決策的方式，另一個針對那些希望改變訂單
在正常操作時的執行方式的客戶。
注意，在任何企業中，不論什么類型的業務流程，它總是與管理“命令和控制”的結構和客戶反饋“相連”的。結果，不論應用的目標業務流程是什么，每個應用都屬于“全動態類別”。
操作平臺架構的動態性是以業務變更生命周期為中心的。它們受內部決策（經理制定內部決策）和外部變更（客戶可以決定給進行中的已有訂單和服務施加變化）驅動。
3）通過提供在生命周期/事件級別完全解耦的架構，提高開發團隊的生產力
前一個生產力因素跟業務變更對架構/設計的影響息息相關。理想情況下，架構/設計中的業務變更可以通過變更管理模塊的界面來完成。該界面使經理和客戶有權自動向工作中所有操作應用變更。
有時，變更需要開發團隊實現新功能。在實現新功能時，應用的架構/設計應該支持高生產力。
當前方法是將一系列組件歸到有數據庫訪問權限的“業務層”上。這種設計有一個基本錯誤。在這一設計中的數據庫很可能是關系數據庫，它保存層次性信息或有狀態信息的能力很差。它們很可能依賴緩存機制，它們需要消耗驚人的計算資源，在后臺持續更新大量數據。
無論怎樣，企業中的所有業務流程都會鏈接到主業務實體（一個產品或一個服務）。對于一個鏈接到主業務實體的業務流程來說，現有歷史是最重要的方面。
即使對最簡單的交易來說也是如此。去一個商店買東西的前提是，你的金融資源將為你提供購買產品所需的足夠金融“資源”，而且商店有“待售”的產品。一個實
體的歷史由最終描述它整個生命周期的事件組成。由于可能改變實體狀態的事件可以在業務結構內的任何位置和多個控制級別被觸發，圍繞這個業務實體動態構建的
AEOP架構必須是有狀態、層次性和分布式的。
由于生命周期圍繞事件而構建，圍繞它們可以構建整個AEOP。任何事件實現都可以按照同一種通用方法完成：整個生命周期可以被認為是反映主業務實體
轉換信息的“裝配線”。因此，可以用相同的結構來實現事件，并裝配：1）從各需要位置（分布式）檢索出來的信息元素；2）在某一時刻瞬間存在的（如，檢索
一張信用卡交易的賬戶信息必須以實時方式完成）信息元素；3）可由一定的業務流程實現的信息元素；4）已經應用了一定的業務規則的信息元素。
AEOP的另一個優勢是能夠圍繞同一個事件模型設計兩類變更管理。最終，這個操作平臺的實現可以在事件級別解耦。操作平臺可以作為一個插件API基礎設施來構建，就像Windows API是圍繞著桌面集成事件模型構建的一樣。
需要注意的是，文獻中記載的EDA（事件驅動架構）跟AEOP事件模型是不一樣的。EDA是圍繞非結構化事件流構建的，而AEOP是圍繞由一組生命周期模板鏈接在一起的結構化事件流構建的。
圖3. AEOP控制層次模型——按變更類型分組的多個用戶、多個客戶端應用、多個分布地點、多個靜態功能
組件及其事件的AEOP層級包含5級：
- OS級：在這里可以找到所有OS組件，如內核、文件系統、網絡和I/O。OS可能還有GUI組件，運行監測各種應用及其活動的圖形化工具時會用到它們。
- 技
術級：在這里可以找到所有傳統的基于服務器的組件，如應用服務器、BPM引擎、業務規則引擎、數據庫。這兒還有實現了Web和Web服務、消息傳遞等標準
的組件。它們或多或少扮演了和飛機設計中標準零部件相同的角色。螺母、螺釘、電動發動機、液壓泵、電線、連接器、座椅、電子面板、馬達對許多其他工業設備
都是通用的，不只限于飛機。可是它們在盡可能簡化和標準化設計的過程中扮演了一個關鍵角色。
- AEOP技術操作級：這是擁有
特定于AEOP組件的頂級級別。這里有3種組件——安裝/啟動/持久化/恢復平臺、系統平臺和操作平臺。它們分別代表了合作運行客戶/服務器應用的3個小
組：業務用戶團隊、技術支持團隊和開發團隊。每個組件實現了特定的事件，如技術支持團隊能監測錯誤和重啟應用。對于那些需要和外部系統合作的應用，還存在
被稱為外部系統監督者平臺的第4類組件。這個組件管理與外部系統交互的初始化、正常操作和錯誤翻譯。
- AEOP業務操作級：它是業務實現的頂級級別，在操作平臺之下的一級。它也包含了3個主要組件：正常操作、內部決策管理變更和外部環境交互（即客戶決策）管理變更。這里包括許多其他組件，如外部系統操作翻譯器、系統Map、許可證管理器等。
- AEOP事件處理級：這是實現的插件級。在這一級實現了被激活業務流程的整個正常操作。由于每個功能被分解成了事件級的函數，整個架構圍繞事件模型被解耦了。這可以包括操作錯誤、操作變更，以及甚至安全訪問。
顯然，在這個AEOP的簡短描述中還有很多組件和事件沒有被覆蓋到。在下一節我們將圍繞這3個組件進一步分析其細節。
AEOP事件模型和事件驅動架構（EDA）之間存在著差異。EDA是一種提倡產生事件、檢測事件、消費事件、對事件做出反應的軟件架構模式（來自維
基百科）。EDA缺失的是如何捕捉業務流程的結構和控制。此外，AEOP區別了3類事件，一個針對正常操作、一個驅動內部變更和一個針對外部變更。它們負
責不同的待處理模塊，而EDA則使用相同的方法處理所有模塊。AEOP使用生命周期在一個分布式、層次、有狀態和動態的結構中將事件分組。
AEOP中的信息“裝配線”是圍繞動態生命周期模式的多聯裝（Multi-shell）容器構建的
所有現代軟件平臺都是圍繞某種形式的容器模式構建的。AEOP也不例外。基于J2EE的應用服務器甚至有兩類容器：Servlet和EJB。操作系
統可被視為是一種應用程序的容器。容器的概念和“計算機資源是有限的”這一思想有一定聯系。容器在AEOP架構中的使用是不同的：
- 容器創建和管理的對象是業務實體資源的直接表示。例如，AEOP操作容器管理整個訂單生命周期，不僅僅是反映現有計算機資源的對象。
- 容器可以區分作為正常事件序列一部分、改變受管資源狀態的調用和觸發正常操作之外變更的調用。由于存在兩類變更，因而每個容器都關聯兩類變更管理模塊。為了提供比現有靜態架構更好的企業動態現實支持，AEOP容器支持受管資源的動態生命周期。
- 容
器并非類似J2EE應用服務器中的單獨結構。各容器按照控制層次鏈接在了一起。集成的事件模型驅動了系統外產生事件的接收和處理。在這種情況下，既不在最
頂端也不在最底端的容器扮演了雙重角色，一個作為資源生命周期管理器，另一個作為受管理的資源。這就是給予系統容器的多聯裝（Multi-shell）結
構。
整個AEOP架構和實現是圍繞描述容器（它管理代表真實業務實體的資源）的模式而構建的，對正常操作和變更進行了區別，是反映業務控制層級的結構的一部分。
圖4. AEOP多聯裝（Multi-shell）容器架構將技術置于頂端，業務操作置于中間，事件處理置于底部
每個AEOP容器可能處理3類事件：（1）由“事件模型”模塊標識的正常操作；（2）來自由控制層級中上層容器發出的內部變更的事件；或（3）來自由控制層級中下層容器發出的外部變更的事件。
除了主生命周期及其關聯的事件模型，那里還有被認為是正常操作“靜態部分”的業務實體。例如，在正常操作期間不期望改變的項目價格或物理位置。它們
是通過所謂的“靜態模型”的模塊捕捉到的。這并不意味著它們就是固定且隔離于業務動態之外。靜態模型只有通過變更管理流程使用內部和外部變更來更新。
AEOP控制層次可被用來設置容器的模式：初始化、操作和關閉。只有處于操作模式的容器才能處理事件。
在AEOP架構中，有3個相關元素：1）組件和控制的高級別技術結構，2）操作平臺，3）事件處理平臺。
高級別AEOP技術代表整個應用，該應用可被認為是一個自適應系統。它有3個主要平臺，并且它們各自也都可被認為是一個自適應子系統：上面的平臺扮
演了管理角色，下面的平臺扮演了環境角色。每個平臺自己都有定義良好的、實現了自身功能的事件模型，并且它還要和其他兩個進行交互。在每個平臺上我們都可
以發現一個倉儲，它可以是一個緩存數據庫或一個較傳統的關系數據庫。
與外部系統的集成遵循相同的事件模型。根據外部系統類型的不同，可以使用的集成策略有兩種。如果AEOP只有訪問持久化倉儲的權限，它可以使用始終
運行的調度任務來查看數據庫記錄中的數據變更。第二個方法依賴API調用，如果可以將外部系統實現改成在主業務實體變更時發起調用，那么就可以實施這個策
略。
圖5. 高級別AEOP多聯裝（Multi-shell）容器架構
這3個平臺中的每一個也都是圍繞特定生命周期元素構建的。操作平臺圍繞主業務實體生命周期，系統運行時平臺圍繞用戶會話，安裝/持久化平臺圍繞版本控制生命周期。
雖然數據只能按照苛刻的事件模型藍圖來處理，但是相同的數據卻可以被任何有權訪問系統且有正確證書的用戶訪問。但是，很少有針對平臺用戶的數據查看
工具。例如，系統運行時平臺有一個針對運行時錯誤的查看器，它被用來監測用戶和分布式系統。這一工具也可在各子系統失效時重新啟動它們。
AEOP技術級還實現了一個完整的初始化過程。啟動過程中，在用戶可以運行第一個任務之前，應用必須經歷3個步驟：
- 啟動應用：系統管理員啟動主應用。這是通過啟動像Tomcat（J2EE
servlet容器）以及Axis這樣的容器（Web服務平臺）做到的。應用可以將Spring框架加載到一個輕量級容器中，并使用Spring
bean配置文件加載初始的“啟動”模塊。“啟動”模塊初始化“系統”模塊。該模塊負責主應用的硬編碼配置。它還可能包含對現有遠程數據源的硬連接、讀取
遠程部署的應用版本的Web服務端點、測試方法和對各種分布式系統的開放互聯性，以及提供正常操作、性能和日志相關數據的功能。產生數據的主要用戶是開發
者和技術支持。
- 安裝/啟動/持久化/恢復 “系統”模塊：這個模塊實現了所有系統相關的功能，包括檢查系統配置。它的主要功能是將一個包含所有資源（遠程數據源、用戶、版本、集群中的服務器、連接、安全數據等）及其狀態的系統Map載入緩存。該模塊提供了應用監視器。這個模塊的主要用戶是技術支持。步驟：
- 此階段的第一個步驟是驗證分布式系統上線并正在運行。如果遠程系統沒有激活，一個被調度的操作變更將被發送給操作系統，由它使那些依賴它們的任務無效。它還將把它們的緩存數據設為“過時”。它還將給應用儀表盤發送一個信號，并在日志中記錄。
- 一旦這個工作完成，它就驗證那些遠程數據位置的軟件版本是否正確。如果不正確，它將使它們失效，并給應用儀表盤發送一個信號和日志記錄的動作。
- 最后一步是檢查那些遠程分布式系統的數據定義。如果它們改變了，將采取同前一活動相同的步驟。
- 啟動主應用運轉：這是用戶可以訪問應用之前的最后一個步驟。它將操作上下文，連同所有激活的用戶實例和它們的狀態載入緩存。操作上下文的一部分是指向分布式系統數據及其狀態，以及這些分布式系統操作上下文的指針。這個模塊的主要用戶是業務用戶。
圖6. 系統控制層級確定的3個主要容器的狀態
初始化之后，同一架構被用來控制主應用的操作就緒狀態。它有3個場景：
- 用戶運行/創建查詢時產生的錯誤：這是最普通的場景。一旦錯誤被操作模型子平臺檢測到，系統就被設置成“操作錯誤”模式，一
條消息將被發送給系統模型子平臺，并且待顯示的新狀態/警報被發送給監測主應用的技術支持團隊。出于日志記錄的目的（這是給開發團隊的信息），同一錯誤將
被發送給安裝/持久化/恢復模型子平臺。用戶也將收到一條顯示當前事件狀態以及可用選擇的消息。一個選擇是由前一步恢復實例。因為整個操作是圍繞保證前一
事件被成功完成的事件模型構建而成的，這令這一選擇成為可能。
- 經理或數據源管理員改變操作上下文：在這個情況下，主應用被設置成特殊的“操作變更”模式。當前受變更影響、正在運行任務的所有用戶都將被通知。他們有兩個選擇：要么經歷一個實例更新過程，要么簡單地忽略。
- 產生了一個環境系統錯誤：在這個情況下，監測IT環境的技術支持團隊會得到通知。它是通過能夠監測集群或J2EE/NET應用服務器的工具做到的。此時，主應用將試圖記錄最近的活動或幫助調試的應用服務器堆棧信息。
接下來的細節是關于AEOP操作平臺的。事件模型是圍繞業務實體的類型構建的。每個產品類型的服務有其自己的生命周期，它由自己的事件藍圖表示。事
件藍圖是定義良好的有序事件集合。每個藍圖關聯一組變更類型。內部或外部事件可以是正常操作的一部分，或可以代表不同類型的變更。每個事件必須被清晰地標
出，因為它是要被一定的模塊處理的。這種方法不同于事件驅動的架構方法，后者將事件視為“在你的企業內部或外部發生的值得注意的東西”。它也不同于
EDA，EDA是以事件結構為中心的，比如它需要有事件頭、事件體、事件時戳等。AEOP沒有任何這些限制，因為整個結構是由它的類型決定的。
圖7. AEOP的“信息裝配線”是圍繞業務操作的容器被構建的
操作平臺使得3類基本用戶——工人（他們支持正常操作），經理（他們觸發內部操作變更）和外部業務團體（即用戶）——之間的交互自動化。
最后一個要詳細描述的平臺是AEOP事件處理。“裝配線”概念能在超過一個世紀的時間里如此流行，其中一個原因就是，每一步可以輕易地和其余的步驟
解耦。除此之外，不管他需要執行什么工作，每個“崗位”的工人都將遵循相同步驟。當一個產品的主實例到達這個“崗位”，它就像一個需要使用各種零件“填充
”的空
“殼”一樣。這些零件有兩類：在當前“崗位”待組裝的特殊零件；對裝配過程只起幫助作用的零件，我們稱這些零件為“工具”。例如，一個“工具”可能是幫助
裝配過程的某種膠水。這三個待組裝元素有它們自己的倉庫，它們有自己的“到達”時間安排，并且它們遵循特殊的裝配過程邏輯。一旦組裝完成，在到達下一個“
組裝崗位”之前，那個零件實例不會發生任何事情。
“信息裝配線”跟真實的裝配線概念非常相似。在事件處理期間，我們遇到的是同類信息：代表主業務實體的“殼”，特定于一個事件和需要被增加實例的信
息，以及被稱為“工具”、只特定于需要被增加事件的信息。“工具”類型信息的主要特征是，它是有限的，可以為同一事件多次使用它，并且在處理事件過程中你
可能把它“用光”，在某種程度上類似裝配過程期間用來粘住零件的“膠水”。在訂單處理中，“工具”信息的一個例子就是企業給客戶的賒賬限額。他可能一次性
使用所有可用賒賬限額支付產品，或者他可能決定只使用部分，他可以使用它支付多次購買，并且在一個購買過程中他可能把它“用光”了。
另外它與“倉庫概念”也很相似。“待裝配”信息對何時開始檢索它有明確的規則。例如，當客戶用信用卡支付帳單時，賬戶信息是實時從銀行檢索出來的。保存在任何其他數據“倉庫”中的值都不是一個有效的值。
處理事件期間，從各系統取信息可以通過事件“定位”層和事件“調度器”層來完成。只有在完成這兩步之后，“信息”才能按照邏輯進行“裝配”。“定位
”層使用一種面向消息的組件，“調度器”層使用以調度為中心的組件，“邏輯”層使用BPM/業務規則引擎作為主組件。次序總是不變的。
調度器在架構/設計中的任務不僅僅是安排不同任務的時間，它的另一個任務是幫助設計一個在事件層完成控制狀態變化的多線程架構。這是通過使用調度器
作為一個事件模塊做到的，它把在狀態變化期間可能有并行任務的流程轉換成單獨的“泳道”。這樣，我們就可以在事件層像調度器處理每個事件子任務那樣來實現
狀態變化邏輯了。這樣，流程“泳道”中的失效將使整個系統處于一個清晰可辨的狀態中。
圖8. AEOP事件處理容器——定位、調度和邏輯
結合所有這3個元素，“信息裝配線”可以被構建成對任何企業系統都是通用的，不論企業涉足的領域和規模大小。這與裝配線的方法類似，起源于汽車制造業，后來擴展至所有其他制造行業。
AEOP事件處理容器針對內外部變更有兩類變更管理模塊。假如一個事件被標識為一個變更，決策表將把具體的變更類型和特殊事件聯系起來。這個架構是
作為一組插件來設計的，它是根據現有實例的狀態被調用的。例如，在訂單處理中，對于預付和未付訂單而言，處理價格變更的方法是不同的。
總結——數天內完成架構、數周內完成設計、數月內完成實現——構建集成的DBA服務器端基礎設施的簡易之道
AEOP方法有諸多優點。主要優點是它標準化了服務器端應用的架構，這正是當今IT所缺失的。它將這個服務器端實現轉變成事件插件代碼的編寫，類似微軟Windows應用的編寫方式。
圖9. 自適應操作平臺支持動態、擁有控制層級、分布式和有狀態的業務
使用AEOP實現應用的3步驟包括：
- 獲取對象流和變更類型
- 獲取3個平臺的組件
- 構建每個事件處理的5個模型
在這個架構中，像SOA這樣的技術和架構概念扮演配角。像BPM引擎、調度器、消息傳遞這樣的組件在架構中有明確的角色，但是它們對設計的影響很
小。這類似于飛機設計中各零件扮演角色的方式。電動發動機、電線、螺母和螺釘對整個飛機的功能至關重要，但是它們對設計過程卻非如此。
由于這種方法不依賴于業務，可以構建類似微軟Visual C++向導或Visual Basic這樣的工具進一步使實現過程自動化。這不僅提高了開發團隊的生產力，而且還有助于開發者關注實現的真實方面，而不是與錯誤的架構“搏斗”。
即將到來的第三部分——案例研究和局外人觀點
本文將在第三部分繼續，它探討一個真實實現的案例研究和新的自適應系統理論的簡要總結。
查看英文原文：Beyond SOA, a New Type of Framework for Dynamic Business Applications - Part II。
轉自：http://www.infoq.com/cn/articles/beyond-soa-dba-part-2