Technische Universität Dresden

Transkript

1 Technische Universität Dresden Fakultät Informatik Lehrstuhl Rechnernetze Diplomarbeit Architektur und Design einer Webanwendung für die Finanzbuchhaltungssoftware MoRIS mit Bereitstellung eines Prototypen Vorgelegt von: Martina Burghagen Betreuender Hochschullehrer: Prof. Dr. habil. A. Schill Betreuer: Dr.rer.nat. D. Gütter Erstellt bei: Systema Systementwicklung GmbH Betreuer im Unternehmen: Dipl.-Inf. M. Ertelt Bearbeitungszeit: 01. Dezember 2006 bis 31. Mai 2007

2 Danksagung Ich bedanke mich für die Unterstützung bei Roland, meiner Familie und Rachel. Ferner danke ich der Firma Systema Systementwicklung für die Betreuung meiner Diplomarbeit. ii

3 Inhaltsverzeichnis 1 Einleitung 1 2 Anforderungen Sicherheit der Anwendung Sichere Datenübertragung Maßnahmen für die Erweiterbarkeit und Wartbarkeit der Anwendung Entwurfsmuster für Webanwendungen Wiederverwendung Client-Server-Architekturen Client-Server-Architekturen und ihre Klassifikationen Die 2-Tier-Architektur Die 3-Tier-Architektur Tier- und N-Tier-Architekturen Client-Server-Architekturen und ihre Technologien Vergleich von Technologien Clientseitige Technologien Serverseitige Technologien Vergleich ausgewählter Technologien ASP.NET Java PHP PERL Gegenüberstellung Ajax Die Entwicklung des Prototyps Die Ausgangssituation Die Bewertung der MoRIS-Architektur iii

4 INHALTSVERZEICHNIS 5.3 Die Anforderungen Alternative Realisierungen Die Entwurfsentscheidungen Der Entwurf Implementierung Der Webclient Die Bibliotheken SSL Caching Der Test Erweiterungen und Optimierung Mögliche Weiterentwicklung von MoRIS Die serviceorientierte Architektur Mashups Software-As-A-Service Multi-Tenant-Architektur Zusammenfassung 79 8 Fazit und Ausblick 81 A Verzeichnisse 83 Literaturverzeichnis Abbildungsverzeichnis Tabellenverzeichnis B CD 90 iv

5 Kapitel 1 Einleitung Das Internet hat in den letzten Jahren kontinuierlich an Bedeutung gewonnen. Stetig wachsende Nutzerzahlen weltweit haben zu einer rasanten Entwicklung der Internettechnologien geführt. Innerhalb von ein paar Jahren wurden schlichte HTML-Seiten durch komplexe Webanwendungen ersetzt. Die Möglichkeiten sind beinahe unbegrenzt: online-banking, online-shopping, online telefonieren, um nur ein paar zu nennen. Eine solche Entwicklung kann viele Vorteile bieten: In vielen Bereichen können Kosten durch Onlinevermarktung eingespart werden. Neue Geschäftsfelder werden erschlossen und unternehmensspezifische Prozesse können vereinfacht und beschleunigt werden. Bei einer Webanwendung muss Software nicht lokal installiert werden, wodurch sie plattformunabhängig wird, da der Zugriff über den Browser stattfindet. Die Wartung und die Aktualisierung von Daten kann zentral durchgeführt werden. Durch die zentrale Administration ist es einfacher Daten konsistent zu halten und zuverlässige Backups zu erstellen. Es können Datenbanken, Legacy- 1, und andere Systeme eingebunden werden. 1 Legacy-Systeme sind ältere und etablierte Softwaresysteme, die durch langjährigen Einsatz in einem Unternehmen gewachsen sind. Sie werden meistens beibehalten um Ausfallrisiken und Umstellungskosten zu vermeiden. 1

