CN103336813A - 一种基于中间件架构的物联网数据集成管理方案 - Google Patents

Abstract

本发明公开了一种基于中间件架构的物联网数据集成管理方案，该数据集成管理方案将物联网数据的采集及集成管理架构分为四层，分别是用户接口层，应用层，数据集成层和底层异构层。在物联网的大环境下，针对数据集成层，提出了物联网中数据采集的中间件架构，并详细阐述了该中间件的各个功能模块以及具体设计流程。本发明基于中间件，提出了物联网异构数据库集成管理框架，将中间件架构和集成管理框架组合在一起，可以实现物联网中数据的统一管理，很好的满足用户的需求，因此，具有一定的实际使用价值。

Description

一种基于中间件架构的物联网数据集成管理方案

技术领域

本发明涉及物联网数据管理技术应用领域，特别涉及一种基于中间件架构的物联网数据集成管理方案。 

背景技术

物联网是目前国际和国内新兴的热门技术，正在给人们的生产和生活方式带来深刻的变革。物联网在带来诸多好处的同时，也给软件乃至整个信息技术领域带来了前所未有的挑战。伴随着物联网的迅速发展，可以获取的异构数据呈现爆炸式的增长趋势，一个物联网系统中，可以包含形形色色的传感器，如交通传感器、地质传感器、气象类传感器等，其中每一类又包括诸多具体的传感器，如温湿度传感器节点（sensor）数据、RFID或者条形码阅读器数据等，而且由于节点采集的数据格式不同、语义不同、数据结构不同、功能不同等，对物联网数据采集以及集成管理提出了新的挑战性问题。 

另一方面，物联网中通常需要存储长时间的历史与当前采样数据，以满足溯源处理和统计分析的需要，而传感器节点和RFID阅读器的存储能力是相对有限的，难以满足长时间采样数据存储的要求。所以就需要将采样数据存储到数据库中，物联网中节点采集的数据可能被存入不同的数据库中，而这些异构数据库的运行环境、数据存储方式、数据模型以及访问控制策略等各不相同，导致用户不能同时查询和处理各数据库上的数据，会阻碍数据流通和信息共享。 

因此，如何设计出满足物联网信息节点的数据统一集成管理方案，以满足用户对数据量日益增长的信息访问的多样化要求，以及如何在不改变原有这些异构数据库的基础上，为用户提供一个集成、透明的访问环境，使得用户以一种统一的模式访问这些异构的数据库，已经成为阻碍物联网发展的数据处理技术难题。物联网中如何充分处理各种各样的传感器数据，以满足用户对多种异构数据的时间约束查询、群体数据查询和统计分析等操作一直是研究的重点。而本发明能够很好地解决上面的问题。 

发明内容:

本发明主要解决物联网中的数据应用存在的两个问题：针对传感器节点采集的数据，基于时间约束的实时群体数据查询；物联网中异构数据库集成管理。本发明的主要目的在于提供一种面向物联网数据采集的基于中间件架构的数据集成管理方案，重点阐述数据采集中间件的架构和工作流程以及基于代理的全局模式的异构数据集成接口，并有效合理的利用这两者来处理物联网中的数据，以达到以一种统一的模式操作数据，具有高效、方便快捷的特点。 

本发明解决其技术问题所采用的技术方案是：本发明提供了一种基于中间件架构的物联网数据集成管理方案，该方案将整个物联网数据的采集及集成管理架构分为四层体系结构，分别是用户接口层，应用层，数据集成层和底层异构层。如图1所示。 

底层异构层：该层是整个物联网各种业务平台所有数据的来源，即物联网环境中部署的各种传感器，包括温湿度传感器、RFID传感器等。 

数据集成层：该层对物联网中的所有数据进行集成处理，包括来自传感器节点的数据和存入到异构数据库中的历史数据。通过该层的处理，最终呈现给应用程序或者用一种统一的模式访问数据。 

应用层：该层主要功能是面向各类型的有不同需求的用户，是包含各种物联网业务的平台。 

用户接口层：由于应用层包含各种物联网业务，那么用户接口层就针对用户的特殊应用，展现给用户的可视化界面，是对应用层的扩展。 

综合以上四层的划分，当有新的温湿度传感器或者RFID传感器加入到物联网环境中时，首先，各种传感器节点按照一定的需求规范连入底层异构层。此时在数据集成层中的数据采集中间件负责对新添加的传感器进行注册并确认，并保存传感器的设备信息，以及对传感器数据的基于时间约束的实时群体数据查询，而基于代理的全局模式的异构数据库集成接口负责对异构数据库集成，以满足统计分析等操作。此时应用层中的物联网业务平台可以通过访问数据集成层中的实时数据库进行数据的查询和统计分析，实时数据库将存储着当前获取的实时数据或者用户最近经常访问的历史数据，如果实时数据库中没有平台所需的数据，则就可以通过数据采集中间件或者基于代理的全局模式的异构数据库集成接口访问数据。用户接口层则会根据用户的特定需求，定制出满足用户需求的物联网业务平台中的相应业务。 

