CN114915533B - 一种基于平台的北向接口实现方法和架构 - Google Patents

Abstract

本发明涉及信息和通信技术领域，提供了一种基于平台的北向接口实现方法和架构。其中发明包括构建北向接口平台，将北向接口所用到的数据结构进行抽象，并根据抽象后形成的标准数据结构，对非产品特性的基础功能构建对应的标准服务接口，形成北向接口平台；构建北向接口产品，将北向接口功能进行抽象后形成北向接口产品，通过调用北向接口平台的标准服务接口或网管服务接口提供北向功能。本发明将原来老的网管产品中的北向接口子系统解耦，构建独立的北向接口平台以及北向接口产品，基于此平台进行的全新架构设计，向第三方开放多种不同格式规范的接口，不同类型接口项目并行开发互不影响，减少多版本之间的合并，提升开发效率。

Description

一种基于平台的北向接口实现方法和架构

【技术领域】

本发明涉及信息和通信技术领域，特别是涉及一种基于平台的北向接口实现方法和架构。

【背景技术】

SDN(Software Defined Network，软件定义网络)作为一种颠覆传统网络的新型网络架构，凭借其快速提供网络服务、实现网络灵活管理、加速网络应用创新、降低运营开销等诸多好处，吸引了众多运营商的广泛关注与青睐。随着我国5G商用的快速推进，SDN也得到了广泛的应用。

SDN的核心是实现网络的可编程控制，推动网络业务的创新，而北向接口恰恰是这一趋势的最关键推动力，通过北向接口，网络业务开发者能以软件编程的形式调用各种网络资源，同时上层的网络资源管理系统可以通过北向接口全局把控整个网络的资源状态，并对资源进行统一调度。

北向接口方面还缺少业界公认的标准。其主要原因是北向接口直接为业务应用服务，其设计需密切联系业务应用需求，具有多样化的特征，很难统一。因此各运营商提出自已的北向接口规范，接口种类繁多，如：CORBA(Common Object Request BrokerArchitecture，通用对象请求代理体系结构)、MTOSI(Multi-Technology OperationsSystem Interface，多重技术运营系统接口)相关的接口：中国电信传输I2、中国电信接入WebService(web服务)、中国联通MTOSI、国际用户MTOSI；SOCKET(套接字)、SNMP(SimpleNetwork Management Protocol，简单网络管理协议)、TL1(Transaction Language-1，业务语言)、SDN相关的接口：SPTN(Software Packet Transport Network，软件定义分组传送网)、SOTN(Software Optical Transport Network，软件定义光传送网)等等。在一个北向接口系统中同时提供众多类型的接口，对架构的设计来说是一个挑战。因每种类型都是不同时间段出现的，新的接口的实现都是在老接口架构上进行的优化，随着接口类型的增多，多个项目的并行开发时，各个项目之间相互冲突，互相影响，架构在各项目开发完成后需进行合并与冲突处理，开发效率低下，且架构上的接口不易扩展，即使勉强扩展后，接口间的冲突也很难完全消除，往往影响工程交付，上工程后也问题不断，使用户体验不佳。

鉴于此，克服该现有技术所存在的缺陷是本技术领域亟待解决的问题。

【发明内容】

本发明要解决的技术问题是：因每种类型接口都是不同时间段出现的，新的接口的实现都是在老接口架构上进行的优化，随着接口类型的增多，多个项目的并行开发时，各个项目之间相互冲突，互相影响，架构在各项目开发完成后需进行合并与冲突处理，开发效率低下，且架构上的接口不易扩展，即使勉强扩展后，接口间的冲突也很难完全消除，往往影响工程交付，上工程后也问题不断，使用户体验不佳。

本发明为了解决上述技术问题，提供一种基于平台的北向接口实现方法和架构，将原来老的网管产品中的北向接口子系统解耦，构建独立的北向接口平台以及北向接口产品，使不同类型接口项目并行开发互不影响，减少多版本之间的合并，提升开发效率。

本发明采用如下技术方案：

第一方面，提供一种基于平台的北向接口实现方法，包括：

构建北向接口平台，将北向接口所用到的数据结构进行抽象，并根据抽象后形成的标准数据结构，对非产品特性的基础功能构建对应的标准服务接口，形成北向接口平台；

