Client-Server-Architektur - Das Fachgebiet Software Engineering
Werbung
Client-Server-Architektur (DB-Anwendungen) B.Sc. Oleg Schmelzle [email protected] Gliederung • Geschichte • Ausgangssituation • Ziele • Einordnung des Themas • Monolithische Anwendungen • Client Server Architektur • Charakteristika von C/S-Architekturen (Verteilungsformen) • Klassifikation des Clients • 2-Schichten Client/Server-Architektur • Beispiel einer Implementierung • Mit dem Ziel zum Übergang zur n-Schichten-Architektur • Zusammenfassung Oleg Schmelzle: Client-Server-Architektur 2 Geschichte • Ausgangssituation • leistungsfähige Server sind teuer! • Zunächst unter dem Aspekt: Kostenreduktion • Optimierung von Geschäftsprozessen • Ziele der Einführung: • • • • • • Geschäftsfunktionen direkter zu unterstützen Informationen näher zum Anwender zu bringen Ersetzt großrechnerdominierte und zentralisierte Ansätze Server entlasten und Rechenkapazität auf Clients verlagern Bindet lokale und isolierte Rechner zusammen Um zentralisierte Dienste in Anspruch zu nehmen • (ggf. Hardware-/Softwarebetriebsmittel – z.B: PrintServer) • Von der lokalen Datenbank auf den Database-Server • Jeder Benutzer verfügt über gleiche Funktionen und gleiche Datenbank Oleg Schmelzle: Client-Server-Architektur 3 Geschichte • Weitere Ziele: • Optimale Ausnutzung der Ressourcen • Einsatz von kostengünstigeren Ressourcen (Workstations) • Teure Ressourcen allen Nutzern anbieten Æ Kooperation im Team ermöglichen • Heute: Datenbanken sind unternehmensstrategische Kerntechnik • Konzept der Anwendungsprogrammierung • Von Flatfiles zu einer richtigen Datenbank Æ Standardisierte Konzepte der Anwendungsentwicklung gefragt Oleg Schmelzle: Client-Server-Architektur 4 Geschichte • Wirtschaftliche Nachteile • Kein Garant für Kosteneinsparungen • Große Anzahl von Clients notwendig • eine Firma mit 1000 Arbeitsplätzen muss die Kosten dafür aufbringen • Neue Versionen der Software auf allen Clients zu verteilen • z.B: schwierig bei Unternehmen mit mehr als 1000 Arbeitsplätzen Æ die Verteilung ist unangenehm und frustrierend Æ Verteilte Anwendungen erfordern einen höheren administrativen Aufwand Æ Riesige Kosten für die nachfolgende Wartung der Clients Æ Häufige Erneuerung der Clients notwendig Æ Geschäftsfunktionen höher bewertet als Kostensenkung Oleg Schmelzle: Client-Server-Architektur 5 Software-Architektur • Warum braucht man Software-Architektur? • Klassische Definition zur Software-Architektur Booch, Rumbaugh, and Jacobson, 1999: „An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization - …“ (The UML Modeling Language User Guide, Addison-Wesley, 1999). Oleg Schmelzle: Client-Server-Architektur 6 Software-Architektur • Nichtfunktionale Anforderungen an die Software! • Gesamtkosten der Lösung • Time to market Performance • Performance Time to market • Wartbarkeit Kosten • Einfachheit • Veränderbarkeit und Flexibilität Wartbarkeit Flexibilität Einfachheit Æ Beeinflussen den Aufbau eines SW-Systems Quelle: Vorlesung, „Software Engineering für große Informationssysteme“, Wolfgang Keller, Technische Universität Wien, SS2002 Oleg Schmelzle: Client-Server-Architektur 7 Einordnung des Themas Design DesignPatterns Patterns Creational CreationalPatterns Patterns Behavioral BehavioralPatterns Patterns Structural StructuralPatterns Patterns UML UML Hilfsmittel OO OOAnalyse Analyse&&Design Design Beurteilung Software-Metriken Software-Metriken OOP OOP Lösen Design-Probleme Wichtiger Bestandteil Betrachtete Programmiertechnik Organisation und Methodik der Anwendungsentwicklung Client-Server-Architektur Client-Server-Architektur Software-Entwurf Software-Entwurf Oleg Schmelzle: Client-Server-Architektur 8 Monolithische Anwendungen • • • • • • • Traditionelle Enterprise-Anwendungen abgekapselte Programme Nur als abgeschlossenes Ganzes nutzbar Redundante Abbildung von Funktionalität Fehlende Schnittstellen zur Partionierung DatenbankNur eingeschränkte Zugriffe auf Daten und Prozeduren Server Relativ schwer zu warten Kleine Änderungen ziehen Neustrukturierung und Neukompilation nach sich. • am Beispiel von zwei Java-Methoden Netz Gesamte Anwendungs- u. Datenverwaltungslogik gemeinsam mit Präsentation u. Steuerung Oleg Schmelzle: Client-Server-Architektur 9 Client-Server-Architektur • Warum braucht man Client/Server-Architektur? • Moderne Datenbanksysteme basieren auf Client/Server-Architektur • Client/Server-Architektur als eine Form der Schichten-Architektur • Ausnutzung der lokal verfügbaren Rechenleistung • Um zentrale Server zu entlasten • Vereinigt Qualitäten verschiedener Plattformen • Zentrale Verwaltung von Daten • Eröffnet die Möglichkeit, Datenbestände zu integrieren Æ Steigerung der Effizienz Æ Vermeiden von Redundanzen Oleg Schmelzle: Client-Server-Architektur Datenbank 10 Client-Server-Architektur • Ein Systemdesign • • • • • • Organisation und Methodik der Anwendungsentwicklung eine Strukturierungsmöglichkeit bei verteilter Informationsverarbeitung Leitgedanke: Erforderliche Funktionen in Form von Diensten verschiedene Dienste für eigene Funktionen Dienste unabhängig von der physikalischen Verteilung z.B: Dienste: Vertrieb, Rechnungswesen • Probleme • Konsistenz der Daten • Aktualität der abgelegten Funktionen und Daten • Unterschiede in Bezug auf Codierungen, Formate oder Datentypen Æ Kompensation durch Schnittstellen Oleg Schmelzle: Client-Server-Architektur 11 Allgemeine Aspekte der Client-Server-Architekturen • Allgemein: • Indetntifikation von Diensten • Bildung von mehrfach verwendbarer Dienste Æ Wiederverwendung Æ Klassifikation von Diensten • Auslagerung von mehrfach verwendeten Diensten Æ Schafft Schnittstellen zur Verteilung • Zentralisierung von diesen Diensten Æ Reduktion der Mehrfachentwicklung • Wichtige Rolle • Partitionierung der Anwendung • Funktionen der Clientanwendung und Datenbankservers aufteilen Æ Aufteilung kann Performanz und Funktionalität beeinflussen Oleg Schmelzle: Client-Server-Architektur 12 Client-Server-Architektur • Komponenten müssen auf die Ressourcen aufgeteilt werden • Ressourcen: Client und Server • Unterscheidung der Trennung Æ Klassifikation des Clients Oleg Schmelzle: Client-Server-Architektur 13 2-Schichten-(Tier)-Client-Server-Architektur • Aufteilung der Verarbeitung einer Anwendung auf zwei Teile Æ Teilung von Datenbank und Logik + Anzeigefunktion • Server (= Dienstleister, Backend-Komponente) - Verwaltet die Datenbankzugriffe/Transaktionen - Verwaltet Daten • Client (= Dienstnutzer, Workstation o. Frontend) – Fat Client - Business-Logik: Funktionen und Prozeduren - Datenverwaltungslogik, Schnittstellen - GUI: Anzeigefunktion - Anwendungslogik, Präsentation, Steuerung Möglichkeiten des Clients: - Präsentation - Steuerung Client DatenbankServer Möglichkeiten der Datenbank: - Tabellen – „tables“ - Sichten - „view“ - Prozeduren – „procedures“ - Trigger Datenbanken: -Oracle, PostgreSQL, MySQL, -IBM DB2 Oleg Schmelzle: Client-Server-Architektur 14 Verteilungsformen der Client-Server-Architektur 2. 3. 4. 5. 6. Client 1. Präsentation/GUI Präsentation/GUI Präsentation/GUI Präsentation/GUI Präsentation/GUI Präsentation/GUI Steuerung Steuerung Anwendungslogik Steuerung Steuerung Steuerung Anwendungslogik Anwendungslogik Anwendungslogik Datenverwaltung Datenverwaltung Datenhaltung Datenhaltung Datenhaltung Server Steuerung Anwendungslogik Anwendungslogik Datenverwaltung Datenverwaltung Datenverwaltung Datenverwaltung Datenhaltung Datenhaltung Datenhaltung Datenhaltung entfernte Präsentation Kooperative Verarbeitung verteilte Präsentation Anwendungslogik Persistente entfernte Geschäftsregeln Datenbank (Fat-Client – 2 ½ -Tier) (Fat Client – 2-Tier) Oleg Schmelzle: Client-Server-Architektur verteilte Datenbank (fast Monolith) 15 Klassifikation des Clients Benutzerinterface GUI Client 11 Anwendungslogik 22 33 Datenverwaltung 44 Server Datenhaltung 55 66 1. Null Client – Verteilte Präsentation • • • • • Client übergibt nur Tastaturanschläge und Mausbewegungen an Server Präsentationsfunktionen auf dem Client Alle anderen Schichten auf dem Server Im UNIX-Umfeld: X-Window-System (X-Terminals) Nachteile: – Hohes Transportvolumen von Ein- und Ausgaben über das Netz Æ Datenvolumen an der Schnittstelle sehr groß Æ Nur sinnvoll bei Auskunfts- und Anzeigesystemen Oleg Schmelzle: Client-Server-Architektur 16 Klassifikation des Clients Benutzerinterface GUI Client Anwendungslogik 22 Datenverwaltung Datenhaltung Server 2. Thin Client – Entfernte Präsentation • komplette GUI mit voller Funktionalität • Steuerung auf dem Client • mit Dialogsteuerungslogik und Prüffunktionen • Aufgaben des Servers: Applikationslogik und Daten Vorteile: Æ Wiederverwendbarkeit der Anwendungslogik Æ Verringerung der Wartbarkeit und Steigerung der Entwicklungseffizienz – MVC-Konzept als Grundlage möglich • auf dem Client nur die View, auf dem Server – Controller und Model Oleg Schmelzle: Client-Server-Architektur 17 Klassifikation des Clients GUI Benutzerinterface Client Anwendungslogik 33 Datenverwaltung Datenhaltung Server 3. Kooperative Verarbeitung - Applet Client • Teile der Applikationslogik laufen auf dem Client • Bei großen Client/Server Anwendungen mit vielen Benutzern • Aufteilung der Anwendungslogik auf LAN und Server Vorteile: Æ Definition der kleinsten gemeinsamen Schnittstelle Æ Hohe Flexibilität in der Zuordnung der Funktionseinheiten Nachteile: • Redundante Speicherung von Prüftabellen • Erlaubt Ablage von Daten auf der Client-Seite (z.B. Cookies) Oleg Schmelzle: Client-Server-Architektur 18 Klassifikation des Clients GUI Benutzerinterface Client Anwendungslogik Datenverwaltung 44 4. Fat Client – persistente Geschäftsregeln • • • • Datenhaltung Datenbank-Server Häufiges Verteilungsmodell im Rahmen der 2-Schichten-Architektur Erlauben anwendungsspezifischen Code in Form von Prozeduren auf dem Server abzulegen Gespeicherte Prozeduren sind indentifizierende Geschäftsregeln Vorteile – Geringe Netzbelastung Æ Zentralisierung von Geschäftsregeln – Persistente Ablage in der Datenbank, Aufruf über API – Stehen allen Anwendungen zur Verfügung • Nachteile – Verlagerung von Funktionen auf Client-Seite Æ Vermischen von Präsentation und Anwendungslogik Æ schlechte Wartbarkeit – ggf. eine Abhängigkeit zum verwendeten DBMS – Keine nebenläufige Transaktionen Oleg Schmelzle: Client-Server-Architektur 19 Klassifikation des Clients GUI Benutzerinterface Anwendungslogik Datenverwaltung Client Datenhaltung 55 Server 5. Zugriff auf entfernte Datenbanken (Remote Database) • Wie Punkt 4, nur • Für Standard-Technologie im LAN • Nicht realisierbar für große Datenmengen und häufige Zugriffe – Da eine Trennung zw. Datenverwaltung und Daten • Nachteile: • • • • schlechte Wartung des Codes Sehr hohes Netzvolumen Keine Optimierungen möglich (keine geeignete Schnittstelle) Keine Zusammenfassung mehrerer Zugriffe möglich (Prozeduren) Oleg Schmelzle: Client-Server-Architektur 20 Klassifikation des Clients GUI Benutzerinterface Anwendungslogik Client Datenverwaltung Datenhaltung 66 Server 6. Zugriff auf verteilte Datenbanken • • • • Wie Punkt 5, nur Auf jedem Rechner ein DBMS-System installiert Verwaltung verteilter Datenbestände Nachteile: – Redundante Speicherung der Daten – Unikate Ablage auf dem Client – Funktionen müssen vorhanden sein, um Verteilung und Aktualisierung der Kopien abzudecken. Oleg Schmelzle: Client-Server-Architektur 21 Konzepte der 2 bis n-Tier Client-Server-Architektur GUI GUI N-GUIs BusinessLogik BusinessLogik N-ServiceLogik Datenbank Datenbank NDatenbanken Monolith 2-Tier-Architektur Fat-Client N-Tier-Architektur Intensive Arbeit der Clients File Server Architektur (Flatfile) Database Server Architektur (2-Schichten) 3-Schichten Architektur weniger intensive 4-Schichten Architektur Arbeit der Clients Oleg Schmelzle: Client-Server-Architektur 22 1.Tier: Client = GUI + Business Logik • • • • • Definiert Schnittstellen für Benutzerinteraktionen Ziel: einfache zu bedienende Oberfläche Lokale Bedienung vom Endanwender Keine Trennung zwischen Darstellung und Anwendungslogik erlaubt verschiedene Präsentationen der selbigen Serveranwendung nicht möglich, da Business Logik auf dem Client Æ kein MVC-Konzept möglich • Gibt an den Server die Bearbeitung in Auftrag • Nimmt Leistungen des Servers in Anspruch • • • • Datenverwaltung Rechnen Drucken Kommunikation Oleg Schmelzle: Client-Server-Architektur 23 2.Tier: Server = Datenbank • Aufgaben des Servers: • Gibt Daten zu weiteren Aufbereitung an den Client weiter • Kein spezieller Rechner, sondern ein Dienst/Prozess • Jedoch heute häufig ein spezieller Rechner mit viel Speicher, da begrenzte Leistung vorhanden • • • • Bietet Services zur Verwaltung an z.B.: Dienst: „Vertrieb“ – Kundendaten verwalten Datenbankzugriffe/Transaktionen verwalten Verwaltung von Daten, keine grafische Oberfläche • Anforderungen an den Server: • Hohe Ausfallsicherheit (ggf. Reserve-Server) • Hohes Leistungsvermögen Oleg Schmelzle: Client-Server-Architektur 24 Kommunikation • Kommunikation basiert auf Transaktionen • Transaktionen werden generiert auf dem Client • Zur Verarbeitung dem Server überlassen • Transaktion: • Eine Folge logisch zusammenhängender Aktionen • Übertragen nach dem Prinzip vollständig oder gar nicht (Rollback) • Anbindung erfolgt über Netzwerk • Größenordnung des Fat-Client-Systems nicht begrenzt • Jedoch nur für Anwendungen mit wenig „Verkehr“ geeignet! Æ Schlechte Performance Oleg Schmelzle: Client-Server-Architektur 25 Architekturentwurf • Gefahren für den Erfolg einer Client/Server-Architektur • Schichtenmodell nicht berücksichtigen oder • Keine saubere Trennung der Schichten Æ Monolithische Anwendungen erstellen • deren Daten nur auf dem Server installiert sind Æ Wenig skalierbar! • Client/Server Architektur als Client/Server-Datenbank (Fat Client) • Nicht geeignet die redundante Abbildung von Geschäftsregeln zu unterbinden • Keine hohe Flexibilität vorhanden • für ständige Veränderungen der Geschäftsregeln • Keine Mehrfachverwendung von Services auf der Ebene der Anwendungslogik • In der Praxis verwendet man Kombinationen der Verteilungsformen • oder n-Tier-Architekturen Oleg Schmelzle: Client-Server-Architektur 26 Implementierung auf dem Client • Beispiel einer 2 schichtigen Implementierung void ladeDataForBoxSaison(String turnier) throws SQLException { String str = "SELECT DISTINCT sa.name " "FROM saison sa " "JOIN turnier t " "ON sa.turnier_id = t.id " "WHERE t.name = ? ORDER BY sa.name"; PreparedStatement st = Login.con.prepareStatement(str); st.setString(1, turnier); ResultSet rs = st.executeQuery(); Vector executeString = new Vector(); while (rs.next()) { executeString.add(rs.getString(1)); } view.setSaison(executeString); } • Nachteil: schlecht wartbar! Oleg Schmelzle: Client-Server-Architektur 27 Zusammenfassung Nachteile des 2-Tier-Modells = Datenbank-Servers • Keine Ausnutzung der Wiederverwendung • Wiederverwendung nur durch Copy-Paste und Aufblähen des Codes • Schafft neue Sicherheits- und Konsistenzprobleme • Keine Sicherstellung der Datenintegrität im Mehrnutzerbetrieb • Datenverwaltungslogik und Anwendungslogik im Client • Einbettung der DB-Sprache in eine Programmiersprache • Umfang des Codes im Client vergrößert • Hohe Netzwerkbelastung durch Operationen • die über viele Datensätze ausgeführt werden müssen • Hohe Wartungs- und Installationskomplexität Æ Monolithische Anwendungen vermeiden!!! • Lösung des Problems: • Verlagerung von Anwendungsfunktionen auf Server • In Form von Prozeduren (stored procedures) (2 ½ Schichten-Modell) Oleg Schmelzle: Client-Server-Architektur 28 Implementierug auf dem Client Beispiel einer 2 ½ schichtigen Implementierung public void saisonAnlegen(String saison, int turnier_ID) throws SQLException { String str = "{? = call insertSaisonJava (?, ?) }"; CallableStatement st = Login.con.prepareCall(str); st.registerOutParameter(1, Types.INTEGER); 4. st.setString(2, saison); Präsentation/GUI st.setInt(3, turnier_ID); Steuerung st.execute(); Anwendungslogik int saison_ID = st.getInt(1); } Vorteile: Verlagern der Datenverwaltungslogik auf den Server! Æ Bessere und einfachere Wartbarkeit Æ schnellere Laufzeiten und Antwortzeiten Oleg Schmelzle: Client-Server-Architektur Datenverwaltung Datenhaltung 29 Stored Procedure auf dem Server CREATE OR REPLACE FUNCTION insertSaisonJava(TEXT, INTEGER) RETURNS INTEGER AS ‚ DECLARE v_saisonName ALIAS FOR $1; v_turnier_id ALIAS FOR $2; v_saison_id INTEGER; BEGIN • PL/pgSQL-Funktion, die auf dem -- Saison-ID bestimmen SELECT id Server abgelegt wird INTO v_saison_id • Kopplungsarten: FROM saison WHERE UPPER(name) = UPPER(v_saisonName) Prozedurale oder CallAND turnier_id = v_turnier_id; Schnittstellen IF v_saison_id IS NULL THEN INSERT INTO saison(name, turnier_id) VALUES (v_saisonName, v_turnier_id); v_saison_id = currval(''gen_saison_id''); END IF; RETURN v_saison_id; END; ' LANGUAGE plpgsql; Oleg Schmelzle: Client-Server-Architektur 30 Vorteile von Stored Procedures • Vorteile: • Ausnutzung des Bausteinprinzips (Client/Server-Modell) od. (MVC-Model) • Sehr gutes Strukturierungsmittel für größere Anwendungen • Optimierung der Prozeduren möglich Æ Performanceoptimierung Æ Wiederverwendung Æ Reduktion von Redundanzen Æ Konzentration von Geschäftsregeln • Prozeduren nur vom DBMS abhängig und nicht von externen Programmiersprachen oder Betriebssystemumgebungen • Ausführung der Prozeduren unter Kontrolle des DBMS • zentrale Kontrolle der Prozeduren: redundanzfreie Darstellung relevanter Aspekte der Anwendungsfunktionalität • Rechtevergabe für Prozeduren (möglich einzelne Arbeitsplätze zu spezifizieren) Oleg Schmelzle: Client-Server-Architektur 31 Nachteile von Stored Procedures • Nachteile: • statische Einbettung: Vorübersetzer-Prinzip • Call-Anweisungen zur Übersetzungszeit festgelegt • Keine Änderung der Parameter mehr möglich • dynamische Einbettung: • Konstruktion von SQL-Anweisungen zur Laufzeit • Andere Alternative zur Lösung des Problems Æ Verwendung von 3 bis n-Schichten-Architektur Oleg Schmelzle: Client-Server-Architektur 32 Multi-Tier-Architektur • Weiterentwicklung der Client/Server-Architektur • Allgemeine Logik auf Server auslagern • Auf dem Client nur noch die Präsentationsschicht • Mit seiner individueller Logik • Heutiger Trend • Verteilte Anwendungen als mehrschichtige Anwendungen • Vorteile: • • • • • • Bessere Skalierbarkeit bei den Servern Einschluss der webbasierten Technologien weniger Speicher und weniger Kosten für die Clients Wiederverwendung der Anwendungslogik Verringern der Wartbarkeit Weitere Aspekte dieser Entwicklung im darauf folgenden Vortrag Danke für die Aufmerksamkeit! Oleg Schmelzle: Client-Server-Architektur 33
