Introduction

  Over the last couple of years IT-management has made enormous progress: Management architectures and their realization in platforms and tools provide standardized remote access to the managed environment [#!han99!#]. But there is still a number of management tools that is based on proprietary resource interfaces. And worse, often important management information is only available through those non-standardized interfaces or even not at all. This is especially true for information about dependencies between those managed objects, although this would be required by the various management applications described in section .

Figure shows a small scenario with two domains. One hosts a web server WS, the other contains the Domain Name Service DNS responsible to resolve the name of the web server and other subservices that are not shown in the figure, e.g., a database server providing content information for the web pages. Thus, the web server is said to depend on the DNS server. Further, there are two users who typically access information on WS via web clients. They depend on the web server and--if they want to type normal URLs instead of IP addresses--also on DNS. The figure also depicts the mentioned dependencies between the major objects. For simplicity, it neglects all dependencies to the communication infrastructure and further sub-services.

Although several objects of the example depend on DNS, none of them explicitly tells to do so and cannot be queried by a management application for their dependencies. In the example, the dependencies are hidden in WS' configuration file that mentions the database server by name instead of by IP address, plus the fact that this host name is not listed in local name resolving files like ``resolve.conf''. One can already imagine how hard an automated detection of dependencies by looking at configuration files would be. The case would become even more complicated, if host name and IP address indeed are listed in ``resolve.conf'', because it would then be up to a third file to determine whether local resolving is carried out at all.

Simple multi service scenario  [r]

Conventional approaches generally struggle with evaluation problems of various configuration files as mentioned above. It gets even worse if the format of those files changes with software updates. In heterogeneous environments such modeling tools typically must further be restricted to a very limited set of resource types or vendors. The major alternative to dependency detection at runtime is an a priori description of the environment with its components and dependencies, similar to what is achieved in software engineering by the help of Architecture Description- resp. Module Interconnection Languages. However, so far similar dependency description languages have not been commonly agreed on in the IT-network and service provisioning world.

As a consequence, dependency models are not generally used in today's management world--although their benefits are commonly known. This leads to a lack of overview for the IT-administrators and prevents the use of powerful management tools like event correlators that are based on dependency models [#!gopa2000!#]. More applications are described in section together with an overview of existing types of dependency models.

To overcome the problems of automated modeling described above, this paper presents a new approach to gain management relevant dependency information. Unlike conventional approaches it is designed to obtain useful results independent of the heterogeneity of the managed environment. It is based on two key parts. The first (covered by section ) are the underlying concepts of dependency determination that are carried out with the help of Neural Networks. However, this paper does not aim at details about artificial intelligence like the training methods of our neural networks etc., but concentrates on modeling and realization aspects relevant for IT-management. Thus, the second part (section ) deals with the concepts' integration into real IT-environments and management processes, where questions of installation efforts, scalability etc. have to be taken into account. The conclusions of the paper are drawn in section .