云协同中作战资源两阶段虚拟化方法

孙海洋, 张 安, 高 飞

(1. 西北工业大学电子信息学院, 陕西 西安 710129;2. 西北工业大学航空学院, 陕西 西安 710072)

0 引 言

随着云计算、Web服务和面向服务架构的快速发展,军事领域出现了一种网络化作战的新模式——云协同。云协同立足于解决网络中心战发展过程中的两个问题——资源整合问题和服务模式问题,它将作战资源以云服务的形式进行虚拟化,构成一个庞大的资源池,使得所有资源不仅可以“分散资源集中使用”,还能做到“集中资源分散服务”[1]。

由于作战资源具有分布性和异构性,控制方式、数据格式等均相互独立,难以实现它们的共享。为了对作战资源进行集成,实现资源共享,须将它们以统一的形式虚拟化为可发现、可组合、可调用的云服务,并采用面向服务的架构,将作战资源按需动态分配给使用者。因此,作战资源的虚拟化是云服务组合、搜索和执行的前提。

目前,关于云协同中作战资源的虚拟化方法研究较少。文献[2]提出了一种基于模板的作战资源虚拟化方法,设计了作战资源适配器,将云服务的接口分为部署接口、管理接口和监听接口,所提出的作战资源云服务模板包括作战资源描述模板和作战资源实现模板。该虚拟化方法更加侧重于对作战资源属性的封装,而忽略了作战资源协同方式的封装,虽易于云协同中心管理云服务,但不易于组合云服务内各原子云服务间的协同作战。

目前,相关学者在云制造中关于制造资源的虚拟化方法研究较多。文献[3]提出了云制造资源虚拟化框架并对其关键技术进行了研究。文献[4]提出了一种基于物联网和云计算技术的服务封装和虚拟接入模型,在此基础上设计了传感器管理、实时感知制造信息、服务封装、注册和发布等方法。文献[5]提出了一种制造设备资源封装方法,通过对资源进行分类和形式化描述,并构建虚拟化类模板,来完成对制造设备资源的封装。文献[6]提出了一种针对制造资源和能力进行封装的方法,包括制造资源建模和制造云服务虚拟化两个阶段。

然而,云制造中的虚拟化技术不能直接应用于云协同中。云制造侧重于发现和使用异构的制造资源,对各制造资源间的协同要求不高;而在云协同中,作战任务的完成与作战资源间的协作密不可分,因此作战资源的虚拟化不仅要包含资源的属性封装,更要对作战资源的协同方式进行封装。

本文在云制造虚拟化相关技术的基础上,提出了基于接口和事件驱动架构的作战资源虚拟化方法,实现了云服务间的高效协同,并给出了服务的组合方法和执行方法。

1 作战资源虚拟化过程

作战资源在云协同系统中以3种形式存在:物理资源、虚拟资源和云服务。物理资源是作战资源最直接的表现形式,是对作战资源可实现的功能和实现这些功能的途径的直接体现;虚拟资源代表作战资源的能力,是对作战资源能力和接口的封装,它屏蔽了作战资源的异构性,将其访问接口、可生产的事件和可消费的事件暴露出来,使外部可访问;云服务是对虚拟资源的服务化的结果,定义了作战资源的网络服务描述语言(web services description language,WSDL)文件,可在云协同资源池进行注册,可以与其他云服务进行组合并接受服务使用者的服务请求等。

本文设计了如图1所示的作战资源虚拟化框架,该虚拟化框架包括3个层次,即物理资源层、虚拟描述层和服务封装层。这3个层次分别对应于云协同中作战资源存在的3种形式。

图1 作战资源虚拟化框架Fig.1 Framework of virtualization of combat resource

虚拟化是指对作战资源的能力进行封装,并通过一定方法,将该能力发布、注册于云协同资源池,并可为服务使用者调用[7]的过程,如图2所示。

图2 资源、虚拟资源、云服务Fig.2 Resource, virtual resource and cloud service

作战资源的虚拟化主要包含两个步骤:第一,对作战资源进行功能化封装,从作战资源的能力出发,抽象出其能提供的接口、生产的事件和提供的数据流;第二,对作战资源模型进行服务化封装,利用服务适配器,将作战资源的属性、接口、事件和数据流等信息以WSDL协议进行描述,并以统一描述、发现与集成(universal description, discovery and integration,UDDI)协议在云协同资源池进行注册,并对云服务的执行提供支持。

1.1 功能化封装

作战资源的功能化封装是服务提供者使用计算机可读的语言对作战资源进行抽象和描述,它屏蔽了作战资源的异构性,使作战资源可对外将提供的能力暴露出来,是服务化封装与发布的基础。