随着物联网传感器采样数据管理中所面临的数据的异构性、时间敏感性、数据海量性等问题，如何对采集到的数据进行合理、有效的集成管理，以及成为物联网研究重点之一。根据以上提出的四层体系结构下，本发明对数据采集中间件和基于代理的全局模式的异构数据库集成接口进行了详细的设计和说明。 

一、物联网中数据采集的中间件架构 

该中间件架构旨在设计和实现如下的功能： 

以数据为中心的物联网数据采集系统； 

统一的异构设备的接口； 

支持高度动态变化的网络（比如，无线传感网络）； 

当有新设备接入时，最小化编码工作。 

如图2所示，为物联网中数据采集的中间件架构： 

下面对该中间件架构各个部件进行说明。 

如图2所示，该中间件架构的组件分为两个宏观层：底层支持层（Low-Level Support Layer,LLSL）和高层支持层（High-level Support Layer,HLSL）。 

1.底层支持层（LLSL） 

底层支持层（Low-Level Support Layer,LLSL）管理和运营所有物联网中的不同的传感设备。下面对该层的几个概念或部分进行说明： 

（1）XML设备描述符 

XML设备描述符是一个包含所有与硬件和软件模块交互信息的文档，是由物联网中的设备发送的信息文档。当一个XML设备描述符发送到中间件时，中间件会按照XML设备描述符中的信息，组合所有传感器节点所需要的软件处理组件。终端用户和扩展节点并不需要进行额外编写代码。 

（2）统一格式功能组件（UFFC） 

底层支持层（LLS）的主要软件模块是统一模式功能组件（the Unified Format Functionality Component,UFFC），UFFC充当一个代理，介于传感器节点和其余的物联网数据集成管理系统。借助于UFFC的统一访问接口，高层支持层的组件和传感设备直接通信，而不用去关心底层的传感设备如何具体地完成任务。 

一个UFFC就是一个Java对象，对给定的一个或者一组传感设备的功能进行抽象。中间件借助于UFFC和传感器节点进行交互。UFFC实际上实现了对传感器设备节点的抽象，可以理解为一个逻辑对象。HLSL中的LLQE（低级别查询执行器）就是利用UFFC来获取从传感器节点收集的数据。 

UFFC就是一个JAVA对象，传感器节点收集的信息可以被抽象成为UFFC属性。这些属性可以被用来检索节点的状态（例如，电池状态，内存使用情况状态等），访问采样数据（如温度、压力等），或者改变某些传感器设备上的参数（采样频率，节点参数等）。本专利根据类型的抽象值，将UFFC属性分为三类： 

●静态属性。即恒定值，描述传感器节点不可改变的特性，这些静态属性通常用来定义如设备名称，最大采样频率，固定节点的位置等。可以使用XML的设备描述符来设置这些类型的属性，静态属性在整个UFFC生命周期中都不会发生改变。 

●主动上传属性。主动上传属性是根据XML设备描述符中设定的值，由传感器节点自身进行计算和判断，只有当规定的条件满足时才上传数据到本地缓存中，UFFC从缓存中读取该属性值，而不是真正的去读取传感器节点中该属性的值。简单地说， 当有新的属性值产生或者改变时，设备主动发送一个消息到UFFC。这种方式具有较好的数据传输效率。 

●被动上传属性。被动上传属性是以按照XML设备描述符中设定的值，以一定的频率周期性地上传数据到本地缓存中，当读取该属性时，UFFC从本地缓存中返回存储的该属性值。该属性值由UFFC定期读取，而不管用户否请求该属性值。这种方式会有较大的通信代价，但是节点计算能力小。 

每一个传感器节点发送的消息和通知（例如，当一个RFID阅读器读取RFID标签）都会被UFFC截获，并转发到其他的中间件组件。图3对UFFC进行了概述，图中给出了UFFC和设备之间的交互过程。并区分了属于中间件的软件模块和开发者写入的软件模块。 

UFFC的高层接口由两种方法组成：第一个方法是getAttributeInfor()，它允许从设备上获取参数；第二个方法是setAttribueInfor()。节点发送消息，以及UFFC解码并存储到一个内置对象中（DataMessage.class）。需要注意的是，这个类是在运行时创建的，因此，适合采用java反射机制来实现该字段的访问。该解决方案具有通用性和一般性，并不依赖给定的类（如DataMessage.class）。 