6 Die Liste der Vorteile ist beachtlich und kann noch weiter geführt werden. Trotzdem gibt es auch Nachteile. Die Performance der Anwendung kann sich verschlechtern, da mehr Hintergrundprozesse arbeiten, die eine Laufzeitverlängerung bewirken können. Eine Nutzung der Anwendung ohne Internetverbindung ist nicht mehr möglich. Unterschiedliche Browser können, abhängig von den verwendeten Technologien, in der Darstellung und im Verhalten variieren. Durch die verteilte Architektur der Anwendung steigen die Sicherheitsrisiken. Um eine geeignete Architektur und die dazugehörenden Technologien für eine Webanwendungen bestimmen zu können, müssen die Anforderungen herausgearbeitet und Vergleiche durchgeführt werden. Diese Arbeit hat das Ziel verschiedene Realisierungsmöglichkeiten zu diskutieren. Das nächste Kapitel beschäftigt sich mit den Anforderungen an eine Webanwendung. Dazu gehören in erster Linie Anforderungen an die Sicherheit. Gerade wenn private Daten über das Internet übertragen werden ist es wichtig, dass entsprechende Schutzmaßnahmen ergriffen werden. Dabei geht es darum, die Gefahren zu analysieren und die Schutzmaßnahmen zu bestimmen. Weitere Anforderungen sind die Wartbarkeit und Erweiterbarkeit. Um diesen Anforderungen gerecht zu werden spielt der Entwurf der Anwendung eine wichtige Rolle. Das dritte Kapitel stellt sich mit Client-Server-Architekturen vor. Für die Realisierung einer Webanwendung können verschiedene Verteilungsmodelle gewählt werden. Zusätzlich werden die einzelnen Technologien vorgestellt, die in diesem Bereich ihren Einsatz finden. Das darauf folgenden Kapitel diskutiert die einzelnen Technologien. Die clientseitigen und die serverseitigen Technologien werden miteinander verglichen, um entsprechend den Anforderungen, die geeignetste Technologie auswählen zu können. 2

7 Das fünfte Kapitel stellt den, im Rahmen dieser Arbeit, entwickelten Prototypen vor. Dabei soll zuerst die aktuelle Architektur der Anwendung, wie sie momentan in der Firma Systema GmbH vorliegt, analysiert und kritisch bewertet werden. Nachdem die Anforderungen an den Prototyp kurz skizziert wurden, wird der Entwurf dargestellt, der die Entscheidungen in der Umsetzung aufzeigt. Zusätzlich werden noch die Implementierung und der Test erläutert. Am Ende werden Optimierungsmöglichkeiten und Erweiterungen angesprochen. Das letzte Kapitel diskutiert die Weiterentwicklung von Moris. Dabei werden verschiedene Konzepte vorgeschlagen. Dazu gehören zum einen, Möglichkeiten der Umstrukturierung der Architektur und zum anderen Möglichkeiten für den Vertrieb der Software. 3

8 Kapitel 2 Anforderungen Es ist schwierig genau zu bestimmen, welche Anforderungen eine gute Software erfüllen muss. Zumindest aber sollte sie den Kunden zufrieden stellen und fehlerfrei sein. Um eine fehlerfreie Software zu produzieren spielen Softwaretests eine große Rolle und in der Regel nehmen sie eine große Zeitspanne in der Projektplanung in Anspruch (siehe Abschnitt 5.7.5). Die Tests werden jedoch nach der Entwicklung durchgeführt. Bereits während der Entwicklung müssen Maßnahmen für die Erweiterbarkeit und Wartbarkeit der Anwendung getroffen werden. Für Webanwendungen kommen als weitere Fehlerquelle Sicherheitslücken hinzu, die im Folgenden näher erläutert werden. 2.1 Sicherheit der Anwendung Es gibt viele verschiedene Angriffsmethoden bei Webanwendungen. Um sich effektiv gegen Angriffe zu schützen müssen die Angriffe analysiert und deren Zweck bestimmt werden. Auf dieser Basis können Schutzmaßnahmen, mit denen das Risiko eines Angriffs reduziert werden kann, erarbeitet werden. Microsoft hat eine Klassifizierung für die Sicherheit von Webanwendungen, namens STRIDE entwickelt (vgl. [JM03]). STRIDE ist ein Acronym von Microsoft und steht für: Spoofing, Tampering, Repudiation, Information Disclosure, Denial-of-Service, Elevation of Privilege. Spoofing (Verschleierung): Bei dieser Bedrohung täuscht der Angreifer eine falsche Identität vor. Dadurch kann er unerlaubt Zugriff zum System erlangen. Hat der Angreifer erst einmal 4

