Theoretische Grundlagen

SEITE IST NOCH IN DER ENTSTEHUNG!!!

Um zu verstehen, warum die durch Jini(TM) festgelegten und anfänglich oft als reichlich kompliziert empfundenen Konstrukte in dieser Architektur enthalten sein müssen, sollte man zunächst, die unter ... dargelegten Designziele von Jini(TM) den tatsächlichen Gegebenheiten eines verteilten Systems gegenüber stellen. Um daran anschließend besser verstehen zu können wie besagte Konstrukte in der Java Intelligent Network Infrastructure ineinander greifen, ist ein gewisses Verständnis sogenannter dienstorientierter Architekturen, engl. service-oriented architectures (SOAs), vorteilhaft. Zwar ist es im Rahmen einer Studienarbeit gänzlich unmöglich auch nur einen der genannten Themenkomplexe erschöpfend zu behandeln, einige wichtige Punkte aus diesen sollen aber dennoch dargelegt werden, soweit sie für den weiteren Kontext von Bedeutung sind.

Verteilte Systeme

Unter diesem Punkt sollen kurz die wichtigsten Eigenschaften verteilter Systeme vorgestellt werden. Dies geschieht wie oben erwähnt nicht mit dem Anspruch auf erschöpfende Behandlung des Themas. Hierfür sei auf die einschlägige Literatur verwiesen, u. a. [..., Tanenbaum1], [..., Tanenbaum2], [..., Chow] und [..., Andrews].

Charakterisierung und Eigenschaften

Für den Begriff des verteilten Systems existieren mehrere Definitionsansätze. Einige betonen mehr die physische Sicht auf Verteilung, während andere mehr eine logische bzw. anwendungsorientierte Sichtweise auf ein verteiltes System in den Vordergrund stellen. Die an den physischen Aspekte der Verteilung orientierte Sichtweise betrifft die Aufteilung eines Systems auf mehrere, voneinander unabhängige Computer. Die logischen bzw. anwendungsorientiere Perspektive beschreibt dagegen die Aufteilung von Zustand und Verhalten des Gesamtsystems auf mehrere autonome Verarbeitungsknoten, wobei egal ist, auf welchen Rechnern diese Knoten ablaufen. Im Rahmen der nachfolgenden Abhandlungen soll für ein verteiltes System die folgende, auf Puder&Römer [..., Puder&Römer, S. ...] aufbauende Erklärung für ein verteiltes System gelten.

Ein verteiltes System ist ein Informationsverarbeitendes System, das eine Vielzahl autonomer Verarbeitungsknoten enthält, die auf unterschiedlichen Rechnern ablaufen können und die über ein Kommunikationsnetzwerk miteinander kooperieren, um ein angestrebtes Ziel zu erreichen.

Als Verarbeitungsknoten kann im Jini(TM)-Kontext eine Java(TM) Virtual Machine (JVM) angenommen werden. Das Kommunikationsnetzwerk sei die Vereinigung aller aktiven und passiven Hard- und Softwarebausteine, die notwendig sind, damit Daten zwischen den verschiedenen, an einem verteilten System beteiligten Verarbeitungsknoten ausgetauscht werden können.

Griffel identifiziert in [..., Griffel, S. 143] für ein verteiltes System weiterhin folgende Eigenschaften:

• Der Austausch von Daten zwischen den Verarbeitungsknoten eines verteilten Systems erfolgt ausschließlich über den Austausch von Nachrichten via Kommunikationsnetzwerk.
• Ein verteiltes System besitzt zu keinem Zeitpunkt einen feststellbaren globalen Zustand, da der Datenaustausch zwischen den Verarbeitungsknoten des Systems mittels Nachrichten erfolgt und deren Übertragung Latenz- und Vermittlungszeiten in Anspruch nimmt. Trifft eine Nachricht bei ihrem Empfänger ein, können somit die in ihr enthaltenen Informationen schon veraltet sein.
• Ein verteiltes System erbringt seine Gesamtfunktionalität durch die arbeitsteilige zielgerichtete Kooperation der in den einzelnen Verarbeitungsknoten angesiedelten Softwarekomponenten.

