?

面向服務(wù)的分析與設(shè)計原理

??????????????????????????????????????????? -------SOA 項目交叉學(xué)科建模方法

最初的面向服務(wù)的體系結(jié)構(gòu)（ Service-Oriented Architecture ， SOA ） 的實現(xiàn)項目的經(jīng)驗表明，諸如面向?qū)ο蟮姆治雠c設(shè)計（ Object-Oriented Analysis and Design ， OOAD ）、企業(yè)體系結(jié)構(gòu)（ Enterprise Architecture ， EA ）框架和業(yè)務(wù)流程建模（ Business Process Modeling ， BPM ）這樣的現(xiàn)有開發(fā)流程和表示法僅僅涵蓋了支持目前出現(xiàn)在 SOA 中的體系結(jié)構(gòu)模式所需的部分要求。

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

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

需要結(jié)構(gòu)化方法或 分析與設(shè)計方法來設(shè)計高質(zhì)量的 SOA 。因為現(xiàn)有的方法中沒有一種能夠滿足程序設(shè)計人員對最新的 SOA 項目的要求，所以他們建議將已經(jīng)形成的良好實踐（如 OOAD 、 EA 和 BPM ）中的原理組合起來，并且使用根據(jù)需要創(chuàng)新的原理來對其加以補(bǔ)充。 ?

1. 引言

面向服務(wù)的體系結(jié)構(gòu)（ SOA ）和 Web 服務(wù)的基本觀念是成為我們?nèi)粘ＵZ言的一部分，并可看作是適于設(shè)計現(xiàn)代企業(yè)應(yīng)用程序的體系結(jié)構(gòu)形式。在這種背景下， 什么構(gòu)成好的服務(wù) 這個基本問題就成為確保成功實現(xiàn) SOA 的關(guān)鍵。

像 面向?qū)ο蟮姆治雠c設(shè)計（ Object-Oriented Analysis and Design ， OOAD ） 、 企業(yè)體系結(jié)構(gòu)（ Enterprise Architecture ， EA ）框架 和 業(yè)務(wù)流程建模（ Business Process Modeling ， BPM ） 這樣的現(xiàn)有建模規(guī)則為我們提供了高質(zhì)量的實踐，可以長期幫助標(biāo)識和定義體系結(jié)構(gòu)內(nèi)的適當(dāng)抽象。然而經(jīng)驗表明，這些實踐各自單獨應(yīng)用時達(dá)不到要求。

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

2. 面向服務(wù)的概念

在發(fā)現(xiàn)新的商機(jī)或威脅的預(yù)期下， SOA 體系結(jié)構(gòu)形式旨在提供企業(yè)業(yè)務(wù)解決方案，這些業(yè)務(wù)解決方案可以 按需 擴(kuò)展或改變。 SOA 解決方案由可重用的服務(wù)組成，帶有定義良好且符合標(biāo)準(zhǔn)的已發(fā)布接口。 SOA 提供了一種機(jī)制，通過這種機(jī)制，可以集成現(xiàn)有的遺留應(yīng)用程序，而不管它們的平臺或語言。

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

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

在 SOA 術(shù)語中，業(yè)務(wù)流程包括依據(jù)一組業(yè)務(wù)規(guī)則按照有序序列執(zhí)行的一系列操作。操作的排序、選擇和執(zhí)行稱為服務(wù)或流程 編排 。典型的情況是調(diào)用已編排服務(wù)來響應(yīng)業(yè)務(wù)事件。

從建模的觀點來看，由此帶來的挑戰(zhàn)是如何描述設(shè)計良好的操作、服務(wù)和流程抽象的特征以及如何系統(tǒng)地構(gòu)造它們。這些相關(guān)問題都是當(dāng)前行業(yè)內(nèi)和學(xué)術(shù)界最常討論的問題。據(jù)我們所知，最近幾乎所有的 SOA 項目或?qū)ｎ}研討會都將這樣的服務(wù)建模方面作為重要的主題，并引起了許多的爭論。因此，讓我們更近地作一番審視。

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

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