同样地，setAttribueInfor()允许通过对类的操作，进行修改设备参数（如ParameterMessage.class）。Arranger用这个类为节点创建信息；相应的，节点在接收到消息后设置相应的参数。 

（3）UFFC工厂 

正如前面所介绍的，UFFC能和传感器设备进行简单的交互，隐藏了通信细节并掩饰了低层次的编程问题。为了能够真正达到即插即用、，中间件应该能够在运行期间引进新的节点,并创建UFFCs，并实例化和创建虚拟通道，这时，我们就需要一个称为UFFC工厂的中间件组件。 

为了对即插即用提供完整的支持，要求加入到系统中的传感器节点必须能够发送它自己的XML设备描述符到最近的UFFC工厂，并能在没有人为干预的情况下与其产生的UFFC进行通信。物理信道中会预留一个特定的虚拟通道用于UFFC与UFFC工厂通信。因此，一个新设备可以在预留信道上发送它的XML描述符，如果没有发送错误，一个新的UFFC将会生成。以后该传感器节点和UFFC之间通信都在该虚拟通道中执行。 

UFFC工厂创建UFFC的步骤如下： 

UFFC工厂接收XML设备描述符； 

UFFC工厂用JAXB库传输XML实体到一个Java对象。 

UFFC工厂创建一个新的UFFC派生类，并封装第二步生成的java对象。 

UFFC工厂调用java编辑器进行编译，并生成相应的类文件。 

UFFC工厂在运行时，调用java加载程序并加载UFFC。 

UFFC工厂在注册表注册一个新的UFFC。 

UFFC工厂通过虚拟通道捆绑FPC和其对应的传感器设备节点。 

（4）UFFC注册表 

另一个重要的并且和UFFC工厂非常相关的中间件组件是UFFC注册表，它主要是包含所有现存的UFFC的一个内存数据库。其主要目标是对低水平查询（LLQ）的EXECUTE IF语句的执行提供支持，在一个新的UFFC生成之后，UFFC工厂就会将其注册到UFFC注册表中。设备元数据（属性和事件，最大采样频率等）、属性值和UFFC对象的远程引用等都会被存储在UFFC注册表处。 

所有UFFCs活动的完整清单都存在于UFFC注册表中。UFFC注册表主要是用来选择列表中的传感器节点，以运行特定的查询，并检查一个尝试连接到UFFC系统的节点是否已经有对应的UFFC。 

2.高层支持层（HLSL） 

高层支持层（High-level Support,HLSL）该层实现数据的管理和查询执行服务，用来支持物联网中的终端用户和应用程序的一个接口。下面我们给出几个具体功能组件的详细说明： 

（1）查询解析器（QP） 

查询解析器（Query Parse,QP）是物联网数据集成管理系统的前端，直接与最终用户交互。该组件接收并解析文本查询，并将查询发送到QA。 

（2）查询分析器（QA） 

查询分析器（Query Analyzer,QA）负责创建高级查询执行器（HLQE）和低级别查询执行器（LLQE），如图2所示。 

（3）低级别查询（LLQ）和高级别查询（HLQ） 

物联网数据集成管理系统语言定义了两种类型的查询： 

●低级别查询（Low-level Query,LLQ）。定义单一设备的行为。 

●高级别查询（High-level Query,HLQ）。操作LLQs生成的数据流。 

高级别查询执行器（High-level Query Executor,HLQE）就像是一个外部的数据流管理系统（DBMS）的封装器（Wrapper）。它的主要目的是允许用户对从物联网网络环境中收集到数据进行操作。每个HLQ是由用户在一个专用的HLQE中执行的。 

不同于高级查询中（HLQ），低级别的查询（LLQ）需要建立一个特定的执行引擎，这个引擎被称为低级别查询执行器（LLQE）。一个低级别的查询根据如下步骤进行： 

●QA访问UFFC注册表来获取可以成功执行查询的UFFCs列表； 

●QA为每个列表中的UFFC实例化并配置一个LLQ，以执行用户提交的语句。 

●每一个LLQE和相应的UFFC交互，以从相应的物理设备中获取信息。 

LLQEs生成的所有关系到同一个子查询的记录会被结合成一个单一的数据流，并以用户发送的低级别查询的形式输出。 

二、一个基于多代理技术的全局模式的分布式数据库集成模型 

众所周知的，像CORBA，DCOM，J2EE这样传统的技术，在一定程度上，可以集成分布式系统和异构系统。然而，当系统需要彼此交互并要保持一定程度的自我管理时，上述传统技术就有一定的局限性。因为多代理具有流动性，自主性和主动性，还有其他特性，通过多代理技术，就可以很好地解决物联网平台中的信息集成的难题。 

2.1物联网中异构数据数据库集成模型 

