Asynchronous Metadata Instrumentation via Unified Interface
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current network management systems face challenges in efficiently managing diverse assets across different types and protocols without requiring detailed knowledge of their application programming interfaces (APIs), leading to complexity and inefficiency in monitoring and managing network resources.
Innovation Solution
A method and system that abstract the application programming interface (API) from management data and functionality, using a data acquisition (DAQ) runtime and information model to manage assets through a common interface, allowing management applications to receive notifications and perform operations on assets without knowing the specific API, and enabling asynchronous notification support.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If a management application directly accesses the API of each resource to manage it, then the management application can obtain detailed control and information about the resource, but the management application must have detailed knowledge of each resource's specific API, increasing complexity
Solution Approach 1:
The patent introduces a management application programming interface (management API) as an intermediary layer between management applications and resource-specific APIs. This management API provides a standardized interface that abstracts away the diverse underlying resource APIs, allowing management applications to operate without detailed knowledge of specific resource interfaces while maintaining full control capabilities.
Solution Approach 2:
The management API is designed as a universal interface that can manage multiple types of resources (hardware, software, network devices) through a common set of operations. This multi-functional interface eliminates the need for separate management code for each resource type, reducing the complexity of management applications while maintaining broad applicability.
2Loss of information
If the system polls resources frequently to obtain management information, then up-to-date information is available, but system performance decreases due to constant polling overhead
Solution Approach 1:
The patent implements an event-driven architecture where resources generate asynchronous notifications when their state changes. This feedback mechanism allows the system to receive real-time updates about resource status without continuous polling, maintaining information timeliness while eliminating the performance overhead of frequent polling operations.
Solution Approach 2:
Instead of continuous or frequent periodic polling, the system transitions to event-triggered periodic action where information is retrieved only when necessary (i.e., when a state change occurs). This reduces the frequency of information acquisition operations from constant polling to conditional retrieval based on actual state changes.
3Adaptability or versatility
If the system integrates multiple asset types and protocols, then the system becomes more versatile, but the complexity of integrating new assets and protocols increases
Solution Approach 1:
The management API provides a universal interface that works across diverse asset types and communication protocols. By defining a common set of management operations and information models that apply to all assets, the system achieves versatility without requiring separate integration logic for each asset type, thereby reducing integration complexity.
Solution Approach 2:
The patent segments the management system into distinct layers: the management API layer provides standardized operations, while protocol-specific handlers manage the diversity of underlying protocols. This segmentation allows new assets and protocols to be integrated by implementing only the protocol-specific layer, without affecting the universal management API, thus reducing integration complexity.
4Reliability
If detailed framework code is written to handle specific asset types and protocols, then precise control is achieved, but the amount of framework code increases
Solution Approach 1:
The management API acts as an intermediary that provides precise control capabilities through a standardized interface. By handling protocol-specific details in separate protocol handlers rather than in the main framework code, the system achieves precise control over diverse assets while keeping the core framework code minimal and protocol-agnostic.
Solution Approach 2:
Instead of writing detailed control logic for each asset type in the main framework, the patent uses template-based information models and protocol handler templates that can be instantiated for different asset types. This copying approach allows precise control logic to be reused across multiple asset types without duplicating framework code.
Data Source
AI summary
A method for providing management information about an asset includes obtaining a job from a job queue, determining the asset type of the asset from the job, triggering a protocol handler based on a data acquisition (DAQ) definition associated with the asset type and the job, receiving management information about the asset from the protocol handler, identifying at least one registered listener of the management information from the DAQ definition, where at least one registered listener includes an information model class instance, and notifying the at least one registered listener of the management information.