一、两种引用类型

　　为了从其他EJB组件访问某个Bean，容器提供了一种特殊的机制。这种机制允许一个Bean提供者通过称为EJB引用的“逻辑名字”引用另一个EJB的Home。EJB容器利用应用的部署描述器为EJB构造环境，而这些引用在部署描述器中作为特殊的项目声明。在部署描述器中，部署者把组件代码中要用到的EJB引用绑定到其他被引用EJB的Home。

　　如前所述，在EJB 2.0规范出现之前，在一个EJB中引用其他Bean只有一种方法，即通过远程接口，它要求进行跨越网络的远程过程调用。如果某个事务由多个Bean协作完成，通过网络进行多个对象的汇集和释放将是一项相当繁重的工作。

　　EJB 2.0规范新增了一种本地接口类型，允许在同一容器之内的Bean直接互相引用，避免了远程接口的网络开销。本地接口是一种标准的Java接口，而不是从RMI继承得到。EJB组件的定义可以包含本地接口或远程接口，或者两者都定义。

　　本地引用的指定方式和传统的远程引用一样，即在部署描述器中指定。事实上，本地引用的部署描述元素与远程引用的描述元素完全对应。

　　下面的代码片断是一个典型的远程引用：

Product
ejb/Product
Entity
com.xyz.widgets.ProductHome
com.xyz.widgets.Product
../products/product.jar#Product

　　下面的代码片断是同一Bean的本地引用：

Product
ejb/Product
Entity
com.xyz.widgets.ProductHome
com.xyz.widgets.Product
../products/product.jar#Product

　　下表简要说明了各个元素的用途：

　　二、创建本地接口，通过本地接口访问EJB

　　要把一个现有的远程接口改为本地接口，有三个地方必须修改：部署描述器，Bean的接口，以及对EJB的调用。前面我们介绍了如何通过部署描述器指定一个本地引用，现在我们要把远程接口转换成本地接口，然后修改JNDI查找调用，让它使用新的本地接口。

　　■ Home接口

　　指定Home接口时，现在必须导入的是“javax.ejb.EJBLocalHome”，而不是“javax.ejb.EJBHome”。接口的声明也必须改变，让它从“EJBLocalHome”（一个标准Java接口）继承，而不是从“EJBHome”（一个RMI接口）继承。同时，从该接口定义的方法中唯一应该抛出的异常是javax.ejb.CreateException，而java.rmi.RemoteException异常则不再必要。

　　■ 本地接口

　　指定本地接口时，现在必须导入“javax.ejb.EJBLocalObject”，而不是“javax.ejb.EJBObject”。接口声明也必须改变，让它从“EJBLocalObject”（一个本地接口）继承，而不是从“EJBObject”（一个RMI接口）继承。

　　■ 执行调用

　　创建好接口、设置好部署描述器之后，剩下的工作就是执行JNDI调用，查找对其他EJB的引用。调用Bean的远程接口时，javax.rmi.PortableRemoteObject的“narrow()”方法汇集经过RMI的调用。对于本地引用，这种开销就不再必要，这时只需简单地进行JNDI查找并进行适当的类型定型。下面是一个例子：

　　home = (ProductHome) initCtx.lookup("java:comp/env/ejb/Product");

　　它不仅提高了效率，而且代码也比用来获取远程接口的代码更直观易懂。

　　本地接口使得处于同一容器内的两个EJB组件能够更高效地进行通信。对于实体Bean的应用来说，这种技术尤其有用，因为与客户程序直接访问实体Bean相比，在实践中，通过会话Bean访问实体Bean得到了更广泛的认可。

在现今的技术条件下，何时以及是否使用 EJB 组件是方案小组面临的一个十分烦人的问题。为帮助你做出正确决定，我们准备了一些问题，以供你在考虑从其它技术转移到 EJB 组件，或者考虑一个可能使用 EJB 组件的新方案时作为判断依据。我们还将比较两个使用了 EJB 组件的方案，并将看到它们是如何被正确或错误地应用于实际的。

什么是 EJB 组件？EJB 组件是为企业级应用设计的 java 组件模型。
EJB 组件是基于标准分布式对象技术、CORBA 和 RMI 的服务器端 java 组件。EJB 组件总是分布式的，这是它们与标准 JavaBeans 组件最根本的区别。
EJB 组件提供了应用的商务逻辑部分。由于它们不涉及表示层的问题，因此必须与其它的显示技术(如 servlets)，服务于 HTML 客户端的 JSP 技术，或者使用了诸如 AWT、Swing 技术的 java 应用一起使用。
实现了 EJB 规范的应用服务器提供了可以解决安全性、资源共享、持续运行、并行处理、事务完整性等复杂问题的服务，从而简化了商业应用系统。
Sun 公司制定的 EJB 组件模型要求 EJB 组件运行于 EJB 服务器(通常称为应用服务器)的环境下。我们的示例中使用了高级版 WebSphere 应用服务器，但所讨论的功能适用于大多数 EJB 服务器。

需要考虑的技术问题
当你在决定 EJB 组件是否为适合你的实际情况的合适技术时，不妨先考虑几个问题。如果你对所有这些问题的回答都是肯定的话，那么 EJB 组件就是你可以采用的合适技术。反之的话，别的技术可能更适合。

你需要将商务逻辑组件与面向外界的 Internet 隔离开吗？
许多公司认为他们的应用软件，特别是构成商务逻辑的一些标准和数据结构，是极为重要的公司财产(例如，公司所拥有的分析应用工具构成了股票交易网站的一部分)。允许外人访问这些属于公司资产的原码和目标码将对公司产生极大的危害。因此，这些公司十分需要将商务逻辑置于一套安全防火墙后面(通常称为无戒备区，也称 DMZ)。
在这种情况下，分布式对象组件体系结构(例如 EJB 技术)允许你将有价值的公司资产隔离到 DMZ 以内，同时表示层代码可以访问 DMZ 内的 EJB 服务器。下图描述了这种分布式解决方案：

防火墙内部的 EJB

这里我们假设表示层逻辑不如后台的商务逻辑重要。如果不是这样，那么这种方案的安全性就要下降，整个系统可能都需要置于 DMZ 之内。如果整个应用必须(或者能够)置于第二层防火墙后面，那么选择其它技术(如通过 Java Servlets 发出 JDBC 请求来直接访问数据库)就显得更合理。

