重/轻量：其实是使用难易程度，从根本上说，重/轻量应该和可伸缩性不矛盾的，特别是EJB 3.0推出以后，这个问题应该得到比较好的解决。
　　 但是，在目前情况下，编写一个JavaBeans要比编写一个EJB容易多，那么，是重/轻量还是可伸缩性应该成为系统架构的主要依据呢？ 在这个问题背后，还隐藏了目前在开源领域两个架构技术选择：
　　1. 重量：基于JBoss/EJB的完整J2EE系统架构 （具有可伸缩性，目前不易于学习）
　　2. 轻量：基于Tomcat的Struts+Hibernate/Spring+Hibernate （目前无太大可伸缩性，但是易于学习使用）

因为轻量解决方案易于学习新技术，容易使用，选中率比较高。但是让人产生对系统的可伸缩性担忧。鉴于这种情况，我认为有必要强调一下可伸缩性的重要性，切不能因为要跟进新的设计思想和技术，而盲目地采用一个无可伸缩性的设计方案。

其实，"轻量"应该是一个中性词，但是因为大量新的设计思想比较容易通过轻量方案获得成型软件，如（Spring/Naning/Hibernate）等，逐渐的"轻量"好像变成了一个褒义词。 如果从可伸缩性的标准看，轻量还可能是一个贬义词，轻量意味着丧失重量系统中的分布式网络计算的设计考量，那么可伸缩性就要打问号。

从这次JavaOne大会以及从长远来看，随着EJB 3.0中间件轻量化、SOA架构理念普及，轻量/重量的区别已经模糊，如果还是以轻量/重量作为架构选择的标准，甚至标榜自己的系统，无疑是不明智的。