集成应用平台开发

集成应用平台开发（精选9篇）

集成应用平台开发 第1篇

随着计算机与网络技术的飞速发展, 软件已经渗透到了社会经济和建设的各个领域, 在信息社会中发挥着至关重要的作用。针对越来越多的软件应用需求, 为了保证这些软件的成功开发, 人们建立起软件工程思想, 希望软件开发能够借鉴其他工程学科的成功做法, 走“软件工程化”的道路。要实现软件的工程化, 最关键是建立以配套的计算机辅助软件工程工具组成的软件开发平台。目前, 人们在软件开发和相关应用技术方面都有了很大的提升;但现有的软件集成开发产品, 大多停留在发展完善阶段, 相关的研究多集中在软件集成开发平台的扩展机制上, 缺乏对软件集成开发环境体系结构以及评价指标方面的研究。文章从6个方面, 即结构性指标、开发指标、协作性指标、成熟度指标、持续性指标和综合指标进一步阐述软件集成开发平台的评价体系[1,2,3]。

1 结构性指标

结构性指标体现在软件集成开发平台的体系结构设计和关键机制设计上。因而可以从功能层划分、微内核设计、扩展机制设计和系统插件设计这四个方面建立指标进行定性的分析。

功能层划分:功能层一般分为业务功能和系统功能两层, 平台功能层的划分是否符合此两层标准是评价功能层划分合理的重要指标;微内核设计:微内核是内核的一种精简形式, 将通常与内核集成在一起的系统服务层被分离出来, 变成可以根据需求加入的选件, 对系统进行升级, 用新模块替换旧模块而非改变整个系统, 这样就可提供更好的可扩展性和更优良的应用环境;扩展机制设计:通过插件机制实现集成开发平台的扩展渐渐地成为人们的共识, 其直接关系到平台良好的成长性;系统插件设计:系统插件一般包括工作空间、工作平台、协同开发支持和帮助等, 系统插件设计的合理和丰富直接关系到开发平台基本功能的完备性和易用性。

2 开发指标

开发指标体现在软件开发的各个环节, 主要可以从平台对软件开发的支持程度去建立指标[4]。

编译支持:编译直接影响软件的最终质量, 编译器对代码错误的定位准确度以及对后续开发过程的支持都是考察该指标的依据;调试支持:调试直接影响开发效率和代码质量, 支持局部变量、单步执行等流程控制功能、支持条件断点、堆栈显示和监视、支持远程调试功能、线程的查看及修改以及支持会话都是对该指标进行评价的因素;测试支持:测试支持考察的是开发平台对测试模式、测试方法的支持以及测试效率的优劣, 也是影响开发效率和代码质量的重要指标, 对优秀的测试插件支持是评价该指标的重要依据;界面设计与开发:开发平台对界面开发和设计的支持度是界面设计与开发考察的内容, 其直接影响用户需求的表达和开发的效率, 可视化开发工具、界面元素的支持等都是影响该指标的因素;开发帮助:该指标考察的是软件开发平台对软件开发全过程的帮助情况, 具体包括在线帮助、帮助文档、设计和编码帮助、开发实例帮助、解决方案支持等;国际化机制:国际化是指为同一应用程序开发出多套语言包, 使应用程序可以应用于不同的国家和地区, 国际化是提高产品国际竞争力、优化用户体验的重要手段;代码编辑:代码编辑考察的是代码编辑器的人性化设计, 其直接影响到开发效率和代码质量, 源程序自动纠错和自动排版、代码自动提示等都是考察该指标的因素;产品发布:该指标考察的是开发平台对产品发布功能的支持度, 软件产品发布方式的易用性是考察该指标的因素。

3 协作性指标

协作性指标体现在集成开发平台对软件开发领域一些前瞻性概念和方法的支持度上。具体包括5个部分:开发社区、知识管理、协作开发、版本管理和在线帮助[5]。

开发社区目前在开源软件社区表现最为显著, 成熟的开发社区是考察一个软件协同开发和软件开发过程的重要因素;知识管理创造价值的过程, 也是流程运行的过程, 必须将知识管理紧紧的运用到开发流程体系, 为开发的流程运行提供最合适的人员和工具;协作开发考察的是开发平台对软件团队协同开发的支持度, 软件协作开发方式的易用性是考察该指标的因素;版本管理是开发制品改进的基石, 开发制品达到一个稳定状态后称为一个版本, 版本管理自然管理了开发制品的稳定性;在线帮助提供软件开发平台的API查询等服务, 该指标考察的是开发平台是否支持帮助的在线查询。

4 成熟度指标

成熟度指标体现在插件支持、开源项目组活跃程度、产品市场化程度、成功应用案例和应用模式支持这5个方面[6,7,8]。

插件支持:一个成熟的软件集成开发平台必须有成熟的插件去支持其应用, 软件开发的各个环节都必须有与之对应的多种插件进行支持, 以确保软件开发平台的专业性、通用性和易用性, 因此成熟的第三方插件便成为衡量软件开发平台成熟度的重要指标;开源项目组活跃程度:每个软件集成开发平台都有官方的开源项目组, 其主要工作是组织开发新版本开发平台和插件、新研功能上具有代表性的插件以及在应用领域有代表性的应用系统;产品市场化程度:作为产品, 软件集成开发平台需要一个良性的市场环境去支持其发展, 具体表现在有良好的研发资金链以确保其持续稳定的推出新版本适应新的需求, 有多种推广产品行之有效的手段确保其市场占有率以及商业化插件的应用程度;成功应用案例:基于软件开发平台的成功应用案例, 可以有效地降低同类软件产品的开发难度和开发成本, 具有丰富、典型的成功应用案例是软件开发平台成熟度的重要标志;应用模式支持:软件开发平台应该提供多种应用模式的支持, 以适应各种应用领域的需求, 进而降低开发应用软件的成本。

5 持续性指标

持续性指标体现在业界对开发平台的持续性开发、升级、维护, 以及对插件开发的支持上, 可以分为应用前景、厂商支持度和开发群体支持度这3部分[9]。

应用前景:软件开发平台是基于应用情景和技术背景开发的, 应用前景的优劣是考察持续性指标的重要因素;厂商支持度:评价一个软件开发平台还要考虑它的可持续性, 其中厂商支持度是其可持续性的重要保证, 厂商支持度包括对新功能和新版本的开发、对软件开发平台发展趋势的把握、组织开源组进行相关项目的开发和技术支持等;开发群体支持度:与厂家支持类似, 一个软件开发平台的持续性发展离不开开发群体的支持, 开发群体通过开发组、论坛等形式促进和支持软件开发平台的发展, 开发群体支持度体现在开发组的数量和活跃程度、相关论坛的规模和活跃程度以及开源项目排名等。

6 综合指标

综合指标体现在开发平台的总体使用体会和应用领域侧重上, 可以分为应用领域侧重、学习周期和人性化设计3个部分[10,11]。

应用领域侧重:不同厂商和组织研发的软件开发平台具有不同的应用领域侧重, 应用领域侧重直接关系到软件开发平台的生命力;学习周期:熟悉软件开发平台需要学习周期, 这个学习周期不但与程序员本身有关, 还与软件开发平台的插件支持、设计、帮助等有关, 是衡量软件开发平台优劣的综合性指标;人性化设计:与学习周期指标类似, 人性化设计指标在其系统插件设计指标、开发指标、协作性指标、扩展机制设计指标中都有具体的体现。

7 结束语

软件集成开发平台的评价体系由六个部分组成:结构性指标、开发指标、协作性指标、成熟度指标、持续性指标和综合指标。其中结构性指标体现在软件集成开发平台的体系结构设计和关键机制设计上。开发指标体现在软件开发的各个环节。协作性指标体现在开发平台提供新的开发趋势的支持上、成熟度指标和持续性指标体现在开发社区和厂商对平台和插件的支持上, 综合指标体现在开发平台的总体使用体会和应用领域侧重上。

本文根据软件集成开发平台的体系结构, 从6个层面提出了29项软件集成开发平台的评价指标, 基本覆盖了软件集成开发平台的各个方面, 建立了软件集成开发平台的评价体系, 为软件集成开发平台的设计和选择提供重要的参考。

摘要：目前, 软件集成开发平台还处在发展阶段, 功能、应用和发展方向还在探索阶段。但是, 基于软件集成开发平台的应用越来越广泛, 软件集成开发平台相关评价体系及其指标等一系列研究急需进一步开展, 以指导用户的选择和开发。文章研究软件集成开发平台的评价体系, 深入阐述了组成评价体系的6大指标, 旨在为软件集成开发平台的更全面的评价提供可靠的理论依据。

关键词：软件集成开发平台,评价体系,分析

参考文献

[1]相东飞.基于OSGi插件化的应用框架[J].科技信息, 2007 (12) :174-176.

[2]郭娜, 黄永平, 吴学义, 等.基于插件的动态模块框架研究[J].吉林大学学报, 2008 (1) :154-159.

[3]吴明晖, 应昌, 何志均.基于构件的框架式开发方法及其重用库系统[J].计算机工程与应用, 2000 (9) :93-94.

[4]李连云, 李毅, 温利娜, 等.基于Eclipse框架的嵌入式IDE实现[J].计算机工程, 2006 (18) :278-279.

[5]熊江.OSGI的分析和实现及其改进思路[J].计算机科学, 2004 (3) :192-194.

[6]张旻, 麦先根, 贾璐.Eclipse插件开发技术浅探[J].航空计算技术, 2006 (6) :173-176.

[7]陈方明, 陈奇.基于插件思想的可重用软件设计与实现[J].计算机工程与设计, 2005, 26 (1) :172-173.

[8]姜昌华.插件技术及其应用[J].计算机应用与软件, 2003 (10) :10-11.

[9]陈火旺, 王戟, 董威.高可信软件工程技术[J].电子学报, 2003, 31 (12A) :1933-1938.

[10]唐雄燕, 庞韶敏.软交换网络-技术与应用实践[M].北京:电子工业出版社, 2005.

集成应用平台开发 第2篇

粉针是医学临床应用上的重要的药品剂型，广泛应用于静脉注射、肌肉注射用途，不断扩大的用量需求和不断提高的分装要求推动着粉针分装设备的更新和发展，

粉针分装可以通过不同的原理完成。国内螺杆分装机是粉剂制药企业当前的主流设备。螺杆分装机机械原理成熟可靠，设备占地面积小，便于同前后工序的制药、包装设备联线工作。螺杆分装机的机械系统设计经历了几个阶段的发展过程，在每一阶段都有与之相适应的电气控制系统配合工作。机械系统设计目前已趋于稳定成熟，电气控制系统的研究和进步对整机分装性能的进一步提高有着突出的作用。

