Upload
doanphuc
View
217
Download
0
Embed Size (px)
Citation preview
ClientClient--ServerServer--ArchitekturArchitektur(DB(DB--Anwendungen)Anwendungen)
B.Sc. Oleg [email protected]
2Oleg Schmelzle: Client-Server-Architektur
GliederungGliederung
• 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
3Oleg Schmelzle: Client-Server-Architektur
GeschichteGeschichte
• 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
4Oleg Schmelzle: Client-Server-Architektur
GeschichteGeschichte
• 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
5Oleg Schmelzle: Client-Server-Architektur
GeschichteGeschichte
• 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ätzendie Verteilung ist unangenehm und frustrierend
Verteilte Anwendungen erfordern einen höheren administrativen AufwandRiesige Kosten für die nachfolgende Wartung der ClientsHäufige Erneuerung der Clients notwendigGeschäftsfunktionen höher bewertet als Kostensenkung
6Oleg Schmelzle: Client-Server-Architektur
SoftwareSoftware--ArchitekturArchitektur
• Warum braucht man Software-Architektur?• Klassische Definition zur Software-Architektur
Booch, Rumbaugh, and Jacobson, 1999:
„An architecture is the set of significant decisions about theorganization of a software system, the selection of the structuralelements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations amongthose elements, the composition of these structural and behavioralelements into progressively larger subsystems, and the architecturalstyle that guides this organization - …“
(The UML Modeling Language User Guide, Addison-Wesley, 1999).
7Oleg Schmelzle: Client-Server-Architektur
SoftwareSoftware--ArchitekturArchitektur
• Nichtfunktionale Anforderungen an die Software!• Gesamtkosten der Lösung
• Time to market
• Performance
• Wartbarkeit
• Einfachheit
• Veränderbarkeit und Flexibilität
Beeinflussen den Aufbau eines SW-Systems
Quelle: Vorlesung, „Software Engineering für große Informationssysteme“, Wolfgang Keller, Technische Universität Wien, SS2002
Performance
Time to market
EinfachheitFlexibilität
Kosten
Wartbarkeit
8Oleg Schmelzle: Client-Server-Architektur
Einordnung des ThemasEinordnung des Themas
Design PatternsDesign Patterns
Creational PatternsCreational PatternsBehavioral PatternsBehavioral Patterns
Structural PatternsStructural Patterns
OO Analyse & DesignOO Analyse & Design
UMLUML
Software-MetrikenSoftware-Metriken
OOPOOP
Software-EntwurfSoftware-Entwurf
Lösen Design-Probleme
BetrachteteProgrammiertechnik
Beurteilung
Hilfsmittel
Client-Server-ArchitekturClient-Server-Architektur
Organisation und Methodik der AnwendungsentwicklungWichtiger
Bestandteil
9Oleg Schmelzle: Client-Server-Architektur
Monolithische AnwendungenMonolithische Anwendungen
• Traditionelle Enterprise-Anwendungen abgekapselte Programme• Nur als abgeschlossenes Ganzes nutzbar• Redundante Abbildung von Funktionalität• Fehlende Schnittstellen zur Partionierung• Nur eingeschränkte Zugriffe auf Daten und Prozeduren• Relativ schwer zu warten• Kleine Änderungen ziehen Neustrukturierung
und Neukompilation nach sich.• am Beispiel von zwei Java-Methoden
Datenbank-Server
Gesamte Anwendungs- u. Datenverwaltungslogik gemeinsam
mit Präsentation u. Steuerung
Netz
10Oleg Schmelzle: Client-Server-Architektur
ClientClient--ServerServer--ArchitekturArchitektur
• 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 Datenbank
11Oleg Schmelzle: Client-Server-Architektur
ClientClient--ServerServer--ArchitekturArchitektur
• 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
12Oleg Schmelzle: Client-Server-Architektur
Allgemeine Aspekte der ClientAllgemeine Aspekte der Client--ServerServer--ArchitekturenArchitekturen
• Allgemein:• Indetntifikation von Diensten• Bildung von mehrfach verwendbarer Dienste
WiederverwendungKlassifikation von Diensten
• Auslagerung von mehrfach verwendeten DienstenSchafft Schnittstellen zur Verteilung
• Zentralisierung von diesen DienstenReduktion der Mehrfachentwicklung
• Wichtige Rolle• Partitionierung der Anwendung• Funktionen der Clientanwendung und Datenbankservers aufteilen
Aufteilung kann Performanz und Funktionalität beeinflussen
13Oleg Schmelzle: Client-Server-Architektur
ClientClient--ServerServer--ArchitekturArchitektur• Komponenten müssen auf die Ressourcen aufgeteilt werden• Ressourcen: Client und Server
• Unterscheidung der TrennungKlassifikation des Clients
14Oleg Schmelzle: Client-Server-Architektur
22--SchichtenSchichten--(Tier)(Tier)--ClientClient--ServerServer--ArchitekturArchitektur
• Aufteilung der Verarbeitung einer Anwendung auf zwei TeileTeilung 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
Datenbank-Server
Client
Möglichkeiten der Datenbank:- Tabellen – „tables“- Sichten - „view“- Prozeduren – „procedures“- TriggerDatenbanken:-Oracle, PostgreSQL, MySQL,-IBM DB2
Möglichkeiten des Clients:- Präsentation- Steuerung
15Oleg Schmelzle: Client-Server-Architektur
Verteilungsformen der ClientVerteilungsformen der Client--ServerServer--ArchitekturArchitektur
2. 3. 4. 5. 6.1.
Clie
nt
Präsentation/GUI Präsentation/GUI Präsentation/GUI Präsentation/GUI Präsentation/GUI Präsentation/GUI
verteilte Präsentation
Steuerung
Anwendungslogik
Datenverwaltung
Datenhaltung
Steuerung
Anwendungslogik
Datenverwaltung
Datenhaltung
Anwendungslogik
Datenverwaltung
Datenhaltung
Steuerung
Anwendungslogik
Steuerung Steuerung Steuerung
Anwendungslogik Anwendungslogik Anwendungslogik
Datenverwaltung DatenverwaltungDatenhaltung
Serv
er
Datenverwaltung
Datenhaltung Datenhaltung Datenhaltung
entfernte Präsentation
KooperativeVerarbeitung
PersistenteGeschäftsregeln
(Fat-Client – 2 ½ -Tier)
entfernte Datenbank
(Fat Client – 2-Tier)
verteilteDatenbank
(fast Monolith)
16Oleg Schmelzle: Client-Server-Architektur
Klassifikation des ClientsKlassifikation des Clients
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 NetzDatenvolumen an der Schnittstelle sehr großNur sinnvoll bei Auskunfts- und Anzeigesystemen
GUI Benutzer-interface
Anwendungs-logik
Daten-verwaltung
Daten-haltung
22 33 44 55 66Client Server
11
17Oleg Schmelzle: Client-Server-Architektur
Klassifikation des ClientsKlassifikation des Clients
GUI Benutzer-interface
Anwendungs-logik
Daten-verwaltung
Daten-haltung
22Client 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 DatenVorteile:
Wiederverwendbarkeit der AnwendungslogikVerringerung der Wartbarkeit und Steigerung der Entwicklungseffizienz
– MVC-Konzept als Grundlage möglich• auf dem Client nur die View, auf dem Server – Controller und Model
18Oleg Schmelzle: Client-Server-Architektur
Klassifikation des ClientsKlassifikation des Clients
GUI Benutzer-interface
Anwendungs-logik
Daten-verwaltung
Daten-haltung
33Client 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 ServerVorteile:
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)
19Oleg Schmelzle: Client-Server-Architektur
Klassifikation des ClientsKlassifikation des Clients
GUI Benutzer-interface
Anwendungs-logik
Daten-verwaltung
Daten-haltung
4. Fat Client – persistente Geschäftsregeln• 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
44Client Datenbank-Server
20Oleg Schmelzle: Client-Server-Architektur
Klassifikation des ClientsKlassifikation des Clients
GUI Benutzer-interface
Anwendungs-logik
Daten-verwaltung
Daten-haltung
55Client 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)
21Oleg Schmelzle: Client-Server-Architektur
Klassifikation des ClientsKlassifikation des Clients
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.
GUI Benutzer-interface
Anwendungs-logik
Daten-verwaltung
Daten-haltung
Client Server66
22Oleg Schmelzle: Client-Server-Architektur
Konzepte der 2 bis nKonzepte der 2 bis n--Tier ClientTier Client--ServerServer--ArchitekturArchitektur
GUI
Business-Logik
Datenbank
GUI
Business-Logik
Datenbank N-Datenbanken
N-Service-Logik
N-GUIs
2-Tier-ArchitekturFat-Client
N-Tier-Architektur
File Server Architektur (Flatfile)Database Server Architektur (2-Schichten)
3-Schichten Architektur4-Schichten Architektur
Intensive Arbeit der Clients
weniger intensiveArbeit der Clients
Monolith
23Oleg Schmelzle: Client-Server-Architektur
1.Tier: Client = GUI + Business Logik1.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 Clientkein MVC-Konzept möglich
• Gibt an den Server die Bearbeitung in Auftrag• Nimmt Leistungen des Servers in Anspruch
• Datenverwaltung• Rechnen• Drucken• Kommunikation
24Oleg Schmelzle: Client-Server-Architektur
2.Tier: Server = Datenbank2.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
25Oleg Schmelzle: Client-Server-Architektur
KommunikationKommunikation
• 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
26Oleg Schmelzle: Client-Server-Architektur
ArchitekturentwurfArchitekturentwurf
• 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
27Oleg Schmelzle: Client-Server-Architektur
Implementierung auf dem ClientImplementierung 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!
28Oleg Schmelzle: Client-Server-Architektur
ZusammenfassungZusammenfassungNachteile 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ätMonolithische Anwendungen vermeiden!!!
• Lösung des Problems:• Verlagerung von Anwendungsfunktionen auf Server• In Form von Prozeduren (stored procedures) (2 ½ Schichten-Modell)
29Oleg Schmelzle: Client-Server-Architektur
ImplementierugImplementierug auf dem Clientauf 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);st.setString(2, saison);st.setInt(3, turnier_ID);st.execute();int saison_ID = st.getInt(1);
}
Vorteile:Verlagern der Datenverwaltungslogik auf den Server!
Bessere und einfachere Wartbarkeitschnellere Laufzeiten und Antwortzeiten
DatenverwaltungDatenhaltung
Präsentation/GUI
AnwendungslogikSteuerung
4.
30Oleg Schmelzle: Client-Server-Architektur
StoredStored ProcedureProcedure auf dem Serverauf dem ServerCREATE 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 -- Saison-ID bestimmen
SELECT idINTO v_saison_idFROM saisonWHERE UPPER(name) = UPPER(v_saisonName) AND turnier_id = v_turnier_id;
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;
• PL/pgSQL-Funktion, die auf dem Server abgelegt wird
• Kopplungsarten:Prozedurale oder Call-Schnittstellen
31Oleg Schmelzle: Client-Server-Architektur
Vorteile von Vorteile von StoredStored ProceduresProcedures
• Vorteile:• Ausnutzung des Bausteinprinzips (Client/Server-Modell) od. (MVC-Model)• Sehr gutes Strukturierungsmittel für größere Anwendungen• Optimierung der Prozeduren möglich
PerformanceoptimierungWiederverwendungReduktion von RedundanzenKonzentration 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)
32Oleg Schmelzle: Client-Server-Architektur
Nachteile von Nachteile von StoredStored ProceduresProcedures
• 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
33Oleg Schmelzle: Client-Server-Architektur
MultiMulti--TierTier--ArchitekturArchitektur
• 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!