Abgrenzung zur 2-Tier-Architektur
Im Gegensatz zur 2-Tier-Architektur wird bei der 3-Tier-Architektur die Server-Tier
(analog: Server-Schicht) weiter aufgeteilt. Businesslogik und Datenhaltung werden
getrennt und jeweils in eine eigenständige Tier (s.o.) verschoben.
Die herausgetrennte Businesslogik bzw. Anwendungsschicht wird in der Praxis oft mit dem
Begriff Middleware umschrieben. Da in ihr die eigentliche Programmlogik und damit verbundene
rechenintensive Prozesse enthalten sind, steht sie oft im Fokus von
performanceverbessernden Maßnahmen.
Vorteile der 3-Tier-Server-Architektur
Die 3-Tier-Architektur ermöglicht es,
Businesslogik und Datenhaltung auf getrennten Systemen zu verwalten und somit eine
bessere Skalierbarkeit zu erreichen. Die Systeme der Datenhaltung und der Businesslogik
können getrennt voneinander besser an die jeweiligen Anforderungen einer Anwendung angepasst
werden. In der Praxis wird für die Schicht der Datenhaltung häufig ein
Datenbankserver wie Oracle, MySQL oder Postgres eingesetzt.
Dies wiederum bringt weitere Strategien für eine mögliche Lastverteilung mit sich,
auf die in dieser Arbeit aber nicht weiter eingegangen werden kann.
Abbildung 2 verdeutlicht die Abhängigkeiten der Schichten innerhalb des 3-Tier-Architektur-Modells:
Abbildung 2: 3-Tier-Architektur J2EE-Anwendung
Quelle: Eigene Darstellung
Im Idealfall greift die Präsentationsschicht ausschließlich über definierte
Businesslogik-Schnittstellen auf persistierte Daten der Datenhaltung zu.
In der Praxis findet jedoch in Einzelfällen ein direkter Zugriff statt.
Dies kann zu Problemen bei hoher Last führen, da sich die Lastverteilung
in der Regel auf die Businesslogik und nicht auf die Präsentations-Schicht fokussiert.
In Kapitel 2.2.1 wird auf dieses Problem näher eingegangen und erläutert,
wie man es mit den eingesetzten Frameworks umgehen kann.
