SOA：構建更好的企業應用架構

面向服務的架構（SOA）絕對是一大熱門。但是，重新調整網絡以適合Web服務應用的時機是否成熟呢？

由于Web服務規劃仍處于早期階段，大多數組織在謹慎地改進IT基礎設施，以順應這股潮流。至少，這是面向服務架構（SOA）背后的思想。這個眼下最熱門的概念備受Web服務廠商、分析師和幻想家的推崇。SOA也許是一個好東西——前提是實施得當。

嚴格說來，SOA并不是什么新概念，只是通過網絡上可以發現的共享服務來提供應用功能的一種方法。其原理是，通過把應用程序從底層硬件提取出來，從而提高資源使用效率。有了可以重復使用的軟件組件，就可以簡化定制應用程序的開發，這樣與使用依賴特定服務器的服務相比，IT人員就可以更有效地滿足最終用戶的需求。

就在不久前，這個概念還很難付諸實踐，主要是因為SOA歷來依賴專有的中間件，這種中間件往往讓獲得的各種效率蕩然無存。Web服務的出現改變了這種局面。由于整個行業投入到了XML、簡單對象訪問協議（SOAP）、Web服務描述語言（WSDL）以及通用描述、發現和集成（UDDI）的標準化工作，使用所有競爭廠商都支持的接口，就可以發布、發現及調用服務。 SOA不僅僅是Web服務的集合體，也是發布、發現、運行及管理支持企業應用的服務所需要的技術架構。雖然Web服務確實簡化了SOA的推廣，但它仍影響網絡性能和IT安全的關鍵決策。

不成熟的Web服務讓設計SOA進一步復雜化。仍在竭力應對XML的企業面對不斷變化的標準無所適從。原先來自不同市場的廠商開始競相提供SOA解決方案，都聲稱各自為這種架構提供最重要的部分，無論是管理、安全和開發工具，還是讓SOA有別于獨立式Web服務的中間件——企業服務總線(ESB)。其中一些解決方案對SOA至關重要，另一些方案將依賴現有的IT架構和組織目標。

值得一提的是，SOA不是套裝應用軟件，也沒法從哪家廠商處購得。實際上，SOA可能根本就不需要任何附加的軟件或者技術。

SOA上路應用效果明顯

SOA的主要優點是靈活。不像以前的計算模式如客戶/服務器和大型機環境，SOA把IT功能作為跨平臺的共享服務來提供。這帶來了諸多好處，但最立竿見影的就是可以通過重復使用現有資產，獲得明顯的投資回報。

一旦SOA中有了一組Web服務，這種重復使用好處就會急劇變大，這就是“SOA網絡效應”。SOA的價值會隨著可用服務的數量以及使用這些服務的不同應用程序或者用戶的數量而增加。這種價值會隨著時間的推移不斷增大。如果SOA在組織內外得到利用，增幅會更驚人。

企業開始可以讓SOA用于內部服務，然后擴大范圍，用于面向客戶的應用。這需要與商業合作伙伴交換XML數據，這種做法在電信業和旅游業變得越來越常見。SOA還有助于面向客戶的B2B應用，在這種情況下，用戶并不知道底層的基礎設施。

譬如說，一家銀行可以使用客戶的門戶網站，支持客戶查詢和要求訪問多個遺留后端系統的自助服務功能。SOA方案可以把這些功能作為Web服務，提供給面向客戶的門戶網站和銀行內部員工。這就減少了提供全面訪問遺留系統功能所需的內部集成工作，因為所有應用都使用同一個SOA接口。

SOA的靈活性還可以讓組織受益，因為可以加快應用開發，通過重復使用硬件部件和軟件組件，來降低成本。用這種辦法開發應用程序的其質量可能比獨立開發的還要高，因為組件預先經過了測試，Web服務接口也已經得到了驗證。

這些好處絕不是推測出來的。摩托車生產商Harley-Davidson之所以能夠在短短三年內為經銷商開發及推廣IP電話系統，要歸功于使用Web服務進行應用集成。該公司運行BEA Systems的WebLogic應用系統，并輔以自己內部設計的Java框架，以構建可以重復使用的SOAP服務。VoIP鏈路可以重復使用原先為CRM應用系統設計的經銷商聯系服務。