9 2.1 Sicherheit der Anwendung Zugriff zum System erhalten, kann er weitere Angriffe starten. Auf Netzwerkebene funktioniert das Spoofing, in dem der Angreifer seine Pakete mit einer falschen Quelladresse versieht. Als Gegenmaßnahme kann ein Filter eingebaut werden, der eingehende und ausgehende Pakete filtert und damit Pakete, die erkennbar manipuliert wurden, blockiert. Tampering (Verfälschung): Beim Tampering verändert der Angreifer unerlaubt Daten. Einem solchen Angriff kann durch Daten-Hashing und -Signaturen begegnet werden, die dafür sorgen, dass unbefugt veränderte Daten schnell erkannt werden. Eine sichere Autorisierung und eine sichere Verbindung mit fälschungssicheren Protokollen gewährleisten den Schutz von Anmeldedaten. Repudiation: (Ablehnung) Bei dieser Bedrohung leugnet der Angreifer das Durchführen einer Aktion. Hier helfen sichere Überwachungslisten und digitale Signaturen, denn sie sind eindeutige Beweise für das Durchführen einer Aktion. Information Disclosure (Aufdeckung von Informationen): Bei dieser Bedrohung gelangt der Angreifer an Informationen für deren Einsicht er keine Berechtigung besitzt. Ein Angriff wird durch das Abfangen von Datenpaketen zwischen Client und Server oder durch das Scannen von Netzwerkgeräten, die dem Angreifer Aufschluss über Systemeigenschaften geben können, möglich. Mit einer geeigneten Systemkonfiguration kann ein solcher Angriff verhindert werden. Alle Protokolle, die nicht benötigt werden, sollten deaktiviert sein und eine Firewall sollte nicht benötigte Ports sperren. Denial-of-Service (Dienstversagen): Bei dieser Bedrohung sorgt der Angreifer dafür, dass eine Anwendung oder ein System nicht mehr verfügbar ist. Dabei wird die Anwendung mit so vielen Anforderungen konfrontiert, dass eine Überlastung eintritt. Das führt dazu, dass die Anwendung keine regulären Anfragen mehr entgegen nehmen kann. Um die Gefahr von Denial-of-Service-Angriffen zu verringern kann ein Netzwerksystem zur Erkennung von Eindringversuchen verwenden werden. Gleichzeitig sollten Techniken verwendet werden, die Ressourcen und Bandbreite schonen. Elevation of Privilege (Erhebung der Rechte): Bei dieser Bedrohung nimmt der Angreifer eine Identität an, mit der er mehr Rechte auf dem System besitzt als mit der eigenen. Um das Risiko eines solchen Angriffs zu reduzieren, sollten alle Konten mit so wenig Rechten wie möglich 5

10 2.1 Sicherheit der Anwendung ausgestattet werden. Es gibt unzählige verschiedene Arten von Angriffen. Nicht jeder Angriff kann genau einer Bedrohung zugeordnet werden. Oft ist ein Angriff Vorbereitung für den Nächsten. Angriffe können sich jedoch gegen verschiedene Bereiche richten, gegen das Netzwerk, gegen den Host, das heißt gegen die Systemsoftware, auf der die Anwendung läuft oder gegen die Anwendung selbst.[ss06] Netzwerkebene: Beim Sniffing überwacht der Angreifer den Datenverkehr im Netzwerk, um an unverschlüsselte Daten oder Konfigurationsinformationen zu gelangen. Gegenmaßnahme: Datenverschlüsselung Bei Sitzungsübernahme auch Man-in-the-Middle-Angriff genannt schaltet sich der Angreifer in die Server-Client-Kommuniaktion ein. Dadurch kann er Nachrichten abfangen oder manipulieren. Gegenmaßnahme: Datenverschlüsselung Hostebene: Computerviren, Trojanische Pferde und Computerwürmer. Gegenmaßnahme: Virenscanner Netzwerkgeräte können einem Angreifer Aufschluss über Systemeigenschaften geben. Diese Vorgehensweise nennt sich Footprinting. Ein Beispiel sind Port-Scans. Hier sucht der Angreifer nach offenen Ports bei einem Router. Über die offenen Ports können weitere Angriffe gestartet werden. Gegenmaßnahme: Alle nicht benötigten Ports sperren. Anwendungsebene: Eine SQL-Injektion kann dann stattfinden, wenn aus einer Benutzerangabe eine SQL-Abfrage generiert wird, die dann ohne entsprechende Prüfung ausgeführt wird. Auf diese Weise kann ein Angreifer SQL-Abfragen einschleusen, die dann ungewollt von der Anwendung ausgeführt werden. Gegenmaßnahmen: Überprüfung der Nutzereingaben. Ein Pufferüberlauf kann dann stattfinden wenn die Anwendung auf eine Benutzereingabe wartet. Wenn die Eingabe vom Benutzer größer ist als der 6

