CN111596969B - 一种基于微内核加插件式的软件架构方法 - Google Patents

Abstract

本文发明公开了一种基于微内核加插件式的软件架构方法，该软件架构方法建立动态插件模型基础上，首先构建一个基础的框架应用程序，用以加载插件并且为插件的运行提供必要的执行环境；其次，制定插件的命名规则，确保不同开发者的插件命名的惟一性；然后，依次制定插件的物理组织规则、构建插件生命周期层、构建插件服务层及构建主题事件服务层；最后，构建插件容器，同时在插件容器和主框架中中添加跨进程消息转发功能，提供跨进程统一消息交互服务。本发明实现了主题事件交互和跨进程统一交互等软件框架核心服务功能，除了具有OSGI技术具有的复用性高、扩展性高、插件动态加载等特点，还具有跨平台、效率高和跨进程能力。

Description

一种基于微内核加插件式的软件架构方法

技术领域

本发明属于软件架构方法，具体涉及一种基于微内核加插件式的软件架构方法。

背景技术

软件架构的本质在于模块的拆分，这些经过拆分的模块在实施时按照业务的需求进行组装，满足应用软件的业务需求，最大限度的应对软件变更需要。微内核架构的拆分主要包含两个部分：核心系统和插件模块。内核是一个平台的最小核心，它是平台核心框架、公共类库的最小集合，没有任何业务逻辑，有一个负责插件组装的管理引擎，能够加载、卸载和运行应用所需的插件。内核必须是健壮并稳定的，用以保证平台本身的可扩展性、稳定性及灵活性。插件又分为技术插件和业务插件。每个业务插件均是是可独立完成某个或一系列功能的模块，是一个完整的业务描述，封装了一个业务目标所需的各种技术，业务逻辑。插件之间存在依赖关系，但只能通过指定的接口进行交互，从而实现插件间的松耦合性。通常插件由内核的管理引擎进行加载，它不能独立运行，需要在平台内核的支撑下才可以运行。

插件技术的应用可以大大的减少软件开发的时间，同时也将软件的质量得到了显著。目前，基于C++语言的插件式软件架构在插件的架构与生成、插件的识别、插件信息的获取、插件的生命周期未形成明确统一的规范，插件之间的解耦不足，在动态加载方面能力有所不足。随着软件系统的不断发展，软件系统自身结构和集成的功能正在变得日益庞大和复杂，功能应用的开发难度被提升、各个模块的耦合度增加，对软件的模块化提住了更高的要求。与此同时，各种新技术、新平台的应用需求使得插件框架的能力受到极大的挑战。

发明内容

发明目的：本发明旨在提供一种基于微内核加插件式的软件架构方法，能应对软件系统不断变化的开发需求，保证系统的扩展性、灵活性和可维护性。

技术方案：本发明所述的一种基于微内核加插件式的软件架构方法，包括以下步骤：

(1)构建一个基础的框架应用程序，用以加载插件并且为插件的运行提供必要的执行环境；

(2)制定插件的命名规则，规范插件的命名及内容，确保不同开发者的插件命名的惟一性；

(3)制定插件的物理组织规则，插件以压缩包的形式进行打包，打包的内容有插件名字的描述，同时也包括动态库、资源文件及属性描述文件等，每个插件具有独立的模块组织；

(4)构建插件生命周期层，对组织好的插件进行整个生命周期进行管理，包括插件的安装、启动、停止、更新和卸载过程；

(5)构建插件服务层，作为插件之间交互的桥梁，服务层与插件的生命周期层紧密结合，形成一个动态协作模型，包括服务注册、服务定位、服务更新、服务事件通知；各个插件将其向其他插件提供的功能以服务的形式注册到软件框架提供的服务中心，其他插件则在软件框架的服务中心查找所需的服务；

(6)构建主题事件服务层：基于QT的信号槽机制和服务层，实现事件的异步发送；插件主动先向软件框架订阅某一主题事件时，需传入响应槽函数的签名，当对应的主题信号发出后，所有订阅此主题的槽函数将会被调用，同时事件消息会作为参数传入槽函数，其所属的插件将对这事件消息进行处理；插件在订阅某一主题事件后也可以主动反订阅，则将不会收到事件消息；

