解析如何避免在SOA采用過程中的常見失誤(1)

引言

IT 體系結構已非常成熟，它是一種成功處理典型 IT 問題的方法。體系結構中一個受到很大重視的相對較新的分支是面向服務的體系結構 (SOA)。SOA 經常被吹捧為企業用于解決應用程序靈活性和高維護成本問題的萬能藥，常常被視為幫助企業提高其 IT 投資回報(Return On Investment，ROI)的方法。SOA 是用于進行 IT 系統設計以確保業務目標與 IT 一致的主要體系結構樣式，允許構建具有彈性的 IT 系統來滿足新的和不斷變化的業務需求。

SOA 的優點(如提高靈活性、互操作性以及降低維護成本)得到了廣泛的宣傳，且經受住了時間的考驗。這個成功記錄讓越來越多的企業開始跟著采用 SOA，努力想獲得這些好處。企業宣布啟用 SOA 將導致 SOA 活動的增加，如對遺留應用程序進行轉換和現代化工作，從而實現以服務為中心，并遵循 SOA 的原則和最佳實踐。但 SOA 倡導者和采用者在應用 SOA 時需要保持警惕，因為采用 SOA 的過程并不總是一帆風順或完全不出問題。 在本文中，您將了解各種常見問題，如果架構師和開發團隊在未進行全面而細致的前期工作的情況下貿然嘗試采用 SOA就可能遇到這些問題。

正如模式是獲得反復成功的明確選擇，反模式會帶來很容易導致失敗的失誤。在開發人員和架構師嘗試全面了解 SOA 最佳實踐時，同樣要重視 SOA 采用過程中的常見失誤。

最常見的失誤包括：

• 注意供應商專有服務產品。不要局限于實際上具有專有特征的 SOA 供應商產品;這可能會導致失去真正 SOA 的互操作性和靈活性好處。
• 尋求使用開放標準的穩定性。行業中的最新開放標準規范并不一定是最穩定的;因此，可能并不成熟，不適合采用。
• 仔細評估遺留資產現代化工作。選擇特定遺留系統進行現代化工作時，請從企業的全局出發進行考慮。SOA 過渡中的豎井 (Silo) 方法可能導致出現冗余。
• 避免“瀑布”式開發和缺少服務版本控制的情況。SOA 過渡本質上應該具有迭代的特征。服務生命周期管理應該具有維護服務的多個版本的功能。
• 了解遺留系統的技術限制。在進行遺留資產現代化工作前，請充分考慮遺留系統的所有技術限制。
• 不要將 SOA 等同于 Web 服務。了解 SOA(一種體系結構樣式)和 Web 服務(一組 SOA 實現標準)間的差異。
• 避免采用豎井方法處理服務創建和所有關系。理解傳統應用程序開發和基于 SOA 的開發之間的范式轉換。
• 避免使用細粒度服務。與細粒度應用程序編程接口(Application Program Interfaces，API)相比，服務是更高級的抽象。服務應該為粗粒度的，且與業務一致。
• 避免點到點調用。使 SOA 生態系統具有可管理性，且組件間采用松散耦合方式。加入中介層，以處理服務發現和調用，并協調不同 SOA 實現間的基礎技術差異。
• 避免不遵循標準的情況。采用穩定的、經過驗證的行業特定標準。此方法將為您的 SOA 帶來互操作性的好處。
• 使用冗余數據存儲。將重點放在數據整合策略上。通過創建虛擬數據服務來提供數據冗余性。
• 避免使用“大爆炸”方法。對于復雜 SOA 過渡，請完全避免使用“大爆炸”方法。請充分認識到，最好的平穩 SOA 過渡是通過采用迭代方法實現的，并尊重這一事實。
• 分配服務所有關系。不要讓服務孤立。為其提供一個環境，讓某個業務部門作為其所有者。此所有關系使得有人負責維護非功能性服務質量。
• 進行 SOA 治理。授權治理組織管理整個服務生命周期。

供應商專有服務產品

SOA 的基本原則之一是，它能跨各種異類功能和基礎設施環境提供服務互操作性。盡管 SOA 產品供應商正在進行大量的開發工作，以提供功能和基礎設施服務組件，但這些產品經常會采用其提供的服務的專有形式。購買這些產品并將這些產品作為其 SOA 的基礎的企業可能很快就發現自己被限制在了供應商服務組件的專有特性內。

SOA 是基于業務需求定義的，具有突出的互操作性和靈活的服務即插即用功能。絕不應該使用其服務并不基于穩定的開放標準的專有供應商產品來損害這種靈活性。請注意，除非供應商的 SOA 產品符合制定得非常完善的開放標準，以此作為其提供的服務實現的基礎，否則，在使用這些產品時就應該格外小心。為了實現基于 SOA 的過渡的長期成功，必須為其實現支持、采用和實施開放標準。

