不过EJB CMT其实可以做得更好。EJB事务支持的另一个局限是：它与JTA驱动的全局容器事务绑在一起。尽管表面上看起来完全恰当，实际上这对于很多应用来说是杀鸡用牛刀。依赖全局JTA事务不仅带来了对EJB容器的依赖，同时还造成了对应用服务器所提供的分布式事务协调器的依赖，而后者仅仅在需要多个事务性资源（例如数据库）的时候才有意义。实际上，很多J2EE应用——甚至是那些非常复杂的应用——只需要使用一个数据库（可能是一个分布在集群上的数据库，例如Oracle 9i RAC），这些应用需要的仅仅是一个本地的、特定于资源的事务，当然声明性事务管理的好处总是存在的。
因此，可以同时适应高端和低端的轻量级、更少侵入性的事务基础架构才是真正的价值所在。例如Spring框架提供的基于AOP的声明性事务管理可以通过配置，在支持多个数据库的JTA、或者JDBC、或者其它的特定于资源的事务管理API（例如JDO事务API）之间切换，而不需要对业务代码做任何修改。这意味着你可以根据应用的需求选择最适合的事务管理策略——毕竟，如果你要做的只是一个单数据库应用，你就不需要具有JTA支持的高端的应用服务器。
而且，EJB CMT还可以做得更加灵活。只有当业务方法抛出一个非受控（unchecked）异常时，EJB容器才会回滚事务。非受控异常被看作是一个严重的问题， EJB容器会把它记入日志，然后销毁出错的EJB实例，并抛出一个EJBException（对本地客户端）或者RemoteException（对远程客户端）。如果抛出的是EJB规范定义的“应用”异常（RemoteException之外的受控异常），EJB开发者就必须调用 EJBContext.setRollbackonly()方法指定回滚策略。这样的处理方式不是我们通常希望的，如果能够指定“哪些受控异常可以直接触发事务回滚”就更好了——这样的自动回滚将不被视为程序错误。Spring的声明性事务管理通过“回滚规则”提供了这样的能力，这样做的好处在于：应用开发者几乎不再需要调用一个特定于框架的setRollbackOnly()方法。
远程调用
远程调用也是EJB——尤其是SLSB——证实了自身价值的领域。直到EJB 2.0为止，SLSB只能提供RMI远程调用；EJB 2.1增加了web service远程调用。EJB容器支持远程请求的能力，就像支持EJB实例的生命周期一样，是很有价值的，任何一个还记得如何管理自定义的RMI服务器的人都会同意这一点。
然而，正如我曾经说过的，很多人认为EJB规范混淆了远程和组件模型。这里最重要的问题是：很多时候，我们根本不需要远程调用。EJB极大地简化了远程调用，也使它成为了一种危险的诱惑——诱惑人们采用一种并不适用、而且可能非常昂贵的体系结构（昂贵在复杂性、工作量和性能上）。
在web应用中，将web组件和业务组件放在同一个JVM中几乎总是一个更好的主意。在这类应用中使用带远程接口的EJB无法增加任何价值，通常对于设计还是有害的。
集群
EJB常常被鼓吹为获得J2EE应用最大可伸缩性的不二法门。这种说法的理由之一是这样一种信念：为了获得比普通应用更高的可伸缩性，就必须采用分布式应用。另外一个信念是：EJB容器具有神奇的集群能力——商业EJB容器通常是昂贵的，所以期待其中存在某种魔力也是很合理的。事实上，EJB容器的集群功能并不是那么神奇，对于entity bean和有状态session bean的集群服务是相当有限的。
entity bean在集群中往往没有O/R映射解决方案（例如一个好的JDO实现）表现得那么好。在一个集群环境中，因为EJB容器的数据复制能力的局限，通常必须在每一个事务开始时从数据库加载entity状态。对比之下， Tangosol Coherence之类专门的集群缓存技术比应用服务器厂商所提供的复制功能更加强大。
有状态session bean的集群很容易引起问题，因为EJB规范本身就决定了它无法像Servlet API那样轻松地实现集群环境下的优化、减少节点间状态复制的次数。事实上，薄弱的集群能力已经被广泛认为是有状态session bean的致命弱点。
于是，关于EJB集群的争论最终归结到了远程无状态session bean。对于SLSB来说，它的所有实例都是相同的，并且可以互换。EJB容器只需要为远程客户端提供一个EJBObject存根，在其中用循环算法、基于负载的算法或者随机算法来提供负载均衡。但借助Cisco负载均衡管理器这样的设备，也可以在硬件级别很容易地实现负载均衡（而且很可能效率更高）。
问题的关键在于，集群的主要用途并不在于J2EE web应用的业务对象层。在下列位置的集群服务通常更为重要：
Ø web 层。通常必须在这里管理session状态，所以有必要设计一个路由方案。如果不需要保存session状态，一个web farm[2]风格的解决办法通常是最有效的。
Ø 数据访问层。
Ø 数据库。
