構(gòu)件化軟件服務(wù)及其在Ａｒｔｅｍｉｓ—ＡＲＣ系統(tǒng)中的應(yīng)用

摘 要：在Web服務(wù)的基礎(chǔ)上提出一種構(gòu)件化服務(wù)方法。它顯式化地描述了服務(wù)間的依賴關(guān)系，并保證了統(tǒng)一的功能抽象和良好的復(fù)用性。對構(gòu)件化服務(wù)的描述、搜索、集成等關(guān)鍵技術(shù)進行了討論；在基于Axis 和JBoss 基礎(chǔ)平臺以及Eclipse 公用環(huán)境的Atremis—ARC系統(tǒng)中初步實現(xiàn)了構(gòu)件化服務(wù)的思想。

關(guān)鍵詞：面向服務(wù)的計算； Web服務(wù)； 構(gòu)件； Web服務(wù)描述語言； 統(tǒng)一描述、發(fā)現(xiàn)和集成

中圖分類號：TP393文獻標(biāo)志碼：A

文章編號：1001—3695(2007)03—0169—04

近年來，Web服務(wù)、SOA、SOC等關(guān)于服務(wù)的概念和技術(shù)已經(jīng)逐漸成為學(xué)術(shù)界和工業(yè)界關(guān)注的焦點[1，2]。Web服務(wù)作為一種計算元素，具有自描述性和平臺無關(guān)性，其目的是為整合異構(gòu)平臺上的資源提供足夠的能力。在這種整合過程中，如果每個服務(wù)都從頭開發(fā)并不是一個好的策略，開發(fā)人員往往希望對現(xiàn)有服務(wù)采用擴充、限制、拼裝的方法來進行增量式開發(fā)。本文認(rèn)為，將服務(wù)構(gòu)件化，以類似基于構(gòu)件的軟件開發(fā)來組織Web服務(wù)的開發(fā)過程是一種可行的途徑。

顯然，在這種開發(fā)過程中，與已有服務(wù)之間進行的交互將十分重要，需要一種方法來描述服務(wù)之間的關(guān)系。目前許多研究都是在Web服務(wù)的原有功能描述層WSDL（Web Service Description Language， Web服務(wù)描述語言）上抽象出服務(wù)之間關(guān)系的定義并且通過新加入語言層來表達這種關(guān)系及其交互機制，典型的如BPEL4WS[3]。與本文工作類似的文獻[4]提出了Web Component的概念，也給出了對服務(wù)構(gòu)件化的討論。事實上也是在WSDL上以類似面向?qū)ο蟮姆椒ǘx了Web Component Class的結(jié)構(gòu)來保證服務(wù)之間的關(guān)系。本文認(rèn)為這類做法有以下兩點問題：①破壞了服務(wù)在功能描述這一抽象層次上的統(tǒng)一性，使得復(fù)雜服務(wù)（由高層語言描述）和簡單原始服務(wù)（由WSDL描述）在功能描述階段就已被區(qū)分開；②眾多的WSDL之上的語言層導(dǎo)致服務(wù)在描述上的異構(gòu)性，而這種異構(gòu)性又會降低服務(wù)的可集成性和可復(fù)用性。例如由Web Component和BPEL描述的服務(wù)要進行整合或復(fù)用就會因為各自基于不同的描述方法而產(chǎn)生困難。這一點恰恰違背了Web服務(wù)提出的目的。

本文認(rèn)為構(gòu)件化服務(wù)要在功能描述層達到統(tǒng)一，具體說就是在Web服務(wù)的WSDL描述上保證復(fù)雜服務(wù)與簡單服務(wù)的一致性，從而避免了在構(gòu)件化服務(wù)之上相關(guān)技術(shù)的異構(gòu)性。提出一種構(gòu)件化服務(wù)的方法，它具有兼容標(biāo)準(zhǔn)Web服務(wù)、可以被第三方組裝以及獨立部署等特性。在其關(guān)鍵技術(shù)上，通過擴展WSDL來進行構(gòu)件化服務(wù)功能描述，增強了注冊中心的服務(wù)搜索能力以及給出合適的構(gòu)件化服務(wù)集成框架。在基于Axis 和JBoss 基礎(chǔ)平臺以及Eclipse 公用環(huán)境的Artemis—ARC系統(tǒng)[5]中初步實現(xiàn)了構(gòu)件化服務(wù)的思想。

