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

The construct of the middleware API does not depend upon the model,
however, the value of arguments passed are model-dependent. For example,
the URI arguments in the APIs identify the target object instance to create,
read, update, delete or execute. It may also identify a collection of object
instances as in the case of a Collection URI (COL-URI) for manipulation of a
collection of objects and data. The DataIn and DataOut arguments
signify the variant types of data that may be passed between the client and the
identified target object(s). The middleware API is illustrated below in pseudo
code.
errorcode create(URI);
errorcode readConfigData(DataOut, URI);
errorcode readOperationalData(DataOut, URI);
errorcode updateConfigData(DataIn, URI);
errorcode delete(URI);
errorcode execute(DataOut, DataIn, URI);
When the middleware receives a call across this interface, it resolves the
URI to the object instance and performs the associated Instrumentation API
call for the entity.
readOperationalData(long&
lRate,”/services;servicename=
/IFFlowMon/probes;id=/Q/flowRate”
);
The middleware resolves this information to a call to the instrumentation
API shown here in trivial pseudo code:
Q=get(”/services;servicename=/IFFlowMon/probes;id=
/Q”);
lRate=Q->readIntefaceFlowProb_flowRate(ErrorOut);
While most of the fine details of the middleware and instrumentation API
interactions have been excluded, the example illustrates the design choices
and resulting concepts of middleware and instrumentation API construction
from the instrumentation model.
5 Related Work
There is a great deal of work that has been done in the area of Model-Driven
Engineering (MDE) over the past three decades and was crystallized with the
formation of the Object Management Group (OMG) [10] in 2001. The OMG
was formed to establish modeling and model-based standards. Since that