异构数据库集成模型由四层组成的，即用户层，应用层，基于代理的全局模式的异构数据库集成接口层和底层异构层。 

底层异构层：该层是整个物联网各种业务平台所需部分数据的来源，即不同的数据库管理系统，如Oracle，SQLServer，MySQL。 

异构数据库集成接口层：该层对物联网中的存入异构数据库中的数据进行集成处理，负责访问数据库以及其它应用系统集成。。通过该层的处理，最终呈现给应用程序或者用一种统一的模式访问数据。 

应用层：该层主要功能是面向各类型的有不同需求的用户，是包含各种物联网业务的平台。处理权限管理，工作流控制等。用于衔接用户层和基于代理的全局模式的异构数据库集成接口层。 

用户接口层：由于应用层包含各种物联网业务，那么用户接口层就针对用户的特殊应用，展现给用户的可视化界面，是对应用层的扩展。这是提供给用户的界面显示和数据验证。 

由于位置透明性，分布式数据库的全局性、物理分布性和异构性等特点，完成用户提交的查询请求的第一个步是，通过物联网业务平台，将请求转换成XML文本文档并传送给基于代理的全局模式的异构数据库集成接口层。基于代理的全局模式的异构数据库集成接口的内存管理模块将接收到的XML传给XML信息解析模块，XML信息解析模块对XML文档内容进行解析并提交给协同信息管理模块，协同信息管理模块根据视图中整体的消息和数据库信息，找到异构数据库能提供的服务和数据。根据收集到的数据，划分子任务。称为协同任务管理层的这层实现任务分工和创造合作任务服务模块。合作任务服务模块完成合作任务，同时根据统一视图的实施结果，合作任务服务层发送反馈的协同任务管理，合作任务层能根 据反馈信息的决策规则，进行动态调整。例如，物理地址的变化会导致全局信息和合作的政策调整的变化。图4所示，为物联网中异构数据库集成的一般模型。图5所示，为物联网中异构数据库查询流程图。图6所示，为异构数据库集成架构图。 

2.2异构数据库集成架构 

分布式的、异构的数据源不利于深入和全面的信息处理，如预测和决策，由于网络连接问题，数据源可能有时处于脱机状态。同时，由于很多数据的数量和数据动态的改变，如果所有的数据集中存储，不仅是浪费空间，而且不符合实时数据的要求。因此，存储在数据仓库的有关历史数据，和被分布在不同的数据源的其它数据，整体构成一个虚拟数据中心。虚拟数据中心向用户提供了一个数据的统一的视图，对于用户或应用系统来说，就好像所有数据都存储在数据中心。 

物联网中异构数据库集成架构如图4所示。 

在体系结构中，分为3种类型的代理: 

●数据访问代理（Data Access Agent,DAA）：DAA负责数据源的访问，DAA由数据服务提供者创建。对于数据源中的不同的数据源或不同的数据服务，我们就可以实现不同的DAA。数据服务提供商必须描述数据的输入、输出和数据格式，以及服务的安全性要求。DAA属于数据收集代理。 

●应用程序服务代理（Application Service Agent,ASA）：ASA是负责调用应用系统的功能。所有的应用程序服务，可以使用不同的语言在不同的平台上实现。为了不影响系统，ASA可以部署在数据交换中心。ASA属于数据收集代理。本架构中的物联网业务平台是使用java编程实现的。 

集成代理(Integration agent)：集成代理屏蔽的应用系统和数据的物理分布之间的差异，为用户和应用系统提供透明的，统一的数据访问，本架构的集成代理使用统一虚拟视图实现。有益效果： 

1、本发明能够很好地满足用户的需求，使得数据的查询效率更高，更快捷，更简单。 

2、本发明具有很高的使用价值。 

附图说明：

图1是物联网数据采集及集成管理架构图。 

图2是物联网中数据采集中间件架构图。 

图3是统一格式功能组件（UFFC）示意图。 

图4是物联网中异构数据库集成模型图。 

图5是物联网中异构数据库的数据查询流程图。 

图6是异构数据库集成架构图。 

图7物联网业务平台开发框架图。 

具体实施方式：

以下结合说明书附图对本发明创造作进一步的详细说明。 

如图1所示，本发明提供了一种基于中间件架构的物联网数据集成管理方案，该方案将整个物联网数据的采集及集成管理架构分为四层，分别是用户接口层，应用层，数据集成层和底层异构层。 

底层异构层：该层是整个物联网各种业务平台所有数据的来源，即物联网网络环境中部署的各种传感器，包括温湿度传感器、RFID传感器等。传感器节点第一个步骤就是将自己部署在物联网环境中，传感器接入底层异构层之后，通过数据集成层向更高层提供数据支持。 

