TU Wien:Advanced Internet Computing VU (Dustdar)

From VoWi
Jump to navigation Jump to search
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[edit]

Lecturers Schahram Dustdar, Ognjen Scekic
ECTS 3
Department DSG
When winter semester
Links tiss:184269, Homepage
Zuordnungen
Master Business Informatics Wahlmodul Distributed Systems
Master Software Engineering & Internet Computing Pflichtmodul Internet Computing and Distributed Systems Technologies

Mattermost: Channel "advanced-internet-computing" Team invite & account creation link Mattermost-Infos

Inhalt[edit]

  • 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[edit]

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

Benötigte/Empfehlenswerte Vorkenntnisse[edit]

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

Vortrag[edit]

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

Übungen[edit]

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

Prüfung, Benotung[edit]

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.

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

Für Prüfungsordner siehe Materialien.

Dauer der Zeugnisausstellung[edit]

  • 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[edit]

  • 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.

Unterlagen[edit]

Folien im TUWEL verfügbar.

Tipps[edit]

  • 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.

Verbesserungsvorschläge / Kritik[edit]

  • 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.