Schichtenarchitektur

Grundprinzip und Einteilung

Die Schichtenarchitektur, auch Schichtenmodell oder Schichtenmuster, ist ein häufig verwendetes Prinzip zur Strukturierung von Softwaresystemen. Funktionen, Komponenten oder Klassen werden dabei konzeptionell verschiedenen Schichten zugeordnet. Grundsätzlich dürfen Elemente einer höheren Schicht nur Elemente tieferer Schichten verwenden. Dadurch entsteht ein mehrschichtiges System mit klar geregelten Abhängigkeiten.

Bei einer strengen oder geschlossenen Schichtenarchitektur darf eine Schicht ausschließlich die unmittelbar darunterliegende Schicht aufrufen; Schichten dürfen nicht übersprungen werden. Dies wird als direkte Adressierung bezeichnet. Änderungen betreffen im ungünstigsten Fall die angrenzenden Schichten und nicht das gesamte System. Dadurch lassen sich die Schichten leichter testen, warten und austauschen.

Bei einer nicht-strengen oder offenen Schichtenarchitektur darf eine Schicht jede beliebige tiefere Schicht aufrufen. Diese indirekte Adressierung kann die Ausführung beschleunigen, weil Daten nicht durch sämtliche Zwischenschichten geleitet werden müssen. Dafür nimmt die Kopplung, also die gegenseitige Abhängigkeit der Schichten, zu. Daneben gibt es Modelle, in denen eine Schicht sowohl mit der darüberliegenden als auch mit der darunterliegenden Schicht kommuniziert; das bekannteste Beispiel ist das ISO/OSI-Modell.

Im Englischen bezeichnet „Layer“ funktionale Einheiten innerhalb derselben Software. Von „Tiers“ spricht man, wenn funktionale Einheiten auf voneinander unabhängiger Infrastruktur laufen.

Nutzen und Grenzen

Eine Schichtenarchitektur verringert die Komplexität der Abhängigkeiten. Sie fördert eine geringe Kopplung zwischen den Schichten und zugleich eine hohe Kohäsion, also einen starken inneren Zusammenhang der Aufgaben innerhalb einer Schicht. Außerdem verhindert sie Zyklen im Abhängigkeitsgrafen. Das System wird dadurch verständlicher und leichter wartbar. Einzelne Schichten können häufig ersetzt werden, ohne dass das gesamte System geändert werden muss.

Nachteilig kann zusätzlicher Code sein, der Daten zwischen den Schichten weiterleitet oder umwandelt. Er kann die Ausführungsgeschwindigkeit vermindern. Das fällt besonders auf, wenn Daten strukturell besser zu einer tieferen Schicht passen als zu der Schicht, auf die ein Anwendungsteil zugreifen darf. Ein typisches Beispiel sind Reports, die Aggregate wie Summen oder Durchschnittswerte darstellen. Bei solchen Anwendungsteilen wird zugunsten der Geschwindigkeit mitunter auf Vorteile der konsequenten Schichtentrennung verzichtet.

Zwei- und Drei-Schichten-Architekturen

Architekturen mit mindestens zwei Schichten heißen Mehrschicht- oder Mehrschichtenarchitekturen.

Eine Zwei-Schichten-Architektur besteht aus einer höheren und einer niedrigeren Schicht. Nur die höhere darf auf die niedrigere zugreifen. Die niedrigere Schicht stellt daher als Server Dienste für die höhere, den Client, bereit; deshalb wird diese Form häufig Client-Server-Architektur genannt. Client und Server müssen nicht auf unterschiedlichen Rechnern laufen. Sie können auch zwei Software-Module auf demselben Rechner und meist innerhalb derselben Anwendung sein. Bei einer rechnerseitig verteilten Form liegt ein großer Teil der Rechenarbeit auf den Client-Rechnern, um den Server zu entlasten. Traditionell werden ein Fat Client und ein Fat Server eingesetzt: Auf dem Server läuft eine Datenbankanwendung, während die Clients Logik und Benutzerschnittstelle übernehmen.

Eine Drei-Schichten-Architektur besitzt zusätzlich meist eine Logikschicht für die Datenverarbeitung. Ihre typische Gliederung lautet:

• Die Präsentationsschicht oder das Front-End stellt Daten dar, nimmt Benutzereingaben entgegen und bildet die Benutzerschnittstelle. • Die Logikschicht, auch Businessschicht, Middle Tier oder Enterprise Tier, enthält die Verarbeitungsmechanismen und die Anwendungslogik. • Die Datenhaltungsschicht oder das Back-End enthält die Datenbank und speichert beziehungsweise lädt Daten.

Bei verteilten Systemen ist diese Trennung gut skalierbar. Beispielsweise kann die Datenhaltung auf einem zentralen Datenbankserver, die Logik auf Workgroup-Servern und die Präsentation auf den Workstations der Benutzer laufen. Bei Citrix entspricht die Interaktion dem Client, die Funktion dem Citrix Server und die Datenhaltung dem Datenbankserver. Allgemein werden präsentationsnahe Schichten eher vom Client und datennahe Schichten eher vom Server bearbeitet.

