CN104717179A - 一种通信业务的处理方法及装置 - Google Patents

Abstract

本发明公开了一种通信业务的处理方法及装置，用以解决现有技术中存在的稳定度低，维护困难，最终影响通信效率的问题，该方法包括：接收到一个业务处理请求，提取该业务处理请求中携带的业务参数，并确定该业务处理请求所针对的业务类型；将该业务参数加载至针对该业务类型预设的子类文件中；基于加载了该业务参数的子类文件，执行相应的业务处理。这样，可以实现处理每个通信业务时，只要提取该业务参数，并调用的子类文件和主类文件就可以执行相应的业务处理，实现了接口文件的复用，当业务发生变化时，只需要将该业务类型针对的子类文件进行修改即可，稳定度高，且开发和维护更方便，从而保证了处理通信业务的效率。

Description

一种通信业务的处理方法及装置

技术领域

本发明涉及通信领域，尤其涉及一种通信业务的处理方法及装置。

背景技术

在移动通讯领域业务支撑系统中，尤其是业务运营支撑系统（Business&Operation Support System，BOSS）、客户关系管理（Customer RelationshipManagement，CRM）等系统，对外都提供了大量的Java语言实现的数据接口，这些数据接口为其外围系统提供数据交换，业务处理等服务。这些数据接口分为两类，扩展标识语言（eXtensible Markup Language，XML）报文接口、非XML报文接口。

XML报文接口，通过超级文本传送协议（Hyper Text Transport Protocol，HTTP）协议发送HTTP请求，并携带要请求的XML数据给服务端，服务端收到XML报文后对其进行解析，根据解析出来的数据做出相应的处理，并以约定的XML格式的结果反馈给调用者。

非XML报文接口，每个接口方法实现一个业务，接口方法参数的数量和类型都是根据具体业务需要而设计的，各不相同，通常参数本身无需转换处理即可以直接为业务实现编码所用。

对于XML报文接口，存在如下问题：

XML报文接口的开发和使用复杂。客户端和服务端都需要识别XML报文，并解析该XML报文，其中，XML报文与具体业务类型相对应，不同具体业务类型的XML报文也不相同。因此，使用者需要另外构建一个XML报文规范来调用XML报文接口，然而，XML报文接口本身需要接收XML报文并对其进行解析处理，整个使用XML报文接口的过程都是硬编码完成，相当的麻烦且容易出现失误。

XML报文数量众多，维护困难。虽然都是通过XML报文形式来调用XML报文接口，但实际上是一个具体业务类型对应一个XML报文，因此，针对不同的具体业务类型对应的XML报文，还需要构建对应的不同的XML报文规范来满足各种不同业务的需要，。然而具体业务类型数量巨大，每个具体业务类型对应的XML报文规范数量同样巨大。将大量的XML报文规范硬编码到代码中，给规范的维护与代码维护带来很大困难，在维护过程中，必须同时拿到XML报文规范对照代码才能进行维护工作，如果具体业务类型稍有变更，而规范没有做同步变更，那么长期积累下来后，系统的维护工作将非常困难，在后期修正过程中，还需要进行很多系统的改动。

对于非XML报文接口，存在如下问题：

以邮件投递的接口为例，系统中有众多的邮件投递需求，比如详单投递，M值查询投递等等，每个邮件投递的数据不一样，模版格式也不一样，要存储的数据字段也不一样，需要针对每个具体的邮件投递业务进行编码实现。

非XML报文接口无法实现复用。由于接口方法参数与具体业务类型紧密相关，调用双方必须相互“约定”、“遵守”、“理解”接口方法参数的定义，并通过接口方法参数来实现某一类型的具体业务，通常一个非XML报文接口只能实现一个特定的具体业务类型。所以，由于一个非XML报文接口是针对一个具体业务类型编码实现的，因此，一个非XML报文接口无法复用，更谈不上通用。

非XML报文接口不适应业务变化。当某一具体业务类型发送变动时，对应该具体业务类型的非XML报文接口通常也要跟着变动，因为非XML报文接口的参数是需要开发者根据具体业务类型定义的。