螺杆分装机的工作原理是通过高速旋转的螺杆向药瓶内推进药粉，快速性和准确性是设备的两个基本要求。缩短螺杆在每次分装推进时的占用时间，就可以提高分装速度，这要求螺杆旋转速度要高，动态响应要快，现在的设备分装速度已可以达到300瓶/分。增加设备上螺杆的数量，可以同时对几只药瓶进行灌装，也是提高设备快速性的有效手段，目前国产分装机上可以见到一头、二头、四头的配置。

为保证分装准确性，通常采用交流伺服电机来直联驱动分装螺杆，早期设备应用过步进电机，但随着设备要求的提高和伺服电机价格的下降，步进电机在该设备上已基本不用。伺服电机动态性能的调整也至关重要，如果加减速响应迟缓，连续灌装中前后相邻两次推进的药粉没有清晰的边界，也会造成装量不准确。

因此，电气控制系统的合理设计与提升螺杆分装机的工作性能直接相关。台达自动化产品可以为螺杆分装机的应用提供一套完整的控制驱动解决方案，设计中通过优化控制结构和应用性能更高的控制器件可以使得分装机工作更快速、更精准。本文中介绍的是应用台达自动化产品设计的一台4头螺杆分装机的应用实例。

控制系统分析

以一台四头螺杆分装机的控制为例，设备要求完成送瓶传送带的变频调速驱动和带动螺杆的4台伺服电机的同步驱动。其它控制要求，如送粉控制、送塞控制、药粉搅拌控制、灌装口药瓶检测、螺杆碰壁报警等，都是常见的开关量控制逻辑，通常的PLC系统都可以完成，本文为突出重点，略去不作讨论。通用设计方案中控制系统结构。

PLC系统为完成1-4轴伺服电机控制，要采用专用的位置控制单元模块，每一台伺服电机接收来自位控单元的脉冲序列完成螺杆推进动作。

对于只要求做1轴或2轴控制的螺杆分装机，通常也会采用PLC主机内置的2轴脉冲输出，但是PLC主机输出的脉冲频率上限都较低，为使伺服电机达到最高转速，需要调低伺服电机的控制分辨率，设备分装的精确性会受到影响。

送瓶传送带电机要用变频器驱动，为实现平滑调速PLC要配置1块D/A单元。

台达自动化方案特色

采用台达自动化产品，为完成上述的任务，设计中采用如图2所示的控制结构。系统中省去了D/A单元和位控单元，节省了成本，减少了配线，更重要的是系统性能有了实质性的提高，

独立自动化技术平台

PLC主机通过RS-485总线与变频器和四台伺服驱动器联在一起。这是台达自动化产品的特色，台达的任何一种控制器件，小到一只温控仪表都在本机上配置有符合MOS-BUS通讯协议的RS-485总线，设计中可以根据系统具体要求灵活地组成不同的控制架构，提高系统的功能和效率。

本例中，共有四台伺服电机，每次分装的动作要求，即电机的旋转角度和旋转速度通过PLC的485通讯接口传送到驱动器的寄存器里，每次动作执行由PLC的一个输出点来触发。

台达PT伺服模式

伺服电机工作在台达特有的PR模式(即寄存器控制定位模式)下，工作时只需要等待触发信号，而不必接收脉冲序列，这也可以看作由内部预置的脉冲发生器来指挥运行。与传统的脉冲序列定位模式(在台达称PT模式，仍可以选有)相比，本机上应用PR模式的优点是：

提高信号抗扰能力

如果伺服电机采用脉冲序列来工作的话，脉冲的传递线路极易受到电气干扰，但在PR模式下，不再有脉冲信号的传递，也就没有抗扰工作的麻烦。

简化布线

PR模式省去复杂的双绞屏蔽线的布线的烦琐，特别在设备被控轴数多的时候，对比特别明显。

提高定位运行品质

伺服电机在定位执行过程中，驱动器知道总的目标值，进而知道确切的脉冲偏差数，不像在PT模式下，一方面伺服的运行使得脉冲偏差在缩小，同时后续的脉冲又使得偏差在增大，因此PR模式在位置闭环运算中可以获得更好的控制品质。

便于系统扩展

当系统要对更多数量的伺服轴进行控制时，只需要把它们分别联在RS-485总线上，对PLC的点数和位控输出的轴数没有影响，便于实现系统扩展。

降低PLC系统成本

通常的系统中，因为对PLC输出脉冲的上限频率的轴数的特别要求，总是要功能相对要强的PLC类型，自然价格就相对要高。而在台达提供的方案中，PLC只要能完成基本的逻辑控制任务即可，实际应用中我们也是采用相对功能简单的模块来实现的。

送瓶传送带的变频器控制，也是同样道理，采用RS-485总线来传送速度指令。因为是数字通讯，速度传送没有偏差，同时也具有简化布线、便于扩展的优点。

结语

集成应用平台开发 第3篇

关键词：OA系统；即时通讯

中图分类号：TP393文献标识码：A文章编号：1007-9599 (2010) 13-0000-01

OA System and Instant Messaging Platform Integration and Application

Liu Guocheng,Zhang Yang

(Guangzhou Institute of Railway Technology,Guangzhou510430,China)

Abstract:For the weakness and disadvantages of the Office Automation system using in colleges,a method that combining the Office Automation system with the instant messaging system is presented.And the application of integration with the instant messaging system and the OA system discussed.

Keyword:Office Automation system;Instant messaging system

一、引言

近年來国内许多高校都出现了多校区并存、远距离教学的办学模式，这使传统的办公方式已难以满足新模式的要求，因而越来越多的高校采用或倾向于实施基于B/S（浏览器/服务器）下的办公自动化系统，即OA系统。一套完善的高校OA系统可以实现公文处理无纸化、事务处理自动化、资讯决策智能化，是现代高校信息化的关键之一，已成为当前高校信息化规划和建设的热点。它不仅有助于学校简化行政工作量、扩大办学规模、提高办事效率和工作质量，而且使管理更加规范化、信息化，并促进校务公开。

二、高校OA系统存在的问题

然而目前高校主流使用的OA，多数是以工作流为中心，能够实现公文流转、流程审批、文档管理、制度管理、会议管理、新闻发布等众多实用的功能，属于流程性OA。随着科技的发展和办公管理的要求日益提高，流程性OA系统逐渐暴露了一些问题和不足，这些问题和不足主要表现在以下几方面：

（一）只偏重于解决行政办公方面的需求，而忽略了对实时信息交流和教职工协同工作方面的支持。存在一个突出的问题就是即时信息交流功能远远不能满足高校办公即时交流和协同工作的需要。

（二）沟通手段复杂，文件传输功能实时性差、通用性低。对文件的即时传输需要对方必须同时在线，否则不能传送，这对需要经常上课、难以保障实时在线的教师而言，是难以实现的，也是让行政部门头疼的事情。

（三）语音视频服务急需进一步开发和使用。办公自动化系统引入多媒体技术，使之处理语音、图形、图像、视频功能加强，能够提高办公信息处理的应用范围和价值。而目前高校使用的OA系统，大部分还没有实现语音和视频的功能，明显滞后于现代办公自动化技术的发展。

（四）体系结构采用B/S，操作相对比较复杂，影响使用效果。大多数主流的OA系统需要经过一定培训，才能对使用方式有所了解。另外，验证过程过多、对IE安全性要求太多，在部分主流浏览器中界面显示效果不理想以及不完善的IE窗口弹出，也给使用者带来诸多不便。

三、即时通讯系统与OA系统的结合

针对OA系统存在的问题和不足，高校OA系统的发展正在不约而同地寻求与即时通讯技术的无缝嵌合。但是传统的个人即时通讯系统因为其不足，影响了它在现代OA系统中的应用。因此，有针对性地开发和利用企业即时通讯系统（如腾讯通），则能克服使用个人即时通讯工具的弊端，企业即时通讯系统的功能除了具备个人即时通讯软件常用的功能外，最大的区别就是由于应用模式不同而集成了各种办公必备功能的自动化办公交流平台。企业即时通讯软件主要是针对办公时的业务流程和数据传输，并且能够与其他软硬件设备进行交互，具有更高安全性和便利性。

若把OA系统与企业即时通讯平台结合起来，将使OA系统享有即时通讯技术所具有的便利、快捷、直接的优点，使高校教师可随时、随地进行即时交流，真正实现高校办公的协同工作，业务上的平等交流，从而提高各部门的协调工作能力，提高工作效率。

四、即时通讯系统与OA系统的结合实现

本文针对红帆OA系统和腾讯通即时通讯平台的结合和应用进行了探讨，解决了以下内容：

（一）解决办公自动化系统与即时通讯平台融合的接口问题，实现红帆OA系统与腾讯通平台的结合。

（二）组织机构集成，实现腾讯通平台与OA系统中组织结构及用户的同步，两个系统可以共享一套用户信息。

（三）完善消息机制，拓展集成后系统的即时通讯功能。

通过对OA系统和腾讯通平台接口开发，实现了二者的结合，并实现以下功能：

1.实现OA与即时通讯平台的整合。提取重要的和最新的信息，能够直接打开通知公告、文档文件。2.即时沟通，实时收发消息，满足用户在办公、沟通、协作以及个性化的需求。3.完善消息机制，实现即时处理。各种待处理信息通过即时通讯平台的消息机制进行提醒。4.实现手机短信通知用户。如用户外出，则系统自动将待办信息发送到该用户的手机上。5.建立明朗的组织架构，搭建了一个简单易用、结构合理、安全实用、高效的电子办公和沟通环境。

五、小结

即时通讯技术和办公自动化技术正在飞速发展，但二者都有自己的优势和不足，最合适的解决方案莫过于将二者整合，这也是近年来的热门技术，它在办公自动化中的应用为网络办公信息的处理提供了更加高效、稳定的解决方案。随着即时通讯系统和办公自动化系统的研究和应用不断深入，把二者向大型的综合集成系统方向发展是一个必然趋势。

参考文献：

[1]秦红兵,何正,符学斌.基于即时通讯技术的校园应用模式探索.软件研制,2005,7

[2]柳延东.即时通讯技术对现代教学的影响.教育探索,2007,7

[3]刘小舟.应用于电子政务的即时通讯系统的研究和设计.计算机时代,2007,10

作者简介：

刘国成（1975-），男，博士，研究方向：计算机应用技术。

集成应用平台开发 第4篇

