2008 年 1 月 21 日

本文是本系列五篇文章中的第 4 篇，它的內(nèi)容包括如何裝配和連接在“第 3 部分 服務(wù)實(shí)現(xiàn)”中建模的服務(wù)提供者，并且設(shè)計(jì)它們的交互作用，為業(yè)務(wù)需求提供一個(gè)完全的解決方案。最為結(jié)果的合成要素將成為一個(gè)服務(wù)參與者，它負(fù)責(zé)把由 Invoicer、Productions 和 Shipper 合成要素所提供的服務(wù)組合在一起，提供處理定購(gòu)單的服務(wù)能力。本文還展示了這一服務(wù)參與者如何實(shí)現(xiàn)最初的業(yè)務(wù)需求。

關(guān)于本系列

在本系列前面的三篇文章中（請(qǐng)參見(jiàn)左上方的 “More in this series”），我們描繪出了識(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ò)程作為一個(gè)幫助我們識(shí)別必需的服務(wù)以及它們之間潛在聯(lián)系的契約來(lái)使用。然后，我們完成了被識(shí)別服務(wù)的規(guī)范。

在本系列的第 1 篇文章第 1 部分 服務(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ù)解決方案必須實(shí)現(xiàn)的反映需求契約的服務(wù)協(xié)作連接起來(lái)。

在第 2 篇文章第 2 部分 服務(wù)規(guī)范 中，我們對(duì)服務(wù)規(guī)范的細(xì)節(jié)進(jìn)行建模。服務(wù)規(guī)范定義了服務(wù)的潛在消費(fèi)者需要知道的所有東西，以便他們決定是否有興趣使用該服務(wù)，以及如何使用該服務(wù)。它同樣指定了服務(wù)提供者必須知道的所有東西，以便他們成功地執(zhí)行該服務(wù)。

在第 3 部分 服務(wù)實(shí)現(xiàn)中，我們對(duì)在服務(wù)提供者：Invoice、Productions 和 Shipper 中作為結(jié)果的服務(wù)規(guī)范的實(shí)現(xiàn)進(jìn)行建模。每一個(gè)合成要素依照服務(wù)規(guī)范提供服務(wù)和功能。每一個(gè)被提供的服務(wù)操作都有一個(gè)描述服務(wù)如何真正執(zhí)行的方法。方法可以是任何的 UML 行為，包括 Activity、Interaction、StateMachine 或者 OpaqueBehavior。這由建模器來(lái)決定。

本系列的最后一篇文章“SOA 建模: 第 5 部分 服務(wù)實(shí)現(xiàn)”，使用 IBM? Rational? Software Architect UML-to-SOA 轉(zhuǎn)換特性來(lái)創(chuàng)建一個(gè) Web 服務(wù)實(shí)現(xiàn)，它能夠在 IBM? WebSphere? Integration Developer 中直接被使用，從而實(shí)現(xiàn)、測(cè)試和配置完全的解決方案。

本文的內(nèi)容

在本文中，我們將第 3 篇文章中創(chuàng)建的服務(wù)提供者集合在一起，以另一個(gè)服務(wù)提供者的方法來(lái)使用它們的功能。也就是說(shuō)，我們將從其他服務(wù)的合成要素中創(chuàng)建一個(gè)新的服務(wù)。這一技術(shù)能夠被遞歸使用任意次，越過(guò)任何一個(gè)關(guān)注集和任何一個(gè)抽象層。然而，有可能存在許多體系結(jié)構(gòu)的約束，對(duì)服務(wù)操作的粒度、安全性和執(zhí)行關(guān)注、數(shù)據(jù)交換量、以及有可能約束什么服務(wù)是由什么合成要素提供的寫級(jí)通訊協(xié)議和綁定問(wèn)題。這些問(wèn)題決定解決方案的體系結(jié)構(gòu)，并且不在本系列這些文章的討論范圍之內(nèi)。請(qǐng)參見(jiàn) Design an SOA solution using a reference architecture 獲得關(guān)于這一重要課題的更多細(xì)節(jié)。

如同本系列中的所有文章一樣，我們將使用現(xiàn)有的 IBM? Rational? 和 IBM? WebSphere? 工具來(lái)建造解決方案，并且將它們鏈接到一起，從而我們能夠檢驗(yàn)該解決方案是否符合需求和更加有效的管理變化。表1總結(jié)了我們開(kāi)發(fā)例子將使用的全部過(guò)程，以及我們所使用的工具。

服務(wù)實(shí)現(xiàn)回顧

我們首先回顧在前面的文章中被執(zhí)行的服務(wù)提供者。圖1顯示了 Invoicer 服務(wù)提供者。