開放標準的穩定性

那么，為了真正獲得服務間互操作性的好處，您的 SOA 實現必須遵循被廣泛接受的現有開放標準(例如 WS-* 規范)，而不管是對服務從頭開發、重用還是從供應商購買。

任何基于 SOA 的開發工作都必須仔細地分析已確定要遵循和采用的開放標準集。如果確定的開放標準僅處于設計或規范級別，而更為成熟穩定的版本尚未發布和廣泛采用，則 SOA 可能會遭遇傳統的維護困境。隨著每個標準規范的新版本的發布，業務應用程序還將需要進行恰當的更改，以與標準保持一致。如果標準沒有得到廣泛接受，或僅由一個供應商提出且尚未得到行業內大幅度的認可，同樣的問題可能會變得更為關鍵。

不過，市場上被看好的最新開放標準并不一定是可采用的最佳標準。它仍然要經歷自己逐漸成熟并被主流供應商采用的過程。至少，它必須具有定義良好的路線圖，以過渡到穩定成熟的版本。

遺留資產現代化

遺留資產現代化是企業采用 SOA 時的一個重要方面。任何過去數十年使用 IT 系統的企業都一定具有幫助其開展業務的遺留應用程序。遺留系統可以存在于基礎設施級別，也可以存在于操作級別;例如，運行企業人力資源(Human Resource，HR)系統的 IBM CICS® 大型機。遺留系統還可能以特定基礎設施組件和操作環境上運行的過時軟件或編寫質量較差的軟件應用程序的形式存在。

當企業采取行動對其 IT 基礎設施進行現代化工作并使其與業務要求保持一致時，IT 團隊需在為過渡到基于 SOA 的投資組合構建業務用例前對現有的遺留系統進行更為深入的分析。此類分析經常采用豎井方式執行，而這意味著將選取特定的獨立業務域進行臨時性的遺留資產現代化工作。

如果在沒有全面考慮整個企業的情況下或在沒有考慮依賴關系和相關業務域或能力的情況下進行遺留資產現代化工作，則可能創建重復的服務和應用程序編程接口(Application Program Interface，API)。這種重復的情況源自缺乏對現有服務投資組合的詳細分析。必須使用 80-20 原則對現有服務進行仔細分析：如果可滿足當前現代化要求至少 80% 的所需功能的現有服務僅需要 20% 的工作就能完全從頭構建，則最好通過以現有服務為基礎實現新要求。

如果企業 IT 組織的操作方法是通過采用豎井 SOA 遺留資產現代化工作進行的，則能從 SOA 得到的潛在好處可能就會大打折扣。即，如果在沒有評估整個系統的情況下進行自動化工作，很可能無法得到真正的 SOA。在這些業務模型類型中，SOA 并不是適合采用的好方法。盡管進行了相關的工作，但 SOA 的業務價值將很難得到業務涉眾的認可。

“瀑布”式開發和缺少服務版本控制

采用瀑布式方法可能是在進行 SOA 工作的過程中的常見問題之一。瀑布方法應用于傳統應用程序開發時，就意味著存在嚴格的開發序列(如解決方案概要、宏觀設計、微觀設計)，要依次進行開發、編碼和單元測試(Develop, Code, and Unit Test，DCUT)。對 SOA 采用這種方法可能導致創建僅能部署一次的服務，而無法在以后對其進行重用。

SOA 不能一蹴而就。企業應該以迭代的方式過渡到 SOA，要進行階段劃分，并創建計劃良好的轉換路線圖。路線圖確定最活躍的業務領域，SOA 采用工作可以在其中對業務和 IT 的需求進行結合。此過渡可以在業務域級別上進行;經過標識并隨后采用類似方式開發的服務可從迭代開發獲益。

根據迭代方法的要求，服務必須具有定義良好的生命周期，如圖 1 中所示。

圖 1. SOA 中服務的生命周期

此生命周期的一部分涉及到對您開發的每個服務進行版本控制。有版本控制的服務可確保該服務的升級并不需要重新測試應用程序使用的所有其他服務。服務版本控制能為服務的不同使用者提供服務水平協議(Service-Level Agreement，SLA)的不同級別支持，另外還具有其他很多好處。服務版本控制還允許對服務進行迭代開發，并能基于業務功能需求進行持續的改進和增強。

對于大型的面向服務的企業，服務版本控制應該成為服務管理生命周期不可或缺的一部分。因此，企業的 IT 環境的操作功能要具有可靠的 SOA 管理基礎設施這一點非常重要。如果不能滿足此要求，則會對面向服務的企業的增長造成嚴重的限制。

服務版本控制也屬于 SOA 治理的討論范疇之內，我們稍后將對 SOA 治理進行討論。不過，對于剛剛開始進行 SOA 開發的人員而言，常常會忽略對版本控制加以考慮，因此我們將這個問題在此單獨列出。