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結構一樣，設計和性能是實際架構選擇的兩個基本點，善于平衡才是我們實際架構選擇的主要宗旨。