讓企業(yè)SOA項目更可控之必備十大戒條.doc

讓企業(yè)SOA項目更可控之必備十大戒條面向服務(wù)的架構(gòu)(SOA)是一種組織信息處理的方法。各系統(tǒng)為協(xié)同工作在各方面達(dá)成了協(xié)議，SOA通過減少這些協(xié)議的數(shù)量，能夠降低信息系統(tǒng)互操作性的成本。如果SOA能得到大范圍的應(yīng)用，系統(tǒng)將呈現(xiàn)與現(xiàn)在截然不同的前景，這就好比當(dāng)今貨運(yùn)行業(yè)有別于集裝箱出現(xiàn)前的貨運(yùn)業(yè)時代一般。然而，目前的應(yīng)用方式卻導(dǎo)致了額外的開支卻并未體現(xiàn)出這些互操作性的優(yōu)勢。將適用于數(shù)據(jù)庫時代的范式應(yīng)用于SOA中，會招致反效果，往往是愚蠢的，有時甚至是十分危險的設(shè)計。這些模式必須由新的思想和行為方式所替代，以確保SOA朝著接口更簡單、IT方案更優(yōu)化以及項目更可控的方向發(fā)展。這一點(diǎn)可以通過遵守以下十大戒條來實現(xiàn)。引言：SOA的潛在影響面向服務(wù)的架構(gòu)(SOA)是一種組織信息處理的方法。這種方法以服務(wù)的形式描述所有交互活動，服務(wù)請求者請求代理完成某些處理，代理確保處理得以完成并將處理結(jié)果反饋給服務(wù)請求者。這種思維方式可以應(yīng)用于業(yè)務(wù)級別，以描述各組織機(jī)構(gòu)之間的交互;應(yīng)用于功能級別，以描述組成業(yè)務(wù)流程的活動的交互方式;應(yīng)用到信息系統(tǒng)級別，以描述系統(tǒng)及系統(tǒng)各部分的交互方式。每個級別的準(zhǔn)則都是相同的：代理完成所需工作的方式與請求者無關(guān)，乃至與是否完全自動、完全人工亦或兩者兼具都無關(guān)系。哪怕代理將部分或者甚至全部工作外包給其他代理完成也與請求者無關(guān)。所有請求者所需關(guān)注的是與代理就以下方面達(dá)成一致：請求及響應(yīng)應(yīng)該如何制定，以及服務(wù)的效果如何。SOA被大肆宣揚(yáng)為一種具有巨大潛力的范式，能夠降低系統(tǒng)發(fā)展、測試及維護(hù)的成本。特別需要指出的是，SOA承諾可以通過大幅度減少達(dá)成協(xié)議的因素的數(shù)量，從而降低信息系統(tǒng)各模塊協(xié)同工作的成本。采用SOA，諸如像計算平臺和數(shù)據(jù)格式之間的差別造成的系統(tǒng)間通信屏障會較采用早期的范式要少得多。這使得更大范圍上的協(xié)作變得可能，因為它減少了障礙，使系統(tǒng)設(shè)計師們不必被強(qiáng)行要求相互達(dá)成一致，就此而言，也使得系統(tǒng)配置員之間不必被強(qiáng)行要求達(dá)成一致。如果這種承諾可以實現(xiàn)，其結(jié)果將會是革命性的。就像汽車改變了城市區(qū)域形態(tài)，集裝箱運(yùn)輸革新了貨運(yùn)行業(yè)，以及交易費(fèi)用的降低發(fā)展了現(xiàn)代自由市場經(jīng)濟(jì)，SOA將開啟新的合作模式。當(dāng)SOA主導(dǎo)我們應(yīng)用IT的方式，系統(tǒng)前景將與今日迥然不同，好比圍繞汽車來設(shè)計規(guī)劃的城市和圍繞火車來設(shè)計規(guī)劃的城市截然不同一般。對我們之中那些思維受限于目前技術(shù)的人來說，SOA可以產(chǎn)生多大的不同是難以想象的。然而SOA所提供的靈活性優(yōu)勢就好比汽車勝過火車一樣：即便火車可以被制造跑得和汽車一樣快，火車還是絕不可能像汽車那樣提供門到門的運(yùn)輸服務(wù)。把火車站安置在每個車道的盡頭，亦或甚至把鐵軌鋪設(shè)在每條道路上都是根本不現(xiàn)實的。為何此影響尚未實現(xiàn)為獲取新范式帶來的好處，我們必須好好利用其所能提供的各種新的可能性。遺憾的是，目前圍繞SOA的言過其實的宣傳對這些可能性的提及是言之甚少。大部分討論似乎都關(guān)注于如何利用SOA幫助單獨(dú)信息系統(tǒng)更快速地開發(fā)。然而，這并非SOA所能創(chuàng)造的最大價值之處。事實上，SOA是否真正能夠改進(jìn)以往的方法，即各個功能點(diǎn)通過某一共同的數(shù)據(jù)池(通常是以數(shù)據(jù)庫的方式實現(xiàn))來實現(xiàn)交互，還存在爭議。使用SOA來構(gòu)建單獨(dú)、孤立的信息系統(tǒng)就像使用集裝箱在加工廠附近搬運(yùn)貨物一樣：當(dāng)然，它限定了內(nèi)部物流的順序和組織，但是集裝箱更多的是擋了道路而非提供幫助。SOA使信息系統(tǒng)間達(dá)到更好的互操作性，就像集裝箱促使了運(yùn)輸商之間的互操作性一樣。那是一種重要優(yōu)勢，因為從需求確定到信息系統(tǒng)可操作之間的時間周期通常很大程度上是由互操作性決定的。要使某一信息系統(tǒng)能夠與其操作環(huán)境中的其他系統(tǒng)一起工作，那將會花費(fèi)比重新構(gòu)建這樣一個系統(tǒng)更多的時間和精力。關(guān)注于SOA在信息系統(tǒng)內(nèi)部而非各系統(tǒng)之間的使用是情況更加惡化的征兆：因為看起來SOA是一種全新的處理我們一直以來所做的事情的方式，我們無法直接獲取它所帶來的收益。SOA概念和技術(shù)正為目前的系統(tǒng)開發(fā)范式所利用。這些范式還是數(shù)據(jù)庫時代的開發(fā)產(chǎn)物，同時也帶有數(shù)據(jù)庫技術(shù)的一些限制。在這些限制下應(yīng)用SOA將會導(dǎo)致額外的開支，而不能獲得額外的收益。然而，這些“數(shù)據(jù)庫化”的范式是如此普遍和有害以至于我們常常忽略了它們對我們的思維影響有多大。它們是如此根深蒂固，以至于我們會不自覺將其視作常理。遺憾的是，這樣通常招致相反效果，常常是愚蠢的，有時甚至是相當(dāng)危險的。它們導(dǎo)致了一種不好的方案，這種方案集合了數(shù)據(jù)庫時代的缺點(diǎn)以及SOA不好的一面，而又不能體現(xiàn)SOA必定提供的優(yōu)點(diǎn)。需要改變什么SOA范式有其自身的常識守則，較之?dāng)?shù)據(jù)庫范式的守則截然不同?；窘渎捎惺棥Ｇ拔屙楆P(guān)于如何簡化事物，使其比數(shù)據(jù)庫化的范式要求更加簡化從堅持要點(diǎn)意義上更加簡化。如果我們以此種方式簡化事物，同一問題的不同解決方案相互間協(xié)作的可能性將大大提升。接下來的四項關(guān)于使IT解決方案優(yōu)于同等數(shù)據(jù)庫解決方案，這是通過阻止那些戴著有色眼鏡、慣于數(shù)據(jù)庫思維方式的人開發(fā)出無效解決方案來實現(xiàn)的。最后一項關(guān)于如何使IT更可控，尤其是組織系統(tǒng)開發(fā)以降低項目復(fù)雜度和風(fēng)險。SOA使這些成為了可能同樣也是必須的因為它讓更多的功能交付成為基礎(chǔ)架構(gòu)。簡化之理論在高空雜技表演中，高效的合作的基礎(chǔ)是每個空中飛人演員完全默契地配合，對方會及時地在每個時點(diǎn)出現(xiàn)。一些空中飛人演員非常自信，他們經(jīng)常蒙著眼進(jìn)行表演。他們能夠接到彼此正因為他們確定在某個特定時刻對方只可能出現(xiàn)在一個可能位置。成功應(yīng)用SOA以達(dá)到最大化的協(xié)作性與高空雜技表演非常相似?；ゲ僮餍砸箨P(guān)于如何進(jìn)行交流的解決方案從數(shù)以百萬計減少到只有一個，交互雙方都可以依賴該方案。這并不意味著其他方案有問題：這好比我們既可以靠左行駛也可以靠右行駛，但重要的是我們必須都靠同一邊行駛。當(dāng)只有一方執(zhí)行服務(wù)，一方接受服務(wù)時，只要雙方協(xié)議好，具體使用哪種方案其實并沒有太大區(qū)別。雙方中任一方的特異性可以決定最終方案，無需做更多的溝通努力。畢竟，無論使用哪種方案，這些特異性總要被處理。但是如果是多方請求服務(wù)或者多方執(zhí)行服務(wù)，那將呈現(xiàn)不一樣的情景。此時使通信方案精簡非常重要，如此，各方必須處理各自的特異性，無需面對另一方。將信息通信與外科移植手術(shù)對比很能說明問題。成功的移植手術(shù)，要將一個人身上的器官移植到另一個人身上，要求該移植器官必須在多方面與接收者匹配，而其中大部分匹配因素與該器官的生物功能無關(guān)。換句話說，被移植的器官必須和接受者本身有相同的特征。因此，我們的器官不能像拼搭樂高積木一樣隨便被移植。目前的信息通信恰恰如此。當(dāng)一個信息系統(tǒng)為另一個系統(tǒng)提供服務(wù)時，它們必須在很多方面達(dá)成一致。它們必須使用相同的詞匯(元數(shù)據(jù))、相同的由一方調(diào)用而另一方執(zhí)行的功能集、對于每個功能請求應(yīng)答數(shù)據(jù)內(nèi)容的相同期望、相同的編碼系統(tǒng)、相同的技術(shù)通訊協(xié)議、相同的用于信息傳遞的尋址模式、兼容的可預(yù)期的響應(yīng)速率、兼容的確保消息不被丟失的技術(shù)、兼容的認(rèn)證機(jī)制以確保雙方安全通信而不是與冒名者通信、兼容的加密技術(shù)以及密鑰管理以確保消息不被竊聽或者篡改等等。為了促進(jìn)互操作性，必須確保參與各方從彼此獨(dú)立制定各自標(biāo)準(zhǔn)變?yōu)樾纬杉嫒莸臉?biāo)準(zhǔn)規(guī)范。只有當(dāng)一些非常嚴(yán)謹(jǐn)?shù)囊?guī)則得到遵守時這才有實現(xiàn)的可能，接口才能減至精要。如此一來特異性將無容身之地。嚴(yán)謹(jǐn)?shù)囊?guī)則都關(guān)注于如何使得服務(wù)接口更為簡單。我們規(guī)定的越少，爭議的余地就越小。1.不了解你不需要了解的你不需要去了解的東西不會傷害到你SOA范式的本質(zhì)在于使得合作各方或系統(tǒng)之間達(dá)成最少限度的協(xié)議卻可以實現(xiàn)最大程度的合作。這是一種巨大的優(yōu)勢，因為任何你不需要了解的東西既不需要被測試也不需要被維護(hù)。你不需要去了解的東西不會傷害到你。假設(shè)40%的系統(tǒng)開發(fā)成本用于測試上，而高達(dá)80%的信息系統(tǒng)生命周期的成本被花費(fèi)到了系統(tǒng)維護(hù)階段，任何SOA范式讓你無需了解的東西都代表了你能節(jié)省的金錢。元數(shù)據(jù)你最不需要了解的就是結(jié)構(gòu)、含義以及容許值這些元數(shù)據(jù)不會被系統(tǒng)中篩選、排序或執(zhí)行計算的邏輯使用的數(shù)據(jù)。你并不需要去了解這些，因為SOA技術(shù)使得數(shù)據(jù)和元數(shù)據(jù)同時出現(xiàn)。你的系統(tǒng)可以實時解讀元數(shù)據(jù)，所以如果你要做的僅僅是獲取、呈現(xiàn)或傳送相應(yīng)的數(shù)據(jù)，你完全不需要為系統(tǒng)構(gòu)建元數(shù)據(jù)知識。在有相當(dāng)精密的表示(presentation)功能的幫助下，它甚至可以為用戶實現(xiàn)各種各樣特定的篩選及計算，且只使用與已有數(shù)據(jù)同時提供的元數(shù)據(jù)，而不是內(nèi)部構(gòu)建元數(shù)據(jù)。通過解讀數(shù)據(jù)相應(yīng)的元數(shù)據(jù)，而不是把元數(shù)據(jù)構(gòu)建到系統(tǒng)中，你的系統(tǒng)不需要隨元數(shù)據(jù)的改變而改變。需要改變的僅僅是源系統(tǒng)。想想如果遵守該守則，你能在開發(fā)、測試和維護(hù)上節(jié)省多少金錢!記住，在兩個系統(tǒng)上做更改，平均來說，其復(fù)雜度是在單個系統(tǒng)做更改的四倍，因為其中包含了所有各方的協(xié)作。對于很多面對客戶的系統(tǒng)來說，表示以及特定篩選功能基本是其主要的功能。這些系統(tǒng)只針對最基本的客戶數(shù)據(jù)要求內(nèi)部構(gòu)建元數(shù)據(jù)。這并不包括當(dāng)前或過去的訂單、客戶通訊錄、照片、信函以及任何可用于展示的其他數(shù)據(jù)，所有這些數(shù)據(jù)都可以用一種不需要這些數(shù)據(jù)本質(zhì)相關(guān)知識的方式進(jìn)行表示，內(nèi)建于系統(tǒng)中。技術(shù)許多你不需要了解的事情是與技術(shù)相關(guān)的。有了SOA，你不需要了解你正在接口的系統(tǒng)是否采用“軟件即服務(wù)”(Software-as-aservice)，不需要了解實施該系統(tǒng)的計算機(jī)安放在何處，是哪種類型的計算機(jī)或者運(yùn)行于何種操作系統(tǒng)，防火墻是如何配置，使用的是哪種數(shù)據(jù)庫管理系統(tǒng)，亦或可以使用哪種交易管理系統(tǒng)。其他你不需要了解的事情是與你所通信的系統(tǒng)內(nèi)部相關(guān)的。尤其是，你不需要去了解任何用于內(nèi)部數(shù)據(jù)存儲的元數(shù)據(jù)，因為任何其他系統(tǒng)需要同XSD一致的轉(zhuǎn)換都是其自身的問題，而不是你的。即便如此，使用SOA進(jìn)行通信的各方必須達(dá)成一致的技術(shù)相關(guān)的標(biāo)準(zhǔn)還有很多選擇。特別是有很多與Web服務(wù)相關(guān)的那些標(biāo)準(zhǔn)，SOA從業(yè)者將其統(tǒng)稱為WS-*標(biāo)準(zhǔn)(*指可以使用很多可能的標(biāo)簽替換)。在一定程度上，這些標(biāo)準(zhǔn)提出得很恰當(dāng)，因為SOA社區(qū)并沒有滿足于不去了解它不需要了解的東西;本文這個白皮書給出了一些指導(dǎo)以期降低由這些標(biāo)準(zhǔn)引起的問題的影響。遵守這些指導(dǎo)，SOA需要的先期協(xié)議將比其他方法要少得多。設(shè)計穩(wěn)定的接口如果想獲取SOA提供的種種好處，不去了解你不需要了解的東西會成為你的習(xí)慣。請銘記這點(diǎn)!比如說，當(dāng)設(shè)計一個訂貨服務(wù)時，請記住服務(wù)請求者只需要知道，當(dāng)他需要貨物的時候該貨物是否會有貨，而不需要去了解當(dāng)前的庫存量。如果你的程序調(diào)用某一安全服務(wù)以判斷請求活動是否被授權(quán)，不要在系統(tǒng)內(nèi)構(gòu)建任何超過其所需服務(wù)工作的知識。例如，如果安全服務(wù)需要使用輸入到程序的安全證書，唯一必須做的就是傳遞該證書!對你來說，它們只是被封裝在輸入消息中的單個數(shù)據(jù)項。該證書是否是格式完整的XML也不要去驗證。如果，由于某些只有那些負(fù)責(zé)安全的小鬼知道的原因，他們選擇了違背標(biāo)準(zhǔn)的SOA操作或?qū)ψC書進(jìn)行了加密，那么這是他們的問題，不是你的。如果他們改變了任何與證書相關(guān)的東西，你的程序不應(yīng)該為此做任何改變或調(diào)整。任何你不需要了解的東西不會傷害到你。當(dāng)然了，除非你硬要去了解它，在這種情況下如果你們不想在SOA上浪費(fèi)時間的話，其他人可能最好離遠(yuǎn)點(diǎn)兒。不去了解那些你不需要了解的東西可能比你想象的要難。如果你開發(fā)專門用于與你通信的信息系統(tǒng)的信息檢索服務(wù)，你的思路已經(jīng)不對了，因為你已經(jīng)把其他系統(tǒng)的知識歸并到系統(tǒng)中了。需求中的任何更改將會迫使雙方系統(tǒng)都作出更改。通常來講，比較好的方式是采用數(shù)量有限的檢索服務(wù)暴露系統(tǒng)數(shù)據(jù)，當(dāng)檢索服務(wù)結(jié)合在一起使用時，它們涵蓋了所有相關(guān)服務(wù)的信息檢索需求。例如，某個產(chǎn)品數(shù)據(jù)庫可能通過好幾個服務(wù)分別暴露出去：一個簡單的僅包含編碼、描述、部門以及產(chǎn)品定價的服務(wù)、一個暴露出所有該產(chǎn)品財務(wù)方面信息的服務(wù)，以及一個暴露出所有該產(chǎn)品物流方面信息的服務(wù)。許多系統(tǒng)僅需簡單服務(wù)即可得到滿足，大部分只需要部分?jǐn)?shù)據(jù)而非全部，或財務(wù)或物流的服務(wù)，而有一些兩者都需要，但此外沒有任何一個需要特別接口的系統(tǒng)。這種工作方式被稱為麥當(dāng)勞方式：客戶從標(biāo)準(zhǔn)產(chǎn)品中搭配出自己需要的產(chǎn)品。支持這種方式并不困難，因為不管怎樣你都需要這些服務(wù)去支持面向客戶的程序。你甚至可以用這種方式來支持非常特別的信息需求，因為那些不需要的數(shù)據(jù)可以在消費(fèi)前就過濾掉。如果不想在巨無霸漢堡中放小黃瓜，扔掉它就可以了!這種方式的基本思路是提供過多的信息要比提供過少的信息遇到的問題少，因為接收方系統(tǒng)可以很容易通過程序過濾掉不需要的信息，但是如果缺少信息那就麻煩了。不去了解你不需要了解的東西也會使得為支持業(yè)務(wù)流程所需的信息交互大大簡化。在SOA的范式中，當(dāng)你請求另一個代理為你做一些事，那就是你所需要做的全部。你不需要為代理提供可能有助于完成任務(wù)的或者是其必需的額外信息。在點(diǎn)菜時，確保有用于這道菜的原料是廚師的職責(zé)。你說出想要的東西，然后就可以靜候佳音了。反過來，代理會使用信息檢索服務(wù)來向你咨詢所有信息，但是檢索什么、何時檢索以及從何檢索，這些問題都應(yīng)該由他來決定，你無須去了解，更不用將該知識歸并至你的系統(tǒng)中。這樣，在他那一端的更改幾乎不需要你這邊作出更改。比如說，如果他決定停止維護(hù)對你數(shù)據(jù)的拷貝，你什么更改都不需要做。當(dāng)然，不去了解你不需要了解的事情確實會導(dǎo)致效率低下。原本只需要一次交換即可實現(xiàn)的操作現(xiàn)在將需要多個步驟。麥當(dāng)勞方式常常會導(dǎo)致原本一個服務(wù)即可滿足卻提供了多個服務(wù)的情況，另一邊卻還在檢索信息，而這些信息又常常是冗余而非十分必要?？倳霈F(xiàn)一些情形，可以通過好的商業(yè)意識來優(yōu)化這些通信模式。也會有很多場合你會想要優(yōu)化用戶接口，那也只是因為當(dāng)前的表示設(shè)備并不擅長提供給用戶吸引人的界面。但是在你優(yōu)化之前，請考慮你會失去什么樣的靈活性。另外絕不要想去優(yōu)化那些尚未穩(wěn)定的功能需求。2.不要了解你還不能了解的事情為時過早的規(guī)范凍結(jié)數(shù)據(jù)庫范式中，一個真正的難題在于：它要求在你還未足夠了解并有能力去確定數(shù)據(jù)的具體結(jié)構(gòu)前，就去做這件事。因為它們忽視了一個生活中簡單的事實：只有當(dāng)用戶看到他們不想看到的東西時，他們才知道其真正想要的是什么。其工作原理是這樣：一旦完成了數(shù)據(jù)結(jié)構(gòu)的設(shè)計，任何后續(xù)修改都會引起雜亂的數(shù)據(jù)庫轉(zhuǎn)換，除此之外每個訪問該數(shù)據(jù)庫的系統(tǒng)也會改變。所有這些改變必須都協(xié)調(diào)好，當(dāng)所有對數(shù)據(jù)庫的操作都限制在單個系統(tǒng)時候，這種協(xié)調(diào)是很困難的，但如果有多個系統(tǒng)都在操作，那就更難了，尤其是：如果其中有些系統(tǒng)被不受你控制的參與方管理的時候。事實上，在系統(tǒng)開發(fā)階段做這些更改就已經(jīng)很成問題了。其后果是，數(shù)據(jù)庫設(shè)計早在系統(tǒng)開發(fā)階段就被凍結(jié)，然后數(shù)據(jù)分析師們再去竭力修正這些設(shè)計?，F(xiàn)在的問題是數(shù)據(jù)分析師們面臨著不可能完成的工作。他們必須在用戶理解這個設(shè)計(且不說贊賞這個設(shè)計實際應(yīng)用如何)前就確定該設(shè)計。只有在過了很久之后系統(tǒng)已經(jīng)構(gòu)建好之后用戶才能對該系統(tǒng)有所體會并對其是否滿足自己的需求作出評估。如果此時發(fā)現(xiàn)數(shù)據(jù)結(jié)構(gòu)上有任何大問題，要想修復(fù)就太晚了。SOA原型法你可能會問：“SOA是怎么個不同尋常呢?”說到底，難道SOA不像數(shù)據(jù)庫范式那樣一樣需要結(jié)構(gòu)化數(shù)據(jù)嗎?這個問題的簡單答案：不管請求數(shù)據(jù)時，被人工代理處理還是被自動化系統(tǒng)處理，SOA都是管用的，并且就算數(shù)據(jù)沒有被最優(yōu)結(jié)構(gòu)化，人們還是可以解讀它。比如說，用戶可以判斷信件是否正在被發(fā)送至另一個國家，無論信件的地址是用行一、行二、行三和行四來表示的，而信息系統(tǒng)需要至少“國家”來作為數(shù)據(jù)結(jié)構(gòu)可識別的一部分。仔細(xì)回答這個問題就包括了對SOA原型法的討論，這種討論包括以下幾方面：識別將被構(gòu)建到系統(tǒng)中的元數(shù)據(jù)。把它放在主命名空間中，用傳統(tǒng)方式根據(jù)其結(jié)構(gòu)把數(shù)據(jù)存儲到數(shù)據(jù)庫管理系統(tǒng)(DBMS)。例如，用戶信息，這個元數(shù)據(jù)可能由用戶ID和用戶名構(gòu)成。因為這個元數(shù)據(jù)被構(gòu)建到系統(tǒng)中，所以為了使用這些字段而把邏輯也構(gòu)建到系統(tǒng)中是完全有可能的，比如通過用戶ID檢索記錄并基于用戶名排序和篩選記錄。對每一條數(shù)據(jù)庫記錄，把不包含在主命名空間的所有數(shù)據(jù)放到一個單獨(dú)的XML字符串中，該字符串作為一個單獨(dú)的字段添加到數(shù)據(jù)庫記錄中。對每個XML字符串，構(gòu)建一個二級命名空間，開發(fā)XSD，同時添加一個單獨(dú)數(shù)據(jù)項到主命名空間。對用戶記錄的初步實現(xiàn)來說，這個字符串可能包括地址行一、行二、行三和行四的元數(shù)據(jù)。用戶記錄本身的XSD將會包括三個字段的元數(shù)據(jù)：用戶ID、用戶名和以XML字符串包括的附加的用戶相關(guān)數(shù)據(jù)。附加用戶數(shù)據(jù)的XSD包括每條地址行的元數(shù)據(jù)。使用基于XSD的邏輯來為數(shù)據(jù)庫記錄的各相關(guān)層次獲取及展示所有數(shù)據(jù)，這可以通過給每個XML字符串(包含對主記錄的字符串)增加一個標(biāo)準(zhǔn)驗證服務(wù)來實現(xiàn)。如有可能，利用某種工具來產(chǎn)生使用XSD的接口而不要自己去編程。該工具必須使用二級XML字符串所包含的元數(shù)據(jù)來將其解包，并且必須同時使用主、次兩級XSD的邏輯來獲取新記錄。其結(jié)果就是一個可運(yùn)行的原型，用戶可用以評估預(yù)期使用的系統(tǒng)。要盡量適應(yīng)和修改基于XSD的邏輯以及驗證服務(wù)直到用戶對系統(tǒng)滿意為止。就拿用戶記錄來說，一個新的針對字符串的XSD可包括以下元數(shù)據(jù)：街道地址、郵編、縣市、以及國家。使用舊XSD存儲的數(shù)據(jù)仍會正確顯示，所以無需立即將其轉(zhuǎn)換。而使用新XSD將會獲取新的記錄。一旦用戶和你確信元數(shù)據(jù)已經(jīng)穩(wěn)定了，那么請考慮把數(shù)據(jù)遷移到傳統(tǒng)的數(shù)據(jù)結(jié)構(gòu)和主命名空間。當(dāng)然，SOA原型法并不總是必要的。當(dāng)需求受限于如此多的不確定性時，請使用原型法，這樣先做原型然后再將其穩(wěn)定比較經(jīng)濟(jì)。但是請記住這個肯定要比數(shù)據(jù)庫化原型法要簡單的多。在數(shù)據(jù)庫化的時代，原型法只是可有可無，但是在SOA的時代，它便是家常便飯。不要將設(shè)計細(xì)節(jié)固定，除非你確定它們是正確的;就是這么簡單。3.除了要求的不要多做產(chǎn)品驅(qū)動的服務(wù)分解SOA主要的優(yōu)勢就是它是一個能被轉(zhuǎn)化成技術(shù)的業(yè)務(wù)概念，不像數(shù)據(jù)庫世界里那樣，技術(shù)概念總想試圖跟上業(yè)務(wù)的步伐。在SOA中，每個服務(wù)必須明確地增加價值，不只是在抽象意義層面上，而更具體地要針對那些調(diào)用方而言。發(fā)生的一切之所以這樣發(fā)生了，是因為服務(wù)請求者要求其如此。通過不實現(xiàn)任何服務(wù)請求者沒有明確要求的東西，服務(wù)可以被限定在它們的核心功能上。如果SOA中所有的參與者都積極這樣去做，那么將會使互操作性大大增加。SOA中最高層次的服務(wù)是業(yè)務(wù)交易：某個客戶下了一個貨物或服務(wù)的訂單除非訂單被供應(yīng)商拒絕否則這就開始了一個訂單交付。在SOA范式中，任何從接受訂單到訂單交付之間所發(fā)生的都可以也應(yīng)該以服務(wù)的形式實現(xiàn)。為實現(xiàn)訂單交付而要求的每個中間產(chǎn)品或狀態(tài)，供應(yīng)商會要求某些人或某些組織機(jī)構(gòu)不一定是供應(yīng)商內(nèi)部的組織來執(zhí)行交付。然后這些中間服務(wù)自身又可以分解成多個服務(wù)，一直到增加價值的基本組織層面。層次服務(wù)分解是SOA范式中非常重要的一部分，因為它使服務(wù)交付通過服務(wù)水平協(xié)議的方式管理。它可以確保每個服務(wù)都有專人負(fù)責(zé)，并且服務(wù)消費(fèi)者們知道他們會得到什么。通用的中間產(chǎn)品和通用的服務(wù)服務(wù)分解都是關(guān)于產(chǎn)品的。只有當(dāng)組成服務(wù)的那些子服務(wù)不能立即執(zhí)行時流程才會出現(xiàn)。例如，如果決定是否接受客戶訂單的服務(wù)要求：先執(zhí)行判斷訂單價值的子服務(wù)，再執(zhí)行確定客戶信用狀態(tài)的子服務(wù)，那么實現(xiàn)該服務(wù)就包含了一個流程。每個這樣的流程只與一個服務(wù)相關(guān)。如果你發(fā)現(xiàn)有個流程不僅限于單個這樣的服務(wù)，那么你很有可能是忘了把客戶的初始需求建模為服務(wù)了。有可能出現(xiàn)這樣的情況，相同的中間產(chǎn)品當(dāng)然還有相同的服務(wù)可能會被不同的高級別產(chǎn)品需要。比如，那些要求明顯區(qū)分交付過程的商品，在中間產(chǎn)品的環(huán)節(jié)，其中的差別一般來說幾乎微乎其微，中間產(chǎn)品其實也是由客戶來支付為了從客戶那里賺取利潤，我們需要金額、日期以及讓我們可以冠冕堂皇地向客戶要求支付的條款，實際是什么則并不用去理會。在這種情況下，正常的基準(zhǔn)是如果存在通用的中間產(chǎn)品，那么它應(yīng)該由單個服務(wù)來實現(xiàn)，而這個服務(wù)能夠被多個高級別的服務(wù)調(diào)用。這種服務(wù)只有結(jié)果是重要的不是開始因為收集對交付服務(wù)有用的信息是服務(wù)本身的一部分，而不是請求服務(wù)源頭的一部分。需要注意的是：是否需要單個服務(wù)是由業(yè)務(wù)決定的，和信息技術(shù)沒有任何關(guān)系。如果不管是現(xiàn)在還是相關(guān)的未來，交付相同的中間產(chǎn)品都是切實有用的，那么就應(yīng)該有單個服務(wù)。除非在現(xiàn)在或相關(guān)的未來有商業(yè)力量發(fā)揮作用使中間產(chǎn)品發(fā)生結(jié)構(gòu)性分化，那我們最好不要為每組需求分別提供相應(yīng)服務(wù)。然而事實偏偏相反。在SOA，事物是由相同走向不同，而在數(shù)據(jù)庫化的方法中，事物則是由不同走向相同。帶有多種行為的通用服務(wù)你可能會問，如果需要兩種完全不同的行為而你只為其提供一種服務(wù)，這樣做的意義何在呢?難道我們還在被同樣困擾數(shù)據(jù)庫世界的“一刀切”做法限制?比如，如果我們出售兩種類型的產(chǎn)品，其中一種使用固定價格而另一種則根據(jù)某些復(fù)雜的公式計算出變動價格，為什么不用兩種結(jié)算服務(wù)，為每種特定的產(chǎn)品各訂制一種呢?這些問題很好，但問錯了地方。它們是好問題，那是因為任何不能充分應(yīng)對發(fā)生在問題域內(nèi)變化的設(shè)計方法注定會失敗。但是它們問在了錯誤的地方，這是因為根據(jù)問題域中的變化來調(diào)整方案的靈活性應(yīng)該構(gòu)建到服務(wù)中，而不是圍繞著服務(wù)來構(gòu)建。就拿結(jié)算服務(wù)來說，每次調(diào)用一種方法時，它應(yīng)該決定這兩種算法應(yīng)該使用哪一種。那樣的話，如果引入第三種結(jié)算算法，那么只有結(jié)算服務(wù)需要去做調(diào)整。請注意這并不意味著結(jié)算服務(wù)必須被設(shè)計成某種“萬能”機(jī)器;它同樣可以很好地為每個算法分別調(diào)用相應(yīng)的子服務(wù)。這種選擇介于多功能解決方案和包含不同組件的框架之間是一種可以根據(jù)服務(wù)來決定的選擇，因為它不需要被服務(wù)請求者知道。在SOA中，這種選擇更常見，但目前的做法則常常導(dǎo)致產(chǎn)生框架解決方案，因為需要多功能方案的感覺在很大程度上是由于不能從那些需要執(zhí)行的信息里識別出服務(wù)請求造成的。這種需要高素質(zhì)專家來實現(xiàn)的帶有如此多參數(shù)的以一應(yīng)十的多功能方案的日子不會長久了。堅持要點(diǎn)流程驅(qū)動方法也可以使我們分清我們是代表服務(wù)請求者做事還是為自己做事。以服務(wù)請求者身份做的事應(yīng)該作為服務(wù)的一部分來執(zhí)行，而其余的就不應(yīng)該了。通過這種區(qū)分，我們可以讓服務(wù)盡可能簡單，這樣可以在不需要改變各式各樣其他東西的情況下替換掉該服務(wù)。舉例來說，我們會生產(chǎn)產(chǎn)品來滿足外部服務(wù)請求，但是維護(hù)簿記系統(tǒng)是為了滿足我們自己的需求，而不是請求者的。如果要開發(fā)一項服務(wù)將客戶訂單轉(zhuǎn)變成制造活動及賬目簿記，那么只要我們實現(xiàn)一個新的簿記系統(tǒng)，我們就要去修改一次這個服務(wù)。這聽起來似乎還不是太糟糕，但試想一下所有事情都是為我們自己而做，那就太糟糕了。包含最新數(shù)據(jù)的數(shù)據(jù)倉庫的簿記、日志、儲存、員工績效數(shù)據(jù)的維護(hù)：所有這些及其他事情一般都由系統(tǒng)完成，這些系統(tǒng)隨組織機(jī)構(gòu)和時間的不同而不同，因此在業(yè)務(wù)服務(wù)中包含這些知識會降低互操作性，增加了用其他系統(tǒng)來實現(xiàn)服務(wù)替換的難度。我們可以通過產(chǎn)生通知的方式來避免此類問題，即：如果對這些功能很重要的事情發(fā)生了，就發(fā)出通知，然后它們可以使用通用服務(wù)檢索處理事件所需的信息。另一類不應(yīng)作為服務(wù)一部分執(zhí)行的業(yè)務(wù)活動包括那些一旦服務(wù)請求被撤銷就無法逆轉(zhuǎn)的活動。通常來說，這類活動包括諸如因客戶訂貨導(dǎo)致庫存量低于補(bǔ)貨水平從而需要訂購補(bǔ)給、注冊新用戶以及更新現(xiàn)有用戶信息。這些活動是整個流程中的各個步驟，應(yīng)使用單獨(dú)的服務(wù)一一執(zhí)行。當(dāng)然，這種思維方式可以與數(shù)據(jù)庫范式緊密結(jié)合。但并不是其所特有的，因為它與SOA有關(guān)。結(jié)果是，許多SOA的實現(xiàn)與數(shù)據(jù)庫化的思維方式背道而馳，而正是這種思維方式激發(fā)了他們以自下而上的方式識別服務(wù)，而非SOA的自上而下方式。在自下而上方式中，原本一開始為某個問題開發(fā)的服務(wù)也可以為其他問題復(fù)用，這多虧了設(shè)計它的人對于如何更廣泛地應(yīng)用做了認(rèn)真的思考。SOA中，在多個上下文中使用某個服務(wù)是縝密設(shè)計的結(jié)果，而不是靠直覺，并且從設(shè)計之初就將所有那些上下文都考慮了進(jìn)來。說到復(fù)用某一服務(wù)來交付某一通用的中間產(chǎn)品就好比說重復(fù)使用前門進(jìn)入房子，不管那扇門是通向客廳、廚房，還是衛(wèi)生間。你能想象廚房設(shè)計師說：“真妙!那家伙設(shè)計的室外通向客廳的入口正好可以被我用來作為通向廚房的室外入口!”嗎?任何談?wù)摗皬?fù)用”(如復(fù)用支付服務(wù))的人都還沒有實現(xiàn)它。請注意，這并不是錯誤的，只是有點(diǎn)奇怪和沒有什么啟發(fā)性罷了。服務(wù)遵從業(yè)務(wù)采用SOA方式思考問題的一個結(jié)果就是SOA會使得服務(wù)依據(jù)其業(yè)務(wù)意義而非機(jī)械的實現(xiàn)來表述。例如，名為增加用戶記錄的服務(wù)是數(shù)據(jù)庫化的，而名為注冊新用戶的服務(wù)就是SOA的，即便這兩個服務(wù)做的事情完全一樣。我們對服務(wù)的命名十分重要，因為它告訴我們是誰在請求該服務(wù)，以及為什么他要請求這項服務(wù)。在這個特定的例子中，SOA自上而下的方法會得到一個結(jié)論，那就是業(yè)務(wù)流程需要一個有效的用戶注冊服務(wù)，該服務(wù)通過修改現(xiàn)存的注冊服務(wù)(如果有的話)來完成，而不是重新自動創(chuàng)建一個新的。在SOA中，這是用戶注冊服務(wù)的責(zé)任，而數(shù)據(jù)庫化的方法卻會把這個責(zé)任推到服務(wù)請求者身上。類似地，SOA注冊用戶服務(wù)自身會決定用戶ID是什么，而數(shù)據(jù)庫化的服務(wù)可能就會干脆讓服務(wù)請求者做這個決定。匯聚到單個方案總的看來，SOA由上至下的思維方式使得很多設(shè)計決策只存在一個選項，而數(shù)據(jù)庫化的思考者會把該選項僅僅看作眾多可選方案之一。這是SOA很重要的一個優(yōu)勢，考慮到SOA是以互操作性為導(dǎo)向的，而互操作性要求我們行車時都在同一邊行駛而不用去和我們碰到的每輛車去交涉。那些忽視這點(diǎn)的人比如通過主張Web服務(wù)只是眾多實現(xiàn)跨系統(tǒng)邊界SOA的一種方式能夠一直成功的機(jī)會和那些只考慮下一步的棋手差不多。誠然，總是有比Web服務(wù)更簡單的方法去連接兩個系統(tǒng)，但是為了讓呼叫中心或輸出管理設(shè)施能使用相同數(shù)據(jù)你會怎么做?為了確保數(shù)據(jù)倉庫能夠在你把事件從一個系統(tǒng)轉(zhuǎn)換到另一個系統(tǒng)時得到通知，或者事件一發(fā)生便能及時通知你的客戶，你又會怎么做呢?在SOA的世界里，數(shù)據(jù)和事件必須在多個系統(tǒng)中可用，而Web服務(wù)是能夠確保在低投資和低維護(hù)成本的前提下達(dá)到這一效果的最有效的方法。存在這一明顯差異的一個領(lǐng)域就是電子數(shù)據(jù)交換(EDI)。傳統(tǒng)的電子數(shù)據(jù)交換(EDI)技術(shù)旨在確定組織之間通信可能需要的信息，并為該信息定義詞匯。那和定義某一特定的信息交互不是一回事。比如，你可以使用相同的EDI報文來下訂單、查詢其進(jìn)展以及修改它。兩個組織想通過這些規(guī)范進(jìn)行通信必須坐下來一起就這一詞匯的使用方式達(dá)成一致。SOA分離了這些關(guān)注點(diǎn)：詞匯由命名空間來處理，而這些命名空間可能會被多個服務(wù)使用，每個服務(wù)有各自特定的目的。“SOA由上至下方式導(dǎo)致更具體的結(jié)論”的另一領(lǐng)域是這樣一個問題：是什么筑起了一個編排過的流程邊界。通常，這個問題會引起無休止的爭論。比如，采用輸出管理服務(wù)給客戶發(fā)送確認(rèn)信息是否應(yīng)被編排為用戶流程的一部分，如果是的話，它應(yīng)該采用即發(fā)即棄(fire-and-forget)的方式處理還是應(yīng)該由輸出管理服務(wù)來報告動作成功完成?按SOA的話講，所有這些東西都是用戶意圖的一部分，因此都應(yīng)該被編排的。其他一些行為，比如考慮到新用戶訂單的更新數(shù)據(jù)倉庫或者更新總分類，很顯然都不是用戶意圖的一部分，不應(yīng)該包含在流程編排中，哪怕它們是同一方執(zhí)行的。4.不要自己做瑣事通用功能業(yè)務(wù)服務(wù)應(yīng)該只包含特定于該服務(wù)的那些功能邏輯。它應(yīng)該把其他功能都委托出去。那樣的話，服務(wù)自身就可以盡可能簡單。這使得設(shè)計、測試以及替換服務(wù)，如有必要的話，更容易。這是個基本的數(shù)學(xué)知識：新軟件模塊需要匹配的因素越多，那么同價位下的成品軟件(COTS)的共性越少，而且若恰好有個方案可用時它也會更貴。如果可以將這些非特定功能委托給標(biāo)準(zhǔn)服務(wù)，那么就可以降低需要匹配的因素個數(shù)。服務(wù)可以代勞的首要任務(wù)是瑣事：都是些“家務(wù)事”而非真正業(yè)務(wù)相關(guān)的功能。這些瑣事天生就是普遍的，換句話說完成這些瑣事的方式并不是為支持業(yè)務(wù)上下文的服務(wù)量身定制的。通用用戶接口當(dāng)你得知信息系統(tǒng)最不應(yīng)該做的一大瑣事就是管理用戶體驗時你可能會覺得驚訝。這是一個通用的功能，應(yīng)該盡可能的采用標(biāo)準(zhǔn)工具來處理。用戶體驗包括用戶可以選擇要執(zhí)行工作項的工作列表，工作項執(zhí)行的工具比如通過啟動一個用戶界面(如果有的話)來關(guān)閉已完成的工作項。它包含了用戶有可能執(zhí)行的交易甄選，輸入信息屏幕的表示一般是從XSD生成以及使用和交易相對應(yīng)的標(biāo)準(zhǔn)驗證服務(wù)進(jìn)行驗證。它包括了保持當(dāng)前用戶上下文環(huán)境，這樣他就無需再次輸入當(dāng)前的客戶、產(chǎn)品、項目、流程實例或者其他任何東西，而是可以使用這些默認(rèn)值或者在必要時候重寫它們。它包括了和當(dāng)前用戶上下文環(huán)境相關(guān)的所有文檔的介紹。它包含了用戶可能需要作出響應(yīng)的提示對話框。所有這些東西都可以使用無需包含任何業(yè)務(wù)知識的工具實現(xiàn)。總的來說，給用戶提供一個統(tǒng)一、包含所有東西的環(huán)境遠(yuǎn)比為某個特定行為而優(yōu)化的用戶界面要好。如果有業(yè)務(wù)案例違背了這一原則，請至少記住這點(diǎn)：在穩(wěn)定用戶界之前，不要去優(yōu)化它。典型通用功能其他的瑣事還包括，但并不僅限于以下幾個方面：安全：建立服務(wù)請求者身份和訪問權(quán)限。通知：確認(rèn)某一業(yè)務(wù)事件應(yīng)通知哪些人。這包括了維護(hù)基于此的事件訂閱。輸出管理：在線下進(jìn)行信息通信，而不是作為一種服務(wù)響應(yīng)。典型例子就是當(dāng)客戶請求必須被正式確認(rèn)時，比如使用電子郵件來確認(rèn)你剛剛通過瀏覽器所做的網(wǎng)上采購。對那些主動提供的消息也是需要的，比如每月的賬單。輸出管理必須決定通過哪條渠道去發(fā)送信息，以及使用哪個地址來發(fā)送。它應(yīng)該把消息轉(zhuǎn)換成接收方能夠接收的格式，發(fā)送消息，并把消息添加到歸檔文檔。輸出管理包括維護(hù)那些被用來將數(shù)據(jù)轉(zhuǎn)換成用戶可理解消息的模板，以及潛在接收者的地址和渠道偏好。數(shù)據(jù)轉(zhuǎn)換：把數(shù)據(jù)從一種格式轉(zhuǎn)換為另一個，把獨(dú)立的各個服務(wù)打包為一個服務(wù)用麥當(dāng)勞的說法，開心樂園餐以及分解拆包，將服務(wù)請求拆分成適用于不同人群的各個獨(dú)立請求，匯集各個回應(yīng)，排隊及出列，或協(xié)議轉(zhuǎn)換。流程編排：編排某一流程，以確保按適當(dāng)順序且僅相關(guān)時來執(zhí)行那些組成流程的服務(wù)，確?？煲馄跁r發(fā)送告警信息，以及確保因輔助信息或者逾期打斷從而引起的新流程分支被啟用。歸檔管理：維護(hù)及訪問相關(guān)的歸檔信息。這些可能是虛擬的檔案，從某種意義上是展現(xiàn)給用戶的信息，當(dāng)他需要某個檔案時可以使用查詢來檢索。對那些從數(shù)據(jù)庫中抽取的內(nèi)容，這被認(rèn)為是正常的，但是沒有特殊理由不對文檔使用相同的方法。在某些情況下應(yīng)使用設(shè)備來特別增加指派文檔至檔案中。記錄管理：維護(hù)那些不允許被更改的信息。至下而上敘述這些實現(xiàn)瑣事的服務(wù)不能形成業(yè)務(wù)服務(wù)層次的部分。不能使用自上而下的方式去設(shè)計它們，因為這些服務(wù)都沒有所謂的“上”。對這樣的服務(wù)，使用旨在實現(xiàn)最大程度重用的自下而上的方法會更適合。這使得從這個階段起就能夠?qū)崿F(xiàn)服務(wù)的優(yōu)勝劣汰。采用數(shù)據(jù)庫化的方法，很少能夠?qū)嶋H把次等通用功能用更好的替換，因為這要求修改所有使用該方法的應(yīng)用。使用SOA則不同，這種替換很簡單，前提是已經(jīng)應(yīng)用了“不去了解你不需要了解的事情”這條規(guī)則，包括其推論：服務(wù)請求不應(yīng)該包含超過指定該請求必要信息之外的其他信息，而且服務(wù)本身應(yīng)該在需要時主動要求更多信息。如授權(quán)服務(wù)，該服務(wù)由某應(yīng)用調(diào)用，旨在決定是否允許某特定用戶在某客戶數(shù)據(jù)上執(zhí)行某項功能比如說：“我們的雇員Donald Jones是否被授權(quán)可以訪問Acme Widgets company公司相關(guān)的財務(wù)數(shù)據(jù)?”。服務(wù)的簡單版本可能具備處理某些特定情況的能力，在此特定情形下可以通過使用雇員功能對應(yīng)表來回答這些問題。稍微復(fù)雜一點(diǎn)的版本可能會識別出Donald Jones屬于某個或多個組的成員，除了個人權(quán)限外還擁有該組的權(quán)限。再更近一步，授權(quán)服務(wù)可能會使用用戶證書去區(qū)別雇員和客戶，并允許客戶只能夠訪問他們自己的數(shù)據(jù)。一個完善的版本可能會使用標(biāo)準(zhǔn)化的服務(wù)去調(diào)用業(yè)務(wù)流程管理系統(tǒng)或者項目管理系統(tǒng)，詢問Donald Jones是否已經(jīng)被賦予了任何我們和Acme Widgets交易相關(guān)的職責(zé)。更好的做法是，授權(quán)服務(wù)會記錄請求和應(yīng)答的日志，而簡單的版本不會這樣做。組織可以從一個服務(wù)的版本切換到另一個而無需對調(diào)用服務(wù)的應(yīng)用做任何改變。也有可能設(shè)計出根據(jù)操作必需的條件自動配置自己的通用服務(wù)。例如，授權(quán)服務(wù)可以檢查是否有服務(wù)可以告知它員工對某些特定客戶有職責(zé)，并在該服務(wù)不可用的情況下決定只使用個人還是群組的訪問權(quán)限。用這種方式，服務(wù)可以在很多組織之間復(fù)用。5.不要在測試上自尋煩惱為什么SOA更容易測試對SOA缺點(diǎn)的一種看法是測試?yán)щy。這種看法完全不恰當(dāng)，原因有很多。首先，在SOA中使用元數(shù)據(jù)可以避免錯誤被植入到系統(tǒng)中?？梢栽谠獢?shù)據(jù)層次就對系統(tǒng)進(jìn)行驗證，例如，保證所有需要處理的數(shù)據(jù)在使用前就被匯總并校驗。在整個業(yè)務(wù)流程范圍內(nèi)都可以實現(xiàn)這點(diǎn)。當(dāng)你可以驗證設(shè)計的時候就不要測試整個系統(tǒng)。其次，幾乎所有測試，包括所有系統(tǒng)集成測試，一旦測試基準(zhǔn)被建立后都可以自動完成。但是，需要一些前提條件。表現(xiàn)層和業(yè)務(wù)執(zhí)行層必須被嚴(yán)格的區(qū)分。好在這是使用SOA的一種很自然的方式。對所有輸入，都應(yīng)該存在相應(yīng)的XSD。使用該XSD，可以生成測試記錄。同理，也可以生成帶有預(yù)期輸出結(jié)果的測試記錄。在測試過程中，不能產(chǎn)生可以證明系統(tǒng)運(yùn)行正常的任何輸出地方，必須在測試腳本中添加專門為此生成的附加輸出的查詢語句。當(dāng)測試開始運(yùn)行時，測試記錄被一條條輸入系統(tǒng)，然后輸出的結(jié)果自動和期望的結(jié)果進(jìn)行對比。這會產(chǎn)生一個異常列表，其中每項都應(yīng)仔細(xì)考慮。測試可以按需進(jìn)行。自然，測試的結(jié)果可能取決于存積在數(shù)據(jù)庫中的數(shù)據(jù)，所以這點(diǎn)需要進(jìn)行彌補(bǔ)。而且，系統(tǒng)不可表現(xiàn)出時間相關(guān)的行為。系統(tǒng)必須有能力響應(yīng)每隔一段時間(它對自動化測試序列更適合)就產(chǎn)生的事件，而不是花上一周時間去等待某個基于時間的觸發(fā)器被觸發(fā)。用戶界面的測試應(yīng)該單獨(dú)進(jìn)行，而且永遠(yuǎn)不在集成測試中使用。第三，SOA的設(shè)計趨向于產(chǎn)生更加健壯的系統(tǒng)：系統(tǒng)出錯的機(jī)會更少。SOA減少了信息系統(tǒng)為了協(xié)同工作而需要達(dá)成協(xié)議的因素數(shù)量，這樣一來，導(dǎo)致在某關(guān)鍵因素上產(chǎn)生分歧的設(shè)計錯誤的概率也減少了。就算真的出錯，也能夠在造成損害之前檢測到。使用SOA，消息在被處理前會被驗證，這樣可以判斷消息是否格式正確、是否符合相應(yīng)的XSD?？尚行詼y試最后，作為數(shù)據(jù)庫時代特有的產(chǎn)物測試環(huán)境和生產(chǎn)環(huán)境必須嚴(yán)格區(qū)分，從此不再需要了，而且有時候這也是不適合的。這是很有可能的，這是因為我們不再實際進(jìn)行系統(tǒng)測試了，而是對測試通路和信息處理的方式進(jìn)行測試。SOA提供了三重安全的、有效區(qū)分測試消息和生產(chǎn)消息的方法。除了被封裝好的消息，其他每個消息自身和相應(yīng)的命名空間都包含版本號。而且每個消息都包含一個標(biāo)簽用以指示它是用于測試還是生產(chǎn)。所需的只是一個SOA網(wǎng)關(guān)，它存在于防火墻內(nèi)部，對每條進(jìn)入消息進(jìn)行如下處理：校驗消息以確定其是否與一個已知XSD的版本相符(被封裝好的消息除外)。使用我們對相應(yīng)XSD的副本對消息進(jìn)行校驗，以確定其是否有效。如果消息用于生產(chǎn)的，就驗證消息版本號是否被允許用于生產(chǎn)。只有這樣，消息才能夠被傳遞到生產(chǎn)系統(tǒng)。其他所謂的“生產(chǎn)”消息都會被拒絕。如果消息用于測試，消息可能會被傳遞到指定的測試版系統(tǒng)。在特殊情況下，消息如果只是用來做數(shù)據(jù)檢索，那也有可能被傳遞到生產(chǎn)系統(tǒng)。只有在消息被完全測試過后，生產(chǎn)版本的注冊庫和XSD才能得以更新。這樣的處理方法不僅僅只是三重安全的，而且使得消息的路由能以一種合乎實際的方式得到測試。這也大大降低了從測試系統(tǒng)切換到生產(chǎn)系統(tǒng)時重新進(jìn)行配置的需求。因為這種重新配置天生就是不可測試的，常常成為錯誤的根源。發(fā)布經(jīng)理只能通過在半夜或者周末發(fā)布新的版本軟件來彌補(bǔ)這類錯誤;這樣，就算新版本出現(xiàn)了任何錯誤，也可以在有人發(fā)現(xiàn)錯誤之前恢復(fù)到老版本。但如果這樣的變化影響到了其他組織那就沒有辦法這樣操作了。SOA發(fā)布管理要簡單得多!我們對于SOA測試的一般認(rèn)識是時候該改變了。SOA是能夠把測試需求和設(shè)置測試的工作減少到最低的一種方案。它能使重要測試更自動化的完成，結(jié)果也更好。完善之理論SOA使得信息系統(tǒng)的開發(fā)和部署能夠比使用數(shù)據(jù)庫化的方法支持更為豐富的用戶體驗。這樣的系統(tǒng)能夠涵蓋更多的信息格式、更廣的行為集合，其行為上也可以達(dá)到更高層次的統(tǒng)一和一致以及更加可靠，不管是從客戶還是從組織內(nèi)關(guān)注合規(guī)的人員的觀點(diǎn)來衡量。然而，要想獲得這些好處需要我們跟已有的數(shù)據(jù)庫方法實踐說再見。6.始終信守你的諾言為什么數(shù)據(jù)庫不能一直信守諾言接收一個服務(wù)請求的動作是通過定義一個承諾，即向請求者承諾服務(wù)請求會被執(zhí)行，來確定的。這種執(zhí)行定義了一個流程，其至少包含一個步驟，但通常是多個步驟。數(shù)據(jù)庫化的思考和流程不能融洽相處。從它們各自的本質(zhì)來看，數(shù)據(jù)庫就像是一個個孤島。而孤島會促使偏狹地思考問題：任何孤島之外的東西都不重要?？梢酝ㄟ^數(shù)據(jù)庫中的事務(wù)概念來形象地解釋這個問題：某個工作單元把數(shù)據(jù)庫從一種一致性狀態(tài)轉(zhuǎn)移到另一個。在一些特殊的情況下，該概念可能會被擴(kuò)展到多個數(shù)據(jù)庫，雖然可以通過兩階段提交技術(shù)來做，但這也有局限性。邏輯一致性可能需要貫穿整個業(yè)務(wù)流程得以維護(hù)，而不只是恰好在某個時刻;需要在信息改變波及的所有地方去維護(hù)，其中不僅包括數(shù)據(jù)庫還有流程管理系統(tǒng)、信息以及發(fā)送和接受信息的人工代理，而這一切從數(shù)據(jù)庫世界的觀點(diǎn)看來是完全陌生的。SOA交易概念對數(shù)據(jù)庫世界陌生的東西對與SOA來說卻是再自然不過了。業(yè)務(wù)交易實現(xiàn)它的一般是一個流程就是服務(wù)。為了理解SOA何以能很好支持邏輯一致性需求，理解業(yè)務(wù)交易的需要很重要。業(yè)務(wù)交易由下面元素組成：廠商給客戶提供信息，客戶據(jù)此可作出采購決定。一般來說，這種信息包括出售商品和服務(wù)的屬性、得到該商品的條件包括，當(dāng)然，價格以及可用性。從法律的角度，廠商所描述的這一信息是真實的。用戶基于廠商描述的信息下采購訂單。廠商核實該采購決定依據(jù)的信息是否仍然適用，如果是，則確認(rèn)該訂單。如果有變化可能由于產(chǎn)品或服務(wù)已終止，或產(chǎn)品已經(jīng)漲價，也可能是貨物或服務(wù)的規(guī)格已經(jīng)變更那么需要一些處理來決定到底應(yīng)該如何做：是不管三七二十一繼續(xù)提交訂單，還是通過協(xié)商修改訂單，或者干脆取消訂單。廠商和客戶雙方履行采購協(xié)議中各項條約。SOA怎樣維持一致性SOA通過多種方法維護(hù)業(yè)務(wù)交易的邏輯一致性。第一，所有暗含對前一個狀況改變的通信都要使用能夠保證消息安全交付的協(xié)議來完成。只要廠商或用戶做出某個承諾，為實現(xiàn)該承諾所要做的動作就應(yīng)該包含這樣的改變。這樣的話，客戶和廠商就不可能對當(dāng)前業(yè)務(wù)狀態(tài)持有不同的看法了。第二，數(shù)據(jù)庫的邏輯一致性和流程管理系統(tǒng)中處理過程的記錄可以通過兩階段提交協(xié)議來維護(hù)。跨多個數(shù)據(jù)庫的邏輯一致性通過一連串這樣的兩階段提交維護(hù)。首先讓數(shù)據(jù)庫A和流程管理系統(tǒng)同步，然后流程管理系統(tǒng)再和數(shù)據(jù)庫B同步，以此類推。第三，從廠商給客戶展示產(chǎn)品到訂單下達(dá)期間，廠商面對的任何改變都可以使用樂觀鎖并發(fā)控制機(jī)制來處理。這種處理方式對SOA來說很自然：判斷是否存在相應(yīng)改動的過程可以完全自動化。因為SOA使得數(shù)據(jù)在被用來作決定的同時也可以進(jìn)行訪問，找不到樂觀鎖而需要人工介入的情況幾乎鮮有發(fā)生。最后，一筆交易的中止比如說用戶撤銷了訂單，原因可能是用戶沒有能力支付，或者用戶去世了使用SOA可以相對容易地處理。因為在交易上下文中使用或產(chǎn)生的記錄可以被清晰地識別，所以可以確定需要哪些補(bǔ)償信息用以糾正用戶和廠商的不同認(rèn)知。因為哪個數(shù)據(jù)庫更新和該交易有直接關(guān)系是很清楚的，在數(shù)據(jù)庫中的哪些變更需要使用補(bǔ)償交易服務(wù)做回滾也很清楚。假設(shè)，交易中止的發(fā)生相對不那么頻繁，使這些活動完全自動化通常是高投入低產(chǎn)出的，但是你的設(shè)計必須要考慮到這些。請注意業(yè)務(wù)交易的范圍限制在那些為了處理某個服務(wù)請求而直接完成的操作。在SOA中，編排你自己的流程并提供事件通知給他人，是一條守則。如果服務(wù)中止了，那么有必要發(fā)通知用戶這一個變化。至于他們要怎么處理，則完全是他們自己的事。也請注意，創(chuàng)建用戶服務(wù)請求的內(nèi)容，嚴(yán)格說起來，應(yīng)該在流程處理之前進(jìn)行，而不應(yīng)該作為流程處理的一部分。這真的不是你該做的事：原則上，提供消息的XSD和消息驗證服務(wù)給用戶就夠了，讓他決定是從鍵盤錄入數(shù)據(jù)還是從他自己的信息系統(tǒng)以某種方式直接生成數(shù)據(jù)。對消費(fèi)者來說，這并不是尚未成為一個可行的方法，但采集數(shù)據(jù)和處理數(shù)據(jù)是兩件獨(dú)立的事情，并使用不同工具在各自的環(huán)境中執(zhí)行這些事情，對于這一點(diǎn)仍然是有效的。同樣是數(shù)據(jù)采集，有很多實現(xiàn)方式，這取決于用戶的期望以及他們和你溝通的渠道，但不管怎樣都應(yīng)該只有一個服務(wù)去處理這事兒。7.不要將自己禁錮于模型數(shù)據(jù)庫只是模型，SOA代表更多領(lǐng)域模型是領(lǐng)域本身的體現(xiàn)，操作領(lǐng)域模型要比直接操作領(lǐng)域更簡單。絕大多數(shù)的數(shù)據(jù)庫都是模型。它們以這樣一種方式代表一些管理的、物理的或者社會的領(lǐng)域：相關(guān)領(lǐng)域的問題都可以通過查詢數(shù)據(jù)庫來得到答案，而存在于領(lǐng)域中所需的行為可以從數(shù)據(jù)庫內(nèi)部得到指示。比如說，通過訪問數(shù)據(jù)庫查詢用戶的地址信息要比跟隨用戶到他家然后抄下他所進(jìn)房子的門牌號要方便的多。而且，在數(shù)據(jù)庫中對記錄進(jìn)行計數(shù)也要比清點(diǎn)一個城市有多少人或倉庫里有多少產(chǎn)品要容易。原則上，提供對這些功能的支持足以確定數(shù)據(jù)庫的數(shù)據(jù)結(jié)構(gòu)。盡管這樣，因為一般不太可能事先就能明確所有這些功能，所以我們使用數(shù)據(jù)建模技術(shù)對領(lǐng)域中感興趣的對象進(jìn)行分析，包括對象之間的關(guān)系，以及信息項(它們會告訴我們關(guān)于其自身的一些我們可能想知道的東西)。例如，若數(shù)據(jù)庫和用戶有關(guān)，那么每個用戶通常都應(yīng)該存在對應(yīng)的數(shù)據(jù)庫記錄，包括一些數(shù)據(jù)庫使用者感興趣的與用戶相關(guān)的信息。因為數(shù)據(jù)模型更多是基于功能上的考慮而不是某些特定數(shù)據(jù)庫的使用，所以將數(shù)據(jù)結(jié)構(gòu)建立在這種模型之上會使數(shù)據(jù)庫能夠更易適應(yīng)各種未預(yù)見的需求。數(shù)據(jù)庫在語義上被結(jié)構(gòu)化了;換句話來講，數(shù)據(jù)庫是根據(jù)其表達(dá)出的意思來構(gòu)造的。對沒有實現(xiàn)數(shù)據(jù)模型的數(shù)據(jù)結(jié)構(gòu)，數(shù)據(jù)庫技術(shù)就沒那么方便了。它實在不能在描述、文本、圖像等方面做很多貢獻(xiàn)。相反，SOA卻能夠很好地處理文檔、記錄，就像可以很好處理那些根據(jù)數(shù)據(jù)模型構(gòu)建的數(shù)據(jù)一樣。SOA允許單個設(shè)計能夠處理語義結(jié)構(gòu)化信息和文檔。盡管如此，由于數(shù)據(jù)庫系統(tǒng)支配了我們的思維模式，所以當(dāng)應(yīng)用SOA時免不了很自然的會堅持其局限性。但是在SOA的世界里不存在特殊的理由要去應(yīng)用這種限制，任何理由都不能夠這樣做。超越模型的益處將語義上結(jié)構(gòu)化的數(shù)據(jù)和一些像超鏈接、文本、圖片以及音頻片段的東西結(jié)合起來的一個主要原因是創(chuàng)建更為豐富的用戶體驗。對消費(fèi)者來說，這是必須的，而不是可選的。對你雇傭的知識型工作人員而言，這會使他們做事更有效率。只有對從事日常管理的員工來說，它才會成為一種障礙。然而你應(yīng)用SOA越多，你對這些人員的需要就越少。他們從表單鍵入數(shù)據(jù)的工作可以外包給任何人做：你需要做的僅僅是掃描每個表單然后把圖像發(fā)送給代理，代理本