Java客戶端工具選擇：HTML？Swing？XML？
阿新 • • 發佈：2019-02-05
整理下面的文章是因為個人覺得寫的很好，關於java的客戶端了解也並不是太多。看了下面的文章覺得很有必要貼出來，方便自己以後瞭解java客戶端程式設計。
Java軟體設計師和管理人員經常會面臨這樣的難題：在開發應用軟體的客戶端時，應該在Swing、HTML、XML三種技術中選擇誰。在這篇文章中，我將把自己在這三種技術方面的經驗與廣大讀者共享，並對在Java應用軟體開發中選擇哪一種技術提出一些標準和技巧。在文章的最後，還會介紹一種整合Java Swing和HTML的新方法。
與現有的技術相比，Java有明顯的優點，因此它已經在伺服器端應用軟體的開發中確立了主導地位。然而，由於每一個應用程式都有幾種形式的使用者介面和前端的表達形式，我們中的許多人都對在客戶端採用Java技術有不好的印象，因此在客戶端的開發中採用HTML似乎已經成為唯一的選擇了。比如說我，在java客戶端這塊，我基本是在玩HTML。
- JSP/Servlets環境下的HTML客戶端
由於HTTP/HTTPS協議非常簡單，可以使開發的應用程式很好地適應各種網路配置和防火墻。但這是有代價的，HTML缺乏與使用者的互動性，而且對使用者每個行為的響應都需要與伺服器進行連線。作為一名程式設計人員，我們一直在追求簡單性，並使開發的軟體可以適合所有的瀏覽器？然而簡單性並不總是好的，簡單地說，與靜態HTML相比，JavaScript可以較好地實現不太複雜的互動性，但對於開發複雜的使用者介面而言，它還是不能勝任的。
除非擁有高速的網際網路連線，否則你一定有過焦急的等待載入一個網頁的經歷。儘管瘦客戶端提供了一些很好的非互動性的使用者介面，但傳統的胖客戶終端一般情況下都比它們更聰明。例如，Netscape Communicator和MS Outlook等電子郵件的前端就比基於網際網路的電子郵件工具具有更好的使用者親和性。
用Java開發一個HTML前端應用是一個很好的選擇，因為HTML提供了跨平臺的內容傳輸能力。程式設計人員可以使用Java Servlets和JSP開發在任何作業系統平臺上執行的伺服器端應用程式。同時考慮到眾多的Java API和它得到的廣泛的伺服器開發商的支援，對於開發可伸縮網際網路站而言，Java是一種理想的選擇。
總而言之，配合使用Servlets和JSP的HTML前端開發工具是開發靜態介面的很好的方式，但當需要對使用者的行為作出快速反應和需要對資料進行高速處理的複雜應用時，這種方式則不大理想。
- 基於Swing的GUI客戶端
AT&T的一個業務部門Telecorp PCS曾經開發過一個應用程式，使其商店可以收集希望購買行動電話的使用者的資料，檢查其信用卡，然後立即開通行動電話，除了確認使用者輸入的資訊外，應用還必須通過使用排序、選擇和其他的標準資料庫功能處理提交的報告。此外，當一個新的行動電話開通後，這個應用程式還需要顯示一個通知。
你能相像用HTML來完成這一切嗎？也許可能，但它將非常討厭，而且速度很慢，需要不間斷地使用網路連線。Telecorp PCS決定冒險在互動的Applet中使用Java，那麼結果如何呢？完全成功，這一應用程式在開發時採用了Swing，並佈署在採用了Java外掛的網際網路網站上。通過使用Swing UI類，很簡單地完成了應用所要求的功能。
我相信許多開發人員在早期使用Java時，都使用過applet，並且在解決各種瀏覽器之間的不相容性、applet下載時間、效能方面花費過大量的時間。對客戶端Java最大的批評來自其物件性，但現在情況已經有了很大的改觀。Sun已經花費了大量的時間來改進其程式碼的質量，下面我將向你說明為什麼基於Swing的UI是值得一試的。
- Swing及其佈署模式
大多數的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可以提供快速的雙向網路呼叫，它可以回叫客戶端應用程式，提醒使用者根據伺服器的要求更新顯示內容。
方案三、以純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檔案儲存在記憶體或儲存在磁碟上，為得到指定的表達型別，例如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進行編輯的工具的出現，這些技術在使用方面將更加簡單方便。
- 結論
使用HTML/JSP：
━━適合於由大量圖形和美術作品組成的靜態內容。
━━前端應用程式的介面面向使用所有平臺的使用者。
━━使用者所使用的網際網路連線較慢。
━━希望快速地構建功能比較單一的應用程式。
使用Java Swing：
━━適合建立具有內建、與介面相關的邏輯的GUI。
━━可以減輕網路流量，提供儘可能的即時響應。
━━如果使用者對介面的質量和功能有較高的期望。
━━如果UI的功能比其美感更重要時。
使用XML/XSLT
━━需要支援許多不同的而且經常變化的窗體。
━━資料是XML格式。
━━需要個性化。
━━計劃提供無線訪問等不同的訪問方式。