TU Wien:Advanced Internet Computing VU (Dustdar)

Aus VoWi
Zur Navigation springen Zur Suche springen
Diese Lehrveranstaltung hat möglicherweise starke Emotionen bei den TeilnehmerInnen hinterlassen. Daher sind zusätzliche Fakten und Meinungen besonders erwünscht, um den Artikel zu verbessern. Weitere Hintergründe findest du eventuell auf der Diskussionsseite. Flames und ähnliches bitte auch dort.


Daten[Bearbeiten | Quelltext bearbeiten]

Vortragende Schahram Dustdar• Pantelis Frangoudis• Alireza Furutanpey• Philipp Alexander Raith
ECTS 3,0
Letzte Abhaltung 2024W
Sprache English
Mattermost advanced-internet-computing • Register • Mattermost-Infos
Links tiss:184269
Zuordnungen
Masterstudium Business Informatics Modul ISE/COR - Information Systems Engineering Core (Gebundenes Wahlfach)
Masterstudium Software Engineering & Internet Computing Modul Internet Computing and Distributed Systems Technologies (Pflichtfach)


Inhalt[Bearbeiten | Quelltext bearbeiten]

  • Service Oriented Computing und Service-oriented Architectures
  • Enterprise Application Integration und Middleware
  • Web services - Foundations, Architecures and Standards (SOAP, WSDL, UDDI)
  • Web services Composition and Workflows (e.g., BPEL, WS-Coordination, WS-Transaction, BPML, WSCI etc.)
  • Cloud Computing

Der Titel der Lehrveranstaltung ist eigentlich zu allgemein, besser wäre "Web Service Computing" gewesen, weil es fast nur um Web Services geht.

Ablauf[Bearbeiten | Quelltext bearbeiten]

Geblockte Vorlesung mit insgesamt sechs Vorlesungsterminen. Dazu ein Projekt, das in Gruppen zu fünft gelöst werden muss.

Benötigte/Empfehlenswerte Vorkenntnisse[Bearbeiten | Quelltext bearbeiten]

Programmieren und Verteilte Systeme. Software Architekturen und E-Commerce Technologien behandeln ähnlichen Inhalt mit etwas anderem Fokus.

Vortrag[Bearbeiten | Quelltext bearbeiten]

Vortrag ist nicht schlecht, manchmal wird zu schnell über die Folien hinweg gegangen.

Übungen[Bearbeiten | Quelltext bearbeiten]

Es gibt 5 Topics - jede Gruppe (bis zu 5 Personen) muss ein solches Topic lösen. Der eigentliche Aufwand ist wohl die Koordination einer Gruppe von vier bis fünf Leuten und die Planung des Systems. Alles in allem aber deutlich weniger Aufwand als in den letzten Semestern (habe ich gehört :) ) und einigermaßen interessant ist es auch.

Im WS 2014 waren die Topics:

  • Sentiment Analysis – Analyze the "general feeling" expressed in tweets
  • Cloud-based RAID Storage – Replicate files in the cloud
  • Cloud-based Onion Routing - Provide a Cloud-based anonymization approach
  • Analysing Big Data - Identifying relationships in a social network
  • Service Composition - Integrate several services and assess their QoS

Im WS 2016 waren die Topics:

  • Stream Processing – Implement a stream processing topology and populate a dashboard in real-time.
  • Cloud-based RAID Storage – Build a redundant cloud storage via a RAID like middleware
  • Cloud-based Onion Routing - Develop a cloud-based anonymity solution
  • Docker-based Service Composition - Build a fault tolerant service composition that integrates different web services

Im WS 2020 waren die Topics:

  • Stream Processing for Spatially-Distributed IoT Systems – Implement a stream processing topology and populate a dashboard in real-time.
  • Federated Storage Infrastructure for IoT Sensor Data – Build a federated cloud storage solution for the IOT.
  • Intelligence at the Edge Using Distributed Learning - Implement a decentralized system for training Machine Learning models on edge devices.
  • Securing IoT Networks with Onion Routing - Develop a cloud-based anonymity solution which implements some basic functionalities of onion routing.

Im WS 2021 warden die Topics identisch zu jenen vom WS 2020. Es ist zu beachten, dass uns die "Submission Guidelines" erst ca. 2 Wochen vor der Abgabe zur Verfügung gestellt wurden und zusätzliche Anforderungen bzgl. der Implementierung enthielten, die uns vorher nicht mitgeteilt wurden. Es wäre daher von Vorteil, wenn die Studierenden dieses Dokument im Voraus anfordern würden, um nicht überrascht zu werden. Weiters gibt es jedoch auch noch versteckte Anforderungen, die erst nach Beurteilung der Implementierung offenbart werden.

