基于微内核设计思想的软件应用框架设计

董 强，许长霞

（西南计算机有限责任公司，重庆 400060）

0 引言

伴随信息化技术的飞速发展，软件产品逐渐渗透应用到社会的各个领域。客户期望软件产品能够满足更多的功能需求，快速适应功能需求变更，缩短产品研制周期等要求［1］。本文先分析传统应用框架的缺陷，再结合实际工程应用需求，基于微内核设计思想，构建一套能够支撑软件产品高效、快速开发的应用框架。

1 应用框架现状分析

传统应用框架主要用于对各类基础功能和业务功能进行整体性封装，并实现对各功能适时调度和流程控制；基础功能是一种与业务功能无关的功能，具有粒度小，复用度高的特点；业务功能主要用于实现软件产品的业务需求。基础功能与基础功能、业务功能与业务功能、基础功能与业务功能之间都可能直接发生信息交互（包括功能调用、数据交换、消息交互等），传统应用框架基本组成如图1所示。

图1 传统应用框架基本组成图Fig.1 Basic composition diagram of the traditional application framework

用户对软件产品功能需求的增多，软件产品所包含的各类功能也随之增多，功能之间的耦合程度变得更加紧密。新功能的增加和原功能的变更，都会导致应用框架和各类功能受到一定程度的影响，造成软件产品修改、维护、扩展困难的问题，无法满足客户对软件产品的高要求［2］。

2 基于微内核设计思想的应用框架分析

2.1 微内核分析

微内核（Micro kernel）是提供操作系统核心功能内核的精简版本［3］，是内核的一种精简形式。它提供一组“最基本”的服务，如进程调度、进程间通信、存储管理、处理I/O 设备。其他服务，如文件管理、网络支持等作为扩展服务通过接口连接到微内核［4］。将通常与内核集成在一起的系统服务层被分离出来，变成可以根据需求加入的选件，这样就可提供更好的可扩展性和更加有效的应用环境。使用微内核设计，对系统进行升级，只要用新模块替换旧模块，不需要改变整个操作系统［5］。微内核具有可移植性、灵活性和扩展性，以及健壮性等特点［6］。微内核示意图如图2 所示。

图2 微内核示意图Fig.2 Schematic diagram of microkernel

2.2 组件化分析

组件化是指解耦复杂系统时将多个功能模块拆分、重组的过程，有多种属性、状态反映其内部特性。为了达到解耦的目的［7］，按照软件产品需求将软件产品拆分成多个组件［8］，确定各组件的边界和职责。拆分出来的各组件由于耦合度低，基本上互不影响，便于开发人员同步开展各组件的开发工作。开发完成的独立组件按照集成规范集成到应用框架，由测试人员实施单元测试。当各独立组件完成单元测试后，将所有组件集成到应用框架，进行集成测试，对测试过程暴露出软件问题，只需要修改相应的组件。针对用户变更的需求，定位变更组件后进行修改即可；针对用户新增的需求，重新按照拆分组件、开发组件、组件单元测试、集成测试、修改组件等流程，最终形成软件产品。组件化的意义还在于提升代码复用性［9］，可以直接将相同功能的组件运用到其他项目，而无所重新开发，或者是对该组件进行重构，让其复用程度更高，也便于后续软件产品的复用［10］，提高软件产品的开发效率。

2.3 总体设计思路

借鉴微内核操作系统设计思想和组件化的设计方法，将传统软件应用框架核心功能分离出来，作为软件应用框架的内核服务，负责完成与具体业务功能无关的最基本功能，如组件管理、组件通信、组件连接等，它不会因为各类功能的扩展而不断修改，仅用于支撑软件产品的基本运行。由于其精简形式的核心设计，更容易对其充分测试，保证整个系统的稳定性。

基础组件通过组件连接服务实现应用框架的基础功能扩展，而不影响整体系统的稳定性；根据软件产品功能需求，开发或复用相应的业务组件，通过组件连接服务按需集成所有业务组件。基于微内核设计思想的软件应用框架总体设计如下页图3 所示。

