CN103607702B - 一种在短信业务中不同平台间进行通讯的方法和系统 - Google Patents

Abstract

本申请公开了一种在短信业务中不同平台间进行通讯的方法，包括：接收预先生成的插件的安装请求，所述插件携带有通信协议的功能代码、安装卸载引导类代码和插件配置文件；获取所述插件并进行校验；判断校验通过时，采用动态加载的方式将所述插件的代码加载到系统运行环境中；读取所述插件配置文件，根据所述配置文件在系统数据库中生成通信协议配置信息；根据所述通信协议配置信息进行不同平台间的通讯。本申请公开的方法在系统运行中动态加载插件，无需暂停短信服务，不影响用户的正常使用。

Description

一种在短信业务中不同平台间进行通讯的方法和系统

技术领域

本申请涉及通信技术领域，更具体地说，涉及一种在短信业务中不同平台间进行通讯的方法和系统。

背景技术

目前国内短信系统开发的门槛相对较低，很多企业的运营系统都是自主研发的，因此对外提供的接口协议也不完全相同。对于一家行业短信运营企业来说，需要经常找同行的短信平台进行对接测试，这就需要在短时间内实现对应的接口协议。现有运营系统主要实现方式为：直接将协议在平台中实现，协议部分代码和平台代码耦合在一起，每次开发新的协议都必须给平台升级，这样短息服务必须暂停，而且会影响系统的稳定性。

发明内容

有鉴于此，本申请提供了一种在短信业务中不同平台间进行通讯的方法和系统，用于解决现有技术中当开发新的协议时必须升级平台，暂停短信服务的问题。

为了实现上述目的，现提出的方案如下：

一种在短信业务中不同平台间进行通讯的方法，包括：

接收预先生成的插件的安装请求，所述插件携带有通信协议的功能代码、安装卸载引导类代码和插件配置文件；

获取所述插件；

对所述插件进行校验；

判断校验通过时，采用动态加载的方式将所述通信协议的功能代码和所述安装卸载引导类代码加载到系统运行环境中；

读取所述插件配置文件，根据所述配置文件在系统数据库中生成通信协议配置信息；

根据所述通信协议配置信息进行不同平台间的通讯。

优选地，所述插件的生成过程具体为：

开发所述通信协议的功能代码；

根据插件规范，开发插件安装卸载引导类代码；

编写插件配置文件；

将所述通信协议的功能代码、所述插件安装卸载引导类和所述插件配置文件编辑并打包成可以安装的插件。

优选地，所述对所述插件进行校验包括：校验所述插件是否符合插件规范和校验所述插件配置文件是否正确。

优选地，还包括：

判断校验不通过时，提示插件安装失败，并显示具体原因。

优选地，所述根据所述通信协议配置信息进行不同平台间的通讯具体为：

建立与所述通信协议对应的通道；

启动所述通道，系统根据所述通信协议配置信息实例化所述通信协议的功能代码；

使用所述通信协议的功能代码接入网关；

进行短信的收发。

优选地，在所述根据所述通信协议配置信息进行不同平台间的通讯之后进一步包括插件卸载过程，所述插件卸载过程具体为：

接收插件卸载请求，所述请求包括插件标识；

检测与所述插件标识对应的插件的状态；

判断所述插件的状态为未使用时，将所述通信协议的功能代码和所述安装卸载引导类代码从所述系统运行环境中卸载；

从所述数据库中删除所述通信协议配置信息；

从插件安装目录中删除所述插件的物理文件。

优选地，还包括：

判断所述插件的状态为使用中时，提示卸载失败，并显示具体原因。

一种在短信业务中不同平台间进行通讯的系统，包括：

请求接收模块，用于接收预先生成的插件的安装请求，所述插件携带有通信协议的功能代码、安装卸载引导类代码和插件配置文件；

插件获取模块，用于获取所述插件；

校验模块，用于对获取的所述插件进行校验，并判断校验是否通过；

配置文件读取模块，用于读取所述配置文件，根据所述配置文件在系统数据库中生成通信协议配置信息；

通讯模块，用于根据所述通信协议配置信息进行不同平台间的通讯。

优选地，还包括：插件生成模块，用于预先生成插件。

优选地，所述校验模块包括：

插件规范校验子模块，用于校验所述插件是否符合插件规范；

插件配置文件校验子模块，用于校验所述插件配置文件是否正确。

