Figure shows a small scenario with two domains (L and R). One hosts a web server WS and a database server DB providing content for the web pages. The other contains the Domain Name System DNS responsible to resolve the name of both web- and database server. Thus, WS is said to depend on DNS. Further, there are two users who typically access information on the web server via web clients. They depend on WS and--if they want to type normal URLs instead of IP addresses--also on DNS.
The figure also depicts the mentioned dependencies between its major objects. For simplicity, it neglects all dependencies to the communication infrastructure and further sub-services. One can see that although several objects of the example depend on DNS, none of their existing implementations explicitly tells to do so and cannot be queried by management applications for this fact.
As there is no support to obtain information about dependencies by nowadays management tools, conventional approaches generally struggle with evaluation problems, e.g., of configuration files (for an overview see section ). The problem becomes worse if, e.g., the format of those files changes with software updates etc. In heterogeneous environments such modeling systems typically must further be restricted to a very limited set of resource types or vendors. The major alternative to dependency detection at runtime would be 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 Languages (ADL) and Module Interconnection Languages (MIL), respectively. 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 (section explains existing applications). This fact 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.
Typical enterprise scenarios will of course be much larger than the example above. In such cases it would be hard to keep the overview even with the help of dependency models. To reduce the number of elements, respectively to restrict the model to currently interesting parts, the concept of domains is used to provide a basic means of structuring models. This allows to provide an overview on higher, e.g., business process oriented levels, and enhances visualization and understandability for the IT-managers working with them--without abandoning details on lower levels needed for proper fault diagnosis. Graphical user interfaces of management tools will typically be capable of folding and unfolding domains to navigate into sub-models, thus handling scalability of their visualization. However, this concept also needs support from the underlying modeling architecture.
To overcome the two main problems of automated modeling--the lack of direct dependency information as well as the scalability issues--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, e.g., the training methods of our neural networks, but concentrates on modeling and realization aspects relevant for IT-management. Thus, the second part (section ) deals with questions of installation efforts and scalability to seamlessly integrate the modeling into real IT-environments.
Section introduces the most important types of models and shows their existing applications. This is followed by an overview of the state of the art of approaches to model creation in section . They are analysed by the help of a generic modeling process which also leads to a complete set of requirements. Our solution to meet those requirements is presented in section . Section draws the conclusions of the paper.