在過去的幾年里，大大小小的許多公司實施了眾多的SOA項目，但結果多少讓人失望。許多公司漸漸認識到：SOA實施起來比預料的要復雜，不但需要高度關注各個方面的企業數據，還要改變企業文化，程度之深超過以往任何一股技術潮流。  

　　眾所周知，面向服務的架構不是什么新架構。SOA的幾個先行者如通用對象請求代理體系結構(CORBA)和分布式組件對象模型(DCOM)使用松散耦合、面向服務的方法，已經成功地為不同應用架起了橋梁。SOA這股潮流新就新在SOA不僅僅涉及服務。日益興起的互聯網和XML為數據交互敞開了大門。  

　　軟件行業以前所未有的力度支持通用的數據交換格式(XML)和互聯網傳輸協議。因而出現了一大批得到公認、開放的標準，它們能夠實現SOA的承諾：支持業務流程的靈活配置、減少操作成本、能夠動態發現服務，并且在諸多應用、部門和交易合作伙伴之間提供無縫集成。  

　　但很遺憾，讓企業和技術人員大失所望的是，SOA的這些美好承諾并沒有得到兌現。這倒不是因為承諾本身有什么不對，而是因為如今實施的SOA大多數其本質都是試驗性的。好消息是，我們可以從SOA試驗項目中汲取寶貴經驗，而這些經驗有助于SOA試驗項目變成能夠充分發揮SOA潛力的企業級實施項目。  

　　SOA的目標  

　　我們在探討通向SOA的道路面臨的挑戰之前，不妨先退后一步思考，重新分析一下啟動SOA實施項目的組織通常有哪些目標。  

　　一、獲得流程的可見性和靈活性  

　　席卷全球的SOA潮流無疑是合情合理的潮流。SOA已經逐漸融合了分布式計算領域的幾個重大變化。許多組織總是大力投資技術，以便領先競爭對手，而SOA正是提供了這種突破性機會。與此同時，許多組織還一直在改善業務流程，以充分發掘競爭優勢。  

　　新出現的業務流程管理(BPM)有望不斷改進流程、促進業務部門和IT部門之間實現前所未有的協作。SOA是集大成者，在它的統領之下，多家組織齊心協力，獲得全面了解數據和流程的可見性、不斷進行改進，并且以一種有效、透明的方式實施細粒度控制。  

　　二、消除孤島  

　　SOA的第二個目標就是消除應用、部門、交易合作伙伴當中的孤島(silo)。這些孤島是由于多年的軟件開發工作形成的，SOA有望消除這些孤島，讓組織獲得更清楚地了解數據及流程的可見性。  

　　三、管理更準確的數據  

　　一家組織不但需要更有效地管理數據，還需要管理更準確的數據。確保這一點很重要：跨組織及交易合作伙伴生成及使用的數據是干凈的、可靠的、安全的、妥善管理的、易于獲取的。SOA的目標之一就是，為組合式數據服務平臺提供一套統一的組件，這些組件用于數據存取、質量、轉換、管理、緩存及其他許多以數據為中心的服務。  

　　四、重復使用服務  

　　SOA的一個相關目標就是有效地管理及重復使用企業的服務和數據。如果由組織內某一部門開發的服務在易于訪問的注冊中心里面采用標準格式發布并加以描述，它們就可以供該組織內外的其他任何部門使用。如果數據和服務屬于所有者，使用者需要時，又可以共享它們，就能減少與維護及管理數據和服務有關的操作成本。重復使用是SOA最主要的優點之一。  

　　五、統一組織目標  

　　SOA的另一個目標就是協調業務部門和IT部門，共同實現組織的目標：有助于更好地開發靈活、可配置的業務流程。在過去，業務部門和IT部門幾乎采用獨立的方式來提高組織的經濟效益。  

　　而作為SOA的一個方面，BPM可以消除業務和IT之間的分歧，因為它采用了業務部門和IT部門之間通用并且都能理解的一套術語，通過建模、模擬、執行和監控等手段，能夠不斷改進流程。  

　　SOA實施現狀  

　　我們已經知道了SOA的目標，現在看一下幾個迫切需要實施SOA的行業實例。幾個行業如今正面臨法規驅動的監管壓力，譬如金融服務業的《薩班斯-奧克斯利法案》和可擴展商業報告語言(XBRL)，或者是制藥業供應鏈中的藥品“譜系”。  

