Skip to content
This repository has been archived by the owner on Feb 23, 2021. It is now read-only.

Latest commit

 

History

History
59 lines (44 loc) · 4.69 KB

README.md

File metadata and controls

59 lines (44 loc) · 4.69 KB
Raw

component-runtime-environment

About

Development of a component runtime environment for a semester project at the university.

Underlying Exercises

Exercise 2

  • FA1: Der Component Assembler muss die Laufzeitumgebung starten können.
  • FA2: Der Component Assembler muss die Laufzeitumgebung stoppen können.
  • FA3: Der Component Assembler muss neue Komponenten aus einem lokalen Verzeichnis des Rechners in die Laufzeitumgebung einsetzen (deployen) können.
  • FA4: Der Component Assembler muss eingesetzte Komponenten in der Laufzeitumgebung ausführen können. Eine Start-Methode sollte dabei mit Hilfe einer Annotation im Rahmen eines Komponentenmodells definiert werden.
  • FA5: Der Component Assembler soll mehrere Komponenten gleichzeitig (parallel) ausführen können.
  • FA6: Der Component Assembler muss in der Lage sein, die Status der aktuell eingesetzten Komponenten über die Laufzeitumgebung abzurufen. Ein Status sollte pro Komponente folgendes beinhalten: Laufende Identifikationsnummer, Name, Zustand.
  • FA7: Der Component Assembler muss Komponenten in der Laufzeitumgebung stoppen können. Auch hierzu sollte das Komponentenmodell eine „entsprechende“ Operation bereitstellen.
  • FA8: Der Component Assembler muss Komponenten aus der Laufzeitumgebung löschen können.

Folgende strukturelle Eigenschaften sollte eine Komponente besitzen:

  • Eine „deploybare“ Komponente entspricht einem .jar-File,
  • Ein .jar-File kann wiederum eine beliebige Menge aus Klassen enthalten. In einem .jar-File muss mindestens eine Klasse enthalten sein.
  • Eine Komponente kann muss ein Meta-File besitzen. / Muss nur ausführbare jars
  • Klassen in einem .jar-File können in Packages angeordnet sein.

Weitere Anforderungen:

  • Deployment von Komponenten (Muss)
  • Lebenszyklus realisieren: start und stop von Komponenten (parallele Ausführung) (Muss)
  • Status-Abfrage einer Komponente (Muss)
  • Fehlerhandling bei Komponenten (Co)
  • LZU muss die Abhängigkeiten auflösen und bereitstellen (Muss) / Test mit Log4J2
  • Konfiguration von Komponenten (Muss) / Name, Id, Status, Annotationen
  • Konflikte auflösen bei Abhängigkeiten (Muss) / Test mit Log4J2
  • Löschen von Komponenten (Muss)
  • Einhalten von Sicherheitsaspekten (Co)
  • Starten einer LZU (Muss)
  • Stoppen einer LZU (Muss)
  • Unabhängigkeit von LZUs (W)
  • Fehlerhandling einer LZU (Co)
  • Verfügbarkeit garantieren von Komponenten (Muss)

Exercise 3

  • CR1: Die aktuelle Konfiguration einer Laufzeitumgebung (welche Komponenten wurden in welcher Reihenfolge eingesetzt) soll stets persistent auf einem externen Server abgespeichert werden, so dass bei einem Absturz der lokalen Laufzeitumgebung der Zustand (= die Konfiguration) der Laufzeitumgebung wiederhergestellt werden kann. Der Zustand einer Komponente braucht nicht gespeichert werden.
  • CR2: Erweitern sie ihre Laufzeitumgebung um einen horizontalen Logging-Dienst, der von ihrer Laufzeitumgebung für alle kompatiblen Komponenten angeboten werden soll. Möchte eine Komponente diesen Dienst verwenden, so muss sie eine typ-konforme Variable in der Start-Klasse (wo @Start-Methode vorhanden) definieren und diese mit einer Annotation versehen (siehe Aufgabe).
  • Die konkrete Implementierung sollte dann auf einer Console folgendes ausgeben: ++++ Runtime-Log: Meldung aus Component: Prozess gestartet ([TimeStamp])
  • Eine Auslagerung der relevanten Konfigurationsdaten auf einen externen Server ist nicht notwendig, das Abspeichern kann in einem lokalen File oder unter Verwendung eines lokalen Datenbanksystems prototypisch erfolgen.

Exercise 5

  • Demonstrieren sie die Machbarkeit anhand einer prototypischen Umsetzung innerhalb ihrer Laufzeitumgebung. Ziel: ihre ausgewiesenen Komponenten (nicht alle Klassen!) sollen sich gegenseitig über Zustandswechseln flexibel informieren können. (Bei der Umsetzung mit DI und Observer-Modell an https://jcp.org/en/jsr/detail?id=299 orientieren.)

Exercise 6

  • Erweitern sie ihre Laufzeitumgebung um eine Funktionalität zur flexiblen Komposition von eingesetzten Komponenten. Orientieren sie sich dabei um die Ideen rund um das Pattern „Dependency Injection“ (Kapitel 4).
  • Führen sie ein Scope-Management in ihre Laufzeitumgebung ein, so dass Referenzen zu konkreten Komponenten abhängig vom Lebenszyklus einer Komponente injiziert werden (siehe Aufgabe).
  • Entwickeln sie ein Web-basiertes Frontend für ihre Laufzeitumgebung, mit der sie wesentliche Befehle ausführen können. Dieses Web-Frontend sollte dabei auf den eingeführten Technologien der Vorlesungen (vgl. Kapitel 5) aufbauen.