11 2.2 Sichere Datenübertragung reservierte Speicherplatz des Puffers dann läuft der Puffer über. Dadurch können unter Umständen Befehle eingeschleust und Anwendungsdaten beschädigt werden. Gegenmaßnahmen: Überprüfung der Nutzereingaben. 2.2 Sichere Datenübertragung Daten müssen während der Übertragung im Internet geschützt werden. Das wird durch die Verschlüsselung der Daten erreicht. Das am weitesten verbreitete Protokoll ist SSL, die Secure Socket Layer. Die Erweiterung von SSL nennt sich TLS, Transport Layer Security. SSL arbeitet oberhalb der Transportschicht 2. Da SSL unabhängig von den darüber liegenden Protokollen ist, kann es flexibel eingesetzt werden, zum Beispiel in Verbindung mit HTTP, FTP und SMTP. Eine Alternative zu SSL ist SHTTP, ein sicheres Nachrichten-orientiertes Kommunikationsprotokoll, welches HTTP um kryptographische Funktionen erweitert. Jede Nachricht kann durch digitale Unterschriften, Datenverschlüsselung und Authentifizierung geschützt werden. Im Weiteren können die einzelnen Mechanismen beliebig kombiniert werden. Im Gegensatz zu SSL ist SHTTP auf der Anwendungsebene angesiedelt. Dadurch ist es weniger flexibel als SSL. SSL kapselt alle Sicherheitsdienste in der Transportschicht. Da es eine sichere Verbindung aufbaut und nicht einzelne Nachrichten verschlüsselt ist es unabhängig und kann bei verschiedenen Anwendungen verwendet werden. Dadurch ist SSL in seinen Anwendungsmöglichkeiten sehr flexibel. SHTTP wiederum bietet die Möglichkeit mehr Einfluss auf die kryptographischen Mechanismen auszuüben. Obwohl beide Protokolle im Design und ihren Zielen sehr unterschiedlich sind und dadurch auch gleichzeitig verwendet werden können hat sich SSL gegenüber SHTTP durchgesetzt (siehe [Hei07] und [Lüp05]). 2 Die Transportschicht ist die vierte Schicht des Osi-Modells zur Datenübertragung. Sie bietet den anwendungsorienterten Schichten einen einheitlichen Zugriff, so dass diese nicht auf die Eigenschaften der Kommunikationsnetze eingehen müssen. 7

12 2.3 Maßnahmen für die Erweiterbarkeit und Wartbarkeit der Anwendung 2.3 Maßnahmen für die Erweiterbarkeit und Wartbarkeit der Anwendung Bei Softwareprojekten, die einen gewissen Umfang überschreiten, spielt die Strukturierung der Software eine wichtige Rolle. Diesen Vorgang können Entwurfsmuster unterstützen Entwurfsmuster für Webanwendungen Ein Muster beschreibt ein Problem das regelmäßig auftritt und bietet dazu eine Lösung an. Dadurch ist es möglich Erfahrungen in objektorientierter Softwareentwicklung festzuhalten und weiterzugeben. Der Einsatz von Entwurfsmustern bietet viele Vorteile. Durch die Abstraktion lassen sich Probleme und vor allem ihre Lösungen gut dokumentieren und vergleichen. Es ist leichter sich in eine bestehende Software einzuarbeiten, wenn Entwurfsmuster verwendet wurden, da die Muster schnell erkannt werden und der Programmierer dadurch die Zusammenhänge schneller erfasst. Entwurfsmuster können in drei Kategorien unterteilt werden. Erzeugungsmuster: Diese Entwurfsmuster erzeugen Objekte. Dabei wird die Objekterzeugung gekapselt und ausgelagert. Strukturmuster: Diese Entwurfsmuster beschreiben wie Gruppen von Objekten in größere Strukturen eingeordnet werden können. Hier kann nochmal zwischen Klassenmustern und Objektmustern unterschieden werden. Wobei die Klassenmuster mit Vererbung arbeiten, das heißt durch Vererbung zwischen den Klassen wird eine Struktur aufgebaut und Schnittstellen definiert. Objektmuster beschreiben wie Objekte zu großen Strukturen kombiniert und zusammengefasst werden können. Das kann zum einen durch Komposition realisiert werden zum anderen durch die Verschachtelung von Objekten. Verhaltensmuster: Diese Entwurfsmuster helfen dabei die Kommunikation und Interaktion zwischen Objekten oder Klassen zu definieren sowie den Kontrollfluß in komplexen Programmen zu bestimmen. 8

