Document Number: XMP1033
Date: 2013-02-23
Version: 1.1.0a
Example Profile Registration Profile
IMPORTANT: This specification is not a standard. It does not necessarily reflect the views of the DMTF or all of its members. Because this document is a Work in Progress, this specification may still change, perhaps profoundly. This document is available for public review and comment until the stated expiration date. This document expires on: 2013-07-31. Target version for DMTF Standard: 1.1.0. Provide any comments through the DMTF Feedback Portal: http://www.dmtf.org/standards/feedback |
Document Type: Specification
Document Status: Work in Progress
Document Language: en-US
DMTF is a not-for-profit association of industry members dedicated to promoting enterprise and systems management and interoperability. Members and non-members may reproduce DMTF specifications and documents, provided that correct attribution is given. As DMTF specifications may be revised from time to time, the particular version and release date should always be noted.
Implementation of certain elements of this standard or proposed standard may be subject to third party patent rights, including provisional patent rights (herein "patent rights"). DMTF makes no representations to users of the standard as to the existence of such rights, and is not responsible to recognize, disclose, or identify any or all such third party patent right, owners or claimants, nor for any incomplete or inaccurate identification or disclosure of such rights, owners or claimants. DMTF shall have no liability to any party, in any manner or circumstance, under any legal theory whatsoever, for failure to recognize, disclose, or identify any such third party patent rights, or for such party’s reliance on the standard or incorporation thereof in its product, protocols or testing procedures. DMTF shall have no liability to any party implementing such standard, whether such implementation is foreseeable or not, nor to any patent owner or claimant, and shall have no liability or responsibility for costs or losses incurred if a standard is withdrawn or modified after publication, and shall be indemnified and held harmless by any party implementing the standard from any and all claims of infringement by a patent owner for such implementations.
For information about patents held by third-parties which have notified the DMTF that, in their opinion, such patent may relate to or impact implementations of DMTF standards, visit http://www.dmtf.org/about/policies/disclosures.php.
Design Note: This document contains design notes (like this one), that provide information about the way the document is written, or to demonstrate certain things. Such design notes would not appear in a released version of this document.
Design Note: This document represents a WG draft of DSP1033 (Profile Pegistration Profile) version 1.1.0a and can be used as a real-life example for a profile in MRP 1.1 format.
This document was prepared by the DMTF Architecture Working GroupDMTF is a not-for-profit association of industry members dedicated to promoting enterprise and systems management and interoperability. For information about the DMTF, see http://www.dmtf.org.
DMTF acknowledges the following individuals for their contributions to this document:
This document defines the CIM model for discovering implemented profiles in a managed environment. The information in this document is intended to be sufficient for a provider or consumer of this data to identify unambiguously the classes, properties, methods, and values that need to be instantiated and manipulated.
The target audience for this specification is implementers who are writing CIM-based providers or consumers of management interfaces that represent the components described in this document.
The following typographical conventions are used in this document:
Constraints in this document are specified using OCL (see OCL 2.0).
OCL statements are in monospaced font.
Deprecated material is not recommended for use in new development efforts. Existing and new implementations may use this material, but they shall move to the favored approach as soon as possible. CIM services shall implement any deprecated elements as required by this document in order to achieve backwards compatibility. Although CIM clients may use deprecated elements, they are directed to use the favored elements instead.
Deprecated material should contain references to the last published version that included the deprecated material as normative material and to a description of the favored approach.
The following typographical convention indicates deprecated material:
DEPRECATED
Deprecated material appears here.
DEPRECATED
In places where this typographical convention cannot be used (for example, tables or figures), the "DEPRECATED" label is used alone.
The Profile Registration profile extends the management capabilities of referencing profiles by adding the capabilities to advertise conformance of the implementation to the referencing profiles , and to discover instances for which conformance to the referencing profile is advertised.
The following referenced documents are indispensable for the application of this document. For dated or versioned references, only the edition cited (including any corrigenda or DMTF update versions) applies. For references without a date or version, the latest published edition of the referenced document (including any corrigenda or DMTF update versions) applies.
DMTF DSP0004, CIM Infrastructure Specification 2.7,
http://www.dmtf.org/standards/published_documents/DSP0004_2.7.pdf
DMTF DSP0223, Generic Operations 1.0,
http://www.dmtf.org/standards/published_documents/DSP0223_1.0.pdf
DMTF DSP1001, Management Profile Specification Usage Guide 1.1,
http://www.dmtf.org/standards/published_documents/DSP1001_1.1.pdf
OMG formal/06-05-01, Object Constraint Language 2.0,
http://www.omg.org/spec/OCL/2.0/
ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards,
http://isotc.iso.org/livelink/livelink?func=ll&objId=4230456&objAction=browse&sort=subtype
In this document, some terms have a specific meaning beyond the normal English meaning. Those terms are defined in this clause.
The terms "shall" ("required"), "shall not", "should" ("recommended"), "should not" ("not recommended"), "may", "need not" ("not required"), "can" and "cannot" in this document are to be interpreted as described in ISO/IEC Directives, Part2, Annex H. The terms in parenthesis are alternatives for the preceding term, for use in exceptional cases when the preceding term cannot be used for linguistic reasons. Note that ISO/IEC Directives, Part2, Annex H specifies additional alternatives. Occurrences of such additional alternatives shall be interpreted in their normal English meaning in this document.
The terms "clause", "subclause", "paragraph", "annex" in this document are to be interpreted as described in ISO/IEC Directives, Part2, Clause 5.
The terms "normative" and "informative" in this document are to be interpreted as described in ISO/IEC Directives, Part2, Clause 3. In this document, clauses, subclauses or annexes indicated with "(informative)" as well as notes and examples do not contain normative content.
The following additional terms are defined in this document.
autonomous profile
a profile that addresses an autonomous and self-contained management domain. For a complete definition, see DSP1001 .
DSP1001 defines that in autonomous profiles, the central class adaptation and scoping class adaptation are the same. Thus, autonomous profiles cannot be scoped by other profiles . With the exception of this profile , autonomous profiles do not need to be referenced in order to be implemented, and can therefore be implemented alone. Autonomous profiles may reference component profiles and autonomous profiles (including themselves) and may scope component profiles . See also term "component profile" .
central class adaptation
central class methodology
central element
central instance
component profile
a profile that addresses a subset of a management domain. For a complete definition, see DSP1001 .
DSP1001 defines that in component profiles, the central class adaptation and scoping class adaptation are not the same. Component profiles need to be scoped by one or more scoping profiles to be implemented, and can be implemented only together with one of their scoping profiles . Component profiles may reference autonomous profiles and component profiles (including themselves) and may scope other component profiles. See also term "autonomous profile" .
Interop namespace
a role of a CIM namespace for the purpose of providing a common and well-known place for clients to discover modeled entities, such as the profiles to which an implementation advertises conformance. The term is also used for namespaces that assume that role. For a complete definition, see subclause "Interop namespace" . See also term "implementation namespace" .
implementation namespace
a role of a CIM namespace for the purpose of providing a place for CIM objects for which no specific namespace requirements are defined. The term is also used for namespaces that assume that role. For a complete definition, see subclause "Implementation namespaces" . See also term "Interop namespace" .
profile
profile conformance
conformance of an implementation to one or more profiles , such that the implementation satisfies the rules for full implementation conformance defined in subclause 5.2.2 of DSP1001 .
referenced profile
referencing profile
registered profile
a profile to which an implementation advertises conformance . Before version 1.1 of this profile , registered profiles were termed "subject profiles" (that term is now deprecated).
scoping class adaptation
scoping class methodology
scoping element
scoping instance
scoping path
scoping profile
a profile that provides a scope to a scoped profile by defining a central class adaptation that is based on the scoping class adaptation defined in the scoped profile. For a complete definition, see DSP1001 .
subject profile
DEPRECATED: The term "subject profile" has been deprecated in version 1.1 of this profile , because its meaning as defined in this profile was different from the meaning as defined in DSP1001 .
Use the term "registered profile" instead.
this profile
The abbreviations defined in DSP0004, DSP0223, and DSP1001 apply to this document.
This document does not define any additional abbreviations.
Profile name: Example Profile Registration
Version: 1.1.0
Organization: DMTF
Abstract: No
Profile type: Autonomous
Schema: DMTF CIM 2.10
Central class adaptation: RegisteredProfile
Scoping class adaptation: RegisteredProfile
The Profile Registration profile extends the management capabilities of referencing profiles by adding the capabilities to advertise and discover conformance of the implementation to the referencing profiles .
For historical reasons, the scoping and central class adaptations of the Profile Registration profile are the same. Thus, it is an autonomous profile . Nonetheless, it cannot be implemented on its own, but only in context of its referencing profiles .
identifies the profile references defined in this profile.
Profile reference name | Profile name | Organi-zation | Version | Relation-ship | Description |
---|---|---|---|---|---|
SelfPRP | Example Profile Registration | DMTF | 1.1 | Mandatory |
Used to advertise
conformance
of the implementation to
this profile
.
|
identifies the features defined in this profile.
Feature | Requirement | Description |
---|---|---|
CentralClassMethodology | ConditionalExclusive | See subclause "Feature: CentralClassMethodology". |
ScopingClassMethodology | ConditionalExclusive | See subclause "Feature: ScopingClassMethodology". |
identifies the class adaptations defined in this profile.
Adaptation | Elements | Requirement | Description |
---|---|---|---|
Instantiated, embedded and abstract adaptations | |||
RegisteredProfile | CIM_RegisteredProfile | Mandatory | See subclause "Adaptation: RegisteredProfile". |
ElementConformsToProfile | CIM_ElementConformsToProfile | ConditionalExclusive | See subclause "Adaptation: ElementConformsToProfile". |
ScopingElement | CIM_ManagedElement | See derived adaptations | See subclause "Adaptation: ScopingElement". |
CentralElement | CIM_ManagedElement | See derived adaptations | See subclause "Adaptation: CentralElement". |
ReferencedProfile | CIM_ReferencedProfile | ConditionalExclusive | See subclause "Adaptation: ReferencedProfile". |
ReferencedRegisteredProfile | CIM_RegisteredProfile | See derived adaptations | See subclause "Adaptation: ReferencedRegisteredProfile". |
Indications and exceptions | |||
This profile does not define any such adaptations. |
identifies the use cases and state descriptions defined in this profile.
The DMTF adaptation diagram (see DSP1001 ) in the following figure shows all class adaptations defined in this profile , and relevant class adaptations from referenced profiles.
DMTF adaptation diagram
Registered profiles (that is, profiles to which an implementation advertises conformance) are represented by instances of the RegisteredProfile adaptation in the Interop namespace .
As defined in subclause "WBEM server requirements on CIM namespaces" , the roles of an Interop namespace and of an implementation namespace can be assumed by different namespaces or by the same namespace. The diagram in Figure 1 shows the case of different namespaces. If these namespaces are different, the class adaptations shown in the Interop namespace may also be implemented in the implementation namespace .
The RegisteredProfile class adaptation is the central and scoping class adaptation of this profile .
The central and scoping elements of the registered profile are represented by instances of the CentralElement and ScopingElement adaptation, respectively.
If the ElementConformsToProfile association adaptation is implemented, the registered profile supports the central class methodology ; otherwise, it supports the scoping class methodology . For a complete definition, see subclause "Central and scoping class concept" .
If the registered profile references any profiles , these referenced profiles are represented by instances of the ReferencedRegisteredProfile class adaptation. These instances are associated via the ReferencedProfile association adaptation to the instances of the RegisteredProfile class adaptation that represent the referencing profile .
The referenced profiles also advertise their profile conformance through this profile .
If the registered profile is a component profile, it has a scoping profile . Conformance of an implementation to the scoping profile is also advertised through a use of this profile . This configuration is not shown in the diagram; the diagram only shows how this profile is used by the registered profile . A use of this profile for advertising conformance of an implementation to the scoping profile results from the fact that the scoping profile references this profile as well, so it is on the role of a registered profile and the diagram is simply applied another time using that role.
The part of an implementation that implements this profile can also advertise conformance to the Profile Registration profile (that is, this profile ). The resulting use of this profile by itself is named "SelfPRP" in ; the profile RegisteredProfile adaptation is shown in the diagram with a label "(from the Profile Registration profile referenced as SelfPRP)".
Profiles typically define constraints and behavioral requirements for more than one CIM schema class. The usages of CIM schema classes in the context of a profile are termed adaptations (see DSP1001 ). For an implementation to conform to a profile , each of the CIM elements for which the profile defines constraints and behavioral requirements needs to conform to these constraints and behavioral requirements. Because profiles also define which entities in the managed environment are represented by the model entities, conformance to a profile cannot only be limited to interface conformance (see DSP1001 ), but needs to include those mapping aspects as well. Therefore, an implementation conforms to a profile , if it satisfies the rules for full implementation conformance defined in 5.2.2 of DSP1001 .
This profile establishes the concepts of a central class adaptation and a scoping class adaptation that allow a client to perform the following tasks:
The central class adaptation of a profile acts as an algorithmic focal point for all adaptations defined by that profile . The central class adaptation also represents the boundary for clients between using a generic discovery mechanism and using a priori knowledge about the profile, as follows:
Implementations that conform to multiple profiles and implementations that conform to profiles and in addition implement schema classes outside of the context of any profile deserve particular attention by clients, when navigating the network of instances, because it is possible that instances of a particular class conform to different profiles or to no profile. This often requires clients to have a priori knowledge about the way these multiple profiles and schema classes have been combined in the implementation.
The scoping class adaptation of a profile is used for discovering the central instances indirectly, in cases where there are many central instances to be expected.
In autonomous profiles , the central class adaptation and the scoping class adaptation are the same adaptation (see DSP1001 ), with the same set of instances.
This profile defines two profile advertisement methodologies through which an implementation can advertise conformance to a particular profile , and through which clients can navigate between the RegisteredProfile instance representing the registered profile and its central instances :
The first methodology is termed central class methodology ; it is characterized by a direct ElementConformsToProfile association adaptation between the CentralElement and the RegisteredProfile adaptation. This means, every central instance is directly associated with the RegisteredProfile instance representing the registered profile .
See subclause "Central class methodology" for more information about the central class methodology .
The second methodology is termed scoping class methodology ; it uses the ElementConformsToProfile association adaptation only between the ScopingElement adaptation of the registered profile and the RegisteredProfile adaptation of the scoping profile . As a result, the central instances of the registered profile are not directly associated through the ElementConformsToProfile adaptation to instances of the RegisteredProfile adaptation that represent the registered profile .
The ScopingElement adaptation of the registered profile binds to the CentralElement adaptation of the scoping profile , so this profile advertisement methodology basically delegates the traversal of the ElementConformsToProfile association adaptation to the scoping profile .
This delegation may happen across multiple levels of scoping profiles , until some scoping profile finally implements the central class methodology . It is typical (but not required) that that final scoping profile is an autonomous profile .
See subclause "Scoping class methodology" for more information about the scoping class methodology .
Use of the central class and scoping class methodologies are mutually exclusive for a specific registered profile version; exactly one of these methodologies shall be implemented.
The decision about implementing central class methodology or scoping class methodology should be left to the implementation; that is, profiles should not require one or the other profile advertisement methodology to be implemented.
In situations where implementations have small footprint requirements and want to reduce the number of instances or in situations where the implementation is monolithic and only a single version of each profile is used, the implementation may use the scoping class methodology to reduce the number of necessary ElementConformsToProfile instances.
In situations where implementations use multiple versions of the same profile (for example, when multi-vendor providers are integrated into a single WBEM server), the central class methodology is recommended, because it provides unambiguous relationships through ElementConformsToProfile instances between central instances and the RegisteredProfile instances representing the registered profiles with their versions.
For autonomous profiles , the scoping class methodology gets reduced to become the same as the central class methodology , because scoping element and central element are the same.
An implementation that conforms to multiple versions of a particular registered profile may use different methodologies for each profile version, as long as the scoping class methodology is used for no more than one of the profile versions. The reason for this restriction is that with more than one use of the scoping class methodology , it is not possible to find out which subset of the central instances are related to which version of the registered profile .
An example of this situation could be a system with two network interface cards, each from a different vendor, and the parts of the overall implementation contributed by each vendor conform to different versions of the Ethernet Port Profile. This example also shows that in multi-vendor environments, it may be difficult to coordinate the choice of profile advertisement methodology. Using the central class methodology puts an implementation on the safe side in multi-vendor environments.
This profile defines no mechanisms for explicitly advertising which methodology has been used. The methodology that was used can be ascertained by testing whether a central instance of the registered profile is referenced by an ElementConformsToProfile instance. Determining the methodology by testing whether the RegisteredProfile instance representing the registered profile is referenced by an ElementConformsToProfile instance only works when it is also ascertained that there is at least one central instance of the registered profile .
The central class profile advertisement methodology (or short: central class methodology ) is based on a straightforward approach whereby every CentralElement instance (representing the central instances of a registered profile ) is associated through ElementConformsToProfile with a RegisteredProfile instance that represents the registered profile and version to which the profile implementation advertises conformance.
This profile advertisement methodology is straightforward because clients only need to traverse the ElementConformsToProfile association adaptation from or to the profile's CentralElement instance to ascertain the profiles to which the implementation advertises conformance.
Using this profile advertisement methodology is covered by the CentralClassMethodology feature.
Figure 2 is an object diagram (showing unnamed instances with their top-level class adaptation names) that provides an example of the central class methodology of advertising profile conformance . In the figure, the dotted line bi-directional arrows represent the ability of a client to traverse the ElementConformsToProfile association adaptation in the following ways:
In both cases, the traversal of the ElementConformsToProfile adaptation typically will be across namespaces; that is not represented in Figure 2 but is described in subclause "Cross-namespace associations" .
In Figure 2 , the ComputerSystem, Fan, and Sensor adaptations are defined in respective profiles; they are all central elements in these profiles and are therefore based on the CentralElement adaptation defined in this profile . The RegisteredProfile instances represent these three profiles. It is furthermore assumed that for the purposes of this example, that the Sensors profile is implemented for some system level sensor (and not for a fan sensor).
Central class methodology example
The scoping class profile advertisement methodology (or short: scoping class methodology ) is an approach characterized by the use of the ElementConformsToProfile association adaptation not between the central instances of a registered profile and a RegisteredProfile instance that represents that registered profile , but instead by having that association adaptation at the next scoping profile that uses the central class methodology for itself.
Using this profile advertisement methodology is part of the ScopingClassMethodology feature.
Figure 3 is an object diagram (showing unnamed instances with their top-level class adaptation names) that provides an example of the scoping class methodology of advertising profile conformance with one level of scoping profiles .
Scoping class methodology example
In Figure 3 , a client may traverse from a Fan instance to its scoping instance (the ComputerSystem instance) through the SystemDevice association adaptation, following the scoping path defined in the Example Fan profile. Because the ComputerSystem instance is referenced by ElementConformsToProfile instances, the client knows that the corresponding profile has used the central class methodology , and can now traverse ElementConformsToProfile to a RegisteredProfile instance that represents the Example Base Server profile, version 1.0.0, which is the scoping profile of the Example Fan profile. Finally, ReferencedProfile is traversed to a RegisteredProfile instance that represents the Example Fan profile, version 1.0.0, to which the implementation is advertising conformance.
The client may reverse this traversal and start from the RegisteredProfile instance that represents the Example Fan profile to get to the instance(s) of Fan.
The concept is in both cases that the client navigates up the scoping profile hierarchy to the level where a scoping profile uses the central class methodology (as indicated by the presence of instances of the ElementConformsToProfile association adaptation), and then traverses from the element side to the profile side or vice versa, and then navigates down the scoping profile hierarchy the same number of steps.
In both cases, the traversal of the ElementConformsToProfile adaptation typically will be across namespaces; that is not represented in Figure 3 but is described in subclause "Cross-namespace associations" .
In Figure 3 , the ComputerSystem, Fan, and Sensor adaptations are defined in respective profiles; they are all central elements in these profiles and are therefore implicitly based on the CentralElement adaptation defined in this profile . The RegisteredProfile instances represent these three profiles.
This subclause defines the roles of Interop namespace and implementation namespace for CIM namespaces, and related implementation requirements for WBEM servers.
Some of these concepts and requirements have a more general scope than this profile . For example, the concept of an Interop namespace is also used by other profiles (e.g., DSP1054 ) or by WBEM SLP discovery (see DSP0206 ). Another such example is the concept of cross-namespace associations.
Interop namespace is a role of a CIM namespace for the purpose of providing a common and well-known place for clients to discover modeled entities, such as the profiles to which an implementation advertises conformance .
A WBEM server shall implement exactly one CIM namespace that assumes the role of an Interop namespace ; that namespace is also called the Interop namespace .
A WBEM server shall expose its Interop namespace by using the namespace name:
interop
DEPRECATED
A WBEM server may expose its Interop namespace using the following alternative namespace name, instead of using the "interop" namespace name:
root/interop
The use of this alternative namespace name is not preferred and has been deprecated in version 1.1 of this profile.
Note that clients need to be prepared to deal with any one of these two namespace names.
DEPRECATED
A WBEM server may expose its Interop namespace by using additional implementation-defined namespace names that are not one of the namespace names described previously in this subclause. This accommodates WBEM server implementations that support namespace alias names. The client-visible appearance of such a WBEM server is that it exposes multiple distinct Interop namespaces , each with a distinct set of CIM objects (where these sets are equal, except for different CIM object paths).
DEPRECATED
The use of leading slash (/) characters in Interop namespace names is deprecated.
Older WBEM implementations may have considered the slash separator character in a CIM object path URI to be part of the namespace name and thus exposed the namespace name (e.g., in the Name property of CIM_Namespace) with a leading slash character. Version 1.0 of this profile permitted a leading slash character in the name of the Interop namespace. DSP0004 does not permit namespace names to begin with a slash. Therefore, version 1.1 of this profile has deprecated the use of leading slash characters in the name of the Interop namespace.
Producers of Interop namespace names should not create a leading slash character in the Interop namespace name. Consumers of Interop namespace names shall ignore a leading slash character in Interop namespace names when processing them (e.g., for comparison or identification purposes).
DEPRECATED
Implementation namespace is a role of a CIM namespace for the purpose of providing a place for CIM objects for which no specific namespace requirements are defined.
A WBEM server shall implement one or more CIM namespaces that assume the role of an implementation namespace ; each such namespace is also called an implementation namespace .
The names of implementation namespaces are implementation-defined.
A CIM namespace of a WBEM server may play the roles of an implementation namespace and of an Interop namespace at the same time.
Thus, a simple implementation of a WBEM server can expose a single CIM namespace that plays both roles. Of course, that single CIM namespace needs to satisfy the requirements for its name as defined in subclause "Interop namespace" .
A typical implementation of a WBEM server will expose a single Interop namespace and multiple implementation namespaces , each of which is a distinct namespace implementation.
The part of an implementation that conforms to a particular single profile may span multiple namespaces, including multiple implementation namespaces .
Some association adaptations defined in this profile may cross CIM namespaces (within the same WBEM server).
Associations that cross CIM namespaces shall be instantiated in both namespaces. The rationale for this is to support association traversal from either namespace to the other.
Each of these association instances shall have their creation class exist in the same namespace as the association instance. The versions of these association classes in each of the two namespaces may be different; this is needed in order to allow that the implementation namespaces within a WBEM server can be used for objects from different versions of the CIM schema.
Implementing this feature for a registered profile provides support for advertising conformance of an implementation to that registered profile using the central class methodology . For details, see subclause "Central class methodology" .
The requirement level for this feature is conditional exclusive, with the following condition:
This feature can be made available to clients at the granularity of RegisteredProfile instances.
It can be concluded that the feature is available for a RegisteredProfile instance if:
At least one ElementConformsToProfile instance exists that references the RegisteredProfile instance representing the registered profile . This discovery mechanism only works if at least one central instance exists and if all implementations of the registered profile use the same methodology.
Otherwise, it can be concluded that the feature is not available.
Implementing this feature for a registered profile provides support for advertising conformance of an implementation to that registered profile using the scoping class methodology . For details, see subclause "Scoping class methodology" .
The requirement level for this feature is conditional exclusive, with the following condition:
This feature can be made available to clients at the granularity of RegisteredProfile instances.
It can be concluded that the feature is available for a RegisteredProfile instance if:
No ElementConformsToProfile instance exists that references the RegisteredProfile instance representing the registered profile . This discovery mechanism only works if at least one central instance exists and if all implementations of the registered profile use the same methodology.
Otherwise, it can be concluded that the feature is not available.
This profile defines operation requirements based on DSP0223.
For adaptations of ordinary classes and of associations, the requirements for operations are defined in adaptation-specific subclauses of subclause Adaptations.
For association traversal operation requirements that are specified only in the elements table of an adaptation (i.e., without operation-specific subclauses), the names of the association adaptations to be traversed are listed in the elements table.
The default initialization requirement level for property requirements is optional.
The default modification requirement level for property requirements is optional.
This profile repeats the effective values of certain Boolean qualifiers as part of property, method parameter, or method return value requirements. The following convention is established: If the name of a qualifier is listed, its effective value is True; if the qualifier name is not listed, its effective value is False. The convention is applied in the following cases:
This adaptation models registered profiles (that is, profiles to which an implementation advertises conformance .
It is important to understand that there are no "profile implementations" that could be distinguished within an overall implementation. The overall implementation may be a mix of parts from different vendors, each of which may have implemented a profile, but these different parts are not necessarily distinguishable within the overall implementation. Only the conformance of the overall implementation to a profile is represented using this profile.
The implementation type of this adaptation is instantiated ordinary adaptation.
The requirement level for this adaptation is mandatory.
identifies the element requirements for this adaptation.
Element | Requirement | Description |
---|---|---|
Properties | ||
InstanceID | Mandatory | Key, see schema definition. |
RegisteredOrganization | Mandatory | Required, see schema definition. |
RegisteredName | Mandatory | Required, see subclause "Property: RegisteredName". |
RegisteredVersion | Mandatory | Required, see schema definition. |
AdvertiseTypes | Mandatory | Required, see schema definition. |
OtherRegisteredOrganization | Conditional | See subclause "Property: OtherRegisteredOrganization". |
AdvertiseTypeDescriptions | Conditional | See subclause "Property: AdvertiseTypeDescriptions". |
Operations | ||
GetInstance( ) | Mandatory | See DSP0223. |
EnumerateInstances( ) | Mandatory | See DSP0223. |
EnumerateInstanceNames( ) | Mandatory | See DSP0223. |
Associators( ) for ElementConformsToProfile | ConditionalExclusive | See subclause "Operation: Associators( ) for ElementConformsToProfile". |
AssociatorNames( ) for ElementConformsToProfile | ConditionalExclusive | See subclause "Operation: AssociatorNames( ) for ElementConformsToProfile". |
Associators( ) for ReferencedProfile | ConditionalExclusive | See subclause "Operation: Associators( ) for ReferencedProfile". |
AssociatorNames( ) for ReferencedProfile | ConditionalExclusive | See subclause "Operation: AssociatorNames( ) for ReferencedProfile". |
The presentation requirement level for this property is mandatory.
The value shall be the name of the registered profile .
The presentation requirement level for this property is conditional, with the following condition:
The RegisteredOrganization property can potentially have a value of 1 (Other).
The presentation requirement level for this property is conditional, with the following condition:
For general requirements on the implementation of this operation, see DSP0223.
The requirement level for this operation is conditional exclusive, with the following condition:
This operation requirement applies when traversing the following association adaptations:
For general requirements on the implementation of this operation, see DSP0223.
The requirement level for this operation is conditional exclusive, with the following condition:
This operation requirement applies when traversing the following association adaptations:
For general requirements on the implementation of this operation, see DSP0223.
The requirement level for this operation is conditional exclusive, with the following condition:
This profile is implemented for a profile referenced by the registered profile .
This operation requirement applies when traversing the following association adaptations:
For general requirements on the implementation of this operation, see DSP0223.
The requirement level for this operation is conditional exclusive, with the following condition:
This profile is implemented for a profile referenced by the registered profile .
This operation requirement applies when traversing the following association adaptations:
The implementation type of this adaptation is instantiated association adaptation.
The requirement level for this adaptation is conditional exclusive, with the following condition:
Note that if the CentralClassMethodology feature is not implemented, traversal between RegisteredProfile and CentralElement instances is delegated to the level of the scoping profile, as described in subclause "Central and scoping class concept" .
identifies the element requirements for this adaptation.
Element | Requirement | Description |
---|---|---|
Properties | ||
ConformantStandard | Mandatory | Key, see subclause "Property: ConformantStandard". |
ManagedElement | Mandatory | Key, see subclause "Property: ManagedElement". |
Operations | ||
GetInstance( ) | Mandatory | See DSP0223. |
The presentation requirement level for this property is mandatory.
The implementation shall satisfy the following constraints for this reference property:
The presentation requirement level for this property is mandatory.
The implementation shall satisfy the following constraints for this reference property:
This adaptation models scoping elements of registered profiles .
This adaptation shall be (implicitly) applied as a base adaptation to the scoping class adaptation of the registered profile ; that is, that adaptation does not need to specify this adaptation is its base adaptation, but is still considered a derived adaptation of this adaptation.
The implementation type of this adaptation is abstract ordinary adaptation.
The requirement level for this abstract adaptation is left to be defined in its derived adaptations.
This adaptation models central elements of registered profiles . Note that DSP1001 requires that every DMTF profile references this profile , and requires that referencing profiles base their central class adaptation on this adaptation.
This adaptation shall be (implicitly) applied as a base adaptation to the central class adaptation of the registered profile ; that is, that adaptation does not need to specify this adaptation is its base adaptation, but is still considered a derived adaptation of this adaptation.
The implementation type of this adaptation is abstract ordinary adaptation.
The requirement level for this abstract adaptation is left to be defined in its derived adaptations.
identifies the element requirements for this adaptation.
Element | Requirement | Description |
---|---|---|
Operations | ||
Associators( ) for ElementConformsToProfile | ConditionalExclusive | See subclause "Operation: Associators( ) for ElementConformsToProfile". |
AssociatorNames( ) for ElementConformsToProfile | ConditionalExclusive | See subclause "Operation: AssociatorNames( ) for ElementConformsToProfile". |
For general requirements on the implementation of this operation, see DSP0223.
The requirement level for this operation is conditional exclusive, with the following condition:
This operation requirement applies when traversing the following association adaptations:
For general requirements on the implementation of this operation, see DSP0223.
The requirement level for this operation is conditional exclusive, with the following condition:
This operation requirement applies when traversing the following association adaptations:
This adaptation models the relationship between registered profiles and the profiles they reference.
The implementation type of this adaptation is instantiated association adaptation.
The requirement level for this adaptation is conditional exclusive, with the following condition:
This profile is implemented for a profile referenced by the registered profile .
identifies the element requirements for this adaptation.
Element | Requirement | Description |
---|---|---|
Properties | ||
Antecedent | Mandatory | Key, see subclause "Property: Antecedent". |
Dependent | Mandatory | Key, see subclause "Property: Dependent". |
Operations | ||
GetInstance( ) | Mandatory | See DSP0223. |
The presentation requirement level for this property is mandatory.
The implementation shall satisfy the following constraints for this reference property:
The presentation requirement level for this property is mandatory.
The implementation shall satisfy the following constraints for this reference property:
This adaptation models referenced profiles ; that is, profiles that are referenced by the registered profile represented by the RegisteredProfile adaptation instance. The type of profile relationship can be any; that is, usage or derivation. This adaptation provides the ability to traverse the ReferencedProfile association between the RegisteredProfile instances representing the referencing profile and the referenced profile .
This adaptation is implicitly applied as a base adaptation to the RegisteredProfile adaptation when implemented in context of the referenced profile . For example, if an Example Fan profile references an Example Sensors profile, and both reference this profile, the use of the RegisteredProfile adaptation in context of the Example Sensors profile's use of this profile will get the ReferencedRegisteredProfile adaptation in context of the Example Fan profile's use of this profile implicity applied as a base adaptation.
The implementation type of this adaptation is abstract ordinary adaptation.
The requirement level for this abstract adaptation is left to be defined in its derived adaptations.
identifies the element requirements for this adaptation.
Element | Requirement | Description |
---|---|---|
Operations | ||
Associators( ) for ReferencedProfile | ConditionalExclusive | See subclause "Operation: Associators( ) for ReferencedProfile". |
AssociatorNames( ) for ReferencedProfile | ConditionalExclusive | See subclause "Operation: AssociatorNames( ) for ReferencedProfile". |
For general requirements on the implementation of this operation, see DSP0223.
The requirement level for this operation is conditional exclusive, with the following condition:
This profile is implemented for a profile referenced by the registered profile .
This operation requirement applies when traversing the following association adaptations:
For general requirements on the implementation of this operation, see DSP0223.
The requirement level for this operation is conditional exclusive, with the following condition:
This profile is implemented for a profile referenced by the registered profile .
This operation requirement applies when traversing the following association adaptations:
This state description describes a simple scenario in which an implementation conforms to three example profiles, and advertises conformance through this profile (i.e., the Profile Registration profile). In this state description, each implementation of this profile in turn advertises conformance to this profile itself.
lists these four profiles, and their referenced profiles:
Profile | Profile Type | Referenced Profile | Profile Reference Type | Profile Reference Name |
---|---|---|---|---|
Example Base Server | Autonomous | Profile Registration | Usage | PRP |
Example Fan | Usage | SystemFan | ||
Example Power Supply | Usage | SystemPowerSupply | ||
Example Fan | Component | Profile Registration | Usage | PRP |
Example Power Supply | Component | Profile Registration | Usage | PRP |
Profile Registration | Autonomous | Profile Registration | Usage | SelfPRP |
lists the class adaptations defined in the three example profiles and in this profile , to the extent they are relevant for this scenario.
Profile | Adaptation | Schema Class | Base Adaptation | Profile Reference Name (of Base Adaptation) |
---|---|---|---|---|
Example Base Server |
ComputerSystem
(central + scoping element) |
CIM_ComputerSystem |
ScopingElement
(implied) |
PRP |
CentralElement
(implied) |
PRP | |||
System | SystemFan | |||
System | SystemPowerSupply | |||
Example Fan |
System
(scoping element) |
CIM_System |
ScopingElement
(implied) |
PRP |
SystemDevice | CIM_SystemDevice | |||
Fan
(central element) |
CIM_Fan |
CentralElement
(implied) |
PRP | |
Example Power Supply |
System
(scoping element) |
CIM_System |
ScopingElement
(implied) |
PRP |
SystemDevice | CIM_SystemDevice | |||
PowerSupply
(central element) |
CIM_PowerSupply |
CentralElement
(implied) |
PRP | |
Profile Registration |
RegisteredProfile
(central + scoping element) |
CIM_RegisteredProfile |
ScopingElement
(implied) |
SelfPRP |
CentralElement
(implied) |
SelfPRP | |||
ReferencedRegisteredProfile
(implied) |
Profile Registration profile implementation in context of referenced profile | |||
ElementConformsToProfile | CIM_ElementConformsToProfile | |||
ScopingElement | CIM_ManagedElement | |||
CentralElement | CIM_ManagedElement | |||
ReferencedProfile | CIM_ReferencedProfile | |||
ReferencedRegisteredProfile | CIM_RegisteredProfile |
lists the parts of the overall implementation that corresponds to the four profiles in the scenario, along with their profile implementation context and implemented advertisement methodology (in this example). The profile implementation context of each such part is defined by the profile reference in the referencing profile, and is stated as a path of named profile references relative to the top-level Example Base Server profile.
Profile Corresponding to the Implementation Part | Profile Implementation Context | Implemented Advertisement Methodology |
---|---|---|
Example Base Server | N/A (top-level) | central class methodology |
Example Fan | SystemFan | central class methodology |
Example Power Supply | SystemPowerSupply | scoping class methodology |
Profile Registration | PRP | central class methodology |
Profile Registration | SystemFan::PRP | central class methodology |
Profile Registration | SystemPowerSupply::PRP | central class methodology |
Profile Registration (1) |
PRP::SelfPRP
SystemFan::PRP::SelfPRP SystemPowerSupply::PRP::SelfPRP |
central class methodology |
Note (1): This implementation uses an optimization for the implementation parts that correspond to this profile . The optimization uses one single RegisteredProfile instance to advertise conformance for all three parts; such optimizations are described in DSP1001 .
lists the implemented class adaptations that are used in the object diagram.
Implemented Adaptation | Profile Implementation Context | Base Adaptation (Effective) | Profile Implementation Context (of Base Adaptation) |
---|---|---|---|
ComputerSystem | N/A (top-level) |
ScopingElement
(implied) |
PRP |
CentralElement
(implied) |
PRP | ||
System | SystemFan | ||
ScopingElement
(implied) |
SystemFan::PRP | ||
System | SystemPowerSupply | ||
ScopingElement
(implied) |
SystemPowerSupply::PRP | ||
SystemDevice | SystemFan | ||
SystemDevice | SystemPowerSupply | ||
Fan | SystemFan |
CentralElement
(implied) |
SystemFan::PRP |
PowerSupply | SystemPowerSupply |
CentralElement
(implied) |
SystemPowerSupply::PRP |
ElementConformsToProfile | PRP | ||
ElementConformsToProfile | SystemFan::PRP | ||
ElementConformsToProfile | PRP::SelfPRP | ||
ElementConformsToProfile | SystemFan::PRP::SelfPRP | ||
ElementConformsToProfile | SystemPowerSupply::PRP::SelfPRP | ||
RegisteredProfile | PRP | ||
RegisteredProfile | SystemFan::PRP | ReferencedRegisteredProfile (implied) | PRP |
RegisteredProfile | SystemPowerSupply::PRP | ReferencedRegisteredProfile (implied) | PRP |
RegisteredProfile (1) |
PRP::SelfPRP
SystemFan::PRP::SelfPRP SystemPowerSupply::PRP::SelfPRP |
ReferencedRegisteredProfile (implied) |
PRP
SystemFan::PRP SystemPowerSupply::PRP |
ReferencedProfile | PRP | ||
ReferencedProfile | SystemFan::PRP | ||
ReferencedProfile | SystemPowerSupply::PRP |
Note (1): This implementation is an optimization that merges three separate implementations into one implementation, as defined in DSP1001 .
The object diagram in the following figure shows an example set of instances in this scenario. The implementation follows the recommendation to separate the implementation namespace from the Interop namespace , and it implements the requirement to advertise conformance to this profile through itself.
Simple object diagram
In this scenario, the
system1
instance representing a managed system, the
fan1
instance representing a fan in that system, and the
ps1
instance representing a power supply in that system are all exposed in the
implementation namespace
"ABCCorp".
The Interop namespace contains four instances of RegisteredProfile that advertise conformance to the Example Base Server, Example Fan, and Example Power Supply profiles, and to the Profile Registration profile (that is, this profile ).
Profile conformance
for the
ps1
instance is determined through the
scoping class methodology
because that instance is not referenced by any
ElementConformsToProfile
instances.
Profile conformance
for the
fan1
,
system1
and the four
RegisteredProfile
instances is determined through the
central class methodology
because these instances are referenced by the
ManagedElement
end of an
ElementConformsToProfile
association instance.
Because some of the
ElementConformsToProfile
instances cross namespaces, the instances of these associations exist in both namespaces.
The associated instances exist in only one of the namespaces. For example, the
ElementConformsToProfile
instance between
system1
and
prof1
has an instance in each of the two namespaces. In the instance in the
implementation namespace
,
ManagedElement
is a reference to the
system1
instance in the same namespace, and
ConformantStandard
is a cross-namespace reference to the
prof1
instance in the
Interop namespace
. In the instance in the
Interop namespace
,
ConformantStandard
is a reference to the
prof1
instance in the same namespace, and
ManagedElement
is a cross-namespace reference to the
system1
instance in the
implementation namespace
. See
subclause "Cross-namespace associations"
for more information about cross-namespace associations.
The scenario defined in this state description is used by some of the following use cases.
For the scenario defined in the SimpleStateDescription state description, this use case describes how a CIM client can retrieve profile information for an instance of the ComputerSystem adaptation. In that scenario, the Example Base Server profile (defining the ComputerSystem adaptation) is an autonomous profile .
This use case has the following preconditions:
The instance path of a ComputerSystem instance (in the implementation namespace ) is known.
It is known that the Example Base Server profile is an autonomous profile and thus the implementation will always use the central class methodology .
The main flow for this use case consists of the following steps:
Invoke the Associators( ) for ElementConformsToProfile operation on that ComputerSystem instance. The resulting RegisteredProfile instances represent all profiles to which that ComputerSystem instance conforms.
Iterate through the retrieved RegisteredProfile instances and inspect their RegisteredOrganization , RegisteredName and RegisteredVersion property values, which identify the profiles to which the ComputerSystem instance conforms.
For the scenario defined in the SimpleStateDescription state description, this use case describes how a CIM client can retrieve the version of the Example Fan profile to which an instance of the Fan adaptation conforms. In that scenario, the Example Fan profile (defining the Fan adaptation) is a component profile and has been implemented using the central class methodology .
This use case has the following preconditions:
The instance path of a Fan instance (in the implementation namespace ) is known.
It is known that the Example Fan profile is a component profile and that it has been implemented using the central class methodology .
The main flow for this use case consists of the following steps:
Invoke the Associators operation on the given Fan instance, filtering on the ElementConformsToProfile association. This will retrieve all RegisteredProfile instances representing profiles to which that Fan instance conforms. In this scenario, only one RegisteredProfile instance representing the Example Fan profile will be returned.
The value of its RegisteredVersion property indicates the version of the Example Fan profile to which the given Fan instance conforms.
For the scenario defined in the SimpleStateDescription state description, this use case describes how a CIM client can retrieve the version of the Example Power Supply profile to which an instance of the PowerSupply adaptation conforms. In that scenario, the Example Power Supply profile (defining the PowerSupply adaptation) is a component profile and has been implemented using the scoping class methodology .
This use case has the following preconditions:
The instance path of a PowerSupply instance (in the implementation namespace ) is known.
It is known that the Example Power Supply profile is a component profile and that it has been implemented using the scoping class methodology .
The main flow for this use case consists of the following steps:
Invoke the Associators operation on that PowerSupply instance, filtering on the SystemDevice association. This will retrieve the (one) ComputerSystem instance that is the scoping instance of the PowerSupply instance.
Invoke the Associators operation on that ComputerSystem instance, filtering on the ElementConformsToProfile association. This will retrieve all RegisteredProfile instances representing profiles to which that ComputerSystem instance conforms. In this scenario, only one instance representing the Example Base Server profile will be returned.
Invoke the Associators( ) for ReferencedProfile operation on the returned RegisteredProfile instance representing the Example Base Server profile. This will retrieve all RegisteredProfile instances representing profiles referenced by the Example Base Server profile. In this scenario, three instances will be returned, representing the Example Power Supply, Example Fan, and Profile Registration profiles.
Iterate through these retrieved instances and select the Example Power Supply profile based on the values of its RegisteredOrganization and RegisteredName properties. The value of its RegisteredVersion property indicates the version of the Example Power supply profile to which the PowerSupply instance conforms.
For the general case, this use case describes the algorithm for a CIM client to determine to which profiles a central instance of a given profile conforms, when the advertisement methodology implemented for that profile and for its scoping profiles is not known upfront.
This use case has the following preconditions:
The instance path of a central instance of a given profile is known.
The profile reference and scoping hierarchies between the given profile and its top-level autonomous profile is known, including the scoping path of each of those profiles .
Note that component profiles may define scoping elements that are not the central elements of their referencing profiles. For example, in the SimpleStateDescription scenario, the Example Fan profile could reference an additional Example Sensors profile that defines a scoping adaptation named System, that matches the ComputerSystem adaptation of the Example Base Server profile.
The main flow for this use case consists of the following steps:
Invoke the Associators( ) for ElementConformsToProfile operation on the central instance .
If this operation returns one or more RegisteredProfile instances, the profile has been implemented using the central class methodology , and each (typically one) returned instance represents a profile to which the central instance advertises conformance.
Their RegisteredOrganization , RegisteredName , and RegisteredVersion properties of the returned instances identify these profiles .
If this operation returns no RegisteredProfile instances, the profile has been implemented using the scoping class methodology ; in that case, follow these steps:
Navigate from the central instance to its scoping instance by following the scoping path defined in the profile .
Invoke the Associators( ) for ElementConformsToProfile operation on that scoping instance . This returns the RegisteredProfile instances representing the profiles to which the scoping instance advertises conformance.
If this operation returns one or more RegisteredProfile instances, the profiles of the scoping instance have been implemented using the central class methodology , and each (typically one) returned instance represents a profiles to which the scoping instance advertises conformance.
Go to step 4.
If this operation returns no RegisteredProfile instances, the scoping profiles also have been implemented using the scoping class methodology , and step 3 needs to be recursively repeated until a scoping instance is reached that returns such instances. After that is reached, each (typically one) returned instance represents a profile to which the scoping instance advertises conformance.
Go to step 4.
At this point, at least one RegisteredProfile instances representing profiles to which the top-most scoping instances advertise conformance.
Select the profile of those top-most profiles that directly or indirectly references the profile in which you are interested.
Invoke the Associators( ) for ReferencedProfile operation on the RegisteredProfile instance representing the selected top-most profile, and repeat that operation recursively on its result, such that you traverse as many profile levels down as you had to traverse profile levels up to the top-most profile in step 3. At each level, if more than one instance is returned, select the profile that directly or indirectly references the profile in question.
The RegisteredProfile instances resulting from the last such traversal represent the profiles to which the original central instance advertises conformance.
Their RegisteredOrganization , RegisteredName , and RegisteredVersion properties of the returned instances identify these profiles .
The following figure
is an object diagram for this use case and illustrates an implementation that conforms to
the Example Fan profile described in the
SimpleStateDescription
scenario. The diagram shows some additional class adaptations defined in the Example Fan
profile (compared to that scenario); schema classes are stated in the object diagram only
for these additional adaptations. The
central instances
of the Example Fan profile are the two Fan instances,
fan1
and
fan2
.
The instances of adaptations defined in a profile form a graph, where those instances can be reached by association traversal from the central instances of that profile . Knowing the structure of this graph for the Example Fan profile, a CIM client can navigate to all these instances starting from the central instances of that profile , and can conclude from the existence of these instances that they conform to the Example Fan profile.
This use case determines all instances of ordinary adaptations conforming to the Example Fan profile, given the set of all central instances of that profile . Note that association instances conforming to the Example Fan profile are not determined in this use case; they could be determined by using the References() operation.
Redundant fans object diagram
This use case has the following preconditions:
The instance paths of all central instances of the Example Fan profile are known.
The navigation graph between instances of all adaptations defined in the Example Fan profile is known.
The main flow for this use case consists of the following steps:
For each
central instance
and for each association adaptation defined in the Example Fan profile that
starts at the Fan adaptation, invoke the
Associators( )
operation on that instance, filtering on the association class and result class
of that association traversal. This will retrieve all conforming instances of
ordinary classes one hop away from the
central instance
; in this case, the RedundancySet instance
fanrset1
and the
RegisteredProfile
instance
profile2
.
Repeat step 1 recursively for its resulting instances, until there are no more
traversable adaptations defined in the Example Fan profile. This will retrieve
the remaining set of conforming instances of ordinary classes; in this case, the
ComputerSystem instance
system1
.
For the general case, this use case describes the algorithm for a CIM client to determine the set of profiles advertised by a WBEM server.
This use case has the following preconditions:
The namespace path of the Interop namespace of the WBEM server is known.
The main flow for this use case consists of the following steps:
Invoke the EnumerateInstances( ) operation on the class of the RegisteredProfile adaptation in the Interop namespace .
This will retrieve the RegisteredProfile instances representing all profiles to which the WBEM server advertises conformance.
Iterate through these retrieved instances and inspect the values of their RegisteredOrganization , RegisteredName , and RegisteredVersion properties, which identify these profiles.
For the general case, this use case describes the algorithm for a CIM client to determine the top-level profiles advertised by a WBEM server. Top-level profiles of an implementation are those that are not referenced by any other profiles to which the implementation conforms. This is accomplished by determining which instances of RegisteredProfile are not antecedents for any ReferencedProfile associations.
Typically, top-level profiles are autonomous profiles that represent the largest scoping of the CIM representation of the target system and that reference component profiles . Note that autonomous profiles may be referenced by other profiles .
This use case has the following preconditions:
The namespace path of the Interop namespace of the WBEM server is known.
The main flow for this use case consists of the following steps:
Invoke the EnumerateInstances( ) operation on the class of the RegisteredProfile adaptation in the Interop namespace .
This will retrieve the RegisteredProfile instances representing all profiles to which the WBEM server advertises conformance.
Invoke the AssociatorNames( ) operation on the class of the RegisteredProfile adaptation in the Interop namespace , filtering on the class of the ReferencedProfile association adaptation and on source role Antecedent.
This will retrieve the instance paths of the RegisteredProfile instances representing all profiles to which the WBEM server advertises conformance and that are referenced by other such profiles .
Reduce the set of all profiles (retrieved in step 1) by the set of referenced profiles (retrieved in step 2), by means of comparing the values of their RegisteredOrganization , RegisteredName , and RegisteredVersion properties, which identify these profiles . This results in the set of all top-level profiles to which the WBEM server advertises conformance.
For the scenario defined in the SimpleStateDescription state description, this use case describes how a CIM client can determine the central instances of the Example Fan profile. In that scenario, the Example Fan profile is a component profile and has been implemented using the central class methodology .
This use case has the following preconditions:
The instance paths of any RegisteredProfile instances advertising conformance of the implementation to the Example Fan profile are known.
These instance paths can be determined as described in use case AlgorithmForDeterminingAdvertisedProfiles . Note that an implementation may expose more than one such instance.
The main flow for this use case consists of the following steps:
For each RegisteredProfile instance for the Example Fan profile, invoke the Associators( ) for ElementConformsToProfile operation on that instance.
Because the Example Fan profile has been implemented using the central class methodology , the central instances of the Example Fan profile are returned.
If no instances are returned, the profile may not currently have any central instances . For example, the implementation may have chosen to represent pluggable fans as Fan instances only if they are plugged in, and the system may have no fans plugged in, currently. Note that older profiles require that an implementation exposes at least one central instance at any time.
Aggregate the central instances returned from all these invocations into one set.
This set is the set of central instances of the Example Fan profile, for this implementation.
For the scenario defined in the SimpleStateDescription state description, this use case describes how a CIM client can determine the central instances of the Example Power Supply profile. In that scenario, the Example Power Supply profile is a component profile and has been implemented using the scoping class methodology .
This use case has the following preconditions:
The instance paths of any RegisteredProfile instances advertising conformance of the implementation to the Example Power Supply profile are known.
These instance paths can be determined as described in use case AlgorithmForDeterminingAdvertisedProfiles . Note that an implementation may expose more than one such instance.
It is known that the scoping profile of the profile in question is an autonomous profile (in this scenario, the Example Base Server profile). Therefore, the central class methodology will be supported at the level of that scoping profile .
The main flow for this use case consists of the following steps:
For each RegisteredProfile instance for the Example Power Supply profile, invoke the Associators( ) for ReferencedProfile operation on that instance, filtering on the class of the ReferencedProfile association adaptation and on source role Antecedent.
This will return RegisteredProfile instances for the Example Base Server profile. Aggregate the instances returned from all these invocations into one set, and reduce the set by eliminating any duplicate instances. Note that the resulting set may contain more than one instance.
For each instance in the resulting set, invoke the Associators( ) for ElementConformsToProfile operation on that instance.
Because the Example Base Server profile is an autonomous profile, the implementation will always use the central class methodology , and the central instances of the Example Base Server profile (that is, ComputerSystem instances) are returned.
If no instances are returned, the Example Base Server profile may not currently have any central instances . In this case, the Example Power Supply profile also has no central instances .
For each central instance of the Example Base Server profile, navigate across the scoping path of the Example Power Supply profile to its central instances by invoking the Associators operation on these instances, filtering on the association class of the SystemPowerSupplyDevice adaptation, and on the target class of the SystemPowerSupply adaptation.
Note that the filters used in this association traversal operation are tight enough to not return any undesired Fan instances.
Aggregate the SystemPowerSupply instances returned from all these invocations into one set.
This set is the set of central instances of the Example Power Supply profile, for this implementation.
Note to reviewers: This use case may not cover all cases at this point and deserves particular review. If we don't get it complete and specific enough, we need to remove it again or state the restrictions.
This use case describes for the general case the algorithm for a CIM client to determine the central instances of a given profile that is advertised by a WBEM server, when the advertisement methodology implemented for that profile and for its scoping profiles is not known upfront.
This use case has the following preconditions:
The namespace path of the Interop namespace of the WBEM server is known.
The profile reference hierarchy between the given profile and its top-level autonomous profile is known, including the scoping path of each of those profiles .
The main flow for this use case consists of the following steps:
Invoke the EnumerateInstances( ) operation on the class of the RegisteredProfile adaptation in the Interop namespace .
This will retrieve the RegisteredProfile instances (and their instance paths) representing all profiles to which the WBEM server advertises conformance.
Out of the returned RegisteredProfile instances, determine the subset of instances where the values of their RegisteredOrganization , RegisteredName , and RegisteredVersion properties match the given profile .
If that subset contains more than one instance, repeat the following steps for each such instance. Note that there is no requirement that multiple implementations of the same profile in a WBEM server use the same RegisteredProfile instance for advertising conformance.
Navigate to the RegisteredProfile instance representing the next scoping profile that has implemented the central class methodology , by following these steps, starting from the RegisteredProfile instance:
Invoke the Associators( ) for ElementConformsToProfile operation on the RegisteredProfile instance.
If one or more instances are returned, the profile has implemented the central class methodology ; Return from this recursive invocation of step 3.
If no instances are returned, the profile has implemented the scoping class methodology ; Continue with the following steps.
Invoke the Associators( ) for ReferencedProfile operation on the RegisteredProfile instance, filtering on the target role Dependent.
This will return the RegisteredProfile instances representing the referencing profiles of the profile.
Recursively invoke step 3 for the RegisteredProfile instance representing the scoping profile of the profile.
Now that you have determined an instance of RegisteredProfile that represents the next scoping profile that uses the central class methodology . Invoke the Associators( ) for ElementConformsToProfile operation on that RegisteredProfile instance. This returns the central instances of that profile.
Based on knowledge about the scoping paths of each profile in the chain of referencing profiles whose RegisteredProfile instances were traversed in the previous steps, construct the effective scoping path between the originally given profile to the next scoping profile that uses the central class methodology .
Each of the central instances returned in step 4, is also a scoping instance in that effective scoping path. Navigate from each of these scoping instances across the effective scoping path to the central instances . The resulting instances are the central instances of the originally given profile.
For the general case, this use case describes the algorithm for a CIM client to determine whether a profile represented by a given RegisteredProfile instance has been implemented using the central class methodology or the scoping class methodology .
This algorithm is based on whether ElementConformsToProfile associations are directly linked to the given instance of RegisteredProfile .
This use case has the following preconditions:
The instance path of a RegisteredProfile instance (in the Interop namespace ) is known.
The main flow for this use case consists of the following step:
Invoke the Associators( ) for ElementConformsToProfile operation on the given RegisteredProfile instance.
If one or more instances are returned, the central class methodology has been implemented.
If no instances are returned, the scoping class methodology has been implemented.
If the profile represented by the given RegisteredProfile instance is an autonomous profile , the scoping class methodology also has been implemented at the same time, because for autonomous profiles , both advertisement methodologies fall together and result in the same implementation.
This scenario illustrates the relationship between RegisteredProfile instances for a component profile (Example Fan) that references another component profile (Example Sensors).
In this scenario, it is assumed that the Example Sensors profile has been implemented for speed sensors of the fans for which the Example Fan profile has been implemented. The Example Fan profile is the scoping profile for the Example Sensors profile, and the reference to the Example Sensors profile in the Example Fan profile is represented using ReferencedProfile instances between the respective RegisteredProfile instances.
Referencing component profiles object diagram
The following figure depicts the hierarchy of RegisteredProfile instances associated through ReferencedProfile instances that would represent a modular system with a chassis manager and an included blade server with RAID storage. This figure is provided as an example to illustrate the nature of the relationships among the various autonomous and component profiles . Also depicted are the relationships between component profiles .
Profile compliance hierarchy object diagram
Version | Date | Description |
---|---|---|
1.0.0 (prelim) | 2006-12-06 | Released as a Preliminary Standard |
1.0.0 | 2007-06-25 | |
1.1.0a | 2013-02-23 |
Released as Work in Progress, with the following changes:
|
DMTF DSP0206, WBEM SLP Template 2.0,
http://www.dmtf.org/standards/published_documents/DSP0206_2.0.0.txt
DMTF DSP1054, Indications Profile 1.2,
http://www.dmtf.org/standards/published_documents/DSP1054_1.2.pdf