免费视频淫片aa毛片_日韩高清在线亚洲专区vr_日韩大片免费观看视频播放_亚洲欧美国产精品完整版

Jim Amsden (jamsden@us.ibm.com), STSM, IBM　

2008 年 1 月 21 日

在本篇文章中，我們繼續(xù)定義 SOA 解決方案。我們對每一個服務(wù)的規(guī)范進行詳細的建模。這些規(guī)范將會定義服務(wù)的消費者和生產(chǎn)者之間的契約。這些契約包括被提供的和被要求的接口，那些接口在服務(wù)規(guī)范中所扮演的角色，以及那些角色在提供服務(wù)中進行交互的規(guī)則和協(xié)議是什么。

本文的內(nèi)容

本系列的第 1 篇文章：“SOA 建模 第 1 部分 服務(wù)識別”（請參見左上方的 本系列更多內(nèi)容）描繪出了識別那些同業(yè)務(wù)需求相連接的服務(wù)的一種方法的大致輪廓。我們首先捕獲實現(xiàn)業(yè)務(wù)任務(wù)所必須的業(yè)務(wù)目標。然后，對滿足這些目標所必須的業(yè)務(wù)操作和過程進行建模。接著，我們將業(yè)務(wù)過程視作反映我們的最終解決方案所必須滿足的業(yè)務(wù)服務(wù)需求契約的一種服務(wù)協(xié)作。然后，我們使用該需求契約來幫助我們識別它們被要求的服務(wù)及它們之間的潛在聯(lián)系。這為鏈接到業(yè)務(wù)目標的業(yè)務(wù)相關(guān)服務(wù)的識別提供了一種形式化的方法。

在前一篇文章中，我們也查看了如何通過識別于業(yè)務(wù)相關(guān)的服務(wù)來最大化 SOA 解決方案的潛力。我們設(shè)計了基于業(yè)務(wù)需求的服務(wù)拓撲結(jié)構(gòu)，并且將服務(wù)連接到反映服務(wù)解決方案所必須滿足的 Service Requirements 契約的服務(wù)協(xié)作上。

在本文中，我們繼續(xù)通過對每一項服務(wù)的規(guī)范進行詳細的建模來定義 SOA 解決方案。這些規(guī)范將定義服務(wù)的消費者和提供者之間的契約。這些契約包括被提供的和被要求的接口，那些接口在服務(wù)規(guī)范中所扮演的角色，以及那些角色在提供服務(wù)中進行交互的規(guī)則和協(xié)議是什么。

服務(wù)規(guī)范概述

我們還沒有準備好開始對服務(wù)規(guī)范的細節(jié)進行建模。服務(wù)規(guī)范必須為服務(wù)的潛在消費者指定其需要知道的每一件事情，以便他們決定是否有興趣使用該服務(wù)，以及如何使用它。它還必須指定服務(wù)提供者為成功執(zhí)行該服務(wù)所必須知道的每一件事情。因此，服務(wù)規(guī)范就是消費者的需要同提供者的提供之間的媒介或者契約。

理想情況下，這一信息由單一地點提供。這使得為復用服務(wù)而搜索資產(chǎn)庫和獲得所有必要的信息變得十分容易，而且不需要在許多不同的文檔中定位或者搜索相關(guān)的元素。服務(wù)規(guī)范至少包括這些信息：

• 服務(wù)的名稱，暗示出其目的。
• 被提供和被要求的接口，從而定義由服務(wù)和需求消費者所提供的功能性的能力。請注意：這與服務(wù)是如何被執(zhí)行的并不相關(guān)，而是與服務(wù)的消費者和提供者之間的相互作用相關(guān)。
• 指定功能性的能力如何被使用以及以什么樣的順序被使用的任何協(xié)議。
• 反映服務(wù)想要達到什么樣的成功以及如何對其進行評估的約束。
• 服務(wù)消費者所期望得到的和服務(wù)提供者被期望提供的質(zhì)量，例如花費、可用性、性能、腳印、任務(wù)的適宜性、和競爭信息等等。
• 使用服務(wù)的原則，例如用于維持安全性和完整性或者用于將服務(wù)從無能力恢復到成功執(zhí)行的安全性和事務(wù)范圍。

