广义的企业套用系统由三个层次构成：管理模式、业务模型与软体系统。业务模型体现了企业内先进的管理模式，并直接表现为软体系统的行为，业务模型的可重构性是影响企业套用系统重构能力的关键因素。传统的企业建模方法，如CIM2OSA、GRA I/GIM等，通常将模型的重点放在如何使用不同视图对企业进行完备描述，较少考虑模型本身的动态性。

狭义的企业套用系统是指运行在企业内的单纯的软体系统，而广义的套用系统则是由标準化的管理模式、知识化的业务模型以及集成化的软体系统三个层次构成，如图1所示。

现代企业面临巨大的市场压力，这就要求企业业务流程不断变化，以便适应市场变化的需求，流程重组又是很频繁的事情。客观上，企业应用程式必须通过重构才能快速回响企业业务流程的变化，那幺，重构的易操作性和灵活性就十分重要。并且，伴随着电子商务的普及。跨企业供应链协作需求也日益增加。因此，需要有一种技术能够将构建于不同时期、不同类型的异构系统以及跨企业边界的软体系统进行灵活的整合。套用系统架构的选择!实际上是在系统实现的功能与系统实现的複杂性间寻求一种折衷。在这种背景下，基于各种架构或模型的企业套用系统应运而生了。

设计和性能是实际框架选择的两个基本点，善于平衡才是框架选择的主要宗旨。轻量级框架和重量级框架解决问题的侧重点是不同的。

轻量级框架侧重于减小开发的複杂度，相应的它的处理能力便有所减弱（如事务功能弱、不具备分散式处理能力），比较适用于开发中小型企业套用。採用轻量框架一方面因为儘可能的採用基于POJOs 的方法进行开发，使套用不依赖于任何容器，这可以提高开发调试效率；另一方面轻量级框架多数是开源项目，开源社区提供了良好的设计和许多快速构建工具以及大量现成可供参考的开原始码，这有利于项目的快速开发。例如目前Tomcat+Spring+Hibernate 已经成为许多开发者开发J2EE 中小型企业套用偏爱的一种架构选择。随着可供选择的框架层出不穷，开发者可以根据需要对应于企业套用三个层次的轻量级框架选择，本文第2 节的内容可供选择参考。而作为重量级框架EJB 框架则强调高可伸缩性，适合与开发大型企业套用。在EJB 体系结构中，一切与基础结构服务相关的问题和底层分配问题都由应用程式容器或伺服器来处理，且EJB 容器通过减少资料库访问次数以及分散式处理等方式提供了专门的系统性能解决方案，能够充分解决系统性能问题。轻量级框架的产生并非是对重量级框架的否定，甚至在某种程度上可以说二者是互补的。轻量级框架在努力发展以开发具有更强大，功能更完备的企业套用；而新的EJB 规範EJB3.0 则在努力简化J2EE 的使用以使得EJB 不仅仅是擅长处理大型企业系统，也利用开发中小型系统，这也是EJB 轻量化的一种努力。对于大型企业套用以及将来可能涉及到能力扩展的中小型套用採用结合使用轻量级框架和重量级框架也不失为一种较好的解决方案。

由于 EJB 容器能够很好的处理系统性能、事务机制、安全访问许可权以及分散式运算等问题，基于EJB 框架进行开发能保证企业套用平滑发展，而不是发展到一种规模就重新更换一套软体系统，且可以保证开发人员将大部份精力集中在业务逻辑的开发上。採用EJB 框架开发的企业套用具有必须继承或依赖EJB 容器的特点。EJB 充分考虑到了顶级大型项目的需求，使用它几乎能解决企业级套用涉及到的所有问题，相应的基于EJB 框架也是一个功能複杂的重量级框架。

J2EE1.4 标準规定的EJB 2.1 框架缺少设计且实现起来有些过于複杂。当前J2EE5.0 的新规範提出的EJB 3.0 的目标就是简化开发，借鉴了一些基于POJO 的思想，它相对于EJB2.1 中两个重要的变化分别是：一是使用了Java5 中的程式注释工具，注释取代了过多的XML 配置档案并且消除了严格组件模型需求；二是採用了基于Hibernate 和TopLink 思想的O/R Mapping 模型。

J2EE5.0 的新规範中定义企业套用三个层次的标準实现为：表现层採用JSF（Java Server Face），JSF 的开发流程的核心是事件驱动，组件和标籤的封装程度非常高，很多典型套用已经不需要开发者去处理http。整个过程是通过IoC(依赖注入)来实现的；业务组件层採用EJB3.0 的Session Bean。EJB3.0 允许开发者使用藕合鬆散的组件来开发套用。这些组件通过自己发布的商业接口来耦合，不必像EJB 2.1 规範定义的那样一个Bean 必须遵守的严格的组件模型，每一个EJB 类必须从某一种抽象类中继承，并为容器提供了回调的钩子；持久层採用EJB3.0 实体Bean 持久化模型，吸收了Hibernate 的一些思想採用O/R Mapping 模式， EJBQL也有许多重要的改变。

