Kapitel 09 Client-Server-Anwendungen. 9 Client-Server-Anwendungen

Transkript

1 Kapitel 09 Client-Server-Anwendungen 9 Client-Server-Anwendungen 9 Client-Server-Anwendungen Allgemeines Definition der Client/Server-Architektur Kooperation und Kommunikation im Client/Server- Modell Architekturaspekte Verschiedene Realisierungsformen von C/S-Modellen Architekturaspekte Beispiele für verteilte Funktionalitäten Beispiel für verteilte Präsentation (Schnitt 1) Beispiel für verteilte Applikationsfunkt. (Schnitt 3).8 Seite 1

2 9.6 Basistechnologien Remote Procedure Call (RPC) Kommunikationsdienste Autorisierung, Authentifizierung und geschützte Übertragung Common Request Broker Architecture (CORBA) Remote Database Access (RDA) TP-Monitore Transaktionskonzept für lange Transaktionen...25 Seite 2

3 9.1 Allgemeines Man unterscheidet gewöhnlich drei Inhalte für den Begriff Client-Server : 1. Sicht: Ablösung von Zentralrechnern 2. Sicht: keine direkter Datenzugriff 3. Sicht: verbesserte Informationsbereitstellung 9.2 Definition der Client/Server-Architektur Definition: Unter der Client-Server-Architektur (engl.: client-server architecture) versteht man eine kooperative Informationsverarbeitung in offenen Systemen oder mit Hilfe offener Systeme. Bemerkungen: Es lassen sich verschiedene Rollen unterscheiden: Server (= Dienstleister; Backend) Clients (= Kunden; Frontend) Seite 3

4 9.3 Kooperation und Kommunikation im Client/Server-Modell Die Kommunikation zwischen einem Client-Programm und dem Server-Programm basiert auf Transaktionen, die vom Client generiert und dem Server zur Verarbeitung überstellt werden. Grundschema der Kooperation bzw. Kommunikation: Die Initiative zu einer Interaktion geht immer vom Client aus. Der Client formuliert Aufträge und schickt diese zur Ausführung an einen Dienstanbieter, auch Server genannt. Der Server schickt das Resultat des Auftrags an den Client zurück. Für jeden Server ist dabei festgelegt, welche Arten von Diensten er anbietet. Seite 4

5 Interaktionen im Client/Server-Modell: Client Server 1.Auftrag 2. Bearbeitung 3. Resultat/Antwort Verschiedene Rollen im Client/Server-Modell: Client Server/Client Server 1.Auftrag 1.Auftrag 3. Resultat/Antwort 3. Resultat/Antwort Seite 5

6 9.4 Architekturaspekte Verschiedene Realisierungsformen von C/S-Modellen Man kann Applikationen in drei abstrakte Schichten bzw. Komponenten mit unterschiedlichen Funktionalitäten unterteilen: Präsentationsfunktion Applikationsfunktion Datenveraltungsfunktion Komponenten einer Applikation: Präsentationsfunktion Applikationsfunktion Datenverwaltungsfunktion Datenbank Seite 6

7 Eine solche Architektur lässt sich an fünf Stellen zerlegen. Mögliche Funktionsteilungen sind dabei: Präsentation Applikation Datenverwaltung Client Server Erläuterungen zu den Schnitten Schnitt 0: Schnitt 1: Schnitt 2: Schnitt 3: Schnitt 4: Schnitt 5: Keine Zerlegung Verteilte Präsentation Entfernte Präsentation Verteilte Applikationsfunktion Entfernter Datenbankzugriff Verteilte Datenbank oder Dateiserver Seite 7

8 9.5 Architekturaspekte Beispiele für verteilte Funktionalitäten Beispiel für verteilte Präsentation (Schnitt 1) Das bekannteste System für verteilte Präsentation ist X- Windows, das am MIT entwickelt worden ist. Es besteht aus zwei Komponenten: X-Server bzw. X-Display-Server: Der X-Server läuft auf dem Rechner des Benutzers und übernimmt die Verwaltung der Fenster seiner X-Clients. X-Clients: Die X-Clients können auf demselben oder auch anderen Rechnern wie der X-Server laufen Beispiel für verteilte Applikationsfunkt. (Schnitt 3) Ein Teil der Applikation wird auf dem Client- und ein anderer auf dem Server-System ausgeführt. Seite 8

9 Doch die Realisierung von C/S-Systemen mittels entferntem Datenbankzugriff kann dazu führen, dass zur Ausführung einer bestimmten Anwendungsfunktion viele entfernte Datenbankaufrufe notwendig werden. Beispiel: Ein Informationssystem zur Verwaltung von Bestellungen Relation Lieferanten Relation Bestellungen Relation Bestell-Positionen Lieferanten LiefNr LiefName... AnzBestGesamt BestSummeGesamt Bestellungen BestNr LiefNr... AnzPosten BestSumme BestellPositionen BestNr PosNr ArtNr... BestWert Seite 9

