基于SOA 和本体的指挥信息系统数据集成研究*

叶 霞，刘睿珩，许飞翔，岳增营

（火箭军工程大学作战保障学院，西安 710025）

0 引言

在信息化战争背景下，指挥信息系统作为作战指挥的“神经中枢”，已然成为各国部队的建设重点之一，数据作为其“血液”，更是发挥着至关重要的作用。然而，随着指挥信息系统数据需求的快速增长，各类数据资源的规模、结构、分布都发生了巨大变化。当前，由于各作战单位指挥信息系统建设的阶段性和分布性特点，这些系统的建设时间、开发人员、运行环境大都不一致，并且它们的数据源之间相互独立，因此，存在着大量冗余、异构的数据。这导致数据难以在系统之间流转、共享和融合，容易产生“信息孤岛”的现象。

为解决不同指挥信息系统数据之间存在的格式异构、空间异构、语义异构等问题，实现数据资源的高效利用。本文提出了一种基于SOA（service-oriented architecture）和本体技术的多源异构数据集成系统。通过面向SOA 的Web Service技术，对多个孤立数据源进行整合，结合本体映射方法，合并不同指标体系中具有相同语义的概念，从而构建统一的全局指标本体，为指挥员提供一个完整统一的数据视图，协助指挥中心对子单位数据资源进行管理。除此之外，通过统一底层数据源格式，系统还集中了数据模式转换和查询处理等功能，实现异构数据源的无缝链接和信息共享，为指挥员提供兼容可靠的查询功能，便于获取、集成和查看数据。因此，多源异构数据集成系统的设计实现成为了解决“信息孤岛”问题的有效手段，是实现数据一体化访问和挖掘运用的关键因素。

1 相关研究

数据集成指通过清理、映射和转换等操作，将不同来源的数据合并到单个统一视图的过程。起初的研究主要集中在联邦数据库系统上，通过建立联邦模式架构，实现各个数据源之间的相互联系和独立自治，但这种架构很难实现数据源的拓展。随着数据存储能力的提升，数据仓库能较好地整合多个数据源从而实现高效查询，并得到了进一步运用，但数据仓库不能很好地处理冗余数据，导致数据实时更新困难。为了更好地解决用户与数据源之间的连接关系，一些工作在两者之间建立一个中间件层，从而为用户提供统一的数据视图和访问接口。但这种方法难以区分具有相似语义的数据，并且查询效率很大程度上依赖于中间层的设计。因此，近年来越来越多的研究集中在实体匹配和语义映射等方面，但是这些方法往往只针对结构化或者非结构化类型的单一数据。XML（extensible markup language）和本体技术的引入为异构数据集成提供了一种新思路，利用XML 在统一数据格式时的普适性以及本体技术严谨的概念结构和逻辑推理等特性，进一步提升了数据集成的效果。本文以Web Service 体系为框架并结合本体技术，针对指挥信息系统数据在空间、结构和语义上的差异，设计实现了一个多源异构数据集成系统。

1.1 SOA 和Web Service 概述

SOA 即面向服务架构，它是一种软件架构设计的模型和方法论，将应用程序的不同功能单元通过这些服务之间定义良好的接口和契约联系起来。SOA 的提出是在企业计算领域，就是要将紧耦合的系统，划分为面向业务的，粗粒度，松耦合，无状态的服务。在SOA 的技术框架下，可以把杂乱无章的庞大系统整合成一个全面有序的系统，从而增加企业在业务发展过程中应用系统的灵活性，解决异构系统之间通信问题，实现最大的网络资产利用率。

Web Service 作为一个新型的分布式计算模型，是实现SOA 这一理念的推荐标准，它由3 个部分组成，分别为服务提供者、服务请求者和服务代理，通过发布、查找和绑定实现信息的传输。Web Service的关键技术包括XML、SOAP、WSDL 和UDDI。

XML 是指可扩展标记语言，是Web Service 的技术基础，WebService 中各种信息的描述都是基于XML。

SOAP（simple object access protoco1）是指简单对象访问协议，是基于XML 在分散或分布式的环境中交换信息的简单的协议。允许服务提供者和服务请求者经过防火墙在Internet 进行通讯交互。

WSDL（web service description language）是指网络服务描述语言，也是基于XML 语言的，用于描述WebService 以及如何对它们进行访问。

UDDI（universal description，discovery and integration）是指通用描述、发现与集成服务，用来创建Web 服务注册中心，它是Web 服务注册和发现的技术规范。UDDI 是一个独立于平台的框架，用于通过使用Internet 来描述服务，发现企业，并对企业服务进行集成。

