12. client/server-anwendungen - informatik.uni-ulm.de · client/server-anwendungen 12-1 12....

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme12. Client/Server-Anwendungen 12-1

12. Client/Server-Anwendungen

12.1 Allgemeines

p "Client/Server" - ein Modewort und vielschichtigerBegriff

p Wird in verschiedenen Kontexten mit verschiedenerBedeutung verwendet:

m Downsizing / Rightsizing

m Datenkapselung

m Informationsserver / Data Warehouse

p Ziel dieses Kapitels

m Vorstellung des Client/Server-Verarbeitungsmodells

m Vorstellung der Architekturvarianten

m Kurze Vorstellung der Basis-Technologien für dieImplementierung

m Aufzeigen von Fallstricken


12.2 Das Client/Server-Modell

p Das Client/Server-Modell - C/S-Modell - ist einSoftware-Architektur-Modell

p Zwei Komponententypen: Client und Server

p Grundschema der Kooperation

m Die Initiative zu einer Interaktion geht stets vom Klienten(Client) aus.

m Der Client formuliert Aufträge und schickt diese zurAusführung an einen Dienstanbieter (Server).

m Für jeden Server ist festgelegt bzw. bekannt, welcheArten von Diensten (Services) er anbietet.

p Typisch für C/S-Modell:

m Asymmetrie der Rollen bzw. Funktionen.

m Das Modell legt die Rolle der Beteiligten (Client oderServer) sowie die Abfolge der Interaktionsschritte fest(siehe Abb. 12-1).

m Ein Client kann im Laufe einer Verarbeitung auf mehrereServer zugreifen

m ... und ein Server kann mehrere Clients bedienen

m Ein Server kann im Rahmen einer Auftragsbearbeitungselbst auch wieder Client sein (siehe Abb. 12-2).


1. Auftrag

3. Resultat/Antwort

Client Server

2. Bearbeitung

Abb. 12-1: Interaktionen im Client/Server-Modell

Client Server/Client Server

Auftrag

Resultat/Antwort

Auftrag

Resultat/Antwort

Abb. 12-2: Verschiedene Rollen bei Auftragsausführung


12.3 Architekturaspekte

p Viele verschiedene Realisierungsformen von C/S-Systemen möglich

p Die Unterschiede liegen hauptsächlich in der Aufteilungder Funktionen des Anwendungssystems (Applikation)zwischen Client- und Server-System

p Komponenten einer Applikation

m Präsentationsfunktion

Gesamte Handhabung der Ein-/Ausgabe (Tastatur, Maus, ....,Bildschirm, Drucker, ...)

m ApplikationsfunktionEigentliche anwendungsspezifische Programm- und Ablauflogik;benutzt Präsentations- und Datenverwaltungsfunktionen (z.B.mittels embedded SQL) zur Realisierung

m DatenverwaltungsfunktionRealisieren den physischen Zugriff auf die Daten mittels Datei-oder DB-Schnittstelle.

Präsentations-Funktionen

Applikations-Funktionen

Datenverwaltungs-Funktionen

DB

Abb. 12-3: Komponenten einer Applikation


p Verschiedene "Schnitte" möglich:

Client Server

0 1 2 3 4 5

Präsentation DatenverwaltungApplikation

Abb. 12-4: Mögliche Funktionsverteilungen

Schnitt 0: (= keine Zerlegung) Typische Zentralrechner-anwendung: Vom Datenzugriff über Applikations-logik bis zum Bildschirmaufbau wird alles vomZentralsystem erledigt.

Schnitt 1: Verteilte Präsentation. Die Präsentationsfunktionwird hierbei in eine Server- und eine Client-Komponente aufgespalten (siehe Abs. 12.3.1).

Schnitt 2: Entfernte Präsentation. Vom Grundgedanken hertraditionelle Terminal-Host-Konfiguration. Die Appli-kation steuert, im Gegensatz zur verteiltenPräsentation, den Bildschirm durch entsprechendeKommandosequenzen unmittelbar selbst.

Ein Terminalemulationsprogramm auf einem PC,das mit einem Hostsystem verbunden ist, wäre einBeispiel für eine solche C/S-Variante.


Schnitt 3: Verteilte Applikationsfunktion. Ein Teil derApplikation auf dem Client-, ein anderer auf demServersystem ausgeführt (siehe Abs. 12.3.3).

Schnitt 4 C/S-Variante mit entferntem Datenbankzugriff(remote database access; RDA), der über einesemantisch hohe Schnittstelle (wie z. B. SQL)realisiert wird (siehe Abs. 12.3.2).

Schnitt 5 C/S-Variante, bei welcher der Server auf einenreinen Dateiserver (file server) bzw. Pageserverreduziert wird. Die Umsetzung logische Satz-adresse (z.B. über TID) in physische Adresse wirdclientseitig durchgeführt.


12.3.1 Verteilte Präsentation

p Bekanntestes System für verteilte PräsentationX-Windows1

p Zwei Komponenten: X-(Display-)Server + X-Client(s)

p Der X-Server

m läuft auf dem Rechner des Benutzers und verwaltet dieFenster seiner X-Clients.

m bietet den X-Clients Ein- und Ausgabedienste an, mittelsderer diese die gewünschte Anwendungsfunktionalität(bzgl. Ein-/Ausgaben) realisieren

m stellt auf seinem Bildschirm die Fenster (X-Windows) darund registriert Maus- und Tastatureingaben

p Die X-Clients

m können auf demselben oder auch einem anderenRechner wie der X-(Display-)Server laufen

m sind hinsichtlich der Ein-/Ausgabe ortsunabhängig.

p Der Benutzer kann auf seinem Bildschirm mit mehrerenAnwendungen gleichzeitig arbeiten