非XML报文接口稳定度很低，维护困难。如果使用某一非XML报文接口的系统数量较多，当对应的具体业务类型发生变化的时候，该非XML报文接口的方法定义也要随之改动。其他使用此非XML报文接口的方法的系统都要改动，给维护带来很大的困难。

非XML报文接口数量伴随着具体业务类型的增加而增加，增加维护困难。

发明内容

本发明实施例提供一种通信业务的处理方法及装置，用以解决现有技术中XML报文接口存在的使用复杂，每次使用都要另外构建一个XML报文规范，处理过程复杂，容易出现失误，且XML报文数量众多，开发和维护困难，影响通信质量的问题，以及非XML报文接口存在的无法实现复用，不适应业务变化，稳定度低，以及接口数量众多，维护困难，最终影响通信效率的问题。

本发明实施例提供的具体技术方案如下：

第一方面，一种通信业务的处理方法，包括：

接收到一个业务处理请求，提取所述业务处理请求中携带的业务参数，并确定所述业务处理请求所针对的业务类型；

将所述业务参数加载至针对所述业务类型预设的子类文件中，其中，所述子类文件的属性继承指定的主类文件的属性；

基于加载了所述业务参数的子类文件，执行相应的业务处理。

通过这种方法，处理每个通信业务时，只要提取该业务参数，并调用的子类文件和主类文件就可以执行相应的业务处理，实现了接口文件的复用，当业务发生变化时，只需要将该业务类型针对的子类文件进行修改即可，稳定度高，且开发维护更方便，从而保证了处理通信业务的效率。

结合第一方面，在第一种可能的实现方式中，所述业务参数为轻量级数据交换JSON格式的字符串。

通过这种方法，可以提高系统的通用性与灵活性。

结合第一方面或第一方面的第一种可能的实现方式，在第二种可能的实现方式中，所述指定的主类文件的属性中定义了通用的功能模块；所述子类文件的属性中定义了针对所述业务类型设定的功能模块。

通过这种方法，可以提高接口文件的复用性、稳定度，后期的开发和维护更方便。

结合第一方面的第二种可能的实现方式，在第三种可能的实现方式中，将所述业务参数加载至针对所述业务类型预设的子类文件中，包括：

读取所述业务参数中包含的每一个参数标识的参数值，并根据所述每一个参数标识将相应的参数值赋值给所述子类文件的属性中定义的各个功能模块。

通过这种方法，可以在调用该子类文件的各个功能模块时，实现针对该业务处理请求，执行相应的业务处理。

结合第一方面的第二种可能的实现方式，在第四种可能的实现方式中，基于加载了所述业务参数的子类文件，执行相应的业务处理，包括：

基于加载了所述业务参数的子类文件设置一个对象；

根据所述对象调用所述子类文件的属性中定义的各个功能模块，以及调用所述子类文件的属性继承的所述主类文件的属性中定义的的各个功能模块；

采用调用的各个功能模块，执行相应的业务处理。

通过这种方法，可以调用子类文件的属性中定义的各个功能模块，以及调用子类文件的属性继承的主类文件的属性中定义的各个功能模块。

第二方面，一种通信业务的处理装置，包括：

处理单元，用于接收到一个业务处理请求，提取所述业务处理请求中携带的业务参数，并确定所述业务处理请求所针对的业务类型；

加载单元，用于将所述业务参数加载至针对所述业务类型预设的子类文件中，其中，所述子类文件的属性继承指定的主类文件的属性；

运行单元，用于基于加载了所述业务参数的子类文件，执行相应的业务处理。

这样，本装置可以处理每个通信业务时，只要提取该业务参数，并调用的子类文件和主类文件就可以执行相应的业务处理，实现了接口文件的复用，当业务发生变化时，只需要将该业务类型针对的子类文件进行修改即可，稳定度高，且开发维护更方便，从而保证了处理通信业务的效率。

结合第二方面，在第一种可能的实现方式中，所述业务参数为轻量级数据交换JSON格式的字符串。

这样，可以提高系统的通用性与灵活性。

结合第二方面或第二方面的第一种可能的实现方式，在第二种可能的实现方式中，所述指定的主类文件的属性中定义了通用的功能模块；所述子类文件的属性中定义了针对所述业务类型设定的功能模块。

这样，可以提高接口文件的复用性、稳定度，后期的开发和维护更方便。

