UNIVERSITÄT AUGSBURG. Fakultät für Informatik Multimedia Concepts and their Applications Prof. Dr. Elisabeth André. Masterarbeit

Transkript

1 UNIVERSITÄT AUGSBURG Fakultät für Informatik Multimedia Concepts and their Applications Prof. Dr. Elisabeth André Masterarbeit Entwicklung eines Systems zur Integration dezentraler organisierter Webanwendungen in ein einheitliches Benutzerinterface am Beispiel eines Lernportals vorgelegt von: Student: Patrick Noack Studiengang: Master Informatik und Multimedia Fachsemester: 4 Matrikelnummer: Geburtsdatum: Adresse: Pfladergasse 20 Telefon-Nr.: noack@limtec.de Augsburg, den

2 II

3 Zusammenfassung In dieser Arbeit werden am Beispiel des zentralen Lernportals Digicampus die Probleme und Herausforderungen bei Konzeption, Betrieb und der kontinuierlichen Weiterentwicklung heterogener Webportale aufgezeigt. In vielen Fällen werden diese Prozesse durch schlechte Integrationsmöglichkeiten und unzureichende Schnittstellen von innerhalb des Portals eingesetzten Webanwendungen erschwert. Dem Leser werden daher unterschiedliche Lösungsstrategien vorgestellt, die sich mit der Integrationsproblematik in und von Webanwendungen befassen. Im Rahmen dieser Arbeit wird basierend auf aktuellen Forschungsergebnissen die Idee und das Konzept des Frameworks emigrant erarbeitet, mit dem sich beliebige Webanwendungen optisch und funktional in ein Portal integrieren lassen, ohne dass dafür Modifikationen in deren Quelltext vorgenommen werden müssen. Außerdem wird die Implementierung eines funktionsfähigen Prototyps dokumentiert und im Anschluss die Integration einiger Webanwendungen aus der Sicht eines Administrators an praktischen Beispielen gezeigt. Den Abschluss der Arbeit bildet ein Ausblick in die Zukunft, indem der weitere Projektverlauf und die Einsatzmöglichkeiten des Frameworks diskutiert werden. Schlagwörter: Lernportal, Proxy, Integration, Webportal, Software-Entwicklung, Widget, Mashup, e-learning, Learning Management System, LMS, Dezentralisierung, Service Oriented Architecture, SOA, Content Management, Personal Learning Environment III

4 IV

5 Inhalt 1 EINLEITUNG VORTEILE VON WEBANWENDUNGEN...1 NACHTEILE VON WEBANWENDUNGEN...2 DIGICAMPUS ALS PRAXISBEISPIEL FÜR DEN ENTWICKLUNGSPROZESS EINES LEHR-/LERNPORTALS...6 GLIEDERUNG DER ARBEIT TECHNISCHE GRUNDLAGEN GRUNDBEGRIFFE BROWSER-KOMMUNIKATION WEBTECHNOLOGIEN TECHNISCHE ANFORDERUNGEN AN EIN LERNPORTAL ANFORDERUNGEN AUS BENUTZERSICHT ANFORDERUNGEN AUS ENTWICKLERSICHT VERWANDTE ARBEITEN NEUENTWICKLUNG EINES LEHR-/LERNPORTALS INTEGRATION NEUER FUNKTIONEN UND ANWENDUNGEN ANPASSUNG DER DARSTELLUNG EINER WEBSEITE FACEBOOK ALS VORBILD FÜR EINE OFFENE LERNPLATTFORM? ENTWICKLUNGSSTRATEGIE NEUENTWICKLUNG, WEITERENTWICKLUNG ODER FRAMEWORK ENTSTEHUNG DES LERNPORTALS DIGICAMPUS WEITERENTWICKLUNG DES DIGICAMPUS KONZEPT INTEGRATION UND ERWEITERUNG VON ANWENDUNGEN...42 ANWENDUNGSLEISTUNG...47 BENUTZERVERWALTUNG...48 ENTWICKLERZUGRIFF...50 GRAFISCHE OBERFLÄCHE ZUR KONFIGURATION ARCHITEKTUR ENTWURFSMUSTER MVC KOMMUNIKATION IM EMIGRANT-FRAMEWORK PORTALARCHITEKTUREN IM EMIGRANT-FRAMEWORK IMPLEMENTIERUNG EMIGRANT-CLIENT...58 EMIGRANT-SERVER...75 GRAFISCHE BENUTZEROBERFLÄCHE...89 AJAX -FUNKTIONEN...90 BEDIENELEMENTE UND DARSTELLUNG...91 KONFIGURATIONSOBERFLÄCHE...95 V

6 8.7 BENUTZERFUNKTIONEN PRAXISBEISPIEL ERSTELLUNG EINER PORTALSEITE AUTOMATISCHE BENUTZER-REGISTRIERUNG UND LOGIN LESSONS LEARNED AUSBLICK LITERATURVERZEICHNIS ANHANG...I VI

7 Verzeichnis der Abbildungen ABB. 1: DER DIGICAMPUS UND SEINE FUNKTIONEN (1.3)...6 ABB. 2: EINIGE BEISPIELE FÜR RELATIVE URL-ANGABEN (2.1)...9 ABB. 3: CLIENT-SERVER-KOMMUNIKATION BEIM ABSENDEN EINES EINFACHEN WEB-FORMULARS (2.2) 11 ABB. 4: KOMPONENTEN, FUNKTIONEN UND BENUTZER EINES LERNPORTALS (2.3)...15 ABB. 5: POPULARITÄT DER SUCHBEGRIFFE TYPO3 UND DRUPAL BEI GOOGLE (4.1)...25 ABB. 6: DAS SOZIALE NETZWERK FACEBOOK (4.4)...34 ABB. 7: LOGO DES EMIGRANT-FRAMEWORKS (6)...42 ABB. 8: ABFANGEN DES HTTP-DATENVERKEHRS DURCH DAS EMIGRANT-FRAMEWORK (6.1.1)...43 ABB. 9: ERSTELLUNG EINES WIDGETS AUS SYSTEM2 UND EINBETTUNG IN SYSTEM1 (6.1.3)...45 ABB. 10: ERSTELLUNG EINES WIDGETS AUS SYSTEM2 UND EINBETTUNG IN SYSTEM1 (6.1.3)...46 ABB. 11: INTEGRATION EINES WIDGETS: CLIENTSEITIG (LINKS), SERVERSEITIG (RECHTS) (6.1.3)...47 ABB. 12: SINGLE SIGN-ON (6.3.1)...48 ABB. 13: ANWENDUNGSSPEZIFISCHE NUTZERPROFILE (6.3.3)...49 ABB. 14: KOMPONENTEN DES EMIGRANT-FRAMEWORKS (7)...52 ABB. 15: KOMPONENTEN DES EMIGRANT-FRAMEWORKS (7.1)...53 ABB. 16: BREITE VS. TIEFE INTEGRATION VON ANWENDUNGEN IM EMIGRANT-FRAMEWORK (7.3)...55 ABB. 17: ABLAUF EINER BREITEN SERVERSEITIGEN INTEGRATION (7.3)...56 ABB. 18: ABLAUF EINER TIEFEN SERVERSEITIGEN INTEGRATION (7.3)...57 ABB. 19: NORMALER MODUS VS. PROXY MODUS (8.1.1)...59 ABB. 20: AUFRUF DER SEITE MIT UND OHNE PROXY (8.1.3)...66 ABB. 21: FEHLERMELDUNG BEIM VERSUCH EINE CROSS-SITE-SCRIPTING ATTACKE DURCHZUFÜHREN (8.1.7)...74 ABB. 22: ERZEUGUNG UND INTEGRATION EINES WIDGETS NEWSBOX (8.2.1)...76 ABB. 23: DROPDOWN-MENÜ ZUM SCHNELLEN BENUTZER-ROLLENWECHSEL (8.2.2)...86 ABB. 24: AUSGABE DES INTEGRIERTEN DEBUGGERS (8.2.3)...88 ABB. 25: NACHLADEN RELEVANTER SEITENBEREICHE VIA AJAX (8.4)...90 ABB. 26: VESCHIEDENE ÜBERSCHRIFTEN-EBENEN DER JQUERYUI-KLASSE (8.5)...91 ABB. 27: KONTEXT-SENSITIVER LÖSCHEN-BUTTON BEIM ÜBERFAHREN MIT DER MAUS (8.5)...92 ABB. 28: DROPDOWN-MENÜ MIT FORMULARREIHENAUSWAHL (8.5)...92 ABB. 29: KONTEXT-SENSITIVER LÖSCHEN-BUTTON BEIM ÜBERFAHREN MIT DER MAUS (8.5)...93 ABB. 30: INFORMATIONSMELDUNG (LINKS) UND KURZINFOS (RECHTS) (8.5)...94 ABB. 31: PARSER EINSTELLUNGEN IN DER KONFIGURATIONSOBERFLÄCHE (8.6.2)...96 ABB. 32: AUFGEKLAPPTER PARSER-REGELSATZ IN DEN PARSER EINSTELLUNGEN (8.6.2)...97 ABB. 33: FEHLER BEI DER REGISTRIERUNG EINES NEUEN BENUTZERS AUFGRUND FALSCHER ANGABEN (8.7.1) ABB. 34: AUTOMATISCHE GENERIERUNG DES REGISTRIERUNGSFORMULARS AUS DEN ANWENDUNGSPROFILEN (8.7.1) ABB. 35: KONTOEINSTELLUNGEN EINES EINGELOGGTEN BENUTZERS (8.7.2) ABB. 36: VERBESSERTE DIGICAMPUS-BENUTZEROBERFLÄCHE - AUFTEILUNG (9.1) ABB. 37: ERSTELLUNG EINES SEITENTEMPLATES (9.1.1) ABB. 38: REGISTRIERUNG EINER ANWENDUNG (9.1.2) ABB. 39: AUFRUF DER ANWENDUNG STUD.IP ÜBER DAS EMIGRANT-FRAMEWORK (9.1.2) VII

8 ABB. 40: AKTIVIERUNG DES TEMPLATES MAIN UND ANSCHLIESSENDER AUFRUF DER ANWENDUNG STUD.IP (9.1.3) ABB. 41: PARSER-REGEL, UM DEN MENSA-SPEISEPLAN AUS DER STUDENTENWERKSSEITE ZU EXTRAHIEREN (9.1.4) ABB. 42: EINBINDEN DES MENSAPLAN-WIDGETS IN DIE ANWENDUNG STUD.IP (9.1.5) ABB. 43: INTEGRATION DER ANWENDUNG EEE-PORTFOLIO IN DAS EMIGRANT-FRAMEWORK UND ZUWEISUNG EINER BENUTZERROLLE (9.2) ABB. 44: ANALYSE DES REGISTRIERUNGSFORMULARS DER EEE-PORTFOLIO PLATTFORM (9.2.1) ABB. 45: INTEGRATION DER ANWENDUNG EEE-PORTFOLIO IN DAS EMIGRANT-FRAMEWORK UND ZUWEISUNG EINER BENUTZERROLLE (9.2.2) ABB. 46: INTEGRATION DER ANWENDUNG EEE-PORTFOLIO IN DAS EMIGRANT-FRAMEWORK UND ZUWEISUNG EINER BENUTZERROLLE (9.2.4) ABB. 47: LOGIN IN DAS EMIGRANT-FRAMEWORK (9.2.4) Verzeichnis der Tabellen TAB. 1: BEWERTUNG DER VOR- UND NACHTEILE UNTERSCHIEDLICHER ENTWICKLUNGSSTRATEGIEN FÜR DIGICAMPUS...40 TAB. 2: BEISPIELE FÜR DAS SUCHMUSTERVERFAHREN...77 TAB. 3: HÄUFIGE FEHLERQUELLEN...87 TAB. 4: AKTION FÜR DIE DURCHFÜHRUNG EINER AUTOMATISCHEN REGISTRIERUNG IM SYSTEM EEEPORTFOLIO DEN Verzeichnis des Anhangs ANHANG I: AUFRUF DER SEITE ÜBER DEN EMIGRANT-CLIENT...I ANHANG II: ANPASSUNG EINER SEITE IM EMIGRANT-SERVER...II ANHANG III: CD MIT QUELLEN UND PROGRAMMBESCHREIBUNG...III VIII

9 Verzeichnis der Abkürzungen LMS Learning Managment System CMS Content Management System LCMS Learning Content Management System PLE Personal Learning Environments URL Uniform Ressource Locator HTTP Hypertext Transfer Protokoll GUI Graphical User Interface FBML Facebook Markup Language HTML Hypertext Markup Language PHP PHP Hypertext Preprocessor UI User Interface MDL Mashart Description Language IX

10

11 1. Einleitung 1 Einleitung Das Internet ist aus unser heutigen Gesellschaft nicht mehr wegzudenken, und die Entwicklung schreitet rapide voran. Das Mitmach-Internet ist allgegenwärtig, der Internetsurfer ist nicht mehr ein passiver Rezipient, sondern beteiligt sich aktiv an der Verbreitung von Informationen, sei es, indem er bei Wikipedia1 einen Artikel überarbeitet, mit Studienkollegen via Doodle2 den besten Termin für einen Ausflug ermittelt oder bei facebook3 die Fotos seines Nachbarn kommentiert. Diesem Trend folgen auch zahlreiche Internetkonzerne und bieten Ihren Benutzern für jeden Zweck die passende Webapplikation, die meisten davon sogar kostenlos. Die Palette der Anwendungen reicht von Online-Bild-Bearbeitung über Live-Broadcasting vom eigenen Mobiltelefon bis hin zu einem vollständigen Online-Desktop, bei dem sämtliche Nutzerdaten und Anwendungen über den Browser verwaltet werden. Durch das vielfältige Online-Angebot verliert der klassische Desktop-PC an Bedeutung, da die Webanwendungen sich auf jedem Endgerät nutzen lassen, das über einen Webbrowser und Internetanbindung verfügt. Die zunehmende Verbreitung von Netbooks [1], Internet-Tablets und Smartphones [2] bei gleichzeitig rückläufigen Verkaufszahlen der Desktop-Systeme [3] bestätigen diesen Trend. 1.1 Vorteile von Webanwendungen Webanwendungen laufen auf modernen Smartphones, wie dem iphone4, dem Palm Pre5 oder Android6-Systemen ebenso problemlos, wie auf dem heimischen PC. Für den Benutzer bietet eine Webanwendung den wesentlichen Vorteil, dass er orts- und geräteunabhängig bleibt und der darin befindliche Datenbestand sowie das Aussehen der Anwendungen überall weitgehend identisch ist. Zudem ist die Software sofort verfügbar, ohne dass dies mit einem längeren Installationsprozedere verbunden ist. Dadurch lässt sich neue webbasierte Software auch meist gefahrlos im Browser ausprobieren, ohne dass das System selbst Schaden davon nehmen kann. Die Daten einer Webanwendung werden in der Regel zentral auf einem Server abgelegt und sind somit nicht von der Verfügbarkeit des heimischen Rechners abhängig. Es spielt daher auch keine Rolle, an welcher Arbeitsstation der Benutzer auf die Anwendung zugreift, er findet stets die Anwendung so vor, wie er sie zuletzt verlassen hat. Die zentrale Speicherung bedeutet auch, dass sich die Daten vieler auf der ganzen Welt verteilter Nutzer zusammenführen lassen. Es entstehen semantische Verknüpfungspunkte, die auch in der alltäglichen Arbeit mit der Anwendung einen Mehrwert schaffen. In Google-Docs7 ist es zum Beispiel möglich, als Team von mehreren Benutzern simultan in einem Dokument arbeiten. Um ein Dokument einem anderen Benutzer zur Verfügung zu stellen, genügt ein einfacher Link, der Benutzer spart sich das zeitauf

12 1. Einleitung wendige Hin- und Herschicken von Dateien. Bei Heimcomputern wird das Thema Backup und Sicherheit gerade von weniger erfahrenen Anwendern oft vernachlässigt. Die meisten großen Anbieter verfügen hingegen über eine gute Backup-Infrastruktur und kümmern sich um die regelmäßige Sicherung und Versionierung der dort gespeicherten Daten. Auch bei Updates muss sich der Benutzer in der Regel nicht darum kümmern, ob eine Software aktuell ist, sofern er nicht selbst der Betreiber ist. Für Entwickler und Betreiber sind Webanwendungen ebenfalls attraktiv, da das Produkt nicht auf verschiedene Plattformen portiert werden muss und die Intervalle für ein Update nicht vom Hersteller eines Betriebssystems vorgegeben werden. Die Standardisierungsmaßnahmen bei Webtechnologien sorgen dafür, dass auch 15 Jahre alte Internetseiten sich immer noch problemlos auf gängigen Webserversystemen betreiben lassen und die Ansicht im Browser nicht von der ursprünglichen Darstellung abweicht. Zudem behält der Entwickler die volle Kontrolle über sein Produkt. Er kann jederzeit Updates bereitstellen und dabei sicherstellen, dass alle Benutzer zum selben Zeitpunkt von den Update profitieren. Dadurch ist auch gewährleistet, dass ein Dokument in einem Internet-Office-Programm immer gleich aussieht, unabhängig davon, welcher Nutzer gerade darauf zugreift. Für einen Anbieter von Webapplikationen ist es somit einfacher eine Entwicklung im Sinne von Continuous Integration8 voranzutreiben, da er ausschließen kann, dass auch noch ältere Versionen desselben Produkts eingesetzt werden. Auch die Finanzierung von Webanwendungen gestaltet sich einfacher, da auf eine aufwendige Vertriebs- und Händlerinfrastruktur, die Auslieferung von Datenträgern und den Installationssupport verzichtet werden kann. Kostenpflichtige Webanwendungen können als Software-as-a-Service mit langfristigen Mietverträgen vermietet werden und erhöhen damit die Planungssicherheit und Entwicklungsperspektive des Herstellers [BK00]. Ein weiterer Vorteil besteht darin, dass sich eine Webanwendung wesentlich schwieriger cracken lässt, ohne dass der Anbieter davon Kenntnis nimmt. Somit sind auch Raubkopien bei Webanwendungen weit weniger verbreitet. 1.2 Nachteile von Webanwendungen Obgleich die Webanwendungen zahlreiche Vorteile bieten, bringt der Wechsel von den klassischen Desktop-Anwendungen hin zu Webanwendungen für den Benutzer auch einige Nachteile mit sich, die überwiegend auf die meist intransparente Verteilung der Anwendung und Daten auf verschiedene Server unterschiedlicher Anbieter zurückzuführen ist. Die Nachteile sind: 8 Datenschutz auf Vertrauensbasis Geschlossene Plattformen Mangelhafte Datenkontrolle Mehrfach-Login Daten nicht offline verfügbar Verringerte Geschwindigkeit keine anwendungsübergreifende Datenkonsistenz 2

13 1. Einleitung Datenschutz auf Vertrauensbasis Während der Benutzer einer Desktopanwendung auch gleichzeitig der Besitzer der in der Anwendung gespeicherten persönlichen Daten ist, bleibt bei den meisten InternetDienstleistern völlig ungeklärt, wo die Daten in welcher Form gespeichert, welche zusätzlichen Daten erhoben werden und wie gut die Daten gegen den Zugriff anderer geschützt sind. Der Benutzer einer Internetanwendung übergibt somit die vollständige Verantwortung über die dort verwalteten Daten seinem Anbieter. Er muss vertrauen, dass dieser die hinterlegten Informationen gegen Fremdzugriff absichert, Backups gewissenhaft durchführt und auch für die Zukunft die Erreichbarkeit und den Zugriff auf die Daten gewährleisten kann. Geschlossene Plattformen Darüber hinaus sind viele Internetanwendungen voneinander unabhängige Insellösungen, die keine standardisierten Schnittstellen zu anderen Internetanwendungen bieten und jeweils eigene Benutzerkonten erfordern. Am Beispiel der sozialen Netzwerke (Def. Kap.2.3) zeigt sich, welche Nachteile damit verbunden sind. Möchte man seinen gesamten Freundeskreis über etwas informieren, so muss man die Nachricht in der Regel in mehreren verschiedenen Portalen absenden. Freunde, die ebenfalls in mehreren Sozialen Netzwerken eingetragen sind, erhalten die Nachricht doppelt. Das Gleiche gilt, wenn man seinen Freunden Fotos zur Verfügung stellen möchte. Da nie davon auszugehen ist, dass alle Freunde ausschließlich ein Soziales Netzwerk benutzen, sieht man sich also unter Umständen dazu gezwungen, sich bei verschiedenen Portalen anzumelden. Mangelhafte Datenkontrolle Auf den ersten Blick erscheint es daher notwendig, die Sozialen Netzwerke offener zu gestalten, um zum Beispiel einheitliche Freundeslisten und Nachrichtenfunktionen in mehreren Netzwerken zu ermöglichen. Der Austausch von Daten zwischen den Anwendungen verschiedener Dienstleister ist jedoch aus Sicht der Privatsphäre sehr problematisch, da Informationen unerwünscht verbreitet werden können und sich kaum mehr nachträglich löschen lassen. Häufiger in die Kritik geraten ist in letzter Zeit das Soziale Netzwerk facebook, da es auch einfachen darin integrierten Anwendungen, wie beispielsweise einem Online-Quiz den Zugriff auf nahezu alle hinterlegten Daten ermöglicht. Wenn der Benutzer seinen Zugang in einer Webanwendung löscht, so bedeutet dies nicht zwangsläufig, dass der Anbieter danach sämtliche Spuren entfernt, die der Benutzer auf dessen Servern in den Datenbanken und Logdateien hinterlassen hat. Der digitale Fingerabdruck des Benutzers bleibt oft noch lange darüber hinaus bestehen und wird von Suchmaschinen und Webcrawlern9 im Internet weiter verbreitet

14 1. Einleitung 4

15 1. Einleitung Mehrfach-Login Soziale Netzwerke wie xing10, studivz11, lokalisten12 und facebook, Online-Photosharing Dienste wie picasa web13 oder flickr14, Online-Office Anwendungen wie Google Docs oder Zimbra Office15, für jedes dieser Programme ist meist ein separates Benutzerprofil notwendig und mit jeder Einladung durch einen Freund und mit jedem neuen Tool kommt auch ein neues hinzu. Die große Menge an Benutzerkonten und die Inkompatibilität der Webanwendungen zueinander bedeuten für den Benutzer einen hohen Pflegeaufwand. Um diesen zu minimieren, verwenden Anwender oft immer wieder dieselben Passwörter und Benutzernamen für den Login in viele verschiedene Webapplikationen. Wenn nur eine der Anwendungen eine Sicherheitslücke aufweist, über die ein Hacker Benutzername und Passwort erspähen kann, so besitzt er auch die Kontrolle über das Profil in allen anderen Anwendungen. Oft findet das Passwort auch bei Paypal16, Sofortüberweisung17 oder einer beliebigen anderen Bankanwendung Verwendung. Neben dem Risiko der unbefugten Einsicht privater Daten begibt sich der Nutzer also auch in ein finanzielles Risiko, wenn er einheitliche Zugangsdaten verwendet. Daten nicht offline verfügbar Ohne eine aufgebaute Verbindung zum Internet sind die meisten Webanwendungen nicht nutzbar. Nur einige wenige Betreiber bieten für ihre Software eine spezielle Variante an, bei der sich ein Teil der Funktionen auch offline nutzen lässt. Verringerte Geschwindigkeit Durch die vielen Client-Server Verbindungen und die, verglichen mit dem Zugriff auf eine lokalen Festplatte deutlich geringeren Datentransferraten, fühlen sich Webanwendungen bei der Bedienung oft deutlich träger an, als ihre Desktop Pendants [4]. Obwohl es mit AJAX Technologie möglich ist, den Datentransfer auf einen sich ändernden Teilbereich in einer Webanwendung zu beschränken, wird in den meisten Fällen die gesamte Seite mit allen statischen Elementen neu generiert, bevor diese an den Browser zurückgegeben wird [4]. Die dadurch entstehenden langen Ladezeiten und Unterbrechungen bei der grafischen Ausgabe erschweren eine intuitive und effiziente Bedienung der Anwendung. Keine anwendungsübergreifende Datenkonsistenz Die Pflege und Aktualisierung relevanter Daten wird vernachlässigt, wenn der Benutzer dazu gezwungen ist, diese regelmäßig auf verschiedenen Webseiten manuell hinsichtlich ihrer Korrektheit zu überprüfen. Am Beispiel der Universität Augsburg wird dieses Dilemma deutlich. Augsburger Studenten und Dozenten nutzen während

16 1. Einleitung Ihres Studiums neben der zentralen Webseite der Uni-Augsburg vor allem die folgenden Webanwendungen um sich zu informieren und alltägliche studienbegleitende Aufgaben durchzuführen: FlexNow! für die Notenverwaltung und Prüfungsanmeldung Stud.IP18 für die Kursverwaltung LectureReg für Übungen und Kursanmeldungen eee-portfolio19 als Begleitstudiumsplattform AVMD für Vorlesungsmitschnitte den Megastore20 für den Tausch großer Dateien OPAC21 für die Fernleihe Romeo22 für die Reservierung von Räumen LimeSurvey23 für Umfragen QIS24 für Studienbescheinigungen und Anträge Neben den genannten Webanwendungen nutzen die Studenten und Dozenten je nach Studiengang und Fachrichtung diverse weitere Webapplikationen. Allein die Anzahl der Webanwendungen macht jedoch deutlich, dass es für die Studenten und Dozenten schwierig geworden ist, den Überblick über alle Anwendungen, deren Funktionen und die jeweils darin gespeicherten Daten zu behalten. Die meisten der oben genannten Systeme verfügen über eine eigene Benutzerverwaltung, ein individuelles Layout und unterschiedliche Authentifizierungsmechanismen. Wenn ein Dozent den Termin einer Übungsveranstaltung ändern möchte, so muss er die aktualisierten Daten im worstcase in den Systemen Stud.IP, LectureReg, Romeo sowie auf der Webseite der UniAugsburg eintragen. Sind die Daten in den einzelnen Systemen nicht konsistent zueinander, erhält der Student widersprüchliche Informationen anstelle verlässlicher Angaben. Noch schwieriger gestaltet es sich, wenn ein Benutzer sein Benutzerprofil ändern muss, weil sich beispielsweise sein Nachname geändert hat. Dies muss in sämtlichen Systemen separat durchgeführt werden

17 1. Einleitung 1.3 Digicampus als Praxisbeispiel für den Entwicklungsprozess eines Lehr-/Lernportals Um die Zahl der Webanwendungen und den damit verbundenen Pflege- und Wartungsaufwand für Mitarbeiter und Studenten gering zu halten, wurde am Medienlabor der Universität Augsburg im Jahr 2006 das Projekt Digicampus25 ins Leben gerufen. Der Digicampus vereint an der Universität Augsburg zahlreiche Anwendungen zur Unterstützung von Lehr/Lernaufgaben unter einer einheitlichen Benutzeroberfläche (Abb.1). Die zentrale Lehr/Lern-Plattform befindet sich seit dem Wintersemester 2006/2007 im Einsatz. Im Wintersemester 2009/2010 wurde der Digicampus von knapp Studenten, Dozenten und Mitarbeitern für insgesamt 1522 Veranstaltungen genutzt. Durch die rasante Ausdehnung der Plattform von einer auf sieben Fakultäten und diverse weitere Einrichtungen innerhalb eines Zeitraums von nur drei Jahren erweisen sich der Wartungsaufwand, das Einspielen von Updates und deren Integration als zunehmend zeitaufwändig und unflexibel. Zudem ist es schwierig neue Entwickler in das bestehende mit der Zeit gewachsene System einzuarbeiten. Im Rahmen zweier Masterarbeiten wird daher eine neue Plattform für den Digicampus entwickelt. Während sich die Masterarbeit von Bernhard Strehl mit einer neuen GUI befasst [SB10], beschäftigt sich diese Arbeit mit der Schaffung eines technisches Grundgerüsts, dass die zuvor genannten Nachteile webbasierter Applikationen minimieren soll und dabei im besonderen auch Merkmale und Anforderungen der heterogenen universitären Infrastruktur Rücksicht nimmt. Informations-Plattform Kurs-Anmeldung Learning-Management Begleitstudiums-Plattform Vorlesungsmitschnitte Abb. 1: Der Digicampus und seine Funktionen 1.4 Gliederung der Arbeit Im Anschluss an die Einleitung werden einige wesentliche technische Grundlagen erläutert, deren Wissen im weiteren Verlauf der Arbeit vorausgesetzt wird. Im darauf folgenden Kapitel werden die technischen Anforderungen definiert, die ein webbasiertes Portalsystem an einer Universität idealerweise erfüllen muss, um eine

18 1. Einleitung einfache Erweiterbarkeit des Systems, eine intuitive Benutzerführung, sowie den Schutz sensibler Benutzerdaten zu gewährleisten. Im vierten Kapitel verwandte Arbeiten werden verschiedene Ansätze vorgestellt, die zumindest Teile der zuvor gestellten Anforderungen für eine Lehr/Lernverwaltung erfüllen oder Lösungsansätze bereitstellen. Es werden bereits bestehende Systeme analysiert und Möglichkeiten zur Integration und Erweiterung einer bereits vorhandenen IT-Infrastruktur hin zu einem einheitlichen Portalsystem gezeigt. Die Analyse der vorgestellten Arbeiten und die daraus resultierenden Ergebnisse werden im anschließenden fünften Kapitel bei der Wahl einer für den Digicampus geeigneten Entwicklungsstrategie berücksichtigt. Dabei wird insbesondere auch auf die gesammelten Erfahrungen beim Betrieb des Digicampus zurückgegriffen. Im sechsten Kapitel wird das Konzept für ein Framework vorgestellt, mit dem sich der Digicampus unter Berücksichtigung der speziellen Bedürfnisse einer Universität und bereits vorhandener Hard- und Softwareinfrastruktur erweitern und verbessern lässt. Das Konzept dient als Grundlage für das im Framework26 emigrant, das zukünftig die Lehr/Lernplattform Digicampus bilden soll. Framework zugrunde liegende Architektur verwendete technische Konzepte erläutert. Rahmen dieser Masterarbeit erstellte technische Basis für die zentrale Im sechsten Kapitel wird die dem beschrieben und wesentliche darin Das Kapitel Implementierung geht auf den Entwicklungsprozess des Frameworks ein, zeigt die dabei entstandenen Probleme und beschreibt, wie diese gelöst oder umgangen wurden. Neben der programmiertechnischen Umsetzung wird auch auf die Wahl der Programmiersprache, auf die im Verlaufe der Implementierung aufgetretenen Herausforderungen sowie auf die Benutzeroberfläche zur Konfiguration des emigrant-frameworks eingegangen. Die Funktionalität des im Rahmen dieser Arbeit entwickelten emigrant-frameworks wird im neunten Kapitel exemplarisch an einem Praxisbeispiel gezeigt, bei dem mehrere bereits bestehende Anwendungen in ein einheitliches Layout zusammengeführt werden. Das Szenario beschreibt insbesondere die Aufgaben, Konfiguration und Weiterentwicklung aus der Sicht eines Entwicklers und zeigt die Arbeitsschritte und die Vorteile, die das emigrant-framework den Entwicklern dabei bietet. Anschließend werden die im Rahmen dieser Masterarbeit gewonnen Erkenntnisse im Kapitel Lessons Learned zusammengefasst und ein Ausblick auf die weitere Entwicklung des Digicampus gewährt. Anhand einiger Beispiele wird der weitere Ausbau und die zukünftige Erweiterung des Digicampus um neue Funktionalitäten im Zusammenspiel mit dem Framework emigrant gezeigt. Den Schluss dieser Arbeit bildet ein Ausblick in die Zukunft und eine Prognose, wie Internet-Technologien und Anwendungen die Arbeit mit dem Computer revolutionieren können und welche Rolle Plattformen, wie der Digicampus dabei spielen werden

19 1. Einleitung 9

