面向服務的分析與設計原理(1)

最初的面向服務的體系結構（Service-Oriented Architecture，SOA） 的實現項目的經驗表明，諸如面向對象的分析與設計（Object-Oriented Analysis and Design，OOAD）、企業體系結構（Enterprise Architecture，EA）框架和業務流程建模（Business Process Modeling，BPM）這樣的現有開發流程和表示法僅僅涵蓋了支持目前出現在 SOA 中的體系結構模式所需的部分要求。

在 Info World 最近的訪談（請參見參考資料）中，Grady Booch 宣稱“像對問題的良好抽象和良好的分離這樣的工程基礎決不會過時”，不過，他也指出“還是有現實的機會提升抽象的級別。過去的經驗表明，必須將抽象的級別提升到公司處理的業務領域，從而將整個企業 IT 前景都納入考慮的范疇。

正如 Mark Colan 在文章“面向服務的體系結構擴展 Web 服務的前景，第 1 部分”中介紹的，SOA 是一種新興的企業結構形式，可以用于設計下一代企業應用程序。SOA 方法在有力地加強已經制定的良好通用軟件體系結構原則（如信息隱藏、模塊化和問題分離）的同時，還增添了一些其他的主題，例如服務編排、服務庫和服務總線中間件模式。

需要結構化方法或分析與設計方法來設計高質量的 SOA。因為現有的方法中沒有一種能夠滿足程序設計人員對最新的 SOA 項目的要求，所以他們建議將已經形成的良好實踐（如 OOAD、EA 和 BPM）中的原理組合起來，并且使用根據需要創新的原理來對其加以補充。

引言

面向服務的體系結構（SOA）和 Web 服務的基本觀念是成為我們日常語言的一部分，并可看作是適于設計現代企業應用程序的體系結構形式。在這種背景下，什么構成好的服務這個基本問題就成為確保成功實現 SOA 的關鍵。

像面向對象的分析與設計（Object-Oriented Analysis and Design，OOAD）、企業體系結構（Enterprise Architecture，EA）框架和業務流程建模（Business Process Modeling，BPM）這樣的現有建模規則為我們提供了高質量的實踐，可以長期幫助標識和定義體系結構內的適當抽象。然而經驗表明，這些實踐各自單獨應用時達不到要求。

在本文中，我們將研究 OOAD、EA 和 BPM 中的適當原理。我們還將推動對混合方法的需求，這種方法把所有這些規則中的原理與許多獨特的新原理組合起來。這樣得到的交叉學科 OOAD 方法使成功地進行 SOA 開發更容易，我們稱之為面向服務的分析與設計（Service-Oriented Analysis and Design，SOAD），它還有待正式定義。我們還只是剛剛跨入 SOAD 的殿堂。

面向服務的概念

在發現新的商機或威脅的預期下，SOA 體系結構形式旨在提供企業業務解決方案，這些業務解決方案可以按需擴展或改變。SOA 解決方案由可重用的服務組成，帶有定義良好且符合標準的已發布接口。SOA 提供了一種機制，通過這種機制，可以集成現有的遺留應用程序，而不管它們的平臺或語言。

從概念上講，SOA 中有三個主要的抽象級別：

• 操作：代表單個邏輯工作單元（LUW）的事務。執行操作通常會導致讀、寫或修改一個或多個持久性數據。SOA 操作可以直接與面向對象 (OO) 的方法相比。它們都有特定的結構化接口，并且返回結構化的響應。完全同方法一樣，特定操作的執行可能涉及調用附加的操作。
• 服務：代表操作的邏輯分組。例如，如果我們將 CustomerProfiling 視為服務，則按照電話號碼查找客戶、按照名稱和郵政編碼列出顧客和保存新客戶的數據就代表相關的操作。
• 業務流程：為實現特定業務目標而執行的一組長期運行的動作或活動。業務流程通常包括多個業務調用。業務流程的例子有：接納新員工、出售產品或服務和完成訂單。

  在 SOA 術語中，業務流程包括依據一組業務規則按照有序序列執行的一系列操作。操作的排序、選擇和執行稱為服務或流程編排。典型的情況是調用已編排服務來響應業務事件。

從建模的觀點來看，由此帶來的挑戰是如何描述設計良好的操作、服務和流程抽象的特征以及如何系統地構造它們。這些相關問題都是當前行業內和學術界最常討論的問題。據我們所知，最近幾乎所有的 SOA 項目或專題研討會都將這樣的服務建模方面作為重要的主題，并引起了許多的爭論。因此，讓我們更近地作一番審視。