结合第二方面的第二种可能的实现方式，在第三种可能的实现方式中，所述加载单元将所述业务参数加载至针对所述业务类型预设的子类文件中，包括：

所述加载单元读取所述业务参数中包含的每一个参数标识的参数值，并根据所述每一个参数标识将相应的参数值赋值给所述子类文件的属性中定义的各个功能模块。

这样，可以使运行单元在调用该子类文件的各个功能模块时，实现针对该业务处理请求，执行相应的业务处理。

结合第二方面的第二种可能的实现方式，在第三种可能的实现方式中，所述运行单元基于加载了所述业务参数的子类文件，执行相应的业务处理，包括：

所述运行单元基于加载了所述业务参数的子类文件设置一个对象；

所述运行单元根据所述对象调用所述子类文件的属性中定义的各个功能模块，以及调用所述子类文件的属性继承的所述主类文件的属性中定义的的各个功能模块；

所述运行单元采用调用的各个功能模块，执行相应的业务处理。

这样，运行单元可以调用子类文件的属性中定义的各个功能模块，以及调用子类文件的属性继承的主类文件的属性中定义的各个功能模块。

采用本发明技术方案，可以有效的避免计算的标定矩阵存在误差，从而使得枪机和球机的对应关系不准确，引起联动跟踪的失败的问题，提升了枪机与球机的标定精度，并简化了标定的过程。本发明技术方案，适用于目前市场出现的各种枪球联动系统，而且运用软件实现，没有增加硬件开销。

附图说明

图1为本发明实施例提供的一种通信业务的处理方法的具体流程图；

图2为本发明实施例提供的一种通信业务的处理装置的结构图。

具体实施方式

采用本发明技术方案，能够有效地避免了现有技术中的接口开发和维护困难，不适应业务变化，最终影响通信质量和效率的问题。

本发明实施例提供了一种通信业务的处理方法，下面结合附图对本发明优选的实施方式进行详细说明。

本发明实施例所提供的方法，可以应用于各类能够处理通信业务的装置，具体的，参阅图1所示，此类装置处理通信业务的具体流程包括：

步骤101：接收到一个业务处理请求，提取该业务处理请求中携带的业务参数，并确定该业务处理请求所针对的业务类型。

为了通信接口的通用性与灵活性，本实施例中将业务参数即接口方法参数定义为字符串格式，优选的，在本实施例中，业务参数为轻量级的数据交换（JavaScript Object Notation，JSON）格式。

从该业务处理请求中提取出来的业务参数（JSON字符串）就是将该业务处理请求以JSON字符串的形式表达。

通信业务中业务类型有很多种，例如，充值，邮件投递中的积分查询、历史账单查询等。不同的业务类型对应的业务参数各不相同，本发明实施例中仅以积分查询业务为例，其它业务类型的处理方法基本相同，在此不再赘述。接收到积分查询业务请求（业务处理请求）后，从该积分查询业务请求中提取业务参数（JSON字符串），该JSON字符串中包含了所有参数标识以及每个参数标识对应的参数值，例如，收件人邮箱地址、业务编码、服务端流水号以及积分值等。

步骤102：将上述业务参数加载至针对上述业务类型预设的子类文件中，其中，子类文件的属性继承指定的主类文件的属性。

其中，指定的主类文件的属性中定义了通用的功能模块；子类文件的属性中定义了针对所述业务类型设定的功能模块。

由于要为系统设置一个通信接口，方便外部系统调用该通信接口，以实现通信业务处理的功能，但是由于外部系统的业务处理请求所针对的业务类型复杂多样，不可预测，如果针对一个业务类型设计一个通信接口，则无法实现通信接口的复用性，给后期的开发和维护也造成很大的困难。因此，本发明实施例中将同类的业务类型设置同一个模板即主类文件。模板中定义了每个业务类型都通用的参数和功能模块。

仍以积分查询业务为例，由于外部系统发送邮件的内容形式复杂多样，不可预测，有积分查询、历史账单查询等，因此对这些相似的邮件发送业务设置一个通用的模板即主类文件，模板中定义了所有这些相似的业务类型中通用的参数、功能模块。通用的参数包括：服务端流水号、收件人邮箱地址、手机号码、手机的品牌名称、业务编码等；通用的功能模块包括：邮件的大小、将收件人的邮箱地址填写入相应的位置等。