Invoicer 服務(wù)提供者為計(jì)算定購(gòu)單的最初成本提供了 InvoicingProtocol，然后當(dāng)運(yùn)送信息得知以后重新定義這一價(jià)格。定購(gòu)單的總價(jià)取決于產(chǎn)品是在哪里生產(chǎn)的，以及它們是從哪里運(yùn)送的。最初成本的計(jì)算可能被用來(lái)檢驗(yàn)消費(fèi)者有足夠的信用或者仍然想要定購(gòu)產(chǎn)品。在實(shí)現(xiàn)定購(gòu)之前完成這一檢驗(yàn)操作是最好的。

圖2顯示了 Productions 服務(wù)提供者。

Productions 服務(wù)提供者提供 Scheduling 服務(wù)，決定產(chǎn)品在哪里被生產(chǎn)，以及如何何時(shí)被生產(chǎn)。這一信息能夠被用來(lái)創(chuàng)建運(yùn)送時(shí)間表，這個(gè)表在處理定購(gòu)單時(shí)使用。

圖3顯示了 Shipper 服務(wù)提供者。

Shipper 服務(wù)提供者提供 ShippingService 服務(wù)，將產(chǎn)品運(yùn)送到消費(fèi)者來(lái)完成定購(gòu)。該服務(wù)需要 ScheduleProcessing 接口來(lái)請(qǐng)求消費(fèi)者處理完成的時(shí)間表。

服務(wù)合成

現(xiàn)在，服務(wù)已全部由一些提供者提供，我們已經(jīng)準(zhǔn)備好將這些提供者集合起來(lái)使用，實(shí)現(xiàn)最初的業(yè)務(wù)需求。這種集合根據(jù)業(yè)務(wù)需求來(lái)合成和設(shè)計(jì)服務(wù)，為 Purchasing 服務(wù)提供一種方法。我們將創(chuàng)建一個(gè) OrderProcessor 合成要素，為處理定購(gòu)單提供一個(gè)購(gòu)買服務(wù)。這個(gè)服務(wù)提供者要求服務(wù)被 InvoicingService、Scheduling 和 ShippingService 服務(wù)規(guī)范定義。我們將創(chuàng)建一個(gè) OrderProcessing 合成要素，它集合了 Invoicer、Productions 和 Shipper 合成要素的實(shí)例，以及 OrderProcessor 合成要素，從而執(zhí)行處理定購(gòu)單的操作。

Order Processor 服務(wù)提供者

定購(gòu)單處理服務(wù)由 Purchasing 服務(wù)規(guī)范指定（請(qǐng)參見(jiàn)圖4），該規(guī)范包括如下功能（或者操作）：

+ processPurchaseOrder (customerInfor : Customer, purchaseOrder : PurchaseOrder) : Invoice

這一服務(wù)將由 OrderProcessor 服務(wù)提供者提供。OrderProcessor 是一個(gè)合成要素，它通過(guò)將其他服務(wù)提供者（根據(jù)需求契約設(shè)計(jì)的）連接在一起來(lái)提供一個(gè)服務(wù)。也就是說(shuō)被提供的服務(wù)方法的某些方面被設(shè)計(jì)用來(lái)以某種方式使用其他服務(wù)提供者。這一合成要素通過(guò)它的購(gòu)買服務(wù)端口提供 Purchasing 接口。所有的消費(fèi)者接口都是通過(guò)這個(gè)端口的，從而將消費(fèi)者客戶端從同合成要素同其他服務(wù)消費(fèi)者或者提供者的相互作用中分割出來(lái)。這樣做限制了模型中的耦合性，隨著市場(chǎng)和服務(wù)消費(fèi)者和提供者的變化能夠更容易的做出改變。

OrderProcessor 合成要素的組織展現(xiàn)在圖5中所示的 Project Explorer 視圖中。

OrderProcessor 服務(wù)提供者包含在 org::ordermanagement 包中，它用于組織同定購(gòu)管理相關(guān)的服務(wù)。定購(gòu)管理包也包含相關(guān)的服務(wù)接口、服務(wù)消費(fèi)者和服務(wù)提供者。

圖6中顯示的 OrderProcessor 圖表提供了 OrderProcessor 服務(wù)者及其提供的和要求的服務(wù)的一個(gè)外部視圖。（要求的服務(wù)有時(shí)被稱作請(qǐng)求，以便同功能需要相區(qū)分。）外部的或者叫做“黑盒”視圖是呈現(xiàn)給服務(wù)提供者的消費(fèi)者查看的。稍后將顯示的合成要素的內(nèi)部結(jié)構(gòu)提供了一個(gè)支持合成要素的執(zhí)行設(shè)計(jì)結(jié)構(gòu)的一個(gè)內(nèi)部的或者叫做“白盒”的視圖。

