Verwaltung und Austausch von Cloud-Diensten: Rollen, Architektur, Design und Implementierung

Größe: px
Ab Seite anzeigen:

Download "Verwaltung und Austausch von Cloud-Diensten: Rollen, Architektur, Design und Implementierung"

Transkript

1 Bereitstellung, Verwaltung und Vermarktung von portablen Cloud-Diensten mit garantierter Sicherheit und Compliance während des gesamten Lebenszyklus Verwaltung und Austausch von Cloud-Diensten: Rollen, Architektur, Design und Implementierung Version 2.0 (Auszug der OpenTOSCA betreffenden Inhalte)

2 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 Inhalt 1 Einleitung Inhalt Verfeinerung der CloudCycle-Gesamtarchitektur (AP-302) Beschreibung von Cloud-Diensten mittels TOSCA Interpretation und Ausführung von TOSCA Modellen CloudCycle-Laufzeitumgebung Anforderungen an die Implementierung von CloudCycle-Laufzeitumgebungen CloudCycle-Ökosystem und CloudCycle-Gesamtarchitektur Kommunikationsbeziehungen der Komponenten im Ökosystem Integration der CloudCycle-Laufzeitumgebung in die Gesamtarchitektur Verfeinerung des CloudCycle Rollenmodells (AP-301) Neue Rollen auf Basis erweiterter existierender Rollen Zusätzliche TOSCA-Container bezogene Rollen Die Rolle des Kunden Anforderungsanalyse an die Architektur der TOSCA-Laufzeitumgebung Struktur der Anwendungsfälle Anwendungsfälle für die TOSCA-Laufzeitumgebung TOSCA-Lösungspaket installieren TOSCA-Lösungspaket deinstallieren TOSCA-Laufzeitumgebung installieren TOSCA-Laufzeitumgebung konfigurieren TOSCA-Laufzeitumgebung deinstallieren TOSCA-Laufzeitumgebung starten TOSCA-Laufzeitumgebung herunterfahren TOSCA-Laufzeitumgebung Plugin installieren TOSCA-Laufzeitumgebung Plugin konfigurieren TOSCA-Laufzeitumgebung Plugin deinstallieren Dienstinstanz starten Dienstinstanz verwalten Dienstinstanz terminieren Open Source TOSCA-Container OpenTOSCA (Universität Stuttgart) Architektur Komponenten der Architektur Externe Schnittstellen und APIs Erweiterbarkeit des Containers Grobdesign Datenspeicher Entwurf, Feindesign und Implementierung Arbeitsweise des Containers Fazit und Ausblick Referenzen

3 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE 1 Einleitung Das vorliegende Dokument basiert auf den in Arbeitskomplex AK-100 und AK-200 durchgeführten Analysen, Rollenkonzepten, Architektur- und Ökosystemgedanken und erweitert diese in Hinblick auf die Integration einer CloudCycle-Laufzeitumgebung zum Management von Cloud-Diensten, deren Instanzen und Sicherheitsanforderungen. Aus den erarbeiteten Verfeinerungen der CloudCycle-Gesamtarchitektur, Rollen und erarbeiteten Anwendungsfällen werden detaillierte Systemarchitekturen der OpenSource CloudCycle-Laufzeitumgebung vorgestellt. Diese Systemarchitektur wird in nachfolgenden Arbeitskomplexen im Projekt implementiert. Daher stellt dieses Dokument nicht nur die finale erweiterte Gesamtarchitektur des CloudCycle Projekts dar, sondern spezifiziert auch die letztendlichen Implementierungen der im Projekt einzusetzenden Laufzeitumgebung und deren Integration mit bestehenden Managementsystemen der Cloud-Betreiber. Das vorliegende Dokument ist die zweite aktualisierte Version und enthält verschiedene kleinere Anpassungen basierend auf den Erfahrungen und Arbeiten im Projekt, wie in AP-321 Pflege von Architekur- und Designdokumentation aus Erkenntnissen der Pilotstudie vorgesehen. Dieses Dokument enthält damit den endgültigen konzeptionellen Stand des Arbeitskomplexes AK-300 und der beiden TOSCA Laufzeitumgebungen im Rahmen des Projektes CloudCycle. 1.1 Inhalt Das vorliegende Dokument gliedert sich in die folgenden Kapitel: Kapitel 2 beschreibt, wie die CloudCycle-Gesamtarchitektur verfeinert werden muss, um die CloudCycle- Laufzeitumgebung in die Architektur zu integrieren. Kapitel 3 erweitert das in [CC-Ökosystem] definierte Rollenmodell in Hinblick auf die Integration der CloudCycle- Laufzeitumgebung in die Gesamtarchitektur. Kapitel 4 beschreibt 13 Anwendungsfälle, welche an die CloudCycle-Laufzeitumgebung gerichtet sind um diese in die Cloud-Managementsysteme des Cloud-Betreibers zu integrieren. Kapitel 5 beschreiben die beiden Architekturen der CloudCycle-Laufzeitumgebungen, welche im CloudCycle-Projekt entwickelt und implementiert werden. Die Architekturen basieren dabei auf den Erkenntnissen vorangegangener Kapitel und beziehen so die Rollen, Anwendungsfälle und die verfeinerte Gesamtarchitektur bei der Entwicklung mit ein. Kapitel 6 fasst die Ergebnisse zusammen und gibt einen kurzen Ausblick auf die weitere Vorgehensweise, bei der die Möglichkeiten, die die speziellen Eigenschaften der Architekturen und des CloudCycle-Ökosystems bieten, genutzt werden sollen. 2

4 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 2 Verfeinerung der CloudCycle-Gesamtarchitektur (AP-302) In diesem Abschnitt wird die CloudCycle-Gesamtarchitektur wie in [CC-Ökosystem] beschrieben basierend, auf dem CloudCycle-Ökosystem verfeinert. Der Fokus dieses Dokuments liegt dabei auf der Einbettung der CloudCycle- Laufzeitumgebung zum Management von portablen Cloud-Diensten in die Gesamtarchitektur und deren Auswirkungen, welche durch Anwendungsfälle (Use Cases) in späteren Kapiteln dokumentiert werden. In diesem Kapitel werden die CloudCycle-Laufzeitumgebung und deren Integration in die CloudCycle-Gesamtarchitektur beschrieben, sowie Rollen, Akteure und Use Cases abgeleitet bzw. verfeinert. Viele der Anforderungen an eine CloudCycle Laufzeitumgebung ergeben sich aus Konzepten und Vorgaben der OASIS Topology and Orchestration Specification for Cloud Applications (kurz TOSCA), welche als standardisiertes Austauschformat für Cloud-Dienste dem Projekt CloudCycle zugrunde liegt. Um die sich daraus ergebenden Anforderungen besser zu verstehen, wird deshalb in Abschnitt 2.1 zunächst ein Überblick über TOSCA Konzepte gegeben. Im Folgenden werden dann Anforderungen an eine CloudCycle Laufzeitumgebung abgeleitet. 2.1 Beschreibung von Cloud-Diensten mittels TOSCA TOSCA ermöglicht die standardisierte Beschreibung von Cloud-Diensten sowohl bezüglich der Struktur von Anwendungen, d. h. ihrer Bestandteile in Form von Komponenten und deren Relationen untereinander, als auch durch sog. Management-Pläne, welche detaillierte Managementprozesse für verschiedene Anwendungsfälle beschreiben. TOSCA Beschreibungen beinhalten somit detailliertes Wissen über den strukturellen und konzeptionellen Aufbau einer Cloud-Anwendung und bieten zusätzlich die Möglichkeit, technisches und nutzerbezogenes Expertenwissen in Form von Plänen zu hinterlegen. Komplette Lösungen können mit Hilfe von TOSCA als in sich abgeschlossene Archive (Cloud Service Archive, CSAR) paketiert werden, welche sowohl Modellbeschreibungen der Anwendung als auch sämtliche zur Instanziierung und zum Management der Anwendung erforderlichen Artefakte enthalten (siehe Abbildung 1). Abbildung 1: TOSCA Cloud Service Archive Die Beschreibung eines Cloud-Dienstes bzw. der zur Verfügung gestellten Anwendung erfolgt in Form eines Service Templates, welches die strukturelle Beschreibung der Anwendung (Topology Template) sowie Management-Pläne (Plans) enthält. Bausteine für die Modellierung einer Anwendung, d. h. mögliche Komponenten und mögliche Beziehungen zwischen Komponenten, werden durch Node Types und Relationship Types beschrieben. Beide definieren Attribute, die durch eine TOSCA-Laufzeitumgebung konfigurierbar sein sollen (z.b. Die IP-Adresse sein, unter der ein Web Server erreichbar ist, könnte solch ein Attribut sein), sowie Managementoperationen, die von einer TOSCA- Laufzeitumgebung aufgerufen werden können, um bestimmte Managementaktionen (z. B. das Starten oder Stoppen von Komponenten) zu ermöglichen. Ein wichtiger Aspekt von TOSCA ist, dass Artefakte, welche die eben genannten Managementoperation implementieren (sog. Implementation Artifacts) als Teil einer Lösung paketiert werden und Node- oder Relationship Types auf diese Artefakte verweisen können. Weiterhin können Artefakte, 3

5 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE welche für die Instanziierung der jeweiligen Komponenten einer Anwendung nötig sind (z. B. Installationspakete, Laufzeitbibliotheken, Virtual Machine Images) als sog. Deployment Artifacts innerhalb eines CSAR enthalten sein. Für eine TOSCA Laufzeitumgebung ergibt sich somit die Anforderung, diese Erweiterungskonzepte der TOSCA- Spezifikation (d. h. Definition neuer Node- und Relationship Types sowie verschiedener Typen von Artefakten) entsprechend zu unterstützen Interpretation und Ausführung von TOSCA Modellen Im Laufe der TOSCA-Standardisierung haben sich zwei grundlegende Varianten herauskristallisiert, über welche TO- SCA Modelle prozessiert werden können: die deklarative Verarbeitung und die imperative Verarbeitung. Bei der deklarativen Verarbeitung werden bestimmte Anwendungsfälle wie z. B. die Instanziierung oder die Terminierung eines Cloud-Dienstes einzig und allein aus der strukturellen Beschreibung des Dienstes abgeleitet. Für diese Art der Bearbeitung ist eine genau definierte Semantik von Komponenten und Beziehungen zwischen Komponenten notwendig, um sicherzugehen, dass unterschiedliche TOSCA Umgebungen gleiche Abfolgen von Managementaktionen basierend auf der Topologie einer Anwendung ableiten. Zum Beispiel kann aus dem Fakt, dass eine Komponente von einer anderen Komponente abhängig ist, abgeleitet werden, in welcher Reihenfolge Komponenten instanziiert werden müssen. Bei der imperativen Verarbeitung werden sämtliche Anwendungsfälle durch die Ausführung von Management- Plänen realisiert, wobei die genaue Abfolge von auszuführenden Managementaktionen explizit in Plänen (z. B. in Form von BPMN Prozessmodellen) vorgeben ist. Dieser Ansatz hat eine weniger starke Abhängigkeit auf die Definition der Semantik von Komponenten oder Beziehungen, sondern verlässt sich auf die Korrektheit der typischerweise von Experten erstellten Management-Pläne. Neben einer strikten Trennung beider Ansätze ist ebenfalls ein hybrider Ansatz möglich, bei dem zum Beispiel manche Anwendungsfälle, wie das Instanziieren einer Anwendung, mittels des deklarativen Ansatzes und andere Anwendungsfälle, wie das Erstellen ein Backups während der Laufzeit eines Dienstes mittels des imperativen Ansatzes implementiert werden. 2.2 CloudCycle-Laufzeitumgebung Die CloudCycle-Laufzeitumgebung (auch TOSCA-Container bzw. TOSCA-Laufzeitumgebung genannt) ermöglicht voll automatisiertes und portables Management von Cloud-Diensten über deren gesamten Lebenszyklus hinweg. Die Technologie basiert dabei TOSCA, welche die Definition von Cloud-Applikationen und deren Management ermöglicht. Die CloudCycle-Laufzeitumgebung ermöglicht somit, basierend auf der TOSCA-Spezifikation das Management von Cloud-Diensten, welche in TOSCA beschrieben werden. Da in TOSCA Standardisierung und Portabilität speziell unterstützt wird, ermöglicht die Implementierung einer CloudCycle-Laufzeitumgebung basierend auf TOSCA die Austauschbarkeit der Applikationen selbst und deren Management zwischen verschiedenen Cloud-Betreibern und auch zwischen verschiedenen TOSCA Laufzeitumgebungen, da der Standard die angesprochene Portabilität ausdrücklich ermöglicht. Im Folgenden wird beschrieben, wie die CloudCycle-Laufzeitumgebung in die Gesamtarchitektur integriert werden kann und wie dabei verschiedene Implementierungen der Laufzeitumgebung zusammenwirken. CloudCycle-Laufzeitumgebungen implementieren den TOSCA-Standard und sorgen so für Portabilität von Cloud- Diensten zwischen verschiedenen Implementierungen. In CloudCycle werden zwei verschiedene CloudCycle- Laufzeitumgebungen implementiert: Eine kommerzielle Variante und eine Open Source Variante. Ziel von CloudCycle ist es, die beiden Implementierungen so dicht an der standardisierten TOSCA-Spezifikation zu halten, dass Applikationen auf beiden Umgebungen ausführbar und somit portabel sind. Im folgenden Abschnitt werden vier Anforderungen beschrieben, die an eine TOSCA-standardkonforme Implementierung einer CloudCycle-Laufzeitumgebung erhoben werden. Diese dienen als Grundlage für die Portabilität von Cloud-Diensten und der Interoperabilität zwischen den verschiedenen Umgebungen Anforderungen an die Implementierung von CloudCycle-Laufzeitumgebungen An eine korrekte Implementierung einer CloudCycle-Laufzeitumgebung wird eine Reihe von Anforderungen gestellt, um die Ziele des TOSCA Standards insbesondere Portabilität von Cloud-Diensten und Interoperabilität zwischen verschiedenen TOSCA-Laufzeitumgebungen zu erfüllen. Im Folgenden werden diese Anforderungen vorgestellt und im Detail diskutiert. 4

6 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 Anforderung 1: TOSCA Spezifikationstreue und Interoperabilität. Um Interoperabilität zwischen verschiedenen CloudCycle-Laufzeitumgebungen zu gewährleisten, müssen diese den TOSCA-Standard gemäß der Definitionen, Schnittstellen und Konzepte der Spezifikation implementieren. Dabei ist vor allem auf Portabilitätsanforderungen der Spezifikation zu achten, welche beispielsweise die Interaktionsmöglichkeiten von Plänen mit der Laufzeitumgebung spezifizieren. Anforderung 2: Erweiterbarkeit. Eine korrekte CloudCycle-Laufzeitumgebungsimplementierung muss bezüglich individueller Applikationstopologien erweiterbar sein. Dadurch sollen verschiedenste Cloud-Dienste modelliert und verwaltet werden können. Es wird gefordert, dass individuelle Komponenten in den Topologien verwendet werden können, beispielsweise beliebige Betriebssysteme oder Web Server. Dafür muss die Laufzeitumgebung Mechanismen anbieten, um individuelle Komponenten in Topologien integrieren und verarbeiten zu können. Anforderung 3: Lose Kopplung. Die Implementierung der Laufzeitumgebung muss auf lose gekoppelten Systemkomponenten basieren, sodass diese im Idealfall vom Cloud-Betreiber individuell ausgetauscht werden können. Ein Beispiel hierfür ist die Komponente zur Ausführung von Management-Plänen: Möchte ein Cloud-Betreiber nur spezielle Plan-Sprachen, wie z. B. BPMN 2.0, zulassen, muss das entsprechende Prozessmanagementsystem in die Laufzeitumgebung integriert werden können. Anforderung 4: Multi-Mandantenfähigkeit. CloudCycle-Laufzeitumgebungen müssen multi-mandantenfähig sein, um bei der Integration in die Cloud-Managementsysteme der Cloud-Betreiber verschiedene Kunden mit entsprechenden unterschiedlichen Sicherheitsmechanismen (z. B. Isolation) gleichzeitig bedienen zu können. Die Multi- Mandantenfähigkeit zielt dabei auf die Granularität der Lösungspakete pro Kunde ab. Die Architektur der in diesem Dokument vorgestellten Open Source CloudCycle-Laufzeitumgebung (Kapitel 5) erfüllt die genannten Anforderungen. 2.3 CloudCycle-Ökosystem und CloudCycle-Gesamtarchitektur In diesem Abschnitt werden das CloudCycle-Ökosystem und die CloudCycle-Gesamtarchitektur beschrieben. Basierend darauf werden diese in den nächsten Kapiteln verfeinert. Abbildung 2 zeigt das CloudCycle-Ökosystem wie in [CC-Ökosystem] beschrieben. Die CloudCycle-Gesamtarchitektur beschreibt dabei einen speziellen Teil dieses Ökosystems, welcher beim Cloud- Betreiber die Architektur der für CloudCycle wesentlichen Cloud Management Komponenten und Aspekte widerspiegelt, in welche die Laufzeitumgebung integriert wird. Die Gesamtarchitektur ist somit in das gesamte Ökosystem eingebettet und detailliert die nötigen Komponenten und Abhängigkeiten, welche zur Erfüllung der CloudCycle-Ziele benötigt werden alle anderen Komponenten wie z. B. Marktplatz sind dabei ohne Relevanz und finden sich deshalb in dieser Architektur nur in Form von Schnittstellen wieder. Da die beiden zu entwickelnden Laufzeitumgebungen konzeptionell ähnlich in die Cloud Management Schicht des Cloud-Betreibers eingebettet werden können, spiegelt die Gesamtarchitektur die abstrakten Gemeinsamkeiten der beiden Laufzeitumgebungen wider und beschreibt deren Integration. Das CloudCycle-Ökosystem unterscheidet zwischen den nachfolgend beschriebenen Akteuren und Komponenten sowie ihren jeweiligen Aufgaben. Abbildung 2 zeigt die Akteure und Komponenten in einem an UML angelehnten Diagramm. Akteure und Komponenten sind jeweils als Stereotype einer Klasse dargestellt (<<actor>>, <<component>>). Gemäß UML spezifiziert ein Akteur eine Rolle, die von Personen, Organisationen oder Systemen angenommen werden kann. Eine Komponente stellt gemäß UML einen modularen Teil eines Systems dar, der selbst wiederum andere Komponenten kapseln kann. Akteure und Komponenten können als abstrakte Klasse deklariert sein, von denen keine Instanzen angelegt werden können (gekennzeichnet durch die Eigenschaft {abstract}). Dies dient zum einen der Strukturierung von Klassen und zum anderen der Vereinfachung. Beispielsweise kann vereinfachend der Begriff Kunde verwendet werden, wenn eine Unterscheidung zwischen Diensteigentümer und 5

