CN113519141A - 用于数据完整性的模型驱动的服务回滚机制 - Google Patents

Abstract

一种用于对基于模型的供应网络设备配置的回滚的系统和方法，包括：存储器，存储器能够存储包括数据模板序列的基于模型的供应数据模板。在确定目标设备的预配置数据的取回消息之后，与传输目标对象请求消息的请求相关联的数据被接收和传输。预配置数据被存储，并且指定CRUD语义的目标对象请求消息被传输。指示执行结果的通知被接收，并且如果执行结果不成功，则指定CRUD语义的回滚栈被取回，并且预配置参数被取回以将目标设备恢复到预请求状态。如果执行结果成功，则第二目标对象请求消息从目标设备列表被取回。

Description

用于数据完整性的模型驱动的服务回滚机制

相关申请的交叉引用

本申请要求于2019年2月8日提交的标题为“MODEL-DRIVEN SERVICE ROLLBACKMECHANISM FOR DATA INTEGRITY(用于数据完整性的模型驱动的服务回滚机制)”的美国临时专利申请第62/704,057号的优先权，其内容通过引用整体并入本文。

技术领域

本公开涉及用于服务数据的分布式网络数据完整性。更具体地，本公开涉及使用电信应用的模型驱动供应为服务提供自动化数据完整性的系统和方法。

背景技术

数据完整性要求存储的数据在其驻留的系统中的服务生命周期内是可靠并准确的。为了实现、利用和更改数据，网络提供方必须维持主动系统，该系统在存储系统内执行功能之前和之后都对数据的完整性进行调节。

电信应用也往往是长期存在的并且经常被重新配置。例如，在支持消费者移动客户的网络中，每次有额外的消费者加入网络或更改其账户时，许多网络节点和后端业务系统都需要进行配置。单个网络服务事务可能涉及目标设备内和跨一个事务中的若干目标设备的多种类型的操作。例如，在电信网络系统中，诸如订户身份模块(SIM)交换之类的用户的更新信息需要在单个目标设备(诸如归属订户服务器(HSS))内并且跨目标设备(诸如网络内的HSS、策略和计费规则功能(PCRF)和电信应用服务器(TAS))进行多个删除、读取、创建和更新操作，以使得适当更新每个节点以反映该事务。

目前，服务异常情况下的数据完整性是通过单独检查每个网络节点以确定其中存储的数据与数据的异常服务状态之前的数据状态相比是否准确来实现的。当前的手动数据完整性确认程序要求个体运营方或硬件提供方保持存储在其控制内的个体网络设备上的数据的服务前记录。当请求服务时，自动化的模型驱动服务跨所有网络设备系统地被应用到网络(即，推出(rollout))。推出可以由创建、取回、更新和删除(在本文中也被称为CRUD语义)生命周期的操作组成，用于在每个网络设备上进行实例化。如果对于任何网络设备，服务失败，则服务被停止，并且每个网络设备必须由其相应的运营方进行检查以用服务前状态来确认数据完整性。只有在对每个网络节点进行全面检查后，从推出中的触发异常开始向后工作，分布式网络提供方才能确认数据完整性。鉴于电信应用受益于网络管理的无代理方法，此过程既耗时又低效。

传统上，用于电信环境中这些频繁更新选项的最终集成点是运营支持系统/业务支持系统(OSS/BSS)系统。然而，将更改集成到网络中的设备和/或服务往往非常耗时且非常昂贵，需要在OSS/BSS系统中进行自定义代码开发——其本身就是一个非常庞大、复杂和定制化的系统。另外，当实现的更改或服务失败时，需要手动检查以执行类似于数据完整性确认过程的任何过程，因为网络设备无法将服务前状态传递到中央位置。最终结果，即使在花费充足的时间和金钱之后，该程序也不是高度自动化的，而是引导用户通过一组连续的图形用户界面(GUI)屏幕，通常每个类型的设备需要配置以支持整体服务并确保分布式系统哦其服务前状态的数据完整性。

发明内容

本文公开了一种用于对基于模型的供应网络设备配置的回滚的系统和方法。在一些实施例中，该系统和方法包括：存储器，该存储器能够存储包括数据模板序列的基于模型的供应数据模板；以及处理器，与该存储器通信，该处理器被配置为读取存储在该存储器中的基于模型的供应数据模板并且使得处理器：接收与向将从目标设备类型列表中选择的目标设备传输目标对象请求消息的请求相关联的数据，目标对象请求消息定义目标设备的能力，并且这些能力来自数据与目标设备相关联的存储库。在一些实施例中，处理器还被配置为：向目标设备传输取回消息；响应于该取回消息，从目标设备接收目标对象响应消息，目标对象响应消息包括目标设备的预配置数据；并且将目标对象响应消息的预配置数据存储在与基于模型的供应数据模板相关联的高速缓存中。在一些实施例中，处理器还被配置为向目标设备传输目标对象请求消息，目标对象请求消息包括基于与目标设备类型、目标设备类型协议和用户提供的数据相关联的第一对象参数来指定创建、读取、更新和删除(CRUD)语义的配置参数。在一些实施例中，处理器还被配置为从目标设备接收指示目标对象请求消息的执行结果的通知，以及如果目标对象请求消息的执行结果是目标对象请求消息的不成功执行，则取回与目标对象请求消息相关联的回滚栈，该回滚栈指定与配置参数相关联的CRUD语义；从高速缓存取回目标对象响应消息的预配置数据；请求目标设备基于预配置数据执行回滚栈以将目标设备恢复到预请求状态。在一些实施例中，如果目标对象请求消息的执行结果是目标对象请求消息的成功执行，则处理器被配置为从目标设备的列表取回第二目标对象请求消息。

在一些实施例中，该系统和方法还被配置为使得处理器可以请求目标设备执行回滚栈，包括以回滚栈的相反顺序执行回滚栈以作为配置目标对象请求消息中的参数的逆操作。在其他实施例中，处理器请求目标设备执行回滚栈，包括根据由运营方定义的操作指定的顺序将回滚栈作为运营方定义功能来执行。在一些实施例中，运营方定义的操作包括在操作时定制的多个公式参数类型。在其他实施例中，第二目标对象请求消息与第二目标设备相关联。在一些实施例中，向目标设备传输目标对象请求消息的请求包括由基于模型的供应模板的数据模板序列定义的多个目标设备的请求消息序列。在一些实施例中，处理器还被配置为针对多个目标设备中的每个目标设备重复步骤b)-h)中的每一步。

在一些实施例中，该系统和方法还被配置为使得处理器可以在将目标设备恢复到预请求状态之后传输指示目标对象请求消息的执行不成功的通知。在一些实施例中，配置参数包括可导入表格，可导入表格与可从服务器导入到数据库中的数据相关联。在一些实施例中，基于模型的供应数据模板包括由运营方定义的目标设备类型序列，包括统一通信即服务(UCaaS)、Zhone、视频监控即服务(VSaaS)、分组数据网络网关(PGW)、服务网关(SGW)、策略和计费规则功能(PCRF)、归属用户服务器(HSS)、iNum和电信应用服务器(TAS)。在其他实施例中，逆操作具有多个参数类型，多个参数类型中的每一种包括运营方定义的函数，运营方定义的函数除了目标对象请求消息中的参数字段之外还定义附加参数字段。在一些实施例中，传输目标对象请求消息包括能够保留与目标设备相关联的预配置数据的目标设备特定操作。在一些实施例中，接收与传输目标对象请求消息的请求相关联的数据还包括确定在基于模型的供应数据模板内是否启用了目标设备类型的自动路由。在一些实施例中，目标设备类型协议包括表现层状态转移(REST)协议、结构化查询语言(SQL)协议、简单对象访问协议(SOAP)、安全文件传输协议/安全外壳协议(SFTP/SSH)、简单网络管理协议(SNMP)和网络和配置协议(NETCONF)中的至少一种。

附图说明

当结合以下附图考虑时，参考所公开主题的以下具体实施方式，可以更充分地理解所公开主题的各种目的、特征和优点，其中相同的附图标记表示相同的元素。

图1是示出根据本公开一些实施例的服务自动化平台部署的系统图。

图2是示出根据本公开一些实施例的用移动虚拟网络运营方(MVNO)对信息进行操纵的系统图。

图3是根据本公开一些实施例的服务模型构建器和服务模型事务器的系统图。

图4A-图4C是根据本公开一些实施例的服务实例管理的对象关系图。

图5A是示出根据本公开一些实施例的服务模型构建器用户界面的屏幕截图，该服务模型构建器用户界面具有包括服务模型段和属性段的服务组件关联。

图5B是示出根据本公开一些实施例的服务模型构建器用户界面的屏幕截图，该服务模型构建器用户界面具有包括服务组件部件段、服务组件属性段和服务组件属性编辑段的一个服务组件的参数视图。

图5C是示出根据本公开一些实施例的服务模型构建器用户界面的屏幕截图，该服务模型构建器用户界面具有包括被分成目标元素组的服务模型序列视图的服务组件的序列视图。

图6是示出根据本公开一些实施例的服务模型构建器用户界面的屏幕截图，该服务模型构建器用户界面具有包括本地目标元素表示的服务组件的目标元素参数视图。

图7A是示出根据本公开一些实施例的服务模型构建器用户界面的屏幕截图，该服务模型构建器用户界面包括供应方模式对象显示窗口和使用代表性状态转移(REST)架构指向目标元素的服务组件显示窗口。

图7B是示出根据本公开一些实施例的服务模型构建器用户界面的屏幕截图，该服务模型构建器用户界面包括供应方模式对象显示窗口和使用传输控制协议(TCP)架构指向目标元素的服务组件显示窗口

图8A是根据本公开一些实施例的用于执行服务模型的服务模型事务器用户界面的屏幕截图。

图8B是示出根据本公开一些实施例的包括翻滚和空运行的服务模型事务器用户界面覆盖区管理的屏幕截图。

图9A-图9B是根据本公开一些实施例的在网络元素之间执行服务的服务模块推出中的步骤的流程图。

图10A-图10B是根据本公开一些实施例的执行默认回滚程序的服务模块回滚中的步骤的流程图。

图11是示出根据本公开一些实施例的服务模型构建器用户界面的屏幕截图，该服务模型构建器用户界面具有基于上下文为属性分配多个条件值的目标元素参数视图。

图12是示出根据本公开一些实施例的服务模型构建器用户界面的屏幕截图，该服务模型构建器用户界面具有定义了定制推出和回滚操作的目标元素参数视图。

具体实施方式

在一些实施例中，公开了一种用于自动分布式系统服务回滚的技术。本文公开的技术允许可重用的服务模型、属性和目标元素，它们可以针对各种分布式网络应用和设备进行定制。可以实现本文所描述的技术，以使用应用编程接口(API)针对企业服务管理(ESM)的数据完整性提供服务回滚。常见的ESM应用包括电信网络、基础设施网络(例如，电力网络、水管理、公用事业等)和过程自动化等。为了清楚解释的目的，本公开将电信网络提及为ESM分布式网络的代表。

由于在电信分布式网络内实现的设备的复杂性，电信公司提供了充分的示例性实施例。例如，网络功能虚拟化(NFV)不仅仅是关于打开新的虚拟网络功能(VNF)/虚拟机(VM)。许多VNF是长寿命和多租户的。许多VNF具有复杂、冗长的数据链。