(7)根据上述步骤，构建插件容器，同时在插件容器中添加跨进程消息转发功能，提供跨进程统一消息交互服务。

进一步地，步骤(2)所述的插件命名规则如下：

插件命名采用反向域名机制，即名字由多个以“.”分隔的子部分组成，第一部分是机构或厂商的顶级域名，第二部分是机构或公司的域名，剩下的部分则是由厂商或者机构自由地分配，域名中的字符采用大小写字母字符、数字以及中横线，命名的最后一部分是以下划线连接的版本信息，版本信息由主版本号、副版本号以及修订号三部分组成。

进一步地，步骤(2)所述的插件内容主要包括插件内容将由动态链接库、清单文件、数据文件、配置文件和资源文件。

进一步地，所述步骤(3)包括以下步骤：

(31)以可执行环境为基础开发插件自动打包工具，将插件内容压缩至同一个压缩包内，形成扩展名为“bndl”的压缩文件；

(32)提供接口读取插件数据，包括将提取插件文件和解析插件数据；

(33)基于可执行环境层提供跨平台的类加载器，以加载实现插件激活器接口的插件激活器类。

进一步地，所述步骤(4)包括以下步骤：

(41)设计文件组织结构，规定插件的部署位置，只有部署到指定位置的插件才会被默认加载；

(42)利用模块层中的数据读取接口，从插件压缩包提取清单文件和属性文件，对插件进行必要的初始化操作；

(43)启动插件前，分析插件依赖关系，先启动依赖的插件；

(44)启动插件时，利用模块层中的类加载器，加载插件激活器类，调用其中的“start”方法，启动插件；

(45)利用模块层中的类加载器，加载插件激活器类，调用其中的“stop”方法，停止插件；

(46)插件不再使用时，卸载插件和与之相关的资源。

进一步地，步骤(5)所述的服务注册包括单例和工厂两种注册模式；所述单例注册模式须使服务接口继承自服务基类；其主要接口函数声明如下：

virtual const std::type_info&type()const

返回对象的类型信息；

virtual bool isA(const std::type_info&otherType)const

判断对象是否为指定类型的子类；

所述工厂服务注册是服务提供者将服务工厂注册到框架内，服务消费者可以通过工厂获取多个服务实例，工厂服务需继承工厂服务基类，其主要接口函数如下：

ServiceRegistration registerService(const cppString&clazzes,Service::Ptr service,const cppDictionary&properties＝cppDictionary())

注册服务，传入参数分别为服务的唯一ID、服务本身的指针、服务的属性；

ServiceReference getServiceReference(const cppString&clazze)

通过服务的唯一ID获取服务引用；

Service::Ptr getService(const ServiceReference&reference)

通过服务的引用获取服务本身的指针。

进一步地，所述步骤(7)工作过程如下：

软件框架作为主进程，另一软件框架作为插件容器，它们同时具有插件管理和服务管理的能力，插件容器只有跨进程交互服务功能，而主进程框架提供更多的核心服务功能；在单一进程中，当A插件订阅了某一主题事件，其他插件若想发送事件给A插件，则需调用发送同一主题事件的接口，A插件才能收到事件消息；但在跨进程时，主进程框架和插件容器将使用不同的主题事件进行消息发送和接收，从而向外暴露统一的接口进行消息发送和消息接收，实现了插件无论部署在子进程或者是在子进程都调用同样的接口进行消息发送和接收。