p und kann zwischen diesen mittels Cut & Paste(unterstützt durch den X-Server) Daten austauschen

p Die Programmierschnittstelle zwischen X-Server undX-Client ⇒ X-Bibliothek

1 1984 am MIT (Massachusetts Institute for Technology) entwickelt


X-Display-Server X-Client

Applikation

Rechner A Rechner B

X-Display-Server X-Client

Applikation

Rechner A

a) nichtverteilte Lösung b) verteilte Lösung

Datei Bearbeiten Zeichnen HilfeAnordnen Datei Bearbeiten Zeichnen HilfeAnordnen

Abb. 12-5: X-Windows-basierte Applikation


12.3.2 Entfernter Datenbankzugriff

p "Schnitt 4" in Abb. 12-4

m Die gesamte Datenverwaltungsfunktionalität wird aufdem Serversystem bereitgestellt.

m Die gesamte Applikationsfunktionalität liegt auf demClient-System.

p Der Client bedient sich hierbei einer semantisch „hohen“Schnittstelle, wie z. B. SQL oder eines objektorientiertenPendants.

p Die physischen Aspekte des Zugriffs, insbesondere dergezielte Zugriff auf Datenbankseiten, Indexe u. ä.bleiben hierdurch vor dem Client verborgen.

p Im einfachsten Fall bedient sich das Clientsystem der„normalen“ Datenbankschnittstelle des eingesetztenDBMS, wie z. B. Embedded SQL.

p Für die Anwendung ist es in diesem Fall völligtransparent, ob die Datenverwaltungsfunktionalität aufdemselben Rechner oder auf einem entfernten Rechnerangeboten wird oder ob es sich um den Zugriff auf einverteiltes DBMS handelt.

p Viele DBMSe bieten über diese Schnittstelle auch dentransparenten Zugriff auf Daten anderer Datenbankendesselben oder anderer Hersteller an⇒ Database Gateways (proprietäre Lösung!)

p Das eigene Server-DBMS fungiert dabei quasi als"Vermittler" (zu Einschränkungen siehe Abs. 5.6).


12.3.3 Verteilte Applikationsfunktion

p "Schnitt 3" in Abb. Abb. 12-4.

p Merkmal: Ein Teil der Applikation wird auf dem Client-ein anderer auf dem Server-System ausgeführt.

p Problemstellung in der Regel: Verteilung so wählen, daßKommunikationsaufwand möglichst gering wird

p Beispiel 12-1:

Gegeben sei ein Informationssystem, das Bestellungen verwaltet.

m Relation Lieferantenn AnzBestGesamt = die Anzahl der aktuell noch offenen

Bestellungen bei diesem Lieferantenn BestSummeGesamt = (ggf. restlicher) Gesamtwert dieser

Bestellungen an.

m Relation Bestellungenn AnzPosten = aktuelle Anzahl der (ggf. restlichen)

Bestellpositionen dieser Bestellungn BestSumme = (ggf. restlicher) Gesamtwert dieser Positionen

(= Summe über alle BestWert-Attribute einer Bestellung).

m Relation BestellPositionen

= die einzelnen Positionen der Bestellungen

Lieferanten LiefNr LiefName ... AnzBestGesamt BestSummeGesamt

Bestellungen BestNr LiefNr AnzPosten BestSumme

BestellPositionen PosNr ArtNr BestWert

...

BestNr ...

Abb. 12-6: Relationen für Bestell-Informationssystem


Datenbankzugriffe für die Implementierung der Teilfunktion"Verbuchung Warenzugang":

1. SELECT-Zugriff auf Lieferant: über LiefNr oder LiefName.

2. SELECT-Zugriff auf Bestellungen: über LiefNr.

3. SELECT-Zugriff auf BestellPositionen: über BestNr.

4. DELETE-Zugriff auf BestellPositionen: ein Tupel wirdgelöscht.

5. UPDATE-Zugriff auf Bestellungen: Aktualisierung vonAnzPosten und BestSumme.

6. UPDATE-Zugriff auf Lieferanten: Aktualisierung vonBestSummeGesamt.

7. COMMIT für alle Änderungsoperationen.

Bei dieser Vorgehensweise sind also insgesamt sieben (entfernte)Datenbankaufrufe erforderlich. 2

Alternative: Stored Procedure

Naheliegende Funktionsaufteilung in diesem Fall:

Zusammenfassung der DELETE- und UPDATE-Anweisungen ineiner Stored Procedure⇒ DeleteBestPos(LiefNr, BestNr. BestPos, BestWert)

Damit:

Schritte 1 - 3 wie oben

Schritte 4 - 7 als Stored-Procedure-Aufruf

2 Durch Verwendung eines Joins könnten zwar die ersten drei Aufrufe im Prinzip zueinem Aufruf zusammengefaßt werden, damit würde sich allerdings das zuübertragende Datenvolumen stark aufblähen und auch die Verarbeitung imAnwendungsprogramm (Zerlegen des Join-Resultats in die Bestandteile „Lieferant“,„Bestellung“ und „BestellPositionen“) komplizierter werden, so daß man dies in derRegel nicht tun wird.


CREATE PROCEDURE DeleteBestPos ( LiefNr INTEGER,BestNr INTEGER,PosNr INTEGER,BestWert DECIMAL(7,2))

BEGIN /* Beginn Prozedurrumpf */DELETEFROM BestellPositionenWHERE BestNr = :BestNr AND PosNr = :PosNr;

ON ERROR GOTO Fehler;

UPDATE BestellungenSET AnzPosten = AnzPosten -1,

BestSumme = BestSumme - :BestWertWHERE BestNr = :BestNr;


