Previous section.

Systems Management: Topology Service

Systems Management: Topology Service
Copyright © 1997 The Open Group

Introduction

Purpose

With the move to re-engineer and automate tasks and processes, coupled with the move to distributed systems environments, we have seen the need to have more robust and cooperating network and systems management and administration tools.

One of the fundamental needs of an automated management system is to be able to keep track of where resources are located and how they are related to other resources in the managed environment. Therefore, a well designed Topology information management service will be of increasing importance. Topology provides a service to applications for managing topological relationships (associations) among managed objects in a distributed workgroup up through the enterprise environments.

A Topology Service relieves most of the burden applications have in managing associations by providing storage of topological data, by maintaining semantic integrity of associations, and by providing query support to clients interested in retrieving topological information. As such, Topology serves as a fundamental integration point for management applications in determining how managed objects are organized, what their inter-dependencies are, and how underlying aspects of the managed environment blend together to form the resources administrators manage. Classes of applications which benefit from this integration include fault management applications, map generators, correlators, and configuration management tools.

As management environments become increasingly complex, and due to the integral role that topological data has in management, a Topology Service necessarily must:

Accordingly, major operational goals pertaining to management that the Topology Service supports include:

Scope

This specification addresses Topology information management services for network and systems management purposes. However, this technology may well be applicable outside of its original charter (for example: relationship management of other applications).

It is not the function of the Topology Service to "discover" topological data or to manage assets. It is also not the function of this service to "display" information to the user. This service cooperates with other services such as Discovery Services, Event Services, Inventory Management or Asset Management Services, and User Presentation Services such as map services or map generation services, etc.

Likewise, this service does not specifically address "interchange" of information between implementation-specific topology managers. However, this service could support an additional component that performs interchange functions.

Requirements

Association Management

A Topology Service must provide a general, distributed service for managing topological associations that exist among managed objects in a consistent manner.

It must manage the lifecycle of associations as directed by clients using the service. Operations include the ability to:

It must provide the ability to validate that associations may be allowed and the validation process must be client-definable and extensible so that the Topology Service can be made to manage arbitrarily-defined topologies, newly and dynamically defined by clients of the service. The extensible aspects which the service must support include:

Semantics of the associated objects are unaffected by their involvement in topological associations.

Validation must also be enforced when a client may request an edit to the topological information. This enforcement may allow or prohibit the client to make the edit, based on the enforcement process results.

Scalability and Performance

The Topology Service must scale well to be able to support very large environments that may require management of the order of millions of objects, yet be able to also not be so heavyweight and burdensome as to not be appropriate for small workgroup environments who may only have hundreds of objects to manage.

The Topology Service should allow the storage of relationships between CORBA objects and non-CORBA objects.

Topological data, internal to the service, should not be required to be exposed in the form of directly addressable objects in and of themselves (such as directly addressable CORBA objects).

The Topology Service should not restrict implementations from being federated in order to support improved performance in large-scale, distributed environments.

Query Support

The Topology Service should support arbitrary queries which are client-defined. Example queries might include:

Queries should be able to be stored, re-used and referenced as sub-queries from within other queries.

Application Integration

The Topology Service must provide semantics that are well defined and established so that all clients (both internal within a product and third-party supported clients) can edit topology data.

The Topology Service must allow for clients to be able to build on the work of others by creating and manipulating associations involving objects that have been defined and managed by other applications.

The Topology Service should support extensions to new topologies based on existing objects may participate in. This must be done in such a way that the semantics and implementations of existing objects are unaffected by new associations they are called to participate in via the Topology Service.

The Topology Service must provide an integrated, comprehensive view of both logical and physical worlds.

The Topology Service should provide direct support for integratedmanagement of logical and physical worlds where these worlds are tied together. In particular, Topology should support integrated views of resources that actually consist of cooperating logical and physical objects, while retaining individuality and direct management access to the underlying objects:

The Topology Service should directly support integrated management of systems, networks and distributed applications. Queries should be able to span linkages transparently among these topologies through its integrated views and common storage.

The Topology Service should allow applications to query all topological data (subject to security restrictions). It should integrate the various topologies that objects participate in such that queries can be written to retrieve unified views (spanning associations defined by separate and distinct topologies).

The Topology Service should allow for queries to be named and shared (re-used) by applications other than those which defined the queries.

The Topology Service should integrate with external event services so applications can subscribe to change notifications pertaining to topological data:

The Topology Service should maintain a persistent store of its topological data. If the topological data is stored in an RDBMS, the underlying tables should be published to support read access by independent report generators. However, the form of the data in the relational store may not be conducive to simple or efficient access.

Interoperability

The Topology Service should support the interchange of topological data with heterogeneous implementations, including:

Usability

The Topology Service should support a usable, intuitive interface:

The Topology Service interface and querying capabilities should support:

Relationship to Existing Services

Relationship Service

The OMG Relationship Service has considerable overlap in its functionality with the proposed Topology Service. In particular they both address the following key requirement:

However, Topology has some additional requirements that yield a different service:

The particular interface defined for Topology yields some additional benefits beyond the basic requirements outlined above:

Transaction Service

