CN114265636A - 一种通信协议的配置方法及装置、存储介质 - Google Patents

Abstract

本申请提供一种通信协议的配置方法及装置、存储介质。通信协议的配置方法，包括：获取模型描述文件；所述模型描述文件包括：用于指示网络设备之间的通信协议的传输层文件、用于指示所述通信协议对应的内容的内容层文件、以及用于指示网络设备之间的接口参数的接口层文件；将所述模型描述文件编译为工程代码；根据所述工程代码对所述网络设备之间的通信协议进行配置。该配置方法用以降低通信协议的配置成本，实现通信协议的灵活配置。

Description

一种通信协议的配置方法及装置、存储介质

技术领域

本申请涉及通信技术领域，具体而言，涉及一种通信协议的配置方法及装置、存储介质。

背景技术

随着互联网技术的发展，网络设备由过去的登录设备终端使用命令行配置的方式逐渐转为调用设备API(Application Programming Interface，应用程序接口)的方式进行配置。随着网络规模的不断扩大，以及网格代理技术的使用，网络设备的业务和类型变得多样化，对网络设备的协议配置通常也需要经过多个中间设备的转发和处理。

现有的配置方式，各个设备的开发和设计人员之间需要协调和沟通，各个网络设备之间也需要协商，导致配置成本较高。

发明内容

本申请实施例的目的在于提供一种通信协议的配置方法及装置、存储介质，用以降低通信协议的配置成本，实现通信协议的灵活配置。

第一方面，本申请实施例提供一种通信协议的配置方法，包括：获取模型描述文件；所述模型描述文件包括：用于指示网络设备之间的通信协议的传输层文件、用于指示所述通信协议对应的内容的内容层文件、以及用于指示网络设备之间的接口参数的接口层文件；将所述模型描述文件编译为工程代码；根据所述工程代码对所述网络设备之间的通信协议进行配置。

在本申请实施例中，与现有技术相比，通过模型描述文件来实现通信协议的配置，在模型描述文件中包括传输层文件、内容层文件和接口层文件，因此，该模型描述文件所派生出的工程代码可以理解为一套函数调用库，封装了传输协议的细节；进而，对于网络设备来说，只需要集成这些工程代码，然后进行调用，便可以实现设备之间的协议配置。在整个配置过程中，开发人员根据需求对模型描述文件进行配置即可，网络设备也只需接收模型描述文件对应的工程代码即可，无需网络设备之间，以及开发人员之间进行协商。因此，该配置方法能够降低通信协议的配置成本，实现通信协议的灵活配置。

作为一种可能的实现方式，所述模型描述文件为基于YAML语法的描述文件，包括多个标签中的至少2个标签，所述多个标签包括：用于描述数据对象的身份标识标签、用于描述数据对象的属性信息的属性标签、用于描述数据对象之间的关联关系的关系标签、用于描述数据对象存储时的索引特征的索引标签、用于描述可排序的属性的名称的名称标签。

在本申请实施例中，采用基于YAML语法的模型描述文件，通用性较高，成本较低。

作为一种可能的实现方式，所述属性标签包括关键字标签，所述关键字标签用于指示对应的属性信息所在的属性文件。

在本申请实施例中，采用关键字标签作为属性标签，实现整个内容层的描述，提高模型描述文件的简洁性和规范性。

作为一种可能的实现方式，所述将所述模型描述文件编译为工程代码，包括：将所述模型描述文件解析为中间数据对象；根据预设的代码模版将所述中间数据对象转换为目标工程代码。

在本申请实施例中，先将模型描述文件解析为中间数据对象，再结合预设的代码模版将中间数据对象转换为目标工程代码，实现工程代码的有效编译。

作为一种可能的实现方式，所述中间数据对象对应多个模版数据对象，所述多个模版数据对象对应不同的预设代码模版，所述根据预设代码模版将所述中间数据对象转换为目标工程代码，包括：将所述中间数据对象转换为模版数据对象；根据所述模版数据对象对应的预设代码模版将所述模版数据对象转换为目标工程代码。

在本申请实施例中，先将中间数据对象转换为模版数据对象，再根据模版数据对象对应的预设代码模版将模版数据对象转换为目标工程代码；通过两级对象关系实现目标工程代码的有效转换。