这种解决方案也有一些效率方面的缺陷。例如在安装 WebSphere 时，如果你将客户端(servlets 与 JSP文件)与图示的位于另一个 java 虚拟机(JVM)中的 EJB 组件分隔开，这种选择将降低整体性能。与客户端和 EJB 组件位于同一个 JVM 中的情况相比，这种方式下每一个需要经过防火墙的请求都将增加20%的耗时。

你需要不止一种类型的客户端访问共享数据吗？
通常，一个应用会有多种类型、需要访问相同信息的客户端。例如，一个应用可能会有供外部客户访问的基于 web 的 HTML 前端，以及供内部人员使用的更完整的应用前端。通常，这个问题是通过为同一应用编写两个共享相同数据源(数据库表)的版本来解决的。但是，这种方法效率不高，无论是从编程时间还是从同时发生多个数据库锁定时数据库的利用率来说。

EJB 技术的解决方案是将共享数据和商务逻辑集成到一套 EJB 组件中，以供不同类型的客户端(如 servlet/HTML 和 application)访问。EJB 组件控制着对后台数据的访问，并管理着当前事务以及数据库的内部锁定。通过去除应用中的重复代码，减少编写数据库控制逻辑的工作，这种方案降低了总的编程量。

在这个领域还有其它一些解决方案--比如，java 应用可以通过 HTTP 访问 java servlets，同时浏览器也可以通过 HTTP 访问 java servlets。这些解决方案的问题在于：如果 servlet 是用来在浏览器中显示信息的，它就必须包含一些表示层逻辑，这些表示层逻辑对于向另一个程序传递信息来说是多余的。因此，你最终不得不采用两套部分重复的 servlets 来处理两种情况。此外，HTTP 不是程序间通讯的效率最高的协议。你必须设计能通过 HTTP 管道进行程序间信息传递的数据格式--这通常或者是基于文本的格式，比如 XML（由接收端进行解析，由发送端生成），或者是基于对象的格式，比如 java 序列化。两种格式都需要大量的编程工作，它们都不如本地的 IIOP 速度快。

你是否需要对共享数据同时进行读和写操作？
通常，"胖客户端"解决方案要求应用在数据库级别上管理对共享数据的访问。其结果是：处理数据库锁定与同步的方案非常复杂，若不考虑数据库锁定与同步问题又会失去数据的完整性。

EJB 技术能自动处理这些复杂的共享数据同步问题。正如前面提到的那样，EJB 组件控制着对后台数据的访问，并管理着当前事务和数据库的内部锁定。这不仅省去了编写数据库控制逻辑的工作量，同时也保证了数据的一致性与正确性，从而降低了总的编程量。

你需要访问具备事务处理功能的多个异构数据源吗？
许多应用需要访问多个数据源。例如，一个应用程序可能既要访问来自中间层的 Oracle 数据库，又要通过中间件(如 MQSeries)访问 CICS、IMS 等大型主机系统。问题的关键是一些应用要求这种访问是完全事务化的，并且数据完整性在不同数据源间也能得到保证。例如，某个应用可能要求在处理用户的订购信息时，既要在 Oracle 数据库中存储详细的订购信息，同时又通过 MQSeries 在 CICS 系统中存储一份出货订单。无论是数据库更新或是 MQ 队列产生错误，整个事务都应被取消。

过去，构建这样的系统的唯一选择是采用事务监视器，例如 Encina、CICS、Tuxedo，它们使用非标准接口并需要用 COBOL、C、C++ 等语言进行开发。例如，高级版 WebSphere 中的 EJB 容器支持多个并发的事务，具备在多个 DB2 数据源间进行完整的事务提交及事务取消的能力，这些都是在一个完全支持二状态事务提交的环境中进行的。目前，WebSphere 对其它数据源(如 Oracle, MQSeries 和 CICS)只支持单状态的事务提交。企业版 WebSphere 中的 EJB 容器能对更多的数据源支持二状态的事务提交。

大多数容器正在支持各种数据源下的二状态事务提交方面不断完善。随着时间的推移，我们将在这一领域看到不断的进步。

你需要能与 HTML 文档、servlets、JSP 文件、客户端登录安全性无缝集成的方法级对象安全性吗？
某些类型的应用由于其安全性限制，使得以前它们很难通过 java 应用来实现。例如，某些保险业的应用程序为了满足管理规定的要求，必须限制对客户数据的访问。直到 EJB 技术出现后，才能够限制特定用户访问某个对象或方法。在这之前，可实施的办法只有：在数据库级别上限制访问，并捕获在 JDBC 层次上抛出的错误；或者通过客户安全密码在应用层上限制访问。

EJB 技术可以在任何 EJB 组件或方法上实施方法级的安全策略。创建的用户和用户组可以被授予或禁止对任何 EJB 组件或方法的操作权。在 WebSphere 中，用户组可以被授予或禁止对 web 资源(servlets, JSP 文件和 HTML 页面)的访问权，用户的 ID 可以通过底层的安全机制被安全地从 web 资源传递到 EJB 组件。

体系结构是否有标准化、轻量化、组件化的需要呢？
对于许多有远见的公司来说，关键问题是要实现平台、销售商和应用服务器设备间的相互独立。符合工业标准的 EJB 组件体系结构有助于实现这些目标。为 WebSphere 开发的 EJB 组件通常可以发布到其它类型的应用服务器上使用，反之亦然。尽管这一目标尚未完全实现，但它已成为许多客户选择的战略发展方向。从短期看，利用一些可能优于标准化的特性会更方便、更迅速，但从长远看标准化具有最大的好处。

你也应当考虑到越来越多的可选工具和 EJB 标准的优化实现手段，这些都是你无法从本地管理对象框架中获得的。由于大多数公司并不从事中间件业务，将注意力集中在与你的业务更直接相关的活动上会更有效。

你需要多个服务器来满足系统的吞吐量和有效性需要吗？
胖客户端系统显然不能适应 web 系统可能拥有的成千上万个用户。软件发布方面的问题也要求给胖客户端减肥。Web 站点的24小时不间断运行特点也使得时间成为关键问题。但并不是每个人都需要24小时不间断运行，并能同时处理上万个用户的系统。你应当能设计这样的系统：在不增加开发和标准化难度的前提下，实现系统的伸缩性。

因此，你要设法使得编写的商务逻辑可以进行伸缩来满足这些需要。EJB 技术为构建这种具有高伸缩性、高利用率的系统提供了骨架。例如，WebSphere 通过以下一些特性帮助开发者构建这类系统。这些特性也适用于其它的 EJB 服务器：

