(控制理论与控制工程专业论文)基于xml的消息队列中间件的设计与实现.pdf_第1页
(控制理论与控制工程专业论文)基于xml的消息队列中间件的设计与实现.pdf_第2页
(控制理论与控制工程专业论文)基于xml的消息队列中间件的设计与实现.pdf_第3页
(控制理论与控制工程专业论文)基于xml的消息队列中间件的设计与实现.pdf_第4页
(控制理论与控制工程专业论文)基于xml的消息队列中间件的设计与实现.pdf_第5页
已阅读5页,还剩63页未读 继续免费阅读

(控制理论与控制工程专业论文)基于xml的消息队列中间件的设计与实现.pdf.pdf 免费下载

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

文档简介

摘矍 摘要 计算机网络环境的f 益复杂使分布式网络通信面临着巨大的挑战。消息中 间件技术是分布式网络通讯问题的最好的解决方法。它所创建的客户机中间件 服务器三层分布式计算模型已经成为网络应用的主流。为此本文研究并实现 了一个应用于客户n 务器模式的基于x m l 的消息队列中间件系统。 首先,在综合分析客户机服务器模型中通信系统整体要求的基础上,引入 了可扩展标记语言,制定了一个适用于异步、低可靠网络环境的跨平台消息传 输协议,用以封装所有传输在t c p i p 套接字上的数据。 其次,设计了可靠的消息队列,并采用平均加权算法对消息进行排队,支 持优先级机制。 最后,完成了消息中间件的体系结构设计,将其划分为传输模块、队列管 理模块、安全模块和日志模块。整个系统采用事件驱动设计,并综合了异步输 入输出、反应器模式和对象池技术,给出了各模块的具体实现。 本系统屏蔽了客户机n 务器模式中的网络通信细节,给用户提供了简单方 便的应用程序接口,实现了低可靠性网络通信的异步性和安全性,具有可移植 性和可伸缩性,适用于企业级三层或多层客户机n 务器应用程序的开发。 关键字面向消息中间件 消息传输协议 消,自、队歹j 可扩展标记语言 客户n 务器模式 事件驱动 a b s t r a c t w i t ht h er a p i dd e v e l o p m e n to fc o m p u t e rn e t w o r kt e c h n o l o g y , d i s t r i b u t e d a p p l i c a t i o ns y s t e m sh a v e b e e nw i d e l yu s e d b u tt h e ya r ei n s u f f i c i e n tt os a r i s f y t o d a y sc o m m u n i c a t i o nr e q u i r e m e n t sw h e nt h en e t w o r ke n v i r o n m e n ti sm o r ea n d m o r ec o m p l i c a t e d a sa ne f f i c i e n tw a y , m e s s a g e - o r i e n t e dm i d d l e w a r e ( m o m ) c a n s o l v et h ed i s t r i b u t e dn e t w o r kc o m m u n i c a t i o n p r o b l e m s i nt h i sd i s s e r t a t i o n , x m l b a s e dm e s s a g eq u e u i n gm i d d l e w a r es y s t e mi sp r o p o s e d f i r s t ,x m lt e c h n i q u ei sa d o p t e dt oe x p r e s sm e s s a g ea sx m ld o c u m e n t a t i o n t o s a t i s f yt h er e q u i r e m e n t so fc sn e t w o r kc o m m u n i c a t i o ns y s t e m ,am e s s a g e t r a n s p o r tp r o t o c o li sb r o u 曲tf o r w a r df o rp a c k a g ea n dt r a n s p o r to fa l lt h ed a t ao v e ra s t e a d yt c ps o c k e t ,w h i c hi sa p p l i e dt o a s y n c h r o n o u s ,s e 、c ,u r e a n dr e l i a b l e c o m m u n i c a t i o n s t h e n ,ap r i o r i t ym e s s a g eq u e u ei sd e s i g n e d ,a n dw e i g h t e df a i rq u e u i n g ( w f q ) a l g o r i t h mi su s e df o rm e s s a g e sq u e u i n g f i n a l l y , t h ea r c h i t e c t u r e o ft h em e s s a g e - o r i e n t e dm i d d l e w a r ei s p r e s e n t e d , w h i c hi sc o m p o s e do ft r a n s f e rm o d u l e ,q u e u em a n a g e rm o d u l e ,s e c u r em o d u l ea n d l o gm o d u l e m o mh i d e st h ed e t a i l so fn e t w o r kc o m m u n i c a t i o n ,a n dp r e s e n t sa na p if o r a p p l i c a t i o np r o g r a m m e r st of a c i l i t a t em e s s a g ee x c h a n g ei na l la s y n c h r o n o u sa n d s e c u r es t y l e f u r t h e r m o r e ,i ta c h i e v e sl o o s e l yc o u p l eb e t w e e nc l i e n ta n ds e r v e rv i a m e s s a g eq u e u e m o mi sp u ti n t op r a c t i c et od e v e l o pe n t e r p r i s es c a l et h r e e t i e r ( o r m o r e ) c l i e n t s e r v e ra p p l i c a t i o n s k e yw o r d s : m e s s a g e o r i e n t e dm i d d l e w a r e ( m o m )m e s s a g eq u e u e e x t e n s i b l em a r kl a n g u a g e ( x m l )c o m m u n i c a t i o np r o t o c o e v e n td r i v e n c l i e n t s e r v e r ( c s ) 绪沦 第一章绪论 1 1网络应用模式的发展 迄今为止,网络计算机模式的发展经历了3 个阶段: 1 )以大型机为中心的计算模式:称为分时共享模式,他是采用大型机 作为主机并配备多个终端组成一个系统。这种模式是利用主机的能力,主机 是系统的核心,一旦主机出了故障,整个系统便瘫痪。 2 1以服务器为中心的计算模式:称为资源共享模式,它通过网络将多 台计算机相连,以实现资源共享。这种模式是利用各站点的能力对所有应用 进行运行,用服务器的能力作为外设的延伸。 3 )c l i e n t s e r v e r 计算模式:在基于两层客户服务器模型的应用中,数 据统一存储在数据服务器上,而有关的业务逻辑都在客户端实现,即所谓胖 终端的解决方案。随着c s 模型的发展,许多公司逐渐认识到两层体系结构 的局限性。这些局限性如下: 应用程序层与层之间通信效率低下 不能划分应用逻辑 安全性差 可扩展性差 可移动性差 中i n j 件技术为c s 计算机应用模式带来了。次革新。它在原有的两层模型 中插入了一个中间层,该中间层提供业务逻辑处理、消息队列、进程运行和数 据传输等服务来满足大量用户同时访问的需求。中间件技术的产生为两层c s 模型应用向三层乃至n 层分布式应用的转移提供了重要的支持【l 】。现在,中 间件技术所创建的客户中间件服务器这样一种三层分布式计算模型已经成为 网络应用的主流。 绪论 1 2 分布式网络通信面临的挑战 网络应用程序,经历了从简单到复杂,从集中到分布的演变。大型分布式 应用程序的构建和维护却是一件十分复杂的事情,尤其是不同应用程序| - b j 的通 信。随着网络环境的同益复杂,网络中的通信问题同趋严重。主要表现在两个 方面: 1 在大型的分布式网络应用中,不同的应用运行在不同的进程中分布在不 同的计算机上,甚至跨系统,跨网络,如何将这些应用有效的集成,使不 同的应用能够保持良好的通讯,真f 发挥分布式应用的巨大优越胜。这一 点成为衡量一个网络应用是否可靠,是否稳定的重要标准【2 】。 2 大多数传统的通信技术要求发送和接收应用程序必须满足两个条件【l 】: 一是他们同时在线: 二是通过网络能同时通信,发送者和接受者必须知道相互间程序的调用 接口。 这就要求,一个应用程序一旦有任何接i d 变化,都必须通知其他应用程序。为 了保持数据的完整性,发送和接收应用程序通常使用分布式业务,以确保任一 方应用程序数据的改变能被双方承认。然而,在分布式网络应用中,实际情况 是: 应用程序并不总是同时运行; 网络,尤其是广域网,并不总是可用和可靠的。 网络的硬件故障往往不可避免:数据的流量具有突发性,可能造成网络的 信息捌塞;某个应用需要立即得到处理,而另外一个却可以缓一缓,他们应当 区别对待:这样一来,应用之间的异步通讯问题变得非常突出。 1 3 课题的提出 消息中间件是解决这些问题的最好方法。消息中间件指的是利用高效uj _ 靠 的消息传递机制进行平台无关的数据交流,并基于数据通信来进行分伽式系统 的集成。通过提供消息传递和消息排队模型,它可在分布环境下扩展进程| 白j 的 通信,并支持多通汛协议、语言+ 、应用程序、硬件利软件平台。 2 绪论 在此背景下,本文的主要任务是一个基于c s 模式的消息队列中间件 j x m o m 的设讨与实现。 中间件支持下的应片j 程序从逻辑上可划分为两个部分,一部分负责程序的 t 体,另一部分负责访问中问件。这种逻辑上的划分十分有利于分布式c s 环 境下的程序编写。无论数据或服务处于多少个运行着不同操作系统的主机j 二 丌发者不用编写传输层指令到每个应用程序中,只需在其软件中写入一些筒啦 的指令,来调用中i a j 件提供的a p i 函数,中间件就会迅速、有效的在心用程序 和各种操作系统、通信协议或数据库系统之问建立起一道桥梁,使c s 环境发 挥出最佳效能【1 6 】。 中间件领域目前最热门的技术是异步的消息中间件。消息中间件将消息从 一个应用发送到另一个应用时,使用消息队列作为一个过渡。客户应用的消息 被消息中间件送到一个队列中,并且一直被保存在其中,直到服务应用将他们 取走为止。实际上,消息队列中发给服务应用的消息,服务应用可以在任何时 候取走他们。此外,服务进程可以以任意的顺序取走消息,能够很好的支持优 先级或负载均衡机制。 消息中间件可以提供一定级别的容错能力,这种容错能力一般是采用持久 性的队列来保存消息,这种队列在系统崩溃并重新启动后,能自动的重新回复 消息队列中的消息,这样,在系统故障时仍能保证下的正常传输。 总的来讲,消息中间件的作用体现在两个方面:一是集成大型的分布式应 用;二是确保分布式应用之间的通信,提供可靠的和松散耦合的通信服务。 1 4 本课题的内容 针对分布式应用通讯中存在的问题,本文主要做了一下几方面的工作: 1 重点介绍了消息中间件的原理、分类及功能,讨论了j a v a 、x m l 等相关技 术。 2 在综合分析了c s 模型中通信系统整体要求的基础上,从系统层的角度出 发,提出了一个异步的、r ,j 靠的、安全的、跨平台的数据传输协议j x m t p 。 包括引入x m l 定义消息格式、采用t c p 连接、加速提不设汁以及安全f ! l f j 、 绪沦 商过程。 3 设计了一种可同时读写的消息队列j x m q ,在综合分析了f i f o 、支持优先 级、m f q 算法的基础上,提出了一种改进的m f q 算法用于消息排队。 4 在j x m q 的基础上提出了j x m o m 的体系结构,将其划分为传输漠块、队 列管理模块、安全模块和日志模块几个不同的功能模块,并给出各个模块 的具体实现。 5 总结了j x m o m 的特点并指出下一步的改进工作。 相关技术背景 2 1中间件 第二章相关技术背景 2 1 1 中间件的定义 中间件就是一个位于应用程序和由异构平台和协议组成的网络层之间的通 用服务系统,具有标准的程序接1 :3 和协议,可实现不同硬件和操作系统平台上 的数据共享和应用互操作,并使商业应用程序与异构操作系统、硬件平台和通 信协议解耦合。如图2 一l 昕示。 图2 1 :消息中i 司件 由于标准接口对于可哆殖性和标准协议对于互操作性的重要性,中间件已 成为许多标准化工作的主要部分。对于应用软件开发,中间件远比操作系统和 网络服务更为重要,中阍牛提供的程序接口定义了一个相对稳定的高层应用环 境,f :管底层的计算机硬斗和系统软件怎样更新换代,只要将中间件升级更新, 并保持中问件对外的接【二= 定义不变,应用软件几乎不需任何修改,从而保护了 企业存应用软件丌发和维护中的重大投资。【l 】 相关技术背景 2 1 2 中间件的分类 中阳j 件所包括的范围十分广泛,针对不同的应用需求涌现出多种各具特色 的中间件产品。但是至今中问件还没有一个比较精确的定义,因此,在不同的 角度或不同的层次一h 对中间件的分类也会有所不同。i s g 把中间件分成5 类: 数据库中洲件 数据库中间件通常是数据库供应商的产品,适用于与数据源之间的互操作 模型,客户端使用面向数据库的a p i ,以提请直接访问和更新服务器的数据源, 数据源可以是关系型、非关系型和对象型。这类中间件大都基于s q l 语句,采 用同步通信方式。此类中间件使应用开发变得简单,但如果是透过广域网使用, 会带来严重的效率问题,因为在低速网上来回交互s q l 语句会使通信流量过 大,同时对数据压缩、加密带来不便。 事务中唰件 事务处理监控技术为大规模的事务处理提供可靠的运行环境。在有成千上 万个客户的情况下,如果服务器为每个客户都分配资源,那么服务器将不堪重 负。事务处理监控介于客户和服务器之间,把大量的客户请求映射到一组受控 制的处理例程,并进行事务管理与协调、安全控制、负载平衡、资源管理、错 误恢复等,从而提高了服务器的整体性能。 面向对象中间件 列象请求代理为分布式系统中的对象通信提供了一套基础框架。o r b 是对 象总线,定义了在分布式系统中对象透明地发送请求和接收响应的基本机制, 是建立对象之阃c l i e n t s e r v e r 关系的中问件。o r b 使得对象可以透明地向其它 对象发出请求或接受其它对象的响应,这些对象可以位于本地也可以位于远程 机器。o r b 拦截请求调用,并负责找到可以实现请求的对象、传送参数、调用 相应的方法、返回结果等。 远程过程调用中间件 远程过程调用是一种早期的分布式应用实现方式,应h j 程序在本地调用远程过 程,而过程的实体则在不同的地址空间中执行,在效果上和本地调j _ = j _ i f 同。远 程过程渊用提供的是基于过程的通信服务。通信的过程是同步的,客户州用远 相关技术背景 地过程之后需要等待其执行返回,降低了灵活性。由于客户与服务器直接牛h 连, 没有中问机构处理请求远程过程调用具有一定的局限性。 面向消息中剧件 消息中间件在不同的网络协议、不同的操作系统和不同的应用程序之删提供可 靠的和可恢复的( 若发尘意外) 消息传送。这时应用并不需要消息即时即刻传 送到达对方,只是由消息中间件确保把消息传送到适当的目的地,并且只传送 一次。 2 2 消息中间件 2 2 1 消息中间件定义 消息中间件亦称消息队列中间件或通信中间件,它是依据消息传送或消息 队列的原理来工作的。它能够简化应用之间数据的传输,提供可靠的、跨平台 的消息传输手段。消息中间件支持同步和异步两种通信模式,其中异步通信模 式是基于消息队列转发机制的。一般来说,消息队列采用分布式计算模型来实 现同步和异步交互。消息队列一般提供多协议支持、高端服务和其他系统管理 服务,完成可靠的、可扩展的异构环境中的通信。 消息中间件并无标准可循,一般把工业标准t c p i p 协议作为基础。面向消 息旨勺中问件在t c p7 i p 网络体系结构中处于应用层( 见图2 2 ) ,n a p ( 网络应 用程序) 建立在面向消息中间件之上,实现各种分布式应用服务。【1 6 】 n a p 应用层 t c p 传输层 l p网络层 x 2 5s l i pp p p 网络接口层 图2 - 2 :消息中间件在t c p i p 体系结构中的位置 7 州父技术背景 2 2 2 消息中间件的分类 般来说,基本的m o m 只提供消息传递,没有其色的服务。高级的m o m 提 供消息队列和可靠性传输,以及安全性、可扩展性以及其他的功能。所以从功 能束分,消息中间件分为三种: 消息传递 消息传递是一种直接的,应用程序到应用程宇的通信模型。通过使用消息 传递,应用程序的请求以消息的形式直接传送到另一个应用程序。应用程序之 间以面向连接的方式直接通信,而且通信的双方要保持他们之间的逻辑连接。 消息传递的通信机制既可以是同步的,也可以是异步的。所谓同步是指发 送者发送请求之后,进入阻塞,直到接受到返回的消息为止。异步通信通常采 用p o l l i n g 模型,或者通过回调路由实现,它使中间件产品适用于事件驱动的应 用程序。消息传递总是面向连接的,不适合松祸合、时间独立的应用程序。 消息队列( m e s s a g eq u e u e ) : 消息队列方式是一种间接的程序到程序的通信模型,程序之间的通信是通 过消息队列而不是直接的互相调用。它允许程序无需直接建立起连接即可发送 和接收消息。使用消息队列方式,程序只需简单地将消息发送给消息队列, 由 消息i :j k n 负责消息的传递,对应用程序完全透明。在大型企业级应用中,消息 还可以从一个队列转发到另一个消息队列中。如图23 所示。 隔稠i m a c h i n eb 图2 3 :消息队列中间件原理 8 相戈技术背景 消息队列中间件的特点有: 通过队列进行通信:消息队列提供了一个a p i 接门使应用程序丌发者可以方 便的进行消息交换。应用程序之i b j 的通信都通过消息队列进行。这样,应用程 序之间不再需要保持完全同步,通信时,应用程序只需将消息放入消息队列, 而不必关心对方是否存在或是否准备好处理消息。 不需与对方建立连接:消息队列方式允许程序无需与对方直接建立连接即可发 送和接收消息。程序只需简单的将消息发送给消息队列,由消息队列负责消息 的传递,对应用程序完全透明。 支持异步方式:消息队列采用异步方式,为消息提供了一个安全的存储方式。 总之,对于企业分布式匣用开发者而言,消息队列中间件是种极具吸引 力的模型。它为开发者提供了一个丰富的、灵活的同时也是简单的通信模型。 它适用于事件驱动应用程亭,一个应用程序中的事件能够引起其他应用程序中 的动作。这反映了一个企业或企业之间的商业过程。 发布订阅模式 在发布订阅模型中没有传统意义上的客户和服务器,应用程序被分为信息 的发枷者和定购者。这种模型本质上是基于“主题( t o p i c ) ”的,发布者发送消 息到“主题”,定购者定购感兴趣的主题,接受主题的所有消息并进行消费。 个丰题可以有多个发布者和多个订阅者一个应用程序可以既是发布者也是 词阅者。如图2 4 所示: m e s s a g eb u s 圈圈 图2 4 :发布订阅模式 存发机汀阅模型中采用推技术。对于推技术,就是服务器把数据推向客 户,这是指h 服务器有了客户的数据,它就启动与客户的通信并发送数据。 甲一 | 哭投术什景 这种援蔓的特点是: 不需与对方建立直接连接:程序无需与对方建立连接即可发送和接l l 叟f i j 息,发 布者只需简单的将消息发送给主题,由主题将消息发送给定购者。所有的参与 应用程宁组件对系统的其他部分而言是完全屏蔽的,实现了透明性。 支持异步通信:发布订阅模型采用异步方式进行通信。 实现了松散耦合:在发布订阅模型中,发布者和定购者应用程序不必知道彼此 的位置、状态,甚至不必知道对方是否存在。这意味着整个系统可以动态的重 配置,新的客户或服务能够在不中断系统的情况下增加到系统中。 2 2 3 消息中间件的优点 使用x i o m 构建企j 应用程序具有许多优点: 可扩展性: 当需要增加某种服务的时候,开发者要做的切就是在m o m 中增加所需的 功能而无需改变客户端和服务器端应用程序。同样,当要删除某种服务的时候, 只要将其从m o m 中去除即可。 异步通信: 当组件不忙于处理请求的时候,他可以去执行别的任务。当他准备好接收 应答的时候,他可以通知m o l d 以接收应答。也就是说,组件可以使用m o m 服务 发送消息而不管接收组件是否正在运行或可通过阿络联系到。 可靠性: 企业的消息通常具有一定的商业价值,因此要求传输过程中的可靠性。队 列管理软件使用强大的技术来保证消息在传送中不会丢失、打乱顺序或重复传 送。 灵活性: 因为应用程序的a p i 是由交换的消息的格式定义的,因此,系统的组件可 以运行在不同的平台上,也可以由不同的语言来编写。换句话说,使用消息的 通信不需要组件互相了解对方的实现细节。 州工技术付最 2 3j a v a 语言 2 3 1j a v a 特点 在j i :发今天的动态交换信息技术环境下的应用程序时,会遇到很多问题, 而ja 、a 本身提供了对这些问题的解决方案。尽管儿乎所有的程序设计语言都有 一些独特的优势,但是j a v a 出于其协调的性能,为开发者提供了理想的选择。 j a v a 在管理时间和资源方面效率很高,这使它在企业界非常流行。其主要特性 如下: 平台无关性 构造j a v a 就是为了在不同的平台上运行,并易于消除网络的差异。j a v a 的 这个通信排除了应用程序在不同的平台上运行时遇到的复杂性。用j a v a 构造的 应用程序很少要求平台配置和网络拓扑,对用户来说其应用程序的分布就会更 加宽。 简易性 在流行的面向对象的语言中,j a v a 比c 和c + + 简单容易的多,j a v a 去掉 了c + + 语言的复杂通信,比如指针:大家所知道的简单结构i n t e r f a c e ( 接口) 也代替了多重继承:j a v a 自动分配内存和收集垃圾,而在c + + 中则需要自己 动手: 分布性 使用j a v a 不必写冗长的代码,因为可以分歼构造模块,然后再将模块继承 在一起形成最后的应用程序。而且,写过代码之后,不必一遍遍的编译,用j a v a 构造的应用程序可以直接编译成字节码。这就是j a v a 的“一次编写,随处运行”。 安全性 到目前为止,没有一个程序设计语言能够提供绝对的安全,j a v a 也不例外。 但是,j a v a 与其竞争的程序设计语言相比有更多的优势,因为他既考虑到企业 界的要求也考虑到最终用户的需求,从而在各个阶段采取了一系列的安全措施。 健壮性 j a v a 是健壮的,这是指他所提供的都是可靠的。j a v a 真正让人感觉到是 干h 关技术背露 个可靠的语言:它能够在执行之前很容易也很全面的检测到可能的代码错误。 j a v a 不支持指针,因而避免了复杂性。没有集成指针的背后原因是限制内存蕈 写,从而在数据管理方面提供了更高的可靠性。 2 3 2j a v a 异步i o i a v a 在j d k l 4 中推出了新i o ( n 1 0 ) ,它针对那些旧的u o a p i s 不能解决或 旨解决超术很麻烦的问题提供了一些新特性,主要体现在出下几个方面: 更加灵活的可伸缩的i o 接口 快速缓存( f a s tb u f f e r e d ) 的二进制和字符i 0 接口。 字符集的编码器和解码器( c h a r a c t e r - s e te n c o d e r sa n dd e c o d e r s ) 。 基r 二p e r l 胍格e 则表达式的模式匹配机制。 改良的文件系统接口 新的i o 违例类 新t o 和传统i o 包最重要的差别在于如何对待数据的存取以及数据在程序 中和程序问的转移。 传统i o 系统基于两个核心概念:b y t e ( 字节) 和s t r e a m ( 数据流) 。系统一 次只处理一个比特。这种模式的好处是概念易于理解,容易过滤数据,容易链 接几个经过过滤的不同数据源,同时各个数据源可以用不同的方法处理数据。 1 j 利之处是速度太慢。 新1 0 系统则的两个核心概念是缓冲器( b u f f e r ) 和通道( c h a n n e l ) 。每一个 缓冲器直接或间接包含一个字节数组( b n e a r r a y ) 作为数据存储。这种模式的 主要好处是速度陕,因为他利用了操作系统管理文件和内存的方式方法,并且 将一砦耗时操作直接转嫁给操作系统。相比而言,其概念则不如传统i o 那么直 观,容易理解。从图2 5 可以看到两种模型的比较。 相关技术背景 t h es w e a mm o d e l 叵 b i t l t e r 三习 t h en 1 0 m o d e l 2 4x m l 图2 5 :新旧1 0 模型的比较 8 x t e n s i b em a r k u pl a n g u a g e ( 可扩展标记语言) ,又简称为x 她,是针对 网络应用的一项新技术。b l 是w o r l dw i d ew e bc o n s o r t i u m ( w 3 c ) 的一个标 准,它允许丌发者定制自己的标记【4 】。 x m l 并不仅仅包括删l 。语言,还包括了需要相关的规范,如文档格式化标 准、文档显示模式定义、文档查询标准、文档解析标准和文档链接标准等。 x m i 相关标准及他们的关系如图26 所示: 图2 - 6 :x m l 相关标准关系 文档格式化标准 d 1 1 ) ( d o cl j it l e i tt y p ed e fl n i t i o n :文档类型定义) 和s c h e m a 足坩文档格 式进行定义的语言,就相当于数据库中我们需要定义数据库模式一样,d t i ) 和 s c h e m a 决定了文档的内容应该是些什么类型的东西,其中d t d 是从s g m i ,继承 下来的,而s c h e m a 是专门为定义x m l 文档的格式而设计的,他们都规定了x m l 文件的逻辑结构,定义了x m l 文件中的元素、元素属性以及他们之问的关系。 文档显示模式定义 x m l 是内容和格式分离的语音,文档本身只描述数据内容,所以需要号f j 的协议来定义x m l 文档的显示格式。x m l 的显示功能由x m ,样式单来完成。过 对同一个文档采用不同的样式表( s t y l e s h e e t ) ,一个x m l 文档可以被展现成不 同的形式。w 3 c f 式推荐的样式单标准有两种:一是层叠样式单c s s ( c a s c a d i n g s t y l es h e e t ) ;一是可扩展样式单语言x s l ( e x t e n s i b l es t y l el a n g u a g e ) 。 c s s 是随着h t m l 的出现而出现的,它的初衷是为了更好的控制h t m l 中各 个元素的显示特征,他也可以用到x m l 中来控制x m l 文档的显示。而x s l 事实 l 就是专门为x m l 设计的,它是用于规定x m l 文档呈现样式的语言,使得数据 与表现形式相互独立。当然x s l 的作用不仅仅是用来显示x m l 文档,它的另一 个应用就是用来把,一个x l 文档转化为另一个x m i 文档,也就说我们可以从原 始的x m l 文档生成一个新的x m l 文档。 文档解析标准 为了x m ,文档进行分析,需要一个x m l 解析器,用它来分析x m l 文档的内 容是否符合x m l 标准。有两种解析方法:d o m 和s a x 。 使用d o m 时,数掘以树类结构被装入内存中。d o m 树在内存中是持久的,可以 修改,所以应用程守可以更改数据和结构,也可以在任何时候遍历树。f 1 4 是, 这种方法需要读取整个文件并将他存储到树结构中,因而效率不高、缓慢,并 且会过渡使用资源; s a x 是基于事件的解析器,也就是况当它逍到一个丌始或者结束标记的时 候,它i b j 应用程序发送消息由应用程序决定如何进行处理。s x 可以”刚” 始分析,而不必等待所有要处理的数据。同样,由于应用棵序简整的黔惫纾过 的数掘,不需要将数据存储在内存眼,所以s a x 更快。但是,【f 川为小f 采存数 相关技术背景 据,使用s a x 时,不可能对数据进行更改,或者“返回”至数据流中前面的数 据。 文档查询标准 要在h t m l 文档中查询特定的内容几乎不可能,而x n l 文档是一个结构化的 文本,所以具各了埘x m l 文档进行内容检索的条件,但是需要有一套完善的语 言。来实现从简单到复杂的类以关系数据库的检索功能,这套语言就是x o l ( x j l q u e r yl a n g u a g e ) ,在关系数据库中,我们可以通过s e l e c t 语句部分来限定查 询的范围,在x q l 语言中,也定义了一套类似的限定范围的规范,就是x p a t h ( x m l p a t hl a n g u a g e ) 文档链接标准 x m l 也具有超链接的功能,而且作为h t m l 的后来者,他的链接功能又有很 大增强,其具体的规范标准就是x l i n k 。x l i n k 虽然有用,但只允许引用另一 篇文档。但在很多时候,都要引用另一篇文档的特定部分,x p o i n t e r ( x m l p o i n t e rl a n g u a g e ) 规范就实现了这一点。 通竹m 议 第三章通信协议 升i 论是语言传达、交通舰则和表情符号,人类之所以能互相沟通,是因为 长久以米已经发展出一套彼此熟知的沟通规则,同样,在网络世界中,通讯设 备也需要有一套彼此能了解的沟通规则,成为通讯协议。通讯协议是网络和通 讯系统之问赖以沟通的规则,是传送与接受双发彼此事先约定好的一套协议。 通过通信协议,通信双方才能f 确解读信息的含义。 j x m t p ( j a v ax m lm e s s a g et r a n s f e rp r o t o c 0 1 ) 描述了一个使用x m l 消息 格式的传输协议。该协议用来封装和传输在t c ps o c k e t 上的所有数据。t x m t p 主要是为了设计个轻量级的、灵活的传输协议,使其能够满足客户机n 务器 模式中客户端到服务器的通信的需求。 3 1 消息 在分布式应用中,特别是在客户n 务器结构应用中,消息是一个常用的概 念。在分布式应用中,不同的应用进程之间传递、交换的信息统称为消息。消 息的内容及格式由消息的提供者及接受者协商而定。 本文采用x m l 来定义消息格式。 利用x m l 来定义消息是基于统一数据格式的需要,消息队列服务可视为分 布式环境中的中间件。这种中间件在不同应用之间交互消息必须有唯一的身份 标志。不同的消息有着不同的格式,这也将导致消息交互和系统更新的困难, 如果所有消息的格式能够统一,消息队列服务则只需要处理单一格式的消息。 此外,x m l 可方便地表示结构化的数据。将x m l 引进消息队列中间件,正 是基于它的这种互操作性和表示能力。 同时,x m l 是以文本形式来描述的一种文件格式,不依赖于任何编程语舌、操作 系统或软件供应商。而平台独立性使得x m l 有助于在不同编程平台和操作系统 之问实现互操作。现在,x l 已经成为互联网和企业内部网的全球标准。 越价汕一议 3 。1 。1 消息格式 x m l 文档包含了若干结点,是基本的树状结构,结点又包含了子结点或有关 信息,一旦某个i d 类型的属性值被设定,结点之间通过身份标志使用i d r e f 和 i d r e f s 类型的属性值进行交叉引用是完全可能的。于是,利用x m l 可对消息作 如下定义: ”一个x m l 文档代表了一个消息: 2 ) 消息类型包含一个或多个结点元素: 3 ) 结点元素对应于对象: 4 ) 元素属性对应于对象属性: 5 ) 对象间的关系采用i d i d r e f i d r e f s 数据类型表示。 基于x m l 的消息可以分为信封、消息头和消息体三部分。 信封元素 信封元素是所有消息的根并包含所有其他的元素,它出现在每一个消息中, 定义了消息的命名空间b 、版本、语言等内容。 1 ) 根元素一 l e s s a g e 2 ) 消息版本号一一x m 、7 e r s i o n 1 0 3 ) 语言一一e n c o d i n g :“u t f 一8 ” 4 ) 命名空j 1 = i j - - 一“h t t p :w w w x m t p t o m ” 消息头 消息头定义消息的属性和特征,它是信封元素中的第一个子元素,必须包 含在每一个消息中。消息头包括: 1 ) 类型一指明消息的类型,一共有三种: r e q u e s t :表示用户请求消息 r e p l y :服务器返回的应答 n o t i f y :报告信息。 2 ) 消息优先级指明消息的重要程度,优先级高的消息优先处理。 :3 ) 用户标i , k 一用户名r 用户i d ,雌一标示一个用户。 口) 消息序列号一一仞:让i :自息次序客户机发送消息从“0 ”序列盯始,每发送 通信饥潋 一个消息,序列号加“1 ”:序列号的范围从0 2 ( 3 2 ) 一1 当达到最大时,序 列号重置为0 5 ) 时戳一一十进制数表示消息的构造时间:毫秒级,0 0 :0 0 :0 0j a n u a r y l ,2 0 0 3 消息体 消息体记录消息包含的具体内容,电即应用数据,其不同的内部信息以灵 活的方式对应不同的应用数据。消息体的第一级子元素是“文档”,一个消息体 中可以包含多个文档元素。该元素有三个属性: 1 ) 类型- - i x 属性最多出现一次。每个文档元素只能对应一个类型,可以有 三种不同取值: 数据文档:指定消息中传输的具体内容。如表l 所示。 执行文档:指定消息的执行结果。 加密文档:表明文档已被加密。 2 1 对象一该属性最多出现一次。指明处理的对象。 3 1 动作一该属性最多出现一次,必须与对象属性成对出现。指明对象的处 理方式,包括c r e a t e 、q u e r y 、d e l e t e 、u p d a t e 。 第二级子元素定义非常简单,j x m t p 仅仅定义了一个框架,用户可以根 据需要向其中添加元素。 1 如果文档类型为“数据文档”,其子元素为对象对应的取值,用户可以将 自定义的元素作为“数据文档”元素的子元素。 2 如果文档类型为“执行文档”,其子元素为“状态”,标识请求的处理结果, 有两种取值: 成功,晚明信息已经被成功执行。 失败,定义信息接收不成功或者处理错误等详细信息。其包含的予元 素为“错误”。错误通常分两种,系统错误和应用错误。如表2 所示。 3 如果文档类型为“加密文档”,其子元素包括“编码数据”和“数字签名”, 这一点将在加密部分详细介绍。 表1 : j 垃竹1 , p j1 z 王东 表2 : 失败( 状态 数据库中没有n a m e = ”王东”的记录 3 1 2 消息处理 j x m t p 采用x m l 表示消息,那么就需要指定对x m 文档的处理规则。根据 本文需要,主要包括三个方面:格式定义、解析和命名空间的支持。 格式定义 为了在企业团体之间进行x m l 格式的数据的交换,x m l 数据的结构、元素 的名称、元素的数据类型以及元素的亲子关系都需要仔细考虑,一定要设计成 人和系统能够理解的语言。x m i ,中的文档格式化标准就解决了这个问题,包括 d t d ( d a t at y p ed e f i n a t i o n ) 和x m ls c h e m a 。 根撮d t d 和s c h e m a 的比较,j x m t p 采用了s c h e m a 定义x m l 文档格式。因 为在x ls c h e m a 中有下述d t d 中不具备的特征: 1 ) 多个s c h e m a 复合使用x m l 名字空间: 2 ) 用x m i 。语法描述; 3 ) 可以详细定义元素的内容及属性值的数据类型。 、i x m t p 的主要月标是建立一个消息格式的框架,用户可以根据需要定义自 己的元素标签,只需增加或修改s c h e m a 即可。 消息解析 l 解析器有两种形式:验证和非验证。究竟需要哪一种呢? 一般来说如 果不使用f 式的b r r d 或x m ls c h e m a ,验证特性并不重要。如果已经或者正在 j 血f i 朗l 丑 h 划使用d t d 或x 批s c h e m a ,也i 午应该首选验三掣折器。在i x m t p f f 消息 都使用s c h m e a 定义,所以采用验证解析器。 命名空间 在个模式中的所有名字都是惟一的,这样孰避免了相互之i d j 的混淆。然 而,对于一个引用了多个模式的x m l 文档来说可能会有两个或更多的模式 中包含了相同的名字。这样一来,文档就需要为每个模式定义一个命名空间, 使得解析器在分析某个特定模式的一个实例h , i ,能够分清应该使用哪个定义。 命名空间能唯一地区分和利用x m l 词汇表:使用命名空间,可以 把来自不同文档的片段组合到一起,而不会出现命名的冲突。 编写能够为特定元素和属性所调用的可用重复使用的代码模块。 定义能在其他结构描述或者实例文档旱被重复使用的元素和属性,而不 用担心名称的冲突。 在j x m t p 中,支持命名空问的使用,具体规范见n a m e s p a c e si nx m l 【5 】。 3 2 连接 3 2 1s o c k e t j x m t p 以t c p 口作为底层协议,建立在套接字( s o c k e t ) 应用程序接口之 i :。套接字a p i 由一些套接字函数实现,如图3 1 所示,这些函数屏蔽了协议 的实现细节,使应用程序变得简单。 s o c k e t 为整个网络通信提供协议基础。进程间的通信就通过连接两个进程 的通路进行,软件设计人员不必考虑这个通路是什么,只要知道如何把一个进 程连接到通路的端点即可。s o c k e t s 有两种主要的操作方式:面向连接的和无连 接的 本协议采用面向连接的操作,提供双向、可靠、有次序、不重覆的消息传 送。面向连接的操作使用t c p 协议一个这个模式下的s o c k e t 必须在发送数据 之前与目的地的s o c k e t 取得一个连接一旦连接建立了,s o c k e t s 就可以使用一 个流接r :打丌一读写一关闭所有的发送的信息都会在另一端以同样的顺序被 接收面向连接的操作比无连接的操作效率低,但是数据的安全性更高 2 n 通信诉议 客户机j 套接字层 协议层t c p ,p 驱 设备层动 以太网程 序 程 服务; 套接宇层 协议层t c p i p 驱 设备层动 以太网程 序 图3 1 :套接字模型 3 2 3 连接的初始化和终止 进程 初试化的过程是t c p 三次握手过程。具体实现就是服务器监听端口1 1 , 等待客户连接,客户发起主动连接到端口1 1 1 l 琏接建立。 每个t c p 连接包含两个流,每个方向一个流。客户发送器通过发送第一个 消息来初试化流,然后等待服务器发送器发送他的响应。流可能有很长的生命 周期,从几秒到几天甚至更长,这主要取决于应用程序。 客户端发起请求后,是直保持原来的连接等待对方的响应( 长连接) 还 是立即断开连接,等对方取得响应报文后由对方重新建立新的连接( 短连接) ? 在客户机n 务器模式中一般采用长连接,因为它实现起来较为简单,且可 靠性高,比较适合于对处理延迟要求较高的场合,但是它不能缓冲请求与响应, 当交易高峰朔很多请求差不多同时到达的时候会拒绝一些请求,从而影响业务 的处理。 在j x m t p 将长连接和短连接结合起来。系统中建立两个消息队列,一个 存放所有到达的请求消息另一个存放所有收到的响应消息;对应每一个消息队 列,有一个d a e m o n 进程专门处理其中每一个消息,这样就把发起请求后等待 响应报文的时山j 左掉了( 这部分时间包括对方业务处理的时间和返回的传送时 f 日j ,般占整个交易时一j8 0 以上) ,请求d a e m o n 只管不停的处理请求队列 中的请求消息,而响应d a e m o n 则专门处理受到的响应消息,二者并发进行。 如果在传输过程牛r 7 1 二异常,服务器终jj ,连接:否则,客户f 常断_ 1 :连接。 丑f i m 嫂 3 3 协议参数 3 3 1a c c e l e r a t i o

温馨提示

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

评论

0/150

提交评论