Client-Server-Architektur - Das Fachgebiet Software Engineering

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