（控制理论与控制工程专业论文）集成ejb和uml的分布式应用开发.pdf

口.1 摘要 ab s t r a c t wi t h t h e r a p i d d e v e l o p m e n t a n d w i d e a p p l i c a t i o n o f t h e c o m p u t e r n e t w o r k t e c h n o l o g i e s , t h e d i s t r i b u t e d o b j e c t t e c h n o l o g y h a s b e c o m e t h e m o s t i m p o rt a n t t e c h n o l o g y i n c o n s t r u c t i n g t h e fr a m e w o r k o f a p p l i c a t i o n s f o r e n t e r p r i s e s e r v i c e s as w e l l as i n s o ft w a r e c o m p o n e n t w h i c h s h o w s s t r o n g v i t a l i ty i n t h e d e v e lo p m e n t o f l a r g e - s c a l e d i s t r ib u t e d a p p l i c a t i o n s y s t e m . t h e t e c h n o l o g y o f e n t e r p r i s e j a v a b e a n s ( e j b ) , a s t a n d a r d i z e d , d i s t r i b u t e d a n d o o - b as e d c o m p o n e n t s t r u c t u r e , h a s b e c o m e t h e d e v e l o p m e n t p l a t f o r m a n d s u p p o r t i n g f r a m e w o r k i n t h e d i s t r i b u t e d a p p l i c a t i o n s y s t e m f o r it s o u t s t a n d in g f e a t u r e s o f t r a m s - p l a t f o r m a n d i n t e r - o p e r a t i o n . t h i s t e c h n o l o g y h a s b e e n w i d e l y u s e d i n e n t e r p r i s e a p p l i c a t i o n . h o w e v e r , h o w w i l l t h e o b j e c t m o d e l c o n s t r u c t i o n t e c h n o l o g y b e a p p l i e d t o t h e d e v e l o p m e n t o f t h e d i s t ri b u t e d o b j e c t t e c h n o l o g y a n d h o w w i l l t h e f i v e w o r k fl o w s , t h a t i s , r e q u i r e , a n a l y s i s , d e s i g n , r e a l i z a t io n a n d t e s t , b e o r g a n i c a l l y a n d s e a m l e s s l y i n t e g r a t e d i n t h e d e v e l o p m e n t o f t h e d i s t r i b u t e d o b j e c t s y s t e m , t h e s e p r o b l e m s a r e w h a t w e w i l l d i s c u s i n t h i s a rt i c l e . f i r s t l y , t h i s a r t i c l e g i v e s a b r i e f i n t r o d u c t i o n o f t h e m a i n p r o b l e m s c o n f r o n t e d b y e n t e r p r i s e s i n t h e i r a p p l i c a t i o n s a n d t h e o u t l i n e s o f t h e d i s t ri b u t e d o b j e c t t e c h n o l o g y . t h e n , a ft e r m a k i n g a d e e p r e s e a r c h i n t o t h e e j b s y s t e m s t r u c t u r e a n d t e c h n o l o g y s t a n d a r d s as w e l l as t h e u ml o b j e c t m o d e l c o n s t r u c t i o n t e c h n o l o g y a n d t h e p r o c e s s o f u n i f i e d d e v e l o p m e n t ( r u p ) , w e p u t f o r w a r d a m e t h o d o f i n t e g r a t e d d e v e l o p m e n t w h i c h i s b as e d o n t h e t e c h n o l o g i e s o f u ml a n d e j b a n d f e a t u r e s b y d i s t r i b u t e d a p p l i c a t i o n . t h i s m e t h o d i s c h a r a c t e r i z e d b y l i g h t w e i g h t , i n t e r a t i o n a n d i n c r e m e n t ， w h i c h c a n b e u s e d t o d e v e l o p m e n t t h e o p e n i n g , r e a p p l i c a t i o n a n d e x p a n s i b l e d i s t r i b u t e d o b j e c t s y s t e m fl e x i b l y a n d q u i c k l y . f u rt h e r m o r e , w e e x p o u n d t h i s m e t h o d b y g i v i n g a n e x a m p l e o f t h e d e v e l o p m e n t o f t h e“f i c t i t i o u s s t o c k e x c h a n g e s y s t e m , w h i c h s u c c e s s f u l l y t e s t s a n d v e r i f i e s i t s f e a s i b i l i ty a n d e ff e c t i v e n e s s f i n a l ly , w e m a k e a s u m m a ry o f t h e w h o l e a r t i c l e a n d d i s c u s t h e f u t u r e d e v e l o p m e n t o f t h e d i s t r i b u t e d o b j e c t s y s t e m. k e y wo r d s : e j b u ml r u p d e s i g n p a t t e r n d e v e l o p m e n t p r o c e s s mo d e l 第一章 绪论 第一章 绪论 前不久，著名的咨询公司麦肯锡曾提出一个令业界哗然的报告，在这份题 为 i t a n d p r o d u c t i v i t y ) ( i t与生产力) 的 报告中， 似是而非却又非常明 确地传 达了 这样一个令人吃惊的结论: 在绝大部分经济领域中， 对i t方面的大幅投资 没有起到任何帮助生产力增长的作用。然而与之相矛盾的是，在麦肯锡的网站 和其他文章中，却是大量以电子商务、新经济为核心的咨询业务介绍。并且在 显要的部分表示: 麦肯锡通过研究发现， 浸泡在信息与数据海洋中的现代企业， 其成功与否的重要分水岭，就是对以网络为代表的信息技术的应用和把握。我 们不管麦肯锡的目的是什么，但这些看起来格格不入的观点至少传达出两个方 面的含义: 一、没有人能够否认网络的巨大力量，即使是站在怀疑者的立场上，也不 得不面对网络咄咄逼人的锋芒. 二、驾驭网络是一项艰巨的任务，它绝不是简单的投资与采购。如果没有 正确的应用，企业在花费了大量的金钱之后，往往看不到任何回报。 网络是今天最强大、最自由、也是最具推动性的力量。它是技术革命积累 到一定程度的自 然质变，也是商业社会迈向下一个辉煌的必由之路。网络改变 了原来的商业秩序，尤其是在项目 实施和价值创造方式方面影响深远。正如经 济学家m a l o n e y 所说: “ 所有的 混乱只证明了 一件事 网 络正在以 它的力量改 变这一切。 ” 而我们真正应该关注的是， 究竟怎样才能成功地驾驭网络， 快速且 高质量地开发出满足不同需求的软件? ， . ， 企业应用系统的特点 ， . ， . ， 支持异构分布式环境 在企业级应用中，企业基于性能、价格、服务等方面的考虑，通常在同一 系统中集成来自 不同厂商的硬件设备、 操作系统、数据库平台和网络协议。异 构的环境在以下情况也可能出现:要完成多个不同项目的机构;对拥有不同部 署环境的公司进行合并、收购。在以上情形中，跨异构系统的可移植性与互操 作性是非常重要的。 第一章 绪论 ， . ， .2可伸缩性 在信息技术领域，这个词的意思是，在系统规模扩大时，使相应的额外开 销 ( 包括硬件、关机时间及系统管理工作) 增幅小于系统规模的增幅，而不是 等于或大于系统规模增幅的这样一种能力。 公司必须要选择一种服务器端平台， 这种平台应能提供极佳的可伸缩性去满足那些在他们系统上进行商业运作的大 批新客户。 1 . 1 . 3可用性 指系统在预期的长时间内可以进行的持续性操作，从而保证和提高企业应 用系统的 运行性能和可靠性。对于成功的企业应用系统来说，高可用性是一个 重要的特征。 1 . 1 .4保护现有的投资 由 于公司必须适应新的商业需求，利用已 有的企业信息系统方面的投资， 而不是重新制定全盘方案就变得很重要。 这样， 一个以渐进的 ( 而不是激进的 全盘否定的)方式建立在已 有系统之上的服务器端平台机制是公司所需求的。 1 . 2 分布式对象技术概述 1 . 2 . ，分布式对象产生的背景 分布对象技术 是计算机网络技术和面向对象技术相互协调、 相互促进而发 展起来的。以前的计算机系统多是单机系统，多个用户是通过联机终端来访问 的，没有网络的概念。网络出现后，产生了c l i e n t / s e r v e : 的计算服务模式，多 个客户端可以共享数据库服务器和打印服务器等等。 随着网络的更进一步发展， 许多软件需要在不同厂家的网络产品、 硬件平台、 网络协议等异构环境下运行， 应用的规模也从局域网发展到广域网。 在这种情况下， c l ie n t/ s e r v e r 模式的局限 性也就暴露出来了，于是中间件应运而生。中间件是位于操作系统和应用软件 之间的通用服务，它的主要作用是用来屏蔽网络硬件平台的差异性和操作系统 与网络协议的异构性，使应用软件能够比较平滑地运行于不同平台上。同时中 间件在负载平衡、连接管理和调度方面起了很大的作用，使企业级应用的性能 第一章 绪论 得到大幅提升，满足了关键业务的需求。但是在这个阶段，客户端是请求服务 的，服务器端是提供服务的，它们的关系是不对称的。随着面向对象技术的进 一步发展，出 现了分布式对象技术。可以这么说，分布式对象技术是随着网络 和面向 对象技术的发展而不断地完善起来的。 9 0 年代初c o r b a 1 . 0 标准的颁布， 揭开了分布式对象计算的序幕。 分布对象计算中，通常参与计算的计算体 ( 分布对象)是对称的。分布对 象往往又被称为组件 ( c o m p o n e n t ) ，组件是一些独立的代码的 封装体，在分布 计算的 环境下可以 是一个简单的 对象， 但大多数情况下是一组相关的对象复合 体，提供一定的服务。分布环境下，组件是一些灵敏的软件模块，它们可以位 置透明、语言独立和平台独立地互相发送消息，实现请求服务。 1 .2 . 2 分布式对象模型与标准 分布式对象技术采用面向对象的多层次 c p s的计算模型，该模型将分布在 网络上的全部资源 ( 无论是系统层还是应用层)都按对象的概念来组织，每个 对象都有明确定义的访问接口。 创建和维护分布对象实体的应用称为服务器( 或 者为容器) ， 按照接口 访问该对象的应用为客户。 服务器中的对象不仅能够被访 问，而且自 身也能作为其它对象的客户。因此，在分布式对象技术中，客户与 服务器的角色的划分是相对和多层次的。支持客户访问异地分布对象的核心机 制称为对象请求代理 ( o r b ) , o r b 处于分布式对象技术的核心位置。 这里的o r b 如同一条软件总线把分布式系统中的各类对象和应用连接成相互作用的整体。 目 前分布式对象技术已 经成为建立应用框架和软构件的核心技术，其中有三种 具有代表性的主流技术，它们是: 1 . 2 . 3 . 1 公共对象请求代理体系结构c o r b a 是对象管理组o m g ( o b j e c t m a n a g e m e n t g r o u p )设计的一个标准 c o b r a 标准主要分为3 个层次: 对象请求代理、公共对象服务和公共设施。最 底层是对象请求代理 o r b ，规定了分布对象的定义 ( 接口)和语言映射，实现 对象间的通讯和互操作， 是分布对象系统中的“ 软总线” ; 在o r b 之上定义了很 多公共服务，可以提供诸如并发服务、名字服务、事务服务、安全服务等各种 各样的服务;最上层的公共设施则定义了组件框架，提供可直接为业务对象使 用的服务，规定业务对象有效协作所需的协定规则。总之，c o r b a的特点是大 而全， 互操作性和开放性非常好。目 前c o r b a 的最新版本是2 . 5 . c o r b a 3 . 0 也 已 基本完成， 增加了有关工 n t e r n e t 集成和q o s 控制等内 容。 c o r b a 的缺点是庞 大而复杂，并且技术和标准的更新相对较慢，c o b r a规范从 1 . 0 升级到2 . 0所 花的时间非常短，而再往上的版本的发布就相对十分缓慢了。 第一章 绪论 1 . 2 . 3 . 2分布构件对象模型d c o m d c o m 是c o m 体系结构的网 络分布式扩展， 它通过运行。 r p c ( o b j e c t r e m o t e p r o c e d u r e c a l l ) 协议来支持远程对象。c o m 最初作为m i c r o s o f t 桌面系统的构 件技术， 主要为本地的o l e 应用服务， 但是随着m i c r o s o f t 服务器操作系统n t 和d c o m 的发布， c o m 通过底层的远程支持使得构件技术延伸到了分布应用领域。 d c o m / c o m / c o m + 更将其扩充为面向服务器端分布应用的业务逻辑中间件。通过 c o m + 的相关服务设施，如负载均衡、内 存数据库、对象池、构件管理与配置等 等， d c o m / c o m / c o m + 将c o m , d c o m , m t s 的 功能 有机地统一在一 起， 形成了 一 个 概念、功能强的构件应用体系结构。 m i c r o s o f t 的d c o m 平台效率比较高，同时 它有一系列相应的开发工具支持，应用开发相对简单。但它有一个致命的弱点 就是d c o m 的跨平台性较差， 如何实现与第三方厂商的互操作性始终是它的一大 问题。 1 . 2 . 3 . 3 j 2 e e 标准 为了 推动基于j a v a 的 服务器端应用开发， s u n 于是在1 9 9 9 年底推出了j a v a 2 技术及相关的j 2 e e 规范。j 2 e e 的目 标是: 提供平台无关的、可移植的、支持 并发访问 和安全的， 完全基于j a v a 的开发服务器端中间件的 标准。 在j 2 e e 中， s u n 给出了完整的基于j a v a 语言开发面向企业分布应用规范。 其中在分布式互 操作协议上， j 2 e e 同时支持r m i 和工 i o p ， 而在服务器端分布式应用的构造形式， 则包括了j a v a s e r v l e t , j s p ( j a v a s e r v e r p a g e ) , e j b 等多种形式，以 支持不 同 的 业 务 需 求， 而 且j a v a 应 用 程 序 具 有“ w r i t e o n c e , r u n a n y w h e r e ” 的 特 性， 使得 j 2 e e技术在分布计算领域得到 t 快速发展。e j b 是 s u n推出的基于j a v a 的服务器端构件规范j 2 e e 的一部分，自 从j 2 e e 推出之后， 得到了广泛的发展， 己经成为应用服务器端的标准技术。e j b 技术是在j a v a b e a n 本地构件基础上， 发展的面向 服务器端分布应用构件技术。它基于 j a v a 语言，提供了基于j a v a 二进制字节代码的重用方式。e j b给出了系统的服务器端分布构件规范，这包 括了构件、构件容器的接口规范以及构件打包、构件配置等的标准规范内容。 e j b 技术的推出， 使得用j a v a 基于构件方法开发服务器端分布式应用成为可能。 从企业应用多层结构的角度，e j b是业务逻辑层的中间件技术，与 j a v a b e a n s 不同，它提供了事务处理的能力。自 从三层结构提出以后，中间层也就是业务 逻辑层，是处理事务的核心，从数据存储层分离取代了存储层的大部分地位。 从分布式计算的角度，e j b像 c o r b a一样，提供了分布式技术的基础一对象之 间的通讯手段。 第一章 绪论 1 . 3 基于分布式对象的软件开发 在面向对象技术给解决软件危机带来曙光之时，分布式网络计算的巨大压 力又给软件开发提出了许多新的难题，使软件开发仍处于高风险状态。 新的分 布式网络计算要求软件实现跨空间、跨时间、跨设备、跨用户的共享，导致软 件在规模、复杂度、功能上的极大增长，迫使软件要向异构协同工作、 各层次 上集成、可反复重用的工业化道路上前进。为适应软件的这种需求，新的软件 开发模式必须支持分布式计算、浏览器/ 服务器结构、 模块化和组件化集成， 使 软件类似于硬件一样，可用不同的标准组件拼装而成。具体地说可实现下列几 点要求: i 提供一种手段， 使应用软件可用预先编好的、 功能明确的产品部件定制而成， 并可用不同版本的部件实现应用的扩展和更新。 2 )利用模块化方法， 将复杂的难以维护的系统分解为互相独立、 协同工作的部 件，并努力使这些部件可反复重用。 3 )突破时间、 空间及不同硬件设备的限制， 利用客户和软件之间统一的接口实 现跨平台的互操作。 综上所述， 企业应用系统的开发一直面临着重大挑战: 一方面， 企业应用系 统面对的是一个异构的分布式环境，它必须支持与己有系统的集成性和与其他 系统的互操作性:另一方面，作为为客户、合作伙伴和企业内部提供信息服务 的 平台， 企业系统还必须具有高可用性、安全性、可靠性和可伸缩性。这些要 求再加上复杂多变的用户需求和不断伸缩的交付时间，使得企业系统的开发越 来越困难。开发商和广大程序员一直在努力推动和殷切期待一个成熟、标准的 企业平台来简化和规范企业系统的开发和部署。而分布式对象技术的出 现，尤 其是j 2 e e 平台的推出正是这种努力的结果， 也使得企业系统的开发由 此变得更 加快速和方便。而如何应用分布式对象技术来开发企业应用系统正是本文所要 研究的问题。本文将首先介绍e j b 技术，接下来研究面向对象的建模技术，并 提出了一种针对企业分布式应用系统的开发方法， 最后以“ 证券委托交易系统” 为例，说明了该方法的具体应用。 第二章 e n t e r p r i s e j a v a b e a n s 技术 第二章 e n t e r p r i s e j a v a b e a n s 技术 今天，对企业开发人员来讲， 难以编写分布式商务应用程序和其它任何较大 的 应用程序是他们所面临着一个共同问 题。 如果一个应用程序是分布式的， 或在 网 络中以 多重形式出 现， 那它必然应该是一个综合化的 产物。 如果一个应用程序 必须可靠而有保证地执行它的商务逻辑， 那么其综合化程度又必然需要进一步 提高。 企业所面临的另一个复杂问题是企业自身的基本操作环境也是多种多样 的。另外，企业希望能以尽可能快的速度建立自己的应用程序，而不是被限制 在单一的平台上。 理想的情况是， 企业开发人员只编写一次应用程序， 而该程序 即可在任意平台上运行。 而 e n t e r p r i s e j a v a b e a n s ( e j b ) 技术是解决上述问题的一个极佳选择。e j b 组件结构是以作为可重复使用的服务器端组件而设计的，它使企业能够建立可 升级、安全可靠、可运行于多重平台且以商务为重点的应用程序。 2 . 1 什么是企业j a v a b e a n s 技术? e j b 从技术上而言不是一种产品， 而是j a v a 服务器端服务框架的技术规范s o 设计e j b 结构的目 的是， 通过使企业开发人员 将注意力只集中 于编写商务逻辑， 从而解决上面所提出的问题。 2 . 1 . 1 e j b架构的设计目 标s e j b规范的第一版以初稿形式于1 9 9 7 年 1 2 月公布，并于1 9 9 8 年3 月作为 1 . 0 版发行。规范作者为叮b 体系结构制定了以下目 标: e n t e r p r i s e j a v a b e a n s 体 系结 构 将 是 标 准的 组 件体 系结 构， 用于以j a v a 编程语言构建分布式的面向对象的商务应用程序。通过把使用不同供应 商提供的 工具开发出来的 组件组合在一起， e n t e r p r i s e j a v a b e a n s 体系 结构将有可能构建分布式的应用程序。 e n t e r p r i s e j a v a b e a n s 体系结构将使编写应用程序变得容易:应用程序 开发人员将不必了解低层次的事务和状态管理的细节、多线程、资源共 享和其他复杂的低级 a p i 。但是，将允许专家级的程序员直接访问低级 a p i . 第二章e n t e rp r i s e j a v a b e a n s 技术 e n t e r p r i s e j a v a b e a n s 应 用 程 序 将 遵 循 j a v a 编 程 语言 的“ 一 次 编 写， 随处运行”的原则。 e j b 组件可以只开发一次，然后在多个平台上部署， 而不需要重新编译或修改源代码。 e n t e r p r i s e j a v a b e a n s体系结构将处理企业应用程序生命周期中的开 发、部署和运行等方面。 e n t e r p r i s e j a v a b e a n s 体 系结 构 将定 义 一 些约 定， 这 些 约 定 使多 个 供 应 商提供的工具能够开发并部署可在运行时互操作的组件。 e n t e r p r i s e j a v a b e a n s 体 系结 构将与 现有的 服务 器 平台 兼 容。 供 应商 将 能够扩展它们的现有产品，以支持 e n t e r p r i s e j a v a b e a n s组件。 e n t e r p r i s e j a v a b e a n s 体系结构将与 j a v a 编程语言编写的其他 a p i 兼 容。 e n t e r p r i s e j a v a b e a n s体系结构 将提供 e j b组件和非 j a v a编 程语言 应用程序之间的互操作性。 e n t e r p r i s e j a v a b e a n s体系结构将与 c o r b a兼容。 2 . 1 . 2 使用e j b技术的好处 这些设计目 标会使企业和开发人员得到什么好处呢?下面列出了可望从采 用 e n t e r p r i s e j a v a b e a n s环境获得的好处: e j b 组件使编写应用程序更为简单。尽管 e j b体系结构复杂，但应用程 序开发人员一般都不必再编写用于访问 系统服务的代码。 一种称为 e j b 容器的系统组件使系统服务可用于 e j b组件的任务。 服务器端商务逻辑可以移植。除了j a v a 语言固有的可移植性外， e j b 体 系结构还在b e a n 和支持该b e a n 的容器之间提供了一套标准化的应用程 序编程接口。 这使开发人员能够将b e a n 从一种操作环境移植到另一种操 作环境，而无须重新编写其源代码。 可以从现有的软件组件装配出服务器端应用程序，这与从现有的 j a v a b e a n 可以装配出客户端应用程序一样，从而使软件能够重用。 e j b体系结构内 置了对典型企业级系统服务的支持，包括分布式对象、 事务处理、数据库、安全和全局命名。 多家 i t 供应商都采纳 e j b体系结构，这是由于有这样的承诺:客户将 第二章 e n t e r p r i s e j a v a b e a n s 技术 能够从选定的供应商那里选购软件组件，如e j b 组件、容器及e j b 服务 器; 也由于承诺了不同 供应商的产品， 只要符合 e j b 体系结构， 就都是 可互操作的。 用e j b组件构建的应用程序可以从一个服务器移植到另一个服务器，从 而支持可伸缩性，这是因为在e j b 模型中，各个软件组件都是严格分离 的。 e j b 体系结构能保障原有的i t 投资， 这是通过允许将现有的信息系统和 资产 “ 包裹”在这些应用程序中， 而不要求客户更换现有技术。 事实上， 在关系数据库中存储数据的企业己经有了一套己 有雏形的实体b e a n ， 正 等着通过e j b 外壳去访问。 2 . 2 e n t e r p r i s e j a v a b e a n s 休系结构 为了 满足架构的目 标， 规范中 描述了 服务器、 容器、 企业b e a 。 类、 h o m 。 和 r e m o t e 接口、客户端。图2 . 1 是e n t e r p r i s e j a v a b e a n s 体系结构的一个描述。 图2 . 1 e j b体系结构 2 . 2 . 1 e j b服务器 e j b服务器作为容器和底层平台的桥梁管理着 e j b容器和函数 。它向e j b 容器提供了访问系统服务的能力。例如:数据库的管理和事务的管理，或者对 于其它的e n t e r p r i s e 的应用服务器。 简而言之，e j b 服务器管理那些支持e j b 组件所需要的资源。一个e j b 服务器提供商可提供一个容器的实现，他也可以 为第三方厂商提供a p i以使其能嵌入附加e j b 容器。e j b规范在服务器的设计 第二章 e n t e r p r i s e l mb e a n s 技术 和实现上给了开发人员以极大的自由。 2 . 2 . 2 e j b容器 e j b组件并不在 e j b服务器的顶部直接执行。一个称为 e j b容器的中间 软件组件在 e j b 服务器环境中 运行， 从而又为这些 b e a n自 身提供操作环境. 。 e j b 容器对 e j b 应用程序是完全透明的， 但是在支持 b e a n 操作方面起着关键 性的作用。 为了使b e a n 能充当可重用的软件组件， 它们对特定的服务器或平台 功能不能有内建的相关性。 服务器端功能的几种常见类型己经被从b e a n 设计中 分离出去， 而将此功能的责任转移给了 容器组件。 例如，容器将被用来接管安 全性、 并发性、 事务处理、 交换到辅助存储器和其它服务的责任， 从而使 b e a n 免受服务器相关性的制约， 并将按业务逻辑来优化， 而不是按服务逻辑来优化。 其主要的职责为: 管理b e a n 生命周期;将e j b 服务器提供的服务传递给b e a n . 生成代码来实现对 b e a n 的存取访问;强制事务处理的限制;创建、初 始化和回收 b e a n ;管理持久数据的存储。 对客户端而言 e j b容器是透明的。 目 前容器通常是由 e j b 服务器本身提供的， 这是由 于在 e j b 1 . 0 或 1 . 1 规 范中没有定义容器到服务器的接口，各厂商可以根据他们的见解来实现服务器 和容器的各自责任。 2 . 2 . 3企业 b e a n 企业b e a n 实现具体的业务逻辑， 它是个符合预先定义好的接口规范的,l a v a 类。在最新的e j b 规范中，将 b e a n 分为三种类型: 2 . 2 . 3 . 1 会话 b e a n ( s e s s i o n b e a n ) 会话b e a n 对业务过程建模 。对于客户机，会话b e a n 是一种非持久性的对 象，它实现某些在服务器上运行的业务逻辑。 可以 把会话对象看作是运行在服 务器上的客户机程序的逻辑扩展。会话b e a n 按其是否保持客户状态分为两类: 无状态会话b e a n 有状态会话 b e a n 这两种会话b e a n 的区别如表 1 。在这里需要说明的是，有状态会话b e a n 采 用钝化 ( p a s s i v a t i o n ) 和激活 ( a c t i v a t i o n ) 来共享实例。 钝化是指当内 存资 源紧张时，通过将 b e a n实例交换出去来回收其所占内存。这里通常采用最近 最少使用原则( l r u ) 来选择被交换出去的 b e a n ，接着容器调用 b e a n中的 第二章 e n t e r p r is e l a v a be a n s技术 e j b p a s s i v a t e 方法关闭使用中的任何资源 ( 如数据库连接、 s o c k e t连接等) 。 然后通过串行化将状态数据写入持久性的存储中去，比如数据库或文件。而激 活的过程与之相反， 将状态数据重新读入b e a n 中， 并在e j b a c t i v e 方法中打开 所需的资源。钝化与激活的概念与虚拟内存中的交换概念很相似。 无状态 ( s t a t e le s s )有状态 ( s t a t e f u 1 ) 在不同 方法调用间不保留 任何状态 事务处理必须在一个方法中结束 通常资源占 用较少; 可以 被共享( 因为它是 无状态的 ) 可以在不同的方法调用间保持针对各个客户 端的状态 与客户端的联系必需被维持:通常开销较大 表1 状态会话b e a n 与无状态会话b e a n 的区别 2 . 2 . 3 .2 实体b e a n ( e n t i ty b e a n ) 实体b e a n 在体系结构上与会话 b e a n 类似， 但它们提供对企业数据的访问， 而不是支持用户会话。一个实体 b e a n可以支持多个并发用户，而容器则使访 问和事务同步。 实体b e a n 还具有支持h o m e 对象中的f i n d e r 方法的主键。 知道 实体 b e a n的主键的客户机可以 通过调用h o m e 对象上的f i n d b y p r i m a r y k e y 0 方法获得对象引用。 与会话 b e a n 不同， 实体b e a n 的h o m e 对象除了具有 c r e a t e 方法外还具有f i n d e r 方法。 持久性是实体b e a n 的一个基本属性。 e j b 规范允许两种形式的实体持久性: b e a n管理的持久性和容器管理的持久性。对于代表数据库中的数据的实体 b e a n , b e a n对持久性的管理意味着，对数据库访问的调用是直接编写在企业 b e a n的方法中的 ( 使用 j d b c或 s q l j ) 。这种方法是直截了当的，但它降低了 可移植性。 容器对持久性的管理意味着b e a n 不受数据库调用的影响。 在安装时 告知容器有关b e a n 数据所需的持久性， 而容器负责生成实现持久性的代码。 这 种方法允许 b e a n 的可移植性更高， 甚至达到持久性可使用不同数据源的程度。 然而，此方法要求容器中要有复杂功能。 2 .2 .3 .3 消息b e a n ( me s s a g e - d r i v e n b e a n ) 在 e j b 2 . 0 中， 对规范的一个基础性更改是添加了一种全新的企业级 b e a n 类型，即m e s s a g e - d r i v e n b e a n 。消息b e a n 专门 来处理入网的j m s 消息，从 而可以对基于消息的系统提供服务。 j m s 是一种与厂商无关的a p t ， 用来访问消息收发系统。 它类似于j d b c ， 这 里，j d b c是可以 用来访问许多不同关系数据库的a p t ，而j m s 则提供同样与厂 商无关的访问方法，以访问消息收发服务。 消息收发系统是异步的， 也就是说， 第二章 e n t e r p r i s e j a v a b e a n s 技术 j m s 客户机可以发送消息而不必等待回应。 比较可知， 这完全不同于基于 r p c 的 ( 基于远程过程的)系统，如 e j b 1 . 1 , c o r b a和 j a v a r m i的引用实现。在 r p c中，客户机调用服务器上某个分布式对象的一个方法。在方法调用返回之 前，该客户机被阻塞;该客户机在可以执行下一条指令之前，必须等待方法调 用结束。 在j m s 中，客户机将消息发送给一个虚拟通道 ( 主题或队列) ， 而其它 j m s客户机则预订或监听这个虚拟通道。当川s客户机发送消息时，它并不等 待回应。它执行发送操作，然后继续执行下一条指令。消息可能最终转发到一 个或许多个客户机，这些客户机都不需要作出回应”。 虽然大多数 j m s厂商都提供消息中介工具，来将消息从发送者路由到接收 者， 但构建使用 ( 接收) 消息的j m s 客户机却是应用程序开发人员的职责。 在 许多情况下，接收消息的应用程序必须强健、安全、快速而且可伸缩;它需要 的基础结构基本上与 e j b应用程序相同。 由于认识到这种需要， e j b 2 . 0 现在包括了消息b e a n 类型， 它可以使用 j m s 消息，并且在同一个强健的、基于组件的基础结构中处理这些消息，这样的基 础结构对于会话 b e a n和实体 b e a n都非常有用。 2 . 2 .4 r e m o t e 接口与e j b 对象 “ 客户机从来不直接访问 e n t e r p r i s e b e a n类的实例。客户机总是使用 e n t e r p r i s e b e a n 的远程接口来访问e n t e r p r i s e b e a n 的实例。 实现e n t e r p r i s e b e a n的远程接口的类由容器提供。此类所实现的分布式对象称为 e j b对 象。， 3 j .c忆 . ， 妞1 1 目创，曰侧臼 c a in 目c a l白. . 的h 二 台 . 翻 创 . 份 八 即栩. .m口 .o d 图 2 . 2 在这里，客户端通过e j b 代理一样。在把调用通过e j b e j b o b j e c ts和远程接口 对象间接调用b e a n 中的方法，e j b 对象就象一个 对象传递时，容器开发商通过包装编码插入其自 第二章j a v a b e a a s 技术 己的功能，这称为请求解释。请求解释的一个例子是为每个方法调用创建一个 新的事务上下文，当方法返回到e j b 对象时提交或回滚事务。 通过这种方式， 容器自 动的执行了隐藏的中间件服务层，正如图2 . 2 所示。这将极大地简化了 组件的开发周期，因为开发人员无需写、调试和维护有关事务、安全和持久性 等服务代码。 由 于客户调用的是e j b 对象上的方法，因 此， e j b 对象必须复制企业b e a n 对象中每一个业务方法。这里的一个问 题是:e j b对象是由容器产生的，那么 容器如何知道它应该复制那些方法?在 e j b规范中，是通过远程接口( r e m o t e i n t e r f a c e ) 解决这个问题。 远程接口 定义了客户能够调用特定企业b e a n 对象的 业务方法，而 e j b 对象实现了该接口。 在这里，我们需要注意的一点是:e j b对象是一个完全的网络对象，访问 叮b 对象需要通过网络以及远程调用的参数转换。当b e a n 的客户与其位于同一 机器时，这种方式效率是很低的。而在e j b 规范2 . 0 中，增加了l o c a l 接口 和 对象从而解决这个问题。 2 . 2 . 5 h o m e 接口与对象 正如前面所提及的，客户是通过 e j b对象来间接地访问b e a n 。这里的一个 问题是:客户如何获得e j b 对象的引用?客户不能直接初始化e j b 对象，这是 由于客户可能与e j b 对象位于不同的进程中。因此，在e j b 规范中，客户代码 需要从一个e j b 对象工厂( f a c t o r y ) 中获得对e j b 对象的引 用。 而这个工厂被称 为h o m e 对象，其主要的职责为: 创建e j b 对象 查找现存的e j b 对象 去除e j b 对象 同e j b对象相似，h o m e对象也是与容器相关的。实际上，它们都是容器的 一部分，并且由 容器所提供的工具来产生。e n t e r p r i s e b e a n还必须具有h o m e 接口， 该接口定义了创建、 销毁和查找e j b 对象的方法。 容器产生的h o m e 对象 实现了 该接口。 图2 . 3 详细说明了h o m e 接口 和h o m e 对象的作用。图中h o m e 对象的引用被 放在名字服务中，客户通过j n d i 来获得它。在获得h o m e 接口的引用后，客户 调用h o m e 接口中定义的c r e a t e ( ) 方法， 作为代理的h o m e 对象则创建一个新的 e j b对象，并将e j b 对象的引用返回给客户。在这里我们可以看出，e j b对象 和h o m e 对象充当 b e a n 对象的代理， 因为它们代表 b e a n 接收方法调用。 e j b 对 象主要为 b e a n业务方法充当代理;h o m e 对象主要为 b e a n生存周期方法充当 第二章 e n t e r p ri s e j a v a b e a n s 技术 代理。 e j b c a n t 目. 曰注 t o - 泳 r创比n已 日 1 : c 旧. 加a n o w e j 日伪 a c t 图2 .3 h o m e i n t e r f a c e s a n d o b j e c t s 2 . 2 .6 部署描述符( d e p lo y m e n t d e s c r ip t o r s ) 为了通知容器b e a n 所需要的系统服务， b e a n 开发者必须在一个部署描述符 文件中声明所需要的系统服务。在最新的e j b规范中，部署描述符是一个 x m l 文档， 它包含了一个或多个b e a n的声明信息。部署描述符说明性地定义 b e a n 的某些行为， 而不是在b e a n 类中通过编码定义行为。 这就允许组装者和部署者 改变b e a n 的工作方式， 如它的事务处理行为或者它的数据库模式， 而无需修改 这个b e a n的代码。 b e a n开发者通常使用工具来产生部署描述符。部署描述符 主要描述了下列信息。 b e a n 组件;它给出h o m e 和r e m o t e 接口，以及b e a n 类的名字。 b e a n 组件期望容器所提供的服务:例如，事务和安全等。 这个 b e a n 对于其他企业 b e a n 和资源管理器的依赖性。 2 . 3 e j 日结构中的角色分析 e j b 体系结构简化了复杂业务应用的开发。 它将e j b 应用开发和部署过程化 分为不同的角色，每个角色有一组特定任务。这些角色解决应用开发、基础设 施服务、应用组