CN114443132A - 一种基于OSGi的嵌入式服务治理方法 - Google Patents

Abstract

本申请提供了一种基于OSGi的嵌入式服务治理方法，属于计算机的技术领域，具所述治理方法包括将服务作为可执行程序，用统一封装方法并暴露统一接口屏蔽服务操作上的区别并在封装内部保留服务的差异；服务运行过程中系统通过每个服务的相同接口进行服务的状态管理，使得非必要服务可以在不影响整个系统功能的前提下停止或挂起；在分布式系统中，各个节点可以随时向中心节点提出服务申请，中心节点收到消息并将服务予以回传。通过本申请的处理方案，实现服务的高度可迁移性和统一化管理。

Description

一种基于OSGi的嵌入式服务治理方法

技术领域

本申请涉及计算机技术的领域，尤其是涉及一种基于OSGi的嵌入式服务治理方法。

背景技术

在嵌入式软件开发过程中，硬件底层、操作系统、应用程序等往往都是定制级开发的，这导致了软件与硬件的高度耦合。在既定开发模式的情况下，嵌入式应用都与操作系统高度相关，但是随着计算机技术的发展以及不同场景的需求下，程序需要进行一定规模的迁移和扩展。以往开发模式下设计完成的程序无疑对程序的可迁移性和可扩展性造成了巨大的影响，往往需要对程序进行极大的改动并进入一个繁冗的测试周期。这造就了嵌入式领域应用服务可迁移性差、程序可复用率低以及软件成本高等诸多不良影响。

发明内容

有鉴于此，本申请提供一种基于OSGi的嵌入式服务治理方法，解决了现有技术中的问题，实现服务的高度可迁移性和统一化管理。

本申请提供的一种基于OSGi的嵌入式服务治理方法采用如下的技术方案：

一种基于OSGi的嵌入式服务治理方法，将所有服务进行标准化封装并在服务标准化的基础上对于服务进行管理和操作，所述治理方法包括：

将服务作为可执行程序，用统一封装方法并暴露统一接口屏蔽服务操作上的区别并在封装内部保留服务的差异；

服务运行过程中系统通过每个服务的相同接口进行服务的状态管理，使得非必要服务可以在不影响整个系统功能的前提下停止或挂起；

在分布式系统中，各个节点可以随时向中心节点提出服务申请，中心节点收到消息并将服务予以回传。

可选的，封装包括描述文件、可执行程序和资源文件，所述描述文件记录该服务的具体信息，可执行程序为对应服务的实体，资源文件为可执行程序在运行过程中所依赖的外部资源文件。

可选的，通过访问统一暴露的接口，对服务的状态进行管理和转换，通过接口实现服务的基本状态包括未安装态、已安装态、已解析态、启动态、停止态、激活态。

可选的，节点在有新任务到达时，指定使用系统下的对应服务，当所述分布式系统所持有服务不足以满足新任务需求时，节点将对中心节点提出服务申请，报送所需服务。

可选的，中心节点收到消息并将服务予以回传具体包括：中心节点在任何时刻都可能收到任意节点的服务申请，这些申请可能是单个服务ID，也可能是批量服务ID，中心节点将记录这些申请信息和平台信息，并根据ID将查找到的服务ID按批次依次回传给对应节点。

可选的，转换服务状态具体包括，非必要依赖性的服务间转换状态，在保证系统正常运行的前提下，根据需要停止对应的非必要服务进行维护扩展后再投入使用。

可选的，每个任务在执行完毕之后系统对当非必要的服务进行关闭或挂起注销。

可选的，服务回传给对应节点后，节点在接收到中心节点传输的标准化封装的缺省服务后，首先对服务完整性进行验证，验证结束后即直接投入系统解析使用。

综上所述，本申请包括以下有益技术效果：

1、本申请将嵌入式系统下的服务进行了统一化的封装及管理，在服务封装完成注册后，服务注销删除前，该服务的停止启动以及提供服务都被一对一管控，相比于现有的适配型开发模式，这种开发模式屏蔽了嵌入式环境下的各类系统差异，使得服务被提取为可执行程序，只要对编程语言都支持，并且同样使用该系统就可以直接进行软件迁移，在服务执行过程中，服务的状态也被实时监控，使得软件开发、测试、维护的成本大幅度降低；

2、本申请结合当前嵌入式系统网络互联的常态性特点，将服务治理方法与分布式系统相结合，设计一个主节点负责监控管理所有节点的所有服务，其他节点各司其职，通过对主节点操作即可协同所有节点完成任务；

