异构系统通信模型技术（精选4篇）
异构系统通信模型技术 篇1
一、引言
光线网络、移动通信等网络技术快速发展, 能够将分布于各个位置的计算机终端连接在一起, 实现云计算服务, 共享数据资源[1]。云计算服务环境中, 接入的系统设计架构包括C/S架构、B/S架构, 开发技术包括JSP技术、PHP技术、ASP .NET技术等多种, 应用系统之间是异构的, 无法直接进行网络通信[2]。本文基于ESB技术、SOA技术、XML技术设计了一种异构系统网络通信平台, 提高云计算环境下异构系统通信传输性能。
二、云计算环境下异构系统网络通信功能设计
基于ESB架构的异构系统集成平台业务系统的接口都不相同, 采用的接口技术主要包括Web Service技术、MQ消息机制、FTP技术, 这些技术均可以与ESB进行直接连接, 在ESB中心端执行数据交换, 采用SOA面向对象思想, 将其融入到ESB架构中, 设计各个独立的逻辑业务管理系统的数据交换与共享接口, 在设计过程中将每一个接口统一转换为Web Service模式, 并且以服务的模式实现数据交换[3]。如图1 所示。
三、云计算环境下异构系统网络通信技术研究
(1) ESB技术。ESB是一种中间件技术, 可以支持实现SOA的功能, 因此ESB作为一个体系架构的构造器, 可以部署配置SOA、设计SOA的相关逻辑业务处理流程, 并且能够将EAI与应用服务器技术互相结合起来, 简而言之, ESB在SOA架构中扮演的角色非常重要, 比如是最基本的数据路由、数据传输角色, 可以为用户提供消息代理传输机制, 增加SOA架构的功能, 完善系统服务, 并且可以扩展SOA架构物理范围。
(2) XML技术。XML技术是一种有万维网协会创建的自我描述性的语言, 创建XML最为重要的目的是实现数据采用一种合适的文本方式进行传输, XML可以创建其他的语言和描述其他语言采用的数据结构, 由标记符和属性描述共同构成, 这种自我描述的特性使XML具有自我解释的能力, 更容易让系统理解和接收, 同时XML语言具有文本特性, 可以方便地进行运行维护和数据交换。
(3) SOA技术。SOA相关的技术包括SOAP传输协议、UDDI集成化协议、WSDL协议三个方面。SOAP协议定义了服务请求者和服务提供者之间一种完善的传输规范, 因此SOAP协议使得XML数据传输更加安全, 同时SOAP协议采用了传统的互联网传输协议HTTP作为数据传输的标准, 可以格式化相关的协议信息, 并且能够承载HTTP协议消息。UDDI协议是一种集成、发现和描述相关的协议, 其可以表示一个实际的注册表, 能够用来描述和发现相关的数据传输标准, 系统能够建立一个具有平台无关性、数据共享化的体系架构, UDDI可以基于SML和SOAP技术为用户提供强大Web服务内容, 实现SOA与其他服务标准的交互。WSDL是一种描述Web服务的语言, 该语言定义了一种健全的、完善的网络访问机制, 其可以配置Web服务请求函数、Web业务请求返回值和相关输入参数等, WSDL保存在相关的UDDI中, UDDI可以从WSDL中找到相关的服务关键词。
四、结束语
随着云计算技术的普及和使用, 更多的应用系统接入到云计算服务平台上, 设计一种异构系统网络通信平台, 可以提高计算机资源的利用率, 虚拟化硬件资源, 提高软件资源的接入率, 进一步提高系统的并发性, 高速处理用户的逻辑业务请求。
摘要：云计算可以将分布于互联网每一个角落的软硬件资源集成在一起, 为用户提供强大的云计算服务功能。云计算服务接入的系统越来越多, 系统设计架构、实现技术等不同, 造成异构系统之间通信困难, 需要使用一个中间件平台, 共享异构系统数据资源。
关键词：云计算,异构系统,网络通信,ESB
参考文献
[1]任磊, 陈风波, 吴永刚, 等.异构STAP系统的多层次数据通信研究[J].空军预警学院学报, 2013 (01) :52-54.
[2]张琛, 粟欣, 王文清, 等.异构网络跨层协作传输技术研究[J].通信学报, 2014, 35 (08) :198-205.
[3]方焕.基于XML的分布式异构数据库同步系统设计与实现[J].广西通信技术, 2014 (4) :21-25.
异构系统通信模型技术 篇2
视频监控系统是一种利用摄像机和报警器监视设防区域并实时显示、记录现场图像的电子系统[1], 一般划分为早期的模拟视频监控系统和现已广泛应用的数字视频监控系统。由于前者缺乏必要的通信和控制模块, 需要改造成数字系统后才可进行网络化集成, 故本研究的视频监控系统均指数字视频监控系统。典型视频监控系统的结构框图如图1所示[2,3,4]。其中, 前端设备层包括摄像机、报警器等设备, 用于提取视频源和报警信息;设备管理层通过各种类型的服务器管理前端设备, 各类视频服务器的详细描述见文献[3];系统服务层需要封装设备管理层中服务器的功能接口, 为用户提供统一的系统服务接口, 并对设备信息、视频信息以及用户信息进行集中存储管理。
需要指出的是, 由于视频监控系统建设一直缺乏统一的规划和标准, 因此, 长期以来, 不仅不同行业, 甚至相同行业内的视频监控系统都是以小范围区域性部署为主, 且呈现出一定的差异性, 虽然结构形式基本相同, 但构成系统的具体模块存在深层次的异构性。主要体现在如下3个方面:设备管理层中服务器功能接口的差异, 系统服务层中系统服务类型和接口的差异, 以及数据库结构的异构。然而, 随着视频监控技术的不断发展和视频监控系统的广泛应用, 特别是在电力行业和城市交通系统中的大规模应用, 克服视频资源的“信息孤岛”现象并实现统一管理和后期的系统再扩展已经成为现代视频监控系统发展的主要方向之一。因此, 为从根本上解决现有监控系统的异构问题进而实现监控信息共享和系统扩展, 异构视频监控系统集成技术和模型已经成为亟待解决的关键问题。
本研究针对此问题提出了基于节点自治的系统集成模型及技术。
1 传统视频监控集成技术与模型分析
传统的监控系统集成技术直接对子系统的设备管理层进行访问和管理, 而不与系统服务层产生交互, 如图2所示[5]。集成过程一般分两步进行:一是移植子系统中的设备信息到整个模型系统服务层的数据库中;二是将设备管理层中不同服务器功能接口进行封装形成统一的用户调用接口。因此, 上述技术必须解决异构数据库信息共享和服务器功能接口封装等问题。
为解决现有数据共享技术和模型的不足, 文献[6]提出了一种基于黑板模式的信息共享解决方法。然而, 该方法在实际应用中, 无论从技术难度, 还是从工作量方面来说, 都存在着难以逾越的障碍。因此, 实际工程应用中往往不采用这种数据共享方法, 而是建立独立的数据库, 将子系统的设备信息人工添加到数据库。虽然这种方法不失为一个解决之道, 但其弊端也很明显:数据库中设备信息更新不能同步。另一方面, 尽管视频服务器功能接口的封装在实践中不存在任何障碍, 但封装后却存在巨大隐患, 即异构系统的设备管理层将同时服务于两套系统应用层, 并在资源调用方面缺乏协调管理机制和能力, 可能产生冲突, 导致视频监控服务无法稳定运行。
传统视频监控集成技术和模型的上述缺点限制了监控系统的扩展性。因为, 若需集成新的监控系统, 必须人工更新系统数据库的设备信息, 甚至需要重新封装系统中新型服务器的功能接口。有鉴于此, 本研究提出了一种基于节点自治的视频监控系统系统集成技术和模型。
2 基于节点自治的异构视频监控系统集成技术和模型
节点自治的思想来源于MIT计算机科学学者Minsky提出的Agent概念。Minsky在其《Society of Mind》一书中将社会与社会行为概念引入计算系统, 并将自治性作为Agent的属性之一。自治性是指节点应是独立运行的, 并根据内部状态和感知到的环境信息决定和控制内部状态和自身的行为[7]。将这一思想应用到异构视频监控系统的集成, 各异构系统作可看作为独立运行并维持其内部运行状态的节点, 节点外的访问者只能通过节点规定的服务接口获取相应资源。因而, 通过节点自治可以提高节点本身运行的稳定性。
兼顾异构系统的自治性和异构系统间资源共享的要求, 本研究的异构视频监控系统集成技术和模型定义了3种不同功能的节点:视频服务节点、信息管理节点和用户节点 (如图3所示) 。视频服务节点为待集成的异构系统增加代理层后的节点;信息管理节点为管理模型中全局信息节点;用户节点为模型中资源的访问者。整个模型的运行依赖于节点间的服务。视频服务节点提供自描述, 功能调用, 信息订阅3种服务;信息管理节点提供视频服务节点注册和视频服务节点地址查询等服务。而用户节点属于模型中的消费者, 不提供服务。加入模型的视频服务节点需向信息管理节点注册。用户节点从信息管理节点中获取视频服务节点的地址, 再通过视频服务节点提供的服务获取其他资源。
2.1视频服务节点
视频服务节点的设计既要保持原视频系统的独立性又要为其他节点提供服务。因此, 代理层的添加不应破坏原有系统的结构, 而必须与原系统用户的调用方式保持一致, 并经系统应用层进行资源访问。为此, 本研究设计了一种典型的视频服务节点结构, 其结构图如图4所示。
上述代理层的各项服务完全依赖于系统服务接口, 从而避免了设备管理层中服务器功能接口的重复封装, 同时因为原系统数据库中存储的信息能够通过系统服务接口获取, 异构数据库的设备信息共享问题也因此迎刃而解。由于在上述系统中系统服务的类型以及功能接口的差异依然存在, 本研究视频服务节点的代理层具有自描述服务和功能调用服务。
2.2自描述服务
自描述服务定义了向服务请求方提供本节点管理的所有设备信息以及能够支持的视频服务的类型。设备信息包括设备类型、设备名称、设备ID和设备描述。其中设备类型抽象为两种:摄像机和报警器。设备名称和设备描述一般无特别界定。视频监控系统提供的服务类型虽有差异, 但经长期的实践应用已趋于一致, 参考安讯士、博世及索尼公司联合制定的开放型网络视频接口核心规范 (ONVIF) [8], 本研究模型中定义了视频服务类型的总集合, 包括:实时视频流获取, PTZ控制, 录像查询, 录像下载, 设备状态查询。在应用中, 某一节点信息的XML (可扩展标记语言) [9]具体描述为:
上述描述文件中定义了设备集合“DeviceInfoSet”和功能集合“ServiceTypeSet”。设备集合包含该节点的设备信息记录, 功能集合定义了该节点对视频服务的支持情况。
2.3功能调用服务
功能调用服务向访问者提供视频服务接口描述并处理访问者的功能调用请求。WSDL (网络服务描述语言, Web Services Description Language) 是一种基于XML的语言, 用于描述Web Services的接口[10]。本研究使用该语言对视频服务接口进行定义。以录像查询接口的描述为例, 其功能调用服务如下:
上面描述文本中定义了录像搜索服务的操作集合“RecordSearchFunctions”。集合中包括两种操作:“SearchRecord”和“GetRecordInfo”。“SearchRecord”操作用于查找符合条件的录像数目, 其输入信息为“SearchRecordRequest”, 包括录像的起始时间“BeginTime”, 结束时间“EndTime”以及录像类型“RecordType”。而输出信息“SearchRecordResponse”中则包含了符合搜索条件的录像数目。“GetRecordInfo”操作用于获取指定录像文件信息。输入信息“GetRecordInfoRequest”中包括指定文件的ID, 输出信息“GetRecordInfoResponse”中包含指定文件的名称和文件大小。
2.4信息订阅服务
本研究信息订阅服务主要针对节点中报警器的报警事件, 采用典型的订阅/通知模型如图5所示。该服务一般分两步完成:第一步, 用户节点向视频服务节点发送订阅请求, 请求信息必须包含报警器的ID和报警信息接收地址, 视频服务节点返回用户订阅成功与否的相应消息。第二步, 当报警器发生报警事件后, 视频服务节点必须向订阅该信息的用户发送报警通知, 用户接到通知后返回约定的响应消息。
2.5信息管理节点和用户节点
信息管理节点的主要功能是登记模型中的视频服务节点信息, 并供其他节点查询。其注册服务和地址查询服务的实现依赖于模型中的注册机制:视频服务节点在加入整个联网系统前首先向信息管理节点发送注册消息。注册消息包括本次注册的有效时间、能够提供节点服务的网络地址、系统节点名称和位置。信息管理节点对注册信息进行验证、核准, 对符合接入条件的视频服务节点进行登记。若视频服务节点的网络地址发生改变, 则必须重新注册。用户节点作为消费者, 必须能够向其他节点发出服务申请, 并利用其他节点提供的服务获取相应的资源并进行显示。
3 应用实例
为验证上述基于节点自治的异构视频监控系统集成技术和模型的有效性和正确性, 本研究应用其对南自信息技术有限公司的ObserverStar视频监控平台 (如图6所示) 和网络视频监控软件平台 (如图7所示) 进行了集成。上述两套系统无论在视频服务类型和接口方面, 还是在内部数据库结构方面都存在明显的差异, 因此, 这是一个典型的异构系统集成问题。在集成过程中, 增加了信息管理程序作为信息管理节点, 开发了视频客户端程序作为用户节点, 并在两套系统中分别添加代理程序后使之成为视频服务节点。节点间使用XML文本进行通信, 而媒体流的传输采用实时通信协议 (RTP/RTCP) 实现。在集成后的视频服务系统中, 客户节点能够获取原本分属于两套软件管理的设备信息和视频资源, 满足了视频资源共享的相关需求。客户节点的运行效果图如图8所示。
需要说明的是, 本研究的技术和模型已成功应用于广东电网全省变电站及环境视频监测系统、四川电力公司变电站视频监控系统。与原基于传统集成技术的视频监控系统对比, 二者的性能比较如表1所示。由这些结果不难评价本研究模型和方法在工程应用中的优越性。
4 结束语
本研究提出了一种基于节点自治的异构视频系统集成技术和模型, 并使用XML和WSDL对异构系统中的设备信息和视频服务接口进行描述。节点自治加自描述机制的应用不仅实现了视频资源的共享访问, 也克服了传统模型在扩展性方面的不足。若有新的视频系统加入, 只要添加代理层, 提供自描述和功能调用服务, 用户节点就能对其资源进行访问。此外, 从长远来看, 欲实现异构系统间资源的统一管理和安全访问, 上述集成技术和模型中还需添加相应的权限管理机制和安全机制, 这也正是笔者未来努力的方向之一。
摘要：随着视频监控系统的普及和推广, 资源共享已经成为异构视频监控系统集成中亟待解决的关键技术问题之一。而传统视频系统集成模型和技术在应用中存在着扩展性和稳定性方面的不足, 针对此问题提出了基于节点自治的系统集成模型及技术。通过定义模型中不同角色节点的服务, 既屏蔽了系统间的异构性又保持原系统的独立性;通过对视频服务节点设计的自描述服务增加了系统的可扩展性。典型工程应用结果表明了该系统集成模型及技术的有效性和优越性。
关键词：视频监控系统,异构性,自描述,节点自治
参考文献
[1]李向东.数字视频监控系统的研究与实现[D].西安:长安大学环境工程学院, 2008.
[2]赵青芝, 叶旭东, 朱善安.基于DM642的无线视频监控系统[J].机电工程, 2010, 27 (4) :73-74.
[3]汪洋洋, 李霞.多源异构视频整合技术的应用[J].计算机工程, 2008, 34 (23) :235-257.
[4]凌庆华, 石志强, 程伟明.基于SIP的网络视频监控系统的设计与实现[J].计算机工程, 2007, 33 (2) :261-263.
[5]钟远山.一种统一的视频监控管理平台的研究与实现[D].广州:中山大学软件学院, 2009.
[6]张琳娜, 王映辉.基于节点自治的分布式数据共享模型[J].计算机工程, 2009, 35 (3) :32-38.
[7]MINSKY M.The society of mind[M].New York:Simonand Schuster, 1986.
[8]ONVIF.Open network video interface forum core specifica-tion[S/OL].http://www.onvif.org/, 2009.
[9]W3C.Extensible Markup Language (XML) 1.0[S/OL].ht-tp://www.w3.org/TR/1998/REC-xml-19980210, 1998.
异构系统通信模型技术 篇3
关键词：通信链路,网络监视,GIS显示
一、引言
随着通信技术快速发展, 通信网络构成也在迅速多样化, 传统基于设备状态监视的网管系统已经不能完全反映通信网络运行状态, 特别是在公安、军队等单位多种体制的通信网络相互交联, 整合多个网管系统成本很高, 导致异构通信网络监视手段相对缺乏, 本文从IP体制网络入手, 研究通过通信网络链路层和网络层主动获取相关网络参数方法, 设计通信网络参数获取、显示、部署及运用方式。
二、异构通信网络特点
异构通信网络是公安、军队等单位执行任务的基础保障, 不同于一般民用通信网络, 主要特点如下:
(1) 网络类型多; (2) 可靠性要求高; (3) 链路易中断; (4) 业务接入不固定; (5) 网络管理相对独立。
三、异构通信网络状态监视需求与获取方式
在公安、军队等单位通信网络使用过程中, 指挥人员最关心的几个问题是:我的通信设备部署哪里?开通了那些通信链路?现在通信状态怎么样?通信业务能不能满足需求?这就需要通信网络状态监视系统能够获取这些信息, 实时显示在指挥员面前, 具体信息种类及获取方式如下:
(1) 通信设备布站信息, 采用人工标绘和自动获取方式获取; (2) 无线通信范围信息, 采用人工设定和辅助计算方式获取; (3) 通信链路通断信息, 采用主动探测方式获取; (4) 通信业务开通信息, 采用数据包分析方式获取; (5) 通信链路质量信息, 采用主动探测和数据分析方式获取; (6) 通信链路告警信息, 采用人工策略和智能分析技术获取; (7) 通信网络状态统计信息, 采用GIS和表页综合显示模式获取。
四、系统软件实现方法
系统采用主动探测和被动获取相结合的方式, 主动探测基于ICMP协议, 通过发送ping包获取通信链路通断、时延、抖动、丢包率等参数信息, 被动获取基于抓取网络数据包, 通过数据分析获取通信链路流量、业务种类、带宽利用率等信息, 通过融合双方数据监视整个通信网络, 直观显示装备布站、无线通信范围、整体网络拓扑、链路质量等信息。
4.1软件总体结构
软件总体结构如图1所示。网络探针模块主要完成链路探测、流量分析、本地显示和数据上报功能;GIS模块主要完成综合布站信息显示、网络拓扑信息显示和无线覆盖范围信息显示功能;表页显示模块主要完成链路通断状态显示、链路质量信息显示和链路状态信息录取功能;数据库管理模块主要完成通信网络拓扑信息管理、通信节点信息管理和业务终端信息管理;通信模块主要完成远程多探针管理和多用户数据分发功能。
4.2软件信息流程
软件信息流程如图2所示。显示软件具备数据库功能, 能够为用户使用软件提供交互窗口, 用户可根据使用需求对探针软件进行参数设定, 可通过显示软件对探针软件进行管理, 参数信息设定好后, 显示软件通过通信模块将参数下发给探针软件, 探针软件根据接收的探测参数及运行指令开启链路探测进程和流量获取分析进程, 对进程进行管理控制, 然后对获取的数据进行统计、封装, 一份用于本地显示, 一份用于上报显示软件。显示软件通过TCP/IP协议接收上报数据, 对数据进行分选、计算、统计, 读取数据库通信节点、装备、业务信息, 将探针软件上报信息和本地数据库信息融合, 送给GIS显示模块和表页显示模块显示, 表页显示模块可根据用户需要对表页显示数据进行记录, 用户可实时调整软件运行所需参数, 形成软件运行闭环。
五、系统部署运用方式
软件部署采用分布式部署使用方式如图3所示, 多探针收集, 多用户显示, 集中管理。探针软件部署在主要路由器、核心交换机、无线网络专用交换机部位, 用于获取通信网络状态参数;GIS服务器部署于网络中心机房, 用于融合多探针数据, 提供GIS显示所需服务;GIS显示软件部署于指挥中心, 用于直观显示装备布站、链路通断和网络拓扑信息;表页显示部署于后台, 用于详细显示装备部署、链路质量、业务识别等信息。用户管理置于后台, 用于管理员进行软件参数设定、运行保障。
六、系统关键技术
6.1基于ICMP协议的IP链路参数获取技术
ICMP协议使用IP协议进行信息传递, 向数据包中的源端节点提供发生在网络层的错误信息反馈, 通过ping报文返回数据可以获取端到端的链路时延和丢包信息, 统计时延和丢包信息可实时计算链路抖动和丢包率。要想获取几百条链路参数, 单一探针需要开启几百个线程, 对硬件要求高, 实现起来比较困难, 本文采用多线程发包, 单线程收包处理的方式, 有效解决了这一问题, 分布式探测数据融合也是一个难点, 本文通过数据库规划的方式有效融合了多探针数据。
6.2基于数据采集探针的监测技术
数据采集探针通过交换机流量镜像端口或直接将其串接在待观测的链路上, 对链路上所有的数据报文进行处理, 提取流量监测所需的协议字段甚至全部报文内容。经条件设置对网络流量进行实时采集或流量镜像, 进行报文的协议分析。一个探针同时只能监测一条或几条链路的流量信息。对于全网流量的监测需要采用分布式方案, 在重要通信节点部署一个探针, 再通过后台服务器和数据库, 收集所有探针的数据, 做全网的流量和业务分析。
6.3基于GIS的宏观网络态势显示技术
GIS显示主要依托地理信息系统, 在地图上叠加显示通信节点位置、无线基站覆盖范围、通信链路通断状态等信息, 通信节点位置采用军标符号标注方式, 固定节点直接读取数据库经纬度, 移动节点提供外来位置信息接口, 实时在地图上刷新通信装备布站数据, 无线基站覆盖范围通过输入基站高度, 自动计算基站视距范围, 在地图上用圆圈覆盖显示, 通信链路通断状态采用在地图上显示通信节点网络拓扑, 节点间通信质量采用不同颜色的线来显示。
七、系统软件测试结果
软件测试截图如图4所示, 系统软件实时获取了基于IP网络层数据, 直观显示多条通信链路质量信息, 能够满足通信网络状态监视需求。
八、结束语
本文通过实验方式对设计内容进行初步实现, 实验结果证明通过系统软件能够主动获取IP网络链路层和网络层信息, 提取不同通信网络链路状态参数, 满足异构通信网络实时监视需求, 系统软件具有通用性, 可移植性强, 不受通信设备体制限制, 具有很高的应用价值。
参考文献
[1]周莲英.超宽带无线自组网若干关键技术研究.南京理工大学, 2007, 10.
异构系统通信模型技术 篇4
煤矿信息化系统种类繁多,大部分系统采用的技术路线不尽相同,存在系统间交互困难、数据表示不统一、信息共享不同步等问题,给煤矿企业安全生产管理者带来了诸多不便。本文在分析煤矿企业现有异构系统集成方式优缺点的基础上,提出了一种基于BizTalk的煤矿企业异构系统集成模型。
1 煤矿企业异构系统集成发展
在煤矿企业信息集成的早期,每个部门使用的都是独立的应用子系统,这些应用子系统按照各自不同部门的应用需求产生不同的数据信息,比如安全监控系统和人员定位系统,它们彼此是自包含的,无需交互。这个时候的信息集成只是简单地将信息从一个系统传递到另外一个系统,应用程序之间没有任何交互接口,真正的无缝集成很少,也很难实现。随着时间的推进,不同的组织单位开始使用基于点对点集成方式的应用程序,数据可以方便地在不同的应用程序之间流动。但是,要实现这种集成方案需要耗费大量的时间和精力,不同的软件开发人员需要通力合作建立技术约定、共享数据模型、交互的方案和协议等。尽管实现成本较高,但点对点集成方式仍然流行了一段时间。点对点集成方式存在一定的劣势和固有的脆弱性:如果一个子系统的约定改变了,那么和它相关的其他子系统也必须进行改变,以适应新的交互方式,随着应用子系统越来越多,点对点集成将变得很难管理,导致更多的IT资源用于集成的维护工作而不是解决新的和紧急的业务需求。最终,在点对点集成方式中引入了hub-and-spoke模型,其结构如图1所示。在这个模型中,应用子系统先将消息发布到中心的hub服务,然后由hub服务将消息统一转发给其他的接收者。消息的发送者和接收者的关系可以通过配置或者发布订阅规则进行动态定义。该模型使发布消息的应用程序无需关注接收者,消息接收者也无需关注发送者,最终达到系统和系统之间松耦合的目的。
目前,在煤矿企业实际应用的信息集成方式有以下几种[1]:数据仓库法、中间件法及综合集成法。数据仓库法将来自多个业务系统数据库中的数据复制到数据仓库中,由于数据仓库中保存有大量的历史数据,查询效率高,对网络的依赖性弱,但数据同步的实时性较差。中间件法通过提供一个统一的数据接口来访问异构系统的数据,自身并没有任何数据。该方法构建灵活,实时性好,但对网络的依赖性强,查询效率低,实现算法复杂。综合集成法是上述2种方法的结合体,查询效率高,实时性好,但建设成本高,对中间件的依赖性强。本文提出的基于BizTalk的煤矿企业异构系统集成模型是上述hub-and-spoke模型的一种具体实现,是对综合集成法的一种改进。
2 BizTalk简介
BizTalk是微软实现服务器连接的解决方案,用于将不同的系统组合到有效的业务流程中。BizTalk作为企业应用集成服务平台具有良好的架构,包括业务流程处理框架、消息处理框架、应用接口适配器框架和一个采用集中式数据存储的消息服务引擎(MessageBox)。消息服务引擎用于提供与其他一系列软件通信的消息传送组件,通过依靠不同通信类型的适配器,可以支持诸如 Web Services之类的各种协议和数据格式,支持创建和运行被称为业务流程的以图形方式定义的程序。业务流程建立在该引擎的消息传送组件的基础上,可实现驱动所有或部分业务程序的逻辑。BizTalk支持如下2种方式的应用程序集成,即企业应用程序集成(Enterprise Application Integration, EAI)和企业对企业集成(Business to Business,B2B)。EAI用于连接单个企业内部的应用程序。B2B用于连接不同企业之间的应用程序。本文针对煤矿企业现状,主要讨论EAI方式。
3 集成模型设计
3.1 基于BizTalk的煤矿企业异构系统集成结构
针对煤矿企业异构系统的复杂性、各个应用系统之间业务逻辑处理复杂度较高、在进行数据集成时对业务流程处理的要求也较高等特点,采用BizTalk作为企业数据集成总线的方式来对异构系统进行集成,如图2所示。
3.2 设计目标
基于BizTalk的煤矿企业异构系统集成模型作为煤矿信息化建设的基础平台,不仅承载着各个业务系统之间数据交换及采集的需求,还肩负着存放共享数据的任务。其设计目标:
(1) 实时性。即当异构系统源数据发生改变后,数据必须能够及时到达需要该数据的其他应用系统中。
(2) 安全性[2]。即通过集成模型交互的数据必须是不能随意查看和修改的。可通过设置一定的权限来限制用户对数据的访问,还可按照一定的规则对交互数据进行加密,这样即使传送的数据被截获,也不会造成数据泄密。
(3) 一致性和完整性。即异构系统之间的共享数据应该是一致的,并且是完整的。集成模型能够采取有效措施防止因数据交互过程中发生的异常而导致的数据不完整、不一致现象发生,如网络中断、设备故障等原因造成数据交互失败时,集成模型应具备重新同步的机制。
(4) 扩展性。对于集成模型建设完成后建立的新业务系统,数据集成平台能够很方便地实现新系统数据的共享与同步。随着煤矿信息化水平的提高,会产生更多的业务系统, 而这些系统中大部分都会有数据集成与共享的需求,所以,集成模型的扩展性就变得非常重要,是衡量集成模型建设是否成功的重要指标。
3.3 整体架构
基于BizTalk的煤矿企业异构系统集成模型分为子系统应用层、应用接口适配器层、消息处理层、消息服务引擎层、业务逻辑处理层、数据中心层、协调控制管理系统平台层,其架构如图3所示。
(1) 子系统应用层。
包括煤矿企业中的异构系统,如瓦斯抽采子系统、人员定位子系统、广播子系统等,每个子系统对外提供的交互接口都不相同,并且都需要把数据集成到统一的综合平台上进行展示,通过对这些数据的二次分析,把各个子系统有机地串联起来。
(2) 应用接口适配器层。
煤矿各个应用子系统对外提供信息和接收信息的方式各不相同,如采用File,HTTP(Hyper Text Transfer Protocol),SMTP(Simple Mail Transfer Protocol),Web Services及DBMS(Database Management System)等方式[3],可通过使用单独的适配器层来分离服务模型(消息处理层)对异构系统交互接口的关注。BizTalk 提供一个主机环境使适配器可与BizTalk 交互,同时也提供了创建或者扩展现存适配器的功能。除此之外,BizTalk提供了一个开箱即用的扩展类库支持数据库系统、第三方ERP( Enterprise Resource Planning)和CRM(Customer Relationship Management)等不同的适配协议。
(3) 消息处理层。
负责将接收到的消息或要进行发送的消息根据消息的处理规则(拆包、封包),实现消息的预处理操作序列。将对象与若干XML(Extensible Markup Language)数据包进行转换,并对消息体进行加密、解密、编码、解码等。
(4) 消息服务引擎层。
采用集中式业务流程数据存储方式(SQL Server方式),支持多种数据存储介质。BizTalk 中消息服务引擎的核心是MessageBox数据库。如果有业务流程订阅消息,则MessageBox数据库将向该业务流程发送所订阅的消息。当业务流程接收到消息后,将在可用的主机实例上处理该消息。消息处理后,如果业务流程订阅了管道或发送端口,则该业务流程将向MessageBox数据库发送一个返回消息[4]。
(5) 业务逻辑处理层。
包括业务流程的定义与管理,业务流程是可执行的业务程序,可通过MessageBox数据库订阅和发布消息。此外,业务流程还可构造新的消息。在填入业务流程的订阅后,将激活新的实例并传送消息;如果从业务流程发送消息,则这些消息将发布到MessageBox数据库。BizTalk 提供了图形化的业务流程定义工具来定义具体的业务流程,还提供了业务活动监视组件来监视业务流程的运行状态,并及时处理流程运行过程中产生的异常情况[5]。
(6) Web服务。
BizTalk将数据的获取和提交转变为Web服务,新建立的应用系统可与集成模型之间通过这些服务进行对接,只需要调用这些服务就能实现共享数据的获取。同时,新应用系统也可能是共享数据的提供者,所以它也可以通过调用Web服务的方式完成共享数据的提交,有效提高了系统的扩展性[6]。
(7) 数据中心层。
数据中心采用SQL Server存放异构系统之间的共享数据,各个异构系统把自身的数据实时同步到数据中心层,同时数据中心层把所有异构系统的共享数据实时同步到各个异构子系统中,实现共享数据的双向同步。
(8) 协调控制管理系统平台层。
包括实时数据的展示、异构系统的组合应用、基于GIS(Geographic Information System)的Web组态、报表的定制。异构系统的组合应用是指对集成模型采集的数据进行综合分析,构建新的业务流程,如瓦斯抽采子系统、人员定位子系统、广播子系统之间的联动控制等。基于GIS的Web组态是指结合GIS平台技术构建图形化的数据展现方式。报表定制是指按照客户需求自动生成报表,从而提高整个煤矿企业安全生产的自动化水平。
基于BizTalk的煤矿企业异构系统集成模型的数据流程:协调控制管理系统平台客户端请求某些数据时,调用发布的Web Services中的某个方法,将参数传递给该方法, Web Services获得需要调用的服务方法和参数,将它们发送到BizTalk,BizTalk相关端口接收到参数并送入业务流程按照一定规则进行处理,处理完后将参数送到BizTalk 的相应子系统适配器对应的端口,通过适配器将参数送到子系统的数据源中,子系统数据源根据具体业务参数返回查询结果,并将结果返回到业务流程,结果又通过Web Services返回到发出请求的客户端。
3.4 可行性验证
针对设计的基于BizTalk的煤矿企业异构系统集成模型,在川煤集团攀枝花某煤矿进行了可行性分析试验,分别对不同厂家的安全监控系统、人员定位系统和主通风机监控系统进行了异构系统的集成、特定业务的逻辑分析、消息的发布与订阅、组态展示功能的测试,在数据集成的实时性、安全性、一致性、完整性及集成模型的扩展性方面都达到了最初的设计目标及技术、性能指标,完全满足煤矿在数据集成方面的需求。
4 结语
针对煤矿企业异构系统的现状,提出了一种基于BizTalk的煤矿企业异构系统集成模型,该模型基于面向服务体系结构,对比煤矿企业现有的数据集成方式,在实时性、安全性、一致性、扩展性方面有较大优势,降低了异构系统之间的耦合度,具有一定的技术通用性,对煤矿数字化建设具有一定的参考意义。
参考文献
[1]程学先,蒋慧婷.异构数据源集成实现的研究[J].计算机工程与科学,2008,30(8):90-92.
[2]张妍,王淑蓉.基于BizTalk的SOA安全研究[J].科技信息,2009(25):455.
[3]宋璟玥.多种数据集成接口适配组件的研究[J].工矿自动化,2012,38(8):124-127.
[4]刘宇.基于BizTalk的企业应用集成研究[J].中国高新技术企业,2008(7):146.
[5]刘维.基于微软公司业务流程管理服务器中间件BizTalk Server平台的流程整合研究[J].电力信息化,2008,6(4):32-34.