外部視圖不是一個(gè)從執(zhí)行中分離出來(lái)的規(guī)范；它僅僅是合成要素某些方面的視圖。如果架構(gòu)師或者開(kāi)發(fā)人員希望完全的將服務(wù)提供者的規(guī)范從它的可能執(zhí)行中分離出來(lái)，就將使用到規(guī)范合成要素。規(guī)范合成要素定義了一個(gè)服務(wù)消費(fèi)者和服務(wù)提供者之間的契約，它從特定的提供者執(zhí)行中減弱了它們。規(guī)范合成要素能夠被許多具體的合成要素識(shí)別出來(lái)，這些要素以一種識(shí)別契約的方式提供服務(wù)，并且提供服務(wù)的可接受的質(zhì)量。請(qǐng)參見(jiàn)“SOA 建模: 第二部分 服務(wù)規(guī)范”獲得更多細(xì)節(jié)。

OrderProcessor 服務(wù)提供者要素十分簡(jiǎn)單和穩(wěn)定，在這個(gè)例子中，架構(gòu)師和開(kāi)發(fā)人員決定不使用服務(wù)規(guī)范。結(jié)果是，使用 OrderProcessor 合成要素的任何服務(wù)消費(fèi)者都將同這個(gè)特定的執(zhí)行相聯(lián)系。這是不是一個(gè)充分的設(shè)計(jì)取決于有多少服務(wù)將被使用，以及隨著時(shí)間的推移它們將發(fā)生多大程度的改變。只有解決方案架構(gòu)師能夠決定一個(gè)特定的系統(tǒng)能夠容忍什么程度的耦合性。

OrderProcessor 合成要素也擁有反映有其他服務(wù)提供者（貨品計(jì)價(jià)、時(shí)間表、運(yùn)送）提供的需要請(qǐng)求的服務(wù)端口。這些服務(wù)提供者提供了 OrderProcessor 合成要素用來(lái)執(zhí)行其被提供的服務(wù)操作的那些服務(wù)。

每一個(gè)服務(wù)交互作用點(diǎn)都涉及到一個(gè)簡(jiǎn)單協(xié)議，該協(xié)議影響被提供的和被要求的接口。例如，貨品計(jì)價(jià)交互作用點(diǎn)要求 Invoicing 接口啟動(dòng)價(jià)格計(jì)算器，并且發(fā)送運(yùn)送價(jià)格。然而，它可能會(huì)花費(fèi)一些時(shí)間來(lái)計(jì)算運(yùn)送價(jià)格，所以 OrderProcessor 通過(guò)其貨品計(jì)價(jià)端口來(lái)提供 InvoiceProcessing 接口，從而使得貨品計(jì)價(jià)服務(wù)提供者能夠在其準(zhǔn)備好時(shí)發(fā)送一張發(fā)貨單。

潛在的耦合性問(wèn)題 請(qǐng)注意在這個(gè)例子中有一個(gè)潛在的設(shè)計(jì)問(wèn)題，它可能導(dǎo)致意想不到耦合性。定購(gòu)處理服務(wù)提供者如何同在同一個(gè)業(yè)務(wù)過(guò)程（活動(dòng)）中被捕獲的貨品計(jì)價(jià)進(jìn)行相互作用的規(guī)則，就像同生產(chǎn)時(shí)間表和運(yùn)送服務(wù)提供者相互作用的規(guī)則一樣。這使得在沒(méi)有復(fù)制交互作用協(xié)議的情況下，復(fù)用貨品計(jì)價(jià)、時(shí)間表和運(yùn)送服務(wù)很困難。 這種耦合性作用經(jīng)常是由業(yè)務(wù)過(guò)程服務(wù)操作的直接執(zhí)行造成的。業(yè)務(wù)過(guò)程模型關(guān)注一個(gè)活動(dòng)完成一個(gè)特定的業(yè)務(wù)目標(biāo)所必須的那些步驟，例如有效的定購(gòu)處理。它們并不需要關(guān)注如何復(fù)制那些步驟來(lái)增加內(nèi)聚性，減少耦合性，使復(fù)用變得便捷、最小化分布式通訊、處理網(wǎng)絡(luò)安全性、管理持久數(shù)據(jù)的完整性，等等。這些都是 IT 解決方案關(guān)注的問(wèn)題，必須使用軟件架構(gòu)和實(shí)用的并且經(jīng)過(guò)證明的設(shè)計(jì)模式來(lái)處理。 使用服務(wù)契約，提供了一種形式上捕獲業(yè)務(wù)需求的方法，同時(shí)允許復(fù)制架構(gòu)的服務(wù)提供者，同時(shí)滿足業(yè)務(wù)需求并且處理 IT 解決方案的關(guān)注。架構(gòu)的解決方案和業(yè)務(wù)需求之間的鏈接使通過(guò)契約實(shí)現(xiàn)的，它將服務(wù)提供者的各部分同它們?cè)诜?wù)契約中所扮演的角色綁定在一起。在這個(gè)例子中，我們不再對(duì)這些設(shè)計(jì)問(wèn)題作進(jìn)一步的處理，但是我們會(huì)顯示如何將服務(wù)解決方案鏈接到它所完成的業(yè)務(wù)需求上面。