构建北向接口产品，将北向接口功能进行抽象后形成北向接口产品，通过调用北向接口平台的标准服务接口或网管服务接口提供北向功能；

北向接口产品将接口按功能分解为同产品特性相关的子接口以及同产品特性无关的子接口，在接收到第三方网管的调用请求时，若请求的接口类型为同产品特性相关的接口，则选择直接调用相关的网管服务接口；若请求的接口类型为同产品特性无关的接口，则选择调用北向接口平台的标准服务接口。

进一步的，在将各类型接口功能进行抽象后形成北向接口产品时，还包括：

将提供给第三方网管调用的各种类型的接口的处理流程抽象形成一个或者多个处理模型，所述处理模型的处理机制放入到北向接口平台中。

进一步的，在接收到第三方网管的调用请求时，还包括：

对请求的接口所需的对象数据进行模型转换，将请求的规范标准数据模型转化为网管私有的数据模型。

进一步的，还包括：对各接口返回的结果进行数据合并后返回给第三方网管。

进一步的，所述对各接口返回的结果进行数据合并后返回给第三方网管具体包括：

将从网管获取的私有数据整合合并为规范标准数据格式，并将合并后的数据一次性返回给第三方网管。

进一步的，其特征在于，所述第三方网管调用的接口包括：

第三方网管调用请求的设备类型为OTN设备时，调用的接口包括SOTN接口和I2接口；

第三方网管调用请求的设备类型为5G设备时，调用的接口包括SPTN接口和Socket接口；

第三方网管调用请求的设备类型为PON设备时，调用的接口包括TL1接口和Corba接口。

进一步的，所述北向接口平台的多个基础功能包括告警/性能处理、安全处理、数据存储、缓存处理、模型转换、上报处理、通信协议、网管接口中的一项或者多项。

第二方面，提供一种基于平台的北向接口实现架构，包括北向接口平台和北向接口产品，其中：

所述北向接口产品包括I2、SOCKET、CORBA、SPTN、TAPI中的一种或多种接口产品，用于给第三方网管提供接口服务；

所述北向接口平台包括告警/性能处理模块、安全处理模块、数据存储模块、缓存处理模块、模型转换模块、上报处理模块、通信协议模块、网管接口模块中的一项或者多项，用于实现无产品特性的基本功能。

进一步的，所述北向接口产品还包括用于与北向接口平台交互的平台接口客户端以及用于与网管服务交互的产品功能接口客户端，若第三方网管请求的接口类型为同产品特性相关的子接口，则选择产品功能接口客户端来实现网管服务接口调用服务；若第三方网管请求的接口类型为同产品特性无关的子接口，则选择平台接口客户端来实现北向接口平台服务接口调用服务。

进一步的，所述架构包括视图层、数据转换层、公共层和代理层，其中，视图层、数据转换层、公共层和代理层之间依次逻辑关联，具体的：

所述视图层用于对第三方网管开放接口；

所述数据转换层用于将第三方网管请求的规范标准数据模型转化为网管的私有数据模型；

所述公共层用于为各个第三方网管处理其所涉及的基础功能模块中的服务支撑；

所述代理层位于公共层和网管核心服务之间，所有与网管接口的调用都通过代理层完成交互。

本发明将原来老的网管产品中的北向接口子系统解耦，构建独立的北向接口平台以及北向接口产品。将各种接口同网管的交互、数据的存储、模型转换、告警性能的处理、上报处理机制等没有产品特性的功能进行抽象解耦后形成一个北向接口平台，基于此平台进行的全新架构设计，向第三方开放多种不同格式规范的接口，不同类型接口项目并行开发互不影响，减少多版本之间的合并，提升开发效率。本发明面向接口编程，遵行开放封闭原则，具有独立的版本发布，定制化服务安装，可提升运行效率，便于扩展与维护。

【附图说明】

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

图1是本发明实施例1提供的一种基于平台的北向接口实现方法的流程图；

图2是本发明实施例1提供的原有的北向接口子系统的架构示意图；

图3是本发明实施例2提供的一种基于平台的北向接口实现架构示意图；

图4是本发明实施例2提供的架构细化示意图；

图5是本发明实施例2提供的架构搭建流程示意图；

图6是本发明实施例2提供的步骤S1的具体流程示意图；

图7是本发明实施例2提供的步骤S2的具体流程示意图；