如同本系列中所有文章一樣，我們將使用現(xiàn)已存在的 IBM? Rational? 和 IBM? WebSphere? 工具來建立解決方案并將它們鏈接在一起，從而我們能夠根據(jù)需求驗證解決方案并且更加有效的對變化進行管理。表1總結(jié)了我們將要開發(fā)例子的過程，以及我們將要使用的工具。除此之外，我們通過將 IBM? Software Services Profile 添加到 IBM? Rational? Software Architect 中的 UML 模型中，為服務(wù)建模擴展了統(tǒng)一建模語言(UML)。

服務(wù)識別回顧

我們首先回顧業(yè)務(wù)需求以及滿足它們的被識別的服務(wù)，正如我們在 “SOA 建模 第 1 部分 服務(wù)識別” 中所詳細描述的那樣。圖1將業(yè)務(wù)需求顯示為業(yè)務(wù)中角色的一個協(xié)作、角色職責、以及角色如何相互作用的規(guī)則。

這一服務(wù)協(xié)作反映了一個需求契約，該契約來自一個指定服務(wù)解決方案必須做什么的業(yè)務(wù)過程。它是與體系結(jié)構(gòu)無關(guān)的但是正式的需求規(guī)范，它它并不過度約束 SOA 解決方案。所謂與體系結(jié)構(gòu)無關(guān)，是指該需求契約只是指定了解決方案必須做什么，但是并沒有指定如何去做。

圖2顯示了被識別的服務(wù)規(guī)范的總體情況，該規(guī)范將會制造解決方案并且使用依賴關(guān)系，同時指出它們打算如何被使用。

最終，圖3展示了您如何使用那些服務(wù)來實現(xiàn)您的業(yè)務(wù)要求。

這就完成了對服務(wù)以及它們是如何同業(yè)務(wù)需求相關(guān)的識別。本文的剩余篇幅還將解釋如何對服務(wù)規(guī)范的細節(jié)進行建模。這些服務(wù)規(guī)范在圖2中被詳細表示為接口。它們提供了許多在 Overview 中列出細節(jié)。

在完成這些接口后，您仍然不知道接口所描述的是哪一項服務(wù)參與者提供或者需要的服務(wù)，也不知道服務(wù)功能如何被執(zhí)行（可能使用其他服務(wù)）。這些都將在討論服務(wù)實現(xiàn)的下一篇文章中加以介紹。

服務(wù)規(guī)范的類型

一個服務(wù)規(guī)范需要提供如下信息：

• 服務(wù)的名稱，指示出它是什么或者它做什么。
• 被提供和被要求的接口，描述服務(wù)的功能性的性能。每一個功能性都包括：
  • 它的名稱，通常是一個動詞詞組，指示出它做什么
  • 任何被要求或者可選的服務(wù)數(shù)據(jù)輸入和輸出
  • 任何消費者在使用該功能之前所期望具備的前提條件
  • 任何 消費者 期望的并且是 生產(chǎn)者 必須提供的功能成功使用的后期條件
  • 即使前提條件已經(jīng)被滿足，但是功能由于某種原因未能被提供時，任何被提出的期望或者錯誤條件
• 任何通訊協(xié)議或者規(guī)則，它們決定功能什么時候后能夠被使用或著按照什么樣的順序被使用。
• 消費者期望被提供使用的或者同服務(wù)進行交互的任何功能。
• 在提供服務(wù)時，任何執(zhí)行都必須滿足的需求。
• 反映服務(wù)想要達到什么樣的成功以及如何對其進行評估的約束。
• 服務(wù)消費者所期望得到的和服務(wù)提供者被期望提供的質(zhì)量，例如花費、可用性、性能、腳印、任務(wù)的適宜性、和競爭信息等等。
• 使用服務(wù)的原則，例如用于維持安全性和完整性或者用于將服務(wù)從無能力恢復到成功執(zhí)行的安全性和事務(wù)范圍。

顯然，本文不可能涵蓋所有這些內(nèi)容。特別是，我們將不會關(guān)注服務(wù)或者策略的質(zhì)量。對于那些內(nèi)容，將有專門的文章加以詳細的說明。進一步地，它們可能明確一個服務(wù)特定的提供者，而不是特定服務(wù)的接口自身。我們要做的是，關(guān)注定義和使用一個服務(wù)的最根本的必須條件。