7 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE Dienstnutzer nicht erforderlich ist [CC-Ökosystem]. Im Folgenden werden die drei Komponenten Cloud-Betreiber, Service-Orchestration und Service-Management zum besseren Verständnis aus [CC-Ökosystem] zitiert. Abbildung 2: CloudCycle-Ökosystem Akteure und Komponenten Cloud-Betreiber. Der Cloud-Betreiber kann typischerweise ein großes oder mittelständiges Unternehmen sein, das Cloud-Dienste anbietet, d. h. über die entsprechende Cloud-Technologie und über ein geeignetes Rechenzentrum verfügt. Hierbei kann es sich um Dienste auf allen Service-Modell-Ebenen handeln. Der Cloud-Betreiber kann über eine Pricing Komponente Angebote für konkrete Dienstinstanzen veröffentlichen. Zusätzlich kann er diese Angebote auch in die vom Marktplatzbetreiber verwaltete globale Pricing Komponente eintragen. Eine Komponente zum Service-Management läuft beim Cloud-Betreiber, über die IT-Ressourcen verwaltet werden können. Aufgabe des Cloud-Betreibers ist, für die Verfügbarkeit der von den Diensten benötigten Ressourcen (Software- und Hardware) zu sorgen. Der Cloud-Betreiber wiederum kann selbst Cloud-Dienste von anderen Cloud-Betreibern, die als Unterauftragnehmer fungieren, nutzen. Hierbei kann es sich sowohl um Dienste auf anderen Service-Modell-Ebenen (z. B. PaaS, IaaS) handeln, auf denen er seine eigenen Dienste aufsetzt, als auch um Dienste, die er nutzt, um daraus eine Aggregation von Diensten durchzuführen. Voraussetzung ist, dass das Sicherheitsniveau, welches diese anderen Cloud-Betreiber bieten, feststellbar ist und das Sicherheitsniveau für die verwalteten Dienste gehalten werden kann. Service-Management. Mit Hilfe des Service-Managements werden Lösungspakete, Dienste und Dienstinstanzen organisatorisch, technisch und kaufmännisch verwaltet. In diesem Dokument liegt der Schwerpunkt auf den technischen Aspekten. Das Service-Management ist dabei für die Administration der verfügbaren Dienste und deren Instanzen verantwortlich. Sie bietet unterschiedliche Sicherheitsniveaus für die Laufzeitumgebung von Cloud-Diensten und deren Instanzen. Die Service-Orchestration wertet die festgelegte Sicherheitsrichtlinie aus und setzt diese um, indem sie die Laufzeitumgebung des Cloud-Dienstes 6

8 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 entsprechend konfiguriert. Darin enthalten ist auch das Self-Service Portal welches es den Kunden ermöglicht, Lösungspakete zu installieren und ihre Dienstinstanzen zu verwalten (Kaufen und Abrechnen, Starten und Stoppen, Anlegen von Backups usw.). 2.4 Kommunikationsbeziehungen der Komponenten im Ökosystem Im Folgenden werden die Beziehungen zwischen den Akteuren des CloudCycle-Ökosystems beschrieben, welche für die Verfeinerung der CloudCycle-Gesamtarchitektur und der beteiligten Rollen benötigt werden. Dabei liegt der Fokus auf den Kommunikationsbeziehungen, über die Cloud-Applikationen übertragen und verwaltet werden (Kommunikationsbeziehungen, siehe Abbildung 3). Abbildung 3: Kommunikationsbeziehungen zwischen den Akteuren Die nachfolgenden Kommunikationsbeziehungen betreffen jeweils den Cloud-Betreiber und seine direkte Peripherie, da in diesem Dokument speziell der Cloud-Betreiber und die Einbettung der CloudCycle-Laufzeitumgebung im Fokus stehen. Die direkten Kommunikationskomponenten sind dabei der Marktplatzbetreiber, der Kunde und der Lösungsanbieter, da diese dem Cloud-Betreiber die Cloud-Applikationen überliefern. Cloud-Betreiber - Marktplatzbetreiber. Der Cloud-Betreiber sucht im Dienstverzeichnis des Marktplatzbetreibers nach Lösungspaketen. Er kann ein gefundenes Lösungspaket direkt beim Marktplatzbetreiber erwerben. Zudem kann der Cloud-Betreiber ein Angebot für Dienstinstanzen abgeben, welches dann in der globalen Pricing Komponente des Marktplatzbetreibers veröffentlicht wird. 7

9 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE Cloud-Betreiber - Kunde. Der Kunde kann über die lokale Pricing Komponente des Cloud-Betreibers nach Angeboten für Dienstinstanzen suchen. Der Kunde kann Dienstinstanzen kaufen, administrieren und nutzen. Weiterhin kann er die Installation eines Lösungspaketes beauftragen. In diesem Fall überträgt er das Lösungspaket zu dem Cloud-Betreiber. Cloud-Betreiber - Lösungsanbieter. Der Cloud-Betreiber kann die Entwicklung eines Cloud-Dienstes (Lösungspaket) beim Lösungsanbieter beauftragen oder ein fertiges Lösungspaket direkt einkaufen. 2.5 Integration der CloudCycle-Laufzeitumgebung in die Gesamtarchitektur In diesem Kapitel wird die Integration der CloudCycle-Laufzeitumgebung in die Gesamtarchitektur des CloudCycle- Ökosystems beschrieben und die Auswirkungen verschiedener Implementierungen der Laufzeitumgebung untersucht. Die CloudCycle-Laufzeitumgebung wird in Form eines TOSCA-Containers realisiert, welcher das Management von Cloud-Diensten, welche in TOSCA definiert sind, automatisiert. Der TOSCA-Container wird dabei beim Cloud- Betreiber installiert und übernimmt Aufgaben zum Service-Management und Orchestrierung. Die CloudCycle-Laufzeitumgebung (im Folgenden TOSCA-Laufzeitumgebung genannt) stellt funktional Teile der beiden rot markierten Bereiche in Abbildung 2 zur Verfügung: Verwaltung der Dienste (Service-Management) und Verwaltung deren Instanzen (Cloud-Services). Cloud-Dienste werden basierend auf TOSCA in einem austauschbaren, portablen Format definiert und stellen somit portable Lösungspakete (siehe Abbildung 2, Komponente Lösungspaket ) dar, welche von Marktplatz, Kunde und Cloud-Betreiber als abgeschlossene Einheit gesehen und gehandelt werden können. Diese TOSCA-basierten Lösungspakete werden im Folgenden TOSCA-Lösungspaket genannt. TO- SCA-Lösungspakete beinhalten gemäß der Konzeption von TOSCA nicht nur die Applikationsstruktur und zugehörige Software-Artefakte, sondern auch Pläne, die das Management realisieren. Durch die Portabilität von TOSCA- Lösungspaketen zwischen verschiedenen TOSCA-Laufzeitumgebungen wird die Portabilität auf das Management der Applikation vererbt. Dies ermöglicht den Austausch von Cloud-Diensten zwischen verschiedenen Implementierungen einer TOSCA-Laufzeitumgebung inklusive all ihrer Management-Funktionalitäten. Dadurch können verschiedene Cloud-Betreiber basierend auf diesen Funktionalitäten die Applikation als Dienst ihren Kunden anbieten und auf diesen operieren, ohne dabei spezielles technisches Wissen über die Applikation und deren Management zu benötigen. Durch die standardisierte Beschreibung der TOSCA-Lösungspakete und deren Management können Dienste und Dienstinstanzen verwaltet werden. Die TOSCA-Laufzeitumgebung ist somit für das Installieren und De-Installieren eines Cloud-Dienstes (siehe Abbildung 2, Komponente Dienst ) verantwortlich und ermöglicht dies voll automatisiert. Das instanziieren einer Dienstinstanz (siehe Abbildung 2, Komponente Dienstinstanz ) des installierten Dienstes wird von Management-Plänen übernommen, welche im TOSCA-Lösungspaket applikationsspezifisch enthalten sind. Durch die Kombination dieser beiden Funktionalitäten wird die Self-Service -Komponente in Abbildung 2 realisiert: Marktplatz, Kunde oder Cloud-Betreiber selbst nutzen Schnittstellen (siehe nächsten Absatz) um einen Dienst zu installieren und anschließend Management-Pläne um den Dienst zu instanziieren und zu verwalten bzw. operieren. Welche Funktionen der Cloud-Betreiber dabei dem Marktplatz und dem Endnutzer bzw. Endkunden direkt zur Verfügung stellt und welche Funktionen er durch diese eigenen Schnittstellen nach außen kapselt, ist betreiberspezifisch und nicht Bestandteil dieses Dokuments. Speziell die Preisgestaltung und Bezahlmethoden sind dabei sehr Cloud-Betreiber spezifisch und benötigen weitere Integrationsmechanismen mit den vorhandenen Systemen und der TOSCA-Laufzeitumgebung. 8

10 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 Cloud-Services <<component>> Service-Management <<component>> Dienstinstanz <<component>> Lösungspaket <<component>> Selfservice <<component>> Dienst <<component>> Pricing <<component>> TOSCA Laufzeitumgebung <<component>> + Abbildung 4: Verfeinerung des Cloud Betreibers Die resultierende Verfeinerung der CloudCycle-Gesamtarchitektur besteht somit zum einen Teil aus der Integration der TOSCA-Laufzeitumgebung in die Rolle des Cloud-Betreibers wo sie die beiden Komponenten Cloud-Services und Service-Management technisch umsetzt. Die Integration wird in Abbildung 4 veranschaulicht: Die TOSCA- Laufzeitumgebung wird unter Cloud-Services und Service-Management dargestellt und ist für das Verwalten der Dienst- und Dienstinstanz-Komponenten verantwortlich (Integration symbolisiert durch das grüne Plus-Symbol). Wie in vorherigen Abschnitten beschrieben, ist das Self-Service-Management und zugehörige Rechte für Marktplatz und Endnutzer bzw. Endkunde Cloud-Betreiber spezifisch, somit greift die Self-Service-Komponente auf die TOSCA- Laufzeitumgebung zu und steuert diese basierend auf den Anforderungen und Implementierungen des Cloud- Betreibers. 9

11 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE 3 Verfeinerung des CloudCycle Rollenmodells (AP-301) In diesem Kapitel werden die Rollen aus AK-100 und AK-200 verwendet, um ein verfeinertes Rollenmodell basierend auf der verfeinerten CloudCycle-Gesamtarchitektur aus Kapitel 2 zu entwickeln, welches anschließend als Grundlage für die Anwendungsfälle an die CloudCycle-Laufzeitumgebung und deren Integration dient. Die Rollen werden dabei auf die verfeinerte Systemsicht aus den vorherigen Kapiteln angewendet, welche aus der Integration der TOSCAbasierten CloudCycle-Laufzeitumgebung (im Folgenden wieder TOSCA-Laufzeitumgebung genannt) in die Gesamtarchitektur bzw. das Ökosystem entstanden ist. Die in AK-100 und AK-200 entwickelten Rollen, Akteure und Komponenten werden dabei im Kern erhalten und um feingranulare Rollen bezüglich der Integration von TOSCA und der CloudCycle-Laufzeitumgebung erweitert. In den folgenden Definitionen werden folgende zwei Begriffe verwendet: TOSCA-Lösungspakete sind Lösungspakete, welche Cloud-Dienste basierend auf TOSCA implementieren und TOSCA- Cloud-Dienste sind Cloud-Dienste, welche durch ein TOSCA-Lösungspaket bereitgestellt werden. 3.1 Neue Rollen auf Basis erweiterter existierender Rollen In diesem Kapitel werden neue Rollen beschrieben, die auf anderen Rollen basieren und diese erweitern. Sie ergänzen das bisherige Rollenmodell um TOSCA-basierte Aspekte und stehen zusätzlich zu den bereits existierenden Rollen zur Verfügung. TOSCA-Enabled-Lösungspaket-Hersteller. Der TOSCA-Enabled-Lösungspaket-Hersteller ist ein Akteur, der aus der Software, die der Software-Hersteller implementiert hat, einen TOSCA-Cloud-Dienst erstellt. D. h., er erzeugt das TOSCA-Lösungspaket, welches den Dienst formal beschreibt und die Software enthält. Er basiert auf der Rolle des Lösungspaket-Hersteller und erweitert diesen um TOSCA-Konzepte. Ob der Hersteller auf TOSCA-Dienste spezialisiert ist und diese ausschließlich anbietet oder gemeinsam mit anderen Cloud-Diensten, ist individuell und wird durch die Definition nicht eingeschränkt. TOSCA-Enabled-Lösungsanbieter. Der TOSCA-Enabled-Lösungsanbieter erweitert die Rolle des Lösungsanbieters um TOSCA-basierte Cloud-Dienste. Diese Dienste werden in Form von TOSCA-Lösungspaketen vertrieben. Das TOSCA- Lösungspaket bietet der TOSCA-Lösungsanbieter wahlweise Interessenten 1 direkt an oder er kann es von einem TOSCA-Enabled-Marktplatzbetreiber vertreiben lassen. Hierzu erstellt er ein TOSCA-Lösungsangebot, das aus einer Beschreibung des Dienstes, des vorgegebenen Rahmens für das Sicherheitsniveau und den Leistungsumfang, sowie der Angabe der Nutzungsbedingungen für den Dienst besteht. Wählt ein Interessent ein Angebot aus, erhält er das TOSCA-Lösungspaket, das im Anschluss bei einem Cloud-Betreiber installiert werden muss. Ob der Hersteller auf TOSCA-Lösungspakete spezialisiert ist und diese ausschließlich anbietet oder gemeinsam mit anderen Lösungspaketen, ist individuell und wird durch die Definition nicht eingeschränkt. TOSCA-Enabled-Marktplatzbetreiber. Die Rolle des TOSCA-Enabled-Marktplatzbetreibers basiert auf der des Marktplatzbetreibers und erweitert diesen um TOSCA-basierte Angebote. Er bietet innerhalb des CloudCycle- Ökosystems einen speziellen Dienst, einen TOSCA-Enabled-Marktplatz 2, an und bietet Interessenten über ein Dienstverzeichnis zusätzlich zu anderen Cloud-Lösungen die zur Verfügung stehenden TOSCA-basierten Cloud- Lösungen an (TOSCA-Lösungspakete). Das letztendliche Angebot ist spezifisch für individuelle Marktplatzbetreiber und liegt außerhalb des Rahmens von CloudCycle. Für TOSCA-basierte Lösungspakete nutzt der TOSCA-Enabled- Marktplatzbetreiber die in Kapitel 2.5 eingeführte Marktplatz Schnittstelle um über diese mit dem Cloud- Betreiber zu interagieren. Die restliche Definition entspricht der des Marktplatzbetreibers. TOSCA-Enabled-Cloud-Betreiber. Die Definition des TOSCA-Enabled-Cloud-Betreibers basiert auf der Definition des Cloud-Providers und erweitert diese um den Einsatz von TOSCA-basierten Cloud-Diensten. Die TOSCA-basierten Cloud-Dienste kann der TOSCA-Enabled-Cloud-Betreiber in Form von TOSCA-Lösungspaketen über den TOSCA- Marktplatz oder direkt bei einem TOSCA-Lösungsanbieter einkaufen. Alternativ können Kunden des TOSCA-Enabled- Cloud-Betreibers auch ihre eigenen TOSCA-Lösungspakete in einer dafür vom TOSCA-Enabled-Cloud-Betreiber für den Kunden bereitgestellten Umgebung installieren. 1 Bei den Interessenten kann es sich sowohl um Kunden als auch um Cloud-Betreiber handeln. 2 D. h. der Marktplatz selbst kann auch ein Cloud-Dienst sein, der von einem Cloud-Betreiber angeboten wird. 10