数据集成层：该层对物联网中的所有数据进行集成处理，包括来自传感器节点的数据和存入到异构数据库中的历史数据。通过该层的处理，最终呈现给应用程序或者用户一种统一的数据访问模式。该层中包括数据采集中间件、基于代理的全局模式的异构数据库集成接口，以及实时数据库。数据采集中间件是以数据为中心的物联网数据采集系统，提供一个统一的异构传感器设备的接口，支持高度动态变化的网络，并且当有新的设备接入时，最小化编码工作。基于代理的全局模式的异构数据库集成接口可以集成不同的异构数据库，为用户提供一个集成的、透明的访问环境，使得用户以一种统一的模式访问这些异构的数据库。实时数据库负责衔接数据采集中间件和基于代理的全局模式的异构数据库集成接口，实时数据库负责将从数据采集中间件的传感器数据定期地传送给基于代理的全局模式的异构数据库集成接口，并存储到不同的数据库中。并且实时数据库直接与上层的应用层交互，当应用层需要查询或者操作数据时，首先在实时数据库中查找，如果没有查找到，再通过数据采集中间件或者异构数据库集成接口查找数据等操作。 

应用层：该层主要功能是面向各类型的有不同需求的用户，是包含各种物联网业务的平台。通过物联网平台中可以使用存在的各种各样的业务，如基于温湿度查询的智能家居业务，基于RFID传感器的资产管理业务等。 

用户接口层：由于应用层包含各种物联网业务，那么用户接口层就针对用户的特殊应用，展现给用户的可视化界面，通过该可视化界面，用户就可以组合自己需要的业务，该层是对应用层的扩展。 

本发明的面向物联网数据采集的基于中间件架构的数据集成管理方案位于数据集成层。该数据集成管理方案由三部分组成，分别是数据采集中间件、基于代理的全局模式的异构数据库集成接口、实时数据库。首先，就数据采集中间件架构进行说明，其次再对基于代理的 全局模式的异构数据库集成接口进行详细阐述。 

一、物联网中数据采集的中间件架构 

该中间件架构旨在设计和实现如下的功能： 

以数据为中心的物联网数据采集系统； 

统一的异构设备的接口； 

支持高度动态变化的网络（比如，无线传感网络）； 

当有新设备接入时，最小化编码工作。 

如图2所示，该中间件架构的组件分为两个宏观层：底层支持层（Low-Level Support Layer,LLSL）和高层支持层（High-level Support Layer,HLSL）。其中，底层支持层管理和运营所有物联网中的不同的传感设备； 

1.底层支持层（LLSL） 

底层支持层（Low-Level Support Layer,LLSL）管理和运营所有物联网中的不同的传感设备。下面对该层的几个概念或部分进行说明： 

（1）XML设备描述符 

XML设备描述符是一个包含所有与硬件和软件模块交互信息的文档，是由物联网中的设备发送的信息文档。当一个XML设备描述符发送到中间件时，中间件会按照XML设备描述符中的信息，组合所有传感器节点所需要的软件处理组件。终端用户和扩展节点并不需要进行额外编写代码。 

（2）统一格式功能组件（UFFC） 

底层支持层（LLSL）的主要软件模块是统一模式功能组件（the Unified Format Functionality Component,UFFC），UFFC充当一个代理，介于传感器节点和其余的物联网数据集成管理系统。借助于UFFC的统一访问接口，高层支持层的组件和传感设备直接通信，而不用去关心底层的传感设备如何具体地完成任务。 

一个UFFC就是一个Java对象，对给定的一个或者一组传感设备的功能进行抽象。中间件借助于UFFC和传感器节点进行交互。UFFC实际上实现了对传感器设备节点的抽象，可以理解为一个逻辑对象。HLSL（高层支持层）中的低级别查询执行器（LLQE）就是利用UFFC来获取从传感器节点收集的数据。 

UFFC就是一个JAVA对象，传感器节点收集的信息可以被抽象成为UFFC属性。这些属性可以被用来检索节点的状态（例如，电池状态，内存使用情况状态等），访问采样数据（如温度、压力等），或者改变某些传感器设备上的参数（采样频率，节点参数等）。本专利根据 类型的抽象值，将UFFC属性分为三类： 

●静态属性。即恒定值，描述传感器节点不可改变的特性，这些静态属性通常用来定义如设备名称，最大采样频率，固定节点的位置等。可以使用XML的设备描述符来设置这些类型的属性，静态属性在整个UFFC生命周期中都不会发生改变。 

●主动上传属性。主动上传属性是根据XML设备描述符中设定的值，由传感器节点自身进行计算和判断，只有当规定的条件满足时才上传数据到本地缓存中，UFFC从缓存中读取该属性值，而不是真正的去读取传感器节点中该属性的值。简单地说，当有新的属性值产生或者改变时，设备主动发送一个消息到UFFC。这种方式具有较好的数据传输效率。 

