基于中间件ICE的客户端的设计与应用
2013-04-29刘路明
刘路明
【摘要】ICE中间件简化了客户端和服务器的通信,使得整体架构数据高度可扩展,且支持语言独立性,本文基于中间件ICE实现了客户端界面的美观以及对用户的友好性。
【关键词】中间件ICE;客户端;设计;应用
一、中间件ICE
ICE(Internet Communication Engine)中间件是分布式系统中集成各个组成的软件粘接剂。也有人把中间件定义为网络环境中一组为许多应用需要的、可复用和可扩充的服务或功能。大型应用软件通常要求在软硬件各不相同的分布式网络上运行。为了更好地开发和应用能够在异构平台上运行的应用软件,迫切需要一种基于标准的、独立于计算机硬件以及操作系统的开发和运行环境,中间件技术应运而生。DCOM和CORBA 这样的使用多年的面向对象中间件平台,正逐渐显现出许多难以解决的问题,MicrosoftNET平台和DCOM都是Microsoft的独家解决方案,不是异种环境下的选择。CORBA近年来已停滞不前。Web服务基于HTTP的SOAP协议无论是在网络带宽还是在CPU开销方面,都会给应用造成严重的性能恶化,以至于无法适用于许多有苛刻性能要求的系统。
ICE 是一种面向对象的中间件平台。从根本上说,这意味着ICE为构建面向对象的客户-服务器应用提供了工具、API和库支持。ICE应用适合在异种环境中使用:客户和服务器可以用不同的编程语言编写,可以运行在不同的操作系统和机器架构上,并且可以使用多种网络技术进行通信。无论部署环境如何,这些应用的源码都是可移植的。
在从不发出请求,只是响应请求的意义上,许多服务器常常不是“纯粹”的服务器:它们常常充当某些客户的服务器,但为了完成它们的客户请求,它们又会充当另外的服务器的客户。与此类似,在只从某个对象那里请求服务的意义上,客户常常也不是“纯粹”的客户:它们常常是客户-服务器的混合物。例如,客户可以在服务器上启动一个长时间运行的操作,在启动该操作时,客户可以向服务器提供回调对象,供服务器用于在操作完成时向客户发出通知。在这种情况下,客户在启动操作时充当客户,而在接收操作完成通知时充当服务器。这样的角色反转在许多系统中都很常见,所以,许多客户-服务器系统常常可以被更准确地描述为对等系统。要想与某个ICE对象联系,客户必须持有这个对象的代理。代理是客户的地址空间中的一种制品;对客户而言,代理就是ICE对象的代表(该对象可能在远地)。一个代理充当的是一个ICE对象的本地大使。
ICE 对象是一种具有类型、标识,以及寻址信息的概念性实体。但客户请求最终必须到达具体的服务器端的处理实体,由该实体提供操作调用的行为。换言之,客户请求最后必须到达服务器,在其内部执行代码,而这些代码用特定的编程语言编写,并在特定的处理器上执行。在服务器端提供操作调用的行为的制品叫做servant。一个servant 提供一个或多个ICE对象的实质内容(或体现这些对象,incarnate)。实际上,servant 就是服务器开发者编写类的实例,这些类作为一个或多个ICE对象的servant向服务器端run time进行注册。类的方法对应于ICE 对象的接口上的操作,并且提供这些操作的行为。一个servant 可以只体现一个ICE对象,也可以同时体现若干ICE 对象。如果是前一种情况,servant 所体现的ICE 对象的标识在这个servant中是隐含的。如果是后一种情况,在每次收到请求时,servant也会收到ICE对象的标识,这样,servant可以决定在处理该请求期间,体现哪一个对象。反过来,一个ICE对象也可以拥有多个servant。使用体现同一个ICE对象的多个servant,你可以构建冗余的系统:客户端run time试着把请求发给一个服务器,如果失败,就把请求发给第二个服务器。只有在第二次尝试也失败的情况下,错误才会报告给客户端应用代码。
二、部分系统模块的设计与实现
(一)配置文件解析
配置文件的解析主要依靠自定义函数parsemainini()函数来完成,该函数主要调用WIN32 API有关解析ini文件的函数来完成从ini文件读取配置载入到指定变量的操作。
(二)检查版本更新
版本检查主要依靠getverinfo()函数载入目前系统版本到变量,再与远程服务器通信取得最新版本号进行对比的方式进行。同时系统会做出是否需要更新的判断,如果需要更新,系统再调用startupdate()函数进行更新。实际上,startupdate()函数仅仅是打开外部程序houjieupdateclient.exe,再交由该子程序去完成更新任务。更新子程序会从服务器下载需要更新的文件的列表进行解析,然后根据列表依次下载更新文件,覆盖到当前文件夹,值得一提的是,若不存在文件夹则会自动创建,若已有文件则自动覆盖。完成更新以后,子程序重新启动更新完的主程序,便会自动退出。
(三)注册与登录的实现
在注册界面上,除了一些常规的注册选项外有几个值得一提:学校、学院、班级。因为系统目前只对固定的学校的固定专业同学进行内侧,所以学校以及专业班级信息必须从服务器取得以保证准确。并且还需要考虑以后对系统进行扩充,所以本系统用注册通信器第一次向服务器发起请求,取得学校信息,因为学校信息是处于信息链的顶层。有你学校信息后,系统利用用户选定你的学校信息代码进一步请求服务器,并获得学院信息,以此类推,最后获得班级信息。在填写完所有必须填写的字段以后提交信息到服务器即可完成注册。
在处理登录时,由于验证登录信息需要与服务器进行通信,而通信必然有可能存在一定的人为可察觉的延迟。为了使本系统对用户友好,有必要在登录的时候显示登录动画。这样,系统在后台通信,而UI则响应用户消息并显示登录动画。为实现这个需求,本系统新初始化一个工作线程,该线程处理与服务器进行登录信息验证的事项,主线程则作为UI线程响应用户消息。这样也有效防止了登录时出现的UI界面无反应假死的现象。
(四)教师任务与上传打印
本系统需要时刻检测教师布置的新任务并呈现给客户端用户下载,系统通过主通信器向服务端请求并取得包含教师所有当前未完成任务的列表,任务则是一个结构体,具体为任务ID、名称以及任务文档下载等。由于需要时刻检测有无新任务出现,所以在实现中,系统首先记录第一次返回的任务列表中的任务数目,然后系统新增一个工作线程去轮询服务器返回当前未完成的任务列表,如果新返回的任务列表里的任务数目比已经记录的要多,说明教师布置了新的任务。这时通知用户有新任务,并把新任务更新到列表上。在打印文档上传的模块中,用户可以选择本地被允许的文件类型进行上传,上传前系统会询问用户的地址以方便派送。上传的实现,是通过调用主通信器向服务器发送建立上传任务以及传输的调用来完成。派送的地址在此时也是发送给服务器记录起来。值得注意的是,在上传文档时,需要新增一个工作者线程进行上传任务的处理,否则会造成主线程堵塞,进而导致假死的现象。
【参考文献】
[1]杨小,沈曾伟.ICE协议的形式化分析[J].计算机科学,2006(33).
[2]汤晓燕,徐竞.ICE中间件的研究与应用[J].常熟理工学院学报,2009(10).