最初的面向服務(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īng)驗表明，必須將抽象的級別提升到公司處理的 業(yè)務(wù)領(lǐng)域，從而將整個企業(yè) IT 前景都納入考慮的范疇。
正如 Mark Colan 在文章 “面向服務(wù)的體系結(jié)構(gòu)擴展 Web 服務(wù)的前景，第 1 部分”中介紹的，SOA 是一種新興的企業(yè)結(jié)構(gòu)形式，可以用于設(shè)計下一代企業(yè)應(yīng)用程序。SOA 方法在有力地加強已經(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)新的原理來對其加以補充。
引言
面向服務(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 方法使成功地進行 SOA 開發(fā)更容易，我們稱之為
面向服務(wù)的分析與設(shè)計（Service-Oriented Analysis and Design，SOAD），它還有待正式定義。我們還只是剛剛跨入 SOAD 的殿堂。
面向服務(wù)的概念
在發(fā)現(xiàn)新的商機或威脅的預(yù)期下，SOA 體系結(jié)構(gòu)形式旨在提供企業(yè)業(yè)務(wù)解決方案，這些業(yè)務(wù)解決方案可以
按需擴展或改變。SOA 解決方案由可重用的服務(wù)組成，帶有定義良好且符合標(biāo)準(zhǔn)的已發(fā)布接口。SOA 提供了一種機制，通過這種機制，可以集成現(xiàn)有的遺留應(yīng)用程序，而不管它們的平臺或語言。
從概念上講，SOA 中有三個主要的抽象級別：
從建模的觀點來看，由此帶來的挑戰(zhàn)是如何描述設(shè)計良好的操作、服務(wù)和流程抽象的特征以及如何系統(tǒng)地構(gòu)造它們。這些相關(guān)問題都是當(dāng)前行業(yè)內(nèi)和學(xué)術(shù)界最常討論
的問題。據(jù)我們所知，最近幾乎所有的 SOA
項目或?qū)ｎ}研討會都將這樣的服務(wù)建模方面作為重要的主題，并引起了許多的爭論。因此，讓我們更近地作一番審視。
為什么 BPM、EA 和 OOAD 還不夠？
早期的 SOA 實現(xiàn)項目經(jīng)驗表明，諸如 OOAD、EA 和 BPM 這樣的現(xiàn)有開發(fā)流程和表示法僅僅涵蓋支持 SOA 范式所需的部分要求。SOA 方法在加強已經(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ū)別，而建模活動通常就是在其上進行的。
圖 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，F(xiàn)ODA）和
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)進行自底向上的分析。因此，對現(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 的增強；
按需操作系統(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 將流程的范圍從分析擴展到實現(xiàn)。這樣的可執(zhí)行模型引發(fā)了一系列的新問題，其中包括：
- 哪些方面應(yīng)該用 BPEL 描述，哪些方面應(yīng)該用 WSDL 描述？流程模型和傳統(tǒng)的編程模型之間的區(qū)別在什么地方？
- 如何將非功能性要求和服務(wù)質(zhì)量特征這樣的方面加入模型之中？
- 同更傳統(tǒng)的編碼（例如在 J2EE 中）相比，在 BPEL 引擎的編程語言擴展中執(zhí)行多少邏輯？
- 如何評定可執(zhí)行流程模型的質(zhì)量，其應(yīng)用的最佳實踐是什么？
- 什么工作角色進行 BPEL 流管理；是業(yè)務(wù)專家（分析人員），還是開發(fā)角色（軟件架構(gòu)師）？
必須利用所有現(xiàn)有的 BPM 方法作為 SOAD 的起點；然而，必須使用流程模型中用于驅(qū)動
候選服務(wù)和它們的操作的附加技術(shù)來對其加以補充。此外，SOAD 中的流程建模必須與設(shè)計層用況建模保持同步，并且必須給出與 BPEL 有關(guān)的問題的答案。
OO 范式與面向服務(wù) (SO) 范式
OO 分析是一種非常強大且廣為贊譽的方法，同樣，SOAD 應(yīng)該盡可能多地利用 OO 分析技術(shù)。要將 OO 分析成功地應(yīng)用于 SOA 項目，您就必須一次分析多個系統(tǒng)。用況模型必須繼續(xù)扮演重要的角色。然而，SOAD 必須主要是
流程，而不是
用戶驅(qū)動的。因此，SOAD 需要 BPM 和用況建?；顒又g的強鏈接。
在
設(shè)計層，
OO 的目標(biāo)是能夠進行快速而有效的設(shè)計、開發(fā)以及執(zhí)行靈活且可擴展的應(yīng)用程序。對象是軟件構(gòu)造，其行為就像它們建模的真實世界的實體。例如，顧客
(Customer) 將有名稱和聯(lián)系信息，并且還可能有一個或多個與之相關(guān)的帳戶對象。從 OO 的角度看，每件事情都是對象。
OO的基本原則是：
- 封裝：軟件對象就是包含模擬真實世界的對象的物理屬性（數(shù)據(jù)）和功能（行為）的離散包。例如，帳戶對象保持收支平衡并且包含平衡中的借貸機制。
- 信息隱藏：結(jié)構(gòu)良好的對象有簡單的接口，并且不向外界顯漏任何內(nèi)部機制。真實世界信息隱藏的例子是，您不需要詳細(xì)了解汽車的工作原理就能夠駕駛它。
- 類和實例：
類是定義特定類型的軟件對象具有什么類型的屬性和行為的模板，而
實例是具有這些屬性值的個別對象。創(chuàng)建類的新實例稱為
實例化。利用生物學(xué)進行類比，人就是一個類。所有的人都具有一些屬性，比如身高、體重、頭發(fā)和眼睛顏色等等。我們中的每個人都是這個類 HumanBeing 的實例，具有一些特定的身高、體重以及其他的屬性值。類是一直存在的，而實例具有有限的生命周期。
- 關(guān)聯(lián)和繼承：
在 OO 中，表達(dá)類和對象之間的關(guān)聯(lián)的能力是一個關(guān)鍵的概念；繼承是關(guān)聯(lián)的強形式，用于表達(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ù)語描述兩個或兩個以上的類接受相同的消息但是以不同的方式進行實現(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)用程序的漸進式開發(fā)，每次實現(xiàn)一個業(yè)務(wù)場景或用況。像 IBM WebSphere Studio Application Developer 這樣的工具有助于開發(fā)人員快速地構(gòu)造和測試 OO 應(yīng)用程序。
- OO 運行時環(huán)境，例如由 Java 虛擬機提供的，提供應(yīng)用程序服務(wù)（如垃圾收集（刪除因使用它們的對象已經(jīng)被丟棄而不再使用的資源））以及框架（如 J2EE）來為駐留在不同的服務(wù)器上的對象提供相互通信的機制。
目前與 SO 有關(guān)的 OO 設(shè)計實踐的主要問題在于，它的粒度級別集中在類級，對于業(yè)務(wù)服務(wù)建模來說，這樣的抽象級別太低了。諸如繼承這樣的強關(guān)聯(lián)產(chǎn)生了相關(guān)方之間一定程度的
緊耦合（因而具有依賴性）。與此相反，SO 范式試圖通過
松耦合來促進靈活性和敏捷性。目前，在 SOA 中還沒有服務(wù)
實例的跨平臺繼承支持和一流的表示法來避免需要處理服務(wù)生命周期維護管理問題（如遠(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）和概要加以增強——自然成為 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è)計的組件。
SOAD 原理
在這一部分中，我們將更詳細(xì)地描述 SOAD 的需求，并且開始確定它的主題和原理。目的是將關(guān)于這個主題的討論引到進一步的設(shè)計工作。進一步的工作無疑需要形式化 SOAD 方法。
SOAD 必須提供什么？
已經(jīng)為 SOAD 確定了下列需求：
- 正如任何其他的項目和方法一樣，必須正式（至少半正式）地定義
流程和
表示法。通過選擇和組合 OOAD、BPM 和 EA 原理，就可以在需要時確定額外的原理。
- 必須有結(jié)構(gòu)化的方法來概念化服務(wù)：
- OOAD 為我們提供了應(yīng)用程序?qū)由系念惡蛯ο?，?BPM 具有事件驅(qū)動的流程模型。SOAD 需要將它們結(jié)合在一起。
- 方法不再是面向用況的，而是由業(yè)務(wù)事件和流程驅(qū)動的。用況建模是在更低的層次上作為第二步進行的。
- 方法包括語法、語義和策略。這就需要特別的組合、語義代理和運行時發(fā)現(xiàn)。
- SOAD 必須提供定義良好的品質(zhì)因素和最佳實踐（例如回答粒度問題）。必須回答 BPEL 提出的角色問題。例如，誰為哪部分工作負(fù)責(zé)：是開發(fā)人員、架構(gòu)師，還是分析人員？
- SOAD 活動還必須回答這樣的問題：什么
不是好的服務(wù)？例如：不可重用的任何東西都不可能成為好的一流 SOA 成員（即服務(wù)）。另一個例子就是帶有挑戰(zhàn)性的非功能要求的嵌入式實時系統(tǒng)，它們不能承受任何 XML 處理開銷。
- SOAD 必須易于進行端到端建模，并且有全面的工具支持。假如 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）、
讀?。≧ead）、
更新（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 建?；顒犹峁┢瘘c。但是正如我們在前面提到的，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 來進行 BPM 和
直接需求分析是一個容易理解且非常合適的標(biāo)識候選服務(wù)的方法。
過去的經(jīng)驗表明，這條主要的途徑應(yīng)該通過補充
間接技
術(shù)來加以改進。在選擇候選服務(wù)時，產(chǎn)品經(jīng)理和其他業(yè)務(wù)領(lǐng)導(dǎo)應(yīng)該進行協(xié)商。例如，什么是計劃付款和開票模型？應(yīng)該商議假定使用正在構(gòu)建中的系統(tǒng)的企業(yè)的組織
結(jié)構(gòu)圖。建議還考慮一下非 SOA
項目中任何現(xiàn)有的用況模型。用于對正在構(gòu)造的系統(tǒng)進行營銷介紹的術(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)鍵問題。您常常會聽到
進行粗粒度建模的建議。這有點過于簡單化了。您應(yīng)該將其改為在不損失或損害相關(guā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 特征，所有這些都必須進行建模；正式的接口契約必須涵蓋的比 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ù)進行部署。它可以連接到另一個與企業(yè)體系結(jié)構(gòu)相關(guān)的服務(wù)，但是不能單獨作為一個服務(wù)而存在。
然而，即使從開始就計劃好了重用，還必須形式化服務(wù)獲取流程。由多個使用者使用服務(wù)是明確的 SOA 設(shè)計目標(biāo)。構(gòu)建時服務(wù)注冊中心（例如企業(yè) UDDI 目錄）可能能夠解決部分問題。
示例：汽車工作訂單
汽車工作訂單（Automotive Work Order）描述了一家汽車維修公司管理其顧客運營的流程。我們將通過這個領(lǐng)域中的問題來闡述 SOAD 的觀點。
工作訂單代表汽車服務(wù)公司和顧客之間的約定，以進行一系列例行維修或應(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件的機器。
- 計算估計的總成本，接著顧客認(rèn)可該預(yù)約；或者方案終止，隨即取消工作訂單。
- 在預(yù)約之前，立即在選定的維修間裝配必需的零件、備件、工具和設(shè)備。
- 當(dāng)顧客到達(dá)時，進行計劃的活動以及在檢查交通工具時顯得有必要的任何其他活動。
- 記錄所用的零件和備件的實際價值以及勞務(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 范式進行設(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)為普通汽車維修活動進行勞務(wù)估價。除非維修人員收取的費用超過該估價的 X% 并且報告產(chǎn)生差別的有根據(jù)的原因，否則顧客就應(yīng)該支付標(biāo)準(zhǔn)的勞務(wù)費。
- 如果超過估價的 Y% 以上，就應(yīng)該聯(lián)系顧客以進行確認(rèn)。
SOAD 為這些問題提供了極好的解決方案。由于它基于相關(guān)的行為對服務(wù)進行分組，而不是進行封裝（行為及數(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ù)外面維護的業(yè)務(wù)流程編排決定了執(zhí)行服務(wù)調(diào)用的順序和時間。
從概念上講，從第一次顧客聯(lián)系到完成工作和帳單支付的整個業(yè)務(wù)表示單個宏觀層次的工作單元，并具有數(shù)天到數(shù)周不等的生命周期。畢竟，從企業(yè)的角度來看，工作單元會產(chǎn)生收入。
然而，實際出現(xiàn)的情況是在一段相對長的時間內(nèi)單獨發(fā)生的一系列集中活動，例如，定義活動、安排預(yù)約、選擇零件和備件、進行維修活動等等。在 IT 系統(tǒng)中，沒有實際的
流程會持續(xù)幾分鐘以上；事件之間的業(yè)務(wù)流程狀態(tài)以數(shù)據(jù)的形式保存在數(shù)據(jù)庫中。
這種類型的流程可以用狀態(tài)轉(zhuǎn)換模型（例如 UML 中可用的）很好地進行表示。
圖 10顯示了用有限狀態(tài)機（finite-state machine）方法如何對業(yè)務(wù)流進行建模的示例。它是在業(yè)務(wù)流程進行時工作訂單的狀態(tài)如何改變的高級視圖。
圖 10. 工作訂單的業(yè)務(wù)流程模型
業(yè)務(wù)流程編排集中于狀態(tài)之間的這些轉(zhuǎn)變。單獨的操作永久地記錄相關(guān)的狀態(tài)改變。
圖 11顯示了部分編排的示例，其中包括
圖 10所示的業(yè)務(wù)場景中的步驟 1 到 5（例如，顧客定義他們的交通工作所需的工作，并且安排預(yù)約以進行實施）。
圖 11. 工作訂單的業(yè)務(wù)交互模型
總結(jié)和展望
在
本文中，我們已經(jīng)討論和激發(fā)了對創(chuàng)新的中間相遇的方法的需求，這種方法搭建了業(yè)務(wù)和 IT 之間的橋梁，并且支持 SOA
項目的分析和設(shè)計階段。我們還提議將這種新的交叉學(xué)科的 SOAD 方法作為一個整體的建模規(guī)則，它以現(xiàn)在構(gòu)建良好且廣為贊譽的 OOAD、EA、和
BPM 為基礎(chǔ)。
在詳細(xì)定義 SOAD 表示法和流程的同時，還確定了關(guān)鍵的原理，比如服務(wù)概念化（或標(biāo)識）、服務(wù)分類或聚合、策略和方面、中間相遇流程、語義代理和服務(wù)獲?。ㄒ怨┲赜茫?。
SOAD 需要增強現(xiàn)有的軟件開發(fā)方法，進一步提高企業(yè)應(yīng)用程序開發(fā)項目的可用性和適用性。隨著時間的推移，還將發(fā)展相關(guān)的最佳實踐。
我們還認(rèn)識到，UML 在流程的表示法選擇方面將繼續(xù)占支配地位；可能需要進行增強以滿足更廣泛的 SOAD 的要求。
完成 SOAD 方法的下一步就是定義所需的端到端流程和表示法，復(fù)審活動中的角色和它們的責(zé)任，并且繼續(xù)檢查所提議的方法在項目中的有效性。
參考資料
 |
|
作者簡介
|
| | Olaf
Zimmermann 是 IBM worldwide Applied Web Services 組的顧問 IT
構(gòu)架師。他在分布式計算、面向服務(wù)體系結(jié)構(gòu)、Web 服務(wù)/XML 和 J2EE 方面頗有專長。在過去的幾年里，Olaf 指導(dǎo)了大量與 Web
服務(wù)有關(guān)的交流項目，包括幾本產(chǎn)品參考書。他是 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
合作，涉及的領(lǐng)域非常廣泛，其中包括產(chǎn)品開發(fā)、技術(shù)預(yù)售咨詢、教學(xué)以及系統(tǒng)集成。Olaf 在位于德國 Braunschweig 的
Technical University 獲得計算機科學(xué)學(xué)位。您可以通過 ozimmer@de.ibm.com與他聯(lián)系。
|
|
| | Pal
Krogdahl 是一名解決方案架構(gòu)師，在 IGS 的 IBM Business Consulting Services（位于瑞典）工作。他從
1998 年開始就職于
IBM，涉及了多個領(lǐng)域，比如軟件開發(fā)、售前技術(shù)咨詢和解決方案體系結(jié)構(gòu)。他擅長的領(lǐng)域包括分布式計算、中間件和應(yīng)用程序服務(wù)體系結(jié)構(gòu)，主要集中在
EAI 和 SOA。Pal 最近撰寫了一些范圍廣泛的文章，探討的主題有基于 SOA 的 EA、以及它們與 IBM
用于電子商務(wù)和按需操作系統(tǒng)環(huán)境的模式的關(guān)系。到目前為止，他已經(jīng)完成了 IBM International Technical Support
Organization 的一些高級培訓(xùn)，在該組織中，他同人合著了一些與 WebSphere 有關(guān)的紅皮書，這些紅皮書主要集中在 Web
服務(wù)和 SOA 方面，例如 Patterns: Service-Oriented Architecture and Web Services(ISBN 073845317X)。在過去的 18 個月里，他一直在向 IBM 內(nèi)外的技術(shù)人員介紹 Web 服務(wù)和基于 SOA 的按需操作環(huán)境的實現(xiàn)方面的知識。您可以通過
pal.krogdahl@se.ibm.com與他聯(lián)系。
|
|
| | Clive
Gee 是一名高級解決方案架構(gòu)師，工作在 IBM Enterprise Integration Services 部。他于 1976 年加入
IBM Europe 并于 1997 年調(diào)到 IBM US。1990 年，作為創(chuàng)立 IBM European Object
Technology Practice 的一員，他是 IBM 中第一位 OO 的支持者。從那以后，他獲得了領(lǐng)導(dǎo)企業(yè) OO
交流項目的大量實踐經(jīng)驗，涉及多個行業(yè)（如公用事業(yè)、金融業(yè)、運輸業(yè)、零售業(yè)和電信業(yè)）的復(fù)雜系統(tǒng)集成和應(yīng)用程序開發(fā)。目前，他正忙于為一個重要的美國客
戶配置部署 SOA 解決方案。Clive 從蘇格蘭的 University of Stirling 大學(xué)獲得理論物理博士學(xué)位。您可以通過 clive@us.ibm.com與他聯(lián)系。
|