構件化軟件服務及其在Ａｒｔｅｍｉｓ—ＡＲＣ系統中的應用

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

關鍵詞：面向服務的計算； Web服務； 構件； Web服務描述語言； 統一描述、發現和集成

中圖分類號：TP393文獻標志碼：A

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

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

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

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

1 構件化服務

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

本文認為構件化服務是一種可以組裝的Web服務。它具有統一的顯式交互接口描述，可以被獨立地部署并由第三方任意組裝。

構件化服務基本框架如圖1所示。它與構件以及標準Web服務相比，具有以下特點：

（1）從類別上看，構件化服務屬于Web服務，兼容標準Web服務的協議：由WSDL描述服務、UDDI注冊和發現服務、SOAP訪問服務，支持Publish、Find、Bind過程；進行的擴展不會破壞原有服務的可用性。

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

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

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

圖1 構件化服務的基本框架

1.1 構件化服務的描述語言

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

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

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

1.2 構件化服務注冊中心

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

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

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

算法：findAll，找出符合輸入條件的服務依賴關系

輸入：businessName、serviceName、portName

輸出：基于圖的依賴關系

1.3 構件化服務的集成

對服務開發者而言，大部分開發過程均類似于構件的復用組裝過程。開發過程包括三個階段，即計劃和搜索、描述和定義、實現。

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

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

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

2 實現以及在Artemis—ARC系統中的應用

Artemis—ARC是一個面向服務的動態協同架構系統，該系統為具有動態調整能力的面向服務的應用開發、運行提供了一套可視化的集成環境[5]。它基于Axis 和JBoss 基礎平臺以及Eclipse 公用環境，以可視化的集成界面支持面向構件化服務的應用集成和系統運行監控。在Artemis—ARC系統中實現了一個完整的構件化服務計劃、開發、部署和管理平臺，并且采用了這種基于構件化服務的應用開發；同時還具有構件化服務的訪問、發現和發布能力。

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

圖2展示了Artemis—ARC的工作環境，并且提供了一個構件化服務的應用實例，代表上文中所提到的數據服務的例子。半圓的Port代表Required接口，圓形的Port代表Provided的接口。該服務接口的描述片斷如下：

圖2 一個數據分析服務的例子

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

3 相關工作

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

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

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

4 結束語

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

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

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