Das Modell kann ebenso innerhalb eines einzelnen Softwaresystems umgesetzt werden. Dazu werden Module für Präsentation, Anwendungslogik und persistente Speicherung den drei Schichten zugeordnet und voneinander entkoppelt. Neben dem Model-View-Controller-Muster gilt diese Gliederung üblicherweise als Mindestmaß architektonischer Strukturierung, sofern keine zwingenden Gründe für eine andere Entscheidung vorliegen.

Typische Schichten einer Anwendung

Art und Anzahl der Schichten sind grundsätzlich nicht festgelegt. Moderne Anwendungen können unter anderem Dependency Injection, Anwendungspräsentation, Geschäftslogik, Datenzugriff, Steuerung, Datenpräsentation und Datenhaltung unterscheiden.

Die Dependency-Injection-Schicht ist die oberste Anwendungsschicht und bleibt für die Clients transparent. Sie stellt alle von der Anwendung benötigten Objekte bereit. Ohne diese Schicht können das Service-Locator-Antimuster oder starke Abhängigkeiten entstehen; Validierbarkeit und Testbarkeit sind dann eingeschränkt.

Die Präsentationsschicht stellt die von der Software verarbeiteten Daten und angebotenen Funktionen dar und nimmt Eingaben entgegen. In verteilten Systemen kann ein Webbrowser als Thin Client verwendet werden. Inhalte und Formulare werden dann etwa mit XHTML, XML oder JavaScript dargestellt; die Verbindung zu tieferen Schichten erfolgt normalerweise über HTTP. Eine Alternative ist eine eigene grafische Oberfläche als Fat Client, beispielsweise mit Flash, Java Swing oder XAML. Sie kann über SOAP, Java RMI oder Microsoft .NET Remoting mit der Anwendungsschicht kommunizieren.

Die Steuerungsschicht koordiniert mehrere fachlich getrennte Teile der Geschäftslogik. In einer serviceorientierten Architektur findet dort beispielsweise die Orchestrierung statt, also die Abstimmung verschiedener Dienste. Häufig verantwortet diese Schicht auch die Transaktionssteuerung.

Die Geschäftslogikschicht, auch Verarbeitungs-, Anwendungslogik- oder Domänenschicht genannt, setzt das eigentliche Geschäftsmodell um. Dazu implementiert sie die beteiligten Geschäftsobjekte und die zugehörige Logik.

Datenzugriff und weitere Modelle

Die Datenzugriffsschicht kapselt sowohl den Zugriff auf persistente, also dauerhaft gespeicherte Daten, als auch die dabei eingesetzten Techniken. Meist werden Datenbanken verwendet; in anderen Systemen können normale Dateien zur Speicherung dienen.

Beim Einsatz einer Datenbank erfolgt der Austausch mit der Datenhaltungsschicht über Datenbankschnittstellen oder durch direkten Zugriff auf das DBMS, das Datenbankmanagementsystem, beispielsweise bei PHP. Werden objektorientierte Programme mit einem relationalen DBMS verbunden, ist eine objektrelationale Abbildung erforderlich. Dieses Object-Relational Mapping, kurz ORM, überführt Objekte in relationale Datenstrukturen und umgekehrt. Häufig übernimmt ein ORM-Framework diese Aufgabe.

Ein Schichtenmodell mit sieben Schichten ist das ISO/OSI-Modell. Es beschreibt die Aufteilung eines Netzwerk-Stacks und nicht die innere Aufteilung einer Anwendung.

Betriebssysteme und Nachverfolgung

Auch Betriebssysteme können nach einem Schichtenmodell aufgebaut sein, das dort ebenfalls Schalenmodell heißt. Es gehört neben dem monolithischen Kernel und dem Microkernel zu den drei wesentlichen Architekturmodellen von Betriebssystemen. Die Komponenten liegen wie Schalen übereinander.

Die Übergänge bestehen aus klar definierten Schnittstellen. Schichten dürfen nicht übersprungen werden: Ein Anwendungsprogramm kann beispielsweise nicht direkt auf eine Datenstruktur zugreifen, sondern muss über die Schnittstellen aller Zwischenschichten kommunizieren. Je näher eine Schicht an der Hardware liegt, desto stärker sind normalerweise ihre Schreib- und Leseberechtigungen. Der Übergang zwischen Kernel-Mode und User-Mode kann allerdings schwer abzugrenzen sein.

In komplexen Systemen wird außerdem die Ende-zu-Ende-Verfolgung der Kommunikation zwischen den Schichten wichtiger. Sie kann mit dem Application Response Measurement Standard umgesetzt werden, indem die Transaktionen der einzelnen Schichten miteinander korreliert, also zusammengehörig gekennzeichnet und verfolgt werden.