在短短 15 年中，World Wide Web 已經(jīng)從一項研究實(shí)驗成長(cháng)為現代社會(huì )的技術(shù)支柱。最初發(fā)明 Web 的目的是使人們可以輕松發(fā)布和鏈接信息，現在它已經(jīng)發(fā)展為軟件應用程序的可行平臺。但隨著(zhù)應用程序通過(guò)使用富應用程序模型和生成個(gè)性化內容而獲得了更多的融入性，它們的架構對 Web 架構風(fēng)格 REST（Representational State Transfer）的違背也越來(lái)越多。這種違背會(huì )降低應用程序的可伸縮性，增加系統復雜性。
新興的 Ajax Web 客戶(hù)機架構風(fēng)格讓融入式 Web 應用程序與 REST 架構風(fēng)格協(xié)調一致。使它們可以盡享 REST 那些出色的特性，同時(shí)又消除了應用程序違背 REST 準則時(shí)帶來(lái)的不良特性。本文將介紹為融入式 Web 應用程序成功結合 Ajax 和 REST 的方法與原因。
 |
|
盡管 World Wide Web 是在數十年的相關(guān)研究基礎上建立起來(lái)的，但它的有效誕生日期是 1990 年 12 月，當時(shí) Tim Berners-Lee 完成了 Web 主要組件的工作原型：統一資源標識符（URI）、HTTP、HTML、瀏覽器和服務(wù)器。Web 被迅猛采用，遠遠超過(guò)了先驅者們的預期。在 Roy Fielding 最出名的系列文章中（請參看 參考資料），他描述了自己當時(shí)的心情：
“盡管對其成功感到興奮不已，但是 Internet 開(kāi)發(fā)者社區逐漸開(kāi)始擔心，Web 使用的這種快速增長(cháng)，以及早期 HTTP 的一些拙劣的網(wǎng)絡(luò )特性，會(huì )快速壓倒 Internet 基礎設施所能承擔的容量，從而導致突然的崩塌。”
|
|
Fielding 和其他人對 Web 架構及其是否能夠足以支持各種擴展和用法重新進(jìn)行了審視。這種重新審視的有形結果包括更新諸如 URI 和 HTTP 之類(lèi)的一些重要標準。這種重新審視還獲得了一些無(wú)形但卻非常有意義的結果：為超級媒體應用程序確定了一種新的架構風(fēng)格，Fielding 將其命名為 REST（Representational State Transfer）。Fielding 斷言，使用且符合 REST 設計約束的 Web 上部署的組件可以充分利用 Web 的有用特性。他還警告說(shuō)，違背 REST 準則的 Web 組件都將無(wú)法利用這些優(yōu)點(diǎn)。
早期時(shí)，大部分 Web 站點(diǎn)和簡(jiǎn)單的 Web 應用程序實(shí)際上都是遵守 REST 準則的。但是隨著(zhù)融入式 Web 應用程序的日益普及，Web 應用程序架構逐漸開(kāi)始背離 REST 準則了，此后因果循環(huán)，情況日益惡化。融入式服務(wù)器端 Web 架構的問(wèn)題很難分析清楚，因為在使用這種架構風(fēng)格的十年中，已經(jīng)建立起這樣一種信仰：這些問(wèn)題都是 Web 應用程序架構所固有的。實(shí)際上，這并非是 Web 應用程序架構的問(wèn)題。而是由服務(wù)器端 Web 應用程序架構風(fēng)格所產(chǎn)生的問(wèn)題。要打破這種偏見(jiàn)，我們來(lái)回顧一下整個(gè)架構是如何發(fā)展到現在這種狀態(tài)的，這會(huì )很有幫助。我們將說(shuō)明為什么在 Ajax 應用程序創(chuàng )建在商業(yè)上可行之后，過(guò)去接受的很多假設現在都不再成立了。
 |