12 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 TOSCA-Enabled-Mehrwertdienstleister. Der TOSCA-Enabled-Mehrwertdienstleister erweitert die Rolle des Mehrwertdienstleister um TOSCA-bezogene Komponenten wie Security-Plugins, welche die TOSCA-Laufzeitumgebung erweitern, modifizieren oder konfigurieren können. Zusätzlich können diese Art Mehrwertdienstleister Komponenten für die Modellierung von TOSCA-basierten Lösungspaketen bereitstellen, welche den Cloud-Dienst selbst erweitern können. 3.2 Zusätzliche TOSCA-Container bezogene Rollen In diesem Kapitel werden die neuen Rollen eingeführt, welche das bisherige verfeinerte Rollenmodell in Bezug auf die TOSCA-Laufzeitumgebung erweitern: TOSCA-Container-Administrator und TOSCA-Container-Hersteller. TOSCA-Container-Administrator. Der TOSCA-Container-Administrator ist eine neue Rolle, welche für die Administration und Konfiguration einer TOSCA-Laufzeitumgebung beim Cloud-Betreiber verantwortlich ist. Die Rolle kann entweder von einem Mitarbeiter des Cloud-Betreibers übernommen werden oder durch externe auf TOSCA spezialisierte Firmen zur Verfügung gestellt werden. Der Administrator ist vor allem für die Konfiguration und Sicherung der Security Mechanismen in der Laufzeitumgebung verantwortlich. Die TOSCA-Laufzeitumgebung ist gemäß den oben erhobenen Anforderungen erweiterbar. Diese Erweiterungen durch z. B. Plugins werden vom TOSCA- Container-Administrator organisiert, durchgeführt, auf Korrektheit überprüft und überwacht. Die Rolle ist ausdrücklich nur für Aufgaben an der TOSCA-Laufzeitumgebung verantwortlich; nicht für die Administration oder andere Aufgaben bezüglich von Cloud-Diensten oder Lösungspaketen. TOSCA-Container-Hersteller. Die Rolle des TOSCA-Container-Herstellers ist für die Entwicklung einer TOSCA- Laufzeitumgebung auf Basis der TOSCA-Spezifikation zuständig. Der Container-Hersteller darf dabei jede andere Rolle des Rollenmodels gleichzeitig übernehmen. So können Cloud-Betreiber eigene TOSCA-Container gemäß der Spezifikation entwickeln, die besonders auf die vorhandene Infrastruktur optimiert sind und somit für den Cloud- Betreiber die bestmögliche Variante darstellen. In CloudCycle übernehmen zwei Projektpartner die Rolle des TO- SCA-Container-Herstellers, wodurch eine kommerzielle Version und eine Open Source Variante implementiert werden. 3.3 Die Rolle des Kunden Die Rolle des Kunden wird bei der Verfeinerung und Erweiterung des Rollenmodells speziell untersucht. Die Einführung der TOSCA-Technologie in das CloudCycle-Ökosystem hat zu den beiden zusätzlichen Rollen TOSCA-Enabled- Cloud-Betreiber und TOSCA-Enabled-Marktplatzbetreiber geführt. Da der Kunde mit diesen beiden Rollen interagieren kann, könnte man die Rolle eines TOSCA-Enabled-Kunde einführen. Da TOSCA-Lösungspakete abgeschlossene Einheiten sind, die maschinell verarbeitet werden können, ist es im Rollenmodell nicht vorgesehen, dass dem Kunden die Technologie bewusst ist. Somit ist für den Kunden nicht von Bedeutung, um welche Art Lösungspaket es sich beim Handel und Kauf mit Lösungspaketen handelt. Ein Kunde kann ein TOSCA-Lösungspaket bei einem TOSCA-Marktplatz kaufen und verändern. Dieses veränderte Lösungspaket kann nun bei einem TOSCA-Enabled-Cloud-Betreiber installiert werden, um dadurch nutzerspezifische Cloud-Dienste zu realisieren, bei denen der Kunde direkte funktionale oder nicht-funktionale Änderungen am Dienst selbst tätigt. In diesem Fall übernimmt der Kunde bewusst oder unbewusst zusätzlich die Rolle des TOSCA-Enabled- Lösungspaket-Herstellers. 11

13 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE 4 Anforderungsanalyse an die Architektur der TOSCA-Laufzeitumgebung Da die Integration der TOSCA-Laufzeitumgebung in das Cloud-Management System des Cloud-Betreibers der zentrale Ansatzpunkt der verfeinerten CloudCycle-Gesamtarchitektur darstellt, werden in diesem Kapitel Anwendungsfälle an die TOSCA-Laufzeitumgebung analysiert, definiert und erklärt. 4.1 Struktur der Anwendungsfälle In diesem Unterkapitel wird die Struktur der Anwendungsfälle definiert und erklärt. Jeder Anwendungsfall hat einen Namen, der den Fall identifiziert. Das Ziel beschreibt, was durch den Anwendungsfall erreicht werden soll. Jeder Anwendungsfall betrifft einen oder mehrere Akteure, welche die beteiligten Rollen am Fall beschreiben. Die Vorbedingungen geben Konditionen und Bedingungen an, die erfüllt sein müssen, dass der Anwendungsfall angewendet werden kann. Sind diese Vorbedingungen nicht erfüllt, ist der Anwendungsfall nicht valide und darf nicht angewendet werden. Die Vorbedingungen stellen möglicherweise Bedingungen an vorhergehende Anwendungsfälle, beispielsweise dass ein System erst installiert sein muss, bevor der Anwendungsfall System starten angewendet werden darf. Nachbedingungen geben den Zustand des Systems bzw. der beteiligten Komponenten an, wenn der Normalablauf des Anwendungsfalls korrekt und ohne Fehler durchgeführt wurde. Sind beim Normalablauf, welcher die einzelnen Schritte des Anwendungsfalls beschreibt, Fehler aufgetreten, gelten die spezifizierten Nachbedingungen nicht mehr oder nur noch teilweise. Anwendungsfälle können Fehlerbehandlung und Unregelmäßigkeiten in einem separat spezifizierten Ablauf bei Fehlerfall dokumentieren, um Fehlerbehandlung explizit zu definieren. 4.2 Anwendungsfälle für die TOSCA-Laufzeitumgebung Die nachfolgenden Unterkapitel beschreiben die Anwendungsfälle für die TOSCA-Laufzeitumgebung im Detail. Die Anwendungsfälle beziehen sich nicht auf das gesamte CloudCycle-Ökosystem, da die zentrale Architekturkomponente, welche zur Erfüllung der CloudCycle-Ziele benötigt wird, ausschließlich die TOSCA-Laufzeitumgebung und deren Plugin-Mechanismen darstellt. Das vollständige CloudCycle-Ökosystem bildet jedoch zusätzliche Komponenten und Interaktionen ab, die nicht im Projekt behandelt werden und somit auch nicht in diesem Dokument diskutiert werden (z. B. Der Marktplatz zum Handeln von Cloud-Diensten). Das Ergebnis dieses Kapitels ist eine Reihe von Anwendungsfällen, die von der TOSCA-Laufzeitumgebung und deren Integration in die Cloud-Managementsysteme der Cloud-Betreiber abgedeckt werden müssen. Die beschriebenen Funktionalitäten werden anschließend als Basis für die Entwicklung der beiden TOSCA- Laufzeitumgebungsarchitekturen verwendet und berücksichtigt. 12

14 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 Abbildung 5: Anwendungsfalldiagramm mit beteiligten Akteuren Abbildung 5 zeigt einen Überblick über die 13 Anwendungsfälle und den beteiligten Akteuren. Die Farbgebung der Anwendungsfälle zeigt die logische Zusammengehörigkeit einzelner Anwendungsfälle und soll zur besseren Übersicht dienen. Alle folgenden Anwendungsfälle sind Grundlage für die Implementierung einer minimalen TOSCA- Laufzeitumgebung TOSCA-Lösungspaket installieren Name Ziel TOSCA-Lösungspaket installieren Dieser Anwendungsfall beschreibt die Installation eines TOSCA-Lösungspakets auf die TOSCA-Laufzeitumgebung. Nach der Installation kann der Dienst, welcher durch das Lösungspaket beschrieben wird, über die TOSCA- Laufzeitumgebung instanziiert werden und dem Endkunden zur Verfügung gestellt werden. Der beteiligte Akteur ist dabei der TOSCA-Enabled-Cloud-Betreiber. Gemäß dem CloudCycle-Ökosystem können zwar auch TOSCA-Enabled- Marktplatzbetreiber und der Kunde ein Lösungspaket beim Cloud-Betreiber installieren, dieser Anwendungsfall beschreibt jedoch nur die direkte Interaktion mit der TOSCA-Laufzeitumgebung. Da der Cloud-Betreiber die Kommuni- 13

15 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE Akteure kationsschnittstelle der Laufzeitumgebung nicht direkt dem Kunden bzw. Marktplatz anbieten sollte, wird die Schnittstelle durch Cloud-Betreiber spezifische Komponenten gekapselt, welche die Laufzeitumgebung mit den Management Systemen des Cloud-Betreibers integriert. Somit ist nur der TOSCA- Enabled-Cloud-Betreiber durch diese kapselnden Komponenten der direkte Akteur, Kunde und Marktplatz nur indirekt. TOSCA-Enabled-Cloud-Betreiber (TECB) Vorbedingungen Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß installiert Die TOSCA-Laufzeitumgebung ist so konfiguriert, dass sie alle genutzten Plugins des TOSCA-Lösungspakets unterstützt (z. B. die verwendete Plansprache) Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß gestartet (siehe Anwendungsfall TOSCA-Laufzeitumgebung starten ) Die im Lösungspaket verwendeten Systeme zum Management des Dienstes sind verfügbar Nachbedingungen Das TOSCA-Lösungspaket wurde ordnungsgemäß in die TOSCA- Laufzeitumgebung installiert (bei der Installation sind keine Fehler aufgetreten) Der durch das TOSCA-Lösungspaket beschriebene Dienst kann nun instanziiert werden (siehe Anwendungsfall Dienstinstanz instanziieren ) Normalablauf 1. Der TOSCA-Enabled-Cloud-Betreiber (oder eine kapselnde Komponente seines Cloud Management Systems) ruft die Installationsmethode an der Kommunikationsschnittstelle der TOSCA-Laufzeitumgebung auf und übergibt ein TOSCA-Lösungspaket und die zugehörigen Meta-Informationen, die zur Installation benötigt werden 2. Nachdem das Lösungspaket übergeben wurde, installiert die TOSCA- Laufzeitumgebung vollautomatisch den Dienst 3. Nach der Installation erscheint der Dienst in der Management Oberfläche der TOSCA-Laufzeitumgebung und kann vom TECB (oder einer kapselnden Komponente) in Dienstinstanzen instanziiert werden. Die Zuordnung von Kundeninformationen und Dienstinstanz ist dabei Aufgabe des TECB bzw. seines Management Systems und liegt daher außerhalb dieses Anwendungsfalls Ablauf im Fehlerfall 1. Der TOSCA-Enabled-Cloud-Betreiber (oder eine kapselnde Komponente seines Cloud Management Systems) ruft die Installationsmethode an der Kommunikationsschnittstelle der TOSCA-Laufzeitumgebung auf und übergibt ein TOSCA-Lösungspaket und die zugehörigen Meta-Informationen, die zur Installation benötigt werden 2. Nachdem das Lösungspaket übergeben wurde, installiert die TOSCA- Laufzeitumgebung vollautomatisch den Dienst 3. Bei der Installation des TOSCA-Lösungspakets tritt ein Fehler auf 4. Das Lösungspaket wird nicht installiert und alle bereits installierten Komponenten werden deinstalliert und der Zustand der Laufzeitumgebung zurückgesetzt auf den Standpunkt vor der Installation 14

16 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version TOSCA-Lösungspaket deinstallieren Name TOSCA-Lösungspaket deinstallieren Ziel Dieser Anwendungsfall beschreibt die Deinstallation eines TOSCA- Lösungspakets auf der TOSCA-Laufzeitumgebung. Nach der Deinstallation kann der Dienst, welcher durch das Lösungspaket beschrieben wird, nicht mehr über die TOSCA-Laufzeitumgebung instanziiert werden. Akteure Der beteiligte Akteur ist dabei der TOSCA-Enabled-Cloud-Betreiber. Gemäß dem CloudCycle-Ökosystem können zwar auch TOSCA-Enabled- Marktplatzbetreiber und der Kunde ein Lösungspaket beim Cloud-Betreiber deinstallieren, dieser Anwendungsfall beschreibt jedoch nur die direkte Interaktion mit der TOSCA-Laufzeitumgebung. Da der Cloud-Betreiber die Kommunikationsschnittstelle der Laufzeitumgebung nicht direkt dem Kunden bzw. Marktplatz anbieten sollte, wird die Schnittstelle durch Cloud-Betreiber spezifische Komponenten gekapselt, welche die Laufzeitumgebung mit den Management Systemen des Cloud-Betreibers integriert. Somit ist nur der TO- SCA-Enabled-Cloud-Betreiber durch diese kapselnden Komponenten der direkte Akteur, Kunde und Marktplatz nur indirekt. TOSCA-Enabled-Cloud-Betreiber (TECB) Vorbedingungen Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß installiert Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß gestartet (siehe Anwendungsfall TOSCA-Laufzeitumgebung starten ) Alle Dienstinstanzen basierend auf dem zu deinstallierenden TOSCA- Lösungspakets sind beendet Es existiert keine Instanz des Dienstes mehr, andernfalls kann dieser Use Case nicht angewendet werden. Dies muss durch das System verhindert werden. Nachbedingungen Das TOSCA-Lösungspaket wurde ordnungsgemäß aus der TOSCA- Laufzeitumgebung deinstalliert (bei der Deinstallation sind keine Fehler aufgetreten) Alle Laufzeitdaten des Dienstes und zugehöriger Instanzen sind vom System entfernt worden Der durch das TOSCA-Lösungspaket beschriebene Dienst kann nun nicht mehr instanziiert werden (siehe Anwendungsfall Dienstinstanz instanziieren ) Normalablauf 1. Der TOSCA-Enabled-Cloud-Betreiber (oder eine kapselnde Komponente seines Cloud Management Systems) ruft die Deinstallationsmethode an der Kommunikationsschnittstelle der TOSCA-Laufzeitumgebung auf und referenziert das zu deinstallierende TOSCA-Lösungspaket 2. Nachdem das Lösungspaket spezifiziert wurde, deinstalliert die TOSCA- Laufzeitumgebung vollautomatisch den Dienst 3. Nach der Deinstallation erscheint der Dienst nicht mehr in der Management Oberfläche der TOSCA-Laufzeitumgebung und kann nun nicht mehr in Dienstinstanzen instanziiert werden. 15

