基于分布式数据流的指控系统服务集成方法

卢 飞,程培星,阴启玉

(1.海装电子部，北京 100841;2.江苏自动化研究所,江苏 连云港 222006)

当前以“信息化”为核心的世界新军事变革浪潮席卷全球,获取信息优势、进而取得决策优势和最终的行动优势是夺取未来信息化战争胜利的关键。在相应军事系统构建中,面向服务架构 SOA(Service Orient Architecture)能将广泛分布的松耦合的各种系统组成信息服务网络,为终端用户提供所需的各种服务和数据[1]。但是,军用通信环境是一个包含战略、战役及战术互联网的复杂多系统异构通信网络,其中,既有地面光纤宽带骨干网,又有卫星通信、无线电台通信和战术互联网等其他通信网络。而现有的SOA技术实现主要还是针对互联网环境的,并未考虑军用网络环境的复杂性,尤其是目前 SOA技术主要采用BPEL(Business Process Execution Language)作为业务逻辑整合标准实现业务流程的动态配置和发布,其标准规范是基于中心式的,需要大量的数据流和控制流信息的通信,难以适应无线电台、数据链等窄带通信信道要求,无法满足网络化指控系统的服务集成要求。

1 国外现状

美军在20世纪90年代末提出了建立全球信息栅格(Global Information Grid,GIG),实现全球范围的信息优势,即在正确的时间,将正确的信息以正确的形式安全可靠地传送给正确的接收者,同时压制敌方谋求同样能力的企图。全球信息栅格是一种可互操作的联合电子信息系统,利用信息技术和创新的概念,实现多种综合信息系统与传感器系统、武器系统在更多功能领域、更大空间范围、更多作战层次上的综合集成,在网络上提供信息与服务,使用户能够根据所需主动提取而不是强推信息和服务[2]。

但是,全球信息栅格也面临着许多方面的技术挑战。通信带宽容量在战略、战役和战术级别都受到严重制约和挑战,特别是战术级的带宽需要扩展才能满足未来作战的信息需求。由于通信带宽容量的限制,很大程度上降低了信息共享以及系统间互操作的能力,限制了关键信息向指挥系统和武器系统的传输,阻碍了作战空间中时敏作战行动,因此如何有效融合现有的各通信带宽的信息节点以及最终各信息节点形成统一的互操作标准将是GIG发展的重点。

2 服务组件模型设计

要实现作战要素的动态组合,并能够根据不同需要构建不同规模和能力的任务系统,组成指控系统的服务组件必须具备可组合性,通过服务组件之间的组合,可以构建新的服务,这个新的服务能完成单个服务不能完成的任务,满足用户特定的需求。在面向服务架构中主要采用 Orchestration形式的组合,Orchestration定义了可执行的流程,流程和外界信息交换的顺序由Orchestration来集中控制,其对应的规范为BPEL[3]。目前其技术实现主要采用集中式的信息流处理方法,这样做使得组合后的服务成为一个中心控制端,它负责运行时各子服务的消息关联。各个子服务间交互的数据都必须通过这个中心控制端进行转发、处理,这样不仅大大降低了业务流执行效率,而且还浪费了大量带宽。目前,很多软件架构都是基于这种中心式的数据流进行集成的,包括J2EE、CORBA、Microsoft .NET等。在军用网络环境中(包含各类低速无线网络),这个缺点显得尤其突出,指控系统中很多基于无线窄带的应用平台将无法适合目前的SOA体系结构[4]。

基于以上原因,本文提出了一种基于分布式数据流的指控系统服务集成方法。基于该方法集成的指控系统可以实现以下目标:①增强服务化指控系统的扩展性,可以支持军用异构网络环境下的多平台系统集成,适应各种复杂的军事网络环境。②提高服务化指控系统的执行效率,可使集成后的系统执行速度和效率更高。③简化集成难度,异构平台下的各个服务组件可以在不牺牲扩展性和效率的前提下,更加便捷、快速的集成。

为了实现基于分布数据流集成的指控系统,本文首先设计了服务组件模型,该组件模型可以有效地提升服务间的互操作效率。指控的服务组件模型如图1所示,它由一个核心处理部分、一个输入事件队列、一个输出事件队列、一个输入数据容器、一个输出数据容器组成,其中:

· 核心处理部分是服务组件的核心功能实现。它负责处理输入的数据,并生成相应的输出数据。我们通过适应性改造可以把已有的软件应用封装成服务核心处理部分。

· 事件是在服务之间交互的控制流信息。服务组件的异步运行主要通过事件来进行协调控制。其中队列结构采用FIFO(first in and first out),即保证按照事件到达的顺序依次进行处理,在工程应用中可通过设置事件流水号来确保事件的发送顺序与到达顺序的一致。

· 数据容器包含服务组件的输入数据和输出数据。输入的数据元素可从输入数据容器中获取,由服务核心处理部分计算、处理,其产生的数据元素放入到输出数据容器中。

服务化指控的各软件模块按照服务组件模型的定义进行封装,并发布到网络上。尽管各个服务实现的功能不同,但是所有服务组件发布形式都是相同的,因为它们含有共同的要素,如事件队列和数据容器。这就保证了组件之间交互方式是统一的。因此,服务化指控可以基于标准的模块进行构建、重组,大大减少了集成的难度。这里,我们将服务核心处理部分封装的部分,即图1中的灰色部分,称作服务封装。

服务组件基于服务核心处理部分,实现了三个主要接口函数,将核心处理部分封装成标准化的服务组件,接口函数主要包括:setup( ),execute( ),terminate( )。其中:

· setup( ):主要定义了服务初始化阶段进行的操作;

· execute( ):当服务被调用时,负责触发服务的核心处理部分的执行,处理时核心处理部分从输入数据容器中取出待处理数据,并将结果放入输出数据容器中;

· terminate( ):当服务终止时被调用。

其中每个接口函数都包含三个参数,inputcontainer定义了输入数据容器的引用,outputcontainer定义了输出数据容器的引用,flowid定义了服务组件所属的工作流。

3 服务组件访问协议

基于以上的服务组件模型,下面定义了服务组件访问协议,根据定义的协议服务组件可以进行互操作。服务组件访问协议通过一系列的事件来管理控制流和数据流。该协议是异步和非阻塞的,这就保证了事件的发送者不需要等待响应,可以继续执行其他操作。该协议是基于XML的分层结构的,与具体的编程语言、操作系统无关的。

协议中与数据流调度相关的几个主要事件如下所示:

· 创建(Service)

创建事件用来初始化一个服务组件,并为服务组件调用准备必要的系统资源。当服务组件初始化完成后返回一个应答。

· 终止(Service)

终止事件将强制终止一个服务组件。在终止服务的时候将释放服务组件占用的系统资源。当服务组件终止后,返回一个应答。

· 调用(Service)

调用事件将启动一个服务组件。在处理调用事件的时候,服务组件的核心处理部分开始执行。调用完成后,核心处理部分输出的数据元素将放到输出数据容器中。另外,返回一个应答。

· 数据映射(DataElement,SourceService, DestinationService)

数据映射事件用来控制两个数据容器间的数据流,该事件定义了各服务组件间数据流的流向。数据映射事件由协调各个服务组件的组合服务控制器来发送,数据元素在服务组件的数据容器间直接交互。数据映射事件可以实现分布式的数据流,通过预先订好的事件可以实现分布式数据流的灵活重组,并有效的提高了重组效率。

数据映射事件有两种实现形式。一种实现形式是“推事件”,事件将被发送到源服务组件,源服务组件从输出数据容器中获取数据元素,然后将数据推送到目的服务组件中。另一种实现方式是“拉事件”,事件发送到目的服务组件,目的服务组件从源服务组件中拉数据元素,然后将数据放入输入数据容器。

4 服务组件集成架构

基于前面定义的服务组件模型以及服务组件间的访问协议,我们可以构建服务组件集成架构。如图2所示。

图2 服务组件集成架构