从上述的技术方案可以看出，本申请公开的通讯方法通过预先生成与新通讯协议对应的插件，在系统运行时获取该插件，并在校验通过后采用动态加载的方式将插件内的代码文件加载到系统运行环境中，从而使系统支持对应的通信协议，这个过程无需暂停短信服务，不影响用户的正常使用。

附图说明

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

图1为本申请实施例公开的一种在短信业务中不同平台间进行通讯的方法流程图；

图2为本申请实施例公开的另一种在短信业务中不同平台间进行通讯的方法流程图；

图3为本申请实施例公开的一种插件生成方法流程图；

图4为本申请实施例公开的利用插件实现不同平台间通讯的方法流程图；

图5为本申请实施例公开的一种插件卸载过程方法流程图；

图6为本申请实施例公开的另一种插件卸载过程方法流程图；

图7为本申请实施例公开的一种在短信业务中不同平台间进行通讯的系统组成图；

图8为本申请实施例公开的另一种在短信业务中不同平台间进行通讯的系统组成图；

图9为本申请实施例公开的校验模块组成图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有付出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

参见图1，图1为本申请实施例公开的一种在短信业务中不同平台间进行通讯的方法流程图。

如图1所示，该方法包括：

步骤101：接收预先生成的插件的安装请求，所述插件携带有通信协议的功能代码、安装卸载引导类代码和插件配置文件；

具体地，我们可以预先生成一个插件文件，该插件文件是与系统需要支持的通信协议相对应的，换句换说，该插件文件携带有新通信协议的功能代码。并且，根据需要还要在插件内设置安装卸载引导类代码，用于在插件的安装和卸载过程中使用；插件配置文件，用于对该插件进行描述，其中插件配置文件也定义了通信协议的功能代码的协议标识，用于在系统安装插件时使用。

步骤102：获取所述插件；

步骤103：对所述插件进行校验；

具体地，在获取插件之后我们还要对这个插件进行校验，校验的内容可以包括：校验插件是否符合插件规范和校验插件的配置文件是否正确。

步骤104：在判断校验通过时，采用动态加载的方式将所述通信协议的功能代码和所述安装卸载引导类代码加载到系统运行环境中；

具体地，在插件校验通过以后，我们可以采用动态加载的方式将插件内携带的所有代码文件即通信协议的功能代码和安装卸载引导类代码加载到系统运行环境中。通过采用动态加载的方式不需要停止或重启系统服务即可在系统中增加相应的短信协议。

步骤105：读取所述插件配置文件，根据所述配置文件在系统数据库中生成通信协议配置信息；

具体地，这个过程主要是向系统数据库中增加一条记录，用于记录协议标识和通信协议的功能代码之间的对应关系，如：cmpp2对应com.ctc.cmpp2.CMPP2Channel。有了这样一个对应关系系统就可以通过协议标识找到对应的通信协议的功能代码。

步骤106：根据所述通信协议配置信息进行不同平台间的通讯。

本实施例公开的通讯方法通过预先生成与新通讯协议对应的插件，在系统运行时获取该插件，并在校验通过后采用动态加载的方式将插件内的代码文件加载到系统运行环境中，从而使系统支持对应的通信协议，这个过程无需暂停短信服务，不影响用户的正常使用。

参见图2，图2为本申请实施例公开的另一种在短信业务中不同平台间进行通讯的方法流程图。

如图2所示，本实施例的步骤201、202、203、204、206、207分别与上一实施例的步骤101-106相同，本实施例只是在上一实施例的步骤104和步骤105之间增加了步骤205。步骤205：判断校验不通过时，提示插件安装失败，并显示具体原因。具体地，在校验不通过时，我们可以向用户发出提示，显示失败，当然也可以进一步显示失败的具体原因，以便用户解决问题。本实施例的步骤205只是在判断校验失败后的一种处理方式而已，当然还可以不做处理或有其它的处理方式。

参见图3，图3为本申请实施例公开的一种插件生成方法流程图。

如图3所示，该方法包括：

步骤301：开发所述通信协议的功能代码；

具体地，我们可以根据系统需要支持的某种通信协议开发相应的功能代码。

步骤302：根据插件规范，开发插件安装卸载引导类代码；

具体地，按照预先设定的插件规范，开发插件在上传和下载过程中所用到的安装卸载引导类代码。