下面各小節(jié)詳細描述了每一個在 圖2 中被識別的服務(wù)規(guī)范。其介紹順序是從一個非常簡單的沒有協(xié)議的服務(wù)規(guī)范，到一個反映一個簡單的請求/響應(yīng)協(xié)議的服務(wù)規(guī)范，再到一個更加復雜的、涉及到消費者和提供者之間多步協(xié)議和交互作用的服務(wù)。

時間進度服務(wù)

圖4中顯示的 Scheduling 服務(wù)規(guī)范十分簡單。服務(wù)提供了兩種功能性：一種是對一個生產(chǎn)時間表請求進行響應(yīng)的能力，一種是創(chuàng)建一個運送時間表的能力。據(jù)我們所知，在這種情況下，沒有一種使用這些功能性的協(xié)議。這兩者都能夠被消費者以任何順序被使用。

Scheduling 服務(wù)規(guī)范是在生產(chǎn)包中定義的一個簡單的 UML 接口。它提供兩種服務(wù)操作。每一種操作都具有前提和后期條件，并且它們能夠提出例外。服務(wù)操作的參數(shù)被要求要么為服務(wù)數(shù)據(jù)（消息），要么為簡單類型。這就確保了參數(shù)不會出現(xiàn)被引用調(diào)用或者被值調(diào)用的狀況，服務(wù)數(shù)據(jù)被放置在哪里（在什么地址空間中），服務(wù)消費者或者提供者是否在操作數(shù)據(jù)的一個副本或者某些持久數(shù)據(jù)源，等等。所有這些需要確保服務(wù)不受其配置地點的限制。服務(wù)數(shù)據(jù)被定義在下面的服務(wù)數(shù)據(jù)模型小節(jié)中。

裝運服務(wù)

Shipping 服務(wù)協(xié)議有一些復雜。想要運送產(chǎn)品的消費者請求運送服務(wù)。然而，運送者可能會花一些時間來決定產(chǎn)品被放置在哪里，它們是否在可用清單中或者是否需要被生產(chǎn)，以及運送產(chǎn)品的最有效的方式。因此，運送時間表使用前需要一段時間。消費者通常不希望等到時間表完成，因為這會阻止并行中的其他工作，或者不必要的將系統(tǒng)資源消耗在長進程上。

因此，IT 架構(gòu)師決定在消費者和提供者之間使用一個簡單的請求響應(yīng)或者回叫協(xié)議。消費者請求運送，過一段時間之后，響應(yīng)來自運送者的請求來處理完全的時間表。要對這一協(xié)議進行建模，我們需要指定生產(chǎn)者和消費者這兩個角色，它們的職責、以及它們進行交互的協(xié)議或者規(guī)則。最后一部分是非常重要的，這是因為如果運送者接收不到一個運送請求，那么它們將不能發(fā)送時間表。

服務(wù)規(guī)范告訴您需要知道的關(guān)于服務(wù)的任何事情。這包括您必須滿足的使用服務(wù)的需求（有時被稱作 Use 或者 Usage 契約，請參見 Resources 中列出的 Daniels 和 Cheesman 的文章，再加上服務(wù)必須滿足的應(yīng)用的需求（有時被稱作 Realization 契約）。這是您需要為業(yè)務(wù)需求捕獲的同一類信息；除了主題區(qū)域和細節(jié)級別是不同的之外。您將在涉及服務(wù)消費者和提供者如何進行交互的 Service Requirements 契約中定義該規(guī)范。

在這種情況下，我們使用一個抽象類來定義服務(wù)規(guī)范，如圖5所示。

ShippingService 規(guī)范涉及到兩個角色：

• 角色 shipper 是一個提供者的角色。它負責滿足其類型賦予它的運送的職責，即運送接口。
• 角色 orderer 負責處理運送進度表。這通過其 ScheduleProcessing 類型被顯示。

將這些角色指明為提供者和消費者并不是必須的。在一個潛在的長期運行的會話中（可能涉及到多方），這些只是任意的區(qū)別。通過 Service 規(guī)范實現(xiàn)被提供的運送接口和使用被需要的 ScheduleProcessing 接口，也很容易看出誰是消費者、誰是提供者。

