EJB技术概论

Enterprise JavaBean (EJB) 1.1 规范定义了开发和部署基于事务性、分布式对象应用程序的服务器端软件组件的体系结构。企业组织可以构建它们自己的组件，或从第三方供应商购买组件。这些服务器端组件称作 Enterprise Bean，它们是 Enterprise JavaBean 容器中驻留的分布式对象，为分布在网络中的客户机提供远程服务。

两层和三层环境

在两层客户机／服务器环境中，程序员编写与供应商特定软件紧密结合的应用程序。通常，两层应用程序直接从客户机访问数据库服务或事务服务。有时这种应用程序称作胖客户机，因为应用程序逻辑驻留在客户机上，这使客户机变得庞大和复杂。下图描绘了这一特性：

三层客户机／服务器应用程序使用一个中间或中间层，应用程序服务器，它在客户机应用程序和后端数据库之间操作。中间层存储了系统的商业逻辑，并协调客户机上与后端数据库交互的显示。

在两层模型上使用三层体系结构是出于以下两个动机：

改进的可伸缩性、可用性和性能

改良的商业系统灵活性和可扩展性

由于两层系统利用了客户机的处理能力，因而它具有良好的性能，但许多客户机对单一后端资源（如数据库）的特性会产生瓶颈，随着客户机数量逐渐增大，这会抑制可伸缩性、可用性和性能。三层系统试图通过更有效地管理后端资源来消除这个瓶颈。利用资源管理技术，如合用和集群中间层服务器，可以实现这个目标。合用允许许多客户机共享不充足的资源（如数据库连接），这样可以减少后端服务器的工作负荷，从而使三层系统更有效。由于多个服务器和资源可以支持故障恢复并均衡不断增加的客户机数量的负载，因此集群可以使三层系统变得更具可用性和可伸缩性。

三层系统比相应的两层系统更灵活且更可扩展，这是因为商业逻辑和服务（如安全性和事务）都驻留在中间层，并且基本上独立于客户机应用程序。如果正确实现了三层系统，那么在使用 Enterprise JavaBean 的情况下，服务会自动应用于客户机请求，因此服务是看不见的。由于服务对于客户机不可见，因此对服务的更改也不可见。如果正确实现了三层系统，那么中间层上对商业逻辑的更改和增强也可对客户机应用程序隐藏。

另外，如果客户机与中间件组件是以 Java 编程语言实现的，那么它们极有可能具有可移植性。可以非常容易地将实现客户机和应用程序服务器的类文件重新安置到当前最合适的主机上。

在最近二、三年中，一些供应商发布了基于 Java 的三层应用程序服务器，这些服务器全都可以与后端服务器操作交互，并管理这些操作。尽管这些中间件产品支持分布式体系结构，这些体系结构在两层设计上（以及 Java 之前的应用程序服务器）做了非常重大的改进。它们的主要限制是编程模块越来越趋向于特定于某个供应商。这意味着公司必须大量购买一家供应商的型号，而且系统是不可移植的，从而导致了供应商锁定。

随着面向对象编程范例日益普及，分布式对象系统已经逐渐壮大。现在已经存在一些分布式对象技术。最流行的是由 Object Management Group 创建的 CORBA、Sun Microsystems 的 Java RMI (JRMP) 和 Microsoft 的 DCOM 和 MTS（又名 COM+）。每种都有其自身的优缺点。Sun Microsystems 的 Enterprise JavaBean 是最新加入这个圈子的技术。在某些方面，它既是这些技术的竟争者，同时也是合作者。

由于在三层计算中使用了其它开放标准（如 LDAP），CORBA（公共对象请求中介体系结构）在解决供应商垄断问题方面取得了成功。不幸的是，虽然 CORBA 根本改变了分布式计算，但经验证编程模块太复杂，而且供应商不能一致地遵守规范。CORBA 有高级的分布式计算，但已证明太难而无法实现，并且其可移植性也比预期差。

