Information Technology Reference
In-Depth Information
obtain hard-coded reports of configuration and operational data from specific
instrumented features is a challenging proposition. While seemingly model-
friendly data-oriented interfaces such as Simple Network Management
Protocol (SNMP) exist, these interfaces tend to be confined to data monitoring
rather than configuration, provide less functional coverage and are frequently
developed as distinctly separate and parallel instrumentation paths from their
command-oriented counterparts. Over time, this parallelism degrades the
quality, reliability and consistency of the system and complicates transitions
to a model-driven design.
Inconsistencies across interfaces are demonstrated when data and functions
are exposed in one management interface path but not others, like Command
Line Interfaces (CLI) providing instrumentation in one form while the same
instrumentation is supplied in an SNMP management interface in a different
form - or perhaps not at all.
Different and multiply redundant instrumentation results in different and
redundant request processing, inconsistent request handling, and duplicate
configuration synchronization and maintenance requirements. The handling
of a CLI instrumentation request, for example, involves certain parameter and
system state validation coupled with a specific response however; duplicate
constraint validation and default processing can result in inconsistent handling
and duplicate maintenance requirements. CLI has one instrumentation data
access method while SNMP has another. With duplicated instrumentation
access, in order to ensure consistency, quality and reliability, changes to
instrumentation data and data constraints, must be applied and tested in all
interfaces that access instrumentation. This burden is compounded as
instrumentation and management interfaces grow.
The introduction of modeling concepts into a system constructed around a
command-oriented paradigm will be met with difficulty, as there is a
significant impedance mismatch between them. Command-oriented
instrumentation uses specific management interface commands tailored for
particular features that access data and services directly. Conversely model-
driven instrumentation focuses on access to feature data and services through
a common abstract interface shared by all management interfaces. Modeled
instrumentation describes data and services for all management interfaces.
The primary transition problem to overcome is determining the origin of the
instrumentation model. One may utilize the characteristics of data and
services embedded within the command-oriented implementations; one may
create a model based on need and map implementation data and services to it.
The choice is hindered by the inherent impedance mismatch introduced by
multiple and inconsistent implementations of the command-oriented system
Search WWH ::
Custom Search