从封装的内容来说,在云协同系统中,功能化封装包括作战资源属性的封装和协同方式的封装。作战资源属性的封装是对作战资源能力的描述,包括静态属性、动态属性和使用属性,可利用作战资源云服务模板来定义不同种类的作战资源[1];协同方式的封装是指对作战资源与其他作战资源协同执行任务的方式的封装。服务之间的协同通过信息交互实现,信息交互按照类型分为远程调用、事件通知和数据流。远程调用通过接口实现,即作战资源间通过明确地相互调用,实现协同;事件通知通过事件驱动架构实现[2],云服务间通过生产和消费事件实现协同,它们之间不必明确地调用,耦合性低于接口;数据流通过建立数据流通道实现,适用于云服务间的长连接协同。因此,对协同方式的封装需要包含对调用接口、事件和数据流的封装。

具体来说,功能化封装主要指对作战资源如下信息进行封装:

(1) 作战资源能力属性信息。服务提供者对作战资源的能力进行描述,包括静态属性、动态属性、使用属性和部署属性。表示为p={Type,StaticPro,DynamicPro,UsingPro,DeploymentInfo}[1]。

(2) 作战资源可提供的接口。接口是对作战资源功能的封装,明确了资源提供的能力,并明确了访问方式。作战资源按照功能划分可封装为若干个接口,每个接口由若干个操作方法组成,每个操作方法均包含若干输入参数和输出参数。接口可表示为int={intName,method1,method2,…,methodn},其中,methodi为接口提供的操作方法,表示为methodi={methodName,inPars,outPars},其中,inPars表示操作方法的输入参数,outPars为输出参数。

(3) 作战资源可生产和可消费的事件。已有学者将面向服务的架构与事件驱动架构进行了组合[8],因此本文提出将事件驱动架构(event driven architecture, EDA)引入云协同来实现云服务间的协同。在作战活动中,作战资源可以探测到外部的一些事件(如发现目标或敌方有所行动等),而该作战资源本身无法对这些事件进行处理(如雷达站无法自行对目标实行攻击)。此时,作战资源便可将这些事件发送给其他作战资源,并由其他作战资源处理。因此对作战资源关于事件的封装包括两个部分,即作战资源可生产的事件和作战资源可消费的事件。

事件由事件名称和一组包含属性名和属性值的键值对组成,可以表示为e={eventName,〈a1,v1〉,〈a2,v2〉,…,〈an,vn〉},其中,eventName表示事件名称,ai表示属性名,vi表示属性值。如感知资源可产生的发现目标的事件可由{evTargetDetected,〈id,43 409〉,〈longitude,122.533 256〉,〈latitude,32.653 295〉,〈velocity,40 m/s〉}表示。

(4) 作战资源可产生和消费的数据流。作战资源间的远程调用和事件是短连接,对于需要长连接的服务请求(如视频、音频信息)可用数据流表示。由于数据流格式多样,甚至是二进制数据,故无法将这些数据以统一格式进行封装。因此,本文以数据格式作为数据的描述信息来对数据的异构性进行区分。作战资源可生产和消费的数据表示为:ds={dsName,dsCatagory,dsFormat,dsProperty}。其中,dsName为数据名,dsCatagory为数据种类,dsFormat为数据格式,dsProperty为数据的品质属性。

接口、事件和数据流都是对协同方式的封装,但它们的应用场景是不同的。

接口调用是一种远程调用方式,调用方需显式地调用被调用方中接口的某一具体操作,须指定调用接口统一资源定位符(uniform resource location,URL)地址和操作方法名称,并对必要的参数进行赋值。接口调用可心是单向的,也可以是双向的。接口调用是一对一的调用,若对多个云服务的相同接口进行调用须分别调用。接口调用方式适用于云服务间联系密切,调用方式相对固定的情形。

相比于接口,事件的生产者不知道事件消费者对事件具体的处理方法。当事件发生时,事件生产者生产事件,并由事件路由将该事件向订阅过该事件的消费者进行投送,而各事件消费者接收到事件后分别采取行动。基于事件驱动的协同是一对多的协同,即事件生产者可同时向多个事件消费者投送事件。适用于作战资源间耦合性较低,没有直接调用关系的情形。基于接口与基于事件驱动架构的区别如表1所示,运行方式如图3所示。

表1 接口与事件驱动的比较

图3 操作方法和事件在使用上的区别Fig.3 Difference between usage of operation and event

操作和事件属于短连接,适用于短时协同,而数据流属于长连接,适用于云服务间的长时交互。