圖 1 展示了現(xiàn)有的 EA 、 BPM 和 OOAD 建模方法的主要應(yīng)用領(lǐng)域，也是我們隨后討論 SOAD 的出發(fā)點。圖中的水平軸表示 項目生命周期階段 ；垂直軸表示不同抽象層或 領(lǐng)域 之間的區(qū)別，而建?；顒油ǔ＞褪窃谄渖线M(jìn)行的。

圖 1. BPM 、 EA 和 OOAD 的位置

SOA 的遠(yuǎn)景是相當(dāng)容易理解的，因為它的技術(shù)基礎(chǔ)眾所周知。例如，在任何 SOA 工作中，應(yīng)用通用的軟件體系結(jié)構(gòu)原則和 OO 技術(shù)都是一個有效的開端。然而，正如我們已經(jīng)提到的，早期采用者最常詢問的問題是如何標(biāo)識正確的服務(wù)。如前所述， OOAD 、 EA 和 BPM 在各自獨立地應(yīng)用時不能提供滿意的答案，而這正是我們現(xiàn)在要說明的。

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

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

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

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

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

圖 2. SOAD 及其組成部分： OOAD 、 BPM 和 EA

EA

將企業(yè)應(yīng)用程序和 IT 基礎(chǔ)設(shè)施發(fā)展成 SOA 可能是一個大的負(fù)擔(dān)，會影響多個業(yè)務(wù)線和組織單元。因此，需要應(yīng)用 EA 框架和參考體系結(jié)構(gòu)（如 開放組織體系結(jié)構(gòu)框架（ The Open Group Architecture Framework，TOGAF） ）以及 Zachman ，以努力實現(xiàn)單獨的解決方案之間體系結(jié)構(gòu)的一致性。

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

此外，許多企業(yè)級參考體系結(jié)構(gòu)和框架是相當(dāng)普通的，并沒有觸及設(shè)計領(lǐng)域。這樣的高級體系結(jié)構(gòu)無法為架構(gòu)師和開發(fā)人員提供具體的戰(zhàn)術(shù)意見，并且常常導(dǎo)致企業(yè)體系結(jié)構(gòu)和解決方案體系結(jié)構(gòu)之間出現(xiàn)根本性的分歧。

SOAD 必須幫助 SOA 架構(gòu)師定義服務(wù)前景的整體業(yè)務(wù)級視圖。這是當(dāng)今的 EA 框架所無法提供的，它們需要未來特定于 SOA 的增強(qiáng)； 按需操作系統(tǒng)（ On Demand Operating Environment，ODOE） 是 IBM 針對這種趨勢制定的主要戰(zhàn)略。

BPM

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

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

最近的趨勢是定義表示可執(zhí)行流模型（如 用于 Web 服務(wù)的業(yè)務(wù)流程執(zhí)行語言（Business Process Execution Language for Web Services，BPEL） ）的標(biāo)準(zhǔn)方法。 BPEL 將流程的范圍從分析擴(kuò)展到實現(xiàn)。這樣的可執(zhí)行模型引發(fā)了一系列的新問題，其中包括：

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

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

4. OO 范式與面向服務(wù) (SO) 范式

OO 分析 是一種非常強(qiáng)大且廣為贊譽(yù)的方法，同樣，SOAD 應(yīng)該盡可能多地利用 OO 分析技術(shù)。要將 OO 分析成功地應(yīng)用于 SOA 項目，您就必須一次分析多個系統(tǒng)。用況模型必須繼續(xù)扮演重要的角色。然而，SOAD 必須主要是 流程，而不是 用戶驅(qū)動的。因此，SOAD 需要 BPM 和用況建?；顒又g的強(qiáng)鏈接。 在 設(shè)計層，OO 的目標(biāo)是能夠進(jìn)行快速而有效的設(shè)計、開發(fā)以及執(zhí)行靈活且可擴(kuò)展的應(yīng)用程序。對象是軟件構(gòu)造，其行為就像它們建模的真實世界的實體。例如，顧客 (Customer) 將有名稱和聯(lián)系信息，并且還可能有一個或多個與之相關(guān)的帳戶對象。從 OO 的角度看，每件事情都是對象。

OO 的基本原則是：

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

OO 支持應(yīng)用程序分析、設(shè)計和開發(fā)的完整生命周期：

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

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

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