Enterprise JavaBean (EJB) 是 Sun Microsystems 对 CORBA 的可移植性和复杂性的解决方案。EJB 引入了比 CORBA 更简单的编程模块，它可以让开发人员创建可移植分布式组件，称作 Enterprise Bean。EJB 编程模块可以让开发人员创建安全的、事务性的和持久的商业对象 (Enterprise Bean)，该对象使用非常简单的编程模块和声明属性。与 CORBA 不同，例如访问控制（授权安全性）和事务管理等设施非常易于编程。CORBA 需要使用复杂的 API 来利用这些服务，而 EJB 则根据一种称作“部署描述信息”的特性文件中的声明将这些服务自动应用到 Enterprise Bean。这个模型确保了 bean 开发人员可以集中精力编写商业逻辑，而容器会自动管理更复杂但又必要的操作。

由于 EJB 规范颁布了一组明确的 EJB 容器（供应商服务器）和 EJB 组件（商业对象）之间的契约，因此 EJB 中实现了可移植性。这些契约或规则确切规定容器必须为 Enterprise Bean 提供什么服务，bean 开发人员需要使用什么 API 和声明属性来创建 Enterprise Bean。由于详细指定了 Enterprise Bean 的生命周期，因此供应商知道如何在运行时管理 bean，bean 开发人员确切知道 Enterprise Bean 在其存在期间可以做什么。

Enterprise JavaBean 简化了分布式对象的开发、部署和访问。EJB 分布式对象（一种 Enterprise Bean）的开发人员只需依照为 Enterprise JavaBean 建立的契约和协议实现对象。支持 EJB 的应用程序服务器可以，也确实，使用任何分布式网络协议，包括本地 Java RMI 协议 (JRMP)、专有协议或 CORBA 的网络协议 (IIOP)。不管在某个特定产品中使用的基本网络协议是什么，EJB 使用相同的编程 API 和语义以 Java RMI-IIOP 访问分布式对象。协议的细节对应用程序和 bean 开发人员隐藏；对于所有供应商来说，定位和使用分布式 bean 的方法是相同的。

注：Enterprise Bean 与 JavaBean 不同。JavaBean 是使用 java.beans 包开发的，它是 Java 2 标准版的一部分。JavaBean 是一台机器上同一个地址空间中运行的组件。JavaBean 是进程内组件。Enterprise Bean 是使用 javax.ejb 包开发的，它是标准 JDK 的扩展，是 Java 2 Enterprise Edition 的一部分。Enterprise Bean 是在多台机器上跨几个地址空间运行的组件。因此 Enterprise Bean 是进程间组件。JavaBean 通常用作 GUI 窗口小部件，而 Enterprise Bean 则用作分布式商业对象。

EJB的专用术语解释

Bean

　　Bean是Enterprise Java Bean的缩写，一个Bean扮演着应用程序素材的角色。她包含有一个functional interface，一个life-cycle interface，以及一个实做它所支援的商业方法的类别。

　　Bean Instance（Bean实例）

　　一个Bean Instance是Bean位于一个容器中的instantiation，如果把bean比作class，那么Bean Instance就是Java Object。

　　Bean-managed persistence（Bean自己所管理的永续性）

　　这个术语是用来描述Enterprise Java Bean如何来存储它们的state到数据库或者是其他的存储机制。容器将促使Bean呼叫Bean的EjbLoad()和EjbSave()方法。

Container（容器）

　　一个Bean的容器会实做bean的home interfaces与remote interfaces。它应该提供一组公用程序类别以便能够隐藏bean instances，介入方法调用，维持交易完整性与bean instances池的一般管理。虽然Ejb规则中规定一个容器必须管理超过一种以上的bean，不过通常每个容器只有一个bean。

　　Container-managed demarcation

　　对于一个enterprise bean，不论何时，当其中的一个商业方法被呼叫，容器便自动启动一项新的交易。商业方法完成后，交易就结束了。容器启动交易的形式由bean的交易属性来决定，或者，由商业方法本身来决定（如果有指明的话）。

　　Container-managed persistence（委托容器管理的永续性）

　　Bean开发者可以委托容器来负责记录Bean的最新状态。Bean的状态必须由Bean中的许多public Fields得到。容器可以确保这些public fields在任何bean的方法被唤醒之前为正确的。public fields必须在deployment descriptor中定义，然后才产生container classes。

