第 4 章：SOA 方法學

這是《SOA：原理方法實踐》的第 4 章。在第 3 章我們已經詳細闡述了作為一種新的方法，SOA使用哪些原理和方法去構建IT系統，并使得構建的IT系統更加靈活，更加和業務對齊。那么如何在實踐的層面上，在IT的生命周期中貫徹SOA的原理和思想，一步步構建出符合SOA設計原則的IT系統呢？這個問題的答案屬于SOA方法學的范疇。

廣義上講，SOA方法學貫穿于IT生命周期的各個階段和各個方面：IT系統項目的規劃，系統分析和設計，系統的實施，系統的部署和維護，以及整個過程中的監控和管理等。從實踐的角度說，已經出現如下SOA方法學。

（1）面向服務的分析和設計（SOAD）。以服務為中心，根據業務需求發現服務、描述服務，并設計服務的實現。

（2）面向服務的開發過程。結合現有開發過程，規劃以服務為中心的開發過程中的角色、職責、活動和工件。

（3）SOA的成熟度分析和遷移路線圖。以服務為中心，分析現有或目標系統的成熟度，并設計從現有成熟度遷移到目標成熟度的路線圖。

（4）SOA監管。設計組織和流程，確保SOA的設計原則在IT生命周期中得以貫徹，管理服務生命周期中的各種遷移的合理性等。

本章對SOA方法學的闡述主要集中在面向服務的分析和設計。首先介紹SOA方法學和主要的幾種方法學的區別和聯系，其次以IBM的SOMA（Service Oriented Modeling and Architecture，面向服務的建模與架構）為例，介紹SOA分析和設計中的主要內容和方法。

回頁首

4.1 SOA方法學和其他方法學的比較

與SOA的設計原則類似，SOA方法學并不是全新的方法學，它是現有方法學的繼承和發展。一方面，原有的方法學并不能解決由于服務概念的引入帶來的問題，如怎樣發現服務，怎樣定義服務；另一方面，服務是一個水平的概念，而不是一個垂直的概念，在服務分析和設計的過程中，需要處理服務和現有方法學產物的關系，如業務流程和服務，企業架構和SOA，服務和對象等。因此服務的分析和設計最主要的職責在于發現服務、定義服務和實現服務，并指導如何和其他方法學結合完成這些職責。

如圖4-1所示揭示了現有幾種方法學的定位。圖的橫坐標將項目周期分為分析、設計和開發三個階段，縱坐標將域分為應用、架構和業務。流程建模（BPM）用于業務領域的分析和設計，如業務流程的定義、業務數據的定義等；企業架構（EA）和方案架構（SA）側重在架構領域的分析和設計，如根據業務需求確定目前目標業務系統和IT系統，根據目標系統需求設計主要架構元素和它們之間的關系；面向對象的分析和設計（OOAD）則貫穿分析、設計和開發三個階段，它主要分析細粒度的業務需求，如用例，分析和設計實現這些需求的類和對象，以及它們之間的關系。

如圖4-2所示，面向服務的分析和設計貫穿項目周期的三個階段和IT系統的三個域。這暗示著，在操作層面上，面向服務的分析和設計會和其他方法學緊密相聯。

1．BPM和SOA

業務流程建模是一個相當零散的領域，存在各種各樣的方法和技術，有效的方法可以幫助企業對業務進行合理的劃分，從而求得業務層面的靈活性。有些方法則側重于流程建模本身，例如如何確定和定義業務流程中的業務活動、業務數據、業務規則、業務指標和業務事件等，但是BPM并不會幫助我們去發現和定義服務。從SOA的方法學來看，各種BPM的結果是面向服務的分析和設計的重要輸入，如業務組件、業務流程和業務目標是服務發現的重要依據，而業務指標、業務數據、業務規則等是服務暴露的分析的重要依據。

2．EA和SOA

