• 沒有找到結果。

對非決定性service-oriented architecture應用程式進行動態測試的研究

N/A
N/A
Protected

Academic year: 2021

Share "對非決定性service-oriented architecture應用程式進行動態測試的研究"

Copied!
75
0
0

加載中.... (立即查看全文)

全文

(1)國立臺灣師範大學 資訊工程研究所碩士論文. 指導教授:黃冠寰 博士. 對非決定性 service-oriented architecture 應 用程式進行動態測試的研究. Dynamic testing for Non-deterministic service-oriented architecture application. 研究生:曹笠德 撰. 中華民國九十八年.

(2) 摘要 因為現行 service-oriented architecture 架構的軟體越來越多,很多公司 行號慢慢開始採用 service-oriented architecture 架構來建立內部工作流程管 理系統。service-oriented architecture 架構是由許多 web service 所組合而 成一個整合性的系統。所以這個架構之下所建立的系統,每個 service 之間可能 會有許多 interactions,所以每個 service 的是否都可以順利的執行就顯得相當 重要。不過,在現有的測試環境與測試方法當中,沒有一個完整有系統的測試方 式可以來對 service-oriented architecture 架構做一個測試。. 而我們就是設計出一個 framework 來針對 service-oriented architecture 架構的系統來做一個自動化的測試環境。我們利用 BPEL 來建立 service-oriented architecture 架構的環境,然後我在每一個 BPEL process 訊息交換的地方多加 上一個 proxy 來收集測試所需的資訊再配合上 reachability testing 的技術, 來測試 service-oriented architecture 架構的系統。. 關鍵字: service-oriented architecture, software testing, web service, BPEL.. I.

(3) Abstract Because the existing structure of service oriented architecture of the software more and more slowly, many companies began to use service oriented architecture to build the internal structure of the workflow management system. service oriented architecture framework is composed of many web service by a combination of an integrated system. Therefore, under the framework established by the system, each service may be many interactions, so whether each service has been running smoothly in the implementation of it is very important. However, the existing test methods and test environment, the absence of a complete and systematic way to test service-oriented architecture framework for a test.. And our framework is to design a service-oriented architecture for the system architecture to make an automated test environment. We use BPEL to build service oriented architecture framework for the environment, and then I have a BPEL process for each of the local multi-message exchange with a proxy to collect the necessary information to test the reachability testing together with the technology, to test the service-oriented architecture framework system.. Key word:service-oriented architecture, software testing, web service, BPEL.. II.

(4) 誌謝 二年的時間很快就過去了,我也從一個懵懂無知小子,成長一個有擔當的人, 這一份論文之所以可以完成,黃冠寰老師給我的幫助最大。一路以來的指導,加 上細心的注意許許多的細節,讓我的研究之路進行的十分順利。黃老師嚴謹的研 究態度,讓我學習到應該用怎樣的態度來做研究,如何從頭到尾完成研究工作。. 除了指導老師之外,師大的其他老師,也是給予我很多幫助,如:鄭永斌老 師的軟體工程,林順喜老師的演算法,對於我的研究也是有很多幫助,以前每一 個課程都有一定的幫助。. 實驗室的夥伴們,也是幫忙很多。哲生學長跟宇程學長,總是在我遇到問題 時,不辭辛勞的幫忙我,讓我在遇到問題時,可以有一個討論的對象,而且也在 研究的問題上提供我一些經驗,讓我不會這麼緊張。光耀、招政、李棋、彥佑、 文賢,我們六個人是一起進實驗室的,大家一起唸書,一起上課。終於大家也一 起畢業了,大家相處的日子真的很開心,如果沒有你們陪伴,可能我就沒辦法這 麼順利的畢業了,也謝謝各位學弟妹的陪伴,讓我在無聊的時候,可以有很多人 聊天。. 最後,要感謝的就是我的家人,我的父母對我的支持。他們總是關心我每 天吃飯了沒,幫我把其他事情都處理的好好的,讓我可以專心的做研究,不用煩 惱太多其他的事情,真的很謝謝大家一路以來的支持與鼓勵,沒有你們,我可能 就沒辦法這麼順利的畢業了。. 曹笠德誌於 國立台灣師範大學資訊工程研究所 民國九十八年七月 III.

(5) 目錄 摘要 .................................................................................................................................................. I  ABSTRACT .................................................................................................................................... II  1. . 2. . 3. . 4. . 5. . 簡介 ........................................................................................................................................ 1  1.1 . WEB SERVICES ........................................................................................................................ 2 . 1.2 . BPEL ...................................................................................................................................... 5 . 1.3 . SERVICE-ORIENTED ARCHITECTURE ........................................................................................ 6 . 1.4 . 動態測試 ................................................................................................................................ 9 . 1.5 . 靜態分析 .............................................................................................................................. 11 . 1.6 . MODEL CHECKING ................................................................................................................ 11 . 1.7 . REACHABILITY TESTING AND DYNAMIC EFFECTIVE TESTING ............................................... 12 . 1.8 . EXAMPLE OF AN NON-DETERMINISTIC WEB SERVICES APPLICATIONS ................................... 19 . 1.9 . OUR SCHEMA ........................................................................................................................ 20 . 文獻探討 ............................................................................................................................... 26  2.1 . MODEL CHECKING ................................................................................................................ 26 . 2.2 . DYNAMIC TESTING ................................................................................................................ 28 . 2.3 . SOA TESTING ........................................................................................................................ 29 . 將動態敏捷測試應用在網路服務 .......................................................................................... 32  3.1 . RACE CONDITION .................................................................................................................. 32 . 3.2 . PREFIX-BASED REPLAY .......................................................................................................... 34 . 3.3 . BPEL SYNCHRONIZATION MODEL ......................................................................................... 43 . 實作與實驗結果 .................................................................................................................... 46  4.1 . FRAMEWORK ......................................................................................................................... 46 . 4.2 . EXPERIMENTAL RESULTS ....................................................................................................... 55 . 結論與未來展望 .................................................................................................................... 62  5.1 . 結論 ...................................................................................................................................... 62 . 5.2 . 未來展望 .............................................................................................................................. 62 . REFERENCE ................................................................................................................................ 64 .   IV.

(6) 附圖目錄 . FIGURE 1.1 THE WEB SERVICES TECHNOLOGY STACK .......................................................................... 2  FIGURE 1.2 WEB SERVICES ................................................................................................................. 5  FIGURE 1.3 BPEL PROCESS DATA FLOW .............................................................................................. 6  FIGURE 1.4 NON‐DETERMINISTIC .................................................................................................... 10  FIGURE 1.5 REACHABILITY TESTING 架構圖 ..................................................................................... 12  FIGURE 1.6  利用 RACE GRAPH 產生 RACE VARIANT ........................................................................ 16  FIGURE 1.7  造成 REACHABILITY TESTING 問題的受測程式之一 ...................................................... 17  FIGURE 1.9  造成 REACHABILITY TESTING 問題的受測程式之三 ...................................................... 19  FIGURE 1.10 TARGET SYSTEM .......................................................................................................... 20  FIGURE 1.11 OUR SCHEMA .............................................................................................................. 21  FIGURE 1.12 RACE CONDITION ........................................................................................................ 22  FIGURE 1.13 SOLUTION ................................................................................................................... 24  FIGURE 3.1 RACE CONDITION .......................................................................................................... 32  FIGURE 3.2 SHARE OBJECT .............................................................................................................. 34  FIGURE 3.3 PROXY ........................................................................................................................... 35  FIGURE 3.4 EVENTLOG DATA STRUCTURE ......................................................................................... 36  FIGURE 3.5 EVENTLOG .................................................................................................................... 37  FIGURE 3.6 EVENTNODE .................................................................................................................. 39  FIGURE 3.7 EVENTID ....................................................................................................................... 40  FIGURE 3.8 ENTRY PROTOCOL ......................................................................................................... 42  FIGURE 3.9 EXIT PROTOCOL ............................................................................................................. 43  FIGURE 3.10 WSDL MESSAGING PATTERNS ...................................................................................... 44  FIGURE 4.1 FRAMEWORK ................................................................................................................ 46  FIGURE 4.2 TESTSCRIPT ................................................................................................................... 49  FIGURE 4.3 CORRELATION SET ......................................................................................................... 52  V.

(7) FIGURE 4.4 STATE ANALYZER ........................................................................................................... 52  FIGURE 4.5 RACE ANALYZER ............................................................................................................ 53  FIGURE 4.6 TEST MAIN .................................................................................................................... 55  FIGURE 4.7 BOOKSTORE .................................................................................................................. 56  FIGURE 4.8 PETERSON'S ALGORITHM .............................................................................................. 59 . VI.