图8是本发明实施例2提供的架构分层后接口功能的实现逻辑示意图；

图9是本发明实施例3提供的一种基于平台的北向接口实现装置示意图。

【具体实施方式】

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

在本发明的描述中，术语“内”、“外”、“纵向”、“横向”、“上”、“下”、“顶”、“底”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明而不是要求本发明必须以特定的方位构造和操作，因此不应当理解为对本发明的限制。

此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。

实施例1:

如图1所示，本发明实施例1提供了一种基于平台的北向接口实现方法，包括如下步骤：

步骤100：构建北向接口平台，将北向接口所用到的数据结构进行抽象，并根据抽象后形成的标准数据结构，对非产品特性的基础功能构建对应的标准服务接口，形成北向接口平台。该步骤将已有的北向接口子系统所用到的数据结构进行重构，只保留不涉及网管私有数据结构的基础功能，以便解耦生成多个基础功能模块，并将这些基础功能模块组合形成北向接口平台。

步骤200：构建北向接口产品，将北向接口功能进行抽象后形成北向接口产品，通过调用北向接口平台的标准服务接口或网管服务接口提供北向功能。步骤100的平台已经实现了基本功能及同网管系统的交互，本步骤构建北向接口产品后，将同产品特性及接口类型相关部分放在产品层也即北向接口产品中，各类接口产品都依赖于同一北向接口平台，各类型接口产品同不同的网管产品进行适配，接口产品可成为网管产品的一个子系统给运营商的第三方网管提供服务。

步骤300：北向接口产品将接口按功能分解为同产品特性相关的子接口以及同产品特性无关的子接口，在接收到第三方网管调用请求时，根据请求的接口类型选择调用北向接口平台服务接口或网管服务接口。该步骤实现新的北向接口系统(北向接口产品、北向接口平台合在一起作为新的北向接口系统)、网管以及第三方网管的交互，通过解耦后的北向接口平台以及北向接口产品来实现原有的北向接口子系统所具备的功能。

通过上述步骤，本实施例将原来老的网管产品中的北向接口子系统解耦，构建独立的北向接口平台以及北向接口产品，通过北向接口平台以及北向接口产品既能实现原有北向接口子系统与网管、第三方网管的交互，又能使不同类型接口项目并行开发互不影响，减少多版本之间的合并，提升开发效率。

需要说明的是，如图2所示的现有技术中原有的北向接口是作为网管系统的一个子系统存在，北向接口同网管核心服务之间都是面对模块进行编程，存在编译依赖和运行依赖。这种依赖使网管核心服务有更新，北向接口子系统也必须同步编译更新，影响开发效率。子系统各模块对网管依赖关系及相互依赖关系复杂，难于开发与维护。新增加一个功能，几乎每个模块都需改动，影响模块的稳定性。为解决编译依赖问题，本实施例将原来面向模块编程统一转为接口编程，使模块之间只依赖于接口的定义与二进制包，只要接口定义未发生变化，一个模块内部的问题修改及优化等不会影响到其它模块，同时网管核心服务的变化也被透明化，北向接口子系统从原来的网管系统中移出进行独立的配置管理。

本优选实施例在北向接口子系统同网管系统解耦后，进行整体架构的优化调整，将各种接口同网管的交互、数据的存储、模型转换、告警性能的处理、上报处理机制、大数据的处理等无产品特性的功能形成北向接口平台，所有同网管系统的基础交互都通过平台来进行。具体的，在本实施例的步骤100中，所述北向接口平台的多个基础功能包括告警/性能处理、安全处理、数据存储、缓存处理、模型转换、上报处理、通信协议、网管接口中的一项或者多项，相对应的，解耦生成多个基础功能模块也包括告警/性能处理模块、安全处理模块、数据存储模块、缓存处理模块、模型转换模块、上报处理模块、通信协议模块、网管接口模块中的一项或者多项。其中，告警/性能处理模块用于设备告警、性能数据的获取、分析以及相关管理；安全处理模块用于设备使用的各种权限管理；数据存储模块用于设备告警、性能数据、配置数据的分析管理存取；缓存处理模块用于大数据量时为保证数据获取效率对一些非实时数据进行本地缓存；模型转换模块用于完成标准数据模型与网管私有的数据模型之间的转换；上报处理模块用于对设备的一些告警、事件进行接受与处理；通信协议模块用于北向同设备进行交互的南向接口的各种协议的实现；网管接口用于北向同网管基础平台之间接口。

