實戰SOA 擺脫人們對SOA的嚴重誤解

許多企業在構建SOA，但進展相當緩慢，這主要是由于SOA涉及方方面面，關系太多，太復雜。通過本文可以了解一些公司在部署SOA時實際遇到的問題以及解決方法。

如果問起負責構建面向服務的架構(Service-Oriented Architecture,SOA)的人什么最困難，他們中很多人會告訴你: 最困難的部分不是技術，而是改動業務流程以及隨之而來的角色和職責的重新劃分。許多SOA實施者也這樣說，而事實可能的確如此。但技術這方面卻未必簡單， 在所有規劃和戰略制訂完畢后，如何提供及管理服務及消息傳送基礎架構，還有如何處理已有的平臺、應用和系統，并非易事。

SOA的最終目的是獲得極其靈活的基礎架構，使IT人員可以在企業里面橫跨多種平臺和領域的抽象層上開發組合式應用，但誰也無法一蹴而就。在實 際應用時，技術人員必須做出以下關鍵決策: 在哪些平臺上構建服務; 這些服務又將如何被提供、管理。有些公司可能會選擇使用企業服務總線(ESB)來連接服務，另一些公司可能為追求重用而選擇標準化的服務?，F在，有不少公 司在SOA上進行了實踐，分析一下這些公司的決策，可以為實際需要構建SOA的人提供寶貴經驗。

構建、提供及監控服務

選擇構建服務所需的平臺恐怕是IT人員面臨的最簡單決策了。大多數組織從頭開始編制服務時，只需充分利用開發人員的強項即可，因為面向各大開發 平臺的Web服務創建工具已趨于成熟，這些平臺包括Java應用服務器、Windows上的.Net和z/OS上的COBOL等。不過，把現有應用的功能 作為服務來提供時，一些公司也使用ESB作為平臺，原因是服務可以通過配置而不是編碼來提供。

在完成服務構建及測試之后，開發人員就可以把該服務發布到服務注冊中心(Registry)，那樣授權者就能發現它，其他服務或者應用也能使用 它。如今，大多數注冊中心與指向服務元數據的存儲庫(Repository)結合在一起——包括管理服務開發的策略，譬如安全設計規則以及運行時管理參數 (如服務級別協議或者預期負載)。

英國電信公司的策略和架構部門主管George Glass說: “一開始我們就認識到，我們需要存儲庫工具?！钡娦殴締覵OA項目的時候，市場上其實還沒有存儲庫工具，于是該公司使用Borland設計工具 作為存儲庫，通過自己重新創建的Web接口把服務提供給業務分析人員。

哈特福德保險公司的基礎服務部門主管Ben Moreland說，哈特福德公司把可用的服務發布到通用描述發現集成協議(UDDI)注冊中心，不過是使用Excel電子表格和數據庫作為其存儲庫。作 為整個企業的參考架構項目的一部分，哈特福德公司現在正準備建設比較正規的存儲庫系統。讓Moreland高興的是，公司當時采取了等一等的策略，因為現 在的注冊中心/存儲庫產品能夠有效地處理元數據。

eBay公司負責系統開發的副總裁James Barrese說: “一旦部署了服務，人們使用服務的速度就會比你想像的快得多。所以基本的基礎架構需要落實到位，包括使用者和發布者中央目錄、詳細記錄操作的日志以及儀表板(dashboard)等操作監控技術?！?

有關服務的存儲庫元數據一般描述應當會出現什么，而不是實際出現了什么。在SOA中，必須實時監控服務的性能、可用性及使用情況——這往往借助 于Actional(最近被Sonic Software收購)、AmberPoint或者Blue Titan(最近被SOA Software收購)等廠商提供的服務管理產品。這些解決方案還支持版本控制、故障替換和消息日志等功能，并提供了集中視圖，可以了解網絡上服務的總體 運行情況。

