Tomcat是只支持Web應用系統，所以采取struts+hibernate或tapestry+hibernate（或者中間加上Spring/Jdon）都屬於Web應用系統，他們都是單機Stand-alone系統，利用上述Tomcat的負載平衡只能勉強支撐兩三台服務器，而且隨著訪問量增加，Tomcat等Web服務器將趨於緩慢，從這篇文章觀點來看，Web應用程序在性能的伸縮性不太高。
下面討論的都是因為使用EJB後而使得你的應用程序自動獲得的能力：
以Weblogic JBoss為主的采取的paired servers 對服務器復制策略則要提高性能很多，但是對load balancer算法要求高，有些普通的load balancer不一定符合要求。
IBM采取的是中央狀態服務器策略；而SUN則采取的是特殊數據庫復制HADB策略。
該文最後分析了JNDI EJB和JMS的集群原理，實際也是闡述了從性能集群原理上說，為什麼會誕生EJB等復雜技術以及對於一些大型應用為什麼需要使用EJB的原因所在。
文章還否定了這樣的觀點：單機系統幾乎可以透明的遷移到集群結構。
在遷移時，需要考慮很多問題，如狀態/緩存 httpsession以及特殊的服務等。
另外觀點：分布式結構一定比配置定制結構可靠嗎？不一定。
在使用EJB時有人喜歡什麼都實現分布式，其實這是不必的，一般可讓Web應用程序首先選擇同台服務器中的EJB服務，這叫配置結構。
作者的結論是：
Clustering is different from the stand-alone environment
集群架構是完全不同於單機結構的。在建立一個大型的可伸縮系統之前，我們必須對不同的J2EE
服務器產品實現集群有不同的了解和掌握，選擇合適的第三方框架保證確認他們也是支持集群環境的（如Jdon框架），合適的架構設計將從集群中得益，而不是將苦難留給你的企業及其其他後來的同事（國人經常是在架構設計時，喜歡方便自己，害了系統和他人）。
一直以來，所謂輕量的架構系統受到狂熱分子的鼓吹和極端追從，甚至提出否定EJB的觀點（如Spring作者提出的without EJB），這些禍患人心的觀點不能說是完全錯誤的，但是至少是極端，屬於一葉遮目，看待EJB不能只從OO設計角度，還要從實際應用性能上考慮，就象看到SOA結構一樣，設計和性能是實際架構選擇的兩個基本點，善於平衡才是我們實際架構選擇的主要宗旨。
