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.
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 [
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 [
Existing BPMN Modeling tools such as bpmn.io1, Signavio2, or the
webbased 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 [
A Domain-Specific Modeling Tool to Model Management Plans
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 ofered 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 ofered and one of them can be chosen. In case of “Implementation
Artifact,” all implementation artifacts of all node and relationship templates are
ofered and one of them can be chosen. One use case for the latter two is to specify
ifles 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 ofered. When
choosing “Plan,” the parameter is ofered 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 [
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 funding from the German government through the BMWi projects CloudCycle (01MD11023) and NEMAR (03ET401 8B), the BMBF project ECHO (01XZ13023G), and the DFG project SitOPT (610872).