由于子类文件的属性继承指定的主类文件的属性，所以子类文件可以调用该指定主类文件的属性中定义的通用的功能模块、通用的参数等。且由于该子类文件为针对该业务类型预设的，所以，该子类文件中定义了针对该业务类型设定的功能模块以及参数。以积分查询业务为例，针对积分查询业务设定的参数，如积分值等；针对积分查询业务设定的功能模块，如积分值的计算等。

优选的，本实施例通过可重用组件JavaBean来表达主类文件，采用面向对象程序设计（Object Oriented Programming，OOP）对同类业务进行抽象，通过以下程序，生成主类文件：

通过以下程序，生成针对积分查询业务类型预设的子类文件：

具体的，将业务参数加载至针对相应的业务类型预设的子类文件中，包括：

读取该业务参数中包含的每一个参数标识的参数值，并根据每一个参数标识将相应的参数值赋值给该子类文件的属性中定义的各个功能模块。

继续以积分查询业务为例：

在步骤101中，从积分查询业务请求中提取业务参数（JSON字符串），该JSON字符串中包含了所有参数标识以及每个参数标识对应的参数值，例如，收件人邮箱地址、业务编码、服务端流水号以及积分值等；

由以上描述可知，针对积分查询业务类型预设的子类文件的属性中，定义了包含继承的主类文件的属性——通用的参数（服务端流水号、收件人邮箱地址、手机号码、手机的品牌名称、业务编码等），通用的功能模块（邮件的大小、将收件人的邮箱地址填写入相应的位置等），以及该子类文件的属性——针对积分查询业务设定的参数，（如积分值等），针对积分查询业务设定的功能模块，（如积分值的计算等）；

因此可以将读取该业务参数中包含的每一个参数标识的参数值，并根据每一个参数标识将相应的参数值赋值给该子类文件的属性中定义的各个功能模块，例如，读取从积分查询业务请求中提取的业务参数中的收件人邮箱地址，并将该收件人邮箱地址赋值给针对积分查询业务预设的子类文件的属性中的参数——收件人邮箱地址。

步骤103：基于加载了上述业务参数的子类文件，执行相应的业务处理。

具体的，基于加载了该业务参数的子类文件，执行相应的业务处理，包括三个步骤：

首先，基于加载了该业务参数的子类文件设置一个对象；

然后，根据该对象调用该子类文件的属性中定义的各个功能模块，以及调用该子类文件的属性继承的主类文件的属性中定义的的各个功能模块；

最后，采用调用的各个功能模块，执行相应的业务处理。

还以积分查询业务为例，首先，基于加载了该积分查询业务请求中提取的业务参数的子类文件，采用以下程序，设置一个对象，并利用该对象可以调用该子类文件的属性中定义的各个功能模块，如积分值的计算：

PointQuery data=new new PointQuery();

Data.setPoint(2132)

在调用该子类文件的属性继承的主类文件中定义的各个功能模块，如邮件的大小、将收件人的邮箱地址填写入相应的位置，根据这些功能模块可以最终实现积分查询业务，即将计算得到的积分值以邮件的形式发送给发出积分查询业务请求的用户。

基于上述实施例，参阅图2所示，本发明实施例还提供了一种通信业务的处理装置，该装置包括处理单元201，加载单元202以及运行单元203，其中

处理单元201，用于接收到一个业务处理请求，提取该业务处理请求中携带的业务参数，并确定该业务处理请求所针对的业务类型；

加载单元202，用于将该业务参数加载至针对该业务类型预设的子类文件中，其中，该子类文件的属性继承指定的主类文件的属性；

运行单元203，用于基于加载了该业务参数的子类文件，执行相应的业务处理。

进一步的，该业务参数为JSON格式的字符串。

进一步的，该指定的主类文件的属性中定义了通用的功能模块；该子类文件的属性中定义了针对该业务类型设定的功能模块。

加载单元202将该业务参数加载至针对该业务类型预设的子类文件中，包括：

加载单元202读取该业务参数中包含的每一个参数标识的参数值，并根据每一个参数标识将相应的参数值赋值给该子类文件的属性中定义的各个功能模块。

