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