面向服務的架構（SOA）是一種組織信息處理的方法。各系統(tǒng)為協(xié)同工作在各方面達成了協(xié)議，SOA通過減少這些協(xié)議的數(shù)量，能夠降低信息系統(tǒng)互操作性的成本。如果SOA能得到大范圍的應用，系統(tǒng)將呈現(xiàn)與現(xiàn)在截然不同的前景，這就好比當今貨運行業(yè)有別于集裝箱出現(xiàn)前的貨運業(yè)時代一般。然而，目前的應用方式卻導致了額外的開支卻并未體現(xiàn)出這些互操作性的優(yōu)勢。將適用于數(shù)據(jù)庫時代的范式應用于SOA中，會招致反效果，往往是愚蠢的，有時甚至是十分危險的設計。這些模式必須由新的思想和行為方式所替代，以確保SOA朝著接口更簡單、IT方案更優(yōu)化以及項目更可控的方向發(fā)展。這一點可以通過遵守以下十大戒條來實現(xiàn)。
引言
SOA的潛在影響
面向服務的架構（SOA）是一種組織信息處理的方法。這種方法以服務的形式描述所有交互活動，服務請求者請求代理完成某些處理，代理確保處理得以完成并將處理結果反饋給服務請求者。這種思維方式可以應用于業(yè)務級別，以描述各組織機構之間的交互；應用于功能級別，以描述組成業(yè)務流程的活動的交互方式；應用到信息系統(tǒng)級別，以描述系統(tǒng)及系統(tǒng)各部分的交互方式。每個級別的準則都是相同的：代理完成所需工作的方式與請求者無關，乃至與是否完全自動、完全人工亦或兩者兼具都無關系。哪怕代理將部分或者甚至全部工作外包給其他代理完成也與請求者無關。所有請求者所需關注的是與代理就以下方面達成一致：請求及響應應該如何制定，以及服務的效果如何。
SOA被大肆宣揚為一種具有巨大潛力的范式，能夠降低系統(tǒng)發(fā)展、測試及維護的成本。特別需要指出的是，SOA承諾可以通過大幅度減少達成協(xié)議的因素的數(shù)量，從而降低信息系統(tǒng)各模塊協(xié)同工作的成本。采用SOA，諸如像計算平臺和數(shù)據(jù)格式之間的差別造成的系統(tǒng)間通信屏障會較采用早期的范式要少得多。這使得更大范圍上的協(xié)作變得可能，因為它減少了障礙，使系統(tǒng)設計師們不必被強行要求相互達成一致，就此而言，也使得系統(tǒng)配置員之間不必被強行要求達成一致。如果這種承諾可以實現(xiàn)，其結果將會是革命性的。就像汽車改變了城市區(qū)域形態(tài)，集裝箱運輸革新了貨運行業(yè)，以及交易費用的降低發(fā)展了現(xiàn)代自由市場經(jīng)濟，SOA將開啟新的合作模式。當SOA主導我們應用IT的方式，系統(tǒng)前景將與今日迥然不同，好比圍繞汽車來設計規(guī)劃的城市和圍繞火車來設計規(guī)劃的城市截然不同一般。對我們之中那些思維受限于目前技術的人來說，SOA可以產(chǎn)生多大的不同是難以想象的。然而SOA所提供的靈活性優(yōu)勢就好比汽車勝過火車一樣：即便火車可以被制造跑得和汽車一樣快，火車還是絕不可能像汽車那樣提供門到門的運輸服務。把火車站安置在每個車道的盡頭，亦或甚至把鐵軌鋪設在每條道路上都是根本不現(xiàn)實的。
為何此影響尚未實現(xiàn)
為獲取新范式帶來的好處，我們必須好好利用其所能提供的各種新的可能性。遺憾的是，目前圍繞SOA的言過其實的宣傳對這些可能性的提及是言之甚少。大部分討論似乎都關注于如何利用SOA幫助單獨信息系統(tǒng)更快速地開發(fā)。然而，這并非SOA所能創(chuàng)造的最大價值之處。事實上，SOA是否真正能夠改進以往的方法，即各個功能點通過某一共同的數(shù)據(jù)池（通常是以數(shù)據(jù)庫的方式實現(xiàn)）來實現(xiàn)交互，還存在爭議。使用SOA來構建單獨、孤立的信息系統(tǒng)就像使用集裝箱在加工廠附近搬運貨物一樣：當然，它限定了內(nèi)部物流的順序和組織，但是集裝箱更多的是擋了道路而非提供幫助。SOA使信息系統(tǒng)間達到更好的互操作性，就像集裝箱促使了運輸商之間的互操作性一樣。那是一種重要優(yōu)勢，因為從需求確定到信息系統(tǒng)可操作之間的時間周期通常很大程度上是由互操作性決定的。要使某一信息系統(tǒng)能夠與其操作環(huán)境中的其他系統(tǒng)一起工作，那將會花費比重新構建這樣一個系統(tǒng)更多的時間和精力。
關注于SOA在信息系統(tǒng)內(nèi)部而非各系統(tǒng)之間的使用是情況更加惡化的征兆：因為看起來SOA是一種全新的處理我們一直以來所做的事情的方式，我們無法直接獲取它所帶來的收益。SOA概念和技術正為目前的系統(tǒng)開發(fā)范式所利用。這些范式還是數(shù)據(jù)庫時代的開發(fā)產(chǎn)物，同時也帶有數(shù)據(jù)庫技術的一些限制。在這些限制下應用SOA將會導致額外的開支，而不能獲得額外的收益。然而，這些“數(shù)據(jù)庫化”的范式是如此普遍和有害以至于我們常常忽略了它們對我們的思維影響有多大。它們是如此根深蒂固，以至于我們會不自覺將其視作常理。遺憾的是，這樣通常招致相反效果，常常是愚蠢的，有時甚至是相當危險的。它們導致了一種不好的方案，這種方案集合了數(shù)據(jù)庫時代的缺點以及SOA不好的一面，而又不能體現(xiàn)SOA必定提供的優(yōu)點。
需要改變什么
SOA范式有其自身的常識守則，較之數(shù)據(jù)庫范式的守則截然不同�；窘渎捎惺�。前五項關于如何簡化事物，使其比數(shù)據(jù)庫化的范式要求更加簡化——從堅持要點意義上更加簡化。如果我們以此種方式簡化事物，同一問題的不同解決方案相互間協(xié)作的可能性將大大提升。接下來的四項關于使IT解決方案優(yōu)于同等數(shù)據(jù)庫解決方案，這是通過阻止那些戴著有色眼鏡、慣于數(shù)據(jù)庫思維方式的人開發(fā)出無效解決方案來實現(xiàn)的。最后一項關于如何使IT更可控，尤其是組織系統(tǒng)開發(fā)以降低項目復雜度和風險。SOA使這些成為了可能——同樣也是必須的——因為它讓更多的功能交付成為基礎架構。
簡化之理論
在高空雜技表演中，高效的合作的基礎是每個空中飛人演員完全默契地配合，對方會及時地在每個時點出現(xiàn)。一些空中飛人演員非常自信，他們經(jīng)常蒙著眼進行表演。他們能夠接到彼此正因為他們確定在某個特定時刻對方只可能出現(xiàn)在一個可能位置。
成功應用SOA以達到最大化的協(xié)作性與高空雜技表演非常相似�；ゲ僮餍砸箨P于如何進行交流的解決方案從數(shù)以百萬計減少到只有一個，交互雙方都可以依賴該方案。這并不意味著其他方案有問題：這好比我們既可以靠左行駛也可以靠右行駛，但重要的是我們必須都靠同一邊行駛。
當只有一方執(zhí)行服務，一方接受服務時，只要雙方協(xié)議好，具體使用哪種方案其實并沒有太大區(qū)別。雙方中任一方的特異性可以決定最終方案，無需做更多的溝通努力。畢竟，無論使用哪種方案，這些特異性總要被處理。但是如果是多方請求服務或者多方執(zhí)行服務，那將呈現(xiàn)不一樣的情景。此時使通信方案精簡非常重要，如此，各方必須處理各自的特異性，無需面對另一方。
將信息通信與外科移植手術對比很能說明問題。成功的移植手術，要將一個人身上的器官移植到另一個人身上，要求該移植器官必須在多方面與接收者匹配，而其中大部分匹配因素與該器官的生物功能無關。換句話說，被移植的器官必須和接受者本身有相同的特征。因此，我們的器官不能像拼搭樂高積木一樣隨便被移植。目前的信息通信恰恰如此。當一個信息系統(tǒng)為另一個系統(tǒng)提供服務時，它們必須在很多方面達成一致。它們必須使用相同的詞匯（元數(shù)據(jù)）、相同的由一方調(diào)用而另一方執(zhí)行的功能集、對于每個功能請求應答數(shù)據(jù)內(nèi)容的相同期望、相同的編碼系統(tǒng)、相同的技術通訊協(xié)議、相同的用于信息傳遞的尋址模式、兼容的可預期的響應速率、兼容的確保消息不被丟失的技術、兼容的認證機制以確保雙方安全通信而不是與冒名者通信、兼容的加密技術以及密鑰管理以確保消息不被竊聽或者篡改等等。為了促進互操作性，必須確保參與各方從彼此獨立制定各自標準變?yōu)樾纬杉嫒莸臉藴室?guī)范。只有當一些非常嚴謹?shù)囊?guī)則得到遵守時這才有實現(xiàn)的可能，接口才能減至精要。如此一來特異性將無容身之地。
嚴謹?shù)囊?guī)則都關注于如何使得服務接口更為簡單。我們規(guī)定的越少，爭議的余地就越小。
1.不了解你不需要了解的
你不需要去了解的東西不會傷害到你
SOA范式的本質(zhì)在于使得合作各方或系統(tǒng)之間達成最少限度的協(xié)議卻可以實現(xiàn)最大程度的合作。這是一種巨大的優(yōu)勢，因為任何你不需要了解的東西既不需要被測試也不需要被維護。你不需要去了解的東西不會傷害到你。假設40%的系統(tǒng)開發(fā)成本用于測試上，而高達80%的信息系統(tǒng)生命周期的成本被花費到了系統(tǒng)維護階段，任何SOA范式讓你無需了解的東西都代表了你能節(jié)省的金錢。
元數(shù)據(jù)
你最不需要了解的就是結構、含義以及容許值——這些元數(shù)據(jù)——不會被系統(tǒng)中篩選、排序或執(zhí)行計算的邏輯使用的數(shù)據(jù)。你并不需要去了解這些，因為SOA技術使得數(shù)據(jù)和元數(shù)據(jù)同時出現(xiàn)。你的系統(tǒng)可以實時解讀元數(shù)據(jù)，所以如果你要做的僅僅是獲取、呈現(xiàn)或傳送相應的數(shù)據(jù)，你完全不需要為系統(tǒng)構建元數(shù)據(jù)知識。在有相當精密的表示（presentation）功能的幫助下，它甚至可以為用戶實現(xiàn)各種各樣特定的篩選及計算，且只使用與已有數(shù)據(jù)同時提供的元數(shù)據(jù)，而不是內(nèi)部構建元數(shù)據(jù)。
通過解讀數(shù)據(jù)相應的元數(shù)據(jù)，而不是把元數(shù)據(jù)構建到系統(tǒng)中，你的系統(tǒng)不需要隨元數(shù)據(jù)的改變而改變。需要改變的僅僅是源系統(tǒng)。想想如果遵守該守則，你能在開發(fā)、測試和維護上節(jié)省多少金錢！記住，在兩個系統(tǒng)上做更改，平均來說，其復雜度是在單個系統(tǒng)做更改的四倍，因為其中包含了所有各方的協(xié)作。
對于很多面對客戶的系統(tǒng)來說，表示以及特定篩選功能基本是其主要的功能。這些系統(tǒng)只針對最基本的客戶數(shù)據(jù)要求內(nèi)部構建元數(shù)據(jù)。這并不包括當前或過去的訂單、客戶通訊錄、照片、信函以及任何可用于展示的其他數(shù)據(jù)，所有這些數(shù)據(jù)都可以用一種不需要這些數(shù)據(jù)本質(zhì)相關知識的方式進行表示，內(nèi)建于系統(tǒng)中。
技術
許多你不需要了解的事情是與技術相關的。有了SOA，你不需要了解你正在接口的系統(tǒng)是否采用“軟件即服務”（Software-as-aservice），不需要了解實施該系統(tǒng)的計算機安放在何處，是哪種類型的計算機或者運行于何種操作系統(tǒng)，防火墻是如何配置，使用的是哪種數(shù)據(jù)庫管理系統(tǒng)，亦或可以使用哪種交易管理系統(tǒng)。其他你不需要了解的事情是與你所通信的系統(tǒng)內(nèi)部相關的。尤其是，你不需要去了解任何用于內(nèi)部數(shù)據(jù)存儲的元數(shù)據(jù)，因為任何其他系統(tǒng)需要同XSD一致的轉(zhuǎn)換都是其自身的問題，而不是你的。
即便如此，使用SOA進行通信的各方必須達成一致的技術相關的標準還有很多選擇。特別是有很多與Web服務相關的那些標準，SOA從業(yè)者將其統(tǒng)稱為WS-*標準（*指可以使用很多可能的標簽替換）。在一定程度上，這些標準提出得很恰當，因為SOA社區(qū)并沒有滿足于不去了解它不需要了解的東西；本文這個白皮書給出了一些指導以期降低由這些標準引起的問題的影響。遵守這些指導，SOA需要的先期協(xié)議將比其他方法要少得多。
設計穩(wěn)定的接口
如果想獲取SOA提供的種種好處，不去了解你不需要了解的東西會成為你的習慣。請銘記這點！比如說，當設計一個訂貨服務時，請記住服務請求者只需要知道，當他需要貨物的時候該貨物是否會有貨，而不需要去了解當前的庫存量。如果你的程序調(diào)用某一安全服務以判斷請求活動是否被授權，不要在系統(tǒng)內(nèi)構建任何超過其所需服務工作的知識。例如，如果安全服務需要使用輸入到程序的安全證書，唯一必須做的就是傳遞該證書！對你來說，它們只是被封裝在輸入消息中的單個數(shù)據(jù)項。該證書是否是格式完整的XML也不要去驗證。如果，由于某些只有那些負責安全的小鬼知道的原因，他們選擇了違背標準的SOA操作或?qū)ψC書進行了加密，那么這是他們的問題，不是你的。如果他們改變了任何與證書相關的東西，你的程序不應該為此做任何改變或調(diào)整。任何你不需要了解的東西不會傷害到你。當然了，除非你硬要去了解它，在這種情況下如果你們不想在SOA上浪費時間的話，其他人可能最好離遠點兒。
不去了解那些你不需要了解的東西可能比你想象的要難。如果你開發(fā)專門用于與你通信的信息系統(tǒng)的信息檢索服務，你的思路已經(jīng)不對了，因為你已經(jīng)把其他系統(tǒng)的知識歸并到系統(tǒng)中了。需求中的任何更改將會迫使雙方系統(tǒng)都作出更改。通常來講，比較好的方式是采用數(shù)量有限的檢索服務暴露系統(tǒng)數(shù)據(jù)，當檢索服務結合在一起使用時，它們涵蓋了所有相關服務的信息檢索需求。例如，某個產(chǎn)品數(shù)據(jù)庫可能通過好幾個服務分別暴露出去：一個簡單的僅包含編碼、描述、部門以及產(chǎn)品定價的服務、一個暴露出所有該產(chǎn)品財務方面信息的服務，以及一個暴露出所有該產(chǎn)品物流方面信息的服務。許多系統(tǒng)僅需簡單服務即可得到滿足，大部分只需要部分數(shù)據(jù)而非全部，或財務或物流的服務，而有一些兩者都需要，但此外沒有任何一個需要特別接口的系統(tǒng)。這種工作方式被稱為麥當勞方式：客戶從標準產(chǎn)品中搭配出自己需要的產(chǎn)品。支持這種方式并不困難，因為不管怎樣你都需要這些服務去支持面向客戶的程序。你甚至可以用這種方式來支持非常特別的信息需求，因為那些不需要的數(shù)據(jù)可以在消費前就過濾掉。如果不想在巨無霸漢堡中放小黃瓜，扔掉它就可以了！這種方式的基本思路是提供過多的信息要比提供過少的信息遇到的問題少，因為接收方系統(tǒng)可以很容易通過程序過濾掉不需要的信息，但是如果缺少信息那就麻煩了。
不去了解你不需要了解的東西也會使得為支持業(yè)務流程所需的信息交互大大簡化。在SOA的范式中，當你請求另一個代理為你做一些事，那就是你所需要做的全部。你不需要為代理提供可能有助于完成任務的或者是其必需的額外信息。在點菜時，確保有用于這道菜的原料是廚師的職責。你說出想要的東西，然后就可以靜候佳音了。反過來，代理會使用信息檢索服務來向你咨詢所有信息，但是檢索什么、何時檢索以及從何檢索，這些問題都應該由他來決定，你無須去了解，更不用將該知識歸并至你的系統(tǒng)中。這樣，在他那一端的更改幾乎不需要你這邊作出更改。比如說，如果他決定停止維護對你數(shù)據(jù)的拷貝，你什么更改都不需要做。
當然，不去了解你不需要了解的事情確實會導致效率低下。原本只需要一次交換即可實現(xiàn)的操作現(xiàn)在將需要多個步驟。麥當勞方式常常會導致原本一個服務即可滿足卻提供了多個服務的情況，另一邊卻還在檢索信息，而這些信息又常常是冗余而非十分必要�？倳霈F(xiàn)一些情形，可以通過好的商業(yè)意識來優(yōu)化這些通信模式。也會有很多場合你會想要優(yōu)化用戶接口，那也只是因為當前的表示設備并不擅長提供給用戶吸引人的界面。但是在你優(yōu)化之前，請考慮你會失去什么樣的靈活性。另外絕不要想去優(yōu)化那些尚未穩(wěn)定的功能需求。
2.不要了解你還不能了解的事情
為時過早的規(guī)范凍結
數(shù)據(jù)庫范式中，一個真正的難題在于：它要求在你還未足夠了解并有能力去確定數(shù)據(jù)的具體結構前，就去做這件事。因為它們忽視了一個生活中簡單的事實：只有當用戶看到他們不想看到的東西時，他們才知道其真正想要的是什么。
其工作原理是這樣：一旦完成了數(shù)據(jù)結構的設計，任何后續(xù)修改都會引起雜亂的數(shù)據(jù)庫轉(zhuǎn)換，除此之外每個訪問該數(shù)據(jù)庫的系統(tǒng)也會改變。所有這些改變必須都協(xié)調(diào)好，當所有對數(shù)據(jù)庫的操作都限制在單個系統(tǒng)時候，這種協(xié)調(diào)是很困難的，但如果有多個系統(tǒng)都在操作，那就更難了，尤其是：如果其中有些系統(tǒng)被不受你控制的參與方管理的時候。事實上，在系統(tǒng)開發(fā)階段做這些更改就已經(jīng)很成問題了。其后果是，數(shù)據(jù)庫設計早在系統(tǒng)開發(fā)階段就被凍結，然后數(shù)據(jù)分析師們再去竭力修正這些設計。
現(xiàn)在的問題是數(shù)據(jù)分析師們面臨著不可能完成的工作。他們必須在用戶理解這個設計（且不說贊賞這個設計實際應用如何）前就確定該設計。只有在過了很久之后——系統(tǒng)已經(jīng)構建好之后——用戶才能對該系統(tǒng)有所體會并對其是否滿足自己的需求作出評估。如果此時發(fā)現(xiàn)數(shù)據(jù)結構上有任何大問題，要想修復就太晚了。
喜歡 
頂
難過
囧
圍觀
無聊