10 Implementation der Teilfunktion Verbuchung Warenzugang mittels eines (entfernten) Datenbankzugriffs: 1. SELECT-Zugriff auf Lieferant: über Lief-Nr. oder Lief-Name. 2. SELECT-Zugriff auf Bestellungen: über Lief-Nr. 3. SELECT-Zugriff auf Bestell-Positionen: über Best-Nr. 4. DELETE-Zugriff auf Bestell-Positionen: ein Tupel wird gelöscht 5. UPDATE-Zugriff auf Bestellungen: Aktualisierung von AnzPosten und Best-Summe 6. UPDATE-Zugriff auf Lieferanten: Aktualisierung von Best-SummeGesamt 7. COMMIT für alle Änderungsoperationen Mechanismen zur Funktionsverteilung: Stored Procedure Stored Function Trigger Mit Hilfe folgender Basistechnologien: Remote Procedure Call (RPC) Remote Function Call (RFC) Seite 10

11 Stored Procedure: Vereinfachung und Reduzierung der Datenbankzugriffe durch Zusammenfassung in einer Stored Procedure: einmal DELETE-Zugriff zweimal UPDATE-Zugriff einmal COMMIT-Zugriff der Form: DeleteBestPos(LiefNr, BestNr, BestPos, BestWert) Beispiel-Pseudocode für eine Stored Procedure: CREATE PROCEDURE DeleteBestPos ( LiefNr INTEGER, BestNr INTEGER, PosNr INTEGER, BestWert DECIMAL(7,2)) BEGIN /* Prozedurrumpf */ Seite 11

12 DELETE FROM BestellPositionen WHERE BestNr = :BestNr AND PosNr = :PosNr; ON ERROR GOTO Fehler; UPDATE Bestellungen SET AnzPosten = AnzPosten - 1, BestSumme = BestSumme - :BestWert WHERE BestNr = :BestNr; ON ERROR GOTO Fehler; UPDATE Lieferanten SET BestSummeGesamt = BestSummeGesamt - :BestWert WHERE LiefNr = :LiefNr; ON ERROR GOTO Fehler; COMMIT WORK; GOTO Ende; Fehler: ROLLBACK WORK; SQL_STATUS_CODE :=...; Seite 12

13 Ende: END; /* Prozedurrumpf */ Trigger: Ein Trigger ist eine Art Stored Procedure, die jeweils mit einem bestimmten Datenbankobjekt assoziiert ist und auf Ereignisse (events) bezüglich dieses Objekts reagiert. Bestandteile eines Triggers: einer Ereignisspezifikation einem Bedingungsteil einem Aktionsteil (event) (condition) (action) Seite 13

14 Beispiel-Pseudocode für einen Trigger: CREATE TRIGGER AfterDeleteBestPos AFTER DELETE ON BestellPositionen FOR EACH ROW DECLARE LiefNr Integer; /* Hilfsvariable */ BEGIN /* Prozedurrumpf */ SELECT LiefNr /* Ermittlung LieferantenNr */ INTO :LiefNr /* Speicherung in LiefNr */ FROM Bestellungen WHERE BestNr = old.bestnr; ON ERROR GOTO Ende; UPDATE Bestellungen /* Aktualisierung Bestellungen */ SET AnzPosten = AnzPosten -1, BestSumme = BestSumme - DelTupel.BestWert WHERE Best = old.bestnr; ON ERROR GOTO Ende; Seite 14

15 UPDATE Lieferanten /* Aktualisierung Lieferanten */ SET BestSummeGesamt = BestSummeGesamt - DelTupel.BestWert WHERE LiefNr = :LiefNr; Ende: END; /* Prozedurrumpf */ Probleme der Trigger-Programmierung Bei der Trigger-Programmierung ergeben sich die folgende Probleme: Ungewollte Kaskadierungseffekte Reihenfolge der Aktivierung ist nicht festgelegt Anzahl der Trigger ist bei vielen Implementierungen beschränkt Seite 15

16 9.6 Basistechnologien Remote Procedure Call (RPC) Kommunikationsdienste Common Request Broker Architecture (CORBA) Remote Database Access (RDA) TP Monitore Transaktionskonzept für lange Transaktionen Remote Procedure Call (RPC) Formal gehaltene Definition: Remote Procedure Call (RPC) RPC ist die synchrone Kontrollfluss- und Datenübergabe in Form von Prozeduraufrufen und von aktuellen Parametern zwischen Programmen in unterschiedlichen Adressräumen über einen schmalen Kanal im Sinne von Durchsatz und Verweilzeit. RPC und Kommunikation: Der RPC dient zur Kommunikation zwischen zwei Prozessen einer verteilten Anwendung. Auch hier spricht man von einem Client und einem Server. Seite 16

17 Dazu werden üblicherweise zwei Stummel (stub) Prozeduren, der Client-Stub und der Server-Stub, verwendet, die das Einund Auspacken der Aufrufparameter und Ergebnisse sowie deren Versand und Empfang erledigen. Ablaufschema eines RPC: Client Server Client Stub Anwendungsprogramm Kommunikations- Komponente Kommunikations- Komponente Server Stub Server- Programm Prozeduraufruf Verpacken Aufrufparameter Vorgang Übertragung Aufruf Warten Ampfang Aufruf Auspacken Aufrufparameter Vorgang Prozeduraufruf Abarbeitung Rückgabeergebnis Auspacken Ergebnis Empfang Ergebnis Übertragung Ergebnis Verpacken Ergebnis Ergebnis Rückgabe Prinzipielle Schwäche des RPC-Mechanismus Fehler im Netz. Absturz des Clients. Absturz des Servers. Serverprobleme können dazu führen, dass Applikationen hängen. Seite 17