有益效果：与现有技术相比，本发明的有益效果：1、该软件架构方法参考面向JAVA的动态模型系统OSGI(Open Service Gateway Initiative)，具有降低系统复杂、提高功能复用性、简单小巧易于部署、插件可动态更新等特点；2、该软件架构方法建立在动态插件模型的基础之上，在插件的组织结构、插件的形式、框架对插件的生命周期管理及插件之间的交互提出了一套具体实施方法，一定程度上弥补了基于C/C++语言插件框架架构方法较少的不足；3、该软件架构方法不仅适用于windows平台，也同时适用于linux平台，其可执行环境层采用C/C++ 标准库和名为POCO的跨平台C++开源核心库，屏蔽上层对操作系统API的依赖，基于此实现的功能在不同平台具有通用性；4、提供基于主题事件服务的跨进程消息交互机制，解决单一框架中插件过多，内存占用过高等问题。

附图说明

图1为基于微内核加插件式的软件架构图；

图2为插件的组成图；

图3为插件的组织结构图；

图4为插件的生命周期状态变化图；

图5为服务功能原理图；

图6为主题事件的发布与订阅图；

图7为主题事件的发送与接收图；

图8为跨进程统一消息交互图。

具体实施方式

下面结合附图对本发明作进一步详细说明：

本发明提供一种基于微内核加插件式的软件架构方法，软件架构如图1所示，具体包括以下步骤：

1、构建一个基础的框架应用程序，用以加载插件并且为插件的运行提供必要的执行环境。跨平台可执行环境层采用C/C++标准库和名为POCO的跨平台 C++开源核心库，向上层模块提供与平台无关的底层功能，包括文件系统访问、动态库加载、通知和事件、日志、XML解析、配置数据处理等)、多种工具类和功能函数。

2、制定插件的命名规则，规范插件的命名及内容。

插件命名采用反向域名机制，即名字由多个以“.”分隔的子部分组成，第一部分是机构或厂商的顶级域名，第二部分是机构或公司的域名，剩下的部分则是由厂商或者机构自由地分配，域名中的字符采用大小写字母字符、数字以及中横线，命名的最后一部分是以下划线连接的版本信息，版本信息由主版本号、副版本号以及修订号三部分组成(如“com.cetc.samples.webpage_1.0.0.bndl”)，包括了插件的各类开发信息。

插件内容将由动态链接库、清单文件、数据文件、配置文件和资源文件等组成，如图2所示。

这里需规范插件识别接口和清单文件，宿主程序在启动和停止插件时，识别接口就会进行调用，通过对插件清单文件的解析和接口的识别，宿主程序才能加载这个插件。

识别接口包含在继承并且实现插件激活器接口的插件激活器类中，它是插件在启动或者关闭时进行必要操作的入口点。声明如下：

virtual void start(BundleContext::Ptr pContext)

插件启动过程中，在插件所有的依赖插件启动后，框架会调用start函数。

virtual void stop(BundleContext::Ptr pContext)

插件停止过程中，框架会调用stop函数。

其中BundleContext是插件上下文，它是插件与软件框架进行交互的媒介，每一个插件独占一个插件上下文，在插件激活器的start函数和stop函数中插件上下文的指针被传递给插件。通过插件上下文，插件可以实现获取本插件指针、获取配置属性、注册各类事件、注册服务、获取服务、查找其他插件等操作。此外插件中可以不包含继承并实现了插件激活器接口的类，在这种情况下，插件的作用通常是为其他插件提供必要的动态运行库。

插件的清单文件包含软件框架加载插件需要的插件信息，其内容包括 Manifest-Version，该属性描述文件该清单文件所采用的格式的版；Bundle-Nam，该属性描述插件的名称；Bundle-Vendor，该属性描述插件的版本信息； Bundle-Copyright，该属性描述该插件的著作权信息，仅仅用来显示； Bundle-SymbolicName，该属性描述插件不带有任何版本信息别名； Bundle-Version，该属性描述插件的版本信息；Bundle-Activator，该属性描述该插件实现插件激活器类接口的类的全名称；Bundle-RunLevel，该属性描述该插件的启动顺序；Bundle-LazyStart，该属性描述该插件是否随着应用程序的启动而自启动，默认为false，即自启动，如果设置为true；Require-Bundle，该属性描述该插件运行所依赖的其他插件列表，所依赖的插件包括插件的版本信息。

