Posted on 2005-12-07 15:54
笨笨 閱讀(2733)
評論(2) 編輯 收藏 所屬分類:
Java
With or Without EJB?
EJB 運行時所享受的 J2EE 基礎服務
1 參與AppServer 提供分布式事務管理(JTA,JTS)。
2 AppServer 提供高性能通訊框架(基于RMI 或 IIOP實現)和大并發處理。
1) AppServer 如 WebLogic/WebSphere 替換了 Sun 標準 RMI 實現（基于著名的多線程阻塞IO），國內的 Apusic 4 則基于純 NIO 的 IIOP通訊協議實現EJB 遠程通訊。
2) AppServer 提供 EJB 實例池、請求隊列、執行線程池等等服務。
3 AppServer 提供透明 EJB 集群管理（負載均衡、故障恢復），保證應用的處理能力能夠水平擴展。
4 J2EE 安全體系
5 AppServer 特有的附加增值服務
1) 如 WebLogic WTC EJB，可實現從TUXEDO Service(C語言) 高性能訪問 EJB。
大型項目所關注的重點
對于大型項目如全國集中這一級別而言，它所關注的重點風險反而是系統的性能、吞吐量、穩定性、高可用性這樣的一些基本屬性，這里并非說具體的業務功能就不重要；而是與上述的基本屬性相比，業務功能可以說是相對的不重要。
基本屬性如果有某一項沒有達到，直接后果就是項目失敗，或者運行時存在高風險。
業務功能則主要是堆時間、堆人、堆代碼、堆測試人員的問題，如果實在來不及了，那就放到第二期去做好了，不影響主旋律么。
對于大型項目而言，采用新技術的關注點主要是：
1 能否滿足基本質量屬性，無重大運行時風險。
比如說，數據訪問層，從性能和穩定性角度而言，還算直接采用 JDBC 編碼合適，最多采用SQL映射型JDO。對于帶緩沖的JDO實現則不宜采用，會帶來水平擴展和穩定性風險。
2 項目組相關人員是否有此技術的經驗，最好不要付出學習成本，避免因不熟悉所帶來的風險。
EJB 和 IoC 框架如 Spring 的定位比較
Spring IoC/Context/AOP 可以認為是一個代碼組織(Assembler)框架，關注代碼如何組織和去耦。
EJB 則是運行結構，關注我們的應用如何運行，如何做集群，系統計算資源如何分配等等。
EJB 3 的改進主要還是從代碼組織角度做出的，對于 EJB 運行時架構并沒有多少變化（如果說錯了，還請指正）；BEA 還有過將 EJB 3的代碼翻譯為 EJB 2.1 運行時架構的考慮（參見 BEA 的關于 EJB 3 的一篇文章http://www.javaworld.com/javaworld/jw-08-2004/jw-0809-ejb_p.html）。
從上述角度來看，EJB 和 Spring 是從不同的角度看待應用，我們完全可以做到用 Spring 組織代碼實現EJB。
With or Without EJB?
從上述討論可以看出，用Spring還是用EJB并不是個問題，最終還是看用戶的實際需求而定。小Web項目多半不關注性能、并發、集群等等屬性，出于開發過程簡單和學習成本的考慮，完全可以不用EJB；而大型項目可能還是得用EJB。