作为一种可能的实现方式，所述将所述中间数据对象转换为模版数据对象，包括：根据所述网络设备对应的场景和需求将所述中间数据对象转换为模版数据对象。

在本申请实施例中，基于网络设备对应的场景和需求，将中间数据对象转换为对应的模版数据对象，以使最终生成的目标工程代码与场景和需求适配。

作为一种可能的实现方式，所述工程代码包括不同的网络设备分别对应的工程代码；所述根据所述工程代码对所述网络设备之间的通信协议进行配置，包括：将所述不同的网络设备分别对应的工程代码分发给对应的网络设备，以使对应的网络设备基于所述工程代码配置与其他网络设备之间的通信协议。

在本申请实施例中，通过将不同的网络设备分别对应的工程代码分发给对应的网络设备，实现对应的网络设备基于工程代码配置与其他网络设备之间的通信协议。

作为一种可能的实现方式，所述模型描述文件还包括：扩展描述文件；所述扩展描述文件为可编辑的文件，用于写入扩展的描述信息。

在本申请实施例中，通过扩展描述文件，开发人员还可以根据需求写入扩展的描述信息，实现通信协议的灵活配置。

第二方面，本申请实施例提供一种通信协议的配置装置，包括：用于实现第一方面以及第一方面的任意一种可能的实现方式中所述的通信协议的配置方法的各个功能模块。

第三方面，本申请实施例提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，所述计算机程序被计算机运行时，执行如第一方面以及第一方面的任意一种可能的实现方式中所述的通信协议的配置方法。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的互联网系统的结构示意图；

图2为本申请实施例提供的通信协议的配置方法的流程图；

图3为本申请实施例提供的模型描述文件的编写形式的示意图；

图4为本申请实施例提供的通信协议的配置方法的操作流程示意图；

图5为本申请实施例提供的通信协议的配置装置的结构示意图。

图标：500-通信协议的配置装置；510-获取模块；520-处理模块。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

本申请实施例提供的技术方案可以应用于互联网应用场景中，对网络设备之间的通信协议进行配置，所涉及的通信协议包括：传输层协议、内容层协议以及接口层协议。其中，传输层协议可以理解为，网络设备之间所采用的传输协议，内容层协议可以理解为基于传输协议的传输内容，接口层协议可以包括设备所采用的接口和接口参数。

请参照图1，为本申请实施例提供的互联网系统的结构示意图，在该互联网系统中，包括：第一客户端、第二客户端、服务端和配置端。

作为一种可选的实施方式，第一客户端可以是浏览器的客户端，对应的，服务端为浏览器的客户端对应的服务端。对于第一客户端与服务端之间的通信协议配置，第一客户端作为通信客户端，服务端作为通信服务端。

第二客户端可以是防火墙设备，对应的，服务端仍然可以为浏览器的客户端对应的服务端。对于第二客户端与服务端之间的通信协议配置，第二客户端作为通信客户端，服务端作为通信服务端。

基于图1这样的互联网系统，其通信场景可以是，用户操作web浏览器向设备管理服务端提交用户对防火墙的配置请求，管理服务端受理了用户的请求，将用户的请求转换成防火墙设备的配置策略，发送给防火墙设备。

因此，在进行通信协议配置时，可以对服务端-第一客户端，服务端-第二客户端之间的通信协议分别进行配置。

在一些实施例中，该互联网系统还可以包括更多的客户端，或者仅包括第一客户端或者第二客户端；对应的通信场景对应变化。

在本申请实施例中，配置端可以是集成在互联网系统中的硬件，也可以是独立于互联网系统外的硬件，其可以作为本申请实施例所提供的技术方案的硬件运行环境。

基于上述应用场景的介绍，接下来请参照图2，为本申请实施例提供的通信协议的配置方法的流程图，包括：

步骤210：获取模型描述文件。模型描述文件包括：用于指示网络设备之间的通信协议的传输层文件、用于指示通信协议对应的内容的内容层文件、以及用于指示网络设备之间的接口参数的接口层文件。

步骤220：将模型描述文件编译为工程代码。

步骤230：根据工程代码对网络设备之间的通信协议进行配置。