对象缓存与共享。WebSphere 自动在服务器层面上共享无状态会话 EJB 组件，从而减少了用于创建对象和回收碎片的时间。这将使得更多的处理时间周期可以分配给真正的实际工作。
服务器端的工作量优化。WebSphere 还使得 EJB 服务器具备群管理的特点。在 WebSphere 应用服务器上，你可以创建跨越多个节点的服务器组。除此之外，你可以创建模型(服务器的抽象表述)，并把它们克隆到多个 JVM 中。你可以将克隆的模型配置成运行于组内的任何一台服务器上。另外，一个服务器的多个克隆模型也能运行与一台机子上，充分利用了多处理器的结构特点。同样，你也可以把所有克隆的模型作为一个组来管理。这就提高了可靠性，避免了个别地方故障时对应用服务器的破坏。
通过克隆可支持自动故障恢复。由于有几个克隆的服务器可以用来处理请求，故障不太可能破坏系统的吞吐量和可靠性。由于多个节点运行相同的服务，一台整机的故障就不会产生灾难性的后果。
所有这些特性都不需要对系统进行特殊的编程。利用这种可伸缩性也无需改动服务器端的代码。

WebSphere 支持其它服务器端 java 技术(如 java servlets，JSP文件)的发布、克隆和自动故障恢复。但是，这些更面向表示层的技术与其说是 EJB 组件的竞争对手，不如说是对其的补充。当总体时间和可伸缩性是问题的关键时，整体解决方案中应包括 EJB 组件。

关于两个方案的描述，或者说是关于正确使用 EJB 组件的描述
现在你已经了解了一些评估一个应用是否适合使用 EJB 技术的办法，下面我们来比较两个使用了 EJB 组件的应用，看看 EJB 技术究竟是帮助还是阻碍了开发者达到目标。在一个例子中 EJB 组件的正确使用使得代码更简洁、更易懂。在另一个例子中，使用 EJB 组件使得系统过于复杂，性能也不好。

这两个应用都是综合了多个其它应用的例子，而不是来自于某个单一的公司或方案小组。

一个使用 EJB 技术失败的例子
作为一个被授权评估新技术的高级技术小组的成员，某个方案小组最初设计了这个方案。该方案具有如下体系结构(每个方框代表运行于各自硬件上的不同程序)：

不可取的 EJB 体系结构

该体系结构的一些具体设计使得 EJB 组件的使用不如它初看起来那么有吸引力：

应用的主体部分是信息的显示，这部分由 java servlets 实现。EJB 组件只用来获取、更新数据。
方案小组在后台主机的事务处理中使用的数据连接不包括遵从扩充体系结构(XA)标准的数据源。事务不能被成批取消或提交，对每个主机的访问都是一个独立的请求。
由于不能区分用户是来自 web 还是来自后台主机，EJB 技术的安全特性在此没有得到利用。
servlet 对 EJB 组件的每一次访问都是一个网络请求。组件的探测方法和 ejbLoad() 方法的内部逻辑执行了真正的主机请求，但这之后 EJB 组件仅仅进行数据缓存，直到事务提交后才由 ejbStore() 方法将信息回传给主机。直到事务提交前的每一次数据访问和更新都导致了大量的网络开销。
该方案小组仅仅把 EJB 组件用作主机数据与 servlets 间的数据映射机制，这不是 EJB 技术的有效使用方法。本例中的应用没有利用以下一些特性：

EJB 组件的事务处理特性
EJB 组件的方法级安全性
EJB 组件的伸缩性与分布式特点(该方案小组仅使用了一个 EJB 服务器)
多种类型客户端间的商务逻辑共享
具备容器管理持久性(CMP)的 EJB 组件的自动数据映射功能

如果直接由和 java servlets 处于同一 JVM 中的 JavaBeans 组件来实现数据映射功能，系统的速度将比使用 EJB 组件快得多，同时避免了大量的网络开销。该系统还变得不必要的复杂(因为需要本地和远程接口，以及分布代码)。事实上，该方案后来被废弃并以不使用 EJB 组件的方式进行了重新设计，其中的数据映射由一套被 servlets 使用的标准 JavaBeans 组件实现。这使得最后的系统变得更简单、更快速。

一个成功使用EJB技术的例子
一个金融机构的方案小组设计了这套方案，最初使用了 java 和 RMI 技术。其系统体系结构如下：

RMI服务器体系结构

除了多种类型的客户端，方案小组还在系统内构建了以下两个框架单元，在本图中未画出来：

一个数据库映射层，通过 RMI 服务器上的 JDBC 将其 Oracle 数据表映射成 java 类，或者反过来。
一个用户安全框架单元，用于验证来自浏览器或应用客户端的用户，并进而决定用户是否有权进行 RMI 和数据库请求。
由于他们的应用需求与 EJB 技术的目标紧密相连，该方案小组得以很快将其设计方案转变为以下体系结构：

新的 EJB 体系结构

通过使用容器管理持久性(CMP)，EJB 组件使得方案小组可以抛弃数据库映射框架，转而利用 WebSphere 和 VisualAge for Java 中完整高效的实现机制。通过利用 EJB 技术的安全性，方案小组得以在应用中保留方法级安全性的同时，抛弃了他们的用户安全框架。结果，由于需要维护的代码量减少了，他们的应用变得更为简单。

简单地说，该应用的以下特点使得它适合使用 EJB 技术：

具有共享相同商务逻辑的多种类型客户端
使用了事务处理
需要通过 CMP 组件来实现与对象有关的映射
需要方法级的安全性

由于系统的设计目标是通过使用与实体同时发布的会话级 EJB 组件来实现最小的网络流量，该系统最终的体系结构很好地使用了 EJB 组件。对于前一种体系结构，由于客户端需要发出大量的请求，很可能会增加网络负担，另外由于要求客户端进行事务的启动、提交、取消，使得系统复杂化。

　　 安装EJB运行和开发环境

　　EJB必须要在EJB容器内执行。所以，我们必须安装一个符合J2EE标准的EJB容器。为了帮助我们部署自己的EJB，我们还需要一个部署工具。来自Sun的、对J2EE的参考实现包含了一个EJB容器和一个EJB部署工具。这个J2EE参考实现能够在Sun发布的J2EE开发工具包里找到。

　　J2EE开发包要依靠Java 2 SDK、标准版（Standard Edition，J2SE）的开发包，所以你也需要把它下载下来。你需要J2SE SDK 来运行参照实现的J2EE服务器，并创建和运行EJB应用程序。