圖 4 展示了可見性層次和 OO 、 面向組件 和 SO 設(shè)計提供的重點之間的對應(yīng)關(guān)系。它還展示了在 SOA 和 SOAD 背景中它們之間的相互關(guān)系。

圖 4. 設(shè)計層次

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

在使用 Rational Unified Process (RUP) ——被認(rèn)為是支持迭代軟件開發(fā)的分析與設(shè)計的主流 OOAD 流程之一——的流程方面，使用 UML 模型具有首要價值。然而， RUP 以 OOAD 的原則為基礎(chǔ)，因而使其不容易與 SOA 設(shè)計保持一致。從 RUP 的角度來看，系統(tǒng)的體系結(jié)構(gòu)是其通過已定義接口交互的主要組件的體系結(jié)構(gòu)。此外，這些組件還由逐漸減小到類級粒度的更小組件組成。相反，在 SOA 中，系統(tǒng)的體系結(jié)構(gòu)通常包括滿足普通 業(yè)務(wù)服務(wù) 需要的無狀態(tài)、全封裝且自描述的服務(wù)組成，它更接近于映射到 BPM ，如 圖 5 所示。

圖 5. SOAD 服務(wù)定義層次

這些服務(wù)可能包括許多協(xié)作或編排服務(wù)。這并沒有排除 RUP 采用的 OO 觀點，而是在其上實現(xiàn)了另一個抽象層。這個超層的作用是封裝作為正式的跨層接口結(jié)構(gòu)中的 RUP 構(gòu)件（ 軟件服務(wù) ）設(shè)計的組件。

5.SOAD 原理

在這一部分中，我們將更詳細(xì)地描述 SOAD 的需求，并且開始確定它的主題和原理。目的是將關(guān)于這個主題的討論引到進(jìn)一步的設(shè)計工作。進(jìn)一步的工作無疑需要形式化 SOAD 方法。

SOAD 必須提供什么？

已經(jīng)為 SOAD 確定了下列需求：

• 正如任何其他的項目和方法一樣，必須正式（至少半正式）地定義 流程 和 表示法 。通過選擇和組合 OOAD 、 BPM 和 EA 原理，就可以在需要時確定額外的原理。
• 必須有結(jié)構(gòu)化的方法來概念化服務(wù)：
• OOAD 為我們提供了應(yīng)用程序?qū)由系念惡蛯ο?，?/span> BPM 具有事件驅(qū)動的流程模型。 SOAD 需要將它們結(jié)合在一起。
• 方法不再是面向用況的，而是由業(yè)務(wù)事件和流程驅(qū)動的。用況建模是在更低的層次上作為第二步進(jìn)行的。
• 方法包括語法、語義和策略。這就需要特別的組合、語義代理和運行時發(fā)現(xiàn)。
• SOAD 必須提供定義良好的品質(zhì)因素和最佳實踐（例如回答粒度問題）。必須回答 BPEL 提出的角色問題。例如，誰為哪部分工作負(fù)責(zé)：是開發(fā)人員、架構(gòu)師，還是分析人員？
• SOAD 活動還必須回答這樣的問題：什么 不是 好的服務(wù)？例如：不可重用的任何東西都不可能成為好的一流 SOA 成員（即服務(wù)）。另一個例子就是帶有挑戰(zhàn)性的非功能要求的嵌入式實時系統(tǒng)，它們不能承受任何 XML 處理開銷。
• SOAD 必須易于進(jìn)行端到端建模，并且有全面的工具支持。假如 SOA 給業(yè)務(wù)帶來了靈活性和敏捷性，就應(yīng)該對從企業(yè)到體系結(jié)構(gòu)和應(yīng)用程序設(shè)計領(lǐng)域產(chǎn)生的支持方法有相同的期望。

品質(zhì)因素

一些通用原則或品質(zhì)因素已經(jīng)確定，并且可以作為 SOAD 中的設(shè)計基準(zhǔn)：

