=Paper=
{{Paper
|id=Vol-1360/paper9
|storemode=property
|title=A Domain-Specific Modeling Tool to Model Management Plans for Composite Applications
|pdfUrl=https://ceur-ws.org/Vol-1360/paper9.pdf
|volume=Vol-1360
|dblpUrl=https://dblp.org/rec/conf/zeus/KoppBBLM15
}}
==A Domain-Specific Modeling Tool to Model Management Plans for Composite Applications==
https://ceur-ws.org/Vol-1360/paper9.pdf
A Domain-Specific Modeling Tool to Model
Management Plans for Composite Applications
Oliver Kopp1 , Tobias Binz2 , Uwe Breitenbücher2 ,
Frank Leymann2 , and Thomas Michelbach2
1
IPVS, 2 IAAS, University of Stuttgart, Germany
lastname@informatik.uni-stuttgart.de
Abstract TOSCA is a standard to describe composite Cloud-applications
and their management in a portable fashion. Thereby, BPMN4TOSCA is
a proposed extension for BPMN to ease modeling of management plans.
This demonstration presents a web-based modeling tool that supports
an updated version of BPMN4TOSCA. The updated version supports
direct wiring of data of tasks and events without the need of separate
data objects.
1 Introduction
The Topology and Orchestration Specification for Cloud Applications (TOSCA [6])
is an OASIS standard for automating provisioning, management, and termination
of applications in a portable and interoperable way. To enable this, TOSCA
employs two concepts: (i) application topologies and (ii) management plans. An
application topology describes the software and hardware components involved
in an application and the relationships between them. Management plans capture
knowledge to deploy and manage an application and are typically modeled as
BPMN or BPEL workflows.
The current OpenTOSCA toolchain starts with Winery [4]. Here, a user spec-
ifies required types and models the application topology. Currently, management
plans have to be created manually and uploaded as archive into Winery. The
whole application package including the topology, required types and the manage-
ment plans is exported as CSAR and imported in the OpenTOSCA runtime [1].
The runtime deploys the CSAR and adds the application to the Vinothek [2].
Therein, a user can instantiate an application with one click.
In this paper, we present tool support for modeling management workflows
in Winery. It is based on BPMN4TOSCA, a domain-specific extension of BPMN
to ease the modeling of management plans [3]. BPMN4TOSCA consists of four
new elements: The TOSCA Topology Management Task, the TOSCA Node
Management Task, the TOSCA Script Task, and the TOSCA Data Object. The
TOSCA Topology Management Task is used to interact with the OpenTOSCA
runtime. For instance, to retrieve the current service template. The TOSCA
Node Management Task is used to invoke management operations on a node.
The TOSCA Script Task is used to invoke a script on a node. The TOSCA Data
T. S. Heinze, T. M. Prinz (Eds.): Services and their Composition, 7th Central European Workshop,
ZEUS 2015, Jena, Germany, 19-20 February 2015, Proceedings – published at http://ceur-ws.org
52 Oliver Kopp et al.
Object provides integration of properties of nodes and relationships as data. If
data should be read from or written to a property of a node or relationship, the
TOSCA Topology Management can be used or directly a TOSCA Data Object.
We developed a prototypical BPMN4TOSCA-based modeler [3]. In the mean-
while, we improved the OpenTOSCA container to natively support script exe-
cution [8] and, therefore, the TOSCA Script Task is obsolete. Furthermore, we
discovered that BPMN4TOSCA is still too complex due to directly visible data
dependencies; especially if complex application structures have to be handled in
non-trivial management plans. Therefore, we reduced the complexity by replacing
the TOSCA Data Object, which is the reason for the increased complexity, by a
direct wiring of data dependencies between (i) tasks and (ii) properties of the
components and relations in the TOSCA model.
First, in BPMN4TOSCA management tasks are modeled by specifying the
component and the operation to be invoked on this entity. In the revised version of
BPMN4TOSCA, input parameters can be directly wired with output parameters
of former tasks. Thus, there is no need for an explicit data object. Although this
is a common way to specify data flows, BPMN4TOSCA provides a new means
to ease accessing properties of the components and relations described in the
application topology model: To specify the input parameter value of an operation
invocation, a property of an application component or relation in the topology
can be referenced directly. As a consequence, if the component or relation is not
instantiated when invoking this operation, the specified property is extracted
out of the TOSCA model. If the component or relation is already running, the
property is taken from the instance model of the application that holds current
runtime information about each component and relation of the application. The
same way, properties can be specified for output parameters: After the invocation,
the output is written into the specified property of the instance model. Thus, the
improved version of BPMN4TOSCA simplifies modeling data flow significantly by
enabling a direct access to the instance model of the application, which changes
the data flow from a task-centric perspective to a topology-plan perspective.
The extension itself does not follow the idea of data transfer in BPMN. We
believe, however, that our extension is in line with the use of BPMN in executable
workflows. For instance, camunda BPM also does not use data objects, but uses
a global hashmap to store data [7].
Existing BPMN Modeling tools such as bpmn.io1 , Signavio2 , or the web-
based modeler of Stardust3 neither provide a tight integration with application
topologies nor allow for a direct wiring of data dependencies. Therefore, we tightly
integrated a plan modeler supporting the new version of BPMN4TOSCA in
Winery [4], a web-based modeling tool for TOSCA-based application descriptions.
In the next section, we describe the modeling of a TOSCA management plan
using the presented concept and plan modeler tool. In Sect. 3 we outline next
steps.
1
http://bpmn.io/
2
http://www.signavio.com/
3
https://www.eclipse.org/stardust/
A Domain-Specific Modeling Tool to Model Management Plans 53
2 Modeling a Management Plan in BPMN4TOSCA 2.0
We call the improved version of our management-specific workflow language
BPMN4TOSCA 2.0. The modeling of a management plan in TOSCA basically
encompasses two tasks: (i) specifying the application topology model and (ii)
modeling the management plans, for example, a so-called build plan that deploys
the application. To model the topology, Winery provides a repository of available
node and relationship types, for example, an UbuntuVirtualMachine node type
and hostedOn relationship type. These types typically specify available operations,
for example, the VM type provides an operation runScript to execute low level
management commands. Afterwards, management plans can be modeled. To
describe management logic, Node Management Tasks specify which operation
shall be invoked on which node or relation. Based on that, the input and output
parameters are shown. For the input parameter, there is the choice between String,
Plan, Topology, Deployment Artifact, Implementation Artifact, and Concat. A
string is taken as is as input parameter. When specifying “Plan,” all elements
preceding the current tasks are queried for their output parameters and offered as
choice. In Fig. 1, “Size” of the StartEvent has been chosen. In case “Topology” is
chosen, all properties of all node templates and relationship templates are shown
for selection. In case of “Deployment Artifact,” all deployment artifacts of all node
templates are offered and one of them can be chosen. In case of “Implementation
Artifact,” all implementation artifacts of all node and relationship templates are
offered and one of them can be chosen. One use case for the latter two is to specify
files to be transferred to a node. For instance, a SQL script to be executed can
be chosen here. In case of “Concat,” a combination of the other options can be
specified. This enables a simple transformation of output variables. For instance,
a location path can be appended to the IP address returned by an operation.
In the case of output parameters, only Plan and Topology are offered. When
choosing “Plan,” the parameter is offered as output for subsequent activities.
When choosing “Topology,” the parameter additionally is written to a property
in the topology. Figure 1 shows available properties of an example topology.
The current prototype of the BPMN4TOSCA 2.0 plan modeler is available via
http://dev.winery.opentosca.org. A detailed description of the concepts, the
architecture, and the implementation is provided by Michelbach [5].
3 Next Steps
The modeler provides a basis for modeling management plans. The prototype
enables us to undertake a user evaluation to quantify the improvements of
BPMN4TOSCA 2.0 in comparison to BPMN4TOSA 1.0. When using the modeler
in our projects, we did not need complex transformations of the output parameters.
An analysis of possible management plans is required to justify the absence of
transformation capabilities.
Acknowledgments The research leading to these results has received fund-
ing from the German government through the BMWi projects CloudCycle
54 Oliver Kopp et al.
Figure 1. Editing the properties of a node management task
(01MD11023) and NEMAR (03ET401 8B), the BMBF project ECHO (01XZ13023G),
and the DFG project SitOPT (610872).
References
1. Binz, T., et al.: OpenTOSCA – a runtime for TOSCA-based cloud applications. In:
ICSOC. Springer (2013)
2. Breitenbücher, U., et al.: Vinothek – a self-service portal for TOSCA. In: ZEUS.
CEUR (2014)
3. Kopp, O., et al.: BPMN4TOSCA: A domain-specific language to model management
plans for composite applications. In: BPMN (2012)
4. Kopp, O., et al.: Winery – modeling tool for TOSCA-based cloud applications. In:
ICSOC. Springer (2013)
5. Michelbach, T.: Ein Modellierungswerkzeug für BPMN4TOSCA. Diploma thesis,
University of Stuttgart (2015)
6. OASIS: OASIS Topology and Orchestration Specification for Cloud Applications
(TOSCA) Version 1.0 (2013)
7. Rücker, B.: Data in processes (2013), https://app.camunda.com/confluence/
display/BestPractices/Data+in+Processes
8. Wettinger, J., et al.: Unified invocation of scripts and services for provisioning,
deployment, and management of cloud applications based on TOSCA. In: CLOSER.
SciTePress (2014)