世界顶尖运动队教练的成功秘诀
本文列出了来自于顶级教练Marc Lammers的9条原则，他是在打造世界最佳曲棍球队的过程中发现这些原则的，文章把这些原则映射到了软件开发实践之中。
文章
EJB 3 术语汇编
作者 Oliver Ihns, Stefan M. Heldt译者 Jason Lai 发布于 2007年3月26日 上午5时38分
中文翻译：Jason Lai。如果您在阅读过程中发现任何翻译问题或者存在任何疑问，欢迎您邮件联系 Jason[at]infoq.com，期待您的宝贵建议与意见 :)
版本 1.1.2，最新更新于2006年7月17日。这是一份关于 EJB 3 引入的新术语、新概念的核心术语表。本术语表旨在为一些流行术语（buzzwords）揭开神秘面纱，如 IoC、按异常配置（Configuration by Exception）、POJO、POJI、依赖注射（Dependency Injection）、可嵌入对象（Embeddable Object）、拦截器（Interceptors），还有许多。本术语表是一项不断完善的工作，我们将定期对其进行更新。
术语链接： A - B - C - D - E - F - H - I - J - L - M - P - R - S
A
Attached Object（附属对象）- EJB 3.0 - 表示实体 Bean 的一个实例，该实例及其所持的来自数据库的数据目前被实体管理器（Entity Manager）所管理。
B
Bean Class（Bean 类）- EJB 1.x，EJB 2.x，EJB 3.0 - Bean 类是 EJB 组件的产物，这个 EJB 组件持有业务逻辑的实现。在面向对象表示法中，我们会把这个类视为实现类（例如 CustomerImpl）。对于 EJB 我们则使用“Bean 类”这个术语（例如 CustomerBean）。
Bean-managed Persistence（Bean 管理的持久化）- EJB 2.x，EJB 3.0 - 实体 Bean 的两种持久化机制之一。当实体 Bean 采取 Bean 管理的持久化（BMP）时，开发人员须负责实现持久化逻辑。总的来说，这意味着你必须将实体 Bean 的持久化属性恰如其分地与持久层进行匹配。要达到这个目的，你必须在 Bean 类中为持久层实现访问逻辑（例如，使用 JDBC 访问数据库，或使用 JCA 访问既有系统）。
- EJB 容器决定操作产生的时间。
- 开发人员决定完成一些什么操作。
BMP - EJB 2.x，EJB 3.0 - Bean-managed Persistence（Bean 管理的持久化）的缩写。
Business Interface（业务接口）- EJB 3.0 - 业务接口包含一个 EJB 组件中业务方法的声明。此外，它是 EJB 3.0 里描述 POJI 类型接口的术语。与 EJB 2.x 组件接口不同，这些业务接口不能扩展 javax.ejb.EJB[Local]Object。同一个业务接口不允许同时作为一个 EJB 组件的本地和远程业务接口。
会话 Bean（Session Beans）必须有业务接口。消息驱动Bean（Message-Driven Beans）必须拥有一个符合其使用的消息类型（例如 javax.jms）的（业务）接口。在 EJB 3.0，消息驱动 Bean 的这个接口也可以被称作业务接口，不过该接口要比功能性接口更技术化一些。EJB 3 实体不一定需要用业务接口来表现。
C
Callback Methods（回调方法）- EJB 2.x，EJB 3.x - 在 EJB 2.x 里，Bean 类必须按照 Bean 的类型（javax.ejb.SessionBean、javax.ejb.MessageDrivenBean 或 javax.ejb.EntityBean）实现其回调接口。首先，这些接口指明你拥有的 EJB 类型。其次，这些接口声明了回调方法，EJB 容器调用这些方法，管理EJB 组件的生命周期。开发人员必须在 Bean 类中实现接口声明的回调方法。
在 EJB 3.0 中，上述回调接口不再需要由 Bean 类来实现了。由于开发人员不再被强制去实现这些回调方法，开发时间及工作量均得以缩减。但是，仍然可以使用一系列已定义的标注（annotations）来接手 EJB 组件的生命周期管理，标注可以标记在任意的方法上，这样可以根据使用的标注在定义的时间执行这些方法。你可以把这些标注用在所有的 EJB 类型上。标注 @PostConstruct、@PreDestroy、@PostActivate 和 @PrePassivate 可被应用于会话 Bean 和消息驱动 Bean 上；而对于 EJB 3 实体来说，下列标注可用：@PrePersist、@PostPersist、@PreRemove、@PostRemove、@PreUpdate、@PostUpdate 和 @PostLoad。
CMP - EJB 2.x，EJB 3.0 - Container-managed Persistence（容器管理的持久化）的缩写。
Component Interface（组件接口）- EJB 1.x，EJB 2.x，EJB 3.0 - 组件接口是 EJB 组件的业务接口。它有两种形式：作为本地接口（仅能在同一进程内访问→参见 Local Interface）和/或作为远程接口（可以跨机器和进程进行访问→参见 Remote Interface）。组件接口必须扩展自 javax.ejb.EJB[Local]Object。
Configuration by Exception（按异常配置）- EJB 3.0 - 按异常配置的方法随着 EJB 3.0 一起被引入。这个方法的目标之一就是减少对于 EJB 组件的配置和/或者开发的开发次数和工作量。
开发人员只须在异常情况下（正因如此称为“按异常配置”）为 EJB 组件提供配置或者运行期控制信息，也就是说，仅须在所期望的行为与已定义且给定的某个类型 EJB 组件的标准行为相悖的情况下提供。其目标是为了减少对配置参数的显式说明的必要性，这些配置参数用于通常预期的EJB组件行为以及对EJB容器的需求。
具体言之，这就是说在 EJB 3.0 中，许多功能和/或行为默认情况下已经为 EJB 组件设置好了。这些缺省行为应涵盖绝大多数 EJB 组件（和/或相应 EJB类型）的典型用例。假如标准行为不适合需求的情况，那么开发人员可以很容易地重载这些默认数值和/或标准行为。
Container-Managed Persistence（容器管理的持久化）- EJB 2.x，EJB 3.0 - 实体 Bean 的两种持久化机制之一。如果你正在使用容器管理的持久化（CMP），你可以不必编写代码处理实体 Bean 与持久层间的同步。代码是由应用服务器的工具生成的。开发人员的任务只需要集中在持久化属性的声明及不同实体 Bean 之间的关系。运行时期的同步由 EJB 容器的一个特殊部件来完成——即所谓的“持久化管理器”。
D
DD - EJB 1.x，EJB 2.x，EJB 3.0 - Deployment Descriptor（部署描述符）的缩写。
Detached Entity（游离实体，也译作“脱管实体”）- EJB 3.0 - 参见 Detached Object（游离对象）。
Detached Object（游离对象，也译作“脱管对象”）- EJB 3.0 - 表示一个 EJB 3 实体的实例，该实例脱离了将它持久化或者取得它的持久化上下文环境。因此，这样的对象不再受实体管理器所管理，其数据与数据库之间的同步不再可能进行。但应用程序仍旧可以使用游离对象，可以访问其可用的状态，并进行更改，但（实体管理器）不会对这些操作进行跟踪。
游离对象的产生可以分为很多种情况。例如，对一个 EJB 3 实体进行序列化就是其中之一。经过序列化，EJB 3 实体将转化成一个游离对象。
Dependency Injection（依赖注射）- EJB 3.0 - 依赖注射（DI）这个名词是反转控制（Inversion of Control）模式的一个特殊形式。Martin Fowler 发明了这个术语（参看 http://martinfowler.com/articles/injection.html）——这是因为目前的一些轻量级容器/框架中反转控制的使用形式，其性质更像是类/对象的引用的注射。
将 DI 引入EJB 3 的动机是为了简化对 EJB 组件资源的查找。我们不再需要在 EJB 组件中编写任何基于 JNDI API 的代码了——即便你还是可以随意使用它。
EJB 的 DI 技术意味着开发人员可以从编写基于 JNDI API 代码实现资源查找的桎梏中解脱出来。相反他只须在 EJB 组件中标注实例变量或者 setter 方法，或者在相应 XML 中声明这样的依赖说明，就可以从容器中请求到资源的引用。接着，容器在运行期，执行 EJB 组件某个方法之前，把必要或者请求的资源引用注射到 EJB 组件中，也就是说，EJB 组件不再需要主动从它的容器中一个接一个地请求资源，取而代之的是通过容器的注射来取得它们。
使用标注（annotations）比使用 XML 要方便许多，它将是 EJB 3 的首选方案。在这里 DI 只是访问 JNDI context 及获取引用的一个简化机制。
Deployment Descriptor（部署描述符）- EJB 1.x，EJB 2.x，EJB 3.0 - 部署描述符是一个 XML 文件，它包含生成、执行 EJB 组件的编译期和运行期信息。开发人员通过简单地在部署描述符中声明某些关键字的方式实现功能和/或行为，而不需要编写一行代码，因此这种方式又称作声明式编程（declarative programming）。例如 EJB 组件的事务处理行为就是通过这种方式控制的。
E
Eager Load（贪婪加载，亦作“提前加载”）- EJB 3.0 - 贪婪加载是 Java Persistence API 中定义的两种数据抓取策略（fetching strategies）之一。简而言之，贪婪加载表示 EJB 3.0 实体的持久化数据是从数据库中直接且完整地读取，并且被写入该 EJB 3.0 实体的相应实例属性中的。此 EJB 3.0 实体中所有被引用到的持久化实体（EJB 3.0 实体或者可嵌入对象）也将以类似的方式加载。事实上，贪婪加载实现的实际特点和厂商的各自实现有关。
贪婪加载的优点是，数据在一个回合中一次性抓取完毕。当应用程序访问这些属性时，它们的数据已经被取好，摆在那里了。而对较大的持久化对象网络或者对象树使用贪婪加载的缺点是会导致漫长的加载时间以及大量的内存消耗。
EJB - EJB 1.x，EJB 2.x，EJB 3.0 - Enterprise JavaBeans 的缩写，Java EE 平台下服务器端组件模型的名称。
EJB 3.0 Entity（EJB 3.0 实体）- EJB 3.0 - EJB 3.0 实体是一个轻量级的持久化业务域对象。在 Java Persistence API 中，它被称为持久化实体。其原因是，Java Persistence API 不再应该仅在 Java EE 下专用，而应该也能在 Java SE 环境下使用。
EJB Component（EJB 组件）- EJB 1.x，EJB 2.x，EJB 3.0 - EJB 组件是所有 EJB 类型（→参见 EJB Types）的通用名词。
EJB Types（EJB 类型）- EJB 1.x，EJB2.x，EJB 3.0 - EJB 规范在 EJB 2.x 中定义了三种 EJB 类型：
- Session Bean（会话 Bean，具有有状态和无状态两种性质）
- Message-Driven Bean（消息驱动 Bean）
- Entity Bean（实体 Bean）
在 EJB 3 中定义了下列的 EJB 类型：
- Session Bean（会话 Bean，具有有状态和无状态两种性质）
- Message-Driven Bean（消息驱动 Bean）
- EJB 3 实体
注意：在 EJB 3 中，会话 Bean 和消息驱动 Bean 将被通称为 Enterprise Beans。轻量级持久化业务域对象将被明确地命名为 EJB 3 实体或者持久化实体。
EJB QL - EJB 1.x，EJB 2.x - EJB Query Language（EJB 查询语言）的缩写。
EJB Query Language（EJB 查询语言）- EJB 1.x，EJB 2.x - EJB QL 是 Enterprise JavaBeans 组件架构的查询语言。它与 SQL 相似，但专注于对象。它随着 EJB 3.0 一起被升级，但在 EJB 3.0 中被称为 Java 持久化查询语言（Java Persistence Query Language，Java Persistence QL）。
Embeddable Object（可嵌入对象）- EJB 3.0 - 如果有这样的 POJO，它们不是 EJB 3 实体，因而不具备持久化性质，可以被嵌入 EJB 3 实体中作为属性，那么这样的对象就称为可嵌入对象。这些可嵌入对象的属性装载的是对象的外围 EJB 3 实体所关联的数据表的数据。
例如，你可以将一个数据表映射到一个 EJB 3 实体及嵌入它的另外一些 POJO 上，将一个非常规的数据表映射到一个对象网络上。
@Entity
@Table(name="CUSTOMER")
public class Customer implements java.io.Serializable {
private int id;
private Address address;
private String lastName;
private String firstName;
public Customer(String lastName, String firstName,String street, String city) {
this.address = new Address(street, city);
this.lastName= lastName;
this.firstName = firstName;
}
...
@Embedded
@AttributeOverrides(
@AttributeOverride(name="street", column=@Column(name="STREET")),
@AttributeOverride(name="city",column=@Column(name="CITY")) })
public Address getAddress() {
return address;
}
public void setAddress(Address address) {
this.address = address;
}
@Column(name="LASTNAME")
public String getLastName() {
return lastName;
}
public void setLastName(String lastName) {
this.lastName = lastName;
}
...
Embeddable Object
@Embeddable
public class Address implements java.io.Serializable {
private String street;
private String city;
...
}
Enterprise Bean - EJB 3 - 会话 Bean 和消息驱动 Bean 可以被更概括地称为 Enterprise Beans。请注意 EJB 3 实体不能被称作 Enterprise Beans。但对于 EJB 3 实体则不能使用这个通称，因为它们可以也能被用于 Java SE 环境。
Entity Bean（实体 Bean）- EJB 2.x - 在EJB 2.x，用于持久化实体的 EJB 类型称为实体 Bean。
Entity Manager（实体管理器）- EJB 3.0 - Java EE 和 Java SE 的新成员，随 EJB 3.0 一同引入。（正像在JDO和Hibernate一样）它是一个核心的持久化管理器。实体管理器负责实体（POJOs）的持久化映射，它在数据库中创建持久化实体，对它们加载、存储、删除和搜索操作，同时也关注实体在并发访问时的一致性（并发处理）。
F
Fetching-Strategy（抓取策略）- EJB 3.0 - 在 EJB 3.0 规范的 Java Persistence API 中，定义了两种抓取策略：延迟加载（Lazy Load）和贪婪加载（Eager Load，亦作“提前加载”）。和 Hibernate 以及其它持久方案提供工具（如 TopLink）相比，这两种策略以及其性质只有少数可选方案。对这两种抓取策略的进一步细化及改进的工作，大致计划在规范的后续版本中开展。
绝大多数情况下，贪婪加载策略被预设为 Java Persistence API 的缺省方案。延迟加载仅在开发人员显式声明时才被使用。持久方案提供者运行时（Persistence Provider Runtimes，例如 Hibernate）被要求实现并提供贪婪加载机制。延迟加载则仅被持久方案提供者进行时实现者视为需注意事项而已。EJB 3.0 规范没有提供更多的关于延迟加载机制应当如何实现的细节，这样将带来许多风险，譬如，因为不同厂商架构和技术实现的分歧所带来的互操作性弱的问题。
H
Home Interface（Home 接口）- EJB 1.x，EJB 2.x - EJB 组件的 Home 接口包含创建、删除或加载 EJB 组件实例的方法。由于客户端无法跨越机器和进程界限，直接创建、删除或者加载 EJB 组件的实例，它们必须强制使用相应 EJB 组件的 Home 接口。Home 接口提供多种功能。通过使用 Home 接口，我们得以实现 EJB 组件和客户端的解耦。Home 接口实现了“工厂方法（Factory Method）”设计模式，它以两种形式存在：
- Remote Home Interface（远程 Home 接口）——用于跨机器和进程的远程访问
- Local Home Interface（本地 Home 接口）——用于进程内调用的本地访问
在 EJB 3.0 中，会话 Bean 不再强制使用 Home 接口，就是说，它们可以不必实现 Home 接口。而 EJB 3 实体也不再需要 Home 接口了。但是，规范中并没有规定 Home 接口应当消失。
I
Interceptor（拦截器）- EJB 3.0 - 在 EJB 3.0 中，对业务方法的调用进行拦截成为可能——与基于 CORBA 系统相似，在这些系统中拦截器的广泛使用已经有一段历史了。你可以在需要时分析及操作参数，并且允许或者禁止业务方法的执行。由于拦截器机制的出现，面向方面编程（aspect oriented programming）走入了基于 EJB 开发——起码是起始阶段。拦截器允许将技术性功能（比如日志、跟踪、安全）透明地织入业务方法中。拦截器的开发人员可以实现任何代码，这些代码将在拦截器被激活，对EJB对象的某个方法调用进行拦截时被执行。
Inversion of Control（反转控制）- EJB 3.0 - 反转控制（IoC）是框架的一个常见性质，一般常用好莱坞原则“don't call us, we'll call you”一语来作诠释（译注：这里的 call 一语双关，既包含通俗意义上“打电话”之意，更主要地，在编程上也做“函数/方法调用”解），意即程序执行过程中的责任是落在框架上，而不在组件上。就是说，组件所赖以构建的框架，要求相应的组件实现框架的某些回调方法（callback methods）。接着，框架在运行期调用这些回调方法，将信息注入，触发预定行为。
在 EJB 3.0 环境下，IoC 和依赖注射两个词常作为同义词互相代用，即便细节上它们有一些语义的区别（→参见 Dependency Injection）。在 EJB 3.0 中使用的是反转控制的一个特殊形式，叫做依赖注射。
J
Java Persistence API（Java 持久化 API）- EJB 3.0 - EJB 3.0（Java Community Process 中的 JSR 220）中开发出了 Java Persistence API。Java Persistence API 将成为 Java EE 和 SE 的标准持久化方案，其中一项重要性质就是可以被用于任意 POJO，并不仅限于 EJB 组件。因此 Java Persistence API 对于不需要在应用程序中使用 EJB 组件的开发人员同样是可用的。领导 Hibernate、TopLink、JDO 和 EJB 持久化解决方案的专家参与了 Java Persistence API 的开发。
Java Persistence QL - EJB 3.0 - Java Persistence Query Language（Java 持久化查询语言）的缩写。
Java Persistence Query Language（Java 持久化查询语言）- EJB 3.0 - Java 持久化查询语言是 Enterprise JavaBeans 组件架构的查询语言，与 SQL 相似，但是更专注于对象。与 EJB SQL 相比，Java 持久化查询语言进行了大幅度的改进。EJB QL 的许多遗缺功能都在 Java 持久化查询语言中被实现。Java 持久化查询语言比 EJB QL 拥有更加丰富的功能集合，且看起来有点像 Hibernate HQL。
L
Lazy Load（延迟加载）- EJB 3.0 - 正像其它持久化解决方案一样，延迟加载在此也代表这样一种策略：持久化实体（EJB 3.0 实体）的持久化数据仅在对持久对象和/或其属性的实际访问发生时，才从数据库中读入。用延迟加载标记过的所有的属性或与其它持久化实体连接的关系，仅在对它们的相应访问发生的时候，才实时（just in time）地从数据库加载。
延迟加载实现的实际性质取决于厂商各自的实现。
延迟加载的优点在于，数据仅在出现对某个属性或者关系的存取时才被取用，这样做可以减少对内存的消耗；其缺点则是，应用程序可能会因为对持久化数据进行即时抓取而减慢运行速度。
Local Home Interface（本地 Home 接口）- EJB 2.x - 本地类型的 Home 接口称为本地 Home 接口。它就是所谓的高速 Home 接口，因为它仅在 EJB 组件客户端处于同一个容器（进程）的情况下才被使用。本地 Home 接口和远程 Home 接口一样用于创建、删除和加载 EJB 组件。本地 Home 接口比起远程 Home 接口结构要轻便一些，因为前者无法通过 RMI 调用，并且不具备在网络上进行列集（marshalling），散集（unmarshalling）以及传送（transmitting）的功能。客户端与 EJB 组件间的通信是进程内的，因此比远程 Home 接口更快。本地 Home 接口不能接受远程方法调用。
在 EJB 3.0 中，会话 Bean 不再强制使用 Home 接口，就是说，它们可以不必实现 Home 接口。而 EJB 3 实体也不再需要 Home 接口了。但是，规范中并没有规定 Home 接口应当消失。
Local Interface（本地接口）- EJB 2.x，EJB 3.0 - 仅允许本地通信的业务接口（EJB 3）技术上的变体或者 EJB 组件的组件接口（EJB 2.x）称为本地接口。它仅允许客户端和组件之间的进程内通信。当一个 EJB 组件只包含本地接口而没有远程接口时，将无法对组件进行远程访问。
M
Managed Entity/Managed Object（受管实体/受管对象）- EJB 3.0 - 受管实体是一个带有持久化性质的 EJB 3.0 实体的实例。该实体目前与一个持久化上下文环境（persistent context）相关联，因此它受实体管理器（Entity Manager）的管理。
Message-Driven Bean（消息驱动 Bean）- EJB 2.x，EJB 3.0 - 消息驱动 Bean（MDB）被用于在 J2EE 和 Java EE 应用程序中实现异步工作流，是消息代理的消息消费者。MDB 可以从消息代理取得异步消息，并进行处理。因而在消息系统的环境中，消息驱动 Bean 作为消息的终点。
消息驱动 Bean 既不包含 Home 接口也不包含组件接口（EJB 1.x，EJB 2.x）或业务接口（EJB 3.0）。注意：EJB 3 规范规定，消息驱动 Bean必须有一个业务接口。具体来说，该业务接口是一个根据使用的具体消息类型的接口。在 EJB 3 中，消息驱动 Bean 的这个接口又叫做业务接口，尽管它比功能性接口更为技术性。由于 MDB 没有一个实际的业务接口，消息驱动 Bean 对客户端是不可见的，即 MDB 不能被直接使用。
Meta-Annotations（元标注）- EJB 3.0 - 元标注是 Java 编程语言的动态语言扩充，它们在 JSR 175 中被引入 JDK 5.0（也叫 Java 1.5）。标注允许在 Java 代码中放置元信息（meta information），这些元信息可以在编译期和运行期被取值。它们可以用来进行代码生成或者控制对象或者 EJB 组件的运行期行为。
Multi-table Mapping（多表映射）- EJB 3.0 - 多表映射表示 EJB 3.0 实体可以被映射到多个物理数据库表格上。除非你显式地在 Bean 管理的持久化中写代码实现，否则 EJB 2.x 不具备这项功能。在 EJB 3.0 里，一个 EJB 3.0 实体不再只有和数据表以 1:1 对应的单一形式了。相反地，它是逻辑业务对象的技术层面的包装器，这个逻辑业务对象的数据可以分布在若干个表格中。在 EJB 3.0 实体中，使用标注（annotations）方便地指明哪些表格/字段是相应数据的来源，也可以在 XML 中指定 O/R 映射。实体管理器则负责在运行期解析关系模型，为 EJB 3.0 实体装载数据（参考图示）。
被映射到三个数据表的 EJB 3.0 实体
@Entity
@Table(name="CUSTOMER")
@SecondaryTables({
@SecondaryTable(name="ADDRESS")
@SecondaryTable(name="TYPE") })
public class Customer implements java.io.Serializable {
private int id;
private String firstName; // from table "CUSTOMER"
private String lastName; // from table "CUSTOMER"
private String street; // from secondary table "ADDRESS"
...
// Attribute from main table ?CUSTOMER“
@Column(name="LASTNAME")
public String getLastName() {
return lastName;
}
...
// Attribute from secondary table "ADDRESS"
@Column(name="STREET", table="ADDRESS")
public String getStreet() {
return street;
}
...
// if no @Column annotation is specified,
// it is assumed that column name equals attribute name
public String getFirstName() {
return firstName ;
}
}
P
Persistence Provider Runtime（持久方案提供者运行时）- EJB 3.0 - “持久方案提供者运行时”这个术语指代 Java Persistence API 的持久化实现的运行期环境。在 Java EE 中，它可能是一个带有集成持久化方案实现的 Java EE 容器，或者一个与第三方持久化方案提供工具实现集成的 Java EE 容器。在 Java SE 中，它是一个单独的持久化方案提供工具的实现（就像 Hibernate）。
Plain Old Java Interface（简单传统 Java 接口，也译作无格式普通 Java 接口）- EJB 3.0 - 这个术语与 2004 年在各种刊物和电子杂志突然出现。“简单传统Java接口/无格式普通Java接口（Plain Old Java Interface，POJI）”这个术语代表一个简单的 Java 接口，这个接口没有被某个基础架构或其他技术层面的关联代码所“污染”。EJB 3.0 的环境中也引入了这个术语。EJB 3.0 的核心思想是，从开发人员的角度看，EJB 组件在使用上以及它们的微架构方面变得不那么复杂。
Plain Old Java Object（简单传统 Java 对象，也译作无格式普通 Java 对象）- EJB 3.0 - 这个术语于 2004 年在各种刊物和电子杂志突然出现。“简单传统 Java 对象/无格式普通 Java 对象（Plain Old Java Object，POJO）”这个术语代表一个简单的 Java 类（或者应该叫做 POJC ;-)），这个类并没有被某个基础架构或其他技术层面的关联代码所“污染”，在更复杂的系统中这种“污染”的情况很典型。EJB 3.0 的环境中也引入了这个术语。EJB 3.0 的核心思想是，从开发人员的角度看，EJB 组件在使用上以及它们的微架构方面变得不那么复杂。目标就是使它们变得简单到可以被视为 POJO。
POJI - EJB 3.0 - Plain Old Java Interface的缩写。
POJO - EJB 3.0 - Plain Old Java Object的缩写。
R
Remote Home Interface（远程 Home 接口）- EJB 1.x，EJB 2.x - 远程Home接口使远程客户能够通过网络创建、加载或者删除 EJB 的实例。客户端使用 RMI/IIOP 协议进行远程方法调用，与远程 Home 接口通讯。在分布式系统中，当网络中任意指定机器上的客户端需要 EJB 时，必须使用远程 Home 接口。
在 EJB 3.0 中，会话 Bean 不再强制使用 Home 接口，就是说，它们可以不必实现 Home 接口。而 EJB 3 实体也不再需要 Home 接口了。但是，规范中并没有规定 Home 接口应当消失。
Remote Interface（远程接口）- EJB 1.x，EJB 2.x - 允许远程通信的业务接口（EJB 3）技术上的变体或者 EJB 组件的组件接口（EJB 1.x，2.x），成为远程接口。当一个 EJB 组件包含远程接口时，其他进程的客户端可以跨越进程和机器的阻隔调用该组件。这个通信方式采用 RMI/IIOP。即便客户端和 EJB 组件在同一个进程中（例如客户端本身就是一个 EJB 组件的情况），并且客户端使用远程接口，通讯方式还是采用 RMI/IIOP。在这种情况下这会导致通讯效率不必要的损耗。改进的方法是使用组件的本地接口，可以使性能得以提升。
S
SFSB - EJB 1.x，EJB 2.x，EJB 3.0 - Stateful Session Bean（有状态会话 Bean）的缩写。
SLSB - EJB 1.x，EJB 2.x，EJB 3.0 - Stateless Session Bean（无状态会话 Bean）的缩写。
版权所有© 2005-2006，由[objects-at-work] Oliver Ihns 和 Stefan M. Heldt 提供。本术语汇编的所有图示均取自我们撰写的文章/书籍《Enterprise JavaBeans komplett》，而非来源于第三方组织。
不错。这文章真的很漂亮。
发表人
占彬 庄
发表于
2007年3月30日 上午2时5分
Re: 不错。这文章真的很漂亮。
发表人
Jason Lai
发表于
2007年3月31日 上午2时6分
thanks
发表人
Jekey stone
发表于
2007年4月2日 上午9时3分
一点意见
发表人
图灵 刘江
发表于
2008年5月9日 上午2时47分
4 条回复
回复