　　一旦你下载了开发包，你就要安装它们，并为每个开发包选择理想的位置。你要先定义一个叫作JAVA_HOME的环境变量，并将它指向J2SE开发包的安装目录。然后，定义一个叫做J2EE_HOME的环境变量，并把它指向J2EE开发包的安装目录。

　　现在你就准备好开始编写你的EJB了。

　　 编写一个简单会话EJB

　　开发一个EJB所涉及的大多数步骤和概念和我们开发传统的Java对象（plain-old Java object，POJO）所使用的是相同的，只有少数的不同之处。下面就是开发和部署EJB的一个基本步骤：

　　1. 为你的EJB编写类和接口。
　　2. 为你的EJB编写部署描述符。
　　3. 将EJB和相关联的文件打包进一个jar文件。
　　4. 部署EJB。

　　会话bean有两种不同的类型。在我们开始编写代码之前，让我们来看看它们之间的相同之处和不同之处。

　　 状态会话EJB概述

　　状态会话EJB会在单个会话期间维持一种和客户端的对话状态。这就表示状态会话EJB能够在单个会话期间，维持从一个客户端跨越多个调用的实例变量。

　　一旦客户端完成了同EJB的交互操作，而且EJB容易删除了EJB，那么EJB的会话就会结束，用于EJB的所有状态数据都会被删除。

　　 无状态会话EJB概述

　　无状态会话EJB不会为每个单独的客户端都维持一个对话状态。对无状态会话EJB的每次调用，都应该被当作是对一个全新的对象实例的请求。因为任何实例－变量状态都会在调用之间丢失。

　　无状态会话EJB不会被EJB容器保存到第二存储地里，所以程序员必须要知道：每个客户端的每次调用之间的所有数据都是瞬时的。无状态会话EJB的瞬时特性允许EJB容器重复使用EJB实例，因此常常会优化EJB的性能。

　　 会话Bean之间的关系

　　图A说明了EJB客户端、EJB容器和几个会话EJB之间的关系。

　　会话EJB包括至少三个强制类／接口。第一个强制类／接口是Component接口。Component接口定义了一些对EJB来说是可视的商业方法，它必须扩展javax.ejb.EJBObject。

　　这里我们会举个例子，实现一个非常简单的无状态会话EJB，它会在一个叫作getBalance的方法里返回帐目结算。我们Component接口的代码如下：

　　package com.jeffhanson.ejb;

　　public interface Account extends javax.ejb.EJBObject, java.rmi.Remote
　　{
　　　public String getBalance() throws java.rmi.RemoteException;
　　}

　　第二个强制类／接口是Home接口。Home接口被EJB客户端用来获取对Bean的组件接口的参照，它必须扩展javax.ejb.EJBHome。我们Home接口的代码如下：

　　package com.jeffhanson.ejb;

　　public interface AccountHome extends javax.ejb.EJBHome
　　{
　　  public Account create() throws javax.ejb.CreateException,
                                  java.rmi.RemoteException;
　　}

　　第三个强制类／接口是Enterprise Bean类。Enterprise Bean类为Component接口和Home接口提供实现。用于会话EJB的Enterprise Bean类必须要实现javax.ejb.SessionBean接口。我们Enterprise Bean类的代码如下：

　　package com.jeffhanson.ejb;

　　public class AccountBean
 　 implements javax.ejb.SessionBean
　{
   private javax.ejb.SessionContextctx;
 
   public void ejbActivate() {}
 
   public void ejbCreate() {}

   public void ejbRemove() {}
 
   public void ejbPassivate() {}
 
   public void setSessionContext(javax.ejb.SessionContextctx)
   {  
      this.ctx = ctx;
   }
 
   // business method
   public String getBalance()
      throws java.rmi.RemoteException
   {
      String balance = dataObj.getAccountBalance();
      return(balance);
   }
　}

　　 结束语

　　EJB的全称是Enterprise Java bean。是JAVA中的商业应用组件技术。EJB结构中的角色 EJB 组件结构是基于组件的分布式计算结构，是分布式应用系统中的组件。
　　一个完整的基于EJB的分布式计算结构由六个角色组成，这六个角色可以由不同的开发商提供，每个角色所作的工作必须遵循Sun公司提供的EJB规范，以保证彼此之间的兼容性。这六个角色分别是EJB组件开发者（Enterprise Bean Provider）、应用组合者（Application Assembler）、部署者（Deployer）、EJB服务器提供者（EJB Server Provider）、EJB 容器提供者（EJB Container Provider）、系统管理员（System Administrator）：

　　1.EJB中各角色的分析
　　（1）EJB组件开发者（Enterprise Bean Provider）
　　EJB组件开发者负责开发执行商业逻辑规则的EJB组件，开发出的EJB组件打包成ejb-jar文件。EJB组件开发者负责定义EJB的remote和home接口，编写执行商业逻辑的EJB class，提供部署EJB的部署文件（deployment descriptor）。部署文件包含EJB的名字，EJB用到的资源配置，如JDBC等。EJB组件开发者是典型的商业应用开发领域专家。
　　EJB组件开发者不需要精通系统级的编程，因此，不需要知道一些系统级的处理细节，如事务、同步、安全、分布式计算等。
　　（2）应用组合者（Application Assembler）
　　应用组合者负责利用各种EJB组合一个完整的应用系统。应用组合者有时需要提供一些相关的程序，如在一个电子商务系统里，应用组合者需要提供JSP（Java Server Page）程序。
　　应用组合者必须掌握所用的EJB的home和remote接口，但不需要知道这些接口的实现。
　　（3）部署者（Deployer）
　　部署者负责将ejb-jar文件部署到用户的系统环境中。系统环境包含某种EJB Server和EJB Container。部署者必须保证所有由EJB组件开发者在部署文件中声明的资源可用，例如，部署者必须配置好EJB所需的数据库资源。
　　部署过程分两步：部署者首先利用EJB Container提供的工具生成一些类和接口，使EJB Container能够利用这些类和接口在运行状态管理EJB。 部署者安装EJB组件和其他在上一步生成的类到EJB Container中。部署者是某个EJB运行环境的专家。
　　某些情况下，部署者在部署时还需要了解EJB包含的业务方法，以便在部署完成后，写一些简单的程序测试。
　　（4）EJB服务器提供者（EJB Server Provider）
　　EJB 服务器提供者是系统领域的专家，精通分布式交易管理，分布式对象管理及其它系统级的服务。EJB 服务器提供者一般由操作系统开发商、中间件开发商或数据库开发商提供。
　　在目前的EJB规范中，假定EJB 服务器提供者和EJB 容器提供者来自同一个开发商，所以，没有定义EJB 服务器提供者和EJB容器提供者之间的接口标准。
　　（5）EJB 容器提供者（EJB Container Provider）
　　EJB 容器提供者提供EJB部署工具为部署好的EJB组件提供运行环境 。EJB容器负责为EJB提供交易管理，安全管理等服务。
　　EJB 容器提供者必须是系统级的编程专家，还要具备一些应用领域的经验。EJB 容器提供者的工作主要集中在开发一个可伸缩的，具有交易管理功能的集成在EJB 服务器中的容器。EJB 容器提供者为EJB组件开发者提供了一组标准的、易用的API访问EJB 容器，使EJB组件开发者不需要了解EJB服务器中的各种技术细节。
　　EJB容器提供者负责提供系统监测工具用来实时监测EJB容器和运行在容器中的EJB组件状态。
　　（6）系统管理员（System Administrator）
　　系统管理员负责为EJB服务器和容器提供一个企业级的计算和网络环境。
　　系统管理员负责利用EJB 服务器和容器提供的监测管理工具监测EJB组件的运行情况。