UPDATE LieferantenSET BestSummeGesamt = BestSummeGesamt - :BestWert

WHERE LiefNr = :LiefNr;


COMMIT WORK;GOTO Ende;

Fehler:ROLLBACK WORK;SQL_STATUS_CODE := ....;

Ende:END; /* Ende Prozedurrumpf */

Abb. 12-7: Stored Procedure 3

3 Stored Procedures, Stored Functions und Triggers sind in SQL-92 noch nichtdefiniert, sondern erst für SQL-3 vorgesehen. Sie werden jedoch von einigenrelationalen DBMSen – allerdings in syntaktisch unterschiedlichen Formen – bereitsheute angeboten.

Hostvariable


Alternative dazu: Trigger

Löschoperation (Schritt 4) noch "von Hand", restliche Updatesdann über Trigger-Prozedur.

Ablauf hier:

Schritte 1- 4 wie gehabt

Schritt 5 (faßt mittels Trigger die Schritte 5-7 zusammen)

CREATE TRIGGER AfterDeleteBestPosAFTER DELETE ON BestellPositionenFOR EACH ROW

DECLARELiefNr Integer; /* Deklaration Hilfsvariable */

BEGINSELECT LiefNr /* Ermittlung LieferantenNr */INTO :LiefNr /* und Speicherung in LiefNr */FROM BestellungenWHERE BestNr = old.BestNr;

ON ERROR GOTO Ende;

UPDATE Bestellungen /* Aktualisierung Bestellungen */SET AnzPosten = AnzPosten - 1,

BestSumme = BestSumme - old.BestWertWHERE BestNr = old.BestNr;

ON ERROR GOTO Ende;

UPDATE Lieferanten /* Aktualisierung Lieferanten */SET BestSummeGesamt =

BestSummeGesamt - old.BestWertWHERE LiefNr = :LiefNr;

Ende:END;

Abb. 12-8: Trigger

Zugriff auf alten Tupelwert


p Probleme bei der Verwendung von Triggern

m Erschwerte Wartung: Ggf. zwei Programm zu ändern

m Kaskadierungseffeke (Trigger aktiviert Trigger ...)

m Aktivierungsreihenfolge manchmal schwerdurchschaubar (bei Systemen, die mehrfache Triggereines Typs (ON UPDATE, ON DELETE, ...) je Tabellezulassen)

m Fehlerpotential bei Systemen, die nur einen Triggereines Typs je Tabelle zulassen⇒ Fallunterscheidung innerhalb des Triggers⇒ "WHEN-Bedingung" wird immer unspezifischer

p Zusammenfassung

m Stored Procedures / Trigger die "Datenbank-Lösung" fürverteilte Applikationsfunktion

m kann helfen - wo geeignet -, die Performanz signifikantzu verbessern

p Wegen der Wartungsproblematik

m Stored Procedures und Trigger mit Augenmaßeinsetzen!

m Wartung mit bedenken

m Verlust an Portabilitiät bedenken


12.4 Basistechnologien

p Im folgenden exemplarische und skizzenhafteBehandlung einiger Basistechnologien, die bei derRealsierung eines C/S-Systems oftmals direkt oderindirekt zum Einsatz kommen.

12.4.1 Remote Procedure Call (RPC)

p Bekannteste Vertreter:

m Sun-RPC

m DCE-RPC (der OSF4)

p Zwei Teile:

m Client-Stub

⇒ "entfernter" Prozeduraufruf auf dem Client

m Server-Stub

⇒ "echter" Prozeduraufruf auf dem Server

p Beschreibung der Schnittstellen mittels speziellerInterface Description Language (IDL), die jeweils andie Syntax der verwendeten Programmierspracheangelehnt ist.

p IDL-Compiler erzeugt daraus dann den "echten" Aufruf-Code

4 Open Software Foundation


Client-Stub Server-Stub

Warten Abarbeitung

Client Server

Anwendungs-programm

VerpackenAufruf-parameter

Prozedur-aufruf

RückgabeErgebnis

AuspackenErgebnis

EmpfangErgebnis

Kommunikations-Komponente

ÜbertragungAufruf

Kommunikations-Komponente

Server-Programm

Prozedur-Aufruf

EmpfangAufruf

AuspackenAufruf-parameter

Ergebnis-rückgabe

VerpackenErgebnis

ÜbertragungErgebnis

Abb. 12-9: Ablauf eines RPC


p Potentielle Probleme:

m fehlender Time-out-Mechanismus

m falls nicht vorhanden, komplexe Eigen-Implementierung(⇒ paralleler Thread)

m dadurch erhöhtes Blockierungs- bzw. Fehlerrisiko

p RPC-Ausführungssemantiken

m "kann sein" (may-be)-Semantik: Ausführung ohneGarantie über die Häufigkeit der Prozedurausführungenin Fehlerfällen

m "höchstens einmal" (at most once)-Semantik: maximaleinmalige Ausführung der Prozedur auf Serverseite,ggf. mehrfach auf Serverseite eintreffende Aufruf-aufforderungen werden ignoriert,

m "mindestens einmal" (at least once)-Semantik: dieProzedur wird mindestens einmal auf dem Serverausgeführt (evtl. auch mehrfach),

m "genau einmal" (exactly once)-Semantik: die Prozedurwird genau einmal ausgeführt.

Anmerkung:

Diese Ausführungssemantiken werden vor allem dannwichtig, wenn es mehrere Server im Netz geben kann, dieeinen bestimmten Dienst erbringen können.


p Für transaktionsorientiertes Arbeiten verlangt dereinfache RPC dem Anwendungsentwickler einenerheblichen Entwurfs- und Implementierungsaufwandab, um die sichere bzw. atomare Ausführung derAnwendungsfunktion auch im Kontext möglicher Fehlerzu gewährleisten. - Er ist daher solche Aufgabenpraktisch ungeeignet.