17 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE Ablauf im Fehlerfall 1. Der TOSCA-Enabled-Cloud-Betreiber (oder eine kapselnde Komponente seines Cloud Management Systems) ruft die Deinstallationsmethode an der Kommunikationsschnittstelle der TOSCA-Laufzeitumgebung auf und referenziert das zu deinstallierende TOSCA-Lösungspaket 2. Nachdem das Lösungspaket spezifiziert wurde, tritt bei der Deinstallation ein Fehler auf 3. Der TOSCA-Container-Admin wird beauftragt, die Fehlerursache zu untersuchen und gegebenenfalls den Dienst von Hand zu deinstallieren TOSCA-Laufzeitumgebung installieren Name TOSCA-Laufzeitumgebung installieren Ziel Akteure Dieser Anwendungsfall beschreibt, wie die TOSCA-Laufzeitumgebung ordnungsgemäß installiert wird um anschließend für die Installation von TOSCA- Lösungspaketen und Instanziierung von Dienstinstanzen zur Verfügung zu stehen TOSCA-Container-Administrator (TCA) Vorbedingungen Der TOSCA-Enabled-Cloud-Betreiber stellt alle nötigen Infrastruktursysteme, welche für die Installation der TOSCA-Laufzeitumgebung benötigt werden, zur Verfügung Nachbedingungen Die TOSCA-Laufzeitumgebung ist installiert und kann anschließend für die Installation von TOSCA-Lösungspaketen und Instanziierung von Dienstinstanzen benutzt werden Normalablauf 1. Der TOSCA-Container-Administrator installiert alle Komponenten der TOSCA- Laufzeitumgebung und konfiguriert sie 2. Der TOSCA-Container-Administrator installiert nötige Plugins, die ihm vom TOSCA-Enabled-Cloud-Betreiber vorgegeben werden 3. Die TOSCA-Laufzeitumgebung ist installiert TOSCA-Laufzeitumgebung konfigurieren Name TOSCA-Laufzeitumgebung konfigurieren Ziel Akteure Dieser Anwendungsfall beschreibt, wie die TOSCA-Laufzeitumgebung konfiguriert werden kann. Beispiele für Konfiguration sind die Auswahl der Systemkomponenten, z. B. verschiedene Datenspeicher zum Ablegen der Lösungspakete, oder die Konfiguration der grafischen Oberfläche der TOSCA- Laufzeitumgebung TOSCA-Container-Administrator (TCA) Vorbedingungen Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß installiert Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß gestartet (siehe Anwendungsfall TOSCA-Laufzeitumgebung starten ) Nachbedingungen Die neue Konfiguration der TOSCA-Laufzeitumgebung wurde übernommen 16

18 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 Normalablauf 1. Der TOSCA-Container-Administrator konfiguriert die TOSCA- Laufzeitumgebung über die Konfigurationsschnittstelle des Systems 2. Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß konfiguriert und das System nimmt die neue Konfiguration an und setzt diese um TOSCA-Laufzeitumgebung deinstallieren Name Ziel TOSCA-Laufzeitumgebung deinstallieren Dieser Anwendungsfall beschreibt, wie die TOSCA-Laufzeitumgebung ordnungsgemäß deinstalliert wird Akteure TOSCA-Container-Administrator (TCA) Vorbedingungen Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß installiert Alle Dienste und Dienstinstanzen wurden deinstalliert / terminiert Es sind keine Laufzeitdaten von Dienst bzw. Dienstinstanz mehr auf dem System Nachbedingungen Die TOSCA-Laufzeitumgebung wurde mit allen zugehörigen Laufzeitdaten, Teilsystemen und Plugins deinstalliert Normalablauf 1. Der TOSCA-Container-Administrator deinstalliert alle Komponenten der TO- SCA-Laufzeitumgebung und löscht zugehörige Laufzeitdaten 2. Die TOSCA-Laufzeitumgebung ist vollständig deinstalliert TOSCA-Laufzeitumgebung starten Name TOSCA-Laufzeitumgebung starten Ziel Akteure Dieser Anwendungsfall beschreibt, wie die TOSCA-Laufzeitumgebung ordnungsgemäß gestartet wird, um anschließend für die Installation von TOSCA- Lösungspaketen und Instanziierung von Dienstinstanzen zur Verfügung zu stehen TOSCA-Container-Administrator (TCA) Vorbedingungen Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß installiert (siehe Anwendungsfall TOSCA-Laufzeitumgebung installieren ) Nachbedingungen Die TOSCA-Laufzeitumgebung wurde gestartet und kann nun für die Installation von TOSCA-Lösungspaketen und Instanziierung von Dienstinstanzen benutzt werden Normalablauf 1. Der TOSCA-Container-Administrator startet alle Komponenten der TOSCA- Laufzeitumgebung 2. Der TOSCA-Container-Administrator führt eine Test-Suite aus, welche die korrekte Funktionsweise der TOSCA-Laufzeitumgebung prüft 3. Bei erfolgreicher Prüfung ist die Umgebung gestartet und wird für die Managementsysteme des Cloud-Betreibers freigegeben 17

19 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE Ablauf im Fehlerfall 1. Der TOSCA-Container-Administrator startet alle Komponenten der TOSCA- Laufzeitumgebung 2. Der TOSCA-Container-Administrator führt eine Test-Suite aus, welche die korrekte Funktionsweise der TOSCA-Laufzeitumgebung prüft 3. Bei fehlgeschlagener Prüfung wird die Umgebung nicht freigegeben und der TCA wird mit der Suche und Beseitigung der Fehlerursache beauftragt TOSCA-Laufzeitumgebung herunterfahren Name Ziel TOSCA-Laufzeitumgebung herunterfahren Dieser Anwendungsfall beschreibt, wie die TOSCA-Laufzeitumgebung ordnungsgemäß gestoppt bzw. heruntergefahren Akteure TOSCA-Container-Administrator (TCA) Vorbedingungen Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß installiert (siehe Anwendungsfall TOSCA-Laufzeitumgebung installieren ) und wird ausgeführt Alle Dienstinstanzen von installierten Diensten wurden ordnungsgemäß beendet (siehe Anwendungsfall Dienstinstanz terminieren ) Nachbedingungen Die TOSCA-Laufzeitumgebung wurde heruntergefahren Normalablauf 1. Der TOSCA-Container-Administrator beendet alle Komponenten der TOSCA- Laufzeitumgebung 2. Die TOSCA-Laufzeitumgebung wurde vollständig heruntergefahren TOSCA-Laufzeitumgebung Plugin installieren Name TOSCA-Laufzeitumgebung Plugin installieren Ziel Dieser Anwendungsfall beschreibt die Installation eines TOSCA- Laufzeitumgebung Plugins in die TOSCA-Laufzeitumgebung. Nach der Installation übernimmt das Plugin die konzipierten Aufgaben und kann so beispielsweise Sicherheitsanforderungen umsetzen. Akteure Plugins stellen Erweiterungen der Funktionalität einer TOSCA- Laufzeitumgebung dar. Sie können dadurch beispielsweise Management- Funktionalitäten von Anwendungen unterstützen oder überhaupt erst ermöglichen. Plugins stellen dabei Funktionalitäten, wie zum Beispiel weitere Workflow-Engines, die zur Ausführung von Management-Plänen verwendet werden oder Laufzeitumgebungen, welche benötigt werden, um Services, die von Management-Plänen benötigt werden, bereitzustellen. TOSCA-Container-Administrator Vorbedingungen Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß installiert Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß gestartet (siehe Anwendungsfall TOSCA-Laufzeitumgebung starten ) Das zu installierende Plugin ist noch nicht in der TOSCA-Laufzeitumgebung installiert Nachbedingungen Das Plugin ist in der TOSCA-Laufzeitumgebung installiert und kann verwendet werden 18

20 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 Die Installation eines Plugins bietet möglicherweise Funktionen, welche von Anwendungen zu deren Management benötigt werden. Nach der Installation eines Plugins kann es somit möglich sein, dass Anwendungen, welche vorher aufgrund eines fehlenden Plugins nicht verwaltet werden konnten, nun betrieben werden können. Normalablauf 1. Der TOSCA-Container-Administrator installiert das Plugin über die Management-Schnittstelle der TOSCA-Laufzeitumgebung 2. Der TOSCA-Container-Administrator schaltet das Plugin nach erfolgreicher Installation über die Management Oberfläche der TOSCA-Laufzeitumgebung frei. Anschließend kann es von der Laufzeitumgebung benutzt werden. Ablauf im Fehlerfall 1. Der TOSCA-Container-Administrator installiert das Plugin über die Management-Schnittstelle der TOSCA-Laufzeitumgebung 2. Bei der Installation tritt ein Fehler auf. Der TOSCA-Container-Administrator wird mit der Fehlersuche beauftragt und macht die bisherigen Änderungen manuell rückgängig TOSCA-Laufzeitumgebung Plugin konfigurieren Name TOSCA-Laufzeitumgebung Plugin konfigurieren Ziel Dieser Anwendungsfall beschreibt die Konfiguration eines TOSCA- Laufzeitumgebung Plugins der TOSCA-Laufzeitumgebung. Ein Beispiel für eine Konfiguration ist das Einstellen des Sicherheitsniveaus für bestimmte Anwendungstopologien. Akteure TOSCA-Container-Administrator Vorbedingungen Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß installiert Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß gestartet (siehe Anwendungsfall TOSCA-Laufzeitumgebung starten ) Das zu konfigurierende Plugin ist in der TOSCA-Laufzeitumgebung installiert Nachbedingungen Das Plugin wurde neu konfiguriert und beeinflusst fortan das Verhalten des Plugins Da das Management von Anwendungen auf Funktionalitäten von Plugins basieren kann, hat die Konfiguration eines Plugins und damit dessen Funktionalität möglicherweise Auswirkungen auf den Betrieb einer (installierten) Anwendung. Wird ein Plugin neu konfiguriert, können möglicherweise betroffene Management-Funktionalitäten der Anwendung nicht mehr lauffähig sein oder ein anderes Verhalten zeigen. Normalablauf 1. Der TOSCA-Container-Administrator konfiguriert das Plugin über die Management-Schnittstelle der TOSCA-Laufzeitumgebung 2. Der TOSCA-Container-Administrator schaltet das Plugin nach erfolgreicher Konfiguration über die Management Oberfläche der TOSCA- Laufzeitumgebung frei. Anschließend sind die getätigten Änderungen aktiv und kann von der Laufzeitumgebung benutzt werden. Ablauf im Fehlerfall 1. Der TOSCA-Container-Administrator konfiguriert das Plugin über die Management-Schnittstelle der TOSCA-Laufzeitumgebung 2. Bei der Konfiguration tritt ein Fehler auf. Der TOSCA-Container-Administrator wird mit der Fehlersuche beauftragt und macht die bisherigen Änderungen manuell rückgängig 19

21 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE TOSCA-Laufzeitumgebung Plugin deinstallieren Name TOSCA-Laufzeitumgebung Plugin deinstallieren Ziel Dieser Anwendungsfall beschreibt die Deinstallation eines TOSCA- Laufzeitumgebung Plugins aus der TOSCA-Laufzeitumgebung. Akteure TOSCA-Container-Administrator Vorbedingungen Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß installiert Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß gestartet (siehe Anwendungsfall TOSCA-Laufzeitumgebung starten ) Das zu deinstallierende Plugin ist in der TOSCA-Laufzeitumgebung installiert Nachbedingungen Das Plugin ist in der TOSCA-Laufzeitumgebung deinstalliert und kann nicht mehr verwendet werden Da das Management von Anwendungen auf Funktionalitäten von Plugins basieren kann, hat die Deinstallation eines Plugins und damit dessen Funktionalität möglicherweise Auswirkungen auf den Betrieb einer (installierten) Anwendung. Fehlt ein Plugin, können Management-Funktionalitäten der Anwendung möglicherweise nicht mehr lauffähig sein. In diesem Fall teilt die TOSCA-Laufzeitumgebung dem Nutzer mit, dass aufgrund eines fehlenden Plugins die Management-Funktionalität nicht verwendet werden kann. Normalablauf 1. Der TOSCA-Container-Administrator deinstalliert das Plugin über die Management-Schnittstelle der TOSCA-Laufzeitumgebung 2. Das Plugin ist nicht mehr in der TOSCA-Laufzeitumgebung installiert und kann nicht mehr verwendet werden. Ablauf im Fehlerfall 1. Der TOSCA-Container-Administrator deinstalliert das Plugin über die Management-Schnittstelle der TOSCA-Laufzeitumgebung 2. Bei der Deinstallation tritt ein Fehler auf. Der TOSCA-Container-Administrator wird mit der Fehlersuche beauftragt und macht die bisherigen Änderungen manuell rückgängig Dienstinstanz starten Name Ziel Dienstinstanz starten Dieser Anwendungsfall beschreibt die Instanziierung einer Dienstinstanz eines Cloud-Dienstes über die TOSCA-Laufzeitumgebung. Nach der Instanziierung kann die Dienstinstanz konfiguriert und vom Endnutzer genutzt werden. Der beteiligte Akteur ist dabei der TOSCA-Enabled-Cloud-Betreiber. Gemäß des CloudCycle-Ökosystems können zwar auch TOSCA-Enabled- Marktplatzbetreiber und der Kunde eine Dienstinstanz beim Cloud-Betreiber instanziieren, dieser Anwendungsfall beschreibt jedoch nur die direkte Interaktion mit der TOSCA-Laufzeitumgebung. Da der Cloud-Betreiber die Kommunikationsschnittstelle der Laufzeitumgebung nicht direkt dem Kunden bzw. Marktplatz anbieten sollte, wird die Schnittstelle durch Cloud-Betreiber spezifische Komponenten gekapselt, welche die Laufzeitumgebung mit den Management Systemen des Cloud-Betreibers integriert. Somit ist nur der TO- SCA-Enabled-Cloud-Betreiber durch diese kapselnden Komponenten der direkte Akteur, Kunde und Marktplatz nur indirekt. 20

22 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 Akteure TOSCA-Enabled-Cloud-Betreiber (TECB) Vorbedingungen Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß installiert Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß gestartet (siehe Anwendungsfall TOSCA-Laufzeitumgebung starten ) Das TOSCA-Lösungspaket, welches den zu instanziierenden Dienst beschreibt, wurde ordnungsgemäß installiert (siehe Anwendungsfall TOSCA- Lösungspaket installieren ) Nachbedingungen Die Dienstinstanz wurde ordnungsgemäß instanziiert und kann nun konfiguriert und vom Endnutzer genutzt werden Normalablauf 1. Der TOSCA-Enabled-Cloud-Betreiber (oder eine kapselnde Komponente seines Cloud Management Systems) ruft die Methode, welche für die Dienstinstanziierung verantwortlich ist, an der Kommunikationsschnittstelle der TO- SCA-Laufzeitumgebung auf und referenziert den zu instanziierenden Dienst, welcher durch ein vorab installiertes TOSCA-Lösungspaket beschrieben wird 2. Die TOSCA-Laufzeitumgebung leitet die vollautomatische Instanziierung des referenzierten Dienstes ein 3. Nach der Instanziierung erscheint die Dienstinstanz in der Management Oberfläche der TOSCA-Laufzeitumgebung und kann nun konfiguriert und vom Endnutzer genutzt werden Ablauf im Fehlerfall 1. Der TOSCA-Enabled-Cloud-Betreiber (oder eine kapselnde Komponente seines Cloud Management Systems) ruft die Dienstinstanziierungsmethode an der Kommunikationsschnittstelle der TOSCA-Laufzeitumgebung auf und referenziert den zu instanziierenden Dienst, welcher durch ein vorab installiertes TOSCA-Lösungspaket beschrieben wird 2. Die TOSCA-Laufzeitumgebung instanziiert vollautomatisch den referenzierten Dienst. Dabei kommt es zu einem Fehler und die Dienstinstanz kann nicht ordnungsgemäß instanziiert werden 3. Der TOSCA-Container-Administrator wird mit der Ursachenforschung und Behebung des Fehlers beauftragt Dienstinstanz verwalten Name Ziel Dienstinstanz verwalten Dieser Anwendungsfall beschreibt die Verwaltung einer Dienstinstanz eines Cloud-Dienstes über die TOSCA-Laufzeitumgebung. Die Verwaltung der Dienstinstanz kann dabei unterschiedlichste Ausprägungen annehmen. Beispiele sind das Skalieren einer Dienstinstanz um die Performanz der Applikation zu erhöhen, das Aktualisieren von Sicherheitsmechanismen oder Einspielen von Updates, bis hin zur Erstellung von Datenbackups. Die Verwaltungsaufgaben sind daher anwendungsspezifisch bezüglich des Cloud-Dienstes und werden über die TOSCA-Laufzeitumgebung aufgerufen. Der beteiligte Akteur ist dabei der TOSCA-Enabled-Cloud-Betreiber. Gemäß dem CloudCycle-Ökosystems können zwar auch TOSCA-Enabled- Marktplatzbetreiber und der Kunde eine Dienstinstanz beim Cloud-Betreiber verwalten, dieser Anwendungsfall beschreibt jedoch nur die direkte Interaktion mit der TOSCA-Laufzeitumgebung. Da der Cloud-Betreiber die Kommunikationsschnittstelle der Laufzeitumgebung nicht direkt dem Kunden bzw. Marktplatz anbieten sollte, wird die Schnittstelle durch Cloud-Betreiber spezifische Komponenten gekapselt, welche die Laufzeitumgebung mit den Ma- 21