為什么 BPM、EA 和 OOAD 還不夠？

早期的 SOA 實現項目經驗表明，諸如 OOAD、EA 和 BPM 這樣的現有開發流程和表示法僅僅涵蓋支持 SOA 范式所需的部分要求。SOA 方法在加強已經制定的良好通用軟件體系結構原則（如信息隱藏、模塊化和問題分離）的同時，還增添了附加的主題，例如，服務編排、服務庫和服務總線中間件模式，在建模時需要對它們給予特別的關注。

現有的 EA、BPM 和 OOAD 建模方法的主要應用領域，也是我們隨后討論 SOAD 的出發點。圖中的水平軸表示項目生命周期階段；垂直軸表示不同抽象層或領域之間的區別，而建?；顒油ǔ＞褪窃谄渖线M行的。

SOA 的遠景是相當容易理解的，因為它的技術基礎眾所周知。例如，在任何 SOA 工作中，應用通用的軟件體系結構原則和 OO 技術都是一個有效的開端。然而，正如我們已經提到的，早期采用者最常詢問的問題是如何標識正確的服務。如前所述，OOAD、EA 和 BPM 在各自獨立地應用時不能提供滿意的答案，而這正是我們現在要說明的。

在由 Booch 和 Jacobson 撰寫的開創性的書（大約 10 年前出版的）中介紹的 OOAD 方法在定義 SOA 方面提供了非常好的起點。同樣地，雖然許多年來在體系結構層次中應用 OOAD 技術和統一建模語言（Unified Modeling Language，UML）表示法是一個常見的實踐，但是 OOAD 還是與像類和單獨的對象實例這樣的微觀層次的抽象有關。由于每個問題域常常都創建單獨的用況模型，因此，應用程序開發項目，這個企業的大方向在許多情況下變得模糊。此外，由于種種原因，用況模型并不總是與其對等的 BPM 保持同步。

諸如 Treasury 企業體系結構框架（Treasury Enterprise Architecture Framework，TEAF）、面向特征的領域分析（Feature-Oriented Domain Analysis，FODA）和 Zachman 這樣的 EA 方法都將城市規劃級的觀點加在解決方案體系結構之上，但是并沒有解決如何找到易于重用且具有持久性的高質量企業抽象的問題。

雖然 BPM 方法（如 BPMI）在功能工作單元之上提供了端到端視圖，但是它們通常都沒有觸及體系結構和實現領域。例如，在像用于 Web 服務的業務流程執行語言（Business Process Execution Language for Web Services，BPEL）這樣的語言出現之前，BPM 表示法缺少操作語義。此外，我們還看到了許多流程建模與開發活動彼此分離的情況。

最后，現有的規則中沒有一個可以解決如何為 SOA 啟用現有的應用程序的問題；大部分時間都采用自頂向下流程?，F有的系統通常都存放有大量的重要數據和業務邏輯，并且不能簡單地加以替代。因此，為了研究包裝和重構策略，必須對這些系統進行自底向上的分析。因此，對現有應用程序的考慮會將我們帶到中間相遇的流程。

由于這些原因的存在，所以需要混合 SOAD 建模方法。這種方法以最佳的方式組合了 OOAD、BPM 和 EA 中的原理，并且融入了一些具有創新性的原理。這種新的方法的 SOAD 資源（原理和技術）：

EA

將企業應用程序和 IT 基礎設施發展成 SOA 可能是一個大的負擔，會影響多個業務線和組織單元。因此，需要應用 EA 框架和參考體系結構（如開放組織體系結構框架（The Open Group Architecture Framework，TOGAF））以及 Zachman，以努力實現單獨的解決方案之間體系結構的一致性。

根據過去的經驗，大多數現有的 EA 框架都在一個或多個方面有限制。例如，如果主要的問題是表示技術設備的低級構塊如何在宏觀層次互連，則無法獲得業務層流程或服務視圖。然而，在 SOA 的背景下，這種考慮問題的方式必須轉換為以表示業務服務的邏輯構件為中心，并且集中于定義服務之間的接口和服務級協定（Service Level Agreements，SLA）。

此外，許多企業級參考體系結構和框架是相當普通的，并沒有觸及設計領域。這樣的高級體系結構無法為架構師和開發人員提供具體的戰術意見，并且常常導致企業體系結構和解決方案體系結構之間出現根本性的分歧。

