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)可識別的一部分。
仔細回答這個問題就包括了對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ù)放到一個單獨的XML字符串中，該字符串作為一個單獨的字段添加到數(shù)據(jù)庫記錄中。對每個XML字符串，構(gòu)建一個二級命名空間，開發(fā)XSD，同時添加一個單獨數(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ù)期使用的系統(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)濟。但是請記住這個肯定要比數(shù)據(jù)庫化原型法要簡單的多。在數(shù)據(jù)庫化的時代，原型法只是可有可無，但是在SOA的時代，它便是家常便飯。不要將設(shè)計細節(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)商會要求某些人或某些組織機構(gòu)——不一定是供應(yīng)商內(nèi)部的組織——來執(zhí)行交付。然后這些中間服務(wù)自身又可以分解成多個服務(wù)，一直到增加價值的基本組織層面。
層次服務(wù)分解是SOA范式中非常重要的一部分，因為它使服務(wù)交付通過服務(wù)水平協(xié)議的方式管理。它可以確保每個服務(wù)都有專人負責(zé)，并且服務(wù)消費者們知道他們會得到什么。
通用的中間產(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è)計成某種“萬能”機器；它同樣可以很好地為每個算法分別調(diào)用相應(yīng)的子服務(wù)。這種選擇——介于多功能解決方案和包含不同組件的框架之間——是一種可以根據(jù)服務(wù)來決定的選擇，因為它不需要被服務(wù)請求者知道。在SOA中，這種選擇更常見，但目前的做法則常常導(dǎo)致產(chǎn)生框架解決方案，因為需要多功能方案的感覺在很大程度上是由于不能從那些需要執(zhí)行的信息里識別出服務(wù)請求造成的。這種需要高素質(zhì)專家來實現(xiàn)的帶有如此多參數(shù)的以一應(yīng)十的多功能方案的日子不會長久了。
堅持要點
流程驅(qū)動方法也可以使我們分清我們是代表服務(wù)請求者做事還是為自己做事。以服務(wù)請求者身份做的事應(yīng)該作為服務(wù)的一部分來執(zhí)行，而其余的就不應(yīng)該了。通過這種區(qū)分，我們可以讓服務(wù)盡可能簡單，這樣可以在不需要改變各式各樣其他東西的情況下替換掉該服務(wù)。舉例來說，我們會生產(chǎn)產(chǎn)品來滿足外部服務(wù)請求，但是維護簿記系統(tǒng)是為了滿足我們自己的需求，而不是請求者的。如果要開發(fā)一項服務(wù)將客戶訂單轉(zhuǎn)變成制造活動及賬目簿記，那么只要我們實現(xiàn)一個新的簿記系統(tǒng)，我們就要去修改一次這個服務(wù)。這聽起來似乎還不是太糟糕，但試想一下所有事情都是為我們自己而做，那就太糟糕了。包含最新數(shù)據(jù)的數(shù)據(jù)倉庫的簿記、日志、儲存、員工績效數(shù)據(jù)的維護：所有這些及其他事情一般都由系統(tǒng)完成，這些系統(tǒng)隨組織機構(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)致庫存量低于補貨水平從而需要訂購補給、注冊新用戶以及更新現(xiàn)有用戶信息。這些活動是整個流程中的各個步驟，應(yīng)使用單獨的服務(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)用做了認真的思考。SOA中，在多個上下文中使用某個服務(wù)是縝密設(shè)計的結(jié)果，而不是靠直覺，并且從設(shè)計之初就將所有那些上下文都考慮了進來。說到復(fù)用某一服務(wù)來交付某一通用的中間產(chǎn)品就好比說重復(fù)使用前門進入房子，不管那扇門是通向客廳、廚房，還是衛(wèi)生間。你能想象廚房設(shè)計師說：“真妙！那家伙設(shè)計的室外通向客廳的入口正好可以被我用來作為通向廚房的室外入口！”嗎？任何談?wù)?ldquo;復(fù)用”（如復(fù)用支付服務(wù)）的人都還沒有實現(xiàn)它。請注意，這并不是錯誤的，只是有點奇怪和沒有什么啟發(fā)性罷了。
服務(wù)遵從業(yè)務(wù)
采用SOA方式思考問題的一個結(jié)果就是SOA會使得服務(wù)依據(jù)其業(yè)務(wù)意義而非機械的實現(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)向的，而互操作性要求我們行車時都在同一邊行駛而不用去和我們碰到的每輛車去交涉。那些忽視這點的人--比如通過主張Web服務(wù)只是眾多實現(xiàn)跨系統(tǒng)邊界SOA的一種方式--能夠一直成功的機會和那些只考慮下一步的棋手差不多。誠然，總是有比Web服務(wù)更簡單的方法去連接兩個系統(tǒng)，但是為了讓呼叫中心或輸出管理設(shè)施能使用相同數(shù)據(jù)你會怎么做？為了確保數(shù)據(jù)倉庫能夠在你把事件從一個系統(tǒng)轉(zhuǎn)換到另一個系統(tǒng)時得到通知，或者事件一發(fā)生便能及時通知你的客戶，你又會怎么做呢？在SOA的世界里，數(shù)據(jù)和事件必須在多個系統(tǒng)中可用，而Web服務(wù)是能夠確保在低投資和低維護成本的前提下達到這一效果的最有效的方法。
存在這一明顯差異的一個領(lǐng)域就是電子數(shù)據(jù)交換（EDI）。傳統(tǒng)的電子數(shù)據(jù)交換（EDI）技術(shù)旨在確定組織之間通信可能需要的信息，并為該信息定義詞匯。那和定義某一特定的信息交互不是一回事。比如，你可以使用相同的EDI報文來下訂單、查詢其進展以及修改它。兩個組織想通過這些規(guī)范進行通信必須坐下來一起就這一詞匯的使用方式達成一致。SOA分離了這些關(guān)注點：詞匯由命名空間來處理，而這些命名空間可能會被多個服務(wù)使用，每個服務(wù)有各自特定的目的。
“SOA由上至下方式導(dǎo)致更具體的結(jié)論”的另一領(lǐng)域是這樣一個問題：是什么筑起了一個編排過的流程邊界。通常，這個問題會引起無休止的爭論。比如，采用輸出管理服務(wù)給客戶發(fā)送確認信息是否應(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ù)進行驗證。它包括了保持當(dāng)前用戶上下文環(huán)境，這樣他就無需再次輸入當(dāng)前的客戶、產(chǎn)品、項目、流程實例或者其他任何東西，而是可以使用這些默認值或者在必要時候重寫它們。它包括了和當(dāng)前用戶上下文環(huán)境相關(guān)的所有文檔的介紹。它包含了用戶可能需要作出響應(yīng)的提示對話框。
所有這些東西都可以使用無需包含任何業(yè)務(wù)知識的工具實現(xiàn)�？偟膩碚f，給用戶提供一個統(tǒng)一、包含所有東西的環(huán)境遠比為某個特定行為而優(yōu)化的用戶界面要好。如果有業(yè)務(wù)案例違背了這一原則，請至少記住這點：在穩(wěn)定用戶界之前，不要去優(yōu)化它。
喜歡 
頂
難過
囧
圍觀
無聊
