SOA原型法
你可能會(huì)問：“SOA是怎么個(gè)不同尋常呢？”說到底，難道SOA不像數(shù)據(jù)庫范式那樣一樣需要結(jié)構(gòu)化數(shù)據(jù)嗎？這個(gè)問題的簡單答案：不管請求數(shù)據(jù)時(shí)，被人工代理處理還是被自動(dòng)化系統(tǒng)處理，SOA都是管用的，并且就算數(shù)據(jù)沒有被最優(yōu)結(jié)構(gòu)化，人們還是可以解讀它。比如說，用戶可以判斷信件是否正在被發(fā)送至另一個(gè)國家，無論信件的地址是用行一、行二、行三和行四來表示的，而信息系統(tǒng)需要至少“國家”來作為數(shù)據(jù)結(jié)構(gòu)可識(shí)別的一部分。
仔細(xì)回答這個(gè)問題就包括了對SOA原型法的討論，這種討論包括以下幾方面：
識(shí)別將被構(gòu)建到系統(tǒng)中的元數(shù)據(jù)。把它放在主命名空間中，用傳統(tǒng)方式根據(jù)其結(jié)構(gòu)把數(shù)據(jù)存儲(chǔ)到數(shù)據(jù)庫管理系統(tǒng)（DBMS）。例如，用戶信息，這個(gè)元數(shù)據(jù)可能由用戶ID和用戶名構(gòu)成。因?yàn)檫@個(gè)元數(shù)據(jù)被構(gòu)建到系統(tǒng)中，所以為了使用這些字段而把邏輯也構(gòu)建到系統(tǒng)中是完全有可能的，比如通過用戶ID檢索記錄并基于用戶名排序和篩選記錄。
對每一條數(shù)據(jù)庫記錄，把不包含在主命名空間的所有數(shù)據(jù)放到一個(gè)單獨(dú)的XML字符串中，該字符串作為一個(gè)單獨(dú)的字段添加到數(shù)據(jù)庫記錄中。對每個(gè)XML字符串，構(gòu)建一個(gè)二級(jí)命名空間，開發(fā)XSD，同時(shí)添加一個(gè)單獨(dú)數(shù)據(jù)項(xiàng)到主命名空間。對用戶記錄的初步實(shí)現(xiàn)來說，這個(gè)字符串可能包括地址行一、行二、行三和行四的元數(shù)據(jù)。用戶記錄本身的XSD將會(huì)包括三個(gè)字段的元數(shù)據(jù)：用戶ID、用戶名和以XML字符串包括的附加的用戶相關(guān)數(shù)據(jù)。附加用戶數(shù)據(jù)的XSD包括每條地址行的元數(shù)據(jù)。
使用基于XSD的邏輯來為數(shù)據(jù)庫記錄的各相關(guān)層次獲取及展示所有數(shù)據(jù)，這可以通過給每個(gè)XML字符串（包含對主記錄的字符串）增加一個(gè)標(biāo)準(zhǔn)驗(yàn)證服務(wù)來實(shí)現(xiàn)。如有可能，利用某種工具來產(chǎn)生使用XSD的接口而不要自己去編程。該工具必須使用二級(jí)XML字符串所包含的元數(shù)據(jù)來將其解包，并且必須同時(shí)使用主、次兩級(jí)XSD的邏輯來獲取新記錄。其結(jié)果就是一個(gè)可運(yùn)行的原型，用戶可用以評(píng)估預(yù)期使用的系統(tǒng)。
要盡量適應(yīng)和修改基于XSD的邏輯以及驗(yàn)證服務(wù)直到用戶對系統(tǒng)滿意為止。就拿用戶記錄來說，一個(gè)新的針對字符串的XSD可包括以下元數(shù)據(jù)：街道地址、郵編、縣市、以及國家。使用舊XSD存儲(chǔ)的數(shù)據(jù)仍會(huì)正確顯示，所以無需立即將其轉(zhuǎn)換。而使用新XSD將會(huì)獲取新的記錄。
一旦用戶和你確信元數(shù)據(jù)已經(jīng)穩(wěn)定了，那么請考慮把數(shù)據(jù)遷移到傳統(tǒng)的數(shù)據(jù)結(jié)構(gòu)和主命名空間。
當(dāng)然，SOA原型法并不總是必要的。當(dāng)需求受限于如此多的不確定性時(shí)，請使用原型法，這樣先做原型然后再將其穩(wěn)定比較經(jīng)濟(jì)。但是請記住這個(gè)肯定要比數(shù)據(jù)庫化原型法要簡單的多。在數(shù)據(jù)庫化的時(shí)代，原型法只是可有可無，但是在SOA的時(shí)代，它便是家常便飯。不要將設(shè)計(jì)細(xì)節(jié)固定，除非你確定它們是正確的；就是這么簡單。
3.除了要求的不要多做
產(chǎn)品驅(qū)動(dòng)的服務(wù)分解
SOA主要的優(yōu)勢就是它是一個(gè)能被轉(zhuǎn)化成技術(shù)的業(yè)務(wù)概念，不像數(shù)據(jù)庫世界里那樣，技術(shù)概念總想試圖跟上業(yè)務(wù)的步伐。在SOA中，每個(gè)服務(wù)必須明確地增加價(jià)值，不只是在抽象意義層面上，而更具體地要針對那些調(diào)用方而言。發(fā)生的一切之所以這樣發(fā)生了，是因?yàn)榉⻊?wù)請求者要求其如此。通過不實(shí)現(xiàn)任何服務(wù)請求者沒有明確要求的東西，服務(wù)可以被限定在它們的核心功能上。如果SOA中所有的參與者都積極這樣去做，那么將會(huì)使互操作性大大增加。
SOA中最高層次的服務(wù)是業(yè)務(wù)交易：某個(gè)客戶下了一個(gè)貨物或服務(wù)的訂單——除非訂單被供應(yīng)商拒絕——否則這就開始了一個(gè)訂單交付。在SOA范式中，任何從接受訂單到訂單交付之間所發(fā)生的都可以也應(yīng)該以服務(wù)的形式實(shí)現(xiàn)。為實(shí)現(xiàn)訂單交付而要求的每個(gè)中間產(chǎn)品或狀態(tài)，供應(yīng)商會(huì)要求某些人或某些組織機(jī)構(gòu)——不一定是供應(yīng)商內(nèi)部的組織——來執(zhí)行交付。然后這些中間服務(wù)自身又可以分解成多個(gè)服務(wù)，一直到增加價(jià)值的基本組織層面。
層次服務(wù)分解是SOA范式中非常重要的一部分，因?yàn)樗狗⻊?wù)交付通過服務(wù)水平協(xié)議的方式管理。它可以確保每個(gè)服務(wù)都有專人負(fù)責(zé)，并且服務(wù)消費(fèi)者們知道他們會(huì)得到什么。
通用的中間產(chǎn)品和通用的服務(wù)
服務(wù)分解都是關(guān)于產(chǎn)品的。只有當(dāng)組成服務(wù)的那些子服務(wù)不能立即執(zhí)行時(shí)流程才會(huì)出現(xiàn)。例如，如果決定是否接受客戶訂單的服務(wù)要求：先執(zhí)行判斷訂單價(jià)值的子服務(wù)，再執(zhí)行確定客戶信用狀態(tài)的子服務(wù)，那么實(shí)現(xiàn)該服務(wù)就包含了一個(gè)流程。每個(gè)這樣的流程只與一個(gè)服務(wù)相關(guān)。如果你發(fā)現(xiàn)有個(gè)流程不僅限于單個(gè)這樣的服務(wù)，那么你很有可能是忘了把客戶的初始需求建模為服務(wù)了。
有可能出現(xiàn)這樣的情況，相同的中間產(chǎn)品——當(dāng)然還有相同的服務(wù)——可能會(huì)被不同的高級(jí)別產(chǎn)品需要。比如，那些要求明顯區(qū)分交付過程的商品，在中間產(chǎn)品的環(huán)節(jié)，其中的差別一般來說幾乎微乎其微，中間產(chǎn)品其實(shí)也是由客戶來支付——為了從客戶那里賺取利潤，我們需要金額、日期以及讓我們可以冠冕堂皇地向客戶要求支付的條款，實(shí)際是什么則并不用去理會(huì)。在這種情況下，正常的基準(zhǔn)是如果存在通用的中間產(chǎn)品，那么它應(yīng)該由單個(gè)服務(wù)來實(shí)現(xiàn)，而這個(gè)服務(wù)能夠被多個(gè)高級(jí)別的服務(wù)調(diào)用。
這種服務(wù)只有結(jié)果是重要的——不是開始——因?yàn)槭占瘜桓斗⻊?wù)有用的信息是服務(wù)本身的一部分，而不是請求服務(wù)源頭的一部分。需要注意的是：是否需要單個(gè)服務(wù)是由業(yè)務(wù)決定的，和信息技術(shù)沒有任何關(guān)系。如果不管是現(xiàn)在還是相關(guān)的未來，交付相同的中間產(chǎn)品都是切實(shí)有用的，那么就應(yīng)該有單個(gè)服務(wù)。除非在現(xiàn)在或相關(guān)的未來有商業(yè)力量發(fā)揮作用使中間產(chǎn)品發(fā)生結(jié)構(gòu)性分化，那我們最好不要為每組需求分別提供相應(yīng)服務(wù)。然而事實(shí)偏偏相反。在SOA，事物是由相同走向不同，而在數(shù)據(jù)庫化的方法中，事物則是由不同走向相同。
帶有多種行為的通用服務(wù)
你可能會(huì)問，如果需要兩種完全不同的行為而你只為其提供一種服務(wù)，這樣做的意義何在呢？難道我們還在被同樣困擾數(shù)據(jù)庫世界的“一刀切”做法限制？比如，如果我們出售兩種類型的產(chǎn)品，其中一種使用固定價(jià)格而另一種則根據(jù)某些復(fù)雜的公式計(jì)算出變動(dòng)價(jià)格，為什么不用兩種結(jié)算服務(wù)，為每種特定的產(chǎn)品各訂制一種呢？
這些問題很好，但問錯(cuò)了地方。它們是好問題，那是因?yàn)槿魏尾荒艹浞謶?yīng)對發(fā)生在問題域內(nèi)變化的設(shè)計(jì)方法注定會(huì)失敗。但是它們問在了錯(cuò)誤的地方，這是因?yàn)楦鶕?jù)問題域中的變化來調(diào)整方案的靈活性應(yīng)該構(gòu)建到服務(wù)中，而不是圍繞著服務(wù)來構(gòu)建。就拿結(jié)算服務(wù)來說，每次調(diào)用一種方法時(shí)，它應(yīng)該決定這兩種算法應(yīng)該使用哪一種。那樣的話，如果引入第三種結(jié)算算法，那么只有結(jié)算服務(wù)需要去做調(diào)整。請注意這并不意味著結(jié)算服務(wù)必須被設(shè)計(jì)成某種“萬能”機(jī)器；它同樣可以很好地為每個(gè)算法分別調(diào)用相應(yīng)的子服務(wù)。這種選擇——介于多功能解決方案和包含不同組件的框架之間——是一種可以根據(jù)服務(wù)來決定的選擇，因?yàn)樗恍枰环⻊?wù)請求者知道。在SOA中，這種選擇更常見，但目前的做法則常常導(dǎo)致產(chǎn)生框架解決方案，因?yàn)樾枰喙δ芊桨傅母杏X在很大程度上是由于不能從那些需要執(zhí)行的信息里識(shí)別出服務(wù)請求造成的。這種需要高素質(zhì)專家來實(shí)現(xiàn)的帶有如此多參數(shù)的以一應(yīng)十的多功能方案的日子不會(huì)長久了。
堅(jiān)持要點(diǎn)
流程驅(qū)動(dòng)方法也可以使我們分清我們是代表服務(wù)請求者做事還是為自己做事。以服務(wù)請求者身份做的事應(yīng)該作為服務(wù)的一部分來執(zhí)行，而其余的就不應(yīng)該了。通過這種區(qū)分，我們可以讓服務(wù)盡可能簡單，這樣可以在不需要改變各式各樣其他東西的情況下替換掉該服務(wù)。舉例來說，我們會(huì)生產(chǎn)產(chǎn)品來滿足外部服務(wù)請求，但是維護(hù)簿記系統(tǒng)是為了滿足我們自己的需求，而不是請求者的。如果要開發(fā)一項(xiàng)服務(wù)將客戶訂單轉(zhuǎn)變成制造活動(dòng)及賬目簿記，那么只要我們實(shí)現(xiàn)一個(gè)新的簿記系統(tǒng)，我們就要去修改一次這個(gè)服務(wù)。這聽起來似乎還不是太糟糕，但試想一下所有事情都是為我們自己而做，那就太糟糕了。包含最新數(shù)據(jù)的數(shù)據(jù)倉庫的簿記、日志、儲(chǔ)存、員工績效數(shù)據(jù)的維護(hù)：所有這些及其他事情一般都由系統(tǒng)完成，這些系統(tǒng)隨組織機(jī)構(gòu)和時(shí)間的不同而不同，因此在業(yè)務(wù)服務(wù)中包含這些知識(shí)會(huì)降低互操作性，增加了用其他系統(tǒng)來實(shí)現(xiàn)服務(wù)替換的難度。我們可以通過產(chǎn)生通知的方式來避免此類問題，即：如果對這些功能很重要的事情發(fā)生了，就發(fā)出通知，然后它們可以使用通用服務(wù)檢索處理事件所需的信息。
另一類不應(yīng)作為服務(wù)一部分執(zhí)行的業(yè)務(wù)活動(dòng)包括那些一旦服務(wù)請求被撤銷就無法逆轉(zhuǎn)的活動(dòng)。通常來說，這類活動(dòng)包括諸如因客戶訂貨導(dǎo)致庫存量低于補(bǔ)貨水平從而需要訂購補(bǔ)給、注冊新用戶以及更新現(xiàn)有用戶信息。這些活動(dòng)是整個(gè)流程中的各個(gè)步驟，應(yīng)使用單獨(dú)的服務(wù)一一執(zhí)行。
當(dāng)然，這種思維方式可以與數(shù)據(jù)庫范式緊密結(jié)合。但并不是其所特有的，因?yàn)樗cSOA有關(guān)。結(jié)果是，許多SOA的實(shí)現(xiàn)與數(shù)據(jù)庫化的思維方式背道而馳，而正是這種思維方式激發(fā)了他們以自下而上的方式識(shí)別服務(wù)，而非SOA的自上而下方式。在自下而上方式中，原本一開始為某個(gè)問題開發(fā)的服務(wù)也可以為其他問題復(fù)用，這多虧了設(shè)計(jì)它的人對于如何更廣泛地應(yīng)用做了認(rèn)真的思考。SOA中，在多個(gè)上下文中使用某個(gè)服務(wù)是縝密設(shè)計(jì)的結(jié)果，而不是靠直覺，并且從設(shè)計(jì)之初就將所有那些上下文都考慮了進(jìn)來。說到復(fù)用某一服務(wù)來交付某一通用的中間產(chǎn)品就好比說重復(fù)使用前門進(jìn)入房子，不管那扇門是通向客廳、廚房，還是衛(wèi)生間。你能想象廚房設(shè)計(jì)師說：“真妙！那家伙設(shè)計(jì)的室外通向客廳的入口正好可以被我用來作為通向廚房的室外入口！”嗎？任何談?wù)?ldquo;復(fù)用”（如復(fù)用支付服務(wù)）的人都還沒有實(shí)現(xiàn)它。請注意，這并不是錯(cuò)誤的，只是有點(diǎn)奇怪和沒有什么啟發(fā)性罷了。
服務(wù)遵從業(yè)務(wù)
采用SOA方式思考問題的一個(gè)結(jié)果就是SOA會(huì)使得服務(wù)依據(jù)其業(yè)務(wù)意義而非機(jī)械的實(shí)現(xiàn)來表述。例如，名為增加用戶記錄的服務(wù)是數(shù)據(jù)庫化的，而名為注冊新用戶的服務(wù)就是SOA的，即便這兩個(gè)服務(wù)做的事情完全一樣。我們對服務(wù)的命名十分重要，因?yàn)樗嬖V我們是誰在請求該服務(wù)，以及為什么他要請求這項(xiàng)服務(wù)。在這個(gè)特定的例子中，SOA自上而下的方法會(huì)得到一個(gè)結(jié)論，那就是業(yè)務(wù)流程需要一個(gè)有效的用戶注冊服務(wù)，該服務(wù)通過修改現(xiàn)存的注冊服務(wù)（如果有的話）來完成，而不是重新自動(dòng)創(chuàng)建一個(gè)新的。在SOA中，這是用戶注冊服務(wù)的責(zé)任，而數(shù)據(jù)庫化的方法卻會(huì)把這個(gè)責(zé)任推到服務(wù)請求者身上。類似地，SOA注冊用戶服務(wù)自身會(huì)決定用戶ID是什么，而數(shù)據(jù)庫化的服務(wù)可能就會(huì)干脆讓服務(wù)請求者做這個(gè)決定。
匯聚到單個(gè)方案
總的看來，SOA由上至下的思維方式使得很多設(shè)計(jì)決策只存在一個(gè)選項(xiàng)，而數(shù)據(jù)庫化的思考者會(huì)把該選項(xiàng)僅僅看作眾多可選方案之一。這是SOA很重要的一個(gè)優(yōu)勢，考慮到SOA是以互操作性為導(dǎo)向的，而互操作性要求我們行車時(shí)都在同一邊行駛而不用去和我們碰到的每輛車去交涉。那些忽視這點(diǎn)的人--比如通過主張Web服務(wù)只是眾多實(shí)現(xiàn)跨系統(tǒng)邊界SOA的一種方式--能夠一直成功的機(jī)會(huì)和那些只考慮下一步的棋手差不多。誠然，總是有比Web服務(wù)更簡單的方法去連接兩個(gè)系統(tǒng)，但是為了讓呼叫中心或輸出管理設(shè)施能使用相同數(shù)據(jù)你會(huì)怎么做？為了確保數(shù)據(jù)倉庫能夠在你把事件從一個(gè)系統(tǒng)轉(zhuǎn)換到另一個(gè)系統(tǒng)時(shí)得到通知，或者事件一發(fā)生便能及時(shí)通知你的客戶，你又會(huì)怎么做呢？在SOA的世界里，數(shù)據(jù)和事件必須在多個(gè)系統(tǒng)中可用，而Web服務(wù)是能夠確保在低投資和低維護(hù)成本的前提下達(dá)到這一效果的最有效的方法。
存在這一明顯差異的一個(gè)領(lǐng)域就是電子數(shù)據(jù)交換（EDI）。傳統(tǒng)的電子數(shù)據(jù)交換（EDI）技術(shù)旨在確定組織之間通信可能需要的信息，并為該信息定義詞匯。那和定義某一特定的信息交互不是一回事。比如，你可以使用相同的EDI報(bào)文來下訂單、查詢其進(jìn)展以及修改它。兩個(gè)組織想通過這些規(guī)范進(jìn)行通信必須坐下來一起就這一詞匯的使用方式達(dá)成一致。SOA分離了這些關(guān)注點(diǎn)：詞匯由命名空間來處理，而這些命名空間可能會(huì)被多個(gè)服務(wù)使用，每個(gè)服務(wù)有各自特定的目的。
“SOA由上至下方式導(dǎo)致更具體的結(jié)論”的另一領(lǐng)域是這樣一個(gè)問題：是什么筑起了一個(gè)編排過的流程邊界。通常，這個(gè)問題會(huì)引起無休止的爭論。比如，采用輸出管理服務(wù)給客戶發(fā)送確認(rèn)信息是否應(yīng)被編排為用戶流程的一部分，如果是的話，它應(yīng)該采用即發(fā)即棄（fire-and-forget）的方式處理還是應(yīng)該由輸出管理服務(wù)來報(bào)告動(dòng)作成功完成？按SOA的話講，所有這些東西都是用戶意圖的一部分，因此都應(yīng)該被編排的。其他一些行為，比如考慮到新用戶訂單的更新數(shù)據(jù)倉庫或者更新總分類，很顯然都不是用戶意圖的一部分，不應(yīng)該包含在流程編排中，哪怕它們是同一方執(zhí)行的。
4.不要自己做瑣事
通用功能
業(yè)務(wù)服務(wù)應(yīng)該只包含特定于該服務(wù)的那些功能邏輯。它應(yīng)該把其他功能都委托出去。那樣的話，服務(wù)自身就可以盡可能簡單。這使得設(shè)計(jì)、測試以及替換服務(wù)，如有必要的話，更容易。這是個(gè)基本的數(shù)學(xué)知識(shí)：新軟件模塊需要匹配的因素越多，那么同價(jià)位下的成品軟件(COTS)的共性越少，而且若恰好有個(gè)方案可用時(shí)它也會(huì)更貴。如果可以將這些非特定功能委托給標(biāo)準(zhǔn)服務(wù)，那么就可以降低需要匹配的因素個(gè)數(shù)。
服務(wù)可以代勞的首要任務(wù)是瑣事：都是些“家務(wù)事”而非真正業(yè)務(wù)相關(guān)的功能。這些瑣事天生就是普遍的，換句話說完成這些瑣事的方式并不是為支持業(yè)務(wù)上下文的服務(wù)量身定制的。
通用用戶接口
當(dāng)你得知信息系統(tǒng)最不應(yīng)該做的一大瑣事就是管理用戶體驗(yàn)時(shí)你可能會(huì)覺得驚訝。這是一個(gè)通用的功能，應(yīng)該盡可能的采用標(biāo)準(zhǔn)工具來處理。用戶體驗(yàn)包括用戶可以選擇要執(zhí)行工作項(xiàng)的工作列表，工作項(xiàng)執(zhí)行的工具——比如通過啟動(dòng)一個(gè)用戶界面（如果有的話）來關(guān)閉已完成的工作項(xiàng)。它包含了用戶有可能執(zhí)行的交易甄選，輸入信息屏幕的表示——一般是從XSD生成——以及使用和交易相對應(yīng)的標(biāo)準(zhǔn)驗(yàn)證服務(wù)進(jìn)行驗(yàn)證。它包括了保持當(dāng)前用戶上下文環(huán)境，這樣他就無需再次輸入當(dāng)前的客戶、產(chǎn)品、項(xiàng)目、流程實(shí)例或者其他任何東西，而是可以使用這些默認(rèn)值或者在必要時(shí)候重寫它們。它包括了和當(dāng)前用戶上下文環(huán)境相關(guān)的所有文檔的介紹。它包含了用戶可能需要作出響應(yīng)的提示對話框。
所有這些東西都可以使用無需包含任何業(yè)務(wù)知識(shí)的工具實(shí)現(xiàn)�？偟膩碚f，給用戶提供一個(gè)統(tǒng)一、包含所有東西的環(huán)境遠(yuǎn)比為某個(gè)特定行為而優(yōu)化的用戶界面要好。如果有業(yè)務(wù)案例違背了這一原則，請至少記住這點(diǎn)：在穩(wěn)定用戶界之前，不要去優(yōu)化它。
喜歡 
頂
難過
囧
圍觀
無聊