嵌入系统开发已经趋于规范化,但是嵌入式系统的开发并不像在普通PC机上进行软件开发那样容易,它同样需要一个高度集成的开发平台,来降低开发的难度。目前市场上的嵌入式系统集成开发平台特点是:(1)多数嵌入式系统集成开发平台都是以Windows为系统环境,很少有以Linux为系统环境的;(2)部分集成开发平台具有一定的开放性,许多功能作为插件供用户选择;(3)多数集成开发平台通用性较差,仅支持一个或者几个系列的微处理器;(4)目前嵌入式系统集成开发平台产品大都价格昂贵;(5)很少有集成开发平台集成有图形模块支持的功能。

为了解决其它嵌入式集成开发平台的缺点,本文研究了嵌入式系统可视化集成开发平台,ESGIDE(Embedded system graphical integrated development environment),其最大特点是具有图形化人机交互功能和ARM CPU工作方式自动初始化。所谓图形化人机交互,是指把将要裁剪和配置的系统级软件(比如bootloader、kernel、通用I/O输入、输出等)化整为零,封装成不同功能的形象化图形模块,开发者根据自己开发的系统需要,选择不同图形模块,动态生成bootloader、kernel、I/O等系统级的源代码,不需要开发者自己输入,这大大简化了开发步骤,减轻了程序员的负担,减少了操作的复杂度,提高了开发效率。另一方面,ARM系列CPU应用比较广泛,不同型号的CPU在开发时需要对使用的内部资源进行初始化。传统的做法是开发者确定工作方式,确定工作方式字,然后手动编程。我们采用开发模式是:以定时器应用为例,将定时器的个数,工作方式确定,时钟频率的确定,是否允许中断等编写成对话框模式,开发者只要选中其中的方式,初始化控制字自动生成,编写代码自动生成,同样大大简化了开发步骤,减轻了程序员的负担。

面向对象技术是当前实现软件模块化、提高软件复用性最优的方法,现在成为计算机领域中的一种主流技术,本文提出利用面向对象的技术来设计一种嵌入式软件IDE,对嵌入式软件开发中的各个对象的类进行分析与设计,架构一个通用的开发模型,根据硬件配置自动产生基本的系统软件方案。只需要系统中的每个对象类的属性及其操作设置,自动搭建交叉编译环境,降低操作系统裁减和移植的难度,产生驱动程序的基本框架。开发人员只需要配置好各个模块的基本信息,将更多精力集中在系统的应用上。

1 嵌入式软件的开发流程

与常见的PC和服务器软件不同,嵌入式软件主要是对设备内部各部分的运行进行协调,并不与设备使用者发生直接接触。PC和服务器软件的运行环境是标准化的,而嵌入式软件的运行环境随电子设备的不同而改变,必须针对不同的电子产品进行专门的设计、开发和优化。由于嵌入式Linux操作系统在嵌入式开发中占据了主流,因此本文围绕针对移植有Linux操作系统的嵌入式开发流程进行讨论。

典型的基于嵌入式Linux操作系统的嵌入式软件开发流程如下[1]:

(1)获取硬件系统的信息:如选取的微处理器体系,Flash型号、网卡型号及其他外设的信息等;

(2)建立交叉编译工具:一般的GCC工具都是针对X86体系的,为了能够生产目标板执行的代码必须建立交叉编译工具;

(3)开发Bootloader:建立启动系统的主引导程序;

(4)移植Linux内核:如基于Linux2.6内核移植;

(5)开发一个根文件系统:如rootfs的制作;

(6)开发特定硬件的驱动程序:如LCD,Keypad等;

(7)开发上层的应用程序:如QT GUI开发。

对于开发过程的各个环节,有的提供了辅助的开发工具,有的需要完全依赖经验手工从底层开发,嵌入式软件开发依然停留在手工作坊式的方式,很难做到工程化管理。本文所设计的IDE将涵盖整个开发的各个重要环节,力求最大程度上降低开发难度,在集成化开发环境里完成主要工作。

2 IDE面向对象的分析与设计

对于运行嵌入式Linux操作系统的系统,根据其开发流程,利用面向对象技术分析设计出6个基本的大类,并给出对象之间的协作关系图,如图1、图2所示。这几个大类贯穿了嵌入式软件开发的重要环节。

硬件系统信息类,承载了硬件系统的描述信息,比如选取何种体系的微处理器,处理器的工作频率设置,采用何种启动方式,是Nand Flash,还是Nor Flash或者EPROM等,用户通过设定这些参数,其他对象将获取其中的信息进行配置。

嵌入式开发需要交叉编译,Linux环境下一般就是采用开源Gcc系列进行配置,环境搭建类管理交叉编译链的源代码,根据体系架构的信息自动生成运行脚本,在制定目录下生成完整的交叉编译链,这是嵌入式开发的基础。

工程管理类,集成开发环境的主要目的就是同一组织文档,省却人工管理,自动编译运行源码,其中包含了文件操作,组织好源代码之间的关系,利用make技术进行编译,牵扯到大量全局环境参数的设定。

引入控制字库类是方便部分程序的编写,比如Bootloader类需要对处理器初始化,基本的驱动控制器进行操作,其中包含了汇编指令级别和C语言的操作,开发人员往往需要对参考手册熟练掌握,大大降低了开发效率。控制字库尽量包含了常见的处理器系列的寄存器控制字库,只需选择某个具体功能,便可产生需要的指令源码。同样驱动程序开发中,也是频繁利用了C语言对寄存器进行操作。

系统移植类涵盖了整个系统需要移植的模块,引导程序,操作系统内核和文件系统,各类封装了大量繁杂的细节内容,尽量以最简化形式帮助开发人员完成操作,重要的环节只需设定参数,其他交由对象自动执行。

面向对象最重要的特征就是“高内聚度和低耦合性”,各个对象封装了细节操作,只需要有限的外部接口交换信息,这种柔性思想最大程度上提高了软件的复用性。本文所设计的IDE,根据体系结构的不同,所需修改的只是个别对象的内部数据和操作,整体架构不受任何影响[2,3]。

图3给出了面向对象嵌入式集成开发平台的结构。

3 系统的具体实现

目前可视化的面向编程语言种类比较多,从对面向对象技术的支持程度上来说,微软最新的VC#从封装性、类型安全性方面相当强大。重要的是,类层次清晰,编码容易,可以根据面向对象设计的框架轻松的进行转换,却和C++一样强大。所以本文利用VC#设计了嵌入式软件IDE,对各个类编写详细代码。整个系统基本架构如图4所示。

集成开发环境运行于Windows平台下,但需要Linux的强大命令集,在此,本文提出了Cygwin技术来模拟Linux运行环境,从而使得IDE的底层得到强大的各种命令支持,可以运行各种脚本文件。此技术属于开源项目,安装后需个别地方的细节修改。

交叉编译工具链模块是IDE设计的核心,开发一个实用的编译器,需要花费大量的人力物力和财力,其可靠性也要经受时间的考验。幸运的是,GNU提供了免费的、功能强大的GCC工具链,它不仅可以编译Linux操作系统下的应用程序以及Linux内核,而且还是一款交叉编译器,支持ARM、Power PC、x86、Intel960、M68等几乎所有知名的CPU厂家,而且国外大多数集成开发工具都从GCC移植而来。

本文的交叉编译工具链模块并不是单独的针对某个体系结构,可以重定向,根据参数配置,生成某个系列的编译工具,如图5所示。

软件设计的一个重要环节就是,要组织好源代码之间的关系,编译连接,这就要用到工程化的手段去管理源码。这是IDE设计中的桥梁。

本文利用的Makefile技术对整个工程进行管理,主要就是针对驱动程序和应用程序的组织和编译。Makefile是Linux工程管理的一项成熟的技术,有一套完整的规则,只需要按照规则去编写Makefile文件,然后由make命令去解释执行。Cygwin中集成了Gnumake,因此只要编写好Makefile文件,只需一个make命令,就可以完成所有的编译连接工作,如图6所示。

大多数的IDE都有这个命令,比如:Delphi的make,Visual C++的nmake,Linux下GNU的make。可见,makefile都成为了一种在工程方面的编译方法。

一个关键技术就是显示信息重定向到IDE指定的输出窗口,各种脚本运行信息都是标准控制台输出,因此需要将编译中的标准信息和错误信息进行重定向。通常是靠管道技术来解决这个问题,但嵌入式开发中许多编译过程长达数小时,信息往往需要进程结束才能完全显示。本文IDE则采用了管道技术加异步式读取技术,使得重定向和信息显示同时进行,及时反馈编译过程中的各种信息。

Bootloader是嵌入式系统的引导加载程序,它的作用是初始化必要的硬件设备,创建内核需要的一些信息并将信息通过相关机制传递给内核,从而将系统的软硬件环境带到一个合适的状态,最终调用操作系统内核,真正起到引导和加载内核的作用[5]。

Bootloader依赖于硬件实现,除了体系结构,还依赖于具体的嵌入式板级设备的配置,因此Bootloader是嵌入式开发移植最困难的部分,一般来说都是将已有的代码进行大量的修改,本文采用的是U-Boot 1.2.0,目前来说是比较通用的Bootloader。

如图7所示,针对这部分移植,为了最大程度上帮助用户完成代码的修改,IDE提供不同类型的体系架构需要修改的源码的提示信息,以及某种配置下需要修改的提示信息,需要建立一个帮助文件数据库。通过控制字库模块添加需要的源码。其实一般来说,修改都是大同小异,最主要的是修改两个方面,何种方式启动,是Nadflash还是Norflash,如果是Nandflash启动,需要定义芯片配置函数,增加Nandflash拷贝数据到内存的代码。还有就是为了利用tft协议烧录内核到flash,需要针对某种网卡芯片进行修改。

简单来说,内核配置无非就是生成一个配置文件,由Makefile来读取,不同的架构,就会选择不同架构目录下的源码。但是内核配置比较繁杂,一般人员很难理清源码之间的关系,配置不好,不仅无法编译,即使勉强编译成功,也未必能够正常运行。

而且,内核不单单是配置问题,还有部分源码根据需要必须修改,比如如果是Nandflash作为存储器,需要建立Nandflash分区表。

对于内核配置,本文IDE提供利用模板来进行二次配置,建立模板数据库,根据用户的参数设定,提供符合条件的模板,如果模板基本符合要求,就可以利用模板进行编译,如果需要细节的修改,则调用内核配置工具来进行配置,内核配置工具利用make xconfig形式,产生图形化界面,当然需要X系统的支持,需要在Cygwin中安装、修改。

对于内核源码修改,则需要帮助文件数据库,根据用户参数设置,产生需要的源码,添加到内核中去。如图8所示。