• 構(gòu)思良好的服務(wù)給業(yè)務(wù)帶來了靈活性和敏捷性；它們通過松散耦合、封裝和信息隱藏使重構(gòu)更加容易。
• 設(shè)計良好的服務(wù)是有意義的，并且不只適用于企業(yè)應(yīng)用程序；服務(wù)之間的依賴性減到最少，并且是顯式聲明的。
• 服務(wù)抽象是內(nèi)聚、完整和一致的；例如，在設(shè)計服務(wù)和它們的操作簽名時應(yīng)該考慮 創(chuàng)建（ Create ） 、 讀取（ Read ） 、 更新（ Update ） 、 刪除（ Delete ） 和 搜索（ Search ） (CRUDS) 隱喻。
• 常常聲明的假定是，服務(wù)是無狀態(tài)的（例如非對話式的）；為了要求服務(wù)在特定的問題域和上下文中是無狀態(tài)的，將削弱這種聲明。
• 領(lǐng)域?qū)＜覠o需深奧的專業(yè)知識就可以理解服務(wù)命名。
• 在 SOA 中，所有的服務(wù)都遵循相同的設(shè)計體系（通過模式和模板連接的）和交互模式；底層體系結(jié)構(gòu)形式可以容易地標(biāo)識（例如在體系結(jié)構(gòu)復(fù)審期間）。
• 服務(wù)和服務(wù)使用者的開發(fā)除了領(lǐng)域知識之外只需要基本的編程語言技能；中間件專業(yè)知識只有少數(shù)的專業(yè)人員才需要，在理想的情況下，這種知識是為工具和運行時廠商所用，而不是為制作像 SOA 這樣的企業(yè)應(yīng)用程序的公司所用。

服務(wù)標(biāo)識和定義

自頂向下的業(yè)務(wù)級建模技術(shù)（如 CBM ）可以為 SOA 建模活動提供起點。但是正如我們在前面提到的， SOA 實現(xiàn)很少是在全新的項目中開始的；創(chuàng)建 SOA 解決方案幾乎總需要涉及集成現(xiàn)有的遺留系統(tǒng)，方法是將它們分解成服務(wù)、操作、業(yè)務(wù)流程和業(yè)務(wù)規(guī)則（同時參見 圖 6 ）：

• 將現(xiàn)有的應(yīng)用程序和廠商軟件包分解成表示相關(guān)操作組的離散服務(wù)集（自底向上方法）。
• 從應(yīng)用程序中將業(yè)務(wù)流程和規(guī)則抽象為由業(yè)務(wù)編排模型管理的單獨 BPM 。

圖 6. 服務(wù)分解

所有的 OOAD 都同標(biāo)識和定義服務(wù)有關(guān)；但是還需要具有更高層的觀點。此外，當(dāng) SOA 致力于比經(jīng)典開發(fā)項目層次更高的開發(fā)時，就有了發(fā)揮其他創(chuàng)造性思維的空間。

直接和間接業(yè)務(wù)分析
通過項目相關(guān)人員的會談和 CBM 來進(jìn)行 BPM 和 直接 需求分析是一個容易理解且非常合適的標(biāo)識候選服務(wù)的方法。

過去的經(jīng)驗表明，這條主要的途徑應(yīng)該通過補(bǔ)充 間接 技術(shù)來加以改進(jìn)。在選擇候選服務(wù)時，產(chǎn)品經(jīng)理和其他業(yè)務(wù)領(lǐng)導(dǎo)應(yīng)該進(jìn)行協(xié)商。例如，什么是計劃付款和開票模型？應(yīng)該商議假定使用正在構(gòu)建中的系統(tǒng)的企業(yè)的組織結(jié)構(gòu)圖。建議還考慮一下非 SOA 項目中任何現(xiàn)有的用況模型。用于對正在構(gòu)造的系統(tǒng)進(jìn)行營銷介紹的術(shù)語是另一個很好的關(guān)于服務(wù)操作候選者的來源（特別是動詞，很少關(guān)注營銷動詞！）。

域分解
在 Endrei 中定義的域分解、子系統(tǒng)分析、目標(biāo)模型創(chuàng)建和相關(guān)技術(shù)是 SOA 流程構(gòu)造方法或 服務(wù)概念化框架 （它是基于 Levi and Arsanjani 先前完成的工作構(gòu)建的）最有希望的提議。來自 SEI 的 FODA 工作也為這方面的討論做出了貢獻(xiàn)。