该架构主要由组合服务控制器、服务组件目录及各个封装好的服务组件组成。组合服务负责控制整个业务的执行过程,其根据预先定义好的控制流信息,通过发送事件来控制各个服务组件间的执行流程。服务组件目录保存了网络中所有服务组件的详细信息,这里逻辑上虽是中心式的,但是可以基于分布式架构来实现。新的服务组件只需在服务组件目录中注册其相应信息,并连接到通信网络上即可插入到集成架构中。

图3 集中式和分布式数据流服务集成架构

通常情况服务集成框架实现中,控制流和数据流都是集中式管理的,如图 3(a)所示,组合服务首先向服务 1发送请求信息,然后依次由服务2、服务3处理。因为数据流和控制流没有分离,所有的数据都必须经过组合服务转发,额外增加了很多数据的通信量,尤其是在军用通信网络中对通信资源造成了很大的压力,进而影响了系统的性能和可扩展性。

如图3(b)所示,说明了本文中的分布式数据流服务集成架构。图中,控制流和数据流是分离的,控制流负责事件的处理和服务组件的运行状态控制,数据流主要涉及数据容器间的数据交换和服务组件的数据处理。组合服务通过控制流建立了服务组件间的数据流直接交互通道。因此,图3(b)中的服务1和服务2,服务2和服务3可以直接交换数据,而不需要像图3(a)中的集中式数据流,必须通过组合服务。通过分布式的数据流,减少了冗余数据的发送,克服了原来所有数据都需要通过组合服务带来的服务响应时延大、通信带宽占用大的弊端。而且,如果经过流程的优化,可以使得数据尽量在本地进行处理,这样可以进一步减少数据的传输量,提高执行效率。

为了保证业务流程的顺利执行,分布式数据流服务集成架构需要生成向各服务组件发送的控制流。首先需要分析组合服务组件间的数据依赖关系,建立服务组件间的数据依赖图,最后生成组合服务控制器发送的控制流事件依赖图。

分析上面所示的一段示例代码,Service3的输入为A和B,而A和B分别由Service1和Service2生成,所以 Service3在数据上依赖于 Service1和Service2的调用。同理,示例代码被映射成如图 4(a)所示的数据依赖图。图中的节点代表一个服务组件的调用,每条线代表着服务组件之间交互的数据元素。将图4(a)中的线转换成数据映射事件,就得到了组合服务的控制流事件依赖图,如图 4(b)所示,图中的每一个节点代表的是组合服务控制器将要发送的一个控制事件,图中的线表示了事件发送的先后关系,后一个事件只有在前一个事件发送后才会发出,其中调用事件负责调用服务组件的 execute( )接口,数据映射事件负责从源服务的输出数据容器中取出数据发送到目的服务的输入数据容器。组合服务控制器根据图4(b)依次发送控制事件,保证整个流程的顺利执行。

5 结束语

本文提出的服务集成架构基于分布式数据流模型。该模型允许不同服务间数据的直接交互,比起集中式数据处理,特别是当传输的数据量很大时,分布式的数据流模型提供了更好的服务集成性能和扩展性。分布式的数据交互有利于充分利用服务间的带宽资源,避免集中管理带来的通信瓶颈。尤其是当组合服务调用的构件在无线低带宽的移动平台时,传统的集中式服务管理将受到很大限制。而基于本文提出的架构,只有控制流(如远端程序的调用)是中心式的,占用带宽大的数据流则完全是分布式的,减少了对带宽的要求。

图4 控制流事件依赖图(

基于本文的研究成果,在复杂的军用通信环境下,基于服务组件模型构建的分布式服务集成架构将有效支持服务组件向各级作战平台的延伸,可初步实现军事信息系统中岸海之间、海上编队之间的互操作。基于不同规模和能力的作战任务,实现服务的多平台、跨网络组合应用,解决了面向服务架构中服务的组合与应用对低带宽环境的适应性。

[1]毛新生.SOA原理·方法·实践[M].北京:电子工业出版社,2007.

[2]张培珍,等.美军全球信息栅格结构研究[J].兵工自动化,2009,28(10):65-68.

[3]余浩,等.SOA实践[M]. 北京:电子工业出版社,2009.

[4]周晓明,等.指挥控制系统服务化研究[J]. 指挥控制与仿真,2010,32(3):12-14,21.