Im WS 2023 waren die Topics:

  • Stream Processing for Spatially-Distributed IoT Systems – Implement a stream processing topology and populate a dashboard in real-time.
  • Cloud-Native Development - Implement a serverless/cloud-native application using a local emulation of AWS.
  • Microservice Architecture for Scalable Remote Sensing - Implement a microservice architecture with classification and storage for images.
  • Securing IoT Networks with Onion Routing - Develop a cloud-based anonymity solution which implements some basic functionalities of onion routing.


Prüfung, Benotung[Bearbeiten | Quelltext bearbeiten]

Schriftlich, keine Unterlagen erlaubt, 60 Minuten Zeit. Offene Fragen. Es gibt zwei Termine, einen Haupttermin im Jänner und einen Nebentermin im März.

Benotung ist sehr fair. Wenn man den Haupttermin geschrieben hat, kann man den Nebentermin auch wahrnehmen, das bessere Ergebnis zählt. Aufgrund von COVID-19 wurde der Nebentermin verschoben, ich habe die Prüfung im Büro von Herrn Frangoudis schreiben dürfen was mir aufgrund von Stipendien sehr geholfen hat.

WS2023: Prüfung war online in Tuwel und open-book. Wurde einmal eine Frage beantwortet, konnte man nicht mehr zurückgehen und sie bearbeiten. Ein paar Rechenaufgaben waren dabei, die mehr Punkte gaben, ansonsten Single-Choice und Multiple-Choice Theoriefragen.

Die Prüfung ist optional falls im Übungsteil schon genug Punkte erreicht wurden (>=50)

Für Prüfungsordner siehe Materialien.

Dauer der Zeugnisausstellung[Bearbeiten | Quelltext bearbeiten]

  • WS09: Prüfung am 25.01.2010, Zeugnis erhalten am 24.02.2010 (ca. 1 Monat), wobei die Testergebnisse schon zwei Tage nach dem Test bekanntgegeben wurden.
  • WS13: 1. Nebentermin: Note erfahren nach ca. 2 Wochen, Zeugnis nach 3 Wochen.
  • WS14: Prüfung am 12.12.2014, E-Mail mit Note nach ca. 2 Wochen. Finale Präsentation am 28.01.2015, E-Mail mit Gesamtnote am 02.03.2015, Zeugnis am 11.03.2015

Zeitaufwand[Bearbeiten | Quelltext bearbeiten]

  • Eigentlich ganz ok, wenn man ein gutes Team hat. Dennoch sollten man je nach Topic den Programmieraufwand nicht unterschätzen. Ein paar Tage (bzw. Nächte) sind schnell mal vorbei.
    • Andere Meinung: Mittlerer Zeitaufwand, es kommt sehr stark auf die Vorkenntnisse an.
  • Prüfungsvorbereitung: ca. 2-3 Tage
    • Andere Meinung: Man lasse sich nicht von den "zwei Tagen" die hier empfohlen werden verleiten. Damit es kein Glücksspiel ist sollte man 4 Tage vorher anfangen, ansonsten wird das Lernen sehr stressig.
    • Andere Meinung (WS13): Ich habe 40 Stunden vor Prüfungsbeginn begonnen zu lernen, dann aber intensiv (ca. 20 Stunden reine Lernzeit). Ich habe einmal alle Folien auf Verständnis gelesen, dann noch einmal durchgegangen und die wichtigsten Überschriften notiert, und dann nocheinmal durchgegangen und zu diesen Überschriften die wichtigsten Stichwörter notiert. Wichtige Auflistungen auswendig gelernt. Ein paar POs überflogen. Note: S1 (Prüfung am 1. Nebentermin am 10.03.2014). Die Vorlesung habe ich kaum besucht, ein paar Vorkenntnisse (HTL und Arbeit mit REST) hatte ich. Die Übungen waren mittlerer Zeitaufwand.
  • Je nach Minimalismus und Perfektionismus bewegt sich der Aufwand für eine positive Note wohl zwischen 5 h (Altfragen lernen) und 40 h (Folien detailiert lernen) für die Prüfung. Die Prüfung ist aber nicht zu detailiert und weißt einen gewissen Wiederholungseffekt auf.
  • WS21: Insbesondere der erste Teil (Thema: Federated Storage Infrastructure for IoT Sensor Data) war nicht sehr aufwändig, wir haben damit in der Woche vor der ersten Präsentation begonnen und hatten bis auf einige Kleinigkeiten keinen Stress. Der reine Programmieraufwand wird pro Teammitglied bei ~20h liegen.

Unterlagen[Bearbeiten | Quelltext bearbeiten]