在運送者和訂貨人角色之間有一個連接器。它指出了在這些角色之間涉及某些交互作用的協(xié)議。requestShipping 交互作用為 ShippingService 類所擁有，它顯示了這個交互作用是什么。

ShippingService 交互作用指定了訂貨方運送方角色之間交互的行為的或者動態(tài)的方面。訂貨方首先發(fā)送一個 requestShipping 消息（或者調(diào)用運送方的 requestShipping 操作），一段時間后，必須響應(yīng)來自運送方的 processSchedule 消息。交互作用涉及到兩條生命線：一條用于訂貨方，另一條用于運送方。這些對象實例就是 Service 規(guī)范類中的訂貨方和運送方屬性。也就是說，消息在哪些角色之間通過連接器被交換。這是一個簡單的、異步的請求/響應(yīng)或者回叫模式，它是許多服務(wù)協(xié)議的典型應(yīng)用。

ShippingService 協(xié)議通過使用任何 UML 2 行為被指定，這些行為可以是：活動、交互、狀態(tài)機、或者不透明行為（代碼）。選擇哪一種來使用取決于建模者、他們更加偏愛的風格、或者問題域的適用性。

貨品計價服務(wù)

為發(fā)貨單計算初始的和最終的價格，涉及到訂貨者和貨品計價之間一個更加復雜的協(xié)議。顯然，initiatePriceCalculation 必須在 completePriceCalculation 之前被調(diào)用。然后，訂貨者必須被準備來作為結(jié)果的發(fā)貨單。

我們能夠通過使用一個指定發(fā)貨方和訂貨方角色、它們的職責、以及它們之間如何交互的協(xié)議（會話或者規(guī)則）的抽象類來捕獲這個協(xié)議。這就像 ShippingService 規(guī)范，除了交互作用僅僅是簡單的請求/響應(yīng)之外。為了服務(wù)的有效使用，服務(wù)功能性必須以一種順序被調(diào)用。

圖6中顯示的 InvoicingService 服務(wù)規(guī)范捕獲了這一協(xié)議。請注意該服務(wù)規(guī)范也執(zhí)行了 Invoicing 用例。一個用力可能被用來反映服務(wù)指定的需求。該服務(wù)規(guī)范包括兩個角色：發(fā)貨方和訂貨方。這些角色的類型分別是 Invoicing 實現(xiàn)的接口和被使用的 InvoiceProcessing 接口。這些接口封裝了角色（服務(wù)或者請求功能或者操作）的職責。服務(wù)規(guī)范中的 InvoicingService 活動為使用服務(wù)操作指定了協(xié)議，在訂貨方和發(fā)貨方角色之間能夠發(fā)生的實際交流。

InvoicingService 是一個指定訂貨人和發(fā)貨單之間的會話、交流協(xié)議、或者交互規(guī)則的類。協(xié)議的細節(jié)在該類的 ownedBehavior 中被捕獲，并被用來為使用這一服務(wù)指定有效的交互模式。在這種情況下，該協(xié)議被表達為一種 UML 活動。

該協(xié)議指示出訂貨方必須在試圖得到完全的價格計算之前，啟動一個價格計算。訂貨方然后必須響應(yīng)一個請求（在本例中是回叫）來處理最終的貨物。一些請求貨品計價服務(wù)的消費者只需執(zhí)行這三種操作，但是這些指定操作的順序是受到協(xié)議約束的。沒有一個 InvoicingService 活動中的 ActivityPartitions 反映 InvoicingService 類中的角色或者屬性。一個屬于某個分區(qū)的操作祈禱行動指示出祈禱處于分區(qū)所反映的角色（行動的目標輸入碼正是活動分區(qū)所反映的角色）。

在這種情況下，在訂貨人和貨品計價服務(wù)之間只有一種交互作用，所以服務(wù)規(guī)范類只有一個 ownedBehavor。在另一種情況下，消費者和提供者之間會有超過一種的交互作用，每一種都是用不同的協(xié)議。服務(wù)規(guī)范將擁有一個 ownedBehavior 為每一個會話指定有效的交互模式。

