Types of Models

  To enable a common understanding of the meaning of dependency models in the explanations following later, this section distinguishes and explains several model types.

Generally speaking, service dependency models can be considered graphs consisting of nodes which represent the managed objects -- in this case the services or service realizations -- and of edges, standing for functional inter-service dependencies.

In the simplest case the graph is not directed; then edges only represent generic relationships, but it is not possible to express the direction of the dependencies. This must be regarded a serious deficiency for lots of applications, but might be sufficient for special tasks.

Usually, directed graphs are used. Besides the direction it is in some cases useful to attach further management relevant attributes to them. With these it is possible:

• to form groups which, e.g., to express that a dependency cannot occur without the others,
• to express that some dependencies must occur in a certain order, or
• to attach values of strength or likelihood.

One can already imagine that dependency models used for different purposes may differ in various ways, e.g. according to their level of abstraction, the degree of detail and of course the types of services and components. Examples are:

• hosts with communication dependencies
• high level services, disregarding distributed service implementations and
• services including several levels of subservices.

Basically, for the models there are always two opposite levels of abstraction:

1.

abstract service models and

2.

models of real world services (applications, components, etc.).

The first type is used to model purely abstract services with their dependencies. It is independent of any concrete runtime environment. Figure shows an example.

  

Abbildung: Typical Abstract Service Dependency Graph

1#1

Advantages of abstract representations are that they are comparably small, compared to the second type, generic in nature and reusable in various environments.

Models of the second type provide a representation of a particular, real environment -- it models the dependencies of the service implementations as they exist at runtime, like a program or piece of hardware communicating with others, or depending on underlying software/hardware components. Thus, the infrastructure the services are implemented in influence the structure of the model.

Sometimes these models are simply considered as instantiated examples of the abstract graph. However, while this is true for the nodes (services), this may not be true for the edges (dependencies). It may, e.g., not be the case due to special circumstances, where the abstract model is (purposely) generalising too much, thus hiding differences in distinct service implementations.

Figure shows a scenario, where one of the web clients does not depend on the DNS server. This might be the case, because only very special web pages are viewed from that particular browser, for which only direct IP addresses are needed, or simply because the host names are stored in a static configuration file. Thus, the dependency depicted by the broken line would be part of a model instantiated from the abstract one (figure ), but is not part of the real world model. For simplicity reasons, the modelling of the communication infrastructure is left aside.

  

Abbildung: Real World Service Dependency Graph

2#2

Thus, the

3.

instantiated dependency model

is a third type of models.

Compared to the abstract models, a possibly huge number of objects and dependencies might be needed for the real world and the instantiated models. The real world graph has less or exactly the same number of dependencies than the instantiated one, otherwise there would be major faults in the abstract model.

In the differences between these two graphs lies useful information, because they are, in other words, exceptions from the generic case.

Models, as usually described in other works, are either abstract or instantiated models. The benefits of models that directly describe real world dependencies are usually left out of consideration, because the automatic creation is not yet possible in an adequate way.

Between these two extremes of abstract and real world models lie the

4.

reduced real world model.

Just like the real world models, they provide a view on the real services and resources, but -- to reduce complexity -- they make one step towards abstraction by merging some instances into one node.

This may, happen to hide the existence of redundant services, or with services/applications of the same type used exclusively. The latter case is useful, e.g. in a scenario where a worker may use one of two input terminals, according to his location at the working environment (e.g. the side of the assembly line), but not both at the same time.