隨筆檔案

分析和設計

SOA 分析和設計也可以指以下術語中的一個或多個：

服務建模
面向服務的分析和設計
面向服務的建模和體系結構 (SOMA)
Rational Unified Process for Service-Oriented Modeling and Architecture (RUP SOMA)

分析會在較高的（概念級）抽象級別上對將要構建的系統進行描述。分析的輸入是一組需求和現有的資產

（或是應用程序或系統）。輸出則是對需要構建的各個方面的描述。分析對 SOA 來說是至關重要的，因

為通過分析，可以在服務標識期間使 IT 與業務保持一致。分析結果將作為輸入在設計中使用。

大多數體系結構（在第 1 部分中有述）工作是在分析和設計的工作流中、在項目的細化階段執行的。
面向服務的分析和設計利用了分析和設計原則（如面向對象的開發或基于組件的開發中的原則）。例如，

您也許還記得所謂的面向對象的分析和設計 (OOAD)。不過，必須注意的是，SOA 的工作重點始終在于服

務（而不是對象或組件）。

服務標識

服務標識 是核心的面向服務的分析活動。服務標識的目的是將各個分組的概念化服務及其操作標識出來

。

自頂向下方法

業務體系結構工作從一組業務目標開始，標識出一個或多個應予關注的業務流程，這在 SOA 中是非常典

型的。通過業務建模工作，可能會出現已經過設計的業務流程（即未來的流程），對于正在設計中的系統

，它們可以被視為功能性的需求。

自頂向下方法旨在分解業務元素（主要是業務流程和用例），然后將它們細化為適合服務的粒度。在使用

自頂向下方法的過程中，您通常要在業務任務中標識出各種服務操作。這種做法的好處在于，您可以確保

標識的服務與業務保持一致。

自底向上方法

自底向上方法旨在分析現有的 IT 資產（如遺留的應用程序和系統），找出可以作為服務公開的功能，以

便重用它們。

重用是 SOA 的一個重要組成部分，對于 SOA 的成功是極為關鍵的。您可能知道，遺留應用程序（即已經

部署的應用程序）是您的公司最寶貴的資產，應該加以利用。例如，自底向上方法將分析現有的信息管理

系統 (IMS) 事務或 COBOL 程序。

對于自底向上的分析，有一句忠告：您必須謹慎從事，不要盲目地公開現有的 IT 功能。例如，用于創建

、讀取、更新、刪除 (CRUD) 數據的各項服務的粒度可能太小，無法與業務保持一致。

此外還要注意，您應使用現有的資產分析工具（如 IBM WebSphere Studio Asset Analyzer），這一點至

關重要，因為準確的部署和運行情況常常是無人知曉的。

中間相遇方法

中間相遇方法在需求（由自頂向下的分析標識出來的服務）和現有的 IT 資產提供的功能之間進行協調。

中間相遇方法需要業務分析師、軟件架構師和遺留應用程序專家彼此協作。注意，雖然在特定項目的上下

文環境之外進行的自底向上分析也是有價值的（例如，某個企業體系結構團隊對候選服務進行編目），但

事實上，作為項目的一部分，在工作開始時通常會采用自頂向下方法，對一個或多個業務流程進行分解。

此后，會在這個上下文環境中進行自底向上的分析，試著為所需的服務找到與之匹配的項（中間相遇方法

）。

通過上述三種方法，可對服務集及其操作進行標識和驗證（例如，通過驗證，可以確保服務先前并不存在

，或服務與業務保持一致），并對它們分組，歸入各個邏輯類別（如業務組件或業務功能區域）。另外還

要標識業務項（如策略或索賠），這些業務項主要來自現有的數據遺留應用程序。下一個步驟是完整地指

定這些服務及其操作，定義它們的結構和行為。

 

 

服務實現

服務實現旨在對如何實現服務進行設計。這一設計已經達到最為詳細的程度（僅次于代碼級）。它的目的

并不是實現（構造）服務，而是在設計級描述如何實現服務，至于實現（構造）服務，將在第 3 部分予

以介紹。服務實現是由軟件架構師和設計師來完成的。

在規范和實現之間有一道明顯的鴻溝。您可以用一個簡單的方法看出它們的區別：如果說服務規范解決的

是是什么的問題，服務實現介紹的就是怎樣做。

設計模型

由 RUP SOMA 定義的設計模型，是服務實現的核心輸出工作產品。它描述了 SOA 的實現，是對實現（包

括代碼）的抽象。服務實現的輸出將被輸入到服務的正式實現之中。

服務組件

您應當關注的主要設計模型組件是設計組件，它表示的是一個或多個服務規范是如何實現的，還描述了如

何處理所有的功能性/非功能性需求，以及結構和行為規范。

在服務實現期間會創建大量的新類，對服務組件和服務進行細化。此外還會定義這些類的結構和行為。

正如先前所說的那樣，服務實現應當大量使用設計模式（如委托模式、獨立模式和工廠模式），這些模式

一般是在服務實現期間被應用到各個類的。

 

服務設計原則

這一部分將列出您在設計 SOA 解決方案時必須牢記的四項服務設計原則。不過請注意，這并不是一份官

