A Loosely Coupled Federation of Distributed Management Services Extended Version

[attachment=17380]

INTRODUCTION
For many years, management of networks and distributed systems has been shaped on
one hand by dedicated management architectures, such as OSI-MF/TMN and SNMP,
and on the other hand by monolithic management platforms and frameworks, such as
HP Openview, IBM Netview, or CA Unicenter. SNMP’s restricted information modeling
techniques make designing management applications complex and awkward. Both
SNMP and TMN are therefore complex technologies and management platforms supporting
one or even both of them are just as complex.


INTRODUCTION 2
process, a matching organizational framework and constant customization, configuration,
and development. Therefore, only large organizations can afford to invest in this
process and the highly specialized human resources to run the systems.
Current and widely used technologies like CORBA, theWorldWideWeb (WWW),
and Java have led to a strong trend of replacing the special-purpose management architectures
by multi-purpose middleware infrastructures. These infrastructures allow for
cheap off-the-shelf components, such as the CORBA Common Object Services (Naming,
Transaction, Life-Cycle, etc.), and are available to a broad range of developers,
programmers, and operators. However, we have to distinguish between two basic types
of approaches:


SCENARIOS
To introduce our architecture, we start by describing a few scenarios which we think
are typical network management tasks. By analyzing these scenarios, we can identify
the components that are needed to support these tasks. The scenarios are not focused
on an administrator’s work but describe tasks performed by different people in a
medium- to large-sized company. All scenarios are centered around the administration
of a work-group’s printer. As these scenarios show, human intervention is required
only in abnormal cases.


ANALYSIS
By analyzing the above use-cases, we can identify a number of properties that our
communication infrastructure needs to offer, as well as a number of services that need
to be present somewhere in the network.

3.1 Infrastructure Requirements
Our architecture consists of a large number of small components which have to discover
and interact with each other at run time. As this is a recurring problem that all
components face, the communication infrastructure should support this functionality
and ease its usage. For both problems—communication across a network and finding
services—a number of solutions exist. Communication can be performed via CORBA,
Java RMI, plain sockets, etc. Locating services is possible via COS naming services,
RMI registries, and so on. However, these technologies do not completely satisfy our
aim. They all require clients and services to know the location (usually an IP address)
of the naming service and, as our ultimate goal is to minimize pre-configuration, this
is not acceptable. Clients should configure themselves as autonomously and automatically
as possible. Jini was found to support this requirement.