步骤303：编写插件配置文件；

具体地，配置文件是对插件的一个描述，通信协议的功能代码也是插件的一部分，所以配置文件中也有对通信协议的功能代码的描述，配置文件中针对通信协议的功能代码的描述为协议标识符，例如：cmpp2表示中国移动通信互联网短信网关接口协议。

步骤304：将所述通信协议的功能代码、所述插件安装卸载引导类和所述插件配置文件编辑并打包成可以安装的插件。

本实施中，通过预先开发与某种通信协议相对应的插件代码和编写插件配置文件，最后将代码文件和配置文件编辑打包成可以安装的插件，在系统运行时提供给系统，无需系统暂停短信服务，方便了用户的正常使用。

参见图4，图4为本申请实施例公开的利用插件实现不同平台间通讯的方法流程图。

在实施例一的步骤105完成插件安装之后，具体地步骤106进行通讯的过程可以参见图4：

步骤401：建立与所述通信协议对应的通道；

步骤402：启动所述通道，系统根据所述通信协议配置信息实例化所述通信协议的功能代码；

步骤403：使用所述通信协议的功能代码接入网关；

步骤404：进行短信的收发。

具体地，我们对上述过程做如下解释：通道是在系统中的一个逻辑概念，每个通道必须指定具体的一种短信通信协议，而且一个通道只能指定一种短信通信协议，但是系统中可以存在多条指定相同短信通信协议的通道。系统要使用某一个通道进行短信收发首先需要先启动该通道，启动通道的实质是实例化通信协议的功能代码中定义的类，类实例化后得到相应的对象，通过调用对象提供的方法与短信网关进行连接。通道启动成功后就可以调用实例化过程产生的对象提供的发送短信和接收短信的方法进行短信的收发。

其中，实例化是面向对象的概念。因为只有对象才能被系统使用，所以实例化就是通过使用类创建对象。

参见图5，图5为本申请实施例公开的一种插件卸载过程方法流程图。

如图5所示，该方法包括：

步骤501：接收插件卸载请求，所述请求包括插件标识；

步骤502：检测与所述插件标识对应的插件的状态；

步骤503：判断所述插件的状态为未使用时，将所述通信协议的功能代码和所述安装卸载引导类代码从所述系统运行环境中卸载；

步骤504：从所述数据库中删除所述通信协议配置信息；

步骤505：从插件安装目录中删除所述插件的物理文件。

具体地，插件卸载是指从系统中移除某种短信通信协议的过程，因为在系统中插件是短信通信协议的载体所以只要将插件卸载了，那么对应的短信通信协议也就自动从系统中移除了。

某个插件可以被卸载的前提是插件在系统中没有被使用中，也就是指定使用该短信通信协议的全部通道都处于关闭的状态。

系统接收到插件卸载请求时根据插件标识查找系统中所有使用该标识对应的短信通信协议的通道的状态，如果都处于关闭状态，那么系统就会从其运行环境中移除对应通信协议的功能代码，然后删除系统数据库中对应的通信协议配置信息，最后删除插件的通信协议的功能代码文件、插件安装卸载引导类文件和插件配置文件（即插件物理文件）。当通信协议的功能代码从系统运行环境中移除后系统就无法再实例化通信协议的功能代码了，而之前实例化得到的对象在通道关闭时已经被销毁，无法实例化就无法使用，这样就达到了移除短信通信协议的目的。

如图6，图6为本申请实施例公开的另一种插件卸载过程方法流程图。

本实施例中的步骤601、602、603、605、606分别于上一实施例的步骤501-505相同，本实施例只是在上一实施例的步骤503和步骤504之间增加了步骤604，步骤604：判断所述插件的状态为使用中时，提示卸载失败，并显示具体原因。具体地，在判断插件状态为使用中时，我们可以向用户发出提示，显示失败，当然也可以进一步显示失败的具体原因，以便用户解决问题。本实施例的步骤604只是一种处理方式而已，当然我们还还可以不做处理或有其它的处理方式。

参见图7，图7为本申请实施例公开的一种在短信业务中不同平台间进行通讯的系统组成图。

如图7，包括：

请求接收模块70，用于接收预先生成的插件的安装请求，所述插件携带有通信协议的功能代码、安装卸载引导类代码和插件配置文件；

插件获取模块71，用于获取所述插件；

