Web服務(wù)可視化的研究.doc

Web服務(wù)可視化的研究日期：2006-05-23來源： 作者：字體：大 中 小 王衛(wèi)民 郭鳴 蘇德富摘 要 可視化不僅是語言環(huán)境的發(fā)展趨勢，還是組件開發(fā)的方向。Web服務(wù)1作為一種組件開發(fā)技術(shù)，其可視化也是一個值得研究得課題。本文首先分析了Claus Brabrand博士在他的博士論文Domain Specific Languages for Interactive Web Services2中提出的觀點，在此基礎(chǔ)上，提出了基于文件下載機制的Web服務(wù)可視化解決方案，最后改進了該方案，提出了基于窗體自動生成的Web服務(wù)可視化改進方案（WSVL）。關(guān)鍵詞 DSL，Web服務(wù)，可視化1 DSL的概念DSL3456是Domain Specific Language（領(lǐng)域?qū)Ｓ谜Z言）的縮寫。DSL是一種用于解決特定領(lǐng)域問題的計算機編程語言，它提供了該領(lǐng)域合適的、固定的抽象概念和符號。DSL通常比較小，側(cè)重于聲明而不是過多的規(guī)則或命令，并且比通用目標語言(GPL General Purpose Language)的表達能力要差。比如，DSL不能操縱復(fù)雜的數(shù)據(jù)結(jié)構(gòu)。所以領(lǐng)域?qū)Ｓ谜Z言也曾被稱為應(yīng)用領(lǐng)域語言、“小”語言或宏語言，與腳本語言緊密相關(guān)。像大家熟悉的SQL、Unix shells、makefiles等可以視為領(lǐng)域?qū)Ｓ谜Z言7。目前領(lǐng)域?qū)Ｓ谜Z言的應(yīng)用已經(jīng)滲透到各種領(lǐng)域，如圖形圖象、金融產(chǎn)品、電話交換系統(tǒng)、各種協(xié)議、操作系統(tǒng)、設(shè)備驅(qū)動程序、網(wǎng)絡(luò)中的路由器和機器人語言等。由于DSL在領(lǐng)域級別上的高度抽象性，使得其更易于編程、易于驗證，提高了產(chǎn)品的生產(chǎn)力、可靠性、可維護性和可移植性，并且可以實現(xiàn)系統(tǒng)級的重用。2 DSL for WS的基本思想Claus Brabrand博士在他的博士論文中，將DSL語言應(yīng)用于交互式Web服務(wù)的研究中，獲得了一個有效的解決方案。他的主要思想是：當Web應(yīng)用程序調(diào)用Web 服務(wù)時，該服務(wù)可以動態(tài)地產(chǎn)生HTML文件，該HTML文件可以被瀏覽器所解釋，轉(zhuǎn)換成相應(yīng)的Web窗體和服務(wù)器端組件代碼，這樣就可以實現(xiàn)Web服務(wù)與客戶端Web應(yīng)用程序的交互。Claus Brabrand博士采用了DSL來完成這個過程。論文從四個關(guān)鍵的方面來闡述了他的主張，它們是交互式會話管理、動態(tài)HTML/XML的產(chǎn)生、窗體字段驗證和并發(fā)控制。但是，我們知道，所有的應(yīng)用程序分兩大類，Web應(yīng)用程序和桌面應(yīng)用程序。Web服務(wù)的使用者不僅僅是Web應(yīng)用程序，更應(yīng)該是桌面應(yīng)用程序。否則，就根本不需要Web服務(wù)這種技術(shù)了。因為傳統(tǒng)的Web應(yīng)用程序就可以滿足和客戶端Web應(yīng)用程序的通信了，且交互性更優(yōu)。當Web服務(wù)的使用者是桌面應(yīng)用程序的時候，Claus Brabrand博士提出的方案顯然就滿足不了組件可視化的需求了。同時Claus Brabrand博士主要是從交互式應(yīng)用的角度來考察Web服務(wù)的交互能力的，我們知道，交互并不一定是可視化的?，F(xiàn)在我們需要從可視化的角度來重新考察這個問題。3 Web服務(wù)可視化的研究可視化的組件比非可視化的組件更好用，更易于維護。當任何一個動態(tài)庫成了組件，就希望成為可視化的控件，Web服務(wù)組件也不例外。該文主要研究了如何將Web服務(wù)可視化的問題。提出了自己的一些設(shè)想，并在一個Web服務(wù)中間件的開發(fā)中使用了這種設(shè)想。我們首先提出了基于文件下載機制的可視化實現(xiàn)方案，然后改進這個方案，提出了WSVL解決方案。圖1 傳統(tǒng)的Web服務(wù)調(diào)用過程圖1顯示了傳統(tǒng)的Web服務(wù)的調(diào)用過程。我們以一個實例來說明這個過程，比如一個遠程的Web服務(wù)組件WSAuthentication，該組件有一個認證操作，bool Authentication(string username,string password)的操作，其結(jié)果是驗證傳遞的用戶名和密碼，返回驗證的結(jié)果true或false。我們添加了相應(yīng)的Web服務(wù)之后，我們就可以使用這個組件了。為了客戶可以自己輸入用戶名和密碼，我們需要建立一個窗體，它有兩個文本框，一個輸入用戶名，設(shè)為EditName，另一個輸入密碼，設(shè)為EditPassword，有兩個按鈕，一個是“確定”按鈕，另一個是“取消”按鈕。我們編寫確定按鈕事件如下：WSAuthentication theWSAuthentication =new WSAuthentication();/建立Web服務(wù)對象bool b= theWSAuthentication.Authentication(EditName.text,EditPassword.text);/向這個對象發(fā)送消息，要求認證。MessageBox.Show(b.ToString();/顯示認證結(jié)果。這就是一個完整的Web服務(wù)組件的使用過程。但是，在這個過程中，我們發(fā)現(xiàn)：第一，這個界面非常特殊，完全可以由客戶端或服務(wù)器端自動生成；第二，這個過程直接暴露了Web服務(wù)的操作。這顯然是很不安全的。為了解決這兩個問題，同時實現(xiàn)組件的可視化，我們對這個調(diào)用過程改進如下圖2所示：圖2 改進的Web服務(wù)調(diào)用過程在這個過程中Web服務(wù)客戶端之前增加了Web服務(wù)界面層，由它負責調(diào)用Web服務(wù)的功能。現(xiàn)在的問題是這個Web服務(wù)界面從哪里來，針對Web服務(wù)界面的來源，我們有兩種不同的設(shè)計方案。1）基于文件下載的解決方案第一種就是基于文件下載的解決方案。這種解決方案的最大特點是，界面從Web服務(wù)端下載下來。界面可以是語言相關(guān)的窗體代碼，也可以直接是二進制代碼，比如可執(zhí)行文件。這兩種文件的傳送方式是不一樣的。窗體代碼可以采用XML文件的形式傳送，二進制代碼則不行。在這里我們僅僅討論二進制代碼的傳送。首先，我們需要在客戶端編寫程序，它可以將字節(jié)流數(shù)組轉(zhuǎn)換可執(zhí)行文件，并運行，返回調(diào)用結(jié)果。void *ExecByte(byte);第二，我們需要在服務(wù)器端編寫每一個Web服務(wù)對應(yīng)的界面程序。第三，我們在服務(wù)器端編寫一個額外的文件下載服務(wù)方法。它可以將指定的文件轉(zhuǎn)換成字節(jié)流傳送到客戶端。byte DownLoad(string filename);第四，同時我們編寫統(tǒng)一的服務(wù)調(diào)用操作，它會將方法對應(yīng)的程序轉(zhuǎn)換成字節(jié)流。byte Show(string methodname);這樣，Web服務(wù)的調(diào)用過程變成了：WSAuthentication theWSAuthentication =new WSAuthentication();/建立Web服務(wù)對象bool *pb=bool*（ExecByte(theWSAuthentication.Show(“Authentication”)）;MessageBox.Show(*pb).ToString();/顯示認證結(jié)果。其中theWSAuthentication.Show(“Authentication”)將認證操作對應(yīng)的可執(zhí)行文件轉(zhuǎn)換成字節(jié)流，并傳送到客戶端。ExecByte將該字節(jié)流轉(zhuǎn)換成可執(zhí)行文件，并執(zhí)行。執(zhí)行的結(jié)果是，屏幕上將出現(xiàn)一個標準的對話框，提示你輸入用戶名和密碼，你輸入用戶名和密碼后，點擊確定按鈕按鈕將調(diào)用真正的認證操作，認證操作的結(jié)果保存到pb中，如圖3所示。圖3 認證對話框在該方案中，第一步需要的程序可以直接在開發(fā)環(huán)境或操作系統(tǒng)中提供；第二步的界面，第三步的下載服務(wù)，第四步的統(tǒng)一的服務(wù)調(diào)用操作都可以由Web服務(wù)開發(fā)工具自動生成。該方案的優(yōu)點：(1)大大提高Web服務(wù)的安全性；(2)更強的交互能力和統(tǒng)一的調(diào)用方式；(3)它還有一個不可忽視的優(yōu)點是Web服務(wù)操作的界面上可以承載廣告，費用信息等內(nèi)容。缺點：(1)服務(wù)器要傳送大量的程序；(2)由于從Web服務(wù)所在的服務(wù)器上下載文件直接運行，對客戶端來說是不安全的；解決的方法是觀察Web服務(wù)界面的統(tǒng)一特點，由客戶端自動生成界面代碼。這就是下面的WSVL的解決方案。2）改進的解決方案WSVL以上的做法值得改進，原因有二：一、服務(wù)器端需要編寫多個與Web服務(wù)相關(guān)的額外的程序；二、該程序需要下載到本地，同時在本地要有一個函數(shù)來處理這些程序。我們改進這些過程，原因是客戶完成Web服務(wù)的添加之后就可以知道Web服務(wù)有關(guān)方法的實現(xiàn)接口，客戶端完全可以根據(jù)這些接口生成相應(yīng)的界面和對應(yīng)的處理程序。例如上述的認證操作，它的界面上將有兩個label,一個label的caption是用戶名，另一個的caption是密碼；有兩個edit，窗體有兩個數(shù)據(jù)成員，它們是WebServicesObject，保存這個Web服務(wù)對象，另一個是result，保存服務(wù)調(diào)用的結(jié)果。這兩個變量都是可變對象；有兩個按鈕，一個確定按鈕按鈕，一個取消按鈕按鈕。一個確定按鈕的程序是：thisform.result=thisform.WebServicesObject.Authentication(editusername.text,editpassword.text);thisform.hide;另一個取消按鈕的內(nèi)容是：editusername.text=“”；editpassword.text=“”；我們以偽碼來表示窗體設(shè)計模式：圖4 窗體模式文件圖示模式 Form(list,operate,WebServiceType,Type)/模式有五個參數(shù)，list表示W(wǎng)eb操作的參數(shù)名稱數(shù)組；operate對應(yīng)Web操作的名稱，WebServiceType表示了該操作對應(yīng)的Web服務(wù)的類型。Type則表示該操作的返回值的類型,如圖4所示。根據(jù)list數(shù)組的個數(shù)n，界面上將有n個label和n個edit框。其中l(wèi)abel的名稱由label連接listi組成，它的caption屬性為listi，同樣edit的名稱由edit連接listi組成。i從0開始到n-1：Label：名字為lable+List0,顯示為List0Label：名字為lable+List1,顯示為List1.Label：名字為lable+Listn-1,顯示為Listn-1Edit：名字為Edit+List0Edit：名字為Edit+List1.Edit：名字為Edit+Listn-1有兩個變量：一個是Web服務(wù)對象，另一個是返回值類型的對象：WebServiceType WebServicesObject；Type result；有兩個按鈕，確定按鈕和取消按鈕。確定按鈕的程序：(這里用EditI代表第I個文本框的名字。)result=(Type) WebServicesObject.operate(Edit.text,Edit2.text,.,Editn.Text);thisform.hide;取消按鈕的程序：edit1.text=“”;edit2.text=“”;editn.text=“”;最后是窗口布局。/模式結(jié)束我們可以將該設(shè)計模式用XML模式文件表示29。在Visual Studio.Net中可以用設(shè)計模式來表示30。在添加Web服務(wù)時，讓客戶端環(huán)境中的窗體生成向?qū)硖幚磉@個模式文件，生成所有的窗體文件。生成的窗體文件將有兩種形式：可執(zhí)行文件或環(huán)境有關(guān)的窗體代碼，如果是第一種，處理與上相同，否則處理的時候就完全可以把它當成一個可視化的組件。這就實現(xiàn)了設(shè)計時的可視化，這時，我們可以改進生成的窗體的布局，改進界面設(shè)計。實現(xiàn)了設(shè)計時的可視化后，僅僅需要在設(shè)計時添加屬性值就行了。編譯時這些程序就會和程序員編寫的程序一起被編譯。WSVL將有兩個部分組成，如圖5所示。圖5 WSVL組成圖示一部分是模式文件，它能根據(jù)輸入的參數(shù)產(chǎn)生具體的窗體；另一部分是窗體生成向?qū)?。該向?qū)г谔砑右脮r被激發(fā)，讓用戶在選擇了要添加的Web服務(wù)之后，選擇要產(chǎn)生窗體的Web方法，然后該向?qū)Ь鸵赃x中的Web方法的參數(shù)列表、它的方法名字、Web服務(wù)類型以及返回值類型為參數(shù)，執(zhí)行窗體模版，形成所需的窗體文件。方案的分析：優(yōu)點：顯然，它可以解決基于文件下載機制所帶來的不足。缺點：這個方案還有待完善。生成的窗體文件太多也將造成客戶端的負擔，同時這種方案的實現(xiàn)離不開客戶端的支持。當然，如果客戶端不支持這個，我們完全可以自己編寫一個工具來實現(xiàn)。4 小結(jié)Web服務(wù)的可視化是一個值得研究的課題，本文主要提出了Web服務(wù)的可視化的兩個方案。隨著Web服務(wù)技術(shù)的進一步成熟，它的可視化技術(shù)的進一步發(fā)展，以及MDA工具的不斷推廣，我們將可以在利用MDA就可以直接得到可視化的Web服務(wù)。那時，Web服務(wù)完全就可以象本地控件一樣地使用了。參考文獻：1 柴曉路,梁宇奇.Web Services技術(shù)、架構(gòu)和應(yīng)用M.電子工業(yè)出版社.2003年1月第1版.2 Claus Brabrand.Domain Specific Languages for Interactive Web Services. PhD thesis, Department of Computer Science University of Aarhus Denmark 2002 9.www.brics.dk/brabrand/dissertation.pdf.3 D. Atkins, T. Ball, M. Benedikt, G. Bruns, K. Cox, P. Mataga, and K. Rehor. Experience with a domain specific language for form-based services. In Proc. Conference on Domain-Specific languages, DSL 97.USENIX, October 1997.4 D. Atkins, T. Ball, G. Bruns, and K. Co