為SOA而開發的應用程序具有的速度、簡潔和質量讓許多分析師認為，這種架構是可以使企業目標與IT服務和功能相一致的一種方法。如果實施合理，其靈活性會滲透到整個網絡、乃至整個組織。IT部門可以隨意改動技術，不必對可用服務進行改變；企業也可以改變其應用程序或者業務流程，IT架構受到的影響極小。

在試圖集成不同系統（如企業并購帶來的系統）時，SOA的靈活性顯得特別重要。譬如說，在自然增長和多次并購后，辦公用品零售商Staples發現居然在使用五個重復的信用卡授權系統。Staples于是實施了五個系統都使用的Web服務，而不是改用單一授權系統，或者是構建多個接口連到每個后端應用程序。SOA提供了運行時支持、管理和安全功能，這樣，五家銀行和票據交換所當中哪家能夠為某筆支付提供最佳服務，Staples就可以通過它來轉發信用卡交易信息。如今，Staples每年總共要轉發100萬條交易信息。

沒有Web服務的SOA面臨挑戰

可以實施沒有Web服務的SOA。這種概念自面向對象技術興起以來就已存在，表現為遠程過程調用（RPC）中間件解決方案，如微軟RPC和Java遠程方法調用（RMI）。這些解決方案基于公共對象請求代理體系結構（CORBA）、分布式計算環境（DCE）以及組件對象模型/分布式組件對象模型(COM/DCOM），實施的是同步的客戶/服務器通信模式。一個應用程序在其中充當客戶機，另一個充當服務器。

與Web服務相比，這種模式有兩大缺點:首先，同步操作會減慢應用程序的運行速度，因為客戶機在服務器完成請求處理之前一直處于閑置狀態。其次，類似RPC的解決方案通常是專有的，無法跨平臺協同工作。最大的難題在于找到一種單一的RPC解決方案，能與各種所需的編程工具和計算平臺兼容，還要價格合理。

譬如說，盡管CORBA得到了最廣泛的平臺和語言支持，但它很復雜也很昂貴。Java內置了支持CORBA和RMI的功能；微軟的Windows支持DCOM和微軟RPC；大多數Linux和Unix平臺支持開放式網絡計算（ONC）RPC。這樣一來，跨異構計算環境實施單一的RPC解決方案也就成了難題。

面向消息的中間件（MOM）為解決RPC的兩個問題起到了一定作用。MOM解決方案實施的是異步對等通信模式，這樣應用程序在等待來自另一個應用程序的響應的同時，就可以繼續處理正常事務，譬如IBM的WebSphere MQ、Sonic Software的SonicMQ、微軟的MSMQ和TIBCO Software的Rendezvous。這種方法通常與松散耦合連接有關，這樣一來，消息處理方式有了更大的獨立性。

不過MOM在解決問題的同時也帶來了問題。MOM解決方案的缺點在于：實施起來往往比基本的RPC來得復雜，也很昂貴、具有專有性。雖然Java平臺提供了Java消息服務（JMS）API，可以連接到幾乎各種MOM產品，但SonicMQ無法與WebSphere MQ協同工作，WebSphere MQ也無法與Rendezvous進行聯系。這兩種應用系統想聯系，就必須使用相同的中間件層。

使用Web服務的SOA類似于使用MOM的SOA，不過用支持同步RPC和異步消息傳送的開放標準取代了專有的中間件。無論SOA運行在Sun的J2EE上、微軟的.NET上，還是運行在遺留平臺上，都使用同一行業標準——XML來提供服務。

注冊中心、ESB和WSM是SOA的核心

SOA要發揮作用，就得有許多核心架構要件。大多數SOA用戶會看到的第一個部分就是服務注冊中心（services registry），它通?；诿嫦騑eb服務目錄的XML標準——UDDI。

第二個部分就是企業服務總線（ESB），又叫Web服務代理，它負責處理消息，把流量轉發到最合適的應用程序或者服務。如今ESB越來越多地與監控SOA性能的Web服務管理（WSM）平臺結合在一起。

最后，Web服務安全或者身份管理解決方案通常少不了。

1．需要注冊

服務注冊中心充當信息庫，存放著SOA當中有可用的Web服務信息。注冊中心本身使用UDDI來加以發布，而客戶機在調用服務時，需要WSDL文檔。因而，客戶機或者用戶就可以瀏覽UDDI注冊中心，然后請求某項服務所需的WSDL文檔。一些廠商通過獨立產品提供UDDI注冊中心，譬如Systinet、Cape Clear Software、IBM、微軟和Novell。不過若要構建SOA，與Digital Evolution等公司的WSM平臺進行捆綁的服務注冊中心可能更吸引人，因為那樣兩者可以緊密集成。

WSM本身為調用Web服務提供了運行時環境，還負責管理服務運行、執行服務級別協議（SLA）。SOA市場有著大量的解決方案，包括Actional、AmberPoint、Infravio和Service Integrity等。

一些WSM廠商強調自己在這一大類當中提供不同的功能，不過它們通常提供相似的功能。譬如說，Digital Evolution強調安全和可靠消息傳送功能；Infravio強調管理SLA的功能；Service Integrity強調監控和可見性;其他廠商則強調負載均衡和故障替換這些操作。WSM廠商們也在開始整合其他產品類別的功能，包括安全和ESB這兩類，旨在逐步構建完整的SOA解決方案。

2．混合搭配

如今，還沒有哪家廠商能夠提供單一、綜合的解決方案。SOA也需要ESB把XML解析成SOAP消息或者其他Web服務消息，然后相應地轉發或者轉換這些消息。旨在增強現有IT架構的ESB還為開始向SOA遷移的組織提供了一系列穩健的功能。許多廠商提供獨立的ESB，包括Sonic、Fiorano Software、Cape Clear和Blue Titan。

一些分析師預計，WSM系統和ESB會在將來趨于融合，因為兩者功能有重疊之處。其實，有關ESB的一份白皮書聲稱，ESB是“預包裝的SOA實施方案，已經包括了實現SOA目標所必需的功能部件”。這番夸大之辭忽視了SOA的許多核心功能，譬如管理和服務發現功能。ESB功能是任何SOA的一個關鍵方面，但僅有它還不夠。

3．服務安全

與網絡上的其他各種資源一樣，Web服務也需要確保安全。Web服務安全方面的標準已成了所有廠商關注的焦點，這些標準往往分為兩大類：Web服務安全本身和聯合身份管理（federated identity management）。

這兩類都為具體實施提供了諸多選擇。WSM解決方案（如Digital Evolution的方案）往往包括了對基本Web服務安全標準的支持，而Forum Systems和Reactivity等廠商提供專用的安全設備。聯合身份管理通常包括在Netegrity、Tivoli、RSA Security和Novell等廠商的單次登錄（SSO）解決方案里面。

Web服務安全通過Web服務安全（WS-Security）和安全聲明標記語言（SAML）這些新興標準，滿足對驗證、授權、機密性和數據完整性的需求。WS-Security 和SAML都基于現有的安全標準，從基本的安全套接層（SSL）、X.509證書、XML簽名到XML加密等。

自由聯盟（Liberty Alliance）負責基于標準的聯合身份方面的大多數工作?；赟AML的聯合身份把權限與身份聯系起來。在SOA當中，用戶和應用程序都一定要有身份。

隨著Web服務從內部集成項目，擴大到針對客戶和商業合作伙伴的面向外部的服務，聯合身份也變得越來越重要。這會導致WSM廠商和身份管理廠商加強合作，前者擁有經過實踐證明的保護Web服務安全的解決方案，后者擴大了SSO解決方案，以支持Web服務應用程序和SOA。

另辟蹊徑的附加方案一樣精彩

除了注冊中心、ESB和WSM外，大多數SOA還包括取決于組織特定需求的其他部分。如果某家企業自行開發工具，會需要Web服務開發和編程工具，譬如集成開發環境（IDE）和WSDL編譯器。

一旦SOA達到臨界數量，核心架構可能也會得到其他新興解決方案的補充。其中一些方案非常吸引人。譬如說，SOA策略和監管解決方案可以幫助網絡設計師定義及執行Web服務訪問規則。元數據也很重要，因為XML具有無限可擴展性。而WSM解決方案必須能夠處理及管理Web服務文檔里面的所有元素。

即便沒有SOA，Web服務也需要使用附加產品。XML加速或者安全設備在組織內部的Web服務數量激增時，可以提供逐步提升性能這一重要功能。

為實施SOA提幾條建議

SOA市場出現了群雄逐鹿的局面。SOA新興公司提供先進工具，來幫助企業構建及運行SOA和其他Web服務，向擁有龐大用戶群的老牌廠商叫板。IBM、微軟、SAP和甲骨文等老牌廠商也絕不會輕易把控制權拱手讓給WSM和ESB廠商。

網絡設計師真正面臨的問題就是找出促使實施SOA的主要動因。這些動因通常與SOA的靈活性帶來的諸多業務和技術問題有關。譬如說，往往啟動SOA和Web服務計劃的是一些至關重要的商業需求，譬如獲得收入和客戶忠誠度、提高內部的IT和業務效率，或者降低成本。明白這一點，有助于闡明需要哪些SOA核心解決方案，以及實施的先后順序。

譬如說，如果SOA的主要功能是提供面向外部的Web服務，那么最重要的功能就是可靠的安全和WSM解決方案。如果某家組織的初期目標是致力于集成，那么用Web服務替換或者補充企業應用集成（EAI）策略，就能獲得投資回報。這種情況下，SOA可能需要基于ESB、并且結合現有的消息傳送和集成技能的解決方案。

現有用戶群也會影響到遷移到SOA的決策。有J2EE架構的組織可能會根據應用服務器解決方案如BEA的WebLogic或者IBM的WebSphere，來制訂SOA策略。同樣道理，SAP用戶會傾向于把NetWeaver作為SOA的中心。不過，這些觀點忽視了兩個關鍵問題。首先，這些技術解決方案本身不是SOA;其次，SOA也并非涉及哪一家廠商或者是哪一款產品，而是涉及讓IT人員能夠針對組織的需求做出更迅捷的響應。

理想的SOA最初應當從業務角度來開發，與任何廠商無關。這保證了重點可以放在SOA提供的服務上，而不是產品或者技術上。一旦確立了這個大環境之后，為了引入及支持SOA，應當評估現有IT架構和應用組合；也應當調查新的SOA解決方案，以便構建穩健的SOA核心。

每家廠商自然聲稱，自己的SOA方案是最重要的。ESB、WSM、UDDI和安全廠商都認為，單單自己的解決方案就足以把現有的IT架構轉變為SOA，但實際上，所有這些功能缺一不可。設計網絡時，首先應當關注SOA的哪個核心要素對用戶的需求最重要，但這僅僅是第一步。將來，可能還需要全面的SOA解決方案。

最終，SOA解決方案必須始終支持組織的目標。也許，SOA方面的真正較量在于保持這個重點。實施SOA必須首先是業務決策，其次才是如上所述的技術選擇。如果IT主管能夠牢牢抓住這個重點不放，就不會為廠商之間的口水戰所動，讓SOA需求與業務目標相一致。

注：名詞解釋

● UDDI服務注冊中心 讓Web服務能夠被應用程序看見。鼓勵開發人員向UDDI注冊中心發布所有服務，這樣就可以為重用代碼和共享應用提供一個平臺。它往往是向SOA遷移的第一步。

● 企業服務總線 提供了可靠消息傳送和數據集成基礎。解析XML消息，基于內容進行轉發和轉換。

● Web服務管理 為Web服務提供了可見性和管理。監控服務可用性，以確保服務質量、執行SLA(服務級別協議)。還負責處理負載均衡、故障替換及Web服務可靠消息傳送。

● Web服務安全 為外部用戶或者應用程序訪問的Web服務提供了安全環境。包括加密、數字簽名、驗證、授權、機密性、數據完整性和不可否認性?？赡芘c聯合身份管理解決方案結合在一起。

SOA風險評估

作為一種概念，SOA已成熟。但實現SOA的Web服務技術并不成熟。XML、SOAP、WSDL和UDDI等核心標準在整個行業已得到接受，而其他標準如安全所需的標準還處在發展中。許多組織要投資于SOA，勢必要進一步確定SOA與經營業績有什么明確關系。

SOA沒有Web服務也可以實施，也已有先例，這個事實很鼓舞人心。這意味著，由于Web服務的進入成本較低，而且能夠重復使用現有的IT資產，SOA獲得成功的可能性就更大了。SOA可以采用諸多方案通過諸多方法來實施，不過對每個組織來說，它們各自的好處還不明顯。如果用戶在設計和擴建方面的需求壓倒一切，SOA和Web服務會帶來巨大影響。衡量成功的尺度要與組織的目標和業績聯系起來。即便業務和IT沒有緊密聯系，SOA也會給內部的IT系統帶來好處，從而提高內部客戶的滿意度。

SOA存在兩個風險:一個風險是，向SOA遷移過早或者過晚、未能充分發掘節省成本的潛力;另一個風險就是，SOA實施不當（也就是說，沒有用Web服務），可能會導致組織被過時、專有的技術縛住手腳。