|
Berners-Lee 創(chuàng )造了 Web，最初是將 Web 作為研究人員遠程共享文檔和在文檔之間創(chuàng )建簡(jiǎn)單鏈接以加速知識和思想傳播的一種手段。然而，URI 標準的架構特征很快實(shí)現了除靜態(tài)文件之外更多內容的共享。
Web 上最早的內容由一些靜態(tài) HTML 文檔組成，其中有很多到其他靜態(tài)文檔的鏈接，如圖 1 所示：
REST 使靜態(tài)文檔的檢索極其高效、可伸縮，這是因為它們可以根據 URI 和最后修改日期來(lái)輕松緩存。很快開(kāi)發(fā)人員就超越了靜態(tài)文檔的領(lǐng)域，開(kāi)始動(dòng)態(tài)文檔的提供。
Berners-Lee 和其他人設計了 URI 標準，為資源的統一唯一標識提供支持，同時(shí)使其表示（HTML、文本等）根據 Web 客戶(hù)機（通常是 Web 瀏覽器）和 Web 服務(wù)器之間的協(xié)商結果而變化。由于 URI 將資源標識和資源的底層存儲機制區分開(kāi)來(lái)，因此 Web 開(kāi)發(fā)人員可以創(chuàng )建一些程序，使之檢查 URI 語(yǔ)法，并動(dòng)態(tài)生成文檔，將預先定義的 UI 元素和動(dòng)態(tài)檢索的數據（通常是從關(guān)系數據庫中）合并在一起，如圖 2 所示。盡管這些文檔是生成的，但是它們的緩存特征與靜態(tài)文件的完全相同。
此類(lèi)早期應用程序的一個(gè)簡(jiǎn)單例子是統一目錄 Web 應用程序。這種應用程序通常以如下方式工作：
Bill Higgins），并單擊提交按鈕。 GET http://psu.edu/Directory/Bill+Higgins）。 這種交互的一個(gè)重要特性是它是冪等的（idempotent），也就是說(shuō)除非底層資源發(fā)生變化（例如 Bill 修改了自己的電話(huà)號碼），否則同一請求的結果總是相同的。這意味著(zhù)瀏覽器或代理服務(wù)器都可以在本地對 Bill Higgins 的文檔進(jìn)行緩存，只要底層資源沒(méi)有發(fā)生變化，那就可以從本地緩存中檢索資源，而不再需要從遠程服務(wù)器檢索。這種方法能提高用戶(hù)感受到的響應性，并增加系統整體效率和可伸縮性。這些早期的動(dòng)態(tài) Web 應用程序可以很好地工作，將大量的信息送至用戶(hù)指尖。
下一代 Web 應用程序的目標就是高度融入，提供個(gè)性化的內容和富應用程序模型。在過(guò)去十年中，Web 開(kāi)發(fā)人員成功創(chuàng )建了這些融入式應用程序。一個(gè)非常恰當的例子是 Amazon.com 電子商務(wù)站點(diǎn)。當用戶(hù)與 Amazon Web 應用程序進(jìn)行交互時(shí)，它會(huì )創(chuàng )建復雜的客戶(hù)頁(yè)面來(lái)推薦有針對性的商品，顯示瀏覽歷史記錄，并顯示用戶(hù)購物車(chē)中商品的價(jià)格。
|
|
融入式 Web 應用程序確實(shí)非常有用，但服務(wù)器端的融入式 Web 應用程序風(fēng)格從根本上來(lái)說(shuō)是不符合 REST 架構準則的。具體來(lái)說(shuō)，它違背了一項關(guān)鍵的 REST 約束，并且沒(méi)有利用 REST 最為重要的一些優(yōu)點(diǎn)，因此又產(chǎn)生了一組新問(wèn)題。
REST 的 “客戶(hù)機－無(wú)狀態(tài)－服務(wù)器” 約束禁止在服務(wù)器上保存會(huì )話(huà)狀態(tài)。符合這一約束進(jìn)行設計可以提高系統的可見(jiàn)性、可靠性和可伸縮性。但是融入式服務(wù)器端 Web 應用程序希望能夠為單個(gè)用戶(hù)提供大量個(gè)性化內容，因此必須在兩種設計之間作出選擇。第一種設計要在每個(gè)客戶(hù)機請求中都發(fā)送大量狀態(tài)信息，因此每個(gè)請求都完整地保留了上下文的內容，服務(wù)器是無(wú)狀態(tài)的。第二種解決方案表面上來(lái)看比較簡(jiǎn)單，應用程序開(kāi)發(fā)人員和中間件供應商都比較傾向于這種方法，它只是簡(jiǎn)單地發(fā)送一個(gè)用戶(hù)標識，并在服務(wù)器端為這個(gè)標識關(guān)聯(lián)一個(gè) “用戶(hù)會(huì )話(huà)”（如圖 3 所示）。第二種設計直接違背了客戶(hù)機-無(wú)狀態(tài)-服務(wù)器約束。盡管它確實(shí)可以實(shí)現我們想要的用戶(hù)功能（具體來(lái)說(shuō)就是指個(gè)性化），但卻對這個(gè)架構進(jìn)行了極大的改動(dòng)。
Java™ Servlet 的 HttpSession API 正是一個(gè)此類(lèi)變動(dòng)的例子。HttpSession 讓我們可以在狀態(tài)和特定用戶(hù)之間建立關(guān)聯(lián)。這個(gè) API 看起來(lái)對于開(kāi)發(fā)新手非常簡(jiǎn)單。實(shí)際上，它似乎可以將任何對象保存到 HttpSession 中，并且不需要自己實(shí)現任何特定的查找邏輯就可以將這些對象取出來(lái)。但是當我們開(kāi)始在 HttpSession 中放入更多對象時(shí)，就會(huì )開(kāi)始注意到我們的應用服務(wù)器要占用的內存和處理資源越來(lái)越多。很快我們就確定自己需要將應用程序部署到集群環(huán)境中來(lái)應對日益增加的資源需求。然后就會(huì )認識到，要讓 HttpSession 在集群環(huán)境中工作，每個(gè)對象都必須實(shí)現 Java 的 Serializable 接口，以使會(huì )話(huà)數據能夠在集群環(huán)境中的服務(wù)器間傳遞。然后必須確定應用服務(wù)器在關(guān)機/重啟過(guò)程中是否要繼續維護會(huì )話(huà)數據。很快您就會(huì )質(zhì)疑，違背客戶(hù)機－無(wú)狀態(tài)－服務(wù)器約束是否真的是一個(gè)好主意。（實(shí)際上，很多開(kāi)發(fā)人員都不了解這個(gè)約束。）
融入式服務(wù)器端 Web 應用程序的第二個(gè)嚴重后果在于：它實(shí)際上不能利用 REST 的第一類(lèi)支持進(jìn)行資源緩存。引用 Fielding 的話(huà)來(lái)說(shuō)，“添加緩存約束的優(yōu)點(diǎn)是可以部分或完全避免某些交互操作，從而可以通過(guò)減少一系列交互的平均延遲來(lái)提高效率、可伸縮性以及用戶(hù)可以感受到的性能。不過(guò)這樣做的代價(jià)是如果緩存中的陳舊數據與通過(guò)將請求直接發(fā)送給服務(wù)器而獲得的數據有很大區別，那么緩存的可靠性就降低了。”
我們可以將融入式 Web 應用程序近似地看作一個(gè)活動(dòng)實(shí)體，它會(huì )根據用戶(hù)提供的新輸入內容、其他人輸入的新內容以及新的后臺數據而不斷發(fā)生變化。由于服務(wù)器必須根據多個(gè)用戶(hù)與應用程序的交互來(lái)生成每個(gè)頁(yè)面，因此我們實(shí)際上無(wú)法兩次生成相同的文檔。因此，Web 瀏覽器或代理服務(wù)器無(wú)法緩存服務(wù)器資源。
有幾種解決方案可以用來(lái)處理資源無(wú)法緩存的問(wèn)題。一種就是創(chuàng )建細粒度的資源在服務(wù)器端的緩存，這樣服務(wù)器就可以通過(guò)預先組合好的部分來(lái)構建一個(gè)粗粒度的頁(yè)面，而不是通過(guò)基本元素（HTML 和數據）從頭開(kāi)始一步步地構建這種頁(yè)面了。但是問(wèn)題依然存在：每個(gè)請求都會(huì )導致大量的服務(wù)器處理，這會(huì )損害系統的可伸縮性，還可能會(huì )對用戶(hù)感受到的響應性造成負面影響。
無(wú)法提供可緩存資源的另外一個(gè)結果是：動(dòng)態(tài)程度相當高的 Web 應用程序必須顯式地禁止搜索引擎和其他類(lèi)型的 “機器人”作出請求，因為處理這類(lèi)請求的成本都非常昂貴；而在符合 REST 準則的應用程序中，只需一次性地將某個(gè)資源提供給那一類(lèi) “機器人”，然后對它們的后續訪(fǎng)問(wèn)發(fā)送一條簡(jiǎn)單的 “Not-modified” 消息即可。
|
|
但是為什么要在一個(gè)負載過(guò)重的服務(wù)器上集中這么多的資源消耗呢？從理論上來(lái)說(shuō)，我們什么時(shí)候可以將處理和內存需求分布到客戶(hù)機呢？簡(jiǎn)單的答案是給定傳統 Web 瀏覽器約束，這是不可行的（請參看 不使用 Ajax 的客戶(hù)端處理）。但是 Ajax 架構風(fēng)格使開(kāi)發(fā)人員可以將處理和狀態(tài)需求分布到客戶(hù)機。請繼續閱讀，學(xué)習為什么選擇使用 Ajax 風(fēng)格的融入式應用程序可以繼續遵循 REST 準則，并充分利用它的優(yōu)勢。
正如我們前面看到的一樣，傳統的服務(wù)器端 Web 應用程序將數據的標識和服務(wù)器上的動(dòng)態(tài)數據元素合并在了一起，并將所構成的完整 HTML 文檔返回給瀏覽器。Ajax 應用程序在其主要 UI 和瀏覽器中的主要邏輯方面有所不同；基于瀏覽器的應用程序代碼可以在必要時(shí)獲取新的服務(wù)器數據，并將這些數據織入當前頁(yè)面（請參看 參考資料 中 Jesse James Garrett 有關(guān) Ajax 的啟蒙文章）。呈現和數據綁定的位置看起來(lái)可能是一個(gè)實(shí)現細節，但是這種區別會(huì )導致完全不同的架構風(fēng)格。
利用有狀態(tài) Web 客戶(hù)機的優(yōu)點(diǎn)
人們通常將 Ajax 應用程序描述成無(wú)需在每次點(diǎn)擊時(shí)徹底地刷新整頁(yè)的 Web 頁(yè)面。盡管這個(gè)描述非常確切，但是根本的動(dòng)機在于徹底刷新整頁(yè)會(huì )令用戶(hù)不耐煩，從而無(wú)法獲得愉快、融入式的用戶(hù)體驗。從架構的角度來(lái)看，整個(gè)頁(yè)面全部刷新的設計甚至非常危險，這種設計使您無(wú)法選擇在客戶(hù)機存儲應用程序狀態(tài)，這可能會(huì )導致妨礙應用程序充分利用 Web 最強大的架構設計點(diǎn)的設計決策。
Ajax 讓我們不需要進(jìn)行完全刷新就可以與服務(wù)器進(jìn)行交互，這一事實(shí)使有狀態(tài)客戶(hù)機再次成為可用選擇。這一點(diǎn)對于動(dòng)態(tài)融入式 Web 應用程序架構的可能性有深遠的影響：由于應用程序資源和數據資源的綁定轉換到了客戶(hù)端，因此這些應用程序都可以享受這兩個(gè)世界中最好的東西 —— 融入式 Web 應用程序中動(dòng)態(tài)、個(gè)性化的用戶(hù)體驗，以及遵守 REST 準則的應用程序中簡(jiǎn)單、可伸縮的架構。
設想一下，將 Amazon.com 徹底重新實(shí)現為一個(gè) Ajax 應用程序 —— 一個(gè) Web 頁(yè)面可以從服務(wù)器上動(dòng)態(tài)獲取所有的數據。（出于商業(yè)原因，Amazon 可能并不希望這樣做，不過(guò)那是其他文章討論的話(huà)題了。）由于現在有很多 UI 和應用程序邏輯都可以在客戶(hù)機而不是在服務(wù)器上運行，根據 Garrett 的說(shuō)法，最初加載頁(yè)面時(shí)需要下載 Amazon 的 Ajax “引擎”。這個(gè)引擎包含大量應用程序邏輯（以 JavaScript 代碼實(shí)現），另外還有此后將使用從服務(wù)器上異步獲取的數據填充的 UI 框架（見(jiàn)圖 4）：
Ajax 引擎一個(gè)有趣的特征就是：盡管它包含了很多應用程序邏輯和表示框架元素，但是如果經(jīng)過(guò)恰當的設計，它可以不包含任何業(yè)務(wù)數據或個(gè)性化內容。應用程序和表示都凍結在部署時(shí)。在典型的 Web 環(huán)境中，應用程序資源可能 6 個(gè)月才會(huì )變更一次。這意味著(zhù)負責隔離應用程序資源和數據資源的 Ajax 引擎是高度可緩存的。
Dojo Toolkit 就是一個(gè)很好的例子（請參看 參考資料）。Dojo 提供了構建時(shí)工具來(lái)創(chuàng )建一個(gè)包含所有應用程序邏輯、表示和風(fēng)格的壓縮 JavaScript 文件。由于它終究只是一個(gè)文件，因此 Web 瀏覽器可以對其進(jìn)行緩存，這意味著(zhù)我們第二次訪(fǎng)問(wèn)啟用 Dojo 的 Web 應用程序時(shí)，很可能就會(huì )從瀏覽器緩存中加載 Ajax，而不是從服務(wù)器上加載它。我們可以將這種情況與高度融入化的服務(wù)器端 Web 應用程序進(jìn)行一下對比，后者每次請求都會(huì )導致大量的服務(wù)器處理，因為瀏覽器和網(wǎng)絡(luò )中介不能對緩存不斷變化的資源。
由于 Ajax 應用程序引擎只是一個(gè)文件，因此它也是可以使用代理緩存的。在大型的企業(yè)內部網(wǎng)中，只要有一名員工曾經(jīng)下載過(guò)某個(gè)特定版本的應用程序的 Ajax 引擎，其他任何人都可以從內部網(wǎng)網(wǎng)關(guān)上上獲取一個(gè)緩存過(guò)的拷貝。
因此對于應用程序資源來(lái)說(shuō)，經(jīng)過(guò)良好定義的 Ajax 應用程序引擎符合 REST 準則，與服務(wù)器端 Web 應用程序相比，它具有顯著(zhù)的可伸縮性?xún)?yōu)勢。
用戶(hù)瀏覽一個(gè) Ajax Web 站點(diǎn)，加載 Ajax 應用程序引擎，最好是從瀏覽器緩存中加載的，否則就從本地代理服務(wù)器加載。那么對于業(yè)務(wù)數據來(lái)說(shuō)情況如何呢？由于應用程序邏輯和狀態(tài)都在瀏覽器上駐留并執行，因此應用程序與服務(wù)器的交互就與傳統 Web 應用程序的方式有很大的不同。不需要獲取混合的內容頁(yè)面，只需要獲取業(yè)務(wù)數據即可。
現在回到 Amazon.com 的例子上來(lái)，假設我們點(diǎn)擊了一個(gè)鏈接，要查看有關(guān)設計模式的一本書(shū)籍。在 Amazon.com 目前的應用程序中，鏈接點(diǎn)擊操作會(huì )發(fā)送很多標識所請求的資源的信息。它還會(huì )發(fā)送很多會(huì )話(huà)狀態(tài)信息，這讓服務(wù)器可以創(chuàng )建一個(gè)新頁(yè)面，其中可以包括之前的狀態(tài)（例如最近查看的內容）、個(gè)性化信息（例如您在 1999 年購買(mǎi)的書(shū)籍）以及實(shí)際的業(yè)務(wù)資源本身。應用程序是動(dòng)態(tài)且高度個(gè)性化的 —— 但是卻不能緩存，也無(wú)法伸縮（正如 Amazon 所示范的一樣，這些架構問(wèn)題都可以通過(guò)投入大量資金構建基礎設施來(lái)克服）?，F在我們考慮一下這個(gè)操作在（假想的）Ajax 版本的應用程序中的情況。對于 “最近查看的內容” 并不需要進(jìn)行處理。當我們點(diǎn)擊某個(gè)鏈接時(shí)，這些在頁(yè)面上已經(jīng)存在的信息并不會(huì )消失。有兩個(gè)請求很可能會(huì )與設計模式的書(shū)籍有關(guān)：
/Books/0201633612（其中 0201633612 是設計模式書(shū)的 ISBN 號） /PurchaseHistory/0201633612/bhiggins@us.ibm.com 第一個(gè)假定的請求會(huì )返回有關(guān)書(shū)籍的信息（作者、標題、簡(jiǎn)介等）；其中并沒(méi)有包含特定于用戶(hù)的數據。特定于用戶(hù)的數據意味著(zhù)當更多用戶(hù)請求相同的資源時(shí)，很可能會(huì )從 Internet 上的中間節點(diǎn)上來(lái)檢索緩存版本，而不是從原始服務(wù)器上檢索這些資源。這種特性會(huì )降低服務(wù)器和總體網(wǎng)絡(luò )負載。另外一方面，第二個(gè)請求包含了特定于用戶(hù)的信息（Bill Higgins 的購買(mǎi)該書(shū)的歷史記錄）。由于這些數據包括一些個(gè)性化信息，因此只有一名用戶(hù)需要從這個(gè) URI 中獲取并緩存數據。盡管這種個(gè)性化數據并沒(méi)有非個(gè)性化數據的可伸縮特性，但是重要的問(wèn)題是這些信息都是直接從 URL 中獲取的，因此都具有這樣的正面特征：它們都不會(huì )妨礙其他可緩存的應用程序和數據資源的緩存。
Ajax 架構風(fēng)格的另外一個(gè)優(yōu)點(diǎn)是它可以輕松處理服務(wù)器的故障。正如我們前面介紹的一樣，具有融入式用戶(hù)體驗的服務(wù)器端 Web 應用程序通常會(huì )在服務(wù)器上保存大量的用戶(hù)會(huì )話(huà)狀態(tài)。如果服務(wù)器發(fā)生了故障，會(huì )話(huà)狀態(tài)就丟失了，那么用戶(hù)就會(huì )體驗到非常奇怪的瀏覽器行為（“為什么我又回到主頁(yè)上來(lái)了？我的購物車(chē)中的東西都到哪里去了？”）。在采用有狀態(tài)客戶(hù)機和無(wú)狀態(tài)服務(wù)的 Ajax 應用程序中，服務(wù)器崩潰/重新啟動(dòng)對于用戶(hù)來(lái)說(shuō)都是完全透明的，因為服務(wù)器崩潰不會(huì )影響會(huì )話(huà)狀態(tài)，這些都保存在用戶(hù)的瀏覽器中；無(wú)狀態(tài)服務(wù)的行為是冪等的，可以由用戶(hù)請求的內容來(lái)單獨確定。
|
|
對于我們稱(chēng)為融入式 Web 應用程序的那些 Web 應用程序來(lái)說(shuō)，設計良好的 Ajax/REST 應用程序在用戶(hù)體驗、響應性和可伸縮性方面都遠遠超過(guò)傳統的服務(wù)器端 Web 應用程序。然而，一種架構風(fēng)格的運行時(shí)特征對于軟件項目和 Web 應用程序來(lái)說(shuō)并非是決定成功的惟一因素。在創(chuàng )建 Ajax/REST 應用程序時(shí)有一些非常困難的非運行時(shí)問(wèn)題，包括大規模 JavaScript 開(kāi)發(fā)、文化問(wèn)題和打包問(wèn)題。我們將在另外一篇文章中討論有關(guān)文化的問(wèn)題，其他內容留待我那些研究 Ajax 的同僚們去處理。
聯(lián)系客服