(8) 附表目錄 TABLE 4.1 EXPERIMENTAL RESULT FOR BOOKSTORE USE DYNAMIC EFFECTIVE TESTING .................... 56  TABLE 4.2 EXPERIMENTAL RESULT FOR BOOKSTORE USE NON‐DETERMINISTIC ................................ 57  TABLE 4.3 不同次數的 NON‐DETERMINISTIC 的比較 ....................................................................... 57  TABLE 4.4  兩種測試方法產生 SYN‐SEQUENCE 效率的比較(BOOKSTORE) ....................................... 58  TABLE 4.5 EXPERIMENTAL RESULT FOR PETERSON'S ALGORITHM USE DYNAMIC EFFECTIVE TESTING 59  TABLE 4.6 EXPERIMENTAL RESULT FOR PETERSON'S ALGORITHM USE NON‐DETERMINISTIC ............. 60  TABLE 4.7 不同次數的 NON‐DETERMINISTIC 的比較 ....................................................................... 61  TABLE 4.8  兩種測試方法產生 SYN‐SEQUENCE 效率的比較(PETERSON'S ALGORITHM) ................... 61 .  . VII.

(9) Dynamic testing for Non-deterministic Service-oriented architecture Applications. 1. 簡介 因為現在 web services[1]十分盛行,許多的服務都採用網路的方式來運作。 而軟體測試對於注重軟體工程的現在,也是非常重要的。但是現有的一些軟體測 試的方法對於 web services 都不很適用,因為是採用網路運作的方式,所以要測 試起來十分困難。因為以往的自動化測試方式都是屬於靜態的方式,這樣的測試 方式,對於網路服務來說效力可能不夠,因為 web service 的運作可能會有相當程 度的複雜性,單單只靠靜態分析,對於一些 non-deterministic[2]行為要分析相當 的困難。所以本篇論文就是提出一套作法,使得 web services 的 application 也能 夠有動態測試的系統可以使用。第一章節主要是 introduction,簡介一下 web services 與 BPEL[3]以及 service-oriented architecture(SOA)[4]的相關 background, 以及 software testing 各種類型方式的簡介,最後就介紹我們要解決的 target system 與我們的解決方法。第二章是 related work,分別找了幾個 web services testing 相 關的研究 paper,如:model checking[5]、SOA testing 等相關領域之 paper。第三 章是說明如何將 web services 套用上我的們的 dynamic effective testing。第四章是 1.

(10) 說 說明一些實 實作上的細節 節以及實驗 驗的介紹與數 數據。第五 五章則是把文 文章做一個 個歸納的 結 結論。. 1 Web 1.1 b Servicees. Figgure 1.1 The Web Serv vices technoology stack 由 figuure 1.1 可以 以清楚地看到 到,現在 web w servicess 目前現有的 的技術,他 他們彼此 的 的關係與定 定位。包含了 了底層的通 通訊協定,如 如:HTTP, SMTP 等,message 的交換格 的 式 式是使用 X XML[6]的資 資料格式,然後使用 然 SO OAP[7]這個 個通訊協定。上層更有 security、 r reliability 的 standard。 。最上層還 還有 businesss process 的 applicationn,如:BP PEL4WS 等 等。整個 sttandard 制定 定算是已經 經蠻完整的,也因為幾 幾乎每個項目 目都有標準 準可以依. 2.

(11) 循,所以只要遵照這些標準來撰寫程式,不管在那個平台,都可以順利運行,許 多服務都是可以在跨平台上面運作的。底下我們會慢慢介紹我們這個 work 有使 用的部分,讓大家更為了解 web services 的平台操作,以及 service-oriented architecture 這個目前很熱門的架構方式。 在以往 B2C 的年代,web 的應用,可能服務對像只是個人而已。但是現今服 務對象擴展到軟體,也就是軟體之間相互溝通的問題。web services 以 XML 為資 料格式,透過網路提供服務,將軟體服務封裝成一堆可以在遠端呼叫的函數,將 資料公佈在網路上(UDDI[6]、ebXML),透過標準的網路通訊協定(例如 HTTP、 SMTP、FTP、RMI 等) ,透過 XML 標準格式的底層協定(例如 SOAP 與 WSDL[8])來 處理溝通與辨認程式碼的問題。 如 Figure 1.2 所示,web services 的基礎包括:XML、WSDL、SOAP、UDDI, 其底層運作架構模式步驟如下:以 XML 格式為基準將資料轉變為 web services 的資料,利用 WSDL 描述將服務的對象做一個描述,使另一端可以透過這一個描 述,解譯所得的資料。以 SOAP 通訊底層,進行傳送的動作,向 UDDI 進行搜尋或 是註冊動作。我們可以看到,WSDL、SOAP 與 UDDI 皆是用 XML 方法來描述。 W3C 對 Web Services 的定義如下: “A Web service is a software system identified by a URI, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may 3.

(12) then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by internet protocols." SOAP 指的是一種提供給 web services 以 XML 製作出來的通訊協定,目前版 本是 1.2,就像是打電話必須通過電話線或是無線基地台等,其目的就是讓應用 程式與應用程式能相互溝通,但不需要知道彼此的作業平台是那一種或是各自如 何實作等細節資訊。 WSDL 主要是描述 web services 的細節,也是使用 XML 格式之語言,讓 web services 應用程式能以一種標準方法來描述自己擁有哪些能力,以便讓互動更容 易進行。 UDDI 指的是一種有關於 web services 的目錄註冊服務,其架構也是以 XML 為基礎,其主要的目的為提供 web services 的提供者,透過 UDDI 告知其他人提 供者有提供 web services,因此 UDDI 的功能也就類似電話簿,或是稱為黃頁, 目的就是要快速告知服務使用者他可以利用的 web services 有哪些。. 4.

(13) Figure 1.2 Web Services. 1.2 BPEL BPEL 是 business process execution language (BPEL)的縮寫,也有人稱為 web services business process execution language (WS-BPEL)。談到 BPEL 的歷史,當 年 IBM 與微軟公司各式定義了一個很類似的語言,分別為 WSFL[9]和 XLANG[10], 隨者知名度的提升與 BPML 的慢慢的熱門起來,所以 IBM 與微軟決定要這些語 言整合成一個新的語言- BPEL4WS,2003 四月 BEA Systems、IBM、Microsoft、 SAP and Siebel Systems 提交了 BPEL4WS 1.1 到 OASIS 來通過標準化的審議,到 了 2004 年九月正式名為 WS-BPEL 2.0。主要是由 web services 架構而成,是可指 定運行的 web service。其運作的過程中,所有訊息的 import 和 export 完全都是使 用 web services 的 interface。其運作的方式也是在控制與執行 web services 的 flow, BPEL 本身並不是執行者,而是一個指揮,他所做的工作,只是在控制 web services 5.

(14) 的運行,真正在運作的還是外部的 web services。因為 BPEL 製作並不複雜,所以 被視為實作 SOA 架構最合適的平台,所以最近幾年許多的研究都往這個方向來 走。figure1.3 為 BPEL 的示意圖。. Figure 1.3 BPEL process data flow. 1.3 Service-oriented architecture 到底什麼是 service-oriented architecture (SOA)呢?SOA 是一個架構模型,我們常 聴到 information technology (IT)產業的架構演進,由 1980 年代的主機(mainframe) 架構,到 1990 年代的主從式(client server)架構,到 1999 年時是 network centric 架構,而到 2004 年時已複雜到所謂的 service-oriented architecture 架構(SOA,服 務導向架構) 。其實大多數的人對於 SOA 都有一些迷思,SOA 並不是最近才有 6.

(15) 的概念,早在多年之前,就有資訊部門公司成功地利用 SOA 的架構,來建構與 運行應用程式,當時 XML 與 web services 都還沒提出呢。SOA 並不是一種技術, 它是一種建構與組織的方法。從資訊技術層面而言,一個執行學校或企業業務的 應用程式稱為一個獨立的「邏輯單位」,而對學校或企業營運層面而言則可稱為 一項「服務」,在企業的整體運算環境中就存在著多個「獨立邏輯/業務服務」, 且需要對其進行妥善設計、開發、佈建、管理等,也因此需要採行服務導向架構 (SOA) 。要將 SOA 的概念得以發揮,程式設計師的想法必須有所改變。要以「持 續累積服務」的觀念與角度來開發應用程式,即便這麼做在短時間內看不到顯著 好處,程式師還是必須跳脫、超越過往對應用程式的想法,改以「既有服務可否 再運用?」或者是「能否沿用他人曾經開發過的服務再建構?」的觀點來面對程 式開發。SOA 主張「程式開發技術」與「程式建構方法」的交替並用,以類似傳 訊溝通的作法,將數個所需的「服務」進行連結,以此來實現一個新的應用程式, 而非「從頭開發」。當用戶的需求有改變的時候,新的應用程式只要透過「傳訊 微調」即可實現,而非「重新撰寫」 。SOA 不只是在程式開發上面帶來新的想法, 也給管理上面帶來更便利的管理模式。打破以往的觀念,非是以應用程式個體為 角度來進行管理,而是直接將過往程式師開發出的程式視為「服務」來管理。而 對「服務」間的「互動傳訊」進行分析,SOA 便可讓程式設計部門的主管瞭解何 時該執行哪個業務邏輯,以及為何要執行,如此資訊管理者與分析師便可對服務 程序進行最佳化調適。SOA 服務導向架構是一種新興的系統架構模型,組合的元 7.

(16) 素通常包括:軟體元件、服務及流程三個部份。例如:當學校或企業面對外部要 求時,流程負責定義外部要求的處理步驟;服務包括特定步驟的所有程式元件, 而軟體元件則負責執行工作的程式。SOA 已成為現今軟體發展的重要技術,透過 SOA 讓異質系統整合變得容易,程式再使用度也提高。不必自行開發或擁有所有 程式元件,發展者可以視其需要組合網路上最好的服務。不受限於特定廠商的產 品功能或是平台,達到真正的開放性(openness)。從分散式元件架構到 SOA 概念 上,SOA 如同物件導向、軟體元件等軟體技術一般,運用小的零組件組合成應用 系統。但 SOA 強調的是如何將彼此關係鬆散的應用系統功能元件在網路上發行、 組合及使用。SOA 具有下列技術特性: 1. 分散式架構 (distributed)-SOA 的組成元件是由許多分散在網路上的系統 組合而來,可能是區域網路,也可能是來自廣域網路。例如網站服務技術 (web services) 就是運作 HTTP 來相互連結的 SOA。如此的作法,也使得 網站服務技術很快的就成為所有支援網際網路的系統平台均能使用的技 術。 2. 關係鬆散的界面 (loosely coupled)-傳統的系統主要是將應用系統功能需 求切割成相互關聯的小零組件:模組、物件或元件,發展者要花費極大的 心力了解零組件是如何設計及使 用,以確保不會違反零組件連接關係限 制。如此一來,若要以不同零組件替換原始設計,就成為一件困難的事。 SOA 的作法是以界面標準來組合系統,只要符合界面要求,零組件可以任 8.

(17) 意替換,大幅提高系統變更的彈性度。 3. 依據開放的標準 (open standard)-使用開放標準是 SOA 的核心特色,過 去的軟體元件平台如 CORBA、DCOM、RMI、J2EE 採用專屬協定作為元 件連結的規範,使得不同平台的元件無法相通。SOA 則著重於標準與互動 性,將可避免不同平台 (.NET web services 與 Java web services) 開發程式 間相互整合的困擾。 4. 以流程角度出發 (process centric)-在建構系統時,首先了解特定工作的流 程要求,並將其切割成服務界面(包括輸入與輸出資料格式),如此其他的 發展者就可以依據服務界面開發 (或選擇) 合適的元件來完成工作。 因此 SOA 的實作,就是將所有程式邏輯及服務內容全部包裹在服務內部,並實 作一個標準的介面與外部作溝通,這種做法跟傳統的元件導向做法非常類似,唯 一的差別是介面定義的方式、資料格式、與溝通管道必須是產業標準 (HTTP、 XML、SOAP 等)。 也就是說只要能實作出這樣的介面,不論介面後面是什麼, 都可使成為 SOA。. 1.4 動態測試 動態測試就是透過實際的執行程式,將執行完的結果做分析。所以並非是一成不 便的,可能會因為執行的過程當中程式的時序不同,而有不同的變化。輸入的數 值不同也會造成不同的結果。在每一組的輸入值時,就如同一次的靜態分析,可 9.

(18) 以根據其輸出的結果分析是否為預期之結果。但是目前 dynamic testing[11]主要都 是採用 sequential 的方式,但是如果發生 non-deterministic 的情況,以前的方法是 沒有辦法確保是否能夠執行到程式中每一個 interleaf,如 figure 1.4 有左邊那條路 線,發生的可能性高達 95,而右邊的路線發生的可能性只有 5%,極有可能在執 行 50 個例子之後一個左邊路線的例子也沒有,這樣測試的覆蓋率就不夠完整。 但是在我們實驗室所研究的 reachability testing[12]可以驗證 non-deterministic 的情 況,確保每一個 interleaf 都有被執行過,而且強制的指定每次執行一個 path 避免 執行到同樣的 interleaf,也盡可能縮短 dynamic testing 的執行時間,讓 dynamic testing 需要花費比較多時間的缺點也得以改善,使得 dynamic testing 的實用性大 幅增加。. 95%. 5%. Figure 1.4 non-deterministic. 10.

(19) 1.5 靜態分析 靜態測試是軟體測試的一種模式,這種測試模式並沒有實際執行程式,而是針對 程式的 code、演算法或是 document 做一些驗證的動作。再驗證之時主要是確認 requirement 跟 specification,並不無法確保當程式執行之時是否會發生一些 run time error,所以基本上來說 static analysis 只是做到部分的檢查跟確認。對於 web services 中,可能會發生兩個以上的 web services 彼此 transition 的交互作用,進而 發生一些 non-deterministic 的行為。這時如果使用 static analysis 的驗證方式,可 能會發生無法驗證的情況出現。. 1.6 Model Checking Model checking 也是 software testing 中,常見的一種方式。model checking 最大的 特色就是:必須要先將要測試的 source code,轉換成他們的 model。model checking 通常有兩個比較需要考量的問題,第一個是怎麼簡化 model 的 system,因為 model checking 最怕發生的就是 state 的數量太多造成 state 爆炸的情況。第二個是一個 符合需求的自動化系統,因為 model checking 往往轉換之後的 model 都有相當多 的 state,這時候就需要能夠自動化驗證系統,自動化驗證系統是否能夠 cover 所 有的 state,這個 checking tool 是很重要的。model checking 最重要的一個步驟就 是要將需要驗證的 source 轉換成 tool 可以驗證的 model,通常是透過 verification language 表示成 automata,最後再用 model checking 的 tools 例如:SPIN[13]、 11.

(20) NuSMV[14]......,來驗證其定義的 property 是否有錯,property 通常需要一些 logic 的式子來做定義,所以 model checking 往往需要 temporal logic[16]來做輔助,如 LTL[15]與 CTL[15]。總結來說,model checking 就是利用數學的方式如 finite state machine 的概念配合上 logic 來做驗證的動作,但是面對 web services 這種可能擁 有比較高複雜性的 communication 行為,model checking 可能做起來就比較吃力而 且表現出來的成效也不比較不佳。. 1.7 Reachability Testing and Dynamic Effective Testing reachability testing 是一種用來測試並行程式非決定性行為的方法,架構上揉合了 nondeterministic testing 與 deterministic testing 兩者的概念;透過 reachability testing, 系統開發人員可以確認並行程式執行的正確與否 Execution P with input X A SYN-sequence S. Race analyzer (To derive race-variants ) Derived race variants …………. Queue to store race variants Remove a race variant R from queue. Prefix-based replay of R Obtain a SYN-sequence. Figure 1.5 Reachability testing 架構圖 reachability testing 整個測試過程如 Figure 1.5 可粗分成兩個階段:monitor phase. 12.

(21) 與 replay phase。在 monitor phase 中,受測程式的執行如同 nondeterministic testing 一般,是完全不受控制的,系統的排程可自由地組合任何可能 SYN-sequence 並 完成執行。對於 reachability testing 整體架構而言,monitor phase 所需要作的僅是 將受測程式執行的 SYN-sequence 記錄下來,供作後續的分析與執行需要。顧名 思義,replay phase 的目的即在重現前次的執行,它應用 deterministic testing 的概 念,受測程式在執行時需要指定 synchronization events 的 partially order 關係,藉 由 reachability testing 提供的協定,將所有 synchronization events 按指定的次序執 行。 很明顯地,單純地實作 monitor phase 與 replay phase 並不能解決 nondeterministic testing 與 deterministic testing 的不足,reachability testing 因此導入了 race analyzer 的機制,將 monitor phase 與 replay phase 作完美的結合。Race analyzer 的主要工 作在於從 monitor phase 記錄的 SYN-sequence 中,分析出其他不同於此 SYN-sequence 但又可能出現的 partially order 關係,稱作 race variant。換言之,race analyzer 可藉由更動 SYN-sequence 中部分 synchronization events 的 partially order 關係用以產生 race variants;由於在被更動點之後的 synchronization events 已無法 保證其執行的必然性(例如:經由不同的執行順序,執行過程中可能會產生不同 的變數值,而這些變數值可能會作為程式中 conditional branch 的依據,並決定部 分程式碼的執行與否) ;相對於 SYN-sequence,race variants 將不再代表某次完整 的執行順序,而是某個執行順序中最前面的一部分;當要進行受測程式的整個執 13.

(22) 行時,必須將 replay phase 作一個適當的調整。 前面提到的 replay phase 僅是應用 deterministic testing 的概念,但由於指定的 partially order 關係 race variant 是一個不完整的執行過程,reachability testing 因此 提出 prefix-based replay 的概念,透過在 race variant 中加入一個特殊標記的方式, 使 replay phase 時得知 race analyzer 更動的 partially order 的位置,當 replay 的過 程中遇到前述的特殊標記,reachability testing 立刻切換到 monitor 模式,改由系 統排程自由地產生可能的執行順序,執行受測程式中之後的部分,並將此記錄下 來形成另一個不同的 SYN-sequence 再交由 race analyzer 分析、產生其它新的 race variants。由此可見,reachability testing 利用這樣反覆的動作,一開始將第一次執 行得到的 SYN-sequence 從頭開始對每一個 partially order 關係作更動,產生一些 race variants,並標示更動的位置;在後續的 race analyzer 進行過程中,特殊標記 前的 partially order 將不再被更動,因此隨著 reachability testing 中每一輪的執行, 標記的位置會逐步地向受測程式結尾處靠近。當特殊標記到達程式結尾,race analyzer 將不再產生任何新的 race variants,整個 reachability testing 過程也在執行 完所有的 race variants 後結束。最後,為了達到完整測試的目的,race analyzer 所 採用的演算法必須能保證所有受測程式可能產生的 race variants 都會在測試過程 中產生,另外由於效率上的考量,演算法同時也要儘量避免產生重複的 race variants。 對於 reachability testing,race analyzer 所採用的演算法是整體效能的關鍵, 14.

(23) SYN-sequence 的記錄格式也常因 race analyzer 的需要及程式存取機制上的差別 (如:shared-memory, message-passing, semaphore, …etc)而有所不同。黃冠寰博 士於 1995 年首先提出了利用建構 RV-diagram 的方式,並以 shared-memory 與 semaphore 兩種存取機制為例子作演示。RV-diagram 是一個 n-ary 的樹狀結構,其 中 n 代表整個受測程式中並行程序的個數。由 RV-diagram 的 root 到樹狀結構中任 一個節點的路徑都分別代表了此受測程式中一部分 synchronization events 間 totally order 的關係。在 reachability testing 執行過程中,每個相異的 SYN-sequence 都分別會產生各自的 RV-diagram,並在展開的過程中標記出代表 race variant 的節 點。之後黃冠寰博士在 2004 年於 IEEE Transaction on Software Engineering 發表以 race graph 的方式,直接更改 Synchronization events 間 partially order 的關係。在 race graph 中每一個節點都代表程式中某一個 Synchronization event, Synchronization events 間的 partially order 關係則用 directed edge 表示。產生 race variants 時,僅需要分別就某一節點的 in-edge 作反向即可;若某一節點一共有 k 個 in-edge,則在此節點的位置上,至多會產生(sk-1)個 race variants。實驗上相較 於 RV-diagram,race graph 的方法能大幅提高效能,對於某個 SYN-sequences 總數 為 117 的並行程式,RV-diagram 的方式一共需要 3,537 次的執行,而 race graph 僅僅需要 152 次。那是因為 RV-diagram 所產生的 race variants 容易造成重複的測 試,即產生相同的 SYN-sequence。. 15.

(24) Reverse direction of in-edges. A race-graph of a SYN-sequence. (1) There is a loop.. i=1=[1,0]2. E. P1. P0. Remove some nodes. (2). e1. i=2=[0,1]2. e2. E. E. E. (3) i=3=[1,1]2. E. E. Figure 1.6 利用 race graph 產生 race variant 雖然 reachability testing 已實證能完整地測試並行程式的非決定性行為,並在效能 上取得長足的進步,但其基礎架構上卻存在一嚴重的不足。在前面提到, reachability testing 在 monitor 的過程中並不對受測程式的執行進行任何干預,因 此當程式中出現無窮迴圈或忙碌等待迴圈(busy-waiting loops)時,reachability testing 很容易因為執行無法順利結束,導致 prefix-based replay 的過程中失敗。 “a” is a shared variable. Process 0. Process 1. .... .... S0,0. a=1;. S1,0. S0,1. DO { ... }. .... S0,2. WHILE (a==0) 16. a=0;.

(25) ... Figure 1.7 造成 Reachability testing 問題的受測程式之一 Figure 1.7 是一個由兩個程序 process 0 與 process 1 組成的並行程式,在 process 0 中有三行程式碼:S0,0, S0,1 與 S0,2,而 process 1 中由一行程式碼 S1,0 組成。這 邊很明顯地可以看到:程式的執行將會在 S0,1 與 S0,2 不斷地來回,{S0,0, S1,0, S0,1, S0,2, …}是其中一個可能產生的執行順序。就如前面所敘述 reachability testing 的架構,執行時產生的順序將會被記錄下來,提供後續的 race analyzer 作 分析的動作;但在以{S0,0, S1,0, S0,1, S0,2, …}為首的執行順序時,程式將會進入 無窮的等待迴圈之中,不斷地記錄的執行順序,最終耗盡系統所有可用的記憶體 空間。 “a” is a shared variable and its initial value is 0. Process 0. Process 1. .... .... S0,0. DO { ... }. S1,0. S0,1. WHILE(a==0). .... a=1;. ... Figure 1.8 造成 Reachability testing 問題的受測程式之二 另外一個潛在的問題是:有時程式的執行並沒有進入無窮迴圈之中。以 Figure 1.8 為例:受測程式最快可能只執行三行的程式碼{S1,0, S0,0, S0,1}就結束,也有可能 17.

(26) 多在迴圈裡執行一次,得到{S0,0, S0,1, S1,0, S0,0, S0,1}這樣的執行順序。很明顯 地,process 0 中的迴圈 S0,0, S0,1 必須不斷地執行忙碌等待迴圈直到 process 1 中 的 S1,0 獲得執行;有別於無窮迴圈 Figure1.8 的例子最終必定會因為操作系統排 程給 process 1 而執行結束。但是在 reachability testing 的架構之下,race analyzer 為達到完整測試的目的,會將所有程式可能的執行順序全部產生,因此無論是執 行迴圈 S0,0, S0,1 一次、兩次,甚至是無限多次的執行順序,都會因為 race analyzer 視作相異的 race variants 而逐一地付予執行。我們可以把這些產生的 race variants 表達成{(S0,0, S0,1,)i S1,0, S0,0, S0,1}的形式,其中 i 可以是大於或等於零的任意 整數,而這些 race variants 將使得存放 race variants 的佇列永遠無法被清空,整個 reachability testing 將因而沒有結束的時候。 前面以一個最簡單的例子說明非無窮迴圈可能的問題,其中反覆執行的部分 S0,0, S0,1 都在同一個程序中,Figure1.9 是另一個較複雜的例子,反覆執行的部份將橫 跨兩個不同的程序。在 Figure 1.9 造成 Reachability testing 問題的受測程式之三中 最短的可能執行序列是{S1,0, S0,0, S0,1, S1,1},和前述例子類似,這個例子中所 有可能的執行序列可以表達成:{(S0,0, S1,0, S0,1, S1,1,)i S1,0, S0,0, S0,1, S1,1}, 其中 i 是大於或等於零的任意整數;可能重複執行的部分為 S0,0, S1,0, S0,1, S1,1, 分別屬於 process 0 與 process 1。 “a” is a shared variable. Process 0. Process 1 18.

(27) .... ... S0,0. DO { a = 1;}. S1,0. DO { a = 0;}. S0,1. WHILE(a==0). S1,1. WHILE(a==0). .... .... Figure 1.9 造成 Reachability testing 問題的受測程式之三 Multi-core 系統的測試驗證有以下困難點: Shared variables 的存取造成 race condition 除了、具迴圈,還有 Task priority,分成以下三個部分來進行研究: 處理迴圈程式可能造成的問題,在 prefix-based replay 時要能將已陷入無窮迴圈的 受測程式強制結束,並回報可能造成無窮迴圈的部分程式碼與特定的執行順序。 其次,在 race analyzer 的部分應發展能處理忙碌等待迴圈的演算法,避免產出過 多的 race variants,導致無窮的測試。. 1.8 Example of an Non-deterministic Web Services applications. 19.

(28) Figure 1.10 Target System 如 figure1.10 所示,這是一個平常很常見的網路書店的運作系統,同一個時間可 能會許多客戶向網路書店下訂單。這時書店會連接到倉儲系統,去檢查存貨,但 是可能因為客戶彼此間的先後順序而有不同的庫存數量的狀況產生,這時可能可 能因為庫存數量而有不同的回應回覆給客戶。這樣一個常見的網路商業的 model, 整個 flow 可能會產生相當多不同的狀況,有一些狀況可能發生的機率非常低,但 是那些狀況還是有可能造成系統出現狀況。而我們的系統就是確保每個 interleaf 都是會被執行到,不管是有沒有錯誤都是會保證執行過。. 1.9 Our Schema. 20.

(29) Figure 1.11 Our Schema 我們驗證的目標系統,主要就是以 BPEL 建構而成 web services 系統。因為 BPEL process 之間會有許多 interaction 的情況,所以可能會產生許多 non-deterministic 的行為,這時可能會交互產生許多 interleaf,而我們的測試系統就是要確保每一 個 interleaf 都有被執行到。我所設計的方法,是由 agent 這個部分擔任模擬 client 端的角色。而我們另外設計了 XML 格式的 test Script,test Script 的作用,就是將 原本在進行 testing 的過程中,原本是需要人們輸入的部分先存放在 Test Script 當 中,到時候再由 agent 讀入,可以達到自動化執行 testing 的目的,而且如果需要 修改輸入數值之時,我們可以不用修改程式碼,直接修改 test script 當中的數值就 可以了。agent 在讀取了 test script 之後,原本應該是要向 target web services 發出 request 的。但是我為了要收集我們 Testing 所需的資訊,所以我再多做了一個 proxy. 21.

(30) 的 web services 在中間,作為一個中介的平台。proxy 最重要的工作就是收集 share variables 的 version number、value 以及 program counter 的 reachability testing 所需 要的資訊。而 proxy 另外一個任務就是啟動 reachability testing,先運行 prefixBasedreplay ,再產生 race variant,然後就這樣 loop 反覆執行下去,直到所 有產生的 race variant 都消除為止。 由於我們在測試之時,主要就是針對 web services 之間 race condition 來作分析。 所以我們認定兩個 web services 的 request 有 race 的關係,就是當兩個 request 共 同 access 到某一個共同的 shareobject。. Figure 1.12 Race Condition 當兩個 request 共同 access 到同一個 shareobject 時,一定會有先後 order 的關係, 22.

(31) 我們稱這種現象為 race condition,當 order 的順序不同的時候,可能會造成不同 的 condition 發生,造成不同的 response 回覆回來,而不同的 response 也有可能造 成原本的 BPEL process 走不同的 path。舉一個例子來說,有兩個 BPEL process 是在處理網路購書的流程,兩個 process 剛好要購買同一本書,process1 要購買 3 本,process2 要購買 1 本,當兩個 process 同時發出 request 到網路書店的 web services 去,但是這時書店的庫存只有兩本,如果 order 是 procees1 先然後才是 process2,這樣會回覆兩個 process 都是庫存不足,兩個 process 都會走到右邊的 路線。如果今天 order 變成 process2 先然後再換 process1 的話,這時會 process2 會收到交易完成的 response,process1 會收到庫存不足的 response。這時可能 process2 的 BPEL 會走左邊的 path,而 process1 的 BPEL 會走右邊的 path。由以 上的例子可以知道針對 race condition 發生的地方,我們對於其 order 順序加以控 制,可以將不同的 path 都 cover 到。所以我們設計出的方法主要就是針對這個部 分來做處理。. 23.

(32) F Figure 1.13 Solution 我 我們採用的 的方式,是多 多加一個 proxy p 的 weeb service 在原本 在 BPE EL process 跟 target w servicees 中間,當 web 當兩個 BPEL L process 發送 發 requestt 到 proxy 的 的時候,我 我們會做 一 一次記錄資 資訊的動作,就是 monnitor 的動作 作,然後收集 集到的資訊 訊我們就稱為 為 event h history,當完 完成一次動 動作之後,我 我們會將所 所有的 evennt history 收 收集起來,進 進行 race a analysis 的分 分析之後會 會產生 race variants,當 v 當 BPEL proocess 再次發 發送 requesst 時,這 時 proxy 會根 根據得到的 的 race variannts 來做為這 這次發送到 到 target webb services 的 order。 我 我們會根據 據 race variannts 來強迫 request 照我 我們的 ordeer 來發送, ,所以當強迫進行 24.

(33) 一個順序時,這時就稱為 replay,每一次進行完之後都會將資訊紀錄下來變成 event history,以便我們進行 race analysis 的分析,進而達成所有的 interleaf。. 25.

(34) 2. 文獻探討 2.1 Model Checking 在 Towards Model-based Verification of BPEL with Model Checking[16]這篇 paper 當 中,作者 Honghua Cao, Shi 提出先用 UML activity 來驗證 BPEL model,主要是驗 證流程是否正確完整的進行。使用的方法是先將 UML activity 轉變成 PROMELA language,再透過 SPIN 這個 model checker 的系統來驗證是否正確。因為其 model 還是必須仰賴 SPIN 來做最後的驗證,所以其驗證可以達到的範圍就是 bound 在 SPIN 上面。而他們的系統因為是採用 model check 轉換的方式,所以並不能確保 是否有 cover 到原本全部系統的狀態。相較於我們的系統一方面是真實在的執行 原本的 code 所以可以保證是原本最真實的情況,而且我們的系統可以保證任何 non-deterministic 的行為,所有的 interleaf 都會執行到,因此我們可以確保整個系 統的正確性。在 BPEL4WS Unit Testing:Framework and Implementation[17]這篇 paper 中,Zhongjie LI, Wei SUN 提出將受測的 process 分別放置在幾個不同的 test process(TP)當中,再由 control process(CP)來控制,control process 則是由 user interface 來控制,沒辦法達到 automatic 驗證。也有提出使用 BPEL 驗證 BPEL 的 手法,可以減少再去開發 test program language。這個系統目前最大的缺點就是, 他的測試方式是 unit testing,把整個 BPLE 拆開成一小部分一小部分的,所以這 會比較缺乏整個系統上面的測試,有些交互間的 interaction 可能就沒辦法測試。 而且這個 testing framework 還是要他 test 時有些操作必須依賴 user interface,並不 26.

(35) 能到全部 automatic 的狀況。目前我們的系統,是通盤運行整個系統的測試,而且 全程都是自動化運行。在 Verification of Web Service Flows with Model-Checking Techniques[18]這篇 paper 當中,Shin NAKAJIMA 提出由 WSFL(Web Service Flow Language)來描述 web service,再轉譯成 Promela 的語言,最後再由 SPIN 來做 model checker,SPIN 是一個 automaton-based model-checker,用來做 model check。也因 為是做 model check 主要還是驗證定義上的 constraint。他們的系統專注在驗證 web services 上面,主要強調在 message 的 communication 上面,所以他們將 flow 中的 一些 transition 轉換成 promela,來做 model checking。但是 model checking 都有一 個固定的缺點,就是沒有辦法保證系統轉換到別的 model 時,他的 model 能否 cover 到原本的 system。而我們的系統,因為是直接 run 原本的 real code,所以沒有這 個方面的問題。在 Modelling and verification of BPEL business process[19]這篇文章 當中,作者 Marina Mongiello, Daniela Castelluccia 提出使用 BPEL4WS(Business Process Execution Language for Web Services)來描述 business process,定義一些 Formal model 來轉換 web service 成 finite state machine,透過所設計的 framework 將 BEPL file 轉成 SMV file 最後透過 NuSMV checker 來自動驗證 CTL specifications on the formal model 及一些定義屬性的驗證。他們的 work 必須先將 BPEL 的 system 轉換成,這可能會造成轉換出來的 model 是否有完全 cover 原本 system 的問題, 而且因為是使用 model checking 的方式,有一些 concurrent 執行時的 interleaf 可 能沒有辦法確保是否都有執行到。 27.

(36) 2.2 Dynamic testing 作者 Srini Narayanan, Sheila A. McIlraith 在 Simulation, Verification and Automated Composition of Web Services[20]這篇文章中提出先用 DAML-S(DAML+OIL)來描 述 web services 的能力,這種語言是一種邏輯式的語言。然後再輔以 Petri Nets, 做成 Petri Nets 的型態,來執行模擬的動作,可以驗證其 Reachability 和 Deadlock。 這個系統我自己本身認為算是相當不錯的,因為它可以利用它本身有設計一些 construct,例如 split construct、choice construct、if-then-else construct......等。可以 用來製作一些 web services 可能發生的一些狀況,加上利用 PetriNes 的應用可以 跑一些 simulation,不單單只是 static analysis 而已。比較大的問題就是其 semantic web 開發的複雜度相當高,是否能夠把所有 web services 的狀況都能實做出來, 這點應該是最大的問題。作者 W. T. Tsai, X. Wei, Y. Chen, R. Paul 在 A Robust Testing Framework for Verifying Web Services by Completeness and Consistency Analysis[21]這篇文章中提出一個 web services testing 的 model,他有兩個不同驗 證模式。分別為 positive testing 跟 negative testing。positive testing 是針對 web services 的 function 來做測試,不過他的完整性有多少就不知道。negative testing 主要是針對 web services completeness and consistency 來做測試,感覺比較像是在 驗證一些 security 的東西。最後可以再用 swiss cheese diagram 做一個化簡的動作。 他們的系統,可以分成兩部分看,前面 negative testing 基本上就是 unit testing, 28.

(37) 將 web services 一個一個 operation 拿出來做測試,但是他是靠 test case 來做測試, 因為是使用隨機產生 test case 的方式,所以可能會出現沒辦法完整測試到整個 system 的狀況。不過他們的系統,還有考量到 security 的部分,這部分我們目前 的系統還沒將這邊一起考量進去。. 2.3 SOA testing 在 Testing services and service-centric systems: challenges and opportunities[22]這篇 paper 當中,作者 Canfora, G. , Di Penta, M 提出,在做 SOA testing 之時會遭遇許 多困難,第一個問題就是,services 之間很多 interactions 而且這些 interaction 還是 dynamic 的情形,所以在測試之時相當的麻煩。所以她們提出的想法是使用 mutation strategy 來做 service functional testing,作法為先由 request 端送出 request 到 target service,等到 target service 將 response 送回來之時,再來分析 response 是否有 fault。接下來他們會做整合性的測試,作法是利用幾組不同的 input 將其 輸入之後,看看系統是否能正確的運行,他們也提到因為 service 之間的 interaction 可能會因為不同的 message 有不同的 condition,所以他們也提出軟體測試的觀點, 就是要做 regression testing,就是當 path 出現分歧的時候,必須要在那個分歧的 地方再加以測試,不過他們自己也說這可能不是太容易。不過,現在我們的系統 就是在朝這個方向來做努力,採用 monitor 跟 replay 的方式,配合上 reachability testing,就是在運用這種方式做 testing。在 Challenges in Evaluating SOA Test 29.

(38) Processes[23]這篇 paper 當中,作者 Ayaz Farooq, Konstantina Georgieva, Reiner R. Dumke 提出使用 Evalution process 的方式來做 SOA 的 testing,一開始的時候他也 提到要做 SOA 的 testing 有相當程度的困難。因為以往的 testing 技巧,不能完全 work 在 SOA 的架構當中,因為他們的 interface 跟以往的架構不太相同,加上 service 的封裝,使得要做 testing 不是很容易。於是他們使用 evalution process 這 個 framework 來做 SOA 的 testing。這個 evalution process 有四個步驟,第一個步 驟是 establish evalution requirements,這個步驟主要是在做一些 initial 的動作,根 據 business 的需求,來定義一些 requirement,讓等下 evalution 時可以有一個方向 來針對這些 requirement 來做評估。第二個步驟是 specify evalution,這個會仔細 定義等下 evalution 一些 quality 的 attribute 以及 quality 的 matrix。第三個步驟是 Design evalution,這個步驟主要是考量到 resource 使用狀況的問題,可以定義 when, how, what 的一些狀況,讓整個 resource 的使用狀況也可以評估進去。最後一個步 驟就是 execute evalution,最後就是將所有上面定義的東西一起納入考量,去評估 受測程式的 quality,主要是使用 qualiity indexing scheme。當評估完成之後,會回 報一份 report,除了評估的結果之外,還會再給予一些改進的建議以及一些比較 危險的地方會標示出來。這個 work 也是有不少的挑戰,像是如何制定 SOA 的 test process。以及如何設定 evalution 的目標,最後就是 qualiity indexing scheme 這個 方法要用的 SOA Test Matrices。這些都是這個方法會遭遇到的問題,雖然作者都 有些方法可以來幫忙解決,但是他們還是有很多限制在,而我們的系統可以有比 30.

(39) 較 formal 的方式來解決各式各樣的 case。在 SOA: Testing and Self-Checking[24] 這篇 paper 當中,作者 Gerardo Canfora and Massimiliano Di Penta 提到,傳統的 testing 技術應用在 service-oriented architecture(SOA)的平台上,並不適用。因為 SOA 的架構當中每個 service 都可能與其他的 service 同一時間超過一個以上的 interaction,要怎麼可能做到 run-time 的 monitor,是一個相當大的挑戰。所以他 們提出的做法是採用 role testing and monitoring。role testing 是採用 XML 的資料 格式存放一些要輸入的 input 資料,製造 test case。而 role monitoring 他會 weaving 成一個 crosscutting concerns 在 system code (例如:BPEL 的 process 之中)上面,當 系統出現問題的時候會做一個 recovery 的動作。當兩個系統整合在一起的時候, 可以驗證 service QoS、service interoperability、service evolution。目前我覺得這個 framework 的想法還算不錯,不過因為有些地方都有相當難度的運作。所以很多 地方還要做一些限制。但是對於 SOA 這個新的架構方式,我覺得已經算是提供 了一個不錯的方式來做處理,比較大的缺點就是沒辦法確定在 concurrent application 執行的情況下,每一個 interleaf 都有執行到,不然的話我覺得考量算 是蠻完整的。. 31.

(40) 3. 將動態敏捷測試應用在網路服務 3.1 Race condition. Figure 3.1 Race Condition 雖然我們主要目標是針對 BPEL 的 application 來做驗證,但是其實 BPEL 的 message transition 還是建立在 web services 的 transition 之上,而 web services 的 message transition,是使用 SOAP1.1 的規格。兩邊溝通是採用 RPC 的方式,兩邊 靠者一份兩邊都同意的 XML 文件,這份 XML 的文件裡面定義這個 transition 的 operation 名稱與參數的型態,他的參數型態空間給的很大,除了一般的參數型態 如:integer、string、boolean、float、double 之外,還可以自己定義 structure ,另 如用 XML 格式可以表示出來的 tree structure 之類的。我們現在主要能夠處理的 32.

(41) 參數型態,還是屬於比較基本的那些格式 string、integer、double 等。我們處理的 方式就先以參數的名稱做為 share object 的 valueName,然後他們參數的 value 可 能為 integer、double 等,我們就把它作為 share object 的 value。我們現在是先根 據他們 access 的 share object,如果 access 同一個 share object 的時候,就認定它 們有 race condition 的狀況。我們目前處理 race condition 的是採用比較單純的 read、 write object 的方式來做,而且目前我們也沒有考慮其他的狀況,只要 access 到同 一個 object 我們就認定他是有 race 的狀況,未來在這個 race condition 的認定上還 可以多做改良,例如:我們可以多做一些分析,來判定兩者是否真的是有 race 的 關係。還有一個地方可以改進之處,就是我們現在能夠處理的資料型態都是基本 的資料型態,還沒有辦法處理比較複雜的資料結構,例如:樹狀結構的資料型態, 因為都是 XML 格式的表是型態,我們可以使用 encoding 的方式,把樹狀結構的 調整成可以使用基本資料結構的型態來做,不過,這邊目前還有技術上面的問題 需要去做。 當我們將 soap message 轉換成 read、write 的 shareobject 之時,我們會先將 operation 轉換成 read 或是 write 的 operation,我們會根據 operation 只是單純的 access share data 的話我們就將其轉換成 read operation。如果,operation 會 update share data 的話,這時我們就把他轉換成 write operation。因為我們主要是考量的問題是 share object 上面,所以我們對於 operation 就沒有做比較仔細的分析討論。而其他的 parameter 上面的處理,我們會透過 entry protocol 與 exit protocol 來記錄,因為每 33.

(42) 一個 request 都是由一個 thread 來處理。我們為了確保每一個 version number 都只 對應一筆資料,當進入 entry protocol 之時,會先去搶 semaphore,如果沒有搶到 的話,這個 thread 就會 waiting 在哪邊。如果搶到了就可以開始記路資訊,將 prcid 先記錄起來。然後將裡面的 soap message 的 parameter 利用 function 分別取出他的 valuename、value 將其紀錄在 event history,而透過 exit protocol 也會將其 version 的參數給紀錄在 event history。. Figure 3.2 Share object. 3.2 Prefix-based replay Prefix-based replay 基本上是依賴 proxy 來完成,當 SOAP message 傳入的時候, 這時 proxy 會先將 SOAP request 另外開一個 thread 來處理,所以每一個 request. 34.

(43) 都是一個獨立的 thread 來處理。所以這時的狀況,大家就變成 concurrent 在執行, 所以我們必須利用 semaphore 來確保同一時間只有一個一個 thread 進入 critical section 取得 version number。再配合上 entry protocol 與 exit protocol 來完成 prefix-based replay 的動作。. Figure 3.3 Proxy 要完成 prefix-based replay 主要是由幾個部分所組成,第一個部分就是 monitor, 當程式執行到 entry protocol 時,如果 mode 為 monitor 時,這時就要執行 monitor 的動作,而 monitor 的用意,就是將這時候的資訊給記錄下來,如果 mode 為 replay 時,這時就要執行 replay 的動作,replay 就是要根據我們推出來的 race variants 的 order 來執行,但是後面還是會做 monitor,所以 replay 是搭配 monitor 在做的。 35.

(44) 不管 mode 是 monitor 還是 replay,每次執行之後都會有 event log 產生。 所以我們先來看看,整個 EventLog 的資料結構,整個資料結構如下圖所示:. Figure 3.4 eventLog data structure eventID 為一個 structure,裡邊存放 prcid 與 evnseq。execinfo 則是在執行 entry protocol 與 exit protocol 之後,會將其紀錄起來的一個 structure。而 eventlog 則是 將 execinfo 這個 sturcture 收集進來,以及 RWOP、valuename、LOCCTR 組合而 成 eventlog 這個 structure。以下我們會用 code 輔佐,解釋每一個 parameter 的意 義。 public class EvntLog {. 36.

(45) public String RWOP, VarName, Mode;. public int VarVersion, VarValue, LOCCTR;. public EvntLog(ExecInfo tmpExecInfo, String RWOP, String VarName,. int LOCCTR) {. this.RWOP = new String(RWOP);. this.VarName = new String(VarName);. this.Mode = new String(tmpExecInfo.Mode);. this.VarVersion = tmpExecInfo.Version;. this.VarValue = tmpExecInfo.Value;. this.LOCCTR = LOCCTR;. }. }. Figure 3.5 EventLog eventLog 的結構如 fiquere3.5,一共有八個 item 的資訊,RWOP 是 string type 的 value 記錄這個動作是 read 或是 write 的 operation,這個是依據是否有 update 資料 來判定,如果有 update 資料就為 write operation,反之就為 read operation。varname 也是 string type 的 value 記錄 value 的名字,這個 value 通常是直接從 request message 37.

(46) 的參數中直接取出來。mode 則是記錄現在執行的 mode 是 monitor 還是 replay。 varversion、varvalue、LOCCTR 都是 integer type 的 value。varversion 是記錄 value 的 verison number,version number 是由 exit protocol 來領取。varvalue 就是存放 value 的值,可以從 request message 當中 query 出來。LOCCTR 則是記錄現在程式 運行到哪一個部分,這個數值可以由 BPEL process 當中設立一個 global 變數來存 取。 package RaceGraph;. public class EventNode {. public EventID EvnID;. public int VarVersion, LOCCTR;. public String VarName, Mode, RWOP;. public boolean Flag;. public EventNode() {. EvnID = new EventID();. VarName = new String("");. VarVersion = -1;. RWOP = new String(""); 38.

(47) Mode = new String("");. LOCCTR = -1;. }. }. Figure 3.6 EventNode 由於在進入 entry protocol 之時,其中有一個參數為 eventnode,所以我們先來看 一下 eventvode 的結構是什麼,eventvode 就是 racegraph 當中的 node,裡面的結 構也大致跟 eventlog 一樣,唯一不同的地方,就是多了一個 evnid 。 package RaceGraph;. public class EventID {. public int PrcID;. public int EvnSeq;. public EventID() {. PrcID = -1;. EvnSeq = -1;. }. 39.

(48) public void set(int PrcID, int EvnSeq) {. this.PrcID = PrcID;. this.EvnSeq = EvnSeq;. }. public void set(EventID theEvnID) {. this.set(theEvnID.PrcID, theEvnID.EvnSeq);. }. }. Figure 3.7 Eventid eventid 裡有兩個 value,一個是 prcid,就是指 processid 用來記錄這是哪一個 process 所產生的。另一個為 evnseq,用來記錄這個 event 的 sequence。. 當進入 entry protocol 時,如果 mode 為 monitor,就開始進行 monitor 的動作。一 開始會先搶 semaphore,搶到了才能進去將資訊記錄起來。接下來會進入 Exit protocol,然後 valverison 會先加 1 然後將 versionnumber、value 與 mode 暫時存放 到 execinfo 去,都完成了之後,再將 semaphore 放掉。 public void Entry(EventNode evnt, int ProcID, ExecMode mode,. ArrivalList Arrivals) { 40.

(49) if (mode.equals("monitor")) {. this.Smphr.down();. // VersionNum = VersionNumber.addVersionNum();. } else if (mode.equals("replay")) {. if (evnt == null) {. Arrivals.setArvl(ProcID);. while (!Arrivals.isAlltrue()) {. synchronized (Arrivals) {. try {. System.out.println(ProcID);. Arrivals.wait();. } catch (InterruptedException e) {. e.printStackTrace();. }. }. }. mode.set("monitor");. } else if (evnt.RWOP.equals("W")) {. while (this.Version != (evnt.VarVersion - 1)); 41.

(50) while (this.totalReaders[evnt.VarVersion -. 1].intValue() != 0);. } else {. System.out.println("SharedVariable.WriteEntry(): " +. "Error! Evnet[". + evnt.EvnID.PrcID + "," + evnt.EvnID.EvnSeq. + "] should be a write operation.");. }. }. }. Figure 3.8 Entry protocol public ExecInfo Exit(ExecMode mode, int AdjRemWriters) {. ExecInfo tmpInfo;. if (mode.equals("monitor")) {. this.Version = this.Version+1;. this.RemWriters = this.RemWriters + AdjRemWriters;. int tmpVersion = this.Version;. int tmpValue = this.Value; 42.

(51) tmpInfo = new ExecInfo(tmpVersion, tmpValue, mode.get());. this.Smphr.up();. } else {. tmpInfo = new ExecInfo(this.Version+1, this.Value,. mode.get());. this.Version = this.Version+1;. this.RemWriters = this.RemWriters + AdjRemWriters;. // FinishNumber.addFinishNum();. }. return tmpInfo;. }. Figure 3.9 Exit protocol. 3.3 BPEL synchronization model BPEL 本身的架構就是建構在 web services 之上,所有的 invocation 都是使用 web services 原本的通訊格式。而 web services 的通訊格式都是利用 WSDL 來描述的, 所以透過 Figure 我們先來了解 web services 的 message patterns。. 43.

(52) Figure 3.10 WSDL messaging patterns 第一種方式是 one-way 的 message 傳遞方式,只有 sender 端單向的送出 SOAP message。在 WSDL 的描述上面就是<operation>的 element 上只定義<input>這個 element。第二種方式是 request/response 的 message 傳遞方式,當 receiver 收到一 個 message 時,必須 return 一個 response。在 WSDL 的描述上面<operation>的 element 上先定義<input>element,然後再定義<output>element。第三種方式是 notification 的 message 傳遞方式,service 自己會 send message 給 client,但是並不 44.

(53) 會收到任何 response。在 WSDL 的描述上面,<operation>的 element 裡面,只有 定義<output>的 element。第四種方式是 solicit/response 的 message 傳遞方式,當 service 送出 message 給 client 的時候,會預期 client 會回應一個 response 回來。在 WSDL 的描述上面,<operation>的 element 先描述<output>的 element,在描述 <input>的 element,達到 solicit 的效果。這四種方式當中,第一種跟第二種算是 比較常見的,而這兩種方式的訊息傳遞,我們的 proxy 都可以直接處理。而第三 種與第四種算是比較特別的情況,我們的 proxy 可能需要一點調整。第三種語第 四種傳輸訊息的方式,都是由 receiver 這端來率先發送訊息,所以我們必須多增 加一個參數,來記錄傳遞訊息的模式,我們稱為 messagepattern。當使用第三種與 第四種方式傳遞 message 之時,因為 BEPL engine 的關係,我們必須使用 correlation set 做一個 mapping 的動作。因此,我們必須選一個參數作為 mapping 之用,所以 我們利用 prcid 做一個對應的參數,因此我們在記錄資訊之時,process id 變的不 可或缺,否則這種接近 asynchronous 的傳遞方式,proxy 如果沒有記錄到 correlation set 需要 mapping 的參數,我們的測試系統可能就會卡住,可能會發生一直 waiting 在那邊的情況。. 45.

(54) 4. 實作與實驗結果 4.1 Framework. Figure 4.1 Framework 整個 framework 的工作環境,都是由 BPEL 與 web services 建立而成。而我們的 系統是使用 axis2 這個套件來產生的。我先稍為簡介一下 axis2,apache axis2[25] 是一個 web 服務的核心支援引擎。之前版本是 axis。在 2004 年 8 月的會議討論 之後,正式確定新的架構。新的 axis2 是根據 axis1.x 改寫而來,而且提供 Java 與 C 兩種開發版本,axis2 比起原本的 Axis 更靈活更有效能。因為 axis2 使用更多模 組化的觀念,當你有一些特別的功能或是一些安全性的需求,可以直接以模組 (module)的方式添加進去。另外就是安全性的問題,web service 可靠信息服務由 apache sandesha2 支持 WS-Coordination,而 WS-Atomic Transaction 由 apache. 46.

(55) kandula2 支持 WS-Security,由 apache rampart 支持 WS-Addressing 已包括作 axis2 在為核心模組。而且 axis2 現在還支持異步 Web 服務和異步 Web 服務調用並使用 非阻塞的客戶端,這對於一些應用相當有幫助。而且 axis2 又可容易可以跟 tomcat 結合,所以是相當多 web service 實作平台的首選。 以下是我實作的幾個部分,一一的跟大家介紹: Test Script:test script 為一個 XML 檔案,作為其執行的腳本。agent 在執行的時 候就直接讀取 test script 做為 input 的 value。最大的作用就是可以達到自動化驗證 的目的,不用再等使用者輸入。而且當要改變 value 時,只要修改 test script 就可 以了,code 的修改幾乎都不用再變動了,我覺得這是在做 testing 之時一個蠻方便 的設計。以下為一個 test script 的 example。 <?xml version="1.0" encoding="UTF-8"?> <TestScript> <Application> <ParticipantBehavior> <ProcessName>0</ProcessName> <Peterson1> <Participant> <PrcID>0</PrcID> <flag0>1</flag0> 47.

(56) <flag1>0</flag1> <turn>1</turn> </Participant> </Peterson1>>. <ProcessName>1</ProcessName> <Peterson2> <Participant> <PrcID>1</PrcID> <flag0>0</flag0> <flag1>1</flag1> <turn>1</turn> </Participant> </Peterson2>>. </ParticipantBehavior>. <OutputVerificaton> <REGEX>Case\\s[0-9]*\\sis\\sOk|Case\\s[0-9]*\\sis\\sReject</REGEX> 48.

(57) </OutputVerificaton> </Application> </TestScript> Figure 4.2 TestScript <ParticipantBehavior>這個結構之內,就是那些原本應該是需要人輸入的一些資訊, 因為裡面可能會有不只一組以上的輸入,所以會使用一些 tag 將其做區分。例如: <Peterson1>,<Peterson2>就是代表兩組不同的 input。而<Participant>之中就是那些 input 的資料,分別會有一些欄位名跟數值。<OutputVerificaton>這個結構之內, 有一個<REGEX>的 tag,這個 tag 就是存放 java regular expression 的 pattern 在裡 面。 Agent:agent 為一個 java 程式,做為一個 client 端的啟動程式。當開始執行時, 會先啟動 inputreader 這個 function,利用 DOM 的技術,讀進 test script 中的資料。 將這些資料送入發送 web services 的 petersonthread 之中,做為 request 的 input 值。 接下來 petersonthread 就是將 request 利用 service 的 operation 將 request 發送到 BPEL process 當中,然後開始執行整個 BPEL process 的運作。當全部的 process 都執行完了以後,BPEL process 就會發送 response 給 agent。當 agent 收到 response 之後,我們會使用 java 的 regular expression 來驗證 response 所回傳的訊息是不是 我們所預期的。 Proxy:proxy 這個 web services,我是採用 apache axis2 結合 eclipse 的 axis2 code 49.

(58) generator 來製作的。proxy 在這個 system 當中,扮演非常重要的角色。原本正常 來說,應該是 BPEL process 直接發送 request 到 web services provider 就可以了, 並不需要一個 proxy。但是因為我們要 testing 的關係,所以必須多加一個 proxy 在 web services provider 之前,來運作 reachability testing。不過也因為這樣,原本 的 BPEL process 必須要做修改,將 invoke activity 的 WSDL 做一個修改,讓它發 送到 proxy 去。當 BPEL process 發送 request 到 proxy 之後,這時候因為 proxy 本 身就是一個 web service 的關係,所以當有一個 request 送到 proxy 來了之後。proxy 會另外啟動一個 thread 來處理這個 request,這樣才可以繼續監聽原本的 port,並 不會因為一個 request 就把整個 service 給占住了。所以我們的 proxy 是一個 multithread 的環境,所以我們在 proxy 之中就要利用 entry protocol 與 exit protocol 來記錄每個 request 存取 share object 的狀況。我們在 entry protocol 裡面使用了 semaphore 來保護同一個時間,只有一個 thread 可以進入 critical section 存取到 share object data。而我們的 entry protocol 與 exit protocol,會將存取的 share object 的資料 log 起來。內容包括 prcid、valuename、versionnumber、value、locctr,我 們將這些資料收集起來之後稱做 event history。當 BPEL process 都執行完畢之後, 我們會將每一個 proxy 的 event history 都收集起來,然後開始進行 race variants 的 分析。然後再根據推出來的 race variants 在執行一次 BPEL process,這樣的動作 會一直執行下去,這個動作稱為 prefixbased replay,直到 race variants 都執行到沒 有為止。當所以動作都完成了,代表這個 testing 的動作也完全執行完畢了,這時 50.

(59) 就會 BPEL process 就會回應 agent 一個 response 結束這個程式。 BPEL:我們的 application 都是使用 BEPL 來建構,而我們採用的 BPEL engine 是 activeBPEL[26]。由於他目前是 open source 加上 activeBPEL 幾乎就是 BPEL engine 的代表,許多目前一些開發的 BPEL 產品的基型,幾乎都是參考 activeBPEL, 於是我們也採用這一款代表性相當高的引擎。因為其有 GUI 介面的 editor,所以 建立起來並不困難,只要將原先建立好的 wsdl 根據需求,將他用適當的 activity 給 import 進去。再慢慢建立好整個 BPEL process,這樣 BPEL 文件也建立完成。 當文件建立好了之後,就要建立一個 pdd 來 deploy,由 pdd 加上 BPEL 的文件就 可以運作到 tomcat 之上。activeBPEL engine 本身並沒有辦法執行 asynchronous 的 message 的 transition。所以必須依賴 correlation set 來做一個 mapping 的動作。 correlation set 可以指定某幾個 wsdl 裡面的參數,互相 mapping 只有在參數相同的 時候才會讓另一個 receive activity 執行下去。可以參照下圖這個例子。當 invoke 的 message1 的 prcid 為 1,而如果送到 receive 的 message2 如果 prcid 為 2 的時候, 這時候 process 的執行就會 waiting 在 receive 那邊,直到 receive 收到 prcid 為 1 的 message,才會繼續執行下去。. 51.

(60) Figure 4.3 Correlation set Dynamic effective testing:由於我們將測試時所需的數據收集完成之後,還是必 須依賴 Dynamic effective testing 來做 race variant 的分析。當整個 SOA applications 全部執行完一次之後,我們寫了一個 Testmain 的 method 來執行 Dynamic effective testing。一開始先進行 state analyzer,把之前收集來的 syn-squence,進行 function 的轉換,避免有重複的 state 也放進去進行 race analyzer。 PSEGJointNodes tmpJntPnts = new PSEGJointNodes();. tmpJntPnts.get(ExecLogRG);. Figure 4.4 state analyzer 接下來就進行 race analyzer,當進行 state analyzer 之後,如果產生的數量為零的 話就不用進行 race analyzer。反之,就進行 race analyzer 來推導出 race variant。產 生 race variant 之後,將 race variant 放入 RVQueue 當中。 52.

(61) if(tmpJntPnts.size()==0). System.out.println("A3TestMain: Error! No Group-Joint. node produced.");. else {. RaceGraphSet TransformedSYNSequences1 =. StateAnalyzer.exec(ExecLogRG);. genRVNum =. RaceVariant.MultiGen(TransformedSYNSequences1, RVQueue);. }. Figure 4.5 race analyzer 接下來就是每次取出一個 race variant 來進行 prefix based replay,再將每一次產生 的 syn-sequence 記錄下來,再次進行 race analyzer 來推導 race variant。這樣反覆 的執行,直到將 RVQueue 當中的 race variant 全部消除完畢,就算是完整的執行 dynamic effective testing。 while(RVQueue.size()!=0) {. for(RaceGraph tmpRV : RVQueue) {. RVQueue.remove(tmpRV);. RaceGraph tmpExecLogRG = 53.

(62) PrefixBasedReplay.perform(tmpRV);. if(PetersonThread.gotInfiniteLoop) {. NumOf_gotInftLoop = NumOf_gotInftLoop+1;. }. NumOfTest = NumOfTest + 1;. ExecLogSet.add(tmpExecLogRG);. PSEGJointNodes tmpJntPnts2 = new PSEGJointNodes();. tmpJntPnts2.get(tmpExecLogRG);. if(tmpJntPnts2.size()==0) {. genRVNum = 0;. System.out.println("Error! No Group-Joint node. produced.");. } else {. RaceGraphSet TransformedSYNSequences2 =. StateAnalyzer.exec(tmpExecLogRG);. genRVNum =. RaceVariant.MultiGen(TransformedSYNSequences2, RVQueue);. } 54.

參考文獻

相關文件

應用閉合電路原理解決生活問題 (常識) 應用設計循環進行設計及改良作品 (常識) 以小數加法及乘法計算成本 (數學).

在這段記載中說到羅什為其小乘師說大乘方等空義,由於無法乍然令其

本程式要用到三個素材: 街道地圖 (舞臺背景) 、 媽媽 (角色) 和 蛋糕 (角色) , 應該如何安排到舞臺上?. 註 蛋糕 可在範例庫中找到, 媽媽 和

此塊控制電路主要在控制,當一個新的 IP 進來的同時,利用 lookup_change 這根 信號,先送至 Change Table,如圖 3.4.2-1,裡查詢此組 IP 是否已存在 Table

利用 Web Survey 來蒐集資料有許多的好處。許多研究者利用 Web Survey 進行研究的主要原因在於可以降低成本、即時的回覆。然而,Web Survey

值得一提的是,Add-in 在 Inventor 運行時會自動加載的特性是一個非常實用的功 能。使用者可以在執行 Inventor 前選擇所需要加載的 Add-in,而沒有選擇的

接下來的 FDTD 疊代運算將是整個計算的核心,也是運算量最大 的部分,在這中間,如何利用光波導的性質以及傳播常數等特徵參量

在軟體的使用方面,使用 Simulink 來進行。Simulink 是一種分析與模擬動態