WS06/07Prof. Dr. Andreas Schmietendorf1 Programmierung von Client/Server- Anwendungen Grundlagen von Client/Server Systemen

WS06/07 Prof. Dr. Andreas Schmietendorf 1

Programmierung von Client/Server-Anwendungen

Grundlagen von Client/Server Systemen

http://www.fhw-berlin.de/


Grundlagen von Client/Server-Systemen

Grundlegendes zum Client-Server Prinzip

Grundlagen verteilter Systeme

Begriff der Verteilungstransparenz

Kommunikation in verteilten Systemen

Mehrschichtige C/S-Anwendungen

Transaktionssicherheit

Kriterien zur Technologieauswahl



Grundlegendes zum Client/Server-Prinzip



Client (Kunde bzw. Auftraggeber)

- Fordert von einem Server eine bestimmte Dienstleistung an

- Wartet auf eine entsprechende Antwort

Server (Diensterbringer)

- Komponente die Aufträge von Clients entgegennimmt

- Bearbeitet die Aufträge entsprechend einer def. Logik

- Sendet die Antwort an den Client zurück

Client-Server-Prinzip



Problem der Synchronisation zwischen Client & Server

Client (Programm um Serververbindungen aufzubauen)

- Übernimmt den aktiven Teil des Verbindungsaufbaus

- Bestimmt den Zeitpunkt des Verbindungsaufbaus

- Häufig Benutzerprogramme um Dienste des Servers zugänglich

zu machen (aber auch Systemprogramme)

Server (häufig auch als daemon-Prozess bezeichnet)

- Häufig als Endlosschleife implementiert

- Wartet auf eingehende Verbindungsanforderung

Client-Server-Prinzip



Nebenläufiger Server

- Erzeugt für jeden Client einen neuen Prozess

- Genutzt bei langer und unbestimmter Verarbeitungszeit

- z.B. FTP oder HTTP-Server

Iterativer Server

- Können nur eine Anfrage zur selben Zeit beantworten

- Insbesondere bei Diensten mit kurzer Verarbeitungszeit

- z.B. Time Server

Klassen von Servern I



Verbindungsorientierter Server (synchron)

- Datenaustausch läuft in 3 Phasen: Verbindungsaufbau,

Datentransfer und Verbindungsabbau

- Rückmeldung über Erfolg bzw. Mißerfolg

- Vorteil: Sicherheit der Datenübertragung

Verbindungsloser Server (asynchron)

- Versendung in sich abgeschlossener Datenpakete

- Keine Signalisierung der Empfangsbereitschaft

- Keine Empfangsbestätigung

- Vorteil: höhere Übertragungsgeschwindigkeit

Klassen von Servern II



Zustandsbehafteter Server

- Speichert Informationen über Interaktionen mit dem Client

- Vorteil: höhere erreichbare Effizienz

- z.B.: Datenbankserver

Zustandsloser Server

- Keine Speicherung von Informationen

- Vorteil: Datenübertragung ist sicherer

- z.B.: HTTP Webserver

Klassen von Servern III



Server unter WindowsXP



Grundlagen verteilter Systeme



Unternehmensarchitekturen

ERP E-Commerce

KundenDatenbank

ProduktDatenbank

Legacy Systeme

CRM

SOP Call Center



Ein verteiltes System ist eine Menge autonomer Rechner (keine

zentrale Steuerung), die gekoppelt sind, über Nachrichten

miteinander kommunizieren und damit verteilte Anwendungen

ermöglichen. Die Kommunikation sollte über offene wohl

definierte Schnittstellen erfolgen. Der Verteilungsaspekt sollte

für die Benutzer des Systems möglichst transparent sein.

Definition und Abgrenzung



Gemeinsame Nutzung von Daten

- z.B. verteiltes Dateisystem

- Fehlertoleranz durch Replikation der Daten einer Datenbank

Gemeinsame Nutzung von Funktionen

- z.B. email, Terminkalender, (Funktionsmodell)

Gemeinsame Nutzung von Rechenleistung (z.B. Grids)

Gemeinsame Nutzung von Geräten (z.B. Drucker)

Gegenstand einer Verteilung