3、制定插件的物理组织规则，插件以压缩包的形式进行打包，打包的内容有插件名字的描述，同时也包括动态库、资源文件及属性描述文件等，每个插件具有独立的模块组织。

组织插件时使用后缀名为bndl压缩包方式存储插件。插件文件以层次的目录结构进行物理存储，其必须包含一个“META-INF”的子目录，该目录下包含插件的清单文件manifest.mf，以及一些可选的文件(如插件签名所需要的文件)，清单文件的内容是插件的属性文件(bundle.properities)中配置属性的提取。“bin”目录包含共享库形式的可执行二进制程序，其中根据不同的系统结构建立不同的子目录，子目录由操作系统名称以及处理器结构两层目录构成，具体的可执行程序包含在子目录中，如“bin/Windows_NT/IA32”、“bin/Linux/i386”。共享库文件的命名规则遵循插件的命名规则。插件文件最终以扩展名为“bndl”的Zip 格式文件进行压缩存储，最终形式如图3所示。

确定插件的组织形式后，将按照下述步骤构建模块层。

1)以可执行环境为基础开发插件自动打包工具，将插件内容压缩至同一个压缩包内，形成扩展名为“bndl”的压缩文件。

2)提供接口读取插件数据，包括将提取插件文件和解析插件数据。

3)基于可执行环境层提供跨平台的类加载器，以加载实现插件激活器接口的插件激活器类。

4、构建插件生命周期层，对组织好的插件进行整个生命周期进行管理，包括插件的安装、启动、停止、更新和卸载过程。规范插件的生命周期，包括 INSTALLED(已安装)、RESOLVED(已解析)、STARTING(启动中)、ACTIVE (激活)、STOPPING(停止中)和UNINSTALLED(已卸载)等，如图4。生命周期模块层的功能设计和开发将主要围绕这些过程展开，包括下述功能：

1)设计文件组织结构，规定插件的部署位置，只有部署到指定位置的插件才会被默认加载。

2)利用模块层中的数据读取接口，从插件压缩包提取清单文件和属性文件，对插件进行必要的初始化操作。

3)启动插件前，分析插件依赖关系，先启动依赖的插件。

4)启动插件时，利用模块层中的类加载器，加载插件激活器类，调用其中的“start”方法，启动插件。

5)利用模块层中的类加载器，加载插件激活器类，调用其中的“stop”方法，停止插件。

6)插件不再使用时，卸载插件和与之相关的资源。

5、构建插件服务层。作为插件之间交互的桥梁，服务层定义了一个和生命周期层紧密结合的动态协助模型，其原理如图5。框架提供了服务的注册中心，功能包括服务注册、服务定位、服务更新、服务事件通知；各个插件将其向其他插件提供的功能以服务的形式注册到软件框架提供的服务中心，其他插件则在软件框架的服务中心查找所需的服务。服务提供者将服务描述和服务本身注册到框架；服务使用者通过服务的唯一Id从框架的注册中心获取服务本身。

1)服务注册分为单例和工厂两种注册模式。单例服务是指在框架内只有一个服务实例，在实现这类服务时，须使服务接口继承自服务基类(Service)，其主要接口函数声明如下：

virtual const std::type_info&type()const

返回对象的类型信息。

virtual bool isA(const std::type_info&otherType)const

判断对象是否为指定类型的子类。

工厂服务是指服务提供者将服务工厂注册到框架内，服务消费者可以通过工厂获取多个服务实例，工厂服务需继承工厂服务基类(ServiceFactory)，其主要接口函数如下：

virtual Service::Ptr createService()

创建服务。

这两种方式都通过插件上下文(BundleContext)类提供的接口注册到软件框架中。

软件框架通过插件激活器的start函数和stop函数将插件上下文的指针传递给插件，插件通过插件上下文注册、获取和更新服务，相关接口函数如下：

ServiceRegistration registerService(const cppString&clazzes,Service::Ptr service,const cppDictionary&properties＝cppDictionary())

2)服务定位，传入参数分别为服务的唯一ID、服务本身的指针、服务的属性。

ServiceReference getServiceReference(const cppString&clazze)

