WWW訪問傳統客戶/服務器應用的方法

2019-11-18 15:13:00

字體：大中小

來源：轉載

供稿：網友

　　作者：張文麟

--------------------------------------------------------------------------------

一、概述

在過去的幾年中，人們已經開發投資成千上萬的客戶/服務器應用。這些應用中包括一個非凡的運行在中心計算機上(也有可能是幾個)的服務器軟件，以及運行在應用系統各用戶端的非凡客戶軟件。現在人們更希望能夠在原有的系統中加入Internet的功能。WWW孕育了大量了WEB瀏覽器，對Html標準語言這些瀏覽器是“可編程的”。可以在瀏覽器開發平臺上建立客戶/服務器系統的用戶。?
有幾種訪問傳統客戶/服務器應用的方法：?

修改現存的服務器軟件“模擬”一個WEB服務器。
這只是對非常簡單的應用可行。可以想象將數據庫引擎搬到WEB上情形，對數據庫的查詢都表示為URL。對布滿交互的應用采用本方法實現有困難。?
使用瀏覽器有關的工具。比如Mosaic的CGI和Netscape的PlugIn API為客戶/服務器系統建立基于客戶機的WEB瀏覽器。然而，使用API限制導致了平臺相關和瀏覽器相關的客戶軟件的應用。?

創建一個“中間件”。
中間件在WEB瀏覽器和服務器之間充當路由器。在這種客戶/服務器體系中，WWW瀏覽器作為替代客戶/服務器的系統客戶端軟件，不僅能顯示和格式化從服務器接收到信息，而且WEB瀏覽器能夠請求中間件為服務器或客戶端軟件執行額外的工作。?
使用CGI程序能夠實現中間件的功能。這是目前應用最多的方法。目前，每種WEB瀏覽器支持代理(PRoxy)應用。HTTP代理通常用于在Internet防火墻之后的WEB訪問、或者作為控制訪問企業內部網的系統。當WEB瀏覽器用戶請求一文件時，WEB瀏覽器不是直接連接到文件指定的URL處、而是先與代理聯系，代理為WEB瀏覽器讀取文件并回傳給瀏覽器。?
HTTP服務器和HTTP代理可用來建立瀏覽器客戶能夠訪問現存客戶/服務器系統中服務器的中間件。這種方法使客戶/服務器系統和數據遷移到WWW上的工作變得輕易。基于中間件的方法不必對現在的應用服務器代碼做修改。?