在本申请实施例中，与现有技术相比，通过模型描述文件来实现通信协议的配置，在模型描述文件中包括传输层文件、内容层文件和接口层文件，因此，该模型描述文件所派生出的工程代码可以理解为一套函数调用库，封装了传输协议的细节；进而，对于网络设备来说，只需要集成这些工程代码，然后进行调用，便可以实现设备之间的协议配置。在整个配置过程中，开发人员根据需求对模型描述文件进行配置即可，网络设备也只需接收模型描述文件对应的工程代码即可，无需网络设备之间，以及开发人员之间进行协商。因此，该配置方法能够降低通信协议的配置成本，实现通信协议的灵活配置。

接下来对该配置方法的详细实施方式进行介绍。

在步骤210中，获取模型描述文件，该模型描述文件可以为开发人员预先在配置端上配置好的模型描述文件，在需要对网络设备进行配置，直接从本地进行获取即可。该模型描述文件也可以为开发人员基于配置需求在配置端上实时配置的模型描述文件，此时，步骤210中，获取开发人员所输入的模型配置文件即可。

其中，开发人员可分为网络设备开发人员和模型协议开发人员。模型协议开发人员编写模型文件，并将其转化成网络设备开发人员熟悉的编程语言库。

一般来说，用于配置网络设备的接口是接口层的一部分，配置项会对应转换成接口层的一个实体及其接口参数。

在模型描述文件中，包括：传输层文件、内容层文件和接口层文件。传输层文件用于指示网络设备之间的通信协议，内容层文件用于指示通信协议对应的内容，接口层文件用于指示网络设备之间的接口参数。

在本申请实施例中，模型描述文件可以按照预设的模型文件形式进行编写。对于该模型文件形式，可以采用YAML的词法逻辑和语法逻辑，即key：value键值对形式。

作为一种可选的实施方式，请参照图3，为模型描述文件的段落结构的示意图，在该段落结构中，包括：定义模型元数据的段落、定义模型之间的关系的段落、定义模型属性的段落以及定义模型索引的段落。

在一些实施例中，还可以包括：定义模型的可排序的属性的名称的段落以及扩展段落。

在这些段落中，可设置对应的段落属性标签，模型描述文件包括以下标签中的至少2个标签：用于描述数据对象的身份标识标签(对应定义模型元数据的段落)、用于描述数据对象的属性信息的属性标签(对应定义模型属性的段落)、用于描述数据对象之间的关联关系的关系标签(对应定义模型之间的关系的段落)、用于描述数据对象存储时的索引特征的索引标签(对应定义模型索引的段落)、用于描述可排序的属性的名称的名称标签。

在本申请实施例中，采用基于YAML语法的模型描述文件，通用性较高，成本较低。

为了便于理解，接下来对上述段落结构进行举例介绍。

在图3所示的段落结构中，一些对应的模型文件形式可以如下：

#Model

model:

用于接口的标识名称属性:属性值

用于资源分类的名称属性:属性值

用于生成的数据结构的名称属性:属性值

用于生成分类标签属性:属性值

用于描述模型属性:属性值

用于切换生成的代码类型的属性:属性值

…

其他属性

#Attributes

attributes:

版本号1:

属性1:

名称:值

属性描述:值

类型:值

是否公开:值

是否存储:值

枚举范围:值

Json的标签别名:值

Yaml的标签别名:值

是否允许空置:值

以及其他属性1的属性

属性2:

同上

版本号2:

属性1:

名称:值

属性描述:值

类型:值

是否公开:值

是否存储:值

枚举范围:值

Json的标签别名:值

Yaml的标签别名:值

是否允许空置:值

以及其他属性1的属性

属性2:

同上

#Relations

relations：

这一段是可选段，这里描述数据在树里面的关系格式同#model。

#Indexs

indexs:

这一段是可选段，这里描述模型之间的关系，用于组织数据，格式和#model相同。