Order Processor 執(zhí)行設(shè)計(jì)模型

我們現(xiàn)在完成了服務(wù)模型的架構(gòu)，并且在服務(wù)提供者的外部視圖中捕獲到它。下一步就是為 OrderProcessor 合成要素所提供的 processPurchaseOrder 服務(wù)操作提供一種方法。這種方法必須遵循任何一個(gè)已經(jīng)完成的服務(wù)契約或者已經(jīng)實(shí)現(xiàn)的服務(wù)規(guī)范，也要遵循那些操作已經(jīng)被定義的服務(wù)規(guī)范。

內(nèi)部結(jié)構(gòu)

OrderProcessor 服務(wù)提供者通過(guò)它的購(gòu)買服務(wù)端口提供了一個(gè)簡(jiǎn)單的服務(wù)規(guī)范 Purchasing。這個(gè)服務(wù)規(guī)范指定了一個(gè)簡(jiǎn)單的操作 processPurchaseOrder。服務(wù)提供者必須為它所提供的全部服務(wù)操作提供一些方法。在這個(gè)例子中，我們使用 Activity 作為 processPurchaseOrder 服務(wù)操作的方法。有關(guān)的細(xì)節(jié)被顯示在提供服務(wù)的 OrderProcessor 合成要素的內(nèi)部結(jié)構(gòu)中。OrderProcessor 內(nèi)部結(jié)構(gòu)在圖表、接口、類和活動(dòng)中被捕獲，如圖7中的 Project Explorer 視圖和圖8中的復(fù)合結(jié)構(gòu)圖表所示。

Project Explorer 視圖顯示了 OrderProcessor 提供者各個(gè)部分的列表，以及每一個(gè)被提供的操作的方法（行為）。在這個(gè)例子中所使用的約定是，使用一個(gè)和合成要素名稱一致的類圖表，并且在包含該合成要素的包中，顯示它的外部視圖。這就是圖6和圖7中所顯示的圖表。同合成要素具有同樣名稱并且被包含在合成要素中的復(fù)合結(jié)構(gòu)圖表，提供了服務(wù)提供者結(jié)構(gòu)的內(nèi)部視圖。這個(gè)圖表直接位于圖7中的 OrderProcessor 服務(wù)提供者的下面。這些約定能夠更好的協(xié)調(diào)服務(wù)參與者的外部和內(nèi)部視圖，并且如同合成要素一樣仔細(xì)研究圖表。

OrderProcessor 復(fù)合結(jié)構(gòu)圖表如圖8所示，提供了一個(gè)服務(wù)提供者的內(nèi)部結(jié)構(gòu)的總體視圖。再一次顯示了合成要素的合成靜態(tài)結(jié)構(gòu)的各個(gè)部分（端口和屬性）。

OrderProcessor 合成要素的內(nèi)部視圖很簡(jiǎn)單。它由用于被提供的和被要求的接口的服務(wù)端口、加之許多其他保持服務(wù)提供者狀態(tài)的屬性共同合成。屬性 ID 被用來(lái)識(shí)別服務(wù)提供者的實(shí)例。這個(gè)屬性將被用來(lái)動(dòng)態(tài)的關(guān)聯(lián)消費(fèi)者和提供者的交互作用。屬性 schedule 和 shippingInfo 是在 processPurchaseOrder 服務(wù)操作的執(zhí)行中被使用的信息。

被提供的服務(wù)操作的方法

由服務(wù)提供者所提供的每一項(xiàng)服務(wù)操作必須通過(guò)以下兩種方式之一被實(shí)現(xiàn)：

• Behavior （Activity、Interaction、StateMachine 或者 OpaqueBehavior），它是操作的方法；
• 屬于合成要素的一個(gè) Activity 中的 AcceptEventAction （異步調(diào)用）或者 AcceptCallAction （同步需求或者回復(fù)調(diào)用）。

OrderProcessor 合成要素包含兩種服務(wù)實(shí)現(xiàn)風(fēng)格的例子。processPurchaseOrder 操作擁有一個(gè)同樣名字的方法活動(dòng)。這一活動(dòng)，如圖9所示，是提供服務(wù)操作的服務(wù)提供者所擁有的一種行為。

這個(gè)圖表同用于相同行為的 WebSphere Business Modeler 圖表非常符合。InvoiceProcessing 和 ScheduleProcessing 服務(wù)操作通過(guò)過(guò)程中的 processInvoice 和 processSchedule 接收事件行動(dòng)被實(shí)現(xiàn)。請(qǐng)注意接口中的相應(yīng)操作被指示為觸發(fā)器操作，它指出響應(yīng) AcceptCallActions 的能力（類似于接收和 AcceptEventActions，此處觸發(fā)器是一個(gè) SignalEvent）。關(guān)鍵字觸發(fā)器并不是 UML 2 的一部分，它只是用來(lái)強(qiáng)調(diào)這些操作是如何實(shí)現(xiàn)的。