eBay把服務質量(QoS)的參數添加到了服務模板中，其中內置了速率限制和日志功能。正如Barrese所言，這項功能旨在確保實施起來具 有統一性和一致性。比如儀表板服務可以監控日志，以發現性能問題， 負載過大的服務知道性能有問題后，可以請求支持或者通知IT分析人員。

要不要采用ESB

服務的監控及提供相對比較簡單。最讓人困惑的SOA決策是服務如何聯系、服務之間應采用哪種仲裁機制。

在理想情況下，SOA中的每個服務都應符合標準的Web服務規范，健壯可靠，而且可以供需要服務的應用或者XML負載的一系列眾多授權的應用或 者服務直接使用。但實際上，企業需要應對使用從MQ到AS2等各種專有協議的遺留系統。而許多人認為，只有WS-Reliable Messaging等Web服務協議完全成形，并得到廣泛實施，Web服務的傳送才會獲得企業所需的可靠性。

于是，ESB蜂擁而入——ESB是如今與SOA關系最緊密的一類產品。ESB是一種消息傳送總線及服務平臺，有了它，連接舊系統、管理及編制服 務就會比較簡單。與企業應用集成(EAI)產品一樣，ESB也負責轉換及發送消息。ESB廠商對自己的產品是否基于標準非常重視，目前大多數使用Java 消息服務(JMS)或者某種專有的消息傳送協議，目的是為了提供必要的可靠性。

支持者喜歡ESB是因為ESB讓他們可以配置服務、管理服務之間的聯系。經歷了好幾年沒有ESB的日子后，工資單處理服務市場的巨擘ADP公司 最近采用了分布式ESB，因為“很難維護大批一對一的消息傳送適配器”，該公司雇主服務部門的CIO Bob Bongiorno說。這家公司的服務數量從9個增加到了30個以上，但在此過程中，“管理難度絕不是僅僅增加了三倍”。

Intuit公司集成架構解決方案部門的首席架構師Martin Moseley說，ESB適用于需要編制的長時間運行流程，譬如訂單處理。在這種流程中，各步驟必須按某種次序來進行，而且整個過程都要進行驗證。譬如， 在計算運費或者批準使用信用卡之前，訂單流程可能需要驗證顧客的地址(原因是驗證信用卡往往需要地址); 只有完成了所有步驟，才可以發送貨物清單。Intuit的訂單處理系統就使用這樣一種仲裁服務方法。

但也有人認為ESB只是改頭換面的EAI而已，他們認為ESB有悖于SOA的開放性。伯頓集團的分析師Anne Thomas Manes認可使用ESB配置服務，甚至把細粒度服務編制成可廣泛訪問的粗粒度服務，但抨擊了總線作為傳送所有服務的網關這一概念，尤其當ESB消息的來 回傳送帶來額外開銷時，她更是覺得不能接受。

性能、安全和運行時治理

要不要使用ESB取決于每家組織的獨特需求和情況。譬如說，如果分布式服務的編制必不可少，而這些服務沒有接入到異步消息傳送基礎架構，編制起來難度就會相當大。

不過單單有了ESB并不等于就有了SOA。在實施的各種規模的SOA中，一般不會只有一種?？赡苄枰B接多條消息總線，而且消息在這些總線上傳送過程中還需要轉換。

思科、Forum Systems、IBM DataPower、Layer 7和Reactivity等廠商提供的新一代XML設備非常勝任這項工作，這類設備主要用于保護、管理及提升SOA的性能。這些廠商銷售的設備可以根據內 容來轉發XML消息，并使用專門為此設計的處理器高速完成XML轉換、轉發及映射等工作。

這些設備大多集成了一系列功能，其中許多功能與ESB的功能相重疊。它們尤其善于對服務進行虛擬化處理，這樣一旦需要提升性能時，就可以動態創建服務，而且可以在運行時使用集中管理軟件，執行針對服務制訂的策略。大多數設備還包括了一系列XML安全功能。