具体的，在应用时，可以先创建结构化的模型描述文件，内容层文件以.spec作为扩展名。标签#Model部分，描述数据模型(数据对象，即模型描述文件对应的数据)的身份标识，用于确定数据模型在模型库里的唯一标识。标签#Attributes部分，描述数据模型的属性部分，对模型的承载业务数据的属性做细致定义。比如名称，类型，是否存储，标签别名，是否公开，是否废弃等等。标签#Indexs部分，作为可选部分，描述数据存储时的索引特征。标签#Relations部分，作为可选部分，描述模型之间的关联关系。

上述各部分代表了模型描述文件的基本格式，沿用此种格式，可以对描述内容进行扩展，举例，比如还可以增加#Order部分，标识出可排序的属性的名称。

因此，作为一种可选的实施方式，模型描述文件还包括：扩展描述文件；扩展描述文件为可编辑的文件，用于写入扩展的描述信息。该扩展描述文件与模型描述文件的基本格式相同。

作为一种可选的实施方式，通过_parameter.mapping,_type.mapping,_validation.mapping三个文件分别对接口参数，属性的类型和属性的校验逻辑给予扩展支持，用于提高兼容性。

在本申请实施例中，通过扩展描述文件，开发人员还可以根据需求写入扩展的描述信息，实现通信协议的灵活配置。

在上述的属性标签中，其对应的属性值可直接为确定的值，也可以为关键字标签。作为一种可选的实施方式，属性标签包括关键字标签，关键字标签用于指示对应的属性信息所在的属性文件。

在这种实施方式中，在spec文件的Attributes部分定义的属性里面使用extenal关键字，对应的属性类型将从这_type.mapping文件里面查找。举例来说，使用validate关键字，对应的校验方法将从_validation.mapping文件查找，使用parameter关键字，将使用_parameter.mapping定义的参数作为协议内容。

在本申请实施例中，采用关键字标签作为属性标签，实现内容层文件的分层，提高模型描述文件的简洁性和规范性。

对于传输层，可通过api.info文件定义通讯传输层使用的协议，指定使用的传输层协议是rpc或是restful API。

对于内容层，由模型描述文件的#Attrubutes部分定义，这部分的每一个键值对描述了一种属性特征。根据不同的传输层协议，描述文件定义的模型会编码成不同的传输格式，在客户端和服务端之间传输，典型的传输格式有json，msgpack等。

对于协议层，模型描述文件的#Model部分和#Relations部分一起描述模型的接口路径。基于这部分内容，编译器抽取这两部分的键值，拼装接口路由，最终生成的目标代码会包括已经协商好的一份服务端接口代码和一份客户端接口代码。具体的接口实现依据不同的传输层和内容层定义有不同的实现，比如传输的路由形式和内容的编码解码，甚至是函数库的选型。

通过上述模型描述文件的介绍，在应用时，开发人员只需根据实际的配置需求，按照上述模型描述文件的结构、形式等，编写描述文件即可。

在步骤220中，将模型描述文件编译为工程代码。作为一种可选的实施方式，配置端包括解析器，在步骤220中，通过解析器将模型描述文件编译为工程代码。

对于解析器，可以理解为一个执行程序，将模型描述文件输入该执行程序中，便可输出对应的工程代码。

作为一种可选的实施方式，步骤220包括：将模型描述文件解析为中间数据对象；根据预设的代码模版将中间数据对象转换为目标工程代码。

在本申请实施例中，先将模型描述文件解析为中间数据对象，再结合预设的代码模版将中间数据对象转换为目标工程代码，实现工程代码的有效编译。

在这种实施方式中，中间数据对象是一系列约定好的数据结构，通过对中间数据对象进行处理，根据属性的类型和值匹配不同的代码模版，并对模版进行填充和剪裁，生成代码片段，片段代码重新组织之后按照文件类型输出成工程代码。

片段代码按照客户端，服务端，通讯协议三大块组织。其中通讯协议又分为模型管理器，模型关系器，内容模型三个部分。

作为一种可选的实施方式，中间数据对象对应多个模版数据对象，多个模版数据对象对应不同的预设代码模版，根据预设代码模版将中间数据对象转换为目标工程代码，包括：将中间数据对象转换为模版数据对象；根据模版数据对象对应的预设代码模版将模版数据对象转换为目标工程代码。

在本申请实施例中，先将中间数据对象转换为模版数据对象，再根据模版数据对象对应的预设代码模版将模版数据对象转换为目标工程代码；通过两级对象关系实现目标工程代码的有效转换。

