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

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 WS06/07 Prof. Dr. Andreas Schmietendorf

Grundlegendes zum Client/Server-Prinzip WS06/07 Prof. Dr. Andreas Schmietendorf

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 WS06/07 Prof. Dr. Andreas Schmietendorf

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 WS06/07 Prof. Dr. Andreas Schmietendorf

Prof. Dr. Andreas Schmietendorf Klassen von Servern I 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 WS06/07 Prof. Dr. Andreas Schmietendorf

Prof. Dr. Andreas Schmietendorf Klassen von Servern II 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 WS06/07 Prof. Dr. Andreas Schmietendorf

Klassen von Servern III 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 WS06/07 Prof. Dr. Andreas Schmietendorf

Server unter WindowsXP Prof. Dr. Andreas Schmietendorf

Grundlagen verteilter Systeme WS06/07 Prof. Dr. Andreas Schmietendorf

Unternehmensarchitekturen WS06/07 Prof. Dr. Andreas Schmietendorf

Definition und Abgrenzung 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. WS06/07 Prof. Dr. Andreas Schmietendorf

Gegenstand einer Verteilung 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) WS06/07 Prof. Dr. Andreas Schmietendorf

Charakteristik verteilter Systeme I 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) WS06/07 Prof. Dr. Andreas Schmietendorf

Charakteristik verteilter Systeme II 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 WS06/07 Prof. Dr. Andreas Schmietendorf

Prof. Dr. Andreas Schmietendorf Begriff der Verteilungstransparenz & Vor- und Nachteile verteilter Systeme WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilungstransparenz I 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. Quelle: Oechsle, R.: Verteilte Systeme, in Taschenbuch der Informatik, Fachbuchverlag Leipzig WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilungstransparenz II 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. Quelle: Orfali, R. et al.: The Essential Client/Server Survival Guide – Second Edition, John Wiley & Sons, New York 1996 WS06/07 Prof. Dr. Andreas Schmietendorf

Arten der Verteilungstransparenz I 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. Quelle: Oechsle, R.: Verteilte Systeme, in Taschenbuch der Informatik, Fachbuchverlag Leipzig WS06/07 Prof. Dr. Andreas Schmietendorf

Arten der Verteilungstransparenz II 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. Quelle: Oechsle, R.: Verteilte Systeme, in Taschenbuch der Informatik, Fachbuchverlag Leipzig WS06/07 Prof. Dr. Andreas Schmietendorf

Vorteile verteilter Systeme 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 WS06/07 Prof. Dr. Andreas Schmietendorf

Nachteile 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) WS06/07 Prof. Dr. Andreas Schmietendorf

Kommunikation in verteilten Systemen WS06/07 Prof. Dr. Andreas Schmietendorf

Kommunikation in verteilten Systemen 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 WS06/07 Prof. Dr. Andreas Schmietendorf

Kommunikation in verteilten Systemen 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 WS06/07 Prof. Dr. Andreas Schmietendorf

Kommunikation in verteilten Systemen WS06/07 Prof. Dr. Andreas Schmietendorf

Kommunikation in verteilten Systemen 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 WS06/07 Prof. Dr. Andreas Schmietendorf

Kommunikation in verteilten Systemen 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 WS06/07 Prof. Dr. Andreas Schmietendorf

Kommunikation in verteilten Systemen 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 WS06/07 Prof. Dr. Andreas Schmietendorf

Kommunikation in verteilten Systemen 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 WS06/07 Prof. Dr. Andreas Schmietendorf

Begriff der Middleware 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. In Anlehnung an: Orfali, R. et al.: The Essential Client/Server Survival Guide – Second Edition, John Wiley & Sons, New York 1996 WS06/07 Prof. Dr. Andreas Schmietendorf

Prof. Dr. Andreas Schmietendorf General Middleware 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) In Anlehnung an: Orfali, R. et al.: The Essential Client/Server Survival Guide – Second Edition, John Wiley & Sons, New York 1996 WS06/07 Prof. Dr. Andreas Schmietendorf

