（计算机应用技术专业论文）移动奥运智能交通受理台系统的设计与实现.pdfVIP

哈尔滨工程大学硕士学位论文 摘要 智能交通系统( i t s ) 是通过对场馆、道路进行监控，运用先进的信息、 通信、控制等高新技术对传统交通运输系统进行改造而形成的一种信息化、 智能化、社会化的新型交通运输系统。它可以增强交通运输系统的运行效率， 提高被监控场所的可靠性和安全性，是交通信息领域发展的重要方向。2 0 0 8 年奥运会即将到来之际，为体现科技奥运的理念，中国移动通讯公司推出了 移动奥运智能交通示范项目。 本论文主要研究了移动奥运智能交通受理台子系统的设计与实现。受理 台子系统处于移动奥运智能交通系统的最前端，是整个系统的信息采集源。 它通过对道路、场所的视频监控，采集到路况、场所状况等信息，然后通过 c n g i 网络，将信息发送到智能交通服务中心，以便进行车辆调度、预警信息 发布等操作。由于视频监控点很多，对视频信息发送的实时性要求高，单一 的客户端进行集中处理的方式会造成视频文件积压，长期得不到处理的严重 后果。鉴于以上弊端，本文采用了多客户端一服务器的体系结构，服务器负 责视频源的分发，客户端则专注于对视频源的监控和处理。 本文讨论了实现多客户端一服务器架构的基本理论，对视频源分发算法， 组件设计方案和远程通讯方法做了详细论述。首先从需求分析入手，阐述了 受理台在智能交通系统中的位置及其与其它业务模块的交互关系，继而给出 了系统功能模型并划分出多个子功能模块。然后详细论述各功能模块的设计， 给出了功能模型和流程图。对视频文件的分发算法做了详细的阐述。最后结 合实际应用对客户端g u i 组件的实现方案，c s 架构的远程通讯方法做了详 细的论述。 本课题来源于中兴软件技术( 南昌) 有限公司的移动奥运智能交通项目， 课题的研究项目已经开发完成并通过验收。 关键词：智能交通；受理台；组件设计；企业级j a v a 构件；消息服务 哈尔滨工程大学硕士学位论文 a b s t r a c t i n t e l l i g e n tt r a n s p o r t a t i o ns y s t e m ( i t s ) i sa i li n f o r m a t i o n a l ，i n t e l l i g e n t i z e d t r a n s p o r t a t i o ns o f t w a r ew h i c hi m p r o v e st r a d i t i o n a lt r a n s p o r t a t i o ns y s t e ma n du s e s s o m en e wt e c h n i q u e s ，s u c ha si n f o r m a t i o n ，c o m m u n i c a t i o na n dc o n t r 0 1 i tc a n i m p r o v et h ee f f i c i e n c y , r e l i a b i l i t y , s e c u r i t yo ft h et r a f f i c ，a n di sa ni m p o r t a n t d i r e c t i o no f t h e t r a f f i c 。i m f o r m a t i o nf i e l d b e f o r et h ec o m i n go f o l y m p i c g a m e si n 2 0 0 8 ，d r i v e db yt h es p i r i to ft e c h n o l o g i c a lo l y m p i cg a m e s ，c h i n am o b i l e p r o p o s e d t h i si t sp r o j e c tf o rb e i j i n go l y m p i cg a m e s t h i st h e s i sf o c u s e so nt h ed e s i g na n dr e a l i z a t i o no f t h ea c c e p t e rs u b s y s t e mo f i t sw h i c hi st h ef r o n te n do fd a t aa c q u i r e m e n ta n dp r o c e s s i ts e n d st h et r a f f i c i n f o r m a t i o nc o l l e c t e db yt h em e t h o do fv i d e om o n i t o r i n gt ot h e i n t e l l i g e n t t r a n s p o r t a t i o ns e r v i c ec e n t r et h r o u 【曲t h ec h i n an e x tg e n e r a t i o ni n t e m e t ( c n g i ) ， a n dt h ec e n t r ew o u l di m p l e m e n tt h ev e h i c l er o u t i n ga n df o r e w a r n i n ga c c o r d i n gt o t h e s ei n f o r m a t i o n t h er e a l f i m ep r o c e s s i n gi sc e r t a i n l yn e c e s s a r y s i n g l ec l i e n t w o u l di n d u c et h eo v e r s t o c ko ft h ev i d e of i l e s t h i st h e s i su s e st h e m u t i - c l i e n t s e r v e rs t r u c t u r et os o l v et h i sp r o b l e m s e v r a lc l i e n t sa n do n es e r v e r t a k et h ec h a r g eo f v i d e om o n i t o r i n ga n di n f o r m a t i o ns e n d i n gr e s p e c t i v e l y t h ep r i n c i p l eo fm u f f c l i e n t s e r v e rs t r u c t u r ea n dv i d e of i l ed i s t r i b u t i o n a l g o r i t h ma r ed i s c u s s e d f i r s t l y , t h ea c c e p t e r sp o s i t i o ni ni t sa n di t sc o r r e l a t i o n s w 诩、o t h e rm o d u l e sa r ei n t r o d u c e d a n dt h i st h e s i sg i v e st h es y s t e mf u n c t i o n m o d e lw i t l lm a k i n go f fs e v e r a ls u b m o d u l s s e c o n d l y , w ed e s i g ne a c hs u b m o d u l e s o fa c c e p t e lp r o p o s eav i d e of i l ed i s t r i b u t i o na l g o r i t h m ，a n dg i v et h ef l o wc h a r t s f i n a l l n t h e r e a l i z a t i o no fc l i e n tg u i c o m p o n e n t a n d l o n g d i s t a n c e c o m m u n i c a f t o nm e t h o db a s e do nc sa r c h i t e c t u r ea r er e s e a r c h e d t h i ss u b j e c ti sf r o map r o j e c to fz t es o f t w a r et e c h n o l o g i c a lc o m p a n y f 1 、a n c h a n g ) n a m e d “m o b i l eo l y m p i c ”w h i c hh a sb e e nc o m p l e t e da n dt e s t e d k e yw o r d s ：i n t e l l i g e n tt r a n s p o r t a t i o ns y s t e m ；a c c e p t e r ；c o m p o n e n td e s i g n i n g ； e n t e r p r i s ej a v ab e a n ；j a v am e s s a g es e r v i c e 哈尔滨工程大学 学位论文原创性声明 本人郑重声明：本论文的所有工作，是在导师的指导 下，由作者本人独立完成的。有关观点、方法、数据和文 献的引用已在文中指出，并与参考文献相对应。除文中已 注明引用的内容外，本论文不包含任何其他个人或集体己 经公开发表的作品成果。对本文的研究做出重要贡献的个 人和集体，均已在文中以明确方式标明。本人完全意识到 本声明的法律结果由本人承担。 作者( 签字) ：毛叁垒 日期：2 0 吵年月e t 1 t 项目背景 第1 章绪论 在2 0 0 8 年奥运会即将来临之际，由中国移动通信集团公司主导提出，并 联合华为技术有限公司、中兴通讯股份有限公司、霄霆万钧网络科技有限公 司等企事业单位，结合c n g i 的特点，推出了以2 0 0 8 年北京奥运作为应用场 景的开放试验和应用示范一一c n g i 移动奥运示范系统。其意义在于：一方面 服务于我国的0 8 北京奥运，充分体现“科技奥运”的理念；另一方面充分发 掘和体现i p v 6 的特点，并验证i p v 4 业务的平滑过渡和兼容性。 “移动奥运”示范项目包括“奥运风云”业务、奥运智能交通相关业务 和奥运安保应用等三个部分。智能交通系统( i t s ) 作为“移动奥运”项目的 一个组成部分，通过车载移动终端、手持移动终端、固定视频采集点等设备， 采集车辆的地理位置坐标、交通路况的文本、视频等信息，然后通过g p r s 和c n g i 网络将上述三种信息传送到智能交通信息服务中心，进行数据存储、 数据分析、数据分发等操作。它主要实现车辆定位、路况信息广播、视频监 控等功能。本课题来源于智能交通系统的子系统一一受理台系统。 1 2 智能交通的发展和研究现状 1 2 1 国外有关研究动态 ； 在美国，智能运输系统应用发展较快的几个方面分别是，车辆安全系统， 电子收费，公路及车辆管理系统，实时自动定位系统，商业车辆管理系统。 欧洲在智能运输系统应用方面的进展介于日本和美国之间由于欧洲各国 政府的分散投赘和各国的i t s 需求不一致，在整个欧i i i 建立统一的变通信息 服务系统困难重重。然而在开发先进的旅行信息系统( a t i s ) ，先进的车辆控 制系统( a v c s ) - 先进的商业车辆运行系统( a c v 0 ) ，先进的电子收费系统方 面，前景十分诱人。 哈尔滨工程大学硕士学位论文 正在欧洲开展的d e l t a 计划，在汽车出厂之前，车载信标已经被集成在 车载计算机中成为车辆识别和同路边设备进行通讯的车辆必选器件，信标 的电源直接由汽车供应 日本政府在i t s 领域进行了大量的资金、政策等方面的投入，以期形成 i t s 产业推动日本经济发展在过去的5 到6 年的时间里，已经有近4 0 0 万 套车内导航系统在市场上应用。日本的i t s 应用主要是在交通信息提供、电 子收费、公共交通、商业车辆管理以及紧急车辆优先等方砸。 除了欧、美、日以外，新兴的工业国家和发展中国家也开始i t s 的全面 开发和研究，如韩国由建设交通部牵头制定了全面的i t s 框架结构和发展计 划，新加坡已经在全国开始推行不停车电子收费。世界各国纷纷开展i t s 的 研究和开发。除了解决交通问题的原因之外，另一个重要的出发点则是i t s 将成为继军事应用之后高新技术最大的应用市场。一。 i 2 2 国内有关研究动态 我国智能运输系统研究起步较晚，但是发展速度很快。我国交通运输界 和国家政府部门已认识到开展智能运输系统研究的重要性。国家科技部已于 1 9 9 9 年1 1 月批准成立了国家智能交通系统工程技术研究中心，并于2 0 0 0 年 3 月组织全国交通运输领域专家组成专家组。起草完成了中国智能运输系统 体系框架。国家。十五”智能运输系统示范工程项目计划己经初步确定，包 括1 0 余个示范工程项目，几十个研究内容，其中交通诱导系统是一项重要研 究内容。下面举几个i t s 在我国应用的实例： ( 1 ) 北京成功地完成了英国s c o o t 及南斯拉夫t 3 z a 贝s y t 一7 f 交通信息 控制系统的引进、安装和运行管理的研究 ( 2 ) 上海市成立了出租车联合调度公司，建立全行业g p s 调度中心，将 上海市区2 0 0 多k 舒，按每块i 8 k m 分成1 2 4 个区域。采用数码通讯传输把 讯息发送时间缩短至千分之一秒。这一调度系统具有组呼和群呼的功能，改 变了原来无线电调度只能与一辆车对讲情况，调度员在接听电话的同时，可 将用户的消息与用户所在地区待租车辆信息分别键入系统，电脑自动按待租 车捧列顺序逐一询问，司机接到信息后，只需在接收器上按一下确认的键码， 所在用户的信息资料就会显示在接收器上 2 啥尔滨工程大学硕士学位论文 ( 3 ) 深圳市公共交通公司应用大面积非接触式i c 卡储值系统。该系统包 括；车载验票机、余额验票机、数据采集和处理等系统。 中国在i t s 的开发和研究上，由于起步较晚，起点也较低，因此与国外 还有相当太的距离但在我国一些大城市中，由于人口密度大，道路条件差。 交通拥挤程度其实已经超过发达国家的大城市。因此，我国已有越来越多的 交通运输研究人员投入到智能交通系统的研究和运营管理中，为我国交通运 输事业的现代化、科学化贡献力量“ 1 3 课题研究的主要内容 本文研究的课题来源于中兴软件技术( 南昌) 有限公司为中国移动开发 的移动奥运项目智能交通系统。受理台子系统位于整个后台数据处理平台的 前端，是后台系统的主要数据来源，其性能的稳定和服务质量的优劣将对整 个系统的性能产生重大的影响， 论文主要研究工作如下： ( 1 ) 分析受理台子系统在整个系统中的位置。确定其同其它业务模块的 数据交互关系及数据传输模式。 ( z ) 根据受理台系统的特点，确定了c s 模式的平台架构。对整个子系 统进行建模分析，设计了系统的用倒模型图和活动图，为系统的后续开发奠 定了良好的基础。 ( 3 ) 研究j 螨、e j b 等开源软件的a p i 及其在分布式系统应用中的优缺点， 确定了用j 璐进行异步消息调用，用e j b 中的无状态会话b e a n 作为同步远程 方法调用的对象通讯模式， ( 4 ) 研究了谩计模式的多种原理方法，将柳c 、单子、抽象工厂等多种 设计模式应用到系统设计中，极大地提高了软件工程的质量。 ( 5 ) 研究如何克服j a v a 作为一门跨平台的语言不能直接调用_ i n d o w s 本地组件的问题，继而，利用j a v a 快速稳定、高效的调用w i n d o w s 底层组 件，制作一个视颓播煎器，从而克服j m f 框架支持单一视频文件的缺点。 ，：堕玺鎏三堡奎茎璧圭耋堡鎏耋；。；。 1 4 论文的内容和结构 本文从研究智能交通系统入手，在明确了受理台子系统在智能交通系统 中的位置的基础上对受理台系统的需求做了必要的分析，明确了受理台予 系统的基本功能和基本结构，继而论述了以j 峪进行异步消息通讯、以e j b 作为远程方法同步调用为通讯手段的受理台子系统的构建过程。最后，在 e c l i p s e 平台上实现了各个模块的功能。 论文结构如下： 第l 章：介绍了进行课题研究的项目背景，分析了智能交通在国内、外 的应用概况，明确了论文研究的主要内容及目标，并给出了论文的总体结构。 第2 章：概括介绍了项目实施过程中涉及到的主要技术、j 2 髓容器组件、 f t p 协议和组件设计思想，茼要说明了它们的应用场合和注意事项。 第3 章：对受理台系统进行了需求分析和设计实现，对其各个功能模块 的架构设计和实现原理做了必要的说明。 第4 章：就系统实现过程中涉及到的主要技术解决方法做了详细的论述。 ；堕玺鎏三堡奎茎堡圭茎堡丝耋；。 第2 章主要技术及背景介绍 2 1 j n i 技术介绍 j n l ( j a v an a t i v ei n t e r f a c e ) ，即j a v a 本地化方法，是对混合编程技 术的简单扩展，其目的是为了实现j a v a 不擅长的东西，比如大量的计算和多 媒体播放等。 2 1 1 应用场合 一些主要的j a m 技术，如j b c 和跚i ，大部分都采用j n i 方式实现。 但是。采用j n i 会影响程序的平台无关性。所以只能在特别需要的地方才能 使用。通常来说，如果遇到下面的情况。我们可以考虑j n i 。 ( 1 ) 需要直接操作物理设备，而没有相关的驱动程序，这时候我们可能 需要用c 甚至汇编语言来编写该设备的驱动，然后通过j n l 调用。 ( 2 ) 涉及大量数学运算的部分，用j a v a 会带来些效率上的损失。 ( 3 ) 用j a v a 会产生系统难以支付的开销，如需要大量网络链接的场合 “) 存在大量可重用的c c h 代码。通过j n i 可以减少开发工作量，避 免重复开发“一。 2 1 2 使用注意事项 ( 1 ) 由于j a v a 安全机制的限制，不要试图通过j a r 文件的方式发布包 含本地化方法的a p p l e t 到客户端。 ( 2 ) 注意内存管理问题，虽然在本地方法返回j a v a 后将自动释放局部 引用，但过多的局部引用将使虚拟机在执行本地方法时耗尽内存。 ( 3 ) j n i 技术不仅可以让j a v a 程序调用c c + + 代码，也可以让c l c h 代 码调用j a v a 代码。 2 2e j b 组件简介 e n t e r p r i s ej a v a b e a n ( e j b ) 是一个关于用j a v a 语言开发的可部署的服务 器端组件。这个在客户端和服务器端的协议能使组件运行于任何应用服务器 中。叮b 组件是可部署的，它们可被导入到作为组件主机的应用服务器中。 这样，e j b 组件开发人员可以集中精力实现业务逻辑，把大量资源管理工作 留给容器。同时简化开发、配置与部署e j b 的步骤。标准埘l 部署描述项定 义e j b 如何在e j b 容器中工作“ 2 2 1e j b 分类 b j b 2 0 定义了三种不同类型的企业b e a n ：s e s s i o nb e a n ( 会话b e a n ) ， e n t i t ，y b e a n ( 实体b e a n ) 和m e s s a g e - d r i v e nb e a n ( 消息驱动b e a n ) “”。 ( 1 ) 会话b e a n 主要甩来描述系统的业务逻辑。一个会话b e a n 代表应用 程序和客户的一次会话过程。会话b e a n 可以是无状态的( s t a t e l e s s ) 或有状 态的( s t a t e f u l ) 。无状态是指不维护客户会话状态，在某个方法调用结束后， 实例变量不再拥有状态。有状态是指会话b e a n 需要维护同客户端的会话状态 直至该b e a n 被撤销。这种分类主要适用不同的数据操作“。 ( 2 ) 实体b e a n 是用于表示和维护应用数据实体的组件。简单地说，数据 实体就是程序所使用的数据库中的数据对象。一个实体b e a n 代表存放在数据 库的一类数据对象，它是数据库内数据在e j b 容器里的翻版。 ( 3 ) 消息驱动b e a n 用来异步地处理j a v a 消息服务( j a v am e s s a g e s e r v i c e s ) 的消息，可以实现客户和服务器之间的异步通信。 2 2 2e j b 体系结构 e j b 体系结构的客户端包含e j b 接口，用于调用e j b 上的业务特定方法， 以及处理服务器端对象甸柄。可以用r u l i i o p 映射作为接口机制。e j b 基本 体系结构如图2 。1 所示”1 。 e j b 体系结构中主要应用程序特定元素有： e j b 客户机；e j b 客户机应用程序使用j n i ) i ( j a v an a m ea n dd i r e c t o r y i n t e r f a c e ) 查找本地接口，以便按分布式或在同一容器进程中与e j b 服务器 6 哈尔滨工程大学硕士学位论文 功能通信。 e j b 主接口：对客户机提供分布式操作生成、删除、查找e j b 远程接 口对象句柄提供相应的操作。s t u b 负责处理主接口请求和拆装主接口响应 e j b 远程接口：提供对特定e j b 定义的业务客户机接口方法。相应的s t u b 负责处理远程接口请求和拆装远程接口的响应 e j b 实现：由开发人员实现的实际e j b 应用程序组件。提供任何应用程 序特定业务方法的调用、创建、删除、查找、激活、钝化、数据库存储和数 据库加载逻辑。 容器e j b 实现( s k e l e t o n 与代理) ：容器管理分布通信s k e l e t o n ，编组 与拆装客户机收发的数据容器还可以存储e j b 实现实例，并且使用代理在 调用发送给e j b 实现实例之前，执行与特定e j b 有关的服务管理操作。 2 3j m s 消息服务 图2 ie j b 基本体系结构 2 3 1j m s 简介 消息中问件m o m ( m e s s a g eo r i e n t e dm i d d l e w a r e ) 为分布式企业应用系 统中创建、发送、接收和阅读消息提供了一套可靠通用的方法。已有的m o m t 哈尔滨工程大学硕士学位论文 系统包括i b m 的m q s e r i e s 、m i c r o s o f t 的惦m q 和b e a 的w e b l o g i c 等。由于 没有一个通用的标准，这些系统很难实现互操作和无缝连接。 j a v a m e s s a g e s e r v i c e ( j 憾) 是s 删提出的瞽在统一各种m o i l 系统接口 的规范，它制定了基于j a v a 点到点( p 2 p ) 和发布订阅( p u b s u b ) 异步消 息传递的标准，为j a v a 程序提供了一种刨建、发送、接收和读取企业级消息 系统消息的一般方法” 2 ，3 ，2j m s 消息收发模式 ( 1 ) 点到点( p t p ) 消息收发模式 在j 船中，点到点( p t p ) 式的消息发送使用j m s 服务器管理的一个叫做 0 u e u e ( 队列) 的对象来管理发送者到接收者的消息数据流j m s 消息发送者 又叫做消息生产者。而j m s 消息接收者又叫做消息消费者。消息生产者获得 服务器上的一个j 峪q u c u e 的引用，并向该引用发送消息。当消息到达时 j 煅提供者负责通知唯一一个接收该q u e u e 消息的消费者。j 惦提供者每次发 送消息后( 可选地) 将接收到消息收据的确认。点到点( p t p ) 式消息的收发 过程如图2 2 如示。 由图2 2 可以看出，在点到点( f r f ) 式消息的收发过程中，消息的发布 者和消息的接收者是一一对应关系“”。 图2 2 点到点( g r p ) 消息通讯模式 ( 2 ) 发布订阅( p u b s u b ) 消息收发模式 在j 船中，发布订阅式的消息发送使用j m s 管理的一个叫做t o p i c ( 主 题) 的对象来管理发布者到预订者的消息流。3 m s 发布者又叫做消息生产者 面3 m s 预订者又叫做消息消费者。消息生产者获得服务器上一个t o p i c 的引 用，并向该t o p i c 发送消息。当消息到达时，j 崛提供者负责通知所有预订 了该t o p i c 的消息消费者。j 璐提供者每次发送消息后( 可选地) 将接收到 b 哈尔滇工程大学硕士学位论文 消息收据的确认。图2 3 是发布订阅式消息的收发示意图 由图2 3 可以看出，在发布订阅式消息的收发过程中，消息的发布者与 消息的接收者是一对多的关系，并且每一组消息的订阅者都可以共享一个 t o p i c 消息引用对象”1 ”。 图2 3 发布订阅( p u b s t m ) 式的消息通讯模式 2 4t i i v c 设计模式 2 4 1i i v c 设计模式概述 耵c 本来是存在于d e s k t o p 程序中的，m 是指数据模型，v 是指用户界面， c 则是控制器。使用m v c 的目的是将m 和v 的实现代码分离，从而使同一个 程序可以使用不同的表现形式比如一批统计数据可以分别用柱状图、饼图 来表示。c 存在的目的则是确保m 和v 的同步，一旦m 改变，v 应该同步更新。 m v c 是一种设计模式。它强制性的使应用程序的输入、处理和输出分开。 使用眦应用程序被分成三个核心部件：模型、视图、控制器它们各自处 理自己的任务”。 ( 1 ) 视图 视图是用户看到并与之交互的界面。视图向用户显示相关的数据，并能 接收用户的输入数据，但是它并不进行任何实际的业务处理视图可以向模 型查询业务状态，但不能改变模型。视图还能接收模型发出的数据更新事件， 从而对用户界面进行同步更新。唧c 一个大的好处是它能为应用程序处理很 多不同的视图。在视图中其实没有真正的处理发生。不管这些数据是联机存 储的还是一个雇员列裹；作为视图来讲，它只是作为一种输出数据并允许用 哈尔滨工程大学硕士学位论文 户操纵的方式。 ( 2 ) 模型 模型表示企业数据和业务规则在m y c 的三个部件中模型拥有最多的 处理任务。被模型返回的数据是中立的，就是说模型与数据格式无关，这样 一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以 被多个视图重用，所以减少了代码的重复性。 ( 3 ) 控制器 控制器接受用户的输入并调用模型和视图去完成用户的需求所以当应 用程序界面中的触发器被触发时。控制器本身不输出任何东西和做任何处理 它只是接收请求并决定调用哪个模型构件去处理请求，然后用确定用哪个视 图来显示模型处理返回的数据。 ( 4 ) m v c 处理过程 蝌c 处理过程如下： 8 ) 首先控制器接收用户的请求，并决定应该调用哪个模型来进行处理： b ) 然后模型根据用户请求进行相应的业务逻辑处理，并返回数据： c ) 最后控制器调用相应的视图来格式化模型返回的数据，并通过视图呈 现给用户。 2 4 2w c 设计模式的优点 ( 1 ) 缺点 州c 的缺点是由于它没有明确的定义，所以完全理解m v c 并不是很容易。 使用耐c 需要精心的计划，由于它的内部原理比较复杂。所以需要花费一些 时间去思考程序设计人员将不得不花费相当可观的时间去考虑如何将肌 运用到应用程序，同时由于模型和视图要严格的分离，这样也给调试应用程 序到来了一定的困难。每个构件在使用之前都需要经过彻底的测试。一旦构 件经过了测试，就可以毫无顾忌地重用它们了。， ( 2 ) 优点 首先，多个视图能共享一个模型。比如，同一个应用程序会提供多种用 户界面，同一个数据比例模型可以表现为多种表格、圆柱等多种形状。在m v c 设计模式中，模型响应用户请求并返回响应数据，视图负责格式化数据并把 哈尔滨工程大学硕士学位论文 它们呈现给用户，业务逻辑和表示层分离，同时一个模型可以被不同的视图 重用，所以大大提高了代码的可重用性。 其次，模型是自包含的，与控制器和视图保持相对独立，可以方便地改 变应用程序的数据层和业务规则。由于m v c 的三个模块相互独立，改变其中 一个不会影响其他两个。所以依据这种思想能构造蔑好的松耦合的构件。 此外，控制器提高了应用程序的灵活性和可配置性。控制器可以用来连 接不同的模型和视图去完成用户的需求，也可以为构造应用程序提供强有力 的手段。给定一些可重用的模型和视图。控制器可以根据用户的需求选择适 当的模型进行处理然后选择适当的视图将处理结果显示给用户0 1 2 5f t p 协议简介 f t p 协议“的任务是从一台计算机将文件传送到另一台计算机，它与这 两台计算机所处的位置、联接的方式、甚至是是否使用相同的操作系统无关 f t p 有两种传输模式及两种工作模式： ( 1 ) 两种传输方式：a s c i i 传输模式和二进制数据传输模式。 a ) a s c i i 传输方式 此模式假定用户正在拷贝的文件包含简单a s c i i 码文本，如果在远程机 器上运行的不是u n i x ，当文件传输时f t p 通常会自动地调整文件的内容以便 于把文件解释成另外那台计算机存储文本文件的格式 b ) 二进制传输模式 在二进制传输中，保存文件的位序，原始和拷贝的是逐位一一对应的。 如果在a s c i i 方式下传输二进制文件，即使不需要也仍会转译。这会使传输 稍微变慢，也会损坏数据。 ( 2 ) 两种工作模式：s t a n d a r d ，也就是p o r t 方式，这是主动方式；另一 种是p a s s i v e ，也就是p a s v ，称为被动方式 a ) p o r t 模式 ， p o r t 模式下。f r p 客户端首先和f t p 服务器的t c p2 1 端口建立连接，通 过这个通道发送命令，客户端需要接收数据的时候在这个通道上发送p o r t 命令。p o r t 命令包含了客户端用什么端1 3 接收数据。在传送数据的时候，服 1 l 哈尔滨工程大学硕士学位论文 务器端通过自己的t c p2 0 端口连接至客户端的指定端口发送数据。f t p s e r v e r 必须和客户端建立一个新的连接用来传送数据。 b ) p a s s i v e 模式 p a s s i v e 模式在建立控制通道的时候和s t a n d a r d 模式类似。但建立连接 后发送的不是p o r t 命令，而是p a s v 命令。f r p 服务器收到p a s v 命令后随 机打开一个高端端口( 端口号大于1 0 2 4 ) 并且通知客户端在这个端口上传送 数据，客户端连接f t p 服务器此端口，然后f t p 服务器将通过这个端口进行 数据的传送。这个时候f r ps e r v e r 不再需要建立一个新的和客户端之间的连 接“ 2 6 本章小结 本章介绍了项目实施过程中所应用到的主要技术及其相关背景，阐述了 一种通用组件设计模式。州i 方法用于本地系统方法调用，解决了j a v a 如何 集成w i n d o w s 系统a c t i v e x 可视化组件的问题。e j b 组件和j 骼消息服务系 统用以实现同步方法调用和异步消息通知。m v c 设计模式用于组件的开发， 增强了组件的可重用性和易维护性，使组件的开发更易于控制。f t p 协议用 于实现视频文件的上传、下载，满足了多用户、大流量视频文件传输的需要。 第3 章系统分析与设计 3 1 系统建模及其功能分析 3 1 1 受理台系统在移动奥运智能交通系统中的位置 受理台系统处于移动奥运智能交通前台数据采集系统与后台数据处理系 统之间，它从f t p 处理服务器接收移动视频信息，从固定视频采集系统接收 固定视频信息，继而为后台所使用到实时交通信息提供可靠的数据来源。其 在智能交通系统中的位置如图3 1 所示： 图3 1 移动奥运智能交通系统数据交互关系图 3 1 2 受理台系统与智能交通后台模块的数据交互关系 受理台系统包括受理台服务器和受理台客户端两部分。受理台客户端处 于实时交通后台系统的最前端，为实时交通后台系统所使用到实时交通信息 提供可靠的数据来源，是后台系统的数据采集源。受理台客户端的数据来源 包括固定视频采集系统拍摄的固定视频信息和f r p 服务器传来的移动视频信 息。受理台服务器主要处理受理台客户端与智能交通后台系统各业务模块之 间的信息传送。受理台服务器主要负责三部分工作：第一，担任受理台客户 端与用户管理、信息栈和数据库三个模块之间数据传递的中介者。第二，接 收f i p 服务器上传的视频文件并根据预定的算法分发给受理台客户端。第三， 保持受理台客户端与其他模块之间的网络通讯链路并处理异常状态受理台 子系统与各模块数据交互关系如图3 2 所示： 图3 2 受理台系统数据交互关系图 3 1 3 系统功能模型 实时交通受理台子系统所实现的主要功能，如图3 3 所示； 图3 3 受理台系统功能模型 l l 哈尔滨工程大学硕士学位论文 各个功能模块具体说明如下： ( 1 ) 视频监控模块 a ) 固定视频监控通过集成外购的固定视频监控系统，对编号了的固 定视频采集点进行监控，发现异常情况，通过应用程序悬浮窗发送 事件消息体到实时交通信息栈。由其他节点去取相关的信息。 b ) 移动视频监控。响应f t p 服务器文件发送消息，然后采用特定的分 发策略分发给备个受理台客户端。受理台客户端从f t p 服务器下载 移动视频文件并对移动视频信息进行实时监控，发现异常情况，通 过应用程序悬浮窗发送事件消息体到实时交通信息栈，由其他节点 去取相关的信息 ( 2 ) 建权登录模块 a ) 权限认证根据用户输入的用户名和密码核实受理台用户的权限， 并根据相应的权限初始化各功能菜单。合法的受理台用户分为普通 坐席和班长坐席，不同的用户具有不同的操作权限班长坐席拥有 所有的操作权限，而普通用户则不具有查看系统日志的权限。 b ) 数据初始化。用户权限认证通过后，受理台客户端通过服务器到数 据库服务器和本地配置文件读取初始化数据，然后将读取的数据正 确归类并初始化客户端界面信息。 ( 3 ) 事故处理模块 a ) 分类选择。事故类型分为多种可选类型，比如交通状况、场馆状况、 天气状况等等，通过视频监控得到的事故信息即可通过点选事件列 + 表而快捷的设置，也可编辑备注信息栏自定义事故类型。 b ) 事故信息上报。对所发生的事故信息要实时的发送到信息栈，以方 便其他处理模块及时收取信息。事故信息在入栈前要做相应的处 理，如经纬度数据格式的转换，时问日期的规范等等。 ( 4 ) 日志功能模块 a ) 操作日志记录。视频文件发放给受理台子系统处理时，受理台子系 统对视频文件所做的一切行为，包括受理时同、交由哪个坐席处理、 坐席处理的状态等等信息都要记录日志，以便明确责任方和系统维 护 1 5 哈尔滨工程大学硕士学位论文 b ) 系统日志查看。班长坐席能够查看所有操作日志记录，以及各个记 录的详细信息 ( 5 ) 系统维护模块 a ) 网络状态维护。负责监控受理台子系统与用户管理、数据库、信息 i 栈和f t p 服务器等模块的链路状态是否畅通，各服务模块的服务是 否正常运行等 b ) 本地服务维护。对本地缓存的移动视频文件，能够根据其状态进行 分类，比如是否被受理等。对于已经受理的视频文件。受理台坐席 可以视情况予以删除。视频文件播放时所用浏览器，本地接收视频 文件的上限等均可由受理台坐席自行配置。 3 2 系统框架设计 3 2 1 内部整体框架 根据在整个平台中的功能划分本子系统，采用c s 结构，服务器端负责 与其他各个模块的通讯及业务处理，客户端主要处理视频文件信息的采集工 作。如图3 4 所示。 一1r 一一 受理台予荒统i l 一后白业务模块一j i i i 图3 4 受理台系统框架设计图 3 2 2 外部f t p 文件服务器交互框架 | 一耋 j 了厂骶l 田譬 l 菲i 测粥 | 区妒；倒霉 3 3 模块设计说明及其用例 3 3 1 受理台客户端登录权限认证 受理台客户端程序打开前需要进行权限认证，只有合法的用户才可打开 受理台客户端程序，并根据其响应的权限初始化受理台客户端各功能菜单。 权限认证流程如图3 6 所示。 躅3 6 用户登录权限认证流程图 ( 1 ) 业务流程 受理台客户端向受理台服务器发送登录信息和登录请求。 受理台服务器根据登录信息查询用户管理模块，确认用户权限。 用户管理模块将用户权限认证结果返回给受理台服务器。 若该用户的登录请求类型为初次登录，则请求下载业务数据，否则转 到。 业务应用数据库将业务数据发送至受理台服务器。 受理台服务器将权限认证结果和业务数据发送至受理台客户端。 ( 2 ) 异常处理 在，的执行过程中，分别设置了服务的时间限制，超过 各自规定的时问则认为服务超时。服务超时也被定义为异常的一种 受理台服务器根据异常类型的不同，发送给客户端相应的异常标识代码， 受理台客户端根据接收到的异常代码在m e s s a g e b o x 中提示相应的异常信息。 当 发生服务超时异常时，受理台客户端无需等待受理台服务器的返回信 息，而直接结束本次会话，并显示服务器超时异常提示信息。 3 3 2 受理台日志处理 受理台客户端根据其权限不同分为普通台和班长台。普通台不具备查询 日志的权限，班长台具备所有权限。受理台客户端要记录其所受理的视频文 件的日志信息，在这一点上无权限之分。下面以普通台记录日志，班长台查 询日志为例，对日志处理流程加以说明，如图3 7 所示。 f受理f | j 用服务器 图3 7 受理台内部处理流程 ( 1 ) 向日志数据库写入日志流程 每个受理台把日志信息以记录的方式发送给受理台应用服务器。 受理台服务器将信息写入日志数据库。 日志数据库写入成功后，向受理台服务器发送确认消息。 受理台服务器将确认消息发送给受理台客户端。 ( 2 ) 从日志数据库查看日志流程 班长台向受理台服务器发送查询日志申请及其参数信息。 受理台服务器将参数预处理之后，查询日志数据库。 日志数据库将查询的结果返还给受理台服务器。 受理台服务器将查询结果返还给受理台客户端。 ( 3 ) 异常处理 流程或在规定时间内没有完成，即客户端没有及时收 到 代表的返回结果，客户端程序则启动s s a g e b ，提示异常信息。若 由或产生异常，受理台服务器向客户端返回错误代码，客户端根据 错误代码进行提示“日志数据库无响应，请稍后进行查询”；若由或 产生异常，导致在规定的时间内无结果返回，客户端程序将提示“服务器 或网络繁忙，请稍后进行查询”。 3 3 3 移动视频文件下载 ( 1 ) 客户端登录f t p 服务器流程 ； ；堕垒鎏三坠兰垄圭耋堡i 垒圣；。； 客户端登录f t p 服务器流程如图3 8 所示 n 圉3 8f 1 p 服务器登录流程图 a ) 流程介绍 每个受理台客户端程序都作为f t p s e r v e r 的一个客户端，持有各自的用 户名和密码。当受理台客户端登录受理台服务器成功后，需要从服务器给的 配置数据中读出y t p s e r v e r 的服务器地址和服务端口号，然后登录 f t p s e r v e r 。 受理台客户端登录f t p s e r v e r 时，登录进程首先需要实例化一个 f r p c i i e n t ，即实例化f t p s e r v e r 客户端对象。然后调用f t p c i i e n t 对象的 l o g i n ( ) 方法进行登录认证。若登录返回成功信息则设置受理台客户端登录标 识l o g i n s u c c e s s 为t r u e 。若f t p s e r v e r 拒绝登录或链接超时，则检查网络 是否畅通，即，用f t p c i i e n t 的c o n n e c t ( ) 方法。若网络通畅，则分析f f p s e r v e r 2 0 哈尔滨工程大学硕士学位论文 拒绝登录的返回信息并记录，以供上报受理台服务器f t p s e r v e r 无法登录的 原因。然后，将受理台客户端登录标识l o g i n s u c c e s s 设置为f a l s e 。 b ) 说明 l o g i n s u c c e s s 为布尔变量，其意义为标识受理台客户端是否已经成功登 录f r p s e r v e r ，成功登录为t r u e ，未成功登录为f a l s e 。 ( 2 ) 视频文件输出流设置 视频文件输出流设置如图3 9 所示 圈3 9 视频文件输出流设置流程 a ) 流程介绍 ， f t p c i i e n t 下载文件时，需设置好文件输出流( o u t p u t s t r e a m ) ，而文件 输出流的设置则需要正确的路径名，输出文件的存储则需要足够的磁盘空间。 视频文件的默认存储路径写在受理台客户端的配置文件里，在进程开始 时，首先从配置文件中把视频文件的存储路径信息读出，然后检查当前路径 是否有足够的磁盘剩余空间若磁盘剩余空间不足，则将文件创建失败标识 2 l 哈尔滨工程大学硕士学位论文 f i l e n o t f o u n d 设置为t r u e ，并且弹出磁盘清理对话框以供用户在对话框中 进行磁盘“清理”或者“取消”“清理”菜单项包