作为另一个示例，服务功能链(SFC)可以增加回滚挑战。SFC中的VNF往往是长寿命和多租户的，表示冗长的数据链。SFC并没有完全解决策略的协调问题(例如，VNF可能不知道哪些策略与服务功能路径(SFP)ID相关联)。

真正的端到端运营方服务可能需要广泛的协调数据收集以用于例如跨控制平面(例如，MME、RADIUS、PCRF、OCS、OFCS、PE路由器)和各种内部应用的回滚。

服务建模可能花费太长时间(例如，定义服务以及如何在网络中实现它所花费的时间)并且不够自动化(例如，面向元模型的编程(MOP)表达为具有对应清单的Word文档)。

数据驱动的自动化方法已经以脚本的形式被使用了相当长的一段时间。在某种程度上，使用脚本来驱动自动化是数据驱动的，因为脚本本身表示数据。此外，脚本是“射后不管(fire and forget)”，导致运行脚本所达到的效果没有状态表示。

虽然脚本方法已经在传统信息技术(IT)设置中被使用，但是一段时间以来，它没有在很大程度上跨越到电信应用的供应。与典型的电信应用不同，典型的IT应用通常在部署时进行配置，几乎不需要或根本不需要对其进行增量重新配置。相比之下，电信应用需要服务配置验证，以确保网络中的预期工件仍按预期提供。

已经尝试简化将电信应用配置集成到自动化框架中，但是每个都需要自动化平台的开发者编写代码，最终，完成新设备、服务或程序的集成。相比之下，本文所描述的方法完全是数据驱动和无代理的，其中解决方案的最终用户提供建模所需自动化程序所需的所有数据。

电信应用通常也是无代理的。基于代理的方法允许客户端(例如，应用)从服务器(例如，在服务器上运行的代理或询问服务器应该安装哪些软件包的虚拟机(VM))提取所需的配置。相比之下，如果没有代理，中央“管理器”必须将所有需要的操作推送到各个客户端。由于供应方和应用类型(例如，路由器、DNS服务器、PCRF、PGW等)的多样性，电信应用往往是无代理的。这与具有基于代理的目标(例如，执行基于事务的数据备份或多版本货币控制程序)的同构环境形成对比。

如本文所述，模型驱动的回滚方法是指这样一种系统，该系统向网络提供所有所需信息的系统以便在服务实现异常的情况下自动管理回滚。如在一些实施例中所描述的，该系统不需要针对每个网络设备的单独回滚。相反，系统可以以动态方式实现所述设备的回滚。如本文所述，此无代理方法可以被用于诸如电信之类的应用中，其中部署无处不在的(例如，部署在任何地方)代理来回滚所有相关的网络数据和应用是不切实际的。

本文所描述的实施例使用自动化模型驱动框架在分布式端到端网络内使用回滚程序。本文所描述的方法完全是数据驱动的和无代理的，其中解决方案的最终用户向模型提供所有必要的数据，以在服务失败的情况下执行回滚所需的自动化程序。

为了减轻最终用户对本文所述问题的负担，可以使用服务模型语言来描述任何和所有的自动化程序。在一些实施例中，本文所述的系统和方法使用可扩展标记语言(XML)来创建一种语言，该语言允许将在诸如安全外壳/命令行接口(SSH/CLI)等受支持传输上发生的通用动作序列表达成一些目标实体集。在一些实施例中，此语言的表达能力还足以捕获if/else逻辑，以便处理目标设备集内任何范围的可执行版本。

这种方法可以是面向对象的，允许抽象服务实例的生命周期管理，这可以包括在已选择目标上支持的本地对象实例的集合。这种服务实例可以被创建、删除、修改、检查与底层目标的同步、强制与底层目标同步、检查状态、以及收集以进行统计。

本文所描述的方法可以支持任何到期望的目标设备的所需传输协议，包括网络配置协议(NETCONF)、简单网络管理协议(SNMP)、命令接口(CLI)/安全外壳(SSH)、SSH文件传输协议(SFTP)、表现层状态转移(REST)和简单对象访问协议(SOAP)/XML。

在一些实施例中，使用服务模型构建器(在本文中也被称为vBuilder)对服务进行建模。如下文更详细描述的，服务模型构建器允许主题专家(SME)去构建模型，以供网络运营方执行，从而创建并管理服务。在一些实施例中，本文所描述的系统提供了基于GUI的终端用户设备，无需编码且无需内置产品特定适配器。在一些实施例中，使用了由SME定义的可重用模型。如下文更详细描述的，可重用模型定义的一个示例是用于多个目标设备的服务属性。在一些实施例中，本文所描述的系统允许灵活的自变量处理和传播，并且可以被修改以通过任何传输连接器(例如，NETCONF、REST、SOAP、SNMP、Java结构化查询语言(JSQL)、CLI/SSH)来支持任何目标设备或应用。在一些实施例中，本文所描述的系统支持多版本目标以在单个事件中跨网络元素来执行服务(在本文中被称为“服务模型推出”或“推出”)。

在一些实施例中，本文所描述的系统提供服务模型回滚程序(回滚)作为服务模型推出的逆程序。在逆向推出程序中，服务模型事务器以相反的顺序执行服务模型推出的步骤。另外，服务模型事务器还执行与在推出中执行的每个服务模型步骤相反的操作，以撤销推出中的操作并将网络元素返回到其服务前状态。在其他实施例中，服务模型事务器以相反的顺序执行服务模型推出的步骤，以使得服务模型事务器执行由服务模型中的SME定义的附加步骤补充的每个服务模型步骤的相反操作。这种步骤可能包括在删除用户账户之前禁用用户、更新用户的计费信息、QoS策略、评级组或创建应用到MVNO的新服务规则。

在一些实施例中，本文所描述的系统提供具有服务模型事务器(在本文中也被称为vTransactor)的回滚。服务模型事务器可以从服务模型构建器中导入完成的服务模型。在一些实施例中，服务经由GUI或以编程方式使用NorthBound应用编程接口(NB-API)触发。NB-API可以是REST/JSON、REST/XML或基于TCP的客户管理接口(CAI)协议。这些服务可以包括创建/修改/删除、状态、统计和用户定义的操作。在一些实施例中，本文所描述的系统可以跟踪实例化的服务实例，诸如配置同步/检查、跨目标聚合的状态、以及关于跨目标推出的统计。

图1是示出了根据本公开一些实施例的基于模型的服务平台部署的系统图。图1示出运营网络102、公司IT网络104、运营方接口106、主题专家(SME)接口108、服务模型构建器(在本文中也被称为vBuilder)110、服务模型事务器(在本文中也被称为vTransactor)112、运营支撑系统/业务支撑系统(OSS/BSS)应用114、网络元素管理系统(EMS)116、网络元素(NE)118、NE 120、虚拟I/O模块(VIM)122、NFV编排器/虚拟网络功能管理器(NFVO/VNFM)124、以及应用126。

服务模型构建器110可以被部署为公司网络104中的工具。在一些实施例中，目标用户是SME 108。SME 108可以通过诸如REST之类的网络服务架构与服务模型构建器110通信。服务模型构建器110指定如何构建适合于跨网络中的设备来实现的服务重复调用的模型。如下文更详细描述的，在一些实施例中，服务模型构建器110允许SME 108通过使运营方106能够创建、取回、更新和删除服务实例来指定运营方可以怎样操纵客户数据。服务模型构建器110还允许SME 108指定服务模型事务器112如何响应服务模型执行失败或异常。SME108可以使用本地供应方模式对象作为目标对象或目标元素来构建服务模型115(未示出)，本文进一步描述(例如，QoS策略、计费计划、HSS、封装后脚本子系统(EPSSUB)、IP多媒体子系统(IMSSUB)，或国际号码名称权威指针(iNUM Naptr)，或网络管理系统(NMS)CreateSpecProc等)。在本文所描述的系统中，至少部分地不需要编码和产品特定适配器，因为服务模型115可以由SME 108构建，SME 108经由与服务模型构建器的GUI进行直接交互而导入配置对象模型模式(例如，路由器供应方X的又一下一代(YANG)模块)以及用户数据输入，以便为不提供机器可读模式的应用定义一种“伪模式”。这方面的示例是仅仅使用命令行界面(CLI)管理的应用或网络功能。应用提供方可能经常发布以PDF文件的CLI用户指南(例如，有可能发布机器可读格式，诸如Backus-Noir-Form(BNF)，但仅提供语法而不提供语义)。在CLI文档示例中，应用实际上没有“官方”模式。

驻留在运营网络102中的服务模型事务器112允许运营方106基于从服务模型构建器110接收的服务模型115来提供服务。运营方106可以通过诸如REST之类的网络服务架构与服务模型事务器112通信。服务模型事务器112利用模型，以便执行以推出形式的服务实例(例如，创建、取回、更新、删除)。服务模型事务器112可以包括随机存取存储器。例如，服务实例可能包括删除用户账户、更新用户的计费策略、QoS规则、账户标识信息、数据计划容量、或其他账户信息。

服务模型事务器112还可以与所有其他组件(例如，OSS/BSS应用114、元素管理系统(EMS)116、网络元素(NE)120、虚拟I/O模块(VIM)122、NFV编排器(NFVO)/虚拟网络功能管理器(VNFM)124和应用126)通过所支持的连接器集或协议集进行交谈。可以从与服务实例化有关的协议或设备的先验知识中的至少一个，并且从服务模型115检测到的协议和设备类型中的至少一个来创建模型。通过向服务模型115提供具体目标实例特定信息，运营方106可以通过服务模型事务器112来实例化服务(即，推出)。服务模型事务器112可以向OSS/BSS应用114、元素管理系统(EMS)116、网络元素(NE)120、虚拟EO模块(VIM)122、NFV编排器(NFVO)/虚拟网络功能管理器(VNFM)124以及应用126指定参数来实例化服务。服务模型事务器112还可以用更多指令向OSS/BSS应用114指定参数，以配置元素管理系统(EMS)116、网络元素(NE)120、虚拟基础设施管理器(VIM)122、NFV编排器(NFVO)/虚拟网络功能管理器(VNFM)124和应用126来实例化服务。服务模型事务器112可以通过系统支持的协议/连接器(例如，REST、SOAP和NETCONF中的至少一种)与其他运营网络元素通信。

OSS/BSS应用114可以被用来管理和支持端到端电信服务。OSS包括诸如服务供应之类的管理功能。BSS包括为电信服务提供方管理业务运营的组件。EMS 116管理电信网络中的网络元素120。NFVO/VNFM 124管理和编排NFV资源。VNFM管理VNF生命周期。应用126指的是电信应用。

如本文所述，服务模型构建器110是数据驱动的。为了将客户信息过程的操纵自动化，SME 108可以使用一个或多个供应方模式对象和一个或多个注释目标元素的组合来限制用于每个组件的配置参数，该配置参数需要由运营方106指定。如在下文中更详细描述的，SME 108可以在单个属性中包括注释目标元素的组合，并且指定目标元素之间的关系。服务模型事务器112支持配置产品的协议，从而有助于配置产品本身。服务模型115可以指定每个协议所需的至少一些参数。在一些实施例中，SME 108可以通过硬编码某些属性来简化模型，这些属性从目标的角度来看是灵活的和/或指定了比目标自己的约束更严格的约束。在一些实施例中，最终满足所有约束的实际值在操作(例如，创建、更新等)执行期间由服务模型事务器112来处理。