Auf den ersten Blick führen diese Eigenschaften in Bezug auf die von Jini(TM) formulierten Ziele zu einem Dilemma. Auf der einen Seite sollen auf Basis von Jini(TM) verteilte Systeme erstellt werden, die genauso stabil und zuverlässig laufen und die in ihrem Antwortverhalten genauso performant sind, wie man es von traditionellen zentralisierten Systemen gewohnt ist. Auf der anderen Seite kann man in einem verteilten System zu keinem Zeitpunkt den aktuellen globalen Zustand ermitteln. Diese Eigenschaft impliziert u. a., auch, dass man zu keinem Zeitpunkt feststellen kann, welche Verarbeitungsknoten und damit welche Komponenten und Ressourcen aktuell am System beteiligt sind. Wie soll man unter diesen Voraussetzungen ein stabiles und funktionierendes System erstellen, welches seine Gesamtfunktionalität durch die zielgerichtete arbeitsteilige Kooperation seiner, über die verschiedenen Verarbeitungsknoten verteilten Komponenten erbringt? Und wie will man für ein verteiltes System eine Performanz im Antwortverhalten sicher stellen, die annähernd äquivalent zu der eines traditionellen zentralisierten Systems ist, wenn die Kommunikation zwischen Komponenten, die in unterschiedlichen Verarbeitungsknoten angesiedelt sind, von vornherein mit nicht unerheblichen Latenzzeiten belegt ist? Auf all diese Fragen muss Jini(TM) eine Antwort liefern, sollen die gesteckten Ziele erreicht werden.

Die Struktur eines verteilten Systems

TODO

Das Client/Server-Modell

Untersucht man die Verarbeitungsknoten eines verteilten Systems näher, wird man feststellen, dass einige dieser Knoten dafür ausgelegt sind, den anderen Knoten des Systems bestimmte Dienstleistungen, engl. services, anzubieten. Andere Verarbeitungsknoten initiieren aktiv Kommunikation, um diese Dienstleistung in Anspruch zu nehmen. Verarbeitungsknoten, die eine bestimmte Dienstleistung für andere Verarbeitungsknoten anbieten, sind bzgl. dieser Dienstleistung Dienstgeber, engl. service provider, bezeichnet werden. Knoten die eine angebotene Dienstleistung in Anspruch nehmen sind bzgl. dieser Dienstleistung Dienstkonsumenten, engl. service consumer. Es hat sich eingebürgert, dienstgebende Verarbeitungsknoten als Server und dienstnehmende Knoten als Klienten, engl. clients, zu bezeichnen. Es ist wichtig zu beachten, dass Klient und Server nur Rollen bzgl. der Inanspruchnahme einer konkreten Dienstleistung sind. Ein Verarbeitungsknoten, der für service1 als Server auftritt, kann bzgl. service2 in der Rolle des Klienten agieren. Bei der Vorstellung des Konzepts serviceorientierter Architekturen werden die Begriffe Klient, Server und Service eine weitere Konkretisierung erfahren. Vorerst sollen die oben dargelegten Erklärungen aber ausreichend sein.

Zentraler Server vs. Peer-to-Peer

