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

2008 年 1 月 21 日

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

本文的內(nèi)容

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

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

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

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

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

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

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

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

服務(wù)識(shí)別回顧

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

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

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

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

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

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

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

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

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

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

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

時(shí)間進(jìn)度服務(wù)

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

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

裝運(yùn)服務(wù)

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

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

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

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

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

• 角色 shipper 是一個(gè)提供者的角色。它負(fù)責(zé)滿足其類型賦予它的運(yùn)送的職責(zé)，即運(yùn)送接口。
• 角色 orderer 負(fù)責(zé)處理運(yùn)送進(jìn)度表。這通過(guò)其 ScheduleProcessing 類型被顯示。

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

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

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

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

貨品計(jì)價(jià)服務(wù)

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

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

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

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

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

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

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

購(gòu)買規(guī)范

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

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

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

服務(wù)拓?fù)浣Y(jié)構(gòu)重溫

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

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

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

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

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

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

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

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

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

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

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

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

下一步工作展望

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

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