(计算机应用技术专业论文)基于j2ee的web+services技术研究.pdf_第1页
(计算机应用技术专业论文)基于j2ee的web+services技术研究.pdf_第2页
(计算机应用技术专业论文)基于j2ee的web+services技术研究.pdf_第3页
(计算机应用技术专业论文)基于j2ee的web+services技术研究.pdf_第4页
(计算机应用技术专业论文)基于j2ee的web+services技术研究.pdf_第5页
已阅读5页,还剩7页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

摘要 本文目的是研究如何利用w e b 服务技术构建企业s o a 。现在,s o a 不再是 抽象的软件工程术语,实现s o a 已经具有现实的技术和平台,这就是在面向服 务概念指导下,在s o a 架构模型基础上,利用w e b 服务技术开发面向服务解决 方案,构建具体的企业面向服务架构。 研究方法是从如何实现s o a 出发,对s o a 实现中的基础技术进行研究。实现 s o a 必须借助于面向服务原则、s o a 架构模型和相应的实现技术集。本文选择w e b 服务作为实现s o a 的具体技术。首先,对w e b 服务技术进行研究,尤其是w e b 服务通信框架,并对组成框架的服务角色、服务模型、服务描述和实现服务交 互的消息进行了详细分析论述。其次,详细论述了面向服务概念。在s o a 内部, 服务遵从面向服务原则,服务是自治的逻辑单位,服务设计以及服务层建模都 是构建s o a 的最关键部分。最后是对s o a 架构模型的分析研究。论述了工程上 交付s o a 过程中最重要的两个阶段:面向服务分析和面向服务设计。面向服务 分析是确定如何通过面向服务的方式来描绘业务自动化需求的过程。讨论的主 要问题是:需要构建哪些服务,以及每个服务需要封装哪些逻辑。特别地,确 定需要构建哪些服务层,以及如何完成其交付,将是形成整个面向服务环境结 构的关键。面向服务设计的阶段是指通过从逻辑的服务候选派生出具体的物理 服务设计,然后装配到实现业务流程的抽象组合中,需要实现未知的工作流定 义,将服务设计连接到一起放入流程逻辑的聚合单元。 研究的成果是构建了智能大厦o a s 软件体系结构,通过设计智能大厦的租 赁业务模块,实践了如何定义和设计服务,如何进行服务之问的消息传递。最 终提出一个面向服务架构的企业应用集成框架。 关键词:智能大厦,面向服务架构,w e b 服务 a b s t r a c t t h em a i np u r p o s eo ft h ep a p e ri st os t u d yh o wt ob u i l da ne n t e r p r i s es o a b y u s i n gw e bt e c h n o l o g y s o ai sn o ta l la b s t r a c tt e c h n i c a lt e r mf o rs o f t w a r ee n g i n e e r i n g a n ym o t en o w i m p l e m e n t i n gs o a h a sa l r e a d yas p e c i f i ct e c h n o l o g ya n dp l a t f o r m t h a ti s , ag u i d i n gs e r v i c e - o r i e n t e dc o n c e p t , t od e v e l o ps e r v i c e - o r i e n t e ds o l u t i o nb y m a k i n gu s eo fw e bs e r v i c e st e c h n o l o g ya n db u i l dt h eb a s ef o u n d a t i o ns e r v i c e s - o r i e n t e de n t e r p r i s ea r c h i t e c t u r e t h er e s e a r c hi sb a s e do nt h eb a s i c t e c h n o l o g yi m p l e m e n t i n g s o a c o n s t r u c t i n gs o ar e q u i r e st h eu o ft h es e r v i c e s - o r i e n t e dp r i n c i p l e s o am o d e la n d c o r r e s p o n d i n gt e c h n o l o g i e s ic h o o s ew e bs e r v i c e st oi m p l e m e n t i n gs o a t h i s r e s e a r c hp r o c e e d si nt h r e es t e p sa sd e s c r i b e db e l o w f i r s t , i tw i l la n a l y z ew e bs e r v i c e s w , c h n o l o g y , e s p e c i a l l yw e bs e r v i c e sc o m m u n i c a t i o nf r a m e a n di td e a lw i t hs e r v i c e r o l e ,s e r v i c em o d e , s e r v i c ed e s c r i p t i o na n dm e s s a g eb e t w e e ns e r v i c e si n t e r a c t i v ei n d e t a i l s e c o n d , i td e s c r i b e st h ed e t a i l so fs e r v i c e - o r i e n t e dc o n c e p t i nt h ei n t e r n a l s o a , s e r v i c e sc o m p l yw i t ht h ep r i n c i p l e so fs e r v i c e - o r i e n t e d s e r v i c ei st h e a u t o n o m o u sa n dl o g i c a lu n i t s d e s i g n i n gs e r v i c e sa n ds e r v i c el e v e l sa r et h em u s t c r u c i a lp a r tb u i l d i n gs o am o d e l i n g f i n a l l y , i td i s c u s s e st h es o am o d e l i n g t h e m o s ti m p o r t a n to ft h et w op h a s e sd u r i n gt h ep r o c e s so fd e f i v e r yo fs o a p r o j e c t si sa s e r v i c e - o r i e n t e da n a l y s i sa n ds e r v i c e - o r i e n t e dd e s i g n s e r v i c e - o r i e n t e da n a l y s i si st h e p r o c e s so fd e t e r m i n i n gh o w t h es e r v i c e - o r i e n t e da p p r o a c hd e s c r i b e st h ep r o c e s so ft h e b u s i n e s sa u t o m a t i o nn e e d s t h em a i ni s s u e sd i s c u s s e da r ew h i c hs e r v i c e si sn e e d e d a n dw h a tl o g i cs h o u l db ep a c k a g e di nt h es e r v i c e s i np a r t i c u l a r , w h i c hs e r v i c el a y e r i sn e e d e da n dh o wt oc o m p l e t ei t sd e l i v e r y , w o u l db et h ek e yt oc r e a t eaw h o l e s e r v i c e - o r i e n t e de n v i r o n m e n t s e r v i c e - o r i e n t e dd e s i g ni st h a td e r i v e ss p e c i f i cp h y s i c a l d e s i g ns e r v i c e sf r o mt h el o g i c a lc a n d i d a t es e r v i c e s ,a n dt h e na s s e m b l e st oa c h i e v e a b s t r a c tc o m p o s i t i o no fb u s i n e s sp r o c e s s i tn e e d su n k n o w nw o r kf l o wd e f i n i t i o na n d l i n k ss e r v i c e st o g e t h e ri n t oal o g i c a lf l o wo fp o l y m e r i z a t i o nu n i t t h ep u r p o s eo ft h ep r o j e c ti st ob u i l da ni n t e l l i g e n tb u i l d i n go a ss o f t w a r e a r c h i t e c t u r e t h r o u g hd e s i g ni n t e l l i g e n tb u i l d i n gl e a s i n gm o d u l e ,i tc a l l sf o rt h e d e f i n i t i o na n dd e s i g no fs e r v i c e sa n dh o ws e r v i c e sb e t w e e nt h em e s s a g ep a s s i n g f i n a l l y i tb u i l d s u pas e r v i c e - o r i e n t e d a r c h i t e c t u r ef o re n t e r p r i s e a p p l i c a t i o n i n t e g r a t i o nf r a m e w o r k k e yw o r d s :i n t e l l i g e n tb u i l d i n g , s e r v i c e - o r i e n t e da r c h i t e c t u r e ,w e bs e r v i c e s 此页若属实请申请人及导师签名。 独创性声明 本人声明,所呈交的论文是我个人在导师指导下进行的研究工 作及取得的研究成果据我所知,除了文中特别加以标注和致谢 的地方外,论文中不包含其他入已经发表或撰写过的研究成果, 也不包含为获得武汉理工大学或其它教育机构的学位或证书而使 用过的材料与我一同工作的同志对本研究所傲的任何贡献均已 在论文中作了明确的说明并表示了谢意。 研究生签名: 关于论文使用授权的说明 日期呈聋望:兰f 本人完全了解武汉理工大学有关保留、使用学位论文的规定, 即:学校有权保留送交论文的复印件,允许论文被查阅和借阅; 学校可以公布论文的全部内容,可以采用影印、缩印或其他复制 手段保存论文 ( 保密的论文在解密后应遵守此规定) 研究生签名:蜱导师签名姆日期幽 注:请将此声明装讨在学位论文的目录前 武汉理工大学硕士学位论文 1 1 课题研究的背景 第1 章绪论 面向服务架构( s o a ) 是当今i t 界倍受关注的主题,也是未来的发展趋势。 g a r t n e rg r o u p 预测,到2 0 0 8 年,s o a 将成为占绝对优势的软件工程技术“儿叮。 采用s o a 架构,可以更加快速、灵活的应对信息系统的调整需求。采取以往系 统架构和编码的方式,一旦有新的需求,往往存在调整周期长、费用高、重用 率低等特点,信息系统的调整需求很难得到快速充分满足。以前台软件为例, 代码成千上万行,修改一个地方,可谓是“牵一发、动全身”,难以控制产品 的质量。同时,传统的开发模式下,是通过打补丁、版本升级等方式来满足需 求的变化,导致了后来的版本混乱,软件系统过于繁杂。 s o a 是基于服务的架构,针对各个服务需求开发出相对独立的软件模块,这 些模块类似“积木”,可以更加灵活的调整和可抽换,在应对需求变化时,只 要调整相应部分组件即可。 但是,与先前的任何技术或概念相比,s o a 又是一个宏大的主题,这是i t 技术发展积累的结果,也是由它所担负的使命所决定的。同时,与j 2 e e 、n e t 等具体技术相比,s o a 更具有厂商独立性。因而,s o a 主题的研究既要继承历史, 立足现实,又要面向未来。 1 x i i l 是w e b 服务的基础“m 扩展标记语言( x 札) 由w 3 c 创建,源自流行的标准通用标记语言( s g m l ) 。 x m l 在9 0 年代后期的电子商务运动中得到普遍应用,服务器端脚本语言可以通 过互联网进行业务处理。 ) a 也不仅用于标准化的方式表达数据,其语言本身还被用作一系列的附加规 范的基础,x m ls c h e m a 定义语言( x s d ) 和x s l 转换语言( x s l t ) 都以x m l 表达。 这些规范,事实上已成为x m l 技术集的关键部分。 核心x m l 技术集提供基础数据表达和s o a 数据管理层,代表了s o a 的基础 层,x m l 建立了在服务各处流动的消息格式与结构。x s ds c h e m a s 保持消息数据 的完整性与有效性,而且x s l t 使得不同的数据在表达上可以通过s c h e m a 映射 武汉理工大学硕士学位论文 而互相通信。在s o a 内部没有x m l 会寸步难行 2 w e b 服务技术提供了s o a 的理念o 】【4 1 , 在2 0 0 0 年,w 3 c 接受了一项关于简单对象访问协议( s o a p ) 规范的提案, 这个规范本来是为统一专有r p c 通信设计的。该想法是将在组件传输的参数数 据序列化为x 札传送,然后再序列化成其原生格式。很快,公司和软件厂商开 始注意到,构建在免费互联网通信框架之上的电子商务技术日益强大的进步潜 力。这最后导致了需要创建一个纯粹的、基于w e b 的分布式技术,该技术可以 充分利用概念标准化的通信框架来桥接组织内部所存在的巨大差异。这个概念 被称为w e b 服务。 w e b 服务最重要的部分是它的公共接口,公共接口是分配服务识别并将其 激活的核心信息块。首先支持w e b 服务的是w e b 服务描述( w s d l ) 。w 3 c 接受第 一份w s d l 评议提案是在2 0 0 1 年,此后还不断地修订这一规范。 最初的s o a p 规范实现了开放互操作性的愿景,w e b 服务需要的互联网友好 的、x m l 兼容的通信格式,因此而建立了标准化的消息框架现在,“s o a p ”一 词不再代表“简单对象访问协议”的首字母缩写,在1 2 版规范中,“s o a p ”成 了一个独立的术语。 完成第一代w e b 服务标准系列的是u d d i 规范,它最初由u d d i o r g 开发。 该规范考虑了组织内部和组织边界之外创建标准化服务描述的注册。u d d i 提供 了对w e b 服务在集中位置注册的潜能,使服务请求者可以在这个集中位置发现。 与w s d l 和s o a p 不同,u d d i 尚未被工业界普遍接受,而是保留了一个可选的s o a 扩展。 开发自定义的w e b 服务可以适应变化的业务需求,而且第三方市场还出现 了促进各种实用服务的销售或租赁。 3 s o a 成为企业架构的必然嘲 很多组织意识到w e b 服务可以成为一种独立的架构平台的基础,不仅仅是 提供现有的分布式应用;这一平台可以充分利用那些用来在企业中实现服务概 念的w e b 服务技术集的效益。因此,面向服务架构开始成为i t 的主流。 s o a 分类通常取决于构建服务所用的实现技术。早期的模型主要从w e b 服务 标准系列中得到启发,将s o a 定义为一个围绕三个基本组件的架构模型:服务 请求者,服务提供者和服务注册。 第一代w e b 服务标准实现该模型三个部分: 2 武汉理工大学硕士学位论文 ( 1 ) u s d l 描述服务。 ( 2 ) s o a p 提供用于服务及其请求者的消息格式。 ( 3 ) u d d i 提供标准化的服务注册格式。 第一代w e b 服务架构来自关键标准的开发:w s d l 、s o a p 和u d d i 。虽然u d d i 对大多的数据环境而然仍然是一个可选的发现机制,而w s d l 和s o a p 己成为构 建在x l i l 层之上定义s o a 基本通信框架的核心技术。 所有主要厂商的开发及运行平台都支持该模型。并且这些厂商都有关于s o a 的远大计划。由此产生了一系列第一代w e b 服务平台的扩展。著名的是。第二 代”或“w s 一卑”规范,这些扩展处理特殊的功能区域,其整体目标是将w e b 服 务技术平台全面提升至企业水平。 s o a 充分利用x m l 和w e b 服务事先奠定的基础,它将久经考验的概念与先进 技术相结合,这些已为i t 社团充分接受。 1 2 课题研究的意义 研究w e bs e r v i c e s 技术是为了学习如何用w e b 服务构建s o a ” s o a 是一个广泛的主题,它代表包含一系列当代技术的新一代架构平台( 专 属的和厂商独立的) 实现s o a 有不同的途径和技术,w e b 服务平台提供了众多 实现s o a 形式中的一种。 w e b 服务驱动了s o a 正在全球范围内替代传统的分布式架构。s o a 涵盖基本 的w e b 服务理论,研究x m l 和w e b 服务技术无疑对构建s o a 很有帮助。面向服 务需要业务与应用逻辑在检视、分割和自动化方面有所改变,因此也需要依照 特定原则来使用和设计w e b 服务。w e b 服务易于融入现存的传统分布式架构,可 以处于中心位置并承担重要的处理职责,或者会被附以外围应用点。s o a 中所用 到的w e b 服务方式各不相同,重点在于业务逻辑封装和服务抽象层的创建。 实际上,s o a 就是为了解决一些系统之间交互难的问题,比如说企业原来有 几个系统,e r p 、c 跚之间要整合,但这些系统可能是o r a c l e ,s q l s e r v e r 等,数 据库的结构都不一样,包括一些银行原来用的是比较老的应用系统,如用c o r b a 开发的,交互会很困难。现在提出s o a 的策略以后,如果想进行两个系统的整 合,事情就变得简单多了。 假如一个系统可以提供3 种服务,首先把这三种服务定义出来,这三种服 3 武汉理工大学硕士学位论文 务各有一个对外的接口,就是说如果需要某种服务的时候,需要用特定的格式 来申请,然后系统用特定的格式来反馈,至于内部是怎样实现的并不关心,对 外就是三种服务。举个例子来说,这个系统是个很老的银行系统,有一种服务 是查询帐户余额,那么需要用户提供用户名、密码、帐号这三个信息,然后系 统反馈一个数字,就是这个帐户余额,内部怎么操作不用去管,对外的公布就 是可以提供一种这样的服务。这就是一个基本的s o a 应用。 如果每个系统都可以实现这种功能,那么就不用去管具体是哪种语言、哪 种平台、哪种系统,只要提供相应的接口,系统之间都可以实现交互了 1 3 论文组织结构 本论文按照下面章节组织。 第一章绪论,主要概述了本课题研究的背景,面向服务架构发展的过程。 第二章w e b 服务与s o a ,主要论述了早期的w e b 服务技术,这些技术现在 是面向服务架构的基础。还对什么是s o a 服务进行了介绍,以及如何进行服务 的设计。最后对w e b 服务和s o a 服务进行了对照分析,以澄清一些概念,s o a 服 务并不是简单的w e b 服务。 第三章面向服务分析与设计,服务的分析与设计是成功建立面向服务架 构的关键环节。首先对如何成功交付一个s o a 架构的软件系统周期进行了介绍。 接着是对面向服务分析的详细论述,服务是整个s o a 的灵魂,已经有许多可借 鉴的分析方法和步骤,尤其是对服务进行建模,既要考虑业务流程,又要考虑 软件工程的方法学。最后是面向服务设计,在成功的服务建模的基础上如何对 系统进行设计,在这里介绍了不同的设计方法,从不同的侧面进行全面介绍。 第四章智能大厦o a s 的面向服务架构设计首先,对面向服务架构的通用 平台进行了介绍,s o a 不是一个抽象的概念,已经有厂商支持,有具体的开发平 台。设计了智能大厦系统的面向服务架构,并且,以具体的租赁业务为例,对 在s o a 架构上的软件系统如何实现具体的业务进行了分析与设计,这是服务之 问的通信与协作。 第五章结束语总结了本论文做出的工作成果,即构建了智能大厦o a s 的 软件体系结构,实践了服务的定义与设计。最后展望了s o a 发展的未来趋势。 4 武汉理工大学硕士学位论文 第2 章f f e b 服务与$ o a 2 1f f e b 服务框架 w e b 服务的基本功能是让计算机系统之间和应用系统之间互相连接,共享 服务。技术框架是一个集合,它可包括一个或多个架构、技术,概念、模型甚 至子框架。由w e b 服务建立的框架包括了所有这些部分“蚰日 第一代w e b 服务技术和第二代w e b 服务扩展( 也称为w s 一半) ,连同与设计 无关的概念和实现中立的架构,共同形成了一个抽象的w e b 服务框架。该框架 具备以下特征: 1 由标准组织定义的抽象的实体,且由( 专有) 技术平台实现 2 包括w e b 服务、服务描述和消息的核心构件 3 围绕基于w s d l 的服务描述的通信协议 4 包括s o a p 技术和概念的消息框架 5 服务描述注册和有时通过u d d i 实现的服务发现架构 6 支持消息模式与组合的良好定义的架构 7 第二代w e b 服务扩展不断扩展其根本特性集 2 2f f e b 服务 每个w e b 服务都可以关联于临时分类和永久分类。 临时分类是基于它在消息的运行时处理期间所承担的角色划分。 永久分类是基于它提供的应用和它在解决方案环境中所承担的角色划分。 相应地,研究w e b 服务可从服务角色( 临时分类) 、服务模型( 永久角色) 、 如何描述服务和服务之阿如何进行通信这些方面进行研究“”。 2 2 1 服务角色 w e b 服务可以担当不同的角色,这取决于使用的语境。没有将服务独立于客 户机或服务器,而是作为能够转换角色的软件单元。在给定的业务任务中,w e b 5 武汉理工大学硕士学位论文 服务不止一次变换角色,对s o a 内的w e b 服务而言,在不同的业务任务中担当 不同角色尤为正常。 w e b 服务有服务提供者、服务请求者、中介或中介服务三种服务角色。 1 服务提供者 w e b 服务在下列条件下承担服务提供者角色: ( 1 ) w e b 服务由外部资源调用,如服务请求者。 ( 2 ) w e b 服务提供发布的服务描述,并给出其特征和行为信息。 2 服务请求者 任何能够处理可被服务提供者理解的请求消息的处理逻辑单元,都可归为 服务请求者。最好将服务请求者看作是发起带有服务提供者会话的软件程序。 w e b 服务是服务提供者,但也可以担任服务请求者w e b 服务在以下环境下承担 服务请求者的角色: ( 1 ) w e b 服务通过给提供者发送消息来调用服务。 ( 2 ) w e b 服务通过研究可用的服务描述来搜寻并评估最合适的服务提供 者。 3 中介服务 w e b 服务通信使用消息路径为基础。在最初发送者以及到达最终目标前将转 发和处理消息的w 曲服务以服务代理看作中介或中介服务。中介的角色总是在 服务提供者和服务请求者之间转换。 中介有两种类型。一种是被动中介,典型地负责转送消息到下一个位置, 它不对消息做任何修改。它可能根据s o a p 消息中的报头信息决定转发路径,或 可能采用内定的路由逻辑转发消息。另一种是主动中介,在传输消息时,它主 动处理并改变消息内容。主动中介将寻找特殊的s o a p 报头条目并执行一些动作 以响应在此找到的消息。主动中介几乎都要改变报头条目数据,并有可能插入 甚至删除整个报头条目。 图2 1 示意了w e b 服务通信的基本框架。 6 武汉理工大学硕士学位论文 图2 iw e b 服务通信的消息路径和角色转换 4 服务组合 任何服务能召集一个或多个其他服务来完成特定任务,任何被召集的服务 都能调用其他服务来完成特定的子任务。因此,参与组合的每个服务承担服务 组合成员的角色。 通常,需要以服务组合的思想设计w e b 服务以便成为有效成员。面向服务 原则特别强调可组合性,允许将一些w e b 服务设计成这种方式,以便能将它们 纳入未知的未来服务组合中 2 2 2 服务模型 服务角色是w e b 服务在普通语境内可以执行的普通状态。然而,服务在真 实世界中的使用方式,已经导致对基于它们提供的应用逻辑性质和在整体解决 方案内与业务相关的角色进行分类。这些分类称为服务模型“”。 服务模型代表了服务驻留逻辑的永久分类,还有其在全部解决方案内的角 色。服务可以属于不止一个服务模型。 1 业务服务模型 在s o a 内,业务服务代表最基本的构件。它封装了一个定义完整的功能范 围内的独特业务逻辑集。业务服务充分自治却不限于以孤立的方式执行,时常 需要业务服务参与服务组合。 业务服务在s o a 内有以下用途: ( i ) 作为表达业务逻辑的基本构件 7 武汉理工大学硕士学位论文 ( 2 ) 代表企业实体或信息集 ( 3 ) 代表业务流程逻辑 ( 4 ) 作为服务组合成员 业务服务可以作为控制器组成工具应用服务。 2 工具服务模型 任何设计用于潜在复用的w e b 服务或服务代理都可归为工具服务 工具服务在s o a 内有以下用途: ( 1 ) 在s o a 内作为激发复用特征的服务 ( 2 ) 作为未知的解决方案的中介服务 ( 3 ) 作为促使s o a 的内在互操作性特性的服务 ( 4 ) 作为具有最高程度自治的服务 3 控制器服务模型 服务组合包括一组独立的服务,每个都对整个业务任务的执行有所贡献。 这些服务的组装和协调经常是其自身的任务,并且被安排为专门服务的主要功 能,或者作为可以独立充分执行业务的服务的次要功能。控制器服务充当了这 个角色,负责服务组合成员的父服务。 在s o 内控制器服务具有以下用途: ( 1 ) 支持并实现可组合性原则 ( 2 ) 利用复用机会 ( 3 ) 支持其他服务的自治 控制器服务本身可以成为从属的服务组合成员,组合通过控制器进行协调, 完整地形成一个更大的组合。 2 2 3 服务描述( 用w s d l 语言) 服务描述用w s d l 语言定义,w s d l 描述服务提供者的服务端点,它提供正式 的端点接口定义并且建立了服务的物理位置( 地址) 。每个服务请求者都在使用 服务提供者的w s d l ,以确保所发送的消息可以被理解和接受。 如图2 2 所示的w s d l 栈“加”,w s d l 服务描述可分为两类:抽象描述和具体 描述。 1 抽象描述 抽象描述建立了w e b 服务的接口特征,而无需参考任何用于驻留或者促成 8 武汉理工大学硕士学位论文 w e b 服务传输消息的技术。通过分离这个信息使得不管底层技术平台发生任何改 变,都能保证服务描述的完整性。 2 具体描述 为了使w e b 服务能执行其任何逻辑,需要将其抽象接口定义连接到一些真 实的、可实施的技术上。服务应用逻辑的执行要包括通信,抽象的w e b 服务接 口需要与物理传输协议连接。这个连接定义成w s d l 文件的具体描述部分,它包 括三个相关部分:绑定、端口和服务。 绑定描述了服务建立物理连接或者用服务建立连接的需求。绑定代表服务 用来通信的一种可能的传输技术。s o a p 是常见的绑定形式,但也支持其他形式。 与绑定相关的是端口,它代表可以以特定协议访问的服务的实际地址。在 w s d l 语言中,术语服务用于指一组相关的端点。 具体执行程序: 抽象界面; 图2 2w s d l 栈 9 武汉理工大学硕士学位论文 3 元数据与服务契约 由w s d l 定义提供的抽象与具体描述,表达了关于服务如何交互和它支持什 么类型的数据交换的技术信息。 w s d l 定义常用x s ds c h e m a 来格式化进入和外出的消息。用策略提供规则、 首选项,并处理上述细节,甚至超越w s d l 和x s ds c h e m a 文档所表达的细节。 w s d l 定义、x s os c h e m a 和策略这三个独立的服务描述文档都可归为服务元 数据。这三个服务描述文档都提供了关于服务的信息,共同建立了一个服务契 约,必须由潜在的服务请求者遇到和接受该条件集,以促成成功通信。 4 服务描述广告和发现 服务联系另一个服务的唯一需求就是访问其服务描述:定位己知服务描述 的最新版本和发现适合某种准则的新w e b 服务。 当组织内部和外部的服务数量增加时,就最终会形成一个服务池。把服务 通过私有或公有注册到相应服务池来管理w e b 上提供的服务。利用公有或私有 服务注册,服务描述能被人工或应用动态发现。 2 2 4w s d l 语言 1 w s d l 相关的x 札s c h e m a 语言嘲 x m ls c h e m a 定义语言( ) 眦s c h e m ad e f i n i t i o nl a n g u a g e ,x s d ) 是x m l 和 w e b 服务规范的固有部分,并且对于我们要求用于构建为面向服务设计过程的一 部分的服务接口定义语言而言是关键。通过创建x s ds c h e m a 能够正式地定义x 札 文件的层次结构,因此认为x m l 文件是其相应模式的一个实例。 在x s ds c h e m a 中建立的结构包含了一系列规则和约束。由x s ds c h e m a 提 供的基础数据表示规则涉及到根据类型来表示数据。根据在程序设计语言中使 用的数据类型,x s ds c h e m a 提供了一套用于表示x m l 文件实例中的信息的非专 有的数据类型。x s ds c h e m a 所支持的数据类型是可扩展的,但是它们并不总是 能够清晰地映射到程序语言所使用的专有类型。 x s ds c h e m a 可以作为独立的文档存在,或者可以将它们嵌入到其他类型的 文件中,如x m l 文档实例或者w s d l 定义。由于几乎所有的x m l 和w e b 服务规范 本身都是以x m l 编写的,x s ds c h e m a 已经变成了x m l 数据表示和面向服务架构 的固有组成部分。 2 w s d l 语言 1 0 武汉理工大学硕士学位论文 w e b 服务描述语言是服务设计相关的最基础的技术标准。w s d l 定义是服务 设计所有方面的核心部分,是服务设计的重点,用于设计抽象和具体的服务接 口定义。同时,w s d l 定义包含了多个与服务描述的抽象部分和具体部分相关联 的子结构。 图2 3w s d l 定义的结构 w s d l 定义结构是一段x m l 文档。它由元素按照一定的格式组成。文档的 根元素或是父元素是d e f i n i t i o n 元素,它涵盖了所有其他部分的服务定义并且也 是建立w s d l 文档中使用的很多命名空间的特定区域。 ( 1 ) 抽象服务定义 用于抽象服务定义的元素完成服务接口的描述,但是没有引用任何消息通 信技术手段。 在图2 3 中,t y p e s 结构是x s ds c h e m a 内容放置的地方。这部分w s d l 可 1 1 武汉理工大学硕士学位论文 以构成实际的x s ds c h e m a 标记( 整个s c h e m a 结构包含类型定义) ,或者它包 含i m p o r t 元素能够引用外部的s c h e m a 定义。 m e s s a g e 结构定义抽象的s o a p 消息体。该元素为消息赋予名称并包含一个 或多个p a r t 子元素,它们每一个都被赋予一个类型。m e s s a g e 元素随后和 o p e r a t i o n 元素相关联以建立操作的输入和输出消息 p o r t t y p e 结构简单地代表操作集,服务操作在该区域中定义。单个操作采用 适当命名为o p e r a t i o n 的元素来定义。在w e b 服务描述语言的1 1 版本中定义有 p o r t t y p e 元素,该规范的2 o 版本该元素的名称更改为i n t e r f a c e ( 2 ) 具体定义 b i n d i n g 元素开始了服务定义的具体部分,赋予了可用于w s d l 访问和交互 的通信协议。b i n d i n g 结构包含了一个或多个o p e r a t i o n 元素,s o a p :b i n d i n g 与s o a p : o p e r a t i o n 元素作为建立s o a p 协议的方式,通过该方式w s d l 能够与之通信。 s e r v i c e 元素简单地提供了服务能够访问到的物理地址该位置信息包含在 它的子元素p o r t 元素中。由于绑定了s o a p 协议,所以p o r t 元素包含一个具有 物理地址信息的s o a p :a d d r e s s 子元素。 2 2 5 消息( 以s o a p 规范) 服务间的所有通信都基于消息,因此消息框架必须是标准化的,以便于所 有的服务,不论其来源,都使用同一种格式和传输协议。在s o a 内部,着重强 调以消息为中心的应用设计,以便于逐渐增长的业务和应用逻辑能嵌入到消息 中。服务的消息接收是s o a 内的最基本行为,并且是发起面向服务自动化的唯 一行为。 s o a p 消息规范定义了标准的消息格式,这种格式的构造十分简单,但它的 扩展和定制能力已使s o a p 消息成为许多当代s o a 最重要特征背后的强大驱动 力 1 s o a p 消息的基本构造 s o a p 是主要的消息标准,用于定义服务通信所要求的消息。 武汉理工大学硕士学位论文 图2 4s o a p 消息的基本构造 每个s o a p 消息都会打包到称为封套的容器中。消息包含报头、正文。报 头是表达宿主消息信息的区域。在大多数面向服务的解决方案中,报头部分是 整个架构的必要部分,虽然是可选的,但很少忽略它。其重要性是通过报头条 目可以实现众多扩展。实际的消息内容驻留在消息体,消息体典型地包括含有 x m l 格式化数据。消息体的内容称为消息有效载荷。 s o a p 消息文档由父e n v e l o p e 结构组成,它宿主必需的b o d y 结构和可选的 h e a d e r 与f a u l t 结构。w s d l 定义使用x s d 类型定义和验证s o a p 消息的b o d y 结 构的内容。 1 x s ds c h e m a 、w s d l 和s o a p 的关系 武汉理工大学硕士学位论文 s o a p 消息 图2 5x s ds c h e m a 、w s d l 和s o a p 消息三者关系示意图 1 4 武汉理工大学硕士学位论文 图2 5 中,在w s d l 的抽象定义中,由x s ds c h e m a 类型构成w s d lt y p e s 结 构,m e s s a g e 结构用t y p e s 类型来表示s o a p 消息体b o d y 结构。但是,通过消息 路径的s o a p 消息的实际处理由具体定义中的结构来监管。在s o a p 消息的传输 过程中s o a p 报头条目能够得到积极地处理,不会涉及s o a p 消息体。 2 3s o a 服务 面向服务架构( s o a ) 鼓励单个逻辑单元自治而不孤立嘲1 。逻辑单元要遵从 允许其独立的一系列原则,同时充分维护其通用性和标准化。在s o a 内部,这 些逻辑单元称之为服务。 2 3 1 服务如何封装逻辑 服务在独特的语境中封装逻辑,该语境可能特定于某一业务任务、业务实 体或一些其他逻辑组。对于封装逻辑的服务而言,它们可以参与业务活动的执 行。这些服务必须与其他使用者形成清晰的关系。 当构建一个包含服务的自动化解决方案时,每种服务都可封装为一个由单 独步骤执行的任务或包含一系列步骤的子过程。服务甚至可以封装整个逻辑。 2 3 2 服务如何关联 在s o a 内部,服务可以用于其他服务或程序。服务之间的关系应基于对服 务交互的理解,它们之间必须相互知晓。这个知晓通过w s d l 服务描述获得。最 基本的服务描述确定了服务的名称和服务的位置,以及要求交换的数据。服务 用服务描述的方式导致了松散耦合的分类关系。 2 3 3 服务如何通信 服务为了相互作用并完成任务活动而必须交换信息。需要一个可以保留其 松散耦合关系的通信框架,这样的框架是消息传递。服务以自己的方式发送一 个消息之后,它对消息此后所发生的一切都将失去控制。因此,消息是作为“独 立的通信单元”存在,消息和服务一样都是自治的。 武汉理工大学硕士学位论文 2 3 4 服务如何设计 面向服务是独特的设计方法,引入通用的原则来控制架构组件的配置与设 计。面向服务原则对处理逻辑的应用形成了标准化的面向服务处理逻辑。当一 个解决方案由面向服务的处理逻辑单元组成时,就成为所谓的面向服务解决方 案。 面向服务原则的关键方面是: 松散耦合服务维护了最小的依赖关系,并且仅需要保持相互间的知晓。 服务契约服务都应遵守一个通信协议,由一个或多个服务描述及相关文 档共同定义 自治服务已经控制了其所封装的逻辑。 抽象超出服务契约的描述之外,服务对外部世界隐藏了逻辑。 复用性将逻辑分成服务以便促进复用。 组合性可以对服务的集合进行替换并组装以形成组合服务。 无状态性服务保留了最少的服务特定信息。 可发现性服务的直观描述设计,从而可以通过发现机制来发现何评估服 务。 图2 6 面向服务原则提出的设计问题 武汉理工大学硕士学位论文 2 3 5 服务层 企业模型中,服务接口层位于业务流程与应用层之间。这是服务连通的所 在,也是企业中s o a 特征最常出现的地方。 1 服务层解决的问题 服务层解决的问题是:什么逻辑应当用服务来表示;应当如何将服务关联 到现有应用逻辑;如何用服务最佳地表示业务流程逻辑;如何能够构建服务与 定位以促进敏捷。 ( 1 ) 什么逻辑应当用服务来表示 企业逻辑分成两个主要领域:业务逻辑与应用逻辑。建模时可以用任何一 种或两种逻辑来表示服务,只要能够应用面向服务原则。然而,要达到企业范 围的松散耦合实际上需要服务的物理分层。当各个服务共同代表公司的业务逻 辑及特定技术的应用逻辑时,企业的每个领域就不再直接依赖于其他部分。 允许业务流程逻辑的自动化表示,从而进化到与负责其执行的技术层面应 用逻辑分离,即建立了业务逻辑与应用逻辑间的松散耦合的关系。 ( 2 ) 应当如何将服务关联到现有应用逻辑 大多数依靠现有遗留应用逻辑是否需要通过服务暴露、或开发新逻辑以支 持服务。对现有系统能够施加任何数量的约束、限制以及环境的需求,这在服 务设计时都要加以考虑。在遗留应用环境之上,应用服务层可能需要对一些面 向服务原则做折衷的考虑。这与开始按意愿中的服务层建立解决方案有所不同, 因为那样可用控制面向服务直接组合应用逻辑。 以任一方式特别设计代表应用逻辑的服务都应当以一个单独的层存在,将 这组服务归属为应用服务层。 ( 3 ) 如何用服务最佳地表示业务流程逻辑 业务逻辑被定义在一个组织的业务逻辑模型与业务流程之内。当用服务建 模代表业务逻辑时,最重要的是确保代表逻辑的服务与现有业务模型联盟。以 这种方式分门别类地设计服务,将涉及代表业务逻辑的服务归属为业务服务层。 通过增加业务服务层,实现支持面向服务的业务建模。 ( 4 ) 如何能够构建服务与定位以促进敏捷 构建敏捷s o a 的关键在于:尽量减少已拥有处理逻辑的服务间的依赖性。 包含业务规则的服务需要在运行时加强对这些规则的遵循。这限制了服务利用 1 7 武汉理工大学硕士学位论文 这些规则之外环境的能力。同样,需要编写嵌入逻辑的控制器服务的其他服务 时,可以依赖组合结构来开发。 在更多专门的服务层之上引入父控制器层,可以为业务规则确定一个集中 位置,并编写与服务执行序列相关的逻辑。编排就是为该目标而专门设计的。 它引入了流程服务的概念,能够组合其他服务来根据预先确定的工作流逻辑完 成业务流程。流程服务建立了编排服务层。 加入编排服务层在很大程度上提升了组织敏捷性,但它却不能独自实现这 个品质。服务抽象的所有组织形式都有助于建立敏捷企业,这意味着创建分离 的应用、业务及编排层共同实现这个特征。 2 服务层抽象 通过利用组合的概念来建立专门的服务层,每一层均能抽象解决方案的一 个特殊方面,定位我们所标识的问题。s o a 的三个常见层是应用服务层、业务服 务层和编排服务层。 ( 1 ) 应用服务层 应用服务层建立了用来表示特定技术功能的底层基础。位于这一层的服务 可以简单地称为应用服务。应用服务负责表示技术与应用逻辑。应用服务层的 目的是要在新的或遗留应用环境之内提供处理数据相关的可复用功能。 应用服务可分成不同类型的服务模型类别,代表一组特定技术的功能,因 此,应用服务可以是一个工具服务、包装服务或者其他类型。 ( 2 ) 业务服务层 业务服

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论