Verteilte Systeme 1 Grundlagen...2 1.1 Anforderungen...2 1.2 Kommunikation in verteilten Systemen...5 1.3 Fehlersemantik bei auftragsorientierter Kommunikation.7 1.4 Architektur verteilter Systeme...10 2 Middleware...14 2.1 Kommunikation über Sockets...15 2.2 Formen von Middleware...18 2.3 Distributed Computing Environment (DCE)...20 2.4 Common Objekt Request Broker Architecture (CORBA) 24 2.5 Web-Services...27 2.6 Vergleich der Middleware-Ansätze...32 3 Mobiler Code...34 4 Verteilte Softwaresysteme...35 4.1 Verteilte Datenbanksysteme...35 4.2 Verteilte Anwendungssysteme...36 4.3 Verteilte Web-Systeme...38 5 Marktsituation...40 Seite 1 von 41
1 Grundlagen 1.1 Anforderungen Unter einem verteilten System versteht man ein zusammenhängendes Rechnersystem, das aus einer Menge unabhängiger, kooperierender Rechner besteht, die über ein Rechnernetz verbunden sind. Aus der Sicht eines Anwenders erscheint das verteilte System als ein gemeinsames System. Einzelne Komponenten eines verteilten Systems können verschiedene Rollen ausfüllen. Man unterscheidet typischerweise zwischen Serverprogrammen, das sind Softwarekomponenten, die Dienste anbieten, und Klientenprogrammen, das sind Softwarekomponenten, die bei Bedarf Dienste von Serverkomponenten in Anspruch nehmen. Die Kommunikation zwischen einem Klientenprogramm und dem Serverprogramm basiert auf Anfragen, die vom Klientenprogramm zur Verarbeitung an den Server übermittelt werden. Meist sind Klientenprogramme auf kostengünstigen Arbeitsplatzrechnern installiert, während die von vielen Benutzern gemeinsam genutzten Serverprogramme auf leistungsfähigen Serverrechnern Seite 2 von 41
laufen. In diesem Kapitel befassen wir uns vorwiegend mit der Software, die in verteilten Systemen eingesetzt wird. Der Trend bei verteilten Systemen geht zur Dezentralisierung, die durch folgende Merkmale gekennzeichnet ist: Steigende Leistung der Arbeitsplatzrechner Verfügbarkeit von immer leistungsfähigeren und kostengünstigeren Netzverbindungen Zunehmendes Angebot von (offenen) Kommunikationsstandards und Standardsystemplattformen Veränderte Unternehmensstrukturen Verstärkter Wunsch nach Integration bestehendes PC- Insellösungen Durch verteilte Systeme ergeben sich häufig Verbundvorteile. Gemeinsam nutzbare Ressourcen sind zum Beispiel zentrale Datenbanken, große Speichermedien, Hochleistungsdrucker und Anschlüsse an öffentliche Netze. Bei verteilten Netzen sind folgende Punkte zu beachten: Transparenz (es soll nicht sichtbar sein, dass ein System auf verschiedene Rechner verteilt ist) Seite 3 von 41
Schnittstellendefinition ( bei einem offenen System sind Dienste gemäß wohldefinierter und veröffentlichter Spezifikationen implementiert, wobei darauf zu achten ist, dass sämtlicher funktionalen Aspekte des Systems abgedeckt werden) Interoperabilität und Portabilität (Um dies zu sichern müssen die Schnittstellendefinitionen syntaktisch vollständig sein und implementierungsneutral in dem Sinne, dass sie keine Aussagen über die Implementierung im Detail treffen. Zwei Systeme sind interoperabel, wenn sie aufgrund einer Schnittstellendefinition oder eines Protokolls miteinander kooperieren können.) Homogene und heterogene Netzwerke (zu unterscheiden ist bei verteilten Systemen, ob diese homogen oder heterogen sind) Skalierbarkeit (Leistung des Systems muss höheren Anforderungen anzupassen sein) Robustheit (Da die Zahl der Komponenten in verteilten Systemen üblicherweise höher ist als in nicht verteilten treten mehr Fehler auf und die Fehlersuche ist schwieriger. Zu unterscheiden ist in partielles Versagen und vollständiges Versagen.) Seite 4 von 41
1.2 Kommunikation in verteilten Systemen Jede Interaktion zwischen Softwarekomponenten in einem verteilten System basiert auf der Übermittlung von Informationen zwischen diesen. In der Regel übermittelt dabei das Klientenprogramm eine Anfrage an den Server, die von diesem verarbeitet wird. Der Server schickt nach erfolgter Verarbeitung das Ergebnis wiederum an den Klienten. Die Kommunikation in verteilten Systemen hat unterschiedliche Gestaltungsdimensionen. Zu unterscheiden sind folgende: Adressierung: Die Adressierung dient der Identifikation des Empfängers einer Nachricht. Prinzipiell können direkte und indirekte Adressierung unterschieden werden: Direkte Adressierung: Sender kennt Empfängeradresse und sendet direkt Seite 5 von 41
Indirekte Adressierung: Sender spricht Empfänger über Vermittlerdienst an. Blockierung: Bei einem Nachrichtenaustausch kann man mit Blick auf die zeitliche Abfolge zwischen einem blockierenden (synchronen) und einem nicht-blockierenden (asynchronen) Nachrichtenverkehr unterscheiden. Beim synchronen Nachrichtenverkehr ist der Sender bis zum Empfang der Antwort des Empfängers blockiert. Beim asynchronen Nachrichtenverkehr ist der Sender nur bis zur Ablieferung der Nachricht an das Transportsystem blockiert. Pufferung: Die Nachrichtenübertragung zwischen zwei Kommunikationspartnern kann mit und ohne Pufferung der Nachrichten in einer Warteschlange organisiert werden. Bei ungepuffertem Nachrichtenverkehr existiert keine Warteschlange für eingehende Meldungen, bei gepuffertem bietet das Betriebssystem oder das jeweilige Programm selbst einen Pufferspeicher in Form einer Warteschlange an. Kommunikationsmuster: Das Kommunikationsmuster bestimmt, welche Interaktionsreihenfolge für eine bestimmte Aufgabe vorgesehen ist. Man unterscheidet zwischen mitteilungsorientierter und auftragesorientierter Kommunikation: Seite 6 von 41
1.3 Fehlersemantik bei auftragsorientierter Kommunikation Verteilte Systeme bestehen im einfachsten Fall aus zwei Rechnern, auf denen jeweils ein Programm läuft, das mit dem anderen Programm über ein Netzwerk kommuniziert. Daraus ergibt sich eine Reihe von potentiellen Fehlerquellen für verteilte Systeme, die bei einem lokalen System, das auf einem einzigen Rechner läuft, nicht Seite 7 von 41
auftreten können. Man kann in fünf Fehlerfälle unterscheiden: Das Klientenprogramm kann den Server nicht lokalisieren Verlorene Auftragsnachricht Absturz des Serverprogramms Verlorene Antwortnachricht Absturz des Klientenprogramms Die Kommunikation verläuft immer folgendermaßen: Die Fehlerbehandlung kann unterschiedlich erfolgen. Zu beachten ist, ob es sich um eine idempotente Operation handelt. Seite 8 von 41
Eine Operation ist idemotent, wenn Sie mehrere Male durchgeführt werden kann und stets dasselbe Ergebnis liefert und den globalen Zustand des Servers nicht verändert. Erschwerend kommt noch hinzu, dass ein Klientenprogramm immer nur über lokale Informationen verfügt, so dass es beispielsweise nur schwer unterscheiden kann, ob die Auftrags- oder Antwortnachricht verloren gegangen ist, oder ob der Server zwischenzeitlich abgestürzt ist. Daher werden Mechanismen benötigt, um Fehlersituationen umgehen zu können. Unterschieden wird in: Maybe-Fehlersemantik At-Least-Once-Fehlersemantik At-most-Once-Fehlersemantik Exactla-Once-Fehlersemantik Eine Übersicht gibt folgende Tabelle: Seite 9 von 41
1.4 Architektur verteilter Systeme Unterschieden wird in 4 unterschiedliche Stufen von verteilten Informationssystemen: Einstufige Architektur (Alle drei Schicht auf einer Stufe (Bsp: Großrechner) Zweistufige Architektur (Client/Server) Dreistufige Architektur Vierstufige Architektur Seite 10 von 41
Die einstufige Architektur ist diejenige Architektur, die vor einigen Jahrzehnten benutzt wurde. Es handelt sich hierbei um einen Großrechner, der sämtliche Aufgaben erledigt. Die Zweistufige Architektur ist die Client/Server-Architektur, wobei die erste Stufe in der Regel der Arbeitsplatzrechner ist und die zweite Stufe der Serverrechner: Seite 11 von 41
Bei der dreistufigen Architektur handelt es sich um die am Weitesten verbreitete Form der Client/Server-Architektur mit zentrale Datenhaltung auf einem passiven Server. Für komplexe Anwendungen besteht jedoch der Nachteil, dass die klientseitige Komponente sehr umfangreich werden kann. Die Vorteile liegen in der klaren Trennung von Benutzerkomponente, Anwendungskomponente und Datenhaltung und der Speicherstrategie. Die Speicherstrategie betrifft nur die Datenbank- und die Anwendungslogik, nicht aber die benutzerseitige Seite 12 von 41
Komponente. Die Grundlage der dreistufigen Architektur ist folgende: Die nächste Ebene ist die N-stufige Architektur. Hierbei kooperieren eine Vielzahl spezialisierter Server für eine Aufgabe (n-tier). Generell muss bei der Verteilung aber zwischen Gewinn an zusätzlicher Komplexität und Flexibilität und erhöhten Verarbeitungsaufwand bei der Verteilung abgewogen werden. Seite 13 von 41
2 Middleware Verteilte Softwaresysteme sind im Wesentlichen dadurch gekennzeichnet, dass sie aus mehreren interagierenden Softwarekomponenten bestehen, die sich meist auf physikalisch unterschiedlichen Rechnern innerhalb eines Rechnernetzes befinden. Die Middleware bildet die kommunikationstechnische Infrastruktur zur Entwicklung verteilter Anwendungen und ermöglicht dem Entwickler dadurch die Konzentration auf die Umsetzung der Anwendungslogik. Entsprechend werden allgemeine Softwarekomponenten, die von konkreten Realisierungen von Kommunikationsprotokollen abstrahieren und auf die Erleichterung der Interaktion zwischen verteilten Softwarekomponenten abzielen, als Middleware bezeichnet. Middleware kann ein großes Anwendungsspektrum abdecken. Man kann zum Beispiel mithilfe von Middleware zwei Anwendungssysteme im selben lokalen Netzwerk integrieren, oder auch zwei vollständige dreistufig Informationssysteme zusammenschalten. Seite 14 von 41
2.1 Kommunikation über Sockets Middleware ermöglicht die Abstraktion für die Realisierung von Dienstaufrufen auf entfernten Rechnern, indem sie einen Teil der dahinter stehenden Komplexität versteckt und den entfernten Methodenaufruf über eine lokale Schnittstelle zur Verfügung stellt. Damit verschiedene Komponenten miteinander kommunizieren können, muss zunächst ein Kommunikationskanal geöffnet werden, über den Informationen ausgetauscht werden können. Über einen Socket wird ein Kommunikationskanal zwischen zwei Prozessen verwaltet, die entweder auf demselben oder unterschiedlichen Rechnern in einem Seite 15 von 41
Netzwerk laufen. Sockets stellen Endpunkte für den Austausch von Daten zwischen Rechnern dar. Jeder Socket hat eine Socketadresse, die sich aus einer Dienstnummer, einer Rechneradresse und dem verwendeten Transportprotokoll zusammensetzt. Eine zentrale Aufgabe von Middleware ist die Realisierung eines synchronen Aufrufs eines entfernten Dienstes, das heißt, einer Funktion, die von einem Serverprozess bereitgestellt wird. Diese Funktionalität wird allgemein als Remote-Procedure-Call bezeichnet. Über einen Remote-Procedure-Call (RPC) kann ein Klientenprogramm eine Funktion von einem Serverprogramm aufrufen, das unter Umständen auf einem anderen Rechner installiert ist. Dabei wird ein lokaler Funktionsaufruf durch einen entfernten Funktionsaufruf simuliert. Da auch ein lokaler Aufruf eine Synchrone Operation ist, wird in der Regel auch der RPC als synchroner, entfernter Dienstaufruf realisiert. Das Klientenprogramm übermittelt den Funktionsaufruf inklusive der jeweiligen Argumente an das Serverprogramm und setzt seine Ausführung erst fort, wenn der Rückgabewert eingetroffen ist. Seite 16 von 41
Die Funktionsweise von entfernten Dienstaufrufen bei einem RPC ist folgende: Man kann den Ablauf folgend untergliedern: Definition der Schnittstelle Seite 17 von 41
Erzeugung von Platzhalterfunktionen für die Schnittstelle ( Meist durch IDL-Compiler) ABB Nutzung des Dienstes 2.2 Formen von Middleware Durch Middleware wird eine komplexe Softwareinfrastruktur zur verteilten Verarbeitung bezeichnet, durch die laufend mehr Funktionalität zur Verfügung gestellt wird. Zu den wichtigsten Standard-Bestandteilen von Middleware zählen: Schnittstellendefinitionssprache (IDL) Übersetzungsprogramm für die Schnittstellendefinitionssprache Seite 18 von 41
Programmbibliotheken für RPC für die Entwicklung und die Laufzeitumgebung. Der Funktionsumfang von Middleware-Systemen variiert darüber hinaus sehr stark. Es ist daher zu unterscheiden, wie die Middleware orientiert ist: Transaktionsorientiert Objektorientiert Meldungsorientiert Service-orientiert Während bei den ersten drei Ansätzen der Schwerpunkt auf der engen Kopplung von Informationssystemen liegt, liegt der Service-orientierte Ansatz auf höherem Abstraktionsniveau: Eine service-orientierte Architektur ist eine Form einer verteilten Informationsarchitektur, deren Fokus auf der Ankündigung, dem Auffinden und dem dynamischen Aufrufen von hoch stehenden, anwendungsnahen und in sich abgeschlossenen Diensten liegt. Die Interaktion von Dienstanbieter, Dienstnachfrager und Dienstverzeichnis bei einer service-orientierten Architektur ist folgende: Seite 19 von 41
2.3 Distributed Computing Environment (DCE) DCE wurde Anfang der 90er Jahre von einem herstellerübergreifenden Konsortium, der Open Software Foundation, entwickelt. DCE ist ein Middleware-System aus zusammenhängenden Softwarekomponenten zur Realisierung verteilter Anwendungen in offenen heterogenen Netzwerken. DCE stellt Dienste und Werkzeuge zur Verfügung, um derartige Anwendungen zu erstellen, zu verwenden und zu warten. Die Komponenten von DCE kann man in zwei Kategorien einteilen: Seite 20 von 41
Programmbibliotheken für die Entwicklung von verteilten Systemen Dienste für die Verwaltung von Systemen Der Aufbau von DCE ist folgender: Um ein solches System einfacher verwalten zukönnen werden kleinere Einheiten gebildet, die unter Aufsicht einer Abteilung stehen, in denen eine hohe Kooperation und ein hohes Vertrauensverhältnis existiert. Diese Einheiten werden DCE-Zellen genannt. Ein Beispiel für eine solche DCE-Zelle ist folgendes: Seite 21 von 41
Der nächste Schritt ist die Konfiguration des DCE-Systems. Hierbei sind im wesentlichen zwei Ausprägungen zu unterscheiden. Bei der ersten handelt es sich um eine DCE- Zelle mit einem DFS-Server. Ein DCE-Klientrechner ist mit der nötigen DFS-Klientsoftware ausgestattet, wodurch er den Server nutzen kann: Seite 22 von 41
Die zweite Möglichkeit sind vernetzte DCE-Zellen, die die globalen Verzeichnisdienste von DCE nutzen und somit Zellendienste für andere Zellen nutzbar machen: Seite 23 von 41
2.4 Common Object Request Broker Architecture (CORBA) CORBA ist einer der wichtigsten Vertreter von Middleware- Systemen und erweitert die erste Generation von Middleware, die auf dem entfernten Funktionsaufruf mittels RPC beruhte, um objektorientierte Konzepte. CORBA ist ein Standard zur Entwicklung objektorientierter Anwendungen in verteilten und heterogenen Systemen. Die wichtigsten Bestandteile von CORBA sind der so genannte Objekt Request Broker (ORB), der die Kommunikationsinfrastruktur für die Kommunikation zwischen verteilten Objekten bereitstellt, eine Schnittstellenbeschreibungssprache mit mehreren Programmiersprachenanbindungen, eine Sammlung von Basisdiensten und Anwendungskomponenten. CORBA ist ein Standard der OMG. CORBA besteht aus einer Vielzahl von Spezifikationen, die aufeinander abgestimmt sind. Durch diese Spezifikationen werden sowohl Infrastrukturdienste wie Anwendungsdienste oder auch die Organisation und Verwaltung dieser Dienste beschrieben. Das zentrale Element der Objektverwaltung ist der ORB. Die Objektverwaltungsarchitektur ist folgende: Seite 24 von 41
Ein Objektsystem im Sinne von COBRA ist eine Sammlung von Objekten, die über wohldefinierte Schnittstellen kommunizieren. Einzelne Objekte bieten Dienste an (Serverobjekte), andere Objekte (Klientenobjekte) nutzen diese Dienste. Die Klientenobjekte sind von der eigentlichen Implementierung der Servers völlig abgekoppelt. Der ORB agiert bei einem Methodenaufruf als Vermittler zwischen den beteiligten Objekten: Seite 25 von 41
Für die serverseitige Verwaltung von Serverobjekten sieht CORBA so genannte Objektadapter vor, die eng mit dem ORB kooperieren. Ein Objektadapter Erzeugt für die von ihm verwalteten Serverobjekte eindeutige Objektreferenzen Aktiviert oder deaktiviert Instanzen der Serverobjekte Verteilt Abfragen an die entsprechenden Serverobjekte Benutzt die Objektskelette für die Rückumwandlung in interne Datentypen und Kümmert sich um den Methodenaufruf und die entsprechende Fehlerbehandlung. Ein serverseitiger Methodenaufruf sieht folgend aus: Darüber hinaus bietet CORBA zahlreiche Dienste an, um die Erstellung und Verwaltung von verteilten Anwendungen zu erleichtern: Seite 26 von 41
Namensdienst (ermöglicht, Objektreferenzen mit entsprechenden Namen zu versehen) Transaktionsdienst (regelt Transaktionen über verteilte Objekte durch einen Transaktionskoordinator) Persistenzdienst (dauerhaftes Speichern von Objektdaten) Sicherheitsdienst (bietet Authentifizierung, Zugriffskontrolle, etc.) Ereignisdienst ( realisiert asynchrone Kommunikation zwischen Objekten über Ereignisse) Abfragedienst (ermöglicht abfragesprachenabhängige Abfrage über Sammlung von Objekten) 2.5 Web-Services Während DCE und CORBA umfangreiche Implementierungen mit einer Vielzahl von Diensten bereits von zahlreichen Herstellern existieren, bilden Web-Services eine noch verhältnismäßig junge Technologie, die eigens Seite 27 von 41
für service-orientierte Architekturen auf Basis der Internet- Infrastruktur entwickelt wurde. Unter Web-Services versteht man lose gekoppelte, verteilte Dienste, die über Internet-basierte Protokolle und XML-Nachrichten in einer service-orientierten Architektur veröffentlicht, lokalisiert und dynamisch aufgerufen werden können. Die drei Kernstandards von Webservices sind SOAP für den Dienstaufruf, WSDL zur Dienstbeschreibung und UDDI als Verzeichnisdienst zum Ankündigen und Auffinden von Diensten. SOAP (simple objekt access protocol) ist ein Protokoll zum Austausch von strukturierter Information zwischen Softwarekomponenten in verteilten Systemen. SOAP- Seite 28 von 41
Nachrichten können mittels Übertragungsprotokollen wie etwa http oder SMTP zwischen den interagierenden Softwarekomponenten, den so genannten SOAP-Knoten übertragen werden. Es gibt drei Arten von SOAP-Knoten: 1. Der SOAP-Sender ist die Softwarekomponente, die eine SOAP-Nachricht erstellt und versendet. 2. Der SOAP-Empfänger ist die Softwarekomponente, für die eine SOAP-Nachricht bestimmt ist. 3. Der SOAP-Intermediär ist ein SOAP-Knoten, der eine SOAP-Nchricht auf dem Weg zum Empfänger verarbeitet, bzw. weiterleitet. Der Aufbau einer SOAP-Nachricht ist folgender: Seite 29 von 41
WSDL web services definition language) ist eine XMLbasierte Sprache zur Beschreibung von Web-Services. Diese Beschreibung definiert unter andere, welche Funktionen von den beschriebenen Web-Services bereitgestellt werden und wie ein Klientenprogramm möglichst automatisiert auf die Web-Services zugreifen kann. WCDL trennt explizit die Beschreibung der Schnittstelle der Dienste von der Beschreibung der Protokollbindungen. Auf diese Weise kann eine Schnittstellenbeschreibung mit mehreren Protokollbindungen angeboten werden. Ein WSDL-Dokument umfasst: 1. Die Definition von dienstspezifischen Argumenttypen 2. Die Definition von Nachrichtentypen 3. Die Schnittstellenbeschreibung 4. Die Protokollbindung 5. Die Dienstbeschreibung Seite 30 von 41
UDDI (universal description, discovery and integration) definiert einen Verzeichnisdienst für Web-Services. UDDI definiert ein Datenmodell für die Beschreibung von Web- Services und deren Anbietern. Mittel UDDI können die funktionalen Beschreibungen und die Nutzungsbeschreibungen von Web-Services veröffentlicht werden. Diese Information kann im Wesentlichen des WSDL-Beschreibungen von Web-Services entnommen werden. UDDI verfolgt sowohl das Ziel, Web-Service-Nutzer Seite 31 von 41
beim Auffinden benötigter Dienste zu unterstützen, als auch den automatisierten Dienstaufruf zu ermöglichen. 2.6 Vergleich der Middleware-Ansätze Nach Darstellung der verschiedenen Alternativen Für Middleware soll nun in folgender Tabelle eine Übersicht gegeben werden über die jeweilige Funktionalität: Seite 32 von 41
Hierbei ist jedoch zu beachten, dass nicht unterstützt nicht bedeutet, dass eine entsprechende Funktionalität unmöglich ist, sondern nur, dass diese im allgemeinen nicht integriert sind, aber durch Drittprodukte erzielt werden können. Seite 33 von 41
3 Mobiler Code Als mobiler Code wird Programmcode bezeichnet, der zwischen zwei Rechnern ausgetauscht wird, und zumindest auf dem Zielrechner zur Ausführung gelangt. Im Fall einer objektorientierten Realisierung werden die übermittelten Programmiersprachenobjekte als mobile Objekte bezeichnet. Prinzipiell können beliebig komplexe Programme/Komponenten die Mobilitätseigenschaft aufweisen. Dieses Wandern von Softwarekomponenten von Rechner zu Rechner bezeichnet man als Programmmigration. Durch die Verwendung von mobilem Code steht eine weitere Middleware-Technik zur Verfügung, die von der Übermittlung von Aufträgen in Form von Dienstaufrufen und Argumenten deutlich abweicht. Durch mobilen Code kann ein Auftrag in Form eines Programms zwischen Systemen weitergegeben werden. Seite 34 von 41
4 Verteilte Softwaresysteme In diesem Abschnitt werden die wichtigsten Typen von verteilten Systemen dargestellt. Es handelt sich dabei um Datenbanksysteme, verteilte Anwendungssysteme und verteilte Web-Systeme. 4.1 Verteilte Datenbanksysteme Unter einem verteilten Datenbanksystem versteht man ein Datenbanksystem, das als verteiltes System realisiert ist. Dabei werden logisch zusammengehörende und gemeinsam verwaltete Daten einer Datenbank physisch auf mehrere, durch ein Rechnernetz verbundene Rechner verteilt. Ein lokales Teilsystem der verteilten Datenbank kann dabei vielfach autonom lokale Anwendungen bedienen. Darüber hinaus unterstützt das lokale Teilsystem globale Dienste, die über das Netzwerk abgewickelt werden. Der Aufbau eines verteilten Datenbanksystems ist folgender: Seite 35 von 41
Das gesamte Datenbanksystem besteht also im Gegensatz zu einem Client-Server-System aus einer Reihe von lokalen, autonomen und gleichrangigen Teilsystemen, die über ein Netzwerk kommunizieren können. 4.2 Verteilte Anwendungssysteme Unter der betriebsübergreifenden Anwendungsintegration versteht man die Integration von heterogenen, autonomen Anwendungssystemen, die entweder innerhalb eines Betriebs oder zwischen Betrieben stattfindet. Die Anwendungsintegration wird durch eine lose Kopplung von Anwendungssystemen wesentlich vereinfacht. Für die lose Integration von Anwendungssystemen unterscheidet man mehrere prinzipielle Integrationsarten, je nachdem, auf welcher Schicht die Integration stattfindet: Integration auf der Persistenzschicht, auf der Anwendungsund auf der Präsentationsschicht. Seite 36 von 41
Die Integration von Anwendungen über (zwischen-) gespeicherte Daten wird als Anwendungsintegration auf der Persistenzschicht bezeichnet. Bei der Anwendungsintegration auf der Anwendungsschicht werden in den beteiligten Applikationen Schnittstellen geschaffen, damit die laufenden Anwendungen direkt miteinander kommunizieren können. Dies erfolgt vielfach durch Middleware. Ein Vorteil dieser Integrationsform gegenüber der Integration auf der Persistenzschicht ist, dass die Anwendungen die angefragten Werte nicht Zwingenderweise vorhalten und speichern müssen, sondern dass diese bei Bedarf in der benötigten Form erzeugt werden. Bei der Anwendungsintegration auf der Präsentationsschicht werden die bestehenden Benutzerschnittstellen eines Anwendungssystems genutzt, um automatisiert mir weiteren Anwendungssystemen Daten auszutauschen. Diese Integrationsform eignet sich auch für Programme, die nur in ausführbarer Form vorliegen. Seite 37 von 41
4.3 Verteilte Web-Systeme Durch die steigende Internet-Nutzung steigt auch die Anzahl der potentiellen Benutzer der öffentlich zugänglichen Webserver. Die Nutzungsintensität der Server unterscheidet sich allerdings wesentlich. Während wenig genutzte Server etwa bis zu 10.000 Anfragen pro Tag verarbeiten, werden andere Server oft viele Millionen Mal pro Tag angefragt. Die Verarbeitungsgeschwindigkeiten pro Anfrage kann dabei ebenso schwanken. Während auf heutigen Intelbasierten Maschinen ein Webserver je nach verfügbarer Bandbreite und Rechnerleistung leicht über 1.000 statische Web-Ressourcen pro Sekunde liefern kann, ist die Berechnung von dynamischen Web-Inhalten weit aufwändiger. Man spricht von einer statischen Web-Ressource, wenn diese als Datei im Dateisystem des Webservers abgelegt ist. Dynamische Web-Ressourcen werden erst beim Einlangen einer Anfrage auf einem Webserver zusammengestellt. Die Dimensionierung der Hard- und Software ist somit gerade für Web-Systeme einrelativ schwieriges Problem, da zu lange Wartezeit zu entgangenem Umsatz führt: Seite 38 von 41
Seite 39 von 41
5 Marktsituation Peer-to-Peer-Systeme: Unter einem Peer-to-Peer-System versteht man ein kommunikationssystem, bei dem jedem Teilnehmer dieselben Möglichkeiten der Kommunikation zur Verfügung stehen und jeder Teilnehmer direct Verbindungen zu anderen Teilnehmern aufbauen kann. Das Wort peer steht dabei für Gleichrangiger. Ein Knoten in einem P2P-System kann sowohl als Klient als auch als Server fungieren. Ein P2P-System stellt also ein flüchtiges Kommunikationsnetz dar, mit dessen Hilfe Endbenutzer, welche dieselbe P2P-Software verwenden, direkt untereinander Daten austauschen können: Client/Server P2P-System Seite 40 von 41
Eine weitere Entwicklung ist Grid-Computing: Unter Grid-Computing versteht man eine verteilte Infrastruktur aus Hard- und Software, die einen Rechnercluster in Form eines virtuellen Supercomputers bildet. Der Computer-Grid besteht aus einer Vielzahl von einzelnen vielfach unterschiedlichen Rechnern, die ihre Rechenleistung dem Cluster zur Verfügung stellen. Ziel des Grid-Computing ist die Bereitstellung eines zuverlässigen, konsistenten, kostengünstigen und skalierbaren Zugangs zu Rechnerkapazitäte Seite 41 von 41