根文件系统是Linux/Unix系统启动的一个重要组成部分,也是操作系统正常工作时候的必要组成部分,在启动时候内核需要跟文件系统来挂载。在现代Linux操作系统中,内核代码影像文件保存在根文件中,系统引导启动程序会从这个根文件设备商把内核代码加载到内存中取运行。如图9所示。

嵌入式根文件系统有Rom FS,JFFS2,NFS,EXT2,RAM-DISK,Cramfs等,每个系统都有自己的特点,最常用的就是Cramfs文件系统,Cygwin工具集中提供了Cramfs工具,mkcramfs。

嵌入式根文件的最底层目录中,都有其具体的用途和目的,因此必须建立最基本的根目录。而且一些根目录下必须有固定的文件,如/bin,/sbin,/usr/bin,/usr/sbin需要放置Linux命令工具,/etc目录下需要系统配置文件,包括启动文件。因此,本模块要完成这么几个功能,提供必须的根目录,根目录下的文件,将根目录制作成某种跟文件系统,本文暂时提供Cramfs文件系统。嵌入式Linux命令工具集由Busy Box工具提供,它包含了很多标准Linux工具的单个可执行实现,本文的IDE提供了一个Busy Box的标准配置,只需要利用交叉工具链进行编译。

4 嵌入式微处理器内部资源驱动

嵌入式微处理器有大量的内部I/O接口资源,如定时计数器、中断、DMA、开关量输入输出等,要选择其中的接口应用,首先要进行初始化,编写驱动程序。

驱动程序编写模块和应用程序编写模块只要提供一个文本编辑器,利用工程管理部分去组织源码进行编译就可以。对于驱动程序的编写,Linux驱动程序都有一套固定的模式,比如字符型、块型、网络型数据结构都有区别,但每种类型的驱动程序架构都一样。另外驱动程序编写中最重要的就是根据每个接口资源确定的工作方式确定控制字,即使开发人员对某个体系下的各类CPU内部资源的控制字十分熟悉,也要经常参考手册才能准确无误。

本文提出了驱动程序编写模式,一个是选择类型,自动生成某种类型的模板,在此模板上进行添加修改;第二就是利用控制字模块,在开发驱动程序过程中,开发人员可以选择某个体系结构下的针对某种具体寄存器的操作,然后会自动产生必要的代码,如图10、图11所示,只需要将代码嵌入到驱动程序源码中。

图10是定时器的选择界面,开发者只要根据需求选择相应的定时器,确定其功能,初始值,然后选择确认按钮,初始化代码自动生成,如图11包含初始化控制字,非常快捷、便利。另外,如果驱动程序要添加到内核去,重新重新配置内核即可。

5 结语

本开发平台具有友好的用户界面、文本编辑器、工程管理工具、交叉编译器、烧录和下载工具、图形化模块支持。本集成开发平台可以供学生、老师或者工程技术人员学习嵌入式linux的裁剪和移植,ARM系列CPU的开发和应用。

利用本文研究的嵌入式软件IDE,针对ARM系列的2410平台进行了U-Boot、Linux2.6内核、根文件系统的配置和移植,编写出基本的网卡驱动程序,测试取得成功。

参考文献

[1]田丽从,张莉,周伯生.基于UML的集成化软件开发环境的研究与实现[J].北京航空航天大学学报,2003,29(10):935-938.

[2]姚卫新.新编操作系统实验教程[M].上海:东华大学出版社,2010.

[3]Arnold Robbins.Unix技术手册[M].4版.南京:东南大学出版社,2009.

[4]Wendy Boggs,Michael Boggs.UML与Rational Rose2002从入门到精通[M].邱仲潘,等译.北京:电子工业出版社,2002.

[5]肖永泉,马小平.实时嵌入式系统集成开发环境研究与设计[J].微机发展,2004,14(4).

[6]吴建,郑潮,汪杰.UML基础与Rose建模案例[M].北京:人民邮电出版社,2004.

[7]董兰芳,刘振安,等.UML课程设计[M].北京:机械工业出版社,2005:45-46.

[8]Maguire L P,McGinnity T M,McDaid L J.Issues in the Development ofan Integrated Environment for Embedded System Design[J].Micropro-cessors and Microsystems,1999(23).

[9]史济民,顾春华,李昌武,等.软件工程——原理、方法与应用[M].北京:高等教育出版社,2002.

[10]Stephen R Schach.面向对象与传统软件工程:统一过程的理论与实践[M].韩松,邓迎春,译.北京:机械工业出版社,2006.

集成应用平台开发 第5篇

关键词：CAD,CAE,BOM,集成系统,二次开发

0 引言

信息技术迅速发展，科技技术日新月异，一些新的产品开发、生产及管理等技术层出不穷。作为工程技术、设计技术、开发和生产新产品重要手段的CAE(Computer Aided Engineering)、CAD(Computer Aided Design)和BOM(Bill of Material)，对增强产品性能、降低产品成本、提高产品质量等起到了重大作用。但是，现阶段产品生产过程中的CAE、CAD和BOM，只是在各自的功能过程阶段起到作用，彼此孤立，无法实现彼此信息的无隙共享，成为进一步提高工作效率的“瓶颈”。

为了抢占信息化的先机，许多大型的软件开发商都开发了或正在开发集成CAE、BOM和CAD功能的大型设计软件。但由于价格、资金或者企业规模等诸多因素，大部分中小型企业都对大型设计软件望而却步，而仅仅使用CAD系统进行产品的绘图而已。

我们若以AutoCAD2008系统为开发平台，通过二次开发来实现CAE、CAD和BOM的集成。这样不但可以保留原CAD系统，还可通过很少的投入就实现CAE、CAD和BOM集成。既可满足中小企业的信息化需求，节省中小企业投资费用;也可利用此集成系统进而改善企业的生产状况，提升产品的竞争力和企业的经济效益。

1 集成系统的开发原则

对于集成系统的开发，其主要是在A u t o C A D 2 0 0 8设计软件的基础上，利用ObjectARX2010开发工具，使用Visual C++6.0程序语言，对AutoCAD2008设计软件进行二次开发来实现集成系统的独特功能。因此，在集成系统的总体设计中，应该遵循工程性、继承性、标准性和构件性原则。

1.1 工程性原则

首先对企业所要解决的问题进行针对性的详细分析，并加以确切描述，确定软件技术目标和功能目标，编写软件功能说明书、确认测试计划和数据信息说明书等。然后根据功能说明书的要求，构造软件系统的体系，编写软件设计和详细步骤说明书、数据库或数据结构设计说明书，实现测试计划，从而确保二次开发软件的针对性、有效性和延伸性。

1.2 继承性原则

二次开发是在原有软件基础上根据实际需要而进行有针对性的再次开发，对支撑软件有很强的依赖性和继承性。这点与一般从底层做起的软件设计不同，开发后的系统在图形界面和操作风格应与原软件保持一致，新加入的部分在功能、数据等方面应与原系统实现无缝结合，从而保持系统的一致性和延续性。

1.3 标准性原则

标准化是开发任何软件的基础。首先，在开发过程中要遵循CAD技术的基础标准;其次，产品设计过程有着严格的国家标准规定，CAD系统的运行过程是对具体产品设计过程的模拟，也要遵循相应的国家标准规定。

1.4 构件性原则

在软件的构造中应遵循构件性的原则，将整个系统分解成若干个子系统(或模块)即构件，定义构件的接口关系，使系统的构件既相对独立又紧密联系，方便系统的维护和扩展。

2 系统功能模块结构的分析

集成系统功能主要应包括以下几点：

1)数据库内容查看与编辑。包括数据内容的查看、添加、修改、删除等功能。2)常规设计能自动进行常规计算。3)优化计算能自动进行优化计算方法的选择，并进行优化计算。4)在AutoCAD2008中能自动绘制所设计产品的图纸。5)图纸技术要求的自动标注。6)图层、图框、明细的自动生成与填写。7)产品部件BOM和图目的自动汇总、浏览和输出。

在系统功能分析的基础上，可得到如图1所示的系统功能模块图。CAE子系统包括优化计算模块、常规计算模块。CAD子系统包括图框生成模块、图层生成模块、明细填写模块、自动绘图模块、技术标注模块。BOM子系统包括图目汇总模块和BOM汇总模块。它们之间可以相互通信和同时使用，也可以单独使用某一个模块(即构件)或某一个子系统。

3 集成系统的数据流程分析

分析系统功能模块，可得出集成系统的各功能模块所处理的数据流程(如图2所示)。

4 功能模块和CAD结合方式分析

集成系统是在AutoCAD2008的基础上产生CAD子系统，通过前推来产生CAE子系统，后延产生BOM子系统，因此必须考虑二次开发功能模块与AutoCAD2008的结合方式。目前，结合方式主要有三种：

1)主动式。AutoCAD2008将二次开发功能模块所需的信息直接写入二次开发功能模块的数据库中。

采用主动式，A u t o C A D 2 0 0 8系统与二次开发功能模块中信息的同步性较好;但在安全性方面存在一定问题，如出现写数据冲突，即AutoCAD2008系统写数据到二次开发功能模块的同时，二次开发功能模块也在往里写数据。

2)中间式。AutoCAD2008将二次开发功能模块所需的信息生成中间文件或中间数据表，二次开发功能模块直接读取中间文件或中间数据表中的信息，并写入自己的数据库中。

采用中间式，AutoCAD2008系统和二次开发功能模块相对独立，接口不涉及双方内部的结构，而且接口的责任也很明确，数据的安全性也得到了保证。

3)被动式。二次开发功能模块从AutoCAD2008系统中读取所需的数据，将其写入二次开发功能模块的数据库中。

采用被动式，AutoCAD2008系统与二次开发功能模块的同步性做得比较好，安全性方面也比主动式要强，并且具有较高的数据独立性，同时简化编程人员及用户的数据管理。

5 BOM子系统数据获得方式的分析

BOM数据的来源是一个主要问题，目前，重点从以下的几种途径来考虑：

1)把DWG格式文件转换为DXF格式文件或者IGES格式文件，再提取明细表信息。

2)将图纸明细表做成一个带有属性的模块，然后利用CAD软件提供的二次开发接口，将其中的信息存储在外部文件或数据库中，再进行BOM表的生成。

3)用Activcx Automation技术实现CAD与Excel之间的信息通讯，将明细表的数据提取到Excel中，然后利用其强大的功能来实现BOM表的生成。

4)从AutoCAD2008图形数据库对象中直接提取有关明细表的信息。

5)利用AutoCAD2008提供的数据库接口，来实现对图纸明细表中数据的自动提取，并保存在事先指定的数据库中。

