Table Of Contents

The MODEL Component

MODEL

The topology manager and repository

MODEL operation

Databases of MODEL

Starting up MODEL

Prerequisites for running MODEL

Conclusion

The MODEL Component

---

This section describes MODEL, the MWFM NMOS component responsible for the management, storage and distribution of the discovered network topology.

MODEL

The component MODEL (also known as riv_model) is responsible for managing and storing the network topology. MODEL is also responsible for distributing the network topology to other applications that make use of it in their own specialized way.

Figure 14-1 Interaction of MODEL with other NMOS components

The topology manager and repository

After the completion of the discovery process and when you are satisfied with the results of the Scratch Topology, you can activate the Scratch Topology and turn it into the Impact Topology. Alternatively you may choose to bypass this approval stage and automate the transition of the Scratch topology to MODEL via the Impact Topology.

At that point, entries in the Impact Topology are sent to MODEL if—and only if—they pass a filter condition, known as the Instantiation Filter, specified in DiscoSchema.cfg as an insert into the instantiationFilter table of the Scope database in DISCO (see Chapter 24). MODEL is a central repository and acts like a server for the network topology, distributing it to other MWFM NMOS processes on demand. For example, MONITOR interrogates MODEL for the topology in order to distribute it to the Polling Agents so that they can know which part of the network to poll.

It is worth noting that, during the transition of the discovered network topology from DISCO to MODEL, the devices are instantiated as instances of various classes as defined by the Active Object Classes managed by CLASS.

Figure 14-2 MODEL, the topology repository and distributor

MODEL operation

At startup, MODEL waits for DISCO to finish the discovery process so that the Containment Model within the Scratch Topology can migrate (either automatically or by approval) to the Impact Topology. As soon as the Impact Topology is created, the topology is moved from the Impact Topology database into the MODEL databases, which MODEL uses to distribute the topology information to other processes and applications.

Databases of MODEL

The databases of MODEL (and their constituent tables) are discussed in more depth in "MODEL Databases,"of this guide. It is possible, as with other components of MWFM NMOS, to login and interrogate the databases using the OQL service provider and command line interface, riv_oql. Information on how to use riv_oql, and a detailed tutorial demonstrating all the keywords and syntax, is given in "The OQL Language."

Table 14-1 Databases that interact with MODEL

Database	Database description (Chapter reference)
Master database	The central database used by MODEL to store the network topology.
Translations database	The database used to store the definitions and translations of external data types used in the master database.

Starting up MODEL

MODEL is started using the following command line:

riv_model -domain <DOMAIN_NAME> [-cachesize <SIZE_IN_MB>] [ -cachepercent <PERCENTAGE_OF_CACHE_IN_MEMORY>] &

<DOMAIN_NAME>	The domain under which the NMOS processes are being run.
<SIZE_IN_MB>	Specifies the size of the cache in megabytes (MB).
<PERCENTAGE_OF_CACHE_IN_MEMORY>
	Enables you to specify the ratio of the cache that will be resident in memory to the cache that will be resident on the hard disk. Note The ratio that you specify is dependent on the amount of memory that exists on the host machine and the number or processes it will be running.

A help option can be accessed using the following command line:

riv_model -help &

-help

Prints out a synopsis of all the command line options for running MODEL. MODEL is not started even if -help is used in conjunction with other arguments.

Prerequisites for running MODEL

In order to enable successful distribution of network topology information, the prerequisites that must be in place before initiating MODEL are:

•It is helpful, but not strictly necessary, to have CTRL, the process controller, running.

•It is also helpful, but not strictly necessary, to have STORE, the persistent storage engine, running.

•Unless MODEL has a copy of the last discovered topology, DISCO must have completed a successful discovery, which must have been approved and passed on to MODEL before MODEL can distribute the topology to other processes.

Conclusion

This chapter has described the function of the MWFM NMOS component MODEL, the management, storage, and distribution component of MWFM NMOS, and how it interacts with DISCO to receive the network topology.

The next chapter introduces MONITOR, the MWFM NMOS component responsible for device status monitoring and event generation.