Java客戶端工具選擇：HTML？Swing？XML？

整理下面的文章是由於我的以爲寫的很好，關於java的客戶端了解也並非太多。看了下面的文章以爲頗有必要貼出來，方便本身之後瞭解java客戶端編程。

Java軟件設計師和管理人員常常會面臨這樣的難題：在開發應用軟件的客戶端時，應該在Swing、HTML、XML三種技術中選擇誰。在這篇文章中，我將把本身在這三種技術方面的經驗與廣大讀者共享，並對在Java應用軟件開發中選擇哪種技術提出一些標準和技巧。在文章的最後，還會介紹一種整合Java Swing和HTML的新方法。

　　與現有的技術相比，Java有明顯的優勢，所以它已經在服務器端應用軟件的開發中確立了主導地位。然而，因爲每個應用程序都有幾種形式的用戶界面和前端的表達形式，咱們中的許多人都對在客戶端採用Java技術有很差的印象，所以在客戶端的開發中採用HTML彷佛已經成爲惟一的選擇了。好比說我，在java客戶端這塊，我基本是在玩HTML。

　　實際狀況是，在客戶端應用程序的開發中不止只有HTML一種選擇，咱們將在本文討論基於Java的應用軟件開發中三種用戶界面的解決方案。我將首先討論HTML與JSP和servlet聯合使用的優勢和缺點，而後討論Java最初的目標之一：經過GUI Applet實現交互式互聯網。最後，咱們將討論XML以及由它所衍生出來的其餘技術。

• 　　JSP/Servlets環境下的HTML客戶端

　　大多數讀者都曾編寫過servlet、開發過JSP應用，清楚基於HTML的用戶界面的優勢和缺點。選擇HTML的最大的理由仍然是其普遍的平臺適應性，基本HTML的標準性很好，雖然比較枯燥，但它能夠很好地完成工做。

　　因爲HTTP/HTTPS協議很是簡單，可使開發的應用程序很好地適應各類網絡配置和防火墻。但這是有代價的，HTML缺少與用戶的交互性，並且對用戶每一個行爲的響應都須要與服務器進行鏈接。做爲一名編程人員，咱們一直在追求簡單性，並使開發的軟件能夠適合全部的瀏覽器？然而簡單性並不老是好的，簡單地說，與靜態HTML相比，JavaScript能夠較好地實現不太複雜的交互性，但對於開發複雜的用戶界面而言，它仍是不能勝任的。

　　除非擁有高速的互聯網鏈接，不然你必定有過焦急的等待加載一個網頁的經歷。儘管瘦客戶端提供了一些很好的非交互性的用戶界面，但傳統的胖客戶終端通常狀況下都比它們更聰明。例如，Netscape Communicator和MS Outlook等電子郵件的前端就比基於互聯網的電子郵件工具具備更好的用戶親和性。

　　用Java開發一個HTML前端應用是一個很好的選擇，由於HTML提供了跨平臺的內容傳輸能力。編程人員可使用Java Servlets和JSP開發在任何操做系統平臺上運行的服務器端應用程序。同時考慮到衆多的Java API和它獲得的普遍的服務器開發商的支持，對於開發可伸縮互聯網站而言，Java是一種理想的選擇。

　　總而言之，配合使用Servlets和JSP的HTML前端開發工具是開發靜態界面的很好的方式，但當須要對用戶的行爲做出快速反應和須要對數據進行高速處理的複雜應用時，這種方式則不大理想。

• 　基於Swing的GUI客戶端

　　今天還有多少人在使用Java Applet做爲客戶端？也許使用基於HTML的UI更安全，但這是最好的選擇嗎？

　　AT&T的一個業務部門Telecorp PCS曾經開發過一個應用程序，使其商店能夠收集但願購買移動電話的用戶的資料，檢查其信用卡，而後當即開通移動電話，除了確認用戶輸入的信息外，應用還必須經過使用排序、選擇和其餘的標準數據庫功能處理提交的報告。此外，當一個新的移動電話開通後，這個應用程序還須要顯示一個通知。

　　你能相像用HTML來完成這一切嗎？也許可能，但它將很是討厭，並且速度很慢，須要不間斷地使用網絡鏈接。Telecorp PCS決定冒險在交互的Applet中使用Java，那麼結果如何呢？徹底成功，這一應用程序在開發時採用了Swing，並佈署在採用了Java插件的互聯網網站上。經過使用Swing UI類，很簡單地完成了應用所要求的功能。