结合企业的生产实际和程序开发的难度及对数据一致性的要求，集成系统应采用以下的方式：通过对AutoCAD2008进行二次开发，在填写明细栏和标题栏时，直接将数据做两次处理，一是显示在图纸相应的位置上，二是将相关内容存储到外部数据库中。这样，既保证了数据的一致性和有效性，又降低了系统的开发难度;同时，二次开发模块与AutoCAD2008系统是采用中间式结合方式，也便于对数据的处理和后续软件开发对数据的获取。

6 系统的集成

集成是指将以某一个特定功能系统(如CAD系统)为核心的各单元系统(如CAM、CAE、CAPP、BOM等)通过网络和信息集成技术实现系统间信息的无缝联结、交换和共享，进而与底层自动化系统沟通，实现系统的一体化，使整个系统的各个组成模块有机结合并使其总体效能达到最佳。

集成系统主要是对产品开发过程中的CAE、BOM和CAD进行集成，一则可以提高企业产品设计过程中信息共享的程度，二则为企业集成打下一定的基础。

对系统进行集成，主要应考虑数据库结构设计、记录集处理、数据库对象的处理等具体的数据结构和模块之间数据的具体传输方式等。

7 CAD/CAE集成系统的实现

CAD/CAE集成系统基于关键参数库、知识约束库、函数约束库和CAD/CAE参数接口，通过关键数据库，实现有限元模型和三维实体模型的转换。通过CAD/CAE参数化零件库、函数约束库、知识约束库、关键参数库和CAD/CAE参数接口的开发，实现了三维实体模型和有限元模型的参数化，最终达到驱动参数化模型的功能，如图3所示。

8 集成系统性能测试的分析

对于集成系统的性能测试，测试模型的建立至关重要，性能测试模型要以实际生产环境为标准搭建，只有模型符合实际的生产环境，性能测试的结果才能真实有效的反映将来上线的生产环境的实际性能情况。一个标准的性能调优过程是：

1)确定基准环境、基准负载和基准性能指标。

2)调整系统运行环境和实现方法，执行测试。

3)记录测试结果、进行分析

集成系统是通过对AutoCAD2008绘图软件进行二次开发而实现的，也属于一般软件的范畴，因此，也必须遵循一般软件的测试原理和测试步骤。首先应进行模块测试，发现缺陷，性能调优，确保每个模块作为一个单元能正常运行;然后进行子系统测试，在这里要着重测试模块的接口;接下来就是系统测试，把经过测试的子系统装配成一个完整的系统来测试。

9 结论

以CAD为平台的CAE、CAD和BOM的集成，既可以为企业节省办公成本、消除企业信息化的孤立，在很大程度上更可以提高产品的竞争力及企业的知名度。

参考文献

[1]吴亚南.开关外壳注塑模具CAD/CAE/CAM一体化的应用研究[D].大连交通大学,2005(3).

[2]陈世东,武一南,黄有群.面向AutoCAD的BOM表的自动生成及产品结构管理[J].沈阳工业大学学报,2001,23(6).

[3]黄继明.关于CAE/CAD/BOM集成关键技术的研究[D].华北电力大学,2006(6).

集成应用平台开发 第6篇

洪涝灾害是我国损失最为严重的自然灾害,随着社会经济的发展和城市化进程的加速,洪水造成的损失越来越大。洪水预报是调度决策的重要依据,在防洪减灾中发挥着重要的技术支撑作用。洪水预报系统是各项洪水预报技术的集成,是一项重要的防洪减灾的非工程措施[1]。本文结合当前先进的信息、软件开发技术,基于综合集成平台[2,3],采用组件[4,5,6]、Web Service[7,8]等技术将洪水预报模型和参数率定方法划分并实现为功能相互独立的组件,形成模型组件库和参数率定方法库。在综合集成平台上,通过知识图、业务组件搭建洪水预报系统,实现洪水预报集成应用。

1 洪水预报系统及应用模式存在的问题

随着软件开发技术的不断发展及洪水预报需求的不断提升,传统的洪水预报系统及应用模式存在的问题也越来越突出。

传统模式在洪水预报模型开发方面存在的主要问题如下:

1)模型难以重用。由于模型通常是与洪水预报系统绑定在一起,在开发别的洪水预报系统时,这些模型无法重用,需重新开发。

2)模型不灵活。传统的洪水预报系统通常是针对某一流域、断面等进行模型的制作,模型与模型的参数联系在一起,制作出来的模型只适用于该流域或断面,不能应用于别的流域或断面,缺乏灵活性。

3)缺乏参数率定及修正能力。传统的洪水预报系统大都是针对流域、断面等而开发的,系统中的模型也都只能应用与该流域或断面,模型的参数率定没有和模型自身分离,使得系统缺乏参数的修正能力。

4)低水平重复开发。由于模型和参数绑定在一起,缺乏灵活性,加之缺乏标准的参数估计方法,使得针对不同部门或地域的洪水预报系统、模型都必须重新开发,造成人力和物力的浪费,增加系统的建设成本。

传统模式在洪水预报系统建设方面存在的主要问题如下:

1)系统可扩展性差,难以满足业务需要。传统的洪水预报系统大多采用面向对象方法,系统一旦建成,新的预报模型或方法很难加入到系统中,不能满足实际业务需要。

2)系统功能单一,缺乏实用性。传统的洪水预报系统在功能上缺乏扩展性,在业务上缺乏扩充性,在应用上缺乏灵活性,在表现形式上缺乏多样性,在操作上缺乏交互性。预报模型方法单一,缺乏多模型、多方案对比,决策支持能力欠缺。

3)系统灵活性差,低水平重复开发。模型和软件系统耦合在一起,使得系统难以重用。

针对洪水预报系统及应用模式存在的问题,结合最新的软件开发技术及洪水预报需求,本文探讨了基于综合集成的洪水预报及集成应用模式,其基本思路是:在面向服务的体系架构(SOA)下,将洪水预报模型组件化,采用Web Service技术将洪水预报模型封装成标准的组件,形成洪水预报模型组件库;采用知识图来组织模型和描述业务逻辑(流程);通过平台、组件、知识图搭建洪水预报系统,实现洪水预报的集成应用。

2 洪水预报模型组件化及模型搭建

2.1 洪水预报模型组件化过程

洪水预报模型组件化可分为模型组件划分、封装和搭建3个阶段,具体过程如下:

1)根据洪水预报模型的计算过程,将模型划分各个独立的子模型,各个子模型留有参数、输入和输出接口。这一过程可由Java实现,每个子模型可以看作是1个类;

2)利用Web服务技术,将各个子模型封装成模型组件;

3)将已经封装好的组件存入相应的模型组件库;

4)利用各个子模型搭建洪水预报模型。

洪水预报模型组件化过程如图1所示。

2.2 洪水预报模型组件化实例

2.2.1 新安江模型组件化

1)新安江模型组件划分。新安江模型强调从降雨到形成径流的时间和空间上的变化过程,预报过程比较复杂,且可以分割为多个子系统,如蒸发、产流、水源划分、流域汇流和洪水演进等子系统。根据新安江模型的各个组成部分,将新安江模型分为蒸散发、产流、水源划分和汇流计算等4类组件。为便于组件的通用和重用,又将蒸散发计算划分为一层、二层和三层蒸散发计算等3个标准组件;将汇流计算划分为坡地汇河网和河道汇流计算2个组件;将水源划分分为二水源、三水源和四水源等3个组件。

2)组件业务逻辑分析。业务逻辑分析过程主要分析模型组件的参数、初值和输出(模型组件的计算结果)。下面以三层蒸散发组件为例来说明组件的业务逻辑。

参数是和该模型相关的一些流域的参数。其中K为蒸散发折算系数;SM为自由水需水容量;KG为地下径流出流系数;KSS为壤中流出流系数;KKG为地下水库消退系数;KKSS为壤中流消退系数;CS为河网蓄水消退系数;WM=WUM+WLM+WDM为蓄水容量,是上层蓄水容量WUM、下层蓄水容量WLM、深层蓄水容量WDM之和;IMP为不透水面积比例;B为蓄水容量曲线系数;C为深层蒸散发系数;EX为自由水容量分布指数;UH为单位线;KE为马斯京根模型参数;XE为流量比重因素;A为流域面积。

初值:主要有2个来源,一个是流域在各个时段上的初值,其中,P为降雨量;另外一个是别的模型或者是模型本身的计算结果,其中,WU为上层土壤含水量,WL为下层土壤含水量,WD为深层土壤含水量,EI为蒸发量,属于三层蒸发模型本身的时段计算结果,这个结果又可作为下一时段的初值。

输出:也是2个部分。一部分是输出给其他模型的计算结果,其中,R为总径流量;RS为地表径流量;RSS为壤中流径流量;RG为地下径流量;QRS为地表径流;QRSS为壤中流;QRG为地下径流;Q为计算出流量。另一部分是流域在这个时段内使用该模型发生改变的状态(属于该模型的初值)如三层蒸发模型中计算出的WU,WL,WD,又要作为下一时段土壤含水量的初值。

新安江模型共由5个模型组件构成,由模型的原理可知,这5个组件之间并不完全独立,各个组件之间存在一定逻辑关系,具体逻辑关系如图2所示。这种逻辑关系就是组件组装新安江模型的依据。

3)新安江模型组件的实现。新安江模型组件的实现是将划分好的各个组件,根据组件开发标准,通过编程实现其业务功能。新安江模型总共要实现9个模型组件,各组件的类名、关键方法及功能如表1所示。

2.2.2 洪水预报模型参数优选组件化

参数优选方法是借助一定的数学方法,如最小二乘法、单纯形法,以及近年来出现的遗传、粒子群、蚁群等算法来实现模型参数优化,完全由计算机实现。

考虑到优化算法在参数优选方面的优势,本文对SCE-UA、改进粒子群(SMSE-PSO)、并行遗传(PGA)和免疫克隆选择(ICSA)等算法按照模型组件化过程进行组件化。

2.2.3 洪水预报模型组件库

随着洪水预报模型组件的增多,将形成预报模型组件库。组件库的主要任务是对外提供组件,需要的组件只要从组件库“取”即可。对组件库中的各组件进行分类,以便于其应用,组件分类如表2所示。

2.3 洪水预报模型搭建

预报模型的搭建模式是模型组件化的核心,搭建模式的好坏直接决定着代码重用率的高低。组件的重用率越高,越节省资源,而且能真正体现组件化的最终目的。

2.3.1 多模型共用1个或多个组件