原有北向系统的多个并行项目大多是不同产品线不同接口类型在同一时间段提供，例如OTN产品线的ACTN、SOTN，分组交付的SPTN接口都是同时在开发(即图2中的北向视图层)。在原来北向接口子系统的架构上(参考图2)，各类型的接口在新增功能时都会修改相同的模块，因各项目是由不同人员并行开发，所以经常会出现冲突问题，在各项目完成后，需要进行大量代码的合并，合并后需进行大量的测试，测试产生的状况要花费大量的人力处理，开发效率低下。同时如若新增加一个接口类型，基本大部分的模块都需要修改，可扩展性差。在本实施例的新方法下，北向接口平台已将公共功能抽象提取出来，一般情况下都不会改动，各项目只关注有产品特性的功能，不会互相冲突，也不必进行代码的合并。同时通过平台层屏蔽了产品同网管系统的交互，网管核心服务的变化也不会影响到北向产品项目的开发。

在本实施例的步骤200中，在将各类型接口功能进行抽象后形成北向接口产品时，还包括：将提供给第三方网管调用的各种类型的接口的处理流程抽象形成一个或者多个处理模型，所述处理模型的处理机制放入到北向接口平台中。以在第三方网管调用接口时，直接选择相应处理模型的处理机制来进行处理。

在本实施例的步骤300中，在接收到第三方网管调用请求时，根据请求的接口类型选择调用北向接口平台服务接口或网管服务接口具体包括：若请求的接口类型为同产品特性相关的子接口，则选择调用相关的网管服务接口；若请求的接口类型为同产品特性无关的子接口，则选择调用北向接口平台服务接口。另外，在接收到外部调用请求时，还包括：将请求的接口所需的对象数据进行模型转换，以将请求的规范标准数据模型转化为网管私有的数据模型。

在本优选实施例中，第三方网管调用的接口包括：第三方网管调用请求的设备类型为OTN设备时，调用的接口包括SOTN接口和I2接口；第三方网管调用请求的设备类型为5G设备时，调用的接口包括SPTN接口和Socket接口；第三方网管调用请求的设备类型为PON设备时，调用的接口包括TL1接口和Corba接口。

在本优选实施例中，方法还包括：对各接口返回的结果进行数据合并后返回给第三方网管。具体的，需要将从网管获取的私有数据整合合并为规范标准数据格式，并将合并后的数据一次性返回给第三方网管。

在本优选实施例中，新的北向接口系统支持版本定义，独立发布。具体的，北向接口系统按接口类型进行产品的划分，不同接口的类型对应的规范和标准不一样。大版本按所支持的规范和标准来划分，子版本按所支持的设备类型进行细分。例如。NBI V X.X.X第一个X对应接口的类型，第二个X代表对应的接口规范，第三个X对应所支持的设备类型。北向接口平台具有独立的版本管理，以二进制包的形成提供给北向接口产品从而向运营商软件提供服务。用户在工程使用时根据使用场景和所管理的设备进行定制性安装布置。

通过上述方法，本实施例将原来老的网管产品中的北向接口子系统解耦，构建独立的北向接口平台以及北向接口产品。将各种接口同网管的交互、数据的存储、模型转换、告警性能的处理、上报处理机制等没有产品特性的功能进行抽象解耦后形成一个北向接口平台，基于此平台进行的全新架构设计，向第三方开放多种不同格式规范的接口，不同类型接口项目并行开发互不影响，减少多版本之间的合并，提升开发效率。本实施例面向接口编程，遵行开放封闭原则，具有独立的版本发布，定制化服务安装，可提升运行效率，便于扩展与维护。

实施例2:

如图3所示，本发明实施例1提供了一种基于平台的北向接口实现架构，该架构包括视图层、数据转换层、公共层和代理层，其中，视图层、数据转换层、公共层和代理层之间依次逻辑关联，具体的：所述视图层用于对第三方网管(第三方网管或第三方APP)开放接口；所述数据转换层用于将第三方网管请求的规范标准数据模型转化为网管的私有数据模型；所述公共层用于为各个第三方网管处理其所涉及的基础功能模块中的服务支撑；所述代理层位于公共层和网管核心服务(网管服务层)之间，所有与网管接口的调用都通过代理层完成交互。