　　我相信許多開發人員在早期使用Java時，都使用過applet，而且在解決各類瀏覽器之間的不兼容性、applet下載時間、性能方面花費過大量的時間。對客戶端Java最大的批評來自其對象性，但如今狀況已經有了很大的改觀。Sun已經花費了大量的時間來改進其代碼的質量，下面我將向你說明爲何基於Swing的UI是值得一試的。

•  　　Swing及其佈署模式

　　我無需對Swing的內部架構以及類和界面的設計、設計模板的實現方面有多少新思想多做敘述了。Swing幾乎是我見過的最完全的窗體系統，它的容器、組件和UI元素之間的關係很是清晰。Swing的架構是基於Model-View-Controller（MVC）設計模板的，其數據與數據的表達和處理相互獨立。

　　大多數的Swing模型都是由各類UI元素共享的。例如，JTable使用和JList、JTree相同的模型集，這就使得學習和使用Swing很是簡單,並且Command、Observable和Listener等模板提供了很好的靈活性和良好的面向對象特性。也許Swing架構中惟一的不足之處是全部的事件都被交付到相同的EventDispatch線程中，使整個GUI客戶端應用程序只有一個線程。但咱們能夠經過使用不一樣的線程響應用戶的命令而不經過EventDispatch線程來完成全部操做，就能夠很簡單地克服Swing這一缺點。

　　Sun發佈的每一個JDK版本都對Java和Swing的性能都進行了改進。JDK 1.3中與Swing相關的改進表如今性能、內存消耗和一個輸入確認框架。性能和內存消耗方面的改進至關可觀。咱們公司將客戶端的應用程序由JDK 1.2.2升級到1.3後，內存消耗下降了30%，一些應用程序內存佔用減小得更多。因爲Swing內部的初始化過程被優化了，咱們的客戶端應用程序的運行速度和響應速度都更快了。簡而言之，對速度影響最大的是加載其餘界面組件時自動產生的大量的類，而這一方案中只包含有一個類。另外一個重大的變化是缺省的JVM是HotSpot Client VM，它專門針對GUI繪製和客戶端應用程序執行進行了優化，能夠經過在命令行方式下運行java命令獲得缺省的JVM。
　　
　　輸入確認框可使咱們很方便地經過編程實現命令字段或輸入確認。在這之前，若是要在處理下一個字段以前，對前一個用戶輸入進行處理，必須在該部件上添加一個監聽程序，每當該部件再也不是焦點後都須要對它進行確認，這種方式很是單調和乏味。使用新的InputVerifier類，能夠經過建立InputVerifier子類的一個實例，並將它賦予須要確認的JComponent，就能達到相同的目的。在焦點轉換以前，部件將自動地調用verify()方法。

Swing存在的問題在於佈署時的速度和兼容性問題。如今，它的一個重大改進解決了這些問題並使Java客戶端應用程序從新成爲一個可行的選擇，CPU的速度在過去2年中翻了一番。在JDK 1.3中，基於Swing的應用程序的運行速度已經很是快了，所須要的內存也至關少。這就使咱們在佈署Swing方面還存在着最後一個問題，那就是如何進行佈署，在這裏，咱們有三種解決方案可供選擇。

　　方案一：Java插件

　　基於瀏覽器的Java中最精彩的特性之一是Java插件。對HTML網頁做簡單的修改就可以消除對瀏覽器JVM的依賴，並使咱們能夠在Sun的標準JVM中運行Applet。一旦安裝了JRE，Applet就被下載到本地磁盤上，並被放置在高速緩衝區中，再打開帶Applet的HTML網頁的速度就會快許多，緣由是全部的東西都是在本地磁盤上的。爲說明其工做原理，咱們首先來看看原來的Applet佈署方式，HTML網頁是如何使用插件的，咱們假設你已經掌握了HTML和Java Applet的有關知識，並建立了以下的網頁：

[TABLE][TR][TD][B]＜HTML＞
＜HEAD＞
＜TITLE＞My traditional applet page＜/TITLE＞
＜/HEAD＞
＜BODY＞
＜APPLET CODE=HelloWorld.class ARCHIVE=HelloWorld.jar＞
Sorry, looks like I bumped into another browser that doesn't support Java applets
＜/APPLET＞
＜/BODY＞ 

