基于WINDOWS消息队列机制的远程通信研究与实现-论文_第1页
基于WINDOWS消息队列机制的远程通信研究与实现-论文_第2页
基于WINDOWS消息队列机制的远程通信研究与实现-论文_第3页
基于WINDOWS消息队列机制的远程通信研究与实现-论文_第4页
基于WINDOWS消息队列机制的远程通信研究与实现-论文_第5页
已阅读5页,还剩69页未读 继续免费阅读

下载本文档

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

文档简介

基于windows消息队列机制的远程通信研究与实现摘要随着硬件设备和软件技术的开展,网络上的应用也越来越复杂,应用程序的体系结构也从单层、两层、三层到多层。分布式的网络应用成为网络应用的开展趋势。但是,人们在感受到分布式网络应用在解决大型复杂任务的优越性的同时,也愈来愈发现构建和维护分布式应用面临的困难。一个是由于应用程序往往分布在不同的不同的系统、不同的计算机上,如何将这些应用程序有效的集成起来协同工作;另外,在以往,应用程序之间的通讯一般是同步的通讯,而现在在很多情况下要求异步的通讯。应用程序之间要能够实现异步的消息传输。为解决这样的问题,消息队列中间件应运而生。它的突出功能就表现在实现应用程序之间异步的消息传输以及集成分布的应用程序。微软的消息队列中间件技术MSMQ是消息队列中间件中的优秀代表,它也是本文重点研究的对象。本文从消息中间件技术的出现原因引出消息中间件技术的相关概念并加以阐述,同时说明了MSMQ技术的实现方法与API函数,最后在介绍了基于MSMQ的一个远程通讯系统的实现,在该系统中封装了MSMQ的windowsAPI函数。关键词:分布式网络应用,中间件石消息队列中间件;异步消息传输;MSMQ

AbstractWiththehardwareandsoftwaretechnologydevelopment,applicationonthenetworkalsomorecomplex,applicationarchitecturefromsingle-layer,two-story,three-tiertohigh-rise.Distributednetworkapplicationsbecomethedevelopmenttrendofnetworkapplications.However,itwasfeltinthedistributednetworkapplicationsinresolvinglargeandcomplextaskofthesuperiorityatthesametime,alsofoundthatmoreandmoreconstructionandmaintenanceofdistributedapplicationsthedifficultiesfacingthem.Asanapplicationisoftendistributedinvariousdifferentsystems,differentcomputer,howeffectivetheseapplicationsworktogethertointegrateaddition,inthepast,communicationbetweentheapplicationisgenerallysynchronouscommunication,andnowInmanycasestherequirementsofasynchronouscommunication.Applicationsmustbeachievedbetweenthenewsasynchronoustransmission.Tosolvethisproblem,messagequeuemiddlewareemerged.Itfunctionsontheoutstandingperformanceinachievingtheapplicationofinformationbetweenasynchronoustransmissionanddistributionofintegratedapplications.Microsoft'sMessageQueuemiddlewaretechnologyMSMQmessagequeueisinanexcellentrepresentativeofmiddleware,itisthisfocusonthetarget.

ThisarticlefromthenewsmiddlewaretechnologyleadstotheemergenceofthereasonsforinformationrelatedtotheconceptofmiddlewaretechnologyandexpandtheMSMQtechnologyatthesametimethatthemethodandAPIfunction,inthefinalbasedonMSMQonalong-rangecommunicationssystemstoachieve,inthesystemPackagingintheMSMQthewindowsAPIfunction.KeyWords:distributednetworkapplication,middleware,messagequeue middleware,asynchronousmessagetransmission,MSMQ目录1绪论 11.1课题提出的背景和意义 1网络应用面临的挑战 11.1.2消息队列中间件(MQM)的出现 11.2国内外开展现状 21.3本文主要研究内容 32.应用程序体系结构 42.1单层应用体系结构模型 42.2两层应用体系结构模型 42.3多层应用体系结构模型 52.4Internet应用体系结构 63中间件 83.1什么是中间件 83.2中间件要解决的问题 83.3中间件的分类 93.4中间件技术的开展趋势 124.MSMQ概述 134.1MSMQ的功能 134.2MSMQ的网络拓扑 144.3MSMQ网络组件 16效劳器 16独立客户端 16附属客户 174.3.4MSMQExchange连接器与MSMQAPI 174.4MSMQ队列类型 184.5消息类型 184.6消息路由 204.7队列管理器 204.8组件队列 215.MSMQ的安装 246.MSMQ的编程 246.1COM 24概述 24接口 256.2MSMQ编程模型 286.3创立队列 29公有队列 29私有队列 296.4队列定位 296.5消息发送 306.6消息接收与窥探 307.MSMQAPI的封装 307.1创立发送与接收队列 327.2发送消息到远程计算机消息队列并保存到本机 337.3消息的组包发送 377.4队列的删除 407.5队列中消息的删除 428.系统的实现 458.1系统主界面 458.2消息发送 46发送消息 46组包消息发送 478.3队列消息查看 48查看发送队列 48查看接收队列 48参考文献 50致谢 511绪论1.1课题提出的背景和意义网络应用面临的挑战网络技术近些年来开展得很快,硬件设备的性能越来越强大,所承载的网络应用也越来越复杂。体系结构从集中式,到两层模式,到三层模式,直至多层模式。毫无疑问,网络应用的复杂化,大型化是软件技术开展的必然,也是任务复杂化直接推动的结果。分布式的网络应用在许多领域都提供了最正确的解决方案。以至分布式网络成为一个极为热门的研究方向。但是,在分布式网络应用开展的过程中,却面临着两个颇为棘手的问题。在大型的分布式网络应用中,不同的应用运行在不同的进程,分布在不同的计算机上,甚至跨系统,跨网络,如何将这些应用有效地集成,使不同的应用能够保持良好的通讯,真正发挥分布式应用的巨大优越性。这一点成为衡量一个网络应用是否可靠,是否稳定的重要标准。在分布式网络应用中,越来越多的应用程序之间的通讯不仅要求可以同步发送接收,还要求能够实现异步的通讯。而传统的通讯技术一般都要求发方应用和接收方应用同时在线,而且发送者和接收者还要知道互相的程序对程序的调用接口。实际情况却是,应用程序并不总是同时在线;网络的硬件故障往往不可防止;数据的流量具有突发性,可能造成网络的信息拥塞;某个应用需要立即得到处理,而另外一个应用却可以缓一缓,它们应当区别对待;这样一来,应用之间的异步通讯问题变得非常突出。消息队列中间件(MQM)的出现 应用消息队列中间件(MessageQueueMiddleware)技术,就能够很好的解决以上问题。总的来讲,消息队列中间件的作用表达在两个方面,一是集成大型的分布式应用,二是确保分布式应用之间的异步通讯。MQM提供可靠的异步的和松散偶合的通信效劳。MQM在其它传统的通讯方法不能奏效时能够成功,因为它满足三个重要的条件:发送者和接收者无须同时连接。即使发送者和接收者之间的通讯不是同时发生的,也会有极强的请求和答复传送保障。请求和答复可以通过发送方和接收方之间的路由器进行翻译和重新格式化。利用MQM,应用程序通过一系列消息在彼此间进行通信。当消息在发送方和接收方之间进行传送时,MQM提供方将消息限定在控制域内,这个控制域叫做队列,因此才有“消息队列中间件〞的名称。队列防止消息在传输过程中被丧失,并在消息准备好时为接收方提供一个寻找消息的地方.应用程序通过向预定接收方相关的队列发送消息来产生请求。如果发送方希望得到答复,它们通常在所有发送给接收方的请求中包含应答队列的名字。MQM的作用主要表达在以下几点(1)存储和转发(Store-and-forward)通信MQM能使应用程序向其他应用程序发送请求,而那些应用程序不必正在运行或是可到达。(2)防御通信MQM软件使用强大的技术来保证消息在传送中不会丧失,打乱顺序或重复传送。(3)并发执行使用MQM,应用程序可以向许多不同的接受方发送请求而不必等待响应;等待接受方可以平行地处理请求;当所有的响应消息都到达时,或无论什么时候只要方便,应用程序就处理结果。(4)日志通信MQM产品可以产生日志,以利于记录,核查和错误恢复。1.2国内外开展现状消息队列中间件技术并不是最新技术,早期,由于没有统一的,适合各种情况和平台的消息队列产品,人们往往自己编写消息队列中间件,这些消息队列中间件虽然可以起到相关的作用,但是它们还是太专门,太原始,费用太高。因此,许多大的公司就开始开发适用于各种情况和平台的消息队列中间件产品,最著名的有IBM的MQSeries和Microsoft的MSMQ,这两个产品都有很好的跨平台性,适用面很广,现在许多公司采用它们作为中间件的一局部。而最近两三年,由于中间件的(包括消息队列中间件)市场销t以惊人的速度增长,国外专门做中间件的公司越来越多,工业级的产品也越来越多。中间件技术在保证系统的平安性,可伸缩性,可用性,可管理性,互操作性,适应性,分布式需求等等方面都有了很大的进展。中间件被广泛用于银行,电信,金融,电子商务,大型企业化制造,国家平安等等领域。据工DC预测,到2002年全球中间件市场销售额将到达80亿美元;在中国,1998年中间件市场总值仅为12.34亿美元,而到2004年将到达90.3亿美元,年增长率高达39.7%。中间件市场空间之大,成长率之高,由此可见一斑。面对全球中间件技术和市场的开展态势,我们国家的情况是怎样的了?客观来讲,我们在计算机系统软件,以及一些关键性的大型应用软件方面的落后是不争的事实,这一点,相信国人都有切肤之痛.但是对于中间件,我们再也不能落后了。理由有二:首先中间件作为操作系统之上的独立的系统软件或效劳程序,其市场潜力极其巨大,如果我们将这一市场再次拱手让给外国,我们将会面临巨大的经济损失。这里有一个现实的例子.BEA中间件刚进入中国的时候,报价是4000万美元,后来出现了一个国内的竞争者清华北美公司,BEA的报价马上就降为300万人民币,其间的悬殊令人乍舌。其次,中间件技术在国外的开展历史也不长,也是近几年的事情,我们虽然起步稍微迟了一点,但是完全有赶上的可能。目前国内专门的中间件厂商虽然只有一两家,但是它们的技术在很多方面并不比国外差。譬如东方通的TongLINK/Q(消息队列中间件)已经占领了中国建设银行的业务份额,另外几家大的金融单位和电信单位(包括中国联通)也采用了东方通的产品.1.3本文主要研究内容论文从网络应用面临的问题和挑战入手,研究了中间件技术,对其概念、功能、类别、开展趋势等方面进行了阐述。接着对中间件中最热门,开展最快的消息队列中间件技术进行了剖析,尤其是它的消息处理机制和同步通讯协议的比照。消息队列技术的优秀代表MSMQ,是本论文的研究的重点,详细阐述了它的根本概念、特点、使用和管理、编程等等方面。并结合一个具体的应用来展示消息队列技术在应用程序通讯,数据传输方面的优越性。 文章最后以一个系统为例详细说明对MSMQAPI的封装,与消息队列根本功能的实现。1.4系统总体设计与本文的安排 本课题为基于windows消息队列机制的远程通信研究与实现,基于这个课题本系统总体设计如下: 首先,分析系统完成功能〔为消息队列进行远程通信的根本功能〕,在分析的根底之上对MSMQ的相关API函数进行封装。封装成能够实现功能的各个功能函数。其次,在各个功能模块中调用相关封装函数实现可视化的界面显示。本文整体组织如下:第一章中主要介绍了关于windows消息队列研究的一些根本情况与论文与系统的设计与组织;第二章中结合第一章中指出的应用体系结构进行了详细的分析与说明,为下文中中间件技术的提出做好铺垫;第三章中重点介绍了中间件技术〔windows消息队列就是一种最典型的中间件技术〕;第四章中就详细介绍了微软公司所提供windows消息队列编程组件MSMQ的相关知识,这是消息队列机制研究的重点;第五章中简单表述了MSMQ组件的安装方法;第六章中重点介绍了MSMQ的编程,由于MSMQ编程的特殊性流程性所以在这里进行了集中地介绍;第七章详细地介绍了本系统实现的核心-对于MSMQAPI函数的封装,封装是依据系统功能的需求而来;第八章介绍了系统各个界面的具体代码实现。设计目标 实现对windows消息队列相关API函数的封装,完成基于windows消息队列机制的远程通信系统。系统结构 系统总体结构如下: MSMQ相关API函数的封装类;系统主界面〔含发送与接收队列的创立〕;发送队列的相关操作;接收队列的相关操作;消息的发送。 队列的相关操作包括:对应队列消息条数的显示;消息的两种删除方式的操作;消息的获取与显示。 消息的发送包括:MSMQ消息的正常结构的发送;消息体打包之后的发送。消息队列操作流程图SEQ图\*ARABIC1消息发送图SEQ图\*ARABIC2消息接收流程图消息队列的传输与接收 MSMQ技术为消息队列的传输与接收提供强大的支持。消息队列在传输时,只需要根据IP地址将消息发送到接收者〔根据IP来分辨〕的接收队列中。消息队列在接收时,本机〔接受者〕直接从自己的接收队列中取出消息。2.应用程序体系结构 任何一个应用程序的设计开发的最重要的元素之一就是如何进行系统架构。系统架构定义一个应用程序的各个模块之间如何相互作用,以及每个模块负责执行什么样的功能。从纯功能的观点来看,大多数应用程序主要处理如下三种任务:获取用户输入,将输入存储为数据,按预定的操作程序处理这些数据。目前流行的主要有三种应用程序体系结构模型,各应用体系模型就是根据在用户与数据之间所具有的层次来划分的。每一层次一般都运行在不同的系统或是相同系统的不同进程空间内。这三种应用体系结构模型分别就是单层应用体系结构模型、两层应用体系结构模型、多层(可以是三层或三层以上)应用体系结构模型。2.1单层应用体系结构模型单层应用体系结构模型在单一的应用层内实现用户界面、商业规那么、数据管理。对数据本身来说,它可以是物理上位于一个远端位置,但是存取数据的逻辑却是应用程序的一局部。在这样的体系结构中,数据处理主要不是通过数据库,而是文件来存取数据,应用程序自己定义如何进行数据的存储、查询、读取等运算逻辑。单层应用的一个最普遍的例子就是字处理器:它有一个用户界面用于接收键盘输入以及显示输出,它有众多商业规那么来完成页码标记、拼写检查等功能,它还有一些文件存取程序来管理数据文档。单机应用特别是Windows的应用程序多数属于这种单层模型。这种模型的好处在于应用程序的前期分析和设计比拟简单,但是后期的维护会变得非常麻烦,因为用户界面、商业规那么、数据管理交织在一起,对任何一局部的改动都会影响到其它局部。2.2两层应用体系结构模型 在两层应用体系结构模型中,商业规那么和用户界面仍然结合在一起构成应用程序的客户端。但是数据的存取和管理独立出来由单独的通常是运行在不同的系统上的程序来来完成,这样的数据存取和管理程序通常就是象SQLServer或Oracle这样的数据库系统。熟知的Client/Server就是这样的两层结构,基于Client/Server结构的应用在局域网的应用中占绝大多数。以下是该结构的典型模型:图SEQ图\*ARABIC3典型的两层体系结构模型 在两层应用体系结构模型中,还有一种情况是用户界面单独为一层,商业规那么和数据处理合而为一构成另一层。这种结构的典型例子就是商业规那么以存放在数据库效劳器内的存储过程来表达。存储过程是数据库系统的一个重要功能,每个存储过程就是存储在数据库效劳器上的一段程序,它指明如何进行一系列的数据库操作。存储过程可以直接被客户端调用,此外还有一种触发机制可以调用执行存储过程:当数据满足一定条件时,触发一个事件,引起相应的存储过程被调用执行.Client/Server结构模型的一个最大的好处在于:通过允许多用户同时存取相同的数据,来自一个用户的数据更新可以立即被连接到效劳器上的所有用户访问。这种结构的缺点也很明显:当客户端的数目增加时,效劳器端的负载会逐渐加大,直到系统承受不了众多的客户请求而崩溃;此外,由于商业规那么的处理逻辑和用户界面程序交织在一起,因此商业规那么的任何改动都将是费钱、费时、费力的。虽然两层结构模型为许多小规模商业应用带来简便、灵活性,但是对快速数据访问以及更短的开发周期的需求驱使应用系统开发人员去寻找一条新的创立分布式应用的道路,那就是多层应用体系结构模型.2.3多层应用体系结构模型 在多层应用体系结构模型中,商业规那么被进一步从客户端独立出来,运行在一个介于用户界面和数据存储的单独的系统之上。现在,客户端程序提供给用系统的用户界面,用户输入数据,查看反应回来的请求结果,对于Web应用,浏览器是客户端用户界面,对于非Web应用,客户端是独立的编译后的前端应用程序;商业中间层由封装了商业逻辑的组件构成,这些商业逻辑组件模拟日常的商业任务,通常是一种COM组件或者CORBA组件:数据层可以是一个象SQLServer这样的数据库管理系统,或者是象Exchange这样的非结构化数据交换系统,还可以是象事务处理或消息队列这样事务处理机制,应用程序可以选择一个或多个这样的数据效劳。商业规那么处理并确保所有的商业过程正确执行。在这种多层体系模型中,客户端程序不能直接存取数据,从而为数据的平安性和完整性带来保障。这种结构带来的好处就是应用系统的每一个局部都可以被单独修改而不会影响到另外两个局部。此外,因为每一层之间是通过接口来相互通信的,所以只要接口保持不变,内部程序的变化就不会影响到系统的应用其余局部。以下是典型的应用程序结构:图SEQ图\*ARABIC4典型的多层应用体系结构模型在多层体系结构模型中,各应用层并不一定要分布在网络上不同机器的物理位置上,而可以只是分布在逻辑上的不同位置,此外各应用层和网络物理拓扑之间并不需要有一一对应关系,每个应用层在物理拓扑上的分布可以按系统需求而变化.比方,商业中间层和数据处理层可以位于装有IISWeb效劳器和SQLServer数据库效劳器的同一台机器。使用多层体系结构模型为应用程序的生命周期带来诸多好处,包括:可复用性、适应性、易管理性、可维护性、可伸缩性。你可以将你创立的组件和效劳共享和复用,并按需求通过计算机网络分发。你可以将大型的、复杂的工程工程分解成简单平安的众多子模块,并分派给不同的开发人员或开发小组。你可以在效劳器上配置组件和效劳以帮助跟踪需求的变化,并且当应用程序的用户荃础、数据、交易t增加时可以重新部署。多层应用程序将每个主要的功能隔离开来。用户显示层独立于商业中间层,而商业中间层独立于数据处理层。设计这样的多层应用程序需要进行权衡:它在初始阶段需要更多的分析和设计,但在后期阶段会大大减少维护费用并且增加功能适应性。中间商业层组件可以按响应时间或其它规那么的需要移动到不同的位置。例如,移动到用户层以加强用户界面处理功能并且可以减少网络的数据往复,通过存储过程将数据规那么移动到数据层来实现。只有当具有多重数据源时,数据规那么独立为一层才变得至关重要。在多层体系结构模型中,客户端应用程序变得比在Client/Server这样的两层体系结构模型中更为小巧,因为服务组件已经分布在中间商业层。这种方式带来的结果是在用户上的一般管理费用降低,但是由于效劳组件分布在不同的机器上,因此系统的通信量会大大增加。2.4Internet应用体系结构过去的一段时间,许多大大小小的公司都在为功能越来越强大、费用越来越低廉的个人计算机建立强壮的应用程序。而当这些应用程序每天被成百上千万的用户使用时,新兴的技术也同时为应用软件开发人员及应用软件系统平台带来意义深远的影响.Internet技术的开展为全球信息在大小企业以及个人之间的共享奠定了基础。Internet催动着技术创新,竞争和加速的变化脚步使得对快速开发具有高适应性应用程序的方法模型的需求日益迫切。各种应用体系结构模型都可以用于Internet应用开发,但是在单层、两层、多层这三种模型中,多层应用体系结构模型是开发Internet应用的最好的应用模型。基于Web的应用多数属于多层应用体系结构.Web技术如HTML,DHTML.XML等表示的标记语言为用户层界面带来了更好的信息显示方式,丰富了用户界面层的应用;Web效劳器如IIS.Apache等架设在用户层浏览器和数据层数据库效劳器之间,一方面通过CGI.ASP等直接为Web应用提供中间商业层服务,另一方面驱动商业逻辑组件提供中间层效劳:接受来自浏览器的效劳请求,传递给数据库效劳器,并将从数据库效劳器返回而来的数据提供给用户层浏览器;随着Web应用的增加,数据层数据库效劳器也变得日益重要。应用于Internet的三层应用体系结构模型也有很大的缺限。这种模型将绝大局部工作交由效劳器进行:数据存储在效劳器,’商业应用程序代码存储在服务器,数据的加工、处理在效劳器端进行,程序的执行也在效劳器端,客户端浏览器只简单地用于显示由效劳器端传来的标记语言页面。这是一种瘦客户端-胖效劳器端模式,它缺点之一是代价昂贵,能满足要求的效劳器价格是不菲的;缺点之二是客户端计算功能的严重浪费,今天的PC机已具有相当大的运算能力以及相当低廉的价格,真正好的应用模式应该对PC运算能力加以充分利用;缺点之三是写效劳器商业应用程序的要求是很苛刻的,应用程序的任何微小的失误在多用户访问情况下将很快导致效劳器系统的崩溃;缺点之四是集中式的数据访问将会在Web效劳器上产生数据传输瓶颈。如果采用单层或两层体系结构模型,那么当用户想要运行一个应用程序时,必须将该应用程序整个下载到客户端用户机器,即便用户只需要该应用程序的局部功能或只须临时用一下该应用程序。不言而喻,这种模式不适合Web应用。Web应用的一个特点是Web上存在着无数的应用程序,如果用户每访问一个这样的应用程序都必须先完全下载完全安装然后才能运行,那么无论是时间效率还是用户的机器都是不现实的。此外,这种应用模式在安装、升级、维护方面都极为不便,这是因为每次安装、升级、维护都必须在每台用户机器上进行。分析一下从单层体系结构到两层体系结构再到多层体系结构的开展过程,可以看出隐含其间的是一个完整的应用程序逐步被分割为不同的组成成份:先是数据存取和管理独立出来成为单独的数据层,然后是商业逻辑处理独立出来构成单独的商业中间层。每一次的分割都带来不同层度的好处。分割到最后,一个完整的应用就包括用户层显示页面、商业中间层的商业逻辑组件、数据层数据库系统。当前流行的商业逻辑组件主要是基于COM/DCOM组件模型或者基于CORBA组件模型。所有的这些页面或组件都成为不可再分割的单元。3中间件3.1什么是中间件中间件是一种独立的系统软件或效劳程序,分布式应用软件借助这种软件在不同的技术之间共享资源,中间件位于客户机效劳器的操作系统之上,管理计算资源和网络通讯.从中间件的定义可以看出,中间件是一类软件,而非一种软件;间件不仅仅实现互连,还要实现应用之间的互操作;中间件是基于分布式处理的软件,定义中特别强调了其网络通讯功能.图SEQ图\*ARABIC5中间件在应用中的位置3.2中间件要解决的问题 首先,应用的互连和互操作是中间件要解决的第一位的问题。不管这些应用分布在什么硬件平台上,使用了什么数据库,透过了多么复杂的网络,或是同一电脑中的不同应用系统.这里所说的互连和互操作是应用之间而不是说系统之间的,因为中间件是一种应用级的软件,是一种应用集成的关键构件,一个好的中间件产品要能解决应用互连带来的各种问题,通讯要支持各种通讯协议、各种通讯效劳模式、传输各种数据内容、数据格式翻译、流量控制、数据加密、数据压缩等;中间件核心要解决名字效劳、平安控制、并发控制、可靠性保证、效率保证等。应用开发要能提供基于不同平台的丰富的开发接口、支持流行的开发工具、支持流行的异构互连接口标准(如XA、工DL等);系统管理要解决对中间件本身的配置、监控、调谐,为系统的易用易管理提供保证.其次,针对不同的应用领域,对中间件又有各种不同的要求。由于实际的应用环境千差万别,不能指望有一种包罗万象的中间件解决所有的问题。对于邮件系统需要提供存储转发功能;对工作流应用需要以条件满足状态将信息从一个应用传递到另一个应用;对联机交易处理系统,需要保证数据一致性、不停机作业、大量并发的高效率;对于一个数据采集系统需要保证可靠传输,等等.3.3中间件的分类在讨论中间件的分类前,先分析一下应用之间常用的会话方式。一般地,应用级的会话有两种方式,各类中间件都是基于这两种会话方式一种是同步方式,客户方向效劳方发出请求后,等待效劳方返回的结果,在收到效劳方的处理结果前不做其它处理。在这种方式下,客户方在等待效劳方的处理结果时,可以结合“超时〞概念,在规定时限内,如果客户方还未收到效劳方的处理结果,那么本次请求失败。同步方式可能因为拥挤的网络环境造成灾难,当客户方超时时间到而未收到效劳方的应答时,客户方本次请求失败,它会去重新发起请求。这会造成恶性循环,大大降低网络上的处理效率.另一种会话方式是异步方式,客户方在等待效劳方的处理结果时可以去完成其它任务。在异步方式下,当一个节点向另外一个节点发出消息后,不等待应答。因而一个消息发送完成后,发送方就可以去处理其它事情。但不幸的是发送方也可以发送新的消息,因而同样会造成网络拥堵.中间件的分类方式很多,按照IDC的分类方法,中间件可分为六类(1)终端仿真/屏幕转换用以实现客户机图形用户接口与已有的字符接口方式的的效劳器应用程序之间的互操作(2)数据访问中间件适用于应用程序与数据源之间的互操作模型,客户端使用面向数据库的API,以提请直接访问和更新墓于效劳器的数据源,数据源可以是关系型、非关系型和对象型。这类中间件大都基于SQL语句,采用同步通讯方式.此类中间件使应用开发简单,但如果是透过广域网使用,会带来严重的效率问题,因为在低速网上来回交互SQL语句会使通讯流量过大,同时对数据压缩、加密带来不便.(3)远程过程调用中间件远程过程调用是一种广泛使用的分布式应用程序处理方法。一个应用程序使用RPC来“远程〞执行一个位于不同地址空间里的过程,并且从效果上看和执行本地调用相同。事实上,一个RPC应用分为两个局部:server和client.server提供一个或多个远程过程:client向server发出远程调用。server和client可以位于同一台计算机,也可以位于不同的计算机,甚至运行在不同的操作系统之上。它们通过网络进行通讯。相应的stub和运行支持提供数据转换和通讯效劳,从而屏蔽不同的操作系统和网络协议。在这里RPC通讯是同步的。RPC机制可用以构造客户机/效劳器方式的应用,但由于它是同步方式,因而在工作的时候,要求客户方和效劳方均能正常工作才能很好地运行,有一方不能工作将导致RPC失败。这在网络故障、机器故障存在的情况下,这一要求是很难保证的。还有一点值得注意的是,不管客户方能做什么或做的多快,它必须依靠效劳方才能有效工作。有些恢复机制可以在一个远程调用阻塞时转而去调用另一个服务器上的过程,但这种路由方式也会影响效率。也有的RPC机制采用异步方式,客户方非阻塞地调用远端的过程,但这种方式不太标准而且很难采用。另外,由于大多数RPC机制很难建立点到点的关系,因而也很难用在面向对象的编程当中。(4)交易中间件交易中间件是专门针对联机交易处理系统而设计的。联机交易处理系统需要处理大量并发进程,处理并发涉及到操作系统、文件系统、编程语言、数据通讯、数据库系统、系统管理、应用软件,是一个相当艰巨的任务,但是工作的难度可以通过采用一个交易中间件来简化。交易中间件就是一组程序模块,用以大大减少开发一个联机交易处理系统所需的编程量。交易中间件管理由应用声明和提交的交易,并通过两阶段提交协议等方式保证分布式交易的完整性、控制并发、实现交易路由和均衡负载.(5)对象中间件面向对象的中间件提供一个标准的构件框架,能使不同的厂家的软件通过不同的地址空间、网络和操作系统互相交互访问。该构件的具体实现、位置及所依附的操作系统对客户来说都是透明的。例如,我们可以通过简单的组装或扩展已有的构件就可以建立一个客户机/效劳器结构的信息系统。面向对象的中间件技术的目标就是为软件用户及开发者提供一种应用级的即插即用的互操作性,就象现在使用集成块和扩展板一样。对象请求代理(ObjectRequestBroker)是对象中间件的核心组件它的作用在于提供一个通信框架,透明地在异构的分布计算环境中传递对象请求。CORBA标准包括了OR]〕的所有标准接口。1991年推出的CORBA1.1定义了接口描述语言OMGIDL和支持Client/Server对象在具体的ORB上进行互操作的API.CORBA2.0标准描述的是不同厂商提供的ORB之间的互操作.对象请求代理(ORB)是对象总线,它在CORBA标准中处于核心地位,定义异构环境下对象透明地发送请求和接收响应的根本机制,是建立对象之间client/server关系的中间件。ORB使得对象可以透明地向其他对象发出请求或接受其他对象的响应,这些对象可以位于本地也可以位于远程机器。ORB拦截请求调用,并负责找到可以实现请求的对象、传送参数、调用相应的方法、返回结果等.client对象并不知道同server对象通讯、激活或存储server对象的机制,也不必知道server对象位于何处、它是用何种语言实现的、使用什么操作系统或其他不属于对象接口的系统成分。值得指出的是client和serve:角色只是用来协调对象之间的相互作用,根据相应的场合,ORB上的对象可以是client,也可以是server,甚至兼有两者。当对象发出一个请求时,它是处于client角色:当它在接收请求时,它就处于server角色。大局部的对象都是既扮演client角色又扮演server角色。另外由于ORB负责对象请求的传送和server的管理,client和server之间并不直接连接,因此,与RPC所支持的单纯的Client/Server结构相比,ORB可以支持更加复杂的结构.(6)消息中间件尽管消息中间件不象RPC机制那样流行,但越来越多的分布式应用采用消息中间件来构建,基于消息的机制更多地适用于事件驱动的应用,当一个事件发生时,消息中间件通知效劳方应该进行何种操作使用消息中间件编程采用的是消息中间件的API,可以很好地扩展到不同的操作系统和硬件平台上.消息中间件的核心安装在需要进行消息传递的系统上,在它们之间建立逻辑通道,由消息中间件实现消息发送。消息中间件可以既支持同步方式,又支持异步方式,实际上它是一种点到点的机制,因而可以很好地适用于面向对象的编程方式。 中间件领域目前最热门的技术是异步的消息中间件,异步中间件技术比同步中间件技术具有更强的容错性,在系统故障时可以保证消息的正常传输,因而在过去的两年里增长迅速.异步中间件技术可以分为两类:播送方式和发布/订阅方式。播送方式把消息分发给系统的所有用户。发行/订阅方式可以指定哪种类型的用户可以接收哪种类型的消息。发布/订阅方式由于更加智能有效,事实上已成为异步中间件的非正式标准.3.4中间件技术的开展趋势根据有关组织的预测,消息中间件是目前中间件技术的开展热点,如果也把交易中间件看成是一类特殊的消息中间件的话,那么消息中间件在目前的市场上占据主导地位,而且开展势头迅猛。消息中间件以其独特的优势为各种分布式应用的开发注入了强大动力,极大地推动了应用系统集成的开展.对象中间件技术也开展迅速,各大硬软件厂商都在积极参与有关标准的制定和产品开发工作,象IBM,HP,DEC,AT&T,ICL,Microsoft等都制定了相应的战略。许多对象中间件的专门厂商也相继诞生,未来的对象中间件市场会出现群雄逐鹿的局面.中间件的另一个开展动向是向Intemet的延伸,Intenret门ntranet技术早己在全球范围内广泛采用,但由于其自身的技术特点,在构造许多大型企业级应用时仍显缺乏,如并发控制、负载均衡、可靠传输、数据路由等,因而仍然存在供中间件开展的中间地带。总之,中间件技术作为软件行业新崛起的一个崭新的分支,正在全球范围内迅猛开展,根据IDC组织的预测,到2002年,全球的中间件市场将到达70亿美元。中间件技术的开展,也将把分布式应用的带到一个新的境界。4.MSMQ概述 MSMQ是微软的消息队列中间件产品,它是Windows2000操作系统中消息应用程序的根底,也是用于创立分布式,松散连接的消息通讯应用程序的开发工具。为消息队列开发的应用程序可以将消息发送到队列,这些队列是用来确保消息能够到达目标的临时存储位置。这些应用程序可以通过不同种类的网络进行通讯,也可以与脱机的计算机通讯。消息队列提供了有保障的消息传递、有效的路由、平安性、事务处理支持以及基于优先级的消息传递。具有这些功能的软件产品通常在业界叫做消息队列软件、存储转发软件或面向消息的中间件。使用消息队列,最终用户能够在断开连接的网络和计算机之间通讯,而不管网络和计算机的当前状态如何。系统管理员可以用消息队列高效地管理大型复杂的计算机和消息队列网络。通过消息队列,MIS决策者可以得到更加可靠的通讯,并且更有效地使用网络资源。开发人员可以只关注商业规那么,而不必关心网络问题,因为消息队列能够提供有效的网络通讯。4.1MSMQ的功能在Windows2000以前,MSMQ的根本功能如下:(1)无连接消息传递使用存储和转发消息队列,计算机不会受到网络的干扰,也不必建立会话。因为在应用程序级使用无会话模式,所以源计算机和目标计算机不需要支持相同的网络协议。既支持网际协议(IP),也支持Internet数据包交换(IPX)协议。(2)消息优先化消息优先化允许先发送紧急或重要的消息,再发送次重要消息,这样可以保证对关键的应用程序有足够的响应时间,而忽略不太重要的应用程序。(3)有保障的消息传递消息可以存储在基于磁盘的队列中,然后转发以提供有保障的消息传递.(4)事务处理消息。使用事务处理功能,可以将一些相关活动在一个事务处理中连接起来,保证消息按顺序传递,保证消息只传递一次并确认消息能够从目标队列成功返回。(5)动态队列创立可以随意创立或更改队列属性,而不影响消息应用程序.(6)消息路由消息队列能够根据网络的物理拓扑、会话集中性需要以及传输连通性提供消息路由,会话的集中性,易于有效的利用慢速的网络连接。(7)不同系统的集成消息队列可以跨越各种硬件平台使用。(8)跨平台支持MSMQ-MQSeriesBridge扩展7消息队列的功能,提供与IBMMQSeriesVersion2和Version5平台的无缝、事物处理连通性.消息队列连接器(MQC)可用于将消息队列的功能扩展到其他非Windows的操作系统,包括:UNIX,AS/400,Tandem,DigitalVMS,CICS/MVSH和UnisysClearPathHMP.在Windows2000中,MSMQ有T一些新的功能。(1)ActiveDirectory集成集成并扩展ActiveDirectory目录效劳,以便存储所有配置和状态信息。(2)混合模式操作消息队列可以在混合模式域环境下操作,这意味着在WindowsNT4.0下运行的MSMQ1.0控制器效劳器和Windows2000下运行的消息队列效劳器能够进行无缝通讯。(3)Windows2000平安集成消息队列仍然可以通过使用访问控制、审核、加密和身份验证支持保密和平安性,并且能够对嵌入Windows2000中的新平安功能起到平衡作用,例如KerberosV5平安协议。(4)工作组支持消息队列可以在Windows2000工作组中安装和运行,而不是在域中。此外,安装在工作组中的消息队列能够在以后参加到域中,然后再从域别离。Active/active群集支持。目前消息队列完全支持效劳器群集中的active/active操作,这意味着消息队列能够同时在效劳器群集中的所有节点上运行。(5)WindowsCE支持消息队列客户端的特殊版本预装在运行WindowsCE3.0(或更高版本)操作系统的手持式和掌上型计算机中。消息备份和复原.万一计算机发生故障,那么消息存储文件、日志文件、事务处理日志文件和注册表设置都可以备份和还原。(6)Microsoft管理控制台(MMC)支持目前使用MMC控制台中的管理单元管理消息队列。4.2MSMQ的网络拓扑消息队列是由在Windows2000网络上提供不同功能和连接的计算机所组成的消息根底结构。消息队列既可以在域环境中,也可以在工作组环境中使用。在消息队列环境中,域环境包括提供ActiveDirectory之类目录效劳的域控制器,而工作组环境是不提供这种目录效劳的任意环境。1域环境在域环境中,消息队列在Windows2000域控制器上运行,提供对ActiveDirectory的访问。Windows2000网络中所有域的总和叫做树林。消息队列也可以在混合模式域环境中运行,这个域由在WindowsNT4.0上运行的MSMQ1.0控制器效劳器和在Windows2000上运行的能够互相通讯的消息队列效劳器组成。在域环境中,消息队列网络分成不同的Windows2000站点,这些站点由路由链接互连。站点映射网络的物理结构,而域通常映射单位的逻辑结构。逻辑结构和物理结构是相互独立的,因此一个站点中可能有多个域,也可能在一个域中有多个站点。在消息队列的环境中,站点包含以下内容:(1)Windows2000域控制器,它在ActiveDirectory目录效劳中保存配置和状态信息,并可以使用站点链接在站点之间复制这些信息。ActiveDierctory使用多主机模式,这意味着任何Windows2000域控制器都可以读取或写入存储在ActiveDirectory中的对象。(2)所有Windows2000计算机都使用相同的网络协议(一般为IP)。一个站点中使用相同网络协议的任意两台计算机之间都是直接连通的。这种连通性意味着快速而廉价的通讯。(3)相关子网的集合,每个子网都有单独的IP子网地址。2工作组环境消息队列可以在不是域的环境下运行,例如工作组或其他不提供目录效劳的环境。如果消息队列在工作组中的计算机上运行,那么该计算机可以随后参加Windows2000域.相反,消息队列计算机可以是域的一局部,然后再参加工作组。该计算机可以随后重新参加相同的域.但是在非域环境下使用消息队列存在以下限制:(1)计算机发送的消息不能由与需要的目标计算机直接连通的消息队列效劳器发送(2)不能访问ActiveDirectory。因此,只能在本地计算机上创立和管理专用队列。不能查看或管理公用队列及ActiveDirectory内的任何其他信息。当然,如果直接连通,那么可以将消息发送到专用队列或从中读取消息。不能使用内部证书发送经过身份验证的消息:必须使用外部证书代替。