注釋：
除非 processPurchaseOrder 活動(dòng)正在運(yùn)行，并且控制流程已經(jīng)到達(dá)兩個(gè)接收呼叫行動(dòng)，否則這些操作將不會(huì)被接收。這指示出一個(gè)操作的執(zhí)行能夠決定其他操作何時(shí)將被響應(yīng)。

實(shí)現(xiàn)服務(wù)契約

OrderProcessor 合成要素至此已經(jīng)完成。但是還有兩件事沒(méi)有做：

1. 首先，我們需要將 OrderProcessor 服務(wù)提供者同對(duì)其需求進(jìn)行建模的業(yè)務(wù)過(guò)程相結(jié)合。
2. 其次，我們需要?jiǎng)?chuàng)建一個(gè)子系統(tǒng)，將能夠提供 OrderProcessor 需求接口的服務(wù)提供者和適當(dāng)?shù)姆?wù)端口連接起來(lái)。

術(shù)語(yǔ) IBM? Software Services Profile 將服務(wù)協(xié)作描述為“一組服務(wù)根據(jù)某些過(guò)程規(guī)范以一種經(jīng)過(guò)協(xié)議的方式共同行動(dòng)”。這從本質(zhì)上說(shuō)是一個(gè)契約，它指定了一組服務(wù)如何被連接和設(shè)計(jì)，以達(dá)到某些目標(biāo)，例如另一個(gè)服務(wù)應(yīng)該如何被執(zhí)行或者某些業(yè)務(wù)目標(biāo)將如何被實(shí)現(xiàn)。服務(wù)協(xié)作還能夠用來(lái)形式上描述需要滿足的需求。WebSphere Business Modeler 業(yè)務(wù)過(guò)程模型和 Rational Software Architect UML 建模之間的綜合，被設(shè)計(jì)為開(kāi)發(fā)協(xié)作，就像描述需求的角色中心方法一樣。當(dāng)它在 Rational Software Architect 中被打開(kāi)的時(shí)候，它將 WebSphere Business Modeler 業(yè)務(wù)過(guò)程視作一個(gè)協(xié)作。 術(shù)語(yǔ)服務(wù)協(xié)作、服務(wù)需求契約和業(yè)務(wù)服務(wù)需求契約都表示相似的意義，并且都使用協(xié)作來(lái)描述一組共同使用的服務(wù)的需求。這些不同的術(shù)語(yǔ)只不過(guò)是關(guān)注上下文環(huán)境中協(xié)作的特定使用。

本小節(jié)中的操作不會(huì)對(duì) OrderProcessor 合成要素如何轉(zhuǎn)變?yōu)橐粋€(gè) SOA 執(zhí)行產(chǎn)生任何改變。將合成要素鏈接到服務(wù)契約，只是描述合成要素如何完成那些契約所指定的需求。這并不影響服務(wù)提供者的執(zhí)行或者它將如何被轉(zhuǎn)變?yōu)橐粋€(gè) SOA 解決方案。然而，聯(lián)接較之依賴要復(fù)雜得多。它特定的顯示服務(wù)提供者的各個(gè)部分在服務(wù)需求契約中扮演什么角色，以及合成元素完成業(yè)務(wù)的約束。這提供了更加豐富的可追溯性，對(duì)有細(xì)密紋理的變化管理的支持，以及使用模型驗(yàn)證解決方案確實(shí)滿足它們的需求的能力。

圖10使用一個(gè)服務(wù)契約顯示了 OrderProcessor 服務(wù)提供者的需求，該服務(wù)契約提供了一張由業(yè)務(wù)分析師創(chuàng)建的業(yè)務(wù)過(guò)程的角色中心視圖。一個(gè)協(xié)作使用被添加到 OrderProcessor 服務(wù)提供者中，指出它所完成的服務(wù)契約。

圖10中被稱作契約的的協(xié)作使用，是圖11中所顯示的 Purchase Order Process 服務(wù)協(xié)作的一個(gè)實(shí)例。這指定了 OrderProcessor 服務(wù)提供者完成 Purchase Order Process 業(yè)務(wù)需求。角色綁定指示出服務(wù)提供者的哪一個(gè)部分在服務(wù)契約中扮演哪一個(gè)角色。例如，貨品計(jì)價(jià)端口扮演貨品計(jì)價(jià)角色，購(gòu)買端口扮演 orderProcessor 角色。