●被动上传属性。被动上传属性是以按照XML设备描述符中设定的值，以一定的频率周期性地上传数据到本地缓存中，当读取该属性时，UFFC从本地缓存中返回存储的该属性值。该属性值由UFFC定期读取，而不管用户否请求该属性值。这种方式会有较大的通信代价，但是节点计算能力小。 

每一个传感器节点发送的消息和通知（例如，当一个RFID阅读器读取RFID标签）都会被UFFC截获，并转发到其他的中间件组件。图3对UFFC进行了概述，图中给出了UFFC和设备之间的交互过程。并区分了属于中间件的软件模块和开发者写入的软件模块。 

UFFC的高层接口由两种方法组成：第一个方法是getAttributeInfor()，它允许从设备上获取参数；第二个方法是setAttribueInfor()。节点发送消息，以及UFFC解码并存储到一个内置对象中（DataMessage.class）。需要注意的是，这个类是在运行时创建的，因此，适合采用java反射机制来实现该字段的访问。该解决方案具有通用性和一般性，并不依赖给定的类（如DataMessage.class）。 

同样地，setAttribueInfor()允许通过对类的操作，进行修改设备参数（如ParameterMessage.class）。Arranger用这个类为节点创建信息；相应的，节点在接收到消息后设置相应的参数。 

（3）UFFC工厂 

正如前面所介绍的，UFFC能和传感器设备进行简单的交互，隐藏了通信细节并掩饰了低层次的编程问题。为了能够真正达到即插即用，中间件应该能够在运行期间引进新的节点,并创建UFFCs，并实例化和创建虚拟通道，这时，我们就需要一个称为UFFC工厂的中间件组件。 

为了对即插即用提供完整的支持，要求加入到系统中的传感器节点必须能够发送它自己的XML设备描述符到最近的UFFC工厂，并能在没有人为干预的情况下与其产生的UFFC 进行通信。物理信道中会预留一个特定的虚拟通道用于UFFC与UFFC工厂通信。因此，一个新设备可以在预留信道上发送它的XML描述符，如果没有发送错误，一个新的UFFC将会生成。以后该传感器节点和UFFC之间通信都在该虚拟通道中执行。 

UFFC工厂创建UFFC的步骤如下： 

UFFC工厂接收XML设备描述符； 

UFFC工厂用JAXB库传输XML实体到一个Java对象。 

UFFC工厂创建一个新的UFFC派生类，并封装第二步生成的java对象。 

UFFC工厂调用java编辑器进行编译，并生成相应的类文件。 

UFFC工厂在运行时，调用java加载程序并加载UFFC，。 

UFFC工厂在注册表注册一个新的UFFC。 

UFFC工厂通过虚拟通道捆绑FPC和其对应的传感器设备节点。 

（4）UFFC注册表 

另一个重要的并且和UFFC工厂非常相关的中间件组件是UFFC注册表，它主要是包含所有现存的UFFC的一个内存数据库。其主要目标是对低水平查询（LLQ）的EXECUTE IF语句的执行提供支持，在一个新的UFFC生成之后，UFFC工厂就会将其注册到UFFC注册表中。设备元数据（属性和事件，最大采样频率等）、属性值和UFFC对象的远程引用等都会被存储在UFFC注册表处。 

所有UFFCs活动的完整清单都存在于UFFC注册表中。UFFC注册表主要是用来选择列表中的传感器节点，以运行特定的查询，并检查一个尝试连接到UFFC系统的节点是否已经有对应的UFFC。 

2.高层支持层（HLSL） 

高层支持层（High-level Support,HLSL）该层实现数据的管理和查询执行服务，用来支持物联网中的终端用户和应用程序的一个接口。下面我们给出几个具体功能组件的详细说明： 

（1）查询解析器（QP） 

查询解析器（Query Parse,QP）是物联网数据集成管理系统的前端，直接与最终用户交互。该组件接收并解析文本查询，并将查询发送到QA。 

（2）查询分析器（QA） 

查询分析器（Query Analyzer,QA）负责创建高级查询执行器（HLQE）和低级别查询执行器（LLQE），如图2所示。 

（3）低级别查询（LLQ）和高级别查询（HLQ） 

物联网数据集成管理系统语言定义了两种类型的查询： 

●低级别查询（Low-level Query,LLQ）。定义单一设备的行为。 

●高级别查询（High-level Query,HLQ）。操作LLQs生成的数据流。 

高级别查询执行器（High-level Query Executor,HLQE）就像是一个外部的数据流管理系统（DBMS）的封装器（Wrapper）。它的主要目的是允许用户对从物联网网络环境中收集到数据进行操作。每个HLQ是由用户在一个专用的HLQE中执行的。 

