WO2010034237A1 - 模糊查询、查询结果处理和过滤条件处理的方法及设备 - Google Patents

模糊查询、查询结果处理和过滤条件处理的方法及设备 Download PDF

Info

Publication number
WO2010034237A1
WO2010034237A1 PCT/CN2009/074132 CN2009074132W WO2010034237A1 WO 2010034237 A1 WO2010034237 A1 WO 2010034237A1 CN 2009074132 W CN2009074132 W CN 2009074132W WO 2010034237 A1 WO2010034237 A1 WO 2010034237A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
filtering
filter
attribute
matching
Prior art date
Application number
PCT/CN2009/074132
Other languages
English (en)
French (fr)
Inventor
张彬
金丰鑫
李国辉
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2010034237A1 publication Critical patent/WO2010034237A1/zh
Priority to US13/073,667 priority Critical patent/US20110179047A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/02Capturing of monitoring data
    • H04L43/028Capturing of monitoring data by filtering
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/16Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using machine learning or artificial intelligence

Definitions

  • the present invention relates to the field of communications technologies, and in particular, to a method and a device for processing fuzzy query, query result processing, and filtering condition processing. Background technique
  • the Network Configuration Protocol is a network management protocol that uses Extensible Markup Language (XML) to describe operation requests and network management data.
  • XML is a set of rules for semantic markup that divides a document into many parts and identifies them with tags. These tags are usually in natural language and are therefore highly readable. The markup looks like this:
  • Each pair of labels has been composed of a starting label i ( ⁇ mouth ⁇ age> ) and an ending label i ( ⁇ mouth ⁇ /age> ), each pair of labels and their contents is called an element (element),
  • an element can have a value, such as ⁇ &36>, which has a value of 10; it can also have child elements, such as ⁇ 11&111 ⁇ 2> There can also be no value, :3 ⁇ 4.
  • ⁇ hobby> this case is called an empty element, and can be abbreviated as ⁇ hobby/>; an element can also have an attribute, and the attribute is a "name-value" pair, such as ⁇ 1 ⁇ 1!1 ⁇ 2> has attributes Language, the attribute value is English.
  • FIG. 1 is a schematic diagram of a tree data structure in the prior art.
  • Hierarchical nesting relationships between elements are often expressed as a tree data structure, as shown in FIG. 1, and thus elements are also referred to as nodes.
  • the outer node is called the parent of the inner node; the inner node is called the outer node.
  • Child node
  • ⁇ 0> is the parent of ⁇ 3 ⁇ 41>, ⁇ b2>, ⁇ b3>, and ⁇ bl>, ⁇ b2>, ⁇ b3> are child nodes of ⁇ a>.
  • sibling nodes such as ⁇ 3 ⁇ 41>, ⁇ b2>, and ⁇ b3> are sibling nodes.
  • the network management device sends a query message to describe the data that needs to be queried. After the managed device receives the query message, it depends on the conditions in the query message. Execute the query and answer the query result to the network management device.
  • the NETCONF protocol has two kinds of query operations: ⁇ get> ⁇ get-config> 0 Although the query objects of the two are different, they have the same expression expression, that is, subtree filtering and XML path language (XML Path Language, Hereinafter referred to as: Xpath).
  • subtree filtering uses XML to describe the filtering conditions, and selects the qualified data elements through a set of simple matching rules.
  • Example 1 is an example of a subtree query.
  • the ⁇ rpc> element indicates that this is a request from a network management device.
  • the ⁇ ⁇ 6 1> element indicates that the network management device requests to perform a query operation, and the ⁇ filter> element indicates the query mode and query conditions.
  • the subnodes contained in ⁇ filter> indicate: The query wants to query the namespace "http: ⁇ example.eom/schema/l.2/stats" ⁇ 1;( ⁇ interfaces> in the ⁇ > element is an ⁇ interface> L element, and the ⁇ interface> L element must have an if ame attribute, and the attribute value of ifName is "ethO".
  • Example 1 A ⁇ get>"3 ⁇ 4" query using a subtree query:
  • the ⁇ filter> element is called a filter.
  • the filter In subtree filtering, the filter consists of zero or more sub-trees that select standard elements.
  • the managed device makes a logical judgment on each set of sibling nodes to determine whether the subtrees led by each sibling node are included in the output of the filter. All elements that appear in the filter subtree must match the corresponding nodes in the server's conceptual data model.
  • Filters can be divided into five components, each of which performs different filtering rules, including: Namespace Selection, Attribute Matching Expressions, Include Nodes, Select Nodes, Content Matching Nodes.
  • Namespace selection If you use a namespace, the output of the filter contains only the elements in the specified namespace. That is: the contents of the "xmlns" attribute in the filter should be the same as the "xmlns" attribute in the managed device data model.
  • ⁇ t:top xmlns:t htt : ⁇ example.com/schema/1.2/stats”> ⁇
  • the selected namespace is htt : //example . com/schema/ 1.2/stats, only The child elements in ⁇ top> in this namespace are output.
  • Example 2 Query results for attribute matching:
  • a node in a filter that contains child elements is called an inclusion node.
  • a child element that contains a node can also be a containing node, or another type of node.
  • ⁇ top> is an inclusive node whose child elements ⁇ 111 &068> are also a containing node.
  • Select Node An empty node in the filter is called a Select Node and represents an explicit selection of the data model. If a selection node appears in the sibling node of the data model, only the subtree under the selection node is selected, and the sibling node of the selection node is not selected. As in Example 3, the ⁇ 3 ⁇ 4&1!16> element is a selection node. In the data model of the managed device, if ⁇ user> has ⁇ child> and other child nodes, then only ⁇ 1 ⁇ 111 ⁇ 2> is selected, and the ⁇ 11&111 ⁇ 2> siblings will not be selected.
  • a leaf node containing a text value is called a content matching node and represents a selection condition for the parent node.
  • the ⁇ 3 ⁇ 4&1116> element is a content matching node, indicating all ⁇ 1 ⁇ 1!16>
  • the ⁇ 1 ⁇ 1"> element (and its child elements) that is "fred” will be selected for output.
  • the result of the filter query is shown in Example 5.
  • Example 4 Content matching nodes in the filter:
  • the output of the filter starts to be empty.
  • the managed device compares the data model it supports with each data branch in the filter. If all the branches of the subtree represented by a node and the corresponding part of the data model of the managed device are completely matched, Then the node and all its children are included in the result data.
  • Subtree filtering requires more known conditions, such as node name, node value, attribute name, attribute value, namespace, etc. on the tree, which has higher memory requirements for network administrators.
  • the matching mode is single and can only be matched exactly. Otherwise, it is considered that there is no node in the data model that meets the filtering conditions. It is not possible to logically combine multiple query conditions (and, or, not), nor to filter the range of values and time data (greater than, less than).
  • XPath is the XML path language, which is the W3C general language standard for querying XML documents.
  • XPath is a way to represent XML document query conditions in the form of file paths.
  • the subtree filtering in Example 4 is expressed in XPath as shown in Example 6.
  • the XPath mechanism is more complicated and difficult to master. And XPath is expressed in a non-XML way. As mentioned, additional mechanisms are needed for parsing and processing.
  • XPath uses a path expression to select a node or a node set in an XML document. Only one query record can be obtained at a time. This makes it impossible for a user to query multiple results at a time, and the query efficiency is relatively low.
  • the subtree filtering in the prior art 1 is based on exact matching and absolute path, requires the user to provide more known conditions, and lacks statistics on the filtering result. And the processing mechanism; and the XPath mechanism in the prior art 2 is more complicated and difficult to grasp. Summary of the invention
  • the embodiment of the invention provides a method and a device for processing fuzzy query, query result processing and filtering condition, so as to solve the NETCONF protocol, the subtree filtering mechanism is limited to exact matching and absolute path, and the data query requires more known.
  • the inconvenience caused by the information solve the problem of lack of query, filtering and processing means in the NETCONF protocol data model query; enrich the query and filtering means of the subtree filtering mechanism, improve the flexibility and functionality of subtree filtering;
  • the XML filtering result document obtained by the subtree filtering reduces the processing and transmission of redundant information; and corrects the unreasonable filtering message processing method of the subtree filtering part in the NETCONF protocol.
  • An embodiment of the present invention provides a fuzzy query method based on subtree filtering, including: receiving a data stream to be filtered;
  • the embodiment of the present invention further provides an extended method for logical combination of a seed tree filtering condition, including: receiving a data stream to be filtered;
  • the element type nodes in the data stream are filtered using a plurality of attributes or a plurality of content matching nodes.
  • the embodiment of the present invention further provides a method for processing a seed tree filtering query result, including: setting a value of a third attribute at a corresponding node in the filter, indicating whether the node descendant is displayed at the node;
  • the third attribute is a first value or a second value.
  • the third attribute defaults to displaying all descendants in the same namespace, the third attribute is equal to the second value; when the third attribute is equal to the first If a value is used, the filtering result only outputs the information of the node, and does not output the descendant node in the same namespace.
  • the embodiment of the invention further provides a filter, comprising:
  • a receiving module configured to receive a data stream to be filtered
  • a filtering module is configured to filter the data flow by means of incomplete matching, and process a filtering condition in a string form that does not give complete information to the user.
  • the embodiment of the invention further provides a logic filtering device, including:
  • a receiving module configured to receive a data stream to be filtered
  • a logic filtering module is configured to filter element type nodes in the data stream by using multiple attributes or multiple content matching nodes.
  • the embodiment of the present invention further provides a seed tree filtering query result processing apparatus, including: a setting module, configured to set a value of a third attribute at a corresponding node in the filter;
  • a determining module configured to set a value of the third attribute according to the setting module, to indicate whether a node descendant is displayed at the node.
  • a NETCONF subtree filtering mechanism which is expressed in XML form, and the XML network management data is queried and filtered, so that the management information in the NETCONF protocol is more convenient to be obtained, and the data is also avoided.
  • Query and filtering redefine many of the issues that come with a set of specifications.
  • Embodiments of the present invention provide a refinement and combination mechanism for filtering conditions of XML data.
  • a node in an XML document sometimes contains specific data information, similar to a field in a relational database; sometimes it is just a means of encapsulating data information, similar to a record in a relational database.
  • the matching degree of the node is refined, and the user can select a corresponding query method according to the specific role of the node in the data storage.
  • the filter conditions expressed by attributes and namespaces can be combined logically to make the query more flexible.
  • the embodiment of the invention provides a node or attribute name that cannot completely spell out the data storage in the case that the filtering condition is incomplete, or can not completely give the data definition in the XML document.
  • the location you can still subtree filtering the XML data, and get the results the user wants.
  • the embodiment of the invention increases the query function of the namespace in the subtree filtering, and helps the user to quickly understand the structure of the data distribution in the XML document; the NETCONF protocol subtree filtering must provide the namespace condition, but does not provide a complete means to achieve Defects in namespace queries.
  • Embodiments of the present invention address special query requirements for certain data, such as range queries for time, date, quantity, etc., quantity queries for data, and the like.
  • Subtree filtering is more suitable for real network management or other practical applications.
  • the embodiment of the present invention implements optimization of filtering results, and implements merging or sorting of the same or similar data; discarding useless descendant nodes when needed, and greatly reducing a large amount of redundant information that may exist in the subtree filtering result.
  • FIG. 1 is a schematic diagram of a tree data structure in the prior art
  • FIG. 2 is a structural diagram of a subtree filtering system in the NETCONF protocol according to an embodiment of the present invention
  • FIG. 3 is a general flowchart of an embodiment of the present invention
  • FIG. 5 is a flowchart of a filter control call name space processing component in an embodiment of the present invention
  • FIG. 6 is a flow chart of recursive flow control in an embodiment of the present invention
  • FIG. 8 is a flowchart of a fuzzy query method based on subtree filtering according to Embodiment 2 of the present invention
  • FIG. 9 is a flowchart of a method for expanding logical combination of subtree filtering conditions according to Embodiment 3 of the present invention
  • FIG. 10 is a fourth embodiment of the present invention
  • FIG. 11 is a schematic structural diagram of a filter according to Embodiment 5 of the present invention.
  • FIG. 12 is a schematic structural diagram of a logic filtering apparatus according to Embodiment 6 of the present invention
  • FIG. FIG. 13 is a schematic structural diagram of a subtree filtering query result processing apparatus according to Embodiment 7 of the present invention. detailed description
  • the embodiment of the present invention provides a method for defining a data query and data filtering function of a network management information model defined by the XML language based on the NETCONF protocol and extending the subtree filtering mechanism in the NETCONF protocol.
  • the definition method includes a detailed description of the subtree filtering function and a keyword definition related to the function definition.
  • the value of the type attribute of the node is added to the type attribute of the node.
  • the advancedSubtree is added to indicate that the request may be performed by the subtree filtering mechanism.
  • the subtree filtering extension mechanism mainly includes the following functions:
  • Fuzzy matching means that in the filtering process, in the string matching of the node name, node content, attribute name, attribute value, and namespace, the string in which the user does not give the complete query information is processed in an incomplete matching manner.
  • Example 7 Example 8: Filtering the ⁇ 11 ⁇ &#6> node with a certain attribute value of Ethernet1 under the ⁇ 1"01 ⁇ 1 ⁇ > node. For example, Example 7 uses the wildcard "-" to match any value. The attribute of "Ethernetl", the attribute and the attribute corresponding to the attribute value Ethernetl are found in the filter, and the node where the attribute is located, The attribute name and attribute value are output, and the filtering result is as shown in Example 8.
  • ⁇ /filter> A fuzzy query with a node name and value is similar.
  • the value of ⁇ name> and the query of ⁇ name> itself can be as follows:
  • fuzzy filtering of incomplete content matching of node values, attribute values, and namespace contents can be implemented.
  • Such query conditions are as follows:
  • Protocol subtree filtering uses absolute path matching: that is, the root node of the filter and the descendant nodes of each level must be identical to those in the data model.
  • a relative path matching mechanism is added, that is, the nodes in the filter only maintain the same ancestor-descendant relationship as in the data model, but do not strictly maintain the same parent-child relationship in the data model.
  • nodes A and B in the data model are grandparents, but the two in the filter are parent-child relationships.
  • the parent nodes of B are different in the data model and filter, the ancestor-descendence relationship between A and B is in both. The same is true.
  • the present invention defines an attribute _110 ( ⁇ & for the ⁇ 1 1"> node, which has two values:
  • Absolute indicating that all nodes in the filter are filtered by absolute path, that is, the parent-child relationship between each node in the filter must be strictly consistent with the parent-child relationship in the data model. Is the default value for this property;
  • Relative indicates that relative path filtering is used, that is, nodes with parent-child relationships in the filter satisfy the ancestor-descendant relationship in the data model.
  • Example 10 Relative path filtering:
  • the invention expresses the matching degree of the node by adding the attribute _11 ⁇ (;11 hex 6) in each content matching node, and indirectly realizes the logical relationship combination between the node filtering conditions indirectly.
  • the attribute _11 ⁇ (:11 ⁇ 6 has three values:
  • Example 12 Query the ⁇ interface> element, the ⁇ interface> element should satisfy ⁇ name> as Ethernet 1, JL ⁇ received> 49 0
  • the ⁇ 1 ⁇ &06> node can be output.
  • Example 13 Implementation of an OR relationship between content matching nodes:
  • the logical relationship between multiple attributes of a node can be represented by adding the attribute _&1 ⁇ 0 ⁇ to the node.
  • the logical relationship between namespaces can be represented by adding the attribute_1 ⁇ 1 ⁇ (3 ⁇ 4.
  • the attribute _& « (the value of 3 ⁇ 4 is a logical expression.
  • the following logical operators can be used in logical expressions:
  • the logical expression of the attribute _nsLogic can only be used with a logical "or" operation.
  • Objects that participate in logical operations in logical expressions are property names or namespace prefixes.
  • the query name attribute value is not "Ethernet 1"
  • the ip-address attribute value is "59.64.139.69” ⁇ 0 ⁇ &06> node.
  • the query condition is expressed as follows:
  • Namespace logical relationship usage is similar to that of an attribute, except that only the "or" operation can be used, as shown in Example 15.
  • Namespace query can get a definition of the namespace in the data model and give a list of namespaces.
  • the keyword of the namespace query is the label element ⁇ _xmlns>.
  • ⁇ _xmlns> When the child node of the filter ⁇ 6 ⁇ 1"> is ⁇ _ 1111118>, it means that the data model is named namespace related query; ⁇ _xmlns> owns the attribute plf,
  • the attribute value is the prefix of the namespace in the XML document. If the namespace is the default namespace (ie, no prefix), the prf attribute is not output.
  • Example 16 shows the filter definitions and filtering results for all namespaces in the query data model.
  • Example 17 Filtering results in Example 16:
  • the above example 16 informs the filter via the keyword element ⁇ _ 1111113> to query all namespaces present in the data model.
  • the result of the filtering returns all the namespaces in the data model in the form ⁇ _ xm l ns > urn:ietf:params:xml:ns:netconf:base: 1.0 ⁇ /_xmlns>.
  • Example 18 Query the namespace of some elements:
  • ⁇ _xmlns pri if '> urn:bupt:pris:priser:agent:module:interface: 1.0 ⁇ /_xmlns>
  • the filter ⁇ filter> tells the filter to query the data model by setting the child node ⁇ _ 1111113> The namespace, by setting the node " ⁇ . ! ⁇ ! ⁇ ! ⁇ > ! ⁇ ! ⁇ Informs the filter that the subquery/netconf/routing namespace is specifically queried, so only ⁇ 11 ⁇ 21 ⁇ 01 1 and ⁇ 3 ⁇ 4 in the data model are returned in the filter result. ) 111; 0 ⁇ > node namespace "urn: bupt: pris: priser: agent: module: interface: 1.0".
  • the attribute _show can be set at the corresponding node in the filter to indicate whether to output the node descendant.
  • the attribute has the following two values:
  • the filtering result only outputs the information of the node itself, and does not output its descendant nodes.
  • the filtered result outputs the node and all its descendant nodes, which are attribute default values.
  • Example 19, Example 20, Example 21, and Example 22 show how to filter out the complete information and partial information of the specified node.
  • Example 20 Filtering results in Example 19:
  • Example 21 Output only the information of the node itself:
  • Example 22 Filtering results in Example 21:
  • the number query function can count the number of elements of a certain type in the data model, that is, the number of elements corresponding to the same filter node. This is done by using the _count attribute in an element type node in the filter. The value of this attribute has true and false. When the value of the -count attribute is set to "true”, the number of query entities is output by the filtering result; when the _count attribute is set to "false", the filtering result is not lost. The number of query entities, "false” is the default value of the property _coimt. If the number of the query entities is returned, the label element ⁇ _countNum> is added to the corresponding entity element type node in the filtering result, and the text value of the element identifies the number of the query entity.
  • Example 23 and Example 24 show how to query the child node of the ⁇ monitor> node.
  • the number of 0111 81 ⁇ 311011>, filter and filter results are as follows:
  • Example 23 Query the number of specified nodes:
  • Example 24 Filtering results in Example 23:
  • the present invention adds an attribute indicating a range to a selection node indicating the number or time, thereby
  • the selection node is regarded as a content matching node indicating a time or a range of numbers, and thus is used as a filtering condition in filtering processing.
  • Jessthan indicating that the value of the selected node where the attribute is located is less than the value of the attribute
  • _notmorethan indicates that the value of the selected node where the attribute is located is not greater than the value of the attribute; _notlessthan, indicating that the value of the selected node where the attribute is located is greater than the value of the attribute.
  • the attribute keywords that represent the time range are:
  • Jimebefore indicating that the time value of the selected node where the attribute is located is ahead of the value of the attribute;
  • Jimeafter indicating that the time value of the selected node where the attribute is located lags behind the value of the attribute;
  • Jimenotbefore indicating the time value of the selected node where the attribute is located Equal to or behind the value of the attribute;
  • Jimenotafter indicates that the time value of the selected node where the attribute is located is equal to or ahead of the value of the attribute.
  • Example 26 shows the results of this query.
  • Example 26 Filtering results in Example 25:
  • the filtering results obtained by the same filter node are sorted as needed.
  • the nodes in the query result are identical in the ascending or descending order according to the content of a certain node.
  • Sorting is done by setting the attributes _ascOrder and _( ⁇ 0 ⁇ ( ⁇ ) at the root node of the subtree to be sorted.
  • the attribute _ascOrder indicates ascending order according to a node or attribute
  • the attribute _descOrder indicates descending according to a node or attribute.
  • the value of these two attributes is the node name or attribute name of the sorting.
  • the identifier is an attribute name.
  • the node value is the index by which the order is sorted.
  • node names and attribute names are connected by " ⁇ ", and the previous nodes and attribute names have higher priority than the following nodes and attribute names.
  • Example 27 shows the results of the sorting.
  • Example 27 Output elements in descending order of the specified node value:
  • Example 28 The filtering results for Example 27 are as follows:
  • the genre 3 ⁇ 4_merge can be set at the root node of the subtree to achieve the merging of the same subtree.
  • the value of this property is: true or false.
  • the default value of attribute_merge is, false" .
  • Example 29 The merged filter is not used:
  • the user actually only wants to know if the interface node exists in the data model and does not care about the other. If you use the _merge attribute, the ⁇ &06> node is modified to:
  • node In the same ⁇ &06> node (or subtree), only one is compressed, which may avoid the disadvantage of a large amount of redundant information being transmitted in the management network when there are a large number of nodes with the same name in the data model.
  • the node's logical matchType may be an "or" point to extend the new attribute
  • the node that is filtered out For the execution of the attribute, the node that is filtered out, the logical expression between the attributes, the logical operation
  • the filtered node extension attrLogic's properties should satisfy the set of relationship operators including: ⁇ ,
  • Namespaces for element type sections should be logical expressions
  • the query point is a subtree namespace
  • New attribute descendant node itself and its descendants Attribute default value Query the number of nodes of a node that meets the filter bar true.
  • Point extension new attribute Query the number of inner queries of a node that satisfies the filter strip false
  • the default value of the attribute is ⁇ ( ⁇ &> element's number of nodes for the query response, which is a positive child element, carrying the horse
  • node value is greater than
  • a numeric value node value is less than a numeric data class lessthan value
  • Filter value node value is less than new attribute notmorethan value
  • the value of the node is greater than the notlessthan value
  • the node with " ⁇ >, indicates that the keyword exists as an element; without " ⁇ >, and only with "_,” indicates that the keyword exists as an attribute; neither Indicates that the keyword exists as an attribute value or a node value.
  • the present invention modifies the following processing scenarios in the NETCONF protocol subtree filtering mechanism:
  • Example 32 Query for a node that does not match:
  • the interface node Since there is no matching interface node in the data model, the interface node is not output, but its ancestor routing and netconf. are returned. For the user, the meaning of the filtering results is not clear, and it also brings useless redundant information.
  • Example 35 Namespace filtering results in the NETCONF protocol:
  • the child node when the namespace of the node does not match, the child node continues to be processed because there may be a descendant matching the given namespace.
  • the hierarchical relationship of the filtering results is still valid, it is also possible to keep the elements whose namespaces do not match as the paths of other nodes. Users can clearly distinguish these elements with other namespaces from the filtering results.
  • Example 36 Example 34 The filtering results obtained in the subtree filtering function extension are as follows:
  • the embodiment of the present invention provides a processing system for implementing data query and data filtering functions of a network management information model defined by the XML language based on the extension of the subtree filtering mechanism in the NETCONF protocol.
  • the processing system details the specific structure of each module in the overall structure and structure of the system implementation.
  • the main architecture of the extended NETCONF subtree filtering system includes a filtering control module, a packet setting module, and a namespace processing. Modules, relative path access modules, recursive process control modules, node function processing modules, and result processing modules.
  • the filtering control module 2010 is the core of the entire subtree filtering part, and provides a control mechanism for the entire subtree filtering process.
  • the protocol subtree filtering and XPath filtering operations can be performed according to the parameters in the packet.
  • the module parses the relevant part in the rpc packet, and calls other modules to complete the corresponding functions according to the specific content of the packet. After the corresponding module function is processed, the processing result needs to be reported to the packet and the filtering control module 2010 determines how to proceed to the next step. Operation. After obtaining the initial filtering result, if there is a request for processing the filtering result in the message, the module calls the result processing module 2070 to process the initial filtering result, obtain the final filtering result, and return.
  • the rpc packet includes the filtering information required by the filtering control module 2010, and the filtering control module 2010 first determines the correctness of the rpc packet. If it is correct, the specific parameter is set according to the packet information, including the filtering type ( Subtree filtering, extended subtree filtering, XPath) and whether relative path matching is required in extended subtree filtering. The result is returned to the Filter Control Module 2010.
  • the filtering type Subtree filtering, extended subtree filtering, XPath
  • the namespace processing module 2030 is configured to process an operation request related to the namespace query, for example, querying a namespace of all nodes in the configuration document, querying a namespace of all nodes in a subtree, etc., in the implementation, a recursive flow control module 2050 and The result processing module 2070 is supported. 4. Relative path access module 2040
  • the relative path access module 2040 is configured to filter the configuration document when the relative path of the node is given in the rpc message. Therefore, it is avoided that the full path of the node must be given under the conditions of the protocol, and filtering can be performed without giving the full path of the node.
  • the main function is to find the appropriate configuration document node as a parameter for the recursive flow control module 2050.
  • the configuration document is divided from the top layer to the bottom layer, and a group of sibling nodes in the filter are processed at one time, and are divided into a container node, a selection node, and a content matching node for related processing; whenever a node is added to the filtering result, the node function is processed. .
  • the node function processing module 2060 includes: a fuzzy matching module 2061, a node number query module 2062, a value range query module 2063, a time range query module 2064, and a logical relationship combining module 2065, which are used to filter nodes and The judgment of the nodes in the data model is compared, and the judgment result is given.
  • the result processing module 2070 is configured to operate on the filtering result, and specifically includes a message encapsulating module 2071, a node sorting module 2072, and a node merging module 2073.
  • the result processing module 2070 needs to encapsulate the filtering result and encapsulate all the namespaces into an xml format.
  • the result processing part processes the initial result according to the sorted keyword, and obtains the sorted result and submits it to the filtering control module 2010. Node merging is used to merge the same subtrees in the initial filtered results.
  • the embodiment of the present invention provides a method for processing data query and data filtering function based on the network management information model defined by the XML language based on the extension of the subtree filtering mechanism in the NETCONF protocol.
  • the processing method includes an overall process of the extended NETCONF subtree filtering implementation and a detailed flowchart of the specific module.
  • FIG. 3 is a general flow chart of an embodiment of the present invention, which mainly includes packet error detection, setting a running parameter according to a keyword, and then filtering the data model locally saved by the filter to the device, and encountering a node call.
  • the node processing module after all the nodes have finished processing, do the filtering result Further processing includes the following steps:
  • Step 3020 Parse the rpc packet.
  • Step 3030 determining whether the rpc packet setting is correct, if yes, proceeding to step 3050, if not, proceeding to step 3040;
  • Step 3040 error reporting, step 3110;
  • step 3050 the keyword is determined to determine whether it is namespace filtering or cross-layer access. If it is namespace filtering, go to step 3060. If it is cross-level access, go to step 3070; Step 3060, call namespace filtering, and then Step 3080;
  • Step 3070 call cross-level filtering, and go to step 3080;
  • Step 3080 calling recursive flow control
  • Step 3090 calling node function processing
  • Step 3100 Process the filtering result according to the keyword
  • the filter control module is the manager of the entire subtree filtering process. It calls other components to complete the work and receives the results of other component work to determine the next work.
  • FIG. 4 is a flowchart of the operation of the filtering control module in the embodiment of the present invention. As shown in FIG. 4, the method includes the following steps:
  • Step 4010 calling the message setting module in FIG. 2;
  • step 4020 it is determined whether to use the extended subtree filtering. If yes, go to step 4030. If no, determine whether the query object type is configuration data in different configuration data storage. If yes, execute step 4021 to use XPath filtering. If not, Then, step 4022 is performed to determine whether the query object type is the currently running configuration and status data, and if so, the protocol subtree is used for filtering;
  • Step 4030 determining the correctness of the packet according to the rpc packet, if yes, proceeding to step 4060, otherwise proceeding to step 4100;
  • Step 4060 performing a namespace query, if found, proceed to step 4070, otherwise, go to step 4072;
  • Step 4070 call the namespace processing module, go to step 4080;
  • Step 4072 according to the keyword to determine whether to use cross-level filtering, if yes, then go to step 4075, otherwise go to step 4080;
  • Step 4075 call the cross-level filtering module, and go to step 4080;
  • Step 4080 the recursive process control module is invoked, and the subtree filtering is started, and the process proceeds to step 4090; Step 4090, the filtering result is processed, and the process proceeds to step 4100;
  • Step 4100 Return the operation result encapsulation message to the related operation.
  • FIG. 5 is a flowchart of a filter-control call namespace processing component according to an embodiment of the present invention. As shown in FIG. 5, the method includes the following steps:
  • Step 5001 obtaining a child node of the ⁇ _1 ⁇ 11 ⁇ 2> element in the message definition
  • Step 5010 it is determined whether ⁇ _] ⁇ 118> has no child nodes, and if yes, go to step 5020, otherwise go to step 5030;
  • Step 5020 the configuration document as a whole filter initial result, go to step 5040;
  • Step 5030 performing subtree filtering recursion
  • Step 5040 obtaining a namespace insertion set of the node
  • step 5050 it is determined whether all nodes have been acquired. If yes, go to step 5060; otherwise, go to step 5030.
  • Step 5060 The encapsulated content is returned to the filter control module.
  • FIG. 6 is a flowchart of the recursive flow control in the embodiment of the present invention. As shown in FIG. 6, the method includes the following steps:
  • Step 6001 parsing the message to set an operation parameter of the node
  • Step 6010 the node determines whether the information of the own match, if yes, go to step 6020, if not, go to step 6015; wherein the information of the node itself includes the node type, the node name, the node attribute, the node name space, etc., the node attribute And the node name space may have multiple logical relationships; Step 6015, the node determines whether there is a relative path, if yes, then go to step 6017; Step 6017, looking for a suitable node on the relative path, step 6090;
  • Step 6020 The node determines whether the content matching node matches, if yes, go to step 6030, otherwise, go to step 6100; wherein the content matching node includes a node having a text value and a node having other conditions such as a data range, and possibly There will be multiple logical relationships, and there may be extended query clauses;
  • Step 6030 creating a current node copy that meets the requirements, proceeds to step 6040;
  • Step 6040 adding a content matching node to the filtering result, and proceeding to step 6050;
  • step 6050 the selection node is processed, and the node including the node and the child node in the filter without the child node are built-in keywords such as ⁇ _111 «>. If the selected node is set to not display its descendants, only copy itself; if it is set to not display the ancestor, copy the selected node to the result root node; Go to step 6060
  • Step 6060 Obtain a container node list.
  • Step 6070 determining whether the container node and the selection node are both empty, if yes, proceed to step 6080, otherwise, go to step 6090;
  • Step 6080 copy other nodes to the current node copy, go to step 6100;
  • Step 6090 recursively call the processing container node, go to step 6100;
  • Step 6100 Exit the current process and return to the previous level of recursion; the returned result includes the current node and its descendants that meet the filtering condition, and also includes the part that must be retained due to the reservation of other nodes, which does not meet the filtering condition, and does not include the user. Say no meaningful nodes.
  • the node function processing module accepts calls from recursive flow control to implement processing functions for a single node.
  • the node function processing module starts from a node in the filter definition, retains the node in the configuration document that meets the filtering condition represented by the node, and performs some processing on the reserved configuration file node according to the requirements of the representation.
  • the functions of the node function processing module include: matching of nodes, selecting nodes whose text content is a specific value, selecting a text content as a node at a specific time, querying the number of child nodes, attributes and namespaces, or non-logical operations, searching and A configuration document node with a similar node but a path that is not complete.
  • the node function processing module accepts the parameters passed by the recursive control part, performs corresponding processing, and returns the processing result to the recursive control module.
  • the main implementation methods are as follows:
  • the text content can be converted into a numerical type. If yes, it is determined whether the numerical value is within the specified numerical range, and the numerical range judgment includes four parts: greater than, less than, no greater than, and not less than.
  • the text content can be converted into data indicating time. If yes, it is determined whether the data is within the specified time range, and the time range judgment includes four parts: earlier than, later than, no earlier than and no later than specified. time.
  • the node is searched in the descendant of the current node and matched with the current node for use by the relative path function module.
  • the result processing module implements the following functions:
  • Packet encapsulation is mainly to encapsulate the filtering result into the appropriate packet format and send it back to the filtering control according to the parameters set in the filtering control.
  • FIG. 7 is a flowchart of a result processing implementation in an embodiment of the present invention. As shown in FIG. 7, the basic process of the result processing includes the following steps:
  • Step 7010 determining whether the filter is empty, and if yes, proceeding to step 7020;
  • Step 7020 copying the entire configuration file.
  • Step 7030 determining whether to perform a namespace query, if yes, proceeding to step 7040; Step 7040, retrieving the namespace and the prefix;
  • Step 7050 performing node sorting or performing node merging
  • Step 7060 the encapsulated message is returned.
  • Embodiment 1 of the present invention is a diagrammatic representation of Embodiment 1 of the present invention.
  • Example 38 Example filter definition:
  • the get/get-config operation finds that the operation message contains a filter node, it is handed over to the filter control module in Figure 2.
  • the message check was performed before the operation started, and no syntax error was found.
  • Urn:bupt:pris:priser:agent:module:interface: 1.0 contains an interface string that matches.
  • the filtered result is:
  • Process Filter The child node configuration of the monitor node. There are two configuration elements in the data model: urn:bupt:pris:priser:agent:module:monitor: 1.0 , urn:bupt:pris:priser:agent:module:interface: 1.0 , or mt represents ⁇ monitor: 1.0, either conforms to the interface* represented by if, and the four parent configuration nodes in the data model match.
  • the filtered result is:
  • the text content is not, in ascending order. Then the monitor is changed to:
  • the sorted filtering result is given to the control module and returned to the superior operation.
  • Example 39 Filtering results in Example 38:
  • FIG. 8 is a flowchart of a fuzzy query method based on subtree filtering according to Embodiment 2 of the present invention. As shown in FIG. 8, the method includes:
  • Step s801 receiving a data stream to be filtered;
  • the data stream is filtered by means of incomplete matching, and the filtering condition in the form of a string in which the user does not give complete information is processed.
  • the string includes: a node name, a node content, an attribute name, an attribute value, or a namespace; the manner of incomplete matching includes: the path is incomplete; the element name is incomplete, the element value is incomplete, the attribute name is incomplete, and the attribute The value is incomplete and the namespace is incomplete.
  • the data flow through the absolute path is specifically as follows:
  • the filter given by the user contains all the ancestors of the selected node that must be given from the root node.
  • the ancestors included in the filter and the ancestors in the data model are completely filtered. Consistent nodes and node descendants;
  • the data flow filtered by the relative path is specifically:
  • the node that satisfies the parent-child relationship in the filter satisfies at least the ancestor relationship in the filtering result; the node that is the root node in the filter includes at least the non-root node in the filtering result.
  • the child nodes of the aforementioned node are processed, and the elements whose matching space does not match are reserved as the path of the descendant node.
  • the embodiment of the invention increases the query function of the namespace in the subtree filtering, helps the user to quickly understand the structure of the data distribution in the XML document, and makes up for the naming space condition in the NETCONF protocol subtree filtering, but does not provide a complete means to implement the naming Defects in spatial queries.
  • Embodiments of the present invention address special query requirements for certain data, such as range queries for time, date, quantity, etc., quantity queries for data, and the like.
  • Subtree filtering is more suitable for real network management or other practical applications.
  • the embodiment of the present invention implements optimization of filtering results, and implements merging or sorting of the same or similar data; discarding useless descendant nodes when needed, and greatly reducing a large amount of redundant information that may exist in the subtree filtering result.
  • FIG. 9 is a flowchart of a method for expanding a logical combination of subtree filtering conditions according to Embodiment 3 of the present invention. As shown in FIG. 9, the method includes:
  • Step s901 receiving a data stream to be filtered
  • Step s902 using multiple attributes or multiple content matching nodes to the element type in the data stream
  • the node filters.
  • Step s902 The content matching node filters the element type node in the data stream, which is:
  • a content matching node as a filtering condition for selecting a specific parent node from the data model; indicating a matching degree of the node by adding a first attribute in the content matching node, the matching degree includes a matching match, an optional match, and a mismatch ;
  • the element type nodes in the data stream are filtered according to the content matching node and the matching degree.
  • Filtering element type nodes in the data stream according to the content matching node and the matching degree specifically:
  • the parent node can be added to the filtering result
  • the optional matching degree in the filter is an optional matching.
  • the parent node can be added to the filtering result;
  • a logical relationship between a plurality of attributes of the node may be embodied by adding a second attribute to the node, the second attribute being an _attrLogic attribute.
  • the process of filtering the element type nodes in the data stream by the foregoing multiple content matching nodes includes: performing a namespace query, and performing a namespace query specifically:
  • the filter condition further includes a range condition, where the range condition is used to select a node having a certain value or a date range, in indicating the quantity or time An attribute indicating a range of attributes or a time range is added to the selection node, and the selected node is regarded as a content matching node indicating a time or a range of numbers, and is used as a filtering condition in filtering processing.
  • the embodiment of the invention increases the query function of the namespace in the subtree filtering, and helps the user to quickly understand the structure of the data distribution in the XML document; the NETCONF protocol subtree filtering must provide the namespace condition, but does not provide a complete means to achieve Defects in namespace queries.
  • Embodiments of the present invention address special query requirements for certain data, such as range queries for time, date, quantity, etc., quantity queries for data, and the like.
  • Subtree filtering is more suitable for real network management or other practical applications.
  • the embodiment of the present invention implements optimization of filtering results, and implements merging or sorting of the same or similar data; discarding useless descendant nodes when needed, and greatly reducing a large amount of redundant information that may exist in the subtree filtering result.
  • FIG. 10 is a flowchart of a method for processing a subtree filtering query result according to Embodiment 4 of the present invention. As shown in FIG. 10, the method includes:
  • Step slOOl setting a value of the third attribute at the corresponding node in the filter, indicating whether the node is a descendant of the node, and the third attribute is a _show attribute;
  • Step sl002 the value of the third attribute is: a first value or a second value, the first value is a self value, and the second value is a descendant value, and when the third attribute defaults to displaying all descendants in the same namespace, Then the third attribute is equal to the second value; when the third attribute is set equal to the first value, the filtering result only outputs the information of the node, and does not output the descendant node in the same namespace.
  • the processing method further includes:
  • the number of elements of a certain type in the statistical data model is realized by using the fourth attribute in an element type node in the filter. Count the number of elements corresponding to the same filter node.
  • the fourth attribute is the _count attribute.
  • the fourth attribute has two values: a first value or a second value, the first value is true, and the second value is false.
  • the filtering result is outputting the query entity.
  • the filtering result does not output the number of query entities.
  • the processing method further includes:
  • the filtering results obtained by the same filter node are sorted as needed, and the nodes with the same content in the query result are combined.
  • the processing method further includes:
  • the embodiment of the invention increases the query function of the namespace in the subtree filtering, and helps the user to quickly understand the structure of the data distribution in the XML document; the NETCONF protocol subtree filtering must provide the namespace condition, but does not provide a complete means to achieve Defects in namespace queries.
  • Embodiments of the present invention address special query requirements for certain data, such as range queries for time, date, quantity, etc., quantity queries for data, and the like.
  • Subtree filtering is more suitable for real network management or other practical applications.
  • the embodiment of the present invention implements optimization of filtering results, and implements merging or sorting of the same or similar data; discarding useless descendant nodes when needed, and greatly reducing a large amount of redundant information that may exist in the subtree filtering result.
  • FIG. 11 is a schematic structural diagram of a filter according to Embodiment 5 of the present invention. As shown in FIG. 11, the method includes: a receiving module 1110, configured to receive a data stream to be filtered;
  • the filtering module 1120 is configured to filter the data flow by means of incomplete matching, and process a filtering condition in a string form that the user does not give complete information.
  • the filtering module 1120 includes:
  • the first filtering sub-module 1121 is configured to filter the data flow by using an absolute path; and/or the second filtering sub-module 1122 is configured to filter the data flow by using a relative path.
  • the embodiment of the invention increases the query function of the namespace in the subtree filtering, and helps the user to quickly understand the structure of the data distribution in the XML document; the NETCONF protocol subtree filtering must provide the namespace condition, but does not provide a complete means to achieve Defects in namespace queries.
  • Embodiments of the present invention address special query requirements for certain data, such as range queries for time, date, quantity, etc., quantity queries for data, and the like.
  • Subtree filtering is more suitable for real network management or other practical applications.
  • FIG. 12 is a schematic structural diagram of a logic filtering apparatus according to Embodiment 6 of the present invention. As shown in FIG. 12, the method includes:
  • the receiving module 1210 is configured to receive a data stream to be filtered.
  • the logic filtering module 1220 is configured to filter the element type nodes in the data stream by using multiple attributes or multiple content matching nodes.
  • the logic filtering module 1220 includes:
  • a setting sub-module 1221 configured to set a content matching node as a filtering condition for selecting a specific parent node from the data model
  • the adding sub-module 1222 is configured to indicate a matching degree of the content matching node by adding a first attribute in the content matching node, and implement a logical relationship combination between the content matching node filtering conditions;
  • the processing sub-module 1223 is configured to filter the element type nodes in the data stream according to the logical relationship between the filtering conditions.
  • the embodiment of the invention increases the query function of the namespace in the subtree filtering, and helps the user to quickly understand the structure of the data distribution in the XML document; the NETCONF protocol subtree filtering must provide the namespace condition, but does not provide a complete means to achieve Defects in namespace queries.
  • Embodiments of the present invention address special query requirements for certain data, such as range queries for time, date, quantity, etc., quantity queries for data, and the like.
  • Subtree filtering is more suitable for real network management or other practical applications.
  • the embodiment of the present invention implements optimization of filtering results, and implements merging or sorting of the same or similar data; discarding useless descendant nodes when needed, and greatly reducing a large amount of redundant information that may exist in the subtree filtering result.
  • FIG. 13 is a schematic structural diagram of a subtree filtering query result processing apparatus according to Embodiment 7 of the present invention. As shown in FIG. 13, the method includes:
  • the setting module 1310 is configured to set a value of the third attribute at a corresponding node in the filter, where the third attribute is a _show attribute;
  • the determining module 1320 is configured to set a value of the third attribute according to the setting module 1310, indicating whether the node descendant is displayed at the node.
  • the processing device further includes:
  • the sorting module 1330 is configured to sort the filtering results obtained by the same filter node as needed.
  • the node merge module 1340 is configured to combine nodes with identical contents in the query result.
  • the present invention can implement the following functions in the NETCONF protocol that the subtree filtering mechanism cannot be implemented or has a poor effect or a defective processing method, as shown in Table 2:
  • the embodiment of the invention provides a method for querying and filtering XML network management data based on the NETCONF subtree filtering mechanism and expressed in XML form, so as to enable the NETCONF protocol.
  • the acquisition of management information is more convenient, and avoids many problems caused by redefining a set of specifications for data query and filtering.
  • Embodiments of the present invention provide a refinement and combination mechanism for filtering conditions of XML data.
  • the degree of matching of the nodes is refined, and the user can select a corresponding query method according to the specific role of the nodes in the data storage.
  • the filter conditions expressed by attributes and namespaces can be combined in a logical operation to make the query more flexible.
  • the embodiment of the invention provides a node or attribute name that cannot completely spell out the data storage in the case that the filtering condition is incomplete, or can not completely give the position defined by the data in the XML document, and can still perform the XML data.
  • the tree filters the operation and gets the results the user wants.
  • the embodiment of the invention increases the query function of the namespace in the subtree filtering, and helps the user to quickly understand the structure of the data distribution in the XML document; the NETCONF protocol subtree filtering must provide the namespace condition, but does not provide a complete means to achieve Defects in namespace queries.
  • Embodiments of the present invention address special query requirements for certain data, such as range queries for time, date, quantity, etc., quantity queries for data, and the like.
  • Subtree filtering is more suitable for real network management or other practical applications.
  • the embodiments of the present invention implement optimization of filtering results, and implement merging or sorting of the same or similar data; discarding useless descendant nodes when needed. Significantly reduce the amount of redundant information that may exist in subtree filtering results.
  • the present invention can be implemented by hardware, or can be implemented by means of software plus necessary general hardware platform, and the technical solution of the present invention can be implemented.
  • the software product can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.), including a number of instructions for making a computer device (may be A personal computer, server, or network device, etc., performs the methods described in various embodiments of the present invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Artificial Intelligence (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Databases & Information Systems (AREA)
  • Evolutionary Computation (AREA)
  • Medical Informatics (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

模糊查询、 查询结果处理和过滤条件处理的方法及设备 技术领域
本发明涉及通信技术领域, 尤其涉及一种模糊查询、 查询结果处理和过 滤条件处理的方法及设备。 背景技术
网络配置协议( Network Configuration Protocol , 以下简称: NETCONF ) 是一种网管协议, 使用可扩展标记语言 (Extensible Markup Language, 以下 简称: XML )描述操作请求和网管数据。 XML是一套语义标记的规则, 将文 档分成许多部件并用标记对这些部件加以标识。这些标记通常采用自然语言, 因此具有很高的可读性。 标记看起来如下:
<age>10</age>
<name language^' 'English' '>
<first-name>George</first-name>
<last-name>Bush</last-name>
</name>
<hobby></hobby>
<hobby/>
每一对标 i己由起始标 i己(^口 <age> )和结束标 i己 (^口 </age> )组成, 每一 对标记及其内容称为一个元素( element ), 在以上例子中就有 <age>、 <name> 元素。 元素可以拥有值, 如<&36>的值是 10; 也可以拥有子元素, 如<11&11½>
Figure imgf000003_0001
也可以没有值, :¾。<hobby>, 这种情 况称为空元素, 可缩写记为 <hobby/>; 元素还可以拥有属性 (attribute ) , 属 性是一个 "名字 -值" 对, 如<1^1!½>拥有属性 language, 属性值是 English。
图 1是现有技术中一种树型数据结构示意图, 元素间的层次嵌套关系经 常表达为一个树型数据结构, 如图 1 所示, 因此元素也被称作节点。 在一对 嵌套关系中, 外层节点被称作内层节点的父节点; 内层节点被称作外层节点的 子节点。 ^口图 1中, <0>是<¾1>、 <b2>、 <b3>的父节点, <bl>、 <b2>、 <b3> 是 <a>的子节点。 拥有同一父节点的几个节点相互称为兄弟节点, 如<¾1>、 <b2>、 <b3>彼此是兄弟节点。
在网络管理中, 需要监视网络设备的配置和状态, 为达到此目的, 网管 设备发出查询报文, 描述所需要查询的数据, 被管设备收到查询报文后, 依 照查询报文中的条件执行查询, 并向网管设备应答查询结果。
NETCONF协议拥有两种查询操作: <get>^<get-config>0 尽管两者的查 询对象有所区别 , 但拥有相同的查询条件表达方式, 即子树过滤和 XML路 径语言 (XML Path Language, 以下简称: Xpath ) 方式。
现有技术一中, 子树过滤使用 XML 方式描述过滤条件, 通过一组简单 的匹配规则, 对符合条件的数据元素进行选取。 例 1是一个子树查询的例子, <rpc>元素表明这是一个网管设备发出的请求, <§61>元素表明网管设备请求 执行查询操作, <filter>元素指明了查询方式和查询条件, 其属性 type= "subtree" 指出该查询釆用子树过滤方式, <filter>包含的子节点表明: 该查 询希望查询命名空间 "http:〃 example.eom/schema/l.2/stats"内的<1;(^>元素中的 <interfaces> L素中的某个 <interface> L素, 并且该 <interface> L素必须具有 if ame属性, ifName的属性值是" ethO"。
例 1 : 一个使用子树查询的 <get>"¾"求:
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base: 1.0">
<get>
<filter type="subtree">
<t:top xmlns:t="http:〃 example. com/schema/1.2/stats"> <t:interfaces>
<t: interface t:ifName="eth0 >
</t: interface s>
</t:top>
</filter> </get>
</rpc>
其中, <filter>元素被称为过滤器, 在子树过滤中, 过滤器由零到多个代 表选择标准的元素子树构成。 在子树的各层, 被管设备对每个兄弟节点集合 进行逻辑判断, 以决定各兄弟节点所牵头的子树是否包含在过滤器的输出结 果中。 所有在过滤器子树中出现的元素, 必须与服务器概念数据模型中的对 应节点相匹配。
过滤器可分为 5种组件, 每种组件执行不同的过滤规则, 包括: 命名空 间选择、 属性匹配表达式、 包含节点、 选择节点、 内容匹配节点。
命名空间选择: 如果使用命名空间, 则过滤器的输出只包含指定的命名 空间中的元素。 即: 过滤器中" xmlns"属性的内容应与被管设备数据模型中" xmlns " 属 性 的 内 容 相 同 。 在 例 1 中 <t:top xmlns:t="htt :〃 example.com/schema/1.2/stats"> ^ 出 了选择的命名空间是 htt : //example . com/schema/ 1.2/stats, 只有该命名空间中的 <top>中的子元素被 输出。
属性匹配表达式: 出现在过滤器中的属性是属性匹配表达式的一部分。 被选择的数据除了要与过滤器中的节点匹配,还必须与过滤器的属性相匹配。 如果一个元素不包含指定的属性, 则该元素将不被选择。 例 1 中, if ame="ethO"就是属性匹配表达式。 过滤结果将输出拥有 ifName属性, 并且 ifName的属性值是" ethO' ^i interface ^素,如例 2所示。例 2中, <rpc-reply> 元素表明这是一个应答, <£^ >元素表明应答的数据, 应答数据的命名空间、 各级子元素和属性都和过滤器中的对应部分相匹配。
例 2: 属性匹配的查询结果:
<rpc-reply message-id- '101 "
xmlns="urn:ietf:params:xml:ns:netconf:base: 1.0">
<data>
<t:top xmlns:t="http:〃 example. com/schema/1.2/stats ">
<t:interfaces> <t: interface t:ifName="ethO">
<t: ifln0ctets>45621 </t:ifInOctets>
<t:ifOutOctets>774344</t:ifOutOctets>
</t:interface>
</t:interfaces>
</t:top>
</data>
</rpc-reply>
包含节点: 过滤器中包含子元素的节点被称为包含节点。 包含节点的子 元素也可以是包含节点, 或其他类型的节点。例 1中, <top>是一个包含节点, 其子元素<111 &068>也是一个包含节点。
选择节点: 过滤器中的空节点被称为选择节点, 表示对数据模型的一个 显式选择。 如果在数据模型的兄弟节点中出现了选择节点, 则只有该选择节 点下的子树被选择, 该选择节点的兄弟节点不被选择。 如例 3中, <¾&1!16>元 素是个选择节点。 在被管设备的数据模型中, 如果 <user>除了 <name>还有其 他子节点, 那么只有<1^11½>才被选择, <11&11½>的兄弟节点将不被选择。
例 3: 过滤器中的选择节点:
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name/>
</user>
</users>
</top>
</filter>
内容匹配节点: 包含文本值的叶子节点被称为内容匹配节点, 表示对父 节点的选择条件。 例 4 中, <¾&1116>元素是内容匹配节点, 表示所有<1^1!16> 为" fred" 的<1^1">元素 (及其子元素)将被选择输出。 该过滤器的查询结果 如例 5所示。
多个兄弟内容匹配节点间执行 "与" 的逻辑运算;
例 4: 过滤器中的内容匹配节点:
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>fred</name>
</user>
</users>
</top>
</filter>
例 5 针对内容匹配节点的应答输出:
<rpc-reply message-id=" 101"
xmlns="urn:ietf:params:xml:ns:netconf:base: 1.0">
<data>
<top xmlns="htt ://ex ample . com/schema/ 1.2/config ">
<users>
<user>
<name>fred</name>
<type>admin</type>
<full-name>Fred Flintstone</full-name>
<company-info>
<dept>2</dept>
<id>2</id>
</company-info>
</user> </users>
</top>
</data>
</rpc-reply>
综上所述, 子树过滤的流程可概括如下:
过滤器的输出开始是空的。 被管设备将它所支持的数据模型与过滤器中 的每个数据分枝进行比较, 如果一个节点所代表的子树的所有分枝与被管设 备的数据模型的对应部分实现了完全匹配, 则该节点及其所有子节点包含在 结果数据中。
子树过滤存在以下缺点:
1.子树过滤需要较多的已知条件, 如树上各层级节点名字、 节点值、 属 性名字、 属性值、 命名空间等, 这对网络管理员的记忆力要求较高。
2.匹配模式单一, 只能精确匹配, 否则会认为在数据模型中不存在符合 过滤条件的节点。 不能将多个查询条件进行逻辑组合(与、 或、 非) , 也不 能实现数值、 时间数据的范围过滤 (大于、 小于) 。
3.不能控制过滤结果的输出, 容易造成冗余和混淆。 例如当用户试图查 询某个节点本身的信息时, 子树过滤总是将其所有后代一并输出, 这样可能 会造成在网络中传输大量不必要的加密信息以及用户人工查找信息的困难。
4.缺少对过滤结果的统计和处理机制。仅能返回 xml数据自身, 对于 xml 数据的统计信息用户无法获得, 同时也无法控制这些实体的返回方式。
现有技术二中, XPath即 XML路径语言, 是 W3C关于查询 XML文档 的通用语言标准。 从外观上看, XPath是用文件路径的形式表示 XML文档查 询条件的方法。 例如, 例 4中的子树过滤用 XPath表达就如例 6所示。 例中 type="xpath"表明使用 XPath查询方法, select属性的值为一个 XPath表达式, 指出了查询的内容和条件。
例 6: XPath过滤表达式:
<filter type="xpath" select="top/users/user[name="fred"]"/>
XPath机制较为复杂, 掌握起来较为困难。 并且 XPath以非 XML方式表 述, 需提供额外机制进行解析和处理。
XPath是通过路径表达式来选取 XML文档中的节点或者节点集,每次只 能获取一条查询记录,这样对于用户想一次实现多个结果的查询就无法实现, 查询效率比较低。
在实现本发明的过程中, 发明人发现现有技术至少存在以下缺点: 现有技术一中的子树过滤基于精确匹配和绝对路径, 需要用户提供较多 已知条件, 缺少对过滤结果的统计和处理机制; 而现有技术二中 XPath机制 较为复杂, 难于掌握。 发明内容
本发明实施例提供了一种模糊查询、 查询结果处理和过滤条件处理的方 法及设备, 以解决 NETCONF协议子树过滤机制仅局限于精确匹配和绝对路 径, 数据查询中要求给出较多已知信息带来的不便; 解决 NETCONF协议数 据模型查询中, 对命名空间查询、 过滤、 处理手段匮乏的问题; 丰富子树过 滤机制的查询和过滤手段, 提高子树过滤的灵活性和功能性; 处理子树过滤 得到的 XML过滤结果文档, 减少冗余信息的处理和传输; 修正 NETCONF 协议中子树过滤部分不合理的过滤报文处理方法。
本发明实施例提供了一种基于子树过滤的模糊查询方法, 包括: 接收待过滤数据流;
通过不完全匹配的方式过滤所述数据流, 处理用户没有给出完全信息的 字符串形式的过滤条件
本发明实施例还提供了一种子树过滤条件的逻辑组合的扩展方法, 包括: 接收待过滤数据流;
采用多个属性或多个内容匹配节点对所述数据流中的元素类型节点进行 过滤。
本发明实施例还提供了一种子树过滤查询结果的处理方法, 包括: 在过滤器中相应节点处设置第三属性的值, 表明所述节点处是否显示节 点后代; 所述第三属性的取值为第一值或者第二值, 当所述第三属性默认为显示 所有在同一命名空间的后代, 则第三属性等于第二值; 当设置第三属性等于 第一值, 则过滤结果只输出该节点的信息, 不输出在同一命名空间的后代节 点。
本发明实施例还提供了一种过滤器, 包括:
接收模块, 用于接收待过滤数据流;
过滤模块, 用于通过不完全匹配的方式过滤所述数据流, 处理用户没有 给出完全信息的字符串形式的过滤条件。
本发明实施例还提供了一种逻辑过滤装置, 包括:
接收模块, 用于接收待过滤数据流;
逻辑过滤模块, 用于采用多个属性或多个内容匹配节点对所述数据流中 的元素类型节点进行过滤。
本发明实施例还提供了一种子树过滤查询结果处理装置, 包括: 设置模块, 用于在过滤器中相应节点处设置第三属性的值;
确定模块, 用于根据所述设置模块设置所述第三属性的值, 表明所述节 点处是否显示节点后代。
本发明的实施例中, 提供一种基于 NETCONF 子树过滤机制, 以 XML 形式表达, 对 XML网络管理数据进行查询和过滤, 使对 NETCONF协议中 管理信息的获取更为方便, 也避免了为数据查询和过滤重新定义一套规范带 来的诸多问题。
本发明实施例提供了一种对 XML数据过滤条件的细化和组合机制。 XML 文档中的节点有时包含了具体的数据信息, 类似于关系数据库中一个字段; 有时只是封装数据信息的手段, 类似于关系数据库中的一条记录。
本发明实施例中细化了节点的匹配程度, 用户可以根据节点在数据存储 中的具体作用选择相应的查询方法。 另外, 属性、 命名空间方式表达的过滤 条件可以以逻辑运算方式组合到一起, 使查询更为灵活。
本发明实施例提供一种在过滤条件不完整的情况下, 比如不能完整拼写 出数据存储的节点或属性名字, 或者不能完全给出数据在 XML 文档中定义 的位置, 仍可以对 XML数据进行子树过滤操作, 并得到用户想要的结果。 本发明实施例增加子树过滤中命名空间的查询功能, 帮助用户快速的了 解 XML文档中数据分布的结构; 弥补了 NETCONF协议子树过滤中必须给 出命名空间条件, 但又不提供完整手段实现命名空间查询的缺陷。
本发明实施例处理对某些数据的特殊查询需求, 比如时间、 日期、 数量 等的范围查询、 数据的数量查询等等。 使子树过滤更能满足实际网络管理或 其他实际应用中的需求。
本发明实施例实现对过滤结果的优化, 实现对相同或类似数据的合并或 排序; 在需要时, 丢弃无用的后代节点, 大大减少了子树过滤结果可能存在 的大量冗余信息。 附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案, 下面将对实 施例或现有技术描述中所需要使用的附图作一简单介绍, 下面描述中的附图 仅仅是本发明的一些实施例, 对于本领域普通技术人员来讲, 在不付出创造 性劳动的前提下, 还可以根据这些附图获得其他的附图。
图 1是现有技术中一种树型数据结构示意图;
图 2是本发明实施例中 NETCONF协议中子树过滤系统结构图; 图 3是本发明实施例中总体流程图;
图 4是本发明实施例中过滤控制模块工作流程图;
图 5是本发明实施例中过滤控制调用名字空间处理组件流程图; 图 6是本发明实施例中递归流程控制流程图;
图 7是本发明实施例中结果处理实现流程图;
图 8是本发明实施例二的基于子树过滤的模糊查询方法流程图; 图 9是本发明实施例三的子树过滤条件的逻辑组合的扩展方法流程图; 图 10是本发明实施例四的子树过滤查询结果的处理方法实现流程图; 图 11是本发明实施例五的过滤器结构示意图;
图 12是本发明实施例六的逻辑过滤装置结构示意图; 图 13是本发明实施例七的子树过滤查询结果处理装置结构示意图。 具体实施方式
为了使本发明的目的、 技术方案及优点更加清楚明白, 以下结合附图及 实施方式, 对本发明进行进一步详细说明。 应当理解, 此处所描述的具体实 施方式仅仅用以解释本发明, 并不用于限定本发明。
本发明实施例提供一套基于 NETCONF协议并对 NETCONF协议中子树 过滤机制加以扩展的, 实现对 XML语言定义的网络管理信息模型的数据查 询和数据过滤功能的定义方法。 定义方法包括对于子树过滤功能的详细说明 和与功能定义相关的关键字定义。
为与 NETCONF协议中子树过滤机制相区别, 本发明实施例为 61">节 点的 type属性新增取值 advancedSubtree, 表示其中可能含有进行子树过滤机 制扩展功能操作的请求。
子树过滤扩展机制主要包括以下功能:
1. 模糊匹配
模糊匹配是指在过滤流程中, 处理节点名字、 节点内容、 属性名字、 属 性值、 命名空间等字符串匹配中, 以不完全匹配的方式处理用户没有给出完 全查询信息的字符串。
举例来说, 由于 XML 文档标签对于字符串有着较为严格的限制, 所以 节点名、 属性名等标签内容与节点内容、 属性值、 命名空间等文本内容的模 糊匹配手段是不一样的。 对于标签内容来说, 仅可使用字符 "_,, 表示匹配任 何字符。 对于节点内容、 属性值、 命名空间等带有双引号的字符串, 则进行 字母匹配或者利用" *" 匹配所有字符。 又举例来说, 可以使用 "_" 和 "*" 作为通配符, 其中, "_" 用于匹配节点名和属性名中的任何字符; "*" 用 于匹配节点值和属性值中的任何字符。
例 7, 例 8: 过滤 <1"01^1^>节点下具有某属性值为 Ethernetl的<11^ &。6> 节点。 举例来说, 例 7使用通配符 "―" 用于匹配任何值为 "Ethernetl " 的属 性, 过滤中找到属性值 Ethernetl对应的属性和属性所在节点, 将所在节点、 属性名字和属性值均输出, 过滤结果如例 8。
例 7 : 属性名字的模糊匹配:
<filter type="advancedSubtree">
<netconf xmlns="*">
<routing>
<interface _="Ethernetl"/>
</routing>
</netconf>
</filter>
例 8: 属性名字模糊查询的返回结果:
<netconf xmlns="urn:ietf:params:xml:ns:netconf:base: 1.0"
xmlns: if="urn:bupt:pris :priser: agent: module: interface: 1.0"> <routing>
<if: interface name=" Ethernet 1" ip-address=" 59.64.139.65">
<... />
</if:interface>
</routing>
</netconf>
另外, 若已知属性名但不知属性值, 也可以对属性值使用模糊查询, 这 时用到通配符 "*" , 如例 9所示:
例 9 : 属性值的模糊匹配:
<filter type="advancedSubtree">
<netconf xmlns="*">
<routing>
<interface name="*"/>
<routing/>
<netconf/>
</filter> 节点名字与值的模糊查询与之类似。如模糊了 <name>的值和 <name>自身 的查询可 ^下所示:
<interface><name>*</name></interface>
或者:
<interface><_>Ethernet 1 </_></interface>
此外, 还可以实现对节点值、 属性值、 命名空间内容进行不完全内容匹 配的模糊过滤。 这样的查询条件如下所示:
<interface name="Eth*"/>
若 XML数据中存在多个<0^ &06>元素,并且它的 name属性值以 "Eth" 开头, 则这些 <0«6 &06>元素均被匹配输出。
2. 相对路径与跨层次访问
协议中子树过滤采用绝对路径匹配: 即过滤器的根节点和各级后代节点 必须和数据模型中的完全相同。
为了提高过滤的灵活性, 特增加相对路径匹配机制, 即过滤器中节点仅 保持和数据模型中一样的祖先-后代关系, 但并不严格保持和数据模型中一样 的父子关系。 例如数据模型中节点 A和 B是爷孙关系, 但过滤器中两者是父 子关系, 虽然 B的父节点在数据模型和过滤器中各不同, 但 A和 B的祖先- 后代关系在两者中是相同的。
为了实现相对路径过滤, 本发明为< 1 1">节点定义了属性_110(^ & , 该 属性有两个取值:
absolute, 表示过滤器中所有节点采用绝对路径过滤, 即过滤过滤器中各 个节点间的父子关系必须与数据模型中的父子关系严格一致。 为该属性的默 认值;
relative, 表示采用相对路径过滤, 即过滤器中有父子关系的节点在数据 模型中满足祖先-后代关系。
例如例 10, 例 11希望查询数据模型中的<11^ &06>节点, 因不知其在数 据模型中的具体位置, 无法在过滤器中给出该节点的绝对路径, 因此使用了 _nodepath="relative"进行相对路径的过滤: 例 10: 相对路径过滤:
<filter type="advancedSubtree" _nodepath="relative">
<interface xmlns="*"/>
</filter>
例 11 : 相对路径过滤的过滤结果:
<netconf xmlns="urn:ietf:params:xml:ns:netconf:base: 1.0"
xmlns: if="urn:bupt:pris :priser: agent: module: interface: 1.0"> <routing>
<if: interface name=" Ethernet 1" ip-address=" 59.64.139.65">
<... />
</if:interface>
<if: interface name="Ethernet2" ip-address=" 59.64.139.69">
<· .. />
</if:interface>
</routing>
</netconf>
如果已知 <^^ &06>节点所在数据模型的根节点 A<netcon£> , 也可以改 写例 10为:
<filter type="advancedSubtree" _nodepath="relative">
<netconf xmlns="*">
<interface/>
</netconf>
</filter>
3. 查询条件细化与组合
在子树过滤中, 可以采用多个属性表达式或多个内容匹配节点作为过滤 条件进行过滤。 但多个过滤条件之间只能是 "与" 的关系。
为了提高过滤条件设置的灵活性, 特增加其他两种逻辑关系: 或、 非, 并细分以元素类型节点方式定义的过滤条件的匹配程度。 3.1 元素类型节点过滤条件的逻辑关系
本发明通过在每个内容匹配节点中添加属性_11^(;11丁 6来表示该节点的 匹配程度, 并在一定程度上间接地实现节点过滤条件之间的逻辑关系组合。
属性_11^(:11丁^6有三个取值:
must, 表示该内容匹配节点必须和数据模型中相应的节点完全匹配, 才 将其父节点添加到过滤结果中, 为属性默认值;
may, 表示该内容匹配节点如果和数据模型中相应的节点完全匹配, 则 将该内容匹配节点的父节点添加到过滤结果中; 若不匹配, 则忽略该内容匹 配节点, 查看过滤器中其他的内容匹配节点的情况;
not, 表示该内容匹配节点和数据模型中相应的节点不匹配, 才将其父节 点添加到过滤结果中。
例 12: 查询 <interface>元素, 该 <interface>元素应满足 <name>为 Ethernet 1 , JL<received> 490
<filter type="advancedSubtree">
<netconf xmlns="*">
<routing>
<interface>
<name _matchType=' 'must' '>Ethernet 1 </name>
<received _matchType="must">49</received>
</interface>
</routing>
</netconf>
</filter>
在上述例 12 中, 两个内容匹配节点 <name>和 <recei ved>均使用了 _matchType="must", 表明这两个节点指示的查询条件必须同时满足, 这样的
<^1^ &06>节点才能被输出。
若改变查询条件, 希望得到< 1116>为 Ethemetl , 或者 <^06^^(1>为 49的 interface ^素, 则应令 _matchType="may", 口例 13所示。 例 13 : 内容匹配节点之间 "或" 逻辑关系的实现:
<filter type="advancedSubtree">
<netconf xmlns="*">
<routing>
<interface>
<name _matchType="may">Ethemet 1 </name>
<received _matchType="may">49</received>
</interface>
</routing>
</netconf>
</filter>
例 14 演示 7 _matchType= "not" 的例子, 该查询希望输出 <name>不是 Ethernet 1的 <interface> T5"点。
例 14: 内容匹配节点的 "非" 过滤条件:
<filter type="advancedSubtree">
<netconf xmlns="*">
<routing>
<interface>
<name _matchType="not">Ethemet 1 </name> </interface>
</routing>
</netconf>
</filter>
3.2 节点属性和命名空间的逻辑关系过滤
节点的多个属性间的逻辑关系可以通过向节点中添加属性_&1^^0§^ 来 表示。命名空间间逻辑关系可以通过添加属性_1^1^(¾ 来表示。属性_&« (¾ 的值为一逻辑表达式。 逻辑表达式中可使用下列逻辑运算符:
Λ , 逻辑 "与" 运算; ||, 逻辑 "或" 运算;
!, 逻辑 "非" 运算;
( ), 改变运算优先级。
属性 _nsLogic 的逻辑表达式只能使用逻辑 "或" 运算。 逻辑表达式中参 与逻辑运算的对象是属性名或命名空间前缀。
如果节点中未出现属性_&½^^, 则默认各个属性之间是 "与" 的关系。 即下面两个条件描述等同:
<interface name= " Ethernet 1" ip-address=" 59.64.139.69" />
<interface name="Ethemetl " ip-address=" 59.64.139.69"
_attrLogic="nameAip-address"/>
如果爹改过滤条件, 查询 name属性值不是" Ethernet 1" , 或者 ip-address 属性值是" 59.64.139.69" 的<0^ &06>节点, 这个查询条件的表达方式如下:
<interface name= " Ethernet 1 " ip-address=" 59.64.139.69" _attrLogic="! name ||ip-address"/>
命名空间逻辑关系用法和属性的类似, 只不过仅能使用 "或" 操作, 如 例 15所示。
例 15: 节点多重命名空间查询:
<filter type="advancedSubtree">
<netconf xmlns="*">
<routing>
<interface
xmlns:if="urn:bupt:pris:priser:agent:module:mterface: 1.0"
xmlns:mt=''urn:bupt:pris:priser:agent:module:monitor: 1.0''
_nsLogic- 'ifl|mt" />
<routing/>
<netconf/>
</filter>
4. 命名空间查询 命名空间查询可以获取数据模型中命名空间的定义情况, 并给出命名空 间的列表。 命名空间查询的关键字为标签元素 <_xmlns>, 当过滤器<6^1">的 子节点为<_ 1111118>, 则表示对该数据模型进行命名空间相关查询; <_xmlns> 拥有属性 prf, 属性值是该命名空间在 XML文档中对应的前缀,如果该命名空 间是默认命名空间 (即无前缀) , 则不输出 prf属性。
例如例 16, 例 17分别显示了查询数据模型中所有命名空间的过滤器定 义和过滤结果。
例 16: 查询所有命名空间:
<filter type="advancedSubtree">
<_xmlns/>
</filter>
例 17: 例 16的过滤结果:
<data>
<_xmlns> urn:ietf:params:xml:ns:netconf:base: 1.0</_xmlns>
<_xmlns prf="if > urn:bupt :pris :priser : agent: module: interface: 1.0</_xmlns>
<_xmlns prf="mt"> urn:bupt :pris :priser : agent: module: module: 1.0</_xmlns>
</data>
上述实例 16通过关键字元素<_ 1111113>告知过滤器,查询数据模型中存在 的 所 有 命 名 空 间 。 过 滤 结 果 则 以 <_xmlns > urn:ietf:params:xml:ns:netconf:base: 1.0</_xmlns>的形式将数据模型中所有的 命名空间返回。
另外, 还可以查询部分数据模型的命名空间, 如例 18所示:
例 18: 查询部分元素的命名空间:
<filter type="advancedSubtree">
<_xmlns>
<netcon > <routing/>
</netconf>
</_xmlns>
</filter>
过滤结果如下:
<_xmlns pri="if '> urn:bupt:pris:priser:agent:module:interface: 1.0</_xmlns> 上述实例中, 过滤器 <filter>通过设置子节点<_ 1111113>告知过滤器查询数 据模型的命名空间 , 同时通过设置节点"^^^。!!^!^^!!^〉 !^ !!^告知过 滤器具体查询的是子树 /netconf/routing的命名空间,所以过滤结果中只返回了 数据模型中<1½1^01 1 和<¾)111;0^>节点的命名空间 "urn: bupt: pris: priser: agent: module: interface: 1.0" 。
5. 后代输出控制
当过滤器给出一个选择节点或包含节点, 过滤结果将输出节点自身及其 所有后代; 有些时候它的后代节点是不需要的。
为了提高过滤效率及方便用户获取所需信息, 可以在过滤器中相应节点 处设置属性 _show指示是否输出节点后代。 该属性的有如下两种取值:
self, 过滤结果只输出该节点自身的信息, 不输出其后代节点。
descendant, 过滤结果输出该节点及其所有后代节点, 为属性默认值。 例如例 19、 例 20、 例 21、 例 22分别显示了如何过滤出指定节点的完整 信息和部分信息。
例 19: 输出节点完整信息的过滤器:
<filter type="advancedSubtree"_ nodepath="relative">
<interface _show="descendant"/>
</filter>
例 20: 例 19的过滤结果:
<netconf xmlns="urn:ietf:params:xml:ns:netconf:base: 1.0"
xmlns: if="urn:bupt:pris :priser: agent: module: interface: 1.0"> <routing> <if: interface name=" Ethernet 1" ip-address=" 59.64.139.65">
<... />
</if:interface>
<if: interface name="Ethernet2" ip-address=" 59.64.139.69">
<... />
</if:interface>
</routing>
</netconf>
例 21 : 只输出节点本身信息:
<filter type="advancedSubtree"_ nodepath="relative">
<interface _show="self '/>
</filter>
例 22: 例 21的过滤结果:
<netconf xmlns="urn:ietf:params:xml:ns:netconf:base: 1.0"
xmlns: if="urn:bupt:pris :priser: agent: module: interface: 1.0"> <routing>
<if: interface name=" Ethernet 1" ip-address=" 59.64.139.65"/> <if: interface name="Ethernet2" ip-address=" 59.64.139.69"/> </routing>
</netconf>
对比上述例 20 和例 22 , 可以明显看到当在过滤器 <filter>†的节点 <interface>中设置属性 _show=" self 时, 则只输出节点本身的信息, 避免了 返回过多的冗余信息, 提高过滤效率。
6. 个数查询
个数查询功能可以统计数据模型中某一类元素的个数, 即同一过滤器节 点对应的元素个数。通过在过滤器中某元素类型节点中使用 _count属性实现 , 该属性的取值有 true和 false。 当设置—count属性值为" true" 时, 则过滤结 果输出查询实体的个数; 当设置 _count属性为" false" 时, 则过滤结果不输 出查询实体的个数, " false" 是属性 _coimt 的默认值。 如果过滤结果返回查 询实体的个数, 则在过滤结果中相应实体元素类型节点下面添加标签元素 <_countNum>, 该元素的文本值标识查询实体的个数。
例如例 23、例 24显示了如何查询 <monitor>节点的子节点<。0111 81^311011> 的个数, 过滤器和过滤结果如下:
例 23 : 查询指定节点的个数:
<filter type="advancedSubtree">
<netconf xmlns="*">
<monitor xmlns- ' urn:bupt:pris:priser:agent:module:monitor: 1.0" >
<configuration _count="true"/>
</monitor>
</netconf>
</filter>
例 24: 例 23的过滤结果:
<netconf>
<monitor xmlns=" um:bupt:pris:priser:agent:module:monitor: 1.0">
<configuration>
<_countNum>3 </_conutNum>
</configuration>
</monitor>
</netconf>
还可以为个数查询增加其他条件, 比如查询属性
Figure imgf000022_0001
<interface>的节点数, 或者节点值为 running-state 0 <configuration> "^点数。 这样的查询如下所示:
<interface name=" Ethernet 1" _count="true">
Configuration _count="true">running-state</running>
7. 范围条件
本发明在表示数量或时间的选择节点中添加表示范围的属性, 以此将该 选择节点看作是表示时间或数量范围的内容匹配节点, 从而在过滤处理时作 为过滤条件。
其中表示数量范围的属性关键字有:
_morethan, 表示该属性所在的选择节点的值大于该属性的值;
Jessthan, 表示该属性所在的选择节点的值小于该属性的值;
_notmorethan , 表示该属性所在的选择节点的值不大于该属性的值; _notlessthan, 表示该属性所在的选择节点的值大于该属性的值。
表示时间范围的属性关键字有:
Jimebefore , 表示该属性所在的选择节点的时间值超前于该属性的值; Jimeafter, 表示该属性所在的选择节点的时间值滞后于该属性的值; Jimenotbefore , 表示该属性所在的选择节点的时间值等于或滞后于该属 性的值;
Jimenotafter, 表示该属性所在的选择节点的时间值等于或超前于该属性 的值。
例如欲查询 <received^ 值大于 12 且小于 25的<11^ &06>节点, 过滤器表达 如例 25所示, 其中 <received _morethan=" 12" _lessthan=" 25" />表达了 这一范围条件。 例 26显示该查询的结果。
例 25 : 数值范围过滤的过滤器:
<filter type="advancedSubtree">
<netconf xmlns="urn:ietf:params:xml:ns:netconf:base: 1.0"
xmlns:if="urn:bupt:pris:priser:agent:module:interface: 1.0">
<routing>
<if:interface>
<received _morethan="12" _lessthan=',25,7»
</if:interface>
</routing>
</netconf
</filter> 例 26: 例 25的过滤结果:
<netconf xmlns="urn:ietf:params:xml:ns:netconf:base: 1.0"
xmlns:if="urn:bupt:pris:priser:agent:module:interface: 1.0">
<routing>
<if: interface name="Ethernetl " ip-address="59.64.139.65"> <if:received> 19</if:received>
<... />
</if:interface>
、 </routing>
</netconf>
下面是才艮据时间范围条件查询的例子:
<startTime _timenotafter=" 2007-07-01 05:24:06" _timeafter=" 2007-06-30 05:24:06"/〉
表示查询表示时间晚于但不包括 2007年 06月 30日 05:24:06, 并早于且 包括 2007年 07月 01 日 05:24:06的<31&10¾^>节点。
或者添加字符串匹配功能:
<startTime _timeafter=" 2005-06-30 05:24:06">*-07-*</startTime> 符合 -07-格式的只有月份的表达, 上述定义可以查询 2005年 06月 30曰 05:24:06以后每年 7月的相关数据。
8. 子树排序合并
对同一个过滤器节点得到的过滤结果按照需要进行排序, 如根据某个节 点内容进行升序或者降序排列, 合并查询结果中内容完全相同的节点。
排序通过在要排序子树根节点处设定属性 _ascOrder和_(^0〇(^实现。 属性 _ascOrder表示根据某节点或属性做升序排列, 属性 _descOrder表示根据 某节点或属性做降序排列。这两个属性的取值为排序依据的节点名或属性名。 排序所依据的节点应当有值, 并且是该属性所在节点的子节点。 以属性进行 排序时需要在属性名前加 "@" , 标识这是一个属性名。 节点值为排序依据 的索引, 默认按文本方式排序; 如果按数值大小排序, 在节点或属性名后加 标识 " ( n ) " , 比如 _ascOrder= "recived ( n ) " ; 如果该节点或属性的值为 非数值类型, 则向用户返回错误信息。
当需要以多个节点、 属性进行^ ^序时, 多个节点名、 属性名间以 "Λ" 连 接, 排在前面的节点、 属性名字优先级高于后面的节点、 属性名字。
例如, 希望按 <name>节点的值以降序的顺序输出 <interface>节点, 具有 相同 <name>值的 <^^ &06>节点再按 i 属性排序。 这样的查询入例 27所示、 其中 _descOrder=" name A @ip"表达了这个排序要求。 例 43显示了排序的结 果。
例 27: 按指定节点值降序输出元素:
<filter type="advancedSubtree">
<netconf xmlns="urn:ietf:params:xml:ns:netconf:base: 1.0">
<routing>
<interface
xmlns="urn:bupt :pris: riser : agent: module: interface: 1.0"
_descOrder="name A @ip"/>
</routing>
</netconf>
</filter>
例 28: 例 27的过滤结果如下所示:
<netconf xmlns="urn:ietf:params:xml:ns:netconf:base: 1.0"
xmlns: if="urn:bupt:pris :priser: agent: module: interface: 1.0" xmlns:mt="urn:bupt:pris:priser:agent:module:monitor: 1.0" > <routing>
<if: interface name="Ethernet2" ip-address=,, 59.64.139.69"> <if :name>Ethernet2</if: name>
</if:interface>
<if: interface name=" Ethernet 1" ip-address=" 59.64.139.65"> <if :name>Ethernet 1 </if : name>
</if:interface>
</routing>
</netconf>
由于对同一个过滤器节点可能得到许多相同结构、 相同内容的子树, 所 以可以在排序子树根节点处设定属 ¾_merge来实现相同子树的合并。 该属性 的取值为: true 或 false。 _merge= "true" ,则表示对过滤结果进行相同子树 合并后再返回; 当_1116 6= "false" , 表示对过滤结果不进行子树合并, 属性 —merge的默认值是,, false" 。
假设数据模型中<11^ 06>节点不具有任何属性, 那么将对于下述报文: 例 29: 未使用合并的过滤器:
<filter type="advancedSubtree">
<netconf xmlns="urn:ietf:params:xml:ns:netconf:base: 1.0"> <routing>
<interface
xmlns="urn:bupt:pris:priser:agent:module:interface: 1.0" _show="self 7>
</routing>
</netconf>
</filter>
例 30: 未使用合并的过滤结果:
<netconf xmlns="urn:ietf:params:xml:ns:netconf:base: 1.0"
xmlns: if="urn:bupt:pris :priser: agent: module: interface: 1.0" xmlns:mt="urn:bupt:pris:priser:agent:module:monitor: 1.0" >
<routing>
<if: interfaced
<if: interfaced
</routing> </netconf>
此时用户实际上只想知道数据模型中是否 interface节点的存在而不关心 其他。 如果使用 _merge属性 , <^^ &06>节点修改为:
<interface xmlns="urn:bupt: pris: priser: agent: module: interface: 1.0" _show= "self _merge=" true" />
过滤结果如例 31所示。
例 31 : 合并后的过滤结果:
<netconf xmlns="urn:ietf:params:xml:ns:netconf:base: 1.0"
xmlns: if="urn:bupt:pris :priser: agent: module: interface: 1.0" xmlns:mt="urn:bupt:pris:priser:agent:module:monitor: 1.0" > <routing>
<if: interfaced
</routing>
</netconf>
多个相同的<^^ &06>节点 (或者说子树)中压缩只输出一个, 这在数据 模型中具有大量同名节点的情况下, 可能会避免大量冗余信息在管理网络中 传输的弊病。
综上, 本发明扩展功能的定义规范总结如表 1所示:
表 1 子树过滤功能定义
Figure imgf000027_0001
对于节点的路径 严格按绝对路径 absolute
匹配。 属性默认 为<6^! 节点
路径匹配 nodepath 值
扩展新属性
对于节点的路径 relative 不按绝对路径匹 酉己
多个内容匹配节 must 点间是 "与"的关 系。 属性默认值 内容匹配 多个内容匹配节 为内容匹配节
节点的逻 matchType may 点间是 "或"的关 点扩展新属性
辑关系 系
对属性所在的内 not 容匹配节点执行
"非"运算 该节点的属性的逻
为执行属性过 被过滤出的节点 属性间逻 辑表达式, 逻辑运
滤的节点扩展 attrLogic 的属性应满足该 辑关系 算符包括: Λ、 ||、 !、
新属性 逻辑表达式
(、 )
被过滤出的节点 名字空间前缀的逻
命名空间 为元素类型节 应属于逻辑表达
— nsLogic 辑表达式, 逻辑运
逻辑关系 点扩展新属性 式所指示的名字 算符包括: II
空间
命名空间 无子节点或其子节 查询子树归属的 扩展新元素 < xmlns>
查询 点为一子树 命名空间
仅仅输出该属性 self
为选择节点和 所在节点自身 后代输出
包含节点扩展 show 输出该属性所在 控制
新属性 descendant 节点的自身及后 代。 属性默认值 查询满足过滤条 true 件的某节点的个 为元素类型节 数
—count
点扩展新属性 查询满足过滤条 false 件的某节点的内 个数查询
容。 属性默认值 为<(^ &>元素的 为查询应答结 节点的个数, 为正 子元素, 携带匹
< countNum>
果扩展新元素 整数 配节点的个数 数值节点值大于
morethan 数值
某数值 数值节点值小于 为数值数据类 lessthan 数值
数值范围 某数值
型的元素扩展
过滤 数值节点值小于 新属性 notmorethan 数值
等于某数值 数值节点值大于 notlessthan 数值
等于某数值 符合时间规范表达 超前于某设定时 timebefore
的字符串 间
符合时间规范表达 滞后于某设定时 为时间数据类 timeafter
时间范围 的字符串 间
型的元素扩展
过滤 符合时间规范表达 等于或滞后于某 新属性 timenotbefore
的字符串 设定时间 符合时间规范表达 等于或超前于某 timenotafter
的字符串 设定时间 所在节点的某些后
按属性所在节点 ascOrder 代节点的名字, 以
升序排列 为节点扩展新 与运算符号" Λ"连接
子树排序
属性 所在节点的某些后
按属性所在节点 descOrder 代节点的名字, 以
降序排列 与运算符号" Λ "连接
合并完全相同的 true
为节点扩展新 Τ点 子树合并 merge
属性 不合并完全相同
false
的节点 带有 "< >,, 表示该关键字以元素的形式存在; 不带有 "< >,, 而只带有 "_,,表示该关键字以属性的形式存在; 两者皆不带有表示该关键字以属性值 或节点值形式存在。
除此之外, 本发明对 NETCONF协议子树过滤机制中的以下处理情形进 行了修正:
1.舍弃不匹配节点的祖先
如果有下例过滤请求:
例 32: 不匹配节点的查询:
<filter type="subtree"> <netconf xmlns=" urn:ietf:params:xml:ns:netconf:base: 1.0">
<routing>
<interface name="Ethemet" xmlns="urn:bupt:pris:priser:agent:module:interface: 1.0"/>
<routing/>
<netconf/>
</filter>
而数据模型中没有一个属性 name值为 Ethernet的 interface节点。那么在 NETCONF协议子树过滤机制中, NETCONF协议中得到的过滤结果如下: 例 33 : NETCONF协议中对不匹配节点的过滤结果:
<data>
<netconf xmlns="urn:ietf:params:xml:ns:netconf:base: 1.0"
xmlns: if="urn:bupt:pris :priser: agent: module: interface: 1.0" xmlns:mt="urn:bupt:pris:priser:agent:module:monitor: 1.0" > <routing/>
</netconf>
</data>
由于数据模型中, 不存在匹配的 interface节点, 故而不输出 interface节 点, 但返回其祖先 routing和 netconf.。 对于用户来说, 过滤结果含义表达并 不明确, 也带来了无用的冗余信息。
本发明中, 当所有需要匹配的节点没有匹配数据模型节点, 因而全部被 舍弃时,这些节点的父节点也不返回。因而例 32的过滤会返回空的过滤结果:
<data></data>
2.命名空间过滤
由于 NETCONF协议中的子树过滤机制将具有相同父节点的节点 (即兄 弟节点集合) 集中在一起进行处理, 从根节点到叶子节点。 因此一旦匹配失 败, 会将不匹配节点和其所有子节点全部删除。 例如在 NETCONF协议中下 述过滤请求: 例 34: NETCONF协议中命名空间过滤:
<filter type="subtree">
<netconf xmlns=" urn:bupt:pris:priser:agent:module:interface: 1.0"/> </filter>
处理根节点 netconf时, 节点的名字匹配, 但命名空间不匹配, 于是丢弃 netconf节点, 从而得到空过滤结果:
例 35 : NETCONF协议中命名空间过滤结果:
<data></data>
而本发明实施例中, 当出现节点的命名空间不匹配时, 仍然继续处理其 子节点, 因为可能存在其后代与给定的命名空间匹配。 同时由于要保证过滤 结果的层次关系仍然有效, 故也可能保留命名空间不匹配的元素作为其他节 点的路径。 用户可以从过滤结果中很清楚的分辨出这些带有其他命名空间的 元素。
例 36: 例 34在子树过滤功能扩展中得到的过滤结果如下:
<netconf xmlns="urn:ietf:params:xml:ns:netconf:base: 1.0"
xmlns: if="urn:bupt:pris :priser: agent: module: interface: 1.0" xmlns:mt="urn:bupt:pris:priser:agent:module:monitor: 1.0" > <routing>
<if: interface name=" Ethernet 1" ip-address=" 59.64.139.65">
</if:interface>
<if: interface name="Ethernet2" ip-address=" 59.64.139.69">
</if:interface>
</routing>
</netconf>
实现这种机制后, 可以很容易的查找文档内或某节点下所有属于某命名 空间的元素。 1"列^口查句命名空间 urn:bupt:pris:priser:agent:module:interface: 1.0 中的元素, 直接将该命名空间作为过滤器中根节点的命名空间, 虽然在数据 模型中该命名空间与根节点的命名空间不同。
本发明实施例提供一套基于并对 NETCONF协议中子树过滤机制加以扩 展的, 实现对 XML语言定义的网络管理信息模型的数据查询和数据过滤功 能的处理系统。 处理系统详细说明了系统实施的总体结构和结构中每个模块 的具体功能。
图 2是本发明实施例中 NETCONF协议中子树过滤系统结构图, 如图 2 所示, 本发明扩展后的 NETCONF子树过滤系统主要体系架构包括过滤控制 模块、 报文设置模块、 名字空间处理模块、 相对路径访问模块、 递归流程控 制模块、 节点功能处理模块和结果处理模块。
各模块的主要功能如下:
1.过滤控制模块 2010
过滤控制模块 2010是整个子树过滤部分的核心,为整个子树过滤过程提 供控制机制, 同时可以根据报文中的参数执行协议子树过滤和 XPath过滤操 作。 该模块解析 rpc报文中过滤相关部分, 并且根据报文的具体内容按顺序 调用其他模块完成相应功能, 相应模块功能处理完毕后需向其汇报处理结果 并由过滤控制模块 2010 决定如何进行下一步的操作。 在获取初始过滤结果 后, 如果报文中有对过滤结果进行处理的要求, 此模块即调用结果处理模块 2070对初始过滤结果进行处理, 获得最终过滤结果并返回。
2.报文设置模块 2020
即 rpc报文, rpc报文中包含过滤控制模块 2010所需的过滤信息, 过滤 控制模块 2010首先判断 rpc报文的正确性, 如果正确则根据报文的信息设置 具体的参数, 包括过滤类型 (子树过滤、 扩展子树过滤、 Xpath )和在扩展子 树过滤中是否需要相对路径匹配。 并将结果返回给过滤控制模块 2010。
3.名字空间处理模块 2030
名字空间处理模块 2030用于处理与名字空间查询相关的操作请求,例如 查询配置文档中所有节点的名字空间、 查询某个子树中所有节点的名字空间 等, 在实现中需要递归流程控制模块 2050和结果处理模块 2070的支持。 4.相对路径访问模块 2040
相对路径访问模块 2040用于当 rpc消息中给出的是节点的相对路径时, 对配置文档进行过滤。 因此避免了在协议中的条件下必须给出节点完整路径 的限制, 可以在不给出节点完整路径的情况下进行过滤。 主要功能是为递归 流程控制模块 2050找到合适的配置文档节点作为参数。
5.递归流程控制模块 2050
将配置文档由顶层到底层划分, 一次处理过滤器中一群兄弟节点, 将其 分为容器节点、 选择节点、 内容匹配节点进行相关处理; 每当添加节点到过 滤结果时, 对其进行节点功能处理。
6.节点功能处理模块 2060
节点功能处理模块 2060 包括: 模糊匹配模块 2061、 节点数量查询模块 2062、 数值范围查询模块 2063、 时间范围查询模块 2064和逻辑关系组合模 块 2065 , 用于在进行过滤时对过滤器文档中的节点和数据模型中的节点的判 断比较, 并给出判断结果。
7.结果处理模块 2070
结果处理模块 2070 是对过滤结果进行操作, 具体包括报文封装模块 2071、 节点排序模块 2072和节点合并模块 2073。 当过滤器为名字空间过滤 时, 结果处理模块 2070需要对过滤结果进行封装, 将所有的名字空间封装成 xml 的格式返回。 当过滤器报文中要求对过滤结果进行排序时, 结果处理部 分根据排序的关键字对初始结果进行处理, 获得排序后的结果并提交给过滤 控制模块 2010。 节点合并用于对初始过滤结果中相同子树的合并。
本发明实施例提供一套基于并对 NETCONF协议中子树过滤机制加以扩 展的, 实现对 XML语言定义的网络管理信息模型的数据查询和数据过滤功 能的处理方法。 该处理方法包括扩展后的 NETCONF子树过滤实施的总体流 程和具体模块的佯细流程图。
图 3是本发明实施例中总体流程图, 主要包括报文检错、 根据关键字设 置运行参数、 之后将给出的过滤器对设备(Agent )本地保留的数据模型进行 过滤, 遇到节点调用节点处理模块, 待所有节点处理完毕后, 对过滤结果做 进一步处理, 具体包括以下步骤:
步骤 3010, 开始;
步驟 3020, 解析 rpc报文;
步骤 3030, 判断 rpc报文设置是否正确, 如果正确则转步骤 3050, 如果 不正确则转步骤 3040;
步骤 3040, 报错, 转步骤 3110;
步骤 3050, 判断关键字, 以确定是命名空间过滤, 还是跨层次访问; 如 果是命名空间过滤, 则转步骤 3060, 如果是跨层次访问, 则转步骤 3070; 步驟 3060, 调用命名空间过滤, 转步骤 3080;
步驟 3070, 调用跨层次过滤, 转步骤 3080;
步骤 3080 , 调用递归流程控制;
步驟 3090 , 调用节点功能处理;
步驟 3100, 根据关键字, 对过滤结果进行处理;
步骤 31 10, 结束。
1.过滤控制
过滤控制模块是整个子树过滤流程的管理者,它调用其他组件完成工作, 并接收其他组件工作的结果来决定下一步的工作内容。 图 4是本发明实施例 中过滤控制模块工作流程图, 如图 4所示, 包括以下步骤:
步骤 4010, 调用图 2中的报文设置模块;
步骤 4020,判断是否采用扩展子树过滤,如果是则转步驟 4030,如果否, 则判断查询对象类型是否为不同配置数据存储中的配置数据, 如果是则执行 步骤 4021采用 Xpath过滤, 如果否, 则执行步骤 4022判断查询对象类型是 否为当前正在运行的配置和状态数据, 如果是, 则釆用协议子树过滤;
步骤 4030 , 根据 rpc报文判断报文的正确性, 如果正确则转步骤 4060 , 否则转步骤 4100;
步骤 4060, 进行名字空间查询, 如果查到, 则转步骤 4070, 否则, 转步 骤 4072;
步骤 4070, 调用名字空间处理模块, 转步骤 4080; 步骤 4072, 根据关键字判断是否采用跨层次过滤, 如果是, 则转步骤 4075 , 否则转步骤 4080;
步驟 4075 , 调用跨层次过滤模块, 转步骤 4080;
步骤 4080, 调用递归流程控制模块, 开始进行子树过滤, 转步骤 4090; 步骤 4090, 对过滤结果进行相关处理, 转步骤 4100;
步骤 4100, 将操作结果封装报文返回给相关操作。
2.名字空间处理
当 filter的根节点为 <_xmlns>时, 过滤控制调用名字空间处理组件, 声明 其报文仅是名字空间的过滤条件。 返回结果只包含名字空间的信息。 图 5是 本发明实施例中过滤-控制调用名字空间处理组件流程图, 如图 5所示, 包括 以下步骤:
步驟 5001 , 获取报文定义中<_ 1^1½>元素的子节点;
步驟 5010, 判断是否<_ ]^118>无子节点, 如果是, 则转步骤 5020, 否则 转步骤 5030;
步骤 5020, 将配置文档整体作为过滤初始结果, 转步驟 5040;
步骤 5030, 执行子树过滤递归;
步骤 5040, 获得节点的命名空间插入集合;
步驟 5050, 判断是否所有节点获取完毕, 如果是, 则转步骤 5060, 否则 转步骤 5030。
步骤 5060, 封装获取内容返回给过滤控制模块。
3.递归流程控制
递归流程控制与协议中实现方法基本类似, 图 6是本发明实施例中递归 流程控制流程图, 如图 6所示, 包括以下步骤:
步骤 6001 , 解析报文设置该节点的操作参数;
步驟 6010, 节点判断本身信息是否匹配, 如果匹配, 则转步驟 6020, 如 果不匹配, 则转步骤 6015; 其中, 节点本身的信息包括节点类型、 节点名字、 节点属性、 节点名字空间等, 节点属性和节点名字空间可能有多种逻辑关系; 步骤 6015 , 该节点判断是否有相对路径, 如果有则转步骤 6017; 步驟 6017, 寻找相对路径上合适的节点, 转步骤 6090;
步骤 6020 , 该节点判断与内容匹配节点是否匹配, 如果是, 则转步骤 6030, 否则, 转步骤 6100; 其中, 内容匹配节点包括具有文本值的节点和具 有数据范围等其他条件的节点, 同样可能会存在多种逻辑关系, 并可能存在 扩展查询子句;
步骤 6030, 创建符合要求的当前节点副本, 进入步骤 6040;
步骤 6040, 在过滤结果中添加内容匹配节点, 进入步骤 6050;
步骤 6050, 处理选择节点, 选择节点包括过滤器中不含子节点的节点及 子节点为内置关键字如<_ 111«>等。 如果选择节点设定为不显示其子孙, 则 只复制本身; 如果设定为不显示祖先, 则将选择节点复制到结果根节点下; 进入步骤 6060
步驟 6060, 获取容器节点列表;
步驟 6070 , 判断容器节点和选择节点是否都为空, 如果是, 则转步骤 6080, 否则, 转步驟 6090;
步骤 6080, 将其它节点复制到当前节点副本下, 转步驟 6100;
步骤 6090, 递归调用处理容器节点, 转步骤 6100;
步骤 6100, 退出当前流程, 返回上一级递归; 返回结果包括符合过滤条 件的当前节点及其子孙, 同时也包括由于保留其他节点而必须保留的部分不 符合过滤条件的节点, 不包括对用户来说没有意义的节点。
4.节点功能处理
节点功能处理模块接受递归流程控制的调用, 实现针对单个节点的处理 功能。 该节点功能处理模块从过滤器定义中某一个节点出发, 保留配置文档 中符合该节点代表的过滤条件的节点, 并根据其表述的要求对保留的配置文 档节点故一些处理。
该节点功能处理模块的功能包括: 节点的匹配、 选择文本内容为特定数 值的节点、 选择文本内容为特定时间的节点、 子节点个数查询、 属性及命名 空间或与非逻辑的运算, 查找与当前节点相似但是路径不完全的配置文档节 点。 该节点功能处理模块接受递归控制部分传递的参数, 进行相应的处理, 并且将处理结果返回给递归控制模块。
主要实现方法如下:
( 1 )模糊匹配:
判断配置文档和过滤器文档中两个节点的属性是否模糊匹配。 首先将文 本节点的内容进行适当预处理, 然后根据正则表达式进行判断是否匹配。
( 2 ) 选择文本内容为特定数值范围的节点:
首先判断文本内容是否可以转换成数值类型 , 若是则继续判断数值是否 在指定的数值范围内, 数值范围的判断包括 4个部分: 大于、 小于、 不大于 和不小于。
( 3 ) 选择文本内容为特定时间范围的节点:
首先判断文本内容是否可以转换成表示时间的数据, 若是则继续判断数 据是否在指定的时间范围内, 时间范围的判断包括 4个部分: 早于、 晚于、 不早于和不晚于指定的时间。
( 4 ) 子节点个数查询:
设置节点计数器, 当寻找到匹配节点时, 计数器加 1 ; 将节点划归到过 滤结果文档时只复制节点本身及其个数。
( 5 ) 查找与当前节点相似但是路径不完全的配置文档节点:
根据节点部分特性在当前节点后代中查找节点,并与当前节点进行匹配, 供相对路径功能模块使用。
( 6 )属性、 命名空间逻辑关系:
首先确定过滤器中给出的各命名空间、 属性, 配置文档节点是否符合。 以 true或 false表示。 然后计算布尔类型表达式的值。
5.结果处理模块实现以下功能:
报文封装: 报文封装主要是将过滤结果根据过滤控制中设置的参数封装 为适当的报文格式发回给过滤控制;
节点合并: 合并具有相同结构的过滤结果;
节点排序: 对过滤结果根据给定节点的值进行排序, 并将排序后的结果 返回。 图 7是本发明实施例中结果处理实现流程图, 如图 7所示, 结果处理 的基本流程包括以下步驟:
步驟 7010, 判断过滤器是否为空, 如果是, 则转步驟 7020;
步骤 7020, 拷贝整个配置文档;
步骤 7030, 判断是否进行命名空间查询, 如果是, 则转步骤 7040; 步骤 7040 , 检索命名空间和前缀;
步骤 7050, 进行节点排序或进行节点合并;
步骤 7060, 封装报文返回。
本发明实施例一,
假设设备端管理的数据模型如例 37所示。
例 37: 设备端管理的数据模型
<netconf xmlns="urn:ietf:params:xml:ns:netconf:base: 1.0"
xmlns:mt="urn:bupt:pris:priser:agent:module:monitor: 1.0" xmlns: if="urn:bupt:pris :priser: agent: module: interface: 1.0"> <routing>
<if: interface name="Ethternetl" ip="59.64.139.65">
<if :name>Ethernet 1 </if : name>
<if:mac-address>0006GG93KAG8</if:mac-address> <if:ipv4>
<if:address-v4>59.64.139.65</if:address-v4> <if: flags up="true"/>
< if:received>19< /if:received>
</if:ipv4>
</if:interface>
<if: interface name="Ethternet2" ip="59.64.139.69">
<if :name>Ethernet2</if: name>
<if:mac-address>000E35A83K4K</if:mac-address> <if:ipv4> <if:address-v4>59.64.139.69</if:address-v4>
<if: flags up="false"/>
< if:received>49< /if:received>
</if:ipv4>
</if:interface>
</routing>
<mt:monitor>
<mt : configuration>running- state</ mt :configuration>
<mt: configuration>startup-config</mt:configuration>
<mt :configuration>running-config</mt: configuration
<if: configuration>http ://pri s . bupt . cn/examp le/</if: configuration </mt:monitor>
</netconf>
现对其进行查询, 过滤器定义如下
例 38: 实施例过滤器定义:
<filter type="advancedSubtree" _nodepath="relative">
<if: interface name="Ethtemetl " ip="59.64.139.65"_attrLogic=" ( name A ip ) II ( !name A !ip ) "
xmlns: if="* interface* "/>
<_ —count = true/>
</if:interface>
<mt: monitor xmlns: mt=" * monitor: 1.0">
configuration _nsLogic="if | mt" _order="asc"/>
</mt:monitor>
</filter>
当 get/get-config操作发现操作报文中含有 filter节点,将之交给图 2中过 滤控制模块, 该模块调用图 2中参数设置功能模块, 由 filter的属性 type=" advancedSubtree" 得知需要进行子树过滤扩展功能操作, 并解析到需要相对 路径匹配, 将参数 _nodepath送给流程控制开始扩展子树过滤操作。 如图 4中 步驟 4020所示。
过滤器的定义主要流程如下:
操作开始前进行报文检查, 没有发现语法错误。
没有找到 <_xmlns>元素, 认为非命名空间查询后。
将 filter第一个子节点 interface与数据模型根节点 netconf 匹配。 由于名 字不同, 匹配失败。
由于是非绝对路径, 因此在 netconf节点的后代中寻找到与 interface匹配 ό 节 、: <if: interface name="Ethtemetl " ip="59.64.139.65"\>与 <if:interface name="Ethtemet2" ip="59.64.139.69"\>。
查找匹配节点时, 涉及到属性的逻辑关系组合过滤条件。 name="Ethtemet l" ip="59.64.139.65 "_attrLogic=" ( name A ip ) | ( !name A !ip ) "表示, 过滤结果中 interface节点要么 name和 ip均满足给定条件, 要么均不 满足。 匹配中 , 对于数据模型节点 <if :interface name="Ethternetl" ip="59.64.139.65">, name 属性条件满足, ip 属性条件也满足。 则_&« (^ 引出的表达式的匹配结果为: ( true Λ true ) || ( false A false ) =true, 即该数 据模型节点满足属性的逻辑关系过滤条件。类似的, routing下另一个 interface 节点同样满足。
查 找 匹 配 节 点 时 , 涉 及 到 命名 空 间 的 模糊 匹 配 。 urn:bupt:pris:priser:agent:module:interface: 1.0含有 interface字符串 ,能够匹配。
由于 <if:interface name="Ethtemetl" ip="59.64.139.65">节点和过滤器中的 interface 节点匹配, 则处理该节点的子节点, 这些子节点是兄弟节点, 同时 进行处理。
过滤器 interface节点下只有 <_>节点,且没有属性限制条件, 匹配任何命 名空间包含 interface字符串的元素类型节点。 故而 name、 mac-address, ipv4 节点均符合过滤条件。
<—>节点带有— count属性值为 true, 统计与 <_>节点匹配的数据模型节点 个数为 3。 从而实现统计 interface子节点个数的功能。 则过滤器子树:
<if: interface name="Ethtemetl " ip="59.64.139.65"_attrLogic=" ( name A ip ) II ( !name A !ip ) " xmlns: if=" * interface * "/>
<_count = true/>
</if:interface>
得到的过滤结果为:
<if: interface name="Ethternetl" ip="59.64.139.65">
<_countNum>3 <_countNum>
</if:interface>
<if: interface name="Ethternet2" ip="59.64.139.69">
<_countNum>3 <_countNum>
</if:interface>
将匹配节点和其祖先复制到过滤结果中。
处理过滤器中 interface的兄弟节点 monitor。
数据模型中 monitor的命名空间 urn: bupt: pris: riser: agent: module: interface: 1.0包含 monitor: 1.0字符串在末尾。 无其他匹配条件, mt: monitor节点匹配。
处理过滤-器 monitor节点的子节点 configuration。数据模型中 configuration 元素 ό 命名 空间有两种: urn:bupt:pris:priser:agent:module:monitor: 1.0 、 urn:bupt:pris:priser:agent:module:interface: 1.0 , 要 么 匹 酉己 mt 代表 的 ^monitor: 1.0 ,要么符合 if代表的 interface* ,数据模型中四个同父 configuration 节点均匹配。
则过滤器子树:
<mt: monitor xmlns: mt=" * monitor: 1.0">
<configuration _nsLogic="if | mt" _order="asc"/>
</mt:monitor>
得到的过滤结果为:
<mt:monitor>
<mt : configuration>running- state</ mt: configuration> <mt :configuration>startup-config</mt:configuration> <mt :configuration>running-config</mt: configuration>
<if:configuration>http://pris.bupt.cn/example/</if: configuration </mt:monitor>
将匹配节点和其祖先复制到过滤结果中。
过滤器中节点匹配完毕, 得到初始过滤结果:
<netconf xmlns="urn:ietf:params:xml:ns:netconf:base: 1.0"
xmlns:mt="urn:bupt:pris:priser:agent:module:monitor: 1.0"
xmlns: if="urn:bupt:pris :priser: agent: module: interface: 1.0">
<routing>
<if: interface name="Ethternet 1 " ip="59.64.139.65">
<_countNum>3 <_countNum>
</if:interface>
<if: interface name="Ethternet2" ip="59.64.139.69">
<_countNum>3 <_countNum>
</if:interface>
</routing>
<mt:monitor>
<mt : configuration>running- state</ mt: configuration>
<mt: configuration>startup-config</mt:configuration>
<mt :configuration>running-config</mt: configuration
<if: configuration>http ://pri s . bupt . cn/examp le/</if: configuration </mt:monitor>
</netconf>
对过滤器中 configuration节点得到的过滤结果进行排序。 文本内容不为 , 按升序 列。 则 monitor子才对变为:
<mt:monitor>
<if: configuration>http ://pris.bupt. cn/ example/</if: configuration <mt: configuration>running-config</mt: configuration
<mt: configuration>running-state</mt: configuration
<mt: configuration>startup-config</mt: configuration
</mt:monitor>
将排序后的过滤结果交给控制模块, 返回给上级操作。
最终得到的过滤结果如例 39所示。
例 39: 例 38的过滤结果:
<netconf xmlns="urn:ietf:params:xml:ns:netconf:base: 1.0"
xmlns:mt="urn:bupt:pris:priser:agent:module:monitor: 1.0" xmlns: if="urn:bupt:pris :priser: agent: module: interface: 1.0"> <routing>
<if: interface name="Ethternetl" ip="59.64.139.65">
<_countNum>3 <_countNum>
</if:interface>
<if: interface name="Ethternet2" ip="59.64.139.69">
<_countNum>3 <_countNum>
</if:interface>
</routing>
<mt:monitor>
<if : configuration>htt : //pris .bupt. cn/example/</if: conflguration> <mt:configuration>running-config</mt:configuration>
<mt:configuration>running-state</mt:conflguration>
<mt :configuration>startup-config</mt:configuration>
</mt:monitor>
</netconf>
图 8是本发明实施例二的基于子树过滤的模糊查询方法流程图, 如图 8 所示, 包括:
步骤 s801 , 接收待过滤数据流; 步驟 s802, 通过不完全匹配的方式过滤数据流, 处理用户没有给出完全 信息的字符串形式的过滤条件。
所述字符串包括: 节点名字、 节点内容、 属性名字、 属性值或命名空间; 所述不完全匹配的方式包括: 路径不完整; 元素名不完整、 元素值不完整、 属性名不完整、 属性值不完整、 命名空间不完整。
上述通过不完全匹配的方式过滤数据流, 具体为:
通过绝对路径过滤数据流; 或通过相对路径过滤数据流。
通过绝对路径过滤数据流具体为: 用户给出的过滤器包含被选择节点的 必须给出从根节点开始的所有祖先, 过滤结果中只包含在过滤器中的祖先和 在数据模型中的祖先完全一致的节点及节点后代;
通过相对路径过滤的数据流具体为:
在过滤器中满足父子关系的节点在过滤结果中至少满足祖先后代关系; 在过滤器中为根节点的节点在过滤结果中至少包括非根节点。
当出现节点的命名空间不匹配时, 继续处理前述节点的子节点, 保留命 名空间不匹配的元素作为其后代节点的路径。
本发明实施例增加子树过滤中命名空间的查询功能, 帮助用户快速了解 XML文档中数据分布的结构;弥补了 NETCONF协议子树过滤中必须给出命 名空间条件, 但又不提供完整手段实现命名空间查询的缺陷。
本发明实施例处理对某些数据的特殊查询需求, 比如时间、 日期、 数量 等的范围查询、 数据的数量查询等等。 使子树过滤更能满足实际网络管理或 其他实际应用中的需求。
本发明实施例实现对过滤结果的优化, 实现对相同或类似数据的合并或 排序; 在需要时, 丢弃无用的后代节点, 大大减少了子树过滤结果可能存在 的大量冗余信息。
图 9是本发明实施例三的子树过滤条件的逻辑组合的扩展方法流程图, 如图 9所示, 包括:
步驟 s901 , 接收待过滤数据流;
步骤 s902, 采用多个属性或多个内容匹配节点对该数据流中的元素类型 节点进行过滤。
步骤 s902中多个内容匹配节点对数据流中的元素类型节点进行过滤, 具 体为:
使用内容匹配节点作为从数据模型中选择特定的父节点的过滤条件; 通过在所述内容匹配节点中添加第一属性表示所述节点的匹配程度, 匹 配程度包括必须匹配、 可选匹配和不匹配;
根据所述内容匹配节点和所述匹配程度对所述数据流中的元素类型节点 进行过滤。
根据所述内容匹配节点和所述匹配程度对所述数据流中的元素类型节点 进行过滤, 具体为:
过滤器中所有匹配程度是必须匹配的内容匹配节点都与数据模型中相应 的元素类型节点完全匹配时, 其父节点才可以被添加到过滤结果中;
过滤器中可选匹配程度是可选匹配的内容匹配节点中至少有一个节点与 数据模型中相应的元素类型节点完全匹配时, 其父节点才可以被添加到过滤 结果中;
过滤器中匹配程度不匹配的内容匹配节点与数据模型中相应的元素类型 节点完全匹配时, 其父节点不被添加到过滤结果中。
另外, 可以通过向节点中添加第二属性, 体现该节点的多个属性间的逻 辑关系, 该第二属性为 _attrLogic属性。
上述多个内容匹配节点对数据流中的元素类型节点进行过滤的过程中还 包括: 进行命名空间查询, 进行命名空间查询具体为:
获取数据模型中命名空间的定义情况, 并给出命名空间的列表, 其中, 命名空间查询的关键字用一个元素表示。
上述多个内容匹配节点对数据流中的元素类型节点进行过滤的步驟中, 过滤条件中还包括范围条件, 该范围条件用于选择具有某些特定数值或者日 期范围的节点 , 在表示数量或时间的选择节点中添加表示属性范围或时间范 围的属性, 将该选择节点看作是表示时间或数量范围的内容匹配节点, 在过 滤处理时作为过滤条件。 本发明实施例增加子树过滤中命名空间的查询功能, 帮助用户快速的了 解 XML文档中数据分布的结构; 弥补了 NETCONF协议子树过滤中必须给 出命名空间条件 , 但又不提供完整手段实现命名空间查询的缺陷。
本发明实施例处理对某些数据的特殊查询需求, 比如时间、 日期、 数量 等的范围查询、 数据的数量查询等等。 使子树过滤更能满足实际网络管理或 其他实际应用中的需求。
本发明实施例实现对过滤结果的优化, 实现对相同或类似数据的合并或 排序; 在需要时, 丢弃无用的后代节点, 大大减少了子树过滤结果可能存在 的大量冗余信息。
图 10是本发明实施例四的子树过滤查询结果的处理方法实现流程图,如 图 10所示, 包括:
步驟 slOOl ,在过滤器中相应节点处设置第三属性的值,表明该节点处是 否显示节点后代, 该第三属性为 _show属性;
步驟 sl002, 该第三属性的取值为: 第一值或者第二值, 第一值为 self 值, 第二值为 descendant值, 当该第三属性默认为显示所有在同一命名空间 的后代, 则第三属性等于第二值; 当设置第三属性等于第一值, 则过滤结果 只输出该节点的信息, 不输出在同一命名空间的后代节点。
该处理方法还包括:
通过在过滤器中某元素类型节点中使用第四属性实现个数查询, 统计数 据模型中某一类元素的个数, 通过在过滤器中某元素类型节点中使用第四属 性实现个数查询,统计同一过滤器节点对应的元素个数。该第四属性为 _count 属性。
该第四属性的取值有两个: 第一值或第二值, 该第一值为 true, 第二值 为 false, 当设置第四属性值为第一值时, 则过滤结果输出查询实体的个数; 当设置第四属性为第二值时, 则过滤结果不输出查询实体的个数。
该处理方法还包括:
对同一个过滤器节点得到的过滤结果按照需要进行排序, 合并查询结果 中内容完全相同的节点。 该处理方法还包括:
当所有需要匹配的节点没有匹配数据模型节点, 全部被舍弃时, 不返回 上述节点的父节点。
本发明实施例增加子树过滤中命名空间的查询功能, 帮助用户快速的了 解 XML文档中数据分布的结构; 弥补了 NETCONF协议子树过滤中必须给 出命名空间条件, 但又不提供完整手段实现命名空间查询的缺陷。
本发明实施例处理对某些数据的特殊查询需求, 比如时间、 日期、 数量 等的范围查询、 数据的数量查询等等。 使子树过滤更能满足实际网络管理或 其他实际应用中的需求。
本发明实施例实现对过滤结果的优化, 实现对相同或类似数据的合并或 排序; 在需要时, 丟弃无用的后代节点, 大大减少了子树过滤结果可能存在 的大量冗余信息。
图 11是本发明实施例五的过滤器结构示意图, 如图 11所示, 包括: 接收模块 1110, 用于接收待过滤数据流;
过滤模块 1120, 用于通过不完全匹配的方式过滤该数据流, 处理用户没 有给出完全信息的字符串形式的过滤条件。
过滤模块 1120包括:
第一过滤子模块 1121, 用于通过绝对路径过滤该数据流; 和 /或, 第二过滤子模块 1122, 用于通过相对路径过滤所述数据流。
本发明实施例增加子树过滤中命名空间的查询功能, 帮助用户快速的了 解 XML文档中数据分布的结构; 弥补了 NETCONF协议子树过滤中必须给 出命名空间条件, 但又不提供完整手段实现命名空间查询的缺陷。
本发明实施例处理对某些数据的特殊查询需求, 比如时间、 日期、 数量 等的范围查询、 数据的数量查询等等。 使子树过滤更能满足实际网络管理或 其他实际应用中的需求。
本发明实施例实现对过滤结果的优化, 实现对相同或类似数据的合并或 排序; 在需要时, 丟弃无用的后代节点, 大大减少了子树过滤结果可能存在 的大量冗余信息。 图 12是本发明实施例六的逻辑过滤装置结构示意图, 如图 12所示, 包 括:
接收模块 1210, 用于接收待过滤数据流;
逻辑过滤模块 1220, 用于采用多个属性或多个内容匹配节点对该数据流 中的元素类型节点进行过滤。
逻辑过滤模块 1220包括:
设置子模块 1221 , 用于设置内容匹配节点作为从数据模型中选择特定的 父节点的过滤条件;
添加子模块 1222, 用于通过在该内容匹配节点中添加第一属性表示该内 容匹配节点的匹配程度, 并实现该内容匹配节点过滤条件之间的逻辑关系组 合;
处理子模块 1223 , 用于根据该过滤条件之间的逻辑关系组合对该数据流 中的元素类型节点进行过滤。
本发明实施例增加子树过滤中命名空间的查询功能, 帮助用户快速的了 解 XML文档中数据分布的结构; 弥补了 NETCONF协议子树过滤中必须给 出命名空间条件, 但又不提供完整手段实现命名空间查询的缺陷。
本发明实施例处理对某些数据的特殊查询需求, 比如时间、 日期、 数量 等的范围查询、 数据的数量查询等等。 使子树过滤更能满足实际网络管理或 其他实际应用中的需求。
本发明实施例实现对过滤结果的优化, 实现对相同或类似数据的合并或 排序; 在需要时, 丟弃无用的后代节点, 大大减少了子树过滤结果可能存在 的大量冗余信息。
图 13是本发明实施例七的子树过滤查询结果处理装置结构示意图,如图 13所示, 包括:
设置模块 1310, 用于在过滤器中相应节点处设置第三属性的值, 该第三 属性为 _show属性;
确定模块 1320, 用于根据设置模块 1310设置第三属性的值, 表明所述 节点处是否显示节点后代。 该处理装置还包括:
排序模块 1330, 用于对同一个过滤器节点得到的过滤结果按照需要进行 排序,
节点合并模块 1340, 用于合并查询结果中内容完全相同的节点。
综上, 可以看到本发明可以实现以下 NETCONF协议中子树过滤机制无 法实现或实现效果不好或处理方法有缺陷的功能, 如表 2所示:
表 2扩展子树过滤机制实现附加功能
Figure imgf000049_0001
由表 2中可以看 1
本发明实施例提供一种基于 NETCONF子树过滤机制, 以 XML形式表 达的, 对 XML网络管理数据进行查询和过滤的方法, 使对 NETCONF协议 中管理信息的获取更为方便, 也避免了为数据查询和过滤重新定义一套规范 带来的诸多问题。
本发明实施例提供了一种对 XML数据过滤条件的细化和组合机制。 本 发明中细化了节点的匹配程度, 用户可以根据节点在数据存储中的具体作用 选择相应的查询方法。 另外, 属性、 命名空间方式表达的过滤条件可以以逻 辑运算方式组合到一起, 使查询更为灵活。
本发明实施例提供一种在过滤条件不完整的情况下, 比如不能完整拼写 出数据存储的节点或属性名字, 或者不能完全给出数据在 XML 文档中定义 的位置, 仍可以对 XML数据进行子树过滤操作, 并得到用户想要的结果。
本发明实施例增加子树过滤中命名空间的查询功能, 帮助用户快速的了 解 XML文档中数据分布的结构; 弥补了 NETCONF协议子树过滤中必须给 出命名空间条件, 但又不提供完整手段实现命名空间查询的缺陷。
本发明实施例处理对某些数据的特殊查询需求, 比如时间、 日期、 数量 等的范围查询、 数据的数量查询等等。 使子树过滤更能满足实际网络管理或 其他实际应用中的需求。
本发明实施例实现对过滤结果的优化, 实现对相同或类似数据的合并或 排序; 在需要的时候, 丢弃无用的后代节点。 大大减少了子树过滤结果可能 存在的大量冗余信息。
通过以上的实施方式的描述, 本领域的技术人员可以清楚地了解到本发 明可以通过硬件实现, 也可以借助软件加必要的通用硬件平台的方式来实现 基于这样的理解, 本发明的技术方案可以以软件产品的形式体现出来, 该软 件产品可以存储在一个非易失性存储介质 (可以是 CD-ROM, U盘, 移动硬 盘等) 中, 包括若干指令用以使得一台计算机设备(可以是个人计算机, 服 务器, 或者网络设备等)执行本发明各个实施例所述的方法。
以上所述仅是本发明的优选实施方式, 应当指出, 对于本技术领域的普 通技术人员来说, 在不脱离本发明原理的前提下, 还可以做出若干改进和润 饰, 这些改进和润饰也应视为本发明的保护范围。

Claims

权 利 要 求
1、 一种基于子树过滤的模糊查询方法, 其特征在于, 包括:
接收待过滤数据流;
通过不完全匹配的方式过滤所述数据流, 处理用户没有给出完全信息的 字符串形式的过滤条件。
2、如权利要求 1所述的方法, 其特征在于, 所述字符串包括: 节点名字、 节点内容、 属性名字、 属性值或命名空间。
3、如权利要求 1所述的方法,其特征在于,所述不完全匹配的方式包括: 路径不完整; 元素名不完整、 元素值不完整、 属性名不完整、 属性值不完整、 命名空间不完整。
4、 如权利要求 1所述的方法, 其特征在于, 所述通过不完全匹配的方式 过滤所述数据流, 包括:
通过绝对路径过滤所述数据流; 或通过相对路径过滤所述数据流。
5、 如权利要求 4所述的方法, 其特征在于, 所述通过绝对路径过滤所述 数据流, 包括:
用户给出的过滤器包含被选择节点的从根节点开始的所有祖先, 过滤结 果中只包含在过滤器中的祖先和在数据模型中的祖先完全一致的节点及节点 后代。
6、 如权利要求 4所述的方法, 其特征在于, 所述通过相对路径过滤所述 数据流, 包括:
在过滤器中满足父子关系的节点在过滤结果中至少满足祖先后代关系; 在过滤器中为根节点的节点在过滤结果中至少包括非根节点。
7、 如权利要求 4所述的方法, 其特征在于, 还包括:
当出现节点的命名空间不匹配时, 继续处理所述节点的子节点, 保留命 名空间不匹配的元素作为其后代节点的路径。
8、 一种子树过滤条件的逻辑组合的扩展方法, 其特征在于, 包括: 接收待过滤数据流;
采用多个属性或多个内容匹配节点对所述数据流中的元素类型节点进行 过滤。
9、 如权利要求 8所述的方法, 其特征在于, 采用多个内容匹配节点对所 述数据流中的元素类型节点进行过滤, 包括:
使用内容匹配节点作为从数据模型中选择特定的父节点的过滤条件; 通过在所述内容匹配节点中添加第一属性表示所述内容匹配节点的匹配 程度, 匹配程度包括必须匹配、 可选匹配和不匹配;
根据所述内容匹配节点和所述匹配程度对所述数据流中的元素类型节点 进行过滤。
10、 如权利要求 9所述的方法, 其特征在于, 所述根据所述内容匹配节 点和所述匹配程度对所述数据流中的元素类型节点进行过滤, 包括:
过滤器中所有匹配程度是必须匹配的内容匹配节点都与数据模型中相应 的元素类型节点完全匹配时, 其父节点才可以被添加到过滤结果中;
过滤器中可选匹配程度是可选匹配的内容匹配节点中至少有一个节点与 数据模型中相应的元素类型节点完全匹配时, 其父节点才可以被添加到过滤 结果中;
过滤器中匹配程度不匹配的内容匹配节点与数据模型中相应的元素类型 节点完全匹配时, 其父节点不被添加到过滤结果中。
11、 如权利要求 8所述的方法, 其特征在于, 还包括:
向节点中添加第二属性, 以体现所述节点的多个属性间的逻辑关系。
12、 如权利要求 8所述的方法, 其特征在于, 还包括: 进行命名空间查 询:
获取数据模型中命名空间的定义情况, 并给出命名空间的列表, 其中, 命名空间查询的关键字用一个元素表示。
13、 如权利要求 9所述的方法, 其特征在于, 过滤条件中还包括范围条 件, 所述范围条件用于选择具有某些特定数值或者日期范围的节点, 在表示 数量或时间的选择节点中添加表示属性范围或时间范围的属性, 将该选择节 点看作是表示时间或数量范围的内容匹配节点,在过滤处理时作为过滤条件。
14、 一种子树过滤查询结果的处理方法, 其特征在于, 包括: 在过滤器中相应节点处设置第三属性的值, 表明所述节点处是否显示节 点后代;
所述第三属性的取值为第一值或者第二值, 当所述第三属性默认为显示 所有在同一命名空间的后代, 则第三属性等于第二值; 当设置第三属性等于 第一值, 则过滤结果只输出该节点的信息, 不输出在同一命名空间的后代节 点。
15、 如权利要求 14所述的方法, 其特征在于, 还包括:
通过在过滤器中某元素类型节点中使用第四属性实现个数查询, 统计数 据模型中某一类元素的个数。
16、 如权利要求 14所述的方法, 其特征在于, 还包括:
通过在过滤器中某元素类型节点中使用第四属性实现个数查询, 统计同 一过滤器节点对应的元素个数。
17、 如权利要求 15所述的方法, 其特征在于,
所述第四属性的取值有两个: 第一值或第二值, 当设置第四属性值为第 一值时, 则过滤结果输出查询实体的个数; 当设置第四属性为第二值时, 则 过滤结果不输出查询实体的个数。
18、 如权利要求 14所述的方法, 其特征在于, 还包括:
对同一个过滤器节点得到的过滤结果按照需要进行排序, 合并查询结果 中内容完全相同的节点。
19、 如权利要求 14所述的方法, 其特征在于, 还包括:
当所有需要匹配的节点没有匹配数据模型节点, 全部被舍弃时, 不返回 所述节点的父节点。
20、 一种过滤器, 其特征在于, 包括:
接收模块, 用于接收待过滤数据流;
过滤模块, 用于通过不完全匹配的方式过滤所述数据流, 处理用户没有 给出完全信息的字符串形式的过滤条件。
21、 如权利要求 20所述的过滤器, 其特征在于, 所述过滤模块包括: 第一过滤子模块, 用于通过绝对路径过滤所述数据流; 或者, 第二过滤子模块, 用于通过相对路径过滤所述数据流。
22、 一种逻辑过滤装置, 其特征在于, 包括:
接收模块, 用于接收待过滤数据流;
逻辑过滤模块, 用于采用多个属性或多个内容匹配节点对所述数据流中 的元素类型节点进行过滤。
23、 如权利要求 22所述的装置, 其特征在于, 所述逻辑过滤模块包括: 设置子模块, 用于设置内容匹配节点作为从数据模型中选择特定的父节 点的过滤条件;
添加子模块, 用于通过在所述内容匹配节点中添加第一属性表示所述内 容匹配节点的匹配程度, 并实现所述内容匹配节点过滤条件之间的逻辑关系 组合;
处理子模块, 用于根据所述过滤条件之间的逻辑关系组合对所述数据流 中的元素类型节点进行过滤。
24、 一种子树过滤查询结果处理装置, 其特征在于, 包括:
设置模块, 用于在过滤器中相应节点处设置第三属性的值;
确定模块, 用于根据所述设置模块设置所述第三属性的值, 表明所述节 点处是否显示节点后代。
25、 如权利要求 24所述的装置, 其特征在于, 还包括:
排序模块,用于对同一个过滤器节点得到的过滤结果按照需要进行排序, 节点合并模块, 用于合并查询结果中内容完全相同的节点。
PCT/CN2009/074132 2008-09-28 2009-09-23 模糊查询、查询结果处理和过滤条件处理的方法及设备 WO2010034237A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/073,667 US20110179047A1 (en) 2008-09-28 2011-03-28 Method and system for fuzzy searching, searching result processing, and filter condition processing

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN2008101669652A CN101686146B (zh) 2008-09-28 2008-09-28 模糊查询、查询结果处理和过滤条件处理的方法及设备
CN200810166965.2 2008-09-28

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/073,667 Continuation US20110179047A1 (en) 2008-09-28 2011-03-28 Method and system for fuzzy searching, searching result processing, and filter condition processing

Publications (1)

Publication Number Publication Date
WO2010034237A1 true WO2010034237A1 (zh) 2010-04-01

Family

ID=42049131

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2009/074132 WO2010034237A1 (zh) 2008-09-28 2009-09-23 模糊查询、查询结果处理和过滤条件处理的方法及设备

Country Status (3)

Country Link
US (1) US20110179047A1 (zh)
CN (1) CN101686146B (zh)
WO (1) WO2010034237A1 (zh)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9256593B2 (en) * 2012-11-28 2016-02-09 Wal-Mart Stores, Inc. Identifying product references in user-generated content
CN104079676A (zh) * 2013-03-27 2014-10-01 中国移动通信集团公司 一种云计算集群主机地址查询方法及设备
EP3084637A1 (en) * 2013-12-16 2016-10-26 Siemens Aktiengesellschaft Computer device for detecting correlations within data
CN105630838B (zh) * 2014-11-07 2019-03-26 北大方正集团有限公司 一种数据替换方法及系统
CN105824855B (zh) * 2015-01-09 2019-12-13 阿里巴巴集团控股有限公司 一种对数据对象筛选分类的方法、装置以及电子设备
CN105550968A (zh) * 2016-01-15 2016-05-04 中国民用航空总局第二研究所 航班加油调度控制系统、方法、发送及接收方法、装置
CN107870925B (zh) * 2016-09-26 2021-08-20 华为技术有限公司 一种字符串过滤方法和相关装置
CN106528651B (zh) * 2016-10-08 2019-04-30 温州大学 一种面向家庭数据库的模糊查询方法
CN108875087B (zh) * 2016-10-24 2021-09-21 北京亚控科技发展有限公司 一种描述事物空间属性并基于所述描述进行查找的方法
CN107391691A (zh) * 2017-07-26 2017-11-24 成都科来软件有限公司 一种网络分析中数据的过滤方法
CN107463711B (zh) * 2017-08-22 2020-07-28 山东浪潮云服务信息科技有限公司 一种数据的标签匹配方法及装置
CN110674387B (zh) * 2018-06-15 2023-09-22 伊姆西Ip控股有限责任公司 用于数据搜索的方法、装置和计算机存储介质
CN110968742A (zh) * 2018-09-30 2020-04-07 北京国双科技有限公司 数据过滤方法和装置
CN111488515A (zh) * 2019-01-25 2020-08-04 华为技术有限公司 信息查询方法、装置、设备及存储介质
EP3963474A4 (en) * 2019-05-01 2022-12-14 Microsoft Technology Licensing, LLC METHOD AND SYSTEM FOR USING UNSUPERVISED LEARNING TO IMPROVE TEXT ON SUGGESTED CONTENT
CN112395369A (zh) * 2020-11-20 2021-02-23 深圳市银众信息技术有限公司 一种基于物联网的智能终端数据控制方法、装置及系统
CN112685611A (zh) * 2020-12-31 2021-04-20 恒安嘉新(北京)科技股份公司 一种数据过滤方法、装置、存储介质及电子设备
CN112749180B (zh) * 2021-01-19 2023-06-23 上海复佳信息科技有限公司 数据管理方法、电子设备及计算机可读存储介质
CN117278660B (zh) * 2023-11-21 2024-03-29 华信咨询设计研究院有限公司 一种基于dpdk技术的流量过滤的协议解析方法
CN117909389B (zh) * 2024-03-19 2024-06-11 成都虚谷伟业科技有限公司 一种sql模糊查询方法、设备及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040153469A1 (en) * 2002-07-24 2004-08-05 Keith-Hill Roderic M. Database comparator
US20050050066A1 (en) * 2003-08-29 2005-03-03 Hughes Merlin P. D. Processing XML node sets

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US375164A (en) * 1887-12-20 Michael katzneb
US375847A (en) * 1888-01-03 Heney g
US6782380B1 (en) * 2000-04-14 2004-08-24 David Victor Thede Method and system for indexing and searching contents of extensible mark-up language (XML) documents
GB2397400A (en) * 2003-01-14 2004-07-21 Adam Raff Matching information over a network by comparing profile data between different terminals
US7120864B2 (en) * 2004-01-27 2006-10-10 International Business Machines Corporation Eliminating superfluous namespace declarations and undeclaring default namespaces in XML serialization processing
US7493338B2 (en) * 2004-08-10 2009-02-17 Palo Alto Research Center Incorporated Full-text search integration in XML database
CN101222468B (zh) * 2007-12-28 2010-08-04 华为技术有限公司 多载波正交频分复用系统中峰均比抑制的方法和装置

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040153469A1 (en) * 2002-07-24 2004-08-05 Keith-Hill Roderic M. Database comparator
US20050050066A1 (en) * 2003-08-29 2005-03-03 Hughes Merlin P. D. Processing XML node sets

Also Published As

Publication number Publication date
CN101686146B (zh) 2013-01-30
US20110179047A1 (en) 2011-07-21
CN101686146A (zh) 2010-03-31

Similar Documents

Publication Publication Date Title
WO2010034237A1 (zh) 模糊查询、查询结果处理和过滤条件处理的方法及设备
US6954778B2 (en) System and method for accessing directory service via an HTTP URL
US7398265B2 (en) Efficient query processing of XML data using XML index
US8762410B2 (en) Document level indexes for efficient processing in multiple tiers of a computer system
US6341277B1 (en) System and method for performance complex heterogeneous database queries using a single SQL expression
US7290049B2 (en) Management information to object mapping and correlator
US7440954B2 (en) Index maintenance for operations involving indexed XML data
US8572127B2 (en) Structure based storage, query, update and transfer of tree-based documents
US7493305B2 (en) Efficient queribility and manageability of an XML index with path subsetting
US5317742A (en) Dynamic translation of network management primitives to queries to a database
US20080281815A1 (en) Optimal storage and retrieval of xml data
JP4384247B2 (ja) 拡張可能マークアップ言語(xml)のための軽量なアプリケーションプログラムインターフェース(api)
US20060184551A1 (en) Mechanism for improving performance on XML over XML data using path subsetting
US8145641B2 (en) Managing feature data based on spatial collections
US9026533B2 (en) Method and apparatus for document matching
JP2014137820A (ja) データ記憶システム、データ記憶システムで実行されるプログラム及び方法
US20080092034A1 (en) Identifying and annotating shared hierarchical markup document trees
US20090138491A1 (en) Composite Tree Data Type
US7877400B1 (en) Optimizations of XPaths
Felber et al. Scalable filtering of XML data for Web services
JP4724177B2 (ja) Xmlデータにアクセスするためのインデックス
WO2022253047A1 (zh) 基于网络配置协议的查询信息的方法和装置
Park et al. Efficient schemes of executing star operators in XPath query expressions
Finance et al. Querying future telecommunication networks
Chen et al. Stored Procedures for Distributed XML Databases

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09815606

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09815606

Country of ref document: EP

Kind code of ref document: A1