Erklärung - home.hs

Erklärung
I
Erklärung
Hiermit erkläre ich, dass ich die vorliegende Diplomarbeit selbständig angefertigt habe.
Es wurden nur die in der Arbeit ausdrücklich benannten Quellen und Hilfsmittel
benutzt. Wörtlich oder sinngemäß übernommenes Gedankengut habe ich als solches
kenntlich gemacht. Die Arbeit wurde in gleicher oder ähnlicher Form keiner anderen
Prüfungsbehörde zur Erlangung eines akademischen Grades vorgelegt.
Ort, Datum
Unterschrift
Kurzfassung
II
Kurzfassung
Gegenstand dieser Arbeit ist die Ausarbeitung eines Konzepts für die Verwaltung von
E-Learning Prozessen bei kooperierenden Content Management Systemen (CMS) auf
der Grundlage einer vorhergehenden Bachelorthesis (Kim Matthäß: „Kontrollierter
automatischer
Datenaustausch
zwischen
befreundeten
Content
Management
Systemen“, HS Karlsruhe, Fak. WI, 2005) .
Hintergrund der Arbeit ist die Idee, dass sowohl Lernobjekte als auch die
Administration des Lehrbetriebs auf mehreren Content Management Systemen verteilt
sein können. Hierbei sind über mehrere CMS verteilte Lernobjekte wie Projektaufgaben
und Objekte der Administration wie Semester-/Veranstaltungsdaten zu verwalten.
In dieser Arbeit wird ein Lösungsvorschlag für die Verwaltung von E-Learning
Prozessen bei kooperierenden Content Management Systemen vorgestellt. Um die
Realisierbarkeit des Konzepts nachzuweisen, wird zunächst eine Testumgebung
implementiert. Diese Testumgebung wird durch zwei konkrete Content Management
Systeme
implementiert,
die
verteilte
Lernobjekte
und
Administrationsobjekte
beinhalten.
Der Lösungsvorschlag für die gegebene Problemstellung basiert auf der Technologie
der Web Services. Die beiden CMS werden durch die Web Services in der Verwaltung
komplexer Lernprozesse, wie z.B. der Vorkorrektur durch Tutoren und der endgültigen
Bewertung durch den Dozenten, unterstützt.
Schließlich werden auf der Basis des erstellten Prototyps die Möglichkeiten der
Verwaltung von Lernprozessen durch Workflow-Management anhand von BPEL und
XML-Netzen diskutiert.
Schlagwörter: BPEL, CMS, Content Management Systeme, E-Learning, Web
Services, Workflow-Management, XML-Netze
Inhaltsverzeichnis
III
Inhaltsverzeichnis
Erklärung.........................................................................................................................I
Kurzfassung...................................................................................................................II
Inhaltsverzeichnis........................................................................................................ III
Abbildungsverzeichnis.................................................................................................V
Tabellenverzeichnis..................................................................................................... VI
Abkürzungsverzeichnis..............................................................................................VII
1 Aufgabenstellung..................................................................................................... 1
2 Zielsetzung...............................................................................................................2
3 Begriffsklärung und Ausgangsszenario................................................................ 3
3.1 Content Management Systeme...................................................................... 3
3.1.1 Allgemeines............................................................................................ 3
3.1.2 Klassifikation von CMS........................................................................... 5
3.1.3 Probleme bei verteilten Inhalten............................................................. 6
3.2 E-Learning...................................................................................................... 7
3.2.1 Allgemeines............................................................................................ 7
3.2.2 Formen von E-Learning.......................................................................... 9
3.2.3 E-Learning auf der Basis von CMS...................................................... 10
3.3 Web Services................................................................................................11
3.3.1 Allgemeines.......................................................................................... 11
3.3.2 Transaktionen und Prozesse mit Web Services................................... 13
3.3.3 Workflow Management bei Web Services............................................ 15
3.4 Ausgangsszenario........................................................................................ 17
3.4.1 Allgemeines.......................................................................................... 17
3.4.2 Auswahl eines CMS..............................................................................17
3.4.3 Architektur des Gesamtsystems........................................................... 20
4 Konzept zur Verwaltung von E-Learning Objekten auf der Basis von Web
Services............................................................................................................ 22
4.1
Modul „Zeiterfassung“................................................................................ 22
4.1.1 Problembeschreibung...........................................................................22
4.1.2 Funktionsbeschreibung.........................................................................22
4.1.3 Modell................................................................................................... 23
4.1.3.1 Aktivitätsdiagramm...................................................................24
4.1.3.2 Use-Case................................................................................. 27
4.1.3.3 Sequenzdiagramm................................................................... 28
Inhaltsverzeichnis
IV
4.1.4 Lösungsvorschlag................................................................................. 29
4.2 Modul „Verwaltung von E-Learning Objekten“..............................................30
4.2.1 Problembeschreibung...........................................................................30
4.2.2 Funktionsbeschreibung.........................................................................30
4.2.3 Modell................................................................................................... 31
4.2.3.1 Aktivitätsdiagramm...................................................................32
4.2.3.2 Use-Case................................................................................. 35
4.2.3.3 Sequenzdiagramm................................................................... 37
4.2.4 Lösungsvorschlag................................................................................. 39
5 Prototypische Realisierung...................................................................................41
5.1 Modellierung................................................................................................. 41
5.1.1 Zeiterfassung........................................................................................ 41
5.1.1.1 Architektur................................................................................ 41
5.1.1.2 Klassendiagramm.................................................................... 42
5.1.2 Verwaltung von E-Learning Objekten................................................... 43
5.1.2.1 Architektur................................................................................ 43
5.1.2.2 Klassendiagramm.................................................................... 44
5.2 Implementierung........................................................................................... 48
5.2.1 Code-Beispiele Client (Webseiten).......................................................50
5.2.2 Code-Beispiel Server (Web Services).................................................. 51
6 Feasibility Study Workflow-Management............................................................ 57
6.1 BPEL.............................................................................................................57
6.2 XML-Netze.................................................................................................... 61
7 Sicherheitsaspekte................................................................................................63
7.1 Allgemeine Sicherheitsanforderungen.......................................................... 63
7.2 Sicherheitslösungen für Web Services......................................................... 65
8 Zusammenfassung und Ausblick......................................................................... 67
Anhang: Quelltexte..................................................................................................... 70
Glossar......................................................................................................................... 81
Literaturverzeichnis.................................................................................................... 83
Stichwortverzeichnis.................................................................................................. 85
Abbildungsverzeichnis
V
Abbildungsverzeichnis
Abbildung 3.1: Architektur Gesamtsystem................................................................................................... 20
Abbildung 4.1: Vereinfachtes Modell des Moduls „Zeiterfassung“............................................................... 24
Abbildung 4.2: Studentische Aktivitäten am Modul „Zeiterfassung“............................................................. 25
Abbildung 4.3: Aktivitäten eines Dozenten am Modul „Zeiterfassung“......................................................... 26
Abbildung 4.4: Use-Case Modul „Zeiterfassung“ Student............................................................................ 27
Abbildung 4.5: Use-Case Modul „Zeiterfassung“ Dozent............................................................................. 28
Abbildung 4.6: Sequenzdiagramm Modul „Zeiterfassung“........................................................................... 29
Abbildung 4.7: Vereinfachtes Modell des Moduls „Verwaltung von E-Learning Objekten“.......................... 32
Abbildung 4.8: Aktivitätsdiagramm „E-Learning Objekte“ Student............................................................... 33
Abbildung 4.9: Aktivitätsdiagramm „E-Learning Objekte“ Tutor................................................................... 34
Abbildung 4.10: Aktivitätsdiagramm „E-Learning Objekte“ Dozent............................................................. 35
Abbildung 4.11: Use-Case Modul „Verwaltung von E-Learning Objekten“ Student..................................... 36
Abbildung 4.12: Use-Case Modul „Verwaltung von E-Learning Objekten“ Tutor......................................... 36
Abbildung 4.13: Use-Case Modul „Verwaltung von E-Learning Objekten“ Dozent...................................... 37
Abbildung 4.14: Sequenzdiagramm Modul „Verwaltung von E-Learning Objekten“ Student....................... 38
Abbildung 4.15: Sequenzdiagramm Modul „Verwaltung von E-Learning Objekten“ Dozent........................ 39
Abbildung 4.16: Sequenzdiagramm Modul „Verwaltung von E-Learning Objekten“ Tutor........................... 39
Abbildung 5.1: Komponentendiagramm Modul „Zeiterfassung“................................................................... 41
Abbildung 5.2: Klassendiagramm „Zeiterfassung“........................................................................................42
Abbildung 5.3: Komponentendiagramm Modul „Verwaltung von E-Learning Objekten“ Dozent..................43
Abbildung 5.4: Komponentendiagramm Modul „Verwaltung von E-Learning Objekten“ Student.................43
Abbildung 5.5: Komponentendiagramm Modul „Verwaltung von E-Learning Objekten“ Tutor.....................44
Abbildung 5.6: Pakete Modul „Verwaltung von E-Learning Objekten“......................................................... 44
Abbildung 5.7: Klassendiagramm Modul „Verwaltung von E-Learning Objekten“ Paket Dozent................. 46
Abbildung 5.8: Klassendiagramm Modul „Verwaltung von E-Learning Objekten“ Paket Student................ 47
Abbildung 5.9: Klassendiagramm Modul „Verwaltung von E-Learning Objekten“ Paket Tutor.................... 48
Abbildung 5.10: Die Stellvertreterklasse (Proxyklasse)................................................................................ 49
Abbildung 5.11: Webseite für den Web Service Student..............................................................................52
Abbildung 5.12: Aufruf der Web Methode „GetSemesterKalenderwochen“................................................. 53
Abbildung 5.13: Rückgabewerte der Web Methode „GetSemesterKalenderwoche“................................... 53
Abbildung 6.1: Prozess „Hausaufgabe abgeben“......................................................................................... 58
Abbildung 7.1: Beteiligte Systeme und Angriffsmöglichkeiten bei Web Services.........................................64
Tabellenverzeichnis
VI
Tabellenverzeichnis
Tabelle 3.1: Abgrenzung von Web-Begriffen..................................................................................................3
Tabelle 3.2: Auswahlkriterien für ein CMS................................................................................................... 18
Tabelle 7.1: Sicherheitsstandards für Web Services.................................................................................... 66
Abkürzungsverzeichnis
VII
Abkürzungsverzeichnis
ASP
Active Server Pages
BPEL(4WS)
Business Process Execution Language (for Web Services)
CAE
Computer Aided Engineering
CD
Compact Disc
CMS
Content Management System
DISCO
Discovery of Web Services
GXSL
Graphical XML Schema Definition Language
HP
Hewlett-Packard
HTML
Hypertext Markup Language
HTTP
Hypertext Transfer Protocol
IBM
International Business Machines Corporation
IIS
Internet Information Service
IPSec
Internet Protocol Security
MITM
Man in the middle attacks
MVC
Model View Control
OASIS
Organization for the Advancement of Structured Information
Standards
PHP
Hypertext Preprocessor
SAML
Secure Assertion Markup Language
SOAP
Simple Object Access Protocol
Abkürzungsverzeichnis
VIII
SSL
Secure Socket Layer
UDDI
Universal Description, Discovery and Integration
UML
Unified Modeling Language
VPN
Virtual Private Network
WSCL
Web Services Conversation Language
WSDL
Web Services Description Language
WSFL
Web Services Flow Language
WS-Security
Web Service-Security
W3C
World Wide Web Consortium
XACML
Extensible Access Control Markup Language
XKMS
XML Key Management Specification
XML
Extensible Markup Language
XManiLa
XML Manipulation Language
YAWL
Yet Another Workflow Engine
1 Aufgabenstellung
1
1
Aufgabenstellung
Content Management Systeme (CMS), die im Umfeld des E-Learning zum Einsatz
kommen, sind nicht selten auf die Lerninhalte fokussiert. Die auftretenden Lehr-, Lernund Administrationsprozesse werden häufig nicht ausreichend unterstützt. Aufgabe
dieser Arbeit ist es deshalb, auf der Grundlage bestehender Systeme und Vorarbeiten
an Hand einer prototypischen Implementierung die Einbeziehung prozessorientierter
Aspekte in E-Learning-Anwendungen zu erproben.
Grundidee der Arbeit ist die Vorstellung, dass komplexe Lernobjekte, aber auch
Objekte, die der Administration des Lehrbetriebs dienen, verteilt auf mehrere Content
Management Systeme vorliegen. Die Verteilung reicht von der Verwendung
unterschiedlichster Werkzeuge zur Erzeugung der Lernobjekte durch verschiedene
Beteiligte bis zur Einbeziehung externer Quellen in den Lehr-/Lernprozess. Trotz der
Einbindung vielfältiger Quellen sollen die beteiligten Teilsysteme autonom agieren, d.h.
beispielsweise die Regie über die eigenen Inhalte bewahren. Ein typisches Beispiel für
einen entsprechenden Prozess wäre etwa die Vorkorrektur von Projektarbeiten durch
Assistenten und Tutoren und deren endgültige Bewertung durch den verantwortlichen
Dozenten. Hier sind neben Lernobjekten (z.B. schriftlichen Kursunterlagen) auch
Administrationsobjekte (z.B. Teilnehmerlisten, Terminpläne) zwischen den Beteiligten
zu kommunizieren.
Um ein Gesamtsystem zu konzipieren, das diesem Anspruch genügt, musste zunächst
grundsätzlich geklärt werden, welche technischen Möglichkeiten zur Synchronisation
„befreundeter“ Content Management Systeme bestehen. Dies ist in Form einer
Bachelorthesis bereits geschehen. (Kim Matthäß: „Kontrollierter automatischer
Datenaustausch zwischen befreundeten Content Management Systemen“, HS
Karlsruhe, Fak. WI, 2005)
Der nächste Schritt besteht darin, von der Verwaltung der Lernobjekte hin zu einer
Modellierung des Lernobjekt- bzw. Lernprozess-Managements und schließlich zu einer
aktiven Unterstützung der Abläufe (z.B. Koordination von Tutoren bei der Durchführung
eines Kurses) zu kommen. Dazu sollen die Content Management Systeme, welche die
E-Learning-Plattform bilden, um eine Komponente für das Workflow-Management
ergänzt werden.
2 Zielsetzung
2
Ziel
2
Zielsetzung
ist
die
prototypische
Implementierung
einer
Lernplattform
(DozentWeb,
TutorClient), die über die Verwaltung der Lernobjekte hinaus Funktionen für
prozessorientierte Aspekte miteinander kooperierender CMS anbietet.
Im Einzelnen sind folgende Problemfelder zu bearbeiten:
1. Aufnahme und Analyse der Ergebnisse der o.g. Bachelorthesis
2. Auswahl eines CMS
3. Einrichtung der Testumgebung
4. Prototypische Implementierung einer E-Learning-Plattform (DozentWeb,
TutorClient)
5. Definition der zu betrachtenden Prozesse
6. Implementierung der Funktionen zur Unterstützung des Workflows für
ausgewählte Prozesse durch Web Services
7. Bereitstellung
von
Testfällen
zur
Demonstration
des
Lern-
und
Administrationsobjekt-Managements
8. Prüfung, inwieweit ein Workflow-Management auf der Basis neuerer
Verfahren, wie z.B. BPEL oder XML-Netzen, angebracht und zu realisieren
wäre
3 Begriffsklärung und Ausgangsszenario
3
3
Begriffsklärung und Ausgangsszenario
3.1
Content Management Systeme
3.1.1
Allgemeines
Der Begriff Content Management System (CMS) setzt sich aus drei eigenständigen
Begriffen zusammen: Unter Content werden die Inhalte, wie z.B. Texte, Bilder,
Audiodaten, Videodaten etc. verstanden. Management steht für die Verwaltung dieser
Inhalte. Der Begriff System steht für ein Softwaresystem, das diese Verwaltung, z.B.
die Repräsentation der Zusammenhänge zwischen Textmodulen ermöglicht. Der
überwiegende Teil der zur Zeit verfügbaren Content Management Systeme ist als
browserfähige Webanwendung implementiert. Die relativ neuen Begriffe Content
Management System, Portal-System und Web-Content Management System sind im
aktuellen Sprachgebrauch noch nicht eindeutig definiert. Wenn im weiteren Verlauf
dieser Arbeit der Begriff CMS verwendet wird, dann wird darunter ein Web Content
Management System, also ein CMS zur Verwaltung der Inhalte von Webauftritten
verstanden.
Im aktuellen Sprachgebrauch sind die Begriffe, wie z.B. Webseite, Website und
Homepage, nicht eindeutig definiert. Im Rahmen dieser Arbeit werden diese Begriffe
wie folgt verwendet:
Tabelle 3.1: Abgrenzung von Web-Begriffen
Begriff/
Definition
Einzelne HTML Mehrere HTML Seiten System zur Verwaltung
Seite
von Content
Website
Ja
Nein
Webauftritt
Nein
Ja
Portal
Nein
Nein
Webseite
Nein
Webpage
Homepage
Ja
3 Begriffsklärung und Ausgangsszenario
4
Eine ausführliche Definition des Begriffs Content Management System findet sich z.B.
in [11], dort heißt es:
„A web site's "content" is a combination of different components: text,
graphics, images, scripts, included files such as Flash animations,
audio/video streams or downloadable files. All of these may be
components of one page, included in an HTML page using links or
sometimes integrated in the HTML page itself. But even the text shown
in the HTML page itself is regarded as "content".
Content management systems organize and classify these components
by dividing the content from the layout. In more concrete terms, the con­
tent is stored in content files, the layout is stored in layout files (i.e. docu­
ment templates).
Using this approach, a CMS provides the means for treating content and
layout in separate ways. This also allows using the same content in diffe­
rent documents and formatted for different media ("cross-media publis­
hing"); think of an HTML page as it shows in the browser and the printerfriendly display of the same page, for example.“
Content
Management
Systeme
bieten
also
dem
Benutzer
auch
ohne
Programmierkenntnisse die Möglichkeit, Inhalte einzustellen und zu verwalten.
Besonderen Wert legen Content Management Systeme auf die medienneutrale
Verwaltung der Inhalte. Ziel ist es, beliebige Inhalte für ihre Präsentation im Internet
aufzubereiten. Häufig wird von Content Management Systemen folgende Klassifikation
der zu verwaltenden Informationen zu Grunde gelegt:
•
Inhalt
•
Darstellung / Präsentation
•
Struktur
Kernfunktionen, die von einem Content Management System umfasst werden müssen,
sind nach [13] :
•
Benutzerverwaltung in Gruppen und Rollen
3 Begriffsklärung und Ausgangsszenario
5
Entwicklung der Sitestruktur, Navigation, Stylesheets und Templates für
•
die Redakteure
•
Pflege von existierendem Content
•
Qualitätssicherung und Freigabemanagement
•
Stylesheetverwaltung
Zur Unterstützung dieser Funktionen bietet ein Content Management System
Prozesse, die den Administrator bei Rountineaufgaben unterstützen und die ggf.
weitere Prozesse für korrelierende Aufgaben im Hintergrund anstoßen können. Ein
Beispiel hierfür ist das Löschen aller Verlinkungen beim Entfernen einer Quelle.
3.1.2
Klassifikation von CMS
Es gibt viele Möglichkeiten zur Klassifikation von Content Management Systemen, z.B.
nach dem jeweiligen Einsatzgebiet. Unabhängig von dieser Klassifikation besitzen aber
alle Systeme einen gemeinsamen Vorrat an Funktionalitäten. Meistens werden diese
Funktionalitäten in Form einzelner Module, die speziell für ein bestimmtes Gebiet
erarbeitet wurden, bereitgestellt.
In dieser Arbeit werden CMS für folgende Einsatzgebiete betrachtet:
•
Enterprise Content Management Systeme
•
Redaktionssysteme
•
Learning Content Management Systeme
•
Digital Asset Management Systeme
Enterprise Content Management Systeme
Enterprise Content Management Systeme sind auf die Bedürfnisse von großen Firmen
hin ausgelegt. Enterprise steht für unternehmensweit im Sinne einer einheitlichen, von
allen Beteiligten im Unternehmen nutzbaren Lösung. Content steht für beliebige Inhalte
in elektronischen Systemen. Management wird im Sinne eines Softwaresystems
benutzt und steht für die Verwaltung, Verarbeitung und Kontrolle von Systemen.
3 Begriffsklärung und Ausgangsszenario
6
Redaktionssyteme
Content Management Systeme werden auch als Redaktionssysteme bezeichnet. Dies
trifft aber in den wenigsten Fällen wirklich zu. Redaktionssysteme dienen dazu, Inhalte
zu
verwalten
und
veröffentlichen
zu
können.
Typische
Inhalte
in
diesem
Zusammenhang sind Artikel oder Schriftstücke. Ein Redaktionssystem ist damit eher
als ein Teil eines Content Management Systems anzusehen denn als ein
eigenständiges System.
Digital Asset Management Systeme
Digital Asset Management Systeme haben sich auf die Speicherung und Verwaltung
digitaler Inhalte, insbesondere von Grafiken, Videos und Audiodaten spezialisiert.
Diese Systeme werden auch unter dem Begriff Media Asset Management gehandelt.
Learning Content Management Systeme
Als Aufgaben eines Learning Content Management Systems werden das Erstellen,
Wiederverwenden, Auffinden, Nacharbeiten und das Ausliefern von Lerninhalten
(Content) verstanden. Learning Content Management Systeme verfügen über eine
Benutzerverwaltung, die es ermöglicht, Benutzern oder Gruppen bestimmte Rechte
zuzuweisen. Dadurch können die Zugriffsstrukturen für Lernende festgelegt werden.
Der Benutzer muss beispielsweise erst eine bestimmte Aufgabe lösen, um dann bei
Erfolg an eine andere Aufgabe herangehen zu dürfen.
3.1.3
Probleme bei verteilten Inhalten
Im Rahmen dieser Arbeit wird die Problematik verteilter Lerninhalte untersucht. Die
Inhalte einer Lernplattform sind demnach über zwei oder mehrere CMS verteilt. Der
Konsument dieser Lerninhalte soll die Verteilung der Inhalte nicht bemerken und die
Systeme als ein einziges System wahrnehmen.
Eine Definition der Problematik von verteilten Inhalten findet sich in [10], dort heißt es:
„The ability to compose, aggregate, and transform content from distribu­
ted heterogeneous sources makes it possible to present users with new
and customized resources. However, providing access to these new
resources, while maintaining the integrity of a traditional environment, is
often problematic. With the distribution of content, services and users, in­
3 Begriffsklärung und Ausgangsszenario
7
stitutions face a formidable task in providing reliable service, protecting
the privacy of users and rights of content providers, and ensuring the
long-term preservation of digital content that may not be in their direct
control.“
Bei der Verwendung von verteilten Inhalten müssen folgende Kriterien beachtet
werden:
•
Verteilte Inhalte müssen verlässlich zur Verfügung gestellt werden.
•
Es dürfen nicht die Rechte der Urheber dieser Inhalte verletzt werden.
•
Der Zugriff auf die Inhalte muss auch auf lange Sicht gesichert sein.
Ein Administrator, der ein CMS mit verteilten Inhalten betreibt, muss möglicherweise
Inhalte aus Systemen beziehen, die nicht unter seiner Kontrolle stehen. Verwaltung
von verteilten Inhalten stellt deshalb häufig ein Risiko dar.
Die Qualität und Verfügbarkeit verteilter Inhalte ist häufig nicht sichergestellt. So kann
z.B. ein Inhalt von einem entfernten System eingebunden werden. Dieser Inhalt
entspricht bei der Prüfung, die vor der Einbindung geschieht, den geforderten
Qualitätsmerkmalen. Dieser Inhalt kann aber jederzeit vom Urheber geändert werden,
ohne dass eine weitere Prüfung erfolgt.
Ausführlich wird die Problematik von verteilten Inhalten in [8] beschrieben.
3.2
E-Learning
3.2.1
Allgemeines
Unter E-Learning wird im Allgemeinen der Einbezug von Kommunikations- und
Informationstechnologie in den Prozess des Lernens verstanden. E-Learning kann sich
über die Vorbereitung in Form von Kursauswahl oder Studienführern bis hin zur
Nachbereitung in Form von Klausurergebnissen oder Evaluierungen erstrecken.
Wichtig hierbei ist, dass die Technologien mit dem Prozess des Lernens verknüpft sind
und nicht nur ein Hilfsmittel darstellen.
3 Begriffsklärung und Ausgangsszenario
8
Eine Definition des Begriffes E-Learning ist z.B. nach [14] :
„eLearning kann verstanden werden als ein Lernprozess, der durch In­
formations- und Kommunikationstechnologie unterstützt wird. eLearning
umfasst somit Informationen, Aktivitäten, Abläufe, Menschen und
Techniken. Die Gewichtung kann - je nach Bedarf - unterschiedlich sein:
In akademischen oder schulischen Umgebungen wird eLearning v.a. ein­
gesetzt, damit die Lernenden im Rahmen ihrer Kurse bzw. Fächer Kon­
zepte und Ideen verfügbar haben, analysieren, konstruieren, publizieren
und evaluieren können. Dabei können die Inhalte und Funktionen des
eLearning in sich abgeschlossen sein oder gemeinsam mit Präsenz-Ver­
anstaltungen eingesetzt werden.“
Ausschlaggebend für den Einsatz von E-Learning war besonders die rasante
technologische Entwicklung der Computerindustrie und die fortschreitende Vernetzung
der Computer. Die damit ermöglichten neuen Verfahren förderten in großem Umfang
die Entwicklung des E-Learnings.
E-Learning wurde auch aufgrund seiner ökonomischen Vorteile gefördert, denn ein
„life-long-learning“ (lebenslanges Lernen) bedeutet ein Lernen neben dem Beruf oder
ein Lernen im Beruf. Die Lernenden sind mit E-Learning räumlich sowie zeitlich
unabhängig und die Vermittlung von Lernstoff kann ohne Präsenz eines Lehrenden
geschehen.
Die Vor- und Nachteile des E-Learning werden heute viel diskutiert. Laut [15] hat man
sich aber mittlerweile darauf geeinigt, E-Learning als einen Teil des Lernprozesses
anzusehen und nicht mehr als revolutionären Prozess, der den klassischen
Lernprozess ersetzen könnte. Aktuell wird davon ausgegangen, dass der optimale
Lernprozess erst entstehen kann, wenn Medien, Inhalte, Organisation, Didaktik und
Methodik professionell geplant und umgesetzt werden. Man sieht E-Learning als einen
Teil des Lernprozesses an und nimmt Abstand von dem Gedanken, dass das Medium
einen sehr hohen Einfluss auf den Lernprozess hat.
3 Begriffsklärung und Ausgangsszenario
3.2.2
9
Formen von E-Learning
E-Learning kann nach [15] in folgende Klassen unterteilt werden:
Web- und Computer-basiertes E-Learning
Unter
Web-
und
Computer-basiertem
E-Learning
versteht
man
E-Learning-
Anwendungen, die es dem Lernenden z.B. per Web oder CD ermöglichen, zeitlich und
räumlich unabhängig zu lernen. Meist beinhaltet diese Art des E-Learning Multimedia
in Form von Video- oder Audiodaten. Es steht eindeutig das Selbststudium im
Vordergrund. Kontakt zu anderen Lernenden oder dem Autor erfolgt, wenn überhaupt,
nur über E-Mail oder Foren.
Autorensysteme
Autorensysteme dienen der Entwicklung von E-Learning-Inhalten und werden nur von
Lehrenden benutzt. Der Lernende hat keinen Kontakt zu diesem System. Das
Autorensystem hilft dem Lehrenden, Inhalte zum Beispiel als Webseite oder als CD zu
publizieren. Der Lehrende muss hierbei über keine Kenntnisse in den angewandten
Technologien, wie zum Beispiel HTML (Hypertext Markup Language) besitzen.
Simulationen
Simulationen bilden Modelle der realen Welt ab und dienen der Veranschaulichung von
meist sehr theoretischen Inhalten. Sie erlauben dem Lernenden selber Wissen durch
Experimentieren und Beobachten zu erlangen. Im Zuge der Simulationen kommen
unterschiedlichste Technologien zum Einsatz. Zum Beispiel das CAE (Computer Aided
Engineering) im Feld des Maschinenbaus, das den Ingenieuren die Simulation eines
Teiles erlaubt, bevor dieses überhaupt gebaut wird.
Videokonferenz/Teleteaching
Videokonferenzen
ermöglichen
die
Kommunikation
zwischen
Lernenden
und
Lehrenden über Distanz. Dies erlaubt den Einsatz von Gestik und Mimik sowie direkte
Fragen zum Lehrinhalt.
Teleteaching ist mehr auf die Erschaffung virtueller Hörsäle ausgerichtet. Eine
Kommunikation erfolgt hier meist in der Richtung vom Lehrenden zum Lernenden.
3 Begriffsklärung und Ausgangsszenario
10
Beide Formen des E-Learning sind durch ihren sehr hohen technologischen Aufwand
nur eingeschränkt nutzbar.
Learning Management System
Als Learning Management System werden Systeme aus der Sicht des E-Learning
bezeichnet, wenn sie die für das Lehrangebot nötige Organisation, den Ablauf und die
Verwaltung übernehmen. Dies umfasst zum Beispiel Buchungsprozesse bei der
Anmeldung zu Veranstaltungen und Klausuren oder auch Ressourcenverwaltung bei
Kursen mit beschränkter Teilnehmeranzahl. Learning Management Systeme sind
strategische Systeme, die den gesamten Prozess des Lernens unterstützen. Ein
Learning Management System zeichnet sich vor allem durch folgende Funktionalitäten
aus:
•
Planung von Seminaren/Kursen
•
Anmeldung zu Seminaren/Kursen
•
Bereitstellung von Kursunterlagen
•
Zertifizierung/Erstellung von Kursabschlüssen
•
Erfolgsmessung/Messung des Lernfortschrittes
In einigen Learning Management Systemen ist zusätzlich eine Raumplanung und
Vertretungsplanung integriert. Den Funktionalitäten eines Learning Management
Systems sind nach oben fast keine Grenzen gesetzt.
3.2.3
E-Learning auf der Basis von CMS
In dieser Arbeit soll ein Content Management System als eine E-Learning Plattform
implementiert werden. Nach [12] muss eine E-Learning Plattform mindestens folgende
Funktionlitäten bieten:
•
Benutzerverwaltung (Anmeldung mit Verschlüsselung)
•
Kursverwaltung (Kurse, Verwaltung der Inhalte, Dateiverwaltung)
•
Rollen- und Rechtevergabe mit differenzierten Rechten
3 Begriffsklärung und Ausgangsszenario
•
11
Kommunikationsmethoden (Chat, Foren) und Werkzeuge für das Lernen
(Whiteboard, Notizbuch, Annotationen, Kalender etc.)
•
Darstellung der Kursinhalte, Lernobjekte und Medien in einem
netzwerkfähigen Browser
Eine Benutzerverwaltung ist bei den meisten Content Management Systemen
Grundausstattung. Eine Rollen- und Rechtevergabe ist in den handelsüblichen Content
Management Systemen ebenso vorhanden. Bei der Kursverwaltung, die in diesem
Sinne nur in speziellen Systemen (Learning Management Systemen) implementiert ist,
kann man sich durch die Unterteilung mit Kategorien oder Sektionen, die die meisten
Content Management System bieten, behelfen. Kommunikationsmethoden gibt es in
Content Management Systemen sehr viele – jedoch werden nicht von jedem Content
Management System alle Methoden implementiert; häufig wird von den CMS aber
mindestens eine Kommunikationsmethode unterstützt, in den meisten Fällen das
Forum. Die Darstellung der Inhalte in browserfreundlichen Formaten ist Grundaufgabe
eines Content Management Systems (siehe Kapitel 3.1) und muss von jedem Content
Management System beherrscht werden.
Es besteht also die Möglichkeit, eine E-Learning Plattform mit einem handelsüblichen
Content Management System zu betreiben, da alle Mindestanforderungen von diesem
abgedeckt werden können.
3.3
Web Services
3.3.1
Allgemeines
Hinter Web Services steht die Idee, dass Übertragungsstandards für den Daten- und
Informationsaustausch zwischen Kommunikationspartnern sorgen. Diese Idee an sich
ist nicht neu, aber bei Web Services steht nicht der Mensch als Kommunikationspartner, sondern die Maschine im Blickfeld. Es wird eine Maschine-zu-MaschineKommunikation angestrebt.
Nach [2] ist eine Definition von Web Services folgende:
„Durch die Maschine-zu-Maschine-Kommunikation unterscheiden sich
die Web Services vom bisherigen Web-Ansatz, bei dem der Nutzer Da­
ten und Funktionalitäten vom Webserver abruft. Für Web Service ist kein
3 Begriffsklärung und Ausgangsszenario
12
Nutzer erforderlich. Vielmehr muss der Web Service einmal in ein Pro­
gramm eingebunden werden und läuft dann – in der Theorie – automa­
tisch.“
Es gibt keine einheitliche Regelung für Web Services. Wenn man heute von Web
Services spricht, meint man eine Menge von Standards und Spezifikationen. Laut [2]
basieren Web Services auf unterschiedlichsten Technologien, haben jedoch stets die
drei folgenden Elemente gemeinsam:
•
Die
Übermittlung:
Übertragung
von
Nachrichten
zwischen
den
Kommunikationspartnern.
•
Die
Beschreibung:
Der
Service
und
seine
Methoden
müssen
beschrieben werden, damit der Konsument weiß, was der Service
leisten kann.
•
Der Verzeichnisdienst: Ein Web Service sollte immer in einem
Verzeichnis
aufgenommen
werden,
um
dort
von
Konsumenten
gefunden zu werden.
Die Standards für diese drei Elemente bilden das Fundament für Web Services.
Übermittlung
Bei der Übermittlung von Nachrichten hat sich mittlerweile SOAP (Simple Object
Access Protocol) als Standard durchgesetzt. Dieser Standard, der von dem W3C
(World Wide Web Consortium) verwaltet wird, basiert auf XML (Extensible Markup
Language).
Beschreibung
Bei der Beschreibung ist WSDL (Web Services Description Language) der Standard;
dieser wird ebenfalls von dem W3C verwaltet.
Verzeichnisdienst
Bei den Verzeichnisdiensten gibt es mehrere Ansätze, einige davon proprietärer Art,
wie z.B. Microsofts DISCO (Discovery of Web Services). Als Standard hat sich aber
3 Begriffsklärung und Ausgangsszenario
13
UDDI (Universal Description, Discovery and Integration) durchgesetzt. UDDI wird nicht
von dem W3C, sondern von der OASIS (Organization for the Advancement of
Structured Information Standards) verwaltet und gepflegt.
3.3.2
Transaktionen und Prozesse mit Web Services
Web Services ermöglichen es, Software zu bauen die lose gekoppelt ist. Damit ist es
möglich, Software einfach aus einzelnen Teilen zusammenzustecken und ein
funktionierendes System zu erhalten. Unternehmen wünschen sich eine solche
Vorgehensweise für die Modellierung von Geschäftsprozessen. Man möchte
Prozessketten nahtlos, schnell und kostengünstig verwirklichen können.
Eine Definition von Web Services in Geschäftsprozessen findet sich z.B. in [7], dort
heißt es:
„While Web Services are a gentle evolution of existing technology, they
are a revolution in the way of business can be represented in software.
However, we cannot realize the full potential of Web Services, or see
their revolutionary nature, unless we start constructing partner-to-partner
e-business dialogues that conduct real business transactions.“
Die Problematik bei solchen lose gekoppelten Softwaresystemen liegt in der
Konsistenz und der Abstimmung zwischen den einzelnen Teilen des Systems. Hier ist
eine weiterführende Technologie notwendig, um dies zu gewährleisten. Gerade im ebusiness kann es schwerwiegende Folgen haben, wenn ein Teilsystem ausfällt und im
schlechtesten Fall das komplette System handlungsunfähig wird. Diese Problematik
nimmt zu mit der Komplexität der Systeme und ist um so wichtiger, je
unternehmenskritischer diese Systeme sind. Es muss sichergestellt werden, dass
Transaktionen
zwischen
verteilten
Anwendungen
konsistent
erfolgen,
damit
umfangreiche Prozesse auf Dauer realisiert werden können.
Transaktionen
Eine Transaktion stellt eine zusammengehörende Menge von Operationen dar.
Transaktionen können immer nur ganz oder gar nicht ausgeführt werden. Sie
unterliegen den ACID-Restriktionen aus dem Umfeld der Datenbanken.
3 Begriffsklärung und Ausgangsszenario
14
Eine Definition der ACID-Restriktionen findet man z.B. in [4]:
•
Atomicity: Eine Transaktion ist ein atomare Einheit. Sie wird
entweder vollständig und korrekt ausgeführt oder gar nicht.
•
Consistency: Vor dem Beginn und nach dem Abschluss einer
Transaktion ist das zugrunde liegende System (Datenbank, Va­
riablen etc.) in einem konsistenten Zustand.
•
Isolation: Während der Ausführung einer Transaktion darf eine
andere Transaktion nicht auf relevante und möglicherweise in­
konsistente Teile des Systems zugreifen.
•
Durability: Durchgeführte Änderungen am System dürfen nach
Abschluss einer Transaktion nur durch eine weitere Transaktion
verändert oder rückgängig gemacht werden.
Die ACID-Kriterien zu erfüllen ist für eine Web Service Transaktion zwar
anstrebenswert, aber in vielen Fällen nicht einhaltbar. Web Services in lose
gekoppelten autonomen Systemen lassen sich häufig nicht in so eng formulierte
Kriterien fassen. Ein einfaches Beispiel sind Transaktionen, die über einen längeren
Zeitraum – oft über Tage oder Wochen hinweg – laufen. Diese würden nach ACIDKriterien Teile des System für diese Dauer sperren. Eine weitere Problematik ist die
Zustandslosigkeit von WSDL (Web Service Description Language), wodurch der Web
Service nicht ohne Weiteres weiß, in welchem Kontext er steht, um auf die jeweils
richtigen Daten zugreifen zu können.
Prozesse
Prozesse stehen für die Kopplung mehrerer, genau definierter Aktivitäten. Prozesse
müssen genau spezifiziert werden, damit sie nutzbar werden für alle Beteiligten.
Während man bei einigen wenigen Prozessen ohne genaue Spezifikationen noch von
Hand implementieren kann, wird bei größeren Systemen die ausführliche und korrekte
Spezifikation von Prozessen um so wichtiger. Damit ein späteres „Prozess-Plug&Play“
möglich wird, müssen die Details der beteiligten Partner genau zueinander passen.
Man unterscheidet zwischen öffentlichen und privaten Prozessen. Die privaten
Prozesse unterliegen nicht den strengen Spezifikationen der öffentlichen Prozesse,
welche eindeutig in ihrer Beschreibung sein müssen.
3 Begriffsklärung und Ausgangsszenario
3.3.3
15
Workflow Management bei Web Services
Um die Konsistenz der Transaktionen und Prozesse zu gewährleisten, muss eine
übergeordnete Technologie eingesetzt werden. Da WSDL bzw. SOAP aber erst in den
letzten Jahren entwickelt wurden, fehlt es hier noch an einem einheitlichen Standard.
Der Praxisdruck war so hoch, dass Technologien ohne Standard entwickelt wurden.
Vor allem größere Unternehmen schrieben ihre eigenen Spezifikationen. Auf dem
Markt hat ca. ein Dutzend Unternehmen solche Standards entwickeltet: HP mit WSCL
(Web Services Conversation Language), IBM mit WSFL (Web Services Flow
Language), Microsoft mit XLANG und BizTalk. Um einen einheitlichen Standard
erreichen
zu
können,
übergaben
einige
Firmen
ihre
Spezifikationen
an
Standardisierungsorganisationen. IBM und HP reichten ihre Spezifikationen an das
W3C weiter, während Microsoft WSFL mit XLANG verschmolz und diese Spezifikation
als BPEL (Business Process Execution Language for Web Services) an die OASIS
übergab. Da sich aktuell einige der größten Firmen hinter BPEL stellen, scheint diese
Spezifikation mit hoher Wahrscheinlichkeit zum allgemeinen Standard zu werden.
Unterstützt wird BPEL hauptsächlich von BEA, IBM, Microsoft und Sun. Eine
weiterführende Liste mit Unternehmen und Artikeln über BPEL ist unter [1] aufgeführt.
BPEL (Business Process Execution Language)
Eine Definition für BPEL findet sich z.B. in [16], dort heißt es:
„BPEL (Business Process Execution Language) wurde im Jahr 2003 von
IBM, BEA und Microsoft eingeführt. BPEL ist eine XML-basierte Sprache
zur Beschreibung von Geschäftsprozessen, deren einzelne Aktivitäten
durch Webservices implementiert sind. Weiterhin kann mit BPEL ein
Webservice selbst beschrieben werden.“
Das Ziel von BPEL ist die Sprachspezifikation zur Beschreibung von Prozessen, die
auf einem oder mehreren Web Services basieren. Diese Prozesse sollen
wiederverwendbar sein und kombiniert eingesetzt werden können. BPEL kann sowohl
für private als auch für öffentliche Prozesse angewendet werden.
Die logischen Grundelemente von BPEL sind nach [5] :
•
Partner: Teilnehmer an einem Prozess
3 Begriffsklärung und Ausgangsszenario
16
•
Messages: Nachrichten, die von Partnern ausgetauscht werden
•
Data Handling: Funktionen für das Aktualisieren und Austauschen von
Zustandsvariablen der Prozesse
•
Activities: Aktivitäten, die zusammen einen Prozess darstellen
•
Scopes: Kontext um zusammengehörige Aktivitäten
Einzelne Schritte heißen in BPEL Aktivitäten. Nach [5] werden BPEL-Aktivitäten in
folgende Aktivitäten unterschieden:
Basisaktivitäten
•
Invoke: Aufrufen eines Web Service
•
Receive: Erhalten einer Nachricht von einem Web Service
•
Reply: Antworten auf einen Web Service
•
Throw: Zurückgeben von Fehlermeldungen
•
Empty: Keine Aktivität ausführen
Strukturierte Aktivitäten
•
Sequence: Festgelegte Reihenfolge von Aktivitäten
•
Switch: Bedingte Schleife von Aktivitäten
•
Pick: Ausführen einer Aktivität nach einem erwarteten Ereignis
•
Scope: Aktivität mit eigenem Scope
Strukturierte Aktivitäten können verschachtelt werden, um komplexe Prozesse
abzubilden.
3 Begriffsklärung und Ausgangsszenario
17
BPEL-Transaktionen verwirklichen die ACID-Kriterien nur in den privaten Prozessen.
BPEL baut auf dem Standard WSDL auf. Dadurch wird der Einstieg für Web ServiceEntwickler erleichtert. Ein Nachteil von BPEL ist aber zugleich die Abhängigkeit von
diesem Standard.
3.4
Ausgangsszenario
3.4.1
Allgemeines
Die Verwaltung von Lernobjekten, wie z.B. Projektaufgaben und Skripten, wird an
Hochschulen häufig nicht ausreichend unterstüzt. Dozenten verwalten ihre Lernobjekte
meistens mit statischen Webseiten. Im Rahmen dieser Arbeit werden zwei konkrete
Szenarien bei der Verwaltung von Lernobjekten bearbeitet.
Ein Szenario ist die Erfassung von Zeitdaten der Studierenden. Die Studierenden
werden aktuell einmal im Semester in einer schriftlichen Umfrage nach den Zeiten
befragt,
die
sie
bei
Vorlesungen,
Übungen,
Hausaufgaben
und
bei
der
Klausurvorbereitung verbracht haben. Diese Befragung geschieht während der
Vorlesung und wird von dem Dozenten ausgewertet.
Das zweite Szenario umfasst die Verwaltung von Lernobjekten, welche die
Vorkorrektur von Projektaufgaben durch Tutoren unterstützen soll. Aktuell müssen
Studenten sich die Projektaufgaben von einer statischen HTML-Seite des Dozenten
herunterladen. Die Korrektur geschieht momentan nur durch den Dozenten, der die
bearbeiteten Projektaufgaben schriftlich oder per E-Mail erhält. Die erreichten Punkte
werden statisch von dem Dozenten publiziert.
Basierend auf einer Lernplattform, die von zwei CMS gebildet wird, soll durch die
Unterstützung von Web Services eine Lösung dieser Problemstellung gefunden
werden.
3.4.2
Auswahl eines CMS
Ein ausführlicher Überblick über Content Management Systeme ist unter [8] aufgeführt.
Die Zahl der momentan auf dem Markt befindlichen CMS wird darin auf 1.116
Anwendungen beziffert. Es wird hervorgehoben, dass ein Entscheidungsprozess durch
die Vielzahl an Anwendungen nicht leicht ist. In der Praxis müssen viele Punkte für die
Auswahl eines CMS berücksichtigt werden. Die im Rahmen dieser Arbeit gestellten
Kriterien für ein CMS sind:
3 Begriffsklärung und Ausgangsszenario
18
•
Open Source/Kostenfreiheit
•
Erfüllung der Funktionalitäten aus Kapitel 3.2.3
•
Schnelle Einarbeitung
•
Lauffähigkeit auf gängigen Webservern (z.B. Apache)
Einen kompletten Überblick über die verschiedenen CMS zu schaffen, ist nicht Ziel
dieser Arbeit und würde deren Rahmen übersteigen. Als erstes Kriterium zur Auswahl
der Systeme wurde die Forderung nach Kostenfreiheit festgelegt. Die drei
bekanntesten Vertreter dieser Kategorie wurden auf die Eignung nach den
verbliebenen drei Kriterien geprüft. Diese Vertreter sind im Einzelnen:
•
Mambo
•
OpenCMS
•
Typo3
Nach Installation und Test der Systeme ergab sich folgender Überblick über die
Testkriterien:
Tabelle 3.2: Auswahlkriterien für ein CMS
Kriterium/System
Typo3
OpenCMS
Mambo
Open Source
Ja
Ja
Ja
Sprache Webserver PHP/Apache
Java/Tomcat
PHP/Apache
Funktionalitäten
aus Kapitel 3.2.3
Erfüllt
Erfüllt
Erfüllt
Schnelles Einarbei­ Sehr komplexes
Ist möglich
ten
System, das auf
Projektdenken ba­
siert
Ist möglich
Die geforderten Funktionalitäten aus Kapitel 3.2.3 werden von allen drei Systemen
erfüllt.
3 Begriffsklärung und Ausgangsszenario
19
OpenCMS und Typo3 sind für die Umsetzung im Rahmen dieser Arbeit jedoch nicht
geeignet. Die Gründe sind im Einzelnen:
•
OpenCMS benötigt einen Tomcat Server, der auf dem Markt nicht
gängig ist.
•
Typo3 ist ein sehr komplexes System, das eine lange Einarbeitungszeit
erfordert.
Mambo läuft auf einem gängigen Webserver (Apache), erfüllt die geforderten
Funktionalitäten und ist leicht zu erlernen.
Die beiden CMS (DozentWeb, TutorClient), die im Rahmen dieser Arbeit verwendet
wurden, sind deshalb durch Mambo Systeme der Version 4.5.2 implementiert.
3 Begriffsklärung und Ausgangsszenario
3.4.3
20
Architektur des Gesamtsystems
Die Architektur des Gesamtsystems stellt sich wie folgt dar:
Abbildung 3.1: Architektur Gesamtsystem
Die Architektur des Systems bezieht sich auf das MVC-Pattern (Model View Control).
Das Model, hier Verwaltung genannt, wird durch die beiden CMS repräsentiert. Die
Schicht des View, hier Präsentation, wird durch ASP Webseiten implementiert. Die
Web Services bilden den Controller. Dieser wird hier als Datenverwaltung bezeichnet.
Die in dieser Arbeit zur Realisierung des Systems verwendeten Technologien und
Standards sind folgende:
•
UML (Unified Modeling Language)
•
Microsoft Web Services
•
ASP.NET (Active Server Pages)
3 Begriffsklärung und Ausgangsszenario
•
21
MySQL
UML-Diagramme sind nach den Spezifikationen von UML, wie sie in Microsofts Office
Visio 2003 verwendet werden, entworfen.
Web Services sind mit Microsofts Visual Studio .NET 2003 entworfen und
programmiert. Alle Web Services wurden in C# geschrieben und sind basierend auf
dem .NET Framework 1.1 entstanden. Web Services haben in dieser Arbeit die
Endung .asmx. Klassen die in C# geschrieben wurden, enden mit dem Bezeichner .cs.
Zur Gestaltung der Webseiten kam ASP.NET zum Einsatz. Alle ASP.NET-Seiten
wurden im Visual Studio.NET 2003 entworfen und implementiert. Neben ASP.NET
wurde auch C# als Programmiersprache verwendet. ASP.NET-Seiten enden mit .aspx,
die dazugehörigen Code Behind-Klassen mit aspx.cs.
Als Datenbank für die Web Services wurde eine MySQL Datenbank der Version 4.1.14
verwendet.
Alle Web Services und Webseiten wurden unter einem Windows XP System
(Servicepack 1) mit dem IIS (Internet Information Service) als Webserver entwickelt
und getestet.
Desweiteren wurde für alle Beispiele des Workflow-Management durch BPEL die
Version 1.1 von BPEL gewählt und verwendet.
4 Konzept zur Verwaltung von E-Learning Objekten auf der Basis von Web Services
4
Konzept zur Verwaltung von E-Learning
Objekten auf der Basis von Web Services
4.1
Modul „Zeiterfassung“
4.1.1
Problembeschreibung
22
Zur Zeit wird jeder Student rückwirkend befragt über die für Veranstaltungen
aufgebrachte Zeit. Erfasst wird die Zeit, die ein Student in den Vorlesungen, Übungen
und bei den Hausarbeiten verbracht hat und die er für die Klausurvorbereitung
aufgewendet hat. Diese Befragung geschieht aktuell schriftlich auf Papier und wird
einmal pro Semester ausgeführt.
Zukünftig sollte die Erfassung online geschehen und von den Studenten eigenständig
ausgefüllt werden. Zum Beispiel sollen die Studenten von Dozent Z während den
Vorlesungen „Datenbanken I“ und „Elektronische Medien und Märkte“ diese
Erfassungen über die Portalseiten DozentWeb oder TutorClient eintragen. Die Daten
sollen an einem zentralen Ort gespeichert werden, dadurch wird die spätere
Auswertung durch Dozent Z vereinfacht.
Der Fragebogen ist für die Studenten möglichst einfach zu gestalten, so dass er ohne
großen Aufwand bei einem Besuch auf DozentWeb oder TutorClient ausgefüllt werden
kann.
Die Zeit, die in Vorlesungen, Übungen und bei Hausaufgaben verbracht wird, soll
wöchentlich abgefragt werden. Die Klausurvorbereitungszeit wird einmal pro Semester
abgefragt.
4.1.2
Bei
den
Funktionsbeschreibung
benötigten
Funktionen
kann
man
zwischen
Nutzerfunktionen
und
Verwaltungsfunktionen unterscheiden. Nutzerfunktionen werden von den Studenten
benötigt,
um
Daten
einzugeben
und
gegebenenfalls
zu
modifizieren.
Verwaltungsfunktionen werden von Dozenten zur Auswertung benötigt und dienen
desweiteren dazu, Semester- oder Vorlesungseinträge zu erstellen und zu pflegen.
4 Konzept zur Verwaltung von E-Learning Objekten auf der Basis von Web Services
23
Nutzerfunktionen
•
Wöchentliche
Eintragung
von
Übungs-,
Vorlesungs-
und
Hausaufgabenzeiten
•
Eintragen von aufgewendeter Zeit für die Klausurvorbereitung pro
Semester
•
Auskunft über die Einträge
Verwaltungsfunktionen
4.1.3
•
Anlage und Pflege von Semestereinträgen
•
Anlage und Pflege von Veranstaltungseinträgen
•
Abruf der erfassten Zeitdaten der Studierenden
Modell
Zur besseren Übersicht wird der Ablauf einer Zeiterfassung auf ein Diagramm
abgebildet.
Als Vertreter der Benutzer sind hier Student X und Student Y gewählt worden. Dozent
Z steht repräsentativ für die Verwalter. Die beiden Studenten besuchen eine Vorlesung
bei Dozent Z und tragen ihre Daten in die Zeiterfassung ein. Student X wählt hierbei
den Weg über das Portal DozentWeb, Student Y hingegen gibt seine Daten über das
Portal TutorClient ein. Dozent Z ruft die Zeitdaten für diese Veranstaltung ab und
wertet
diese
aus.
Dies
sind
alles
Anwendungsbeispiele,
die
aus
der
Funktionsbeschreibung hervorgehen und in folgendem Modell verdeutlicht werden
können.
Modellbeschreibung
Durch dieses Modell ergibt sich eine Trennung zwischen der Eingabemaske, welche
die Studenten benutzen und der Eingabemaske für die Abfrage der gespeicherten
Daten durch Dozenten. Die Studenten nehmen über ihre Eingabemasken die
Nutzerfunktionen wahr. Die Verwaltungsfunktionen für den Dozenten werden über eine
Eingabemaske oder über Direktzugriff auf den Datenspeicher wahrgenommen. Die
4 Konzept zur Verwaltung von E-Learning Objekten auf der Basis von Web Services
24
Eingabemaske für die Studenten und Dozenten dient rein der Darstellung. Logik und
Speicherung werden an zentraler Stelle von einem Server und einer Datenbank
übernommen.
Abbildung 4.1: Vereinfachtes Modell des Moduls „Zeiterfassung“
4.1.3.1
Aktivitätsdiagramm
Die Aktivitäten der Benutzer des Moduls „Zeiterfassung“ müssen aus der Sicht der
Studenten und der Dozenten betrachtet werden. Die Aktivitäten der Studenten sind alle
auf die Erfassung und Abfrage ihrer eigenen Zeitdaten gerichtet. Dagegen sind die
Aktivitäten des Dozenten auf die Auswertung aller Daten fokussiert.
Aktivitätsdiagramm Student
Der Student ruft als erstes die Seite zur Zeiterfassung auf. Diesen Zustand wollen wir
als Startzustand definieren. Seine erste Aktivität besteht nun darin, sich am System
anzumelden. Bei nicht erfolgreicher Anmeldung gelangt er wieder zurück in den
Startzustand. Sollte die Anmeldung erfolgreich sein, erlangt der Benutzer den Zustand
4 Konzept zur Verwaltung von E-Learning Objekten auf der Basis von Web Services
25
„Eingeloggt“ und kann nun zwischen den Aktivitäten „Ausloggen“ und „Auswahl
Veranstaltung“ wählen. Die Aktivität „Ausloggen“ führt zum Endzustand, der sich von
dem Startzustand nur durch die Tatsache unterscheidet, dass dieser über den Zustand
„Eingeloggt“ erreicht wird. Die Aktivität „Auswahl Veranstaltung“ ermöglicht zwei
weitere Aktivitäten: „Neuer Wocheneintrag“ und „Neuer Semestereintrag“. Beide
Aktivitäten führen nach Beendigung zurück in den Zustand „Eingeloggt“.
Abbildung 4.2: Studentische Aktivitäten am Modul
„Zeiterfassung“
4 Konzept zur Verwaltung von E-Learning Objekten auf der Basis von Web Services
26
Aktivitätsdiagramm Dozent
Den Dozenten wird als Verwaltern eine andere Seite zur Verfügung gestellt. Das
Aufrufen dieser Seite wird wieder als Startzustand angenommen. Bei gescheitertem
Login gelangt der Dozent wieder auf den Startzustand zurück. Nach erfolgreichem
Login hat der Dozent den Zustand „Eingeloggt“; dort stehen drei Aktivitäten zur
Auswahl: „Veranstaltung neu/ändern“, „Semester neu/ändern“ oder „Statistik anzeigen“.
Die Aktivität „Ausloggen“ führt zum Endzustand, der wiederum bis auf den Punkt, dass
er aus dem Zustand „Eingeloggt“ erreicht wird, mit dem Startzustand gleichzusetzen ist.
Alle drei möglichen Aktivitäten im Zustand „Eingeloggt“ führen wieder auf diesen
Zustand „Eingeloggt“ zurück.
Abbildung 4.3: Aktivitäten eines Dozenten am Modul
„Zeiterfassung“
Die beiden Diagramme (Abbildungen 4.2 & 4.3) beschreiben Ablaufmöglichkeiten und
einzelne Aktivitäten des Moduls „Zeiterfassung“. Als nächstes kann nun an einen Use-
4 Konzept zur Verwaltung von E-Learning Objekten auf der Basis von Web Services
27
Case (Anwendungsfall) herangegangen werden und das Verhalten des Moduls aus der
Sicht des Benutzers und vor allem die Beziehungen zwischen dem System und dem
Benutzer können dargestellt werden.
4.1.3.2
Use-Case
Die Use-Cases (Anwendungsfälle) für das Modul „Zeiterfassung“ müssen von der Sicht
der Benutzer ausgehen: den Studenten und den Dozenten.
Use-Case Student
Will der Student seine Daten im Modul „Zeiterfassung“ einsehen oder ändern, so
stehen ihm zwei Wege offen: über das Portal „DozentWeb“ und über das Portal
„TutorClient“. Beide bieten die Möglichkeit, die Daten der Studenten auf dem neusten
Stand zu halten. Der Student kann frei zwischen beiden Portalen wählen. Er ruft das
Modul „Zeiterfassung“ über eines der beiden Portale auf und loggt sich ein. Der
Student besitzt zwei Anwendungsfälle: Er kann entweder seine Daten abrufen oder
diese ändern.
Abbildung 4.4: Use-Case Modul „Zeiterfassung“ Student
4 Konzept zur Verwaltung von E-Learning Objekten auf der Basis von Web Services
28
Use-Case Dozent (Verwalter)
Der Verwalter besitzt den vollen Zugriff auf die Datenbasis oder kann über einen Client
in dem Portal „DozentWeb“ handeln. Er kann, sollte er es wünschen, die Änderungen
direkt an der Datenbank vornehmen oder über den Webclient auch die alltäglichen
Verwaltungsarbeiten erledigen. Benutzt der Verwalter den Webclient, so besitzt er drei
Anwendungsfälle: „Statistik abfragen“, „Semester neu/ändern“ und „Veranstaltung
neu/ändern“.
Abbildung 4.5: Use-Case Modul „Zeiterfassung“ Dozent
4.1.3.3
Sequenzdiagramm
Ein Sequenzdiagramm für das Modul „Zeiterfassung“ soll zeigen, wie der zeitliche
Ablauf von Nachrichten zwischen Objekten des Moduls gestaltet werden muss. Wie
schon in vorhergehenden Punkten festgestellt, besteht das Modul „Zeiterfassung“ aus
mehreren Clients, die auf einen Server zugreifen. Die Clients sind Webseiten, die
einen Server verwenden, der durch Web Services implementiert ist. Interessant ist vor
allem der Nachrichtenaustausch zwischen den Clients und dem Server – weniger die
Nachrichten, die im Server versendet werden.
4 Konzept zur Verwaltung von E-Learning Objekten auf der Basis von Web Services
29
Abbildung 4.6: Sequenzdiagramm Modul „Zeiterfassung“
Beide Clients können gleichzeitig auf dem Server aktiv sein und unterschiedliche
Anfragen an diesen senden. Der Server, in diesem Fall der Web Service, muss
feststellen können, wer die Anfrage gesendet hat und ob dieser die Berechtigung dazu
besitzt. Desweiteren muss sich der Server den Status der einzelnen Clients merken.
Hierbei ist eine zentrale Frage, die der Web Service sicherstellen muss, ob der Client
eingeloggt ist und er die Anfrage stellen darf oder ob die Anfrage von einem nicht
eingeloggten Client stammt. Solange ein Client eingeloggt ist, kann er immer wieder
Anfragen an den Server stellen. Die Anfragen erfolgen in einer zeitlich nicht
festzulegenden Reihenfolge und müssen vom Server einem Client zugeordnet werden
können.
4.1.4
Lösungsvorschlag
Die Implementierung des Moduls „Zeiterfassung“ erfordert eine Trennung zwischen
einem Client als Webseite in den Portalen DozentWeb und TutorClient und einem
Server in Form von Web Services, die zentral die Bearbeitung und Speicherung der
erfassten Daten übernehmen. Als Client sollten weiterhin getrennte Seiten erstellt
werden: eine Seite für die Studenten als Benutzer und eine weitere Seite für den
Dozenten als Verwalter der Erfassung. Beide Clients benutzen den selben Web
4 Konzept zur Verwaltung von E-Learning Objekten auf der Basis von Web Services
30
Service als Server mit unterschiedlicher Zugriffsberechtigung, abhängig davon, welcher
Typ von User sich am Server angemeldet hat. Die Web Services können nur mit
gültiger Anmeldung am Server genutzt werden.
4.2
Modul „Verwaltung von E-Learning Objekten“
4.2.1
Problembeschreibung
Zur Zeit müssen die Studenten sich Aufgaben von einer statischen HTML-Seite eines
Dozenten herunterladen. Diese Aufgaben werden von den Studenten bearbeitet und in
Form einer E-Mail oder auf Papier zur Korrektur eingereicht. Der Dozent veröffentlicht
die Ergebnisse der Korrektur auf einer statischen HTML-Seite.
Zukünftig soll eine Vorkorrektur der abgegebenen Aufgaben durch Tutoren erfolgen.
Die Studenten sollen sich die Aufgaben für eine Veranstaltung selbständig von einer
Seite des Dozenten herunterladen. Einer oder mehrere Tutoren korrigieren diese
Aufgaben und legen sie zur Endkorrektur dem Dozenten vor. Dieser kann der Korrektur
des Tutors zustimmen oder diese verwerfen und die Korrektur selbst durchführen. Die
erreichten Punktzahlen werden von dem Dozenten veröffentlicht.
4.2.2
Funktionsbeschreibung
Die Funktionalitäten im Modul „Verwaltung von E-Learning Objekten“ müssen in drei
Kategorien unterschieden werden: Funktionalitäten, die Studenten, Tutoren und
Dozenten benötigen. Studenten sind Benutzer (User) dieses Moduls; Tutoren und
Dozenten
sind
Verwalter
(Administratoren),
jedoch
Aufgabengebieten.
Funktionalitäten für Studenten
•
Authentifizieren am Modul
•
Übersicht über erreichte Punktzahlen
•
Abgabe bearbeiteter Aufgaben
Funktionalitäten für Tutoren
•
Authentifizieren am Modul
mit
unterschiedlichen
4 Konzept zur Verwaltung von E-Learning Objekten auf der Basis von Web Services
•
Übersicht über eingereichte Aufgaben von Studenten
•
Übersicht über bereits bearbeitete Aufgaben
•
Abgabe einer Vorkorrektur an den Dozenten
31
Funktionalitäten für Dozenten
4.2.3
•
Authentifizieren am Modul
•
Übersicht über eingereichte Vorkorrekturen
•
Übersicht über Punktzahlen der Studenten
•
Eintragen von Punktzahlen
Modell
Anhand eines einfachen Diagramms soll die Problem- und Funktionsbeschreibung im
Modell verdeutlicht werden.
Modellbeschreibung
Als Vertreter für Studenten, Tutoren und Dozenten wurden Student X, Tutor Y und
Dozent Z gewählt. Student X erhält durch das Portal „DozentWeb“ eine Aufgabe. Diese
wird bearbeitet und über das gleiche Portal abgegeben. Tutor Y erhält diese Aufgabe
zur Vorkorrektur in dem Portal „TutorClient“. Ist die Aufgabe von dem Tutor bearbeitet
worden, wird sie weiter an den Dozent Z zur Endkorrektur gereicht. Dozent Z kann die
Vorkorrektur über das Portal „DozentWeb“ einsehen. Die erreichten Punkte werden
ebenfalls über dieses Portal von Dozent Z eingetragen. Student X kann die erreichte
Punktzahl über das Portal „DozentWeb“ abfragen.
4 Konzept zur Verwaltung von E-Learning Objekten auf der Basis von Web Services
32
Abbildung 4.7: Vereinfachtes Modell des Moduls „Verwaltung von E-Learning Objekten“
4.2.3.1
Aktivitätsdiagramm
Aktivitäten am Modul „Verwaltung von E-Learning Objekten“ müssen aus der Sicht der
Studenten, Tutoren und Dozenten betrachtet werden. Aktivitäten der Studenten sind
auf die Abgabe von Hausaufgaben und die Abfrage der erreichten Punkte gerichtet.
Die Aktivitäten von Tutoren und Dozenten sind auf die Bewertung dieser Aufgaben
und, im Speziellen beim Dozenten auf die Veröffentlichung der erreichten Punktzahlen
gerichtet.
Aktivitätsdiagramm Student
Der Student ruft als erstes die Seite zur Verwaltung von E-Learning Objekten auf.
Diesen Zustand wollen wir als Startzustand definieren. Seine erste Aktivität besteht
4 Konzept zur Verwaltung von E-Learning Objekten auf der Basis von Web Services
33
nun darin, sich am System anzumelden. Bei nicht erfolgreicher Anmeldung gelangt er
wieder zurück in den Startzustand. Sollte die Anmeldung erfolgreich sein, erlangt der
Benutzer den Zustand „Eingeloggt“ und kann nun zwischen den Aktivitäten
„Ausloggen“ und „Aufgabe abgeben“ wählen. Die Aktivität „Ausloggen“ führt zum
Endzustand, der sich von dem Startzustand nur durch die Tatsache unterscheidet,
dass dieser über den Zustand „Eingeloggt“ erreicht wird. Die Aktivität „Aufgabe
abgeben“ führt nach Beendigung zurück in den Zustand „Eingeloggt“.
Abbildung 4.8: Aktivitätsdiagramm „E-Learning Objekte“
Student
4 Konzept zur Verwaltung von E-Learning Objekten auf der Basis von Web Services
34
Aktivitätsdiagramm Tutor
Der Tutor ruft die Seite zur Verwaltung von E-Learning Objekten auf. Dieser Zustand
ist als Startzustand anzusehen. Die folgende Aktivität des Tutor ist es, sich am System
anzumelden. Sollte die Aktivität „Einloggen“ erfolgreich sein, gelangt er in den Zustand
„Eingeloggt“. Dort hat er die Auswahl zwischen den Aktivitäten „Ausloggen“, welche
zum Endzustand führt und „Vorkorrektur abgeben“, welche nach Beendigung in den
Zustand „Eingeloggt“ zurückführt.
Abbildung 4.9: Aktivitätsdiagramm „E-Learning
Objekte“ Tutor
Aktivitätsdiagramm Dozent
Der Dozent ruft eine Seite zur Verwaltung von E-Learning Objekten auf. Dieser
Zustand ist der Startzustand. Die nächste Aktivität des Dozenten besteht darin, sich am
System anzumelden. Dies geschieht durch die Aktivität „Einloggen“. Ist diese
4 Konzept zur Verwaltung von E-Learning Objekten auf der Basis von Web Services
35
erfolgreich, erlangt der Dozent den Zustand „Eingeloggt“. Dort kann er zwischen den
Aktivitäten
„Ausloggen“,
„Punkte
eintragen“,
„Aufgaben
anlegen/pflegen“
und
„Semester/Veranstaltungen anlegen/pflegen“ wählen.
Abbildung 4.10: Aktivitätsdiagramm „E-Learning Objekte“ Dozent
4.2.3.2
Use-Case
Die Use-Cases (Anwendungsfälle) des Moduls „Verwaltung von E-Learning Objekten“
müssen aus der Sicht der Studenten, Tutoren und Dozenten betrachtet werden.
4 Konzept zur Verwaltung von E-Learning Objekten auf der Basis von Web Services
36
Use-Case Student
Der Student besitzt zwei Anwendungsfälle: „Hausaufgabe herunterladen“ und
„Hausaufgabe abgeben“. Der Anwendungsfall „Hausaufgabe herunterladen“ erfolgt
über das Portal „DozentWeb“, ohne dass das Modul „Verwaltung von E-Learning
Objekten“
benötigt
wird.
Die
Hausaufgabe
wird
zur
Korrektur
durch
den
Anwendungsfall „Hausaufgabe abgeben“ durch das Modul „Verwaltung von E-Learning
Objekten“ eingereicht.
Abbildung 4.11: Use-Case Modul „Verwaltung von E-Learning Objekten“ Student
Use-Case Tutor
Der Tutor besitzt einen Anwendungsfall „Vorkorrektur abgeben“. Durch diesen werden
vorkorrigierte Hausaufgaben im Portal „TutorClient“ mit dem Modul „Verwaltung von ELearning Objekten“ zur Endkorrektur durch den Dozenten eingereicht.
Abbildung 4.12: Use-Case Modul „Verwaltung von E-Learning Objekten“ Tutor
4 Konzept zur Verwaltung von E-Learning Objekten auf der Basis von Web Services
37
Use-Case Dozent
Der Dozent besitzt drei Anwendungsfälle: „Punkte eintragen“, „Aufgabe veröffentlichen“
und „Verwaltung“. Im Anwendungsfall „Punkte eintragen“ trägt der Dozent einem
Studenten die erreichte Punktzahl für eine eingereichte Lösung ein. Aufgaben werden
im Portal „DozentWeb“ zum Herunterladen eingestellt und müssen im Modul
„Verwaltung von E-Learning Objekten“ zur Bearbeitung freigegeben werden. Der
Anwendungsfall „Verwaltung“ umfasst die Anlage und Pflege von Semestern und
Veranstaltungen.
Abbildung 4.13: Use-Case Modul „Verwaltung von E-Learning Objekten“ Dozent
4.2.3.3
Sequenzdiagramm
Sequenzdiagramme für das Modul „Verwaltung von E-Learning Objekten“ sollen den
zeitlichen Ablauf der Nachrichten verdeutlichen. Dabei muss zwischen Nachrichten aus
dem Portal „DozentWeb“ und Nachrichten aus dem Portal „TutorClient“ unterschieden
werden. Desweiteren müssen Nachrichten aus dem „DozentWeb“ nochmals in
Nachrichten von Studenten und von Dozenten unterteilt werden. Aus diesem Grund
sind für das Modul insgesamt drei Sequenzdiagramme notwendig.
Sequenzdiagramm DozentWeb Student
Die erste Nachricht an den Server (Web Services) von dem Client der Studenten im
Portal Dozent besteht aus dem Login. Wird diese Nachricht mit „True“ beantwortet, ist
eine Sitzung an dem Server hergestellt und es kann die Nachricht „Aufgabe abgeben“
an den Server gesendet werden. Wird die Nachricht ohne einen erfolgreichen Login
4 Konzept zur Verwaltung von E-Learning Objekten auf der Basis von Web Services
38
gesendet, so muss diese nicht bearbeitet werden. Die Sitzung wird durch die Nachricht
„Logout“ beendet.
Abbildung 4.14: Sequenzdiagramm Modul „Verwaltung von E-Learning Objekten“
Student
Sequenzdiagramm DozentWeb Dozent
Die erste Nachricht aus dem Portal „DozentWeb“ (Dozent) an den Server (Web
Service) besteht aus dem Login. Wird diese Nachricht mit „True“ beantwortet, ist eine
Sitzung an dem Server hergestellt und es können andere Nachrichten in beliebiger
Reihenfolge an den Server gesendet werden. Einige dieser Nachrichten sind z.B.
„Punkte eintragen“ oder „Aufgabe veröffentlichen“. Sollte eine Nachricht ohne einen
gültigen Login an den Server gesendet werden, so ist diese nicht zu bearbeiten. Sind
alle Nachrichten an den Server mitgeteilt, wird mit der Nachricht „Logout“ die Sitzung
am Server beendet.
4 Konzept zur Verwaltung von E-Learning Objekten auf der Basis von Web Services
39
Abbildung 4.15: Sequenzdiagramm Modul „Verwaltung von E-Learning Objekten“
Dozent
Sequenzdiagramm TutorClient Tutor
Die erste Nachricht des Client in dem Portal „TutorClient“ an den Server (Web Service)
besteht aus dem Login. Ist diese Nachricht mit „True“ beantwortet, hat der Client eine
Sitzung an dem Server. Die Nachricht „Vorkorrektur abgeben“ kann dann an den
Server gesendet werden. Die Sitzung wird durch die Nachricht „Logout“ beendet. Ohne
gültigen Login werden Nachrichten nicht bearbeitet.
Abbildung 4.16: Sequenzdiagramm Modul „Verwaltung von E-Learning Objekten“
Tutor
4.2.4
Lösungsvorschlag
Die Implementierung des Moduls „Verwaltung von E-Learning Objekten“ erfordert eine
Trennung zwischen Clients (Webseiten) und dem Server (Web Services). Die Clients
4 Konzept zur Verwaltung von E-Learning Objekten auf der Basis von Web Services
40
werden als Webseiten implementiert, die in die Portale „DozentWeb“ und „TutorClient“
integriert werden. Die Clients müssen deshalb weiterhin unterteilt werden in Clients für
die einzelnen Portale und Benutzer. Im „DozentWeb“ muss es einen Client für den
Dozenten und einen für die Studenten geben. Im Portal „TutorClient“ ist ein Client für
die Tutoren notwendig. Die Benutzer können sich an den Clients anmelden, wenn sie
im betreffenden Portal als Benutzer registriert sind. Ein Tutor z.B. muss als Benutzer
im Portal „TutorClient“ bekannt sein, um sich über seinen Client am Modul „Verwaltung
von E-Learning Objekten“ anmelden zu können. Ein Student muss als Benutzer und
ein Dozent als Administrator am Portal „DozentWeb“ bekannt sein.
Der Server, welcher über Web Services realisiert wird, ist in drei eigenständige Web
Services untergliedert, die jeweils für Studenten, Tutoren und Dozenten zuständig sind.
Diese Web Services sind die Gegenstücke zu den oben beschriebenen Clients. Die
Web Services bearbeiten nur Aufgaben, die von Benutzern mit gültiger Berechtigung
gestellt wurden.
Die Datenspeicherung für das Modul „Verwaltung von E-Learning Objekten“ erfolgt
unabhängig von den Datenbanken der Portale „DozentWeb“ und „TutorClient“ in einer
eigenen Datenbank. Für die Handhabung von Datenbankzugriffen wird den Web
Services eine Komponente DBHandler zur Verfügung gestellt.
5 Prototypische Realisierung
5
Prototypische Realisierung
5.1
Modellierung
5.1.1
Zeiterfassung
5.1.1.1
Architektur
41
Die Architektur des Moduls „Zeiterfassung“ ist eine Client/Server-Architektur.
Folgendes Komponentendiagramm soll die Zusammensetzung von Client und Server
verdeutlichen.
Abbildung 5.1: Komponentendiagramm Modul „Zeiterfassung“
Der Client besteht aus zwei Komponenten: den ASP.NET Webseiten und den CodeBehind-Klassen. Die Code-Behind Klassen enthalten C# Code, welcher die Darstellung
und Steuerung von den ASP.NET Seiten betrifft. Ein Beispiel hierfür sind Button Click
Events. Eine Besonderheit bei der Code-Behind Komponente besteht darin, dass sie
nur im Quelltext eine eigenständige Komponente darstellt. Nach der Kompilierung
bildet sie zusammen mit den Webseiten eine einzige Komponente.
Der Server besteht aus zwei Komponenten: Den „Web Services“ und dem
„DBHandler“. Die Komponente „DBHandler“ soll aus Gründen der Übersichtlichkeit die
Kommunikation mit der Datenbank übernehmen, da sonst die Komponente „Web
Services“ mit Datenbankbefehlen überladen wäre.
5 Prototypische Realisierung
5.1.1.2
42
Klassendiagramm
Beide Komponenten im Modul „Zeiterfassung“ auf Seiten des Servers bestehen aus
jeweils einer Klasse. Folgendes Diagramm zeigt die beiden Klassen „Zeiterfassung“
und „DBHandler“ mit ihren öffentlichen Methoden und Attributen.
Abbildung 5.2: Klassendiagramm „Zeiterfassung“
Die Klasse „Zeiterfassung“, die über ihre einzelnen Methoden in die Web Services
implementiert ist, wird durch die Klasse „DBHandler“ bei Operationen auf der
Datenbank unterstützt. Beispielhaft für diese Unterstützung ist die Methode
„SelectFromDatabase“, die von der Klasse „DBHandler“ bereitgestellt wird. Durch diese
Methode kann der Web Service beliebige Anfragen an die Datenbank stellen.
5 Prototypische Realisierung
5.1.2
Verwaltung von E-Learning Objekten
5.1.2.1
Architektur
43
Das Modul „Verwaltung von E-Learning Objekten“ besteht aus einer Client/ServerArchitektur. Im Unterschied zum Modul „Zeiterfassung“ existieren hier mehrere Clients
und mehrere Server. Insgesamt sind drei Clients und Server im Einsatz. Folgende
Komponentendiagramme sollen einen Überblick über die einzelnen Komponenten der
Clients und Server vermitteln.
Abbildung 5.3: Komponentendiagramm Modul „Verwaltung von E-Learning Objekten“
Dozent
Abbildung 5.4: Komponentendiagramm Modul „Verwaltung von E-Learning Objekten“
Student
5 Prototypische Realisierung
44
Abbildung 5.5: Komponentendiagramm Modul „Verwaltung von E-Learning Objekten“
Tutor
Die drei Client/Server setzen sich jeweils wie folgt zusammen: Die Seite des Client
besteht immer aus den Komponenten Code-Behind und den ASP. NET Webseiten. Die
Code-Behind Komponente enthält den Quellcode, der die Darstellung und die
Steuerung der ASP. NET Webseiten betrifft. Es gilt zu beachten, dass die Code-Behind
Komponente nur im Quellcode eigenständig anzusehen ist; im kompilierten Zustand
verschmilzt sie mit den ASP.NET Webseiten.
Der Server setzt sich aus dem Web Service und der Komponente DBHandler
zusammen. Die Komponente DBHandler enthält unterstützende Werkzeuge für den
Datenbankzugriff, die von der Komponente Web Service benötigt werden.
5.1.2.2
Klassendiagramm
Der Server des Moduls „Verwaltung von E-Learning Objekten“ besteht aus drei Teilen:
Dozent, Student und Tutor. Diese Teile werden als Pakete bezeichnet.
Abbildung 5.6: Pakete Modul „Verwaltung
von E-Learning Objekten“
5 Prototypische Realisierung
45
Alle Pakete des Moduls „Verwaltung von E-Learning Objekten“ bestehen aus den
Komponenten Web Service und DBHandler (siehe 5.2.2.1), welche jeweils durch eine
Klasse implementiert sind. Die Klasse, die den Web Service implementiert, ist nach
ihrem Aufgabengebiet benannt. Der Web Service, der z.B. für das Portal DozentWeb
und den Dozenten implementiert ist, heißt „Dozent“.
Die Klassen der Web Services und die Klassen der Datenbankunterstützung besitzen
in den drei Paketen einige Gemeinsamkeiten.
Gemeinsamkeiten DBHandler
Sogenannte Connection Strings (Verbindungs-Texte) sind in jeder „DBHandler“ Klasse
hinterlegt. Sie erlauben den Zugriff auf Datenbanken und tragen in den Klassen immer
den Namen „MY_CONN_STRING“, möglicherweise mit dem Zusatz der Datenbank auf
die sie verbinden. Diese Variablen sind in den Klassen immer statisch hinterlegt, was
durch die Großschreibung des Namens angezeigt wird. Jede Klasse „DBHandler“
besitzt die Methode „SelectFromDatabase“ und „ExecuteQuery“. Erstere erlaubt es, mit
Hilfe des Connection String eine Select-Abfrage an die Datenbank zu senden. Die
Methode „ExecuteQuery“ führt mit Hilfe des Connection String z.B. ein Insert
Statement aus.
Gemeinsamkeiten Web Services
Die Klassen der Web Services besitzen alle die Methoden „Login“, „Logout“,
„IsUserLoggedIn“
Benutzernamen
und
und
„GetLoggedInUser“.
Passwörter
mit
Die
angegeben
Methode
„Login“
Datenbankeinträgen
vergleicht
in
den
betreffenden Portalen. Bei positivem Vergleich wird eine Sitzung hergestellt. Die
Methode „Logout“ beendet diese Sitzung wieder. Über die Methode „GetLoggedInUser“
kann der Benutzername des eingeloggten Benutzers in Erfahrung gebracht werden.
Über die Methode „IsUserLoggedIn“ kann erfragt werden, ob ein Benutzer am Server
angemeldet ist.
Klassendiagramm Dozent
Die Klasse „Dozent“ (Web Service) erhält über die Klasse „DBHandler“ Zugriff auf die
Datenbanken vom Portal „DozentWeb“ und die Datenbank, die der Speicherung von
Daten des Moduls „Verwaltung von E-Learning Objekten“ dient. Eine Besonderheit der
5 Prototypische Realisierung
46
Klasse „Dozent“ ist die Methode „IsLoggedInUserAdmin“; diese überprüft, ob der
betreffende Benutzer in der Datenbank des Portals „DozentWeb“ als Administrator
geführt wird. Die Methode „GetAufgabenToDo“ liefert dem Dozenten eine Liste von
Aufgaben zurück, die von Tutoren vorkorrigiert und noch nicht vom Dozenten
bearbeitet wurden. Eine Liste von allen bereits durch den Dozenten bewerteten
Aufgaben
erzeugt
die
Methode
„GetBearbeiteteAufgaben“.
„GetVorkorrigierteAufgaben“ liefert eine Liste aller Aufgaben, die durch Tutoren
bearbeitet
wurden.
Durch
die
Methode
„GetVeranstaltungen“
werden
alle
Veranstaltungen, die von diesem Dozenten betreut werden, zurückgeliefert.
Abbildung 5.7: Klassendiagramm Modul „Verwaltung von
E-Learning Objekten“ Paket Dozent
Klassendiagramm Student
Die Klasse „Student“ (Web Service) erhält über die Klasse „DBHandler“ Zugriff auf die
Datenbanken des Portals „DozentWeb“ und einer Datenbank, die der Speicherung von
Daten des Moduls „Verwaltung von E-Learning Objekten“ dient. Die Methode
„HausaufgabeAbgeben“ ermöglicht es, eine bearbeitete Aufgabe zur Vorkorrektur
abzugeben. Die Methode „GetAktivesSemester“ liefert die Kennung des aktuellen
Semesters
zurück.
Eine
Liste
aller
Veranstaltungen
liefert
die
Methode
„GetVeranstaltungen“. Über die Methode „ShowMyHausaufgaben“ können alle
5 Prototypische Realisierung
47
Hausaufgaben, die zu einem Semester und einer Veranstaltung gehören, eingesehen
werden. Die Methode „ShowMySelectableHausaufgaben“ zeigt die Hausaufgaben
eines Semesters und einer Veranstaltung, die noch von dem Studenten abgegeben
werden können. „GetMyHausaufgabenDone“ zeigt die Hausaufgaben, die von diesem
Studenten abgegeben wurden und zur Vorkorrektur bei einem Tutor vorliegen. Durch
die Methode „GetMyHausaufgabenDoneBewertet“ kann der Student die Hausaufgaben
einsehen, die von einem Dozenten bewertet wurden und die erreichte Punktzahl
erfahren.
Abbildung 5.8: Klassendiagramm Modul „Verwaltung von ELearning Objekten“ Paket Student
5 Prototypische Realisierung
48
Klassendiagramm Tutor
Die Klasse „Tutor“ (Web Service) erhält über die Klasse „DBHandler“ Zugriff auf die
Datenbanken des Portals „TutorClient“ und einer Datenbank, die der Speicherung von
Daten des Moduls „Verwaltung von E-Learning Objekten“ dient. Durch die Methode
„KorrekturAbgeben“
können
Tutoren
korrigierte
Aufgaben
an
den
Dozenten
weiterreichen. Die Methode „GetVeranstaltungNameForTutor“ liefert den Namen der
Veranstaltung zurück, die der Tutor betreut. „GetAufgabenForTutor“ erzeugt eine Liste
aller Aufgaben, die zur Vorkorrektur bei diesem Tutor eingereicht wurden. Eine
Übersicht über alle bereits korrigierten Aufgaben eines Tutors erzeugt die Methode
„GetKorrekturForTutor“. Die Methode „GetAufgabenToDoForTutor“ listet alle Aufgaben
auf, die noch von diesem Tutor korrigiert werden müssen.
Abbildung 5.9: Klassendiagramm Modul „Verwaltung von ELearning Objekten“ Paket Tutor
5.2
Implementierung
Im Folgenden wird ein kurzer Überblick über die Implementierung der beiden Module
„Zeiterfassung“ und „Verwaltung von E-Learning Objekten“ gegeben. Dies geschieht
anhand beispielhafter Implementierungen. Der komplette Quellcode liegt der Arbeit als
Anhang bei. Bei den Beispielen unterscheiden wir zwischen Code-Beispielen auf der
Seite des Servers und des Client.
5 Prototypische Realisierung
49
Um einen Web Service, der in C# geschrieben ist, in einer Client Anwendung einfach
zu nutzen, stellt Microsoft mit der „wsdl.exe“ (enthalten im Microsoft .NET Framework
Software Development Kit) eine Lösung bereit. Der Web Service wird an die „wsdl.exe“
übergeben; als Rückgabe erhält man eine Proxyklasse (Stellvertreterklasse) für diesen
Web Service. Diese Stellvertreterklasse muss mit dem Kompiler des .NET Framework
übersetzt
werden.
Stellvertreterklasse
Dadurch
erzeugt.
wird
Diese
eine
Library
(Programmbibliothek)
Programmbibliothek
muss
in
dieser
den
Client
eingebunden werden, damit dieser über die Stellvertreterklasse Zugriff auf den Web
Service hat.
Im Einzelnen sind die Schritte zur Erzeugung einer Programmbibliothek einer
Stellvertreterklasse folgende:
wsdl.exe /l:c# /n:proxy /out:proxy.cs DerWebService.asmx
Der Parameter „/l:“ legt die Programmiersprache fest; über den Parameter „/n:“ wird der
Namensraum (vgl. Glossar) der Stellvertreterklasse bestimmt. Die „wsdl.exe“ erzeugt
dadurch für den Web Service eine Stellvertreterklasse in C# mit dem Namen „proxy“ in
der Datei proxy.cs.
csc.exe /target:library proxy.cs
Durch
obigen
Befehl
wird
die
Stellvertreterklasse
kompiliert
und
in
eine
Programmbibliothek mit dem Namen „proxy.dll“ übersetzt. Folgende Abbildung zeigt,
wie eine Stellvertreterklasse, die in einen Client eingebunden wurde, mit dem Server
agiert.
Abbildung 5.10: Die Stellvertreterklasse (Proxyklasse)
5 Prototypische Realisierung
50
Der Browser sendet eine Anfrage an die Stellvertreterklasse – dies geschieht über
„HTTP GET“ oder „HTTP POST“. Die Stellvertreterklasse formuliert nun aus dieser
Anfrage eine „SOAP-Nachricht“ und sendet diese über „HTTP“ an den Web Service.
Als Antwort erhält die Stellvertreterklasse XML, das an den Browser weitergeleitet wird.
Durch die Möglichkeit der „wsdl.exe“ des .NET Framework muss sich der
Programmierer von .NET Web Services nur noch sehr gering mit den Spezifikationen
SOAP, WSDL und den XML-Antworten auseinandersetzen.
5.2.1
Code-Beispiele Client (Webseiten)
Ein typisches Code-Beispiel auf der Seite des Client ist der Aufruf eines Web Service
in der Code-Behind Klasse einer ASP-Webseite. Voraussetzung hierfür ist die
Einbindung der Stellvertreterklasse als Programmbibliothek in dieser Klasse z.B. durch
den Befehl:
use Proxy;
Ist dies geschehen, wird eine Instanz einer Stellvertreterklasse erzeugt mit folgender
Zeile:
proxy.Zeiterfassung myService = new proxy.Zeiterfassung();
Auf der Instanz dieser Stellvertreterklasse wird als Methodenaufruf die Web Methode
dieses Web Service aufgerufen.
Die Web Methode „IsUserLoggedIn“ kann
beispielsweise wie folgt aufgerufen werden:
myService.IsUserLoggedIn();
Alle Web Services, die in den Klassendiagrammen dargestellt sind, können so erzeugt
und ihre Web Methoden dementsprechend aufgerufen werden. Gibt der Web Service
„IsUserLoggedIn“ den Wert „true“ zurück,
können von diesem Client die Web
Methoden aufgerufen werden, die vor nicht eingeloggtem Zugriff geschützt sind. Ein
Beispiel für einen solchen Web Service ist „ShowMyAccountWeek“, der die
Wochendaten eines Nutzers bereitstellt. Eine Einbindung in eine Code-Behind Klasse
würde z.B. folgendermaßen geschehen:
5 Prototypische Realisierung
51
if (myService.IsUserLoggedIn())
{
string user = myService.GetLoggedInUser();
System.Data.DataSet WeekList = ((System.Data.DataSet)
myService.ShowMyAccountWeek(user, veranstaltung ));
weekData.DataSource = WeekList;
weekData.DataBind();
}
Zuerst wird durch eine „if-Abfrage“ sichergestellt, dass der User eingeloggt ist. Im
zweiten Schritt wird über den Web Service „GetLoggedInUser“ die Benutzerkennung
des Users erfragt. Danach werden die Wochendaten für diesen Benutzer mit dieser
Benutzerkennung über den Web Service „ShowMyAccount“ abgerufen. Die Daten
werden in einem DataSet gespeichert. Ein DataSet nimmt z.B. Ergebnisse von
Datenbankabfragen auf und speichert diese intern wiederum als Datenbank ab.
Deshalb werden DataSets auch als Abbilder von Datenbanken bezeichnet, jedoch mit
dem Unterschied, dass DataSets nur im Speicher existieren, wohingegen Datenbanken
persistent sind. Auf der ASP.NET-Webseite existiert ein Element „weekData“. Dies ist
ein DataGrid. Jedes DataGrid kann an eine Quelle zum Befüllen gebunden werden.
Dies kann ein DataSet wie im vorliegenden Beispiel sein. Das DataGrid stellt die so
befüllten Daten als Tabelle auf der ASP.NET-Seite dar. Dadurch werden die
abgefragten Wochendaten des Benutzers auf der Webseite ausgegeben.
5.2.2
Code-Beispiel Server (Web Services)
Die Web Services auf Seiten des Servers sind als Klassen implementiert. Sie sind
abgeleitete Klassen von der Klasse „System.Web.Services.WebService“ des .NET
Framework. Der Rumpf einer Web Service Klasse sieht z.B. folgendermaßen aus:
[WebService(Namespace="http://WebServiceE-Learning/")]
public class Student : System.Web.Services.WebService
Die erste Zeile deklariert diese Klasse als eine Web Service Klasse und legt deren
Namensraum fest. In den folgenden Zeilen wird die Klasse „Student“ als öffentliche
Klasse erstellt. Die einzelnen Web Services sind Methoden dieser Klasse – diese
werden im .NET Framework als „Web Methode“ bezeichnet. Zu jeder Web Service
5 Prototypische Realisierung
52
Klasse und ihren Methoden erzeugt das .NET Framework passende Webseiten, durch
die der Web Service im Browser betrachtet und aufgerufen werden kann.
Abbildung 5.11: Webseite für den Web Service Student
Ein einfaches Code-Beispiel für eine Methode eines Web Service ist die Methode
„GetSemesterKalenderwochen“ aus dem Web Service „Zeiterfassung“.
[WebMethod]
public string[] GetSemesterKalenderwochen(
string semestername)
{
return DBHandler.GetSemesterKalenderwochen(
semestername);
}
Die Methode wird mit dem Bezeichner „[WebMethod]“ als Methode eines Web Services
bekanntgemacht. Durch diesen Bezeichner wird die Methode veröffentlicht und eine
Webseite, die das Betrachten und Aufrufen der Methode durch einen Browser
ermöglicht, wird bereitgestellt. Die Methode hat ein Feld von Strings als Rückgabewert
und nimmt als Parameter einen String auf, der den Semesternamen beinhaltet. Die
5 Prototypische Realisierung
53
Methode reicht diesen erhaltenen Parameter weiter an eine Methode der Klasse
„DBHandler“, welche die benötigten Daten bei der Datenbank erfragt und diese an die
Web Methode zurückgibt. Bei diesem Beispiel ist der Rückgabewert eine Liste der
Kalenderwochen, die in dem erfragten Semester liegen. Ein beispielhafter Aufruf der
Web Methode über einen Browser ist folgender:
Abbildung 5.12: Aufruf der Web Methode „GetSemesterKalenderwochen“
Das Ergebnis des Aufrufs einer Web Methode wird als XML zurückgeliefert und stellt
sich in diesem Beispiel wie folgt dar:
Abbildung 5.13: Rückgabewerte der Web Methode „GetSemesterKalenderwoche“
5 Prototypische Realisierung
54
Als Ergebnis wird eine in XML formatierte Liste der Kalenderwochen, die im
Wintersemester 05/06 liegen, zurückgegeben. Der Client kann nun mit den
bereitgestellten Daten arbeiten.
Ein weiters typisches Code-Beispiel für die Implementierung eines Web Service in die
z.B. oben genannte Klasse „Student“ ist die Web Methode „IsUserLoggedIn“.
[WebMethod(EnableSession=true) ]
public bool IsUserLoggedIn()
{
object loggedIn = Session["LoggedIn"];
if (null != loggedIn)
return (bool)loggedIn;
return false;
}
Diese unterscheidet sich durch den Zusatz „(EnableSession=true)“ in dem Bezeichner
„[WebMethod]“ von der vorhergehenden Web Methode. Dadurch wird diese Web
Methode sitzungsfähig gemacht. Web Methoden ohne diesen Zusatz sind wie z.B.
HTML-Seiten zustandslose und können sich nicht merken, in welchem Kontext sie
stehen. Die Methode liefert als Rückgabewert einen boolschen Wert zurück. Parameter
sind nicht erforderlich für diesen Vorgang. Daten über Sitzungen werden in
Sessionobjekten gespeichert; dementsprechend tragen sie den Namen „Session“. In
diesen Sessionobjekten können verschiedene Attribute gespeichert werden, wie z.B.
Name und Status eines Benutzers. Das Sessionobjekt wird in diesem Beispiel nach
dem Status des Attributs „LoggedIn“ gefragt. Ist ein Attribut mit diesem Namen
vorhanden, wird dieses zurückgegeben. Sollte das Attribut „LoggedIn“ nicht vorhanden
sein, so wird in jedem Fall der Wert „false“ zurückgegeben.
Ein typisches, aber eher komplexes Beispiel für Web Methoden in der Klasse „Student“
ist die Web Methode „GetVeranstaltungen“. Diese Web Methode soll zurückgeben,
welche Veranstaltungen in der Datenbank hinterlegt wurden. Die Rückgabe erfolgt als
ein DataSet; Parameter sind keine notwendig. Die Web Methode stützt sich hierbei
einerseits auf die Sessionobjekte, um die Gültigkeit der Anfrage festzustellen und
andererseits auf die Klasse „DBHandler“ für den Dantenbankzugriff.
5 Prototypische Realisierung
55
[WebMethod(EnableSession=true)]
public DataSet GetVeranstaltungen()
{
if ((object)Session["LoggedIn"] == null)
return null;
if ((bool)Session["LoggedIn"] == true)
{
string query = "Select Name from veranstaltung";
DataSet dataSet = new DataSet("dataSet");
return DBHandler.SelectFromDatabase(
dataSet, DBHandler.MY_CONN_STRING, query);
}
else
return null;
}
Nachdem überprüft wurde ob der Benutzer eingeloggt ist, wird der String „query“ mit
einer
Datenbankabfrage
aufgebaut.
Dieser
String
wird
an
die
Methode
„SelectFromDatabase“ der Klasse „DBHandler“ übergeben. Zusätzlich werden an diese
Methode noch ein leeres DataSet, welches mit dem Ergebniss befüllt wird, und der
Connection String übergeben.
Web Services übernehmen aber nicht nur die Aufgabe der Sitzungsverwaltung und
Erstellung der Datenbankabfragen. Sie steuern auch die Logik, die den Änderungen an
Datenbanken vorhergehen muss. Dies soll an der Web Methode „AddSemester“
verdeutlicht werden. Diese Methode wird immer aufgerufen, wenn Änderungen an den
Semesterdaten in der Datenbank vorgenommen werden müssen. Dies geschieht bei
zwei Anwendungsfällen: Es wird ein neuer Eintrag hinzugefügt oder es wird ein bereits
bestehender Eintrag editiert. In dem folgenden Beispiel wurde aus Gründen der
Übersichtlichkeit der Code, der die Sitzungsverwaltung betrifft, weggelassen.
[WebMethod(EnableSession=true)]
public bool AddSemester(String semesterName, int wochen,
int startKalenderwoche, int aktiv,
5 Prototypische Realisierung
56
int startJahr)
{
bool status = false;
if(DBHandler.IsNewSemester(semesterName))
{
status = DBHandler.InsertSemester(
semesterName, wochen,
startKalenderwoche, aktiv, startJahr);
}
else
{
status = DBHandler.UpdateSemester(
semesterName, wochen,
startKalenderwoche, aktiv, startJahr);
}
return status;
}
Per Parameter werden die Daten für die Änderung an den Semesterdaten an die Web
Methode „AddSemester“ übergeben. Diese überprüft nun mit Hilfe der Klasse
„DBHandler“ und der Methode „IsNewSemester“, ob es sich um einen neuen Eintrag
handelt oder ob ein Eintrag editiert wurde. Nach dem Ergebnis dieser Abfrage wird die
Methode „InsertSemester“ oder die Methode „UpdateSemester“ mit den Parametern
gerufen. Der boolsche Wert „status“ zeigt an, ob die Operation erfolgreich auf der
Datenbank ausgeführt werden konnte.
6 Feasibility Study Workflow-Management
6
57
Feasibility Study Workflow-Management
Dieses Kapitel beschäftigt sich damit inwiefern die Unterstützung der vorliegenden
Web Services durch Workflow-Management machbar und sinnvoll ist. Als zu
untersuchende Tools des Workflow-Management wurden BPEL und XML-Netze
gewählt.
6.1
BPEL
BPEL kann nur auf Servern ausgeführt werden, die diese Sprache unterstützen. Dies
sind z.B. folgende Server:
•
Microsoft BizzTalk Server 2004
•
Oracel BPEL Process Manager
•
IBM WebSphere Business Integration Server Foundation
•
IBM BPWS4J
•
Vergil VCAB
•
OpenStorm Service Orchestrator
•
ActiveBPEL Engine and ActiveWebflow
In den folgenden Beispielen wird von „naivem“ BPEL ausgegangen, das von allen
Servern unterstützt wird. Einige Firmen haben BPEL auf ihrem Server noch mit
Erweiterungen ausgestattet. Es wird im weiteren Verlauf von allgemeinem BPEL der
Version 1.1 ausgegangen, ohne auf die Zusätze und Einschränkungen verschiedener
Serveranbieter zu achten.
Für Microsoft .NET Web Services wie sie hier verwendet wurden, ist der BizzTalk
Server 2004 von Microsoft kompatibel. Dieser läuft allerdings nur auf einem Microsoft
Windows Server 2003, auf dem ein Microsoft SQL Server 2000 installiert ist. Da der in
dieser Arbeit erstellte Prototyp auf einer Microsoft Windows XP Plattform mit einer
MySQL Datenbank entwickelt wurde, steht diese Option zur Realisierung nicht zur
6 Feasibility Study Workflow-Management
Verfügung.
Die
Überprüfung
der
58
Machbarkeit
kann
eingeschränkt
dennoch
weitergeführt werden unter der Annahme, dass Betriebssystem und Datenbank
ausgetauscht werden.
Um die Machbarkeit von BPEL für die prototypische Realisierung dieser Arbeit zu
untersuchen, muss ein Prozess (Arbeitsablauf) betrachtet werden. Beispielhaft hierfür
wäre z.B. der Prozess der Abgabe einer Hausaufgabe durch einen Studenten aus dem
Modul „Verwaltung von E-Learning Objekten“. Dieser Prozess besteht aus zwei
Schritten: Überprüfung, ob diese Hausaufgabe schon abgegeben wurde sowie
Benachrichtigung des Tutors über den Eingang einer neuen Hausaufgabe. Die zweite
Aktivität ist abhängig vom dem Ausgang der ersten Aktivität. Dieser Prozess wird in der
prototypischen Realisierung als ein Web Service dargestellt, der alle dazugehörigen
Funktionen aufruft. Diese könnten aber auch als eigenständige Web Services
implementiert sein. Von diesem Fall wird hier ausgegangen. Folgende Abbildung zeigt
den Prozess mit seinen Aktivitäten:
Abbildung 6.1: Prozess „Hausaufgabe
abgeben“
Es ist davon auszugehen, dass „Überprüfung der Abgabe“ und „Benachrichtigung
Tutor“ eigenständige Web Services sind, die nacheinander von einem Workflow
angestoßen werden müssen, damit sie ausgeführt werden.
Bei diesem Beispiel wurde der Code an einigen Stellen gekürzt oder nur
andeutungsweise wiedergegeben. Wie bereits erklärt, ist nicht die Implementierung auf
einer konkreten Plattform Ziel dieses Kapitels, sondern die Untersuchung der
6 Feasibility Study Workflow-Management
59
allgemeinen Machbarkeit von Workflow-Management an einem Beispiel aus dem
Modul „Verwaltung von E-Learning Objekten“. Das folgende Beispiel entstand in
Anlehnung an die Beispiele in [6].
Als erstes müssen die beteiligten Partner durch folgende Zeilen beschrieben werden:
<partnerLinks>
<partnerLink name="Client" partnerLink="http://WebClient" />
<partnerLink name="AbgabePrüfen" partnerLink=
"http://WebService/" />
</partnerLinks>
In diesem Beispiel werden durch die Zeilen der Client und der beteiligte Web Service
bekanntgemacht. Danach müssen die Variablen für die Anfragen und Antworten der
Web Methoden des Web Service festgelegt werden.
<variables>
<variable name="AbgabePrüfenRequest" messageType=
"AbgabePrüfenRequestMessage" />
<variable name="AbgabePrüfenResponse" messageType=
"AbgabePrüfenResponseMessage" />
<variable name="TutorBenachrichtigenRequest" messageType=
"TutorBenachrichtigenRequestMessage" />
</variables>
Abschließend muss der Prozess selbst beschrieben werden. Hier wird festgelegt,
welche Web Methoden in welcher Reihenfolge und unter welcher Bedingung
aufgerufen werden.
<sequence>
<receive partnerLink="Client"
operation="HausaufgabeAbgeben"
variable="AbgabePrüfenRequest"
createInstance="yes"
</receive>
6 Feasibility Study Workflow-Management
60
In diesem ersten Abschnitt, der mit „<receive>“ umschrieben ist, wird festgelegt durch
welches Event der Prozess ausgelöst wird – in diesem Fall durch den Aufruf der Web
Methode „HausaufgabeAbgeben“ – und welche Variablen übergeben werden müssen.
Danach folgt die Beschreibung der Web Methoden der oben festgelegten Web
Services, die in diesem Prozess gerufen werden. Diese werden mit ihren Ein- und
Ausgabevariablen beschrieben.
<flow>
<invoke partnerLink="WebService"
operation="AbgabePrüfen"
inputVariable="AbgabePrüfenRequest"
outputVariable="AbgabePrüfenResponse"
</invoke>
<invoke partnerLink="WebService"
operation="TutorBenachrichtigen"
inputVariable="TutorBenachrichtigenRequest"
</invoke>
</flow>
</sequence>
Nachdem die beteiligten Web Methoden festgelegt wurden, können die Bedingungen
der Aufrufe bestimmt werden. Dies geschieht mit den Konstrukten „<switch>“, „<case>“
und „<otherwise>“. Desweiteren bietet BPEL noch mehr Möglichkeiten, um
Bedingungen abzufragen und den Ablauf von Web Services zu steuern. Die hier
beschriebenen Konstrukte stellen nur einige Grundbausteine von BPEL dar. Ein
gesamter Überblick über BPEL und seine Möglichkeiten kann an dieser Stelle nicht
gegeben werden. Es wurde aber gezeigt, dass der beschriebene Prozess in BPEL
abgebildet werden kann. Dadurch ist die Machbarkeit von Workflow-Management
durch BPEL bei diesem Prototyp gegeben.
Ob eine Umsetzung mit BPEL am gegebenen Prototyp sinnvoll ist, liegt in der
Komplexität der Prozesse. Der Prototyp implementiert einfache und kurze Prozesse,
die leicht durch den Code selbst gesteuert werden können. Eine Umsetzung mit BPEL
ist aus diesem Grunde nicht sinnvoll, da die Einsparungen im Code nicht den
6 Feasibility Study Workflow-Management
Mehraufwand
der
Einrichtung
61
eines
Workflow-Managements
rechtfertigt.
Bei
Weiterentwicklung des Protoyps muss diese Entscheidung immer wieder von Neuem
untersucht werden.
6.2
XML-Netze
XML-Netze sind eine neue, höhere Variante von Petri-Netzen (vgl. Glossar). Eine
Besonderheit von Petri-Netzen ist ihre eindeutige graphische Darstellung und die
einfache Verhaltensbeschreibung. Alle Petri-Netze besitzen eine gemeinsame
Grundstruktur. Auf dieser bauen XML-Netze auf. Ein Definition von XML-Netzen findet
sich z.B. unter [9], dort heißt es:
„XML-Netze integrieren strukturierte XML-Dokumente in eine Petri-Netzbasierte
Ablaufmodellierungssprache.
XML-Netze
ermöglichen
die
Modellierung voneinander abhängiger, aber auch nebenläufiger und
alternativer betrieblicher Abläufe, die auf XML-Dokumenten basieren.“
Um die graphische Modellierung bei XML-Netzen zu ermöglichen, müssen folgende
XML-Erweiterungssprachen
zum
graphischen
XML-basierten
Dokumenten-
management eingesetzt werden:
•
GXSL (Graphical XML Schema Definition Language)
•
XManiLa (XML Manipulation Language)
Diese können direkt von Workflow-Engines ausgeführt werden wodurch XML-Netze
formuliert werden können. Workflow-Engines, die XML-Netze unterstützen, sind z.B.
folgende:
•
YAWL (Yet Another Workflow Engine)
•
Bossa
•
Microsofts BizzTalk 2004
Es gibt noch weitere Workflow-Engines, sowohl kommerzielle Engines als auch Open
Source-Engines, die XML-Netze unterstützen. Im Gegensatz zu BPEL, das
hauptsächlich von kommerziellen Engines unterstützt wird, werden XML-Netze stark
6 Feasibility Study Workflow-Management
62
durch Open Source-Engines unterstüzt. Bossa und YAWL sind z.B. beides Open
Source-Engines. Ein Nachteil von XML-Netzen liegt darin, dass es – soweit feststellbar
– noch keine Unterstützung durch Tools zur Modellierung solcher XML-Netze gibt. Ein
weiterer Nachteil in Bezug auf den hier zu Grunde liegenden Prototypen ist die
Tatsache, dass sich XML-Netze zur Modellierung von Abläufen auf die Verarbeitung
von XML-Dokumenten
stützen.
Die Lernobjekte des
Prototypen
sind nicht-
standardisierte Dokumente verschiedenster Formate. Diese müssten in XMLDokumente umgewandelt werden, um sie für XML-Netze nutzbar zu machen. Dies
stellt eine grundlegende Änderung an der prototypischen Realisierung dar. Die
Realisierung von XML-Netzen mit dem gegebenen Prototypen setzt dadurch weitere
größere Implementierungen voraus. Die Realisierbarkeit von XML-Netzen mit den in
dieser Arbeit eingesetzten Prototypen und Werkzeugen ist deshalb nicht gegeben.
7 Sicherheitsaspekte
7
Sicherheitsaspekte
7.1
Allgemeine Sicherheitsanforderungen
63
Sicherheit gilt als ein schwerwiegendes Problem von Web Services. In diesem Kapitel
sollen zuerst die grundlegenden Sicherheitsanforderungen und potenziellen Lücken bei
Web Services aufgezeigt werden, um dann im nächsten Abschnitt die möglichen
Spezifikationen für Web Service-Sicherheit vorstellen zu können.
Die Sicherheitsanforderungen sind im Einzelnen laut [3] folgende:
•
Authentifizierung: bezeichnet das Erkennen des Kommunika­
tionspartners.
•
Autorisierung: steht für die Überwachung der Rechte, die ein
Kommunikationspartner besitzt.
•
Glaubwürdigkeit: bedeutet, dass eine Nachricht auch nachträglich
noch einem Sender zugeordnet werden kann.
•
Vertraulichkeit: besagt, dass die Daten vor dem Zugriff Dritter von
außen geschützt sind.
•
Verfügbarkeit: gewährleistet zu guter Letzt, dass der Web Service
einsetzbar ist und nicht „gewaltsam“ in seiner Funktionalität ein­
geschränkt werden kann.
Die Sicherheitsanforderungen zeigen nicht auf, an welchen Stellen Web Services für
Angriffe verwundbar sind. Um potenzielle Sicherheitslücken zu erkennen, muss
bekannt sein, wo Web Services verwundbar sind. Ein Web Service besteht meist aus
drei beteiligten Systemen: Endbenutzer, Konsument und Anbieter. Angriffe auf Web
Services sind an allen drei Stellen möglich. Web Services sind desweiteren für „man in
the middle“ (MITM) Angriffe anfällig, da die Daten unverschlüsselt übertragen werden.
Folgende Szenarien sollen zeigen, wie die Systeme beispielsweise angegriffen werden
können:
7 Sicherheitsaspekte
•
64
Direkter Angriff auf den Server des Web Service Anbieters: Dadurch
ergibt sich eine Beeinträchtigung der Verfügbarkeit.
•
Angriff auf den Server des Konsumenten: Dabei erhält der Angreifer
unter Umständen Daten über Authentifizierung und Autorisierung.
•
Angriff auf den Datenverkehr, um Passwörter oder ähnlich sensible
Daten zu erlangen durch z.B. MITM-Angriffe.
Diese Auswahl von Beispielen kann beliebig erweitert werden und ist weder vollständig
noch repräsentativ. Folgende Abbildung soll nochmals die beteiligten Systeme und die
Angriffsmöglichkeiten bei Web Services verdeutlichen.
Abbildung 7.1: Beteiligte Systeme und Angriffsmöglichkeiten bei Web Services
(Quelle: Hauser,M., Löwer,M.,U., Web Services Die Standards, 2004, S. 130)
7 Sicherheitsaspekte
7.2
65
Sicherheitslösungen für Web Services
Sicherheitslösungen für Web Services unterscheiden sich in zwei Kategorien: in
Lösungen ohne Standards und Lösungen mit Standards.
Lösungen ohne Standards
Dies sind Lösungen, die zur Sicherung von Web Services abseits der neuen Standards
von großen Firmen und Standardisierungsorganisationen eingesetzt werden können.
Folgende Liste soll einen kurzen Überblick über verfügbare Lösungen geben:
•
SSL (Secure Socket Layer)
•
IPSec (Internet Protocol Security) und VPNs (Virtual Private Network)
•
Firewalls
•
Vermeidung von SQL Injections durch Verwendung von Stored
Procedures
Der Vorteil dieser „unstandardisierten“ Lösungen besteht darin, dass sie unabhängig
von
den
Web
Services
implementiert
werden
können.
Sollte
eine
dieser
Sicherheitslösungen schon auf einem System implementiert sein, kann sie von Web
Services mitgenutzt werden. In diesem Vorteil liegt aber auch ein Nachteil: Da diese
Lösungen nicht für Web Services entwickelt wurden, beeinträchtigen sie meist die
Performance der Web Services.
Lösungen mit Standards
Die „unstandardisierten“ Lösungen des letzten Abschnitts sind nicht auf die
Bedürfnisse von Web Services zugeschnitten und bringen einige Nachteile mit sich.
Deshalb entwickelten einige große Firmen und Standardisierungsorganisationen neue
Spezifikationen, um die Sicherheitsanforderungen für Web Services zu decken. Es
wurden z.B. folgende neue Spezifkationen für Web Services entwickelt:
•
XML-Signaturen
•
XML-Encryption
7 Sicherheitsaspekte
66
•
XKMS (XML Key Management Specification)
•
XACML (Extensible Access Control Markup Language)
•
SAML (Secure Assertion Markup Language)
•
WS-Security (Web Service-Security)
Jede dieser Spezifikationen wurde entwickelt, um einen oder mehrere Aspekte der
Sicherheitsanforderungen für Web Services abdecken zu können. Folgende Tabelle
zeigt die Abdeckung der Anforderungen durch die hier genannten Sicherheitslösungen.
Tabelle 7.1: Sicherheitsstandards für Web Services
Anforderung/ Authentifi­
zierung
Standard
XML-
Auto­
risierung
Glaub­
würdigkeit
Vertraulich­ Verfüg­
keit
barkeit
+
-
+
-
-
-
-
-
+
-
XKMS
+
-
-
+
-
XACML
+
+
-
-
-
SAML
+
+
-
-
-
WS-Security
+
+
+
+
-
Signaturen
XMLEncryption
(Quelle: Hauser,M., Löwer,M.,U., Web Services Die Standards, 2004, S. 136)
Die prototypische Implementierung, die im Rahmen dieser Arbeit erstellt wurde,
verwendet keine der hier vorgestellten Sicherheitslösungen. Sicherheit für Web
Services kann zwar implementiert werden, doch viele Lösungen sind zu einigen Web
Services-Implementierungen und untereinander noch inkompatibel. Die Realisierung
von Sicherheit für Web Services ist weiterhin an größere Implementierungen, die
weitere Planungen voraussetzen, gekoppelt. Die Web Services der prototypischen
Realisierung sind deshalb anfällig gegenüber den beschriebenen Sicherheitslücken.
8 Zusammenfassung und Ausblick
8
67
Zusammenfassung und Ausblick
In dieser Diplomarbeit wurden die bedeutsamen Aspekte einer prototypischen
Realisierung zur Verwaltung von E-Learning Objekten erörtert. Dies geschah auf der
Basis
einer
vorhergehenden
Bachelorthesis
automatischer
Datenaustausch
zwischen
(Kim
Matthäß:
befreundeten
Content
„Kontrollierter
Management
Systemen“, HS Karlsruhe, Fak. WI, 2005) zum Thema des kontrollierten und
automatischen
Datenaustauschs.
Im
Bereich
des
E-Learning
liegt
dieser
Datenaustausch in Form von Lern- und Administrationsobjekten vor. Neben einer
kurzen Beschreibung der verschiedenen Formen des E-Learning und deren
Verwendung wurde vor allem ein Konzept zur Verwaltung von E-Learning-Objekten
entwickelt. Zur Bildung dieses Konzepts wurden eine Problembeschreibung und eine
Funktionsbeschreibung
ausgearbeitet.
Die
Beschreibung
erfolgte
durch
Aktivitätsdiagramme, Sequenzdiagramme und Use-Cases. Um die Realisierbarkeit des
Konzepts nachzuweisen, wurde eine Testumgebung aus zwei konkreten Content
Management Systemen realisiert. Die prototypische Realisierung wurde auf Basis von
Microsoft Web Services und ASP.NET Webseiten implementiert. Die Webseiten bilden
hierbei den Client für die Web Services, welche als Server agieren. Als Basissoftware
für die Content Management Systeme wurde Mambo aus einer Reihe von Open
Source CMS ausgewählt und implementiert. Bei der Realisierung zeigten sich erste
Schwierigkeiten bezüglich der Kombination eines PHP-gestützten Systems wie Mambo
mit ASP.NET Webseiten. Der Webserver IIS (Internet Information Service) muss beide
Sprachen verstehen und übersetzen können, bringt jedoch von Haus aus nur die
Unterstützung für ASP.NET mit. Diese Hürde konnte durch die Installation von PHP
und die Einbindung in den IIS überwunden werden. Ein weiteres Problem stellte die
Verbindung der Web Services zur MySQL Datenbank dar. Die Sprache C#, in welcher
die Web Services geschrieben werden sollten, kennt keine einfache Möglichkeit der
Verbindung zu MySQL Datenbanken. Dies konnte behoben werden durch eine
Programmbibliothek von MySQL, welche die Möglichkeit von einfachen Verbindungen
von C# zu MySQL Datenbanken implementiert. Diese Schwierigkeiten sind
bezeichnend für Web Services, da viele Web Service Implementierungen mit
bestehenden Technologien nicht kompatibel sind und oft nur eine sehr begrenzte
Auswahl an kompatiblen Technologien vorhanden ist. Properitäre Produkte wie
Microsoft Web Services setzten meist nur auf Produkte aus dem eigenen Haus.
8 Zusammenfassung und Ausblick
68
Lösungen wie hier dargestellt sind anfällig dafür, nach einem Update einer oder
mehrerer der Technologien, wie z.B. C#, eingeschränkt oder gar nicht mehr zu
funktionieren.
Nachdem eine funktionierende Testumgebung eingerichtet wurde, konnte mit der
Realisierung des Prototyps begonnen werden. Zur Realisierung wurden im ersten
Schritt
Komponentendiagramme
erstellt,
mit
deren
Hilfe
in
der
Folge
Klassendiagramme erstellt werden konnten, auf denen die Implementierung basiert.
Microsoft bietet – vorausgesetzt, es werden Technologien aus dem eigenen Hause
verwendet – oft Tools an, um die Kommunikation zwischen diesen zu erleichtern. In
diesem Fall zeigte sich, dass durch die Verwendung der „wsdl.exe“ und die Erzeugung
von Stellvertreterklassen die Kommunikation zwischen Web Services und den
ASP.NET Webseiten vereinfacht werden konnte. Der Programmierer muss sich durch
dieses Tool nicht mehr um die im XML-Format gestaltete Kommunikation zu kümmern,
sondern kann die Aufrufe und die Handhabung der Rückgabewerte von Web Services
in den Webseiten in der von ihm gewünschten Programmiersprache erledigen.
Die Realisierbarkeit von Workflow-Management bei Web Services wurde beispielhaft
anhand von BPEL und XML-Netzen untersucht. Beide Möglichkeiten sind nicht ohne
Weiteres realisierbar. BPEL setzt voraus, dass die Web Services auf einem Microsoft
Server laufen und dass die Datenbank ein SQL Server von Microsoft ist. Beide
Voraussetzungen sind bei dem entwickelten Prototypen nicht gegeben. Durch eine
Untersuchung von Beispielen in BPEL konnte aber festgestellt werden, dass eine
Unterstützung durch BPEL realisierbar wäre, wenn der Prototyp diese Anforderungen
erfüllen würde. XML-Netze setzen als Grundlage XML-Dokumente zur Verwaltung
voraus, was bei dem Prototypen jedoch nicht gegeben ist. Dementsprechend kann ein
Workflow-Management durch XML-Netze nicht realisiert werden, da es nur durch
grundlegende Änderungen am Prototypen erreicht werden könnte.
Die
Sicherheitsaspekte
von
Web
Services
wurden
aufgrund
von
gültigen
Sicherheitsanforderungen und möglichen Sicherheitslücken untersucht. Es konnte
festgestellt werden, dass Web Services ohne zusätzliche Sicherheitslösungen anfällig
für eine Vielzahl von Angriffen sind. Mögliche Sicherheitslösungen wurden kurz
vorgestellt und deren Abdeckung der Sicherheitsanforderungen gezeigt.
Der entwickelte Prototyp zeigt, dass die Unterstützung der Verwaltung von E-Learning
Objekten durch Web Services umgesetzt werden kann. Eine Unterstützung durch
8 Zusammenfassung und Ausblick
69
Workflow-Management konnte unter den gegebenen Bedingungen nicht realisiert
werden. Die Unterstützung durch BPEL könnte aber durch Veränderungen an dem
Prototypen und der Entwicklungsplattform realisiert werden. Sicherheit kann für Web
Services mit den aufgezeigten Lösungen erreicht werden. Hierfür sind aber weitere
Untersuchungen und Planungen erforderlich. Abschließend kann gesagt werden, dass
Web Services momentan noch unter der Vielfalt der in diesem Projekt verwendeten
Standards und Technologien leiden. Sollte jedoch in Zukunft eine einheitliche Lösung
implementiert werden, wären Web Services durchaus in der Lage, eine sinnvolle und
realisierbare Technologie für die Verwaltung von E-Learning Objekten darzustellen.
Anhang: Quelltexte
Anhang: Quelltexte
Die folgenden Quelltexte sind hier aufgeführt:
•
Tutor.asmx
•
TutorInfos.aspx.cs
•
wsdl.bat
Die vollständigen Quelltexte befinden sich auf einer CD, die der Arbeit beigelegt ist.
Tutor.asmx:
using System;
using System.Collections;
using System.ComponentModel;
using System.Data;
using System.Diagnostics;
using System.Web;
using System.Web.Services;
using System.Security.Cryptography;
using System.Text;
namespace WebServiceE_Learning.Tutor
{
[WebService(Namespace="http://localhost/WebServiceE-Learning/")]
public class Tutor : System.Web.Services.WebService
{
public Tutor()
{
InitializeComponent();
}
70
Anhang: Quelltexte
71
[WebMethod(EnableSession=true) ]
public bool IsUserLoggedIn()
{
object loggedIn = Session["LoggedIn"];
if (null != loggedIn) return (bool)loggedIn;
return false;
}
[WebMethod(EnableSession=true) ]
public bool Login(string username, string password)
{
if (username == "" || username == null)
return false;
string query = "select username, password from mos_users "
+ "where username = " + "'" + username + "'";
DataSet dataSet = new DataSet("dataSet");
DBHandler.SelectFromDatabase(dataSet,
DBHandler.MY_CONN_STRING_TUT, query);
DataTable dt = dataSet.Tables[0];
if (dt.Rows.Count == 0)
return false;
DataRow dr = dt.Rows[0];
string userDB =
(dr.ItemArray)[0].ToString();
string pwDB = (dr.ItemArray)[1].ToString();
MD5CryptoServiceProvider md5 = new
MD5CryptoServiceProvider();
byte[] md5PassPhraseHash = md5.ComputeHash(
Encoding.ASCII.GetBytes(password));
StringBuilder sb = new StringBuilder();
for (int i = 0; i < md5PassPhraseHash.Length; i++)
Anhang: Quelltexte
{
sb.Append(md5PassPhraseHash[i].ToString("X2"));
}
string encodedPassword = sb.ToString().ToLower();
if ( userDB == username && pwDB == encodedPassword)
{
Session["LoggedIn"] = true;
Session["Username"] = userDB;
return true;
}
else
{
Session["Username"] = "";
Session["LoggedIn"] = false;
}
return false;
}
[WebMethod(EnableSession=true)]
public void Logout()
{
Session["LoggedIn"] = false;
Session["Username"] = "";
}
[WebMethod(EnableSession=true)]
public string GetLoggedInUser()
{
object user = Session["Username"];
if (null != user) return (string)user;
return "";
}
72
Anhang: Quelltexte
[WebMethod(EnableSession=true)]
public void KorrekturAbgeben(string tutor, int lid,
string url, double punkte)
{
if ((bool)Session["LoggedIn"] == true)
{
if (DBHandler.IsNewKorrektur(lid))
DBHandler.InsertVorKor(tutor, lid, url, punkte);
else
DBHandler.UpdateVorKor(tutor, lid, url, punkte);
}
}
[WebMethod(EnableSession=true)]
public string GetVeranstaltungNameForTutor(string tutor)
{
if ((object)Session["LoggedIn"] == null)
return "";
if ((bool)Session["LoggedIn"] == true)
{
return DBHandler.GetVeranstaltungNameForTutor(tutor);
}
else
return ""
}
[WebMethod(EnableSession=true)]
public DataSet GetAufgabenVorkorForTutor(string tutor)
{
if ((object)Session["LoggedIn"] == null)
return null;
if ((bool)Session["LoggedIn"] == true)
73
Anhang: Quelltexte
74
{
int sid = DBHandler.GetAktiveSemesterID();
int vid = DBHandler.GetVeranstaltungForTutor(tutor);
string query = "SELECT l.id as 'Loesungs Nr.', v.url"
+ " as 'Korrektur URL' , l.url as 'Loesung URL', "
+ " h.Beschreibung,v.Punkte as 'Vorkorrektur Punkte',"
+ " h.Punkte as 'Max. Punkte', l.Student, t.Name"
+ " from vorkorrektur v, tutor t, hausaufgabe h,loesung l
+ " where v.tutor = t.id "
+ " and v.hausaufgabe = h.id "
+ " and v.loesung = l.id "
+ " and h.Semester = " + sid
+ " and h.Veranstaltung = " + vid;
DataSet dataSet = new DataSet("dataSet");
return DBHandler.SelectFromDatabase(dataSet,
DBHandler.MY_CONN_STRING, query);
}
else
return null;
}
[WebMethod(EnableSession=true)]
public DataSet GetAufgabenForTutor(string tutor)
{
if ((object)Session["LoggedIn"] == null)
return null;
if ((bool)Session["LoggedIn"] == true)
{
int sid = DBHandler.GetAktiveSemesterID();
int vid = DBHandler.GetVeranstaltungForTutor(tutor);
string query = "select l.id as 'Loesungs Nr.', "
+ " h.Beschreibung, "
+ " l.Student, l.url as 'Loesung URL', "
+ " h.URL as 'Aufgabe URL', Punkte as 'Max.Punkte' "
"
Anhang: Quelltexte
75
+ " from loesung l, hausaufgabe h "
+ " where h.id = l.hausaufgabe "
+ " and h.veranstaltung = " + vid
+ " and h.semester = " + sid;
DataSet dataSet = new DataSet("dataSet");
return DBHandler.SelectFromDatabase(dataSet,
DBHandler.MY_CONN_STRING, query);
}
else
return null;
}
[WebMethod(EnableSession=true)]
public DataSet GetAufgabenToDoForTutor(string tutor)
{
if ((object)Session["LoggedIn"] == null)
return null;
if ((bool)Session["LoggedIn"] == true)
{
int sid = DBHandler.GetAktiveSemesterID();
int vid = DBHandler.GetVeranstaltungForTutor(tutor);
string query = "select h.Beschreibung,l.Student,l.Id "
+ " from loesung l , hausaufgabe h where "
+ " l.Hausaufgabe = h.id and "
+ " h.Semester = " + sid +" and "
+ " h.Veranstaltung = " + vid
+ " and l.id not in (select v.loesung from
+ " vorkorrektur v )";
DataSet dataSet = new DataSet("dataSet");
return DBHandler.SelectFromDatabase(dataSet,
DBHandler.MY_CONN_STRING, query);
}
else
return null;
Anhang: Quelltexte
}
}
}
TutorInfo.aspx.cs
using System;
using System.Collections;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Web;
using System.Web.SessionState;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.HtmlControls;
namespace WebZugriffE_Learning.Tutor
{
public class TutorInfo : System.Web.UI.Page
{
protected System.Web.UI.WebControls.TextBox UserTextBox;
protected System.Web.UI.WebControls.TextBox PasswortTextBox;
protected System.Web.UI.WebControls.Label UserLabel;
protected System.Web.UI.WebControls.Label PasswortLabel;
protected System.Web.UI.WebControls.Label HeaderLabel;
protected System.Web.UI.WebControls.DataGrid VorDataGrid;
protected System.Web.UI.WebControls.Label
AbgegebeneHausaufgabenLabel;
protected System.Web.UI.WebControls.Label VorLabel;
protected System.Web.UI.WebControls.DataGrid
AbgegebeneHausaufgabenDataGrid;
protected System.Web.UI.WebControls.DropDownList
HausaufgabeDropDownList;
protected System.Web.UI.WebControls.TextBox URLTextBox;
76
Anhang: Quelltexte
protected System.Web.UI.WebControls.Label URLLabel;
protected System.Web.UI.WebControls.Label PunkteLabel;
protected System.Web.UI.WebControls.Button VorKorButton;
protected System.Web.UI.WebControls.Label StatusLabel;
protected System.Web.UI.WebControls.Button LoginButton;
protected System.Web.UI.WebControls.Label VorEinLabel;
protected System.Web.UI.WebControls.TextBox PunkteTextBox;
protected System.Web.UI.WebControls.Button Logout;
private static proxyTutor.Tutor myService;
private static System.Net.CookieContainer cookies;
private void Page_Load(object sender, System.EventArgs e)
{
myService = new proxyTutor.Tutor();
if (cookies == null)
{
cookies = new System.Net.CookieContainer();
myService.CookieContainer = cookies;
}
else
myService.CookieContainer = cookies;
if (myService.IsUserLoggedIn())
{
ShowLoggedIn(true);
}
else
ShowLoggedIn(false);
if (! IsPostBack)
{
FillHausaufgabenDropDown();
}
77
Anhang: Quelltexte
78
FillGrids();
}
private void FillHausaufgabenDropDown()
{
HausaufgabeDropDownList.DataSource =
myService.GetAufgabenToDoForTutor(
myService.GetLoggedInUser());
HausaufgabeDropDownList.DataTextField = "Id";
HausaufgabeDropDownList.DataValueField = "Id";
HausaufgabeDropDownList.DataBind();
}
private void ShowLoggedIn(bool trigger)
{
AbgegebeneHausaufgabenDataGrid.Visible = trigger;
AbgegebeneHausaufgabenLabel.Visible = trigger;
VorLabel.Visible = trigger;
VorDataGrid.Visible = trigger;
HausaufgabeDropDownList.Visible = trigger;
URLTextBox.Visible = trigger;
URLLabel.Visible = trigger;
PunkteLabel.Visible = trigger;
PunkteTextBox.Visible = trigger;
VorEinLabel.Visible = trigger;
VorKorButton.Visible= trigger;
Logout.Visible = trigger;
LoginButton.Visible = !trigger;
UserLabel.Visible = !trigger;
UserTextBox.Visible = !trigger;
PasswortLabel.Visible = !trigger;
PasswortTextBox.Visible = !trigger;
}
Anhang: Quelltexte
79
private void FillGrids()
{
AbgegebeneHausaufgabenDataGrid.DataSource =
myService.GetAufgabenForTutor(
myService.GetLoggedInUser());
AbgegebeneHausaufgabenDataGrid.DataBind();
VorDataGrid.DataSource = myService.GetAufgabenVorkorForTutor(
myService.GetLoggedInUser());
VorDataGrid.DataBind();
}
private void LoginButton_Click(object sender, System.EventArgs e)
{
bool status = myService.Login(UserTextBox.Text,
PasswortTextBox.Text);
ShowLoggedIn(status);
FillHausaufgabenDropDown();
FillGrids();
if(status)
StatusLabel.Text = "Sie sind eingeloggt als " +
myService.GetLoggedInUser()
+ " sie sind Tutor für die Veranstaltung "
+ myService.GetVeranstaltungNameForTutor(
myService.GetLoggedInUser());
else
StatusLabel.Text = "Login gescheitert!";
}
private void Logout_Click(object sender, System.EventArgs e)
{
myService.Logout();
ShowLoggedIn(false);
Anhang: Quelltexte
StatusLabel.Text = "";
}
private void VorKorButton_Click(object sender,
System.EventArgs e)
{
if (myService.IsUserLoggedIn())
{
myService.KorrekturAbgeben(myService.GetLoggedInUser(),
Int32.Parse(HausaufgabeDropDownList.SelectedItem.Text),
URLTextBox.Text, Double.Parse(PunkteTextBox.Text));
FillGrids();
FillHausaufgabenDropDown();
}
}
}
}
wsdl.bat:
d:
cd D:\programmieren\csharp\VS\SDK\v1.1\Bin
wsdl.exe /l:c# /n:proxyTutor /out:proxyTutor.cs
http://localhost/WebServiceE-Learning/Tutor/Tutor.asmx
move proxyTutor.cs C:\Inetpub\wwwroot\WebZugriffE-Learning\bin
c:
cd C:\Inetpub\wwwroot\WebZugriffE-Learning\bin
csc.exe /target:library proxyTutor.cs
80
Glossar
81
Glossar
Client: Ein Client ist eine Komponente, die in einem Netzwerk den Dienst eines
Servers (siehe auch „Server“) in Anspruch nimmt. Man spricht dann vom Client-ServerPrinzip. Der Webbrowser ist ein Beispiel für einen Client, denn er sendet bei jedem
Aufruf einer Webseite eine Anfrage an einen Webserver und erhält dann von diesem
eine Antwort. Das Wort Client wird umgangssprachlich auch oft verwendet, um einen
Computer in einem Netzwerk zu bezeichnen. Der Client (Rechner und Programm) ist
bei einer Datenübertragung für die Kontaktaufnahme verantwortlich und bestimmt
deren Zeitpunkt. Das hat für den Client-Rechner den Vorteil, dass er erst zum
Zeitpunkt der Kontaktaufnahme eine Netzverbindung benötigt (Wikipedia, 05.01.2006).
Namensraum: (englisch name space) ist ein Begriff aus der Informatik. Ein Name
identifiziert ein Objekt. Zur eindeutigen Zuordnung ist jedoch der entsprechende
Kontext – eben der Namensraum zu beachten. Die Beschreibung geschieht
üblicherweise durch die "Punkt"-Notation. Neben der "Punkt"-Notation sind aber auch
andere Zeichen gebräuchlich, z. B.: bei Dateinamen "\" oder "/". Einige Namensräume
(z.B. Dateisysteme) sind hierarchisch aufgebaut; d.h. Namensräume können selbst
wieder aus Namensräumen bestehen. Namensräume werden dazu verwendet,
Konflikte bei der Namensvergabe zu verhindern. Graphisch sind Namensräume mit
Bäumen äquivalent; d.h. Namensräume haben eine Wurzel (einen festen, definierten
Ausgangspunkt),
Knoten
(Verzeichnisse)
und
Blätter
(Objekte)
(Wikipedia,
05.01.2006).
Petri-Netz: ist ein mathematisches Modell von nebenläufigen Systemen. Die
ursprüngliche Form der Petri-Netze nennt man auch Bedingungs- oder Ereignisnetz.
Endliche Automaten und Bedingungs- oder Ereignisnetze sind gleichmächtig. PetriNetze wurden durch Carl Adam Petri in den 1960er Jahren definiert. Sie
verallgemeinern wegen der Fähigkeit, nebenläufige Ereignisse darzustellen, die
Automatentheorie (Wikipedia, 05.01.2006).
Server: Ein Server ist in der Informatik ein Dienstleister, der in einem Computersystem
Daten oder Ressourcen zur Verfügung stellt. Das Computersystem kann dabei aus
einem einzelnen Computer oder einem Netzwerk mehrerer Computer bestehen. Es
Glossar
82
wird zwischen dem Server-Programm (Computerprogramm, das einen Dienst (z.B.
Netzwerkprotokoll) implementiert) und dem Server-Computer (Computer auf dem ein
oder mehrere Server-Programme laufen, wobei die korrekte Bezeichnung für diesen
physischen Rechner „Host“ ist) unterschieden (Wikipedia, 05.01.2006).
Stored Procedure: (deutsch: Gespeicherte Prozedur, kurz: SP) ist eine Funktion
bestimmter Datenbankmanagementsysteme. In einer Stored Procedure können ganze
Abläufe von Anweisungen unter einem Namen gespeichert werden, die dann auf dem
Datenbankserver zur Verfügung stehen und ausgeführt werden können. Mit anderen
Worten: Eine SP ist ein eigenständiger Befehl, der eine Abfolge von gespeicherten
Befehlen ausführt (Wikipedia, 05.01.2006).
SQL-Injection: Bezeichnet das Ausnutzen einer Sicherheitslücke in Zusammenhang
mit SQL-Datenbanken. Diese entsteht bei mangelnder Maskierung oder Überprüfung
von Funktionszeichen. Der Angreifer versucht über die Anwendung, die den Zugriff auf
die Datenbank bereitstellt, eigene Datenbankbefehle einzuschleusen. Sein Ziel ist es
dabei, Kontrolle über die Datenbank oder den Server zu erhalten (Wikipedia,
05.01.2006).
Workflow: Ein modellierter Workflow (deutsch: Arbeitsablauf) beschreibt möglichst
genau und operativ die auszuführenden Arbeitsschritte. Das Ziel ist hierbei weniger
eine Dokumentation für die Mitarbeiter als eine mögliche (Teil-)Automatisierbarkeit der
Ausführung. Arbeitsablaufmodelle sollen dabei helfen, die optimale Einbindung
verschiedenster
Anwendungen
(Textverarbeitungen,
Tabellenkalkulationen,
Datenbanken usw.) in die jeweiligen Arbeitsabläufe sicherzustellen (Wikipedia,
05.01.2006).
Literaturverzeichnis
83
Literaturverzeichnis
[1] Cover Pages (Hrsg.), BPEL, http://xml.coverpages.org/
[2] Hauser,T., Löwer,U.,M.: Web Services Die Standards, 2004, S. 12-20
[3] Hauser,T., Löwer,U.,M.: Web Services Die Standards, 2004, S. 128ff.
[4] Hauser,T., Löwer,U.,M.: Web Services Die Standards, 2004, S. 164
[5] Hauser,T., Löwer,U.,M.: Web Services Die Standards, 2004, S. 172
[6] Juric,B.,M., Mathew,B., Sarang,P.: Business Process Execution Language for Web
Services – An architect and developer´s guide to orchestrating web services using
BPEL4WS, 2004, S. 51ff.
[7] Masud,S.: BPEL4WS and RosettaNet, 2003,
http://www.128.ibm.com/developerworks/webservices/library/ws-rose1/
[8] Matthäß,K.: Kontrollierter automatischer Datenaustausch zwischen befreundeten
Content Management Systemen, HS Karlsruhe, Fak. WI, 2005
[9] Mevius,v.,M.: Modellierung von dokumentenbasierten Geschäftsprozessen mit
XML-Netzen, http://lwi2.wiwi.uni-frankfurt.de/projekte/xmlnet/BTW01_mevius.pdf
[10] Payette,S., Lagoze,C.: Value-Added Surrogates for Distributed Content, D-Lib
Magazine, Volume 6 Number 6, June 2000, ISSN 1082-9873
[11] phpCMS (Hrsg.), CMS,
http://docs.phpcms.de/index.php/The_definition_of_Content_Management_Systems
Literaturverzeichnis
[12] Schulmeister,R.: Lernplattformen für das virtuelle Lernen, 2003, S. 10
[13] Schuster,E., Wilhelm,S.: Content Management, Gesellschaft für Informatik (GI),
08/2005, http://www.gi-ev.de/service/informatiklexikon/informatiklexikondetailansicht/meldung/28/druckversion.html
[14] Universität Hildesheim (Hrsg.), Definition E-Learning, 2003,
http://www.uni-hildesheim.de/de/9808.htm
[15] Wikipedia (Hrsg.), E-Learning, http://de.wikipedia.org/wiki/E-Learning
[16] Wikipedia (Hrsg.), BPEL, http://de.wikipedia.org/wiki/BPEL
84
Stichwortverzeichnis
85
Stichwortverzeichnis
ACID............................................ 13f., 17
Petri-Netz...................................... 61, 81
Aktivitätsdiagramm............ 24, 26, 32, 34
Portal....... 3, 22f., 27ff., 31, 36ff., 45f., 48
Architektur............................... 20, 41, 43
Prozess................... 1, 7f., 10, 14ff., 58ff.
ASP......................... VII, 20f., 41, 44, 50f.
Sequenzdiagramm..................... 28, 37ff.
BPEL........2, VII, 15ff., 21, 57f., 60f., 83f.
Server. VII, 19f., 24, 28ff., 37ff., 43ff., 49,
51, 57, 64, 81f.
CAE.................................................VII, 9
Client 28f., 37, 39ff., 43f., 49f., 54, 59, 81
Client .................................................. 29
CMS............................ 1ff., 10f., 17ff., 83
Code-Behind........................... 41, 44, 50
Content Management Systeme...1ff., 11,
17, 67, 83
DataSet....................................... 51, 54f.
Datenbank. 14, 21, 24, 28, 40ff., 45f., 48,
51, 53ff., 82
DBHandler..........40ff., 44ff., 48, 52, 54ff.
DISCO...........................................VII, 12
Dozent.... 17, 22f., 26, 28, 30f., 34f., 37f.,
40, 44ff.
DozentWeb.....2, 19, 22f., 27ff., 31, 36ff.,
40, 45f.
Session..............................................54f.
Sicherheit...................................... 63, 66
SOAP................................ VII, 12, 15, 50
Stellvertreterklasse............................ 49f.
Student.. 22ff., 27, 31f., 36f., 40, 44, 46f.,
51, 54
TutorClient....2, 19, 22f., 27, 29, 31, 36f.,
39f., 48
UDDI............................................ VIII, 13
UML........................................... VIII, 20f.
Use-Case................................ 26ff., 35ff.
Verwaltung von E-Learning Objekten.22,
30, 32, 34ff., 39f., 43ff., 48
W3C..................................... VIII, 12f., 15
Web Methode............................. 51, 53ff.
E-Learning1f., 7ff., 22, 30, 32, 34ff., 39f.,
43ff., 48, 51, 84
Web Service.VIII, 11f., 14ff., 29, 38f., 42,
44ff., 48ff., 54, 58f., 63f., 66
Klassendiagramm.................42, 44ff., 48
Web Services.......2, VIIf., 11ff., 17, 20ff.,
28ff., 37, 39ff., 45, 50ff., 55, 57, 83
Komponentendiagramm...................... 41
Mambo........................................ 18f., 67
Management..... 1ff., 10f., 15, 17, 21, 57,
59f., 66f., 83f.
Methode...................... 42, 45ff., 50ff., 60
Microsoft............................ 15, 20, 49, 57
Modell...................................... 23, 31, 81
Modellbeschreibung...................... 23, 31
OASIS..................................... VII, 13, 15
Open Source......................... 18, 61f., 67
Webseite....... 3, 9, 17, 21, 28f., 39ff., 44,
50ff.
Workflow............................1f., 15, 57, 82
Workflow-Management................. 1f., 57
XML......2, VIIf., 12, 15, 50, 53f., 57, 61f.,
65f., 83
XML-Netze.............................. 2, 57, 61f.
Zeiterfassung22ff., 26ff., 41ff., 48, 50, 52
.NET...................................... 21, 49, 51f.