簡介： 隨著 Ajax 的興起，對于消解這個熱門技術(shù)的謎團并有針對性地處理在它的使用中出現(xiàn)的問題的需求出現(xiàn)了。高級 IT 專家 Patrick Gan 利用這個機會，研究了在 Java? EE Web 應(yīng)用程序中引入 Ajax 對整個開發(fā)生命周期可能產(chǎn)生的影響。對采納 Ajax 基于異步通信的模式會存在的問題保持清醒，有助于踏上有效集成 Ajax 的正確道路。
Asynchronous JavaScript + XML （Ajax）是個相當(dāng)新的術(shù)語（有些人說它是舊酒裝新瓶），在不同的 Web 開發(fā)社區(qū)中，都引起了很大的爭議，其中包括 Java EE 社區(qū)。Ajax 技術(shù)通過消除過多的 Web 頁面刷新，提高了應(yīng)用程序的可用性。而且 Ajax 二者通吃的技術(shù)，同時利用了客戶端和服務(wù)器端代碼，向 Web 用戶呈現(xiàn)了幾乎無縫的用戶界面。Ajax 被鼓吹成 Web 開發(fā)復(fù)興（或稱為 Web 2.0）的一個主要推動者。
作為用心的 Java EE 開發(fā)人員，您可能已經(jīng)閱讀了許多關(guān)于 Ajax 的 how-to 文章，并對它會給應(yīng)用程序帶來的可能改進而興奮。但是 Ajax 基于異步通信的模式要怎樣才適合您的 Java EE 應(yīng)用程序呢？這篇文章通過研究在 Java EE 應(yīng)用程序的設(shè)計、開發(fā)、執(zhí)行和測試各階段引入 Ajax 會帶來的影響，將幫助您回答這個問題。我的目的不是不鼓勵使用 Ajax 或者暗示您可能遇到的問題是 Ajax 技術(shù)固有的問題。相反，我是為了幫助您規(guī)劃并減輕這些問題，好讓您更有效而順利地利用 Ajax。
相當(dāng)一段時間以來，Java 社區(qū)一直在努力把好的設(shè)計模式應(yīng)用到與 Web 有關(guān)的應(yīng)用程序開發(fā)上。其中使用最廣泛的一個模式就是模型-視圖-控制器（MVC）。一些開放源碼框架，例如 Apache Struts，就基于這個設(shè)計模式/架構(gòu)（請參閱 參考資料）。MVC 的眾多優(yōu)勢包括：問題隔離 和減少冗余代碼。
問題隔離在整個應(yīng)用程序架構(gòu)中使用預(yù)先協(xié)商好的接口，從而讓應(yīng)用程序開發(fā)項目中的每個開發(fā)人員都專注于自己特定的角色。例如，模型層的開發(fā)人員側(cè)重于 JDBC、企業(yè) JavaBean（EJB）組件或者與底層數(shù)據(jù)持久技術(shù)接口的 Java 類這一類的技術(shù)。視圖層開發(fā)人員側(cè)重于 Java 服務(wù)器頁面（JSP）技術(shù)、標(biāo)記庫和其他與表示有關(guān)的技術(shù)。控制器層隔離及協(xié)調(diào)模型和視圖，把進入的請求路由到后端持久性調(diào)用，同時維護問題的清晰隔離。圖 1 演示了 MVC 架構(gòu)：
把 Ajax 引入 Java EE Web 應(yīng)用程序?qū)τ趩栴}的隔離（以及開發(fā)人員角色的隔離）是有意義的。在某些情況下，Ajax 會把大量 JavaScript 代碼帶回視圖層（JSP）頁面。表 1 描述了沒有 Ajax 的視圖層，還指出了需要的代碼（假設(shè)控制器層由 servlet 實現(xiàn)，視圖層由 JSP 技術(shù)實現(xiàn)。（在下一節(jié) 處理開發(fā)困境 我將解釋同步和異步請求的區(qū)別。）
| 序列 | 說明 | 要求代碼？ |
|---|---|---|
| 在調(diào)用同步請求之前 | 準(zhǔn)備表單提交需要的腳本代碼 | 否 |
| 調(diào)用異步請求 | 由按鈕或鏈接調(diào)用引起表單提交；DOM 元素的值自動設(shè)置到 HttpRequest（通過 GET 或 POST）。 | 否：所需要的只是調(diào)用頁面提交的途徑。 |
| 處理同步請求的響應(yīng) | 在服務(wù)器端代碼執(zhí)行完成后，通常會向 JSP 發(fā)送回一個對象（通過 HttpRequest 或保存在 HttpSession 中）。這時，在 JSP 中可以通過 HttpRequest 或 HttpSession 訪問這個對象（通過腳本或某些標(biāo)記庫），只需要編寫極少的腳本就可以顯示對象的內(nèi)容。 | 是：最少的腳本。 |
對比表 1 和表 2，表 2 描述了有 Ajax 的 MVC 視圖層，同樣假設(shè)控制層由 servlet 實現(xiàn)，視圖層由 JSP 技術(shù)實現(xiàn)。
| 序列 | 說明 | 需要代碼？ |
|---|---|---|
| 在調(diào)用異步請求之前 | 需要用 JavaScript 代碼檢索出 Ajax 調(diào)用需要的 DOM 元素的值。 | 是 |
| 調(diào)用異步請求 | 需要用 JavaScript 代碼創(chuàng)建 XMLHTTPRequest 并把（以前搜集的）DOM 元素值與之關(guān)聯(lián)并發(fā)送（XMLHTTPRequest.send()）。 | 是 |
| 處理異步請求的響應(yīng) | 在服務(wù)器端代碼執(zhí)行完成后，要用 JavaScript 代碼得到請求（從 XML 響應(yīng)流中）并把值相應(yīng)地填充到適當(dāng)?shù)?DOM 元素。 | 是 |
可以看出，由于使用了 Ajax，視圖層的腳本編寫量增加了，從而導(dǎo)致三個明顯缺陷：
有幾個選項可以避免或者至少減輕這些設(shè)計缺陷：
在 Java Web 開發(fā)中使用 Ajax 時，重要的是完整理解同步 和異步 通信模型的區(qū)別（請參閱 參考資料）。對異步通信模型支持的缺乏，會對客戶端開發(fā)、與 Web 框架的集成、標(biāo)記庫的使用、IDE 的使用以及線程的行為有影響。
在同步請求/響應(yīng)通信模型中，總是瀏覽器（與 Web 服務(wù)器、應(yīng)用服務(wù)器或 Web 應(yīng)用程序相對）發(fā)起請求（通過 Web 用戶）。接著，Web 服務(wù)器、應(yīng)用服務(wù)器或 Web 應(yīng)用程序響應(yīng)進入的請求。在處理同步請求/響應(yīng)對期間，用戶不能繼續(xù)使用瀏覽器。
圖 2 中的序列圖演示了傳統(tǒng) Web 應(yīng)用程序的同步通信模型。請注意在服務(wù)器的生命線上，來自客戶機的數(shù)據(jù)提交和服務(wù)器端的處理是緊密耦合的。
在異步請求/響應(yīng)通信模型中，瀏覽器（通過 Web 用戶）到 Web 服務(wù)器、應(yīng)用服務(wù)器或 Web 應(yīng)用程序的通信（以及反過來）是解耦的。在異步請求/響應(yīng)對的處理中，Web 用戶在當(dāng)前異步請求被處理時還可以繼續(xù)使用瀏覽器。一旦異步請求處理完成，異步響應(yīng)就被通信（從 Web 服務(wù)器、應(yīng)用服務(wù)器或 Web 應(yīng)用程序）回客戶機頁面。典型情況下，在這個過程中，調(diào)用對 Web 用戶沒有影響；他們不需要等候響應(yīng)。
圖 3 的序列圖演示了異步通信模型。請注意第一個 dataSubmission （由服務(wù)器端處理）和第一個返回的 dataSubmission，兩個都用紅圈圈上了。這些序列是解耦的。這個圖示還強調(diào)了一個重要方面（后面將詳細介紹，請參閱 線程問題）：在這個模型中，可以發(fā)生多個提交（線程）。
在向 Web 應(yīng)用程序引入 Ajax 時，開發(fā)團隊需要注意幾個風(fēng)險，主要與生成的 HTML 頁面及其與瀏覽器的交互方式有關(guān)。這些問題在 Chris Laffra 兩部分的 Considering Ajax 系列中有詳細介紹（請參閱 參考資料）。有些需要記住的要點是：
試著把 Ajax 開發(fā)與所選的 Java EE Web 框架集成，是很自然的。但是有些 Java EE Web 框架對異步通信模型提供直接可以使用的支持。要體會這個事實的意義，需要理解 servlet 處理同步和異步通信的方式。圖 4 顯示了處理同步請求的傳統(tǒng) servlet 序列：
圖 4 對于 Java EE Web 開發(fā)人員來說應(yīng)當(dāng)相當(dāng)熟悉。來自瀏覽器的請求先由控制器 servlet 的 service() 處理。servlet 可以從 HttpRequest 檢索到需要的任何值（以參數(shù)的形式或者以屬性的形式）。一旦控制器處理完成，結(jié)果就發(fā)送回 HttpRequest （或 HttpSession），而 RequestDispatcher 則把控制轉(zhuǎn)發(fā)（或包含）回頁面。
圖 5 顯示了處理異步請求的 servlet 序列：
圖 5 中的序列與同步序列略有不同。來自瀏覽器的請求先由控制器 servlet 的 service() 處理。servlet 可以從 HttpRequest 檢索到需要的任何值（以參數(shù)的形式或者以屬性的形式）。一旦控制器處理完成，HttpServletResponse 的內(nèi)容類型必須設(shè)置成 XML。而且，控制器邏輯的結(jié)果要用 PrintWriter 寫入。這時，RequestDispatcher 的使用被越過。
這個（異步序列）恰恰是多數(shù) Java EE Web 框架不支持的，從而造成與 Ajax 的集成非常困難。不支持異步通信模型的 Portlet 和 JavaServer Faces （JSF）框架面臨著同樣的問題。
克服這個問題也有一些選項：
大量使用標(biāo)記庫（taglib）在 Java 的 Web 應(yīng)用程序開發(fā)中是很普遍的。像許多 Java EE Web 框架一樣，有些標(biāo)記庫現(xiàn)在也不支持異步通信模型，沒有把通過 XMLHttpRequest 提交的數(shù)據(jù)轉(zhuǎn)換成 HttpServletRequest （以及反過來）的途徑。實際上，不支持異步通信的標(biāo)記庫，在 Ajax XMLHttpRequest 調(diào)用期間不工作?？捎玫倪x項有：
ExecutionContext.forwardToString()）。 在這種情況下，可以繼續(xù)使用以前一直使用的標(biāo)記庫。有許多 JavaScript 調(diào)試工具可以幫助開發(fā)人員開發(fā) JavaScript 解決方案。但是，傳統(tǒng)的 Java 開發(fā)環(huán)境不允許檢查 XMLHTTPRequest 和與 Ajax 相關(guān)的其他東西的值。
一個解決方案是利用 AJAX Toolkit Framework（ATF）（請參閱 參考資料）。ATF 是個 Eclipse 插件，帶有增強的 JavaScript 編輯特性，例如編輯時語法檢查，內(nèi)嵌的 Mozilla Web 瀏覽器，內(nèi)嵌的 DOM 瀏覽器，內(nèi)嵌的 JavaScript 調(diào)試器。ATF 還包含 Personality Builder 功能，這個功能可以幫助任何 Ajax 運行時框架構(gòu)建 IDE 特性，從而加入到 ATF 支持的運行時環(huán)境集中。
在典型的同步 Web 應(yīng)用程序中，有些領(lǐng)域?qū)Π粹o或鏈接點擊要求更長一點的處理時間。沒有耐心和沒經(jīng)驗的 Web 用戶通常會不止一次地點擊按鈕或鏈接，以為可以幫助加快處理速度，從而引發(fā)多重表單提交。其他時候，用戶認為需要雙擊（就像桌面應(yīng)用程序那樣）。Web 應(yīng)用程序中的多重表單提交在某些情況下是無害的。而在其他情況下，副作用可能造成嚴(yán)重的線程問題或爭用情況（此時多個線程競爭執(zhí)行一個代碼塊）。例如，在銀行應(yīng)用程序中多次點擊轉(zhuǎn)帳按鈕，可能造成不希望的多次轉(zhuǎn)帳。
既支持同步通信模型又支持異步通信模型的 Web 應(yīng)用程序會發(fā)現(xiàn)，如果它的功能沒有正確分析和規(guī)劃，那么自己就處在了相似的困境中。支持兩種通信模型的應(yīng)用程序在某個頁面上可能混合了服務(wù)器端調(diào)用（即，或者同步，或者異步，或者混合了同步和異步）。就像在多重點擊場景中一樣，異步調(diào)用可能處理得慢些。如果應(yīng)用程序不做預(yù)防，用戶可能會在異步線程正在處理時又調(diào)用了一個同步調(diào)用，因為頁面沒有刷新，所以無法阻止頁面上的進一步活動。結(jié)果是兩個線程并發(fā)處理。雖然不是由 Web 頁面上的同一按鈕或鏈接引發(fā)，這類情況還是會造成服務(wù)器端的線程問題（與多重點擊問題類似）。
例如，以圖 6 所示的銀行應(yīng)用程序的轉(zhuǎn)賬頁面為例：
對于這個示例，用紅色表示的轉(zhuǎn)賬按鈕引發(fā)一個 Ajax 調(diào)用。退出鏈接（黃色）引發(fā)同步調(diào)用。如果不耐煩或沒有經(jīng)驗的用戶點擊了紅色按鈕之后接著又點擊黃色鏈接（假設(shè)兩個鏈接在代碼中有共同的路徑），就會發(fā)生爭用情況。
一般來說，有兩種方式可以避免這類情況發(fā)生。第一種方式是客戶端解決方案。一旦點擊了一個鏈接或按鈕，就用 JavaScript 確保禁止后續(xù)的頁面提交，直到當(dāng)前線程執(zhí)行完成。第二個解決方案是允許多線程提交，但是依賴于服務(wù)器端代碼中的同步來避免爭用情況。如果引入同步來解決這個問題，請記住 Java EE Web 組件（servlet、portlet、JSF 等）是多線程的。要當(dāng)心大段代碼的同步（特別是與請求/響應(yīng)生命周期處理有關(guān)的代碼）。在效果上，同步的誤用，會把應(yīng)用程序變成單線程應(yīng)用程序，從而降低吞吐率。
使用 Ajax 還有可能影響基于 Java EE Web 的應(yīng)用程序的性能。允許每個請求上有額外線程的可能性，可能會影響兩個資源。
首先，servlet 容器的線程池 可能受到影響。線程池指定 Web 容器中允許并發(fā)運行的線程的最大數(shù)量。每個客戶機請求需要一個線程。但是，一個客戶機請求不一定等于一個用戶請求。瀏覽器可能為一個用戶請求要求多個客戶機請求。例如，提交表單的一個用戶可能要求多個客戶機請求（其中包含提交表單的值、檢索 GIF 文件、檢索 JavaScript 文件、檢索 CSS 文件）。如果允許并發(fā)地提交同步和異步請求，就意味著每個用戶請求至少要支持多出一個的線程消耗（用于 Ajax 請求）。雖然為每個用戶請求多增加一個線程的可能性看起來不多，但是當(dāng)應(yīng)用程序處在負載之下時，影響就明顯了（這時每個用戶請求多出的一個額外線程乘上平均用戶數(shù)量）。顯示，這種情況有可能影響 servlet 容器的性能。
另一個可能受影響的資源是數(shù)據(jù)庫連接池。典型的 Java EE Web 應(yīng)用程序支持一個用戶請求的兩類序列：淺（shallow）請求和 深（deep）請求。淺請求是執(zhí)行服務(wù)器端代碼但是不訪問持久性存儲（例如數(shù)據(jù)庫）就完成請求的 Web 頁面發(fā)出的請求。深請求是執(zhí)行服務(wù)器端代碼并訪問持久性存儲才能完成請求的 Web 頁面發(fā)出的請求。
在深請求序列中（假設(shè)需要數(shù)據(jù)庫連接），數(shù)據(jù)庫連接池的這些方面可能會由于允許多個線程而受到影響：
所以，可能需要提高連接池的平均大小或連接數(shù)量。
Java 開發(fā)人員一直在不斷地努力為 Java SE 和 Java EE 代碼提供單元測試工具。由于 Ajax 的引入造成瀏覽器內(nèi)的 JavaScript 增多，對可靠的 JavaScript 單元測試框架也提出了要求。現(xiàn)在可用的框架有 JsUnit、Selenium 和 HttpUnit（請參閱 參考資料）。
這些框架提供了為 JavaScript 函數(shù)開發(fā)單元測試的工具，可以操縱 Web 頁面上的 DOM 元素。它們允許把單元測試組織成測試套件。Selenium 的瀏覽器兼容性測試特性允許在不同的瀏覽器和操作系統(tǒng)上測試 JavaScript 函數(shù)。它利用 JavaScript 和 Iframe 在瀏覽器中嵌入了測試自動引擎。這項技術(shù)應(yīng)當(dāng)可以在任何支持 JavaScript 的瀏覽器中工作，對于支持多個瀏覽器和瀏覽器版本的應(yīng)用程序來說特別有用。Selenium 和 JsUnit 都支持持續(xù)集成：可以把 JavaScript 單元測試和測試套件集成到自動構(gòu)建過程。
把 Ajax —— 就像其他技術(shù)或模式一樣 —— 引入 Java EE 應(yīng)用程序，也有它的優(yōu)勢和不足。本文提供了把 Ajax 集成到 Java EE Web 應(yīng)用程序的概述。Ajax 的異步通信模型與傳統(tǒng) Java EE Web 應(yīng)用程序內(nèi)置就支持的同步模型有很大不同。為了避免盲目，請確保在采用 Ajax 之前對潛在的問題領(lǐng)域有全面的事前規(guī)劃。
Java EE 框架對 Ajax 的支持和工具在不斷改進。未來有望會有框架自帶的 Ajax 支持來降低集成的復(fù)雜性。基于 JSF 的 Apache Shale 和基于 servlet 的 DWR 是兩個希望您保持關(guān)注的框架。
學(xué)習(xí)
獲得產(chǎn)品和技術(shù)
討論