使用服务模型执行的服务的一个示例是当无线运营方直接更新客户信息时(例如，

对

进行客户引导(onboarding))或当无线运营方更新附属客户(例如，

对诸如Cricket Wireless之类的移动虚拟网络运营方(MVNO)进行客户引导(onboarding))。另一个示例是当无线运营方分别从其网络删除客户或向其网络添加客户时。在一些实施例中，更新客户的信息需要配置多个接触点，如下面结合图2所更详细地描述的。

图2是示出根据本公开一些实施例的MVNO中的自动化服务的系统图。图2示出了服务模型事务器112、网络功能虚拟化基础设施(NFVI)202、OSS 114、NFVO/VNFM 124、Gi LAN服务208、分组数据网络网关(PGW)210、移动性管理实体(MME)212、域名服务器(DNS)214、离线计费系统(OFCS)216、在线计费系统(OCS)218、归属订户服务器/归属位置寄存器(HSS/HLR)220、策略和计费规则功能(PCRF)222、认证、授权和计费(AAA)服务器224、提供方边缘(PE)路由器226、北向应用编程接口(API)投标器228、服务模型事务器112、授权管理器232、表现层状态转移(REST)协议234、结构化查询语言(SQL)协议236、简单对象访问协议(SOAP)238、安全文件传输协议/安全外壳协议(SFTP/SSH)240、简单网络管理协议(SNMP)242、网络和配置协议(NETCONF)244。

NFVI 202是可供VNF使用的计算、存储和网络资源的集合。在一些实施例中，本文所描述的系统可以被用来管理虚拟网络功能、物理网络功能或虚拟和物理网络功能的组合。如图2中所示，推出一项服务需要操纵多样化的网络元素。操纵每个网络元素可以作为由服务模型115内的SME 108设置的系统序列中针对每个目标的一系列步骤而发生，下面进一步详细描述。例如，改变用于PE路由器226的数据的步骤可以包括配置边界网关协议(BGP)虚拟路由功能(VRF)和多协议标签交换(MPLS)BGP/MPLS VRF中的至少一个，或其中每一个的多个实例；改变AAA服务器224、PCRF 222和HSS/HLR 220的数据可以包括配置接入点名称(APN)策略映射和国际移动用户身份(IMSI)策略映射中的至少一种；改变OCS 218和OFCS 216的数据可以包括配置APN到MVNO的映射；改变DNS 214的数据可以包括配置APN和PGW C-名称记录；改变MME 212的数据可以包括配置APN运营方策略和PGW选择策略；而改变Gi LAN服务208的数据可以包括配置PGW、APN、用户设备(UE)池、BGP/MPLS VRF、工作流控制和数据简档。Gi是GGSN/PGW到互联网的接口。在一些实施例中，在GGSN/PGW和互联网之间插入了各种增值服务。那些实体被称为GiLAN或Gi LAN。例如，GiLAN服务208可以包括对用于超文本传输协议(HTTP)代理、传输控制协议(TCP)代理、HTTP内容过滤、网络地址转换(NAT)或防火墙的策略和行为进行配置。如本文所述，通过北向API投标器228，运营方106可以通过服务模型事务器112执行多个服务模型115以操纵网络元素内的数据，以便通过所支持的协议(例如，REST 234、SQL 236、SOAP 238、SFTP/SSH 240、SNMP 242、NETCONF 244)来创建、取回、更新或删除服务实例。服务模型事务器112还可以包括能够与网络元素通信以确定网络元素是否可操作的路由引擎。服务模型事务器112还可以包括用于与网络元素通信的目标类型协议特定连接器。目标类型协议特定连接器能够根据本文所描述的众多个体网络元素协议的要求将目标特定请求消息推送到网络元素。

相比之下，现有技术需要1)作为服务实例化的一部分，手动应用到每个网络元素；或2)不灵活的系统，仅支持IT部门或脚本方法以高成本设计的少数服务子集，脚本方法保留了不充足的状态以持续验证以前的配置。如本文更详细地描述的，操纵客户数据的过程使用本文所描述的系统和方法通过SME输入的信息而被自动化：1)包括服务模型的第一层，2)包括属性的第二层，3)第三层，包括a)目标设备本地可见的供应方模式对象(VSO)，和b)由SME注释的VSO(在本文中也被称为“注释目标元素”或“目标对象”)。动词(例如，CRUD)是所有层的行为方面。

在一些实施例中，在第三层处，存在两阶段建模方法——首先，导入或定义资源的目标的本地表示(例如，对象)，第二，装饰或注释该本地表示以便指定更严格的约束，经由对某些属性进行硬编码来执行数据隐藏，或经由合并(例如，组合)多个属性来进行简化。与每个CRUD动词相关的模型方面可以被称为模型的方面——VSO/注释目标元素——都具有创建方面、更新方面等，以表示该模型动词特定方面。在一些实施例中，非动词特定资源或对象模型的一个方面是关键属性，关键属性唯一地标识资源实例。那些属性被完全指定以便执行动词。

如本公开一些实施例中所描述的，供应方模式对象是由本地应用提供给对象的精确度和灵活性的表示——例如，在CLI界面中可能存在静态路由对象，该静态路由对象例如具有唯一地标识其实例的特定方式，具有某些强制性属性、某些可选属性，并且该属性具有类型和可能的约束。一旦建立了供应方模式对象(例如，由SME导入)，就允许以附加约束、数据隐藏和诸如合并属性之类的其他操作的形式进一步细化，以使得始终为多个属性提供等同值。例如，可以基于静态路由供应方模式对象来创建注释目标元素，方法是将其限制为仅使用IPv4地址。在基于相同供应方模式对象的不同注释目标元素中，约束可能是仅允许IPv6地址。

在本文所描述的系统的一些实施例中，授权管理器232启用一些次要功能性。可以指定被创建的服务实例，以使得只有运营方的子集可以对其进一步操作(更新、删除等)。例如，基于由SME 108设计的MVNO模型或配方，事务器可以创建一个Cricket MVNO和一个Jasper MVNO。可以有一个运营方团队可以只修改Cricket MVNO，并且可以有一个不同的团队可以只修改Jasper MVNO。

图3是根据本公开一些实施例的服务模型构建器110和服务模型事务器112的系统图。图3示出了服务数据库310、服务模型数据库312、端到端(E2E)测试服务模型316、服务模型318、仿真测试目标320、Web服务定义语言(WSDL)322、XML模式定义(XSD)324、又一下一代配置对象建模语言(YANG)326、管理信息库(MIBS)328、物理/虚拟网络功能(P/VNF)330 332340 342、NFVO/NF/应用334、P/VNF/应用336和远程数据库344。

服务数据库310包括由服务模型事务器112实例化的服务记录。如下文更详细描述的，服务记录可以包括服务实例、目标类型和目标实例。服务模型数据库312包括由SME 108通过服务模型构建器110创建的服务模型115、属性、供应方模式对象和注释目标元素的记录。服务模型数据库312可以由系统运营方、具体目标类型的制造商，或与系统相关联的独立第三方数据库运营方所拥有。

仿真测试目标320允许SME 108在仿真环境中执行服务模型115以用于测试、调试和修改。仿真测试目标320指的是可以由如PCRF之类的目标的SME 108在请求/响应对方面定义的仿真。这允许甚至在部署在服务模型事务器112上之前就对旨在用于PCRF的属性进行第一级测试。仿真测试目标320将以目标设备本地形式来提供将发往目标设备的准确请求消息。SME 108或运营方106可以在实况系统中实现推出之前验证该请求消息。

服务模型构建器110可以以两种方式利用服务模型：E2E测试服务模型316(在本文中也被称为“试运行”)和服务模型执行318。E2E测试服务模型316可以验证经由服务模型115创建的服务实例的行为。E2E测试服务模型316不仅测试配置是否正确和当前的，还可以测试真实的端到端行为，这些行为可能受到操作条件影响，诸如各种不同的路由器到路由器的链路上的物理链路状态等。例如，代替通常的服务实例的CRUD生命周期管理，本文所描述的系统和方法可以被用来对活动测试的调用进行建模，以及收集并解释可能被用于服务验证的活动测试的结果。为了测试服务模型，SME或运营方会传输标志“dryRun＝true”，这将导致它输出会到达目标的实际消息。除了推送到真正的目标设备之外，它将执行所有执行步骤。它可以被触发以进行测试，并且被查询本次测试的结果。在此示例中没有创建实际的服务实例，取而代之的是一个无状态的动作。如本文更详细地描述的，服务模型318可以由SME 108设计以供运营方106用于对服务进行实例化。

服务模型115可以被设计成，与经由SOAP/XML管理的应用进行通信，并且发布对应的Web服务定义语言(WSDL)322、又一下一代(YANG)326、JavaScript对象符号(JSON)和/或管理信息库(MIBS)328。WSDL 322是一种XML格式，其将服务定义为能够交换消息的网络端点的集合。YANG 326是一种用于NETCONF的语言，它是模块化的，并且以XML树格式来表示数据结构。MIBS 328允许网络管理系统监视数据库对象。

如本文所述，服务模型事务器112可以接收可以利用任何数量的协议(例如，表现层状态转移(REST)协议234、结构化查询语言(SQL)协议236、简单对象访问协议(SOAP))238、安全文件传输协议/安全外壳协议(SFTP/SSH)240、简单网络管理协议(SNMP)242、网络和配置协议(NETCONF)244)的服务模型115。每个协议都可以与P/VNF 330 332 340 342、NFVO/NF/应用334、P/VNF/应用336和远程数据库344的配置相关联并且被用来指定该配置。例如，NETCONF可以与有YANG能力的路由器(例如，Juniper路由器、Cisco路由器)一起使用。如本文中更详细描述的，YANG文件由应用提供方发布(例如，“企业”YANG模型)和/或在征求意见稿(RFC)中进行标准化(例如，由互联网工程任务组(IETF)进行标准化)，并且可以将其拖入服务模型构建器110工作区以指定工作流(例如，QoS流)。其他协议包括REST、SOAP和命令行界面(CLI)。NETCONF协议一般搭配YANG模式，SNMP协议一般搭配MIB模式，SOAP/XML协议一般搭配WSDL模式，REST和CLI协议一般没有正式的模式。

图4A-图4C是根据本公开一些实施例的服务实例管理的对象关系图。图4A-图4C示出了与服务模型构建器110相关联的服务模型1402、属性404和目标元素406；以及与服务模型事务器112相关联的服务实例410、目标类型412和目标实例(或目标设备)414。