23 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE Akteure nagement Systemen des Cloud-Betreibers integriert. Somit ist nur der TOSCA- Enabled-Cloud-Betreiber durch diese kapselnden Komponenten der direkte Akteur, Kunde und Marktplatz nur indirekt. TOSCA-Enabled-Cloud-Betreiber (TECB) Vorbedingungen Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß installiert Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß gestartet (siehe Anwendungsfall TOSCA-Laufzeitumgebung starten ) Das TOSCA-Lösungspaket, welches den zu terminierenden Dienst beschreibt, wurde ordnungsgemäß installiert (siehe Anwendungsfall TOSCA- Lösungspaket installieren ) Die zu terminierende Dienstinstanz (Instanziierter Dienst welcher durch ein TOSCA-Lösungspaket beschrieben wird) wurde ordnungsgemäß instanziiert (siehe Anwendungsfall Dienstinstanz starten ) Nachbedingungen Die intendierte Verwaltungsaufgabe wurde erfolgreich an der Dienstinstanz ausgeführt Normalablauf 1. Der TOSCA-Enabled-Cloud-Betreiber (oder eine kapselnde Komponente seines Cloud Management Systems) ruft die generische Dienstverwaltungsmethode an der Kommunikationsschnittstelle der TOSCA-Laufzeitumgebung auf und referenziert den zu verwaltenden Dienst, welcher durch ein vorab installiertes TOSCA-Lösungspaket beschrieben wird, und die beabsichtigte Verwaltungsaufgabe 2. Die TOSCA-Laufzeitumgebung führt die spezifizierte Verwaltungsaufgabe vollautomatisch an der referenzierten Dienstinstanz durch Ablauf im Fehlerfall 1. Der TOSCA-Enabled-Cloud-Betreiber (oder eine kapselnde Komponente seines Cloud Management Systems) ruft die generische Dienstverwaltungsmethode an der Kommunikationsschnittstelle der TOSCA-Laufzeitumgebung auf und referenziert den zu verwaltenden Dienst, welcher durch ein vorab installiertes TOSCA-Lösungspaket beschrieben wird, und die beabsichtigte Verwaltungsaufgabe 2. Bei der Durchführung der spezifizierten Verwaltungsaufgabe tritt ein Fehler auf. Der TOSCA-Container-Administrator wird mit der Fehlersuche beauftragt und führt die Verwaltungsaufgabe möglicherweise manuell an der Dienstinstanz durch Dienstinstanz terminieren Name Ziel Dienstinstanz terminieren Dieser Anwendungsfall beschreibt die Terminierung (Beenden) einer Dienstinstanz eines Cloud-Dienstes über die TOSCA-Laufzeitumgebung. Nach der Terminierung wird die Instanz des Dienstes beendet und kann nicht weiter vom Endnutzer genutzt werden. Der beteiligte Akteur ist dabei der TOSCA-Enabled-Cloud-Betreiber. Gemäß dem CloudCycle-Ökosystems können zwar auch TOSCA-Enabled- Marktplatzbetreiber und der Kunde eine Dienstinstanz beim Cloud-Betreiber terminieren, dieser Anwendungsfall beschreibt jedoch nur die direkte Interaktion mit der TOSCA-Laufzeitumgebung. Da der Cloud-Betreiber die Kommunikationsschnittstelle der Laufzeitumgebung nicht direkt dem Kunden bzw. Marktplatz anbieten sollte, wird die Schnittstelle durch Cloud-Betreiber 22

24 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 Akteure spezifische Komponenten gekapselt, welche die Laufzeitumgebung mit den Management Systemen des Cloud-Betreibers integriert. Somit ist nur der TO- SCA-Enabled-Cloud-Betreiber durch diese kapselnden Komponenten der direkte Akteur, Kunde und Marktplatz nur indirekt. TOSCA-Enabled-Cloud-Betreiber (TECB) Vorbedingungen Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß installiert Die TOSCA-Laufzeitumgebung wurde ordnungsgemäß gestartet (siehe Anwendungsfall TOSCA-Laufzeitumgebung starten ) Das TOSCA-Lösungspaket, welches den zu terminierenden Dienst beschreibt, wurde ordnungsgemäß installiert (siehe Anwendungsfall TOSCA- Lösungspaket installieren ) Die zu terminierende Dienstinstanz (Instanziierter Dienst welcher durch ein TOSCA-Lösungspaket beschrieben wird) wurde ordnungsgemäß instanziiert (siehe Anwendungsfall Dienstinstanz starten ) Nachbedingungen Die Dienstinstanz wurde terminiert Normalablauf 1. Der TOSCA-Enabled-Cloud-Betreiber (oder eine kapselnde Komponente seines Cloud Management Systems) ruft die Dienstterminierungsmethode an der Kommunikationsschnittstelle der TOSCA-Laufzeitumgebung auf und referenziert die zu terminierende Dienstinstanz 2. Die TOSCA-Laufzeitumgebung terminiert vollautomatisch die referenzierte Dienstinstanz 3. Nach der Terminierung erscheint die Dienstinstanz nicht mehr in der Management Oberfläche der TOSCA-Laufzeitumgebung und kann nicht mehr vom Endnutzer genutzt werden Ablauf im Fehlerfall 1. Der TOSCA-Enabled-Cloud-Betreiber (oder eine kapselnde Komponente seines Cloud Management Systems) ruft die Dienstterminierungsmethode an der Kommunikationsschnittstelle der TOSCA-Laufzeitumgebung auf und referenziert die zu terminierende Dienstinstanz 2. Die TOSCA-Laufzeitumgebung versucht die referenzierte Dienstinstanz zu terminieren. Dabei tritt ein Fehler auf. 3. Der TOSCA-Container-Administrator wird mit der Fehlersuche beauftragt und versucht die Dienstinstanz manuell zu terminieren 23

25 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE 5 Open Source TOSCA-Container OpenTOSCA (Universität Stuttgart) In diesem Kapitel werden Architektur (5.1), Grobdesign (5.2) und Feindesign (5.3) des OpenTOSCA-Containers (in den vorherigen Kapiteln TOSCA-Laufzeitumgebung bzw. CloudCycle- Laufzeitumgebung genannt) detailliert beschrieben. Der Container ist eine Laufzeitumgebung zur Ausführung von TOSCA Service Templates und implementiert in der aktualisierten Version die TOSCA-Spezifikation in der Version 1.0, welche die aktuell von OASIS standardisierte Version ist. OpenTOSCA wird von der Universität Stuttgart im Rahmen des CloudCycle-Projekts entwickelt und wird als Open Source Software bereitgestellt. Dies ermöglicht einer breiten Masse an Entwicklern und Nutzern von den neuen Technologien im Bereich Cloud Computing zu profitieren und OpenTOSCA bei Bedarf anzupassen oder weiterzuentwickeln. Die Modellierung und Sicherstellung von Sicherheits- und Compliance-Policies wird in diesem Dokument nicht explizit betrachtet. Die in CloudCycle dafür entwickelten Konzepte und in OpenTOSCA implementierten Lösungen sind in den publizierten wissenschaftlichen Beiträgen [CC-Policy1, CC-Policy2] zu finden. 5.1 Architektur Im Laufe der Definition der Architektur wurden verschiedene Open Source Komponenten identifiziert und evaluiert, welche vom OpenTOSCA-Container genutzt werden. Für die Datenbank ist das selbstverständlich, daneben werden zur Ausführung von Plänen, also Workflows, und Implementation Artifacts existierende Komponenten verwendet, wie in Abbildung 6 dargestellt. Diese werden durch eine generische Schnittstelle vom Container getrennt, sind also austauschbar und kombinierbar, um die Erweiterbarkeit und lose Kopplung des Containers zu erreichen. In Zukunft können damit einfach weitere Workflow Engines und Implementation Artifact Runtimes integriert werden. Dies entspricht den gestellten Anforderungen aus Kapitel Die Komponente OpenTOSCA-Container in Abbildung 6 wird somit neu entwickelt, die in Grau dargestellten Teile stellen bestehende externe Komponenten dar, genannt Umsysteme, welche nicht direkter Bestandteil des Containers sind und nur entsprechend konfiguriert und integriert werden. Im Folgenden zeigen wir die Architektur des OpenTOSCA-Containers, ihre Komponenten (5.1.1), sowie die Integration der Umsysteme. In Kapitel die Schnittstellen des Containers diskutiert. Abbildung 6: OpenTOSCA-Container und seine Umsysteme 24

26 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version Komponenten der Architektur In der in Abbildung 7 dargestellten Architektur werden TOSCA-Lösungspakete über die Container API in den Open- TOSCA-Container importiert. Dies kann direkt aus einem Modellierungs-Tool, über die grafische Administrations Oberfläche des Containers oder über andere in Zukunft entwickelte Werkzeuge geschehen. Im Container installierte TOSCA-Lösungspakete können über das Self-Service Portal vom Kunden instanziiert werden, wenn die entsprechenden Daten im TOSCA-Lösungspaket enthalten sind. Der Container besteht aus fünf großen logischen Teilen, wie abgebildet in Abbildung 7: (i) Die Control-Komponente steuert den ganzen Container, indem sie die anderen Komponenten orchestriert, je nach Zustand der verwalteten Dienste. (ii) Die Core-Komponente bietet eine Reihe von Funktionalitäten, welche von allen anderen Komponenten gebraucht werden, insbesondere die Verwaltung der Daten, Dateien und Modellen. (iii) Implementation Artefakte, welche die Management Operationen der verschiedenen TOSCA Node Types implementieren, werden von der Implementation Artifact Engine in Abhängigkeit des Types an eines der Plugins übergeben. Die Implementation Artifact Engine stellt außerdem sicher, dass der Container die benötigten Anforderungen der Implementation Artifacts bietet und entscheidet somit, welche Implementation Artifacts deployed werden, insbesondere dann, wenn das TOSCA-Lösungspaket verschiedene Alternativen beinhaltet. (iv) Nach einem ähnlichen Prinzip funktioniert die Plan Engine, in der ein auf die Workflow Engine abgestimmtes Plugin die Management Pläne verarbeitet: Zuerst werden die Pläne analysiert, d.h. es wird untersucht, welche Services ein Plan aufruft. Da diese Aufrufe nur durch Service-Schnittstellen definiert sind, müssen konkrete Service-Endpunkte in den Deployment-Descriptor des Plans geschrieben werden. Diese Informationen werden anschließend bei der Ausführung des Plans verwendet, um die Services aufzurufen. (iv) Der Service Invoker stellt die Verbindung zwischen den Plänen und den von ihnen aufgerufenen Operationen (egal ob durch Implementation Artefakte Implementier oder in der Container oder Portability API angeboten) her. In den nachfolgenden Kapiteln zum Design und Implementierung gehen wir nochmals detailliert auf die Funktionsweise und Realisierung der einzelnen Komponenten ein. Admin UI Self-Service Portal Modeling Tool Container API Operation Control Implementation Artifact Engine Plugin Implementation Artifact Runtime Service Invoker Core Datenspeicher Plugin Plan Engine Plan Portability API Management Plan Plan Runtime Komponente Plugin Umsystem Extene APIs Abbildung 7: Architektur des OpenTOSCA-Containers Externe Schnittstellen und APIs Aktuell bietet der OpenTOSCA-Container drei Arten von Schnittstellen nach außen bzw. für die Pläne an, welche im Folgenden näher beschrieben werden: 25

27 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE Plan Portability API Damit Pläne portabel zwischen verschiedenen TOSCA-Laufzeitumgebungen sind, dürfen sie keine Abhängigkeiten zu Schnittstellen einer speziellen Laufzeitumgebung haben. Pläne brauchen jedoch Zugriff auf die Modell- und Instanz- Daten der Laufzeitumgebung. Damit Management Pläne die Struktur des Dienstes interpretieren und entsprechend darauf reagieren können, ist ein API nötig, welches den Plänen lesenden Zugriff auf die Topologie des Dienstes, wie im TOSCA Service Template beschrieben, gibt. Instanzdaten hingegen sind die Eigenschaften der Knoten und Kanten der Topologie (z. B. die IP Adresse, Benutzernamen) einer Dienstinstanz, also eines laufenden, instanziierten Dienstes. Pläne müssen diese Instanzdaten sowohl lesen als auch schreiben können, beispielsweise wenn eine Management Aktion den Zustand eines Dienstes geändert hat. Da diese Art von Daten für Management Pläne nötig sind, Pläne jedoch nicht von einer bestimmten Laufzeitumgebung abhängig sein dürfen, sollte diese sogenannte Plan Portability API in Zukunft standardisiert werden. Container API Die Container API ist spezifisch für den OpenTOSCA-Container und ermöglicht die Steuerung des Containers. Hier sind Funktionalitäten wie der Import, das Auflisten und das Löschen von TOSCA-Lösungspaketen möglich, sowie die Verwaltung der Container Plugins. Service Invoker Der Service Invoker ist die zentrale Anlaufstelle für Pläne wenn diese Operationen welche durch Implementation Artifacts oder durch die Container API bereitgestellt werden aufrufen. Der Pläne können somit ausschließlich gegen diese Schnittstelle implementiert werden und der Service Invoker reicht die Anfragen dann an die entsprechenden Operationen weiter. Dies entkoppelt die Pläne komplett von der Implementierung des TOSCA Containers welcher die Implementation Artifacts an einer beliebigen Stelle deployen kann, dazu macht TOSCA und die CSAR keine Vorgaben Erweiterbarkeit des Containers Um die Anforderungen aus Kapitel zu erfüllen, verwendet der OpenTOSCA-Container die Softwareplattform und das Komponentenmodell von OSGi, dem Industrie Standard für Komponenten-basierte Anwendungen im Java- Umfeld. Die verschiedenen Komponenten werden als OSGi Bundles in der OSGi Plattform ausgeführt und bieten ihre Funktionalität als Dienst für andere Komponenten an. Zwei Vorteile von OSGi sind dabei (1) das dynamische Hinzufügen und Entfernen von Diensten zur Laufzeit und (2) das Management der Abhängigkeiten verschiedener Bundles, sowie diese zu konfigurieren und zu binden. Der Container ist komplett durch OSGi realisiert und die gesamte Funktionalität durch OSGi Bundles implementiert. Somit ist es möglich, den Container schnell und einfach zu erweitern, was für den OpenTOSCA Architekturansatz von zentraler Bedeutung ist, da sehr viel Logik in Plugins ausgelagert wird. Schnittstelle für Plan Engine und Implementation Artifact Engine Plugins Sowohl Pläne als auch Implementation Artifacts erlauben es dem Modellierer verschiedene Sprachen und Formate (gemeinsam im Folgenden Typ genannt) in das TOSCA-Lösungspaket zu integrieren. Pläne können in verschiedenen Workflow Sprachen definiert sein, beispielsweise BPEL oder BPMN. Gleiches gilt für Implementation Artifacts, also die Implementierungen von Management Operationen, die beispielsweise in Java, Perl, PHP,.Net etc. implementiert sein können. Diese verschiedenen Optionen sollten selbstverständlich nicht in den eigentlichen Kern des Containers hineingezogen werden, was Abhängigkeiten schaffen und die Erweiterbarkeit erschweren würde. Aus diesem Grund wird bei OpenTOSCA typspezifische Logik durch Plugins integriert, welche, wie alle anderen Container Komponenten auch, als OSGi-Bundles realisiert werden. Konzeptionell implementieren wir damit das sogenannte SOA-Dreieck ( publish, find, bind ), wie in Abbildung 8 am Beispiel der Plan Engine Plugins dargestellt. Ein Plan Engine Plugin, welches das entsprechende Interface implementiert, registriert sich beim OSGi Framework und teilt diesem mit, welche Dienste es anbietet ( publish -Phase). Die Plan Engine erhält entsprechende Anforderungen des Containers, um bestimmte Pläne zu deployen. Daraufhin sucht die generische Plan Engine nach einem passenden Plugin für die Verarbeitung eines bestimmten Plan-Typs ( find -Phase). Die Plan Engine stellt nun, mithilfe des OSGi 26