實際上，上述這些廠商銷售的首批設備是XML防火墻，用來阻擋基于XML的威脅和拒絕服務攻擊。如今，XML安全設備支持加密/解密、驗證、身份管理、XML模式驗證及更多功能，既可以控制應用訪問，又能保護網絡邊界。

隨著SOA日趨成熟，安全服務必不可少。ADP公司就是這種情況，該公司現正致力于部署標準安全模型，作為供其他所有服務使用的集中流程。同 樣，技術服務提供商USi也在使用聯合身份管理驗證用戶身份。高級技術部門的副總裁Mike Rulf說: “服務可能甚至不知道用戶是誰，但知道該用戶已在服務傳送過程中的某個階段通過了驗證，因為服務傳送了這些驗證信息?！?

AMR研究公司的高級分析師Dennis Gaughan提醒道: “SOA中的安全沒有得到足夠的注意?！痹缙陧椖客鶄戎赜诙x服務和傳送接口，或者側重于把業務邏輯與數據邏輯彼此分開來，并且把它們與執行及顯示分開 來。但隨著服務得到廣泛使用及采用，重新改動服務以適應訪問控制和授權機制就變得困難重重——這往往需要大范圍改動，因為安全控制會改變流程和數據流。

USi公司的Rulf說，這就是為什么一開始考慮到安全性比較明智的原因，哪怕你的安全服務和系統還沒有得到部署。在USi，所有服務都有一個 標準的Web服務描述語言(WSDL)模板，模板包括了安全驗證和訪問控制，還包括錯誤報告、調用行為及數據預期等，確保一開始服務就有安全性。

使用LDAP將是身份管理項目的關鍵，Turato計劃讓所有服務都包括調用LDAP查詢的機制。為了防止每個服務在每次運行時進行直接查詢，Avis Budget現計劃在業務流程的特定階段進行查詢，然后把該驗證信息傳送給以后的服務。

這種方法存在的風險是，有人只要一路傳送“通過驗證的”屬性，就可以騙過驗證機制，所以Turato準備把驗證屬性變成簽名，簽名可以跟蹤驗證在何處進行、何時進行，目的是為了確保在合適流程的合適階段進行了驗證。

測試及調試服務 部署SOA時常不被重視的另一個工作就是測試及調試。ADP公司的Bongiorno說: “從許多方面來看，實施得當的SOA有助于你更快進入市場，但測試方面需要一些時間?！?

雖然使用嚴格定義的服務接口有助于緩解服務集成測試工作，但服務之間多對多聯系的性質以及配置服務的眾多軟硬件系統給測試帶來了難度。eBay 的Barrese說: “你總不至于把整個企業變成質量保證實驗室，”所以你得盡量擴大測試平臺，但又不能影響企業業務的正常運作。

eBay自行開發了部分質量保證工具用于自動遞歸測試，幫助測試SOA固有的許多執行場景。同時也使用現成工具，譬如Mercury Interactive開發的工具(ADP公司也使用Mercury的自動遞歸測試工具)。另外，eBay正在評估采用開放源代碼的Apache Axis服務測試工具與其BEA和IBM平臺的兼容性。

一個與此有關的難題是版本控制。隨著服務越來越大，常常需要支持多個版本，因為你沒法同時更新所有服務。注冊中心或者存儲庫可以維護版本信息，作為那些服務的標準屬性的一部分。這種保護措施很重要，因為這樣其他服務就可以相應調整期望。

當然，再全面的測試也不可能發現每個錯誤，比如，很可能會在監控過程發現事務錯誤。但要在運行時確認服務本身的邏輯錯誤，調用服務必須查看返回的消息，才能根據業務流程的規范，知道格式、策略或者其他預期屬性是否出現不一致。

立足于自己掌握的技術

選擇哪一種開發平臺、注冊中心/存儲庫、管理模式、消息傳送系統、安全技術以及測試工具，這會讓人暈頭轉向。人們很容易陷入戰術性決策，譬如要不要購買ESB、向誰購買。但你應當在確定了業務流程、核心服務和整體架構之后，再去選擇方案。