校验模块72，用于对获取的所述插件进行校验，并判断校验是否通过；

配置文件读取模块73，用于读取所述配置文件，根据所述配置文件在系统数据库中生成通信协议配置信息；

通讯模块74，用于根据所述通信协议配置信息进行不同平台间的通讯。

本实施例公开的通讯系统通过插件获取模块71获取预先生成的插件，在校验模块72校验通过时由配置文件读取模块73根据配置文件在系统数据库中生成通信协议配置信息，从而使系统支持对应的通信协议，这个过程无需暂停短信服务，不影响用户的正常使用。

参见图8，图8为本申请实施例公开的另一种在短信业务中不同平台间进行通讯的系统组成图。

在上一实施例的基础上，本实施例进一步增加了插件生成模块75，用于预先生成所需要安装的插件。

参见图9，图9为本申请实施例公开的校验模块组成图。

校验模块72包括：

插件规范校验子模块721，用于校验所述插件是否符合插件规范；

插件配置文件校验子模块722，用于校验所述插件配置文件是否正确。

通过对插件的规范和配置文件进行校验，当其中一项不符合要求时即停止插件的安装过程，反馈给用户插件安装失败的信息。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (9)

1.一种在短信业务中不同平台间进行通讯的方法，其特征在于，包括：

接收预先生成的插件的安装请求，所述插件携带有通信协议的功能代码、安装卸载引导类代码和插件配置文件；

获取所述插件；

对所述插件进行校验；

判断校验通过时，采用动态加载的方式将所述通信协议的功能代码和所述安装卸载引导类代码加载到系统运行环境中；

读取所述插件配置文件，根据所述配置文件在系统数据库中生成通信协议配置信息；

根据所述通信协议配置信息进行不同平台间的通讯，包括：建立与所述通信协议对应的通道；启动所述通道，系统根据所述通信协议配置信息实例化所述通信协议的功能代码；使用所述通信协议的功能代码接入网关；进行短信的收发。

2.根据权利要求1所述的方法，其特征在于，所述插件的生成过程具体为：

开发所述通信协议的功能代码；

根据插件规范，开发插件安装卸载引导类代码；

编写插件配置文件；

将所述通信协议的功能代码、所述插件安装卸载引导类和所述插件配置文件编辑并打包成可以安装的插件。

3.根据权利要求1所述的方法，其特征在于，所述对所述插件进行校验包括：校验所述插件是否符合插件规范和校验所述插件配置文件是否正确。

4.根据权利要求1所述的方法，其特征在于，还包括：

判断校验不通过时，提示插件安装失败，并显示具体原因。

5.根据权利要求1所述的方法，其特征在于，在所述根据所述通信协议配置信息进行不同平台间的通讯之后进一步包括插件卸载过程，所述插件卸载过程具体为：

接收插件卸载请求，所述请求包括插件标识；

检测与所述插件标识对应的插件的状态；

判断所述插件的状态为未使用时，将所述通信协议的功能代码和所述安装卸载引导类代码从所述系统运行环境中卸载；

从所述数据库中删除所述通信协议配置信息；

从插件安装目录中删除所述插件的物理文件。

6.根据权利要求5所述的方法，其特征在于，还包括：

判断所述插件的状态为使用中时，提示卸载失败，并显示具体原因。

7.一种在短信业务中不同平台间进行通讯的系统，其特征在于，包括：

请求接收模块，用于接收预先生成的插件的安装请求，所述插件携带有通信协议的功能代码、安装卸载引导类代码和插件配置文件；

插件获取模块，用于获取所述插件；

校验模块，用于对获取的所述插件进行校验，并判断校验是否通过；

配置文件读取模块，用于读取所述配置文件，根据所述配置文件在系统数据库中生成通信协议配置信息；

通讯模块，用于根据所述通信协议配置信息进行不同平台间的通讯，包括：建立与所述通信协议对应的通道；启动所述通道，系统根据所述通信协议配置信息实例化所述通信协议的功能代码；使用所述通信协议的功能代码接入网关；进行短信的收发。

8.根据权利要求7所述的系统，其特征在于，还包括：插件生成模块，用于预先生成插件。

9.根据权利要求7所述的系统，其特征在于，所述校验模块包括：

插件规范校验子模块，用于校验所述插件是否符合插件规范；

插件配置文件校验子模块，用于校验所述插件配置文件是否正确。