13 2.3 Maßnahmen für die Erweiterbarkeit und Wartbarkeit der Anwendung Es gibt noch andere Kategorien von Mustern, die jedoch nicht zu den Entwurfsmustern gezählt werden. Die Architekturmuster sind im Gegensatz zu den Entwurfsmustern allgemeiner, das bedeutet sie besitzen eine höheren Abstraktionsgrad. Der Grundaufbau der Anwendung wird in Form einer allgemeine Strukturierung beschrieben. Das Idiom wiederrum besitzt einen geringeren Abstraktionsgrad als das Entwurfsmuster. Idiome sind programmiersprachenspezifisch und beschreiben die Implementierung von speziellen Entwurfsaspekten. Zuletzt gibt es die Anti-Muster oder auch Negativmuster genannt. Sie geben darüber Aufschluss wie ein Problem nicht gelöst werden sollte. (vgl.[gol02] und [EG04]) Es gibt eine sehr große Anzahl von Mustern für die verschiedenartigsten Situationen. Im folgenden sollen ein paar Muster die speziell bei Webanwendungen ihren Einsatz finden vorgestellt werden Das Model-View-Control-Muster Abbildung 2.1: Das Model-View-Control-Muster Das Model-View-Control-Muster, kurz MVC ist ein Muster bei dem die Einordnung Schwierigkeiten bereitet. Da es sehr allgemein gehalten ist wird es von vielen Entwicklern bereits zu den Architekturmustern gezählt. Es wird meist bei komplexen Anwendungen verwendet, bei denen große Datenmengen verwaltet und auf verschiedene Art und Weise angezeigt werden. Das Ziel ist es, die Daten und ihre Präsentation zu trennen. Um diese Trennung zu gewährleisten gibt es die Steuerung, die zwischen beiden Bereichen vermittelt. Damit ergibt sich eine Dreiteilung. Das Datenmodell enthält die Daten, die Präsentation ist für die Beschaffung der Daten aus dem Datenmodell und ihre Darstellung verantwortlich 9

14 2.3 Maßnahmen für die Erweiterbarkeit und Wartbarkeit der Anwendung und die Steuerung reagiert auf Ereignisse, verwaltet Sichten und kann Änderungen im Datenmodell herbeiführen. Das Model-View-Control-Muster wird häufig für Webanwendungen verwendet, mit den HTML-Seiten als Präsentation, dem Anwendungscode als Steuerung und der Datenbank als Datenmodell. Datenmodell Präsentation Steuerung ASP.NET Data Set ASPX/ASCX Dateien Code-Behind-Classes Java Entity Beans Java Server Page Java Servlet Tabelle 2.1: Umsetzung des Model-View-Control-Muster in Java und ASP.NET Bei Java gibt es verschiede Möglichkeiten das MVC-Muster zu implementieren. Eine Variante wird mit Entity Beans, Java Server Pages und Java Servlets realisiert, wie in der Tabelle 2.1 angezeigt. Das Pendant dazu in ASP.NET sind das Data Set, die ASPX/ASCX Dateien und die Code-Behind-Klassen (siehe Abschnitt 5.7). Zur Unterstützung während der Entwicklung werden häufig MVC-Frameworks eingesetzt. Beispiele dafür sind Struts oder WebWork für Java und für ASP.NET das.net Framework. MVC-Frameworks gibt es jedoch auch für andere Sprachen. Für Scriptsprachen wie zum Beispiel Ruby, Phyton, Perl und PHP gibt es MVC-Frameworks die ähnliche Eigenschaften wie die Java Frameworks oder das.net Framework besitzen. Dazu gehören Nitro und Ruby on Rails für Ruby, Django und TurboGears für Phyton, Catalyst für Perl und CakePHP, Symfony und PHPOnTrax für PHP. Das MVC Pattern beschreibt eine Architektur mit einer Dreiteilung in Datenmodell, Präsentation und Steuerung. Für die praktische Umsetzung ist es wichtig die Steuerung so zu entwerfen, dass sie Flexibilität und Wiederverwendbarkeit ermöglicht und Codewiederholungen vermeidet. Bei Webanwendungen wird häufig der Page-Controller eingesetzt, der mit Vererbung arbeitet. Diejenigen Funktionen, die von mehreren Seiten benötigt werden, kommen in eine Basisklasse. Alle Klassen, die die Funktionen der Basisklasse benötigen erben von dieser. Dadurch wird eine Codewiederholung vermieden. Bei sehr komplexen Anwendungen kann jedoch eine Hierarchie von Basisklassen entstehen, die sehr unübersichtlich und schwer zu pflegen ist. Hier kommt der Front-Controller zum Einsatz. Dieser besteht aus einem Handler und einer Hierarchie aus Befehlen. Der Handler erhält die HTTP-Anfrage und 10