Folien im TUWEL verfügbar.

Tipps[Bearbeiten | Quelltext bearbeiten]

  • WS23: Der Machine Learning Topic ist irgendwie das Lieblingskind des Professors und deshalb fragte er diese Gruppe bei der Abschlusspräsentation auch einige Theoriefragen dazu. Ansonsten stellen sie beim Q&A nur 1-2 kleinere Fragen, wenn das Ding ausschaut als wärs korrekt fertig implementiert worden. Auch die Zwischenpräsentation ist sehr entspannt, sie wird nicht benotet und ist eigentlich ziemlich unnötig meiner Meinung nach. Bei Problemen dem Tutor schreiben, er kann einem echt weiterhelfen und antwortet sehr schnell.
  • WS21: An dem Frontend unserer finalen Lösung wurde nicht wirklich etwas angemerkt. Es sollte aber unbedingt sehr genau auf die Anforderungen geachtet werden und bei Unsicherheiten auch gleich nachfragen, um nicht unnötig Punkte zu verlieren. Wir haben uns nämlich auf eine Aussage im TUWEL-Forum verlassen, wonach bei unserem Topic nach einer Bild Recovery in dem Federated Storage das Bild im Frontend nicht unbedingt mehr als fehlerhaft angezeigt werden muss. Eben dieser Aspekt wurde dann im finalen Feedback bemängelt. Für die Prüfung im Online-Modus reicht grundsätzlich einmaliges Durchgehen der Folien, da die Prüfung ohnehin sehr auf Verständnis und Verknüpfung des Stoffes ausgelegt ist. Wichtig sind vor allem auch Rechenbeispiele, da diese einfach sind und dennoch viele Punkte bringen.
  • WS20: Die Anmerkung aus dem WS19 möchte ich mit meiner Erfahrung noch erweitern: Auch wenn das Backend perfekt funktioniert (laut Tutor "bestes Deployment" und keine Fehler) und das Frontend alles Geforderte richtig macht, gut aussieht und noch zusätzliche Usability-Funktionen hat, werden bei kleinen Usability-Problemen enorm viele Punkte abgezogen. So wurden uns 15% (!!) der Punkte für ein Fehlverhalten eines (von mehreren funktionierenden) zusätzlichen, nicht geforderten Usability-Features abgezogen. Empfehlung: Keine gut gemeinten Zusatz-Features einbauen, denn diese haben keinesfalls positive, sondern ausschließlich negative Auswirkungen.
  • WS19: Ein Großteil der Bewertung des Übungsteils basiert auf dem Frontend der jeweiligen Aufgabe, ob das fair ist sei dahin gestellt, jedoch ist es enorm wichtig ein ordentliches Frontend zusammenzubauen. Selbst wenn das Backend perfekt ist werden bei einem rudimentären Frontend gerne mal 30% abgezogen, oftmals auf Grund von Usability-Schwachstellen und nicht wie man annehmen würde durch technische Fehler.
  • Bei der Stream-Processing Aufgabe sollte man nicht!! auf Trident State setzen und stattdessen eigenes State Management mit Redis implementieren. Ist deutlich einfacher weil Trident State nicht dokumentiert ist. Wir hatten sehr große Probleme mit den Spouts und Storm UI gehabt weil Trident State eigene Spouts hat.
  • Frühzeitig mit der Aufgabe beginnen.
  • Falls Amazon Webservices eingesetzt werden (muss), darauf achten, dass in der Region "Frankfurt" nur wenige Instanzen erzeugt werden können (WS-2014). Das kann je nach Topic zu unnötigem Stress führen.

Highlights / Lob[Bearbeiten | Quelltext bearbeiten]

noch offen