Parallele und verteilte Aktivitäten

- Notwendigkeit der Koordination und Synchronisation

- Separierung der Verantwortlichkeiten zwischen C/S-Komponenten

Kein gemeinsamer Speicher

- Interaktion durch Nachrichtenaustausch

- Services warten passiv auf eingehende Anforderungen

Aufbau sehr großer Systeme

- Quantität erfordert neue Qualitäten

- Umgang mit veränderten Anforderungen (z.B. Anzahl der Clients)

Charakteristik verteilter Systeme I



Fehler- und Ausfallwahrscheinlichkeit

- Problem der Fehlertoleranz

- Umgang mit Ausnahmesituationen

Heterogene Hard- und Software-Komponenten

- Bedarf einer standardisierten Vernetzung

- Bedarf an Schnittstellen-Standard

Gemeinsame Nutzung von Betriebsmittels

- Daten, Funktionen, Geräte, …

- Berücksichtigung sicherheitsrelevanter Aspekte

Charakteristik verteilter Systeme II



Begriff der Verteilungstransparenz&

Vor- und Nachteile verteilter Systeme



Da die Nutzung verteilter Systeme in der Regel komplizierter ist

als die Nutzung eines einzelnen Rechners, wurden auf

unterschiedlichen Ebenen (Nutzerebene, Programmierebene,

Netzwerkebene, …) Mechanismen eingeführt, die den Aspekt der

Verteilung verbergen. Ein verteiltes System erscheint auf dieser

Grundlage wie ein zentrales System. In diesem Zusammenhang

wird auch von Verteilungstransparenz gesprochen.

Verteilungstransparenz I

Quelle: Oechsle, R.: Verteilte Systeme, in Taschenbuch der Informatik, Fachbuchverlag Leipzig



Transparency of location: The server is a process that can reside

on the same machine as the client or on a different machine

across a network. Client/server software usually masks the

location of the server from the clients by redirecting the service

calls when needed. A program can be a client, a server, or both.

Verteilungstransparenz II

Quelle: Orfali, R. et al.: The Essential Client/Server Survival Guide – Second Edition, John Wiley & Sons, New York 1996



Zugriffstransparenz - der Zugriff auf lokale und entfernte

Ressourcen erfolgt in der gleichen Art und Weise.

Ortstransparenz – der Zugriff auf Ressourcen ist ohne

Kenntnis des Orts, an dem sich diese befinden, möglich.

Namenstransparenz - konsistente Verwendung von

Namen innerhalb des gesamten verteilten Systems.

Skalierungstransparenz - einfacher Erweiterbarkeit des

Systems ohne Auswirkungen auf die Gesamtstruktur.

Arten der Verteilungstransparenz I




Replikationstransparenz – Erhöhung der Verfügbarkeit

und Fehlertoleranz durch gezielte Redundanz

Nebenläufigkeitstransparenz - Parallele Prozesse und

Benutzer arbeiten ohne gegenseitige Beeinflussung

Ausführungstransparenz - gegenüber dem Benutzer

bleibt der Ort einer Serviceausführung verborgen. Ggf.

besteht sogar die Möglichkeit einer Prozess-Migration.

Arten der Verteilungstransparenz II




Kostenreduktion

Lokale Kontrolle und Verfügbarkeit

Maßgeschneiderte Konfiguration

Leichte Erweiterbarkeit

Ausfalltoleranz

Hohe Leistung durch Parallelität

Modulare Software

Herstellerunabhängigkeit

Übereinstimmung mit organisatorischen Strukturen

Vorteile verteilter Systeme



Hoher Bedienungs- und Wartungsaufwand

Probleme der Heterogenität

Schwierigkeit korrekte verteilte Software zu erstellen

Komplexität des Kommunikationssystems

Aufwand beim Übergang vom zentralisierten zum

dezentralen System

Sicherheitsprobleme, Gesamtkosten schwer

einschätzbar (ggf. versteckte Kosten)

Nachteile verteilter Systeme






Klassifizierung von Kommunikationsverfahren: Art der Nachricht

- Übertragung der gesamten Information- Verweis auf Information bzw. Zugriffsrecht