p Deshalb Entwicklung von RPC-Erweiterungen, um RPCsu.a. auch in einem transaktionsorientierten Kontextsinnvoll einsetzen zu können (⇒transactional RPCs).

p Von einem Transactional RPC spricht man, wenn

m zwischen Client und Server eine (transaktions-)gesicherte Übergabe erfolgt,

m die Prozedur in Transaktionslogik („Alles-oder-Nichts-Prinzip“) implementiert wird,

m die Freigabe aller Änderungen einem gemeinsamenCommit-Protokoll unterliegt.

p Oftmals werden diese erweiterten RPCs daher inVerbindung mit TP-Monitoren (siehe Abschnitt 12.4.7)realisiert bzw. angeboten.

p Die meisten RPC-Systeme fallen in die At-most-once-Fehlerklasse, weil sie einen guten Kompromiß zwischenNützlichkeit und Implementierungsaufwand darstellt. 5

5 Eine ausführlichere Behandlung und ein Vergleich von RPC-Systemen findet sichin Schill, A.: Remote Procedure Call: Fortgeschrittene Konzepte und Systeme - einÜberblick. Informatik-Spektrum, Band 15, Teil 1: Grundlagen, Heft 2, April 1992, S.79-87, Teil 2: Erweiterte RPC-Ansätze, Heft 3, Juni 1992, S. 145-155


12.4.2 Systemeinbettung: Prozesse undThreads

p Problemstellung:Eine bestimmte Anwendung soll von mehrerenBenutzern (auf einem Applikationsserver) gleichzeitiggenutzt werden können.

p Alternativen

m jede Anwendungsinstanz als eigener Prozeß miteigenem geladenen Programmcode

⇒ komplett getrennte Adreßräume

m dto., aber mehrfache Verwendung desselbenProgrammcodes 6

⇒ Shared Segments

⇒ Voraussetzung: Code reentrant übersetzt

m Ausführung der Anwendungsinstanz als Threads

⇒ eigener Programmzähler

⇒ evlt. auch lokale Variablen möglich

⇒ ansonsten gemeinsamer Adreßraum

6 Macht UNIX automatisch bei mehrfachem Laden eines Programms. In einigenälteren Betriebssystemen muß man diese Shared Segments explizit anlegen undverwalten.


p Beispiel 12-2: Prozeßerzeugung und -überlagerung in UNIX

main(){

int pid;switch( pid = fork() )

{case -1 : printf("fork failed\n");

exit(1);case 0 : printf("child: process id = %d\n", getpid() );7

execl("/bin/ls", "ls", "-la", (char*)0); /* Überlagerung*/

printf("exec failed\n");exit(1)

default : printf("parent: process id of child = %d\n", pid)exit(0);

}}

Anmerkungen:

case = -1 fängt den Fall ab, daß fork fehlschlägt und als Returncode -1zurückliefert.

case = 0 trifft im Erfolgsfall auf den Kindprozeß zu. In diesem Fall führtder Kindprozeß jedoch nicht den Code des Vaterprozesses aus,sondern überlagert diesen (natürlich nur in seinem eigenenAdreßraum) durch ein anderes Programm, das er mittels execl(...)einlagert und zur Ausführung bringt. – In unserem Beispiellagern wir das ls-Kommando von Unix ein und bringen es zurAusführung.

default (also case > 0 ) trifft im Erfolgsfall auf den Vaterprozeß zu. Inunserem Beispiel wird lediglich die Prozeßnummer des Kind-prozesses ausgegeben. In der Regel wird hier natürlich dereigentliche Programmcode des Vaterprogramms folgen.

7 mit getpid() kann ein Prozeß seine eigene Prozeßnummer erfragen.


12.4.3 Kommunikationsdienste

p Zu unterscheiden

m Kommunikation zwischen Prozessen auf demselbenRechner

⇒ Interprozeßkommunikation

⇒ pipes, named pipes (wie Dateizugriff)

⇒ Message send/receive

m Kommunikation zwischen Prozessen auf verschiedenenRechnern

⇒ Sockets

p Sockets

m logische "Steckdosen" zur Herstellung bidirektionalerKommunikationsverbindungen

m bestehen (aus Benutzersicht) aus drei Teilen:

n Socket-Kopf (socket layer)

n Protokollteil (protocol layer)

n Gerätetreiber (device layer)


result = socket( pf, type, protocol ) mit

pf = Protokoll-Familiez. B. TCP/IP (Internet), dann pf = PF_INET

Appletalk, dann pf = PF_APPLETALK,Unix-intern, dann pf = PF_UNIX

type = Art (Typ) der Kommunikationz. B. SOCK_STREAM, SOCK_DGRAM,

SOCK_RAW

protocol = (ggf.) genauere Spezifikation des gewählten Protokolltyps

result = Deskriptor

Abb. 12-10: Erzeugung eines Socket

Client-Prozeß Server-Prozeß

Socket-Kopf

Protokollteil

TCP

IP

Gerätetreiber

Rechnernetz

Socket-Kopf

Protokollteil

TCP

IP

GerätetreiberEthernet-treiber

Ethernet-treiber

Abb. 12-11: Socket-Modell


p Je nach Protokoll und Gebrauch verschiedeneKommunikationsmodelle möglich

m Stream-Verbindung

n Stellt eine virtuelle, gesicherte, verbindungsorientierteKommunikation zur Verfügung.

n Analog zum Telefonieren wird (virtuell) eine „feste“Kommunikationsverbindung zwischen zwei Prozessenaufgebaut, also eine Art von „virtueller Leitung“geschaltet.