运行单元203基于加载了该业务参数的子类文件，执行相应的业务处理，包括：

运行单元203基于加载了该业务参数的子类文件设置一个对象；

运行单元203根据该对象调用该子类文件的属性中定义的各个功能模块，以及调用该子类文件的属性继承的该主类文件的属性中定义的的各个功能模块；

运行单元203采用调用的各个功能模块，执行相应的业务处理。

综上所述，通过本发明实施例中提供的一种通信业务的处理方法：提取接收的业务处理请求中携带的业务参数，并将得到的业务参数加载到针对该业务处理请求对应的业务类型预设的子类文件中，最终，基于该加载了业务参数的子类文件，执行相应的业务处理，其中，子类文件的属性继承了指定的主类文件的属性，通过这种方法，处理每个通信业务时，只要提取该业务参数，并调用的子类文件和主类文件就可以执行相应的业务处理，实现了接口文件的复用，当业务发生变化时，只需要将该业务类型针对的子类文件进行修改即可，稳定度高，且开发和维护更方便，从而保证了处理通信业务的效率。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明实施例进行各种改动和变型而不脱离本发明实施例的精神和范围。这样，倘若本发明实施例的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种通信业务的处理方法，其特征在于，包括：

接收到一个业务处理请求，提取所述业务处理请求中携带的业务参数，并确定所述业务处理请求所针对的业务类型；

将所述业务参数加载至针对所述业务类型预设的子类文件中，其中，所述子类文件的属性继承指定的主类文件的属性；

基于加载了所述业务参数的子类文件，执行相应的业务处理。

2.如权利要求1所述的方法，其特征在于，所述业务参数为轻量级数据交换JSON格式的字符串。

3.如权利要求1或2所述的方法，其特征在于，所述指定的主类文件的属性中定义了通用的功能模块；所述子类文件的属性中定义了针对所述业务类型设定的功能模块。

4.如权利要求3所述的方法，其特征在于，将所述业务参数加载至针对所述业务类型预设的子类文件中，包括：

读取所述业务参数中包含的每一个参数标识的参数值，并根据所述每一个参数标识将相应的参数值赋值给所述子类文件的属性中定义的各个功能模块。

5.如权利要求3所述的方法，其特征在于，基于加载了所述业务参数的子类文件，执行相应的业务处理，包括：

基于加载了所述业务参数的子类文件设置一个对象；

根据所述对象调用所述子类文件的属性中定义的各个功能模块，以及调用所述子类文件的属性继承的所述主类文件的属性中定义的的各个功能模块；

采用调用的各个功能模块，执行相应的业务处理。

6.一种通信业务的处理装置，其特征在于，包括：

处理单元，用于接收到一个业务处理请求，提取所述业务处理请求中携带的业务参数，并确定所述业务处理请求所针对的业务类型；

加载单元，用于将所述业务参数加载至针对所述业务类型预设的子类文件中，其中，所述子类文件的属性继承指定的主类文件的属性；

运行单元，用于基于加载了所述业务参数的子类文件，执行相应的业务处理。

7.如权利要求6所述的装置，其特征在于，所述业务参数为轻量级数据交换JSON格式的字符串。

8.如权利要求6或7所述的装置，其特征在于，所述指定的主类文件的属性中定义了通用的功能模块；所述子类文件的属性中定义了针对所述业务类型设定的功能模块。

9.如权利要求8所述的装置，其特征在于，所述加载单元将所述业务参数加载至针对所述业务类型预设的子类文件中，包括：

所述加载单元读取所述业务参数中包含的每一个参数标识的参数值，并根据所述每一个参数标识将相应的参数值赋值给所述子类文件的属性中定义的各个功能模块。

10.如权利要求8所述的装置，其特征在于，所述运行单元基于加载了所述业务参数的子类文件，执行相应的业务处理，包括：

所述运行单元基于加载了所述业务参数的子类文件设置一个对象；

所述运行单元根据所述对象调用所述子类文件的属性中定义的各个功能模块，以及调用所述子类文件的属性继承的所述主类文件的属性中定义的的各个功能模块；

所述运行单元采用调用的各个功能模块，执行相应的业务处理。