不同于高级查询中（HLQ），低级别的查询（LLQ）需要建立一个特定的执行引擎，这个引擎被称为低级别查询执行器（LLQE）。一个低级别的查询根据如下步骤进行： 

●QA访问UFFC注册表来获取可以成功执行查询的UFFCs列表； 

●QA为每个列表中的UFFC实例化并配置一个LLQ，以执行用户提交的语句。 

●每一个LLQE和相应的UFFC交互，以从相应的物理设备中获取信息。 

LLQEs生成的所有关系到同一个子查询的记录会被结合成一个单一的数据流，并以用户发送的低级别查询的形式输出。 

二、一个基于多代理技术的全局模式的分布式数据库集成模型 

众所周知的，像CORBA，DCOM，J2EE这样传统的技术，在一定程度上，可以集成分布式系统和异构系统。然而，当系统需要彼此交互并要保持一定程度的自我管理时，上述传统技术就有一定的局限性。因为多代理具有流动性，自主性和主动性，还有其他特性，通过多代理技术，就可以很好地解决物联网平台中的信息集成的难题。 

2.1物联网中异构数据数据库集成模型 

异构数据库集成模型由四层组成的，即用户层，应用层，基于代理的全局模式的异构数据库集成接口层和底层异构层。 

底层异构层：该层是整个物联网各种业务平台所需部分数据的来源，即不同的数据库管理系统，如Oracle，SQLServer，MySQL。 

异构数据库集成接口层：该层对物联网中的存入异构数据库中的数据进行集成处理，负责访问数据库以及其它应用系统集成。。通过该层的处理，最终呈现给应用程序或者用一种统一的模式访问数据。 

应用层：该层主要功能是面向各类型的有不同需求的用户，是包含各种物联网业务的平台。处理权限管理，工作流控制等。用于衔接用户层和基于代理的全局模式的异构数据库集成接口层。 

用户接口层：由于应用层包含各种物联网业务，那么用户接口层就针对用户的特殊应用，展现给用户的可视化界面，是对应用层的扩展。这是提供给用户的界面显示和数据验证。 

由于位置透明性，分布式数据库的全局性、物理分布性和异构性等特点，完成用户提交 的查询请求的第一个步是，通过物联网业务平台，将请求转换成XML文本文档并传送给基于代理的全局模式的异构数据库集成接口层。基于代理的全局模式的异构数据库集成接口的内存管理模块将接收到的XML传给XML信息解析模块，XML信息解析模块对XML文档内容进行解析并提交给协同信息管理模块，协同信息管理模块根据视图中整体的消息和数据库信息，找到异构数据库能提供的服务和数据。根据收集到的数据，划分子任务。称为协同任务管理层的这层实现任务分工和创造合作任务服务模块。合作任务服务模块完成合作任务，同时根据统一视图的实施结果，合作任务服务层发送反馈的协同任务管理，合作任务层能根据反馈信息的决策规则，进行动态调整。例如，物理地址的变化会导致全局信息和合作的政策调整的变化。图4所示，为物联网中异构数据库集成的一般模型。图5所示，为物联网中异构数据库查询流程图。图6所示，为异构数据库集成架构图。 

2.2异构数据库集成架构 

分布式的、异构的数据源不利于深入和全面的信息处理，如预测和决策，由于网络连接问题，数据源可能有时处于脱机状态。同时，由于很多数据的数量和数据动态的改变，如果所有的数据集中存储，不仅是浪费空间，而且不符合实时数据的要求。因此，存储在数据仓库的有关历史数据，和被分布在不同的数据源的其它数据，整体构成一个虚拟数据中心。虚拟数据中心向用户提供了一个数据的统一的视图，对于用户或应用系统来说，就好像所有数据都存储在数据中心。 

物联网中异构数据库集成架构如图4所示。 

在体系结构中，分为3种类型的代理: 

●数据访问代理（Data Access Agent,DAA）：DAA负责数据源的访问，DAA由数据服务提供者创建。对于数据源中的不同的数据源或不同的数据服务，我们就可以实现不同的DAA。数据服务提供商必须描述数据的输入、输出和数据格式，以及服务的安全性要求。DAA属于数据收集代理。 

●应用程序服务代理（Application Service Agent,ASA）：ASA是负责调用应用系统的功能。所有的应用程序服务，可以使用不同的语言在不同的平台上实现。为了不影响系统，ASA可以部署在数据交换中心。ASA属于数据收集代理。本架构中的物联网业务平台是使用java编程实现的。 

●集成代理(Integration agent)：集成代理屏蔽的应用系统和数据的物理分布之间的差异，为用户和应用系统提供透明的，统一的数据访问，本架构的集成代理使用统一虚拟视图实现。 