1 構(gòu)件化服務(wù)

構(gòu)件化服務(wù)要把服務(wù)間的依賴顯式地泛化到所有服務(wù)開發(fā)層次中，以打破開發(fā)的獨立性，從而保證任何服務(wù)在描述級別的統(tǒng)一性，達到服務(wù)可以在同一個概念和技術(shù)下進行多次復(fù)用的目的。而基于構(gòu)件的軟件開發(fā)（CBSD）是在一定構(gòu)件模型的支持下，復(fù)用構(gòu)件庫中的一個或多個軟件構(gòu)件，通過組合手段高效率、高質(zhì)量地構(gòu)造應(yīng)用軟件系統(tǒng)的過程。構(gòu)件間的依賴關(guān)系則成為復(fù)用和組合的基礎(chǔ)。構(gòu)件化服務(wù)正是借鑒了這種思想來描述和組織服務(wù)的。為了保證現(xiàn)有服務(wù)的可用性和構(gòu)件化服務(wù)在標(biāo)準(zhǔn)協(xié)議下的兼容性，本文的做法是在遵循標(biāo)準(zhǔn)Web服務(wù)技術(shù)的前提下，通過對相關(guān)技術(shù)和功能的擴充來引入構(gòu)件化服務(wù)。

本文認(rèn)為構(gòu)件化服務(wù)是一種可以組裝的Web服務(wù)。它具有統(tǒng)一的顯式交互接口描述，可以被獨立地部署并由第三方任意組裝。

構(gòu)件化服務(wù)基本框架如圖1所示。它與構(gòu)件以及標(biāo)準(zhǔn)Web服務(wù)相比，具有以下特點：

（1）從類別上看，構(gòu)件化服務(wù)屬于Web服務(wù)，兼容標(biāo)準(zhǔn)Web服務(wù)的協(xié)議：由WSDL描述服務(wù)、UDDI注冊和發(fā)現(xiàn)服務(wù)、SOAP訪問服務(wù)，支持Publish、Find、Bind過程；進行的擴展不會破壞原有服務(wù)的可用性。

（2）描述語言上，構(gòu)件化服務(wù)需要對服務(wù)間的依賴關(guān)系有明確的表達。在構(gòu)件技術(shù)中，接口是交互的基本單位和構(gòu)件之間關(guān)系的體現(xiàn)者，而IDL（接口描述語言）則實現(xiàn)了對其進行的描述。標(biāo)準(zhǔn)Web服務(wù)的描述語言無法描述服務(wù)間的這種依賴關(guān)系。所以通過對WSDL的擴展，顯式地表現(xiàn)出服務(wù)間交互的接口契約。保證服務(wù)在功能抽象級別上具有統(tǒng)一性，所有Web服務(wù)在構(gòu)件化的定義下將有一個統(tǒng)一的概念和技術(shù)平臺，對于簡單服務(wù)和復(fù)雜服務(wù)將不再有本質(zhì)的區(qū)別。

（3）服務(wù)搜索上，標(biāo)準(zhǔn)UDDI注冊中心為Web服務(wù)提供了良好的發(fā)布平臺以及最基本的搜索功能。但是當(dāng)構(gòu)件化服務(wù)發(fā)布到注冊中心時，服務(wù)間的依賴關(guān)系則潛在地成為注冊中心的內(nèi)在特性，所有的服務(wù)實際上構(gòu)成了一個所謂的服務(wù)空間。利用這種特點，本文在不改變注冊中心原有組織的情況下，引入在依賴基礎(chǔ)上的發(fā)現(xiàn)搜索方法，為服務(wù)的開發(fā)者和使用者提供更強大的功能。