二、基于CGI數據庫訪問的方法
??
在WEB上典型的數據庫應用包含三個部分：WEB瀏覽器或有時稱為WEB客戶，帶有CGI程序的HTTP服務器，數據庫服務器。當用戶的請求從WEB客戶端(一般是HTML form)傳送到HTTP服務器時數據庫開始查詢并初始化。根據收到的用戶請求，HTTP服務器激活CGI程序，CGI把用戶輸入數據嵌入數據庫的SQL語句，然后將其送到數據庫服務器處理。查詢結果由數據庫服務器送到CGI程序返回，通過HTTP服務器傳送到WEB客戶端。由于CGI是HTTP服務器與外部程序事實上的標準界面，這種數據庫訪問的模式成為當今WEB世界最常見的方法。?
CGI的概念源于為HTTP服務器與用戶自定義服務器應用程序之間提供界面。盡管有其簡單和被廣泛接收特點，基于CGI的方法存在一些共性的問題。首先，在客戶與后臺數據庫之間的通信必須通過中間的HTTP服務器，當大量的用戶同時訪問時HTTP服務器很輕易成為瓶頸。對每個用戶提交的查詢或每一個數據庫服務器的響應，HTTP服務必須將從HTML文檔轉換到數據或從數據轉換到HTML文檔。這必然為查詢處理增加了大量的無效工作。?
第二個問題是基于CGI數據庫訪問模式缺乏效率和缺乏事務的支持。對每一通過CGI提交到后臺數據庫服務器的查詢，甚至對同一用戶提交的連續的查詢，數據庫也要執行相同的login和logout的過程。這個過程肯定浪費許多的時間和資源，尤其當大量用戶同時訪問數據庫之時。這是因為CGI程序只能以批模式處理多個查詢，故CGI程序很難支持在線的數據庫事務，這些事務包括在交互模式下與控制函數一起執行多次查詢。
這個問題是繼續了HTTP的無狀態性，HTTP是在WEB上客戶/服務器通信的標準協議。無狀態性是指服務器對客戶請求的反應不依靠于前面的請求和反應的信息。象HTTP之類的無狀態協議對單個查詢類型的應用是合適的，但對于處理面向會話的數據庫程序、當效率和事務處理作為主要焦點時就不夠理想。許多的程序開發者提出了圍繞HTTP無狀態性的不同解決方案，但是只有當低層的協議能夠支持有狀態的客戶/服務器通信、才能形成全功能的數據庫系統。?
第三個問題是由于HTTP的無狀態性缺乏用戶訪問控制。WEB客戶以批模式傳送查詢數據和必需的用戶ID和密碼。由于請求的數據一般由WEB客戶以明文的ASCII格式傳送到HTTP服務器，這種做法是不安全的。出于安全考慮，一般將用戶ID和密碼嵌在訪問后臺數據庫的CGI程序中，而用戶的訪問控制由HTTP服務器處理。HTTP服務器安全功能只能處理用戶域的控制、并沒有更細的訪問控制功能，即在數據庫層次上的各種特權功能(比如：讀、寫、數據庫治理和數據庫擁有者，等等)。在企業環境中，人們渴望使用由數據庫服務器提供的、現已存在的用戶訪問控制功能，使得相同的安全性和訪問特權能夠作用于整個企業網絡。第四個問題是由于HTML的限制缺乏圖形表示。HTML文檔是靜態的，沒有動態的2D和3D圖形表示。盡管VRML能夠處理復雜的3D圖形，但它依靠HTTP而且沒有提供直接的通信接口。借助于形成GIF格式或其它圖形格式的圖像可以實現圖形表示，由于所有的圖像必須由在HTTP服務器端的CGI程序產生，這種方法速度低而且浪費空間。客戶/服務器模式主要的優點之一是所有的用戶非凡功能??比如查詢結果的圖形表示??應在客戶端進行。唯一的可能是WEB客戶端能夠實現動態的圖形功能。?

三、基于中間件訪問數據庫的方法
?
1?中間件訪問數據庫的方法優點
?
為所有的平臺編寫一個客戶軟件?
開發特定的客戶軟件使用戶的界面具有無窮的創造性，但是這種創造性帶來的是高價格，開發者必需為每種運行平臺開發客戶軟件。在異構的網絡環境中意味著為Macintosh,MS Windows,以及各種各樣Unix開發客戶軟件。當客戶使用瀏覽器時，系統中只有一套代碼(HTML和幫助程序)需維護。當客戶必需調用中間件不能模擬的功能時，可使用新的MIME和幫助應用程序。此時，由于功能的要求，必需為每一種運行的平臺建立MIME幫助應用程序，但其代碼長度比特定客戶應用程序平臺相關的代碼長度短得多。?

模塊化?
一旦WEB瀏覽器訪問系統結構建立起來，修改系統變得簡單。?

統一界面?
在天天有多個用戶群使用多個客戶/服務器應用的系統中，當系統遷移到WEB上后，不同系統的不同用戶界面合并成一個統一的界面。這能帶來多種好處，包括降低培訓費用，系統中用戶的交流變得輕易。?

2?客戶/服務器系統遷移到WEB的幾點基本要求?
實現現存客戶/服務器系統大部分的功能?
新的基于WEB的系統必需實現現存客戶/服務器系統的大部分功能。答應有少量的功能不能在WEB上實現，但是當許多原系統的功能沒有實現時，往WEB的遷移是無意義的。?

現存客戶/服務器系統變最小化?
遷移過程中必需的變動員不需大量修改現存的代碼。現存的客戶和服務器應能照常工作。遷移過程中修改代碼不可能時(比如商品化軟件的原代碼是不可得的)，可以建立中間件以應付不能修改現存的代碼。?
不修改HTTP或HTML標準?
不能修改HTTP或HTML的標準。標準的HTTP請求被創建的中間件處理，并將請求路由到現存的應用服務器上。

