部署过程
Enterprise JavaBeans (EJB) 组件是在称为部署的特定过程中安装的。由容器组件提供对部署过程的支持。在高级别上，部署由下列步骤组成：
EJB 组件的开发人员编写 bean 的 Java 源文件，此文件包含为这个 bean 提供功能的业务逻辑方法，还包括 ejbCreate() 方法。bean 类还必须实现 javax.ejb.SessionBean 接口或 javax.ejb.EntityBean 接口。此外，bean 的开发人员编写接口文件，定义对 javax.ejb.EJBHome 接口和 javax.ejb.EJBObject 接口的扩展。EJBHome 接口的扩展，称为 bean 的本地接口，包含一个创建方法，并且如果 bean 是一个实体 bean，它还会包含一个 finder 方法。EJBObject 接口的扩展，称为 bean 的远程接口，指定在 bean 本身中定义的业务逻辑方法。
bean 的开发人员提供由部署描述符、环境属性和清单式文件组成的控制信息。
部署描述符是 javax.ejb.deployment.SessionDescriptor 对象或 javax.ejb.deployment.EntityDescriptor 对象的序列化实例。 环境属性作为键-值对存储在一个文件中，可通过 java.util.Properties 对象访问此文件。 清单式文件是标识企业级 bean 及其相关文件所必需的。企业级 bean 的类文件、这两个接口的类文件、部署描述符文件、环境属性文件和清单式文件都是使用名为 ejb-jar 的文件格式归档的。所生成的 ejb-jar 文件提供给容器，作为部署过程的输入。
在部署时，容器分析 ejb-jar 文件的内容，并采取必要的操作使此 bean 可用。这些操作包括：生成实现 bean 的本地和远程接口的新 Java 类，将本地接口实现绑定到 JNDI 命名空间中，生成桩模块和 skeleton helper 类，后者是支持 RMI 通信所必需的。容器也可以生成 bean 的子类，并入容器专用的代码，以方便对 bean 的管理。部署时由容器生成的类通常是容器专用的，而不像 EJB 组件本身那样具有可移植性。
持久性、事务和安全
在为 EJB 组件提供持久性、事务和安全服务方面，EJB 容器可扮演主要角色。是将这些服务的职责指定给容器，还是假定职责由 bean 自身负责，EJB 规范为 bean 的开发人员提供了灵活性。例如，对实体 bean 的持久性支持既可以由 bean 管理，也可以由容器管理。如果 EJB 组件开发人员选择使用容器管理式持久性，他们就会在部署描述符中添加一个称为 containerManagedFields 的属性。根据 EJB 规范：
除了支持容器管理式持久性以外，EJB 体系结构还支持容器对事务的管理。该规范规定：
“Enterprise JavaBeans 是一种高级组件框架，它试图使应用程序开发人员不面对系统的复杂性。因此，大多数企业级 bean 及其客户机不需要通过程序访问事务管理。”(Enterprise JavaBeans Specification 1.0)
当 bean 的开发人员依赖容器进行事务管理时，就称为容器管理式定界，容器使用在部署时提供的事务属性：
“无论客户机何时调用企业级 bean，容器都会介入这个方法调用。这种介入允许容器通过事务属性显式控制事务定界。例如，如果企业级 bean 部署了 TX_REQUIRED 事务属性，则无论何时，只要客户机调用支持事务的企业级 bean，容器就会自动启动事务，而客户机并不与任何事务上下文相关联。”( Enterprise JavaBeans Specification 1.0)
如果开发人员选择在 bean 内支持事务，则他们在部署描述符中指定 TX_BEAN_MANAGED 事务属性，然后就可以在 bean 自身内部自由使用 javax.transaction.UserTransaction 接口划分事务边界。通过认出 TX_BEAN_MANAGED 事务属性，容器就能知道不必介入事务支持。
通过增强 AccessControlEntry 对象和 RunAs 安全标识中指定的限制，容器为 EJB 组件提供安全支持。AccessControlEntry 对象在 bean 级别上或针对单个方法，将 Identity 对象与企业级 bean 相关联。Identity 对象反映允许调用 bean 的方法的用户或角色。当容器试图访问数据源或另一个 bean 时，它们也会将 RunAs 安全身份应用于 EJB 组件。可将 RunAs 身份设置为等同于某个特定用户帐户、有权限的系统帐户或客户机安全身份。访问控制和 RunAs 的信息是 bean 的开发人员在部署描述符中指定的，将影响容器管理 bean 的与安全有关的行为方式。
虽然 EJB 1.0 规范也提到安全问题，但更详细的安全功能定义，见该规范的后续版本。
CORBA 和 EJB 技术的关系
公用对象请求代理程序体系结构 (CORBA) 为分布式对象的平台中立和语言中立的计算环境奠定了基础。在 CORBA 环境中，功能驻留于对象之中，而客户机可通过对象请求代理程序 (ORB) 访问这些对象。完整的 CORBA 实现提供 ORB，外加称为 CORBA 对象服务和 CORBA 公用工具的几个运行时服务。也可只提供 ORB，不提供相关联的对象服务和公用工具（例如，IBM 就提供这样的两种独立 ORB）。实现基本 ORB 功能的软件称为 ORB 核心。为了支持语言无关性，CORBA 应用程序是用接口定义语言 (IDL) 编写的。该语言在语法上类似于 C++，但不包含语义：IDL 中指定的操作是操作接口，而不是操作实现。由于它对多种平台和多种语言的支持，以及源自其分布式特征的可伸缩性，CORBA 非常适合于管理企业规模的信息系统。
设计 EJB 规范也是为了支持企业信息系统。这样说来，CORBA 是一个竞争者吗？根据 Frequently Asked Questions for Enterprise JavaBeans，答案是否定的：
“实际上，EJB 技术很好地补充了 CORBA。CORBA 提供了一个强大的基于标准的基础结构，可在此结构之上构建 EJB 服务器。EJB 技术使得在 CORBA 基础结构的顶层构建应用程序变得更为容易。”（Enterprise JavaBeans 常见问题解答）
虽然 EJB 规范和 CORBA 规范说明的是不同的技术，但 EJB 实现目前利用 CORBA 技术的某些方面。一个例子就是 RMI/IIOP。EJB 规范要求 EJB 组件及其容器使用 Remote Method Invocation (RMI) 技术，实现分布式对象之间的方法调用。 RMI 规定远程方法的语法和语义，但并不规定应使用何种传输协议提供网络连接。CORBA Internet 对象请求代理程序间协议 (IIOP) 基本上定义了通过 TCP/IP 传输 CORBA 消息的一种方法。开发使用 IIOP 消息形式交换 RMI 数据的 EJB 实现，说明了 EJB 应用程序怎样才能有效地使用 CORBA 技术的各部分。这种网络也支持与 CORBA 应用程序的互操作性，后者使用 IIOP 发送本地 CORBA 消息，与 RMI 无关。IBM 的 EJB 实现，即 WebSphere Application Server，优化了 IIOP 的使用，方法是，弄清楚分布式对象何时驻留在同一台服务器上，并且只在对象确实在远程时才调用 IIOP。
为了方便既并入 EJB 技术，又并入 CORBA 技术的企业系统的开发，Sun Microsystems 在 EJB 规范和 CORBA 之间创建了一种映射。将 EJB 体系结构映射到 CORBA，影响到 EJB 技术的几个方面，包括对象分布、命名和事务。CORBA 映射的主要目的是，保证不同厂商构建的 EJB 服务器之间的互操作性。互操作性提供以下好处：
CORBA 客户机可以访问部署在基于 CORBA 的 EJB 服务器上的 EJB 组件 客户机程序在事务中可以将对 CORBA 对象的调用，与对企业级 bean 的调用混合在一起 事务可以跨多个 bean，而这些 bean 又位于来自不同厂商的基于 CORBA 的多台 EJB 服务器上 使用来自某个厂商的 ORB 的客户机，可以访问另一个厂商基于 CORBA 的 EJB 服务器上的 bean对于要访问 EJB 组件的 CORBA 客户机来说，bean 接口被映射到 IDL。例如，可将股票交易 bean 中定义的 buy() 和 sell() 方法，指定为 IDL 文件中的 CORBA 操作。非 bean 的 CORBA 客户机，如 C++ 客户机，可以访问这个 bean，并用标准 CORBA 调用来调用 bean 的方法。如果容器使用 IIOP 作为它的分布式对象协议，则该容器的职责是，生成与企业级 bean 及其接口对应的 IDL。
EJB 命名服务，它以“CORBA 对象服务”命名服务为基础，使 EJB 组件可用于 CORBA 客户机。Java Naming and Directory Interface (JNDI) 可提供到 CORBA 命名服务的接口，同时，客户机既可以通过 JNDI 调用间接访问基础命名服务，也可以通过“CORBA 对象服务” (COS) 命名 API 直接访问该服务。
EJB 事务支持依赖于 CORBA Transaction Service，即 Object Transaction Service (OTS)。Java Transaction Service (JTS) 代表 OTS 的 Java 绑定，它是语言中立的。基于 CORBA 的 EJB 容器必须识别 CORBA 客户机通过 OTS 接口发出的事务边界，以及 EJB 应用程序通过 Java Transaction API (JTA) 接口发出的事务，JTA 是到 JTS 的应用程序级接口。JTA 还代表 Open Group XA 接口的 Java 绑定，以便将应用程序资源连接到外部事务管理器。JIA 中含存的 javax.transaction.UserTransaction 接口，为事务边界的应用程序级控制提供 API。UserTransaction 接口，既可由其事务属性设置为 TX_BEAN_MANAGED 的 bean 使用，以可由 Java 客户机使用。
使用 EJB 组件
因为 EJB 体系结构被设计为高度灵活的，并支持使用任意复杂的方式连接企业级 bean，所以可构建许多不同的方案，来说明应用程序可怎样使用企业级 bean。一个有用的方案提出将 EJB 组件表示为三层信息系统的关键组件，该系统将企业数据、事务和应用程序资源连接到 Web 上。
基于 EJB 的三层编程模型视 Web 浏览器为第一层，视支持应用程序的 Web 服务器为第二层，视企业信息资源为第三层。在此编程模型中，除了 EJB 技术外，还实现了 Java servlet 技术、JavaBeans 技术和 Java Server Page (JSP) 技术。下图显示了各层的排列情况：
第一层是瘦客户机 -- 通常是 Web 浏览器，它可以处理普通 Web 数据类型，如 HTML 和 GIF，并支持 HTTP 通信。第二层是 Web 应用程序服务器，它是用代码扩充的 Web 服务器，用来对能够通过 Web 服务器调用的应用程序提供运行时支持。现有的 Web 应用程序都沿用 CGI-BIN 编程模型，但预计第二层应用程序开发将转向 Java servlet 编程模型，后者提供大幅改善的性能和可移植性。除支持 Java servlet 外，Web 应用程序服务器还将添加 EJB 服务器功能，以支持使用 EJB 组件的应用程序。第三层代表企业级信息资源，可以包括关系数据库和面向对象的数据库、事务监视器和定制的应用程序。EJB 技术在这一设计中扮演着关键角色，因为，它使驻留在第二层上的应用程序组件，与组成第三层的企业资源之间的接口，得以标准化。
Java servlet、Java beans 和 Java server page 不是 EJB 应用程序方案的必需元素，但它们可与 EJB 组件一起工作，以提供基于 Java 的内聚性的应用程序环境。此处描绘的环境将以下职责指定给参与工作的 Java 组件：
给 Java servlet 指定了应用程序“控制器”的角色 JSP 页面处理数据表示和用户界面的任务 Java bean 充当“数据封装器”，存储中间结果的数据 EJB 组件提供访问企业信息资源的机制客户可以使用一个假定的、基于 EJB 的 Web 应用程序更新现有的库存，并用容器管理式持久性和容器管理式事务，将访问库存数据库的位置封装在实体 EJB 组件的内部。库存票据可通过 Web 浏览器输入，浏览器提供一个 HTML 表单来捕获产品编号、供应商，等等，并在提交时调用一个 servlet。servlet 代码充当应用程序控制器角色，确定哪些企业数据库需要更新，需要用户追加什样的信息。servlet 可通过代表它的实体 bean 访问主库存数据库，并调用 JNDI 接口获取对此 bean 的本地对象的引用，然后使用 finder 方法定位所请求产品编号的远程对象。此时，通过调用远程对象的方法，servlet 可更新库存计数，接着容器将此方法委托给 EJB 组件。因为容器根据数据库更新，以对 bean 透明的方式划分一个事务，而且以对 bean 透明的方式将数据写入数据库来保证数据持久性，所以也就保持了数据的完整性。
从 EJB 组件返回到 servlet 的任何结果信息，都可以使用 setter 方法存储在一个（非企业的） Java bean 的属性中。此时 servlet 可将控制权转让给一个适当的 JSP 页面，以便将这些结果组合到表示格式中，并将结果返回给用户。JSP 页面很可能主要由静态文本和有关单个事务的可变信息占位符组成。在向浏览器发送表示数据之前，JSP 页面使用 getter 方法从 Java bean 的属性中获得可变数据元素。
基于 EJB 的三层设计提供了几个好处，包括：
访问企业数据的业务逻辑可封装在可重用、可移植的企业级 bean 中。 现有的企业系统只需很少修改或者根本不需要修改，就可以集成为企业级 bean。 企业应用程序所需的运行时服务，如事务和持久性，可以从 bean 中分解出来，并指定给此 bean 的容器。 无须更改 EJB 组件，即可修改控制应用程序流程的 Servlet。 Servlet 代码可将注意力集中在应用程序控制逻辑上，而无须考虑数据表示。 JSP 页面可将静态和动态内容混合在一起，生成表示信息。 用 Java 语言编写的系统组件，对于具有 JVM 的任何平台都是可移植的。结论
在开发能够支持关键任务的企业级信息系统的过程中，EJB 规范代表了 Java 技术的下一个发展阶段。EJB 组件将随 JavaBeans 规范引入的 Java 组件模型，扩展到服务器领域，从而使业务逻辑组件的开发可以跨企业应用程序重用，并且可以跨支持 Java 的平台移植。由于包含了基于 RMI 技术的对象分布，所以支持跨多层的可执行组件的分立，从而允许最大的实现灵活性和高度可伸缩性。如果将常规的企业应用程序运行时服务重新定义为可指定给容器抽象的对象服务，则允许 EJB 组件的开发人员将精力集中在业务逻辑上，从而减小了通常与运行时服务相关的复杂性和平台相关性。
增强 Java 运行环境，以包括命名和目录服务的标准接口、关系数据库访问、事务服务和远程对象访问，使 Java 开发人员能够编写强健的企业应用程序，而不必离开 Java 编程环境。将其它 Java 技术 -- 如 Java servlet 和 JavaServer Pages 技术 -- 与 EJB 组件一起使用，可创建一个对于大型企业系统来说足够强健的紧凑编程模型，但由于使用了巧妙的接口，从而简化了开发工作。而且，因为 EJB 体系结构是 JavaBeans 组件模型的逻辑扩展，所以作为 EJB 组件开发的业务逻辑可跨多个企业应用程序重用。
企业级 bean 体系结构的另一个好处是，提供了现有企业信息系统的直接集成通道，此通道可能与 Java 编程语言或 bean 编程模型毫无共同之处。因为现有的企业信息资源 -- 如关系数据库、事务监视器和业务应用程序的定制新品种 -- 可通过将它们封装在 EJB 组件中连接到 Web 前端，而无须替换应用程序或重写主要代码段，所以，客户可保护其现有的 IT 投资。
考虑到 EJB 技术的巨大前景，IT 业界以相当大的兴趣欢迎 EJB 规范，就不是什么令人惊讶的事了。EJB 体系结构提供的一个最大好处可能是，把业务逻辑编程与将业务逻辑和企业级服务器端运行环境的复杂集成分离开来。如果部署了 EJB 组件的容器承担了管理运行时服务（如持久性、事务和并发数据库访问）的职责，则 bean 的开发人员就可以自由地将精力集中在开发封装业务逻辑的软件组件上。JavaSoft 副总裁表述了 EJB 技术的重要性（引自 Sun Microsystems 网站）：
“‘Enterprise JavaBeans API 将为企业开发人员和解决方案提供商提供一种新的战略武器，供他们建立下一代行业领先的、基于关键业务的应用程序，’Sun Microsystems 的 JavaSoft 软件产品部副总裁，Jon Kannegaard 说：‘因为用 Enterprise JavaBeans API 设计的应用程序将与现有的企业系统一起工作，所以企业利用 Java 平台会获得新的竞争优势，同时还保留他们对现有技术的投资，’Kannegaard 继续说。
本文地址：http://com.8s8s.com/it/it12903.htm