Step 3: Tie the Provider Code to the PBX Class

Having written and compiled the provider code, we have to tell the WBEM server that it exists and when to invoke it. This is done by creating instances of three classes as illustrated informally as follows :

PG_ProviderModule. This class, which is a CIM_Log-icalElement, defines a so-called ProviderModule ”a group of providers collected together into one dynamically linked library (.so or .dll file). Assuming that the instance and method providers are included in the same library file, the instance required for the PBX example is shown in Figure 12.13.
```
 // ********************************************* // create an instance of a PG_ProviderModule // to group together a number of providers // related to the PBX // ********************************************* instance of PG_ProviderModule     {     // description of the module     Description = "PBXLogicalModule";     // version of the module     Version = "1.0.0";     // version of the pegasus API definition     InterfaceVersion = "2.1.0";     // shared library name for the provider     // module, e.g., Location = "x" means     // that the shared library is libx.so     Location = "PBXLogicalCode";     // unique name for this module (not     // a particular provider)     Name = "PBXLogicalProviders";     // name of the vendor producing this     // module     Vendor = "Chris and Ying Inc";     // programming language: in this     // case C++     InterfaceType = "C++Default";     }; 
```
Figure 12.13: mof Code to Instantiate a PG_ProviderModule
Most of the properties in that example are self-explanatory, but note the following:
- InterfaceVersion defines the actual version of the openPegasus Application Program Interface (API); this is not a version number which you can choose freely .
- Location defines the actual library.
```
 Location = "PBXLogicalCode" 
```
  means that the dynamically linked library is libPBXLogicalCode.so in whichever directory is contained in the environment variable LD_LIBRARY_PATH.
- InterfaceType defines the interface which the provider will use. Currently, openPegasus only supports its own C++ interface (known as C++Default ) but in future will offer CMPI and other interfaces.

PG-Provider. An instance of PG_Provider (which also is a CIM_LogicalElement) defines each specific provider within a ProviderModule. Figure 12.14 shows the mof for the instance and method providers in the PBX example. Note that the ProviderModuleName refers back to the name of the ProviderModule defined in Figure 12.13.

 // ********************************************* // create an instance of a PG_Provider to // define the instance and method providers // within the providerModule // ********************************************* instance of PG_Provider     {     // pointer back to the ProviderModule     ProviderModuleName = "PBXLogicalProviders";     // unique name for the instance provider     // within the provider module     Name = "PbxInstanceProvider";     }; instance of PG_Provider     {     // pointer back to the ProviderModule     ProviderModuleName = "PBXLogicalProviders";     // unique name for the method provider     // within the provider module     Name = "PbxMethodProvider";     };

Figure 12.14: mof Code to Instantiate a PG_Provider

PG_ProviderCapabilities. An instance of this class (which is a CIM_ManagedElement) defines the precise capabilities of the provider ”what type of provider is it and what properties or methods does it support? The instances for the PBX example are shown in Figure 12.15 and Figure 12.16.

 // ********************************************* // create an instance of PG_ProviderCapabilities // to define precisely what our instance // provider can do // ********************************************* instance of PG_ProviderCapabilities     {     // pointer back to the ProviderModule     ProviderModuleName = "PBXLogicalProviders";     // pointer back to the ProviderName     ProviderName = "PbxInstanceProvider";     // which mof class does this provider support?     ClassName = "ACNE_PBXTelephoneModule";     // which functions does the provider provide?     // (i.e. is it an instance provider or     // method provider, etc?). Options are:     // Instance (2)   Association (3)     // Indication (4) Method (5)     ProviderType = { 2 };     // the namespaces within which this provider     // functions     NameSpaces = { "root/acnePbx" };     // a name for this set of capabilities which is     // unique within provider     CapabilityId = "1";     };

Figure 12.15: mof Code to Instantiate PG_ProviderCapabilities for Instance Provider

 // ********************************************* // create an instance of PG_ProviderCapabilities // to define precisely what our method // provider can do // ********************************************* instance of PG_ProviderCapabilities     {     // pointer back to the ProviderModule     ProviderModuleName = "PBXLogicalProviders";     // pointer back to the ProviderName     ProviderName = "PbxMethodProvider";     // which mof class does this provider support?     ClassName = "ACNE_PBXTelephoneModule";     // functions as in previous example     ProviderType = { 5 };     // the namespaces within which this provider     // functions     NameSpaces = { "root/acnePbx" };     // a name for this set of capabilities which is     // unique within provider     CapabilityId = "2";     };

Figure 12.16: mof Code to Instantiate PG_ProviderCapabilities for Method Provider

Again, most of the properties are self-explanatory but note that a provider may, for example, be both an instance provider and a property provider. The types of provider supported by the code are listed in the ProviderType property ”an enumerated value as described in the comments in Figure 12.15.

Once these instances have been defined, they need to be loaded into the repository through the WBEM server. This is achieved by putting them into a file named, say, pbxRegistration.mof, and invoking the compiler (note that the PG_InterOp namespace is used for these "linkage" instances):

 cimmof -nroot/PG_InterOp pbxRegistration.mof

As you can imagine, it is very easy to get the linkages wrong between the PG_ProviderModule, PG_Provider, PG_ProviderCapabilities, and the actual C++ libraries. As the linkages are passed as constant strings, there is no hint of a problem during the compilation process and the only indication is when the provider does not get invoked as expected ” a misspelling in the mof can take hours to track down. It would be useful to have a program which cross-checked these names but I have not found one. In the meantime use plenty of printf or cout << statements to ensure that the providers are being invoked.