　　Entity beans

　　Entity beans 代表可以辨认的永续物件。典型的实例就是：它可以代表关系数据库中个别的rows。当然，也可以是档案系统中的档案，或者是任何其他独一无二的可辨识资料。

　　Home

　　每一个Enterprise Bean，不论是Session或者是Entity bean，都有一个interface来让客户端能够建立与移除一个bean instance。以Entity为例，home interface 提供一些方法以允许客户端对于一个bean instance来作定位用。这个interface遵循Java RMI interface的规定。每个home interface都继承自一个远端界面，即EJBHome。

　　Remote

　　一个bean的remote interface 描述对于一个bean instance中可供客户端呼叫的方法集合。这个interface 遵循Java RMI interface的规定。每个remote interface都继承自一个远端界面，即EJBObject。

　　Session beans

　　Session beans为 particular client所建立。如果经过一段被称为timeout的指定空闲时间之后，就不再存在。

　　Session synchronization

　　Session beans 可选择性地实做Session Synchronization interface。这样可以允许Session beans在交易将完成之前与完成之后被通知。session bean可以使用beforeCompletion()方法来否决交易的成功完成，并且能够使用afterCompletion()来判断交易成功与否。

　　Transaction Attribute （交易属性）

　　一项transaction attribute可以用在bean与其特殊的商业方法上。其可能的值有六种，分别是TX_NOT_SUPPORTED,TX_REQUIRED,TX_SUPPORTS,TX_REQUIRES_NEW,TX_MANDATORY,TX_BEAN_MANAGED。

from?javaresearch.org

EJB的编程限制

EJB的编程限制

2003-6-16　Matrix让你不断进步 浏览选项： 颜色 默认 灰度 橄榄色 绿色 蓝色 褐色 红色 本文已被浏览 21 次

Enterprise JavaBeans(EJB)是一个开发和部署分布式服务器端的、带事务处理的、安全的商业组件的规范和结构。EJB的体系结构是J2EE的基础和核心，J2EE定义了整个标准的应用开发体系结构和一个部署环境。在这个体系结构中，应用开发者的注意力集中在封装商业逻辑和商业规则上，一切与基础结构服务相关的问题和底层分配问题都由应用程序容器或服务器来处理。

甚至，从属于事务、持久化、安全等等方面的应用组件的运行时属性都可以使用高度灵活的声明方法在部署的环境中定制。这个体系结构定义了一个容器和一个服务器模型－－容器是应用组件生存和执行的环境，而这个容器却又寄居在一个服务器之中。J2EE平台提供了一个简化的开发模型，它具有工业强度的可扩展性、支持合理的集成和灵活的部署，与开发商和应用服务器无关，这一切使得一些专用的应用服务器和专用的分布式对象框架变得古旧了。

EJB的角色和责任

EJB规范定义了几个标准的角色和责任者，如下：

1.EJB服务器提供商提供的应用服务器应是一个在分布式事务处理、系统服务等方面的专家。

2.EJB容器提供商提供EJB组件实例运行环境和部署工具。EJB 服务器/容器提供商是典型的操作系统开发商、数据库开发商或者是应用服务器开发商。EJB的服务器和EJB的容器应是同一个开发商提供，因为无论是在现在的EJB1.1规范（最终版）还是EJB2.0公共草稿版（正在修改）中都没有定义两者之间的接口。

3.Bean的提供商或者EJB开发者开发的EJB组件都包涵商业逻辑及商业功能。EJB开发者提供的每一个EJB组件都应满足以下条件：EJB的实现中应包括所有必须有的组件－容器合同方法（Contract method），如：ejbCreate(),ejbRemove()等等和一些商业方法（business method）；Home接口；Remote接口；如需要还应有帮助类。Home接口为创建、删除和查找EJB实例的方法提供签名，Remote接口定义了商业方法的签名。

4.应用程序组装器把一些由Bean提供商开发的EJB组件组装成一个完整的J2EE应用程序。

5.部署器在应用程序部署的目标产品环境中是专家，它在应用服务器中安装应用组件并配置它们的事务、持久化和安全方面。这样你就可以管理复杂的问题了，诸如：事务处理、并发处理、持久化以及安全。