如图4A-图4C中所示，线上方的元素从服务模型构建器110的角度示出了本文所描述的系统和方法的一些实施例(例如，服务模型115)；线下方的元素从服务模型事务器112的角度示出了本文所描述的系统和方法的一些实施例(例如，执行模型以创建服务实例的结果)。特别地，已经在那些目标实例(即，VRF、MP-BGP对等会话等)上创建了工件，这些工件已经按照涉及哪些目标实例(例如，哪些PE路由器实例和什么本地对象或资源，包括它们的所有关联值)而被配置到网络中。从服务模型构建器110的角度来看，服务模型1402、属性404和目标元素406被创建并链接以部署在服务模型事务器112上。首次服务命令与服务模型1402相关联地被发出(例如，以创建客户)时，服务实例410被创建。多个服务实例410表示基于由服务模型1402表示的服务模型115创建的每个服务实例。相同的服务模型115可以被用来为不同的客户提供不同的服务实例。可以通过执行服务模型115(例如，删除命令)来创建服务实例。在一些实施例中，服务模型事务器112具有我的结构化查询语言(MySQL)数据库以跟踪服务实例和目标实例(或目标设备)414(在本文中也被称为服务实例的覆盖区，结合图8B进一步描述)的层级。

服务模型1402可以包括多个属性404。在一些实施例中，每个属性404与一个或多个目标类型412相关联。在一些实施例中，目标类型412包括设备类型(例如，路由器)。属性404可以包括受相同目标类型和相同目标类型协议特定连接器类型约束的目标元素406(在本文中也被称为“目标对象”)中的至少一个。目标元素406包括必须被配置以便创建服务实例化的对象(例如，VNF、PNF、应用)。例如，目标元素406包括CRUD语义(例如，创建、取回、更新和删除)。

如本文所述并参考图1，服务模型115可以由SME 108创建以最小化由运营方106执行的手动配置量以实例化服务。在一些实施例中，服务模型115可以由SME 108硬编码，从而消除了对运营方106进行大量配置的需要。在一些实施例中，服务模型115可以具有开放字段以从运营方106获取输入。例如，服务模型115可以留下为每个VRF指定的开放字段，唯一的路由鉴别器整数值。服务模型115可以将这个值公开为运营方106提供的必需自变量。在一些实施例中，服务模型115可以包含开放字段，该开放字段包括逻辑输入(例如，if/else)，以使得基于设备操纵来填充该字段。

服务实例410的一种实现包括一个或多个目标类型412，一个或多个目标类型412是由与定义服务实例410的服务模型1402相关联的属性404所指定的，从属性404定义了服务实例410。在一些实施例中，目标类型412包括一个或多个目标实例414。目标实例(或目标设备)414是实际存在且目标实例414可以与之交谈的VNF、PNF或应用的实例(例如，Juniper路由器、Cisco路由器)。如本文所述，每个目标实例414与服务实例410的数据库以及相关联的覆盖区和工件相关联。在一些实施例中，在运行时，服务模型事务器112可以要求运营方106指定若干实例。在一些实施例中，可以以服务模型事务器112可以使用的格式(例如，电子表格)来指定用于多个服务实例410中的每个服务实例的所有参数。

图5A是示出根据本公开一些实施例的具有包括服务模型段和属性段的服务组件关联的服务模型构建器用户界面的屏幕截图。图5A示出了用于服务模型501的服务模型构建器用户界面500、服务模型视图选择502、服务模型段504、服务组件506a-506f和服务组件列表段508。服务模型构建器用户界面500可以是运营方标记系统，例如，Affirmed ServiceAutomation Platform(“ASAP”)。

服务模型段504包括用于接收或设置服务模型名称的字段。服务模型段504还包括用于在服务内添加服务组件及其关联的工作空间。如本文所述，每个属性404可以包括供应方模式对象和注释目标元素中的至少一个。例如，如图5A中所示，服务模型段504可以包含用于供应订户和订户服务的服务模型名称的6个服务组件506a-506f。在一些实施例中，服务组件506a-506f表示一种或多种记录类型。在图5A中，订户服务组件506a表示各种底层目标类型中的订户记录集。例如，图5A还示出了服务组件506a-506f(表示记录的类型)之间的关联，并且订户记录与策略和计费规则功能(PCRF)规则集相关联。服务组件506a-506f形式的订户记录也可以与多个包相关联，例如基本包、高级包、预付费包等。可能需要使用网络管理服务(NMS)服务组件506d、506e和506f在网络上为预期服务供应每个包。

若干服务组件506a-506f之间的关系可以包括诸如1:1(一对一关联)、1:N(一对多关联)或M:N(多对多关联)。服务组件506a-506f可以独立地或结合服务模型501的所有其他服务组件来执行或推出。这意味着，对于现有订户，可以添加新包，可以删除现有的包，或者可以更新现有的包以作为服务执行的一部分(即推出)。在一些实施例中，服务组件506a-506f可以保持与其他对等服务组件506a-506f的层级关系(即父子关系)。在这种实施例中，子服务组件可以从其父组件继承属性。例如，在图5A中，作为PCRFRuleSet服务组件的代表性服务组件506b可以从服务组件506a(订户服务组件)继承订户身份属性，诸如国际移动订户身份(IMSI)和移动站国际订户导向号码(MSISDN)。这样，在服务模型501执行时，运营方可以一次性提供属性IMSI和MSISDN的值。

图5B是示出根据本公开一些实施例的服务模型构建器用户界面的屏幕截图，其具有包括服务组件部件段、服务组件属性段和服务组件属性编辑段的服务组件的参数视图。服务模型构建器用户界面500包括服务组件部分段510和服务组件属性段512。服务组件属性段512列出了执行服务组件506a-506f所需的属性。服务组件属性段512可以包括作为底层注释目标元素(TE)和供应方模式对象(VSO)的一部分的属性。可以使用服务组件属性段512来组合或合并来自属性列表的相似属性。例如，如图5B中所示，使用国际移动订户身份(IMSI)的多个底层记录可以被组合为一个IMSI，以使得运营方可以给出一个IMSI值以提供不同目标类型的订户。合并(组合)段516，如图5B中所示，允许SME 108组合属性。例如，合并段516可以将底层目标元素(TE)中的IMSI用作实验室环境的演进分组核心订户(LAB-EPSSUB)、实验室环境的多媒体订户(LAB-IMSSUB)、实验室环境的隐式注册集(LAB-IRS)等来组合所有属性。SME 108还可以将硬编码值设置为IMSI或为运营方选择包括切换以提供IMSI的值。

包括在服务组件部分段510中的是目标元素518的列表。目标元素518的列表可以是目标元素(TE)集或指向预期网络元素(NE)的命令。目标元素列表518可以与诸如MCC、HSS、PCRF、TAS、NMS之类的服务组件TargetType(目标类型)以及诸如NETCONF、SOAP、REST、CLI之类的网络协议相关联。目标元素518的列表中所有的TE可以在一个推出会话上下文内被推送到指定的服务组件，如关于图9A-图9B进一步描述的。

图5C是示出根据本公开一些实施例的具有服务组件的序列视图的服务模型构建器用户界面的屏幕截图，服务组件的序列视图包括被分成与服务模型501对应的目标元素组的服务模型序列视图。服务模型序列视图520提供了被分成目标元素组(TEG)的个体目标元素的序列的图示。代表性TEG 526a-626c对应于与图5中的订户服务组件506a相关联的目标元素，而TEG 526d对应于与PCRFRuleSet服务组件506b相关联的目标元素。序列窗口522a-522e示出了用于TEG 526a-526d的服务模型501的执行序列。在一些实施例中，序列窗口522a-522e示出了序列，从序列窗口522a-522e中每一个的左侧开始，并且从服务模型序列视图520顶部的序列窗口522a开始向右跟踪每个目标元素。例如，如图5C中所示，序列窗口522a显示包含分别对应于HSS订户和字段组的TE的代表性目标元素组(TEG)526a。同样，与用于PCRFRuleSet的服务组件522b相关联的TEG 526b包括用于对应于一般订户和GenericSpm的TE的执行指令序列。SME 108可以在对应于TEG的服务模型501内定义可执行指令，而不是定义关于每个个体TE的属性。

如图6中所示，服务模型构建器用户界面500还包括目标元素段602，目标元素段602可以被用来单独操纵服务模型501的代表性TE。图6还示出了代表性TE的属性段606。目标元素段602可以包括显示原生目标元素表示(例如，从供应方模式对象中提取)的TE名称604。从一个VSO中，可以提取一个或多个TE，每个都有不同的注释。例如，在图6中，TE名称604包括用于实验室环境的HSS的IP多媒体私有身份(IMPI)记录。对于每个预期的环境或市场段，SME可以额外添加一个TE、对其适当命名、注释用于环境的属性，并且构建模型。属性段606显示HSSI MPI的供应方模式对象(VSO)的多个属性608a-608f。SME 108可以选择注释各个属性608a-608f中的每个属性。属性608a-608f中的每个属性都可以被忽略，以使得它不会被传播到服务组件506a-506f中的每个服务组件。属性608a-608f中的每个属性还可以被注释为“包括”以将其包括在服务组件属性段512中，如图5B中所示。

还可以使用公式612来注释属性608a-608f中的每个属性。如图6中所示，公式窗口610示出了使用公式612的注释属性608f的细节。对于TE 604，可以使用具有每个对应公式612的公式窗口610来注释属性608a-608f中的每个属性。例如，可以使用自定义属性来捕获本地移动号码并使用它来构建具有给定市场移动网络代码(MNC)和移动国家代码(MCC)的IMSI。用公式612注释每个属性608a-608f为SME 108提供了更大的灵活性。使用公式窗口610，每个属性608a-608f可以被设置为常数值，使用字符串连接来设置值，或使用带有if-then逻辑的正则表达式对值进行逻辑评估等。例如，如图6的公式窗口610中所图示，IMPI密钥是使用给定的IMSI来设置的，该IMSI用于具有移动网络代码(MNC)和移动国家代码(MCC)的具体市场段。

属性608a-608f中的每个属性也可以在运行时使用具有响应属性或具有系统日期和时间的LateBinding(后期绑定)机制进行动态设置，该机制将关于所选服务组件的数据捕获为被执行属性608a-608f的一部分。在一些实施例中，LateBinding机制允许SME 108设计服务模型501，以基于当时的可用数据在服务模型执行时(即，动态地)定义属性608a-608f的值。LateBinding动态值可以包括执行时的日期和时间值或执行时的可用属性值，诸如来自NE的先前的响应属性值。也可以使用正则表达式和if-then-else逻辑来设置LateBinding机制。例如，如果由运营方106提供的PortId已经被使用，则LateBinding可以将端口绑定到由GETCONFIG(获取配置)目标元素返回的端口号加1。在调用目标类型协议特定连接器之前，可以由vTransactor 112执行LateBinding机制以基于vTransactor 112已知的先前捕获的数据来计算该值。SME 108还可以设计服务模型501以从目标设备收集值，并且通过在目标类型协议特定连接器处使用LateBinding机制使用该值来计算新的值。

如本文所述，TE表示潜在的VSO。对于基于NETCONF的TargetType，VSO是通过加载已发布的YANG模式生成的。对于基于REST的TargetType，可以通过加载已发布的JSon或XML负载来构建VSO。对于基于SOAP的目标类型，名称空间和属性的容器层级608可以使用服务模型构建器用户界面500来添加。对于基于CLI的目标类型，可以使用服务模型构建器用户界面500来添加命令或命令集。VSO表示会发往目标设备的请求消息。目标设备是TargetType的实例。系统会基于目标类型特定VSO以服务组件506a-506f的序列来构建到目标设备的请求消息，目标元素针对服务模型501内的具体步骤而指向这些服务组件。

