原貼地址：
http://news.csdn.net/n/20061221/99748.html從根本上說，面向服務的架構能夠使企業內部動態數據服務的創建變得更加方便，同時，還能夠使企業開發人員創建影響這些服務的復合應用程序。Web2.0提供了一個豐富的Web體驗，用戶能夠以高效的、充滿希望的、有益的方式參與合作。
如果我們把這兩個現象結合起來，那么，通過企業社團成員之間的互相交流，以及成員與不斷變化的企業數據之間的交互，我們就能夠實現這一關鍵的提高效率的新方法。
協作型企業相互融合，下一代的Web應用程序也已露端倪，但是，開發團體的推測是，為了實現明顯的利益，企業所采用的各種技術之間存在著根本性 的差異。標準必須朝哪個方向發展才能夠滿足SOA與Web2.0概念的結合，為了更好的理解這個問題，我們將致力于檢驗Java表示技術的狀態。
Ajax化JavaServer Faces
標準奠定了SOA的基本結構，但是，在Web2.0的世界中卻不存在著標準。為了支持Web2.0的功能，市場上出現了太多的方法，其中大多數 在JavaScript的實現(影響Ajax的技術)上卻非常繁雜。在Java EE的規范中，JavaServer Faces提供了表示層，但是，相比起Ajax技術和Web2.0概念的流行，它目前的修訂版出現的更早。
事實證明，在組件層，JSF中的可擴展組件架構非常適合與Ajax技術協同使用，但是，組件層Ajax技術存在的問題是，它們是存在于狹小的規 避JSF生命周期的交互空間內。解決這一問題所需要的是，一種更加全面的方式，以實現在JSF生命周期內的Ajax交互。具體來說，有以下兩點需要著重闡 述。
1.改進的用戶交互模型: 在JSF中，目前的用戶交互模型是基于表格的，它過于粗略而無法傳輸豐富的Web2.0特性。組件層的Ajax交互粒度，以及JSF目前依賴的基于表格的子任務模型，這兩者之間存在著顯著的差異。交互類型應當包含以下幾種形式：
- 純粹的本地客戶端JavaScript交互，沒有服務器通信、不需要執行JSF生命周期。這種類型的例子可以是，在日期選擇組件中通過日歷來進行導航。目前，通過組件層JavaScript實現能夠支持這個模型。
- 組件層的Ajax交互，不需要執行JSF生命周期。這種類型的例子可以是，基于當前用戶在文本框中的輸入，從而形成一個列表。這里的關鍵是，用戶與組件的交互僅僅影響到該組件的表示。同樣，目前，通過組件層JavaScript實現能夠支持這個模型。
- 組件層的提交，引發JSF生命周期的執行。生命周期的執行結果將成為新的表示，該表示可能會影響到頁面中的多種組件。這這種類型的例子可以是，在日期選擇組件中完成日期的選擇，結果是引發顯示不同的日期安排信息。目前在JSF中，還無法支持這種形式的交互。
2. 增量表示更新: 為了使用Ajaxian 方式(不是頁面刷新)實現第三種交互模型，JSF需要一個增量更新機制，僅僅是把頁面中應用到的表示層所做的必要修改從一個表現處理傳向下一個表現處理。 下面這個圖示表明了這個概念。它需要一個Ajax橋，在服務器端把表示的改變組合起來，在客戶端的DOM把那些變化重組。
JSF Push模式
Ajaxified JSF實現和多數其它的Ajax方式從遺留的Web應用程序模型中繼承了一個共同的特征，該模型是一個客戶端發起的交互模型。這意味著，客戶端的表示層只需要針對用戶與表示層的交互進行相應變化。
與使用遺留應用程序相比，使用Ajax技術，這個交互是細粒度的，但是，它仍然是客戶發起的?，F在，當你檢驗支持應用程序的SOA數據模型的動 態特性、了解眾多同步用戶采用這一動態數據所進行的協調互操作時，你就能夠意識到，在客戶端推動動態表示變化的機制是非常重要的，這一點越來越清晰。它是 達到Web2.0模型所需要的真正的動態特性的唯一途徑。
在產業中已經證明，對于JSF規范與一個表示push模型的協作來說，Ajax push技術，也指Comet，是十分必要的。前文已經描述的這個增量更新特性，提供了在實現JSF Push模式時所需要的基于Ajax的更新機制。除此之外，當應用程序邏輯發現出現了一些將會影響客戶端表示層狀態的變化時，延長JSF的生命周期來允許 一個強制的表現處理是很有必要的。
雖然，JSF push模型相對而言實現起來更加容易，但是，生產經驗表明，為使得開發人員能夠有效繼承，僅僅暴露JSF API中底層強制的表示機制是遠遠不夠的。關于基本的push機制，JSF規范很有必要對表現API進行介紹，從而呈現給開發人員一個清晰有效的機制，用 于請求強制表示。API尤其需要提供以下幾個方面：
1.觸發的表現:應用程序開發人員應當能夠在發出表示處理請求的業務邏輯中定義觸發點。
2. 群組表現: 一個觸發點能夠影響一個單一客戶端、多個客戶端，或者是所有連接到該應用程序上的客戶端。因此，為觸發表現提供群組管理結構，這是很有必要的。
3. 預定的表現:有許多合適的計劃機制應當被支持，包括，按需表現、推遲表現，以及內部表現。預定的表現架構應當具備可擴展性，以支持其他用戶預先設定的需 求。很重要的一點是，觸發表現機制應當能夠更加有效的傳輸。由于存在著大量的觸發，它們潛在地以各種方式影響著客戶端，因此，管理表現的處理這一任務不能 僅僅落在開發人員身上。觸發表現的實現，必須有效地合并表現處理請求、處理必要的同步，而且，這些操作都是以一種線程有效的方式。
多視圖支持
現存的為JSF定義的階段和需求范圍，根本不足以支持滿足Ajax的JSF應用程序——用戶能夠在同一應用程序上獲得多個活動視圖。階段范圍能 夠維護所有視圖共同的狀態，但是，它不足以處理視圖之間不同的狀態。由于多個同步請求都必須是活動狀態，所以，需求范圍也不充分。因此，需要一個新的范 圍，來管理滿足Ajax 的JSF應用程序的會話方面。JBoss的Seam 方案提出了會話范圍，它主要提供JSF中所需要的額外范圍。除了支持多視圖之外，會話范圍還能夠帶來其他優勢，例如，在應用程序中，通過會話中對一系列用 戶交互的明確描述，就能夠有效地支持書簽和返回按鈕特性。
長期存在的HTTP請求
回到前面所提到的push模型，你可能注意到，機制需要一個特殊的HTTP請求，它能夠異步地響應從應用程序中發出的觸發表現出理請求。依據更 新的頻率，這個特殊HTTP請求能夠長期存在。由于在響應之前，每一個請求都占用其線程，所以，在處理這個長期存在的請求時，現存的Servlet模型無 法很好的響應。因此，為了支持push模型，必須對Servlet模型進行改變，使它能夠以線程有效的方式來處理長期存在的請求。再強調一次，有很多生產 方案與異步Servlets和HTTP服務器相關，Java EE規范能夠在此基礎上定義一個解決方案。
結論
人們仍然有些質疑：SOA與Web2.0世界將會發生抵觸，新一代的協作型企業應用程序已露端倪。也存在著這樣的質疑，現存的Java EE規范無法完全處理Web2.0提出的請求，以及JSR處理必須開始在直接項中考慮這些請求。然而，產業中的重大進步，已經能夠處理出現的請求，并且能 夠實現擴展現存Java EE基礎結構的商業化的可行方案。即將使用JSR 172來生成JSF2.0規范，非常重要的是,包含Ajax特性，以及產業參與者貢獻相關技術,來確保能夠及時做出基于標準的解決方案。