　　這些法規遵從措施要求各組織從散布于諸多IT系統的孤島收集數據，有時還要求與第三方的Web服務進行集成。這些數據往往必須進行清理，轉換成標準格式，以便能夠交換數據。  

　　另一個例子出現在供應鏈上下游需要應對無線射頻識別(RFID)技術的各個IT部門。RFID能夠實時監控供應鏈，從而提高效率、改善運作。不過，大多數供應鏈和IT應用并不牢靠，因而沒法使用RFID提供的實時、細化的數據。正如我們所知，SOA大大減小了集成的復雜性，并且讓解決方案的完善能夠適應未來需要，又不會給生產環境帶來很大影響。 

非SOA或者半心半意的SOA方案會導致需要定制集成，這需要大筆費用，還會使系統更加呈現緊密耦合的特性，從而使問題更為嚴重。  

　　如今，大多數IT部門只是在嘗試SOA而已。有些IT部門在小規模部署服務，供內部使用。許多部門正在遺留應用上面構建服務封裝器(service wrapper)，以便獲得重用性、降低運作成本。不管怎樣，SOA實施的重心似乎放在了服務層上。  

　　概念有待澄清  

　　SOA這一術語其實用詞不當。SOA與其說是一種架構，還不如說是一套方法，如今，SOA的每一層都有好多種實施方法。AMR研究公司近期的一份調查表明，Web服務是許多組織構建服務的最主要方法，但集成框架、平臺、應用服務器和業務流程管理服務器也得到了積極使用。  

　　構建服務層的選擇非常廣泛，這也許是樁好事；不過對考慮實施SOA的許多組織而言，這也是導致概念混淆的根源之一。  

　　許多組織為了弄明白外人難以理解的技術行話，并且確認合適的服務實施方案，已耗費了太多的時間和精力，結果它們無力顧及行之有效的SOA的其他同樣重要的部分，于是決定僅僅構建服務層，迫不及待地想感受投資帶來的好處。  

　　結果，實施的這些SOA到頭來成了概念證明而已。它們并沒有經過精心考慮，也無法解決重要的問題，如可擴展性、安全和治理。  

　　成功實施企業級SOA面臨許多挑戰。許多組織把大部分精力用在了服務層上，但構架的核心部分：SOA注冊中心和存儲庫卻設計得不夠好，無法進行有效擴展。  

　　SOA原型證明了潛在的好處，但通向真正的企業級SOA這條道路顯得困難重重，大多數組織都不敢上路。企業必須認識到：要發揮SOA的潛力，單單服務層是不夠的。組織制訂的目標與實現這些目標的SOA各部分之間要有切實的對應關系。  

局限和挑戰  

　　現在我們不妨分析一下成功實施SOA所面臨的種種挑戰。  

　　一、文化障礙  

　　消除組織孤島的目標不僅僅帶來了技術上的挑戰。許多公司沒有為這種理念帶來的深層的文化變革做好準備。許多人習慣于完全控制自己使用的特定應用軟件的各方面需求。  

　　如今他們卻要依賴其他部門提供的服務。如果這種變革未認真處理好，就有可能導致有人對交出控制權心存不滿，因為擁有數據和服務的是別人，而不是自己。如果不但與組織里面的部門共享服務，還與外面的交易合作伙伴共享服務，這個問題會進一步復雜化。  

　　二、誰來負責  

　　數據歸屬權和準確性方面有可能會讓人混淆。設想一下：某個應用軟件重復使用由另一個部門擁有或者開發的一項服務，這項服務可能反過來會使用屬于幾個不同部門的其他服務。如果該應用軟件因底層服務出現問題而無法正常運行，想想一路查明問題出在哪一方，并且通過層層服務實行補救辦法、最終修復應用軟件會變得多么困難。  

　　三、實施困難  

　　除了文化和后勤方面的挑戰外，成功實施SOA還涉及許多技術上的挑戰。單單針對實施服務層，許多組織就在采取暫時性的措施。服務層其實只是SOA的一部分而已。即使如此有限的實施范圍，人們也發現實際情況要比預計的來得復雜。他們發現，遺留系統的大小、數量和復雜性使得業務流程配置起來極其困難，這樣實現SOA的其中一個主要目標就無從談起。  