以对某雷达资源建模为例,说明了功能化封装的过程。该雷达资源的能力包含两个功能类,即控制功能类(请求雷达进行特定区域搜索或对目标进行跟踪)和访问功能类(请求特定目标方位、距离和高度信息[9]);除此之外,雷达还能在搜索到目标时通知需求者。因此,可将雷达封装为两个接口(IControl和IObjectInfo)和一个事件(evTargetDetected事件),如图4所示。

图4 雷达资源的封装Fig.4 Encapsulation of radar resource

1.2 服务化封装

当前大量遗留作战资源在建设之初未考虑到作战资源的集成,因此形成了各自独立、无法互联互通的局面,对这些资源直接进行服务化改造必然成本巨大,且安全性不能得到保障。为了将这些作战资源接入云服务,在对作战资源进行功能化封装之后,可在作战资源外层加上一层“壳”,以与云协同中心以及其他云服务进行交互,为此本文提出服务适配器的概念。

服务适配器是作战资源模型与云协同中心、作战资源模型与其他云服务交互的中介,它与虚拟资源构成了一个完整的云服务。服务适配器是独立于作战资源的第三方软件或硬件资源,以即插即用的方式将作战资源模型封装为云服务。它包含了云服务正常运行所必备的若干模块,对内主要与作战资源模型通讯,对外与云协同中心和其他云服务进行交互,如图5所示。

图5 云服务的交互Fig.5 Communication of cloud services

(1) 与作战资源通讯。解析外部对云服务的简单对象访问协议(simple object access protocol,SOAP)请求,将其转化为作战资源模型可读取的操作或事件;将作战资源模型对其他云服务的调用请求和事件流转化为SOAP文件,并通过服务总线传输给其他云服务。

(2) 与云协同中心交互。主要实现云服务的注册与管理和服务质量的管理[10]。

(3) 与其他云服务交互。在云服务执行时,遵循SOAP协议与其他云服务进行交互,实现协同,包括基于接口的调用、基于事件驱动的协同和基于数据流通道的长时协同等形式。

为了实现上述交互功能,服务适配器应包含服务注册与管理、服务质量管理、服务事件路由和操作方法接口等模块,如图6所示。服务注册与管理模块负责在云协同中心注册、注销以及云服务状态的更新;服务质量管理模块根据作战资源的状态动态维护云服务的服务质量;服务事件路由基于发布-订阅机制接受其他云服务的事件订阅和订阅其他云服务的事件[11-12],当事件产生时,通过服务事件路由根据其他云服务的订阅情况对所生产的事件进行分发[13];操作方法接口负责将作战资源模型的远程调用进行格式转换。

为保证云服务的正常发布和运行,服务适配器对外交互须遵循相应的协议。服务注册与管理模块应遵循UDDI协议[14];服务质量管理模块应遵循服务水平(service-level agreement, SLA)协议[15];服务事件路由模块所生产和消费的事件、操作方法接口模块都应遵循EDA扩展的WSDL协议[16]。以WSDL 1.1为例,接口和事件的声明在WSDL中的表示示例分别如图7和图8所示[17]。

图6 服务适配器Fig.6 Service adaptor

图7 操作的声明在WSDL中的表示示例Fig.7 Example of operation declaration in WSDL

图8 事件的声明在WSDL中的表示示例Fig.8 Example of event declaration in WSDL

通过上述服务化封装方法,屏蔽了作战资源的异构性,使得用户不必关心作战资源的具体执行过程,而只需要以标准的接口或事件来访问云服务即可,因而作战资源对调用者是透明的。

2 虚拟化对云协同主要流程的支持

对作战资源进行虚拟化是为了能在云协同系统中被发现、组合和执行,因此本节从服务组合、服务选择和组合服务执行3个方面说明虚拟化方法的可行性。

2.1 服务组合

服务组合是指根据作战需求,将原子云服务进行流程编排,生成组合云服务模板的过程[18]。多数服务组合方法仅基于工作流,将各抽象原子云服务按照串行、并行、选择、循环等基本结构进行组装而成,而忽视了各云服务间的数据和消息的传输,因而也忽略了云服务间的协作方式[2]。利用本文所提出的云服务封装方法,可方便地对组合服务的协作方式进行建模。

服务流程编排包括各抽象原子云服务执行流程的确定和云服务间协作方式的确定两个阶段,如图9所示[19]。在执行流程确定阶段根据作战任务制定组合服务的工作流[20];在协作方式确定阶段,确定原子服务间的接口调用、事件订阅和数据流通道等信息。

图9 服务组合方法Fig.9 Service composition method

2.2 服务选择