具体的，本实施例的架构还可以转化为如图4所示，其中的北向接口产品(也即图3中的视图层)用于给第三方网管提供接口服务，具体包括各种接口产品(如I2、SOCKET、CORBA、SPTN、TAPI等)。另外，所述北向接口产品(视图层)还包括用于与北向接口平台交互的平台接口客户端(北向接口平台服务接口调用服务)、用于与网管服务交互的产品功能接口客户端(网管服务接口调用服务)，若第三方网管请求的接口类型为同产品特性相关的子接口，则选择产品功能接口客户端来实现网管服务接口调用服务，调用网管服务中的产品服务(根据需要调用对应服务，如OTN产品服务、分组产品服务、PON产品服务等)；若第三方网管请求的接口类型为同产品特性无关的子接口，则选择平台接口客户端来实现北向接口平台服务接口调用服务，调用网管服务中的网管基础功能服务。本实施例的北向接口平台用于实现无产品特性的基本功能，可以细化为告警/性能处理模块、安全处理模块、数据存储模块、缓存处理模块、模型转换模块、上报处理模块、通信协议模块、网管接口模块中的一项或者多项。其中，各模块的主要功能已在实施例1中描述，这里就不赘述了。本实施例的图3和图4是对本实施例架构不同粒度的逻辑划分，其中北向视图层对应北向接口产品，数据转换层、公共层以及代理层对应北向接口平台，图3可表示从APP应用整个处理过程的逻辑，其中的数据转换层和代理层是对图4中北向接口平台更细的逻辑层次划分，例如图4中的模型转换模块只是图3中数据转换层的一部分，数据转换层还有对数据进行清洗与整合的功能。还需说明的是，本实施例图3的代理层在功能逻辑上也并非完全属于图4中的北向接口平台，例如所有与网管接口的调用都通过代理层来完成交互，这个交互就既包括了北向接口平台与网管基础功能服务的交互，也包括了北向接口产品与网管产品服务的交互。

下面通过具体的流程来说明本实施例架构的搭建过程。如图5所示，本实施例的架构搭建主要包括：

步骤S1：同网管系统解耦构建独立的北向系统；

步骤S2：平台定义，构建平台；

步骤S3：将平台同产品分离；

步骤S4：版本定义，独立发布。

其中，如图6所示，步骤S1具体包括如下过程。

S11、梳理原有北向接口子系统同网管核心服务之间的接口，将接口进行规范定义。按接口编程的思想，子系统的编译只依赖于接口定义文件和所依赖模块的二进制包。原北向接口子系统同网管接口分散到多个网管后台服务，接口的数据交互中含有网管的私有数据结构，同网管服务成紧耦合关系，在编译时时依赖网管服务的一些头文件。在本实施例中将接口所用到的数据结构进行抽象，去掉私有数据结构的使用，制定接口兼容性规范，使其在windows和linux系统下能正确的编译与运行。制定接口设计规范，可缓解接口数据的源兼容性、二进制兼容性、语义兼容性。

S12、源码用独立的版本控制系统管理，独立进行编译与打包发布。其中，版本控制系统优选但不限定于SVN(是一个开放源代码的版本控制系统)。这里对源码进行独立进行编译与打包发布是为了与网管系统分开管理，使现有的北向系统与网管系统解耦更彻底。

S13、将功能实现进行层次划分，明确层与层之间的调用关系，北向系统同网管系统之间的调用只留一个模块通道。

层次划分后的系统如图3所示，可将系统纵向分为视图层、数据转换层、公共层、代理层。视图层对第三方APP开放接口，提供服务。数据转换层将第三方APP请求的规范标准数据模型转化为网管私有的数据模型。公共层为各接口类型处理公用的处理模块。代理层是北向系统同下层网管核心服务通信的唯一通道。系统同网管核心服务之间构建一个代理层，所有同网管接口的调用都在代理层进行相关的处理。同时代理层进行上报的订阅与处理转发，代理层收到上报后，进行数据处理后再分发给各自的处理模块进行相应的处理。

本实施例的步骤S2是为了解决多项目并行开发引起冲突，并行项目完成后进行大面积的代码合并的问题，同时遵循软件设计中的开放封闭原则，在新增一种接口类型或新增接口功能时只新增或修改一个模块。如图7所示，步骤S2具体包括如下过程。

