本文來(lái)自于 Rational Edge：IBM Rational Unified Process Update for Service Oriented Architecture（RUP Update for SOA）與 UML Profile for Software Services 的 Rational Software Architect 實(shí)現(xiàn)的結(jié)合提供了建模方法，以及一組用于面向服務(wù)體系結(jié)構(gòu)模型解決方案的體系結(jié)構(gòu)和設(shè)計(jì)的最佳實(shí)踐。本文描述了背景、范圍和此新功能背后的一些概念。
三年前，我們這些處于 Rational Software Corporation 前沿的一組人坐下來(lái)撰寫(xiě)了一篇有關(guān)利用面向服務(wù)的體系結(jié)構(gòu)（service-oriented architecture，SOA）式樣1來(lái)開(kāi)發(fā)解決方案問(wèn)題的文章，并且從那以后發(fā)生了許多事。我們所面臨的一個(gè)問(wèn)題是 Rational Software 有一組建模工具，但沒(méi)有 IDE 來(lái)實(shí)際地開(kāi)發(fā)我們所建模的服務(wù)實(shí)現(xiàn)。隨著 IBM 對(duì) Rational 的收購(gòu)，我們現(xiàn)在有了一個(gè)世界級(jí)的 WebSphere Studio Application Developer（現(xiàn)在是 Rational Application Developer，或 RAD）形式的 IDE。我們還面臨著一個(gè)問(wèn)題，許多關(guān)于 SOA 的思想都不成熟，并且許多是被錯(cuò)誤驅(qū)使的 —— 一個(gè)我們?cè)谖恼轮锌紤]的問(wèn)題。既然支持 SOA 的 IBM 平臺(tái)已經(jīng)相當(dāng)?shù)爻墒欤⑶椅覀兊拈_(kāi)發(fā)工具已經(jīng)增加了按照靈活快捷的方式開(kāi)發(fā)服務(wù)的功能，我們決定再次訪(fǎng)問(wèn)我們?cè)谇懊嫖恼轮懈爬ǖ姆?wù)設(shè)計(jì)的概念。
此討論的結(jié)果是一個(gè)新的理解：我們的價(jià)值不是在表現(xiàn) WSDL（Web 服務(wù)描述語(yǔ)言）和 XML 的所有三角地的模型開(kāi)發(fā)，而是允許設(shè)計(jì)人員和架構(gòu)師用恰當(dāng)?shù)墓δ苤付ㄇ‘?dāng)?shù)姆?wù)并實(shí)現(xiàn) SOA 式樣的潛在益處。 此理解將我們引向一些長(zhǎng)遠(yuǎn)的討論，這些討論是關(guān)于 1) 用來(lái)表現(xiàn)服務(wù)模型的恰當(dāng)抽象級(jí)別，和 2) SOA 式樣的開(kāi)發(fā)影響 Rational Unified Process?，或 RUP? 的方式。
本文的前三分之一介紹了我們?yōu)樽兏O(shè)置的范圍，包括我們所關(guān)注的需求。接下來(lái)我將描述一些關(guān)鍵的主題，我們將這些主題用作對(duì) RUP 的變更框架，及用于支持面向服務(wù)的解決方案開(kāi)發(fā)的 Rational Software Architect（RSA）補(bǔ)充。最后，我將描述一些在我們的思想中使用的情境，這些情境隨時(shí)間得到了改進(jìn)，但還需要一些關(guān)鍵客戶(hù)的驗(yàn)證。
設(shè)置恰當(dāng)?shù)姆秶?/font>
我們決定不僅開(kāi)發(fā)一個(gè)新的用于 RSA 的建模概要文件，還要開(kāi)發(fā)添加到 RUP 中的指導(dǎo)，為幫助實(shí)踐者在預(yù)想和開(kāi)發(fā)面向服務(wù)的解決方案中實(shí)際地使用工具。
然而，眾所周知，對(duì)于任何項(xiàng)目最關(guān)鍵的方面之一是設(shè)置恰當(dāng)?shù)姆秶禾。蜁?huì)做出對(duì)任何人沒(méi)有實(shí)際意義的東西（除了可能能夠拿出您自己的要獲得利益的目的），太大，就很可能要煮沸整個(gè)海洋。所以我們建立了以下標(biāo)準(zhǔn)：
- 我們開(kāi)發(fā)的模型必須要處于當(dāng)前實(shí)現(xiàn)技術(shù)和標(biāo)準(zhǔn)之上的抽象級(jí)別上（WS-* 規(guī)范，就是各種 Web 服務(wù)規(guī)范），然而，還要將 SOA 的概念作為頭等的要素。
- 結(jié)果的模型必須是可擴(kuò)展的，可以考慮到相關(guān)的額外規(guī)范，如安全性、服務(wù)質(zhì)量，可管理性，等等。
- 模型必須在 IBM Rational Software Modeler（RSM）和 IBM Rational Software Architect（RSA）中實(shí)現(xiàn)，最初作為一個(gè) UML 概要文件。
- 指導(dǎo)不得不向基礎(chǔ) RUP 添加具體的 SOA 概念。然而，我們想要在現(xiàn)有的 RUP 中利用盡可能多的東西，因此，為了使更新很容易地添加到現(xiàn)有的 RUP 配置中，我們最初選擇不改變?nèi)魏未嬖诘臇|西。
- 我們的工作應(yīng)該考慮在提供 SOA 指導(dǎo)中 IBM 已經(jīng)完成的工作，如 IBM Global Services SOMA 技術(shù)。2
因此我們定義了一組三個(gè)可交付使用的標(biāo)準(zhǔn)，每一個(gè)都可以從 IBM developerWorks 中得到：
- 描述 UML Profile for Software Services 的文檔，3它依照的是 OMG 概要文件文檔的式樣。
- 實(shí)現(xiàn) UML Profile for Software Services 的 RSM 或 RSA 插件，4它使模型構(gòu)建于工具之中并符合上面的概要文件。
- 包含了所有關(guān)于 SOA 體系結(jié)構(gòu)5和設(shè)計(jì)主題指導(dǎo)的 RUP 插件，它提供了關(guān)于依照上面的概要文件開(kāi)發(fā)服務(wù)設(shè)計(jì)模型的具體指導(dǎo)。
幸虧 RSM 和 RSA 工具具有可擴(kuò)展機(jī)制，我們才能夠不僅交付 UML Profile for Software Services，還交付一個(gè)模板模型（當(dāng)您選擇 File -> New -> UML Model 時(shí)可用）和兩個(gè)添加到 Sample Gallery 中的示例。
這是我們考慮的一個(gè)合理的標(biāo)準(zhǔn)集合并可以交付。所以讓我們看看在 2005 年 5 月 IBM developerWorks 中實(shí)際交付的內(nèi)容。
關(guān)鍵概念和主題
首先，什么是 SOA？流行著許多定義，但讓我們以一個(gè)軟件工程師的角度去看，簡(jiǎn)單地說(shuō) SOA 是一個(gè)“體系結(jié)構(gòu)式樣”的實(shí)例。這又引出一個(gè)問(wèn)題，什么是體系結(jié)構(gòu)式樣？這里有一個(gè)來(lái)自 Roy Thomas Fielding 的很好的定義：
體系結(jié)構(gòu)式樣等同于限制體系結(jié)構(gòu)要素的作用或特性及任何體系結(jié)構(gòu)中符合該式樣的那些要素之間的容許關(guān)系的體系結(jié)構(gòu)約束。6
舉個(gè)例子，一個(gè)已編制的體系結(jié)構(gòu)式樣是管道和過(guò)濾器樣式，它包含了將管道作為連接器來(lái)關(guān)聯(lián)過(guò)濾器的獨(dú)立的要素。在管道連接的兩個(gè)過(guò)濾器之間存在著數(shù)據(jù)類(lèi)型必須遵照的具體的約束，且存在著一些令式樣適應(yīng)于某些環(huán)境的特征。
知道了這些，我們可以開(kāi)始列舉 SOA 的體系結(jié)構(gòu)要素，以及具體到其式樣的關(guān)系和約束。有了這個(gè)有用的體系結(jié)構(gòu)式樣的定義，F(xiàn)ielding 還提供了一個(gè)非常及時(shí)的建議：
設(shè)計(jì)這個(gè)強(qiáng)意詞是普遍發(fā)生的。至少軟件行業(yè)中的某些此種行為還缺乏對(duì)為什么已知的體系結(jié)構(gòu)約束集合是有用的的理解。換句話(huà)說(shuō)，在選擇復(fù)用那些體系結(jié)構(gòu)時(shí)，好的軟件體系結(jié)構(gòu)背后的原因?qū)υO(shè)計(jì)人員不是顯然的。7
我們希望通過(guò)提供 RUP 中的具體附加內(nèi)容集的簡(jiǎn)明及時(shí)的指導(dǎo)來(lái)緩和此精確的行為。此指導(dǎo)描述了體系結(jié)構(gòu)的式樣、要素和關(guān)系，以及在整個(gè)開(kāi)發(fā)生命周期中他們是如何被識(shí)別、指定和管理的。同事還要注意，通常體系結(jié)構(gòu)的目標(biāo)，特別是體系結(jié)構(gòu)建模，提供了一個(gè)適當(dāng)?shù)某橄蠹?jí)別，在此級(jí)別上，可以容易地識(shí)別體系結(jié)構(gòu)的要素，并且在不隱藏那些應(yīng)該添加到針對(duì)實(shí)現(xiàn)更低層細(xì)化級(jí)別的細(xì)節(jié)的情況下，對(duì)要素進(jìn)行控制。
在下面幾個(gè)部分中，我們將討論針對(duì) SOA 的 RUP 更新中的一些關(guān)鍵主題 —— 特別是，要素、關(guān)系和每個(gè)主題引入的約束。
服務(wù)的識(shí)別和說(shuō)明
我們的標(biāo)準(zhǔn)規(guī)定，關(guān)鍵的 SOA 概念必須作為頭等要素通過(guò)模型表現(xiàn)出來(lái)，因此這些關(guān)鍵的概念是什么？如您所預(yù)想的，其中一個(gè)概念就是服務(wù)本身，然而，與其作為模型建立的中心，還不如實(shí)際地成為次要的要素（不是重要的，但作為模型的要素，因?yàn)樗荒塥?dú)立存在）。要構(gòu)建一個(gè)表現(xiàn) WSDL 所定義服務(wù)的服務(wù)模型，我們必須首先開(kāi)發(fā)服務(wù)規(guī)范以及服務(wù)供應(yīng)商。
服務(wù)規(guī)范有三個(gè)規(guī)范要素，所有都同樣重要，雖然在某種情況下，根據(jù)服務(wù)的建模類(lèi)型可對(duì)它們進(jìn)行選擇：
-
結(jié)構(gòu)規(guī)范。它可以用標(biāo)準(zhǔn)的 UML 或 Java 接口考慮。其定義了可以調(diào)用的操作和由這些操作銷(xiāo)毀或創(chuàng)造出的消息。
-
行為規(guī)范。它表示出服務(wù)客戶(hù)和所指定服務(wù)之間的任意預(yù)期的有意義的協(xié)議或會(huì)話(huà)。例如，服務(wù)也許要求您在調(diào)用另一個(gè)操作之前先登錄，這稱(chēng)為偽對(duì)話(huà)服務(wù)。服務(wù)也許還要求客戶(hù)實(shí)現(xiàn)特殊的接口，以便接口可以被回調(diào)，且協(xié)議可以展示這點(diǎn)。
-
策略規(guī)范。它表示服務(wù)的策略主張和約束。策略主張可能包括安全性、可管理性等等。
那么，例如，如果我們?cè)O(shè)想一個(gè)訂單管理服務(wù)，我們也許期望看到列出“下訂單”、“取消訂單”和“更新訂單”作為可用操作的結(jié)構(gòu)規(guī)范。此訂購(gòu)服務(wù)的行為規(guī)范可能會(huì)說(shuō)明，您如何不能更新或取消沒(méi)有訂購(gòu)的訂單，或者在您取消訂單之后就不能再對(duì)其更新。最后，策略規(guī)范可能要求加密訂單的某些要素，指示要使用的加密技術(shù)、要使用的證書(shū)等等。
我們?cè)?RUP 中已經(jīng)交付的指導(dǎo)的一個(gè)方面是一組技術(shù)（新的行為識(shí)別服務(wù)中進(jìn)行了描述），用來(lái)從業(yè)務(wù)過(guò)程模型、用例或現(xiàn)有的各種清單資產(chǎn)中確定服務(wù)。這種行為和這些技術(shù)集允許架構(gòu)師和設(shè)計(jì)人員制造出候選服務(wù)模型，這些模型是經(jīng)常用于描述用來(lái)實(shí)現(xiàn)過(guò)程或需求集的“理想化”服務(wù)的服務(wù)規(guī)范。
我們介紹術(shù)語(yǔ)“候選服務(wù)”，因?yàn)樵S多這些服務(wù)經(jīng)常不得不被重構(gòu)來(lái) 1) 符合現(xiàn)有服務(wù)，2) 適應(yīng)現(xiàn)有功能體系結(jié)構(gòu)的框架，或者 3) 被分開(kāi)以考慮更細(xì)致或并行的開(kāi)發(fā)。
管理服務(wù)組合
SOA 式樣解決方案的開(kāi)發(fā)的一個(gè)主要優(yōu)點(diǎn)是在開(kāi)發(fā)一個(gè)應(yīng)用程序時(shí)（收集需求、設(shè)計(jì)并實(shí)現(xiàn)解決方案，且管理項(xiàng)目），不用將應(yīng)用程序作為一個(gè)固定的邊界考慮。在 SOA 中，我們看到的應(yīng)用程序是一個(gè)動(dòng)態(tài)的實(shí)體，一個(gè)滿(mǎn)足特殊業(yè)務(wù)需求集的服務(wù)配置。要達(dá)到這種狀態(tài)，我們顯然需要在企業(yè)中設(shè)計(jì)、實(shí)現(xiàn)并管理作為可用功能組合的服務(wù)集。
該需求就是為什么我們指定前面提到的新的識(shí)別服務(wù)行為的原因。我們不僅是在識(shí)別候選服務(wù)時(shí)考慮組合，我們還由服務(wù)的原始形式進(jìn)行重構(gòu)以適應(yīng)組合中服務(wù)的形式。該級(jí)別的復(fù)用不僅應(yīng)該得到設(shè)計(jì)工具的支持，不僅應(yīng)該得到關(guān)于服務(wù)組合的信息存儲(chǔ)庫(kù)的支持，還應(yīng)該 —— 最重要的 —— 得到以恰當(dāng)?shù)姆绞介_(kāi)發(fā)恰當(dāng)?shù)姆?wù)時(shí)指導(dǎo)參與者的過(guò)程支持。
這確實(shí)導(dǎo)致了一個(gè)特別的問(wèn)題，在傳統(tǒng)情況下，我們關(guān)注軟件開(kāi)發(fā)生命周期，視其為一個(gè)由項(xiàng)目限制時(shí)間的過(guò)程，項(xiàng)目受到解決方案的某些離散部分的開(kāi)發(fā)時(shí)間的限制。就服務(wù)組合本身而言（關(guān)于已安裝的服務(wù)的元數(shù)據(jù)和考慮復(fù)用的設(shè)計(jì)模型的組合），我們看到這樣一個(gè)生命周期，它橫切了使用它并對(duì)它做出貢獻(xiàn)的單個(gè)項(xiàng)目，如圖 1 所示。
圖 1：服務(wù)組合生命周期
圖 1 所示的服務(wù)組合管理過(guò)程是一個(gè)不斷進(jìn)展的活動(dòng)。注意單個(gè)項(xiàng)目與服務(wù)組合交互的方式，在項(xiàng)目的細(xì)化階段從單個(gè)的項(xiàng)目中提取需要組合的服務(wù)，在項(xiàng)目的構(gòu)造階段組合的服務(wù)被實(shí)現(xiàn)。
劃分面向服務(wù)的解決方案
不管多大規(guī)模的模型（或?qū)嶋H上是要素的任意集合）都存在的一個(gè)問(wèn)題就是如何管理模型，如何對(duì)要素分類(lèi)，以及如何以任何檢查模型的不同涉眾都可以理解的方式來(lái)組織要素。
服務(wù)模型的此種結(jié)構(gòu)在服務(wù)的識(shí)別和服務(wù)的管理過(guò)程中變得重要起來(lái)。讓我們暫時(shí)考慮 UML 1.x 中的模型管理 —— 包 —— 的典型方法。關(guān)于包的問(wèn)題是它們通過(guò)所有權(quán)或聚合來(lái)管理模型要素，換句話(huà)說(shuō)，一旦將一個(gè)要素放入單個(gè)的包中，不同包中的要素可以對(duì)其訪(fǎng)問(wèn)但不能將其“放置”在一個(gè)以上的包中。此刻，對(duì)于我們這些具有程序設(shè)計(jì)語(yǔ)言背景的人來(lái)說(shuō)，這似乎不是主要問(wèn)題，它反映出包、模塊或命名空間在語(yǔ)言中工作的方式。
然而，我們真正需要表示的是模型的視圖，因?yàn)閷?duì)業(yè)務(wù)所有者有用的結(jié)構(gòu)集合不同于軟件架構(gòu)師、設(shè)計(jì)人員、開(kāi)發(fā)人員、操作人員等所需要的集合。出于該原因，我們推薦不要將包作為管理模型視圖的主要機(jī)制（不是說(shuō)包中不出現(xiàn)服務(wù)，只是說(shuō)包應(yīng)該用于模型的更平凡結(jié)構(gòu)）。取而代之，我們指望 UML 2.0 規(guī)范的復(fù)合結(jié)構(gòu)概念，其提供了表示使用“部件”和“連接器”的分類(lèi)器的內(nèi)部結(jié)構(gòu)功能。
我們利用這些技術(shù)劃分所管理的服務(wù)，換句話(huà)說(shuō)，根據(jù)邏輯分類(lèi)方案進(jìn)行組織，不需要讓服務(wù)所屬于任何一個(gè)分區(qū)。例如，我們可能有兩個(gè)不同的組合視圖：一個(gè)表示不同的業(yè)務(wù)線(xiàn)，另一個(gè)表示提供服務(wù)的應(yīng)用程序“類(lèi)型”，如圖 2 所以。
圖 2：根據(jù)邏輯分類(lèi)方案利用分區(qū)進(jìn)行組織，不需要讓服務(wù)所屬于任何一個(gè)分區(qū)
注意，相同的服務(wù)（較小的方框）出現(xiàn)在一個(gè)以上的分區(qū)中（較大的方框），頂部的三個(gè)分區(qū)表示業(yè)務(wù)線(xiàn)，且底部的三個(gè)表示應(yīng)用程序類(lèi)型。從此處我們可以看到，雖然業(yè)務(wù)的供應(yīng)鏈擁有并管理著 Shipping、Validation，和 Warehouse 服務(wù)，但我們可以看到 Shipping 服務(wù)由 ERP 包提供而 Warehouse 和 Validation 服務(wù)是定制開(kāi)發(fā)的。
該技術(shù)不僅在管理已開(kāi)發(fā)的服務(wù)集方面體現(xiàn)價(jià)值，還在服務(wù)的識(shí)別過(guò)程中體現(xiàn)價(jià)值。分區(qū)可以用于表示服務(wù)分組，并作為服務(wù)規(guī)范進(jìn)行開(kāi)發(fā)，可以將服務(wù)放置于不同的分區(qū)中以可視化關(guān)系和它們之間的依賴(lài)。
RUP 更新
對(duì) SOA 的 RUP 更新已經(jīng)在許多（和諧的）地方得到擴(kuò)展，以提供關(guān)于體系結(jié)構(gòu)開(kāi)發(fā)和面向服務(wù)解決方案的設(shè)計(jì)模型的具體指導(dǎo)。但 RUP 的許多領(lǐng)域仍舊不受到該更新的影響。例如，我們?cè)谠缙跊Q定的更新的開(kāi)發(fā)，盡管一些行業(yè)作家已經(jīng)引入了支持 SOA 的新開(kāi)發(fā)角色，但我們相信當(dāng)前 RUP 的Software Architect 和Designer 角色對(duì)于我們所需要的更新是足夠的。
新的和更新的工作流
在更新 RUP 以引入對(duì)于 SOA 解決方案構(gòu)建的指導(dǎo)的過(guò)程中，我們只添加了以下兩個(gè)新活動(dòng)：
-
識(shí)別服務(wù)。由 Analysis & Design 和 Refine the Architecture 工作流中的 Software Architect執(zhí)行。
-
服務(wù)設(shè)計(jì)。由 Analysis & Design 和 Design Services 工作流中的 Designer 執(zhí)行。
識(shí)別服務(wù)活動(dòng)是軟件架構(gòu)師在概括解決方案的體系結(jié)構(gòu)時(shí)所執(zhí)行的一個(gè)活動(dòng)，活動(dòng)的輸出是服務(wù)模型。該服務(wù)模型中包含一組已識(shí)別的，已經(jīng)是候選的服務(wù)，這些服務(wù)要作為服務(wù)設(shè)計(jì)活動(dòng)的一部分由設(shè)計(jì)人員進(jìn)一步細(xì)化。
新的和更新的工件
更新將整個(gè)服務(wù)模型（表示 UML Profile for Software Services）和其附屬的要素引入到 RUP 中。模型表示面向服務(wù)解決方案的體系結(jié)構(gòu)抽象，該抽象使軟件架構(gòu)師和設(shè)計(jì)人員在這樣一種環(huán)境下開(kāi)發(fā)模型，在這種環(huán)境下，服務(wù)的概念和對(duì) SOA 的具體關(guān)注是頭等的模型要素。模型不直接表示任何實(shí)現(xiàn)技術(shù)，如 WSDL。
圖 3：UML Profile for Software Services
新的和更新的指導(dǎo)方針
除了在服務(wù)模型中描述工件的具體內(nèi)容，更新還包括與上面描述的主題相關(guān)的概念以及在開(kāi)發(fā) SOA 模型時(shí)反映對(duì)重要性所關(guān)注的額外的指導(dǎo)方針。這些關(guān)注包括：
-
消息設(shè)計(jì)和消息附件。設(shè)計(jì)消息，管理可復(fù)用的消息目錄和消息方案的一致性。
-
服務(wù)數(shù)據(jù)封裝。圍繞服務(wù)中數(shù)據(jù)管理的服務(wù)設(shè)計(jì)特性和數(shù)據(jù)方案與服務(wù)邊界之間的關(guān)系。
-
服務(wù)仲裁。有關(guān)一般作為 SOA 式樣一部分（特別是 Enterprise Service Bus，或 ESB 視野）的仲裁組件的概念的具體指導(dǎo)。
-
狀態(tài)管理。對(duì)有狀態(tài)和無(wú)狀態(tài)服務(wù)的優(yōu)點(diǎn)的討論，包括對(duì)于規(guī)范的技術(shù)和管理資源狀態(tài)的服務(wù)設(shè)計(jì)。
我們還提供了指導(dǎo)方針 Going from Services to Service Components（從服務(wù)到服務(wù)組件），其論證了從服務(wù)設(shè)計(jì)模型到傳統(tǒng)的設(shè)計(jì)或?qū)崿F(xiàn)模型的一種可能的變換。
更新還包含兩個(gè)報(bào)告描述，描述創(chuàng)建服務(wù)模型的 RSA 工具指導(dǎo)者，和表現(xiàn)服務(wù)模型開(kāi)發(fā)的相當(dāng)完整的實(shí)例。
RSM 或 RSA 插件
IBM Rational Software Modeler 和 IBM Rational Software Architect 的新插件（今后稱(chēng)為 RSM 或 RSA 插件）提供了 UML Profile for Software Services，一個(gè)您可以使用的模板模型，和一對(duì)論證概要文件使用的示例模型。該插件可以在 IBM developerWorks 下載，并可以利用標(biāo)準(zhǔn)的軟件更新機(jī)制將其添加到工具中（注意下載的壓縮文件表示一個(gè)存檔更新站點(diǎn)）。
在 RSM 或 RSA 中，在軟件服務(wù)的插件安裝完之后可以很容易地創(chuàng)建新的服務(wù)模型。以下的步驟是必要的（注意是在 Modeling Perspective 中）：
- 如果在您的工作區(qū)中已經(jīng)有了一個(gè) UML 建模工程，您可以將服務(wù)模型添加到該工程中或創(chuàng)建新工程（參見(jiàn)步驟 2）。
- 右鍵單擊工程并選擇 New -> UML Model 或者在 File 菜單中選擇 New -> UML Model。
- 當(dāng)您看到 New UML Model 向?qū)r(shí)，如圖 4，轉(zhuǎn)到步驟 3。
- 要?jiǎng)?chuàng)建新的 UML 建模工程，到 File 菜單中并選擇 New -> Project，UML Project 處在 Modeling 目錄下面。
- 在結(jié)果向?qū)е校o出工程的名稱(chēng)并選擇 Next。
- 在 New UML Model 向?qū)е校鐖D 4 所示，確保正確設(shè)置了目標(biāo)文件夾，從模板列表中選擇 Service Design Model，并給模型命名。
![圖 4：New UML model 向?qū)? src=]()
圖 4：New UML model 向?qū)?/b>
這將創(chuàng)建并打開(kāi)帶有 UML Profile for Software Services 的 UML 模型和一個(gè)模板結(jié)構(gòu)，您可能由該模板結(jié)構(gòu)開(kāi)始為 SOA 解決方案建模。模型還包含一組可以在創(chuàng)建一些復(fù)合要素時(shí)有用的可復(fù)用模型要素，至少使用這些要素要比手動(dòng)創(chuàng)建更簡(jiǎn)單。
三個(gè)情境
以下的部分概述了我們從與客戶(hù)的討論（不論客戶(hù)認(rèn)為面向服務(wù)的解決方案的開(kāi)發(fā)如何適應(yīng)他們的軟件開(kāi)發(fā)生命周期）中總結(jié)出的三個(gè)情境。我們先認(rèn)明三個(gè)開(kāi)發(fā)服務(wù)的方法，而它們當(dāng)然不是不相容的（真實(shí)的工程使用技術(shù)的組合），它們?cè)陉U明不同方法和思想方面是有用的。
在任何可能的地方，我將把在這些情境中描述的任務(wù)與 RUP 中定義的結(jié)合起來(lái)。
1. 以消息為中心的設(shè)計(jì)
在消息為中心的設(shè)計(jì)中，焦點(diǎn)在服務(wù)領(lǐng)域中。例如領(lǐng)域工程或面向?qū)ο蠓治龊驮O(shè)計(jì)（Object-Oriented Analysis and Design，OOAD）的技術(shù)提供了許多對(duì)抽象領(lǐng)域模型開(kāi)發(fā)的洞察，并且這些技術(shù)通常生成對(duì)應(yīng)消息方案的高度可復(fù)用模型。服務(wù)設(shè)計(jì)常常是次要的活動(dòng)，盡管有時(shí)候并行地完成。例如，在電子數(shù)據(jù)交換（Electronic Data Interchange，EDI）中，不存在真正的服務(wù)接口概念，因?yàn)?EDI 系統(tǒng)通常有一個(gè)單個(gè)的全球的消息收件箱和發(fā)件箱。
該方法的一個(gè)實(shí)例可能是在傳統(tǒng)的B2B 環(huán)境中，以 EDI 標(biāo)準(zhǔn)化作為代表。在此種情況下，主要的設(shè)計(jì)活動(dòng)涉及開(kāi)發(fā)某些行業(yè)或其他范圍內(nèi)取得一致的消息方案，這被認(rèn)為是表示一類(lèi)消息的方案 —— 例如，EDI8Purchase Order、ACORD9Claim Inquiry，或者 SWIFT10Credit Transfer。
在許多現(xiàn)代標(biāo)準(zhǔn)活動(dòng)中，如 SWIFT 或 RosettaNet，11經(jīng)常存在一個(gè)用于標(biāo)準(zhǔn)的設(shè)計(jì)過(guò)程，包含了一個(gè)混合的以消息為中心并以服務(wù)為中心的方法，在該方法中使用了如用例分析的技術(shù)。
情境
在此實(shí)例中，客戶(hù)是一個(gè)大的保險(xiǎn)供應(yīng)商，開(kāi)發(fā)新的應(yīng)用程序以支持其中一條業(yè)務(wù)線(xiàn)。在該公司中業(yè)務(wù)和 IT 支持之間的結(jié)合相當(dāng)?shù)暮茫覈?yán)密關(guān)注通過(guò) IT 傳遞到業(yè)務(wù)的價(jià)值。
此情境中的項(xiàng)目擴(kuò)展了兩個(gè)索賠處理系統(tǒng)，以便兩個(gè)系統(tǒng)可以提供將要啟動(dòng)策略集成并使公司收回一個(gè)系統(tǒng)并將所有索賠處理系統(tǒng)移到一個(gè)單個(gè)的系統(tǒng)中的面向服務(wù)的接口。
業(yè)務(wù)人員希望服務(wù)能夠支持一些現(xiàn)有的業(yè)務(wù)過(guò)程，但他們清楚地知道這些過(guò)程隨時(shí)變化，所以將服務(wù)與過(guò)程結(jié)合是不切實(shí)際的。作為回應(yīng)，該業(yè)務(wù)領(lǐng)域的軟件架構(gòu)師相信更加適合的方法可能會(huì)集中于過(guò)程中的業(yè)務(wù)工件，主要是索賠本身。除了這些，他們已經(jīng)在 IBM IAA 中投了資，12這為工件提供了定義良好的且標(biāo)準(zhǔn)的模型，如索賠。
在這點(diǎn)上，對(duì)于主要工件的實(shí)際數(shù)據(jù)模型已經(jīng)由 IAA 指定，所以主要的工作是理解在當(dāng)前系統(tǒng)中使用這些工件的方式及圍繞著不同的實(shí)現(xiàn)如何開(kāi)發(fā)新的外觀(guān)。
活動(dòng)
業(yè)務(wù)分析人員開(kāi)始編制需求，還利用業(yè)務(wù)過(guò)程模型來(lái)描述系統(tǒng)的功能需求。非功能需求在需求數(shù)據(jù)庫(kù)中進(jìn)行描述，依附于業(yè)務(wù)過(guò)程模型中的任務(wù)或項(xiàng)。過(guò)程模型是為兩個(gè)當(dāng)前系統(tǒng)和兩者的交集開(kāi)發(fā)的。
軟件架構(gòu)師拿到了這些模型和需求并與業(yè)務(wù)分析人員一起開(kāi)發(fā)集中于兩個(gè)系統(tǒng)間一般工件的流程的更具體的過(guò)程。軟件架構(gòu)師還與業(yè)務(wù)分析人員一起理解當(dāng)前系統(tǒng)的數(shù)據(jù)需求及它們到 IAA 數(shù)據(jù)模型的關(guān)系。
數(shù)據(jù)架構(gòu)師與軟件架構(gòu)師一起描繪出針對(duì)新的過(guò)程中工件的邏輯和物理表示的方案。
軟件架構(gòu)師開(kāi)發(fā)了一個(gè)將過(guò)程活動(dòng)劃分成一組服務(wù)操作的候選服務(wù)模型。該模型還包括每個(gè)服務(wù)的消息需求及這些消息到下面的數(shù)據(jù)模型的關(guān)聯(lián)。
軟件架構(gòu)師與集成專(zhuān)家一起（不是通常的 RUP 角色，但對(duì)應(yīng)該角色的描述是為 RUP 設(shè)計(jì)的）定義從候選模型到當(dāng)前實(shí)現(xiàn)所需的映射（在它們存在的地方）。這些映射將在所選的中間件中實(shí)現(xiàn)，但不應(yīng)該像引入主要性能問(wèn)題那樣麻煩。
2. 以服務(wù)為中心的設(shè)計(jì)
在此方法中，設(shè)計(jì)人員牽扯到展示（作為服務(wù)或一組服務(wù)）預(yù)期的業(yè)務(wù)或應(yīng)用程序的功能。在此種情況下，我們不必要知道服務(wù)的客戶(hù)會(huì)選擇什么來(lái)利用服務(wù)，但我們知道此種客戶(hù)期望的交互類(lèi)型。因此，與第一個(gè)情境相反，消息是次要，并且被作為對(duì)操作的需求響應(yīng)被開(kāi)發(fā)。
該方法的實(shí)例是由 Amazon 和 eBay 表現(xiàn)的 Web 服務(wù) API（Web Services APIs presented by Amazon，AWS）13。此服務(wù)接口沒(méi)有將業(yè)務(wù)過(guò)程強(qiáng)加于客戶(hù)，一般地，它們甚至沒(méi)有將所期望的接口強(qiáng)加于客戶(hù)，但它們使第三方開(kāi)發(fā)人員以清晰直觀(guān)的方式接觸到了各自的服務(wù)供應(yīng)商的操作。
如前面所提到的，以服務(wù)為中心的建模通過(guò)了解參與者的需求（服務(wù)的外部客戶(hù)）并提供支持那些需求的操作（瀏覽目錄、向購(gòu)物車(chē)中添加物品、付賬等）有助于用例驅(qū)動(dòng)的方法。
成為次要關(guān)注的消息的問(wèn)題在 Amazon API 中是明顯的，在 Amazon API 中肯定能夠?qū)⑵胀ǖ姆桨付x從當(dāng)前設(shè)計(jì)中分析出來(lái)，這證明消息是為每個(gè)操作請(qǐng)求和響應(yīng)而分別開(kāi)發(fā)的。
情境
此處我們的實(shí)例是一個(gè)為化學(xué)加工行業(yè)提供零件的在線(xiàn)供應(yīng)商。商家可以提供一個(gè) Web 門(mén)戶(hù)，客戶(hù)可以通過(guò)該門(mén)戶(hù)購(gòu)買(mǎi)零件，商家還可以通過(guò)電話(huà)和傳真管理進(jìn)一步的業(yè)務(wù)。但需要為客戶(hù)提供通過(guò)比 Web 本身更程序化的方法對(duì)購(gòu)買(mǎi)門(mén)戶(hù)進(jìn)行的訪(fǎng)問(wèn)。這種對(duì)核心訂購(gòu)功能的訪(fǎng)問(wèn)使公司成為客戶(hù)供應(yīng)鏈中的關(guān)鍵要素，一個(gè)可以直接與客戶(hù)核心業(yè)務(wù)應(yīng)用程序集成的要素。商家試圖實(shí)現(xiàn) EDI 購(gòu)買(mǎi)解決方案，但初始部署的成本和必要的基礎(chǔ)結(jié)構(gòu)證實(shí)是不可行的的。執(zhí)行團(tuán)隊(duì)相信許多客戶(hù)正在向其他的能夠提供此種購(gòu)買(mǎi)門(mén)戶(hù)的供應(yīng)商轉(zhuǎn)移，因?yàn)檫@些競(jìng)爭(zhēng)者已經(jīng)能夠通過(guò)更自動(dòng)化的過(guò)程更好地集成。
與我們的第一個(gè)情境比較，此項(xiàng)目由 IT 組織推動(dòng)。以一個(gè)商家的觀(guān)點(diǎn)，項(xiàng)目目標(biāo)是簡(jiǎn)單地提供一個(gè)機(jī)制來(lái)執(zhí)行同樣的訂購(gòu)操作，不需要讓客戶(hù)花時(shí)間將數(shù)據(jù)輸入到 Web 門(mén)戶(hù)或者商家輸入來(lái)自傳真訂購(gòu)清單的類(lèi)似數(shù)據(jù)。IT 組織被允許獨(dú)立做出許多決定，只要能夠生成比前一個(gè) EDI 嘗試花費(fèi)少的解決方案。
兩個(gè)重要的影響設(shè)計(jì)的觀(guān)察已經(jīng)由 IT 組織的高級(jí)團(tuán)隊(duì)做出來(lái)了。
- 提供的功能必須不得少于通過(guò) Web 或人工訂購(gòu)提供的當(dāng)前功能。
- 操作集不是由我們的業(yè)務(wù)過(guò)程所推動(dòng)，而是由客戶(hù)所使用的，作為他們過(guò)程的一部分。針對(duì)該原因，我們必須假設(shè)關(guān)于這些操作使用的可能性越少越好。
軟件架構(gòu)師生成了一組描述客戶(hù)所期望的功能的用例文檔，并且確保業(yè)務(wù)團(tuán)隊(duì)同意。然后用例被斷成一組離散的操作，且數(shù)據(jù)需求（消息）被指定。這些操作集合成一組三個(gè)用于搜索、訂購(gòu)和賬戶(hù)管理的服務(wù)。此步驟傾向于受到經(jīng)驗(yàn)和判斷的影響比受到精確的規(guī)格影響要多，因而此步驟是迭代的。
一旦知道了服務(wù)和操作集，團(tuán)隊(duì)就可以更加正式地定義服務(wù)規(guī)范，包括針對(duì)每個(gè)接口的協(xié)議和服務(wù)客戶(hù)所需要的任意策略信息。該步驟非常的重要：它向客戶(hù)提供了在服務(wù)可用時(shí)，不能夠通過(guò)簡(jiǎn)單地閱讀由商家部署的 WSDL 就能夠被理解的信息。
活動(dòng)
業(yè)務(wù)執(zhí)行者（不是當(dāng)前的 RUP 角色，但似乎我們都承認(rèn)他們）傳達(dá)了這樣一個(gè)需要，就是當(dāng)客戶(hù)感覺(jué)他們的收入正在被當(dāng)前提供這些功能的更大的供應(yīng)商搶走時(shí)，必須向客戶(hù)提供可編程訪(fǎng)問(wèn)業(yè)務(wù)服務(wù)的能力。
軟件架構(gòu)師打算開(kāi)發(fā)一組提供 Web 訂購(gòu)系統(tǒng)的核心功能的服務(wù)。提議包括一組用例，描述了客戶(hù)通過(guò) Web 執(zhí)行的活動(dòng)（與來(lái)自在線(xiàn)業(yè)務(wù)的業(yè)務(wù)分析人員一起開(kāi)發(fā)）。同時(shí)也包含了初始階段的模型，這個(gè)模型展示了對(duì)于當(dāng)前后端系統(tǒng)的候選服務(wù)和他們之間的關(guān)系。
軟件架構(gòu)師，贊成該項(xiàng)目，迭代候選服務(wù)模型以在后端應(yīng)用程序分區(qū)（公然地展示所需的業(yè)務(wù)功能以支持服務(wù)）中識(shí)別服務(wù)。同時(shí)，軟件架構(gòu)師讓設(shè)計(jì)人員觀(guān)察當(dāng)前的 Web 應(yīng)用程序及如何與后端系統(tǒng)交互，挖掘出要由服務(wù)實(shí)現(xiàn)的任何所需的業(yè)務(wù)邏輯和需求。
軟件架構(gòu)師和業(yè)務(wù)分析人員一致同意把所需的功能集作為服務(wù)執(zhí)行的操作和任意所需的約束或策略來(lái)提供。此模型的迭代顯示了三個(gè)具體的服務(wù)和初始服務(wù)規(guī)范，盡管在過(guò)程的這一點(diǎn)上這些只指定了服務(wù)的結(jié)構(gòu)方面。
軟件架構(gòu)師與 Web 應(yīng)用程序團(tuán)隊(duì)的開(kāi)發(fā)人員一起了解對(duì)于已識(shí)別的操作集的具體數(shù)據(jù)需求。這被交給了具有 XML 技術(shù)的數(shù)據(jù)架構(gòu)師，來(lái)開(kāi)發(fā)將會(huì)生成由操作銷(xiāo)毀和生成的消息方案的消息模型。
設(shè)計(jì)人員可以開(kāi)始連接服務(wù)模型和將用來(lái)描述提供業(yè)務(wù)邏輯的組件的實(shí)現(xiàn)模型（J2EE）并連接到現(xiàn)有的后端應(yīng)用程序。
軟件架構(gòu)師和設(shè)計(jì)人員最終用細(xì)節(jié)根據(jù)服務(wù)規(guī)范細(xì)化了服務(wù)模型，主要提供可以使客戶(hù)了解如何與服務(wù)交互的協(xié)議和策略細(xì)節(jié)。
我們現(xiàn)在有一組完整的模型：
- 描述客戶(hù)期望的用例模型
- 描述客戶(hù)視角（服務(wù)規(guī)范）和供應(yīng)商視角（服務(wù)、分區(qū)等）的服務(wù)模型
- 描述實(shí)現(xiàn)服務(wù)規(guī)范的軟件組件的實(shí)現(xiàn)模型
現(xiàn)在開(kāi)發(fā)人員能夠?qū)崿F(xiàn)準(zhǔn)備由客戶(hù)使用的試驗(yàn)系統(tǒng)。
繼續(xù)的行動(dòng)
在成功部署試驗(yàn)工程之后，要注意的是，向客戶(hù)提供的服務(wù)涉及 Web 系統(tǒng)特定功能的并行實(shí)現(xiàn)。建議建立新的工程來(lái)重新配置 Web 應(yīng)用程序以復(fù)用這些服務(wù)，這項(xiàng)工作應(yīng)該包含于 Web 應(yīng)用程序的常規(guī)計(jì)劃更新中。這樣的重配置將某些業(yè)務(wù)邏輯從 Web 應(yīng)用程序中移到服務(wù)中，因而一個(gè)單獨(dú)的組件集合由基于 Web 和服務(wù)的客戶(hù)使用。
為了滿(mǎn)足 Web 應(yīng)用程序團(tuán)隊(duì)對(duì)性能的關(guān)注，除了向合伙人提供的 SOAP/HTTP 綁定之外，服務(wù)還需要被重配置，以在 Web 應(yīng)用程序中訪(fǎng)問(wèn)服務(wù)時(shí)，服務(wù)能夠提供更有效的 Java 綁定，。
3. 以協(xié)作為中心的設(shè)計(jì)
在協(xié)作為中心的方法中，重點(diǎn)是兩個(gè)或多個(gè)服務(wù)的協(xié)作，這是服務(wù)的過(guò)程視角，它與傳統(tǒng)業(yè)務(wù)建模的相關(guān)性要比與軟件開(kāi)發(fā)活動(dòng)的相關(guān)性更大。在此方法中，服務(wù)作為協(xié)作中的實(shí)現(xiàn)角色，因此服務(wù)規(guī)范成為為跨一個(gè)或多個(gè)協(xié)作的角色而定義的責(zé)任。
這樣一種方法將對(duì)那些涉及到 RosettaNet Partner Interchange Processes（PIPs）的開(kāi)發(fā)和 OAGIS14標(biāo)準(zhǔn)的開(kāi)發(fā)中的人是可識(shí)別的（然而，在這些情況下協(xié)作遠(yuǎn)不完全）。這樣的方法在業(yè)務(wù)中對(duì)于業(yè)務(wù)過(guò)程設(shè)計(jì)或在業(yè)務(wù)集成活動(dòng)（在活動(dòng)中 IT 系統(tǒng)的組件作為服務(wù)出現(xiàn)）中而言是普遍的。
通常在這樣的情境中，服務(wù)規(guī)范可能直接源自協(xié)作，而該方法傾向于較少關(guān)注于導(dǎo)致需要實(shí)現(xiàn)完整性的混合方法的消息內(nèi)容。
情境
此情境涉及一個(gè)已經(jīng)決定通過(guò)收購(gòu)而繼續(xù)擴(kuò)充策略的中型銀行企業(yè)，這意味著對(duì)于該企業(yè)來(lái)說(shuō)，IT 不只是一個(gè)必須擁有的部分，而且還是在吸收所收購(gòu)操作過(guò)程中發(fā)揮競(jìng)爭(zhēng)優(yōu)勢(shì)的業(yè)務(wù)的一部分。
銀行已經(jīng)開(kāi)發(fā)了一個(gè)領(lǐng)先的得到謹(jǐn)慎管理的組合，以確保成本和功能的效率。然而，很清楚的是某些技術(shù)和文化方面的阻礙出現(xiàn)在視線(xiàn)中，在整個(gè)企業(yè)中提供應(yīng)用程序的一般集合。由于這些阻礙，公司已經(jīng)決定使用服務(wù)方法來(lái)提供它們的 IT 功能并以此式樣開(kāi)發(fā)所有的新功能。企業(yè)已經(jīng)經(jīng)過(guò)多年開(kāi)發(fā)了一套以過(guò)程為中心的東西。這些很好理解，一般的過(guò)程使它們有效地集成所收購(gòu)的企業(yè)并指導(dǎo)他們的 IT組織來(lái)支持這些過(guò)程。
在我們的情境中，銀行將一個(gè)遺留應(yīng)用程序引入了服務(wù)組合中，這給我們提供了一個(gè)機(jī)會(huì)來(lái)觀(guān)察帳戶(hù)統(tǒng)一的過(guò)程模型，即一個(gè)令企業(yè)幫助客戶(hù)有效利用帳戶(hù)的業(yè)務(wù)服務(wù)。此過(guò)程模型已經(jīng)由許多“黑盒子”活動(dòng)設(shè)計(jì)而成，意味著一個(gè)活動(dòng)通常由一個(gè)沒(méi)有作為服務(wù)組合的一部分而啟動(dòng)的系統(tǒng)執(zhí)行或者以還沒(méi)有細(xì)化的方式執(zhí)行。模型將這些活動(dòng)表示為“黑盒子”并不提供更多的細(xì)節(jié)。團(tuán)隊(duì)已經(jīng)注意到特定的遺留應(yīng)用程序系統(tǒng)參與了帳戶(hù)統(tǒng)一過(guò)程的三個(gè)活動(dòng)，且其他過(guò)程模型的分析揭示了使用同一應(yīng)用程序的兩個(gè)其他的過(guò)程。
在企業(yè)所依靠的方法中，過(guò)程模型是分析和需求收集的主要工件。過(guò)程本身表現(xiàn)出通過(guò) IT 和相應(yīng)的人員，業(yè)務(wù)功能需求的完全體現(xiàn)，附屬的且正式定義的文檔描述了非功能的需求。在配置管理之下這些過(guò)程模型得到了小心的維護(hù)，并且為每個(gè)操作過(guò)程而發(fā)布，這樣它們不僅指導(dǎo)過(guò)程的開(kāi)發(fā)還為過(guò)程中的銀行職員培訓(xùn)提供了材料。
早期提及的服務(wù)組合是一個(gè) RAS15存儲(chǔ)庫(kù)，其考慮了基于由每個(gè)資產(chǎn)中的 RAS 名單所定義的標(biāo)準(zhǔn)的搜索。資產(chǎn)是所部署的服務(wù)，而名單包含了描述服務(wù)的核心組合及描述業(yè)務(wù)信息（如所有權(quán)、策略等等）的范圍。
在開(kāi)發(fā)服務(wù)以提供遺留應(yīng)用程序的功能過(guò)程中，包含了業(yè)務(wù)和 IT 代表的團(tuán)隊(duì)致力于作為業(yè)務(wù)過(guò)程實(shí)現(xiàn)的服務(wù)之間的協(xié)作。該方法使業(yè)務(wù)端將結(jié)果看成是傳統(tǒng)的業(yè)務(wù)過(guò)程模型，而 IT 端將同樣的模型看成是服務(wù)之間的協(xié)作。
活動(dòng)
業(yè)務(wù)分析人員要么創(chuàng)建新的業(yè)務(wù)過(guò)程模型，要么更新現(xiàn)有的業(yè)務(wù)過(guò)程模型。此模型是按照商家所展望描述的新過(guò)程，該過(guò)程更新還包括由過(guò)程活動(dòng)管理、消除或產(chǎn)生的業(yè)務(wù)文檔定義。軟件架構(gòu)師創(chuàng)建了差距分析文檔，這個(gè)文檔對(duì)新業(yè)務(wù)過(guò)程的需求和現(xiàn)有服務(wù)組合進(jìn)行了比較。
業(yè)務(wù)分析人員將關(guān)鍵性能指示器（Key Performance Indicators，KPI)16定義為業(yè)務(wù)過(guò)程本身的一部分。這暗示著參與過(guò)程的服務(wù)必須支持可以查詢(xún)的用來(lái)確保與 KPI 的一致性的度量。
數(shù)據(jù)架構(gòu)師改進(jìn)來(lái)自業(yè)務(wù)過(guò)程模型的消息定義，確保與現(xiàn)有方案的通用性，然后開(kāi)發(fā)可以用于生成服務(wù)所需的 XML 方案的消息模型。
軟件架構(gòu)師用新的服務(wù)或向現(xiàn)有服務(wù)中添加新的規(guī)范來(lái)更新服務(wù)模型。數(shù)據(jù)架構(gòu)師開(kāi)發(fā)的消息模型用于（或復(fù)用于）這些服務(wù)規(guī)范。
軟件架構(gòu)師和業(yè)務(wù)分析人員更新早期定義的過(guò)程模型以將活動(dòng)映射到新的或更新的服務(wù)上。對(duì)于服務(wù)更新，模型是完整的了，現(xiàn)在就可以對(duì)其進(jìn)行轉(zhuǎn)換并發(fā)布。
軟件架構(gòu)師和設(shè)計(jì)人員開(kāi)發(fā)了包含協(xié)議和策略信息的具體服務(wù)規(guī)范。這樣一個(gè)具體的規(guī)范作為供應(yīng)商和客戶(hù)之間的合約，不能由任何一方打破。
開(kāi)發(fā)人員創(chuàng)建針對(duì)遺留應(yīng)用程序的適配器和/或變換，用來(lái)實(shí)現(xiàn)具體的規(guī)范。
開(kāi)發(fā)人員必須開(kāi)發(fā)用于監(jiān)控的度量生成器。這些通常是具體的操作，需要監(jiān)控基礎(chǔ)結(jié)構(gòu)來(lái)查詢(xún)對(duì)應(yīng)一般狀態(tài)和度量狀態(tài)的服務(wù)。
集成專(zhuān)家使用新的服務(wù)來(lái)更新過(guò)程的編排 —— 在此種情況下，業(yè)務(wù)過(guò)程被轉(zhuǎn)化為編排語(yǔ)言，業(yè)務(wù)過(guò)程執(zhí)行語(yǔ)言（Business Process Execution Language，BPEL）。在某些情況下，在部署之前還要用一些額外的信息更新生成的編排。
業(yè)務(wù)分析人員用業(yè)務(wù) KPI 定義和它們到具體度量的關(guān)系來(lái)更新監(jiān)控中間件，以便可以監(jiān)控新的服務(wù)。
接下來(lái)的步驟
IBM Rational 團(tuán)隊(duì)已經(jīng)與許多客戶(hù)一起工作，并在IBM 的內(nèi)部項(xiàng)目中展示并使用了 RUP 和 RSM/RSA 插件。我們已經(jīng)收到足夠的反饋信息，通過(guò)這些信息我們得知盡管我們還有許多事情要做的，但我們已經(jīng)建立了良好堅(jiān)實(shí)的基礎(chǔ)。現(xiàn)在我們正致力于一組具體的工程，其設(shè)計(jì)用來(lái)延伸我們所做的工作，并且了解我們可以在哪里添加更多內(nèi)容，特別是在用于建模工具和額外的 RUP 指導(dǎo)主題的策略規(guī)范的領(lǐng)域。