曾经和一个憎恨EJBs 喜欢POJOs Java的开发人员就web容器进行了一个有趣的讨论，我必须查看他的体系结构，然后询问他的解决方案
I:你如何解决transactionality？
Developer:很容易。我仅仅实现一个本地线程。我在我的servlet中打开事务，在本地线程里存储连接。我的DAOs从本地线程里取得连接并使用它。
I:不错。实现这个解决要花多久呢？
Developer:测试和文档仅用2天。
I:好。你们有一些监控要求吗？
Developer:是的，我们有。我们用动态代理和一个factory实现一个简单的解决。我现在能监控方法。我将decorator和Log4J ->联系起来，它工作的很好，我只用一天就完成了。
I: 你需要持久性吗？
Developer:是的。但我不喜欢CMP 2.0，而且Hibernate也太复杂。我实现我自己的轻量级的DAO解决方案。通过利用反射我映射数据库纪录到Vos，它比OR-stuff更容易。我仅花了2天完成整个框架。非常容易。
I:它是事务性的吗？
Developer:当然了。
I:如果在同一个事务中，你请求同一个对象2次，会发生什么呢？
Developer:你将得到2个实例
I: 因此它不是事物的。你应当小心。整个体系会变得不一致...
Developer:真的吗？我也能实现一个事物的一级缓存—它只是映射...
我们也讨论了其他问题，像线程，扩充性限制,实时监控等。在每一个必需的方面他都提供或完成一套自己的方案。我最终同意他的设计，因为很清晰而且开发者真的很有经验。但是代码是清晰干净的却不可维护！一些Java开发者并不知道本地线程是什么，又是如何工作的。
在这个对话中没什么特别的。如果你仅考虑到开发阶段，EJBs似乎太复杂。如果你也考虑它的非功能性方面，它变得更加有趣。只有较少的开发者关心实时监控(JSR-77)，线程，合适的加载平衡等。如果你在产品中正使用POJOs，你将仅仅看到你的servlet，你不会知道你的应用正在做什么。所以EJBs一直很复杂，但复杂性有它的根由，它并不在EJB spec里而是在实际中，那就是我们大部分都在开发分布式和事务性的应用。
EJB 2.1并不优雅，有一些设计缺陷（例如，在EJBContext 中的getPrimaryKey方法仅仅当你在一个CMP 2.0情况下才能被激活 ），你必须记住一些规则（例如，远程方法必须抛出RemoteExceptions异常等），但它不复杂。有经验的Java开发者能布署一个CRUD J2EE 1.4应用在大约半个小时内(Ant+Xdoclet)。
EJB 3.0真的很了不起，但也不容易。参看我的entry "Nothing Is Transparent" （没有什么是透明的）
specs J2EE 1.4 和 Java EE 5都很好，但Java EE 5更好，更干净