S21、对已有的功能进行梳理分类。北向接口系统对外提供的服务可分两大类，一类是对外第三方APP开放服务接口，响应第三方APP的调用请求，这类功能抽象为资源的获取、业务的发放、相关告警、性能、状态的监控。另一类是北向接口向第三方APP的主动上报，第三方APP注册订阅后，当网络出现告警、资源或业务发生变化时向已注册APP进行主动上报变化。

S22、将各种接口同网管的交互、数据的存储、模型转换、告警性能的处理、上报处理机制、大数据处理、网络连接、数据的缓存等同设备产品特性无关的功能、技术与处理机制形成为北向接口平台。以上的模块是北向接口内部处理模块，同对外开放的接口类型无关(这里指代的对外开放是说第三方APP)，同运营商的设备类型无关，是各种接口类型共用的模块。功能实现后，不会因接口功能的增加或用户需求的变化而改变。这些功能模块功能比较稳定，不会轻易变更，所以将其形成北向接口平台，在此平台上可开发各种接口类型的服务开放给第三方APP使用。

S23、将各类型接口功能进行抽象后也放入平台。将各种类型的接口的处理流程进行抽象形成统一的处理模型，模型的处理机制放入到北向接口平台中，当新增接口类型时，只需在产品层进行模型的适配即可。

S24、构建基于平台的系统新架构。最后如图4所示。

本实施例中步骤S3的将平台同产品分离的具体实施方案为：将原来子系统中视图层模块进行拆分为产品相关和平台相关两部分，产品相关上浮到产品层(北向接口产品)，将平台相关功能下沉到平台层(北向接口平台)，分层后接口功能的实现逻辑如图8所示，包括如下过程。

S31、第三方网管通过规范的接口向北向视图层(也即北向接口产品层)发送调用请求。

S32、数据转换层将接口所需的对象数据进行模型转换。接口对外提供服务的对象如：网元、单盘(对应图4中的数据存储)、告警、性能(对应图4中的告警/性能处理)、业务等，每种对象有各自的属性，属性是根据北向接口的规范和标准来确定。但网管管理的对象并不同北向接口的管理对象的属性一一对应，网管的管理对象的属性更细更多，带有内部的私有性。故网管核心提供的数据模型同北向接口对外提供服务的数据模型存在一定的差异性，故需进行模型转换，将第三方网管请求的规范标准数据模型转化为网管的私有数据模型，当数据量很大时，模型的转换效率对北向接口对外提供服务的效率具有一定的影响。

S33、将接口的功能分解为同产品特性相关与无关两大类型的子接口。一个外部的接口请求可能分解为多个子接口。北向接口对外提供的服务的粒度比较粗，如：导出所有的网元对象、导出所有业务信息、查询网元的所有告警性能状态等，这些第三方APP请求调用，北向接口需要将这些大的接口进行细分为多个内部子接口，通过多个内部子接口向网管服务发出请求。这些内部子接口，有些是同具体的设备产品有关，如OTN光层业务(对应图4中网管服务的OTN产品服务)、电层业务带有产品特性的，有些是一些通用的接口，如网元的属性、单盘的状态等(对应图4中北向接口平台的数据存储)。同产品特性相关的接口将调用网管服务的各产品服务模块。通用的接口通过北向接口平台调用网管基础功能服务模块。北向接口系统将这些子接口调用的结果进行分析组织后返回给第三方APP使用。

S34、同产品无关特性的子接口调用北向平台服务接口，同产品特性相关的子接口调用相关的网管服务接口(例如调用图4中的OTN产品服务、分组产品服务、PON产品服务)。

S35、对各子接口的返回的结果按接口规范进行数据合并。各子接口返回的数据都比较零散，很多数据因性能问题都通过批量进行处理，从网管获取到的数据都是离散的，北向接口系统按照逻辑关系按接口规范格式进行整合合并后再返回给第三方APP。

S36、将合并后的数据一次性返回给第三方APP调用者。返回第三方APP的数据为按北向接口规范各标准来组织的，该过程需要通过数据转换层进行逆向转化，将网管的私有数据模型转化为规范标准数据模型。北向接口的规范和标准是由国际或国内一些权威机构制定，是设备产商和运营商之间达成一致的协议。第三方APP获取数所后可进行数据解析构建自已的应用。

