前兆数据管理系统中设备资源统一管理

庞晶源，李雪梅，王 楠，李承雪

（吉林省地震局，长春 130117）

0 引言

中国地震前兆台网系统建设主要用于满足地震行业内设备与数据资源共享、互联互通、协同工作的需求。由于地震行业中设备资源具有异构性、分布性与自治性等特点［1］，因此在前兆数据管理系统建设过程中迫切需要一个有效的统一设备资源管理机制，以满足设备资源共享和协同工作的需求，从而建立完善的面向地震行业特点的管理平台。

目前已经开展了大量针对设备资源管理系统的研究［2－4］，但是这些研究主要集中在设备静态信息的管理，即设备的基本信息和静态业务数据的统计管理上，而对设备的运行状态、设备业务功能的实现方式、动态业务数据的综合处理等各种动态信息的深层管理研究较少，更无法满足对设备实现远程监视、控制的需求。而在当前的地震行业内部更缺乏有效统一的设备管理手段，因此急需一种新的设备管理系统来满足人们对设备管理日益增长的需求。为此，本文对前兆数据管理系统中的设备资源管理系统进行了深入研究。

1 需求分析

1.1 设备资源特点

除了具备价值含量大、技术含量高、更新速度快等一般性特点以外，前兆数据管理系统中的设备资源还具有以下特点：

（1）自治性：前兆数据管理系统的设备资源的管理权限完全在于各个省、区域的地震局和地震台站，每个所有者独立自主的管理自己的资源，随时可能撤销对自己资源的共享。

（2）异构性：在实际环境中，设备资源响应命令的性能不一致，返回的数据格式不一致，设备所在的网络条件状况不一致，设备层接入系统的时间和空间也具有不一致性。

（3）海量数据：每天的全国数据量可达到3GB。

（4）远程监控：整个国家地震数字台网的拓扑是四层的超树结构，即父节点可以访问非直接子节点。设备资源处于最底层，对于各个节点来说，需要进行远程的控制访问。

（5）协作性：设备属于不同的学科，同一学科的设备处于不同的地理位置，需要这些设备的协作，才能完成某些业务功能。

1.2 设计目标

为满足前述的特点，前兆数据管理系统中的设备资源管理系统的主要设计目标是：

（1）将设备资源转化成为一种位置透明的统一的资源，使得用户在任何地方都可以通过网络透明地、方便地使用设备资源，而不需要知道设备资源的具体地理位置。

（2）屏蔽行业中各种不同设备的异构性，将设备资源转化成为一种标准的资源供用户使用。

2 系统框架

2.1 设备资源管理系统层次结构

为了达到上述的设计目标，设备资源管理系统被划分为4个层次：

（1）设备资源层（Resource Layer）：由多个地理上分布的设备组成，这些设备存在着不同程度的异构性。

（2）适配器层（Adapter Layer）：完成与设备资源的直接通信，通过对所发送的命令和设备返回的结果作相应的映射，将异构的设备资源，转化为统一的虚拟设备，向上层提供统一的接口，从而屏蔽了设备资源对中间件层和业务层的异构性。

（3）中间件层（Middle Layer）：负责接收从用户接口层中发送的服务调用请求，由调度器根据命令队列和结果队列返回的信息，将请求服务中的命令发送给适配器进行执行，将执行成功后的结果返回给用户接口层。

（4）业务层（Business Layer）：为用户提供相应的业务交互接口，并完成对多用户的并发访问任务，进行优化和结果的分发处理。

2.2 设备资源管理系统业务层体系结构

设备资源管理系统的业务层的体系结构如图1所示：

图1 设备资源管理系统业务层体系结构图

（1）设备资源管理系统的门户：该门户是用户与系统的接口，分为设备管理，设备监控，业务数据采集、业务数据服务和系统管理5个功能模块。本文实现了基于B／S 的门户，实现了对设备的统一管理，提高了工作人员的工作效率。

（2）处理层核心模块：主要包括元数据访问模块，并发任务管理模块等，第4 节将重点介绍该模块。

（3）数据访问层：通过中间件调用模块实现对中间件所提供的服务的调用，通过数据资源调用实现对数据资源的访问［5］。

3 业务层核心模块的设计与实现