（4）服務(wù)集成方式上，構(gòu)件化服務(wù)是在部署以后進行組裝，如圖1中的服務(wù)實際上是與已經(jīng)部署的服務(wù)發(fā)生了依賴關(guān)系而組裝的。組裝包括在功能層次描述和實現(xiàn)層次的綁定，這種機制也使得服務(wù)在復(fù)用時有了更多的靈活性（如擴充或定制）。組裝實施者則與構(gòu)件一樣，可以是任意的第三方，如圖1中所示；服務(wù)的組裝者和開發(fā)者可以是不同的。服務(wù)的開發(fā)方式與構(gòu)件類似，搜索用于組裝的部件成為開發(fā)開始階段的重要步驟。

圖1 構(gòu)件化服務(wù)的基本框架

1.1 構(gòu)件化服務(wù)的描述語言

構(gòu)件化服務(wù)描述語言不僅是整個構(gòu)件化服務(wù)實現(xiàn)的基礎(chǔ)，也是包括服務(wù)依賴關(guān)系的接口規(guī)約、服務(wù)集成方式以及服務(wù)庫的搜索的構(gòu)建基礎(chǔ)。本文認(rèn)為，對于依賴關(guān)系的描述是構(gòu)件化服務(wù)的關(guān)鍵。在構(gòu)件的IDL中有專門的語言設(shè)施來描述構(gòu)件間的交互接口契約。例如COBRA Component 3.0[6]給出了四種類型的Port來與COBRA的其他部分交互，其中的Facets（即通常所說的Provided Interfaces，它允許構(gòu)件向客戶端提供可以供其調(diào)用的接口視圖）和Receptacles（代表了構(gòu)件需要哪些接口來完成其自身功能，可以理解為Required Interfaces）加起來即可以表達接口間的關(guān)系。

然而WSDL語言[7]的主要功能集中在對單個服務(wù)的描述上，而對服務(wù)間的依賴關(guān)系描述能力較弱。WSDL中的接口（WSDL語法中的Port Type）支持四種類型的操作，即四種消息交換的原語：單向（One—way）、通知（Notification）、請求—響應(yīng)（Request—response）和懇求—響應(yīng)（Solicit—response）。雖然在任何一個WSDL接口中都可以任意地包含和組合這四種操作，即這四種消息交換原語提供了推和拉的交互機制。所謂推和拉，隱約可以相對應(yīng)到CCM構(gòu)件模型中的Facets和Receptacle。但是，必須在分析到WSDL文檔Port Type內(nèi)部的Operation中的屬性時，才可以知道方法是屬于Provided的還是Required的，即WSDL只是提供了在方法級別上的推和拉交互機制。顯然這不符合構(gòu)件以接口作為服務(wù)提供者與使用者之間橋梁的概念，交互力度由接口級下降到了方法級。并且在當(dāng)前對WSDL規(guī)范的應(yīng)用中基本上還是僅限于Provided的功能。

為了在服務(wù)功能描述級別提供依賴關(guān)系的描述，本文的做法是在WSDL的描述中顯式地描述出這種Provided和Required接口級別的語言設(shè)施（見附錄）。具體示例可參見2章的服務(wù)接口描述片斷。因此，一個構(gòu)件化服務(wù)既包含了服務(wù)所提供給用戶的可以調(diào)用的接口集合——Provided部分，又有服務(wù)本身需要導(dǎo)入的其他服務(wù)提供的接口——Required部分。服務(wù)依賴關(guān)系在接口上體現(xiàn)等同于一個集成的元模型來定義服務(wù)接口之間是如何交互的，簡單地說就是如何從一個服務(wù)的Provided接口匹配到另一個服務(wù)的Required接口。

1.2 構(gòu)件化服務(wù)注冊中心

