TU Wien:Verteilte Systeme VO (Göschka)/Prüfung 2012-06-06

Aus VoWi
Zur Navigation springen Zur Suche springen

1.Openness[Bearbeiten]

Frage: Was versteht man unter "Openness"?

{{#dpl:resultsheader=Diese Frage wurde bereits in folgenden Prüfungen gestellt: |oneresultheader=Diese Frage wurde bereits in der folgenden Prüfung gestellt: |noresultsheader=* Diese Frage wurde noch nie gestellt! |skipthispage=no |shownamespace=false |uses=Vorlage:Kapitel |replaceintitle=/Verteilte Systeme VO \(Göschka\)\/Prüfung/, |include={Kapitel}.dpl |includematch=/\|\s*TU Wien:Verteilte Systeme VO \(Göschka\)\/Fragenkatalog Wiki\s*\|\s*Was versteht man unter "Openness"?\s*/si}}

Ein "Offenes VS" bietet Dienste nach Standardregeln an, die die Syntax und die Semantik dieser Dienste beschreiben.

In VS werden Dienste generell durch Schnittstellen (Interfaces) spezifiziert, die oft in einer Interface Definition Language (IDL) beschrieben sind.

Gute Spezifikationen sind vollständig (alles, was für eine Implementierung erforderlich ist, wurde spezifiziert) und neutral (Spezifikationen schreiben nicht vor, wie eine Implementierung aussehen soll).

Vollständigkeit ist wichtig für Interoperabilität (beschreibt den Grad bis zu dem zwei Implementierungen von Systemen/Komponenten verschiedener Hersteller zusammenarbeiten können, indem sie sich lediglich auf die Dienste der anderen verlassen, die nach einem gemeinsamen Standard spezifiziert sind).

Neutralität ist wichtig für Portabilität (beschreibt, in welchem Ausmaß eine Anwendung, die für VS A entwickelt wurde, ohne Veränderungen auf VS B ausgeführt werden kann, das dieselben Schnittstellen wie A implementiert).

Ein offenes VS sollte auch erweiterbar sein (Hinzufügen/Ersetzen von Komponenten, ohne dass die vorhandenen beeinträchtigt werden) -> Flexibilität

Um in einem offenen VS Flexibilität zu erzielen, sollte es aus kleinen, einfach austauschbaren/anpassbaren Komponenten angeordnet sein -> impliziert, dass nicht nur Definitionen der Schnittstellen der obersten Ebene (die von Benutzern/Anwendungen gesehen werden), sondern auch für Schnittstellen zu den internen Bestandteilen des Systems bereitgestellt werden sollten, und außerdem beschrieben wird, wie diese Bestandteile zusammenarbeiten.


Nötig ist Trennung von Policy (Richtlinie) und Mechanismus!

Eine Definition: Offenheit (Openness): Ein verteiltes System ist ein offenes verteiltes System, wenn neue Dienste zu den bereits existierenden Diensten hinzugefügt werden können, ohne letztere zu Unterbrechen bzw. Dienste zu duplizieren


2.Message-oriented Middelware/Message-Queue[Bearbeiten]

Frage: Was versteht man unter "Message-oriented Middleware MoM"? Erläutern Sie Modell und Architektur solcher "Message-Queueing"-Systeme. Erklären Sie die Primitivoperationen Put, Get, Poll und Notify eines Message-Queuing Systems. Diskutieren Sie Einsatzzwecke sowie Vor- und Nachteile - gehen Sie insbesonders auf den Begriff des Message Brokers und dessen Bedeutung für EAI ein.

{{#dpl:resultsheader=Diese Frage wurde bereits in folgenden Prüfungen gestellt: |oneresultheader=Diese Frage wurde bereits in der folgenden Prüfung gestellt: |noresultsheader=* Diese Frage wurde noch nie gestellt! |skipthispage=no |shownamespace=false |uses=Vorlage:Kapitel |replaceintitle=/Verteilte Systeme VO \(Göschka\)\/Prüfung/, |include={Kapitel}.dpl |includematch=/\|\s*TU Wien:Verteilte Systeme VO \(Göschka\)\/Fragenkatalog Wiki\s*\|\s*Message-oriented Middleware\s*/si}}


MoM bieten Unterstützung für persistente asynchrone Kommunikation. Anwendungen kommunizieren, indem sie ihre Nachricht in eine Message Queue einstellen. Jede Anwendung hat ihre eigene Queue von der sie liest.

Ein Sender einer Nachricht erhält nur eine Garantie, dass die Nachricht irgendwann in die Queue eingefügt wird.


Vorteil: Empfänger kann passiv sein während Sender sendet und umgekehrt (loosly-coupling).

Für das loosely-coupling gibt es 4 Kombinationen:

  • Sender running - Receiver running
  • Sender running - Receiver passive
  • Sender passive - Receiver running
  • Sender passive - Receiver passive


Nachteil: Übertragung kann sich im Minutenbereich abspielen.


Architektur:

MOM Architektur.png

  • Get: blockt solange die Queue leer ist; gibt ansonsten die erste Nachricht zurück
  • Put: hängt eine Nachricht an eine Queue an
  • Poll: Queue nach Nachrichten durchsuchen, gibt die erste Nachricht zurück. Blockt niemals.
  • Notify: installiert einen Handler, der aufgerufen wird, wenn eine Nachricht in die Queue gestellt wird.


MoM erlaubt es loosly-coupled Systems zusammenzuarbeiten. Unterschiedliche Systeme kommunizieren möglicherweise über unterschiedliche Nachrichtenformate, die von anderen Systemen nicht verstanden werden.

Message-Broker und Einsatz in EAI: Der Hauptzweck eines Message-Brokers (MB) ist es, eingehende Nachrichten so umzuwandeln, dass sie von der Zielanwendung verstanden werden können. Zusätzlich zu seiner Hauptaufgabe kann ein Message-Broker jedoch noch andere Aufgaben erfüllen - so wird ein Message-Broker etwa für EAI (Enterprise Application Integration) verwendet. Hierbei handelt es sich um ein sogenanntes Publish/Suscribe-Modell. Hierbei senden Anwendungen Veröffentlichungen zum Thema X an den Broker, der diese Veröffentlichungen dann an andere Anwendungen, die Thema X abonniert haben, weiterleitet. (lt. Verteilte Systeme - Principles and Paradigms (Tanenbaum) Seite 175 f.).


3.Client-Seite/Aspekte[Bearbeiten]

Frage: Welche Aspekte Verteilter Systeme sind auf Client-Seite zu berücksichtigen? Wie werden User Interfaces in die Architektur Verteilter Systeme eingebunden? Wie können dabei verschiedene Arten der Transparenz unterstützt werden?

{{#dpl:resultsheader=Diese Frage wurde bereits in folgenden Prüfungen gestellt: |oneresultheader=Diese Frage wurde bereits in der folgenden Prüfung gestellt: |noresultsheader=* Diese Frage wurde noch nie gestellt! |skipthispage=no |shownamespace=false |uses=Vorlage:Kapitel |replaceintitle=/Verteilte Systeme VO \(Göschka\)\/Prüfung/, |include={Kapitel}.dpl |includematch=/\|\s*TU Wien:Verteilte Systeme VO \(Göschka\)\/Fragenkatalog Wiki\s*\|\s*Verteilte Systeme auf Client-Seite\s*/si}}

TODO: Verschiedene Aspekte? Wie werden sie eingebunden?


Paper über die Entwicklung von User Interface Tools: UI Tools

Clients müssen in Verteilten Systemen mit dem User und dem Remote Server parallel kommunizieren. Dies kann durch Multithreading am besten und einfachsten geschehen. Weiters können dadurch zB Latenzzeiten bei der Kommunikation überbrückt werden. Wenn es die Server unterstützen, so kann auch über Load-Balancing nachgedacht werden, so dass sich ein Client von mehreren Server-Replikas die Daten parallel besorgt. Auch die lokale Abarbeitung von Daten steigert die Performance, da zB der Netzwerktransfer minimiert werden kann (zB durch Formularkontrolle am Client anstatt am Server).

User Interfaces

  • Model
  • Control
  • View

UIs werden (wie auch Verteilte Systeme) oft schon in einem Schicht-Model realisiert (Vertikale Verteilung). Einzelne Schichten können auf verschiedenen Maschinen laufen (Horizontale Verteilung) (Distributed User Interface). z.B.: kann das Rendering und die Interpretation der Usereingaben komplett am Server erfolgen und der Client dient nur noch als "dumme" Konsole (Remote Application ==> Rechner-Last auf Server). Damit wird die Application unabhängig von der Client-Plattform (Location, Migration, Relocation Transparency).

Arten der Transparenz: Neben Benutzeroberfläche und anderer für die Applikation benötigter Software besteht die Client-Software aus Komponenten, mit denen Verteilungstransparenz erzielt werden soll. Im Idealfall sollte ein Client nicht erkennen, dass er mit einem entfernten Prozess kommuniziert.

Die Zugriffstranzparenz wird häufig realisiert, indem aus der vom Server gebotenen Schnittstellendefinition ein Client-Stub erzeugt wird. Der Stub bietet dieselbe Schnittstelle, die auch auf dem Server zur Verfügung steht, verbirgt jedoch die möglichen Unterschiede in Hinblick auf die Maschinenarchitektur, sowie die eigentliche Kommunikation. Es gibt unterschiedliche Möglichkeiten, Orts-, Migrations- und Relokationstransparenz zu realisieren. Die Verwendung eines praktischen Namenssystem ist wesentlich. In vielen Fällen ist auch die Zusammenarbeit mit Client-seitiger Software wichtig. Ist beispielsweise ein Client bereits zu einem Server gebunden, kann der Client direkt informiert werden wenn sich die Position des Servers ändert. In diesem Fall kann die Middleware des Clients die aktuelle Position des Servers vor dem Benutzer verbergen und die erneute Bindung zu dem Server ggf. transparent vornehmen.

Auf ähnliche Weise implementieren viele Verteilte Systeme die Replikationstransparenz mithilfe Client-seitiger Lösungen.

Die Maskierung von Kommunikationsfehlern mit einem Server erfolgt normalerweise über Client-Middleware. Beispielsweise kann eine Client-Middleware so konfiguriert werden, dass sie wiederholt versucht, eine Verbindung mit einem Server aufzunehmen, oder nach mehreren Versuchen einen anderen Server auszuprobieren (Fehlertransparenz).


4.Dependability[Bearbeiten]

Erläutern Sie die grundlegenden Begriffe der Dependability: Nennen Sie die fünf wesentlichen Attribute (bzw. Requirements) eines "dependable system". Was ist der Unterschied zwischen Availability und Reliability? Erläutern Sie die "dependability threats" Failure, Error und Fault sowie den Zusammenhang zwischen den drei. Erläutern Sie "permanent", "transient" und "intermittent" faults anhand von Beispielen.



Eine Eigenschaft von Verteilten System ist, dass es keinen single-point of failure gibt, fällt eine Komponente aus, so werden möglicherweise einige andere Operationen beeinträchtigt, jedoch nicht das komplette System. Fehlertoleranz bedeutet, dass ein System auch im Falle eines Fehlers seine Dienste zur Verfügung stellt. Attribute eines dependable system:

  • Availability/Verfügbarkeit wird als Wahrscheinlichkeit angegeben, mit welcher ein Service/System zu einem beliebigen Zeitpunkt korrekt arbeitet, sagt jedoch nichts darüber aus, wie lange ein System am Stück verfügbar ist. Ein hoch verfügbares System hat also eine hohe Wahrscheinlichkeit zu jedem beliebigen Zeitpunkt zu funktionieren.
  • Reliability/Ausfallsicherheit: Definiert die Eigenschaft, das ein System fortlaufend fehlerfrei läuft. Ein höchst zuverlässiges System steht also durchgehend über einen relativ langen Zeitraum fehlerfrei zur Verfügung.

Im Gegensatz zur Verfügbarkeit ist hier von einem Zeitraum und nicht von einem Zeitpunkt die Rede. Wenn ein System pro Stunde eine Millisekunde lang nicht funktioniert ist, hat es zwar eine hohe Verfügbarkeit, aber keine hohe Ausfallsicherheit. Andererseits hat ein System welches ganze 11 Monate am Stück fehlerfrei läuft aber dann den ganzen Dezember über abgeschalten wird, hat eine hohe Ausfallsicherheit aber ist nicht hoch verfügbar.

  • Safety/Sicherheit: Definiert, wie sicher ein System im Falle eines Fehlers agiert, sodass keine größeren Schäden passieren.
Bsp: Bei einem Software Fehler in einem Atomkraftwerk sollte das System keinen Katastrophen ähnlichen Zustand annehmen.
  • Integrity/Integrität: Das System soll nicht in einen ungewünschten/nicht definierten Zustand gelangen.
  • Maintainability/Wartbarkeit: Gibt an, wie leicht ein System im Falle eines Fehlers repariert werden kann. Eine hohe Maintainability kann zu einer hohen Verfügbarkeit führen, da im Falle eines Fehlers dieser möglicherweise automatisch erkannt und repariert werden kann.

dependability threats:

  • Fault: ist die Ursache eines Errors/Fehlers
  • Error: Ein Teil des Systemzustands, welcher wegen eines Faults angenomen wurde und schlussendlich zu einem failure führen könnte
  • Failure: Ein Failure tritt ein, wenn ein System durch einen Error seine Dienste nicht mehr vollständig oder überhaupt nicht mehr anbieten kann.

Faults können wie folgt klassifiziert werden:

  • transient fault: Treten zufällig, jedoch nicht wiederholt auf. Bsp: Ein Vogelschwarm stört die Funkverbindung.
  • intermittent fault: treten zufällig auf, verschwinden wieder, und kommen dann wieder; diese Klasse der Faults ist besonders schwer zu identifizieren. Bsp: ein loser Netzwerkstecker, welcher zu einem Wackelkontakt führt.
  • permanent: Treten solange dauerhaft auf, bis die fehlererzeugende Komponente ersetzt wurde. Bsp: Hardwaredefekte, Software Bugs

5.EAI[Bearbeiten]

Frage: Was ist EAI? Geben sie 3 Beispiele von Architekturen, die die Anwendung erleichtern. Was ist ein "Legacy System"?

{{#dpl:resultsheader=Diese Frage wurde bereits in folgenden Prüfungen gestellt: |oneresultheader=Diese Frage wurde bereits in der folgenden Prüfung gestellt: |noresultsheader=* Diese Frage wurde noch nie gestellt! |skipthispage=no |shownamespace=false |uses=Vorlage:Kapitel |replaceintitle=/Verteilte Systeme VO \(Göschka\)\/Prüfung/, |include={Kapitel}.dpl |includematch=/\|\s*TU Wien:Verteilte Systeme VO \(Göschka\)\/Fragenkatalog Wiki\s*\|\s*EAI\s*/si}}


Unter Enterprise Application Integration versteht man die Schaffung von betrieblichen Anwendungssystemen durch die Kombination einzelner Anwendungen unter Verwendung einer gemeinsamen Middleware.

Präsentations - Integrationsmodell z.B: Gemeinsames Java Interface für mehrere Mainframe Anwendungen

Daten - Integrationsmodell z.B: Integration von Kundendaten aus verschiedenen DB-Systemen in eine Call-Center-Anwendung

Funktionales Integrationsmodell z.B: Schaffung einer einheitlichen Kundensicht über alle betrieblichen Anwendungen und Datenbanken durch Schnittstellen der Middleware zu allen Anwendungen

Im Buch auf Seite 41 (deutsche Ausgabe, 2008) steht, dass EAI eine Middleware ist, die die Kommunikation zwischen mehreren Anwendungen ermöglicht (siehe Abbildung 1.11). Beispielsweise wird dies durch RPC, RMI und Message Oriented Middleware ermöglicht. RPC und RMI verlangen im Gegensatz zu MoM, dass Aufrufer und Aufgerufener beide aktiv sein müssen. Außerdem muss bekannt sein, wie man sich gegenseitig ansprechen kann. Diese enge Kopplung ist ein schwerwiegender Nachteil und zu MoM geführt.


Ein Legacy System bezeichnet eine etablierte, historisch gewachsene Anwendung.

Ein grundsätzliches Problem mit der Ablösung von Legacysystemen ist der gewachsene Funktionsumfang.


ANMERKUNG koDiacc: Diese Frage kam heute am 6.6.2012 bei der Prüfung dran. Sollten wir sie deswegen nicht von den "Alten Fragen" entfernen? Oder hier lassen, weil sie nicht im Offiziellen Fragenkatalog der LVA-HP steht?