Java 版 (精华区)

发信人: zhangyan (电梯吃人啊), 信区: Java
标  题: 什么是EJB组件？
发信站: 哈工大紫丁香 (2001年05月18日17:51:50 星期五), 站内信件

发信人: SecretPower (梧桐雨@爱之箭), 信区: Java
标  题: 什么是EJB组件？
发信站: 武汉白云黄鹤站 (2001年05月18日14:04:25 星期五), 站内信件

第一部分：EJB 体系结构的历史和目标
Ken Nordby
IBM 软件工程师
2000 6 月

本文概述 Enterprise JavaBeans (EJB) 技术，旨在让读者快速理解基本概念。第 1
部分讲述 EJB 技术的历史和某些目标、优点和技术。为了简洁明了，有选择地讲述 EJ
B 技术的一些关键要素。请注意，虽然 EJB 组件依赖于一些基础的 Java 服务（如 Ja
va Transaction Service），但使用 EJB 组件及认识这些组件的好处并不需要掌握这些
相关技术的知识。
Enterprise JavaBeans 技术自 1998 年 3 月问世以来很受好评。下面这段话就是一个
例子：
“自从两年多以前问世以来，Enterprise JavaBeanstm 技术在平台供应商和企业的开发
小组中，同样都保持着空前的发展势头。这是因为 EJBtm 的服务器端组件模型简化了中
间件组件的开发，这些中间组件都是事务性的、可伸缩的和可移植的。Enterprise Jav
aBeans 服务器通过为中间件服务（如事务处理、安全性、数据库连接及其他）提供自动
支持，降低了开发中间件的复杂程度。”（Sun Microsystems 网站）
Enterprise JavaBeans 这一名称利用了 Java bean — 这种可移植、可重用的 Java 软
件组件的声望。Enterprise JavaBeans 技术把 Java 组件的概念从客户机域扩展到了服
务器域：这是 Java 技术成长过程中有重大意义的一步，它使 Java 技术发展成为一种
强健的、可伸缩的环境，能够支持以任务为关键的企业信息系统。
服务器上的 Java 应用程序
Java 编程语言最初在 Web 开发人员中获得好评的一个原因是，它支持称为 applet 的
可下载 Java 程序。对 Applet 的支持以 Applet 类的形式内置到了 1.0 版的 Java D
evelopment Kit (JDK) 中。按照 1.0 版的时间框架，Java 开发是以 applet 和应用程
序作为中心的。基于 JDK 1.0 版的 Java 读物都是从 applet 和应用程序的角度来描述
 Java 编程的：
“Java 程序由更多的类定义中的某一个组成，每个类定义均已编译成它自已的 Java 虚
拟机对象代码的 .class 文件。这些类之一必须定义一个叫做 main() 的方法，程序就
是从这个方法开始运行的。想调用一个 Java 程序，需要运行 Java 解释器 java，并指
定包含 main() 方法的类的名称。请注意 Java applet 并不是一个应用程序 — 它是一
个由已在运行的 Java 应用程序（如 Web 浏览器或 applet 查看器）装入并运行的 Ja
va 类。”（见 Flanagan 所著的 Java in a Nutshell）
Java 应用程序可以在服务器上运行，但是不管是在客户机-服务器环境下，还是在基于
 Web 的环境下，JDK 中都没有提供让 Java 应用程序专用于服务器机器的接口或包。认
识到 Java 在 Web 环境下作为一种服务器语言的潜力，Sun Microsystems 编写了 Jav
a Servlet 规范。servlet 在许多方面与 applet 相似，它是专门为在 Web 服务器机器
上运行而设计的 Java 程序：
“servlet 是由容器管理的 Web 组件，可产生动态内容。servlet 是一种小型的、与平
台无关的 Java 类，被编译成体系结构中立的字节代码，这种代码可以动态地加载到一
个 web 服务器上，并由此 web 服务器运行。servlet 通过一种由 servlet 容器实现的
请求-响应模型与 Web 客户机进行交互。这种请求-响应模型建立在超文本传输协议 (H
TTP) 行为的基础之上。”（见 JavaSoft 的“Java Servlet API Specification”）
在一台 Web 服务器控制下，在多台服务器上运行若干小型用户程序，这种想法并不新鲜
 — 一段时间以来，公共网关接口 (CGI) 程序（常被称为 CGI 脚本）一直起着这种作
