The X/Open Systems Management Programme makes use of object-oriented techniques to describe the encapsulation of Resources and the interactions between managed and managing entities.
The X/Open Systems Management Reference Model uses object-oriented techniques in the specification of systems management. These techniques are derived from those used in the OSI Management Model, as well as the Object Management Group Common Object Request Broker Architecture. The use of such techniques for specification does not require an object-oriented implementation, although in many cases there would be benefits in adopting such an implementation.
The benefits of adopting an object-oriented approach are
described in
The Reference Model consists of 3 basic components:
For management of Resources to take place it is necessary that management interactions are possible. If that were all that was provided, every Manager would need to know specific details about each Resource and understand all aspects of its operation in terms that were unique to the Resource. So that management of heterogeneous systems is possible, it is necessary that the management view of a Resource achieves isolation from the implementation of that Resource and reflects the need for management of the Resource. The management view should be expressed in terms that enable Managers to perceive Resources as being the same from a management perspective, even when their implementation and functional interface are quite different. This view of the Resource is in terms of Managed Objects, the definition of which encapsulates the management characteristics of the Resource and isolates those characteristics from the implementation of the Resource. It is also necessary that different types of Resources, as well as different implementations of the same Resource, are expressed in the same form.
A Manager is the initiator of a management interaction. It is a software component that requests some operation to be performed by a managed Resource.
Within an OSI environment, this functionality would be described as the performance of a Manager Role. In general distributed computing terminology, this functionality would be described as a client, making requests of a server.
Managers may provide a user interface which thus form the means of invoking Management Tasks. Managers may invoke other Managers which provide common management functions.
Managers may be invoked by an Administrator, either directly by means of a command line interface (CLI) or a graphical user interface (GUI), or indirectly by a scheduler, programmed to invoke a particular task at a specific time, or upon detection of a specific condition. Managers may also be invoked by other Managers which need to make use of some composite function that this Manager provides.
A Manager invoked by another Manager appears to be the same as a Managed Object. It will take part in a management interaction with the requesting Manager and will perform the requested function. It may in turn initiate further management interactions with other Managers and with other Managed Objects.
This behaviour describes an important aspect of the Reference Model, the concept of "cascading". Although management is often simply described in terms of the interaction between Managers and managed Resources, in reality, there are often multiple layers of management interaction between the original initiator of the management request and the ultimate target Resource(s) that are affected by it. Cascading may be performed for various reasons, such as delegation, policy implementation, or ease of provision of composite management functions. The cascading of Managers illustrates the transient nature of management roles, with a given software entity acting sometimes as a Manager, sometimes as a Managed Object.
In order to transform a Resource into a Managed Object it is necessary to encapsulate it with software that provides the necessary management interface. This encapsulation may be extremely simple, or it may involve significant complexity. The simple case is that of a Resource which has implemented the necessary management interface directly. No additional encapsulation is necessary in this case.
Within an OSI environment, this functionality would normally be described as an Agent, and would perform an Agent Role in a management interaction. In general distributed computing terms, such a software entity is acting as a server, responding to requests originated by a client.
Any type of Resource may be encapsulated with a management
interface. Indeed, some Managed Objects may not
correspond to any real Resource within the system, but rather
to an abstract element of functionality that is relevant to the
management of some other Resource. In this way, Managed Objects
can be defined which represent some aggregation of
disparate real Resources that neeed to be managed as a coherent
whole. This is explored further in the examples in
The interface between the encapsulating software and the Resource that it is managing may conform to standards, or they may be entirely specific to a particular implementation of a Resource. One of the major purposes of the encapsulating software is to provide a standard management interface to diverse implementations of common Resources. If different implementations provide a standard interface for use by the encapsulating software, then it is possible to envisage the development of a portable implementation of the encapsulating software.
As has been described in previous sections, a Managed Object may represent a "real" Resource, (e.g. a file system), a "logical" Resource, (e.g. a user), or a unit of management functionality, providing the capability of cascading Managers.
Services exist to provide the common facilities that must be provided by the XSM Support Environment in order to support distributed systems applications. Services can be divided into 3 major classes:
This classification derives from the relationship of a specific service to the specific problem space being addressed.
General services are characterised as being of use to a wide range of different problem areas.
Management Services are common facilities which have been specialised for XSM distributed management. Areas of specialisation might include: policies for more centralised control of security, policies for configuring and distributing applications, and the ability to control the location of objects.
Application Services are services that are specific to some particular functional area within the overall management problem space. While these services are not of general use to a wide range of management applications, they provide common services to implementations addressing that particular area. An example might be a catalogue service provided for the use of multiple backup and restore applications.
A fuller discussion of management and general services is given in the X/Open Systems Management: Identification of Management Services Snapshot (see reference XIMS). This section summarises some of the services that are needed by distributed management systems.
XSM specifies a means by which management interactions can take place, namely the Communications Service. This service provides a defined interface which is specified as part of XSM. The Communications Service provides access to communications mechanisms. The Communications Service provides:
The Communications Service may use a local transport mechanism for communications within the same system.
XSM defines an interface to a Data Store which can be used to store information about Managed Objects. This interface reflects the object structure and naming of these objects. The Data Store itself may be implemented as a conceptual repository, thus supporting implementations based upon different vendor database systems.
XSM requires a security model which addresses several components of secure access to Managed Objects including:
These components of security are used to construct application specific security policies for the management applications, as well as site-specific security policies defined by administrators.
XSM will provide services to ensure the consistency of the Managed Object state in the following cases:
Two other cases are not considered applicable to the XSM consistency services. The first is guaranteeing consistency of the state within a single Managed Object, both in lieu of an object request failure and modification of the managed Resource outside the XSM reference model implementations. It is left to the Managed Object implementation to address these consistency issues. The second case involves managed Resources interacting in ways that are not reflected in the Managed Object definitions. This should be considered a deficiency in the Managed Object definition.
XSM provides services to enable the establishment of relationships among Managed Objects, thus supporting the ability for management applications to operate on a set of Managed Objects (such capability is important to implement scalable management applications and tasks, as well as providing a mechanism for organising Managed Objects for searching, filtering, and browsing). Some relationships of interest are containment, connectivity, and activity.
Administrators require a mechanism to determine the set of Managed Objects that are to be acted upon by a Management Task. The techniques for scoping, filtering and finding provide mechanisms for supporting such services. Scoping and filtering rules are expressed as one or more conditions based on the relationships between Managed Objects and/or the attributes of Managed Objects.
Many Managed Objects have the ability to generate asynchronous event notifications associated with the encapsulated managed Resource. XSM addresses services which support the generation, registration, filtering, and forwarding of such event notifications to management applications and other management objects. The services support the ability for a management application or task to explicitly specify which event notifications should be forwarded to it. Such specification can be based upon one or more conditions relating to the values of the parameters in the notification.
The Naming Service provides a common interface to underlying naming servers (such as X.500, DCE CDS, and ONC/NIS+). This service encapsulates a federated naming model, providing operations which are naming syntax independent.
The Reference Model illustrates the relationship between the fundamental components.
Within this model, the Communication Service has been specifically singled out for special treatment as it forms the core function of conveying management requests and their responses between Managers and Managed Objects. It may also provide access to Management Services, especially those that are defined using object-oriented techniques.
It is important to note that there is no direct access between the Manager and the Managed Object, except via the Communications Service. The Communication Service is defined as providing all the functionality necessary to provide transparent communications between Managers and Managed Objects. In the case where the Manager and the Managed Object are on the same system, then the Communication Service may make use of efficient local transport mechanisms, such as IPC.
Two forms of interface are present in the model. The primary interface to the Communication Service is presented as an object-oriented interface in which requests and responses are expressed in object terms. Non-object interfaces are also shown as it is expected that many services will be expressed in terms of traditional, functional interfaces. This is especially true of pre-existing general services which are not specific to management.
| Contents | Next section | Index |