Introduction

Purpose

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:

• scale well to address the broad range of size seen today in customer environments

• be extensible to accommodate new technologies and unanticipated topologies.

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

• the provision of an environment in which applications can integrate with one another, via topological information, by means of consistent paradigms

• the enabling of scalable solutions, whereby an application can usefully participate in managing hundreds to millions of objects.

Scope

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

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

• make managed objects known to Topology (manage and unmanage them) so associations can be established with them

• create, delete, and query associations

• notify clients of such association changes

• represent associations of arbitrary degree (relating multiple objects with a single association) in a manner consistent with the overall Topology paradigm.

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:

• configuration of the kinds of associations that can be established with what types of objects

• specification of the minimum and maximum number of a given kind of association that an object type can participate in

• dynamic alteration of topology semantics if and when required

• policy imposition and removal, enforced by Topology as topological edits take place, as needed.

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 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

• Which clients are currently mounting file systems from NFS server Q?

• Which users are currently running shared Application X?

• What systems are dependent on router A for connectivity to P, Q and R?

• What departments are responsible for managing the PC inventory in Building 6?

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

Application Integration

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:

• Topology should define and generate events to notify interested clients of changes (such as creations, deletions and updates) that occur on the basis of:

  • object types

  • object state

  • association instances

  • the management and unmanagement of object instances by topology.

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 exchange of associations

• the exchange of objects involved in the associations

• ideally, the semantics which apply to valid topological representations.

Usability

• provide a paradigm that hides Topology-internal representations from the client to relieve the burden from the client of dealing with Topology internals.

The Topology Service interface and querying capabilities should support:

• comprehensive views of cooperating components, to provide individual views of aggregated components and provide queries based on either comprehensive or individual views

• provide transparency between comprehensive and individual component views that allows comprehensive representations to take on the characteristics of all of their individual components.

Relationship to Existing Services

Relationship Service

• Manage relationships between objects of which the objects themselves are unaware.

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

• Scale up to the management of relationships of hundreds of thousands of objects.

• Provide a mechanism to integrate relationship data from disparate application spaces and present a unified view of the complete set of relationships. This is the aggregation concept which is explained in the abstract portion of the Topology submittal.

• Manage relationships between things that are not CORBA objects.

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

• The distinction between relationships and entities is blurred. This is important as an integration enabler, because what one application views as a relationship may be an entity to another.

  Consider the example in which one application manages People that are Married to each other, and a different application manages Marriages which are Performed by Clergy. In the first application, Marriage is a relationship between persons, but in the second application Marriage is an entity that participates in a different sort of relationship with a clergy.

• The Topology Service maintains information about the kinds of entities and relationships that may be managed. This information can be requested via the defined interfaces and may also be augmented at run-time on the fly.

  The OMG Relationship Service provides no such standard mechanism for a client to gather this information, and new relationships and roles can only be defined by creating new CORBA interfaces - generally a compile-time activity.

Transaction Service

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

Persistence Service

XCMF Policy 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

XCMF Managed Sets

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.