其中，将中间数据对象转换为模版数据对象，包括：根据网络设备对应的场景和需求将中间数据对象转换为模版数据对象。

在本申请实施例中，基于网络设备对应的场景和需求，将中间数据对象转换为对应的模版数据对象，以使最终生成的目标工程代码与场景和需求适配。

其中，场景和需求一般指不同的工程语言场景下的异构接口协议，比如说目标工程语言是java或者C++,然后接口类型又分为了restful和rpc，这样一套数据对象就对应了4套模板。

为了便于理解，接下来结合实例对解析器的代码转换的实现方式进行介绍。

解析器的工作原理，是采用yaml的通用格式来定义特定领域的描述语言，可以理解为，在yaml的语法基础上，进行建模领域的扩展，所采用的领域专属语言如前所述，使用yaml这样的通用的标记语言来代替这一过程，可以复用yaml解析库，省掉开发脚本以及之后人员培训的大量时间。接下来举例说明解析器的语法规则。

任何语言都要遵循规定的语法，以自然语言举例，比如“I do something”,按照语法这是一个”主语-谓语-宾语”的句法结构，转化成yaml格式写成:

句式1:

主语:值

谓语:值

宾语:值

再举例一个”主语-系词-表语”的形式，比如“I am a student”和”they arestudents”，在这里，系词作为主词和表语的连接词，没有特定意义，并且系词的单数和复数变位和表语的形式一致，因此句法结构，转化成yaml格式写成:

句式2:

主语:值

表语:值

对于常用的函数语句，比如“函数(参数1，参数2)”或者更自然语言化的“函数参数1，参数2”这样的形式，可以按照上面的语法思路，可以认为是一种“谓语-补语”的表示形式，转化成yaml格式可以写成:

句式3:

谓语:值

补语:值列表

更近一步，引入闭包的概念，闭包是另外一个模型表述块，可以理解为自然语言的“do something”里面的”something”,使用关键字“do”表示，举例一个“函数参数1参数2do闭包3次”，转化成yaml格式就写成:

句式4:

谓语:值

补语:值列表

Do：

次数:值

闭包:值

以上这些句式的集合，就构成了解析器的解析规则的基础。

上述所述的解析器的内部语义对象，是以上句法规则被yaml编码库处理之后的数据结构以及绑定在这些数据结构上的操作。大块的输入文件会被解析成一系列小对象，比如输入上述的句式4的数据文件，会解析成以下形式：

句式结构:

句式类型:值(为4,对应句式4)

主语:值(为空)

谓语:值(句式4的谓语)

系语；值(为空)

表语：空(为空)

补语:空(句式4的值列表)

闭包:

闭包类型:值

闭包执行方式:给定的枚举值之一

闭包循环次数:表达式

闭包执行条件:表达式

闭包参数:值列表

…

更多其他闭包属性

内部语义对象在之后会带入模版，模版是一套预设的字符串文本，其中的关键字段可以被中间对象的属性代替。

举例:

模版例子1:

模版类型1:

{{主词}}{{谓词}}{{宾词}}{{补语}}.

有句式1中间对象:

句式1:

主语:I

谓语:do

宾语:something

生成的工程代码为:

I do something.

如果是句式4中间变量：

句式4:

谓语:plus

补语:

-item:1

-item:2

生成的工程代码为:

plus 1 2.

模版也可以执行逻辑运算，比如

模版例子2:

If对象类型是句式1then

使用模版类型1

else

使用模版类型2

end

模版和内部语义对象的搭配关系根据不同的需求而定，不同的对象属性执行不同的逻辑，生成不同的代码片段。这些代码片段再根据工程要求进行组织后最终生成工程代码。

最终，工程代码包括客户端调用库，服务端调用库和用于客户端与服务端通讯的网络协议库。

通过步骤220的介绍，可以了解如何将模型描述文件编译为工程代码。进而，在步骤230中，根据工程代码对网络设备之间的通信协议进行配置。

作为一种可选的实施方式，步骤230包括：将不同的网络设备分别对应的工程代码分发给对应的网络设备，以使对应的网络设备基于工程代码配置与其他网络设备之间的通信协议。

