J2EE領域熱切的盼來了一種非常流行的開源技術，它就是Hibernate。這個技術被提升到JCP（一種Java規范組織）標准中去了。從J2EE開發者反饋的信息來看，掌握Hibernate知識是所有想在J2EE領域有所作為的人的必修課。
Hibernate是一個對象關系映射的技術。它是一個開源，並且免費的技術，由SourceForge. Net開發。在過去，有許多的類似的對象關系映射技術。TopLink就是這樣的一種工具，後來被Oracle所采用。來自SourceForge的Hibernate和Apache的OJB也都是非常知名的對象關系工具，開源並且免費。JDO也要被歸為這一類。
Gavin King是Hibernate的負責人，而Craig Russell 和David Jordan是JDO的主要設計者，JDO是由SUN牽頭做的。由於一些技術的原因，今天JCP規范中的大多數成分有利於Hibernate，而不是JDO。從表面上它們沒有什麼區別，語法和一些處理方法看起來大多數相同，但是，Hibernate的語法更簡單易學。
非常有趣的是Craig Russell為SUN工作，而Gavin King 為JBoss工作。資料表明JCP是一個非常民主的社區組織，SUN並沒有強制規定一些條條款款，保護自己的語言和企業級的用戶。
EJB-3是目前最新的版本，很大程度上受到了Hibernate的影響。一些讀者將EJB-3 和Hibernate等同起來。Oracle支持EJB-3提議，而它是j2ee領域中重要的數據庫公司，那麼EJB-3前景就會很好。從J2EE這個名字本身，就能看出它是一種企業級的技術，並且EJB本質上就是針對這些企業級的應用，由於存在提供的內置容器服務，只有Hibernate和EJB聯合使用，Hibernate才能凸顯其重要性，因此Hibernate轉向到EJB是不可避免的。
EJB有三種類型的Bean。一種類型是會話Bean，存在於企業容器中，可以被認為是一種功能Bean，以RMI-IIOP方式調用。
ORM工具有時和會話Bean一起使用。最近主要的問題是過去ORM工具具有所有權的、價格昂貴的問題。但是現在，可靠、開源的ORM工具可以得到，並且Richard Monson Haefel承認使用ORM工具，替代實體bean，是一種非常安全、並且很有開發效率的方法。
另外一個類型實體Bean就沒有這麼走運了。EJB-1. 1、 EJB-2. 0和隨後的EJB-2. 1在關於實體Bean規范方面做了許多的改變。
我們能夠說實體bean是一個“Attribute bean”或者'property-bean'，帶有setter 和getter方法，以RMI-IIOP方式調用，存在於企業容器中。定義一個Javabean的方式是Java中經常提到的話題。同樣的方式也要出現在BDK,、EJB-Entity beans,、Struts、JSF 和現在的Hibernate技術中。所以，如何定義Javabean是非常重要並且很有藝術性的。
第三中類型就是通信和MDB。從企業這兩個字就看出這裡面應用程序裡面涉及了很多的用戶和並發事務，RPC形式非常像打電話，容易導致“占線”問題。如果你所呼叫的人正在給別人的打電話，那麼這個時候就導致了線路阻塞。但是，通信的樣式中，如在email中，至少要保證信息發送出去。很明顯RPC是不合適的，被誇大了。有時，我需要即時響應。由於一些原因，即使像XML web服務，如果問題很嚴重的話，也應該采用同新樣式。MDB（消息驅動bean）事實上越來越被接受。
因此，為什麼單單實體bean發現不合格，並且規范老在變呢？
實體bean有兩種類型。CMP和BMP兩種。
CMP指的是容器管理持久化，而BMP指的是Bean管理持久化。理論上說，EJB規范並沒有規定你采用何種方法來持久化你的對象。你也可以簡單的將對象串行化。數據庫可以是對象數據庫或者是關系對象數據庫，或者是XML的。但是，在實際中，數據庫經常是指關系數據庫，使用SQL。
在CMP中，編碼員只是在存儲器中處理對象。創建新對象，修改它們，刪除它們，和查詢它們，所有都是在存儲器中進行的。保存這些對象到關系數據庫表格中去的任務由容器自動完成。編碼員不需要些任何的與SQL相關的代碼。
在BMP中，編碼員不得不寫SQL語句來持久化對象到關系數據庫中。
EJB1. 1版本的CMP適合簡單的表格，和其它的表格沒有復雜的關系。CMP避免對底層數據庫的引用。因此，它是很具有可移植的。CMP除了能將數據庫持久化到關系數據庫中之外，還能持久化到對象數據庫中去。
但是，CMP並不是適合所有的情況。如果數據庫是先前遺留的類型的話，如不能使用SQL，數據庫公司提供了自己的代碼來持久化，並且這些代碼在我們的編程中用來持久化數據，這樣的情況就不適合了。
但是，真正的問題在於CMP使用了ORM概念，雖然很多的實現迫切需要。它並沒有暴露EJB開發商到底實現了多少規范。Weblogic, Oracle, IBM WebSphere, SUN , JBoss都是實現了CMP中他們認為適合的部分。使用CMP是不錯的，並不僅僅因為它使得代碼可移植，很容易寫。如果我們采用CMP，更多的原因是EJB容器能夠極大優化性能。因此開發社區希望采用CMP，但是發現CMP不適合復雜的任務。
雖然做了一些改進，但是發現CMP不能成為最終的解決方案。它裡面沒有繼承性。
雖然EJB容器所提供的服務在真正大的企業級的應用程序中是不可或缺的，但是J2EE陣營仍讓垂直的劃分為兩個層，Web層和EJB層。支持Web層的聲稱EJB的陡峭的學習曲線和容易發生錯誤的開發環境對於大多數的應用程序是不需要的。他們喜歡有一個對象關系映射工具構建到J2EE規范中。並不是只有在EJB存在ORM任務，甚至在Servlets、JSP也在使用他們，只不過J2EE規范沒有對此做規定。ORM工具如OJB, JDO 和 Hibernate不只是能夠用在EJB容器，還可以用在web容器和一個獨立的容器中。使用這樣的工具，J2EE標准就會使得開發任務簡單，無論是開發web層的應用程序還是ejb層的應用程序。
在嚴厲的攻擊EJB實體Bean的復雜性和性能時，Rod Johnson預言在今後幾年，J2EE將會終止EJB的使用。無論我們同不同意他的觀點，我們還是很有價值去看看他對EJB實體Bean的一些批判。他提議將Spring框架作為EJB容器的替代品，並且這個觀念影響力正在擴大。