对于多个模型共用1个或多个组件,以新安江和陕北模型为例,可以将新安江模型划分为蒸散发、蓄满产流、水源划分、汇流和河道汇流(马斯京根模型)等组件;可以将陕北模型划分为蒸散发、超渗产流、汇流和河道汇流等组件。由于都有蒸散发、汇流和河道汇流3个组件,因此这3部分可以共用,而这3部分共包含7个组件,则可以共用的组件有7个。组件共用示意图如图3所示。

当然组件共用远不止这些,组件越多,共用机会就越多,越能充分发挥组件共用的作用。随着组件越来越多,各个组件的共用机率也会越来越大。

2.3.2 多个组件的组合搭建

多个组件组合搭建的情况以新安江模型为例,根据各个组件的详细分类,将这些组件组合应用,即可搭建成不同类型的新安江模型。组合搭建示意图如图4所示。一共可以组合成一层蒸发二水源单位线汇流马斯京根模型、二层蒸发二水源划分单位线汇流马斯京根模型等54个模型。

3 洪水预报模型集成应用

在已有组件库的基础上,运用洪水预报模型搭建模式可快速搭建多个洪水预报模型并实现应用;对于1个流域或断面,可同时应用多个模型进行预报,为此,本文提出多模型洪水预报的集成应用模式。集成应用模式主要分为洪水集成预报和预报方案集成发布。

3.1 洪水集成预报

洪水集成预报一般有2种方法,一种是综合线性集成方法;另一种是黑箱模型集成方法,如神经网络、支持向量机等。

3.1.1 综合线性集成

综合线性集成可用下式表示:

另一种是采用多年资料,用每种模型对多场次洪水进行模拟,取其中1种模型所有场次洪水模拟的确定性系数的平均值作为这种模型的可信度DCi,采用下式计算出每种模型的权重系数:

3.1.2 黑箱模型集成

神经网络和支持向量机在洪水预报方面应用比较多,本文将这2种方法用于洪水集成预报,即将各个模型的预报和实测结果作为神经网络的训练资料,从而确定神经网络和支持向量机的参数,建立基于神经网络和支持向量机的洪水集成预报模型。当然,这2种方法的参数也可以采用优化算法来求解。

3.2 洪水预报方案集成发布

洪水预报方案的发布主要要求3个数据,即洪峰流量、峰现时间和洪水总量。本文提出2种预报方案发布方法,一种很简单,直接采用集成预报的结果,提取这3个数据即可。但本文认为,此法非常不太人性化,预报方案发布是为决策服务的,采用了多个模型进行预报,各个模型的特点不一,应该集成各个模型的预报思想,实现方案的集成发布。为此,提出具有可选性的预报方案,即将每个模型的这3个数据提取出来,以这3个数据的最小和最大值的闭区间作为预报方案,这样做,使得方案更加接近实际情况,也更加人性化。

4 应用实例

组件开发好以后,可根据组件搭建模式将组件搭建成模型,而模型组件的展示需要1个平台,课题组开发了知识可视化综合集成支持平台,可以在此平台上对组件的运行情况进行展示。对冯家山水库入库洪水进行了模拟,如图5所示。

图5中左上角每个方框代表1个组件,点击每个组件可查看组件的运行结果,本文同时采用4个模型对冯家山水库进行集成预报,集成预报结果见图5右边。

5 结语

考虑到目前洪水预报系统中存在的问题,本文提出洪水预报模型组件化及应用。针对洪水预报模型在结构和逻辑上的特性,将各个模型划分为多个相互独立的模块,在面向对象的编程语言JAVA基础之上,运用Web Service组件封装技术和SOA组件模型将各个划分好的模块封装成组件;同时,针对洪水预报模型结构特性,提出洪水预报模型搭建模式,并在此基础之上提出洪水预报集成应用模式,并针对具体流域实现其应用。应用结果表明,组件化的洪水预报模型及其集成应用模式无论对于软件开发还是洪水预报而言都有极大的意义,具体如下:

1)可移植性强。对于任何一个流域,只需更改部分组件,即可搭建适合该流域的模型。

2)代码重用率高。从组件的共用和组件组合搭建可以看出,组件被大量重用,从而也实现了代码的重用,节省了资源。

3)可扩展性好。洪水预报模型组件库的建立有利于组件的进一步扩展,可以将新模型封装成组件,从而壮大组件库,有利于应用。

4)可维护性好。各个组件之间相互独立,1个组件出现问题,不会影响到其他组件,只需更改1个组件即可解决问题。

5)展示效果好。以往洪水预报系统常常只能显示最后结果,而组件化的模型实施细节透明,每个模块是1个组件,每个模块的计算状况都可以显示。

6)预报精度更高。集成预报结果一般优于任何单模型的预报结果,从而可以提高预报的精度。

7)预报方案更加人性化。具有可选的方案才是更加贴切实际,更加人性化的预报方案。

参考文献

[1]章四龙.洪水预报系统关键技术研究与实践[M].北京:中国水利水电出版社,2006:35-39.

[2]解建仓,张刚,魏娜,等.基于综合集成平台的洪水演进及错峰调度[J].水利信息化,2011(1):19-24.

[3]解建仓,罗军刚.水利信息化综合集成服务平台及应用模式[J].水利信息化,2010(5):18-22.

[4]张世现,张文娟.基于软件体系结构的可复用构件制作和组装[J].软件学报,2001,12(9):1351-1359.

[5]黄平.基于构件的软件开发方法在金融中间业务系统中的应用[J].浙江理工大学学报,2007,24(4):453-456.

[6]战德臣,王忠杰.一种基于构件的复杂应用系统开发过程[J].哈尔滨工业大学学报,2002,34(6):751-755.

[7]岳昆,王晓玲,周傲英.Web服务核心支持技术研究综述[J].软件学报,2004,15(3):428-434.

企业级应用集成平台研究与应用 第7篇

1移动业务支撑系统接口管理现状

业务运营支撑系统在与各平台进行交互时,根据平台提供的接口协议、报文格式、接入方式等内容,对每一个应用平台单独进行接口程序开发工作,外部系统通过各个接口与业务支撑系统进行业务交互,随着业务的增加,接口程序呈现出烟筒状的增长方式,并出现以下问题(如图1)。

(1)协议种类繁多,报文种类也非常多,基本一个接口一个报文规范。 系统缺乏统一接口平台架构和接口规范,各个接口各自开发,接口不易复用,系统扩展性差。

(2)接口应用比较多,对应用安全性能考虑少,缺乏集中、分类化的管理,系统维护难度大。

(3)基础服务直接给外围系统,外围系统压力会直接传递给核心系统,导致系统运行不稳定。

2企业级应用集成平台架构组成

为了统一管理外部平台与业务支撑系统的对接服务, 构建了应用集成平台。 为业务支撑系统提供统一的标准化通道与外部系统进行交互, 实现在各个应用系统与业务支撑系统间桥梁作用,实现跨系统业务交易处理。

应用集成平台由通讯总线和适配器构成。 通讯总线是传输控制层,负责根据路由信息在功能请求者和功能提供者直接转发信息;协议适配器是应用接口层,负责接口标准化。 具体结构如图2 所示。

(1)通讯总线处于集成平台核心地位,负责管理各个适配器的接入, 根据路由信息在功能请求者和功能提供者直接转发信息。 通讯总线由管控中心、交换中心组成,数据交互格式为MML格式。

①管控中心仅有一个,管理整个系统配置信息、路由信息, 管理所有节点的状态,以及网络连接情况。 管控中心不参与生产数据的处理,如果有异常,不影响整个系统的正常运行。

②交换中心分三级管理, 负责把客户端适配器的服务请求转发给服务端适配器,并把结果进行反馈。 一级交换中心负责连接适配器;二、三级交换中心仅仅根据目的路由地址进行消息转发。 客户端适配器向一级交换中心发起服务请求,一级交换中心根据目的路由地址,通过二、三级交换中心将请求消息转发给服务端适配器。

③通讯总线内部及通讯总线与适配器数据交互格式采用MML键值对方式。

(2)协议适配器用于实现协议标准化。存在多种协议适配器, 用于完成外部协议与内部协议的转换,实现协议的标准化。

①按照协议种类分为HTTP+XML协议适配器、SOAP协议适配器、TUXEDO协议适配器、TCP协议适配器、数据库适配器。

②按照功能分类, 根据每种协议适配器与通讯总线关系,分为客户端适配器与服务端适配器。 客户端适配器作为交易发起方;服务端适配器作为交易受理方。

③协议适配器主要功能是数据格式转换功能,把外部协议转换为内部系统能够识别的MML格式, 把内部MML格式转换为外部系统能够识别的协议格式。

3企业级应用集成平台在业务支撑系统中的应用

通过通讯总线、适配器进行组装,建立应用集成平台,业务支撑系统与外部系统统一通过应用集成平台对接。针对不同协议接入的业务平台,只需要配置相关的适配器进行对接,实现业务支撑系统与外部平台的一体化管理。如外部系统对接使用SOAP协议接入, 在应用集成平台部署一个SOAP客户端适配器、 一个SOAP服务端适配器、一个Tuxedo服务端适配器。 SOAP服务端适配器调用外部系统服务;SOAP客户端适配器接收外部系统调用;Tuxedo适配器调用内部服务。 实现业务支撑系统与外部系统间业务交互。 具体如图3。

3.1 实现业务支撑系统调用外部系统服务流程

(1)业务支撑系统客户端程序通过API向总线发送服务调用请求。

(2)通讯总线根据路由信息、 把消息把服务请求信息转发给SOAP服务端适配器。

(3)服务端适配器把请求信息MML串转换为SOAP报文传给外部系统。

(4)外部系统接收服务请求,把服务处理结果反馈给服务端适配器。

(5)服务端适配器把SOAP报文转换为MML串并转发给通讯总线。

(6)通讯总线把处理结果MML串传给业务支撑系统客户端程序。

3.2 实现外部系统调用业务支撑系统服务流程

(1)外部系统向SOAP客户端适配器发起服务请求。

(2)客户端适配器把请求转换为MML串后传给通讯总线。

(3)通讯总线根据路由信息把消息传给服务端适配器,服务端适配器调用相关服务。

(4)服务端适配器把处理结果通过MML串格式发给通讯总线。

(5)通讯总线把处理结果给客户端适配器。

(6)客户端适配器把MML串转换为SOAP报文发给外部平台。

4企业级应用集成平台使用优势

在企业信息化管理快速发展过程中, 系统专业分工趋势明显,系统功能与服务分散在各系统中进行管理。 但是各系统间有时需要进行交互,实现服务及数据的共享。 系统间服务集成成为企业信息化建设中必须面对的问题。 企业级应用集成平台的建设就是满足企业信息化管理中系统间服务集成要求, 并体现出如下优势。

