总结：EJB的服务
上面所讨论的服务大多已经被加诸所有类型的EJB，然而除了SLSB和MDB之外，别的EJB（尤其是entity bean）并不经常使用它们。例如，处于性能考虑，几乎任何场合都不会使用entity bean的远程接口。为entity bean提供事务管理也是毫无意义的：经验告诉我们，最好把entity bean设计成不包含业务逻辑的哑数据访问对象，而这样的对象不需要任何事务管理。
EJB帮助证实和普及了很多有价值的想法，但这并不意味着EJB的实现就是完美的。我们需要的解决方案原本可以不必这么复杂，这正是EJB的轻量级替代品出现的原由。有了过去七年的经验，以及从.NET中学到的东西，我们现在有机会既吸取EJB的优秀之处又避免其缺陷。我们可以拥有SLSB的一切长处，同时又避免所有不必要的复杂性。
EJB的现状
EJB仍然有其位置，但比很多J2EE开发人员所认为的位置要少得多。我可以确信，就在不长的几年之后，EJB将被归入“遗产系统”之列。然而，如果符合下列条件之一的话，现在使用EJB也是恰当的：
Ø 你在开发以中间件为核心的应用，其中web界面只扮演很少的角色，并且需要一个分布式（而不是简单的集群）体系架构。很多大型金融应用符合这个描述。然而，分布式体系结构常常被滥用，导致性能的损失和复杂性的提升，而没有带来任何真正的收获。
Ø 你想要开发一个基于RMI的分布式应用。EJB是达到这个目标的最简单的技术。
Ø 你确实需要有状态session bean，不能借助HTTP session对象或者厚客户端来满足这个需求：譬如说，你必须同时保存多种客户端的状态。在真实项目中，这种情况是相当罕见的。
你不需要使用EJB来满足下列需求——它们常常被误认为是需要使用EJB的理由。
Ø 事务需求。事务协调器是由应用服务器（而非EJB容器）提供的。EJB CMT确实很好（特别是当与SLSB同时使用时），但我们还可以做得更好。
Ø 多线程。编写适用于多线程环境的无状态服务对象并不困难。如果需要缓冲池，Spring可以提供，并不需要EJB。
Ø 资源池。这也是由J2EE（而非EJB）提供的。
即便不使用EJB，你也可以享受这些服务，而且不需要开发你自己的基础架构代码。
如果恰好有非常熟悉EJB的开发人员，你或许想要使用EJB。然而，由于EJB的复杂性，很多有EJB开发经验的开发人员实际上缺乏关于EJB的深度知识，而一知半解很可能是一件危险的事情。
我希望你从本文中得到的信息不止是“EJB是一种糟糕的技术”，更重要的是判断是否使用、何时使用EJB所需的基础知识。你应该能够为自己准备一个核对清单，用来检验EJB是否能为应用提供价值。如果所有条件都满足，就放心地使用EJB吧。