傳統(tǒng)的UDDI注冊中心是用WSDL來描述服務(wù)的，通過服務(wù)的businessName和serviceName屬性進行匹配查找，這種做法使得搜索服務(wù)在兩個屬性中進行匹配，局限性較大。對于構(gòu)件化服務(wù)而言，服務(wù)的開發(fā)者往往是一個雙重身份，既是服務(wù)發(fā)布者同時又是需求者，只有在找到了合適的服務(wù)之后才可以完成進一步的開發(fā)。而體現(xiàn)這些最關(guān)鍵的就是構(gòu)件化服務(wù)間的依賴。所以UDDI注冊中心要能夠處理在搜索時細(xì)致到服務(wù)依賴信息，僅僅依靠businessName和serviceName屬性是不夠的，需要支持對接口屬性的分析，以方便找出Provided和Required類型。

本文的做法是借助服務(wù)間的依賴關(guān)系來幫助服務(wù)搜索。事實上，構(gòu)件化服務(wù)的開發(fā)有相當(dāng)一部分集中在與其他服務(wù)組裝以及組裝后的綁定上（從功能描述到實現(xiàn)的綁定）。而前提就是能夠搜索到足夠用于組裝的部件。這時，對注冊中心的搜索就需要給出更為復(fù)雜的搜索結(jié)果，給出構(gòu)件化服務(wù)間的服務(wù)依賴關(guān)系圖較為合適。考慮到現(xiàn)實中的服務(wù)注冊中心可以有龐大數(shù)量的服務(wù)存在，可能導(dǎo)致的結(jié)果是依賴關(guān)系過于復(fù)雜，從而降低搜索的效率。所以本文在搜索時已提供了一個代表搜索層數(shù)的參數(shù)，以控制搜索關(guān)系圖的大小。算法的結(jié)果是以欲搜索的服務(wù)為根的一棵或多棵樹組成的圖。樹中每個節(jié)點代表一個服務(wù)，邊代表服務(wù)間的Provide和Require關(guān)系。

事實上，對于注冊中心的所有服務(wù)而言，它們之間的依賴關(guān)系構(gòu)成了一個所謂的服務(wù)空間。任何一個單獨的構(gòu)件化服務(wù)以及其Require的服務(wù)形成一個依賴圖，實際上是該服務(wù)空間的一個子空間；而它的Provide功能又與其他服務(wù)的Require相匹配，使其存在于另一個子空間中。因此，當(dāng)每個服務(wù)發(fā)布到注冊中心時，也同時是一個將自身加入到原有服務(wù)空間中的過程。基于依賴關(guān)系的服務(wù)搜索算法如下：

算法：findAll，找出符合輸入條件的服務(wù)依賴關(guān)系

輸入：businessName、serviceName、portName

輸出：基于圖的依賴關(guān)系

1.3 構(gòu)件化服務(wù)的集成

對服務(wù)開發(fā)者而言，大部分開發(fā)過程均類似于構(gòu)件的復(fù)用組裝過程。開發(fā)過程包括三個階段，即計劃和搜索、描述和定義、實現(xiàn)。

如某數(shù)據(jù)處理公司A希望開發(fā)一個數(shù)據(jù)分析服務(wù)，他們的優(yōu)勢在于獨到的數(shù)據(jù)處理算法。原先的服務(wù)不進行數(shù)據(jù)預(yù)處理（如去噪聲）和數(shù)據(jù)后期加工（如報表生成），通常客戶必須提供直接有效的數(shù)據(jù)并由自己處理直接返回的結(jié)果。現(xiàn)在，該公司打算提供更加完善的數(shù)據(jù)處理服務(wù)，包括整套流程，即預(yù)處理（如數(shù)據(jù)去噪）、分析計算（自己的優(yōu)勢服務(wù)）和后期加工（報表生成等）。所以，整個過程可以描述如下：

（1）計劃和搜索階段。先通過搜索構(gòu)件化服務(wù)注冊中心，搜索需要的數(shù)據(jù)預(yù)處理和后期加工的現(xiàn)有服務(wù)，再計劃通過拼裝、擴充、限制的方法使用這些搜索到的服務(wù)以完成完整的業(yè)務(wù)流程。