图3 基于微内核设计思想的软件应用框架总体设计图Fig.3 Overall design diagram of software application framework based on microkernel design concept

3 基于微内核设计思想的软件应用框架设计

按照基于微内核设计思想的软件应用框架总体设计思路，细化内核服务功能，将其设计成基于微内核设计思想的软件应用框架，它包括一个组件描述文件规范和组件管理服务、组件连接服务、组件通信服务等三种集成接口服务。组件管理服务提供加载组件、注册组件、查询组件、调度组件、卸载组件等功能；组件连接服务提供连接组件、获取接口类集合、初始化组件、释放组件等功能；组件通信服务用于各组件间的信息交互，包括发送信息和接收信息等。基于微内核设计思想的软件应用框架组成如图4 所示。

图4 基于微内核设计思想的软件应用框架组成图Fig.4 Composition diagram of software application framework based on microkernel design concept

其中，基础组件用于完成某类应用需求而构建的通用化功能模块；业务组件用于完成特定应用需求而构建的专业化功能模块。

3.1 微内核应用框架工作原理

软件产品启动时，宿主程序直接调用微内核应用框架提供的导出函数，由其函数自动启动组件管理服务；组件管理服务先依次加载各组件，再调用组件连接服务获取各组件连接对象，然后将各组件注册到组件管理服务中；各组件启动时按需向组件管理服务注册组件接收信息对象。

软件产品运行中，各组件按需调用组件通信服务中的发送信息对象向其他组件发送交互信息；发送信息对象经过一系列的数据预处理，通过接收信息对象将交互信息分发到指定组件；接收到交互信息的组件，根据交互信息标识符进入对应的处理流程。

软件产品退出时，组件管理服务调用组件连接服务释放并卸载各组件。

3.2 组件描述文件规范设计

组件描述文件规范是一种结构化的描述模板，定义了组件基本信息，以及组件与外部发生交互关系所需信息。具体包括组件信息、集成信息、交互信息、接口类信息的规范；其中，组件信息中组件标识符用于唯一标识某个组件；集成信息中集成接口标识符用于唯一标识某个组件功能点；交互信息中交互信息标识符用于唯一标识某个组件传递的某条信息；接口类信息中接口类标识符用于唯一标识某个组件的接口类。

考虑到组件描述文件规范应具备跨平台、易阅读、可扩展、可视化等特性，建议采用XML 文件格式来存储组件描述信息。组件描述文件规范如图5所示。

各组件参照组件描述文件规范，编写专属组件描述文件，并编码实现其描述文件中定义的外部交互标识符所对应的逻辑代码，再由组件管理服务通过组件描述文件中定义的外部交互标识符间接调用组件内部的逻辑代码。组件描述文件规范使用原理图如图6 所示。

图6 组件描述文件规范使用原理图Fig.6 Schematic diagram of the use specification of component description files

3.3 组件管理服务设计

组件管理服务为各类组件提供加载、注册、查询、调度和卸载等功能。

组件管理服务启动时，自动扫描所有组件描述文件，将描述信息转换成内存结构化数据，再按照顺序逐个加载组件，调用组件连接服务创建组件连接对象，通过组件连接对象获取组件接口类集合，最后将已加载组件存储到注册组件集合中，实现组件的注册。当某组件需要获取其他组件提供的服务时，通过组件管理服务查询组件接口集合；当不再使用某组件时，由组件管理服务对其卸载，并释放软件内存空间。组件管理服务注册组件流程图如图7 所示。

图7 组件管理服务注册组件流程图Fig.7 Flow chart of registered components of component management service

3.4 组件连接服务设计

组件连接服务为各组件提供连接到组件管理服务的规范，各组件参照组件连接服务规范，编写其具体逻辑代码，实现组件连接功能。组件连接规范由一个组件连接（全局）函数和一个组件连接（基类）组成。

