Overall Modelling Process

  Before an explanation of the modelling itself, this section describes the overall modelling process it is embedded in.

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.

  

Abbildung: Steps of the Modelling Process

3#3

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:

1.

First, all services and components that should be part of the model must be selected. Of course this depends on the management tasks the model will be used for.

2.

For each abstract service the matching implementations in the real world must be chosen. These may be a number of different software implementations, hardware components, etc. In some cases, as explained in section , several of these objects may finally represent only one instance of a service.

3.

Now, the necessary means of data collection may be installed per object, using e.g. local management agents or tools commonly available.

4.

Then, the real world data may be collected,

5.

merged according to the reduced model, and

6.

dependencies may be calculated. This step is the actual challenge for the automation using neural technologies, as described in the next section.

7.

If necessary for the management task, also an abstract service model can be derived, from the model above, together with the information from step 2.

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.

  

Abbildung: Extension of the Modelling Process

4#4

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.