盡管和BPM一樣，EA是一個零散的領域，但是當前的EA主要側重于定義跨越業務單元邊界的系統框架，企業范圍內系統的主要構成元素，這些元素間的關系，以及將這些元素有機組合在一起的參考架構。但是，各種EA技術都缺乏業務領域的藍圖指導企業架構的設計。從SOA方法學來看，一方面，面向服務的分析和設計通過和BPM結合將業務分解為各種類型的服務，可以作為企業業務的藍圖指導企業架構的設計；另一方面，企業架構設計的結果，如參考架構，又是服務實現的重要依據。

3．OOAD和SOA

面向對象的分析和設計告訴我們使用Use Case捕獲需求，并設計類、對象及對象間交互來滿足Use Case定義的需求。但是面向對象的分析和設計往往只是局限在單個應用內部，它不會缺乏業務藍圖和企業架構藍圖的指導。從SOA方法學看，在原理層面上，OOAD中的很多設計原則，如抽象、隔離關注等被SOA繼承和發揚，并應用于服務的定義和實現中。而在操作層面上，服務模型為OOAD進行類和對象設計提供了業務藍圖和企業架構藍圖，與此同時，Use Case作為對業務流程的補充說明被用于服務的發現和定義中。

回頁首

4.2 面向服務的分析和設計概述

本章以下小節將以IBM的SOMA為例，說明面向服務的分析和設計的主要任務和方法。 IBM的SOMA將面向服務的分析和設計分為服務發現、服務規約和服務實現。服務的實現包括服務、組件和服務組裝的實現。

為了開始面向服務的分析和設計，如下的輸入需要被用在分析和設計的過程中。

（1）業務領域（Business Domain）和業務功能域（Business Function Area）。業務領域和業務功能域的劃分勾勒了目標企業的業務結構，它一方面幫助我們從全局的角度來理解目標企業的業務，另一方面也是我們進行組織服務層次結構的重要依據。

（2）業務流程（Business Process）。業務流程，尤其是第一級的業務流程，對企業經營全局至關重要。通常，通過第一級的業務流程可以追溯到企業中最為重要的業務活動，因此第一級業務流程是我們進行服務分析和設計的主要入口點。

（3）業務目標（Business Goal）。組織和業務流程都是為業務目標服務的，為了完成業務目標，組織和業務流程都有可能進行適當的調整。分析業務目標在有些時候可以幫助我們發現一些通過業務流程分析遺漏的服務；與此同時，業務目標也是服務描述中一部分重要的內容。

（4）現有系統（Existing System）?，F有系統是目前業務活動和業務流程的寫照，通過分析現有系統模塊和功能，能夠幫助發現服務。與此同時，對于現有系統的分析和理解是進行服務實現設計的重要前提。

在掌握了業務領域劃分、業務流程、業務目標和現有系統后，SOMA按照三個階段來進行服務分析和設計--發現服務、描述服務和服務實現，如圖4-3所示。在SOMA三個階段的分析和設計過程中，分析和設計人員還需要借助于傳統方法中的一些素材，如業務環境和業務用例、IT環境、當前應用或組件的模型和設計等，從而完成與現有業務和IT緊密結合的服務規范和服務設計。在運用SOMA的過程中，這三個階段并不是一次性完成的，一般需要一個迭代的過程。另外，從企業范圍而言，分析和確定的服務模型也有一個演化的過程，并逐漸地精化，越來越貼近業務。

4.2.1 服務發現

服務發現是SOMA進行服務分析和設計的第一步。服務發現的主要任務，是確定在一定范圍內（通常是企業范圍，或若干關鍵業務流程范圍內）可能成為服務的候選者列表。

目前有三種方式發現服務的候選者，它們分別是自上而下的領域分解、自下而上的現有系統分析和中間對齊的業務目標建模。

1．自上而下（領域分解）方式

自上而下的領域分解方式從業務著手進行分析，選擇端到端的業務流程進行逐層分解至業務活動，并對其間涉及的業務活動和業務對象進行變化分析。