n Nachdem die Verbindung hergestellt ist, können mittelssend- und recv-Anweisungen Nachrichten versandt bzw.empfangen werden

m Datagram-Verbindung

n Eine Nachricht an einen oder mehrere Adressatengeschickt.

n Der Empfang ist jedoch nicht gesichert und dieReihenfolge der Nachrichten ist nicht garantiert.

n Bei diesem Verbindungstyp können Nachrichten mitsendto versandt und mittels recvfrom empfangen werden


p Prinzipieller Ablauf bei Stream-Verbindung

1. Server-Socket erzeugen:sock = socket(PF_INET, SOCK_STREAM, 0)

2. Socket mit Port verbinden:serv_addr.sin_addr = < leer >;serv_addr.sin_port = server_port;serv_addr.sin_family = PF_INET;serv_addr.sin_addr.s_addr =

htonl(INADDR_ANY);bind(sock, &serv_addr, len_serv_addr);

3. Festlegen max. Anzahl von Verbindungen(= Länge der Warteschlange):listen(sock, MAX_CONNECTION);

4. Übergang in Wartezustand:new_sock =

accept(sock, &clnt_addr, len_clnt_addr);

5. Client-Socket erzeugen:sock = socket(PF_INET, SOCK_STREAM, 0);

6. (Virtuelle) Verbindung zum Server aufbauen:serv_addr.sin_addr = server_host_addr;serv_addr.sin_port = server_port;serv_addr.sin_family = PF_INET;connect(sock, &serv_addr, len_serv_addr);

7. Datenaustausch (voll duplex):send(sock, clnt_data1, len_data1, 0);

len = recv(new_sock, clnt_data1, BUFSIZE);send(new_sock, serv_data1, len_serv_data1, 0);

len = recv(sock, serv_data1, BUFSIZE);

.

.

.

8. Verbindung abbauen:close(sock);

close(new_sock);

Server Client


Erläuterungen:

Zu 2: Der Server initialisiert den Socket-Descriptor mit einer leerenHost-Adresse und stellt den „Eingangsfilter“ aufINADDR_ANY. Das heißt er ist bereit, von allen ClientsNachrichten zu empfangen. Außerdem spezifiziert er die"Steckdosen-Nummer" (Port) seines Sockets. Mittels derPorts lassen sich die verschiedenen Server eines Rechnersunterscheiden. Die Adresse eines Servers setzt sich also ausder Host-Adresse des Rechners, auf dem er läuft, unddessen „Steckdosen-Nummer“ zusammen.

Zu 4: Der Aufruf new_sock = accept(sock, clnt_addr, len_clnt_addr)versetzt den Server in einen Wartezustand. Er wartet nun aufClients, welche die in clnt_addr spezifizierten Anforderungen(Protokoll-Familie, Adresse) erfüllen.

Zu 6: Der Client spezifiziert genau den Server (Netzadresse) +Server-Port, mit dem kommuniziert werden soll.8 Connectstellt die Verbindung zum Server her, falls möglich bzw.zulässig. (Der Server verbleibt hierdurch immer noch imWartezustand.)

Zu 7: Der Server wird durch den Eingang der Nachricht"aufgeweckt" und erhält die Nachricht am Socket new_sock.Der Socket-Deskriptor von new_sock wurde mit denAbsender-Adreßdaten des Clients initialisiert. Damit ist die"Leitung" nun "geschaltet". Die weitere Kommunikationzwischen diesem Client und diesem Server wird nun übernew_sock abgewickelt. Der "alte" Socket sock kann damitzum Aufbau weiterer (paralleler) Verbindungenwiederverwendet werden.

8 Die genaue Host-Adresse des Servers erhält man in der Regel durch eine entspre-chende Bibliotheksfunktion, wie z. B. gethostbyname().


p Prinzipieller Ablauf bei Datagram-Verbindung

1. Server-Socket erzeugen:sock = socket(PF_INET, SOCK_DGRAM, 0)

2. Socket mit Port verbinden:serv_addr.sin_addr = < leer >;serv_addr.sin_port = server_port;serv_addr.sin_family = PF_INET;serv_addr.sin_addr.s_addr =

htonl(INADDR_ANY);bind(sock, &serv_addr, len_serv_addr);

3. Client-Socket erzeugen:sock = socket(PF_INET, SOCK_DGRAM, 0);

4. Daten senden (mit Empfängerangabe):serv_addr.sin_addr = server_host_addr;serv_addr.sin_port = server_port;serv_addr.sin_family = PF_INET;sendto(sock, clnt_data1, len_clnt_data1, NO_FLAGS,

&serv_addr, len_serv_addr);

len = recvfrom(sock, clnt_data1, BUFSIZE,NO_FLAGS, &clnt_addr,len_clnt_addr);

sendto( sock, serv_data1, len_serv_data1,NO_FLAGS, &clnt_addr,len_clnt_addr);

len = recvfrom( sock, serv_data1, BUFSIZE, NO_FLAGS,&serv_addr, len_serv_addr);

.

.

.

5. Socket freigeben:close(sock);

close(sock);

Client Server


12.4.4 Autorisierung, Authentifizierung undgeschützte Übertragung

p Probleme:

m lokal: siehe Zugriff auf Dateien/Datenbanken(siehe z.B. Vorlesung "Datenbanksysteme")

m ungeschützte Übertragung von Paßwörtern

m ungeschützte Übertragung (sensibler) Antwortdaten

p Lästig und deshalb potentielle Schwachstelle

m erforderliche Mehrfachanmeldungen bei denKomponentensystemen

m Versuchung groß,

n Anmeldung im Programm "hart zu verdrahten"

