Architektur eines verteilten Lernobjektrepositoriums

Architektur eines verteilten Lernobjektrepositoriums
Sascha Bobrowski, Olaf Nowaczyk
2006
Forschungsberichte
des Fachbereichs Elektrotechnik & Informationstechnik
ISSN 0945-0130
2/2006
Fachbereich Elektrotechnik
Lehrgebiete
Allgemeine und Theoretische Elektrotechnik
Prof. Dr.-Ing. R. Pregla
Datenverarbeitungstechnik
Prof. Dr.-Ing. B. Krämer
Informationstechnik
Prof. Dr.-Ing. W.A. Halang
Prozeßsteuerung und Regelungstechnik
Prof. Dr.-Ing. H. Hoyer
Optische Nachrichtentechnik
Prof. Dr.-Ing. J. Jahns
Herausgeber:
Satz:
Vertrieb:
Bauelemente der Elektrotechnik
Prof. Dr.rer.nat. W. Fahrner
Elektrische Energietechnik
Prof. Dr.-Ing. D. Hackstein
Elektronische Schaltungen
Prof. Dr.-Ing. H. Wupper
Kommunikationssysteme
Prof. Dr.-Ing. F. Kaderali
Prof. Dr.-Ing. B. Krämer
FernUniversität Hagen
Nur über Internet: http://www.fernuni-hagen.de/etit/fachbereich/forschung/index.html
Forschungsbericht 2/2006
Architektur eines verteilten Lernobjektrepositoriums
Sascha Bobrowski, Olaf Nowaczyk
2006
Zur Veröffentlichung empfohlen von Prof. Dr.-Ing. Krämer
© Sascha Bobrowski, Olaf Nowaczyk 2006
Architektur eines verteilten Lernobjektrepositoriums1
Sascha Bobrowski, Olaf Nowaczyk
FernUniversität in Hagen, 58084 Hagen, Germany
{sascha.bobrowski|olaf.nowaczyk}@fernuni-hagen.de
Kurzfassung
Die Gestaltung einer Architektur für ein Lernobjektrepositorium weist einige Besonderheiten auf, die es zu beachten gilt. Auf Grund der Hemmschwelle, Inhalte auf
einem zentralen Server einzustellen, was einen Verlust der Kontrolle über die Materialien bedeuten würde, ist für das CampusContent-Repositorium eine verteilte Architektur vorgesehen. Somit besteht die Möglichkeit, einen eigenen Server aufzusetzen, auf dem die Materialien bereitgestellt und allen Nutzern des Repositoriums zur
Verfügung gestellt werden. Weiterhin ist die Möglichkeit eines Schutzes von bestimmten Inhalten vorgesehen, um einen Zugriff nur mit bestimmten Rechten zu ermöglichen. Das vorliegende Dokument gibt einen Überblick sowohl über die voraussichtlichen Module und Funktionalitäten des Repositoriums, als auch einen
Ausblick auf die benötigten und verwendeten Technologien und physischen Ressourcen. Zur Trennung der verschiedenen Aspekte der Gesamtarchitektur werden
hierbei verschiedene Sichten verwendet, welche sich am Open Distributed Processing (ODP) Referenzmodell für offene, verteilte Datenverarbeitung ( ISO, 1996) orientieren.
Keywords: Repositorium, Architektur, CampusContent
1
Überblick
Aufgrund der Komplexität und des Umfangs der Gesamtarchitektur des CampusContentRepositoriums wurde im Folgenden eine logische Unterteilung in fünf aufeinander aufbauende Sichten vorgenommen (Abbildung 1). Eine Grundlage hierfür bot das Open Distributed
Processing (ODP) Referenzmodell für offene, verteilte Datenverarbeitung (ISO, 1996). Dieses
stellt einheitliche Konzepte und Regeln bereit, um eine Architektur für verteilte Anwendungen umfassend zu beschreiben und hierbei auch die besonderen Anforderungen an verteilten
Anwendungen wie Transparenz der Verteilung, Flexibilität von Anwendungskomponenten
und Portabilität auf andere Plattformen zu modellieren. Um eine hohe Verfügbarkeit der Infrastruktur zu gewährleisten und den am Leistungszentrum beteiligten Autor(inn)en und Institutionen einen hohen Grad an Autonomie im Hinblick auf Organisation und Betrieb des von
Ihnen genutzten Teils des Leistungszentrums einräumen zu können, wird im Projekt eine verteilte Architektur bevorzugt. Dies ermöglicht es den Lehrenden verschiedener Institutionen
1
Dieser Beitrag ist entstanden im Rahmen des Forschungsprojektes "CampusContent"
(http://www.campuscontent.de), das unter der Kennziffer 44200719 von der Deutschen Forschungsgemeinschaft (DFG; http://www.dfg.de) gefördert wird.
-1-
ihre Materialien auf ihren eigenen Rechnern zu halten, was die Kontrollmöglichkeiten erhöhen und die Hemmschwelle zur Einstellung von Lernmaterialien senken dürfte.
Um die hohe Komplexität einer verteilten Anwendung besser erfassbar zu machen, wurden unterschiedliche Sichten eingeführt, die so genannten Viewpoints. Das ODP Referenzmodell bietet fünf Viewpoints an, die jeweils unterschiedliche Aspekte und Phasen in der Entstehung als auch beim Betrieb einer verteilten Anwendung abdecken, ohne sich dabei
wesentlich zu überschneiden. In Rahmen dieses Papiers sollen noch keine Spezifikationen
abgeben werden, sondern verschiedene Alternativen vorgestellt und verglichen werden und
unter Umständen eine unverbindliche Empfehlung abgegeben werden.
Abbildung 1: Viewpoints des CampusContent-Repositorium
2
Enterprise Viewpoint
Wesentliche Aspekte des „Enterprise Viewpoints“ sind die Modellierung der Zielsetzungen,
Verfahren und Regeln (vgl. SAGA, 2003:32) der Anwendung. Zentrales Ziel von CampusContent ist die Bereitstellung einer Infrastruktur für den Austausch von Lehr- und Lernmaterialien zwischen verschiedenen Institutionen und damit eine Förderung der Wiederverwendung, sowie die Entwicklung eines Systems zur Unterstützung der Lehrenden bei der
Erzeugung und Nutzung didaktischer Szenarien. Weiterhin sollen im Rahmen von CampusContent die Lernmaterialen mit pädagogischen Funktionen wie Lernzielen und Handlungsempfehlungen angereichert werden, um sie didaktisch „aufzuwerten“. Für das geplante Repositorium ergeben sich daraus Anforderungen an geeignete Werkzeugfunktionen und die
Gestaltung der Benutzungsschnittstelle des Repositoriums.
-2-
Abbildung 2 gibt einen Überblick über die geplante Architektur und eine mögliche Organisation der Zugriffsrechte auf die Inhalte des verteilten CampusContent-Repositoriums.
Abbildung 2: Verteilungsarchitektur und Nutzergruppen des CC-Repositoriums
Das verteilte Repositorium in Abbildung 2 besteht aus insgesamt n Installationen der
Software bei verschiedenen Institutionen (Universitäten, Fachhochschulen). Die unterschiedlich schraffierten Flächen der Teilrepositorien und Anwendergruppen in Abbildung 2 haben
dabei folgende Bedeutung. Die Schraffuren bei den Repositorien stehen für einen Anteil geschützter Inhaltsobjekte, die nicht allgemein zugänglich sind und für die gesonderte Zugriffsrechte notwendig sind. In Abbildung 2 besitzt die dritte Anwendergruppe zum Beispiel die
erforderlichen Zugriffsrechte, um auf die geschützten Inhalte des zweiten Repositoriums
zugreifen zu können (identische Schraffur).
Das verteile Repositorium wird mit Inhalten durch verschiedene Domänengruppen gespeist. Domänengruppen umfassen Expertinnen und Experten desselben Fachgebietes, derselben Bildungseinrichtung, mit ähnlichen Interessen oder ähnlichem Profil, die Inhalte in das
Repositorium einstellen. Dabei ist es durchaus realistisch, dass eine Domänengruppe die In-3-
halte nur auf bestimmten, ihrer Institution zugehörigen Servern verwaltet. Die Anwendergruppen repräsentieren verschiedene Nutzergruppen, die Inhalte aus dem Repositorium beziehen. Bei den verschiedenen Gruppen in Abbildung 2 ist zu betonen, dass es sich dabei nur um
Rollen im softwaretechnischen Sinn handelt. Reale Personen können sowohl mehreren Anwender- als auch Domänengruppen zugehörig sein.
Kommuniziert wird mit dem System über eine Schnittstelle, welche verschiedene (Web-)
Services wie das Suchen, Publizieren und Herunterladen von Inhalten anbietet. Diese Schnittstellen werden im Computational Viewpoint genauer angegeben.
3
Information Viewpoint
Mit dem „Information Viewpoint“ werden die semantische Struktur und somit die inhaltlichen
Bezüge der modellierten Daten innerhalb der Anwendung festgelegt. Nach dem CampusContent-Modell werden Materialien begrifflich in möglichst didaktikfreie Informationsobjekte auf
der einen Seite sowie den damit verbindbaren Beschreibungen der intendierten Lernaktivitäten (Handlungsempfehlungen, Lernziele) auf der anderen Seite unterschieden (Heyer, 2005;
Heyer, 2006; Bobrowski, 2006). Der daraus zu erwartende Vorteil ist die Erhöhung der Wiederverwendbarkeit sowohl der fachspezifischen Inhalte, als auch der weitestgehend generisch
zu haltenden und damit vielseitiger einzusetzenden didaktischen Einbettung.
Abbildung 3: Information Viewpoint (Klassendiagramm aus Heyer, 2006)
-4-
Abbildung 3 zeigt, dass Informationsobjekte (im Diagramm als Resource bezeichnet) mit bestimmten Lernzielen verbunden werden können, welche einem intendierten kognitiven Prozess und einem Wissenstyp der Taxonomie Anderson & Krathwohls (2001) zugeordnet sind.
Die Klasse Educational_scenario ist im obigen Diagramm noch ein Platzhalter und ihre
Verbindung zu anderen Klassen ist zurzeit noch Gegenstand der Forschungsarbeit.
Für die Ressourcen können generische Lernziele empfohlen werden, welche sich am
Knowledge_type des Informationsobjektes orientieren. Weiterhin wird bei den Lernzielempfehlungen davon ausgegangen, dass sich für die verschiedenen Ausprägungen der Wissensdimension spezielle Ausprägungen der Prozessdimension am Besten eignen (Tabelle 1; Anderson & Krathwohl, 2001:239f). Für Faktenwissen eignet sich ein kognitiver Prozesse der
Kategorie Erinnern am Besten, während sich für konzeptuelles und prozedurales Wissen eher
Prozesse der kognitiv höherwertigeren Kategorien Verstehen und Anwenden anbieten.
Zusätzlich sind Lernziele noch von den Autoren frei definierbar und explizit einem Informationsobjekt zuweisbar, was unserer Meinung nach die semantisch hochwertigste Form
der Verbindung bildet.
Erinnern
Faktenwissen
Verstehen
Anwenden
███
Konzeptwissen
███
Prozesswissen
███
Tabelle 1: Zusammenhang Wissensart -> kognitiver Prozess (Ausschnitt aus der Anderson & Krathwohl
Taxonomie, 2001)
4
Computational Viewpoint
Hauptaufgabe des „Computational Viewpoints“ ist die Modellierung der einzelnen Komponenten des Repositoriums, sowie die Festlegung der Kommunikationsschnittstellen.
Abbildung 4 gibt einen Überblick über die vorgesehenen Komponenten des CampusContentRepositoriums. Dabei stellen Client-Programme über standardisierte Schnittstellen verschiedene Anfragen an vom System bereitgestellte und unabhängig voneinander funktionierende
Services.
-5-
Abbildung 4: Computational Viewpoint
4.1 Komponenten des Repositoriums
Folgende Komponenten gelten für ein Lernobjektrepositorium als essentiell und sollten auch
im CampusContent Repositorium Verwendung finden.
4.1.1
Benutzerverwaltung
Das Modul für die Benutzerverwaltung ist verantwortlich für das Nachhalten der Benutzerprofile, der Zugriffsrechte einer Person sowie sämtlicher Angaben einer Person, die für eine
gewünschte Personalisierung des Portals notwendig sind. Benutzerinnen steht es offen, Angaben zu ihrem für sie interessantem/relevanten Themenbereich zu machen, der bei einer Suche
nach Lernmaterialien voreingestellt ist. Weiterhin können persönliche Suchabfragen gespeichert werden, um sie zu einem späteren Zeitpunkt zu reaktivieren. Suchanfragen, die nicht
zum Erfolg führten, können als Filter für Services gespeichert werden, die bei der Ablage
eines neuen Objekts die gespeicherten Filter automatisch aktivieren und, sollte die Suchabfrage auf das neue Objekt passen, eine Meldung an die Besitzerinnen der passenden Filter
versenden.
4.1.2
Versionsmanagement
In das Repositorium eingestellte Materialen sollen von allen berechtigten Benutzern bearbeitet und damit verbessert werden können. Das Versionsmanagement stellt sämtliche Funktionalitäten zur Verfügung, um Varianten und Versionen von Lernmaterialien zu verwalten und
frühere Versionen wieder herzustellen. Bei einer Zusammenstellung verschiedener Materia-6-
lien zu größeren Einheiten kann es zu Inkompatibilitäten kommen, wenn eine Teileinheit einer zwischenzeitlichen Änderung unterzogen wurde. Daher sollten alle Versionen separat
gespeichert werden. Lehrende, welche diese Einheit in ihrem Kurs einsetzen, werden über
eine Alert-Funktionalität benachrichtigt, ob sie in ihrer Kurszusammenstellung auf die neue
Version umstellen möchten. Die separate Speicherung aller neuen Version ist allerdings sehr
aufwändig, speicherintensiv und bei kleineren Änderungen oft unnötig. Es gilt daher im Laufe
des Projektfortschritts einen Kompromiss zwischen möglichen Inkompatibilitäten und hohem
Aufwand zu finden.
4.1.3
Autorenwerkzeuge
Autorenwerkzeuge bieten verschiedene Möglichkeiten, bestehende Inhalte zu modifizieren
oder neue zu erstellen. Dabei müssen Funktionalitäten zum Einbinden von Grafiken, Videos
und anderen Multimedia-Elementen vorhanden sein. Gespeichert wird das neue erstellte Material im XML-Format, wobei eingebundene Elemente wie Grafiken innerhalb des XMLCodes referenziert werden.
4.1.4
Import / Export
Materialien aus anderen Repositorien und Lernmanagementsystemen (LMS) können über die
Import-Schnittstelle des CampusContent-Repositoriums eingepflegt werden. Weiterhin können Materialien exportiert werden, um sie in anderen LMS einsetzbar zu machen. Für das
Projekt CampusContent bieten sich verschiedene Austauschformate wie beispielsweise
SCORM an. Dabei wird die Version 1.2 von SCORM im Gegensatz zur Version
SCORM2004 bereits von nahezu jedem LMS unterstützt. Hierbei sei angemerkt, dass zwar
der eigentliche Inhalt exportiert werden kann, doch der didaktische Mehrwert in Form entsprechender Metadaten nach dem CampusContent-Modell verloren geht, da Bestandteile wie
zum Beispiel Handlungsempfehlungen, Lernziele und eine Einordnung in eine Prozess- und
Wissensdimension im SCORM-Standard nicht vorgesehen sind.
4.1.5
Ressourcenverwaltung
Hauptaufgabe dieses Moduls ist die Verwaltung sämtlicher Materialien (Informationsobjekte,
Übungsaufgaben, Lernziele etc.). Dazu gehören die physische Strukturierung auf den Dateiservern2 sowie die Sicherstellung der korrekten Adressierung der Materialien, um eine fehlerfreie Präsentation zu gewährleisten. Weiterhin speichert die Ressourcenverwaltung die Be2
Ob Fileserver zum Einsatz kommen oder die Lerninhalte als „Binary Large Objects“ (BLOBs) in der Datenbank gespeichert werden, ist bisher noch unklar.
-7-
schreibung der Zusammenstellung von Materialien zu größeren Einheiten und die Verknüpfung von Materialien. Ein Beispiel für eine solche Zusammenstellung ist die Gestaltung von
Lernobjekten im Projekt CampusContent. Dabei werden Informationsobjekte mit didaktischen
Aspekten wie Lernzielen, Handlungsempfehlungen und Übungsaufgaben „angereichert“.
4.2 Web-Services
Das CampusContent-Repositorium entspricht dem Aufbau einer Service-orientierten Architektur (SOA), wobei verschiedene Web-Services angeboten werden (vgl. Abbildung 4). Die
Kommunikation zwischen den Clients und dem verteilten Repositorium erfolgt dabei über das
Protokoll SOAP3. Eingehende Suchanfragen (suchen) werden an alle dem verteilten Repositorium zugehörigen Installationen der Software weitergeleitet und das Suchergebnis an die Benutzerin weiter gegeben (liefern). Suchanfragen ohne Ergebnis können im individuellen Nutzerprofil gespeichert werden. Falls im Zeitverlauf Materialien eingestellt werden, welche der
Suchanfrage entsprechen, wird die Benutzerin darüber in Kenntnis gesetzt (alarmieren). Webservices wie erzeugen und aktualisieren ermöglichen eine Erstellung neuer und die Modifikation bereits bestehender Materialien. Im Repositorium hinterlegte Materialien können über
den Dienst veröffentlichen freigegeben werden, wobei optional der Zugriff auf bestimmte
Nutzergruppen beschränkt werden kann. Weiterhin sollen sich alle Materialien über einen
bereitgestellten Service (kombinieren) miteinander zu größeren Einheiten zusammenstellen
lassen. Der Webservice „mit Lernzielen verbinden“ stellt eine wichtige Basisfunktionalität
des CampusContent Repositoriums dar. Wie im Information Viewpoint bereits spezifiziert,
werden didaktische Aspekte aus den Lernobjekten zunächst herausgetrennt um zu möglichst
didaktikfreien Informationsobjekten zu gelangen. Der Webservice bietet nun die Möglichkeit
die Informationsobjekte im Sinne einer „late composition“ mit verschiedenen Lernzielen zu
verbinden um eine Anpassung an verschiedene Nutzungsumfelder zu ermöglichen
(Bobrowski, 2006). Analog hierzu sind Mechanismen zur Verbindung von Informationsobjekten mit Übungsaufgaben und Handlungsempfehlung vorgesehen.
5
Engineering Viewpoint
Der „Engineering Viewpoint“ beschreibt die Verteilung eines Systems auf physische Ressourcen und gibt die Verbindungen zwischen den einzelnen Elementen wieder. Hierzu gehören beispielsweise Rechner- und Kommunikationsinfrastrukturen sowie die verschiedenen
3
seit Version 1.2 keine offizielle Abkürzung mehr. Davor die Abkürzung für Simple Object Access Protocol.
-8-
Arten von Software-Plattformen, die in verteilten Systemen zum Tragen kommen. Auch wenn
für die Erstellung eines Funktionsprototyps Gesichtspunkte wie Performanz unter großer Last,
Skalierung, Verteilung und Hochverfügbarkeit zunächst nachrangig sind, sollten diese trotzdem möglichst früh in den Planungen mitbedacht werden, um eine spätere Erweiterung auf
den Produktivbetrieb zu erleichtern. Die hierbei zu bedenkenden Punke (vgl. BSI, 2004) sind:
Skalierbarkeit von Systemen und Infrastruktur
Das geplante Repositorium muss sowohl bezüglich Anzahl und Umfang der abgelegten Inhalte, als auch bezüglich der Nutzerzahl möglichst gut skalierbar sein. In einem verteilten System
sind Replikationsmechanismen für Nutzerprofile, rechnerübergreifende Single-sign-onMechanismen (Blum, 2004) und eine standortübergreifende Indizierung der Inhalte, etwa
durch Vergabe einer eindeutigen Netzwerkkennung (global_DOI), vorzusehen.
Höchstmögliche Verfügbarkeit
Hierzu gehört sowohl die zuverlässige, robuste Zugreifbarkeit auf die Systeme im Sinne einer
Rund-um-die-Uhr-Verfügbarkeit, als auch eine hohe Verfügbarkeit der bereitgestellten Funktionalität auf möglichst vielen Client- und Server-seitigen Plattformen.
Physischer Schutz der Systeme
Für den Produktivbetrieb sollte beachtet werden, dass die Rechnersysteme in dafür speziell
ausgerüsteten Räumen des jeweiligen Rechnerbetriebs bzw. Hochschulrechenzentrums unterzubringen sind. Diese sind zumeist mit einer redundanten Stromversorgung und Klimatisierung zum Schutz der Rechner vor Überhitzung ausgestattet. Datensicherungen müssen regelmäßig nach einem Datensicherungsplan von dafür geschultem Personal durchgeführt und an
einem sicheren (feuerfesten) Ort, getrennt von den Rechnersystemen gelagert werden.
Ein Vorschlag für den Engineering Viewpoints des CampusContent Repositoriums ist in
Abbildung 5 gegeben. Hierbei ist für jeden CampusContent-Standort eine aus Datenbank-,
Applikations- und Web-Server bestehende Infrastruktur vorgesehen. Diese drei Server sind
sauber durch Protokolle getrennt und der optimale Ansatzpunkt für eine Skalierung. Für den
bei CampusContent im ersten Projektabschnitt geplanten Prototyp soll die Skalierung zunächst jedoch in die andere Richtung betrieben werden, indem Datenbank-, Applikations- und
Web-Server auf einem einzelnen Prozessor ausgeführt werden. Mit der Vorwegplanung von
Schnittstellen und Protokollen, die zunächst einen Mehraufwand darstellt, wird eine spätere
Erweiterung und Verteilung der Ressourcen entscheidend erleichtert.
-9-
- 10 Abbildung 5: Engineering Viewpoint
5.1 Authentifizierungsserver
Wie in Abbildung 5 zu sehen, wird der Zugang zu den an verschiedenen Standorten verteilten
Repositorien durch eine zentrale Authentifizierungsstelle gewährt. Diese Stelle verwaltet die
Nutzerprofile und Zugangsberechtigungen der registrierten Benutzerinnen. Da es sich hierbei
um personenbezogene Daten handelt, erfordert der Authentifizierungs-Server besondere technische und organisatorische Maßnahmen, um die Datensicherheit konform zum Bundesdatenschutzgesetz4 zu gewährleisten.
5.2 Datenbankserver
Der Datenbank-Server dient zur Speicherung der Referenzen auf die auf dem Dateiserver5
befindlichen (Lern-)Inhalte des Repositoriums. Weiterhin werden in ihm auch von den Benutzern erstellte Strukturierungen der Mediendateien abgelegt. Für die konkrete Ausprägung
empfiehlt es sich aus verschiedenen Gründen, die an dieser Stelle aus Platzgründen nicht diskutiert werden sollen, eine bewährte relationale Datenbank zu verwenden. Als Standardsprache für die Abfrage und Manipulation von Daten in relationalen Datenbanken hat sich SQL
(Structured Query Language) etabliert. Dieser standardisierte Zugang, der gleichzeitig auch
die Austauschbarkeit zwischen verschiedenen Open-Source und kommerziellen Datenbankimplementierungen ermöglicht, wird daher auch für das CampusContent-Repositorium empfohlen. Ein direkter Zugriff auf die Datenbankinhalte durch die Benutzerinnen wird ähnlich
wie schon beim Authentifizierungs-Server unterbunden. Stattdessen wird ausschließlich der
mittelbare Zugriff über die im Folgenden dargestellten Applikations- und Web-Server erlaubt.
5.3 Applikationsserver
Der Applikations-Server stellt den Benutzern verschiedene Dienste in Form von standardisierten Web-Services zur Verfügung (siehe hierzu das Kapitel Web-Services im Computational
Viewpoint). Für den Engineering Viewpoint gesondert herauszustellen sind hier die Replikations- und Indexmechanismen, mit denen ein transparenter, standortübergreifender Zugriff auf
Medieninhalte in verteilten Repositorien ermöglicht werden kann. Mithilfe einer Peer-to-PeerVerteilung können Inhaltsverzeichnisse und Metadaten beständig zwischen den Repositorien
abgeglichen werden, so dass unabhängig vom Einstiegspunkt eine Übersicht über den Gesamtverbund eingeholt werden kann. Alternativ hierzu wären auch Federated-Search-
4
http://bundesrecht.juris.de/bdsg_1990/ (siehe Anlage zu § 9 Satz 1, zuletzt geprüft am 19. Januar 2006)
Dateiserver sind in Abbildung 5 nicht berücksichtigt. Es ist auch möglich, sämtliche Lerninhalte als „binary
large objects“ in der Datenbank zu speichern, womit keine Referenzen mehr notwendig wären.
5
- 11 -
Mechanismen denkbar, die erst im Falle einer konkreten Anfrage entfernte Repositorien über
entsprechende Web-Services durchsuchen. Diese Lösung ist sicherlich weniger aufwändig in
ihrer Implementierung, bedeutet auf Seiten der Benutzer jedoch wesentlich höhere Wartezeiten.
5.4 Webserver
Der Web-Server bietet über das Hypertext Transfer Protokoll (HTTP) einen Zugriff auf die
CampusContent-Inhalte nach außen an, so dass diese unter Verwendung eines StandardBrowsers eingesehen werden können. Er ist verantwortlich für die Verwaltung und korrekte
Auslieferung der vom Applikationsserver generierten Webseiten und damit der Haupteinstiegspunkt in das Repositorium. Über diese Webseiten erfolgt ein Zugriff auf die verschiedenen in Form von Services angebotenen Funktionalitäten des Repositoriums.
6
Technology Viewpoint
Im technologischen Viewpoint werden die Standards und Techniken, welche bei der Implementierung des Repositoriums von Bedeutung sind, spezifiziert. Die hier vorgestellte 4Schichten-Software Architektur entstand unter dem Einfluss verschiedener Grundsatzentscheidungen. Diese beinhalteten vor allem ein komponentenbasiertes Schema für eine schnellere Entwicklung von flexibleren Anwendungssystemen von höherer Qualität und zu reduzierten Kosten.
Auf Grund der Anforderungen für die Verwendung bestimmter Präsentationsformate und
der einfachen Zugriffsmöglichkeit über einen Internetbrowser wurde der technologische
Viewpoint anhand der von Alonso (2004:6f) vorgeschlagenen vier Teilschritte eines TopDown-Entwurfs vorgenommen.
- 12 -
Abbildung 6: Vier-Schicht Architektur des CC-Repositoriums
6.1 Clientschicht
Der Clientzugriff auf das CampusContent Repositorium sollte keine spezielle Software benötigen, sondern per Browser erfolgen können. Bei einer gewünschten Zugriffsmöglichkeit per
PDA oder Mobiltelefon sind auf Grund des erheblich kleineren Formats des Ausgabegerätes
verschiedene Technologien und Standards in der Präsentationsschicht zu berücksichtigen.
6.2 Präsentationsschicht
Für den Zugriff per Webbrowser sind dabei etablierte Auszeichnungssprachen wie HTML6
und XML7 vorgesehen sowie CSS8 zur W3C-konformen Formatierung der Webseiten. Für
Mobiltelefone und andere Ausgabemedien mit kleinem Bildschirm ist HTML nicht konzipiert
und nur eingeschränkt brauchbar. Für diesen Bereich haben sich Standards wie UMTS9 und
GSM10, sowie Auszeichnungssprachen wie WML11 durchgesetzt (Krämer, 2005). Bei der
Verwendung von Java als Programmiersprache, kommen unter Umständen noch Technologien wie Applets und Java Server Pages zum Einsatz. Weiterhin können die HTML-Seiten
durch dynamische Javascript-Inhalte ergänzt werden. Zu beachten ist hierbei, dass nicht jeder
6
Hypertext Markup Language
eXtensible Markup Language
8
Cascading Stylesheets
9
Universal Mobile Telecommunications System
10
Global System for Mobile Communications
11
Wireless Markup Language
7
- 13 -
Benutzer Javascript in seinem Browser aktiviert hat. Daher ist auch im Hinblick auf eine einzuhaltende Barrierefreiheit darauf zu achten, dass Javascript zwar verwendet, doch keine
Grundvoraussetzung für die Benutzung der Funktionalitäten des Repositoriums sein darf.
6.3 Mittelschicht
Die Mittelschicht beinhaltet die wesentlichen Bestandteile der Anwendungslogik. Dabei werden die Daten aus der Persistenzschicht die durch Datenbanksysteme realisiert wird, gelesen,
durch die Anwendungslogik modifiziert und schließlich der Präsentationsschicht übergeben.
Für die Implementierung der Anwendungslogik kommen als mögliche Alternativen J2EE in
Kombination mit einem Application-Server, J2SE mit Tomcat als Servlet-Engine oder PHP in
Kombination mit dem Webserver Apache in Frage. Für die Entwicklung von Anwendungen,
dessen Bestandteile auf Wiederverwendung ausgelegt sind, hat sich Java 2 Enterprise Edition
(J2EE) als besonders geeignet herausgestellt. Dabei ist die Enterprise Edition von Java mit
seinen Programmierschnittstellen und Bibliotheken speziell für die Entwicklung von komponentenbasierter Software ausgelegt. Gegenüber der Standard Edition von Java werden unter
anderem Technologien wie Enterprise Java Beans (EJB) und WebServices geboten. Die
Zugriffe auf die Datenbank erfolgen mit Hilfe von Java Database Connectivity (JDBC). Zur
Bereitstellung einer Laufzeitumgebung für J2EE Komponenten wird ein spezieller Application-Server (vgl. Abbildung 6) benötigt. Wichtige Vertreter der kommerziellen ApplicationServer sind BEA WebLogic, IBM WebSphere und die Application Server von Oracle und
SAP. Unter den Open Source Application Servern ist vor allem JBoss zu nennen. JBoss
zeichnet neben seinen niedrigen Kosten vor allem seine Stabilität und seine Standardkonformität aus.
Die Standardedition von Java erlaubt die Erstellung von „normalen“ Java Beans, welche
in Java Server Pages (JSP) eingebunden werden können. Die Java Server Pages werden dabei
von Tomcat in Servlets übersetzt, was eine Ausführung in der Servlet Engine ermöglicht.
Verschiedene Frameworks wie zum Beispiel Struts bilden bei beiden Java Editionen eine robuste Grundlage für die Entwicklung von umfangreichen Web-Applikationen.
Als Alternative für einfache E-Learning Anwendungen bietet sich als Programmiersprache (die Skriptsprache) PHP in der Version 4.X oder 5.X an in Kombination mit Apache als
WebServer an. PHP wurde speziell für die Bedürfnisse des Webs entwickelt und verfügt über
eine sehr große Nutzergemeinschaft. Mit der Version 5 wurde die in der vorigen Version eingeführte Objektorientierung weiter ausgebaut. Auf Grundlage der Programmiersprache PHP
- 14 -
wurden im Rahmen der CampusSource12 Initiative bereits verschiedene Learning Management Systeme wie Moodle oder ILIAS realisiert.
6.4 Persistenzschicht
Für die Speicherung der Daten der Benutzer und für die Ressourcenverwaltung bieten sich in
der Persistenzschicht verschiedene Datenbankmodelle an. Während das hierarchische und das
Netzwerkdatenbankmodell zunehmend an Bedeutung verlieren und nur noch in Spezialfällen
eingesetzt werden, besitzen aus heutiger Sicht das relationale und das objektorientierte Datenbankmodell die größte Relevanz.
In relationalen Datenbanken werden die Daten in verschiedenen zweidimensionalen Tabellen gespeichert. Dabei bildet jede Spalte der Tabelle ein Attribut und jede Zeile einen Datensatz (auch Tupel genannt). Jeder Datensatz verfügt in der Regel über einen eindeutigen
Primärschlüssel. Die Verknüpfungen der einzelnen Tabellen untereinander sind über Fremdschlüssel realisiert.
Objektorientierte Datenbanken speichern ihre Daten in Form von Objekten im Sinne der
objektorientierten Programmierung. Ein Objekt ist hierbei ein Exemplar einer Klasse, welche
durch eine Menge von Attributen und Methoden definiert ist. Die Vorteile von objektorientierten Datenbanken gegenüber den relationalen Datenbanken sind unter anderem die Möglichkeiten, Klassen ineinander zu schachteln (d.h. ein Objekt einer Klasse ist Ausprägung eines Attributes einer anderen Klasse) und die Verwendung von Vererbungsstrukturen.
Nachteile gegenüber relationalen Datenbanken sind die geringere Verbreitung und die etwas
schlechtere Performance.
12
http://www.campussource.de
- 15 -
Literatur
Alonso, Gustavo; Casati, Fabio; Kuno, Harumi; Machiraju, 2004: Web-Services − Concepts,
Architectures and Applications, Springer Verlag Berlin, 2004
Anderson, Lorin W.; Krathwohl, David R. [Eds.], 2001: A Taxonomy For Learning, Teaching, And Assessing : A Revision of Bloom’s Taxonomy of Educational Objectives, Complete
Edition. New York: Addison Wesley Longman.
Blum, Thorsten, 2004: Entwicklung eines Single-Sign-On-Verfahrens auf Basis einer Certification Authority für verteilte Web-Systeme zur Integration und sicheren Nutzung angebotener
Dienste, 2004, Forschungsbericht, ISSN 0945-0130 1/2004, http://www.fernunihagen.de/etit/fachbereich/forschung/ForBer1-2004_blum.pdf, geprüft am 16.03.2006
Bobrowski, Sascha; Nowaczyk, Olaf: Übertragung softwaretechnischer Entwurfsmethoden
auf die Entwicklung wieder verwendbarer E-Learning Inhalte, 2006, eingereicht für Gesellschaft für Medien in der Wissenschaft e.V., GMW06
BSI, 2004: IT-Grundschutzhandbuch, Bundesamt für Sicherheit in der Informationstechnik,
November 2004, http://www.bsi.bund.de/gshb/deutsch/index.htm , geprüft am 01.02.2006.
Heyer, Susanne, 2005: An Analysis of Learning Resources Using a Cognitive Process Taxonomy, International Conference Interactive Computer Aided Learning 2005: Ambient and Mobile Learning . Kassel: Kassel University Press.
Heyer, Susanne, 2006: Pedagogical Enrichment of Information Objects, eingereicht für Integrated Design and Process Technology, IDPT-2006
ISO, 1996: ISO/IEC 10746-3: Information Technology − Open Distributed Processing − Reference Model: Architecture, Genf 1996
Krämer, Bernd, 2005: Mobile Learning: The Next Generation of Learning, FernUniversität’s
Contributions to the 2nd Year of the Leonardo Project mlearn2, 2005, http://www.fernunihagen.de/etit/fachbereich/forschung/Forschungsbericht_5_2005.pdf, geprüft am 16.03.2006
SAGA, 2003 − Standards und Architekturen für E-Government-Anwendungen Version 2.0,
http://www.kbst.bund.de/Anlage304275/SAGA-Dokument+Version+2.0+(2,3+MB, geprüft
16.01.2006
- 16 -