業務組件模型是業務領域分解的輸入之一。業務組件模型是一種業務咨詢和轉型的工具，它根據業務職責、職責間的關系等因素，將業務細分為業務領域、業務執行層次和業務組件。由于企業內部和外部環境的不同，每個業務組件在成本、投資、競爭力等方面不盡相同，因此，每個業務組件在企業發展的過程中戰略職責和演化的路徑也是不同的，于是由于角度的不同，就形成了所謂的業務組件的"熱點視圖"。SOA是一種特別強調業務和IT互動的技術。對于面向服務的分析和設計，業務組件模型提供了進行服務劃分的依據，而且這種劃分的方法可以平滑地從業務視圖細化到服務視圖。

端到端的業務流程是業務領域分解的另一個輸入。將業務流程分解成子流程或者業務活動，逐級進行，直到每個業務活動都是具備業務含義的最小單元。流程分解得到的業務活動樹上的每一個節點，都是服務的候選者，構成了服務候選者組合。業務領域分解可以幫助發現主要的服務候選者，加上自下而上和中間對齊方式發現的新服務候選者，最終會構成一個服務候選者列表。在SOA的方法中，服務是業務組件間的契約，因此將服務候選者劃分到業務組件，是服務分析中不可或缺的一步。服務候選者列表經過業務組件的劃分，會最終形成層次化的服務目錄。

變化分析的目的是將業務領域中易變的部分和穩定的部分區分開來，通過將易變的業務邏輯及相關的業務規則剝離出來，來保證未來的變化不會破壞現有設計，從而提升架構應對變化的能力。變化分析可能會從在未來需求的分析中發現一些新的服務候選者，這些服務候選者需要加入到服務候選者目錄中。

2．自下而上（已有資產分析）方式

自下而上的已有資產分析方式的目的是利用已有資產來實現服務，已有資產包括：已有系統、套裝或定制應用、行業規范或業務模型等。

通過對已有資產的業務功能、技術平臺、架構及實現方式的分析，除了能夠驗證服務候選者或者發現新的服務候選者，還能夠通過分析已有系統、套裝或定制應用的技術局限性，盡早驗證服務實現決策的可行性，為服務實現決策提供重要的依據。

3．中間對齊（業務目標建模）方式

中間對齊的業務目標建模方式的目的是幫助發現與業務對齊的服務，并確保關鍵的服務在流程分解和已有資產分析的過程中沒有被遺漏。

業務目標建模將業務目標分解成子目標，然后分析哪些服務是用來實現這些子目標的。在這個過程中，為了可以度量這些服務的執行情況并進而評估業務目標，我們會發現關鍵業務指標、度量值和相關的業務事件。

結合這三種方式的分析，我們發現服務候選者組合，并按照業務范圍劃分為服務目錄。同時為服務規約做好其他準備，如通過對已有資產分析進行的技術可行性評估，通過業務目標建模發現的業務事件等。

關于服務發現示例，請參見本書第13章"SOA體系結構的實例講解"。

4.2.2 服務規約

經過服務發現階段，服務目錄基本形成，但是對于每個服務本身的屬性信息依然零散。為了能夠將服務作為業務和IT層面互動的契約，服務規約階段是必不可少的。服務規約階段的主要任務是規范性地描述服務各個方面的屬性，其中既包括輸入/輸出消息等功能性屬性，服務安全約束和響應時間等服務質量約束，以及服務在業務層面的諸多屬性，如涉及的業務規則、業務事件、時間/人員消耗等。與此同時，規范描述服務相關方面的關系也很重要，如服務間依賴關系，服務和業務組件間關系，服務和IT組件間關系和服務消息間關系等。

進行服務暴露決策是服務規約的第一步。理論上所有的服務候選者都可以暴露為服務，但是一旦暴露為服務，該服務候選者就必須滿足附加的安全性、性能等方面的要求。企業還必須為服務的規劃、設計、開發、維護、監管支付額外的開支，因此，我們會根據一定的規則來決定將哪些服務候選者暴露為服務。