2.3系统开发结构 

在设计中，我们采用了多层次的结构，基于C/S。该系统在逻辑上划分成5层，表示层，控制层，业务逻辑层，集成层和服务层，如图7所示。 

每层的功能描述： 

●表示层，该层负责界面显示和数据验证。 

●控制层，该层负责处理权限管理，工作流控制等。 

●业务逻辑层，该层负责处理业务的逻辑功能。 

●集成层，该层负责访问数据库以及其它应用系统集成。 

●服务层，该层提供基本服务，如系统日志，数据高速缓存等。 

Claims (10)

1.一种基于中间件架构的物联网数据集成管理方案，其特征在于：所述数据集成管理方案分为四层，分别为：底层异构层、数据集成层、应用层、用户接口层；

所述数据集成管理方案应用于物联网数据管理技术领域。

2.根据权利要求1所述的一种基于中间件架构的物联网数据集成管理方案，其特征在于，底层异构层：该层是整个物联网各种业务平台所有数据的来源。

3.根据权利要求1所述的一种基于中间件架构的物联网数据集成管理方案，其特征在于，数据集成层：该层对物联网中的所有数据进行集成处理，包括来自传感器节点的数据和存入到异构数据库中的历史数据。

4.根据权利要求1所述的一种基于中间件架构的物联网数据集成管理方案，其特征在于，应用层：该层的功能是面向各类型的有不同需求的用户，是包含各种物联网业务的平台。

5.根据权利要求1所述的一种基于中间件架构的物联网数据集成管理方案，其特征在于，用户接口层：通过可视化界面，用户可以组合自己需要的业务，该层是对应用层的扩展。

6.根据权利要求1或3所述的一种基于中间件架构的物联网数据集成管理方案，其特征在于：基于中间件架构的数据集成管理方案位于数据集成层，该层有三部分组成：数据采集中间件、基于代理的全局模式的异构数据库集成接口、实时数据库。

7.根据权利要求6所述的一种基于中间件架构的物联网数据集成管理方案，其特征在于：该中间件架构的组件分为两个宏观层：底层支持层（Low-LevelSupport Layer,LLSL）和高层支持层（High-level Support Layer，HLSL）；其中，底层支持层管理和运营所有物联网中的不同的传感设备；底层支持层有如下组件：XML设备描述符、统一格式功能组件（UFFC）、UFFC工厂和UFFC注册表；高层支持层实现数据的管理和查询执行服务，用来支持物联网中的终端用户和应用程序的一个接口，该层包括查询解析器（Query Parser，QP）、查询分析器（Query Analyzer，QA）、低级别查询（Low-level Query,LLQ）和高级别查询（High-level Query,HLQ）。

8.根据权利要求7中所述的一种基于中间件架构的物联网数据集成管理方案，其特征在于：所述的XML设备描述符是一个包含所有与硬件和软件模块交互信息的文档，是由物联网中的设备发送的信息文档；当一个XML设备描述符发送到中间件时，中间件会按照XML设备描述符中的信息，组合所有传感器节点所需要的软件处理组件；终端用户和扩展节点并不需要进行额外编写代码。

9.根据权利要求7中所述的一种基于中间件架构的物联网数据集成管理方案，其特征在于：所述的UFFC充当一个代理，介于传感器节点和其余的物联网数据集成管理系统；一个UFFC就是一个Java对象，对给定的一个或者一组传感设备的功能进行抽象；中间件借助于UFFC和传感器节点进行交互；UFFC属性分为三类：静态属性、主动上传属性和被动上传属性；UFFC工厂能够在运行期间引进新的节点并创建UFFCs，并实例化和创建虚拟通道，以实现即插即用；UFFC注册表是包含所有现存的UFFC的一个内存数据库；QP是物联网数据集成管理系统的前端，直接与最终用户交互，该组件接收并解析文本查询，并将查询发送到QA；查询分析器（Query Analyzer）负责创建高级查询执行器（HLQE）和低级别查询执行器（LLQE）；低级别查询（LLQ）定义单一设备的行为；高级别查询（HLQ）操作LLQs生成的数据流；高级别查询执行器（High-level QueryExecutor,HLQE）就像是一个外部的数据流管理系统（DBMS）的封装器（Wrapper）。

10.根据权利要求6所述的一种基于中间件架构的物联网数据集成管理方案，其特征在于：所述的基于代理的全局模式的异构数据库集成接口位于该集成模型的异构数据库集成接口层，其由数据访问代理（Data Access Agent,DAA）、应用程序服务代理（Application Service Agent,ASA）和集成代理(Integration agent)组成；基于代理的全局模式的异构数据库集成模型由四层组成的：用户层，应用层，异构数据库集成接口层和底层异构层。

Images