本文從實戰角度比較EJB2和EJB3的異同，通過深入剖析揭示EJB3.0的真相，EJB3.0真是帶來簡化？還是一種表象上的簡化？EJB3.0真的變得輕量了，還是披著羊皮的狼？

　　EJB程式設計模型的簡化

　　首先，EJB3簡化的一個主要表現是：在EJB3中，一個EJB不再象EJB2中需要兩個介面一個Bean實現類，雖然我們以前使用JBuilder這樣視覺化開發工具自動生成了EJB2的這三個類，好像不覺得複雜，但是當EJB個數增加時，就顯得累贅了。

　　簡化後的EJB3的sessionBean依靠annotations元註釋來定義SessionBean的型別，也就是說，EJB2中的SessionBean型別區分在EJB3繼續繼承，只不過書寫程式碼的方式不同而已，例如下程式碼使用@Stateless表示一個無狀態Bean.

　　上述Session Bean中沒有了EJB2中ejbCreate等多餘方法，這樣TestSessionBean很象一個普通JavaBeans了。是不是簡單？先別急，我們需要接著看看這個TestSessionBean是如何呼叫？

　　在EJB2中，一個EJB物件的呼叫需要經過兩個步驟：JNDI尋找和工廠建立，如下例：

　　其實上述程式碼最後一句才是我們真正目的，但是為了這個目的，必須經過前面冗長的程式碼建立，而在EJB3中，為建立型模式的Ioc模式（或稱依賴注射）取代了home.create這樣簡單工廠建立模式，以一種更加鬆耦合和簡潔的方式解決了物件建立問題，可以讓我們精力更集中在物件的使用上了。

下面是annotations+Ioc/DI的EJB3呼叫程式碼：

　　上述EJB3呼叫程式碼中，@EJB後面是空白，這其實使用了TestSessionLocal的預設JNDI名稱，一直到這裡，我們一直滿足於EJB3的簡化，但是如果研究@EJB語法後，會發現其完整寫法如下：

　　上述完整@EJB寫法適用於同一個介面有多個實現子類時，其中關鍵是 beanName的定義：beanName是被呼叫EJB的類名 （不帶包名，稱為unqualified name ），或者， 如果被呼叫EJB有 XML descriptor定義， 它就是配置項ejb-name值（如果你使用過EJB2，就容易理解這個ejb-name了）。

　　@EJB還有一個屬性mappedName，這是被呼叫者的JNDI名稱，一般不使用，因為這個JNDI名稱和具體伺服器有關，如果是JBoss4，那麼它的預設形式是："EAR-FILE-BASE-NAME/BEAN——CLASS-NAME/local" （or remote）。 也就是：被呼叫者EJB所在EAR包的名稱/Bean實現子類（不帶包名）/local，如果是remote呼叫，就是remote. 如果這個EJB被打包在jar包中，那麼JNDI名稱就是EJB-CLASS-NAME/local and EJB-CLASS-NAME/remote，當然，作為替換@RemoteBinding 和 @LocalBinding 也可定義JNDI名稱。

　　也就是說：JBoss的EJB3中，如果你不使用XML配置，直接使用annotations，那麼JNDI預設名稱沒有一個統一規定名稱，有的可以直接是類名；在JBoss中還和EJB打包的形式有關，是動態變化的。如果你以為在EJB3中不會接觸到這個變化的JNDI預設名稱，那你就錯了。

　　JBoss 4 在Servlet中不支援類似EJB呼叫EJB那樣的依賴注射 binding-by-injection，因為Web容器和EJB容器是兩個不同容器，當然藉助另外JBoss Seam則是另外一回事，因此，在Web層呼叫EJB，就必須通過JNDI繫結一個session bean，這時，你就必須使用到那個變化不定的預設JNDI名稱了。

　JNDI Naming Context

　　無論J2EE還是Java EE中，JNDI是一個好像不起眼，但是極其重要的概念，不理解JNDI可以說，對J2EE或JavaEE只瞭解一半。

　　JNDI本來是EJB2中比較複雜的一個概念，不同容器有自己的JNDI名稱，由此EJB2引入了第三者EJB-Reference，雖然解決了程式碼中耦合JNDI名稱問題，但是又帶來了更加煩瑣的配置，這種現象當然被JavaEE5.0繼續繼承了下來，問題遠非這麼簡單。

　　J在Java EE5.0中（包括EJB3和Web環境），當我們需要訪問一個JNDI環境下資源時，有兩種方式：除了傳統EJB2中的JNDI呼叫方式；還有一種就是：使用依賴注射Ioc模式，這個依賴注射的表達方式是使用annotations.

　　因此，在EJB3中，必須好好搞清楚annotations、依賴注射和JNDI之間的關係，如果這個問題不弄明白，EJB3就絕非EJB2那麼容易搞定，當然，搞定了的結果很簡單，讓人感覺簡化輕量了，真不知道EJB3這種簡化是不是有點象“掩耳盜鈴”。

　　可以總結一句：凡是EJB2中使用配置檔案定義的；EJB3一般都可以使用 annotations定義（當然EJB3也支援配置檔案定義）；凡是EJB2通過JNDI尋找的資源（呼叫容器中其他EJB、呼叫環境變數等Resource資源等），都是可以依靠annotations+依賴注射機制完成。

　　JPA替代實體Bean

　　。如果說EJB3與EJB2變化最大的部分，就是持久層使用Java Persistence API 替代了EJB2的實體Bean，這樣，我們通過Evans DDD建模得到的Domain Model類可以直接持久化儲存到資料庫，不像EJB2中還需要在Model類和實體Bean中進行一次轉換。

　　EJB3引入EntityManager進行需要持久實體的查詢及其新增修改；EntityManager非常類似JDBCTemp/HibernateTemplate等持久化模板。

　　JPA和JDO以及Hibernate等O/R mapping框架都是非常相似的。

　　雖然在JPA中，我們都可以使用Annotation來替代配置，實現很多過去需要專門配置檔案才能實現功能，不再一定需要 每個伺服器不同的cmp對映檔案，增強了移植性，但是EJB3還是需要 一個叫persistence.xml配置檔案，在這個配置中進行資料庫JNDI配置；當然，還有一些和具體伺服器有關的配置屬性，如果使用JBoss，JBoss的JPA底層使用Hibernate實現，因此在persistence.xml要進行有關Hibernate屬性配置：