Types of Provider

The following list summarises the types of provider normally supported by a WBEM server; each is described in more detail below.

• Method Providers handle calls to extrinsic methods : general-purpose calls to instances of classes. These calls may do anything relevant to the class being invoked.

• Instance Providers handle the creation, enumeration (i.e., listing) and deletion of instances of particular classes.

• Property Providers handle operator requests for getting and setting properties on an instance.

• Association (or Associator) Providers handle the creation, deletion and general handling of associations between classes or instances.

• Indication (or Indicator) Providers handle events and alarms raised in the system being managed: filtering them and passing them to programs registered to receive them (this functionality is similar to that of the CORBA event and notification services).

• Query Providers handle database-style queries.

Although their functions differ , a single piece of code may implement more than one type of provider: a module may be an instance provider, a property provider and an association provider. Furthermore, many functions can be carried out by different types of provider ”modifying a property on an instance might be carried out at different times by a Property Provider, an instance provider or a method provider. The choice of provider type is a design decision.

In general, providers are associated with dynamic entities: counters that are updated by external events, associations that are formed when services are created, etc. Static entities (classes and static instances) generally do not need providers ”they can be defined in the mof code and loaded once into the WBEM server. The WBEM server will then effectively act as a provider to respond to queries about these classes and instances.

In the C++ world, providers are typically compiled to dynamically linked libraries (.so or .dll) loaded by the WBEM server as required. The WBEM server will then automatically unlink a provider that has not been used for some time (and has not been locked in memory).

Method Providers

A "method" is an extrinsic function defined for a particular class. Such a function may perform any operation on a managed object: a call to a method provider from a WBEM client is effectively a two-way Remote Procedure Call (RPC). The WBEM client specifies the instance on which the procedure is to be invoked, the name of the method and its parameters. The WBEM server invokes the method provider defined for that method for that class and returns the values generated.

If you have CORBA experience, you may interpret this process as a Remote Procedure Call (which it is) and expect the WBEM server to check the type correctness of the parameters and refuse to invoke a method provider if the parameter types are wrong. Generally, WBEM servers do not do this (although the specification is silent on the subject and it is left to the developers of the WBEM server), relying instead on the method provider to do the parameter checking. See FAQ 20 on page 84.

An example might be a method provider for a high-level service, providing a means of shutting the service down:

 void shutdown(boolean immediately); 

The same result could be obtained by using a Property Provider and by relying on the side effect of changing a Property's value, as is required in SNMP. For example, you could define a Property called something like RequiredState and then allow an operator to set this to a value of ShuttingDownNow . A Property Provider could then note this change and, as a side effect of the change, carry out the required function. This is less natural than simply calling a shutdown(true) method and much harder to use if complex parameters are involved or if several parameters need to be modified simultaneously (atomically).

The types of parameters which can be passed to a method provider are the normal CIM types: signed and unsigned integers of 8, 16, 32, and 64 bits; strings and characters ; Booleans; 4- and 8-octet floating point numbers and dates/times.

A method provider is required to provide a single function: invoke-Method .

Instance Providers

An instance provider manages the dynamic instances of a class. In some applications, instances of a class may be created and deleted by an operator. In this case the instance provider may maintain a list of instances (possibly stored in nonvolatile memory). In other applications it may be inappropriate for the operator to be able to create and delete instances (for example, in many applications it makes no sense for an operator to create a new instance of the operating system).

Typically, the instance provider maintains a list of instances either by responding to operator requests or by scanning the real equipment to see what has been fitted. Of course, in the latter case, the list can be "virtual," being recreated from the hardware each time it is required.

For example, when a router is first installed, there is no way for the WBEM server to know a priori how many ports of particular types have been installed. An instance provider would communicate directly with the low-level drivers to determine the number of ports. If this information were requested by a WBEM client, then the WBEM server would invoke the instance provider to retrieve it. When instances of a class can be defined statically in advance ("there are always exactly two instances of the power supply: called PS2 and PS2"), they can be configured in a mof specification and no instance provider is required, although one could be provided ”it would be invoked as the instances defined in the mof are compiled and loaded into the repository. Even in this case, an explicit provider might be useful since it could prevent a malicious or faulty WBEM client from creating another instance ”the creation request would be routed to the provider which could reject it.

An Instance Provider typically implements the following functions:

• getInstance() : Retrieve and return a particular instance

• enumerateInstances() : List all available instances

• enumerateInstanceNames() : List the names of all instances

• modifyInstance() : Modify an instance ”similar to the action of a Property Provider

• createInstance() : Create an instance (reasonably enough, given the name)

• deleteInstance() : Delete an instance (eponymously)

Property Providers

Properties associated with a managed object can be either static or dynamic. A name, for example, might be permanently and statically associated with a device, whereas a field containing a count of the number of packets which have passed through a particular port would be dynamic. This counter changes rapidly and needs to be read from the physical device when requested by an operator. The WBEM server uses a property provider to extract the actual value of the counter only when it receives a request for it.

A Property Provider will typically provide the following methods:

• getProperty() or getPropertyValue() : Get the value of a property

• setProperty() or setPropertyValue() : Set the value of a property

As we saw on page 128, the client-side interface does not need to support getProperty() and setProperty() and some of the implementations of the WBEM servers do not actually support the concept of property providers ”relying instead on instance providers to return an instance, including the required properties.

Association Providers

An Association Provider, sometimes called an "Associator Provider," is able to build, destroy, list, and generally manipulate associations between components dynamically.

For example, imagine that an OSPF Service ^[1] has been dynamically created on a particular device and that the operator now adds an OSPF Area. This OSPF Area must be linked to the OSPF Protocol Endpoints which it contains. An association is defined in the standard DMTF models for this: EndPointInArea .

Because this association is created dynamically, it will be supported by an association provider to keep track of the instances of the association.

This type of provider is an extremely powerful tool for connecting loosely coupled instances as it can answer questions of the type: "With which OSPF Areas is this particular OSPF Protocol Endpoint associated?" or "Through which associations is instance X of class Y associated with instance Q of class R?"

An association provider will typically implement the following functions:

• associators() : Return a list of instances associated with (i.e., linked to) a particular instance by a particular association (in case the provider supports more than one type of association). For example, return a list of all objects with which the OSPF Service myOspfService is associated.

• associatorNames() : Return a list of names of instances associated with a particular instance by a particular association (in case the provider supports more than one type of association). For example, return a list of the names of all objects with which the OSPF Service myOspfService is associated.

• references() : Return a list of all instances of associations referring to a given instance. For example, what associations connect the OSPF Service myOspfService to other objects?

• referenceNames() : Return a list of the names of all instances of associations referring to a given instance. For example, what associations connect the OSPF Service myOspfService to other objects?

Note that, as described on page 139, a WBEM client may invoke an intrinsic method to manipulate associations for either classes or instances. Those invoked on classes ("With which classes is class X associated?") are handled by the WBEM server itself and do not find their way to a provider. The provider described here will only handle requests for instances.

Indication Providers

This provider differs from the others in that it does not simply respond to requests from the WBEM server ”it is activated by an external event of some type and initiates communication with the WBEM server. Of all of the provider types this is the one with the least standardisation across WBEM server implementations, although a standardisation process is in progress, driven by the openPegasus, SBLIM, and other teams .

Before reading this section, you may wish to review the whole indication process which I described in Chapter 8, particularly the section on subscriptions starting on page 160. Armed with that information, it is worthwhile considering in a general way the interfaces which an indication provider will require:

• It will require a mechanism to allow it to inform the WBEM server of an indication. This is known as "publishing" in CIM-speak.

• It will require a mechanism that allows it to validate listeners which want to receive its indications ("subscribing" to those indications ); because the provider is the authority for notification delivery, there will have to be some way for the WBEM server to ask the provider whether a certain subscription should be allowed. The provider may, in its turn , access some central or distributed authentication and authorisation server.

• Although not essential, for efficiency it will require a mechanism for the WBEM server to inform the provider that no one has subscribed for one or more of the indications it raises. This knowledge would allow the provider to suppress the generation of the indications. Of course, it must also be able to switch the indications back on when a subscription is created.

The last two of these mechanisms are provided by a small number of functions which the indication provider must support:

• authorizeFilter() . The WBEM server calls this function when a client creates a subscription. It effectively asks the provider whether this particular client is authorised to receive the indications associated with the filter. How the provider determines this is, of course, outside the specification of the process ”it might have a local, compiled-in table, might accept any client or might contact some external authorisation device. The provider might also reject the authorisation on grounds other than the authority of the client ”perhaps the filter would be too expensive to use because of its processing time or memory needs.

• activateFilter() . This function is also called by the WBEM server when a client creates a subscription for one or more of the indications for which the provider is responsible. If this is the first subscription for a particular indication then the provider can take this as a request to start generating notifications of the indication.

• deActivateFilter() . This is, of the course, the opposite of activateFilter . It tells the provider that a subscription has been deleted and, if that was the last subscription for a particular indication, allows the provider to stop generating notifications of the indication.

• mustPoll() . This is a dangerous function call. It is designed to allow particularly simple indication providers to be written ”if the provider responds to this call with true, then, instead of it having to generate indications asynchronously, it will be called by the WBEM server at regular intervals (through the instance provider interfaces) to see whether an alarm has occurred. It does not need much imagination to see how this could very quickly become inefficient if misused.

The first mechanism on my list above, that of actually informing the WBEM server that an indication has been raised, is covered by allowing the indication provider to create an instance of the appropriate indication class ”effectively to act as a WBEM client and create an instance. At present this is achieved in different ways in different WBEM server implementations.

Query Providers

This type of provider handles the ExecQuery() intrinsic method which can be invoked by a WBEM client (see page 139). It typically provides only one interface: ExecQuery().

^[1] OSPF ( Open Shortest Path First) is an IP routing protocol used within a network to distribute routing tables amongst all routers ”see Glossary.