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