這些角色綁定和下一小節(jié)中所描述的服務(wù)信道連接器并不相關(guān)。服務(wù)信道連接器被用來(lái)連接子系統(tǒng)中的消費(fèi)者請(qǐng)求和提供者服務(wù)。角色綁定指定了該部分在服務(wù)契約中扮演什么角色。角色綁定既可以是嚴(yán)格的也可以使松散的。嚴(yán)格的契約完成意味著各個(gè)部分必須同它們所綁定到的角色類型一致。松散的契約完成意味著各個(gè)部分將會(huì)根據(jù)架構(gòu)師的要求扮演那些角色，但是模型驗(yàn)證并不驗(yàn)證角色和部分功能。也就是說(shuō)，或許因?yàn)闃I(yè)務(wù)服務(wù)契約不完全，或者只有業(yè)務(wù)需求的概略信息。

顯示 SOA 解決方案如何完成業(yè)務(wù)需求要花費(fèi)額外的工作來(lái)指定契約和角色綁定，但是它提供了一個(gè)管理變化的有利條件。模型查詢可能被用來(lái)決定哪一個(gè)服務(wù)提供者完成什么業(yè)務(wù)需求。需求中的任何改變將可能導(dǎo)致服務(wù)協(xié)作中的其中一個(gè)角色的變化。建模器于是能夠直接定位到扮演那些角色的部分，決定代表那些可能需要改變的角色的服務(wù)規(guī)范如何處理需求中的變化。模型驗(yàn)證也能夠被用來(lái)決定某些角色是否被改變，以及在 SOA 解決方案中扮演該角色的各個(gè)部分不再有能力執(zhí)行角色的所有責(zé)任。這較之用例實(shí)現(xiàn)的不具備支持語(yǔ)義或者松散語(yǔ)義的老套依賴要強(qiáng)大得多。正是這種類型的形式，可驗(yàn)證的 SOA 解決方案和業(yè)務(wù)需求之間的連接器（確保解決方案是業(yè)務(wù)相關(guān)的，滿足需求，并且是敏捷的解決方案），才能夠便于適應(yīng)改變。

組裝 OrderProcessing 子系統(tǒng)

在我們的 SOA 解決方案中，最后要做的就是創(chuàng)建一個(gè) OrderProcessing 子系統(tǒng)，它使用我們一直執(zhí)行的服務(wù)提供者將各部分裝配到一個(gè)可配置的解決方案之中。

這個(gè)子系統(tǒng)如圖12所示，它反映了一個(gè)將 OrderProcessor 服務(wù)提供者同其他提供其需求服務(wù)的服務(wù)提供者連接起來(lái)的可配置的合成要素。這個(gè)子系統(tǒng)是提供所有配置和運(yùn)行 OrderProcessor 服務(wù)的必要信息的合成要素的一個(gè)集合。

OrderProcessing 子系統(tǒng)包括 OrderProcessor、Invoicer、Productions 和 Shipper 服務(wù)提供者合成要素的實(shí)例。銷售者合成要素的貨品計(jì)價(jià)服務(wù)同 Invoicer 合成要素的貨品計(jì)價(jià)服務(wù)相連接。這是一個(gè)有效的連接，因?yàn)?OrderProcessor 合成要素的貨品計(jì)價(jià)服務(wù)的服務(wù)規(guī)范，正是 Invoicer 提供者的貨品計(jì)價(jià)服務(wù)的變形。OrderProcessor 合成要素要求 Invoicing 接口，它是由 Invoicer 服務(wù)提供者所提供的。它還為 Invoicer 提供了 InvoiceProcessing 接口，接收更新的貨品計(jì)價(jià)。

連接服務(wù)（服務(wù)規(guī)范的實(shí)例）意味著參與者同意根據(jù)服務(wù)規(guī)范相互作用連接器。也就是說(shuō)，它們同意遵守被要求的協(xié)議。服務(wù)規(guī)范定義了協(xié)議中被連接的參與者所扮演的角色。orderProcessor 消費(fèi)者的貨品計(jì)價(jià)端口和貨品計(jì)價(jià)提供者的貨品計(jì)價(jià)端口之間的服務(wù)信道連接器擁有一個(gè)契約（行為），這個(gè)行為是 InvoicingService 服務(wù)規(guī)范的 InvoicingService 行為。連接器的名稱根據(jù)約定被設(shè)置為其契約的名稱。任何經(jīng)過(guò)這個(gè)連接器的交互作用都被要求遵守契約或者協(xié)議。這些連接器將服務(wù)架構(gòu)中的使用依賴形式化了。

請(qǐng)注意，生產(chǎn)者和銷售者部分之間的連接器沒(méi)有契約。這是因?yàn)樵?Scheduling 服務(wù)接口中沒(méi)有協(xié)議，所以該連接器不需要契約。

其他消費(fèi)者和提供者以相似的方式被連接起來(lái)。連接的服務(wù)能夠提供不同的綁定風(fēng)格。服務(wù)相互作用點(diǎn)之間的服務(wù)信道能夠指定實(shí)際使用的綁定風(fēng)格。