用，并推动了 Web 的普及。但 Java servlet 可以以更高的效率和可移植性来实现这一
目的，因而可望最终会取代 CGI 程序。为 servlet 提供运行时环境的软件（通常被称
为 servlet 引擎）可以添加到现有的、本身并不支持 Java 可执行程序的 Web 服务器
上。
Java servlet 的出现，为应用程序员使用 Java 来创建 Web 应用程序开辟了新的途径
。但是，仅有 servlet 还不能为真正的企业计算提供完整的模型。CGI 应用程序本身往
往不是完整的应用程序，在处理接收自 Web 浏览器上用户的信息请求时，CGI 只是整个
处理过程中的一个中间步骤。例如，CGI 应用程序的一种常见用途是访问数据库。将它
用于这种任务时，CGI 程序提供一种方法，将用户的数据请求连接到能满足这种请求的
企业数据库。CGI 程序常常充当一种中间软件，从 Web 浏览器接收请求，决定必须调用
哪些计算资源来满足这些请求，并向浏览器发回响应。Java servlet 与 CGI 程序一样
，最适合充当连接前端 Web 请求与后端数据资源的中间层组件。
三层体系结构
Web 编程向服务器端 Java 应用程序的演化，也带来了体系结构的演化，使它脱离了常
规的客户机-服务器两层模型，而向一种三层方法发展。两层模型当时曾经具有创新意义
，因为它将一些计算任务从主处理器上卸载到灵巧的客户机。常规的基于 LAN 的数据库
应用程序就是一个例子，其中数据库管理器服务器软件驻留在一个专用的服务器机器上
，而用户则通过他们的工作站上的客户机代码来访问数据库。随着客户机-服务器模型成
长到能付诸使用，就出现了对服务器可伸缩性和对客户机代码大小和复杂性的关注。于
是提出了一种三层的体系结构，以避免在两层模型中已察觉到的弱点，使 Web 能成为一
个计算平台：
“许多人...断言，传统的客户机/服务器两层体系结构不会有好的可伸缩性，因为用户
连接和数据访问的数量无法预测，而且在一些系统管理上也存在问题。为处理两层体系
结构的限制，许多开发集体都在转向三层体系结构。这种体系结构大致可以定义为：客
户机层上的表示层、中间的服务器和后端的某种数据库。这种设想的目的就是缓和客户
机或数据库服务器上的代码膨胀，集中管理业务逻辑，更灵活地使用数据库，而不仅是
使用所存储的过程和触发器。”（见 Kim 的“Looking for a 3-Tier App Builder?”
）
一个三层结构模型通常被想像成有一个 Web 浏览器作为客户层。Web 浏览器由于有可能
成为一种真正的通用客户机，使它从观念上取代了两层结构的“胖客户机”。如果浏览
器作为 Web 应用程序体系结构的标准瘦客户机获得认可，那么以前驻留在两层模型的胖
客户机中的功能会怎么样呢？现在，应用程序专用的功能并不移植回服务器（例如数据
库管理器），而是有意将它驻留在一个新的中间层上。中间层支持应用程序服务器软件
，这种软件是中间件的一种形式，它处于第一层上瘦客户机的最小功能和第三层上服务
器端业务系统的丰富功能之间。由于三层体系结构与 Web 处理模型有密切关系，所以中
间层应用程序服务器常被视为 Web 服务器的一种功能扩展。现有的 Web 应用程序利用
 CGI 程序，将来自 Web 浏览器的用户请求传送到不基于 Web 的业务系统，并向浏览器