您并不知道哪個服務(wù)提供者執(zhí)行了一個 InvoicingService。您也不知道哪個服務(wù)消費者可能使用它。您只知道任何一個消費者使用服務(wù)必須做什么，以及任何一個提供者執(zhí)行它時必須做什么。

購買規(guī)范

最后，我們來看處理定購單的服務(wù)規(guī)范，如圖7所示。

如同 Scheduling 服務(wù)規(guī)范一樣，Purchasing 是一個簡單的接口，它僅僅擁有一個為消費者處理定購單提供功能的操作，而這些消費者將返回一個完全的發(fā)貨單。伴隨而來的副作用是，訂購的條目被生產(chǎn)（如果需要的話）并且運送給消費者。

該服務(wù)接口反映了在原始的 Process Purchase Order 業(yè)務(wù)過程中指定的功能性的能力。它反映了從那個業(yè)務(wù)過程中識別和設(shè)計的服務(wù)。

服務(wù)拓撲結(jié)構(gòu)重溫

至此，服務(wù)規(guī)范被更加完整的定義。我們能夠查看前面 圖3 中所顯示服務(wù)拓撲結(jié)構(gòu)?；仡櫵@示了被識別服務(wù)的實例如何能夠被使用來滿足業(yè)務(wù) Service Requirements 契約。但是那個圖表沒有很好的顯示服務(wù)自身，它們是如何被連接的，以及在它們的交互作用中涉及到什么協(xié)議。既然服務(wù)規(guī)范已經(jīng)被完成，您創(chuàng)建一個新的圖表，來指示使用這些服務(wù)的服務(wù)參與方如何進行交互來實現(xiàn)該需求。您將在本系列的下一篇文章 “SOA 建模 第三部分 服務(wù)實現(xiàn)” 中再次看到這一圖表，在那里它將被當作本例子中最終的完整的服務(wù)解決方案的出發(fā)點被使用。

圖8顯示了一個抽象的 Order Processing 組件，它為顯示服務(wù)拓撲結(jié)構(gòu)的另一個視圖提供了上下文環(huán)境。它部分反映了將要提供或者需求服務(wù)（或者既提供又需求）的必須滿足 Process Purchase Order 需求契約的順序處理參與方。我們尚不精確的知道這些部分是什么（它們沒有類型），但是我們能夠通過指出它們在定義其如何交互的服務(wù)規(guī)范中扮演什么角色，結(jié)合它們想要滿足的需求是什么，來指定它們需要做什么。

Order Processing 組件各部分之間的連接器，指出了各部分之間預期的交互作用。連接器的名稱與它們契約的名稱相對應(yīng)，在這種情況下，這是相應(yīng)的服務(wù)規(guī)范的協(xié)議。這指示出這些部分將必須提供和要求服務(wù)規(guī)范所指定的接口，并且根據(jù)服務(wù)規(guī)范的協(xié)議各部分將會使用的這些接口。在本系列的下一篇文章對服務(wù)實現(xiàn)的描述中，將對這件事是如何完成的進行建模。

我們還看到這些被放在一起的部分將會以一種滿足 Process Purchase Order 需求契約的方式相互作用。因此，Order Processing 總結(jié)出以下兩點：

• 服務(wù)消費者和提供者（或者稱之為參與者）需要滿足業(yè)務(wù)需求，
• 表示這些參與者如何相互作用的連接和協(xié)議同樣如此。

服務(wù)數(shù)據(jù)模型

package org::crm 中定義的 Customer Relationship Management (CRM) 數(shù)據(jù)模型，定義了在這個例子中的 Purchase Order Process 模型中所有服務(wù)操作所使用的所有數(shù)據(jù)（請參見圖9）。CRM 包反映了 Customer Relationship Management 服務(wù)數(shù)據(jù)模型的設(shè)計，該模型能夠在許多服務(wù)中被復用，甚至是由不同公司所提供的服務(wù)。服務(wù)數(shù)據(jù)是如何被發(fā)現(xiàn)和格式化的，以及它是如何同持久實體或者物理數(shù)據(jù)源相關(guān)聯(lián)的，已經(jīng)超出了本文的范圍。我們這里所介紹的是該服務(wù)數(shù)據(jù)是什么，以及該模型如何被捕獲。