服務(wù)粒度
選擇正確的抽象級別是服務(wù)建模的一個關(guān)鍵問題。您常常會聽到 進(jìn)行粗粒度建模 的建議。這有點過于簡單化了。您應(yīng)該將其改為在不損失或損害相關(guān)性、一致性和完整性的情況下 盡可能地進(jìn)行粗粒度建模 。在任何 SOA 中，都有細(xì)粒度服務(wù)抽象的空間（假定有業(yè)務(wù)要求的話）。由于 SOA 并不等同于 Web 服務(wù)和 SOAP ，因此可以使用不同的協(xié)議綁定來訪問抽象級別不同的服務(wù)。另一種選擇就是將一些相關(guān)的服務(wù)捆綁成粗粒度的服務(wù)定義，這是門面模式的變種。

命名約定
應(yīng)該定義企業(yè)命名模式（ XML 名稱空間、 Java 包名、 Internet 域）。簡單的例子就是始終用名詞來命名服務(wù)，而用動詞來命名操作。這種最佳實踐來源于 OOAD 空間。

第一類 SOAD 原理

除了組合 OOAD 、 BPM 和 EA 技術(shù)之外，還有幾個重要的 SOAD 概念和方面有待充實：

• 服務(wù)分類和聚合
• 策略和方面
• 中間相遇流程
• 語義代理
• 服務(wù)獲取和知識代理

服務(wù)分類和聚合
服務(wù)有不同的用法和用途；例如，軟件服務(wù)可以不同于業(yè)務(wù)服務(wù)（如前面的 圖 5 所示）。此外，還可以將原子服務(wù)編排成級別更高、功能齊全的服務(wù)。

服務(wù)組合可以通過可執(zhí)行模型（如 BPEL 建模的模型）來加以簡化；這是傳統(tǒng)的建模工具和方法不能處理的事情。

策略和方面
服務(wù)具有語法、語義和 QoS 特征，所有這些都必須進(jìn)行建模；正式的接口契約必須涵蓋的比 Web 服務(wù)描述語言（ Web Services Description Language ， WSDL ）的多。因此， Web 服務(wù)策略（WS-Policy）框架 是一個重要的相關(guān)規(guī)范。

除了已經(jīng)制定的良好 體系結(jié)構(gòu)可跟蹤性 原則之外， 業(yè)務(wù)可跟蹤性 也是一個理想的品質(zhì)：應(yīng)該有可能將所有的運行時構(gòu)件直接與非技術(shù)領(lǐng)域?qū)＜铱梢岳斫獾恼Z言聯(lián)系起來。這對于直接在業(yè)務(wù)和服務(wù)層公開的抽象非常重要。 Sarbanes-Oxley (SOX) 法案（請參閱來自 Astor 的文章）是需要這種業(yè)務(wù)可跟蹤性的業(yè)務(wù)驅(qū)動程序的一個例子。

流程：中間相遇
在真實世界中，并沒有全新的項目，必須始終考慮遺留系統(tǒng)（ 遺留系統(tǒng) 是現(xiàn)有系統(tǒng)的同義詞）。因此，需要 中間相遇 的方法，而不是單純的自頂向下或自底向上的流程。

在設(shè)計取決于現(xiàn)有的 IT 環(huán)境而不是現(xiàn)在和將來的業(yè)務(wù)需要的情況下，自底向上的方法往往會導(dǎo)致不好的業(yè)務(wù)服務(wù)抽象。而自頂向下的方法可能會產(chǎn)生不足的非功能性需求特征，并且損害其他的體系結(jié)構(gòu)品質(zhì)因素（例如因域模型中缺乏標(biāo)準(zhǔn)化而導(dǎo)致的性能問題），另外，也會在服務(wù)和組件中產(chǎn)生不匹配的不良問題。

服務(wù)獲取和知識代理
這是一個知識管理和生命周期問題：如何成功地準(zhǔn)備好服務(wù)并且使其在概念化之后可以重用？

應(yīng)該將重用看作是標(biāo)識和定義服務(wù)最主要的推動標(biāo)準(zhǔn)之一。如果組件（或服務(wù)）不可能重用，就不無法將其作為服務(wù)進(jìn)行部署。它可以連接到另一個與企業(yè)體系結(jié)構(gòu)相關(guān)的服務(wù)，但是不能單獨作為一個服務(wù)而存在。

