SNIA Developer Conference September 15-17, 2025 | Santa Clara, CA
Developing Providers
SMI Provider Development
An SMI Provider (aka WBEM Provider, provider) is a software component that translates instrumentation data into the CIM format, responds to WBEM Server requests and in some cases provides dynamic indication support (e.g. events). A WBEM Server loads and calls providers on demand in order to respond to client requests. For each CIM class being implemented, a separate provider is created. Developers may want to consider using code generation tools to speed up the development process. See the Development Tools on the Resource page for tools that may aid in speeding up the development process and lower the number of defects.
A provider is written to an interface (JSR48, CMPI, proprietary, ...) provided by a WBEM Server. While the interfaces may differ, due to programming language and WBEM Server handling, all interfaces are modeled, using concepts, from the Generic Operations specification defined by the DMTF. The Generic Operations specification defines the operations a client uses to access a WBEM Server. The Generic Operations specification defines schema operations and instance operations. Schema operations are handled by the WBEM Server and providers can ignore them. The provider interfaces are loosely modeled using the instance and indication operations. When the Generic Operations was first defined it did not include asynchronous operations (aka pull operations). Pull operations were added in a subsequent release and as of SMI-S 1.6.0, pull operations shall be supported. Many of the provider interfaces were updated, such that only the pull operations need to be implemented, but the developer should verify this by reviewing the interface requirements for the selected WBEM Server.
There are two types of providers
- End Point - providers which represent concrete elements, such as a computer system, disk drives and storage pools.
- Association - providers which show a relationship, for example an associator would show which disk drives make up a specific storage pool.
The following operation concepts are defined in the Generic Operations and need to be handled by providers. The table below shows the operation concept, description, the provider type that the operation concept applies and the requirement. For example, very few providers will be required to support the Create/Delete/Modify operations.
| Operation | Description | Provider Type | Requirement |
|---|---|---|---|
| GetInstance | Return the CIM instance requested. | ALL | Mandatory |
| DeleteInstance | Delete the CIM Instance requested. This may require the provider to delete something on the device, such as a storage pool or storage volume, or it may be the deletion of setting data that the provider maintains. | ALL | Conditional Only when section 5 of the profile requires for a specified class. |
| ModifyInstance | Modify the CIM Instance requested. This may require the provider to modify something on the device, such as a storage pool or storage volume, or it may be the modification of setting data that the provider maintains. | ALL | Conditional Only when section 5 of the profile requires for a specified class. |
| CreateInstance | Create the CIM Instance requested. This may require the provider to create something on the device, such as a storage pool or storage volume, or it may be the creation of setting data that the provider maintains. | ALL |
Conditional Only when section 5 of the profile requires for a specified class. |
| OpenEnumerateInstances | Return all instances of a class, for example if a device has 5 storage pools and a client makes an EnumerateInstances request for storage pools the provider would be responsible for returning 5 instances. | ALL | Mandatory |
| OpenAssociators | The client passes in information on one of the endpoints, the provider must return the element(s) that are related. For example the CIM_AllocatedFromStoragePool associates a pool to the volumes that have been created from it. If a client called the Associators operation passing in a CIM_StoragePool instance, the provider would be responsible for returning all of the CIM_StorageVolume instances that had been created out of that pool. | Association | Mandatory |
| OpenReferences | The client passes in information on one of the endpoints, the provider must return the instances of the association class. For example if a client called the references operation passing a CIM_StoragePool the association provider would be responsible for returning the CIM_AllocatedFromStoragePool instances | Association | Mandatory |
| InvokeMethod | Execute the method. The method may include input and output arguments that the provider must need to handle. | ALL |
Conditional only if a method is supported for the class. |
Some providers may also be required to handle Indications. Indications are mechanisms a client can use to be notified when certain events occur (e.g. the creation of a storage volume).
There are 2 types of indications
- Life Cycle - Life Cycle Indications are the representation of the creation, deletion and modification for an element represented by a CIM class. For example, a new disk drive may be added to a system. If an SMI Listener is subscribed for the InstCreation life cycle indication for CIM_DiskDrive, the provider is responsible tracking the changes of the device and sending the indication to the listener.
- Alert - Alert indications are usually events that occur outside the model. For example, should the device be running low on memory, it might alert an administrator via an alert indication. Alert Indications provide additional information for clients, such as Recommended Actions. It is anticipated that additional Alert Indications will be added as requirements to each revision of the specification.
The following list contains some of the issues developers need to consider during the design and development of providers.
- Scalability - A provider may deal with thousands of instances (e.g. Storage Volumes). Providers that are required to handle many instances shall be designed to return instances to the server as quickly as possible. The provider, when possible, should not wait until all information is received from the instrumentation API prior to responding to the server. For example, the provider may create a thread and return the data as quickly as it creates it, while still gathering additional data from the instrumentation API(s). This will allow the WBEM Server to respond to the client as it receives the data, thereby using less memory.
- Job Control - A provider that supports a method may have to handle Job Control. A method invocation that may take a longer time to complete will return a job that can be monitored by the client. The job is represented by the CIM_ConcreteJob instance that may be monitored to determine the status or progress of the job. Indications may also be used to monitor the progress of a job. Once completed the result information can be retrieved from the associated CIM_MethodResult instance. Some of the infrastructures provide support for handling job control.
- Cache - A provider may utilize multiple or slow instrumentation interfaces when building a CIM Instance. Providers shall ensure that response times are acceptable to SMI Clients and may need to cache data to ensure performance is acceptable. When caching data, the provider shall ensure that the data is in synch with the storage device. Some implementations expose the management of the cache to allow administrators to flush and regenerate the cache.
- Indication Polling - An instrumentation API may not support dynamic event notification for some of the mandatory SMI-S indication filters. The provider may need to poll the device to determine if a change has occurred and when to deliver the indication. If polling for indications, there should be one polling engine that all providers use for an implementation to ensure that resources are not wasted and performance is acceptable.