Positioning the PBX Class

Warning! I walk through the selection of this first class in excruciating detail, leaving bread crumbs behind, showing my train of thought. Don't despair; once through this first selection, I speed up substantially.

The fundamental problem in creating an extension schema is knowing where to start. There are over 900 classes in version 2.8 of the core and common models and we need to find the classes from which we should inherit. It is essential that we choose carefully because, if we choose wrongly, our choice will be difficult to change later. The basic technique that we will employ is to keep coming back to the basic inheritance rule, is a, and ask ourselves repeatedly, "is it true that my class is a X?" Obviously the descriptions given in the core and common class definitions are a great help in this process.

Even when we have found what we believe are the correct locations for our classes, it may be necessary to relocate them (or add additional associations) for performance reasons.

So, we will start at the top and assume that we are going to define a ACNE_PBX class to model the entire PBX. This is presumably going to be a CIM_ManagedElement (as everything is). Looking at Figure 6.1 on page 91 (or, better still, at the full UML diagrams issued by the DMTF for the latest release of the core and common models), we may arrive at the CIM_System and the CIM_LogicalDevice classes as possible representations for our PBX. Certainly a PBX is, in the common usage of the term , a "system" and it is also a "device."

On examining the full model, the subclasses of CIM_LogicalDevice appear to be a bit low-level for us: power supply, cooling device, door, power supply, etc. Our PBX certainly includes these but is an altogether larger entity. Figure 6.1 also shows a useful aggregation: CIM_SystemDevice which combines logical devices into a system ”more evidence that our PBX is a system.

I give a short description of the System Model starting on page 99 of this book and the definition written into the DMTF's mof file contains:

CIM_System represents an entity made up of component parts (defined by the SystemComponent relationship ^[1] ) that operates as a "functional whole." It should be reasonable to uniquely name and manage a System at an enterprise level. For example, a ComputerSystem is a kind of System that can be uniquely named and independently managed in an enterprise. However, this is not true for the power supply (or the power supply subsystem) within the computer.

Certainly our PBX is an entity made up of component parts (chassis, boards , power supply, application software, operating system, etc.) and it operates as a functional whole. The CIM_System class seems to be a good place to start, but before we declare our PBX class to be a subclass of CIM_System, we should look at its existing subclasses to see whether any more refined ( specialised ) class fits even better.

In version 2.8 of the common models, there are only four subclasses defined for CIM_System (see Figure 9.3; CIM_ApplicationSystem, CIM_AdminDomain, CIM_StorageLibrary, and CIM_ComputerSystem). Our PBX is certainly neither an Admin Domain nor a Storage Library but we need to examine Application System and Computer System more closely.

Figure 9.3: CIM_System's Children (and Grandchildren)

The description in the mof file defining CIM_ApplicationSystem says:

The CIM_ApplicationSystem class is used to represent an application or a software system that supports a particular business function and that can be managed as an independent unit. Such a system can be decomposed into its functional components using the CIM_SoftwareFeature class. The Features for a particular application or software system are located using the CIM_ApplicationSystemSoftwareFeature association.

This sounds a bit too software-oriented for us. CIM_ComputerSystem, on the other hand, is described as:

A class derived from System that is a special collection of ManagedSystemElements. This collection provides compute capabilities and serves as aggregation point to associate one or more of the following elements: FileSystem, OperatingSystem, Processor and Memory (Volatile and/or Nonvolatile Storage).

This sounds much closer to our PBX: it certainly contains computing capabilities and it serves as an aggregation point for several of the stated elements.

Once again we should look at the available subclasses and check whether any of them describe our system more completely ”see Figure 9.3. CIM_ComputerSystem's subclasses are CIM_UnitaryComputerSystem, CIM_VirtualComputerSystem and CIM_Cluster.

Of these, CIM_Cluster is described as being for a system "that 'is made up of two or more ComputerSystems which operate together as an atomic, functional whole to increase the performance, resources and/or Reliability, Availability, and Serviceability."

While we may one day add a second processor to our PBX, it will not be primarily to increase performance or availability; so, we will avoid CIM_Cluster.

CIM_UnitaryComputerSystem, on the other hand, is described as representing "a Desktop, Mobile, NetPC, Server or other type of a single node Computer System." This is more tempting, but its use would preclude the introduction of a second processor (perhaps on a second processor board) at a later date.

A useful sanity check on the positioning of ACNE_PBX is to look at the properties and associations that it has inherited and determine inhowfar they relate to our PBX. If we found them to be totally irrelevant to a PBX then this might make us suspicious that we had chosen wrongly. Some of the properties certainly seem to be relevant:

• Dedicated: Describes whether this is a general-purpose computer or one dedicated to a particular function. This is an enumerated variable and its values, although not containing PBX ( unfortunately ), do contain devices which are not dissimilar to PBXs in their own field: router, switch, layer 3 switch, central office switch, hub, access server, firewall, file server, repeater, bridge/extender, gateway.

• ResetCapability: Defines whether or not the PBX's computer can be reset by a hardware switch.

• PrimaryOwnerName: Defines the owner of the PBX.

• CIM_InstalledOS and CIM_RunningOS: These associations link our PBX with its operating system.

• CIM_HostedService: This association allows us to tie our PBX to the services it offers.

• CIM_SystemPackaging: This association ties our logical PBX to its physical packaging.

• CIM_SystemDevice: As described above, this allows us to tie the lower-level devices (power supplies , etc.) together into our PBX system.

These sound reasonable and so I will assume that the PBX is a CIM_ComputerSystem and that its component parts are CIM_LogicalDevices; see Figure 9.4.

Figure 9.4: The PBX Class

^[1] Beware: Only use the CIM_SystemComponent association if no lower-level association, such as CIM_SystemDevice, exists and will do the job. CIM_SystemDevice is a CIM_SystemComponent.