服务选择是对组合云服务中各抽象原子云服务进行实例化的过程。服务选择包括两个阶段,即按功能性属性筛选阶段和按服务质量选择阶段[21]。功能性属性包括作战资源的属性信息(静态属性、动态属性、使用属性和部署属性)、接口信息、事件信息和数据流信息。对于各个抽象原子云服务,首先要从资源池中选择出满足功能性属性的一组云服务,构成云服务候选集,然后依据一定的优化算法,从中选择出服务质量与用户所期望最匹配的组合云服务作为最终结果[2]。

2.3 组合服务执行

通过服务组合和服务选择,得到一个可执行的组合服务。组合云服务在开始执行作战任务之前,仍是互相分离的,未建立通信通道,因此须首先完成组合服务的初始化,包括接口的绑定、事件的订阅和数据流通道的建立等,这些通信通道的建立均由各云服务的服务适配器完成的。在如图9所示的组合服务中,包括如图10所示的接口绑定、事件订阅和数据流通道建立等信息。

图10 接口绑定、事件订阅和数据流通道建立Fig.10 Interface binding, event subscription and establish of data stream channel

初始化完成之后,组合云服务便按照组合服务的流程、接口绑定信息、事件订阅信息和数据流通道等信息执行。

3 实验验证

为了验证作战资源虚拟化方法的有效性,本文在“网络化作战组织云协同仿真实验台”上进行了验证。实验台由战场环境与兵力生成台、云协同中心台、云服务管理台、战场态势服务提供台、物理资源仿真台、云服务请求台和若干作战任务执行台组成,其中物理资源仿真台模拟战场上的作战资源,通过作战资源建模抽象出其作战能力,并通过接口、事件和数据流通道的形式将能力暴露出来,再通过服务化封装,封装为服务,并在云服务管理台进行服务注册与发布。

实验场景为:某敌机侵入我方领空,我方首先利用感知云服务在指定区域进行搜索,搜索到目标大致位置后利用服务质量更高的感知云服务进行目标确认,确认目标后利用攻击云服务对目标发射导弹实施攻击,并利用引导云服务为导弹进行引导。打击结束后利用评估云服务评估目标毁伤情况。作战的工作流图如图11所示。

图11 作战工作流图Fig.11 Workflow of operation

利用本文所提出的作战资源服务化方法,对某型地基雷达、某型载有红外探测装置的战斗机、某型载有导弹的战斗机、某型载有激光指引器的战斗机、雷达成像情报侦察卫星系统等进行了封装,如表2所示。

表2 作战资源服务封装

经过服务搜索,可得到满足条件的一组原子云服务,这些原子云服务组成一个组合云服务。组合云服务首先要完成初始化,初始化结构图如图12所示。

图12 云服务交互协作图Fig.12 Interoperability of cloud services

初始化完毕后,组合服务开始执行。作战任务执行台通过调用S1的int1接口开始云服务的执行。

可以看出,各原子云服务已按照预计的协作方式完成了作战任务。在基于模板的作战资源虚拟化方法[1]中,只对作战资源的功能以接口的形式进行了封装,而没有以事件的形式封装,因而作战资源间的协同需要在创建组合云服务之初,由云协同平台对各云服务的执行顺序和调用的接口显式地指定,并且在执行过程中必须明确各种情况下的执行方法,各云服务都是在其他云服务的调用下被动地执行,执行效果难以保证,降低了各云服务根据环境和本身当前状态进行自主执行的能力。而在本文提出的虚拟化方法下构成的组合云服务,各云服务保留了自身的自主性,因而增强了云服务间的协作能力。

4 结束语

针对网络化作战组织云协同中的关键问题之一——虚拟化,本文提出了一种异构作战资源的虚拟化方法。通过功能化封装,将作战资源的能力以接口、事件和数据流的形式体现出来;通过服务化封装,将服务适配器与虚拟资源组合为云服务。实验结果表明,该方法可以更方便地实现云服务间的协同。下一步的工作将主要从以下两方面展开:一是事件路由安装在服务适配器中,还是直接集成于服务总线需进一步讨论;二是针对该虚拟化方法,进一步设计高效的服务优选算法。

参考文献：

[1] 齐玲辉. 面向服务的军事组织云协同关键技术研究[D]. 西安: 西北工业大学, 2015.

QI L H. Research on the key technology of service oriented collaborative cloud military organization[D]. Xi’an: Northwestern Polytechnical University, 2015.

[2] ZHANG A, SUN H Y, TANG Z L, et al. Service composition based on discrete particle swarm optimization in military organization cloud cooperation[J]. Journal of Systems Engineering and Electronics, 2016, 27(3): 590-601.

