Object manager for common information model6862736Abstract A common information model (CIM) enables management application programs to receive uniformly rendered results regardless of the source of the information. A CIM object manager isolates the applications from internal components which retrieve the information from various sources and through various other components, and provides refinements to that model that improve the exchange of information. In addition to providing uniform rendering of management information to a client applications, the CIM object manager dynamically adapts to complement the capabilities of the information providers, whereby the information providers may do so in a highly flexible manner. The CIMOM also decomposes a client query to determine the appropriate source or sources of information necessary to resolve that query, and further handles client queries having inherited object classes to render appropriate results in a uniform manner. Claims What is claimed is: Description FIELD OF THE INVENTION
Class Disk
{
string Volume;
string FileSystem;
uint32 TotalCapacity;
uint32 FreeSpace;
};
This class models a disk wherein the four property fields describe individual aspects of a disk. While most classes are representation objects for real-world devices, there is no restriction on the content, or the application of the class to a particular managed object, although a particular CIM implementation may place limits on the number of properties in a class, the types of properties, or other similar limits. Once published, class definitions are immutable and universal, and thus changes are typically effected by either derivation from existing classes or creation of new classes. Note that because of the shared and distributed nature of classes, changing a class definition has the potential to impact managed entities that are currently deployed. As in object-oriented paradigms, classes can be derived from superclasses. A derived class implicitly inherits or contains the entire contents of the superclass. For purposes of simplicity, the present CIM meta-model supports single inheritance only, although more complex inheritance models are feasible. As used herein, the terms base class and superclass may be used interchangeably to indicate a parent, while the terms derived class or subclass may be used to indicate a child class. The fields of a class definition are called properties, and are named values subject to naming guidelines in a CIM implemenation. A wide range of sized integer types are supported (both signed and unsigned), along with IEEE four and eight byte floating point values, UNICODE strings, dates and times, and other known types. Further refinement of the semantics of property values is achieved through the use of qualifiers, described below. By way of example, qualifiers applied to properties may give additional semantics of properties, such as whether a 32-bit integer is actually a `counter` or a `gauge` property type. A class defines a template for describing managed objects. Based on a class definition, specific managed objects are defined using instances of that class. Where the class models the real-world device or component in the general sense, each instance represents a specific occurrence of the class. Continuing with the above example in which a general class called Disk was described, an instance of this previously described Disk class might appear in the MOF syntax as in the table below:
Instance of Disk
{
Volume = "DISKC";
FileSystem = "XFS";
TotalCapacity = 240000000;
FreeSpace = external; // Dynamically supplied by
instrumentation
};
Note that since the FreeSpace parameter is highly volatile, in a typical implementation the value would be supplied by a provider 64, rather than being a stored or static value. As described in more detail below, the CIMOM 64 is capable of retrieving both the static and dynamic information from various sources including the CIM database 66 and/or appropriate providers 64, and returning the object instance to the application 60. In keeping with one aspect of the present invention, the database 66 and/or providers 64 provide their portion of the information without knowledge of its final destination, i.e., the identity of the client process, and the application receives this information transparently, i.e., as instances of the class disk without knowledge of its actual source or sources. A Qualifier is a modifier applied to a class definition, an instance, or a property. Qualifiers constitute meta-data, and are generally, though not necessarily, non-essential modifiers, in that removal of the qualifier should not substantially change the meaning of what was being modified. In MOF syntax, qualifiers are indicated by preceding a list of declarations, delimited by square brackets, as shown in the table below:
[description ("This class models a disk") ]
class Disk
{
string Volume;
[description ("The name of the filesystem") ] string
FileSystem;
uint32 TotalCapacity;
uint32 FreeSpace; };
While the above qualifiers give additional information, their removal does not invalidate the definition of Disk. The presence and values of qualifiers may vary between CIM installations, even for the same class definitions. In general, if removal of a qualifier would seriously alter a class or instance definition, then that qualifier should be re-implemented as a property. Any number of user-defined qualifiers may be applied to class definitions, instances, or any of the properties. As in relational database models, instance identification is done through the use of keys. Using the table and column model common to relation databases, the table corresponds to a CIM class, and the rows correspond to CIM instances. The column or columns which uniquely identify the row are designated as keys. Key properties are designated by attaching a qualifier named `key` to each property that constitutes the key for the class. Key qualifiers can be attached to more than one property to create a compound key. Using the MOF Syntax as an illustration, the Volume property has been designated as the key for the Disk class as shown in the table below:
Class Disk
{
[key] string Volume;
string FileSystem;
uint32 TotalCapacity;
uint32 FreeSpace;
};
The above definition of Disk specifies that the Volume property is used to distinguish instances within the class Disk (and its derived classes), and that there is one unique value of Volume for each real disk on the machine. The other property values can be duplicated across instances. For example, many volumes could support the same FileSystem or TotalCapacity values, and thus such properties would be poor choices for instance discrimination. Certain rules for selecting and using keys apply. For any given class hierarchy, once a key has been introduced it may not be overridden or supplemented by any derived classes. For example, an abstract class SystemElement could be introduced which defines no properties at all, so it would be legal to derive several other classes from it, each introducing their own particular key values. However, no derived classes of each of those subclasses could in turn introduce their own keys. In sum, classes inherit the key of any superclass, if there is one, and only if there is not a key value in the superclass chain is a class permitted to introduce its own key. Since CIM instances belong to a class and reside in a particular namespace (described below) on a particular host, some method of locating or referring to a particular object is required. This takes the form of an Object Path, which is conceptually similar to a URL (Uniform Resource Locator). Object paths come in several varieties. They can be relative to a particular server, relative to the entire network, or relative to a particular namespace, just as file paths in a file system may be relative to a particular sub-directory or volume. As an illustration, a full network-relative object path might appear as //myhost/root/default:disk.volume="C", wherein the first field after the leading double-slash is the server address (network address or host name, i.e., "myhost"). This is followed by the relevant namespace ("root/default") within that server, and the class ("disk") of the desired object. Finally the key values (the property "volume" whose value is "C"), which uniquely designate that instance within the class, are specified. A Namespace is a fundamental grouping unit for sets of classes and instances. A namespace has an effect on the scoping of classes within it. By default, the instances of a class are private to a particular namespace, i.e., instances with the same key may exist in another namespace, but two instances of a class with matching keys are considered to be the same instance within a namespace. By default, a class definition is private to each namespace. However, any given class, while present in more than one namespace, may not have a definition which is at variance from its definition in another namespace. A system is permitted to have single copies of class definitions for its supported namespaces and use reference counting or other mechanisms for the sake of efficiency. Namespaces can be nested in a manner similar to a hierarchical file system. In relational database terminology, a Namespace is similar to a database, except that nesting is possible. The base namespace for all CIM implementations comprises the classes and instances constituting the representation objects for the local host device or machine. Namespaces can be manipulated through the use of the standard system class _Namespace. Creation of an instance of class _Namespace results in the creation of a real logical namespace within the CIM implementation. Note that there are two objects involved, the representation object and the actual namespace itself. Thus, an instance of _Namespace is a representation object for a real database namespace. Deletion of the _Namespace object results in deletion of all the classes and instances within that Namespace as well as deletion of the Namespace itself. Querying for instances of _Namespace is equivalent to querying for the actual list of namespaces supported by the CIM installation. A special type of property called a reference is supported within CIM. This property is a "pointer" to another class or instance within the schema. A reference takes the form of a string which contains an object path. A special type of class which contains a pair of references is called an Association. Instances of association classes are used to set up a binding relationship between two other objects. For example, while it is possible for each of objects A and B to contain reference fields which point to each other, this would entail designing the class to contain a reference property from the outset. In many cases, it may not be known at class design-time which objects may require references to each other. Instead, classes are ordinarily designed to contain no assumptions about relationships in which they may participate. Instead, an association class C can be created after classes A and B are created, wherein C can contain two reference property fields, one which is designated as pointing to instances of A, and the other as pointing to instances of B. In this manner, associations can be used to create object relationships without the knowledge or participation of the objects themselves. Likewise, relationships can be removed without affecting the objects. In a more specific example, it may sometimes be useful to associate a NetworkCard object with a NetworkProtocol object using a dedicated association class called NetCardToProtocolBinding. This is a desirable model, since a card may support more than one protocol, and the same protocol may be running over more than one network card on the host machine. The association objects describe the complex relationships without the more primitive objects being aware of it. In order to deal with queries in a uniform manner, the CIMOM supports the Execute Query protocol operation and preferably supports at least a minimal subset of ANSI SQL. Of course, additional query languages may be supported. In general, SQL specifies the syntax for a simple form of `select` statements for executing read-only queries. Using this syntax, CIM classes (which may be stored in the CIM repository or retrieved from some source on the network) are represented as tables and CIM properties as columns, resulting in a natural SQL-like mapping. The result set of such a query is always a set of CIM instances. By way of example, assume an administrator wants to locate all network disk drives that are running low on free disk space. Through a management application 60, the administrator submits to the CIMOM 62 an SQL query, --"select * from LogicalDisk where FreeSpace<20000000"--. In accordance with one aspect of the present invention and as described in more detail below, the CIMOM 62 works in conjunction with one or more providers 64 and complements the capabilities of the providers to return a result set comprising uniformly rendered managed objects. For example, the provider may not be capable of processing queries in high-level languages such as SQL, but may only be able to return a list of all the instances it supports. In this case, CIMOM will transparently translate the user's high-level query into a series of simple retrievals and then perform the query internally on behalf of the user, giving the user the impression that the provider directly supported the query. Thus, the above-query results in a set of CIM objects (instances) of class LogicalDisk where the property value for FreeSpace is less than twenty million bytes. Each operation within the CIM schema is modeled as a separate protocol operation. For example, most servers acting as CIMOMs will support class creation and update, class retrieval, class deletion, and instance creation and update, instance retrieval, instance deletion, and query execution. Each of these has a corresponding protocol operation. Servers acting as providers may only support one or two operations, such as "Get Instance" and "Put Instance." For example, to retrieve an instance of a particular class, the protocol operation "Get Instance" is used. Once the instance is obtained, it may be necessary to consult the class definition itself, and so a "Get Class" operation is executed. Lastly, in a distributed environment, a client will construct a request packet for the desired protocol operation and send it to the server using an underlying network transport protocol, such as TCP. The reply packet or stream typically contains the result of the operation, or an error packet detailing why the operation could not be completed. Operation of the CIM Object Manager In accordance with one aspect of the present invention, in response to a query, the CIM object manager 62 is capable of retrieving information from various providers and static sources as necessary to satisfy the query. To this end, the object manager 62 receives potentially high level SQL queries, decomposes those queries as necessary, and communicates with a variety of sources, possibly in a series of very primitive operations, to produce a result. The operations are transparent to the client, as the result is returned in the same manner regardless of the sources that supplied the information. FIGS. 4-6 show the general decomposition of a query. When the management application 60 sends a query 74 to the CIMOM 62, the query may be of arbitrary complexity. By way of example, assume the query is--select * from Diskplus where Drive="c:"--, thus requesting all the information from a class called Diskplus for the c: drive, where the class Diskplus is shown below:
[dynamic, provider ("XYZ") ]
Class Diskplus
{
[key] string Drive;
string VolumeID;
[dynamic FreeSpace];
[dynamic, provider ("REG") MfrID
uint32 TotalCapacity;
};
The CIMOM 62 receives and analyzes the query 74, locates the class diskplus via its class repository 66, and recognizes that some of the information is static and exist on the CIM database 66, while other information is dynamic and is to be retrieved from dynamic instance providers. Dynamic instance providers are registered in the CIMOM namespace for which it provides instance values. Preferably, dynamic instance providers are COM objects with a CLSID. The CIMOM 62 locates the appropriate providers in its class repository 66 and as represented in FIG. 5 (properties A, B and E), obtains any static data in the query from a database, e.g., the same CIM database 66 (FIG. 4). For example, using the "c:" drive as the key, the volume ID and total capacity may be located in the static database 66. However, the freespace value is volatile, (shown in FIG. 5 as property D), and is instead obtained by communicating with a disk provider 64.sub.11 named "XYZ," while the manufacturer ID (property C in FIG. 5) is obtained by communicating with a "REG" registry provider 64.sub.6. Thus, by decomposing the query, through a combination of static lookups and communicating with dynamic instance providers, the CIMOM 62 is able to return a result 72 comprising a set of CIM objects (instances) of the class Diskplus that satisfy the query. Note that queries may identify classes of objects that include other objects therein (i.e., via inheritance). Thus, as shown in FIG. 6, a different query 77 may specify an object of class D that inherits classes A, B and C, each having properties with instances located from different sources. Even with such a potentially sophisticated query, the CIMOM 62 is able to obtain the correct result by decomposing the query into the various classes and thereafter into provider identities and static information, and then by communicating with those providers to obtain the correct results. Regardless of how the result set is completed, the operation is transparent to the client, who receives uniformly rendered managed objects. Moreover, in a class, an additional tag may be placed on a property that specifies an override on a particular property. For example, after going to provider xyz and getting the instance of a class, the override instructs the CIMOM 62 to call another provider and override a property based on the information returned from the other provider. For example, the FreeSpace property may be tagged such that after the "xyz" (e.g., a generic) provider returns the freespace, an "abc" provider (e.g., belonging to a vendor having an intimate knowledge of the drive) should be contacted to override that property with its value. As can be appreciated, because of the inheritance capabilities of objects, it is thus possible for an object to have the same property value supplied by two or more providers and/or the static database. In accordance with another aspect of the present invention, the CIMOM provides a mechanism for aggregating multiple properties so as to provide the uniformly rendered result. By way of example, assume a class "Mfr" inherits the class Disk, i.e., Mfr:Disk. However, as shown in FIG. 8, when values for of the properties of each class are retrieved, some of the properties are common, and potentially have different values, since one class may specify one provider while another specifies a different provider for that same property. Note that in FIG. 8, a line indicates a static property that is to be retrieved from the database, while a "?" indicates a dynamic property retrievable from a provider. The CIMOM 62 decomposes the query as described above, and retrieves the properties. To consistently handle conflicts, the CIMOM 62 keeps the deepest of those common properties in the inheritance chain. Thus, as shown in FIG. 8, the CIMOM 62 aggregates the A, B, C, and D properties of the Disk instance (having values c:, NTFS, 2G and 200M, respectively), with the A, C, D and E properties of the Mfr instance (having values c:, 2G, 220M and MfrID, respectively). The joined result set properly includes properties A through E, with any common values kept from the Mfr instance since that instance is deeper in the inheritance chain. Note that the CIMOM 62 may also do some processing to optimize the returning of each set of properties, e.g., do not twice ask for the same static property value. Moreover, other information including the class of an object or the identity of a provider may be nested in other providers. For example, instead of returning the CLSID of a dynamic instance provider identified in a class, the database may return the CLSID of a class provider. From that information, the CIMOM 62 may obtain the class information dynamically, and then use that information to locate the dynamic instance provider necessary for resolving a query. Indeed, the entire schema is dynamic, as each provider can be property, instance, and so on. Note that queries need not request all of the information in a defined class, but may potentially request of subset of instances that match a query based on that class. For example, the query--select * from LogicalDisk where FreeSpace<20000000--intends to have returned only instances that meet the less than twenty megabyte criteria, and not all instances of the LogicalDisk class. In accordance with another aspect of the present invention and as described below, the CIMOM 62 provides the correct result set by a post-retrieval filtering operation, by submitting the query to a provider that is capable of handling queries, or some combination of both. Thus, the CIMOM 62 includes a filtering mechanism 80 that examines each of the resulting instances and discards those that do not properly satisfy the query. Again, regardless of how the result set is completed, the operation is transparent to the client, who receives uniformly rendered managed objects. Thus, in accordance with another aspect of the present invention, the CIM object manager performs operations that compliment the capabilities of providers in order to uniformly render managed objects to management applications. For example, if one provider 64 supplies too much information with respect to a query, the CIMOM 62 examines and filters the unnecessary information in order to provide a managed object that includes the correct information relative to the query. However, some providers have substantially more capabilities than other providers. For example, one provider may simply enumerate all of the information it has, while another provider may be able to handle queries and return specific information. For reasons of efficiency, the CIMOM 62 attempts to operate the provider with its maximum capabilities. Note, however, that the CIM is flexible in how the various types of providers produce information. Indeed, the clients request a full variety of services (e.g., Get/Set, Enum Instances, Enum Classes, Exec Queries, Generate Events and so on), and regardless of the requested service, the CIM Object Manager provides the appropriate response. However, if a provider does have some capabilites, the CIMOM 62 dynamically adapts to complement the capabilities of the components which provide this information. As such, information providers may provide information in a highly flexible manner. By way of example, assume a management application 60 submits a query requesting the return of all files on drive d: having *.exe as an extension and that are less than 200 kilobytes in size. A simple provider may not be able to handle such a query, but instead is only able to return the entire contents of all drives on the system. A slightly more sophisticated provider might be able to find the instances of a class by its path and return it (and thus for example return the files on only drive d:), but is not able to filter the result set by file extension or size. An even more sophisticated provider is able to return an exact result set in response to the query. In accordance with another aspect of the present invention, the CIMOM 62 dynamically adjusts to the capabilities of the providers 64 in order to efficiently return the correct result. Thus, in the first example wherein the machine's provider simply enumerates all files on all drives, the CIMOM 62 performs the filtering and discards the results other than d:*.exe files less than 200 kilobytes. As can be appreciated, this may result in a significant amount of information being transferred from the provider 64 to the CIMOM 62, and is thus ordinarily less efficient than having a smaller result set for the CIMOM 62 to start with, such as via a more sophisticated provider described above. In keeping with the invention, however, the application receives the same result set from the CIMOM regardless of the capability of the provider on the machine. FIG. 7 generally represents how the CIMOM dynamically adjusts to the capabilities of a provider, and more particularly, to a dynamic instance provider. To facilitate this operation, providers have been separated into three levels based on their general retrieval capabilities resulting from the COM object methods therein. As used herein, a level one provider is one that can enumerate all instances of a given class, (which can occur in a synchronous or asynchronous manner depending on the method invoked). A level two provider is one which can find an instance by an object path and return the instance, again, either synchronously or asynchronously. Lastly a level three provider is one which can (synchronously or asynchronously) execute SQL queries against the instances provided. Beginning at step 700, the CIMOM 62 first determines the level of the provider 64. This may be accomplished by retrieving the level information from the database 66 wherein the provider information is maintained. As will become apparent below, this may also be accomplished by initially assuming that the provider is a level three provider, and then reducing the level as necessary until the provider returns a result. If the provider is a level one provider, then step 702 is executed wherein the CIMOM the CIMOM simply asks for a return of all information available to the provider, since this is all that the provider is capable of doing. For example, the CIMOM may invoke a method of the provider requesting enumeration of all the instances of a class. If successful, the results are returned at step 704, otherwise an errorcode or the like is returned, and at step 706 the application is informed of some error in the system, (e.g., the provider code may have become corrupted). If successful, the enumerated instances are provided to the CIMOM 62, which then filters those instances to match the query. The CIMOM 62 includes an SQL-capable filtering mechanism 80 (FIG. 4) for this purpose. Once the proper result set is obtained, the results are returned to the application at step 718. Of course, since the filtering process may be lengthy, rather than wait for the complete result set to be filtered, the CIMOM 62 may begin returning some of the results (instances) while the rest of the filtering is taking place. If the provider is a level two provider, then step 710 is executed wherein the CIMOM passes the class information to the provider and requests the particular instances of that class. If successful, the results are returned at step 712, and steps 716-718 are performed as described above to filter the results and return those results to the application. If the provider was unable to provide the expected results and instead returns an errorcode, the CIMOM 62 then reduces the level of the provider to level one and this time requests an enumeration of all instances (e.g., branches to step 702). Note that lowering the level may entail writing information into the database 66 for this provider indicating an inability to properly operate at the previous level. Lastly, a provider may be a level three (query-capable) provider which results in step 700 branching to step 720. Step 720 passes the query to the provider, and step 722 tests for results. Via a return code, a query-capable provider may return one of three responses to a request, either it exactly resolved the query, it did not exactly return the query, or it was unable to resolve the query in its present form. Note that if the provider returns information informing the CIMOM 62 that it did not exactly resolve the query, the provider returns more results than requested (a superset), never less (a subset). In the event that either the exact set or a superset thereof was returned, the CIMOM filters the results at step 716 before returning the results to the application at step 718. Note that while an exact result set should not need to be filtered, the CIMOM scans the set anyway to double-check that the provider correctly interpreted the query. In the event that the provider was unable to return the query, step 722 branches to step 724 to determine if the complexity of the query can be reduced. For example, a certain provider may be able to handle most SQL queries, but is unable to resolve a few. Rather than simply bypass the capabilities of such a provider, the CIMOM attempts to reduce the complexity of the query at step 726. Similar to the above example, assume a query asks for all files on drive d: having *.exe as an extension and that are less than 200 kilobytes in size, and only those created before Apr. 1, 1996. If a particular directory provider handles most file-based queries, but is unable to work with date information, the complexity of the query may be reduced at step 726 to remove this part of the query. As can be appreciated, such a query is still far more efficient than simply asking the provider to enumerate all files on drive d:, or simply all files on all drives. Note that step 726 may itself comprise an algorithm that attempts various permutations of query criteria each time through the loop for a given query. Alternatively, (or in addition), step 726 may look-up (and also store) certain information about a specific provider that instructs the CIMOM 62 in how to reduce the complexity of a query for that provider. For example, the knowledge that a certain provider cannot handle queries with date information may be detected and stored for future complexity-reduction operations. After the complexity of the query is reduced, the new query is passed to the provider at step 720. The process continues looping until either some results (exact set or superset) are returned (step 722), or the complexity of the query can no longer be reduced (step 724). If results are returned, steps 716-718 are executed as described above. Note that if a query of reduced complexity is given to a provider, a superset of the desired result set is actually returned, even when the provider indicates that it exactly resolved the (reduced) query. Nevertheless, the filtering by the CIMOM 62 completes the complementing of the capabilities of the provider to return the exact result set to the application. If at step 724 the complexity can no longer be reduced, the provider may be considered a level one or two provider and the process repeated from step 700 in an attempt to obtain some suitable results. While the invention is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention.
|
Same subclass Same class Consider this |
||||||||||