Beteiligung des Betriebssystems- Implizite Kommunikation (Prozesse regeln selbst)- Explizite Kommunikation (unter Steuerung des BS)

Zahl der kommunizierenden Prozesse- 1 : 1 Unicast- 1 : m Broadcast

Synchronisation




Blockierende und nicht blockierende Kommunikation

Synchrone Kommunikation- Aufrufer ist blockiert bis ein Ergebnis eintrifft

- Vereinfacht das Design von Anwendungen

- Starke Kopplung zwischen Client und Server (schwierig im Netz)

- Ggf. Performanceeinbußen

Asynchrone Kommunikation- “Fire and forget”

- Kein blockieren

- Ideal in weit verteilten Systemen





Client Web-Service

request

result

Client Web-Service

request

response

doSomething

synchron asynchron



Mittel zur Interprozesskommunikation

- Gemeinsame Dateien – langsame implizite Kommunikation

- Gemeinsame Speicherbereiche (shared memory)

- Kanäle, Pipeplines (pipes, FIFO)

- Sockets (API zur direkten Nutzung des TCP/IP)

- Briefkästen (mailboxes bzw. message queues)

- Entfernte Prozedur- bzw. Methodenaufrufe




Kommunikation über Sockets (Steckdose)

- De-facto-Standard einer Programmierschnittstelle

- Nutzung von TCP/IP und UDP/IP zur Kommunikation

- Kommunikationsendpunkt innerhalb einer Anwendung

- Adressierung von IP-Adresse und Portnummer




Kommunikation via UDP (User Datagram Protocol)

- Verbindungsloses unzuverlässiges Transportprotokoll

- UDP-Client muss IP-Adresse und Portnummer des Servers

kennen auf dem der benötigte Dienst läuft

Kommunikation via TCP (Transmission Control Protocol)

- Zuverlässiges verbindungsorientiertes Protokoll

- TCP-Client muss IP-Adresse und Portnummer des Servers

kennen auf dem der benötigte Dienst läuft




Nachteile einer Socket-basierten Kommunikation

- Bei UDP muss die Unzuverlässigkeit ausgeglichen werden

- Bei TCP muß der Verbindungsauf- und Abbau explizit

ausprogrammiert werden

- Explizite Berücksichtigung der Parallelität bei der

Serverprogrammierung

- Ggf. notwendige Formatierung der übertragenen Daten

- Paradigmenbruch zur prozeduralen bzw. objektorientierten

Programmierung




Unscharfer Begriff zur Beschreibung der benötigten Software um

zwischen Client- und Server-Komponenten kommunizieren zu

können. Wird auch als „glue“, also Kleister zwischen der Client- und

Server-Implementierung bezeichnet. Bezieht sich auf die

Möglichkeiten des Serviceaufrufs (API) sowie die Übertragung der

Anforderung bzw. Antwort über das verwendete Netzwerk.

Begriff der Middleware

In Anlehnung an: Orfali, R. et al.: The Essential Client/Server Survival Guide – Second Edition, John Wiley & Sons, New York 1996



Berücksichtigte Aspekte:- Kommunikations-Stack- Verzeichnis- und Zeitdienste- Authentifizierung & Autorisierung- Verteilte Datei- und Druckservices

Beispiele:- DCE/RPC - Prozedurspezifikation- CORBA/RMI - Methodenspezifikation- MOM - Message Queue Systeme- Web Services (XML, SOAP, WSDL)

General Middleware




Berücksichtigte Aspekte:

- Bezieht sich auf einen speziellen Servicetypen

- Teilweise überlappend zu den allgemeinen Middlewareansätzen

Beispiele

- Datenbankspezifische Middleware (JDBC, ODBC, CLI, …)

- Groupware spezifische Middleware (SMTP, …)

- Transaktionsmonitore (JTS API, JTA, …)

- System Management spezifsiche Middleware (SNMP, CMIP, …)

Service-spezifsche Middleware




Mehrschichtige Client/Server-Systeme



Client – z.B. Browser-basiert

Presentation Layer

- HTML(XML)

- JSP, Servlets, Applets

Web Server (HTTP/HTTPS)

