1 mday 1.1.2.1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
2 <html>
3 <head>
4 <title>PEP # ?:Supporting Dynamic Core Schema in Pegasus 2.2</title>
5 <link rel="stylesheet" type="text/css" href="http://www.soft-hackle.net/md.css">
6 </head>
7
8 <body>
9 <body>
10 <table >
11 <tr>
12
13 <td>
14 <img height="70" src="http://www.opengroup.org/images/pegicon2.gif" width="70" border="0">
15 </td>
16 <td>
17 <h1>PEP # ?:Supporting Dynamic Core Schema in Pegasus 2.2</h1>
18 </td>
19 </tr>
20 </table>
21
22 mday 1.1.2.1 <table class="comment">
23 <tr align="left">
24 <th>Type</th><th>Status</th><th>Approveers</th>
25 </tr>
26 <tr>
27 <td>Architecture</td><td>Draft</td><td>Pegasus architecture team</td>
28 </tr>
29 </table>
30 <table class="comment">
31 <tr align="left">
32 <th>Version</th><th>Date</th><th>Author</th><th>Comments</th>
33 </tr>
34 <tr>
35 <td>1.0</td><td>Fri Feb 28 09:51:20 2003</td><td>IBM/Mike Day
36 </td><td><i>Design Proposal, to be extended with implementation details</i></td>
37 </tr>
38 </table>
39 <hr>
40
41 <h2>Summary</h2>
42
43 mday 1.1.2.1 <p>
44 The premise of CIM/Wbem is to provide normalized access to
45 heterogenous computing resources. This is a difficult
46 technical to solve but the benefits are tremendous for
47 writers of systems management software.
48 </p>
49
50 <p>
51 The ability of CIM/Wbem implementations to provide normalized
52 access to heterogenous resources derives from the
53 extensibility of the CIM meta schema, or modelling
54 language. CIM models can be extended or revised
55 dynamically. There is limited polymorphism built into the
56 CIM Schema.
57 </p>
58 <p>
59 CIM/Wbem does not isolate program code from data
60 model. Rather, it separates the access mechanism from the
61 resource. This means, for example, that specific schema
62 classes can be supported by custom source code. However, the
63 CIM/Wbem infrastructure which includes the access protocol,
64 mday 1.1.2.1 schema repository, and operations, have no requirement to be
65 aware of specific schema classes.
66 </p>
67
68 <p>
69 Most of Pegasus is implemented to take advantage of this
70 separation of infrastructure from resource
71 instrumentation. We can define new classes and provide
72 instances of those classes dynamically without modifying any
73 of the Pegasus source code.
74 </p>
75 <p>
76 However in some critical infrastructure components,
77 Pegasus is hardcoded to support specific schema definitions
78 and classes. Further, it is hardcoded to preclude schema
79 extension for important portions of the CIM schema.
80 </p>
81 <p>
82 Schema components that are statically coded in Pegasus today
83 include the Provider schema, the Indication Schema,
84 and Authentication.
85 mday 1.1.2.1 </p>
86 <p>
87 The static nature of the Provider, Indication, and
88 Authentication schemas causes Pegasus to enforce behavior
89 that is not the subject of any DMTF standards. For example, today
90 only C++ providers are allowed, and the provider interface
91 (which is not standardized) is statically hardcoded in
92 Pegasus from the Schema to the dynamic library support for providers.
93 </p>
94 <p>
95 Other examples of non-standardized behavior that is enforced
96 by hard-coded schema support in Pegasus include Indication
97 Handling, Indication formats, and authentication options.
98 </p>
99
100 <h2>Problem Solved/Feature Added</h2>
101 <p>
102
103 </p>
104
105
106 mday 1.1.2.1 <h2> Proposed schedule.</h2>
107
108 <h2>Risk Mitigation</h2>
109
110 <hr>
111 <address><a href="mailto:mdday@us.ibm.com">Michael Day</a></address>
112 <!-- Created: Fri Feb 28 09:49:31 EST 2003 -->
113 <!-- hhmts start -->
114 Last modified: Fri Feb 28 12:34:34 EST 2003
115 <!-- hhmts end -->
116 </body>
117 </html>
|
Return to
dynamic_schema.html
CVS log
Up to [Pegasus] / pegasus