Web Service 三角形的设计模型被称作SOA的体系结构，Web Service 模型如下页图1 所示。

图1 Web Service 模型图

一个完整的Web Service 体系结构的实现过程如图2 所示。

图2 Web Service 体系结构实现过程图

Step 1：客户查询服务中介以请求特定的服务；

Step 2：服务注册中心引导客户找到满足请求的服务WSDL 文档；

Step 3：服务请求者访问WSDL 文档；

Step 4：WSDL 提供服务的具体描述信息；

Step 5：客户根据WSDL 生成相应的SOAP 消息，发送给Web 服务提供者；

Step 6：服务提供者应答SOAP 消息，提供给请求者相应的服务。

1.2 本体技术

随着语义网技术的不断发展成熟，异构数据集成的重点慢慢地转移到解决语义异构的问题上，而目前本体技术利用对语义很好地描述能力，可以很好地解决数据的语义异构问题，Ehrig M 等在文献［17］中介绍了本体集成的问题在欧洲委员会启动的SWAP（semantic web and peer-to-peer）项目中首次被提出，该项目有着在每个终端建立各自的本体之后建立一个集成大本体的需求，因此，提出了本体映射和本体合并的概念，本体技术的运用消除了数据集成过程中的语义异构问题，并最终实现语义融合的目的。

本体概念的发展使得本体模型也在不断地进行完善，最终得到公认的一套本体模型：O={C，R，F，A，I}。

1）C 代表类（Class）：是从本体中提取出用以表述事物对象的集合，描述领域内的实际概念，既可以是实际存在的事物，也可以是抽象的概念，比如逻辑推理、动作、策略和工作过程等；

2）R 代表关系（Relations）：用于描述类（概念）之间的关系，表示了领域内的概念与概念之间的相互影响力，如part-of、kind-of 等；

3）F 代表函数（Function）：函数是一类特殊的关系，可以理解为关系的一个特例，在这种关系中前n-1 个元素可以唯一决定第n 个元素；

4）A 代表公理（Axioms）：公理代表本体内存在的事实，多用来表示对概念或者实例的约束；

5）I 代表实例（Instances）：表示具体某个类的实际存在，从语义方面讲实例代表的就是具体对象。

为解决指挥信息系统数据目前存在的空间异构、格式异构以及语义异构等问题，本文提出使用本体技术和基于SOA 的Web Service 技术实现多源异构数据集成的方法，设计并实现了多源异构数据集成原型系统。

2 基于Web Service 和本体的多源异构数据集成原型系统设计

2.1 需求分析

不同的作战单位在地理位置分布上十分的分散，而且每个单位指挥信息系统存储数据的格式不尽相同，不利于进行联合作战指挥，难以提高部队战斗力。因此，考虑将各个单位的数据集成起来，进行统一查询，并将集成后的数据以二维数据表的形式输出，可以很好地了解相应系统的作战水平。

多源异构数据集成原型系统是服务于基层作战单位以及指挥中心的。该系统使用Web Service 技术进行数据传输，利用XML 技术和本体技术实现数据集成查询，提供给指挥员数据集成分析的功能，为各级指战员高效完成作战提供坚实的基础，是信息化战争中不可或缺的一环。

多源异构数据集成原型系统的主要参与者可以分为两类：指挥中心技术员作为指挥中心用户完成数据集成查询等操作；各个子单位技术员作为子单位用户完成数据采集处理等操作。具体的系统用户及其功能性需求如表1 所示。

表1 系统用户功能性需求

2.2 系统功能设计

在充分调研了现有的指挥信息系统数据管理现状后，结合用户的需求，将系统划分为各作战单位使用的客户端以及指挥中心使用的服务端。完整的系统功能设计如图3 所示。

图3 系统功能设计图

2.2.1 客户端主要功能

1）本地数据管理

各作战单位是数据的来源，对数据的管理尤为重要，直接关乎到后续数据集成效果的优劣，用户需要通过此功能对本地的数据进行管理，不论是非结构化的文本数据还是结构化的数据库数据，都可以进行增删查改等操作。

2）数据清洗及转换

规范的数据可以减少服务端进行集成所花费的时间，所以在客户端需要实现数据的清洗及格式的转换。数据的清洗主要针对数据中出现的重复、缺失、不合理值的情况进行处理，从而得到规范的数据，方便后续的处理。由于在数据传输中采用Web Service 技术，可扩展的标记语言XML 作为Web Service 平台表示数据的基本格式，除了易于建立和易于分析外，其主要的优点在于它可以不受平台和所使用软件的影响。因此，考虑将数据格式全部统一成XML 格式的文件，以便于后续的数据传输和集成。