這些規則包含以下幾個方面：

• 業務對齊。該服務候選者可以支持相關的業務流程和業務目標。
• 可組裝。該服務候選者滿足技術中立、自包含及無狀態等特點，同時還滿足復合應用的相關非功能性需求。
• 可重用。該服務候選者可以在不同的應用、流程中重用，從而減少重復的功能實現，降低開發和維護的成本。

基于企業應用開發的經驗，我們還可以有其他一些方面的考慮。

經過服務暴露決策后，層次化的服務目錄基本形成。下一步是結合傳統的方法學對服務各方面屬性進行描述。這里說的傳統的方法學是指企業架構，面向對象的分析和設計等。在企業架構方法學的產物中，企業數據模型有助于服務消息的定義，IT組件模型有助于服務和IT組件間關系的描述，企業安全架構有助于服務安全約束規約，企業基礎設施架構有助于服務質量的描述。在面向對象分析和設計的產物中，業務用例和系統用例有助于服務消息、服務相關業務規則和業務事件等描述，組件靜態模型和動態模型有助于描述服務間關系。

經過服務規約，服務組件（企業組件）和服務的各個方面的屬性被規范下來，它會成為業務和IT層面互動的基礎。以后，業務對IT的新需求會體現為服務層面的變更，IT層面的變化會盡量遵循服務規約。在SOA監管的配合下，任何對服務規約的變更都是可管理和可控制的。

關于服務規約示例，請參見本書第13章"SOA體系結構的實例講解"。

4.2.3 服務實現

經過服務規約階段，作為業務和IT互動的服務契約已經形成。但是服務契約和IT的現狀還是有很大差距的，如和某個服務對應的業務邏輯分散于不同的應用中，分散在不同的地域，某些服務目前主要依靠人工完成，還沒有IT層面的實現。

為了將服務契約落在實地，服務實現階段通過差距分析，并結合傳統方法學完成每個服務實現決策。這其中包括的內容甚多，其主要內容如下。

（1）現有系統分析：調研現有系統架構，了解架構風格、主要架構元素和能力和架構元素的基本特征；調研現有應用，了解應用主要功能和對外接口，技術實現特征等；如果應用構建已經遵循基于組件開發規范，編制應用已有組件目錄；如果應用并沒有組件化，將應用覆蓋的業務功能和服務規約確定的企業組件進行映射，確定應用現有"組件"目錄。

（2）確定服務分配：通過服務組件和現有系統分析確定的IT組件間差距分析，確定服務組件和IT組件間映射關系。例如，一個服務組件對應一個或多個IT組件，沒有IT組件和服務組件對應，沒有服務組件和IT組件對應，服務組件和IT組件對應時有能力缺失或不匹配等。經過差距分析，一些服務中介被確定下來去實現服務路由，或消息格式等不匹配現象，一些新的IT組件被確定下來，如實現某業務流程的組件或實現人工服務的組件等。最終，服務組件都被映射到IT組件上，從而完成服務分配。

（3）服務實現決策：服務分配僅僅確定了需要哪些組件來實現服務，但是并沒有實現的策略和技術層面的決策。服務實現決策首先幫助確定服務實現策略，是在現有基礎上進行服務包裝，還是重新構建，如果重新構建，是采用已經包裝好的應用，還是外包，或者自己構建；如果是服務包裝的話，有哪些候選方案等。通常服務實現決策和傳統的架構決策是關聯在一起的。

（4）服務基礎設施設計：服務的功能實現，非功能需求的滿足都需要服務基礎設施的支持。在進行服務實現決策后，需要根據具體的需求確定服務基礎設施的能力，如用于支撐人工服務的人工服務容器，用于支撐服務編排的流程引擎等。

將服務實現階段的各種產物和傳統設計方法結合起來，就可以開始指導實際服務實現的實施。