（2）描述和定義階段。對完整的服務(wù)在功能層面上進行描述，用到擴展的WSDL。將搜索到的服務(wù)通過Require關(guān)聯(lián)到其服務(wù)中，同時自己的數(shù)據(jù)分析算法則由自己開發(fā)。最后公司將整個數(shù)據(jù)加工過程作為一個Provide服務(wù)功能。（3）實現(xiàn)階段。實現(xiàn)數(shù)據(jù)分析部分的功能并完成綁定和發(fā)布。

2 實現(xiàn)以及在Artemis—ARC系統(tǒng)中的應(yīng)用

Artemis—ARC是一個面向服務(wù)的動態(tài)協(xié)同架構(gòu)系統(tǒng)，該系統(tǒng)為具有動態(tài)調(diào)整能力的面向服務(wù)的應(yīng)用開發(fā)、運行提供了一套可視化的集成環(huán)境[5]。它基于Axis 和JBoss 基礎(chǔ)平臺以及Eclipse 公用環(huán)境，以可視化的集成界面支持面向構(gòu)件化服務(wù)的應(yīng)用集成和系統(tǒng)運行監(jiān)控。在Artemis—ARC系統(tǒng)中實現(xiàn)了一個完整的構(gòu)件化服務(wù)計劃、開發(fā)、部署和管理平臺，并且采用了這種基于構(gòu)件化服務(wù)的應(yīng)用開發(fā)；同時還具有構(gòu)件化服務(wù)的訪問、發(fā)現(xiàn)和發(fā)布能力。

Artemis—ARC中構(gòu)件化服務(wù)在實現(xiàn)協(xié)議上體現(xiàn)了多樣化支持。為了擴充服務(wù)集成的原材料，構(gòu)件化服務(wù)在實現(xiàn)上引入了對成熟構(gòu)件技術(shù)的支持，如EJB。針對每一個構(gòu)件技術(shù)都有各自上下文和訪問協(xié)議的問題，在Artemis—ARC中本文使用的方法是要求服務(wù)提供者需要在服務(wù)WSDL文件的服務(wù)綁定和實現(xiàn)細(xì)節(jié)上進行擴充定制，而用SOAP協(xié)議包裝特定的訪問協(xié)議。

圖2展示了Artemis—ARC的工作環(huán)境，并且提供了一個構(gòu)件化服務(wù)的應(yīng)用實例，代表上文中所提到的數(shù)據(jù)服務(wù)的例子。半圓的Port代表Required接口，圓形的Port代表Provided的接口。該服務(wù)接口的描述片斷如下：

圖2 一個數(shù)據(jù)分析服務(wù)的例子

如圖2所示，A是支持完整流程的數(shù)據(jù)服務(wù)，B和C是已存在于網(wǎng)絡(luò)上的服務(wù)。A服務(wù)Required兩個服務(wù)B和C的接口進行數(shù)據(jù)預(yù)處理和后期加工，而A本身則著重于數(shù)據(jù)分析過程算法的實現(xiàn)以及服務(wù)組裝，最后提供一個統(tǒng)一的Provided服務(wù)接口完成整套服務(wù)。結(jié)合Provided服務(wù)接口描述片斷可以看到，該服務(wù)的輸入消息為RawDataMsg，代表原始的預(yù)處理數(shù)據(jù)；輸出消息為DelicateResponse，代表后期加工過的結(jié)果。在服務(wù)內(nèi)部，實際上采用了一個Pipe Filter結(jié)構(gòu)。輸入RawDataMsg經(jīng)由預(yù)處理服務(wù)B得到去噪的數(shù)據(jù)CleanDataMsg，然后交給該公司得力的數(shù)據(jù)分析功能去進行運算，得到未經(jīng)后期輸出加工的結(jié)果RoughResult。最后將RoughResult交給C服務(wù)完成輸出的加工（生成報表），產(chǎn)生最終返回結(jié)果Delicate￣Response。

3 相關(guān)工作

