Skip to main content
main-content

Inhaltsverzeichnis

Frontmatter

Kapitel 1. Architektur verteilter Systeme

Zusammenfassung
Bevor wir in die Entwicklung verteilter Anwendungen mit Hilfe von Middleware einsteigen, soll dieses Kapitel die wichtigsten Begriffe und Techniken erläutern und dadurch ein grundsätzliches Verständnis verteilter Systeme ermöglichen.
Steffen Heinzl, Markus Mathes

Kapitel 2. Nebenläufigkeit in Java

Zusammenfassung
Nebenläufigkeit wird auf Betriebssystemen durch zwei unterschiedliche Konzepte realisiert: durch Prozesse oder durch Threads. In der Programmiersprache Java steht dem Anwendungsentwickler nur die Möglichkeit zur Verfügung Threads zu erzeugen und zu verwenden. Allerdings entsteht daraus kein größeres Problem, da aufgrund des Objektparadigmas jeder Thread innerhalb des Java Programms seine eigenen gekapselten Daten hat. Im Folgenden wird erklärt, was ein Thread ist und wie Threads in Java verwendet werden.
Steffen Heinzl, Markus Mathes

Kapitel 3. Synchronisationsmechanismen

Zusammenfassung
Da parallele Programme aus mehreren sequentiellen Ausführungsfäden bestehen, stellt sich oft die Anforderung, Daten zwischen Programmen oder innerhalb von Programmen auszutauschen oder auch Ergebnisse zurückzumelden. Sobald mehrere parallele Zugriffe auf eine Variable, eine Funktion oder ein Gerät erfolgen, können Synchronisationsprobleme oder Interferenzen1 auftreten.
Steffen Heinzl, Markus Mathes

Kapitel 4. Design von Client/Server-Software

Zusammenfassung
Der Entwurf verteilter Anwendungen richtet sich heute häufig nach dem so genannten Client/Server-Modell. Bei diesem Interaktionsmodell werden die miteinander kommunizierenden Einheiten in Client und Server unterschieden. Unter einem Server versteht man einen Dienstanbieter, der eine spezifische Funktionalität erbringt. Der Client ist ein Dienstnutzer, der die Ausführung eines spezifischen Dienstes von einem Server anfordert. Da Client und Server unabhängig voneinander ausgeführt werden — oftmals auf verschiedenen Rechnersystemen — muss die Kommunikation zwischen beiden synchronisiert werden. Andernfalls kann es zwischen ihnen eventuell niemals zu einem Datenaustausch kommen.
Steffen Heinzl, Markus Mathes

Kapitel 5. Serialisierung

Zusammenfassung
Unter Serialisierung versteht man die Zerlegung des Status’ eines Objekts in ein Bytearray [Heinzl/Mathes 2003]. Dadurch ist es möglich, Objekte (als Bytearray) über einen Stream zu verarbeiten. Beispielsweise kann der Status eines Objekts in eine Datei geschrieben oder auch über das Netzwerk versendet werden.
Steffen Heinzl, Markus Mathes

Kapitel 6. Verteilte Objekte durch RMI

Zusammenfassung
In diesem Kapitel beschreiben wir einen alternativen Ansatz zur Entwicklung verteilter Anwendungen, der auf der Verteilung von Objekten beruht und eng an die Programmiersprache Java geknüpft ist. Die Rede ist vom entfernten Methodenaufruf (Remote Method Invocation, RMI), der eine Verteilung von Objekten auf mehrere Rechner bzw. auf mehrere virtuelle Maschinen erlaubt. Man unterteilt Objekte dann in so genannte lokale und entfernte Objekte und unterscheidet entsprechend den Aufruf einer lokalen und entfernten Methode. Lokale und entfernte Objekte können vom Client jedoch nicht unterschieden werden und realisieren dadurch Ortstransparenz. Ein Client kann mit entfernten Objekten genau wie mit lokalen arbeiten. Ein Methodenaufruf auf einem entfernten Objekt verhält sich identisch zum Aufruf einer Methode auf einem lokalen Objekt.
Steffen Heinzl, Markus Mathes