　　2.EJB的体系结构：
　　EJB分布式应用程序是基于对象组件模型的，低层的事务服务用了API技术。EJB技术简化了用JAVA语言编写的企业应用系统的开发，配置。EJB技术定义了一组可重用的组件：Enterprise Beans。你可以利用这些组件，象搭积木一样的建立你的分布式应用程序。当你把代码写好之后，这些组件就被组合到特定的文件中去。每个文件有一个或多个Enterprise Beans，在加上一些配置参数。最后，这些Enterprise Beans被配置到一个装了EJB容器的平台上。客户能够通过这些Beans的home接口，定位到某个beans，并产生这个beans的一个实例。这样，客户就能够调用Beans的应用方法和远程接口。
　　EJB服务器作为容器和低层平台的桥梁管理着EJB容器和函数。它向EJB容器提供了访问系统服务的能力。例如：数据库的管理和事务的管理，或者对于其它的Enterprise的应用服务器。所有的EJB 实例都运行在EJB容器中。
　　容器提供了系统级的服务，控制了EJB的生命周期。EJB中的有一些易于使用的管理工具如：
　　Security－配置描述器（The Deployment descriptor）定义了客户能够访问的不同的应用函数。容器通过允许授权的客户访问这些函数来达到这个效果。
　　Remote Connectivity－容器为远程链接管理着低层的通信issues，而且对Enterprise Beas的开发者和客户都隐藏了通信细节。EJB的开发者在编写应用方法的时候，就象是在条用本地的平台一样的。客户也不清楚他们调用的方法可能是在远程被处理的。
　　Life Cycle managment－客户简单的创建一个Enterprise beans的实例，并通常取消一个实例。而容器管理着Enterprise Beans的实例，使Enterprise Beans实现最大的效能和内存利用率。容器能够这样来激活和使Enterprise Beans失效，保持众多客户共享的实例池。等等。
　　Trasction management－配置描述器定义了Enterprise beans 的事务处理的需求。容器管理着那些管理分布式事务处理的复杂的issues。这些事务可能要在不同的平台之间更新数据库。容器使这些事务之间互相独立，互不干扰。保证所有的更新数据库都是成功发生的，否者，就回滚到事务处理之前的状态。
　　EJB组件是基于分布式事务处理的企业级应用程序的组件。所有的EJB都有如下的特点：
　　EJB包含了处理企业数据的应用逻辑，定义了EJB的客户界面。这样的界面不受容器和服务器的影响。于是，当一个EJB被集合到一个应用程序中去时，不用更改代码和重新编译。
　　EJB能够被定制。各种系统级的服务，例如安全和事务处理的特性，都不是属于EJB类的。而是由配置和组装应用程序的工具来实现。
　　有两种类型的EJB： Session beans 和 entity beans。Session beans是一种作为单用户执行的对象。作为对远程的任务请求的相应，容器产生一个Session beans 的实例。一个Session beans有一个用户。从某种程度上来说，一个Session bean 对于服务器来说就代表了它的那个用户。Session beans 也能用于事务，它能够更新共享的数据，但它不直接描绘这些共享的数据。Session beans 的生命周期是相对较短的。典型的是，只有当用户保持会话的时候，Session beans 才是活着的。一旦用户退出了，Session beans 就不再与用户相联系了。Session beans被看成是瞬时的，因为如果容器崩溃了，那么用户必须重新建立一个新的Session对象来继续会话。
　　Session bean典型的声明了与用户的互操作或者会话。也就是说，Session bean在客户会话期间，通过方法的调用，掌握用户的信息。一个具有状态的Session bean称为有状态的Session bean。当用户终止与Session beans互操作的时候。会话终止了，而且，bean 也不再拥有状态值。Session bean也可能是一个无状态的 session bean。无状态的Session beans并不掌握它的客户的信息或者状态。用户能够调用beans的方法来完成一些操作。但是，beans只是在方法调用的时候才知道用户的参数变量。当方法调用完成以后，beans并不继续保持这些参数变量。这样，所有的无状态的session beans的实例都是相同的，除非它正在方法调用期间。这样，无状态的Session beans就能够支持多个用户。容器能够声明一个无状态的Session beans。能够将任何Session beans指定给任何用户。
　　Entity Beans对数据库中的数据提供了一种对象的视图。例如：一个Entity bean能够模拟数据库表中一行相关的数据。多个client能够共享访问同一个Entity bean。多个client也能够同时的访问同一个Entity bean。Entity beans通过事务的上下文来访问或更新下层的数据。这样，数据的完整性就能够被保证。Entity Beans能存活相对教长的时间，并且状态是持续的。只要数据库中的数据存在，Entity beans就一直存活。而不是按照应用程序或者服务进程来说的。即使EJB容器崩溃了，Entity beans也是存活的。Entity Beans生命周期能够被容器或者 Beans自己管理。如果由容器控制着保证 Entity beans持续的issus。如果由Beans自己管理，就必须写Entity beans的代码，包括访问数据库的调用。
　　Entity Beans是由主键（primary key 一种唯一的对象标识符）标识的。通常，主键与标识数据库中的一块数据，例如一个表中的一行，的主键是相同的。主键是client能够定位特定的数据块。

　　利用EJB进行开发有哪些步骤？

