Modellierung von TOSCA-basierten Deployment Modellen in Java
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Institut für Architektur von Anwendungssystemen
Universität Stuttgart
Universitätsstraße 38
D–70569 Stuttgart
Bachelorarbeit
Modellierung von TOSCA-basierten
Deployment Modellen in Java
Jan Fuhrmann
Studiengang: Softwaretechnik
Prüfer/in: Prof. Dr. Dr. h. c. Frank Leymann
Betreuer/in: Dr. Uwe Breitenbücher
Beginn am: 6. November 2019
Beendet am: 6. Mai 2020
Kurzfassung
In den letzten Jahren gewinnt das Thema Cloud Computing in vielen Bereichen der Gesellschaft
zunehmend an Bedeutung. Immer mehr Unternehmen verlagern Anwendungen sowie Teile der loka-
len Infrastruktur in die Cloud. Die Automatisierung des Deployments solcher Cloud-Anwendungen
wird jedoch durch deren steigende Komplexität und zugleich hohe Diversität signifikant erschwert,
weshalb eine einheitliche Strukturierung erforderlich ist. Die „Topology and Orchestration Specifi-
cation for Cloud Applications (TOSCA)“ definiert einen Standard für die Beschreibung und das
Management sowie die automatisierte Bereitstellung von Cloud-Anwendungen. Alle Komponenten
einer Anwendung, in TOSCA Node Templates genannt, inklusive Abhängigkeiten und Verbindungen
(Relationship Templates) werden dabei innerhalb sogenannter Topology Templates dargestellt.
Bisher erfolgt die Modellierung von TOSCA Topologien ausschließlich in XML oder YAML, aber
in einer objektorientierten Programmiersprache wie Java ist dies bislang nicht möglich. In dieser
Arbeit wird ein Konzept vorgestellt, das eine automatisierte Konvertierung von TOSCA Node Types
und Relationship Types in die Programmiersprache Java beschreibt. Diese Umwandlung findet
im sogenannten „TOSCA2JAVA-Transformator“ statt, der im Rahmen dieser Arbeit entwickelt
wurde. Er bildet damit die Grundlage für eine zukünftige Kreierung und Konfiguration von TOSCA
Topologien in der objektorientierten Umgebung von Java.
Abstract
In recent years, cloud computing has become increasingly important in many areas of society.
More and more companies are shifting applications and parts of their local infrastructure to the
cloud. However, automating the deployment of such cloud applications becomes significantly more
difficult by their increasing complexity and simultaneously high diversity, which makes a consistent
structuring necessary. The “Topology and Orchestration Specification for Cloud Applications
(TOSCA)“ defines a standard for the description, management and automated deployment of cloud
applications. All components of an application, in TOSCA declared as Node Templates, including
dependencies and connections (Relationship Templates) are represented within so-called Topology
Templates.
Until now the modeling of TOSCA topologies has been done exclusively in XML or YAML, but
this was not yet possible in an object-oriented programming language such as Java. This thesis
presents a concept that allows an automated translation of TOSCA Node Types and Relationship
Types into the object-oriented programming language Java. This conversion takes place in the so-
called “TOSCA2JAVA-Transformator“, which was developed within the scope of this thesis. It thus
forms the basis for a future creation and configuration of TOSCA topologies in the object-oriented
environment of Java.
3Inhaltsverzeichnis
1 Einleitung 13
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2 Anwendungsbeispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2 Hintergrund und Related Work 17
2.1 OASIS Standard TOSCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 TOSCA Deployment Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 OpenTOSCA Ecosystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 Programmiermodell für TOSCA Topology Templates in Java 27
3.1 Erweiterte Beispiel-Topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 Modellierung von Node Templates in Java . . . . . . . . . . . . . . . . . . . . 28
3.3 Modellierung von Relationship Templates in Java . . . . . . . . . . . . . . . . 30
3.4 Praktische Umsetzung der Beispiel-Topologie in Java . . . . . . . . . . . . . . 31
4 Transformation von TOSCA Typen in Java Klassen 33
4.1 TOSCA Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2 Transformationsregeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3 Java Class Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5 Prototypische Validierung 43
5.1 Architektur des Java Prototyps . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2 Transformation von Node Types in Java via Service Template . . . . . . . . . . 48
6 Zusammenfassung und Ausblick 51
Literaturverzeichnis 53
5Abbildungsverzeichnis
1.1 Überblick des Konzepts anhand eines Input/Output-Modells . . . . . . . . . . . 14
1.2 Beispiel-Topologie in TOSCA . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1 Drei Schichten einer TOSCA-basierten Anwendung . . . . . . . . . . . . . . . . 17
2.2 Aufbau eines Service Templates in TOSCA . . . . . . . . . . . . . . . . . . . . 19
2.3 Struktur eines Cloud Services Archives (CSAR) in TOSCA . . . . . . . . . . . . 20
2.4 Schematischer Aufbau des OpenTOSCA Ecosystems [Ope] . . . . . . . . . . . . 22
2.5 Darstellung der Beispiel-Topologie in Winery . . . . . . . . . . . . . . . . . . . 23
2.6 Darstellung integrierter Cloud-Anwendungen in der Vinothek [BBKL14b] . . . . 25
3.1 Erweiterte Version der Beispiel-Topologie in TOSCA . . . . . . . . . . . . . . . 28
4.1 Ausführliche Ansicht der Übersicht des Konzepts inklusive TOSCA2JAVA-
Transformator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7Verzeichnis der Listings
2.1 Definition eines Node Types in XML . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1 Instanziierung und Parametrisierung eines Node Templates anhand der Beispiel-
Topologie in Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 Implementierung eines Relationship Templates in Java . . . . . . . . . . . . . . 31
3.3 Modellierung eines vollständigen Topology Templates in Java . . . . . . . . . . 32
4.1 XML-Annotationen der Attribute und Elemente im TOSCA2JAVA-Transformator 35
4.2 Resultat des Exports einer Java-Klasse anhand der Komponente FlinkApp . . . . 39
4.3 Superklasse „JNodeTemplate“, die alle Eigenschaften eines Node Templates an die
Node Type Klasse vererbt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.1 Verwendung des JAXB-Parsers für die Instanziierung eines XML-Elements in Java 44
5.2 Implementierung des TOSCA2JAVA-Transformators: Erstellung einer Java-Klasse
Node Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3 Implementierung des TOSCA2JAVA-Transformators: Hilfsmethode zur Integration
von Requirement Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.4 Implementierung des TOSCA2JAVA-Transformators: Hilfsmethode zur Integration
von Management Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.5 Implementierung des TOSCA2JAVA-Transformators: Transformation mehrerer
Node Types über das Service Template . . . . . . . . . . . . . . . . . . . . . . . 49
9Abkürzungsverzeichnis
API Application Programming Interface. 24
BPEL Business Process Execution Language. 20
BPMN Business Process Model and Notation. 20
CSAR Cloud Service ARchive. 13, 20, 24
DA Deployment Artifact. 18
IA Implementation Artifact. 18
IP Internetprotokoll. 18
JAXB Java Architecture for XML Binding. 34, 38, 43
OASIS Organization for the Advancement of Structured Information Standards. 13
REST Representational State Transfer. 18
TOSCA Topology and Orchestration Specification for Cloud Applications. 3, 13, 17
URL Uniform Resource Locator. 23
VALESCA Visual Editor for TOSCA. 20
VINO4TOSCA Visual Notation For TOSCA. 14
WSDL Web Services Description Language. 18
XML Extensible Markup Language. 14, 34
YAML YAML Ain’t Markup Language. 14
111 Einleitung
In diesem Kapitel wird zunächst die Motivation und das Ziel dieser Arbeit in Abschnitt 1.1 vorgestellt.
Danach folgt ein Beispiel einer Anwendungstopologie in Abschnitt 1.2, das zur Erläuterung der
entwickelten Konzepte die gesamte Arbeit begleiten wird. Abgeschlossen wird diese Einleitung in
Abschnitt 1.3, der einen kurzen Überblick über die Struktur der Arbeit geben wird.
1.1 Motivation
In den letzten Jahren gewinnt das Thema Cloud Computing in vielen Bereichen der Gesellschaft
zunehmend an Relevanz. Immer mehr Anwendungen und Services inklusive Ressourcen (Software,
Speicher, Datenbanken, etc.) werden von Unternehmen in die Cloud verlagert, um die eigene
lokale Infrastruktur zu entlasten. Größere Flexibilität, diverse Möglichkeiten der Skalierung oder
Einsparung von Kosten sind nur wenige der zahlreichen Vorteile von Cloud Computing gegenüber
der Bereitstellung von Ressourcen in lokalen Datenzentren [Ley09].
Aufgrund des rasanten technologischen Fortschritts und dank diverser neuer Techniken sind Un-
ternehmen bereits heute in der Lage, ihre IT-Systeme kostengünstig in die Cloud auszulagern und
dadurch eine hohe Flexibilität bei wachsendem Automatisierungslevel zu erreichen [Ley09]. Die
zunehmende Komplexität und zugleich hohe Diversität von Cloud-Anwendungen erschwert jedoch
die Umsetzung der Automatisierung des Deployments erheblich. Ohne ein festgelegtes automati-
sierbares Format gestaltet sich auch die Verwaltung des Deployments solcher Anwendungen als
fehleranfällig und erfordert zudem hohen Zeitaufwand [BBKL14a]. Eine einheitliche Strukturierung
ist somit erforderlich, die das Erstellen, die automatisierte Bereitstellung und das Management
von Cloud-Anwendungen ermöglicht. Die „Topology and Orchestration Specification for Cloud
Applications (TOSCA)“ [OAS13b] definiert einen Standard der „Organization for the Advancement
of Structured Information Standards (OASIS)“, welcher all diese Faktoren berücksichtigt. Sie legt
ein Metamodell fest, womit Instanzen von Modellen standardisiert erzeugt werden können, die
das Deployment einer Anwendung deklarativ beschreiben. Eine solche Instanz spezifiziert neben
der kompletten Infrastruktur, auf der die Anwendung basiert, zudem alle Abhängigkeiten sowie
Verbindungen der beteiligten Komponenten untereinander. Diese Struktur bestehend aus allen Kom-
ponenten und Verbindungen, wird als „Topologie“ [BKLW17] bezeichnet und bildet als Bestandteil
deklarativer Modelle die Grundlage zur Beschreibung des Deployments einer Anwendung. Die
genannten und zahlreiche weitere Konzepte des Metamodells werden in Abschnitt 2.1 detailliert
erläutert und können außerdem über die Spezifikation eingesehen werden. TOSCA bietet zudem
die Möglichkeit, die gesamte Beschreibung des Deployments einer Anwendung als ebenfalls stan-
dardisiertes „TOSCA Cloud Service ARchive (CSAR)“ zu exportieren und unterstützt damit den
Aspekt der Portabilität, der speziell bei Cloud-Anwendungen wünschenswert ist.
131 Einleitung
Abbildung 1.1: Überblick des Konzepts anhand eines Input/Output-Modells
Bisher geschieht die Modellierung der Anwendungstopologie, in TOSCA Topology Template ge-
nannt, ausschließlich direkt über die von TOSCA definierten Sprachen Extensible Markup Language
(XML) [OAS13a] bzw. YAML Ain’t Markup Language (YAML) [OAS16] oder über grafische
Modellierungswerkzeuge wie Eclipse Winery [KBBL13], die bereits spezifizierte Modelle veran-
schaulichen und sich durch eine übersichtliche Benutzeroberfläche steuern lassen. Das Erstellen und
Verwalten von TOSCA-basierten Deployment-Modellen über eine objektorientierte Programmier-
sprache wie Java ist bislang jedoch nicht möglich. Im Zuge dessen soll in dieser Arbeit ein „TOSCA
to Java Model Transformator“ entwickelt werden, der bereits bestehende Definitionen von Node
sowie Relationship Types einliest und daraus anschließend die entsprechenden Java-Klassen erstellt.
Diese bilden dann die Grundlage, um Topologien zukünftig auch innerhalb der objektorientierten
Umgebung von Java bearbeiten und exportieren zu können.
Abbildung 1.1 zeigt einen Überblick des Konzepts dieser Arbeit und enthält außerdem den entwi-
ckelten TOSCA2JAVA-Transformator, der den Umwandlungsprozess von TOSCA-Modellen
in Java koordiniert. Damit soll es nun möglich sein, TOSCA Topology Templates über Node und
Relationship Types direkt objektorientiert in Java-Klassen zu erstellen. Eine solche Java-Klasse
beinhaltet folglich alle Eigenschaften der Node Types und repräsentiert damit das zugrunde lie-
gende Node Template. Hierzu werden die Vorteile der Objektorientierung von Java genutzt, die
es ermöglicht, diverse Eigenschaften der bestehenden Node Types als Parameter und Methoden
innerhalb einer Klasse in Java darzustellen. Weiterhin sollen diese Klassen über eine entsprechende
Funktionalität komprimiert und anschließend als CSAR-Archiv exportiert werden können.
1.2 Anwendungsbeispiel
Für die Veranschaulichung der unterschiedlichen Operationen und Transformationsregeln des
TOSCA2JAVA-Transformators wird das in Abbildung 1.2 dargestellte Beispiel einer Topologie
in TOSCA verwendet. Es basiert auf der „Visual Notation For TOSCA (VINO4TOSCA)“, die in
Breitenbücher et al. [BBK+12] definiert wurde. Jedes abgerundete Rechteck beschreibt ein Node
141.3 Aufbau der Arbeit
Template, Relationship Templates werden als gerichtete Kanten in Form von Pfeilen dargestellt.
Diese Beispiel-Applikation zeigt eine vereinfachte Topologie der in Falkenthal et al. [FBK+16]
beschriebenen FlinkApp und wird die gesamte Arbeit begleiten.
Es ist eine in der Programmiersprache Python 2.71 geschriebene Anwendung dargestellt, die auf dem
Stream-Verarbeitungs-Framework Apache Flink Simple Version 1.0.32 basiert. Flink Simple 1.0.3.
läuft dabei auf dem Betriebssystem Ubuntu 14.043 , worauf zugleich auch das Python-2.7-Paket
installiert ist. Die komplette Anwendung befindet sich außerdem innerhalb einer virtuellen Maschine,
welche auf VMware VSphere 5.54 betrieben wird.
Abbildung 1.2: Beispiel-Topologie in TOSCA
1.3 Aufbau der Arbeit
Diese Arbeit beschreibt zunächst das bereits bestehende Metamodell von TOSCA sowie weite-
re Hintergrundinformationen inklusive Related Work in Kapitel 2. Hier wird die Problematik
erläutert, weshalb bisher kein derartiges System in Java existiert, um dann anschließend einen
ersten Lösungsansatz in Kapitel 3 zu präsentieren. Im folgenden Kapitel 4 wird der kreierte „TOS-
CA2JAVA-Transformator“ sowie dessen Funktionsweise explizit erläutert und dabei genauer auf die
Transformationsregeln eingegangen, die für die Konvertierung der XML-Modelle in Java notwendig
sind. Anschließend wird eine prototypische Validierung des entwickelten Systems in Kapitel 5
durchgeführt, die sämtliche eingeführte Konzepte und Code-Algorithmen beinhaltet. Abgeschlossen
wird die Arbeit mit einer Zusammenfassung und einem Ausblick in Kapitel 6.
1 https://python.org
2 https://flink.apache.org
3 https://ubuntu.com
4 https://vmware.com
152 Hintergrund und Related Work
In diesem Kapitel werden Hintergrundinformationen beschrieben, die zum Verständnis von TOSCA
und der durch diese Arbeit ermöglichten Modellierung in Java notwendig sind. Es wird zunächst der
OASIS Standard TOSCA in Abschnitt 2.1 eingeführt und anschließend in Abschnitt 2.2 unterschied-
liche bereits bestehende TOSCA Deployment Systeme beschrieben. Abgeschlossen wird dieses
Kapitel mit der praktischen Umsetzung des Standards im OpenTOSCA Ecosystem, das exemplarisch
ein solches Deployment System repräsentiert (Abschnitt 2.3).
2.1 OASIS Standard TOSCA
Die Topology and Orchestration Specification for Cloud Applications (TOSCA) [OAS13b] ist
ein im Jahr 2013 veröffentlichter OASIS-Standard zur Beschreibung und Verwaltung sowie der
automatisierten Bereitstellung von Cloud-Anwendungen. TOSCA basiert auf der Grundidee, den
kompletten Aufbau einer Cloud-Anwendung inklusive bestehender Abhängigkeiten und Ressourcen
zu spezifizieren und definiert dafür ein Metamodell für deklarative Deployment Modelle, welche
auf Topologien basieren. TOSCA verwendet bei der Darstellung einer Applikation diverse interne
Bezeichnungen, welche die Struktur der Applikation in unterschiedliche Bereiche gliedern. Anwen-
dungen werden in TOSCA über ein sogenanntes Service Template modelliert, das unter anderem
auch das Topology Template beinhaltet. Dieses stellt die Struktur der Anwendung als gerichteten
Graph bestehend aus Knoten und Kanten dar [BBH+13], wodurch ein deklaratives Deployment
Modell beschrieben wird. Die Knoten beschreiben dabei die unterschiedlichen Komponenten der
Applikation und werden als Node Templates bezeichnet, während die Kanten die Beziehungen
zwischen den Komponenten über Relationship Templates definieren. Beide Templates fungieren
dabei als Instanzen der sogenannten Node Types und Relationship Types, die jeweils die Semantik
zugehöriger Templates genauer spezifizieren. Aus Node Templates und Relationship Templates
können Objekte zur Laufzeit instanziiert werden, woraus die endgültige Differenzierung in drei
Schichten resultiert, welche in Abbildung 2.1 zu sehen ist.
Abbildung 2.1: Drei Schichten einer TOSCA-basierten Anwendung
172 Hintergrund und Related Work
Nachdem die Komponenten des Topology Templates genannt wurden, sollen nun die Node Types
und Relationship Types genauer betrachtet werden. Der strukturelle Aufbau eines Node Types im
XML-Format anhand des Beispiels FlinkApp ist in Listing 2.1 dargestellt. TOSCA unterstützt neben
XML zudem YAML [OAS16] als alternative Serialisierungsform. Das gezeigte TOSCA-Modell
beginnt standardisiert mit einem Definitions-Tag und beinhaltet darin als weiteres XML-Element
die entsprechende Komponente mitsamt aller weiterer Informationen.
In den Node Types werden alle Properties und Interfaces des zugehörigen Node Templates gespei-
chert. Als Properties werden hier Informationen bezeichnet, die zur Laufzeit für die Bereitstellung
und Verwaltung der Anwendung benötigt werden, z. B. die Internetprotokoll (IP)-Adresse, Ports
oder Speicherkapazitäten [BBKL14a]. Interfaces beinhalten Funktionen, die auf Instanzen ausge-
führt werden können und in TOSCA als Management Operations bezeichnet werden. Jede Operation
kann über Skripte, die Web Services Description Language (WSDL) oder über Representational
State Transfer (REST) beschrieben werden [SBLB12]. Eine solche Operation wäre zum Beispiel
die install-Operation der Komponente FlinkApp, die in Listing 2.1 in Zeile 15 dargestellt ist. Um
ein Interface zu implementieren, stellt TOSCA [OAS13b] sogenannte Implementation Artifacts
(IAs) zur Verfügung. Diese beschreiben über ein Skript, wie die definierte Management Operation
auszuführen ist und können instanziiert werden, um die Ausführung der Operation zu starten. Die
Implementierung eines spezifischen Node Types wird über ein Deployment Artifact (DA) beschrie-
ben. Ein Node Type kann mehrfach durch unterschiedliche Node Templates instanziiert werden,
dasselbe gilt auch für Relationship Types.
Listing 2.1 Definition eines Node Types in XML
1
2
3
4
5
7
9
10
11
12
13
14
15
16
17
18
19
Darüber hinaus kann das Deployment eines Node Types von anderen Node Types abhängig sein,
die innerhalb der Topologie über sogenannte Requirement Definitions und Capability Definitions
dargestellt werden. So benötigt die FlinkApp in Listing 2.1 beispielsweise das Stream-Verarbeitungs-
Framework Apache Flink, weshalb dieses eine Capability Definition und die FlinkApp in Zeile 5 des
Listings eine Requirement Definition mit dem Namen Flink_Simple-Req definiert. Alle Requirement
182.1 OASIS Standard TOSCA
Definitions sowie Capability Definitions besitzen jeweils einen zugehörigen Requirement Type bzw.
Capability Type, der das Element genauer spezifiziert und ebenfalls mehrfach verwendet werden
kann. Jeder Requirement Type enthält außerdem den Parameter requiredCapabilityType, der ihn mit
dem entsprechenden Capability Type verbindet.
Die Relationship Types definieren analog zu den Node Types unterschiedliche Properties und
Interfaces. Die davon instanziierten Relationship Templates repräsentieren Verbindungen zwischen
mehreren Node Templates, indem sie sowohl den Start- als auch den Zielknoten spezifizieren. So
sind in Abbildung 2.2 die Node Templates FlinkApp und Flink Simple_1.0.3 über das Relationship
Template hostedOn miteinander verbunden, wobei FlinkApp als Startknoten und Flink Simple_1.0.3
als Zielknoten fungiert.
Exemplarisch soll nun die in Kapitel 1 eingeführte Topologie der FlinkApp in TOSCA modelliert
werden, dargestellt in Abbildung 2.2. Zu sehen ist ein vollständiges Service Template basierend
auf der Beispiel-Topologie. Diese besteht aus den fünf zentralen Komponenten FlinkApp, Flink
Simple_1.0.3, Ubuntu_14.04, VSphere_5.5 und Python_2.7. Jede dieser Komponenten repräsentiert
ein Node Template, welches durch Relationship Templates mit anderen Komponenten verbunden
ist. Die Semantik eines jeden Templates wird dabei durch einen zugehörigen Node Type bzw.
Relationship Type definiert. Die Anwendung enthält somit die fünf Node Types FlinkApp, Flink
Simple_1.0.3, Ubuntu_14.04, VSphere_5.5 und Python_2.7 und die beiden Relationship Types
hostedOn und dependsOn.
Abbildung 2.2: Aufbau eines Service Templates in TOSCA
192 Hintergrund und Related Work
Ein weiterer Bestandteil des Service Templates sind sogenannte Management Plans (in Abbil-
dung 2.2 rechts unten dargestellt), welche die Erstellung und Terminierung des Services definieren
[OAS13b]. Die Spezifikation konkretisiert den Aufbau der Management Plans als Workflow-Modell,
wodurch bereits bestehende Workflow-Sprachen wie die Business Process Model and Notation
(BPMN) [OMG11] oder die Business Process Execution Language (BPEL) [OAS07] genutzt werden
können. Eine für TOSCA ausgelegte und auf BPMN basierende Workflow-Sprache mit dem Namen
BPMN4TOSCA wurde 2012 in Kopp et al. [KBBL12] vorgestellt. Ziel war es dabei, ein bestehendes
TOSCA Modell auf ein BPMN Workflow Modell zu übertragen [CCDT17]. Die grafische Modellie-
rung TOSCA-basierter Deployment-Modelle in Verbindung mit Management Plans kann z. B. über
den Visual Editor for TOSCA (VALESCA) [IAA12] durchgeführt werden. Weitere Informationen zu
Management Plans und deren praktische Umsetzung sind in Spatzier et al. [SBLB12] zu finden.
Um den Aspekt der Portabilität zu bewahren und ein erstelltes Service Template auf andere De-
ployment Systeme und Infrastrukturen überführen zu können, bietet TOSCA die Möglichkeit, die
gesamte Anwendung als Cloud Service ARchive (CSAR) zu speichern. Innerhalb dieses Archivs
können sämtliche Informationen standardisiert exportiert und auf jedem anderen Deployment Sys-
tem aufgerufen werden. So enthält ein CSAR Archiv, das wie eine gewöhnliche ZIP-Datei extrahiert
werden kann, alle für das Deployment notwendigen Elemente der Applikation (Modelle, Skripte,
Definitionen, etc.) in einer internen Verzeichnisstruktur. Die Struktur eines exemplarischen CSAR
Archivs anhand der Beispieltopologie FlinkApp ist in Abbildung 2.3 dargestellt.
Abbildung 2.3: Struktur eines Cloud Services Archives (CSAR) in TOSCA
Da alle Komponenten einer Anwendung in TOSCA entweder in XML- oder in YAML-Code
geschrieben werden, gibt es unterschiedliche Werkzeuge, die das Erstellen und Bearbeiten der
TOSCA-Anwendung erleichtern. Meistens geschieht dies durch eine übersichtliche Modellierungs-
oberfläche, die die Komponenten der Anwendung sowie deren Relationen auf anschauliche Art
darstellt. Dort können CSAR-Archive innerhalb einer Laufzeitumgebung importiert, bearbeitet und
anschließend wieder exportiert werden. Eine Übersicht aktueller Deployment Systeme wird im
Abschnitt 2.2 gegeben. Anschließend wird das OpenTOSCA Ecosystem als Beispiel einer solchen
Umgebung in Abschnitt 2.3 vorgestellt und näher betrachtet.
202.2 TOSCA Deployment Systeme
2.2 TOSCA Deployment Systeme
Für die praktische Umsetzung von Topologien bedarf es einer geeigneten Laufzeitumgebung, welche
die TOSCA Spezifikation unterstützt. Eine solche Umgebung wird im Folgenden als Deployment
System bezeichnet und bildet die Grundlage, um bestehende Topologien instanziieren und über
Management Plans verwalten zu können. Beispiele für derzeit existierende Deployment Systeme,
die TOSCA unterstützen, sind OpenTOSCA [BBH+13], TosKer [BRS18], SeaClouds [BCC+16],
Cloudify [Clo20], Brooklyn-TOSCA [CCDP16] oder ARIA TOSCA [The20].
Die meisten dieser Deployment Systeme verwenden Docker [Doc20] für das Deployment und
Management von Cloud-Anwendungen. Dabei werden alle Komponenten der Anwendung sowie
zugehörige Software in Form von Bibliotheken etc. in sogenannte „Docker Container“ verlagert,
die miteinander vernetzt werden können und die Aspekte der Portabilität bei vergleichsweise
geringer Dateigröße unterstützen. In diesem Abschnitt werden die drei TOSCA Deployment Systeme
Cloudify [Clo20], TosKer [BRS18] und die OpenTOSCA Runtime [BBH+13] aufgezeigt und genauer
beschrieben.
Cloudify ist ein Open Source Framework zur Beschreibung, Modellierung und Automatisierung von
Cloud-Anwendungen sowie deren Deployment [Clo20]. Es besitzt einen eigenen Parser, um TOSCA
Service Templates, in Cloudify Blueprints genannt, im YAML-Format einzulesen und auf die
interne Dateistruktur zu übertragen. Dabei beinhaltet ein Blueprint explizit einzelne Workflows, die
den Aufbau der Management Plans in einer der oben beschriebenen Workflowsprachen beschreiben.
Weitere Informationen zu Cloudify und der Nutzung im Kontext der TOSCA Spezifikation [OAS13b]
sind auf der Cloudify Website [Clo20] und in TOSCA 101 - A primer on TOSCA modeling and
concepts (Whitepaper) [Clo18] zu finden.
Ein weiteres Deployment System zur Orchestrierung von TOSCA-basierten Cloud-Anwendungen
ist TosKer [BRS18], dessen Name eine Komposition der Begriffe „TOSCA“ und „Docker“ ist.
TosKer importiert ebenfalls ein in YAML definiertes Service Template, ordnet jede Komponente der
Anwendung in einem eigenen Docker-Container an und führt anschließend die im Service Template
definierten Management Operations auf den einzelnen Komponenten aus. Es unterscheidet sich
jedoch von Cloudify und anderen Deployment Systemen, da es die Orchestrierung der beteiligten
Komponenten unabhängig von den umgebenden Docker Containern erlaubt.
Die OpenTOSCA Runtime [BBH+13] stellt als Teil des OpenTOSCA Ecosystems ebenfalls eine
Laufzeitumgebung für TOSCA Deployment Modelle dar. Sie verwendet anders als die Mehrheit
der bisher genannten Deployment Modelle die Modellierung der Topologien in der Sprache XML.
Der Aufbau des kompletten Ecosystems [BEK+16] inklusive der OpenTOSCA Runtime wird im
folgenden Abschnitt 2.3 detailliert beschrieben.
212 Hintergrund und Related Work
2.3 OpenTOSCA Ecosystem
Das OpenTOSCA Ecosystem [BEK+16] stellt eine auf dem OASIS Standard TOSCA [OAS13b]
basierende Open-Source Laufzeitumgebung zur Verfügung, die aus drei zentralen Komponenten
besteht: Eclipse Winery [KBBL13] (in Abschnitt 2.3.1 näher beschrieben), dem OpenTOSCA-
Container und der sogenannten Vinothek [BBKL14b] (Siehe Abschnitt 2.3.2). Abbildung 2.4 zeigt
schematisch den Aufbau des OpenTOSCA Ecosystems inklusive der drei genannten Komponen-
ten.
Abbildung 2.4: Schematischer Aufbau des OpenTOSCA Ecosystems [Ope]
2.3.1 Eclipse Winery
Eclipse Winery [KBBL13] ist ein im Jahr 2013 veröffentlichtes Werkzeug zum Erstellen und Bear-
beiten von TOSCA-basierten Cloud-Anwendungen. Winery ermöglicht dabei eine ausschließlich
webbasierte Modellierung von TOSCA-Modellen ohne zusätzliche benötigte Software, indem es
alle relevanten Elemente der Spezifikation im eigenen Webbrowser visualisiert. Bereits bestehende
Topologien können entweder über eine entsprechende Funktionalität als CSAR importiert oder
alternativ lokal erstellt werden. Falls erwünscht, kann die gesamte Topologie anschließend zudem
erneut als CSAR exportiert werden.
Die auf Angular1 basierende Benutzeroberfläche von Winery stellt zum einen das bereits beschriebe-
ne grafische Modellierungstool zur Verfügung, mit dessen Hilfe Node Templates als Instanzen von
zuvor definierten Node Types kreiert werden und über Relationship Templates verbunden werden
können. Dabei orientiert sich Winery bei der Darstellung von Topologien an VINO4TOSCA aus
Breitenbücher et al. [BBK+12], Node Types werden als abgerundete Rechtecke und Relations-
hip Templates als Pfeile zwischen Node Templates visualisiert. Abbildung 2.5 zeigt die grafische
Darstellung der definierten Beispiel-Topologie aus Abschnitt 1.2 in Winery.
Neben dem grafischen Modellierungswerkzeug bietet Winery auch einen eigenen Element Ma-
nager [KBBL13], in welchem unter anderem Node Types und Relationship Types sowie weitere
Elemente der Spezifikation gelistet sind. Hier werden sämtliche Definitionsdokumente anschaulich
in unterschiedliche Kategorien gegliedert, wodurch zusätzliche Elemente und Attribute ganz simpel
1 https://angular.io/
222.3 OpenTOSCA Ecosystem
Abbildung 2.5: Darstellung der Beispiel-Topologie in Winery
hinzugefügt oder geändert werden können. Da es bei der manuellen Bearbeitung von XML-Modellen
schnell zu Fehlern kommt, bietet Winery außerdem diverse Überprüfungswerkzeuge an, welche
unter anderem die Eingabe von korrekten Werten oder Fehlermeldungen überwachen.
Winery deckt so durch den Element Manager, der die Semantik und Properties der einzelnen
Elemente verwaltet, die „Type-Schicht“ des zu Beginn in Abbildung 2.1 aufgezeigten Drei-Schichten-
Modells ab. Das grafische Modellierungstool, das die Verknüpfung unterschiedlicher Templates
und Visualisierung als gerichteten Graphen realisiert, repräsentiert die „Template-Schicht“. Die
dritte und letzte „Instanz-Schicht“ übernimmt dann die Vinothek, welche in Abschnitt 2.3.2 genauer
beschrieben wird.
Jedes Element der Topologie wird in Winery separat gespeichert und ist über einen individuellen
Uniform Resource Locator (URL) erreichbar. Hierfür beinhaltet jedes Element ein Attribut target-
Namespace, welches gemeinsam mit dem id-Parameter als URL fungiert und damit innerhalb der
Gesamtstruktur der Topologie lokalisiert und referenziert werden kann. So ermöglichen einfache
Referenzen innerhalb des Dateisystems eine Verknüpfung unterschiedlicher Elemente miteinan-
der, woraus im Vergleich zum Austausch von Dateien eine erhebliche Einsparung der Dateigröße
resultiert. Eine URL am Beispiel des bekannten Node Types FlinkApp mit der id FlinkApp und
dem targetNamespace http://opentosca.org/nodetypes würde also folgendermaßen aussehen:
nodetypes/http%253A%252F%252Fopentosca.org%252Fnodetypes/FlinkApp. Der targetNamespace ist
hier encodiert, da er zusätzliche Slashes enthält, die bei der Referenzierung zu Problemen führen
könnten.
232 Hintergrund und Related Work 2.3.2 OpenTOSCA-Container und Vinothek Nachdem betrachtet wurde, wie Topologien innerhalb der Benutzeroberfläche von Winery erstellt werden können, wird eine entsprechende Umgebung benötigt, die TOSCA-Topologien unterstützt. Das OpenTOSCA-Ecosystem beinhaltet hierfür den „OpenTOSCA-Container“ [BBH+13; BEK+16], der eine solche TOSCA-Laufzeitumgebung repräsentiert, um bereits erstellte Topologien instanziie- ren und über integrierte Management Plans verwalten zu können. Dies geschieht über den Import des bereits in Abschnitt 2.1 aufgeführten Cloud Service ARchive (CSAR), das sämtliche Dateien der Topologie in einer internen Verzeichnisstruktur enthält. Die „Vinothek“ [BBKL14b] stellt ein Tool zur Verfügung, womit die erstellte Anwendung anschließend durch den Nutzer über eine weitere Benutzeroberfläche gestartet werden kann. Der OpenTOSCA-Container stellt eine Laufzeitumgebung für TOSCA zur Verfügung und sorgt dafür, dass das importierte CSAR-Archiv korrekt verarbeitet wird und anschließend über die integrierten Implementation Artifacts und Management Plans als Anwendung aufgesetzt wird. Dabei wird das Archiv zunächst analysiert und dann der integrierte Build Plan aufgerufen, um die Anwendung zu instanziieren. Die Verarbeitung der CSAR kann dabei sowohl imperativ als auch deklarativ erfolgen [BBK+14]. Der OpenTOSCA-Container ist direkt in Winery integriert, wo auch Management Plans für eine Applikation erstellt und bearbeitet werden können. Diese Management Plans ermöglichen anschließend eine Verwaltung der erstellten Applikationsinstanz. Ein weiteres Feature des OpenTOSCA-Containers ist der sogenannte „Plan Generator“ [BBK+14], der Build Plans selbst erzeugen kann, falls diese nicht vorhanden sind. Die Vinothek [BBKL14b] ermöglicht es, bereits aufgesetzte TOSCA Laufzeitumgebungen wie die oben beschriebene OpenTOSCA Runtime über eine einfach gehaltene Benutzeroberfläche steuern zu können. So können Anwendungen unterschiedlicher Laufzeitumgebungen gesammelt im Web- browser aufgelistet, bearbeitet und als eigene Instanzen gestartet werden. Da TOSCA bisher keine standardisierte Laufzeitumgebung definiert, werden unterschiedliche Application Programming Interfaces (APIs) verwendet, deren technische Integration in ein einheitliches Interface die Vinothek koordiniert [BBKL14b]. So kann der Nutzer in der auf HTML5 und Javascript basierenden Webdar- stellung jede importierte Anwendung durch einen simplen Knopfdruck instanziieren, worauf sich eine Instanz der erstellten Applikation in einem weiteren Browserfenster öffnet. Abbildung 2.6 ist aus Breitenbücher et al. [BBKL14b] entnommen und zeigt die Übersichtsseite der Vinothek, die in diesem Fall zwei Anwendungen enthält. 24
2.3 OpenTOSCA Ecosystem
Abbildung 2.6: Darstellung integrierter Cloud-Anwendungen in der Vinothek [BBKL14b]
253 Programmiermodell für TOSCA Topology
Templates in Java
In diesem Kapitel wird ein Programmiermodell für die Modellierung von TOSCA Topology Tem-
plates in der objektorientierten Programmiersprache Java eingeführt. Das Ziel ist dabei, Node
Templates in Java erstellen, parametrisieren und über Relationship Templates miteinander verbinden
zu können. Dafür werden exemplarisch Ausschnitte eines Java-Programms gezeigt, welches die
Erstellung und Konfiguration von Node Templates anhand einer erweiterten Anwendungstopologie
basierend auf der zu Beginn dieser Arbeit eingeführten Beispiel-Topologie darstellt.
Dieses Kapitel gliedert sich in vier Unterabschnitte. Zunächst wird in Abschnitt 3.1 eine Erweiterung
der bekannten Beispiel-Topologie präsentiert und ausführlich beschrieben. Anschließend wird in
Abschnitt 3.2 aufgezeigt, wie Node Templates in Java behandelt werden. Dabei wird explizit
erläutert, wie die Erstellung von Node Templates in Form einer Instanziierung bekannter Node
Types sowie die folgende Bearbeitung und Parametrisierung realisiert wird. Es folgt Abschnitt 3.3,
der die Modellierung von Relationship Templates in Java anhand ausgewählter Beispiele beschreibt.
Abgeschlossen wird dieses Kapitel in Abschnitt 3.4, worin die Umsetzung einer vollständigen
Topologie in Java basierend auf der erweiterten Anwendungstopologie mittels Code-Beispielen
aufgeführt wird.
3.1 Erweiterte Beispiel-Topologie
Die Modellierung von Topology Templates in Java soll anhand eines Anwendungsbeispiels exem-
plarisch aufgezeigt werden. Hierfür wurde die in Kapitel 1 beschriebene Beispiel-Topologie um
eine zusätzliche Komponente inklusive zugehöriger Verbindungen erweitert. Es handelt sich dabei
um eine MySQL1 Datenbank, die über ein connectsTo Relationship Template mit der FlinkApp
und über ein hostedOn Relationship Template mit dem Betriebssystem Ubuntu verbunden ist. Die
bisher noch nicht erläuterte connectsTo-Relation beschreibt den Verbindungsaufbau der FlinkApp
zur Datenbank, um auf zur Darstellung der FlinkApp benötigte Datenspeicher zuzugreifen. Damit
werden die bisherigen, in Wurster et al. [WBB+20] als „vertikal“ definierten Relationen dependsOn
und hostedOn der Beispiel-Topologie um die „horizontale“ Relation connectsTo erweitert. So be-
inhaltet die erweiterte Beispiel-Topologie beide Klassen von Relationship Types und unterstützt
folglich Cloud-Native Deployability wie in Wurster et al. [WBB+20] definiert.
1 https://www.mysql.com/
273 Programmiermodell für TOSCA Topology Templates in Java
Die Topologie umfasst nun insgesamt die sechs Komponenten FlinkApp, die Programmiersprache
Python 2.7, das Stream-Verarbeitungs-Framework Flink Simple Version 1.0.3, das Betriebssystem
Ubuntu 14.04, die virtuelle Maschine von VSphere 5.5 und die neu hinzugefügte Datenbank MySQL.
Alle Komponenten repräsentieren wie oben beschrieben je ein Node Template und sind über die
bekannten Relationship Templates verbunden.
Die vollständige erweiterte Beispiel-Topologie ist in Abbildung 3.1 zu sehen. Auf der Basis die-
ser Topologie wird in den folgenden Abschnitten beschrieben, wie eine Modellierung von Node
Templates und Relationship Templates in Java auszusehen hat.
Abbildung 3.1: Erweiterte Version der Beispiel-Topologie in TOSCA
3.2 Modellierung von Node Templates in Java
In diesem Abschnitt wird beschrieben, wie TOSCA Node Templates in der Programmiersprache Java
objektorientiert umgesetzt werden können. Hierfür wird zunächst betrachtet, welche Eigenschaften
ein Node Template besitzt, um anschließend eine geeignete Darstellungsform aus dem Bereich der
Objektorientierung zu finden, über die das Node Template in Java modelliert werden kann. Wie
bereits in Kapitel 2 beschrieben, besitzt jedes Node Template einen zugehörigen Node Type, aus
welchem mehrere Node Templates zugleich instanziiert werden können. Diese spezifizieren den Node
Type, indem weitere Eigenschaften und Parameter innerhalb des Node Templates festgelegt werden
[OAS13b]. Eine solche Eigenschaft wäre z. B. die Anzahl, wie oft ein Node aus dem vorliegenden
Node Template instanziiert werden darf. Außerdem können Node Templates unter Verwendung von
Relationship Templates miteinander verbunden werden und so Relationen spezifizieren.
283.2 Modellierung von Node Templates in Java
Nun soll betrachtet werden, wie die Kreierung von Node Templates in Java umgesetzt werden kann.
Das Listing 3.1 veranschaulicht die im weiteren Verlauf beschriebenen Konzepte exemplarisch
anhand der erweiterten Beispiel-Topologie aus Abschnitt 3.1. In Java können Instanzen aus bereits
bestehenden Klassen einfach über den new-Operator erstellt und anschließend als sogenannte Java-
Objekte weiterverwendet werden. Hätte man folglich eine Repräsentation der TOSCA Node Types
in Form von Java-Klassen, so könnte man daraus Objekte erstellen, die ein Node Template abbilden.
Im folgenden Kapitel 4 wird explizit erläutert, wie Node Types in Klassen der objektorientierten
Programmiersprache Java transformiert werden können. Diese Transformation wird automatisch
unter Berücksichtigung diverser Transformationsregeln durchgeführt und bildet damit die Grundlage,
um Node Templates in Java als Objekte instanziieren zu können.
Listing 3.1 Instanziierung und Parametrisierung eines Node Templates anhand der Beispiel-
Topologie in Java
1 public class FlinkAppTopology {
2 public void createTopology() {
3 // Instanziiere die Komponente FlinkApp
4 FlinkApp flinkApp = new FlinkApp();
5
6 // Lege Parameter Id fest
7 flinkApp.setId("FlinkApp");
8
9 // Rufe die drei Operationen der FlinkApp nacheinander auf
10 flinkApp.configure();
11 flinkApp.install();
12 flinkApp.start();
13
14 // Instanziiere die Komponente Flink Simple
15 Flink_Simple_1_0_3 flinkSimple = new Flink_Simple_1_0_3();
16 // Deployment der FlinkApp auf einer Instanz von FlinkSimple
17 flinkApp.deployOn(flinkSimple);
18 ...
19
20 }
21 }
Das Listing 3.1 zeigt in Zeile 4, wie eine solche Instanziierung des Node Templates flinkApp über den
zugehörigen Node Type aussehen könnte. Dabei wird das Node Template streng genommen nicht
direkt aus dem Node Type instanziiert, sondern aus einer Erweiterung der Node Type Klasse, die
sämtliche Parameter und Methoden des Node Types beinhaltet und gleichzeitig alle Eigenschaften
des Node Templates erbt (Siehe Kapitel 4). Nachdem die Komponente instanziiert wurde, können
Parameter wie name oder id über entsprechende set-Methoden festgelegt werden. In Zeile 7 des
Listings wird zum Beispiel die Id des instanziierten Objekts der FlinkApp benannt. Auf Objekten
können zudem implementierte Methoden aufgerufen werden, die durch die Interfaces bzw. die
enthaltenen Management Operations im Node Type festgelegt werden. So besitzt beispielsweise der
Node Type FlinkApp die Operation install zur Installation der Komponente. Diese und die beiden
weiteren Operationen configure und start werden nacheinander als Methodenaufrufe in den Zeilen
10 bis 12 ausgeführt. Zur Veranschaulichung und Vereinfachung sind hier keine Input-/Output-
Parameter dargestellt, die jedoch entsprechend der Operation ebenfalls erforderlich wären.
293 Programmiermodell für TOSCA Topology Templates in Java
Die praktische Umsetzung der Requirements und Capabilities ist ein weiterer zentraler Aspekt,
der in Java betrachtet werden muss. Um das Deployment einer Komponente zu steuern und dabei
die definierten Requirement Definitions der Node Types zu berücksichtigen, kann die Methode
deployOn eines Node Templates aufgerufen werden. Diese benötigt als Input-Parameter die Instanz
der Komponente, die das Hosting übernimmt. Aus der anfangs definierten Beispiel-Topologie geht
hervor, dass die FlinkApp auf dem Stream-Framework Apache Flink Simple Version 1.0.3 aufgesetzt
wird, welches in Zeile 15 instanziiert wird. Die Realisierung des Deployments ist in Zeile 14 von
Listing 3.2 über den Aufruf der deployOn-Methode mit dem inkludierten Node Template flinkSimple
als Input dargestellt.
Final sollen Instanzen außerdem über Relationship Templates mit anderen Komponenten verknüpft
werden. Dafür bedarf es der Entwicklung eines Konzepts, auf welche Art TOSCA Relationship
Templates auf die objektorientierte Programmiersprache Java abgebildet werden können. Die
Vorstellung dieses Konzepts sowie die Frage, wie Relationship Templates in der Folge in Java
modelliert werden können, wird im folgenden Abschnitt 3.3 detailliert behandelt.
3.3 Modellierung von Relationship Templates in Java
Dieser Abschnitt umfasst die Darstellung von Relationship Templates in Java. Zunächst soll auch hier
nochmals die Struktur von Relationship Templates betrachtet werden, um die Form der Abbildung
etwaiger Parameter und Eigenschaften auf Java bestimmen zu können. Wie das Node Template
besitzt jedes Relationship Template einen zugehörigen Relationship Type, welcher die Semantik
der Verbindung und deren Eigenschaften genauer spezifiziert. Diese Verbindung mehrerer Node
Templates mitsamt ihrer Richtung wird im Relationship Template mithilfe eines Source Elements
sowie eines Target Elements festgelegt [OAS13b].
Um Relationship Templates nun in Java modellieren zu können, bedarf es einer anderen Kon-
vertierung als zuvor bei den Node Templates. Während Node Templates als Instanzen von Node
Types Java-Objekte repräsentieren, ist eine Instanziierung aus Relationship Types bei Relationship
Templates nicht sinnvoll. Relationship Templates verbinden mehrere Node Templates miteinander
und sollten deshalb innerhalb eines Node Templates mit anderen verknüpft werden können. Wäre
ein Relationship Template hier ebenfalls ein Objekt, müsste es über eine weitere Funktion mit
beiden Node Templates verbunden werden. Dies wäre überaus umständlich und benötigt zudem die
Implementierung weiterer Funktionen. Besser wäre eine direkte Implementierung innerhalb des
zugehörigen Node Templates. Somit wäre eine praktische Umsetzung von Relationship Templates
in Form eines Methodenaufrufs innerhalb des Node Templates wünschenswert.
Das Listing 3.2 zeigt eine mögliche Implementierung eines Relationship Templates in Java anhand
der Beispiel-Topologie aus Abschnitt 3.1. Die Komponente FlinkApp ist dort über eine connectsTo-
Relation mit der MySQL Datenbank verbunden. Diese Relation soll nun auf Java übertragen werden,
indem zunächst das Node Template FlinkApp instanziiert (Zeile 4) und anschließend über den
Methodenaufruf connectToDatabase(MySQL object){} in Zeile 10 eine Verbindung zur Datenbank
aufnimmt. Diese MySQL Datenbank muss zuvor ebenfalls instanziiert werden, was in Zeile 7
geschieht.
303.4 Praktische Umsetzung der Beispiel-Topologie in Java
Listing 3.2 Implementierung eines Relationship Templates in Java
1 public class Main {
2 public static void main(String[] args) {
3 // Instanziiere die Komponente FlinkApp
4 FlinkApp flinkApp = new FlinkApp();
5
6 // Instanziiere die MySQL-Datenbank
7 MySQL mySQL = new MySQL();
8
9 // Verbinde die FlinkApp mit der Datenbank
10 flinkApp.connectToDatabase(mySQL);
11
12 // Instanziiere die Komponente Python 2.7
13 Python_2_7 python = new Python_2_7();
14
15 // Füge die Abhängigkeit von Python hinzu
16 flinkApp.addDependency(python);
17 ...
18
19 }
20 }
Nach diesem Schema ist nun auch die Implementierung von Relationship Templates in Java möglich
und kann in Kombination mit der in Abschnitt 3.2 aufgezeigten Umsetzung der Node Templates
dazu verwendet werden, ganze TOSCA Topology Templates objektorientiert in Java zu modellieren.
Die Implementierung eines vollständigen Topology Templates in Java anhand der erweiterten
Beispiel-Topologie aus Abschnitt 3.1 wird im folgenden Abschnitt 3.4 beschrieben.
3.4 Praktische Umsetzung der Beispiel-Topologie in Java
Listing 3.3 zeigt die Erstellung und Parametrisierung der erweiterten FlinkApp-Topologie aus
Abschnitt 3.1 in der Programmiersprache Java. Die Anwendung FlinkApp besitzt die sechs zentralen
Komponenten FlinkApp, Flink Simple_1.0.3, Ubuntu_14.04, VSphere_5.5, MySQL und Python_2.7.
Jede dieser Komponenten wird durch ein Node Template repräsentiert, das zunächst aus einem
zugehörigen Node Type instanziiert werden muss. Dies geschieht im Java-Code in den Zeilen 4-9.
Anschließend werden sämtliche Relationship Templates sowie Requirements und Capabilities in
Form von Methodenaufrufen der entsprechenden Node Templates in den Zeilen 11 bis 24 abgebildet.
Beispielsweise realisiert die FlinkApp das Relationship Template dependsOn über die Methode
addDependency(Object object){} in Zeile 14 und baut eine Verbindung zur MySQL Datenbank auf,
die in Zeile 16 dargestellt ist.
So kann Schritt für Schritt die gesamte Topologie in Java modelliert werden. Auch weitere Metho-
den sowie zusätzliche Parameter der einzelnen Objekte sind möglich, werden hier zur besseren
Übersichtlichkeit jedoch nicht aufgeführt. Voraussetzung für die Modellierung von TOSCA To-
pology Templates in Java ist immer eine korrekte Transformation der TOSCA Node Types, um
daraus die zur Spezifizierung der Topology Templates notwendigen Node Templates instanziieren zu
313 Programmiermodell für TOSCA Topology Templates in Java
Listing 3.3 Modellierung eines vollständigen Topology Templates in Java
1 public class Main {
2 public static void main(String[] args) {
3 // Instanziiere alle sechs Komponenten
4 FlinkApp flinkApp = new FlinkApp();
5 Flink_Simple_1_0_3 flinkSimple = new Flink_Simple_1_0_3();
6 Python_2_7 python = new Python_2_7();
7 Ubuntu_14_04_VM ubuntuVM = new Ubuntu_14_04_VM();
8 MySQL mySQL = new MySQL();
9 VSphere_5_5 vSphere = new VSphere_5_5();
10
11 // Deployment der FlinkApp auf FlinkSimple
12 flinkApp.deployOn(flinkSimple);
13 // Relationship "dependsOn" zwischen FlinkApp und Python_2.7
14 flinkApp.addDependency(python);
15 // Relationship "connectsTo" zwischen FlinkApp und MySQL Datenbank
16 flinkApp.connectToDatabase(mySQL);
17
18 // Deployment von Python, MySQL und Flink Simple auf der Ubuntu VM
19 python.deployOn(ubuntuVM);
20 mySQL.deployOn(ubuntuVM);
21 flinkSimple.deployOn(ubuntuVM);
22
23 // Deployment der Ubuntu VM auf VSphere
24 ubuntuVM.deployOn(vSphere);
25 ... // Weitere Parametrisierung und Methodenaufrufe zulässig
26 }
27 }
können. Die praktische Vorgehensweise einer automatisierten Transformation in ein gleichwertiges
Java-Klassenformat mittels ausgewählter Werkzeuge und Algorithmen wird im folgenden Kapitel 4
ausführlich beschrieben.
324 Transformation von TOSCA Typen in Java Klassen
In diesem Kapitel soll ein Überblick über das Konzept dieser Arbeit gegeben werden, indem ein
erster Lösungsansatz für die praktische Transformation von TOSCA Node Types in Java Klassen
präsentiert wird. Dieser beinhaltet den selbst erstellten „TOSCA2JAVA-Transformator“, der die
Konvertierung von TOSCA-basierten Topologien bis zu den endgültigen Java-Klassen koordiniert.
Hierfür werden sich auch Grundlagen aus bereits bestehenden Systemen wie das beschriebene Tool
Winery [KBBL13] oder die OpenTOSCA Runtime [BBH+13] (Abschnitt 2.3) zunutze gemacht.
Explizit wird in diesem Kapitel aufgezeigt, wie die zur Instanziierung von Node Templates notwen-
digen Node Types in Java modelliert werden können. Damit wird die Grundlage für die im vorigen
Kapitel 3 beschriebene Modellierung von TOSCA Topology Templates gelegt.
Ein Überblick über die Vorgehensweise der Konvertierung vorhandener TOSCA-Modelle in ein
Java-Format bis hin zur endgültigen Ausgabe der Node Types in Java-Klassen ist in Abbildung 4.1
dargestellt. Die Verarbeitung der Modelle geschieht über ein eigens erstelltes Tool, im Folgenden
TOSCA2JAVA-Transformator genannt, dessen Arbeitsweise sich auf drei wesentliche Schritte be-
schränken lässt. Node Types werden zu Beginn in das Programm eingelesen, sämtliche Properties
sowie Interfaces extrahiert und mittels eines Parsers auf das im vorigen Kapitel 4 vorgestellte
Programmiermodell in Java übertragen. Diese bilden unter Berücksichtigung entsprechender Regu-
larien, die in den Transformationsregeln in Abschnitt 4.2 detailliert benannt werden, die Grundlage
für die finale Java-Klasse. Der letzte Schritt des TOSCA2JAVA-Transformators umfasst dann den
Export der kreierten Objekte in ein standardisiertes Java-Klassenmodell und wird in Abschnitt 4.3
beschrieben.
Abbildung 4.1: Ausführliche Ansicht der Übersicht des Konzepts inklusive TOSCA2JAVA-
Transformator
334 Transformation von TOSCA Typen in Java Klassen 4.1 TOSCA Import Zunächst wird die standardkonforme Spezifikation (TOSCA [OAS13b]) in Java überführt, indem sämtliche Bausteine auf entsprechende Typen in Java übertragen werden. Hierfür werden das Ausgangs- und das Zielformat verglichen, um Strukturähnlichkeiten beider Sprachen erkennen und für die Transformation nutzen zu können. Für diese Transformation wird ein sogenannter Parser benötigt, um eine korrekte Konvertierung der vorhandenen Bausteine zu garantieren. Sowohl das Service Template, das als Hauptkomponente des Topology Templates alle Node sowie Relationship Templates definiert, als auch die einzelnen Node Types liegen in der Extensible Markup Language (XML) vor, weshalb eine Programmschnittstelle verwendet wird, die jegliche vorhandene XML- Struktur auf eine Java-Klassenstruktur abbildet. Dieser Parser überträgt standardkonforme TOSCA-Modelle auf bereits definierte Java-Klassen und erstellt direkt ein Objekt dieser Klasse, das anschließend für die Erstellung der entsprechenden Export-Klassen verwendet wird. Hierfür wird die „Java Architecture for XML Binding (JAXB)“ [Sun06] genutzt, die als Bibliothek in das bestehende Programm integriert wird und das TOSCA- Modell über spezielle Marshall-Operationen in die jeweilige Klasse überführt. Für die Verwendung von JAXB ist es zunächst erforderlich, jedes Element der TOSCA-Spezifikation [OAS13b] auf eine eigene Java-Klasse abzubilden, die denselben Namen trägt und damit das entsprechende Element repräsentiert. Dabei werden sämtliche Parameter jedes TOSCA-Elements auf den zugehörigen Java-Typ übertragen, der in XML deklariert ist. Anschließend werden get- und set-Methoden für jeden Parameter erstellt und alle für die Erstellung der Node Type Klassen relevanten Parameter identifiziert, um diese dann im Quellcode über bereitgestellte JAXB-Befehle [Sun06] mit der korrekten Markierung des Typs zu versehen. Die Markierung geschieht über die Annotationen @XmlElement und @XmlAttribute sowie der Basismarkierung @XmlRootElement. Daher wird im Folgenden auch zwischen dem eigentlichen Element, das in XML immer in Großbuchstaben geschrieben wird, und dem Attribut (in XML klein geschrieben) unterschieden. Außerdem wird bei der Konvertierung von Aufzählungen mehrerer Elemente die Annotation @XmlElementWrapper verwendet, um diese auf eine Liste in Java abzu- bilden. Da jedes XML-Element in Java eine weitere Klasse repräsentiert, muss diese bereits in der Verzeichnisstruktur erstellt sein und entsprechend per Import referenziert werden. Nachdem nun definiert wurde, wie Elemente und Attribute in Java zu markieren sind, wird exempla- risch eine solche Klasse aus dem Quellcode des TOSCA2JAVA-Transformators in Listing 4.1 aufge- zeigt. Es ist ein reduzierter Ausschnitt der Node Type Klasse inklusive diverser XML-Annotationen zu sehen, wobei weitere Elemente zur besseren Übersichtlichkeit entfernt wurden. In den Zeilen 1-6 werden sämtliche Imports durchgeführt, die für die Darstellung der Klasse notwendig sind. Hier ist direkt ersichtlich, dass neben den in Zeile 6 importierten XML-Annotationen auch weitere Elemente der TOSCA-Spezifikation [OAS13b] wie die Capability Definition oder die Requirement Definition inkludiert werden. Dazu muss zuvor eine Klasse für das jeweilige Element analog zu der in Listing 4.1 gezeigten Klasse erstellt und ebenfalls mit Annotationen versehen werden. Da auch diese Klassen noch undefinierte Elemente beinhalten können, wird die Markierung rekursiv weitergeführt, bis alle enthaltenen Parameter markiert wurden. 34
4.1 TOSCA Import
Listing 4.1 XML-Annotationen der Attribute und Elemente im TOSCA2JAVA-Transformator
1 import java.util.List;
2
3 import definitions.CapabilityDefinition;
4 import definitions.RequirementDefinition;
5
6 import javax.xml.bind.annotation.*;
7
8 @XmlRootElement(name = "NodeType")
9 public class NodeType {
10 String name;
11 List requirementDefinitions;
12 List capabilityDefinitions;
13 ...
14
15 public String getName() {return this.name;}
16
17 @XmlAttribute(name = "name")
18 public void setName(String name) {this.name = name;}
19
20 private List getRequirementDefinitions()
21 {
22 return this.requirementDefinitions;
23 }
24
25 @XmlElementWrapper(name = "RequirementDefinitions")
26 @XmlElement(name = "RequirementDefinition")
27 private void setRequirementDefinitions(List requirementDefinitions)
28 {
29 this.requirementDefinitions = requirementDefinitions;
30 }
31 ...
32 }
Jede Markierung ist nach dem folgenden Schema aufgebaut:
@XmlTYPE(name = ”NameOfType”), wobei TYPE durch den zugehörigen Typ ersetzt wird.
Es wird dabei zwischen einem Attribute (siehe Zeile 17), einem Element (siehe Zeile 26), einem
RootElement (siehe Zeile 8) und einem ElementWrapper (siehe Zeile 25) unterschieden. Der name-
Parameter muss mit dem abgebildeten XML-Element in der korrekten Schreibweise übereinstimmen,
wobei Groß- und Kleinschreibung relevant ist. So werden nach und nach alle Klassen der Spezi-
fikation auf Java übertragen und markiert, sodass im nächsten Schritt ein Objekt dieser Klasse
speziell für jeden Node Type der Topologie instanziiert werden kann. Wie die Instanziierung und
Parametrisierung eines solchen Objekts in Java aussieht, ist im Kapitel 3 ausführlich dargestellt.
Nun, da der TOSCA Node Type mittels JAXB auf eine entsprechende Java-Klasse abgebildet wurde,
müssen sämtliche enthaltene Elemente wie Listen oder TOSCA-spezifische Elemente wie Operations
in die objektorientierte Struktur von Java überführt werden. So besitzt ein Node Type unter anderem
35Sie können auch lesen
