所谓可伸缩性，是指在小型规模单台服务器情况下，应用系统可以良好运转，系统的访问量或功能增加后，整个系统只需通过增加服务器硬件就可以实现性能扩展，无需修改太多软件。对于可伸缩性平台（如JBoss）来说，理论上，没有最大负载或最多在线人数这样的概念。
重/轻量其实是使用难易程度，从根本上说，重/轻量应该和可伸缩性不矛盾的，特别是EJB 3.0推出以后，这个问题应该得到比较好的解决。
但是，在目前情况下，编写一个JavaBeans要比编写一个EJB容易多，那么，是重/轻量还是可伸缩性应该成为系统架构的主要依据呢？ 在这个问题背后，还隐藏了目前在开源领域两个架构技术选择：
1. 重量：基于JBoss/EJB的完整J2EE系统架构 （具有可伸缩性，目前不易于学习）
2. 轻量：基于Tomcat的Struts+Hibernate/Spring+Hibernate （目前无太大可伸缩性，但是易于学习使用）
因为轻量解决方案易于学习新技术，容易使用，选中率比较高。但是让人产生对系统的可伸缩性担忧。鉴于这种情况，我认为有必要强调一下可伸缩性的重要性，切不能因为要跟进新的设计思想和技术，而盲目地采用一个无可伸缩性的设计方案。
其实，"轻量"应该是一个中性词，但是因为大量新的设计思想比较容易通过轻量方案获得成型软件，如（Spring/Naning/Hibernate）等，逐渐的"轻量"好像变成了一个褒义词。如果从可伸缩性的标准看，轻量还可能是一个贬义词，轻量意味着丧失重量系统中的分布式网络计算的设计考量，那么可伸缩性就要打问号。
从这次JavaOne大会以及从长远来看，随着EJB 3.0中间件轻量化、SOA架构理念普及，轻量/重量的区别已经模糊，如果还是以轻量/重量作为架构选择的标准，甚至标榜自己的系统，无疑是不明智的。
可伸缩性应该依然是实用企业系统架构的主选，可伸缩性是站在软件公司的客户企业立场，为这些客户企业考虑的，但是他们经常因为被认为是外行，挡在了软件系统架构选择的门外。