使用流行的瀏覽器軟件?
為保證系統的可用性，使用流行的瀏覽器軟件。?

3?體系結構?
這是一種三層結構模式的客戶/服務器應用系統。為了將系統連接到WEB上，在基于WEB客戶和現存應用服務器之間建立HTTP代理(圖1)。HTTP代理設計成數據翻譯為HTTP請求，并將該請求轉換成傳統系統的協議請求。??
HTTP代理(或中間件)可在原服務器同一臺計算機上運行，也可運行、連接到服務器在LAN中的任一臺計算機上。中間件不必與WEB瀏覽器運行在同一臺計算機上，一個中間件轉換系統中多個WEB瀏覽器用戶的請求。這解決了每個基于WEB用戶有一個中間件的資源問題。?
有多種創建中間件的方法：?

從零開始建立中間件?
當WEB界面加入到沒有原代碼的系統時(也許是商品化的軟件包)、或者修改任何一小段代碼都很困難時，只有從零開始建立中間件。?

基于現存系統客戶的中間件?
現存的客戶可改為其行為如同一個HTTP代理服務器。當新HTTP代理的代碼部分收到來自WEB瀏覽器客戶的請求時，它簡單地將請求送入服務器。當客戶端代碼較簡單時，此法只需修改少量的現存代碼。?

直接修改服務器代碼?
在某些情況下，為了直接與WEB瀏覽器交互可以修改服務器代碼。這取決于服務器是否依靠于現存客戶“狀態”，即在多個請求之間記憶應用的狀態。在這些情況下，修改系統客戶代碼比修改服務器代碼要復雜得多。?

同時修改客戶和服務器的代碼?
建立在現存系統客戶的中間件和將服務器修改成與新客戶交互時有不同的行為，也許是可行的方法。服務器期望系統的每個客戶只表現為一個用戶，因為在我們的體系結構中，一個中間件響應多個基于WEB的系統用戶。為了建立一對多的映射，有必要修改服務器代碼或修改在服務器與新“中間件客戶”之間的協議。?
有幾個因素使問題復雜化。首先，HTTP協議是無狀態的，然而許多現存的客戶/服務器系統使用的是有狀態的協議。按照現在HTTP協議說明，WEB瀏覽器連接到服務器、發出請求并接收響應，隨后關閉連接。在多數客戶/服務器系統中的特定客戶打開與服務器的一個連接，并在整個會話期間保持這個連接。為了在基于WEB客戶端模擬這種功能，必需：?

為基于WEB的客戶維護狀態信息?
中間件可以把稱為“magic cookies”嵌入HTML送往WEB瀏覽器。cookies使中間件辨別每個獨立的瀏覽器，保存每個瀏覽器的狀態信息。這種方法有一個問題，即無法確定系統WEB瀏覽器客戶是否崩潰或被重新啟動。此時，中間件要為崩潰的客戶放棄事物，執行中斷連接或執行容錯協議。由于無法確定客戶是否崩潰，中間件必需使用一些確定執行信息的專橫的方法，可以根據閑置時間或其它一些不完美的方法。?
將狀態信息嵌入送往WEB客戶的HTML中，在請求之間不保留狀態信息?
此法辨別WEB客戶magiccookie方法的一個擴展。Magiccookie在客戶端產生并隨瀏覽器用戶對中間件執行的每個命令而變，每個對中間件的請求包含了直接嵌入的WEB客戶請求狀態。中間件能夠從前一個請求中確定用戶已經成功地完成。?
另一個是問題復雜化的因素是中間件要直接處理一些HTML文檔。中間件處理的URL有可能不轉換到現存的服務器的命令。例如URL提供了系統HTML用戶的界面或為系統的新用戶提供幫助信息。為此，中間件維護一個小型的HTML文檔樹。當中間件接收來自WEB客戶的請求，必需確定路由到服務器還是該請求用中間件自己文檔樹中的文檔作應答。?
此外，更為嚴重的問題是如何處理原來客戶端為服務器處理的非凡應用功能。包括調用外部工具和使用平臺相關的類庫、設備或操作系統的訪問服務。只使用HTML的WEB瀏覽器客戶一般不能模擬現存系統特定應用功能。有幾個解決此問題的方法：?

