从技术上讲是可以的。
关键风险问题不是技术,而是你当初编程思路。
需要搞清楚你的负载压力在哪里?在应用服务器tomcat/j2ee服务器上,可以使用EJB集群;如果当初是数据库编程思路,使用SQL完成复杂的业务计算,那么负载显然在数据库上,使用EJB集群就无法解决问题了。
如果你当初选择Spring时,就能够明白这些道理,相信现在移植就很轻松,否则,可能你的系统需要重写。这就是我在这里一直强调DDD和OO设计的目的所在。
有些人一直这句话:80%的项目是中小型项目,因此不需要EJB。
需要不需要与懂不懂EJB是两个问题,如果因为80%项目不需要EJB,就认为不需要了解EJB,以及在做架构时,根本不知道EJB存在,那么很显然范了无知无畏的毛病。
我以前一直在说这么一个道理,人们不可能预测未来,有的只是对现有结果总结,是马后炮定理,马后炮定理根本不能指导我们实践。80%项目不需要分布式计算是一个现实结果,但是你怎么知道你还没做出来的项目将来就肯定属于这个80%的范围内?
打个通俗比喻:炒股都知道要抄底,但是底部是走出来的,也就是说:当涨了以后,回头看看那时是底部,但是那时你知道当时是底部吗?就象现在你知道股票2800点是底部吗?
所以,连马后炮定理这样基本逻辑都没有想明白的人,根本就不适合炒股和搞软件。以前在Jdon网站和我争论EJB的不少人属于这类。
在没有人敢打100%包票说本项目将来肯定不需要高性能,不需要分布式计算情况下,可伸缩性是项目开始之初架构必须考虑的一个因素,至少有一个方案:将来能否平滑过渡到分布式环境,否则一个规模重写一套软件老路。
再说了:使用java这样容器性解释语言,它和C++等拼的不是单机性能,而是群计算能力,就象,我们中国人一个单个人体质不如西方人,那么我们一群人就可以对付他们,所以,我们讲究集体的力量,Java也是一个讲究集体力量的语言平台。
只有了解这些,才真正悟java之道。
著名社交网站LinkedIn的Java架构技术
http://www.jdon.com/jivejdon/thread/34214.html
[该贴被banq于2008-06-25 17:20修改过]