陈 辞

（海军驻大连四二六厂军事代表室 大连 116001）

1 引言

海上面临着愈发多元化的安全威胁，不仅有局部战争、边界冲突、战略威慑等诸多传统军事行动，维和、反恐、救灾、护航、撤侨等非战争军事行动也成为各国海军的重要使命。这使得海上任务的背景更加复杂化、对象更加多元化、行动更加多样化，对于海上信息系统信息化建设的要求也越来越高。但目前海上信息系统的信息化建设主要立足于传统的金字塔型指挥体系，难以满足信息化战争对扁平化信息交互的需求，缺乏对多平台系统资源统一调度、高效运作的支持，系统灵活配置、柔性重组能力不够，系统流程随需应变、动态重构的能力不足。因此，探索一种能够支持动态模块化构建、重组的海上信息化系统是一个亟须解决的问题，本文将商用IT领域流行的OSGi（Open Service Gateway Initiative）架构应用到海上信息系统，并对其应用效果做出了相应的分析。

2 海上信息系统的需求分析

1）现有资源重用、共享需求

未来海战是海、空、天、以至电磁谱域一体化的战争，是昼夜24小时全天候的战争，是一场总体战、立体战、导弹战、电子战［1］。多军兵种联合作战必将成为未来信息化战争的主要作战模式，以作战任务为中心，根据作战系统各自不同的特点和优势资源，进行优化整合，实施作战系统动态集成，极大发挥多系统的整体作战效能［2］。如何最大限度发挥装备协同作战的能力，以及如何为高科技的装备使用创造条件等问题直接关系到高科技局部战争的成败，它们的成功解决将大大提高海军的作战能力［3］。

因此，将现有海上信息系统中包括各个武器平台，传感器系统在内的各种资源充分重用、共享是解决装备性能瓶颈、提高协同作战能力的有效途径，也是目前海上信息系统急需解决的难题。

2）即插即用、动态集成

网络中心战概念的诞生使得海军能够建立以C4ISR为支撑点、以网络为中心的新型作战系统结构，从而实现多平台、多基地的互联互通，以及协同作战的快速反应要求［4］。在这种分布式的作战体系中，其最大特征在于体系的区域上分布性、单元的自治性、单元的独立性，以及单元间在整体目标驱动下的同步性，包括通信交流网络、指挥与协调关系、在任务执行上协作与协同关系等［5］。

但是，由于目前海上信息系统各个平台之间的能力差异、集成规划和技术体制的限制，在各个系统接口关系和信息流程相对固定，缺乏对信息化战争中灵活、快速、动态OODA环的支持，海上信息系统随需应变、动态集成、重组能力严重不足。因此，研究面向海上信息服务的即插即用、动态集成技术，实现跨平台多系统指挥控制、情报收集、处理能力、武器控制能力的聚合分解，能够打破系统边界，满足多样化的海上信息服务的需要势在必行。

3）稳定性、可扩展性

海上信息系统其实是不同平台预警探测系统、情报侦察系统、指挥与火力控制系统、通信系统、武器系统等诸多子系统整合而成的大系统（System of Systems）。而目前大系统集成没有有效的方法指导，缺乏顶层设计，导致大系统构建的周期增长、系统稳定性减弱、性能降低、互操作性弱、耦合度大等问题。

横向参考美军的发展，2004年1月，美军发布《联合转型路线图》，强调以“基于能力，效果驱动”的方式推进联合部队转型，全球信息栅格（GIG）是联合作战转型的关键概念和基础设施。使命能力包则是美军在网络中心战的背景下提出的，基于面向服务体系结构（SOA）的指挥控制系统解决方案。使命能力包以网络中心企业服务为基础，整合各个现役的指控平台，用以增强美军在联合作战战场环境下的技术优势和信息优势。

因此，自主构建具有良好稳定性、可扩展性的海上信息系统非常必要。

3 OSGi架构描述

随着通信、汽车、娱乐等行业的发展以及手持设备的应用，输入设备日益丰富，获取数据和服务的方式也越来越多［6～7］。复杂的应用环境无疑使得软件功能复杂，规模庞大，开发周期更长，成本更高，在这样的动态环境中，商业与应用模式变化迅速，已开发的软件很快就不能适应新的变化。有的软件甚至刚刚开发完成就已经不适合应用了［8］。正是在这种日新月异的背景下，OSGi应运而生。

OSGi直译为“开发服务网关”，是一个由OSGi联盟发起的以Java为技术平台的动态模块化规范。自从1999年OSGi联盟成立以来，OSGi技术就伴随着Java一起飞速发展，越来越多的世界著名IT企业都加入到了OSGi的阵营之中，如Adobe、IBM、Oracle、SAP、RedHat和Siemens等。这些软件厂商推出的许多产品都支持OSGi技术，甚至产品本身就使用了OSGi技术构建。这些IT巨头的踊跃参与，也从侧面证明了OSGi技术有着非常广阔的市场前景［9］。