　　新出現的大批服務導致數據管理方面存在可擴展性問題。一小批服務發布到注冊中心、使用者發現后加以使用也許很容易。但SOA的真正優點、確實也是面臨的挑戰在于擁有成千上萬的服務，它們必須有效地加以發布、發現及管理。  

　　消除業務和IT之間的分歧、實現業務流程的靈活配置，這需要投資業務流程管理解決方案。可問題在于，正如服務層實施那樣，如今BPM實施方面不但選擇廣泛，還同樣讓人混淆。  

　　企業級SOA的組成部分  

　　以下概述了實現企業級SOA所必要的幾個組成部分。  

　　一、服務層和注冊中心  

　　如今實施的SOA大多數關注服務層，進而關注發布及發現服務的注冊中心。由于這種架構已落實到位，許多企業已經獲得了大大改進的可見性，遠勝過Web服務描述語言(WSDL)和UDDI等標準出現之前的時候。遺憾的是，正是由于滿足于這種投資回報，大多數實施項目就止步不前——也就是說，等到試圖對建立的模型進行擴展的時候，光有服務層和注冊中心是根本不足以獲得SOA的真正投資回報的。  

　　二、SOA比看起來要復雜  

　　等到通常基于服務層和注冊中心的SOA實施項目開始獲得一定成效時，IT部門和業務部門就會拼命添加越來越多的服務。發布及使用的Web服務數量急劇增加，這會立即讓人把重點放在之前沒有預料到的重要功能上。  

　　需要的第一項功能就是聯合信息管理功能。服務使用者一下子要面對成百上千的服務，所以需要數據和服務的聯合視圖，以便了解它們。需要的第二項功能是SOA數據緩存功能。要是沒有某種緩存功能，就無法快速、可靠地訪問來自SOA實施系統的海量數據。  

　　人們清醒地認識到：數據和服務需要前所未有的治理水平，才能確保有效性，這就需要第三項功能：SOA治理。SOA治理是指定義及執行組織策略和標準的一種方法。這些策略針對諸多業務需求：管理責任和依賴關系、確保業務運作的連續性以及降低成本。因為這些策略定義了控制企業內部數量激增的服務的機制，集成了不斷完善的標準，并且促進互操作性，IT部門也能從中得益。  

　　只有組織采用有條不紊、精心制訂的方法來滿足這些需求，才能真正獲得SOA的投資回報。  
三、SOA存儲庫  

　　SOA存儲庫能夠提供的一套服務要比注冊中心豐富得多，因為它不但可以訪問圍繞服務的元數據，還可以訪問實際的SOA數據。因而，與注冊中心基于元數據的簡單服務相比，元數據以及存儲庫提供的基于數據的發現服務功能要強得多。存儲庫還提供了把策略管理與轉換、聯合、抽象及緩存SOA工件(SOA artifact)等功能集成在一起的優點。業務流程和組合式數據服務可以部署在SOA存儲庫上面并加以管理，以確保它們是集中的、透明的，因而是易于治理的。  

　　由于所有上述原因，SOA存儲庫是精心設計的SOA的一個核心部分。  

　　四、工作流和業務流程管理  

　　我們前面提到了SOA的一個重要目標，獲得業務流程的可見性和靈活性。服務層最能滿足這個目標，可使用工作流或者業務流程管理系統。服務層已成為SOA當中發展速度最快的一部分。這個市場的廠商種類繁多，既有專業的BPM和工作流公司，也有企業應用集成(EAI)和應用服務器公司。  

　　組織內部及組織之間流動的數據大部分是XML數據。只有基于最適合管理這種數據的基礎設施來進行實施，才能充分發揮SOA的潛力。  

　　經過周密計劃的工作流或者BPM產品應當對業務用戶和IT部門來說都很便利。它應當提供無需編寫代碼的流程建模、模擬、執行、監管和調試等功能。  

　　理想情況下，這種產品應當與SOA存儲庫緊密地集成在一起，那樣工作流和業務流程就可以作為元數據來部署，以便集中治理。它還應當支持可重復使用的組合式數據服務的開發、部署及使用。  

　　正確實施SOA  