方的正式列表，而且也并不全面，其中一些概念來自于其他范例，如面向對象。這些原則在面向服務的解

決方案設計中是十分重要的。

重用

在設計服務時，請把重用這一原則隨時記在心中。通常，在設計時，特定的服務使用者會有特定的要求。

不過，如果您想從 SOA 中獲益，您會希望那些需求略有不同的其他使用者會重用自己設計的服務。而在

您創建設計時，并不知道這些使用者，也不知道它們有什么需求，因此這并不是一項輕松的任務。

下面是您可以考慮的事項：

根據業務域（而不是技術）為服務及其操作提供一個有意義的描述性名稱。
提供完整的、可由人工閱讀或計算機處理的規范，并將其公布給服務注冊中心，使服務可以被發現（詳細

信息，請參閱本系列后續的部分）。
各個使用場景的服務質量與初始場景不同，例如，如果服務被頻繁使用，需求和工作負載提高，可以制訂

相應的計劃。
是否有可能對服務提供的初始功能（是根據初始需求集提供的）進行擴展，以便完善服務。
是否有可能在多種不同的平臺上實現某個服務規范。
松散耦合

耦合是指實體或系統彼此間的依存程度。在 SOA 的上下文中，您可以考慮服務規范與它的提供者或實現

之間的耦合，或服務提供者與服務使用者間的耦合。如要支持 SOA 應有的靈活性，必須采用松散耦合。

服務提供者無需了解服務使用者的某個特定實例，反之亦然。如果要替換某個服務提供者或服務的實現，

必須保證這樣做對使用者造成的影響可忽略不計，或不會對其造成干擾。

如果要幫助實現松散耦合，請考慮下列事項：

將服務規范（本文中所述的服務和模型）與服務實現分離開來。正如第 2 部分有關 MDD 的那一節所描述

的那樣，對于服務而言，擁有完整的規范是十分重要的，規范不會依賴于某個特定的實現。而且，服務契

約應處于規范級別（而非實現級別）。
使用工具，以一種人機可讀的標準格式（如 WSDL 和 WS-Policy）描述服務規范，以使代碼生成器能幫助

您實現服務（ 本系列的第 4 部分將提供這一方面的詳細信息）。
當開發服務使用者的代碼時，請記住，可能存在服務中間層或其他提供者，請不要對某個提供者的實例的

任何信息進行硬編碼。

無狀態性

事務狀態意味著服務必須具有關于某些發生的事件的信息，這些事件是一個在服務提供者和服務使用者各

自的特定實例間長期運行的事務的一部分。例如，如果服務操作已被調用，或在調用某個操作前需要先調

用另一個操作，在這兩種情況下調用服務操作的結果是不同的。雖然在基于組件的開發中可以找到事務狀

態的身影，但對于 SOA 來說，事務狀態卻是應該避免的。

數據（信息）狀態意味著需要對數據實例的狀態進行管理。某些服務通常需要管理數據的狀態。以保險業

中的索賠服務為例。該服務必須管理索賠實例的狀態，因為多個用戶會通過不同的業務事務訪問這些實例

。注意，保持狀態不變的服務通常是原子（細粒度服務）。如要處理狀態需求，您應依靠一些在實現中運

用的基礎技術，如 Java™ 平臺、使用狀態會話 Bean 的 Enterprise Edition (Java EE) 等等。

粒度

對于面向服務的設計，您可以對粒度進行考慮，如服務提供者級或服務規范級的粒度（對于前者而言，要

考慮應提供多少服務）。服務規范是一個針對服務操作的邏輯分組。在此處，邏輯表示它在業務方面的合

理性。例如，在保險領域中，一個索賠處理接口將提供使用索賠處理的場景中所需的所有操作。這在 IT

實現方面也是合理的。例如，服務中所有被標識出的操作都可以通過同一種開發迭代實現。

在設計服務操作時，請考慮協作、使用場景，以及在服務提供者和使用者之間流動的消息的數目和大小。

粗粒度的操作可以提供更高的業務價值，而且使對實現的修改變得更容易了。粗粒度操作的參數（使用消

息作為輸入、輸出和故障參數）出錯率較低。不過，使用細粒度的參數（而不是消息）通常具有更好的描

述性。例如，如果某個操作服務簽名為 determineEligibility(application: ApplicationMessage)，則

您需要查看 ApplicationMessage 的定義。如果簽名為 determineEligibility(customer : Customer,

product : Product, date : Date, amount : Amount)，則該簽名的描述性更好。此外，Customer 或

Product 參數類型（舉例來說）可以在其他操作中重用，這與 ApplicationMessage 不同。

對于服務粒度，請務必記住，服務是可組合的。這涉及到重用和在現有功能基礎上提供新功能的能力。某

一粒度級別的一組服務可以通過編排，形成另一個具有較粗粒度的服務。您可以想想這個例子：多個服務

提供各種業務任務，然后將這些業務任務排成序列（一個業務流程），以提供另一個服務。

最終，如果要在設計決策中確定服務粒度，應當在性能（如在高效實現的前提下，用于交換的消息的大小

和數目）和重用的可能之間作出折衷。而且，一個典型的 SOA 會同時包括細粒度（原子服務）和粗粒度

（組合服務）兩種服務。