n Anmeldedaten zentral zu hinterlegen (⇒ Schutz?)

p Sichere Lösung nicht ganz trivial

m nichts für "Bastler"

m ggf. geeignete "Middleware" (z. B. DCE) einsetzen 9

9 siehe hierzu z.B. P. Dadam: Verteilte Datenbanken und Client/Server-Systeme ...bzw. für eine ausführlichere Darstellung A. Schill: DCE - Das OSF DistributedComputing Environment, Einführung und Grundlagen, Springer-Verlag, 1993


12.4.5 Common Object Request Broker(CORBA)

Object Request Broker

Application Objects Common Facilities

Object Services

Abb. 12-12: OMG Object Management Architecture (OMA)

p Application Objects

m Ziel der OMA: Unterstützung von interoperablen,portablen und wiederverwendbaren Anwendungen.

m Die restlichen Komponenten dienen dazu, dieses Ziel zuerreichen.

p Object Request Broker (ORB)

m Der ORB ist die Kernkomponente von OMA.

m Er vermittelt zwischen den verteilten Objekten und sorgtdafür, daß die Methodenaufrufe zum passenden Zielobjektgeleitet werden, daß dieses aktiviert wird (falls erforderlich)und daß die Ergebnisse zum Aufrufer gelangen.

m Architektur und Funktion des ORB sind in der CORBAfestgelegt.


p Object Services

m Die Objektdienste unterstützen die Abwicklung der Inter-aktionen auf den verteilten Objekten.

m Zu diesen Diensten gehören Basisfunktionen wie Sicherheit,Ereignisbehandlung, persistente Speicherung, ...

m Ziel der OMG: Auszuarbeitung entsprechenderSpezifikationen für diese Objektdienste.

p Common Facilities

m Sammlung von Objekten, die von vielen Anwendungenbenötigt werden, wie z. B. Objekte (und damitverbundene Methoden) zum Drucken oder für dieBehandlung von Fehlern.

p Die Common Object Request Broker Architecture(CORBA) konkretisiert Aufbau, Funktionalität undSchnittstellen eines ORBs.

ObjektadapterORB-Schnittstelle

Aufrufer

ORB-Kern

Server-Objekt

StatischeIDL

StubsDynamischeSchnittstelle

IDLSkeleton

Schnittstellenverzeichnis(interface repository)

Implementierungsverzeichnis(implementation repository)

Abb. 12-13: OMG CORBA


p Der ORB bietet zwei Arten von Schnittstellen für denC/S-Operationsaufruf an: 10

m Statische Schnittstelle:

n Wie beim RPC (siehe Abschnitt 12.4.1) wird vor derAusführung des Client-Programms ein Client-Stub ausder Schnittstellenbeschreibung erzeugt und statisch zumClient-Programm gebunden.

m Dynamische Schnittstelle:

n Erlaubt das dynamische Absetzen von Aufrufen.

n Der Client erzeugt zur Laufzeit einen Auftrag für einegegebene Serverschnittstelle und übergibt den Auftragan den ORB.

n Der Client spezifiziert das referenzierte Objekt, welcheOperation (Methode) aufgerufen werden soll und dieaktuellen Aufrufparameter.

n Die dynamische Schnittstelle ist in der OMG-CORBA-Spezifikation verbindlich festgelegt.

p Für das aufgerufene Objekt ist nicht erkennbar, überwelche der beiden Aufrufschnittstellen ein Dienstangefordert wurde.

p Ein Aufruf gelangt über den Objektadapter (objectadapter) und das IDL-Skeleton (ist vergleichbar mitdem Server-Stub beim RPC) zum Server-Objekt.

10 Für weiterführende Details siehe z. B. R. M. Soley, W. Kent: The OMG ObjectModel, in W. Kim (ed.) Modern Database Systems: The Object Model,Interoperability, and Beyond. ACM Press / Addison-Wesley, 1995, pp. 18-41


p Beim Aufruf einer Operation/Methode ist für den Clientnicht sichtbar,

m ob das Objekt lokal vorhanden ist oder auf einemanderen Rechner liegt

m auf welcher Hardware und in welcher Programmier-sprache ein Objekt implementiert ist

m ob das aufgerufene Objekt bereits aktiv ist oder erst vomSekundärspeicher eingelagert werden muß.

Jedenfalls ist dies das Ziel, das mit der ORB bzw.CORBA verfolgt wird.

p Objektadapter

m Bereitstellung allgemeiner Dienste wie Starten einesinaktiven Server-Objektes, Unterstützung bei derAuthentifizierung.

m Je nach Anwendungsklasse kann es verschiedeneObjektadapter mit unterschiedlicher Funktionalitätgeben.

p Implementation Repository

m Soll die Implementierung von (Server-) Objektenunterstützen.

m Bereitstellung von Beschreibungsdaten über das Objekt,wie etwa Ressourcenbedarf bei der Ausführung oderHardwarevoraussetzungen.


p Interface Repository

m Enthält IDL-Beschreibungen und Informationen zuServer-Schnittstellen.

m Es unterstützt zur Laufzeit das Hinzufügen, Suchen undAuffinden von Schnittstellen sowie die Typüberwachungder Parameter bei dynamischen Methodenaufrufen.

p Abschließende Bemerkungen

m Spezifikationen der OMG bezüglich ORB und CORBAbeziehen sich vor allem auf die Beschreibung/Festlegung der Komponenten, deren Funktionalität undZusammenwirken sowie ggf. deren Schnittstellen. DieImplementierung selbst ist Sache der einzelnenHersteller.