返回响应，就是三层模型的一种实现。这些应用程序逐渐向 servlet 技术的转移说明三
层模型正在增强。
JavaBeans 组件
JavaBeans 规范将“组件软件”的概念引入到 Java 编程的领域。组件是自含的、可重
用的软件单元；而 JavaBeans 组件，则可以使用可视的应用程序开发工具，可视地将它
们编写到 Java 程序中。JavaBeans 规范为 Java 开发人员提供了一种“组件化”其 J
ava 类的方法：
Bean 是一些 Java 类，可在一个可视的构建器工具中操作它们，并且可以将它们一起编
写到应用程序中。任何具有某种特性和事件接口约定的 Java 类都可以是一个 Bean。（
见 JavaSoft，“Using the Beans Development Kit 1.0”）
如果软件重用是一个好主意，那么是否应该让每一个 Java 类都成为 Java bean 呢？如
果 Java 类满足某些准则，它们就适于充当 bean 的角色：
在开发任何新软件之前，都值得考虑是否用 JavaBean 的形式来开发它。如果软件模块
要既能够可视地操作，又能够定制以达到某些效果，则这种软件模块就可能适于做成一
个 JavaBean。为帮助您确定要开发的软件是否应该是一个 JavaBean，假定它应该是用
 Java 编写的，请向您自已提出以下问题，并相应地作出决定：