(1)接口的统一标准化管理:应用集成平台统一对外部平台接入进行管理, 满足外部应用系统与业务支撑系统间各种交易实时调度;针对不同类型协议提供不同的适配器,实现系统协议标准化管理。

(2) 系统的安全稳定性: 外部系统必须通过适配器安全验证,才能接入业务支撑系统;通过各级交换中心调度,实现服务的负载均衡,确保系统稳定;针对每类协议提供适配器,相同协议可以共用适配器,代码复用高。

(3)系统配置化、组件化:当有外部平台接入时,根据需要在通讯总线配置路由,把客户端适配器、服务端适配器发布在系统上并进行参数配置,通过组件的安装就可以实现系统的对接。

摘要：吉林移动是信息化体系建设比较发达的大型企业,业务运营支撑系统需要与大量外部平台进行交互,通过企业级应用集成平台建设实现外部接口的统一管理,提升企业信息化管理水平。

基于SOA实现医院应用集成平台 第8篇

近年来,随着国家对医疗卫生改革的大力推进,医院的业务得到蓬勃发展。随着医院业务的发展,医院内运行的业务应用系统越来越多,也越来越专业化,各个应用系统之间的交流也越发频繁,对数据交换的需求也越来越迫切。而这些应用系统大部分由不同软件厂商采用不同的软件平台技术开发,这些异构系统的存在导致系统间信息的交互与互操作非常困难,形成了一个个"信息孤岛",出现了医院业务系统应用发展的瓶颈。

同时随着医院业务走出医院,对外提供网上预约、网上体检和社保结算等服务时,也面临医院业务系统与医院外部系统的交互,这些交互也对各个应用系统提出集成的需要。

针对以上问题,本文提出在采用基于面向服务架构(ServiceOriented Architectures,SOA)对医院应用系统进行集成,利用SOA松耦合的架构,在不改变现有医院业务系统的基础上,搭建各业务系统的信息框架,实现对现有医院信息化投资的保护,最大化的实现业务系统的发展。

1 面向服务的体系架构

SOA(面向服务的架构)随着各大厂商的追捧而变得炙手可热。虽然SOA本身不是一个全新的概念,但由于Web服务以及网格计算等技术的成熟,SOA具备了更好的发展条件。基于SOA的企业应用系统集成可以灵活的随着企业业务的变化而逐渐变化,能够实现"柔性化"的软件系统,从而降低了企业实施应用集成的成本和风险。

1.1 SOA的定义及其组件结构

SOA是一个组件模型,它将应用程序的不同功能单元(称为服务)通过其间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应用独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

面向服务体系结构的组件包括:

1.1.1 服务提供者

服务提供者是一个或一组以无状态方式执行业务功能的组件,接受预定义的输入和输出。

1.1.2 服务使用者

服务使用者是一组有兴趣使用服务提供者所提供的一项或多项服务的组件。

1.1.3 服务储备库

服务储备库包含服务的说明。服务提供者在该储备库中注册其服务,而服务使用者访问该储备库已发现的所提供的服务。图1说明了SOA中的不同角色及其工作流程

SOA的关键是"服务"。W3C将服务定义为:"服务提供者完成一组工作,为服务使用者将会所需的最终结果。最终结果通常是使用者的状态发生变化,但也可能是提供者的状态改变,或者双方都产生变化"。服务是网络中可用的软件资源。服务提供者通过标准机制提供服务。服务使用者通过网络有计划地使用服务。服务储备库发布服务所在位置,并在使用者请求服务时定位服务。服务使用者和提供者的角色不是惟一的,服务提供者也可以是使用者,反之亦然。

1.2 SOA服务粒度

可以按基于服务的功能及发送和接收的数据数量来划分服务,如细粒度服务、粗粒度服务或组合服务。在SOA中服务粒度有两种相关的意思,即服务是如何实现的,服务使用和返回了多少数据或多少消息。细粒度服务执行了最小的功能,发送和接收少量的数据。粗粒度服务执行了较大的业务功能,并交换了更多的数据。粗粒度服务提供一项特定的业务功能,而细粒度服务代表了技术组件方法。

1.3 SOA实现技术

虽然服务不仅仅是指"Web服务",但Web服务是SOA最流行的一种实现方法。Web服务(Web Service)提供了一个分布式的计算技术,通过开放的Internet标准:Web服务描述语言(WSDL,用于服务描述);统一描述、发现和集成规范(UDDI,用于服务的发布和集成);简单对象访问协议(SOAP,用于服务调用)和Web服务流语言(WSFL,用来定义工作流),Web服务消除了现存解决方案(如CORBA和DCOM)中的互用性问题。使用Web服务,通过松散的服务捆绑集合形式,能够快速,低代价地开发、发布、发现和动态绑定应用。

1.4 ESB企业服务总线

企业服务总线(Enterprise Service Bus,ESB)是构建基于面向服务体系结构(SOA)解决方案时所使用基础架构的关键部分,是由中间件技术实现并支持SOA的一组基础架构功能。ESB支持异构环境中的服务、消息,以及基于事件的交互,并且具有适当的服务级别和可管理性。简而言之,ESB提供了连接企业内部及跨企业间新的和现有软件应用程序的功能,以一组丰富的功能启用管理和监控应用程序之间的交互。在SOA分层模型中,ESB用于组件层以及服务层之间,它能够通过多种通信协议连接并集成不同平台上的组件将其映射成服务层的服务。

作为SOA基础架构的关键部分,ESB的功能主要体现在通信、服务交互、应用集成、服务质量、安全性以及管理和监控方面。在通信方面,ESB能够支持消息路由/寻址,支持多种通信技术、通信协议(如JMS、HTTP),支持发布/订阅的通信模式,能够处理请求/响应、同步以及异步的消息传递方式,并且要求以可靠的方式传递消息。服务交互方面,ESB上所发布的服务是以当前标准的Web服务描述语言(Web Service Description Language)来定义Web服务的,并且ESB上通常配备有服务目录和发现机制。ESB的重要功能就是集成不同的系统,必须能够支持多种接入ESB的方式(例如将ESB、Web Service、CORBA以及使用Socket等方式访问的遗留系统接入到ESB系统),将接入的系统映射成Web服务。在集成不同系统的同时,必须考虑服务质量方面的问题,如事务性和消息传递的可靠性。对于关键的Web服务,ESB需要以加密的方式进行消息传递,并且必须验证访问者的权限。ESB软件作为SOA基础架构的一个复杂子系统,还必须配有相应的管理和监控功能,用于ESB软件自身的系统管理、日志记录、测量和监控等。

2 基于SOA的医院应用集成方案

2.1 系统框架

国内现在大部分医院应用的系统主要包括核心业务系统和辅助业务系统。核心业务系统主要包括HIS系统、LIS系统、PACS系统和电子病历系统。辅助业务系统主要包括账务系统、人事系统、办公自动化系统等。

而医院跨行业的对外服务接口则包括跨保险行业、通信行业的服务接口以及对外信息服务平台。

其基于SOA的架构如图2所示。

如图2中的集成系统框架可分为资源层、接口层(主要包括对内服务接口层和跨行业服务接口层)和服务层共三层体系架构。三层的数据通信则基于HL7数据标准集成交互协议进行交互。

资源层包括了医院的所有业务系统、医疗资源数据库和医疗资源监管系统,医院的各业务系统提供业务资源的支持,实现服务的触发点,医疗资源数据库则将医院常用的、跨多个系统可共享使用的所有的医疗资源数据,在资源层上,医疗资源监管系统可直接监控管理医疗资源数据的使用权限和使用情况跟踪。

服务层将资源层的资源封装为服务,以便整合。根据资源信息化水平的不同,需采用不同的封装方法。一方面,将已建立了医院业务系统的资源通过连接服务、数据服务包装为服务;另一方面,对于尚未建立医院业务系统的资源,直接开发服务,如图中的就诊者远程医疗服务、就诊者就诊信息服务。所有服务都连入企业服务总线ESB(Enterprise Service Bus),并借助信息服务、流程服务、交互服务开发更复杂的服务或应用,实现信息整合。

接口层服务有两个部分,一个是医院对外的接口,包括与社保、医保的接口(支持多个地区),就诊者服务门户网站等,供与保险行业的连接和就诊者的服务,二是医院对内的接口,实现统一的医保社保服务接口,统一的检验检查服务接口等,提供给内部的ESB总线服务。

上述各层的数据格式、消息格式、接口等都要符合基于HL7的数据标准交换协议。

2.2 系统实现

按我们的设计,系统的实现如下图所示:

在系统实现上主要包括医院的内部应用集成和跨行业的应用集成。在内部应用集成上主要是对已有系统的业务流程整合,将已有的核心业务系统(包括HIS系统、LIS系统、PACS系统和电子病历系统等)和辅助业务系统(包括办公自动化系统、人事系统等)的业务流程和数据进行集成整合。在外部应用集成上则是对跨行业的服务进行集成整合,包括对保险行业的社保医保和商业保险的集成、通信行业的短信平台和Web网络应用等的集成。

在实现集成内容上主要包括以下三个方面:

(1)基于HL7的医疗数据集成存储在整个体系结构的数据集成上,存在着巨大的系统间数据集成和共享的需求。主要存在以下三类信息的集成交互。主要包括基础信息数据、患者信息数据和医嘱服务信息。这些信息涉及医院为提供基础医疗服务所涉及的各种基础医疗信息、患者服务信息和医嘱服务信息,这些需共享的数据主要包括医院的药品信息、器械信息、检验检查项目基本信息、物价信息、医疗工作者信息、患者信息、医嘱信息等数据,这些数据是医院能正常提供医疗就诊服务的基础信息数据。这些基础信息数据以基于HL7标准的数据封装存储在一个医疗资源数据仓库中;(2)基于SOA的医疗服务编排在整个体系结构中,存在大量的系统间业务流程的集成交互需求,因此必须先分析各个系统间集成交互的业务流程,提取这些业务流程,将每个系统的关键业务流程提取封装成标准的SOA服务,比如HIS系统和LIS系统间病人检验信息的调用服务,通过LIS系统将检验信息调用服务提取成标准的SOA服务。最终将这些系统间的SOA服务注册在一个统一的医疗资源服务库,在服务库内编排这些服务内容,将细粒度的服务整合成粗粒度的服务以供整个体系使用;(3)实现医院ESB总线平台通过基于HL7的医疗数据集成存储和基于SOA的医疗服务编排后,必须对这些数据服务和业务服务进行统一的调配使用,因此建立一个医院应用集成的ESB总线平台,在平台上构建标准的组件服务层,实现服务间的互联互通,ESB总线平台要实现的功能包括消息格式转换、服务管理功能、服务注册功能、服务路由功能、Qo S管理功能、安全管理功能以及事务管理功能等。

