(DB-Anwendungen) · • Gefahren für den Erfolg einer Client/Server-Architektur • Schichtenmodell nicht berücksichtigen oder • Keine saubere Trennung der Schichten ÆMonolithische

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


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



• 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



• 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


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).


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


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


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


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


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


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


ClientClient--ServerServer--ArchitekturArchitektur• Komponenten müssen auf die Ressourcen aufgeteilt werden• Ressourcen: Client und Server

• Unterscheidung der TrennungKlassifikation des Clients


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


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)


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




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




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)




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




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)



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.


Anwendungs-logik

Daten-verwaltung

Daten-haltung

Client Server66


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


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


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


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


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


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!


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)


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.


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


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)


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


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!

Documents

(DB-Anwendungen) · • Gefahren für den Erfolg einer Client/Server-Architektur • Schichtenmodell nicht berücksichtigen oder • Keine saubere Trennung der Schichten ÆMonolithische