在基于POJOs 轻量级框架上开发的应用程式无需依赖于EJB 容器可独立运行，对应于Java 企业套用三个层次的轻量级框架技术分别都得到了一定的发展，这三个层次流行的框架如下：

目前比较流行的开源表现层框架主要有Struts 和Tapestry。Tapestry 与Struts 套用框架不同的是，它是基于组件，而不是面向脚本语言（比如JSP 和Velocity）的，组件是由一个定义档案(以XML 的格式)、一个HTML 模板、一个JAVA 类构成的；业务组件层轻量级解决方案也不少，包括Spring、Hivemind 等。但是目前使用最为广泛的还是Spring框架，Spring 框架是一个基于IoC 和AOP（面向方面编程）的构架。採用IoC 使得它可以很容易的实现bean 的装配，提供了简洁的AOP 并据此实现事务管理等，但是它不具备处理套用分散式的能力。Spring 的核心要点是：支持不绑定到特定J2EE 服务的可重用业务和数据访问对象。这样的对象可以在不同J2EE 环境 （Web 或 EJB）、独立应用程式、测试环境之间重用；持久层框主要有Hibernate 和各种JDO 产品，以及iBATIS。Hibernate 是一个开源的O/R Mapping 框架，它对JDBC 进行了非常轻量级的对象封装，可以套用在任何使用JDBC 的场合，可以在套用EJB 的J2EE 框架中取代CMP，完成数据持久化的重任。iBATIS 是一个简易的SQL Map 工具，它是将手工编写的在xml 配置档案中的SQL 语句映射成Java对象。

MVC 设计模式不再是某一种表现层框架的特点而是这几种框架的共性。Struts 框架由于出现时间早，所以使用相对广泛，它的社区非常活跃，很容易找到很多现成的开源功能标籤以供使用以及样例程式可供参考。但是它的组件在页面中显示的粗粒度，以及框架类的限制在很多情况下会表现得过于死板，给表示层的开发会带来一些额外的代码开销。JSF 在很大程度上类似Struts，只是JSF 的组件概念没有象Struts 那样必须继承ActionForm 的限制，JSF 在事件粒度上要比Struts 细腻。JSF 有的另外一个优势就是其身后有Sun 公司和其他的一些大公司的支持。Tapestry 是一个完全组件的框架，Tapestry 的组件可以被套嵌并包裹其它组件，因此可以组合形成一个更大的组件或逻辑页面。组件的行为模式为Web 页面编程提供了很大的方便，事件处理也方便很多。所以，如果做一个对页面要求灵活度相当高的系统就可以考虑选用Tapestry。

EJB 2.1 框架有些过于複杂了，有如下缺点：① EJB 模型需要建立许多组件接口和实现许多不必要的回滚方法；②EJB 的部署描述複杂而容易出错；③开发人员不能脱离EJB容器测试。对于以上缺点JCP (Java Community Process)制订的EJB3.0 标準框架做了相应的改进，该框架为所有主要的J2EE 厂商支持。EJB3.0 和Spring 两个框架结构都有一个共同核心设计理念：将中间件服务传递给耦合鬆散的POJOs。

EJB3.0 框架与套用伺服器高度整合，服务整合代码也包装在一个标準接口后面。EJB 框架一方面有成熟的EJB 容器支持，基于EJB 框架的企业套用性能优良；另一方面EJB 容器设计因为考虑了多方面的功能，所以在其核心上总是会显得臃肿，这也是一种重量表现。不需要的东西存在肯定会影响效率，EJB 不能根据项目需求对EJB 整体包括EJB 容器进行可配置式的切割。Spring 框架处于套用伺服器和服务库的上方，服务整合的代码属于框架，并暴露于套用开发者。它与套用伺服器整合的能力相对EJB3.0 要弱。但是Spring 框架模组的可分离配置体现了它优于EJB3.0 的灵活性。

容器管理持久性（CMP）是对EJB 中Entity Bean 进行持久性管理的方式。EJB2.1 持久性模型过于複杂并且存在基础缺陷。EJB3.0 持久层针对EJB2.1 的缺陷做了相应改进，採用与Hibernate 类似的机制。Hibernate 相对而言其基本优势如下：①Hibernate 使用 Java 反射机制而不是位元组码增强程式来实现透明性；②Hibernate 的使用简单；③映射的灵活性很出色，它支持各种关係资料库， 从一对一到多对多的各种複杂关係。Hibernate 也有一些缺点，它限制所使用的对象模型 (例如，一个持久性类不能映射到多个表)。使用iBATIS 提供的O/R Mapping 机制，对业务逻辑实现人员而言，面对的是纯粹的Java 对象， 这一层与通过Hibernate 实现O/R Mapping 而言基本一致，而对于具体的数据操作，Hibernate 会自动生成SQL 语句，而iBATIS 则要求开发者编写具体的SQL 语句。相对Hibernate 等 “全自动”O/R Mapping 机制而言，iBATIS 以SQL 开发的工作量和资料库移植性上的让步，为系统设计提供了更大的自由空间。作为“全自动”ORM 实现的一种有益补充，iBATIS 的出现显得别具意义。