6.系统管理者负责服务器的配置和管理、运行监控和负载平衡。

7.应用程序的用户界面开发者负责用户界面和表示逻辑。

这篇文章的焦点集中在Bean提供商/EJB开发者方面和EJB组件实现代码的限制方面。

EJB组件的约束

EJB的开发者并不需要在EJB的组件实现代码中编写系统级的服务，EJB提供商/开发者需知道并且严格地遵守一些限制，这些限制与开发稳定的和可移植的EJB组件的利益有关。

以下是你应该回避使用的一些Java特色，并且在你的EJB组件的实现代码中要严格限制它们的使用：

1.使用static，非final 字段。建议你在EJB组件中把所有的static字段都声明为final型的。这样可以保证前后一致的运行期语义，使得EJB容器有可以在多个Java虚拟机之间分发组件实例的灵活性。

2.使用线程同步原语来同步多个组件实例的运行。避免这个问题，你就可以使EJB容器灵活的在多个Java虚拟机之间分发组件实例。

3.使用AWT函数完成键盘的输入和显示输出。约束它的原因是服务器方的商业组件意味着提供商业功能而不包括用户界面和键盘的I/O功能。

4.使用文件访问/java.io 操作。EJB商业组件意味着使用资源管理器如JDBC来存储和检索数据而不是使用文件系统API。同时，部署工具提供了在部署描述器（descriptor）中存储环境实体，以至于EJB组件可以通过环境命名上下文用一种标准的方法进行环境实体查询。所以，使用文件系统的需求基本上是被排除了。

5.监听和接收socket连接，或者用socket进行多路发送。EJB组件并不意味着提供网络socket服务器功能，但是，这个体系结构使得EJB组件可以作为socket客户或是RMI客户并且可以和容器所管理的环境外面的代码进行通讯。

6.使用映象API查询EJB组件由于安全规则所不能访问的类。这个约束加强了Java平台的安全性。

7.欲创建或获得一个类的加载器，设置或创建一个新的安全管理器，停止Java虚拟机，改变输入、输出和出错流。这个约束加强了安全性同时保留了EJB容器管理运行环境的能力。

8.设置socket工厂被URL´s ServerSocket,Socket和Stream handler使用。避免这个特点，可以加强安全性同时保留了EJB容器管理运行环境的能力。

9.使用任何方法启动、停止和管理线程。这个约束消除了与EJB容器管理死锁、线程和并发问题的责任相冲突的可能性。

通过限制使用10－16几个特点，你的目标是堵上一个潜在的安全漏洞：

10.直接读写文件描述符。

11.为一段特定的代码获得安全策略信息。

12.加载原始的类库。

13.访问Java一般角色所不能访问的包和类。

14.在包中定义一个类。

15.访问或修改安全配置对象（策略、安全、提供者、签名者和实体）。

16.使用Java序列化特点中的细分类和对象替代。

17.传递this引用指针作为一个参数或者作为返回值返回this引用指针。你必须使用SessionContext或EntityContext中的getEJBObject()的结果。

Java2平台的安全策略

以上所列的特点事实上正是Java编程语言和Java2标准版中的标准的、强有力的特色。EJB容器允许从J2SE中使用一些或全部的受限制的特色，尽管对于EJB组件是不可用的，但需通过J2SE的安全机制来使用而不是通过直接使用J2SE的API。

Java2平台为EJB1.1规范中的EJB容器所制定的安全策略定义了安全许可集，这些许可在EJB组件的编程限制中出现。通过这个策略，定义了一些许可诸如：java.io.FilePermission,java.net.NetPermission,java.io.reflect.ReflectPermission,

java.lang.security.SecurityPermission,以便加强先前所列出的编程限制。

许多EJB容器没有加强这些限制，他们希望EJB组件开发者能遵守这些编程限制或者是带有冒险想法违背了这些限制。违背这些限制的EJB组件，比标准方法依赖过多或过少的安全许可，都将很少能在多个EJB容器间移植。另外，代码中都将隐藏着一些不确定的、难以预测的问题。所有这些都足以使EJB组件开发者应该知道这些编程限制，同时也应该认真地遵守它们。