Verbesserungsvorschläge / Kritik[Bearbeiten | Quelltext bearbeiten]

  • WS22: Die Themenvergabe war enorm undurchdacht, und man sollte sich keinesfalls darauf verlassen, dass das bevorzugte Thema auch tatsächlich zugewiesen wird (selbst wenn man das einzige Team ist, das dieses Thema anfragt; "This is an unfortunate side effect of the online format"). Inhaltlich ist vor allem das Thema mit dem Stream-Processing schlecht durchdacht und noch schlechter spezifiziert. Dazu wurde wiederholt angemerkt, dass das Thema "nächstes Semester überarbeitet wird". Inhaltlich ist das Projekt für 5 Personen viel zu schmal, und könnte leicht zu dritt oder gar alleine gelöst werden. Der Vorlesungsteil, der von Dustdar präsentiert wird ist ein einziger Buzzword-Salat, und hat inhaltlich quasi nichts zu bieten. Vorlesungen von Frangoudis sind allerdings gut strukturiert und man hat die Chance zumindest irgendetwas mitzunehmen.
    • Es wurde mehrmals kommuniziert, dass die Studis sich selber organisieren sollen bei der Themenverteilung. Falls man das Wunschthema nicht gekriegt hat, liegt das nicht an der LVA organisation. Das der Inhalt zu schmal ist, stimme ich zu, aber es gibt genug orte wo es möglich ist mehr als das minimum zu machen was auch einen guten Lerneffekt hat.
  • WS20: Die Benotung des Projekts (der Lösung an sich) scheint keinem vorgegebenem Schema zu folgen. Es wäre sinnvoll, das Punkteschema transparent zu gestalten, sodass klar ist, worauf wert gelegt wird und es zu keinen Unstimmigkeiten kommt. Dasselbe gilt für die Präsentation. Auch auf Nachfrage gibt es kein Feedback zur Endpräsentation. Die Begründung für die Punktevergabe ist: "Wir haben das einstimmig so entschieden"
  • WS21: Generell legt die LVA großen Wert auf die Präsentation der Ergebnisse. Die vorgegebene Zeit muss exakt eingehalten werden. Es gab Feedback zur Zwischenpräsentation, die jedoch nicht beurteilt wurde. Für die Endpräsentation gibt es kein Feedback. Es ist daher nicht klar, wieso bei dieser Punkte abgezogen wurden. Ferner gibt es – wie bereits von anderen Studierenden erwähnt wurde – versteckte Anforderungen, die zuvor nicht kommuniziert werden. Bei Bewertung der Implementierung werden dann Punkte für Nicht-Einhaltung dieser Anforderungen abgezogen, obwohl alle den Studierenden bekannten Anforderungen korrekt umgesetzt wurden. Beispiele für Thema "Intelligence at the Edge Using Distributed Learning": Die einzelnen "Worker" müssen in separaten Docker Container laufen. Es ist nicht erlaubt, dass innerhalb eines Docker Containers alle "Worker" laufen. Ferner muss es möglich sein, dass "Worker" nach einem Neustart des Workers am Training teilnehmen können. Schließlich soll auch auf die Input-Validierung von Textfeldern geachtet werden und die einzugebenden Werte müssen erklärt werden.
  • Die Folien von Dustdar sind leider eine schwach zusammenhängende Orgie von Stockfotos und Zusammenfassungen von eigenen Papers. Das Signal unter dem ganzen Rauschen zu finden ist jedenfalls äußerst mühsam. Man kann nur dankbar darüber sein, dass die Prüfung relativ oberflächlich ist und sich auf die grundlegenden Dinge beschränkt. Die Folien von Scekic wiederum sind überdurchschnittlich gut. Es gibt einen roten Faden und man merkt, dass er sich etwas Mühe gegeben hat und die Inhalte nachvollziehbar aufbereitet hat. Generell kann man sich den Vorlesungsbesuch aber sparen.
  • Die Übung (also das Projekt) findet ja in Gruppen zu fünft statt, was dem Umfang nicht gerecht wird. Drei Leute pro Gruppe wären vollkommen ausreichend, so wird nur der Koordinationsaufwand innerhalb der Gruppe erhöht und eine faire Aufteilung schwieriger.
  • Der Ton während der Pflichttermine wechselt zwischen aggressiv, herablassend und inkohärentem Geschwätz ohne Sinn und Zweck. Die halbbackenen, unfertigen und im Allgemeinen sehr stumpfen Angaben geben die Illusion, bei der Ausführung wird viel Freiheit gegeben. Tatsächlich gibt es viele versteckte Anforderungen die nicht kommuniziert werden. Wenn diese nicht erfüllt sind, sind die Professoren zutiefst beleidigt und verstehen es als persönlichen Angriff, der zu passiv aggressiven Rückmeldungen führt.
  • Die Verantwortlichen scheinen sehr genaue Vorstellungen zu haben haben, wie die Aufgabe zu erledigen ist, sind sich aber aber in keinster Weise einig darüber. Unpraktisch. So kann es passieren, dass Tutoren Features genau ausspezifizieren, die von den Professoren anders interpretiert werden.
  • Eine Methode zur Ermittlung der genauen Anforderungen war erfolgreich:
    • Bei Unklarheiten ein Brainstorming veranstalten.
    • Von den aufkommenden Interpretationsmöglichkeiten wird diejenige ausgewählt, die am wenigsten sinnvoll erscheint.
    • Diese teilen mit hoher Wahrscheinlichkeit die meisten Benoter.
Abgerufen von „https://vowi.fsinf.at/index.php?title=TU_Wien:Advanced_Internet_Computing_VU_(Dustdar)&oldid=189478“