使用UML建模的復(fù)合RESTful Web服務(wù)

使用UML建模的復(fù)合RESTfulWeb服務(wù)摘要Web服務(wù)組合的過(guò)程涉及到不同的參與者在互聯(lián)網(wǎng)上發(fā)布的web服務(wù)，相比于遠(yuǎn)程過(guò)程調(diào)用（RPC）Web服務(wù)而言狀態(tài)代表性傳輸（REST）Web服務(wù)采取了不同的體系風(fēng)格。在本文中，我們針對(duì)在Web服務(wù)組成的背景下的這些差異，激發(fā)引出RESTful接口的新設(shè)計(jì)技術(shù)的需求，我們提出了一個(gè)基于UML的建模方法的RESTWeb服務(wù)組成來(lái)為其靜態(tài)和行為特征的組成建模。這些模型通過(guò)構(gòu)造、作為規(guī)范文檔的一部分，已經(jīng)映射到多個(gè)Web實(shí)現(xiàn)語(yǔ)言和可以用來(lái)驗(yàn)證一個(gè)RESTful組成來(lái)提供了RESTful的組成。我們以酒店及機(jī)票預(yù)訂RESTful的復(fù)合Web服務(wù)為例說(shuō)明了這個(gè)方法的適用性。1刖言一個(gè)Web服務(wù)通過(guò)標(biāo)準(zhǔn)的網(wǎng)絡(luò)協(xié)議向一個(gè)軟件系統(tǒng)提供一個(gè)遠(yuǎn)程接口這些接口是處于機(jī)器能處理的形式，他們的功能不需要人的過(guò)多介入就能夠被機(jī)器操控oWeb服務(wù)可以以遠(yuǎn)程過(guò)程調(diào)用（RPC）的方式發(fā)展，或者作為一個(gè)狀態(tài)代表性傳輸（REST）Web服務(wù)。RPC風(fēng)格的Web服務(wù)以操作為中心，他通過(guò)在其接口上設(shè)置操作說(shuō)明來(lái)展現(xiàn)其功能。與此相反，REST風(fēng)格的Web服務(wù)是以數(shù)據(jù)為中心的，他在其開(kāi)源代碼中展現(xiàn)其功能，這種源代碼更像是類(lèi)中的對(duì)象一樣以能夠控制的數(shù)據(jù)向目標(biāo)服務(wù)傳達(dá)信息。一個(gè)Web服務(wù)組合利用已經(jīng)存在的Web服務(wù)提供構(gòu)建在這些現(xiàn)存的Web服務(wù)頂端的新的功能。他使已經(jīng)發(fā)布的Web服務(wù)的重用更為容易，把不同地方的不同已經(jīng)發(fā)展的服務(wù)通過(guò)不同賣(mài)方組合成一個(gè)整體。精心安排服務(wù)對(duì)發(fā)展一個(gè)組合Web服務(wù)來(lái)說(shuō)是一個(gè)通用的方法，在精心安排服務(wù)中，相關(guān)聯(lián)的服務(wù)組合過(guò)程對(duì)其中的參與者是不可見(jiàn)的，有一個(gè)核心過(guò)程控制并協(xié)調(diào)相關(guān)聯(lián)的Web服務(wù)的執(zhí)行。對(duì)于RPC風(fēng)格的Web服務(wù)，有BPEL4WS和WSCI等不同的流程組成語(yǔ)言存在，他們定義控制和數(shù)據(jù)流，這些控制和數(shù)據(jù)流決定何時(shí)應(yīng)該執(zhí)行某個(gè)特定操作。BusinessProcessExecutionLanguage（BPEL）是一種被用來(lái)實(shí)現(xiàn)一個(gè)Web服務(wù)組合的組成規(guī)范的語(yǔ)言此匕外，為了組建RPC風(fēng)格的Web服務(wù)組合，也提出了許多建模方法。然而，RESTWeb服務(wù)按照不同的體系風(fēng)格，因而他需要不同的設(shè)計(jì)理念和技術(shù)。一個(gè)RESTfulWeb服務(wù)是這樣設(shè)計(jì)的，它的接口提供定址能力，連通性，統(tǒng)一的接口和無(wú)狀態(tài)。因此，一個(gè)復(fù)合的RESTfulWeb服務(wù)也提供一個(gè)RESTWeb服務(wù)的基本特征。他應(yīng)該展示他們地址和代表的資源，這些資源應(yīng)該有連通性，提供統(tǒng)一的接口和在具體資源中調(diào)用一個(gè)方法的輸出應(yīng)該是能夠被觀察的。相比于RPC風(fēng)格，RESTWeb服務(wù)的這個(gè)不同的設(shè)計(jì)理念需要新的設(shè)計(jì)技術(shù)。我們必須明白復(fù)合RESTWeb服務(wù)的資源和方法是如何映射到伙伴網(wǎng)絡(luò)服務(wù)的資源和方法的。在此背景下，我們感覺(jué)我們需要一個(gè)可視化表示形式來(lái)幫助我們理解在產(chǎn)生復(fù)合RESTWeb服務(wù)的設(shè)計(jì)階段，RESTful的特點(diǎn)是如何被處理的。本文中，我們提出了一個(gè)基于UML的建模方法通過(guò)構(gòu)造來(lái)設(shè)計(jì)RETSTfulWeb服務(wù)。建模方法的使用方便了RESTful體系風(fēng)格基本概念和設(shè)計(jì)需求與實(shí)現(xiàn)細(xì)節(jié)相獨(dú)立的目標(biāo)的理解。我們用類(lèi)圖、活動(dòng)圖和狀態(tài)機(jī)圖為復(fù)合RESTfulWeb服務(wù)的靜態(tài)和動(dòng)態(tài)行為建模。本文圍繞組合過(guò)程的建模和其接口實(shí)現(xiàn)的精煉，我們力爭(zhēng)以一種復(fù)雜方式傳遞基本概念時(shí)保持方法的簡(jiǎn)單。文章組織如下：第2部分提出了呈現(xiàn)工作的背景，第3部分給出了此方法的綜述，第4部分給出了資源模式的概念，緊隨其后的第5部分和第6部分給出了行為模式的概念。在第5部分我們呈現(xiàn)了過(guò)程模型，復(fù)合RESTful接口的建模將在第6部分中詳細(xì)闡述。第7部分包含了相關(guān)的工作，第8部分推斷未來(lái)要做的工作。2背景相比于與以操作為中心的RPC風(fēng)格的Web服務(wù)，一個(gè)RESTful體系風(fēng)格呈現(xiàn)出了一個(gè)數(shù)據(jù)為中心的行為。RESTful體系風(fēng)格的主要特點(diǎn)有：可尋址能力，統(tǒng)一接口，連接和無(wú)狀態(tài)?？蓪ぶ纺芰σ笕魏闻c服務(wù)相關(guān)的相關(guān)信息都要作為一種資源呈現(xiàn)，每個(gè)資源有一個(gè)或多個(gè)唯一地址和有一個(gè)或多個(gè)可遠(yuǎn)程訪問(wèn)的代表。為了實(shí)現(xiàn)連接，資源代表應(yīng)該包含到其他資源的連接以至于通過(guò)資源和他們的連接形成的圖形是相連接的為了達(dá)到統(tǒng)一的接口，所有資源在一個(gè)相同的方法集下操作。在HTTPWeb服務(wù)案例，其方法是GET（HEAD），POSE,PUT和DELETE。還有一個(gè)標(biāo)準(zhǔn)的狀態(tài)代碼或者異常的集合用于發(fā)送方法成功或者是失敗的信號(hào)。無(wú)狀態(tài)的特征要求一個(gè)方法是其輸入?yún)?shù)和可尋址資源的函數(shù)。這就是說(shuō)，沒(méi)有隱藏的會(huì)話(huà)或者是狀態(tài)信息。此外GET，POSE,PUT和DELETE操作的效果在影響資源時(shí)應(yīng)該能夠被觀察到。這些特征使得RESTfulweb服務(wù)與因特網(wǎng)上現(xiàn)存的工具和基礎(chǔ)設(shè)施相處融洽，互聯(lián)和統(tǒng)一接口的特征允許利用現(xiàn)存的工具和基礎(chǔ)設(shè)施如rawlers,curl,caches等等，可尋址要求（特別是使用層次化地址時(shí)）幫助我們創(chuàng)造可擴(kuò)展的veb服務(wù)。無(wú)狀態(tài)要求簡(jiǎn)化可以同時(shí)處理很多的服務(wù)請(qǐng)求的便于擴(kuò)展的系統(tǒng)的發(fā)展。當(dāng)前，RESTfulweb服務(wù)在網(wǎng)頁(yè)中廣泛的被采用，現(xiàn)在已經(jīng)有大量的使用者，其中包括Google，Yahoo，Amazon和Flicker一個(gè)web服務(wù)組合過(guò)程結(jié)合不同位置的可能可用服務(wù)和不同發(fā)布者可能發(fā)布的服務(wù)來(lái)提供新的web服務(wù)，這些web服務(wù)組合常常假定被業(yè)務(wù)目標(biāo)所驅(qū)動(dòng)和用一種流程規(guī)范語(yǔ)言分開(kāi)描述。這些復(fù)合web服務(wù)像一個(gè)黑盒子提供給最終用戶(hù)，僅僅通過(guò)操作所聲明的接口才能調(diào)用他們。一個(gè)接口的規(guī)范僅僅包含關(guān)于他們能夠被調(diào)用的操作的句法信息，信息能夠在服務(wù)之間被交換的流程用一種流程規(guī)范語(yǔ)言分開(kāi)描述。對(duì)于RPC風(fēng)格的web服務(wù)，網(wǎng)頁(yè)服務(wù)描述語(yǔ)言2.0（WSDL）常常用作接口規(guī)范，WSDL提供關(guān)于一個(gè)服務(wù)允許和定義的在服務(wù)操作之間作為信息傳遞的數(shù)據(jù)的操作信息接口規(guī)范語(yǔ)言是句法的，方法調(diào)用順序的信息被如BPEL4WS的流程規(guī)范語(yǔ)言所定義。然而，一個(gè)RESTful組合服務(wù)必須展示RESTful體系的特征，下面為RESTfulBPEL流程的定義列出了三種可能的機(jī)制：WSDL2.0對(duì)HTTP的綁定：用標(biāo)準(zhǔn)的BPEL4WS描述（如調(diào)用操作）和通過(guò)綜合的WSDL2.0描述引導(dǎo)調(diào)用。在WSDL綁定中，操作被映射到URLs和HTTP方法（如操作映射成資源1和PUT方法）。REST通過(guò)適配器:從一個(gè)標(biāo)準(zhǔn)的BPEL過(guò)程通過(guò)產(chǎn)生仿造的WSDL來(lái)用RESTful服務(wù)，這個(gè)仿造WSDL描述REST接口，然后產(chǎn)生一個(gè)RESTful服務(wù)通信的適配器。某些BPEL引擎通過(guò)WADL描述也支持交互。為REST擴(kuò)展BPEL:擴(kuò)展BPEL（和BPEL引擎）為了其直接支持RESTful活動(dòng)（如在一個(gè)特定的范圍內(nèi)支持GET,PUT,POST,和DELETE活動(dòng)）。方法1和2的優(yōu)勢(shì)在于對(duì)BPEL語(yǔ)言不需要任何的修改和目前實(shí)現(xiàn)的BPEL引擎。另一方面，WSDL是面向操作的web服務(wù)的一種描述語(yǔ)言，他沒(méi)有完全遵守面向資源的RESTful服務(wù)的語(yǔ)義。在［12，10］，Pautasso用第三種方法，他建議為7REST而擴(kuò)展BPEL。這種方法有幾個(gè)優(yōu)點(diǎn)，比如，支持后期綁定和動(dòng)態(tài)資源。在傳統(tǒng)的PEL_WS過(guò)程中，不支持服務(wù)的動(dòng)態(tài)綁定，作為服務(wù)的末端點(diǎn)是開(kāi)始就決定了的，任何的改變都需要客戶(hù)改變或者更新他們的WSDLs。這樣，這是在第三種方法中這是一個(gè)重要的優(yōu)勢(shì)。這里我們總結(jié)BPEL_WS和BPEL_REST的主要的不同點(diǎn)，正如C.Pautasso在［12,10］中提倡的那樣。在BPEL_WS中，只定義了一種活動(dòng)調(diào)用類(lèi)型，在BPEL_REST中對(duì)每個(gè)HTTP操作都定義了一種不同的活動(dòng)調(diào)用。BPEL_REST引入了資源的概念，資源概念允許定義和發(fā)布資源。他定義運(yùn)行消息處理，這在資源的范圍內(nèi)是可用的。請(qǐng)求處理器的內(nèi)部行為可以用標(biāo)準(zhǔn)BPEL構(gòu)造指定(也就是<sequence>,<if>,<flow><while>etc.)。然而，屬于不同處理器的跨活動(dòng)的控制流連接是不允許的。我們利用這部分呈現(xiàn)出的關(guān)于RESTfulweb服務(wù)組合的信息去呈現(xiàn)一種建模方法，這種建模方法簡(jiǎn)化RESTfulweb服務(wù)的概念和他們的組合過(guò)程。在下一部分中，我們提出了我們的建模方法的一個(gè)綜述，這個(gè)建模方法是利用JML為復(fù)合RESTfulWEB服務(wù)的設(shè)計(jì)進(jìn)行建模。3綜述本文中，我們提出了一種支持RESTfulweb服務(wù)組合的建模方法。我們要求這個(gè)RESTfulweb服務(wù)組合應(yīng)該展示REST接口的特征，比如：可尋址能力，連接性，統(tǒng)一接口和無(wú)狀態(tài)。由于不是從操作的視角組合web服務(wù)網(wǎng)絡(luò)，RESTful風(fēng)格的web服務(wù)組合與傳統(tǒng)的web服務(wù)組合技術(shù)不同，RESTful組合聚焦于資源。RESTfulweb服務(wù)把資源作為構(gòu)建的基礎(chǔ)，在典型的REST發(fā)展環(huán)境，為了保持設(shè)計(jì)簡(jiǎn)單和允許最大化的去耦合，新資源是可見(jiàn)的。這樣，RESTful組合web服務(wù)必須考慮不同搭檔服務(wù)的資源和如何標(biāo)準(zhǔn)化組合web服務(wù)在搭檔web服務(wù)上調(diào)用相應(yīng)操作的方法調(diào)用。在我們的先前工作中，我們已經(jīng)提出了一個(gè)為RESTfulweb服務(wù)建模和產(chǎn)生行為接口規(guī)范的方法。在這篇文章中，我們把我們的工作擴(kuò)展到支持復(fù)合RESTfulweb服務(wù)。我們?yōu)閺?fù)合RESTfulweb服務(wù)的靜態(tài)和動(dòng)態(tài)特征建模，我們的建模方法如圖形1所示。我們以表現(xiàn)復(fù)合RESTfulweb服務(wù)靜態(tài)特征的資源概念性模型開(kāi)始。資源概念性模型通過(guò)一個(gè)類(lèi)代表一個(gè)資源的類(lèi)圖來(lái)呈現(xiàn)，他提供有關(guān)資源的可用性，他們的代表，相關(guān)地址和連通性的信息。這時(shí)我們用這個(gè)資源概念性模型建模我們的組合過(guò)程RESTful服務(wù)的組合行為首先描述為用順序圖，然后處理流程轉(zhuǎn)化為活動(dòng)圖。處理流程表現(xiàn)為過(guò)程發(fā)送信息，過(guò)程接受信息。最后，這個(gè)過(guò)程的信息精化成為一個(gè)狀態(tài)機(jī)這個(gè)狀態(tài)機(jī)提供有關(guān)組合是如何被定義的和實(shí)現(xiàn)和組合的使用來(lái)提供RESTful行為的限制的詳細(xì)信息。我們假設(shè)搭檔服務(wù)是RESTful的，他們的資源模型是可用的或者在組合過(guò)程用他們之前能夠建立好。這種假設(shè)在為組合web服務(wù)提供RESTful接口時(shí)為我們提供幫助。由于為了知道搭檔服務(wù)提供的功能使他們成為組合過(guò)程的一部分，我們首先必須理解搭檔服務(wù)，所以我們認(rèn)為這不是一個(gè)有力的假設(shè)。這個(gè)模型被認(rèn)為是web服務(wù)規(guī)范文檔的一部分，他不需要任何的來(lái)自復(fù)合RESTfulweb服務(wù)(CRWS)的額外支持。我們運(yùn)用了一個(gè)酒店和航班預(yù)訂服務(wù)組合的例子，他用于房間預(yù)RESTfulweb服務(wù)和航班預(yù)訂RESTfulweb服務(wù)。這個(gè)組合服務(wù)并行的提供了預(yù)定房間和航班的服務(wù)，向用戶(hù)提供總的需要支付的款項(xiàng)和提供付款確認(rèn)信息。預(yù)定可以被取消除非是正在等待第三方的服務(wù)確認(rèn)。取消的預(yù)定可以被刪除。在下以部分中，我們?yōu)镃RWS呈現(xiàn)了資源概念性模型。4資源概念性模型RESTfulweb服務(wù)的資源概念性模型顯示了有關(guān)的資源，資源代表的屬性，資源之間的連接和從一個(gè)資源到另外一個(gè)資源的導(dǎo)航路徑。UML類(lèi)圖建模RESTful復(fù)合web服務(wù)的結(jié)構(gòu)特征。我們酒店和航班預(yù)定服務(wù)組合的資源概念性模型如圖2所示。他自己有五個(gè)資源，即預(yù)定HF，取消HF預(yù)定，支付HF款項(xiàng)和證實(shí)HF預(yù)定，兩個(gè)來(lái)自其搭檔的web服務(wù)，即預(yù)定酒店和預(yù)定航班。資源之間的關(guān)聯(lián)顯示資源之間的連接。我們要求在圖形中沒(méi)有孤立的資源，所有資源形成了一個(gè)聯(lián)通圖。關(guān)聯(lián)的箭頭提供了導(dǎo)航的方向，關(guān)聯(lián)的角色定義了從一個(gè)資源到其他資源的導(dǎo)航路徑。如為了到達(dá)資源取消HF，我們要跟隨如下路徑/預(yù)定HF/{bid}/取消HF/。搭檔web服務(wù)資源可以從搭檔資源連接到CRWS資源進(jìn)行導(dǎo)航。如酒店預(yù)定服務(wù)的支付資源可以用如下路徑導(dǎo)航：/預(yù)定HF/{bid}/預(yù)定F/{bid}/支付7。集合資源形式化表示為《collection》，他包含一系列的資源。在圖2中，預(yù)定HF資源是一個(gè)集合資源，其GET方法將返回所有預(yù)定資源的列表（預(yù)定HF）。這些資源被認(rèn)為是我們概念性模型的主要資源其他所以資源的導(dǎo)航都要通過(guò)他為了結(jié)合搭檔web服務(wù)的資源，這個(gè)組合服務(wù)的主要資源通過(guò)所有其他資源的導(dǎo)航被連接至搭檔服務(wù)的資源。在圖5,CRWS的預(yù)定HF分別與搭檔服務(wù)的預(yù)定航班和預(yù)定酒店相關(guān)聯(lián)。1在搭檔web服務(wù)關(guān)聯(lián)結(jié)束的多樣性意味著在HFCRWS上做的預(yù)定必須是對(duì)房間和航班都有預(yù)定。和搭檔web服務(wù)的資源的關(guān)聯(lián)顯示了在CRWS設(shè)計(jì)中的連接和可尋址能力的特征。因?yàn)榭臻g的限制，我們沒(méi)有展示搭檔web服務(wù)的概念性資源模型。圖1：基于模型的RESTful組合的方法除了搭檔web服務(wù)的資源，復(fù)合RESTfulweb服務(wù)擁有自己的資源。這些資源在概念性模型中被建模成類(lèi)。這些資源的描述被當(dāng)作公共屬性展示。資源的建模屬性公開(kāi)指明表示資源描述的公開(kāi)的操控。取消HF,支付HF,和確認(rèn)HF保持通過(guò)組合服務(wù)接口所做預(yù)定的記錄，這些資源中的方法所能被調(diào)用的信息在概念性模型中沒(méi)有被展示，因?yàn)槲覀冋J(rèn)為他們?cè)谶@里是必須的。這是因?yàn)闃?biāo)注的HTTP方法，GET,TUT,POSE和DELETE，能過(guò)被任何資源所調(diào)用。概念性模型提供CRWS的架構(gòu)布局。我們用這個(gè)架構(gòu)模型去表示我們?cè)诘?和第6部分的行為模型。下以部分，陳述RESTful過(guò)程建模。5RESTful過(guò)程建模在WS_BEPL過(guò)程建模時(shí)，UML活動(dòng)圖和BPMN的符號(hào)相同。提議WS_BPEL概述UMLProfile用老的BPEL1.0規(guī)范和UML1.4，但是對(duì)于如何把BPEL_WS過(guò)程映射到UML活動(dòng)圖提供了指導(dǎo)。UML2.0概述WS_BPEL也已經(jīng)被提出來(lái)了。Ruokonen等在［15］中的先前工作展示了為創(chuàng)建BPEL_WS活動(dòng)模型的基于UML的方法，這方法能產(chǎn)生可執(zhí)行的BPEL_WS描述。通過(guò)結(jié)合已經(jīng)存在的工作，我們致力于提出模型構(gòu)建，為BPEL_REST過(guò)程給出UML活動(dòng)圖。我們的目標(biāo)是利用在概念性模型中定義的資源為預(yù)定航班和酒店RESTful過(guò)程建模。過(guò)程的場(chǎng)景，預(yù)定航班和酒店，如圖3所示，預(yù)定HF是一個(gè)過(guò)程，他是作為RESTfu組合服務(wù)而被實(shí)現(xiàn)的。另外，預(yù)定HF實(shí)用三個(gè)外部的RESTful服務(wù)：預(yù)定酒店，預(yù)定航班，支付款項(xiàng)。實(shí)際的資源結(jié)構(gòu)在圖中沒(méi)有展示出來(lái)，他僅僅描述了過(guò)程和他的參與者的交互。在概念性模型中，如圖2所示，所有資源都被定義了，但是這里我們僅僅對(duì)服務(wù)交互進(jìn)行建模。然而，從URI結(jié)構(gòu)，我，可以看到/預(yù)定HF和確認(rèn)HF是預(yù)定HF的子資源，。這樣，他們是預(yù)定航班和酒店服務(wù)提供的接口的一部分。從場(chǎng)景模型，我們想要?jiǎng)?chuàng)建一個(gè)實(shí)現(xiàn)了預(yù)定酒店和航班場(chǎng)景的過(guò)程描述。我們的目標(biāo)是一個(gè)與BPEL_REST兼容的過(guò)程模型。為了構(gòu)建這個(gè)過(guò)程模型，我們?cè)跁?huì)話(huà)中以預(yù)定HF服務(wù)的視角建模。這意味著通過(guò)預(yù)定日卜服務(wù)發(fā)送和接受信息。順序圖發(fā)送消息的事件在活動(dòng)圖中表現(xiàn)為調(diào)用，而接收消息事件意味著過(guò)程接收了一個(gè)操作調(diào)用。在圖4中，預(yù)定酒店和航班過(guò)程的一個(gè)面向工作流的模型作為活動(dòng)圖被展示出來(lái)。這和傳統(tǒng)的建模BPEL過(guò)程是一致的。每個(gè)操作都可以被調(diào)用的條件在工作流描述中定義，包含用戶(hù)交互的是工作流°POST/預(yù)定HF和POST/預(yù)定HF/支付HF被用戶(hù)調(diào)用。這意味著過(guò)程執(zhí)行之前必須要等待用戶(hù)的輸入。下面列表展示了在建模PBEL_REST過(guò)程中如何用UML模型結(jié)構(gòu)。圖2：HF復(fù)RESTfulWeb服務(wù)的概念性模型

