通信系统的元数据增强型库存管理的方法和系统与流程

本申请要求于2014年8月20日提交的申请号为14/464,381，名称为“通信系统的元数据增强型库存管理的方法和系统”的美国非临时专利申请案的在先优先权，该在先申请的内容以引入的方式并入本文。

技术领域

本发明通常涉及数字通信，尤其涉及通信系统的元数据增强型库存管理的方法和系统。

背景技术：

通信系统通过使用户接入更广范围的业务，改变现代世界的生活。例如，第一个用户可以利用家里的笔记本电脑或者出差中会议室的笔记本电脑远程接入工作电脑；第二个用户可以在工作电脑的桌面上直观核实孩子在上学日是否安全到家；第三个用户可以在智能手机上观看最喜爱的电影；第四个用户可以在数字平板上启动做晚餐等。

为了支持如此广泛的用户、服务和接入技术，通信系统已变得越来越复杂。另外，随着硬件和软件组件的数量以及硬件和软件的类型的增加，通信系统也会增加。通信系统复杂性的增加以及硬件和软件组件的数量和类型的增加，使得通信系统的配置和管理越来越困难并且可能容易出错。

技术实现要素：

本发明的示例实施例提供了通信系统的元数据增强型库存管理的方法和系统。

根据本发明的一个示例实施例，提供一种管理实体操作的方法。所述方法包括：管理实体为通信系统中的实体解析采集数据的请求，所述解析用于产生解析后的请求和与所述请求相关的依赖信息；所述管理实体根据由所述解析后的请求派生出的上下文令牌和内容令牌生成模型元素集，其中所述内容令牌包括所述解析后的请求的外部元数据和内部元数据。所述方法也包括所述管理实体从所述模型元素集派生出的优化图形生成所述请求的与平台无关的结果描述，以及所述管理实体执行所述请求以采集所请求的数据。所述方法还包括所述管理实体存储所采集的所述数据。

根据本发明的另一个示例实施例，提供一种管理实体。所述管理实体包括处理器，以及在操作上与所述处理器耦合的存储器。所述处理器为通信系统中的实体解析采集数据的请求，所述解析产生解析后的请求和依赖信息；根据由所述解析后的请求派生出的上下文令牌和内容令牌生成模型元素集，其中所述内容令牌包括所述解析后的请求的外部元数据和内部元数据；从所述模型元素集派生出的优化图形生成所述请求的与平台无关的结果描述；执行所述请求以采集所请求的数据。所述存储器存储所采集的所述数据。

根据本发明的另一个示例实施例，提供一种管理环境。所述管理环境包括被管理的通信系统以及在操作上与所述通信系统耦合的管理实体。所述管理实体为通信系统中的实体解析采集数据的请求，所述解析产生解析后的请求和依赖信息；根据由所述解析后的请求派生出的上下文令牌和内容令牌生成模型元素集，其中所述内容令牌包括所述解析后的请求的外部元数据和内部元数据；从所述模型元素集派生出的优化图形生成所述请求的与平台无关的结果描述；执行所述请求以采集所请求的数据；存储所采集的所述数据。

实施例的一个优势是元数据的使用允许存在于查询过程中的组件之间的依赖的更好描述，以增强通信系统的管理中使用的数据的采集。

实施例的另一个优势在于改善的依赖为如何采集所述通信系统的管理中使用的数据提供了更好地见解。

实施例的另一个优势在于元数据可以用于促进对被管理的系统执行的各种操作，包括但不限于配置、监测以及其他生命周期操作。

实施例的另一个优势在于元数据的使用使得应用的基本功能定义为元数据，而不是在编程语言或者数据库中进行硬编码等。

实施例的另一个优势在于元数据的使用使得应用开发者致力于更高等级的抽象，因此开发者无需担心平台自动处理的低级系统细节。

附图说明

为了更完整地理解本发明及其优点，现在参考下文结合附图进行的描述，其中：

图1a示出了在此描述的示例实施例提供的示例管理环境，其中第一实体管理第二实体。

图1b示出了在此描述的示例实施例提供的包括管理系统和第二实体的管理环境的示例。

图2a示出了在此描述的示例实施例提供的信息模型和数据模型集之间的关系和映射的示例。

图2b示出了在此描述的示例实施例提供的数据语义(即理解)和数据连通性(即这些数据如何互相关联以及关联到被管理的系统的当前上下文或者未来的上下文)之间的示例关系。

图3示出了在此描述的示例实施例提供的包括通信系统以及基于信息模型的管理系统的示例系统。

图4示出了在此描述的示例实施例提供的为管理系统的一部分的突出功能提供细节的示例管理系统。

图5示出了在此描述的示例实施例提供的示例管理系统的组件的详细视图。

图6示出了在此描述的示例实施例提供的管理实体为通信系统中的一个或者多个实体控制数据采集时发生在管理实体中的高级操作的示例流程图。

图7示出了在此描述的示例实施例提供的管理实体为通信系统中的一个或者多个实体控制数据采集和处理时发生在管理实体中的操作的示例流程图。

图8示出了在此描述的示例实施例提供的定义数据和其处理之间依赖的示例元组。

图9示出了在此描述的示例实施例提供的示例类层次。

图10示出了在此描述的示例实施例提供的利用元数据建立上下文的示例图。

图11示出了在此描述的示例实施例提供的在管理实体生成模型元素和XSD文件时发生在管理实体中操作的示例流程图。

图12示出了在此描述的示例实施例提供的管理实体利用元数据增强对存在于请求中不同类型的依赖的理解时发生在管理实体中的操作的示例流程图。

图13示出了在此描述的示例实施例提供的管理实体对依赖和依赖类型的组合进行依赖分析时发生在所述管理实体中的操作的示例流程图。

图14示出了在此描述的示例实施例提供的示例设备。

具体实施方式

以下详细论述当前示例实施例的操作和其结构。但应了解，本发明提供的许多适用发明概念可实施在多种具体环境中。所论述的具体实施例仅仅说明本发明的具体结构以及用于操作本发明的具体方式，而不应限制本发明的范围。

本发明的一个实施例与元数据的使用相关，以更好地描述感兴趣的对象的辅助数据(如版本信息)以及存在于感兴趣的对象之间的依赖的描述。这为如何采集通信系统的管理中使用的数据提供了更好地见解，并且避免了软件上的硬编码决策。元数据的使用使得应用的基本功能定义为元数据，而不是在编程语言或者数据库中进行硬编码等。

本发明的第二实施例与可以如何使用元数据以方便对被管理的系统执行的各种操作有关，包括但不限于配置、监控以及其他生命周期操作。

就特定上下文中的示例性实施例即通信系统的基于模型的管理系统描述本发明，其中所述管理系统利用模型来驱动针对通信系统的数据采集以及利用元数据增强被采集数据的质量。所述被采集的数据可以分为操作数据、行政数据、管理数据以及性能数据。所述通信系统可以是标准的兼容性通信系统例如3GPP LTE、WiMAX、IEEE 802.11、IEEE 802.16等等，非标准的兼容性通信系统，或者一个或者多个技术性标准的兼容性通信系统与一个或者多个非标准的兼容性通信系统的组合。

通信系统通常都是动态的。不仅仅是其逻辑拓扑结构动态变化，而且当现有的物理设备移动或者删除时，会增加新的物理设备。通信系统的动态性质使得维持网络设备的实时列表以及可以用于识别所述网络设备的一个或者多个属性(例如互联网协议(Internet Protocol，IP)地址、端口信息等)具有挑战性。另外，可以下载新的应用、模块或者软件版本(包括操作系统和软件应用)，并且可以改变硬件(例如RAM、CPU、硬盘、固态存储器、网卡等)。

网络发现可以定于在预定时间和/或在预定的间隔发生，也可以基于需要进行。因为典型的通信系统很大，例如网络发现操作通常涉及大量处理。典型地，网络发现是基于采集器的，可以利用多种扫描方法(例如Ping扫射、端口扫描以及搜索不同类型的SNMP属性的简单网络管理协议(Simple Network Management Protocol，SNMP)扫描等)。

但是网络库存的应用会变化。高端应用利用网络发现并且生成通信系统的开放系统互连(open systems interconnection，OSI)1、2以及3级拓扑视图。更高端的应用包括网络设备、操作系统以及高级应用数据(如CPU、磁盘、存储器的正常运行时间、利用率等)。一旦生成所述通信系统的视图，则可以迅速检测到通信系统的变化。

被发现和/或库存的数据的类型与用于发现和/或上报所述数据的协议的类型之间可能存在依赖。用于采集数据的协议的类型与待采集数据的类型之间可能存在重要的依赖。例如，如果使用SNMP，则存在各种定义为主机与“转发数据报的设备”(例如作为路由器的设备)之间差异的管理信息库(management information base，MIB)对象。需要说明的是，这并不意味着该设备就是路由器，例如三层交换机也可以作为路由器。更重要的是(a)其他协议可能没有此项定义的能力；(b)其他协议可能定义比此项能力的功能或多或少的能力集；和/或(c)该差异可能不足以准确地区分特定的网络实体。

