Each month, the TSC examines a key emerging technology or its use. This time, we focus on the management of distributed computing environments, using an object-oriented model.
By Martin Neath
The great diversity of management approaches in use today, and the differences between network management and systems management found in today's practice, leave a lot to be desired in terms of uniformity, ease of use, cost effectiveness and comprehensiveness. To address these issues, a framework is needed that encompasses the different approaches and provides a foundation for managing distributed computing environments. A distributed, object-oriented model can be a suitable base for such a framework.
Systems and network management have to configure and maintain an almost overwhelming diversity of devices, files and services. Each service, even when not networked, requires its own unique approach. But at the same time, the data maintained, for example, in a certain configuration file, is often related to and dependent on the data in other files. For clarity, we will use the term entity to address anything to be managed--a service, device, user or any kind of resource.
The first step, before using any entity in a computer system, networked or stand-alone, is configuration. Certain sets of data, in files or process parameters, have to be identified and established. Examples from this category are partitioning a hard disk, assigning an Internet Protocol (IP) address to a host or assigning a user to a group while adding the user to the system. This configuration establishes the initial state of the entity. This state is maintained in certain attributes, which represent the state. Obviously, there are different sets of attributes for different entities, but similar entities will have similar attributes.
After this initial state is established, administration can be divided into two broad categories: proactive and reactive. The proactive part of management is involved with maintaining or administering the entity. Most operations are carried out by changing the state--that is, modifying attributes--or by invoking commands, which modify an entire set of attributes in one operation. Examples include starting the printer spooling system, modifying the priority of a process or adding a user to another group of users.
The reactive category is involved with certain expected or unexpected conditions. If such a condition arises, the managed entity will emit a notification, informing the administrator of events that may require attention. In fact, the notification itself constitutes the event from a management point of view. The administrator may now choose to react to such events as appropriate. Sample events include paper-out or jammed conditions on a printer, a network failure or disk overflow.
A few rules of thumb will summarize what has been identified so far:
The next step, in order to conquer the diversity of things to be managed, is to classify the different entities to be managed.
To better understand the concepts outlined above, it may help to visualize a television set. When imagining a TV, we usually do not see a specific set but a whole class of things: color TVs, stereo TVs, portable ones and so on. We think of a type of TV, which may actually exist in many different variants. Something is of the TV type if it has a screen, a speaker and a set of buttons to turn it on and off; if we can choose channels and adjust various parameters like volume, brightness and contrast. And there are several companies that manufacture TVs of the same type, such as stereo color TVs with 19-inch screens. We can say that all TVs of a certain type built by one manufacturer belong to the same class. We will call things belonging to a certain class objects, being instantiations of that class.
A further aspect of objects and classes is encapsulation. Consider the TV set again. Most of the time, we are concerned with the external interface of some object, so we can invoke some operations (such as changing the channel) or change the state of the object (adjusting the volume). The implementation of the operation or the representation of the attribute is secondary. This approach works almost everywhere in our daily life. We use all manner of gadgets and devices without being much concerned about their internals.
Management of the diverse services, resources and devices has already been subsumed under the common terms entity, attribute, operation and notification. These concepts now enable us to classify entities as managed objects. A printer is a prime example. There is the generic concept of a printer, and there will be subclasses for laser printers, line printers, PostScript printers and so on. Many attributes of these entities will be the same (such as the paper-out condition), but some require specialization in terms of how accounting is done, the kind of paper being loaded and the kind of interface they support (serial, parallel or networked).
(As an aside, one example of the difference between type and class can be seen in user management. There should be one type of user account, but the management of the user account type falls into different classes, depending on the environment.)
In using the example above to think about objects, we have unified our view of the many different entities to manage. The next step is to address distribution. Clearly, not all managed objects will reside on one computer or even in one program; they will be spread all over the network. How do we invoke operations on remote objects?
Return to the example of the TV set. Most modern TVs come with remote controls. The remote control exposes the same interface as on the TV set, but it does not directly implement the functions. Rather, it transmits the requests to adjust the volume, for example, via infrared light. The TV and the remote control use a common way of exchanging information--a protocol.
In other words, we manage the TV using a little device that invokes operations on the TV object. The same thing happens with a cable box, a CD player or a videocassette recorder. The annoying thing is to have to use four different remote controls. As the world gets evermore "modern," we end up with more remote controls in every home. This is also the situation in distributed systems management today.
In the distributed management environment, objects reside where they need to be, and there is a protocol to access them and invoke operations on them from a remote site. The programs managing the objects are often called object managers, and the programs accessing these object managers are the management applications. In terms of client/server computing, the programs providing for the objects would be called object servers. The framework provides for the common understanding of how to deal with objects and the protocols needed to access them.
How does one find the objects or their servers? What is needed here is a naming service that provides a mapping from the object names to locations of their servers; this is similar to the concept of a telephone directory. If you know the place and name of a person or company, you can look up the phone number to contact that person. Neither the name nor the phone number tells you where the person is really located. In fact, a phone number could be interpreted as an opaque string of digits used to magically connect to the other side; we don't care how it's really done.
The same holds true in distributed computing in general and in distributed management. Objects have names, which can be used to obtain their object IDs. These object IDs are used by the underlying management framework and communications infrastructure to contact the object server.
In addition, the framework provides services to handle the notifications being generated by the objects. Mechanisms exist to filter and correlate notifications based on certain criteria, such as severity, and to forward them to other objects or applications. The notification may then be displayed on the screen, change the color of an icon, trigger some automated operation or just be logged in some file for later inspection.
There is a strenuous effort under way in the IT industry to promote distributed object-oriented environments, of which Microsoft's distributed OLE or ActiveX and the Object Management Group's CORBA are prime examples. The benefit of this approach is obvious: a unifying solution that integrates systems and network management under a common umbrella. Management information is kept in a consistent, uniform fashion; the access to managed entities always follows the same principle.
This consistency greatly reduces the effort required to learn about management and to implement management applications. Furthermore, it is in line with current and evolving international standards addressing management, thus promoting the eventual unification and integration of the current proprietary management systems.
Martin Neath is vice president of development for Tivoli Systems in Austin, TX. For more information, send e-mail to info@tivoli.com.