在過去的幾年中，Java 平台技術取得了一些驚人進展。但這項技術在某些方面的廣泛應用和它最初的設計目標完全不同。Java 平台技術最初是希望通過客戶端運行 Applet 和 application，來給網頁增加交互性。而現在該技術最常見的用途卻是基於服務器的 J2EE 系統。為了讓 Java 平台在客戶端發揮它的最大潛力，人們開發了許多新技術。由於企業系統逐漸被互聯網應用程序所取代，掌握這些新技術也就非常必要。在這篇文章中，你可以看到如何利用新舊技術來達到此目的。
Applet 遇到什麼問題？
當 Java 平台首次發布的時候，就預示著一種新方法，能夠將互聯網從靜態的簡單網頁集合，提升到具有交互性的高級層次。Java 創始者的最初目的是為開發者們提供一些方法，創建可以在任何客戶端機器上運行的小程序。這些程序還能夠將客戶端進程與服務端數據相結合，給客戶提供高度的交互體驗。
然而在某些地方，Java 為客戶端所承諾的許多特性得不到實現。導致這個不幸的可能原因包括以下幾種：
公司防火牆通常阻止 Java Applet 的通過。
許多客戶端沒有提供完全兼容的 Java 虛擬機。
安全設置不允許使用 Applet 來執行很多有用的規則。
浏覽頁面時，下載一個完整用戶界面所需的開銷，常常令許多用戶對 Java Applet 望而卻步。
必須為不同系統以及不同的平台，重新實現許多用戶界面函數（打印，文件管理和其他一些類似任務）。這也是許多開發人員避免使用 Java Applet 的原因。
隨著互聯網上電子商務的成長，終端用戶的處理能力有所增加，對通訊帶寬的需求更是迅猛增長。在客戶端組件中使用 Java 技術再度成為一件很有誘惑力的事情。然而，我們需要研究一種新方法，既能夠利用客戶端的程序，又不必遇到類似於使用 Java Applet 制作 ad-ware 和滾動新聞欄時所面臨的障礙。通過新舊技術的結合使用，甚至融合某些幾乎被快速奔跑的“互聯網時代”所淡忘的舊技術，就能夠減輕這些問題。
人們為什麼稱之為JavaScript
在客戶端使用 Java 技術時，最為忽略的一點便是 Java Applet 和 Javascript 之間的結合。JavaScript 標准早就為腳本提供了調用 Applet 類的方法，而 Applet 也能夠調用腳本的函數。這種結合讓我們能夠發揮這兩種技術的最大長處。我們開發並保持所需要的功能性，而將用戶界面的設計交給網頁開發人員來處理。此外，利用這種結合，還能夠增加用戶與服務器的交互程度卻留下很少客戶端參與的痕跡。
Javascript 標准中的 LiveConnect 技術（參看資料部分），允許在網頁中使用腳本來調用 Applet 方法。只要簡單地創建所需要的 Java 類，並允許 JavaScript 腳本的開發者訪問這個類中的方法便可。而 com.Netscape.JSObject 類則使我們能夠訪問 JavaScript 函數和對象。這就提供了一種在 Java 代碼中調用 JavaScript 函數的方式，直接令網頁發生相當有趣和重要的變化。有了 JavaScript 和 Java Applet 之間的聯系，那些 Javascript 或 Java Applet 無法單獨執行，但結合這二種方法卻能完成的任務就能夠被解決。而且，此二者的結合通常還能夠減少網頁提交到服務器的時間，從而減少了用戶等待時間，服務器處理時間以及服務端的會話狀態維護開銷。考慮下列例子：
在用戶填表的同時，後台線程使用 Java Applet 來在服務端數據庫中尋找地址或電話號碼信息。
當 SSL 不適合使用時，利用 PKI 技術來為系統間的通訊加密。
使用 DSA 標准來對請求簽名，為消息內容和發送者提供強大的確認功能。
使用 Java Applet 向服務器數據庫提交日程改變，並在客戶端的背景上更新本地日程顯示。不需要不斷對所有日程做更新，並且最大程度地縮短這個改動生效所需的時間。
結合使用 Java Applet 和 JavaScript 代碼進行動態顯示，不斷更新浏覽器文檔中的內容；這種結合允許我們不必為每個所想象得到的客戶端平台都寫一段打印例程，也能夠將內容打印出來。
清單 1 闡述如何使用 JSObject 和 LiveConnect 來驗證一個電話號碼，同時將該號碼轉化成標准格式。注意到這只是一個例子代碼，所以我在服務器連接方法中略去若干必須的函數調用，以便簡化這個清單。這個例子是當電話號碼輸入框內容發生變化時，在 Javascript 中調用 Java Applet 函數。於是 Java Applet 就訪問服務器，獲得這個電話號碼的標准格式字符串，並將該字符串返回到隱藏框（hidden fIEld）裡。真正實現此任務的代碼，應該用後台線程來實現服務器連接和電話號碼驗證，以便讓驗證過程對用戶而言是透明的。這個例子還使用了另一項使客戶端 Java 編程更為有趣的技術：HTTP 連接以及與服務器代碼（特別是 servlet 和 JSP 網頁）的結合。
基於服務器的資源
那些必須存放在服務器上的資源會怎樣呢？這類基於服務器的資源包括地址驗證，運輸費用計算，以及信用卡驗證等。支持數據以及要求高安全度的處理必須放在服務端，但大部分的驗證處理，數據轉換以及費用計算過程可以遷移到客戶端系統上。支持這一想法的幾個 Java 語言特點包括：
Java 語言通過 HttpURLConnection 對象來為 HTTP 連接提供內在支持。同時利用 Java.Net 包的其他部分，為服務端代碼與客戶端代碼之間的通訊提供一種方法，簡單有效地生成數據或打包數據。
許多客戶端的 Java Applet 代碼實際上與那些在服務器上運行的代碼是一樣的。
現在我們可以將多種任務分配給服務器和客戶機，從而減少服務器負載，甚至可能減少網絡連接。具體如何分配這些任務將取決於系統的類型以及用戶團體，但幾乎所有的系統都會因為增加一些客戶端處理而受益，例如：
Applet 類能夠將數據從一系列格式轉化到單一的 XML 字符串格式，這使得服務器更容易處理數據。
Applet 類可以進行數據壓縮，即把那些將要上載到服務器的數據壓縮，同時將這些數據分割成較小的數據包，從而進一步提高了可靠性。
當用戶填寫結帳表單時，Applet 類能夠進行地址和運輸費用的計算（在更大的基於服務器數據庫中這類計算常常需要進行交互）。此方法能夠減少最後結算所需要的時間，同時令用戶在提交定單之前就能夠看到正確的運輸費用以及相應稅金等信息。
為了發揮這個技術的最大優勢，需要一些方法向那些返回指定數據的服務器發送請求。 Java servlet 恰好具有這種能力。許多開發者並未完全意識到 servlet 能夠將任何一種數據作為響應並返回，而不僅僅限於 Html 或是 XML。通過返回一系列連續的對象或一個壓縮的數據包，servlet 能夠執行例如地址確認或運輸費用和稅金計算等任務。同時，進行這些計算的客戶端代碼可以通過後台線程的運行來掩蓋用戶等待時間。清單 2 中顯示了一個servlet，該 servlet 接收 HTTP 的帶有 Zip 代碼的 GET 請求，並返回運輸費用的計算結果。同樣出於令清單清晰明了的目的，在這裡省略了若干非常重要的實際代碼。
注意到我使用 ObjectOutputStream 對象來將整個目標圖表寫入待返回的響應中。content 類型需要設置成某些合適的值，同時將 content 處理句柄分配到客戶端。這種方法能夠返回一個 Java 對象，裡面包含顧客運輸、處理費用以及應繳稅金的計算結果。如果這個對象只是與客戶端後台線程進行通訊，用戶就根本不會意識到他已經和服務器進行了一輪通訊。
節約時間的新技術
上述技術都已實現若干時間了，且大多數正在全世界各種不同的系統上應用著。前面我曾經許諾過要介紹一些新技術，現在是具體闡述它們的時候了。客戶端上最有趣的 Java 新技術當屬 weblet。IBM alphaWorks 的 DirectDOM 就是該技術的一個具體實現（參看資料部分)。DirectDOM 允許從 Java 代碼中訪問整個浏覽器 DOM tree (2000年11月13日 W3C 建議為 DOM Level 2)。weblet 沒有用戶界面，必須通過操縱浏覽器中的活動 DOM 文檔來完成它的工作。許多原先需要復雜 JavaScript 代碼才能實現的技術，通過這種方法都能夠實現。必須注意到盡管 DirectDOM 是一項很有吸引力的技術，它仍處在 alpha 階段，是不完善的，並且需要 Internet Explorer 或 Mozilla (M18) 的最新版本才能夠運行。然而，此技術足以使你預測到不遠的將來將會如何令人激動。一些可能實現的例子如下：
在充滿了大量圖形和視覺刺激的結算網頁上，加入 weblet。那麼在用戶處理結算表格的多個步驟時，不需要每步都在表單與網頁間切換，也能夠與服務器通訊交換數據並完成結算。當結算完畢需要確認時，weblet 會將整個包提交到服務器，服務器就可以按照通常的結算處理步驟進行處理。
一個顯示屬性消息的網頁。weblet 通過令頁面空白來標記對應於打印或保存請求的響應，從而防止數據被不加區別地共享。
用戶可以向互聯網上的應用程序請求獲得某些報告。報告的摘要信息會馬上傳送到，而 weblet 則使用後台線程下載該報告的詳細信息。當用戶對摘要中某行條目感興趣時，只要用鼠標點擊該條目，weblet 就能夠立即響應鼠標動作，在這個條目的下方顯示詳細信息。這些具體信息是在摘要頁面下載後，才被後台線程下載的。但是用戶並不會注意到這一點。
另一個長些的例子，更清楚地展示了 weblet 如何工作。在 清單 3，發送給客戶端的 Html 頁面和 清單 4，weblet 類的 Java 代碼中，可以看到這個例子。盡管它不適合於生產環境也未完善，但依然很有用。這個例子下載一個很長的示范網頁，其中含有兩個表單和一個 weblet 標記。weblet 用一些介紹性的文本來替代這些表單，或在演示過程中切換這兩個表單。
為什麼要做這些？
為什麼我們會關注客戶端的 Java 技術發展呢？為什麼不建立那些只為網絡上計算機工作的系統，或是瘦客戶系統，而在服務器上執行絕大部分的復雜計算工作？簡單的說，是因為我們無法提供這樣的服務器服務。倘若要在單獨一個服務器空間中安裝足夠的處理程序，來支持大量客戶端所請求的巨大處理負載，開銷將是極其昂貴的，因此才開發了分布式系統模型 (n-tIEr 結構)。客戶端的 Java 技術允許我們減少大型系統中的操作開銷的同時，大幅度提高客戶端的參與——減少用戶與服務器之間通訊的回合數，提高交互層次，改善數據的確認速度。客戶端的 Java 技術還可以幫助我們實現一些服務器難以單獨完成的任務，比如基於標記 (token-based) 的數字簽名等。即便是單一的開發平台，企業版的 Java 2 也提供了強大的體系結構。可以將客戶端 Java 技術與支持 Java 2 平台的服務器相結合，不能充分利用這個優勢將非常遺憾。
