很多Java开发人员不了解EJB，而实际应用中，普通的网站开发没有必要而且不应该应用EJB，企业级的项目才有应用EJB的需求。EJB成为Java学习中一个高端领域，而其应用领域的限制，又有太多的人对它望而却步。
除去EJB的应用范围问题外，EJB1.0、EJB2.X自身的缺陷也非常明显：
1、性能不佳
越使用 EJB，越让人气馁，虽然不断地优化和调校性能，但总是无法让人感受到性能上的优势。而为提升性能，硬件支出的成本也相对增加了许多，让开发与使用单位面临到更多成本支出的压力与无奈。
2、开发不易
虽然Java应用开发领域不缺少优秀的IDE，而透过这些IDE，大量的代码可以被方便的自动生成，但是需要大量无意义的接口和类充斥你的视线，开发EJB的吸引力由此黯淡了不少。一个 EJB 必须具备Home Interface、Remote/Local Interface 以及 Bean 本身，复杂的逻辑使得很多人不愿接受挑战。
3、 测试耗时
编写完一段EJB代码，我必须将它部署到具体的应用服务器 ( Application Server )上，才能开始测试。这种耦合度极高的测试方式，在分秒必争的软件开发之中，显得非常愚昧，很有可能你整天的工作就是发现一个错误，修改打包后再部署它，最后测试时才又发现必须修改其中的部分程序代码，由此产生的工作极端耗时耗力。
4、EJBQL 功能不完善
EJBQL 提供了一种基于对象的数据库操作语法，完成的是O/R Mapping 的工作。虽然提供了对标准SQL的支持，但EJBQL缺少了许多必要的查询功能，例如 JOIN, SubQueries 等等。
5、复杂的 Deployment Descriptor XML 的编写
EJB的开发部署和使用离不开ejb-jar.xml，我们通过它来设定相关的属性。每种应用服务器对都有自己独立的EJB实现机制，因此每种应用服务器都会需要额外去生成另一个符合自己特征的XML文档。项目规模一旦增大，XML文档的文件大小以及相应的复杂程度就会不断增加。
EJB早期版本的缺点就不再赘述的，读过《J2EE development without EJB》的人基本上都能够接受作者的思想，spring等轻量级框架的出现为多数的非分布式环境提供了EJB的替代性方案。
现有的环境似乎意味着EJB将要消亡了，然而实际开发中尚且存在的少量应用EJB的场景又不断地宣告着自己的需求。哪里有需求，哪里就会被满足。既然EJB的现状存在问题，既然它仍旧有市场需求，于是变化便产生了。EJB3.0应该算是EJB的新生，以简化开发为己任的它吸引着人们的目光。
最近浏览JSR文档的时候，翻阅了关于EJB3.0的部分。最初制定EJB3.0标准时，设定的目标如下：
1、在EJB中应用元数据Annotation，简化开发者的工作，减少需要实现的接口和类的数量，从而简化XML中的EJB部署描述。
2、提供默认编码机制，减少繁杂的重复工作。
3、通过Annotation、依赖注入、简化lookup机制等方式，封装环境依赖和JNDI访问。
4、简化企业Bean的类型。
5、消除session bean对home接口的需求。
6、通过轻量级领域建模，简化持久层API。
7、消除持久化实体对所有接口的需求。
8、规范化Annotation以及基于O/R Mapping的XML部署描述。
9、提供对标准SQL的全面支持，增加对动态查询和native SQL的支持。
10、为session bean和message-driven bean提供interceptor。
11、减少对可捕获异常的使用需求。
12、消除对callback接口实现的需求。
这么多目标列举在这，大家可以发现，目标不过是分为几类：
1、应用metadata Annotation和默认机制以及现有轻量级框架，简化代码量。
2、消除对一些接口的需求，从而简化编程逻辑。
3、适应技术发展的趋势，提供新功能支持。
EJB3.0的变革能力来自于J2EE5.0以及众多优秀的轻量级框架的出现。当EJB的开发足够简单时，学习和使用者的数量增加足以推动它被广泛的使用。
EJB3.0标准一再强调的是，无论EJB2.x还是EJB3.0，应用服务器厂商应该提供的是一种兼容的环境，确保它们能够等价被等价对待，能够被混合使用。
虽然各大应用服务器厂商纷纷提供了EJB3.0的preview支持，但离正式版本的发布还有距离，期待EJB3.0正式被开发社群接受的那一天。