3、基于OSGi思想开发的各个应用服务之间除特殊指定外没有任何交集，这也使得在不关闭整个系统的情况下，停止某些应用服务进行调试改写变得十分简便，大大降低了软件测试维护成本，提高了服务的可扩展性。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1为本申请实施例的分布式服务治理系统整体架构图。

具体实施方式

下面结合附图对本申请实施例进行详细描述。

以下通过特定的具体实例说明本申请的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本申请的其他优点与功效。显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。本申请还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本申请的精神下进行各种修饰或改变。需说明的是，在不冲突的情况下，以下实施例及实施例中的特征可以相互组合。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

要说明的是，下文描述在所附权利要求书的范围内的实施例的各种方面。应显而易见，本文中所描述的方面可体现于广泛多种形式中，且本文中所描述的任何特定结构及/或功能仅为说明性的。基于本申请，所属领域的技术人员应了解，本文中所描述的一个方面可与任何其它方面独立地实施，且可以各种方式组合这些方面中的两者或两者以上。举例来说，可使用本文中所阐述的任何数目个方面来实施设备及/或实践方法。另外，可使用除了本文中所阐述的方面中的一或多者之外的其它结构及/或功能性实施此设备及/或实践此方法。

还需要说明的是，以下实施例中所提供的图示仅以示意方式说明本申请的基本构想，图式中仅显示与本申请中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。

另外，在以下描述中，提供具体细节是为了便于透彻理解实例。然而，所属领域的技术人员将理解，可在没有这些特定细节的情况下实践所述方面。

本申请实施例提供一种基于OSGi的嵌入式服务治理方法。

一种基于OSGi的嵌入式服务治理方法，将所有服务进行标准化封装并在服务标准化的基础上对于服务进行管理和操作，所述治理方法包括：

将服务作为可执行程序，用统一封装方法并暴露统一接口屏蔽服务操作上的区别并在封装内部保留服务的差异，达到标准化服务治理的前提条件。

服务运行过程中系统通过每个服务的相同接口进行服务的状态管理，使得非必要服务可以在不影响整个系统功能的前提下停止或挂起；

在分布式系统中，各个节点可以随时向中心节点提出服务申请，中心节点收到消息并将服务予以回传。

应用服务在实际运行过程中，当具体任务下发时，可以根据统一接口对服务进行批量式生命周期管控；

应用服务在实际运行过程中，当有新服务创建并且该服务能够运行依赖于其他服务的具体功能时，系统将记录该依赖关系并进行逻辑上的捆绑，限制可能会产生服务异常情况的被依赖服务关闭。

标准化的应用服务可以在不同的平台进行任意迁移，由于封装规则相同，任意平台接收到按照标准封装的任意服务都可以直接进行解析使用。

服务封装过程中，通过访问接口，获得空服务模板，将自己编写的可执行程序填写后直接进行服务注册管理。

封装包括描述文件、可执行程序和资源文件，所述描述文件记录该服务的具体信息，可执行程序为对应服务的实体，资源文件为可执行程序在运行过程中所依赖的外部资源文件，如MP3、MP4等格式文件。

为了使系统能精确识别每一个服务且方便开发人员快速识别每个服务及其功能，在服务封装时将服务对应的描述统一进行封装，封装描述包括服务的版本、名称、描述以及其他开发人员自定义的描述。

通过访问统一暴露的接口，对服务的状态进行管理和转换，通过接口实现服务的基本状态包括未安装态、已安装态、已解析态、启动态、停止态、激活态。服务在注册完成后，系统可以对其进行生命周期管理，任意一个服务都有6种基本状态，分别为未安装态、已安装态、已解析态、启动态、停止态、激活态。转换服务状态具体包括，非必要依赖性的服务间转换状态，在保证系统正常运行的前提下，根据需要停止对应的非必要服务进行维护扩展后再投入使用。

服务的描述文件中如果指定了对其他服务的依赖关系，在服务注册后，系统会同时将这种依赖关系进行树形构建，服务的关闭必须按照数据结构中规定的关闭顺序。

系统在运行过程中，通过为每一个服务创建实时对象的方法来对所有服务进行监控，主要监控的内容包括该服务的状态以及服务运行过程中包括正常和非正常运行的系统反馈。

