用了一段時間 Spring, 看了一下 Guice, 現在開始看 EJB 了。書選的是 EJB 3 in Action , 現在只看到第三章。測試服務器用的是 JBOSS 5.1, 用 MyEclipse 開發。
Spring Container 裏面的對象功能類似於 EJB 3 中的無狀態會話Bean(SLSB), 或者更類似於 EJB 3.1 引入的 Singleton。儘管絕大部分業務邏輯都能用 spring 完美解決, 但 EJB 3 一些特有的功能能給我們提供一些新的思路。
- SLSB 無須考慮併發。 首先是 SLSB, 由於有 poll 的概念, 所以同一時間只有一個 SLSB 只有一個客戶端在訪問, 所以在編程時不必考慮併發. 但如果要在運行期修改參數就比較麻煩了, EJB 3.1 可以用 Singleton 來解決, EJB 3 用什麼？ @Resource 可以用來解決這個問題麼？ 如果可以解決的話會不會有效率問題。
- SFSB 給你新的選擇。 對於有狀態會話Bean(SFSB), 在 Spring 中沒有對應的概念。靠近 web 端的需求一般用 HttpSession 來解決, 而靠近後端的一般就用 memcache 來解決了(有時候也用數據庫, 或者在內存中用 Map 來儲存數據), 有的時候直接把狀態儲存在對象中, 每次調用時把狀態對象作爲參數傳入, 就把一個 SFSB 轉成一個 SLSB 了。比較之下, 用 SFSB 來解決類似的問題能更乾淨一些, 但書中也多次強調 SFSB 的風險, 特別是忘記 @Remove 時內存方面會出問題 。
- EJB 容器支持更好的延遲加載。
儘管Spring Bean 容器支持延遲加載, 但能用上的機會不多, 因爲只有樹頂的 Bean 能支持延遲加載, 同時對於 web 工程, 樹頂基本都是 Controller, 而 Controller 在 URL 映射綁定階段基本就全部加載完畢了。當然, 你也可以讓你的類實現 ApplicationContextAware/BeanFactoryAware, 然後注入 Bean 的名字而不是 Bean 本身來實現延遲加載, 不過這樣實在是太麻煩了; 有觀點認爲不應當使用延遲加載, 因爲啓動時就發現資源不存在或者資源不足, 比起運行期再發現會好很多。
EJB 容器支持更好的延遲加載, 當你調用一個 EJB 時, 並不需要初始化他所依賴的 EJB, 他依賴的這些 EJB 可能不存在, 也可能在 EJB Container 的緩衝池中, 甚至可能在遠端, 只有當調用被依賴的 EJB 上的方法時, 才需要初始化一個或者從池中取一個。 EJB 容器對內存不足有一些防範措施, 比如可以銷燬 SLSB, 持久化甚至銷燬 SFSB 。而對於其他資源(如數據庫), JBOSS 一般使用獨立的部署文件(比如 *-ds.xml), 這些資源不存在時, 啓動階段就會有警告。 - EJB Container 是全局的。 由於種種原因(比如人員協調,比如測試服務器啓動太慢), 我們會把一個應用拆分到多個 webapp 上, 每個 webapp 上面一個 spring container。這樣帶來了一些問題, 比如需要更小心的處理一致性問題; 單例類被創建了多個, 浪費了資源; 運行期變更狀態時需要通知多個webapp等等。EJB Container 是在 application server 級別的, 所以很多問題很自然地消失了。
- 可以從客戶端訪問EJB。 在後臺寫界面來控制所有的運行參數實在是太麻煩了, 特別是運行參數經常增刪的情況下。 所以我們的做法是把需要配置的類通過 MBean 來暴露, 通過 JMX 接口來管理。不過比較起來, 聲明一個 EJB @Remote 接口, 比聲明 MBean 看起來乾淨多了。@WebService 也許是一個更好的主意, 不過現在還沒看到, 不敢確定。 spring-ws 還沒看過, 不知道是否適合用來解決這個問題。
Spring 現在能完美地支持我的工作內容, 所以我也不會考慮馬上就倒向 EJB, 我只是不想做井底之蛙而已。
歡迎指正。