企业JAVABEANS技术-Java平台的服务器组件模型


(来源:http://www.sun.com)

Thomas托马斯
Patricia Seybold Group
1998年十二月修订
为 太阳 微系统 公司 准备 。

引言

企业 JavaBeans 技术

企业 JavaBeans (EJB) 技术定义了发展和实施可重用的 Java 服务器组件模型。组件是事先开发好的,并能组装进正在运行 的应用程序系统中的程序代码片断。Java 目前有一个组件模型 称为 JavaBeans,它支持可重用的开发组件。 EJB 结构在逻辑 上扩展了 JavaBeans 组件模型以支持服务器组件。

服务器组件

服务器组件是运行在服务器上的应用程序组件。EJB 技术是 Sun 的企业 Java 平台的一部分。Sun 的企业 Java 平台是一强大的 Java 技术环境,能支持面向大规模的,分布式的,关键业务的应 用系统的严峻要求。EJB 技术支持基于多层(multitier),分布式 对象体系结构的应用开发。在这种体系结构下,应用逻辑大部分 被从客户端移到服务器端。应用逻辑分为一个或多个业务对象在 应用程序服务器上实施。

Java 应用程序服务器

Java 应用程序服务器为服务器端的 Java 应用程序组件提供一个 优化的执行环境 。通过把传统的 OLTP 技术与新的分布对象技 术结合在一起,Java 应用程序服务器提供了一种尤其适合支持因 特网应用的高效, 高度可伸缩,健壮的执行环境。

WORA

企业 JavaBeans 体系结构定义支持“写一次,运行在任何地方” (WORA)可移植性的 Java 应用程序 服务器标准模型。WORA 是 Java 技术的主要信条之一 。 Java  虚拟机 (JVM ) 允许 Java 应用程序在任何 操作系统上运行。但是服务器组件要求不由 JVM 直接提供的附加的服务。这些服务或由应用程序服务器提供或由 分布对象基础结构 , 例如 CORBA 或 DCOM 提供。传统地,每种 应用程序服务器提供一套专门的编程接口访问这些服务 , 并且服 务器组件不能从一种应用程序服务器移植到另一种应用程序服务 器上。例如 , 设计在 BEA Tuxedo 运行的一个服务器组件,如果 不做大的修改,就不能在 IBM TXSeries 上执行 。 EJB 服务器 组件模型为所有的 Java 应用程序服务器定义了一套独立于供应 商的标准的接口 。

件可移植性

企业 JavaBeans 技术把 WORA 概念提高到一个新的高度。这些组 件不仅能在任何平台上运行,而且他们在任何供应商的与 EJB 相 容的应用程序服务器之间完全可移植。 EJB 环境自动地映射组件 到底层的供应商特定的执行服务。

案例

股票资金帐户

例如, Money Makers 是一家大的经纪人事务所,就使用企业 JavaBeans 技术实现管理股票资金帐户的应用系统。Money Makers 想要向客户提供自助的电子交易系统。为了有效地支持经 纪人和客户,应用程序采用了瘦客户机,分布式对象体系结构。 应用程序的体系结构如插图1。

多客户支持

应用程序能支持许多种客户设备,包括桌面工作站,Web 浏览 器,电话,Internet 终端,智能卡或者其它的可接入 Internet 的设备。

通讯协议

客户应用能使用多种协议与股票资金应用程序通信。Java 客户程 序通过本地的 Java 远程方法调用 (RMI) 接口调用服务器应用程 序。RMI 请求通过 Java 远程方法协议(JRMP)传输。在未来,RMI 将被扩展以支持工业标准 Internet InterORB 协议(IIOP)。本地 语言客户程序可以使用运行在 IIOP 协议之上的 CORBA IDL 或者 COM/CORBA 网络互连服务调用服务器应用程序。RMI 客户代理 也能作为 ActiveX 控制方便地提供与任何 Windows 应用程序集 成。浏览器能通过运行在 HTTP 服务器上的 servlet 调用应用 程序。浏览器与 servlet 使用 HTTP 通信,而 servlet 则与应 用程序使用 RMI 通信。

服务器执行环境

Money Makers 有数以百万计的客户,因此期望这个系统能处理大 量的事务。因此,该公司选择了 Big Guns System Software 的 EJB 兼容服务器,并运行在一簇具有容错能力的高速度多处理器 上。Big Guns 系统是基于企业级的事务处理(TP)监视器,以其有 效利用资源而著称。Big Guns 支持对应用程序组件的透明分配和 复制。

外购的应用程序

Money Makers 并没有从头开发整个应用,而是向一个应用软件供 应商 Portfolio Incorporated 购买了一套作为一组企业 JavaBeans 组件实现的股票资金帐户管理系统, Portfolio 使用 由一个数据库供应商提供的 EJB 环境开发和测试了这个应用。

定制和改进

尽管 Portfolio 应用程序提供了管理客户帐户和组织证券组合的 功能,但它并不使用最新股价计算当前帐户余额,它也不支持在 线交易。

Money Makers 设定股票组件让它从实时的数据流中获取最新股 价。为此 Money Makers 使用了Garage Enterprises 开发的 EJB 兼容的股票信息传送组件。Garage 是一家新兴的公司,预算很 紧。该组件是使用公共的 EJB 兼容服务器开发和测试的。

Money Makers选择了通过 CORBA 把现有的交易系统封装并与 Portfolio 系统集成来实现在线交易。

企业 Java TM 平台

使可移植性可能

企业 Java 平台使 EJB 组件的可移植性特性成为可能。 企业 Java 平台包括一套标准的 Java 应用程序编程接口(API)以提供 对核心的企业级基础服务的访问。(参阅描述企业 Java API 的 附表)。术语“企业”暗示着高度可伸缩,高度可获取,高度可 靠,高度安全,事务性的分布式应用程序。企业应用要求访问许 多基础服务,例如分布的通讯服务,命名和目录服务,事务处理 服务,发送消息服务,数据存取和保持服务及资源共享服务。这 些基础服务通常在不同的平台上使用不同的产品和技术实现,这 使得构造可移植的企业级应用系统很困难。企业 Java API 为支 持的基础结构提供了一套通用的界面,通用于所有实际的实施。

与现有基础设施的集成

Sun 本可定义一套新的支持企业 Java 平台的基础服务。过去, 标准化组织为支持新环境而定义新服务很常见。例如,X/Open 定义了分布事务处理(DTP)模型和 XA 标准,OSF 定义了分布计 算环境(DCE)服务,OMG 定义了 CORBA 对象服务(COS,也称 CORBA 服务)。Microsoft 已经定义了支持 DCOM 的一套集成的 NT 服务。与此同时,每一家 TP Monitor 和应用服务器供应商 也提供各自专用的基础服务。许多基础服务执行相似的功能却不 具备互操作性。

[ Money Makers 帐户管理 系统 ]
图 1. Money Makers 帐号管理系统使用了两家供应商的应用程序并且是与
现有的应用系统集成的。这个应用程序通过多种协议支持许多客户设备。

Sun 并没有走老路。企业 Java 平台定义了一套提供访问现有的 基础服务的标准 Java API。使用这些Java API,开发者可以利用 现有平台上的任何企业服务实现应用程序系统。例如,在一个系 统上使用 IBM TXSeries ,DCE 服务和 Oracle 的应用程序能被移 动到一个不同的系统上,并且自动地改用 BEA Systems M3, LDAP 和 Sybase。不需要做别的工作。

对平台和供应商中立

企业 Java API 是完全对平台和供应商中立的。 API 设计成在多 供应商的异种基础服务上的层次。每个 API 提供到一类通用基础 结构服务的通用编程接口。如果提供这种类型服务的每个供应商 都实现这个 API,应用程序就能通过公共接口访问任何服务供应 者 。

ODBC 隐喻

企业 Java API 把 Microsoft 的 ODBC 隐喻应用到所有的基础结 构服务。ODBC 隐喻是所有关系数据库的公共接口。例如,Java 命名和目录接口(JNDI )提供标准命名和名录服务的接口。JNDI API 能被用来访问任何 供应商的目录服务 , 例如 Microsoft Active Directory, Novell NDS ,Sun NIS+, 或任何 LDAP 目录。

企业 Java APIs
API 描述
EJB 企业 JavaBeans API 定义在应用程序服务器之间 可移植的并为应用组件实现自动服务的服务器组 件模型。
JNDI Java 命名和目录接口提供命名和目录服务,例如 DNS,NDS,NIS+,LDAP,和 COS 命名。
RMI 远程方法调用 API 为 Java 平台上的分布式计算 创建远程接口。
Java IDL Java 接口定义语言 API 在 Java 平台上创建支 持 CORBA 通信的远程接口。Java IDL 包括 IDL 编译器和一轻的、可替代的支持 IIOP 的 ORB。
Servlets 和JSP Java Servlets 和 Java Server Pages API 支持 动态 HTML 生成和浏览器客户会话管理。
JMS Java 消息服务 API 支持通过不同消息系统的异 步通信,例如可靠队列和出版订阅服务。
JTA Java 事务处理 API 提供事务划分 API。
JTS Java 事务处理服务 API 定义基于 CORBA 对象事 务处理服务的分布式对象事务管理服务。
JDBC TM JDBC 数据库访问 API 提供对关系数据库的一致 访问,例如 DB2, Informix, Oracle, SQL Server 和 Sybase 。
表 1 。 企业 Java API 。

工业界的认可

为了获得成功,这种方案需要为广大的供应商所认可。如果基 础结构供应商不在现有的基础结构产品中加入对这些 API 的支 持,这些 API 将毫无用处。Sun 竭力保证企业 Java 平台遵循 大多数流行的标准。Sun 还聘用了每一种基础服务方面的精英 以确保企业 Java API 满足大容量,关键业务应用的开发。交 易管理(IBM,Compaq/Tandem, BEA 系统,等等),坚持管理 (Oracle,Sybase,Informix,等等)和目录服务(HP,IBM, Novell 等等)等方面的业界领袖参与了企业 Java API 的开发。 早期的情形表明,工业界象欢迎 Java 技术一样欢迎企业 Java 技术。越来越多的供应商宣布他们打算支持企业 Java API,而 许多供应商已经交付了兼容的产品。

基于组件的计算

多层 的应用程序 体系结构

可伸缩性

企业 Java 平台设计目标是提供一种适合于开发和实施完全可移 植的基于 Java 技术的企业级应用系统环境。企业应用程序系统 的真实度量往往体现在系统的可伸缩性和总吞吐量。多少用户可 以同时使用这个系统?多少对象可以在给定的时间片内被实例 化?每秒钟能处理多少交易?

下一代 客户机/服务器

企业应用系统通过多层,分布式应用结构支持高伸缩性。多层的应 用程序是分为多个应用组件的应用程序。Multitier 用与传统的 客户机/服务器体系结构相比,有许多明显的优点,包括可伸缩 性,性能改进,可靠性,可管理性,可重用性以及灵活性。

应用程序分块

在传统的客户机/服务器应用程序里,客户应用程序包含显示逻辑 (窗口和控制处理), 商业逻辑(算法和商业规则), 数据操作逻辑 (数据库连接和SQL查询)-- 胖客户机"。服务器通常是一关系数据 库管理系统,实际上并不是应用程序的一部分。在一多层体系结构 里, 客户应用程序只包含显示逻辑-- "瘦客户机"。 商业逻辑和 数据存取逻辑分为不同的组件安装在一个或多个服务器上。

改进性能和可伸缩性

把商业和数据操作逻辑挪到服务器端有利于应用程序利用多线程 和多处理系统的强大功能。服务器组件能缓冲和共享紧张的资 源,例如进程,线程,数据库连接和网络会话。当系统要求增加, 高使用频率的组件能复制并分布到多系统中去。尽管现代的客户 机/服务器系统能很容易地支持几百个用户同时使用,但他们的可 伸缩性有限。多层系统创建得几乎没有可伸缩性的限制。如果设 计有效率,更多的服务器可以加入以达到提高性能和增加用户的 目的。多层系统能扩展到支持数十万乃至数百万的用户同时使用。

增加可靠性

多层环境能支持多级冗余。通过复制和分配,多层体系结构能消除 瓶颈或单个节点的错误。多层方法支持高可靠性和系统的持续作 业能力以从事关键业务操作。

增加可管理性

瘦客户机应用比传统的客户机/服务器应用更容易管理。在客户机 上只执行很小的一段代码。大多数应用程序逻辑在服务器上展开, 管理以及维护。修理,升级,新建的版本,扩展名能都通过一个集中 式管理环境管理。

增加灵活性

多层应用程序体系结构支持极其灵活的应用程序系统。应用程序 逻辑的多数在小的模块化的组件中实现了。组件中的实际的商业 逻辑被封装在一个抽象的,充分定义的接口后面。单个组件内的 代码不要求更改接口就可以修改。因此, 一个组件的更改不会影 响在应用程序内的其他组件。多层应用能很容易的进行修改以 反映变化的商务需求。

可重用性和集成

出于它接口本性,一个服务器组件是一个可重用软件构件。每组件 执行通过接口公开了可以被任意一个应用访问的一组特定的功 能。一个特定的商业功能只须实现一次,然后就可在需要使用该功 能的任何应用程序里重用。如果一个组织保有一个全面的组件 库,应用程序开发就变成按所需的功能要求把合适的组件装配在 一起的工作。

多客支持

任意数目的客户环境都能通过它的界面访问同样的服务器组件。 单个的多层应用系统能支持许多客户设备,包括传统的桌面工作 站,网络客户端,或者更高级的客户,诸如信息装置,智能卡或 者个人数据助理等。

多层的动力

虽然服务器组件和多层结构的概念提出已近十年,但只有相对很少 的组织应用它们。直到最近,大多数组织并未因感到可伸缩性压力 而考虑采用多层体系结构。但是来自 Web 计算的动力正在使他们 对多层结构发生兴趣。网上商业应用要求瘦客户端体系结构以支 持大的可伸缩性和支持基于浏览器的客户机和快速的小程序下载。

难于开发

不幸的是,构造多层应用不象构造客户机/服务器程序那么容易。 多层应用必须和许多中间件应用打交道。为了达到多层计算可伸 缩性,性能,可靠性方面的特性,多层应用必须支持多线程,资源 共享,复制和负载平衡。

应用程序服务器

应用程序服务器自动化了多层计算的一些很复杂的特性。应用程 序服务器为应用程序管理并循环诸如进程,线程,内存,数据库 连接和网络会话等紧缺的系统资源。一些比较复杂的应用程序服 务器提供负载平衡服务,把应用程序分配给多个系统处理。应用 程序服务器也提供到基础结构服务的存取, 例如命名,目录,交 易,持续性和安全性。但是,直到最近,每一种应用程序服务器 都使用一套专门的接口。每个企业应用程序在实现时不得不考虑 到特定的运行环境,而且应用程序,甚至连 Java 应用,在应用 程序服务器之间不可移植。

企业 JavaBeans 规范

企业 JavaBeans 规范为支持完全可移植的 Java 应用程序服务器 定义了一个标准模型。任何供应商都能使用这个模型实现对企业 JavaBeans 组件的支持。诸如 TP 监视器,CORBA 运行系统 ,COM 运行系统 ,数据库 系统 ,Web 服务器系统 ,或其它基于服务器的 运行系统都能被改编以支持可 移植的企业 JavaBeans 组件。

组件 概述

组件

组件是一个可重用软件构件: 一个预先构建的封装的代码模块, 它能够与其他组件或是硬编码一道很快地生成定制的应用程序。

容器

组件在一个称为容器结构中执行。容器为一个或更多的组件提供 应用的上下文并且为组件提供管理和控制服务。用术语表达就 是,容器提供操作系统进程或线程以使该组件得以执行。客户组 件通常在可视的容器以内执行,例如表单,复合的文档或者网 页。服务器组件是非可视的并且在由例如事务处理应用程序(TP) 监视器,Web 服务器或是数据库系统所提供的容器内执行。

组件模型

组件模型定义组件的基本的体系结构,指定它的接口的结构,及它 与它的容器及另外的组件交互的机制。组件模型提供了创建并且 实现能一起工作以形成更大的应用程序的组件的指南。应用程序 构造者能把从不同的开发者或不同的供应商获取得的组件连接起 来构造应用程序。

间隔尺寸

组件的形状和大小各不相同。组件可能是很小的,例如一简单的 GUI 控件(例如按钮),也许它能实现复杂的应用程序服务,例如帐 户管理功能。

标准接口

作为组件,应用程序代码必须提供允许应用程序的其他部分调用它 的函数,以及存取和操作它内部的数据的标准接口。接口的结构是 由组件模型定义的。

没有源代码的定制

应用程序开发者应该能在不要求访问源代码的情况下充分地利用 组件。组件能通过定制一套外部的属性值来满足应用程序的特定 的要求。例如,按钮组件有指定应该在按钮上出现的名称的属性。 帐户管理组件有指定帐户数据库的位置的属性。属性能被用来支 持强大的定制服务。例如,帐户管理组件可能允许用户在超过某个 美元金额的提款之上添加特殊的批准进程。一个属性将被用来显 示该特殊批准函数是激活的,第二个属性将标识要求特别批准的条 件,第三个属性用来标识当条件满足时应调用的批准进程组件的 名字。

组件市场

组件技术的诺言之一是这样一个世界,定制的商业解决方案能从一 套现成的商业对象经过集成后得到。软件供应商能生产无数的专 业化的商业组件,而商业组织能选择适当的组件来匹配他们的商业 需要。现在,有很大一批现成的第三方客户端的开发组件。暂时 服务器端的组件的市场仍然是很年轻的。随着越来越多的组织采 用服务器组件体系结构,市场可能快要成熟了。开发应用软件的公 司已经开始实现使用服务器组件的应用。一些电子商务供应商正 开始提供一些单个的应用功能,例如购物手推车和信用验证,作 为可定制的组件。

服务器组件

共享服务器

为了从多层体系结构中最大程度的受益,服务器组件应该实现成为 共享的服务器。但是构建共享服务器比构造单用户应用功能要困 难。高度可伸缩共享服务器需要支持并行用户, 需要高效地共享 紧张的系统资源,例如线程,进程,内存,数据库连接和网络连接紧 张的系统资源,例如线程,进程,内存,数据库连接和网络连接 等。对于商业应用,共享服务器必须参与事务处理。在许多情形 中,共享服务器需要加强安全性规则。

即插即用式的集成

组件开发者特别不想在每一个组件中实现多线程,并行控制,资 源缓冲区,安全性以及事务处理管理。如果这些服务是在每组件 中实现的,要做到真正的即插即用的应用程序整合将是很困难 的。组件模型使这些服务的使用统一并且自动化,从而使应用程 序开发变得容易。

容器

应用程序服务器提供管理组件执行的容器。当客户程序调用服务 器组件时,容器自动地分配进程线程并初始化组件。容器为组件 管理所有的资源和它与外部系统的交互操作。

应用程序服务器的例子

现在普遍使用的有许多不同类型的应用程序服务器,每一种都提 供了一个为某种类型的基于服务器请求服务的容器。例如:

  • TP 监视器包含事务处理(Transaction)并且代表事务处理 管理共享资源。多重的事务处理能一起工作并且依靠 TP 监视器协调扩展的事务处理。
  • 数据库管理系统 (DBMS) 包含数据库请求。多个数据库用 户能并发地对数据库提交请求并且依靠 DBMS 协调锁定和 事务处理。
  • Web 服务器包含网页请求。多个 Web 用户能向 Web服务器 提交并行的页请求。Web 服务器对不同请求相应地响应 HTML 页或调用服务器扩展或 servlet 服务。

跨容器的可移植性

容器的操作和行为是由它的组件模型定义的。不幸的是,每个容 器用它自己的服务接口实现它自己的服务的集合。结果,为某一 类环境开发的组件通常对其他类型的环境是不可移植的。然而, 企业 JavaBeans 组件模型则为这些容器系统设计了一个可移植 的层次。

企业 JavaBeans 组件 模型

企业 JavaBeans 技术概述

JavaBeans 开发组件

企业 JavaBeans 组件模型在逻辑上扩展了 JavaBeans 组件模 型。JavaBeans 组件模型定义了开发诸如控件或控制的可移植, 可重用 Java 开发组件的标准机制。JavaBeans 技术可以使用 在任何可视化 Java 集成开发环境中,例如 IBM Visual Age, Inprise JBuilder ,Sybase PowerJ, 和Symantec Visual Cafe。 Java 开发人员使用可视化 Java IDE 开发 Java 类,Java 小程 序, Java 应用或 Java 组件。JavaBeans 组件(bean)是能添加 到应用开发项目并且能由 Java IDE 控制的专门 Java 类。Bean 提供了可视化 Java 开发工具不经访问源代码便可检查并定制 bean 的内容和行为的线索。多个 bean 能互相组合或连接,构造 Java 小程序或应用或创建新的更全面,更专业化的 JavaBeans。

企业 JavaBeans 组件模型

企业 JavaBeans 组件模型在逻辑上扩展了 JavaBeans 组件模型 以支持服务器组件。服务器组件是设计运行在服务器上可重用 的,预包装的程序功能片断。它们能和其它组件组合生成定制的 应用系统。服务器组件与开发组件类似, 但它们通常更大更完 善。企业 JavaBeans 组件(企业 bean)与 JavaBeans 组件不同, 不能被可视化 Java IDE 所操纵。但是,利用 EJB 兼容的 Java 用程序服务器所提供的工具,它们能在实施时组装和定制。

简化开发

企业 JavaBeans 体系结构提供了一个集成的应用程序框架,极大 地简化了开发企业级应用系统的过程。EJB 服务器自动为应用组 件管理繁杂的中间件服务。EJB 组件开发者可以集中精力在业务 逻辑而不是中间件上。结果,程序开发的速度和代码的质量得到 提高。

隐含的服务

EJB 模型支持许多隐含的服务,包括生命周期,状态管理,安全 性,事务处理和持续性。

  • 生命周期。单个的企业 bean 不需显式地管理进程调度, 线程管理,对象激活或对象清除。EJB 容器代表企业 bean 自动管理对象的生命周期。
  • 状态管理。单个的企业 bean 不需在方法调用之间显式地 存储或恢复对话对象的状态。EJB 容器代表企业 bean 自动 管理对象状态。 。
  • 安全性。单个的企业 bean 不需要显式地验证用户或检查授 权级别。EJB 容器代表企业 bean 自动执行所有安全检查。
  • 事务处理。单个的企业 Bean不需要显式地指定事务处理划 界代码来参与分布式的事务处理。EJB 容器自动代替企业 bean 管理事务处理的起始, 进行,执行以及复原。
  • 持续性。单个的企业 bean 不需显式地从数据库中获取或存 储持续性对象数据。EJB 容器自动代替企业 bean 管理持续 性数据。

可移植层

企业 JavaBeans 模型定义企业 bean 组件和企业 bean 容器之间 的相互关系。企业 JavaBeans 组件不要求使用特定的容器系统。 只需添加对规范中定义的服务支持,供应商可以使任何一个应用 程序服务器支持企业 JavaBeans 技术。这些服务在企业 bean 和 容器之间定义一个契约,可以有效地实现可移植层。任何企业 bean 都能在支持企业 JavaBeans 契约的任何应用程序服务器中 运行。

执行服务

与企业 JavaBeans 兼容的应用程序服务器,也称为 EJB 服务 器, 须提供一套标准的服务来支持企业 bean 组件。企业 JavaBeans 是与事物处理有关的。因此,EJB 服务器必须提供 对分布式的的事务管理服务的访问。EJB 服务器必须也为企业 bean 提供一个容器,称为 EJB 容器。EJB 容器为一个或多个企 业 JavaBean 对象类实现管理和控制服务。它也提供为企业 bean 进行生命周期管理,隐式的事务处理控制,持续性管理,透明的 分配服务和安全性服务。在大多数情形下,一个供应商将同时提 供 EJB 服务器和关联的EJB 容器,尽管EJB的规范允许这些服务 的分离。例如,第三方供应商可能提供一个通过对象/关系映射 实现持续性的附加容器。

潜在的企业 JavaBeans 系统

进程管理,线程缓冲池,并行性控制和资源管理的准确定义并不 在企业 JavaBeans 规范的范围以内。供应商能根据所提供服务 是否复杂来区别他们的产品。软件供应商可能选择开发一个新的 应用程序服务器来支持企业 JavaBeans。但更可能只是简单地改 编他们的现有的系统。当前存在着一些应用程序服务器。这些系 统的任何一个都能经过扩展支持企业 JavaBeans 容器。相当多 的供应商提供了很多产品,包括:

  • TP 监视器,例如IBM TXSeries 和 IBM CICS/390
  • 组件事务处理服务器,例如 Sybase Jaguar CTS
  • CORBA 系统, 例如 BEA Systems M3, IBM WebSphere Advanced Edition, 和 Inprise VisiBroker/ITS
  • 关系数据库系统, 例如 IBM DB2, Informix, Oracle, 和 Sybase
  • 对象数据库系统 , 例如 GemStone GemStone/J
  • 对象/关系缓存系统,例如 Persistence PowerTier 和 Secant Extreme
  • Web 应用服务器, 例如 BEA WebLogic, Bluestone Sapphire, IBM WebSphere, Netscape Application Server,Oracle Application Server, Progress Apptivity, SilverStream Application Server 和 Sun NetDynamics。

通用性

企业 JavaBeans 模型提供了具有空前高级别的整合和互操作 性。企业 JavaBeans 应用能用任何兼容企业 JavaBeans 的环 境开发,用户能在任何其他的环境中展开应用。如果出现更高的 性能要求,增加可伸缩性,或更严密的安全性要求,用户可以将 应用移到提供更复杂更全面服务的环境。

结构细节

大图

企业 JavaBeans 服务器

EJB 服务器提供一个支持环境,保障使用企业 JavaBeans 技术 开发出来的应用的执行。它管理并且协调资源在应用间的可分配。

EJB 容器

插图2显示的是一个代表性的 EJB 容器。EJB 服务器必须提供 企业 beans 使用的一个或多个 EJB 容器。EJB 容器管理它所 包含的企业 beans。对于每一个企业 bean, 容器负责对象的 注册,为对象提供远程接口,创建和清除对象实例,为对象检 查安全性,管理对象的活动态和协调分布式事务处理。可选地, 容器也可管理对象内的所有稳态数据。

在 EJB 容器内安装企业 Beans

一个 EJB 容器里可以安装任意多的 EJB 类。 某一特定的企业 bean 的类只被分配到一个唯一的EJB容器。但是容器并不一定代 表物理位置。EJB 容器的物理说明并未在企业 JavaBeans 的规 范中定义。一个 EJB 容器能作为一物理的实体实现,例如在一个 EJB 服务器上的一个多线程的进程。它也能作为一逻辑的实体实 现,能够跨越任意数目的系统和进程进行复制和分布。

暂态和稳态对象

企业 JavaBeans 技术支持暂态的和稳态的对象。暂态的对象称 为会话 bean,稳态的对象称为实体 bean。

会话 Bean 会话 bean 是由客户机创建的,在大多数情形下仅仅存在于单个 的客户机/服务器对话的持续时间内。会话 bean 代表客户的操 作,例如存取数据库或执行计算操作。会话 bean 可能是与事务 处理有关的,但是(通常)如果系统一旦崩溃,它们不可恢复。会话 对象可能没有状态,或他们能在方法和事务处理之间维持临时的状 态。如果需要把会话 bean 从内存释放,容器将会对其临时的状态 进行管理。会话 bean 则必须管理它自己的稳态数据。

企业 JavaBeans 容器
[ 企业 JavaBeans 容器 ]
插图2 企业 bean 被部署在 EJB 服务器内的 EJB 容器中。EJB 容 器充当客户程序和企业 bean 的纽带。实施时,容器自动地产生 EJB Home 接口代表企业 bean 类,并为每个企业 bean 实例产生 EJB Object 接口。EJB Home 接口标志企业 bean 的类,并用以创 建、寻找和清除企业 bean 的实例。EJB Object 接口提供对 bean 内的业务方法的访问。客户所有的对 EJB Home 或 EJB Object 接 口请求都被 EJB 容器所截获,插入生命周期,事务处理, 状态以 及安全性及持续性规则后才能进行所有的操作。

实体 Bean 实体 bean 维护于某一永久性数据存储中的,例如维护于数据库 中的稳态数据的对象表示。实体 bean 每一实例由一主关键字标 识。实体 bean 可以通过使用对象工厂(object factory)的 create 方法或直接把数据插入到数据库来进行创建。实体对象是与事件 处理相关的,它们在系统崩溃后可恢复。

容器管理的稳态

实体 bean 能管理它的自己的稳态,或委托容器管理它的稳态。如 果 bean 把稳态管理交给容器代理,容器自动地为 bean 执行所 有数据存取操作。

实体对象是可选的

在企业 JavaBeans 规范 1.0 版中,对会话 bean 的支持是必须 的,但是对实体 bean 和容器管理的稳态的支持是可选的。将来 的版本将要求对这些特性的支持。

标准协议

企业 bean 能在任何 EJB 服务器上实施,即使不同的服务器使用 不同的方法实现他们的服务。EJB 模型通过一套在 EJB 容器和企 业 bean 之间的标准协议确保在不同 EJB 服务器之间可移植性。 每个企业 bean 都必须实现一套特定接口,以允许EJB 容器管理 并且控制它的对象。EJB 容器则要求在执行的特定阶段调用这些 接口。

包络和截取

EJB 容器管理其包含的企业 bean。客户应用不直接与一企业 bean 产生交互。相反,客户应用程序通过容器生成的两个包络 接口:EJB Home 接口和EJB Object 接口与企业 bean 交互。当 客户通过包络接口调用操作时,容器截取方法调用并插入管理服 务。

EJB Home

EJB Home 接口提供了对 bean 的生命周期服务的访问。客户可通 过 Home 接口创建或清除 bean 实例。对于实体 bean, Home 接口还提供了一个或多个发现方法,以允许客户找到存在的 bean 的实例并从稳态数据存储中取出来。

命名和注册

对每一个安装在容器内的类,容器自动地用 Java 命名和目录接 口 (JNDI) API 在一个目录中注册 EJB Home 接口。使用 JNDI, 客户能找到 EJB Home 接口以创建新的 bean 的实例或找到现存 的实体 bean 的实例。当客户创建或寻找 bean 时,容器返回一 个 EJB Object 接口。

EJB 对象

EJB 对象接口提供对企业 bean 内业务方法的访问。EJB 对象代 表企业 bean 的一个客户视图。EJB 对象暴露所有与应用有关的 接口,但不包括允许 EJB 容器管理并且控制对象的所需的接口。 EJB 对象包络器允许 EJB 容器截取所有在企业 bean上做的操 作。每次客户在EJB 对象上调用方法时,这个请求首先通过 EJB 容器然后才被代转到企业 bean 上。EJB容器实现状态管理, 事务 处理控制,安全性和持续性服务。这些服务对客户和企业 bean 都是透明的。

声明属性

企业 bean 管理生命周期,事务处理,安全和持续性的规则定义 在附属的实施描述对象中。这些规则是在实施时声明式定义而非 在开发时程序式定义的。在运行时, EJB 容器根据跟企业 bean 相关联实施描述文件中所定义的事物属性值自动地实施事务处理 服务。

上下文对象

EJB 容器产生一个实例的上下文对象以维持每个活跃的企业 bean 的管理规则和当前状态。会话 bean 使用一个 SessionContext 对象,实体 bean 使用一个 EntityContext 对象。企业 bean 和 EJB 容器共同使用上下文对象来协调 事务处理,安全性, 稳态以及其它系统服务。同时,每个企业 bean 还有一个称为环境对象的属性表格与之相关联。环境对 象包含了在应用程序组装进程或企业 bean 实施进程期间定 义的属性值的集合。

分布式服务

远程方法调用

企业 JavaBeans 技术通过 Java 远程方法调用(RMI) API 访问 企业 bean。企业 bean 的开发者必须为每个企业 bean 定义一个 RMI远程接口。容器为从远程接口定义生成 EJB 对象接口。

位置透明性

RMI 是一种高级程序设计接口,它可以使服务器的位置对客户透 明。RMI 编译器为每一个远程接口产生一存根对象。存根对象安 装在客户系统上(或在运行时下载)并且为客户提供一本地的代理 对象。存根实现所有的远程接口并且越过网络透明地对远程对象 托付所有的方法调用。

协议

企业 JavaBeans 规范并不要求特定的分布对象协议。RMI 能支 持多种通讯协议。Java 远程的方法协议 (JRMP) 是 RMI 本地的 协议。它支持 RMI 所有功能。下个 RMI 版本将支持使用 CORBA 标准的通讯协议,Internet InterORB 协议(IIOP)的通讯。IIOP 在RMI 以内支持几乎所有的功能。只依靠 RMI 的RM../../j/ejb/IIOP 子集 的企业 bean 在两协议之间是通用的。第三方 RMI 实现支持其 它协议,例如安全套接字层(SSL)。

本地语言集成

通过使用IIOP,企业 bean 可以与本地语言的客户端和服务器 进行互操作。IIOP 使得在 CORBA 系统和 EJB 系统之间可以容 易地集成。企业 bean 能访问 CORBA 服务器, CORBA 客户端 能访问企业Bean。使用COM/CORBA 网络互连服务,ActiveX 客 户端也能访问企业 Bean,企业 bean 也能访问 COM 服务器。 同样也存在着企业 JavaBeans 技术的 DCOM 实施的可能性。

状态 管理

资源优化

单个的 EJB 服务器系统能使用不同的策略管理诸如内存和线程 等稀少的资源。一些 EJB 服务器可能在内存里维持所有的活动 的对象,而其它 EJB 则可能在每次方法调用后将对象清除。一 些 EJB 服务器可能使用最近最少使用的 (LRU) 策略来当资源变 得紧时清除对象。不论使用何种策略,每个EJB 服务器都必须为稳 态的对象进行状态管理。

有状态的会话 Bean

会话 bean 代表单个客户正在进行的工作。有时,整个工作完 全可在一个方法调用内完成。另一些时候,一个工作必须分为多 个方法请求。如果工作分为多个方法,对象必须在方法调用之间 保持用户对象的状态。例如,在一电子商务应用中, CheckCreditAuthorization 方法在整个执行过程中不要求保持 状态。而另一方面,ShoppingCart 对象在顾客购物前必须记住 顾客浏览时选中的所有商品。会话 bean 的状态管理选项定义 在实施描述对象的 StateManagementType 属性里。所有的实体 bean 天生是有状态的。

自动状态管理

如果对象是无状态的,容器在每次方法调用后自动地恢复对象实 例的状态。如果对象是有状态的,容器在会话对象被清除前自动 地维护对象的会话状态,尽管对象有可能临时被从内存中清出。 企业 JavaBeans 体系结构提供了允许开发人员无论对象被装入 或清出内存时进行特定操作的简单编程模型。企业 JavaBeans 模型在每个企业 bean 的类的 ejbLoad,ejbStore,ejbActivate, 和 ejbPassivate 方法中分离了这些功能。

有状态和无状态的服务器的对比

无状态的服务器比有状态的服务器使用更少的资源并且更容易回 收。由于无状态的对象类实例是相同的,实例能被缓存并不断 重用。因此,许多事务处理专家断言无状态的服务器有更好的伸 缩性且更适合于大容量事务处理系统。但是如果应用需求扩展的 多方法会话,使用有状态的服务器可能更为有效。

坚持 管理

坚持的对象

实体 bean 代表稳态数据。实体对象存在一段时间并可被许多客 户所使用。

坚持编程模型

企业 JavaBeans 技术为稳态对象的管理提供了一个简单的程序 设计模型。无论何时只要对象被创造或清除了,或者对象被调入 或清出内存,稳态函数都必须被执行。企业 JavaBeans 模型在 每个企业 bean 的类的 ejbCreate, ejbDestroy, ejbLoad, ejbStore, ejbActivate, 和 ejbPassivate 方法中分离了这些 函数。

实体对象坚持

实体对象能管理它的自己的稳态,或者委托它的容器管理它的稳 态。实体 bean 的稳态选项定义在实施描述对象的 ContainerManagedFields 属性里。

Bean 管理的坚持

如果实体对象管理它的自己的稳态,企业 bean 开发者必须直接 在企业 Bean的类方法中实现稳态操作 (例如 JDBC 或嵌入的 SQL 调用)。

容器管理的坚持

如果实体对象代理保留服务, EJB 容器透明地及暗含地管理稳 态。企业 bean 开发者不需要在企业 bean 的类方法内写任何 实现数据库访问功能的代码。企业 JavaBeans 规范第一版未 定义 EJB 容器必须如何管理对象的稳态。供应商可以在 EJB 容器中实现简单的保留服务。方法是简单地把企业 bean 的 状态序列化并储存在保留的对象中。或者供应商可以实现更复 杂的保留服务,例如,透明地将对象的一些保留字段映射到一个 关系数据库的各列中。供应商也可以通过使用嵌入的对象数据 库来实现保留服务。

会话对象坚持

根据定义,会话对象非稳态,但它们可能也有些信息需要保留。 就如 bean 管理的实体对象,会话对象也能用企业 bean 中的 方法直接实现保留操作。当事务处理启动, 委托或者取消时,会 话对象常常维持这一个必须与数据库同步的数据库信息的缓存。 企业 bean 开发者可以使用可选的 SessionSynchronization 接口在企业 bean 的类中直接实现同步事务处理的方法。 afterBegin ,beforeCompletion ,和 afterCompletion 通知显示 事务分界 , 允许对象在需要时向数据库读或写数据 。

事务处理管理

分布式事务处理

尽管企业 JavaBeans 技术显然能用来实现非事务处理系统,该模 型的设计就是支持分布式的事务处理的。企业 JavaBeans 要求使 用支持扁平的事务处理的两阶段执行协议的分布式事件处理管理 系统。

JTS

企业 JavaBeans 规范建议但并不要求基于 Java 事务处理服 务(JTS) API 的事务处理。JTS 是CORBA 对象事务处理服务(OTS) 的 Java 绑定 。JTS 支持分布式事务处理,它能跨多个系统由 多重的事务处理管理器协调的多样的数据库。使用 JTS,一个企 业 JavaBeans 服务器与另外的企业 JavaBeans 服务器就可以确 保它们在事务处理上等互操作。

JTA

企业 JavaBeans 应用使用 Java 事务处理 API (JTA) 与事务处 理服务通信。JTA 提供启动事务,加入现有的事务,执行事务处 理和恢复事务的编程接口。

简明性

虽然在集中式的应用中事务分界很直接,但是当应用包含很多彼 此互相调用的自主应用组件时,就很困难了。企业 JavaBeans 技术通过自动使用分布事务处理极大地简化了应用开发。所有的 事务处理功能都可由 EJB 容器和 EJB 服务器隐含地完成。单个 的企业 bean 不必在他们的代码以内实施任何事务处理划界语 句。因为在应用程序逻辑以内没有事务处理代码的要求,企业 bean 更简单易写并且是可跨不同的事务处理管理器移植的。

说明性的事务处理规则

事务处理的语义是声明式定义而非程序式定义的。在运行时, EJB 容器根据实施描述对象中所说明的 TransactionAttribute 属性自动地实施事务处理服务。

事务处理属性

企业 JavaBeans 模型支持六种不同的事务处理规则:

  • TX_BEAN_MANAGED. TX_BEAN_MANAGED 属性表示 企业 bean 手工地管理它的自己的事务处理控制。EJB 通过 Java 事务处理 API 支持手工事务处理分界。
  • TX_NOT_SUPPORTED. TX_NOT_SUPPORTED 属性显示企 业bean 不能在一事务处理的上下文以内执行。如果当客 户端(无论是一方法或一远程客户或另一企业 bean) 调用企业 bean 时,其正在进行一个事务处理,事务 处理服务器则会在方法调用期间推迟事务处理。
  • TX_SUPPORTS. TX_SUPPORTS 属性显示企业 bean 无论有 无事务处理的上下文都能运行。如果当客户调用企业 bean 时,其正在进行事务处理,则该方法调用将加入客 户的事务处理的上下文。如果客户端未进行事务处理, 方法调用将在无事务处理的情况下运行。
  • TX_REQUIRED. TX_REQUIRED 属性显示企业 bean 必 须在事务处理的上下文以内执行。如果当客户端调用企 业 bean 时,其正在进行事务处理,则该方法将加入 客户的事务处理的上下文。如果客户端未进行事务处理, 容器将自动地为方法调用创建一次新的事务处理。
  • TX_REQUIRES_NEW. TX_REQUIRES_NEW 属性显示企业 bean 必须在一新建的事务处理的上下文以内执行。容器 总是为方法的调用开始一新建的事务处理。如果当客户 端调用企业 bean 时,有一个事务处理正在进行,容器 将在方法调用期间暂停该事务处理。
  • TX_MANDATORY. TX_MANDATORY属性显示企业 bean 必须总是在客户的事务处理的上下文以内执行。如果当 客户端调用企业 bean 时,并没有一个事务处理,容器将 抛出 TransactionRequired 的例外和请求失败的信息。

安全性

Java 安全性

企业 JavaBeans 模型使用 Java 开发工具包(JDK 1.1.x) 支持的 Java 安全性服务。Java 平台安全性支持确认和授权服务以限制 对象和方法的访问权限从而保障安全。

企业 JavaBeans 安全

企业 JavaBeans 技术自动化了 Java 平台安全性的使用,因此 企业 bean 不需要直接为 Java 安全性编写代码程序。每个企业 bean 的安全性规则是在实施描述对象里的一组 AccessControlEntry 对象中声明式地进行定义的。 AccessControlEntry 对象把方法与有权调用它的用户相关联。 EJB 容器自动使用AccessControlEntry 对象为企业 bean 执行 所有的安全性检查。

企业 JavaBeans 实施

包装

企业 JavaBeans 组件能作为单个的企业 bean,作为许多企业 bean 的集合,或作为一完整的应用系统进行打包。企业 JavaBeans 被放置在称为 ejb-jar 文件的一个Java文件中分发。 ejb-jar 文件包含一个描述该文件的内容的声明文件, 还有企业 bean 的类文件,实施描述对象, 以及可选的环境属性文件。

实施描述

DeploymentDescriptor 对象用来为企业 bean 建立运行时刻的 服务设置。这些设置告诉EJB 容器怎么管理和控制该企业 Bean。 设置在应用程序组装或应用程序实施时进行。

DeploymentDescriptor 对象指定如何创建和维护企业 bean 对 象。这些对象调用了企业bean 类名,代表容器的JNDI 命名空 间, Home 接口名,REemote 接口名和环境属性对象名,等等。 DeploymentDescriptor 对象包含一 ControlDescriptor 对 象数组,它描述作用在企业 bean上的事务处理语义;和一 AccessControlEntry 对象数组,它描述作用在企业 bean 上的 安全规则。

会话 bean 和实体 bean 有微小的不同要求,因此,有两种不同 的实施描述:

  • SessionDescriptor 对象 扩展 DeploymentDescriptor 对 象并增加表明会话 bean 有无状态的属性 。
  • EntityDescriptor 对象扩展 DeploymentDescriptor 对象 并增加表明对象中的那些域应自动地由容器存储的属性 。

环境属性

企业 bean 的开发者能提供一套环境属性来允许应用程序的开发 者对这些 bean 进行定制以满足应用程序的需要。例如,一个属 性可能被用来指定数据库的位置或指定一种默认语言。

工业支持

巨大的认同

工业界为企业 JavaBeans 技术首创作出了很多支持。大多数主要 供应商包括 IBM,Oracle,Sybase,网景,和 BEA Systems 参与 了企业 JavaBeans 规范定义。这些供应商计划在他们的产品中加 入对企业JavaBeans 的支持。

EJB 服务器

第一个EJB 兼容应用程序服务器出现在1998年八月。本文写作时 正发布或处于 Beta 版的产品有:

  • BEA WebLogic Tengah
  • Bluestone Sapphire/Web
  • GemStone GemStone/J
  • IBM WebSphere Advanced Edition
  • Novera jBusiness
  • Oracle8i
  • Oracle 应用程序服务器
  • OrchidSoft Vanda
  • Persistence PowerTier
  • Progress Apptivity
  • Secant Extreme
  • Valto Ejipt

1999 年初将会有更多的EJB 兼容应用程序服务器出现,例如 Forte,Fujitsu, Haht, Inprise, Informix, Netscape, Sun, Sybase, 和 Vision。

应用程序供应商

应用程序软件供应商也对企业 JavaBeans 表示支持。该模型增加 了一体化应用程序解决方案的通用性。使用企业 JavaBeans 组件 实现的应用能在更广泛的系统上使用。另外,他们对现有的应用程 序系统支持更容易,更容易定制和整合。以下公司已有的或正在 开发的 EJB 兼容的应用和组件有:

  • Athena Design Integer (一个复合的速算表)
  • Digital Harbor 个人生产率应用组件
  • EC-Cubed 电子商务组件
  • IBI EDA 组件 (提供主机数据和应用的集成)
  • IBM San Francisco 框架 (总帐,定单管理等。)
  • NovaSoft Novation (一电子文档管理系统)
  • Oracle 应用程序 (ERP )
  • Seven Mountains 个人生产率应用组件
  • TradeEx procurement 组件

EJB 比赛

Microsoft 的抵抗

对企业 JavaBeans 技术的主要的阻力是来自 Microsoft。 虽然 Microsoft 事务处理服务器 (MTS) 能经过改编支持 企业 JavaBeans,Microsoft 却看来不会作出这种努力。 Java 可移植性的思想将渐渐破坏 Microsoft 的紧密依赖 NT 平台的构想。Microsoft 想把开发者推到开发基于 COM 构件模型的构件应用程序系统的道路上。MTS 为 COM 服务 器构件提供一个容器系统, 提供类似企业 JavaBeans 服务 器所提供的事务性和安全性的服务。下一代的MTS,COM+, 将提供诸如动态负载平衡和队列请求处理等附加的能力。

MTS 的限制

尽管COM 构件具有与企业 JavaBeans 相同的一些优点,但它们有 一些显著的不同。

  • 平台限制。COM 构件依托于一个 COM 运行系统和 DCOM 通信协议。虽然 COM 和 DCOM 最近移植到了 Solaris 及其他的 Unix 平台上,但 COM 容器系统在这些平台上 无法使用。COM 服务器构件事实上仅仅能在 Windows 95 或 NT 上使用。企业 JavaBeans 构件与平台无关。
  • 供应商限制。很少有供应商为COM 和DCOM 构件提供容器 系统。当前, COM 容器仅仅有两家供应商提供: Microsoft 和 Sybase。COM 模型没有扩展到足以支持这两种不同环境 之间的互操作性和透明的可移植性。任何数量的容器系统 都能经过改编从而支持企业 JavaBeans 组件。许多供应商 宣布了他们支持该模型的意愿,包括 IBM,BEA,Oracle, Sybase 以及网景。企业 JavaBeans 模型确保了跨越这些 环境时的互操作性和可移植性 。
  • 客户限制。COM 和 DCOM 服务是通常在非 Windows 客户 端上无法使用,例如网络计算机,信息器具,或智能卡。 企业 JavaBeans 能支持任何基于 Internet 的客户设备 。
  • 有限的状态和稳态管理。 MTS 不支持区分暂态和稳态对 象。所有的 MTS 组件等同于无状态的会话对象。MTS 在事 务处理后自动清除所有的对象状态,开发人员负责管理所 有会话状态。MTS 不支持自动稳态对象。 开发人员负责管 理所有稳态数据。企业 JavaBeans 支持有状态和无状态的 临时和稳态的对象。
  • 更严格的处理管理限制。尽管 MTS 支持说明性的事务管 理,COM 构件仍然需要在应用逻辑部分编写一些事务处理 划界代码。 即使这样,MTS 应用并不具备覆盖自动 MTS 事务处理服务的灵活性。企业 JavaBeans 技术在应用程序 逻辑以内不要求事务处理划界代码,但是,开发人员也可 以选择使企业 bean 完全控制它的事务处理行为。

好处和结论

组件可移植性

企业 JavaBeans 体系结构提供一简单并且漂亮的服务器组件 容器模型。该模型确保 Java 服务器组件能够一经开发就能应 用在任何地方,任何供应商的容器系统内。尽管容器系统实现 他们的运行服务的方法不同,企业 JavaBeans 的接口确保企 业 bean 能依靠基础系统提供一致的生存期,稳态,事务处 理,分布和安全性服务。

体系结构独立

企业 JavaBeans 体系结构完全独立于任何专有的平台、协议或 中间件基础结构。在一个平台上开发的应用程序能被拣起、移动 或重新部署到其它的平台上。EJB 应用能不须任何改动适应从小 规模的、基于 Intel 的单处理器的 Novell 环境到大规模多处 理器的 UltraSPARC 环境到超大规模的 Sysplex IBM 主机环境。

开发者生产率

企业 JavaBeans 体系结构提高了应用开发人员的生产率。企业 JavaBeans 境自动化了复杂的基础服务的使用,例如事务处理, 线程管理和安全性检查。组件开发者和应用构造者毋须在应用 编程逻辑里实现复杂的基础服务。

高度可定制

企业 JavaBeans 应用是高度可定制的。基础的 JavaBeans 构件 模型支持定制,并且不要求访问源代码。应用程序行为和运行时 刻设定可以通过实施时修改一套属性列表进行设置。

兼收并蓄

企业 JavaBeans 体系结构是一个极具兼容性的不断进化的环境。 企业 Java 服务层在现有的基础服务之上。组织无须实现另一套 不兼容的中间件技术。企业 JavaBeans 技术增强了、体现了并 简化了流行的系统,例如 CORBA 和 DCOM。

通用性和可伸缩性

企业 JavaBeans 模型基于一个极其通用并且功能强大的多层分布 式对象体系结构,它依靠的是业界标准协议。这种模型既适用于小 规模应用又适用于大规模的商业事务处理。当对应用程序提出更 高的要求时, 应用能被移植到更强大的操作环境。这种环境内在 地支持基于 Web 的应用和许多其他接入 Internet 客户设备。附 加的客户系统能够于任何时候,在不修改任何核心应用程序系统 的情况下进行扩充。企业 JavaBeans 提供一个与业界同步成长的 环境。它能够在新技术出现时随时对它们提供支持。