Kapitel 12: Client/Server

12. Client/Server-Anwendungen
12.1 Allgemeines
p
"Client/Server" - ein Modewort und vielschichtiger
Begriff
p
Wird in verschiedenen Kontexten mit verschiedener
Bedeutung verwendet:
p
m
Downsizing / Rightsizing
m
Datenkapselung
m
Informationsserver / Data Warehouse
Ziel dieses Kapitels
m
Vorstellung des Client/Server-Verarbeitungsmodells
m
Vorstellung der Architekturvarianten
m
Kurze Vorstellung der Basis-Technologien für die
Implementierung
m
Aufzeigen von Fallstricken
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-1
12.2 Das Client/Server-Modell
p
Das Client/Server-Modell - C/S-Modell - ist ein
Software-Architektur-Modell
p
Zwei Komponententypen: Client und Server
p
Grundschema der Kooperation
p
m
Die Initiative zu einer Interaktion geht stets vom Klienten
(Client) aus.
m
Der Client formuliert Aufträge und schickt diese zur
Ausführung an einen Dienstanbieter (Server).
m
Für jeden Server ist festgelegt bzw. bekannt, welche
Arten von Diensten (Services) er anbietet.
Typisch für C/S-Modell:
m
Asymmetrie der Rollen bzw. Funktionen.
m
Das Modell legt die Rolle der Beteiligten (Client oder
Server) sowie die Abfolge der Interaktionsschritte fest
(siehe Abb. 12-1).
m
Ein Client kann im Laufe einer Verarbeitung auf mehrere
Server zugreifen
m
... und ein Server kann mehrere Clients bedienen
m
Ein Server kann im Rahmen einer Auftragsbearbeitung
selbst auch wieder Client sein (siehe Abb. 12-2).
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-2
Client
Server
1. Auftrag
2. Bearbeitung
3. Resultat/Antwort
Abb. 12-1: Interaktionen im Client/Server-Modell
Client
Server
Server/Client
Auftrag
Auftrag
Resultat/Antwort
Resultat/Antwort
Abb. 12-2: Verschiedene Rollen bei Auftragsausführung
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-3
12.3 Architekturaspekte
p
Viele verschiedene Realisierungsformen von C/SSystemen möglich
p
Die Unterschiede liegen hauptsächlich in der Aufteilung
der 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
Applikationsfunktion
Eigentliche anwendungsspezifische Programm- und Ablauflogik;
benutzt Präsentations- und Datenverwaltungsfunktionen (z.B.
mittels embedded SQL) zur Realisierung
m
Datenverwaltungsfunktion
Realisieren den physischen Zugriff auf die Daten mittels Dateioder DB-Schnittstelle.
PräsentationsFunktionen
ApplikationsFunktionen
DatenverwaltungsFunktionen
DB
Abb. 12-3: Komponenten einer Applikation
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-4
p
Verschiedene "Schnitte" möglich:
Client
0
Server
2
1
Präsentation
3
Applikation
4
5
Datenverwaltung
Abb. 12-4: Mögliche Funktionsverteilungen
Schnitt 0:
(= keine Zerlegung) Typische Zentralrechneranwendung: Vom Datenzugriff über Applikationslogik bis zum Bildschirmaufbau wird alles vom
Zentralsystem erledigt.
Schnitt 1:
Verteilte Präsentation. Die Präsentationsfunktion
wird hierbei in eine Server- und eine ClientKomponente aufgespalten (siehe Abs. 12.3.1).
Schnitt 2:
Entfernte Präsentation. Vom Grundgedanken her
traditionelle Terminal-Host-Konfiguration. Die Applikation steuert, im Gegensatz zur verteilten
Präsentation, den Bildschirm durch entsprechende
Kommandosequenzen unmittelbar selbst.
Ein Terminalemulationsprogramm auf einem PC,
das mit einem Hostsystem verbunden ist, wäre ein
Beispiel für eine solche C/S-Variante.
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-5
Schnitt 3:
Verteilte Applikationsfunktion. Ein Teil der
Applikation auf dem Client-, ein anderer auf dem
Serversystem ausgeführt (siehe Abs. 12.3.3).
Schnitt 4
C/S-Variante mit entferntem Datenbankzugriff
(remote database access; RDA), der über eine
semantisch hohe Schnittstelle (wie z. B. SQL)
realisiert wird (siehe Abs. 12.3.2).
Schnitt 5
C/S-Variante, bei welcher der Server auf einen
reinen Dateiserver (file server) bzw. Pageserver
reduziert wird. Die Umsetzung logische Satzadresse (z.B. über TID) in physische Adresse wird
clientseitig durchgeführt.
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-6
12.3.1 Verteilte Präsentation
p
Bekanntestes System für verteilte Präsentation
X-Windows1
p
Zwei Komponenten: X-(Display-)Server + X-Client(s)
p
Der X-Server
p
m
läuft auf dem Rechner des Benutzers und verwaltet die
Fenster seiner X-Clients.
m
bietet den X-Clients Ein- und Ausgabedienste an, mittels
derer diese die gewünschte Anwendungsfunktionalität
(bzgl. Ein-/Ausgaben) realisieren
m
stellt auf seinem Bildschirm die Fenster (X-Windows) dar
und registriert Maus- und Tastatureingaben
Die X-Clients
m
können auf demselben oder auch einem anderen
Rechner wie der X-(Display-)Server laufen
m
sind hinsichtlich der Ein-/Ausgabe ortsunabhängig.
p
Der Benutzer kann auf seinem Bildschirm mit mehreren
Anwendungen gleichzeitig arbeiten
p
und kann zwischen diesen mittels Cut & Paste
(unterstützt durch den X-Server) Daten austauschen
p
Die Programmierschnittstelle zwischen X-Server und
X-Client ⇒ X-Bibliothek
1 1984 am MIT (Massachusetts Institute for Technology) entwickelt
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-7
Datei
Bearbeiten
Zeichnen
Anordnen
Hilfe
Datei
Bearbeiten
Zeichnen
Anordnen
Hilfe
Applikation
X-Display-Server
X-Client
Rechner A
a) nichtverteilte Lösung
Applikation
X-Display-Server
Rechner A
X-Client
Rechner B
b) verteilte Lösung
Abb. 12-5: X-Windows-basierte Applikation
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-8
12.3.2 Entfernter Datenbankzugriff
p
"Schnitt 4" in Abb. 12-4
m
Die gesamte Datenverwaltungsfunktionalität wird auf
dem Serversystem bereitgestellt.
m
Die gesamte Applikationsfunktionalität liegt auf dem
Client-System.
p
Der Client bedient sich hierbei einer semantisch „hohen“
Schnittstelle, wie z. B. SQL oder eines objektorientierten
Pendants.
p
Die physischen Aspekte des Zugriffs, insbesondere der
gezielte Zugriff auf Datenbankseiten, Indexe u. ä.
bleiben hierdurch vor dem Client verborgen.
p
Im einfachsten Fall bedient sich das Clientsystem der
„normalen“ Datenbankschnittstelle des eingesetzten
DBMS, wie z. B. Embedded SQL.
p
Für die Anwendung ist es in diesem Fall völlig
transparent, ob die Datenverwaltungsfunktionalität auf
demselben Rechner oder auf einem entfernten Rechner
angeboten wird oder ob es sich um den Zugriff auf ein
verteiltes DBMS handelt.
p
Viele DBMSe bieten über diese Schnittstelle auch den
transparenten Zugriff auf Daten anderer Datenbanken
desselben 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).
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-9
12.3.3 Verteilte Applikationsfunktion
p
"Schnitt 3" in Abb. Abb. 12-4.
p
Merkmal: Ein Teil der Applikation wird auf dem Clientein 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 Lieferanten
n AnzBestGesamt = die Anzahl der aktuell noch offenen
Bestellungen bei diesem Lieferanten
n BestSummeGesamt = (ggf. restlicher) Gesamtwert dieser
Bestellungen an.
m
Relation Bestellungen
n AnzPosten = aktuelle Anzahl der (ggf. restlichen)
Bestellpositionen dieser Bestellung
n BestSumme = (ggf. restlicher) Gesamtwert dieser Positionen
(= Summe über alle BestWert-Attribute einer Bestellung).
m
Relation BestellPositionen
= die einzelnen Positionen der Bestellungen
Lieferanten
Bestellungen
LiefNr
LiefName
BestNr LiefNr
BestellPositionen
BestNr
PosNr
...
...
AnzBestGesamt
BestSummeGesamt
AnzPosten
BestSumme
...
BestWert
ArtNr
Abb. 12-6: Relationen für Bestell-Informationssystem
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-10
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 wird
gelöscht.
5. UPDATE-Zugriff auf Bestellungen: Aktualisierung von
AnzPosten und BestSumme.
6. UPDATE-Zugriff auf Lieferanten: Aktualisierung von
BestSummeGesamt.
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 in
einer 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 zu
einem Aufruf zusammengefaßt werden, damit würde sich allerdings das zu
übertragende Datenvolumen stark aufblähen und auch die Verarbeitung im
Anwendungsprogramm (Zerlegen des Join-Resultats in die Bestandteile „Lieferant“,
„Bestellung“ und „BestellPositionen“) komplizierter werden, so daß man dies in der
Regel nicht tun wird.
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-11
CREATE PROCEDURE DeleteBestPos ( LiefNr
BestNr
PosNr
BestWert
INTEGER,
INTEGER,
INTEGER,
DECIMAL(7,2))
BEGIN
/* Beginn Prozedurrumpf */
DELETE
Hostvariable
FROM BestellPositionen
WHERE BestNr = :BestNr AND PosNr = :PosNr;
ON ERROR GOTO Fehler;
UPDATE
SET
WHERE
Bestellungen
AnzPosten = AnzPosten -1,
BestSumme = BestSumme - :BestWert
BestNr = :BestNr;
ON ERROR GOTO Fehler;
UPDATE
SET
WHERE
Lieferanten
BestSummeGesamt = BestSummeGesamt - :BestWert
LiefNr = :LiefNr;
ON ERROR GOTO Fehler;
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 nicht
definiert, sondern erst für SQL-3 vorgesehen. Sie werden jedoch von einigen
relationalen DBMSen – allerdings in syntaktisch unterschiedlichen Formen – bereits
heute angeboten.
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-12
Alternative dazu: Trigger
Löschoperation (Schritt 4) noch "von Hand", restliche Updates
dann über Trigger-Prozedur.
Ablauf hier:
Schritte 1- 4 wie gehabt
Schritt 5 (faßt mittels Trigger die Schritte 5-7 zusammen)
CREATE TRIGGER AfterDeleteBestPos
AFTER DELETE ON BestellPositionen
FOR EACH ROW
DECLARE
LiefNr Integer;
BEGIN
SELECT
INTO
FROM
WHERE
LiefNr
:LiefNr
Bestellungen
BestNr = old.BestNr;
/* Deklaration Hilfsvariable
*/
/* Ermittlung LieferantenNr */
/* und Speicherung in LiefNr */
Zugriff auf alten Tupelwert
ON ERROR GOTO Ende;
UPDATE
SET
WHERE
Bestellungen
/* Aktualisierung Bestellungen */
AnzPosten = AnzPosten - 1,
BestSumme = BestSumme - old.BestWert
BestNr = old.BestNr;
ON ERROR GOTO Ende;
UPDATE
SET
WHERE
Lieferanten
/* Aktualisierung Lieferanten */
BestSummeGesamt =
BestSummeGesamt - old.BestWert
LiefNr = :LiefNr;
Ende:
END;
Abb. 12-8: Trigger
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-13
p
p
p
Probleme bei der Verwendung von Triggern
m
Erschwerte Wartung: Ggf. zwei Programm zu ändern
m
Kaskadierungseffeke (Trigger aktiviert Trigger ...)
m
Aktivierungsreihenfolge manchmal schwer
durchschaubar (bei Systemen, die mehrfache Trigger
eines Typs (ON UPDATE, ON DELETE, ...) je Tabelle
zulassen)
m
Fehlerpotential bei Systemen, die nur einen Trigger
eines Typs je Tabelle zulassen
⇒ Fallunterscheidung innerhalb des Triggers
⇒ "WHEN-Bedingung" wird immer unspezifischer
Zusammenfassung
m
Stored Procedures / Trigger die "Datenbank-Lösung" für
verteilte Applikationsfunktion
m
kann helfen - wo geeignet -, die Performanz signifikant
zu verbessern
Wegen der Wartungsproblematik
m
Stored Procedures und Trigger mit Augenmaß
einsetzen!
m
Wartung mit bedenken
m
Verlust an Portabilitiät bedenken
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-14
12.4 Basistechnologien
p
Im folgenden exemplarische und skizzenhafte
Behandlung einiger Basistechnologien, die bei der
Realsierung eines C/S-Systems oftmals direkt oder
indirekt zum Einsatz kommen.
12.4.1 Remote Procedure Call (RPC)
p
p
Bekannteste Vertreter:
m
Sun-RPC
m
DCE-RPC (der OSF 4)
Zwei Teile:
m
Client-Stub
⇒ "entfernter" Prozeduraufruf auf dem Client
m
Server-Stub
⇒ "echter" Prozeduraufruf auf dem Server
p
Beschreibung der Schnittstellen mittels spezieller
Interface Description Language (IDL), die jeweils an
die Syntax der verwendeten Programmiersprache
angelehnt ist.
p
IDL-Compiler erzeugt daraus dann den "echten" AufrufCode
4 Open Software Foundation
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-15
Server
Client
Anwendungsprogramm
Client-Stub
Prozeduraufruf
Verpacken
Aufrufparameter
KommunikationsKomponente
Übertragung
Aufruf
KommunikationsKomponente
Server-Stub
ServerProgramm
Empfang
Aufruf
Auspacken
Aufrufparameter
ProzedurAufruf
Warten
Rückgabe
Ergebnis
Auspacken
Ergebnis
Empfang
Ergebnis
Abarbeitung
Übertragung
Ergebnis
Verpacken
Ergebnis
Ergebnisrückgabe
Abb. 12-9: Ablauf eines RPC
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-16
p
p
Potentielle Probleme:
m
fehlender Time-out-Mechanismus
m
falls nicht vorhanden, komplexe Eigen-Implementierung
(⇒ paralleler Thread)
m
dadurch erhöhtes Blockierungs- bzw. Fehlerrisiko
RPC-Ausführungssemantiken
m
"kann sein" (may-be)-Semantik: Ausführung ohne
Garantie über die Häufigkeit der Prozedurausführungen
in Fehlerfällen
m
"höchstens einmal" (at most once)-Semantik: maximal
einmalige Ausführung der Prozedur auf Serverseite,
ggf. mehrfach auf Serverseite eintreffende Aufrufaufforderungen werden ignoriert,
m
"mindestens einmal" (at least once)-Semantik: die
Prozedur wird mindestens einmal auf dem Server
ausgeführt (evtl. auch mehrfach),
m
"genau einmal" (exactly once)-Semantik: die Prozedur
wird genau einmal ausgeführt.
Anmerkung:
Diese Ausführungssemantiken werden vor allem dann
wichtig, wenn es mehrere Server im Netz geben kann, die
einen bestimmten Dienst erbringen können.
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-17
p
Für transaktionsorientiertes Arbeiten verlangt der
einfache RPC dem Anwendungsentwickler einen
erheblichen Entwurfs- und Implementierungsaufwand
ab, um die sichere bzw. atomare Ausführung der
Anwendungsfunktion auch im Kontext möglicher Fehler
zu gewährleisten. - Er ist daher solche Aufgaben
praktisch ungeeignet.
p
Deshalb Entwicklung von RPC-Erweiterungen, um RPCs
u.a. auch in einem transaktionsorientierten Kontext
sinnvoll 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-NichtsPrinzip“) implementiert wird,
m
die Freigabe aller Änderungen einem gemeinsamen
Commit-Protokoll unterliegt.
p
Oftmals werden diese erweiterten RPCs daher in
Verbindung mit TP-Monitoren (siehe Abschnitt 12.4.7)
realisiert bzw. angeboten.
p
Die meisten RPC-Systeme fallen in die At-most-onceFehlerklasse, weil sie einen guten Kompromiß zwischen
Nützlichkeit und Implementierungsaufwand darstellt. 5
5 Eine ausführlichere Behandlung und ein Vergleich von RPC-Systemen findet sich
in 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
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-18
12.4.2 Systemeinbettung: Prozesse und
Threads
p
Problemstellung:
Eine bestimmte Anwendung soll von mehreren
Benutzern (auf einem Applikationsserver) gleichzeitig
genutzt werden können.
p
Alternativen
m
jede Anwendungsinstanz als eigener Prozeß mit
eigenem geladenen Programmcode
⇒ komplett getrennte Adreßräume
m
dto., aber mehrfache Verwendung desselben
Programmcodes 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 und
verwalten.
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-19
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 -1
zurückliefert.
case = 0 trifft im Erfolgsfall auf den Kindprozeß zu. In diesem Fall führt
der Kindprozeß jedoch nicht den Code des Vaterprozesses aus,
sondern überlagert diesen (natürlich nur in seinem eigenen
Adreßraum) durch ein anderes Programm, das er mittels execl(...)
einlagert und zur Ausführung bringt. – In unserem Beispiel
lagern wir das ls-Kommando von Unix ein und bringen es zur
Ausführung.
default
(also case > 0 ) trifft im Erfolgsfall auf den Vaterprozeß zu. In
unserem Beispiel wird lediglich die Prozeßnummer des Kindprozesses ausgegeben. In der Regel wird hier natürlich der
eigentliche Programmcode des Vaterprogramms folgen.
7 mit getpid() kann ein Prozeß seine eigene Prozeßnummer erfragen.
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-20
12.4.3 Kommunikationsdienste
p
Zu unterscheiden
m
Kommunikation zwischen Prozessen auf demselben
Rechner
⇒ Interprozeßkommunikation
⇒ pipes, named pipes (wie Dateizugriff)
⇒ Message send/receive
m
Kommunikation zwischen Prozessen auf verschiedenen
Rechnern
⇒ Sockets
p
Sockets
m
logische "Steckdosen" zur Herstellung bidirektionaler
Kommunikationsverbindungen
m
bestehen (aus Benutzersicht) aus drei Teilen:
n
Socket-Kopf (socket layer)
n
Protokollteil (protocol layer)
n
Gerätetreiber (device layer)
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-21
result = socket( pf, type, protocol ) mit
pf
= Protokoll-Familie
z. B. TCP/IP (Internet), dann pf = PF_INET
Appletalk, dann pf = PF_APPLETALK,
Unix-intern, dann pf = PF_UNIX
type
= Art (Typ) der Kommunikation
z. 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
Socket-Kopf
TCP
TCP
Protokollteil
Protokollteil
IP
Gerätetreiber
IP
Ethernettreiber
Ethernettreiber
Gerätetreiber
Rechnernetz
Abb. 12-11: Socket-Modell
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-22
p
Je nach Protokoll und Gebrauch verschiedene
Kommunikationsmodelle möglich
m
m
Stream-Verbindung
n
Stellt eine virtuelle, gesicherte, verbindungsorientierte
Kommunikation zur Verfügung.
n
Analog zum Telefonieren wird (virtuell) eine „feste“
Kommunikationsverbindung zwischen zwei Prozessen
aufgebaut, also eine Art von „virtueller Leitung“
geschaltet.
n
Nachdem die Verbindung hergestellt ist, können mittels
send- und recv-Anweisungen Nachrichten versandt bzw.
empfangen werden
Datagram-Verbindung
n
Eine Nachricht an einen oder mehrere Adressaten
geschickt.
n
Der Empfang ist jedoch nicht gesichert und die
Reihenfolge der Nachrichten ist nicht garantiert.
n
Bei diesem Verbindungstyp können Nachrichten mit
sendto versandt und mittels recvfrom empfangen werden
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-23
p
Prinzipieller Ablauf bei Stream-Verbindung
Client
Server
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);
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-24
Erläuterungen:
Zu 2: Der Server initialisiert den Socket-Descriptor mit einer leeren
Host-Adresse und stellt den „Eingangsfilter“ auf
INADDR_ANY. Das heißt er ist bereit, von allen Clients
Nachrichten zu empfangen. Außerdem spezifiziert er die
"Steckdosen-Nummer" (Port) seines Sockets. Mittels der
Ports lassen sich die verschiedenen Server eines Rechners
unterscheiden. Die Adresse eines Servers setzt sich also aus
der Host-Adresse des Rechners, auf dem er läuft, und
dessen „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 auf
Clients, 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 Connect
stellt die Verbindung zum Server her, falls möglich bzw.
zulässig. (Der Server verbleibt hierdurch immer noch im
Wartezustand.)
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 den
Absender-Adreßdaten des Clients initialisiert. Damit ist die
"Leitung" nun "geschaltet". Die weitere Kommunikation
zwischen diesem Client und diesem Server wird nun über
new_sock abgewickelt. Der "alte" Socket sock kann damit
zum Aufbau weiterer (paralleler) Verbindungen
wiederverwendet werden.
8 Die genaue Host-Adresse des Servers erhält man in der Regel durch eine entsprechende Bibliotheksfunktion, wie z. B. gethostbyname().
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-25
p
Prinzipieller Ablauf bei Datagram-Verbindung
Client
Server
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);
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-26
12.4.4 Autorisierung, Authentifizierung und
geschützte Übertragung
p
p
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
Lästig und deshalb potentielle Schwachstelle
m
erforderliche Mehrfachanmeldungen bei den
Komponentensystemen
m
Versuchung groß,
n
Anmeldung im Programm "hart zu verdrahten"
n
Anmeldedaten zentral zu hinterlegen (⇒ Schutz?)
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 Distributed
Computing Environment, Einführung und Grundlagen, Springer-Verlag, 1993
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-27
12.4.5 Common Object Request Broker
(CORBA)
Common Facilities
Application Objects
Object Request Broker
Object Services
Abb. 12-12: OMG Object Management Architecture (OMA)
p
p
Application Objects
m
Ziel der OMA: Unterstützung von interoperablen,
portablen und wiederverwendbaren Anwendungen.
m
Die restlichen Komponenten dienen dazu, dieses Ziel zu
erreichen.
Object Request Broker (ORB)
m
Der ORB ist die Kernkomponente von OMA.
m
Er vermittelt zwischen den verteilten Objekten und sorgt
dafür, daß die Methodenaufrufe zum passenden Zielobjekt
geleitet werden, daß dieses aktiviert wird (falls erforderlich)
und daß die Ergebnisse zum Aufrufer gelangen.
m
Architektur und Funktion des ORB sind in der CORBA
festgelegt.
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-28
p
p
Object Services
m
Die Objektdienste unterstützen die Abwicklung der Interaktionen auf den verteilten Objekten.
m
Zu diesen Diensten gehören Basisfunktionen wie Sicherheit,
Ereignisbehandlung, persistente Speicherung, ...
m
Ziel der OMG: Auszuarbeitung entsprechender
Spezifikationen für diese Objektdienste.
Common Facilities
m
p
Sammlung von Objekten, die von vielen Anwendungen
benötigt werden, wie z. B. Objekte (und damit
verbundene Methoden) zum Drucken oder für die
Behandlung von Fehlern.
Die Common Object Request Broker Architecture
(CORBA) konkretisiert Aufbau, Funktionalität und
Schnittstellen eines ORBs.
ServerObjekt
Aufrufer
Dynamische
Schnittstelle
IDL
Skeleton
Statische
IDL
Stubs
ORB-Schnittstelle
Objektadapter
ORB-Kern
Schnittstellenverzeichnis
(interface repository)
Implementierungsverzeichnis
(implementation repository)
Abb. 12-13: OMG CORBA
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-29
p
Der ORB bietet zwei Arten von Schnittstellen für den
C/S-Operationsaufruf an: 10
m
Statische Schnittstelle:
n
m
Wie beim RPC (siehe Abschnitt 12.4.1) wird vor der
Ausführung des Client-Programms ein Client-Stub aus
der Schnittstellenbeschreibung erzeugt und statisch zum
Client-Programm gebunden.
Dynamische Schnittstelle:
n
Erlaubt das dynamische Absetzen von Aufrufen.
n
Der Client erzeugt zur Laufzeit einen Auftrag für eine
gegebene Serverschnittstelle und übergibt den Auftrag
an den ORB.
n
Der Client spezifiziert das referenzierte Objekt, welche
Operation (Methode) aufgerufen werden soll und die
aktuellen Aufrufparameter.
n
Die dynamische Schnittstelle ist in der OMG-CORBASpezifikation verbindlich festgelegt.
p
Für das aufgerufene Objekt ist nicht erkennbar, über
welche der beiden Aufrufschnittstellen ein Dienst
angefordert wurde.
p
Ein Aufruf gelangt über den Objektadapter (object
adapter) und das IDL-Skeleton (ist vergleichbar mit
dem Server-Stub beim RPC) zum Server-Objekt.
10 Für weiterführende Details siehe z. B. R. M. Soley, W. Kent: The OMG Object
Model, in W. Kim (ed.) Modern Database Systems: The Object Model,
Interoperability, and Beyond. ACM Press / Addison-Wesley, 1995, pp. 18-41
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-30
p
Beim Aufruf einer Operation/Methode ist für den Client
nicht sichtbar,
m
ob das Objekt lokal vorhanden ist oder auf einem
anderen Rechner liegt
m
auf welcher Hardware und in welcher Programmiersprache ein Objekt implementiert ist
m
ob das aufgerufene Objekt bereits aktiv ist oder erst vom
Sekundärspeicher eingelagert werden muß.
Jedenfalls ist dies das Ziel, das mit der ORB bzw.
CORBA verfolgt wird.
p
p
Objektadapter
m
Bereitstellung allgemeiner Dienste wie Starten eines
inaktiven Server-Objektes, Unterstützung bei der
Authentifizierung.
m
Je nach Anwendungsklasse kann es verschiedene
Objektadapter mit unterschiedlicher Funktionalität
geben.
Implementation Repository
m
Soll die Implementierung von (Server-) Objekten
unterstützen.
m
Bereitstellung von Beschreibungsdaten über das Objekt,
wie etwa Ressourcenbedarf bei der Ausführung oder
Hardwarevoraussetzungen.
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-31
p
p
Interface Repository
m
Enthält IDL-Beschreibungen und Informationen zu
Server-Schnittstellen.
m
Es unterstützt zur Laufzeit das Hinzufügen, Suchen und
Auffinden von Schnittstellen sowie die Typüberwachung
der Parameter bei dynamischen Methodenaufrufen.
Abschließende Bemerkungen
m
Spezifikationen der OMG bezüglich ORB und CORBA
beziehen sich vor allem auf die Beschreibung/
Festlegung der Komponenten, deren Funktionalität und
Zusammenwirken sowie ggf. deren Schnittstellen. Die
Implementierung selbst ist Sache der einzelnen
Hersteller.
m
ORB/CORBA ist vom Ansatz her eine mächtige
Entwicklungsumgebung für objektorientierte – auch
verteilte objektorientierte – Anwendungen, die Anwendungsentwickler in C/S-Umgebungen die
Implementierung von systemnahen Diensten abnimmt
oder zumindest vereinfacht. Insbesondere wird sie in
einem hohen Maße eine transparente Verteilung der
Objekte/Dienste ermöglichen.
m
Die Güte der zugrundeliegenden ORB/CORBAImplementierung, insbesondere die Vorkehrungen für
eventuell auftretende Fehlerfälle, wird deshalb von
Hersteller zu Hersteller verschieden sein; auch die Interoperabilität zwischen verschiedenen ORB/CORBAImplementierungen wird nicht immer als gegeben
vorausgesetzt werden können.
m
Deshalb: Angebotene Lösungen genau prüfen!
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-32
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ür
Anwendungsprogramm explizit sichtbar
p
Konkurrenz verschiedener "Industriestandards" (ODBC
von 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., die
unabhängig vom Typ des eingesetzten DBMS gelten.
m
Spezifischen RDA (IS 9579-2)
Beschreibt, welche SQL-Syntax unterstützt wird. Hier
verweist man im Prinzip einfach auf den jeweiligen SQLStandard. – Für andere DBMS-Typen müßten hier dann
jeweils eigene „spezifische RDA“-Standards definiert
werden.
p
Standard beschreibt nur Funktionalitäten
p
Festlegung konkreter Schnittstellen durch u.a. SQL
Access Group (⇒ DB Call Level Interface)
11 Für eine ausführliche Behandlung siehe W. Lamersdorf: Datenbanken in verteilten
Systemen - Konzepte, Lösungen, Standards. Vieweg-Verlag, 1994
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-33
R-Initialize
"Generischer RDA"
R-Open
R-BeginTransaction
R-Execute
SELECT ... , FETCH ...
"Spezifischer RDA"
INSERT ... , UPDATE ... , DELETE ...
...
R-Status
...
R-Commit
...
R-Terminate
Abb. 12-14: Generischer und spezifischer RDA nach ISO
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-34
INACTIVE
R-Initialize
R-Terminate
ACTIVE
RDA Transaction
Not Open
R-BeginTransaction
R-Execute
RDA Transaction
Open
R-Commit Req
R-Execute
RDA Transaction
Terminating
R-Commit Cnf
Abb. 12-15: Zustandsübergangsdiagramm für den
RDA-Client (Single-Server-Fall, vereinfacht)
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-35
12.4.7 TP-Monitore
p
Ursprünglich (70er Jahre + ff.): Systemnahe SW zur
Realisierung großer Online-Informationssysteme
Merkmale dieser IS-Anwendungen:
p
p
p
m
viele Benutzer/Endgeräte
m
benutzen dassselbe Anwendungsprogramm
Damals:
m
Anzahl möglicher paralleler Tasks stark eingeschränkt
m
auch Hauptspeicher war knappe Ressource
m
manche Anwendungen nicht reentrant
Lösung (damals):
m
TP-Monitor-SW übernahm Prozeß- und Ressourcenverwaltung
m
"Sharing" von nicht-reentrant Anwendungen
m
Realisierung "virtueller" Terminals
m
...
Heute:
m
Immer noch populär bei Realisierung großer
Informationssysteme (manchmal weiter über 10.000
Benutzer/Endgeräte)
m
Zunehmender Einsatz für verteilte Anwendungen
(⇒ u.a. two-phase commit)
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-36
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:
p
m
Encina
m
Tuxedo
m
....
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 Transaktionsverarbeitung (distributed transaction processing (TP))
p
Wie üblich, im Standard nur Beschreibung der
Dienstelemente und deren Funktionalität:
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-37
m
Hauptgruppen von Dienstelementen (Auszug):
n
Dialogverwaltung
: zum Auf- und Abbau von
TP-Dialogen
n
Recovery
: zur Fehlerbehandlung, Dialogund Transaktions-Recovery
n
Commitment
: zur koordinierten Freigabe
oder zum Zurücksetzen von
Änderungen
TP-Commit
: Beenden eines Transaktionsbaumes
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
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-38
Anwendung
TP Service
User Invocation
(TPSUI)
1. TP-Commit
5. TP-Commit-Complete
TP
Service Provider
(TPSP)
2. TP-Prepare
4. TP-Done
2. TP-Prepare
3. TP-Ready
4. TP-Done
TP
Service Provider
(TPSP)
2. TP-Prepare
3. TP-Ready
DBMS1
2. TP-Prepare
3. TP-Ready
4. TP-Done
4. TP-Done
3. TP-Ready
TP
Service Provider
(TPSP)
2. TP-Prepare
4. TP-Done
3. TP-Ready
DBMS2
DBMS3
Abb. 12-16: Ablauf eines verteilten Commit bei TP nach ISO
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-39
p
X/Open Distributed Transaction Processing
m
X/Open ⇒ Industriekonsortium
m
Festlegung konkreter Call-Schnittstellen
m
Zur koordinierende Ressourcen im Prinzip nicht auf
DBMS beschränkt
Anwendungsprogramm
RM API
(z.B. SQL)
TX Schnittstelle
(für TA-Steuerung)
Resource
Manager
(RM)
Transaction
Manager
(TM)
DB-Server
XA-Schnittstelle
(Steuerung RM-übergreifender TAs)
Print-Server
Abb. 12-17: X/Open Distributed Transaction Processing
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-40
12.5 Technisch/wissenschaftliche
Anwendungen
p
Häufig: Bearbeitung großer, komplex strukturierte
Datenobjekte
p
"Entfernte" Bearbeitung dem auf Server in der Regel
nicht möglich
p
Übertragung des Datenobjektes auf den Client
⇒ check-out
p
Evtl. sogar "kooperative" Objektbearbeitung auf der
Client-Seite in Zukunft denkbar
p
Rückübertragung des geänderten Objektes (als Ganzes
oder nur die Änderungen12) nach Beendigung
⇒ check-in
12 K. Küspert, P. Dadam, J. Günauer, : Cooperative Object Buffer Management in
the Advanced Information Management Prototype. Proc. Int'l Conf. On Very Large
Databases (VLDB '87), Brighton, England, Sept. 1987, pp. 483-492
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-41
1
Client
Server-DB
SELECT ...
Anwendungen
FROM ...
WHERE ...
Object
Buffer
Check-out
3
Object
Buffer
2
Änderungen
4
Server-DB
Client
Anwendungen
Object
Buffer
Check-in
5
Object
Buffer
6
Abb. 12-18: Check-out/Check-in
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-42
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
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-43
12.6 Typische Fallstricke / Fehler bei
Client/Server-Implementierungen
p
p
p
p
Ortsabhängigkeit von Anwendungsprogrammen
m
Grund: kein verteiltes DBMS eingesetzt
m
Aufteilung der Daten auf verschiedene Server im
Anwendungsprogramm sichtbar
m
spätere Änderung schwierig
globale Blockierungszustände / Verklemmungen
m
nicht alle Fehlerfälle berücksichtigt
m
an globale Verklemmungen nicht gedacht,
keine Erkennungs-/Auflösungsstrategie implementiert
Synchronisation konkurrierender Zugriffe
m
kritische Operationen werden aus Performanzgründen
(oder Unwissenheit) nicht unter Two-Phase-Commit
ausgeführt (⇒ Konsistenzprobleme)
m
globale Sperren implementiert, aber Verfahren nicht
"wasserdicht"
m
an Wiederanlaufproblematik nicht gedacht
Fehlerbehandlung (vergessen oder selbst Fehlerquelle)
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-44
p
p
Verwaltung repliziert gespeicherter Daten
m
infolge naiver Implementierung u.U. geringe
Systemverfügbarkeit
m
... oder potentielle Konsistenzprobleme (insbesondere
bei Wiederanlauf nach Fehlern)
Programmpflege (Versions- und Update-Problematik)
m
Nur Erstinstallation bedacht, nicht Releasewechsel
m
dadurch (Client-)Programme oft auf unterschiedlichem
Stand
m
Falls Programm nicht selbst auf wechselseitige
Verträglichkeit prüfen, kann Chaos drohen
p
....
p
Insgesamt:
Gefahr der Unterschätzung der (potentiellen)
Komplexität des Gesamtvorhabens
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-45
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 der
Unternehmenspraxis. Springer-Verlag, 1994
p
J. Gray, A. Reuter: Transaction Processing: Concepts and
Techniques. 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. Rudolf
Müller online DV-Praxis (Verlagsges. Rudolf Müller GmbH, Köln),
1991
p
R. Koch (Hrsg. P. Jilek): BS 2000/OSD Technische Beschreibung
Transaktionssystem. Publicis MCD-Verlag, 1995
p
A. Schill: DCE - Das OSF Distributed Computing Environment,
Einführung und Grundlagen. Springer-Verlag, 1993
p
M. Wallrath: Entwicklung ingenieurwissenschaftlicher
Datenbankanwendungen. FZI-Berichte Informatik, Springer-Verlag
1994
 P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme
12. Client/Server-Anwendungen
12-46