组件连接（全局）函数定义为一个函数名为*CreatePluginObject（）的导出函数。各组件按规范定义该导出函数，并在其函数内部调用new 方法创建一个组件连接子类对象，并返回该组件连接子对象。组件管理服务在加载组件后，直接调用组件连接（全局）函数用于获取组件连接子对象。

组件连接（基类）包括获取接口类集合、初始化组件、释放组件等接口。各组件从组件连接（基类）派生各自的组件连接子类，并实现其接口功能。在组件连接（基类）和各组件连接子类对象中使用关键字virtual 定义的接口函数都会有建立一个与其对应的虚函数表，该虚函数表中存放每一个对象的虚函数入口地址。对于各组件来讲，它会继承基类的虚函数表同时增加自己的虚函数入口地址，当子类重写基类的虚函数，继承过来的虚函数入口地址将被子类的重写虚函数入口地址替代。程序运行时会发生动态绑定，将基类指针绑定到实例化的子对象，由组件连接基类根据组件连接子类对象来执行不同的成员方法，已达到按需调用组件连接子类功能的目的。组件连接服务原理图如下页图8 所示。

图8 组件连接服务原理图Fig.8 Schematic diagram of component connection service

3.5 组件通信服务设计

组件通信服务为各组件之间的信息交互提供必要的通信链路。组件通信服务由发送信息和接收信息组成。组件通信服务原理图如图9 所示。

图9 组件通信服务原理图Fig.9 Schematic diagram of component communication service

发送信息用于某组件向其他组件发送交互信息。在组件通信服务内部创建一个由发送信息（基类）派生的发送信息（子类），实现发送信息接口功能，该接口包含全局数据交互标识符和数据流两个参数。当该接口被调用时，根据全局数据交互标识符在注册组件集合中查询对应的交互规则，按照指定的传输模式进行组件信息传递。当传输模式设定为寄存模式，发送的数据流将被存放在发送队列中，按照数据交互信息优先原则从队列中逐条取出并进入分发流程；当传输模式设定为及时模式时，发送的数据流将直接进入分发流程。在分发流程中，解析（接收）组件标识符来确定该条信息的通信方式（如：点播、组播和广播3 种方式）。

点播：一个组件发送交互信息到一个指定组件对象

组播：一个组件发送交互信息到多个指定组件对象

广播：一个组件发送交互信息到其他所有组件对象

寄存模式利用队列“先进先出”（FI FO —First-In/First-Out）的重要特性，按照组件提出交互请求的顺序依次存入数据缓存队列，如图10 所示。

图10 寄存模式的数据缓存队列Fig.10 Data cache queue in registration mode

针对寄存模式，先判断轮询定时器是否启动，如果没有启动则启动轮询定时器，按照δt（ms）时间间隔查询数据缓存队列中的交互请求，查询成功，则从队列头部取出一条交互请求，进入分发流程；循环查询数据缓存队列，直到查询失败，则停止轮询定时器。

针对及时模式，暂停当前发送任务，直接进入分发流程，处理完成后恢复到之前的发送状态。

接收信息用于某组件接收其他组件发送到本组件的交互信息。各组件从组件接收（基类）派生各自的组件接收（子类）实体类，并编码处理其接收到的组件交互信息。组件通信服务经过一系列的预处理，通过调用接收信息（基类）间接调用各组件的接收信息（子类）实体类，组件接收方再依据约定的全局信息标识符对数据流进行解析，进入自身交互信息处理流程。

4 结论

本文设计了一种基于微内核设计思想的软件应用框架，支持项目团队同步开发基础组件和业务组件，通过基础组件实现软件应用框架功能的持续扩展，按照软件产品需求加载对应业务组件，以达到最终实现具体软件产品。利用本设计能够适应软件产品“短、频、快”的开发特点，满足用户对产品的需求。该应用框架已应用到某领域的信息系统软件中。