　　對精心設計的一種面向服務的架構而言，功能齊全的SOA存儲庫是核心部分。一個良好的SOA存儲庫能夠以原生方式嵌入數據管理和治理服務。它為一部全面的詞典提供了語義調和功能。它可以把數據和服務組織成有意義的術語，并且提供生命周期管理和版本控制服務。它還提供了一整套數據服務，可以執行質量管理、驗證、轉換、聯合、治理和緩存等操作。  

　　如果把這些服務部署到SOA存儲庫上，與業務流程和工作流相關的工件、定制的組合式數據服務以及第三方服務也可以自動使用它們。  

　　在附圖中處于顯要位置的另一個部分是BPM/工作流平臺。應用層能夠發現及使用直接來自服務注冊中心/存儲庫層面的服務；也能通過工作流業務流程管理平臺，獲得更大的靈活性。盡管BPM/工作流平臺為諸多應用提供了一套服務，但外部的服務層可以同時對服務進行注冊，以便客戶發現及使用。  

　　我們已提到，存儲庫要處理海量的數據，因此，它在設計時應當注重性能和靈活性。如今實施的大多數存儲庫存在這個問題：它們基于傳統的關系數據庫，而這種關系數據庫根本不夠靈活，連中等規模的SOA實施系統帶來的查詢任務都無法處理。所有SOA數據——工件和消息——都采用XML格式，并且使用層次表示法，這不是非常適合于結構僵硬的關系數據庫管理系統。  

　　隨著SOA實施系統不斷擴展，納入更多的端點/使用者、編制和用戶，這個問題尤為嚴重。缺少功能強大的存儲庫還會導致治理和管理工作的復雜化。譬如說，如果想改變注冊中心里面的一系列WSDL，使用XQuery的強大查詢功能來實現就顯得比較簡單。因為XQuery可根據查詢標準來選擇合理的工件，并進行更新。因為SOA中的大多數工件是XML格式，所以需要以原生方式處理所有SOA XML數據的功能。因而，真正響應及時的SOA存儲庫必須實施在原生XML數據庫(XDMS)上，而XQuery用于數據管理。  

　　XQuery是一種非常靈活、功能強大的語言，用于XML數據檢索及管理。如果結合原生XDMS(XML數據庫管理系統)，那么除了傳統方法外，又多了一種處理巧妙、高性能的選擇。傳統方法針對RDBMS SOA工件存儲區，使用傳統的解析方法，對XML進行中間層轉換，這種轉換既復雜，又緩慢。  

　　XDMS可以加快SOA的實施，因為它使數據能夠作為原生XML加以存儲及處理。當然，不是所有的原生XML數據庫其構建方式都是一樣的，它們提供的功能也不是都一樣的。良好的XDMS應當能夠處理各種XML數據，不必事先知道XML模式(XML Schema)的結構。  

　　事實證明，如果處理的XML文檔來自數據結構不一的聯合系統，那么這種功能就有很大優勢。然后就可以在這樣一個平臺上構建功能強大的組合式數據服務。  

　　用正確的方法使用SOA能夠通過按需獲得的信息、服務重復使用、流程優化、集成創新的第三方Web服務，獲得業務效率、靈敏性及創新。讓SOA注冊中心和存儲庫成為SOA的基石，這可以確保企業的SOA基礎設施能夠得到最佳的管理和治理。  

　　SOA能夠實現一系列廣泛的用例(use case)，可以跨不同的地理位置和交易合作伙伴涵蓋各種系統。回到我們之前探討的其中一個例子，許多制藥公司使用全國藥品代碼(NDC)作為供應鏈和監管流程的一部分。如果新藥添加、召回或者處方藥的專利保護到期，這個NDC數據庫就會不斷更新。  

　　實施了SOA的企業可以訂購應用廣泛的NDC數據庫Web服務，這樣就可以實時更新這些數據，因而新產品推出或者被召回產品從制藥供應鏈撤下時，就可以有效地使用數據，實現靈活應對。  

　　同樣，由于監管部門的各種報告需求在不斷變化，必須從不同的IT系統搜集數據。基于SOA的方法可以輕松解決這個問題：幾個版本的類似Web服務可以在SOA存儲庫里面得到維護，并且可根據數據參數進行動態選擇。