Topology does not present any interfaces that overlap or attempt to augment the Transaction Service interfaces. However, Topology is defined to operate in an environment where a transaction service can help maintain consistency of the topology. Thus, some transaction service is needed in order to implement Topology as well as to use it. The OMG Topology Service is an appropriate service to use for this functionality. While it would be feasible to implement a Topology Service using a different transaction service, this would be counter productive since the clients of the service must also use the transaction interfaces.

Topology provides a powerful declarative query mechanism using a formal language specifically designed for querying the relationships that are managed by Topology. It would have been appealing to simply use the OMG Query Service interface for querying topology, however, the Query Service requires the use of the OQL/SQL which is not suitable for use in an environment where the objects being queried have no knowledge of the relationships in which they participate and in which the relationship store has no knowledge of the objects being managed.

Factory Service

Topology does not provide any general lifecycle management services. Thus, there is no overlap with the GenericFactory interface.

Persistence Service

Topology does not present any interfaces that overlap or attempt to augment the Persistence interface. A Topology implementation will usually keep a persistent store of its data and may use whatever mechanism the implementor chooses to use.

XCMF Policy Service

There is some overlap of functionality between certain features of the Topology Service and the "Common Management Facilities" (XCMF) Policy Management Service (see referenced document XCMFv1). Topology has features that enable clients of the service to define rules that apply to relationships between topological entities, or arbitrary rules applied to the state of topological entities that are involved in changes to e underlying topological relationships. Topology enforces these rules automatically whenever a change to the topology being managed is made. Similarly, XCMF Policy Management allows clients of the service to define rules that apply to any portion of the state of each managed object. The state information to which these rules may apply could include, but is in no way limited to, information about the relationships the managed objects participate in. XCMF Policy Management does not automatically enforce policies defined on the state of managed objects. Instead, policy enforcement must be requested by clients of the service.

It would not be feasible to implement XCMF Policy Management in terms of the support for policy provided by the Topology Service, since the latter requires a state change between topological relationships to trigger policy enforcement, and the former allow policy enforcement at any arbitrary time - which may not be preceded by a change in the relationships in which managed objects participate.

It may be possible to implement the support for policy enforcement provided by Topology in terms of XCMF Policy Management. For instance, whenever relationship changes occur CORBA proxies could be created for the topological entities affected using Instance Managers, and Validation Policies could be invoked corresponding to all rules defined by Topology. But, this solution may be sub-optimal, since it requires creation of first class CORBA objects corresponding to all topological entities involved in a state change.

Whether or not the support for policy management provided by Topology is implemented in terms of XCMF Policy Management is an issue which should be left as an implementation detail within the Topology Service, since the choice of whether or not to do this would not impact the interoperability of two implementations of Topology. Also, too little is known at this time about whether or not this is an optimal solution to make the relationship between this services a requirement to an implementor. Instead, it makes more sense to view this as an implementation detail at this time, opening up the possibility of both integrated, and non-integrated solutions, which will ultimately provide for more direct comparison between the various approaches.

XCMF Instance Management

There is no obvious relationship between Topology and XCMF Instance Management. Topology manages the relationships between entities (objects), while XCMF Instance Management manages the lifecycle of object instances by type, along with the policies that may be applied to each type of object instance. Most notably, Topology does not manage any aspect of the lifecycle of the entities it manages.

XCMF Managed Sets

There is clearly some functionality overlap between the Topology Service and XCMF ManagedSets. Essentially, Topology is capable of representing and managing any type of relationship between managed entities. XCMF ManagedSets is capable of managing one particular type of relationship that can exist between managed objects: the member/set relationship.

Since the type of relationship supported by ManagedSets is a subset of the types of relationships that are supported by Topology, it makes no sense to consider implementing Topology in terms of ManagedSets.

Conversely, however, it may be possible to implement XCMF ManagedSets in terms of Topology. To do so, the implementation would likely be such that a topological entity of type Member would be created for each XCMF object supporting the Member interface, and a topological entity of type Set would be created for each XCMF object supporting the Set interface. Whenever an XCMF Member object is added to an XCMF Set object, a relationship would be established between the corresponding Topological entities within Topology. All queries to the XCMF ManagedSet objects for things such as membership of a Set of which Sets a Member belongs to would be delegated as queries to Topology.

We do not feel, however, there has been sufficient implementation experience with either XCMF or Topology to make the implementation of XCMF ManagedSets in terms of Topology a strict requirement at this time. The implementation described above could add appreciable overhead to an implementation of XCMF ManagedSets not integrated with Topology, for example, since the proposed implementation essentially requires delegation of requests on ManagedSets interfaces to Topology. As with the issue of overlap between the XCMF Policy Management Service and the support for Policy Management supported by Topology, we feel the issue of whether one could/should be implemented in terms of the other should be left as an implementation detail at this time. If integrated implementations emerge that demonstrate clear advantages over non-integrated implementations, then issues such as this can be revisited at this time.

In general, there is a strong argument for specifying XCMF and Topology in such a way as there are no dependencies between them. Specifying these as two orthogonal sets of services allows more implementation options, and hopefully will produce more total implementations. Making the requirement that one depends on the other places a heavier-weight requirement on any organization considering the implementation of one or the other, and thus may prohibit implementations of either.


Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

Contents Next section Index