超越SOA：動(dòng)態(tài)業(yè)務(wù)應(yīng)用的新企業(yè)應(yīng)用框架

-.z超越SOA：動(dòng)態(tài)業(yè)務(wù)應(yīng)用的新企業(yè)應(yīng)用框架作者VasileBuciuman-an,MichaelChervenic譯者胡鍵發(fā)布于2008年4月23日下午10時(shí)21分第一局部——即使擁有全部需求和最正確設(shè)計(jì)，你的架構(gòu)仍然很可能失敗，原因在于……目前的管理學(xué)校，教育培養(yǎng)的是公司經(jīng)營者。設(shè)計(jì)公司幾乎沒有引起重視……幾乎從來沒有任何人為了取得方案的增長和穩(wěn)定性，有意識(shí)和有思想地設(shè)計(jì)一個(gè)組織。JayW.Forrester，設(shè)計(jì)未來〔1998〕介紹在一篇名為?動(dòng)態(tài)業(yè)務(wù)應(yīng)用勢在必行〔TheDynamicBusinessApplicationsImperative〕?的論文中，F(xiàn)orrester的高級(jí)分析師JohnR.Rymer指出了當(dāng)今應(yīng)用的一個(gè)致命缺陷：當(dāng)今應(yīng)用迫使人們?nèi)ふ乙环N將孤立的信息和功能組映射到他們?nèi)蝿?wù)和過程的方法，它們強(qiáng)迫IT人員花高額預(yù)算來跟蹤不斷變化的市場、策略、規(guī)章制度和業(yè)務(wù)模型。在下一個(gè)5年內(nèi)，IT的主要目標(biāo)應(yīng)該是創(chuàng)造新一代企業(yè)軟件，適應(yīng)業(yè)務(wù)和業(yè)務(wù)工作，同時(shí)能隨業(yè)務(wù)演變而演變。Forrester稱這個(gè)新生代為動(dòng)態(tài)業(yè)務(wù)應(yīng)用，強(qiáng)調(diào)了和業(yè)務(wù)過程及工作〔為人而設(shè)計(jì)〕的嚴(yán)密配合，對業(yè)務(wù)變化的自適應(yīng)〔為變化而構(gòu)建〕。在這個(gè)階段，動(dòng)態(tài)業(yè)務(wù)應(yīng)用的需求比創(chuàng)立它們所需的設(shè)計(jì)實(shí)踐更清晰。工具都是現(xiàn)成的：面向效勞架構(gòu)〔SOA〕、業(yè)務(wù)過程管理〔BPM〕和業(yè)務(wù)規(guī)則領(lǐng)域中的先驅(qū)——包括獨(dú)立軟件開發(fā)商〔ISV〕——已經(jīng)開場向我們展示了這種方法?，F(xiàn)在就是開場這段旅程的時(shí)候。在這篇由兩局部組成的文章中，我們會(huì)從架構(gòu)和方法論的角度，采用歷史的觀點(diǎn)來對待這些動(dòng)態(tài)業(yè)務(wù)應(yīng)用〔DBA〕的開展。我們的目標(biāo)是獲得一種能使應(yīng)用容易適應(yīng)業(yè)務(wù)變化和其他必要修改的構(gòu)建方法。隨著企業(yè)在21世紀(jì)關(guān)注靈活性，DBA是使業(yè)務(wù)和IT在未來幾十年內(nèi)成功的關(guān)鍵。圖1.靈活性和效率——21世紀(jì)企業(yè)的兩個(gè)主要驅(qū)動(dòng)力動(dòng)態(tài)性對我們意味著什么.在軟件工程領(lǐng)域，許多框架或產(chǎn)品都聲稱具有自適應(yīng)性。在我們設(shè)法理解一個(gè)解決方案在適應(yīng)變化方面終究有多好之前，需要給系統(tǒng)是如何變化的——它們的動(dòng)態(tài)性——下一個(gè)可靠的定義。早期的面向?qū)ο蠓椒ㄕ撜J(rèn)識(shí)到[1]：為了使系統(tǒng)分析中立，它必須基于兩類現(xiàn)實(shí)世界的需求：現(xiàn)實(shí)世界的實(shí)體——收集現(xiàn)實(shí)世界實(shí)體的信息和它們間的關(guān)系，有助于分析師開場以一種系統(tǒng)的、構(gòu)造的、客觀的觀點(diǎn)來對待需求，而非一種技術(shù)的、主觀的觀點(diǎn)現(xiàn)實(shí)世界的事件——系統(tǒng)行為只由改變現(xiàn)實(shí)世界實(shí)體狀態(tài)的事件的出現(xiàn)來驅(qū)動(dòng)在這樣的背景下，對于每一個(gè)被分析的系統(tǒng)，我們總能識(shí)別一個(gè)或多個(gè)最重要的實(shí)體。每個(gè)實(shí)體都又包含3個(gè)關(guān)聯(lián)元素：事件、狀態(tài)和生命周期。每個(gè)事件代表狀態(tài)中的一個(gè)變化，所有普通實(shí)體狀態(tài)的有序和代表了一個(gè)生命周期。但是，那些觸發(fā)狀態(tài)變化且是正常流程一局部的事件與那些觸發(fā)狀態(tài)變化但不是正常流程一局部的事件之間有明顯的差異。例如，當(dāng)一個(gè)產(chǎn)品訂單被提交之后，一組可能發(fā)生的事件包括付費(fèi)處理和訂單交付。當(dāng)一個(gè)用戶變更訂單或當(dāng)企業(yè)改變價(jià)格時(shí)，我們不能認(rèn)為這些動(dòng)作是正常流程的一局部，因此它們與實(shí)體〔如訂單〕的生命周期無關(guān)。核心實(shí)體實(shí)例的生命周期單獨(dú)定義了在正常操作中系統(tǒng)最有可能處理的東西。所有其他事件類型，如變化或中間步驟，被區(qū)別對待。這個(gè)場景對很多工程師都不陌生：一個(gè)系統(tǒng)模型包含一個(gè)核心實(shí)體構(gòu)造，該實(shí)體具有一組事件，這些事件組成了實(shí)體的生命周期。這個(gè)系統(tǒng)模型對分析師和設(shè)計(jì)者都很清晰且易于理解。建模工具，如有限狀態(tài)機(jī)、實(shí)體關(guān)系圖、實(shí)體狀態(tài)轉(zhuǎn)換圖和數(shù)據(jù)流圖，為了幫助這種方法已經(jīng)經(jīng)過了快20年的完善。那些為復(fù)雜系統(tǒng)〔如空客380或F-22，后者是世界上最高級(jí)的戰(zhàn)斗機(jī)〕效勞、擁有數(shù)十億行代碼的軟件就是這樣被編寫出來的。使用對象流圖〔它是捕獲事件和狀態(tài)轉(zhuǎn)換的基礎(chǔ)模型〕虛擬化實(shí)體生命周期是這個(gè)模型的關(guān)鍵。在這個(gè)情況下，架構(gòu)可以被認(rèn)為是靜態(tài)的，因?yàn)檎麄€(gè)系統(tǒng)狀態(tài)在時(shí)間軸上的任意一點(diǎn)都是確定的。圖2.事件模型、狀態(tài)變化和生命周期是正常操作的核心普通事件、狀態(tài)、生命周期間的關(guān)系，以及從其他事件類型中分出的普通事件是理解所建議的動(dòng)態(tài)操作框架的根底。正如JamesMartin和JamesOdell很久以前在?面向?qū)ο蠓治鲈O(shè)計(jì)?中所寫的，分析師、設(shè)計(jì)師和實(shí)現(xiàn)者都應(yīng)該使用同一系統(tǒng)模型。分析師使用數(shù)據(jù)流圖思考，設(shè)計(jì)師使用構(gòu)造圖思考，程序員使用Java和SQL思考。在數(shù)據(jù)流上下文中，分析師識(shí)別對象類型，并思考改變對象狀態(tài)的事件。最終用戶也理解這個(gè)一樣的認(rèn)識(shí)。他們也應(yīng)該按照對象類型、事件、對象狀態(tài)的變化，以及觸發(fā)和控制事件的業(yè)務(wù)規(guī)則進(jìn)展思考。Martin和Odell強(qiáng)調(diào)了對象流圖對系統(tǒng)設(shè)計(jì)師的重要性：“事件模式適合按照事件、觸發(fā)器、條件和操作來描述過程。但是這種方式不適合描述大型復(fù)雜過程。一個(gè)系統(tǒng)領(lǐng)域常常太大或太復(fù)雜，無法表示成事件和觸發(fā)器。此外，可能只有一個(gè)高級(jí)別的認(rèn)識(shí)才是必要的。這對戰(zhàn)略級(jí)別的規(guī)劃尤其正確。在這樣的情況下，一個(gè)對象流圖是有用的。對象流圖〔OFD〕與數(shù)據(jù)流圖〔DFD〕類似，因?yàn)樗鼈兠枋隽嘶顒?dòng)和其他活動(dòng)間的接口。在DFD中，這個(gè)接口傳遞數(shù)據(jù)。在對象技術(shù)中，我們不再限于數(shù)據(jù)傳遞。相反，圖應(yīng)該表示從一個(gè)活動(dòng)傳遞到另一個(gè)活動(dòng)的任何類型事物：不管它是報(bào)表、零部件、已完貨物、設(shè)計(jì)、效勞、硬件、軟件——或數(shù)據(jù)。簡而言之，OFD指的就是被產(chǎn)生的對象，以及產(chǎn)生和交換它們的活動(dòng)。〞為了捕獲與業(yè)務(wù)操作關(guān)聯(lián)的信息流，業(yè)務(wù)分析師用價(jià)值流程圖〔ValueStreamMapping〕對OO方法論進(jìn)展了補(bǔ)充。價(jià)值流程圖起源于豐田，與精益制造關(guān)系嚴(yán)密。美國國家環(huán)境保護(hù)局將價(jià)值流程圖定義為“用來認(rèn)識(shí)那些產(chǎn)生產(chǎn)品或交付效勞的活動(dòng)序列與信息流程的精益過程映射方法。〞此處的關(guān)鍵詞是“產(chǎn)品〞和“效勞〞。它們顯現(xiàn)了適宜的信息流程在整個(gè)企業(yè)中扮演的統(tǒng)一角色。把過程流圖和價(jià)值流程圖兩個(gè)概念結(jié)合在一起后，它產(chǎn)生了一個(gè)完全代表整個(gè)企業(yè)經(jīng)營*圍、可被方便翻譯成OO〔圖2〕概念的框架根底。但是，許多系統(tǒng)并不是靜態(tài)的，它們變化無常的行為無法被一組關(guān)系和事件捕獲。事實(shí)上，它們發(fā)生在不可知的[2]未來，傳統(tǒng)用來捕獲它們動(dòng)態(tài)特點(diǎn)的工具不起作用。所有的業(yè)務(wù)應(yīng)用和絕大多數(shù)現(xiàn)實(shí)世界的系統(tǒng)都?xì)w于此類。這些系統(tǒng)，基于它們和其他外部系統(tǒng)的交互方式，處理3類變化：正常工作——組成主實(shí)體或?qū)嶓w們生命周期的正常事件序列。通過每個(gè)事件——實(shí)體改變其狀態(tài)——通常可以方便地定義一個(gè)過程。在正常工作行為內(nèi)部，有些操作上下文元素不期望被改變。例如，當(dāng)一個(gè)客戶訂購一個(gè)產(chǎn)品時(shí)，在整個(gè)提取訂單、準(zhǔn)備訂單和交付訂單的過程中，諸如價(jià)格、組成和交付方式等是不期望被改變的。內(nèi)部變化——如上所述，在整個(gè)核心實(shí)體生命周期內(nèi)，*些上下文元素不期望被改變。在現(xiàn)實(shí)世界中，這并不總是真理，因?yàn)楣芾頉Q策或其他因素會(huì)迫使上下文元素變化。我們稱內(nèi)部系統(tǒng)屬性的變化是內(nèi)部變化。外部或環(huán)境變化——不管一個(gè)企業(yè)如何相信他們“擁有〞一個(gè)客戶，但是這個(gè)客戶總有保存改變他或她意志的自由。一個(gè)系統(tǒng)不太可能與外部系統(tǒng)〔如客戶或供應(yīng)商〕總是有一個(gè)“固定的〞合同。然而，正常工作很可能圍繞這個(gè)“固定的〞規(guī)則集合進(jìn)展設(shè)計(jì)。我們稱系統(tǒng)外部引起的變化為外部變化。要對現(xiàn)實(shí)世界系統(tǒng)建模，就必須處理好這所有3種變化類型。這種模型與靜態(tài)架構(gòu)模型相比，在管理復(fù)雜性上有了極大的提高。從正常工作的觀點(diǎn)來看，內(nèi)部和外部系統(tǒng)完全獨(dú)立于主信息流運(yùn)行。內(nèi)部和外部系統(tǒng)甚至有它們自己的操作——管理有其自身的決策周期，客戶有其自己的操作環(huán)境——由各自的信息流描述。就信息流而言，這3種系統(tǒng)分別運(yùn)行在3個(gè)平行宇宙中。解決這3種非同步信息流的唯一方法就是為每個(gè)信息流實(shí)現(xiàn)一個(gè)獨(dú)立全面的變更管理。這種復(fù)雜交互在圖3〔動(dòng)態(tài)操作圖〕中表示。郵輪公司給客戶提供的效勞可以作為解釋動(dòng)態(tài)操作的例子。在訂購時(shí)，一個(gè)客戶會(huì)決定在游覽期間他方案參與的效勞。但是，不僅客戶可能在游覽前和游覽中改變主意，而且郵輪公司也可能會(huì)為了利用新時(shí)機(jī)或應(yīng)對未知事件改變效勞。按照當(dāng)前方法設(shè)計(jì)的系統(tǒng)，大局部變更都以極高的運(yùn)營本錢人工處理。使用基于動(dòng)態(tài)業(yè)務(wù)應(yīng)用架構(gòu)原則設(shè)計(jì)出的系統(tǒng)，來自客戶和內(nèi)部管理決策的變更由兩個(gè)與正常工作完全集成的變更管理子系統(tǒng)負(fù)責(zé)。這不僅能降低本錢，而且還提高了效勞質(zhì)量，甚至可以最優(yōu)化運(yùn)營來提高利潤。因?yàn)槭峭耆ㄓ玫?，它還可以重用標(biāo)準(zhǔn)組件。最終結(jié)果對于參與的每個(gè)人、業(yè)務(wù)、IT和客戶來說是多贏的。圖3.動(dòng)態(tài)操作有3個(gè)維度——正常事件、內(nèi)部控制和外部反響動(dòng)態(tài)業(yè)務(wù)應(yīng)用的目標(biāo)之一就是使設(shè)計(jì)和軟件實(shí)現(xiàn)變得簡單，以支持對所有業(yè)務(wù)來說司空見慣的動(dòng)態(tài)系統(tǒng)。以我們的經(jīng)歷，與一個(gè)框架優(yōu)先的工程學(xué)相結(jié)合是構(gòu)建一個(gè)DBA的最有效的技術(shù)方法。設(shè)計(jì)企業(yè)系統(tǒng)要求框架先行構(gòu)建動(dòng)態(tài)業(yè)務(wù)應(yīng)用說起來簡單，做起來難。工程，包括軟件工程，都采用了有百年歷史的框架優(yōu)先方法。設(shè)計(jì)一座橋梁、一架飛機(jī)或者甚至是一個(gè)軟件應(yīng)用都使用一樣的方法：一個(gè)設(shè)計(jì)團(tuán)隊(duì)先收集需求，然后使用一組定義良好的框架步驟來設(shè)計(jì)和構(gòu)建系統(tǒng)。在設(shè)計(jì)橋梁和其他工程系統(tǒng)時(shí)，現(xiàn)有框架已被證明非常成功。但在使用它來為業(yè)務(wù)系統(tǒng)開發(fā)軟件時(shí)，卻碰了壁。這兩類系統(tǒng)之間有一個(gè)根本區(qū)別。在設(shè)計(jì)橋梁和飛機(jī)時(shí)，最終結(jié)果總是一個(gè)擁有靜態(tài)架構(gòu)的系統(tǒng)：當(dāng)變更發(fā)生時(shí)，如增加橋梁負(fù)重或飛機(jī)速度，整個(gè)系統(tǒng)可能就要重頭重新設(shè)計(jì)。不幸的是，軟件也常常使用一個(gè)靜態(tài)架構(gòu)進(jìn)展設(shè)計(jì)：每當(dāng)一個(gè)非預(yù)期的變更被引入到運(yùn)營中時(shí)，很可能所有事情都停了下來，使用包含新增功能的系統(tǒng)替代現(xiàn)有系統(tǒng)。因?yàn)闃I(yè)務(wù)運(yùn)營在一個(gè)不斷變化的環(huán)境中，而且比以往更依賴IT系統(tǒng)，這種停——走式的解決方案是不可承受的。持續(xù)升級(jí)和在企業(yè)根底設(shè)施中集成系統(tǒng)的本錢已經(jīng)到達(dá)了無法支撐的地步。依賴業(yè)務(wù)涉眾作為我們?nèi)啃枨蟮妮斎胧紫染褪莻€(gè)問題?？紤]到需求，目前還沒有真正適合動(dòng)態(tài)操作的“框架優(yōu)先〞軟件設(shè)計(jì)方法。甚至卡內(nèi)基梅隆軟件工程學(xué)院也表示架構(gòu)是由場景驅(qū)動(dòng)的，場景以涉眾輸入為根底被創(chuàng)立出來：“誘導(dǎo)一個(gè)軟件密集型系統(tǒng)的業(yè)務(wù)目標(biāo)是標(biāo)準(zhǔn)架構(gòu)設(shè)計(jì)和分析方法的一個(gè)組成局部。業(yè)務(wù)目標(biāo)是驅(qū)動(dòng)方法的引擎，通過將它們的實(shí)現(xiàn)作為場景……一個(gè)理想的設(shè)計(jì)方法或過程必須考慮眾多涉眾和眾多影響。〞作為工程師，當(dāng)我們收集系統(tǒng)需求時(shí)，我們怎能知道我們得到了正確的場景或是否遇上了正確的涉眾.我們又如何能說明業(yè)務(wù)未來的變化，而這些變化通常連參與的涉眾都不知道.“企業(yè)經(jīng)營者和企業(yè)設(shè)計(jì)師之間存在著根本區(qū)別。為了說明這點(diǎn)，考慮一下在一架飛機(jī)成功操作背后的兩種最重要的人。一個(gè)是飛機(jī)設(shè)計(jì)師，另一個(gè)是這架飛機(jī)的飛行員。設(shè)計(jì)師創(chuàng)造的飛機(jī)連平庸的飛行員都可成功駕駛。一般情況下，經(jīng)理更像是飛行員而非一個(gè)設(shè)計(jì)師。一個(gè)經(jīng)理管理一個(gè)組織，這和一個(gè)飛行員駕駛飛機(jī)沒什么兩樣。飛行員的成功依賴于那些創(chuàng)造了一架成功飛機(jī)的飛機(jī)設(shè)計(jì)師。另一方面，是誰來設(shè)計(jì)一家由管理者管理的公司呢.幾乎從沒有任何人有意識(shí)和有思想的去設(shè)計(jì)一個(gè)組織，以取得有方案的增長和穩(wěn)定性。在當(dāng)前的管理學(xué)校中，教育培養(yǎng)的是企業(yè)的經(jīng)營者，而如何設(shè)計(jì)企業(yè)幾乎不受重視。〞在幾年前完成的報(bào)告“設(shè)計(jì)未來〞中，MIT的教授和系統(tǒng)動(dòng)態(tài)之父JayForrester，指出這個(gè)問題是我們?yōu)槠髽I(yè)設(shè)計(jì)系統(tǒng)的根本限制：Forrester的觀察進(jìn)一步使當(dāng)前的企業(yè)架構(gòu)方法失效。在我們需要設(shè)計(jì)一個(gè)企業(yè)系統(tǒng)架構(gòu)時(shí)，作為知識(shí)主要來源的涉眾甚至是錯(cuò)誤的分類。他們是企業(yè)的“用戶〞，不是“設(shè)計(jì)師〞。在設(shè)計(jì)飛機(jī)時(shí)，飛機(jī)設(shè)計(jì)師決不可能去詢問飛行員或乘客關(guān)于飛機(jī)制造方面的事情。但是，在學(xué)校、工程或MBA課程中卻沒有企業(yè)設(shè)計(jì)這門課。則回到企業(yè)架構(gòu)，其中有一個(gè)根本的斷檔。企業(yè)架構(gòu)的“用戶〞是企業(yè)涉眾，很可能是熟悉企業(yè)動(dòng)態(tài)性的企業(yè)畢業(yè)生，但是他們不熟悉工程方法。企業(yè)系統(tǒng)的設(shè)計(jì)者和構(gòu)建者——軟件工程師——熟悉靜態(tài)框架，但是對動(dòng)態(tài)框架卻很陌生。事實(shí)上，還沒有說明業(yè)務(wù)動(dòng)態(tài)的框架。根據(jù)企業(yè)架構(gòu)框架，這是一個(gè)需要填補(bǔ)的缺口。這個(gè)框架只描述企業(yè)是如何“被設(shè)計(jì)的〞，但是也會(huì)定義開發(fā)路線圖和主要組件，使用它們來構(gòu)建企業(yè)的支持系統(tǒng)。圖4.企業(yè)架構(gòu)的業(yè)務(wù)和工程方法我們建議根本改變我們架構(gòu)和設(shè)計(jì)信息系統(tǒng)的方式，以一種不要求業(yè)務(wù)涉眾作為主要輸入的方式。我們推薦利用一個(gè)以業(yè)務(wù)實(shí)體生命周期和事件模型為中心的框架作為架構(gòu)的主要輸入來源。業(yè)務(wù)場景只被用來微調(diào)一個(gè)已完架構(gòu)，而不是作為主要驅(qū)動(dòng)力。這種框架優(yōu)先方法從一開場就說明了業(yè)務(wù)動(dòng)態(tài)，而不是事后諸葛亮。它暗示被設(shè)計(jì)的企業(yè)應(yīng)用是動(dòng)態(tài)適應(yīng)的，而不是像由今天的方法論所實(shí)現(xiàn)的那樣是靜態(tài)適應(yīng)的。這種方法成數(shù)量級(jí)的減小了開發(fā)和維護(hù)軟件的本錢，并砍掉了與改變和維護(hù)現(xiàn)有系統(tǒng)直接相關(guān)的超過70%的IT開銷。Fig5.基于框架的軟件解決方案開發(fā)方法在我們建議的方法中，業(yè)務(wù)場景只被作為一個(gè)已完架構(gòu)的微調(diào)，而不是主要驅(qū)動(dòng)力。我們將我們的直覺、經(jīng)歷和技巧輸入到設(shè)計(jì)過程中越晚，產(chǎn)生導(dǎo)致巨大損失的錯(cuò)誤的可能性就越少。由涉眾輸入引起的需求變更會(huì)在已經(jīng)建好的現(xiàn)有解決方案框架中處理，減少了風(fēng)險(xiǎn)和延遲。一份Standish報(bào)告研究說明，超過1千萬美元的工程，成功率只有3%。行業(yè)咨詢和哈佛商學(xué)院教授AndrewMcAfee表示，部署如此高本錢技術(shù)〔如ERP、CRM、供應(yīng)鏈管理、電子商務(wù)和其他企業(yè)應(yīng)用〕組織的成功率在25%~70%之間。McAfee總結(jié)說：“這些面臨的問題并非是單獨(dú)的，它們都是同一事情的不同例子，根本上都是使用IT改變業(yè)務(wù)過程的結(jié)果。〞。最近，這些百分比有所提高，但是對于復(fù)雜系統(tǒng)IT仍缺乏清晰的路線。框架優(yōu)先的方法能使業(yè)務(wù)變化集成到IT實(shí)現(xiàn)中，并提供了業(yè)務(wù)和技術(shù)之間更清晰的轉(zhuǎn)換，可以將成功率提高接近100%。建構(gòu)復(fù)雜系統(tǒng)的時(shí)間由幾個(gè)月或幾年縮短至幾天。動(dòng)態(tài)操作的效勞器架構(gòu)——忘記SOA，迎接信息裝配線90年代早期，事件幾乎是每本面向?qū)ο蠓椒ㄕ摃械暮诵慕巧?。隨著象Windows這樣基于GUI操作系統(tǒng)的出現(xiàn)，GUI開發(fā)平臺(tái)依靠復(fù)雜事件模型來設(shè)計(jì)和構(gòu)建單個(gè)應(yīng)用。但是，在客戶機(jī)-效勞器環(huán)境中，效勞器端的事件處理總是基于一個(gè)簡單得多的模型。當(dāng)基于Web的技術(shù)〔如J2EE和.NET〕開場替代傳統(tǒng)的客戶機(jī)-效勞器應(yīng)用，客戶機(jī)和效勞器都經(jīng)歷了根本的轉(zhuǎn)變。客戶端的富OS事件模型由Web瀏覽器和原始的腳本語言代替。在效勞器端，事件處理由無狀態(tài)、扁平的、靜態(tài)架構(gòu)所替代。其方式非常類似將網(wǎng)頁傳給Web瀏覽器的方式。為了模擬現(xiàn)實(shí)世界的需求，需要一個(gè)有狀態(tài)的、層次的、動(dòng)態(tài)的和分布式的架構(gòu)，設(shè)計(jì)必須嚴(yán)重依賴數(shù)據(jù)庫來存儲(chǔ)*圍廣泛的各種動(dòng)態(tài)信息。但是根據(jù)其定義，關(guān)系數(shù)據(jù)庫非常適合存儲(chǔ)不常變化的數(shù)據(jù)間關(guān)系。保存動(dòng)態(tài)、分布式、層次的和有狀態(tài)信息要求一個(gè)不同的根底設(shè)施，它不是以關(guān)系數(shù)據(jù)庫為中心的?；赪eb的技術(shù)為支持現(xiàn)實(shí)世界系統(tǒng)引入了其他挑戰(zhàn)。當(dāng)J2EE應(yīng)用效勞器在一個(gè)分布式環(huán)境被使用時(shí)，使用Java作為編程語言的一個(gè)最大優(yōu)勢完全沒有了。Java虛擬機(jī)的垃圾回收從來沒有被設(shè)計(jì)成能自動(dòng)去除在多實(shí)例間交換的內(nèi)存對象。在這種情況下，架構(gòu)師和設(shè)計(jì)師必須編排整個(gè)對象生命周期，不考慮編程語言的能力。甚至在數(shù)據(jù)保存在數(shù)據(jù)庫中時(shí)，這種一樣的數(shù)據(jù)去除問題也變得非常困難。正如我們已經(jīng)看到的，一旦我們能從正常工作中別離變化，架構(gòu)就能只依賴事件和生命周期進(jìn)展設(shè)計(jì)和實(shí)現(xiàn)。圍繞生命周期進(jìn)展系統(tǒng)設(shè)計(jì)已經(jīng)經(jīng)歷了一個(gè)世紀(jì)——它被稱為裝配線。在裝配線于20世紀(jì)早期引入之前，制造業(yè)的工作方式多多少少和今天面向效勞架構(gòu)〔SOA〕處理信息的方式一樣。每個(gè)對于SOA效勞的調(diào)用一般都被視為一個(gè)無狀態(tài)調(diào)用。為了說明以前調(diào)用的歷史，每個(gè)效勞必須完全實(shí)現(xiàn)如何處理系統(tǒng)內(nèi)部狀態(tài)。一旦需求改變，幾乎所有效勞也需要以本錢極高的方式重新編碼來改變它們各自的實(shí)現(xiàn)。圖6.效勞器架構(gòu)是以事件模型為根底的我們建議使用以事件模型和生命周期為中心的信息架構(gòu)作為業(yè)務(wù)需求和系統(tǒng)架構(gòu)的雙向翻譯平臺(tái)。事件模型在下一級(jí)被擴(kuò)展成四個(gè)根本模型：狀態(tài)、分布式、層次和動(dòng)態(tài)。所有這5個(gè)模型可被根底需求和架構(gòu)模型中的業(yè)務(wù)或技術(shù)人員方便地解釋：事件模型/生命周期——它是構(gòu)建其他模型的根底核心。對業(yè)務(wù)用戶來說，它是價(jià)值流，反映產(chǎn)品/效勞生命周期和為客戶創(chuàng)造價(jià)值的過程序列。對技術(shù)人員來說，同一事件序列反映了代表業(yè)務(wù)實(shí)體對象的狀態(tài)變化。最終結(jié)果是，事件模型扮演了解耦元素，大大簡化了設(shè)計(jì)和實(shí)現(xiàn)。事件模型還扮演了另一個(gè)重要角色。因?yàn)槠渌膫€(gè)模型是圍繞事件模型而構(gòu)建的，它還扮演一個(gè)集成平臺(tái)。事實(shí)上，事件模型是創(chuàng)造實(shí)現(xiàn)變更、層次和分布式組件的唯一方法。狀態(tài)模型——對業(yè)務(wù)用戶來說，這個(gè)模型扮演了企業(yè)的面板，捕獲當(dāng)前經(jīng)營的整體狀況。對技術(shù)人員來說，它是系統(tǒng)的整體狀態(tài)，它是全部生命周期實(shí)例的當(dāng)前狀態(tài)，以及它們的變化之和。分布式模型——對業(yè)務(wù)用戶來說，這個(gè)模型捕獲了其生命周期內(nèi)控制產(chǎn)品/效勞的各種組織。對技術(shù)人員來說，主實(shí)體只能基于分布式模型來控制。層次模型——所有業(yè)務(wù)都有代表管理層級(jí)的層次構(gòu)造。所有系統(tǒng)設(shè)計(jì)應(yīng)該在架構(gòu)上反映這種控制層次。正如銷售VP不能給CEO下命令一樣，低層級(jí)的組件不能給高層級(jí)的組件發(fā)送執(zhí)行“命令〞。動(dòng)態(tài)模型——繼事件模型之后最重要的模型。業(yè)務(wù)用戶使用它來捕獲平時(shí)必須被處理的全部變更。如前所述，有兩種變化類型：外部，如客戶輸入；內(nèi)部，如管理決策。對技術(shù)人員來說，動(dòng)態(tài)模型被翻譯成一個(gè)匹配各種事件、生命周期和變化類型的插件架構(gòu)。這5個(gè)模型不僅可以被用在初始設(shè)計(jì)，對貫穿整個(gè)系統(tǒng)生命周期的需求變更亦有裨益。它們一起形成了自適應(yīng)系統(tǒng)設(shè)計(jì)所缺失的框架步驟。這5個(gè)模型排除了用例作為企業(yè)架構(gòu)的主輸入的必要性。它們可以被翻譯成一個(gè)清晰和全面的工程問題集合，與在橋梁或飛機(jī)設(shè)計(jì)中使用的方法類似。圖7.自適應(yīng)架構(gòu)是以5個(gè)模型為根底的信息架構(gòu)結(jié)果這5個(gè)模型定義了以信息變化和裝配線為中心的動(dòng)態(tài)業(yè)務(wù)應(yīng)用通用架構(gòu)。最重要的子系統(tǒng)是：靜態(tài)模型、變更管理、虛擬裝配對象和事件處理。在下一個(gè)細(xì)化層級(jí)，還有兩個(gè)子系統(tǒng)：系統(tǒng)命令和控制與持久化。這個(gè)架構(gòu)還解決了在尋求一個(gè)適用于事務(wù)型工作流隱喻的通用解決方案過程中長期存在的問題，它是由JimGray[3]在幾十年前提出的。因?yàn)檎麄€(gè)設(shè)計(jì)以單個(gè)事件的執(zhí)行為中心，不僅可以實(shí)現(xiàn)“移動(dòng)到下一個(gè)裝配步驟〞，而且也可實(shí)現(xiàn)“移動(dòng)到前一個(gè)裝配步驟〞。實(shí)現(xiàn)需要根據(jù)用戶的輸入決定前往哪個(gè)“方向〞。通過將多個(gè)步驟“〞在一起，可以使用一樣的架構(gòu)實(shí)現(xiàn)一個(gè)事務(wù)型工作流的“撤銷〔Undo〕〞操作。動(dòng)態(tài)業(yè)務(wù)應(yīng)用的一個(gè)關(guān)鍵元素是事件處理。使用新的自適應(yīng)系統(tǒng)信息理論，可以使用一個(gè)通用組件構(gòu)造來“執(zhí)行〞每個(gè)事件。這個(gè)組件使用聲明性編程來內(nèi)嵌業(yè)務(wù)邏輯、調(diào)用工作流引擎、調(diào)度器和業(yè)務(wù)規(guī)則引擎。這個(gè)實(shí)現(xiàn)不僅可以極大加速自適應(yīng)系統(tǒng)開發(fā)，而且可以使后期改變非常容易處理，也減少了維護(hù)復(fù)雜集成的需要。我們建議圍繞事件〔操作〕和事件生命周期創(chuàng)立一個(gè)供應(yīng)控制、運(yùn)營和環(huán)境的物理模型。生命周期控制器為