56 karl 1.2
57 */
58
59 /** @name Description of the CIMOM and WEBM
60
61 The Common Information Model Object Broker (often known as the CIM Information
62 manager or CIMOM) brokers CIM objects between a number of sources and
63 destinations. A CIM object should be a representation, or model, of
64 a managed resource, such as a printer, disk drive, or central processing unit
65 (CPU). In the Pegasus implementation, CIM objects are represented
66 internally as C++ classes. The CIMOM transfers information
67 between WBEM clients, the CIM Object Manager Repository, and managed
68 resources.
69
70 NOTE: We are very careful in the use of CIM and WBEM. These are terms defined
71 and controled by the DMTF and they have specific meanings both technically and
72 legally. Thus, the objects are CIM objects. However, the client is a WBEM
73 client because it uses the DMTF XML/HTTP specificaitons to transfer
74 information and that specification and CIM form WBEM.
75
76 When a WBEM client application accesses information about a managed
77 karl 1.2 resource, the CIM Object Manager contacts either the appropriate provider
78 for the CIM object that represents that managed resource or the CIM Object
79 Manager Repository. Providers are classes that communicate with managed
80 objects to retrieve data. If the requested data is not available from the CIM
81 Object manager Repository, the CIM Object Manager forwards the request to
82 the provider for that managed resource.
83
84 Using the Repository.
85
86 The provider dynamically retrieves the requested information, which is sent back to the requester. The CIM Object Manager Repository only contains static data. Classes that are handled by a provider must have a Provider qualifier that identifies the provider to contact for the class. When the CIM Object Manager receives a request for a class that has a Provider qualifier, it should route the request to the specified provider. If no provider is specified, it should route the request to the CIM Object Manager Repository.
87
88 When a WBEM client connects to a CIM Object Manager, it will get a handle to the CIM Object Manager. The client can then perform WBEM operations.using this reference. At startup, the CIM Object Manager should perform the following functions: Listen for RMI connections on RMI port 5987 and for XML/HTTP connections on HTTP.
89
90 NOTE: The current version of the CIMOM does not incorporate events. Therefore, this description is written around a CIMOM without events functionality.
91
92 Note - The listener for connections may not be the Object Manager; it could
93 be another entity that is performing the operation for the Object Manager.
94 This could be a servlet in a Web server. Conformant object managers are
95 required to support XML over HTTP - Pegasus is conformant.
96
97 The CIMOM accepts requests called WBEM Operations from the WBEM client. These operations are explicitly defined in the WBEM specification. They represent the operations possible on CIM objects (ex. create/modify/delete class/instance, etc.) During normal operations, the CIMOM performs the following for each operation request received:
98 karl 1.2 <UL>
99 <LI>Security checks to authenticate user login and authorization to
100 access the CIMOM information.
101 <LI>Syntactic and semantic checks of the CIM data operations to
102 ensure that they comply with the current version of the CIM
103 specification.
104 <LI>Route requests to the appropriate provider orthe Repository.
105 The CIMOM iteself does not serve as a Repository for CIM class definitions and instance data. Persistence is provided by the Repository; however, the contact point is the CIMOM. Thus, the Repository could be considered as an option except that the CIMIM is required to keep class information for all semantic and syntatic confirmation and therefore the class repository is a requirement of a working CIMOM, not an option.
106 <LI>Deliver data from providers and from the CIM Object Manager
107 Repository to the originating WBEM client application.
108 </UL>
109 The CIMOM should be a process that accepts requests for CIM
110 operations, as defined by the DMTF, and carries out these operations. The
111 Pegasus CIMOM runs as a daemon process that waits for requests.
112
113 <B>Authentication</B>
114
115 Before any requests can be made to the CIM Object Manager, an
116 authenticated session must be established.
117
118 NOTE:The current version of Pegasus does not
119 karl 1.2 have any authentication. However, it is planned for version 1.1.
120
121 An identifier for the user and optionally a role will be associated with the authenticated session. A role is a principal identity associated with the current session, in addition to the user identity. Systems that do not support roles can ignore them as described in the Security Interface. These can be maintained in an internal Hash map.
122
123 <B>Request Reception</B>
124
125 The CIMOM receives requests through CIM operations over HTTP. Each request will be associated with a session that is set up as part of the initial authentication exchange. Since the session has an associated user, each request automatically has a user associated with it. This should be useful for authorization checking for a given request. Once the request has been received, the appropriate components for handling the specific request will be invoked. The Pegasus implementation has methods for each of the major CIM operations over HTTP. Once the request is received, the appropriate method will be called..
126
127 <B>Authorization</B>
128
129 The default implementation is Access Control List (ACL) based. Access
130 control lists can be maintained per namespace or on a per namespace/user
131 basis. These lists will be maintained in the root/security namespace. The CIM
132 Object Manager will grant read or write permissions within a namespace
133 based on the access control list. Since CIM operations are done within the
134 context of a namespace, these ACLs will enforce rules on whether an
135 operation should be allowed. For operations that will ultimately be handled by
136 a provider, the appropriate provider can replace the authorization scheme.
137 This will allow providers to enforce finer grained control if desired. A
138 provider
139 can replace the default authorization checking scheme by implementing the
140 karl 1.2 Authorizable interface. If implemented, no calls are made to the CIM Object
141 Manager.
142
143 <B>Provider</B>
144
145 <B>Provider RegistrationB/B>
146
147 The Pegasus CIMOM enables developers to write providers, which serve dynamic information to the CIMOM (see Providers). Providers register themselves by specifying their location in a Provider qualifier. Providers can be set up on a class, property, or method basis. Providers can have one or more of the different provider types. The DMTF CIM specification allows the Provider qualifier to have an implementation specific interpretation. For Pegasus, the Provider qualifier constitutes the executable name of a provider executable implementing the provider functions for the class.
148
149
150 There are a number of conceptual interfaces that can be implemented by providers:
151 <UL>
152 <LI>InstanceProvider
153 <LI>MethodProvider
154 <LI>PropertyProvider
155 <LI>AssociatorProvider
156 </UL>
157 .
158 Each conceptual interface provides a subset of the WBEM Operations as follows:
159
160 NOTE: ATTN: Table defining the types vs. operations
161 karl 1.2
162 However
163
164 Providers should be loaded "on
165 demand" by the CIMOM. Classes and properties marked by the
166 provider qualifier will be an indication to the object manager that the
167 associated information is dynamic and must be obtained from the providers
168 rather than the repository. When the object manager determines that a
169 specific request needs dynamic data, provider should be
170 loaded and instantiated. Additionally, the "initialize" method of the Provider
171 will be invoked. There should be only a single instance of the provider.
172
173 ATTN: Review the following: In the reference implementation, the ProviderChecker maintains a hash map of all the providers. This will enable the CIM Object Manager to load a provider only if it has not been loaded previously. There should be no specified time when a provider can be "unloaded", however providers have a "cleanup" method that can be invoked if, and when, this behavior is specified for the object manager.
174
175 The CIM Object Manager will not act as as a provider for
176 classes. However, there are instances where classes must interact with the CIMOM itself. These might include authentication classes, authorization classes, namespace classes, and classes that provide information on the CIMOM iteslf.
177
178 These classes will be handled by providers but these will be specialized providers that have access back to the CIMOM itself. All of this is being defined as part of a services extension interface to PEGASUS. This interface will be discussed in a future version of this document:
179
180 ATTN: add the services interfaces.
181
182 karl 1.2
183
184
185 ATTN: Dealing with multiple providers per class.
186
187
188 <B>Request Routing</B>
189
190 One of the main functions of the CIMOM is operation request routing.
191 Depending on the request, the request may need to be authorized and passed to
192 semantic checkers, providers, and the repository.
193
194 Requests may be for static information such as schema
195 definitions or static instances. In this case, the CIMOM should
196 route the request to the proper repository.
197
198 The more complex routing will involve operations that can traverse multiple
199 classes and their instances. An example of such an operation is association
200 traversal. In order to determine the associated instances of a given input
201 instance, the CIMOM should first determine the associations
202 that the given instance class participates in. It will obtain this from the
203 karl 1.2 associations that have been compiled and stored in the repository. Once
204 these associations are determined, the CIM Object Manager should find
205 those instances of the associations in which the given input instance plays a
206 role. These associations may, or may not be, dynamic. Depending on
207 whether the associations are dynamic or not, the CIM Object Manager may
208 route the requests to providers or the repository. Once the results are
209 returned, they should be concatenated together and returned because of the
210 request. The CIM Object Manager will use schema information to determine
211 which providers to contact. As can be seen, a given request can result in
212 multiple sub-requests to the providers or the repository.
213 A similar situation will occur when a deep enumeration is performed on
214 instances of a class.
215
216 <B>Semantic Checking</B>
217
218 The CIMOM performs semantic checks before classes or
219 instances can be set or createdusing internal class,
220 property, instance, method, and qualifier checkers and the rules ov validation defined by the CIM specification. These verifiers ensure that the CIM rules are enforced. This includes type verification,type conversions, verification of proper key usage, and other checks.,
|
Return to
architecture.dxx
CVS log
Up to [Pegasus] / pegasus / doc / DevManual