在另一个示例中，ManageableEntity的类型可能会有特定的属性和/或指示使用特定类型的协议的需求的行为。例如，定义为桥的端口发送桥接分组数据单元(bridge packet data unit，BPDU)，其中相同的端口可以发送不同的PDU用于不同层次的通信。这会变得复杂，因为层5至层7等高层本身不涉及PDU，但是涉及实际数据(或者数据的传输)。

在又一个示例中，在为特定类型的实体寻找特定类型的邻居时，采集数据的类型的选择会影响使用协议的类型。例如，如果对角色为“运营商边缘”的端口执行发现，在某些情况下，该端口可以连接至角色为“用户边缘”、“运营商边缘”或者“运营商核心”的其他端口。而在其他情况下，该端口可能会只限于寻找角色为“运营商边缘”的端口。此外，如果相同的端口使用多协议标记交换(Multiprotocol Label Switching，MPLS)，则该端口也可以寻找标签交换路由器、入口、出口以及其他类型的MPLS路由器。

在又一个示例中，在寻找设备或者端口具有的特定类型的功能时，因为待检索的数据可能非常具体，实体所具备的属性的类型也可以指示具体协议的使用。例如，设备可能对确定节点是否支持邻居发现，如主动预留协议(active reservation protocol，ARP)或者邻居发现协议(neighbor discovery protocol，NDP)、能力或者节点如何获得其地址(例如利用引导协议(Bootstrap Protocol，BOOTP)或者动态主机配置协议(Dynamic Host Configuration Protocol，DHCP))感兴趣。

上述讨论了用于采集数据的协议与待采集数据之间依赖的几种类型。待采集数据与应该对采集的数据执行的使得所述数据对管理系统有用的预处理和后处理操作的类型之间也可能存在关系，哪类数据(如果有)应该在上述操作中的哪个步骤如预处理或者后处理存储在哪类存储库中。这些依赖集与关系集要求计算与存储资源的协调和优化。本发明所示的示例实施例可以利用信息模型中表现的知识定义代表ManageableEntity的模型元素的特性和行为，并且代表不同类型的决策制定、推理过程和规则以管理该过程的应用。

图1a示出了管理环境100，其中第一实体105管理第二实体110。所述第一实体是管理系统的一部分，第二实体是被管理的系统的一部分。需要说明的是，不失一般性，术语管理可以指监控和/或配置。还需要说明的是，尽管示出为单个实体，但第一实体105和第二实体110可分别代表多个实体。

第一实体105可以通过一级或者多级管理且与所述第二实体110交互。例如，管理可以发生在操作系统级115，其中第一实体105可以利用协议如Web管理接口(web management interface，WMI)等管理第二实体110。管理也可以发生在软件级120，其中第一实体105可以利用协议如命令行接口(command line interface，CLI)、SNMP以及表征状态转移(representational state transfer，REST)等管理第二实体110。管理也可以发生在应用级125，其中第一实体105可以利用协议如系统日志(system log，Syslog)以及REST等管理第二实体110。管理也可以发生在硬件级130，其中第一实体105可以利用协议如SNMP以及机器间可扩展标记语言(machine to machine extensible markup language，M2MXML)等管理第二实体110。实体115、120、125和130分别代表被管理的系统的不同方面，所述管理系统可以从第二实体110获得所述实体的当前状态、取值和/或配置信息，然后可以改变这些方面(即实体115、120、125和130)的一个或者多个方面作为管理过程的一部分。

本发明所示的示例实施例利用面向对象的信息模型定义感兴趣的管理实体(如通信系统中的实体)。本发明所示的讨论会利用如下术语：

-信息模型是一个抽象概念，代表管理环境中的实体。这包括实体的属性、操作以及关系的定义。信息模型与任意特定类型的存储库、软件使用或者接入协议相互独立。

-数据模型是适合利用特定接入协议的特定类型的存储库的信息模型的具体实现。所述数据模型包括数据结构、操作以及定义所述数据如何存储、接入和操作的规则。

-模型映射是一种类型的模型至另一种类型的模型的转化。模型映射将一种模型中使用的代表和/或抽象级改变为另一种模型中的另一种代表和/或抽象级。

-术语“模型元素”是定义可在信息模型中表示的抽象概念的通用术语。例如类、属性、不同类型的关系(如关联、聚合以及合成)以及其他构造等。

-策略规则为智能容器。所述策略规则包括定义如何在管理环境中使用策略规则的数据，以及指示策略规则应用的管理实体如何交互的行为规范。所述包含的数据分为四种类型：(1)定义所述策略规则的语义和行为以及施加于所述系统的其他部分的行为的数据和元数据；(2)可以用于触发评估策略规则的条件条款的事件集；(3)允许执行一个或者多个策略动作的策略条件(如果正确)的集合；(4)执行一个或者多个操作的策略动作(如改变给定设备的配置或者从给定设备采集数据)的集合。

-ManageableEntity定义为管理环境中可以执行和/或响应管理功能的任意感兴趣的实体。ManageableEntity的示例包括设备(如路由器、交换机以及主机等)、作为设备一部分的实体(例如物理端口和设备的逻辑接口)、协议、应用、服务器以及服务，简而言之，任何可以响应管理请求的实体。

-行为表示为捕获管理行为的四个不同方面的模型元素的集合：(1)一种将ManageableEntity唯一地确定为上下文功能的方法；(2)对ManageableEntity可以基于不同类型策略规则以及在管理域中(以及在联合的管理域之间)执行的状态机而产生和消耗机制集进行管理的功能和角色；(3)指挥和/或设计一个或者多个ManageableEntity的行为的能力(指挥从ManageableEntity自身角度定义ManageableEntity集的行为，而设计从其他ManageableEntity角度定义ManageableEntity集的行为)；(4)可以与管理实体交互、利用管理实体和/或在管理实体上操作的角色(人与计算机)集的定义。

-基于网络的数据采集可以定义为有效采集与网络中可用的ManageableEntity相关的信息的能力。这具体指的是处于“父”级以及“子”级的ManageableEntity(如设备和其端口或者应用和该应用提供的服务)。

-代理数据采集涉及将管理设备上本地运行的专用软件作为管理基础设施的一部分，所述基于代理的软件只致力于管理(其包括但可不限于数据采集)。

-无代理数据采集涉及从ManageableEntity采集数据，无需在控制ManageableEntity的设备上安装任何新软件。无代理数据采集与代理数据采集的主要区别在于无代理数据采集不涉及在任意待监控机器上安装任何新软件。

-数据采集管理方法定义为数据模型、协议以及使采集的数据得以分析、处理并理解的软件的集合组合，从而使得产生采集数据的ManageableEntity可以被监控和管理。

图1b示出了包括管理系统153和第二实体160的管理环境150的示例。第一实体155是管理系统153的一部分，并且管理第二实体160，所述第二实体160是管理环境150的一部分。管理环境150可以利用第一实体155接收从第二实体160采集数据的管理请求161。第一实体155可以查询信息模型163确定是否存在可用的第二实体160的信息。信息模型163以面向对象的形式对可以被认为是代表第二实体160的功能和行为的模型元素集的原型信息和行为进行定义。也可以定义注释164，注释164用于描述定义代表第二实体160的合适实例的合适对象集的时间、版本、其他元数据以及该对象是否已经在一个或者多个数据模型166中定义。如果第二实体160的知识(例如当前运行的是哪个操作系统的哪个版本)不足，则第一实体155需要交换一个或者多个消息，例如能力请求167和能力响应168消息，第二实体160确定所述第二实体160支持的功能和行为。所述能力请求167和能力响应168消息可以基于信息模型163中包含的知识。任意数据的交换包括此交换中示出的数据的交换，其可以包括两个单向交换，一个用于请求数据，一个用于返回请求的数据。

第一实体165可以检查要求从管理请求161采集的数据，并且将该请求与第二实体160的能力对比，以确定如何最好地获得所述请求的数据。问题是数据采集过程中的很多元素可能会互相依赖。例如，使用的协议的类型可能影响哪类数据可以被采集，以怎样的频率和粒度采集等其他因素。利用信息模型163将这些和其他依赖建模。例如能力请求167和能力响应168消息的交换定义了同时被第一实体155和第二实体160支持的协议。利用这些协议，第一实体155可以向包括第二实体160的合适的ManageableEntity发出数据请求的集合，其中第二实体160中的每个ManageableEntity都可以利用相同或者各自的协议。