[/B][/TD][/TR][/TABLE]

　　這種方式的缺點是它依賴瀏覽器JVM來加載和執行HelloWorld類。考慮到市場上存在有多種瀏覽器，它們執行Java的方式各不相同，使得Applet的佈署成爲一件使人恐懼的事。你必須保證在通過測試的JVM中運行Applet。咱們不要求瀏覽器運行Java，而要求瀏覽器安裝和運行咱們將要在其中運行Applet的JVM。在IE中，咱們能夠經過使用＜OBJECT＞標誌來完成這一任務，在其餘的瀏覽器中，這一標誌可能會有所不一樣，例如在Netscape Navigator中是＜EMBED＞。修改後的網頁以下所示：

[TABLE][TR][TD][B]＜HTML＞
＜HEAD＞
＜TITLE＞My new applet page＜/TITLE＞
＜/HEAD＞
＜BODY＞
＜OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" 
width=100% height=100
codebase="./j2re-1_3_0_02-win.exe#Version=1,3,0,2"＞
＜param name="code" value="HelloWorld.class"＞
＜param name="archive" value="HelloWorld.jar"＞
＜param name="cache_archive" value="HelloWorld.jar"＞
＜param name="cache_option" value="Plugin"＞
＜/OBJECT＞
＜/BODY＞
[/B][/TD][/TR][/TABLE]
上面的網頁將使瀏覽器檢查指定ClassID的對象是否已經安裝，若是沒有安裝，則從指定的URL下載JVM，並進行安裝。而後瀏覽器執行插件，並下載和顯示Applet。

　　插件帶來的好處是它能夠支持各類操做平臺上的全部瀏覽器，此外，它還提供了一個有保障的執行環境，插件只須要安裝一次，就能夠對全部Applet進行緩衝，使再次訪問網站時很是容易。這一方法的一個最大不足之處是，在運行Applet以前，必須下載一個大小爲5MB的插件，這在低速的互聯網鏈接上尤爲使人不能容忍。事實上，若是你的Applet只是一個大小爲5KB的網頁頂端的一個鐘錶，爲此而下載一個5MB的插件是得不償失的。


　　方案二：使用Java Web Start

　　佈署Java應用軟件的另外一種方式是Sun公司的Java Web Start，它在本質上與Java插件類似，只是在第一個步驟上有明顯的不一樣。Java Web Start要求在每臺臺式機上進行人工安裝，這一點遠不如插件的自動安裝。Java Web Start的安裝至關簡單，一旦安裝完畢，依賴Java Web Start的應用程序就能夠被下載和安裝。就象插件同樣，應用程序也是經過互聯網發行的。


　　根據個人經驗，Java插件在安裝上與Java Web Start類似，但比Java Web Start的用戶親和性更好，緣由是它要求的管理員或用戶干預更少。也有一些公司建立了本身的功能相似的佈署工具，這些工具備時候比Java Web Start還好用。例如，Sitraka公司的DeployDirector在性能上優於Java Web Start，而且安裝也更簡單。


　　總而言之，經過使用Java插件和Java Web Start，基於Swing的應用程序的佈署比原來要簡單和安全許多，但仍然比點擊一個只有JavaScript的HTML網頁要複雜得多。並且有些用戶可能對在本地機器上安裝JVM所須要完成的步驟有被脅迫的感受，或者沒有發現Swing所帶來的好處，但若是須要一個動態GUI用戶界面，使用戶享有更多地靈活性，沒有一種方法比採用Swing Applet更好了。


　　此外，若是整個開發都是基於Java的，在HTML請求數據和應用程序內部結構之間就無需進行映射。RMI能夠提供快速的雙向網絡調用，它能夠回叫客戶端應用程序，提醒用戶根據服務器的要求更新顯示內容。


　　方案3、以純HTML方式佈署Java Swing