是否打算让它可重用？或者，它会是可重用的吗？
是否希望将它与其他可重用的 Java 组件一起使用？
是否预计会在 IDE 工具中使用它？
如果上述问题的答案都是肯定的，则它应该作为 JavaBean 来开发。（见 developerWo
rks 的“JavaBeans Guidelines”）
JavaBean 概念是为了在 Java 编程环境中支持可重用的组件，它是一种一般性的设计方
法，适用于客户机或服务器机器上运行的 Java 程序。由于对可视的构建器工具的强调
，也由于许多 Java bean 都是图形用户界面 (GUI) 组件，所以 JavaBean 组件可能被
视为一种客户端技术。但是，并不要求 Java bean 都是可视的，并且它们也可以用于服
务器环境中。
编码为 Java bean 的 Java 类通常具有以下特征：
使用设计模式。这些模式就是方法和接口的编码约定。
支持可视的软件开发工具。类必须将变量（称为属性）、方法和事件展示出来。
可以定制。定制包括能支持缺省的属性编辑器，或者提供单一的定制规则。定制使开发
人员得以在不更改源代码的情况下更改 bean 的行为。
支持自省 (introspection)。这指的是将属性、方法和事件公开给其他类，可以通过设
计模式或通过创建 BeanInfo 类来完成这种自省。
是持久的。这就允许在一个可视构建器中定制一个 bean，然后以其定制后的状态加以保
存。
Java 2 Platform, Enterprise Edition
Sun Microsystems 发起了一项称为 Java 2 Platform, Enterprise Edition (J2EE) 的
技术创新，旨在将 Java 平台的范围扩展到大规模服务器环境：
“1997 年 4 月 12 日，Sun 宣布了一项为企业环境开发 Java 平台的创新成果。使用
开放式的 Java Community Process，Sun 促进了一组标准的 Java 扩展的开发，称为
Enterprise Java API。这些应用程序编程接口 (API) 为各种各样的中间件的实现提供
了不依赖供应商的编程接口。Enterprise Java API 的要点是 Enterprise JavaBeans
API，后者为 Java 应用程序服务器定义了一个服务器端组件模型，以及一个不依赖供应
商的编程接口。”（见 Thomas 的“Java 2 Platform, Enterprise Edition: Ensurin
g Consistency, Portability, and Interoperability”）
J2EE 为 Enterprise JavaBeans 技术提供了工作环境。事实上，Sun 把若干项软件技术
都设想为这样的构件块，它们将使大型企业能够把以任务为关键的业务系统移植到 Jav
a 环境中，而 Enterprise JavaBeans 技术不过是这些技术之一。EJB 组件是按它们自
己的规范定义的，但 EJB 技术并不是一项独立的技术。它建立在其他 Java 技术之上，
这些技术由 Sun 和其他 IT 公司联合规定，它们一起提供了这个框架的内容，该框架就
称为 Java 2 Platform, Enterprise Edition。
J2EE 中包括以下技术：
Enterprise JavaBeans (EJB) 技术
Java Interface Definition Language (IDL)
Java Message Service (JMS) API
Java Naming and Directory Interface (JNDI)
Java Remote Method Invocation (RMI) 和 Object Serialization
Java Servlet API
Java Transaction API (JTA)
Java Transaction Service (JTS)
JavaServer Pages (JSP) 技术
JDBC 数据库访问 API
参与到这个企业 Java 框架中，并不意味着每项技术都依赖于所有其他技术。单独的规
范文档指出每项技术的相关性。例如，Enterprise JavaBeans 规范 1.0 发行版就指明
了在定位各个组件时与 JNDI 的相关性，以及在编程中启动和停止事务处理时与 JTA 的
相关性。
EJB 技术的设计目标
EJB 规范的第一版以初稿形式于 1997 年 12 月公布，并于 1998 年 3 月作为 1.0 版
发行。规范作者为 EJB 体系结构制定了以下目标：
Enterprise JavaBeans 体系结构将是标准的组件体系结构，用于以 Java 编程语言构建
分布式的面向对象的商务应用程序。通过把使用不同供应商提供的工具开发出来的组件
组合在一起，Enterprise JavaBeans 体系结构将有可能构建分布式的应用程序。
Enterprise JavaBeans 体系结构将使编写应用程序变得容易：应用程序开发人员将不必
了解低层次的事务和状态管理的细节、多线程、资源共享和其他复杂的低级 API。但是
，将允许专家级的程序员直接访问低级 API。
Enterprise JavaBeans 应用程序将遵循 Java 编程语言的“一次编写，随处运行”的原
则。EJB 组件可以只开发一次，然后在多个平台上部署，而不需要重新编译或修改源代
码。
Enterprise JavaBeans 体系结构将处理企业应用程序生命周期中的开发、部署和运行等
方面。
Enterprise JavaBeans 体系结构将定义一些约定，这些约定使多个供应商提供的工具能
够开发并部署可在运行时互操作的组件。
Enterprise JavaBeans 体系结构将与现有的服务器平台兼容。供应商将能够扩展它们的
现有产品，以支持 Enterprise JavaBeans 组件。
Enterprise JavaBeans 体系结构将与 Java 编程语言编写的其他 API 兼容。
Enterprise JavaBeans 体系结构将提供 EJB 组件和非 Java 编程语言应用程序之间的
互操作性。
Enterprise JavaBeans 体系结构将与 CORBA 兼容。
使用 EJB 技术的好处
这些设计目标会使企业和开发人员得到什么好处呢？下面列出了可望从采用 Enterpris
e JavaBeans 环境获得的好处：
EJB 组件使编写应用程序更为简单。尽管 EJB 体系结构复杂，但应用程序开发人员一般
都不必再编写用于访问系统服务的代码。一种称为 EJB 容器的系统组件使系统服务可用
于 EJB 组件的任务。
服务器端商务逻辑可以移植。除了 Java 语言固有的可移植性外，EJB 体系结构还在 b
ean 和支持该 bean 的容器之间提供了一套标准化的应用程序编程接口。这使开发人员
能够将 bean 从一种操作环境移植到另一种操作环境，而无须重新编写其源代码。
可以从现有的软件组件装配出服务器端应用程序，这与从现有的 Java bean 可以装配出
客户端应用程序一样，从而使软件能够重用。
EJB 体系结构内置了对典型企业级系统服务的支持，包括分布式对象、事务处理、数据
库、安全和全局命名。
多家 IT 供应商都采纳 EJB 体系结构，这是由于有这样的承诺：客户将能够从选定的供
应商那里选购软件组件，如 EJB 组件、容器及 EJB 服务器；也由于承诺了不同供应商
的产品，只要符合 EJB 体系结构，就都是可互操作的。
用 EJB 组件构建的应用程序可以从一个服务器移植到另一个服务器，从而支持可伸缩性
，这是因为在 EJB 模型中，各个软件组件都是严格分离的。
EJB 体系结构能保障原有的 IT 投资，这是通过允许将现有的信息系统和资产“包裹”
在这些应用程序中，而不要求客户更换现有技术。事实上，在关系数据库中存储数据的
企业已经有了一套已有雏形的实体 bean，正等着通过 EJB 外壳去访问。
进一步考察 JNDI
Enterprise JavaBeans 组件使用 Java Naming and Directory Interface (JNDI) 来访
问各种目录服务。JNDI 分两部分：应用程序编程接口 (API) 和服务供应商接口 (SPI)
：
“JNDI 体系结构由 JNDI API 和 JNDI SPI 组成。JNDI API 允许 Java 应用程序访问
各种命名和目录服务。JNDI SPI 则是设计来供任意一种服务的供应商（也包括目录服务
供应商）使用。这使得各种各样的目录服务和命名服务能够透明地插入到使用 JNDI AP
I 的 Java 应用程序中。（见 JavaSoft，“JNDI: Java Naming and Directory Inter
face”）
JNDI API 并不同某种专用的命名技术或目录技术连在一起，也不同任何供应商的目录服
务连在一起，因此它对 EJB 组件的可移植性有所贡献。例如，客户可以从多种不同的技
术中选择，来为其 EJB 应用程序提供目录服务，这些技术包括：
LDAP：Sun 的 LDAP 服务供应商支持 LDAP 协议的第 2 版和第 3 版。
NIS：Sun 提供一个 NIS 服务供应商（NIS 即网络信息服务，以前称为黄页）。
COS 命名：Sun 的 COS 命名服务供应商提供对 CORBA 命名服务的访问。
文件系统：Sun 提供一个服务供应商来访问文件系统。
RMI 注册：Sun 为 RMI 注册提供一个服务供应商。
Novell：有几个服务供应商可提供对目录服务 NDS 的访问以及 NetWare 3X 连接库、N
ovell 文件系统和其他 Novell 服务（如扩展 NCP）的访问。
虽然 JNDI 规范对供应商是中立的，但不应认为，实现 JNDI 接口的应用程序服务器一
定要能访问来自多个供应商的服务供应商代码。
JNDI 命名体系结构的关键概念包括：
对象和名称之间的绑定。
若干称为命名上下文的绑定集。
命名系统，即若干组命名上下文。
命名空间，指一个命名系统中的所有名称。
名称分类为原子名称、复合名称和合成名称。原子名称是不可分割的，可以绑定到一个
对象上。复合名称是原子名称的组合，而合成名称则跨越多个命名系统。
命名上下文特别重要：所有的命名操作均是在上下文对象上进行的，并且名称解析过程
总是从最初的命名上下文开始。
EJB 应用程序是如何使用 JNDI 的呢？JNDI 的主要用途是检索对 EJB 组件的引用。因
为 EJB 框架是一个分布式对象框架，所以 EJB 应用程序不应当假定 EJB 组件的位置。
JNDI 就是获取对 bean 的起始引用的一种机制。当一个 bean 安装到一个 enterprise
 bean 服务器上时，一个被称为 EJB 容器的软件组件就负责创建各个名称-对象绑定，