　　开发EJB的主要步骤一般来说，整个的开发步骤（开发，配置，组装）包括如下几个方面。
　　·开发：首先要定义三个类：Bean类本身，Bean的本地和远程接口类。
　　·配置：配置包括产生配置描述器－这是一个XML文件、声明了Enterprise Bean的属性、绑定了bean的class文件（包括stub文件和skeleton文件）。最后将这些配置都放到一个jar文件中。还需要在配置器中定义环境属性。
　　·组装应用程序：包括将Enterprise beans安装到Server服务器中，测试各层的连接情况。程序组装器将若干个Enterprise Beans与其它的组件结合起来，组合成一个完整的应用程序；或者将若干个Enterprise beans组合成一个复杂的Enterprise Bean。
　　·管理Enterprise Bean
　　必须定义和编写一些EJB中的基本类。如Enterprise bean类：这是Enterprise bean内部应用逻辑的实现。编写Enterprise bean的远程接口类。编写Enterprise bean的本地接口类。说明主键类，主键类只是对于Entity bean才需要的。在Enterprise bean的配置描述器中指定主键的名字。Enterprise beans提供者定义了远程接口和本地接口，实现了EJB类本身。Remote接口中提供了客户调用EJB实现的应用逻辑函数的接口。而home接口提供了产生和定位remote接口实例的方法。
　　在Enterprise bean本身类的实现，本地home接口，远程remote接口之间并没有正式的联系（例如继承关系）。但是，在三个类里声明的方法却必须遵守EJB里面定义的规范。例如： 你在Enterprise bean里面声明了一个应用程序的方法或者说应用逻辑。也在beans的remote接口中声明了这个方法，那么，这两个地方必须要同样的名字。Bean的实现里面必须至少有一个Create()方法：ejbCreate()。但是可以有多个带有不同参数的create()方法。在home接口中，也必须有相同的方法定义（参数的个数相同）。EjbCreate()方法返回的一个容器管理的持久对象。它们都返回一个容器管理持久性的主键值。但是，在home的相应的Create()方法中返回值的类型是remote接口。
　　注意：实体bean的实现的ejbCreate方法有点不同。实体bean可以不定义ejbCreate方法。如果实体只是通过应用程序或通过数据库管理程序的途径被加到数据库中，实体bean就省略了ejbCreate方法。EjbCreate返回的值是主键类型。如果ejbCreate方法是容器管理持久性的实体bean的方法，它的返回值就是NULL类型。如果实体bean实现了Bean管理的持久性，ejbCreate方法就返回值类型就是主键类型。容器的任务是把各接口和Enterprise bean的实现类结合起来。保证在编译时和运行时，各接口和实现类是相对应的。
　　EJB的实现类，各接口要从不同的基类中继承下来。一个会话bean必须实现基类Javax.ejb.SessionBean。而实体bean必须实现基类Javax.ejb.EntiyBean。这些EJB的基类都是从Javax.ejb.EnterpriseBean继承而来。而Javax.ejb.EnterpriseBean又是从Java.io.Serializable继承而来。每一个Enterprise Bean都必须有一个remote接口。Remote接口定义了应用程序规定客户可以调用的逻辑操作。这些是一些可以由客户调用的公共的方法，通常由Enterprise beans类来实现。注意，Enterprise bean的客户并不直接访问Bean。而是通过remote接口来访问。Enterprise bean类的remote接口扩展了Javax.ejb.EJBObject类的公共Java接口。而Javax.ejb.EJBObject是所有remote接口的基类。其代码如下：

package Javax.ejb；
public interface EJBObject extends Java.rmi.Remote{
public EJBHome getEJBHome() throws Java.rmi.RemoteException；
public Object getPrimaryKey() throws Java.rmi.RemoteException；
public void Remove() throws Java.rmi.RemtoeException， Java.rmi.RemoveException
public Handle getHandle() throws Java.rmi.RemoteException；
boolean isIdentical (EJBObject p0) throws Java.rmi.RemoteException；
} 

　　getEJBHome()方法允许你取得一个相关的Home接口。对于 实体Bean，用getPrimaryKey()方法获得实体Bean的主键值。Remove()可以删除一个Enterprise bean。具体的语义在各种不同类型的enterprise beans的生命周期中，由上下文中解释的。方法getHandle()返回了一个Enterprise bean实例的持久的句柄。IsIndentical()方法允许你去比较Enterprise beans是否相同。

　　所有的remote接口中的方法必须声明为公共（public）的，并必须抛出Java.rmi.RemotException异常。另外，所有的remote接口中的方法定义的参数和都必须是在RMI-IIOP中有效的。对每一个在remote接口中定义的方法，在Enterprise bean 类里面都要有相应的方法。相应的方法必须要有同样的名字，同样类型和数量的参数，同样的返回值，而且还要抛出同样的例外。 如下代码显示了一个ATM例子的会话bean的remote接口Atm。里面声明了一个应用方法transfer()。黑体部分表示EJB规范中必须要有的内容。Remote接口必须扩展Javax.ejb.EJBObject类。从客户端调用的Enterprise bean的每一个方法都必须在remote接口中声明。Transfer()方法抛出了两个意外。其中InSufficientFundsException例外是应用程序定义的意外。

Public interface Atm extends Javax.ejb.EJBObject{
Public void transfer(String Source， String Target， float amount)
Throws Java.rmi.RemoteException， InSufficientFundsException；
} 

　　Home接口必须定义一个或多个的Create()方法。每一个这样的Create()方法都必须命名为Create。并且，它的参数，不管是类型还是数量都必须与bean类里面的ejbCreate()方法对应。注意，home接口中的Create()方法和bean类中ejbCreate()方法的返回值类型是不同的。实体bean的home接口还包含find()方法。 每一个Home接口都扩展了Javax.ejb.EJBHome接口。如下代码显示了Javax.ejb.EJBHome接口的定义：

package Javax.ejb；
public interface EJBHome extends Java.rmi.Remote() {
void remove(Handle handle) throws Java.rmi.RemoteException，RemoveException；
void remove(Object primarykey) throws Java.rmi.RemoteException，RemoveException；
EJBMetaData getEJBMetaData() throws RemoteException；
Homehandle getHomeHandle() throws RemoteException；
} 

