Mehrschichtige Anwendungen - MT AG
Mehrschichtige Anwendungen - MT AG
Mehrschichtige Anwendungen - MT AG
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
nannt, was die Anwendung letztendlich ausmacht:<br />
die Geschäftslogik.<br />
❚ Ressourcen: <strong>Anwendungen</strong> arbeiten immer mit<br />
Daten. Diese kommen zum Beispiel aus Tabellen<br />
oder Streams und lagern in Datenbanken,<br />
Dateien oder werden von Diensten übermittelt.<br />
Diese ausgelagerten Entitäten können unter<br />
dem Begriff „Ressourcen“ zusammengefasst<br />
werden – weshalb eine Datenzugriffsschicht<br />
auch schon mal als Ressourcenzugriffsschicht<br />
bezeichnet wird.<br />
❚ Facade: Nicht alle <strong>Anwendungen</strong> haben eine<br />
grafische Benutzeroberfläche. Aber wenn es<br />
auch keine sichtbare Schnittstelle gibt, so vielleicht<br />
eine „unsichtbare“ in Form von Interfaces<br />
oder Webservices. Alles, was also „von<br />
außen“ nutzbar gemacht wird, ist in diesem<br />
Begriff zusammengefasst.<br />
❚ Infrastruktur: Ein stark unterschätztes Thema im<br />
Software Engineering ist die Frage: „Ey, wo<br />
laufen sie denn?“ Damit sind nicht die Endbenutzer<br />
gemeint, sondern vielmehr die (Hardware-)Umgebung,<br />
in die eine Anwendung<br />
letztendlich verteilt (engl. deployed) wird.<br />
Behält man diese Gemeinsamkeiten im Hinterkopf,<br />
ist es durchaus möglich, einen wenn auch<br />
nicht optimalen, so doch allgemein anwendbaren<br />
Architekturansatz zu formulieren, und<br />
zwar so, wie dies bereits vielfach geschehen ist.<br />
Bild 3 zeigt eine Übersicht über mehrschichtige<br />
Architekturen (vergleiche Textkasten „Architekturbegriff“).<br />
Wie finde ich zur richtigen Architektur?<br />
Zu einem bestimmten Zeitpunkt in einem Softwareprojekt<br />
ist das Design der Anwendung zu<br />
erstellen. Was zunächst als Vision entsteht und<br />
dann in ein konzeptionelles Design mündet,<br />
muss später als Modell für die Entwicklung dienen.<br />
Dazu ist es erforderlich, alle Dienste zu kennen<br />
und zu verstehen, die die Software bieten<br />
soll. In diesem Kontext ist das Wort „Dienst“<br />
eher im Sinne von Leistungsmerkmal zu verstehen.<br />
So wird ein Dienst hier definiert als ein<br />
Stück Anwendungslogik. Um diese Sichtweise<br />
zu verdeutlichen, sind hier zunächst einige<br />
Gruppen von Diensten aufgelistet, die eine Anwendung<br />
in der Regel vorzuweisen hat:<br />
❚ Data Services: Beim Zugriff auf oder bei der Arbeit<br />
mit Daten kommen Datendienste zum Einsatz.<br />
Dies sind Teile der Anwendungslogik, die<br />
direkt Daten verwalten.<br />
❚ Business Services: Eine Anwendung implementiert<br />
in der Geschäftslogik sogenannte Business<br />
Rules. Ein Businessdienst kapselt diese Logik<br />
sowohl für die darüber als auch für die darunter<br />
liegenden Dienste beziehungsweise Layer.<br />
❚ User Services: Per User Service wird einem Endbenutzer<br />
die grafische Oberfläche zur Verfü-<br />
6/2009 www.databasepro.de<br />
gung gestellt. Und damit wird auch gleichzeitig<br />
die Logik bereitgestellt, die zur Interaktion<br />
zwischen Anwendung und Benutzer gebraucht<br />
wird.<br />
❚ System Services: Systemdienste sind Teile der<br />
Anwendung, die nicht-funktionale Anforderungen<br />
erfüllen. Hierzu können Backup, Fehlerbehandlung<br />
und Sicherheit gehören.<br />
Dienste sind in aller Regel recht einfach. Nehmen<br />
wir zum Beispiel an, ein Datendienst einer<br />
Windows-Anwendung soll die Funktionalität<br />
bieten, einen neuen Kunden inklusive Lieferund<br />
Rechnungsadresse in einer Datenbank zu<br />
speichern. Grundsätzlich ist dies leicht zu lösen.<br />
Wird diese Anforderung jedoch im Kontext eines<br />
mobilen (Web-)Szenarios betrachtet, dann<br />
wird es schon schwieriger. Die Ursache hierfür<br />
ist eigentlich nicht der Dienst selbst, sondern<br />
„das Drumherum“. Die Anforderung an den<br />
Datendienst ist nach wie vor dieselbe (einen<br />
Kunden speichern), doch die Umgebung erschwert<br />
plötzlich die Aufgabe. Um diese lösen<br />
zu können, wäre ein möglicher Ansatz, einen<br />
weiteren Layer einzuführen, der zum Beispiel<br />
Transaktionen übers Web handhabt.<br />
Es lässt sich darüber streiten, ob ein solcher<br />
„Wrapper“ in die Rubrik Systemdienst oder Datendienst<br />
einzuordnen ist. Aus Sicht des Autors<br />
gehört er eher in die letztgenannte Gruppe. Dies<br />
führt zu folgender Frage: Egal wie ich meine Anwendung<br />
betrachte, ändert sich dadurch die<br />
grundlegende Architektur? Hier ein weiteres<br />
Beispiel: Bild 4 zeigt die Illustration einer Anwendung<br />
bestehend aus Presentation, Business<br />
und Data Services beziehungsweise Layers. Wie<br />
die Abbildung darüber hinaus andeutet,<br />
TECHNOLOGIEN Architektur<br />
▲<br />
Layer vs. Tier<br />
Aus dem Englischen ins Deutsche<br />
übersetzt bedeuten beide<br />
Begriffe „Schicht“ (im Sinne von<br />
Ebene). Umgekehrt wird „mehrschichtig“<br />
mit „multilayer“ übersetzt,<br />
und der Begriff „Tier“ wird<br />
im deutschen Sprachgebrauch<br />
ebenfalls verwendet.<br />
Architekturbegriff<br />
Layer und<br />
Komponenten<br />
(Bild 2)<br />
In der Informationstechnik (IT)<br />
wird der Begriff Architektur in<br />
verschiedenen Zusammenhängen<br />
benutzt. Es gibt Architektur<br />
in und für Prozessoren, Rechner,<br />
Netzwerke und in Computerprogrammen.<br />
Ganz allgemein beschreibt<br />
der Terminus das Zusammenspiel<br />
von Komponenten<br />
in einem (mehr oder weniger)<br />
komplexen System.<br />
77<br />
TECHNOLOGIEN