Modelling the PBX s Components

Modelling the PBX's Components

Note: The classes which I decide to add into our extension schema are listed for convenience in Table 9.1 on page 185.

Table 9.1: PBX Classes

Class	Superclass	Notes
ACNE_PBX	CIM_ComputerSystem	Whole PBX
ACNE_PBXAnalogueTrunkPort ACNE_PBXAnalogueTelPort	CIM_NetworkPort CIM_NetworkPort	Ports
ACNE_PBXProcModule ACNE_PBXTelephoneModule ACNE_PBXTrunkModule	CIM_LogicalModule CIM_LogicalModule CIM_LogicalModule	Cards
ACNE_PBXTelephony ACNE_PBXVoiceMail	CIM_Service CIM_Service	Services
ACNE_PBXTrunkToGroup	CIM_Dependency	Association
ACNE_PBXTelephonePortData ACNE_PBXTrunkPortData	CIM_StatisticalData CIM_StatisticalData	Statistics
ACNE_PBXTrunkFailure ACNE_PBXSoftwareFailure ACNE_PBXTelephonePortFailure	CIM_AlertIndication CIM_AlertIndication CIM_AlertIndication	Alarms

Having added the PBX class itself, we still need to model the devices which comprise it (the telephone and trunk ports, the interface cards, processor, disk drive, power supply, etc.), the grouping of telephones and the allocation of incoming trunks to the groups, the users and the services the PBX provides.

Luckily most of these devices are already modelled and I have included part of the logical device subtree in Figure 9.4 for convenience but our PBX has a number of port types which do not yet appear in the common models. One way to find a home for them is to realise that IP routers and other network equipment also have ports, so a class for ports is likely to exist somewhere; a little searching leads to CIM_TokenRingPort, CIM_EthernetPort and other similar ports living as subclasses of CIM_NetworkPort. Even though many of the properties of CIM_NetworkPort are oriented towards data rather than telephony ports (e.g., bitrate ), it would seem that our ports are peers of these and so, as shown in Figure 9.5, we can add two additional types of port there. A nice feature of this is that the CIM_SystemDevice association already exists to link these to our PBX class.

Figure 9.5: The PBX Device Classes

The other port on our PBX, the Ethernet through which we manage it, is already well modelled so we have no work to do there. I have also shown these port classes in Figure 9.5.

The other items we need to model are the interface cards. Remember from the discussion on page 89 that the interface cards may be both physical items with a serial number and physical location, and also a logical item describing the function performed. In the remainder of this chapter, I will deal exclusively with the logical function of the interfaces. This does not mean that the physical characteristics are unimportant or should not be modelled ”simply that the physical models are relatively straightforward. If it is important to manage the hardware inventory of the PBX then the CIM_PhysicalElement, CIM_FRU and CIM_Product classes could be subclassed and exploited. As they say in mathematical textbooks , this is left as an exercise for the reader.

The logical view of the interface functions fit as subclasses of CIM_LogicalModule which is described in its mof as "the logical device corresponding to a line card/ blade in a device. For example, a line card in a switch is an instance of LogicalModule, associated with the switch itself. A logical module is not necessarily independently managed." This seems to fit our requirements nicely and there is even a predefined association CIM_ModulePort which will allow us to associate each module with the port types which it supports. I therefore introduce the three classes ACNE_PBXProcModule, ACNE_PBXTelephoneModule, and ACNE_PBXTrunkModule.