图7A示出了在服务模型501内使用REST协议的VSO的示例性显示。针对用于ZhoneHSI SC服务组件706的CreateSpecProfile 704的基于REST的TargetType，示出了VSO显示窗口702。VSO显示窗口702提供了针对每个方面的模式708，包括创建、删除、更新、获取或任何自定义方面。每个方面对应一个操作，如创建、删除、更新、获取。例如，图7A的模式708对应于用于Zhone HSI SC服务组件706的CreateSpecProfile的创建方面模式。

图7B示出了在服务模型501内使用TCP/CLI语法的VSO的示例性显示。针对用于包括目标目录窗口722的虚拟HSS(vHSS)716的IMPI记录714，示出了基于TCP的目标类型的VSO显示窗口712。VSO显示窗口712提供了诸如KEY、DEFAULT RECORD NAME、IMSI、GUSSLIFETIME、GUSS STATE、GUSS UICC之类的描述属性(或参数)的模式718。例如，图7B的模式718用名称、显示名称、参数类型、基本数据类型、请求数据类型等来描述每个属性。图7B中表示的整个运营方模式对象是用于一个IMPI记录。VSO显示窗口712还包括参数类型输入720，其指示该属性是可选的、必需的还是与IMPI 714相关联的关键属性。从目标目录窗口722，SME 108能够生成对应于VSO显示窗口702和712的一个或多个TE。

一旦使用服务模型构建器用户界面500构建了服务模型501，SME 108就可以从vBuilder 110导出完成的服务模型501并将其传输给运营方106以在E2E网络中执行。运营方106将服务模型501导入vTransactor 112，然后以两种方式之一来执行或运行服务模型501。第一种方式是使用事务器GUI来执行服务模型501。第二种方式是通过OSS/BSS系统使用事务器NortboundAPI(NB-API)。在这两种情况下，运营方106提供使用服务模型构建器用户界面500定义的所需属性，以用于推出服务实例410。在一些实施例中，事务器北向NB-API提供API getServiceData()以给出服务模型501所需的属性。当运营方106通过提供属性来执行服务模型501时，服务模型501将分两步执行。在第一步中，除LateBinding属性之外的所有属性都用公式和合并注释进行解析，并且服务实例410被创建，如结合图4A-图4C所描述的。在第二步中，所创建的服务实例410被应用到目标设备(在本文中也被称为“翻滚”(rollover)，并结合图8B进一步描述)。在NB-API的情况下，两个步骤都用来自OSS/BSS的单个API调用来执行。事务器GUI将结合图8A和图8B做进一步解释，其中图8A表示第一步骤，而图8B表示第二步骤。

图8A是通过为每个服务组件提供属性来示出具有事务器GUI的服务模型执行的屏幕截图。系统将构建对应于输入的服务实例，如本文所述。图8A示出了服务模型事务器页面800、服务模型标题802、服务实例804、当前服务组件实例806和属性页面808。服务模型事务器页面800可以是运营方标记系统套件的一部分，其包括服务模型构建器用户界面500，诸如ASAP系统。例如，在图8A中，用于订户供应的属性页808，IMSI和MSISDN是所需的属性。通过点击服务组件订户(服务模型501的服务组件506a)，此订户服务组件的必要属性被显示在属性页面808中。本文显示的属性处于服务组件级，如图5B中所示。运营方106可以为服务服务组件506a-506f之一或所有服务组件或服务模型501的所需服务组件的组合构建服务实例。此过程的结果或输出是服务实例的创建，如上所述。

图8B是示出根据本公开一些实施例的包括翻滚和空运行的服务模型事务器用户界面覆盖区管理的屏幕截图。图8B示出了服务实例820的翻滚，如上所述使用服务模型事务器页面800促进，由标题订户服务提供者Prov Instl表示。服务实例820可以被翻滚到多个TargetType和TargetType内的多个目标设备(或目标实例)。运营方106可以选择给出具体目标列表或将其留给自动路由算法来确定目标列表。在图8B中，选择4个不同的目标设备以用于服务实例翻滚，包括HSS目标822、PCRF目标824、iNUM目标826和ZhoneNMS目标828。在一些实施例中，TargetType-wise VSO按顺序被传输到对应的目标类型协议特定连接器，以构建最终的请求消息并将其传输到目标设备。在构建该请求消息之前解析所有的LateBinding属性。

如果设备不可操作，则运营方106可以停止向目标设备传输翻滚数据(已解析的服务实例数据)。如图5C中所示，服务模型501可以包含TAS目标类型，TAS目标类型可以不被作为图8B中所示的服务实例1 830的翻滚的一部分而被包括。vTransactor 112覆盖区目标设备可由运营方106定义，以使得覆盖区不被应用到TAS目标类型。vTtransactor 112不是为每个事务提供目标设备的列表，而是为运营方106提供设施以基于输入数据范围自动路由覆盖区，如在本文中进一步描述的。例如，如果MSISDN在某个数字范围内，则它将自动路由到市场中的VNF集，而对于不同的MSISDN范围，它会路由到不同市场中的不同的VNF集。因此，运营方106可以能够将服务实例推送到目标设备的完整集或目标设备的子集。

服务模型501由服务模型事务器112按照由SME 108设置的排序步骤来执行，在本文中参考图5C进行描述。服务模型501可以包括由SME 108在服务模型构建器110中确定的不同序列。推出的每个步骤对应于基于VSO的注释TE。诸如创建、删除之类的推出操作确定了方面。如上面所解释的，一个方面包括由SME 108输入到服务模型501中的每个目标元素的所有必需的动词句法。SME 108可以使用本文所描述的服务模型构建器110将属性608分配给VSO的对应方面。例如，使用CRUD语义，第一属性可以只包括创建和更新命令，第二属性可以只包括创建、删除和获取命令，而第三属性可以只包括创建和更新命令，以使得就没有必要每个属性都包括在给定属性中存在的所有四个CRUD语义操作。在一些实施例中，可能需要基于来自先前的响应和公式的其他属性来解析LateBinding属性。在解析了所有的VSO属性之后，构建目标特定请求消息956并将其传输到指定传输上的设备。

图9A-图9B是图示了服务模型推出的实施例的流程图，服务模型推出包括针对个体目标设备的系统步骤序列。SME 108可以通过以用于每个服务组件的预定顺序放置由图标表示的目标元素来控制推出，目标元素从左到右排序以指示正确的顺序，如图5C中所示。服务模型事务器112执行从服务模型构建器110接收的服务模型501。每个步骤包括由服务所需的网络元素方面中的至少一个组成的服务组件属性。服务模型推出系统地将每个步骤应用到由SME 108在服务模型501中定义的VSO，直到完成服务模型501的所有步骤。

例如，推出针对的是在分布式网络中供应订户。推出由vTransactor 112执行并被应用到针对TE在服务模型501中定义的VSO。如本文所述，服务模型执行被定义为两个步骤。第一步是在将给定的属性解析成VSO之后创建服务实例。第二步是推出，其通过将服务实例作为输入而将配置推送到覆盖区。在步骤920处，vTransactor 112读取用于推出的服务实例对象和目标列表。运营方106提供服务组件属性和可选的目标列表作为事务的一部分，以使得剩余过程根据服务模型501自动化。服务实例基于服务模型501的属性来计算，并且这是翻滚的起始点。在步骤922处，vTransactor 112检查运营方106是否提供了目标列表。然后，如果在步骤922处目标列表为空，则vTransactor 112在步骤924确定是否启用自动路由，以便确定是否可以继续推出。在一些实施例中，使用基于预定路由规则的自动路由算法来计算目标列表。vTransactor 112捕获用于安装的路由规则并应用这些路由规则来计算自动化目标列表。自动路由规则可以包括为诸如MSISDN或IMS之类的服务组件属性提供服务相关规则。可以使用数字范围或具体值来执行自动路由。如果自动路由未被启用，则在步骤926处，vTransactor 112以错误消息的形式或以其他通知形式来引发异常，并且在步骤928处停止所表示的推出。如本文关于服务模型501所描述的，如果在步骤924处启用了自动路由，则vTransactor 112在步骤930处计算用于推出的目标类型和目标列表。用于服务模型501推出的这种目标列表由预先定义的规则计算。例如，如果具有MSISDN范围1的服务模型501的规则是TargetList1，而MSISDN范围2的规则是TargetList2，则自动路由算法确定给定输入属性的范围，然后计算对应的TargetList。如果TargetList为空，则没有可推出的覆盖区并且服务模型将停止。

在确定非空目标列表vTransactor 112之后，vTransactor 112可以使用服务模型构建器用户界面500按照由SME 108所设置的顺序放置需要推出的服务组件。vTransactor112选择序列中的第一可用服务组件以用于推出。如果在步骤932服务组件不可用于推出，则vTransactor 112将其解释为意指推出已完成。在步骤934处，响应于推出完成，vTransactor 112在图3的服务数据库310中存储逐目标推出，该推出是VSO的逐目标列表。服务数据库中的VSO的逐目标列表可以被称为“黄金副本”。此黄金副本反映了针对服务数据的目标设备上的实际数据。在推出失败的情况下，黄金副本可以向运营方106提供E2E网络的恢复性数据点。为了在目标设备上构建现有服务的黄金副本，可以使用“同步自”功能。一旦在服务数据库310处更新了目标设备配置，则在步骤936处停止推出。

如果在步骤932处vTransactor 112中包括的路由引擎确定具体服务组件可用于推出，则vTransactor 112在步骤938中根据由SME 108设置的服务模型推出序列来选择用于推出的服务组件。具有这种能力的vTransactor 112内的路由引擎可以使识别变得可能，如本文所述。在根据序列选择服务组件之后，vTransactor 112可以在步骤940处检查与该服务组件对应的TEG是否可用于执行推出。如果TEG不可用于推出，则vTransactor 112返回到步骤932以推出序列中的下一个可用服务组件。在于步骤942处选择具体的TEG之后，vTransactor 112在步骤944处从用于TEG的TargetType序列中选择可用的TargetType。如果TargetType不可用，则vTransactor 112返回到步骤940以在服务组件中找到下一个可用的TEG以用于推出。

在步骤946处，如果所选TEG内的TargetType可用于推出，则vTransactor 112选择该TargetType用于推出。在步骤948处，vTransactor 112解析LateBinding属性并为TargetType构建VSO列表。在整个服务模型执行过程中，vTransactor 112维持上下文高速缓存。上下文高速缓存可以包含先前的响应对象，以使得它们可用。如本文中所使用的，高速缓存可以是任何存储器存储设备并且不限于在存储器层级中描述的具体高速缓存类型。与LateBinding属性相关联的公式用来自TargetType的可用数据进行评估。可能存在取决于TEG对象内的响应的LateBinding属性，并且这些属性在目标类型协议特定连接器级处被进一步评估。所收集的LateBinding属性然后可以由vTransactor 112保留，如本文中进一步描述的。此后，在步骤950处，vTransactor 112调用其中包含的目标类型协议特定连接器以提供推出。用于推出的VSO按服务模型中给出的顺序排列。如果在步骤952处VSO不可用于推出，则vTransactor 112返回到步骤944以检查可用于推出的下一个TargetType。如果VSO在步骤952处可用，则在步骤954处，vTransactor 112在具有VSO的目标类型协议特定连接器处选择用于推出的VSO并解析LateBinding属性，如果有的话。