Anhand der Rollen beim Anbieten bzw. der Inanspruchnahme der in einem verteilten System vorhandenen Dienstleistungen lässt sich die Struktur eines verteilten Systems ermitteln. Ist ein einzelner Verarbeitungsknoten eines verteilten Systems dafür ausgezeichnet, alle im System abrufbaren Dienstleistungen anzubieten und die anderen Verarbeitungsknoten treten nur als Klienten in Erscheinung, dann spricht man von einem zentralisierten Client/Server-System , auch zentralen Server genannt (siehe ...). Dieser Ansatz für den Aufbau verteilter Systeme stammt aus einer Zeit, in der ein einzelner Mainframe die Rechenleistung für viele Terminals erbrachte. Er hat den Vorteil, das die Struktur des Systems relativ einfach ist und die Wartung und Administration hauptsächlich an einem einzigen Punkt, dem zentralen Server, erfolgen kann. Dafür ist die im System anfallende Rechenarbeit hauptsächlich auf den als Server agierenden Verarbeitungsknoten konzentriert. Wächst das System, d. h., es kommen mehr und mehr Klienten zu diesem hinzu, dann wird der zentrale Server mehr und mehr zum Flaschenhals. Desweiteren stellt der zentrale Server einen Single-Point-of-Failure dar. Fällt der Server aus, kann das System seine Funktionalität nicht mehr erbringen. Ein weiterer Nachteil eines rein auf dem Prinzip des zentralen Servers basierenden verteilten Systems ist die Tatsache, dass die Erweiterung des Spektrums im System zur Verfügung stehender Dienstleistungen nur möglich ist, wenn die neuen Dienstleistungen auch durch den zentralen Server angeboten werden. Dies bedeutet aber, dass noch mehr Arbeit durch diesen Server zu verrichten ist, was zu einer Verschärfung der Flaschenhalssituation führen kann. Außerdem kann es sein, dass für eine Erweiterung des Systems ein komplettes Re-Deployment des Servers notwendig ist. Für diesen Zeitraum wärde das System dann nicht arbeitsfähig. Auf Jini(TM) basierende Systeme werden in aller Regel nicht als zentralisierte Client/Server-Systeme ausgelegt, da der Ansatz des zentralen Servers zu starr ist, um die für Jini(TM) geforderte Anpassungsfähigkeit zu gewährleisten. Zentralisierte Client/Server-Systeme werden in der Java(TM)-Welt eher durch den Application-Server-Ansatz realisiert, der durch die Java2(TM) Enterprise Extension (J2EE(TM)) unterstützen wird.

GRAFIK

Verteilte Systeme, in denen prinzipiell jeder Verarbeitungsknoten in der Lage ist, anderen Knoten eine Dienstleistung anzubieten und aktiv Kommunikation zu initiieren, um die angebotenen Dienstleistungen anderer Verarbeitungsknoten in Anspruch zu nehmen, werden als Peer-to-Peer-Systeme (P2P-Systeme) bezeichnet (siehe ...). Durch den P2P-Ansatz will man erreichen, dass die im System anfallende Rechenarbeit gleichmäßiger über die Verarbeitungsknoten des Systems verteilt wird. Außerdem soll der Single-Point-Of-Failure, den ein zentraler Server darstellt, eliminiert werden. Fällt ein einzelner Knoten eines P2P-Systems aus, bedeutet das noch lange nicht, dass das System seine Funktionalität insgesamt nicht mehr erbringen kann, so wie es beim Ausfall eines zentralen Servers der Fall wäre. Zudem ist es in einem P2P-System möglich, dass mehrere Verarbeitungsknoten die gleiche Art von Dienstleistung anbieten. Fällt ein Verarbeitungsknoten, der eine bestimmte Art von Dienstleistung anbietet aus, dann können die Klienten dieser Dienstleistung auf einen anderen Verarbeitungsknoten umschalten, der die gleiche Art von Dienstleistung anbietet. Hierdurch kann die Ausfallsicherheit eines verteilten Systems erheblich erhöht werden. Zudem ist es in P2P-Systemen durch das Hinzufügen neuer Verarbeitungsknoten möglich, das Spektrum der zur Verfügung stehenden Dienstleistungen zu erweitern. Auf der anderen Seite erfordert die Verwaltung der in einem P2P-System zur Verfügung stehenden Dienstleistungen einen ungleich höheren Aufwand, als dies in einem zentralisierten Client/Server-System notwendig ist. In einem zentralisierten Client/Server-System muss „nur“ darauf geachtet werden, dass der zentrale Server reibungslos läuft. Damit stehen die für das Funktionieren des Systems notwendigen Services zur Verfügung. In einem P2P-System muss hingegen das Funktionieren mehrerer Verarbeitungsknoten überwacht werden. Ein weiteres großes Problem in P2P-Systemen ist die Erhaltung konsistenter Daten bezogen auf das Gesamtsystem. In einem zentralisierten Client/Server-System werden die für das System wichtigen Daten in aller Regel ausschließlich auf dem zentralen Server abgelegt. In einem P2P-System sind diese Daten dagegen oft über viele Verarbeitungsknoten verteilt. Da man in verteilten Systemen zu keinem Zeitpunkt den globalen Zustand des Systems ermitteln kann, kann man auch nicht ohne weiteres feststellen, ob sich alle für das Funktionieren des Systems wichtigen Daten in einem Konsistenten Zustand befinden. Hier müssen besondere Mechanismen entworfen werden, die die Konsistenz verteilter Daten garantieren. Aus der Theorie verteilter Datenbanken weiß man, dass dies nur durch die Verwendung verteilter Transaktionen möglich ist, deren Einsatz aber einen nicht unerheblichen Aufwand bei der Entwicklung verteilter Systeme hervorruft. In der Praxis wird man meist einen Kompromiss aus P2P-Ansatz und zentralisiertem Client/Server-System vorfinden. Der P2P-Ansatz ist aber trotz seiner aufgezählten Nachteile der für Jini(TM)-Systeme natürlichere, da er die größere Flexibilität des Gesamtsystems ermöglicht. Außerdem entspricht er eher den Gegebenheiten dynamischer verteilter Systeme, in denen Verarbeitungsknoten quasi beliebig kommen und gehen können.