在分布式系统中，各个节点可以随时向中心节点提出服务申请，中心节点收到消息并将服务予以回传，具体包括：节点在有新任务到达时，指定使用系统下的对应服务，当所述分布式系统所持有服务不足以满足新任务需求时，节点将对中心节点提出服务申请，报送所需服务ID；每个任务在执行完毕之后系统对当非必要的服务进行关闭或挂起注销。中心节点收到消息并将服务予以回传具体包括：中心节点在任何时刻都可能收到任意节点的服务申请，这些申请可能是单个服务ID，也可能是批量服务ID，中心节点将记录这些申请信息和平台信息，并根据ID将查找到的服务ID按批次依次回传给对应节点。服务回传给对应节点后，节点在接收到中心节点传输的标准化封装的缺省服务后，首先对服务完整性进行验证，验证结束后即直接投入系统解析使用。

本申请面向的是基于嵌入式系统的分布式环境，在中心节点部署所有类型的服务。为了满足服务高可用性和系统轻量级的要求，除中心节点外的节点中正在运行并且占用内存的服务均为必须运行的服务，当节点有新任务需要执行且当前系统正在运行的服务不足以满足任务需求时，节点会向中心节点请求缺省服务以加载运行满足任务需求，在任务执行完成后，根据具体服务需求情况，不需要的服务予以自动挂起或关闭注销。

如图1所示，分布式系统的服务迁移过程具体如下：

步骤1、中心节点配备所有服务包并对其他所有节点建立连接进行远程监控；

步骤2、节点机器启动；

步骤3、将节点中存在的服务进行统一化封装并存放于系统中；

步骤4、将节点中任务所需服务予以启动；

步骤5、节点使用当前启动服务执行节点任务；

步骤6、节点到达新任务，当前服务无法满足新任务需求；

步骤7、缺省服务节点向中心节点报送缺少服务id发起服务申请；

步骤8、中心节点将缺省服务节点发送的服务id记录并查找，将查找到的服务包发送至对应节点；

步骤9、对应节点接收到统一标准化的服务包直接将其放入系统初始化解析使用；

步骤10、在节点任务执行结束后，将非必要服务挂起。

当节点中的任务正常执行时，每个节点重复步骤3至步骤5以满足任务服务需要，而步骤3至步骤5需要打包什么服务以及完成任务需要启动什么服务均由程序自己确定。当有任意任务执行完成时，都会进行步骤10，将不必要服务挂起来节省系统资源。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (8)

1.一种基于OSGi的嵌入式服务治理方法，其特征在于，将所有服务进行标准化封装并在服务标准化的基础上对于服务进行管理和操作，所述治理方法包括：

将服务作为可执行程序，用统一封装方法并暴露统一接口屏蔽服务操作上的区别并在封装内部保留服务的差异；

服务运行过程中系统通过每个服务的相同接口进行服务的状态管理，使得非必要服务可以在不影响整个系统功能的前提下停止或挂起；

在分布式系统中，各个节点可以随时向中心节点提出服务申请，中心节点收到消息并将服务予以回传。

2.根据权利要求1所述的基于OSGi的嵌入式服务治理方法，其特征在于：封装包括描述文件、可执行程序和资源文件，所述描述文件记录该服务的具体信息，可执行程序为对应服务的实体，资源文件为可执行程序在运行过程中所依赖的外部资源文件。

3.根据权利要求1所述的基于OSGi的嵌入式服务治理方法，其特征在于：通过访问统一暴露的接口，对服务的状态进行管理和转换，通过接口实现服务的基本状态包括未安装态、已安装态、已解析态、启动态、停止态、激活态。

4.根据权利要求1所述的基于OSGi的嵌入式服务治理方法，其特征在于：节点在有新任务到达时，指定使用系统下的对应服务，当所述分布式系统所持有服务不足以满足新任务需求时，节点将对中心节点提出服务申请，报送所需服务。

5.根据权利要求1所述的基于OSGi的嵌入式服务治理方法，其特征在于：中心节点收到消息并将服务予以回传具体包括：中心节点在任何时刻都可能收到任意节点的服务申请，这些申请可能是单个服务ID，也可能是批量服务ID，中心节点将记录这些申请信息和平台信息，并根据ID将查找到的服务ID按批次依次回传给对应节点。

6.根据权利要求3所述的基于OSGi的嵌入式服务治理方法，其特征在于：转换服务状态具体包括，非必要依赖性的服务间转换状态，在保证系统正常运行的前提下，根据需要停止对应的非必要服务进行维护扩展后再投入使用。

7.根据权利要求4所述的基于OSGi的嵌入式服务治理方法，其特征在于：每个任务在执行完毕之后系统对当非必要的服务进行关闭或挂起注销。

8.根据权利要求5所述的基于OSGi的嵌入式服务治理方法，其特征在于：服务回传给对应节点后，节点在接收到中心节点传输的标准化封装的缺省服务后，首先对服务完整性进行验证，验证结束后即直接投入系统解析使用。

Images