SOA進階班(1)透過生命周期管理，理解SOA的實作流程

服務導向架構（SOA）是一種架構方法，它仰賴將業務流程和底層活動分解為標準化的服務。這些服務可能或細或粗，甚至以表現層為中心、以資料為中心或許多其他變換方式。不論服務的類型有多少種，有效管理服務的生命周期是SOA專案成功的基礎。

共用服務生命周期
認識SOA帶來的典範轉移，是理解服務生命周期（Service Lifecycle）管理需求的重要關鍵。許多設計人員和分析人員指出，SOA要求業務和IT更緊密地結合，是企業營運的重大轉變。

我們使用共用服務生命周期（Shared Service Lifecycle，SSLC）描述與SOA服務相關的生命周期。「共用」可彰顯服務生命周期管理直接受到它與企業中其他服務的關係影響。以描述典型的往覆式（Iterative） SSLC來說，它包括設計階段和執行階段。

雖然敏捷開發方法學試圖在整個建構過程中取代需求定義，但規則及處理行為可能仍然嵌入在應用程式中。服務生命周期並不會直接解決這一問題，但是SOA中的服務組合，則提供一種對邏輯進行去藕的方法。

由於傳統應用程式中的緊密藕合，以及需在交付項目（Deliverable）中組合眾多功能，執行階段（Run-Time）治理通常相當困難。因此傳統與安全、服務品質等相關的許多決策，乃在設計過程，而不是運行中完成，從而大幅減少了應用程式的靈活性，但靈活性正是滿足不斷變化的業務需求不可或缺的。

SOA的第1步：確定業務流程
許多企業發覺很難理解從何處開始著手建置SOA，以及哪些是最合適的業務流程。一個好方法是在白板上定義需求。將白板畫分為3條路線，分別代表短期需求（3到6個月──通常本質上更有戰術性），中期需求（6到18個月）和長期需求（超過18個月──通常為戰略需求，可能隨業務需求變化而變化）。

SOA的第2步：選擇初始服務
完成初步分析之後，服務工程團隊可能開始尋找相依性，決定優先順序、找出重覆使用的可能性，或確定需求間的相依性。

無論如何，初始服務的選擇，應考量開發團隊的能力。新的團隊需要時間累積SSLC設計階段的經驗。在服務中確定的相依服務可能具有較高的重覆使用性，而且看似一個好的服務，但其實不適合於能力尚未成熟的團隊。若服務已涉及到跨業務部門、提供企業級功能或遵守嚴格的服務品質規章，則可能就不是一個理想的初始候選服務。

另一方面，對一個服務定義清楚、或具有已知端點的流程，如果這些端點又是受管、成熟的，並且範圍很小，服務本身又發展到分散式建構或重構，那麼在很短的時間內，這種服務就是初始開發的最佳選擇。

這樣的初始服務應該可以很快驗證假設、方法學和流程。正確的設計需要經驗、實踐、反覆試驗並糾正錯誤，尤其在SOA計畫的成型階段。透過此一方法可判斷企業內有哪些SOA實踐可以發揮作用。早期如果選擇的是沒有相依性的孤立服務，則可能會妨礙服務工程團隊，使得他們在成型階段無法獲得更多的學習機會。

SOA的第3步：服務的設計和建模
服務設計和建模階段的目標，是依據確定的業務流程，建立定義候選服務的一致方法。等到真正開始做時，服務工程團隊通常用白板描繪業務流程、分解步驟以及討論當前和未來的需求。因此，應該使用業務和IT均可理解的常用語言，建立一致的設計方法學。

服務設計方法學為開發團隊提供了一系列分解業務流程的步驟或方法，許多企業最初對於此類設計方法有一些爭議，尤其是服務粒度（Granularity）。粒度過細的話，無法重覆使用的服務可能越來越多，但過粗又很難著手。

服務生命周期最終的目的是解決業務需求，而SSLC評估階段是根據實際應用和環境再評估分類方式。在某一時間點上定義為某一使用層級的內容，實際上使用方式可能完全不同。

在流程階段，我們主要談論候選服務與服務實現的概念。候選服務是潛在的服務，這些服務可能在最後設計中實現，也有可能不實現。設計流程是為了找出設計和開發未來階段可做的新增或修改工作。了解企業中已存在的服務，及需要新開發的服務。支援服務發現的工具（如相容UDDI的註冊庫）是促進服務重覆使用和了解現有可用資源的重要元件。

SOA第4步：服務的建構和組合
建構和組合重點在開發新服務，以及利用現有資源更快速、更經濟地開發新功能，以縮短上線時間，也是SOA中最關鍵的效益之一。

在這個階段，服務建模和設計階段確定的候選服務被具體化成服務實作，並與基礎架構和實體環境對映。由於當前環境的限制，實現這些目標可能比較困難，但可能會促進某些良性討論以及成本利潤分析，從而確定如何實現期望的未來狀態。但是，現有業務需要繼續發展，所以候選服務在企業環境中必須具有實用效益。

理解了哪些服務及實作比較實用之後，就可以著眼於再利用的可能性，以及在上一階段確定的組合。要充分發揮SOA效益，組合的概念對業務敏捷性來說非常重要。開發環境和服務基礎架構工具，必須在推動設計時發現服務，並組合這些服務以便完成整個業務流程。

通常，服務起源於營運層級而非業務計畫，因為一般情況下這是專案資金和需求來源所在。結果，最初設計時發現的服務，可能不是良好的再利用候選服務，例如會有效能或一致性不足的情況。儘管它們可用於企業中，但仍為應用程式層級的服務。最後，企業必須開始建立管理流程方法，以控制服務的透明度。通常服務註冊機關（Service Registry）提供確保服務品質的管理機制和流程。上述許多方面都必須在服務生命周期的發布和籌備階段即考慮到。

SOA的第5步：快速開發
經驗指出，工具標準化可使企業充分利用現有知識並在整個SOA計畫中重覆使用。這不是說每個人都必須使用相同的IDE或某個特定工具，而是指使用的任何工具的使用都必須支援標準。

若開發人員需要使用不同的工具支援其他專案，則必須降低學習的難度。此外，工具必須能夠測量服務的重覆使用性和控制上市時程。如果能測量服務生命周期，即可以為企業提供相當豐富的價值資訊，確保SOA的成功。

《作者簡介》黃開印
BEA台灣分公司首席技術顧問，於BEA台灣負責技術顧問及大型專案支援與建議，在IT相關技術方面有9年以上的經驗。專長於J2EE系統設計、分析與開發，Unix/Linux系統、HTML、物件導向分析及設計、Java、資料庫管理系統、RFID等不同的技術領域。