![](bg6.png)
ized and normalized manner. Additionally, the nor-
malized node types may define abstract definitions to
describe the overall semantics and explicit versions.
For example, a Ubuntu node type defines that the
VM is running a Ubuntu OS, while a Ubuntu 20.04
node type refines this information with a specific ver-
sion. However, there are cases in which the deploy-
ment technology-specific information is not sufficient
enough to identify a component’s type. In this case,
the generic TOSCA Normative Node Types (OASIS,
2020) are used to represent the identified compo-
nents. For example, TOSCA defines a generic Soft-
ware Component node type which can be used to rep-
resent any kind of software component. Similarly, the
generic Compute node type is available to represent
computing resources such as VMs or containers if a
more concrete node type cannot be identified.
Additionally, the instance model normalizer must
map component specific properties from deployment
technology-specific information to the normalized
representation in TOSCA. Thus, as node types de-
fine the available properties their node templates have,
four kinds of mappings between instance properties
and properties of the node type, can be differentiated:
(i) A property is named equally. In most cases, the
mapping is straightforward. However, the contents
may be semantically different and a more complex
mapping may be required (cf. case iii). (ii) The name
of a property is different but they are describing the
same element. For example, a property of a VM in the
retrieved instance information is named “IP-address”,
while the Compute node type defines it as “public-
address”. Hence, the mapping is usually straightfor-
ward. (iii) A property consists of two or more proper-
ties in one model, while it is combined into one in the
other model. This may be the case, if a web compo-
nent has only a property called “url” while the corre-
sponding node type defines separate properties for the
“hostname”, “port”, and “context-path”. Thus, a more
complex property mapping is required. (iv) Lastly,
there may be properties which cannot be mapped. For
example, if a property cannot be mapped to a property
of a node type, it can be saved in the model as addi-
tional metadata to enable manual refinement of the
component, e. g., to a custom node type that could not
be identified automatically. In contrast, if a property
is not available in the retrieved instance data, it cannot
be filled and, thus, will remain empty.
3.3 Instance Model Completer
In the third, new Instance Model Completer com-
ponent, the normalized instance model is refined
with detailed information about component types and
property values. Since the instance information that
are accessible from the deployment technologies may
not produce a complete model of an application, we
introduce the Instance Model Completer as a third
step. The instance model completer is based on
our previously introduced plugin-based crawler (Binz
et al., 2013). Hereby, plugins identify components
of an application, retrieve their configuration, or re-
fine their types. Then, these component-specific in-
formation are used to improve the derived instance
model. For example, a Tomcat plugin is able to iden-
tify whether a Tomcat web server is running on a VM
or container, refine an already identified Tomcat com-
ponent to a specific version, and identify the port it is
listening to. Additionally, plugins may also be able
to refine the properties or types of multiple compo-
nents. For example, as a Tomcat web server provides
access to applications via the internet, it may be able
to identify the context in which a particular web ap-
plication is accessible. Thus, we extended our con-
cepts by a sub-graph mechanism to identify plugins
that are able to refine the instance model and enrich
it with more details. Thus, to refine node types and
fill their properties with additional runtime informa-
tion, the plugins may specify multiple detectors that
define graph elements they can refine. For example,
the Tomcat plugin may be able to refine the normative
WebServer (OASIS, 2020) node type to a concrete
Tomcat 9 node type if it can identify specific files or
processes running an the corresponding VM. To tell
the instance model normalizer, that the Tomcat plugin
may be able refine a node template of type WebServer
to a Tomcat web server, the plugin’s detector contains
a node template of type WebServer. Additionally, to
also define that the plugin is able to find context paths
of applications running on a Tomcat web server, it
also defines a detector with two node templates: A
Tomcat web server that hosts a node template of type
WebApplication. Thus, to complete a whole applica-
tion, the instance model completer applies all plugins
that have matching detectors, i. e., their detectors are
sub-graphs of the instance model, until there are no
more plugins that can refine the instance model.
3.4 Management Feature Enricher
After a normalized and completed instance model of
the application is generated, it is enriched with addi-
tional management functionalities using the adapted
Management Feature Enricher in the fourth step. The
enrichment of instance models with additional man-
agement functionality is hereby based on the MFEW
method as described in Sect. 2.2. In general, we
can distinguish two kinds of management function-
alities: State-changing and state-preserving manage-
ment functionality. While state-changing functional-
CLOSER 2021 - 11th International Conference on Cloud Computing and Services Science
104