圖9中所顯示的服務(wù)數(shù)據(jù)中的每一個 <message>。服務(wù)數(shù)據(jù)就是在服務(wù)消費者和提供者之間進行交換的數(shù)據(jù)。用于服務(wù)操作的參數(shù)的數(shù)據(jù)類型既可以是消息也可以是簡單類型。

請注意：
服務(wù)數(shù)據(jù)消息同 Web Services Description Language (WSDL) 消息并不一致。服務(wù)操作能夠擁有任何數(shù)量的消息或者簡單類型的輸入和輸出。服務(wù)操作能夠被設(shè)計用作輸入、輸出、和錯誤消息，但是這并不是必須的，而且還將導致不合需要的郵戳數(shù)據(jù)耦合。

消息作為 數(shù)據(jù)傳遞對象(DTOs) 能夠被輕易的在分布式環(huán)境中的地址空間之間進行交換。服務(wù)消費者和提供者并不關(guān)心數(shù)據(jù)存放的實際位置，因此他們假定自己擁有一些實際持久域數(shù)據(jù)的視圖的一個拷貝。消息沒有同一性。由于它們的等同性是基于它們內(nèi)容的值的，而不是基于它們的身份的，所以它們是值對象。

消息反映了在可能的分布式環(huán)境中，服務(wù)消費者和提供者之間的數(shù)據(jù)交換。服務(wù)提供者通常也需要訪問持久的數(shù)據(jù)，用于它們的執(zhí)行設(shè)計。服務(wù)數(shù)據(jù)和服務(wù)執(zhí)行設(shè)計中所使用的持久域數(shù)據(jù)之間的關(guān)系就是服務(wù)提供者及其服務(wù)功能性的執(zhí)行的職責。通常，服務(wù)數(shù)據(jù)是域數(shù)據(jù)的一個選集和投影（或者視圖）。雖然如此，服務(wù)數(shù)據(jù)如何從域數(shù)據(jù)中得到或者更新，取決于服務(wù)執(zhí)行。服務(wù)數(shù)據(jù)對象(SDOs) 對于服務(wù)數(shù)據(jù)消息來說是一個非常有用的執(zhí)行。它們還具備管理變化集和自動將變化提交到持久存儲區(qū)的能力。服務(wù)參與者執(zhí)行可能會用到這些功能，但是它們不需要在模型中被處理。

數(shù)據(jù)模型使用一個 <id> 規(guī)則來識別唯一可以識別類的實例的屬性。這將成為貫穿服務(wù)模型的主題。這是因為 Web 服務(wù)和面向 Web 服務(wù)的 Business Process Execution Language (BPEL) 特別依賴實例相關(guān)性的業(yè)務(wù)數(shù)據(jù)或者基于值的對象同一性。

下一步工作展望

在本文中，我們對每一個被識別服務(wù)的服務(wù)規(guī)范進行詳細的建模。這些規(guī)范將會指示被提供的和被要求的接口，那些接口在服務(wù)規(guī)范中所扮演的角色，以及那些角色在提供服務(wù)中進行交互的規(guī)則和協(xié)議是什么。服務(wù)規(guī)范定義了消費者請求和生產(chǎn)者服務(wù)之間的契約。

本系列的下一篇文章 “SOA 建模 第三部分 服務(wù)實現(xiàn)” 解釋了服務(wù)是如何被真正實現(xiàn)的。服務(wù)實現(xiàn)首先決定哪些組件將會提供哪些服務(wù)。該決定對于服務(wù)可用性、分發(fā)、安全、事務(wù)范圍、和耦合具有非常重要的含義。在這些決定做出之后，我們可以對每一項服務(wù)功能是如何執(zhí)行的進行建模，從而對需求服務(wù)是如何被使用的進行建模。然后，我們將使用包含在 Rational Software Architect 中的 UML-to-SOA 轉(zhuǎn)換特性來創(chuàng)建 Web Services 解決方案，該方案能夠在 Rational Application Developer 或者 WebSphere Integration Developer 中被直接使用，來執(zhí)行、測試、和配置完全的解決方案。