使所需的 Java 类文件能使用这个 bean。应用程序使用 JNDI 的查找方法来检索对象引
用，如下例所示：
Context initialContext = new InitialContext( );
CartHome cartHome = javax.rmi.PortableRemoteObject.narrow(
initialContext.lookup("applications/shopping_cart"), CartHome.class);
应用程序有责任知道外部名称，应用程序就是通过这个名称才得以引用一个 enterpris
e bean，并通过 JNDI 来获取对该 bean 的引用的。
进一步考察 JTA
除 JNDI 以外，Enterprise JavaBeans 体系结构还使用 Java Transaction API (JTA)
。因为事务对维护数据完整性和可靠性很重要，所以支持事务处理是 EJB 体系结构的一
个基本部分。如果企业应用程序是分布式的，事务处理就会更加重要：
“事务的概念是一个重要的编程范例，其目的在于简化既要求可靠性又要求可用性的应
用程序结构，特别是那些需要同时访问共享数据的应用程序。事务的概念最早是用在商
务运作的应用程序中，其中它被用于保护集中式数据库中的数据。后来，事务的概念已
扩展到分布式计算的更广泛的环境中。今天，事务是构建可靠的分布式应用程序的关键
，这一点已得到广泛承认。”（见对象管理组的“Transaction Service Specificatio
n”）
有时将事务描述为具有下列特征的工作单元：
原子性 — 如果因故障而中断，所有结果均撤销
一致性 — 事务的结果保留不变的特性
孤立性 — 中间状态对其他事务是不可见的
持久性 — 已完成的事务的结果是持久的
事务的终止有两种方式：提交一个事务会使其所有的更改永久不变，而回滚 (rolling
back) 一个事务则撤销其所有的更改。
对象管理组织 (OMG) 为一种面向对象的事务服务，即对象事务服务 (OTS)，创建了一种
规范。OTS 是 EJB 体系结构内的事务服务的基础。下列事务规范就是为 enterprise b
ean 所采用的事务模型而设：
OMG 的对象事务服务 (OTS)
Sun Microsystems 的 Transaction Service (JTS)
Sun Microsystems 的 Java Transaction API (JTA)
开放组 (X/Open) 的 XA 接口
这种与语言无关的对象事务服务，为一个强健的分布式事务服务提供了基本概念、定义
和功能。
Java Transaction Service 是 OTS 的 Java 映射，在 org.omg.CosTransactions 和
org.omg.CosTSPortability 这两个包中定义。JTS 对事务分界和事务环境的传播之类的
服务提供支持。JTS 功能由应用程序通过 Java Transaction API 访问。
Java Transaction API 指定事务管理器与分布式事务中涉及的其他系统组件之间的各种
高级接口，这些系统组件有应用程序、应用程序服务器和资源管理器等。JTA 功能允许
事务由应用程序本身、由应用程序服务器或由一个外部事务管理器来管理。JTA 接口包
含在 javax.transaction 和 javax.transaction.xa 这两个包中。
XA 接口定义了资源管理器和分布式事务环境中外部事务管理器之间的约定。外部事务管
理器可以跨多个资源协调事务。XA 的 Java 映射包含在 Java Transaction API 中。
内容预告
“什么是 Enterprise JavaBeans 组件？”的第二部分将讨论 EJB 编程模型。
参考资料
要了解更多有关 Java 技术和 EJB 体系结构的内容，请访问 Sun 的网站。
关于从 applet 和应用程序的角度看 Java 编程，请阅读 David Flanagan 所著的 Jav
a in a Nutshell。
下载一份 Java Servlet API Specification 的副本。
下载 Java Developer's Journal 第 3 卷第 1 期中 Tom Kim 所写的“Looking for a
 3-Tier App Builder?”(PDF)。