图SEQ图\*ARABIC6MSMQ典型网络拓扑4.3MSMQ网络组件MSMQ效劳器消息队列效劳器是消息队列网络中的通信中枢。所有的消息队列效劳器都运行消息队列效劳、主控队列、在本地存储消息,并能默认地发送和接收消息。除此之外,它还提供以下效劳(1)目录访问默认情况下,安装在Windows2000域控制器上消息队列效劳器能够让客户查看或更改在ActiveDirectory目录效劳中列出的信息。(2)路由效劳启用路由效劳的消息队列效劳器能提供消息路由和中间存储和转发消息队列。当客户之间不能直接连通时,消息队列效劳器可以在站点内或不同站点之间发送消息。提供相同站点内的消息路由功能的消息队列效劳器叫做传入路由效劳器(InRS)或传出路由效劳器(OutRs)。提供站点之间消息路由的消息队列效劳器叫做站点入口。一对站点入口轮流定义两个站点之间的路由链接。尽管假定使用相同网络协议的站点内的客户直接连通,但是使用传入路由和传出路由效劳器在站点内部发送消息会降低网络的带宽要求。客户可以配置使用传入路由和传出路由效劳器,以便代表自己提供消息路由选择。在这种情况下,客户发送或接收的所有消息都先通过消息队列效劳器发送。这里的“客户〞是指本身不能发送消息的消息队列计算机,例如独立客户和没有启用路由的消息队列效劳器。该功能不适用于附属客户。附属客户使用支持效劳器代表自己发送和接收消息.如果站点入口用来在站点之间发送消息,那么只有指派的消息队列效劳器才能在站点间发送消息。消息队列效劳器还可以配置成能够让客户使用不同的网络协议(如IP和IPX)相互通信。(3)群集效劳消息队列效劳器还可以提供群集组环境中的效劳。在效劳器群集上安装消息队列效劳器时,可以创立消息队列资源,并将其添加到称为群集虚拟服务器的群集组中。群集虚拟效劳器是包含磁盘资源和网络名称资源的群集组。群集虚拟效劳器的功能与在物理计算机上运行的效劳器类似,所以在群集虚拟效劳器环境中运行的消息队列效劳器提供与物理计算机上运行的消息队列效劳器相似的效劳。消息队列客户可以与效劳器群集的计算机节点上运行的标准消息队列效劳器通信,或者如果消息队列应用程序支持群集,那么可以与群集虚拟效劳器环境中的虚拟消息队列效劳器通信。在效劳器群集上可以运行多个群集虚拟效劳器。在群集虚拟效劳器环境中运行时,消息队列所提供的效劳类型取决于节点上安装的消息队列效劳器的配置。MSMQ独立客户端 独立的客户运行消息队列效劳、主控队列、发送和接收消息,而且在默认情况下还能在与网络断开连接时操作。独立的客户不需要同步访问消息队列服务器来发送或接收消息。独立客户和消息队列效劳器的主要区别在于独立客户不能提供ActiveDirectory访问,也不能为启用路由的消息队列路由器提供消息路由选择功能。独立客户和不启用路由的消息队列效劳器提供相似的功能,唯一区别在于独立客户只能在Windows2000Professional上运行,而消息队列服务器可以在Windows2000Server或Windows2000AdvancedServer上运行。如果独立客户(或相当的消息队列效劳器)从网络上断开连接,那么可以继续生成发送到其他计算机的消息。独立客户在本地存储这些消息,而且一旦重建网络连接就能自动发送。MSMQ附属客户 附属客户需要同步访问消息队列效劳器(称为支持效劳器)的所有功能。附属客户在支持效劳器上应答以代表自己执行所有功能,如主控队列、存储消息、发送和接收消息。在配置附属客户时,有以下明显的缺点:(1)由于消息队列效劳是在支持效劳器上运行,所以被附属客户发送或接收的加密消息在附属客户与支持效劳器间以纯文本的形式传递。(2)附属客户的队列访问时间慢于独立客户。这是因为队列访问通过基于RPC的连接。(3)如果多个附属客户同时连接到支持效劳器发送或接收消息,就可能影响性育旨。(4)附属客户队列位于它们的支持效劳器上,哪个队列属于哪个附属客户并不明显。(5)当附属客户软件被卸载时,相关联的队列不会自动从支持效劳器删除。(6)因为来自附属客户的通讯要通过支持效劳器,所以如果它与支持效劳器的通讯较慢或费用昂贵(例如两个站点间的通讯),那么所有客户通讯也会较慢或费用昂贵。(7)附属客户在本地用户帐户下不能运行。基于以上的局限性,一般将客户机配置为独立客户。MSMQExchange连接器与MSMQAPIMSMQExchange连接器为MicrosoftExchange用户提供了与消息队列应用程序通信的方法。通过MSMQExchange连接器,可以将电子邮件发送到消息队列应用程序,而消息队列的邮件消息也可以发送到MicrosoftExchange用户。MSMQExchange连接器是连接MicrosoftExchange用户和消息队列应用程序的推荐解决方案。Exchange企业中只需要一台MSMQExchange连接器。当消息队列客户把消息发送到Exchange客户时,该消息首先发送到消息队列效劳器的队列中,然后通过与MSMQExchange连接器通信的Exchange效劳器,由MSMQExchange连接器转发到Exchange客户.MicrosoftExchange客户从共享的Exchange通讯簿得到消息队列客户的队列地址。MSMQMAPI传输提供程序允许连接MAPI客户应用程序(如MicrosoftExchange客户)和消息队列应用程序。作为传输提供程序,MSMQMAPI传输提供程序在电子邮件和消息队列邮件之间转换。MAPI客户可以使用MSMQMAPI传输提供程序与消息队列应用程序交换电子邮件。4.4MSMQ队列类型在消息队列环境中,队列是临时存储不同类型消息的地方。有以下的一些类型:(1)公共队列公共队列可以被所有MSMQ客户机访问,由MSMQ效劳器在ActiveDirectory中为所有客户显示。它不存在于工作组环境中。(2)专用队列专用队列不在ActiveDirectory中发布而只在包含它们的本地计算机上显示的队列。专用队列只能通过知道队列完整路径名或格式名的消息队列应用程序访问。(3)日志队列存储消息副本的过程叫做记入日志。称作日志消息的这些副本存储在日志队列中。日志有两种类型,即源日志和目标日志,源日志是存储在源计算机上传出的非事务处理消息副本。目标日志是存储在目标计算机上的传入消息副本.(4)死信队列无法传递和过期的非事务处理消息存储在死信队列中。无法传递的和过期的事务处理消息存储事务处理死信队列中。这些消息就存储在消息过期(投递或转发失败)的计算机上的这些队列中。它可以是源计算机、目标计算机或中间的消息队列效劳器。(5)管理队列管理队列包括已发送消息确实认消息,发送消息时由发送应用程序通过编程指定.任意有效的非事务处理队列都可指定为管理队列。(6)响应队列响应队列包含接收应用程序发回发送应用程序的响应消息。响应队列由发送应用程序在发送消息时通过编程指定。任意有效的队列都可被指定为响应队列。需要响应队列和管理队列时,根据它们的功能可以合并成一个队列。然而,由于所有的管理队列都必须是非事务处理的,因此该队列将只接受非事务处理消息。(7)报告队列报告队列包含的报告消息指出消息到目的地所采用的路由,还可以包括己发送的测试消息.每台计算机只能有一个报告队列。只有先启动消息路由跟踪,才能创立报告队列。(8)系统队列消息队列可使用最多五个系统队列.所有五个系统队列都作为专用队列执行,这意味着它们不在ActiveDirectory中发布。不能删除系统队列.4.5消息类型1)根据类别区分消息类型(1)正常消息消息队列应用程序所创立的所有消息都是正常消息。正常消息可以发送到公用队列、专用队列、日志队列、死信队列及事务处理队列。正常消息不包含状态信息。这类信息包含在确认消息、报告消息及响应消息中。(2)确认消息确认消息报告正常消息的状态。这些消息不是正的就是负的,并发送到源计算机上的管理队列。正确实认消息表示消息到达目标计算机而且消息是否被读取(由接收应用程序删除)。负确实认消息表示在消息传递到目标计算机之前发生错误,或者说明消息不能读取的原因.(3)报告消息报告消息包括发送到源计算机上的报告队列的测试消息和路由跟踪消息。(4)响应消息在消息队列的环境中,消息由正文和一组属性构成。消息正文可包含文本或任何形式的二进制信息,而且可以加密。大多数的消息属性都是由消息队列应用程序通过编程指定的。某些属性,如发送者的平安ID(SID)和消息ID是由消息队列指定的。消息属性不能加密。包括正文和全部指定属性的消息大小不能超过4兆字节(MB).响应消息是由接收应用程序发送到发送应用程序指定的响应队列的消息。2)根据传递方法区分消息类型有两种消息传递方法,一种是快速消息传递,一种是可恢复消息传递选择这两种方法的根本原那么是:如果想得到更好的性能同时使用最少的资源,那么使用快递方式;如果想获得可靠的传递而且在失败之后可以恢复,就选择可恢复传递。(1)快速消息传递使用快递消息传递意味着在路由和传递期间消息存储在内存中,这可以提供非常迅速的传递性能,但是如果消息经过的任意计算机出现问题,那么快递消息不能恢复。只要消息队列效劳停止,快递消息就会丧失。(2)可恢复消息传递使用可恢复消息传递意味着在路由和传递期间将消息写到磁盘上,这种传递方式比快递略慢,但是在没有容错能力或在消息仍在队列中时关机(如使用便携机的移动式客户)的情况下,使用这种方式更好。如果发送消息时计算机故障或关闭,那么该消息存储在磁盘上。重新启动计算机以及重新启动消息队列效劳时,发送过程将自动继续。可恢复消息传递可以进一步区分成事务处理消息传递和非事务处理消息传递。事务处理消息是从事务处理内部发送和接收的。这意味着这些消息或者按发送顺序(提交的事务)一起发送或者根本不发送(放弃的事务)。同样,如果事务被提交,那么事务处理消息只能从队列中读取(删除),否那么会返回到队列,随后能在另一事务处理期间读取。从相同计算机启动到同一目标队列的连续事务将按照事务相互提交的顺序到达,而且每条消息将只到达一次目标队列(如果它到达目标队列)。由于消息屡次写到磁盘而且要求更多的计算机资源,因此事务处理消息传递比非事务处理消息传递慢。事务处理消息只能发送到事务处理队列(非事务处理消息不能发送到事务处理队列).4.6消息路由 消息队列客户利用根本网络传送协议与目标计算机建立直接连接或会话,如果直接连接不可能或不允许,那么消息队列效劳器可以替代客户发送消息。这时候就发生所谓的消息路由。它发生在以下几种具体的情况。(1)在源计算机和目标计算机之间无法建立会话(例如,当目标计算机脱机时)。(2)使用特定消息队列效劳器代表源或目标计算机发送消息。(3)计算机使用不同的网络协议进行通讯。通过提供集中会话,消息队列效劳器(启用路由)的使用可以减少运作开销。此效劳器可以减少一个站点内的带宽需求,也可减少不同站点之间的会话数量。提供站点内消息路由的消息队列效劳器被称为传入路由效劳器(MRS)或传出路由效劳器(OutRs)。在路由链接的站点之间提供消息路由的消息队列效劳器被称为站点入口。消息路由分为站点内的消息路由和站点间的消息路由。站点内的消息路由用跃点测量,它代表消息到达目标计算机必须通过的计算机数目。站点内发送消息时使用最短有效路径(即经过最少跃点数的路径)。为决定消息路由,如果为两台计算机分配了属于一个站点的IP地址,那么这两台计算机在同一站点内。不同站点之间的消息路由称为站间路由,它基于路由链接的使用.使用多个路由链接时,路由消息的捕获量基于路由链接开销。所有路由链接都指派默认开销为1。只有在有多个路由链接情况下和需要使用链接开销使某个路由强于其他路由时,才能更改路由链接开销。4.7队列管理器MSMQ的通讯根底结构对一个称为队列管理器(queuemanager)的组件具有很大的依赖性。队列管理器作为一个Windows月及务运行,它由MQSVC.E)CE装入.MSMQ把队列管理器安装到每一个具有存储转发职责或具有本地队列的计算机上.安装时,每个队列管理器被分配一个唯一的GUID.MSMQ就使用这个GUID跟踪由特定的队列管理器建立并拥有的队列,它还使用这个GUID跟踪源自队列管理器的消息.每台计算机只有一个队列管理器,一个队列管理器的GUID唯一标志了安装它的计算机.简而言之,队列管理器使得MSMQ通讯成为可能发方应用必须传递一个消息给队列管理器,如果这个队列管理器是目的队列的所有者,那么将这些信息转发给另一个队列管理器加果目的队列所在的计算机不可到达,队列管理器就临时存储这个消息,等通讯能够建立时再传递.最后,接收方和读者应用与存储队列的计算机上的队列管理器进行通讯以接收或消息.MSMQ会在活动目录中维护一个全局目录表.每个队列管理器也在一个称为本地队列存储器(localqueuestore,LQS)的地方为本地队列保存一份额外数据。LQS为每个队列包含一个文件,并包含队列管理器本地队列所用到的配置数据。LQS经常复制活动目录里的信息。保存信息副本也使得队列管理器能够使用LQS消除网络信息交换,并且当不能连接到一个活动目录效劳器时仍然能够处理消息。4.8组件队列作为MSMQ的延伸,我们不能不提到组件队列(QueuedComponent)。组件队列(QC)是COM+效劳的一局部。它集成了COM和MSMQ以提供COM风格的调用,同时提供消息处理。一个组件队列就是一个COM组件。但是,它的底层传输是以MSMQ为根底的。组件队列的方法可以从一台机器向另一台机器进行远程传送,这意味着组件队列不会遭受标准COM组件所面临的与RPC相关的局限性。并且使用一个组件队列也相比照拟简单。假设客户计算机上的一个应用创立了一个特殊的QC代理对象并进行一个或多个方法调用。COM十运行时通过把这些方法调用记录在一个MSMQ消息中并把消息发送到效劳器计算机上的一个队列,从而远程传送这些方法调用.QC提供效劳器计算机上的内置监听效劳所需的管件(plumbing)。该监听效劳允许COM+运行时监听队列并当消息到达时获取它们。获取一个消息后,COM十创立组件队列的一个实例并且重放记录在客户计算机上的消息.COM标准代理/占位层的体系结构,如下图.这一体系结构允许在客户和对象之间建立RPC连接。图SEQ图\*ARABIC7COM标准代理/占位层体系结构图SEQ图\*ARABIC8QC体系结构当客户应用正确地从组件队列实例化一个对象时,它并不绑定到包含方法实现的对象,而是绑定到一个称为记录器(Recorder)的特殊代理对象。从这个意义上说,组件队列的体系结构与COM的标准代理/占位层相似。客户分辨不出COM对象、标准COM代理和QC记录器间的不同。但是记录器的实现细节与标准COM代理相同。标准COM代理知道如何使用RPC与占位通讯,而QC记录器对象使用MSMQ转发方法调用.COM十运行时在客户机器上从一个名为QC.Recorder的配置型组件中创立记录器对象。COM十的标准安装把这个系统提供的组件添加到一个名为COM十Utilities的COM十库应用中.标准COM代理与QC记录器有非常大的不同。COM的标准代理/占位层需要一个以建立的RPC连接,客户发出的每个COM方法调用都被实时转发给对象。例如,如果一个客户执行两个方法,在第二个调用能够运行之前,第一个调用必须返回给客户。而组件队列那么被设计成,当客户机不能建立到效劳趋的连接时,仍然能够工作.当客户应用创立QC记录器的一个实例并开始执行方法时,调用不能实时转发.相反,记录器对象通过把所有调用记录在一个单个的MSMQ消息中,在客户计算机上缓存所有的调用,直到记录器对象被释放,QC运行时才设法把消息发送到效劳器。QC依赖于MSMQ的事物消息处理功能,每个消息在一个MSMQ事务范围内进行传送,这意味着使用QC通讯具有精确一次性交付语义。5.MSMQ的安装在每个Windows2000域或站点中第一次安装消息队列必须是在Windows2000域控制器上。随后在站点或域的其他计算机上安装的每个消息队列使用域控制器的名称来完成安装.如果随后的安装不能定位域控制器,那么安装将以工作组模式安装消息队列。工作组模式需要直接与发送消息连接。每次计算机重新启动,消息队列将试图定位运行在Windows2000域控制器上的消息队列效劳器。如果成功,消息队列将转变为域模式,它需要访问ActiveDirectory.在运行消息队列效劳器安装程序之前,必须首先满足如下要求:1要在Windows2000域控制器上安装消息队列效劳器,必须以具有域管理权限的身份登录或属于DomainAdmins组。2要在非域控制器上安装带有路由效劳的消息队列效劳器,必须以具有企业管理权限的身份登录或属于EnterpriseAdmins组。3要卸载消息队列,必须拥有删除MSMQ配置对象的权限。消息队列效劳器的安装步骤1控制面板中翻开添加/删除程序2单击“添加/删除Wmdows组件〞。在“Windows组件向导〞中,单击“下一步。3选中“消息队列效劳〞复选框,然后单击“下一步〞。4在“消息队列安装向导〞中,单击“消息队列效劳器,’.5要提供消息路由效劳,要选中“启用路由〞复选框。6按向导中的其余指令操作。6.MSMQ的编程在本章中只是从理论上讲述编程的相关知识,对于MSMQAPI的封装与代码描述将在下一章中详细给出。6.1COMcom概述COM(组件对象模型)是Microsoft生成软件组件的标准,可以将它比喻成一个规那么簿,如果遵循COM规那么,那么软件就能够与其它的组件交互信息,这样实现软件组件在二进制上的兼容性.COM的好处具体表达为如下几点:(1)COM组件易替换在我们的软件开发和维护中,一旦业务有了新的变化,往往需要更改程序,如果是一个大型的应用,就有可能需要更改所有局部的相关程序代码。改变代码和重建程序后,还要汇编新的版本,安装到所有的计算机上。这样一个过程是非常繁琐和复杂的。利用COM,就没有必要更新整个应用程序,而只要重建一个或者多个组件并且发布即可。(2)COM组件适合于改变业务需求软件的业务需求是经常需要改变的,这样一来,维护软件的任务也就显的非常繁重,由于COM组件易于替换,可以将业务规那么放在少数几个组件中,业务规那么改变时,只要改变这几个组件即可,极大方便了软件对应业务需求的改变。(3)COM组件使复用性成为可能COM组件可以实现非常灵活的复用性。很多代码一次编写,编译为COM组件后,就可以多处使用。例如,可以建立一个处理所有字符串函数的组件,任何应用程序都可以使用这个字符串处理组件。COM组件有助于并行开发通常COM组件开发是先开发组件借口,然后实现接口的要求。一旦设计接口之后,就可以将它分布到几个程序中,组件的实现可以并列进行。例如,有一个字符串处理组件,一个计算组件和一个数据读取组件,如果接口设计正确,这些组件可以同时建立,建立这些组件之后它们将能顺利的配合.接口 COM接口使应用程序和其它组件可以和COM组件的功能进行通讯。组件功能通过虚拟函数表(VirtualFunctionTable)访问。也称vtable或VTBL.Vtable不包含实际的函数,只是组件函数的一组指针.组件要访问其它组件的功能时,要通过这个vtable。客户机不能直接访问vtable。另一指针叫接口指针(interfacepointer),增加了与接口的另一层连接。使这个接口得以实现.以下图是COM接口的结构。图SEQ图\*ARABIC9COM接口结构COM接口的vtable唯一要求的是表的第一个字段应为lunknow,指针。Iunknown是任何组件变为COM组件必须实现的唯一接口,它是所有接口的大门,因为所有其它接口都从它继承而来。COM组件可以包含任意多个接口的实现方法。整个实现方法可以是一个类,也可以不是。由于组件可以包含多个类,这些类可以实例化为多种类型的多个对象.对象是这些类的活的实例。对象能集中提供组件接口的实现方法。组件要靠接口通讯。如果接口不复存在或已经改变,那么通讯断开。接口定义并发布后,就不能改变。COM规那么之一就是保证软件接口在发布后不变。如果改变接口,那么要作为另一新接口发布.前面发布的接口仍然保持不变。由于这种不变性,接口生成之前一定要慎重的考虑。如果接口规划的好,那么可以减少今后对使用某个组件的代码所需的改变工作。只要接口不改变,使用该接口的代码就不需要改变。如果接口规划不好,那么通常需要改变,从而改变周围的代码。IUnkonwn接口lunkonwn接口派生所有其它的接口。它总是位于每一个COM接口层次的顶端。这意味着lunkonwn定义的三个方法(QueryInterface.AddRef,Release)总是位于COM兼容的虚拟表的顶端,如下图图SEQ图\*ARABIC10Iunkonwn接口示意图与通过用户自定义接口所定义的某一特定领域的行为不同,IUnknown表达COM对象的根本行为。lunknown允许每个COM对象管理自己的生存周期。它还允许客户访问一个对象来确定它是否支持某个给定的接口,然后动态地把对象传递给所支持的任何接口.在COM中,对象需要管理自己的生存周期。但是,对象要适当地决定是该中止自身还是应该继续运行,这时候往往需要一些特别的措施。不管什么时候,当一个对象的客户重用一个接口引用时,它要负责对AddRef进行调用;而当它断开一个存在的连接时,它要负责调用Release.如果所有客户都能担负起自身的责任,那么一个对象就可以提供这两个方法的一个简单实现以正确地管理其生存周期。该对象还维护一个对关联引用的计数,并在该计数值降为0的时候把自己从内存中释放出来。Idispatch接口与Automation早些时候,由于虚拟绑定的底层本质,COM只能由C和C++程序员访问。后来,1DL和类型库使得诸如VisualBasic4这样的开发工具在编译时生成所需要的虚表绑定代码成为可能。由于脚本客户不能从类型库中读取接口定义,所以它不能生成所需的客户方代码以访问与COM对象相关的虚表。但是,这些客户仍然可以调用一种称为Automation对象的特殊类型的方法。一个Automation对象是一个名为IDispatch的特殊接口的对象。Idispatch接口允许客户在运行期间在一个名为滞后绑定的进程中建立方法绑定。Idispatch通过四个方法扩展了IunknownaAutomation客户使用其中的GetIDsOfNames和Invoke方法来实现滞后绑定。代表Idispatch的虚表如下图图SEQ图\*ARABIC11Idispatch虚表Automation的工作过程如下:客户在接到一个Idispatch之后,就可以通过GetIDsOfhNames来询问该对象是否支持某个特定的方法。客户在调用中必须以字符串类型的参数来传递方法名

温馨提示

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

评论

0/150

提交评论