相关讨论：
http://www.jdon.com/jive/thread.jsp?forum=46&thread=23302

B 负 |--HTTP SERVER1--TOMCAT1--|\ Tomcat使用JSP/Servlet+JavaBean
B 载 | | \ (NO EJB)+Hibernate
B 均 |--HTTP SERVER2--TOMCAT2--| \
B 衡 | | \ DABABASE
B 软 |--HTTP SERVER3--TOMCAT3--| /
B 件 | | /
B |--HTTP SERVER4--TCOMAT4--| /

在Linux上使用Linux的负载均衡软件，比如（Linux Virtual Server，即LVS）
请赐教

我再次重复一下我的观点：
EJB集群是组件方法级别的集群，这是一种细粒度的集群，因为EJB是一种组件架构，你在Web层能有到POJO的方法集群吗？现在Spring提供POJO方法事务，还没到POJO方法集群呢。

你在下面这个网址：
http://e-docs.bea.com/wls/docs81/ejb/understanding.html
搜索"method level and home level" 会有一个table，对EJB这两个级别的集群进行总结，总结网址如下：
http://e-docs.bea.com/wls/docs81/ejb/understanding.html#1128703

组件方法集群这种细粒度经常会需要使用，你认为没必要用，只是他的实践没有达到这个要求，如果你要求不高，EJB都可以不用呢，就是这个意思。

请老板给大家解释解释，如果“细粒度集群”这么宝贝，为什么大家都用 SESSION FACADE, DTO 来粗化粒度，为什么J2EE规范推荐细粒度场景下使用 LOCAL EJB INTERFACE 而不用远程EJB, EJB3 又为什么取消了REMOTE ENTITY，就行了。

我也不哭，我特喜欢看你到处 GOOGLE 来那些不相干的答案。搬出 BEA 的 EDOCS 有什么意义，对 WEBLOGIC 你还没入门呢。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
那我们就来看WEB粗粒度，EJB细粒度这个假设，或者模型的“有用性”有多少。

今天的J2EE应用，大概少不了SESSION FACADE模式。说到这里，明眼人应该已经明白我的意思了。如果你有耐心，再听我细说。

EJB的细粒度，尤其是REMOTE EJB的细粒度，事实上被生产经验证明是系统性能的杀手。这个经验观察导致了两个结果：LOCAL EJB 标准, 和 SESSION FACADE模式。

SESSION FACADE的根本意图，正是把REMOTE EJB编程粗粒度的组件。
而细粒度的LOCAL EJB，根本不具备远程调用的能力，更无从谈起集群。

也就是说，远程EJB细粒度这种作法，是一种典型的，广泛被批评的J2EE ANTI-PATTERN。所以，WEB粗粒度，EJB细粒度的模型，或者假设，可以说基本没有实际价值。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

我搬出这些文档，是因为你以前要我找证据啊，我说EJB集群可以平衡CPU处理能力，你让我给你指引，我说EJB集群是靠方法集群来达到CPU处理能力，因为你当时对EJB集群是方法级别集群概念一无所知啊。

现在我们的讨论已经到了要校验对方言论的地步，这种讨论已经没有意义了。

你对EJB方法级别的集群总是认为是实体Bean的方法级别集群，而实体Bean一般是被绑定在本地JVM的，所以你就认为整个EJB方法级别集群是无意义的。

EJB还有一个会话Bean，会话Bean不能调用会话Bean吗？会话Bean包含大量业务逻辑代码，才真正需要集群。当然不是所有的会话Bean都需要满网络得找，但是我们可以指定个别的会话Bean为集群，这样可将负载分担出去。

Web层的HttpSession导致的failover是存在的，但是Bea架构师早在TSS上专题采访中说过，尽量勿采取HttpSession。

所以Cluster中的failover几乎不太起作用，但是你的有状态机制不使用HttpSession，还要有一个东西实现啊，那么就使用有态Session Bea，在我的Jdon框架中，也提供POJO下无态和有态，但是这个POJOService是不能集群的。

另外，我觉得有兴趣的人想知道我的水平，看看我的Jdon框架便知有没有，提出疑问，很多设计有相当知识背景的。

我从来没有认为过“EJB方法级别的集群。。是实体Bean的方法级别集群”。 我早就说过，实体BEAN 根本不具备集群能力，又怎么可能说出这样出尔反尔的话？

不知道 BEA 哪个“架构师”在什么时候什么场合下说过尽量不要用 HTTPSESSION。2002年以前业界同志们还认为实体BEAN是好东西呢。呵呵。

我只知道，BEA自己的产品，里面极端少见用到有态SESSION BEAN。这很容易验证，下载个 WEBLOGIC，打开PORTAL目录下的JAR，数数有多少EJB，其中有多少有态SESSION BEAN。

我只见到一个，就一个有态BEAN，在无数的无态BEAN里，只有一个。呵呵。要是BEA在自己的产品中贯彻自己的理念，那么这个现象说明，至少WEBLOGIC PORTAL 的架构师是不喜欢用有态SESSION BEAN的。呵呵～～

并且，我觉得作为 SPRING 的吹捧者（呵呵，或者说信奉者），同时又吹捧有态SESSION BEAN，老板实在是罕见人物啊～～～ 连 ROD 本人都在其经典大作里再三对有态SESSION BEAN嗤之以鼻呢。

我同意你上面提到的那个场景“会话BEAN调用远程会话BEAN”是EJB集群的一个适用场景。

我早等着你提出一个以“远程EJB”为核心的应用场景，不光是客户端是BEAN的场景，还包括客户端是 STANDALONE, 或者是 BPEL，或者远程 WEB CLIENT。你要是早提这些场景，我早赞成了。可惜你说来说去，总围绕着 WEB 应用，那我也只好继续在 WEB 应用 上缠。其实，问题的关键就在于“远程EJB”的合理性。如果“远程EJB”是一个需求，或者合理设计，那么EJB集群是自然而然的。问题就在于，对于绝大多数项目（WEB APP + EJB），这个设计很少是合理的。

我的中心论点，本来就不是说 EJB 集群完全没有一点作用，而是在大多数场景下（WEB + EJB共同部署），它不但没有作用，而且没有物理意义。

我曾经亲身经历过一个公司的产品，当时有严重的性能问题，我（和其他几个同事）的第一个直觉意见就是分出"远程有态EJB"，减少HTTPSESSION。当然，我并不是说这个设计方案应该被广泛应用。事实上我对采取远程，或者有态EJB都持严重保留态度。但是那个产品极端庞大复杂，并且不可能在短期内大规模重构。在那个特殊情况下，远程有态EJB是一个可行的“近水解近渴”的方案。但是这种特殊情况不是每天都能撞见的。

> 欧在这里替老板说句话，呵呵。我想banq的意思重点不是说把
> jb搞细，做成细粒度的东东。而是说，不管我这ejb多庞大，?
> 一个ejb总比你一个web
> application要小吧，所以我就可以利用这一点，灵活的按照e
> b的访问量和cpu占用等决定它要几个机器作集群，而web
> app肯定做不到这一点。
> 嗯，不过翻开老马的POEAA分布式一章，那个反面的例子就是?
> 么讲的，提出这种想法的架构师搞得老马很无奈。于是，书里
> 吞岢隽? 分布对象的第一定律：8要分布你的对象……

老板这句话说的经典啊！！！