15 2.3 Maßnahmen für die Erweiterbarkeit und Wartbarkeit der Anwendung bestimmt aus ihren Parametern den aufzurufenden Befehl, der dann die Anfrage weiterbearbeitet. Das Befehlsobjekt wird bei jedem Aufruf neu instantiiert, wodurch die Thread Sicherheit der Anwendung gewährleistet wird Contract First Design Bei der Entwicklung größerer Softwaresysteme wird die Logik in Module bzw. Komponenten unterteilt. Dadurch entstehen Abhängigkeiten zwischen den Komponenten, die ohne sorgfältige Planung schnell unhandlich und unverständlich werden. Das Contract First Design, welches man als Entwurfsstrategie oder Architekturmuster bezeichnen kann, versucht dem entgegen zu wirken. Es sieht vor, dass für jede Komponente zu Beginn des Entwicklungsprozesses ein Vertrag definiert wird. Der Vertrag definiert die Schnittstelle der Komponente und enthält lediglich Interfaces und Datentypen. Die Implementierung des Vertrags erfolgt als Black Box. Die Ziele sind eine gute Wart- und Testbarkeit durch die eindeutige Spezifikation und eine gesteigerte Produktivität und Verständlichkeit durch die Black Box Entwicklung. Abbildung 2.2: Contract First Design Die Komponenten können parallel entwickelt werden und die Implementierung der Verträge kann jederzeit ausgetauscht werden. Durch die Entkoppelung der Einheiten werden die Abhängigkeiten reduziert und eine dienstorientierte Sicht erzwungen.[sie02][sie04] 11

16 2.3 Maßnahmen für die Erweiterbarkeit und Wartbarkeit der Anwendung Der Page Cache Der Cache ist ein Puffer-Speicher zum Speichern der Daten, die häufig benötigt werden. Der Page Cache wird hauptsächlich im Zusammenhang mit Webanwendung als Entwurfsmuster bezeichnet. Um einen schnelleren Zugriff zu ermöglichen wird eine Kopie der benötigten Daten im Cache abgelegt, der um einiges kleiner ist als der Hauptspeicher. Daraus resultiert eine Verringerung der Zugriffszeit und der Anzahl der Zugriffe auf den Hauptspeicher, welches für Webanwendungen von großer Wichtigkeit sein kann. Abbildung 2.3: Page Cache Die Abbildung 2.3 zeigt wie die Server, Datenbank und Cache in Verbindung stehen. Bei einer hohen Anzahl konkurrierender Zugriffe liegt eine große Last auf dem Server, vor allem auf der Datenbank. Das liegt vor allem daran, dass viele Darstellungselemente sich selten oder gar nicht ändern, aber protokollbedingt neu aufgebaut werden müssen. Solche Elemente müssen identifiziert und zwischengespeichert werden. Die Effizienz steigert sich, da die Daten nicht erst auf der Festplatte gesucht oder neu berechnet werden müssen, sondern bereits im Cache liegen und somit zum Abruf bereitstehen. Es ist möglich ganze Seiten im Cache zu halten, Teile von Seiten, oder einzelne Objekte. Um eine geeignete Cachingstrategie zu entwerfen müssen verschiedene Parameter bestimmt werden. Dazu gehört die Größe der Speichereinheiten und das Indexing. Das Indexing definiert wie die Informationen im Cache lokalisiert werden. Eine Identifikation der Seite kann über die URL der Ressource oder über bestimmte Parameter, wie Browsersettings stattfinden. Zuletzt muss bestimmt werden wie oft die Daten 12