结合步骤220的介绍可知，工程代码包括客户端调用库，服务端调用库和用于客户端与服务端通讯的网络协议库，因此，将对应的工程代码分发给对应的设备，对应的设备便可以根据工程代码进行配置。例如：将客户端调用库分发给客户端，客户端基于该调用库实现协议配置；将服务端调用库分发给服务端，服务端基于该调用库实现协议配置；以及将网络协议库分发给客户端和服务端，客户端和服务端基于协议库实现协议配置。

在本申请实施例中，通过将不同的网络设备分别对应的工程代码分发给对应的网络设备，实现对应的网络设备基于工程代码配置与其他网络设备之间的通信协议。

通过前述实施例的介绍，可以看出，在步骤230中最终配置好的网络协议，具有以下特点：

1.协议包括传输层，内容层和接口约定。

2.传输层，传输层表示协议的传输格式。本协议的传输层使用公开的传输协议，比如restful和rpc。通过修改配置文件app.info指定不同的传输类型，可以使用不同的传输层协议库生成不同的目标工程代码。

3.内容层，内容层表示传输的内容。本协议的内容层由模型描述文件定义，具体的是由模型描述文件的的#Attrubutes部分定义。这部分的每一个键值对描述了一种属性特征。根据不同的传输层协议，描述文件定义的模型会编码成不同的传输格式，在客户端和服务端之间传输，典型的传输格式有json，msgpack等。

4.接口约定，模型描述文件的#Model部分和#Relations部分一起描述模型的接口路径，编译器抽取这两部分的键值，拼装接口路由，最终生成的目标代码会包括已经协商好的一份服务端接口代码和一份客户端接口代码。具体的接口实现依据不同的传输层和内容层定义有不同的实现，比如传输的路由形式和内容的编码解码，甚至是函数库的选型。

以上这些原本是需要由接口调用方和接口提供方的技术人员协商的过程，采用本申请实施例的技术方案，可以由协议订立者独立完成，减少了沟通成本。

本申请实施例的技术方案在应用时，基本的实施流程包括：

1.用户编写模型文件，模型文件内容包括模型标识定义，模型属性定义和模型关系定义。定义好的模型描述了网络协议的内容层和传输层以及客户端/服务端的接口。

2.通过模型解析器将模型文件编译成工程代码。工程代码包括客户端部分和服务端部分，在客户端和服务端代码之外，还有一套代码代表传输层和内容层的协议，这套代码用于约束客户端和服务端的网络传输。

3.提供服务的网络设备集成工程库的服务端部分，请求服务的网络设备集成工程库的客户端部分。网络设备只需要知道工程库提供的函数，不再关心具体的网络通信的协商方式。

请参照图4，为本申请实施例的技术方案在实际应用时的操作流程图，基于该操作流程图，具体的应用场景可以是：

分布式虚拟防火墙是部署在云端虚拟化环境的一套安全系统，为云端网络环境提供数据访问安全服务。防火墙系统由多个虚拟网络设备组成，虚拟网络设备基于硬件虚拟化技术，是运行在标准虚拟机或者容器里面的网络服务。考虑其中的一条通信场景：场景包括浏览器前端，网络设备的管理服务端以及多个被管理的虚拟防火墙设备。用户操作web浏览器向设备管理服务端提交用户对防火墙的配置请求，管理服务端受理了用户的请求，将用户的请求转换成防火墙设备的配置策略，发送给防火墙设备。

该应用场景涉及到的设备以及设备之间的通信：

1.浏览器客户端和管理服务端，以及之间的通信，其中浏览器作为通信客户端，管理服务作为通信服务端，传输层协议是基于json的restful协议，内容层协议的内容是设备配置模型，需要此协议的接口和接口参数。

2.管理服务端和虚拟防火墙设备，以及之间的通信，其中管理服务作为通信客户端，安全设备作为通信服务端，传输层协议是基于二进制编码格式的RPC(RemoteProcedure Call，远程过程调用)协议，内容层协议内容是设备配置模型。

对于图4中涉及的操作流程，包括：