Kapitel 7. Einführung in CORBA

Zusammenfassung
Die Common Object Request Broker Architecture (CORBA) ist ein Standard der Object Management Group (OMG) und definiert eine Kommunikation für verteilte Objekte. Die Struktur von CORBA wird durch das CORBA Referenzmodell verdeutlicht, welches aus folgenden Komponenten besteht (nach [OMG/CORBA] S. xxv):
  • Object Request Broker: Der Object Request Broker (ORB) ist die zentrale1 Komponente für die Kommunikation von verteilten Objekten.
  • Object Services: Object Services sind eine Sammlung von Diensten, die gut zur Realisierung verteilter Anwendungen verwendet werden können. Wichtige Dienste sind beispielsweise:
  • Naming Service: Clients verwenden den Naming Service, um herauszufinden, an welche Rechner sie ihre Anfragen schicken müssen.
  • Interface Repository: Im Interface Repository werden Interfaces von Objekten hinterlegt, um zur Laufzeit einen dynamischen Zugriff auf diese Objekte zu ermöglichen.
  • RootPOA: Ein Object Adapter koordiniert serverseitig die Zugriffe auf die Skeletons (siehe Bild 7.3). In älteren CORBA Versionen wurde dafür der Basic Object Adapter (BOA) eingesetzt. Da die Spezifikation allerdings zu ungenau war und verschiedene Hersteller zueinander inkompatible Adapter entworfen hatten, wurde später der Portable Object Adapter (POA) definiert, der mittlerweile (nahezu) ausschließlich eingesetzt wird. Der Standard POA in einem Programm wird RootPOA genannt und setzt einen bestimmten Satz Policies um (näheres in [OMG/CORBA] S. 11–6). Falls andere Policies realisiert werden sollen, kann der RootPOA ein Kind erzeugen, welches diese Policies umsetzt.
  • Life Cycle Service: Legt Konventionen zur Erzeugung, zum Kopieren, Löschen und Verschieben von Objekten fest.
  • Concurrency Service: Realisiert den konsistenten parallelen Zugriff auf ein Objekt.
  • ...
  • Common Facilities: Unter Common Facilities werden Dienste zusammengefasst, die für verschiedene Anwendungen verwendet werden können, aber weniger wichtig sind als Object Services. Es existieren beispielsweise Spezifikationen für eine „Mobile Agents Facility“ und für „Internationalization and Time“.
  • Application Objects: Für Application Objects besteht keine Spezifikation, da diese für die eigentliche Funktionalität verantwortlich sind, die verteilt angeboten wird. Der Anwendungsentwickler ist für deren Entwurf verantwortlich.
Steffen Heinzl, Markus Mathes

Kapitel 8. Nachrichtenbasierte Kommunikation mit JMS

Zusammenfassung
Die in den letzten Kapiteln vorgestellte Kommunikation über Sockets und RMI hat eine wesentliche Prämisse: sowohl Sender als auch Empfänger der Daten müssen zeitgleich zu einem Datenaustausch bereit sein. Diese Prämisse impliziert eine enge Kopplung zwischen den kommunizierenden Komponenten (synchrone Kommunikation). Diese enge Kopplung kann in bestimmten Fällen nachteilig sein, beispielsweise wenn ein Client eine Anfrage an den Server sendet, dieser aber relativ lange benötigt, um eine Antwort generieren zu können. Der Client wartet derzeit blockiert auf die Antwort des Servers. Hängt die weitere Arbeit des Clients unmittelbar von der Antwort des Servers ab, ist dieser Ansatz natürlich sinnvoll. Oftmals kann ein Client aber noch weitere Dinge erledigen, bis die Antwort des Servers eintrifft. Dies ist jedoch mit den bisher vorgestellten Methoden nicht ohne weiteres möglich.1
Steffen Heinzl, Markus Mathes

Backmatter

Weitere Informationen