18 RPCs können in semantische Klassen eingeteilt werden: kann sein (may-be-) Semantik höchstens einmal (at most one-) Semantik mindestens einmal (at least once-) Semantik genau einmal (exactly once-) Semantik Kommunikationsdienste Man unterscheidet folgende Kommunikationsdienste: interne Kommunikation externe Kommunikation: Realisierung der internen Kommunikation: Nachrichtenkanäle (pipes / named pipes) Nachrichtenwarteschlangen (message queues) gemeinsam genutzte Speicherbereiche (shared memory) Realisierung der externen Kommunikation: sog. Steckdosen (sockets) Seite 18

19 9.6.3 Autorisierung, Authentifizierung und geschützte Übertragung Empfindliche Schwachstelle bei der Datenübertragung über bei C/S-Systemen: Ungeschütze Übertragung von Passwörtern Ungeschützte Übertragung (sensibler) Antwortdaten Zwei potentielle Grundstrategien: Keine Übertragung sensibler Daten Überprüfung der Identität der beteiligten Prozesse (Authentisierung) Seite 19

20 Ablaufschema im Rahmen der Schutzmechanismen: Administrator Security Server Edit Benutzer eintragen Registy Server Benutzer Authentifik. per Name Ticket (mit Passwort verschlüsselt) Authentification Server Security DB Login Autoris. (mit Ticket) Privilege Server PAC Server Anwendungs- Client Autoris. (mit Ticket) Anwendungs-Server ACL Manager Common Object Request Broker Architecture (CORBA) Die OMG entwickelt dazu zwei verschiedene Standards / Architekturen: Object Management Architecture (OMA) Object Request Broker Architecture (ORBA) Seite 20

21 Bestandteile der Object Management Architecture (OMA): Application Objects: [Emente des Anwendungskerns] Object Request Broker (ORB): [Vermittelt zwischen den Objekten] Object Service: [Basisdienste wie Sicherheit, Ereignisbehandlung, etc.] Common Facilities: [Sammlung von allgemein verwendbaren Routinen, wie beispielsweise zum Drucken oder zur Behandlung von Fehlern.] Application Objects Common Facilities Object Request Broker Object Services Seite 21

22 Zusammenhang ORB CORBA: Die Common Object Request Broker Architecture (CORBA) konkretisiert Aufbau, Funktionalität und Schnittstellen eines ORBs. ORBs sind umgekehrt die technischen Implementationen des Standards CORBA. Bemerkungen zu CORBA: Aufrufer Server Object Dynamische Schnittstelle Statische IDL Stubs ORB-Schnittstelle IDL Skeleton Object Adapter ORB-Kern Schnittstellenverzeichnis (interface repository) Implementierungsverzeichnis (implementation repository) Remote Database Access (RDA) Viele DBMS-Hersteller bieten durch sog. Database Gateways die Möglichkeit zum Zugriff auf entfernte Datenbanken an. Seite 22

23 Der ISO-RDA-Standard besteht aus zwei Teilen: In der generischen RDA (IS ) werden die Funktionen zum Initialisieren, Öffnen, etc. der Verbindung beschrieben, die unabhängig vom Typ des DBMS gelten. In der spezifischen RDA (IS ) ist beschrieben, welche SQL-Kommandos unterstützt werden. Hier wird im Prinzip einfach auf den jeweiligen SQL-Standard verwiesen. RDA-Kommunikationsdienste Dialogverwaltung Ressourcen-Verwaltung Datenbanksprachenunterstützung Kontrolldienste TP-Monitore Merkmale erster IS-Anwendungen waren: viele anzuschließende Benutzer bzw. Endgeräte diese alle benutzen dasselbe Anwendungsprogramm Seite 23

24 Als Lösung wurden TP-Monitore entwickelt: die TP-Monitor-Software übernahm die Prozess- und Ressourcenverwaltung Sharing von Anwendungen Realisierung virtueller Terminals Arbeitsweise und Bestandteile von TP-Monitoren: Das User Interface Der TP-Controller Das Application Program Interface Das Data Interface Seite 24

25 9.6.7 Transaktionskonzept für lange Transaktionen Motivation: Bestimmte Arbeiten erstrecken sich über Stunden, Tage, Wochen oder Monate. Dabei können prinzipiell immer Systeme ausfallen und Informationen verloren gehen. Grundidee der Verarbeitung langer Transaktionen: Der Client sperrt das Objekt auf dem Server. Er kopiert (check-out) es in einem privaten (Client-) Arbeitsbereich. Nach ggf. durchgeführten Änderungen spielt er es wieder auf den Server zurück (check-in). Die darauf gesetzten Sperren wird wieder freigegeben. Seite 25