| 以文本方式查看主題 - 曙海教育集團論壇 (http://m.adgdgn.cn/bbs/index.asp) -- JAVA語言開發 (http://m.adgdgn.cn/bbs/list.asp?boardid=64) ---- 【Java開發技術】Java EE 迎合 Web 2.0 (http://m.adgdgn.cn/bbs/dispbbs.asp?boardid=64&id=2462) |
| -- 作者：wangxinxin -- 發布時間：2010-12-11 9:38:15 -- 【Java開發技術】Java EE 迎合 Web 2.0 如果 Web 2.0 應用程序使用的是基于標準的 Java Platform, Enterprise Edition 5 (Java EE) 開發方法，那么將會面臨著嚴重的性能和可伸縮性問題。這是因為，大量支持 Java EE 平臺的底層設計原理（尤其是使用同步 API 的應用）并不適合 Web 2.0 解決方案的需求。本文將解釋 Java EE 和 Web 2.0 方法之間的不一致性，并對一些使用 Java 平臺開發異步 Web 應用程序的解決方案進行評估。 很多成功的企業應用程序都是使用 Java EE 平臺構建的。但是，Java EE 的設計原理并不能夠有效地支持 Web 2.0 應用程序。深入了解 Java EE 和 Web 2.0 原理之間的脫節可幫助您制定明智的決策，從而使用各種方法和工具在一定程度上解決這種脫節。本文將解答 Web 2.0 和標準 Java EE 平臺緣何成為失敗的組合，并演示為何由事件驅動的異步架構更適合 Web 2.0 應用程序。本文還介紹了一些框架和 API，它們通過支持異步設計使得 Java 平臺更加適合 Web 2.0。
Java EE 原理和設想
Java EE 平臺的創建目的就是為企業到客戶（B2C）和企業到企業（B2B）應用程序提供支持。企業發現了 Internet 的價值之后就開始使用它增強與合作伙伴和客戶之間的現有業務流程。這些應用程序通常要與一個現有企業集成系統（EIS）進行交互。大多數常見基準測試（測試 Java EE 服務器的性能和可伸縮性）— ECperf 1.1、SPECjbb2005 和 SPECjAppServer2004的用例都將這一點反映到了 B2C、B2B 和 EIS 中。類似地，標準的 Java PetStore 演示也是一個典型的電子商務應用程序。
很多有關 Java EE 架構可伸縮性的明顯和暗含的設想都反映在基準測試中：
這些設想產生了以下 Java EE API 構建原理：
在 Web 1.0 中，這些原理玩轉得非常好。可以將一些獨特的應用程序設計為遵守這些規則。但是，這些原理不能有效支持 Web 2.0。
Web 2.0 帶來的巨變
Web 2.0 應用程序具有很多獨特需求，因此，不適合將 Java EE 用于 Web 2.0 實現。其中一個需求就是，Web 2.0 應用程序更多地通過服務 API 使用另一個 Web 2.0 應用程序，而不是使用 Web 1.0 應用程序。Web 2.0 應用程序的一個更為重要的因素是，極度傾向于用戶到用戶（C2C）交互：應用程序所有者只生成一小部分內容；用戶負責生成大部分內容。
SOA + B2C + Web 2.0 = 高延遲
在 Web 2.0 環境中，聚合應用程序經常使用通過 SOA 服務 API 公開的服務和提要。這些應用程序需要在 B2C 環境中使用服務。例如，一個聚合應用程序可能從三個不同的數據源提取數據，如天氣信息、交通信息和地圖。檢索這三種獨特數據所需的時間延長了總的請求處理時間。不管數據源和服務 API 的數量是否增加，用戶仍然期望得到具有高反應度的應用程序。
諸如緩存這類技術可以緩解延遲問題，但是不適用于所有場景。比如，可以緩存地圖數據來減少響應時間，但通常并不適合將搜索查詢結果或者實時交通信息進行緩存。
服務調用本來就是一種高延遲過程，在客戶機和服務器上通常只分配很小一部分 CPU 資源。Web 服務調用的持續時間很大一部分用于建立連接和傳輸數據。因此，通常來講，提升客戶端或服務器端的性能對于減少調用持續時間效果甚微。
Web 2.0 對用戶參與的支持引發了另外一大挑戰，因為應用程序要處理來自每個活動用戶的更多數量的請求。下面這些理由證明了這一點：
|