28 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 Frameworks, eine Verbindung mit dem jeweiligen Plugin her und tauscht die nötigen Informationen aus, um den entsprechenden Plan zu deployen ( bind -Phase). Die Verarbeitung von Implementation Artefakten ist analog dazu gelöst und wird deshalb hier nicht nochmals explizit erklärt. OSGi Framework <<ServiceDiscovery>> (2) find (1) publish Plan Engine <<ServiceRequestor>> (3) bind Engine Plan Plugin <<ServiceProvier>> Abbildung 8: Umsetzung des SOA-Dreiecks in der Plan Engine Container Plugins für Container Capabilities Zu den beiden bereits erwähnten Schnittstellen ist es jederzeit möglich, weitere OSGi Bundles für neue Container- Funktionalitäten zu installieren bzw. existierende Komponenten zu ersetzen. Falls Management Operationen eine dieser Funktionalität benötigen, können die Bundles diese als Container-Capability beim Container registrieren und zur Verfügung stellen. 5.2 Grobdesign Basierend auf der in Kapitel 5.1 definierten Architektur wurden die in Abbildung 9 dargestellte OSGi Packages definiert, insbesondere deren Abhängigkeiten untereinander. Das Control-Package empfängt Befehle der ContainerAPI und orchestriert die OSGi-Dienste, welche den Container bilden. Die TOSCAEngine ist für die Bearbeitung des TOSCA Service Templates verantwortlich, beispielsweise das Auflösen von Imports und Ähnlichem. Auf der rechten Seite von Abbildung 9 ist die PortabilityAPI dargestellt, sowie die verschiedenen Implementation Artifact und Plan Plugins, welche mit Laufzeitumgebungen außerhalb des Containers kommunizieren. Die Core-Packages verwalten die verschiedenen Arten von Daten und deren Modelle. Außerdem wird hier der Fortschritt des Deployments persistiert. 27

29 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE Abbildung 9: OpenTOSCA-Container Design der OSGi Packages Datenspeicher OpenTOSCA verwendet eine Reihe von Datenspeichern, um verschiedene Klassen von Informationen abzulegen. Diese sind durch die Core Functionalities gekapselt und werden durch diese den anderen Komponenten des Containers angeboten. Im Folgenden diskutieren wir, welche Informationen in den jeweiligen Datenspeichern abgelegt werden. Dateien Alle Dateien, die in einem TOSCA-Lösungspaket enthalten sind, werden unabhängig von ihrem Typ persistent abgespeichert. Diese können zu einem späteren Zeitpunkt über die sogenannte FileAPI mithilfe ihres relativen Pfads im TOSCA-Lösungspaket wieder abgerufen werden. Dieser Datenspeicher kann auf verschiedene Arten realisiert werden, muss jedoch transparent für die darüber liegenden Management Pläne sein. Im aktuellen Design werden die Dateien auf dem lokalen Dateisystem des Servers gespeichert, welcher den OpenTOSCA-Container ausführt. Somit ist es möglich, auf die Dateien einfach mit ihrem relativen Pfad zuzugreifen. Zusätzlich können Referenzen auf diese Dateien auch über die ModelAPI abgerufen werden. Die Verwendung des lokalen Dateisystems bringt für die aktuelle Version die Einschränkung mit sich, dass alle Komponenten, die Zugriff auf die Dateien brauchen, auf dem gleichen Server laufen müssen wie der Container selbst (z. B. Management Operationen, welche durch Implementation Artefakte implementiert sind oder Pläne selbst). Model In der Modell Datenbank wird das konsolidierte, normalisierte und validierte TOSCA Modell des kompletten TOSCA Service Templates gespeichert. Dieses Modell wird benötigt, um beispielsweise den verschiedenen Komponenten Zugriff auf die Topologie und die Pläne zu ermöglichen. Der Einsatz eines Object Relational Mappers (ORM) bietet sich an, um die Java Objekte, welche das Modell repräsentieren, in die Datenbank zu schreiben oder zu lesen. 28

30 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 Instanz Der Instanzdaten-Datenspeicher wird über die PortabilityAPI bereitgestellt und soll hauptsächlich von den Plänen verwendet werden. Sie verwaltet die Dienstinstanzen, die darin enthaltenen Nodes und Relationen sowie deren ID, Properties und Status. Für eine virtuelle Maschine bei Amazon EC2 könnte hier, in Abhängigkeit von den auf dem Node Type definieren Properties, beispielsweise IP Adresse, Passwort und Ähnliches gespeichert werden. Endpunkte Wenn ein Implementation Artefakt von dem entsprechenden Plugin installiert wird, muss der Container den Endpunkt, unter dem es seine Funktionalität zur Verfügung stellt, speichern. Bei Web Services, welche über eine WSDL beschrieben werden, werden PortType, Operation und eine URL gespeichert, über die diese Operation aufgerufen wird. Gleiches gilt für APIs, welche der Container anbietet, die also nicht durch Implementation Artifacts bereitgestellt werden, wie beispielsweise die PortabilityAPIs. Die hier gespeicherten Informationen werden beim Deployment der Pläne zum Binden der Dienste benötigt, wie in Kapitel 5.3 im Detail beschrieben. Plan Metadaten Auch für Management Pläne müssen Informationen persistiert werden, genauso wie für die Endpunkte. Wenn ein Plan Engine Plugin einen Management Plan auf der entsprechenden Workflow Maschine installiert hat, speichert er ab, welcher Plan wo deployed wurde und unter welchem Endpunkt er aufgerufen bzw. instanziiert werden kann. Aktuell werden die Informationen nicht genutzt, in Zukunft soll es jedoch möglich sein, Management Pläne direkt von der Container Benutzeroberfläche starten zu können. 5.3 Entwurf, Feindesign und Implementierung In diesem Kapitel gehen wir detailliert auf die Umsetzung der Architektur (Kapitel 5.1) und des Grobdesigns (Kapitel 5.2) des Containers ein und verdeutlichen die Schnittstellen und Arbeitsweise Arbeitsweise des Containers Im Folgenden beschreiben wir anhand von sechs Schritten die Funktionsweise des Containers bezüglich des Deployments eines Dienstes und dessen Instanziierung anhand der Architektur-Übersichtsgrafik, welche die verschiedenen OSGi-Komponenten beinhaltet. Jede weiße Box entspricht einem OSGi-Bundle, meistens sogar zwei Bundles, weil Interface und Implementierung des Dienstes separat gehalten werden, um Implementierungen flexibel austauschen zu können. Alle anderen Boxen, beispielsweise Core und Engines, dienen nur der Gruppierung und Zuordnung der Bundles zu einem bestimmten Teil der Architektur. Relationen, über welche im jeweiligen Schritt kommuniziert wird, sind in der jeweiligen Abbildung in Rot hervorgehoben. Schritt 1: Import Über die Benutzeroberfläche des Containers wird ein TOSCA-Lösungspaket importiert und an den Container weitergegeben. Auch wenn ein anderes System oder Client als die Benutzeroberfläche verwendet wird, beispielsweise ein Marktplatz oder ein Modellierungstool, wird dieses immer integriert, indem ein TOSCA-Lösungspaket über die ContainerAPI an den Container gesendet wird. 29

31 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE Abbildung 10: OpenTOSCA-Container Kontrollfluss von Schritt 1 Schritt 2: Entpacken, Analysieren und Auflösen Das TOSCA-Lösungspaket wird an die Core-Komponente geschickt, welche dieses entpackt und im Dateisystem ablegt. Daraufhin werden im nächsten Schritt die Inhalte analysiert. In allen hier definierten Schritten speichert Control den aktuellen Zustand bzw. Fortschritt des Service Template Deployments mithilfe des Deployment Trackers. Abbildung 11: OpenTOSCA-Container Kontrollfluss von Schritt 2 30

32 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 Schritt 3: Verarbeitung der TOSCA Service Definition Eine spezielle Datei mit Metadaten über das Lösungspaket verweist auf die Wurzel TOSCA Service Definition, welche zuerst verarbeitet werden muss und ggf. weitere Service Definitions importiert. Die TOSCA Service Definitionen werden in ihr Java Modell transformiert und die Imports aufgelöst. Diese Service Definition wird in der Model Datenbank gespeichert. Abbildung 12: OpenTOSCA-Container Kontrollfluss von Schritt 3 Schritt 4: Implementation Artifacts deployen Control holt nun alle Node Templates von Core und ruft die Implementation Artifact Engine (IAEngine) auf, um diese zu deployen. Die IAEngine wertet die Required Container Features und den Typ des Implementation Artifacts aus und ruft damit das entsprechende Plugin auf. Diese Plugins holen sich die zum Implementation Artifact gehörenden Dateien und sind für deren Deployment verantwortlich. Dies kann zum Beispiel realisiert werden, indem das Plugin für WAR-Dateien einen Apache Tomcat kennt und das Implementation Artifact auf diesem deployed. 31

33 Verwaltung und Austausch von Cloud-Diensten CLOUDCYCLE Abbildung 13: OpenTOSCA-Container Kontrollfluss von Schritt 4 Schritt 5: Pläne binden und deployen In diesem Schritt holt sich Control die im Service Template definierten Pläne und ruft mit diesen die Plan Engine auf. Diese holt die dazugehörigen Dateien über die FileAPI und leitet die Anfrage an das entsprechende Plugin weiter. Dieses Plugin muss die abstrakten Aufrufe von Diensten in den Workflows an die entsprechenden Endpunkte binden. In der aktuellen Version von OpenTOSCA ist dies ausschließlich der Endpunkt des Service Invokers über welchen alle anderen Aufrufe von Operationen laufen. In früheren Versionen musste dies für jeden Operationsaufruf der verschiedenen Node Types durchgeführt werden. Das Binden der Pläne an die konkreten Endpunkte wird realisiert indem das Plugin den Workflow analysiert und die abstrakten Dienstaufrufe an den entsprechenden konkreten Endpunkt aus der Endpunkt Datenbank bindet. Da dieser Prozess abhängig von der genutzten Sprache, Format und Ziel-Workflow-Engine des Planes ist muss dies im entsprechenden Plugin realisiert werden (z.b. in dem aktuell implementierten Plugin für BPEL Workflows auf dem WSO2 Business Process Server). Anschließend wird der Workflow auf einer, dem Typ entsprechenden Workflow Engine, deployed. Die deployten Pläne werden nun wiederum in der Datenbank für Pläne abgespeichert. Anschließend ist der Import des TOSCA-Lösungspakets im Container abgeschlossen und neue Instanzen können erstellt werden, wie im nächsten Schritt beschrieben. 32

34 CLOUDCYCLE AK-300: Rollen, Architektur, Design und Implementierung Version 2 Abbildung 14: OpenTOSCA-Container Kontrollfluss von Schritt 5 Schritt 6: Ausführung Build Plan Dieser Schritt wird angestoßen, wenn eine neue Instanz des in Schritt 1-5 importierten Cloud Dienstes gestartet werden soll. Dazu muss der Build Plan aufgerufen werden, ein spezieller Management Plan, welcher die Logik zum Instanziieren einer neuen Dienstinstanz enthält. Dies wird durch das Senden einer Nachricht an den Web Service Endpunkt des Plans angestoßen. Während seiner Laufzeit ruft der Build Plan Operationen über den Service Invoker auf und greift über die Plan Portability API auf die Instanzdaten zu, welche vom Container verwaltet werden. Das Senden einer Nachricht zur Instanziierung des Build Plans ist die technische Realisierung welche jedoch nicht von nicht-technisch versierten Benutzer verwendet werden kann. Um die deployten TOSCA-Lösungspakete Nutzer zur Instanziierung zur Verfügung zu stellen wurde das Self-Service Portal Vinothek entwickelt welches in Abbildung 15 dargestellt ist. Dieses stellt dem Nutzer im ersten Schritt eine Liste aller deployten TOSCA-Lösungspakete zur Verfügung. Im zweiten Schritt wird für jedes TOSCA-Lösungspaket eine Detailansicht (dargestellt in Abbildung 15) bereitgestellt, welche weitergehende Informationen zum darin enthaltenen Dienst enthält. Durch einen Klick auf den entsprechenden Button kann der Benutzer die Instanziierung des gewählten TOSCA-Lösungspaketes anstoßen. Im Hintergrund wird dazu eine im TOSCA-Lösungspaket vordefinierte Nachricht an den Build Plan geschickt, dieser ausgeführt und am Ende die Adresse der instanziierten Anwendung dem Nutzer wieder in der Vinothek angeboten, ohne dass dieser etwas von den technischen Details im Hintergrund mitbekommt. Um dies zu ermöglichen muss das TOSCA-Lösungspaket um zusätzliche Informationen wie Icon, Abbildung und beschreibender Text erweitert werden. Diese Erweiterung wird von Winery, dem im Rahmen von CloudCycle entwickelten Modellierungswerkzeug unterstützt. 33

Das CloudCycle - Ökosystem Version: 4.0

Das CloudCycle - Ökosystem Version: 4.0 Bereitstellung, Verwaltung und Vermarktung von portablen Cloud-Diensten mit garantierter Sicherheit und Compliance während des gesamten Lebenszyklus Das CloudCycle - Ökosystem Version: 4.0 CLOUSDCYCLE

Mehr

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

Mehr

Policy-Framework (PFW) - Eine Methode zur Umsetzung von Sicherheits-Policies im Cloud-Computing

Policy-Framework (PFW) - Eine Methode zur Umsetzung von Sicherheits-Policies im Cloud-Computing Policy-Framework (PFW) - Eine Methode zur Umsetzung von Sicherheits-Policies im Cloud-Computing Alexander Blehm, Volha Kalach, Alexander Kicherer, Gustav Murawski, Tim Waizenegger, Matthias Wieland CloudCycle'14

Mehr

IBM SPSS Data Access Pack Installationsanweisung für Windows

IBM SPSS Data Access Pack Installationsanweisung für Windows IBM SPSS Data Access Pack Installationsanweisung für Windows Inhaltsverzeichnis Kapitel 1. Übersicht.......... 1 Einführung............... 1 Bereitstellen einer Datenzugriffstechnologie.... 1 ODBC-Datenquellen...........

Mehr

Sascha Schreier. Softwaretechnik: Übung 11.12.09

Sascha Schreier. Softwaretechnik: Übung 11.12.09 Sascha Schreier Softwaretechnik: Übung 11.12.09 Unklarheiten und Fragen Sascha Schreier 11.12.2009 # 2 Systementwurf: Objektentwurf + Einbettung in die Systemumgebung (Pakete, DB, GUI, ) So viele verschiedene

Mehr

MailStore Service Provider Edition (SPE)

MailStore Service Provider Edition (SPE) MailStore Solutions MailStore Service Provider Edition (SPE) E-Mail-Archivierung für Service Provider Mit Hilfe der MailStore Service Provider Edition können Sie Ihren Kunden moderne E-Mail-Archivierung

Mehr

Forschungsergebnisse Projekt Migrate!

Forschungsergebnisse Projekt Migrate! Forschungsergebnisse Projekt Migrate! www.bmwi.de Dezember 2014 Projektüberblick Projekttitel: BMWi FKZ: Migrate! - Modelle, Verfahren und Werkzeuge für die Migration in Cloud-basierte energieoptimierte

Mehr

INFORMATION MONITOR HSM SOFTWARE GMBH CLIENT-INSTALLATION

INFORMATION MONITOR HSM SOFTWARE GMBH CLIENT-INSTALLATION INFORMATION MONITOR HSM SOFTWARE GMBH CLIENT-INSTALLATION Allgemein Infomon bietet die Architektur für das Informations-Monitoring in einer Windows- Topologie. Die Serverfunktionalität wird in einer IIS-Umgebung

Mehr

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014 Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung Klaus Kusche, September 2014 Inhalt Ziel & Voraussetzungen Was sind abstrakte Datentypen? Was kann man damit grundsätzlich?

Mehr

Projekt:

Projekt: <Hier den Namen des Projektes eingeben!> <Adresse> <Telefon / Fax> <Ansprechpartner> Pflichtenheft Die Aufgabe des Pflichtenheftes ist es zu beschreiben, was die zu entwickelnde Software für den Anwender leisten soll. Diese Vorlage basiert auf der aus TSE I bekannten Vorlage. Projekt:

Mehr

Standardisiert aber flexibel

Standardisiert aber flexibel AFCEA e.v. Mittagsforum 24.10.2008 Godesburg, Bonn-Bad Godesberg Standardisiert aber flexibel Prozessmodelle im Übergang von der Theorie in die Praxis. Brian Rosenberger Die Theorie Der entwickelt Verfahren

Mehr

Institut für Architektur von Anwendungssystemen Universität Stuttgart Universitätsstraße 38 70569 Stuttgart Germany. Studienarbeit Nr.

Institut für Architektur von Anwendungssystemen Universität Stuttgart Universitätsstraße 38 70569 Stuttgart Germany. Studienarbeit Nr. Institut für Architektur von Anwendungssystemen Universität Stuttgart Universitätsstraße 38 70569 Stuttgart Germany Studienarbeit Nr. 2410 Vorlagen für das Deployment von Services und Applikationen in

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Datenschutz in der KIVBF SchulverwaltungsCloud Esslingen, 24.10.2014