SOAD 必須幫助 SOA 架構師定義服務前景的整體業務級視圖。這是當今的 EA 框架所無法提供的，它們需要未來特定于 SOA 的增強；按需操作系統（On Demand Operating Environment，ODOE）是IBM 針對這種趨勢制定的主要戰略。

BPM

BPM 是一個不完整的規則，其中有許多不同的形式、表示法和資源。另一種常用的技術是定義表示概念性流程流的事件驅動流程鏈，正如 Barker 和 Longman 所定義的。這第二種技術使用了不同于 UML 的表示法。

此外，還有許多專用方法（如 BPM 技術）可能被咨詢公司和企業資源規劃（Enterprise Resource Planning，ERP）軟件包廠商視為具有競爭優勢。ARIS Implementation Platform 就是這樣的產品的一個例子。其他的方法包括：Line of Visibility Enterprise Modeling (LOVEM) 和 IBM 的組件業務建模（Component Business Modeling，CBM）戰略。

最近的趨勢是定義表示可執行流模型（如用于 Web 服務的業務流程執行語言（Business Process Execution Language for Web Services，BPEL））的標準方法。BPEL 將流程的范圍從分析擴展到實現。這樣的可執行模型引發了一系列的新問題，其中包括：

• 哪些方面應該用 BPEL 描述，哪些方面應該用 WSDL 描述？流程模型和傳統的編程模型之間的區別在什么地方？
• 如何將非功能性要求和服務質量特征這樣的方面加入模型之中？
• 同更傳統的編碼（例如在 J2EE 中）相比，在 BPEL 引擎的編程語言擴展中執行多少邏輯？
• 如何評定可執行流程模型的質量，其應用的最佳實踐是什么？
• 什么工作角色進行 BPEL 流管理；是業務專家（分析人員），還是開發角色（軟件架構師）？

必須利用所有現有的 BPM 方法作為 SOAD 的起點；然而，必須使用流程模型中用于驅動候選服務和它們的操作的附加技術來對其加以補充。此外，SOAD 中的流程建模必須與設計層用況建模保持同步，并且必須給出與 BPEL 有關的問題的答案。

OO 范式與面向服務 (SO) 范式

OO 分析是一種非常強大且廣為贊譽的方法，同樣，SOAD 應該盡可能多地利用 OO 分析技術。要將 OO 分析成功地應用于 SOA 項目，您就必須一次分析多個系統。用況模型必須繼續扮演重要的角色。然而，SOAD 必須主要是流程，而不是用戶驅動的。因此，SOAD 需要 BPM 和用況建?；顒又g的強鏈接。

在設計層，OO 的目標是能夠進行快速而有效的設計、開發以及執行靈活且可擴展的應用程序。對象是軟件構造，其行為就像它們建模的真實世界的實體。例如，顧客 (Customer) 將有名稱和聯系信息，并且還可能有一個或多個與之相關的帳戶對象。從 OO 的角度看，每件事情都是對象。

OO的基本原則是：