用户通过业务层所提供的页面接口，发送相应的业务请求，业务层经过优化处理后，将任务请求以XML文件的形式发送给中间件来调用中间件所提供的服务。当中间件执行完相应的服务后，会将结果返回给业务层，业务层将结果与之前的任务请求进行映射后，对结果进行处理和分发，从而完成了用户对设备的一次业务操作。通过这种方式，使得用户可以高效、透明的对设备进行访问操作，使得系统具有扩展性，当有新的业务功能添加时，用户只需要通过业务层提供的接口，就可以完成操作。为此，业务层中主要有以下4个核心模块：元数据访问模块、并发访问管理模块、结果处理模块以及系统管理模块。

3.1 元数据访问模块

该模块的主要功能是通过对元数据库UUID的查询，实现对设备和中间件描述的查询和定位，可完成相关设备业务请求的中间件［5］。

对元数据的状态查询分为设备描述查询和中间件描述查询。对设备的元数据查询主要应用于当系统查询设备的属性时，元数据访问模块会对元数据库进行查询，将解析后的设备的元数据描述返回调用模块。

中间件描述信息的查询则用于对中间件定位使用。当用户发送任务请求时，处理层需要通过元数据访问为此任务进行中间件定位，并将选择的中间件的信息返回给并发访问管理模块，使其调用此中间件的相关服务来完成用户的请求。

3.2 并发访问管理模块

本系统具有多视图的需求，为了保证对每个用户的访问操作，系统都能够做到及时、准确的响应，并且对同时进行的相同操作，给予相同的结果，本文对多用户并发任务的分发和结果的优化进行了深入研究，主要分为3个过程：任务解析、任务优化和任务分发。

3.2.1 任务解析

任务解析子模块所完成的主要功能是解析用户通过网页传输过来的命令请求，根据其中的信息解析出请求业务和执行的设备［6］，为用户所请求的任务注册，并将其注册ID 返回。其工作流程如图2所示：

图2 任务解析模块

任务解析模块接收从网页上传输过来的任务命令，首先对任务命令进行验证，包括语法格式验证和语义验证。其中语法验证的主要任务是验证传输过来的任务命令是否满足预先定义的命令格式；语义验证主要是完成命令语义方面的检查；最后对任务命令进行解析，从中得出所请求的服务和要执行的设备ID。

3.2.2 任务优化

任务优化子模块所完成的主要功能是对任务解析模块发送的任务请求进行任务匹配，并根据匹配结果对任务进行不同的处理，从而完成任务的优化。图3是任务优化子模块的流程图：

图3 任务优化子模块的流程图

（1）任务解析模块将经过解析的任务请求信息发送给任务匹配子模块，其任务请求信息包括设备ID，任务请求名称。如图3步骤1所示。

（2）任务匹配模块根据任务请求信息中的设备ID 和任务请求名称进行查询任务执行信息缓冲，查找是否具有相同的任务请求。任务执行信息缓冲是系统为业务层中的任务请求分配的缓冲区。其中包括已经执行完毕的任务、正在执行的任务和即将执行的任务的相关信息，包括设备ID、任务请求名称、任务执行ID 和任务执行情况。如图3步骤2、3所示。

（3）任务匹配模块将任务请求信息和匹配结果发送到任务合并模块，进行任务的优化。如图3步骤4所示。

（4）任务合并模块根据所接收的匹配结果对任务进行不同的处理。共有2种匹配结果。①如果在任务匹配中找到了相同的任务，则将此任务请求的注册ID 和任务执行ID 进行映射，并写入映射文件中，其任务请求将不会发送到命令队列中；②如果匹配的结果是没有相同的任务，则系统为此任务请求分配新的任务执行ID，同时将任务注册ID 与此任务执行ID 的映射写入映射文件中，并将此任务的相关信息写入任务执行信息缓冲，包括任务执行ID、任务请求名称、设备ID 和“待发送”的任务执行情况。如图3步骤5、6、7所示。

3.2.3 任务分发

任务分发模块的主要功能是为命令对队列中的任务请求选择适合的中间件，并根据任务调用中间件所提供的服务，达到将任务分发的目的。图4为 任务分发模块的原理图。

图4 任务分发模块原理图

（1）Runner不断的向任务命令队列请求任务请求，如果当前系统中没有任务请求需要分发，Runner线程将被阻塞，直到有新的任务请求需要被分发，否则Runner线程将从任务命令队列中取出该任务请求。

（2）MiddleChoose负责为即将分发的任务请求选择定位适合的中间件，进行服务的调用，并向XMLGenerator提供中间件的相关信息。

（3）XMlGenerator负责生成向中间件所发送的服务调用的XML文件。

（4）MiddleAccess在接收到XML 文件之后，将会派生一个新的线程来将XML 文件发送给中间件，与此同时，将任务执行信息缓冲的相应任务的任务执行情况更新为“已发送”。