Service-spezifsche 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, …) In Anlehnung an: Orfali, R. et al.: The Essential Client/Server Survival Guide – Second Edition, John Wiley & Sons, New York 1996 WS06/07 Prof. Dr. Andreas Schmietendorf

Mehrschichtige Client/Server-Systeme WS06/07 Prof. Dr. Andreas Schmietendorf

Client/Server-Systeme in mehreren Schichten (tiers) I 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, …) WS06/07 Prof. Dr. Andreas Schmietendorf

Client/Server-Systeme in mehreren Schichten (tiers) II 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) WS06/07 Prof. Dr. Andreas Schmietendorf

Client/Server-Systeme in mehreren Schichten (tiers) III Zwei-Schichten-Architektur WS06/07 Prof. Dr. Andreas Schmietendorf

Client/Server-Systeme in mehreren Schichten (tiers) IV Drei-Schichten-Architektur WS06/07 Prof. Dr. Andreas Schmietendorf

Client/Server-Systeme in mehreren Schichten (tiers) V Mehr-Schichten-Architektur WS06/07 Prof. Dr. Andreas Schmietendorf

Client/Server-Systeme in mehreren Schichten (tiers) VI 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. WS06/07 Prof. Dr. Andreas Schmietendorf

Client/Server-Systeme in mehreren Schichten (tiers) VII WS06/07 Prof. Dr. Andreas Schmietendorf

Client/Server-Systeme in mehreren Schichten (tiers) VIII WS06/07 Prof. Dr. Andreas Schmietendorf

Grundlegende Begriffe der Transaktionsverwaltung WS06/07 Prof. Dr. Andreas Schmietendorf

Prof. Dr. Andreas Schmietendorf Transaktionsbegriff 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. WS06/07 Prof. Dr. Andreas Schmietendorf

Prof. Dr. Andreas Schmietendorf Transaktionskonzept 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). WS06/07 Prof. Dr. Andreas Schmietendorf

Transaktion - Beispiel 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. WS06/07 Prof. Dr. Andreas Schmietendorf

Transaktion - Beispiel Inkorrekter Ablauf von zwei Überweisungen Quelle: Gumm, H. P.; Sommer, M.: Einführung in die Informatik, Oldenbourg-Verlag WS06/07 Prof. Dr. Andreas Schmietendorf

Prof. Dr. Andreas Schmietendorf A - Atomarität Ä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. WS06/07 Prof. Dr. Andreas Schmietendorf

Prof. Dr. Andreas Schmietendorf C - Konsistenz 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. WS06/07 Prof. Dr. Andreas Schmietendorf

Prof. Dr. Andreas Schmietendorf I - Isolation 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. WS06/07 Prof. Dr. Andreas Schmietendorf

Prof. Dr. Andreas Schmietendorf D - Dauerhaftigkeit 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. WS06/07 Prof. Dr. Andreas Schmietendorf

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 WS06/07 Prof. Dr. Andreas Schmietendorf

Kriterien zur Technologieauswahl im Kontext eines verteilten Systems WS06/07 Prof. Dr. Andreas Schmietendorf

Prof. Dr. Andreas Schmietendorf Auswahlkriterien I 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) WS06/07 Prof. Dr. Andreas Schmietendorf

Prof. Dr. Andreas Schmietendorf Auswahlkriterien II 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) WS06/07 Prof. Dr. Andreas Schmietendorf

Prof. Dr. Andreas Schmietendorf Auswahlkriterien III 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) WS06/07 Prof. Dr. Andreas Schmietendorf

Prof. Dr. Andreas Schmietendorf Auswahlkriterien IV Quelle: Massimo Pezzini: Application Server Scenario: From Stovepipes to Services, Gartner 2002 WS06/07 Prof. Dr. Andreas Schmietendorf

Prof. Dr. Andreas Schmietendorf Auswahlkriterien V Quelle: Massimo Pezzini: Application Server Scenario: From Stovepipes to Services, Gartner 2002 WS06/07 Prof. Dr. Andreas Schmietendorf