中間件模擬?
中間件可以為WEB瀏覽器客戶執行一些客戶的任務。在以批方式調用外部工具的情況下，只是做簡單的輸入和匯總輸出工作，此方法是可行的。因為批工具要求在運行時不被中斷。當中間件和基于WEB客戶都運行在X display下時，這同樣有可能調用交互工具的XWindows。中間件啟動同一計算機上的工具，并在用戶的X display上顯示該工具的界面。?

新的MIME類型和MIME處理程序?
這里討論的是必須在WEB客戶計算機上使用外部工具和系統服務。方法是建立平臺有關的MIME幫助程序，該程序響應由中間件下送到瀏覽器的新MIME類型。例如，可使所有WEB瀏覽器在收到一個“X-Foobar”MIME信息時運行一個“Foobar”程序。因為每個HTTP響應包含了一個MIME說明，中間件只是簡單地通知瀏覽器應答是“X-Foobar”類型，瀏覽器就會運行“Foobar”程序。?

Mosaic CGI和Netscape PlugIn API?
瀏覽器生產廠商提供的不同API編寫的瀏覽器相關的代碼，較好地實現WEB瀏覽器與幫助程序之間的集成。例如，假如所有的基于WEB用戶都使用Netscape Navigator作為他們的瀏覽器，設計者就能建立處理由中間件發送的、新“X-Foobar”類型的Netscape PlugIn。編好的API代碼直接在瀏覽器窗口中運行，保持了客戶/服務器系統與WEB瀏覽器之間的無縫集成。?

java applets?
Java applets能夠實現與上述瀏覽器相關API相類似的擴展。最重要的優點是瀏覽器和平臺的無關性，可靈活地建立各種擴展。?

四、基于JAVA數據庫訪問的方法?

對于WEB，使用APPLET的真正潛力在于JAVA APPLET的可移植性可連接性。JAVA APPLET運行在支持JAVA的瀏覽器中，象本身就是一個瀏覽器。在JAVA中建立數據庫客戶最輕易的方法是使用廠商提供類庫(假定這些類庫由C語言編寫)的包裝類，編譯這些類庫作為動態連接庫。然而，出于安全的考慮，只有獨立的JAVA程序才能連接動態連接庫。當JAVA APPLET在WEB瀏覽器中運行時是不準訪問本地文件系統。APPLET訪問遠程服務器的唯一路徑是通過JAVA的SOCKET接口。?
一般來講，有二種構造作為遠程數據庫服務器客戶的JAVA APPLET。一個是使用所有功能都在JAVA中實現的二層結構(圖2)。另一個是使用三層結構，其中獨立的JAVA服務器用作為路由器在APPLET和遠程數據庫服務器之間傳遞請求和響應信息(圖3)。前者需要較高的編程能力，原因是JAVA客戶必須在廠商特定類庫的協議層次上實現。后者較易實現，原因是借助JAVA客戶類庫函數，可以建立獨立的JAVA應用程序?路由服務器。當訪問數據庫服務器時，路由服務器作為通信服務器，與JAVA APPLET連接用用戶定義的協議，在另一端是原本的客戶/服務器協議。?
目前用二層結構完成的數據庫客戶包括：MsqlJava,MiniSQL。客戶/服務結構用三層結構包括：Weblogic dbKorta/T3和由Vincent Engineering開發的OCI/JAVA Gateway。為訪問包括Oracle,Sybase和Informix在內的關系數據庫，前者提供了用JAVA開發客戶和服務器的許多類庫。后者利用(OCI(Oracle Call Interface)連接oracle數據庫。?

五、結論

在本文中，我們展示了應用在WEB上的方法。與基于CGI數據庫應用的方法比較，基于中間件的方法具有更多的優點，基于JAVA的方法更具靈活性、可伸縮性和強壯性。它提供了一條構造以WEB應用為目標的、使用WEB瀏覽器訪問傳統客戶/服務器應用的途徑。

上一篇：Why Java can be used for games?

下一篇：開發Eclipse下的自定義控件