在一个说明性的示例中，第一实体155可以发送超文本传输(安全)协议(Hypertext Transfer Protocol(Secure)，HTTP(S))能力请求至第二实体160以提供各种性能指标，例如上一次重新启动至今的时间以及当前正使用的存储量等。这类指标通常会有多种协议(如简单网络管理协议(Simple Network Management Protocol，SNMP)、系统日志(system log，Syslog)以及命令行接口(command-line interface，CLI)等)支持，但是每个协议可能使用不同的资源集，准确度也会有所不同。通过使用信息模型163，第一实体155可能会通过优化相同协议的使用首先优化对第二实体160数据的请求，以尽可能获得最佳数据。包括第二实体160的ManageableEntity集可以利用第二实体160的数据模型166定义，其中数据模型166可以从信息模型163派生出。

因此，第一实体155可以利用特定协议和特定管理接口向第二实体160请求特定数据(例如用于操作系统数据的WMI，用于软件的CLI以及用于硬件的SNMP等等)。需要说明的是，一种协议可以用于支持一种或者多种类型的数据，特定类型的数据可能会要求多种协议以获得构成特定类型数据的所有信息(例如，这在图1a中利用用于检索所有来自第二实体110的软件信息的CLI、SNMP以及REST的组合示出)。这些请求查询合适的属于第二实体160一部分的ManageableEntity。查询回复可以通过第二实体160接收请求的相同管理接口返回。然后第一实体155可以读取采集的数据，可选地，处理和存储所述采集的数据，然后通知所述数据的请求者数据准备完成或者直接将所述数据发送给请求者。

图2a示出信息模型205和数据模型集之间的关系和映射。从概念上说，信息模型205提供了数据和被管理的通信系统之间内在联系的视图。信息模型205使得代表的信息、知识、观点、关系、模式以及原理以与技术无关的方式建模。相反，数据模型如数据模型210至212以及数据模型220至222可以被认为是信息模型205的实例。数据模型可以从信息模型205派生出并且可以互相关联，因为数据模型共用在信息模型中定义的概念。定义相同概念的信息模型和数据模型之间的区别在于这些概念通过技术、语言和/或协议的实现。一般来说，信息模型不会使用任意特定平台、特定语言和/或协议专用的定义。另一方面，数据模型通常会与这三个特征(平台、语言和协议)中至少一个通常是所有的特性紧密结合。

数据模型可能有多种类型。数据模型的第一类型可以是信息模型205的技术特定的但是与供应商无关的实例化。例如，数据模型210至212是信息模型205的技术特定的但是与供应商无关的实例化，可以利用目录、关系数据库以及平面文件代表概念。数据模型的第二类型可以是信息模型205的技术特定的且供应商特定的实例化。例如，数据模型220至222以及数据模型211是信息模型205的技术特定的且供应商特定的实例化。

图2b示出数据语义(即理解)和数据连通性(即这些数据如何互相关联以及关联到被管理的系统的当前上下文或者未来上下文)之间的关系250。典型地，当原始数据之间的关系是已知的时候，原始数据变为信息。一旦模式是已知的，信息可能会变为知识，反过来，一旦原理是已知的，则信息变为观点。信息模型可以用于定义可以用于将数据转换成信息、知识和观点的方法集。

一般来说，信息模型可以：

-包含可以根据不同参数(如策略和上下文等)集中组织的不同类型的知识，其中这些参数可以用作上下文定义的滤波器以说明采集的数据；

-利用足够的支持数据帮助组织从采集数据推理的数据之间的关系；

-利用适用于特定选区或者选区集的视图而不仅仅是参数组织知识；

-定义可以用于定义如何对网络数据进行采集、聚合、过滤、匹配、管理以及对网络数据执行的其他处理操作的模式，由于信息模型中存在面向对象的类和关系定义，因此所述操作是可能的；

-允许使用不同类型的协议，可以揭示单个网络实体或者网络实体集的不同类型的数据以及其相互之间的约束；

-独立于技术、平台和协议，使得待使用的信息模型通过映射集支持多个数据模型；由于信息模型根据如何采集数据以及采集的实现将网络对象的规格和网络对象之间的关系抽象化，使得信息模型优于开始于特定的数据模型；

-根据附加增强如元数据的实现、使用一阶逻辑的推理以及附加机制对网络对象的规格及其关系进行抽象化；

-使得采集过程与用于验证给定的网络实体具有的其他行为的附加后采集过程任务相分离；

-使得行为定义为包括在信息模型中且定义行为的语法和静态语义(静态语义指的是可以在影响ManageableEntity的状态的设计时间定义的行为的方面)的概念集，所述行为可以由也可以在信息模型中定义的包括但不限于策略规则和状态自动机的概念集执行。

利用信息模型的益处在于信息模型提供自描述的机制集，所述机制定义知识可以如何被用于描述特性的语义和ManageableEntity的行为，包括其属性和关系。

图3示出了包括通信系统以及基于信息模型的管理系统的示例系统300。系统300包括通信系统305和可以用于管理通信系统305的管理系统310。管理系统310包括可以利用数据处理单元320处理从通信系统305采集的数据的管理实体315。管理系统310提供知识库322，所述知识库322可以使得管理系统310确定采集哪类数据以及如何采集数据，也可以包括如果分析处理从所述通信系统305采集的数据的指令等。知识库322可以实现通信系统305的信息模型以及其一个或者多个数据模型。有限状态机324可以用于控制管理实体315的操作。

管理系统310也可以包括从通信系统305中的实体采集数据的数据采集系统330。数据采集系统330可以利用管理实体315指定的一个或者多个协议从通信系统305采集数据。数据采集系统330可以利用流数据单元332将数据流向管理实体315。所述流数据可能会无序或者零散地发送，或者丢失部分数据等。部分数据可以在特定情况下利用指定协议检索。管理图形用户接口(graphical user interface，GUI)335可以允许操作人和管理人等用户与管理实体315以及通信系统305交互。

依赖分析

图4示出为了管理系统的一部分的突出功能提供细节的示例管理系统400。管理系统400包括管理实体405，所述管理实体405可以(通过数据采集系统410)确定待采集数据的类型；(通过协议单元415)确定用于采集数据的协议的类型；(通过处理器420)确定待提供给采集的数据的处理类型(如在采集数据期间发生的预处理和/或在数据采集完成之后发生的后处理)；以及(通过存储单元425)确定用于存储采集的数据的存储类型(如预存储，即在采集数据期间使用的暂时性存储，和/或后存储，即在数据采集完成之后使用的暂时性和/或永久性存储)。如之前所讨论的，管理系统400，具体来说是管理实体405，可以利用通信系统的信息模型确定给定数据采集任务所需的数据类型、协议类型、处理类型以及存储类型。

通信系统的信息模型的使用允许可以用于定义存在于待采集数据的类型、用于采集数据的协议类型、对所述采集数据进行预处理和后处理操作类型以及哪类数据(如果有)应该存储在哪类数据存储库等之间的相关语义的通用模型元素的集合。每个相关语义可以代表数据采集过程的基本部分之间的依赖。此外，每个相关语义都是单向的。例如，待采集数据的类型约束可以使用的协议类型，因为协议类型可能需要满足大量要求，包括：(1)所述协议需要能够可靠地传输数据(并且可能是安全地)，这意味着每个数据的准确性以及整个数据集都不应该更改；(2)所述协议需要能够支持对数据进行的合适操作(如创建、读取、更新以及删除等)。类似地，所述协议限制数据的类型，因为(1)所述协议需要能够支持待采集数据使用的数据结构；(2)所述协议需要与数据的使用语义相配。例如，虽然目录可以理论上存储并且检索任意类型的数据结构，但是它们的协议(如轻型目录访问协议(Lightweight Directory Access Protocol，LDAP))甚至是其更稳健的版本X.500(利用ITU-T定义目录服务的标准的集合)主要设计为与简单的文本搜索应用一起使用。这可能对数据如何在目录中搜索、创建、编辑以及检索造成基本限制。

如果上述依赖均被理解且满足，则可以建立统一的平台，即与技术相互独立的平台用于实现协议的类型、ManageableEntity的类型、待采集数据的类型、待执行的预处理和后处理类型、存储操作类型以及待执行的存储类型等。特别地，所述统一平台允许：

-可再次使用的抽象概念集，因为协议、数据、预处理功能、后处理功能、数据存储以及存储操作均可能表示为模型元素，作为可再次使用对象存在于管理系统中；

-用于按照所述信息模型提供的来创建可再次使用抽象概念的模式集，其可以简化结果设计和实现；

-用于识别ManageableEntity以及其属性和行为的机制的可扩展集，因为ManageableEntity可以利用属性、关系、元数据、行为和/或结构的集合进行识别；

-基于代表采集数据的ManageableEntity或者ManageableEntity集的内部模型元素和外部模型元素管理数据的采集的能力；