任何违背了这些编程限制的EJB组件的实现代码在编译时都不能检查出来，因为这些特点都是Java语言和J2SE中不可缺少的部分。

对于EJB组件的这些限制同样适用于EJB组件所使用的帮助/访问（helper/access）类，J2EE应用程序使用Java文档（jar）文件格式打包到一个带.ear（代表Enterprise Archive）扩展名的文件中，这个ear文件对于发送给文件部署器来说是标准的格式。ear文件中包括在一个或多个ejb－jar文件中的EJB组件，还可能有ejb－jar所依赖的库文件。所有ear文件中的代码都是经过深思熟虑开发的应用程序并且都遵守编程限制和访问许可集。

未来版本的规范可能会指定通过部署工具来定制安全许可的能力，通过这种方法指定了一个合法的组件应授予的许可权限，也指定了一个标准方法的需求：如从文件系统中读文件应有哪些要求。一些EJB容器/服务器目前在它们的部署工具中都提供了比标准权限或多或少的许可权限，这些并不是EJB1.1规范中所需要的。

理解这些约束

EJB容器是EJB组件生存和执行的运行期环境，EJB容器为EJB组件实例提供了一些服务如：事务管理、安全持久化、资源访问、客户端连接。EJB容器也负责EJB组件实例整个生命期的管理、扩展问题以及并发处理。所以，EJB组件就这样寄居在一个被管理的执行环境中－－即EJB容器。

EJB容器也是EJB组件和外部世界的中间者，它提供了客户连接服务来允许应用程序客户访问和使用EJB组件所提供的功能，EJB容器通过bean的Remote和Home接口介入每一个对EJB对象方法的调用。

EJB容器也是EJB组件和访问其它各种资源和服务的中间人，因为EJB容器介入应用组件和J2EE服务，它可以透明地引入组件部署描述符所定义的服务，如：事务管理、安全、持久化、并发处理和状态管理。

资源就是一个封装了访问资源管理器的对象，因为一个资源工厂就是一个用来建造资源的对象。例如，一个JDBC连接代表一个实现了java.sql.Connection接口的对象，它是用来提供访问数据库管理系统的资源，并且实现了javax.sql.DataSource接口的对象是一个这样JDBC连接的资源工厂。同样，定义了许多获得JMS、JavaMail以及URL连接的资源工厂，目前除此之外没有其它的资源工厂了。

（J2EE连接体系结构，目前正在修改，将期盼着包括J2EE未来版本的规范，这个连接体系结构定义了标准的资源适配器和依附于连接、事务、安全管理的合同，所以应用服务器将以标准和统一的方式插入各种企业信息系统，包括ERP（如SAP R/3），主框架事务处理系统和数据库系统。

因为EJB容器完全负责EJB组件的生命期、并发处理、资源访问、安全等等，所以与容器本身的锁定和并发管理相冲突的可能性就需要消除，许多限制都需要使用来填上潜在的安全漏洞。除了与EJB容器责任与安全冲突的问题，EJB组件还意味着仅仅聚焦于商务逻辑，它依赖于EJB容器所提供的服务而不是自己来直接解决底层的系统层的问题。

可能的问题

通常，EJB组件在容器之间的移植不可避免地与如下问题相关：

1.它需要依靠的受限制的特点在特定EJB容器中没有得到加强。

2.它需要依靠的非标准的服务从容器中可获得。

为了保证EJB组件的可移植性和一致的行为，你应该使用一个具有与Java2平台安全策略集相一致的策略集的容器来测试EJB组件，并且其加强了前述的编程限制。

总结

EJB组件开发者应该知道这些推荐的关于EJB组件的编程限制，明白它们的重要性，并且从组件的稳定性和可移植性利益方面考虑来遵循它们。因为这些编程限制能阻止你使用标准的Java语言的特点，违背了这些编程限制在编译时不会知道，并且加强这些限制也不是EJB容器的责任。所有这些原因都使你应很小心地遵守这些编程限制，这些限制在组件的合同中已经成为了一个条款，并且它们对于建造可靠的、可移植的组件是非常重要的。