3）上传数据

各个单位的客户端在处理好数据后，需要将数据上传至指挥中心的服务端，此过程中通过Web Service 技术与服务端进行通信，同时进行数据的传输，从而将各个作战单位的数据全都集中到指挥中心的服务端上，这是解决数据空间异构的重要步骤。

4）系统设置

系统在实现主要功能时，还应具备一些基础功能。如语言选择、时间调整、界面外观设置、用户名和密码修改等通用设置，提供更好地用户体验。

2.2.2 服务端主要功能

1）用户管理

用户管理主要针对服务端和客户端用户，对登录到系统的用户权限进行管理。为了充分考虑各个单位数据源的安全性，因此，可以将每个客户端看作一个数据源，同时对用户和数据源进行相应的绑定。

2）数据管理

数据管理功能主要实现对各单位上传的XML数据的管理，接收到各单位的数据后，可以进行增删查改等操作。服务端还需对客户端清洗过的数据进行检查，如果数据依旧存在有重复、缺失、不合理值等情况，需要再次进行清洗修正。

3）数据集成

数据集成的功能主要利用本体集成相关技术，具体包括本体的构建、本体概念相似度的计算以及本体的映射，最终将各个单位的数据集成到一个全局本体中，这也是整个系统的关键技术。在相似度计算和本体映射中可以引入机器学习算法，提高计算精度和映射准确性。通过本体集成技术实现各个单位数据的高效集成，并存储于服务端的数据库中。

4）集成结果查询

集成结果查询为用户提供了一个人性化查询接口。将各个单位的数据集成到一起后，可实现用户的按需查询，例如，当用户有查看某单位或某一天数据的需求时，可以通过系统搜索框输入需要查询的单位编号、日期、指标名称等关键字，就可以在数据库中查找相应的信息，后台经过一些查询内容的查询转换、最终向用户呈现查询结果。

5）辅助功能

辅助功能主要是保证管理员可以在服务端完成数据和代码的维护。系统将重要的指标名称进行标记，当有新的指标名称出现时，进行相似度计算，实时更新本体概念库，数据维护对于系统的运行十分重要，也是保证本体集成效果的重要措施。代码维护功能可以保证系统正常的调试运行。

6）系统设置

同客户端一样，服务端也具备系统的基础设置功能。

2.3 系统体系结构设计

本文在数据结构和相应算法的基础上进行系统体系结构设计和开发，如下页图4 所示。系统采用基于SOA 的3 层B/S 结构，其中包含应用层、中间层和信息源层。应用层主要表现为网页端系统，直接面向管理员和用户；信息源层主要包含异构数据源，首先进行数据的清洗，然后将数据转换为XML 格式；中间层主要完成基于Web Service 的数据安全传输、接口的管理以及基于本体的数据集成相关工作。系统的体系结构设计如图4 所示。

图4 系统体系结构设计图

2.3.1 应用层

应用层处于多源异构数据集成原型系统的信息源层和中间层之上，主要是服务于系统框架中的信息的用户和管理者，在本系统中以网页的形式展现，为客户端用户和服务端管理员进行数据的传输、处理、集成、查询提供用户界面。用户和管理员只需在网页上选择需要进行的操作或者查询需要查找的信息，浏览器便可以接受用户的请求并进行解析，将请求传至中间层进行处理，完成相应的操作。这种方法的好处在于，用户和管理员无需了解请求数据和系统数据在底层传输处理的细节，而是能够直接在网页系统上查看到中间层返回的结果，有着较好的人机交互体验。

2.3.2 中间层

中间层的主要任务是进行整个业务功能的完成。要为应用层访问该系统的用户提供功能操作和数据查看，向下需要协调各个单位的数据源，在这一层系统主要完成数据的交互、本体的构建、本体概念相似度的计算、本体的映射、集成数据查询处理、Web Service 接口的管理等功能。

2.3.3 信息源层

信息源层是整个系统的基础，本课题研究的数据是来自于各个作战单位指挥信息系统运行数据，数据源存储于不同的单位，在不改变原有信息结构的基础上，将结构化数据及非结构化文本数据转化为XML 格式后上传至服务端，在服务端将XML 文档进行处理，构造局部本体，通过本体映射实现将局部本体映射到全局本体。实现数据的集成，以满足后续的查询需求。

3 系统关键模块设计

3.1 数据格式统一模块