-确定是否有附加数据需要从已经访问的ManageableEntity采集的能力(允许虚拟比较采集的ManageableEntity的数据和信息模型中ManageableEntity的表示，并且确定是否存在数据丢失)；

-定义在哪类预处理操作和/或后处理操作(如果有)执行之后哪类采集数据应该存储在哪类数据存储库(如果有)的能力；

-定义上述哪个特征(如果有)受环境的上下文中哪类变化的影响的能力。

采集数据的管理系统的高级概述

图5示出了示例管理系统500的组件的详细视图。如图5所示，管理系统500包括管理实体505、数据存储层510以及数据采集系统515的详细视图。管理系统500包括利用各种匹配技术包括基于特征的匹配、基于结构的匹配、基于行为的匹配以及语义相关性的匹配等识别对象类的多个类识别单元，如ManageableEntity。数据存储层510可以为采集的数据提供存储和/或管理。采集数据的存储管理的示例包括关系型数据库管理系统(relational database management system，RDBMS)以及非结构化查询语言(not only structured query language，NoSQL)等。

数据采集系统515可以包括控制数据采集的初始过程520，即包括开始和/或终止数据的采集。也可以包括负责采集多个采集代理(如采集代理530)提供的数据的采集管理器525。由于多个采集代理提供的数据可能是零散且无序的，也可能存在数据丢失，因此采集管理器525会碎片重整(或者等效、碎片整理)、重排、调整和/或恢复所述采集的数据。所述采集的数据可以提供给管理实体505。数据采集系统515可以接收对从管理实体505采集的数据的指令。

采集的数据即从ManageableEntity或ManageableEntity集采集的数据可以用于发现现有的ManageableEntity是否增加新的能力(例如增加有附加端口的新网卡)，或者通信系统是否增加新的ManageableEntity(例如创建新的虚拟LAN(virtual local area network，VLAN))。对应于管理系统500的两个示例能够检测到被管理的系统的新物理和逻辑(或者虚拟)能力的增加。类似地，数据采集可以用于发现现有的ManageableEntity和/或ManageableEntity的能力是否已经从系统中删除或者是否不再正常工作。所述采集的数据也可以用于采集在计算和/或评估ManageableEntity的性能等级中使用的指标。所述指标也可以用于生成警示和/或故障、优化ManageableEntity的性能、进行维护操作并且执行附加管理操作等。这些通常称为操作和/或管理操作的操作可能会更复杂，因为不同类型的ManageableEntity有着不同类型的特性和行为。此外，ManageableEntity的单个实例可以在不同的上下文中展现出不同的行为。因此，需要稳健的机制将上下文的影响与数据的采集关联。

数据采集也可以用于查询现有的父节点和/或子节点以确定关于每个节点的附加信息。通常，假设已知的ManageableEntity集(这里称之为父节点)，每个父节点可以有子ManageableEntity集(如ManageableEntity的端口或者应用的服务)。例如，节点的类型通常会决定可能与该节点相关的ManageableEntity的类型以及协议、媒体播放器和其他组成这些关系语义的物理和/或逻辑特性。示例包括端口结合和链路聚合(其是使用的端口类型、媒体类型以及协议类型的功能)。不同类型的VLAN以及虚拟私有网络(virtual private network，VPN)有相同的语义。类似地，服务也可以利用几个不同协议(如简单服务发现协议(Simple Service Discovery Protocol，SSDP)、服务定位协议(Service Location Protocol，SLP)以及通用即插即用(Universal Plug and Play，UPnP)等)从父节点和/或子节点中找到。这些协议有着不同的应用，因此有着不同的语义。因此，信息模型利用通用模型元素的集合以及通用语义的集合为表示不同类型的ManageableEntity和其关系提供单源。

通常，从ManageableEntity采集且附着到一个或者多个通信系统的数据会混合，使得将数据与数据所属的特定ManageableEntity关联变得困难。这可能会根据变化加剧，例如ManageableEntity可能会在没有通知管理系统的情况下加入或者离开管理系统。此外，ManageableEntity可能会发生变化。例如，ManageableEntity的配置可能会发生变化，这会改变ManageableEntity提供的功能。所述通信系统的信息模型提供识别ManageableEntity或ManageableEntity集的一个或者多个能力所需的知识。因此，通过将不同管理实体的不同能力的相同方面进行匹配，可以实现异类实体管理的归一化。一旦确定通用能力的集合，则可以继续对适用的ManageableEntity集进行更多处理(如果需要)。

信息模型可以用于优化数据采集过程或者从所有的ManageableEntity或者ManageableEntity的子集获得数据的过程集。所述优化可以基于优化因素进行，所述优化因素包括待采集数据的性质、有关ManageableEntity的类型、使用协议的类型、通信系统的上下文、用户需求和/或所述采集的数据的应用等。优化可以包括确定哪个用户和/或应用需要相同的数据以及优化数据的采集，使得尽可能少的查询所述数据；使用相同的协议并且优化数据的采集，使得协议连接的数据最小；使用相同的命令(例如供应商特定的CLI和与供应商无关的脚本语言等)查询相同或者不同ManageableEntity的不同属性并且优化数据的采集(可选地，利用经过不同过滤的不同属性)。

ManageableEntity A的行为可以定义为内部属性和/或有关ManageableEntity A的关系的集合，和/或外部的类、属性和/或ManageableEntity A与代表一个或者多个ManageableEntity B₁......B_n的模型元素集之间关系的集合。需要说明的是，当单个ManageableEntity A被ManageableEntity集A₁......A_m替代时，该定义依然成立。信息模型的使用可以使得行为可以通过机制自身在信息模型中表达的机制集(例如通过专用的模型元素集)如策略规则和/或状态机静态定义管理。也可能动态定义行为并在行为中启用变化。

所述信息模型的使用可以使得管理实体与技术特定的实现相互独立。这对于使用的协议、待采集数据的类型、数据采集操作的目标ManageableEntity的类型(例如存储设备对网络设备对服务器对应用)、数据如何采集、对采集数据进行的预处理和后处理类型、用于采集数据的存储类型以及ManageableEntity如何表示等都是适用的。此外，所述管理实体与数据采集机制如采集代理、无代理采集或者二者结合相互独立。

元数据增强型基于模型的库存管理过程的概述

图6示出了管理实体为通信系统中的一个或者多个实体控制数据采集时发生在管理实体中的高级操作600的流程图。操作600可以是管理实体为通信系统中一个或者多个实体如ManageableEntity控制数据如库存数据的采集时发生在所述管理实体中如管理实体315、管理实体405以及管理实体505的操作说明。

操作600可以开始于管理实体接收采集库存数据的请求(方框605)。所述请求可以是所述管理实体的用户输入、在所述管理实体或者其他管理实体中执行的应用、外部管理实体、所述管理实体的另一种例化(如在分布式库存管理系统中)等形式。

根据一个示例实施例，所述请求包括必选部分和可选部分。所述必选部分可以是用户用于指定针对每个请求搜索的信息，而可选部分可以是用户用于定义用户想要提供的任意特定元数据。所述元数据本质上可以是叙述性的和/或规定的。

所述管理实体也可以解析所述请求(方框605)。解析所述请求可以包括确保所述请求的有效性以及检测所述请求中的误差等。解析所述请求也可以包括词素和词汇预处理。所述词素和词汇预处理可以帮助简化后续解析和决策操作。例如，通过执行词素归一化操作，使得单词的单一标准形式可以用于将不同形式的单词分组为同类词素家族。在又一个示例中，词素和词汇预处理可以识别所述请求中没有显示提及的请求元素(如正在使用的协议和正在采集的数据)之间的附加依赖。解析所述请求也可以包括词性(part of speech，PoS))令牌的产生，用于帮助指导进一步处理。

所述管理实体可以生成一个或者多个模型元素(方框610)。模型元素的生成可以包括从解析后的请求中提取上下文令牌和内容令牌。所述上下文令牌集中代表用户和/或管理实体已知的外部元数据和只有管理实体知晓的内部元数据。所述内容令牌包括用户想要检索且转换为允许不同组件之间已定义依赖的形式的信息。另外，所述上下文令牌和内容令牌可以映射到模型元素。

所述管理实体可以生成图形和/或可扩展标记语言(Extensible Markup Language，XML)纲要定义(XML schema definition，XSD)(方框615)。图形和/或XSD的生成可以包括将由内容令牌到模型元素的映射过程所产生的图形集合并为单个图形，并且后续对所述图形进行优化。所述优化的图形可以转换为XSD，其将查询结果描述成与平台无关的格式。

所述管理实体可以利用一个或者多个XSD执行采集和分析数据需要的操作(方框620)。所述XSD指导数据的采集和分析，其可以由管理系统组织和库存。所述管理实体可以处理XSD的结果，即所述数据(方框625)。例如，所述管理实体可以将结果处理成可以显示给用户的形式。