参加 JavaSoft 的“Using the Beans Development Kit 1.0”课程。
从 “JavaBeans Guidelines”中可以发现一些补充的指导原则，它们使您能开发出性能
优良的 Bean，这些 Bean 能够在大多数环境中表现良好，包括流行的各种 IDE 和各种
浏览器。
阅读 Patricia Seybold Group 的 Anne Thomas 所写的 “Java 2 Platform, Enterpr
ise Edition: Ensuring Consistency, Portability, and Interoperability” 中对
J2EE 的详细说明。
查阅 “JNDI: Java Naming and Directory Interface” 中的 JNDI 体系结构和接口的
概述，以及各种情况和示例。
了解 Java 2 Platform, Enterprise Edition 中包含的以下 Java 技术：
Java IDL
Java Message Service (JMS) API
Java Naming and Directory Interface (JNDI)
Java Remote Method Invocation (RMI)
Java Transaction API (JTA)
Java Transaction Service (JTS)
JavaServer Pages (JSP) 技术
JDBC 数据访问 API
要了解常见问题、与 LDAP 相关的 RFC 以及更多信息，请访问 Mark Wahl 的 LDAP 网
站。
要了解如何将 Linux 配置为 NIS(YP) 或 NIS+ 客户机及如何安装成 NIS 服务器，请查
阅 Linux NIS(YP)/NYS/NIS+ HOWTO。
下载 Java IDL 的命名服务 COS naming。
详细了解 Java Remote Method Invocation (RMI)，包括规范、示例和常见问题。
了解 Novell 提供的大量的产品和解决方案。
访问 Object Management Group (OMG) 的网站。
查阅开放组的 XA interface 规范。
作者简介
Ken Nordby 是位于 Research Triangle Park，North Carolina 的 IBM 软件开发实验
室的软件工程师。作为 SWG Product Affinity Services 工作组的成员，Ken 和他的
IBM 同事从事 IBM WebSphere Application Server（Enterprise JavaBeans 的 IBM 实
现）的开发及咨询工作。可以通过 nordby@us.ibm.com 与 Ken 联系。
--

--
※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: 天外飞仙]