• 封裝：軟件對象就是包含模擬真實世界的對象的物理屬性（數據）和功能（行為）的離散包。例如，帳戶對象保持收支平衡并且包含平衡中的借貸機制。
• 信息隱藏：結構良好的對象有簡單的接口，并且不向外界顯漏任何內部機制。真實世界信息隱藏的例子是，您不需要詳細了解汽車的工作原理就能夠駕駛它。
• 類和實例：類是定義特定類型的軟件對象具有什么類型的屬性和行為的模板，而實例是具有這些屬性值的個別對象。創建類的新實例稱為實例化。利用生物學進行類比，人就是一個類。所有的人都具有一些屬性，比如身高、體重、頭發和眼睛顏色等等。我們中的每個人都是這個類 HumanBeing 的實例，具有一些特定的身高、體重以及其他的屬性值。類是一直存在的，而實例具有有限的生命周期。
• 關聯和繼承：在 OO 中，表達類和對象之間的關聯的能力是一個關鍵的概念；繼承是關聯的強形式，用于表達有關系：按照同樣的方式，生物物種由這樣的層次構成：界 (Kingdom)、門 (Phylum)、綱 (Class)、目 (Order)、科 (Family)、類 (Genus)、種 (Species)。我們常常發現軟件對象的自然層次。例如，當您創建一個財務應用程序實體時，您可能需要構造像經常帳戶（CheckingAclearcase/" target="_blank" >ccount）、儲蓄帳戶（SavingsAccount）和貸款帳戶（LoanAccount）這樣的對象。如果您看得更仔細一點，您將發現這些類共享許多屬性，比如都有收支平衡帳戶、借方帳戶和貸方帳戶等等
• 與其重復定義和管理這些屬性的代碼，不如創建一個通用的帳戶（Account）類，該類具有現金收支平衡并且可以處理借貸事務。所有其他的類都是這個帳戶（Account）對象的專門形式。例如，貸款帳戶（LoanAccount）將在零和某個約定的最大值之間具有負平衡，而儲蓄帳戶（SavingsAccount）將具有負平衡，并且將展示增加利息的行為，等等。
• 消息傳遞：為了完成一些有用的工作，軟件對象需要相互通信。它們通過相互發送消息來這樣做。例如，假定我們想將 $1000 從經常帳戶轉到儲蓄帳戶，要達到此目的，可以將帶有參數 $1000 的借消息發送到經常帳戶（CheckingAccount）實例，并且將相應的貸消息發送到儲蓄帳戶（SavingsAccount）實例。當實例接收消息時，它執行相應的功能，稱為方法，它有與消息相同的名稱。
• 多態：這個術語描述兩個或兩個以上的類接受相同的消息但是以不同的方式進行實現的情況。例如，自由經常帳戶（FreeCheckingAccount）實例和經常帳戶（CheckingAccount）實例將響應借 ($100) 消息，但是自由經常帳戶（FreeCheckingAccount）實例將正好 $1000 記入它的帳戶平衡的借方，而經常帳戶（CheckingAccount）實例將 $1000 加上交易費記入它的帳戶平衡的借方。

OO 支持應用程序分析、設計和開發的完整生命周期：

• OOAD 試圖找到最優的對象和最自然的類繼承來實現它們。
• OO 開發集中于應用程序的漸進式開發，每次實現一個業務場景或用況。像IBM WebSphere Studio Application Developer 這樣的工具有助于開發人員快速地構造和測試 OO 應用程序。
• OO 運行時環境，例如由 Java 虛擬機提供的，提供應用程序服務（如垃圾收集（刪除因使用它們的對象已經被丟棄而不再使用的資源））以及框架（如 J2EE）來為駐留在不同的服務器上的對象提供相互通信的機制。

目前與 SO 有關的 OO 設計實踐的主要問題在于，它的粒度級別集中在類級，對于業務服務建模來說，這樣的抽象級別太低了。諸如繼承這樣的強關聯產生了相關方之間一定程度的緊耦合（因而具有依賴性）。與此相反，SO 范式試圖通過松耦合來促進靈活性和敏捷性。目前，在 SOA 中還沒有服務實例的跨平臺繼承支持和一流的表示法來避免需要處理服務生命周期維護管理問題（如遠程垃圾收集）。

這些考慮事項使 OO 難以與 SO 體系結構樣式直接保持一致。然而，對于設計已定義的服務中的底層類和組件結構，OO 仍然是一種有價值的方法。此外，許多 OOAD 技術（例如類、責任、協作（CRC）卡）也可以用于服務建模（如果它們提升到更高層次的抽象的話）。在本文后面，我們將回過頭來討論這一點。

可見性層次和 OO、面向組件 和 SO 設計提供的重點之間的對應關系。它還展示了在 SOA 和 SOAD 背景中它們之間的相互關系。

至于表示法，統一建模語言（Unified Modeling Language，UML）——通過一些附加的定型（Stereotype）和概要加以增強——自然成為 SOAD 的重要基礎。

在使用 Rational Unified Process (RUP)——被認為是支持迭代軟件開發的分析與設計的主流 OOAD 流程之一——的流程方面，使用 UML 模型具有首要價值。然而，RUP 以 OOAD 的原則為基礎，因而使其不容易與 SOA 設計保持一致。從 RUP 的角度來看，系統的體系結構是其通過已定義接口交互的主要組件的體系結構。此外，這些組件還由逐漸減小到類級粒度的更小組件組成。相反，在 SOA 中，系統的體系結構通常包括滿足普通業務服務需要的無狀態、全封裝且自描述的服務組成，它更接近于映射到 BPM。這些服務可能包括許多協作或編排服務。這并沒有排除 RUP 采用的 OO 觀點，而是在其上實現了另一個抽象層。這個超層的作用是封裝作為正式的跨層接口結構中的 RUP 構件（軟件服務）設計的組件。

共2頁: 1 [2] 下一頁