1 karl  1.1.2.1 //%/////////////////////////////////////////////////////////////////////////////
  2               //
  3               // Copyright (c) 2000, 2001 BMC Software, Hewlett-Packard Company, IBM, 
  4               // The Open Group, Tivoli Systems
  5               //
  6               // Permission is hereby granted, free of charge, to any person obtaining a copy
  7               // of this software and associated documentation files (the "Software"), to 
  8               // deal in the Software without restriction, including without limitation the 
  9               // rights to use, copy, modify, merge, publish, distribute, sublicense, and/or 
 10               // sell copies of the Software, and to permit persons to whom the Software is
 11               // furnished to do so, subject to the following conditions:
 12               // 
 13               // THE ABOVE COPYRIGHT NOTICE AND THIS PERMISSION NOTICE SHALL BE INCLUDED IN 
 14               // ALL COPIES OR SUBSTANTIAL PORTIONS OF THE SOFTWARE. THE SOFTWARE IS PROVIDED
 15               // "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
 16               // LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR 
 17               // PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT 
 18               // HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN 
 19               // ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
 20               // WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 21               //
 22 karl  1.1.2.1 //==============================================================================
 23               /*
 24                   $Author:
 25               */
 26               
 27               /** @name Pegasus Architecture
 28               
 29               This section defines the overall architecture of the Pegasus implementation.
 30               
 31               */
 32               //@{
 33               /** @name Design Goals
 34               
 35               The Pegasus design team set some basic design goals early in the development of Pegasus as follows:
 36               <UL>
 37               <LI>C++ as the core development language. We selected C++ because it represented a compromise between the ability to work with objects and a language that would be acceptable for high avaailablity platforms.
 38               <LI>Modular Architecture - We wanted to be able to create the architecture based on well understand standardized modules that have clean well defined interfaces between the modules.
 39               <LI>Open to a wide range of specialization and customization.
 40               <LI>Minimize the functionality of the basic core CIMOM. We wanted to create an environment where the majority of customization could be created by working with attached modules that would both extend and modify the functionality of the broker.
 41               <LI>Use only open source components in the pegasus environment
 42               <LI>Design for maximum portability. The initial targets would be Linux, Unix, and NT but the product should be usable in a wide variety of platforms and platform sizes.
 43 karl  1.1.2.1 <LI>The APIs and interfaces should be clear, given that they are in C++
 44               <LI>
 45               </UL>
 46               */
 47               
 48                 
 49               /** @name The Broker
 50               
 51               The Common Information Model Object Broker (often known as the CIM Information
 52               manager or CIMOM) brokers CIM objects between a number of sources and
 53               destinations. A CIM object should be a representation, or model, of
 54               a managed resource, such as a printer, disk drive, or central processing unit
 55               (CPU). In the Pegasus implementation, CIM objects are represented
 56               internally as C++ classes. The CIMOM transfers information
 57               between WBEM clients, the CIM Object Manager Repository, and managed
 58               resources.
 59               
 60               */
 61               
 62               /** @name Pegasus Providers.
 63               ATTN: Define in more detail
 64 karl  1.1.2.1 
 65               */
 66               
 67               /** @name Extension Services
 68               ATTN: Document this as an architectural component
 69               */
 70               
 71               
 72               /** @name Pegasus Clients.
 73               ATTN: define in more detail
 74               
 75               */
 76               
 77               /** @name Functional Flow
 78               
 79               The Common Information Model Object Broker (often known as the CIM Information
 80               manager or CIMOM) brokers CIM objects between a number of sources and
 81               destinations. A CIM object should be a representation, or model, of
 82               a managed resource, such as a printer, disk drive, or central processing unit
 83               (CPU). In the Pegasus implementation, CIM objects are represented
 84               internally as C++ classes. The CIMOM transfers information
 85 karl  1.1.2.1 between WBEM clients, the CIM Object Manager Repository, and managed
 86               resources.
 87               
 88               NOTE: We are very careful in the use of CIM and WBEM.  These are terms defined
 89               and controled by the DMTF and they have specific meanings both technically and
 90               legally. Thus, the objects are CIM objects.  However, the client is a WBEM
 91               client because it uses the DMTF XML/HTTP specificaitons to transfer
 92               information and that specification and CIM form WBEM.
 93               
 94               When a WBEM client application accesses information about a managed
 95               resource, the CIM Object Manager contacts either the appropriate provider
 96               for the CIM object that represents that managed resource or the CIM Object
 97               Manager Repository. Providers are classes that communicate with managed
 98               objects to retrieve data. If the requested data is not available from the CIM
 99               Object manager Repository, the CIM Object Manager forwards the request to
100               the provider for that managed resource.
101               
102               Using the Repository.
103               
104               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.
105               
106 karl  1.1.2.1 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.
107               
108               NOTE: The current version of the CIMOM does not incorporate events.  Therefore, this description is written around a CIMOM without events functionality.
109               
110               Note - The listener for connections may not be the Object Manager; it could
111               be another entity that is performing the operation for the Object Manager.
112               This could be a servlet in a Web server. Conformant object managers are
113               required to support XML over HTTP - Pegasus is conformant.
114               
115               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:
116               <UL>
117               <LI>Security checks to authenticate user login and authorization to
118               access the CIMOM information.
119               <LI>Syntactic and semantic checks of the CIM data operations to
120               ensure that they comply with the current version of the CIM
121               specification.
122               <LI>Route requests to the appropriate provider orthe Repository.
123               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.
124               <LI>Deliver data from providers and from the CIM Object Manager
125               Repository to the originating WBEM client application.
126               </UL>
127 karl  1.1.2.1 The CIMOM should be a process that accepts requests for CIM
128               operations, as defined by the DMTF, and carries out these operations.  The
129               Pegasus CIMOM runs as a daemon process that waits for requests.
130               
131               <B>Authentication</B>
132               
133               Before any requests can be made to the CIM Object Manager, an
134               authenticated session must be established.  
135               
136               NOTE:The current version of Pegasus does not
137               have any authentication.  However, it is planned for version 1.1.
138               
139               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.
140               
141               <B>Request Reception</B>
142               
143               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..
144               
145               <B>Authorization</B>
146               
147               The default implementation is Access Control List (ACL) based. Access
148 karl  1.1.2.1 control lists can be maintained per namespace or on a per namespace/user
149               basis. These lists will be maintained in the root/security namespace. The CIM
150               Object Manager will grant read or write permissions within a namespace
151               based on the access control list. Since CIM operations are done within the
152               context of a namespace, these ACLs will enforce rules on whether an
153               operation should be allowed. For operations that will ultimately be handled by
154               a provider, the appropriate provider can replace the authorization scheme.
155               This will allow providers to enforce finer grained control if desired. A
156               provider
157               can replace the default authorization checking scheme by implementing the
158               Authorizable interface. If implemented, no calls are made to the CIM Object
159               Manager.
160               
161               <B>Provider</B>
162               
163               <B>Provider RegistrationB/B>
164               
165               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. 
166               
167               
168               There are a number of conceptual interfaces that can be implemented by providers:
169 karl  1.1.2.1 <UL>
170               <LI>InstanceProvider
171               <LI>MethodProvider
172               <LI>PropertyProvider
173               <LI>AssociatorProvider
174               </UL>
175               .
176               Each conceptual interface provides a subset of the WBEM Operations as follows:
177               
178               NOTE: ATTN: Table defining the types vs. operations
179               
180               However
181               
182               Providers should be loaded "on
183               demand" by the CIMOM. Classes and properties marked by the
184               provider qualifier will be an indication to the object manager that the
185               associated information is dynamic and must be obtained from the providers
186               rather than the repository. When the object manager determines that a
187               specific request needs dynamic data, provider should be
188               loaded and instantiated. Additionally, the "initialize" method of the Provider
189               will be invoked. There should be only a single instance of the provider.
190 karl  1.1.2.1 
191               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.
192               
193               The CIM Object Manager will not act as as a provider for
194               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.
195               
196               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:
197               
198               ATTN: add the services interfaces.
199               
200               
201               
202               
203               ATTN: Dealing with multiple providers per class.
204               
205               
206               <B>Request Routing</B>
207               
208               One of the main functions of the CIMOM is operation request routing.
209               Depending on the request, the request may need to be authorized and passed to
210               semantic checkers, providers, and the repository.
211 karl  1.1.2.1 
212               Requests may be for static information such as schema
213               definitions or static instances. In this case, the CIMOM should
214               route the request to the proper repository.
215               
216               The more complex routing will involve operations that can traverse multiple
217               classes and their instances. An example of such an operation is association
218               traversal. In order to determine the associated instances of a given input
219               instance, the CIMOM should first determine the associations
220               that the given instance class participates in. It will obtain this from the
221               associations that have been compiled and stored in the repository. Once
222               these associations are determined, the CIM Object Manager should find
223               those instances of the associations in which the given input instance plays a
224               role. These associations may, or may not be, dynamic. Depending on
225               whether the associations are dynamic or not, the CIM Object Manager may
226               route the requests to providers or the repository. Once the results are
227               returned, they should be concatenated together and returned because of the
228               request. The CIM Object Manager will use schema information to determine
229               which providers to contact. As can be seen, a given request can result in
230               multiple sub-requests to the providers or the repository.
231               A similar situation will occur when a deep enumeration is performed on
232 karl  1.1.2.1 instances of a class.
233               
234               <B>Semantic Checking</B>
235               
236               The CIMOM performs semantic checks before classes or
237               instances can be set or createdusing internal class,
238               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.,
239               
240               */
241               //@}
242