在步骤956处，vTransactor 112构建目标元素特定请求消息。此消息将被推送到目标设备。步骤958检查用于推出的目标设备。如果是测试运行(dryRun＝true)，则构建的请求消息将被保存在dryRun段的上下文高速缓存中。如果不是测试运行，它将选择可用的目标设备以推出。如果目标设备不可用或者它是试运行，则vTransactor 112返回到步骤952，以使得vTransactor 112检查SME 108定义的序列中的下一个可用VSO。如步骤960所表示的，如果目标设备在步骤958处可用，则vTransactor 112将建立目标连接会话并将在步骤956处构建的请求消息传输到目标设备。在接收到请求消息之后，目标设备用响应消息来响应vTransactor 112，该响应消息在步骤962处由vTransactor 112读取。基于目标设备响应，vTransactor 112在步骤964处确定推出是否被成功执行。如果在步骤964处目标设备响应指示推出成功，则vTransactor 112返回到步骤958以查询由SME 108定义的序列中的下一个目标设备以作为服务模型的一部分。如果在步骤964处推出不成功，则vTransactor112进行到步骤966，由此vTransactor 112停止推出操作。作为停止推出操作的一部分，vTransactor 112可以向运营方106提供指示推出失败的通知。在一些实施例中，在停止推出操作之前，vTransactor 112可以触发由服务模型定义的附加服务组件，如关于图10A-图10B所描述的。

在vTransactor 112没有完成推出的情况下(例如，检测到服务模型推出失败/异常)，服务模型触发服务模型回滚(在本文中也被称为“回滚”(rollback))，其颠倒服务模型推出的顺序并将每个服务模型步骤恢复到其服务前的模型执行状态。在一些实施例中，本文所描述的系统执行回滚以作为服务模型推出的反向(在本文中也被称为“默认回滚”)。在其他实施例中，vTransactor 112以相反的顺序执行服务模型推出的步骤，以使得vTransactor 112执行由服务模型定义的附加步骤补充的每个服务模型步骤的相反操作(在本文中也被称为“自定义回滚”)。使用服务模型构建器110，SME 108可以定义由服务模型异常触发的每个步骤(目标元素)内的推出和回滚操作。在一些实施例中，SME 108可以在回滚步骤内定义多个属性，这些属性不是对应服务模型推出步骤的一部分(例如，推出的DELETE(删除)操作可以是单步操作，但是可以在回滚中包括获取/创建/更新步骤以将目标元素恢复到服务前状态)。SME 108将按照正确的顺序在服务模型501中构建推出步骤和回滚步骤。在一些实施例中，服务模型501中的一些步骤专门应用于推出，而一些步骤专门应用于回滚。在一些实施例中，通过将处于目标元素级处的操作设置为针对推出或回滚的“无操作”来控制排他性。

图10A-图10B是图示了本公开一个实施例中的图9A-图9B中的服务模型推出的服务模型回滚的实施例的流程图。在反向推出程序中，服务模型事务器112以相反的顺序执行服务模型推出的步骤。服务模型事务器112通过解释由服务模型构建器110提供的服务模型来保持服务模型推出的顺序。另外，服务模型事务器112执行作为推出的一部分执行的每个服务模型步骤的相反操作，以便撤销推出中的操作并将网络元素返回到其服务前状态。

例如，回滚针对分布式网络中的订户供应的失败的服务实例。推出的过程在图10A-图10B中被重复，对应于图9A-图9B中所示的步骤920到步骤964。在步骤964处，vTransactor 112检查推出是否成功。如果在步骤964处推出成功，则vTransactor 112通过检验由SME 108构建的服务模型来查询是否启用回滚。如运营方106所设置的。如果在步骤1002处未启用回滚，则vTransactor 112将进行到步骤958以用于服务实例中的下一个目标设备。如果在步骤1002处启用了回滚，则vTransactor 112将在步骤1004处将来自步骤962的目标设备响应存储在上下文高速缓存中。然后，在步骤1006处，vTransactor 112将评估由SME 108在服务模型内定义的回滚操作。为了评估回滚操作，vTransactor 112将考虑对目标元素的操作进行推出和回滚，诸如用于推出的创建操作和用于回滚的删除操作等。在步骤1006处，它将评估回滚操作是默认回滚操作还是自定义回滚操作。如果在推出和回滚操作中未定义对应于当前VSO的目标元素(TE)，则vTransactor 112将这些步骤视为默认回滚操作。如果在TE处定义了推出和回滚操作，则其被视为自定义回滚操作。在步骤1008处，基于在步骤1006中定义的回滚操作，vTransactor 112将构建具有默认回滚或自定义回滚的回滚目标元素，稍后将分别结合图11和图12进行描述。在步骤1010处，vTransactor 112然后将回滚目标元素对象推入回滚栈。回滚栈可以被存储在与vTransactor 112相关联的高速缓存、存储器或其他数据存储库中。回滚目标元素是基于底层VSO，该底层VSO具有对应于用于具体目标设备的回滚操作的方面。当回滚被调用时，它能够构建向目标设备的请求消息以进行回滚。在一些实施例中，步骤1010允许在单个推出事务中将若干回滚目标元素命令推入回滚栈。在来自vTransactor 112的单个回滚栈内推送多个目标元素命令提高了网络效率。在步骤1010之后，推出过程通过返回到步骤958继续。

如果在步骤964处推出不成功，则vTransactor 112查询是否在正在执行的服务模型内启用了回滚。如果在步骤1012处没有启用回滚，则vTransactor 112停止在步骤966处结束的推出操作。作为停止推出操作的一部分，vTransactor 112可以向运营方106提供指示推出失败的通知。如果相反，在步骤1012启用了回滚，则vTransactor 112在步骤1014查询回滚栈是否为空。如果回滚栈为空，则vTransactor 112停止操作，由步骤1016表示。如果步骤1014发现回滚栈被填充，则vTransactor 112执行步骤1016，由此回滚栈由vTransactor 112使用在步骤1006处评估并在步骤1008处构建的回滚操作进行填充，并且vTransactor 112构建回滚服务组件。可以基于回滚栈来构建回滚服务组件。回滚服务组件将支持TargetType特定连接会话，类似于用消息组进行推出。在步骤1016处构建回滚服务组件之后，vTransactor 112在推出中进行到步骤940以在启用回滚的情况下执行服务实例。

在一些实施例中，对回滚操作的评估可以确定回滚操作是默认服务回滚操作(在本文中也被称为“默认回滚”)。默认服务模型回滚仅限于创建、更新和删除推出操作。如果服务模型正在处理任何自定义操作，如CONFIGSYNC、IMSISWAP，默认回滚可能需要SME 108执行的又一操作功能性。又一功能性可以被体现在自定义服务模型回滚(在本文中也被称为“自定义回滚”)中以用于任何执行失败。自定义服务模型回滚允许SME 108将另外的方面输入到回滚栈中，以使得回滚不仅仅是推出的逆过程。在一些实施例中，默认回滚在每个对应步骤内执行相反的方面(例如，推出创建对应于回滚删除，推出更新对应于回滚更新，推出删除对应于回滚创建，而推出得到操作对应于回滚无操作)。

当回滚被启用时，为了用默认服务模型回滚机制进行工作，默认回滚VSO方面可以由SME 108定义为服务模型的一部分，以作为回滚的一部分而可用。如果没有默认的回滚VSO方面，则认为没有与序列中的具体步骤对应的回滚操作。图11是示出了根据本公开一些实施例的服务模型构建器用户界面的屏幕截图，其具有用于基于上下文为属性分配多个条件值的目标元素参数视图。图11示出了与上面在图6中描绘的类似的目标元素窗口1100，设计用于定制默认回滚属性。目标元素窗口1100提供对应的属性段1102。例如，目标元素窗口1100对应于区域HSI SC服务组件中的目标元素创建SpecProf。属性段1102允许针对所有方面选择区域HSI SC的供应方模式对象(VSO)的单个TE。在这种情况下，即使多个方面可能处于VSO，单个TE也可以为默认回滚提供多个操作。SME 108可以选择使用公式1104来注释每个单独的属性。用户界面1106示出了用公式1104进行修饰的细节，以例如包括LateBinding值。LateBinding值允许所选属性包含分别对应于推出步骤和回滚步骤的多个值。对于默认回滚操作，可能有单个注释TE服务推出和回滚机制。在一些实施例中，可能存在某些参数，这些参数在推出期间需要一个值而在回滚期间需要不同的值。例如，如图11中所示，属性RequestType(请求类型)应注释有值“Create”以用于推出，值“Delete”用于回滚。在LateBinding窗口1106中，可以基于使用LateBinding的操作在运行时动态设置属性，如结合图11所讨论的。在公式窗口1104中，“LateBinding”胶囊可以被用作“RequestType”属性的值。当“LateBinding”胶囊被点击时，它将打开LateBinding窗口1106，该窗口将有两个选项卡。选择“MultiValue”(多值)选项卡允许为推出(Execute，执行)和回滚定义值。在执行期间，将取决于操作来设置所使用的值，并且将使用该值来构建VSO以传输到目标设备。

例如，对于区域HSI SC服务组件中的目标元素CreateSpecProf，对应的VSOCreateSpecProf应该具有创建方面和删除方面。同一个TE将支持用于推出的创建操作和用于回滚的删除操作。然而，某些属性可以有一个用于推出的值和一个用于回滚的不同值。例如，在CreateSpecProf VSO中，RequestType属性在创建操作期间具有值“add”，而在DELETE操作期间，同一属性具有值“delete”。在一些实施例中，与回滚相比，目标元素属性取决于推出而支持多值逻辑。在服务模型构建器110中，SME 108可以为属性设置多值逻辑，如本文所述。

在另一个示例中，运营方可能正在尝试升级用户包，包括Ribbon UCaaS设备上的不同服务(例如，互联网、电话和电视服务)的组合。用于推出和回滚功能性的其他网络元素可以包括Zhone、视频监控即服务(“VSaaS”)、分组数据网络网关(“PGW”)、服务网关(“SGW”)、策略和计费规则功能(“PCRF”)、归属用户服务器(“HSS”)、iNum、以及电信应用服务器(“TAS”)。为了这样做，运营方或SME可以在由系统实施例部署的服务模型中捕获回滚操作栈(例如，用于更新的订单)，以指示针对REST资源的每个CRUD语义的具体操作。在该服务模型操作中，SME可以为捕获CRUD推出操作和对应的回滚操作的订单创建目标元素，如上所述。在此非限制性示例中，服务模型可以包括三个不同的步骤来更新订户的信息，包括在订单下创建新包、用新包识别信息来更新订户、以及移除与订户相关联的旧包。作为推出的一部分，在基于指定的CRUD语义操作创建新命令后，系统可以将更新的订户信息推送到Ribbon UCaaS元素，包括下列步骤：创建诸如订单库存单元(“sku”)或数量之类的新的订户信息字段，更新诸如产品详细信息之类的任何现有的订户信息字段，删除现有的产品信息，以及得到从数据库取回附加信息的功能。另外，系统还可以将回滚栈作为订单的一部分推送，包括与推出的那些命令相反的命令(例如，在向Ribbon UCaaS传输“在订单下创建新包”命令之前，回滚栈将包括“删除订单下新创建的包”的回滚命令；对于“用新包id来更新订户”推出命令，系统可以将回滚命令“用旧包id来更新订户”推入栈)。对于一些作为推出栈一部分包括的命令，回滚栈可能没有对应的回滚命令(例如，对于“移除与订户相关联的旧包”是最后一个命令推出，因此回滚命令不是必需的，并且系统不会在退出前就更新回滚栈)。在推出的最后一步，系统可以尝试移除与订户相关联的旧包。然而，如果该移除由于缺乏连接或排序不当而失败，则服务模型订单的填充回滚栈将触发回滚并弹出回滚栈命令以在网络上完成该过程，诸如此示例中的Ribbon UCaaS。通过这样做，系统可以确保，即使新包的部署可能已经失败，UCaaS订户的旧包和服务也是活动的。

