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

architectural differences between the existing command-oriented system and
the target model-driven system. Viewed by many as an inside out to outside
in transformation, there were two primary areas that stood out as the biggest
hurdles to overcome - instrumentation API development and Instrumentation
Modeling.

There was considerable effort devoted to developing automated tooling that
could minimize the development effort by leveraging existing command-
oriented source code to generate candidate instrumentation models and create
a basic instrumentation API implementation. In order to perform such a task,
the tooling was required to scan and interpret existing source code, derive
APIs and candidate models from embedded domain knowledge. These efforts
were unsuccessful. Resolution of run-time defined abstract function calls and
model semantics proved impractical due to interface complexities and
inconsistencies. The end solution was to not transition the command-oriented
code and functionality but instead to build a framework that utilized the
existing system for existing feature command requests while directing
requests for newly implemented functionality to the model-driven framework.
This allowed the management instrumentation system to maintain it's
backwards compatibility while at the same time allowing its functionality to
grow within the new model-driven paradigm. This coexistence allows
existing feature and functionality to be transitioned from the legacy
component to the model-driven framework on a piecemeal basis if desired.
Maintaining legacy functionality as a coexisting component within the model-
driven framework was found to be considerably more efficient, reliable and
practical than attempting a manual transition of its entire functional feature
set.

The second highest design hurdle was the construction and composition of
the Model Framework's APIs. There are two APIs to consider:

1. Middleware Interface API - communicates with management interfaces

such as the CLI, SNMP, Syslog and so forth.

2. Instrumentation API - Handles communication between the

instrumentation data/services and the Middleware Interface.

These APIs must be well considered in order to ensure they satisfy the
needs of their users. The Middleware Interface API communicates with
management interfaces to supply access to managed instrumentation data and
services without tight coupling to the particular kind of feature,
instrumentation, data or service being manipulated. A Create Read Update
Delete and eXecute (CRUDx) interface was selected to best satisfy the