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