Systems Management: Topology Service
Systems Management: Topology Service
Copyright © 1997 The Open Group
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:
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
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.
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.
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:
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
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
are unaffected by their involvement in topological
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
of objects, yet be able to also not be so heavyweight and burdensome as to not be appropriate for small workgroup environments who may
of objects to manage.
The Topology Service should allow the storage of relationships between CORBA objects and
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
The Topology Service should not restrict implementations from being federated in order to
support improved performance in large-scale, distributed environments.
The Topology Service should support arbitrary queries which are client-defined. Example queries might include:
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.
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
The Topology Service must provide an integrated, comprehensive view of both logical and
The Topology Service should provide direct support for
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
The Topology Service should directly support integrated management of
systems, networks and distributed applications. Queries should be able to
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
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:
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.
The Topology Service should support the interchange of
topological data with heterogeneous implementations, including:
the exchange of associations
the exchange of objects involved in the associations
ideally, the semantics which apply to valid topological representations.
The Topology Service should support a usable, intuitive interface:
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
provide transparency between comprehensive and individual component views that allows
comprehensive representations to take on the characteristics of all of their individual
Relationship to Existing Services
The OMG Relationship Service has considerable overlap in its functionality with the
proposed Topology Service. In particular they both address the following key requirement:
Manage relationships between objects of which the objects themselves
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
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
is blurred. This is important as an
because what one application views as a relationship may be an entity
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,
is a relationship between persons, but in the second
is an entity that participates in a different sort of relationship with a
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.
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
Topology does not provide any general lifecycle management services.
Thus, there is no overlap with the GenericFactory interface.
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
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
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
would be created for each XCMF object supporting the Member interface, and a
topological entity of type
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.