Usually, the manual creation of abstract models is one of the first steps. Afterwards, the instantiated model is derived adding knowledge about the environment.
However, to enable the automated creation of such models, it is necessary to chose a different approach: The abstract models have to be created from real world dependency models, because it is possible to directly construct them from noticeable interactions of or between services implementations.
The input for the process is a list of (abstract) services and component types for which dependencies should be modelled, and a matching list of service implementations and real components. They will finally become the nodes of the abstract, respectively the real world dependency graph. The output is one abstract and one real world model, containing all dependencies detected.
Figure depicts the necessary steps. The left part of the figure represents the abstract view on services, whereas the right side deals with their real world realizations:
It is then possible to apply the required management tasks, e.g. as described in section , to the models.
The first step is manual, but this is not a real problem, because it is directly driven by the needs of the management. If only models of the real world dependencies are needed, the first two steps may even be omitted; instead, the service implementations must then be selected directly.
The installation of the means of data collection should -- together with the process of collection itself -- be tied to already used management tools, like management platforms, simple SNMP ([#!rfc1157!#]) querying software etc. (for a complete overview see [#!han99!#]). Thus, the effort that must be put into these steps is acceptable.
The most complex task is the final creation of the model (step 6). As it has to deal with even more objects (nodes), it is even more complex than the original task of directly constructing the abstract models. However, with data available from step 5 it is now possible to automate this step. This is described in more detail in the following section.
Figure also shows possible extensions of the process (dotted lines, marked with asterisks) enabling even more applications of the dependency models.
The first types of applications assume the iterative repetition of steps 4 to 6 (*) -- respectively 4 to 7, if they work on the abstract models -- and take two (or more) models, created at different points in time, as input, e.g. to make out changes that happened in the system.
Such comparisons support fault prediction, because changes in system behaviour often reflect errors already present, but simply do not yet effect the usability of services -- or at least not to a noticeable extent.
The detected changes may also be used to point out forbidden actions or disallowed use of services. This is helpful especially for intrusion detection or to recognise service misuse.
Further helpful applications are based on the comparison of the real world models with a re-instantiated abstract model (**), making exceptions and special cases explicitly visible.
Both types of applications take special benefits from the modelling process that are not available in conventional, manually created models.