[轉帖]從中間件廠商的角度看EJB3標準

在我Support過的許多BEA客戶裏面，80%依然使用EJB2，20%已經開始使用Spring，但幾乎沒有看到有真實的大客戶在關鍵系統中使用 EJB3，EJB3的技術其實已經很成熟，在分佈式能力上，WebLogic EJB2.0容器通過10年的改進，在分佈式性能以及穩定性方面，已經至關成熟，強大的JMX支持亦爲WebLogic贏得更多的商業用戶。儘管EJB2 的複雜性，但BEA畢竟將這些複雜性降至最低，好比經過WebLogic的Ant Task擴展，weblogic.ejb.GenericSessionBean等等，但這一切依然沒有解決無接口不OO的尷尬局面（EJB3作到了真正的POJO化，即ReviewManagerBean是implements ReviewService，POJOer舒了一口氣），且IDE工具的重構也更加容易直觀。 EJB3的Annotation改善了POJOer的Coding情況，卻沒有增長EJB容器廠家不少的工做量。各個中間件廠商依然使用他們原有的EJB CodeBase做爲EJB3的基礎，所以，咱們徹底信任EJB3的穩定性和可靠性。 在中間件廠家的角度，EJB3其實能夠分爲兩個部分： A1，Session Bean、MDB領域【具備分佈式容器依賴性】 A2，持久層實現（JPA）【對分佈式容器無依賴性】 在 A1領域，中間件廠家更關注於屬於容器的範疇，即好比爲笨重的EJB2容器添加DI能力，不管是Annotation仍是XML描述符，都額外簡單；你可能有疑問，這些DI是否會增長容器設計的複雜性嗎? 顯然不會。據我所知，爲了支持EJB3後，WebLogic容器的重構了大量的EJB2代碼，從weblogic.ejb20抽出了大量的EJB內部接口到weblogic.ejb Package去，且僅僅改寫了部分的內部類，因而，咱們會看到內核中包含了一些beaninfo.isEjb3的條件分支的判斷。 至於MDB，WebLogic 11g以後會融合更強的Oracle JMS Provider實現，性能和可靠性絕對會讓人耳目一新。 A2，好久之前，WebLogic明顯花了很大的力氣去實現Entity Bean，它太難用了，幾乎毫無學習的必要，KODO隨後被BEA收購，並派生一個OpenJPA的開源項目（輸給了Oracle的TopLink Essential開源項目），Oracle收購BEA以後，可能會將TopLink從新融入到WebLogic默認實現中，以前使用KODO結合 Spring的被發現不少運行時問題(困擾了我好久，後來索性換成TopLink Essential)，可讓開發者大爲放心。有着10多年曆史、業界領先的TopLink做爲WebLogic EJB容器的一部分（JPA Provider方式)，它的穩定性也是有目共睹的；另外，要提到的是，TopLink包含了Runtime監控的特性，Oracle移植TopLink 到Weblogic11g的時候亦會包含它爲OC4J提供的TopLink Runtime Monitor特性，這些特性是容器依賴的，但並非必須。 對 EJB3的客戶而言，Codebase的穩定性是很是重要的，從EJB2->EJB3，WebLogic並無改變太多的EJB核心設計，從而保證了EJB2客戶遷移到EJB3所帶來的可靠性；另外，持久層方面，從KODO過渡到TopLink，ORM的穩定性和性能亦會有一個很多的飛躍。總之，WebLogic 11g是值得期待的一個強大的EJB3版本。