OSGi规范应用的范围非常宽泛，可以应用于移动通讯、汽车、嵌入式设备［10］、家庭网关、个人电脑、高端服务器等多种领域。而最新的OSGi规范是2012年7月发布的Release 5，Version5.0（R5.0）注版本，该规范定义了Java模块化系统所涉及的各种场景（开发、打包、部署、更新和交互等），以及其中用到的标准接口和参考模型。OSGi的运行环境、核心架构以及常用的标准服务如图1所示。

图1 OSGi内容总览

在OSGi插件化开发模型中，系统被设计成一个核心加上一系列插件构成的功能模块，各个模块相对独立，除了实现软件关键逻辑的核心模块，其他模块都是可以被裁减的，如果一个模块设计得当，甚至可以独立发布或者直接安装在其他的系统中运行。而这恰恰就是现有海上信息系统所需要的。

图2 OSGi插件化开发模型

4 基于OSGi架构的海上信息系统应用模型

4.1 OSGi架构应用模型

OSGi架构定义了一个良好的面向服务的编程和运行模型。一个普通的OSGi Bundle可以向本地的注册中心注册服务，同时也可以查询、监听和使用同一个OSGi架构内注册的服务。但是，在分布式、多平台集成的海上环境下仅仅做到这些是不够的。远程服务作为在异构分布式环境中的必备要素，在OSGi架构中也获得了良好的技术支撑。

下面描述了一个典型的基于OSGi的海上信息系统远程服务应用场景。该场景中共有A、B、C、D四个海上信息节点，节点A提供CORBA服务，节点B提供Web服务（模拟异构环境），节点C提供运行于OSGi容器的OSGi服务，而节点D则是服务使用者，相互关系如图3所示。

图3 OSGi远程服务典型应用场景

对于海上信息系统这类异构、复杂的大系统，典型的服务集成框架中至少需要包括以下的几个功能模块：远程服务管理模块、监控模块、策略模块、服务发现管理模块、处理器管理模块等。相应的OSGi架构应用模型如图4所示。

图4 OSGi架构应用模型示意图

远程服务管理模块主要提供上文提到的远程服务管理能力。它负责监听远程服务注册和使用请求，对不同类型的服务进行管理，针对不同的服务配置类型，通知处理器管理模块进行发布和调用，维护当前发布的服务以及使用的远程服务的信息；监控模块负责监控OSGi容器中的本地注册中心，并从远程服务管理模块得到要监控的信息，对系统的运行情况进行调整和配置，保持系统的正常运行；策略模块为远程服务管理模块提供服务管理策略，为监控模块提供动态调整策略的支持；服务发现管理模块用于实现服务发现的动态管理和调用；处理器管理模块用于对处理器模块进行管理，并向远程端点发布和调用服务，根据远程服务管理模块所传递的信息调用相应的处理器模块；处理器模块是对某一种具体的远程访问机制的封装（模拟海上信息系统中的各种异构平台）。不同的处理器模块用于实现OSGi容器内的模块以不同的方式向OSGi容器外的服务的访问。处理器管理模块和不同的处理器模块的相互协作，实现了对异构、复杂的海上信息环境下不同的远程访问机制的集成和管理。

4.2 各个模块的运行机制

1）远程服务管理机制

在服务发布过程中，远程服务管理模块初始化时，会向本地注册中心查询“Strategy”服务，如果不存在则使用默认服务发布策略；查找到策略服务后，通过调用策略服务对象的相应方法获取到服务发布策略，远程服务管理模块内置一个发布的服务列表，当监听到远程服务注册事件时，远程服务管理模块将该服务的描述信息加入到该列表，并使用服务发布策略发布该服务。

在服务使用过程中，远程服务管理模块初始化时，会向本地注册中心查询“Strategy”服务，如果不存在则使用默认服务调用策略；查找到策略服务后，通过调用策略服务对象的相应方法获取到服务调用策略，当监听到远程服务的调用事件并调用成功后，远程服务管理模块内置一个列表来保存调用的远程服务的信息，并使用远程服务调用策略进行处理。

针对海上信息系统的异构、分布式复杂环境，服务提供者在服务注册时可以在自己的属性信息里面配置自己需要使用的远程互操作技术（如CORBA、Web Service等），同样，使用者也可以对应的方式配置自己需要采用的访问方式，从而增加了整个OSGi架构应用模型的灵活性和动态性。

2）监控和动态调整机制

考虑到OSGi架构应用模型中存在很多Bundle，这些Bundle在本地的注册中心注册了很多服务，为了实时掌握OSGi容器的运行情况并给服务发布和动态调整提供依据，此应用模型提供对本地OSGi容器运行情况的监控机制，主要使用的是OSGi内核以及Java虚拟机提供的API，监控的内容主要包括服务的依赖关系、堆栈的使用情况和本地线程数。

其中服务依赖关系方面，OSGi容器内的Bundle在注册服务时可以在元信息描述文件内设置服务注册的信息和需要使用到的其他服务的信息，因而OSGi容器内注册的服务之间存在着依赖关系，除了在元信息描述文件内静态的获取这些信息之外，还需要使用OSGi提供的API获得运行时的服务依赖关系；堆栈使用方面，JVM为每一个新创建的线程都分配一个堆栈。而对于本地线程数而言，如果运行的线程太多可能引起内存溢出之类的异常，因此在线程比较多的情况下控制最大线程数可以保证系统在比较稳定的状态下运行。