步骤A1,用户编写模型描述文件，这里指称的模型，是指面向对象设计概念里定义的模型，模型描述文件必须包含#Model部分和#Attributes部分，其他部分可选，并且可以扩展新模块。

在#Model部分，文件按照YAML的语法格式提供一系列键值对，用来描述模型的唯一性。这些键值包括模型的类型名，模型的内部唯一标识名，外部的唯一标识名，分类标识，分组标识，所属库名，模型说明文档，模型的复数命名，模型的别名，接口约束规则，包括一个接口白名单，接口的描述信息，可选的，字段不限于以上描述，可以进一步增加来强化模型描述能力。

在#Attributes部分，文件描述模型的属性，这里的属性是指面向对象设计概念里定义的类的属性。所谓描述模型的属性，是指，文件里面定义的这些属性是描述面向对象概念里的类的属性的对象。

依照模型里面的这些属性的描述，模型可以被翻译成多个面向对象设计概念里面用于派生对象的类，每个类都适用一种场合并且拥有与场合配套的类方法和帮助方法。模型的属性组织在一系列版本号标识下面，版本标识将模型的属性按照版本进行了区分。

对于任意一条属性，文件按照YAML的语法格式提供一系列键值对，用于描述类属性。这些键值对内容包括但不限于类属性的类型，类属性关联的子类的属性，类属性是否用于持久化场景，类属性用于持久化场景是是否是外键，类属性是否用于restful协议，类属性是否私有，挂载校验方法。可选的，字段不限于以上描述，可以进一步增加键值描述对来强化模型描述力。

可选的，可以增加模块用于描述，以增强模型描述力。比如#Relations部分描述父子模型关系，在这里指定模型关联的子模型，以及访问子模型的接口途径，最终所有模型汇聚在一起，以树的形式组织。

其他可选模块包括但不限于，#Order模块，用于描述排序，#Indexes模块，用于描述索引。

步骤A2，使用解析器解析编写好的模型文件。在这里，解析器会对模型文件做解析处理，转换成语义对象待用。

解析器首先会检查输入的模型文件的使用的领域语言的语法和词法规范，退回不符合规范的文件，并输出错误信息。这里的领域语言形式使用的是YAML语言规范。YAML是通用的标记语言的一种，传播较广。可选的，也可以使用其他领域语言代替，比如json，yang。

模型文件通过解析器的校验之后，解析器将正确形式的模型文件按照工程约定的语义解析成内部语义对象，这些语义对象是执行步骤A3，生成最终工程代码的基础。

可选的，解析器可以接收执行参数，比如-h打印帮助信息，-d指定模型文件的目录。-s指定输出的工程语言类型，-o指定输出目录。

步骤A3，解析器将持有的语义对象按照不同的代码模版，生成工程可用的代码库，代码库包括客户端和服务端和通信协议。

通信协议包括传输层和内容层，传输层包括但不限于restful，RPC，soap，内容层由模型文件的#Attributes部分描述，客户端和服务端基于模型文件约定通信接口和接口说明文档。

可选的，在集成该种语言的代码模版的情况下，可以支持生成多种语言的目标代码库。

至此，浏览器，设备管理服务和安全设备约定了统一通信协议。浏览器客户端使用restful协议访问设备管理服务，设备管理服务基于同样的内容层，作为客户端使用rpc协议访问作为服务端的安全设备。

设备描述文件作为唯一有效的协议描述文档，需要被浏览器前端，设备管理服务，安全防火墙这三方网络设备共同遵守，且对三个网络设备屏蔽了通信实现细节。

通过本申请实施例所采用的技术方案，简化了模型描述的复杂度，能适应web前端开发者的编码习惯；且减少了开发和沟通成本，产生的工程代码可以适应多种编程语言。

以及，能够统一web前端，管理服务端，网络中间件和网络设备端的通信协议和内容。能够生产非常统一的，并且做好严格的格式检查的结构化数据，解决了跨设备配置管理通信，数据不统一的问题。

基于同一发明构思，请参照图5，本申请实施例中还提供通信协议的配置装置500，包括：获取模块510和处理模块520。

