EJB 的三种Bean介绍

EJB 依照特性的不同，目前区分为三种，分别是 Session Bean ，Entity Bean ，以及 Message Driven Bean 。其中 Session Bean 与Entity Bean 算是 EJB 的始祖，这两种 EJB 在 EJB 规格 1.x 的时候就已经存在了，而 Message Driven Bean 则出现在 EJB 2.0 的规格中。


Session Bean


Session Bean 主要的目的是让程序开发者将逻辑层抽离，特别是复杂的逻辑可以放在 Session Bean 中。 Session Bean 还可以再细分为Stateful Session Bean 与 Stateless Session Bean ，这两种的 Session Bean都可以将系统逻辑放在 method 之中执行，不同的是 Stateful Session Bean 可以记录呼叫者的状态，因此通常来说，一个使用者会有一个相对应的 Stateful Session Bean 的实体 (Instance 注一 ) ，换言之，当使用者呼叫某个 Stateful Session Bean 的两个 methods 的时候，EJB Container( 注一 ) 会清楚的知道某个 EJB 的实体属于某一个使用者的。因此一般的设计上，不会让两个使用者同时使用某个 Stateful Session Bean ( 这并不是表示两个使用者不能使用同一个 Stateful Session Bean) 。


Stateless Session Bean 虽然也是逻辑组件，但是他却不负责记录使用者状态，也就是说当使用者呼叫 Stateless Session Bean 的时候，EJB Container 并不会找寻特定的 Stateless Session Bean 的实体来执行这个 method ，换言之，很可能数个使用者在执行某个 Stateless Session Bean 的 methods 时，会是同一个 Bean 的 Instance 在执行。


从内存方面来看， Stateful Session Bean 与 Stateless Session Bean 比较， Stateful Session Bean 会消耗 J2EE Server 较多的内存，然而 Stateful Session Bean 的优势却在于他可以维持使用者的状态。


Entity Bean


Entity Bean 主要是资料组件， Entity Bean 主要的目的，在于提供资料，也就是说程序设计师可以将 Entity Bean 当程序资料，至于 Entity Bean 实际上怎么存取实际上的数据库，那个则是另外一件事情。


Entity Bean 实际上是针对 RDBMS 而设计，也就是说当其它的程序使用 Entity Bean 的时候， Entity Bean 的资料主要是从 RDBMS 而来，当然，如果程序设计师熟悉 Entity Bean 的运作，那么也可以很轻易的把RDBMS 用其它的数据库取代，像是 LDAP 。


Entity Bean 主要区分为 Bean-Managed Persistence 以及 Container-Managed Persistence ( 简称 BMP 及 CMP) ，这两种 Entity Bean 的型态不同，但是目的相同，都在于提供资料！这两种 Entity Bean 主要的差别在于维护资料的角色， BMP 是由 Bean 自行维护资料的一致性，而 CMP 则是由 EJB Container 来维护。一个 Entity Bean 往往代表一张RDBMS 的表格，这个表格内的一笔一笔的资料，则是透过另外一个叫做 Primary Key( 注三 ) 的 Class 来加以区分。


Bean-Managed Persistence


当我们说 BMP 是由 Bean 自行维护资料的一致时，有些人会觉得太过于抽象，简单一点来说，原来的资料均由数据库而来，而当资料从资料库中取出之后，在 BMP 中需要自行宣告字段来存放这些资料，同时也要自行撰写相关的程序代码，包括相关的 JDBC 语法等等。


Container-Managed Persistence


CMP 是比较高阶的 Entity Bean ，比较高阶的意思是说，撰写 CMP 的程序设计师并不需要撰写大多数的 JDBC 语法，只需要透过一些定义，即可产生 CMP ，实际上的 EJB 的程序代码则是 EJB Container 依据相关的 Deployment Description ( 注四 ) 在部署（注五） EJB 的时候产生。


BMP 与 CMP 的型态不同，适用的场合也不同，主要的差异在于如果我们想要自行控制所有的动作，那么应该使用 BMP ， BMP 允许程序设计师完全的控制 BMP 的资料存取行为，而 CMP 很适合快速开发，但是由于要支持 CMP 的 J2EE Server 需要较高的技术，因此每一家对于CMP 的支持程度也不大相同。


此外，数据库中有一个很重要的关系是 OR Mapping ，也就是常听到的一对一，一对多，多对多这种关系，在 EJB 1.x 的规格中，这种一对多的对应关系只有两种方式可以做出，一种是透过 Session Bean 来存取多个 Entity Bean ，另外一种则是透过 BMP 来控制另外数个 BMP 或是CMP ，但是在 EJB 2.0 的规格中，已经可以透过纯粹的 CMP 配合EJB-QL( 注六 ) 语法来做出这种对应关系，这也是 EJB 2.0 的一大特色。


Message Driven Bean Message Driven Bean 与 Session Bean 或是 Entity Bean 均不相同，一般 Session Bean 或是 Entity Bean 都可以让使用者主动触发（可以在需要的时候，呼叫他们的 method 来触发他们），但是 Message Driven Bean 主要的目的在于反应 Message Queue 中的事件。


也就是当 Message Queue 中有讯息传入时， Message Driven Bean 可以主动被触发，做出相对应的反应。因此如果说 Session Bean 与 Entity Bean 是同步模式的 EJB ( 使用者呼叫某个 Method ，就只能等 EJB 响应之后才能进行下一步 ) ，那么 Message Driven Bean 就可以当成是专门处理异步资料格式的 EJB ，也就是说程序设计师将某个讯息丢入 Message Queue 之后，就继续执行下去，另外一方面， Message Driven Bean 会受到通知，知道有某个讯息需要处理，这时候他会自行运作。因此 Message Driven Bean 并不是直接给使用者呼叫的，而是透过 MessageQueue 来触发。


有状态会话bean ：每个用户有自己特有的一个实例，在用户的生存期内，bean保持了用户的信息，即“有状态”；一旦用户灭亡（调用结束或实例结束），bean的生命期也告结束。即每个用户最初都会得到一个初始的bean。

有状态session bean生命周期
1. 当客户调用create(args)时，容器调用newInstance()方法，剩下来的创建过程同无状态session bean。
2. 有状态session bean的方法执行分为事务与非事务两种情况
a. 不包含事务的方法在该bean处于ready状态后就可以执行
b. 包含事务的方法执行就比较复杂：
客户调用事务方法-->容器调用afterBegin()
客户提交方法-->容器调用beforeCompletion()
事务尝试提交，提交结果可能会成功，也可能会滚事务
事务结束-->容器调用afterCompletion()