[3] 任磊, 张霖, 张雅彬, 等. 云制造资源虚拟化研究[J]. 计算机集成制造系统, 2011, 17(3): 511-518.

REN L, ZHANG L, ZHANG Y B, et al. Resource virtualization in cloud manufacturing[J]. Computer Integrated Manufacturing Systems, 2011, 17(3): 511-518.

[4] ZHANG Y, ZHANG G, LIU Y, et al. Research on services encapsulation and virtualization access model of machine for cloud manufacturing[J]. Journal of Intelligent Manufacturing, 2017, 28(5):1109-1123.

[5] 易安斌,周宏甫.云制造环境下设备资源服务化封装方法研究[J].组合机床与自动化加工技术,2016(5):151-154.

YI A B, ZHOU H F. Service encapsulation method of equipment resources in cloud manufacturing environment[J]. Modular Machine Tool & Automatic Manufacturing Technique, 2016(5): 151-154.

[6] LIU N, LI X. A resource virtualization mechanism for cloud manufacturing systems[M]. Berlin: Springer, 2017: 46-59.

[7] 刘宁. 云制造资源虚拟化关键技术及应用[D]. 南京: 东南大学, 2015.

LIU N.The key technology of cloud manufacturing resource virtuali-zation and application[D]. Nanjing: Southeast University, 2015.

[8] WIELAND M, MARTIN D, KOPP O, et al. SOEDA: a method for specification and implementation of applications on a service-oriented event-driven architecture[C]∥Proc.of the International Conference on Business Information Systems, 2009: 193-204.

[9] CHEN J S, CHEN C H, FURUMOTO J I. Radar beam-and range-weighting effects on three-dimensional radar imaging for the atmosphere[J]. Radio Science, 2016, 46(6): 1-13.

[10] RAMIREZ A, PAREJO J A, ROMERO J R, et al. Evolutionary composition of QoS-aware web services: a many-objective perspective[J]. Expert Systems with Applications, 2017, 72: 357-370.

[11] 黄鑫. 基于发布/订阅机制的协同作战敌我识别系统软件设计与实现[D]. 成都: 电子科技大学, 2016.

HUANG X. Software design and implementation of collaborative combat IFF system based on publish / subscribe mechanism[D].Chengdu:University of Electronic Science and technology of China, 2016.

[12] 张仲妹, 刘晨, 苏申,等. SDaaS:一种传感流数据的服务化封装方法[J]. 计算机学报, 2017, 40(2):445-463.

ZHANG Z M, LIU C, SU S, et al. SDaaS: a method for encapsulating sensor stream data as services[J]. Chinese Journal of Computers, 2017, 40(2):445-463.

[13] 刘家红, 吴泉源. 一个基于事件驱动的面向服务计算平台[J]. 计算机学报, 2008, 31(4): 588-599.

LIU J H, WU Q Y. An event-driven service-oriented computing platform[J]. Chinese Journal of Computers, 2008, 31(4): 588-599.

[14] GHADGE T, BOGIRI N. Framework for web service composition and invocation[C]∥Proc.of the International Conference on Automatic Control and Dynamic Optimization Techniques, 2017: 1030-1035.

[15] MIROBI G J, AROCKIAM L. Service level agreement in cloud computing: an overview[C]∥Proc.of the International Conference on Control, Instrumentation, Communication and Computational Technologies, 2015: 753-758.

[16] JURIC M B. WSDL and BPEL extensions for event driven architecture[J]. Information & Software Technology,2010,52(10): 1023-1043.

[17] CURBERA F, DUFTLER M, KHALAF R, et al. Unraveling the web services web: an introduction to SOAP, WSDL, and UDDI[J]. Internet Computing IEEE, 2002, 6(2):86-93.

[18] GARRIGA M, FLORES A, CECHICH A, et al. Web services composition mechanisms: a review[J]. IETE Technical Review, 2015, 32(5): 376-383.

[19] 王辉. Web服务编排协议映射模型及实现机制[D]. 秦皇岛: 燕山大学, 2015.

WANG H. Mapping model and realization mechanism of web service orchestration protocol[D]. Qinhuangdao:Yanshan University, 2015.

[20] VAN DER AALST W M P, TER HOFSTEDE A H M, KIEPUSZEWSKI B, et al. Workflow patterns[J]. Distributed & Parallel Databases, 2003, 14(1): 5-51.

[21] ZHANG A, SUN H Y, ZHANG Y X. Service allocation based on QoS evaluation in military organization cloud cooperation[J].Journal of Systems Engineering and Electronics, 2016, 27(2): 386-394.