Datenschutz in der KIVBF SchulverwaltungsCloud Esslingen, 24.10.2014 Datenschutz in der KIVBF SchulverwaltungsCloud Esslingen, 24.10.2014 1 Agenda 1 KIVBF 2 SchulverwaltungsCloud im Landkreis Karlsruhe 3 Struktur und Datenschutz 4 Ausblick mit CLOUDCYCLE 5 Diskussion 2

Mehr

Handbuch zu AS Connect für Outlook

Handbuch zu AS Connect für Outlook Handbuch zu AS Connect für Outlook AS Connect für Outlook ist die schnelle, einfache Kommunikation zwischen Microsoft Outlook und der AS Datenbank LEISTUNG am BAU. AS Connect für Outlook Stand: 02.04.2013

Mehr

Online Help StruxureWare Data Center Expert

Online Help StruxureWare Data Center Expert Online Help StruxureWare Data Center Expert Version 7.2.7 Virtuelle StruxureWare Data Center Expert-Appliance Der StruxureWare Data Center Expert-7.2-Server ist als virtuelle Appliance verfügbar, die auf

Mehr

Das Interceptor Muster

Das Interceptor Muster Das Interceptor Muster Implementierung des Interceptor Musters basierend auf OSGi and Friends Benjamin Friedrich Hochschule für Technik und Wirtschaft des Saarlandes Praktische Informatik - Entwurfsmuster

Mehr

Business Process Execution Language. Christian Vollmer Oliver Garbe

Business Process Execution Language. Christian Vollmer <christian.vollmer@udo.edu> Oliver Garbe <oliver.garbe@udo.edu> Business Process Execution Language Christian Vollmer Oliver Garbe Aufbau Was ist BPEL? Wofür ist BPEL gut? Wie funktioniert BPEL? Wie sieht BPEL aus?

Mehr

Datenmanagement in der Cloud für den Bereich Simulationen und Wissenschaftliches Rechnen

Datenmanagement in der Cloud für den Bereich Simulationen und Wissenschaftliches Rechnen Datenmanagement in der Cloud für den Bereich Simulationen und Wissenschaftliches Rechnen Peter Reimann, Tim Waizenegger, Matthias Wieland, Holger Schwarz Institute für Parallele and Verteilte Systeme (IPVS)

Mehr

Projekt AGB-10 Fremdprojektanalyse

Projekt AGB-10 Fremdprojektanalyse Projekt AGB-10 Fremdprojektanalyse 17. Mai 2010 1 Inhaltsverzeichnis 1 Allgemeines 3 2 Produktübersicht 3 3 Grundsätzliche Struktur und Entwurfsprinzipien für das Gesamtsystem 3 3.1 Die Prefuse Library...............................

Mehr

Sind Privacy und Compliance im Cloud Computing möglich?

Sind Privacy und Compliance im Cloud Computing möglich? Sind und Compliance im Cloud Computing möglich? Ina Schiering Ostfalia Hochschule für angewandte Wissenschaften Markus Hansen Unabhängiges Landeszentrum für Datenschutz www.ostfalie.de Wolfenbüttel, Germany

Mehr

Ein Marktplatz für TOSCA

Ein Marktplatz für TOSCA Institut für Parallele und Verteilte Systeme Universität Stuttgart Universitätsstraße 38 D 70569 Stuttgart Bachelorarbeit Nr. 65 Ein Marktplatz für TOSCA Matthias Fetzer Studiengang: Softwaretechnik Prüfer/in:

Mehr

Upgrade-Leitfaden. Apparo Fast Edit 1 / 7

Upgrade-Leitfaden. Apparo Fast Edit 1 / 7 Upgrade-Leitfaden Apparo Fast Edit 1 / 7 Inhaltsverzeichnis 1 Download der neuen Version... 4 2 Sicherung des Apparo Datenbank-Repository... 4 3 De-Installation der installierten Apparo Fast Edit Version...

Mehr

Services Computing und SOA

Services Computing und SOA Services Computing und SOA GeneriCo Best-Practices und Design-Guidelines in Form der sog. SOA-Blueprints Martin Pellengahr Agenda A. Übersicht über die SOA-Blueprints-Initiative B. GeneriCo-Spezifikation

Mehr

Normfall 7.2. Whitepaper. Erstellen eines Normfall Projektspeichers auf Basis einer vorhandenen Installation von:

Normfall 7.2. Whitepaper. Erstellen eines Normfall Projektspeichers auf Basis einer vorhandenen Installation von: Normfall 7.2 Whitepaper Erstellen eines Normfall Projektspeichers auf Basis einer vorhandenen Installation von: Microsoft SQL Server 2008 R2/2012/2014 2014 Normfall GmbH Alle Rechte vorbehalten. Vorbemerkungen

Mehr

ProCall 5 Enterprise

ProCall 5 Enterprise ProCall 5 Enterprise Installationsanleitung Upgradeverfahren von ProCall 4+ Enterprise auf ProCall 5 Enterprise ProCall 5 Enterprise Upgrade Seite 1 von 10 Rechtliche Hinweise / Impressum Die Angaben in

Mehr

BSI-Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter

BSI-Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter BSI-Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter Alex Didier Essoh und Dr. Clemens Doubrava EuroCloud Deutschland_eco e.v. Köln 02.02.2011 Ziel Ziel des BSI ist es, gemeinsam mit den Marktteilnehmern

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Einführung in die OPC-Technik

Einführung in die OPC-Technik Einführung in die OPC-Technik Was ist OPC? OPC, als Standartschnittstelle der Zukunft, steht für OLE for Process Control,und basiert auf dem Komponentenmodel der Firma Microsoft,dem Hersteller des Betriebssystems

Mehr

Anforderungen an ein Workflow-Management-System im Gesundheitswesen am Beispiel des Gesundheitsnetzes prosenior. prosenior.

Anforderungen an ein Workflow-Management-System im Gesundheitswesen am Beispiel des Gesundheitsnetzes prosenior. prosenior. Anforderungen an ein Workflow-Management-System im Gesundheitswesen am Beispiel des Gesundheitsnetzes M. Sc. Katja Gippert Versorgungsnetz der Knappschaft Bahn-See Behandlung anhand von IV-Pfaden Programm

Mehr

Die Inhalte der Vorlesung wurden primär auf Basis der Vorlesung Software Engineering von Prof. Dr. Faustmann (FHW Berlin Fachbereich II) erstellt.

Die Inhalte der Vorlesung wurden primär auf Basis der Vorlesung Software Engineering von Prof. Dr. Faustmann (FHW Berlin Fachbereich II) erstellt. Software Engineering Dokumentation von Softwarearchitekturen Die Inhalte der Vorlesung wurden primär auf Basis der Vorlesung Software Engineering von Prof. Dr. Faustmann (FHW Berlin Fachbereich II) erstellt.

Mehr

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests Masterarbeit zur Erlangung des akademischen Grades Master of Science (M.Sc.) im Masterstudiengang Wirtschaftswissenschaft

Mehr

Univention Corporate Client. Quickstart Guide für Univention Corporate Client

Univention Corporate Client. Quickstart Guide für Univention Corporate Client Univention Corporate Client Quickstart Guide für Univention Corporate Client 2 Inhaltsverzeichnis 1. Einleitung... 4 2. Voraussetzungen... 5 3. Installation des UCS-Systems... 6 4. Inbetriebnahme des Thin

Mehr

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Die Unified Modeling Language Die UML (hier in der Version 0.9) ist ein Satz von Notationen zur Beschreibung objektorientierter Softwaresysteme.

Mehr

PRÜFUNG. Grundlagen der Softwaretechnik

PRÜFUNG. Grundlagen der Softwaretechnik Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner PRÜFUNG Grundlagen der Softwaretechnik Name: Matrikelnummer: Note: Prüfungstag: 21.09.2012 Prüfungsdauer:

Mehr

Von der UML nach C++

Von der UML nach C++ 22 Von der UML nach C++ Dieses Kapitel behandelt die folgenden Themen: Vererbung Interfaces Assoziationen Multiplizität Aggregation Komposition Die Unified Modeling Language (UML) ist eine weit verbreitete

Mehr

Band M, Kapitel 7: IT-Dienste

Band M, Kapitel 7: IT-Dienste Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 22899 9582-0 E-Mail: Hochverfuegbarkeit@bsi.bund.de Internet: https://www.bsi.bund.de Bundesamt für Sicherheit

Mehr

1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem

1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem 1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem Management, Access Management a. Event Management b. Service Desk c. Facilities Management d. Change Management e. Request Fulfilment

Mehr

Open Source als de-facto Standard bei Swisscom Cloud Services

Open Source als de-facto Standard bei Swisscom Cloud Services Open Source als de-facto Standard bei Swisscom Cloud Services Dr. Marcus Brunner Head of Standardization Strategy and Innovation Swisscom marcus.brunner@swisscom.com Viele Clouds, viele Trends, viele Technologien

Mehr

1 Einleitung. Betriebswirtschaftlich administrative Systeme

1 Einleitung. Betriebswirtschaftlich administrative Systeme 1 1 Einleitung Data Warehousing hat sich in den letzten Jahren zu einem der zentralen Themen der Informationstechnologie entwickelt. Es wird als strategisches Werkzeug zur Bereitstellung von Informationen

Mehr

Collaboration Manager

Collaboration Manager Collaboration Manager Inhalt Installationsanleitung... 2 Installation mit Setup.exe... 2 Security Requirements... 3 Farmadministrator hinzufügen... 3 Secure Store Service... 3 Feature-Aktivierung... 5

Mehr

3. Konzepte der objektorientierten Programmierung

3. Konzepte der objektorientierten Programmierung 3. Konzepte der objektorientierten Programmierung 3.1 Basiskonzepte 3.2 Generalisierung / Spezialisierung 3.3 Aggregation 3.4 Assoziation 3.5 Nachrichten 3.6 Polymorphismus 3. Konzepte der Objektorientierung

Mehr

Prototypvortrag. Exploiting Cloud and Infrastructure as a Service (IaaS) Solutions for Online Game Service Provisioning. Projektseminar WS 2009/10

Prototypvortrag. Exploiting Cloud and Infrastructure as a Service (IaaS) Solutions for Online Game Service Provisioning. Projektseminar WS 2009/10 Prototypvortrag Exploiting Cloud and Infrastructure as a Service (IaaS) Solutions for Online Game Service Provisioning Projektseminar WS 2009/10 Eugen Fot, Sebastian Kenter, Michael Surmann AG Parallele

Mehr

Unser Auftraggeber ist einer der vier Global Player in den Bereichen Wirtschaftsprüfung,

Unser Auftraggeber ist einer der vier Global Player in den Bereichen Wirtschaftsprüfung, Case Study Testautomatisierung mit Coded UI Die Aufgabe Unser Auftraggeber ist einer der vier Global Player in den Bereichen Wirtschaftsprüfung, Steuerberatung und Unternehmens- bzw. Managementberatung.

Mehr

VMware Schutz mit NovaBACKUP BE Virtual

VMware Schutz mit NovaBACKUP BE Virtual VMware Schutz mit NovaBACKUP BE Virtual Anforderungen, Konfiguration und Restore-Anleitung Ein Leitfaden (September 2011) Inhalt Inhalt... 1 Einleitung... 2 Zusammenfassung... 3 Konfiguration von NovaBACKUP...

Mehr

Open Grid Services Architecture (OGSA)

Open Grid Services Architecture (OGSA) Open Grid Services Architecture (OGSA) IBM Red Paper; Fundamentals of Grid Computing, 2002 A d v an ced M id d lew are P ro f. D r. C h. R eich rc h @ fh-furtw angen.d e http://www.informatik.fh-furtwangen.de/~reich/advancedmiddlewareallg.ss05/index.html

Mehr

C# - PROGRAMME MIT PLUGINS ERWEITERN

C# - PROGRAMME MIT PLUGINS ERWEITERN C# - PROGRAMME MIT PLUGINS ERWEITERN Schreibt man ein Programm welches erweiterbar sein soll, dann gibt es häufig mehrere Möglichkeiten dies umzusetzen. Die Objektorientierung ist dabei der erste Schritt,

Mehr

Mitglied der: KNX Association OPC Foundation BACnet Interest Group Europe. Dokumentversion: 1.0.2

Mitglied der: KNX Association OPC Foundation BACnet Interest Group Europe. Dokumentversion: 1.0.2 Mitglied der: KNX Association OPC Foundation BACnet Interest Group Europe Dokumentversion: 1.0.2 Inhaltsverzeichnis 1. System Überblick 4 2. Windows Firewall Konfiguration 5 2.1. Erlauben von DCOM Kommunikation

Mehr

visionapp Server Management 2008 R2 SP1

visionapp Server Management 2008 R2 SP1 visionapp Server Management 2008 R2 SP1 visionapp Multi Hotfix Installer Produktdokumentation Inhalt 1 Einleitung... 1 2 Unterstütze Varianten... 1 3 Verwendung... 1 4 Optionale Funktionen und Konfigurationsmöglichkeiten...

Mehr

VMware vrealize Automation Das Praxisbuch

VMware vrealize Automation Das Praxisbuch VMware vrealize Automation Das Praxisbuch Cloud-Management für den Enterprise-Bereich von Guido Söldner, Jens-Henrik Söldner, Constantin Söldner 1. Auflage dpunkt.verlag 2015 Verlag C.H. Beck im Internet:

Mehr

Aufbau eigener Cloud-Infrastrukturen mit Eucalyptus Hochschule Mannheim

Aufbau eigener Cloud-Infrastrukturen mit Eucalyptus Hochschule Mannheim Andreas Ries Cloud-Computing Seminar Hochschule Mannheim WS0910 1/26 Aufbau eigener Cloud-Infrastrukturen mit Eucalyptus Hochschule Mannheim Andreas Ries Fakultät für Informatik Hochschule Mannheim ries.andreas@web.de

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

Vorstellung Studienprojekt. Policy4TOSCA. Umsetzung eines Policy-Frameworks für sicheres und energieeffizientes Cloud Computing

Vorstellung Studienprojekt. Policy4TOSCA. Umsetzung eines Policy-Frameworks für sicheres und energieeffizientes Cloud Computing Vorstellung Studienprojekt Policy4TOSCA Umsetzung eines Policy-Frameworks für sicheres und energieeffizientes Cloud Computing Institute of Architecture of Application Systems (IAAS) www.iaas.uni-stuttgart.de

Mehr

Sicherheit in Workflow-Management-Systemen

Sicherheit in Workflow-Management-Systemen Sicherheit in Workflow-Management-Systemen Fakultät für Informatik Institut für Programmstrukturen und Datenorganisation KIT University of the State of Baden-Wuerttemberg and National Research Center of

Mehr

A classification and comparison framework for software architecture description languages

A classification and comparison framework for software architecture description languages A classification and comparison framework for software architecture description languages Christian Gerth Seminar Architekturbeschreibungssprachen Prof. Dr. Heike Wehrheim Fachgebiet Spezifikation und

Mehr

Bedeutung von Interoperabilität und Standards in Grid Infrastrukturen

Bedeutung von Interoperabilität und Standards in Grid Infrastrukturen Bedeutung von Interoperabilität und Standards in Grid Infrastrukturen LMU SS 2012 Grid Computing Morris Riedel Federated Systems and Data Jülich Supercomputing Centre Forschungszentrum Jülich m.riedel@fz-juelich.de

Mehr

3M Helth Information Systems. 3M KAPS PEPP Simulation. Installationsanleitung

3M Helth Information Systems. 3M KAPS PEPP Simulation. Installationsanleitung 3M Helth Information Systems 3M KAPS PEPP Simulation Installationsanleitung 3 Funktionsweise der KAPS-PEPP-Simulation Die Simulation arbeitet nach dem Client-Server-Prinzip, d.h. neben der Installation

Mehr

BPM und egpm. Prozessbasierte Anforderungsanalyse, Fallstudie bei einem Kommunikationsunternehmen. Thorsten Fiege (Pegasystems) & Kai Meyer (C1 WPS)

BPM und egpm. Prozessbasierte Anforderungsanalyse, Fallstudie bei einem Kommunikationsunternehmen. Thorsten Fiege (Pegasystems) & Kai Meyer (C1 WPS) BPM und egpm Prozessbasierte Anforderungsanalyse, Fallstudie bei einem Kommunikationsunternehmen Thorsten Fiege (Pegasystems) & Kai Meyer (C1 WPS) C1 WPS GMBH //// Vogt-Kölln-Str. 30 //// 22527 HAMBURG

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

Bitte beachten Sie beim Update einer Client / Server Version die Checkliste zum Update

Bitte beachten Sie beim Update einer Client / Server Version die Checkliste zum Update Hinweise zum Update Es gibt verschiedene Möglichkeiten ein pixafe System zu aktualisieren, die vorliegenden Hinweise helfen dabei neue Versionen zu finden und diese zu installieren. Dabei werden verschiedene

