通过对分布式多层应用系统的功能进行分析表明：应用系统服务器端组件需要完成两种类型的功能：
一种功能是诸如判断购物车中商品数量、计算订单的价格、线性方程组求解等，归根结底可以表示为数学计算和逻辑分析。这些利用前面章节中介绍的会话类型EJB组件来完成应该比较合适。
服务器端组件完成的另外一种类型的功能是涉及数据库记录或者遗留（Legency）系统资源，如数据库中的人力资源信息记录、银行账户信息记录和企业现有的ERP系统等，这些内容在逻辑上作为一个整体，需要一种类型的EJB组件来表示业务实体或者对业务过程进行抽象。为此，在EJB规范中定义了另外一种类型的EJB组件——实体（Entity）组件。在本讲的内容中将介绍实体类型EJB组件的基本特征以及实体组件的持久性管理方式。
实体组件代表存储在外部介质中的持续（Persistence）对象或者已有的企业应用系统资源。简单地说：一个实体组件可以模拟为数据库表中的一行记录，多个客户端应用能够以共享方式访问表示该数据库记录的实体组件。依赖于EJB容器提供的事务服务，多个客户端应用能够在保持数据库记录的一致性和完整性前提下实现对数据资源的共享。
实体类型EJB组件的生命期相对较长并且其状态是持续的。只要实体组件代表的数据库记录存在，该组件对象实例就一直存在，即使EJB容器崩溃，实体组件仍然具有生命力。
按照实体类型EJB组件持久性的实现形式，可以将实体组件分为容器管理持久性（Container-Managed Persistence，CMP）和组件管理持久性（Bean-Managed Persistence，CMP）两种类型。在CMP类型EJB组件的实现代码中，组件程序设计人员不需要为组件的持久性控制方法编写任何数据库操作的代码，而是在组件组装和部署过程中由部署工具自动创建。如果要创建BMP类型EJB组件，则组件程序设计人员需要为所有持久性方法编写控制代码。
与数据库中的数据记录相对应，每个实体类型EJB组件包含一个主键（Primary Key）标识，该标识与组件代表的数据库记录主键相同。客户端应用可以利用该主键定位EJB容器中的实体组件对象实例，进而定位组件代表的数据库记录。
EJB规范定义的实体类型EJB组件提供了客户端对企业应用系统中的EIS系统层数据资源的对象类型视图。但是，采用EJB组件方式并不是对数据库中数据记录进行管理的唯一方式，可以在J2EE系统外对实体类型EJB组件表示的数据记录进行管理和维护。总结起来，实体类型EJB组件的主要特点包括：
◇实体组件提供数据库中记录的客户端视图；
◇实体组件具有无限制生命期，EJB服务器崩溃不会影响实体组件的存在；
◇多个实体组件可以对应同一数据库记录；
◇EJB服务器可以利用实体组件的Passivate方法将实体组件缓存到临时存储空间中，同样可以利用Activate方法将缓存的实体组件重新读入EJB容器并恢复组件对象实例。
◇客户端应用可以利用在实体组件的Home接口中定义的创建、删除和查询等方法来对组件进行管理。
根据上述分析可以总结出会话组件与实体组件之间的区别，见下表所示：
| 会话组件 | 实体组件 |
| 一个客户端应用使用一个会话组件 | 可被多客户端应用共享 |
| 非持久性对象 | 持久性对象 |
| 客户端不能搜索指定的会话组件 | 组件实例拥有主键标识，客户端可以采用查找的方式获取对组件实例对象的引用 |
| EJB服务器关闭后组件不再存在 | 不受组件部署的EJB服务器的状态影响 |
| 达到非活动状态时间阈值后由EJB服务器收回组件占用的系统资源 | 需要调用remove方法才能删除组件对象实例 |
由于实体组件是数据库中的数据库记录在客户端的对象类型镜像，因此，在讨论组件的生命期时将实体类型EJB组件的状态分为非实例化非引用、非实例化引用、实例化引用和实例化非引用四种类型，如下图所示：
由上图可以看出：当组件处于非实例化非引用状态时，由于EJB组件代表的数据记录存在于数据库中，因此，可以直接利用组件Home接口中的create方法在EJB容器中创建组件对象实例，将实体组件的状态转换为实例化引用状态。当EJB组件处于实例化非引用状态时，可以通过组件Home接口中定义的find方法将组件的状态转换为实例化引用状态。客户端应用可以调用处于该状态的实体组件对象实例中的商务方法来获取服务。