插件加载方法及系统 技术领域
本发明涉及计算机应用软件技术领域,尤其涉及一种插件加载方法及系
统。
背景技术
随着网络的普及,应用类软件进入了高速发展期,对于业务功能的需求变
得更加的多样。因此,系统的兼容性与易扩展性变更尤为重要。为保证系统的
这一特性,将系统平台化,业务模块插件化已经成为了一种较为普遍的架构方
式。
平台化架构方式是指系统基础平台提供基本的、公共的功能服务。系统的
业务模块以插件的方式存在,插件还包括了系统的第三方插件。系统根据具体
需求,能够选择加载、卸载各个插件。通过系统基础平台实现对各个插件的控
制、调用。当前常用的插件加载方式,插件与平台系统会存在依赖树关系,没
有真正的将业务插件独立化,同时对系统的第三方插件也不能保证良好的兼容
性。
当前较为通用的插件加载方式,在加载时,通常会使用到其开发语言的特
性,或在数据结构定义上,未能完全脱离平台限制,未能实现对业务插件的独
立化或者加载方式依赖于开发语言,这些均成为了亟需解决的难题。
发明内容
本发明的目的在于解决未能实现对业务插件独立化及加载方式依赖于开
发语言等问题而提出的一种插件加载方法及系统。
为了实现以上发明目的,本发明采取的技术方案如下:一种插件加载方法,
包括至少一个业务插件和统一平台,步骤如下:
S1:业务插件按照统一平台的接口要求进行插件配置文件定义和启动脚本
配置;
S2:统一平台通过扫描插件配置文件,获取业务插件启动所需的描述信息;
S3:统一平台初始化完成后,调用各个业务插件对应的脚本文件,通过脚
本文件完成对业务插件的加载和启动;
S4:各个业务插件根据需要通过统一平台的接口获取公共信息数据。
作为优选:步骤S1中,所述的插件配置文件定义的信息包括:业务插件
名称、版本、描述信息及入口点脚本信息。
作为优选:步骤S1中,所述的启动脚本配置如下:在业务插件的入口点
脚本至少包含初始化、启动、停止、重启和查看插件状态的接口。
作为优选:统一平台支持各业务插件在配置文件中定义对应组件的启动级
别,统一平台在启动时按照启动级别从高到低依次进行加载,统一平台在停止
时按照启动级别从低到高依次进行卸载。
作为优选:步骤S4中所述的接口是远程方法调用RMI接口。
为了解决上述问题,本发明还提出了一种系统,包括至少一个业务插件和
统一平台,
所述业务插件包括配置模块,所述配置模块用于按照统一平台的接口要求
进行插件配置文件定义和启动脚本配置;并通过统一平台的接口获取公共信息
数据;
所述统一平台包括扫描模块和脚本调用模块,所述扫描模块用于扫描插件
配置文件,获取业务插件启动所需的描述信息;所述脚本调用模块用于在统一
平台初始化完成后,调用各个业务插件对应的脚本文件,完成对业务插件的加
载和启动。
作为优选:所述配置模块具体包括插件配置模块和脚本配置模块;所述插
件配置模块用于在插件配置文件中定义的信息包括插件名称、版本、描述信息
及入口点脚本信息;所述脚本配置模块用于在业务插件的入口点脚本完成初始
化、启动、停止、重启和查看插件。
作为优选:所述统一平台还包括启动级别模块,启动级别模块用于各业务
插件在配置文件中定义对应组件的启动级别。
作为优选:所述的接口是远程方法调用RMI接口。
作为优选:所述的接口是JAVA消息服务JMS接口或者即时消息接口。
本发明的有益效果:为适应当前系统业务需求多变,将各个功能包装为独
立插件的方式能够有效的提高系统扩展性与维护性,本发明通过脚本的方式加
载、启动插件,使得插件的加载过程更加简明,加载方式更加灵活且易于维护。
具体有益效果如下:
1.因为是基于脚本启动,加载过程更加清晰,且易于扩充;
2.各个业务插件均能够独立运行,不存在强依赖树关系,使得各个插件更
加易于维护;
3.具有良好的兼容性,因为脚本语言本身的特点,使得系统能够更加容易
实现对三方插件的兼容和扩展。
附图说明
图1为本发明的系统框架结构示意图。
具体实施方式
为使本发明的目的、技术方案及优点更加清楚明白,以下参照附图并举实
施例,对本发明做进一步详细说明。
一种插件加载方法,包括至少一个业务插件和统一平台,步骤如下:
S1:业务插件按照统一平台的接口要求进行插件配置文件定义和启动脚本
配置;
S2:统一平台通过扫描插件配置文件,获取业务插件启动所需的描述信息;
S3:统一平台初始化完成后,调用各个业务插件对应的脚本文件,通过脚
本文件完成对业务插件的加载和启动;
S4:各个业务插件根据需要通过统一平台的接口获取公共信息数据。
步骤S1中,所述的插件配置文件定义的信息包括:业务插件名称、版本、
描述信息及入口点脚本信息。
步骤S1中,所述的启动脚本配置如下:在业务插件的入口点脚本至少包
含初始化、启动、停止、重启和查看插件状态的接口。
统一平台支持各业务插件在配置文件中定义对应组件的启动级别,统一平
台在启动时按照启动级别从高到低依次进行加载,统一平台在停止时按照启动
级别从低到高依次进行卸载。
步骤S4中所述的接口是远程方法调用RMI接口。
为了解决上述问题,本发明还提出了一种系统,包括至少一个业务插件和
统一平台,
所述业务插件包括配置模块,所述配置模块用于按照统一平台的接口要求
进行插件配置文件定义和启动脚本配置;并通过统一平台的接口获取公共信息
数据;
所述统一平台包括扫描模块和脚本调用模块,所述扫描模块用于扫描插件
配置文件,获取业务插件启动所需的描述信息;所述脚本调用模块用于在统一
平台初始化完成后,调用各个业务插件对应的脚本文件,完成对业务插件的加
载和启动。
所述配置模块具体包括插件配置模块和脚本配置模块;所述插件配置模块
用于在插件配置文件中定义的信息包括插件名称、版本、描述信息及入口点脚
本信息;所述脚本配置模块用于在业务插件的入口点脚本完成初始化、启动、
停止、重启和查看插件。
所述统一平台还包括启动级别模块,启动级别模块用于各业务插件在配置
文件中定义对应组件的启动级别。
所述的接口是远程方法调用RMI接口。
所述的接口是JAVA消息服务JMS接口或者即时消息接口。
如图1所示,RMI(Remote Method Invocation,远程方法调用)是一种
实现远程过程调用的应用程序编程接口,其中业务插件与统一平台通信不一定
需要使用RMI接口,也可通过JMS(Java Message Service Java,Java消息
服务)、即时消息接口等其他进程间信息交互方式。
本发明是各个业务插件按照统一平台的接口要求进行插件配置文件定义
和启动脚本配置,在启动脚本文件中实现基本的启动、停止、初始化等控制接
口用于平台加载调用,从而将各个业务插件包装为能够独立运行启动的服务,
各个插件均为独立进程。
统一平台与各业务插件的关系为松耦合的独立进程关系。统一平台与业务
插件,插件和插件之间应尽可能保持相互独立、不受开发语言及插件本身的运
行框架的限制。
具体实施例如下:
如图1所示,统一平台主用是完成各业务功能插件的加载、控制,同时提
供各项公共服务,如授权、SSO(Single Sign On,单点登录)、页面菜单、样
式控制、资源服务等。
统一平台自身启动完成后,将扫描插件配置文件,获取到四个业务插件的
描述信息,描述信息中包括插件名称、插件启动脚本文件路径、插件加载优先
级等信息。统一平台根据插件优先级依次加载各个插件。具体加载过程如下:
1)根据插件名称与启动脚本文件路径调用插件启动接口;
2)插件启动完成后,统一平台调用启动脚本文件中的初始化接口;
3)插件通过RMI接口,向平台请求自身初始化所需数据,完成插件加载。
具体流程如下:
S1:统一平台通过扫描业务插件配置文件,获取业务插件启动所需的描述
信息,具体包括插件名称、启动脚本路径、权限控制(license)名称、数据
库初始化文件路径等信息,以完成各个插件在统一平台的注册;
S2:统一平台初始化完成后,调用各个插件对应的脚本文件,通过脚本文
件完成对业务插件的加载和启动;
S3:各个业务插件可根据需要通过RMI接口从统一平台获取公共信息数据。
要求各插件开发时必须按照统一平台的接口要求进行插件配置文件定义
和启动脚本配置。
此基本要求包括:
(1)插件配置文件定义:插件配置文件定义的信息包括:当前业务插件
名称、版本、描述信息及入口点脚本等必要信息;
(2)启动脚本配置:在插件的入口点脚本应至少包含初始化、启动、停
止、重启、查看插件状态的接口;
(3)为了正确处理好各业务插件启动顺序,统一平台支持各业务插件在
配置文件中定义对应插件的启动级别,统一平台在启动时会按照启动级
别从高到低依次进行加载,统一平台在停止时会按照启动级别从低到高
依次进行卸载。
本领域的普通技术人员将会意识到,这里所述的实施例是为了帮助读者理
解本发明的实施方法,应被理解为本发明的保护范围并不局限于这样的特别陈
述和实施例。本领域的普通技术人员可以根据本发明公开的这些技术启示做出
各种不脱离本发明实质的其它各种具体变形和组合,这些变形和组合仍然在本
发明的保护范围内。