|
|
PEP # ?:Supporting Dynamic Core Schema in Pegasus 2.2 |
| Type | Status | Approveers |
|---|---|---|
| Architecture | Draft | Pegasus architecture team |
| Version | Date | Author | Comments |
|---|---|---|---|
| 1.0 | Fri Feb 28 09:51:20 2003 | IBM/Mike Day | Design Proposal, to be extended with implementation details |
The premise of CIM/Wbem is to provide normalized access to heterogenous computing resources. This is a difficult technical to solve but the benefits are tremendous for writers of systems management software.
The ability of CIM/Wbem implementations to provide normalized access to heterogenous resources derives from the extensibility of the CIM meta schema, or modelling language. CIM models can be extended or revised dynamically. There is limited polymorphism built into the CIM Schema.
CIM/Wbem does not isolate program code from data model. Rather, it separates the access mechanism from the resource. This means, for example, that specific schema classes can be supported by custom source code. However, the CIM/Wbem infrastructure which includes the access protocol, schema repository, and operations, have no requirement to be aware of specific schema classes.
Most of Pegasus is implemented to take advantage of this separation of infrastructure from resource instrumentation. We can define new classes and provide instances of those classes dynamically without modifying any of the Pegasus source code.
However in some critical infrastructure components, Pegasus is hardcoded to support specific schema definitions and classes. Further, it is hardcoded to preclude schema extension for important portions of the CIM schema.
Schema components that are statically coded in Pegasus today include the Provider schema, the Indication Schema, and Authentication.
The static nature of the Provider, Indication, and Authentication schemas causes Pegasus to enforce behavior that is not the subject of any DMTF standards. For example, today only C++ providers are allowed, and the provider interface (which is not standardized) is statically hardcoded in Pegasus from the Schema to the dynamic library support for providers.
Other examples of non-standardized behavior that is enforced by hard-coded schema support in Pegasus include Indication Handling, Indication formats, and authentication options.