Tapestry和JSF對比
1．JSF和Tapestry性能方面
JSF
從測試數(shù)據(jù)可以看出在只使用JSF及JSF自定義組件的情況下,webmail demo應用速度最快，200用戶并發(fā)訪問的響應時間為1.8秒，基本上可以達到servlet + jsp的性能。
使用JSF + 5個Facelet composition組件的情況下，webmail demo應用仍可達到200用戶并發(fā)訪問的響應時間為2.6秒的性能。
使用JSF + 20個Facelet composition組件的情況下,webmail demo應用可達到200用戶并發(fā)訪問的響應時間為3.1秒的性能。
如果在業(yè)務層方法沒有大的效率問題、并在壓力較大的頁面適當使用緩存的情況下，JSF應用程序可以達到在dell 2850機器上100-200并發(fā)5秒內(nèi)響應的性能
Tapestry
從測試數(shù)據(jù)可以看到tapestry在使用相同數(shù)量框架自身提供組件的情況下，運行效率比JSF明顯要低一些，但也算是在可以接受的范圍內(nèi)。
2．JSF和Tapestry開發(fā)方面
JSF
JSF對servlet API進行了封裝，程序員在使用組件做JSF應用程序的開發(fā)時基本上不需要直接操作HttpRequest和HttpResponse,并且對用戶輸入驗證，手機等其它設備（通過rendererKit），多語言(通過資源文件方式)和換膚（通過rendererKit）的支持都有相應的封裝，可以方便的實現(xiàn)。目前開源的組件庫有MyFaces,ADF等可以使用,其中有些組件內(nèi)置AJAX支持。
開發(fā)工具中IBM WebSphere Studio,Oracle JDeveloper 10g和FaceIDE等IDE對JSF應用開發(fā)提供可視化編輯支持。下面是對JSF自定義組件和JSF+facelet composition組件開發(fā)進行比較
JSF自定義組件開發(fā):
JSF自定義組件由java代碼和tag庫文件組成，開發(fā)難度應該與現(xiàn)有I2SS組件開發(fā)的難度基本一致,JSF自定義組件通過自定義標記構造頁面，在頁面上增加組件的數(shù)量對性能有較大的影響。
JSF + facelet composition組件開發(fā):
facelet composition組件在個性化、重用方面對JSF提供了很好的補充。通過編寫tag庫文件，使用facelet可以把多個JSF自定義組件組合成facelet composition組件，或者把幾個facelet composition組件組合成新的facelet composition組件,這個過程不需要開發(fā)或設計人員編寫Java代碼。facelet composition組件是live模式運行時生成，從測試結果上看組件數(shù)量對性能的影響不大
學習曲線上,開發(fā)難度與組件基本一致,只要寫過組件或寫過servlet+jsp的人,加上適當培訓,一周內(nèi)都可掌握JSF或Tapestry開發(fā)
Tapestry
組件和頁面的開發(fā)過程完全一致，都是由模板、page/component class和specification文件組成。IDE方面目前有開源社區(qū)開發(fā)的eclipse插件Spindle和Tapestry Palette可用，對開發(fā)效率有一定的提升。
3.JSF和Tapestry集群支持方面
JSF
目前在I2SS上做的集群實驗是使用apache+jboss來實現(xiàn)，結構是apache做集群前端實現(xiàn)stick session，jboss做應用服務器。
I2SS架構應用程序Session中放入的對象并不能全部串行化，所以在做集群時只能使用粘貼會話方式(stick session)實現(xiàn),這樣容易出現(xiàn)的情況是如果一臺機器down掉，這臺機器上的所有在線用戶都會無法繼續(xù)當前的會話。如果用戶重新發(fā)起登錄請求，任務會轉移到其它正常工作的機器上。如果down掉的機器重新恢復，轉移到其它機器上的用戶不能重新使用這臺新啟動的機器，只有新發(fā)起的用戶請求和在線用戶調(diào)用session.invalidate()顯式退出后，工作才會轉移到新啟動的機器上，這樣負載的均衡時間會比較長。I2SS架構應用程序可以通過更改框架層，將現(xiàn)有放入session中的對象實現(xiàn)串行化，并且將不能串行化的對象放到session以外的地方來實現(xiàn)使用session replication的集群模式。
在JSF上做的集群實驗是使用apache+jboss來實現(xiàn),支持stick session和session replication兩種模式。stick session模式的結構和討論如上述，session replication的結構是apache做集群前端,通過jboss的TreeCache實現(xiàn)session replication。在編寫JSF程序時要把放入會話中的backing-beans實現(xiàn)串行化，如果一臺機器down掉，在線用戶的會話會轉移到其它正常工作的機器上，對于用戶的感受來說可能是速度變慢，但是不會出現(xiàn)會話斷掉的情況。如果down掉的機器重新恢復，TreeCache通過網(wǎng)卡或文件系統(tǒng)完成session replication的過程后，在線用戶的任務就可以實現(xiàn)與機器未down時相同的負載均衡狀態(tài)。如果想減少網(wǎng)卡或文件系統(tǒng)的I/O操作，可以通過集群分區(qū)來實現(xiàn)。
Tapestry
Tapestry本身提供兩種state持久方式：傳統(tǒng)的session方式和client-side方式。狀態(tài)保存在session中的情況下，實現(xiàn)集群和JSF方式一樣，需要session replication。保存在client-side的情況下，有一些局限性，但是可以實現(xiàn)無狀態(tài)的應用，自動支持集群。
4.對于I2SS組件與JSF組件混合使用的說明
JSF組件應用程序是標準J2EE應用程序，JSF組件對servlet API提供了封裝，同時也提供了直接得到servlet上下文的方法，所以I2SS組件與JSF組件的混合使用與現(xiàn)在已經(jīng)實現(xiàn)的郵件系統(tǒng)中servlet+JSP與I2SS組件的混合使用方法是一樣的，都可以用手動創(chuàng)建EbiContext實例的方法來實現(xiàn)。
5.目前JSF標準的進展情況，以及行業(yè)的支持情況
JSF 體系結構
JavaServer Faces 的 MVC 實現(xiàn)
JSF 的主要優(yōu)勢之一就是它既是 Java Web 用戶界面標準又是嚴格遵循模型-視圖－控制器 (MVC) 設計模式的框架。用戶界面代碼（視圖）與應用程序數(shù)據(jù)和邏輯（模型）的清晰分離使 JSF 應用程序更易于管理。為了準備提供頁面對應用程序數(shù)據(jù)訪問的 JSF 上下文和防止對頁面未授權或不正確的訪問，所有與應用程序的用戶交互均由一個前端“Faces”servlet（控制器）來處理。
【編輯推薦】
