Challenges and Experiences in Transitioning Management Instrumentation from Command-Oriented to Model-Driven - Advances in Network-Embedded Management and Applications - page 14

6 Conclusions
Management instrumentation designers are looking to shift their command-
oriented management instrumentation to model-driven in order to utilize the
benefits of these modern technologies but are daunted by the difficult
challenges that complicate such a transition. Features supported through
stovepipe CLI implementations and augmented with redundant and often only
partial, alternate management interfaces complicate the problem. The practice
of feature-specific/command-oriented implementations, while freeform in
construct, culminates in multiple and redundant request handling,
inconsistencies between management interfaces and differences across
product versions. Perhaps most significantly, it geometrically increases
maintenance requirements and costs due to duplicate and redundant code.
Designers considering a transition to a model-driven system will find this
impedance mismatch to be the most vexing problem.
In an ideal scenario, designers would like to leverage legacy code in the
model-driven system by deriving models directly from the legacy source
code, however this is seldom possible. The tight coupling of individual
management interfaces with manipulated instrumentation data and services
fundamentally blur the lines between the models they desire and the models
implicit within their implemented instrumentation. This makes model
derivation from legacy source an impractical proposition.
Experience has shown that neither reverse engineering nor model-
derivation met expectations, but rather integrating a legacy system as a
coexisting component was found to be the most desirable solution. Instead of
attempting a re-design or fully modeling a seasoned management
instrumentation system, the system itself was leveraged as an integrated
partner of the model-driven framework. This technique allowed the supply
and maintenance of existing features to the system while at the same time
promoted the development of new features and functionality within in the
model-driven framework.
The successful transition of a command-oriented system to a model-driven
management instrumentation framework supporting both management
interfaces and instrumentation involved the resolution of several key design
considerations surrounding API development. Management interfaces reside
above the middleware layer and exist in the management domain, requesting
instrumentation data and services from the middleware interface as clients.
Client services available from this interface are accessed in a manner
decoupled from the instrumentation implementation using functions that
provide well-known Create Read Update Delete and eXecute (CRUDx)