　　儘管HTML和Swing在開發客戶端應用軟件方面各有利弊，但很明顯的是，理想的解決方案應該是兩者都支持。然而，因爲這二種技術在本質上具備較大的區別，在一個應用程序中只能採用兩者之一。儘管大多數用戶都會喜歡基於Swing的快速交互客戶端應用程序，但下載並在客戶端系統上安裝JRE並不是老是一個很好的選擇。有時候，安全和防火牆方面的限制使得RMI很難在網絡上運行。在這種狀況下，咱們須要的是一種能夠在全部系統上運行的交互式客戶端應用程序，即便咱們可以使用的客戶端應用程序只有瀏覽器。CreamTec公司的WebCream能夠充當Swing-HTML之間的橋樑。

　　WebCream是一種Java工具，它能夠爲基於GUI的Java應用程序和Applet提供自動的互聯網訪問，可使咱們利用AWT和Swing實現GUI前端應用程序，同時，能夠自動地使HTML訪問該應用程序。在必定程度上，能夠把WebCream看做是動態的Java-to-HTML轉換工具，它能夠即時地把Java中的框架和對話轉換爲HTML。而後，將Webpage行爲模仿爲GUI事件，以保持應用程序原有的邏輯。WebCream不要求對現有的表格和業務邏輯進行修改，也無需學習任何新的API，它旨在發行現有的應用程序和applets。WebCream只是設置互聯網服務器和描述應用程序屬性文件的工具，它的標準版具備所有的功能，並且是免費的。WebCream還無需在客戶端的機器上進行安裝，甚至無需瀏覽器支持Java，由於瀏覽器接收到的所有都是HTML代碼。


　　據所我知，只有WebCream才具備這樣的功能，沒有其餘的工具能夠提供類似的解決方案。但也有一些產品採用不一樣的方法使本來不是爲互聯網設計的應用程序具備互聯網訪問功能。Windows 2000中有一種內置的終端服務器（Terminal Server）服務，可使用戶只要在本地系統登陸就能夠經過遠程方式訪問服務器。象Citrix系統公司的MetaFrame那樣，終端服務器向遠程終端發送一個視頻流，併爲在服務器上運行的應用程序模仿用戶的行爲。它在高速網絡上能夠很好地運行，在低速網絡上的表現則不盡人意。它在Java應用程序方面還有問題，由於它們不使用本機的繪製和滾動例程。終端服務器的可伸縮性還不太強，緣由是每一個用戶都在運行它的一個拷貝。由WebCream轉換過的應用程序在形式上與在本地系統上運行的應用程序有所不一樣，但它的性能更好，由於只有用戶在提交一個頁面時，纔會與服務器進行鏈接。全部由具備WebCream功能的應用程序服務的用戶能夠共享一個JVM，所以也能夠大大下降資源的消耗。

　　Swing-HTML轉換方式並不適合全部的用戶，WebCream在必定程度上容許經過HTML訪問前端應用而提升基於Swing的前端應用程序的價值。有95%的應用程序能夠無縫地轉換成HTML，另有5%的程序則須要改變數據的表達和處理方式。

• 基於XML/XSLT的客戶端應用程序

      在這裏，咱們假定你已經對XML有了基本的理解，我將重點討論其前端應用程序的開發。與XML相關的用戶界面開發的一個主要特徵是內容和表達方法之間互不干涉。簡單地說，就是數據被保存爲XML文檔，而再也不負責數據的使用和顯示，根據決定數據格式和在網頁上輸出方式的樣式表（XSLT）在HTML、WML、XHTML和其餘表達形式中選擇一種數據表達形式。經過使各層之間保持相對的獨立，讓每一個層處理各自的任務，這種方法的優勢是很是明顯的。


　　儘管XML提供了很好的數據發佈模式，能夠生成不一樣的表達模式，它仍然不能解決全部的問題。XML值得稱道的是讓開發人員專一於數據的處理，而讓設計人員和藝術家來處理數據的表達形式。應用程序則把生成的XML文件保存在內存或存儲在磁盤上，爲獲得指定的表達類型，例如HTML，能夠經過適當的XSLT類型表對內容進行轉換，該類型表能夠將XML文檔轉換爲HTML文檔。類型表與判斷文檔中的內容應當如何分佈在網頁上的模板相似。它還能夠轉換數據，執行傳統的命令和循環來處理數據，進行決策，所以它也可能變得很是複雜。


