重/輕量：其實是使用難易程度，從根本上說，重/輕量應該和可伸縮性不矛盾的，特別是EJB 3.0推出以后，這個問題應該得到比較好的解決。
　　 但是，在目前情況下，編寫一個JavaBeans要比編寫一個EJB容易多，那么，是重/輕量還是可伸縮性應該成為系統架構的主要依據呢？ 在這個問題背后，還隱藏了目前在開源領域兩個架構技術選擇：
　　1. 重量：基于JBoss/EJB的完整J2EE系統架構 （具有可伸縮性，目前不易于學習）
　　2. 輕量：基于Tomcat的Struts+Hibernate/Spring+Hibernate （目前無太大可伸縮性，但是易于學習使用）

因為輕量解決方案易于學習新技術，容易使用，選中率比較高。但是讓人產生對系統的可伸縮性擔憂。鑒于這種情況，我認為有必要強調一下可伸縮性的重要性，切不能因為要跟進新的設計思想和技術，而盲目地采用一個無可伸縮性的設計方案。

其實，"輕量"應該是一個中性詞，但是因為大量新的設計思想比較容易通過輕量方案獲得成型軟件，如（Spring/Naning/Hibernate）等，逐漸的"輕量"好像變成了一個褒義詞。 如果從可伸縮性的標準看，輕量還可能是一個貶義詞，輕量意味著喪失重量系統中的分布式網絡計算的設計考量，那么可伸縮性就要打問號。

從這次JavaOne大會以及從長遠來看，隨著EJB 3.0中間件輕量化、SOA架構理念普及，輕量/重量的區別已經模糊，如果還是以輕量/重量作為架構選擇的標準，甚至標榜自己的系統，無疑是不明智的。