m ORB/CORBA ist vom Ansatz her eine mächtigeEntwicklungsumgebung für objektorientierte – auchverteilte objektorientierte – Anwendungen, die Anwen-dungsentwickler in C/S-Umgebungen dieImplementierung von systemnahen Diensten abnimmtoder zumindest vereinfacht. Insbesondere wird sie ineinem hohen Maße eine transparente Verteilung derObjekte/Dienste ermöglichen.

m Die Güte der zugrundeliegenden ORB/CORBA-Implementierung, insbesondere die Vorkehrungen füreventuell auftretende Fehlerfälle, wird deshalb vonHersteller zu Hersteller verschieden sein; auch die Inter-operabilität zwischen verschiedenen ORB/CORBA-Implementierungen wird nicht immer als gegebenvorausgesetzt werden können.

m Deshalb: Angebotene Lösungen genau prüfen!


12.4.6 Remote Database Access (RDA) 11

p Bereitstellung von Diensten für den Zugriff auf entfernte"fremde" (relationale) Datenbanken

p Im Unterschied zu "Database Gateways" Fernzugriff fürAnwendungsprogramm explizit sichtbar

p Konkurrenz verschiedener "Industriestandards" (ODBCvon Microsoft, DRDA von IBM, ...)

p Seit 1992 ISO-Standard; zwei Teile:

m Generischen RDA (IS 9579-1)

Beschreibt die Funktionen zum Initialisieren, Öffnen,zum Anstoßen der Ausführung, zum Commit usw., dieunabhängig vom Typ des eingesetzten DBMS gelten.

m Spezifischen RDA (IS 9579-2)

Beschreibt, welche SQL-Syntax unterstützt wird. Hierverweist man im Prinzip einfach auf den jeweiligen SQL-Standard. – Für andere DBMS-Typen müßten hier dannjeweils eigene „spezifische RDA“-Standards definiertwerden.

p Standard beschreibt nur Funktionalitäten

p Festlegung konkreter Schnittstellen durch u.a. SQLAccess Group (⇒ DB Call Level Interface)

11 Für eine ausführliche Behandlung siehe W. Lamersdorf: Datenbanken in verteiltenSystemen - Konzepte, Lösungen, Standards. Vieweg-Verlag, 1994


...

...

"Generischer RDA"

R-Open

R-BeginTransaction

R-Execute

R-Status

R-Commit

R-Terminate

R-Initialize

SELECT ... , FETCH ...

INSERT ... , UPDATE ... , DELETE ...

...

"Spezifischer RDA"

Abb. 12-14: Generischer und spezifischer RDA nach ISO


INACTIVE

ACTIVERDA Transaction

Not Open

RDA TransactionOpen

RDA TransactionTerminating

R-Terminate

R-Execute

R-Execute

R-BeginTransaction

R-Commit Cnf

R-Commit Req

R-Initialize

Abb. 12-15: Zustandsübergangsdiagramm für denRDA-Client (Single-Server-Fall, vereinfacht)


12.4.7 TP-Monitore

p Ursprünglich (70er Jahre + ff.): Systemnahe SW zurRealisierung großer Online-Informationssysteme

Merkmale dieser IS-Anwendungen:

m viele Benutzer/Endgeräte

m benutzen dassselbe Anwendungsprogramm

p Damals:

m Anzahl möglicher paralleler Tasks stark eingeschränkt

m auch Hauptspeicher war knappe Ressource

m manche Anwendungen nicht reentrant

p Lösung (damals):

m TP-Monitor-SW übernahm Prozeß- und Ressourcen-verwaltung

m "Sharing" von nicht-reentrant Anwendungen

m Realisierung "virtueller" Terminals

m ...

p Heute:

m Immer noch populär bei Realisierung großerInformationssysteme (manchmal weiter über 10.000Benutzer/Endgeräte)

m Zunehmender Einsatz für verteilte Anwendungen(⇒ u.a. two-phase commit)


p Einige bekannte TP-Monitore

m CICS (IBM) (mit Unix-Variante: CICS/6000)

m UTM (Siemens) (mit Unix-Variante: OpenUTM)

m ...

... und aus dem Unix-Umfeld:

m Encina

m Tuxedo

m ....

p Heute oftmals eher eine Art von "Werkzeugkasten"

m reliable queues

m transactional RPC

m ...

als ein geschlossenes Produkt

p Seit 1992 ISO-Standard für verteilte Transaktions-verarbeitung (distributed transaction processing (TP))

p Wie üblich, im Standard nur Beschreibung derDienstelemente und deren Funktionalität:


m Hauptgruppen von Dienstelementen (Auszug):

n Dialogverwaltung : zum Auf- und Abbau von TP-Dialogen

n Recovery : zur Fehlerbehandlung, Dialog- und Transaktions-Recovery

n Commitment : zur koordinierten Freigabe oder zum Zurücksetzen von Änderungen

TP-Commit : Beenden eines Transaktions- baumes

TP-Done : Freigabe lokaler Daten

TP-Commit-Complete : erfolgreiches Ende der Transaktion

TP-Rollback : Transaktion zurücksetzen

TP-Rollback-Complete : erfolgreiches Ende eines Rollback

TP-Prepare : „Prepare to Commit“- Aufforderung

TP-Ready : „Ready to Commit“-Antwort

...

n TP-Data : „Platzhalter“ innerhalb von TP, u. a. zur Übertragung von RDA-Aufrufen


TP Service Provider

(TPSP)

TP Service Provider

(TPSP)

TP Service Provider

(TPSP)

TP ServiceUser Invocation

(TPSUI)

Anwendung

DBMS1 DBMS2 DBMS3

2. TP-Prepare 2. TP-Prepare

3. TP-Ready 3. TP-Ready

4. TP-Done

2. TP-Prepare

3. TP-Ready

4. TP-Done

4. TP-Done 2. TP-Prepare