获取模块510，用于获取模型描述文件；所述模型描述文件包括：用于指示网络设备之间的通信协议的传输层文件、用于指示所述通信协议对应的内容的内容层文件、以及用于指示网络设备之间的接口参数的接口层文件。处理模块520用于：将所述模型描述文件编译为工程代码；根据所述工程代码对所述网络设备之间的通信协议进行配置。

在本申请实施例中，处理模块520具体用于：将所述模型描述文件解析为中间数据对象；根据预设代码模版将所述中间数据对象转换为目标工程代码。

在本申请实施例中，处理模块520具体还用于：将所述中间数据对象转换为模版数据对象；根据所述模版数据对象对应的预设代码模版将所述模版数据对象转换为目标工程代码。

在本申请实施例中，处理模块520具体还用于：根据所述网络设备对应的场景和需求将所述中间数据对象转换为模版数据对象。

在本申请实施例中，处理模块520具体还用于：将所述不同的网络设备分别对应的工程代码分发给对应的网络设备，以使对应的网络设备基于所述工程代码配置与其他网络设备之间的通信协议。

通信协议的配置装置500与前述实施例中的通信协议的配置方法对应，各个功能模块与配置方法的各个步骤对应，因此，各个功能模块的实施方式参照各个步骤的实施方式，在此不再重复介绍。

基于同一发明构思，本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，所述计算机程序被计算机运行时，执行前述实施例中所述的通信协议的配置方法。

在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种通信协议的配置方法，其特征在于，包括：

获取模型描述文件；所述模型描述文件包括：用于指示网络设备之间的通信协议的传输层文件、用于指示所述通信协议对应的内容的内容层文件、以及用于指示网络设备之间的接口参数的接口层文件；

将所述模型描述文件编译为工程代码；

根据所述工程代码对所述网络设备之间的通信协议进行配置。

2.根据权利要求1所述的配置方法，其特征在于，所述模型描述文件为基于YAML语法的描述文件，包括多个标签中的至少2个标签，所述多个标签包括：用于描述数据对象的身份标识标签、用于描述数据对象的属性信息的属性标签、用于描述数据对象之间的关联关系的关系标签、用于描述数据对象存储时的索引特征的索引标签、用于描述可排序的属性的名称的名称标签。

3.根据权利要求2所述的配置方法，其特征在于，所述属性标签包括关键字标签，所述关键字标签用于指示对应的属性信息所在的属性文件。

4.根据权利要求1所述的配置方法，其特征在于，所述将所述模型描述文件编译为工程代码，包括：

将所述模型描述文件解析为中间数据对象；

根据预设代码模版将所述中间数据对象转换为目标工程代码。

5.根据权利要求4所述的配置方法，其特征在于，所述中间数据对象对应多个模版数据对象，所述多个模版数据对象对应不同的预设代码模版，所述根据预设代码模版将所述中间数据对象转换为目标工程代码，包括：

将所述中间数据对象转换为模版数据对象；

根据所述模版数据对象对应的预设代码模版将所述模版数据对象转换为目标工程代码。

6.根据权利要求5所述的配置方法，其特征在于，所述将所述中间数据对象转换为模版数据对象，包括：

根据所述网络设备对应的场景和需求将所述中间数据对象转换为模版数据对象。

7.根据权利要求1所述的配置方法，其特征在于，所述工程代码包括不同的网络设备分别对应的工程代码；所述根据所述工程代码对所述网络设备之间的通信协议进行配置，包括：

将所述不同的网络设备分别对应的工程代码分发给对应的网络设备，以使对应的网络设备基于所述工程代码配置与其他网络设备之间的通信协议。

8.根据权利要求1所述的配置方法，其特征在于，所述模型描述文件还包括：扩展描述文件；所述扩展描述文件为可编辑的文件，用于写入扩展的描述信息。

9.一种通信协议的配置装置，其特征在于，包括：

获取模块，用于获取模型描述文件；所述模型描述文件包括：用于指示网络设备之间的通信协议的传输层文件、用于指示所述通信协议对应的内容的内容层文件、以及用于指示网络设备之间的接口参数的接口层文件；

处理模块，用于：将所述模型描述文件编译为工程代码；根据所述工程代码对所述网络设备之间的通信协议进行配置。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被计算机运行时，执行如权利要求1-8任一项所述的通信协议的配置方法。

Images