Mehr

Lokales DS-VDR-Tool Instalationshandbuch

Lokales DS-VDR-Tool Instalationshandbuch Lokales DS-VDR-Tool Instalationshandbuch v12.0 [Revisionsdatum: 15. Oktober 2012] Seite: 1 Annahmen Es wird folgendes hinsichtlich der Leserschaft dieses Dokuments angenommen: Kenntnisse: Der Anwender

Mehr

GEVER-Standards und die Herausforderungen an die Anforderungsbeschreibung

GEVER-Standards und die Herausforderungen an die Anforderungsbeschreibung Bundeskanzlei BK GEVER Bund GEVER-Standards und die Herausforderungen an die Anforderungsbeschreibung 15. März 2013 Zielsetzung der Präsentation Sie erhalten einen Überblick über den Stand der Entwicklung

Mehr

Prozesskette Funktionsdaten und Funktionsmodelle

Prozesskette Funktionsdaten und Funktionsmodelle Prozesskette Funktionsdaten und Funktionsmodelle Stuttgart, 11. Februar 2015 D. Ruschmeier 2/15 Wesentliche Eingangsparameter für die funktional-basierten Berechnungsverfahren sind: Anforderungs-, Modellbeschreibungen

Mehr

Erweiterung für Premium Auszeichnung

Erweiterung für Premium Auszeichnung Anforderungen Beliebige Inhalte sollen im System als Premium Inhalt gekennzeichnet werden können Premium Inhalte sollen weiterhin für unberechtigte Benutzer sichtbar sein, allerdings nur ein bestimmter

Mehr

Konzept / Architektur Diagramme

Konzept / Architektur Diagramme Architektur-Modell Konzept / Architektur Diagramme Im Übergang Analyse Design wird das System konzipiert und seine Architektur entworfen: Subsystem-Modell (execution view) UML 1.x Package Diagram «subsystem»

Mehr

IBM SPSS Statistics Version 22. Installationsanweisungen für Windows (Lizenz für gleichzeitig angemeldete Benutzer)

IBM SPSS Statistics Version 22. Installationsanweisungen für Windows (Lizenz für gleichzeitig angemeldete Benutzer) IBM SPSS Statistics Version 22 Installationsanweisungen für Windows (Lizenz für gleichzeitig angemeldete Benutzer) Inhaltsverzeichnis Installationsanweisungen....... 1 Systemanforderungen........... 1

Mehr

PTV MAP&GUIDE INTRANET WAS IST NEU?

PTV MAP&GUIDE INTRANET WAS IST NEU? PTV MAP&GUIDE INTRANET WAS IST NEU? Inhalt Inhalt 1 Was bietet Ihnen das neue PTV Map&Guide intranet?... 3 2 Was ändert sich bei der Lizenzierung?... 3 2.1 Sie haben eine Standard-Lizenz map&guide intranet

Mehr

Management Plattform für Private Cloud Umgebungen. Daniel J. Schäfer Client Technical Professional Cloud & Smarter Infrastructure IBM SWG

Management Plattform für Private Cloud Umgebungen. Daniel J. Schäfer Client Technical Professional Cloud & Smarter Infrastructure IBM SWG Management Plattform für Private Cloud Umgebungen Daniel J. Schäfer Client Technical Professional Cloud & Smarter Infrastructure IBM SWG Neue Aufgaben im virtualisierten Rechenzentrum Managen einer zusätzlichen

Mehr

Design im Softwareentwicklungsprozess. Stand der Dinge & Designziel. fachliche & technische Architektur. generelles Vorgehen bei Grob-Design

Design im Softwareentwicklungsprozess. Stand der Dinge & Designziel. fachliche & technische Architektur. generelles Vorgehen bei Grob-Design Design im Softwareentwicklungsprozess traditionell Geschäftsprozessmodellierung Requirements Engineering Analyse Design Implementierung Tests Design 1 test-getrieben: nur 1. Design top-down hier testgetrieben

Mehr

init.at informationstechnologie GmbH Tannhäuserplatz 2/5.OG 1150 Wien Austria

init.at informationstechnologie GmbH Tannhäuserplatz 2/5.OG 1150 Wien Austria init.at informationstechnologie GmbH Tannhäuserplatz 2/5.OG 1150 Wien Austria Seite 2 von 10 1 Inhaltsverzeichnis 2 Warum CORVUS by init.at... 3 3 Ihre Vorteile durch CORVUS... 3 4 CORVUS Features... 4

Mehr

IBM SPSS Collaboration and Deployment Services (C&DS) version 7

IBM SPSS Collaboration and Deployment Services (C&DS) version 7 Dieses Handbuch richtet sich an Systemadministratoren, die IBM SPSS Modeler Entity Analytics (EA) für die Ausführung mit einem der folgenden Produkte konfigurieren: IBM SPSS Collaboration and Deployment

Mehr

2.Strukturdiagramme. 2.5 Das Komponentendiagramm 2.6 Das Verteilungsdiagramm. Prof. Mario Jeckle

2.Strukturdiagramme. 2.5 Das Komponentendiagramm 2.6 Das Verteilungsdiagramm. Prof. Mario Jeckle 2.5 Das Komponentendiagramm 2.6 Das Verteilungsdiagramm Prof. Mario Jeckle Fachhochschule Furtwangen mario@ http://www. Fachhochschule Furtwangen, Sommersemester 2004 Das Komponentendiagramm Dient Darstellung

Mehr

Test. Dipl. Wirtsch. Ing. Alexander Werth 9-1

Test. Dipl. Wirtsch. Ing. Alexander Werth 9-1 Test Dipl. Wirtsch. Ing. Alexander Werth 9-1 Phasen der Problemdefinition Anforderungsanalyse Spezifikation Entwurf Implementation Erprobung Wartung Methoden der 9-2 Software Test / Erprobung Messen der

Mehr

1. Installation und Inbetriebnahme pcon.update

1. Installation und Inbetriebnahme pcon.update Manual pcon.update 1. Installation und Inbetriebnahme pcon.update Unter nachfolgendem Link können Sie die erforderliche Software pcon.update herunterladen. ftp://ftpdownload:download-9200@ftp.weber-os.ch/download/pcon/update/p-up-

Mehr

crm-now/ps Anwenderhandbuch für die Thunderbird Erweiterung Zweite Ausgabe

crm-now/ps Anwenderhandbuch für die Thunderbird Erweiterung Zweite Ausgabe crm-now/ps Anwenderhandbuch für die Thunderbird Erweiterung Zweite Ausgabe crm-now/ps: Copyright 2006 crm-now Versionsgeschichte Version 02 08.09.2006 Release Version Version 01 16.06.2005 crm-now c/o

Mehr

Modul Software Komponenten Deployment

Modul Software Komponenten Deployment Modul Software Komponenten Deployment Roland Gisler Inhalt 1. Übersicht: Deployment 2. Wann wird Deployed? 3. Was umfasst das Deployment? 4. Releases und Versionierung 5. Beispiele: Open Source -Projekte

Mehr

DWA KVR Expert Betriebshandbuch

DWA KVR Expert Betriebshandbuch DWA KVR Expert Betriebshandbuch Stand Release V1.0.1.0 10.07.2012 Autoren: Dipl.Inf. Peter Zuppa (Sydro Software GbR) Inhaltsverzeichnis 2 Inhalt Kapitel 1: Installation... 3 Voraussetzung... 4 Berechtigungen...4

Mehr

4 Planung von Anwendungsund

4 Planung von Anwendungsund Einführung 4 Planung von Anwendungsund Datenbereitstellung Prüfungsanforderungen von Microsoft: Planning Application and Data Provisioning o Provision applications o Provision data Lernziele: Anwendungen

Mehr

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

Mehr

Integration des Troubleticketsystems OTRS bei einem mittelständischen Unternehmen

Integration des Troubleticketsystems OTRS bei einem mittelständischen Unternehmen Integration des Troubleticketsystems OTRS bei einem mittelständischen Unternehmen Präsentation meiner Diplomarbeit Felix J. Ogris fjo@ogris.de 6. Februar 2008 Felix J. Ogris Integration von OTRS 6. Februar

Mehr

1 YAWL Yet Another Workflow Language

1 YAWL Yet Another Workflow Language 1 YAWL Yet Another Workflow Language Das YAWL Workflow-Management-System wurde von Wil van der Aalst und seinem Team an der Eindhoven University of Technology entwickelt. Das System ist in seiner jetzigen

Mehr

IBM SPSS Statistics Version 22. Installationsanweisungen für Mac OS (Lizenz für gleichzeitig angemeldete Benutzer)

IBM SPSS Statistics Version 22. Installationsanweisungen für Mac OS (Lizenz für gleichzeitig angemeldete Benutzer) IBM SPSS Statistics Version 22 Installationsanweisungen für Mac OS (Lizenz für gleichzeitig angemeldete Benutzer) Inhaltsverzeichnis Installationsanweisungen....... 1 Systemanforderungen........... 1

Mehr

INHALT 1. INSTALLATION DES V-MODELL XT UNTER WINDOWS 7 2. INSTALLATION DES V-MODELL XT UNTER WINDOWS VISTA

INHALT 1. INSTALLATION DES V-MODELL XT UNTER WINDOWS 7 2. INSTALLATION DES V-MODELL XT UNTER WINDOWS VISTA INHALT 1. INSTALLATION DES V-MODELL XT UNTER WINDOWS 7 2. INSTALLATION DES V-MODELL XT UNTER WINDOWS VISTA 1. INSTALLATION DES V-MODELL XT UNTER WINDOWS 7 VORBEDINGUNGEN Als Vorbedingungen sollte bereits

Mehr

QCfetcher Handbuch. Version 1.0.0.10. Ein Zusatztool zum QuoteCompiler. Diese Software ist nur für private und nicht-kommerzielle Zwecke einzusetzen.

QCfetcher Handbuch. Version 1.0.0.10. Ein Zusatztool zum QuoteCompiler. Diese Software ist nur für private und nicht-kommerzielle Zwecke einzusetzen. Seite 1 QCfetcher Handbuch Ein Zusatztool zum QuoteCompiler Diese Software ist nur für private und nicht-kommerzielle Zwecke einzusetzen. Die neuesten Informationen gibt es auf der Webseite: http://finanzkasper.de/

Mehr

MVB3. Einrichten eines Servers für MVB3 ab Version 3.5. Admin-Dokumentation. Inhalt V3.05.001

MVB3. Einrichten eines Servers für MVB3 ab Version 3.5. Admin-Dokumentation. Inhalt V3.05.001 V3.05.001 MVB3 Admin-Dokumentation Einrichten eines Servers für MVB3 ab Version 3.5 Inhalt Organisatorische Voraussetzungen... 1 Technische Voraussetzungen... 1 Konfiguration des Servers... 1 1. Komponenten

Mehr

Informationsbroschüre

Informationsbroschüre Informationsbroschüre Überwachung, Lastverteilung, automatische Aufgaben für Microsoft Dynamics NAV Mit IT IS control 2011 können Sie viele Mandanten und NAV-Datenbanken praktisch gleichzeitig mit wenigen

Mehr

A1 Desktop Security Installationshilfe. Symantec Endpoint Protection 12.1 für Windows/Mac

A1 Desktop Security Installationshilfe. Symantec Endpoint Protection 12.1 für Windows/Mac A Desktop Security Installationshilfe Symantec Endpoint Protection. für Windows/Mac Inhalt. Systemvoraussetzung & Vorbereitung S. Download der Client Software (Windows) S. 4 Installation am Computer (Windows)

Mehr

Rollen- und Rechtekonzept

Rollen- und Rechtekonzept Inhaltsverzeichnis Rollen- und Rechtekonzept 1. Ziele...1 2. Konzeption zur Realisierung durch Access Control List und im Management-Interface...2 2.1. Ansatz...2 2.2. Safety oder Security...2 2.3. User-

Mehr

Scheinaufgabe im Fach Web Engineering

Scheinaufgabe im Fach Web Engineering Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut für Verteilte Systeme Scheinaufgabe im Fach Web Engineering Thomas Thüm 07. August 2006 Matrikel: 171046 Lehrveranstaltung: Web

Mehr

Eigenen WSUS Server mit dem UNI WSUS Server Synchronisieren

Eigenen WSUS Server mit dem UNI WSUS Server Synchronisieren Verwaltungsdirektion Informatikdienste Eigenen WSUS Server mit dem UNI WSUS Server Synchronisieren Inhaltsverzeichnis Einleitung... 3 Installation WSUS Server... 4 Dokumente... 4 Step by Step Installation...

Mehr

PRÜFUNG. Grundlagen der Softwaretechnik

PRÜFUNG. Grundlagen der Softwaretechnik Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner PRÜFUNG Grundlagen der Softwaretechnik Musterlösung Name: Matrikelnummer: Note: Prüfungstag:

Mehr

Ein XML-basiertes Dokumentenmodell für eine langfristige Archivierung intelligenter Dokumente

Ein XML-basiertes Dokumentenmodell für eine langfristige Archivierung intelligenter Dokumente Ein XML-basiertes Dokumentenmodell für eine langfristige Archivierung intelligenter Dokumente Christoph Bernhardt memiq AG Hans-Pinsel-Straße 10a 85540 Haar christoph.bernhardt@memiq.de Abstract: memiq

Mehr

IBM SPSS Modeler Entity Analytics - Erweiterte Konfiguration

IBM SPSS Modeler Entity Analytics - Erweiterte Konfiguration IBM SPSS Entity Analytics - Erweiterte Konfiguration Einführung Die vorgesehene Zielgruppe für dieses Handbuch sind Systemadministratoren, die IBM SPSS Entity Analytics (EA) für die Ausführung in einer

Mehr

5 Installation hypercad

5 Installation hypercad 5 Installation hypercad 5 Administrator-Handbuch Zusammenfassung Dieses Dokument beschreibt aus Sicht eines Administrators, wie hypermill zu installieren und konfigurieren ist. Zum besseren Verständnis

Mehr

Kurzbeschreibung PC-Software für das Gerät URO-2050

Kurzbeschreibung PC-Software für das Gerät URO-2050 Kurzbeschreibung PC-Software für das Gerät URO-2050 1 Einleitung 1.1 Allgemeines Das Programm kann zum Verwalten der durchgeführten Untersuchungen mit dem Gerät URO-2050 benutzt werden. Es funktioniert

Mehr

Dynamische Plug-ins mit Eclipse 3. Martin Lippert (martin.lippert@it-agile.de, www.it-agile.de) Tammo Freese (freese@acm.org)

Dynamische Plug-ins mit Eclipse 3. Martin Lippert (martin.lippert@it-agile.de, www.it-agile.de) Tammo Freese (freese@acm.org) Dynamische Plug-ins mit Eclipse 3 Martin Lippert (martin.lippert@it-agile.de, www.it-agile.de) Tammo Freese (freese@acm.org) Überblick Die Ausgangslage Dynamische Plug-ins Warum? Eclipse 3 Die OSGi-basierte

Mehr

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges Komponentenbasierte Client-Architektur Hamburg, 16.11.2007 Bernd Olleck IT-Beratung Olleck Agenda Clients aus drei verschiedenen Perspektiven: Technische Infrastruktur Fachliche Sicht Aufgaben eines Clients

Mehr

Version 1.0 Erstellt am 12.12.2014 Zuletzt geändert am 17.12.2014. Gültig für Release 1.0.0.0

Version 1.0 Erstellt am 12.12.2014 Zuletzt geändert am 17.12.2014. Gültig für Release 1.0.0.0 Version 1.0 Erstellt am 12.12.2014 Zuletzt geändert am 17.12.2014 Gültig für Release 1.0.0.0 Inhalt 1 WebPart Site Informationen 3 1.1 Funktionalität 3 1.2 Bereitstellung und Konfiguration 4 2 WebPart

Mehr

App-Entwicklung für Android

App-Entwicklung für Android App-Entwicklung für Android Einleitung - Systemarchitektur Hochschule Darmstadt WS15/16 1 Inhalt Historie Systemarchitektur Sandbox 2 Motivation Kontra Pro Limitierte Größe Begrenzte Ressourcen Kein Standardgerät

Mehr

Eine Taxonomie und Bewertung von Cloud Computing Diensten aus Entwicklersicht

Eine Taxonomie und Bewertung von Cloud Computing Diensten aus Entwicklersicht Eine Taxonomie und Bewertung von Cloud Computing Diensten aus Entwicklersicht Universität der Bundeswehr München Mario Golling und Michael Kretzschmar Fakultät für Informatik E-Mail: mario.golling@unibw.de

Mehr