17 2.3 Maßnahmen für die Erweiterbarkeit und Wartbarkeit der Anwendung aktualisiert werden sollen, das heißt in welchen Zeitabständen die Daten aus dem Hauptspeicher in den Cache geladen werden. Dadurch wird vermieden, dass veraltete Daten von Nutzern verwendet werden Der Intercepting Filter Abbildung 2.4: Die Filterkette In vielen Webanwendungen gibt es Aufgaben die thematisch von der Anwendungslogik unabhängig sind. Dies kann zum Beispiel die Abfrage beinhalten ob eine Authentifizierung stattgefunden hat, ob eine Sitzung gültig ist, ob die IP-Addresse des Clients von einem vertrauenswürdigen Netzwerk kommt und weiteres. Solche Aufgaben müssen meist vor oder nach der Anwendungslogik und zusätzlich bei jeder eingehenden HTTP-Anfrage ausgeführt werden. Dieser Code sollte idealerweise zentral verwaltet und separat zur Anwendungslogik gespeichert werden. Um so ein Konzept zu realisieren kann der Intercepting Filter implementiert werden. Jede Aufgabe wird als Filter umgesetzt. Dadurch entstehen unabhängige Module, da zwischen den Filtern keine Abhängigkeiten existieren dürfen. Jede eingehende HTTP-Anfrage muss nacheinander alle Filter durchlaufen, bevor sie von der eigentlichen Webanwendung verarbeitet wird (siehe Abblidung 2.4). Dieses Konzept hat den Vorteil, dass die Filter beliebig kombiniert und ausgetauscht werden können Wiederverwendung Wiederverwendung ist in der Softwareentwicklung zu einer Schlüsselanforderung geworden. Dazu gehört die Wiederverwendung von Code, dem Layout,dem Entwurf und der Architektur. Die Vorteile liegen in der verbesserten Konsistenz, da jeder Inhalt nur einmal existiert und immer auf die selben Daten zugegriffen wird. Das Auffinden und Verändern von Daten ist einfacher wenn keine Duplikate vorhanden sind. Durch das Kombinieren einzelner Einheiten kann schnell eine Umstrukturierung realisiert werden. Die Übersetzungszeit wird verkürzt, da 13

18 2.3 Maßnahmen für die Erweiterbarkeit und Wartbarkeit der Anwendung weniger Daten vorhanden sind. Zusätzlich führt eine Wiederverwendung zu einer Reduzierung der Entwicklungs- und Wartungskosten, einer Verbesserung der Qualität und Zuverlässigkeit, sowie zu einer schnelleren Entwicklungszeit. Um einen Entwurf mit konsequenter Wiederverwendung umzusetzen ist eine umfangreiche Planung notwendig. Der Inhalt muss in eine einheitliche Form gebracht werden und strukturiert werden, wobei die Granularität durch den kleinsten Inhalt bestimmt wird, welcher wiederverwendet werden kann. Metadaten müssen angelegt werden, die die Struktur beschreiben. Dabei wird unterschieden zwischen: Gesperrter Wiederverwendung: Hier kann das wiederverwendete Element nicht verändert werden Abgeleitete Wiederverwendung: Hier kann das wiederverwendete Element verändert werden Verschachtelte Wiederverwendung: Hier wird ein Element aus wiederverwendbaren Elementen zusammen gesetzt oder unterschiedliche Versionen des Inhalts sind im selben Element enthalten Mechanismen in der Programmierung Diese nachfolgenden Mechanismen haben eine feine Granularität. Das bedeutet, die wiederverwendeten Einheiten sind klein. Vererbung: Die Vererbung dient dazu neue Klassen unter Verwendung von bestehenden aufzubauen. Dabei unterscheidet man zwischen der Vererbung der Implementation, der Vererbung der Schnittstelle und der Vererbung funktionaler Eigenschaften. Abstraktion: Wenn mehrere verwandte Klassen existieren kann eine abstrakte Klasse erstellt werden, die die gemeinsamen Eigenschaften und Methoden definiert und an die Unterklassen vererbt. Von einer abstrakten Klasse ist keine Objekterzeugung möglich. Sie enthält nur Definitionen von Eigenschaften und Methoden, nicht die Implementierung. Erst die konkrete Klasse legt das Verhalten und damit die Implementierung fest. 14