应用模型支持在Bundle数量不断增加时对系统和运行环境做出动态调整。监控模块初始化时，会向本地注册中心查询“Strategy”服务，如果不存在则不进行动态调整（使用人工调整）；查找到策略服务后，通过调用策略服务对象isConfigable方法获取到动态调整策略。调整主要涉及对新的服务注册、调用和查询进行控制；对应用模型运行容器的堆栈使用和Bundle生命周期状态调整。

3）策略机制

应用模型以即插即用、动态加载的策略模块的形式实现了策略驱动的海上信息系统。策略主要包括：OSGi本地服务发布给远程使用时，调用监控模块获得本地的运行情况，如果本地线程数或者本地堆栈使用超过设定的上限，则新的远程服务的注册、查询、调用请求将会被缓存；在服务调用过程中，如果服务突然失效，或者因为某些未知的原因不可访问，在服务调动策略的驱动下，远程服务管理模块会进行相应的处理；根据监控模块获得的本地资源使用情况，如果本地线程数超过设定的上限，则新的远程服务的注册、查询、调用请求将会被缓存；如果本地堆栈使用超过上限，则进行清理，并调整高启动级别的Bundle生命周期状态。这样的柔性动态调整策略可以大大增强OSGi架构应用模型的稳定性。

4）处理器管理机制

每个处理器模块都是以OSGi Bundle的形式加载的，OSGi Bundle的动态性保证了基于异构、分布式的处理器的动态性。每个处理器需要实现Handler接口，注册“Handler”服务，并在属性中说明类型，如“TYPE：Web Service”…；处理器管理模块运行期间将会向本地注册中心监听注册的Handler服务，并将服务引用加入到列表，将其属性中的“TYPE”字段加入到自己的“SupportType”列表。同时，基于新的互操作协议开发的处理器，只要实现了Handler接口、注册“Handler”无法，并且按照自身的编程模型做好服务的发布和调用工作，就可以将其动态的加入到基于OSGi的海上信息系统应用模型中来，增强那应用模型的可扩展性。

5）服务发现运行机制

与处理器管理机制类似，应用模型提供了服务发现管理机制。在服务发现管理模块的作用下，包括有一个Discovery的接口类，在该模块中创建了UDDI的名字服务机制、本地配置文件等多种服务发现方式。每种方式都实现了上述的Discovery接口，同时，应用模型运行前可以配置需要加载的服务发现类型。

由于OSGi架构天生的动态性会带来模块加载的不确定性，服务发现管理模块需要缓存所有的远程服务查询和注册请求，按照一定的时间间隔轮询所有请求，并向远程服务注册中心查询和注册，从而控制这些访问不是并发执行，保证了整个应用模型运行效率。

综上所述，基于OSGi架构的海上信息系统应用模型能够满足目前海上信息系统现有资源重用共享、即插即用动态集成、稳定性以及可扩展性等诸多需求。进一步深入地将OSGi架构应用到海上信息系统是很有价值的。

5 结语

随着信息化技术的不断发展，现代信息化战争对扁平化信息交互的需求越来越高。尤其对于海上信息系统而言，多平台各系统资源统一调度、协同共享、即插即用、动态集成、柔性重组的需求急需满足。在商业IT领域已经取得很大成果的OSGi动态模块化架构恰恰能够很好地对应解决目前海上信息系统的各种需求，增强信息服务共享能力，提高海上一体化信息支持服务水平。

［1］张中南，王峰，张卫峰.未来海上防空作战战场环境研究［J］.现代防御技术，2005，33（3）：9－13.

［2］李建军，刘翔，任彦，等.作战任务高层本体描述及规划［J］.火力与指挥控制，2008，33（1）：53－55.

［3］王敏.海上作战环境仿真技术在C4ISR系统的应用研究［J］.舰船电子工程，2003（6）：2－5.

［4］李开生，王文友.国外潜艇作战系统的现状及其发展趋势［J］.火力与指挥控制，2005，30（3）：4－7.

［5］黄广连，阳东升，张维明，等.分布式作战体系的描述［J］.舰船电子工程，2007，27（5）：3－6.

［6］熊江.OSGi的分析和实现及其改进思路［J］.计算机科学，2004，31（3）：192－194.

［7］熊江，应宏.基于 OSGi的普及计算系统的改进［J］.计算机科学，2005，32（1）：61－63.

［8］孙力军，陈德人，施敏华.基于OSGi的自适应可进化软件框架［J］.江南大学学报，2007，6（2）：140－143.

［9］周志明，谢小明.深入理解OSGi［M］.北京：机械工业出版社，2013：2－3.

［10］杨春阳，刘兵.基于OSGi规范的“智能化”嵌入式应用开发［J］.仪器仪表学报，2004，25（4）：632－634.