JavaEE开发中程序架构设计不仅会影响程序性能、复杂性，同时还影响到程序的可扩展性和可维护性，目前业界有规范的JavaEE架构设计被奉为经典，下面将按照是否分布式进行介绍。
非分布式架构：
1.Web应用搭配业务组件接口架构：
经典三层架构：用户接口层、业务逻辑层和持久化层。
优点：
(1).架构简单，是最常用最简单的Web应用架构，但是如果涉及到事务或者多线程问题时，需要编写比较复杂代码，不如直接使用EJB简单。
(2).程序运行速度快，这种架构很少遇到EJB容器的速度开销问题。
(3).不会遇到因EJB调用而破坏面向对象设计原则问题。
(4).测试简单，如果设计的得到，业务逻辑层不需要依赖Web容器就可以测试。
(5).扩展性比较好，若Web应用是无状态的且非分布式的，不需要依赖EJB容器提供的集群支持。若Web应用是分布式的且有状态的，则可以利用Web容器对状态替换的支持。
缺点：
(1).这种架构只支持Web应用的客户端，不支持standalone的java客户端。
(2).整个应用程序运行在同一个java虚拟机中，虽然提高了性能，但是无法自由将应用程序模块分配到不同的物理服务器上。
(3).这种架构无法使用EJB容器对事务的支持，必须在应用程序中编写事务创建和管理的相关代码(Spring等第三方框架可以提供类似javaEE容器的声明式事务)。
(4).这种架构无法使用EJB容器对并发多线程的支持，必须使用java.util.concurrent等并发包来支持多线程问题。
2.Web应用访问本地EJB架构：
这种架构是简单3层架构的扩展，中间层包括业务逻辑层和EJB层，业务逻辑调用EJB，利用了EJB容器提供的基本服务，在不引入分布式等复杂性的前提下充分利用EJB容器提供的事务管理。
优点：
(1).相比一个分布式的EJB应用，这种架构比较简单。
(2).EJB的使用不改变应用程序的基本架构设计，只有需要使用EJB容器服务的业务逻辑才被放到EJB容器中，EJB只是一个可选的技术，如果换用其他的技术实现，不会影响程序的用户接口层，对用户透明。
(3).由于使用的是EJB本地调用，因此这种架构也避免了EJB远程调用的性能和序列化问题。
(4).充分利用了EJB容器提供的事务和线程管理服务。
缺点：
(1).这种架构比纯的Web应用架构复杂，因为需要考虑EJB的部署和类加载器的复杂性问题。
(2).仍然不支持除了Web应用之外的客户端，除非增加一层Web应用层才能支持其他类型的客户端。
(3).这种架构下的应用程序仍然运行在同一个Java虚拟机中，不支持分布式架构，即所有的应用模块必须运行在同一台物理服务器上。
(4).EJB的本地接口难以测试，必须在EJB容器中运行测试用例(可以使用Mock来进行测试，不需要依赖EJB容器)。
分布式架构：
1.使用WebService的分布式应用：
这种架构将JavaEEWeb应用程序对外发布为WebService接口，不但java程序客户端可以调用，C/C++/C#等其他语言平台技术客户端也可以调用。WebService的业务逻辑实现可以和WebService运行在同一个java虚拟机中，也可以运行在其他物理服务器中，通过SOAP消息进行分布式的远程调用。
优点：
(1).WebService现在是面向服务架构的标准，WebService不但可以支持分布式调用，同时还可以支持异构编程语言和平台的调用，客户端实现不再依赖服务端。
(2).将现有的Web应用对外发布为WebService远比改写为分布式的EJB容易，只需要添加一层WebService接口即可实现，程序的业务逻辑和架构设计基本不受影响。同时现在有很多WebService的实现如AXIS、AXIS2、XFire和CXF等可以很方便地java应用发布成WebService应用。
(3).WebService是基于HTTP协议，相比于EJB的RMI/IIOP协议来说，WebService的更加容易跨越防火墙，同时请求和响应消息是XML格式，容易阅读调试。
(4).WebService非常适合分布式异构应用系统集成，即EnterpriseeApplication Integration, EAI。
缺点：
(1).性能和安全性是WebService最大的问题，通过HTTP协议传输XML数据比过RMI传输二进制数据速度慢且容量大，同时由于是明文的XML消息，因此容易泄漏安全性敏感的数据。
(2).如果客户端本身是java程序，并且属于同一个应用系统，没有必要使用平台无关的WebService解决方案，使用EJB比使用WebService更合适。
(3).在WebService调用时，发送端需要将java对象编组为XML消息，接收端需要将XML解析为Java对象，这需要为java对象添加JAXB的支持。
2.使用远程EJB的分布式应用：
这种架构客户端可以使用Web应用，也可以使用非Web的应用，客户端通过业务逻辑代理接口调用运行在EJB容器中的业务逻辑实现，EJB的实体Bean是可选的。
这种架构是经典的JavaEE架构设计，中间层的EJB通过部署和运行在不同的物理或者逻辑上的服务器的java虚拟机中，支持分布式的应用。
优点：
(1).共享的EJB中间层可以支持各种类型的java客户端，不仅包括Web应用的客户端，也可以支持Standalone的客户端。
(2).这种架构允许应用程序组件部署和运行在不同的物理服务器上，尤其对于无状态的会话Bean支持良好，这种架构可以获得最大限度的可扩展性。
缺点：
(1).这种架构是最复杂的JavaEE程序架构设计，如果架构的复杂性无法满足客户需求，将会导致在整个程序生命周期中耗费大量资源，同时引入大量潜在的bug。
(2).大量频繁的远程EJB调用会严重影响程序的性能，远程EJB调用时，对象必须实现序列化。
(3).分布式的应用程序给测试和调试带来了巨大困难。
(4).业务逻辑组件必须运行在EJB容器中，EJB的部署和类加载器带来额外的复杂性，同时在分布式环境中某些简单需求变得难以实现，如单态模式。
(5).分布式环境中，程序的异常和错误处理难度加大，既要捕获处理应用程序本身的异常，同时还要分析分布式环境通信异常。
任何程序设计中，没有一种完美的架构，只有合适的才是最好的，在程序架构设计中需要根据需求场景，选择合适的架构设计方案。