　　類型表的優勢之一是，若是要從一部移動電話上訪問同一個應用程序，所須要做的所有工做就是再建立一個新的WML類型表。從理論上說，這個應用程序的全部其餘部分都無需做任何改變，這使得服務器端的編程工做變得很是高效。採用XML實現一個前端應用程序將使一些任務變得簡單，由於顯示的數據和處理這些數據的代碼都無需改變。開發應用程序各部分的開發小組能夠獨立工做，從而加快開發進程。


　　然而，我曾經在基於XML的前端應用程序開發中吃過苦頭，它的二個最主要的缺點是缺少幫助生成XML以及類型表開發方面的工具和處理速度，第一個因素對那些使用DreamWeaver和FrontPage等可視化HTML開發工具建立HTML網頁的開發人員的影響更大。就我本人而言，我仍是喜歡使用DreamWeaver，但我實在不能從在文本編輯器中編寫HTML代碼中獲得什麼樂趣。畢竟，如今已是21世紀了，咱們來看一個將XML文檔轉換爲HTML的很是簡單的XSLT類型表：


＜?xml version="1.0"?＞
＜xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"＞


＜xsl:template match="page"＞
＜html＞


＜head＞
＜title＞＜xsl:value-of select="title"/＞＜/title＞
＜/head＞


＜body＞
＜xsl:apply-templates/＞
＜/body＞
＜/html＞
＜/xsl:template＞


＜xsl:template match="title"＞
＜h1＞＜xsl:apply-templates/＞＜/h1＞
＜/xsl:template＞


＜/xsl:stylesheet＞


　　若是所選的XSL類型表適當的話，上面的代碼會生成以下所示的HTML代碼：


＜html＞
＜head＞
＜title＞My first page＜/title＞
＜/head＞


＜body＞
＜h1＞Hello, world＜/h1＞
＜/body＞
＜/html＞
 
　　咱們會發現，上面的代碼與咱們用HTML開發工具獲得的代碼不大相同。不幸地是，咱們必須用手工的方式對它進行編輯，在一個能夠生成HTML文檔的工具中對它進行處理後，而後在瀏覽器中打開生成的文檔。若是僅僅是爲了美觀而改變字體的大小，那麼就無需這麼做了。


　　第二個問題是在運行時完成全部的任務須要許多時間。若是數據格式不是XML，還須要生成XML文檔，在類型表對XML進行轉換處理後，才能生成HTML代碼。與在Servlet或JSP應用程序中向內存緩存中寫文件相比，速度和簡潔性實在不是基於XML的前端應用程序的優勢。


　　總而言之，若是須要動態地生成不一樣版面和窗體的表達形式時，就須要使用XML。若是表達形式須要常常變化或須要很是靈活，就應該讓設計人員從新設計新的類型表。須要記信的是，設計人員只要掌握XML和XSLT就萬事大吉了。


　　另外一個須要使用基於XML的UI的場合是你須要處理的資料是XML文檔，而不是Java對象或關係數據庫。XML是一種在將來很有前途的新技術，然而，目前使用JSP開發前端應用不是比較方便的，尤爲是HTML是惟一一種前端開發工具時更是如此。使用JavaBeans和JSP標識庫等一些著名的設計模式則可以使數據的內容和表達形式很好的分離。隨着自動對XML/XSLT進行編輯的工具的出現，這些技術在使用方面將更加簡單方便。

• 　　結論

　　具體到你本身的Java應用程序，這三種前端技術各有利弊，任何一種技術都不能在全部方面超過其餘二種。針對具體的應用程序，咱們必須對需求、用戶的指望進行詳細分析，對這三種技術進行評估。下面是一些基本的準則： 　　使用HTML/JSP： 　　　━━適合於由大量圖形和美術做品組成的靜態內容。 　　　━━前端應用程序的界面面向使用全部平臺的用戶。 　　　━━用戶所使用的互聯網鏈接較慢。 　　　━━但願快速地構建功能比較單一的應用程序。 　　使用Java Swing： 　　　━━適合建立具備內置、與界面相關的邏輯的GUI。 　　　━━能夠減輕網絡流量，提供儘量的即時響應。 　　　━━若是用戶對界面的質量和功能有較高的指望。 　　　━━若是UI的功能比其美感更重要時。  　　使用XML/XSLT 　　　━━須要支持許多不一樣的並且常常變化的窗體。 　　　━━數據是XML格式。  　　　━━須要個性化。  　　　━━計劃提供無線訪問等不一樣的訪問方式。