OrderProcessing 子系統(tǒng)現(xiàn)在已經(jīng)完成，并且做好被配置的準(zhǔn)備。它已經(jīng)指定了服務(wù)提供者完全執(zhí)行 processPurchaseOrder 服務(wù)所必須的所有被需要的實(shí)例。在它被配置以后，其他服務(wù)消費(fèi)者能夠綁定到銷售者 OrderProcessor 合成要素的購(gòu)買服務(wù)，并且調(diào)用該服務(wù)操作。

總結(jié)和下一步工作的展望

至此，我們已經(jīng)完成了服務(wù)、消費(fèi)者和提供者達(dá)到業(yè)務(wù)目標(biāo)所必須的識(shí)別、規(guī)范和實(shí)現(xiàn)。結(jié)果得到一個(gè)和技術(shù)無(wú)關(guān)的但是完全的架構(gòu)服務(wù)解決方案的設(shè)計(jì)模型。

要實(shí)際運(yùn)行這一解決方案，我們需要?jiǎng)?chuàng)建一個(gè)同服務(wù)模型中被捕獲的架構(gòu)設(shè)計(jì)決定相一致的平臺(tái)執(zhí)行。我們能夠?qū)⒃撃Ｐ妥鳛橄驅(qū)?，通過(guò)手工來(lái)創(chuàng)建這個(gè)解決方案。但是這樣做非常冗雜、易出錯(cuò)、費(fèi)時(shí)間、并且需要一個(gè)高水平的開(kāi)發(fā)人員確保架構(gòu)決定能夠正確的被執(zhí)行。當(dāng)然可以通過(guò)手工來(lái)創(chuàng)建解決方案，并且將該模型作為向?qū)б彩欠浅Ｓ袔椭?。但是，一個(gè)完全的、正式的、經(jīng)過(guò)驗(yàn)證的模型才能使我們有機(jī)會(huì)進(jìn)行模型驅(qū)動(dòng)的開(kāi)發(fā)（MDD），從模型中創(chuàng)建一個(gè)解決方案的骨干，然后在特定平臺(tái)編程環(huán)境中完成細(xì)節(jié)的編碼。這正是下一篇，也就是本系列最后一篇文章：“SOA 建模: 第五部分 服務(wù)執(zhí)行”中的內(nèi)容。在那篇文章中，我們使用 Rational Software Architect UML-to-SOA 轉(zhuǎn)換特性，創(chuàng)建一個(gè)能夠直接在 WebSphere Integration Developer 中執(zhí)行、測(cè)試和配置的完整的 Web 服務(wù)解決方案。

參考資料