然而，即使從開始就計劃好了重用，還必須形式化服務(wù)獲取流程。由多個使用者使用服務(wù)是明確的 SOA 設(shè)計目標(biāo)。構(gòu)建時服務(wù)注冊中心（例如企業(yè) UDDI 目錄）可能能夠解決部分問題。

6. 示例：汽車工作訂單

汽車工作訂單（ Automotive Work Order ）描述了一家汽車維修公司管理其顧客運營的流程。我們將通過這個領(lǐng)域中的問題來闡述 SOAD 的觀點。

工作訂單 代表汽車服務(wù)公司和顧客之間的約定，以進(jìn)行一系列例行維修或應(yīng)急維修，例如例行 50,000 英里 服務(wù)，更換剎車片或輪胎，或者換油。

業(yè)務(wù)場景（如 圖 7 所示）如下：

• 當(dāng)顧客打電話預(yù)約時創(chuàng)建工作訂單。
• 為每個計劃的維修活動或操作創(chuàng)建一個獨立的工作訂單項，其中包括需要使用的零件、備件和勞務(wù)的詳細(xì)情況。
• 在安排預(yù)約之前確保所有必需的零件都有庫存。
• 需要為每個工作訂單項安排具有適當(dāng)?shù)难b備的維修間以及具備適當(dāng)?shù)臈l件的機(jī)器。
• 計算估計的總成本，接著顧客認(rèn)可該預(yù)約；或者方案終止，隨即取消工作訂單。
• 在預(yù)約之前，立即在選定的維修間裝配必需的零件、備件、工具和設(shè)備。
• 當(dāng)顧客到達(dá)時，進(jìn)行計劃的活動以及在檢查交通工具時顯得有必要的任何其他活動。
• 記錄所用的零件和備件的實際價值以及勞務(wù)。
• 在完成所有的維修時計算總費用。
• 創(chuàng)建發(fā)票并且將其交給顧客。

圖 7. 工作訂單的宏流示例

如果您將此作為一個獨立的應(yīng)用程序從頭開始創(chuàng)建，您就可能創(chuàng)建一組如 圖 8 所示的類。

圖 8. 工作訂單的類圖示例

如果您將工作訂單構(gòu)造為一個 OO 應(yīng)用程序，這些軟件對象將包含所有必需的業(yè)務(wù)規(guī)則，并且理解應(yīng)該遵循的業(yè)務(wù)流程。

然而，這種方法在實踐方面存在著一些缺點：

• 許多步驟涉及與現(xiàn)有遺留系統(tǒng)和數(shù)據(jù)庫（例如帳單編制、日程安排以及庫存系統(tǒng)）的連接，它們不可能遵循 OO 范式進(jìn)行設(shè)計（在這樣的情況下，應(yīng)用適配器或仲裁器會有所幫助）。
• 為了使系統(tǒng)盡可能地靈活，將一些規(guī)則外化是有幫助的，這樣就可以在不更改代碼的情況下修改流程或工作流。例如像下面這樣的規(guī)則：
• 標(biāo)準(zhǔn)的 24,000 英里 服務(wù)包括四公升油。只是在使用四升以上的油或顧客要求優(yōu)質(zhì)油（如合成油）時才應(yīng)該收取額外的郵費。
• 在遺留應(yīng)用程序中有一套工業(yè)標(biāo)準(zhǔn)為普通汽車維修活動進(jìn)行勞務(wù)估價。除非維修人員收取的費用超過該估價的 X% 并且報告產(chǎn)生差別的有根據(jù)的原因，否則顧客就應(yīng)該支付標(biāo)準(zhǔn)的勞務(wù)費。
• 如果超過估價的 Y% 以上，就應(yīng)該聯(lián)系顧客以進(jìn)行確認(rèn)。

SOAD 為這些問題提供了極好的解決方案。由于它基于相關(guān)的行為對服務(wù)進(jìn)行分組，而不是進(jìn)行封裝（行為及數(shù)據(jù)），所以這組服務(wù)與業(yè)務(wù)對象略有不同。