3.3 结果处理模块

结果处理模块负责将中间件返回的结果数据分发给发送该任务请求的用户，同时还需要按照用户的要求对结果数据进行处理，例如有些数据需要统计入库等。图5为业务层中结果处理模块的实现结构图。

（1）Listening Threads 负责监听是否有中间件向业务层发送包含结果的XML 文件，如果监听到这样的XML 文件，则将XML 文件转发到XML Parse模块中进行解析。

（2）XML Parse将接收到的XML 文件进行解析，其解析的信息包括任务执行ID、任务名称、执行结果和相应的返回结果字符串。

图5 结果分发模块实现示意图

（3）Result Location根据任务执行ID，通过查询任务优化时生成的映射文件，将结果与任务注册ID 进行一一对应，为每个结果找到其对应的任务请求，并将对应的任务注册ID 转发给Result Send。

（4）Result Send负责结果的分发。对于直接返回浏览器的结果，则等待浏览器通过接口进行结果的传输；或者Result Send会主动的将结果进行发送，如写入数据库或数据文件。

3.4 系统管理模块

系统权限维护，采用面向对象的用户管理技术，即由用户、权限和角色3个对象构成。这里的角色是指具有明确行为准则、确定的行为方式、完成规定范围任务的实体，角色与角色之间可以有继承的关系；用户是指可以操作系统的一个拥有具体的用户名称和密码的实体对象。系统权限的分配是通过将权限赋给角色，再将角色分配给用户来实现的，权限和用户之间没有直接的联系；用户的权限是分配给用户的所拥有角色的所有权限的总和。

根据设备资源管理的功能需要，主要划分了如下角色：超级用户角色、设备管理员角色、监控管理角色、业务管理角色、维修管理角色、数据管理角色。

4 设备资源统一管理模型应用及性能测试

目前，我们提出的设备资源统一管理模型已经被成功的应用到了中国地震前兆台网数据管理系统中，该系统界面如图6所示。

为了验证我们提出的设备资源统一管理模型，我们对其进行了性能测验。设备资源统一管理系统的实际运行环境十分复杂，但也可以通过下述参数来大致描述：请求频率12～15个／小时，处理请求频率20～40个／分，设备通道数目1～2个。下面是在实际项目中使用的对于中间件性能的测试用例和测试结果。

表1 设备资源统一管理系统性能测试用例和测试结果

在上述的系统性能测试中，通过模拟实际系统运行环境，多用户频繁进行业务功能操作，系统的性能没有下降，证明设备资源管理系统能够满足一定规模的多用户请求的并发任务处理和结果处理的能力。

本系统已经在全国进行部署和运行，在实际运行环境中得到了更加全面和严格的测试，根据运行情况的反馈，该系统运行稳定，各功能均可正常使用和工作。

5 结论

为了满足设备资源共享和协同工作的需求，本文对前兆数据管理系统中的设备资源管理方法进行了深入的研究。首先，根据前兆数据管理系统中设备的实际特点，分析了系统的各项业务需求，提出了符合地震行业应用特点的设备资源管理系统模型。其次，针对地震台网中设备的异构性，对系统中的信息进行了抽象和统一的描述，将设备资源转化成为一种统一的标准资源，屏蔽各设备之间的差异，使系统具有可扩展性。最后，实现了多用户并发任务的优化和结果数据分发处理，从而提高了系统的性能。测试结果表明，本文提出的设备资源管理系统模型在安全性、功能以及性能等方面均已经达到预期目标。

［1］ 杨永强，马世龙，靳文.一种保持数据完整性的数据集成机制的探讨［J］.北京航空航天大学学报，2008（09）：1045－1047.

［2］ 刘胜国，高景春，陈智勇.基于ActiveMQ 平台的地震消息服务探讨［J］.华北地震科学，2012，30（2）：39－42.

［3］ 曲利，董晓娜，胡旭辉，等.浅谈山东"十五"地震前兆仪器的运行维护［J］.华北地震科学，2012，30（2）：56－59.

［4］ 刘胜国，高景春.EQIMProcess2.3版技术原理与实现方法［J］.华北地震科学，2012，30（4）：53－56.

［5］ 张云勇，张智江，刘锦德，等.中间件技术原理与应用［M］.北京：清华大学出版社，2005.

［6］ Thomas ERL.Service–Oriented Architecture Concepts.Technology and Design［M］.王满红，陈荣华，译.北京：机械工业出版社，2007：22.