Application Logic Layer

- Servlets, Java-Klassen/Java-Beans

- Enterprise Java Beans (EJB & Ressource Adapter)

Applikation Server (RMI, JDBC, JMS, …)

Ressource Management Layer (DBMS, FS, MOM, …)

Client/Server-Systeme in mehreren Schichten (tiers) I



Monolitische Architekturen (typ. Enterprise-Systeme)

2-Tier-Architecture (Trennung von Client und Server)

- Client Arbeitsplatz mit hohen Ressourcen-Anforderungen

3-Tier (3-schichtige C/S-Architekturen)

- 1.Tier: Graphische Benutzeroberfläche (GUI)

- 2.Tier: Geschäftslogik (Service-Logik)

- 3.Tier: Datenbanken (Oracle, Informix, SQL-Server)

Multi-Tier (Mehr-Schichten-Architekturen)

Client/Server-Systeme in mehreren Schichten (tiers) II



Client/Server-Systeme in mehreren Schichten (tiers) III

Server A

Server C

Server B

DB-1

DB-2

DB-3

Client mit GUI

Client mit GUI

Client mit GUI

Zwei-Schichten-Architektur



Client/Server-Systeme in mehreren Schichten (tiers) IV

Server A

Server C

Server B

DB-1

DB-2

DB-3

Anwendungs-server

Client mit GUI

Client mit GUI

Client mit GUI

Drei-Schichten-Architektur



Client/Server-Systeme in mehreren Schichten (tiers) V

DBS

Integration-Server (Wrapper)

DBS

DB-1

DB-2

Legacy-Anwendung

Web-Server

Client mit GUI

Browser

Browser

Applikation-Server

z.B. CORBA

Mehr-Schichten-Architektur



Schnittstellen zwischen den Schichten einer C/S-Anwendung

müssen einem Standard entsprechen, um Teile des

Gesamtsystems verändern zu können ohne die gesamte

Anwendung verändern zu müssen.

Client/Server-Systeme in mehreren Schichten (tiers) VI



Client

Presentation layer

Application logiclayer

Resourcemanagement layer

Top down design

1. Festlegen der Zugriffskanäleund verwendeten ClientPlattformen

2. Festelegen desPräsentationsformats undProtokolle

3. Notwendige Funktionalitätfür die Bereitstellung derInformationen undDatenformate

4. Festlegen der benötigtenDatenquellen undDatenorganisation für dieavisierte Applikationslogik

Client/Server-Systeme in mehreren Schichten (tiers) VII



Client

Presentation layer

Application logiclayer

Resourcemanagement layer

Bottom-up design

1. Festlegen der Zugriffskanäleund verwendeten ClientPlattformen

2. Analyse existierenderRessourcen (Datenquellen)und deren angeboteneFunktionalität

3. Kapslung existierenderRessourcen und Integrationder Funktionen im Rahmeneines Interfaces

4. Anpassung der Interfaces zurApplikatinslogic, so daß diesedurch die benötigtenZugriffskanäle und Client-protokolle genutzt werden kann

Client/Server-Systeme in mehreren Schichten (tiers) VIII



Grundlegende Begriffe der Transaktionsverwaltung



Eine Transaktion (transaction) ist eine Folge von Operationen

(z.B. elementare SQL-Befehle), die zu einer unteilbaren

(atomaren) Ausführungseinheit zusammengefasst werden und

die Datenbank von einem konsistenten Zustand in einen neuen

konsistenten Zustand überführen.

Transaktionsbegriff



Zur Unterstützung des Multiuserbetriebs werden im Rahmen von

DBMS Transaktionen verwendet. Ein Datenbanksystem garantiert

so die Ausführung von Transaktionen unter Berücksichtigung der

so genannten ACID-Bedingungen. Dabei handelt es sich um die

Eigenschaften der Atomarität (atomicity), Konsistenz (consistency),

Isolation (isolation) und Dauerhaftigkeit (durability).

Transaktionskonzept



Täglich werden durch die Kunden einer Bank tausende

Überweisungen initiiert. Dabei gibt es sowohl die Forderungen

nach kurzen Antwortzeiten, als auch eines korrekten