图7示出了管理实体为通信系统中的一个或者多个实体控制数据采集和处理时发生在管理实体中的操作700的流程图。操作700可以是管理实体为通信系统中一个或者多个实体如ManageableEntity控制数据比如库存数据的采集时发生在所述管理实体如管理实体315、管理实体405以及管理实体505中操作的详细视图的说明。

操作700可以开始于管理实体接收采集库存数据的请求(方框705)。所述请求可以包括必选部分和可选部分。所述必选部分可以包括用户提供的管理实体将库存的信息细节，而所述可选部分可以包括用户提供的或者用户定义的元数据。所述用户定义的元数据本质上可以是叙述性的和/或规定的。需要说明的是，所述请求可以是人直接输入或者应用、系统或者另一个管理实体输入等形式。出于讨论目的，假设所述管理实体正在与个人用户交互。但是关注个人用户不应该构成对示例实施例的范围或者精神的限制。此外，为了消除混淆，请求可以用于指代必选部分、可选部分或者同时指代必选部分和可选部分。

根据一个示例实施例，所述请求可以以必选部分(例如作为必选查询串)和可选部分(例如作为可选查询串)的形式提供给管理实体。所述必选查询串可以称为必选查询，所述可选查询串可以被认为是可选查询。对于两组查询串的输入可能没有约束。在一个说明性的示例中，所述约束可以通过强制用户在预填充的单选按钮、列表框以及组合框等中选择来限制用户。约束较少的示例可以允许用户自由进入两组查询串。

如果存在可选查询，则可以增加特殊标签。所述请求(必选查询和可能的可选查询)可以被验证(方框707)。如果两种查询都存在，此时可以将所述必选查询和可选查询视为单独的查询，因为可选查询没有与必选查询集成。如果没有可选查询，则单独验证所述必选查询。

所述验证可以确定所述请求中存在哪种依赖。一般来说，可能有多种不同类型的依赖，包括采集数据的类型、用于采集各种类型数据的协议类型、对各种类型数据执行的预处理和/或后处理类型以及对各种类型数据执行的存储操作类型。所述验证可以产生定义请求数据、使用协议、预处理和/或后处理数据的操作以及数据采集之前/数据采集之后的数据存储之间依赖的元组。也就是说产生了针对所述请求存在的完整的依赖集。

图8示出了定义数据和其处理之间依赖的元组800。元组800可以是解析请求的输出示例，以形成依赖列表(方框610，图6)。根据示例实施例，元组800定义了请求数据、待使用的协议、用于预处理和/或后处理数据的操作以及发送数据之前或者发送数据之后数据的存储之间的依赖。第一行805(即第一组四类语句)代表待采集数据的类型和待使用的协议之间的依赖。由于所述依赖是从数据类型到协议集，因此下标只显示协议。此外，由于需要使用协议检索任意类型的数据，因此只有第一协议是必选的。第一行的其余部分是可选的，并且可以简化如下：