在一些实施例中，可以在目标元素级包括自定义回滚机制。图12是示出根据本公开一些实施例的服务模型构建器用户界面的屏幕截图，其具有定义了自定义推出和回滚操作的目标元素参数视图。如图12中所示，通过将TE操作定义为“Update”用于推出和“Delete”用于回滚来启用自定义回滚。使用这种机制，任何自定义方面都可以在VSO级定义，并且它可以被用于在对应的TE处推出或回滚。图12示出了提供了对应的属性段1202的目标元素窗口1200。例如，目标元素窗口1200对应于区域NMS服务组件中的目标元素ModifySpecificProf。属性段1202显示了区域NMS的供应方模式对象(VSO)的每个单个TE。为了构建自定义回滚能力，SME 108可以选择使用操作公式窗口1204来注释操作。操作公式窗口1204示出了用具体的回滚方面1206来装饰TE的细节，回滚方面1206与与TE相关联的对应的回滚方面1208不同。例如，在图12中，推出方面1206包括更新方面，而回滚方面1208是删除方面。使用操作定义窗口1204，SME 108可以定义自定义回滚操作，该操作不仅仅是针对具体VSO的彼此的逆操作(例如，更新不是删除的逆操作或相反操作)。这样做时，SME 108可以定义自定义回滚以包括不是默认回滚也不是推出的一部分的附加步骤。然而，应当理解，逆操作可以被包括作为回滚操作的一部分。操作公式窗口1204允许SME 108使用与TE相关联的VSO为推出中的每个属性定义推出和回滚方面1206和1208。用于自定义回滚的操作序列对应于使用服务模型构建器用户界面500定义的目标元素序列的相反顺序及其属性。

当在VSO级定义多个方面时，一个对应的TE可以被用于所有操作。在这种情况下，默认回滚可以由vTransactor 112评估，以确定要作为默认回滚的一部分执行的操作序列。在其他实施例中，如果操作需要自定义注释或需要自定义回滚，则可以在服务模型构建器用户界面500处创建多个TE以支持服务模型内的多个操作或多个VSO方面。对于自定义回滚，TE操作需要如图12中所述进行定义。对于默认回滚，对于所有操作(即，创建、更新、删除、获取)可能有一个TE，但是对于自定义回滚的每个操作都有一个单独的TE(例如，用于创建的创建TE，用于删除的删除TE等)。

在一些实施例中，回滚可以包括每个步骤中的前置条件和后置条件。在一些实施例中，前置条件可以包括：在执行针对服务组件的目标元素的服务模型步骤之前，禁用对服务组件的服务实例操作。在其他实施例中，前置条件包括：在实现服务模型步骤之前，将服务前数据保留在上下文高速缓存中的获取操作。在一些实施例中，后置条件可以包括：在针对服务组件的目标元素执行服务模型步骤之后，启用对服务组件的服务实例操作。在其他实施例中，所执行的服务模型步骤可以包括修改条件，修改条件包括前置条件、服务模型属性、以及后置条件。所有这些附加的步骤都可以被建模为服务模型中的目标元素，这些目标元素只能在回滚操作中执行并且它们将被注释为“NO OPERATION”以用于在推出期间没有影响的回滚。

在一些实施例中，回滚可以包括一个步骤，表现为推出内的空步骤，其说明对象之间的关系的规范(例如，服务组件之间的父/子或层次关系)。如本文中关于图5A所描述的，SME 108可以基于在服务模型构建器110中创建服务模型501时服务组件如何相关来定义服务组件之间的关系。使用服务模型构建器110，SME 108可以包括具有服务模型的空推出步骤，以使得在回滚期间，服务模型事务处理器112在父对象回滚之前对子对象执行回滚操作。

在服务模型事务器112没有完成服务模型回滚的情况下，成功的推出步骤和回滚步骤被捕获在记录器(在本文中也被称为“日志文件”)中。包含在vTransactor 112内的记录器可以捕获服务组件目标元素的恢复。在一些实施例中，运营方106可以手动执行记录在记录器中的请求消息以执行否则由于服务异常而失败的回滚。记录器确保在运营方106选择使用手动回滚执行的情况下记录回滚命令。在一些实施例中，运营方106可以使用黄金副本来执行配置同步，以便将该黄金副本推送到目标设备。

在其他实施例中，服务模型构建器110能够执行对服务组件中现有数据的基于模型的、数据驱动的供应。以这种方式，服务模型构建器110允许运营方106捕获E2E系统数据的完整图像，针对系统中服务的数据完整性来创建每个网络元素数据的主版本(即“黄金副本”)。黄金副本网络服务模型在网络集成之初跨所有设备执行数据收集，并且以适当的服务编排器服务数据格式来存储该E2E网络配置。由于许多VNF是长期存在的和多租户的，因此保留网络数据结构的主版本可以在发生故障时提供足够的数据完整性并且可以提高向网络添加设备的效率。可以根据与服务实例化有关的协议或设备的先验知识中的至少一个，以及根据由服务模型检测到的协议和设备类型来创建模型。

在一些实施例中，服务模型构建器100使SME 108能够创建黄金副本服务模型，黄金副本服务模型使用为服务模型推出和回滚设计的相同的属性和方面来执行。这样，黄金副本服务模型作为一种同步服务模型执行，以使用网络元素模式或本地协议来解析目标对象的目标元素，并且将接收到的数据存储为服务编排器服务数据格式。例如，在对运营方所拥有的新MVNO进行客户引导(onboarding)时，可以在MVNO内部署黄金副本服务模型并获取一个文件，该文件可以为服务编排器适当地分析和链接来自每个目标对象的数据。

网络设备数据的保留的黄金副本可以由服务编排器保留以建立基线网络结构，或者在灾难性网络故障的情况下将网络恢复到其原始状态。替代地，网络设备数据的黄金副本提供基线以用于与当前数据状态进行比较。这样做允许运营方106或服务编排器将适当的数据推送到目标对象，以实现高效的端到端网络操作。

虽然本公开的某些实施例已经描述了关于电信应用的数据自动化技术，但是本文所描述的系统和方法也适用于使用无代理目标的其他应用。如本文所述，无代理目标通常是需要不断配置的目标。与可以从服务器拉取更新信息的基于代理的目标不同，与无代理目标相关联的更新需要更频繁和/或更多应用特定更新，而从服务拉取这些更新是不切实际的。无代理应用的示例是工厂自动化。工厂中的机器人部件可能需要增量配置(例如，装配线上的机器人部件)。

在一些实施例中，公开了一种用于执行无代理、数据驱动和有状态自动化以向移动网络客户供应服务的系统和方法。在一些实施例中，该系统和方法包括在计算设备处接收与对象相关联的第一对象参数，第一对象参数包括设备类型和协议中的至少一个。在一些实施例中，该系统和方法包括：在计算设备处基于第一对象参数：从与计算设备相关联的数据库取回第二对象参数，此时与协议相关联的配置参数包括可导入表格，该可导入表格与可从服务器导入数据库的数据相关联；并且从与用户输入数据相关联的数据库取回第二对象参数，此时与协议相关联的配置参数包括不可导入表格，该不可导入表格与不可从服务器导入数据库的数据相关联。例如，可导入表格中的数据可以包括基于协议语义或元数据字段与目标设备通信所需的通用配置参数或代码。不可导入的数据可以包括客户特定信息，诸如账单信息、账号、QoS条款，这些信息可由运营方为各个客户输入。在一些实施例中，第二对象参数包括与第二对象参数相关联的数据配置参数。在一些实施例中，本文所描述的系统和方法包括在计算设备处接收与创建至少一个子配方相关联的组织参数，所述至少一个子配方中的每个子配方包括以下至少一个：目标对象、一个或多个其他目标对象，以及目标对象之间的关联。在一些实施例中，本文所描述的系统和方法包括在计算设备处处理配方，该配方包括至少一个子配方以传输到执行引擎以形成服务实例，该服务实例包括基于该配方预填充的配置参数，服务实例可由运营方106为具体的网络设备定制，从而执行无代理、数据驱动和有状态的自动化以向移动网络客户提供服务。

本文所描述的主题可以在数字电子电路系统中实现，或者在计算机软件、固件或硬件中实现，包括在本说明书中公开的结构部件及其结构等效物，或者它们的组合中实现。本文所描述的主题可以被实现为一个或多个计算机程序产品，诸如有形地体现在信息载体中(例如，体现在机器可读存储设备中)或体现在传播信号中的一个或多个计算机程序，以用于由数据处理装置执行或控制数据处理装置的操作(数据处理装置例如是可编程处理器、计算机、或多台计算机)。计算机程序(也称为程序、软件、软件应用或代码)可以用任何形式的编程语言编写，包括编译或解释语言，并且可以以任何形式部署，包括被部署为独立程序或部署为适合在计算环境中使用的模块、组件、子例程或其他单元。计算机程序不一定对应于文件。程序可以被存储在保存有其他程序或数据的文件的一部分中，存储在专用于相关程序的单个文件中，或存储在多个协调文件中(例如，存储一个或多个模块、子程序或代码部分的文件)。计算机程序可以被部署在一台计算机上或部署在一个站点的多台计算机上执行，或者跨多个站点分布并通过通信网络互连。

本说明书中描述的过程和逻辑流程，包括本文所描述的主题的方法步骤，可以由一个或多个可编程处理器执行一个或多个计算机程序来执行，以通过操作输入数据并生成输出来执行本文所描述的主题的功能。过程和逻辑流程也可以由本文所描述的主题的装置来执行，并且可以被实现为专用逻辑电路系统，例如，FPGA(现场可编程门阵列)或ASIC(专用集成电路)。

例如，适合执行计算机程序的处理器包括通用和专用微处理器，以及任何种类的数字计算机的任何一个或多个处理器。通常，处理器将从只读存储器或随机存取存储器或两者接收指令和数据。计算机的基本元素是用于执行指令的处理器和用于存储指令和数据的一个或多个存储器设备。通常，计算机还将包括，或可操作地耦合，以从用于存储数据的一个或多个大容量存储设备(例如，磁盘、磁光盘或光盘)接收数据或将数据传送到这些设备或执行这两种操作。适合体现计算机程序指令和数据的信息载体包括所有形式的非易失性存储器，例如包括半导体存储器设备(例如，EPROM、EEPROM和闪存设备)；磁盘(例如，内部硬盘或可移动磁盘)；磁光盘；和光盘(例如，CD和DVD磁盘)。处理器和存储器可由专用逻辑电路补充，或被合并到专用逻辑电路中。

