Simple Modeling Example

Let's take a look at an example. Imagine that you are tasked with defining a simple management information model for a device. All you are interested in managing is some basic system information about the device, such as the name of the device, where it is located, who the contact is, how long it has been running, and its TCP connections. The resulting models are graphically depicted in the following figures. All three represent the same underlying domain, but each is based on a different type of metaschema:

■ Figure 6-8 depicts an object-oriented model. In this example, a managed object class represents a managed system. It has three attributes to carry management information: SystemName, SystemContact, and SystemUptime, to carry the name used to refer to the managed system, the contact information of the group responsible for managing the system, and the time elapsed since the system was last started. The managed system is derived from a superclass (denoted by the line with the arrow), Physical Equipment, which has another attribute that Managed System inherits, SystemLocation. Objects of the class Managed System can contain objects of another class, TCP Connection (denoted by the line with the diamond). TCP Connection has more attributes: TCPConnectionState, PacketsSent, and PacketsReceived. TCP Connection maintains two different types of relationships to objects of another class: Endpoint (denoted by simple lines labeled with the relationship names). Those relationships indicate which endpoint is local to the connection and which endpoint is remote. Objects of the class Endpoint contain attributes with the address and port information of the respective endpoint.

Figure 6-8 Example of an Object-Oriented Management Information Model Physical Equipment

SystemLocation: string

Managed System

SystemName: string SystemContact: string SystemUptime: timeticks

TCP Connection

Is-local-to

Endpoint

ConnectionState: tcpState PacketsReceived: integer PacketsSent: integer

Is-remote-to

Address: IPAddress Port: integer

■ Figure 6-9 depicts a table-based model. In this case, the management information is maintained in two tables. The table named Managed System contains only one entry, including SystemName, SystemContact, SystemLocation, and SystemUptime as columns. The table named TCPConnections can contain many entries. It has columns for LocalIP, LocalPort, RemoteIp, RemotePort, ConnectionState, PacketsSent, and PacketsRecvd. The combination of the first four columns serves as a key for the table—that is, they are used to identify a particular table entry. The model here is a little more coarse-grained than the object-oriented one. For example, information about endpoints is not broken out separately.

Figure 6-9 The Same Domain as in Figure 6-8, in a Table-Based Model ManagedSystem

SystemName

SystemContact

SystemLocation

SystemUptime

TCPConnections

LocalIP

LocalPort

RemoteIP

RemotePort

ConnectionState

PacketsSent

PacketsRecvd

Figure 6-10 depicts a "model" based on a set of dedicated functions. Here, the managed system is "modeled" by three functions: showSystemdata, showAllTcpConnections, and ShowTCPConnectionState. showSystemdata is used to retrieve information about the managed system. The function is defined so that it will return the name, system uptime, system contact, and system location when invoked. It is not necessary to define a parameter to identify the managed system because it is the system on which the function is invoked. Two other functions are introduced that allow a manager to modify the system name as well as system contact and system location information. TCP connections are "modeled" by the remaining two functions: showAllTcpConnections lists all current TCP connections on the device along with their local and remote IP address and port information, TCP connection state, and base statistics of the number of packets that were sent and received over this connection. ShowTCPConnectionState allows a manager to retrieve the TCP connection state of a particular TCP connection, identified by its local and remote IP address and port information.

Note that this model is specific about how the manager accesses the information. In the case of object-oriented and table-oriented metaschemas, the model did not define how to access management information. Instead, those functions are assumed to be provided by generic operations of the accompanying management protocol that is used to access the management information.

Figure 6-10 The Same Domain as in Figure 6-8, as a Set of Functions showSystemdata (out: string) configureSystemName (in: string) configureSystemContactLocation (in: string, string)

showAllTcpConnections (out: string) showTcpConnectionState (in: ipaddress, int, ipaddress, int; out: enum)

"System" related functions

"TCP connection" related functions

The models specified for each metaschema represent just one way in which the underlying domain can be modeled. Even with the same metaschema, the same domain can be modeled in many ways, just as you could draw different portraits of the same person that all look slightly different yet clearly resemble the same person. For example, in the table-based model, we might have decided to add a table just for endpoint information, in a manner similar to the way in which endpoints were modeled by their own object class in the object-oriented model. Likewise, we might decide to represent aspects of TCP connections that constitute statistical information in their own table, separate from those aspects that convey the more static configuration information and the TCP connection state. In the object-oriented model, we could have derived the TCP connection managed object class from a more general superclass that represents a generic connection. In the function-oriented model, we could have cut the functions and their parameters slightly differently. We might have introduced another function to retrieve TCP connection statistics, for example.

Which model is eventually defined is a matter of design. Design is a creative activity. There is no single "right" way to model the underlying domain. Instead, different models are possible, some of which might be more appropriate and some less appropriate than others in terms of how easy they make it to manage the device, how straightforward they are to implement, and how easily they can be extended and maintained.

Was this article helpful?

0 0

Post a comment