Geldtransfers.

Zusammenfassung der notwendigen Operationen für eine

Geldüberweisung, d.h. Abbuchen vom einem Konto und

Überweisen auf ein anderes Konto.

Transaktion - Beispiel



Transaktion - Beispiel

x = read (zielKonto);

y = read (zielKonto);

x = x + 25000;

y = y + 250000;

write (zielKonto, y);

write (zielKonto, x);

Zeit Überweisung 1. Kunde Überweisung 2. Kunde

t1

t2

t3

t4

t5

t6

Inkorrekter Ablauf von zwei Überweisungen

Quelle: Gumm, H. P.; Sommer, M.: Einführung in die Informatik, Oldenbourg-Verlag



Änderungen einer Transaktion werden entweder vollkommen

oder gar nicht in die Datenbank eingebracht. Auf dieser

Grundlage kann die Anwendungsprogrammierung stark

vereinfacht werden, da Fehlerzustände (z.B. Rechnerausfall)

nicht im Programm abgefangen werden müssen.

A - Atomarität



Eine Transaktion überführt die Datenbank von einen konsistenten

Zustand in einen anderen konsistenten Zustand. Der konsistente

Zustand einer Datenbank erfordert die Einhalten aller definierten

Integritätsbedingungen. Innerhalb der Transaktion können

Integritätsbedingungen temporär verletzt werden.

C - Konsistenz



Keine gegenseitige Beeinflussung parallel ausgeführter

Transaktionen, d.h. zwischen parallel ausgeführten Transaktionen

besteht keine direkte Kommunikation. Das Ergebnis einer

Transaktion kann nicht durch andere zum gleichen Zeitpunkt

ausgeführte Transaktionen beeinflusst werden.

I - Isolation



Nach einem erfolgreichen Abschluss einer ausgeführten

Transaktion werden alle Änderungen dauerhaft in der Datenbank

gespeichert. Sollte es zu einer Störung kommen, werden die

Ergebnisse von Transaktionen durch entsprechende Recovery-

Mechanismen wieder hergestellt.

D - Dauerhaftigkeit



X/Open Transaktionssystem

X/Open-Modell für Transaktions-

systeme

Aufruf von Ressourcen-Managern

im Rahmen einer Transaktion

DBS als möglicher Typ eines

Ressoucen-Managers

Transaktionsmanager führt

Transaktionsverwaltung durch

Anwendung

TransaktionsManager

Resource Manager

TX

SQL, etc.

XA, XA+



Kriterien zur Technologieauswahlim Kontext eines verteilten Systems



Technische Aspekte

Anforderungen des Anwendungssystems

Unterstützte Standards

Unterstützte Daten- und Funktionsmodelle

Angebotene Schnittstellen (Interfaces)

Art der abzuspeichernden Informationen

Mengengerüste

Performanceeigenschaften (TPC-Benchmarks)

Auswahlkriterien I



Integrative Aspekte

Skills des vorhandenen Personals

Bereits eingesetzte Technologien

Unterstützung durch das Service Management- Softwareverteilung

- Backup

- Konfiguration Management

Ggf. vorhandene Rahmenverträge mit Lieferanten

Durchgängigkeit der Entwicklungsumgebung (z.B. MDA)

Auswahlkriterien II



Kommerzielle Aspekte

Kosten – Invest und Wartung/Pflege

Verbreitung einzusetzender Technologien am Markt

Potential des Anbieters- Eingehen auf eigene Anforderungen

- Implementierung marktgängiger Funktionalitäten

Support-Organisation- Sitz des Help Desk

- Unterstützte Landessprachen

Einschätzung externer Analysten (z.B. Gartner Group)

Auswahlkriterien III



Auswahlkriterien IV

Quelle: Massimo Pezzini: Application Server Scenario: From Stovepipes to Services, Gartner 2002



Auswahlkriterien V

Quelle: Massimo Pezzini: Application Server Scenario: From Stovepipes to Services, Gartner 2002


Documents

WS06/07Prof. Dr. Andreas Schmietendorf1 Programmierung von Client/Server- Anwendungen Grundlagen von Client/Server Systemen