为了提供与用户的交互，本文所描述的主题可以在计算机上实现，该计算机具有显示设备(例如，CRT(阴极射线管)或LCD(液晶显示器)监视器)以用于向用户显示信息，以及键盘和定点设备(例如，鼠标或轨迹球)，用户可以通过它们向计算机提供输入。也可以使用其他类型的设备来提供与用户的交互。例如，提供给用户的反馈可以是任何形式的感官反馈(例如，视觉反馈、听觉反馈或触觉反馈)，并且可以以任何形式接收来自用户的输入，包括声学、语音或触觉输入。

本文所描述的主题可以在包括后端组件(例如，数据服务器)、中间件组件(例如，应用服务器)或前端组件(例如，具有图形用户界面或网络浏览器的客户端计算机，用户可通过图像用户界面或网络浏览器与本文所述主题的实现进行交互)或这种后端、中间件和前端组件的任何组合的计算系统中实现。系统的组件可以通过任何形式的数字数据通信或其介质互连，例如，通信网络。通信网络的示例包括局域网(“LAN”)和广域网(“WAN”)，例如互联网。

应当理解，所公开的主题在其应用方面不限于在以下描述中阐述或在附图中图示的构造细节和组件的布置。所公开的主题能够实现其他实施例并且能够以各种方式来实践和执行。此外，应当理解，本文所采用的措辞和术语是为了描述的目的而不应被视为限制性的。

因此，本领域技术人员将理解，本公开所基于的概念可以容易地用作设计用于执行本公开主题的几个目的的其他结构、方法和系统的设计基础。因此，重要的是权利要求被视为包括这种等效构造，只要它们不脱离所公开主题的精神和范围。

尽管在前述示例性实施例中已经描述和图示了所公开的主题，但是应当理解，本公开仅通过示例的方式做出，并且所公开的主题的实施细节的许多改变可以在仅由下附权利要求限制的不脱离所公开主题的精神和范围的情况下进行。

Claims (31)

1.一种用于对基于模型的供应网络设备配置的回滚的计算设备，包括：

存储器，所述存储器能够存储包括数据模板序列的基于模型的供应数据模板；以及

处理器，与所述存储器通信，所述处理器被配置为读取存储在所述存储器中的所述基于模型的供应数据模板并且使所述处理器：

a)接收与向从目标设备类型的列表中选择的目标设备传输目标对象请求消息的请求相关联的数据，所述目标对象请求消息定义所述目标设备的能力，并且所述能力来自与所述目标设备相关联的数据存储库；

b)向所述目标设备传输取回消息；

c)响应于所述取回消息从所述目标设备接收目标对象响应消息，所述目标对象响应消息包括所述目标设备的预配置数据；

d)将所述目标对象响应消息的所述预配置数据存储在与所述基于模型的供应数据模板相关联的高速缓存中；

e)向所述目标设备传输所述目标对象请求消息，所述目标对象请求消息包括基于以下内容来指定创建、读取、更新和删除(CRUD)语义的配置参数：

与所述目标设备类型相关联的第一对象参数，

目标设备类型协议，

用户提供的数据；

f)从所述目标设备接收通知，所述通知指示所述目标对象请求消息的执行结果；以及

g)如果所述目标对象请求消息的所述执行结果是所述目标对象请求消息的不成功执行，则执行以下操作：

取回与所述目标对象请求消息相关联的回滚栈，所述回滚栈指定与所述配置参数相关联的CRUD语义，以及

从所述高速缓存取回所述目标对象响应消息的所述预配置数据，

请求所述目标设备基于所述预配置数据来执行所述回滚栈，以将所述目标设备恢复到预请求状态，以及

h)如果所述目标对象请求消息的所述执行结果是所述目标对象请求消息的成功执行，则从目标设备的所述列表取回第二目标对象请求消息。

2.根据权利要求1所述的计算设备，其中所述处理器请求所述目标设备执行所述回滚栈包括：以推出栈的相反顺序来执行所述回滚栈，以作为所述目标对象请求消息中的所述配置参数的逆操作。

3.根据权利要求1所述的计算设备，其中所述处理器请求所述目标设备执行所述回滚栈包括：根据由运营方定义的操作所指定的顺序将所述回滚栈作为运营方定义的函数来执行。

4.根据权利要求3所述的计算设备，其中所述运营方定义的操作包括在操作时自定义的多个公式参数类型。

5.根据权利要求1所述的计算设备，其中所述第二目标对象请求消息与第二目标设备相关联。

6.根据权利要求1所述的计算设备，其中向所述目标设备传输目标对象请求消息的所述请求包括由所述基于模型的供应模板的所述数据模板序列定义的、针对多个目标设备的请求消息的序列。

7.根据权利要求6所述的计算设备，其中所述处理器还被配置为针对所述多个目标设备中的每个目标设备重复步骤b)-h)中的每个步骤。

8.根据权利要求1所述的计算设备，其中所述处理器还被配置为：在将所述目标设备恢复到所述预请求状态之后，传输指示所述目标对象请求消息的不成功执行的通知。

9.根据权利要求1所述的计算设备，其中所述配置参数包括可导入表格，所述可导入表格与从服务器可导入到所述数据库中的数据相关联。

10.根据权利要求1所述的计算设备，其中所述基于模型的供应数据模板包括由运营方定义的目标设备类型的序列，所述序列包括以下至少一项：统一通信即服务(UCaaS)、Zhone、视频监控即服务(VSaaS)、分组数据网络网关(PGW)、服务网关(SGW)、策略和计费规则功能(PCRF)、归属用户服务器(HSS)、iNum、以及电信应用服务器(TAS)。

11.根据权利要求1所述的计算设备，其中所述逆操作具有多个参数类型，所述多个参数类型中的每个参数类型包括运营方定义的函数，所述运营方定义的函数除了所述目标对象请求消息中的那些参数字段之外还定义附加参数字段。

12.根据权利要求1所述的计算系统，其中传输所述目标对象请求消息包括目标设备特定操作，所述目标设备特定操作能够保留与所述目标设备相关联的所述预配置数据。

13.根据权利要求1所述的计算设备，其中接收与传输所述目标对象请求消息的所述请求相关联的数据还包括：确定所述目标设备类型的自动路由是否在所述基于模型的供应数据模板内被启用。

14.根据权利要求1所述的计算设备，其中所述目标设备类型协议包括以下至少一项：表现层状态转移(REST)协议、结构化查询语言(SQL)协议、简单对象访问协议(SOAP)、安全文件传输协议/安全外壳协议(SFTP/SSH)、简单网络管理协议(SNMP)、以及网络和配置协议(NETCONF)。

15.根据权利要求1所述的计算设备，其中目标设备的所述列表包括基于设备类型和设备类型协议中的至少一个的多个目标请求对象。

16.根据权利要求1所述的计算设备，其中所述第一对象参数还包括与所述目标设备类型相关联的列表中的多个供应方模式对象。

17.一种用于对基于模型的供应网络设备配置的回滚的方法，包括：

a)接收与向从目标设备类型的列表中选择的目标设备传输目标对象请求消息的请求相关联的数据，所述目标对象请求消息定义所述目标设备的能力，并且所述能力来自与所述目标设备相关联的数据存储库；

b)向所述目标设备传输取回消息；

c)响应于所述取回消息从所述目标设备接收目标对象响应消息，所述目标对象响应消息包括所述目标设备的预配置数据；

d)将所述目标对象响应消息的所述预配置数据存储在与所述基于模型的供应数据模板相关联的高速缓存中；

e)向所述目标设备传输所述目标对象请求消息，所述目标对象请求消息包括基于以下内容来指定创建、读取、更新和删除(CRUD)语义的配置参数：

与所述目标设备类型相关联的第一对象参数，

目标设备类型协议，

用户提供的数据；

f)从所述目标设备接收通知，所述通知指示所述目标对象请求消息的执行结果；以及

g)如果所述目标对象请求消息的所述执行结果是所述目标对象请求消息的不成功执行，则执行以下操作：

取回与所述目标对象请求消息相关联的回滚栈，所述回滚栈指定与所述配置参数相关联的CRUD语义，以及

从所述高速缓存取回所述目标对象响应消息的所述预配置数据，

请求所述目标设备基于所述预配置数据来执行所述回滚栈，以将所述目标设备恢复到预请求状态，以及

h)如果所述目标对象响应消息的所述执行结果是所述目标对象请求消息的成功执行，则从目标设备的所述列表取回第二目标对象请求消息。

18.根据权利要求17所述的方法，其中所述处理器请求所述目标设备执行所述回滚栈包括：以推出栈的相反顺序来执行所述回滚栈，以作为所述目标对象请求消息中的所述配置参数的逆操作。

19.根据权利要求17所述的方法，其中所述处理器请求所述目标设备执行所述回滚栈包括：根据由运营方定义的操作指定的顺序将所述回滚栈作为运营方定义的函数来执行。

20.根据权利要求19所述的方法，其中执行所述运营方定义的操作包括在操作时自定义的多个公式参数类型。

21.根据权利要求17所述的方法，其中所述第二目标对象请求消息与第二目标设备相关联。

22.根据权利要求17所述的方法，其中请求向所述目标设备传输目标对象请求消息包括由所述基于模型的供应模板的所述数据模板序列定义的、针对多个目标设备的请求消息的序列。

23.根据权利要求22所述的方法，还包括针对所述多个目标设备中的每个目标设备重复步骤b)-h)中的每个步骤。

24.根据权利要求17所述的方法，还包括：如果所述目标对象响应消息指示所述目标对象请求消息的不成功执行，则在将所述目标设备恢复到所述预请求状态之后，传输指示所述目标对象请求消息的不成功执行的通知。

25.根据权利要求17所述的方法，其中所述基于模型的供应数据模板包括由运营方定义的目标设备类型的序列，所述序列包括统一通信即服务(UCaaS)、Zhone、视频监控即服务(VSaaS)、分组数据网络网关(PGW)、服务网关(SGW)、策略和计费规则功能(PCRF)、归属用户服务器(HSS)、iNum、以及电信应用服务器(TAS)。

26.根据权利要求17所述的方法，所述多个参数类型中的每个参数类型包括运营方定义的函数，所述运营方定义的函数除了所述目标对象请求消息中的那些参数字段之外还定义附加参数字段。

27.根据权利要求17所述的方法，其中传输所述目标对象请求消息包括目标设备特定操作，所述目标设备特定操作能够保留与所述目标设备相关联的预配置数据。

28.根据权利要求17所述的方法，其中接收与请求相关联的数据还包括：确定所述目标设备类型的自动路由是否在所述基于模型的供应数据模板内被启用。

29.根据权利要求17所述的方法，其中所述目标设备类型协议包括以下至少一项：表现层状态转移(REST)协议、结构化查询语言(SQL)协议、简单对象访问协议(SOAP)、安全文件传输协议/安全外壳协议(SFTP/SSH)、简单网络管理协议(SNMP)、以及网络和配置协议(NETCONF)。

30.根据权利要求17所述的方法，其中目标设备的所述列表包括基于设备类型和设备类型协议中的至少一个的多个目标请求对象。

31.根据权利要求17所述的方法，其中所述第一对象参数还包括与所述目标设备类型相关联的列表中的多个供应方模式对象。

Images