问题描述
可能是比较老的问题了。我目前的水平还理解，用过EJB的，能不能结合你的项目说说使用EJB后，和不用EJB相比，都带来了哪些好处？在网上查，很多说为了分布式，集群，问题又来了，什么情况下需要分布式呢？Apache+Tomcat也可以做集群啊？（我也没做过，网上看的）。知道的来说说吧，好长时间都没弄清楚的问题。。
解决方案
在设计J2EE应用时，最重要的设计决策之一是用不用EJB，EJB常常被理解为J2EE的核心，但这是不正确的说法，其实EJB只是J2EE提供给我们的选择之一。它在某个领域中适合解决某些问题，但是在许多应用中只起到很细微的作用/价值。当业务需求明确指出需要一个分布式体系结构，而且RMI/IIOP是必然的远程化协议时，EJB给我我们一个标准的实现。我们可把自己的业务对象模型编写成具有远程接口的EJB，并可以使用EJB容器来管理这些EJB生存周期和处理远程引用，这比使用RMI的定制解决方案高级的多，因为RMI要求我们管理服务器端对象的生存周期。如果业务需求没有指出需要一个分布式系统，或者RMI/IIOP 不是必然的远程化协议，是否使用EJB的决策将会变得困难的多。EJB是一种高端的技术，它在解决某些问题非常好，但不应该没有理由地使用它,我们应该冷静客观地看待使用EJB的影响，以及对是否使用EJB的决策将会产生影响的重要考虑.EJB规范的关键目标之一是简化应用代码。EJB2.0规范规定EJB体系结构将使编写应用变得更容易，应用开发人员将不必了解低级事务所和状态管理细节、多线程化、连接池、以及其它复杂的低级API。理论上讲，通过把所有低级问题都推组EJB容器，开发人员能够把他们的精力都投入到业务逻辑，但现实几乎是，使用EJB给应用增加的复杂性与消除的复杂性至少是一样大的。EJB技术对我们实际工作中的影响: · 使用EJB使应用变得更难测试 · 使用EJB使应用变得更难部署 · 复杂的类装入器 · 复杂的部署描述符 · 使用J2EE的大多数挫折与EJB有关，这足以让我们有所重视。 ·使用具有远程接口的EJB会妨碍OO设计的实施 ·不必要地使用具有远程接口的EJB所导致的后果 · 由最小化远程方法调用数量的要求所决定的接口粒度和方法签名。如果业务对象本身是细粒度的（情况常常是这样的），这将导致不自然的设计。 · 对串行化（决定将通过RMI进行通信的对象的设计）的需要。我们必须决定应该随每个可串行化对象一起返回多少数据。还必须编写另外的代码从任何不可串行化的对象中 提取远程客户所需要的数据. · 远程引用时应用业务对象中的不连续性。 （这些缺陷在我们真正需要分布式语义时不适用，当需要分布式时，EJB不是问题的诱因，而将会是分布式应用的一个优秀基础结构。但当不需要分布式时，如果使用EJB会使一个应用变成分布式的，那么使用EJB会有一个致命的结果。这样分布式应用比在单个服务器中应用复杂得多，EJB也就增加了我们可能希望避开的一些额外问题。） · 使用EJB可能会使简单的事情变得很困难。 EJB是一种重量级技术，而且使一些简单问题变成繁重的工作。 · 应用服务器选择的减少 WEB服务器比EJB容器多，而且WEB服务器往往比EJB容器更加容易使用。因此，与EJB相比，WEB应用可以运行在范围较广泛的服务器上或相同服务器的较便宜版本上，且配置、部署非常简单。但如果换成是EJB，那么成本问题，而且EJB容器可能已通过在其它项目中的运用为我们所熟悉。 · 我们要更多的时间来关心和注重实践·EJB 是分布式应用和复杂事务管理问题的一个上佳解决方案。但是，许多应用没有遇到这些问题，EJB在这样的应用中增加了不必要的复杂性。一个EJB解决方案可以比喻为一辆卡车，而一个WEB应用服务可以比喻为一辆小轿车。当我们需要执行一些像搬运大型对象之类的任务时，一辆卡车会被一辆小轿车高效得多。但是，当一辆卡车和小轿车做相同工作时，小轿车的灵活性、更容易操作！