SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles
 |
SNIA Profiles |
 |
Profiles |
Subprofiles |
Packages
Fabric Topology |
Server |
Storage |
Host
A SNIA Profile defines the base set of information and capabilities that all implementations must make available to allow a Client to manage a particular SAN device such as a disk array. It defines the classes that a Client will use to perform a particular management task in a SAN. The Profile also defines the associations that will be used to traverse between classes. In addition to identifying the classes used, a Profile also defines the properties and extrinsic methods of each class that must be supported. In certain cases, the Profile even specifies the values a property or method argument must have.
In many Profiles, one class is identified as the entry point for managing the implementation for the Profile. This class is called the top level system. Starting with this class, a Client traverses the associations defined in the Profile to access the properties or extrinsic methods contained in the other classes.
A Profile can allow a Client to be notified when a particular event occurs. To be notified, a Client must subscribe for an Indication using the filter defined in the Profile. Additionally, the SMI Agent must be able to detect such changes in its environment and deliver the notification to subscribed Clients. A Profile defines all filters that a Client can use and that an SMI Agent must recognize and support.
A Profile can define Recipes that a Client may use to perform a particular management task on the elements managed by the Profile. Using comments and PERL-like expressions, a Recipe describes the specific WBEM operations that must be performed, the order in which they must be performed and the argument values to be used for each WBEM operation.
A Profile can define Subprofiles which represent additional capability that a vendor can choose to make available. Like Profiles, Subprofiles define the classes, properties and extrinsic methods that must be implemented to support its functionality. However, implementation of Subprofiles is considered optional because some vendors may not offer the Subprofile functionality in their product. For example, some disk array products do not support the ability to create snapshots or replicas.
A Profile can incorporate Packages. Like Profiles, a Package defines the classes, properties and extrinsic methods that must be implemented to support its functionality. However, unlike Subprofiles, implementation for the classes, properties and extrinsic methods in a Package is mandatory, not optional. In other words, when a Package is referenced by a Profile, all of its CIM elements are considered to be part of the Profile.
A Profile specifies the standards upon which the Profile is based. For example, in SMI-S 1.1.0, the Array Profile is based upon the CIM Schema version 2.11, the CIM Operations over HTTP Specification version 2.3 and the CIM Infrastructure Specification version 1.2.
WBEM operations are grouped by function into sets of operations called functional profiles. For example, the Basic Read functional profile consists of read operations such as GetInstance and EnumerateInstances. A Profile defines the functional profiles that a SMI Agent must support. For example, the Array Profile specifies that the SMI Agent must support the Basic Read, Association Traversal and Indications functional profiles.
In SMI-S 1.1.0, the Profile elements described above are explicitly defined in Extensible Markup Language (XML) files, one XML file for each Profile. For example, the Array Profile is defined in Array.xml.
In SMI-S 1.1.0, the following groups of Profiles have been defined:
- Storage - several Profiles have been defined to manage different types of storage devices
- Host - two Profiles have been defined to manage components attached to host
systems
- Fabric Topology - two Profiles have been defined to manage the Fabric topology
- Server - one Profile has been defined to manage the SMI Agent
|