数据格式的异构是当前数据集成所面临的最基本问题，不同单位的指挥信息系统运行数据存储的格式不尽相同，有的以TXT、Word、Excel 或者XML 格式进行存储，有的存放在数据库中，数据库的选择也不尽相同，有Oracle、SQL Server、MySQL、Access 等，统一各单位数据的数据格式是完成数据集成的第一步。由于Web Service 和本体技术都对XML 格式有着较好的亲和力，因此，考虑以XML 作为数据的统一格式。XML 作为一种机器可读文档的规范，在数据转换领域有着广泛的应用，特别是可以根据其语义约束的特性定义XML 文件结构，以便于开发人员和解析工具处理。本文通过XML Schema 定义各类元素及其系列属性来确定XML 文档结构。在转换数据格式时，对于需要集成的数据，根据结构特点，主要将其划分为结构化和非结构化两类，并按照预先定义的XML Schema 映射文件，在客户端统一将本地数据转换为XML 格式。

3.1.1 结构化数据到XML 数据的转换

由于目前的数据库管理系统存在很多差异，不同的应用领域，数据模型不尽相同，不同的生产商也生产出不同的数据库，如Oracle、SQL Server、MySQL、Access 等。这些关系数据库到XML 的数据转换主要是通过XML Schema 直接建立与数据库的映射。

首先按照需求和XML 文件的定义，根据映射规则生成XML Schema 映射文件，Schema 定义了在数据库中检索的数据，以及最终在XML 文件中如何表示这些数据。然后利用文档对象模型（Document Object Model，DOM）来解析Schema 文件，根据映射的定义，将获得的数据库结果集转化为目标XML文档。

3.1.2 非结构化文本数据到XML 数据的转换

非结构化文本数据主要是以TXT、Word、Excel这些类型存储的数据。其中，TXT 文本数据可以通过java.io 流来进行输入和输出，完成对TXT 文本的读取，并将其中的文件结构和文件内容取出，按照XML Schema 预设的格式写入到同名的XML 文档中，最终实现TXT 文档到XML 文档的转换；Word文档的转换可以通过Jacob（Java-COM Bridge）技术对Word 文档内容进行读取，Jacob 在Java 与微软COM 组件之间建立桥梁，通过JNI 功能访问Windows 平台的COM 组件或win32 系统库，完成读取后按照XML Schema 预设格式生成同名XML 文档；Excel 文档到XML 文档的转换可以通过Java Excel API 实现，该组件可以对Excel 文档进行读取、创建和更新。因此，使用Java Excel API 读取Excel 文档中所有单元格的内容及格式，并按照同样的方法写入到同名XML 文档。

3.2 数据传输模块

结合各级指挥单元之间在空间分布上“散”和“远”的特点，依托指挥信息系统信息通信支撑网和其他共用信息基础设施，数据交互模块主要解决指挥信息系统在数据集成时所面临的空间异构问题，以实现客户端与服务端之间的数据交互，这里的数据不仅指系统数据，还包括请求和响应数据。

首先为每个数据源创建相应的Web Service 接口，然后各子单位可根据指挥中心发布的WSDL 文档并通过SOAP 协议上传数据。在本系统中，服务端作为服务提供者进行Web Service 接口的开发，而各单位的客户端系统作为服务的请求者，根据服务端的WSDL 文件配置交互的参数，并以SOAP 消息的形式封装XML 数据，交互的参数、文档以及返回值都采用XML 格式。客户端与服务端进行通信时的数据交互流程如图5 所示。

图5 客户端和服务端数据传输流程图

3.3 本体构建模块

在指挥信息系统中，由于不同单位建立的指标体系存在差异，相同的概念经常以不同的指标描述，容易引起语义异构问题。本体的构建是利用本体技术进行数据集成的重要基础，本系统将各单位上传的XML 文档转换为局部本体的形式，具体的构建流程如图6 所示。通过本体映射对具有相同语义的指标概念进行合并，从而实现指挥信息系统数据的集成和共享。

图6 本体构建示意图

首先将各个单位上传的XML 文档，使用XML Schema 进行描述，接着将XML Schema 转换成为RDF Schema 模式，然后将RDF 相关文件导入到protégé 中，完成局部本体OWL 的构建，最后将构建好的OWL 本体文件导入到服务端系统。

为增强与指挥信息系统领域与本体概念之间的相关性，在转换成本体概念后，还需进一步地筛选，保证转换后的概念可以有效表示指挥信息系统领域的相关指标，具体方法如下：

1）划定所研究领域的知识范围。比如指挥信息系统通信模块相关数据的集成时，在构建本体时就要将领域知识范围限定在指挥信息新系统通信相关领域，准确分析相关概念，尽量选择认可度最高的概念作为本体构建的权威依据；