为便于对本实施例上述步骤的理解，下面给出一个具体的实例：

分组设备运营商第三方APP发送获取某一网元的所有业务的请求，北向接口产品层的SPTN接口服务接收到请求，进行对象模型的转换，模型转换后将获取业务的接口进行子接口的分解，先进行网元所有业务ID的获取，获取业务ID后，根据业务ID进行业务属性的获取。业务ID获取功能同设备产品特性无关，通过平台接口客户端调用北向接口平台，北向接口平台通过代理层调用网管基础功能服务接口获取相关的数据。获取业务ID后，北向接口产品层SPTN接口服务进行再次进行接口的分解，分解为通过业务ID获取业务基本属性，以及通过业务ID获取业务的定位信息、状态等特殊属性，通过产品功能接口客户端调用分组产品服务批量获取相关的信息。所有数据获取后，再将这几种批量的离散数据以业务ID为关键字，组织成一条完成的接口规范数据返回给第三方APP。

上报处理为上述整个调用过程的逆向过程，第三方APP可以通过注册接口订阅北向接口产品服务的上报，注册和订阅功能与具体的产品特性无关为北向接口平台的功能。北向接口平台向网管基础功能服务注册和订阅上报。当管理的网络有告警或数据的更新时，网管基础功能服务向北向接口平台发送上报信息，北向接口平台将上报的信息分发给北向接口产品层的接口服务，北向接口产品层接口报务对上报信息进行相关的数据模型转换以及数据的整合后，发送相关的上报信息给第三方APP。

本实施例中步骤S4的具体实施方案包括：将所有的接口类型以插件的形成集中在一个完整的北向接口系统中(也即北向接口产品)。北向接口系统的版本按所支持的规范和标准、所支持的设备类型来进行划分，例如。NBI V X.X.X，第一个X对应所支持的接口类型，当新增一个接口类型时这个版本就会更新。第二个X代表对应的接口规范，当所支持的接口规范更新时，此版本号相应更新。第三个X对应所支持的设备类型，同一接口类型，当有新增设备时要进行适配，对应的版本号也相应更新。在上述更新过程中，北向接口平台不需更新，仅新增对新接口和设备的支持。另外，每种类型接口产品提供一个独立的服务，不同的设备类型对应相应的接口，如OTN设备有SOTN、I2接口等，分组5G设备有SPTN、Socket接口等，PON设备有TL1、Corba接口等。用户可根据所使用的场景及设备进行定制性安装相关的接口服务。如工程上只有OTN设备，只安装SOTN、I2接口服务就可以了，如果新增了分组设备，再添加SPTN接口。

通过本实施例所提供的架构，将原来老的网管产品中的北向接口子系统解耦，构建独立的北向接口平台以及北向接口产品。将各种接口同网管的交互、数据的存储、模型转换、告警性能的处理、上报处理机制等没有产品特性的功能进行抽象解耦后形成一个北向接口平台，基于此平台进行的全新架构设计，向第三方开放多种不同格式规范的接口，不同类型接口项目并行开发互不影响，减少多版本之间的合并，提升开发效率。本实施例还面向接口编程，遵行开放封闭原则，具有独立的版本发布，定制化服务安装，可提升运行效率，便于扩展与维护。

实施例3:

如图9所示，是本发明实施例3提供的一种基于平台的北向接口实现装置结构示意图。本实施例的基于平台的北向接口实现装置包括一个或多个处理器21以及存储器22。其中，图9中以一个处理器21为例。

处理器21和存储器22可以通过总线或者其他方式连接，图9中以通过总线连接为例。

存储器22作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序和非易失性计算机可执行程序，如实施例1中的基于平台的北向接口实现方法。处理器21通过运行存储在存储器22中的非易失性软件程序和指令，从而执行基于平台的北向接口实现方法。

存储器22可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，存储器22可选包括相对于处理器21远程设置的存储器，这些远程存储器可以通过网络连接至处理器21。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

所述程序指令/模块存储在所述存储器22中，当被所述一个或者多个处理器21执行时，执行上述实施例1、实施例2中的基于平台的北向接口实现方法、系统功能，例如，执行以上描述的图1、图8所示的各个步骤。

