资源池
在J2EE（或是其它三层应用）的缓冲池中，真正有价值的是资源池，而不是业务对象实例池。例如，将数据库连接放入缓冲池中，以避免在加载时耗尽连接，这是企业应用的基本策略。应用服务器也必须将执行线程放入缓冲池中，以防备拒绝服务攻击或是大负载时的失败。
然而，这样的资源池可以由J2EE应用服务器（而非EJB）提供，因此不必与EJB容器绑在一起。这样一来，任何一个运行于J2EE应用服务器中的对象（例如一个Servlet或者普通的Java类）都可以获得数据库连接池。在web应用中，web容器会在应用服务器的入口处强制使用线程池。并不需要用更多的线程池来保护业务对象，除非它在分布式应用中运行到了进程之外。
安全
另外一个EJB宣称提供的服务是安全管理。开发者可以在EJB部署描述文件中进行方法级的、基于角色的安全性配置（和Servlet API一样，EJB也支持编程性安全管理，可以在代码中检查一个通过了身份识别的用户是否具有某个特定的角色）。
单是捧着J2EE规范看看，这的确是很好，但实际用起来就不是那么好了。我见过不少J2EE应用有复杂的安全需求，它们大多发现J2EE安全基础架构根本不够用。这些应用没有一个能够依赖EJB的声明性、基于角色的安全：原因大抵是基于角色的安全不够用，或是需要一个动态安全凭证检查的级别、而 EJB没有提供。这很大程度上是J2EE安全基础架构的问题，而不是EJB的，但仍然抵消了“安全性”为EJB挣来的分数。
声明性安全性确实有其价值，唯一的问题是：EJB的安全性服务必须绑在标准的J2EE安全基础架构上，而这些基础架构仍然无法满足复杂的需求。更好的办法是使用AOP来实现声明性自定义安全性：一般的做法是将安全凭证保存在一个ThreadLocal对象（而不是J2EE安全上下文）中，再用一个自定义的安全拦截器包裹在需要安全性管理的业务方法周围。
对于安全需求比较简单的web应用，通常在web层检查用户身份就足够了，例如借助Servlet API的声明性（基于web.xml）或者编程性基于角色的安全性。在web层实现声明性安全管理的其他方法还有：向需要保护的内容周围添加 Servlet filter；借助WebWork2和Spring之类web框架中的拦截器；或者在web控制器中使用AOP拦截器。Spring等框架不仅提供了 web MVC功能，还提供了AOP功能。
业务对象管理
最后，EJB容器也是一种工厂：它借助JNDI为服务对象（通常是SLSB）提供目录服务。EJB部署描述文件提供了一个从服务名称（JNDI 名称）到实现对象的映射，从而消除了业务接口（EJB的组件接口）与实现类（EJB实现类）之间的耦合。
这种解耦是一个好的编程实践。EJB的一大优点就是强制调用者使用业务接口，而不是直接使用实现类。随着EJB在实际工作中被广泛采用，它也在无意中普及了“针对接口编程、而非针对类编程”的原则。不过，EJB并不是达到“分离接口与实现”的唯一途径。
Java语言把接口作为头等公民来对待[3]，从而提供了完美的解耦能力。不过，如果在Java代码中明确指定“使用接口的哪个实现类”，那么针对接口编程带来的好处也就被抵消殆尽了，因此我们需要一些基础设施提供帮助，从而可以在Java代码外部选择接口的实现类。EJB容器就是这样的基础设施 ——但不是唯一的，更不是最好的：有很多更加轻量的容器可供选择。Spring框架以一种非常轻量的方法帮助开发者实践“针对接口编程、而非针对类编程” 的原则：它所提供的通用工厂可以根据配置（而不是Java代码）来按名字获得对象实例。如果想要切换某个接口的实现类，你只需要编辑一个简单的XML文件。另外，还有别的轻量级容器也可以达到类似的效果，而不需要EJB的复杂性，例如PicoContainer （www.picocontainer.org）。
由于Spring和PicoContainer是如此轻量级，因此它们比起EJB来更适合管理细粒度的业务对象——而EJB则只适合那些粗粒度的组件。对于细粒度的对象来说，实现、部署EJB和使用JNDI访问的开销太高了，即便这样可以使它们拥有“在不影响调用者的前提下切换实现”的能力也是得不偿失。换句话说， Spring和PicoContainer这样的轻量级解决方案能够提供一步到位的工厂功能；而EJB只适合一部分应用场景，常常需要由组件facade 之后的某种轻量级解决方案来补充。
