Schichtenarchitektur
Die Schichtenarchitektur (auch Schichtenmodell oder Schichtenmuster) ist ein häufig angewandtes Strukturierungsprinzip für die Architektur von Softwaresystemen. Dabei werden einzelne Aspekte des Softwaresystems konzeptionell einer Schicht (engl. tier oder layer) zugeordnet. Die erlaubten Abhängigkeitsbeziehungen zwischen den Aspekten werden bei einer Schichtenarchitektur dahingehend eingeschränkt, dass Aspekte einer höheren Schicht nur solche tieferer Schichten verwenden dürfen. Ein System mit Schichtenarchitektur bezeichnet man auch als „mehrschichtig“.
Die den Schichten zugeordneten Aspekte können dabei je nach Art des Systems oder Detaillierungsgrad der Betrachtung z. B. Funktionalitäten, Komponenten oder Klassen sein.
Klassifikationen
Man unterscheidet verschiedene Arten eine Schichtenarchitektur zu designen:
- Bei einer strengen bzw. geschlossenen Schichtenarchitektur (engl. strict layering, closed architecture) dürfen keine Schichten übersprungen werden und nur die nächstniedrigere Schicht aufgerufen werden. Auf diese Weise wird eine hohe Flexibilität gewährleistet, da bei der Veränderung einer Schicht im schlimmsten Fall anliegende Schichten angepasst werden müssen (nicht jedoch das ganze System), die einzelnen Schichten sind somit auch leichter test- und wartbar. Man spricht von direkter Adressierung.[1]
- Bei einer nicht-strengen bzw. offenen Schichtenarchitektur (loose layering, open architecture) darf eine Schicht jede beliebige untere Schicht aufrufen. Ein Vorteil ist, dass offene Systeme oft performanter sind als geschlossene, da die Daten nicht erst durch dazwischenliegende Schichten hindurchgeschleust werden müssen. Dies führt dann jedoch zu einem höheren Grad der Kopplung der Schichten im Gegensatz zu der i. d. R. gewünschten nur lockeren Kopplung (engl. loose layering). Diese Art der Adressierung nennt man auch indirekte Adressierung.[2]
- Es gibt auch Systeme, in denen die einzelnen Schichten mit der darüber- und der darunterliegenden Schicht kommunizieren. Das bekannteste Beispiel hierfür ist das ISO/OSI-Modell.
Oftmals werden Schichtenarchitekturen nach der Anzahl der verwendeten Schichten unterteilt. Bei Anwendungssystemen sind dabei verschiedene anwendungsfallabhängige Schichtenarchitekturen gebräuchlich.
Vor- und Nachteile
Durch eine Schichtenarchitektur wird die Komplexität der Abhängigkeiten innerhalb des Systems reduziert und somit eine geringere Kopplung bei gleichzeitig höherer Kohäsion der einzelnen Schichten erreicht. Insbesondere werden dadurch Zyklen im Abhängigkeitsgrafen vermieden. Dies hat Vorteile, sowohl für das Verständnis als auch für die Wartung des Systems. Außerdem sind einzelne Schichten gut austauschbar, ohne das ganze System verändern zu müssen.
Ein Nachteil eines Schichtenmodells kann sein, dass die Ausführungsgeschwindigkeit der Applikation durch den zur Weiterleitung und Transformation von Daten über eine Schicht geschriebenen Codes reduziert wird. Dies ist insbesondere bei den Teilen der Applikation merklich der Fall, für die die Daten in tieferliegenden Schichten strukturell besser geeignet wären als in den Schichten, auf die sie zugreifen dürfen. Prominentes Beispiel dafür sind Reports, die Aggregate von Daten wie Summen oder Durchschnittswerte darstellen. In diesen Fällen wird oft bei den genannten Applikationsteilen zu Gunsten der Ausführungsgeschwindigkeit auf die Vorteile der Schichtenarchitektur verzichtet.
Schichtenarchitekturen nach Anzahl der Schichten
Zwei-Schichten-Architektur
Die zweischichtige Architektur (englisch two tier architecture) besteht aus zwei Schichten. Da nur die höhere auf die niedrigere Schicht zugreifen darf, ist die niedrigere Schicht ein Dienstanbieter (englisch Server) der höheren. Man spricht daher auch oft von einer Client-Server-Architektur.
Client-Server-Architekturen müssen nicht unbedingt mittels unterschiedlicher Rechner realisiert sein, vielmehr kann der Client auch als ein Software-Modul verstanden werden, das auf ein zweites Software-Modul auf demselben Rechner, meist innerhalb derselben Anwendung zugreift. Das in der Abbildung gegebene Beispiel greift jedoch auf eine rechnerseitige Client-Server-Architektur zurück.
Bei Architekturen wie in der Abbildung gegeben, wird die Rechenkapazität weitestgehend auf die Client-Rechner ausgelagert, um den Server zu entlasten. Traditionell kommt ein Fat Client und ein Fat Server zum Einsatz. Auf dem Server läuft eine Datenbankanwendung. Die Clients übernehmen dabei die Logik und die Darstellung der Benutzerschnittstelle.
Drei-Schichten-Architektur
Die dreischichtige Architektur (englisch three tier architecture) ist eine Architektur, die softwareseitig drei Schichten hat. Im Gegensatz zur zweischichtigen Architektur gibt es bei der dreischichtigen Architektur noch eine zusätzliche Schicht, oftmals die Logikschicht, welche die Datenverarbeitung vornimmt.
Eine typische Drei-Schichten-Architektur besteht aus den folgenden Schichten:
- Präsentationsschicht (client tier) – Diese, auch Front-End bezeichnet, ist für die Repräsentation der Daten, Benutzereingaben und die Benutzerschnittstelle verantwortlich.
- Logikschicht (application-server tier, Businessschicht, Middle Tier oder Enterprise Tier) – Sie beinhaltet alle Verarbeitungsmechanismen. Hier ist die Anwendungslogik vereint.
- Datenhaltungsschicht (data-server tier, back end) – Sie enthält die Datenbank und ist verantwortlich für das Speichern und Laden von Daten.
Drei-Schichten-Architekturen bei verteilten Systemen
Mehrschichtige Systemarchitekturen wie die dreischichtige Architektur sind gut skalierbar, da die einzelnen Schichten logisch voneinander getrennt sind. So kann z. B. bei verteilten Systemarchitekturen die Datenschicht auf einem zentralen Datenbank-Server laufen, die Logikschicht auf Workgroup-Servern, und die Präsentationsschicht befindet sich auf der jeweiligen Workstation des Benutzers. Ein Beispiel für eine verteilte Drei-Schichten-Architektur ist Citrix: Interaktion: Client; Funktion: Citrix Server; Daten: Datenbankserver.
Wie die Grafik zeigt, gibt es zwischen Client und Server verschiedene Möglichkeiten zur Verteilung der Schichten. Grundsätzlich gilt: Je höher (näher an der Präsentationsschicht) die Schicht ist, desto eher wird sie von einem Client bearbeitet. Je tiefer (näher an der Datenschicht) die Schicht ist, desto eher ist sie Aufgabe eines Servers.
Drei-Schichten-Architekturen innerhalb von Software-Systemen
Die Architektur lässt sich auch innerhalb eines Software-Systems umsetzen, indem die Software-Module, welche für Präsentation, Anwendungslogik und persistente Speicherung von Daten zuständig sind, den einzelnen Schichten zugeordnet werden und gemäß der Schichteneinteilung voneinander entkoppelt werden. Neben einer Strukturierung gemäß dem Model-View-Controller-Architekturmuster gilt eine solche Drei-Schichten-Architektur üblicherweise als das Mindestmaß architektonischer Strukturierung, sofern keine zwingenden Gründe für andere Architekturentscheidungen vorliegen.
Weitere Schichten
Neben den oben genannten Schichten werden in verschiedenen Quellen andere Aufteilungen herangezogen. Grundsätzlich bezeichnet eine Schichtenarchitektur ein Architekturmuster, das hinsichtlich der Art und Anzahl seiner Schichten nicht beschränkt ist. Sehr häufig finden sich in Software-Systemen wie auch bei verteilten Anwendungen die folgenden Schichten:
- Anwendung
- Anwendungen werden weiter unterteilt in:
- Dependency Injection
- Anwendungspräsentation
- Geschäftslogik
- Datenzugriff
- Steuerung
- Datenpräsentation
- Datenhaltung
Weitere Details zu den einzelnen Schichten werden im Abschnitt Klassische Schichten innerhalb einer mehrschichtigen Architektur beschrieben.
Ein Beispiel für eine Architektur mit sieben Schichten bietet das ISO/OSI-Modell, das in der Abbildung rechts dargestellt ist. Das OSI-Modell beschreibt hierbei die Aufteilung des Netzwerk-Stacks, jedoch nicht die Aufteilung innerhalb einer Anwendung.
Klassische Schichten innerhalb einer mehrschichtigen Architektur
Dependency Injection
Die Dependency-Injection-Schicht ist die oberste Schicht in Anwendungen. Sie ist dabei für die Clienten der Anwendung völlig transparent und dient dazu, alle von der Anwendung benötigten Objekte bereitzustellen. Anwendungen, welche auf eine DI-Schicht verzichten, weisen das Service-Locator-Antimuster oder gar starke Abhängigkeiten auf und bieten nur eine eingeschränkte Validier- und Testbarkeit.[3]
Präsentationsschicht
Die Präsentationsschicht (engl. client layer oder presentation layer) ist für die Darstellung und Entgegennahme von der Software bearbeiteten Daten, sowie der von der Software bereitgestellten Funktionen verantwortlich.
Bei verteilten Systemen existieren für die Darstellung der Inhalte zwei Alternativen:
- Man setzt auf den Webbrowser als Thin Client und stellt die Inhalte und Formulare in XHTML, XML, JavaScript und anderen für das World Wide Web geschaffenen Sprachen dar, nutzt also eine klassische „Webanwendung“. Die Kommunikation mit tieferen Schichten erfolgt normalerweise über HTTP.
- Man produziert eine eigene grafische Benutzeroberfläche als Fat-Client. Dieser nutzt die erweiterten Darstellungsmöglichkeiten der dafür verwendeten Programmiersprache bzw. Grafikbibliothek wie Flash, Java Swing oder XAML. Dieser kommuniziert mit der Anwendungsschicht über Netzwerkprotokolle wie SOAP, Java RMI oder Microsoft .NET Remoting.
Steuerungsschicht
Die Steuerungsschicht (engl. process layer) dient der Koordination mehrerer fachlich abgegrenzter Teile der Geschäftslogikschicht.
Zum Beispiel bei einer serviceorientierten Architektur erfolgt hier die Orchestrierung. In der Steuerungsschicht liegt häufig auch die Verantwortung für die Transaktionssteuerung.
Geschäftslogikschicht
Die Geschäftslogikschicht (auch Verarbeitungsschicht, Anwendungslogikschicht, Domänenschicht, application layer oder middle tier) realisiert das eigentliche Geschäftsmodell, indem die am Geschäftsmodell beteiligten Geschäftsobjekte mit der zugehörigen Logik implementiert werden.
Datenzugriffsschicht
Die Datenzugriffsschicht kapselt den Zugriff auf persistente Daten und die dabei verwendeten Techniken.
Für die persistente Speicherung werden häufig Datenbanken eingesetzt, bei anderen Systemen können aber auch normale Dateien verwendet werden.
Beim Einsatz von Datenbanken werden für den Datenaustausch mit der Datenhaltungsschicht Datenbankschnittstellen sowie alternativ der direkte Zugriff auf das DBMS (Datenbank Management System) verwendet (z. B. bei PHP). Bei Verwendung von objektorientierter Programmierung im Zusammenspiel mit einem relationalen DBMS wird in der Datenzugriffsschicht eine objektrelationale Abbildung (object-relational mapping, ORM) benötigt, die oft durch den Einsatz eines ORM-Frameworks umgesetzt wird.
Weitere Anwendungen von Schichtenarchitekturen
Schichtenmodell bei Betriebssystemen
Ein Schichtenmodell, auch Schalenmodell genannt, ist eines von drei wesentlichen Architekturmodellen von Betriebssystemen. Neben dem monolithischen Kernel und dem Microkernel gibt es das Schichtenmodell. Bei dem Schichtenmodell sind die verschiedenen Betriebssystemkomponenten wie Schalen aufeinander aufgebaut. Dies ist auch in der nebenstehenden Abbildung zu sehen.
Die Übergänge zwischen den Schichten werden von Schnittstellen gebildet, wobei die Übergänge sauber sein müssen, es gibt keine Sprünge (z. B. von einem Anwendungsprogramm direkt in die Datenstruktur). Die Kommunikation erfolgt über die Schnittstellen jeder einzelnen Zwischenschicht.
Allgemein kann man sagen, je näher eine Schicht an der Hardware, desto privilegierter ist diese bezüglich Schreib- und Leseberechtigungen. Der Übergang vom Kernel-Mode zum User-Mode kann unter Umständen schwer abzugrenzen sein.
- Siehe auch: Ring (CPU)
Nachvollziehbarkeit
Eine Ende-zu-Ende Verfolgung der Kommunikation zwischen den einzelnen Schichten wird in komplexen Systemen immer bedeutsamer und kann durch den Application Response Measurement Standard mittels korrelierten Transaktionen einer jeden Schicht implementiert werden.
Siehe auch
Weblinks
Einzelnachweise
- Frank Buschmann et al.: Pattern-Oriented Software Architecture: A System of Patterns, John Wiley & Sons, 1996.
- Frank Buschmann et al.: Pattern-Oriented Software Architecture: A System of Patterns, John Wiley & Sons, 1996.
- Daniel Baharestani: Mastering Ninject for Dependency Injection. Packt Publishing, ISBN 978-1-78216-620-7 (englisch, 142 S.).