Spezifikation und Umsetzung von Architekturadaptionen auf Basis der AMACONT-Systemarchitektur

Größe: px
Ab Seite anzeigen:

Download "Spezifikation und Umsetzung von Architekturadaptionen auf Basis der AMACONT-Systemarchitektur"

Transkript

1 Spezifikation und Umsetzung von Architekturadaptionen auf Basis der AMACONT-Systemarchitektur Diplomarbeit Technische Universität Dresden Juni 2006 Stefan Pietschmann Betreuer: Dipl.-Inf. Michael Hinz Hochschullehrer: Prof. Dr. Klaus Meißner Fachgebiet Multimediatechnik Institut für Software- und Multimediatechnik Fakultät Informatik

2 Technische Universität Dresden Fakultät Informatik Aufgabenstellung für die Diplomarbeit Name, Vorname des Studenten: Pietschmann, Stefan Immatrikulationsnummer: Thema: Spezifikation und Umsetzung von Architekturadaptionen auf Basis der AMACONT-Systemarchitektur Zielstellung: Zunehmend gewinnen interaktive, personalisierte und adaptive Web-Anwendungen an Bedeutung. Dadurch wird eine komplexe dynamische Generierung von Webseiten zur Laufzeit erforderlich, die bei jeder Serveranfrage eine hohe Serverlast erzeugen kann. Das Projekt AMACONT beschäftigt sich u. a. mit der Fragestellung, wie die Systembelastung durch Anpassung der System- und Anwendungsarchitektur an die Belastungssituation durch Verteilung von System- und Anwendungskomponenten auf verschiedene Systemknoten optimiert werden kann. Beispielsweise können optionale Systemkomponenten bei einer hohen Serverauslastung abgeschaltet oder durch andere ressourcenschonendere Komponenten ersetzt werden. Ebenfalls kann die Verteilung von Systemkomponenten auf andere Server oder Endgeräte erfolgen. Ziel dieser Arbeit ist es, Spezifikationssprachen und Mechanismen zu entwickeln, mit denen sich Adaptionen auf Systemebene beschreiben und umsetzen lassen. Dadurch soll die Möglichkeit geschaffen werden, Adaptionsszenarien wie Abschalten von optionalen Systemkomponenten, Verlagerung von Systemkomponenten auf andere Server oder Clients und Auswahl einer geeigneten Systemkomponente innerhalb der AMACONT-Architektur zu unterstützen. Im Einzelnen sollen folgende Aufgaben bearbeitet werden: Zusammenstellung des aktuellen Standes der Forschung auf dem Gebiet adaptiver Systemarchitekturen. Analyse, Erweiterung und Verallgemeinerung des im Komplexpraktikum WS04/05 entwickelten Verteilungs- und Adaptionskonzeptes. Das Konzept ist mit dem in der Diplomarbeit von Herrn Umbach zu entwickelnden Verteilungskonzept abzustimmen. Entwicklung einer Spezifikationssprache zur Beschreibung von Adaptionen auf Systemebene in Abhängigkeit von Systemzuständen. Konzeption sowie Implementierung eines Mechanismus zur Umsetzung dieser Beschreibungen. Dazu ist ein Adaptions- / Verteilungsmanager, der die Adaptionsprozesse steuert, und ein Monitoring-Manager, der Systemzustände über eine Schnittstelle zur Verfügung stellt, zu entwickeln. Entwicklung von Mechanismen zur Synchronisation von Kontextmodellen zwischen Servern und Clients innerhalb der AMACONT-Systemarchitektur. Nachweis der Architekturadaptionen mit Hilfe verschiedener Anwendungsszenarien, die die Adaptionen in geeigneter Weise visualisieren. Betreuer: Verantwortlicher Hochschullehrer: Institut: Beginn am: Einzureichen am: Verteiler: Prüfungsamt Dipl.-Inf. Michael Hinz Prof. Dr.-Ing. K. Meißner Software- und Multimediatechnik HSL... Student (Deckblatt der Belegarbeit) Unterschrift des verantwortlichen Hochschullehrers

3 Erklärung Hiermit erkläre ich, Stefan Pietschmann, die vorliegende Diplomarbeit zum Thema Spezifikation und Umsetzung von Architekturadaptionen auf Basis der AMACONT-Systemarchitektur selbstständig und ausschließlich unter Verwendung der im Quellenverzeichnis aufgeführten Literatur- und sonstigen Informationsquellen verfasst zu haben. Dresden, am 01.Juni 2006 (Stefan Pietschmann) Copyright TU Dresden, Stefan Pietschmann iii

4 Inhaltsverzeichnis 1 Einleitung und Hintergrund Motivation Problemstellung Überblick über die Arbeit Einordnung in das Projekt AMACONT Adaptive Web-Systemarchitekturen Einordnung und Charakterisierung der Begriffe Softwarearchitektur Adaptivität Dynamisch adaptive Softwarearchitektur Motivation, Forschungsgebiete und Einsatzszenarien adaptiver Software Motivation Einsatzbereiche und Forschungsgebiete dynamisch adaptiver Software Beispielszenarien adaptiver Architekturen Ausgewählte Aspekte adaptiver Architekturen Auslöser für Adaptionen Anforderungen an adaptive Systeme Adaptionszeitpunkt Regelungssystem Weitere Aspekte Zusammenfassung Spezifikation dynamischer Architekturen ADLs, AMLs und ACLs Formale Modelle Andere Spezifikationsansätze Adaptionsmethoden und -techniken Adaptionsmethoden Adaptionstechniken Aktuelle Forschungsansätze dynamisch adaptiver Systeme Klassifikationsmuster dynamisch adaptiver Systeme Vorstellung ausgewählter Ansätze Besonderheiten adaptiver Web-Architekturen Analyse des bestehenden Adaptions- bzw. Verteilungskonzeptes Die AMACONT Dokumentgenerierung Die Pipeline Die Pipeline-Komponenten Ablauf der Dokumentgenerierung Architekturadaption mit dem Verteilungsmanager Der Verteilungsmanager Copyright TU Dresden, Stefan Pietschmann iv

5 Inhaltsverzeichnis Die Konfigurationsdatei AmaConfig.xml Die Monitorkomponenten Einbindung und Nutzung in der Sitemap Umsetzung der Client-Server-Verteilung Möglichkeiten der Architekturadaption Bewertung und Schlussfolgerungen Vorteile Nachteile Schlussfolgerungen für die Neukonzeption Entwicklung eines Konzeptes zur Architekturadaption Grundlagen, Anforderungen und Ziele des Konzeptes Grundlagen Anforderungen und Ziele Einordnung in den Kontext selbst-adaptiver Systeme Ein 3-Ebenen-Konzept zur Architekturadaption Anwendungsebene Adaptionsmanagementebene Monitoringebene Prinzip des zweistufigen Caching Client-Server-Verteilung mit dem 3-Ebenen-Konzept Verknüpfung von Komponenten mit Vorbedingungen Erweiterung der Sitemap Definition generischer Vorbedingungen Zusammenfassung Technische Umsetzung und Bewertung des Konzeptes in AMACONT Implementierungsgrundlagen und Anforderungen Implementierungsgrundlagen Anforderungen an die Implementierung Softwaretechnische Umsetzung des Konzeptes Umsetzung der Anwendungsschicht Umsetzung der Adaptionsmanagementschicht Umsetzung der Monitoringschicht Konfiguration des SystemAdaptation-Frameworks Struktur und Funktionsweise Nutzung durch andere Anwendungen Diskussion ausgewählter Designentscheidungen Verknüpfung von Pipeline und Requirements Anticipant vs. Lazy Processing Beispiele Performanzbewertung Zusammenfassung und Ausblick 80 A Beschreibung der Klassen I A.1 Adaptive(Profiling)NonCachingProcessingPipeline II A.2 ActTypeNode & ActSetNode III A.3 AdaptationManager(Impl) III A.4 ConfigurationSourceHandler(Impl) V A.5 MonitorManager(Impl) VI Copyright TU Dresden, Stefan Pietschmann v

6 Inhaltsverzeichnis A.6 Monitore VII Abkürzungsverzeichnis Abbildungsverzeichnis Internetquellen Literaturverzeichnis VIII XI XI XIII Copyright TU Dresden, Stefan Pietschmann vi

7 Es gibt Arbeiten, die man nicht erledigt hat, bevor man sie anfängt. Walter Ludin, 1945 z. Z. 1 Einleitung und Hintergrund In den letzten Jahren hat sich ein Bewusstsein für die Notwendigkeit von Adaptivität in webbasierten Systemen entwickelt. Diese soll zum einen den speziellen Anforderungen heterogener Netzwerke, Endgeräte und auch Nutzereigenschaften bzw. -interessen gerecht werden, und zum anderen der ständig steigenden Last durch wachsende Bandbreiten und Nutzerzahlen. Diesen Problemen kann Adaptivität auf zweierlei Weise begegnen: mit adaptiven Inhalten (Dokumentadaption) und mit adaptiven Systemen (Architekturadaption). Zur Unterstützung des Servers kann erstere allerdings nur bedingt beitragen 1. Deshalb benötigen Web-Anwendungen adaptive Systemarchitekturen. In dieser Arbeit wird ein Konzept zur dynamischen Architekturadaption und dessen Umsetzung für die SystemArchitektur für Multimedialen Adaptiven WebCONTent (AMACONT) vorgestellt. Es basiert auf drei Ebenen, die für die Überwachung des Kontextes, das Adaptionsmanagement und die Umsetzung der Architekturrekonfiguration verantwortlich sind. Das entstandene SystemAdaptation Framework ermöglicht die anwendungsunabhängige Adaption pipelinebasierter Softwarearchitekturen zur Laufzeit. 1 Durch die geeignete Auswahl von Inhalten und die Anpassung der Linkstruktur kann der Datenverkehr (Traffic) beeinflusst werden. Copyright TU Dresden, Stefan Pietschmann 1 von 82

8 1. Einleitung und Hintergrund 1.1 Motivation Mit der Entwicklung des Internets von einem Kommunikations- und Browsinginstrument hin zu einer Infrastruktur für verschiedenste Dienstangebote [Abdelzaher und Bhatti, 1999b] kommt Web-Anwendungen und -Servern eine Schlüsselrolle im Internet der Zukunft zu. Dies verlangt von ihnen ein gewisses Maß an Dienstqualität, Verlässlichkeit und Sicherheit, während sie - Moore s Law und Gilder s Law zugrunde gelegt 2 - einer stetig zunehmenden Last ausgesetzt sind. Die Optimierung bzw. Leistungssteigerung solcher Systeme ist also entscheidend, um den technischen und nutzerorientierten Ansprüchen der Zukunft gerecht werden zu können. Auf der anderen Seite muss der Heterogenität von Endgeräten, Netzwerken und auch Nutzern in diesem Umfeld begegnet werden. Dazu bedarf es angepasster Inhalte in Form von adaptive Hypermedia, die vor allem auf Veränderungen des Clientkontextes 3 reagieren und auf Techniken zur dynamischen Auswahl von Inhalten (Content Selection) sowie Anpassung von Präsentation (adaptive presentation) und Linkstruktur (adaptive navigation support) [Pietschmann, 2005] basieren. Diese Techniken bedingen eine Vielzahl adaptierender Systemkomponenten, die aber nicht zwangsläufig bei jedem Aufruf benötigt werden und u. U. auf den Client ausgelagert werden können. Zur Unterstützung der adaptiven Dokumentgenerierung ist folglich eine adaptive Architektur hilfreich, um die benötigten Komponenten dynamisch auszuwählen und automatisch für die Situation bzw. das jeweilige Umfeld zu konfigurieren. Ein weiteres, wesentliches Ziel adaptiver Web-Architekturen besteht in der Performanzverbesserung, um angepasste Inhalte in kürzerer Zeit an mehr Clients liefern zu können. In verschiedenen Projekten wurde bereits belegt, dass durch Architekturadaption eine signifikante Leistungssteigerung erreicht werden kann [Chang und Karamcheti, 2000]. Die heutige Software steht nicht mehr für monolithische Strukturen, sondern für eine Verbindung bereits existierender (COTS) Komponenten. Auch AMACONT ist sowohl auf der Dokument- als auch auf der Architekturebene komponentenbasiert. Die dynamische Anpassung der Komponententopologie und -konfiguration wird bisher aber lediglich innerhalb der Dokumente verwendet (Dokumentadaption), um adaptive Webinhalte generieren zu können. Aufgrund der oben beschriebenen Entwicklung und der bisher stark eingeschränkten Möglichkeiten dynamischer Architekturadaption (Strukturadaption) ist die Konzeption und Umsetzung neuer Mechanismen hierfür von großer Bedeutung. Im Folgenden werden einige Szenarien angedeutet, die durch eine adaptive Systemarchitektur umgesetzt werden könnten. Auf weitere Möglichkeiten wird in Kapitel eingegangen. Ausführung lediglich der benötigten und Auslassen optionaler Komponenten zur Reduktion von Last und Verringerung der Antwortzeit Beschränkung der Ausführungshäufigkeit einer Komponente bei hoher Serverlast (Auswertung von Nutzerinteraktionen aller x Requests) Dynamische Zu-/Abschaltung von Komponenten, je nach Nutzer (zusätzliche Informationen für Administratoren) oder anderer Kontextparameter (Einbindung einer Verschlüsselungskomponente, falls ein unberechtigter Zugriff [Poellabauer et al., 2003] oder Bezahl-Service vorliegt) 2 Moore s Law [Moore, 1965] besagt, dass sich die Rechenleistung (bzw. die Hardware-Kapazität allgemein) alle 18 Monate verdoppelt. Laut Gilder s Law wächst die Bandbreite in den nächsten 25 Jahren aber wenigstens dreimal so schnell ([Gilder, 1997] spricht von einer jährlichen Verdreifachung). Somit können Web-Server immer weniger mit der immensen Bandbreite Schritt halten. 3 Der Clientkontext umfasst alle beobachtbaren Parameter auf der Clientseite (Endgeräteeigenschaften, Bandbreite, Ort etc.). Copyright TU Dresden, Stefan Pietschmann 2 von 82

9 1. Einleitung und Hintergrund Dynamische Parametrisierung von Komponenten (dadurch z. B. Verzicht auf die Einbindung von Applets in ein Dokument, wenn der Client kein Java unterstützt oder einen niedrigen Batteriestand erreicht) Aufgrund der beschriebenen Entwicklung und anhand der Beispiele wird deutlich, welch wichtige Rolle nicht nur adaptiven Inhalten, sondern in zunehmendem Maße auch adaptiven Softwarearchitekturen zukommt. Für AMACONT wäre eine dynamische Architektur insbesondere zur Unterstützung der Dokumentadaption wünschenswert, da das vorliegende System diesem Ziel nicht gerecht werden kann. 1.2 Problemstellung Das Projekt AMACONT [Hinz, 2002] stellt eine komponentenbasierte Architektur zur kontextbasierten Generierung adaptiver Web-Anwendungen bzw. Webseiten zur Verfügung. Dazu wurde eine Vielzahl von Systemkomponenten entwickelt, die aber nicht bei jedem Aufruf benötigt werden, oder u. U. auf den Client ausgelagert werden können. Der Ablauf der Dokumentgenerierung in AMACONT ist bisher jedoch statisch. Alternativen werden durch Verzweigungen im Ablaufplan (Sitemap) beschrieben, die sich lediglich nach dem Namen des Browsers richten. Der dynamische Wechsel zwischen Generierungskomponenten für unterschiedliche Kontexte, beispielsweise zur Ausgabe in HTML oder 3D-Formaten, wie in [Pietschmann, 2005; Dachselt et al., 2006] gezeigt, ist mit der bisherigen Architektur jedoch nicht möglich. Zur Unterstützung der adaptiven Dokumentgenerierung, aber auch zur Leistungssteigerung, bedarf es also einer adaptiven Architektur, um die benötigten Komponenten auszuwählen und für den jeweiligen Kontext zu konfigurieren. In dieser Arbeit wird deshalb der aktuelle Stand der Forschung auf dem Gebiet adaptiver Softwarearchitekturen zusammengefasst und deren Anforderungen und wichtige Kriterien vorgestellt. Unter Nutzung der Erfahrungen und Ergebnisse des Verteilungs- und Adaptionskonzeptes aus [Böhme et al., 2005] wird ein generisches Konzept entworfen und umgesetzt, welches die dynamische Adaption der Architektur ermöglicht. Diese wird von dem Mechanismus aus [Böhme et al., 2005], welcher primär die Client-Server-Verlagerung einer Complementary Discrimination Learning 4 (CDL4)-Komponente [Shen, 1996] ermöglichen sollte, nur unzureichend unterstützt. Ziel dieser Arbeit ist die automatische, dynamische Anpassung der Dokumentgenerierungspipeline an kontextuelle Veränderungen. Für die Entwicklung und Umsetzung des neuen Adaptionskonzeptes müssen die folgenden Teilaufgaben erfüllt werden: Erstellung einer Spezifikationssprache zur Beschreibung adaptiver Eigenschaften in Abhängigkeit von Systemzuständen; Entwicklung von Mechanismen zur Überwachung und Analyse von Kontext und Systemzuständen; Schaffung von Mechanismen zur Entscheidung, Planung und Durchführungen von Adaptionen der Architektur; Etablierung anwendungsseitiger Schnittstellen und Mechanismen zur Unterstützung der dynamischen Adaption. 1.3 Überblick über die Arbeit Kapitel 2 bildet die wissenschaftliche Grundlage für die weitere Arbeit. Zunächst erfolgt die Klärung der Begriffe System- bzw. Softwarearchitektur und Adaptivität. Es folgt ein Überblick Copyright TU Dresden, Stefan Pietschmann 3 von 82

10 1. Einleitung und Hintergrund über Eigenschaften, Anforderungen und Möglichkeiten dynamisch adaptiver Softwarearchitekturen. Danach werden diverse Klassifikationsmuster und Forschungsansätze vorgestellt, die die Bandbreite und verbreitete Konzepte adaptiver Architekturen verdeutlichen. In Kapitel 3 wird das bestehende Verteilungskonzept in AMACONT, basierend auf der Arbeit des Komplexpraktikums Multimediatechnik I [Böhme et al., 2005] im Wintersemester 2004/2005, analysiert. Möglichkeiten der Nutzung bzw. Erweiterung dieses Konzeptes werden diskutiert und Defizite aufgezeigt. Im 4. Kapitel erfolgt die Konzeption erweiterter, generischer Mechanismen zur dynamischen Adaption der AMACONT-Architektur. Nach einer Anforderungsanalyse und der Betrachtung von deren Besonderheiten wird ein 3-Ebenen-Konzept zur Architekturadaption vorgestellt. Kapitel 5 behandelt die Umsetzung des in Kapitel 4 vorgestellten 3-Ebenen-Konzeptes: das SystemAdaptation Framework. Es gliedert sich in eine kurze Betrachtung der Voraussetzungen durch Apache Avalon [Avalon, 2004] bzw. Cocoon [Cocoon, 2006], die Beschreibung der drei Ebenen, deren Kollaboration und Konfigurationsmöglichkeiten. Danach werden einige Beispiele vorgestellt, die im Laufe der Arbeit entstanden, und das System bezüglich seiner Leistung und Möglichkeiten bewertet. Das 6. Kapitel fasst die Ergebnisse der Arbeit zusammen und gibt einen Ausblick auf mögliche Erweiterungen und anschließende Forschungsarbeiten. 1.4 Einordnung in das Projekt AMACONT Ziel des Forschungsprojektes AMACONT ist die softwaretechnologisch einfache, komponentenbasierte Entwicklung adaptiver Web-Sites [Hinz, 2002]. Zu diesem Zweck bietet es ein Autorenwerkzeug [Fiala et al., 2005] zur Erstellung adaptiver Anwendungen und eine Systemarchitektur zu deren Auslieferung bzw. Publikation. Schnittstelle zwischen beiden ist ein komponentenbasiertes Dokumentenmodell, welches genauer in [Fiala et al., 2003] beschrieben wird. AMACONT ist konzeptionell unabhängig von einem konkreten System. Seine Architektur basiert zur Zeit auf dem Projekt Apache Cocoon, welches durch eine Pipeline die schrittweise Transformation eines Ausgangsdokuments in das auszuliefernde Dokument erlaubt. So können Inhalte, Layout, Navigationsstrukturen etc. unter Einbeziehung von Kontext- Informationen, z. B. Nutzer- und Endgerätecharakteristika, angepasst und im benötigten Format (XHTML,WML,VRML u. a.) ausgegeben werden. Die Modellierung der zugrunde liegenden Kontextinformationen übernimmt das AMACONT Context Modeling Framework [Hinz und Fiala, 2005a]. Durch die Arbeit des Komplexpraktikums Multimediatechnik I [Böhme et al., 2005] entstand im Wintersemester 2004/2005 u. a. ein Mechanismus zur Verlagerung des CDL4-Algorithmus auf den Client - je nach Systemzuständen -, welcher rudimentär auch allgemeinere Adaptions- bzw. Verteilungsaspekte unterstützt. Diese Verteilung und Synchronisation von Kontextmodellierungskomponenten zwischen Server und Client wird genauer in [Hinz und Fiala, 2005b] beschrieben. Einen tiefer gehenden Einblick in die Konzepte und den Aufbau des Projektes AMACONT bieten Hinz und Fiala [2004]. Diese Arbeit konzentriert sich auf die Dynamisierung der pipelinebasierten Dokumentgenerierung auf Basis beliebiger Kontextinformationen. Dazu ist die Veränderung der Pipeline- Implementierung und -Komponenten sowie die Etablierung von Mechanismen zur Adaptionsentscheidung und Bereitstellung zusätzlicher Kontextinformationen erforderlich. Copyright TU Dresden, Stefan Pietschmann 4 von 82

11 Nur selten werden Erkenntnisse auf dem Silbertablett serviert. Informationen werden erst zu Erkenntnissen, wenn sie im Schmelztiegel des Geistes, der Erfahrung und des gesunden Menschenverstandes geläutert worden sind. Winston Churchill, Adaptive Web-Systemarchitekturen Begriffsbestimmung und Stand der Forschung In diesem Kapitel soll ein Überblick über das Forschungsgebiet adaptiver Web-Systemarchitekturen gegeben werden. Dazu werden zunächst System- bzw. Softwarearchitektur und Adaptivität begrifflich definiert und deren wesentliche Charakteristika vorgestellt. Es folgt eine Betrachtung dynamisch adaptiver, komponentenbasierter Software, die deren Motivation, Spezifikation, besondere Aspekte und Probleme sowie Adaptionsmethoden und -techniken beinhaltet. Eine ausführliche Betrachtung von Softwarearchitekturen ist im Rahmen dieser Arbeit aufgrund der Fülle an verschiedenen Aspekte nicht möglich und kann beispielsweise [Shaw und Garlan, 1996; Bass et al., 1998] entnommen werden. Der Fokus liegt insbesondere auf der dynamischen Adaptivität solcher Architekturen. Im Anschluss erfolgt eine Zusammenstellung verbreiteter Klassifikationsmuster und die Vorstellung verschiedener grundlegender Konzepte und Forschungsansätze anhand diverser Systeme. Zuletzt wird kurz auf die Eigenheiten webbasierter Software eingegangen. Die gewonnenen Erkenntnisse dienen der Konzeption in Kapitel 4. Copyright TU Dresden, Stefan Pietschmann 5 von 82

12 2. Adaptive Web-Systemarchitekturen 2.1 Einordnung und Charakterisierung der Begriffe Um sich mit adaptiven Softwarearchitekturen auseinandersetzen zu können, bedarf es einer genaueren Betrachtung der Begriffe Softwarearchitektur, Adaptivität und deren Zusammenspiel in adaptiven Softwarearchitekturen. Im Folgenden werden diese geklärt und einige wichtige Charakteristika vorgestellt Softwarearchitektur In diesem Abschnitt werden grundlegende Eigenschaften von Softwarearchitekturen beleuchtet, soweit sie für diese Arbeit von Bedeutung sind. Die Betrachtung erhebt keinen Anspruch auf Vollständigkeit, sondern soll vor allem als Grundlage für die spätere Konzeption dienen. Zunächst gilt es, die System- von der Softwarearchitektur abzugrenzen. Eine Softwarearchitektur bezieht sich auf die Organisation und Struktur von Softwarebestandteilen, d. h. deren Komponenten und Konnektoren. Die Systemarchitektur beschreibt hingegen Eigenschaften und Organisationsstruktur von Ressourcen auf der Hardware-Ebene, auf welche über das Betriebssystem oder Netzwerk zugegriffen werden kann. Einige Definitionen schließen in den Begriff auch die Software ein. Die Systemarchitektur beschreibt also die physische Struktur und Verteilung von Komponenten. Diese Trennung geht konform mit [Medvidovic, 1996]. In dieser Arbeit beziehen sich die Begriffe Architektur bzw. Softwarearchitektur auf komponentenbasierte Softwaresysteme und die Begriffe Systemadaption und Architekturadaption werden synonym zur Beschreibung von Adaption dieser Softwarearchitekturen verwendet Definitionen Für den Begriff Softwarearchitektur gibt es diverse Definitionen, die sich häufig lediglich in Details unterscheiden. Perry und Wolf [1992] beschrieben sie mittels der Formel: Software Architecture = {Elements,Form,Rationale}. Laut Shaw und Garlan [1996] bezieht sich der Begriff auf die Struktur der Komponenten eines Systems und deren Verbindungen, sowie Vorgaben bezüglich seines Entwurfs und Entwicklung mit der Zeit. Fielding [2000] definiert den Begriff folgendermaßen: Eine Softwarearchitektur wird durch eine Konfiguration architektonischer Elemente - Komponenten, Konnektoren und Daten - beschrieben, deren Beziehungen Regeln unterliegen, um eine Menge gewünschter architektonischer Eigenschaften sicherzustellen. Das Rationale, d. h. die Beschreibungen bzw. Grundprinzipien, aus der Definition von Perry und Wolf [1992] wird dabei bewusst ausgeklammert, da ein System auch ohne Wissen über seine zugrunde liegenden Prinzipien bestehen kann [Fielding, 2000]. Softwarearchitektur ist im Grunde also eine high-level Beschreibung eines Softwaresystems auf Basis seiner Komponenten und deren Interaktionen. Hinsichtlich des Abstraktionsniveaus bewegt sie sich oberhalb des Designs, da lediglich abstrakte Bestandteile, sog. Entitäten betrachtet werden. Die Umsetzung in der Programmiersprache spielt für die Architekturbeschreibung keine Rolle, sondern vielmehr die Funktionalität und Schnittstellen, die diese Entitäten veröffentlichen. Das verdeutlicht auch die Definition von Bass et al. [1998], die Softwarearchitektur als Struktur aus Software-Elementen und deren extern sichtbaren Eigenschaften und ihren Beziehungen beschreibt. Shaw und Garlan [1996] nehmen ebenfalls eine ausführliche Definition vor und fügen hinzu, dass die Architektur neben der Spezifikation der Struktur und Topologie des Systems auch die Übereinstimmung zwischen den Systemerfordernissen und den Elementen des konstruierten Systems zeigen muss. Copyright TU Dresden, Stefan Pietschmann 6 von 82

13 2. Adaptive Web-Systemarchitekturen Eine umfangreiche Sammlung weiterer Definitionen findet sich unter [Software Engineering Institute, 2006] und auch Klamar [2004] bietet eine weitergehende Betrachtung der Begrifflichkeit Entwurfsmethoden Dieser Abschnitt gibt einen kurzen Überblick über verschiedene Möglichkeiten des Entwurfs von Softwarearchitekturen. Diese werden hier nur kurz vorgestellt, da in Kapitel einige Erweiterungen - insbesondere der ADLs - um Mittel zum Entwurf von Adaptivität diskutiert werden. Einen tieferen Einblick, Vor- und Nachteile sowie Klassifikationen der einzelnen Methoden bieten u. a. [Shaw und Garlan, 1996; Medvidovic und Taylor, 1997] und [Albring, 2005]. Für den Entwurf von Softwarearchitekturen wurden verschiedenste Methoden entwickelt, die sich vor allem in ihrem Ziel unterscheiden. Sie werden im Folgenden relativ kurz und lediglich unter dem Aspekt der Unterstützung von Adaptivität betrachtet. Nähere Informationen können den angegebenen Quellen entnommen werden. Einen relativ implementierungsnahen Ansatz stellen die CASE-Werkzeuge dar, mit denen sich Softwarearchitekturen in UML, ROOM, SDL o. ä. beschreiben lassen. Mit dem Aufkommen objektorientierter Programmierung und der Beschreibungssprache Unified Modeling Language (UML) [OMG, 2006b] entwickelte sich relativ frühzeitig der eher problemorientierte Ansatz der Entwurfsmuster [Gamma et al., 1995]. In [Shaw, 1996; Buschmann und Meunier, 1995] wurden diverse Architekturmuster vorgestellt, die insbesondere die objektbasierte Entwicklung unterstützten. Diese gehen über das Betrachten der Klassenstruktur hinaus, sind aber trotzdem sehr implementierungsnah und ermöglichen kaum eine abstrakte Sicht auf die Software, deren Bestandteile und adaptives Verhalten. Zur Beschreibung von Architekturen und dem Verhältnis ihrer Komponenten zueinander entwickelten sich Referenzmodelle, z. B. die Object Management Architecture (OMA) der Object Management Group (OMG), und domainspezifische Softwarearchitekturen (DSSA), wie Adaptive Intelligent Systems (AIS) [Hayes-Roth et al., 1995]. Domain-Specific Software Architectures (DSSA) definieren 1 eine Referenzarchitektur, 2 eine Komponenten-Bibliothek und 3 die Methode zur Konfiguration der Anwendung und ihrer Komponenten [Medvidovic et al., 1999]. Einen generellen Überblick über DSSAs bietet [Tracz, 1995]. Architekturbeschreibungssprachen, im Weiteren Architecture Description Language (ADL) genannt, stellen Syntax und Semantik zur Verfügung, um Softwarearchitekturen formal auf einem hohen Abstraktionslevel zu beschreiben. Sie nutzen dazu mindestens 1 vier Entitäten: Komponenten, Schnittstellen, Konnektoren und Konfiguration [Medvidovic et al., 1997]. Neben den vorherrschenden generischen ADLs existieren diverse domainspezifische Sprachen, wie C2 SADL [Medvidovic, 1996] oder UPML [Fensel et al., 2003]. Unter dem Blickwinkel dynamischer bzw. adaptiver Architekturen wurden innerhalb der letzten Dekade eine Vielzahl von Erweiterungen und neuen Sprachen vorgestellt, um Architekturveränderungen zur Laufzeit beschreiben zu können. Auf sie wird im Abschnitt näher eingegangen. Formale Architekturmodelle beschreiben Softwarearchitekturen auf formaler Ebene. Beim Chemical Abstract Machine (CHAM) Formalismus [Inverardi und Wolf, 1995] geschieht dies beispielsweise als Zusammenspiel chemischer Elemente, deren Reaktionen durch festgelegte Regeln gesteuert werden. Er legt fest, wie Komponenten Daten transformieren und nutzt Rezept-Regeln um die individuellen Ergebnisse zum Gesamtergebnis des Systems zusam- 1 Viele ADLs bieten weitere Modellierungsobjekte, wie etwa Ports oder Rollen. Die vorgestellten vier Objekte stellen den kleinsten gemeinsamen Nenner aller Sprachen dar. Copyright TU Dresden, Stefan Pietschmann 7 von 82

14 2. Adaptive Web-Systemarchitekturen menzufassen. Weitere Beispiele sind Rapide [Luckham und Vera, 1995] und Graph Grammars [Métayer, 1998; Hirsch et al., 1998]. Module Interconnection Languages (MIL) dienen der Zusammensetzung von Systemen aus verschiedenen Modulen. Sie beschreiben die use-beziehungen zwischen Modulen im Gegensatz zur ADLs, die Verbindungen zwischen Komponenten zur Festlegung des Daten- und Kontrollflusses nutzen [Medvidovic et al., 1997]. Bestehende MILs können nicht zur Beschreibung dynamischer Architekturen verwendet werden, in denen Objektinstanzen dynamisch erstellt und verbunden werden. Es gibt noch eine Reihe weiterer Modelle, beispielsweise Reflexionsmodelle [Murphy et al., 1995], die Systeme auf Basis des Quellcodes beschreiben, die hier nicht weiter betrachtet werden sollen Architektonische Elemente In der Literatur gibt es unterschiedliche Ansichten, welche und wie viele elementare Bestandteile es in einer Softwarearchitektur gibt. Garlan et al. [2000] unterscheiden für die ADL ACME beispielsweise sieben Typen: components, connectors, systems, ports, roles, representations, und rep-maps (Abb. 2.1). Zur Betrachtung der Architekturadaption in AMACONT sind jedoch die drei Hauptbestandteile processing elements, connecting elements und data elements aus dem wegweisenden Artikel von Perry und Wolf [1992] ausreichend, für welche die heute gängigen Begriffe Komponenten, Konnektoren und Daten genutzt werden. Komponenten sind abstrakte Einheiten einer Software, die Daten transformieren [Fielding, 2000] bzw. etwas berechnen [Garlan und Shaw, 1993]. Sie zeichnen sich durch ihre Schnittstelle und die darüber zur Verfügung gestellte Funktionalität aus, nicht durch deren eigentliche Implementierung [Bass et al., 1998]. Komponenten der Softwarearchitektur können Subsysteme, Bibliotheken, Prozesse o. ä. sein - sie sind also nicht zwingend mit Komponenten in Architekturen wie J2EE oder.net gleichzusetzen [Fielding, 2000]. Konnektoren, in [Perry und Wolf, 1992] vage als Glue (Kleber) bezeichnet, sind abstrakte Mechanismen die die Kommunikation, Koordination oder Kooperation von Komponenten regeln [Fielding, 2000]. Daten spiegeln Informationen wider, die zwischen Komponenten ausgetauscht werden, wie Bytefolgen, Nachrichten, Parameter oder serialisierte Objekte [Fielding, 2000]. Sie sind als Bestandteil einer Softwarearchitektur umstritten und werden in einer Vielzahl von Modellen nicht betrachtet. Boasson [1995] und andere Autoren kritisieren dies allerdings und fordern einen verstärkten Fokus auf datenzentrierte Architekturmodellierung. Abb. 2.1: Elemente einer ACME Beschreibung [Garlan et al., 2000] Copyright TU Dresden, Stefan Pietschmann 8 von 82

15 2. Adaptive Web-Systemarchitekturen Eine festgelegte Topologie von Komponenten, Konnektoren und Daten zu einem bestimmten Zeitpunkt bzw. einer gewissen Zeitspanne zur Laufzeit wird als Konfiguration bezeichnet [Fielding, 2000; Ramdane-Cherif und Levy, 2002]. Das Endprodukt einer Architekturadaption ist also immer eine den Systembedingungen genügende, eindeutige Konfiguration. In selbst-organisierten Softwarearchitekturen konfigurieren die Komponenten automatisch ihre Zusammenarbeit in der Art, dass sie mit einer allgemeinen Architekturbeschreibung übereinstimmt [Georgiadis et al., 2002] Pipelinebasierte Architekturen Bei der Unterscheidung von Softwarearchitekturen ist der Begriff Architekturstil von großer Bedeutung. Er umfasst eine festgelegte, koordinierte Menge architektonischer Bedingungen, die die Rollen bzw. Eigenschaften architektonischer Elemente und die erlaubten Beziehungen zwischen diesen Elementen innerhalb jeglicher Architektur jenes Stils beschränken [Fielding, 2000]. Da sich diese Arbeit mit der Konzeption und Umsetzung von Architekturadaption für AMACONT, und somit für pipelinebasierte Architekturen, beschäftigt, werden diese im Folgenden etwas näher vorgestellt. Der Pipe-and-Filter-Stil Im Bereich von Web-Anwendungen sind pipelinebasierte Ansätze recht häufig vertreten, da sie auf einfache Art und Weise die lineare Verarbeitung vom Input (= Request) zum Output (= Response) ermöglichen. Dieser Stil wird als one-way data flow network (Einbahn-Datenfluss Netzwerk) [Andrews, 1991] oder Pipe-and-Filter-Prinzip bezeichnet. Er beschreibt den sequentiellen Datenfluss innerhalb einer Pipeline, in welcher Filter in einer festen Reihenfolge angeordnet sind. Die Filter definieren Input- und Output-Schnittstellen, über die sie mittels Pipes verbunden sind. Der Eingabestrom wird oft inkrementell transformiert, sodass bereits während der Transformation die Ausgabe beginnen kann [Garlan und Shaw, 1993]. Nutzen alle Filter die gleiche Schnittstelle, so spricht man vom Uniform Pipe-and-Filter (UPF)- Stil. Dieser verbessert die Wiederverwendbarkeit von Komponenten und die Konfigurierbarkeit der Anwendung. Wichtig in diesem Zusammenhang ist das Prinzip des Zero Coupling [Garlan und Shaw, 1993], welches besagt, dass sich Filter weder Zustand, noch Kontroll-Thread, noch Identität mit anderen Filtern ihrer In- oder Output-Schnittstellen teilen dürfen. Sie müssen also völlig unabhängig voneinander funktionieren, was die dynamische Rekonfiguration extrem vereinfacht, da auf Abhängigkeiten keine Rücksicht genommen werden muss (siehe Kap , Konsistenzund Integritätssicherung). Beispiele Pipelining findet besonders bei der Verarbeitung von extensible Markup Language (XML) sehr häufig Anwendung. Zur Beschreibung der Verarbeitungslogik wurde eine Vielzahl an Pipeline-Verarbeitungssprachen entwickelt, wie beispielsweise XML Pipeline Language (XPL) [Bruchez und Vernet, 2005]. Deren Spezifikation, 2005 von Orbeon beim World Wide Web Consortium (W3C) eingereicht, greift W3C Notes von 2002 und 2004 bezüglich der Sprache XML Pipeline Definition Language (XPDL) [Walsh und Maler, 2002] wieder auf 2 Ein XPL- Programm ist ein wohlgeformtes XML-Dokument, welches eine Reihe von Operationen auf sog. XML Information Sets (Infosets) [Tobin und Cowan, 2004] definiert. Die Motivation hinter XPL ist es, die Interoperabilität zwischen verschiedenen Spezifikationen für XML-Dokumente, z. B. XSLT zur Transformation, RELAX NG [Clark, 200] zur Validierung etc., zu ermöglichen. 2 Es handelt sich bei XPL jedoch nicht um eine direkte Weiterentwicklung von XPDL. Wesentliche Unterschiede zwischen beiden Sprachen sind in [Bruchez und Vernet, 2005, Abschnitt B1] aufgeführt. Copyright TU Dresden, Stefan Pietschmann 9 von 82

16 2. Adaptive Web-Systemarchitekturen Dazu bietet sie einen festen Rahmen zur Definition aufeinander folgender Verarbeitungsschritte, wie die Erstellung, Verarbeitung und Serialisierung von Infosets. Jeder XPL-Prozessor definiert eine Menge von Inputs und Outputs, über die er mit dem Rest der Pipeline verbunden ist, und ein Verhalten, welches die Schritte bei seiner Ausführung beschreibt. Insofern ähnelt XPL sehr dem Konzept der Sitemap und Pipelines in Apache Cocoon (siehe Kap ). Weitere Vertreter solcher XML- und pipelinebasierter Verarbeitungsmodelle sind XPipe [XPipe, 2002], SXPipe [Walsh, 2005] und DPML [1060 Research, 2004]. Neben dem Cocoon Framework [Cocoon, 2006], welches in den folgenden Kapiteln näher vorgestellt wird, seien als Beispiele pipelinebasierter Web-Architekturen die Apache Projekte Jetspeed-2 [Jetspeed-2, 2005] und Jelly [Jelly, 2006] genannt, bei denen ebenfalls eine Verarbeitung von Daten bzw. Events durch eine Reihe von Filtern, Transformern bzw. Prozessoren stattfindet. Auch außerhalb der Web-Domäne findet dieser Architekturstil Anwendung, wie das System zur Annotation und Informationsextraktion aus Pathologieberichten von Mitchell et al. [2004] zeigt. Vor- und Nachteile Die Nutzung eines pipelinebasierten Datenflusses bietet diverse Vor-, aber auch Nachteile. Das System ist leicht verständlich (Simplicity), da seine Ausgabe als Summe der Verhalten seiner Filter verstanden werden kann. Weitere Vorteile umfassen die gute Wiederverwendbarkeit (Reusability) - Filter können beliebig neu zusammen geschaltet werden -, Erweiterbarkeit (Extensibility) - es können einfach neue Filter eingefügt werden -, Entwicklungsfähigkeit (Evolvability) - alte Filter können problemlos durch neue Versionen ersetzt werden - und Überprüfbarkeit (Verifiability) des Systems, z. B. mittels Durchsatz- oder Deadlock-Analysen. Aufgrund des Zero Coupling-Prinzips (s. o.) ist sowohl die nebenläufige Ausführung von Prozessen möglich, was die vom Nutzer wahrgenommene Leistung steigert [Garlan und Shaw, 1993], als auch die individuelle Adaption von Komponenten, da nicht auf wechselseitige Abhängigkeiten geachtet werden muss. Einige Nachteile sind lange Laufzeiten bei großen Pipelines (Propagation Delay), die sequentielle Stapelverarbeitung, falls Filter keine inkrementelle Bearbeitung ihrer Inputs zulassen (Batch Sequential Processing), sowie das Fehlen jeglicher Interaktivität [Fielding, 2000]. Tabelle 2.1 zeigt die Unterstützungsmatrix wesentlicher Eigenschaften der Pipelinestile, die in [Fielding, 2000] genauer diskutiert wird. Net. Perform. UP Perform. Efficiency Scalability Simplicity Arch. Stil PF ± UPF - ± Evolvability Extensibility Customizability Configurability Reusability Visibility Portability Reliability Tab. 2.1: Eigenschaften pipelinebasierter Architekturstile [Fielding, 2000] Adaptivität Der Begriff der Adaption, gleichbedeutend mit Adaptation 3 zerfällt in die Teilbereiche Adaptierbarkeit und Adaptivität. Adaptierbarkeit, auch Makro-Adaption, beschreibt die Möglichkeit, 3 Ad ap ta ti on, die; -,-en 1.Anpassungsvermögen [..] 3. Bearbeitung, Umarbeitung eines Kunstwerks, Neubearbeitung in einer anderen Gattung [Langenscheidt, 2006]) Copyright TU Dresden, Stefan Pietschmann 10 von 82

17 2. Adaptive Web-Systemarchitekturen ein System bzw. eine Anwendung durch externe Eingriffe an veränderte Bedingungen anzupassen. Adaptivität, auch Mikro-Adaption genannt, bezeichnet hingegen die Fähigkeit eines Systems, sich selbstständig anzupassen. In der Forschung wird Adaptivität - insbesondere im Internet - aus zwei verschiedenen Blickwinkeln betrachtet. Zum einen gibt es die Sicht der adaptive Hypermedia [Brusilovsky, 1996, 2001], bei der das Augenmerk auf den Inhalten und deren Präsentation liegt. Bei Arbeiten, wie auch der vorliegenden, aus dem Bereich adaptiver Software stehen hingegen softwaretechnische Probleme im Vordergrund, d. h. die Adaption der Software an sich. Natürlich gibt es zwischen beiden Gebieten viele, insbesondere begriffliche, Überschneidungen. Eine sehr detaillierte Begriffsbestimmung von Adaptivität bzw. Adaptierbarkeit findet sich in [Klamar, 2004] Adaptionsziele In Abschnitt werden diverse Fallbeispiele vorgestellt, die den Nutzen adaptiver Architekturen motivieren. Hinter all den Beispielen verbergen sich letztendlich vier wesentliche Gründe, ein System adaptiv zu gestalten. Drei davon wurden zuerst von Ghezzi et al. [1991] unterschieden und später von Ketfi et al. [2002a] um einen vierten Punkt ergänzt: Korrektive Adaption Ziel dieser Art der Adaption ist die Beseitigung von Fehlern. Tritt in einer Anwendung ein unerwünschtes Verhalten auf, wird die verantwortliche Komponente gesucht und durch eine neue, funktionierende Version ersetzt. Diese besitzt exakt die gleiche Funktionalität wie die fehlerhafte Komponente. Adaptive Adaption Kommt es zu Veränderungen des Umfelds, kann sich die Anwendung an die neuen Gegebenheiten anpassen. Eine korrekt funktionierende Anwendung reagiert also auf Veränderungen im Ausführungskontext. Bei webbasierten Anwendungen kann hier zusätzlich zwischen dem Client- und Serverkontext unterschieden werden. Während Ersterer das clientseitige Umfeld beschreibt, z. B. die Auflösung auf dem Endgerät, spiegelt der Zweite das Umfeld auf der Serverseite wider, beispielsweise die momentane Auslastung des Servers. Veränderungen in beiden Kontexten können Auslöser für adaptive Adaptionen sein. Perfektive Adaption Die perfektive Adaption dient der Verbesserung einer ordnungsgemäß funktionierenden Anwendung. Sie kann in Form von Optimierungen eines Algorithmus zur Leistungssteigerung, oder der Vervielfältigung einer Komponente zur Kompensation erhöhter Anforderungen erfolgen. Erweiternde Adaption Um auf neue Erfordernisse oder Bedürfnisse der Nutzer eingehen zu können, ist es erforderlich, Anwendungen um Funktionalität zu bereichern, die zum Entwicklungs- bzw. Einsatzzeitpunkt noch nicht benötigt oder geplant war. Dies geschieht durch die erweiternde Adaption. Sie ist die Triebfeder des Evolutionary Computing, welches die kontinuierliche Weiterentwicklung von Software zur Laufzeit zum Ziel hat Adaptionscharakteristika Bei der Beschreibung von Adaption können unterschiedliche Aspekte betrachtet werden, nämlich wer, was, wann, wie, woran und warum anpasst. Je nach der individuellen Konstellation der Antworten, die ein System auf diese sechs W s hat, setzt es verschiedene Arten Copyright TU Dresden, Stefan Pietschmann 11 von 82

18 2. Adaptive Web-Systemarchitekturen von Adaptierbarkeit oder Adaptivität um. Die einzelnen Kombinationsmöglichkeiten sollen hier jedoch nicht im Detail durchgespielt werden. In Kapitel werden die Ergebnisse der vorliegenden Arbeit bezüglich dieses Schemas eingeordnet. Wer nimmt die Adaption vor? (Adaptionssubjekt) In Abhängigkeit u. a. vom Adaptionsgrad führt entweder der Programmierer, der Übersetzer, der Anwender oder die Architektur selbst die Anpassung durch. Einfach formuliert nimmt bei adaptiver Software die Software selbst die Adaptionen vor, bei adaptierbarer Software ist der Mensch das Adaptionssubjekt. [Klamar, 2004] Was wird adaptiert? (Adaptionsobjekt) Hier ist zu unterscheiden, welcher Teil eines Systems angepasst wird. Dabei kann es sich um Architektur, Inhalte oder Kommunikation bzw. die Interaktion mit dem Nutzer [Klamar, 2004] handeln. Häufig hängt die Wahl des Adaptionsobjektes von der Motivation ab. Warum wird adaptiert? Es gibt vielfältige Gründe für Adaptionen, die sich aus der Motivation (Kap ) und den Adaptionszielen (Kap ) ergeben. Wann wird Adaption vorgenommen? Der Adaptionszeitpunkt (Kap ) und auch die Häufigkeit von Adaptionen sind keine trivialen Aspekte, da die getroffene Entscheidung in großem Maße die Art, Flexibilität und Performanz des entstehenden adaptiven Systems beeinflusst. Wie wird die Adaption umgesetzt? Adaptivität in Software kann zunächst natürlich nach den verwendeten Adaptionsmethoden & -techniken (Kap. 2.5) unterschieden werden. Daneben gibt es eine Reihe weiterer Aspekte, wie z. B. den Grad der Autonomie (manuelle, teiloder vollautomatische Adaption), die das Wie charakterisieren. Woran wird adaptiert? Adaption wird immer durch Veränderungen von Parametern ausgelöst, an die sich das System anpasst. Diese Auslöser (Kap ) bestimmen, ob und wie die Adaption durchgeführt wird. Die vorgestellte Form der Charakterisierung von Adaption stellt nicht den einzigen Ansatz der Forschung dar. Stellvertretend sei hier der stark formalisierte Ansatz aus [Klamar, 2004] genannt, der auf den Ergebnissen von Subramanian und Chung [2002] aufbaut Dynamisch adaptive Softwarearchitektur Dynamische Adaptivität in Softwaresystemen ist kein neues Phänomen. Der Bedarf und Nutzen von dynamisch veränderbarer Software wurde bereits frühzeitig erkannt. So beschrieb bereits Fabry [1976] ein System, dessen Komponenten zur Laufzeit verändert werden können. Solche Systeme werden als dynamische Softwarearchitekturen bezeichnet. Je nach Motivation und Adaptionsziel spricht man von Dynamik [Bradbury et al., 2004], Laufzeit-Evolution oder auch Laufzeit-Adaption. Häufig ist es nicht praktikabel, die Adaptionen durch den Entwickler selbst initiieren zu lassen, wie dies beispielsweise in ArchShell [Oreizy, 1996] über die Kommandozeile geschieht. Viel häufiger werden selbst-verwaltete Architekturen benötigt, die nicht nur dynamisch interne Veränderungen umsetzen können, sondern diese auch eigenständig initiieren und planen. Beispiele solcher Architekturen sind programmierte Dynamik [Endler, 1994], selbst-organisierte Architekturen [Magee und Kramer, 1996b; Georgiadis et al., 2002], selbst-reparierende Systeme [Schmerl und Garlan, 2002] und selbst-adaptive Software [Oreizy et al., 1999]. Im Zuge dieser Arbeit liegt der Fokus auf selbst-adaptiven Systemen. Viele der betrachteten Anforderungen, Methoden und Techniken gleichen sich jedoch auf allen Gebieten. Copyright TU Dresden, Stefan Pietschmann 12 von 82

19 2. Adaptive Web-Systemarchitekturen Von der DARPA wird selbst-adaptive Software wie folgt beschrieben [Laddaga und Robertson, 2004]: Selbst-adaptive Software bewertet ihr eigenes Verhalten und ändert es, wenn die Bewertung zeigt, dass die Software nicht umsetzt, wofür sie entworfen wurde, oder wenn Verbesserungen der Funktionalität oder Leistung möglich sind. Dies bedeutet, dass es Mechanismen zur Überwachung des Verhaltens, zur Evaluation und zur Rekonfiguration geben muss. Es impliziert auch die Reflexivität des Systems, denn es muss Wissen über die eigene Funktionsweise und Struktur besitzen, um diese verändern zu können. Doch nicht nur das Verhalten, auch die Umgebung der Anwendung kann aufschlussreich für deren Adaption sein. Selbst-adaptive Software sollte sich demnach auch in Folge von Ereignissen in seiner Betriebsumgebung ändern [Oreizy et al., 1999]. Diese schließt alles Beobachtbare ein, wie Eingaben des Nutzers, Informationen über dessen Hard- und Softwaresystem, aber auch das eigene System und Verhalten. In dieser Arbeit werden solche selbst-verwalteten Architekturen auch als adaptive Architekturen bezeichnet, da im Wesentlichen die Anpassung an kontextuelle Veränderungen im Mittelpunkt steht. Erfolgt die Adaptionsinitiative von außen, also beispielsweise vom Nutzer, so verwendet dieser ein (dynamisch) adaptierbares System. Der Begriff adaptives System impliziert somit auch, dass es sich um dynamische Adaptivität handelt, da sich eine Anwendung nur zur Laufzeit selbst anpassen kann. Verschiedene Aspekte und Anforderungen adaptiver Software werden in den folgenden Abschnitten beleuchtet. 2.2 Motivation, Forschungsgebiete und Einsatzszenarien adaptiver Software Im folgenden Abschnitt sollen kurz Sinn und Notwendigkeit adaptiver Software dargelegt, und einige Forschungsgebiete und Einsatzszenarien vorgestellt werden, die sich mit der Entwicklung solcher Architekturen beschäftigen bzw. davon profitieren Motivation Mit der Etablierung objektorientierter Programmierung und der zunehmenden Komplexität moderner Software verschob sich in den 1990er Jahren der Schwerpunkt der Softwareentwicklung zu komponentenbasierten Systemen. Das Programmieren von Code wurde durch das Component Based Software Engineering (CBSE) unter Nutzung fertiger Off-The- Shelf-Komponenten abgelöst. Durch das Zusammensetzen von Anwendungen aus diesen unabhängigen Bausteinen wird die Entwicklung vereinfacht und die Flexibilität und Zuverlässigkeit solcher Systeme erhöht [Heineman und Councill, 2001]. Des Weiteren ermöglicht es die unabhängige Wiederverwendung der einzelnen Bausteine. Dies macht jedoch deren Konfiguration entsprechend den jeweiligen Gegebenheiten notwendig, d. h. Komponenten müssen der Umgebung angepasst werden, in der sie eingesetzt werden. Doch nicht nur diese offensichtlichen Vorteile, auch der Nutzen für die dynamische Weiterentwicklung, d. h. die Verbesserung und Erweiterung des Funktionsumfangs kritischer Systeme zur Laufzeit, wurde mit der Zeit deutlich. Deren Verfügbarkeit wird durch die Downtime zur Wartung bestimmt. Die normale Wartungsprozedur - das Herunterfahren, Installieren und Neustarten - kann jedoch durch dynamische Rekonfiguration verhindert werden [Almeida et al., 2001a; Endler, 1994; Kramer und Magee, 1985, 1990; Moazami-Goudarzi, 1999; Oreizy et al., 1998; Wermelinger, 1999]. Nicht allein auf dem Gebiet von Sicherheits- und anderen Copyright TU Dresden, Stefan Pietschmann 13 von 82

20 2. Adaptive Web-Systemarchitekturen kritischen Systemen erwies sich ein gewisses Maß an Adaptivität als unabdingbar. In den letzten Jahren entwickelte sich auch ein Bewusstsein für den Nutzen adaptiver Architekturen zur Anpassung an den Nutzer und dessen Umfeld [Oreizy, 1996]. Insbesondere die rasante Entwicklung des Internets von einem Kommunikations- und Browsinginstrument hin zu einer Infrastruktur für verschiedenste Dienstangebote [Abdelzaher und Bhatti, 1999b] verstärkt die Notwendigkeit adaptiver Systeme. Web-Anwendungen und -Servern kommt eine Schlüsselrolle im Internet der Zukunft zu, was von ihnen ein gewisses Maß an Dienstqualität, Verlässlichkeit und Sicherheit verlangt. Huitema [2000] zufolge sind 40% der Verzögerungen im Web auf Web-Server zurückzuführen, und die Last auf Web-Server wird sich - Moore s Law und Gilder s Law folgend 2 - zunehmend erhöhen. Damit entwickelt sich die Optimierung bzw. Performanzverbesserung von Web-Servern zu einem entscheidenen Kriterium, um die Zufriedenheit von Nutzern zu verbessern. Im mobilen Umfeld sehen sich Systeme außerdem mit stark heterogenen Netzen und Endgeräten konfrontiert. Betrachtet man die Entwicklung hin zu vernetzten bzw. verteilten, umgebenden (engl. ubiquitous) und verschwindenden Systemen, so ist die dynamische Rekonfiguration bzw. Adaption zweifellos der Schlüssel zum Erfolg zukünftiger Software. 4 Nur so werden sich robuste Anwendungen für eine Vielzahl von Endgeräten unterschiedlicher Größe, Rechenleistung und Ressourcen in unzuverlässigen drahtlosen Netzwerken realisieren lassen. Aber auch für normale Anwendungen liegt der Nutzen auf der Hand. Diese sollen auf einer Vielzahl von Endgeräten mit gänzlich unterschiedlichem Angebot an Rechenleistung, Kommunikation und Speicherplatz ausgeführt werden können. Dazu bedarf es sog. ressourcenbewusster Anwendungen, die proaktiv die Ressourcennutzung der zugrunde liegenden Plattform überwachen, und sich dynamisch wechselnden Ressourcencharakteristika anpassen. Zwar stellen Betriebssysteme und Middleware vermehrt Mechanismen zur Überwachung und optimalen Ausnutzung von Ressourcen bereit [Mercer et al., 1994; Goyal et al., 1996; Jones et al., 1997], doch selbst dann muss die Anwendung zumindest auf die festgestellten Änderungen reagieren können (application-aware adaptation [Satyanarayanan et al., 1995]). Die zentralen Herausforderungen, denen sich Entwickler von Web-Anwendungen in Zukunft stellen müssen, sind demnach: 1. Leistungsoptimierung und Lastreduktion 2. Unterstützung von Quality of Service (QoS), d. h. Einhaltung von QoS-Zusagen bezüglich Ausfallsicherheit, Response Time u. v. m., sowie auch in Form differenzierten Hostings (pay-per-qos). 3. Anpassung an den Kontext, d. h. Adaption an heterogene Nutzer, Endgeräte und sonstige Systemparameter. Um diese Aufgaben zu erfüllen, gibt es drei generelle Ansätze: 1 die Skalierung, 2 die Verteilung und 3 die dynamische Anpassung des Systems. Während die ersten beiden Ansätze zusätzliche Ressourcen bereitstellen, was nicht zuletzt die Finanzen und das Netzwerk belastet, versucht der dritte Ansatz, mit den bestehenden Mitteln das System optimal zu nutzen. In dieser Arbeit liegt der Fokus auf Ansatz 3, dessen Umsetzung bisher hauptsächlich durch die folgenden Techniken erfolgte: Anpassung von Inhalten und Linkstruktur (adaptive Hypermedia), entweder dynamisch [Hinz, 2002] oder durch das Umschalten zwischen vorverarbeiteten Inhalten [Abdelzaher und Bhatti, 1999b], auf Basis von Nutzermodellen, Zugriffsmustern [Perkowitz und Etzioni, 1999], Endgeräteprofilen etc. 4 Mit den anstehenden Problemen der Bereiche Mobile und Ubiquitous Computing beschäftigen sich u. a. Duchamp [1992] und Weiser [1993]. Copyright TU Dresden, Stefan Pietschmann 14 von 82

21 2. Adaptive Web-Systemarchitekturen Anpassung der Präsentation [Hinz, 2002]; Anpassung von Requests, beispielsweise über Proxies [Amberg et al., 2003]; Unterschiedliche Gewichtung von Clients mittels Service Differentiation [Abdelzaher und Bhatti, 1999b] bzw. Request Prioritization/Scheduling [Almeida et al., 1998; Vasiliou und Lutfiyya, 2001] je nach Nutzer oder angeforderten Inhalten; Data Prefetching [Banâtre et al., 1997]; Auslagerung von Komponenten auf den Client [Hinz und Fiala, 2005b]; Automatische Komposition und Minimierung der benötigten Menge an Komponenten [Wils et al., 2003]; sowie Admission Control 5 (Zugangskontrolle) und Congestion Control (Flusskontrolle/ Überlastungssteuerung) auf der Netzwerkebene. Viele der verwendeten Lösungen bringen jedoch Probleme mit sich. So lässt sich die Leistung eines Web-Servers eben nur bedingt durch alternative Inhalte beeinflussen, die zudem a priori verarbeitet werden müssen und dadurch Speicherplatz kosten. Auch die admission control muss mit Bedacht eingesetzt werden, da sie dem Nutzer - ohne für ihn ersichtlichen Grund - Dienste verweigert. Zudem geht für den Kommunikationsprotokollstack viel Leistung verloren [Abdelzaher und Bhatti, 1999b]. So stellt letztlich keine dieser Techniken die ideale Lösung der o. g. Probleme dar. Innerhalb der letzten zehn Jahre ist verstärkt die Anpassung an den Nutzer und sein Endgerät, d. h. die ersten drei Techniken, in den Mittelpunkt der Entwicklung webbasierter Systeme gerückt. Nicht mehr nur die Ressourcen, sondern der gesamte technische und soziale Kontext ist von zunehmender Bedeutung für die dynamische Anpassung von Inhalten und Linkstruktur bis hin zur Umwandlung in verschiedenste, vom Endgerät unterstützte Formate [Smith et al., 1998; Zhijun und Georganas, 2001]. Ein einfaches Beispiel dafür ist die dynamische Auswahl des Distillers durch das System, je nach nach Bandbreite, Hard- und Software des Clients [Fox et al., 1996, 1998]. Durch die Vielzahl von Adaptionen entsteht jedoch auch eine große Menge spezifischer Systemkomponenten, von denen der größte Teil nicht ständig benötigt wird bzw. auf den Client ausgelagert werden könnte. Die Auswahl, Konfiguration und Verlagerung der benötigten Komponenten unter Berücksichtigung aller kontextueller Informationen kann nur durch eine adaptive Architektur erfolgen. Der Erfolg einer Web-Anwendung hängt davon ab, ob sie dem Nutzer konsistente, vorhersehbare, rechtzeitige und verlässliche Dienste, trotz Schwankungen und Unzulänglichkeiten des Umfelds, bieten kann [Gu et al., 2001]. Dies kann nur mit einer Softwarearchitektur erfolgen, die sich dynamisch den Veränderungen ihres Umfelds anpassen kann [McCann et al., 2003]. Zudem nimmt die Relevanz auf den Nutzer zugeschnittener Anwendungen stark zu. Diesem Trend kann nur durch die Zusammenarbeit von Dokument- und Architekturadaption in geeigneter Weise begegnet werden. Auch für die zunehmende Last auf Web-Server stellen adaptive Softwarearchitekturen eine Lösung dar, da, wie bereits in verschiedenen Projekten belegt wurde, mit ihrer Hilfe signifikante Leistungssteigerungen erreicht werden können [Chang und Karamcheti, 2000]. Viele zukünftige Aufgaben von (Web-)Anwendungen können also nur von kontextsensitiven, dynamisch adaptiven Softwarearchitekturen in vollem Maße erfüllt werden. 5 Admission Control bezeichnet einen Mechanismus in einem QoS-bewussten Netzwerk, welcher das QoS-Level eines neuen Nutzers einschätzt und daraufhin dessen Session in Abhängigkeit von den zur Verfügung stehenden Ressourcen zulässt oder nicht. Die verbreitetste Methode ist die Capacity Based Admission Control (CAC) [Sheldon, 2001]. Copyright TU Dresden, Stefan Pietschmann 15 von 82

22 2. Adaptive Web-Systemarchitekturen Einsatzbereiche und Forschungsgebiete dynamisch adaptiver Software Von dynamischer Adaptivität profitieren zum einen Systeme, die sich kurzfristig bzw. schnell ändernden Gegebenheiten anpassen müssen (wie im Mobile Computing), und zum anderen Anwendungen, die sich langfristigen, langsamen Veränderungen gegenüber sehen und nicht gestoppt werden können oder sollen, wie Banken-, Sicherheits- oder Überwachungssoftware [Oreizy, 1996]. Dynamische Adaptivität kann auch als nützliches Debugging Werkzeug zum Einfügen experimentellen oder überwachenden Quellcodes eingesetzt werden [Redmond und Cahill, 2002]. Je nach Ziel der Adaption nutzt ein System seine Dynamik zur Evolution, Adaption (engl. adaptation), oder Anpassung (engl. customization) 6. Diese sind, je nach Anwendungsdomäne, recht unterschiedlich. Der Einsatz adaptiver Architekturen ist heutzutage in fast jedem Bereich vielversprechend. Natürlich besteht insbesondere im Distributed und Mobile Computing, d. h. bei mobilen, verteilten Anwendungen, aufgrund der heterogenen, ständig wechselnden Umgebung ein Bedarf daran. Auch der Paradigmenwechsel hin zum verschwindenden Rechner (Ubiquitous bzw. Pervasive Computing), der den Nutzer bei seinen täglichen Aufgaben möglichst unauffällig und ohne Ablenkung unterstützt, macht adaptive Architekturen erforderlich. Die nötige Unterstützung kann nur durch ständige Verfügbarkeit und Anpassung an alle möglichen Kontextinformationen geboten werden - schließlich ist die Welt kein Desktop [Weiser, 1994]. Weitere Felder, in denen adaptive Systeme eingesetzt werden, sind Embedded Software [Laddaga und Robertson, 2004] für Robotik, Konstruktions-, Kontroll- und Sensorsysteme, Bild- und Signalverarbeitung [Robertson und Laddaga, 2004] u.v.m. Auf dem Gebiet adaptiver Systeme selbst haben sich unterschiedliche Forschungsfelder aufgetan. Die Ansätze auf dem Gebiet des Post-Deployment Configuration Management (PDCM) widmen sich der nachträglichen Konfiguration bereits eingesetzter Systeme [Heimbigner und Wolf, 1996]. Ziel des Autonomic Computing ist es hingegen, dass sich Systeme vollkommen selbstständig verwalten können [Oreizy et al., 1999]. Die vier funktionalen Bereiche der Vision eines autonomen Systems bestehen laut Kephart und Chess [2003] in der Selbstkonfiguration, Selbstoptimierung, Selbstheilung und dem Selbstschutz. Der letzte Punkt ist von zentraler Bedeutung für Survivable Systems, in denen mit Hilfe von Adaption die Vertrauenswürdigkeit von Software in feindlichen Umgebungen sichergestellt wird [Shrobe und Doyle, 2001]. In diesem Umfeld ist auch keine Wartung - die längste und teuerste Phase des Software- Lebenszyklus - mehr möglich. Das Evolutionary Computing beschäftigt sich daher mit der Verschiebung von Evolutionstechniken von der Entwurfs- zur Laufzeit, und den dadurch entstehenden Problemen [Lüer et al., 2001]. So gibt es noch viele weitere, nicht zwingend disjunkte, Forschungsfelder in diesem Bereich Beispielszenarien adaptiver Architekturen Im Folgenden soll anhand einiger Beispiele gezeigt werden, wie Systeme von adaptiven Architekturen profitieren können. Die Häufigkeit der Ausführung einer Komponente wird bei hoher Serverlast beschränkt, beispielsweise muss die Benutzermodellierung nicht mit jedem Request erfolgen. Beim Request eines Administrators werden zusätzliche Komponenten ausgeführt, die der Response Informationen über das System hinzufügen. 6 Leider entsprechen die englischen Begriffe adaptation und customization beide dem deutschen Begriff Anpassung. Ersterer bedeutet, dass ein Entwickler eine Komponente, z. B. durch Hinzufügen von Code, an ein spezielles Umfeld anpasst. Stellt ein Endanwender eine Anwendung durch Auswahl von Optionen auf seine Bedürfnisse ein, so ist dies customization. Copyright TU Dresden, Stefan Pietschmann 16 von 82

23 2. Adaptive Web-Systemarchitekturen Bei niedrigem Batteriestand eines PDA-Clients wird auf die Einbindung eines Java Applets in die Ausgabe verzichtet. Bei der adaptiven Dokumentgenerierung werden nur die benötigten Komponenten ausgeführt. So kann auf das Location Modeling für Desktop-Clients verzichtet werden, da sich deren Standort nicht verändert. Im Falle eines Eindringlings oder Bezahl-Dienstes wird automatisch eine Verschlüsselungskomponente in die Verarbeitung eingefügt. Ein Audio/Videostream passt sich dynamisch der schwankenden Bandbreite an, z. B. durch das Umschalten von einem MPEG-2 auf einen H.263 Codec [Batista et al., 2005]. Ist das parallele Senden beider Ströme nicht mehr möglich, oder aufgrund eines clientseitig fehlenden Codecs nicht sinnvoll, so wird automatisch auf Audio umgestellt [Chatterjee, 1999]. Auch der Audiostrom kann natürlich Parametern wie der Bandbreite, der Anzahl verlorener Pakte oder der Ende-zu-Ende-Verzögerung angepasst werden [Ramdane-Cherif und Levy, 2002]. Die Qualität von Bildern kann - bei offensichtlichem Interesse (z. B. bei häufigem Aufruf) - automatisch erhöht werden [Mukhija und Glinz, 2004] bzw. direkt eine Anpassung der Wavelet-basierte Kodierung erfolgen [Servetto et al., 2000]. Ein System passt in Abhängigkeit der Menge an freiem Speicher die Größe seines Caches an [David und Ledoux, 2003]. Diese und die bereits in Kapitel 1.1 genannten Beispiele verdeutlichen die Vielzahl an Möglichkeiten und Vorteilen, die der Einsatz adaptiver Architekturen bietet. 2.3 Ausgewählte Aspekte adaptiver Architekturen Auslöser für Adaptionen Basis jeglicher Adaptivität ist das Kontext-Bewusstsein. Nur in Relation zu den Informationen über sich und seine Umgebung kann ein System sich selbst in Frage stellen und sein Verhalten anpassen (context-awareness). Die Umgebung bzw. der Kontext umfasst dabei alles vom System Beobachtbare - man spricht von kontextabhängiger bzw. situationsabhängiger [Amberg et al., 2003] Adaption. In [Hitz et al., 2002] erfolgt eine Unterscheidung des Situationsbegriffs zwischen natürlichem (Ort, Zeit), technischem (Browser, Netzwerk, Endgerät) und sozialem Kontext (Nutzereigenschaften und -verhalten). Bei der Adaption Client-Server-basierter Anwendungen kann in bestimmten Bereichen nochmals unterschieden werden, ob sich die Informationen auf den Server oder den Client beziehen. Speziell der technische Kontext ist sowohl serverseitig (Auslastung) als auch clientseitig (Unterstützung technischer Aspekte) von Belang. Die drei Kontextarten werden nun kurz dargelegt. Natürlicher Kontext Besonders bei mobilen Anwendungen bzw. Endgeräten ist der Ort des Clients eine wichtige Adaptionsgrundlage (LBS). Zunehmend gewinnen aber auch andere Parameter des natürlichen Umfelds des Clients an Bedeutung [Schmidt et al., 1999]. Beispielsweise können Zeit, Lichtverhältnisse, Helligkeit, Lautstärke oder Temperatur von einem adaptiven System zur Anpassung einbezogen werden. Serverseitig spielt der natürliche Kontext als Adaptionsgrundlage nur eine untergeordnete Rolle. Hier ist u. U. die Zeit von Interesse, um Anpassungen an vordefinierte Spitzenzeiten zu vollziehen. Copyright TU Dresden, Stefan Pietschmann 17 von 82

24 2. Adaptive Web-Systemarchitekturen Technischer Kontext Der technische Kontext umfasst alle messbaren Systemeigenschaften und ist sowohl client- als auch serverseitig elementar für die Adaption. In der bisherigen Forschung spielten vor allem Ressourcen eine wichtige Rolle [Batista et al., 2005; Bharghavan und Gupta, 1997; Keleher et al., 1999; Mukhija und Glinz, 2004; Gorinsek et al., 2003; Oreizy, 1996; Rigole et al., 2004, u. v. m.], besonders jüngere Ansätze gehen jedoch darüber hinaus. In [da Silva e Silva et al., 2003] werden beispielsweise Interaktionen zwischen Objekten überwacht, in [Schmerl und Garlan, 2002] die Funktionsfähigkeit des Systems selbst, und in [Fox et al., 1996, 1998] die Unterstützung von Bildformaten durch das Endgerät. Sozialer Kontext Der wesentliche Kontext auf der Clientseite ist der soziale. Er umfasst Eigenschaften, Vorlieben und Verhaltensmuster von Anwendern, die meist in Nutzerprofilen gespeichert werden. Die Adaption an den sozialen Kontext war lange Zeit das fundamentale Prinzip von adaptive Hypermedia, denn dort erfolgte vor allem die Anpassung von Inhalten an den Nutzer. Diese Beschränkung auf den sozialen Kontext nimmt allerdings zunehmend ab. In [Kobsa et al., 2001] wird die Anpassung sowohl an Nutzer-, Nutzungs- als auch Umgebungsdaten propagiert. Somit rücken verstärkt Aspekte wie Endgeräteunabhängigkeit und Location Based Services (LBS) in den Bereich der adaptive Hypermedia. Gerade dies impliziert jedoch die Notwendigkeit und den Einsatz von Architekturadaption zu deren Unterstützung. Zusammenhang Die oben erfolgte Aufteilung des Kontextbegriffs entspricht nach Auffassung des Autors einer schlüssigen Trennung verschiedener kontextueller Aspekte. Es sei jedoch darauf hingewiesen, dass es abweichende Meinungen gibt, wie die Auslöser adaptiver Rekonfiguration in Systemen zu benennen sind, bzw. was genau der Kontext umfasst. In [Klamar, 2004] werden beispielsweise Einsatzumgebung, Betriebsumgebung und Kontext unterschieden. Für Capra et al. [2001b] besteht context-awareness aus device- und environment-awareness (Endgeräteund Umgebungs-Awareness). Die soziale Komponente wird offensichtlich ausgeklammert, da sie mutmaßlich für adaptive Architekturen weniger bedeutsam ist. Die Trennung zwischen client- und serverseitigem Kontext ergibt sich folgerichtig aus der Betrachtung adaptiver Web-Systeme. Sie ist vergleichbar mit der Unterscheidung von generischen und typspezifischen Ressourcen in [Noble et al., 1995]. Generische Ressourcen beziehen sich auf globale Elemente, wie Speicherplatz, die für alle Nutzer gleich sind. Es handelt sich also um Parameter des Serverkontextes. Typ-spezifische Ressourcen hingegen gelten nur in einem bestimmten Kontext, wie die Anzahl der Anfragen je Abonnement pro Client. Sie sind abhängig von der Session bzw. dem Nutzer und können somit dem Clientkontext zugeordnet werden. Auch die Unterscheidung zwischen (anwendungs-)internen und externen Auslösern aus [David und Ledoux, 2003] ist ein interessanter Ansatzpunkt. Eine genaue Betrachtung des Kontextbegriffs, seiner Definitionen, Teilaspekte und Kategorien nehmen beispielsweise Dey und Abowd [1999] vor. Zur Überwachung der unterschiedlichen Kontextarten muss ein adaptives System die passenden Mechanismen bereitstellen. Im Fall von AMACONT geschieht die Überwachung aller clientseitigen Parameter durch das bestehende Context Modeling Framework [Hinz und Fiala, 2005a]. Serverseitige Parameter werden bisher nicht vom System erfasst. Sinnvoll wäre beispielsweise die Überwachung von Bandbreite und Latenzzeit des Netzwerks, Cachegröße, Prozessorstärke oder auch anfallenden Kosten bei Bezahlmodellen [Noble et al., 1995]. Copyright TU Dresden, Stefan Pietschmann 18 von 82

25 2. Adaptive Web-Systemarchitekturen Anforderungen an adaptive Systeme In dynamisch adaptiven Systemen laufen eine Reihe zusätzlicher Prozesse ab, die die Adaptivität zur Laufzeit ermöglichen und deren reibungslose Funktion sicherstellen (Abb. 2.2). Auf einige wesentliche Aufgaben und Anforderungen wird im Folgenden näher eingegangen. Abb. 2.2: High-level Prozesse und Aufgaben in selbst-adaptiven Systemen [Oreizy et al., 1999] Entkopplung von Adaptions- und Anwendungslogik Die Einbettung der Adaptionslogik in die Anwendung führt zu erhöhter Komplexität und schlechter Wiederverwendbarkeit sowohl der Komponenten als auch der Adaptionsmechanismen. Deshalb ist - dem Prinzip der Separation of Concerns [Hürsch und Lopes, 1995] folgend - generell eine möglichst große Unabhängigkeit von Adaptions- und Anwendungslogik erwünscht, da die Adaption an einen spezifischen Ausführungskontext und dessen Entwicklung [..] ein Anliegen [ist], das getrennt von der restlichen Anwendung behandelt werden muss [David und Ledoux, 2003]. Diese Trennung der Verantwortlichkeiten ermöglicht, dass Anwendungs-, Komponenten- und Adaptionsprogrammierer unabhängig voneinander arbeiten können. Der Entwickler einer Anwendung kann sich auf die Anwendungslogik konzentrieren, ohne auf nicht-funktionale Zwänge, wie Charakteristika oder Beschränkungen des Endgerätes, Rücksicht nehmen zu müssen. 7 Dies ist allein die Aufgabe der Adaptionsmechanismen, welche meist kontext- bzw. domainunabhängig, und damit wiederverwendbar sind. Diese Wiederverwendbarkeit erlaubt wiederum die einfache Veränderung der Adaptionslogik, beispielsweise um sie zu erweitern, zu optimieren oder die Adaptionsstrategie zu ändern. Durch die Separierung der Adaptionsinfrastruktur kann diese auch parallel von mehreren Anwendungen gleichzeitig genutzt werden (z. B. in Form von Shared Monitoring), womit eine gezielte Einsparung von Ressourcen einhergeht. Auch innerhalb des adaptiven Subsystems ist die Separation of Concerns (SoC) von Bedeutung: Häufig findet eine klare Trennung zwischen den Überwachungskomponenten, deren Analyse und Auswertung von Bedingungen, und der eigentlichen Architekturadaption statt [Dowling und Cahill, 2001]. Dadurch können einzelne Teile, wie die Rekonfiguration selbst, 7 In diesem Zusammenhang wird oft von der Anwendungstransparenz gesprochen, die es dem Entwickler erlaubt, unabhängig von Problemen wie der Heterogenität und der Verfügbarkeit von Ressourcen zu arbeiten. Copyright TU Dresden, Stefan Pietschmann 19 von 82

26 2. Adaptive Web-Systemarchitekturen auf die Seite der Anwendung verlagert werden. Diese hat dann die Möglichkeit, die Adaptionsstrategie selbst zu bestimmen, während das adaptive Subsystem die Überwachung, Analyse und Adaptionsentscheidung vornimmt (vgl. [Capra et al., 2001b,a]). Einige vielversprechende Ansätze nutzen für diese Trennung einen aspektorientierten Ansatz (AOP) [Yang et al., 2002; David und Ledoux, 2003]. Für adaptive Systeme ist es zudem von Vorteil, wenn nicht nur die Adaptions-, sondern auch die Ablauflogik (engl. Processing Logic) von der Anwendung getrennt wird [Wang und Scardina, 2002]. Für deren Definition eignet sich besonders ein XML Format, da es ausreichende Möglichkeiten zur Repräsentation der Logiken bietet, standardkonform und einfach zu verstehen, zu validieren und zu erweitern ist. Beispiele für solche Sprachen sind die XPL (siehe Kap ), die darauf aufbauende Framework Control Markup Language (FCML) [Wang und Scardina, 2002] oder Cocoon s Sitemap (Kap ). Die Separierung der Ablauflogik, die zur Laufzeit interpretiert wird, kann die Anpassung einer Architektur u. U. erheblich vereinfachen, beispielsweise indem nur die XML-Datei umgeschrieben werden muss (Abb. 2.3). Abb. 2.3: Trennung von System und Ablauflogik Konsistenz- und Integritätssicherung Die Rekonfiguration bzw. Adaption zur Laufzeit ist ein intrusiver Prozess [Moazami- Goudarzi, 1999] der ins laufende System eingreift und somit Interaktionen zwischen Komponenten des Systems stören kann. Alle dynamischen Veränderungen gefährden u. U. die Konsistenz und Systemintegrität, sodass es Mechanismen zu deren Sicherstellung bedarf. Eine große Anzahl von Forschern, darunter Almeida et al. [2001b]; Moazami-Goudarzi [1999]; Kramer und Magee [1998] und Wermelinger [1999], hat sich mit dem Problem der Aufrechterhaltung von Konsistenz (engl. consistency preservation) während und nach Systemadaptionen beschäftigt. Eine Lösungsmöglichkeit besteht in der Definition von Schranken (engl. constraints). A posteriori Schranken werden nach der Adaption bzw. Rekonfiguration überprüft und im Falle ihrer Verletzung muss die Aktion rückgängig gemacht werden. Sind die Schranken als Vorbedingung, also a priori definiert, dann darf die Adaption nur durchgeführt werden, wenn die Bedingungen eingehalten werden. In diesem Zuge beschreiben Ketfi et al. [2002b] die Adaptierbarkeits-Relation als Menge von Annotationen zwischen Komponenten, die drei Dinge beinhalten: 1 Bedingungen, die für einen Übergang von Komponente A zu Komponente B erfüllt sein müssen, 2 ein Skript, welches die Abbildung von A nach B beschreibt und 3 Bedingungen bzw. Aktionen, die nach dem Ersetzen von A durch B durchgeführt werden müssen, beispielsweise die Ersetzung abhängiger Komponenten oder Überprüfung von a posteriori-schranken. Die Beschreibung dieser Schranken erfolgt gewöhnlich in einer ACL, auf die genauer in Kapitel eingegangen wird. Strukturelle Beschränkungen wurden zuerst von Magee und Kramer [1996b] als Grundlage Copyright TU Dresden, Stefan Pietschmann 20 von 82

27 2. Adaptive Web-Systemarchitekturen für selbst-adaptive Systeme vorgeschlagen und später von vielen Forschern genutzt, z. B. in [Minsky et al., 1996], oder als Basis für die Selbstreparatur von Systemen in Raven [Coatta und Neufeld, 1994] und [Schmerl und Garlan, 2002]. Auch die Tatsache, dass Systeme und deren Komponenten während der Laufzeit veränderliche Zustände annehmen können, ist ein wichtiger Aspekt, den es bei dynamischer Adaption zu beachten gilt. Zustandslose Komponenten können zur Laufzeit problemlos durch neue Versionen ersetzt werden, solange Syntax und Semantik ihrer Schnittstellen sich nicht verändern [Vandewoude und Berbers, 2002]. Ansonsten muss jedoch beim Ersetzen oder Verlagern von Komponenten dafür gesorgt werden, dass der alte Zustand von der neuen Version bzw. an neuer Stelle übernommen wird. Mit derartigen Problemen beschäftigen sich beispielsweise Chen et al. [2001] und Oreizy et al. [1998]. Neben verschiedenen Zuständen stellen auch Abhängigkeiten und die Kommunikation zwischen Komponenten ein Problem für dynamische Rekonfigurationen dar. Deshalb muss sichergestellt werden, dass während der Adaption Funkstille (engl. quiescence [Kramer und Magee, 1990]) herrscht, d. h. keine Interaktionen mit den betroffenen Komponenten stattfinden. Häufig wird ein transaktionales Modell zur dynamischen Rekonfiguration genutzt, wie in Olan [Balter et al., 1998] oder [Wermelinger, 1999]. Transaktionale Adaptionsansätze versuchen, die Konsistenz und Integrität einer Anwendung durch Einfrieren von Komponenten zu wahren [Kramer und Magee, 1990, 1998; Oreizy, 1996]. Dies kann sich jedoch negativ auf die Leistung des Systems auswirken. Bei Versuchen mit den Ansätzen Conic [Kramer und Magee, 1996] und Darwin [Kramer und Magee, 1998] kam man zu dem Schluss, dass es erforderlich ist, alle Komponenten, die mit einer Zielkomponente kommunizieren könnten, ebenfalls in einen passiven Zustand zu versetzen, um diese Möglichkeit zu unterbinden. Dies führt jedoch leicht dazu, dass große Teile einer Anwendung eingefroren werden, was beträchtliche Unterbrechungen verursacht. Zudem müssen aufwändige und langwierige Berechnungen u. U. zugunsten einer Rekonfiguration abgebrochen und später neu gestartet werden. Dies zieht wiederum den Abbruch abhängiger Transaktionen nach sich, und im schlechtesten Fall den Halt der gesamten Anwendung. Weitere, unerwünschte Übergangsprobleme, die beim Ersetzen von Komponenten auftreten können, behandelt [Simon et al., 2000]. Leistung und minimale Störung der Anwendung Der durch die Adaptionslogik hervorgerufene Overhead sollte möglichst minimal sein, insbesondere, da die Leistung des adaptiven Subsystems umso mehr an Bedeutung gewinnt, je häufiger Anpassungen stattfinden. Auch die Adaption selbst sollte möglichst effizient und schnell ablaufen, um die Anwendung nicht an ihrer Ausführung zu hindern. McCann et al. [2003] bemerken sehr richtig: There is no point in a system reacting to a problem so slowly that the system fails before it can do anything about it.ëin Ansatzpunkt dafür ist die Minimierung der Anzahl betroffener, d. h. zu adaptierender Komponenten durch das System. Der nicht betroffene Teil der Anwendung sollte seine Ausführung während der Rekonfiguration normal fortsetzen können [Almeida et al., 2001b]. Generische Funktionalität und Interoperabilität Ein adaptives System sollte generische Mechanismen zur Anpassung von Anwendungen über eine feste Schnittstelle zur Verfügung stellen. Dadurch wird es möglich, sie zusammen mit gemeinsamen Benutzermodellen und Adaptionsregeln für mehrere Anwendungen zu nutzen. Die Konzeption und Umsetzung muss deshalb unterschiedliche Ausführungsmodelle Copyright TU Dresden, Stefan Pietschmann 21 von 82

28 2. Adaptive Web-Systemarchitekturen (einfach oder nebenläufig), verschiedene Objekttypen (zustandslos oder zustandsbehaftet) usw. unterstützen [Almeida et al., 2001b]. Deklarative Beschreibung der Adaptionen Rekonfigurationen bzw. Adaptionen sollten außerhalb des Systems in deklarativer Form und unabhängig von den Algorithmen, Protokollen und Zuständen der Anwendung beschrieben werden [Kramer und Magee, 1990]. Diese Forderung verstärkt die Trennung der Verantwortlichkeiten von Adaptionslogik und Anwendung. Sie geht einher mit den Prinzipien der Konfigurationsprogrammierung [Kramer und Magee, 1998], die zwei getrennte Sprachen befürwortet: Eine Konfigurationssprache für die strukturelle Beschreibung und Adaptionslogik, und eine andere Programmiersprache zur Implementierung von Komponenten. Die Beschreibung der Veränderungen erfolgt also getrennt von der Anwendung auf der Konfigurationsebene. Neben der einfachen Administration und Lesbarkeit ist der große Vorteil der deklarativen Beschreibung, dass sie zur Laufzeit interpretiert, und damit auch einfach, dynamisch verändert werden kann. Weitere Anforderungen Es gibt noch eine Reihe weiterer Anforderungen, die sich zum Teil auch den genannten Forderungen unterordnen lassen, wie Flexibilität und Erweiterbarkeit. In [da Silva e Silva et al., 2003] fordern die Autoren von ihrem Framework zur Architekturadaption zusätzlich Mechanismen zur Koordination von Rekonfigurationsaktionen zwischen verteilten Komponenten und eine einheitliche Management-Schnittstelle zur Konfiguration und Adaption von Komponenten Adaptionszeitpunkt Man kann vier Zeitpunkte unterscheiden, zu denen Architekturadaption stattfinden kann (nach [Oreizy, 1996]): Design time Veränderungen finden am abstrakten Architekturmodell statt. Dieses wird danach mit dem verknüpften Quellcode zu einer Anwendung kompiliert. Pre-Execution Time Veränderungen finden nach der Kompilierung, aber vor der Ausführung statt. Da die Anwendung noch nicht läuft, spielen Aspekte wie Nebenläufigkeit oder Systemzustand keine Rolle. 8 Constrained Run-Time Veränderungen finden zur Laufzeit statt, nachdem bestimmte Vorbedingungen erfüllt sind. Diese können dafür sorgen, dass sich das System in einem sicheren Zustand für die Adaption befindet. Run-Time: Veränderungen werden ohne vorherige Beachtung von Systemzustand oder -topologie zur Laufzeit vollzogen. Nur bei den letzten beiden Kategorien kann man von dynamischer Adaptivität sprechen. Bei Systemen, die diese umsetzen, spielt die Häufigkeit der Adaptionen eine entscheidende Rolle, da diese schließlich nie ohne zusätzlichen Aufwand ablaufen. Zwei häufige Ansätze sind die Adaption 1 mit ungenutzter Prozessorzeit und 2 mit einem kontinuierlichen Anteil an Ressourcen. In [Lu et al., 1997] wird diesbezüglich ein interessanter Weg verfolgt: die rentable Adaption (engl. cost-effective adaptation). Um ständigen Adaptionen, ausgelöst durch 8 Diese Art der Änderung wird häufig in Form von Patches benutzt. Diese funktionieren allerdings nicht auf Modell-, sondern auf Byte-Ebene, was sie sehr fehleranfällig macht. Copyright TU Dresden, Stefan Pietschmann 22 von 82

29 2. Adaptive Web-Systemarchitekturen die kurzfristigen Fluktuationen im Kontext mobiler Anwendungen, vorzubeugen, legt das System die Kosten bzw. den Aufwand jeder Verarbeitung fest. Ein Algorithmus berechnet, ob die Kosten einer Adaption gedeckt sind - nur dann findet sie tatsächlich statt Regelungssystem Da adaptive, autonome Architekturen in Situationen ablaufen, die zum Zeitpunkt ihrer Entwicklung nicht vorhersehbar waren, müssen sie automatisch Veränderungen ihres Umfelds wahrnehmen, und darauf angemessen reagieren können. Der Mensch übernimmt dabei eine neue Rolle: Er kontrolliert das System nicht mehr direkt, sondern definiert nur noch Strategien, Regeln bzw. Schranken, die vom System genutzt werden. Dazu wird ein Regelkreis benötigt, der System und dessen Kontext ständig überwacht und es bei Bedarf innerhalb dieser Schranken anpasst. Die vier wesentlichen Modelle für solche Regelungssysteme sind 1 die Optimalwertsteuerung (offener Regelkreis), 2 die Rückkopplungssteuerung (geschlossener Regelkreis), 3 Adaptive Regelungssysteme sowie 4 Rekonfigurierbare Regelungssysteme [Klamar, 2004]. Darüber hinaus lassen sich die Modelle untereinander kombinieren, wie beispielsweise in [Kokar et al., 1999] zu einer Rückkopplungssteuerung mit Adaptivregelung. Die Probleme und Herausforderungen der Kontrolltheorie zeigen sich am Beispiel des Systems Grounded Reflective Adaptive Vision Architecture (GRAVA) [Robertson und Laddaga, 2004]. Dieses registriert in einer Kontrollschleife Abweichungen vom gewünschten Verhalten und verändert daraufhin den Programmcode. Das kann, muss aber nicht, zum gewünschten Ergebnis führen. Die Adaption geschieht so lange, bis das vorgegebene Verhalten wieder erreicht ist. In einem stabilen System konvergiert dieser Prozess irgendwann, in einem instabilen System führt dieser Vorgang allerdings zu einer Endlosschleife, weshalb es hier expliziter Mechanismen zur Vorbeugung bedarf. Tiefergehende Informationen zur Kontroll-Theorie und den einzelnen Konzepten können in [Klamar, 2004] nachgelesen werden Weitere Aspekte Es gibt noch eine ganze Reihe weiterer Aspekte, die es beim Entwurf und Einsatz adaptiver Systeme zu beachten gilt. Stellvertretend seien noch der Automatisierungsgrad - die Fähigkeit eines adaptiven Systems, möglichst eigenständig Zeitpunkt und Art der Adaption festzulegen - und das Problem der Nebenläufigkeit genannt, welches in komplexen und verteilten Anwendungen beachtet werden muss. Bei der Verwendung heterogener (OTS-)Komponenten, die womöglich in heterogenen Umgebungen laufen, kann nicht davon ausgegangen werden, das System während der Architekturadaption einfrieren zu können [Oreizy, 1996]. Es müssen also Methoden gefunden werden, um Adaption während der Ausführung - also nebenläufig - zu unterstützen, beispielsweise durch Sperren bestimmter Komponenten Zusammenfassung Anhand der aufgeführten Aspekte und Anforderungen wird ersichtlich, dass bei der Entwicklung eines dynamisch adaptiven Systems viele zusätzliche Belange beachtet werden müssen. Je nach Anwendung und Architektur gewinnen und verlieren einige davon an Bedeutung. So spielen beispielsweise die Zustände von Komponenten in pipelinebasierten Systemen oft keine Rolle, da die Filter meist zustandslos und voneinander unabhängig sind. Für eine tiefergehende Analyse und mögliche Auswege sei nochmals auf die jeweils angeführten Quellen verwiesen. Einen Überblick bieten im Speziellen Oreizy et al. [1999], die sich ganz allgemein den Aufgaben und Verantwortlichkeiten adaptiver Systeme widmen (Abb. 2.2). Copyright TU Dresden, Stefan Pietschmann 23 von 82

30 2. Adaptive Web-Systemarchitekturen 2.4 Spezifikation dynamischer Architekturen Die Adaption auf Basis von Architekturbeschreibungen bietet laut [Schmerl und Garlan, 2002] 1 eine globale Sicht des Systems, 2 die Möglichkeit, explizite Integritätsbeschränkungen anzugeben, 3 flexible Evolution von Architekturen durch entsprechend lockere Kopplung von Komponenten, und 4 die Kapselung des Designwissens als Basis für grundsätzliche Adaptionen [Klamar, 2004]. Im Folgenden wird auf Spezifikationssprachen und Modelle eingegangen, die den Aspekt der Laufzeitadaption unterstützen. Des Weiteren wird die Wiederverwendbarkeit gestärkt und die Adaptierbarkeit ermöglicht. Im Folgenden wird auf Spezifikationssprachen und Modelle eingegangen, die den Aspekt der Laufzeitadaption unterstützen ADLs, AMLs und ACLs Ein Großteil der bestehenden ADLs dient lediglich der Beschreibung statischer Architekturen zur Unterstützung eines linearen Entwicklungsprozesses von der Spezifikation bis zur Kompilierung. Dies spiegelt die Forschung bis in die 1990er Jahre wider, die von statischen Architekturen ausging. Einige wenige Sprachen, wie Weaves [Gorlick und Razouk, 1991] bilden allerdings eine Ausnahme, indem sie Mittel zur Spezifikation von Laufzeitveränderungen bereitstellen. Adaptionen mit Hilfe von ADLs können aber noch auf andere Art und Weise erfolgen. Die dynamische Interpretation einer solchen Architekturbeschreibung ermöglicht Änderungen nach dem Zeitpunkt der Übersetzung mit Hilfe von Code-Generierungskomponenten [Medvidovic, 1996]. Einige Sprachen haben sich dadurch zwar vom reinen Entwurfsinstrument zu einer Art Architekturprogrammiersprache, die die Beschreibung automatisch in Quellcode übersetzen kann, entwickelt (LILEANNA [Tracz, 1993]). Dies befreit den Entwickler jedoch nicht davon, jegliche dynamische Veränderung vorhersagen und programmieren zu müssen, bevor sie in ein Programm übersetzt wird. Da die Veränderung der Architekturbeschreibung von Hand weder praktikabel noch wünschenswert ist und einige Probleme aufwirft [Medvidovic, 1996], entwickelten sich zwei weitere Sprachen, um dynamische Aspekte relativ einfach beschreiben zu können: Die Architectural Modification Language (AML) und die Architectural Constraint Language (ACL) (auch Architecture Construction Notation (ACN)s). Erstere beschreibt Änderungen an der Architektur durch eine Menge von Operationen. Mit Hilfe der Zweiten lassen sich diese Operationen so weit beschränken, dass strukturelle, funktionale oder Verhaltens-Eigenschaften gewahrt bleiben [Wermelinger et al., 2001]. Adaptionen, die in der AML spezifiziert werden, müssen also zur Laufzeit gegenüber den Schranken der ACL verifiziert werden [Oreizy, 1996]. Derartige Schranken können sich auf die Art der Veränderungen, das Adaptionsobjekt, den Adaptionszeitpunkt und Kombinationen davon beziehen [Oreizy, 1996]. Am Beispiel der Adaption C2-basierter Architekturen in [Taylor et al., 1996] und [Medvidovic et al., 1999] (C2SADEL) wird der Zusammenhang zwischen diesen Sprachen deutlich. Diverse Arbeiten haben sich bereits mit der Klassifikation bestehender ADLs und deren Unterstützung dynamischer Architekturen beschäftigt. Stellvertretend sei auf [Medvidovic und Taylor, 1997] und [Albring, 2005] verwiesen Formale Modelle Formale Modelle stellen eine Möglichkeit jenseits ADLs und ihren Derivaten dar, um dynamische Veränderungen in Softwarearchitekturen zu beschreiben. Sie umfassen Graph Grammatiken, wie CHAM [Wermelinger, 1998b, 1999] oder die Ansätze in [Métayer, 1998; Hirsch Copyright TU Dresden, Stefan Pietschmann 24 von 82

31 2. Adaptive Web-Systemarchitekturen et al., 1998; Wermelinger et al., 2001], Verarbeitungslogiken, wie Darwin [Magee und Kramer, 1996a] oder Dynamic Wright [Allen et al., 1998], Logik-basierte Ansätze, wie ZCL [de Paula, 1998], oder sonstige Modelle, wie Rapide [Luckham und Vera, 1995]. Die Trennung zwischen formalen Spezifikationsmethoden und ADLs ist der Literatur relativ unscharf, weshalb beispielsweise Darwin und Rapide teilweise der ersten, teilweise der zweiten Gruppe zugeordnet werden. Der große Vorteil formaler Modelle ist ihr stark formalisierter, mathematischer Charakter. Dieser kann die automatische Programmsynthese unterstützen und dabei helfen, die Reichweite von Adaptionen für das Verhalten einer Anwendung vorherzusehen [Robertson und Laddaga, 2004]. Des Weiteren sind formale Modelle unabhängig von Anwendung, Domäne und Programmiersprache. Im Folgenden werden kurz einige wichtige Vertreter vorgestellt. Darwin [Magee und Kramer, 1996a] ist eine deklarative Sprache mittels derer man die Struktur eines Systems als Kombination verschiedener Komponenten beschreiben kann. Sie stellt Syntax und Semantik zur Verfügung, um Komponenten und deren Ports, sowie Verbindungen zu beschreiben. Mit Hilfe des dyn-konstrukts lässt sich die Instanziierung und Verbindung zur Laufzeit ausdrücken. Die Dynamik beschränkt sich auf das Ersetzen bzw. die Replikation von Komponenten, sofern dies zum Entwicklungszeitpunkt vorgesehen war. CHAM (siehe Kap , Entwurfsmethoden) wurde von Wermelinger [1998b] um Unterstützung dynamischer Architekturen erweitert. Mit Hilfe von if-then - Regeln, können Reaktionen ausgedrückt werden, die Transformationen unterschiedlicher Art am Architekturgraphen vornehmen. In [Wermelinger, 1998a] wurde später eine Erweiterung zu einer vollwertigen ADL vorgenommen. Die Sprache Wright [Allen und Garlan, 1997] schafft eine formale Basis zur Beschreibung von Interaktionen zwischen Komponenten. Dies geschieht durch die Spezifikation von Konnektoren-Typen und deren Interaktionsprotokollen [Fielding, 2000]. Leider ist die Adaption eingeschränkt, da die Anzahl der verschiedenen, alternativen Konfigurationen bereits zum Entwurfszeitpunkt bekannt sein muss [Wermelinger et al., 2001]. Der geneigte Leser wird auf [Bradbury et al., 2004] verwiesen, wo eine Gegenüberstellung 14 formaler Methoden bezüglich ihrer Unterstützung selbst-verwalteter Systeme erfolgt. Ein weiteres formales Mittel stellt die Model Driven Architecture (MDA) dar, deren Ziel es ist, plattformspezifische Modelle [im Softwareentwicklungsprozess] möglichst automatisiert aus plattformunabhängigen Modellen abzuleiten [Kempa und Mann, 2005], um daraus Quellcode zu generieren. Neben der Beschreibung statischer Systeme und Komponenten unterstützen die formalen Modelle der MDA auch dynamisches Verhalten, beispielsweise in Form von Zustandsmaschinen. Damit ist dynamische Adaption auf der abstrakten Modellebene denkbar, falls geeignete Mittel und Wege zur Laufzeitgenerierung und -änderung des Programmcodes gefunden werden Andere Spezifikationsansätze Es existieren diverse weitere Methoden, da bisher ein universeller Spezifikationsansatz fehlt [Wermelinger, 1999]. Stellvertretend wird kurz auf ArchJava [Aldrich et al., 2002] eingegangen. Dieses System ist eine Erweiterung von Java, das der losen Kopplung zwischen Architektur und Implementierung, und den daraus entstehenden Problemen bei Analyse, Implementierung, Verständnis und Evolution von Software, entgegenwirken soll. Dazu unterstützt es die Copyright TU Dresden, Stefan Pietschmann 25 von 82

32 2. Adaptive Web-Systemarchitekturen Kommunikationsintegrität 9 [Luckham und Vera, 1995] des Systems. ArchJava stellt Konstrukte zur Verfügung, um im Java Quellcode Komponenten, Konnektoren, Ports, deren Methoden usw. zu definieren und erlaubt die automatische Generierung visueller Architekturdiagramme aus annotiertem Code. Die Implementierung, auch von dynamischen Architekturen, kann durch die innewohnende Architekturbeschreibung beschränkt, und Inkonsistenzen zwischen Architektur und Implementierung verhindert werden. Das System ist jedoch nicht reflexiv, d. h. es können nur Rekonfigurationen unterstützt werden, die bereits zur Entwurfszeit beschrieben wurden. Des Weiteren gibt es diverse Ansätze, bei denen nicht die Spezifikation dynamischer Architekturen, sondern die der funktionalen sowie nicht-funktionalen Eigenschaften der Komponenten und Systeme im Vordergrund steht. Häufig werden diese durch eigens entwickelte XML-Sprachen beschrieben - meist als QoS Description Language (QDL) bezeichnet. Einige Vertreter sind Quality Objects (QuO) [BBN, 2006] (ein Framework, welches die Definition von QoS in verteilten Anwendungen durch die Erweiterung der CORBA IDL um eine QDL ermöglicht), CQML [Röttger und Zschaler, 2003] (vom COMQUAD-Projekt zur Definition nicht-funktionaler QoS-Eigenschaften genutzt) und HQML [Gu et al., 2001] (zur Erweiterung von Multimediaanwendungen um QoS). Auf eine eingehendere Behandlung dieser Sprachen muss hier - auch aus Platzgründen - verzichtet werden, da lediglich das Vorhandensein, nicht aber die genaue Art der Beschreibung von QoS für diese Arbeit von Bedeutung ist. 2.5 Adaptionsmethoden und -techniken Zur Anpassung einer Softwarearchitektur gibt es verschiedene Mechanismen. Im Folgenden wird zwischen Methoden und Techniken unterschieden. Adaptionstechniken beschreiben Mechanismen, um die Adaption von Softwarearchitekturen im System umzusetzen. Adaptionsmethoden hingegen abstrahieren von dieser Umsetzung und stehen für eine eigenständige Adaptionsidee. Sie können durch verschiedene Adaptionstechniken implementiert werden, welche wiederum auch mehreren Methoden zugeordnet werden können. Klamar [2004] unterscheidet zwischen Mechanismen für adaptive Anwendungsarchitekturen und Systemarchitekturen. Letztere beinhalten Punkte wie die Lastverteilung auf unterschiedliche Hardwareknoten, also hardwarenahe Adaption. Da sich diese Arbeit aber mit der Adaption auf single-machine Servern befasst, werden diese Punkte hier ausgeklammert. Einzig die Verteilung zwischen Server und Client wird in die Betrachtung eingeschlossen. In Abb. 2.4 werden die vorgestellten Methoden zur Softwarearchitekturadaption zusammengefasst. Vergleichbare Übersichten für Methoden bezüglich der Adaption von Daten werden in [Pietschmann, 2005] und [Klamar, 2004] vorgestellt Adaptionsmethoden Bei den adaptierten Entitäten in Softwarearchitekturen kann es sich um Prozeduren, Methoden, (Software-)Komponenten, Gruppen von Komponenten, Subsysteme usw. handeln. Die Adaptionsmethoden und -techniken, die in solchen Systemen eingesetzt werden, unterscheiden sich je nach ihrer Granularität [Almeida et al., 2001b]. Bei der überwiegenden Mehrzahl geschieht die Adaption jedoch auf Basis der in Kap vorgestellten Elemente, nämlich Komponenten, Konnektoren und Daten. Da sich diese Arbeit auf die Strukturadaption konzentriert, wird die Anpassung von Daten hier nicht näher betrachtet. Mehr Informationen 9 Die communication integrity bezeichnet die Eigenschaft eines Systems, dass nur die Komponenten in der Implementierung miteinander kommunizieren, die dies auch in der Architekturbeschreibung tun. Copyright TU Dresden, Stefan Pietschmann 26 von 82

33 2. Adaptive Web-Systemarchitekturen zur Adaption von Inhalten, Präsentation und Linkstruktur finden sich in Veröffentlichungen auf dem Gebiet adaptive Hypermedia [Brusilovsky, 1996, 2001; Pietschmann, 2005]. Abb. 2.4: Übersicht der Methoden zur Architekturadaption Adaption der Topologie Die Topologie einer Systemarchitektur kann sich sowohl auf den Datenfluss (logische ), als auch auf die geographische Lage von Komponenten (physische Topologie) beziehen. Methoden zur Adaption der logischen Topologie sind: Hinzufügen von Komponenten Dies impliziert die Manipulation der Konnektoren, um die Komponente auch mit dem System zu verbinden. Neue Komponenten können auf zwei Arten erstellt werden. Entweder es wird ein bestehender, vordefinierter Typ instanziiert (meist durch eine Regel ausgelöst), oder ein nicht in der Anwendung verfügbarer Typ erstellt. Die Programmierung eines neuen Typs erfordert allerdings den Menschen, da Künstliche Intelligenz (KI) diese Aufgabe in naher Zukunft nicht erfüllen wird. Einen Sonderfall dieser Adaptionsmethode stellt die Replikation von Komponenten dar, die dem System eine neue Instanz einer bestehenden Komponente hinzufügt, beispielsweise zur Verteilung der Last. Entfernen von Komponenten Diese Operation darf nicht die Ausführung anderer Bestandteile des Systems beeinflussen [Ketfi et al., 2002a] oder Datenverluste - durch verloren gegangene Nachrichten bei der Kommunikation mit der zu entfernenden Komponente - verursachen. Häufige Ansatzpunkte dafür sind das Einfrieren der betroffenen Teile bzw. die Unterscheidung von aktiven und passiven Zuständen [Kramer und Magee, 1998] (2.3.2). Komponenten können auf zwei unterschiedliche Arten entfernt werden: Entweder sie werden vom System entkoppelt, sodass sie zwar noch existieren, jedoch nicht mehr erreichbar sind, oder sie werden physikalisch entfernt. Anpassung von Konnektoren Durch die Veränderung der Verbindungen zwischen Komponenten lässt sich die logische Topologie komplett verändern. Dies kann - insbesondere in pipelinebasierten Systemen - zu gänzlich unterschiedlichen Funktionalitäten führen. Konnektoren kommt insbesondere in verteilten Anwendungen eine hohe Bedeutung zu, da sie - abhängig vom Ort der Komponente - die Art der Kommunikation festlegen. Adaptionen der physischen Topologie, d. h. die Migration von Komponenten, sind im Grunde Adaptionen der System-, und nicht der Softwarearchitektur. Sie bringen implizit auch Veränderungen des Ausführungskontextes für die Komponenten mit sich. In verteilten Anwendungen erfolgt sie durch die Schritte 1 Zustand speichern, 2 Konnektoren lösen, 3 entfernte Instanziierung mit gespeichertem Zustand und 4 Verbindung zum System mittels neuer Copyright TU Dresden, Stefan Pietschmann 27 von 82

34 2. Adaptive Web-Systemarchitekturen Konnektoren. Logische Topologie und Datenfluss des Systems ändern sich dabei nicht, lediglich die Kommunikation zwischen der verlagerten und anderen Komponenten. Im Kontext dieser Arbeit spielt diese Methode nur insofern eine Rolle, als Komponenten vom Server auf den Client verlagert werden können. Bei der Client-Server-Verlagerung - speziell in pipelinebasierten Web-Systemen - muss allerdings serverseitig eine Komponente komplett entfernt werden. In diesem Fall ändert sich auch die logische Topologie, womit das System umgehen können muss Adaption der Implementierung Austauschen von Komponenten Eine Komponente wird durch eine andere ersetzt (Instance Replacement [McGurren und Conroy, 2002]), die das gleiche Interface - wenngleich auch auf beliebig andere Art und Weise - implementiert. Sie kann in einem anderen Ausführungskontext laufen und andere funktionale und auch nicht-funktionale Eigenschaften (z. B. QoS) haben [Almeida et al., 2001b]. Streng genommen kann diese Methode als Kombination von Entfernen und Hinzufügen einer Komponente gesehen werden. Es muss allerdings zusätzlich 1 ein Zustandstransfer von der alten zur neuen Version stattfinden und 2 sichergestellt sein, dass beide Versionen nicht gleichzeitig aktiv sein dürfen [Oreizy et al., 1998]. Selbst-Adaption von Komponenten Diese Methode befindet sich im Grenzbereich adaptiver Architekturen, da sich die eigenständige, interne Änderung einer Komponente nicht auf die Softwarearchitektur auswirkt. Diese Methode kann jedoch für die Gesamtarchitektur - und damit für diese Betrachtung - von Bedeutung sein, sobald sie zu einer Veränderung der Funktionalität der Komponente führt. Parameteradaption Eine Komponente kann bestimmte (Schnittstellen-)Parameter besitzen, die ihr Verhalten beeinflussen. Dies impliziert, dass die Anpassung bereits während des Entwurfs bedacht wurde. Bei einer solchen Adaption handelt es sich nicht um Architekturadaption im engeren Sinne, da Architektur nur die Struktur, also Komponenten, deren Schnittstellen und Verbindungen betrachtet. Falls eine Parameteränderung aber eine funktionale Veränderung der Komponente und damit des Systems zur Folge hat, ist die Einordnung an dieser Stelle durchaus sinnvoll. In [McGurren und Conroy, 2002] wird sie als Service Level Adaptation bezeichnet, da ein und dieselbe Komponente ihren Dienst (engl. Service) in Abhängigkeit des Aufrufes anpasst Adaption der Schnittstellen In [Klamar, 2004] wird die Meinung vertreten, die explizite Schnittstellenänderung wäre eine streitbare Adaptionsmethode und impliziere den Komponententausch. Dem kann sich der Autor nicht anschließen. Im Speziellen bei reflexiven Ansätzen wirkt sich die Entfernung eines Metaobjektes nicht zwangsläufig auf das Basisobjekt aus, falls Transparenz vorherrscht (siehe [Redmond und Cahill, 2002]). Natürlich kann die Schnittstellenadaption aber auf eine Komponentenadaption abgebildet werden. Hinzufügen von Schnittstellen Komponenten werden um neue oder im System vorhandene Schnittstellen erweitert. Entfernen von Schnittstellen Schnittstellen einer Komponente werden entfernt, beispielsweise weil sie zwar implementiert, jedoch nie genutzt werden und somit aus Performanzgründen entfernt werden sollten [Ketfi et al., 2002a]. Copyright TU Dresden, Stefan Pietschmann 28 von 82

35 2. Adaptive Web-Systemarchitekturen Anpassung von Schnittstellen Durch Verschiebung oder Umbenennung von Schnittstellenparameter ermöglicht diese Methode Komponenten mit inkompatiblen Interfaces die Zusammenarbeit. Sie wird häufig genutzt, um dynamische Aufrufe zu ermöglichen [McGurren und Conroy, 2002]. Klamars Ausführungen treffen insoweit zu, als ein (selbst-)adaptives System in naher Zukunft wohl keine Mittel haben wird, um festzustellen, ob eine Schnittstelle benötigt wird, oder nicht. Auch die Entscheidung, ob eine Schnittstelle in Folge neu benötigter Funktionalität zu erweitern ist, lässt sich mittels KI schwerlich lösen. Adaptionssubjekt einer solchen Methode wird also ein Administrator/Entwickler sein Adaptionstechniken Die Umsetzung der vorgestellten Methoden kann mit einer Reihe unterschiedlicher softwaretechnischer Mittel erfolgen, die alle spezifische Vor- und Nachteile mit sich bringen. Neben der dynamischen Adaption mit Hilfe von ADLs und AMLs (Kap ) besteht ein weit verbreiteter Ansatz in der Nutzung von Reflexion (engl. reflection). Suzuki und Yamamoto [1999b] beschreiben diese als Fähigkeit eines Programms, die Repräsentation seines eigenen Zustands in Form von Daten zu manipulieren. Dies ermöglicht es einer Software, über den eigenen Ausführungszustand zu reflektieren und ihn schließlich zu ändern. Im Kontext dynamischer Softwarearchitektur spricht man von architektonischer Reflexion (engl. architectural reflection) [Cazzola et al., 2000]. Der sonst übliche Weg der Softwareentwicklung wird dabei umgekehrt: Nicht der Designer definiert eine (ADL-)Beschreibung, sondern das System generiert ein Metamodell (häufig in Form eines Konfigurationsgraphen) von sich selbst, welches es zur Laufzeit überwacht, und bei Bedarf verändern kann. Diese Veränderungen führen wiederum zu Veränderungen der Architektur. Die Nutzung von Reflexion in selbst-adaptiven Systemen geht noch einen Schritt weiter, als in gewöhnlichen Anwendungen: Der Nutzer dieser Mechanismen selbst muss hier implementiert werden. Das automatische Programmieren ist zwar seit Jahrzehnten Aufgabe und Forschungsziel der KI, wird aber in naher Zukunft nicht Wirklichkeit werden. Das Metamodell umfasst deshalb nicht nur architektonische Eigenschaften, sondern auch Schranken (constraints), die beschreiben, wann und wie die Architektur sicher rekonfiguriert werden kann [Dowling und Cahill, 2001]. Vorteile reflexiver Architekturen umfassen die klare Separation of Concerns, verbesserte Adaptier- und Konfigurierbarkeit sowie hohe Transparenz [Suzuki und Yamamoto, 1999b]. Ihre Nachteile liegen in dem zusätzlichen Overhead, der durch die Objekte der Metaebene entsteht, dem potentiellen Schaden, den dortige Veränderungen bewirken können, und der relativ niedrigeren Effizienz, die in der Abstimmung zwischen Basis- und Metaebene begründet liegt [Meyer, 1998]. Kurz zusammengefasst kann man feststellen: Um abstrakte Methoden zur Adaption einer Softwarearchitektur umzusetzen, bedarf es Techniken, die häufig nur mit Hilfe von Reflexion umgesetzt werden können. Alle haben spezifische Vor- und Nachteile, die es bei der Konzeption einer dynamisch adaptiven Anwendung zu beachten gilt. Die wichtigsten Techniken werden im Folgenden vorgestellt. Weitere, nicht näher betrachtete Möglichkeiten, umfassen das Exception Handling und Theorem Prover. Adaption von Komponentenparametern Durch die Parametrisierung kann das Verhalten von Komponenten von außen angepasst werden, z. B. in Form eines indirekten Methodenaufrufs. Dazu bedarf es adaptiver Parameter. Deren Möglichkeiten sind jedoch auf die bei der Entwicklung vorhersehbaren und vorgesehenen Veränderungen beschränkt. Copyright TU Dresden, Stefan Pietschmann 29 von 82

36 2. Adaptive Web-Systemarchitekturen Konditionale Ausführung von Komponenten Mit dieser universellen Technik lassen sich nahezu alle genannten Adaptionsmethoden, wie z. B. das Hinzufügen, Entfernen und Austauschen von Komponenten, umsetzen. Dabei werden a priori-bedingungen überprüft und die Komponente nur dann ausgeführt, wenn diese erfüllt sind. Die konkrete Umsetzung erfolgt z. B. mittels Rewiring, der dynamischen Verdrahtung von Komponenten, wie sie beispielsweise die ACN in C2 SADL [Medvidovic, 1996] mit den Funktionen weld und unweld erlaubt. Damit lassen sich Komponenten mit der Architektur verbinden bzw. davon lösen. Bestimmte Komponenten können so ausgelassen werden. Dynamische Objekttechniken Zur Unterstützung der sog. dynamischen Evolution [Medvidovic und Taylor, 1997] von Komponenten werden häufig Techniken wie Dynamic Link Library (DLL)s, Class Loader, Factory- Objekte oder Vererbung genutzt. Sie fallen in den Bereich dynamischer Objekttechniken, wie Dynamic Linking bzw. Dynamic Loading oder Dynamic Binding. Diese ermöglichen das dynamische Laden, Entladen oder Generieren von Komponenten. Viele Programmiersprachen und Bibliotheken stellen dafür heutzutage Mittel zur Verfügung, die insbesondere durch Entwurfsmuster (s. u.) ausgenutzt werden. Diese Techniken werden nicht nur zur Adaption der Anwendung selbst, sondern bei offen-dynamischen Systemen oft auch zur dynamischen Veränderung der Adaptionslogik (Dynamic Loading) [Dowling und Cahill, 2001] genutzt. Die Grundidee ist, den Zeitpunkt der Verknüpfung mit Bibliotheken, Objekten oder Prozeduren von der Übersetzungs- zur Laufzeit zu verschieben. Bestehende Lücken im Programm werden dynamisch, je nach Situation, gefüllt. Dafür ist es wichtig, dass in der Anwendung möglichst wenig statische Referenzen existieren. Je nach Zeitpunkt des Ladens und Art der Einbindung der geladenen Module lassen sich diese Techniken weiter klassifizieren (siehe [Franz, 1997]). Entwurfsmuster Ein häufiges Mittel zur Umsetzung von Adaptierbarkeit in Anwendungen bereits auf der Programmierebene sind Entwurfsmuster [Gamma et al., 1995]. Sie können teilweise auch in (selbst-)adaptiven System genutzt werden, so unter anderem Strategy zur Änderung von Algorithmen (Selbst-Adaption von Komponenten); Bridge zum Wechseln der genutzten Implementierung; Observer zur Trennung von Daten und Beobachtern, und das dynamische Hinzufügen bzw. Entfernen derselben; Mediator für die lose Kopplung unabhängiger Komponenten; Proxy als Stellvertreter zur Weiter- bzw. Umleitung von Aufrufen oder zur Durchführung der Rekonfiguration selbst; Memento zur Sicherung des Zustands einer Komponente; Die Verwendung von Entwurfsmustern muss jedoch bereits beim Entwurf der Software geplant sein und schränkt somit die Möglichkeiten dynamischer Adaptivität etwas ein. Copyright TU Dresden, Stefan Pietschmann 30 von 82

37 2. Adaptive Web-Systemarchitekturen Redundante Hardware Die Umsetzung von Adaption mit redundanter Hardware setzt zumindest einen zweiten Standby -Server voraus. Zur Laufzeit wird das aktuelle System auf den zweiten Server dupliziert und dort adaptiert bzw. erweitert. Der Zustand des alten Systems wird gespeichert, auf das aktualisierte System übertragen, dieses wird gestartet und für den Nutzer transparent zwischen den Servern umgeschaltet. Diese Technik ist eher ungeeignet für kurzfristige, häufige Adaptionen. Sie wird stattdessen häufig zur korrektiven und perfektiven Adaption genutzt. Das ACARS-System [ARINC Inc., 2006] zur Kommunikation in der Luftfahrt nutzt ein solches Konzept. 2.6 Aktuelle Forschungsansätze dynamisch adaptiver Systeme Dynamische Systeme können nach verschiedensten Gesichtspunkten kategorisiert werden, z. B. nach Auslöser und Art der Adaption, unterstützten Adaptionsmethoden, verwendeten Adaptionstechniken oder nach Aspekten wie Automatisierungsgrad oder Art des Regelkreises. In diesem Abschnitt werden zuerst diverse Muster vorgestellt, die eine Unterteilung verschiedener Konzepte und Systeme erlauben. Anhand dieser Muster wurde versucht, bestehende Ansätze in der Literatur zu klassifizieren. Aufgrund der Vielzahl an Unterscheidungsmerkmalen war es jedoch nicht möglich, eine allgemein gültige, umfassende Taxonomie adaptiver Systeme aufzustellen. Die nachfolgende Vorstellung einiger adaptiver Ansätze aus der Literatur dient deshalb vor allem der Übersicht über wesentliche, häufig genutzte Konzepte in dynamisch adaptiven Systemen Klassifikationsmuster dynamisch adaptiver Systeme Ein relativ elementarer Unterschied besteht zwischen adaptierbaren und adaptiven Systemen. Adaptierbare Systeme erlauben die explizite Adaption durch eine externe Entität mittels prozeduraler oder deklarativer Schnittstelle, z. B. eines Graphical User Interface (GUI) [Blair et al., 2001]. Adaptive Systeme hingegen passen ihr Verhalten bzw. ihre Funktionalität selbstständig, also implizit, Veränderungen ihres inneren Zustandes oder ihrer Umgebung an. Implizite Adaption geht von der Anwendung selbst aus und nutzt Informationen des Kontextes, um beispielsweise nicht benötigte oder optionale Komponenten auszuschalten, oder einen Algorithmus auszutauschen. Explizite Adaption geschieht durch äußere Kräfte, d. h. die Mechanismen zur Systemüberwachung, -analyse und Adaptionsplanung befinden sich außerhalb der Anwendung. Verschiedene Arbeiten sprechen in diesem Zusammenhang auch von externer und interner Adaption [Oreizy et al., 1999; Schmerl und Garlan, 2002; Castaldi et al., 2003a; Rigole et al., 2004]. Der feine Bedeutungsunterschied zwischen externer und expliziter Adaption besteht darin, dass bei der ersterer auch die Durchführung der geplanten Adaption durch Mechanismen außerhalb der Anwendung stattfindet, d. h. für diese transparent verläuft. Sehr häufig geschieht dies durch Middleware, da oft nur sie Zugriff auf Strukturen so tief in der Anwendung hat [Rigole et al., 2004]. Die explizite Adaption bezieht sich eher auf die Adaptionsinitiative, die von außen kommt. Abb. 2.5 verdeutlicht, dass ein System sowohl explizite, als auch implizite Adaption unterstützen kann. Ein interessanter Forschungszweig, der sich mit der Koordination beider Arten beschäftigt, ist die Pervasive Adaptation. Die Trennung zwischen im- und expliziter Adaption spiegelt sich auch in den beiden Paradigmen wider, die Laddaga und Robertson [2004] für adaptive Systeme benennen: Copyright TU Dresden, Stefan Pietschmann 31 von 82

38 2. Adaptive Web-Systemarchitekturen Abb. 2.5: Explizite und Implizite Adaption [Dowling und Cahill, 2001] Planungsparadigma Die Anwendung arbeitet als Planungssystem. Die Ausführung von Handlungen erfolgt nicht auf Basis vorgefertigter Algorithmen, sondern wird vom System geplant und - nach positiver Evaluation - gestartet. Der Plan steht in der Anwendung zur Validierung, Evaluation oder Modifikation zur Verfügung. Letztere erfolgt beispielsweise, wenn nicht genügend Ressourcen vorhanden sind. Systeme dieser Art setzen die Adaption also implizit um. Kontrollparadigma Das Laufzeitsystem stellt hier eine Art Factory mit Inputs und Outputs dar, die durch eine Überwachungs- und Steuerungskomponente verwaltet wird. Evaluations-, Überwachungs- und Steuerungskomponente setzen auf der Anwendung auf und regeln die Rekonfiguration des Systems. Hier erfolgt die Adaption also explizit, durch externe Komponenten. Adaptive Systeme können entweder geschlossen- oder offen-dynamisch sein. Ist ersteres der Fall, steht die komplette Anwendungsfunktionalität und Adaptionslogik bereits zum Zeitpunkt der Kompilierung fest. Offen-dynamische Systeme ermöglichen die Evolution und Erweiterung der Anwendungsfunktionalität über vorbestimmte Grenzen hinaus. Sie erlauben Reaktionen des Systems auf unerwartete Veränderungen zur Laufzeit [Oreizy et al., 1999]. In diesem Zusammenhang gilt es auch zwei in der Literatur unterschiedene Adaptionsarten zu betrachten: die programmierte [Endler, 1994; Moazami-Goudarzi, 1999] bzw. beschränkte [Oreizy, 1996] Laufzeit-Modifikation und die sog. ad-hoc [Endler, 1994], evolutionäre [Moazami- Goudarzi, 1999] bzw. einfache [Oreizy, 1996] Veränderung. Wermelinger [1998a] benennt separat davon noch eine dritte Art, nämlich die selbst-organisierte Anpassung. Programmierte Rekonfigurationen dienen der Anpassung an Bedingungen, die bereits beim Entwurf des Systems vorhersehbar sind. Sie werden häufig auf der Modellierungsebene durch predicate-action -Konstrukte [Batista et al., 2005] definiert und zusammen mit der Anwendung kompiliert. Wenn sich ein bestimmtes Prädikat, also ein bestimmter Parameter des Systems, ändert, so wird eine dazugehörige, programmierte Aktion ausgelöst. Auf diese Art erfolgen meist implizite, d. h. automatische, anwendungsgesteuerte Veränderungen, wie Load Balancing [Cherkasova und Ponnekanti, 2000] oder Fault Recovery [Endler, 1994]. Ad-hoc Rekonfigurationen sind bei der Entwicklung der Anwendung noch nicht vorhersehbar. Deshalb werden lediglich Invarianten des Systems bzw. Grenzen späterer Rekonfigurationen festgelegt. Zur Laufzeit kann die Anwendung dann (explizit) mittels einfacher Rekonfigurationskommandos funktional oder strukturell verändert werden, Copyright TU Dresden, Stefan Pietschmann 32 von 82

39 2. Adaptive Web-Systemarchitekturen was allerdings einen Administrator und eine Schnittstelle zur Interaktion mit dem System voraussetzt. Selbst-organisierte Rekonfigurationen nach [Wermelinger, 1998a] gehen von der Anwendung aus, sind aber nicht an Regeln oder Invarianten gebunden. Folglich basieren geschlossen-dynamische Systeme sehr häufig auf impliziten, programmierten Rekonfigurationen, während offen-dynamische Anwendungen ad-hoc Rekonfigurationen durch externe Kommandos zulassen, oder diese im Fall von selbst-organisierten Systemen selbst steuern. Auch bezüglich des Datenflusses existieren zumindest zwei verschiedene Herangehensweisen. Vorherrschend ist die event-gesteuerte Adaption, bei der die Komponenten der Überwachungsebene die Anwendung durch Events über Veränderungen informieren (Push-Prinzip). Daraufhin erfolgt die Auswertung von Event-Condition-Action-Tupeln, welche in einer Domain-Specific Language (DSL) [Consel und Marlet, 1998] beschrieben ist. Den umgekehrten Weg verfolgen Adaptionen über ein Query-Interface [David und Ledoux, 2003]. Sie erfolgen auf Initiative der Anwendung, die in bestimmten Abständen den Kontext auf Veränderungen überprüft, bzw. das adaptive Subsystem dazu anstößt (Pull-Prinzip). Diese beiden Prinzipien lassen sich auch auf die Paradigmen von Laddaga und Robertson [2004] zurückführen. Anwendungen des Planungsparadigmas überprüfen bei der Planung der Ausführung meist eigenständig den Kontext auf Veränderungen (Query), während in Anwendungen des Kontrollparadigmas Adaptionen explizit beim Auftreten von Veränderungen angestoßen werden (Events). Ein Beispiel hierfür ist das Framework aus [da Silva e Silva et al., 2000, 2003] (Abb. 2.6), welches nebenbei eine klare Trennung der Verantwortlichkeiten propagiert. Ein Monitoring Paket überwacht Ressourcen und Ortsinformationen der mobilen Endgeräte und Interaktionen zwischen Komponenten. Es ist getrennt vom Adaptionsmanagement, welches im Dynamic Reconfiguration Paket Mechanismen zur Adaptionsentscheidung, -umsetzung und Konsistenzprüfung bereitstellt. Diese Mechanismen werden durch Events ausgelöst, die das Event Detection and Notification Paket aus den Überwachungsdaten extrapoliert und dann an interessierte Objekte sendet. Abb. 2.6: Framework zur Rekonfiguration adaptiver Systeme [da Silva e Silva et al., 2003] In [Yang et al., 2002] erfolgt eine Klassifikation adaptiver Systeme nach der Dynamik und Reichweite der Adaption: Static-Adapt Ansätze verändern den ausführbaren Code während der Laufzeit nicht. Sie spielen deshalb in dieser Arbeit keine Rolle. Trace-Adapt Ansätze können zur Laufzeit Code hinzufügen, verändern und entfernen, z. B. durch dynamisches Laden und Entladen von Klassen (Kap ). Sie verändern jedoch nie den original Programmcode, wodurch eine Rückverfolgung (engl. traceability) Copyright TU Dresden, Stefan Pietschmann 33 von 82

40 2. Adaptive Web-Systemarchitekturen zum ursprünglichen Programm möglich ist. Vertreter dieser Kategorie sind z. B. die Systeme Hadas [Ben-Shaul et al., 2001] oder Dynamic Component UPdating (DCUP) [Plášil et al., 1997]. Der Ansatz von Blair et al. [1997], welcher auf einer reflexiven Architektur fußt, ist ebenfalls hier einzuordnen. Full-Adapt Ansätze, wie Iguana [Redmond und Cahill, 2002], erlauben die Veränderung des Quellcodes zur Laufzeit. Dadurch büßen sie jedoch die Möglichkeiten der Verifikation und Validierung ein, da der Bezug zum ursprünglichen Programm und seinen Anforderungen verloren geht [Yang et al., 2002]. Oreizy et al. [1999] stellen ein Spektrum adaptiver Systeme nach dem Grad ihrer Adaptionskomplexität vor (Abb. 2.7). Während am unteren Ende lediglich die programmierte Auswahl zwischen vordefinierten Alternativen erfolgt, werden die Systeme nach oben hin zunehmend komplexer und ermöglichen auch unvorhersehbare Veränderungen. Zudem steigt auch die Trennung der Verantwortlichkeiten. In [Oreizy et al., 1999] werden alle Bereiche genauer vorgestellt und bewertet. Abb. 2.7: Das Spektrum von Selbst-Adaptivität [Oreizy et al., 1999] Eine Unterscheidung vor dem Hintergrund der Implementierung nehmen Ketfi et al. [2002a] vor. Sie fassen die bisherigen Ansätze in drei Gruppen zusammen: managerbasierte, frameworkbbasierte und transaktionsbasierte Ansätze. Vertreter dieser Gruppen werden im nächsten Abschnitt beleuchtet. Parallel findet in [Ketfi et al., 2002a] auch eine Betrachtung der Ansätze nach anderen, in diesem Kapitel vorgestellten Gesichtspunkten statt. Als wichtige Unterscheidungskriterien werden u. a. der Automatisierungsgrad der Adaption, ihre Verlässlichkeit, die Unterstützung von Zustandstransfers zur Konsistenzsicherung und die unterstützten Adaptionsmethoden verwendet. Offensichtlich existiert eine Vielzahl sich überschneidender Klassifikationskriterien, die die Aufstellung einer allgemein gültigen Taxonomie dynamisch adaptiver Systeme so nicht möglich macht. Vielmehr kann eine Trennung immer nur nach bestimmten, für die jeweilige Betrachtung relevanten Gesichtspunkten erfolgen Vorstellung ausgewählter Ansätze In diesem Abschnitt werden ausgewählte Stellvertreter dynamischer Softwarearchitekturen vorgestellt, anhand derer einige wichtige Konzepte, wie Proxies, Verträge oder Reflexion, erläutert werden. Als Einstieg dient die im letzten Abschnitt erwähnte Unterscheidung in manager-, framework- und transaktionsbasierte Ansätze nach Ketfi et al. [2002a]. Copyright TU Dresden, Stefan Pietschmann 34 von 82

41 2. Adaptive Web-Systemarchitekturen Managerbasierte Systeme nutzen zur Verwaltung und Adaption von Komponenten einen Manager bzw. Rekonfigurationsagenten [Almeida et al., 2001b; Castaldi et al., 2003a]. Im System DCUP [Plášil et al., 1997, 1998], wo Komponenten aus einem festen (fixed/permanent) und einem veränderlichen, adaptiven Teil (extensible/replacable) bestehen, übernimmt diese Aufgabe der Component Manager. Er gehört zum festen Teil und initiiert die Adaption durch eine Anfrage an einen Component Builder, der die Komponente, d. h. alle funktionalen Subkomponenten, anhält, ihren Zustand sichert und den variablen Teil zerstört. Der Manager instanziiert daraufhin eine neue Version des Builders, der den veränderlichen Teil der Komponente wunschgemäß neu erstellt. Ein Nachteil ist hier, dass bei der Adaption einer Subkomponente alle umgebenden funktionalen Bestandteile ebenfalls zerstört und neu gebaut werden müssen. Der Worst Case besteht somit in der Adaption eines Konnektors zwischen zwei Komponenten auf oberster Ebene der Anwendung: Dabei muss die gesamte Anwendung neu geladen werden [Ketfi et al., 2002a]. Ferner bietet das System keinerlei automatisierte Adaption, d. h. jegliche Anpassung muss extern initiiert werden. Der Adaptionsansatz liegt bei DCUP nicht auf der Komponentenebene, sondern darunter, da nur ein Teil einer Komponente verändert wird. Die Adaption ganzer Komponenten ist nicht möglich, wird jedoch von der Mehrzahl der verbreiteten Anwendungen unterstützt, z. B. in Georgiadis et al. [2002]. Dort besteht jede Laufzeitkomponente aus einer Implementierung, einem Manager und einer Konfigurationssicht. Adaptionen werden von einem oder mehreren Managern bei der Verletzung von Architekturbedingungen durchgeführt und untereinander durch Events propagiert, sodass die Konfigurationssichten aller Komponenten stets konsistent sind. Sehr häufig sind diese Manager als Stellvertreter (Proxies) der eigentlichen Komponenten implementiert, um Anfragen bzw. Aufrufe abfangen und überwachen, analysieren, modifizieren oder umleiten zu können. Dies lässt sich relativ einfach mit Hilfe der Entwurfsmuster Proxy, Decorator oder Adapter realisieren und stellt einen geeigneten Weg dar, statische Systeme um Adaption zu erweitern. Trotz der guten Wiederverwendbarkeit führt die zusätzliche Indirektion über die Proxies zu einem Verlust an Leistung. Dieser kann allerdings durch geeignete Maßnahmen minimiert werden, wie Redmond und Cahill [2002] mit ihrer reflexiven Erweiterung der Java Virtual Machine (JVM) - Iguana/J - beweisen. Sie verknüpfen Metaobjekte, die völlig unabhängig entwickelt werden können, mit den Laufzeitobjekten einer Anwendung. Operationen wie Objekterstellung und -löschung, Methodenaufrufe oder Zugriffe auf Felder von Objekten werden automatisch an die jeweils verknüpften Objekte der Metaebene umgeleitet - völlig transparent für die Anwendungsobjekte der Basisebene. Folglich können die Metaobjekte auch als Adapter dienen, beispielsweise bei einem dynamischen Wechsel der Kommunikations-API [Redmond und Cahill, 2002]. Weitere Beispiele für Proxies sind die reconfiguration agents aus [Castaldi et al., 2003a] und die QoS Proxies aus [Gu et al., 2001]. Die Adaption von Komponenten mittels völlig autonomer Agenten ist ein eher seltener Ansatz. Sehr häufig bedienen sich adaptive Systeme einer zentralen Komponente, die für die Rekonfiguration verantwortlich ist, diese plant und steuert. Auch in der agentenbasierten X-Adapt-Architektur von McGurren und Conroy [2002] (Abb. 2.8) werden die Komponenten der Software über Proxies rekonfiguriert. Deren Konfiguration übernimmt ein zentraler Configuration Manager, der auf einer Meta-Ebene ausgewählte Systemeigenschaften überwacht und durch die geeignete Konfiguration der Proxies sicherstellt. In der Literatur existieren neben Configuration Manager [Kramer und Magee, 1985; Dowling und Cahill, 2001; McGurren und Conroy, 2002] auch die Bezeichnungen Architectural Evolution Manager [Oreizy et al., 1998, 1999], Coordinator [Métayer, 1998] oder Configuror [Allen et al., 1998] für ein solches zentrales Objekt. Copyright TU Dresden, Stefan Pietschmann 35 von 82

42 2. Adaptive Web-Systemarchitekturen Abb. 2.8: Die X-Adapt Architektur McGurren und Conroy [2002] In einigen Systemen übernimmt der Manager neben der Planung und Steuerung auch die eigentliche Durchführung der Adaption, die Überwachung des Kontextes oder die Konsistenzsicherung. Dies ist in [Ramdane-Cherif und Levy, 2002] der Fall, wo ein globaler Agent bei Veränderungen der Architektur oder Umgebung Events empfängt, diese mit Hilfe eines Rule Based System (RBS), bestehend aus Event/Condition/Action-Tupeln, verarbeitet und unter bestimmten Bedingungen Aktionen, wie das Hinzufügen, Entfernen oder Migrieren von Komponenten, ausführt (Abb. 2.9). Ein Nachteil eines solchen monolithischen Ansatzes ist natürlich die schlechte Wiederverwendbarkeit. Deshalb sind die Verantwortlichkeiten zur Überwachung und Analyse des Kontextes, zur Planung und Steuerung von Rekonfigurationen oftmals getrennt (Abb. 2.6). Abb. 2.9: Schematische Übersicht eines Agenten [Ramdane-Cherif und Levy, 2002] Das Modell der Open Services Gateway Initiative (OSGi) [OSGI, 2006] stellt einen frameworkbasierten Ansatz dar, in dem nicht mehr eine zentrale Instanz, sondern ein gesamtes Framework für die Administration aller Komponenten verantwortlich ist. Bundles können in Form vom Java ARchive (JAR)-Dateien dynamisch in das Framework eingebunden, aktiviert, deaktiviert und deinstalliert werden. Dazu müssen sie eine Activator-Klasse besitzen, die Copyright TU Dresden, Stefan Pietschmann 36 von 82

43 2. Adaptive Web-Systemarchitekturen die Methoden start und stop für diese Zwecke implementiert. Die Aufgaben des adaptiven Systems beschränken sich auf das (de)aktivieren, laden und starten von Komponenten. Die Verantwortung, die Komponente zu stoppen, gebundene Ressourcen freizugeben, den Zustand zu sichern etc. obliegt allein dem Programmierer. Auf den Sinn transaktionaler Ansätze - der dritten Art adaptiver Systeme nach [Ketfi et al., 2002a] - wurde bereits in Kapitel eingegangen und das System Olan [Balter et al., 1998] als Vertreter benannt. Es unterstützt sowohl Anwendungs- (engl. applicative) als auch Rekonfigurationstransaktionen (engl. reconfiguration), wobei im Konfliktfall die Rekonfiguration das Vorrecht hat und andere Transaktionen abgebrochen werden. Dies kann jedoch, wie bereits beschrieben, zu starken Leistungseinbußen bis hin zum Halt der Anwendung führen. Transaktionsbasierte Systeme benötigen deshalb eine sinnvolle Verwaltung, um solchen Fällen vorzubeugen. Rekonfigurationen werden in der Regel durch Veränderungen ausgelöst, die bestimmte Grenzen überschreiten. Diese sind häufig in Form von Verträgen von bzw. mit dem System oder seinen Komponenten definiert. Beugnard et al. [1999] unterscheiden vier Arten von Verträgen, wobei für dynamische Systeme die vierte von größter Bedeutung ist: dynamisch verhandelbare Verträge. Die Spezifikation von Verträgen findet oft in einer XML-basierte Sprache statt, wie sie in Kapitel vorgestellt wurden. Im Contract-based Adaptive Software Architecture (CASA)-Framework [Mukhija und Glinz, 2003, 2004] basiert die Adaption auf der Definition von Ressourcenanforderungen und adaptivem Verhalten in Form von Application Contracts (Anwendungsverträgen) - ausgedrückt in der Contract Specification Language (CSL). Zur Laufzeit werden diese Verträge ausgewertet, und zwischen verschiedenen, alternativen Konfigurationen umgeschaltet, die sich in Leistung, Funktionalität und benötigten Ressourcen unterscheiden. Abb zeigt die elementaren Bestandteile des CASA-Frameworks: der ResourceManager verwaltet und überwacht die Ressourcen, das Contract Enforcement System entscheidet über die Allokation von Ressourcen auf Basis der Überwachungsdaten und Anwendungsverträge und das Contract-based Adaptation System ist für die Überführung in alternative Konfigurationen zuständig, falls die verfügbaren Ressourcen für die aktuelle nicht ausreichen. Abb. 2.10: Aufbau des CASA Frameworks [Mukhija und Glinz, 2003] Verträge lassen sich sowohl auf System- als auch auf Komponentenebene einsetzen: Entweder passt sich das System so an, dass es seine Verträge einhalten kann, Komponenten werden Copyright TU Dresden, Stefan Pietschmann 37 von 82

44 2. Adaptive Web-Systemarchitekturen angepasst, um ihre Verträge einzuhalten oder es werden nur die Komponenten ausgeführt, die ihre Verträge einhalten. Den letzten Weg, dessen Prinzip in den Kapiteln 3 und 4 wieder aufgegriffen wird, verfolgt beispielsweise der Ansatz von Rigole et al. [2004]. Er wurde für das Umfeld des Pervasive Computing konzipiert, weshalb aufgrund der kleinen, teils versteckten Endgeräte liegt das Hauptaugenmerk auf Cyber Foraging 10 -Techniken und der Anwendungsadaptionen liegt, um die sehr beschränkten Ressourcen bestmöglich zu nutzen. Jede Komponente des Systems verfügt über eine Resource Declaration - eine parametrisierte Beschreibung ihrer Ressourcenanforderungen -, die zur Aushandlung der Nutzung bestimmter Ressourcen zwischen Anwendung und Middleware dient. Dazu werden Resource Contract Proposals - einer Kombination mehrerer Resource Declarations - kompiliert, von der Middleware validiert, und entweder zurückgewiesen oder bestätigt (Signed Resource Contract). Ein Beispiel dafür wäre ein Bandbreiten-Vertrag, der an einen Konnektor zwischen zwei Komponenten geknüpft ist. Diese werden nur dann verbunden, wenn die Bandbreiten-Voraussetzungen aus den Resource Declarations beider Seiten erfüllt werden. Ist ein Vertrag geschlossen, dann überwacht die Middleware dessen Einhaltung durch alle Parteien. Das Planungsparadigma (Kap ) dieses Systems wird durch das dynamische Task Model 11 [den Bergh und Coninx, 2004] verdeutlicht, welches ständig auf Basis kontextueller Informationen aktualisiert wird. Es bildet die Grundlage für den Deployment Plan, der spezifiziert, wann welche Softwarekomponenten geladen, und wie sie verbunden werden müssen. Das Deployment an sich unterliegt dem oben beschriebenen Prozess der Vertragsaushandlung, sodass bestimmte optionale Komponenten je nach Ressourcenverfügbarkeit entweder geladen werden oder nicht. Abb verdeutlicht, wie das dynamische Task Model schrittweise auf die Softwarearchitektur abgebildet wird. Abb. 2.11: Abbildung eines dyn. Task Models auf die Softwareebene [Rigole et al., 2004] Weitere vertragsbasierte Systeme stellen Gorinsek et al. [2003] (Einhaltung von QoS bei dynamischen Updates von Software mit Hilfe von Resource Contracts), Preuveneers und Berbers [2005] (dynamische Zusammenstellung der minimalen Konfiguration von Komponenten unter 10 Der Begriff Cyber Foraging bezeichnet die dynamische Vergrößerung der Ressourcen eines mobilen Endgerätes durch Nutzung verteilter Ressourcen in angeschlossenen Netzen (näheres dazu in [Garlan et al., 2002]). 11 Ein Task Model beinhaltet Informationen über anstehende Aufgaben, deren Reihenfolge und Anforderungen. Es wird gewöhnlich zur Entwicklungszeit definiert und liegt in Form eines Baums vor. Dynamische Task Models können sich hingegen zur Laufzeit neuen Gegebenheiten anpassen. Das System ist dafür verantwortlich, diese Veränderungen auf die softwaretechnische Ebene abzubilden. Copyright TU Dresden, Stefan Pietschmann 38 von 82

45 2. Adaptive Web-Systemarchitekturen Berücksichtigung aller Verträge zur Zusicherung funktionaler und nicht-funktionaler Eigenschaften), Wils et al. [2003] (vertraglich festgelegte Ressourcennutzung) und Göbel et al. [2004] mit COMQUAD (COMponents with QUantitative properties and ADaptivity) (Beschreibung zugesicherter, nicht-funktionaler Eigenschaften von Komponenten durch System Contracts zwischen Komponenten und dem Laufzeitsystem) vor. Ein häufiges Adaptionsmittel ist - wie gerade für das System CASA beschrieben - das Umschalten zwischen verschiedenen Modi bzw. alternativen Konfigurationen, die entweder verschiedene Qualitätslevel oder vergleichbare Qualität bzw. Funktionalität bei unterschiedlichen Ressourcenanforderungen bieten [Gu et al., 2001]. Dies folgt dem Prinzip des Dienste- Polymorphismus 12. Die Architektur zur Adaption kontextsensitiver Dienste aus [Efstratiou et al., 2001] basiert auf diesem Prinzip. Sie erlaubt den dynamischen Wechsel zwischen verschiedenen Betriebsmodi, der durch zugeordnete kontextuelle Trigger ausgelöst wird. Hier zeigt sich die Schwachstelle solcher Systeme: Sind sind sehr unflexibel, da sie vom Entwickler verlangen, bereits im Vorfeld alle Modi und Trigger genau festzulegen. Der Grad der Autonomie bei Planung und Durchführung der Adaption schwankt bei den verschiedenen Vertretern dieses Mechanismus [Bharghavan und Gupta, 1997; Chang und Karamcheti, 2000; Keleher et al., 1999; McCann et al., 2003; Mukhija und Glinz, 2004] stark. Wie bereits eingangs erwähnt, ist das die Nutzung von Reflexion für die Mehrzahl der adaptiven Ansätze grundlegend. Dies spiegelt sich häufig in einer abstrakten Repräsentation der Architektur wider, wie beispielsweise beim K-Component Meta-Modell [Dowling und Cahill, 2001]. Dieser Ansatz basiert auf der dynamischen Transformation des automatisch generierten Konfigurationsgraphen - einer abstrakten Beschreibung der Softwarearchitektur - auf Basis von adaptation contracts. Diese liegen in Form einer Architecture Constraint Description Language (ACDL)-Beschreibung, getrennt vom Anwendungscode, vor. Ein reconfiguration protocol sorgt dafür, dass sich alle durch die Transformation betroffenen Bestandteile des Graphen in einem sicheren Zustand [Wermelinger, 1999] befinden. In der GRAVA Architektur [Robertson und Laddaga, 2004] zur rechnerbasierten Segmentierung und Beschreibung von Bildern wird Reflexion durch übereinander liegende, reflexive Schichten genutzt, die jeweils die Meta-Level Abstraktion der darunterliegenden Schichten bilden und dort dynamische Veränderungen hervorrufen können. Der OpenWebServer [Suzuki und Yamamoto, 1999a,b], ein komponentenbasierter Web-Server auf Basis des Adaptive Internet Server Framework (AISF) [Suzuki und Yamamoto, 1998], modelliert mit Hilfe von Metaobjekten hingegen verschiedene Aspekte, wie Caching, Logging oder Load Balancing, die dadurch zur Laufzeit verändert werden können. Weitere Systeme, die die Nutzung reflexiver Techniken veranschaulichen, sind das Meta- Framework Plastik [Batista et al., 2005] und das Fractal Composition Framework [Coupaye et al., 2002; Bruneton et al., 2002], welches in [David und Ledoux, 2003] um Kontext-Awareness und Adaptionsstrategien erweitert wird. Häufig findet die Adaption durch anwendungstransparente Middleware statt. Sie ermöglicht es Entwicklern (ortsfester) verteilter Anwendungen, sich nicht explizit mit Problemen der Verteilung, wie Heterogenität, Skalierbarkeit oder Ressourcenteilung, beschäftigen zu müssen, und bietet eine homogene Grundlage auf Basis eines transparenten QoS-Paradigmas. Dies wird entweder durch die Reservierung von Ressourcen [Nahrstedt et al., 1998] oder deren adaptive Allokation auf Basis von anwendungsspezifischen Adaptionsregeln [Blair et al., 1997] ermöglicht. Diverse komponentenbasierte Middlewaresysteme (siehe Referenzen 12 Mit Dienste-Polymorphismus (Service Polymorphism) ist gemeint, dass ein Dienst in verschiedensten Formen und Formaten mit Hilfe unterschiedlicher Konfigurationen der Anwendung angeboten werden kann. Copyright TU Dresden, Stefan Pietschmann 39 von 82

46 2. Adaptive Web-Systemarchitekturen in [Gu et al., 2001]) kombinieren inzwischen beide Arten und trennen häufig das Adaptionsmanagement von der Adaptionsstrategie, um die Entwickler zu entlasten und möglichst generische Adaptionsmechanismen nutzen zu können. Diese Form der Adaption, bei der der Middleware die Aufgaben einer entkoppelten Adaptionsschicht unterhalb der Anwendung zukommen (das QoS Management, d. h. Aushandlung, Anpassung, Rekonfiguration, Allokation und Reservierung, auf Grundlage von QoS Definitionen der Anwendung), ist weit verbreitet. Oftmals handelt es sich bei solchen Systemen um adaptive Frameworks bzw. Rekonfigurationsdienste auf Basis der Common Object Request Broker Architecture (CORBA) für verteilte Anwendungen, wie beispielsweise in [Almeida et al., 2001b; Bidan et al., 1998; Cukier et al., 1998; Rodriguez und Ierusalimschy, 1999]. Einen Vergleich verschiedener Ansätze dynamischer Rekonfiguration durch Middleware bieten Almeida et al. [2001a]. Die klassische, anwendungstransparente Middleware setzt allerdings ein gewisses Maß an System- und Netzwerkintegrität voraus, das im Bereich des Mobile Computing so nicht gegeben ist. Mobile verteilte Anwendungen müssen auf heterogenen, mobilen Endgeräten laufen und mit abrupten Netzwerkausfällen und beschränkten, schwankenden Ressourcen (langsame CPU, wenig Speicher) zurecht kommen. Sie sind der ständigen Veränderung ihrer Umwelt ausgesetzt, z. B. bei Standortwechsel oder großer Varianz der Bandbreite von einigen Kbps bis zu mehreren Mbps [Pitoura und Samaras, 1998]. In [Capra et al., 2001b,a] motivieren die Autoren deshalb eine Abkehr von der transparenten, hin zu einer reflexiven Middleware (Abb. 2.12) zur Unterstützung kontextsensitiver Anwendungen, da diese normalerweise effizientere und qualitativ bessere Entscheidungen, basierend auf anwendungsspezifischen Informationen, treffen. [Capra et al., 2001b] Dafür stellt die Middleware der Anwendung Informationen über deren Ausführungskontext zur Verfügung. Die Anwendung trifft alle kontextunabhängigen Entscheidungen selbst und stellt für die restlichen ein dynamisch veränderbares Anwendungsprofil in Form eines XML- Dokuments auf. Dieses enthält Verknüpfungen von Veränderungen des Ausführungskontextes mit Aktionen, die die Middleware dann ausführt. Weiterhin kann die Anwendung an die Middleware sog. service requests senden. Für jeden Dienst (engl. service) enthält das Anwendungsprofil alternative Wege und dazugehörige Anforderungen, von denen die Middleware den jeweils passenden auswählt. Der Ansatz reflexiver Middleware erlaubt somit die Trennung der Adaptionslogik von der Adaption selbst und den Zugriff der Anwendung auf Metadaten der Middleware. Zudem können kontextunabhängige Anwendungen entwickelt werden, die lediglich Strategien vorgeben, welche die Middleware dann kontextabhängig umsetzt. Die sich daraus ergebenen Probleme, wie sich widersprechende Strategien und die Gefahr durch den reflexiven Zugriff auf Interna der Software, teilt sich dieser Ansatz mit einer Vielzahl anderer Adaptionskonzepte. Es sei darauf hingewiesen, dass Middleware ein streitbares Thema im Bezug auf adaptive Softwarearchitekturen ist. Zwar lassen sich mit ihrer Hilfe adaptive Systeme umsetzen, die Adaptivität liegt dabei aber auf der Seite der Middleware - die Anwendung merkt davon meist nichts. Gerade aufgrund der aufkommenden reflexiven Middleware tritt jedoch die Zusammenarbeit 13 mit der Anwendung in den Vordergrund, weshalb dieses Konzept hier aufgeführt wurde. Offensichtlich gibt es zwischen den bisherigen Ansätzen für dynamische Architekturen teilweise starke Unterschiede bezüglich der Granularität der Adaption (wird eine Prozedur, ein Modul, Objekt oder eine Komponente adaptiert?), den unterstützten Adaptionsmechanismen und -techniken, und natürlich in Leistung, Automatisierungsgrad, Flexibilität u. v. m. [Ketfi et al., 2002a]. Eine universelle Antwort auf die Frage, welche architektonischen Eigenschaften 13 Dieser Trend der Zusammenarbeit anwendungsinterner und -externer Mechanismen wird als application-aware adaptation [Satyanarayanan et al., 1995] bezeichnet. Copyright TU Dresden, Stefan Pietschmann 40 von 82

47 2. Adaptive Web-Systemarchitekturen Abb. 2.12: Funktionsweise reflexiver Middleware [Capra et al., 2001b] eine dynamische Softwarearchitektur besitzen sollte, existiert nicht [Dowling und Cahill, 2001]. 2.7 Besonderheiten adaptiver Web-Architekturen Da sich diese Arbeit im Speziellen mit der dynamischen Adaption von Web-Anwendungen beschäftigt, sollen im Folgenden Besonderheiten der Internet-Domäne für Softwarearchitekturen herausgestellt werden. Generell gelten auch für diese Systeme die gleichen Anforderungen, Problemen und Prinzipien, wie sie in Kapitel 2.3 formuliert wurden. Aufgrund der Request- Response-basierten Interaktion mit dem Nutzer und der physischen Trennung des Servers vom Nutzer und dessen Endgerät gibt es jedoch einige Eigenheiten. Die Adaptivität kann zunächst auf zwei Ebenen erfolgen [McCann et al., 2003]: Am häufigsten wird sie auf dem inter-request Level umgesetzt, d. h. es gibt Veränderungen, die von einem Request zum anderen stattfinden. Ein einfaches Beispiel dafür ist die Auswahl eines Bildes je nach Auflösung des Client-Endgerätes. Adaptionen des intra-request Levels vollziehen sich hingegen während der Verarbeitung des Requests, z. B. in Form der Anpassung eines Video- Streams an die augenblickliche Bandbreite des Nutzers durch den dynamische Wechsel des Codecs [McCann et al., 2000]. Web-Systeme, die nach dem inter-request -Prinzip adaptieren, folgen einem recht einfachen Datenfluss. Dieser basiert auf der schrittweisen Verarbeitung der Daten vom Request zur Response, folgt also dem Architekturstil UPF. Da diese Verarbeitung in der Regel nur einige Millisekunden in Anspruch nimmt, ist die Reaktion auf zwischenzeitliche Veränderungen - auch aus Sicht der Konsistenz- und Integritätssicherung - nicht sinnvoll. Vielmehr sollten die Systeme - dem Planungsparadigma folgend - die Ausführung beim Eintreffen des Requests unter Berücksichtigung der augenblicklichen Gegebenheiten planen und dann starten. Die Verwendung von Events für das Auslösen von Rekonfigurationen ist hier unpassend. Eine fundamentale Besonderheit besteht in der Trennung von Laufzeit- und Einsatzumgebung, die bei normalen Anwendungen so nicht vorliegt. Da der Server physisch vom Nutzer und dessen Endgerät getrennt ist, gilt es auf beiden Seiten auf Veränderungen des Kontextes zu reagieren. Deshalb werden in dieser Arbeit auch Client- und Serverkontext unterschieden (Kap ). Besonders für die Überwachung der unterschiedlichen Eigenschaften und Fähigkeiten von Clients müssen geeignete Mechanismen gefunden und entwickelt werden. In diesem Zusammenhang gewinnt auch eine andere Anforderung an webbasierte Systeme an Bedeutung: nebenläufige Prozesse, d. h. Multithreading. Diese folgen unvermeidlich aus dem parallelen Zugriff mehrerer Nutzer auf die Anwendung. Deren Architektur muss natürlich zweckmäßig aufgebaut sein, um die Anpassung an verschiedene, heterogene Clientkontexte zu ermöglichen. Copyright TU Dresden, Stefan Pietschmann 41 von 82

48 Man muss die Dinge so tief sehen, dass sie einfach werden. Konrad Adenauer, Analyse des bestehenden Adaptions- bzw. Verteilungskonzeptes in AMACONT Aus dem letzten Kapitel wird deutlich, welche Probleme und Aufgaben die Adaption einer Softwarearchitektur zur Laufzeit mit sich bringt, welche Methoden und Techniken dazu genutzt werden und wie unterschiedlich derartige Ansätze bezüglich ihrer Zielstellung und Umsetzung sein können. In diesem Kapitel soll untersucht werden, inwieweit das zu Beginn dieser Arbeit vorliegende Verteilungs- bzw. Adaptionskonzept für AMACONT den genannten Anforderungen gerecht wird und wo dessen Schwachstellen liegen. Zunächst erfolgt eine Einführung in die Architektur von AMACONT und das zugrunde liegende Framework Apache Cocoon [Cocoon, 2006]. Danach wird das Verteilungskonzept, welches im Rahmen des Komplexpraktikums MMT 1 im Wintersemester 2004/2005 entwickelt wurde, vorgestellt, analysiert und bewertet. Da es sich bei der Umsetzung nur um eine Teilaufgabe des Komplexpraktikums handelte, die schwerpunktmäßig die Verlagerung einer Serverkomponente auf den Client ermöglichen sollte, beschränken sich die genutzten Mittel auf diesen Verlagerungsaspekt und erlauben nur sehr rudimentär die Adaption der Softwarearchitektur. Durch die Analyse der Vor- und Nachteile des Konzeptes und seiner Umsetzung sollen Erkenntnisse für die Entwicklung eines mächtigeren, generischen Konzeptes zur Architekturadaption im nächsten Kapitel gewonnen werden. Copyright TU Dresden, Stefan Pietschmann 42 von 82

49 3. Analyse des Verteilungskonzeptes 3.1 Die AMACONT Dokumentgenerierung Um sowohl das zu Beginn dieser Arbeit bestehende, als auch das neue Adaptionskonzept verstehen und bewerten zu können, ist es nötig, sich genauer mit der Architektur von AMACONT auseinanderzusetzen. Im Folgenden soll ein kurzer Einblick in den Ablauf der Dokumentgenerierung gegeben werden. Voraussetzung dafür ist das Verständnis des Konzeptes der Cocoon Pipeline und derer Komponenten. Es wird jedoch nur auf die für diese Arbeit wesentlichen Punkte eingegangen - detailliertere Informationen finden sich beispielsweise auf der Cocoon Projektseite [Cocoon, 2006] oder im Cocoon Wiki [Cocoon Wiki, 2006] Die Pipeline Wie bereits in Kapitel 1.4 erwähnt, baut AMACONT softwaretechnologisch auf dem Projekt Cocoon der Apache Software Foundation (ASF) auf. Dessen elementares Konzept ist das Pipeline Modell, welches schematisch in Abb. 3.1 dargestellt ist. Der Datenfluss folgt dabei dem Architektur-Stil Pipe-and-Filter (siehe Kap ). Da die Komponenten der Pipeline alle die gleichen Schnittstellen nutzen, wird streng genommen der Stil Uniform Pipe-and-Filter (UPF) [Fielding, 2000] umgesetzt. Die Pipeline dient der schrittweisen Transformation eines XML-Dokuments - konkret dessen SAX-Events - durch eine Anzahl von Filtern, genannt Transformer. Diese können - zusammen mit Actions, die andere Aufgaben übernehmen (s. u.) - in beliebiger Reihenfolge angeordnet werden. Abb. 3.1: Pipeline Modell von Apache Cocoon Alle Pipelines und deren Komponenten werden in einer XML-basierten Datei konfiguriert - der Cocoon Sitemap. Am Anfang der Datei werden alle benötigten Pipeline-Komponenten spezifiziert und ggf. mittels Parametern konfiguriert. Danach können beliebig viele Pipelines definiert werden, die jeweils an ein bestimmtes Muster im Request gebunden sind oder von anderen Pipelines aufgerufen werden können. Die Sitemap ähnelt in Syntax und Semantik anderen XML-Pipeline-Sprachen, wie der XPL [Bruchez und Vernet, 2005] (siehe Kap ). Ein elementarer Unterschied zu XPL besteht darin, dass in Cocoon der SAX-Strom manipuliert wird, und nicht XML Infosets [Tobin und Cowan, 2004] Die Pipeline-Komponenten Die für AMACONT relevanten Komponenten werden nun kurz vorgestellt: Generatoren stehen zu Beginn jeder Pipeline. Sie wandeln einen Datenstrom aus beliebiger Quelle, z. B. einer Datei, in Simple API for XML (SAX)-Events um und leiten diese in die Pipeline. Transformer sind für die Transformation von XML-Dokumenten verantwortlich. Diese kann durch die Behandlung der SAX-Events, durch Manipulation des Document Object Model (DOM)-Baums oder mittels eines XSLT-Stylesheets geschehen. Copyright TU Dresden, Stefan Pietschmann 43 von 82

50 3. Analyse des Verteilungskonzeptes Actions verändern nicht den Datenstrom der in der Pipeline verarbeiteten Quelle, sondern u. U. den Datenfluss. Sie geben keinerlei sichtbare Daten aus, sondern dienen vielmehr der Abarbeitung interner Sachverhalte, wie der Auswertung von Formularen. Häufig wird das Resultat der Auswertung genutzt, um zu entscheiden, ob von der Action gekapselte Bereiche abgearbeitet werden sollen oder nicht. 1 Actions können zu einem Action-Set zusammengefasst und als Gruppe referenziert werden. Serialisierer stehen am Ende einer Pipeline und wandeln die SAX-Events in das Ausgabeformat um, z. B. XHTML, XHTML Mobile, WML, aber auch VRML oder PDF. Da Generatoren und Serialisierern eine gesonderte Bedeutung und feste Position am Anfang bzw. Ende der Pipeline zukommt, sind die zur Dokumentgenerierung wesentlichen Komponenten Actions und Transformer. Diese sind generell beliebig austausch- und umordbar, soweit die entstehende Topologie bezüglich ihrer Funktionen sinnvoll erscheint. Die Ermöglichung dynamischer Austauschbarkeit bzw. Änderung der Topologie ist Thema dieser Arbeit Ablauf der Dokumentgenerierung Abb. 3.2: Die AMACONT Pipeline Abb. 3.2 veranschaulicht die Dokumentgenerierung mit der AMACONT-Pipeline. Sie wird durch den Request eines Clients ausgelöst, dessen Anfrage dem zugeordneten Muster in der Sitemap entspricht 2. Zuerst wird das Action-Set generatemodel aufgerufen - ein Container für mehrere Actions, die die Kontextmodellierung übernehmen. Diese Komponenten sind essentiell, da sie die clientseitig (mittels Javascript) bzw. serverseitig (mittels DELI [Butler, 2002]) gewonnenen Kontextinformationen sammeln bzw. aktualisieren, die später die Grundlage für die Dokumentadaption bis hin zum gewählten Ausgabeformat bilden. Als nächster Schritt erfolgt die Generierung eines Datenstroms aus der angeforderten Ressource - einer XML-Datei im AMACONT Dokumentformat [Fiala et al., 2003]. Danach durchläuft der Datenstrom verschiedene Verarbeitungsschritte, wie die Auflösung interner oder externer 1 Folgenreich für die Konzeption ist die Tatsache, dass Actions bereits vor der Abarbeitung der Pipeline ausgeführt werden. Zum Zeitpunkt der Verarbeitung durch die Pipeline kann also keinerlei Einfluss mehr auf das Ergebnis der Actions genommen werden. 2 Zurzeit wird die AMACONT Pipeline für alle angeforderten Ressourcen mit der Endung *.ama ausgelöst. Copyright TU Dresden, Stefan Pietschmann 44 von 82

51 3. Analyse des Verteilungskonzeptes Referenzen, die Auswertung von Logiken bzw. Varianten zur Adaption auf Dokumentebene 3, die Umwandlung ins Ausgabeformat, das Hinzufügen von Links, die Einbettung externer Dokumentfragmente, die Adaption auf Basis von CDL4-Regeln sowie die Serialisierung des SAX-Stroms zur Auslieferung an den Client. 3.2 Architekturadaption mit dem Verteilungsmanager In diesem Abschnitt soll ein Überblick über das zu Beginn dieser Arbeit bestehende Konzept der Client-Server-Verteilung gegeben werden. Die zentrale Rolle spielt dabei der vom Komplexpraktikum Multimediatechnik I 2004/2005 erstellte Verteilungsmanager, welcher die Verlagerung einer serverseitigen Implementierung des CDL4-Algorithmus [Shen, 1996] auf den Client ermöglichen sollte. Das Prinzip basiert auf der Adaption der Architektur in der Art, dass die Komponente serverseitig aus-, und clientseitig eingeschaltet wird (bzw. umgekehrt). Somit wird rudimentär auch eine generellere Architekturadaptionen unterstützt. Zunächst werden die wichtigsten Komponenten des Verteilungsmechanismus, danach ihre Zusammenarbeit vorgestellt sowie die Möglichkeiten und Probleme dieses Konzeptes erörtert. Detailliertere Informationen bietet [Böhme et al., 2005] Der Verteilungsmanager Die Klasse DistributionManagerAction.java ist eine Cocoon Action. Ihre Aufgabe besteht darin, mit Hilfe einer Konfigurationsdatei und Monitorkomponenten eine bestimmte Konfiguration auszuwerten. Die Action hat dabei nur eine Vermittlerrolle, da sie das Ergebnis nicht selbst berechnet, sondern an die Monitorkomponenten der jeweiligen Konfiguration weiterleitet. Zum Auslesen des passenden Konfigurationsabschnitts nutzt sie die Klasse AmaConfigHandler. Diese behandelt die SAX-Events beim Parsen der Konfigurationsdatei mittel Apache Xerces [Xerces, 2006] und liefert ein Resultat zurück, wonach sich der Rückgabewert der Action an die Pipeline richtet. Er kann null oder eine Map sein. Im ersten Fall werden von der Action umschlossene Komponenten ignoriert, ansonsten ausgeführt. Mit Hilfe dieses einfachen Konzeptes lassen sich Bestandteile der Pipeline optional in Abhängigkeit einer Konfiguration definieren Die Konfigurationsdatei AmaConfig.xml Die Datei AmaConfig.xml enthält die sog. Konfigurationen, welche aus Referenzen auf Monitorkomponenten zusammengesetzt sind. Diese können mit Hilfe einer einfachen Syntax verknüpft werden. Die adressierten überwachten Parameter werden von den Monitoren ausgelesen und das Ergebnis der logischen Operation als boolean-wert an den Verteilungsmanager zurückgegeben Die Monitorkomponenten Die Überwachung von Umgebungsparametern bzw. Systemzuständen wird durch Monitore erledigt. Sie sind ebenfalls als Cocoon Action implementiert, werden aber nicht in der Sitemap genutzt, sondern nur vom Verteilungsmanager aus aufgerufen. Als Parameter erhalten 3 AMACONT Dokumente enthalten verschiedene alternative Komponenten und optionale Bestandteile, die in Varianten gekapselt sind. Zur Laufzeit werden die passenden Komponenten mit Hilfe von Logiken ausgewählt, die auf kontextuelle Informationen zurückgreifen (Dokumentadaption). Copyright TU Dresden, Stefan Pietschmann 45 von 82

52 3. Analyse des Verteilungskonzeptes Monitore einen oder mehrere Pfade zu überwachten Parametern zusammen mit einem logischen Operator. Die Ergebnisse der Operationen werden per AND verknüpft und bilden das Gesamtresultat für diesen Monitor. Die Methode act() liefert entweder null (entspricht false) oder new HashMap() (entspricht true) zurück. AbstractMonitorComponent Diese abstrakte Klasse dient als Muster bzw. Superklasse für andere Monitore. Sie stellt eine Liste mit allen Parametern zur Verfügung, die der Monitor unterstützt (und die somit in der Konfigurationsdatei spezifiziert werden können). Unter Zuhilfenahme der Methoden getparameterlist und getparameter kann auf diese Parameter zugegriffen werden, mittels setparameter können neue hinzugefügt werden. Die Parameter selbst sind wiederum vom Typ AmaConfigMonitorComponentParameter. ListOfMonitorComponents Eine Instanz der Klasse ListOfMonitorComponents.java ist eine Liste, die alle abzuarbeitenden Monitore und logischen Verknüpfungsoperatoren zwischen deren Einzelergebnissen enthält. Sie wird vom AmaConfigHandler genutzt, um aus der XML-Beschreibung einer Konfiguration einen Baum von Monitorkomponenten zu bauen. Da die Liste selbst vom Typ AbstractMonitorComponent ist, kann sie selbst sowohl einfache Monitorkomponenten, als auch wiederum Listen enthalten, wodurch eine - theoretisch beliebig tiefe - Hierarchie von Monitoren mit logischen Verknüpfungen aufgebaut werden kann. MonitorComponentContextModel Diese Klasse stellt die einzige konkret umgesetzte Monitorkomponente des Komplexpraktikums dar. Sie dient dem Auslesen von Parametern aus dem Kontextmodell, deren Pfade dem Monitor übergeben werden. Eine beispielhafte Konfiguration, die die clientseitige Unterstützung von Java und die Fensterbreite überprüft, zeigt Abb <?xml version=" 1. 0 " encoding="utf 8"?> 2 <config xmlns=" Amacont. de/amaconfigschema " xmlns:xsi=" org/2001/xmlschema instance " 3 xsi:schemalocation=" Amacont. de/amaconfigschema web/amaconfigschema. xsd "> < a c t c o n f i g id=" 1 "> 6 <monitorcomponent name=" MonitorComponentContextModel "> 7 <parameter name="/authentication/data/deviceprofile/browserua/javaappletenabled " comparator="==" value=" true "/> 8 <parameter name="/authentication/data/deviceprofile/browserua/window/innersize/innersizex " comparator=">=" value=" 500 "/> 9 </monitorcomponent> 10 </ a c t c o n f i g > </config> Lst. 3.1: Beispiel einer Konfiguration mit MonitorComponentContextModel Alle Monitore werden zur Laufzeit dynamisch eingebunden, d. h. sie laufen nicht ständig im Hintergrund, sondern werden erst mit der Aufnahme in die ListOfMonitorComponents vom AmaConfigHandler instanziiert. Sie sind nur für einen sehr kurzen Augenblick aktiv - die Nachteile dieser Implementierung werden später beleuchtet Einbindung und Nutzung in der Sitemap Der Verteilungsmanager wird als normale Action in eine Pipeline eingebunden. Er erhält als Parameter config_id einen Identifier, welcher auf die Konfiguration verweist, die überprüft werden soll. Durch den Parameter debug kann die Ausgabe von Debug-Informationen auf der Konsole eingeschaltet werden. Copyright TU Dresden, Stefan Pietschmann 46 von 82

53 3. Analyse des Verteilungskonzeptes 1 <map:pipeline... > <map:act type=" DistributionManager "> 4 <map:parameter name=" c onfig_id " value=" vrmlenabled "/> 5 <map:parameter name=" debug " value=" f a l s e "/> 6 <map:transform type=" rendervrml "... /> 7 </map:act> </map:pipeline> Lst. 3.2: Einbindung des DistributionManager in die Pipeline In Abb. 3.2 ist beispielhaft ein Teil einer Pipeline zu sehen, in der der XSLT-Transformer rendervrml nur dann ausgeführt wird, wenn die Konfiguration mit der ID vrmlenabled wahr ist. Die DistributionManager-Action kann an beliebiger Stelle in der Pipeline eingefügt werden und eine oder mehrere Komponenten enthalten. Die Bearbeitung des Requests läuft wie unter beschrieben. Enthält die Pipeline eine DistributionManager-Action, startet diese das Parsing der Konfigurationsdatei und übergibt dem dazugehörigen AmaConfigHandler den Parameter config_id. Trifft der Handler auf die passende Konfiguration, dann instanziiert er die nötigen Monitore und erstellt eine Liste der verwendeten Monitorkomponenten (ListOfMonitorComponents). Die Einzelergebnisse der Monitore werden gemäß der Logiken in der Konfigurationsdatei verknüpft und das Gesamtergebnis in Form von null oder einer HashMap an die Action zurückgeliefert. Basierend auf dieser Auswertung werden die Pipeline-Komponenten, die von der Action gekapselt werden, ausgeführt oder nicht Umsetzung der Client-Server-Verteilung Abb. 3.3: Pipeline mit Verteilungsmanager Die Verlagerung zwischen Server und Client wird generell durch die Definition alternativer Pipeline-Komponenten erreicht. Durch die geschickte Kapselung bestimmter Komponenten mittels der DistributionManager-Action wird dafür gesorgt, dass letztlich nur eine (oder keine) von ihnen ausgeführt wird. Mit Hilfe unterschiedlicher Parameter kann gesteuert werden, ob eine Komponente zum Client gesendet und dort ausgeführt werden soll, wenn dieser bestimmte Voraussetzungen erfüllt. Das serverseitige Pendant ist in diesem Fall an eine genau gegensätzliche Konfiguration geknüpft, sodass die Komponente nie sowohl server- als auch clientseitig ausgeführt werden kann. 4 Ziel des DistributionManagers war es, unter gewissen Umständen die Verteilung/Verlagerung der CDL4-Komponente vom Server auf den Client zu erlauben. Dies geschieht nach dem oben beschriebenen Muster: Die DistributionManager-Action kapselt sowohl die serverseitige CDL4-Komponente (CDL4), als auch die Rendering-Komponente, welche das AMACONT Dokumentformat mittels extensible Stylesheet Language Transformations (XSLT) in das Ausgabeformat umwandelt und in diesem 4 Die korrekte Definition und Zuordnung der Konfigurationen übernimmt der Administrator. Die Definition gegensätzlicher Konfiguration wird durch das Fehlen eines NOT-Operators allerdings erschwert. Copyright TU Dresden, Stefan Pietschmann 47 von 82

54 3. Analyse des Verteilungskonzeptes Fall zweimal - mit unterschiedlichen Parametern - in der Pipeline vorkommt (R1, R2). Die Parameter steuern, ob dem Ausgabedokument neben zusätzlichen Javascripts ein Applet hinzugefügt wird, welches clientseitig die Aufgaben des CDL4-Algorithmus übernimmt. Die referenzierten Konfigurationsabschnitte sind für die umschließenden Verteilungsmanager so gewählt, dass der Algorithmus entweder serverseitig ausgeführt und das Applet nicht zu Client geschickt wird, oder genau anders herum. Dies bedeutet, dass die config_id- Parameter der Verteilungsmanager um CDL4 und R1 gleich und genau gegensätzlich zu dem von R2 sind. Einen tiefer gehenden Einblick in die Arbeit des Komplexpraktikums bzw. die Verteilung und Synchronisation von Kontextmodellierungskomponenten bieten [Böhme et al., 2005] und [Hinz und Fiala, 2005b]. Die Verteilung und Verlagerung von Pipeline-Komponenten zwischen mehreren Servern war in der Aufgabenstellung nicht vorgesehen und wird dementsprechend von diesem Konzept nicht unterstützt Möglichkeiten der Architekturadaption Da die Entwicklung des Verteilungskonzeptes lediglich eine Teilaufgabe des Komplexpraktikums darstellte, ist es relativ stark auf das CDL4-Szenario zugeschnitten. Nichtsdestotrotz eignet sich der Verteilungsmanager als einfaches Werkzeug zur Architekturadaption, da er durch die bedingte Ausführung von Komponenten wichtige Adaptionsmethoden, wie das Hinzufügen, Entfernen, Austauschen und die Parameteradaption, ermöglicht (Kap ). 3.3 Bewertung und Schlussfolgerungen Im Folgenden sollen Schwachstellen und auch Vorteile des vorgestellten Konzeptes und seiner Implementierung aufgezeigt werden, um zur Anforderungsanalyse der Neu- bzw. Umkonzeption im nächsten Kapitel beizutragen Vorteile Der Mechanismus des Komplexpraktikums basiert auf dem Constraint-Konzept, für welches in Kapitel 2 bereits einige andere Ansätze vorgestellt wurden. Über die Ausführung einzelner Komponenten wird zur Laufzeit, basierend auf der Erfüllung bestimmter Voraussetzungen bzw. Verträge entschieden - hier etwas unglücklich als Konfigurationen bezeichnet 5. Die genutzte Adaptionstechnik - die konditionale Ausführung von Komponenten - ist ausreichend mächtig. Sie erlaubt das Austauschen, Hinzufügen und Entfernen von Komponenten und damit die komplette Änderung der logischen Topologie. Lediglich die Adaption von Komponentenparametern gerät etwas umständlich, da sie die Anpassung der gesamten Komponente erfordert. Konzeptionell ist der bisherige Ansatz also vielversprechend, hat aber - nicht zuletzt bei der Umsetzung - einige Schwachstellen, auf die im Folgenden eingegangen wird Nachteile Der größte konzeptionelle Nachteil des bisherigen Adaptions- bzw. Verteilungsmechanismus liegt in der Vernachlässigung der Trennung der Verantwortlichkeiten (SoC). Die Funktionsweise der Monitorkomponenten ist diesbezüglich streitbar. Neben der Überwachung von 5 Die Bezeichnung ist insofern unglücklich, als die Konfigurationen eher Systemzustände, genauer genommen Voraussetzungen oder Verträge für die Ausführung von Komponenten, beschreiben (vgl. die Definition einer Konfigurationen unter ). Copyright TU Dresden, Stefan Pietschmann 48 von 82

55 3. Analyse des Verteilungskonzeptes Umgebungsparametern führen sie auch logische Operationen auf diesen aus - ein Aspekt, der nach Meinung des Autors von der reinen Überwachungsfunktion getrennt sein sollte. Da die Monitore die Berechnungen intern durchführen, liefern sie nur true oder false, aber keine Werte zurück. Somit ist die Verknüpfung von Parametern unterschiedlicher Monitore nicht möglich 6. Auch monitorintern lassen sich Parameterergebnisse nicht beliebig nutzen, sondern sind per se mit AND verknüpft. Dadurch, dass die Klasse DistributionManagerAction.java eine Action implementiert und den dazugehörigen Cocoon-Mechanismus nutzt, verliert das Konzept zudem jegliche Anwendungsunabhängigkeit und ist komplett an Apache Cocoon gebunden. Die Entscheidung, Monitore ebenfalls als Actions zu implementieren, verstärkt dies noch mehr. Auch die dynamische Instanziierung der Monitore mit jedem Parsen einer Konfiguration ist kritisch zu betrachten. Sicherlich sind die Monitore dadurch nur für den (kurzen) Zeitraum des Aufrufes aktiv [Böhme et al., 2005]. Es sorgt aber auch dafür, dass mit steigender Nutzerzahl immer mehr Objekte instanziiert und zerstört werden, was sich negativ auf die Leistung auswirkt. Die kurze Lebensdauer verhindert weiterhin, dass längerfristige Aussagen getroffen werden können. So mag es beispielsweise von Interesse sein, wie sich die Auslastung des Servers über einen bestimmten Zeitraum entwickelt hat, oder wie oft eine Komponente bisher ausgeführt wurde oder nicht. In [Böhme et al., 2005] wird angedeutet, dass Überwachungen solcher Art durch ein externes Programm übernommen werden sollen, welches diese Informationen der Monitorkomponente zur Verfügung stellt. In komplexen Sitemaps wird die Schachtelung des Verteilungsmanagers um jede einzelne Komponente schnell unübersichtlich und verursacht nicht zuletzt auch einen Overhead für den Sitemap Prozessor. Die Beschränkung auf den Action-Mechanismus erfordert auch, dass bei der Veränderung eines Parameters die gesamte Komponente erneut definiert werden muss. Grund dafür ist, dass Actions lediglich Komponenten kapseln, und deren Ausführung steuern können, jedoch keinen Einfluss auf deren Parameter haben. Somit unterstützt das Konzept nur die Strukturadaption, d. h. die Adaption der logischen Topologie innerhalb der Pipeline. Durch die Referenzierung nur einer Konfiguration (per config_id) verliert man zudem die Möglichkeit, modulare Voraussetzungen zu kombinieren. Dies ist allerdings theoretisch durch die Schachtelung mehrerer Verteilungsmanager-Actions denkbar. Das Fehlen eines NOT-Operators bei der Referenzierung von Konfigurationen erfordert außerdem die Definition einer komplett gegensätzlichen Konfiguration. 1 < a c t c o n f i g id=" 3 "> 2 <logic junctor=" not "> 3 <monitorcomponent name=" ServerPerformance "/> 4 <monitorcomponent name=" ContextModel "> 5 <parameter name="/authentication/... /JavaEnabled " comparator="==" value=" true "/> 6 </monitorcomponent> 7 </ l o g i c > 8 <logic junctor=" or "> 9 <monitorcomponent name=" NetworkPerformance "/> 10 </ l o g i c > 11 </ a c t c o n f i g > Lst. 3.3: Beispiel von Verknüpfungen in Konfiguration Generell ist die Spezifikation der Konfigurationen ungünstig, da sie auf Verknüpfungen von Monitoren, nicht Umgebungsparametern, beruht. Die verwendete Semantik ist teilweise unausgereift, wie Abb. 3.3 veranschaulicht. Sie zeigt laut [Böhme et al., 2005] die Verknüpfung (NOT(ServerPerformance AND ContextModel) OR NetworkPerformance). Dies folgt aus der impliziten AND-Verknüpfung von Monitoren. Die Position der OR-Logik bleibt jedoch fragwürdig und dürfte den Autor/Administrator eher verwirren. 6 Zu diesem Zweck bietet die AbstractMonitorComponent die Methode getparameter(), die allerdings geschützt und bisher ungenutzt ist. Copyright TU Dresden, Stefan Pietschmann 49 von 82

56 3. Analyse des Verteilungskonzeptes Schlussfolgerungen für die Neukonzeption Wie bereits erwähnt ist das vorliegende Konzept des Komplexpraktikums - sicherlich auch aufgrund des engen Zeitrahmens - relativ beschränkt auf die Verlagerung der CDL4-Komponente zwischen Server und Client. Für ein mächtigeres, generisches Konzept erwachsen aus vorgestellten Vor- und Nachteilen einige Anforderungen: Anwendungsunabhängigkeit (keine Nutzung von Actions); Parameteradaption 7 ; Nutzung des bestehenden Adaptionsschemas [Pietschmann, 2005] zur Definition logischer und mathematischer Verknüpfungen zwischen Kontextparametern; Trennung dieser logischen Operationen von der Überwachungsebene; Dynamische Instanziierung von Monitoren für eine Session, nicht für jede Auswertung; Definition mehrerer Voraussetzungen für eine Komponente; Nutzung eines NOT-Operators zur Vermeidung von Redundanz. Die Idee der bedingten Ausführung von Komponenten ist an sich ein einfacher, aber effizienter Weg, um Adaptivität in einer pipelinebasierten Architektur zu ermöglichen. Die Umsetzung durch das Komplexpraktikum ist jedoch aufgrund verschiedener Umstände für die Erfüllung der Aufgabenstellung unzureichend. Auf Basis des gleichen Prinzips wird deshalb im nächsten Kapitel mit Hilfe der o. g. Erweiterungen ein flexibleres, generisches Konzept entworfen. 7 Mit Parameteradaption ist die Anpassung einzelner Komponentenparameter gemeint, ohne die gesamte Komponente austauschen zu müssen (= Strukturadaption bzw. Adaption der logischen Topologie). Copyright TU Dresden, Stefan Pietschmann 50 von 82

57 Keine Zukunft vermag gutzumachen, was Du in der Vergangenheit versäumst. Albert Schweitzer, Entwicklung eines flexiblen Konzeptes zur Architekturadaption in AMACONT Basierend auf den Anforderungen adaptiver Systeme aus Kapitel 2 und den Erkenntnissen aus Kapitel 3 wurde ein System konzeptioniert, welches die Überwachung und Analyse von Systemzuständen (Systemkontext) sowie die Entscheidung zur Architekturadaption übernimmt. Es dient der Erweiterung jeglicher pipelinebasierter Architektur um dynamische Adaptivität und basiert auf dem Konzept des bestehenden Verteilungsmechanismus (Kap. 3). Grundidee ist die Verknüpfung von Komponenten und deren Parametern mit Vorbedingungen (sog. Requirements), welche durch beliebige Kontextparameter und deren Verknüpfungen beschrieben werden können. Da in AMACONT bzw. Cocoon die Architektur deklarativ in Form einer Sitemap beschrieben ist, findet die Zuordnung der ebenfalls deklarativ beschriebenen Bedingungen dort statt. In diesem Kapitel werden die drei Ebenen des Konzeptes und ihre Zusammenarbeit näher vorgestellt sowie Syntax und Semantik für die Definition von Bedingungen und deren Verknüpfung mit Komponenten der Anwendung näher erläutert. Copyright TU Dresden, Stefan Pietschmann 51 von 82

58 4. Entwicklung des Konzeptes 4.1 Grundlagen, Anforderungen und Ziele des Konzeptes Grundlagen Grundlage des neuen Konzeptes bilden pipelinebasierte Systeme, wie sie in Kapitel vorgestellt wurden. Im Fall von AMACONT handelt es sich um das Apache Cocoon Framework [Cocoon, 2006]. Durch das zu konzeptionierende System soll eine bestehende Anwendung, die bisher keine dementsprechenden Schnittstellen für externe Eingriffe bietet, um Mittel zur Kontextüberwachung und -analyse sowie Adaptionsentscheidung erweitert werden. Diese Erweiterung wird im Folgenden auch als adaptives Subsystem bezeichnet Anforderungen und Ziele Allgemeine Anforderungen an ein adaptives System wurden bereits in Kapitel vorgestellt. Sie gelten auch für das zu entwerfende Konzept, allen voran die Trennung von Anwendung und Adaptionslogik, Generische Funktionalität, Performanz und Flexibilität. Die Tatsache, dass ein System zur dynamischen Adaption einer bereits bestehenden Anwendung konzeptioniert werden soll, führt zu einigen Beschränkungen. So sind in jedem Fall Änderungen an der Anwendung nötig, um das Adaptionsmanagement aufzurufen. Da diese möglichst gering gehalten werden sollen und die Trennung der Verantwortlichkeiten im Vordergrund steht wird vorausgesetzt, dass die Anwendung die eigentliche Durchführung der Adaption, und somit auch die Konsistenzsicherung übernimmt. Das adaptive System ist hingegen für die Überwachung des Kontextes, dessen Analyse und die Entscheidung über Adaptionen verantwortlich. Zur Kommunikation zwischen Anwendung und adaptivem Subsystem bedarf es einer Schnittstelle. Im Folgenden sind einige Anforderungen aufgelistet, die an das neue Konzept gestellt werden. Eine allgemeinere Übersicht erfolgte bereits in Kapitel Ermöglichung einer dynamischen Pipeline durch Adaption sowohl ihrer Komponenten als auch deren Parameter zur Laufzeit; Deklarative Spezifikation von Vorbedingungen für Pipeline-Komponenten und deren Parameter; Flexibilität und leichte Erweiterbarkeit des adaptiven Subsystems; Anwendungsunabhängigkeit, jedoch hauptsächlich Unterstützung von Anwendungen des Planungsparadigmas und des Architekturstils (Uniform) Pipe-and-Filter; Trennung der Verantwortlichkeiten innerhalb des adaptiven Subsystems. Das entstehende System soll die folgenden Adaptionsmethoden hinreichend unterstützen, mit deren Hilfe sich alle in Kapitel 1.1 aufgeführten Szenarien umsetzen lassen: Ein- und Ausschalten von Komponenten (entspricht dem Hinzufügen, Entfernen und implizit Austauschen von Komponenten); Adaptive Komponentenparameter (darüber erfolgt auch die Client-Server-Verlagerung, siehe Kap. 4.4); Änderung der logischen Topologie (implizit durch die mehrfache, alternative Spezifikation von Komponenten in der Pipeline) Einordnung in den Kontext selbst-adaptiver Systeme Das zu entwickelnde Konzept wird im Folgenden in das Feld adaptiver Systeme eingeordnet. Dafür wird zuerst der Ansatz aus Kapitel , danach einige Charakteristika aus Kapitel genutzt. Copyright TU Dresden, Stefan Pietschmann 52 von 82

59 4. Entwicklung des Konzeptes Wer adaptiert? Das Konzept ermöglicht die Adaption durch die Software selbst. Was wird adaptiert? Eine komponenten- und pipelinebasierte Softwarearchitektur wird angepasst. Warum wird adaptiert? Die Adaption soll die Anwendung an kontextuelle Veränderungen anpassen (adaptive Adaption) und deren Leistung optimieren (perfektive Adaption). Die Einbindung zusätzlicher Komponenten (erweiternde Adaption) ist ebenso möglich. Wann wird adaptiert? Die Adaption findet zur Laufzeit statt (im Fall von AMACONT mit jedem Start der Verarbeitung durch die Pipeline). Wie wird adaptiert? Das Konzept unterstützt alle wesentlichen Methoden zur Adaption der logischen Topologie und Implementierung. Dies wird durch die bedingte Ausführung adaptiv parametrisierter Komponenten erreicht. Woran wird adaptiert? Auslöser für die Architekturadaption sind Veränderungen beliebiger Parameter des Client- und Serverkontextes. Somit ergibt sich ein System, welches die automatische und dynamische Adaptivität in pipelinebasierten Softwarearchitekturen, ausgelöst durch kontextuelle Veränderungen, ermöglicht. Es dient nicht primär der Dokumentadaption - eine Erweiterung in diese Richtung ist jedoch denkbar und wird in Kapitel 6 vorgeschlagen. Aspekte der Lastverteilung zwischen mehreren Servern - die Adaption der physischen Topologie - wurden im Rahmen einer parallel laufenden Diplomarbeit für das AMACONT-Projekt beleuchtet [Umbach, 2006] und werden hier nicht betrachtet. Da dynamische Veränderungen der konzeptionellen Bestandteile des Komponentenmodells, der Regelbeschreibung und der Adaption selbst nicht vorgesehen sind, handelt es sich um ein geschlossen-dynamisches System. Der Ansatz folgt dem Open-Closed-Prinzip 1 [Meyer, 1998], d. h. die Anwendung wird nicht durch Veränderungen an ihrem Quelltext, sondern durch das Hinzufügen (bzw. Entfernen) von Code adaptiert. Die Rekonfigurationen sind programmiert und basieren auf der Verknüpfung von Komponenten mit Bedingungen. Je nachdem, ob diese erfüllt sind oder nicht, findet die Adaption der Architektur auf Initiative der Anwendung selbst, also implizit statt. Ad-hoc Adaptionen können jedoch auch explizit durch die Veränderung der Verknüpfungen und der Bedingungen selbst zur Laufzeit vorgenommen werden. 4.2 Ein 3-Ebenen-Konzept zur Architekturadaption Im folgenden Abschnitt wird das entwickelte 3-Ebenen-Konzept zur Adaption pipelinebasierter Softwarearchitekturen beschrieben. Es folgt dem Prinzip des Verteilungsmanagers - der konditionalen Ausführung von Komponenten. Wie in [Rigole et al., 2004] werden diese nur ausgeführt, wenn ihre Verträge - hier als Requirements bezeichnet - erfüllt sind. Die Aufgaben der dynamischen Anpassung - Überwachung, Analyse und Adaption - werden von drei unterschiedlichen Schichten übernommen, deren Verantwortlichkeiten gemäß dem Prinzip der SoC [Hürsch und Lopes, 1995] klar getrennt sind. Abb. 4.1 veranschaulicht das Konzept. Eine derartige Aufteilung zwischen den Überwachungs-, Analyse-, Planungs- sowie Adaptionsmechanismen in Ebenen ist in vielen adaptiven Ansätzen zu finden, beispielsweise im System CASA [Mukhija und Glinz, 2004] oder in [Garlan et al., 2001; Bharghavan und Gupta, 1997]. 1 Das Open-Closed-Prinzip (OCP) besagt, dass Software-Entitäten offen für Erweiterungen, aber geschlossen für interne Modifikationen sein sollen [Suzuki und Yamamoto, 1999a]. Copyright TU Dresden, Stefan Pietschmann 53 von 82

60 4. Entwicklung des Konzeptes Abb. 4.1: 3-Ebenen-Konzept der Architekturadaption Anwendungsebene Die Aufgabe dieser Ebene ist es, die Anwendung vor der Adaption in einen konsistenten (sicheren) Zustand zu bringen und - über eine festgelegte Schnittstelle - zum Adaptionsmanagement zu verzweigen, um die Bedingungen einzelner Komponenten und Parameter zu prüfen. Von dort erhält sie die Informationen, ob die Bedingungen erfüllt sind und wie die adaptiven Parameter aufgelöst werden. Die Semantik dieser Informationen ist nicht festgelegt, d. h. die Anwendung kann beliebig darauf reagieren. Häufig wird das Ergebnis der Bedingungen für die (De)Aktivierung der Komponente sorgen. Die Aufgaben des Anwendungsentwicklers sind also zum einen die Definition von Ausführungsbedingungen (Requirements) bzw. Konfigurationen für Komponenten, und zum anderen die Realisierung der Verzweigung zum Adaptionssubsystem. Auf diese beiden Punkte wird nun genauer eingegangen. Spezifikation von Ausführungsbedingungen Um die Architektur an kontextuelle Veränderungen anpassen zu können, müssen Grenzen definiert werden, bei deren Überschreitung reagiert werden soll. Dafür werden nicht speziell die Änderungen des Kontextes beschrieben, sondern vielmehr der Bereich, in dem das System bzw. eine Komponente korrekt arbeiten kann. Diese Bereiche werden als (Vor)Bedingungen oder Requirements bezeichnet und sind mit Verträgen (contracts) vergleichbar 2 [Mukhija und Glinz, 2003; Gorinsek et al., 2003; Preuveneers und Berbers, 2005, u. a. ]. Sind alle Vorbedingungen einer Komponente erfüllt, so wird diese ausgeführt. Insofern stellen die Requirements eine Art Abstraktion bzw. Interpretation der kontextuellen Informationen dar - ein logisches Gebilde, wie etwa canrunapplet, auf das die Anwendung zurückgreifen kann, ohne Wissen über die beinhalteten Low-level-Kontextparameter zu benötigen. Der Entwickler kann unbeschränkt viele solcher Bedingungen spezifizieren, die auf beliebige Kontextinformationen, wie Nutzerpräferenzen oder die Verfügbarkeit von Ressourcen, zugreifen, und sie - anwendungsspezifisch - mit einzelnen oder Gruppen von Komponenten oder deren Parametern verknüpfen. Wie diese Verknüpfung erfolgt, ist allein der Anwendung vorbehalten und wird für das System AMACONT in Kapitel 4.5 erläutert. 2 Es existiert jedoch ein kleiner Bedeutungsunterschied: Bedingungen werden meist dazu genutzt, um über die Ausführung und Konfiguration von Komponenten zu entscheiden. Bei der Nutzung von Verträgen wird das Gesamtsystem hingegen so angepasst, dass alle Komponenten vertragsgemäß arbeiten. Copyright TU Dresden, Stefan Pietschmann 54 von 82

61 4. Entwicklung des Konzeptes Die Beschreibung der Bedingungen erfolgt in Form von XML und nutzt das AMACONT Adaptionsschema [Pietschmann, 2005], da dieses eine solide Basis zur Definition von Kontextparametern und deren logische und mathematische Verknüpfung mit Hilfe von Termen ermöglicht. Die Syntax und Semantik hierzu wird in Kapitel genauer erläutert. Verzweigungen zum Adaptionsmanagement Wenn Bedingungen definiert und mit Komponenten verknüpft wurden, so muss dafür gesorgt werden, dass sie zur Laufzeit ausgewertet werden. Dies bedeutet, dass der Anwendung Aufrufe des adaptiven Subsystems (Adaptation Kernel) hinzugefügt werden müssen. Das kann durch Ersetzen oder Erweitern von Klassen der Anwendung geschehen, wie es in [Yang et al., 2002] anhand sog. BehaviorAdaptors vorgeschlagen wird (Abb. 4.2). Diese beschreiben ein Codefragment der Anwendungsebene, das eine Methode M der Anwendung ersetzt, um 1 Daten für M vorzuverarbeiten oder zu transformieren, 2 Parameter oder Ergebnisdaten von M zu bearbeiten oder 3 in den Adaptation Kernel zur Umsetzung dynamischer Adaption zu verzweigen. Abb. 4.2: Dynamisch adaptives Programm nach [Yang et al., 2002] Dem Entwickler bzw. Administrator einer Web-Anwendung kommen mit dem Einsatz des Adaptionskonzeptes folglich zwei essentielle Aufgaben zu: 1. die Erweiterung der Anwendungsklassen um Aufrufe des Adaptionsmanagements und 2. die Definition von Requirements und deren Verknüpfung mit Komponenten derart, dass sich zur Laufzeit sinnvolle Topologien - möglichst ohne Redundanzen - ergeben. Dazu sollte er mit der Funktionsweise und den Anforderungen der Komponenten gut vertraut sein Adaptionsmanagementebene Das Adaptionsmanagement hat die Aufgabe, die von der Anwendung übermittelten Bedingungen unter Nutzung der vorliegenden Kontextinformationen auszuwerten, und daraufhin eine Adaptionsentscheidung zu treffen. AdaptationManager Der AdaptationManager bildet die Schnittstelle zwischen Anwendung und adaptivem Subsystem und ist für die Verknüpfung einzelner Bedingungen und die Auswertung adaptiver Copyright TU Dresden, Stefan Pietschmann 55 von 82

62 4. Entwicklung des Konzeptes Parameter zuständig. Die Ergebnisse bestimmen in AMACONT letztlich, ob und in welcher Konfiguration Komponenten ausgeführt werden. ConfigurationSourceHandler Der ConfigurationSourceHandler dient der Auswertung einzelner Requirements unter Nutzung der Monitoringebene. Er erhält vom AdaptationManager die ID einer benötigten Vorbedingung, sucht die passende Definition in der Konfigurationsdatei, lässt sich die Werte der enthaltenen Kontextparameter vom MonitorManager übergeben, verknüpft diese entsprechend den Termvorschriften und liefert das Ergebnis an den AdaptationManager zurück Monitoringebene Diese Ebene dient der Bereitstellung kontextueller Informationen. Diese werden von den höheren Schichten zur Analyse und Auswertung von Bedingungen und damit zu Adaptionszwecken benötigt. MonitorManager Das zentrale Objekt dieser Schicht bildet der MonitorManager. Er funktioniert ähnlich wie ein ResourceManager und bietet der darüberliegenden Adaptionsmanagementschicht eine Schnittstelle, um auf die Parameter verschiedenster, registrierter Monitore zuzugreifen. Zudem ist er für deren Erstellung, Registrierung und Deregistrierung verantwortlich. Monitore Monitore führen die eigentliche Überwachung des Kontextes, d. h. sämtlicher, durch das System beobachtbarer Informationen, durch. Dies kann durch das Auslesen eines Nutzermodells, das eigenständige Erfassen von Informationen oder den Zugriff auf andere Überwachungsmechanismen geschehen. Dabei muss zwischen Serverkontext- und Clientkontext-Monitoren unterschieden werden, da Web-Anwendungen sowohl die Umgebung auf der Client- als auch auf der Serverseite berücksichtigen sollen. Der Serverkontext ist bei nicht-verteilten Web-Anwendungen für alle Clients gleich, kann also von einem globalen Monitor überwacht werden. Für Parameter des Clientkontextes bedarf es allerdings mehrerer Monitore, die den jeweiligen Nutzern bzw. Sessions zugeordnet sind. 4.3 Prinzip des zweistufigen Caching In Abb. 4.1 sind zwei Caches zu sehen, die der Leistungssteigerung des Systems dienen. Auf der Ebene des Adaptionsmanagements befindet sich der RequirementCache. In ihm werden bereits berechnete Ergebnisse von Vorbedingungen zwischengespeichert, um das mehrfache Auslesen von Kontextinformationen und deren Verknüpfung zu Bedingungen während eines Requests zu minimieren. Bei der wiederholten Anfrage einer Bedingung kann deren Ergebnis direkt aus dem Cache gelesen werden. Dazu wird nach der Auswertung jedes Requirements geprüft, ob die darin enthaltenen Kontextparameter zwischengespeichert werden können oder nicht. Dies ist prinzipiell für all solche Parameter der Fall, die sich während der Abarbeitung des Requests nicht verändern können, z. B. der Pfad der Anwendung. Veränderliche Parameter müssen jedoch immer neu ausgelesen werden. Kontextmodellparameter können beispielsweise zwischen zwei Abfragen durch Modellierungskomponenten aktualisiert und verändert worden sein. Ob Parameter eines Monitors cachebar sind oder nicht, kann vom Autor oder Administrator konfiguriert werden (Kap ). Copyright TU Dresden, Stefan Pietschmann 56 von 82

63 4. Entwicklung des Konzeptes Eine weitere Caching-Stufe, der ParameterCache, befindet sich auf der Monitoringebene. Er enthält bereits abgefragte, cachebare Kontextinformationen und erspart bei wiederholter Anfrage den erneuten Aufruf von Monitoren. Dies ist insbesondere bei kostspieligen Kontextparametern, deren Auslesen zeit- oder rechenintensiv ist, von großem Vorteil. Der RequirementCache erlaubt also die Zwischenspeicherung der Ergebnisse von Bedingungen. Ist dies aufgrund veränderlicher Kontextparameter nicht möglich, so kann durch den ParameterCache immerhin das mehrmalige Auslesen cachebarer Parameter verhindert werden. 4.4 Client-Server-Verteilung mit dem 3-Ebenen-Konzept Teilweise können Komponenten der AMACONT-Architektur sowohl auf dem Server, als auch auf dem Client ausgeführt werden. Voraussetzung dafür ist, dass sie eine dafür vorgesehene Implementierung besitzen und diese vom Client unterstützt wird. Aufgabe des Komplexpraktikums im Wintersemester 2004/05 war es unter anderem, den CDL4-Algorithmus clientseitig, d. h. für das Endgerät des Nutzers umzusetzen. Dafür wurde ein CDL4-Applet erstellt, welches natürlich auf die clientseitige Installation des Java Plugins angewiesen ist. Die Information darüber kann als Kontextparameter modelliert und ausgelesen werden. Die eigentliche Verlagerung erfolgt mit Hilfe adaptiver Komponentenparameter die bestimmen, ob das Applet oder eine sonstige clientseitige Implementierung in die Antwort des Servers eingebunden wird oder nicht. Ist dies der Fall, müssen konditionale Komponenten am Anfang der Pipeline hinzugefügt werden, um die clientseitig erstellten Daten, die mit dem Request zurückgesendet werden, zu verarbeiten. Weiterhin muss die serverseitige Komponente in diesem Fall abgeschaltet werden. Da die Verlagerung von Komponenten zwischen Server und Client in dem pipelinebasierten Web-Szenario offensichtlich den Datenfluss ändert, ist die Adaption zumindest an diesen drei Stellen erforderlich. Auch hier liegt es in der Verantwortung des Administrators das System so zu konfigurieren, dass sich die server- und clientseitige Abarbeitung von Komponenten ausschließen. Am einfachsten kann dies durch gegensätzliche Bedingungen (mit Hilfe eines Negators) geschehen. 4.5 Verknüpfung von Komponenten mit Vorbedingungen Für die Umsetzung einer dynamisch adaptiven Pipeline müssen deren Komponenten mit Vorbedingungen verknüpft werden. Zur Laufzeit werden die Verknüpfungen aufgelöst, die referenzierten Bedingungen ausgewertet und daraufhin eine Entscheidung über die Adaption der Komponente bzw. deren Parameter getroffen (Abb. 4.3). Der folgende Abschnitt beschreibt die Verknüpfung von Komponenten der AMACONT-Architektur mit Vorbedingungen und deren Definition Erweiterung der Sitemap Mit der Sitemap bietet Cocoon eine deklarative Beschreibung seiner pipelinebasierten Architektur. Die enthaltenen Komponenten müssen nun mit den Bedingungen aus der Konfigurationsdatei verknüpft werden. Da leider kein (offizielles, valides) Schema für die Sitemap existiert, konnte die verwendete Syntax nicht festgeschrieben werden und wird im Folgenden näher erklärt. Allgemeine Informationen zu Syntax und Semantik der Cocoon Sitemap sind unter [Cocoon, 2006] einzusehen. Copyright TU Dresden, Stefan Pietschmann 57 von 82

64 4. Entwicklung des Konzeptes Abb. 4.3: Schematische Funktionsweise der Architekturadaption Adaptive Pipeline-Komponenten Listing 4.1 zeigt ein Beispiel, wie Pipeline-Komponenten mit Vorbedingungen verknüpft werden. Sie erhalten den zusätzlichen Parameter?requires, der eine Menge von Requirement- IDs (getrennt durch Komma) enthält. Hier besteht die Möglichkeit, einzelne Referenzen mit Hilfe eines not()-operators zu negieren. Nur wenn alle referenzierten Bedingungen erfüllt sind, wird die Action, das Action-Set oder der Transformer ausgeführt. 1 <map:match pattern=" * / * *. ama"> 2 <map:act set=" generatemodel "> 3 <map:parameter name="? requires " value=" not ( guest ) "/> 4 </map:act> 5 [... ] 6 <map:transform type=" templatesql "> 7 <map:parameter name="? requires " value=" sql, not ( highload ) "/> 8 <map:parameter name=" useconnection " value="mmt_miu"/> 9 </map:transform> 10 [... ] 11 </map:match> Lst. 4.1: Verknüpfung von Bedingungen mit Komponenten Adaptive Komponenten-Parameter Listing 4.2 verdeutlicht, wie sich konditionale Parameter von Pipeline-Komponenten ausdrücken lassen. Die Regeln lauten wie folgt: Dem Parameternamen wird? als Präfix vorangestellt. Die Syntax des Parameterwertes ist folgendermaßen zu verstehen: (Requirements)?Then-Zweig:Else-Zweig 3 Existiert der Parameter bereits (ohne Präfix?), so wird dieser durch das Ergebnis des adaptiven Parameters überschrieben. Sind die Bedingungen nicht erfüllt und es ist kein else-zweig vorhanden, wird der Parameter gelöscht. Auch hier kann der not()-operator genutzt werden. 3 Sind alle Bedingungen erfüllt, so nimmt der Parameter den Wert des Strings nach dem Fragezeichen an (then), ansonsten den nach dem Doppelpunkt (else). Dies ist an die verkürzte Schreibweise von if-anweisungen in Java angelehnt. Copyright TU Dresden, Stefan Pietschmann 58 von 82

65 4. Entwicklung des Konzeptes 1 <map:transform type=" addlinks "> 2 <map:parameter name=" componenttag " value=" span "/> 3 <map:parameter name="?componenttag " value=" ( desktop )?span:comp "/> 4 <map:parameter name="?debug " value=" ( debug,not ( highload ) )? t r u e : f a l s e " /> 5 </map:transform> Lst. 4.2: Verknüpfung von Bedingungen mit Parametern Definition generischer Vorbedingungen Bereits in Kapitel wurde auf die Bedeutung von Bedingungen für Komponenten bzw. deren Parameter eingegangen. Nun wird ein Überblick über die Beschreibung dieser sog. Requirements gegeben. Alle Vorbedingungen werden in einer XML-basierten Konfigurationsdatei festgelegt. Standardmäßig befindet sich diese unter config/amaconfig.xml und wird durch das Schema AmaConfig.xsd beschrieben. Pfad und Dateiname können aber beliebig geändert werden (näheres dazu im Kapitel 5.2.4, Konfiguration). Da die Datei später auch für anderweitige Einstellungen von AMACONT genutzt werden soll, sind die Bedingungen unterhalb des Wurzelelementes <acon:amaconfig> im Tag <acon:systemadaptation> gekapselt. Dort können beliebig viele Requirements mit Hilfe des gleichnamigen Elements definiert, und mit einer obligatorischen ID und einer optionalen Beschreibung (description) versehen werden. Werte überwachter Kontextparameter werden mit Hilfe des Elementes <acon:parameter> eingefügt. Dieses enthält den Namen des Monitors, gefolgt von einer Raute und dem Namen des Parameters, z. B. ContextModel#JavaEnabled. Die Verknüpfung von Parametern untereinander oder mit Konstanten erfolgt mit Hilfe von Termen, die sowohl logische, als auch mathematische Operationen - ähnlich den synthetischen Attributen 4 aus [David und Ledoux, 2003] - ermöglichen. Neben der Verwendung von Kontextparametern können auch Ergebnisse anderer Requirements mit dem Element <acon:requirementref> eingebunden werden. Auf die Syntax der Terme wird in [Lehmann et al., 2003; Pietschmann, 2005] näher eingegangen. Abb. 4.3 veranschaulicht die Definition einer Bedingung, die erfüllt ist, falls der Kontextmodellparameter Device dem Wert Desktop entspricht, und das Browserfenster breiter als 800 Pixel ist. Anhand ihrer ID (desktop_wide) kann sie in der Sitemap referenziert, und mit Komponenten verknüpft werden. 1 <?xml version=" 1. 0 " encoding="utf 8"?> 2 <acon:amaconfig [... ] xsi:schemalocation=" Amacont. de/amaconfig AmaConfig. xsd "> 3 <acon:systemadaptation> 4 <acon:requirement id=" desktop_wide " description=" Device Configuration "> 5 <acon:term type=" and "> 6 <acon:term type="="> 7 <acon:parameter>contextmodel# Device</acon:Parameter> 8 <acon:const>desktop</acon:const> 9 </acon:term> 10 <acon:term type=" gt "> 11 <acon:parameter>contextmodel# InnerSize. InnerSizeX</acon:Parameter> 12 <acon:const>800</acon:const> 13 </acon:term> 14 </acon:term> 15 </acon:requirement> 16 [... ] 17 </acon:systemadaptation> 18 </acon:amaconfig> Lst. 4.3: Definition von Bedingungen in der Datei AmaConfig.xml 4 Synthetische Attribute bestehen aus einem oder mehreren einfachen Attributen, die mathematisch verknüpft sind. Statt der gesendeten Bytes einer Netzwerkschnittstelle sind eventuell die Werte in MB/s aussagekräftiger. Auch die Bandbreite eines Clients hat allein weit weniger Aussagekraft, als ihr Anteil an der dem Server zur Verfügung stehenden Gesamtbandbreite. Copyright TU Dresden, Stefan Pietschmann 59 von 82

66 4. Entwicklung des Konzeptes Garlan et al. [2001] regen an, die eigentlichen low-level Daten (von Probes gesammelt) auf höherer Ebene (durch Gauges) zu interpretieren und damit von der Anwendung zu entkoppeln. Diese Abstraktion und Entkopplung wird beim vorliegenden Konzept durch die Requirements erreicht, die für die Anwendung sinnvolle Eigenschaften beschreiben, indem sie low-level Parameter geeignet verknüpfen. Für den Anwendungsentwickler ist nur die abstrakte Bedingung, z. B. Cdl4AppletCapable, von Interesse - alle genutzten Kontextparameter können vom Administrator festgelegt werden. 4.6 Zusammenfassung Im vorliegenden Kapitel wurden zunächst Grundlagen und Anforderungen für die Konzeption dynamischer Architekturadaption beschrieben. Auf Basis dieser Erkenntnisse wurde ein System - bestehend aus drei Ebenen - vorgeschlagen, welches die Überwachung des Kontextes, die Analyse und Auswertung von Vorbedingungen sowie die Adaption der Architektur zur Laufzeit ermöglicht. Es erfüllt alle unter aufgeführten Anforderungen und unterstützt die geforderten Adaptionsmethoden. Kernprinzip des Konzeptes ist die deklarative Definition von Vorbedingungen in Form von XML und deren Verknüpfung mit Komponenten der Anwendung. Mit Hilfe des adaptiven Subsystems wird zur Laufzeit entschieden, ob sie erfüllt sind und ob bzw. in welcher Konfiguration Komponenten ausgeführt werden. Die Auswertung der Bedingungen erfolgt mit Hilfe von Monitoren, die verschiedene Parameter des Kontextes überwachen, und wird durch den Einsatz zweier Caching-Stufen beschleunigt. Generell bleibt es der Anwendungsebene überlassen, wie die Ergebnisse des Adaptionsmanagements genutzt werden. Für pipelinebasierte Architekturen wie AMACONT bieten sich die konditionale Ausführung von Pipeline-Komponenten und adaptive Komponentenparameter an, da sie die dynamische Adaption sowohl der Implementierung einzelner Komponenten, als auch der logischen Topologie der Softwarearchitektur erlauben. Ferner können so auch Komponenten auf den Client verlagert werden. Copyright TU Dresden, Stefan Pietschmann 60 von 82

67 There is little consensus in the research community on what architectural features a dynamic software architecture should contain. Dowling und Cahill [2001] 5 Technische Umsetzung und Bewertung des Konzeptes in AMACONT Dieses Kapitel beschreibt die softwaretechnische Umsetzung des entwickelten Konzeptes zur dynamischen Architekturadaption in AMACONT. Zunächst werden grundlegende Konzepte und Funktionsweisen von Apache Cocoon [Cocoon, 2006] geklärt, soweit sie zum Verständnis der Implementierung nötig sind. Danach folgt die Vorstellung der einzelnen Ebenen des SystemAdaptation-Frameworks und eine Beschreibung der vorgenommenen Eingriffe in die Cocoon- und AMACONT-Architektur. Danach wird die Kollaboration der Ebenen und Objekte bei der dynamischen Adaption näher erläutert und auf Konfigurationsmöglichkeiten eingegangen. Im Anschluss werden repräsentativ Beispiele gezeigt, die im Zuge dieser Arbeit entwickelt wurden und die Möglichkeiten und Vorteile des Konzeptes und seiner Umsetzung belegen. Zuletzt wird das dynamisch adaptive System bezüglich seiner Leistung analysiert und bewertet. Copyright TU Dresden, Stefan Pietschmann 61 von 82

68 5. Umsetzung und Bewertung 5.1 Implementierungsgrundlagen und Anforderungen In diesem Abschnitt werden die Grundlagen und Anforderungen an die Umsetzung des im letzten Kapitel vorgestellten Konzeptes erläutert Implementierungsgrundlagen Das Konzept zur Architekturadaption soll für das System AMACONT und das zugrunde liegende Framework Apache Cocoon [Cocoon, 2006] umgesetzt werden. Auf beide wurde bereits in Kapitel 3.1 eingegangen. Zunächst werden einige interne Abläufe von Cocoon vorgestellt, um dessen generelle Funktionsweise zu verdeutlichen. Dieses Wissen wird für das Verständnis der Implementierung des entwickelten Konzeptes - besonders auf der Anwendungsebene - benötigt. Das Cocoon Verarbeitungsmodell Cocoon ist eine geschichtete Architektur, die - im Falle von AMACONT - über ein Servlet angesprochen wird. Die Framework Schicht bildet einen Wrapper um die Infrastruktur (z. B. Logging, Thread Handling und Connection Pooling) und Komponenten von Apache Avalon [Avalon, 2004]. Deren grundlegende Funktionalitäten werden übernommen und teilweise durch Cocoon erweitert. So existieren Komponenten zum Generieren, Kompilieren, Laden und Ausführen von Logik, zum Generieren, Transformieren und Serialisieren von XML-Datenströmen usw. Die Koordination der einzelnen Verarbeitungsschritte übernimmt eine Pipeline, wie sie bereits in Kapitel vorgestellt wurde. Sie wird durch eine sog. Sitemap repräsentiert und konfiguriert. Die Verarbeitungsschicht verwaltet die Komponenten zur Verarbeitung des Request/Response Kreislaufs. Dies sind Sitemap-Komponenten und Logicsheets, wobei für die später vorgenommene Architekturadaption nur erstere relevant sind. Sitemap-Komponenten, wie Generatoren, Transformer, Serialisierer, Selektoren, Actions u. v. m., werden von der Pipeline im Zuge der Verarbeitung aufgerufen. Auf der Implementierungsebene befinden sich hauptsächlich Mechanismen, die Teil des Cocoon Frameworks sind. Dies umfasst Konfigurationsdateien, z. B. zur Definition und Konfiguration von Komponenten, sowie eigene Komponenten und Logicsheets. Auf der obersten Ebene des Verarbeitungsmodells befindet sich die Inhaltsschicht. Sie enthält die Daten, die für die Anwendung benötigt werden, in Form von XML, Datenbanken, HyperText Markup Language (HTML), Bildern u. v. m. Dieses in aller Kürze vorgestellte Modell zeigt, dass Veränderungen bereits auf der Frameworkund Verarbeitungsebene stattfinden müssen, um die dynamische Adaption der Pipeline zu ermöglichen. Implementierung und Inhalte der Web-Anwendungen, die in Cocoon und somit AMACONT laufen, bleiben davon unberührt. Verarbeitung der Cocoon Sitemap Dieser Abschnitt beleuchtet knapp die Verarbeitung der Sitemap, die in drei Phasen verläuft: 1 Generierung einer internen Repräsentation der Sitemap; 2 Aufbau einer Pipeline, die zum ankommenden Request passt; 3 Ausführung der Pipeline. Die Informationen sind [van der Linden, 2006] entnommen, wo eine detailliertere Beschreibung erfolgt. Beim Start von Cocoon wird die Sitemap in eine logische Baumstruktur (Abstract Syntax Tree) überführt, welche einen Knoten je Matcher, Generator, Transformer und jede weitere Copyright TU Dresden, Stefan Pietschmann 62 von 82

69 5. Umsetzung und Bewertung Komponente enthält. Mit jeder Änderung erfolgt diese Übersetzung erneut. Bei der Ankunft des ersten Requests wird der Baum ausgeführt, d. h. jeder Knoten wird mit den Informationen des Requests evaluiert. Ist das Ergebnis der Evaluation true, dann wird der enthaltene Unterbaum ausgeführt. Selektoren und Actions werden bereits hier auf Basis des Requests ausgewertet, womit am Ende dieses Verarbeitungsschrittes der lineare Verarbeitungsweg nur noch aus Generatoren, Transformern und Serialisieren besteht. Danach, und mit jedem weiteren Request, wird dieser Weg - die fertige Pipeline - abgearbeitet. Aus diesen Informationen ergeben sich zwei wichtige Erkenntnisse: Wenn sich die Verarbeitung dynamisch veränderlichen Umständen anpassen soll, muss die Pipeline adaptiert werden. Dies kann jedoch nur in der dritten Stufe, bei der Erstellung und Ausführung eben solcher erfolgen, da die Auswertung des Abstract Syntax Tree nur für den ersten, nicht aber für alle weiteren Requests erfolgt. Zu diesem Zeitpunkt - während Phase 3 - können allerdings die Actions nicht mehr angepasst werden, da sie bereits vorher ausgewertet werden. Deren Adaption muss also bereits in Phase 2 erfolgen. Somit muss die Implementierung auf der Anwendungsebene an zwei unterschiedlichen Stellen ansetzen: Sowohl die Pipeline, als auch die Action-Knoten müssen um Adaptivität erweitert werden. Abb. 5.1 veranschaulicht die Verarbeitung und diese beiden Ansatzpunkte. Abb. 5.1: Verarbeitung der Cocoon Sitemap mit Architekturadaption Anforderungen an die Implementierung Die Anforderungen an die Implementierung folgen aus den bereits in Kapitel angeführten Anforderungen an das Konzept. Dies bedeutet konkret: Trennung der Verantwortlichkeiten innerhalb des adaptiven Systems; Anwendungsunabhängigkeit, d. h. generelle Verwendbarkeit der Implementierung für beliebige UPF-basierte Software; Unterstützung dynamischer Veränderungen an der Adaptionslogik (in Form von Bedingungen) und der Pipeline; Flexibilität hinsichtlich der Adaption, d. h. Unabhängigkeit des Adaptionssystems von Inhalt und Umfang der Adaption auf Anwendungsebene; Copyright TU Dresden, Stefan Pietschmann 63 von 82

70 5. Umsetzung und Bewertung Konfigurierbarkeit und Erweiterbarkeit, beispielsweise soll der Wechsel der Konfigurationsdatei und das einfache Hinzufügen und Entfernen von Monitoren ohne Eingriff in den Quellcode möglich sein. Mit der Umsetzung des Konzeptes für AMACONT sollen letztlich die folgenden Adaptionsmethoden ermöglicht werden: Änderung der logischen Topologie (Hinzufügen und Entfernen von Komponenten); Änderung der Implementierung (Austauschen von Komponenten durch mehrfache Definition und Verknüpfung mit alternativen Bedingungen); Adaptive Komponentenparameter. Das System soll zunächst geschlossen dynamisch sein und keine automatische Anpassung der Adaptionslogik selbst erlauben. Cocoon erlaubt den dynamischen Wechsel der Pipelineimplementierung - und somit zumindest eines Teils der Anwendungsebene. Die Adaptionslogik kann weiterhin durch Änderungen an den Vorbedingungen von Komponenten modifiziert werden. Beide Wege ermöglichen die Adaption von Adaptionslogik- und -mechanismen, bedürfen jedoch des Eingriffs durch einen Administrator. 5.2 Softwaretechnische Umsetzung des Konzeptes In diesem Abschnitt wird das SystemAdaptation-Framework - die Umsetzung des 3-Ebenen- Konzeptes - vorgestellt. Neben den Aufgaben und Eigenschaften der beiden unteren, anwendungsunabhängigen Ebenen wird auch auf die durchgeführten Veränderungen an der AMACONT bzw. Cocoon-Architektur eingegangen. Ferner werden Konfigurationsmöglichkeiten und die Kollaboration aller Adaptionskomponenten zur Laufzeit beschrieben. Die vorgestellten Implementierungen befinden sich - bis auf die anwendungseigenen Action- Knoten - im Paket de.amacont.systemadaptation. Im Folgenden werden vor allem die Aufgaben der einzelnen Klassen geklärt - Details zu Methoden und der Implementierung können Anhang A und der Javadoc entnommen werden Umsetzung der Anwendungsschicht Dem Modell von Yang et al. [2002] folgend (Abb. 4.2) stellt diese Schicht die adaptierbare Anwendung dar, die mit Hilfe eines BehaviorAdaptors auf den Adaptation Kernel zugreift. Dieser Kernel entspricht im vorliegenden Konzept der Adaptionsmanagementschicht, die über den AdaptationManager angesprochen wird. Es ist die Aufgabe der Anwendung, also AMACONT/Cocoon, diesen an den entscheidenden Stellen aufzurufen (Abb. 5.2), um eine Adaptionsentscheidung zu erhalten. Die angepassten Stellen der Anwendung werden in den nächsten Abschnitten vorgestellt. Die Adaptive Pipeline Die Klassen AdaptiveNonCachingProcessingPipeline und AdaptiveProfilingNonCachingProcessing- Pipeline stellen Erweiterungen der bestehenden Pipeline-Implementierungen um adaptive Aspekte dar. Dazu definieren sie Verzweigungen zum AdaptationManager. Beide Klassen unterscheiden sich lediglich in ihrer Unterstützung des Cocoon Profiling-Mechanismus 1, der von der ersteren Pipeline nicht genutzt wird. Sie sind von den jeweiligen Standard- Implementierungen abgeleitet ((Profiling)NonCachingProcessingPipeline), deren Verhalten über 1 Näheres zum Profiling-Konzept in Cocoon unter concepts/profiler.html Copyright TU Dresden, Stefan Pietschmann 64 von 82

71 5. Umsetzung und Bewertung Abb. 5.2: Verknüpfung von Anwendung und SystemAdaptation-Framework super-aufrufe genutzt, und an bestimmten Stellen erweitert wird. Dadurch wird die Kompatibilität mit zukünftigen Versionen der Cocoon-Klassen gewahrt und Redundanz vermieden. Eine Erweiterung besteht in der Umsetzung des Observer-Patterns Gamma et al. [1995], welches die Überwachung von Pipeline-Ereignissen ermöglicht. Klassen, die die Schnittstelle PipelineListener implementieren, können sich bei der Pipeline registrieren und dadurch Events zu Beginn des Pipeline Setups sowie bei Start und Ende von deren Verarbeitung erhalten. Dieser Mechanismus ist beispielsweise notwendig, um die Caches (Kap. 4.3) am Ende jeder Request-Verarbeitung löschen zu können. Mit dem Einsatz von Cocoon 2.2 wird diese Funktion überflüssig, da sich das gleiche mit Hilfe der neu eingeführten EnterSitemapEventListener und LeaveSitemapEventListener-Schnittstellen erreichen lässt. Die adaptiven Pipelines überladen die Methode setuppipeline() der Standard-Implementierungen, in der für jeden enthaltenen Transformer dessen setup()-methode aufgerufen wird. Dort wird geprüft, ob die Ausführung der Transformer an Bedingungen geknüpft ist. Deren IDs werden an den AdaptationManager gesendet und der Transformer wird, je nach Rückgabewert, entweder aus der Verarbeitungsliste der Pipeline entfernt oder initialisiert. Für alle verbleibenden Transformer wird dann überprüft, ob sie adaptive Parameter enthalten. Ist dies der Fall, werden gleichnamige, bereits vorhandene Parameter entfernt, und durch den richtigen Parameterwert ersetzt, den wiederum der AdaptationManager liefert. Die eigentliche Ausführung der Pipeline bleibt von der Adaption unbetroffen, da ein Eingriff in die Abarbeitung der Cocoon Pipeline weder notwendig, noch zu empfehlen ist (Gründe dafür siehe Kap ). Diese Adaption der Pipeline zur Setup-Zeit folgt dem Planungsparadigma [Laddaga und Robertson, 2004] und ähnelt dem Konzept eines dynamischen Task Models, wie es in [den Bergh und Coninx, 2004] vorgestellt wird. Adaptive Actions & Action-Sets Da Actions und Action-Sets 2 in Cocoon nicht bei der Pipelineausführung, sondern bereits davor abgearbeitet werden (siehe Kap ), war es nötig, die Action und ActionSet-Klassen separat um Verzweigungen zum AdaptationManager zu ergänzen. Die Erweiterungen wurden jedoch in eigene Methoden und unter minimalem Eingriff in den bestehenden Code eingebracht, 2 Action-Sets bilden einen Container für eine Menge von Actions, der in der Pipeline über einen Namen referenziert werden kann. Copyright TU Dresden, Stefan Pietschmann 65 von 82

72 5. Umsetzung und Bewertung sodass auch hier einfache Updates auf neue Versionen der Klassen erfolgen können. Die Implementierung umfasst die beiden Klassen ActTypeNode, die einen Action-Knoten der Pipeline repräsentiert, und ActSetNode, der ein Action-Set darstellt, im Package org.apache. cocoon.components.treeprocessor.sitemap. Bei ihrer Initialisierung wird überprüft, ob sie Vorbedingungen oder adaptive Parameter besitzen, die beim Aufruf durch den TreeProcessor, d. h. vor dem Aufbau der Pipeline, ausgewertet werden. Je nach Ergebnis der verknüpften Bedingungen wird eine Action ausgeführt oder übergangen. Bei einem Action-Set wird eine Session-Variable gesetzt, über die die enthaltenen Actions genau diese Information auslesen können Umsetzung der Adaptionsmanagementschicht Alle Adaptionsentscheidungen, d. h. die Auswertung von Bedingungen und Auswahl adaptiver Parameter, werden vom Adaptionsmanagement in der gleichnamigen Schicht getroffen. Ein AdaptationManager wertet dazu mit Hilfe eines SAX-ContentHandlers die in der Konfigurationsdatei befindlichen Bedingungen aus. Der AdaptationManager Der Manager bietet der Anwendung eine Schnittstelle, um Bedingungen und bedingte Parameter zu übergeben. Er liefert entweder das Ergebnis der Bedingungen (true oder false), oder das Ergebnis des adaptiven Parameters zurück. Im Fall mehrerer Bedingungen werden deren IDs voneinander getrennt und einzeln dem ConfigurationSourceHandler übergeben. Die zurückgegebenen Einzelergebnisse werden vom Manager verknüpft und - falls dies vom Autor bei der Konfiguration erlaubt wurde - im RequirementCache zwischenspeichert. Wird eine Bedingung während eines Requests mehrfach benötigt, kann deren Ergebnis direkt aus dem Cache gelesen werden - das Parsen der Bedingungen und Auslesen der Kontextparameter entfällt. Der Manager überwacht außerdem, ob sich die Konfigurationsdatei zur Laufzeit verändert und lädt sie bei Bedarf nach. Die Implementierung des AdaptationManagers erfolgte als Avalon-Komponente, da dies sehr einfach das automatische Laden beim Start von Cocoon erlaubt. Trotzdem ist der Manager nicht an Cocoon gebunden und kann in beliebigen anderen Anwendungen eingesetzt werden, solange diese für seine Instanziierung sorgen. Ein weiterer Vorteil der Nutzung von Avalon ist die vorgeschriebene Trennung von Schnittstelle und Implementierung, wodurch der dynamische Tausch des Managers möglich wird, auch wenn dies zum jetzigen Zeitpunkt nicht vorgesehen ist. Der ConfigurationSourceHandler Dieser SAX-ContentHandler (er erbt vom AbstractXMLConsumer) dient dem AdaptationManager zur Auswertung der Bedingungen. Er behandelt die SAX-Events beim Parsen der AMACONT Konfigurationsdatei (AmaConfig.xml), sucht das referenzierte Requirement und wertet die enthaltenen Terme aus. Dazu greift er auf die Monitoringschicht zu, die die aktuellen Werte der benötigten Kontextparameter liefert. Der Handler verknüpft diese und liefert das Ergebnis dem AdaptationManager. Falls die referenzierte Bedingung nicht gefunden werden kann, so wird true zurückgegeben, denn wenn keine Voraussetzung vorliegt, kann die Komponente auch ausgeführt werden. In der Log-Ausgabe erscheint jedoch ein Fehler, um den Autor auf das Problem hinzuweisen. Copyright TU Dresden, Stefan Pietschmann 66 von 82

73 5. Umsetzung und Bewertung Umsetzung der Monitoringschicht Die Monitoringschicht bietet Zugriff auf Kontextinformationen über ein Query-Interface [David und Ledoux, 2003]. Im Gegensatz zu verschiedenen Ansätzen, bei denen die nächsthöhere Schicht über Veränderungen des Kontextes durch Events informiert wird [Ramdane-Cherif und Levy, 2002; David und Ledoux, 2003; Georgiadis et al., 2002; da Silva e Silva et al., 2003], werden die Kontextinformationen auf Initiative des Adaptionsmanagements ausgelesen. Aufgrund der einfachen Erweiterbarkeit um Monitore ist die Überwachung beliebiger, beobachtbarer kontextueller Parameter denkbar. Im Folgenden wird näher auf die Objekte der Monitoringebene eingegangen. Der MonitorManager Der MonitorManager ist, genau wie der AdaptationManager, in Schnittstelle und Implementierung getrennt, was letztere leicht austauschbar macht. Seine Aufgabe besteht in der Verwaltung von Monitoren - den eigentlichen Überwachungskomponenten. Der Manager ist für deren Instanziierung, Registierung bzw. Deregistrierung zuständig und erlaubt höheren Schichten die Abfrage von Parametern des Monitors über dessen ID. Zur Zwischenspeicherung von Kontextparameterwerten besitzt der MonitorManager den ParameterCache. Alle ausgewerteten, cachebaren Parameter (Kap ) werden für die Dauer der Verarbeitung eines Requests dort zwischengespeichert, um Redundanz durch den mehrfachen Aufruf von Monitoren zu vermeiden (Kap. 4.3). Die Monitore Monitor-Objekte realisieren die eigentliche Überwachung des Kontextes. Wie und woher sie Kontextparameter erhalten, ist dem Programmierer überlassen. Die Implementierung umfasst bei den bestehenden Monitoren beispielsweise das Auslesen von Informationen aus einem anderen Servlet (ServerLoadMonitor) oder aus dem bestehenden AMACONT Kontextmodell (ContextModelMonitor). In Kapitel wurde die Trennung von Serverkontext- und Clientkontext-Monitoren motiviert. Da erstere globale, für alle Nutzer gültige Werte liefern, müssen sie nur einmal beim Start von Cocoon initialisiert werden. ClientKontextMonitore sind hingegen an eine Session geknüpft und werden bei deren Start erstellt und registriert. Auf welche der beiden Arten ein Monitor konkret genutzt wird, hängt nicht von dessen Implementierung ab - die Schnittstelle ist für alle Monitore gleich - sondern wird durch dessen Konfiguration entschieden (Kap ). Die im Zuge dieser Arbeit entwickelten Monitore werden im Folgenden vorgestellt. 1. ContextModelMonitor Dieser Monitor wurde entwickelt, um auf Parameter des Kontextmodells des eingeloggten Nutzers zugreifen zu können. Unter Verwendung der Bibliothek JXPath [JXPath, 2006] aus dem Apache Jakarta Commons Projekt können beliebige Elemente des Modells mittels XPath [Clark und DeRose, 1999] ausgelesen werden. Die Adressierung eines Parameters kann sowohl über den Elementnamen allein, als auch über einen mehrstufigen Ausdruck der Form Grandparent.Parent.Node erfolgen. 2. ServerLoadMonitor Der ServerLoadMonitor liefert Parameterwerte, die den Zustand des Serversystems widerspiegeln, u. a. die Prozessor-, Netzwerk- und Gesamtlast. Er nutzt dazu die Informationen des Windows Performance Counters, die das LoadDistributor-Servlet [Umbach, 2006] ausliest und Copyright TU Dresden, Stefan Pietschmann 67 von 82

74 5. Umsetzung und Bewertung über die Java Management extensions (JMX) 3 zur Verfügung stellt. Der Monitor kann auf diese Werte zugreifen, indem er die passenden IDs für die Namensauflösung des JMX Pfades verwendet. Diese IDs in der Datei performance-counters.xml des LoadDistributors frei konfigurierbar. Nähere Informationen bietet [Umbach, 2006]. 3. TimingMonitor Dieser Monitor funktioniert wie ein Zähler, der die Zeit seit der letzten Abarbeitung einer Pipeline-Komponente speichert. Der Parameter due gibt true zurück, falls diese Zeit einen bestimmten Schwellenwert überschreitet. Dieser kann mit Hilfe des Monitor-Parameters threshold (Zeit in Sekunden) in der Konfigurationsdatei eingestellt werden. Auf diese Weise kann man eine Pipeline-Komponente nur in gewissen Abständen ausführen, um die Serverlast zu verringern. Beispielsweise ist es ausreichend, das LocationModeling nur sporadisch durchzuführen, wenn klar ist, dass sich der Nutzer nur langsam bewegt. Genauso denkbar wäre, nicht die Zeit seit der letzten Abarbeitung, sondern die Anzahl der vergangenen Requests aufzuzeichnen. 4. ApplicationMonitor Der ApplicationMonitor erlaubt den Zugriff auf Eigenschaften der genutzten Web-Anwendung. Zur Zeit unterstützt er lediglich den Parameter webapp, welcher den aktuellen Anwendungspfad ausgibt. In dessen Abhängigkeit lassen sich dann bestimmte Komponenten, beispielsweise zur Verschlüsselung, ausführen oder nicht Konfiguration des SystemAdaptation-Frameworks Die Konfiguration der SystemAdaptation-Klassen erfolgt über die Dateien web.xml und cocoon.xconf. Beide sind die klassischen Konfigurationsdateien für Apache Tomcat 4 und Cocoon. Für die Anwendung des Frameworks außerhalb von Cocoon kann die Konfiguration auch sehr einfach auf eine eigene Konfigurationsdatei umgestellt werden. Die Datei web.xml erlaubt es, Klassen als SessionListener zu registrieren. Auf diese Weise werden Adaptation- und MonitorManager bei Start und Ende von Sessions informiert, um beispielsweise Clientkontext-Monitore zu instanziieren bzw. zu zerstören. Die Datei cocoon.xconf enthält die Konfigurationen aller Avalon-Komponenten in Cocoon. Listing 5.1 zeigt eine Beispielkonfiguration. Im einzelnen können die folgenden Dinge eingestellt werden: AdaptationManager enabled Mit den Werten true oder false kann die Architekturadaption ein- oder ausgeschaltet werden. configfile Die Attribute file und check-reload geben an, an welcher Stelle sich die Konfigurationsdatei befindet, und ob sie auf Veränderungen zur Laufzeit überprüft, und gegebenenfalls dynamisch nachgeladen werden soll. MonitorManager servercontext-monitors Innerhalb dieses Elementes werden die Monitore definiert, die als Singleton von allen Nutzern verwendet werden können. Diese Monitore liefern insbesondere keine nutzerspezifischen Parameter. 3 JMX bietet eine einheitliche Schnittstelle und ein Objekt Repository für die Verwaltung von Anwendungen und Diensten, die im Rahmen des JSR 3 entstanden. 4 Apache Tomcat [Tomcat, 2006] ist der Servlet-Container, in welchem Cocoon und AMACONT laufen. Copyright TU Dresden, Stefan Pietschmann 68 von 82

75 5. Umsetzung und Bewertung clientcontext-monitors Für alle hier aufgelisteten Monitore wird genau eine Instanz pro Session erstellt. Somit können die Monitore session- und nutzerspezifische Parameter liefern. monitor Hiermit lassen sich beliebige Monitore einbinden und somit die Monitoringschicht erweitern. Die Konfiguration der einzelnen Monitore besteht aus einer ID, mit derer sie innerhalb von Kontextparametern in Requirements adressiert werden können, und der Klasse ihrer Implementierung. Mittels des Attributs cacheable kann das standardmäßig deaktivierte Caching der Parameterwerte angeschaltet werden. Als Kindelemente können Monitore weitere <parameter>-elemente erhalten, deren name/value-paare ihnen dann zur Verfügung stehen. 1 <! ## ADAPTATIONMANAGER ## > 2 <component r o l e =" de. [... ]. AdaptationManager " shorthand=" adaptation manager " c l a s s =" de. [... ]. impl. AdaptationManagerImpl "> 3 <enabled value=" f a l s e "/> 4 <configfile check reload=" false " f i l e =" context://amacont/config/amaconfig. xml "/> 5 </component> 6 <! ## MONITORMANAGER ##### > 7 <component r o l e =" de. [... ]. MonitorManager " shorthand=" monitor manager " c l a s s =" de. [... ]. impl. MonitorManagerImpl " > 8 <servercontext monitors> 9 <monitor id=" System " c l a s s =" de. amacont. [... ]. impl. ServerLoadMonitor "/> 10 </servercontext monitors> 11 <clientcontext monitors> 12 <monitor id=" ContextModel " class=" de. amacont. [... ]. impl. ContextModelMonitor "/> 13 <monitor id=" Application " class=" de. amacont. [... ]. impl. ApplicationMonitor " cacheable=" true "/> 14 <monitor id=" CDL4ModelingTimer " class=" de. amacont. [... ]. impl. TimingMonitor "> 15 <! execute comp. every 30 seconds > 16 <parameter name=" threshold " value=" 30 "/> 17 </monitor> 18 </clientcontext monitors> 19 </component> Lst. 5.1: Konfigurationsabschnitt in cocooon.xconf Struktur und Funktionsweise Die Klassenstruktur der drei Ebenen des SystemAdaptation-Frameworks ist in Abb. 5.3 dargestellt. Man erkennt die Trennung der einzelnen Schichten in Packages, die wiederum in Schnittstellen und Implementierungen unterteilt sind. Der Zugriff durch obere Schichten erfolgt über die Schnittstellen AdaptationManager (Adaptionsmanagementschicht) bzw. MonitorManager (Monitoringschicht). Beim Eintreffen eines Requests werden zuerst die Action-Objekte instanziiert und die referenzierten Requirements gespeichert. Beim Aufruf der Actions bzw. Action-Sets erfolgt mit Hilfe des AdaptationManagers die Überprüfung derer Bedingungen und anhand der Ergebnisse die Entscheidung über die Abarbeitung und Anpassung von Parametern. Ähnlich verläuft die Adaption der Pipeline. Die Liste abzuarbeitender Transformer wird durchlaufen und jede Komponente auf Requirements überprüft. Diese werden ausgewertet und nur diejenigen Transformer initialisiert, deren Bedingungen erfüllt sind. Nachdem die Entscheidung über die Ausführung getroffen wurde, erfolgt die Auswertung der adaptiven Parameter der verbliebenen Komponenten nach dem gleichen Prinzip. Der genaue Ablauf der Adaptionsentscheidung besteht - wie Abb. 5.4 veranschaulicht - aus den folgenden Schritten: 1. Action- und Action-Set-Objekte lesen ihre eigenen Bedingungen bzw. adaptiven Parameter aus, die Pipeline die der abzuarbeitenden Transformer, und senden diese an den AdaptationManager. 2. Der AdaptationManager prüft, ob sich bereits Ergebnisse der Einzelbedingungen im RequirementCache befinden, und lädt diese, falls vorhanden. Copyright TU Dresden, Stefan Pietschmann 69 von 82

76 5. Umsetzung und Bewertung Abb. 5.3: Klassendiagramm des SystemAdaptation-Frameworks zur Architekturadaption Copyright TU Dresden, Stefan Pietschmann 70 von 82

77 5. Umsetzung und Bewertung Abb. 5.4: Ablauf der Adaptionsentscheidung 3. IDs noch nicht ausgewerteter Bedingungen werden an den ConfigurationSourceHandler weitergereicht. 4. Dieser verarbeitet die SAX-Events der referenzierten Bedingung beim Parsen der Konfigurationsdatei, speichert die auszuwertenden Terme zwischen und sendet für jeden enthaltenen Kontextparameter eine Anfrage, bestehend aus Monitor- und Parametername, an den MonitorManager. 5. Der MonitorManager überprüft, ob sich die angeforderten Parameter bereits im Cache befinden, und liest diese gegebenenfalls von dort. 6. Anfragen, die nicht im Cache aufgelöst werden können, werden an die jeweiligen Monitore weitergeleitet. 7. Die Monitore berechnen die Parameter und geben deren Werte an den MonitorManager zurück. 8. Der MonitorManager speichert die Parameterwerte, falls dies das cacheable-attribut 5 erlaubt, im ParameterCache. 9. Die Parameterwerte werden dem ConfigurationSourceHandler übergeben. 10. Der ConfigurationSourceHandler wertet die Terme einer Bedingung mit Hilfe der erhaltenen Parameterwerte aus, und gibt das Gesamtergebnis (als boolean) an den AdaptationManager zurück. 11. Das Ergebnis der überprüften Bedingung wird - falls alle enthaltenen Parameter cacheable sind - im RequirementCache hinterlegt. 12. Je nach Anfrage der Anwendungsebene ergeben sich nun zwei Szenarien. Alle Einzelergebnisse werden verknüpft und dann 5 Alle Monitore können bei ihrer Konfiguration mit dem Attribut cacheable ausgestattet werden. Es gibt an, ob die Werte, die der Monitor liefert, innerhalb eines Requests gecacht werden können (Kap. 4.3). Copyright TU Dresden, Stefan Pietschmann 71 von 82

78 5. Umsetzung und Bewertung a) im Falle einer Bedingungsabfrage der Anwendung als boolean zurückgeliefert. b) im Falle eines adaptiven Parameters zur Auswertung dessen benutzt. Der AdaptationManager wertet die Syntax des adaptiven Komponentenparameters aus (siehe Kap ) und gibt den passenden Wert zurück. Die ermittelten Ergebnisse der Einzelbedingungen werden vom AdaptationManager kontinuierlich verknüpft, sodass beim ersten negativen Ergebnis die Auswertung abgebrochen und der Anwendung der Wert false übergeben wird. Eine Evolution des Systems ist in der oben beschriebenen Form nicht möglich, da sich Komponenten nicht weiterentwickeln, sondern lediglich über deren Ausführung und Konfiguration entschieden wird. Zudem erfolgt die Adaption nicht dauerhaft, da die Pipeline mit jedem Request in ihren anfänglichen, adaptierbaren Zustand zurückgesetzt wird. Eine evolutionäre Adaption wäre hinsichtlich der heterogenen Nutzer auch ungeeignet, da es nicht nur eine optimale Entwicklung gibt, sondern sich diese ganz entscheidend nach dem jeweiligen Clientkontext richtet. 5.3 Nutzung durch andere Anwendungen Das SystemAdaptation-Framework stellt ein anwendungsunabhängiges Subsystem zur Überwachung des Kontextes und Analyse von Bedingungen dar. Es kann von beliebigen, komponentenbasierten Softwarearchitekturen zur Adaptionsentscheidung genutzt werden, wurde aber speziell für die Adaption pipelinebasierter Architekturen entwickelt. Um das Framework nutzen zu können, müssen den Anwendungen lediglich Einstiegspunkte zum AdaptationManager hinzugefügt und die Initialisierung von AdaptationManager und MonitorManager zum Systemstart sichergestellt werden. Wie die Ergebnisse der Bedingungsauswertung von der Anwendung genutzt werden, obliegt allein dem Entwickler. 5.4 Diskussion ausgewählter Designentscheidungen Im Folgenden sollen zwei wesentliche Designentscheidungen stellvertretend diskutiert und begründet werden Verknüpfung von Pipeline und Requirements Zunächst galt es einen geeigneten Weg zu finden, Vorbedingungen mit Pipeline-Komponenten zu verknüpfen. Die folgenden Möglichkeiten wurden in Betracht gezogen: Durch das Selector-Konstrukt stellt Cocoon eine Methode zur Verfügung, um Verzweigungen der Pipeline zu ermöglichen. In Abhängigkeit bestimmter Werte können verschiedene Zweige spezifiziert und durchlaufen werden. Dieser Ansatz wurde allerdings aus verschiedenen Gründen für die Implementierung der adaptiven Pipeline verworfen. Zum einen ist die Auswahl der vom Selektor nutzbaren Parameter stark eingeschränkt 6, zum anderen wäre keine Parameteradaption möglich gewesen. Des Weiteren hätte dieser Ansatz die geforderte Anwendungsunabhängigkeit verletzt. Die Umsetzung als Action (Lst. 5.2) - ähnlich dem Verteilungsmanager (Kap.3.2.1) - versprach zwar eine relativ einfache Implementierung, schied jedoch aufgrund der in Kapitel Es können Request URI, Header-Informationen, Cookies oder Browser-User Agent (UA) genutzt werden, jedoch beispielsweise keine Parameter des Kontextmodells. Copyright TU Dresden, Stefan Pietschmann 72 von 82

79 5. Umsetzung und Bewertung aufgeführten Nachteile aus. Unter anderem hätte ein solcher Ansatz den Anspruch der Anwendungsunabhängigkeit verletzt und vor allem zu einer recht umständlichen Definition in der Sitemap geführt. Die Tatsache, dass Actions - wie auch Selektoren - bereits vor der Abarbeitung der Pipeline ausgewertet werden, und somit die dann möglicherweise aktualisierten Kontextinformationen nicht mehr genutzt werden würden, war ein weiterer Grund für die Entscheidung gegen diese Lösung. 1 <map:act type=" evalconfigs "> 2 <map:parameter name=" requires " value=" r1, r2, not ( r4 ) "/> 3 <map:transform type=" x s l t "/> 4 </map:act> Lst. 5.2: Ansatz 1: Action Die Referenzierung der Bedingungen als Komponenten-Attribute scheiterte an der Umsetzbarkeit. Die Sitemap in ihrer XML-Form wird nur bei der Verarbeitung des ersten Requests in eine interne Objektstruktur überführt - zu diesem Zeitpunkt ist die Auswertung der Bedingungen allerdings nicht möglich, da sie für jeden Request neu durchgeführt werden soll. Ein späterer Zugriff auf Attribute gestaltet sich hingegen schwierig und hätte einen starken Eingriff in die Cocoon Architektur, die zuweilen auch ein Großteil der Entwickler nicht im Detail zu durchblicken scheint, bedeutet. Das Verhältnis von Kosten und Nutzen der Implementierung stand bei dieser Variante in keinem Verhältnis, auch wenn sie eine einfache und platzsparende Lösung dargestellt hätte (Lst. 5.3). 1 <map:transform type=" x s l t " r e q u i r e s =" r 1, r 2, n o t ( r4 ) "/> Lst. 5.3: Ansatz 2: Attribut Letztlich erwies sich die Verknüpfung mit Requirements über Komponenten-Parameter als sinnvoller und verhältnismäßig anwendungsunabhängiger Kompromiss zwischen einfacher, platzsparender Definition (Lst. 5.4) und Implementierungsaufwand. 1 <map:transform type=" x s l t " s r c ="..."> 2 <map:parameter name="? requires " value=" r1, r2, not ( r4 ) "/> 3 </map:transform> Lst. 5.4: Ansatz 3: Parameter Anticipant vs. Lazy Processing Eine weitere Entscheidung betraf den Zeitpunkt der Auswertung der Vorbedingungen. Denkbar waren zwei Szenarien: Lazy Processing Der offensichtlichste Ansatz: Bedingungen werden ausgewertet, wenn sie benötigt werden. Das bedeutet aber auch, dass die Konfigurationsdatei mehrfach zur Ausführungszeit der Komponente geparst werden muss. Ein Vorteil dieser Lösung liegt darin, dass lediglich die benötigten Requirements ausgewertet werden. Anticipant Processing Hierbei erfolgt die Auswertung aller Bedingungen vor der Abarbeitung des Requests, sodass die Ergebnisse beim Aufruf der Komponente, bzw. bei dessen Adaptionsentscheidung, direkt zu Verfügung stehen. Dies nimmt natürlich eine gewisse Zeit zu Beginn der Verarbeitung in Anspruch und führt dazu, dass per se alle Bedingungen ausgewertet werden. Es besteht weiterhin die Gefahr, dass die Ergebnisse zum späteren Zeitpunkt der Nutzung nicht mehr aktuell sind. Copyright TU Dresden, Stefan Pietschmann 73 von 82

80 5. Umsetzung und Bewertung Als beste Entscheidung erwies sich hier ein Kompromiss beider Ansätze: Bedingungen werden erst ausgewertet, wenn sie tatsächlich benötigt werden (lazy), es kommt aber nicht zum mehrfachen Parsen für eine Bedingung, falls deren Ergebnis cachebar ist. Durch interne Messungen wurde zudem bestätigt, dass das Handling der Konfigurationsdatei lediglich marginale Auswirkungen auf die Verarbeitung hat 7. Durch die interne Objektrepräsentation als Source-Objekt wird zudem auch keine Zeit für das Lesen von der Festplatte benötigt. 5.5 Beispiele Im Zuge dieser Arbeit wurden diverse Beispiele zu Test- und Veranschaulichungszwecken erstellt, von denen eine repräsentative Auswahl im Folgenden dargelegt wird. Beispiel 1: Client-Server-Verlagerung von Komponenten Die Verlagerung des CDL4-Algorithmus auf den Client kann nun durch einen Parameter der Rendering-Komponente gesteuert werden. Je nach ihrem Wert wird ein CDL4-Applet in die Response eingebunden oder nicht. Der Parameter ist adaptiv, sodass er immer dann true wird, wenn der Client den Einsatz des CDL4-Applets unterstützt. Dessen serverseitiges Pendant ist an das genau gegensätzliche Requirement geknüpft und wird nur ausgeführt, wenn die Serverlast nicht einen gewissen Schwellenwert überschreitet (Lst. 5.5). 1 [... ] 2 <map:act type=" modelprefscdl4 "> 3 <map:parameter name="? requires " value=" not ( clientjava ),not ( highload ) "/> 4 </map:act> 5 [... ] 6 <map:transform type=" xslt with parameters " src=" { global: trans }Ama2xHTML. Full. x s l t "> 7 <map:parameter name=" watching " value=" true "/> 8 <map:parameter name=" i e " value=" true "/> 9 <map:parameter name="? c d l 4 c l i e n t " value=" ( c l i e n t J a v a )? t r u e : f a l s e "/> 10 </map:transform> 11 [... ] Lst. 5.5: Verlagerung des CDL4-Algorithmus Beispiel 2: Vereinfachung der Sitemap Da das alte Adaptionskonzept keine Adaption von Komponentenparametern unterstützte, wurden Selektoren zu diesem Zweck eingesetzt, die allerdings den bereits genannten Problemen und Einschränkungen unterliegen. Dies wird am Beispiel des addlinks-transformers deutlich (Lst. 5.6). Das verwendete Selektor-Konstrukt ist mit dem neuen System hinfällig und kann durch einen adaptiven Parameter ersetzt werden (Lst. 5.7) 1 <map:select type=" browser "> 2 <map:when t e s t =" desktop "> 3 <map:transform type=" addlinks "> 4 <map:parameter name=" componenttag " value=" span "/> 5 </map:transform> 6 </map:when> 7 <map:otherwise> 8 <map:transform type=" addlinks "> 9 <map:parameter name=" componenttag " value="comp"/> 10 </map:transform> 11 </map:otherwise> 12 </map:select> Lst. 5.6: Vorheriges Selektor-Konstrukt für den addlinks-transformer 1 <map:transform type=" addlinks "> 2 <map:parameter name="?componenttag " value=" ( desktop )?span:comp "/> 3 </map:transform> Lst. 5.7: Adaptiver Parameter für den addlinks-transformer 7 Die Berechnung einer Bedingung, d. h. die Arbeit des ConfigurationSourceHandlers inkl. Abruf eines zweier Parameter aus dem ContextModelMonitor, bewegte sich im Bereich von 10-20ms Copyright TU Dresden, Stefan Pietschmann 74 von 82

81 5. Umsetzung und Bewertung Beispiel 3: Konditionale Kontextmodellierung Die Vorzüge der Kontextmodellierung können mit Hilfe des neuen Konzeptes sehr einfach den registrierten Nutzern vorbehalten bleiben. Dazu muss lediglich eine passende Bedingung mit dem Action-Set generatemodel verbunden werden (Lst. 5.8). 1 <map:act set=" generatemodel "> 2 <map:parameter name="? requires " value=" not ( guest ) "/> 3 </map:act> Lst. 5.8: Deaktivierung der Kontextmodellierung für Gäste Genauso können Modellierungskomponenten auch auf bestimmte Web-Anwendungen beschränkt werden. Auf Basis des Anwendungspfades (ApplicationMonitor) wird das Location- Modeling beispielsweise nur für die Anwendungen durchgeführt, die auch Adaptionen an den Ort vornehmen. Dementsprechend kann die Ausführung beliebiger Komponenten der Kontextmodellierung in Abhängigkeit der genutzten Web-Anwendung und deren speziellen Eigenschaften erfolgen. Beispiel 4: Adaption an den Serverkontext (Last) Da die Verarbeitung von Nutzerinteraktionen zu Adaptionsregeln relativ rechenintensiv ist, wurde sie an eine Bedingung geknüpft, die sie bei hoher Serverlast nur in bestimmten Abständen ausführen lässt (TimingMonitor). Die Modellierung von Nutzerpräferenzen erfolgt dann nur noch in bestimmten Abständen und nicht mit jedem Request, was zu einer Entlastung des Servers führt. Eine solche Bedingung ist in Listing 5.9 abgebildet. Bei geringer Serverlast wird der erste, innere Term wahr und der Parameter due des TimingMonitors abgefragt, welcher nur in vordefinierten Abständen true liefert. Ist also sowohl die Serverlast gering, als auch eine gewisse Zeit seit der letzten Modellierung vergangen, ist die Bedingung erfüllt und die CDL4-Komponente wird ausgeführt. 1 <acon:requirement id="runcdl4"> 2 <acon:term type=" or "> 3 <acon:term type=" l t e "> 4 <acon:parameter>system#load</acon:parameter> 5 <acon:const>80</acon:const> 6 </acon:term> 7 <acon:term type="="> 8 <acon:parameter>cdl4timer#due</acon:parameter> 9 <acon:const>true</acon:const> 10 </acon:term> 11 </acon:term> 12 </acon:requirement> Lst. 5.9: Bedingung für die CDL4-Komponente zur Ausführung nur in bestimmten Abständen bei hoher Serverlast Beispiel 5: Adaption an den Clientkontext (Formatunterstützung) Zu guter Letzt wurde ein Beispiel erstellt, in dem der Transformationsschritt des Rendering mit Hilfe des entstandenen Systems so adaptiert wird, dass - je nach Unterstützung durch das Endgerät - entweder eine VRML-, Flash- oder HTML-Variante eines Menüs an den Client geliefert wird (Abb. 5.5). Viele mobile Endgeräte unterstützen die Einbettung von Rich Media Inhalten in Webseiten nicht, sodass die nun mögliche Ausgabe als reines Format die Wiedergabe in einem externen Player erlaubt. Weitere Beispielszenarien, deren Umsetzung das entwickelte Konzept ermöglicht und die für das System vorteilhaft wären, sollten im Zuge weiterer Arbeiten - auch hinsichtlich ihrer Auswirkungen auf die Leistungsfähigkeit des Systems - untersucht werden. Copyright TU Dresden, Stefan Pietschmann 75 von 82

82 5. Umsetzung und Bewertung Abb. 5.5: Adaptives Rendering mit dem SystemAdaptation-Framework 5.6 Performanzbewertung Es ist zu vermuten, dass die Sicherung der kompletten Pipeline vor der Adaption und die Auswertung von Requirements zur Laufzeit einen gewissen Overhead verursachen. Deshalb stellt sich die Frage, wie groß dieser tatsächlich ist, und in welchem Verhältnis er zum Einsparpotential, z. B. durch das Auslassen optionaler Komponenten, steht. Als maßgebliche Messvariable wurde die Antwortzeit des Servers gewählt, da deren Verbesserung sowohl auf die Optimierung der Serverleistung hinweist, als auch die Zufriedenheit der Nutzer erhöht. Testsystem Software AMD Athlon Windows XP Professional MSI K8N Neo4 (nvidia nforce 4 Ultra) Sun JDK 1.5.0_ MB PC3200 DDR-RAM Apache Tomcat Apache JMeter Die untersuchten Instanzen sind Teile einer typischen AMACONT Web-Anwendung - der Online-Videothek -, weshalb die gewonnenen Erkenntnisse auch auf andere Dokumente des Projektes übertragbar sind. Testlauf 1: Leerlauf Die erste Testreihe sollte klären, wie hoch der durch die Architekturadaption entstehende Overhead ist. Dazu wurden die Antwortzeiten von der alten Pipeline mit denen der adaptiven Pipeline - jeweils mit aktivierter und deaktivierter Adaption (siehe Kap , Konfiguration) - verglichen. Eine Adaption fand nicht statt, d. h. die adaptive Pipeline befand sich im Leerlauf. Der Unterschied der Antwortzeiten spiegelt den Aufwand wider, der durch die Initialisierung, Registrierung und Deregistrierung der Monitore sowie die Überprüfung auf (nicht von!) Vorbedingungen entsteht. Der Testlauf beinhaltete 1000 Requests, die jeweils von einem bzw. zehn Threads an den Server gestellt wurden. Die adaptive Pipeline erwies sich als threadsicher und produzierte - wie Abb. 5.6 verdeutlicht - nur sehr geringen bis gar keinen Overhead. Die Testreihen beim Multithreading schwankten untereinander, sodass teilweise die adaptive Pipeline kaum langsamer war, als die statische. Der Aufwand für die o. g. Aufgaben ist offensichtlich vernachlässigbar gering, sodass die statische Pipeline problemlos durch die neue Version ersetzt werden kann. Copyright TU Dresden, Stefan Pietschmann 76 von 82

83 5. Umsetzung und Bewertung Abb. 5.6: Leistungsvergleich der Pipelines im Leerlauf Testlauf 2: Client-Server-Verlagerung Der nächste Test sollte die Vorteile der adaptiven Architektur für AMACONT verdeutlichen. Es wurden der Ist-Zustand - die Benutzermodellierung durch den CDL4-Algorithmus findet immer auf dem Server statt - mit einer Situation verglichen, in der diese Modellierung in 40% der Fälle auf den Client ausgelagert werden kann. 8 Zu Vergleichszwecken wurde zudem eine Testreihe gänzlich ohne Modellierung durchgeführt, die den Gesamteinfluss der Modellierung erkennbar macht. Die Ergebnisse in Abb. 5.7 zeigen, dass durch die Verlagerung dieser Komponente auf den Client in nur 40% aller Sessions eine durchschnittliche Einsparung der Antwortzeit um 5 11% erreicht wurde. Diese deutliche Verbesserung zeigt, dass die erzielte Einsparung den Aufwand für die dynamische Adaption egalisiert und sogar bei Weitem übertrifft. Abb. 5.7: Performanzauswirkungen der CDL4-Verlagerung Ganz offensichtlich lohnt sich die dynamische Verlagerung von Komponenten auf den Client, da sie zur einer sichtbaren Entlastung des Servers führt. Da sich die durchgeführten Messungen nur auf die Antwortzeit beziehen, gilt es weiterhin zu untersuchen, wie sich eine mögliche, durch die Verlagerung auftretende, erhöhte clientseitige System- oder Netzwerklast 8 Die Menge von 40% wurde willkürlich festgelegt. Verschiedenen Browserstatistiken zufolge bewegt sich der Anteil Java-fähiger Browser über 90%. Für die Verlagerungsentscheidung müssen jedoch auch andere Aspekte, wie die Ressourcen des Clients, berücksichtigt werden. Copyright TU Dresden, Stefan Pietschmann 77 von 82

84 5. Umsetzung und Bewertung auf den Client auswirkt. Derartige Untersuchungen sollten in anschließenden Arbeiten für die vorhandenen Pipeline-Komponenten durchgeführt werden. Testlauf 3: Vereinfachung der Sitemap Bisher wurde ein Parameter des LinkTransformers durch die Auswahl zwischen zwei alternativen Definitionen mittels eines Selektors angepasst (Lst. 5.6). Diese Parameteradaption könnte nun auch durch die Verknüpfung der beiden Versionen des Transformers mit zwei gegensätzlichen Requirements erfolgen. Das neue Konzept ermöglicht nun aber die Nutzung eines adaptiven Parameters, wobei auf die redundante, zweifache Definition der Komponente verzichtet werden kann (Lst. 5.7). Es stellt sich die Frage, wie sich die Auswertung des Selektors, die Aktivierung und Deaktivierung je einer konditionalen Komponente und der adaptive Parameter im Vergleich auf die Leistung des Systems auswirken. Abb. 5.8 zeigt, dass alle drei Varianten - Schwankungen der Messungen berücksichtigt - nahezu gleich schnell sind. Die Verwendung adaptiver Parameter ermöglicht somit die Vereinfachung der Pipeline (Verhinderung von Redundanzen) und die Aufhebung der Beschränkungen von Selektoren (nur wenige Parameter können für die Entscheidung genutzt werden, siehe Kap ), ohne Einbußen bei der Leistung des Systems hinnehmen zu müssen. Die Ergebnisse bedeuten auch, dass Selektor-Konstrukte generell (auch bei der Auswahl alternativer Komponenten, die sich nicht nur in einem Parameter unterscheiden) ohne nachteilige Auswirkungen durch konditionale Komponenten ersetzt werden können. Abb. 5.8: Vergleich der Leistung von Selektor und adaptivem Parameter Testlauf 4: Entfernen optionaler Komponenten Bei der Verarbeitung von Requests werden einige Komponenten abgearbeitet, die nicht unbedingt oder nur in gewissen Abständen benötigt werden. Dadurch ergibt sich ein gewisses Einsparpotential, welches für das folgende Beispiel gemessen wurde: Die Ortsmodellierung muss für Desktop-Nutzer nicht bzw. nur einmal durchgeführt werden, da diese sich nicht bewegen. Auch bei mobilen Nutzern wird dieses Reverse Geocoding, welches aus Ortskoordinaten semantische Informationen ermittelt, - je nach Geschwindigkeit des Client - nicht bei jedem Request benötigt. Das Diagramm aus Abb. 5.9 stellt die Antwortzeiten von Requests nebeneinander, bei denen das LocationModeling 1 immer, 2 nur 1x pro Minute bzw. 3 nie stattfand. Es ist zu sehen, dass eine 8 11%ige Verkürzung der Verarbeitungszeit erreicht werden kann, ohne dass sich für den Nutzer Einschränkungen ergeben. Ein Leistungsvergleich mit dem Verteilungsmanagerkonzept des Komplexpraktikums wurde nicht explizit durchgeführt, da sich seit Zeitpunkt dessen Entwicklung die AMACONT- Architektur teilweise deutlich verändert hatte und eine nachträgliche Anpassung im Rahmen dieser Arbeit nicht nötig erschien. Die in Kapitel aufgeführten Nachteile lassen jedoch Copyright TU Dresden, Stefan Pietschmann 78 von 82

85 5. Umsetzung und Bewertung Abb. 5.9: Auswirkung der bedingten Ausführung optionaler Komponenten auf die Leistung vermuten, dass sich die alte Implementierung - trotz deutlicher Beschränkungen der Adaptionsfunktionalität - als weniger leistungsfähig erweisen würde. Zusammenfassend kann man erkennen, dass der Einsatz einer dynamisch adaptiven Architektur lohnenswert ist, da er zur Leistungssteigerung des Systems und Verkleinerung der Antwortzeiten führt. Das genaue Einsparpotential kann nicht global beziffert bzw. gemessen werden, da es ganz wesentlich davon abhängt, wie groß und komplex die auszuwertenden Bedingungen sind, wie schnell und effektiv die Monitore Kontextparameter ermitteln und wie zeit- und rechenintensiv die zu adaptierende Komponente ist. Im Fall der o. g. Beispiele (CDL4-Verlagerung, LocationModeling) ist der Einsatz dynamischer Adaptivität offensichtlich vorteilhaft. Copyright TU Dresden, Stefan Pietschmann 79 von 82

86 Progress comes from the intelligent use of experience. Elbert G. Hubbard, Zusammenfassung und Ausblick Ziel der vorliegenden Arbeit war es, den Stand der Technik dynamisch adaptiver Softwarearchitekturen zu beleuchten und basierend auf diesem Wissen und der Analyse des zu Beginn der Arbeit vorliegenden Verteilungsmanager-Ansatzes ein neues Konzept zur dynamischen Adaption der AMACONT Dokumentgenerierungspipeline zu erstellen und umzusetzen. Zunächst wurden die Begriffe System- bzw. Softwarearchitektur und Adaptivität charakterisiert und deren Verknüpfung zu adaptiven Architekturen beschrieben. Nach einer Darlegung der Gründe und Einsatzgebiete solcher Systeme folgte die Betrachtung verschiedener, grundlegender Probleme und Anforderungen, sowie eine genauere Betrachtung der Spezifikationsmöglichkeiten dynamischer Adaptivität. Im Anschluss wurden Adaptionsmethoden und -techniken vorgestellt, die für die dynamische Anpassung komponentenbasierter Software angewendet werden. Die theoretische Betrachtung schloss mit der Zusammenfassung wichtiger Klassifikationsmuster und der Vorstellung ausgewählter Ansätze aus der Literatur und deren konzeptuellen Eigenheiten. Im nächsten Kapitel erfolgte eine Analyse des zu Beginn der Arbeit vorliegenden Konzeptes zur Verlagerung und einfachen Architekturadaption - dem Verteilungsmanager. Die daraus gewonnenen Erkenntnisse über Vor- und Nachteile und das gesammelte Wissen aus Kapitel 2 flossen in Kapitel 4 in die Entwicklung eines neuen, generischen Konzeptes zur dynamischen Adaption pipelinebasierter Softwarearchitekturen auf Basis kontextueller Informationen, ein. Es folgte die Beschreibung der Grundlagen und Umsetzung der Implementierung des sog. SystemAdaptation-Frameworks. Dabei wurden einige Beispiele vorgestellt, die im Zuge dieser Arbeit entstanden und Nutzen sowie Funktionsweise des entstandenen Systems verdeutlichen. Zudem fanden diverse Funktions- und Performanztests statt, deren Ergebnisse analysiert und bewertet wurden. Das Ziel der Umsetzung dynamischer Adaptivität in Software sollte nicht ihr Vorhandensein selbst, sondern ein erkennbarer Mehrwert für die Anwendung sein [Amberg et al., 2003]. Beispiele für diesen Mehrwert wurden bereits in den Kapitel 1.1, sowie diskutiert und umfassen die Behebung von fehlerhaftem Verhalten, die Optimierung des Systems zur Minimierung von Last bzw. Antwortzeiten, die Steigerung der Nutzerzufriedenheit durch Beachtung seiner Vorlieben u. v. m. Es ist die Überzeugung des Autors, dass das vorgestellte Konzept diesem Ziel - nicht nur für das Projekt AMACONT - gerecht wird. Sowohl Funktionalität als auch Leistung werden den vorgestellten Anforderungen gerecht. Der Copyright TU Dresden, Stefan Pietschmann 80 von 82

87 6. Zusammenfassung und Ausblick generische Ansatz ermöglicht außerdem die einfache Erweiterung beliebiger pipelinebasierter Softwarearchitekturen um Adaptivität. Ausblick Bei der Entwicklung des Konzeptes und der Umsetzung in Java wurde Wert auf die generische Anwendbarkeit und leichte Erweiterbarkeit gelegt. So ist es durchaus denkbar, das System mit kleinen Anpassungen beispielsweise mit der XPL zu verknüpfen, oder es für z. B. Struts [Struts, 2006] oder andere Anwendungen auch außerhalb der Web-Domäne [Mitchell et al., 2004] zu nutzen. Abschließend sollen einige Ansatzpunkte für weitergehende Arbeiten aufgeführt werden: Um die durchaus vielversprechende Verlagerung von Komponenten auf den Client ausnutzen zu können, bedarf es nicht zuletzt clientseitiger Implementierungen. Die Auswahl geeigneter Komponenten und deren Umsetzung für den Client sollte Aufgabe einer weiterführenden Arbeit sein. Für den erfolgreichen Einsatz des entwickelten Systems sind vor allem sinnvolle Requirements nötig. Diese können nur durch Performanz- und Lasttests bzw. genaue Messungen der Anforderungen für alle Komponenten der Pipeline entwickelt werden. Eventuell ist die Ausführung von Pipeline-Komponenten von deren Eigenschaften, Parametern oder Konfigurationen abhängig. Dementsprechend empfiehlt sich ein Monitor, der diese zugänglich macht und somit die Umsetzung der spezifischen QoS- Anforderungen unterstützt. In [Rigole et al., 2004] wird auf ähnliche Art auf die individuellen Ressourcenanforderungen einer Komponente zugegriffen, um sie mit den verfügbaren Ressourcen zu vergleichen. Die Erhaltung von Integrität und Konsistenz einer Anwendung steht im Mittelpunkt vieler Bemühungen der aktuellen Forschung auf dem Gebiet dynamischer Adaptivität. In AMACONT bleibt das System aufgrund seines UPF-Stils auch bei dynamischen Anpassungen integer. Dies bedeutet jedoch nicht zwingend, dass die hergestellte Reihenfolge und Konfiguration der Komponenten funktionell sinnvoll ist. Deshalb wäre es wünschenswert, den Autor bzw. Administrator - der im Augenblick allein für die geeignete Anordnung und Verknüpfung von Komponenten mit Bedingungen verantwortlich ist - bei seiner Arbeit zu unterstützen. Dazu wäre eine Art PipelineConsistencyChecker denkbar, der anhand von Constraints testet, ob die entstehende bzw. definierte Reihenfolge von Komponenten so sinnvoll ist. Albring [2005] behandelte die Modellierung der AMACONT Architektur mittels einer ADL in Eclipse [Eclipse, 2006]. Diese Beschreibung könnte um dynamische Aspekte erweitert, und der mögliche XML-Export automatisch in eine Cocoon Sitemap transformiert werden. An dieser Stelle könnte auch die geforderte Überprüfung von Konsistenz und Integrität ansetzen. Die Dokumentadaption in AMACONT basiert bisher auf Parametern des Kontextmodells. Dieses enthält aber beispielsweise keine Informationen über den Zustand des Servers. Deshalb ist es wünschenswert, auf Monitore und deren Parameter auch bei der Auswertung von Varianten innerhalb der Dokumente zugreifen zu können. Es gilt zu untersuchen, ob - ähnlich der bisherigen Modellierung von Clienteigenschaften in einem Kontextmodell - ein vergleichbares Systemprofil verwendet werden sollte, welches aktuelle Werte des Systemkontextes enthält. Der Aufwand für die zusätzliche Modellierung und das Auslesen der Werte muss gegen den Nutzen aufgewogen werden. Copyright TU Dresden, Stefan Pietschmann 81 von 82

88 6. Zusammenfassung und Ausblick Die Erweiterungen der bisherigen Logik-Elemente bei der Verknüpfung von Vorbedingungen mit Komponenten ist empfehlenswert. So ist das if/then/else-prinzip der Parameteradaption zwar für den bisherigen Einsatz von Parametern ausreichend, eventuell bedarf es jedoch weiterer Untersuchungen, wie mehrere Werte geeignet auf einen Komponentenparameter abgebildet werden könnten. Ein völlig anderer Ansatz könnte erreicht werden, indem das Adaptionsframework zu einem eigenständigen Adaptionssystem erweitert wird, das auch die Aufgabe der Adaption selbst übernimmt. Die Adaptionstechniken würden also auf die Adaptionsmanagementschicht ausgelagert werden und könnten, wie von da Silva e Silva et al. [2003] gefordert, auf Basis anwendungsexterner, deklarativer Beschreibungen und mit Hilfe von Rekonfigurationsschnittstellen der Anwendung vorgenommen werden. Dies würde allerdings auch die Auslagerung der Steuerung der Verarbeitung mit sich bringen, wovon allerdings für die Erweiterung bereits bestehender Anwendungen und unter dem Gesichtspunkt der Anwendungsunabhängigkeit eher abzuraten ist. Zudem würde sich für die anwendungsexterne Adaption eher ein event-gesteuertes Konzept eignen, welches aber für webbasierte Systeme nicht geeignet erscheint. Copyright TU Dresden, Stefan Pietschmann 82 von 82

89 A Beschreibung der Klassen Im Folgenden wird näher auf die Implementierung der Klassen des SystemAdaptation Frameworks eingegangen. Detailliertere Informationen können der Javadoc entnommen werden. Copyright TU Dresden, Stefan Pietschmann I

90 A. Beschreibung der Klassen A.1 Adaptive(Profiling)NonCachingProcessingPipeline Aufgabe Die AdaptiveNonCachingProcessingPipeline erweitert die Cocoon-Pipeline um dynamische Adaptivität. Dazu überprüft sie vor der Initialisierung der Transformer, ob diese an Vorbedingungen gebunden sind. Diese werden ausgewertet und das Ergebnis entscheidet über den Verbleib des jeweiligen Transformers in der Verarbeitungskette. Alle verbleibenden Transformer werden auf adaptive Parameter überprüft und diese ebenfalls in Abhängigkeit der verknüpften Requirements angepasst. Es existiert ebenfalls eine adaptive Erweiterung zur Pipeline mit Cocoon Profiling Mechanismus - die AdaptiveProfilingNonCachingProcessingPipeline -, deren Implementierung sich aber lediglich durch die Unterstützung des Profiling von der o. g. unterscheidet. Methoden compose(componentmanager):void überlädt die Supermethode und registriert Adaptationund MonitorManager als PipelineListener, damit diese am Ende der Verarbeitung informiert werden und ihre Caches zurücksetzen können. setuppipeline(environment):void ruft die Methode adaptpipeline(environment) und danach die Implementierung der Superklasse auf. adaptpipeline(environment):void durchsucht die Liste der Transformer nach Verknüpfungen mit Requirements (Parameter?requires ), sendet diese zum AdaptationManager und entscheidet je nach Rückgabewert über die Ausführung. Sind alle Bedingungen erfüllt, werden die adaptiven Parameter der Transformer angepasst. process(environment):boolean informiert bei Start und Ende der Verarbeitung durch die Superklasse alle PipelineListener. Abb. A.1: Klassendiagramm der adaptiven Pipeline Copyright TU Dresden, Stefan Pietschmann II

91 A. Beschreibung der Klassen A.2 ActTypeNode & ActSetNode Aufgabe Diese beiden Klassen stellen die Cocoon-Implementierungen der Action- und Action-Set- Knoten aus der Sitemap dar und steuern deren Initialisierung und Ablauf. Um dynamische Adaptivität zu erreichen wurden sie derart erweitert, dass vor der Ausführung eine Überprüfung der referenzierten Requirements, und danach die Anpassung der adaptiven Parameter durchgeführt wird. Im Fall der Deaktivierung eines Action-Sets wird diese Information in eine Session-Variable geschrieben, die beim Start aller enthaltenen Actions ausgelesen wird. Ist ein Action-Set also an unerfüllte Vorbedingungen gebunden, so werden alle enthaltenen Actions übergangen. Methoden setparameters(map):void überlädt die Supermethode dieser Klasse und sorgt dafür, dass die Requirement-Parameter gesondert gespeichert werden. invoke(environment,invokecontext):boolean wird beim Aufruf der Action bzw. des Action- Sets gestartet. Bei Actions findet zuerst die oben beschriebene Überprüfung der Session- Variable statt. Ist die Ausführung erlaubt, werden - wie auch beim Action-Set - die referenzierten Requirements mit Hilfe des AdaptationManagers ausgewertet und adaptive Parameter angepasst. Danach folgt die normale Ausführung. Abb. A.2: Klassendiagramm der Action und Action-Set-Knoten A.3 AdaptationManager(Impl) Aufgabe Der AdaptationManager bildet die Schnittstelle zwischen der Anwendung und dem Adaptionsmanagement. Seine Hauptaufgabe liegt in der Verknüpfung von Requirement-Ergebnissen und der Auswertung adaptiver Parameter. Des Weiteren überprüft er die Aktualität der Konfigurationsdatei und lädt diese bei Bedarf nach. Zur Beschleunigung der Verarbeitung verfügt der AdaptationManager über einen Cache, in welchem die Ergebnisse cachebarer Requirements für den Zeitraum der Verarbeitung eines Requests zwischengespeichert werden. Dadurch kann dem mehrfachen Parsen der Konfigurationsdatei und dem Aufruf von Monitorkomponenten vorgebeugt werden. Zusätzlich implementiert der AdaptationManager das SessionListener-Interface und wird vom System somit über die Erstellung und das Ende von Sessions unterrichtet. Die entsprechenden Events dienen der Generierung bzw. Zerstörung der sessiongebundenen Caches und werden an den MonitorManager weitergeleitet. Copyright TU Dresden, Stefan Pietschmann III

92 A. Beschreibung der Klassen Methoden isenabled():boolean gibt aus, ob die Adaptionslogik aktiviert ist (Kap , Konfiguration). clearcache(string:sessionid):void setzt den internen Cache am Ende der Request-Verarbeitung zurück (ausgelöst durch das PipelineListener-Event). checkrequirements(environment,string):boolean verknüpft die Ergebnisse einer Liste von Vorbedingungen. Bei der ersten unerfüllten Bedingung wird die Auswertung abgebrochen und false zurückgegeben. checksinglerequirement(environment,string):boolean liefert den Status einer einzelnen Bedingung. evalconditionalparam(environment,string):string wertet einen adaptiven Parameter auf Basis seiner Bedingungen aus. Ist die Syntax des Parameters (Kap ) ungültig, wird eine InvalidConditionalParameterException ausgelöst. evalparameters(environment,parameters):parameters passt alle adaptiven Parameter in einer Parameterliste an und gibt diese zurück. sessioncreated(httpsessionevent):void wird vom SessionListener-Interface vererbt und aufgerufen, wenn eine neue Session erstellt wurde. Ein sessionspezifischer Cache wird instanziiert und das Event an den MonitorManager weitergeleitet. sessiondestroyed(httpsessionevent):void zerstört alle Variablen der beendeten Session und informiert den MonitorManager. updateconfigsource():boolean überprüft die Konfigurationsdatei auf Veränderungen und lädt sie bei Bedarf nach. Bei einer Aktualisierung wird true zurückgegeben. Abb. A.3: Klassendiagramm des AdaptationManager Copyright TU Dresden, Stefan Pietschmann IV

93 A. Beschreibung der Klassen A.4 ConfigurationSourceHandler(Impl) Aufgabe Der ConfigurationSourceHandler behandelt die SAX-Events beim Parsen der Konfigurationsdatei. Er sucht eine Bedingung mit einer bestimmten ID, wertet deren Terme aus und gibt das Verknüpfungsergebnis zurück an den AdaptationManager. Die Werte der enthaltenen Kontextparameter werden ihm vom MonitorManager geliefert. Methoden checkrequirement(source,string,environment):boolean[] erhält das Source-Objekt der Konfigurationsdatei, löst deren Parsing aus und gibt das Ergebnis der Bedingung mit der übergebenen ID zurück. startelement(string,string,string,attributes):void wird bei jedem öffnenden Element aufgerufen. endelement((string,string,string):void wird für jedes schließende Element ausgelöst und beinhaltet beispielsweise die Abfrage und Verknüpfung von Kontextparametern. resolve(string,string,string):void wertet einen Term, bestehend aus zwei Werten und einem Operator, aus. starttextrecording():void startet die Aufnahme von Text-Events durch die Methode characters(char[],int,int). endtextrecording():string beendet die Aufnahme und gibt den aufgezeichneten Text zurück. reset():void wird vor dem Handling aufgerufen und setzt alle Zustandsvariablen und -objekte auf ihren Ausgangswert. Abb. A.4: Klassendiagramm des ConfigurationSourceHandler Copyright TU Dresden, Stefan Pietschmann V

94 A. Beschreibung der Klassen A.5 MonitorManager(Impl) Aufgabe Der MonitorManager verwaltet alle Monitore des Systems und bietet dem Configuration- SourceHandler Zugriff auf sie und ihre Parameter. Er bildet somit die Schnittstelle zwischen Adaptionsmanagement und Kontextüberwachung. Bei der Anfrage nach einem Parameter wird der passende Monitor gesucht, angefragt und das Ergebnis zurück gegeben. Die einzelnen Werte der Kontextparameter können im ParameterCache zwischenspeichert werden, sodass sie nicht mehrmals ausgelesen werden müssen. Vom AdaptationManager werden zusätzlich Session-Events an den MonitorManager weitergeleitet, der dadurch Clientkontext-Monitore für jede Session dynamisch laden und instanziieren bzw. zerstören kann. Serverkontext-Monitore werden nur einmal, beim Start des Managers instanziiert. Für die Registrierung aller Monitore stehen die Methoden add- bzw. removeclient bzw. -ServerContextMonitor zur Verfügung. Methoden clearcache(string:sessionid):void setzt den internen Cache am Ende der Request-Verarbeitung zurück (ausgelöst durch das PipelineListener-Event). getmonitor(string,string):monitor liefert das Monitor-Objekt für eine bestimmte ID zurück. Für die Abfrage von Sessionkontext-Monitoren muss der Parameter sessionid den Wert null annehmen. Ist kein Monitor für die ID registriert, wird eine MonitorNotFound- Exception ausgelöst. getparameter(environment,string):string gibt dem Wert eines Parameters eines Monitors zurück. Monitor-ID und Parametername sind - wie in der Konfigurationsdatei - in einem String kodiert und werden in dieser Methode getrennt. Abb. A.5: Klassendiagramm des MonitorManager Copyright TU Dresden, Stefan Pietschmann VI

95 A. Beschreibung der Klassen A.6 Monitore Aufgabe Die Aufgabe der Monitore ist die Bereitstellung von kontextuellen Parametern. Sie werden von der abstrakten Klasse Monitor abgeleitet, die zum Auslesen dieser Werte die Methode getparameter(string) anbietet. Ob die Parameter vom Monitor ausgelesen, berechnet oder von einer externen Anwendung abgefragt werden, obliegt dem Entwickler des Monitors. Methoden getparameter(string):string liefert den aktuellen Wert eines Kontextparameters. iscacheable():boolean gibt an, ob Parameter des Monitors zwischengespeichert werden können. setcacheable(boolean):void erlaubt das Setzen der o. g. Information durch den MonitorManager bei der Monitor-Initialisierung. Die Monitore Der ContextModelMonitor gibt die Werte von Parametern aus dem Kontextmodell des Nutzers zurück. Sie können entweder über ihren Namen, oder über eine Pfadstruktur der Form Grandparent.Parent.Node adressiert werden. Der ServerLoadMonitor liefert Informationen über den Serverkontext. Dazu nutzt er die Parameter, die das LoadDistribution-Servlet über JMX zur Verfügung stellt [Umbach, 2006]. Die verfügbaren Parameter können dessen Konfigurationsdatei performancecounters.xml festgelegt werden. Der ApplicationMonitor dient der Überwachung anwendungsspezifischer Eigenschaften. Zur Zeit umfasst die Implementierung lediglich den Parameter webapp, der den aktuellen Anwendungspfad zurückgibt. Der TimingMonitor bietet den Parameter due, welcher true liefert, sobald seit der letzten Ausführung einer Komponente ein vordefinierter Schwellwert (in Sekunden) überschritten wird. Somit lassen sich Komponenten nur in bestimmten Abständen ausführen. Abb. A.6: Klassendiagramm der Monitore Copyright TU Dresden, Stefan Pietschmann VII

A classification and comparison framework for software architecture description languages

A classification and comparison framework for software architecture description languages A classification and comparison framework for software architecture description languages Christian Gerth Seminar Architekturbeschreibungssprachen Prof. Dr. Heike Wehrheim Fachgebiet Spezifikation und

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

6 Architektur-Mittel (WOMIT)

6 Architektur-Mittel (WOMIT) 6 Architektur-Mittel (WOMIT) Abb. 6-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WOMIT-Dimension des architektonischen Ordnungsrahmens, indem es grundlegende Konzepte

Mehr

Enterprise Social Networking: Ein Framework und ein Fachkonzept für ein Industrieunternehmen

Enterprise Social Networking: Ein Framework und ein Fachkonzept für ein Industrieunternehmen Enterprise Social Networking: Ein Framework und ein Fachkonzept für ein Industrieunternehmen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor auf Science (B.Sc.) im Studiengang Wirtschaftswissenschaft

Mehr

17 Komponentenbasiertes Software-Engineering

17 Komponentenbasiertes Software-Engineering 17 Komponentenbasiertes Software-Engineering 17.0 Einführung Lernziele Grundlagen, Prinzipien und Probleme des CBSE 17.1 Komponenten und Komponentenmodelle Komponenten und ihre Eigenschaften Komponentenmodelle

Mehr

Softwarewiederverwendung und Patterns

Softwarewiederverwendung und Patterns Begrifflichkeiten und Beschreibungssystematik Begriffe Literatur zu Patterns Übersicht über die behandelten Konzepte Beschreibungsschema 97 Begriffe Glossar Patterns (Muster) sind ein Mittel der Wiederverwendung

Mehr

Inhaltsverzeichnis. xiii

Inhaltsverzeichnis. xiii Inhaltsverzeichnis 1 Einleitung... 1 1.1 Ausgangslage und Zielsetzung des Buches...2 1.2 Was ist Software-Architektur?...8 1.3 Leser-Leitfaden... 11 1.3.1 Buchaufbau... 11 1.3.2 Zielpublikum... 15 1.3.3

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit IT-basierte Erstellung von Nachhaltigkeitsberichten Diplomarbeit zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen Fakultät der Leibniz Universität Hannover vorgelegt von

Mehr

Automatisierte Dokumentation mit XML-Pipelining und XProc Autoren: Gregor Bock, Alexander Witzigmann, TANNER AG, Lindau Datum: 06.11.

Automatisierte Dokumentation mit XML-Pipelining und XProc Autoren: Gregor Bock, Alexander Witzigmann, TANNER AG, Lindau Datum: 06.11. Automatisierte Dokumentation mit XML-Pipelining und XProc Autoren: Gregor Bock, Alexander Witzigmann, TANNER AG, Lindau Datum: 06.11.2008 Inhalt Motivation Fliessbandprinzip Pipeline - Anwendungen aus

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble Vertiefungsarbeit von Karin Schäuble Gliederung 1. Einführung 3. Rahmenbedingungen in der heutigen Marktwirtschaft 3.1 Situation für Unternehmen 3.2 Situation für Applikationsentwickler 4. Lösungskonzepte

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

Model Driven Architecture Praxisbeispiel

Model Driven Architecture Praxisbeispiel 1 EJOSA OpenUSS CampusSource Model Driven Architecture Praxisbeispiel 2 Situation von CampusSource-Plattformen Ähnliche Funktionen (Verwaltung von Studenten und Dozenten, Diskussionsforen,...), jedoch

Mehr

XML in der betrieblichen Praxis

XML in der betrieblichen Praxis Klaus Turowski, Klement J. Fellner (Hrsg.) XML in der betrieblichen Praxis Standards, Möglichkeiten, Praxisbeispiele Ги dpunkt.verlag Inhaltsverzeichnis 1 XML/EDI-Standardisierung: Ein Überblick 1 1.1

Mehr

Simulation von Computer- und Kommunikationssystemen

Simulation von Computer- und Kommunikationssystemen Computer und Kommunikationssysteme Nachbildung der Verarbeitung in Rechnern und Kommunikation in Netzwerken Belegung und Auslastung von Systemressourcen Analyse von Systemverhalten Systemleistung in der

Mehr

Bedeutung von Interoperabilität und Standards in Grid Infrastrukturen

Bedeutung von Interoperabilität und Standards in Grid Infrastrukturen Bedeutung von Interoperabilität und Standards in Grid Infrastrukturen LMU SS 2012 Grid Computing Morris Riedel Federated Systems and Data Jülich Supercomputing Centre Forschungszentrum Jülich m.riedel@fz-juelich.de

Mehr

Hochschule Heilbronn Technik Wirtschaft Informatik

Hochschule Heilbronn Technik Wirtschaft Informatik Hochschule Heilbronn Technik Wirtschaft Informatik Studiengang Electronic Business (EB) Diplomarbeit (280000) Evaluierung und Einführung eines Web Content Management Systems bei einem internationalen und

Mehr

Berichte aus der Medizinischen Informatik und Bioinformatik. Günther Schadow. Krankenhauskommunikation mit HL7

Berichte aus der Medizinischen Informatik und Bioinformatik. Günther Schadow. Krankenhauskommunikation mit HL7 Berichte aus der Medizinischen Informatik und Bioinformatik Günther Schadow Krankenhauskommunikation mit HL7 Analyse, Implementation und Anwendungeines Protokollstandards für medizinische Datenkommunikation

Mehr

Taxonomy of Evolution and Dependability. Integration Engineering SS 2009 Andreas Landerer

Taxonomy of Evolution and Dependability. Integration Engineering SS 2009 Andreas Landerer Taxonomy of Evolution and Dependability Integration Engineering SS 2009 Andreas Landerer Agenda Informationen über Massimo Felici Definition zentraler Begriffe Inhalt des Artikels Kernaussagen des Artikels

Mehr

Simulation der SW-Systemzuverlässigkeit in Automatisierungssystemen auf Grundlage von SW-Komponenten

Simulation der SW-Systemzuverlässigkeit in Automatisierungssystemen auf Grundlage von SW-Komponenten Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner Simulation der SW-Systemzuverlässigkeit in Automatisierungssystemen auf Grundlage von SW-Komponenten

Mehr

Vorwort... 11 Azure Cloud Computing mit Microsoft... 12 Danksagungen... 13 Kontakt zum Autor... 13

Vorwort... 11 Azure Cloud Computing mit Microsoft... 12 Danksagungen... 13 Kontakt zum Autor... 13 Inhaltsverzeichnis Vorwort... 11 Azure Cloud Computing mit Microsoft... 12 Danksagungen... 13 Kontakt zum Autor... 13 Einleitung... 15 Zielgruppe... 16 Aufbau... 16 Inhalt der einzelnen Kapitel... 17 Systemanforderungen...

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

3 Anwendungsarchitektur und Entwicklungsumgebung

3 Anwendungsarchitektur und Entwicklungsumgebung 21 3 Anwendungsarchitektur und Bei den Entwicklern von Web-basierten Dialogsystemen hat sich im Laufe der Zeit eine Vorgehensweise im Design von Anwendungen entwickelt, dies es ermöglicht, flexible Web-Dialoge

Mehr

.NET-Networking 2 Windows Communication Foundation

.NET-Networking 2 Windows Communication Foundation .NET-Networking 2 Windows Communication Foundation Proseminar Objektorientiertes Programmieren mit.net und C# Fabian Raab Institut für Informatik Software & Systems Engineering Agenda Grundproblem Bestandteile

Mehr

GeoShop Netzwerkhandbuch

GeoShop Netzwerkhandbuch Technoparkstrasse 1 8005 Zürich Tel.: 044 / 350 10 10 Fax.: 044 / 350 10 19 GeoShop Netzwerkhandbuch Zusammenfassung Diese Dokumentation beschreibt die Einbindung des GeoShop in bestehende Netzwerkumgebungen.

Mehr

Ohne Technik kein Online-Journalismus

Ohne Technik kein Online-Journalismus Ohne Technik kein Online-Journalismus von Frank Niebisch, Redakteur für Technologie- und Medien-Themen ECONOMY.ONE AG - Verlagsgruppe Handelsblatt Online. f.niebisch@t-online.de 0173/2934640 Bochum, 15.05.2002

Mehr

CORBA. Systemprogrammierung WS 2006-2007

CORBA. Systemprogrammierung WS 2006-2007 CORBA Systemprogrammierung WS 2006-2007 Teilnehmer: Bahareh Akherattalab Babak Akherattalab Inhaltsverzeichnis: Verteilte Systeme Vergleich zwischen lokale und verteilte Systeme Verteilte Anwendungen CORBA

Mehr

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges Komponentenbasierte Client-Architektur Hamburg, 16.11.2007 Bernd Olleck IT-Beratung Olleck Agenda Clients aus drei verschiedenen Perspektiven: Technische Infrastruktur Fachliche Sicht Aufgaben eines Clients

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 8 10. Dezember 2002 www4.in.tum.de/~rumpe/se

Mehr

Remote Communications

Remote Communications HELP.BCFESDEI Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher

Mehr

Ein System zur Evaluation der Netzwerkperformance in Online Computerspielen

Ein System zur Evaluation der Netzwerkperformance in Online Computerspielen Ein System zur Evaluation der Netzwerkperformance in Online Computerspielen Alexander Ploss, Prof. Sergei Gorlatch Arbeitsgruppe Parallele und Verteilte Systeme Projektseminar SS 09 Projektaufgabe (1/2)

Mehr

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests Masterarbeit zur Erlangung des akademischen Grades Master of Science (M.Sc.) im Masterstudiengang Wirtschaftswissenschaft

Mehr

Maple Ein WMS zur Visualisierung von Tagclouds generiert aus OpenStreetMap Daten

Maple Ein WMS zur Visualisierung von Tagclouds generiert aus OpenStreetMap Daten Fakultät Forst-, Geo- und Hydrowissenschaften Institut für Kartographie Maple Ein WMS zur Visualisierung von Tagclouds generiert aus OpenStreetMap Daten Stefan Hahmann Fakultät Forst-, Geo- und Hydrowissenschaften

Mehr

Entwurfsmuster (Design Pattern) ETIS SS05

Entwurfsmuster (Design Pattern) ETIS SS05 Entwurfsmuster (Design Pattern) ETIS SS05 Gliederung Motivation Pattern allgemein Proxy-Pattern Zusammenfassung 2 Motivation I Wie gut sind eure Programme strukturiert? Wartbarkeit? - Verständlichkeit

Mehr

... Einleitung... 15. 3... Prozessintegration und Integrationsszenarien... 127 3.1... Integrationsszenariomodelle... 128

... Einleitung... 15. 3... Prozessintegration und Integrationsszenarien... 127 3.1... Integrationsszenariomodelle... 128 ... Einleitung... 15 1... Grundlagen der Modellierung von Enterprise Services... 23 1.1... Serviceorientierte Architekturen... 26 1.1.1... Merkmale serviceorientierter Architekturen... 27 1.1.2... SOA

Mehr

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

Mehr

Entwicklung von Web-Anwendungen auf JAVA EE Basis

Entwicklung von Web-Anwendungen auf JAVA EE Basis Entwicklung von Web-Anwendungen auf JAVA EE Basis Java Enterprise Edition - Überblick Prof. Dr. Bernhard Schiefer Inhalt der Veranstaltung Überblick Java EE JDBC, JPA, JNDI Servlets, Java Server Pages

Mehr

Quality Point München

Quality Point München Quality Point München Test webbasierter Applikationen - Vorgehen, Instrumente, Probleme Gestern habe ich mich wieder über eine fehlerhafte Webanwendung geärgert. Muss das sein? Test ist halt auch hier

Mehr

Model Driven Architecture

Model Driven Architecture { AKTUELLES SCHLAGWORT* / MODEL DRIVEN ARCHITECTURE Model Driven Architecture Martin Kempa Zoltán Ádám Mann Bei der Model Driven Architecture (MDA) bilden Modelle die zentralen Elemente des Softwareentwicklungsprozesses.

Mehr

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Die Unified Modeling Language Die UML (hier in der Version 0.9) ist ein Satz von Notationen zur Beschreibung objektorientierter Softwaresysteme.

Mehr

Softwareentwicklung mit Enterprise JAVA Beans

Softwareentwicklung mit Enterprise JAVA Beans Softwareentwicklung mit Enterprise JAVA Beans Java Enterprise Edition - Überblick Was ist J2EE Java EE? Zunächst mal: Eine Menge von Spezifikationen und Regeln. April 1997: SUN initiiert die Entwicklung

Mehr

Mitglied der: KNX Association OPC Foundation BACnet Interest Group Europe. Dokumentversion: 1.0.2

Mitglied der: KNX Association OPC Foundation BACnet Interest Group Europe. Dokumentversion: 1.0.2 Mitglied der: KNX Association OPC Foundation BACnet Interest Group Europe Dokumentversion: 1.0.2 Inhaltsverzeichnis 1. System Überblick 4 2. Windows Firewall Konfiguration 5 2.1. Erlauben von DCOM Kommunikation

Mehr

Objektorientierte Analyse. Verfeinerung mit Konnektoren (Kollaborationen, Teams, Rollenmodellen) Obligatorische Literatur

Objektorientierte Analyse. Verfeinerung mit Konnektoren (Kollaborationen, Teams, Rollenmodellen) Obligatorische Literatur Objektorientierte Analyse OOA.3.3 Szenarienanalyse mit komplexen Objekten Prof. Dr. rer. nat. habil. Uwe Aßmann Institut für Software- und Multimediatechnik Lehrstuhl Softwaretechnologie Fakultät für Informatik

Mehr

Software Engineering II (IB) Serviceorientierte Architektur

Software Engineering II (IB) Serviceorientierte Architektur Serviceorientierte Architektur Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Webservices Ziel: flexible programmatische Zusammenarbeit zwischen Servern Bereitstellung

Mehr

Workflow Systeme mit der Windows Workflow Foundation

Workflow Systeme mit der Windows Workflow Foundation Studiengang Electronic Business (EB) Diplomarbeit (280000) Workflow Systeme mit der Windows Workflow Foundation externe Betreuung durch Christoph Müller vorgelegt bei Prof. Dr. Michael Gröschel von Hans-Martin

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Dataport IT Bildungs- und Beratungszentrum. HTML- Grundlagen und CSS... 2. XML Programmierung - Grundlagen... 3. PHP Programmierung - Grundlagen...

Dataport IT Bildungs- und Beratungszentrum. HTML- Grundlagen und CSS... 2. XML Programmierung - Grundlagen... 3. PHP Programmierung - Grundlagen... Inhalt HTML- Grundlagen und CSS... 2 XML Programmierung - Grundlagen... 3 PHP Programmierung - Grundlagen... 4 Java - Grundlagen... 5 Java Aufbau... 6 ASP.NET Programmierung - Grundlagen... 7 1 HTML- Grundlagen

Mehr

Visual Studio LightSwitch 2011

Visual Studio LightSwitch 2011 1 Visual Studio LightSwitch 2011 Vereinfachte Softwareentwicklung im Eiltempo W3L AG info@w3l.de 2012 2 Agenda Motivation Softwareentwicklung im Eiltempo Was ist LightSwitch? Merkmale Zielgruppe LightSwitch

Mehr

Vorwort. Zu dieser Reihe. Autoren. Vorwort

Vorwort. Zu dieser Reihe. Autoren. Vorwort Vorwort 9 10 Vorwort Vorwort Herzlich Willkommen zu einem Fachbuch von Comelio Medien, ein Bereich der Comelio GmbH. Dieses Buch aus unserer Reihe zur.net-entwicklung ist das Ergebnis einer Forschungsarbeit,

Mehr

Über dieses Buch. Kapitel 1. 1.1 Einleitung

Über dieses Buch. Kapitel 1. 1.1 Einleitung Kapitel 1 Über dieses Buch 1.1 Einleitung Dieses Buch behandelt das Vorgehensmodell Kanban und seinen Einsatz in Softwareentwicklungsprojekten. Kanban ist ein Vorgehensmodell der schlanken Softwareentwicklung

Mehr

Inhaltsverzeichnis 1 Einleitung 2 Ansätze in Forschung und Praxis

Inhaltsverzeichnis 1 Einleitung 2 Ansätze in Forschung und Praxis ix 1 Einleitung 1 1.1 Motivation 1 1.1.1 Das Projekt»Steuerkanzlei 2005«2 1.1.2 Generalisierung des Anwendungsfalls 3 1.1.3 Situation der Business Intelligence 4 1.1.4 Probleme in der praktischen Anwendung

Mehr

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen Daniel Liebhart SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen ISBN-10: 3-446-41088-0 ISBN-13: 978-3-446-41088-6 Inhaltsverzeichnis Weitere Informationen oder Bestellungen

Mehr

BPMN. Suzana Milovanovic

BPMN. Suzana Milovanovic BPMN Suzana Milovanovic 2 Übersicht Klärung von Begriffen, Abkürzungen Was ist BPMN? Business Process Diagram (BPD) Beispielprozess Entwicklung von BPMN BPMN in der Literatur 3 Grundlegende Begriffe Business

Mehr

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java Willkommen zur Vorlesung Objektorientierte Programmierung Vertiefung - Java Zum Dozenten Mein Name: Andreas Berndt Diplom-Informatiker (TU Darmstadt) Derzeit Software-Entwickler für Web- Applikationen

Mehr

Message Oriented Middleware am Beispiel von XMLBlaster

Message Oriented Middleware am Beispiel von XMLBlaster Message Oriented Middleware am Beispiel von XMLBlaster Vortrag im Seminar XML und intelligente Systeme an der Universität Bielefeld WS 2005/2006 Vortragender: Frederic Siepmann fsiepman@techfak.uni bielefeld.de

Mehr

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16 Probeklausur Lenz Belzner January 26, 2015 Lenz Belzner Probeklausur January 26, 2015 1 / 16 Definieren Sie Software Engineering in Abgrenzung zu Individual Programming. Ingenieursdisziplin professionelle

Mehr

Cloud Computing in Industrie 4.0 Anwendungen: Potentiale und Herausforderungen

Cloud Computing in Industrie 4.0 Anwendungen: Potentiale und Herausforderungen Cloud Computing in Industrie 4.0 Anwendungen: Potentiale und Herausforderungen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftsingenieur der Fakultät

Mehr

Web Services: Inhalt

Web Services: Inhalt Web Services Fachseminar Verteilte Systeme 8. April 2002 - Marco Steiner Assistent: Thomas Schoch Professor: Dr. F. Mattern Web Services: Inhalt Bedeutung Gegenwart Architektur SOAP WSDL UDDI Vergleich

Mehr

Inhaltsverzeichnis. Gernot Starke. Effektive Softwarearchitekturen. Ein praktischer Leitfaden ISBN: 978-3-446-42728-0

Inhaltsverzeichnis. Gernot Starke. Effektive Softwarearchitekturen. Ein praktischer Leitfaden ISBN: 978-3-446-42728-0 sverzeichnis Gernot Starke Effektive Softwarearchitekturen Ein praktischer Leitfaden ISBN: 978-3-446-42728-0 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-42728-0 sowie im

Mehr

Factsheet. Einbau TOSC4. Version: 4 Letzte Änderung: 19.12.2013 Geändert von: Armin Schanitz

Factsheet. Einbau TOSC4. Version: 4 Letzte Änderung: 19.12.2013 Geändert von: Armin Schanitz Factsheet Einbau TOSC4 Version: 4 Letzte Änderung: 19.12.2013 Geändert von: Armin Schanitz Letzte Änderungen: - Mobile Version - Reverse Proxy - Hinweise Lightbox 0. Inhaltsverzeichnis 0. 1. 2. INHALTSVERZEICHNIS...

Mehr

LDAP verstehen, OpenLDAP einsetzen

LDAP verstehen, OpenLDAP einsetzen Dieter Klünter Jochen Laser LDAP verstehen, OpenLDAP einsetzen Grundlagen, Praxiseinsatz und Single-sign-on-Mechanismen Technische Universität Darmstadt FACHBEREICH INFORMATIK Invanter-Nr, J Standort:

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering

Mehr

Inhalt. 3 Architektureller Entwurf... 39 3.1 Modellgeleitete Entwicklung... 39 3.2 Was ist Software-Architektur?... 43

Inhalt. 3 Architektureller Entwurf... 39 3.1 Modellgeleitete Entwicklung... 39 3.2 Was ist Software-Architektur?... 43 1 Was ist Software-Architektur?... 1 1.1 Software-Architektur als Abstraktion... 2 1.2 Software-Architektur als Bauplan... 3 1.3 Software-Architektur-Terminologie... 5 1.4 Was ist Software-Architektur?...

Mehr

Prinzipien der Application Centric Infrastructure

Prinzipien der Application Centric Infrastructure Whitepaper Prinzipien der Application Centric Infrastructure Übersicht Eine der wichtigsten Innovationen der Application Centric Infrastructure (ACI) ist die Einführung einer hochabstrakten Schnittstelle

Mehr

Optimieren von Requirements Management & Engineering

Optimieren von Requirements Management & Engineering Xpert.press Optimieren von Requirements Management & Engineering Mit dem HOOD Capability Model Bearbeitet von Colin Hood, Rupert Wiebel 1. Auflage 2005. Buch. xii, 245 S. Hardcover ISBN 978 3 540 21178

Mehr

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I)

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar: KLIPS 2.0 Dozent: Prof. Dr. Thaller Referent:

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

Model Driven SOA. < J Springer. Anwendungsorientierte Methodik und Vorgehen in der Praxis. Gerhard Rempp Mark Akermann Martin Löffler Jens Lehmann

Model Driven SOA. < J Springer. Anwendungsorientierte Methodik und Vorgehen in der Praxis. Gerhard Rempp Mark Akermann Martin Löffler Jens Lehmann Gerhard Rempp Mark Akermann Martin Löffler Jens Lehmann Model Driven SOA Anwendungsorientierte Methodik und Vorgehen in der Praxis Mit Illustrationen von Martin Starzmann < J Springer Inhaltsverzeichnis

Mehr

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten Aktuelle Themen der Wirtschaftsinformatik Zusammenfassung 09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten 1 Serverseitige Webprogrammierung

Mehr

Abschlussvortrag Masterarbeit: Operationalizing Architecture in an agile Software Projec

Abschlussvortrag Masterarbeit: Operationalizing Architecture in an agile Software Projec Abschlussvortrag Masterarbeit: Operationalizing in an agile Software Projec Freie Universität Berlin, Institut für Informatik February 2, 2015 Übersicht 2 Was ist Softwarearchitektur? Softwarearchitektur

Mehr

XML Grundlagen Sommersemester 2013

XML Grundlagen Sommersemester 2013 XML Grundlagen Sommersemester 2013 Die Lehrveranstaltung wird studienbegleitend durch eine Hausarbeit und eine Präsentation mit Diskussion geprüft. Die Themen der folgenden Liste werden im Rahmen der Lehrveranstaltung

Mehr

Analyse von Sicherheitaspekten in Service-orientierten Architekturen

Analyse von Sicherheitaspekten in Service-orientierten Architekturen Analyse von Sicherheitaspekten in Service-orientierten Architekturen Vortragende: Jia Jia Betreuer: Dipl.-Inf. Matthias Lehmann Dresden,10.12.2009 10.12.2009 Analyse von Sicherheitaspekten in SOA 1 Gliederung

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr

Weborientierte Programmiersprachen am Beispiel PHP

Weborientierte Programmiersprachen am Beispiel PHP Weborientierte Programmiersprachen am Beispiel PHP Serak Rezane Seminar Programmiersprachen SS 2004 Betreuer: Prof. Dr. Claudia Leopold Dipl.-Inf. Michael Süß Was ist PHP? Gliederung (Definition, Geschichte,

Mehr

Software Engineering Übung 4 Architektur, Modulentwurf

Software Engineering Übung 4 Architektur, Modulentwurf software evolution & architecture lab Software Engineering Übung 4 Architektur, Modulentwurf 1 Informationen 1.1 Daten Ausgabe Di 27.10.2009 Abgabe So 08.11.2009 bis 23:59 Uhr Besprechung am Di 17.11.2009

Mehr

Angreifbarkeit von Webapplikationen

Angreifbarkeit von Webapplikationen Vortrag über die Risiken und möglichen Sicherheitslücken bei der Entwicklung datenbankgestützter, dynamischer Webseiten Gliederung: Einführung technische Grundlagen Strafbarkeit im Sinne des StGB populäre

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Verteilte Systeme. Verteilte Architekturen. Prof. Dr. Oliver Haase

Verteilte Systeme. Verteilte Architekturen. Prof. Dr. Oliver Haase Verteilte Systeme Verteilte Architekturen Prof. Dr. Oliver Haase 1 Übersicht Plattformen für verteilte Systeme Softwarearchitekturen Systemarchitekuren Von der Software- zur Systemarchitektur Architekturmuster

Mehr

Aspektorientierte Modellierung

Aspektorientierte Modellierung Aspektorientierte Modellierung Softwaretechnik-Seminar 2002 Thema: Evolutionäre Software Referent: Alexander Winter Gliederung Einführung und Motivation Was ist Aspektorientierte Modellierung? Vorstellung

Mehr

Proseminar Technische Informatik A survey of virtualization technologies

Proseminar Technische Informatik A survey of virtualization technologies Proseminar Technische Informatik A survey of virtualization technologies Referent: Martin Weigelt Proseminar Technische Informatik - A survey of virtualization technologies 1 Übersicht 1. Definition 2.

Mehr

3. Konzepte der objektorientierten Programmierung

3. Konzepte der objektorientierten Programmierung 3. Konzepte der objektorientierten Programmierung 3.1 Basiskonzepte 3.2 Generalisierung / Spezialisierung 3.3 Aggregation 3.4 Assoziation 3.5 Nachrichten 3.6 Polymorphismus 3. Konzepte der Objektorientierung

Mehr

Alexandru Arion, Benjamin Schöllhorn, Ingo Reese, Jürgen Gebhard, Stefan Patsch, Stephan Frank

Alexandru Arion, Benjamin Schöllhorn, Ingo Reese, Jürgen Gebhard, Stefan Patsch, Stephan Frank Message Broker (MB) Alexandru Arion, Benjamin Schöllhorn, Ingo Reese, Jürgen Gebhard, Stefan Patsch, Stephan Frank Programmierung verteilter Systeme Lab Institut für Informatik Universität Augsburg Universitätsstraße

Mehr

Methodische Entwicklung

Methodische Entwicklung Methodische Entwicklung sicherer CORBA-Anwendungen Jan Jürjens Software & Systems Engineering Informatik, TU München juerjens@in.tum.de http://www.jurjens.de/jan Jan Jürjens, TU München: Entwicklung sicherer

Mehr

Content Management. Systeme. 15.05.2002 Irina Fröse

Content Management. Systeme. 15.05.2002 Irina Fröse Content Management Systeme 15.05.2002 Irina Fröse Was ist ein Content Management-System? Content Management ist ein Prozess, der von der Erstellung bis zur Präsentation der Inhalte reicht. Content Management-System

Mehr

SNMP und der MIB- Browser von MG-Soft

SNMP und der MIB- Browser von MG-Soft SNMP und der MIB- Browser von MG-Soft 1. SNMP 1.1 Was ist SNMP 1.2 Historie von SNMP 1.3 Einordnung in das OSI-Modell 1.4 Die Architektur von SNMP 1.5 Kommunikation von SNMP 1.6 SNMP-PDUs PDUs 2. MIB und

Mehr

Ein Auszug aus... Studie. Content Management Systeme im Vergleich. Empfehlungen und Entscheidungshilfen für Unternehmensbereiche

Ein Auszug aus... Studie. Content Management Systeme im Vergleich. Empfehlungen und Entscheidungshilfen für Unternehmensbereiche Ein Auszug aus... Studie Content Management Systeme im Vergleich Empfehlungen und Entscheidungshilfen für Unternehmensbereiche Die komplette Studie ist bei amazon.de käuflich zu erwerben. Inhaltsverzeichnis

Mehr

Das Interceptor Muster

Das Interceptor Muster Das Interceptor Muster Implementierung des Interceptor Musters basierend auf OSGi and Friends Benjamin Friedrich Hochschule für Technik und Wirtschaft des Saarlandes Praktische Informatik - Entwurfsmuster

Mehr

Proseminar: Website-Management-Systeme

Proseminar: Website-Management-Systeme Proseminar: Website-Management-Systeme Thema: Web: Apache/Roxen von Oliver Roeschke email: o_roesch@informatik.uni-kl.de Gliederung: 1.) kurze Einleitung 2.) Begriffsklärung 3.) Was ist ein Web? 4.) das

Mehr

Securing SOAP e-services

Securing SOAP e-services Securing SOAP e-services Nilson Reyes Sommersemester 2004 aus: E. Damiani, S. De Capitani di Vermercati, S. Paraboschi, P. Samarati, Securing SOAP e-sservices, IJIS, Ausgabe 1 (2002), S.110-115. Gliederung

Mehr

1 Problematik eines uneinheitlichen Verständnisses der SOA... 201. 2 SOA als unternehmensweites Architekturkonzept... 203

1 Problematik eines uneinheitlichen Verständnisses der SOA... 201. 2 SOA als unternehmensweites Architekturkonzept... 203 Mehr als alter Wein in neuen Schläuchen 199 1 Problematik eines uneinheitlichen Verständnisses der SOA... 201 2 SOA als unternehmensweites Architekturkonzept........... 203 3 Struktur einer SOA..................................

Mehr

Komponentenbasierte Softwareentwicklung

Komponentenbasierte Softwareentwicklung Seminar WS04 Komponentenbasierte Softwareentwicklung Karl Pauls Software-Komponente A software component is a unit of composition with contractually specified interfaces and explicit context dependencies

Mehr

Universität Passau. Betriebswirtschaftslehre mit Schwerpunkt Internationales Management Prof. Dr. Carola Jungwirth. Masterarbeit

Universität Passau. Betriebswirtschaftslehre mit Schwerpunkt Internationales Management Prof. Dr. Carola Jungwirth. Masterarbeit Universität Passau Betriebswirtschaftslehre mit Schwerpunkt Internationales Management Prof. Dr. Carola Jungwirth Masterarbeit "Identifikation von Erfolgsfaktoren für eine Facebook- Recruiting-Strategie"

Mehr

Wiki-basierte Dokumentation von Software-Entwicklungsprozessen

Wiki-basierte Dokumentation von Software-Entwicklungsprozessen Wiki-basierte Dokumentation von Software-Entwicklungsprozessen Erfahrungen aus der industriellen Praxis Fraunhofer IESE Kaiserslautern Inhalt Wiki-basierte Dokumentation von Software-Entwicklungsprozessen

Mehr

(Titel des Berichts)

(Titel des Berichts) (Titel des Berichts) Praxissemesterbericht von (Vorname Name) aus (Geburtsort) Matrikelnummer Anschrift Telefon HTW Aalen Hochschule für Technik und Wirtschaft Betreuender Professor Abgabetermin Angaben

Mehr

Grob- und Detailplanung bei der Implementierung nutzen

Grob- und Detailplanung bei der Implementierung nutzen Softwarearchitektur Grob- und Detailplanung bei der Implementierung nutzen Bereich Realisierung Aktivität Softwareinkrement realisieren Ziele Vermitteln einer Orientierungshilfe für alle Entwickler Etablierung

Mehr

Grundsätzliche Struktur und Entwurfsprinzipien des Gesamtsystems. Grundsätzliche Struktur und Entwurfsprinzipien der einzelnen Pakete

Grundsätzliche Struktur und Entwurfsprinzipien des Gesamtsystems. Grundsätzliche Struktur und Entwurfsprinzipien der einzelnen Pakete Allgemeines 2 Produktübersicht 2 Grundsätzliche Struktur und Entwurfsprinzipien des Gesamtsystems 3 Grundsätzliche Struktur und Entwurfsprinzipien der einzelnen Pakete Account-Verwaltung 5 Freund-Funktionen

Mehr

- Agile Programmierung -

- Agile Programmierung - Fachhochschule Dortmund Fachbereich Informatik SS 2004 Seminar: Komponentenbasierte Softwareentwicklung und Hypermedia Thema: - - Vortrag von Michael Pols Betreut durch: Prof. Dr. Frank Thiesing Übersicht

Mehr

Der Entwicklungsprozess. Oder wie entwickle ich ein eingebettetes System?

Der Entwicklungsprozess. Oder wie entwickle ich ein eingebettetes System? Der Entwicklungsprozess Oder wie entwickle ich ein eingebettetes System? Einleitung Problemstellung erläutern, Eine Entwicklungsprozess ist ein Prozess, der beschreibt, wie man eine Entwicklung anzugehen

Mehr