典型通用功能
其他的瑣事還包括，但并不僅限于以下幾個方面：
安全：建立服務請求者身份和訪問權限。
通知：確認某一業(yè)務事件應通知哪些人。這包括了維護基于此的事件訂閱。
輸出管理：在線下進行信息通信，而不是作為一種服務響應。典型例子就是當客戶請求必須被正式確認時，比如使用電子郵件來確認你剛剛通過瀏覽器所做的網上采購。對那些主動提供的消息也是需要的，比如每月的賬單。輸出管理必須決定通過哪條渠道去發(fā)送信息，以及使用哪個地址來發(fā)送。它應該把消息轉換成接收方能夠接收的格式，發(fā)送消息，并把消息添加到歸檔文檔。輸出管理包括維護那些被用來將數(shù)據轉換成用戶可理解消息的模板，以及潛在接收者的地址和渠道偏好。
數(shù)據轉換：把數(shù)據從一種格式轉換為另一個，把獨立的各個服務打包為一個服務——用麥當勞的說法，開心樂園餐——以及分解拆包，將服務請求拆分成適用于不同人群的各個獨立請求，匯集各個回應，排隊及出列，或協(xié)議轉換。
流程編排：編排某一流程，以確保按適當順序且僅相關時來執(zhí)行那些組成流程的服務，確�？煲馄跁r發(fā)送告警信息，以及確保因輔助信息或者逾期打斷從而引起的新流程分支被啟用。
歸檔管理：維護及訪問相關的歸檔信息。這些可能是虛擬的檔案，從某種意義上是展現(xiàn)給用戶的信息，當他需要某個檔案時可以使用查詢來檢索。對那些從數(shù)據庫中抽取的內容，這被認為是正常的，但是沒有特殊理由不對文檔使用相同的方法。在某些情況下應使用設備來特別增加指派文檔至檔案中。
記錄管理：維護那些不允許被更改的信息。
至下而上敘述
這些實現(xiàn)瑣事的服務不能形成業(yè)務服務層次的部分。不能使用自上而下的方式去設計它們，因為這些服務都沒有所謂的“上”。對這樣的服務，使用旨在實現(xiàn)最大程度重用的自下而上的方法會更適合。這使得從這個階段起就能夠實現(xiàn)服務的優(yōu)勝劣汰。
采用數(shù)據庫化的方法，很少能夠實際把次等通用功能用更好的替換，因為這要求修改所有使用該方法的應用。使用SOA則不同，這種替換很簡單，前提是已經應用了“不去了解你不需要了解的事情”這條規(guī)則，包括其推論：服務請求不應該包含超過指定該請求必要信息之外的其他信息，而且服務本身應該在需要時主動要求更多信息。如授權服務，該服務由某應用調用，旨在決定是否允許某特定用戶在某客戶數(shù)據上執(zhí)行某項功能——比如說：“我們的雇員Donald Jones是否被授權可以訪問Acme Widgets company公司相關的財務數(shù)據？”。服務的簡單版本可能具備處理某些特定情況的能力，在此特定情形下可以通過使用雇員功能對應表來回答這些問題。稍微復雜一點的版本可能會識別出Donald Jones屬于某個或多個組的成員，除了個人權限外還擁有該組的權限。再更近一步，授權服務可能會使用用戶證書去區(qū)別雇員和客戶，并允許客戶只能夠訪問他們自己的數(shù)據。一個完善的版本可能會使用標準化的服務去調用業(yè)務流程管理系統(tǒng)或者項目管理系統(tǒng)，詢問Donald Jones是否已經被賦予了任何我們和Acme Widgets交易相關的職責。更好的做法是，授權服務會記錄請求和應答的日志，而簡單的版本不會這樣做。組織可以從一個服務的版本切換到另一個而無需對調用服務的應用做任何改變。
也有可能設計出根據操作必需的條件自動配置自己的通用服務。例如，授權服務可以檢查是否有服務可以告知它員工對某些特定客戶有職責，并在該服務不可用的情況下決定只使用個人還是群組的訪問權限。用這種方式，服務可以在很多組織之間復用。
5.不要在測試上自尋煩惱
為什么SOA更容易測試
對SOA缺點的一種看法是測試困難。這種看法完全不恰當，原因有很多。
首先，在SOA中使用元數(shù)據可以避免錯誤被植入到系統(tǒng)中。可以在元數(shù)據層次就對系統(tǒng)進行驗證，例如，保證所有需要處理的數(shù)據在使用前就被匯總并校驗。在整個業(yè)務流程范圍內都可以實現(xiàn)這點。當你可以驗證設計的時候就不要測試整個系統(tǒng)。
其次，幾乎所有測試，包括所有系統(tǒng)集成測試，一旦測試基準被建立后都可以自動完成。但是，需要一些前提條件。表現(xiàn)層和業(yè)務執(zhí)行層必須被嚴格的區(qū)分。好在這是使用SOA的一種很自然的方式。對所有輸入，都應該存在相應的XSD。使用該XSD，可以生成測試記錄。同理，也可以生成帶有預期輸出結果的測試記錄。在測試過程中，不能產生可以證明系統(tǒng)運行正常的任何輸出地方，必須在測試腳本中添加專門為此生成的附加輸出的查詢語句。當測試開始運行時，測試記錄被一條條輸入系統(tǒng)，然后輸出的結果自動和期望的結果進行對比。這會產生一個異常列表，其中每項都應仔細考慮。測試可以按需進行。自然，測試的結果可能取決于存積在數(shù)據庫中的數(shù)據，所以這點需要進行彌補。而且，系統(tǒng)不可表現(xiàn)出時間相關的行為。系統(tǒng)必須有能力響應每隔一段時間（它對自動化測試序列更適合）就產生的事件，而不是花上一周時間去等待某個基于時間的觸發(fā)器被觸發(fā)。用戶界面的測試應該單獨進行，而且永遠不在集成測試中使用。
第三，SOA的設計趨向于產生更加健壯的系統(tǒng)：系統(tǒng)出錯的機會更少。SOA減少了信息系統(tǒng)為了協(xié)同工作而需要達成協(xié)議的因素數(shù)量，這樣一來，導致在某關鍵因素上產生分歧的設計錯誤的概率也減少了。就算真的出錯，也能夠在造成損害之前檢測到。使用SOA，消息在被處理前會被驗證，這樣可以判斷消息是否格式正確、是否符合相應的XSD。
可行性測試
最后，作為數(shù)據庫時代特有的產物——測試環(huán)境和生產環(huán)境必須嚴格區(qū)分，從此不再需要了，而且有時候這也是不適合的。這是很有可能的，這是因為我們不再實際進行系統(tǒng)測試了，而是對測試通路和信息處理的方式進行測試。SOA提供了三重安全的、有效區(qū)分測試消息和生產消息的方法。除了被封裝好的消息，其他每個消息自身和相應的命名空間都包含版本號。而且每個消息都包含一個標簽用以指示它是用于測試還是生產。所需的只是一個SOA網關，它存在于防火墻內部，對每條進入消息進行如下處理：
校驗消息以確定其是否與一個已知XSD的版本相符（被封裝好的消息除外）。
使用我們對相應XSD的副本對消息進行校驗，以確定其是否有效。
如果消息用于生產的，就驗證消息版本號是否被允許用于生產。只有這樣，消息才能夠被傳遞到生產系統(tǒng)。其他所謂的“生產”消息都會被拒絕。
如果消息用于測試，消息可能會被傳遞到指定的測試版系統(tǒng)。在特殊情況下，消息如果只是用來做數(shù)據檢索，那也有可能被傳遞到生產系統(tǒng)。
只有在消息被完全測試過后，生產版本的注冊庫和XSD才能得以更新。
這樣的處理方法不僅僅只是三重安全的，而且使得消息的路由能以一種合乎實際的方式得到測試。這也大大降低了從測試系統(tǒng)切換到生產系統(tǒng)時重新進行配置的需求。因為這種重新配置天生就是不可測試的，常常成為錯誤的根源。發(fā)布經理只能通過在半夜或者周末發(fā)布新的版本軟件來彌補這類錯誤；這樣，就算新版本出現(xiàn)了任何錯誤，也可以在有人發(fā)現(xiàn)錯誤之前恢復到老版本。但如果這樣的變化影響到了其他組織那就沒有辦法這樣操作了。SOA發(fā)布管理要簡單得多！
我們對于SOA測試的一般認識是時候該改變了。SOA是能夠把測試需求和設置測試的工作減少到最低的一種方案。它能使重要測試更自動化的完成，結果也更好。
完善之理論
SOA使得信息系統(tǒng)的開發(fā)和部署能夠比使用數(shù)據庫化的方法支持更為豐富的用戶體驗。這樣的系統(tǒng)能夠涵蓋更多的信息格式、更廣的行為集合，其行為上也可以達到更高層次的統(tǒng)一和一致以及更加可靠，不管是從客戶還是從組織內關注合規(guī)的人員的觀點來衡量。然而，要想獲得這些好處需要我們跟已有的數(shù)據庫方法實踐說再見。
6.始終信守你的諾言
為什么數(shù)據庫不能一直信守諾言
接收一個服務請求的動作是通過定義一個承諾，即向請求者承諾服務請求會被執(zhí)行，來確定的。這種執(zhí)行定義了一個流程，其至少包含一個步驟，但通常是多個步驟。
數(shù)據庫化的思考和流程不能融洽相處。從它們各自的本質來看，數(shù)據庫就像是一個個孤島。而孤島會促使偏狹地思考問題：任何孤島之外的東西都不重要。可以通過數(shù)據庫中的事務概念來形象地解釋這個問題：某個工作單元把數(shù)據庫從一種一致性狀態(tài)轉移到另一個。在一些特殊的情況下，該概念可能會被擴展到多個數(shù)據庫，雖然可以通過兩階段提交技術來做，但這也有局限性。邏輯一致性可能需要貫穿整個業(yè)務流程得以維護，而不只是恰好在某個時刻；需要在信息改變波及的所有地方去維護，其中不僅包括數(shù)據庫還有流程管理系統(tǒng)、信息以及發(fā)送和接受信息的人工代理，而這一切從數(shù)據庫世界的觀點看來是完全陌生的。
喜歡 
頂
難過
囧
圍觀
無聊