值得说明的是，上述装置和系统内的模块、单元之间的信息交互、执行过程等内容，由于与本发明的处理方法实施例基于同一构思，具体内容可参见本发明方法实施例中的叙述，此处不再赘述。

本领域普通技术人员可以理解实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取存储器(RAM，Random AccessMemory)、磁盘或光盘等。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (9)

1.一种基于平台的北向接口实现方法，其特征在于，包括：

构建北向接口平台，将北向接口所用到的数据结构进行抽象，并根据抽象后形成的标准数据结构，对非产品特性的基础功能构建对应的标准服务接口，形成北向接口平台；

构建北向接口产品，将北向接口功能进行抽象后形成北向接口产品，通过调用北向接口平台的标准服务接口或网管服务接口提供北向功能；

北向接口产品将接口按功能分解为同产品特性相关的子接口以及同产品特性无关的子接口，在接收到第三方网管的调用请求时，若请求的接口类型为同产品特性相关的接口，则选择直接调用相关的网管服务接口；若请求的接口类型为同产品特性无关的接口，则选择调用北向接口平台的标准服务接口。

2.根据权利要求1所述的基于平台的北向接口实现方法，其特征在于，在将各类型接口功能进行抽象后形成北向接口产品时，还包括：

将提供给第三方网管调用的各种类型的接口的处理流程抽象形成一个或者多个处理模型，所述处理模型的处理机制放入到北向接口平台中。

3.根据权利要求1所述的基于平台的北向接口实现方法，其特征在于，在接收到第三方网管的调用请求时，还包括：

对请求的接口所需的对象数据进行模型转换，将请求的规范标准数据模型转化为网管私有的数据模型。

4.根据权利要求1所述的基于平台的北向接口实现方法，其特征在于，还包括：对各接口返回的结果进行数据合并后返回给第三方网管。

5.根据权利要求4所述的基于平台的北向接口实现方法，其特征在于，所述对各接口返回的结果进行数据合并后返回给第三方网管具体包括：

将从网管获取的私有数据整合合并为规范标准数据格式，并将合并后的数据一次性返回给第三方网管。

6.根据权利要求1-5任一所述的基于平台的北向接口实现方法，其特征在于，所述第三方网管调用的接口包括：

第三方网管调用请求的设备类型为OTN设备时，调用的接口包括SOTN接口和I2接口；

第三方网管调用请求的设备类型为5G设备时，调用的接口包括SPTN接口和Socket接口；

第三方网管调用请求的设备类型为PON设备时，调用的接口包括TL1接口和Corba接口。

7.根据权利要求1-5任一所述的基于平台的北向接口实现方法，其特征在于，所述北向接口平台的多个基础功能包括告警/性能处理、安全处理、数据存储、缓存处理、模型转换、上报处理、通信协议、网管接口中的一项或者多项。

8.一种基于平台的北向接口实现架构，其特征在于，包括北向接口平台和北向接口产品，其中：

所述北向接口产品包括I2、SOCKET、CORBA、SPTN、TAPI中的一种或多种接口产品，用于给第三方网管提供接口服务；

所述北向接口平台包括告警/性能处理模块、安全处理模块、数据存储模块、缓存处理模块、模型转换模块、上报处理模块、通信协议模块、网管接口模块中的一项或者多项，用于实现无产品特性的基本功能；

所述北向接口产品还包括用于与北向接口平台交互的平台接口客户端以及用于与网管服务交互的产品功能接口客户端，若第三方网管请求的接口类型为同产品特性相关的子接口，则选择产品功能接口客户端来实现网管服务接口调用服务；若第三方网管请求的接口类型为同产品特性无关的子接口，则选择平台接口客户端来实现北向接口平台服务接口调用服务。

9.根据权利要求8所述的基于平台的北向接口实现架构，其特征在于，所述架构包括视图层、数据转换层、公共层和代理层，其中，视图层、数据转换层、公共层和代理层之间依次逻辑关联，具体的：

所述视图层用于对第三方网管开放接口；

所述数据转换层用于将第三方网管请求的规范标准数据模型转化为网管的私有数据模型；

所述公共层用于为各个第三方网管处理其所涉及的基础功能模块中的服务支撑；

所述代理层位于公共层和网管核心服务之间，所有与网管接口的调用都通过代理层完成交互。

Images