通过服务的唯一ID获取服务引用。

Service::Ptr getService(const ServiceReference&reference)

通过服务的引用获取服务本身的指针。

3)服务更新及通知

建立服务通知及更新机制，服务使用者通过框架监听服务事件，当服务提供者更新服务时，服务使用者重新获取更新的服务。

6、构建主题事件服务层：基于QT的信号槽机制和服务层，实现事件的异步发送；插件主动先向软件框架订阅某一主题事件时，需传入响应槽函数的签名，当对应的主题信号发出后，所有订阅此主题的槽函数将会被调用，同时事件消息会作为参数传入槽函数，其所属的插件将对这事件消息进行处理；插件在订阅某一主题事件后也可以主动反订阅，则将不会收到事件消息。

主题事件服务基于服务层，提供便捷的消息传递途径，其原理及实现见发明内容步骤6。具体实施使用时可分为主题事件发布与订阅、主题事件的发送与接收。

如图6，在第一个流程中，主题事件使用插件A向框架发布“主题A”和注册“主题A事件发送服务”，之后事件接收插件1订阅“主题A”。

如图7，在第一个流程中，任意事件发送插件调用“主题A事件发送服务”，框架将事件发送到订阅了“主题A”的事件接收插件1中。

上述步骤就是典型的使用流程，此外插件也可以发布多种主题和订阅多种主题，在图6和图7中，事件接收插件2就订阅了“主题A”和“主题B”，所以它能接收到这两种主题的事件。

7、构建插件容器，同时在插件容器和主框架中添加跨进程消息转发功能，提供跨进程统一消息交互服务。

提取主框架插件管理、服务管理、主题事件服务功能构建插件容器。主框架与插件容器基于共享内存和主题事件服务实现跨进程统一消息交互。

软件框架作为主进程，另一软件框架作为插件容器，它们同时具有插件管理和服务管理的能力，插件容器只有跨进程交互服务功能，而主进程框架提供更多的核心服务功能。在单一进程中，当A插件订阅了某一主题事件，其他插件若想发送事件给A插件，则需调用发送同一主题事件的接口，A插件才能收到事件消息。但在跨进程时，主进程框架和插件容器将使用不同的主题事件进行消息发送和接收，从而向外暴露统一的接口进行消息发送和消息接收，实现了插件无论部署在子进程或者是在子进程都调用同样的接口进行消息发送和接收。

如图8所示，当任意插件向外发送消息时，只需发送主题B消息，主题B 事件经过主框架与插件容器中进程交互插件处理将统一以主题A事件的形式发送出去，无论是在主框架或是插件容器中的插件，只要订阅了主题A事件，就能接收到事件消息。这样就统一了插件发送和接收消息形式，插件可以自由部署在主框架或插件容器中，实现了插件对部署环境的无感。

Claims (6)

1.一种基于微内核加插件式的软件架构方法，其特征在于，包括以下步骤：

(1)构建一个基础的框架应用程序，用以加载插件并且为插件的运行提供执行环境；

(2)制定插件的命名规则，规范插件的命名及内容，确保不同开发者的插件命名的惟一性；

(3)制定插件的物理组织规则，插件以压缩包的形式进行打包，打包的内容有插件名字的描述，同时也包括动态库、资源文件及属性描述文件，每个插件具有独立的模块组织；

(4)构建插件生命周期层，对组织好的插件进行整个生命周期进行管理，包括插件的安装、启动、停止、更新和卸载过程；

(5)构建插件服务层，作为插件之间交互的桥梁，服务层与插件的生命周期层紧密结合，形成一个动态协作模型，包括服务注册、服务定位、服务更新、服务事件通知；各个插件将其向其他插件提供的功能以服务的形式注册到软件框架提供的服务中心，其他插件则在软件框架的服务中心查找所需的服务；