例如，您可能將工作訂單（ Work Order ）和工作訂單項（ Work Order Item ）一起分到工作訂單服務(wù)（ Work Order Services ），并且創(chuàng)建日程安排（ Scheduling ）、目錄（ Catalog ）和庫存（ Inventory ）服務(wù)。另外，因為沒有服務(wù)實例，所以沒有與服務(wù)之間的關(guān)系等價的東西。工作訂單的服務(wù)模型可能看起來如 圖 9 所示。

圖 9. 工作訂單的服務(wù)模型示例

與 OO 范式不同，這個模型并不表示功能系統(tǒng)。既沒有考慮流，也沒有描述業(yè)務(wù)事件或規(guī)則。在 SOA 范式中，在服務(wù)外面維護(hù)的業(yè)務(wù)流程編排決定了執(zhí)行服務(wù)調(diào)用的順序和時間。

從概念上講，從第一次顧客聯(lián)系到完成工作和帳單支付的整個業(yè)務(wù)表示單個宏觀層次的工作單元，并具有數(shù)天到數(shù)周不等的生命周期。畢竟，從企業(yè)的角度來看，工作單元會產(chǎn)生收入。

然而，實際出現(xiàn)的情況是在一段相對長的時間內(nèi)單獨發(fā)生的一系列集中活動，例如，定義活動、安排預(yù)約、選擇零件和備件、進(jìn)行維修活動等等。在 IT 系統(tǒng)中，沒有實際的 流程 會持續(xù)幾分鐘以上；事件之間的業(yè)務(wù)流程狀態(tài)以數(shù)據(jù)的形式保存在數(shù)據(jù)庫中。

這種類型的流程可以用狀態(tài)轉(zhuǎn)換模型（例如 UML 中可用的）很好地進(jìn)行表示。 圖 10 顯示了用有限狀態(tài)機(jī)（ finite-state machine ）方法如何對業(yè)務(wù)流進(jìn)行建模的示例。它是在業(yè)務(wù)流程進(jìn)行時工作訂單的狀態(tài)如何改變的高級視圖。

圖 10. 工作訂單的業(yè)務(wù)流程模型

業(yè)務(wù)流程編排集中于狀態(tài)之間的這些轉(zhuǎn)變。單獨的操作永久地記錄相關(guān)的狀態(tài)改變。

圖 11 顯示了部分編排的示例，其中包括 圖 10 所示的業(yè)務(wù)場景中的步驟 1 到 5 （例如，顧客定義他們的交通工作所需的工作，并且安排預(yù)約以進(jìn)行實施）。

圖 11. 工作訂單的業(yè)務(wù)交互模型

7. 總結(jié)和展望

在本文中，我們已經(jīng)討論和激發(fā)了對創(chuàng)新的中間相遇的方法的需求，這種方法搭建了業(yè)務(wù)和 IT 之間的橋梁，并且支持 SOA 項目的分析和設(shè)計階段。我們還提議將這種新的交叉學(xué)科的 SOAD 方法作為一個整體的建模規(guī)則，它以現(xiàn)在構(gòu)建良好且廣為贊譽(yù)的 OOAD 、 EA 、和 BPM 為基礎(chǔ)。

在詳細(xì)定義 SOAD 表示法和流程的同時，還確定了關(guān)鍵的原理，比如服務(wù)概念化（或標(biāo)識）、服務(wù)分類或聚合、策略和方面、中間相遇流程、語義代理和服務(wù)獲取（以供重用）。

SOAD 需要增強(qiáng)現(xiàn)有的軟件開發(fā)方法，進(jìn)一步提高企業(yè)應(yīng)用程序開發(fā)項目的可用性和適用性。隨著時間的推移，還將發(fā)展相關(guān)的最佳實踐。

我們還認(rèn)識到， UML 在流程的表示法選擇方面將繼續(xù)占支配地位；可能需要進(jìn)行增強(qiáng)以滿足更廣泛的 SOAD 的要求。

完成 SOAD 方法的下一步就是定義所需的端到端流程和表示法，復(fù)審活動中的角色和它們的責(zé)任，并且繼續(xù)檢查所提議的方法在項目中的有效性。