　　这里提供了两个remove()方法来删除Enterprise bean的实例。第一个remove方法是通过句柄来删除一个Enterprise bean的实例。第二个remove方法通过主键来删除一个Enterprise bean的实例。 在众多的Enterprise bean实例中，句柄唯一的标识一个实例。一个句柄与它引用的Enterprise bean有相同的生命期。考虑一个实体对象，客户可以通过一个句柄来重新获得相应的Enterprise bean的实例。一个句柄能够对应一个Enterprise bean对象的多个实例。例如，即使当Enterprise bean对象所在的主机崩溃了，或者Enterprise bean对象在不同的机器之间移动，句柄仍是有效的。这里的句柄是Serialized句柄，与CORBA中的字符串化的CORBA对象的引用是相似的概念。在EJBHome接口中的第二个remove操作通过其主键来决定要删除的Enterprise bean。主键可以是扩展了Java Object类的任何类型，但是，必须要实现Java的Serializable接口。主键是标识实体bean的主要的方法。通常，主键是数据库中的一个关键字，唯一的定义了由实体bean代表的数据。
　　方法getEJBMetaData()返回了Enterprise bean对象的metadata接口。这个接口允许客户获得Enterprise bean的metadata信息。当开发工具来编译链接应用程序的时候，或者配置工具来配置的时候，可能会用到metadata信息。　　Javax.ejb.EJBMetadata接口提供了获得Javax.ejb.EJBHome接口，home类，remote接口，还有获得主键的方法。也提供了一个isSesson()的方法来确定在放这个home接口的对象是会话bean还是实体bean。
　　IsStatelessSession()方法指示这个会话bean是有状态还是无状态的。如下代码显示了Javax.ejb.EJBMetadata接口的定义部分的代码。

Public Javax.ejb； Public interface EJBMetaData{
EJBHome getEJBHome()；
Class getHomeInterfaceClass()；
Class getRemoteInterfaceClasss()；
Class getPrimaryKeyClass()；
Boolean isSession()；
Boolean isStatelesssSession()；
} 

　　对每一个Create()方法，EJB规范定义了如下的命名约定。它的返回值是会话bean的remote接口的类型。方法的名字只能是Create()。对会话bean类中的每一个ejbCreate()方法都必须有一个Create()与之对应。 对于每一个Create()方法的参数的类型和数量都必须与会话bean类中的ejbCreate()方法相对应。方法必须抛出Java.rmi.RemoteException例外。 方法必须抛出Javax.rmi.CreateExeption例外。 Create()方法的参数是用来初始化新的会话bean对象的。如下代码显示了一个会话bean对象的不同的Create()方法，其中必须的部分用粗体显示：

public interface AtmHome extends Javax.ejb.EJBHome{
Atm create() throws Java.rmi.RemoteException，Javax.ejb.CreateException；
Atm create(Profile preferredProfile)
Throws Java.rmi.RemoteExeption，Javax.ehrows Java.rmi.RemoteException，RemoveException；
EJBMetaData getEJBMetaData() throws RemoteException；
Homehandle getHomeHandle() throws RemoteException；
} 

　　这里提供了两个remove()方法来删除Enterprise bean的实例。第一个remove方法是通过句柄来删除一个Enterprise bean的实例。第二个remove方法通过主键来删除一个Enterprise bean的实例。在众多的Enterprise bean实例中，句柄唯一的标识一个实例。一个句柄与它引用的Enterprise bean有相同的生命期。考虑一个实体对象，客户可以通过一个句柄来重新获得相应的Enterprise bean的实例。一个句柄能够对应一个Enterprise bean对象的多个实例。例如，即使当Enterprise bean对象所在的主机崩溃了，或者Enterprise bean对象在不同的机器之间移动，句柄仍是有效的。这里的句柄是Serialized句柄，与CORBA中的字符串化的CORBA对象的引用是相似的概念。
　　在EJBHome接口中的第二个remove操作通过其主键来决定要删除的Enterprise bean。主键可以是扩展了Java Object类的任何类型，但是，必须要实现Java的Serializable接口。主键是标识实体bean的主要的方法。通常，主键是数据库中的一个关键字，唯一的定义了由实体bean代表的数据。方法getEJBMetaData()返回了Enterprise bean对象的metadata接口。这个接口允许客户获得Enterprise bean的metadata信息。当开发工具来编译链接应用程序的时候，或者配置工具来配置的时候，可能会用到metadata信息。Javax.ejb.EJBMetadata接口提供了获得Javax.ejb.EJBHome接口，home类，remote接口，还有获得主键的方法。也提供了一个isSesson()的方法来确定在放这个home接口的对象是会话bean还是实体bean。IsStatelessSession()方法指示这个会话bean是有状态还是无状态的。　　如下代码显示了Javax.ejb.EJBMetadata接口的定义部分的代码。

Public Javax.ejb；
Public interface EJBMetaData{
EJBHome getEJBHome()；
Class getHomeInterfaceClass()；
Class getRemoteInterfaceClasss()；
Class getPrimaryKeyClass()；
Boolean isSession()；
Boolean isStatelesssSession()；
} 

　　EJB的编程环境有哪些？

　　1. 使用Jbuilder
　　Jbuilder与EJB Container能够进行无缝连接。Jbuilder和Inprise的应用服务器包括了所有的开发和配置Enterprise Beans的工具以及所需要的库：运行和管理Enterprise Bean的容器、命名服务、 事务服务、Java数据库、开发Enterprise Beans所需要的API、一个增强的Java-to-iiop编译器，支持值类型和RMI信号等等。
　　Jbuilder还提供了一个快速开发应用程序Enterprise Beans的工具和向导。通过简单而且直观的步骤，向导帮助你建立一个Enterprise Bean。自己设定某些缺省值，产生了bean的模板，在上面，我们可以增加我们自己的应用逻辑。Jbuilder也提供了一个EJB的接口生成向导。向导在Enterprise Bean的公共方法基础上生成了Remote接口和Home接口。Jbuilder还提供一个配置器的向导帮助我们逐步的建立XML描述器文件。并将生成的Stubs集中到一个jar文件中。

　　2.使用Jbuilder之外的集成环境：
　　如果你使用其它的除了别的集成环境（IDE）。要确定使用了集成环境IDE所带的容器工具。也要验证IDE是否支持EJB规范的相应的版本，还要确定它是否正确的支持EJB的API。
　　要确定JD到所支持的EJB容器的版本。可以通过检查Inprise的安装说明来确定EJB容器所支持的支持JDK的版本。
　　在配置Enterprise Bean的时候，你必须使用Inprise的应用服务器所提供的工具。这些工具能够编辑和修改第三方的代理商提供的Inprise配置描述器。还能够验证配置描述器，能够验证bean的源代码。

　　附录：一个具体而微的EJB应用实例？