咨詢公司TekFinancial Solutions的總裁Bill Adiletta說: “討論一大堆技術只會讓人分散精力?！眲e試圖評估所有可能的技術，而是要看看已有的技術，擯棄無法滿足你需求的任何技術。如果公司內部的技術無法勝任，不 妨把目光轉向外面的廠商。他說，在剩下來的合適技術當中，選擇最符合現有技術基礎和技能組合的那些技術，盡可能避免專有技術。

Hurwitz說: “如果你對SAP產品堅信不疑，那么SAP的新平臺NetWeaver可能值得一用。不然，需要認真分析一下你的應用，然后把它們作為服務來提供?！蹦阆?要分析組件部分，然后決定需要什么。一旦服務清晰起來，你就可以關注像服務總線和業務流程引擎這些技術，以便根據需要來管理服務。

譬如說，通用汽車公司在2001年的第一批Web服務項目使用了J2EE平臺，那是把公司的14個汽車品牌合并起來的一項網上購車服務。通用汽 車新興技術部門的首席架構師張洪說他喜歡這一點: J2EE另外有一層可以供數據訪問，這樣就便于處理許多數據源，又不會圍繞數據源形成相互依賴的業務流程。

就宏觀而言，選擇特定的平臺和技術只是戰術性決策，而不是戰略性決策。畢竟在SOA中，流程、數據流、數據定義、服務接口和策略等應當加以抽 象，以便它們不依賴特定的技術。伯頓集團的分析師Manes稱這一難題是“面向企業的規劃、針對本地的實施，SOA并不是中間件”。

最重要的是設計好SOA時理清架構和業務流程，然后搞清楚實施需求、可接受的折衷方案、可能會有的數據流和流程以及管理和性能需求。弄清楚了這幾個方面，你就可以使用自己喜歡的任何技術來構建實際的服務和支持性基礎架構。

一切圍繞架構

一碰到實際工作，人們很容易陷入戰術性決策，譬如要不要購買ESB、向誰購買。但SOA的要點在于創建這種架構: 支持目標非常明確、簡化了的業務流程，通過重新安排傳統的項目為流程的更改提供靈活性。

系統集成商Infosys的副總裁Sohrab Kakalia說: “人們對SOA存在相當嚴重的誤解，而實際上不從整體上考慮IT和業務，誰也無法取得成功?！?

架構描述了提供業務流程的服務的標準層面，包括治理和策略、流程管理、業務邏輯本身、數據管理及訪問、內部定義、便于服務聯系的服務接口以及消息傳送框架——通常就按這順序加以處理。

英國電信公司已開發了14個服務平臺。該公司的Glass說: “每個平臺都有一套與業務操作相關的服務——就像是面向對象編程里面的方法。服務只位于一個平臺里面?！惫緸槊總€平臺派一名架構師來負責，他確保所有服 務都符合這個架構，無論服務是內部開發的、合作伙伴提供的還是向廠商購買的。為了確保始終符合，他們規定，如果英國電信的某個項目沒有符合架構，開發小組 的年度資金就會減少四分之一。

為了確保業務的靈活性和流程得到始終如一的執行，“架構應該不依賴任何實施的技術，新出現的技術可以部署，但架構本身具有可持續性，這就確保了SOA策略的一致性”， Glass說。

SOA高度關注底層的業務流程，反對依賴技術，因為這會限制公司以后更改或者添加業務流程的靈活性。除了架構方面的戰略性決策外，成功部署的SOA還依賴IT人員經常確認項目有哪些機會可以重復使用服務或者業務流程。

“這不是一蹴而就的工作?！盜ntuit公司的Moseley說，誰以為使用SOAP或者WSDL這些技術來提供一種功能或者集成應用就是在部署SOA，那可是大錯特錯。技術是實現目的的一段手段，而不是目的本身。

原文轉自：http://www.kjueaiud.com