{{D_协议1[，D_协议2，……D_协议A]

[可选预处理]

[可选后处理]

[可选预存储]

[可选后存储]……}，……

第二组四类语句(第二行810)是类似的，用于定义协议依赖，首先是数据，然后是预处理、后处理、预存储以及后存储。类似地，六行中的第三行针对预处理，然后是后处理、预存储以及后存储所做相同。需要说明的是，符号[……]表示括号内的文本是可选的。

第二行810定义使用的协议与采集的数据的类型、使用的预处理方法、使用的后处理方法以及任意关联的存储要求之间的依赖。此行与第一行之间的区别在于第一行从数据的角度描述依赖，而此行从协议的角度描述依赖。这是非对称关系，因此每个依赖可能不同。需要说明的是所述依赖是可选的。

第三行815定义了使用的预处理方法与采集的数据的类型、每种方法使用的协议、使用的后处理方法以及任意关联的存储要求之间的依赖。需要说明的是所述依赖是可选的。

第四行820定义了使用的后处理方法与采集的数据的类型、每种方法使用的协议、使用的预处理方法以及任意关联的存储要求之间的依赖。需要说明的是所述依赖是可选的。

第五行825定义使用的“预存储”方法与采集的数据的类型、每种方法使用的协议、使用的预处理和后处理方法以及任意关联的后存储要求之间的依赖。因此，术语“预存储”指的是在数据采集过程中需要的暂时存储。需要说明的是所述依赖是可选的。

第六行830定义使用的“后存储”方法与采集的数据的类型、每种方法使用的协议、使用的预处理和后处理方法以及任意关联的预存储要求之间的依赖。因此，术语“后存储”指的是在数据采集处理操作结束之后需要的暂时性和/或永久性存储。需要说明的是所述依赖是可选的。

返回参考图7，所述管理实体可以进行检查以确定所述请求是否存在误差(方框709)。如果所述请求存在误差，则所述管理实体可以在请求中注释误差(方框711)并且返回方框705接收另一个请求。一般来说，确定所述请求是否存在误差的检查可以是自动动作等未来动作的链接。但是由于并非所有事物都是自动的，因此也可能需要人为干涉。

如果所述请求没有误差，所述管理实体可以对所述查询进行词素和/或词汇预处理操作(方框713)。所述词素和/或词汇预处理操作可以在后续操作中简化查询解析。在一个说明性的示例中，所述管理实体可以进行词干提取和/或词形还原等词素归一化操作，以利用单词的单个标准形式将不同形式的单词分组为同类词素家族。在实践中，词干提取删除词形的尾部，即删除任意曲折词素和/或派生词素，留下词根词素。

但是由于部分单词是同形异义词(拼写相同但是意思不同的单词，如单词saw、bass等有很多可能的形式和意思)，因此简单的词干提取是不够的。在这种情形下，也可能需要单词的语法分类。词形还原通过将词形映射到其词元(或者基础)形式提供语法分类。典型地，对词形还原与词性标签进行结合以消除复杂情况的歧义，并且可以作为解析操作的一部分执行以产生词性(part of speech，PoS)令牌(方框717)。

词汇分析通过检查构成单词的词素集合并且将单词与其词性和其他数据对比致力于单词结构。词汇分析还可以基于存储规则采取更多动作。词汇分析可以解释拼写错误并且提供其他用途。通过一个或者多个设置(方框715)，方框713(词素和词汇预处理)和方框717(解析产生PoS令牌)均可以为用户可配置的。

所述解析产生PoS令牌(方框717)可以利用任一常用解析算法解析采集信息的请求，只要使用的解析算法能够产生将所述请求的文本表示映射到令牌集的PoS令牌集，其中每个令牌负载由关联标签集定义的单个词性。此外，可以使用任意PoS标注器。在一个说明性的示例中，标注器可以提供详细的标签(例如能够区分单数名词、复数名词以及单数专有名词等的标签)。

集中地，方框705至717可以称为接收和/或解析请求(方框719)并且可以是图6的方框605的实现。

所述管理实体可以从解析后的请求中提取上下文令牌(方框721)。一般来说，所述上下文令牌代表用户和/或管理实体已知的外部元数据以及管理实体知晓(或者是管理实体可以从管理系统的管理元素中找到的)的内部元数据。根据示例实施例，使用利用DEN-ng能力的信息模型。这样的信息模型可以将集成元数据类层次作为其模型的一部分，并且所述元数据类层次可以与代表管理系统的管理对象的主类层次无缝集成。

图9示出类层次900。类层次900是DEN-ng类层次。RootEntity 905可以位于类层次900的顶部。RootEntity 905的属性可以启用所述环境中所有对象(包括可管理和不可管理的对象)的名称、描述以及识别。一般来说，实体910是扩展(抽象)RootEntity类905以表示对于所述被管理环境重要的对象类的抽象类。实体910可以表示独立存在的对象，区别于可以代表非独立存在的且只是属性或者行为的抽象概念聚集的对象的(抽象)值类915。实体910的子类可以发挥一个或者多个业务功能，并且代表所述环境中实体的特性和/或行为。实体可以被管理(如网络设备)或者不被管理(如机箱)。

元数据920可以是抽象类，定义描述或规定元数据920应用的实体910或者值915的状态的信息。分类理论可以用于确保实体和值只包括定义实体910或值915需要的特性和行为。其他描述性的和/或规定的数据在附着于各自实体和值的元数据中描述。在DEN-ng设计中，元数据用于实现元数据驱动设计，所述设计使得行为在运行期间动态添加，无需改变或者编辑管理系统的代码。

参考类层次900，任意实体都可以有关联的元数据。EntityMetadataDetail关联类925可以使得利用策略规则控制哪类元数据可以与哪类实体关联。特别地，一个任务可以是元数据的一个子类。因此，EntityHasMetadata聚合以及EntityMetadataDetail关联类925可以用于为给定的上下文定义特定的实体允许承载的任务。这是通过利用DEN-ng策略模式将策略规则的应用自动化，以利用合适的元数据子类集改变行为，定义利用合适的上下文子类子集指定想要的行为所需的元数据，以控制哪个策略规则集在什么时间是激活的。

EntityMetadataDetail关联类925可以是必选的抽象关联类，并且定义所述EntityHasMetadata聚合的语义。EntityMetadataDetail关联类925包括对于指定实体和元数据如何互相关联常见的属性和关系。由于有不同类型的实体和不同类型的元数据可以与每个实体关联，因此EntityMetadataDetail关联类925是抽象的以使得利用类型对象模式建立合适的具体子类集，以对存在于不同实体和不同元数据之间的不同语义建模。在一个说明性的示例中，虽然所有的实体都有定义版本历史的元数据，但是企业中的不同组织可能以不同的方式定义版本信息。在这样情况下，可以利用所述类型对象模式定义此关联类的不同的具体子类，以反映数据模型中每个组织的不同版本要求。由于每个具体的子类继承了常用属性的集合以及定义在所述关联类中的关系，因此哪类元数据可以与哪类实体关联的定义可以以通用的方式分配和管理，任意需要的差异可以在所述关联类的具体子类中反映。所述DEN-ng策略模式用于利用上下文感知策略规则适当地限制或改变元数据为处于特定上下文中的实体提供的信息。这对于使得行为适应变化的上下文是基础。

根据示例实施例，元数据可以用于设置评估请求内容和存在于请求中的依赖之间的关系度的上下文，所述请求中的依赖即所述请求数据、使用的协议、用于预处理和/或后处理数据的操作以及数据发送之前或数据发送之后的数据存储。也就是说设置上下文可以通过确保请求的语义均已定义且已正确考虑来帮助评估内容。设置上下文也可以通过提供附加数据用于测量特定依赖如何影响请求来帮助测量每个依赖的强度。

图10示出利用元数据建立上下文的图1000。如图10所示，用户1005向管理实体输入请求1010。请求1010可以包括必选查询文本1015(之前称为必选部分)和可选元数据文本1020(之前称为可选部分)。所述管理实体可以解析请求1010以确定实体对象1025和元数据对象1030，其中实体对象1025为元数据对象1030提供外部元数据。实体对象1025可以包括内部数据和/或外部数据，而元数据对象1030可以提供静态和/或动态行为规范。同时，实体对象1025与元数据对象1030可以用于指定管理实体的能力。例如，实体对象1025和元数据对象1030可以用于确定当前支持的特征、可以支持且不会逆向影响现有服务的特征以及即使影响现有服务也可以支持的特征。

返回参考图7，所述管理实体可以将上下文令牌映射到第一模型元素集(方框723)。所述上下文令牌到第一模型元素集的映射产生模型元素的图形或者多重图。所述管理实体可以从解析后的请求中提取内容令牌(方框725)。实际上，解析后的请求的内容是以令牌的形式表示。所述内容令牌可以是信息集的代表，所述信息是用户想要检索但是转化为使得管理实体容易定义存在于所述信息采集的不同部分之间的依赖的形式的信息。所述管理实体可以将内容令牌映射到第二模型元素集(方框727)。所述内容令牌到第二模型元素集的映射可能与上下文令牌到第一模型元素集的映射类似，除了该映射是通过内容而非上下文进行的。一般来说，所述上下文可以定义选择和/或限制信息模型等代表的管理系统的功能如限制关联基数。也就是说从查询的上下文派生出的模型元素集725可以用于限制从查询的内容派生出的模型元素集727代表的功能。由于元数据可以代表待采集数据的描述性和规定的信息、如何采集数据以及关于采集过程的其他相关因素，因此元数据通常在管理实体中尤其是数据采集方面起着重要作用。因此元数据可以帮助更精准的定义依赖。

集中地，方框721至727可以称为生成模型元素(方框729)并且可以是图6的方框610的实现。

所述管理实体可以合并并且优化由所述内容令牌到第二模型元素集的映射产生的第二模型元素集的图形或者多重图(方框731)。所述图形或者多重图的合并可以产生单个优化图(如果可以)。所述管理实体可以将优化图转换为XSD文件的集合(方框733)。所述XSD文件的集合可以以与平台无关的形式描述请求结果，并且提供所述请求的机器可理解且与平台无关的表示。集中地，方框731至733可以称为生成图形和/或XSD(方框735)并且可以是图6的方框615的实现。

所述管理实体可以执行请求并且采集实时数据(方框737)。所述采集数据可以根据XSD文件等组织和/或库存。由于采集数据的组织和/或库存可以产生XML XSD文件集，因此通过利用各种XML工具回答问题和/或执行请求中的命令可以很容易获得请求结果。方框737可以称为运行所述请求(方框739)并且可以是图6的方框620的实现。所述管理实体可以将请求结果转换为可显示形式，并且将所述请求结果显示给用户(方框741)。方框743可以称为处理结果(方框745)并且可以是图6的方框625的实现。

图11示出在管理实体生成模型元素和XSD文件时发生在管理实体中操作1100的流程图。操作1100可以是在管理实体生成模型元素和XSD文件时发生在管理实体如管理实体315、管理实体405以及管理实体505中操作的指示性详细视图。操作1100可以是图7的方框721至741的示例实现。

操作1100可以开始于管理实体执行检查确定是否存在可选的元数据(方框1105)。也就是说所述管理实体可以执行检查确定用户是否输入可选的元数据术语。如果存在可选的元数据，则管理实体可以解析所述可选的元数据，并且为所述可选的元数据生成词性(part of speech，PoS)令牌(方框1107)。如果不存在可选的元数据，则管理实体可以定义默认的上下文，并且产生适合于所述默认上下文的PoS令牌(方框1109)。

在定义所述PoS令牌(如上下文PoS令牌)之后，管理实体可以检查内容令牌(方框1111)。所述内容令牌的检查可以帮助确保在没有使用DEN-ng引申模型(或者没有DEN-ng能力的模型)时，所述内容令牌只代表内容而本身不包含元数据。一般来说，很多管理实体实际上将元数据嵌入管理对象的定义中以及描述管理对象的数据中。例如考虑请求内容是寻找特定的SNMP属性的情形。如果利用SNMP检索数据，则很多对于理解数据所需的关键信息包括在管理对象的数据结构的注释属性中。因此，管理实体可以检查PoS表示中的内容令牌，以便更好地确定所述请求的内容部分中元数据的存在(方框1113)。

如果存在元数据，则可以提取解析所述元数据，并且管理实体可能产生附加的PoS令牌(方框1115)。所述附加的PoS令牌可以与原始的元数据PoS令牌(在方框1111中存在)合并，从而产生元数据PoS令牌的组合统一集(方框1117)。

所述管理实体可以利用元数据PoS令牌评估所述请求的内容，以定义元数据PoS令牌和内容PoS令牌之间的链路(方框1119)。所述请求的内容也可以是PoS令牌的形式。所述PoS令牌用于帮助确认可能会考虑的所述请求的语义差别。这包括用户在请求中使用的词汇以及涉及执行请求的依赖产生的推测语义。由于所述请求的上下文和内容均由PoS令牌表示，所述请求可以通过定义所述上下文PoS令牌和所述内容PoS令牌之间的链路评估。所述请求内容的评估可以帮助确保上下文感知的应用可以正确地插装。例如，使用特殊传感器和执行器的物联网应用可以基于不同上下文(如当日时间和输入等)提供不同的数据和功能。此外，所述元数据令牌可以用于消除内容令牌的歧义。例如，请求可能会使用短语“金牌客户使用的网络设备”(其中金牌是一种服务级别)，并且描述相关元数据中“网络设备”的功能。模型中可能没有称为“网络设备”的类。但是，管理实体可以将元数据与信息模型结合使用以将该请求匹配至实际存在的实体，从而满足查询。另外，这也会对管理实体的部分选择造成限制。例如，由于查询是“金牌客户使用的……”，这使得管理实体删除订购不同服务质量的客户使用的任意网络设备。

所述管理实体可以将链路(如方框1119中定义)映射到一个或者多个模型元素的图形(方框1121)。可以利用PoS令牌构建所述一个或者多个模型元素的图形，以确定可以代表请求的不同方面尤其是请求的语义的特定模型元素。由于所述模型元素的关系将元数据对象连接至实体对象，因此在确定特定模型元素中可能发挥重要作用。策略模式的使用能够增强所述模型元素的关系的重要性。

特定模型元素的确定是使用上下文的功率的说明。在一个说明性的示例中，取决于特定的上下文，属性可以承载不同的值，关联可以实例化(或者非实例化)，作为关联类实现的关联的语义可能会有显著变化，因为上下文影响所述关联类，反过来也会影响实现所述关联的关联类的属性和关系等。

链路到一个或者多个模型元素的图形的映射可能产生模型元素图的集合，因为所述请求可能会请求互相之间没有关系的独立对象。但是，可能存在将对象连接在一起的不太明显的潜在链路。例如，用户可能会请求与硬件问题相关的数据，但是用户可能没有意识到硬件都是利用感染病毒的常见代理备份，或者部分硬件是在独立网络中操作但是其他硬件受的保护较小。所述管理实体可以优化模型元素图(方框1123)。模型元素图的集合可以通过确定是否存在共享的且可以将单个图形加入更复杂的图形结构如超图或者多重图的常见附加元素来完成优化。

所述管理实体可以注释并将图形或图形集转换为XSD集(方框1125)。所述图形或者图形集的注释和转换有助于平台依赖最大化。所述管理实体也可以将结果(所述XSD)保存至存储器等。所述XSD可以是用户请求的机器可理解版本，在这个意义上，所述XSD定义管理实体能够如何寻找匹配信息以通过对比数据和模型元素来识别数据。

所述管理实体可以运行查询并将结果(例如原始数据流)提供给单元处理(方框1127)。所述管理实体可以利用之前解析和优化的请求计划和/或请求计划的未优化版本帮助利用模型元素匹配数据实例。所述匹配过程可以利用关联匹配、结构匹配、词汇匹配或者语义相关性匹配的任意组合将每个数据确定为对应于信息中模型元素集的特定模型元素。所述匹配也可以利用识别数据识别较大的数据集，例如管理对象、管理对象的属性和管理对象之间的关系以及管理对象组。此外，所述匹配过程也继续形成越来越大的对象和对象聚合直到没有可以构建的对象。在方框1127进行的处理可以导致数据映射成模型元素图(类似于方框1123)，因此还可以继续将这些图形优化为少量但是更复杂的图形结构(方框1131)。

所述管理实体可以注释图形优化的结果，并将最终图形或者图形集转换为XSD集(方框1133)。所述管理实体可以从XSD集中提取信息并将所述信息显示给用户(方框1135)。所述信息可以是用户请求的结果。XSD集中包含的注释也可以显示给用户。所述注释可以包含针对用户的提示、意见和/或附加说明信息。

图12示出了管理实体利用元数据加强对存在于请求中不同类型的依赖的理解时发生在管理实体中的操作1200的流程图。操作1200可以是管理实体利用元数据加强对存在于采集数据的请求以及存在于用于采集数据的机制集中的不同类型的依赖的理解时发生在所述管理实体如管理实体315、管理实体405以及管理实体505中的操作的说明。操作1200可以是发生在映射链路至模型元素图(方框1121)与优化图11的模型元素图(方框1123)之间的事件描述。

操作1200可以开始于管理实体初始化计数器(方框1205)。第一计数器(depCtr)可以用于记录已经分析的依赖类型如数据、协议等的数量，第二计数器(typeCtr)可以用于记录内部依赖的数量以及已经分析的六种依赖类型，例如，如何划分“数据依赖”，已经分析的内部依赖如数据至协议、数据至预处理等有多少种类型等。在一个说明性的示例中，第一计数器和第二计数器都初始化为1。为了简化目的且不失一般性，图8中所示的元组800用于表示存在于请求数据、使用协议、用于预处理和/或后处理数据的操作以及数据发送之前或数据发送之后的数据存储之间的依赖。因此，第一计数器和第二计数器的最大值分别是6和5。

管理实体可以分析元数据PoS令牌以及元数据PoS令牌与内容PoS令牌之间的关系(方框1207)。所述管理实体可以寻找能够应用于依赖类型和每种依赖中内部依赖的附加信息。例如，如果输入的请求是“发现该SNMP属性的所有实例，其中……”，然后当管理实体分析PoS令牌时，PoS令牌立即知道至少一种待使用协议(SNMP)。此外，所述管理实体可以解析抽象语法编码1(Abstract Syntax Notation One，ASN.1)标准中且是可机读的SNMP属性定义，所述管理实体可以从所述SNMP属性定义中确定更多描述属性、范围或域限制的数据类型以及其他信息的详细信息。

根据一个示例实施例，所述管理实体可以利用允许所述管理实体(或者所述管理实体的用户)理解依赖分析如何进行的信息以及得出的任意结论注释上下文PoS令牌和内容PoS令牌。返回参考上述示例，所述注释可以包括数据，所述数据陈述了由于请求表达了找到特定SNMP数据的需求，因此SNMP是需求协议。另外，所述管理实体也可以从说明分配选择分配的数据类型的决策的相关SNMP管理信息库(management information base，MIB)对象描述定义数据类型和其他信息。所述信息的重要用途是可以提供能够用于帮助验证本文进行的转换的准确性的说明工具，并且提供持续反馈以通过机器学习等改善转换。

所述管理实体可以就依赖信息分析如图11的方框1121产生的模型元素图(方框1209)。所述管理实体在分析模型元素图时可以寻找能够应用于依赖类型以及每种依赖中内部依赖的附加信息。例如，如果输入的请求是“发现客户X体验的所有问题……”，则管理实体可以在模型元素集中查找供客户X参考。需要说明的是，所述查找包括对象类和属性的查找、对象类之间的关联的查找、限制(如对象约束语言(Object Constraint Language，OCL)的表达)的查找以及元数据的查找。返回参考上述示例，假设管理实体发现附着到关联类(关联类是用于实现关联语义的特殊类，否则，关联可以作为有着可选适配性限制的点的简单集实现)的元数据对象中的属性，和包含文本串“针对下列客户X、Y和Z当前实例化”的元数据属性。所述管理实体在解析所述文本串之后可以发现该关联与客户X有关。所述管理实体可以将关联、关联类以及所述关联连接的源类和目的类标注为应该更详细检查的模型元素。

根据示例实施例，管理实体可以注释有着与管理实体(或者管理实体的用户)需要理解依赖分析如何进行以及得出何种结论的请求的内容相关的合适附加信息的模型元素。需要说明的是，这样的注释的模型可以针对DEN-ng派生出的数据模型而不是DEN-ng信息模型实现，因为数据模型是应用特定和/或平台特定，而信息模型属于通用型。当然，请求也都是应用特定而非通用型。该信息的重要用途是可以提供能够用于帮助验证进行的转换的准确性的说明工具，并且提供持续反馈以通过机器学习等改善转换。

管理实体可以将由分析PoS令牌和模型元素图产生的依赖信息关联(方框1211)。由于PoS令牌和模型元素图的分析发生在抽象概念的不同级别因此包括不同类型的信息，所以所述关联是必要的。每次分析可以用于验证并且强化对方的结论。PoS令牌的分析可以提供每个单词、短语以及其他句子单元的详细信息，而模型元素图的分析可以提供对象级别以及请求如何在系统中实现的详细信息。由两类分析产生的信息关联也可以消除所有歧义，使得管理实体通过形成并验证关注存在于请求中明确语义和推测语义之间转化的假设来强化结论。所述管理系统可以检查关联结果，如果需要可以调整一个或者两个计数器。

所述管理实体可以通过检索下一类依赖来发起依赖分析(方框1213)。需要说明的是，必要时管理实体可以利用方框1207、方框1209和/或方框1213的结果确定各种类型的依赖如何针对所述请求表现。

管理实体可以检索下一类依赖，其对于依赖分析的初始迭代可能是数据依赖类型。一般来说，下一类依赖包括必选依赖(如至少一个协议)和四种可选依赖。假设在方框1211中没有计数器更新，第一计数器和第二计数器均为1。则当第一计数器等于1时，1的值映射至第一类型的依赖，第二计数器的值(等于1)映射至协议(具有其他四种需要预处理和后处理以及预存储和后存储的可选依赖)。通过哈希表等多种不同机制可以很容易获得所述数据。

所述管理实体可以针对第一计数器等于1以及第二计数器等于1的组合进行依赖分析(方框1215)。关于依赖分析的细节讨论如下：所述管理实体可以适当地修改模型元素图(方框1217)。如果第一计数器和第二计数器组合的依赖分析建议修改模型元素图，则所述管理实体可以根据需求改变所述模型元素图。

所述管理实体可以执行检查以确定是否有计数器需要改变(方框1219)。例如，如果所述管理实体已经完成针对第一计数器等于1和第二计数器等于1组合的依赖分析，则所述管理实体可以增加第二计数器(方框1223)。如果所述计数器需要改变，则所述管理实体可以调整计数器(方框1221)。所述管理实体也可以执行检查以确定是否完成了对依赖的依赖分析(方框1225)。如果所述管理实体已经完成对依赖的依赖分析，则所述管理实体可以重置第二计数器(方框1227)，如果所述管理实体没有完成对依赖的依赖分析，则所述管理实体可以返回方框1213对新的组合进行依赖分析。

所述管理实体可以执行检查以确定是否对所有依赖均进行依赖分析(方框1229)。如果没有对所有依赖均进行依赖分析，则所述管理实体可以更新第一计数器(方框1231)并且返回方框1213对新的组合进行依赖分析。如果已经对所有依赖进行依赖分析，则可以终止操作1200。

图13示出了管理实体对依赖和依赖类型的组合进行依赖分析时发生在所述管理实体中的操作1300的流程图。操作1300可以是管理实体对依赖和依赖类型的组合进行依赖分析时发生在所述管理实体如管理实体315、管理实体405以及管理实体505中的操作说明。操作1300可以是发生在进行依赖分析中的事件描述(方框1215)，并修改图12的模型元素图(方框1217)。

操作1300可以开始于管理实体将元组(例如元组800)映射到特定依赖(方框1305)。返回参考上述示例，在通过依赖分析环的第一时间，所述元组会是{数据类型，使用协议}。如讨论中使用，“数据类型”可以代表请求中请求的通用类型的数据(例如主动发送流量的路由器或交换机的数量，自从上一请求执行之后，增加的任意类型的新设备的数量等)。

所述管理实体可以分析元数据PoS令牌以及元数据PoS令牌与内容PoS令牌之间的关系，所述分析涉及检索数据和将数据标记为已处理等(方框1307)。可能存在大量不同的实现机制，包括检索存储的数据(所述存储可能是暂时性或永久性存储)或者将数据标记为已处理(如果后续需要所述数据)或者从存储中删除数据(如果不再需要所述数据)。

所述管理实体可以通过评估对模板的需求检查待处理数据的类型(方框1309)。由于不同的数据源可以利用不同的机制描述相同类型的数据(如SNMP MIB对XML，文件对面向对象的数据模型等)，所述管理对象可以通过定义规范不同机制的标准的但是可扩展的数据描述模板来检查数据类型，因此为了进行依赖分析，允许利用常见的属性集描述任意机制。这要求理解数据描述的格式和任意编码语义(例如编码成对象属性而不是区别为单独对象的任意元数据)的能力。这是由信息模型提供。通用型规范到应用特定实现的映射是由一个或者多个数据模型定义。因此，所述管理实体可以检索取决于方框1309中做出的决定的数据描述模板(标准模板(方框1311)或者特殊模板(方框1313))。

虽然基于图8示出的元组800的单一标准的数据描述模板可以定义和使用，但是所述管理实体可以将所述数据描述模板概述为模板集，为通用型依赖至实际数据的映射提供更好的灵活性。一般来说，数据描述模板的数量需要与依赖的最大数量相等(最大数量在本文讨论的示例中是6)。但是因为足够数量的差异，依赖和依赖类型的特定组合的元组可能要求特定的数据描述模板。方框1309至1313提供的逻辑为检索特定的数据描述模板的提供必要操作。

所述管理实体可以利用内容请求的数据填充数据描述模板(标准的或者特殊的)(方框1315)。如元组即(第一计数器和第二计数器)元组定义，所述数据可以是组成依赖类型的两个实体。可以分析所述元数据PoS令牌和所述内容PoS令牌以确定是否存在对应于所述元组的依赖(方框1317)。每组元组可以有不同的依赖。此外，所述依赖通常不是对称的，即数据可以以一种方式与协议相关联，但是所述协议可能以一种完全不同的方式与所述数据相关联。例如，如果用户需要进行特殊形式的搜索和匹配功能如soundex，协议可能不支持该功能，即使该协议设计用于在搜索系统中使用。在这个简单的示例中，soundex匹配对于大部分数据库管理系统是非常常见的并且被其协议支持，但是很显然soundex在用于目录服务器的标准协议(如LDAP)中并非受到直接支持。但是需要说明的是，LDAP确实可以进行近似匹配。但是不能保证所有的目录服务器可以支持这样的功能。数据类型也有类型情形。因此，依赖处理分析的目标是可以发现数据类型、协议、预处理和/或后处理计算公式以及预处理存储和/或后处理存储公式的要求有句法、语义和/或其他形式的依赖的问题。表1提供了经常发生的不同类型依赖的几个示例。

表1依赖处理的示例

所述管理实体可以生成依赖的序列表以保存搜索元数据PoS令牌和内容PoS令牌过程中发现的依赖(方框1319)。通常认为依赖的序列表中没有重复项。所述管理实体可以分析模型元素图的集合以确定对应于元组的依赖是否存在(方框1321)。所述管理实体可以生成依赖的序列表以保存搜索模型元素图集的过程中发现的依赖(方框1323)。如果在搜索模型元素图集的过程中没有发现依赖，则依赖的序列表可能是空表。再次，通常认为依赖的序列表中没有重复项。所述管理实体可以关联两类依赖的序列表并且优化所述序列表(方框1325)。两类依赖的序列表的关联和优化可以产生依赖的单独列表。然后可以终止操作1300。

图14提供设备1400的说明。设备1400可以是管理实体等的实现。设备1400可以用于实现本文所讨论的多个实施例。如图14所示，发送器1405用于发送报文、帧、请求和/或数据和命令的其他形式，接收器1410用于接收报文、帧、请求和/或数据的其他形式。在两种情况中，所述数据可以包括操作、行政、管理和/或性能数据和命令。发送器1405和接收器1410可以有无线接口、有线接口或者二者结合。

请求解析单元1420用于从设备1400的用户接收请求。请求解析单元1420用于解析所述请求，其可以包括确保所述请求的有效性，检测请求中的误差等。解析所述请求也可以包括词素和词汇预处理。所述词素和词汇预处理可以帮助简化后续解析操作。解析请求也可以包括产生词性(part of speech，PoS)令牌。模型生成单元1422用于生成模型元素。模型生成单元1422用于从解析后的请求中提取上下文令牌和内容令牌。模型生成单元1422用于将上下文令牌和内容令牌映射到所述模型元素。

XSD生成单元1424用于生成图形和/或XSD。图形和/或XSD的生成可以包括将由内容令牌到模型元素的映射过程产生的图形集合并为单个图形，并且后续对所述图形进行优化。所述优化的图形可以转换为XSD，其将查询结果描述成与平台无关的格式。XSD处理单元1426用于执行所述XSD。XSD处理单元1426用于执行XSD并且采集数据。结果处理单元1428用于将结果处理成可以显示给用户或者可以存储用于后续回顾的形式。结果处理单元1428用于组织和库存数据。

存储器1430用于存储信息模型、数据模型、元数据、PoS令牌、XSD、模型元素、请求、预处理、后处理、预存储、后存储、采集数据、转换、转换数据以及纲要等。存储器1430可以是物理存储器如磁盘驱动器、固态存储器或者二者集。存储器1430可以是设备1400的物理部分，也可以是远程设置或者是二者结合。存储器1430也可以包括虚拟化的物理存储器，从而使得多个物理存储元素视为能够基于需求分配的单个内存池。用户接口1435包括硬件和/或软件，以允许用户与设备1400交互。例如，用户接口1435包括显示器、键盘、触摸屏、声音识别系统、扬声器、鼠标以及定位笔等，使得用户与设备1400交互。

设备1400的元素可以作为特定的硬件逻辑块实现。可选地，设备1400的元素可以作为在处理器、控制器、应用特定的集成电路中执行的软件实现。在另一个可选项，通信设备1400的元素可以作为软件和/或硬件的组合实现。

例如，发送器1405和接收器1410可以作为特定的硬件块实现，而请求处理单元1420、模型生成单元1422、XSD生成单元1424、XSD处理单元1426、结果处理单元1428可以是处理器1415、微处理器、定制电路或者现场可编程逻辑阵列的定制编译逻辑阵列中执行的软件模块。需要说明的是，所述处理器1415、所述微处理器、所述定制电路以及所述定制编译逻辑阵列等可以在通过通信网络从本地发送到另一个或者分配耦合的多个处理单元配置中实现。请求处理单元1420、模型生成单元1422、XSD生成单元1424、XSD处理单元1426以及结果处理单元1428可以在存储器1430中存储为模块。

在一个示例实施例中，管理实体包括解析元素，为通信系统中的实体解析采集数据的请求，其中所述解析产生解析后的请求和与所述请求相关的依赖信息；模型元素，根据由所述解析后的请求派生出的上下文令牌和内容令牌生成模型元素集，其中所述内容令牌包括解析后的请求的外部元数据和内部元数据；描述元素，描述从模型元素集派生出的优化图形产生的所述请求的与平台无关的结果描述；执行元素，执行采集请求数据的请求；存储元素，存储采集数据。在部分实施例中，所述管理实体可以包括其他或者附加元素用于执行所述实施例中描述的任一或组合的步骤。

虽然已详细地描述了本发明及其优点，但是应理解，可以在不脱离如所附权利要求书所界定的本发明的精神和范围的情况下对本发明做出各种改变、替代和更改。