GRAFIK

Service Oriented Architecture (SOA)

Im vorhergehenden Abschnitt wurde skizziert, wie Services in einem verteilten System auf die verschiedenen Verarbeitungsknoten des Systems aufgeteilt werden können. Jini(TM)-Systeme wurde P2P-Ansatz als der zu bevorzugende herausgestellt. In P2P-Systemen erfolgt eine Aufteilung der im System vorhandenen Services auf mehrere am System beteiligte Verarbeitungsknoten. In einer solchen Konstellation ist es für das Funktionieren des Systems immanent wichtig, Services dynamisch lokalisieren und anschließend Verbindung mit ihnen aufnehmen zu können. In einem zentralisierten Client/Server-System sind alle Services quasi unter der gleichen Adresse, nämlich der des zentralen Servers, aufzufinden. In einem P2P-System müsste man sich hierfür schon die Adressen mehrerer Verarbeitungsknoten merken. Handelt es sich zusätzlich noch um ein dynamisches System, d. h., es steht nicht von vornherein fest, welche (dienstanbietenden) Verarbeitungsknoten ab System teilnehmen, ist über statische Adressen keine Zugriffsmöglichkeit auf die im System vorhandenen Services mehr gegeben. Hier muss ein gänzlich anderer Mechanismus her, um Services trotzdem zuverlässig lokalisieren und auf diese Zugreifen zu können. Nachfolgend wird eine Softwarearchitektur beschrieben, die die für P2P-Systeme notwendigen Eigenschaften besitzt und die gleichzeitig die Grundlage von Jini(TM) ist. Genauer gesagt dürfte Jini(TM) einer der ersten kommerziellen Vertreter wenn nicht gar der Begründer des nachfolgend vorgestellten Architekturansatzes sein. Die folgenden Erläuterungen basieren dabei auf einem Artikel von Michal Stevens , [1] Softwarearchitekturen allgemein beschreiben auf einem höheren Abstraktsniveau die Komponenten eines Softwaresystems und die zwischen diesen möglichen Interaktionen.

„... The softwarearchitecture of a program or a computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them. ...“ [Bass, Clements, and Kazman 1997]

Komponenten sind Softwaremodule, die als Einheit betrachtet und in einem einzigen Verarbeitungsknoten deployed werden können. Die Interaktionen, die zwischen Komponenten möglich sind, werden als Konnektoren, engl. connectors, bezeichnet. Die Konfiguration von Komponenten und Konnektoren bestimmt, wie ein System strukturiert ist und wie es sich verhält (...).