面向服務的分析與設計原理SOA 項目交叉學科建模方法  |
 |
|
|
級別: 初級
Olaf Zimmermann ([email protected]), 高級 IT 架構師, IBM
Pal Krogdahl ([email protected]), 解決方案架構師, IBM
Clive Gee ([email protected]), 高級解決方案架構師, IBM
2004 年 6 月 01 日
最初的面向服務的體系結構（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 實現項目經驗表明，諸如 OOAD、EA 和 BPM 這樣的現有開發流程和表示法僅僅涵蓋支持 SOA 範式所需的部分要求。SOA 方法在加強已經制定的良好通用軟件體系結構原則（如信息隱藏、模塊化和問題分離）的同時，還增添了附加的主題，例如， 服務編排、 服務庫和 服務總線中間件模式，在建模時需要對它們給予特別的關注。
圖 1展示了現有的 EA、BPM 和 OOAD 建模方法的主要應用領域，也是我們隨後討論 SOAD 的出發點。圖中的水平軸表示 項目生命週期階段；垂直軸表示不同抽象層或 領域之間的區別，而建模活動通常就是在其上進行的。
圖 1. BPM、EA 和 OOAD 的位置
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 啓用 現有的應用程序的問題；大部分時間都採用自頂向下流程。現有的系統通常都存放有大量的重要數據和業務邏輯，並且不能簡單地加以替代。因此，爲了研究包裝和重構策略，必須對這些系統進行自底向上的分析。因此，對現有應用程序的考慮會將我們帶到中間相遇的流程。
由於這些原因的存在，所以需要混合 SOAD 建模方法。這種方法以最佳的方式組合了 OOAD、BPM 和 EA 中的原理，並且融入了一些具有創新性的原理。 圖 2展示了這種新的方法的 SOAD 資源（原理和技術）：
圖 2. SOAD 及其組成部分：OOAD、BPM 和 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 是一個不完整的規則，其中有許多不同的形式、表示法和資源。另一種常用的技術是定義表示概念性流程流的 事件驅動流程鏈，正如 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 分析是一種非常強大且廣爲讚譽的方法，同樣，SOAD 應該儘可能多地利用 OO 分析技術。要將 OO 分析成功地應用於 SOA 項目，您就必須一次分析多個系統。用況模型必須繼續扮演重要的角色。然而，SOAD 必須主要是 流程，而不是 用戶驅動的。因此，SOAD 需要 BPM 和用況建模活動之間的強鏈接。
在 設計層，OO 的目標是能夠進行快速而有效的設計、開發以及執行靈活且可擴展的應用程序。對象是軟件構造，其行爲就像它們建模的真實世界的實體。例如，顧客 (Customer) 將有名稱和聯繫信息，並且還可能有一個或多個與之相關的帳戶對象。從 OO 的角度看，每件事情都是對象。
OO的基本原則是：
- 封裝：軟件對象就是包含模擬真實世界的對象的物理屬性（數據）和功能（行爲）的離散包。例如，帳戶對象保持收支平衡並且包含平衡中的借貸機制。
- 信息隱藏：結構良好的對象有簡單的接口，並且不向外界顯漏任何內部機制。真實世界信息隱藏的例子是，您不需要詳細瞭解汽車的工作原理就能夠駕駛它。
- 類和實例： 類是定義特定類型的軟件對象具有什麼類型的屬性和行爲的模板，而 實例是具有這些屬性值的個別對象。創建類的新實例稱爲 實例化。利用生物學進行類比，人就是一個類。所有的人都具有一些屬性，比如身高、體重、頭髮和眼睛顏色等等。我們中的每個人都是這個類 HumanBeing 的實例，具有一些特定的身高、體重以及其他的屬性值。類是一直存在的，而實例具有有限的生命週期。
- 關聯和繼承：在 OO 中，表達類和對象之間的關聯的能力是一個關鍵的概念；繼承是關聯的強形式，用於表達有關係：按照同樣的方式，生物物種由這樣的層次構成：界 (Kingdom)、門 (Phylum)、綱 (Class)、目 (Order)、科 (Family)、類 (Genus)、種 (Species)。我們常常發現軟件對象的自然層次。例如，當您創建一個財務應用程序實體時，您可能需要構造像
經常帳戶（CheckingAccount）、儲蓄帳戶（SavingsAccount）和貸款帳戶（LoanAccount）這樣的對象。如果您看得更仔細一點（請參見 圖 3），您將發現這些類共享許多屬性，比如都有收支平衡帳戶、借方帳戶和貸方帳戶等等
圖 3. UML 類繼承示例![UML 類繼承示例]()
與其重複定義和管理這些屬性的代碼，不如創建一個通用的帳戶（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）卡）也可以用於服務建模（如果它們提升到更高層次的抽象的話）。在本文後面，我們將回過頭來討論這一點。
圖 4展示了可見性層次和 OO、 面向組件和 SO 設計提供的重點之間的對應關係。它還展示了在 SOA 和 SOAD 背景中它們之間的相互關係。
圖 4. 設計層次
至於表示法，統一建模語言（Unified Modeling Language，UML）——通過一些附加的定型（Stereotype）和概要加以增強——自然成爲 SOAD 的重要基礎。
在使用 Rational Unified Process (RUP)——被認爲是支持迭代軟件開發的分析與設計的主流 OOAD 流程之一——的流程方面，使用 UML 模型具有首要價值。然而，RUP 以 OOAD 的原則爲基礎，因而使其不容易與 SOA 設計保持一致。從 RUP 的角度來看，系統的體系結構是其通過已定義接口交互的主要組件的體系結構。此外，這些組件還由逐漸減小到類級粒度的更小組件組成。相反，在 SOA 中，系統的體系結構通常包括滿足普通 業務服務需要的無狀態、全封裝且自描述的服務組成，它更接近於映射到 BPM，如 圖 5所示。
圖 5. SOAD 服務定義層次
這些服務可能包括許多協作或編排服務。這並沒有排除 RUP 採用的 OO 觀點，而是在其上實現了另一個抽象層。這個超層的作用是封裝作爲正式的跨層接口結構中的 RUP 構件（ 軟件服務）設計的組件。
|
|
在這一部分中，我們將更詳細地描述 SOAD 的需求，並且開始確定它的主題和原理。目的是將關於這個主題的討論引到進一步的設計工作。進一步的工作無疑需要形式化 SOAD 方法。
已經爲 SOAD 確定了下列需求：
- 正如任何其他的項目和方法一樣，必須正式（至少半正式）地定義 流程和 表示法。通過選擇和組合 OOAD、BPM 和 EA 原理，就可以在需要時確定額外的原理。
- 必須有結構化的方法來概念化服務：
- OOAD 爲我們提供了應用程序層上的類和對象，而 BPM 具有事件驅動的流程模型。SOAD 需要將它們結合在一起。
- 方法不再是面向用況的，而是由業務事件和流程驅動的。用況建模是在更低的層次上作爲第二步進行的。
- 方法包括語法、語義和策略。這就需要特別的組合、語義代理和運行時發現。
- SOAD 必須提供定義良好的品質因素和最佳實踐（例如回答粒度問題）。必須回答 BPEL 提出的角色問題。例如，誰爲哪部分工作負責：是開發人員、架構師，還是分析人員？
- SOAD 活動還必須回答這樣的問題：什麼 不是好的服務？例如：不可重用的任何東西都不可能成爲好的一流 SOA 成員（即服務）。另一個例子就是帶有挑戰性的非功能要求的嵌入式實時系統，它們不能承受任何 XML 處理開銷。
- SOAD 必須易於進行端到端建模，並且有全面的工具支持。假如 SOA 給業務帶來了靈活性和敏捷性，就應該對從企業到體系結構和應用程序設計領域產生的支持方法有相同的期望。
一些通用原則或品質因素已經確定，並且可以作爲 SOAD 中的設計基準：
- 構思良好的服務給業務帶來了靈活性和敏捷性；它們通過鬆散耦合、封裝和信息隱藏使重構更加容易。
- 設計良好的服務是有意義的，並且不只適用於企業應用程序；服務之間的依賴性減到最少，並且是顯式聲明的。
- 服務抽象是內聚、完整和一致的；例如，在設計服務和它們的操作簽名時應該考慮 創建（Create）、 讀取（Read）、 更新（Update）、 刪除（Delete）和 搜索（Search）(CRUDS) 隱喻。
- 常常聲明的假定是，服務是無狀態的（例如非對話式的）；爲了要求服務在特定的問題域和上下文中是無狀態的，將削弱這種聲明。
- 領域專家無需深奧的專業知識就可以理解服務命名。
- 在 SOA 中，所有的服務都遵循相同的設計體系（通過模式和模板連接的）和交互模式；底層體系結構形式可以容易地標識（例如在體系結構複審期間）。
- 服務和服務使用者的開發除了領域知識之外只需要基本的編程語言技能；中間件專業知識只有少數的專業人員才需要，在理想的情況下，這種知識是爲工具和運行時廠商所用，而不是爲製作像 SOA 這樣的企業應用程序的公司所用。
自頂向下的業務級建模技術（如 CBM）可以爲 SOA 建模活動提供起點。但是正如我們在前面提到的，SOA 實現很少是在全新的項目中開始的；創建 SOA 解決方案几乎總需要涉及集成現有的遺留系統，方法是將它們分解成服務、操作、業務流程和業務規則（同時參見 圖 6）：
- 將現有的應用程序和廠商軟件包分解成表示相關操作組的離散服務集（自底向上方法）。
- 從應用程序中將業務流程和規則抽象爲由業務編排模型管理的單獨 BPM。
圖 6. 服務分解
所有的 OOAD 都同標識和定義服務有關；但是還需要具有更高層的觀點。此外，當 SOA 致力於比經典開發項目層次更高的開發時，就有了發揮其他創造性思維的空間。
直接和間接業務分析
通過項目相關人員的會談和 CBM 來進行 BPM 和 直接需求分析是一個容易理解且非常合適的標識候選服務的方法。
過去的經驗表明，這條主要的途徑應該通過補充 間接技術來加以改進。在選擇候選服務時，產品經理和其他業務領導應該進行協商。例如，什麼是計劃付款和開票模型？應該商議假定使用正在構建中的系統的企業的組織結構圖。建議還考慮一下非 SOA 項目中任何現有的用況模型。用於對正在構造的系統進行營銷介紹的術語是另一個很好的關於服務操作候選者的來源（特別是動詞，很少關注營銷動詞！）。
域分解
在 Endrei中定義的域分解、子系統分析、目標模型創建和相關技術是 SOA 流程構造方法或 服務概念化框架（它是基於 Levi and Arsanjani先前完成的工作構建的）最有希望的提議。來自 SEI的 FODA 工作也爲這方面的討論做出了貢獻。
服務粒度
選擇正確的抽象級別是服務建模的一個關鍵問題。您常常會聽到 進行粗粒度建模的建議。這有點過於簡單化了。您應該將其改爲在不損失或損害相關性、一致性和完整性的情況下 儘可能地進行粗粒度建模。在任何 SOA 中，都有細粒度服務抽象的空間（假定有業務要求的話）。由於 SOA 並不等同於 Web 服務和 SOAP，因此可以使用不同的協議綁定來訪問抽象級別不同的服務。另一種選擇就是將一些相關的服務捆綁成粗粒度的服務定義，這是門面模式的變種。
命名約定
應該定義企業命名模式（XML 名稱空間、Java 包名、Internet 域）。簡單的例子就是始終用名詞來命名服務，而用動詞來命名操作。這種最佳實踐來源於 OOAD 空間。
除了組合 OOAD、BPM 和 EA 技術之外，還有幾個重要的 SOAD 概念和方面有待充實：
- 服務分類和聚合
- 策略和方面
- 中間相遇流程
- 語義代理
- 服務獲取和知識代理
服務分類和聚合
服務有不同的用法和用途；例如，軟件服務可以不同於業務服務（如前面的 圖 5所示）。此外，還可以將原子服務編排成級別更高、功能齊全的服務。
服務組合可以通過可執行模型（如 BPEL 建模的模型）來加以簡化；這是傳統的建模工具和方法不能處理的事情。
策略和方面
服務具有語法、語義和 QoS 特徵，所有這些都必須進行建模；正式的接口契約必須涵蓋的比 Web 服務描述語言（Web Services Description Language，WSDL）的多。因此， Web 服務策略（WS-Policy） 框架是一個重要的相關規範。
除了已經制定的良好 體系結構可跟蹤性原則之外， 業務可跟蹤性也是一個理想的品質：應該有可能將所有的運行時構件直接與非技術領域專家可以理解的語言聯繫起來。這對於直接在業務和服務層公開的抽象非常重要。Sarbanes-Oxley (SOX) 法案是需要這種業務可跟蹤性的業務驅動程序的一個例子。
流程：中間相遇
在真實世界中，並沒有全新的項目，必須始終考慮遺留系統（ 遺留系統是現有系統的同義詞）。因此，需要 中間相遇的方法，而不是單純的自頂向下或自底向上的流程。
在設計取決於現有的 IT 環境而不是現在和將來的業務需要的情況下，自底向上的方法往往會導致不好的業務服務抽象。而自頂向下的方法可能會產生不足的非功能性需求特徵，並且損害其他的體系結構品質因素（例如因域模型中缺乏標準化而導致的性能問題），另外，也會在服務和組件中產生不匹配的不良問題。
服務獲取和知識代理
這是一個知識管理和生命週期問題：如何成功地準備好服務並且使其在概念化之後可以重用？
應該將重用看作是標識和定義服務最主要的推動標準之一。如果組件（或服務）不可能重用，就不無法將其作爲服務進行部署。它可以連接到另一個與企業體系結構相關的服務，但是不能單獨作爲一個服務而存在。
然而，即使從開始就計劃好了重用，還必須形式化服務獲取流程。由多個使用者使用服務是明確的 SOA 設計目標。構建時服務註冊中心（例如企業 UDDI 目錄）可能能夠解決部分問題。
|
|
汽車工作訂單（Automotive Work Order）描述了一家汽車維修公司管理其顧客運營的流程。我們將通過這個領域中的問題來闡述 SOAD 的觀點。
工作訂單代表汽車服務公司和顧客之間的約定，以進行一系列例行維修或應急維修，例如例行 50,000 英里服務，更換剎車片或輪胎，或者換油。
業務場景（如 圖 7所示）如下：
- 當顧客打電話預約時創建工作訂單。
- 爲每個計劃的維修活動或操作創建一個獨立的工作訂單項，其中包括需要使用的零件、備件和勞務的詳細情況。
- 在安排預約之前確保所有必需的零件都有庫存。
- 需要爲每個工作訂單項安排具有適當的裝備的維修間以及具備適當的條件的機器。
- 計算估計的總成本，接着顧客認可該預約；或者方案終止，隨即取消工作訂單。
- 在預約之前，立即在選定的維修間裝配必需的零件、備件、工具和設備。
- 當顧客到達時，進行計劃的活動以及在檢查交通工具時顯得有必要的任何其他活動。
- 記錄所用的零件和備件的實際價值以及勞務。
- 在完成所有的維修時計算總費用。
- 創建發票並且將其交給顧客。
圖 7. 工作訂單的宏流示例
如果您將此作爲一個獨立的應用程序從頭開始創建，您就可能創建一組如 圖 8所示的類。
圖 8. 工作訂單的類圖示例
如果您將工作訂單構造爲一個 OO 應用程序，這些軟件對象將包含所有必需的業務規則，並且理解應該遵循的業務流程。
然而，這種方法在實踐方面存在着一些缺點：
- 許多步驟涉及與現有遺留系統和數據庫（例如帳單編制、日程安排以及庫存系統）的連接，它們不可能遵循 OO 範式進行設計（在這樣的情況下，應用適配器或仲裁器會有所幫助）。
- 爲了使系統儘可能地靈活，將一些規則外化是有幫助的，這樣就可以在不更改代碼的情況下修改流程或工作流。例如像下面這樣的規則：
- 標準的 24,000 英里服務包括四公升油。只是在使用四升以上的油或顧客要求優質油（如合成油）時才應該收取額外的郵費。
- 在遺留應用程序中有一套工業標準爲普通汽車維修活動進行勞務估價。除非維修人員收取的費用超過該估價的 X% 並且報告產生差別的有根據的原因，否則顧客就應該支付標準的勞務費。
- 如果超過估價的 Y% 以上，就應該聯繫顧客以進行確認。
SOAD 爲這些問題提供了極好的解決方案。由於它基於相關的行爲對服務進行分組，而不是進行封裝（行爲及數據），所以這組服務與業務對象略有不同。
例如，您可能將工作訂單（Work Order）和工作訂單項（Work Order Item）一起分到工作訂單服務（Work Order Services），並且創建日程安排（Scheduling）、目錄（Catalog）和庫存（Inventory）服務。另外，因爲沒有服務實例，所以沒有與服務之間的關係等價的東西。工作訂單的服務模型可能看起來如 圖 9所示。
圖 9. 工作訂單的服務模型示例
與 OO 範式不同，這個模型並不表示功能系統。既沒有考慮流，也沒有描述業務事件或規則。在 SOA 範式中，在服務外面維護的業務流程編排決定了執行服務調用的順序和時間。
從概念上講，從第一次顧客聯繫到完成工作和帳單支付的整個業務表示單個宏觀層次的工作單元，並具有數天到數週不等的生命週期。畢竟，從企業的角度來看，工作單元會產生收入。
然而，實際出現的情況是在一段相對長的時間內單獨發生的一系列集中活動，例如，定義活動、安排預約、選擇零件和備件、進行維修活動等等。在 IT 系統中，沒有實際的 流程會持續幾分鐘以上；事件之間的業務流程狀態以數據的形式保存在數據庫中。
這種類型的流程可以用狀態轉換模型（例如 UML 中可用的）很好地進行表示。 圖 10顯示了用有限狀態機（finite-state machine）方法如何對業務流進行建模的示例。它是在業務流程進行時工作訂單的狀態如何改變的高級視圖。
圖 10. 工作訂單的業務流程模型
業務流程編排集中於狀態之間的這些轉變。單獨的操作永久地記錄相關的狀態改變。
圖 11顯示了部分編排的示例，其中包括 圖 10所示的業務場景中的步驟 1 到 5（例如，顧客定義他們的交通工作所需的工作，並且安排預約以進行實施）。
圖 11. 工作訂單的業務交互模型
|
|
在本文中，我們已經討論和激發了對創新的中間相遇的方法的需求，這種方法搭建了業務和 IT 之間的橋樑，並且支持 SOA 項目的分析和設計階段。我們還提議將這種新的交叉學科的 SOAD 方法作爲一個整體的建模規則，它以現在構建良好且廣爲讚譽的 OOAD、EA、和 BPM 爲基礎。
在詳細定義 SOAD 表示法和流程的同時，還確定了關鍵的原理，比如服務概念化（或標識）、服務分類或聚合、策略和方面、中間相遇流程、語義代理和服務獲取（以供重用）。
SOAD 需要增強現有的軟件開發方法，進一步提高企業應用程序開發項目的可用性和適用性。隨着時間的推移，還將發展相關的最佳實踐。
我們還認識到，UML 在流程的表示法選擇方面將繼續佔支配地位；可能需要進行增強以滿足更廣泛的 SOAD 的要求。
完成 SOAD 方法的下一步就是定義所需的端到端流程和表示法，複審活動中的角色和它們的責任，並且繼續檢查所提議的方法在項目中的有效性。
- 您可以參閱本文在 developerWorks 全球站點上的 英文原文.
- 請訪問 IEE Xplore 站點以獲得由 Ali Arsanjani 撰寫的 A Domain-Language Approach to Designing Dynamic Enterprise Component based Architectures to Support Business Services。
- 在 Amazon.com 上獲得由 Barker 和 Longman 撰寫的 CASE Method - Function and Process Modeling。
- 在 Addison Wesley 站點獲得由 Grady Booch 撰寫的 Object-Oriented Analysis and Design with Applications。
- 在 BPMI.org 上查閱 Business Process Management Initiative。
- 閱讀 面向服務的體系結構擴展 Web 服務的前景，第 1 部分（ developerWorks，2004 年 4 月）。
- 閱讀 Endrei M. 等撰寫的 Patterns: Service-oriented Architecture and Web Services 紅皮書（SG24-6303-00，2004 年 4 月，Endrei M.）。
- 在 Carnegie Mellon University Software Engineering Institute (SEI) 站點上學習更多關於 Feature-Oriented Domain Analysis的知識。
- 訪問 InfoWorld.com 以獲得更多關於 Interview with Grady Booch的信息。
- 閱讀 Object-Oriented Software Design : A Use Case Driven Approach。
- 查閱由 Ali Arsanjani 撰寫的 A goal-driven approach to enterprise component identification and specification。
- 閱讀由 F. Leymann、D. Roller 和 M.T. Schmidt 撰寫的 Web Services and Business Process Management（IBM Systems Journal，2002 年第 2 期第 41 卷）。
- 瞭解更多關於 Rational Unified Process (RUP)的信息。
- 要獲得更多關於 Treasury Enterprise Architecture Framework (TEAF)的信息，請訪問 Software.org 站點。
- 訪問 Open Group 站點以獲得更多關於 The Open Group Architecture Framework (TOGAF)Version 8.1 的信息。
- 獲得關於 Web 服務策略框架的信息： Web 服務策略（WS-Policy）框架。
- 瞭解更多關於 IBM 的 on demand Operating Environment的信息。
- 在 Zifa.com 查閱關於用於企業體系結構的 Zachman 框架的信息。
- 在 Developer Bookstore購買涉及各種各樣的技術主題的打折書。
|
||
|
|
|
Olaf Zimmermann 是 IBM worldwide Applied Web Services 組的顧問 IT 構架師。他在分佈式計算、面向服務體系結構、Web 服務/XML 和 J2EE 方面頗有專長。在過去的幾年裏，Olaf 指導了大量與 Web 服務有關的交流項目，包括幾本產品參考書。他是 Springer 教科書 Perspectives on Web Services （ISBN 3-540-00914-0）的作者。他還參與了幾本 IBM ITSO 紅皮書（比如 Web Services Wizardry with WebSphere Studio Application Developer （SG24-6292-00））的寫作。Olaf 從 1994 年開始就與 IBM 合作，涉及的領域非常廣泛，其中包括產品開發、技術預售諮詢、教學以及系統集成。Olaf 在位於德國 Braunschweig 的 Technical University 獲得計算機科學學位。您可以通過 [email protected]與他聯繫。 |
|
||
|
|
|
Pal Krogdahl 是一名解決方案架構師，在 IGS 的 IBM Business Consulting Services（位於瑞典）工作。他從 1998 年開始就職於 IBM，涉及了多個領域，比如軟件開發、售前技術諮詢和解決方案體系結構。他擅長的領域包括分佈式計算、中間件和應用程序服務體系結構，主要集中在 EAI 和 SOA。Pal 最近撰寫了一些範圍廣泛的文章，探討的主題有基於 SOA 的 EA、以及它們與 IBM 用於電子商務和按需操作系統環境的模式的關係。到目前爲止，他已經完成了 IBM International Technical Support Organization 的一些高級培訓，在該組織中，他同人合著了一些與 WebSphere 有關的紅皮書，這些紅皮書主要集中在 Web 服務和 SOA 方面，例如 Patterns: Service-Oriented Architecture and Web Services(ISBN 073845317X)。在過去的 18 個月裏，他一直在向 IBM 內外的技術人員介紹 Web 服務和基於 SOA 的按需操作環境的實現方面的知識。您可以通過 [email protected]與他聯繫。 |
|
||
|
|
|
Clive Gee 是一名高級解決方案架構師，工作在 IBM Enterprise Integration Services 部。他於 1976 年加入 IBM Europe 並於 1997 年調到 IBM US。1990 年，作爲創立 IBM European Object Technology Practice 的一員，他是 IBM 中第一位 OO 的支持者。從那以後，他獲得了領導企業 OO 交流項目的大量實踐經驗，涉及多個行業（如公用事業、金融業、運輸業、零售業和電信業）的複雜系統集成和應用程序開發。目前，他正忙於爲一個重要的美國客戶配置部署 SOA 解決方案。Clive 從蘇格蘭的 University of Stirling 大學獲得理論物理博士學位。您可以通過 [email protected]與他聯繫。 |