　　1.安装Apusic Application Server
　　Note：以下以Linux为例，来说明Apusic Application Server的安装过程。其他平台的安装，可参考Apusic Application Server安装手册。
　　下载JDK1.2，Apusic Application Server必须运行在JDK1.2以上环境中。可从以下站点下载最新JDK。
http：//Java.sun.com
　　下载Apusic Application Server
　　Apusic Application Server 试用版可从以下网址得到：
　　http：//www.apusic.com/download/enter.jsp
　　在下载完成后，你可以得到一个包裹文件apusic.zip，选定安装目录，假设安装到/usr下，则用以下命令：
　　cd /usr
　　jar xvf apusic.zip
　　/usr下会出现一个目录apusic，Apusic Application Server的所有程序都被解压到/usr/apusic下。
　　将以下路径加入到CLASSPATH中
　　/usr/apusic/lib/apusic.jar
　　$JAVA_HOME/lib/tools.jar
　　用以下命令运行Apusic Application Server
　　Java -Xms64m com.apusic.server.Main -root /usr/apusic

　　2.定义EJB远程接口（Remote Interface)
　　任何一个EJB都是通过Remote Interface被调用，EJB开发者首先要在Remote Interface中定义这个EJB可以被外界调用的所有方法。执行Remote Interface的类由EJB生成工具生成。以下是HelloBean的Remote Inteface程序：

package ejb.hello；

import Java.rmi.RemoteException；
import Java.rmi.Remote；
import Javax.ejb.*；

public interface Hello extends EJBObject， Remote {

// this method just get "Hello World" from HelloBean.
public String getHello() throws RemoteException；
} 

　　3.定义Home Interface
　　EJB容器通过EJB的Home Interface来创建EJB实例，和Remote Interface一样，执行Home Interface的类由EJB生成工具生成。以下是HelloBean 的Home Interface程序：

package ejb.hello；

import Javax.ejb.*；
import Java.rmi.Remote；
import Java.rmi.RemoteException；
import Java.util.*；

/**
* This interface is extremely simple it declares only
* one create method.
*/
public interface HelloHome extends EJBHome {

public Hello create() throws CreateException，
RemoteException；

} 

　　4.写EJB类
　　在EJB类中，编程者必须给出在Remote Interface中定义的远程方法的具体实现。EJB类中还包括一些 EJB规范中定义的必须实现的方法，这些方法都有比较统一的实现模版，编程者只需花费精力在具体业务方法的实现上。以下是HelloBean的代码：

package ejb.hello；

import Javax.ejb.*；
import Java.util.*；
import Java.rmi.*；

public class HelloBean implements SessionBean {
static final boolean verbose = true；

private transient SessionContext ctx； // Implement the methods in the SessionBean
// interface
public void ejbActivate() {
if (verbose)
System.out.println("ejbActivate called")；
}

public void ejbRemove() {
if (verbose)
System.out.println("ejbRemove called")；
}

public void ejbPassivate() {
if (verbose)
System.out.println("ejbPassivate called")；
}

/**
* Sets the session context.
*
* @param SessionContext
*/
public void setSessionContext(SessionContext ctx) {
if (verbose)
System.out.println("setSessionContext called")；
this.ctx = ctx；
}

/**
* This method corresponds to the create method in
* the home interface HelloHome.Java.
* The parameter sets of the two methods are
* identical. When the client calls
* HelloHome.create()， the container allocates an
* instance of the EJBean and calls ejbCreate().
*/
public void ejbCreate () {
if (verbose)
System.out.println("ejbCreate called")；
}
/**
* **** HERE IS THE BUSINESS LOGIC *****
* the getHello just return a "Hello World" string.
*/
public String getHello()
throws RemoteException
{
return("Hello World")；
}
} 

　　5.创建ejb-jar.xml文件
　　ejb-jar.xml文件是EJB的部署描述文件，包含EJB的各种配置信息，如是有状态Bean（Stateful Bean） 还是无状态Bean（Stateless Bean），交易类型等。ejb-jar.xml文件的详细信息请参阅EJB规范。以下是HelloBean的配置文件：

Hello
ejb.hello.HelloHome
ejb.hello.Hello
ejb.hello.HelloBean
Stateless
Container

Hello
*
Required

　　6.编译和部署
　　编译Java源文件并将编译后class和ejb-jar.xml打包到Hello.jar

mkdir build
mkdir build/META-INF
cp ejb-jar.xml build/META-INF
Javac -d build *.Java
cd build
jar cvf Hello.jar META-INF ejb
cd ..
用EJB工具生成可部署到Apusic Application Server中运行的jar文件：
Java com.apusic.ejb.utils.EJBGen -d /usr/apusic/classes/Hello.jar build/Hello.jar
增加/usr/apusic/classes/Hello.jar到CLASSPATH中
将Hello.jar加入到Apusic Application Server配置文件中。在/usr/apusic/config/server.xml 加入以下几行：

classes/Hello.jar

Hello
HelloHome

启动服务器
Java -Xms64m com.apusic.server.Main -root /usr/apusic 

　　7.写客户端调用程序
　　现在读者可以从Java Client，JSP，Servlet或别的EJB调用HelloBean。
　　调用EJB有以下几个步骤：
　　·通过JNDI（Java Naming Directory Interface）得到EJB Home Interface
　　·通过EJB Home Interface 创建EJB对象，并得到其Remote Interface
　　·通过Remote Interface调用EJB方法

　　以下是一个从Java Client中调用HelloBean的例子：

package ejb.hello；

import Javax.naming.Context；
import Javax.naming.InitialContext；
import Java.util.Hashtable；
import Javax.ejb.*；
import Java.rmi.RemoteException；

/**
* @author Copyright （c） 2000 by Apusic， Inc. All Rights Reserved.
*/
public class HelloClient{
public static void main(String args[]){
String url = "rmi：//localhost：6888"；
Context initCtx = null；
HelloHome hellohome = null；
try{
Hashtable env = new Hashtable()；
env.put(Context.INITIAL_CONTEXT_FACTORY，
"com.apusic.jndi.InitialContextFactory")；
env.put(Context.PROVIDER_URL， url)；
initCtx = new InitialContext(env)；
}catch(Exception e){
System.out.println("Cannot get initial context： " + e.getMessage())；
System.exit(1)；
}
try{
hellohome = (HelloHome)initCtx.lookup("HelloHome")；
Hello hello = hellohome.create()；
String s = hello.getHello()；
System.out.println(s)；
}catch(Exception e){
System.out.println(e.getMessage())；
System.exit(1)；
}
}
} 

　　运行HelloClient，可得到以下输出：Hello World