（计算机应用技术专业论文）基于j2ee的面向服务体系结构的研究与设计.pdf

abs tract s ervi ce一 o ri e n t e d aichi t e c t u re ( s 0 a) isa n e wg e n e r at i o n o f a r c h i t e cturei d e o l o g y 即p 1 y ing fo r d i s t ri but e dso fi w ar ed e v e l o p m e n t . s o ah assolv e dt h ep r o b l e m s o f a p p 1 i cat in n s fo r fl exi b i l i tya n d i n t e rcon n ec t i v i t y w ond e 而l l y b e cau s e o f i t s fe at u re s o f 1 oos e cou p l i n g，i n d ep e n d c n t o f p l a t fo rm et c . s o aw i l l be a p p l i ed w i dsl yasan c 伍ci ent s o l u t i o n t o ent e rpr 1 s e a p p 1 i cati o n i n t e g r a t i o n a n d n e ws y s t em a r c h i t eetu r e . f i rs t o f al l ， t hi sth e s i sl u cub rate s t h ea d v a nce di d e as of s 0 aandte c h nol o gy 云 a m e o fj z e e ，and th e nc 0 mb i n e s th emr e as o n abl y to dss i gn amo d e lo f s e rvi ce一 o ri e n t e d户 以 c h i t e c 1 u reb ased o n j 2 e ea n dd i scu s s e s 1 h e compos in gp art o f t h e a r c h l t e c t u re . llin c l u d e s w 七 b s e rv i ce s ru n t i m e an d s e rv i eecon t a i n e r a n d th e g e n e r a 1 c l i e n t . t 七 et a r g e to fth ea r c b 1 t ectu re i st h a tm a k i ng th ed e v e l o p m e n t of s e rv ice com pon e n t s o r i e n t s e rvi c e i n the mo s t e x te n t ， soitm ake s t h e d e v e l o p m e n t o f s y s t e ms h a v e the fe ature s o f l oos e cou p l i n g and re u s e and e x p a n s i b i l i t y. ai the l as t ， m 雨 n g an examp l e o f ent e rpr i s e s e l l ma n a g e m e n t s yst e m ， des i gn andi mp l e me nt i t b a s e do nthis mo d e l ， w h i ch v al i dat e th ea d v ant a g eof t h es e rv i ce d eve l o p m e nib a s e d o n th i s m o d e l . f i n a l l y，a concl u s i on i s h a d i n t h e e n d o f the t hes i s ， and ana l yz e s t h e as 讲ct s whi chn e e d tob e 而p ro v e d . i t a lso poin tsth e fu tu rere s e a r c h d i r e c t i o n 心 y w心 川5 : s e rv i ce一 o r i e n t e d a rcb l t ect u re ; s o ft w ar e a r c b i t e c t u r e ; j z e e; m几bse rvi c e s 学位论文独创性声明 学位论文独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作及取得的 研究成果。据我所知，除了文中特别加以标注和致谢的地方外，论文中不包含 其他人已经发表或撰写过的研究成果， 也不包含为获得 南昌大学 或其他教育 机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何 贡献均己在论文中作了明确的说明并表示谢意。 学 位 论 文 作 者 签 名 (手 写 ): 三 髓签 字 日 期 :铆 年 月1 日 学位论文版权使用授权书 本学 位论文作者完全了 解南昌大学有关保留、 使用学位论文的规定， 有权保留并向国家有关部门或机构送交论文的复印件和磁盘，允许论文被查阅 和借阅。 本人 授权南昌大学可以 将学位论文的 全部或部分内 容编入 有关数 据库 进行检索，可以采用影印、缩印或扫描等复制手段保存、汇编学位论文。 ( 保密的学位论文在解密后适用本授权书) 学 位 论 文 作 者 签 名( 手 写 ) : 王 彭 导师签名 ( 手写卿 签 字 日 期 ，卜 刁 年 月日 签 字 日期: 曲年 月 “ 日 学位论文作者毕业后去向: 工作单位: 通 讯地 址: 电话: 邮编: 第 1 章 引言 第 1 章 引言 l l研究背景 随着软件开发方法研究的发展和分布式技术应用的深入，基于多种开发平 台和工具的 软件系统得到大量应用，使得企业中的软件系统变得日 益庞大和复 杂。各式rr系统的建设常常是用不同的语言开发并建立在不同的平台 之上， 这 些系统之间 有很多功能属于重复开发，既浪费 又不便于管理，各系统之间也很 难进行信息共享。此外，由 于传统的软 件开发使用的平台，开发工具，操作系 统 在结构上的紧祸合，以致这些位置分散的独立系统逐渐形成了所谓的 “ 信息孤 岛， ， 1 ， 。 为了更好的重用己 有模块，加快软 件开发速度，使这种重用可以不用考虑 各自 运行平台 和开发环境的 差异， 并使被重用的 模块可以 方便地由旧系统纳入 新系统，因此就需要一种新的软件开发方法来达到以上目的。 从软件发展史来看已经经历了面向过程、面向对象和面向构件等几个阶段， 由于面向 过程高 度祸合而不适合于较大软件系统的开发，面向对象只能支持同 种语言，而面向构件虽然能 做到构件二进制级别共享但还是局限于特定 平台。 因 此， 一种称为面向 服务的体系结构12( serv i ce 一 。 ri en t eda r c b i te cture ， s o a ) 的软 件设计方法被提出来，这种通过对服务流程化的组织来构建分布式系统的方法 既是体系结构模型，又是编程模型。 面向对象的语言和技术是实现构件的 较好 方式，虽然一个良好设计的面向构件的应用并非一定可以转变为好的面向服务 的 应用，但构件却是实现服务最好的方式。这种转变就在于面向 服务的 方法在 已 有应用 之上又实 现了 一个服务层。 面向服务体系结构允许设计这样的软件系统:它通过发布可发现的接口为 其他的 应用程序提供服 务， 而其中的服务可以 通过网 络进行调用。 通过采用s o a 框架，企 业可以最大程度地减少系统间的祸合， 从而提高可重用性。当用 节 阳 b 服务 技术来实现面向 服务体系结构时，我们是在一个强大、灵活的 编程模型中 创建一种新的构建应用程序的方式，这种构建方式降低了开发成本、持有成本 以 及 实 现 风 险 lal 。 第 1 章 引言 w 匕 bserv i ce sln是一套技术体系，可以 用来建立 应用解决方案，解决特定的 消息通信和应用集成问 题.随 着时间的 推移， 这些技术在不断发展、成熟， 也 会更好地帮助实现面向服务的体系结构。面向服务的体系结构具体的实现有很 多，包括 晒 怂 b s erv i ce、 c o r b a和 j ini 等，但随着 we b s erv i ce技术被越来越重 视，其己 经成为构建面向 服务的体系结构的主要技术。 j z e e i .4平台 阁 的 推出， 对节 几 bserv ice 的 创建、部署提供了丰富的 支持，使得jze e 成为企业开发具有 面向 服务体系结构的应用的 首选. j z e e i .4平台也支持web se rv i ce s for jz ee 规 范 (j s r 9 2 1 ) ， 后 者定 义 了v 几 b 服 务的 部 署需 求 并 利 用了 j a x 一r p c 编 程 模型 。 除 t 几种w e b 服务a p l 之外， j z e ei . 4 平台 还声称支持w s 一 i b a s i c p ro fi l e l .0 0 ws 一 i b as ic p rofile 标准让m 几 b 服务克服了不同编程语言、操作系统和供应商平 台之间的障碍，从而使多种应用程序之间能够交互。这意味着除了平台独立性 和完整的 w七 b 服务支持之外，j z e e i .4还提供了跨平台的 研 触 b服务互操作性。 1 .2 国内 外研究现状 面向服务的体系结构是基于“ 软件变服务” 思想， 提出了一种新的解决软件重 用和软件集成的方案。通过采用面向服务的体系结构，企业能够迅速便捷的构 建开放的、模块化的、可重用的软件组件。这种模式尤其适合面向广域环境的 大 规 模 应 用 场景 ， 如 跨 企 业 的电 子 商 务 系 统 ( 如 供 应 链 管 理 和 b z b 等 等 ) 、 跨 地 域 或者跨部门的电子政务系统、intemet 环境下的协同计算 ( 如网格计 算、虚拟组织 等等 )le。 在基于面向服务的软件体系结构研究中，目前已实现了面向服务的体系结 构的较有代表性的工作是s un的j ini 技术以及得到各大公司广泛关注的we b 服务 技术。 作为面向服务的 体系结构的一种实现手段， web服务提供了 基于x ml 标准 接口的若干中间件，具有完好的封装性、松散的祸合性、协议规范的标准性以 及高度的可集成性等特点，能够很好的满足面向服务体系结构应用模式需求。 目前己经有一系列基于x ml 的w七 b 服务标准被业界广泛接受， 形成了v 几 b 月 及 务的 核心技术。w 七 b 服务继承了 x m l 语言的优势，它是一 种与开发语言和平台 无关 的开发技术，并采用和支持国际公开的开放技术标准规范。 针对业已 公布的标准， 许多大型企业( ibm、m ic ro so ft 、s un、 b e a 等等) 开 第 1 章 引言 始着手对基于web服务的面向服务的体系架构予以实现和推广闭。 1 3 本文研究的主要内 容 面向服务体系结构是一种新型的软件体系结构， 它实现了在w七 b 上分发少的 应用程序逻辑， 解决了 v 几 b 数据集中、 冗余、 无法共享的缺陷， 屏蔽了后台技术 的复杂性。通过采用s o a 框架，企业可以最大程度地减少系统间的祸合，从而 提高可重用性。 而j z e e 体系结构提供中间 层集成框架用来满足无需太多费用而 又需要高可用性、 高可靠性以 及可扩展性的应用的需求。 本文深入研究了 s o a 的先进架构理念和jz ee技术框架， 并且将两者很好的结合， 为现代应用系统开 发 提供了一种实现面向 服务的可操作的 技术框架。 并在实际 应用系统的开发中 加以应用。 在本课题的研究过程中，本文的主要工作如下: 1)深 入理 解 面向 服 务 体 系 结 构 的 概 念 及原 理 ; 刀对面向服务体系结构的实现技术框架jzee 及web s ervi ces 技术进行了 分 析和阐述; 3)通 过 对jz ee 技 术 进 一 步 深 入 研究 和 实际 应 用， 将 面向 服 务 体 系结 构 应 用 在jz e e 平台， 设计一种基于jzee 的面向 服务体系结构模型， 从而使得 应用系统的开发能够更加方便、快捷，提高资源的共享程度和利用率， 减小软件的重复开发，降低系统的维护量，而且基于此体系结构所开发 出的 应用系统是基于面向 服务的松散祸合和可重用的系统; 叼 从具体实现的 角度， 将基于 j z e e的 面向服务体系结构应用于企业销售 系统中， 进一 步验证 采用该 体系架构进行服务开 发流程的 优势。 l 4本文组织结构 本论 文由六章组成，各章的主要内 容如下: 第一章:引言 介绍 面向 服务体系结构的研究 背景和国内 外研究现状及本课题的主要研究 内容。 第二章:面向服务 体系结构 (so a ) 的研究 第 1 章 引言 介绍了 s o a的概念并详细分析了其特性，在此基础上给出了一个 s o a的 结构模型，描述了各模块之间的相互作用。然后提出了 部署s o a架构可以给带 来的好处。 第三章:jze e 技术及节 几 b s erv ice s 的研究 深入学习和研究了j z e e技术框架和 w七 b serv i ces 技术。 第四章:基于jzee 的面向服务体系结构的设计 将 jze e技术框架与面向服务架构两者结合，设计一种基于 jzee 的面向服 务体系结 构框架模型，并讨论了 该框架的各组成部分及工作机制， 包括 w 七 b 服 务运行时环境的设计、服务管理容器的设计和通用客户端的设计等。并实现了 服务的整个调用过程。 第五章:企业销售系统应用实例 从具体实现的角度，将基于 jze e的面向服务体系架构模型应用于企业销售 系统中，进一步验证了采用该体系架构开发服务的优点，同时体现了采用面向 服务思想进行软件开发的优势。 第六章:总结与展望 阐述了本课题的主要工作和研究成果以及不足之处，并对其发展应用作出 了展望。 论文最后部分是“ 致谢” 和“ 参考文献，o 第2 章 面向服务体系结构(s o a ) 的研究 第2 章 面向服务体系结构(so a ) 的研究 2. i s o a的 概念 从总体上来讲， s o a 是一种结构模型，它可以 根据需求并通过网络对松散 祸合的粗粒度应用组 件进行分布式部署、 组合和使用。下面给出 业界一些关于 s o a 的定 义151: s ervi 优 一 a r c hi te ct 将s o a 定义为: “ 本质上是服务的集合。 服务间彼此 通信，这种通信可能是简单的数据传送，也可能是两个或更多的 服务协调进行 某些活动。 服务间需要 某些方法进行连接。 所谓服务就是精确定义、 封装完善、 独立于其他服务所处环境和状态的函数气 1 o o se 妙 co uple d. co m 将 s 0 a 定 义 为 : “ 按 需 连 接 资 源的 系 统 。 在 s 0 a 中， 资 源 被作为可通过标准方式访问的独立服务，提供给网络中的其他成员。与传统的 系统结构 相比， s o a 规 定了资源间更为灵活的 松散祸合关系气 ibm 认为: “ s o a 展现出比v 叱 bse rv i ce更加广泛的 应用前景，s o a 是一种构 建能够交付终端一用户间服务或构建其他服务的功能组件，o s o a 解决方案由 可重用的服务组成，带有定义良 好且符合标准的已 发布接 口。s o a 提供了一种机制， 通过这种机制， 可以 集成现有的 遗留应用程序，而 不管它们的平台或语言。 通 过 前 面的 论述 ， 我 们 可以 将 面向 服 务的 体 系结 构 ( s 0 a ) 定 义 如 下: “ 面向 服务的 体系结构是一个组件模型， 它将应用程序的 不同功能单元( 称为服务) 通过 这些服务 之间定义良 好的接口和契约联系 起来，接口是采用中 立的方式进行定 义的， 独立于实现服务的硬件平台 、操作系统和编程语言，使得构建在各种这 样的系统中的服务可以用一种统一和通用的方式进行交互，o 2. 2 5 0 a的体系结构 面向 服务的 体系结 构提供了一种方法， 通过这种方法， 可以构建分布式系 统来将应用程序功能作为服务提供给终端用户应用程序或其他服务. 第2 章 面向 服务 体系 结构(s o a ) 的 研究 图2.i s 0 a协作图 图21 展示了 面向服务体系结构中的 协作。这些协作遵循 “ 查找、 绑定 和调 用”范例;其中，服务使用者执行动态服务定位，方法是查询服务注册中心来 查找与其标准匹配的服务。如果服务存在，注册中心就给使用者提供接口契约 和服务的端点地址。 面向服务的体系结构中的角色包括队 ( 1)服务使用 者: 服务使用者是一个应用 程序、 一个软件模块或需要一个服 务的另一个服务。它发起对注册中 心中的服务的查询，通过传输绑定服务， 并 且执行服务功能。服务使用者根据接口契约来执行服务。 ( 2) 服务提供者: 服务提供者是一个可通过网络寻址的实体， 它接受和执行 来自使用者的请求。它将 自己的服务和接口契约发布到服务注册中心，以便服 务使用者可以发现和访问该服务。 (3 ) 服务注册中 心: 服务注册中 心是服务 发现的支持者。 它包含一个可用服 务的存储库，并允许感兴趣的 服务使 用者查找服务提供者接口。 面向 服务的体系结构中的每个实体都扮演着服务 提供者、 使用者和注册中 心这三种角色中 的某一种( 或多种) 。面向 服务的 体系结 构中的 操作 包括l l o: (l) 发 布: 为 了 使 服 务 可 访 问 ， 需要 发 布服 务 描 述 以 使 服 务 使 用 者 可以 发 现 和调用它。 ( 匀发 现: 服 务 请求 者 定 位 服 务， 方 法是 查 询 服 务 注 册 中 心 来 找 到 满 足 其 标 准的服务。 ( 3 ) 绑定和调用: 在检索完服务描述之后， 服务使用者继续根据服务描述中 的信息来调用服务。 面向服务的体系结构中的构件包括: ( 1)服务: 可以 通过己发 布接口使用服务，并且允许服务使用者调用服务. 第2 章 面向 服务体系结构( s 0 a ) 的 研究 ( 2 ) 服务描述: 服务 描述指定服务使用者 与服务提供者交互的方式。 它指定 来 自服务的请求和响应的格式。服务描述可以指定一组前提条件、后置条件或 服务质量 ( q os) 级别。 除了动态服务发现和服务接口 契约的定义之外，面向服务的体系结构还具 有以下特征: (l ) 服务 的 封装 性 : 把 服务 封 装成 可以 被 不同 业 务流 程 重复 使 用的 业 务 组 件。 它隐藏所有实现细节， 不管服务内 部如何修改， 使用什么平台、 什么语言， 只 要保持接口 不变， 就不会影响最终用户的使用。 (2 ) 服 务 的 重 用 性: 一个 服 务 是 一 个 独 立的 实 体， 与底 层 实 现 和 用 户的 需 求 完全无关，极大的方便了服务的重复使用，从而降低了开发成本。 口 ) 服 务 间的 互 操 作 性: 服 务 之 间 通 过 既 定协 议 采 用同 步 或异 步 方 式 通 信。 仔 ) 服务是自 治的实 体:即 服务自 身是完全独 立的、自 包含的、 模块化的。 (5 ) 服务的 松祸合度:即服务请求者和服务 提供者之间只有接口 上的 往来， 至 于服务内部如何更改，如何实现都与服务请求者无关。 (6) 服 务 是 位 置 透明 的 : 即 服务 请 求者 不 需 要 知 道 服务 的 具 体 位 置 及 是哪 一 个 服务响应了自己的 请求， 服务请求者关心的是使用一个服务完成了自己 要处 理的工作就可以了。 最后，我们需要说明的是，面向服务的体系结构并不是一个新的概念.如 图 2. 2 所示， 面向服务的 体系结构所涉及的 技术至少包括c o r b a 、 d c o m 和jz ee 。 面向 服务的 体系 结构的早期 采用者 还曾 成功地基于消息传递系 统( 如ib m ， 几 b s p h e r e m 助创建过他 们自己 的面向 服务 企业体系结构. 最近， s o a 的应用范 围己 经扩展到包括wo rl d widev 几 b ( w钾叨和 v 几 b 月 及 务等111 10 分布 式系 统体系 结构 图2. 2面向 服务的 体系结构的不同实 现 在面向服务的体系结构中，映射到业务功能的服务是在业务流程分析的过 第2 章 面向服务体系结构(s o a ) 的研究 程中确定的。 服务可以是细粒度的， 也可以是粗粒度的， 这取决 于业务流程。 每个服务都有定义良好的接口，通过该接口就可以发现、发布和调用服务。企 业可以选择将 自己的服务向外发布到业务合作伙伴，也可以选择在组织内部发 部服务。服务还可以由其他服务组合而成。 2 35 0 a与 传统的软件架构的比 较 s o a被认为是传统紧祸合的、面向对象的模型的替代者，例如通用对象代 理架构 c o r b a l l z ( 。mmon o bj e ctr e q u e s t b ro k e r 户 以 c h i t e ct u r e) 和分布式组件对 象 模型 d c o m ，3 1但ist 五 b u t e d com 卯 n e n t o bj ee t 枷d e l) 。 下 面 通 过 传统 的 软 件 架 构 中的分布式组件架构与s o a 架构的对比，来阐述它们之间的不同。下面的表2. 1 分布式组件架构与s o a 对比中给出了s o a 与分布式组件架构的不同点。 表 2. 1 分布式组件架构与 s o a对比 分布式组件架构 s oa 面向功能面向流程 设计目的是为了实现需求设计目的是为了适应变化 开发周期长交互式和重用性开发 成本为中心业务为中心 应用阻塞月 浸 务协调 紧密祸合敏捷的和松散祸合的 同构技术异构技术 面向对象面向消息 需深入了 解实施细节 独立于实施细节 s o a 不是一种新的技术，而是对传统的、紧密的面向对象模型的另一种选 择。 而且 s o a 并没有排斥面向 对象，系统的总体设计 是面向服务的，但是具体 到某个服务的实现可以是基于面向对象设计的。 s o a 是允许对象在系统内存在 的，所以 s o a 其实也是 基于对象的， 但是 s o a 作为一个 整体就不是面向 对象的， 可以说s o a是更高层次意义上的架构。s o a 和面向对象的区别在于接 口上，面 向对象的 接口 是给其他对象使用的，而s o a 的接口 是可以 给从组件到系统来使 用的， s o a 的接口 一般使用w 七 b 服务、 ejb 、 c o r b a 等分布的技术来实现。 与传统架构相比，s o a 具有以下更多优势:基于标准、松散祸合、共享服 务、粗粒度和联合控制等。s o a与大多数通用的客户端/ 服务器模型的不同之处 第2 章 面向 服务体系结构 ( s o a ) 的研究 还在于它着重强调软件组件的松散祸合，并使用独立的标准接口。 2. 4 s o a的优点 面向 服务的体系结构可以基于现有的系统投资来发展，而不需要彻底重新 创建系统。如果组织将开发力量集中在创建服务、 利用现有的技术、结 合基于 组件的方法来开发软件上，将有如下几方面优势il: (1 ) 利用 现有的资产 s o a 提供了一个更高级抽象层，通过这个抽象层，可以 将业务构造成现有 服务的集合。 使用这种新的服务只需要知道它的接口和名称，服务的内 部细节 以 及组成服务的组件之间的数据复杂性都对外界隐 藏了。这种组件的匿 名性使 组织能 够利用现有的投资，从而通过合并构建 在不同的机器上、 运行在不同的 操作系统中和用不同的编程语言开发的 组件来创建服务。组织可以继续 从现有 的资源中获益，而不必重新构建系统。 ( 2) 更易于集成和管理 在面向服务的体系结构中，集成点是规范而不是实现.这提供了实现的透 明性，并将因为基础设施和实现发生的改变带来的影响降到最低限度。通过提 供针对基于完全不同的系统构建的服务规范，使应用集成变得更加易于管理。 特别是当多个企业一起协作时，这会变得更加重要。 (3 ) 更快的响应和上市速度 通过现有的服务组合新服务的能力为那些需要灵活响应商业要求的组织 提 供了 帮 助。 利 用 现 有 的 组 件 和服 务 ， 可以 缩短 软 件开 发 生 命 周期 ( 包 括 收 集需 求 、 进行设计、 开发和测试) 。 这使得可以快速地开发新的 业务服务， 减少了上 市准备时间。 () 持续改进业务过程 s o a 允许清晰地表示流程流， 这些流程流通过在特定的业务服务中 使用的 组件的顺序来标识，这给用户提供了监视业务操作的理想环境。业务建模反映 在业务服务中，流程操纵是以 一定的模式重组部件来实 现的。这将进一步允许 更改流程流，而同时监视产生的结果，因此促进了持续改进。 (5 ) 降 低风险 重用现有的组件降低了在创建新的业务服务的过程中带来的 风险，同时也 第2 章 面向服务体系结构(so a)的 研究 可以减少了维护和管理支持服务的基础架构的负担。 师 ) 以流程为中 心的 体系结构 现有的体系结构模型和实践往往是以程序为中心的。 应用程序是为了程序 员的 便利而开发的。 通常， 流程信息在组件之间传播。 应用程序很像一个黑匣 子，没有粒度可用于外部。重用需要复制代码、合并共享库或继承对象。在以 流程为中心的体系结构中，应用程序是为过程开发的。流程可以分解成一系列 的步骤，每一个步骤表示一个业务服务。实际上，每个过程服务或组件功能都 相当于一个子应用程序。将这些子应用程序链接在一起可以创建能够满足业务 需求的流程。这种粒度允许利用和重用整个组织中的子应用程序. 2 . s s o a 与 we bs e 件i c e s 的关系 s 0 a 与认 肥 b serv ices 是两个不同 层面的问 题， 前者是概念模式， 面向 商业应 用; 后者则是实现模式，面向 技术框架， s 0 a 不等于web s e rv icesll sj. s o a 概念并没有确切地定义服务具体如何交互，而仅仅定义了 服务如何相 互理解以及如何交互。其中的区别也就是定义如何执 行流程的战略与如何执行 流程的战术之间的区别。而另一方面，w七 b 服务在需要交互的服务之间如何传递 消息有具体的 指导原则。 从战术上实现s o a 模型是通过 h t t p 传递的 s o a p 消息 的v 叱 b 月 及 务模型。因 而， 从本质上讲，节 沱 b 月 及 务是实现s o a 的具体方式之一。 尽管我们觉得w七 b 服务是实现s o a 的最好方式， 但是s o a并不局限于v 触 b 月 及 务。 其他使用ws d l 直接实 现服务接口并且通过x m l 消息进行通信的协议也可 以 包括在s o a 之中。 正如其他文献指出的， c o r b a 和m m的m q 系统通过使用能 够处理ws d l 的新特征也可以参与到s o a中来。 第3章 jze e技术框架及 v 叱 bservi ces 的研究 第3章 j z e e 技术框架及w e bs e r v i c e s 的研究 3 .i j z e e 技术概述 jz e e 技术是一种利用 j av a z 平台 来简化诸多与多级企业解决 方案的开发、 部 署和管理相关的复杂问 题的体系结构。jz ee 技术的基础就是核心j a v a 平台或 j avaz平台的标准版，j z e e 不仅巩固了标准版中的许多优点，例如 “ 编写一次、 到处运行” 的特性、 方便存取数据库的 j d b c a p i ， c o r b a 技术以 及能够在inte m et 应 用中 保 护 数 据的 安 全 模 式 等 等， 同 时 还 提 供了 对ej b作 ni erpris e j av a b e a ns ) ， j av a s ervle ts api ， js p (j av a se rv er pa ge s) 以 及 x m l 技 术的 全 面 支 持. 其 最终目 的 就是成为一个能够使企业开发者大幅缩短投放市场时间的体系结构1161。 j z e e 体系结构 提供中间层集成框架用来满足无需太多费用而又需要高可用 性、高可靠性以及可扩展性的应用的需求。通过提供统一的开发平台， jze e 降 低了 开发多 层应用的费用和复杂性，同时 提供对 现有应用程序集成强 有力支持， 完全支持 e n te 甲 r i s e j ava beans ， 有良 好的向 导支持打包和部署应用， 添加目 录支 持，增强了安全机制，提高了性能。 j z e e 提供了 一个企业级的 计算模型和运行环境用于开发和部署多层体系结 构的应用。 它通过提供企业计算环境所必需的各种服务， 使得部署在jz e e 平台 上的多 层应用可以实现高可用性、 安全性、 可扩展性和可靠 性。 它的 优越性在于: 计算平台 支持j av a 语言， 使得基于】 z e e 标准开发的 应用可以 跨平台 地移植; j ava 语言非常安全、 严格，这使开发者可以 编写出 非常可靠的 代码: jzee提供了企 业计算中 需要的所有服务， 且更加易 用; jzee中多数标准定 义了接口 ， 例如j n d i ( j ava n a m 吨 and d i r ec t o ryl n t e ri 兔 c e ) 、 j d b c 、 j ava m ail等，因 此可以 和许多 厂 商的产品配合，容易得到广泛的支持;j z e e 树立了一个广泛而通用的标准，大 大 简 化了 应 用开 发 和 移 植 过 程 11飞 3 .z j z e e 技术组成 3 .2.i j z e e分布式体系结构 jz ee使用多层的分 布式应用模型， 应用逻辑按功能划分为组件，各 个应用 组件根据他们所在的层分布在不同的机器上。事实上，s u n 设计jzee 的初衷正 第 3章 j z e e技术框架及 w七 bs e rv i 沈5 的研究 是 为了 解 决 两 层 模 式 ( cli en 珑 erve r) 的 弊 端， 在 传 统 模 式中 ， 客 户 端 担 当了 过多 的 角色而显得臃肿: 在这种模式中，第一次部署的时候比较容易，但难于升级或改 进， 可伸展性也不理想， 而且经常基于 某种专有的协议， 通常是 某种数据库协议。 它使得重用业务逻辑和界面逻辑非常困难.现在，jze e 的多层企业级应用模型 将两层化模型中的不同层面切分成许多层。 一个多层化应用能够为不同的每种服 务提供一 个独立的分层，以下是 jzee典型的四 层结构1181，如图 3 . 1 所示: . 运行在客户端机 器上的客户层组件 . 运行在jz e e 服务器上的 w七 b 层 组件 . 运行在jz ee服务 器上的 业务逻辑层组件 . 运行在el s 服务器上的企业信息系统( e n t 呷riseinfo rmations ys te m)层软 件 jz e e 应 用 程 序 1 nf e 应 用 程 序2 猎 儡 盖 望 霏 引门一习到 吟崛呼elsm 噩园图困 圈图回 图3.i j z e e层次结构示意图 3. 2. 2 j2e e组件技术 j z e e 平台采用了 基于j ava 技术的分布式组件技术， jzee组件是一个本身包含 功能的软件单元，可以 将它相关的 类和文件装配到一个 jze e 应用中，同时 它还 可以与其 他组件进行通信。 j z e e 规范定义了下列的 jze e 组件11 9= (l ) 客户端层组件 客户 端层组件负责与用户的交互过程， 应用客户 端程序和浏览器是客户端层 组件。客户端层组件可以是基于 v 沱 b方式的即作为 v 几 b服务器的浏览器，也 可以是基于传统方式的 ( 非基于we b 方式) 即独立的 应用程序，可以 完成瘦客户机 无法完成的任务。 w七 b 客户端由两部分组成:动态w eb页面和w eb浏览器. 动态w eb页面包括不 同 类型的标记语言例如 h t m l ， x m l 等等， 这些页面都是由 运行在w e b 层的w eb 组件产生的。而w eb浏览器则负责解释出由服务器传来的这些页面。w七 b 客户端 第3章 j z e e技术框架及w匕 b s erv i ccs 的研究 通常被称作瘦客户端. 瘦客户端通常不做像查询数据库、 执行复杂的业务逻辑或 与任何继有系统连接等工作。 当 我们用一个瘦客户端时， 主要的 操作是由 运行在 j z e e 服务器的企业组件执行的，而这些企业组件是由jze e 服务器端的安全性、 速度及可靠性服务支持的。 应用程序客户端是一种运行在客户端机器上的应用程序。 它使用户能够在自 己的机器上处理任务， 而这则要 求丰富的 用户接口 而不仅仅是一种标记 语言。 这 通常需要有一个g ui。 应用程序可以直接访问 运行在业务 层的企业组件。 但是， 如果需要一个web 客户端时，它也能打开一个h 了 fp连接与运行在 w eb 层的se rvlet 进行通信. ( 2)v 几 b 层组件 v 阳 b层组件用来产生表示逻辑，负责处理用户的输入和产生对客户端的响 应。 jzee v le b 组件有两种: jsp 和serv lcts 。 s e rv l e ts 是能够动态处理请求和构件响 应的j ava 类。j sp是一种基于文本的文档，可以作为se rvlets 运行，但是更容易创 建静态内容。w 七 b层可能包含某些j ava b 恤 对象来处理用户输入，并把输入发 送给运行在业务层上的 e n l e 印 r j s e b e 叨来进行处理.以上 过程如图3. 2 所示. 图3. 2 j z e e 节 几 b 组件通信 (3 ) 业务层组 件 业 务 层 组 件 处 理 应 用 的 核 心 业 务 逻 辑， ente 甲 risej av abe an s 归功 是业 务 层 组 件， 它能够解决在多层结构中由管理分布式商务对象带来的问题. 业务组件通信 主要有两个过程: 一个过程就是企业b ean 接收由 客户端传来的数 据， 处理它， 然 后将处理后的数据送往企业信息层存储; 另一个过程就是企 业be an从存储层取数 据，处理它，然后将处理过的 数据往客户端。 企 业 be an 分 三 种 类 型 : 会 话 be an ( 无 状 态 和 有 状态 ) ， 实 体 be an伪 e an 管 理的 和 容器管理的 ) 和消息驱 动bean。会话bean代表与客户端间的短暂会话。客户端的 处理结束时，会 话bean 和他所持有的数据就消失了。 与此相反， 实体be an代表持 第 3 章 jze e技术框架及 v 几 bservi 邝5 的研究 久存储在数据表中的一条记录。 如果客户端停止运行或者服务器停止， 下层服务 仍然能够确保实 体bean的数据不丢失。消息驱动bean 综合 会话b ea n 和j ava 消息服 务监听器的特点，允许业务组件处理异步消息。以上过程如图3. 3 所示。 例. 6 层 业务层 e i s 层 jze e 服 务器 图3. 3 jzee 业务 组件通信 ( 4) 企业信息系统层组件 企业基础建设系统，例如企业资源计划( e rp) ，大型机事务处理， 数据库系 统等，和其它的遗留信息系统组成了企业信息系统层。 3 . 2 3j z e e容器 jz e e 服务器以 容器的形式为组件提供底层服务。 在部署过程中，组件被安 装到相应的容器中。容器为组件提供与部署、执行、 生命周期管理、安全等相关 服 务。 在 容 器中 ， j zee 组 件 可以 彼 此 之间 (或同 其 它 容 器中 的 组 件 ) 进 行 通 信。 jz ee 标准定 义了四种不同的容器为不同 类型的组件提供服务 120: (l ) 抑pl e 容 器 : 如 运 行 在客 户 机 上 的 v 阳 b 浏览 器 和 j av 痛 件。 (z) 应用客户端容器:管理 一个j z e e 应用中的全部应用客户端组件的执行。 应用客户端及其相关容器运行在客户机上。 (3 ) ， 几 b 容器: 管理jz e e 应用中 jsp 和s e rv l e t 组件的执行，是服务器端容器。 w 七 b 容器中的组件可调用ejb 容器中的组件来完 成复 杂的 商业逻辑。 (4) ejb 容器: 管理 运行在其中的 ejb 组件， 是服务器端容器。 只要满足j zee 规范的 ejb 放入该容器， 马 上就会被容器进行高 效率的 管理。 ejb 容器除了为 ejb 提供事务处理、目 录服务、持久性管理和安 全服务 外， 还负责ejb 的部署、发布 和生命周期管理。 jze e 的组件及其在容器中的分布如图3 . 4 所示: 第 3 章 jzee 技术框架及 w比 servi ces的研究 图 3. 4 j z e e容器 3 3 w 七 bs e r v i c 韶 3 3 . i s e rvi ces 概述 近 年 来， v 几 b se rv ices( web 服务 ) 获 得了 巨 大的 发 展。 许 多 软 件 公司 纷纷 宣 布 了对节 阳 b serv i ces 的支持和应用。并有很多组织参与了v 几 b s erv i ces 标准的完善。 虽然对v 阳 b serv i ce s 的 理解正慢慢的趋同， 但是目 前仍然没有统一明 确的定义; 一般认为， 它是一种新型的 研 几 b 应用程序， 具有自 包含、自 描述以 及模块化的 特 点， 可以 通过v 几 b 发布、 查找 和调用。w 七 bserv i ces 实现的功能可以 是响应客户 一个简单的 请求，也可以是完成一个复杂的 商务 流程。一旦一个v 阳 b serv i ce s 配 置好后， 其它应用程序 和其它， 触 b scrv i ee s 就可以 直接发现和调用该服务.咭 3 j . z w七 bs e rvi c e s 特征 节 阳 bservice s 是一种部署 在研 怂 b 上的 对象、组件，是可以 通过网络访问的 应 用程序接口， 它具备以下 特征 12111221: (l ) 完 好的 封 装 性: 服务 是 一 种部 署 在 节 肥 b 上 的 对 象，自 然具 备 对 象的良 好 封装性， 对于使用者而言，能且仅能看到该对象提供的 功能列表。 (z) 松 散 祸 合 :当 一 个 ， 怂 b 月 及 务的 实 现发 生变 更 的 时 候， 调用 者 是 不 会 感 到 这一点的， 对于调用者 来说， 只要服务的调用接口 不变， 服务实现任何变更对他 们来说都是透明的。 (3) 使 用 标准 协 议 规 范: 作 为 web 服 务， 其 所有 公 共 的 协 约完 全需 要 使 用 开 放的标准协议进行描述、 传输 和交换。 这些标准协议具有完全免费的规范， 以 便 由任意方进行实现. (4) 高 度可集成能力:由于 服务采取简单的、 易理解的 标准协议作为组件接 第 3章 ne e技术框架及 从 飞 b servi 沈5 的研究 口描述规范和协同描述规范，完全屏蔽了不同软件平台的差异，无论是 c o r b a ( 通用对象代理架构) ， d c o m ( 分布式组件对象模型) 还是 ejb(ente 印 n s e j av a b e an s) 都 可以 通 过 这 一 种 标 准的 协 议 进行 互 操 作， 实 现了 在当 前 环境 下 最 高 的可集成性。 w已 b 服务的封装性、 松散祸合、 使用标准协议规范和高 度可 集成能 力的 特点， 很好地适 应了企业应用集成发展的要求。 与传统的企业应用集成技术相比， w 七 b 服务应用于企业应用集成将具备简单性、 开放性、 灵活性、 动态性以 及便宜、 应 用范围广等特点。 w七 b s erv i ees 因其固有的特征， 所以同传统的分布式模型相比， m 怂 b servi ces 技术的主要优势在于123一均: (l) 高 度的 通 用 性和 易 用 性: web se rv ices 利 用 标 准的 inte m et 协 议 ( 如 h t t p ， s m t p 等 ) ， 解 决了 面向 web 的 分 布式 计 算 模式 ， 提高 了 系 统 的 开 放 性 、 通 用 性 和 可 扩展性;而c o r b a， d c o m ， r m i 使 用私有的协议， 只能 解决企 业内 部的 对等 实体间的分布式计算。此外h i t p 协议能够很容易 地跨越系统的防 火墙， 具有高 度的易用性。 (z) 完 全的 平 台 、 语言 独 立 性: v 几 b se rv ices 进 行了 更 高 程 度 的 抽 象 ， 只 要 遵守， 叱 bservi ces 的接口即可进行服务的请求与调用。v 几 b 月 及 务将xm l 作为信息 交换格式，使信息的处理更加简单，厂商之间的信息很容易实现沟通， 这种信息 格式最适合跨平台 应用。 此外， w 比服务基于s o a 卫 协议进行远程对象访问， 开 发实现可以通过各种开发工具， 而不需要绑定到特定的开发工具之上， 这很容易 适应不同客户、 不同系统平台以 及不同的开 发平台。 而c o r b a，d c o m ， t m 工等 模型要求在对等体系结构间才能进行通信。 (3) 高 度的 集 成性 : web 服务 实 质 就 是 通 过 服 务的 组合 来完 成 业 务 逻 辑 的 ， 因