J2EE為實現分布式（distributed）體系結構提供了非常出色的支持，同一個分布式J2EE應用構件可被分布給運行在一台或多台物理服務器上的多個JVM.分布式J2EE應用以使用具有遠程接口的EJB作為基礎，遠程接口可以讓服務器隱藏掉分布式構件的訪問和管理的大部分復雜性…… J2EE對分布應用的出色支持已經導致一種誤解：J2EE必定是一個分布式模型…… 大家都非常的清楚，分布式應用非常復雜，並導致顯著的運行開銷，而且要求設計工作保證令人滿意的性能……人們有這樣一種想法 分布式模型是實現堅固而又可縮放的應用的惟一方法，這種想法是不可行的，聚集所有服務構件把它們集中布置到同一JVM也是可能的……分布式體系結構提供了以下幾點好處：
（1、支持許多需要一個共享式業務對象（中間層）的客戶（客戶可具有不同類型）的能力，考慮這個因素不適用於Web應用，因為Web應用已提供了一個中間層。
（2、部署任一應用構件到任意物理服務器上的能力。這對負載均衡是非常重要的（我們可考慮當一個Web接口做少量工作而業務對象做密集型計算時的一種場景，如果使用一個J2EE分布式模型，我們可把該Web接口運行在一台或多台計算機上，而讓許多服務器運行各種做計算的EJB）這樣做的後果就是雖然每個調用的性能會有所下降，因為無程請求的系統開銷會降低該調用的速度，但每個硬件的總吞吐量可能通過消除性能瓶頸來得到改善……分布式體系結構也引起了一些麻煩：
（1、 性能問題，遠程請求會比本地請求慢許多倍。
（2、 復雜性，分布式應用的開發、調試、部署和維護都是比較困難的。
（3、 實行OO設計方面的限制，這是十分重要的方面……分布式應用帶來了許多有趣的挑戰。由於分布式應用的復雜性，在我們對需求做解決方案時，倘若有選擇的余地，最好是通過選擇一個非分布式解決方案來避開分布式應用的各種復雜性……分布不是實現堅固、可縮放應用的惟一方法。使用了遠程接口的大多數J2EE應用體系結構往往和所有構件一起被部署在相同的服務器上，以避免真正遠程調用的性能開銷，這意味著一個分布式應用的復雜性是完全沒有必要的，因為它沒有給我們帶來或產生任何真正的好處。
