EJB的RPC是同步调用可实现分布式计算，是SessionBean和EntityBean用的，而JMS是异步调用。RMI，和webservice也可以实现分布式计算。

举例说明，假设我们的系统有三个EJB组件：人事、财务、销售，都是开放远程接口，有A、B两台应用服务器，EJB分布式的概念就是可以在A上部署人事、财务的EJB包，在B上部署销售的EJB包，假如有一天用户发现负载不太均衡，就可能调整为在A上部署财务的EJB包，在B上部署人事、销售的EJB包，而程序不必修改。 

而应用服务器集群是这样的，在A、B上都部署全部EJB包，当然还需要在服务器上进行一些集群的设置，这样一来，负载均衡就完全交给应用服务器来管理了。 

至于集群是否足以替代分布式部署(注意：不是分布式计算)，正是大家争论的焦点。

EJB解决的是分布式计算问题，不是群集问题，就算你用EJB，你照样无法做到缓存同步，Session同步，分布式和群集是两个不同的概念

主要看具体是什么集群。现在有些用F5之类的负载均衡器的应用也被叫做集群，还有双机热备（部分人也把它叫集群，其实只有一台机器在工作，另一台是备份机，平时不参与业务，只有主机不能提供服务的时候，备份机采工作）。还有用一些JVM集群缓存软件构件的集群。这些集群每台机器一般都需要单独部署。因为使用F5负载均衡和双机热备的，其实是一台台单机。JVM缓存我没有用过，不太清楚。不过估计应用服务器自己并不知道还有其他机器和自己同步。 

标准的JavaEE集群一般分两种，war集群及EJB集群。war因为考虑到Session复制的问题，一般不推荐做大集群。不过用来做2-3台的廉价入门集群还是可以的。 
EJB集群一般在上面部署的都是EJB组件。不同厂商用不同的办法来保证有状态SessionBean的集群复制。比如Weblogic采用双机结对、Sun使用特殊的数据库同步。一般有一台专门的代理管理服务器负责对整个集群的管理，所以在这台管理器上进行部署就可以了。 
应用在集群上面跑和在单机上面跑是完全不同的两个概念。很多单机上可以使用的框架和设计模式在集群环境下是绝对不能使用的。比如单例模式。集群环境下根本无法再集群中只有一个单例，每个服务器都会有自己的单例。还有就是Spring，Spring目前是不能用于标准的JavaEE集群环境下的（因为spring里应用了很多singleton模式）。当然，有人推出了Spring的集群框架，不过我不太清楚是否好用。AOP配置集群的话，估计会很复杂。

标准的JavaEE集群，一般情况下是这样的。 
入口是一个负载均衡器（有时候也用apache之类的），然后是若干台web服务器（如Tomcat），再后边是EJB集群。最后是数据库。 
这是JavaEE集群模型的标准构造。JavaEE集群的核心是EJB集群。但是如果应用没有达到足够大的规模，且设计不好的话，会产生很多问题。这也是当初为什么老EJB架构被人诟病的地方。 

单机应用是中小型项目的主流。我们在中小型项目中一般只用到事务处理，分布式、容灾等功能一般用不上。所以Spring才会发展这么快。但是企业在发展，当初用Spring开发的程序需要跑集群了，结果发现无法在集群上使用，所以才会出现用AOP方式对Spring添加集群和JVM分布式缓存来进行集群化的方案。但即使如此，很多单机下可以使用的代码，在集群下可能是根本无法跑的。单例、静态对象等等，在集群模式下会出现各种问题。 
所以，现在很多人都只用F5和Apache做分发器，后边跟一大堆互不往来的Tomcat之类的Web服务器。这么做最大的问题是无法使用缓存。因为如果使用缓存，那么其他机器更改了数据库的话，缓存无法刷新而形成脏数据。结果大大拖累了性能。 
如果你的应用是中小型低负载应用，那么可以只考虑单机。如果以后要使用集群，可以先用Spring集群（好像是叫Cluster4Spring）和JVM分布式缓存。如果应用大到必须分布式的程度，那么还是更换成EJB架构吧。