3 总结

针对当前医院系统存在的"信息孤岛"现象,医院系统内外部不能方便、低代价地实现异构系统的集成,难以适应现代医院快速的业务变化需求。本文提出了一种基于SOA架构的医院应用集成方式整合医院内部的各业务系统,以松耦合、灵活的架构实现医院ESB总线平台来服务于医院已有业务和新业务的发展,以组件化的架构方便系统的升级再造。

摘要：当前医院业务系统的应用集成问题已成为当前医院信息化乃至区域医疗信息化的关键。针对现有的医院应用系统的信息化状况,提出并设计了基于面向服务体系架构(Service-Oriented Architectures,SOA)的医院应用集成平台的解决方案。该集成平台通过基于HL7(Health Level Seven)协议提取封装医院内部的基础数据集,整合医院内部和跨行业外部的业务服务,最终建立医院的企业服务总线(Enterprise Service Bus,ESB)实现一个完整的医院集成平台架构。

关键词：面向服务的体系架构,基于HL7,医院应用集成平台

参考文献

[1]谢梅源.以面向服务体系结构(SOA)架构社区医疗信息系统.温州职业技术学院学报,2006,5(3).

[2]廖建军,胡宏涛.基于SOA实现企业应用集成.微机发展,2005,15(9).

[3]丁兆表,董传良.基于SOA的分布式应用集成研究.计算机工程,2007,33(10).

统一通信平台集成框架的研究与应用 第9篇

统一通信 (Unified Communication, 简称UC) 是以IP通信为基础, 以VoIP、视频通信、多媒体会议、协同办公、通信录以及即时通信等为核心业务能力, 通过多样化的终端, 以IP为核心的统一控制和承载网以及融合的业务平台实现各类通信的统一和用户体验的统一。

在SOA、SaaS环境下, 要求系统能够提供多租户和可伸缩的支撑和管理服务, 这是对系统很高的要求。为满足这些要求, 需要作技术方面的努力, 但更重要的是在系统的架构和方法论方面作深入的工作。

1总体框架

本框架由接入服务器、MQ (Message Queue) 集群、AppContainer服务组成。本框架结构如图1。

1.1接入服务器

接入服务器不仅是通信平台的入口, 在业务的集成方面, 接入服务器提供一个插件接口。其中插件对插件接口的主要实现步骤为:①注册第三方集成业务的命名空间;②与MQ集群建立JMS连接, 建立MQ连接;③对客户端的消息和MQ集群中的JMS消息进行监听, 解析收到的消息并封装;④将来自MQ集群的消息发送给客户终端, 将来自客户端的消息发送给MQ集群。

1.2MQ集群

位于同一个群集当中的若干队列管理器之间互相通讯时, 不需要在每一个队列管理器上创建消息通道、远程队列管理器以及与通道相关的传输队列的定义。因此, 采用MQ集群技术大大简化了平台的配置, 并且当某一系统或网络出现故障时, 能够自动进行负载均衡, 同时同一集群中的服务器可以位于不同的平台和物理位置, 使得平台的管理更加简单高效。

1.3AppContainer服务

AppContainer服务是基于OSGi服务框架实现的, OSGi服务框架提供一个通用的、安全的、可管理的Java框架。在OSGi中, 模块被称为Bundle, 是能够对外提供服务的构件, 由普通的JAR文件加上额外的元信息描述构成的。在OSGi服务中, 用户通过开发Bundle来提供所需的功能, 这些Bundle可以动态加载和卸载, 或者根据需要远程下载和更新。

2框架实现方法

2.1基于OSGi的AppContainer服务

出于平台的易扩展性与定义信息的统一传输链路的考虑, 抽象出以下Bundle:

(1) 接口服务Bundle定义了一组服务接口:JMS消息服务接口、消息处理接口、执行业务服务接口和线程池服务接口、以及对外提供统一的服务接口等。这些服务接口定义了AppContainer服务中的Bundle对各自的业务处理所需要的所有服务, 对这些接口中所有方法的说明如下:

①消息处理接口:定义了对接收到消息进行处理的方法。Java描述如下:

(2) JMS Bundle是对接口服务Bundle中JMS消息服务接口的实现, 其主要职能是负责AppContainer服务中消息的接收和发送。对JMS Bundle职能的具体说明如下:①建立JMS连接、连接MQ, 并对MQ的连接进行监听, 若断线则立即重连;②对JMS消息进行监听, 若接收到JMS消息, 则调用线程池服务, 开启一个线程;③在该线程中调用消息服务, 将消息发送至服务控制Bundle中继续处理;④将消息封装成JMS消息发布到MQ集群中。

(3) 服务控制Bundle是对接口服务Bundle中消息服务接口与对外统一服务接口的实现, 其主要职能是根据命名空间分发消息请求到对应的业务Bundle去处理。对服务控制Bundle职能的具体说明如下:①绑定对外统一服务接口的地址;②接收到主动查询请求消息, 解析出消息中的命名空间, 根据命名空间将查询请求消息分发至相应的集成业务Bundle去处理;③接收到推送服务请求, 解析出命名空间, 并从线程池中启动一个线程, 在该线程内, 完成业务的分发、集成业务Bundle对业务的处理以及向MQ集群的推送服务。

(4) 线程池Bundle是对接口服务Bundle中线程池服务接口的实现, 其职能利用线程池来控制线程的数量, 避免平台资源的浪费, 提高平台系统的工作效率。

(5) 集成业务Bundle代表了所有可集成到平台中的业务Bundle。通过开发第三方业务Bundle, 来达到平台对第三方业务集成的目的。具体工作方式如下:①接收到主动查询请求消息, 解析查询请求, 并通过解析结果同对应的第三方业务系统进行交互并进行业务的查询, 并将查询结果返回给JMS Bundle处理;②接收到推送请求消息, 将消息封装成XML消息流, 然后将结果返回给JMS Bundle处理。

抽象出的Bundle结构如图2所示:

AppContainer基于OSGi的特性与支持服务的分发功能保证了第三方业务Bundle能在本平台上热插拔, 同时决定了第三方集成业务能够在平台正常运行的过程中与平台进行动态的集成。

2.2高负载支持

MQ集群技术提供异步的、非阻塞的消息传递。即发送方可即时将消息放入消息队列, 而接收方也能随时从队列中取出消息进行处理。这样避免了双方直接接触保证了任何一方发生脱机时消息都不会丢失。这种可靠的、松耦合的消息传输方式, 在分布式环境下进行多数据的发送和接收时依然能够稳定可靠地通信。

针对与需要不断集成的第三方业务, 部署多个AppContainer服务模块, 将集成业务Bundle平均部署到每个AppContainer服务中, 以此缓解平台压力。

2.3统一接口

每种业务系统都存在着自己定义的用户接口, 进行集成时, 为实现接口的容错处理机制, 避免因为一个系统的接口中断而影响到其它应用系统的接口, 平台向外提供了统一的服务接口, 与第三方业务进行交互。根据不同应用服务的需要, 统一的接口包括:RMI (Remote Method Invocation, 远程方法调用) 接口、Web Service接口、JMS接口等。

统一的接口对业务的集成而言, 简化了集成方式, 方便了维护方法, 实现了接口的可重用性和可管理性。

3集成实例

在本框架下, 我们将此平台与办公自动化 (OA) 业务进行集成实验。开发者仅需要开发接入服务器插件和OA业务Bundle即可实现平台与OA业务的集成。接入服务器中OA插件主要做以下方面的工作:

(1) 注册请求OA消息的命名空间。

(2) 对客户终端的请求消息进行监听, 若与命名空间匹配, 则解析出消息内容, 并封装成JMS消息发布到MQ集群中, 客户终端的XML消息格式如下所示:

(3) 对MQ集群中的消息进行监听, 若监听到发送给客户终端的消息, 则将消息解析出来, 封装成与客户终端交互的消息格式, 发送给客户终端。解析出来发送给客户终端的XML消息格式如下:

(1) 根据查询请求中的信息登录到OA系统, 查询待办项目或通知的个数。

(2) 将推送消息解析封装, 并将封装结果返回给JMS Bundle。

在AppContainer服务中的流程分为主动查询流程和推送流程, 主动查询流程描述如下:①JMS Bundle监听到MQ中有查询OA待办项的请求消息;②JMS Bundle从线程池中启动一个线程, 然后在此线程中, 将此查询请求消息发送至服务控制Bundle中;③服务控制Bundle获取并匹配OA业务的命名空间, 然后分发到OA业务Bundle中;④OA业务Bundle向OA系统进行待办项数目的查询, 并将查询结果返还给JMS Bundle。该Bundle将结果封装成JMS消息发布到MQ集群中。

最后由接入服务器的OA插件从MQ中提取到查询结果, 并将查询结果返还给客户终端。具体流程如图3所示:

推送流程描述如下:①OA业务系统调用平台提供的RMI接口将待办或通知的个数消息发送到平台的AppContainer服务中;②服务控制Bundle获取该消息并根据命名空间进行匹配, 匹配成功后启动一个线程, 在此线程内, 将消息分发到OA业务Bundle中;③OA Bundle通过接口服务提供的JMS消息服务接口调用JMS Bundle中的发送JMS消息方法, 将消息封装成JMS消息, 并发布到MQ集群中。

最后接入服务器中的OA插件从MQ中获取推送消息后, 发送给客户终端。具体流程如图4。

4结语

本文提出的统一通信平台集成框架对私有协议、消息格式和通信链路不同的办公应用进行了研究, 为构建一个扩展性好、重用性高、通信链路统一、支持大并发的统一通信平台提供了一个新的解决方案, 在企业的多个系统中搭建了一座信息的桥梁, 实现了信息的互通和共享, 为企业的协同作业提供了技术支持。更重要的是为用户提供了一个桌面门户和平台, 为其它的企业应用提供了一个统一的入口端。不仅如此, 在该框架下, JMS消息链路和MQ连接的建立都可以重复使用, 因此对第三方企业业务进行集成的开发效率上也有较大提高。

参考文献

[1]江志峰.从统一通信看IMS的发展[J].电信科学, 2008 (2) .

[2]闵丽娟, 朱珠, 娄高见, 等.开放信息服务的运营支撑和服务管理系统[J].电信科学, 2011 (11) .

[3]吴成宾, 朱彬.基于MQ的文件分片传输系统的设计与实现[J].电子科技大学学报, 2007 (3) .