2）分析领域知识中的相关概念和所构建的本体概念之间的差异与联系。确保两者之间不出现逻辑上的混乱和原则上的差错；

3）利用语义模型检验本体概念。将所构建的本体概念在语义网中进行表示，确保不会出现模棱两可、表述不清的情形；

4）确保人工评价的准确性。在使用本体构建原则对所构建的本体进行人工评价时，需要做到评价准确。对补充到本体中新的本体概念，也要进行评价，以确保本体的不断完善；

5）若完成上述操作，即可确定所构建的本体，并使用本体语言表示，添加到本体概念库中。

3.4 集成结果查询模块

查询处理也是系统的重要功能，当用户需要查询一些特定条件下的数据时，比如特定的单位、特定的时间或者特定的指标数据时，系统可以及时作出反应，将用户需要的信息呈现出来。在查询的过程中，系统需要根据用户所输入的关键词与本体库中的概念进行映射匹配，在全局本体中找到该概念的本体表达，将查询命令分解为对局部本体的查询，最后将查询局部本体数据返回给用户界面。

本研究用到两种查询语言OWL-QL 和XQuery，分别对本体语言表示的概念和XML 语言形式的概念进行查询。OWL-QL 是W3C 推荐的网络本体查询语言，由查询回复和查询回复协议组成，与传统查询语言不同，在查询过程中，OWL-QL需要对OWL 知识库进行推理，且支持应答格式的设定、多知识库的选择和使用。XQuery 是一种针对于XML 的查询语言，类似于SQL、OQL 等，能够从XML 文档中抽取数据。XQuery 不仅拥有其他多种查询语言的优点，而且适用于各种类型XML 数据源的查询。系统查询处理的过程如图7 所示，具体步骤为：

图7 系统查询处理示意图

Step 1：查询生成器接收用户所发出的查询请求，将用户的查询关键词接受后送给本体管理器。查询生成器开始验证查询关键词的语法，判断所输入的关键词是否符合语法要求，符合要求时生成OWL-QL 查询语句送至本体管理器，否则提示输入的查询信息有误；

Step 2：本体管理器根据得到词语在全局本体内进行查找，当查找到全局本体里面的概念或者根据本体概念相似度计算模型得出相近的概念时，将全局本体的查询分解为对局部本体的查询，此时查询的是映射为全局本体概念前的所有相似概念，同时生成多个局部本体查询语句，本体管理器会将结果送给查询分解器；

Step 3：查询分解器接收到本体管理器的查找结果后，生成XQuery 查询语句在各局部本体对应的XML 文件中进行相关概念的查找；

Step 4：查询处理器将查询分解器最终查询到的结果以数据表的形式返回到浏览器进行解析，用户便可在网页系统上看到查询的结果。

4 验证与应用

根据多源异构数据集成原型系统需求分析、功能设计、体系结构设计和关键模块的设计，结合Web Service、本体以及XML 技术，基于java 语言，使用Eclipse IDE 开发，系统的整体展示如图8 所示。

图8 系统整体展示

本文所实现的数据集成原型系统于2019 年8月份进行了测试，测试过程中，在101 单位、102 单位、103 单位和201 单位使用IE 浏览器登录数据集成原型系统客户端，将各单位不同格式数据通过格式转换功能统一成为XML 格式的文件，通过Web Service 上传至指挥中心的服务端进行集成，服务端中使用本体集成相关功能进行语义融合和数据集成。

系统在测试中可以基本完成相应的功能，但也存在部分测试用例不通过的情况，例如出现以下问题：各级用户权限判别有误；输入错误或者无效的字段时，查询界面没有错误提示等。产生这些问题的主要原因来自于需求定义不明确、功能性错误、页面设计和需求不一致，以及开发过程中的疏忽等。经过后期的修改和调试工作，对本系统进行了再次测试，结果表明上述问题均得到了有效解决，实现了不同单位、不同格式、存在语义异构数据的集成，较好地验证了系统设计的可行性。

5 结论

本文研究了基于SOA 和本体的指挥信息系统数据集成方法和架构。将系统分为信息源层、中间层和应用层，通过Web Service 技术解决了数据集成中的数据源空间异构问题，使用XML 统一了多种格式的数据源，解决了数据集成中的格式异构问题，利用本体技术解决了数据集成中的概念语义异构问题。实现了指挥信息系统多源异构数据的有效集成，为用户提供全局视图，为数据挖掘、决策支持提供基础。同时设计实现的系统是实验性质的，距离完成大数据的集成和战场应用还有很大的差距，需要进一步改进完善。