Step 1: Write and Compile the mof

The first step of those given on page 211 is to write and compile the mof code for the managed object. I show the mof for the ACNE_PBXTelephoneModule class in Figure 12.1 and have typed it into the file moduleClass.mof.

 [Version ("4.5.3"), Description (     "ACNE_PBXTelephoneModule represents the logical function "     "of the 8 port telephone interface card fitted in the "     "model 34/AGB/76 PBX.") ] class ACNE_PBXTelephoneModule : CIM_LogicalModule     {     [Write,     Description ("Telephone Protocol"),     ValueMap { "0", "1", "2", "3" },     Values {"UK", "European", "NorthAmerican", "Japanese"  }  ]     uint32 Protocol;     Boolean setIndicator(Boolean newValue);     };

Figure 12.1: mof Code for the Telephone Module

Before we can invoke the mof compiler we must select a namespace for our classes. I have assumed the namespace root/acnePbx . If we try to compile our classes into this namespace then we will get an error, since the CIM_LogicalModule class is unknown in that namespace. We must therefore start by compiling the CIM schema into root/acnePbx . Each set of CIM schema as released by the DMTF has one top-level file, which consists of a series of #pragma include statements which collectively cause the whole of the CIM schema to be loaded. It is therefore only necessary to compile (load) this one file into the WBEM server. This file is normally known as CIM_SchemaXX.mof where XX is the version number.

Two versions of the openPegasus mof compiler are available to compile our two mof files and load their contents into the repository:

 cimmof -Rlocalhost:5988 -uc -aEV -aV -nroot/acnePbx                                   CIM_Schema28.mof cimmof -Rlocalhost:5988 -uc -aEV -aV -nroot/acnePbx                                   moduleClass.mof

 cimmofl -R<repository name> -nroot/acnePbx CIM_Schema28.mof cimmofl -R<repository name> -nroot/acnePbx moduleClass.mof

Both cimmof and cimmofl have a number of useful flags, which are listed by running the programs with the -h flag. These include:

-Rserver_port: Tells cimmof where to find the WBEM server. An example might be "-Rlocalhost:5988" to use a WBEM server on the local computer using an HTTP (as opposed to HTTPS) connection.
-uc: Allows a class which is already known by the WBEM server to be replaced by a new version (but only if its version number is higher than the old one).
-aEV: Allows experimental classes (i.e., classes which have not been formally accepted into the standard ”see page 88) to be compiled.
-aV: Allows both major and backward revision changes to be compiled. Normally you would expect version numbers of a class to increase monotonically: 2.7.5 going to 2.8.0 and so on. In this case, a decrease in version number would be an error. By default, therefore, cimmof and cimmofl will not allow a class definition to be replaced by one of the same name but with lower version number. Similarly, a major version change would normally require a software upgrade and this would also represent an error. The -aV flag tells cimmof and cimmofl to accept the new class definition even if these strange version number conditions occur.
-nnamespace: Specifies the namespace into which the classes and instances are to be loaded.

Both cimmof and cimmofl check the syntax of moduleClass.mof , but differ in what they do with the resulting complied output. cimmof is a full WBEM client and passes the new class to the WBEM server through the standard CIM-XML client interface, whereas cimmofl (i.e., cimmof Local ) writes the information directly into the repository. To this extent, cimmofl is dangerous, as any associated providers will not be invoked. If you are confident that you know what you are doing, then cimmofl is useful because it can be used even if no WBEM server is running, but generally it should be avoided; it is really only meant as a debugging tool.