3. TP-Ready

4. TP-Done 2. TP-Prepare

3. TP-Ready

4. TP-Done

5. TP-Commit-Complete

1. TP-Commit

Abb. 12-16: Ablauf eines verteilten Commit bei TP nach ISO


p X/Open Distributed Transaction Processing

m X/Open ⇒ Industriekonsortium

m Festlegung konkreter Call-Schnittstellen

m Zur koordinierende Ressourcen im Prinzip nicht aufDBMS beschränkt

ResourceManager(RM)

DB-Server

TransactionManager(TM)

Print-Server

TX Schnittstelle(für TA-Steuerung)

RM API(z.B. SQL)

Anwendungsprogramm

XA-Schnittstelle(Steuerung RM-übergreifender TAs)

Abb. 12-17: X/Open Distributed Transaction Processing


12.5 Technisch/wissenschaftliche Anwendungen

p Häufig: Bearbeitung großer, komplex strukturierteDatenobjekte

p "Entfernte" Bearbeitung dem auf Server in der Regelnicht möglich

p Übertragung des Datenobjektes auf den Client⇒ check-out

p Evtl. sogar "kooperative" Objektbearbeitung auf derClient-Seite in Zukunft denkbar

p Rückübertragung des geänderten Objektes (als Ganzesoder nur die Änderungen12) nach Beendigung⇒ check-in

12 K. Küspert, P. Dadam, J. Günauer, : Cooperative Object Buffer Management inthe Advanced Information Management Prototype. Proc. Int'l Conf. On Very LargeDatabases (VLDB '87), Brighton, England, Sept. 1987, pp. 483-492


Server-DBClient

SELECT ...

FROM ...

WHERE ...

Check-out

3

4

ObjectBuffer

2

ObjectBuffer

1

Änderungen

Anwendungen

Check-in

5

Client

ObjectBuffer

Server-DB

ObjectBuffer 6

Anwendungen

Abb. 12-18: Check-out/Check-in


p Normales Transaktionskonzept (mit normalen Sperren)nicht ausreichend

⇒ lange Transaktionen

⇒ Langzeitsperren (nicht flüchtig)

⇒ andere Konfliktbehandlung

R W LR LW C

R + - + + -

W - - - - -

LR + - + - -

LW + - - - -

C - - - - -

Legende: R = Read Lock, W = Write Lock, LR = Long Read Lock, LW = Long Write Lock, C = Check-in Lock

Abb. 12-19: Verträglichkeitsmatrix


12.6 Typische Fallstricke / Fehler beiClient/Server-Implementierungen

p Ortsabhängigkeit von Anwendungsprogrammen

m Grund: kein verteiltes DBMS eingesetzt

m Aufteilung der Daten auf verschiedene Server imAnwendungsprogramm sichtbar

m spätere Änderung schwierig

p globale Blockierungszustände / Verklemmungen

m nicht alle Fehlerfälle berücksichtigt

m an globale Verklemmungen nicht gedacht,keine Erkennungs-/Auflösungsstrategie implementiert

p Synchronisation konkurrierender Zugriffe

m kritische Operationen werden aus Performanzgründen(oder Unwissenheit) nicht unter Two-Phase-Commitausgeführt (⇒ Konsistenzprobleme)

m globale Sperren implementiert, aber Verfahren nicht"wasserdicht"

m an Wiederanlaufproblematik nicht gedacht

p Fehlerbehandlung (vergessen oder selbst Fehlerquelle)


p Verwaltung repliziert gespeicherter Daten

m infolge naiver Implementierung u.U. geringeSystemverfügbarkeit

m ... oder potentielle Konsistenzprobleme (insbesonderebei Wiederanlauf nach Fehlern)

p Programmpflege (Versions- und Update-Problematik)

m Nur Erstinstallation bedacht, nicht Releasewechsel

m dadurch (Client-)Programme oft auf unterschiedlichemStand

m Falls Programm nicht selbst auf wechselseitigeVerträglichkeit prüfen, kann Chaos drohen

p ....

p Insgesamt:

Gefahr der Unterschätzung der (potentiellen)Komplexität des Gesamtvorhabens


12.7 Ergänzende Literatur

p P. Dadam: Verteilte Datenbanken und Client/Server-Systeme.Springer-Verlag, 1996

p K. Geihs: Client/Server-Systeme: Grundlage und Architekturen.Thomson's Aktuelle Tutorien Nr. 6, Thomson Publishing, 1995

p W. Lamersdorf: Datenbanken in verteilten Systemen: Konzepte,Lösungen, Standards. Vieweg-Verlag, 1994

p A. Karer, B. Müller: Client/Server-Technologie in derUnternehmenspraxis. Springer-Verlag, 1994

p J. Gray, A. Reuter: Transaction Processing: Concepts andTechniques. Morgan-Kaufmann Publishers, 1993

p J.J. Le Bert: CICS Made Easy. McGraw-Hill Book Comp., 1986

p Th. Kregeloh, St. Schönleber: CICS leicht und schnell gelernt. RudolfMüller online DV-Praxis (Verlagsges. Rudolf Müller GmbH, Köln),1991

p R. Koch (Hrsg. P. Jilek): BS 2000/OSD Technische BeschreibungTransaktionssystem. Publicis MCD-Verlag, 1995

p A. Schill: DCE - Das OSF Distributed Computing Environment,Einführung und Grundlagen. Springer-Verlag, 1993

p M. Wallrath: Entwicklung ingenieurwissenschaftlicherDatenbankanwendungen. FZI-Berichte Informatik, Springer-Verlag1994

12. client/server-anwendungen - informatik.uni-ulm.de · client/server-anwendungen 12-1 12....

Documents