• 您可以參閱本文在 develperWorks 全球網(wǎng)站上的 英文原文。
  
  
• 由 Jim Amsden 撰寫的 SOA 建模: 第 1 部分 服務(wù)識(shí)別，即本系列五部曲中的開(kāi)篇之作，其內(nèi)容關(guān)于基于面向服務(wù)的架構(gòu)（SOA）的軟件開(kāi)發(fā)。（IBM? developerWorks?，2007年10月）
  
  
• 由 Jim Amsden 撰寫的 SOA 建模: 第 2 部分 服務(wù)規(guī)范，對(duì) SOA 解決方案每一個(gè)服務(wù)的規(guī)范進(jìn)行詳細(xì)的建模。（IBM? developerWorks?，2007年10月）
  
  
• 由 Jim Amsden 撰寫的 SOA 建模: 第 3 部分 服務(wù)實(shí)現(xiàn)，介紹基于 SOA 的 Web 服務(wù)如何被實(shí)際實(shí)現(xiàn)。（IBM? developerWorks?，2007年10月）
  
  
• 由 Ali Arsanjani 撰寫的 基于服務(wù)的建模和架構(gòu): 如何為你的 SOA 鑒別、指定和實(shí)現(xiàn)服務(wù)，關(guān)于 IBM Global Business Services 的面向服務(wù)的建模和架構(gòu)（SOMA）的方法。（IBM? developerWorks?，2004 年 11 月）
  
  
• IBM Business service modeling，是由 Jim Amsden 撰寫的一篇 developerWorks 文章（2005 年 12 月），文章描述了業(yè)務(wù)過(guò)程建模和服務(wù)建模之間的關(guān)系，獲得兩者的利益。
  
  
• “使用模型驅(qū)動(dòng)開(kāi)發(fā)和基于模式的工程來(lái)設(shè)計(jì) SOA，第 2 部分: 基于模式的工程”，IBM develperWorks 指南系列四部曲的第二部分（2007 年）。
  
  
• “使用 Rational Software Architect 設(shè)計(jì) SOA 服務(wù)”，IBM developerWorks 指南系列四部曲（2006 年 - 2007 年）。
  
  
• “用 Rational Software Architect 建立面向服務(wù)的體系結(jié)構(gòu)（Service-Oriented Architecture）的模型，第 3 部分: 外部系統(tǒng)建模”，IBM developerWorks 指南系列六部曲的第 3 部分（2007年）。
  
  
• 為面向服務(wù)的解決方案建模，是 Simon Johnston 的一篇著名文章，文章描述了服務(wù)建模驅(qū)動(dòng)面向軟件服務(wù)的 UML Profile 以及面向 SOA 插件程序的 RUP 的開(kāi)發(fā)方法。（developerWorks，2005 年 7 月）
  
  
• 用于軟件服務(wù)的 UML 2.0 Profile，也是由 Simon Johnston 撰寫的（developerWorks，2005 年 7 月），文章描述了面向軟件服務(wù)的 UML Profile，即一種允許對(duì)服務(wù)、面向服務(wù)的體系架構(gòu)（SOA）、以及面向服務(wù)的解決方案進(jìn)行建模的 UML 2.0 規(guī)范。該規(guī)范現(xiàn)在已經(jīng)在 IBM Rational Software Architect 中被執(zhí)行。
  
  
• 由 Donald Ferguson 和 Marcia Stockton 撰寫的 用于實(shí)現(xiàn) Web 服務(wù)的 SOA 編程模型，第 1 部分: IBM SOA 編程模型簡(jiǎn)介 （developerWorks，2005年6月），描述了面向服務(wù)的架構(gòu)（SOA）的 IBM 編程模型，它使得非編程人員能夠創(chuàng)建和復(fù)用 IT 資產(chǎn)。該模型包括組件類型、配線、模板、應(yīng)用程序適配器、統(tǒng)一的數(shù)據(jù)表示、和 Enterprise Service Bus (ESB)。這篇文章是關(guān)于 IBM SOA 編程模型和選擇、開(kāi)發(fā)、配置和推薦程序模型元素需求的內(nèi)容的系列文章的開(kāi)篇之作。
  
  
• 服務(wù)數(shù)據(jù)對(duì)象(Service Data Objects) 單一化并且統(tǒng)一化了應(yīng)用程序訪問(wèn)和操作不同種類數(shù)據(jù)源的方法。
  
  
• 請(qǐng)參見(jiàn) Business Process Execution Language for Web Services 來(lái)了解更多關(guān)于 BPEL 1.1 規(guī)范的知識(shí)。
  
  
• 訂閱 developerWorks Rational zone newsletter。時(shí)刻關(guān)注 developerWorks Rational 的內(nèi)容。每隔一個(gè)星期，您都將收到 Rational Software Delivery Platform 最新的技術(shù)資源和最佳實(shí)踐的更新。
  
  
• 瀏覽 技術(shù)書店 來(lái)獲得更多技術(shù)主題的書籍。
  
  

• 下載面向 SOMA 方法的 Rational Unified Process 插件程序：IBM RUP for Service-Oriented Modeling and Architecture。您必須具備 IBM Rational Method Composer 來(lái)安裝該插件程序。
  
  
• 下載 RUP plug-in for SOA，使用 IBM Software Services Profile 對(duì)面向服務(wù)的 Rational Unified Process 插件程序進(jìn)行建模。
  
  
• IBM SOA Sandbox IBM SOA Sandbox 提供了完全版本軟件試驗(yàn)和 “在線試用” 主機(jī)環(huán)境（在此您能夠探索指南并且獲得架構(gòu)的指導(dǎo)）的一種混合。
  
  
• 下載試用版本：IBM Rational Software Architect V7。
  
  
• 下載 IBM 產(chǎn)品評(píng)估版本，并且從 DB2?，Lotus?，Rational?，Tivoli? 和 WebSphere? 中獲得應(yīng)用程序開(kāi)發(fā)工具和中間件產(chǎn)品。
  
  

• 查看 developerWorks 博客，并且參與到 developerWorks 社區(qū) 當(dāng)中。
  
  
• Rational Software Architect、Data Architect、Software Modeler、Application Developer 和 Web Developer 論壇：提出關(guān)于 Rational Software Architect 的問(wèn)題。

關(guān)于作者

		Jim Amsden 是一名 IBM 的高級(jí)技術(shù)人員，在應(yīng)用程序設(shè)計(jì)和開(kāi)發(fā)以及軟件開(kāi)發(fā)行業(yè)工具方面有二十多年的經(jīng)驗(yàn)。他持有波士頓大學(xué)的計(jì)算機(jī)科學(xué)碩士學(xué)位。他的興趣點(diǎn)包括基于契約的開(kāi)發(fā)，代理編程，業(yè)務(wù)驅(qū)動(dòng)開(kāi)發(fā)，J2EE UML，以及面向服務(wù)架構(gòu)方面。他也是 "Enterprise Java Programming with IBM WebSphere" 一書的合著者。他目前關(guān)注于如何集成工具以更好地支持敏捷開(kāi)發(fā)過(guò)程。