(6)构建主题事件服务层：基于QT的信号槽机制和服务层，实现事件的异步发送；插件主动先向软件框架订阅某一主题事件时，需传入响应槽函数的签名，当对应的主题信号发出后，所有订阅此主题的槽函数将会被调用，同时事件消息会作为参数传入槽函数，在槽函数中对事件消息进行处理；插件在订阅某一主题事件后主动反订阅，将不会收到事件消息；

(7)根据上述步骤，另外构建插件容器，在插件容器和主框架中添加跨进程消息转发功能，提供跨进程统一消息交互服务；

所述步骤(7)工作过程如下：

软件框架作为主进程，另一软件框架作为插件容器，它们同时具有插件管理和服务管理的能力，插件容器只有跨进程交互服务功能，而主进程框架提供更多的核心服务功能；在单一进程中，当A插件订阅了某一主题事件，其他插件若想发送事件给A插件，则需调用发送同一主题事件的接口，A插件才能收到事件消息；但在跨进程时，主进程框架和插件容器将使用不同的主题事件进行消息发送和接收，从而向外暴露统一的接口进行消息发送和消息接收，实现了插件无论部署在主进程或者是在子进程都调用同样的接口进行消息发送和接收。

2.根据权利要求1所述一种基于微内核加插件式的软件架构方法，其特征在于，步骤(2)所述的插件命名规则如下：

插件命名采用反向域名机制，即名字由多个以“.”分隔的子部分组成，第一部分是机构或厂商的顶级域名，第二部分是机构或公司的域名，剩下的部分则是由厂商或者机构自由地分配，域名中的字符采用大小写字母字符、数字以及中横线，命名的最后一部分是以下划线连接的版本信息，版本信息由主版本号、副版本号以及修订号三部分组成。

3.根据权利要求1所述一种基于微内核加插件式的软件架构方法，其特征在于，步骤(2)所述的插件内容主要包括插件内容将由动态链接库、清单文件、数据文件、配置文件和资源文件。

4.根据权利要求1所述的一种基于微内核加插件式的软件架构方法，其特征在于，所述步骤(3)包括以下步骤：

(31)以可执行环境为基础开发插件自动打包工具，将插件内容压缩至同一个压缩包内，形成扩展名为“bndl”的压缩文件；

(32)提供接口读取插件数据，包括将提取插件文件和解析插件数据；

(33)基于可执行环境层提供跨平台的类加载器，以加载实现插件激活器接口的插件激活器类。

5.根据权利要求1所述的一种基于微内核加插件式的软件架构方法，其特征在于，所述步骤(4)包括以下步骤：

(41)设计文件组织结构，规定插件的部署位置，只有部署到指定位置的插件才会被默认加载；

(42)利用模块层中的数据读取接口，从插件压缩包提取清单文件和属性文件，对插件进行初始化操作；

(43)启动插件前，分析插件依赖关系，先启动依赖的插件；

(44)启动插件时，利用模块层中的类加载器，加载插件激活器类，调用其中的“start”方法，启动插件；

(45)利用模块层中的类加载器，加载插件激活器类，调用其中的“stop”方法，停止插件；

(46)插件不再使用时，卸载插件和与之相关的资源。

6.根据权利要求1所述一种基于微内核加插件式的软件架构方法，其特征在于，步骤(5)所述的服务注册包括单例注册和工厂服务注册两种注册模式；所述单例注册模式须使服务接口继承自服务基类；其主要接口函数声明如下：

virtual const std::type_info&type()const

返回对象的类型信息；

virtual bool isA(const std::type_info&otherType)const

判断对象是否为指定类型的子类；

所述工厂服务注册是服务提供者将服务工厂注册到框架内，服务消费者通过工厂获取多个服务实例，工厂服务需继承工厂服务基类，其主要接口函数如下：

ServiceRegistration registerService(const cppString&clazzes,Service::Ptrservice,const cppDictionary&properties＝cppDictionary())

注册服务，传入参数分别为服务的唯一ID、服务本身的指针、服务的属性；

ServiceReference getServiceReference(const cppString&clazze)

通过服务的唯一ID获取服务引用；

Service::Ptr getService(const ServiceReference&reference)

通过服务的引用获取服务本身的指针。

Images