19 2.3 Maßnahmen für die Erweiterbarkeit und Wartbarkeit der Anwendung Polymorphismus: Der Polymorphismus ermöglicht eine vom Datentyp unabhängige Programmierung. Man unterscheidet zwischen universellem Polymorphismus und Adhoc Polymorphismus. Universelle Polymorphismus: Der Universelle Polymorphismus basiert prinzipiell auf einer Menge mit beliebig vielen Datentypen. Sie müssen jedoch eine gemeinsame Grundstrukur besitzen, beispielsweise Subtypen eines gemeinsamen Obertyps sein. Parametrischer Polymorphismus (Generizität): Hier besitzt die Funktion eine Definition und einen extra Parameter, der den Typ der Funktionsparameter enthält. Subtyping: Hier kann die Funktion mit einem beliebigen Parameter aufgerufen werden. Diese Parameter muss jedoch ein Untertyp von dem Typ sein, der in der Funktion angegeben ist. Ad-hoc Polymorphismus: Der Ad-hoc Polymorphismus basiert auf einer endlichen Menge von Datentypen. Diese können völlig voneinander unabhängig sein. Überladen: Hier werden verschiedene Funktionen unter dem gleichen Namen definiert. Anhand des Aufruf-Kontexts, zum Beispiel die Anzahl und der Typ der Aufrufparameter, wird entschieden welche Implementierung aufgerufen wird. Es kann ein unterschiedliches Verhalten für jeden Typ festgelegt werden. Das hat den Vorteil, dass jede Implementierung für den entsprechenden Datentyp optimiert werden kann. Coercion: Hier werden vor dem Aufruf der Funktion die Parameter, deren Typ nicht mit der Funktionsdefinition übereinstimmen, automatisch in den passenden Typ konvertiert. Bei C# können die geerbten Methoden einer Überklasse überschrieben werden, wenn sie mit den Schlüsselwörtern virtual, abstract oder override deklariert sind. 15

20 2.3 Maßnahmen für die Erweiterbarkeit und Wartbarkeit der Anwendung Dies ist auch bei Subtyping der Fall, da Subtyping in objektorientierten Sprachen häufig mit Vererbung gekoppelt wird. Das heißt, es ist sowohl eine abgeleitete als auch eine gesperrte Wiederverwendung möglich. Letzteres wird in C# durch das Schlüsselwort sealed umgesetzt. Das Überladen ist eine verschachtelte Wiederverwendung, da unterschiedliche Versionen der Funktion unter dem selben Namen bereitgestellt werden. Die Coercion und der parametrische Polymorphismus sind gesperrte Wiederverwendung, da die Funktionsdefinition gleich bleibt. Bei der Coercion werden die Parameter vor dem Aufruf angepasst, bei dem parametrischer Polymorphismus ist dies nicht nötig Bibliotheken, Module und Klassen Eine Bibliothek stellt eine Sammlung von Hilfsmodulen zur Verfügung. Diese Module können Komponenten, Funktionen, Deklarationen, Klassen und weiteres enthalten. Sie sind in der Regel nicht selbst lauffähig und werden im Quellcode des Entwicklers aufgerufen. Bibliotheken besitzen eine gröbere Granularität als die vorangegangenen Mechanismen Referenzarchitekturen Referenzarchitekturen sind erprobte, generische Software-Architekturen für bestimmte Anwendungsdomänen, etwa Automotive oder E-Commerce.[RR06] Das bedeutet, dass für verschiedene Anwendungsbereiche Grundkonstruktionen definiert werden. Aus diesem Grund sind sie sowohl produkt- als auch unternehmensunabhängig. Sie enthalten allgemeine Entwurfsregeln, Komponenten, Strukturen und Schnittstellen. Weiterhin besitzen sie domain-spezifische Infrastukturen. Die Referenzarchitektur und die nachfolgenden Techniken besitzen die gröbste Granularität. Man kann in diesem Zusammenhang von der Wiederverwendung von Architekturen sprechen. Entwurfsmuster können ebenfalls zu dieser Kategorie hinzu gezählt werden. Da die Entwurfsmuster bereits im Abschnitt besprochen wurden, soll hier nicht weiter darauf eingegangen werden. 16