為解決方案架構師打造的實用SOA

WSO2出的新白皮書《為解決方案架構師打造的實用SOA》將SOA定位成：

……一個常識性準則，不僅在今天，即便在信息時代出現伊始，都很有價值。

懷揣這一理念，白皮書試圖：

……提供一套使用SOA的實用的方法，而且是容易掌握，立即可用的方法。并且它對產商是中立的，因為它談的是通用概念和邏輯組件，它們幾乎出現在每個產商的產品線中。

白皮書將重點放在解決方案架構師最關心的兩個問題之上：

• 在技術層，解決方案架構師需要為問題找到正確的工具。
• 在數據層，他們需要知道如何降低或消除系統間的不必要的依賴關系。

就技術（工具）而言，白皮書指出，最常用的核心SOA技術組件有三個：

• 服務容器
• 服務代理
• 流程協同器

解決方案架構師需要使用以上組件將現有及未來的功能組件組織起來，從而創建新的端到端業務解決方案。如何使用它們，應該遵循以下規則：

• 服務容器是平臺，新實現的服務作為解決方案的一部分，托管在該平臺上。
• 服務代理是工具，它可將現有企業應用封裝成服務暴露出來。它提供現有功能的適配/轉換/仲裁等功能。
• 流程協同器用于實現業務流程，將服務的執行串接起來。

據白皮書，除以上三個組件之外，SOA實施中常用的其他組件有：規則引擎、數據訪問工具、注冊/存儲工具、管理和監控工具、治理工具、定制事件處理、展現支持等。

白皮書又進一步說明，僅僅選擇了正確的技術組件還不足以保證SOA的成功：

我們還應該保證，通過合適的SOA技術所獲得的成功不能被緊耦合的數據設計所抵消。

它還提出4條法則，以便實現低數據耦合的SOA設計。

• 找出隱性依賴，使之變成顯式的服務契約——這樣，簡單地確保持續符合服務契約，就能隱藏系統內的變化，從而保護系統的其他部分。
• 消除無用的系統間依賴——應該找出并消除(系統間)無意義的依賴關系。
• 保證領域數據和消息數據松耦合——二者之間使用數據映射，而不要使用數據生成或數據繼承。
• 標準化詞匯要在邏輯域中，而不要在整個組織中實施——把整個組織的詞匯標準化無異于“煮沸整個大海”。

白皮書還通過幾個銀行和保險業的示例來闡述上述概念的應用。

它的結尾說：

這些簡單但強力的概念是有效的SOA設計的關鍵，現在你的技能庫中已經有了這些概念工具……[它們]可幫助你下一個項目的落地。所以，你會本能地設計出符合SOA原則的解決方案。

盡管很難駁斥白皮書的結尾，以及其中所給出原則的重要性，但是它卻沒有給現有的SOA文獻帶來任何新東西。在技術層面上，它基本上說，服務的執行既可以從服務容器中從頭開發，也可以通過失配/轉換/仲裁等模式封裝遺留應用的方式得到，業務流程編排了這些服務。而這些技術解決方案是當代ESB的基礎。在數據層面上，“典范”企業數據模型是EAI在15年前就提出了，而且得到很多SOA實施的吸納。至于隱式和顯式的服務接口以及消除不必要的依賴，這些概念直接來自現有服務設計模式之中，即服務的松耦合以及將服務實現隱藏在良定義接口的背后。

話說回來，提醒一下這些SOA實施的原則任何時候都有意義的。

---

查看英文原文：Practical SOA for Solution Architects

來自： InfoQ