最初的面向服務的體系結構（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 中有三個主要的抽象級別：
從建模的觀點來看，由此帶來的挑戰是如何描述設計良好的操作、服務和流程抽象的特征以及如何系統地構造它們。這些相關問題都是當前行業內和學術界最常討論
的問題。據我們所知，最近幾乎所有的 SOA
項目或專題研討會都將這樣的服務建模方面作為重要的主題，并引起了許多的爭論。因此，讓我們更近地作一番審視。
為什么 BPM、EA 和 OOAD 還不夠？
早期的 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
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)。我們常常發現軟件對象的自然層次。例如，當您創建一個財務應用程序實體時，您可能需要構造像
經常帳戶（CheckingAccount） 、
儲蓄帳戶（SavingsAccount） 和
貸款帳戶（LoanAccount） 這樣的對象。如果您看得更仔細一點（請參見
圖 3），您將發現這些類共享許多屬性，比如都有收支平衡帳戶、借方帳戶和貸方帳戶等等
圖 3. 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 方法。
SOAD 必須提供什么？
已經為 SOAD 確定了下列需求：
- 正如任何其他的項目和方法一樣，必須正式（至少半正式）地定義
流程和
表示法。通過選擇和組合 OOAD、BPM 和 EA 原理，就可以在需要時確定額外的原理。
- 必須有結構化的方法來概念化服務：
- OOAD 為我們提供了應用程序層上的類和對象，而 BPM 具有事件驅動的流程模型。SOAD 需要將它們結合在一起。
- 方法不再是面向用況的，而是由業務事件和流程驅動的。用況建模是在更低的層次上作為第二步進行的。
- 方法包括語法、語義和策略。這就需要特別的組合、語義代理和運行時發現。
- SOAD 必須提供定義良好的品質因素和最佳實踐（例如回答粒度問題）。必須回答 BPEL 提出的角色問題。例如，誰為哪部分工作負責：是開發人員、架構師，還是分析人員？
- SOAD 活動還必須回答這樣的問題：什么
不是好的服務？例如：不可重用的任何東西都不可能成為好的一流 SOA 成員（即服務）。另一個例子就是帶有挑戰性的非功能要求的嵌入式實時系統，它們不能承受任何 XML 處理開銷。
- SOAD 必須易于進行端到端建模，并且有全面的工具支持。假如 SOA 給業務帶來了靈活性和敏捷性，就應該對從企業到體系結構和應用程序設計領域產生的支持方法有相同的期望。
品質因素
一些通用原則或品質因素已經確定，并且可以作為 SOAD 中的設計基準：
- 構思良好的服務給業務帶來了靈活性和敏捷性；它們通過松散耦合、封裝和信息隱藏使重構更加容易。
- 設計良好的服務是有意義的，并且不只適用于企業應用程序；服務之間的依賴性減到最少，并且是顯式聲明的。
- 服務抽象是內聚、完整和一致的；例如，在設計服務和它們的操作簽名時應該考慮
創建（Create）、
讀?。≧ead）、
更新（Update）、
刪除（Delete）和
搜索（Search）(CRUDS) 隱喻。
- 常常聲明的假定是，服務是無狀態的（例如非對話式的）；為了要求服務在特定的問題域和上下文中是無狀態的，將削弱這種聲明。
- 領域專家無需深奧的專業知識就可以理解服務命名。
- 在 SOA 中，所有的服務都遵循相同的設計體系（通過模式和模板連接的）和交互模式；底層體系結構形式可以容易地標識（例如在體系結構復審期間）。
- 服務和服務使用者的開發除了領域知識之外只需要基本的編程語言技能；中間件專業知識只有少數的專業人員才需要，在理想的情況下，這種知識是為工具和運行時廠商所用，而不是為制作像 SOA 這樣的企業應用程序的公司所用。
服務標識和定義
自頂向下的業務級建模技術（如 CBM）可以為 SOA 建?；顒犹峁┢瘘c。但是正如我們在前面提到的，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 空間。
第一類 SOAD 原理
除了組合 OOAD、BPM 和 EA 技術之外，還有幾個重要的 SOAD 概念和方面有待充實：
- 服務分類和聚合
- 策略和方面
- 中間相遇流程
- 語義代理
- 服務獲取和知識代理
服務分類和聚合
服務有不同的用法和用途；例如，軟件服務可以不同于業務服務（如前面的
圖 5所示）。此外，還可以將原子服務編排成級別更高、功能齊全的服務。
服務組合可以通過可執行模型（如 BPEL 建模的模型）來加以簡化；這是傳統的建模工具和方法不能處理的事情。
策略和方面
服務具有語法、語義和 QoS 特征，所有這些都必須進行建模；正式的接口契約必須涵蓋的比 Web 服務描述語言（Web Services Description Language，WSDL）的多。因此，
Web 服務策略（WS-Policy） 框架是一個重要的相關規范。
除了已經制定的良好
體系結構可跟蹤性原則之外，
業務可跟蹤性也是一個理想的品質：應該有可能將所有的運行時構件直接與非技術領域專家可以理解的語言聯系起來。這對于直接在業務和服務層公開的抽象非常重要。Sarbanes-Oxley (SOX) 法案（請參閱來自
Astor的文章）是需要這種業務可跟蹤性的業務驅動程序的一個例子。
流程：中間相遇
在真實世界中，并沒有全新的項目，必須始終考慮遺留系統（
遺留系統是現有系統的同義詞）。因此，需要
中間相遇的方法，而不是單純的自頂向下或自底向上的流程。
在
設計取決于現有的 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 方法的下一步就是定義所需的端到端流程和表示法，復審活動中的角色和它們的責任，并且繼續檢查所提議的方法在項目中的有效性。
參考資料
 |
|
作者簡介
|
| | 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 的按需操作環境的實現方面的知識。您可以通過
pal.krogdahl@se.ibm.com與他聯系。
|
|
| | 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 大學獲得理論物理博士學位。您可以通過 clive@us.ibm.com與他聯系。
|