:Cufitonvr:Dookingel-IP:Qo^king'SPIight:快okingsRowl:Cufitonvr:Dookingel-IP:Qo^king'SPIight:快okingsRowl::Paym頑5：|6：('payrnenii-r)|rt7:POSTr/tjiMKingsHFp^irnaioiHF^?BPEL_REST與UML活動(dòng)圖的映射：HTTP調(diào)用get,put,post,和delete被建模成調(diào)用行為活動(dòng)X分別是原語(yǔ)feet》,《put》《post》，《delete》）onPut,onGet,onPost,和onDelete活動(dòng)。onPost建模成一個(gè)調(diào)用行為活動(dòng)（原語(yǔ)6nPost》）onGut建模成一個(gè)調(diào)用行為活動(dòng)（原語(yǔ)?nGut》）onPut建模成一個(gè)調(diào)用行為活動(dòng)（原語(yǔ)?nPut》）onDelete建模成一個(gè)調(diào)用行為活動(dòng)（原語(yǔ)6nDelete》）responset建模成一個(gè)調(diào)用行為活動(dòng)（原語(yǔ)《responset》）sequence建模成一個(gè)控制流和BPEL_WS的onMessage不同，RESTful消息處理可以有內(nèi)部結(jié)構(gòu)，這樣他們也可以被建模成包含response活動(dòng)和可能包含一些其他的if-else結(jié)構(gòu)的結(jié)構(gòu)化活動(dòng)。另一方面,onPut和response可以被建模成一對(duì)簡(jiǎn)單的活動(dòng)，他們之間可能隱含活動(dòng)的順序。相同的應(yīng)用當(dāng)然可以用于其他的信息處理。由于模型的局限性，屬于不同信息處理器的橫跨活動(dòng)連接是不被允許的?；顒?dòng)模型的資源可以被建模成結(jié)構(gòu)化的活動(dòng)，他包含他所支持的所有信息處理器。然而，我們的目標(biāo)是簡(jiǎn)化工作流模型，在活動(dòng)圖中到處我們想要的行為。服務(wù)組合，如復(fù)合服務(wù)，相比BPEL過(guò)程作為復(fù)合服務(wù)，觀點(diǎn)上有輕微的不同。例如，如果我們想建立預(yù)定酒店和航班過(guò)程或者一個(gè)相同目標(biāo)的組合服務(wù)，其使用的方法是有一些不同的。更加明顯的，將會(huì)用到不同的建模方法°BPEL過(guò)程從一個(gè)參與者的視角描述會(huì)話(huà)，如，過(guò)程本身。這里，我們決定在活動(dòng)圖中僅僅建模一個(gè)純凈的工作流。為了使過(guò)程模型完整，資源結(jié)構(gòu)的建模在第6部分給予考慮。圖4：預(yù)定酒店和航班過(guò)程6建模復(fù)合RESTful接口我們用UML狀態(tài)機(jī)為CRWS的行為模型建模。他提供了web服務(wù)的行為接口規(guī)范和定義了方法調(diào)用的正確順序，基于方法應(yīng)該被調(diào)用的條件和這些方法的與其條件。在前面部分展示的過(guò)程模型。在RESTful組合過(guò)程中提供活動(dòng)流信息。在這部分，我們精化活動(dòng)圖到狀態(tài)機(jī)。在精化步驟中，發(fā)送信息(過(guò)程調(diào)用)映射成狀態(tài)機(jī)的實(shí)體活動(dòng)?；顒?dòng)圖的接收消息(過(guò)程接收信息)被映射成狀態(tài)機(jī)的狀態(tài)轉(zhuǎn)換。我們要求每個(gè)狀態(tài)有一個(gè)布爾功能，如：一個(gè)狀態(tài)不變量，當(dāng)給定狀態(tài)是活動(dòng)的他就we哦真，否者為假。轉(zhuǎn)換導(dǎo)致系統(tǒng)狀態(tài)的改變并表示為箭頭，方法調(diào)用表示為轉(zhuǎn)換的加速。轉(zhuǎn)換調(diào)用前要求滿(mǎn)足的條件被標(biāo)記在箭頭上作為指導(dǎo)，完成一個(gè)轉(zhuǎn)換的預(yù)期條件在轉(zhuǎn)換中被有效的注釋出來(lái)。以前，我們利用UML協(xié)議的狀態(tài)機(jī)去描述每個(gè)web服務(wù)的行為接口?，F(xiàn)在我們擴(kuò)展我們的狀態(tài)機(jī)到搭檔資源的動(dòng)作和資源信息來(lái)展示復(fù)合RESTfulweb服務(wù)的完整的行為接口。圖5展示了我們HF預(yù)定復(fù)合服務(wù)的行為模型。在狀態(tài)層次的頂層，狀態(tài)機(jī)有一個(gè)標(biāo)準(zhǔn)的狀態(tài)——取消HF，和一個(gè)組合狀態(tài)——預(yù)定。在資源預(yù)定F針對(duì)狀態(tài)預(yù)定中，狀態(tài)機(jī)被初始化為POST方法。組合狀態(tài)預(yù)定，是三個(gè)組合狀態(tài)的更深組合，即reserveandpay,waitingforpconfirmatioi和pconfirmationinfo酒店房間和航班的預(yù)留和支付是并行做的。在狀態(tài)reserveandpa和waitingforpconfirmatioi被正交狀態(tài)所展示。這就意味著僅僅在這兩個(gè)服務(wù)已經(jīng)支付的基礎(chǔ)上第三方的服務(wù)才會(huì)被調(diào)用以確定支付。支付的確認(rèn)來(lái)自搭檔服務(wù)的個(gè)體的支付服務(wù)。除了在等待第三方確認(rèn)的時(shí)候之外，預(yù)定任何時(shí)候都可以被取消。當(dāng)一個(gè)取消預(yù)定被刪除時(shí)，他也分別刪除了酒店預(yù)定和航班預(yù)定服務(wù)的記錄。行為模型的每個(gè)狀態(tài)都包含了一個(gè)狀態(tài)不變量。我們狀態(tài)機(jī)的狀態(tài)不變量是布爾表達(dá)式，他也考慮了HTTP方法的響應(yīng)代碼。當(dāng)我們?cè)谫Y源上調(diào)用HTTP方法時(shí)，他返回一個(gè)響應(yīng)代碼。這個(gè)響應(yīng)代碼告訴發(fā)送者這個(gè)請(qǐng)求是成功還是失敗。響應(yīng)代碼00指定方法調(diào)用成功，響應(yīng)代碼404指定方法調(diào)用不成功和請(qǐng)求的資源不存在。我們行為模型的狀態(tài)不變量是基于比較資源中GET方法的響應(yīng)代碼和異常的響應(yīng)代碼oOK(r)代表在資衡上GET的響應(yīng)代碼為200。NOT_FOND代表在資源r上GET的響應(yīng)代碼為404。例如，讓我們考慮圖5所示的組合狀態(tài)預(yù)定的狀態(tài)不變量，即，OK(bHF)&&OK(bF)&&OK(bH)&&OK(r)&&OK(f)&&NOTFOUNKcHF)。他是由OK(r)和NOT_FOUND(r)在HF復(fù)合服務(wù)的資源上的功能和調(diào)用搭檔web服務(wù)所組合的布爾表達(dá)式。圖5中的狀態(tài)機(jī)僅僅在上面的布爾表達(dá)式的值為真時(shí)能夠變成預(yù)定狀態(tài)。子狀態(tài)的狀態(tài)不變量由子狀態(tài)的狀態(tài)不變量聯(lián)合他包含的所有狀態(tài)的狀態(tài)不變量給出。例如，子狀態(tài)reserverdnotpaid的狀態(tài)不變量NOTFOUND(pcHF)&&NOTFOUND(pcF)是聯(lián)合他所包含的所有上層狀態(tài)的狀態(tài)不變量來(lái)得到eserverdnotpaid的狀態(tài)不變量的。在行為模型中方法的調(diào)用描述為了得到相應(yīng)功能方法應(yīng)該被調(diào)用的順序這限制我們的CRWS提供所需要功能的實(shí)現(xiàn)。例如，如圖5所示，只有在支付資源的POST已經(jīng)調(diào)用時(shí)，確認(rèn)資源上的POST才能夠被調(diào)用。在我們的概念性模型中，我們也沒(méi)有包含方法由于RESTfulweb服務(wù)提供統(tǒng)一接口和每個(gè)資源用標(biāo)準(zhǔn)的HTTP方法GET,PUT,POST,DELETE操作而能在資源上調(diào)用方法的信息。我們現(xiàn)在針對(duì)在行為模型資源上允許的方法。在行為模型上顯示資源上允許的方法和方法能夠被調(diào)用的條件。例如，除非我們創(chuàng)建了取消IF資源，否則我們不能在預(yù)定上調(diào)用DELETE操作。這樣，我們可以說(shuō)我們的行為模型不僅限制復(fù)奇ESTfulweb服務(wù)的實(shí)現(xiàn)，也限制服務(wù)的使用。我們要求GET方法可以在任何資源上被調(diào)用。bH:陶心氓制呼師用/bF：itic<rfdrq5HEibtt>kirKi5FqbTdltoCikulgsHF^jS：fciiii^HFuF.心kHbH:陶心氓制呼師用/bF：itic<rfdrq5HEibtt>kirKi5FqbTdltoCikulgsHF^jS：fciiii^HFuF.心kH圖*1巳IkjukiIig訐W感VwnIFpHF;SokingGHFribidl燦ymRnXpH:他奶ibg計(jì)IFltJuuklr中Wfg祚■呵pF.(bookingitH^ibocjIyncj^F^JbidypaTi'i'wi'iFJpcHF;mofcl叩sHFffb?曲MF.pcunflrrnalknMFREhi:沁puKingstVjbKl*囹Ihni祜ligriHptF.^KKikiiTgsfrFi^hidFp^^^^F.rpcKiririirnaliu-iF在復(fù)合RESTweb服務(wù)上調(diào)用方法會(huì)出發(fā)相應(yīng)搭檔Web服務(wù)資源上的方法。我們通過(guò)實(shí)體動(dòng)作或者作為有效的轉(zhuǎn)換對(duì)搭檔web服務(wù)上的風(fēng)發(fā)調(diào)用建模。被加入到狀態(tài)的實(shí)體動(dòng)作是無(wú)論是否進(jìn)入狀態(tài)都要被執(zhí)行的行為。國(guó)，不論在預(yù)定HF上POST是否被調(diào)用，都進(jìn)入狀態(tài)預(yù)定，轉(zhuǎn)換POST(bH)和POST(bF)都將被調(diào)用。轉(zhuǎn)換也在搭檔veb服務(wù)作為在復(fù)合web服務(wù)調(diào)用方法的結(jié)果而被加速也可以標(biāo)記在轉(zhuǎn)換上，這樣，萬(wàn)一目標(biāo)狀態(tài)是結(jié)尾狀態(tài)，，他就不要包含實(shí)體動(dòng)作。在幽中，加速方法DELETE(bHF)對(duì)在搭檔web服務(wù)酒店預(yù)定和航班預(yù)定上的方法調(diào)用)ELETE(bH)和DELETE(bF)分別產(chǎn)生影響。狀態(tài)機(jī)上不同的元素可以被3RWS用來(lái)表示行為展示，狀態(tài)reserveandpay和waitingforconfirmatior的聯(lián)合轉(zhuǎn)換顯示除非房間和航班都支付過(guò)來(lái)，否則不能進(jìn)入目標(biāo)狀態(tài)waitingforconfirmation相似的，在狀態(tài)pconfirmationinfO狀態(tài)的選中節(jié)點(diǎn)調(diào)用目標(biāo)狀態(tài)依賴(lài)于轉(zhuǎn)換上的指導(dǎo)條件。我們可以用如分支轉(zhuǎn)換，自轉(zhuǎn)換，高層轉(zhuǎn)換等等的狀態(tài)機(jī)的不同元素來(lái)提供RESTfulweb服務(wù)接口的豐富的行為規(guī)范。我們認(rèn)為利用狀態(tài)機(jī)的不同元素可以為接口提供豐富的行為信息。擁有豐富行為信息的行為模型可以作為規(guī)范文檔，在實(shí)現(xiàn)接口時(shí)指導(dǎo)復(fù)合web服務(wù)的發(fā)展。這個(gè)豐富的行為模型也可以用于產(chǎn)生合約和機(jī)器能夠處理的規(guī)范。