It is instructive to view the XML that the cimmof compiler generates for the mof code shown in Figure 12.1 on the following page. The XML is shown in Figure 12.2 on page 217 ”it complies with the "Specification for the Representation of CIM in XML" document produced by the DMTF (document DSP0201). If nothing else, comparing the two representations makes one realise the inefficiency of the XML notation.

 <?xml version="1.0"?> <!-- Open Group Pegasus CIM Compiler V 2.2 Built Jul 11 2003 --> <CIM CIMVERSION="2.0" DTDVERSION="2.0"> <DECLARATION>  <DECLGROUP>   <VALUE.OBJECT>    <CLASS NAME="ACNE_PBXTelephoneModule"                              SUPERCLASS="CIM_LogicalModule">     <QUALIFIER NAME="Version" TYPE="string" OVERRIDABLE="false"                              TOSUBCLASS="false">      <VALUE> 4.5.3 </VALUE>     </QUALIFIER>     <QUALIFIER NAME="Description" TYPE="string" OVERRIDABLE="false"                              TOSUBCLASS="false">      <VALUE> ACNE_PBXTelephoneModule represents the logical                   function of the 8 port telephone interface card                   fitted in the model 34/AGB/76 PBX. </VALUE>     </QUALIFIER>     <PROPERTY NAME="Protocol" CLASSORIGIN="ACNE_PBXTelephoneModule"                              TYPE="uint32">      <QUALIFIER NAME="Write" TYPE="boolean" OVERRIDABLE="false"                              TOSUBCLASS="false">       <VALUE> TRUE </VALUE>      </QUALIFIER>      <QUALIFIER NAME="Description" TYPE="string"                              OVERRIDABLE="false" TOSUBCLASS="false">       <VALUE> Telephone Protocol </VALUE>      </QUALIFIER>      <QUALIFIER NAME="ValueMap" TYPE="string" OVERRIDABLE="false"                              TOSUBCLASS="false">       <VALUE.ARRAY>        <VALUE> 0 </VALUE>        <VALUE> 1 </VALUE>        <VALUE> 2 </VALUE>        <VALUE> 3 </VALUE>       </VALUE.ARRAY>      </QUALIFIER>      <QUALIFIER NAME="Values" TYPE="string" OVERRIDABLE="false"                             TOSUBCLASS="false">       <VALUE.ARRAY>        <VALUE> UK </VALUE>        <VALUE> European </VALUE>        <VALUE> NorthAmerican </VALUE>        <VALUE> Japanese </VALUE>       </VALUE.ARRAY>      </QUALIFIER>     </PROPERTY>     <METHOD NAME="setIndicator" TYPE="boolean">      <PARAMETER NAME="newValue" TYPE="boolean"> </PARAMETER>     </METHOD>    </CLASS>   </VALUE.OBJECT> </DECLGROUP> </DECLARATION> </CIM>

Figure 12.2: XML Generated from the mof in Figure 12.1

While we are writing mof for this example, it is perhaps worth creating an instance of the ACNE_PBX class. Although it is not strictly necessary for the provider example to work, it does give us another instance to enquire about. The code for this is given in Figure 12.3.

 [Version("1.0.1"),  Description(        "ACNE_PBX is the logical representation "        "of the whole model 34/AGB/76 PBX.") ] class ACNE_PBX : CIM_ComputerSystem     {     // assume that there are no     // properties other than those     // inherited from CIM_ComputerSystem     }; *************************************** // static instance of the ACNE_PBX // created for test purposes *************************************** instance of ACNE_PBX     {     CreationClassName = "ACNE_PBX";     // key     Name = "XYZCompanyPBXl";            // key     PrimaryOwnerName = "XYZCompany";     PrimaryOwnerContact = "14 Cambridge St, Godmanchester";     Roles = { "Primary PBX" };     NameFormat = "Other";     Dedicated = { 2 };                // other     OtherDedicatedDescriptions = { "PBX" };     ResetCapability = 3;               // may be reset     };

Figure 12.3: mof Code to Create Instance of ACNE_PBX

Finally, for the purposes of our example, we need to consider the manner in which the keys of the instances of ACNE_PBXTelephoneModule will be allocated. As we have no real telephone hardware, our provider will have to pretend , using instances preset in a table. The keys of ACNE_PBXTelephoneModule are, of course, inherited from CIM_LogicalDevice and, for the purposes of this example, I have assumed that there are three instances of ACNE_PBXTelephoneModule and that their keys are as follows :

SystemCreationClassName. Set to ACNE_PBX for all three instances.
SystemName. Set to XYZCopmanyPBX1 for all three instances.
CreationClassName. Set to ACNE_PBXTelephoneModule for all three instances.
DeviceID. Set to 1, 3, and 6 for instances 1, 2, and 3 respectively.

Note that three of the four keys are identical in all cases so the instances are really only being differentiated by DeviceID.