20 2. Technische Grundlagen 2 Technische Grundlagen Nachfolgend sollen dem Leser zum besseren Verständnis einige wichtige Grundlagen erläutert werden, auf die im Verlauf der Arbeit öfter zurückgegriffen wird. 2.1 Grundbegriffe Uniform Ressource Locator - URL Umgangssprachlich wird eine URL auch als Internetadresse bezeichnet. Die URL wird für den Aufruf einer Webseite in die Adresszeile eines Webbrowsers angegeben und beinhaltet immer einen Host- oder Domainamen (z.b. in der Regel auch einen URL-Pfad (z.b. /ordner/unterordner/seite.html) und gelegentlich noch einen Query-String (z.b.?abschnitt=kontakt), mit dem beim Seitenaufruf zusätzliche Parameter an den Server übergeben werden [5]. Innerhalb einer Webseite ist eine Angabe des Hostnamen nicht notwendig. Es genügt, die URL relativ zu dem Verzeichnis anzugeben, in dem sich die aktuell aufgerufene Seite befindet. Durch relative URLs ist es möglich, ein und dieselbe Webseite für unterschiedliche Domainnamen zu verwenden. Wenn in einer Webseite unter der Domain ein Link auf gesetzt wird, so kann für den Link auch der relative Pfad../seite2.html angegeben werden. Die relative Pfadangabe bleibt auch dann gültig, wenn anstelle der Domain domainname.de eine andere verwendet wird, da diese nicht im Pfad mit angegeben wurde. Weitere Beispiele für relative Pfadangaben sind Abb.2 zu entnehmen. Abb. 2: einige Beispiele für relative URL-Angaben Der Aufbau absoluter und relativer URLs spielt für das im Rahmen dieser Arbeit entwickelte emigrant-framework eine besondere Rolle, da darin verschiedene URLAngaben automatisch erkannt und umgeschrieben werden müssen. (siehe. Kap.8.1.1) 10

21 2. Technische Grundlagen Cookie Cookies sind kleine Textdateien, die im Browser des Benutzers hinterlegt werden und die durch eine Webanwendung ausgelesen, beschrieben oder modifiziert werden können [6]. In der Regel werden in Cookies Sitzungsinformationen für angemeldete Benutzer hinterlegt, damit der Benutzer bei erneuten Aufruf der Seite eingeloggt bleibt. Darüber hinaus dienen die Cookies der Benutzer-Identifizierung, um festzustellen, ob ein Besucher die Seite vorab schon einmal besucht hat. Cookies werden im in dieser Arbeit beschriebenen emigrant-framework u.a. verwendet, um Benutzersitzungen über mehrere Anwendungen hinweg zu synchronisieren. Widgets und Mashups Wenn in dieser Arbeit von Widgets gesprochen wird, sind damit ausschließlich Web Widgets gemeint. Web Widgets sind kleine Webseitenfragmente, die in eine andere Webseite eingebunden werden können und in einer separaten Sandbox ablaufen, d.h. sämtliche Funktionen des Widgets wirken sich auch nur auf die im Widget hinterlegten Daten und die Benutzeroberfläche des Widgets aus [MP09]. Im Wesentlichen werden Widgets verwendet, um die Besucher einer Seite mit relevanten Zusatzinformationen zu versorgen. Das können beispielsweise über Twitter eingebundene Benutzerkommentare sein, die Bezug zum Inhalt der Seite nehmen oder der RSS-Feed eines themenverwandten Weblogs [NT09]. Sowohl für den Aufbau von Widgets wie auch für die Technik zur Einbettung derselben in eine Webseite hat sich bislang kein Standard durchsetzen können, daher werden Widgets bisher überwiegend in proprietären Umgebungen wie beispielsweise igoogle27 oder Netvibes28 verwendet [MP09]. Während Widgets in einer in sich abgeschlossenen Sandbox laufen, geht das Konzept eines Mashups einen Schritt weiter und erlaubt auch eine Kommunikation zwischen verschiedenen Widgets untereinander. Einige Mashupkonzepte werden im Kapitel verwandte Arbeiten vorgestellt. Die beiden Konzepte sind für ein Lernportal interessant, da mit dieser Technik ein bestehendes Portal um neue Funktionen und Anwendungen erweitert werden kann. 2.2 Browser-Kommunikation Nachfolgend werden einige wesentliche Techniken zur Kommunikation zwischen Webbrowser und Webserver erläutert. Abb.3 gibt anhand eines einfachen Beispiels einen kurzen Überblick über die in diesem Abschnitt beschriebenen Begriffe. Auf die hier beschriebenen Techniken wird bei der Implementierung des emigrantclients zurückgegriffen (Kap.8.1)

22 2. Technische Grundlagen Request-Methode POST HTTP-Aufruf Content-Type HTTP-Header Abb. 3: Client-Server-Kommunikation beim Absenden eines einfachen Web-Formulars HTTP-Aufruf In dieser Arbeit wird der Begriff HTTP-Aufruf verwendet. Der HTTP-Aufruf bezeichnet sämtliche Client-/Server-Kommunikation, die beim Aufruf einer Webseite zwischen dem lokalen Webbrowser und einem Webserver stattfindet. Jedem Aufruf einer Webseite im Browser folgt zunächst ein HTTP-Anfrage (Request) mit der URL, um dem Webserver mitzuteilen, welche Webseite dieser zurückgeben soll [7]. Der Webserver antwortet daraufhin mit einer HTTP-Antwort (Response), in der die angefragten Daten enthalten sind [7]. Diese beiden Vorgänge stellen zusammengefasst einen HTTP-Aufruf dar. Jede übertragene HTTP-Message (Nachricht) beinhaltet HTTP-Header und Message-Body. einen HTTP-Header Die HTTP-Header teilen dem Webserver oder dem Browser zusätzliche Informationen über den Inhalt der im Body übertragenen Daten mit. Darüber hinaus beinhalten die HTTP-Header Anweisungen, die bestimmte Funktionen im Browser oder auf dem Webserver auslösen [8]. So lassen sich über Header-Angaben Cookies im Browser des Benutzer speichern oder Weiterleitungen durchführen. Umgekehrt kann der Browser über einen HTTP-Header erzwingen, dass der Webserver überprüft, ob sich eine Datei innerhalb eines vorgegebenen Zeitraums geändert hat und somit darüber entscheiden, ob eine Datei aus dem lokalen Cache des Browsers angezeigt oder die Datei neu übertragen werden soll. 12

23 2. Technische Grundlagen HTTP-Request Methode Die HTTP-Request Methode wird über einen HTTP-Header übergeben und spezifiziert, wie die Daten vom Browser an den Webserver übermittelt werden. Die beiden gebräuchlichsten Request-Methoden sind HTTP-GET (oder nur GET) und HTTPPOST (oder nur POST). HTTP-GET überträgt in einem Formular eingegebene Daten sichtbar über die URL-Zeile, indem diese in Form eines Query Strings an den URLPfad angehängt werden [9]. POST übermittelt die Daten für den Benutzer unsichtbar im Hintergrund [9]. Größere Datenmengen können ausschließlich via HTTP-POST übertragen werden, da die Länge der über die URL-Zeile übermittelbaren Daten beschränkt ist [9]. Content-Type Im Internet gibt es eine Vielzahl von Medientypen. Neben normalen Webseiten, die als Text übertragen werden finden sich auch zahlreiche Bilder, Videos, Flash-Inhalte oder Dokumente in Form von PDF- oder Word-Dateien. Mit einer HTTP-Anfrage wird daher neben der zu übertragenden Datei zusätzlich ein sogenannter Content-Type als HTTP-Header zurückgegeben, anhand der der Webbrowser ermitteln kann, um was für eine Datei es sich handelt, und wie diese verarbeitet werden muss. Die IETF (Internet Engineering Task Force) spezifiziert insgesamt 9 verschiedene Medientypen, die ihrerseits in Subtypen untergliedert sind [10]. Einige wichtige Beispiele sind: image/jpeg, image/png, image/gif für Bilddateien application/x-shockwave-flash für Flash-Inhalte video/x-flv für in Webseiten eingebettete Videos application/pdf für PDF-Dokumente Charset Encoding Als Text übertragene Daten, wie Webseiten, XML, Javascript oder Stylesheet-Dateien besitzen verschiedene Zeichensätze. Verbreitet sind im Web-Bereich vor allem die Zeichensätze ISO und UTF-8 [11]. Während ISO nur die Angabe europäischer Schriftzeichen erlaubt, umfasst UTF-8 auch eine Reihe von Sonderzeichen und Alphabete anderer Sprachen, erhöht aber auch die Dateigröße [11]. Die Zeichensätze sind nicht zueinander kompatibel. Wird ein übertragenes Dokument mit dem falschen Zeichensatz interpretiert, werden Umlaute und Sonderzeichen falsch dargestellt. 13

24 2. Technische Grundlagen 2.3 Webtechnologien Web-Proxy Ein Proxyserver schaltet sich als Vermittler in die Kommunikation zwischen dem Webbrowser des Benutzers und einem Server ein. Je nachdem, ob der Proxy die Kommunikation lediglich in Client-Server-Richtung oder auch in die Gegenrichtung steuert, spricht man nur von einem Proxy oder einem sogenannten Reverse-Proxy. Der Proxy kann dabei mehrere Funktionen ausüben: Inhalte filtern Aufruf anonymisieren Leistung optimieren Inhalte filtern Alle an den Benutzer übertragenen Daten müssen zuvor den Proxy passieren. Dabei kann der Inhalt analysiert werden, und anhand bestimmter Merkmale oder mittels Filterregeln der Inhalt verändert oder zensiert werden. Ein solches Verfahren wird u.a. bei chinesischen Zugangsprovidern angewendet, um für die Regierung unerwünschte Inhalte von der Bevölkerung fernzuhalten [12]. Aufrufe anonymisieren Mit jedem Aufruf einer Webseite lässt sich auf dem Webserver einwandfrei feststellen, von welchem Client dieser initiiert wurde. Wenn der Aufruf jedoch über einen ProxyServer erfolgt, so fungiert der Proxy-Server als Client und der wahre Client ist nur auffindbar, wenn der Anbieter des Proxy-Servers Informationen über den Zugriff ebenfalls preisgibt [13]. Aus diesem Grund finden Proxy-Server auch in Anonymisierungsdiensten Anwendung. Leistung optimieren Ein Proxyserver kann darüber hinaus die Ladezeiten einer Webseite verbessern, indem er die aufgerufenen Daten bei sich lokal speichert [14]. Darüber hinaus können die übermittelten Daten zusätzlich komprimiert werden, bevor diese an den Client zurückgegeben werden und damit eine weitere Leistungssteigerung erreicht werden. CMS Unter Content-Management wird laut Rothfuss/Ried die systematische und strukturierte Beschaffung, Aufbereitung, Verwaltung, Präsentation, Verarbeitung, Publikation und Wiederverwendung von Inhalten [RR02, S.15] bezeichnet. Bei einem ContentManagement-System handelt es sich hingegen um ein fertiges Stück Software, das die abstrakte Content Management-Aufgabe in einer ganz bestimmten Weise mit programmtechnischen Mitteln zu lösen hilft [RR02, S.16]. 14

25 2. Technische Grundlagen Die abstrakte Content Management-Aufgabe kann je nach Einsatzbereich sehr unterschiedlich ausfallen. Besonders verbreitet sind Content-Management-Systeme zur Verwaltung und Publikation von Inhalten in Webseiten, die auch als WebContent-Management-Systeme (WCMS) bezeichnet werden. Die meisten WCMS verfügen über eine Benutzer-/Rechteverwaltung, über die vorgegeben werden kann, welcher Benutzer welche Änderungen auf der Webseite vornehmen darf [15]. Einfache Aufgaben, wie das Schreiben neuer Texte, oder das Verwalten von Navigationsstrukturen lassen sich über ein CMS meist ohne Programmierkenntnisse durchführen [15]. Die meisten WCMS sind selbst Webanwendungen und lassen sich daher vollständig über den Browser administrieren. Soziales Netzwerk Gemäß der Definition von Boyd/Ellison versteht man unter einem sozialen Netzwerk eine Webseite, die folgenden Funktionen erfüllt: Erstellung eines öffentlichen oder teilöffentlichen Benutzerprofils innerhalb des Systems Bereitstellung einer Liste von Benutzern, zu denen eine Verbindung besteht (z.b. Freundschaft, Geschäftspartner, Mitschüler, Kommilitone) die Möglichkeit, die Benutzerlisten und Beziehungen anderer Benutzer einzusehen [BE07 sinngemäß übersetzt] Je nach Einsatzzweck eines sozialen Netzwerkes kann dieses der Kommunikation von Freunden, Bekannten oder Geschäftspartnern untereinander, zum Kennenlernen neuer Leute, zur Organisation von Gruppentreffen oder reinen Unterhaltungszwecken dienen. LMS und LCMS Das Learning Content Management System (LCMS) ist ein CMS, dass speziell für den Einsatz in Lehr-/Lerneinrichtungen wie Universitäten und Schulen konzipiert wurde. Das Learning Management System (LMS) erfüllt eine ähnliche Aufgabe wie das LCMS, legt dabei aber den Fokus auf die Verwaltung von Lehrveranstaltungen sowie deren Ablauf und Administration [18], während das LCMS vor allem die Verwaltung von Lehr-/Lerninhalten unterstützt. Da beide Systeme themenverwandt sind, gibt es diese scharfe Abgrenzung oft nicht, LCMS enthalten auch wesentliche Bestandteile eines LMS und umgekehrt [16]. Aus diesem Grunde wird meist nur von einem LMS gesprochen. Andere Begriffe für LMS sind Lernplattform oder Lehr-/Lernplattform. Die wesentlichen Aufgaben eines LMS sind [GS07]: Verbesserte Kommunikation von Veranstaltungsteilnehmern untereinander Verwaltung von Veranstaltungen, Terminen, Noten, Arbeiten, Übungen etc. Aufbereitung, Verwaltung und Publikation von Lerninhalten 15

26 2. Technische Grundlagen Rechte- und Zugriffskontrolle, Steuerung des Informationsfluss Bündelung der Lehr-/Lernaktivitäten auf einer Plattform Lernportal In dieser Arbeit wird anstelle von LMS oder LCMS der Begriff Lernportal verwendet, da ein LMS oder LCMS immer ein singuläres in sich abgeschlossenes System bezeichnet. Eine Lehr-/Lernumgebung kann sich jedoch aus mehreren Anwendungen zusammensetzen. Ein Webportal ist eine Internetseite, in der verschiedene Webanwendungen oder Informationen aus verschiedenen Datenbanken in einem einheitlichen Layout dargestellt werden [17]. Somit stellt auch das Lernportal eine übergeordnete Einheit dar, die zwar im Wesentlichen aus einem LMS besteht und dessen Funktionsweise abbildet, darüber hinaus aber auch noch Werkzeuge und Funktionen anderer Anwendungen beinhalten kann. Das Zusammenspiel zwischen LMS, LCMS und Lernportal ist in Abb.4 dargestellt. Abb. 4: Komponenten, Funktionen und Benutzer eines Lernportals basierend auf Abbildung aus Quelle: 16

27 2. Technische Grundlagen 17

28 3. technische Anforderungen an ein Lernportal 3 technische Anforderungen an ein Lernportal Nachfolgend werden wesentliche technische Anforderungen spezifiziert, die ein Framework für eine universitätsweites Portalsystem erfüllen sollte. Die Anforderungen basieren auf den in der Einleitung dargelegten Problemen, die während des Digicampus-Betriebs und der Weiterentwicklung von 2006 bis 2009 gesammelt wurden. Auf die funktionalen Anforderungen einer Lehr-/Lernsoftware wird an dieser Stelle nicht weiter eingegangen, da in dieser Arbeit nicht die Entwicklung eines Lernportals beschrieben werden soll, sondern die Konzeption eines Frameworks, mit der sich ein Lernportal weitgehend unabhängig von der geforderten Funktionalität umsetzen lässt. 3.1 Anforderungen aus Benutzersicht Die Anforderungen an ein Portal für die Begleitung der Lehre an einer Universität sind sehr vielfältig, da dieses von mehreren Benutzergruppen an verschiedenen Fakultäten eingesetzt wird, die teilweise unterschiedliche Ziele verfolgen. Die Gruppe der Nutzer umfasst Studenten, Lehrende und Dozenten, Mitarbeiter, Autoren sowie für Verwaltungsaufgaben zuständige Personen [18]. Auch die Administratoren können der Gruppe der Nutzer zugeordnet werden, wenngleich sie unter Umständen auch an der Entwicklung beteiligt sind. Alle Nutzer versprechen sich von dem Einsatz des Systems eine Arbeitserleichterung und besseres Informationsmanagement auch über mehrere Fakultäten hinweg sowie evtl. verbesserte Zusammenarbeit im Team [18]. Die Anforderungen an ein Lernportal lässt sich zu wesentlichen Teilen aus dem Anforderungskatalog allgemeiner Webportale ableiten Benutzer-Verwaltung Rollen- und Rechtemanagement Einige Benutzer üben in dem System mehrere Rollen gleichzeitig aus. Beispielsweise kann ein Student auch Lehrender in einem Seminar oder Tutorium sein, benötigt also auch in der Lehr-/Lernverwaltung den Zugriff auf für Studenten und Dozenten relevante Funktionen. Der Benutzer muss entweder einfach zwischen Studenten- und Dozentenfunktionen hin- und herwechseln können oder die Funktionen beider Benutzer-Rollen in einer gemeinsamen Benutzeroberfläche vorfinden. Somit ist die Zugehörigkeit eines Benutzers zu mehreren Rollen oder Rechtegruppen und eine effiziente Verwaltung der Zuordnungen eine zentrale Anforderung für eine einheitliche Lehr-/Lernplattform [19,KM04]. Einheitliche Benutzerkennungen An den Universitäten hat sich das System einer einheitlichen zentralen, oft über mehrere Universitäten hinweg gültigen, computergestützten Benutzerkennung etabliert. Um einem Studenten möglichst in einem Vorgang den Zugriff auf sämtliche für ihn relevanten IT-Systeme an der Universität zu gewähren, und diesen Zugriff auch 18

29 3. technische Anforderungen an ein Lernportal nach der Exmatrikulation wieder zu entziehen, ist es sinnvoll auch eine Lehr-/Lernverwaltung an das System der universitären Benutzerverwaltung zu koppeln. Insbesondere wenn die Lehr-/Lernverwaltung aus mehreren unterschiedlichen Teilanwendungen besteht, erleichtert dies die Zuordnung bestimmter Systembenutzer zur realen Person, die sich hinter dem Benutzer versteckt. Das bedeutet wiederum, dass die in Webanwendungen üblicherweise verwendete Registrierung durch den Benutzer selbst nicht erwünscht ist, und die Registrierung, falls notwendig, automatisch und implizit im Hintergrund durchgeführt werden muss, beispielsweise, wenn sich der Student das erste Mal einloggt [KM04]. Single Sign-on Der Benutzer sollte sich unabhängig von den in der Lehr-/Lernverwaltung verwendeten Systemen nur einmal einloggen müssen und erst nach längerer Inaktivität oder nach dem Schließen des Browserfensters wieder ausgeloggt werden. Auch für den Login-Prozess ist die Verwendung einer zentralen universitären Benutzerkennung von Vorteil, da sich der Benutzer somit nur noch einen Benutzername und ein Passwort merken muss [KM04]. Zudem kann eine Sperrung des Benutzers durch Sperrung der Nutzerkennung an zentraler Stelle erfolgen und blockiert auch den Zugriff auf die Lehr-/Lernverwaltung. So ist gewährleistet, dass unbefugte Benutzer keinen Zugriff auf das Portal haben. Zudem ermöglichen es einige Single Sign-on Systeme wie Webauth, dass ein Logging von Benutzerzugriffen, wie es bisher durch die Vorratsdatenspeicherung vorgeschrieben war29, auf einem zentralen Server erfolgen kann. Der Single Sign-on kommt auch der Sicherheit zugute, da das Passwort oder dessen HashWert nur zentral auf einem einzigen Authentifizierungserver gespeichert werden muss [20] Intuitive Benutzeroberfläche Für alle Benutzer ist eine einfache, effiziente und verständliche Benutzeroberfläche zentraler und wesentlicher Bestandteil der Lehr/Lernverwaltung [18]. Häufig genutzte Funktionen muss der Benutzer mit möglichst geringen Aufwand erreichen können, damit das Webportal eine effizientere Arbeitsweise gegenüber althergebrachten Methoden zur Informationsgewinnung und Verbreitung ermöglicht. Beispiele für häufig verwendete Funktionen auf Portalseiten sind die Suche, eine Profilverwaltung sowie ein Login/Logout-Button. Diese Elemente sollten daher möglichst immer sichtbar und möglichst einfach in Ihrer Bedienung sein. Die Benutzeroberfläche sollte darüber hinaus barrierefrei, also behindertengerecht gestaltet sein [BP07]. Personalisierung Durch die vielen unterschiedlichen Rollen im System und die verschiedenen Nutzungsweisen ist es zudem erforderlich, dass die Benutzeroberfläche je nach Nutzerrolle, belegten Vorlesungen und Studienfortschritt soweit individualisierbar ist, dass die jeweils unterschiedliche Relevanz verschiedener Funktionen in der Darstellung berücksichtigt wird. Während bei einem Studenten der schnelle Zugriff auf 29 BVG Urteil vom

30 3. technische Anforderungen an ein Lernportal belegte Vorlesungen, demnächst abzugebende Übungen und ausstehende Anmeldungen im Vordergrund steht, benötigt der Dozent eher einen Überblick über seine Veranstaltungsteilnehmer, bereits eingereichte oder noch fehlende Übungsaufgaben oder die Möglichkeit, zügig Termin- oder Raumänderungen an die Teilnehmer zu kommunizieren. Ein Student im ersten Semester benötigt hingegen unter Umständen andere Informationen, als ein Student im höheren Semester, für den z.b. etwaige Einführungsveranstaltungen nicht von Interesse sind. Bewährt hat sich u.a. das Konzept einer nach dem Benutzerlogin individuell generierten und anpassbaren Übersichtsseite [20], in der nach Relevanz und Aktualität gruppierte Info-Boxen angezeigt werden, die für den Benutzer wesentliche Informationen kurz zusammenfassen, für die er sonst durch weitere Unterseiten navigieren müsste. Konsistente Benutzerführung Zu einer effizienten Benutzeroberfläche zählt auch, dass das Bedienkonzept möglichst einheitlich bleibt, auch wenn in dem Portal unterschiedliche Systeme zum Einsatz kommen, damit der Benutzer auf bereits erlernte Bedienabläufe zurückgreifen kann. Eine konsistente Benutzerführung erleichtert das Erlernen neuer Funktionen, erhöht die Nutzerakzeptanz und verringert die Fehlerquote bei evtl. Eingaben [SJ00]. Kommen unterschiedliche Systeme zum Einsatz, ist es daher notwendig, Layout, Bedienelemente und Farbgestaltung einander anzugleichen und ein einheitliches Corporate Design zu schaffen [KM04]. Hoher Informationsgehalt Die Effizienz der Benutzeroberfläche definiert sich jedoch nicht nur über das Aussehen der GUI und der Positionierung wesentlicher Bedienelemente. Vielmehr spielt vor allem der Informationsgehalt der dargestellten Texte eine wesentliche Rolle und wie diese strukturiert, dargestellt und dem Nutzer zugänglich gemacht werden. Konkret bedeutet dies zum Beispiel, dass ein Student in seinem Online-Wochenplaner nicht nur die Veranstaltungstermine belegter Vorlesungen angezeigt bekommen möchte, sondern auch den genauen Veranstaltungsort, eventuelle Raumverlegungen, Gruppentreffen, Abgabetermine, Anmeldezeiträume oder demnächst stattfindende Events. Ein hoher Informationsgehalt ist nicht gewährleistet, wenn der Student in unterschiedlichen Systemen verschiedene Kalender aufrufen muss, um einen Überblick darüber zu erhalten, welche Termine für ihn in den folgenden Tagen relevant sind. Wenn mehrere Systeme zum Einsatz kommen, ist es daher notwendig, eine semantische Verknüpfung zwischen den Systemen zu schaffen und zueinander gehörige Informationen aus verschiedenen Systemen gebündelt auf einer Seite darzustellen [20]. Keine redundanten Funktionen Einem Prozess oder einer Aufgabe im Portal-System muss immer ein fester Workflow zugeordnet sein, der sich dem Benutzer schnell erschließt. Wenn es zwei ähnliche, zusammenhängende oder weiterführende Prozesse gibt, so sollten diese auch von dem jeweils anderen Prozess aus ansteuerbar sein oder zu einem einheitlichen Prozess zusammengeführt werden, indem dessen Funktionen in einen übergreifenden Prozess migriert werden [NP09]. Wenn in einem Portal mehrere Systeme zum Einsatz 20

31 3. technische Anforderungen an ein Lernportal kommen, kann zum Beispiel der Prozess Benutzer-Benachrichtigung auf verschiedene Art und Weise in jedem dieser Systeme durchgeführt werden. Für den Benutzer bedeutet dies, dass er sich durch alle verwendeten Systeme durchklicken muss, um festzustellen, ob er eine für ihn relevante Nachricht erhalten hat. Wesentliche Kernfunktionen, wie die Benutzerverwaltung, die Benutzer-Benachrichtigung oder anstehende Termine dürfen daher nur an einer zentralen Stelle zugreifbar sein Benachrichtigung Die Benachrichtigungsfunktionen spielen auch in anderem Kontext eine bedeutende Rolle, denn sie dienen dazu, den Benutzer auf wichtige Änderungen oder Termine hinzuweisen. Eine Benutzerbenachrichtigung kann je nach Vorliebe des Benutzers auch per , RSS oder Twitter erfolgen, damit der Benutzer nicht gezwungen ist, die Webseite einer Veranstaltung zu besuchen, um über eine Änderung Bescheid zu wissen. Eine zentrale Plattform zur Lehr-/Lernverwaltung muss also über einen zentralen und einheitlichen Mechanismus verfügen, um Benachrichtigungen an seine Benutzer zu versenden Datenschutz Ein Benutzer hat im Sinne der Datenschutzbestimmungen das Recht, jederzeit zu erfahren, wer die in der Lehr-/Lernverwaltung gespeicherten Daten sehen kann, und an welcher Stelle diese einsehbar sind. Des weiteren kann er, sofern er nicht explizit die Einwilligung für die Speicherung und Anzeige der Daten gibt, anordnen, dass bestimmte Daten gelöscht, versteckt oder gar nicht erst gespeichert werden [21]. Solange dies mit dem über das Portal abgewickelten Lehrbetrieb vereinbar ist, sollte daher der Benutzer die Möglichkeit haben, Benutzerinformationen soweit möglich zu verstecken, zu anonymisieren oder nur bestimmten Benutzern oder Benutzergruppen zugänglich zu machen. Insbesondere, wenn das System offene Schnittstellen bietet, die auch eine Kopplung der Lehr-/Lernverwaltung an andere Systeme außerhalb der Universität ermöglicht, oder wenn Studenten selbst die Möglichkeit haben, die Lehr-/Lernverwaltung um eigene Anwendungen zu erweitern, dürfen diese Drittsysteme keinen Zugriff auf sensible nicht für die Öffentlichkeit bestimmte Benutzerdaten erhalten. Guter Datenschutz beinhaltet auch Vorkehrungen um eine unerwünschte Manipulation von Daten innerhalb des Portals auszuschließen [SJ00]. 21

32 3. technische Anforderungen an ein Lernportal 3.2 Anforderungen aus Entwicklersicht Von besonderer Bedeutung für eine Portalsoftware für die Lehr-/Lernverwaltung ist auch die Entwicklersicht. Gerade im universitären Bereich gibt es häufige Umstrukturierungen durch stetig wechselndes Personal, neue Studiengänge oder verändertes Kursangebot, die möglichst zeitnah auf die IT-Landschaft abgebildet werden müssen Integrationsmöglichkeiten Integration neuer Funktionen Neue Funktionen, wie beispielsweise ein prioritätenbasiertes Anmeldeverfahren für eine bestimmte Veranstaltung müssen mit geringen finanziellen und personellen Aufwand realisierbar sein, da der Zeitraum zwischen der Bedarfsfeststellung bis zum geplanten Einsatz eines Features meist recht kurz ausfällt und die finanziellen Mittel einer Universität begrenzt sind. Um den Aufwand möglichst gering zu halten, muss der Programmierer daher auf bereits vorhandene Bibliotheken zurückgreifen können, die einen einfachen Zugriff auf Datenbankfunktionen und Elemente der Benutzeroberfläche ermöglichen. Wenn der Programmierer auf bereits erprobte Klassen zurückgreifen kann, verringert dies zudem die Fehleranfälligkeit und minimiert den Testaufwand. Integration neuer Anwendungen Werden Funktionalitäten gefordert, die sich innerhalb eines vorgegebenen Zeitraums mit den vorhandenen Ressourcen nicht in das Lehr/Lern-Portal integrieren lassen, lohnt sich eventuell der Einsatz eines bereits fertigen speziell auf den Einsatzzweck hin optimierten separaten Programms [KM04]. Die Schwierigkeit besteht für den Entwickler dann darin, das vorhandene Programm möglichst gut in die bestehende Infrastruktur zu integrieren. Für eine Lösung zum Betrachten und Kommentieren von Vorlesungsmitschnitten ist es beispielsweise erforderlich, die Vorlesungsmitschnitte auch an den entsprechenden Stellen in der Kursübersicht zu verlinken, und die Benutzer- und Zugriffsrechte der Kursverwaltung auch auf die Videomittschnitte zu übertragen. Eine Lehr-/Lernverwaltung muss somit die Möglichkeit bieten, separate Anwendungen möglichst effizient und transparent in das bestehende Portal zu integrieren [NP09]. Austauschbarkeit und Datenkonsistenz Wenn in der Portalsoftware Drittsysteme zum Einsatz kommen, kann es sein, dass diese zu einem späteren Zeitpunkt durch ein anderes System ersetzt werden müssen, das andere oder bessere Funktionalitäten aufweist. An der Universität Augsburg wurde eine E-Portfolio-Plattform für die digitale Unterstützung universitärer Begleitstudiumsprojekte konzipiert, entwickelt und praktisch eingesetzt [MJ09]. Die dabei entstandene Plattform ersetzt das bislang im Digicampus eingesetzte Portfolio-System elgg30. Die in elgg bereits vorhandenen Benutzer, Gruppen sowie deren Beziehungen

33 3. technische Anforderungen an ein Lernportal untereinander dürfen bei einer Integration der neuen Plattform Projektes in das Portal Digicampus nicht verloren gehen, sondern müssen mit übernommen werden. Da ein händisches Übertragen der Bestandsdaten sehr aufwendig ist, muss die Lehr-/Lernverwaltung entsprechende Werkzeuge zur Synchronisation und Migration dieser Daten bieten, indem Sie beispielsweise dem Benutzer die Möglichkeit zur Übernahme eines bereits bestehenden Accounts in das Gesamtsystem schafft [NP09]. Abändern der Benutzeroberfläche Bei der Einbindung zusätzlicher Anwendungen ist eine optische Integration in die bereits vorhandene Benutzeroberfläche wünschenswert. Dies bedeutet, dass der Entwickler die Möglichkeit benötigt, Formulare, Eingabeelemente und Teile des Layouts anders anzuordnen, als dies die ursprüngliche Anwendung vorsieht, ohne dabei deren Funktionalität zu verändern. Darüber hinaus soll es möglich sein, Elemente der grafischen Benutzerschnittstelle zu entfernen oder für den Benutzer unzugänglich zu machen, damit Funktionen wie die Profilverwaltung nur an einer zentralen Stelle im Portal zugänglich gemacht werden können Wartbarkeit Ein System ist wartbar, wenn man Fehler mit vernünftigen Aufwand lokal reparieren kann, ohne neue Fehler an anderen, unerwarteten Stellen zu verursachen [SJ00 S.94]. Die Wartbarkeit in einem Lernportal bleibt nur dann gewährleistet, wenn größere Veränderungen der Programmausgabe nicht direkt im Quellcode der eingebundenen Anwendungen gemacht werden, sofern diese nicht über eine saubere Trennung zwischen Darstellungsschicht und funktionellen Programmcode verfügt, da dies zukünftige Updates der Anwendung sehr aufwendig machen würde. Weil die veränderten Teile des Programms nach einem Update überschrieben werden, müsste der Programmierer nach jeder Aktualisierung erneut manuell den angepassten Quelltext in den neuen Programmcode übertragen. Die Lehr-/Lernverwaltung sollte daher idealerweise einen Mechanismus bereithalten, mit dem nur die optische Ausgabe einer Anwendung modifiziert werden kann, ohne dass die Anwendung selbst dabei umprogrammiert werden muss [KM04] Skalierbarkeit und Leistung Eine universitätsweit einheitliche Plattform für die Begleitung der Lehre muss eine hohe Anzahl gleichzeitiger Seitenbesucher bewältigen können, und zugleich eine hohe Verfügbarkeit aufweisen [SJ00]. Werden über das Portal Übungsanmeldungen nach dem First-Come-First-Served31 Prinzip abgewickelt, können durchaus mehrere tausend Besucher die Lehr-/Lernverwaltung in einer sehr kurzen Zeitspanne aufrufen. Die daraus resultierende Anfragelast übersteigt oft die Kapazitäten marktüblicher Webserver-Systeme. Aus diesem Grund ist es von Vorteil, wenn die Software von vornherein darauf ausgelegt ist, dass sie auf mehrere Server verteilt werden kann [20]. Dies reduziert zum einen die Hardwarekosten, zum anderen erhöht sich die Verfügbarkeit

34 3. technische Anforderungen an ein Lernportal durch Einsatz eines redundanten Zweitsystems. Darüber hinaus muss das Portal trotz der zu erwartenden Komplexität performant sein, um kurze Ladezeiten zu gewährleisten und eine flüssige und effiziente Bedienung zu ermöglichen [SJ00] Schnittstellen Schnittstellen für den Fernzugriff Die Lehr-/Lernverwaltung selbst muss Schnittstellen aufweisen, mit der sich bestimmte Daten auch von anderen Systemen aus auslesen lassen [18]. Insbesondere die Veranstaltungsdaten werden an zahlreichen anderen Stellen innerhalb einer Universität benötigt, wie dem zentralen Vorlesungsverzeichnis oder auf der Homepage. Die Vorlesungsdaten müssen auch Besuchern zugänglich gemacht werden, die nicht an der Universität immatrikuliert sind und somit auch keinen Zugriff auf die Portalsoftware haben [NP09]. Aus diesem Grund ist es notwendig, den Zugriff auf bestimmte Daten von außerhalb zu gewährleisten, ohne dass dieser an einen speziellen Benutzeraccount gebunden ist. Eingeschränkter Entwicklerzugriff Für Entwickler sollte es eine Art Sandbox im System geben, in der sie Erweiterungen entwickeln und testen können, ohne dass ein Zugriff auf die dem System zugrunde liegende Datenbank oder wichtige Systempasswörter notwendig ist. Dadurch kann die Plattform einer breiten Zahl von Entwicklern zugänglich gemacht werden, die zur Verbesserung der Lehr-/Lernverwaltung beitragen und den Entwicklungsprozess beschleunigen, ohne dabei die Sicherheit und Privatsphäre der darin eingetragenen Nutzer zu gefährden Herstellerunabhängigkeit Der der Plattform zugrunde liegende Quellcode sollte einer Open-Source Lizenz unterliegen, um die Abhängigkeit der Universität von Interessenvertretern oder Firmen zu minimieren [22]. Nur so kann langfristig eine effiziente Weiterentwicklung auch dann ermöglicht werden, wenn sich die die ursprünglichen Entwickler aus dem Projekt zurückziehen sollten. Open-Source Anwendungen ermöglichen es auch anderen Universitäten an dem Projekt teilzuhaben, die ihrerseits zu einer Weiterentwicklung und Verbesserung beitragen können. Da für Open-Source Anwendungen keine Lizenzgebühren anfallen, ist der Weiterbetrieb der Software auch dann möglich, wenn vorübergehend wenig finanzielle Mittel bereitstehen, da die Weiterentwicklung und Verbesserung auch von anderen Lizenznehmern getragen wird [22]. 24

35 3. technische Anforderungen an ein Lernportal 25

36 4. Verwandte Arbeiten 4 Verwandte Arbeiten Bei der Entwicklung einer Lehr-/Lernverwaltung stellt sich für die Entwickler zunächst die Frage, ob das Portal von Grund auf neu entwickelt oder bestehende Software eingesetzt werden soll. Die Neuentwicklung eines so umfassenden und komplexen Systems ist sehr aufwendig. Deutlich geringer ist der Implementierungsaufwand, wenn ein bestehendes System als Basis verwendet werden kann, und die gewünschten Zusatzfunktionen in Form neuer Module oder Add-ons eingebracht werden können. 4.1 Neuentwicklung eines Lehr-/Lernportals Da ein Learning-Management-System vom Grundaufbau her wesentliche Elemente eines Content-Management-Systems oder eines Community-Portals enthält, können Systeme wie Drupal oder Typo3 als eine Grundlage für eine Neuentwicklung in Frage kommen. Drupal eignet sich besonders gut für Community-Webseiten, in denen der Benutzer auch administrative Tätigkeiten gemäß der ihm zugeordneten Benutzerrolle ausübt, da der Administrationsbereich für die in Drupal bereitgestellten Module direkt im Frontend abrufbar ist und sich daher in das Layout der bestehenden Seite integriert. Typo3 verschiebt hingegen alle wesentlichen administrativen Aufgaben in einen eigens dafür vorgesehenen Backend-Bereich und eignet sich daher besonders gut für Webanwendungen, in denen es wenige Administratoren, aber viele Rezipienten gibt. Beide Systeme lassen sich modular erweitern und bieten einen vergleichbaren Funktionsumfang. Da Typo3 im deutschsprachigen Raum besonders verbreitet ist (vgl. Abb.5) und auch von vielen namhaften Unternehmen eingesetzt wird, soll nachfolgend ein auf Typo3 aufsetzendes Lehr-/Lernportal und dessen Entwicklung näher beschrieben werden. Abb. 5: Popularität der Suchbegriffe Typo3 und Drupal bei Google Quelle: 26

37 4. Verwandte Arbeiten CAMPUS T3 - eine E-Learning-Architektur auf Open Source-Basis [FB06] Der Autor Fabrizio Branca hat im Rahmen seiner Diplomarbeit 2006 ein LMS konzipiert, das das Open-Source Content Management System Typo3 als Grundlage verwendet. In der Arbeit werden zunächst die verschiedenen Ausprägungen von E-Learning Systemen dargelegt und Definition, Bedeutung und Funktionsweise einer Lernplattform erklärt. Ein wesentliches Merkmal der Lernplattformen sind die Lernobjekte und Lernmodelle, also die digitalen Abbildungen der an den Universitäten üblicherweise verwendeten Hierarchien aus Lehrstühlen, Studiengängen, Kursen, Seminaren, Übungen sowie den darin beteiligten Personen mit jeweils eigenen Zugriffsrechten. Während das Lernobjekt eine didaktisch abgeschlossene Einheit, wie beispielsweise eine einzelne Lehrveranstaltung repräsentiert, sind die Zugriffsrechte und Zugehörigkeiten zu einem Kurs und eines Kurses im System Universität in dem Lernmodell repräsentiert. Die Spezifikation eines Lernmodelles erfolgt über Metadaten innerhalb des Lernobjekts. Für die Spezifikation gibt es wiederum unterschiedliche Standards, die jeweils einen anderen Ansatz verfolgen. Der Autor orientiert sich dabei an der sogenannten Dublin-Core32 Spezifikation, da das Lernmodell einige Parallelen zu den in einem Content Management System wie Typo3 verwendeten Benutzer-, Rollen und Rechtehierarchien sowie dem darin verankerten Dokumenten Lifecycle aufweist. Der Autor verwendet das Rollensystem von Typo3 mit den Rollen Campusmanger, Studienorganisator, Autor, Dozent und Mitglied, und führt darüber hinaus die Lernobjekte Campus, Thema, Modul, Kurs, Baustein, Dokument und Datei ein. Jeder Benutzer erhält in dem System einen persönlichen Schreibtisch, in dem die für ihn relevanten Informationen zusammengefasst werden und von dem ausgehend er in alle Unterbereiche des LMS navigieren kann. Ein Benutzer kann mehrere Rollen ausüben. Für jede dieser Rollen gibt es eine zentrale Einstellungs- und Verwaltungsseite, über die beispielsweise Veranstaltungen, Termine und Dokumente gepflegt werden können. Im Rahmen einer Vorlesung wurde das System einem Praxistest unterzogen. [vgl. FB06 und 23] Der Autor hat sich offenbar relativ früh darauf festgelegt, Typo3 als Basissystem zu verwenden und lässt mögliche Alternativplattformen wie Drupal, Plone, Moodle oder Stud.IP außen vor. Er erläutert die verschiedenen E-Learning-Modelle, geht aber nicht darauf ein, ob und in welchem Maße diese in der CAMPUS T3-Extension eingesetzt werden. Der Funktionsumfang der vorgestellten CAMPUS T3-Extension eignet sich für kleinere oder zentral organisierte akademische Einrichtungen. Die komplexen Abläufe innerhalb einer Universität können mit dem System nicht abgebildet werden, da wesentliche Merkmale, wie verschiedene Anmeldemodalitäten, Prüfungsmanagement oder Videomitschnitte noch nicht integriert sind. Leider wird der Funktionsumfang von Typo3 nicht ausgeschöpft. So wurden die Verwaltungsfunktionen von CAMPUS T3 nicht in den Backend-Bereich von Typo3 integriert. Ein Benutzer muss also unter Umständen zwischen zwei unterschiedlichen Administrationsumgebungen hin- und herwechseln. Dennoch zeigt sich, dass Typo3 eine gute Basis für ein Lehr-/Lernportal bietet und durch seine offene Struktur und den modularen Aufbau leicht um neue Funktionen zu erweitern ist

38 4. Verwandte Arbeiten 4.2 Integration neuer Funktionen und Anwendungen Neben der Neuentwicklung eines Lehr-/Lernportals gibt es die Möglichkeit, verschiedene bereits bestehende Anwendungen aneinander zu koppeln und durch die Bündelung von Funktionalitäten der einzelnen Anwendung ein Portal zu erstellen, das den geforderten Funktionsumfang bietet, ohne die Nachteile einer langen und kostspieligen Eigenentwicklung mit sich zu bringen. Die Schwierigkeit besteht jedoch darin, die vom Aufbau und Funktion meist völlig unterschiedlichen Teilsysteme in einer gemeinsamen Benutzeroberfläche unterzubringen. Widgets und Mashups ermöglichen es, Aussehen und Position von Elementen und Funktionen von der jeweiligen Anwendung abzukoppeln und neu zu arrangieren. Nachfolgend sollen daher zwei technische Konzepte zur Generierung von Mashups vorgestellt werden Turning Web Applications into Mashup Components: Issues, Models, and Solutions [DF09] Die Arbeit von Florian Daniel und Maristella Matera an der Universität Trento beschäftigt sich mit der Erstellung von Mashups. Der Begriff Mashup bezeichnet eine Verknüpfung, steht also für die Schaffung neuer Inhalte durch die Rekombination von bereits bestehenden Inhalten. Übertragen auf Webanwendungen ist damit gemeint, dass eine Internetseite um Inhalt und Funktion einer anderen Webseite erweitert wird. Die Autoren nennt als Beispiel für ein Mashup die Internetseite housingmaps33, die Wohnungsanzeigen aus der Wohnungsbörse Craigslist34 mit der Anwendung Google-Maps35 kombiniert. Das Ergebnis ist eine Anwendung, in der sämtliche in Craigslist gelisteten Wohnungsanzeigen übersichtlich auf einer Karte dargestellt werden. Das Erstellen von Mashups ist im Beispiel der Google-Maps relativ einfach, da das Unternehmen Google dem Entwickler den Google Mashup Editor zur Verfügung stellt, mit dem dieser ohne weiterführende Programmierkenntnisse einfache Anwendungen erstellen kann, die Google-Programme wie Google-Maps nutzen. Auch andere Firmen, die an der Verwendung Ihrer Anwendungen in anderen Seiten ein kommerzielles Interesse haben unterstützen die Entwickler mit eigenen Mashup-Editoren. Zu nennen sind hierbei insbesondere Yahoo Pipes36, Intel Mash Maker37, IBM QEDWiki38 und das nicht mehr weiterentwickelte Microsoft PopFly. Es zeigt sich jedoch, dass fast alle verfügbaren Mashups mit Global Playern am Markt in Verbindung gebracht werden können, da sie durchwegs Tools, wie Google-Maps, Flickr oder Youtube verwenden. Darüber hinaus existieren kaum einheitliche Standards für die Generierung und Einbindung von Mashups. Für die Autoren war dies der Anlass ein eigenes Mashup-Konzept zu entwerfen, das in der Plattform mashart39 Anwendung findet. Besonderes Augenmerk legt das Konzept auf die Sicht des Entwicklers einer Webapplikation, der zunächst die Mashup-fähigen sogenannten UIKomponenten erstellen und freigeben muss. Die UI-Komponenten sind eine Art leicht

39 4. Verwandte Arbeiten gewichtige Widgets, die sich vom klassischen Widget dadurch abgrenzen, dass sie nicht alleine lauffähig sind. Im Gegensatz zu einem normalen Webservice via SOAP40 oder RSS41, der ebenfalls dem Austausch von Daten und Funktionen zwischen zwei unabhängigen Webseiten dient, ist es bei einem Mashup erforderlich, auch die Benutzeroberfläche mit zu übertragen. Für diesen Zweck definieren die Autoren ein plattform und implementierungsunabhängiges UI component model sowie eine dazugehörige Beschreibungssprache MDL (mashart Description Language). Um für die Mashups relevante Deskriptoren in die Webanwendung mit aufzunehmen, ohne umfangreiche Änderungen im Programm vorzunehmen, werden die betreffenden Teile mit dem Microcode MEA (mashart Event Annotation) gekennzeichnet, der sich direkt in HTML einbetten lässt. Darüber hinaus wird auch eine Schnittstelle bereitgestellt, mit der sich herkömmliche Webservices in das Mashup-Konzept integrieren lassen. Die Arbeit stellt einige grundlegende Design-Prinzipien auf, die ein Mashup-Konzept erfüllen muss. Es wird davon ausgegangen, dass der Mashup Composer, also die Person, die aus den verschiedenen Komponenten ein Mashup erstellt nicht über weiterführende Programmierkenntnisse verfügt. Aus diesem Grunde werden die UI-Komponenten und deren Schnittstellen möglichst abstrakt beschrieben, während die internen Details im Verborgenen bleiben. Der Entwickler muss neben der regulären Anwendung auch zusätzlich die UI-Komponenten für ein Mashup entwerfen und dementsprechend über tiefgreifende Expertise verfügen, damit die Komponente unabhängig von der Kernanwendung nutzbar bleibt und sich problemlos in den HTML-Container einer anderen Webseite einbetten lässt. Für die bei der Mashup-Generierung erforderlichen Tools kann auf proprietäre Software zurückgegriffen werden. Für die Mashups selbst müssen hingegen existierende und verbreitete Standardtechnologien verwendet werden, damit sie möglichst vielfältig eingesetzt werden können und keine Abhängigkeiten mit sich bringen. In diesem Fall wird das fertige Mashup als ein Javascript-Programm in die vorgesehene Webseite eingebunden. Das Javascript-Programm erhält die UI-Komponenten via Client-Server-Kommunikation von einem Execution-Framework. Im Anschluss übersetzt es die UI-Komponenten clientseitig in HTML-Code, der dann auf der Webseite in das für die Integration vorgesehene Containerelement geschrieben wird. Daniel und Matera verwenden in Ihrem Mashup-Konzept neben in Form von Flows verbundenen Elementen ein ereignisgesteuertes Modell. Eine UI-Komponente verfügt über Events und Operations, die es ermöglichen, dass verschiedene UI-Komponenten eines Mashups miteinander kommunizieren können. Die Events werden ebenfalls clientseitig via Javascript auf dem Browser des Clients getriggert und reichen das Event ggf. weiter an den Diensteanbieter der betroffenen UI-Komponente. Für das mashart-projekt gibt es einen nodebasierten42 grafischen Editor mit dem der MashupComposer die UI-Komponenten miteinander verknüpfen kann und entsprechende Ereignisse, sowie die dazugehörigen Operationen definieren kann. [vgl. DF09]

40 4. Verwandte Arbeiten Die Univerität Trento macht es mit dem MashArt-Projekt sehr einfach, leistungsfähige Mashups zu erstellen und diese mit neuen Funktionen zu versehen. Das Konzept ist vielversprechend und bietet durch sein Event-Modell nahezu unbegrenzte Erweiterungsmöglichkeiten für Mashups. Bislang dürfte die Anzahl der in MashArt integrierbaren Endanwendungen eher gering ausfallen, da diese sich nur in ein Mashup einbinden lassen, wenn der Entwickler MashArt-kompatible UI-Komponenten für die Anwendung bereit stellt. Damit MashArt auch für die große Masse der Entwickler attraktiv wird und sich als Standard etablieren kann, müsste das Projekt zunächst öffentlich zugänglich gemacht werden und eine signifikante Anzahl von Nutzern für sich gewinnen. Die Nutzerzahlen würden aber wiederum von Anzahl und Attraktivität der gebotenen ui-components abhängen. Somit ergibt sich aus der strickten Trennung von Mashup Composer und Entwickler ein typisches Henne-Ei-Problem. MashArt eignet sich daher vorwiegend für die Rekombination von Anwendungen, in der man selbst den Quellcode anpassen oder die Anpassung bei den Entwicklern durchsetzen kann An Infrastructure for Intercommunication between Widgets in PLE [NT09] In der Arbeit von Tobias Nelker an der Universität Paderborn wird eine Lösung aufgezeigt, mit der die oft monolithischen und schlecht erweiterbaren Personal Learning Environments über Widgets um neue Funktionalitäten erweitert werden können. Bestehende Lernportale bieten meistens eine vereinheitlichte Seiten-Darstellung für Veranstaltungen und kaum individualisierbare Einstiegsseiten. Der durch die Seite zu unterstützende Lernprozess ist jedoch keineswegs linear und standardisierbar, ebensowenig, wie die Art und Weise, wie Benutzer über das Portal kommunizieren, ihr Wissen mitteilen oder Informationsmaterialien austauschen. Widgets bieten hier die Möglichkeit, eine zur Art einer Veranstaltung oder zur Kurswahl des Benutzers passende Seite zu kreieren, die nur die Informationen darstellt, die auch tatsächlich vom Benutzer oder innerhalb des Kurses benötigt werden. Darüberhinaus lassen sich die Seiten jederzeit anpassen und die Funktionen und Inhalte verändern. Es lassen sich aber auch neue Funktionen schaffen, indem zwischen mehreren Widgets ein Datenaustausch stattfindet, also die Ausgabe eines Widgets als Eingabeparameter für ein anderes Widget dient. Für die Kommunikation zwischen den Widgets erwähnt der Autor das EU-Projekt MATURE, in dessen Rahmen ein sogenannter Widget-Server implementiert wird. Als Vorbild für die Implementierung des Widget-Servers dienen zwei andere Projekte namens EzWeb43 und Wookie44. EzWeb stellt eine grafische Oberfläche zur Komposition verschiedener Webservices dar, deren Aus- und Eingaben miteinander verknüpft werden können, um daraus ein Widget mit neuer Funktionalität zu erstellen. Das andere Projekt mit dem Namen Wookie-Server bietet wiederum die technische Infrastruktur, um selber Widgets hosten zu können. Darüber hinaus liefert der Wookie-Server ein Proxy-Backend, mit dem es möglich ist, auch die Widgets anderer Dienste, wie beispielsweise GoogleWave45 selber anzubieten. Eine Kommunikation der Widgets untereinander ist jedoch nicht vorgesehen. Der in der Arbeit vorge

41 4. Verwandte Arbeiten stellte Widget-Server MATURE basiert auf dem Wookie-Server, erweitert diesen aber um wesentliche Funktionen, wie Widget-Interkommunikation oder ein Benutzermanagement um auch personalisierte Widgets mit persistenten Daten zu ermöglichen. Grob unterteilen lässt sich der Server in die 5 Bereiche: Widget Management: Der Server stellt dem Anwender einen Katalog aller verfügbaren Widgets zur Verfügung. Aus dem Katalog kann der Anwender beliebige Widgets wählen und diese seinen Bedürfnissen anpassen. Da sich die Widgets selbst durch Ereignisse oder veränderte Eingabedaten verändern können, verwaltet der Server jedes laufende Widget in einer eigenen Instanz. Die Instanz stellt also gewissermaßen ein personalisiertes und zustandsbezogenes Abbild des jeweiligen Widgets dar, welches an den Benutzer ausgeliefert wird. Daneben verfügt der Server über ein Administrationswerkzeug und einen Widget-Speicher. Message System: Das Nachrichtensystem erlaubt eine Kommunikation zwischen Server und Widgets oder zwischen den Widgets selbst. Über die Nachrichtenfunktionen können die Eingabe oder Ausgabeparameter eines einzelnen Widgets oder einer ganzen Gruppe von Widgets zur Laufzeit verändert werden. Profile Management: Das Profilmanagement ist notwendig, um nutzerbezogene Daten innerhalb eines Widgets für andere Nutzer unzugänglich zu machen. Das Profilmanagement beinhaltet eine Nutzerauthentifizierung und ein Rechtesystem, in dem festgelegt ist, welche Informationen für andere Widgets zugänglich sind oder an andere Widgets weitergegeben werden dürfen. Backend Connector: Der Backend-Connector bildet die Kommunikationsschnittstelle für alle ausgelieferten Widgets, um beispielsweise Eingaben innerhalb eines Widgets in die entsprechenden Aktionen auf dem Server umzusetzen oder auf personalisierte Daten in einer Datenbank zuzugreifen. Graphical User Interfaces: Das grafische Benutzerschnittstelle spielt in dem Konzept keine Rolle. Die Widgets können ebenso gut in eine Webseite, wie auch in eine bestehende Desktopanwendung integriert werden, sofern für die jeweilige Sprache oder Darstellungsschicht ein Adapter existiert, der die vom Widget-Server erhaltene Widget-Spezifikation innerhalb der grafischen Benutzeroberfläche umsetzt. 31

42 4. Verwandte Arbeiten Den Ablauf und die Funktionsweise der Kommunikation zwischen zwei Widgets demonstriert der Autor an einem Mashup, das ein Kalender- und ein Wetterwidget aus igoogle miteinander kombiniert. Erstellt der Benutzer einen neuen Kalendereintrag, so schickt das Kalenderwidget diese Information an den Widget-Server, der das neue Datum wiederum an das Wetter-Widget übergibt, welches daraufhin das Wetter zum im Kalender eingetragenen Datum anzeigt. [vgl. NT09] Das MATURE-Projekt liefert einen fortgeschrittenen Ansatz, bestehende Widgets funktional miteinander zu verknüpfen. Das Projekt definiert keine grundlegend neue Widgetspezifikation, die mit bestehenden Systemen konkurriert, sondern schafft durch die Integration und Kompatibilität zu bereits verfügbaren Widgets verschiedener Anbieter einen direkten Mehrwert auch für bestehende Widgets. Das Projekt ist insgesamt noch sehr jung, es ist daher noch nicht abzusehen, wie leistungsfähig die Kommunikation zwischen den Widgets tatsächlich ist, da Ein- und Ausgabeformate verschiedener Widgets oft zueinander inkompatibel sind, und die Nachrichten bei der Übertragung zu einem anderen Widget umkonvertiert werden müssen. Ebenfalls unklar ist, wie Schleifen bei der Interwidgetkommunikation vermieden werden, die durch das wechselseitige Einspeisen von veränderten Ein-/Ausgabeparametern entstehen können. Interessant wäre zudem der Einsatz eines nodebasierten Konfigurationstools, mit dem die Zusammenhänge der Widgets und deren Nachrichtenfluss grafisch konzipiert werden können. Bestehende Web-Applikationen lassen sich in das System nur dann integrieren, wenn für die Applikation eine zu Wookie kompatible Widget-Schnittstelle implementiert wird. Auch wenn der Titel anderes vermuten lässt, wird das System für eine Personal-Learning Umgebung somit nur dann attraktiv, wenn Entwickler das Konzept aufgreifen und Widgets für ihre E-Learning-Anwendungen bereitstellen. 4.3 Anpassung der Darstellung einer Webseite Die vorgestellten Mashup-Systeme bringen alle den Nachteil mit sich, dass Veränderungen an der Anwendung selbst vorgenommen werden müssen, wenn diese über ein oder mehrere Widgets in das Lehr-/Lernportal integriert werden soll. Da die Anpassung vieler voneinander unabhängiger Webanwendungen zukünftige Updates stark erschwert, soll nachfolgend eine Arbeit vorgestellt werden, mit der es möglich ist, nur die grafische Ausgabe einer Webapplikation anzupassen, ohne die Anwendung selbst dabei zu verändern Accessmonkey: A Collaborative Scripting Framework for Web Users and Developers [BP07] Die Autoren Jeffey P. Bigham und Richard E. Ladner von der Washington Universtät in Seattle entwickelten mit Accessmonkey46 ein Framework, mit dem sich das Aussehen einer beliebigen Webseite anpassen lässt. Vor allem Internetnutzer mit körperlichen

43 4. Verwandte Arbeiten Behinderungen, die das Internet über einen Screenreader mit Sprachausgabe oder Braille erkunden, haben mit vielen herkömmlichen Internetseiten Probleme bei der Bedienung oder dem Rezipieren wesentlicher Informationen, da die Seiten nur unzureichend barrierefrei gemacht wurden. Ein möglicher Ansatz besteht daher darin, den Benutzer einer Webseite selbst mit in die Verbesserung derselben einzubeziehen, indem er clientseitig ausführbare Scripts erstellt, die Layout und Funktion der dargestellten Seite für einen bestimmten Anwendungszweck optimieren. Das Framework Accessmonkey bietet eine Scriptschnittstelle, die in Form eines Javascripts in die dargestellte Seite eingebunden oder als Browserplugin für Mozilla Firefox installiert wird. Die technische Basis für Accessmonkey stellt die Firefox-Erweiterung Greasemonkey dar, die die clientseitige Anpassung des Layouts über sogenannte Greasemonkey-Scripte ermöglicht. Um ein solches Script zu nutzen, muss dieses jedoch von jedem Benutzer separat installiert werden. Accessmonkey nimmt dem Besucher diese Arbeit ab und bietet für jede unterstützte Seite automatisch eine Auswahl an verfügbaren Scripts an, die die Usability der Seite verbessern sollen. Der Benutzer kann ein Script auswählen und sich die Veränderungen der Seite direkt anzeigen lassen. Die Einstellung der angewandten Scripte lässt sich für jeden Benutzer individuell speichern. Für Entwickler gibt es in Accessmonkey einen Developer-Mode, der automatisch Verbesserungsvorschläge direkt auf der Seite visualisiert. Die Vorschläge werden anhand der Nutzungshäufigkeit der Scripte generiert und können bei Bedarf vom Entwickler direkt übernommen werden. Dadurch wird für Entwickler ein Mehrwert geschaffen, der dazu führen soll, dass das Accessmonkey-Framework direkt in die Anwendungen statt über ein Browserplugin integriert wird. Für Benutzer, die Accessmonkey mit einem anderen Browser nutzen möchten, erwähnt der Autor die Möglichkeit, das Accessmonkey-Framework über einen Web-Proxy einzubinden. Der Proxy-Server für das Accessmonkey-Framework wurde als ApacheModul implementiert und ermöglicht die direkte serverseitige Integration von Accessmonkey-Scripten. Durch den Einsatz des Proxy Servers ergeben sich wesentliche Vorteile. Die per Javascript ausgeführten Accessmonkey-Scripte erlauben ohne ein entsprechendes Plugin keinen Zugriff auf die Inhalte unterschiedlicher Domains. Mit einem Web-Proxy lassen sich die HTTP-Requests jedoch über einen einheitlichen Server abwickeln und ermöglichen auch das Nachladen von Inhalten aus verschiedenen Quellen via Javascript. Somit lässt sich das Framework unabhängig von der jeweiligen Webanwendung einsetzen und bleibt unabhängig von der Browserwahl, da keinerlei zusätzliche Plugins installiert werden müssen. [vgl.bp07] Die dargestellte Lösung bietet eine effiziente und einsatzfähige Lösung, um Webseiten zu verändern. Problematisch ist jedoch, dass sämtliche Scripte bislang ausschließlich clientseitig ausgeführt werden und der Proxy nur auf rudimentäre Funktionen beschränkt ist. Die clientseitige Veränderung der Inhalte hat zur Folge, dass das Aussehen der Seite erst verändert werden kann, nachdem diese vollständig im Browser geladen wurde. Zusammen mit dem Nachladen der in den AccessmonkeyScripten spezifizierten zusätzlichen Ressourcen erhöht sich die Ladezeit und das übertragene Datenvolumen signifikant. Die Möglichkeit, auch die AccessmonkeyScripte selbst auf 33

44 4. Verwandte Arbeiten dem Server auszuführen ist für die Zukunft geplant, derzeit aber noch nicht implementiert. Da der Proxy als Apache-Modul selbst in C geschrieben ist, ist die Implementierung eines Parsers, der die Accessmonkey-Scripte bereits serverseitig ausführen kann relativ aufwendig. Um dies zu erreichen, müsste das Apache-Modul selbst um einen vollwertigen DOM-Parser und einen Javascript-Interpreter erweitert werden, was im Wesentlichen der Grundfunktionalität eines Browsers entspricht. Der Ansatz, das endgültige Aussehen der Webseite nicht innerhalb der Webanwendung selbst, sondern über separate und unabhängige Scripte zu steuern, ist für ein Lernportal besonders attraktiv, da eine der wesentlichen Anforderungen darin besteht, dass die in dem Lernportal integrierten Anwendungen austauschbar und updatefähig bleiben müssen. 4.4 facebook als Vorbild für eine offene Lernplattform? facebook (Abb.6) ist das mit circa 400 Millionen Nutzern am weitesten verbreitete und bisher erfolgreichste Soziale Netzwerk [24]. Es hat seine Ursprünge an der Havard University und wurde ursprünglich als Kommunikationsplattform für Havard-Studenten konzipiert. Die Plattform an sich ist zwar propietär, durch zahlreiche Schnittstellen aber auch für externe Entwickler geöffnet, die mit über innerhalb von facebook verfügbaren Applikationen maßgeblich mit zum Erfolg des Netzwerkes beigetragen haben [25]. Inzwischen wurde facebook auch für den Einsatz innerhalb von Forschung und Lehre entdeckt und speziell für E-Learning-Zwecke konzipierte Anwendungen in das Netzwerk integriert [26]. Das zeigt, dass facebook durchaus über wesentliche Merkmale eines Lernportals verfügt und einige technische und strukturelle Konzepte auch auf ein solches übertragbar wären. 34

45 4. Verwandte Arbeiten Abb. 6: Das Soziale Netzwerk facebook Quelle: Gemeinsamkeiten und Unterschiede zu einem LMS In einem Learning-Management-System wird durch die Anmeldung in einer Veranstaltung gemäß SCORM-Spezifikation47, sofern noch nicht vorhanden, eine Gruppe erzeugt, die deren Mitgliedern dann den Zugriff auf weitere die Veranstaltung begleitende Lernressourcen (sogenannte Lernobjekte) und Tools zur Kollaboration innerhalb der Seminargruppe gestattet. In facebook sind prinzipiell keine Gruppen vorgesehen. Das Portal bietet lediglich die Möglichkeit, Nutzer untereinander zu einem oder mehreren Freundeskreisen zu verknüpfen, und innerhalb dieses Freundesnetzwerkes seinen Freunden und bestimmten Anwendungen den Zugriff auf persönliche Ressourcen zu gewähren. Die Anmeldung zu einer Veranstaltung kann also nur über eine entsprechende in facebook integrierte Applikation abgewickelt werden, beispielsweise StudyGroups48. Wesentliches Merkmal von facebook ist eine Art halböffentliches Weblog. In diesem Weblog können alle Benutzer und die verwendeten Programme innerhalb des Freundeskreises Nachrichten, Bilder und Videos eintragen, die vom gesamten Freundeskreis einsehbar sind. Eine ähnliche Funktion gibt es auch in einigen Lernportalen in Form von E-Portfolio-Systemen für die Selbstreflexion und Zusammenarbeit bei der Durchführung von Begleitstudiumsprojekten (z.b. elgg, mahara49 oder das

46 4. Verwandte Arbeiten Augsburger eee-portfolio50). Der einzige Unterschied ist die gegenüber facebook feinere Rechteabstufung, die es erlaubt, Beiträge auch privat oder nur für eine kleine Gruppe innerhalb eines Projektes zugänglich zu machen. Eines der attraktivsten Merkmale von facebook ist der Single Sign-on, das einheitliche Layout und das anwendungsübergreifende Benutzermanagement, auf das facebook-applikation zurückgreifen können. Obgleich dies einer der Hauptkritikpunkte des Portals facebook ist [25,27], nimmt diese Funktion wesentliche Einstiegshürden, um eine neue Funktion auszuprobieren, und vereinfacht die Verwaltung der persönlichen Daten ungemein. Abgesehen von der in einem LMS wesentlich differenzierteren Gruppen, Rechte- und Rollenfunktionen bietet facebook damit einige wesentliche Anforderungen, die die derzeit am Markt verfügbaren Open Source LMS vermissen lassen. Dies soll exemplarisch an einem Beispiel aufgezeigt werden: Für ein Lernportal soll eine neue Komponente eingeführt werden, bei der die Nutzer online abstimmen dürfen. Die Ergebnisse der Abstimmung dürfen nur innerhalb einer geschlossenen Gruppe verfügbar sein. Im Falle eines LMS sieht sich der Entwickler einigen Problemen gegenüber gestellt: Wie wird gewährleistet, dass nur Benutzer den Zugriff auf die Abstimmung erhalten? Wie lässt sich sicherstellen, dass nur die Benutzer innerhalb der Gruppe die Ergebnisse der Abstimmung einsehen können? Wie kann die Abstimmung innerhalb des Lern-Portals dargestellt werden? Da die Lernportale in der Regel über keinen Single Sign-on verfügen, und sich der Benutzerstatus sowie dessen Rechte und Rollen nicht ohne weiteres durch eine Drittanwendung abfragen lassen, muss eine solche Funktion in das LMS nachträglich eingefügt werden. Das wiederum gefährdet zukünftige Updates, da der veränderte Code unter Umständen nicht mehr funktioniert. Eine optische Integration ist bisweilen gar nicht möglich, oder lässt sich quick-and-dirty nur über ein iframe realisieren, das jedoch einige Nachteile mit sich bringt [28] facebook Developer-API Die Einbindung des im Beispiel genannten Umfragetools wäre mit der facebook-api vergleichsweise einfach umzusetzen. Die facebook-api bietet Entwicklern für Drittanwendungen einen Single Sign-on, diverse Funktionen zum Abfragen von Benutzerdaten, Gruppen- und Statusinformationen sowie eine Möglichkeit, die Anwendung optisch an der dafür vorgesehenen Stelle in das Layout von facebook zu integrieren. Mit Hilfe der sogenannten facebook-developer-app kann ein Entwickler online die Schnittstelle zu der von ihm selbst entwickelten facebook Anwendung konfigurieren und festlegen, auf welchem Server diese läuft und wie diese in facebook integriert werden soll. Der Benutzer ruft eine facebook Anwendung zwar innerhalb von facebook auf, dennoch läuft die Anwendung auf einem Server, den der Anbieter der

47 4. Verwandte Arbeiten facebook Anwendung selbst bereitstellen muss. facebook fungiert als man-in-the-middle, leitet die vom Benutzer initiierte Anfrage an die Anwendung weiter, fängt die Rückgabe der Anwendung ab und integriert diese in die für die Anwendung vorgesehene facebook Seite. [GW08] Darstellung über FBML Die Darstellung einer Anwendung erfolgt üblicherweise über die FBML Markup-Language. FBML unterscheidet sich von klassischem HTML und Javascript dadurch, dass einige Javascript- und DOM-Funktionen nicht integriert sind, oder nur innerhalb einer Sandbox in facebook integriert werden [GW08]. Durch den reduzierten Befehlssatz soll verhindert werden, dass Anwendungen auch Komponenten von facebook selbst verändern können und beispielsweise Personen Nachrichten schicken, ohne dass dies vom Benutzer selbst genehmigt wurde. Darüber hinaus lassen sich in FBML Eingabeelemente im facebook Layout erstellen, die dann außerhalb der Sandbox ausgeführt werden. Über diese Eingabeelemente lassen sich auch facebook-interne Funktionen, wie die Benutzerbenachrichtigung ansprechen. Die Funktionsweise solcher aus Sicht der Privatsphäre kritischen Elemente wird von facebook genau vorgegeben und kann vom Entwickler der Anwendung nicht verändert werden [GW08]. Datenbankabfragen facebook Anwendungen profitieren insbesondere von der Möglichkeit, auf die ProfilDaten eines Benutzers und Informationen über dessen Freunde zuzugreifen. Die Daten können entweder über einen Webservice als XML und JSON oder über eine von SQL abgewandelte Abfragesprache namens FQL abgefragt werden [GW08]. Die Verwendung von FQL ermöglicht es facebook, die SQL-Queries vor Ihrer Ausführung durchzuparsen und sicherzustellen, dass keine ungewollten Datenbankabfragen oder gar eine Manipulation von Daten erfolgen kann. FQL bietet dem Entwickler nur einen read-only Zugriff auf die Datenbank. INSERT oder UPDATE-Queries erlaubt die facebook-api nicht [GW08]. Der Datenbankzugriff umfasst nur Daten von Personen, die dem eigenen Freundeskreis angehören oder der Applikation selber den Zugriff auf die Daten gewährt haben [GW08]. Storage-Server facebook speichert auf seinen circa Servern über 80 Milliarden Fotos, die von den Nutzern oder von Anwendungen in dem Portal hinterlegt wurden. Der zentrale Datenspeicher und die Upload-Funktionen lassen sich auch aus facebook Anwendungen heraus ansteuern [GW08]. Einige Anwendungen nutzen zum Beispiel den Zugriff auf die Fotos, um eine Collage aus Profilfotos in Form einer interaktiven Vernetzungskarte zu erstellen. 37

48 4. Verwandte Arbeiten Fazit facebook ist nicht nur das größe Soziale Netzwerk, sondern auch eine attraktive technische Plattform zum Ausführen, Integrieren und Vernetzen neuer Anwendungen. In technischen Belangen ist es allen am Markt verfügbaren LMS weit überlegen. Dennoch eignet es sich nicht als Ersatz für ein Lernportal, da die Technik proprietär ist und hinter dem Projekt finanzielle Absichten stecken, die wenig Rücksicht auf die Privatsphäre des einzelnen Benutzers nehmen. Ein LMS muss aber eine offene Plattform bieten, damit sich der Nutzerkreis nicht der Willkür eines einzelnen Unternehmens aussetzt. Darüber hinaus sind die Anforderungen an den Datenschutz in einen LMS wesentlich strenger, als dies in facebook derzeit der Fall ist, da die Nutzung eines LMS für den Studenten meist nicht auf einer freiwilligen Entscheidung beruht, sondern seitens der Dozenten oder Verwaltungsorgane einer Universität vorgeschrieben wird. Die facebook zugrunde liegende Architektur zeigt dennoch zahlreiche funktionierende Lösungswege für die in der Einleitung (Kap.1.2) genannten Probleme auf und soll daher in der weiteren Implementierung des Digicampus berücksichtigt werden. 38

49 5. Entwicklungsstrategie 5 Entwicklungsstrategie Die verwandten Arbeiten zeigen, dass die Neuentwicklung eines Lernportals ebenso wie die Integration oder Erweiterung bereits bestehender Anwendungen sehr komplex ist. Für das Problem der fehlenden Integrationsmöglichkeiten bestehender Systeme existieren zwar gute Lösungsansätze, allerdings ist in keiner Arbeit bislang ein Szenario dokumentiert, bei dem Mashups im großen Stil für die Schaffung und Erweiterung eines Lernportals erfolgreich eingesetzt wurden. Auf der anderen Seite gibt es aber auch kein Open-Source LMS, das sämtliche Bedürfnisse in einer Universität abdeckt, mit bestehenden Systemen zusammenarbeitet und zudem noch einfach erweiterbar ist. Nachfolgend soll erörtert werden, in welchen Fällen eine Neuentwicklung Sinn macht, in wieweit Erweiterungen möglich sind, ob ein MashupKonzept umsetzbar ist, und welche Strategie an der Universität Augsburg für den Digicampus gewählt wurde. 5.1 Neuentwicklung, Weiterentwicklung oder Framework Unabhängig davon, ob ein Lernportal neu entwickelt wird oder dieses auf bestehenden Systemen aufbaut, existieren Abhängigkeiten zu anderen Systemen, die in das Portalkonzept integriert werden müssen, wenn das System keine Insellösung darstellen soll. Da die Verwaltungssysteme verschiedener Hochschulen nicht identisch sind, müssen für jede Universität eigene Schnittstellen konzipiert werden, die sich flexibel auf die unterschiedlichen Systeme adaptieren lassen. Die Einführung des Lernportals ist daher an jeder Hochschule, die das Lernportal nutzen möchte mit zusätzlichen Implementierungsaufwand verbunden. Die Abwägung, ob es besser ist, ein LMS von Grund auf neu zu konzipieren, oder bestehende Systeme einzusetzen und diese so zu erweitern, dass die gewünschte LMS-Funktionalität gegeben ist, hängt also im Wesentlichen von der bereits existierenden Infrastruktur ab. Ist die IT-Infrastruktur nicht sehr ausgeprägt, macht es möglicherweise Sinn, das Lernportal als zentrales Verwaltungssystem zu etablieren und von dort aus die Schnittstellen zu weiteren daran angebundenen Anwendungen zu schaffen. Wenn bereits viele IT-Systeme im Einsatz sind, die auch weiter genutzt werden sollen, fällt in jedem Fall ein hoher Integrationsaufwand an, wenn das System auch für Dozenten und Verwaltungsmitarbeiter eine Arbeitserleichterung schaffen soll. Die Integration und Migration verschiedener Webanwendungen ist dafür eine zwingend notwendige Anforderung, die einen hohen Entwicklungsaufwand verursacht. Mit einer einmaligen Integration ist es jedoch nicht getan, da die meisten Systeme einer Weiterentwicklung unterliegen, und sich in Optik und Funktionsweise oder hinsichtlich ihrer Schnittstellen immer wieder ändern können. In den verwandten Arbeiten wurde eine Reihe von Möglichkeiten vorgestellt, die die Integration verschiedener Webanwendungen oder von Teilen davon über Mashups ermöglichen. Eine im Lernportal verankerte Anwendung kann darüber hinaus unabhängig von den Prioritäten und Zielen der Entwickler über den Einsatz eines Proxy und clientseitigen Scriptings für einen bestimmten Einsatzzweck optimiert werden. Die in den Arbeiten vorgestellten Projekte sind für den Einsatz in einem Lernportal nicht geeignet, da sie 39

50 5. Entwicklungsstrategie entweder proprietär, noch in der Entwicklung befindlich, oder in Ihrer Funktionalität nicht umfassend genug sind, um damit ein Lernportal neu zu gestalten. Existiert ein solches Framework, mit der die gegenseitige Integration und die optische Anpassung von Webanwendungen technisch einfach umzusetzen ist, so lässt sich ein verbessertes Lernportal auf Basis bestehender Anwendungen schaffen, das ein einheitliches Layout, eine konsistente grafische Benutzeroberfläche und die geforderten Funktionen überwiegend durch den Einsatz und die Rekombination bereits verfügbarer Anwendungen erfüllen kann [NP09]. Für die Entwicklung eines Lernportals gibt es daher folgende Optionen: Neuentwicklung des Lernportals und Vorgaben an die universitäre Verwaltungsinfrastruktur Weiterentwicklung der bestehenden bereits eingesetzten Software und Schaffung von Schnittstellen in Kooperation mit den Entwicklern Entwicklung eines Frameworks, mit dem eine Anpassung, Integration und Weiterentwicklung unabhängig von Version und Codebasis der verwendeten Software möglich ist In Tabelle 1 sind die Vor- und Nachteile der genannten Entwicklungsstrategien sowie eine subjektive Bewertung für die Entwicklung des Lernportal Digicampus dargestellt. Da die Entscheidung für oder gegen eine Entwicklungsstrategie von Umfang, Komplexität, Funktionen des Portals, den verfügbaren finanziellen Mitteln sowie dem angestrebten Einsatzzweck abhängt, kann die Bewertung bei anderen Portalsystemen auch anders ausfallen. Neuentwicklung des Lernportals Weiterentwicklung Framework zur Inbestehender Soft- tegration von ware Fremdanwendungen Planungsaufwand Einmalige Entwicklungs- und Personalkosten Wartung technischer Infrastruktur Zeitaufwand für erste Inbetriebnahme Abbildung realer Lehr-, Lern- und Verwaltungsprozesse Optische Anpassungsmöglichkeiten Anpassung bei veränderten Einsatzbedingungen Gewährleistung der Datenkonsistenz Migration von Bestandsdaten 40

51 5. Entwicklungsstrategie Erweiterung um neue Funktionen Integration anderer Anwendungen Zukunftsperspektive Bewertung Tab. 1: Bewertung der Vor- und Nachteile unterschiedlicher Entwicklungsstrategien für den Digicampus An der Universität Augsburg wurde für das Lernportal Digicampus längere Zeit das Prinzip der kontinuierlichen Weiterentwicklung von Bestandssoftware verfolgt, während die Neuentwicklung aufgrund des hohen Finanz- und Zeitaufwands verworfen wurde. Parallel dazu wurde 2009 mit der Entwicklung eines Frameworks zur Integration begonnen, der auch einen Wechsel der Entwicklungsstrategie einleitet. Die Beweggründe für diesen Schritt werden in den folgenden Abschnitten dargelegt. 5.2 Entstehung des Lernportals Digicampus An der Universität Augsburg ist das Lernportal Digicampus aus verschiedenen, zum Teil bereits im Einsatz befindlichen Webanwendungen entstanden. Die Entwicklung erfolgte nach einem evolutionären Prinzip, es wurden zunächst verschiedene Open Source LMS evaluiert und in der Praxis im Studiengang Medien und Kommunikation am Institut für Medien- und Bildungstechnologie getestet [GS07]. Erst danach wurde das Lernportal Digicampus entworfen und das bestehende LMS Stud.IP darin integriert. Der Digicampus und das LMS stand ab diesem Zeitpunkt auch anderen Studiengängen, Fakultäten und Lehrstühlen offen, die es auf freiwilliger Basis testen und bei Bedarf einsetzen konnten. Da der Einsatz des Systems nicht verpflichtend war, wurde es unabhängig von der bereits bestehenden Infrastruktur aufgebaut, um den Dozenten und Mitarbeitern auch weiterhin die Möglichkeit zu bieten, alternative Systeme einzusetzen und bestehende IT-Anwendungen zu nutzen, die sich insbesondere im Verwaltungsbereich bereits etabliert hatten. Eine komplette Neuentwicklung wurde ausgeschlossen und der Fokus bei der Entwicklung stattdessen auf die Integration der bestehenden Anwendungen zur Verwaltung von Vorlesungen, Prüfungsleistungen und studentischen Daten gelegt um eine schnelle Akzeptanz und hohe Verbreitung an der Universität zu erreichen. Mit der zunehmenden Verbreitung gingen eine Reihe neuer Anforderungen einher, die der Digicampus und das darin eingesetzte LMS nicht erfüllen konnte. Einige Anforderungen, die eine Vielzahl von Lehrstühlen betrafen, wurden als Erweiterung implementiert. Dazu zählt beispielsweise der Export der Vorlesungsdaten in die Homepage der Universität oder die Implementierung eines Tools zur Verwaltung von Anmeldungen, Übungen und an die Übungen gekoppelte Zulassungsbedingungen. Parallel dazu wurde versucht, die Zusammenarbeit des Digicampus mit an der Universität Augsburg bereits etablierten IT-Systemen zu verbessern. Wichtigste Anforderung war die Nutzung der universitätsweit einheitlichen Rechenzentrumskennung für den Login in den Digicampus und alle darin bereitgestellten Systeme. Für diesen Zweck wurde ein Mechanismus entwickelt, mit dem ein Benutzer 41

52 5. Entwicklungsstrategie nach Validierung seiner Zugangskennung automatisch in die jeweiligen Systeme angemeldet wird, indem Replikate der Session-Cookies eines jeden Systems erzeugt und zum Browser des Benutzers übertragen werden. In der Datenbank des jeweiligen Systems wurde das zum Cookie passende serverseitige Äquivalent der Session erzeugt und der Login-Status gesetzt. Der Mechanismus erlaubt derzeit die Zuordnung mehrerer Benutzeraccounts in einem System zu einer Rechenzentrumskennung und impliziert daher einen Wechsel zwischen verschiedenen Benutzerprofilen und Rollen. Ein Benutzer benötigt im LMS Stud.IP verschiedene Benutzerprofile, wenn er gleichzeitig einen Dozenten- und einen Studenten-Status innehat. Ebenfalls umgesetzt wurde eine einheitliche Navigationsstruktur zwischen den verschiedenen Systemen, damit der Benutzer das Gefühl hat, nur eine Anwendung bedienen und erlernen zu müssen. Um das zu erreichen, wird die Ausgabe aller Systeme auf dem Server zwischengespeichert, nochmal mit einem Parser analysiert und dabei verändert, bevor sie an den Browser des Nutzers zurückgegeben wird. Da alle im Digicampus verwendeten Anwendungen die Scriptsprache PHP nutzen, war es einfach möglich, die Ausgabe auf dem Server in ein anderes PHP-Script umzuleiten, das die Veränderungen durchführt [NP09]. 5.3 Weiterentwicklung des Digicampus Die bisher verwendete Möglichkeit, das Die Benutzeroberfläche einer Anwendung zu verändern, erlaubte es nicht ohne weiteres, innerhalb einer Anwendung Teile einer anderen Anwendung anzuzeigen. Die Anpassung der Benutzeroberfläche war zudem aufwendig und musste für jede Anwendung separat erfolgen, da es kein einheitliches System gab, mit dem an zentraler Stelle mittels bestimmter Regelsätze Inhalte extrahiert und verändert werden konnten. Für jedes neu eingesetzte System musste zudem Reverse-Engineering betrieben werden um das System zur Benutzerauthentifizierung und Verschlüsselung von Session-Daten herauszufinden. Dadurch war die Integration eines neuen Systems zwar möglich, aber sehr aufwendig. Durch den sehr hohen Verbreitungsgrad an der Universität Augsburg häuften sich die Anfragen zur Integration neuer Systeme und alte Systeme, wie das bislang eingesetzte E-Portfolio Tool elgg sollten durch andere ersetzt werden. Der Aufwand für die Integration erwies sich als zu hoch, um mit der Dynamik der wechselnden Anforderungen durch verschiedene Kurse und damit verbundenen Lehr-/Lernmethoden Schritt halten zu können, ohne dabei die Investitionen in Weiterentwicklung und den Fehlerbehebung drastisch zu erhöhen. Die bisherige Entwicklungsstrategie, die Systeme nach und nach auszubauen und um Schnittstellen zu erweitern wurde daher auf die für den Lehrbetrieb essentiell notwendigen Systeme beschränkt und parallel im Rahmen dieser Masterarbeit mit der Entwicklung eines Frameworks begonnen, mit dem eine vereinfachte Integration neuer Software in das Lehr-/Lernportal möglich ist. Das dabei erarbeitete Konzept soll auf den folgenden Seiten genauer vorgestellt werden. 42

53 6. Konzept 6 Konzept Eine effiziente Weiterentwicklung des Digicampus soll ermöglicht werden, indem neue Anwendungen so in das Portal integriert werden können, dass die anfangs genannten Anforderungen weitgehend erfüllt sind und der Implementierungsaufwand dennoch überschaubar bleibt. Diesen Zweck soll das Framework emigrant erfüllen. Unter einem Emigranten versteht man allgemein einen Auswanderer. Die Auswanderer stehen im Zusammenhang mit dem zu entwickelnden Webportal bildlich für die Vielzahl der Anwendungen, die nicht in ein einheitliches System migriert werden können und ganz bewusst auf eine dezentrale Infrastruktur mit unterschiedlichen Servern und unterschiedlichen Administratoren ausgelagert werden. So wie Auswanderer die Kultur von Ziel- und Ursprungsland miteinander verbinden, vereint das Framework die vielen unterschiedlichen und verteilten Systeme miteinander. Das Emigrant-Framework (Abb.7) soll am Beispiel des Lehr-/Lernportals Digicampus erläutert werden. Da die Probleme und infolgedessen auch die Anforderungen für alle Arten von Portalsystemen nahezu äquivalent sind, lässt sich das Konzept und damit auch das Framework auch auf andere vergleichbare Systeme, wie Businessportale, Webseiten zum Wissens-Management oder Soziale Netzwerke übertragen. Abb. 7: Logo des emigrant-frameworks 6.1 Integration und Erweiterung von Anwendungen Eine wesentliche Herausforderung besteht darin, die Anwendungen selbst in Ihrer Funktionalität und ihrem Aussehen zu verändern, ohne dabei Eingriffe im Quellcode der betreffenden Anwendung vorzunehmen. Jeder direkte Eingriff im Quellcode einer Anwendung müsste sich mit den Plänen und Interessen der Entwickler vereinbaren lassen, damit nicht alle Anpassungen nach einem Update der Anwendung wieder von neuem vorgenommen werden müssen. Bei der Vielzahl der in einer Universität verwendeten Webanwendungen ist dieses Szenario allerdings schwer umzusetzen, da die Entwickler auch wesentliche Teile Ihrer Anwendung weglassen müssten, wenn eine andere Anwendung denselben Vorgang besser gelöst hat. Der Weg, alle Anwendungen über Webservices anzusteuern, fällt ebenfalls aus, da die wenigsten Anwendungen eine vollwertige SOAP-Schnittstelle bieten. Darüber hinaus würde die Steuerung einer Anwendung über einen Webservice bedeuten, dass wesentliche Teile der GUI ein zweites Mal entwickelt werden müssten. 43

54 6. Konzept Zugriff auf die Ausgabe einer Webanwendung Alle Webanwendungen verfügen unabhängig von ihrer Programmiersprache, den verwendeten Klassen und der Zugänglichkeit über einen Webservice über eine gemeinsame Schnittstelle, die zudem noch standardisiert ist. Jede Webanwendung erzeugt ihre Ausgabe als HTML, Javascript oder Kombination der beiden Sprachen. HTML ist eine maschinenlesbare Sprache und spezifiziert die grafische Ausgabe einer aufgerufenen Webseite, während Javascript clientseitig ausgeführte Zusatzfunktionen implementiert. Abgerufen wird diese Ausgabe über das HTTP-Protokoll 51. Sämtliche Interaktionen mit einer Webanwendung werden ebenfalls über das HTTP-Protokoll abgewickelt. Das Protokoll ermöglicht die sichtbare oder versteckte Übertragung von Formulareingaben, das Hochladen von Binärdaten, die Authentifizierung eines Nutzers sowie den Austausch und die Änderung clientseitig in Form von Cookies oder Sessions gespeicherter Zusatzinformationen. Um das Layout einer Webseite verändern zu können, ohne deren Quellcode zu verändern, muss die über das HTTP-Protokoll versendete HTML-Ausgabe abgefangen werden, bevor diese wieder im Browser des Benutzers ankommt. Das HTTP-Protokoll verbietet jedoch einseitige Verbindungen um zu verhindern, dass zum Beispiel beim Aufruf einer Bankseite ein Duplikat derselben von einer kriminellen Organisation zum Webbrowser zurückgesendet werden kann. Im Wesentlichen gibt es somit genau zwei Ansatzpunkte, um eine HTTP-Verbindung abzufangen, direkt auf dem Server mit der Webanwendung oder auf dem ClientSystem im Browser. Eine Modifikation der HTTP-Verbindungen im Browser würde voraussetzen, dass jeder Benutzer des Webportals ein entsprechendes PlugIn in seinem Browser installiert hat (vgl. Kap.4.3.1). Das würde die Nutzbarkeit des Portals gewaltig einschränken und wäre zudem sicherheitstechnisch problematisch, da solch ein PlugIn zweckentfremdet werden könnte um zum Beispiel Zugangsdaten umzuleiten und einer fremden Datenbank zuzuspielen. Die beste Möglichkeit, die Ausgabe einer Anwendung zu verändern, besteht daher darin, die HTTP-Verbindung genau auf dem Server zu belauschen und abzufangen, auf dem auch die Anwendung selbst läuft. Das emigrant-framework besitzt ein Client-Programm, mit dem es möglich ist, die Ausgabe jeder Webanwendung auf ein anderes Programm oder einen anderen Server umzuleiten, bevor sie an den Browser des Benutzers zurückgegeben wird (vgl. Abb.8). Im Gegensatz zu der im vorhergehenden Kapitel erläuterten Methode zum Abfangen der Ausgabe funktioniert die im emigrant-framework eingesetzte Technik auch mit Applikationen, die nicht in PHP umgesetzt wurden, ist also somit unabhängig von der eingesetzten Programmiersprache. Abb. 8: Abfangen des HTTP-Datenverkehrs durch das emigrant-framework

55 6. Konzept Zugriff auf Webanwendungen externer Anbieter Da eine HTTP-Verbindung auf dem Server der zu integrierenden Webanwendung nur mit Hilfe eines dort installierten Programmes abgegriffen werden kann, ist ein direktes Einbinden einer fremden Webanwendung nur über einen Umweg möglich. Anstatt die HTTP-Verbindung der fremden Webseite zu belauschen, kann auch die Kommunikation zu einem Proxy-Server abgefangen werden, sofern der Proxy-Server selbst auch eine Webanwendung ist und sich auf demselben Server befindet, auf dem auch das Sniffer-Programm läuft. Der Einsatz eines Proxy-Servers ist jedoch nicht ganz unproblematisch, da der Proxy-Server prinzipiell den Zugriff und damit auch die Integration in das Portal für jede Webanwendung erlaubt. Darüber hinaus muss der Proxyserver in der Lage sein, selbsttätig alle Links, Verweise und Ressourcenverknüpfungen im HTML-Code dahingehend zu modifizieren, dass ein Aufruf derselben den Browser wieder an den Proxyserver verweist. Da sich einige Links auch in innerhalb der Seite eingebetteten Javascript verbergen ist dies nicht immer einwandfrei möglich. Darüber hinaus werden Proxy-Server oftmals von externen Anbietern ausgesperrt. Für das emigrant-framework wurde ein eigener Proxy implementiert, der gegenüber anderen am Markt verfügbaren webbasierten Proxy-Lösungen einige Vorteile bietet, auf die im Kapitel Architektur näher eingegangen wird Widgets aus Webseiten generieren Durch das Abfangen der HTML-Ausgabe lässt sich der Quelltext einer Seite beliebig verändern bevor er an den Browser zurückgegeben wird. So kann ein bestimmter Abschnitt einer aufgerufenen Webseite extrahiert werden, und auch nur dieser Teilbereich an den Benutzer zurückgegeben werden. Wenn der zu extrahierende Bereich von eindeutigen HTML-Tags umschlossen wird, kann dieser Vorgang mit einem serverseitigen DOM-Parser erfolgen. Damit ist es möglich, einfache Widgets zu erstellen, die sich in andere Webseiten integrieren lassen. Der wesentliche Vorteil zu den zuvor vorgestellten bereits am Markt verfügbaren Widget-Systemen besteht darin, dass das Widget in diesem Fall aus einer beliebigen Webseite erstellt werden kann, ohne dass die Anwendung selbst eine Schnittstelle für eine Widget-Engine bereitstellt. Damit entfällt theoretisch auch die Notwendigkeit eines Widget-Repositories, da Auswahl, Umfang und Funktion der Widgets nur mehr durch die Anzahl an zugreifbaren Webseiten beschränkt ist. In einem Lernportal bieten die Widgets die Möglichkeit, die Informationen verschiedener Systeme und Unterseiten in einer einheitlichen Portalseite gebündelt darzustellen, um dem Benutzer unnötiges Durchsuchen der darin verankerten Webanwendungen zu ersparen. Ein emigrant-widget muss sich nicht auf einen Teilbereich einer Internet-Seite beschränken, sondern kann auch die gesamte Seite umfassen. In Abb.9 ist in einem vereinfachten Beispiel gezeigt, wie die Erstellung und Integration eines Widgets aussehen kann. 45

56 6. Konzept Abb. 9: Erstellung eines Widgets aus System2 und Einbettung in System1 Widget-Parser Da die Definition und Aussehen eines Widgets nicht im Quelltext der Anwendung erfolgen kann, weil dies dem Prinzip widersprechen würde, die Anwendung selbst nicht zu verändern, wird das Widget unabhängig von der Anwendung definiert. Die Definition eines Widgets ist nicht trivial, da als einzige Eingabeparameter der von der Anwendung erzeugte HTML-Code sowie Informationen zur aufgerufenen Seite existieren, nicht aber logische Konzepte, Klassen und Funktionen, die im Quelltext der Anwendung selbst verborgen sind. Um dennoch die Definition von leistungsfähigen Widgets zu ermöglichen, wurde ein regelsatzbasiertes Parser-System entworfen, mit dem die relevanten Teile einer Webanwendung extrahiert werden können (vgl. Abb.10) und darin verborgene Inhalte mit weiteren Aktionen verknüpft werden können. Das Widget selbst besteht aus einer Vielzahl von Parser-Regeln die top-down abgearbeitet werden und somit eine Verfeinerung des Ergebnisses, den Aufruf eines anderen Widgets oder eine bestimmte Aktion, wie beispielsweise den Login eines bestimmten Benutzerprofils ermöglichen. Die Kombination mehrerer Regeln führt dazu, dass die gefundenen Informationen auch mit anderen Variablen verglichen und an Bedingungen geknüpft werden können, die ihrerseits eine bestimmte Aktion durchführen. Um anhand von in Widgets verborgenen Informationen Aktionen auszulösen, ist es notwendig, die dafür relevanten Merkmale in dessen HTML-Code automatisch zu identifizieren. Der im emigrant-framework integrierte Parser ist daher auch in der Lage in fehlerhaften, unstrukturierten oder nicht barrierefreien HTML-Code eine bestimmte Information zu erkennen und von anderen strukturell ähnlichen Daten abzugrenzen. Zudem besitzt der Parser eine Script-Schnittstelle, um auch komplexere Widgets zu erzeugen, die mit den vordefinierten Regelsätzen nicht umsetzbar sind. 46

57 6. Konzept Abb. 10: Erstellung eines Widgets aus System2 und Einbettung in System1 Unterstützung serverseitiger Widgets In der Regel werden Widgets clientseitig eingebunden, also erst geladen, nachdem die Portalseite, in der die Widgets dargestellt werden sollen, im Browser angezeigt wurde. Widgets, die miteinander kommunizieren oder in Form eines Mashups neue Funktionalität hinzugewinnen sollen, werden im emigrant-framework von einem Server eingebunden. Eine Seite mit serverseitig integrierten Widgets ist vom Umfang und Funktion identisch zu einer Seite mit durch den Browser nachgeladenen Widgets. Der wesentliche Vorteil der Einbettung durch einen Server besteht darin, dass dieser bereits vor der Auslieferung an den Browser das Abbild der Seite aus allen Widgets vorliegen hat. Dadurch lassen sich die Ausgaben verschiedener Widgets vergleichen und mit bestimmten Aktionen verknüpfen. Eine Aktion kann zum Beispiel der Aufruf einer anderen Seite, das Ersetzen eines Widgets durch ein anderes oder die Eingabe eines Datensatzes in einem Widget sein. Das emigrant-framework sieht eine serverseitige Kombination von Widgets vor, und bietet damit die Möglichkeit, Mashups zu erstellen, die ähnlichen Funktionsumfang, wie die im Kapitel Verwandte Arbeiten vorgestellten Systeme bieten. Dadurch, dass im emigrant-framework beliebige HTML-Seiten als Basis für ein Widget fungieren können, spielen sich die durch Widgets ausgelösten Aktionen nicht innerhalb einer Widget-Sandbox mit einem vom Widgetentwickler vorgegebenen Funktionsumfang ab, sondern umfassen sämtliche Funktionen, die in der zu Grunde liegenden Webanwendung durchgeführt werden können. Die emigrant-mashups sind im Vergleich zu den Systemen MashArt oder MATURE (vgl. Kap.4.2.) relativ komplex, da die Widgets lediglich als HTML-Code vorliegen und Aktionen nur anhand des Inhaltes eines Widgets getriggert werden können, nicht aber durch eine Funktion im Quellcode der zu integrieren Anwendung. Da die Anwendungen im Digicampus grundsätzlich austauschbar bleiben sollen und nicht zu eng miteinander verzahnt werden sollen, wurde der Fokus im emigrant-framework auf die Anzeige von Teilen einer Webanwendung innerhalb einer anderen Webseite und der Anpassung des Layouts gelegt. Um die funktionale Integration weiter zu verbessern, ist es denkbar, darüber hinaus ein ereignisgesteuertes System in das Framework einzubauen, das Aktionen auch beispielsweise mit bestimmten Eingaben innerhalb eines Widgets verknüpfen kann und damit das Nachladen oder Wechseln eines Widgets auch nach der Ausgabe auf dem Client ermöglicht. Der Unterschied zwischen server- und clientseitiger Integration ist in Abb.11 dargestellt. 47

58 6. Konzept Abb. 11: Integration eines Widgets: clientseitig (links), serverseitig (rechts) 6.2 Anwendungsleistung Die Integration vieler Anwendungen bedeutet auch, dass das System insgesamt langsamer wird, da die Seite, die letztlich an den Browser zurückgegeben wird, erst erstellt werden kann, wenn alle darin enthaltenen Anwendungen fertig geladen wurden. Die Erstellung der Portalseite benötigt ebenfalls Rechenzeit, die je nach Anzahl der verwendeten Parser-Regeln unterschiedlich hoch ausfallen kann. Nicht zuletzt muss die Seite auch wieder an den Browser zurückgegeben werden. Um den Overhead durch das Portalframework zu reduzieren, wurden unterschiedliche Ansatzpunkte verfolgt. Zum einen gibt es einen Cachingmechanismus, der alle aufgerufenen Seiten und die darin verlinkten Ressourcen wie Bilder oder Stylesheets auf dem Server zwischenspeichert. Das Caching hält einige Daten direkt im Hauptspeicher des Servers vor, um die Zugriffszeit zu minimieren und nutzt auch den browserinternen Cache um die Zahl der nötigen HTTP-Requests zu minimieren. Darüber hinaus können viele Widgets vom Browser aus via AJAX nachgeladen werden und dadurch die Anzahl der Systeme, die aufgerufen werden muss, bis eine erste Anzeige im Browser erfolgt, reduziert werden. Ein weiterer Ansatz besteht darin, für jeden Benutzer häufig aufgerufene Seiten zu analysieren und diese im Voraus zu laden, wenn innerhalb einer Seite darauf verlinkt wird. Weitere Leistungsverbesserungen lassen sich erzielen, indem die im Portal integrierten Anwendungen auf mehrere Server verteilt werden. Die Performance des Widget-Parsers wurde optimiert, indem die Regelsätze nicht zur Laufzeit ausgewertet werden, sondern jedes Widget als ausführbarer Programmcode vorgehalten wird. 48

59 6. Konzept 6.3 Benutzerverwaltung Zentrale Benutzer-Authentifizierung Die meisten e-learning Anwendungen stellen wesentliche Informationen auf der Webseite innerhalb eines zugriffsgeschützten Benutzerbereichs zur Verfügung. Ein Widget von einer geschützten Webseite muss daher zunächst Authentifizierungsinformationen anfordern und einen Benutzerlogin durchführen bevor es die gewünschten Informationen darstellen kann. Bei vielen verschiedenen Webanwendungen innerhalb eines Systems kann dem Benutzer nicht zugemutet werden, für jeden Aufruf eines Widgets die Zugangsdaten des jeweiligen darin verankerten Systems einzugeben. Daher ist es notwendig, dass die Zugangsdaten für die einzelnen Systeme zentral gespeichert werden und der Login mit diesen Zugangsdaten automatisch erfolgt. Das Prinzip ähnelt der in Desktopumgebungen vorzufindenden zentralen Passwort-Datenbank. In Gnome52 gibt es zum Beispiel den sogenannten Gnome-Keyring, der die Passwörter sämtlicher GTK-Applikationen zentral verschlüsselt speichert und die Zuordnungen zu den Programmen regelt. Das emigrant-framework bietet ebenfalls eine zentrale Speicherung von Zugangsdaten, regelt aber darüber hinaus auch deren Vergabe. Beim erstmaligen Login in das Portal vergibt das emigrant-framework selbstständig Zugangsdaten für alle Anwendungen, die über das Portal gesteuert werden oder für die noch kein Benutzerkonto existiert. Die Daten werden zentral gespeichert und beim Betreten eines zugriffsgeschützten Bereichs einer Anwendung automatisch an diese übertragen. Der Benutzer selbst wird nicht mit dem Loginprozedere einer Webanwendung konfrontiert. In Das emigrant-framework bietet somit einen Single Sign-On Mechanimus unabhängig davon, ob die integrierten Webanwendungen selbst Single Sign-On unterstützen (Abb.12). Abb. 12: Single Sign-on Zentrale Benutzerprofile Das emigrant-framework verwaltet neben den Zugangsdaten auch alle Benutzerdaten, die in den Benutzerprofilen der jeweiligen Anwendung abgelegt werden können. Dazu werden zwei Arten von Profilen vorgesehen: Zentrale und Anwendungsspezifische Profile

60 6. Konzept Aus dem zentralen Benutzerprofil werden die darin gespeicherten Benutzer-Informationen an alle Anwendungen übertragen. Das zentrale Profil hat den Vorteil, dass der Benutzer nur noch an einer einzigen Stelle im Portal seine Benutzerdaten aktualisieren oder ändern muss. Jede Änderung wird sofort im Hintergrund mit den Benutzerprofilen der Anwendungen synchronisiert, so dass gewährleistet bleibt, dass in allen Anwendungen dieselben aktuellen Benutzerdaten vorliegen Anwendungsspezifische Benutzerprofile Neben dem zentralen Profil kann der Entwickler im emigrant-framework auch Anwendungsspezifische Profile definieren mit Datenfeldern, die der Benutzer unabhängig vom zentralen Profil verwalten kann. So ist es möglich, auch fremde Systeme, zum Beispiel ein außerhalb der universitären Infrastruktur befindliches Soziales Netzwerk, in ein Lernportal zu integrieren und trotzdem die Privatspäre des Benutzers sicherzustellen, indem dieser eigene anonymisierte Benutzerdaten für dieses System hinterlegen kann. Welche Daten aus dem zentralen Profil entnommen werden, und welche der Benutzer für jedes System individuell festlegen darf, kann der Entwickler bei der Integration einer Anwendung konfigurieren. Zusätzlich enthält die Profilverwaltung des emigrant-frameworks eine Funktion, mit der sich zufallsgenerierte Benutzerprofile erstellen lassen. Außerhalb des Portalsystems ist dann nur die anonymisierte Identität des Benutzers zu sehen. Innerhalb des Portalsystems werden anstelle der verfälschten Benutzerangaben die echten Profildaten angezeigt. In Abb.13 wird dies an einem Beispiel gezeigt: Ein Benutzer, der im Lernportal Hugo heißt und in Berlin wohnt, ist für alle anderen Benutzer der externen Anwendung zum Beispiel als Hermann aus Frankfurt eingetragen. Loggt man sich in das Lernportal ein und wechselt zu der Stelle, an der die externe Anwendung integriert wurde, erscheint darin wieder der Name Hugo anstelle von Hermann. Für einen externen Benutzer ist daher der reale Benutzer hinter dem Decknamen nicht erkennbar. Abb. 13: Anwendungsspezifische Nutzerprofile 50

61 6. Konzept 6.4 Entwicklerzugriff Eines der Erfolgsrezepte von facebook besteht darin, die Plattform auch für Entwickler zugänglich zu machen, damit diese ebenfalls das Portal erweitern können und bei Bedarf nützliche Funktionen hinzufügen. In einem Lernportal ist es ebenfalls erstrebenswert, dass Benutzer eine für eine bestimmte Veranstaltung benötigte Anwendung in das Portal integrieren können. Geplant ist für eine zukünftige Version des emigrantframework eine Möglichkeit, mit der Benutzer eigene Widgets kreieren können, deren Funktionalität sich nur auf ein bestimmtes vom Benutzer eingebundenes System beschränkt. Besucht ein Benutzer innerhalb des Lernportals die eine VeranstaltungsSeite, in der das Widget verwendet wird, so wird er gefragt, ob er den Inhalt der Anwendung angezeigt bekommen möchte und welche Daten an die Anwendung dafür übermittelt werden. Bei der Übermittlung der Daten kann der Benutzer zudem auswählen, ob die Daten aus dem Hauptprofil des Benutzers stammen, oder ob ein separates Profil mit fiktiven Benutzerdaten generiert werden soll. 6.5 Grafische Oberfläche zur Konfiguration Um die Integration von neuen Anwendungen so einfach wie möglich zu gestalten und zudem Fehler auszuschließen, verfügt das emigrant-framework über ein grafisches Benutzerschnittstelle zur Konfiguration. Die Konfiguration umfasst die Erstellung von Regelsätzen und deren Verknüpfung zu Widgets, das Hinzufügen und Verwalten neuer Anwendungen sowie diverse anwendungs- und seitenspezifische Einstellungen. Das Konfigurationsoberfläche lässt sich, sofern der angemeldete Benutzer das Recht dazu besitzt direkt innerhalb der Seite aufrufen und zeigt immer zuerst die Einstellungen für die gerade angezeigte Seite und danach globale Einstellungen. Die Idee dahinter ist, dass der Entwickler bei der Integration einer Anwendung zunächst eine für das gesamte System gültige Konfiguration erstellt und diese dann verfeinert, indem er sich durch die Seite klickt und für jede aufgerufene Seite individuelle Regeln festlegt. Das Konfigurationsoberfläche wurde zudem so konzipiert, dass die meisten Einstellungen gemacht werden können, ohne dass ein Reload der Seite erfolgt, um dem Entwickler längere Wartezeiten zu ersparen. 51

62 6. Konzept 52

63 7. Architektur 7 Architektur Das emigrant-framework gliedert sich in zwei Komponenten: emigrant-client emigrant-server Der Browser des Benutzers kommuniziert mit dem emigrant-client. Der Client fängt die HTML-Ausgabe des aufgerufenen Programms ab und leitet diese an den Server weiter (Abb.14). Der Server verfügt über einen HTML-Parser der auf dem vom Client erhaltenen HTML-Code angewendet wird. Je nachdem, welche Regeln für die aufgerufene Seite hinterlegt sind, führt der Server gegebenenfalls bestimmte Aktionen durch, integriert Widgets in die Seite und erstellt anschließend die Portalseite, die wieder an den Client zurückgegeben wird. Der emigrant-client gibt die vom Server erhaltene Seite an den Browser zurück. Abb. 14: Komponenten des emigrant-frameworks 7.1 Entwurfsmuster MVC Bei der Entwicklung neuer Software mittels objektorientierter Programmierung wird häufig auf bereits definierte Entwurfsmuster (sogenannte Patterns) zurückgegriffen, die die Programmierung übersichtlicher gestalten und spätere Änderungen und Erweiterungen des Programms vereinfachen sollen. Ein bei der Entwicklung von Webanwendungen häufig verwendetes Entwurfsmuster ist das sogenannte MVC-Pattern. Es wurde 1979 am Forschungszentrum Xerox PARC entwickelt und untergliedert ein Softwareprojekt in die drei Bereiche Model, View und Controller [30]. Das Model repräsentiert den aktuellen Datenbestand einer Anwendung und die logische Verknüpfung derselben [31]. Das Model legt seine Daten üblicherweise in einer Datenbank ab und kapselt sie in stärker abstrahierte Objekte, auf die vom Controller aus zugegriffen werden kann. 53

64 7. Architektur Die grafische Benutzeroberfläche ist die für den Benutzer sichtbare visuelle Darstellung des Models und wird in einem View erzeugt [31]. Während das Model so konzipiert ist, dass es primär die effiziente Speicherung und den einfachen Zugriff auf die Programmdaten durch das Programm selbst ermöglicht, soll der View den einfachen Zugriff durch den Benutzer ermöglichen. Der Controller bildet die zentrale Schnittstelle zwischen dem Benutzer, dem Model und dem View. Der Controller nimmt Steuerbefehle durch den Benutzer entgegen und übersetzt die Befehle in die notwendigen Operationen zum Abruf oder zur Speicherung von Daten im Model [31]. Des weiteren steuert der Controller den Datenfluss zwischen Model und View sowie zwischen View und Benutzer. In Abb.15 ist eine MVC-Architektur für ein Web-Framework, wie z.b. cakephp53 dargestellt. In Webapplikationen erfolgt die Kommunikation zwischen dem Browser und dem Controller in der Regel über einen Webserver, der die Steuerungsbefehle des Browsers an den Controller weiterreicht. MVC-Pattern Emigrant-Framework Database Model Model View Emigrant-Server Controller Webserver Browser Regelsätze Webseite Emigrant-Client Browser Abb. 15: Komponenten des emigrant-frameworks angelehnt an Quelle: Entwurfsmuster im emigrant-framework Wie in Abb. 15 dargestellt, basiert das emigrant-framework basiert im Wesentlichen ebenfalls auf dem MVC-Pattern. Der emigrant-client kann als modifizierter Webserver angesehen werden, da er ebenfalls die Steuerbefehle des Benutzers entgegennimmt und an den Controller, in diesem Fall den emigrant-server weiterreicht. Das Aussehen der Portalseite, also der View wird im emigrant-framework über die Regel

65 7. Architektur sätze definiert. Weitergereicht wird die Portalseite an den Benutzer über den emigrantserver. Der einzige signifikante Unterschied zum MVC-Pattern besteht in der Art und Weise, wie auf die Daten im Model zugegriffen wird. Da das emigrant-framework keinen Zugriff auf die Datenbanken der zu integrierenden Anwendungen erhält, dient die Ausgabe einer Anwendung als Datenbasis für das Model. Der Zugriff auf die Webseite erfolgt direkt über den emigrant-client, statt durch den Controller, wie im MVC-Pattern vorgesehen. Diese Vorgehensweise hat den Vorteil, dass MVC nur angewendet wird, wenn die zugegriffenen Daten verändert oder neu kombiniert werden müssen. Wenn der Benutzer über den emigrant-client eine Anwendung aufruft, wird mit der HTML-Seite nur ein kleiner Teil der Daten an den Controller weitergereicht. Der größere Teil, bestehend aus allen Bildern, Javascripts und Stylesheets wird unmittelbar an den Benutzer zurückgegeben. 7.2 Kommunikation im emigrant-framework Zwischen dem Webbrowser und dem emigrant-server findet in der Regel keine Kommunikation statt. Der Webbrowser baut beim Aufruf einer Anwendung im emigrant-framework lediglich eine Verbindung zum emigrant-client auf, der bedarfsweise die Ausführung bestimmter Funktionen auf dem emigrant-server initiiert. Diese sind: aktuelle Seite automatisch abändern aktuelle Seite mit einem festgelegten Regelsatz bearbeiten Profildaten des aktuellen Benutzers übertragen Konfiguration der Anwendung übertragen Benutzerstatus ermitteln (ist der Benutzer angemeldet?) Umgekehrt kommuniziert auch der emigrant-server nicht direkt mit einer Anwendung. Wenn der Server die Anweisung erhält, eine andere Anwendung oder ein Widget in die aktuelle Seite einzubinden, so ruft der emigrant-server die zu integrierende Anwendung ebenfalls über den der Anwendung zugeordneten emigrant-client auf. Der emigrant-server greift auf den emigrant-client für folgende Funktionen zurück: Aktion in einer Anwendung durchführen (Login, Registrierung, Update) eine bestimmte Seite in einer Anwendung aufrufen einen festgelegten Regelsatz auf eine Anwendungsseite anwenden Aktualisierung der Konfiguration auf dem emigrant-client erzwingen Oftmals führen die Funktionen, die der emigrant-server auf dem emigrant-client durchführt, wieder zum Aufruf einer Funktion auf dem emigrant-server, die seinerseits wieder zum Aufruf einer Funktion im emigrant-client einer anderen Anwendung führt. Durch dieses Wechselspiel ist es möglich, ein Mashup unterschiedlicher Anwendungen 55

66 7. Architektur zu realisieren, ähnlich wie dies bei dem in Kap dargestellten Mashup-Composer der Fall ist. 7.3 Portalarchitekturen im emigrant-framework Nachfolgend sollen zwei Beispiele erläutert werden, die eine Portalseite mit Widgets aus bereits bestehenden Anwendungen über das emigrant-framework erzeugen. Die zu integrierenden Anwendungen können clientseitig im Browser des Benutzers durch einen AJAX-Aufruf eingebunden werden. Alternativ lässt sich die fertige Portalseite auch serverseitig generieren. In diesem Fall ruft der emigrant-server die Widgets, die in die Portalseite integriert werden sollen, ab und fügt sie an entsprechender Stelle in die aktuell aufgerufene Seite ein. Das emigrant-framework ermöglicht sowohl eine breite Integration der Anwendungen (vgl. Abb.16, linke Seite), bei der alle zu integrierenden Widgets parallel abgerufen werden, wie auch eine tiefe Integration, bei der ein Widget seinerseits weitere Widgets integrieren kann (vgl. Abb.16, rechte Seite). Darüber hinaus sind auch beliebige Anordnungen möglich, durch die sich auch komplexe Integrationsszenarien realisieren lassen. Die beiden dargestellten Beispiele veranschaulichen jeweils die serverseitige Integration. Der Ablauf einer clientseitigen Integration ist in vereinfachter Form in Abb. 11 dargestellt. Abb. 16: breite vs. tiefe Integration von Anwendungen im emigrant-framework breite serverseitige Integration In Abb.17 ist ein Beispiel für eine Portalarchitektur gezeigt. Es wird gezeigt, wie eine Portalseite bestehend aus drei verschiedenen Anwendungen erzeugt wird. Die Erstellung des Mashups erfolgt in drei Zyklen. Der Benutzer ruft zunächst eine Seite von Anwendung 1 über den emigrant-client in seinem Webbrowser auf. Diese Seite dient als Vaterseite, d.h. alle nachfolgenden Zyklen bewirken eine Änderung innerhalb der abgerufenen Seite von Anwendung 1. Der emigrant-client übergibt die aufgerufene Seite der Anwendung an den emigrant-server, der seinerseits den Aufruf und die Generierung der Widgets 1 und 2 aus Anwendung 2 und Anwendung 3 anstößt. Die Widgets werden anschließend in die Seite der Anwendung 1 eingebunden, eine Navigationsleiste hinzugefügt, und das Ergebnis wieder an den emigrant-client zurückgegeben, der es an den Browser des Benutzers weiterreicht. Der Aufruf der Seite führt also intern im emigrant-framework zu zwei weiteren parallelen Seitenaufrufen, ohne dass der Benutzer etwas davon bemerkt. 56

67 7. Architektur Abb. 17: Ablauf einer breiten serverseitigen Integration tiefe serverseitige Integration Die Abb.18 zeigt ein Beispiel für eine Portalseite, bei der die Widgets verschachtelt integriert werden. Wie auch im vorhergehenden Beispiel setzt sich die Portalseite aus 3 unterschiedlichen Anwendungen zusammen. Der erste Aufruf einer Seite aus Anwendung 1 bewirkt in dem hier gezeigten Fall, dass der emigrant-server die Anwendung 2 aufruft und daraus ein Widget erstellt. Das Widget 2 aus Anwendung 2 enthält jedoch eine zusätzliche Abhängigkeit, da darin eine Komponente aus Anwendung 3 enthalten ist. Nach dem Abruf einer Webseite von Anwendung 2 wird daher zunächst Anwendung 3 aufgerufen und daraus das Widget 3 erstellt. Dieses Widget wird anschließend in das Widget 2 integriert, und die Kombination der beiden Widgets an den emigrant-server zurückgegeben, der die ursprünglich vom Benutzer aufgerufene Seite bearbeitet. Die fertige Portalseite wird im Anschluss wieder über den emigrant-client zurück an den Browser übermittelt. Die im Beispiel gezeigte Verschachtelung lässt sich im Prinzip beliebig weiterführen, jedoch ist darauf zu achten, dass es zu keiner Schleifenbildung kommt, indem erneut ein Widget aufgerufen wird, das bereits in einem der oberen Knoten des Baumes verwendet wurde. 57

68 7. Architektur Abb. 18: Ablauf einer tiefen serverseitigen Integration beliebige serverseitige Integration Die Integration von Anwendungen über das emigrant-framework folgt dem Schema eines ungerichteten Graphen und erlaubt damit in der Theorie eine beliebige Anzahl von Knoten mit beliebiger Kantenzahl. In der Praxis ist es aufgrund der entstehenden Wartezeiten beim Seitenaufruf allerdings nicht sinnvoll, mehr als 3 Knoten hintereinander auszuführen. Auch der parallele Aufruf mehrerer Anwendungen wirkt sich negativ auf die Leistung aus, somit sind der Komplexität durch die Serverhardware natürliche Grenzen gesetzt. Die Integration schließt auch eine Kreisbildung nicht aus, allerdings führt diese unweigerlich zu einem Absturz des Webservers, sofern keine Abbruchbedingung existiert, die die Hintereinanderausführung beendet. 58

69 8. Implementierung 8 Implementierung Der emigrant-client wurde ebenso wie der Server vollständig in der Interpretersprache PHP implementiert, die deshalb gewählt wurde, weil sie die am weitesten verbreitete Scriptsprache ist [33] und insbesondere im Open Source Bereich ein Großteil aller Webanwendungen in PHP umgesetzt werden. Weil PHP von den meisten Webservern unterstützt wird [32], ist auch das emigrant-framework sehr weitläufig einsetzbar. Zudem erwies sich der hohe Verbreitungsgrad von PHP auch bei der Implementierung als vorteilhaft, da sich in den zahlreichen Open Source Anwendungen und OnlineCommunities Lösungen und Praxisbeispiele für die meisten der im Verlauf der Implementierung aufgetretenen Probleme fanden. Die Implementierung umfasste im Wesentlichen folgende Kernkomponenten: emigrant-client emigrant-server Grafische Benutzeroberfläche 8.1 emigrant-client In Anlage I ist ein Ablauf skizziert, bei dem ein Seitenaufruf vom emigrant-client abgefangen wird. Der emigrant-client führt folgende Schritte durch: HTTP-Aufruf abfangen Aufruf serverseitig durchführen Inhalte der Seite zwischenspeichern Kommunikation mit dem emigrant-server Rückgabe des emigrant-servers an den Browser übermitteln Aktionen auf dem System ausführen Intrusion Detection HTTP-Aufruf abfangen Der emigrant-client setzt einen Apache54-Webserver mit Standardkonfiguration voraus, da auf die im Apache-Server integrierten.htaccess-funktionen zurückgegriffen wird. Der Apache-Webserver ist der derzeit am häufigsten genutzte Webserver und liefert knapp 50% aller verfügbaren Webseiten aus [34]. Somit ist auch das emigrantframework auf einem erheblichen Teil der Webserversysteme einsetzbar. Über.htaccess-Dateien lassen sich Einstellungen und Funktionen des Apache-Webservers für ein bestimmtes Verzeichnis individuell konfigurieren, ohne dass dafür die Konfigu

70 8. Implementierung rationsdateien des Apache-Webservers selbst verändert werden müssen. Üblicherweise werden.htaccess-dateien dazu verwendet, einen Zugriffsschutz für ein Webserververzeichnis zu realisieren, das Caching-Verhalten des Browsers zu beeinflussen oder regelbasierte Umleitungen zu realisieren die eine andere Webseite aufrufen, ohne dass sich die in der Adresszeile des Browsers eingegebene URL ändert. Letzteres wird über das Apache-Modul mod-rewrite umgesetzt. Im emigrant-framework dient die.htaccess-datei zum Umleiten der eigentlichen HTTP-Requests auf den emigrantclient, damit dieser den Aufruf modifizieren kann. Der emigrant-client bietet zwei unterschiedliche Betriebsmodi (Abb.19): Im Modus normal wird der emigrant-client im Verzeichnis der zu integrierenden Anwendung installiert und steuert die Integration dieser Anwendung. Die zu steuernde Anwendung muss in PHP geschrieben sein, damit der emigrant-client im normalen Modus betrieben werden kann, da in diesem Fall direkt in den PHP-Aufruf der Anwendung eingegriffen wird. Der normale Modus bietet eine höhere Kompatibilität und bessere Leistung, da alle im Quelltext der Anwendung angegebenen Ressourcenpfade unverändert bleiben. Im Modus proxy wird der emigrant-client auf einem anderen Server installiert und ermöglicht dadurch die Integration von Anwendungen, auf die der Administrator des emigrant-frameworks keinen Administrator-Zugriff hat, die nicht in PHP geschrieben sind, oder die nicht unter einem Apache-Webserver lauffähig sind. Der proxy-modus ist jedoch langsamer und nicht mit jeder Anwendung kompatibel, da der Quelltext so modifiziert werden muss, dass alle Links, Ressourcenpfade und URLs darin wieder im proxy-modus aufgerufen werden. Abb. 19: normaler Modus vs. Proxy Modus Normaler Modus: Im normalen Modus befindet sich der emigrant-client in einem Unterverzeichnis der Anwendung selbst. Über eine.htaccess-datei wird erzwungen, dass jedem Aufruf einer PHP-Datei der Aufruf des emigrant-clients vorausgeht. Diese sogenannten prepend-files bieten die Möglichkeit, beliebige PHP-Funktionen aufzurufen, die sich direkt auf die Anwendung auswirken. In der gegenwärtigen Version des Digicampus 60

71 8. Implementierung wird eine Ausgabe-Pufferung über prepend-files erzwungen, d.h. die gesamte Ausgabe der aufgerufenen Anwendung wird nicht direkt an den Browser ausgegeben, sondern in einer Variablen gespeichert. Die Ausgabe wird anschließend um eine neue Kopfzeile mit einer horizontalen Menüleiste sowie eine Fußzeile und neue Stylesheets ergänzt. Die Ausgabe-Pufferung funktioniert allerdings nicht in jedem Fall, da der AusgabePuffer von der Anwendung überschrieben werden kann, oder sich die Anwendung vorzeitig beenden kann und damit der Zugriff auf den Ausgabe-Puffer nicht mehr möglich ist. Im emigrant-client dient die prepend-datei daher lediglich dazu, die direkte Ausführung des nachfolgenden PHP-Programms zu unterbinden. Stattdessen ruft der emigrant-client die vom Benutzer aufgerufene URL über eine HTTP-Client genannte Klasse auf. Der Aufruf umfasst dabei aber nicht nur die URL, sondern unter Umständen auch übertragene Formulareingaben (sogenannte POST-Requests) oder Datei-Uploads. Der emigrant-client emuliert auf diese Weise exakt den HTTP-Aufruf, den der Benutzer über seinen Browser gemacht hat. Der Initiator des HTTP-Aufrufs ist dadurch nicht mehr der Browser des Benutzers selbst, sondern der emigrant-client, was zur Folge hat, dass die aufgerufene Seite ebenfalls an den emigrant-client zurückgegeben wird und somit modifiziert werden kann, bevor eine Rückgabe an den Browser des Benutzers erfolgt. Um zu verhindern, dass der emigrant-client sich wieder selbst aufruft, und dadurch eine Endlosschleife an HTTP-Aufrufen produziert, ohne die eigentliche Seite anzuzeigen, wird an durch den emigrant-client gestartete HTTP-Aufrufe ein zusätzlicher Parameter emigrant_call=true angehängt. Ist der Parameter gesetzt, so wird nicht der HTTP-Client aufgerufen, sondern direkt die Anwendung angezeigt (vgl. Abb 19). Bilder, sowie Javascript und Stylesheet-Dateien werden im normalen Modus immer direkt aufgerufen und nicht durch den emigrant-client umgeleitet, sofern sie nicht durch ein PHP-Script erzeugt werden. Dadurch bleibt gewährleistet, dass Javascripts in Ihrer Funktion nicht beeinträchtigt werden und die Ladezeiten von in die Seite eingebunden Medien niedrig bleiben. proxy-modus: Im proxy-modus wird der emigrant-client als Standalone-Programm betrieben. Eine.htaccess-Datei im dem emigrant-client übergeordneten Verzeichnis beinhaltet eine rewrite-regel, über die alle aufgerufenen URLs so umgeschrieben werden, dass anstelle der URL der Anwendung ein Aufruf des emigrant-clients erfolgt. Auch der Aufruf eines auf dem Server des emigrant-clients real gar nicht existierenden Unterverzeichnisses verweist auf den emigrant-client. Auf diese Weise ist es möglich, dem Webbrowser die Existenz beliebiger Dateien vorzugaukeln und dadurch die Datei- und Verzeichnisstruktur eines Fremdsystems auf dem Server des emigrant-clients zu simulieren. Mit jedem Aufruf des emigrant-clients wird zudem ein Parameter übergeben, der die aktuell aufgerufene URL beinhaltet. Der emigrant-client übersetzt die vom Benutzer eingegebene URL in die echte URL der aufzurufenden Anwendung. In diesem Schritt findet auch eine Verifizierung statt, ob die aufgerufene URL im proxy-modus aufgerufen werden darf. Damit soll verhindert werden, dass nicht dafür bestimmte Systeme in die Lehr-/Lernumgebung eingebunden werden können. Die echte URL wird an die HTTP-Client Klasse übergeben, die dann die Kommunikation 61

72 8. Implementierung mit der Anwendung dahinter initiiert. Auch im proxy-modus werden übertragene Formulardaten an die Anwendung weitergereicht, so dass der Aufruf abgesehen von der anderen URL identisch mit dem des Benutzer-Webbrowsers ist. Während im normalen Modus nur der Aufruf einer PHP-Datei über den emigrant-client durchgeführt wird, wird der proxy-modus auf jede URL des Fremdsystems angewendet, da es nicht möglich ist, im Voraus von einem externen Server aus zu ermitteln, ob die URL zu einem PHP-Script oder zu einer Javascript- oder Stylesheetdatei führt Aufruf serverseitig durchführen Die vom emigrant-client initiierten HTTP-Aufrufe werden über eine dafür entwickelte HTTP-Client Klasse durchgeführt. Die HTTP-Client Klasse erfüllt im Wesentlichen die Aufgaben eines normalen Desktop-Webbrowsers, nur mit dem Unterschied, dass die Ausgabe nicht grafisch dargestellt wird. Da der HTTP-Client im Unterschied zu einem Desktop-Webbrowser zahlreiche Aufrufe und Benutzersitzungen gleichzeitig bearbeitet, legt die Klasse HTTP-Client für jeden Benutzer einen separaten Container an, in dem alle Cookies und Session-Informationen gespeichert werden, die zu diesem Benutzer gehören. Jeder Container erhält eine eindeutige ID, die im Webbrowser des Benutzers hinterlegt wird, und anhand der der HTTP-Client ermitteln kann, welche Anfrage und welches Sitzungscookie zu welchen Benutzer gehört. Durch die voneinander getrennten Benutzersitzungen kann der im emigrant-client integrierte Browser beliebig viele gleichzeitig in einer Webanwendung eingeloggte Benutzer verwalten, ohne dass ein anderer Benutzer ausgeloggt wird oder gar der Zugriff auf die Daten eines anderen Benutzers in der aufgerufenen Anwendung möglich ist. Der Sitzungscontainer bleibt solange gültig, bis der Benutzer seine Browsersitzung schließt. Der ebenfalls in PHP implementierte HTTP-Client nutzt das Kommandozeilenprogramm Curl55 sowie die dazugehörige PHP-Library libcurl56 um HTTP-Requests durchzuführen. Curl gilt als besonders leistungsfähig und wird daher auch für Web-Crawler, Webserver-Benchmarks und Webservices verwendet. Darüber hinaus erlaubt Curl eine vollständige Modifikation der zu übertragenden Header-Dateien und die Speicherung und Übertragung von Cookies oder Formulardaten. Die HTTP-Client Klasse ruft mittels Curl die ihm übergebene URL samt der zu übertragenden Formulardaten auf und übergibt die dem Benutzer zugeordneten Cookies aus dem Sitzungscontainer. HTTP-Aufruf im normalen-modus: Im normalen Modus gibt der HTTP-Client eine Webeite exakt so zurück, wie sie der Browser des Benutzers erhält, wenn er die Seite ohne den emigrant-client aufruft. Dadurch, dass der emigrant-client direkt im Verzeichnis der Anwendung gespeichert ist, führt auch ein Aufruf eines Links innerhalb der Anwendung wieder dazu, dass zunächst der emigrant-client aufgerufen wird, bevor die HTTP-Anfrage an die Anwendung weitergegeben wird

73 8. Implementierung HTTP-Aufruf im proxy-modus: Wenn sich der emigrant-client im Proxy-Modus befindet, muss der HTTP-Client die gesamte Ausgabe parsen, bevor diese weiter verwertet werden kann. Der HTTP-Client versucht dabei sämtliche im Quelltext der aufgerufenen Seite verborgenen URL-Angaben zu ermitteln, und diese durch eine URL zu ersetzen, die wieder auf den Proxy führt. Dieser Vorgang ist notwendig, da sonst bereits das Verfolgen eines Links genügen würde, um aus dem emigrant-framework auszubrechen, da die Verbindung dann direkt auf den Anwendungsserver, statt auf den dafür vorgesehenen Proxy im emigrant-client verweist. Darüber hinaus verbieten Webbrowser innerhalb eines Javascripts das Nachladen von Ressourcen von einer anderen Serveradresse. Daher ist es auch notwendig URL-Angaben für AJAX-Requests innerhalb eines Javascripts oder URL-Angaben innerhalb einer Stylesheet-Datei zu erkennen und anzupassen. In HTML, CSS und Javascript können URLs neben einem absoluten Pfad auch relativ zu dem Pfad angegeben werden, in dem sich die aufgerufene Datei befindet. Darüber hinaus besteht die Möglichkeit, URLs relativ zum Basisverzeichnis des Webservers anzugeben oder diese dynamisch zur Laufzeit durch ein Javascript zu erzeugen. An die URL angehängte Parameter dürfen bei eine Abänderung zu einer Proxy-URL nicht verloren gehen. Aus diesem Grunde ist die Detektion und das darauf folgende Umschreiben von URL-Angaben sehr kompliziert und nicht immer ohne weiteres möglich. Im Verlauf der Implementierung wurde zunächst eine bereits verfügbare Proxyengine verwendet, die später durch einen selbstentwickelten Webproxy ersetzt wurde. Der anfangs verwendete glype57-proxy ist ein webbasierter ebenfalls in PHP geschriebener Anonymisierungsproxy, dessen Kernfunktion vor allem darin besteht, alle Zugriffe des Browsers über den Proxy umzuleiten. Aus diesem Grunde werden sämtliche Bilder, Javascript- und CSS-Dateien ausschließlich über den Proxy aufgerufen oder nachgeladen. Die vielen Proxy-Aufrufe wirken sich allerdings negativ auf die Leistung der aufgerufenen Seite aus, da sich die Anzahl aller HTTP-Anfragen durch diesen Vorgang verdoppelt. Der glype-proxy arbeitet zudem systemunabhängig, d.h. jeder Link und jede Adresse in einer Seite verweist ihrerseits auf den Proxy, bis die glype-sitzung beendet wird, unabhängig davon, welche Webseite der Benutzer gerade aufruft. Die Tatsache, dass die für einen Proxyaufruf infrage kommenden URLs nicht auf bestimmte Domains oder bestimmte Anwendungen eingeschränkt werden können, erschwert das Parsing. Der Parser des glype-proxy ersetzt alle relativen Pfadangaben (z.b. /index.php) in der aufgerufenen Seite durch absolute Pfade, die auf den glype-proxy verweisen. Wenn die im HTML-Code eingebetteten Pfade Syntaxfehler aufweisen, funktioniert die Ersetzung jedoch oft nicht. Noch problematischer ist die Korrektur der Pfade in im HTML-Code eingebettetem Javascript. Da in Javascript-Aufrufen versteckte URL-Pfade nicht einwandfrei ohne einen Javascript-Interpreter erkennbar sind gibt es im glype-proxy einen ebenfalls in PHP implementierten Javascript-Interpreter. Die Funktionalität dieses Interpreters erwies sich allerdings als nicht ausreichend und führt oft dazu, dass die in eine Seite integrierten Javascript-Funktionen und damit auch wesentliche Teile der Webseite nach einem Aufruf über den Proxy nicht mehr nutzbar sind. Die Ursache für Kompatibilitätsprobleme lässt sich bei glype, wie auch bei anderen webbasierten Proxysystemen

74 8. Implementierung meist auf das Umschreiben der URLs zurückführen, das insbesondere bei relativen URL-Angaben problematisch ist. Für den HTTP-Client wurde daher ein neues Proxysystem entwickelt, das einen anderen Ansatz verfolgt. Anstatt alle in der Seite eingebetteten Pfade umzuschreiben, wird auf dem Proxyserver die Verzeichnisstruktur des aufzurufenden Systems emuliert. Somit verweisen alle relativen URLs automatisch auf den Proxyserver und müssen nicht umgeschrieben werden, während bei absoluten Pfadangaben lediglich der Domainname des Systems durch Domainnamen und Pfad des Proxys ersetzt werden muss. Die Simulation nicht existenter Verzeichnisse erfolgt im emigrant-client über mod-rewrite innerhalb einer.htaccess-datei (siehe vorhergehender Absatz). Durch den Verzicht auf das Umschreiben relativer Pfadangaben in der aufgerufenen Seite konnten die meisten Webanwendungen über den Proxy nutzbar gemacht werden, sofern der Anbieter der Webanwendung nicht explizit die Verwendung eines Proxyservers unterbindet. Aufgrund der Tatsache, dass die über den Proxy integrierten Anwendungen ebenso wie deren Basispfade bekannt sind und im emigrant-framework gespeichert werden, wird beim Aufruf einer Anwendung über den Proxyserver diesem lediglich ein Identifier übergeben. Anhand des Identifiers ermittelt der Proxy die aufzurufende URL und die zu ersetzenden absoluten Pfadangaben. Alle Links in der Anwendung, die auf eine URL verweisen, für die kein System konfiguriert wurde, werden nicht abgeändert. Auf diese Weise soll verhindert werden, dass fremde und nicht durch den Administrator genehmigte Anwendungen innerhalb des emigrant-frameworks verwendet werden können. Behandlung unterschiedlicher Medientypen Bei vielen aufgerufenen Medientypen ist es nicht erforderlich, dass sie im ProxyModus nochmals geparst werden. Ein Bild, Videos oder PDF-Dateien werden im HTTP-Client anders behandelt als übertragener HTML-Code, da sie lediglich ByteCode beinhalten und folglich auch nicht den Mechanismus zum Umschreiben der URLs durchlaufen müssen. Diese Mediendateien werden nicht an den emigrant-server weitergereicht, sondern direkt an den Browser des Benutzers zurückgegeben. Dafür erhalten die Medien eine spezielle Kennzeichnung, den sogenannten Content-Type, an dem der Browser feststellen kann, um welchen Medientyp es sich handelt, und wie die Rückgabe interpretiert werden soll (vgl. Kap. 2.2). Dadurch, dass alle Mediendaten nicht mehr direkt, sondern über den emigrant-client aufgerufen werden, würde der Webserver immer den Content-Type text/html des dem emigrant-client zugrundeliegenden PHP-Scriptes übergeben, was zur Folge hätte, dass sämtliche Mediendateien als Text im Browserfenster ausgegeben würden. Aus diesem Grunde übernimmt der HTTP-Client die Vergabe des Content-Type. Wenn sich bereits anhand der aufgerufenen URL bestimmen lässt, dass es sich um ein Bild vom Typ image/jpeg handelt, weil der Dateinahme mit.jpg endet, so wird der Content-Type auf image/jpeg gesetzt und das Bild direkt abgerufen. Wenn aus der URL nicht hervorgeht, um welchen Medientyp es sich handelt, werden die beim Aufruf des Bildes übertragenen HTTP-Header nach Angaben zum Content-Type durchsucht. Sofern auch die HTTP-Header keinen Aufschluss über den Medientyp geben, wird ein sogenannter MIME-Sniffer aktiviert, der in den HTTP-Client implementiert wurde. Dieser liest die ersten 100 Zeichen der zurückgegebenen Datei und sucht nach Merkmalen, die 64

75 8. Implementierung Aufschluss darüber geben, ob es sich um ein Bild, ein Video oder eine PDF-Datei handelt. Der HTTP-Client unterstützt nur die verbreitetsten Medientypen, weitere lassen sich bei Bedarf jedoch relativ einfach hinzufügen. Der Aufruf von Mediendateien muss nur dann über den HTTP-Client erfolgen, wenn die Dateien entweder zugriffsgeschützt und somit nur für einen in der entsprechenden Anwendung angemeldeten Benutzer sichtbar sind oder wenn der Aufruf der Dateien aufgrund einer lokalen Sicherheitsrichtlinie im Browser untersagt wird. Letzteres trifft beispielsweise zu, wenn die Portalseite über ein SSL-Zertifikat geschützt wird, sich die Anwendung aber auf einem Server befindet, der selbst nicht via SSL abgesichert wird. Das Konfigurationsoberfläche des emigrant-frameworks bietet für jede Anwendung die Möglichkeit, das Durchleiten von Mediendateien über den Proxy zu deaktivieren. Wenn der Server der Anwendung performant und die Anbindung ausreichend schnell ist, kann dadurch der Seitenaufbau im Browser erheblich beschleunigt werden. Charset-Encoding Beim Abruf einer Webseite über den HTTP-Client ist es notwendig den Zeichensatz zu ermitteln, bevor die Seite weiter bearbeitet werden kann, damit Umlaute oder Sonderzeichen lesbar bleiben. Handelt es sich dabei um einen anderen Zeichensatz, als UTF8, so wird die Ausgabe des HTTP-Clients in das UTF-8-Format umgewandelt, bevor sie an den emigrant-client zurückgegeben wird. Die Konvertierung wirkt sich zwar negativ auf die Gesamt auf, im Gegenzug kann aber im gesamten emigrant-framework davon ausgegangen werden, dass ausschließlich UTF-8 kodierte Daten zu bearbeiten sind. Wäre dies nicht der Fall, müssten zeichensatzspezifische Anpassungen bei der Kommunikation zwischen Client und Server und zwischen Client und Browser vorgenommen werden. Darüber hinaus verursacht eine spätere Komposition von Widgets mit verschiedenen Zeichensätzen in einer Seite Darstellungsfehler wenn diese nicht vorher auf ein einheitliches Format konvertiert werden. Header-Anweisungen befolgen Wie bereits in Kapitel 2 dargelegt, werden beim Abruf einer Seite wichtige Header-Informationen mitgegeben, die unter Umständen gewisse Aktionen im Webbrowser auslösen. Wenn der Aufruf aber den Umweg über den HTTP-Client nimmt, so erreichen auch die Header-Informationen zunächst den HTTP-Client. Die HeaderDaten werden aus mehreren Gründen nicht an den Browser weitergereicht. Über die HTTP-Header werden Cookies ausgeliefert. Die Cookieverwaltung für das jeweilige aufgerufene System soll jedoch durch das emigrant-framework erfolgen, denn nur so lässt sich ein serverseitiger Login und Logout durchführen. Daher müssen alle Cookies vom HTTP-Client abgefangen werden. Über die HTTP-Header werden Weiterleitungen durchgeführt. 65

76 8. Implementierung Wenn die Weiterleitung direkt an den Browser weitergegeben wird, kann es entweder passieren, dass der Browser in eine Weiterleitungsschleife gerät, da jedesmal erneut der emigrant-client aufgerufen wird, oder der Browser wird direkt auf das System geleitet und umgeht somit den Proxy-Modus. Die HTTP-Header beeinflussen das Caching-Verhalten des Browsers. Da der emigrant-client über einen eigenen speziell für den Einsatzzweck optimierten Cache verfügt, ist eine Modifikation des Caching-Verhaltens durch die aufgerufene Anwendung nicht wünschenswert. In den HTTP-Client wurde ein Parser implementiert, der die Header-Anweisungen ausliest und gegebenenfalls die damit verbundenen Aktionen serverseitig durchführt. Konkret interpretiert der HTTP-Client derzeit die Header-Anweisungen setcookie und Location. Erstere Anweisung erstellt, verändert oder löscht einen Cookieeintrag im serverseitig gespeicherten dem Benutzer zugeordneten Sitzungscontainer. Der Location-Befehl initiiert im HTTP-Client einen neuen HTTP-Request mit einer anderen Ziel-URL. Header-Anweisungen setzen Der HTTP-Client überträgt mit jedem Aufruf einer Anwendung bestimmte Header-Informationen, um Sitzungsdaten zu übermitteln, die Leistung zu steigern, oder die Kompatibilität zu verbessern. Im Wesentlichen werden dabei die Headerinformationen übertragen, die ein normaler Webbrowser beim Aufruf einer Anwendung setzt. Anwendungsspezifische Cookies Die Cookies werden aus dem Sitzungscontainer des Benutzers ausgelesen und in serialisierter Form als Cookie-Header an die Anwendung übertragen. den verwendeten Browser der HTTP-Client gibt sich als Mozilla-kompatibler Browser aus (z.b. Firefox). die Übertragungskomprimierung der HTTP-Client erwartet, sofern dies die aufgerufene Webanwendung unterstützt, eine Rückgabe im gzip-komprimierten Format. Dadurch werden die übertragenen Dateigrößen üblicherweise um 60-85% kleiner, was zu einer deutlichen Verbesserung der Übertragungszeiten führt [35]. die zuletzt besuchte Seite Im Referer-Feld übergibt der Browser der aufgerufenen Webseite die Information, welche Seite er zuletzt besucht hat, respektive von welcher Seite er gekommen ist. Der HTTP-Client trägt als Referer die letzte vom HTTP-Client aufgerufene Seite ein. 66

77 8. Implementierung Inhalte der Seite zwischenspeichern Jeder zusätzliche oder unnötige vom emigrant-client durchgeführte HTTP-Request wirkt sich negativ auf die Leistung einer über das emigrant-framework integrierten Anwendung aus und steigert darüber hinaus die Auslastung des Servers, auf dem der emigrant-client läuft. Aus diesem Grunde wurde ein serverseitiger Caching-Mechanismus als separate Cache-Klasse implementiert. Der Cache und die Verfallsdaten lassen sich individuell für jede Anwendung konfigurieren. Jede Anwendung verfügt über zwei serverseitige Cache-Datenbanken, einen Media-Cache und einen HTMLCache. Zusätzlich wird auch der im Webbrowser integrierte Cache über den emigrantclient gesteuert, womit insgesamt die folgenden Caches verwendet werden: Media-Cache (Bilder, Javascripts, Stylesheets, Videos, PDF-Dateien) Html-Cache (serverseitiges Caching aufgerufener Seiten) Browser-Cache (Caching lokal im Browser des Benutzers) Mittels dieser Caching-Mechanismen konnte die Geschwindigkeit der im emigrantframework integrierten Seiten soweit gesteigert werden, dass eine flüssige Navigation auch mit hohen Besucherzahlen in einem Lernportal umzusetzen ist. Bei einigen Seiten machte sich sogar eine gegenüber der eigentlichen Anwendung reproduzierbar schnellere Ladezeit bemerkbar (siehe Beispiel Abb.20). Abb. 20: Aufruf der Seite mit und ohne Proxy Media-Cache Der Media-Cache umfasst alle Flashmedien, Bilder sowie Javascript und CSS-Dateien. Bei diesen Dateien wird davon ausgegangen, dass Sie sich nur selten ändern, daher werden diese Daten beim Caching mit einem relativ weit in der Zukunft liegenden Verfallsdatum versehen. Jede aufgerufene URL, die zu einer Datei mit einem der genannten Dateiformate führt, wird mit einen eindeutigen Hashwert versehen. Existiert 67

78 8. Implementierung bereits eine Datei mit demselben Hashwert in der Cache-Datenbank, deren Verfallsdatum noch nicht erreicht ist, so wird der Aufruf gar nicht erst durchgeführt, sondern auf den Cache zurückgegriffen. Wenn die Datei sich noch nicht im Cache befindet oder das Verfallsdatum überschritten ist, führt der HTTP-Client den Aufruf aus und speichert oder überschreibt die Datei in der Datenbank. Javascript-Dateien werden vor dem Speichervorgang mit einem Javascript-Kompressor verkleinert, um die Ladezeiten für spätere Abrufe zu verkürzen. Auch CSS-Dateien werden komprimiert, indem Zeilenumbrüche, und überflüssige Leerzeichen entfernt werden, bevor diese gespeichert werden. Die Mediendateien werden nicht an den emigrant-server weitergeleitet, sondern stets direkt an den Browser des Benutzers zurückgegeben, da der Parser-Mechanismus nur für HTML-Quellcode vorgesehen ist. Weil diese Daten nicht mehr verändert werden, ist es auch nicht notwendig, eine im Cache befindliche Datei zuerst über ein PHP-Programm einzulesen und anschließend an den Browser zurückzugeben. Dieser Vorgang benötigt je nach Größe der Datei relativ viel Arbeitsspeicher und verlängert darüber hinaus die Laufzeit, bis die Datei übertragen wurde. Bei Performancetests im emigrant-client hat sich gezeigt, dass die Zeit bis zur Anzeige eines Bildes im Browser bei guter Verbindungsgeschwindigkeit oft geringer ausfällt, wenn das PHP-Script eine Headerweiterleitung auf die Bilddatei zurückgibt, statt die Datei serverseitig aus dem Cache einzulesen und an den Browser auszuliefern. Ein Geschwindigkeitsvorteil macht sich bereits ab sehr kleinen Dateigrößen von 3KB bemerkbar, und das, obwohl der Browser damit für jede Bilddatei einen zweiten HTTP-Request durchführen muss. Wenn eine Webseite nicht mit vielen Bildern versehen ist, oder die Bilder sehr klein sind, lässt sich diese Vorgehensweise aber nicht rechtfertigen. Das Besondere an der Header-Weiterleitung ist jedoch, dass diese mit einem HTTPStatuscode 301 versehen ist. Damit wird dem Webbrowser mitgeteilt, dass es sich um eine dauerhafte Umleitung handelt. Die meisten Webbrowser verfahren dann bei zukünftigen Aufrufen derselben URL so, dass Sie bei einem Aufruf immer zuerst einen Request auf das Weiterleitungsziel machen [36]. Wenn der erste Aufruf eines Bildes aufgrund der Header-Umleitung etwas länger dauert, so gibt es dafür für alle nachfolgenden Aufrufe derselben Datei einen signifikanten Leistungsvorsprung, solange der Browser das neue Weiterleitungsziel verwendet. Html-Cache Der HTML-Cache speichert den Quelltext aller über den emigrant-client aufgerufenen Webseiten. Dieser Cache verfügt im Gegensatz zum Media-Cache über eine relativ kurze Gültigkeit, da die auf der Webseite dargestellten Informationen sich innerhalb weniger Sekunden grundlegend verändern können. Die Funktion des HTML-Caches besteht daher in erster Linie darin, den Seitenaufbau zu beschleunigen und den Server zu entlasten, wenn der Besucher immer wieder dieselben Seiten kurz nacheinander besucht. In einer Lernplattform tritt dieser Fall immer dann auf, wenn mehrere Kursanmeldungen aktiv geschaltet werden. Der Student besucht dann immer wieder dieselben Kursseiten, gleicht Veranstaltungen und Termine gegeneinander ab und navigiert in regelmäßigen Abständen zurück auf die Übersichtsseite. Während der Media-Cache eine gemeinsame Cache-Datenbank für alle Benutzer verwendet und den Hashwert nur 68

79 8. Implementierung anhand der URL generiert, verfügt jeder Benutzer über einen eigenen HTML-Cache mit jeweils eigenen Hashwerten. Im zugriffsgeschützten Bereich einer Anwendung lassen sich die Seiten verschiedener Benutzer meist nicht anhand der URL voneinander trennen. Wenn der Cache nicht zwischen verschiedenen Benutzern unterscheiden würde, könnten Benutzer, die kurz hintereinander dieselbe Seite aufrufen möglicherweise vertrauliche Daten einsehen, die einem anderen Benutzer gehören. Der Cache eines Benutzers wird immer komplett geleert, wenn dieser Benutzer auf einer Webseite ein Formular abschickt, da dann davon auszugehen ist, dass sich die Seiten durch die eingegebenen Daten verändert haben. Wenn sich ein Benutzer in eine Webanwendung einloggt, verfügen oftmals auch alle in der Anwendung verlinkten Unterseiten über eine veränderte Navigation und andere Inhalte. Der Login-Vorgang führt zur Löschung des HTML-Caches, somit bleibt gewährleistet, dass der Benutzer keine Seiten so angezeigt bekommt, wie sie im ausgeloggten Zustand dargestellt wurden. Browser-Cache Der Cache des Webbrowsers ist ebenfalls Teil des Caching-Konzepts im HTTP-Client. Jedesmal wenn der Browser auf eine gecachte Datei zugreift, überträgt der HTTPClient einige Header-Anweisungen an den Browser, die das clientseitige Caching beeinflussen: Last-Modified In das Last-Modified-Feld trägt der HTTP-Client einen Zeitstempel ein, der den letzten Änderungszeitpunkt der auf dem Server gecachten Datei repräsentiert [37]. Bei jedem Aufruf vergleicht der HTTP-Client den im Browser gespeicherten Zeitstempel mit dem Änderungszeitpunkt der Cache-Datei auf dem Server. Wenn die Datei auf dem Server neuer ist, so hat sie sich seit dem letzten Aufruf wahrscheinlich geändert und der Browser erhält die Datei vom Server. Etag Das ETag-Feld enthält eine Prüfsumme der Cachedatei. Anhand dieser Prüfsumme kann geprüft werden, ob der Inhalt der lokal im Webbrowser gecachten Datei identisch mit der auf dem Server gespeicherten Datei ist [37]. Das ETag-Feld ist eine ergänzende Maßnahme zum Last-Modified-Header um zu verhindern, dass eine fehlerhaft übertragene Datei im Cache des Browsers verbleibt, weil die Datei sich serverseitig nicht geändert hat. Wenn die Prüfsummen voneinander abweichen, wird davon ausgegangen, dass die im beim Benutzer gecachte Datei fehlerhaft ist, und der Browser erhält die Anweisung, stattdessen die Datei vom Server zu beziehen. 69

80 8. Implementierung Expires In das Expires-Feld wird ein Zeitpunkt eingetragen, an dem die im Browser gecachte Datei ungültig wird [37]. Ist dieser Zeitpunkt überschritten, wird ein HTTP-Aufruf durchgeführt. Vor Ablauf des Expires-Datum greift der Browser ausschließlich auf den lokalen Browser-Cache zu, und führt keinen HTTPAufruf durch, sofern sich die angefragte Datei im Cache des Browsers befindet. Umgekehrt sorgt das Expires-Feld aber auch dafür, dass der Browser nach Ablauf des Expires-Datums die lokal gecachten Daten ignoriert und einen neuen HTTP-Aufruf startet. Mit Hilfe dieser drei Caching-Mechanismen konnte die Anzahl und Dauer der vom Webbrowser gemachten HTTP-Anfragen drastisch reduziert werden Kommunikation mit dem emigrant-server In den vorhergehenden Abschnitten wurde erläutert, wie der emigrant-client die HTTP-Aufrufe abfängt und selber durchführt. Diese Proxy-Funktionalität dient jedoch nur als Mittel zum Zweck, um die Webseiten selbst optisch und bezüglich Ihres Inhaltes verändern zu können. Das Parsen der Webseiten erfolgt allerdings nicht auf dem emigrant-client selbst, sondern über einen zentralen Server, der die Inhalte aller emigrant-clients im emigrant-framework entgegennimmt und weiterverarbeitet. Die Kommunikation mit dem Server erfolgt über eine Klasse ServerConnector. Für die Datenübertragung wird anstelle eines Webserviceprotokolls ausschließlich HTTPPOST verwendet, da es sich bei den zu übertragenden Daten in der Regel um Klartext handelt. Ein Webservice benötigt durch die Kapselung der Daten in einer XML-Metasprache client- wie auch serverseitig mehr Rechenzeit und eine höhere Bandbreite als das leichtgewichtigere HTTP-Post, daher ist es für diesen Anwendungsbereich ungeeignet. Die Klasse ermöglicht folgende Funktionen: Übertragen der Seite an den Server Empfangen der Seite vom Server Übertragen von Debug-Informationen an den Server Abfragen und Durchführen von Aktionen Abfragen von Profildaten Übertragen der Seite an den Server Die vom emigrant-client empfangene Webseite wird an den Server übermittelt. Dies geschieht mittels eines POST-Requests. Eine Verschlüsselung der übertragenen Daten findet nicht statt, da davon auszugehen ist, dass die Verbindung zwischen den am emigrant-client beteiligten Servern in der Regel innerhalb eines lokalen Netzwerks stattfindet und sich dies negativ auf die Übertragungsgeschwindigkeit auswirken würde. Die Daten werden vor der Übertragung allerdings in ein übertragungssicheres 70

81 8. Implementierung Format konvertiert, damit im HTML-Quelltext enthaltene Sonderzeichen nicht verloren gehen. Empfangen der Seite vom Server Nachdem der Server die an ihn gesendete Seite anhand der dort gespeicherten ParserRegelsätze modifiziert hat, gibt er die veränderte Seite in Form eines Widgets zurück an den emigrant-client. In der ServerConnector-Klasse ist eine noch experimentelle Funktion integriert, die alle im zurückgegebenen Quelltext enthaltenen URLs, die nicht auf den emigrant-client verweisen so abändert, dass sie ebenfalls den ProxyTunnel des emigrant-clients durchlaufen. Dadurch kann erreicht werden, dass ausnahmslos alle vom Browser für die Darstellung einer Seite gemachten HTTP-Requests auf nur eine Domain führen. Dies ist notwendig, wenn über das emigrant-framework mehrere Systeme mit jeweils unterschiedlichen Domains zusammengeführt und die Seiten per SSL verschlüsselt werden sollen, da viele Webbrowser das Nachladen aus fremden Quellen innerhalb einer mit SSL verschlüsselten Seite verbieten [38]. Übertragen von Debug-Informationen an den Server Da das Auffinden und Eliminieren eines Fehlers im emigrant-framework durch die vielen unterschiedlichen Anwendungen und Server sehr kompliziert ist, werden die Debug-Informationen alle zentral auf dem Server chronologisch gesammelt. Tritt ein Fehler auf, wird das Auftreten des Fehlers über die ServerConnector-Klasse an den emigrant-server übertragen. Abfragen von Aktionen Über Aktionen können Vorgänge, wie der Login oder die Registrierung eines Benutzers in einer integrierten Anwendung automatisiert werden. Diese Scripte werden auf dem Server bereitgestellt und bei Bedarf zum emigrant-client übertragen. Immer wenn ein Script ausgeführt werden soll, stellt der emigrant-client über den ServerConnector eine Anfrage an den emigrant-server. Dieser prüft, ob das angefragte Script vorhanden ist und gibt es zurück an den emigrant-client. Abfragen von Profildaten Die Benutzerprofile werden im emigrant-framework zentral verwaltet. Für einige Aktionen, wie den Login eines Benutzers benötigt der emigrant-client den Zugriff auf seine Profildaten. Diese werden ebenfalls über die Server-Connector-Klasse vom emigrant-server abgefragt. Da die Profildaten auch Daten wie das Benutzerpasswort für eine Anwendung enthalten, die keinesfalls in die Hände unbefugter Personen gelangen dürfen, findet zwischen emigrant-client und Server eine verschlüsselte Übertragung statt. Es wird auf ein einfaches symmetrisches XOR-Verschlüsselungsverfahren [39] zurückgegriffen, bei der die eindeutige SitzungsID des Benutzers als Schlüssel fungiert. 71

82 8. Implementierung Rückgabe des emigrant-servers an den Browser übermitteln Die vom emigrant-server übergebene modifizierte Webseite wird an den Browser des Benutzers zurückgegeben. Alle Header, die von der integrierten Anwendung übergeben wurden, werden verworfen. Dies betrifft auch sämtliche Cookies, mit denen eine Anwendung üblicherweise ermittelt, ob ein Benutzer bereits in der Anwendung angemeldet ist. Da die Cookies bereits vom HTTP-Client auf dem Server gespeichert werden, ist eine weitere Speicherung beim Browser des Benutzers nicht mehr notwendig. Stattdessen erhält der Browser ein Cookie emigrant_session mit einer eindeutigen Sitzungs-ID, mit der sich der Benutzer innerhalb des emigrant-frameworks ausweist. Die vom emigrant-client an den Browser gesendeten Header betreffen in erster Linie das Cachingverhalten und sind im Abschnitt Inhalt der Seite zwischenspeichern (Kap.8.1.3) näher beschrieben Aktionen auf dem System ausführen Eine weitere Kernfunktion des emigrant-clients besteht darin, Aktionen automatisiert durchzuführen. Eine Aktion im emigrant-framework ist im Prinzip eine Abfolge von bestimmten Klicks und Eingaben auf ein oder mehreren Webseiten, die serverseitig durchgeführt werden können. Mittels dieser Aktionen können Benutzer automatisch registriert, Profile geändert oder Benutzerlogins in eine Anwendung durchgeführt werden. Die Aktionen sind notwendig, um einen Single Sign-on umzusetzen, ohne dabei in die Systeme oder die Datenbanken der Systeme einzugreifen, in die der Benutzer angemeldet werden soll. Die Aktionen werden auf dem emigrant-server konfiguriert. Wenn eine Aktion in einer Anwendung durchgeführt werden soll, so wird der Name der Aktion dem emigrant-client der jeweiligen Anwendung als Parameter übergeben. Der emigrant-client greift dann nicht wie bei einem normalen Zugriff auf die angefragte Webseite der Anwendung zu, sondern ruft eine Klasse Action auf, die die betreffende Aktion durchführt. In der Regel besteht eine Aktion aus mehreren Befehlen, die hintereinander abgearbeitet werden. Die Befehlsabfolge ist dabei analog zu den Arbeitsschritten, die ein Benutzer für denselben Vorgang durchführen muss. Für nahezu jede Anwendung wird im emigrant-framework eine Aktion Login definiert. Wenn der Benutzer sich selbst einloggt, führt er die Arbeitsschritte Seite aufrufen, auf Login klicken, Benutzerdaten eingeben, auf den Login-Button drücken hintereinander durch. Im emigrant-client passiert etwas ähnliches. Zunächst ruft die Action-Klasse eine Liste der Befehle für die durchzuführende Aktion vom emigrant-server ab, danach werden die Befehle darin der Reihe nach auf die jeweils zuletzt aufgerufene Seite angewendet. Im Einzelnen gibt es folgende Aktions-Befehle: visit_site (Seite aufrufen) click_link (Link folgen) solve_math_captcha (Einfaches Captcha-Verfahren knacken) send_form (Formular absenden) send_form_script (Script vor dem Absenden eines Formulars aufrufen) check_imap ( konto abfragen) 72

83 8. Implementierung visit_site visit_site weist den HTTP-Client an, eine bestimmte URL aufzurufen. Alle nachfolgenden Befehle werden dann innerhalb der neu aufgerufenen Seite durchgeführt. Der Aufruf wird immer unter der jeweiligen gerade aktiven Benutzersitzung mit Hilfe des HTTP-Client durchgeführt, d.h. alle von der Anwendung übertragenen Cookies werden im Sitzungscontainer des Benutzers gespeichert. click_link Diese Funktion extrahiert sämtliche Links innerhalb der zuletzt aufgerufenen Seite. Wird dabei ein Link gefunden, in dem der angegebene Name vorkommt, so ruft der HTTP-Client die dem Link zugeordnete Ziel-URL auf. solve_math_captcha Mittels sogenannter Captchas, kleinen Aufgabenstellungen um Mensch und Maschine voneinander zu unterscheiden, soll es Spammern erschwert werden, automatische Registrierungen in einem System durchzuführen. Da das emigrant-framework seine Benutzer ebenfalls automatisch in den integrierten Anwendungen registriert, wurde die solve_math_captcha Funktion integriert, mit der sich einfache mathematische Captchas automatisch lösen lassen, sofern diese als Text im Quelltext dargestellt werden. Captchas, die als Bilder angezeigt werden, können von der Funktion nicht gelöst werden, da die Funktion keine optische Zeichenerkennung (OCR) enthält. send_form formularname Bei diesem Befehl extrahiert die Action-Klasse das betreffende Formular auf der zuletzt aufgerufenen Seite und darin wiederum sämtliche Formularfelder. Die Formularfelder werden mit Werten gefüllt und das Formular anschließend über die darin definierte Übertragungsmethode durch den HTTP-Client an die Ziel-URL des Formulars übermittelt. Es müssen lediglich die Formulareingaben in der Befehlszeile eingetragen werden, die auch ein Besucher beim Betreten der Seite ausfüllen würde. Alle weiteren Formularfelder und versteckten Felder sowie deren Werte ermittelt die Funktion automatisch und befüllt sie mit den im HTML-Quelltext vorgefundenen default-werten. Mit der send_form-funktion ist es möglich, beliebige Eingabemasken innerhalb einer Webseite auszufüllen und abzuschicken und somit zum Beispiel einen Login oder eine Registrierung durchzuführen. send_form_script Bei Tests mit der im Digicampus eingesetzten Lernumgebung Stud.IP stellte sich heraus, dass der emigrant-client keinen automatischen Login durchführen konnte, da die Anwendung Stud.IP bei einem Login das eingegebene Passwort über ein Javascript im Browser verschlüsselt, bevor das Formular abgesendet wird. Aus diesem Grund wurde der Befehl send_form_script eingeführt. Der Befehl führt vor dem Absenden eines Formulares PHP-Code aus, der die sonst durch das Javascript durchgeführten Funktionen nachbildet. So war es möglich, die Verschlüsselung serverseitig durchzuführen und das Loginformular von Stud.IP korrekt abzusenden. 73

84 8. Implementierung check_imap Die meisten Webanwendungen verlangen, dass der Benutzer eine gültige adresse in sein Profil bei der Registrierung einträgt. Erst nachdem der Benutzer in einer von der Anwendung zugesandten auf einen Bestätigungslink geklickt hat, wird das Benutzerkonto aktiviert und der Benutzer kann sich in das System einloggen. Der Mechanismus dient dazu, um die Eingabe von falschen -adressen zu verhindern und die automatisierte Anmeldung durch Robots zu unterbinden. Der emigrant-client besitzt eine Funktion, mit der eine automatische Registrierung dennoch durchgeführt werden kann, sofern der Administrator des emigrant-frameworks über eine Wildcard -adresse verfügt. Eine Wildcard -adresse lässt beliebige Namensangaben vor einer -adresse zu und bietet einem Domaininhaber die Möglichkeit, s die an eine nicht existente -adresse versendet werden, trotzdem zu empfangen. Wenn die Action-Klasse eine automatische Registrierung durchführen soll, wird bei der Registrierung die -adresse vergeben. Anschließend wird der Befehl check_imap mit der Wildcard durchgeführt. Dieser Befehl ruft das zur Wildcard-Adresse gehörende konto ab, und öffnet die zuletzt eingegangene . In dieser extrahiert die Klasse den ersten Link, der normalerweise der Bestätigungslink ist, und führt auf diesem Link automatisch den click_link Befehl aus. Dadurch wird das registrierte Benutzerkonto auch automatisch freigeschaltet. Wenn der Benutzer die von der Anwendung versandten s ab diesem Zeitpunkt empfangen soll, muss die Aktion Automatische Registrierung im Anschluss an die Freischaltung noch die korrekte -adresse des Benutzers in das Anwendungsprofil eintragen. Mit diesen sechs Befehlen lassen sich nahezu sämtliche Aktionen auf einer Webseite durchführen, die ein Benutzer innerhalb seines Webbrowsers auch ausführen kann Intrusion Detection Die Tatsache, dass sämtliche Kommunikation mit den im emigrant-framework eingebundenen Anwendungen immer den Proxy des emigrant-client durchlaufen muss ermöglicht es, auch potentielle Sicherheitslücken in den Systemen zu korrigieren ohne das System selbst zu verändern. Für alle Anwendungen lässt sich die Intrusion-Detection PHPIDS58 aktivieren. Diese Open Source PHP-Anwendung überwacht alle an die Anwendung übermittelten Daten und untersucht diese anhand von Heuristiken auf potentiell schädliche Inhalte, die auf eine Cross-Site-Scripting Attacke oder eine SQLInjection hinweisen [40]. Das Ergebnis der Untersuchung ist ein Impact-Rating, für das für jede Anwendung ein Maximalwert angegeben werden kann. Wird dieser Wert überschritten, erscheint eine Fehlermeldung (Abb.21), und der Aufruf der Seite wird nicht ausgeführt. Dies erschwert es Angreifern, erfolgreiche Attacken auf das System durchzuführen und kommt der Datensicherheit und damit auch der Privatsphäre des Benutzers zugute

85 8. Implementierung Abb. 21: Fehlermeldung beim Versuch eine Cross-Site-Scripting Attacke durchzuführen 8.2 emigrant-server Der emigrant-server bildet die zentrale Schnittstelle innerhalb des emigrant-frameworks. Zum einen verwaltet er die Benutzerkonten und deren Zuordnung zu den Anwendungsspezifischen Profilen. Zum anderen werden sämtliche inhaltlichen Veränderungen, wie die Generierung der Widgets und deren Komposition über den emigrant-server gesteuert (siehe Anlage II). Darüber hinaus ist ein Debugger im emigrant-server integriert, bei dem alle im emigrant-framework auftretenden Fehlermeldungen an zentraler Stelle gesammelt und ausgegeben werden. Der emigrant-server gliedert sich im Wesentlichen in die drei Module: Parser (Seite verändern, Widget generieren) Account-Manager (Login, Anwendungsprofile, Profilverwaltung) Debugger (zentrale Ausgabe von Fehlermeldungen) Parser Der emigrant-server verfügt über eine Klasse BuildContent, in der die vom emigrantclient empfangenen Seiten geparst und anhand festgelegter Regelsätze verändert, in ihre Bestandteile zerlegt und wieder neu rekombiniert werden um daraus eine Portalseite zu erzeugen. Anwendung eines Parsers Die Klasse BuildContent sucht zunächst, ob für die aufgerufene Anwendung im emigrant-framework bereits Parser konfiguriert sind. Werden keine Parser gefunden, wird die Seite unverändert zurückgegeben. Wenn genau ein Parser gefunden wird, so werden die darin gespeicherten Regelsätze angewendet. Wenn es mehrere Parser gibt, entscheidet die Klasse, welcher Parser die aktuell aufgerufene Seite behandelt. Dazu wird zuerst der Aufbau der URL der aufgerufenen Seite analysiert und daraus neue URLs mit unterschiedlichem Detaillierungsgrad erzeugt (siehe hierzu auch Kap.2.1). Anschließend wird der Reihe nach geprüft, für welche der generierten URLs ein Parser existiert. Detaillierungsgrad 3 (Systemname, URL-Pfad und Query-String identisch): 75

86 8. Implementierung Zuerst wird verifiziert, ob ein Parser existiert, bei dem Systemname, URL-Pfad und Query-String vorgegeben sind und exakt der URL der aktuell aufgerufenen Webseite entsprechen. Ist dies der Fall, werden die Regelsätze in diesem Parser angewendet. Ein solcher Parser wirkt sich nur auf eine ganz bestimmte Seite innerhalb eines Systems mit festgelegtem Query-String aus. Detaillierungsgrad 2 (Systemname und URL-Pfad identisch): Wird kein Parser gefunden, der den höchsten Detaillierungsgrad erfüllt, so wird geprüft, ob ein Parser existiert, bei dem Hostname und URL-Pfad dem der aufgerufenen Webseite entspricht. Auf diese Weise kann ein Parser definiert werden, der nur auf eine bestimmte Seite in einer Anwendung angewendet wird, aber auf die im Query-String gemachten Übergaben keine Rücksicht nimmt. Detaillierungsgrad 1 (Systemname identisch): Existiert für die aktuell aufgerufene Seite kein Parser, wird nach einem systemweiten Parser gesucht. Dieser Parser wirkt sich auf alle Seiten innerhalb einer Anwendung aus, sofern der Name der Anwendung identisch mit dem im Parser konfigurierten Systemnamen ist. Neben den Parsern, deren Ausführung ausschließlich von der aufgerufenen URL abhängig ist, gibt es noch zwei weitere Parser: Immer gültig (default): Der Parser default wirkt sich immer auf alle Seiten aller Systeme aus. Dieser Parser wird auch aufgerufen, wenn ein Parser mit höherem Detaillierungsgrad existiert und ermöglicht es beispielsweise die Darstellung aller Seiten im emigrant-framework in einem einheitlichen Layout zu erzwingen. Widget Im emigrant-framework wird ein Widget ebenfalls mittels eines Parsers generiert, dessen Aufbau identisch zu den URL-spezifischen Parsern ist. Der Aufruf eines Widget-Parsers kann jedoch jederzeit auf jeder Seite im System erzwungen werden, und ist damit unabhängig von der URL der vom Benutzer aufgerufenen Seite. Ein Beispiel: In einer Anwendung gibt es auf jeder Seite einen Bereich, in dem aktuelle Neuigkeiten angezeigt werden. Für diesen Bereich lässt sich ein Widget-Parser mit dem Namen Newsbox definieren, der jeweils die aktuellen Neuigkeiten aus der Seite extrahiert. Wird eine beliebige Seite in dieser Anwendung als Newsbox-Widget aufgerufen, so wird immer nur dieser Bereich der Seite angezeigt (siehe Abb.22). 76

87 8. Implementierung Abb. 22: Erzeugung und Integration eines Widgets newsbox Such-Funktionen Die meisten Funktionen im emigrant-parser basieren auf dem Suchen, Eingrenzen und Ermitteln sowie Extrahieren oder Ersetzen von Code-Blöcken, Werten oder Textbausteinen im HTML-Quelltext der aufgerufenen Seite. Das korrekte Auffinden bestimmter Merkmale im Quelltext ist ein essentieller Bestandteil der im Parser verankerten Regelsätze, da der Quelltext neben der URL der Seite die einzige Datenquelle darstellt, auf die das emigrant-framework zugreifen kann. Aus dem Quelltext müssen hinreichend viele eindeutige Informationen gewonnen werden, um ein fehlerfreies Regelwerk definieren zu können, mittels dessen die Seite neu zusammengesetzt und mit Bestandteilen anderer Seiten aus anderen Systemen rekombiniert werden kann. Die Suche bestimmter Merkmale im Quelltext orientiert sich prinzipiell an den regulären Ausdrücken. Für eine einfach und leicht verständliche Definition und Administration von Parserregeln erwiesen sich reguläre Ausdrücke jedoch als zu komplex, daher wurden zwei Mechanismen eingeführt, mit denen der Administrator den im Quelltext gesuchten Bereich beschreiben kann, ohne ein tiefgreifendes Verständnis der regulären Ausdrücke zu besitzen. DOM-Selector Mit dem DOM-Selector lassen sich HTML-Tags im Quelltext anhand ihrer Eigenschaften auswählen. Der Selector erhält eine Eingabe in der Form div;id=content und findet in HTML-Code zum Beispiel <div name= inhalt id= content ><div id= innercontent >Text</div> </div> Diese Funktion setzt allerdings voraus, dass der HTML-Tag mit den dargestellten Eigenschaften im Quelltext eindeutig ist und nur einmal vorkommt. Bei barrierefreien Webseiten mit CSS-Layout werden die Layout-Container im HTML-Quellcode in der Regel mit eindeutigen Kennungen versehen. Daher eignen sich barrierefreie Webseiten [41] auch besonders gut für die Integration mit dem Emigrant-Framework. 77

88 8. Implementierung Suchmusterverfahren Wenn sich ein Element nicht über einen HTML-Tag mit eindeutiger Kennung herausfinden lässt, kann dies alternativ über ein Suchmusterverfahren erfolgen. Das Prinzip besteht darin zunächst einen Suchbereichs anhand von zwei eindeutigen Merkmalen zu beschreiben und die Suche dann innerhalb des eingeschränkten Bereiches durchzuführen. Innerhalb des eingeschränkten Suchbereiches wird das zu suchende Element durch einen Anfangs- und ein Endpunkt beschrieben. Zusätzlich kann festgelegt werden, ob der Endpunkt in diesem Bereich von links oder von rechts kommend gesucht werden soll. Das Suchmuster besteht aus einer Eingabe der Form: <table id(any)<td>(max)</td>(any)</table> (ANY) stellt eine Wildcard dar und beschreibt eine beliebig lange nicht näher bekannte Textstelle. (MAX) bedeutet, dass der zwischen den Anfangs- und Endpunkt gesuchte Bereich größtmöglich sein soll und startet die Suche von rechts kommend. (MIN) findet einen möglichst kleinen Bereich findet und führt die Suche von links kommend durch. Quelltext <table><tr><td></td></tr></table><table id="x"><tr><td>zelle 1</td><td>Zelle 2</td></tr></table> Suchmuster MAX <table id(any)<td>(max)</td>(any)</table> Ergebnis <td>zelle 1</td><td>Zelle 2</td> Suchmuster MIN <table id(any)<td>(min)</td>(any)</table> Ergebnis <td>zelle 1</td> Tab. 2: Beispiele für das Suchmusterverfahren Funktionen zur Integration von Webseiten und Widgets Das Auffinden bestimmter Bereiche innerhalb der aufgerufenen Webseite dient dazu, diese Bereiche zu ersetzen, zu erweitern oder darin Teile anderer Webseiten anzuzeigen. Innerhalb der Parser können die Aufrufe und das Einfügen von anderen Webseiten oder Widgets auf drei unterschiedliche Arten erfolgen: die Seite wird serverseitig eingebunden: In diesem Fall ruft der emigrant-server die andere Seite auf. Der dabei zurückgegebene HTML-Quelltext wird sofort in die dafür vorgesehene Stelle eingefügt. Der Parser verfügt unmittelbar über den veränderten Quellcode und kann diesen weiter bearbeiten. Die serverseitige Erzeugung ermöglicht es, das Layout der gesamten Seite zu überarbeiten und Fehler zu erkennen, bevor die Portalseite an den Benutzer zurückgegeben wird. Der Browser des Benutzers macht nur einen HTTP-Aufruf und erhält als Rückgabe die gesamte fertige Portalseite. Durch diese Vorgehensweise wird jedoch das Intervall zwischen 78

89 8. Implementierung dem Aufruf einer Seite und der Anzeige im Browser des Benutzers verlängert und die technische Komplexität sowie das schwierige Debugging der serverseitigen Aufrufe erschweren den Integrationsprozess. Die Seite wird via AJAX eingebunden In diesem Fall werden die Teile der Portalseite, die nicht aus der aufgerufenen Anwendung entnommen wurden, erst im Browser des Benutzers nachgeladen. Der Browser führt einen weiteren HTTP-Aufruf durch und fügt die Rückgabe an der dafür vorgesehenen Stelle in die Portalseite ein. Im Gegensatz zur serverseitigen Integration besitzt der Parser keine Kenntnis darüber, wie die fertige Portalseite aussieht und kann daher auch keine Änderungen durchführen, die sich gleichzeitig auf mehrere eingebundene Widgets auswirken. Die Integration via AJAX hat allerdings den Vorteil, dass der Benutzer die eigentliche Portalseite sehr viel schneller angezeigt bekommt und lediglich die Widgets aufgrund des Nachladeprozesses zeitlich verzögert angezeigt werden. Die Seite wird via iframe eingebunden Diese Funktion verhält sich ähnlich wie die vorhergehende, nur mit dem Unterschied, dass die nachgeladene Seite in einem iframe und damit in einer separaten Browser-Instanz nachgeladen wird. Die Nutzung eines iframe ist notwendig, wenn zwischen den Systemen verschiedene Domains zum Einsatz kommen und ein Nachladen via AJAX nicht möglich ist. Der Nachteil dieser Technik besteht jedoch darin, dass die im iframe nachgeladenen Webseiten eigene Stylesheets, Javascripts und Header-Daten referenzieren, die ebenfalls geladen werden müssen, bevor eine Anzeige erfolgt. Neben der verlängerten Übertragungszeit verursachen die iframes auch einen erhöhten Speicherbedarf im Webbrowser. Darüber hinaus führt eine Integration über iframes oft zu unerwünschten Scrollverhalten der Webseite. Regelsätze Ein Parser kann eine beliebige Anzahl von Regelsätzen enthalten, die hintereinander ausgeführt werden. Jeder Regelsatz gliedert sich in die fünf Bestandteile Gültigkeit, Bedingungen, Aktionen, Anzeigen sowie Suchen und Ersetzen. Gültigkeit Die Regelsätze in einem Parser verfügen über eine Einstellung Gültigkeit. Diese legt fest, ob ein bestimmter Regelsatz ausgeführt werden soll, und knüpft dessen Ausführung an Bedingungen, die teilweise oder vollständig erfüllt sein müssen. Ist dies nicht der Fall, wird der betreffende Regelsatz ignoriert und mit dem nachfolgendem Regelsatz fortgefahren. Des weiteren kann die Ausführung eines Regelsatzes an ein Zugriffsrecht des Benutzers gebunden sein. Nur wenn der angemeldete Benutzer in seiner aktuellen Benutzerrolle dieses Zugriffsrecht besitzt, wird der Regelsatz angewandt. 79

90 8. Implementierung Bedingungen Wird die Gültigkeit eines Regelsatzes an Bedingungen geknüpft, kann der Administrator wählen, welche Bedingungen erfüllt sein müssen, damit der Regelsatz ausgeführt wird. Zur Auswahl stehen folgende Bedingungen: URL-Zeile enthält String Wenn in der im Browser eingegebenen Webadresse ein bestimmter String vorkommt, gilt die Bedingung als erfüllt. Quelltext enthält String Wenn im Quelltext der aufgerufenen Seite ein bestimmter String vorkommt, gilt die Bedingung als erfüllt. PHP-Script gibt true aus Ob die Bedingung erfüllt ist, wird durch ein separates PHP-Programm ermittelt, dass zur Laufzeit in den Parser-Prozess eingebunden wird. Suchstring existiert Es wird mit dem zuvor erläuterten Suchmusterverfahren ein Bereich im Quelltext eingegrenzt und die gesuchte Passage zurückgegeben. Nur wenn das Ergebnis nicht leer ist, gilt die Bedingung als erfüllt. Suchstring hat bestimmten Wert Die gesuchte Textstelle wird mit einem in der Bedingung angegebenen String verglichen. Nur wenn die beiden Werte identisch sind, ist die Bedingung erfüllt. Quelltext enthält HTML-Tag Die Bedingung greift auf den im vorhergehenden Abschnitt beschriebenen DOM-Selector zurück und ermittelt die Existenz eines bestimmten HTMLTags. Nur wenn der DOM-Selector ein Ergebnis liefert, gilt auch die Bedingung als erfüllt. Quelltext enthält HTML-Tag mit bestimmtem Wert Diese Bedingung gilt nur dann als erfüllt, wenn der DOM-Selector ein Ergebnis zurückliefert und dieses identisch zu einem in der Bedingung angegebenen String ist. 80

91 8. Implementierung Aktionen Ein Regelsatz kann, sofern die festgelegten Bedingungen erfüllt sind, in einem beliebigen im emigrant-framework integrierten System eine Aktion ausführen, die z.b. den automatischen Login eines Benutzers erzwingt oder automatisch die Profildaten aktualisiert, wenn diese veraltet sind. Bei der Konfiguration einer Aktion sind drei Angaben zu machen: Das System, in dem die Aktion ausgeführt werden soll Die Seite, auf der die Aktion ausgeführt werden soll Der Name der Aktion, die ausgeführt werden soll Aufbau und Funktionsweise einer Aktion sind im vorhergehenden Kapitel näher beschrieben. Anzeigen Die Anzeigen-Funktionen definieren, was beim Aufruf einer Webseite im Browser des Benutzers angezeigt werden soll. Es lassen sich folgende Komponenten anzeigen: Ein Teilbereich der aufgerufenen Webseite Wenn ein Teilbereich der aufgerufenen Seite angezeigt werden soll, wird der Bereich wahlweise über das weiter oben genannte Suchmusterverfahren oder den DOM-Selector extrahiert. Des weiteren kann angegeben werden, ob den Suchstring umschließende HTML-Tags angezeigt oder verworfen werden sollen. Alle nachfolgenden Regelsätze berücksichtigen nach Anwendung der Anzeigen-Regel nur noch den angezeigten Teilbereich, an Stelle des gesamten Seiten-Quelltextes. Eine beliebige andere Webseite Anstelle der aufgerufenen Seite wird die Ausgabe einer andere Webseite dargestellt. Es muss sich dabei um eine beliebige Unterseite von einem der im emigrant-framework eingebundenen Systeme handeln. Wenn eine andere Seite serverseitig aufgerufen wird, arbeiten alle nachfolgenden Regelsätze mit dem HTML-Code der anderen Seite. Ein Widget Es wird eine beliebige Webseite einer im emigrant-framework eingebundenen Anwendung mit einem zusätzlichen Widget-Parameter aufgerufen. Das generierte Widget wird zurückgegeben und angezeigt. Wenn der Aufruf serverseitig erfolgt, arbeiten alle nachfolgenden Regelsätze der vom Benutzer aufgerufenen Seite auf dem Widget-Code, statt auf dem Quelltext der aufgerufenen Seite. 81

92 8. Implementierung Suchen und Ersetzen Die Suchen-Ersetzen Funktion greift auf die Suchfunktionen DOM-Selector und Suchmusterverfahren zurück, findet Bereiche innerhalb einer Webseite und ersetzt diese durch etwas anderes. Gesucht werden kann im Quelltext nach folgenden Vorkommnissen: ein String oder Marker sucht nach dem Vorkommen eines Strings oder eines Markers im Quelltext der aufgerufenen Webseite. Die Marker sind im emigrant-framework mit layoutspezifischen Funktionen einer separaten Templateengine verknüpft. Die Marker können vor der Ausführung der Templateengine durch die Regelsätze überschrieben werden, so dass die Temlateengine diese nicht mehr verarbeitet. innerer Bereich eines HTML-Tags (innerhtml) Suche nach im Quelltext liefert äußerer Bereich eines HTML-Tags (outerhtml) Suche nach im Quelltext liefert div;id=content <div id= content >Text</div> <div id= content >Text</div> innerer Bereich eines Suchmusters Suche nach im Quelltext liefert div;id=content <div id= content >Text</div> Text <table (ANY)<td>(MAX)</td>(ANY)</table> <table (ANY)<td>Text</td>(ANY)</table> Text äußerer Bereich eines Suchmusters Suche nach im Quelltext liefert <table (ANY)<td>(MAX)</td>(ANY)</table> <table (ANY)<td>Text</td>(ANY)</table> <td>text</td> In die gefunden Bereiche können andere Elemente eingefügt werden. Wird dabei auf eine weitere Webseite zugegriffen, so kann die Integration serverseitig oder clientseitig erfolgen. Mögliche Elemente, die sich einfügen lassen, sind: ein String die Rückgabe eines PHP-Programmes eine Webseite aus einer anderen Anwendung ein Widget 82

93 8. Implementierung Templateengine Der emigrant-server verwendet das Template-System Smarty59, um das Layout der aufgerufenen Seite oder das der Widgets zu verändern. Die Templateengine bildet die Präsentationsschicht im emigrant-framework. Durch sogenannte Templates können Layoutkomponenten unabhängig vom Quellcode der Anwendungen definiert und bearbeitet werden. Durch die Trennung von Layout und Programmkomponenten bleibt gewährleistet, dass die Funktionalität einer Portalseite auch bei Änderungen des Designs weitgehend erhalten bleibt. Die Templateengine durchläuft nach der Ausführung aller Regelsätze den Inhalt erneut und ersetzt darin vorhandene Marker. Ein Marker ist ein String der Form {$markername} und folgt der Syntax der Smarty-Template Engine. Marker können sowohl im Inhalt der aufgerufenen Seite, wie auch in Templates und Subtemplates vorkommen. Für jeden Parser kann ein Haupttemplate angegeben werden, von dem ausgehend die Templatengine das Layout der Portalseite erstellt, indem beim Antreffen eines Markers eine dem Marker zugeordnete Funktion aufgerufen und die Rückgabe der Funktion an die Stelle des Markers gesetzt wird. Die möglichen Funktionen sind: Einfügen eines Subtemplates Einfügen eines PHP-Programmes Darüber hinaus sind im System einige Marker bereits vordefiniert, die den Aufruf bestimmter Funktionen auslösen, ohne dass dies konfiguriert werden muss. Der Marker {$content} in einem Template bewirkt beispielsweise das Einfügen des Inhalts der aufgerufenen Seite nach dem Durchlaufen der Regelsätze an der Position des Markers. Marker, die im Quelltext der aufgerufenen Seite gefunden werden, können auch mit anderen Funktionen belegt werden, indem die Marker durch einen Regelsatz bearbeitet werden, bevor diese die Templateengine passieren Account-Manager Der Account-Manager verwaltet alle aktiven Benutzersitzungen, den Login, die Registrierung sowie die Rollen- und Rechtezuordnung der Benutzer im emigrant-framework. Profile Benutzerdaten, die in allen Anwendungen und sämtlichen Benutzerrollen innerhalb des emigrant-frameworks identisch sind, werden in einem zentralen Profil gespeichert (vgl. Kap.6.3.2). Je nach Benutzerrolle kann das zentrale Profil abweichende Datenfelder beinhalten. Im zentralen Benutzerprofil wird unter anderem der Benutzername, eine systeminterne dem Benutzer zugeordnete -adresse und das verschlüsselte Passwort für den Zugang zum emigrant-framework gespeichert. Der zentrale Benutzername ist ebenso wie die systeminterne -adresse vorgegeben und kann vom

94 8. Implementierung Benutzer selbst nicht verändert werden. Alle anderen Datenfelder im zentralen Profil kann der Benutzer einsehen und verändern. Das zentrale Profil enthält in der Regel Benutzerinformationen, wie Vorname, Nachname, Adresse und des Benutzers. Benutzerdaten, die nur für eine bestimmte Anwendung relevant sind, werden in sogenannten Anwendungsprofilen gespeichert. Für jede Benutzerrolle innerhalb einer Anwendung können separate Anwendungsprofile (vgl. Kap.6.3.3) mit anderen Datenfeldern vergeben werden. Daneben gibt es auch für jede Anwendung ein zentrales Profil, dessen Datenfelder unabhängig von der jeweiligen Rolle des Benutzers sind. Jedes Datenfeld in einem Anwendungsprofil kann entweder für den Benutzer sicht- und editierbar gemacht, automatisch mit Zufallsdaten versehen, oder mit einem Datenfeld aus dem globalen Benutzerprofil verknüpft werden. In letzterem Fall wird zum Beispiel eine Änderung der Adressdaten im zentralen Benutzerprofil automatisch in das Profil einer Anwendung übertragen. Das veränderte Profil führt wiederum zur Ausführung einer Aktion im emigrant-client der Anwendung, die die geänderten Daten in das dort hinterlegte Benutzerprofil überträgt. In jedem Profil können drei unterschiedliche Aktionen konfiguriert werden: Aktion zum Einloggen In dieser Aktion ist festgelegt, welche Formulareingaben für den Login in eine Anwendung gemacht werden müssen. Die Ausführung dieser Aktion in einer Anwendung über den emigrant-client bewirkt, dass der aktuelle Benutzer in der Anwendung angemeldet wird, sofern er darin registriert ist. Den Benutzernamen und das Passwort für die Anwendung erhält der emigrant-client vom emigrant-server. Aktion zum Registrieren Diese Aktion registriert einen Benutzer automatisch in einer Anwendung und schaltet den Benutzer anschließend frei. Der emigrant-client erhält vom emigrant-server automatisch die für die Registrierung benötigten Benutzerdaten. Der Benutzername und das Passwort für die Anwendung wird dabei automatisch erzeugt, während Vorname, Nachname und Adressdaten aus dem zentralen oder dem Anwendungsspezifischen Profil übernommen werden. Für den Zweck der Freischaltung wird temporär eine vom emigrant-server generierte -adresse verwendet, an die die Anwendung eine senden kann. Wenn die etwaige Freischalt unmittelbar nach der Registrierung im Postfach eintrifft, wird sofort eine Freischaltung vorgenommen. Aktion zum Profilupdate Mit dieser Aktion werden Datenfelder aus dem globalen oder einem Anwendungsspezifischem Profil in die jeweilige Anwendung übertragen. Bei der Durchführung der Aktion über den emigrant-client erfragt dieser beim emigrant-server die für das Update benötigten Profildaten. Der emigrantclient ruft dann die Seite zur Profilverwaltung innerhalb der Anwendung auf und befüllt die darin angezeigten Formulare mit den Daten aus dem emigrantprofil. 84

95 8. Implementierung Anonymisierte Benutzerdaten Im emigrant-framework ist eine Klasse RandomProfileGenerator integriert, mit der sich zufällige Benutzerprofile erstellen lassen. Mit den zufälligen Benutzerprofilen können Benutzer in eine Anwendung eingetragen werden, ohne dabei Ihre Identität preiszugeben. Damit die Registrierung eines Zufallsprofils in einer Anwendung ebenso unproblematisch verläuft, wie die Registrierung eines echten Benutzers, wurde bei der Implementierung auf folgende Kriterien Wert gelegt: Plausibilität Ein zufallsgeneriertes Benutzerprofil ist auf den ersten Blick nicht vom Profil eines echten Nutzers zu unterscheiden. Für die Erstellung eines Zufallsprofils wird auf eine Liste von jeweils circa männlichen und ebenso vielen weiblichen Vornamen zurückgegriffen. Auch für Städte und Postleitzahlen wird auf eine Datenbank mit real existierenden Datensätzen zurückgegriffen. Lediglich der Nachname und die Strasse werden durch zufällige Kombination bestimmter Silben und Wörter generiert. Eindeutigkeit Ein zufällig generierter Benutzer in einer Anwendung muss vom emigrant-framework eindeutig dem echten Benutzerprofil zugeordnet werden können, damit im emigrant-framework angemeldete Benutzer den echten Benutzer sehen und eine semantische Verknüpfung nutzerbezogener Daten möglich bleibt. Die Eindeutigkeit wird vor allem durch die hohe Anzahl möglicher Vorname-Nachname-Kombinationen erreicht. So ist es möglich, für jeden Vornamen, Nachnamen oder Benutzernamen innerhalb des Portals ein eindeutiges anonymisiertes Äquivalent zu finden. Login im emigrant-framework Wenn sich ein Benutzer im emigrant-framework einloggt, übernimmt das System im Hintergrund den Login des Benutzers in die integrierten Anwendungen. In einer zentralen Datenbank speichert das emigrant-framework, welcher Benutzer in welchen Anwendungen registriert ist, welche Rollen er dort ausübt und welche Zugangsdaten er in der jeweiligen Anwendung besitzt. Für jede der integrierten Anwendungen prüft der Account-Manager zunächst, ob in der Datenbank für den angemeldeten Benutzer ein Eintrag mit Zugangsdaten hinterlegt ist. Ist dies der Fall, führt der Account-Manager in dem entsprechenden System die Aktion Benutzerlogin durch. Jeder an dem LoginProzess beteiligte emigrant-client vergibt an den Browser des Benutzers ein Sitzungscookie. Dieses Cookie enthält eine eindeutige Sitzungs-ID, die in einer zentralen Sitzungsdatenbank hinterlegt wird, und anhand der verifiziert werden kann, ob ein Benutzer im emigrant-framework angemeldet ist. Wenn der Benutzer in einer Anwendung noch keine Zugangsdaten besitzt, erstellt der Account-Manager neue Zugangsdaten und führt für die Anwendung die Aktion Registrierung durch. Anschließend wird die Aktion Benutzerlogin durchgeführt. Der Benutzer erhält eine 85

96 8. Implementierung Benachrichtigung, dass er in einem neuen System registriert wurde. Wenn der Login in die Anwendung nicht erfolgreich war, kann dies daran liegen, dass keine Freischaltung stattgefunden hat. Aus diesem Grunde wird bei der Konfiguration einer Anwendung in der Regel eine weitere Aktion eingeführt: Aktion zum Freischalten Die Aktion definiert ausschließlich den Freischaltungsprozess. Wenn die Freischaltung nach der Registrierung nicht klappt, weil das Versenden der Freischalt- einige Zeit beansprucht, kann die Freischaltung zu einem späteren Zeitpunkt erneut angestoßen werden. Bei der Freischaltung wird eine dem Benutzer temporär zugeordnete -adresse abgerufen, neu eingegangene s nach Links durchsucht, und ein festgelegter Link in einer aufgerufen. Dabei handelt es sich in aller Regel um den Aktivierungslink, der eine Freischaltung des Benutzers in der entsprechenden Anwendung bewirkt. Der Aufruf dieser Aktion erfolgt nicht durch den Account-Manager, da der AccountManager nicht darüber Bescheid weiß, ob ein Benutzer in einer Anwendung tatsächlich angemeldet ist. Der Account-Manager kann lediglich einen Login initiieren. Die Prüfung, ob ein Benutzer tatsächlich eingeloggt ist, muss daher über die zuvor erläuterten Regelsätze erfolgen, indem beispielsweise die Ausgabe untersucht wird, ob ein Logout-Button vorhanden ist. Ist dies nicht der Fall, kann die Aktion Freischalten gefolgt von einem erneuten Login durchgeführt werden. Nach dem ersten erfolgreichen Login in eine Anwendung werden die Benutzerdaten aus dem zentralen oder dem Anwendungsspezifischen Profil auf die Anwendung übertragen, indem die Aktion Profilupdate durchgeführt wird. Die für die Registrierung verwendete temporäre -adresse wird bei diesem Schritt durch die echte -adresse des Benutzers ersetzt. Benutzer- und Rollenwechsel Einem Benutzer im emigrant-framework können mehrere Benutzer in einer integrierten Anwendung zugeordnet werden. Das ist notwendig, da in einem Lernportal Benutzer oftmals in unterschiedlichen Rollen auftreten, zum einen als Student, zum anderen aber auch als Lehrender oder studentischer Mitarbeiter in der Verwaltung. Je nachdem, welche Rolle der Benutzer gerade ausübt, unterscheiden sich auch die im Lernportal integrierten Anwendungen hinsichtlich ihrer Funktionen und der dazugehörigen Benutzeroberfläche. Das im Lernportal Digicampus integrierte LMS Stud.IP erlaubt für jeden Benutzer nur eine Benutzerrolle, daher benötigt ein Benutzer, der mehrere Rollen ausübt darin mehrere Benutzerkonten. Den Wechsel zwischen den Benutzerkonten einer integrierten Anwendung kann der Benutzer im emigrant-framework über ein Dropdown-Menü (Abb.23) vornehmen. Das DropdownMenü zeigt jedoch nicht die Namen der Benutzerkonten der im emigrant-framework eingebundenen Anwendungen, sondern die dem Benutzer zugeordneten globalen Benutzer-Rollen. Beispiele für Benutzerrollen in einem Lernportal sind Student, Dozent oder Administrator. Die Benutzerrollen sind wiederum mit den Benutzerkonten der eingebundenen Anwendungen verknüpft. Wechselt ein Benutzer seine Benutzer86

97 8. Implementierung rolle, so wird geprüft, welches Benutzerkonto dem Benutzer in welcher Anwendung für die gewählte Rolle zugeordnet ist, und danach ein Login mit den veränderten Kontodaten in den integrierten Anwendungen durchgeführt. Ein Benutzer Jonas, der gleichzeitig Dozent und Student ist, kann über das Dropdown-Menü zwischen diesen beiden Rollen wechseln. Wechselt er von der Studenten- in die Dozenten-Rolle, so wird das Benutzerkonto Jonas-Student im LMS Stud.IP abgemeldet und stattdessen der Benutzer Jonas-Dozent angemeldet. In einer anderen Anwendung, in der keine Rollenunterscheidung notwendig ist, bleibt der Benutzer hingegen als Jonas eingeloggt. Auf diese Weise wird dem Benutzer der Eindruck vermittelt, dass er nur ein einziges Benutzerkonto besitzt, die vielen verschiedenen Benutzerkonten der integrierten Anwendungen sowie deren Zugangsdaten bleiben hingegen im Verborgenen. Abb. 23: Dropdown-Menü zum schnellen Benutzer-Rollenwechsel Debugger Der Debugger dient dazu, den Administrator beim Einrichten eines Portalsystems mit dem emigrant-framework zu unterstützen und Fehlerquellen aufzudecken. Ein Portalsystem wird mit steigender Zahl von Anwendungen, Regelsätzen und Abhängigkeiten zunehmend komplexer. Tritt in einer der Komponenten Anwendung, emigrant-client und emigrant-server ein Fehler auf, so ist es nicht ohne weiteres möglich, herauszufinden, in welcher der Komponenten die Ursache darin liegt, da die Ausgaben der Anwendungen ebenso wie die darin auftretende Fehler an den emigrant-server weitergereicht werden, dort das Parsing durchlaufen und wiederum weitere Fehler infolge der veränderten Ausgabe verursachen können, bevor sie zurück an den Client geschickt werden. Einige im Verlauf der Implementierung häufig beobachtete Fehler sind in Tab. 3 gezeigt: Name Äußert sich in Fehler Weiterleitungs-Schleife Keine Anzeige im Browser Anwendung: Die Anwendung selbst initiiert eine Weiterleitung, z.b. aufgrund falscher oder verlorengegangener Sitzungsdaten. Endlose Ladezeit Absturz des Webservers Emigrant-Client: Header-Weiterleitungen werden vom HTTP -Client falsch interpretiert der HTTP-Client ruft immer dieselbe Seite der Anwendung auf. Der emigrant-client ruft fortlaufend sich selbst mit den gleichen Parametern auf. Emigrant-Server: Eine Parser-Regel mit einer Weiterleitung führt zur erneuten Ausführung derselben Parser-Regel. 87

98 8. Implementierung Fehlende/fehlerhafte Sitzungs- Benutzer bleibt in einer Anwendaten dung nicht eingeloggt Eine Formulareingabe in einer Anwendung wird nicht verarbeitet Benutzer wird sporadisch in einer Anwendung ausgeloggt Anwendung: Die Anwendung beendet die Benutzersitzung, beispielsweise wegen längerer Inaktivität. Emigrant-Client: Die im emigrant-client hinterlegte Sitzungs-ID entspricht nicht der im Browser gespeicherten Sitzungs-ID Es erscheinen Berechtigungsfehler Der Benutzer ist mit einer anderen Sitzungsin einer Anwendung -ID bereits in der betreffenden Anwendung eingeloggt Eine abgelaufene Benutzer-Sitzung wurde nicht erneuert Emigrant-Server: Aktion für den Benutzer-Login fehlerhaft oder nicht durchgeführt falsche Sitzungsdaten im Account-Manager für die betreffende Anwendung hinterlegt. Fehlerhafte Darstellung Das Layout der Seite ist unvollständig Stylesheets werden nicht angewendet. Javascript-Fehler Bilder werden nicht angezeigt Browser: Im Browser-Cache hinterlegte Daten sind fehlerhaft Emigrant-Client: Bild-URLs werden nicht korrekt umgeschrieben und verweisen auf eine nicht-existente Datei Im emigrant-client gecachte Bilder/Videos/ Stylesheets werden falsch/fehlerhaft/nicht gecacht. Der MIME-Type einer URL wird nicht korrekt erkannt und als Text interpretiert Emigrant-Server: Weitere eingebundene Stylesheets beeinflussen sich gegenseitig in der Darstellung Es werden Teile einer Seite extrahiert/eingebunden, die HTML-Tags enthalten, die nicht geschlossen werden Widgets werden an falscher Stelle eingebunden oder falsch formatiert Javascripts sind inkompatibel zur im emigrant-framework verwendeten JQuery-Biblliothek Fehlerhafte Parser-Regeln Portalseiten sind leer Widgets werden nicht angezeigt Formulareingaben funktionieren auf einigen Seiten nicht falsches Widget wird eingebunden es wird auf eine falsche Seite weitergeleitet. Emigrant-Server: Eine oder mehrere Parser-Regelsätze werden falsch interpretiert oder sind fehlerhaft implementiert. Es wird der falsche Parser angewendet. Die Konfigurationsdatei eines Parsers ist fehlerhaft. Bei der Erstellung und Konfiguration der Parser-Regeln wurden Fehler gemacht Tab. 3: häufige Fehlerquellen Bei den beobachteten Fehlern handelt es sich meist um Konfigurationsfehler bei der Erstellung von Parserregeln, oder um Implementierungsfehler im emigrantframework. Bereits im Laufe der Implementierung war es daher notwendig, effiziente Mechanismen für die Lokalisierung eines Fehlers bereitzustellen, um eine zielführende Fehlersuche und Behebung möglich zu machen. Daher wurde im emigrant-framework ein zentraler Debugger implementiert, der chronologisch die im emigrant-framework 88

99 8. Implementierung auftretenden Ereignisse und durchgeführten Aktionen protokolliert. Der Debugmodus kann für jede integrierte Anwendung separat aktiviert werden um den Informationsfluss übersichtlich zu gestalten und keinen unnötigen Performanceverlust herbeizuführen. Für jede Anwendung mit aktivierten Debugmodus sendet der zugehörige emigrant-client detaillierte Informationen über jeden darin ablaufenden Vorgang an den Debugger. Ebenso sendet auch der emigrant-server selbst Debuginformationen an den Debugger. Der Debugger versieht alle Meldungen mit einer Zeitmarke und zeigt sie nach der Reihenfolge ihres Eintreffens in nahezu Echtzeit in einem separaten Ausgabefenster an. Jede eintreffene Debugmeldung wird im Debugger ähnlich wie bei einem Livechat unmittelbar unter der vorhergehenden Meldung angezeigt, ohne dass der Debugger neu aufgerufen werden muss. Die Debugmeldungen werden, wie in Abb.24 zu sehen, thematisch gegliedert und in unterschiedlichen Farben dargestellt. Wenn der Debug-Modus aktiviert ist, wird beim Durchlaufen der Parser-Regelsätze und beim Durchführen einer Aktion jeder Zwischenschritt der veränderten Seite gespeichert und im Debugger angezeigt. So ist anhand der Debugausgabe sofort ersichtlich, welcher Regelsatz fehlerhaft ist oder ob eine Formulareingabe korrekt durchgeführt wurde. Abb. 24: Ausgabe des integrierten Debuggers 8.3 Grafische Benutzeroberfläche Im emigrant-framework wurde eine Klasse JQueryUI implementiert, mit der sich leistungsfähige dynamische Benutzerschnittstellen darstellen lassen. Die Klasse wird im emigrant-framework genutzt, um eine einfache grafische Konfiguration der Anwendungen, Benutzer-Rollen und Parser zu ermöglichen. Darüber hinaus stellt die Klasse auch die grafische Oberfläche für wesentliche Benutzer-Funktionen, wie Login, Registrierung oder Profilverwaltung dar. 89

100 8. Implementierung 8.4 AJAX -Funktionen Die JqueryUI-Klasse nutzt die Javascript-Bibliothek JQuery60 um DOM-Manipulationen und HTTP-Requests via AJAX durchzuführen. Die AJAX-Funktionalität von JQuery ermöglicht es, HTTP-Aufrufe im Hintergrund durchzuführen, ohne dass dafür die Seite neu geladen werden muss. Auf diese Weise können auch Formulareingaben im Hintergrund an den Server übermittelt werden, so dass die Seite auch während des Übertragungsvorgangs bedienbar bleibt und der Benutzer weitere Eingaben vornehmen kann. Darüber hinaus ist es mit AJAX möglich, nach erfolgter Eingabe bestimmte Teilbereiche einer Seite nachzuladen, die sich durch den übertragenen Datensatz verändert haben. Das Nachladen eines Teilbereiches ist in der Regel um ein Vielfaches schneller, als die Seite komplett neu zu laden. Mittels AJAX lässt sich der Datenfluss zwischen Browser und Server soweit minimieren, dass die Bedienung einer im Browser dargestellten Benutzeroberfläche vom Look-and-Feel und der DarstellungsGeschwindigkeit einem lokal installierten Programm relativ nahe kommt. Bei der Konzeption einer Benutzerschnittstelle mit der JQueryUI-Klasse wird dieses zunächst in voneinander unabhängig Bereiche untergliedert, in denen jeweils Formulare oder Teile eines Formulars angezeigt werden, deren Datensätze weitgehend unabhängig von anderen auf der Seite dargestellten Formularen sind. Eine Änderung, die innerhalb eines Bereiches vorgenommen wird, soll sich also im Wesentlichen auch nur auf diesen Bereich auswirken. Das Nachladen und die Anzeige eines Bereichs wird über eine Javascript-Aktion ausgelöst. Ein beliebiges Eingabeelement in der Benutzeroberfläche kann mit der Aktion verknüpft werden, d.h. beispielsweise das Nachladen eines Bereiches durch den Klick auf einen Button ausgelöst werden. Es gibt eine Reihe weiterer Aktionen, wie Fehlermeldung anzeigen, Hinweis anzeigen, Seite neu laden, Erstellen eines neuen Bereichs oder Weiterleiten. Ein PHP-Script, das die in einem Formular gemachten Eingaben auswertet, kann ebenfalls eine dieser Aktionen im Browser des Benutzers auslösen. Abbildung 25 zeigt ein Beispiel anhand des im emigrant-framework integrierten Konfigurationswerkzeug. Es wird dabei zu keinem Zeitpunkt die Seite neu geladen, sondern immer nur die relevanten Teile nachgeladen. Beim Klick auf den Button Config wird die Konfigurationsoberfläche geladen und angezeigt. Der anschließende Klick auf den Reiter Profile bewirkt, das Nachladen und Anzeigen der Profileinstellungen. Die Profileinstellungen sind ihrerseits in Bereiche unterteilt. In den ersten leeren Bereich wird anschließend ein Formular für das Profil default geladen. Werden Widgets clientseitig eingebunden, so werden diese ebenfalls über die JQuery-Bibliothek nachgeladen

101 8. Implementierung Abb. 25: Nachladen relevanter Seitenbereiche via AJAX 8.5 Bedienelemente und Darstellung Die Klasse JQueryUI nutzt eine auf JQuery aufbauende Javascript-Bibliothek JQueryUI61, die der Darstellung und Anpassung von Bedienelementen dient. Mittels JQueryUI kann das Layout aller Bedienelemente über Skins verändert und dem Design einer Webseite angepasst werden. JQuery-UI verändert nicht nur das Aussehen der Bedienelemente, auch deren Verhalten, Effekte sowie die grundsätzliche Bedienung lassen sich mit JQuery-UI anpassen. Dadurch ist es beispielsweise möglich, das Portal beim Zugriff über ein iphone mit einem entsprechenden iphone-skin zu belegen, so dass die Bedienung der Seiten auch auf einem kleinen Touchscreen problemlos möglich ist, und das Look-and-Feel zu anderen iphone-applikationen passt. Aber auch auf normalen Arbeits-Computern kann die User-Experience aufgewertet werden, indem die Webseite und die Bedienelemente ästhetisch ansprechend gestaltet werden. Ein guter optischer Eindruck verstärkt das Vertrauen in die Qualität der Webseite, vermittelt dem Benutzer einen Wert und kann somit als wichtiger Baustein einer guten Usability gesehen werden [42,43]

102 8. Implementierung Alle in der Klasse JQuery-UI verfügbaren Bedienelemente lassen sich über Skins variieren. In die Klasse wurden die folgenden Bedienelemente implementiert: Überschriften Es gibt drei Überschriften-Ebenen. Überschriften können so konfiguriert werden, dass sich der darunter befindliche Bereich ein- und ausklappen lässt, um Platz zu sparen. Jede Überschrift kann zusätzlich mit Icons versehen werden, die mit einer Funktion belegt sind (Abb.26). Überschrift Ebene 1 Überschrift Ebene 2 Überschrift Ebene 2 Überschrift Ebene 3 Überschrift Ebene 3 aufgeklappt Abb. 26: veschiedene Überschriften-Ebenen der JQueryUI-Klasse Formularreihen (einzeilig, mehrzeilig und mit variabler Höhe) Die Formularreihen bilden die Container für alle Eingabeelemente. Darüber hinaus verfügt jede Formularreihe über einen Namen (links) und einen Hilfebereich (rechts). Wenn der Hilfetext mehr Platz einnimmt, als im Hilfebereich zur Verfügung steht, fügt die Klasse der Formularreihe automatisch einen ToolTip mit dem vollständigen Hilfetext hinzu. Eine Formularzeile kann zudem mit einem Löschen-Attribut versehen werden. Ist dies der Fall, so erscheint auf der rechten Seite ein Löschen-Button (Abb.27), der mit einer benutzerdefinierten Aktion versehen werden kann. Das Betätigen des Löschen-Buttons entfernt die Formularzeile unmittelbar aus dem HTML-Text ohne dass dafür ein HTTP-Request notwendig ist. Bei einer mehrzeiligen Formularreihe kann das LöschenAttribut separat für jede Zeile gesetzt werden. 92

103 8. Implementierung Löschen-Button erscheint beim Überfahren mit der Maus Abb. 27: Kontext-sensitiver Löschen-Button beim Überfahren mit der Maus Formularreihen-Auswahl Mit der Formularreihen-Auswahl kann das Aussehen eines Formulars von der Auswahl eines Dropdown-Menüs abhängig gemacht werden. Wählt der Benutzer in dem Dropdown-Menü einen anderen Wert, so ändert sich auch die darunter angezeigte Formularreihe (Abb.28). Abb. 28: Dropdown-Menü mit Formularreihenauswahl Eingabeelemente Jedes Eingabeelement kann links- oder rechtsbündig ausgerichtet werden. Ein Eingabeelement kann mit einer onchange-aktion versehen werden und verfügt 93

104 8. Implementierung über zwei unterschiedliche Anzeigemodi. Im Anzeigemodus inline-edit wird das Formularfeld selbst nicht angezeigt, sondern nur dessen Wert. Überfährt man den angezeigten Wert mit der Maus, wird dieser hervorgehoben. Ein Klick auf das hervorgehobene Element zeigt das dem Element zugeordnete Eingabeelement an, das daraufhin vom Benutzer editiert werden kann. Durch die zunächst unsichtbaren Eingabeelemente soll die Übersicht in komplexen Formularen für den Benutzer verbessert werden. Im zweiten Anzeigemodus ist das Eingabeelemente immer sichtbar (Abb.29). Editierbarer Bereich hervorgehoben Klick öffnet Eingabeelement und SpeichernFunktion Abb. 29: Kontext-sensitiver Löschen-Button beim Überfahren mit der Maus Folgende Eingabeelemente wurden in der JQueryUI-Klasse umgesetzt: Buttons Buttons können mit grafischen Icons und Text versehen werden Textfelder Textfelder können einzeilig oder mehrzeilig sein. Darüber hinaus wurden Editorkomponenten integriert, die eine Wysiwyg-Bearbeitung von Quelltext und Syntax-Highlighting ermöglichen Dropdown-Feld Checkboxes Multiselect 94

105 8. Implementierung Informations- und Fehlermeldungen Erscheint eine Meldung, so scrollt der Browser automatisch in den sichtbaren Bereich der Meldung. Fehlermeldungen werden immer rot gekennzeichnet, während Informationsmeldungen in der Farbe des aktuell aktiven Skins erscheinen. Die Meldungen werden mit einem Effekt ein- und ausgeblendet um die Aufmerksamkeit des Benutzers auf die Information zu lenken. (Abb.30 links) Des weiteren können in der rechten oberen Ecke des Browsers Kurzinfos eingeblendet werden. Diese Meldungen sind weniger aufdringlich, werden nach kurzer Zeit ausgeblendet und eignen sich daher insbesondere zur Anzeige von Informationen mit geringer Relevanz. (Abb.30 rechts) Abb. 30: Informationsmeldung (links) und Kurzinfos (rechts) 8.6 Konfigurationsoberfläche Die Klasse JQueryUI wird im emigrant-framework in erster Linie für die Darstellung einer Konfigurationsoberfläche verwendet. Deren Entwicklung war notwendig, da sich die ausschließliche Verwaltung der Einstellungen über Configfiles als zu fehleranfällig erwies und bei einer größeren Zahl von Anwendungen und Regelsätzen nur noch schwer zu überblicken war. Mit der Konfigurationsoberfläche soll es dem Administrator möglich sein, auch sehr komplexe Parser-Regelsätze und Kombinationen einzurichten, zu verwalten und deren Funktion und Abhängigkeiten zu überblicken. Die grafische Konfiguration unterteilt sich in folgende Bereiche: Basis-Konfiguration Parser Widgets Benutzer/Rollen Profile Anwendungen Aktionen Templates Scripts 95

106 8. Implementierung Die einzelnen Bereiche beinhalten sowohl Einstellungen, die sich im gesamten emigrant-framework auswirken, wie auch Konfigurationsmöglichkeiten, die sich nur auf eine einzelne Anwendung oder gar nur eine bestimmte Seite einer Anwendung beziehen. Um die Menge der dargestellten Informationen zwecks höherer Darstellungsgeschwindigkeit und verbesserter Übersicht gering zu halten, werden in den Einstellungsdialogen vorrangig die Informationen angezeigt, die einen direkten Bezug zur zuletzt aufgerufenen Seite oder Anwendung haben. Allgemeine Einstellungen finden sich hingegen weiter unten auf der Seite während die Informationen und Einstellungen für andere Seiten und Anwendungen nur als Übersicht oder in Form von Verweisen dargestellt werden Basis-Konfiguration Für jede Anwendung können separate Adressen für ein Live- und ein Testsystem angegeben werden. Wenn eine im emigrant-framework integrierte Anwendung aktualisiert werden soll, kann das Zusammenspiel der neuen Anwendung mit dem emigrant-framework und bereits bestehenden Parserregeln zunächst in einer Testumgebung geprüft werden bevor die eigentliche Anwendung überschrieben wird. In der Basis-Konfiguration kann zwischen den Live- und Testsystemen hin- und hergewechselt werden Parser Im Parser-Bereich (Abb.31) können neue Parser und die Regelsätze darin eingerichtet werden. Die Anzeige aller Parser-Regeln wäre für den Benutzer nur schwer zu überblicken und würde lange Ladezeiten verursachen. Aus diesem Grund werden beim Aufruf des Parser Bereichs nur drei Parser sofort angezeigt: URL-spezifischer Parser System-spezifischer Parser Default-Parser Die angezeigten URL- und Systemspezifischen Parser beziehen sich auf die Anwendung, aus der die Konfiguration aufgerufen wurde. Für die Parser der anderen Anwendungen werden Buttons angezeigt, mit denen sich bei Bedarf die Konfiguration nachladen lässt. Dadurch ist es auch möglich, Regelsätze unterschiedlicher Anwendungen miteinander zu vergleichen ohne dafür ein separates Browserfenster öffnen zu müssen. Über einen System-Wechsler kann darüber hinaus auch die Parser-Konfiguration für eine andere Anwendung angezeigt werden, ohne dass die Anwendung selbst aufgerufen werden muss. Für jeden Parser können Regelsätze hinzugefügt und bearbeitet sowie deren Bearbeitungsreihenfolge verändert werden. Durch das Aufklappen eines Regelsatzes in der Benutzeroberfläche werden alle Detailinformationen und Einstellungsmöglichkeiten eines Regelsatzes sichtbar (Abb.32). Für jeden Regelsatz kann der Administrator die in Kap bereits genannten Bestandteile Gültigkeit, Bedingungen, Aktionen, Anzeigen sowie Suchen und Ersetzen festlegen und verändern. 96

107 8. Implementierung Abb. 31: Parser Einstellungen in der Konfigurationsoberfläche 97

108 8. Implementierung Abb. 32: Aufgeklappter Parser-Regelsatz in den Parser Einstellungen Widgets Die Konfiguration eines Widgets ist weitgehend identisch zu der eines Parsers. Die Widgets sind nicht an eine URL oder eine Anwendung im emigrant-framework gebunden und erhalten daher einen eindeutigen Namen als Identifizierungsmerkmal. Beim Aufruf des Widget-Bereichs werden alle im emigrant-framework erstellten Widgets angezeigt Benutzer/Rollen Im diesem Bereich werden die Benutzerrollen für jede integrierte Anwendung sowie die globalen Benutzer-Rollen eingerichtet und die Zuordnung von globalen zu Anwendungsspezifischen Benutzerrollen definiert. Darüber hinaus lassen sich globale Zugriffsrechte erstellen, die einem Benutzer oder einer Benutzerrolle hinzugefügt werden. Die Ausführung eines Parserregelsatzes kann vom Vorhandensein eines bestimmten Zugriffsrechts abhängig gemacht werden und so die Darstellung der Portalseiten an Rechte- und Rollen des Benutzers angepasst werden. Im Benutzer-Rollen-Bereich lassen sich außerdem für jede Anwendung die Zugangsdaten für einen administrativen Benutzer hinterlegen. Mit diesen Daten können in einigen Anwendungen beispielsweise Benutzer automatisiert freigeschalten werden, ohne dass vorher eine -validierung stattfinden muss. 98

109 8. Implementierung Profile Über den Reiter Profile können die Benutzer-Profile angelegt und verwaltet werden. Um die Übersicht zu bewahren, werden dem Benutzer auch in diesem Bereich nur die folgenden Benutzerprofile automatisch angezeigt: Anwendungsspezifische Benutzer-Profile Zentrales Benutzerprofil Die Profile für andere Anwendungen können ebenfalls angezeigt und verwaltet werden. Für diesen Zweck gibt es ähnlich wie im Parser-Bereich für jedes Profil einen Button, mit dem sich die Einstellungsdialoge für das jeweilige Profil nachladen lassen. Für jedes Profil lassen sich Datenfelder und deren Typ (Name, Nummer, , Passwort, etc.) definieren. Je nachdem, welchen Typ ein Datenfeld besitzt, gibt es weitere Einstellungsmöglichkeiten, um Benutzer-Eingaben in dem Datenfeld zu validieren oder automatisiert mit Daten aus dem allgemeinen Benutzerprofil zu befüllen. Vorgesehen ist außerdem die Möglichkeit, anonymisierte Zufallsdaten automatisch in ein Feld einzutragen, um die Privatsphäre des Nutzers innerhalb einer bestimmten Anwendung sicherzustellen Anwendungen Im Einstellungsbereich für Anwendungen lassen sich neue Anwendungen in das emigrant-framework integrieren. Eine Anwendung kann entweder im normalen Modus (direkt) oder über eine andere Anwendung im proxy-modus aufgerufen werden. Wird eine Anwendung im normalen Modus eingebunden, so wird vorausgesetzt, dass die der Anwendung zugeordnete URL zu einem Verzeichnis führt, in dem das emigrant-client-programm installiert wurde. Der Proxy verhält sich genauso, wie jede andere Anwendung im emigrant-framework, daher wird im emigrant-server auch ein proxy als normale Anwendung hinzugefügt. Der Proxy-Server selbst ist austauschbar, die einzige Voraussetzung besteht darin, dass die Ziel-URL des Proxies ebenfalls auf ein Verzeichnis mit installiertem emigrant-client verweist. Wenn eine Anwendung nicht direkt angesteuert werden soll, wird in den Anwendungseinstellungen festgelegt, dass der Aufruf der Anwendung über eine andere Anwendung stattfindet. Die andere Anwendung fungiert dann als Proxy. Für jede Anwendung lässt sich überdies das Caching-Verhalten und die Debug-Ausgabe steuern. Wenn Einstellungen für eine Anwendung verändert werden, so wird die dabei generierte Konfiguration mit dem ihr zugeordneten emigrant-client synchronisiert Aktionen, Templates und Scripts Die Einstellungen für Aktionen, Templates und Scripts sind gleich aufgebaut. Beim Aufruf einer dieser Bereiche wird ein Editor angezeigt, über den sich die Konfigurationsdateien des jeweiligen Bereichs verwalten und editieren lassen. Der Editor bietet eine Syntax-Hervorhebung für einige gängige Programmiersprachen und ermöglicht 99

110 8. Implementierung ein schnelles Bearbeiten wichtiger Konfigurationsdateien direkt im Webbrowser. Aktionen Eine Aktion ist eine Abfolge von Anweisungen, mit deren Durchführung eine automatische Registrierung, ein automatischer Login oder beliebige andere Formulareingaben durchgeführt werden können (vgl. Kap ) Templates Mit Hilfe der Smarty-Templates lässt sich die Struktur und das Layout der Portalseiten im emigrant-framework definieren. Scripts Mit Scripts lassen sich benutzerdefinierte Programme in das emigrant-framework einbinden. Die Scripts können in Parser-Regelsätze eingebunden werden und diese damit um neue Funktionalität ergänzen. 8.7 Benutzerfunktionen Beim Aufruf einer Seite im emigrant-framework wird stets eine Kopfleiste eingebunden, die den Zugriff auf alle wesentlichen Funktionen im emigrant-framework ermöglicht. Je nach Status, Rolle und Zugriffsrechten des Benutzers werden unterschiedliche Bedienelemente in der Kopfleiste dargestellt. Die Bedienelemente sind: Login und Registrierung Benutzerkonto bearbeiten Rollen- und Systemwechsel Entwicklerfunktionen Login und Registrierung Beim Aufruf dieser Funktion wird ein Fenster angezeigt, in dem der Benutzer sich mit den Zugangsdaten eines im System registrierten Benutzer anmelden oder einen neuen Benutzer registrieren kann. Im gezeigten Bild Abb.33 sind diese Funktionen über die Reiter Anmeldung externer Benutzer und Registrierung externer Benutzer aufrufbar. Im Prototyp kann der Benutzer bei der Registrierung selber seine Benutzerrollen und Zugriffsrechte wählen und den Benutzer auch selbst freischalten. Diese Einstellungen dienen ausschließlich Testzwecken und werden in der endgültigen Version des emigrant-frameworks wieder deaktiviert. Die Registrierung läuft in zwei Schritten ab. Zunächst wählt der Benutzer einen geeigneten Benutzernamen und ein Passwort. Wenn das Passwort als sicher eingestuft wird und der Benutzername noch nicht im emigrantframework vertreten ist, wird das zentrale Benutzerkonto eingerichtet. Ist dies nicht der Fall, wird der Benutzer über den Fehler benachrichtigt (vgl. Abb.33). 100

111 8. Implementierung Abb. 33: Fehler bei der Registrierung eines neuen Benutzers aufgrund falscher Angaben In einem zweiten Schritt werden alle Datenfelder der dem Benutzer zugeordneten Anwendungsspezifischen Profile angezeigt, die als Pflichtfelder gekennzeichnet sind. Die Auswahl der Anwendungsspezifischen Profile erfolgt anhand der Zuordnung der globalen Benutzerrollen zu den Benutzerrollen innerhalb einer Anwendung. Im in Abb.34 gezeigten Beispiel wird ein Benutzer mit der globalen Rolle Admin registriert. Für eine Anwendung system1 wurden die Systemrollen Mitarbeiter, Aktensortierer und Buchhalter eingetragen. Dementsprechend werden die diesen Rollen zugeordneten Pflichtfelder der Anwendung bei der Registrierung angezeigt. Nur wenn diese vom Benutzer korrekt ausgefüllt werden, kann mit der Registrierung fortgefahren werden. Bei erfolgreicher Registrierung werden anschließend die in den Anwendungsprofilen festgelegten Aktionen zur Registrierung eines Benutzers durchgeführt. Die Benutzernamen und Passwörter für die Registrierung in den Anwendungen wählt das emigrantframework automatisch. Im Anschluss an die Registrierung kann sich der Benutzer mit seinen Zugangsdaten im emigrant-framework anmelden. Der Login kann auf jeder beliebigen Anwendungsseite durchgeführt werden, sofern die Anwendung im emigrant-framework integriert ist. 101

112 8. Implementierung Registrierung eines Benutzers mit globaler Rolle Admin Konfiguration: Profile der Anwendung System1 Optionales Datenfeld Beschreibung wird nicht angezeigt Konfiguration: Zuordnung der Benutzerrollen in System1 Abb. 34: Automatische Generierung des Registrierungsformulars aus den Anwendungsprofilen Wenn sich der Benutzer mit seinem globalen Benutzerkonto im emigrant-framework anmeldet, wird zunächst geprüft, ob die eingegebenen Zugangsdaten korrekt sind. Ist dies der Fall, führt das emigrant-framework zunächst eine Synchronisierung der Sitzungs-ID in allen integrierten Anwendungen durch. Anschließend wird die in den Anwendungsprofilen festgelegte Aktion zum Login eines Benutzers durchgeführt. Der Benutzer ist ab diesem Zeitpunkt in allen Anwendungen als eingeloggt gekennzeichnet Benutzerkonto bearbeiten Die Kopfleiste eines angemeldeten Benutzers bietet den Zugriff auf die Kontoeinstellungen des Benutzers. In den Kontoeinstellungen kann der Benutzer sämtliche ihm zugeordneten Anwendungsprofile editieren. Über Karteireiter kann zwischen den Profilen hin- und hergewechselt werden. Wie in Abb.35 zu sehen ist, werden in den Kontoeinstellungen im Gegensatz zur Registrierung auch alle Datenfelder angezeigt, die nicht als Pflichtfelder gekennzeichnet wurden. Nachdem der Benutzer seine Daten aktualisiert hat, führt das emigrant-framework die Aktion Aktualisierung in allen Anwendungen durch, in denen der Benutzer eingetragen ist. 102

113 8. Implementierung Abb. 35: Kontoeinstellungen eines eingeloggten Benutzers Rollen- und Systemwechsel In der Kopfleiste sind für den angemeldeten Benutzer zwei Dropdown-Felder sichtbar. Das erste Dropdown-Feld beinhaltet alle dem Benutzer zugeordneten globalen Rollen, während das zweite Dropdown-Feld die Systeme anzeigt, in denen der Benutzer vertreten ist. Mittels dieser beiden Eingabefelder soll ein schneller Wechsel zwischen den globalen Benutzerrollen sowie zwischen den einzelnen Anwendungen möglich werden. Im Prototyp des emigrant-frameworks ist der schnelle Rollen- und Systemwechsel noch nicht implementiert und daher ohne Funktion. 103

114 8. Implementierung Entwicklerfunktionen Für die Implementierung, Administration und Fehlerbehebung im emigrantframework wurden drei Buttons in die Kopfleiste integriert, die einen schnellen Zugriff auf folgende Funktionen bieten: Cache leeren Mit dem Cache leeren-button lassen sich alle im emigrant-client der gerade aktiven Anwendung gespeicherten Cache-Dateien löschen. Debugger anzeigen/verbergen Mit diesem Button lässt sich der Debugger für die aktuell aufgerufene Seite aktivieren. Die Aktivierung bewirkt eine Aufteilung des Browserfensters in zwei Bereiche (Splitscreen). Während im oberen Bereich die Seite dargestellt wird, werden im unteren Bereich die vom Debugger in Echtzeit mitprotokollierten Aktionen angezeigt. Konfigurationsoberfläche aufrufen Diese Funktion öffnet das Konfigurationsoberfläche für die zuletzt aufgerufene Anwendung. 104

115 9. Praxisbeispiel 9 Praxisbeispiel In den vorhergehenden Kapiteln wurde das Konzept, die Implementierung, der Aufbau und die Benutzeroberfläche des emigrant-frameworks erläutert. Um die Praxistauglichkeit des Konzepts und die Funktionsfähigkeit des Prototyps unter Beweis zu stellen, werden die wesentlichen Kernfunktionen des Frameworks in diesem Abschnitt anhand einer einfachen Beispielkonfiguration dargestellt. In der eingangs erwähnten Arbeit von Bernhard Strehl Evaluation und Überarbeitung integrierter Web-Anwendungen am Beispiel einer universitären Lehr-/Lernplattform (Digicampus) [SB09] wurde die grafische Benutzerschnittstelle der bestehenden Plattform Digicampus überarbeitet. Während die technische Plattform für ein neues Digicampus-Lernportal auf das emigrant-framework portiert wird, sollen Aufbau, Struktur und Funktion der überarbeiteten Benutzeroberfläche weitgehend aus dem überarbeiteten Prototypen übernommen werden. Aus diesem Grunde soll zunächst aus der Sicht eines Administrators gezeigt werden, wie eine Portalseite mit dem emigrant-framework umgesetzt wird, deren Aufbau sich an den Vorgaben der überarbeiteten Digicampus-Benutzerschnittstelle orientiert. 9.1 Erstellung einer Portalseite Eine Portalseite im verbesserten Digicampus-Layout lässt sich in Bereiche und Widgets gliedern. Es gibt drei Inhaltsbereiche, einen linken, einen mittleren und einen rechten Bereich. Des weiteren gibt es einen Header, einen Bereich für die Navigation, sowie einen Bereich, in dem wesentliche Benutzerfunktionen dargestellt werden. Innerhalb dieser Bereiche werden Widgets dargestellt, die jeweils Informationen und Funktionen zu einem bestimmten Aufgaben- oder Themengebiet anzeigen (Abb.36). Die Widgets werden clientseitig via Ajax in den dafür vorgesehenen Bereich geladen. Benutzerfunktionen Navigation Widget Neuigkeiten linker Bereich mittlerer Bereich Widget Mensaplan rechter Bereich Abb. 36: Verbesserte Digicampus-Benutzeroberfläche - Aufteilung 105

116 9. Praxisbeispiel Die Erstellung und Integration von Widgets mit den bisher im Digicampus verfügbaren technischen Mitteln ist jedoch sehr aufwendig, da diese in den meisten Fällen eigens entwickelt werden müssen, und nicht auf bereits bestehende Seiten innerhalb einer Anwendung zurückgreifen können sofern diese mit einem Zugriffsschutz versehen sind [SB10 Kap ]. Auch ohne einen Zugriffsschutz ist die Integration von Widgets bislang funktionell eingeschränkt, solange nicht alle Pfadangaben zu Bildern oder Links umgeschrieben werden. Das Widget Mensaplan wurde daher in der neuen Benutzeroberfläche nur rudimentär integriert, indem alle Bilder und Links entfernt werden, bevor dieses angezeigt wird. Nachfolgend wird ein Konfigurationsbeispiel gezeigt, wie im emigrant-framework eine Portalseite aufgebaut wird, in der ebenfalls ein Widget Mensaplan angezeigt wird. Dafür werden in chronologischer Reihenfolge folgende Schritte durchgeführt: Erstellung eines Seitentemplates Registrierung der beteiligten Anwendungen Aktivierung des Layout-Templates Erstellung des Widgets Mensaplan Einbinden des Widgets in die Portalseite Erstellung eines Seitentemplates Die Grundlage einer Portalseite bildet das Layouttemplate, über das die Inhaltsbereiche und das Corporate Design der Seite festgelegt werden. Das in Abb.37 gezeigte Layout enthält zwei Spalten, einen Bereich für den Inhalt der aufgerufenen Seite und einen rechten Bereich für Widgets. Der Inhalt wird an der Stelle des vordefinierten Markers {$content} eingefügt. Der Marker {$mensaplan} soll zu einem späteren Zeitpunkt durch ein Widget mit dem aktuellen Mensaplan ersetzt werden. Das Template wird in das emigrant-framework eingebunden, indem im Bereich Templates im Konfigurationsoberfläche ein neues Template main erstellt wird. Anschließend wird im Editorfenster dem Template main der Quelltext des Layouttemplates hinzugefügt. Benutzerfunktionen Navigation {$mensaplan} Marker für Mensaplan {$content} Marker für Hauptinhalt linker Bereich rechter Bereich Abb. 37: Layout erstellen und als Template einfügen Layout erstellen und als Template einfügen 106

117 9. Praxisbeispiel Registrierung der beteiligten Anwendungen Im Praxisbeispiel sollen zunächst zwei Anwendungen über den Proxy-Modus integriert werden, eine Testinstallation des im Digicampus verwendeten LMS Stud.IP sowie die Seite des Studentenwerks, die als Grundlage für die Erstellung eines MensaplanWidgets dient. Innerhalb der Konfiguration werden für diesen Zweck im Bereich Anwendungen die beiden Systeme Stud.IP und studentenwerk eingetragen. Für beide Anwendungen wird serverseitiges und clientseitiges Caching aktiviert. In den in Abb.38 dargestellten URL-Feldern wird die URL der Stud.IP-Hauptseite für die Anwendung Stud.IP und die Adresse des Studentenwerks für die Anwendung studentenwerk eingetragen. Des weiteren wird im Feld Systemaufruf via angegeben, dass die Anwendung nicht direkt, sondern über die Anwendung proxy aufgerufen wird. Die Anwendung proxy wiederum verweist auf eine URL, in deren Zielverzeichnis sich der emigrant-client befindet. Abb. 38: Registrierung einer Anwendung Anschließend können die Anwendungen Stud.IP und studentenwerk im Browser aufgerufen werden, indem der Titel der Anwendung an die URL der Proxy-Anwendung angehängt wird (Abb.39). Die über den Proxy aufgerufene Seite unterscheidet sich nur durch die Kopfleiste von der ursprünglichen Anwendung. 107

118 9. Praxisbeispiel Abb. 39: Aufruf der Anwendung Stud.IP über das emigrant-framework Aktivierung des Layout-Templates Damit die eingebundene Anwendung Stud.IP im zuvor erstellten Layout erscheint, muss dieses aktiviert werden. Die Verwendung eines Layouts wird über Parser gesteuert. Da alle Seiten in einem einheitlichen Layout erscheinen sollen, wird im Parser-Bereich zunächst ein default-parser hinzugefügt und anschließend in diesem Parser das Template main als Layouttemplate gewählt (vgl Abb.40). Ab diesem Zeitpunkt wird das Layout von allen im emigrant-framework integrierten Anwendungen verwendet. Ein erneuter Aufruf der Stud.IP-Anwendung zeigt, wie die Seite aussieht, wenn Sie in dem Layout integriert ist (Abb.40). Abb. 40: Aktivierung des Templates main und anschließender Aufruf der Anwendung Stud.IP 108

119 9. Praxisbeispiel Erstellung des Widgets mit einem Mensa-Speiseplan Die Seite des Studentenwerks wird über das emigrant-framework ebenfalls im grünen Digicampus-Layout dargestellt. Damit aus der Anwendung studentenwerk ein Mensaplan wird, muss zunächst Ort und Aussehen des Mensaplans auf der Studentenwerksseite lokalisiert werden. Der Speiseplan der Mensa befindet sich auf einer Unterseite verpflegung/_uni-aktuelle-woche.php. Im Quelltext dieser Seite zeigt sich, dass der Mensaplan aus mehreren ineinander verschachtelten Tabellen besteht, die zudem nicht eindeutig gekennzeichnet sind. Um den Mensaplan zu extrahieren, wird über das Konfigurationsoberfläche im Bereich Widgets zunächst ein neues Widget mensaplan angelegt. Das Widget erhält anschließend einen Regelsatz mit der Beschreibung extrahiert den Mensaplan und der Aktion Zeige Suchstring an (outerhtml). Mit der genannten Aktion lässt sich die Ausgabe einer Webseite auf einen bestimmten Bereich innerhalb der Seite eingrenzen. Der Begriff Suchstring beschreibt das in Kap erläuterte Suchmusterverfahren. Das Suchmusterverfahren wird angewendet, da sich der Speiseplan im Quelltext aufgrund der Tabellenstruktur nicht über einen DOM-Selector separieren lässt. Das angewandte Suchmuster ist der Abbildung 41 zu entnehmen. Um die Funktion des Widgets zu testen, wird die Seite mit dem Speiseplan im Browser mit dem angehängten Parameter?emigrant_widget=mensaplan aufgerufen. Der Parameter bewirkt die Anwendung des Widgetparsers mensaplan und ändert die Ausgabe der Seite dahingehend, dass anstelle der vollständigen Studentenwerksseite ausschließlich der Mensaplan dargestellt wird. Abb. 41: Parser-Regel, um den Mensa-Speiseplan aus der Studentenwerksseite zu extrahieren 109

120 9. Praxisbeispiel Einbinden des Widgets in die Portalseite Abschließend soll an dieser Stelle noch gezeigt werden, wie das erstellte Widget in die Portalseite eingebunden werden kann. Dafür wird im Konfigurationsoberfläche erneut der default-parser geöffnet und ein Regelsatz hinzugefügt. Dieser Regelsatz erhält die Beschreibung Mensaplan einbinden (vgl Abb.42) sowie eine Finde Marker Regel, mit der der im Layouttemplate angegebene Marker {$mensaplan} selektiert wird. Eine Ersetzen mit Widget Regel ersetzt wiederum den gefundenen Marker durch das mensaplan-widget. Ein nachfolgender Aufruf der Anwendung Stud.IP zeigt die Portalseite mit integriertem mensaplan-widget. Der emigrant-server passt die Bildpfade und Links im Widget automatisch an, so dass Aussehen und Funktion des Widgets erhalten bleiben. Über weitere Parser-Regeln kann das Widget soweit umgestaltet werden, dass es optisch zum Corporate-Design des Portals passt. Abb. 42: Einbinden des mensaplan-widgets in die Anwendung Stud.IP 9.2 Automatische Benutzer-Registrierung und Login Mit dem zweiten Praxisbeispiel soll die automatische Registrierung und der anschließende Login eines Benutzers in die im emigrant-framework integrierten Anwendungen demonstriert werden. In das Lernportal Digicampus soll zukünftig die Begleitstudiumsplattform eee-portfolio integriert werden, über die der Student wesentliche Aufgaben zur Dokumentation und Kommunikation von Begleitstudiumsprojekten an der Universität Augsburg durchführen kann [MJ09]. Nachfolgend wird für diese Anwendung gezeigt, welche Schritte ein Administrator umsetzen muss, damit Benutzer automatisch registriert und angemeldet werden wenn sie eine Registrierung respektive einen Login im emigrant-framework durchführen. Zunächst wird die Anwendung eeeportfolio im Konfigurationsoberfläche angelegt, damit die Begleitstudiumsplattform über das emigrant-framework aufgerufen werden kann. Die Anwendung erhält zudem eine Benutzer-Rolle User, die allen globalen Benutzer-Rollen im emigrant-framework zugeordnet wird (Abb.43). 110

121 9. Praxisbeispiel Abb. 43: Integration der Anwendung eee-portfolio in das Emigrant-Framework und Zuweisung einer Benutzerrolle Notwendige Schritte für eine automatische Registrierung: Ermitteln der für eine Registrierung notwendigen Datenfelder Erstellen der Benutzer-Profile für die Anwendung Erstellen eines Registrierungsscripts Durchführen einer Benutzer-Registrierung Ermitteln der für eine Registrierung notwendigen Datenfelder Das in Abb.44 gezeigte Formular zur Registrierung eines neuen Benutzers in der Begleitstudiumsplattform befindet sich im URL-Pfad /user/register. Verpflichtende Angaben für eine erfolgreiche Registrierung sind die Daten Benutzername, adresse, Name, Studiengang, Hochschule sowie ein Captcha. Von besonderer Bedeutung ist auch der im Quelltext angegebene Feldname, da dieser zur Identifizierung der Formularfelder bei der automatischen Registrierung benötigt wird. Der Benutzername für die einzelnen Anwendungen wird ebenso wie das dazugehörige Passwort automatisch durch das emigrant-framework vergeben. Als -adresse wird ebenfalls eine vom emigrant-framework generierte Adresse vorgegeben, da diese ein automatisches Abfragen der und somit die Freischaltung eines Benutzers ermöglicht. Das Feld Name muss hingegen aus einem Benutzerprofil entnommen werden und setzt sich aus den Angaben Vorname und Nachname zusammen. Die Felder für Studiengang und Hochschule müssen ebenfalls einem Profil entnommen werden. Da sich die Begleitstudiumsplattform jedoch im Livebetrieb befindet, sollen korrekte Werte für diese Felder fest eingetragen werden, damit keine unnötigen Datensätze die Übersicht für andere Benutzer des Systems erschweren. Das Captcha-Feld kann nicht einem Benutzerprofil entnommen werden und dient dazu, eine automatische Registrierung zu verhindern. Durch den im emigrant-framework eingebauten 111

122 9. Praxisbeispiel Captcha-Dekoder ist eine automatische Registrierung dennoch möglich. Abb. 44: Analyse des Registrierungsformulars der eee-portfolio Plattform Erstellen der Benutzerprofile für die Anwendung Die zuvor ermittelten Datenfelder müssen in der Konfiguration eingetragen werden. Dies erfolgt über die Definition von Benutzerprofilen, die nach Anwendung und Benutzerrolle innerhalb der Anwendung aufgeschlüsselt werden und intern die Bezeichnung Anwendungsname-Benutzerrolle tragen. Dafür werden im Bereich Profile die in Abb.45 gezeigten Profile eeeportfolio-default, eeeportfolio-user und das allgemeine Profil default-default erstellt. Die Datenfelder Vorname, Nachname und werden im allgemeinen Profil eingetragen und als Pflichtfelder gekennzeichnet, da diese auch von anderen Anwendungen benötigt werden und vom Benutzer nur an einer Stelle eingegeben werden sollen. Da für die Anwendung eeeportfolio lediglich eine Benutzerrolle eingetragen wurde, spielt es keine Rolle, ob sich Datenfelder im Profil eeeportfolio-default oder im Profil eeeportfolio-user befinden, da sich beide Profile auf die einzige existierende Benutzerrolle User auswirken. Beide Profile müssen jedoch vorhanden sein, damit das emigrant-framework die Anwendung bei der Registrierung berücksichtigt. Im Profil eeeportfolio-default werden ebenfalls die drei Felder Vorname, Nachname und angegeben. Eine Einstellung automatische Übernahme ermöglicht jedoch, dass die Werte für die Datenfelder automatisch aus dem allgemeinen Benutzerprofil defaultdefault übernommen werden. Die Felder aus dem Profil eeeportfolio-default bleiben somit für den Benutzer unsichtbar und er muss die Daten nur einmalig im allgemeinen Benutzerprofil eintragen. 112

123 9. Praxisbeispiel Abb. 45: Integration der Anwendung eee-portfolio in das Emigrant-Framework und Zuweisung einer Benutzerrolle Erstellen eines Registrierungs-Scriptes Der Ablauf der automatischen Benutzerregistrierung in der Begleitstudiumsplattform ist relativ komplex, da das System bei der Registrierung keine Eingabe eines Passwortes erlaubt. Um dennoch das vom emigrant-framework generierte Passwort für die Anwendung einzutragen muss ein Link in der Bestätigungs aufgerufen werden, über den ein Neu-Setzen des Passworts möglich ist. Welche Schritte der emigrant-client dazu durchführen muss, wird über eine im Konfigurationsbereich erstellte Aktion eeeportfolio_reg festgelegt. In der nachfolgenden Tabelle Tab.4 werden die einzelnen Schritte dieser Aktion beschrieben: visit_site %system_url%user/register Der emigrant-client ruft die Registrierungsseite der Begleitstudiumsplattform mit den dem Benutzer zugeordneten Sitzungsdaten auf. Der Platzhalter %system_url% wird beim Aufruf automatisch durch die URL der Anwendung eeeportfolio ersetzt. solve_math_captcha user-register,span,class=field-prefix Der emigrant-client löst das im Registrierungsformular eingebettete Mathe-Captcha. Der erste Parameter user-register gibt an, wie das Formular im Quelltext der Anwendung benannt ist, indem sich das Captcha befindet. Der zweite und dritte Parameter dienen der Selektion des HTML-Tags, indem die Captcha-Aufgabe eingebettet ist. Das Ergebnis des gelösten Captchas wird in einer Variable zweischengespeichert, und lässt sich über einen Platzhalter %captcha_solution% an anderer Stelle im Registrierungsprozess eintragen. send_form_script user-register,$postdata['profile_realname'] = $this>getuserdata('vorname').' '.$this->getuserdata('nachname'); Der Emigrant-Client erstellt den Namen des Benutzers aus Vor- und Nachname und fügt sie dem Formularfeld profil_realname hinzu. send_form user-register,name=%system_username%,mail=%system_ %,profile_realname=%vorname% %Nachname%,profile_degree_course=Informatik und Multimedia (M. Sc.),profile_university=Uni Augsburg,captcha_response= %captcha_solution% 113

124 9. Praxisbeispiel Der emigrant-client befüllt die Felder des Registrierungsformulars user-register mit folgenden Daten: Vom emigrant-framework generiert: Benutzername der Anwendung name Captcha-Lösung captcha_response temporäre -adresse system_ Aus dem eeeportfolio-benutzerprofil entnommen: Vorname und Nachname profile_realname Fest eingetragene Daten: Studiengang profile_degree_course Universität profile_university Nachdem das Formular abgesendet wurde, schickt die Begleitstudiumsplattform eine mit dem Zugangspasswort an die temporäre -adresse system_ . In diesem Fall wurde die Adresse als temporäre -adresse verwendet. check_imap Der emigrant-client ruft die -adresse mit dem Passwort password auf dem Posteingangsserver imap-gateway.de ab. Diese -adresse dient im Prototyp als temporäre -adresse beim Einrichten neuer Benutzer. Der vierte Parameter bewirkt, dass der zweite (Index 1) in der vorkommende Link nach deren Abruf vom emigrant-client aufgerufen wird. Nach dem Aufruf dieses Links ist der Benutzer in der Begleitstudiumsplattform freigeschalten. send_form user-pass-reset Um das Passwort neu zu setzen, betätigt der emigrant-client den Button Passwort neu setzen im Formular user-pass-reset. Anschließend erhält der emigrant-client Zugriff auf die Kontodaten des eingetragenen Benutzers. click_link Konto Der emigrant-client klickt auf den Link Konto, über den er zu den Kontoeinstellungen des Benutzers gelangt. click_link Bearbeiten Innerhalb der Kontoeinstellungen klickt der Benutzer auf Bearbeiten um diese zu verändern. send_form user-edit,pass[pass1]=%system_password%,pass[pass2]= %system_password%,mail=% % Im letzten Schritt wird das Passwort des Benutzers durch das vom emigrant-framework generierte Passwort für die Anwendung ersetzt und die -adresse des Benutzers anstelle der temporären -adresse eingesetzt. Nach dem Absenden des Formulars ist die Registrierung des Benutzers abgeschlossen. Tab. 4: Aktion für die Durchführung einer automatischen Registrierung im System eee-portfolio 114

125 9. Praxisbeispiel Durchführen einer Benutzer-Registrierung Um die korrekte Funktion der automatischen Benutzerregistrierung in der Begleitstudiumsplattform zu verifizieren, wird die Registrierung und ein darauffolgender Login am Beispiel des Benutzers Rainer demonstriert. Die Anwendung eeeportfolio wurde dafür mit einer weiteren Aktion versehen, die den automatischen Login eines Benutzers ermöglicht. Neben der Anwendung eeeportfolio wurden auch für die Anwendung Stud.IP Benutzerprofile und Aktionen angelegt um die simultane Registrierung und den Login eines Benutzers in mehreren Systemen zu demonstrieren. Im Registrierungsformular des emigrant-frameworks werden die Benutzerdaten für den Benutzer Rainer angegeben (Abb.46). Der Benutzer wurde korrekt in beide Systeme übertragen, wenn ein anschließender Login im emigrant-framework auch den Login in die beiden Anwendungen eeeportfolio und Stud.IP zur Folge hat. Ebenso soll ein Logout des Benutzers dazu führen, dass dieser danach in keinem der Systeme mehr eingeloggt ist. Abb. 46: Registrierung eines Benutzers im emigrant-framework Nach erfolgter Registrierung wird der Login des Benutzers Rainer auf einer beliebigen Seite im emigrant-framework durchgeführt. Das nachfolgende Bild Abb.47 zeigt Aussehen und Zustand der integrierten Anwendungen nach einem Login. 115

126 9. Praxisbeispiel Login auf beliebiger Seite Eingeloggt im emigrant-framework Eingeloggt in eeeportfolio Eingeloggt in studip Abb. 47: Login in das emigrant-framework 116

127 10. Lessons Learned 10 Lessons Learned Mit dem emigrant-framework wurde gezeigt, dass es möglich ist, beliebige Webseiten unabhängig von Aussehen, Struktur und Quellcode neu zu kombinieren, deren Benutzeroberfläche und Funktionen zu verändern sowie einen Single Sign-on bereitzustellen, ohne dabei die Webseiten selbst zu verändern. Auf diese Weise können die einzelnen Bereiche in einem Webportal auf mehrere Server und Administratoren verteilt und die Funktionen innerhalb des Portals mit unterschiedlichen Anwendungen realisiert werden, die jeweils nur eine Teilfunktionalität erfüllen. Ebenso lassen sich Anwendungen zu einem späteren Zeitpunkt deaktivieren und durch andere ersetzen, ohne dass dafür Programmcode angepasst werden muss. Da die Konfiguration der Anwendungen über eine grafische Benutzeroberfläche erfolgt, kann diese auch von Personen durchgeführt werden, die nicht über weitreichende Programmierkenntnisse verfügen. Fehler bei der Konfiguration sind zudem meist reversibel, da der Quellcode der Anwendungen selbst und auch der des emigrant-frameworks unverändert bleibt. Da eine Universität sich ständig neuen Enticklungen und Forschungsergebnissen anpassen muss unterliegen die digitale Medien in Forschung und Lehre wie auch die universitäre IT-Infrastruktur häufigen Veränderungen die sich auf ein Lernportal auswirken, dass in einer Universität als Schnittstelle zwischen Dozenten, Studenten und Verwaltungspersonal fungiert. Daher ist es für ein Lernportal essentiell wichtig, dass dieses keine neuen Abhängigkeiten schafft, die diese Erneuerungsprozesse behindern oder verlangsamen. Erfahrungen mit dem Digicampus haben gezeigt, dass die stetige Erneuerung, Verbesserung und Veränderung eines Lernportals kostspielig, aufwendig und fehleranfällig sein kann. Das emigrant-framework bietet daher einen vielversprechenden Ansatz, die Integration neuer Anwendungen zu vereinfachen, die Benutzeroberfläche zu verbessern und die Fehleranfälligkeit zu reduzieren. Der Kern des Frameworks erweist sich als relativ stabil und wurde einem mehrfachen Refactoring und zahlreichen Tests unterzogen. Dies betrifft vor allen den emigrant-client und den dazugehörigen Proxy, der hinsichtlich der Kompatibilität bei einer Vielzahl von Seiten deutlich besser abschneidet, als andere vergleichbare webbasierte Proxy-Lösungen. Für den Praxiseinsatz im Digicampus ist jedoch eine Weiterentwicklung des emigrantframework notwendig, da noch nicht alle notwendigen Funktionen implementiert wurden und vereinzelt Fehler auftreten können. Die grafische Benutzeroberfläche zur Konfiguration, die Benutzer-/Rollen-Verwaltung sowie einige Parser-Regelsätze erfüllen noch nicht alle Funktionen, sind noch nicht ausgiebig getestet und können daher nur als Prototyp angesehen werden. Insgesamt umfasst das emigrant-framework knapp Lines-of-Code ohne eingebundene Bibliotheken, Module oder Kommentare, davon circa 7000 im emigrant-client und ungefähr 3000 im emigrantserver. Die verbleibenden 4000 Zeilen entfallen auf die grafische Benutzeroberfläche. 117

128 10. Lessons Learned 118

129 11. Ausblick 11 Ausblick Wie bereits in der Einleitung angedeutet wurde, haben webbasierte Programme das Potential, ein Großteil der klassischen Desktopanwendungen vom Markt zu verdrängen. Im Rahmen dieser Masterarbeit konnte gezeigt werden, dass viele der eingangs erwähnten Nachteile von Webanwendungen lösbar sind. Im e-learning Umfeld konnten sich die Browser-Anwendungen von vornherein durchsetzen. Dies zeigen auch die Ergebnisse der DeLFI - E-Learning Fachtagung Informatik, in der zuletzt fast ausschließlich webbasierte Lösungen vorgestellt wurden [SA09]. Ein Lernportal eignet sich durchaus für einen Blick in die Zukunft, zum einen, weil die Universitäten bei der Evaluierung und Akzeptanz neuer Technologien eine Vorreiterrolle ausüben, zum andern weil der Mikrokosmos einer Universität ein ideales Testumfeld für organisationelle Stukturen und der Zusammenarbeit einer Wissensgesellschaft darstellt. Das Lernportal Digicampus konnte vor allem durch die Integration von und mit anderen Anwendungen und deren Anpassung eine hohe Akzeptanz erreichen, die sich in den stetig steigenden Nutzerzahlen widerspiegelt. Die ständige Anpassung und Integration stellt jedoch keine zukunftsfähige Lösung dar, da sich die meisten Webanwendungen aufgrund fehlender Standards und mangelnder Interoperabilität in einem autarken Umfeld, abgeschottet von den Programmen anderer Anbieter, befinden und gar nicht vorsehen, dass Daten nach außen gelangen. Nur wenn es offene allgemein akzeptierte Schnittstellen gibt, können die vielen Bruchstücke der in den Webanwendungen gespeicherten Informationen zu neuem kollektiven Wissen vereint werden. Der Schlüssel zu einem besseren und sozialeren Internet liegt in der semantischen Verknüpfung der Webseiten, Daten, Meinungen und Ergebnisse, dem Semantic Web. The web is more a social creation than a technical one. I designed it for a social effect to help people work together and not as a technical toy. [44] (Tim Berners-Lee) 119

130 11. Ausblick 120

131 12. Literaturverzeichnis 12 Literaturverzeichnis Quellen [SB10] Strehl B. (2010); Masterarbeit: Evaluation und Überarbeitung integrierter Web-Anwendungen am Beispiel einer universitären Lehr-/Lernplattform (Digicampus); Uni-Augsburg: Lehrstuhl für Multimediakonzepte und Anwendungen 2010 [FB06] Branca F. (2006); Diplomarbeit: CAMPUS T3 - eine E-Learning-Architektur auf Open Source-Basis; TH Karlsruhe: Institut für theoretische Informatik 2006 [DF09] Daniel F., Matera M. (2009); Turning Web Applications into Mashup Components: Issues, Models, and Solutions; ICWE 2009 [NT09] Nelker T. (2009); An Infrastructure for Intercommunication between Widgets in Personal Learning Environments [KM04] Kerres M., Nattland A. (2004); Online-Campus: Eine hybride Lernplattform für Online-Studienprogramme; MKWI 2004 [BP07] Bigham P.J., Ladner E.R. (2007); Accessmonkey: A Collaborative Scripting Framework for Web Users and Developers; W4A2007 [GW08] Graham W., Facebook API Developers Guide; Firstpress [MP09] Mendes P., Cáceres M, Dwolatzky B. (2009); A review of the widget landscape and incompatibilities between widget engines; IEEE AFRICON 2009 [BK00] Bennett K. (2000); Service-based software: the future for flexible software; APSEC 2000 [RR02] Rotfuss G., Ried C. (2002); Content-Management mit XML, SpringerVerlag GmbH (September 2002) [BE07] Boyd d.m., Ellison N.B. (2007); Social Network Sites: Definition, History, and Scholarship; Journal of Computer-Mediated Communication 13(1) Article 11 [SJ00] Siedersleben J. (2000); Softwaretechnik: Praxiswissen für Softwareingenieure; Hanser Fachbuch Verlag (Mai 2000); S [MJ09] Metscher J. (2009); Masterarbeit: Interdisziplinäre Konzeption und Entwicklung einer kollaborativen e-portfolio Umgebung; Uni-Augsburg: Lehrstuhl für Multimediakonzepte und Anwendungen 2009 [GS07] Grünwald S. (2007); LMSNews.com als universitäres Projekt - Projektplanung, Durchführung und Abschluss; Lulu Enterprises Inc 2007 [NP09] Noack P., Rosina P., Strehl B. (2009); Integration von E-Learning-Werkzeugen und Realisierung einer campusweiten Lehr-/Lernplattform; DeLFI 2009 [SA09] Schwill A., Apostolopoulos N. (2009); Lernen im digitalen Zeitalter; DeLFI 2009 Die E-Learning Fachtagung für Informatik; Köllen Druck + Verlags GmbH (2009) 121

132 12. Literaturverzeichnis Weblinks [1] Artikel von golem.de zur Verbreitung von Netbooks; zuletzt besucht am [2] Artikel von techchannel.de zur Verbreitung von Smartphones; massenmarkt_und_verbreiten_das_mobile_internet/ zuletzt besucht am [3] Artikel von teltarif.de Verkaufszahlen Netbook und PC; zuletzt besucht am [4] Garrett J.J.; Ajax: A New Approach to Web Applications ; Adaptive Path LLC, 18. Februar zuletzt besucht am [5] W3C: Spezifikation des HTTP-Protokolls RFC2616: URI-Parameter zuletzt besucht am [6] W3C: Spezifikation der HTTP-Cookieheader RFC zuletzt besucht am [7] W3C: Spezifikation des HTTP-Protokolls RFC2616: HTTP-Message zuletzt besucht am [8] W3C: Spezifikation des HTTP-Protokolls RFC2616: HTTP-Header zuletzt besucht am [9] W3C: Spezifikation des HTTP-Protokolls RFC2616: Request-Methods zuletzt besucht am [10] IETF: Spezifikation des Content-Type RFC zuletzt besucht am [11] Schönitzer Michael; Übersicht zu Content-Encodings zuletzt besucht am [12] Edelmann B., Zittrain J. (2003); Internet Filtering in China; Harvard Law School; IEEE Internet Computing (March/April 2003) zuletzt besucht am

133 12. Literaturverzeichnis [13] Sun: Securing Web Applications Through a Secure Reverse-Proxy zuletzt besucht am [14] Wissenswertes über Proxy Caches zuletzt besucht am [15] Artikel von e-teaching.org Content Management Systeme; zuletzt besucht am [16] Rengarajan R.: LCMS and LMS Taking advantage of tight integration zuletzt besucht am [17] PCMag: Definition des Portal-Begriffs p zuletzt besucht am [18] Sisto C., Gehl H., Georgiev I, Fink und andere; Learning Management Systeme; Websquare Ausgabe zuletzt besucht am [19] Zimmermann Wolf (2009);Vorlesungsunterlagen Softwaretechnik; Universität Halle zuletzt besucht am [20] Sun One Portal Server Development Guide Chapter 4: Analysing your requirements zuletzt besucht am [21] Bundesdatenschutzgesetz zuletzt besucht am [22] Kreilsheimer H.; Open Source Jahrbuch 2008, Kapitel 4: Von der Entscheidung zum Einsatz (2008) zuletzt besucht am [23] Branca F.; T3N Typo3-Magazin: CAMPUS T3 ein TYPO3-basiertes Learning Management System; t3n Nr. 6 (12/2006) zuletzt besucht am [24] Facebook-Marketing: Aktuelle Nutzerstatistiken zuletzt besucht am

134 12. Literaturverzeichnis [25] Petersen C. (2010); Artikel: In the World of Facebook; zuletzt besucht am [26] Wolf K; Webblog mit Erfahrungsberichten zu Facebook als Elearning-Werkzeug; zuletzt besucht am [27] Jodeleit B.; Facebook und die Datensicherheit; zuletzt besucht am [28] de Jonge A. (2009); Blog - IFrames are like heroin...; zuletzt besucht am [29] Data Center Knowledge: Artikel zur Facebook Server Infrastruktur zuletzt besucht am [30] Reenskaug T.; Definition des MVC-Pattern; XEROX Parc zuletzt besucht am [31] SUN: Erläuterungen zum MVC-Pattern; zuletzt besucht am [32] Nexen: Statistiken zur Verbreitung von PHP, zuletzt besucht am [33] TIOBE Programming Community Index for February zuletzt besucht am [34] Netcraft: Verbreitung von Webservern; Feburar zuletzt besucht am [35] websiteoptimization: Artikel zu Übertragungskompression; zuletzt besucht am [36] W3C: Spezifikation des HTTP-Protokolls RFC2616: Header-Weiterleitungen zuletzt besucht am [37] Yahoo Developer Network: Best Practices for Speeding Up Your Web Site zuletzt besucht am

135 12. Literaturverzeichnis [38] stackoverflow: Diskussion zu Ajax und SSL zuletzt besucht am [39] Pohlig: Verschlüsseln mit XOR htm zuletzt besucht am [40] Heise Security: Erste Schritte mit der Einbruchserkennung PHPIDS; zuletzt besucht am [41] Barrierefreies Webdesign: CSS-Design in 3 (oder 5) Schritten zuletzt besucht am [42] Hassenzahl M., Thielsch T.M.: Achtmal Schönheit; i-com Ausgabe zuletzt besucht am [43] Hassenzahl M., Eckold K., Thielsch T.M. (2009); User Experience und Experience Design Konzepte und Herausforderungen; Folkwang University in Essen zuletzt besucht am [44] Zitat von Tim Berners-Lee ber-das-internet/ zuletzt besucht am

136

137 13 Anhang Anhang I: Aufruf der Seite über den emigrant-client Ablaufskizze und Übersicht über Komponenten und Klassen des emigrant-client I

138 Anhang II: Anpassung einer Seite im emigrant-server Ablaufskizze und Übersicht über Komponenten und Klassen des emigrant-server II