構(gòu)件技術(shù)是以軟件重用為初衷而發(fā)展起來的[8]。基于構(gòu)件的軟件開發(fā)遵循購買而不創(chuàng)建（Buy， Don’t Build）的開發(fā)哲學(xué)[9]，讓人們由“一切從頭開始”的程序編制轉(zhuǎn)向軟件組裝。它不同于以往的軟件開發(fā)之處是利用集成技術(shù)來體現(xiàn)重用，正如Szyperski在文獻[10]中所提出的 “構(gòu)件是用來集成”的觀點。在構(gòu)件的研究領(lǐng)域，基于語境的組合機制(Contextual Composition)占有重要的地位[10]。而構(gòu)件化服務(wù)的組裝過程可以看成是這種組合機制在Web服務(wù)下的一個擴充。

在面向服務(wù)的計算環(huán)境中，Web服務(wù)描述語言[7]、動態(tài)定位Web服務(wù)UDDI[11]、服務(wù)訪問協(xié)議（Simple Object Access Protocol， SOAP）使Web服務(wù)顯示出一種與整個Internet環(huán)境中的服務(wù)交互的能力，足夠動態(tài)查詢服務(wù)描述和綁定服務(wù)的機制以及跨平臺和跨語言的支持。具有代表性的組合服務(wù)技術(shù)BPEL4WS[3]用于在組合現(xiàn)有的Web服務(wù)基礎(chǔ)上定義一個商業(yè)流程，并且對其在交互過程中的實際行為和相互之間的消息交互進行建模。BPEL是基于WSDL語言并通過抽象的引用至對應(yīng)服務(wù)來構(gòu)建一個商業(yè)流的，而本文的做法正是要把這種抽象的引用下降到WSDL層進行。文獻[4，12]認(rèn)為用BPEL 來組合服務(wù)，其結(jié)構(gòu)過于平坦且不規(guī)整。因此筆者提出Web Component的概念，試圖在Web服務(wù)流集成的基礎(chǔ)上提升服務(wù)的重用性，并且采用面向?qū)ο蟮姆椒ńo出了Web Component Class的結(jié)構(gòu)。而事實上這種方法仍然是WSDL層之上的擴充，不能保持服務(wù)的描述統(tǒng)一性。

在服務(wù)搜索方面，為了改善搜索質(zhì)量，World Wide Web Consortium（W3C）提出將語義信息加入服務(wù)描述中。在文獻[13]中，W3C建議使用OWL—S Ontologies描述Web服務(wù)，并通過廣告查詢服務(wù)的輸入/輸出來得到匹配的服務(wù)列表。文獻[12]提出了一種在服務(wù)依賴圖上的搜索發(fā)現(xiàn)算法，但仍然是基于消息的或方法級別的交互搜索，而并未從接口契約的層次來進行。

4 結(jié)束語

Internet開放環(huán)境下面向服務(wù)的計算帶來了新的業(yè)務(wù)運行模式，對現(xiàn)有服務(wù)采用一種類似擴充、限制、拼裝的方法進行增量式開發(fā)以得到新的Web服務(wù)是一種有效的途徑。本文認(rèn)為，通過服務(wù)構(gòu)件化，以一種類似于基于構(gòu)件的軟件開發(fā)來組織Web服務(wù)的開發(fā)過程是一種可行的途徑。因此提出一種構(gòu)件化服務(wù)概念，顯式化地描述了服務(wù)之間的依賴關(guān)系，并保證了統(tǒng)一的功能抽象和良好的復(fù)用性。同時構(gòu)件化服務(wù)具有兼容標(biāo)準(zhǔn)Web服務(wù)、可以被第三方組裝以及獨立部署等特性。本文通過擴展WSDL描述構(gòu)件化服務(wù)的功能，借助服務(wù)依賴關(guān)系增強注冊中心的服務(wù)搜索能力以及給出合適的構(gòu)件化服務(wù)集成步驟。在基于Artemis—ARC系統(tǒng)中初步實現(xiàn)了構(gòu)件化服務(wù)思想。

下一步將對服務(wù)搜索注冊機制進行強化，通過加入語義信息來描述和搜索注冊中的構(gòu)件化服務(wù)，以提高服務(wù)搜索的可用性和準(zhǔn)確性。

本文中所涉及到的圖表、注解、公式等內(nèi)容請以PDF格式閱讀原文。