細看Web 2.0的三大技術特征
盡管對于Web 2.0的定義不僅僅只有一種，但是它的核心是互聯網，扮演著社交網絡的一個平臺，在這個平臺上面信息是可以被創建的，并且可以在有趣的社區里面與大家分享。因為通過提供一些更加有效的用戶界面來實現增強平臺的性能，豐富的互聯網應用軟件(RIAs)與Web 2.0的概念才能相結合。
AJAX與Web 2.0相結合是因為它能夠支持使用一種輕便的方法來開發RIA，通過一種單一的普遍存在的界面——Web瀏覽器，就能執行。
對于現有社交網絡平臺，比如wiki和博客的互動模式的一個調查顯示他們缺乏真正的實時的人機交互。這是一個偽同步網絡模型，當我們考慮預想中的Web 2.0系列的下一代平臺的時候，這是必須要克服的一個問題。基于互聯網的交流就是Web2.0所需要的，近乎瞬時互動的最基礎的例子，但是即便是這些基礎能力，升級，輕便，以瀏覽器為基礎的機制都是大多數AJAX無法實現的。
基礎內容之基于Web的推動
工業上并沒有為機制定型，或者是為異步數據設定一個名稱，推動其到瀏覽器上。在AJAX領域內，技術的成長伴隨著各種各樣的名稱，包括AJAX Push、 Comet和 Reverse AJAX，但是不管你稱呼其什么，各種做法都有一個共同的特征。唯一可用于瀏覽器的輕量級的交流機制就是HTTP協議，但是HTTP協議只能減輕一些困難，這些困難主要是執行從瀏覽器到服務器的標準請求/回答交流機制。為了交付異步響應，通過在服務器中支持一個開放式的請求來達到反轉HTTP協議的目的的操作是非常有必要的，并且當一個更新操作可用的時候，徹底的執行這個請求。標準AJAX請求處理與進棧的倒轉機制請求之間的不同，如圖一所示。
為了支持異步進棧，預期的基于服務器的事件中我們必須保持開放的瀏覽器連接，這將會導致瀏覽器外表的變化。直覺告訴我們這里能夠提供這種方法，并且在這種情況下，當我們面對瀏覽器和服務器上面關于連接的問題的時候，直覺做得很好。
瀏覽器連接限制
異步Web技術所要面對的主要問題中的一個是由典型的瀏覽器“雙連接限制”所引起的。為了減輕服務器負載，用戶代理確定的HTTP規范建議每服務器最多連接兩個瀏覽器，但是異步技術消耗掉了其中的一條連接，將其作為通知渠道。考慮到這樣一種情況，多重瀏覽器窗口在一樣的Web頁面打開，如果每一個窗口都嘗試著確定它自己的連接，我們很快就會造成可用連接的飽和。在這些限制條件內工作，單一的一個連接肯定會被分享，但是為了確保安全，各種不同的瀏覽器窗口的腳本環境都是獨立的，這使得彼此之間協調分享連接變得非常困難。一種可以使用于此處的技術利用一個可共用的HTTP cookie，這個HTTP cookie于所有的HTTP關聯，與一個給定的服務器共同工作。Cookie被共用于交叉的窗口上，并且通過Java腳本的操作可以被用于跨窗口的交流。
在門戶網站環境中這個問題會被擴大，因為傳統的門戶網站引擎不支持必須的異步通信途徑。為了推動多重門戶網站的工作，不僅僅是需要分享瀏覽器連接，而且一個單一的共享服務器連接被要求排列異步請求。如果門戶網站的部署是來自于多重的WAR，這里將會產生一個額外的難題，因為共享機制必須在多重Web應用程序之間并列協調，并且將會要求一些IPC機制來實現這個操作。當我們評估了不同的推進機制，自從它變得越來越復雜，超過了典型的應用開發人員應該接觸的范圍，了解它們是如何標記連接共享問題就變得非常重要了。順便說一句，瀏覽器供應商將會徹底的降低共享連接的復雜性，他們將會通過控制HTTP流水線操作來實現降低共享連接的復雜性，因此可以允許不同的窗口共享一個單一的連接。
應用服務器可擴展性
當我們審查來自應用服務器方面的開放連接的問題，我們發現這個問題發生了變化。結果是現代的應用服務器可以應付很多的高效連接，但是在現有的servlet模型下，每一個這樣的連接都要求一個線程的執行。如果這些連接變的持續時間很長，由于服務器發起的更新，服務器的可擴展性將會被線程池用盡這樣的情況所拖累。
盡管在JSR 315中，標準活動在servlet模型進展中是與異步通信相關聯的，在工業上解決這個問題的方法是根本不相同的，沒有標準的。標準機制的缺乏是十分令人失望的，因為任何可升級的推進機制都需要緊緊地與基礎服務機制相結合，這一切要求部署的具體實施。好的消息就是多種多樣的解決方案已經出現了，跨越開源的應用服務器，哪一個我們需要考察?
結論
我們描述Web 2.0的特征，如自發的平臺，實時的社交網絡，審閱與使用輕量級基于Web技術的交付時候必須的入棧模式性能連接的復雜性，傳遞信息性能方面一些開源的技術開始出現。所以，Web 2.0在今天很有可能就是伴隨著現有的開源技術。更遠一些來說，標準化的制定將會有所幫助，下一階段的瀏覽器執行將會最終緩解這種復雜性。如果入棧模式的Web應用和Web 2.0在你的預料之中，投入進去看看什么即將會發生吧。有一點需要謹慎，你需要謹慎的檢查現有開發的***方法和強制部署，設計出一種方法能夠準許你把重點放在應用開發上面，而不是那些低級別的入棧之類的基礎開發。
【編輯推薦】
