A Practical Approach to WBEM[s]CIM Management

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.

Категории