Konzeption und Implementierung eines Prototyps eines interaktiven Lernsytems für die UNIX-Shell
©2001
Diplomarbeit
174 Seiten
Zusammenfassung
Inhaltsangabe:Einleitung:
In allen Branchen ist eine wachsende Bedeutung von Telelearning bzw. eLearning in der betrieblichen Aus-, Fort- und Weiterbildung zu beobachten. Mit dem Internet entwickelt sich Telelernen als Lernform der Zukunft.
Zu jeder Zeit halten Computer Lernhilfen, Lernprogramme und Informationen bereit. Telelearning und Präsenzunterricht werden sorgfältig aufeinander abgestimmt und ergänzen sich. Die Rolle der Lehrer und Dozenten wandelt sich: Wissensvermittler im Frontalunterricht werden zu Online-Lernbegleitern und -Beratern im Einzel- und Gruppengespräch.
Computer-Based Training (CBT) steht für Lernen mit Selbstlernprogrammen zum Beispiel von CD-ROM. Unter Web-Based Training (WBT) wird das Lernen mit Online-Lernprogrammen verstanden.
Im Einsatz von eLearning wird darüber hinaus die Chance gesehen, offenes Lernen zu fördern. Da Lernen heute aktiver und selbstregulierender wird, tritt Lehren gegenüber Lernen zunehmend in den Hintergrund. Von den Schulen wird gefordert, dass sie sich verstärkt gegenüber der Umwelt öffnen. Beispielsweise könnten sie ihren Schülern via Internet den direkten Kontakt zu Schülern anderer Länder ermöglichen.
In Unternehmen kann offenes Lernen bedeuten, dass sich die Arbeitnehmer jederzeit am Arbeitsplatz oder in sogenannten Lernstudios mit Hilfe von Lernprogrammen fortbilden können.
Auch die deutschen Hochschulen haben die Zeichen der Zeit erkannt und die Möglichkeiten des offenen Lernens für sich entdeckt. Überall wird derzeit an der Erweiterung der klassischen Lehre um multimediale Techniken gearbeitet, es entstehen zahlreiche Teleteaching-Projekte, multimedial aufbereitete Lehr-/Lernsoftware wird entwickelt.
So soll auch diese Diplomarbeit zum weiteren Einsatz der modernen Technologien beitragen und den Studenten des Fachbereichs Informatik an der Fachhochschule Mannheim beim Lernen helfen.
Bei der Implementierung dieser Diplomarbeit wurde die moderne Technologie des Publishing Framework Cocoon eingesetzt. Cocoon ist vollständig in Java implementiert und XML basiert. Außerdem unterstützt Cocoon die Trennung von Inhalt, Logik und Layout, was eine neue Art von Management der Webanwendungen ermöglicht.
Die lauffähige Version eines Unix-Kurses wird momentan in der Fachhochschule für Technik und Gestaltung Mannheim im Fachbereich Informatik eingesetzt. Die Quellcodes sind beigefügt.
Teil I Einführung: Der erste Teil der Diplomarbeit gliedert sich in zwei Kapitel. Im ersten Kapitel wird die […]
In allen Branchen ist eine wachsende Bedeutung von Telelearning bzw. eLearning in der betrieblichen Aus-, Fort- und Weiterbildung zu beobachten. Mit dem Internet entwickelt sich Telelernen als Lernform der Zukunft.
Zu jeder Zeit halten Computer Lernhilfen, Lernprogramme und Informationen bereit. Telelearning und Präsenzunterricht werden sorgfältig aufeinander abgestimmt und ergänzen sich. Die Rolle der Lehrer und Dozenten wandelt sich: Wissensvermittler im Frontalunterricht werden zu Online-Lernbegleitern und -Beratern im Einzel- und Gruppengespräch.
Computer-Based Training (CBT) steht für Lernen mit Selbstlernprogrammen zum Beispiel von CD-ROM. Unter Web-Based Training (WBT) wird das Lernen mit Online-Lernprogrammen verstanden.
Im Einsatz von eLearning wird darüber hinaus die Chance gesehen, offenes Lernen zu fördern. Da Lernen heute aktiver und selbstregulierender wird, tritt Lehren gegenüber Lernen zunehmend in den Hintergrund. Von den Schulen wird gefordert, dass sie sich verstärkt gegenüber der Umwelt öffnen. Beispielsweise könnten sie ihren Schülern via Internet den direkten Kontakt zu Schülern anderer Länder ermöglichen.
In Unternehmen kann offenes Lernen bedeuten, dass sich die Arbeitnehmer jederzeit am Arbeitsplatz oder in sogenannten Lernstudios mit Hilfe von Lernprogrammen fortbilden können.
Auch die deutschen Hochschulen haben die Zeichen der Zeit erkannt und die Möglichkeiten des offenen Lernens für sich entdeckt. Überall wird derzeit an der Erweiterung der klassischen Lehre um multimediale Techniken gearbeitet, es entstehen zahlreiche Teleteaching-Projekte, multimedial aufbereitete Lehr-/Lernsoftware wird entwickelt.
So soll auch diese Diplomarbeit zum weiteren Einsatz der modernen Technologien beitragen und den Studenten des Fachbereichs Informatik an der Fachhochschule Mannheim beim Lernen helfen.
Bei der Implementierung dieser Diplomarbeit wurde die moderne Technologie des Publishing Framework Cocoon eingesetzt. Cocoon ist vollständig in Java implementiert und XML basiert. Außerdem unterstützt Cocoon die Trennung von Inhalt, Logik und Layout, was eine neue Art von Management der Webanwendungen ermöglicht.
Die lauffähige Version eines Unix-Kurses wird momentan in der Fachhochschule für Technik und Gestaltung Mannheim im Fachbereich Informatik eingesetzt. Die Quellcodes sind beigefügt.
Teil I Einführung: Der erste Teil der Diplomarbeit gliedert sich in zwei Kapitel. Im ersten Kapitel wird die […]
Leseprobe
Inhaltsverzeichnis
ID 5288
Hawlisch, Evgenia: Konzeption und Implementierung eines Prototyps eines interaktiven
Lernsytems für die UNIX-Shell: (Die Arbeit ist nur als CD erhältlich) / Evgenia Hawlisch -
Hamburg: Diplomica GmbH, 2002
Zugl.: Mannheim, Fachhochschule, Diplom, 2001
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die
der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen,
der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der
Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung,
vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im
Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der
Bundesrepublik Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem
Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche
Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten
wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können Fehler nicht
vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die Autoren oder
Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für evtl.
verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2002
Printed in Germany
Inhaltsverzeichnis
Erklärung ...i
Vorwort ...ii
I. Einführung ...iv
1. Aufgabenstellung ... 1
2. Grundlagen... 2
2.1. Internet ... 2
2.1.1. Die Geschichte des Internets... 2
2.1.2. Internet und seine Basis-Dienste... 2
2.2. Auszeichnungssprachen (Markup Language)... 4
2.2.1. SGML ... 5
2.2.2. SGML-DTD... 6
2.2.3. DocBook ... 8
2.2.4. HTML (Hypertext Markup Language) ... 9
2.2.5. XML... 10
2.2.6. Hierarchie der Auszeichnungssprachen... 11
2.3. XML... 11
2.3.1. XML-Dokumente... 12
2.3.2. XML-Parser ... 16
2.3.2.1. DOM ... 17
2.3.2.2. SAX... 18
2.3.3. XSL - Stylesheets in XML... 19
2.4. UNIX und LINUX ... 20
2.4.1. Die UNIX-Shell ... 21
2.4.2. Entfernter Shell-Zugriff ... 21
2.4.2.1. Telnet... 21
2.4.2.2. SSH (Secure Shell) ... 22
2.5. Client-Server Architekturen... 23
2.5.1. 2-Schichten-Architektur... 23
2.5.2. 3-Schichten-Architektur... 24
2.6. Client-Server Kommunikation ... 25
2.6.1. Middleware ... 25
2.6.1.1. Sockets ... 25
2.6.1.2. RMI ... 26
2.6.1.3. CORBA ... 27
2.6.1.4. SOAP ... 28
2.6.2. Web-Anwendungen... 28
2.6.2.1. CGI... 28
2.6.2.2. Skriptsprachen... 29
2.6.2.3. Servlets... 30
2.6.2.4. XML-basierte Web-Entwicklung mit Cocoon ... 30
2.6.2.5. Applets ... 33
2.7. Die Programmiersprache JAVA... 34
2.8. Lehr- und Lernsysteme ... 34
iii
II. Analyse der Problemstellung ... 35
3. Das Lernsystem... 36
3.1. Varianten von Lernsystemen... 36
3.2. Anforderungen an das Lernsystem ... 37
3.2.1. Lernförderlichkeit ... 37
3.2.2. Einbettung in eine integrierte Lernumgebung ... 38
3.2.3. Wiederverwendbarkeit ... 38
3.2.4. Ergonomische Benutzerschnittstelle ... 39
3.2.5. Bereitstellung einer Benutzerumgebung... 39
3.3. Strukturierung der Kurse und Aufgaben... 40
3.3.1. Gestaltung von Fragen ... 40
3.3.2. Fragetypen... 40
3.3.2.1. Geschlossene Fragen... 41
3.3.2.2. Offene Fragen ... 43
3.3.2.3. Zusammenfassung... 45
4. Interaktive Übungs-Shell ... 46
4.1. Benötigte Kommandos... 46
4.1.1. Manual pages ... 46
4.1.2. Hilfesystem ... 47
4.1.3. Arbeiten mit Dateien... 47
4.1.4. Prozessverwaltung ... 50
4.1.5. Die Editoren unter UNIX... 50
4.1.5.1. Der Editor vi ... 50
4.1.5.2. Der Editor emacs ... 51
4.1.6. Weitere Befehle... 52
4.1.7. Zusammenfassung... 52
III. Konzeptionierung und Entwurf ... 54
5. Vorgehensweise beim Systementwurf ... 55
5.1. Phasenmodelle für Software-Entwicklung ... 55
6. Systementwurf des Lernsystems für die UNIX-Shell... 57
6.1. Benutzerschnittstelle ... 57
6.1.1. Web-basiert ... 57
6.1.2. Applikationen... 58
6.1.3. Web-basiert vs. Applikation... 58
6.2. Aufteilung in Unterrichts- und Übungsteil ... 58
7. Konzeptionierung des Unterrichtsteiles ... 60
7.1. Architektur des Unterrichtsteiles ... 60
7.2. Datenhaltung ... 61
7.2.1. Textdateien ... 61
7.2.2. XML-Dateien... 61
7.2.2.1. Zugriff auf die XML-Dateien ... 62
7.2.2.2. DOM und SAX ... 63
7.2.2.3. XSL ... 64
7.2.3. Datenbank ... 66
7.3. Schlussüberlegungen... 67
8. Konzeptionierung des Übungsteils ... 68
8.1. Emulation der Kommandos ... 68
8.2. Zugriff auf einen bestehenden LINUX-Server ... 68
8.2.1. Sicherheit ... 68
8.2.1.1. Zugriffskontrolle mit chroot... 68
iv
8.2.1.2. Ressourcenbeschränkung... 70
8.2.1.3. Weitere Sicherheitsaspekte ... 70
8.2.2. Applet als Implementierungswerkzeug... 71
8.2.2.1. JavaTM Telnet Application/Applet... 71
8.2.2.2. Signieren von Applets... 72
9. Beispielentwurf mittels Servlet und CORBA ... 74
10. Beispielentwurf mittels Cocoon... 77
10.1. Kursaufbau ... 77
10.2. Datenmodell... 80
10.3. Datenbankzugriff ... 82
10.4. Seitenlayout... 83
IV. Implementierung ... 85
11. Geführter UNIX-Kurs mit dem Applikationsserver Cocoon ... 86
11.1. Erhalten von Sessions ... 86
11.2. Datenbank für Benutzer- und Kursinformationen ... 87
11.3. Pipeline-Struktur in der Sitemap... 89
11.3.1. Erste Ebene ... 93
11.3.2. Zweite Ebene ... 96
11.3.3. Dritte Ebene ... 98
12. Telnet/SSH Zugang ... 103
12.1. Serverseitig ... 103
12.2. Clientseitig ... 103
13. Installation... 104
13.1. Systemvoraussetzungen ... 104
13.1.1. Apache Cocoon 2.0... 104
13.1.2. JavaTM Telnet Applet... 104
13.2. Installation von
Apache Cocoon 2.0
... 104
13.2.1. Installation auf Tomcat 3.X... 105
13.2.2. Installation auf Tomcat 4.X... 106
13.3. Installation von JavaTM Telnet Applet ... 106
13.4. Datenbankinstallation ... 110
14. Resümee und Ausblick ... 111
Glossar und Abkürzungsverzeichnis... 112
Literaturverzeichnis ... 117
Index... 121
A. Quellcode... 124
v
Tabellenverzeichnis
7-1. Vergleich von DOM und SAX... 63
Abbildungsverzeichnis
2-1. Hierarchie der Auszeichnungssprachen... 11
2-2. Objekthierarchie im logischen DOM Strukturmodell ... 17
2-3. Das SAX Modell ... 18
2-4. Mechanismus von XSL ... 19
2-5. Telnet-Sitzung unter Unix ... 22
2-6. Zwei-Ebenen Architektur. ... 23
2-7. Drei-Ebenen Architektur... 24
2-8. Ablauf eines Java-RMI Funktionsaufrufes ... 26
2-9. Allgemeiner Aufbau eines CORBA-ORBs ... 27
2-10. XSLT Prozessor ... 32
4-1. Shell Interpreter-Schleife... 46
9-1. Entwurfsmodell mittels Servlet und CORBA... 74
9-2. Interface Definition Language ... 75
9-3. Bausteine einer DOM-Anwendung ... 75
10-1. Grundstruktur des Unix-Shell-Kurses ... 77
10-2. Sitemap im Cocoon2 ... 79
10-3. Aufbau des Unix-Shell-Kurses ... 79
10-4. Die Entity im ER-Modell ... 80
10-5. Beziehungen im ER-Modell ... 81
10-6. Das Entity-Relationship Modell ... 82
10-7. Seitenlayout im Unix-Shell-Kurs ... 83
11-1. Datenbankmodell im Unix-Shell-Kurs ... 88
11-2. Ablauf der Pipeline-Verarbeitung... 90
11-3. Drei Pipeline-Ebenen im Unix-Shell-Kurs... 92
11-4. Zusammenfügen von zwei Dateien in XSL... 101
Beispiele
2-1. Ein einfaches DocBook-Dokument ... 9
2-2. Ein einfaches HTML-Dokument ... 10
2-3. Ein einfaches XML-Dokument ... 12
2-4. Ein XML-Dokument mit externer DTD:... 13
2-5. Ein XML-Dokument mit interner DTD: ... 13
2-6. Entities-Sammlung ... 14
2-7. Ein wohlgeformtes XML-Dokument: ... 16
2-8. Ein gültiges XML-Dokument (mit einer internen DTD)... 16
vi
Vorwort
Die Welt des Lernens verändert sich. In allen Branchen ist eine wachsende Be-
deutung von Telelearning bzw. eLearning in der betrieblichen Aus-, Fort- und Weit-
erbildung zu beobachten. Mit dem Internet entwickelt sich Telelernen als Lernform
der Zukunft. Lernen über das Internet bietet gegenüber traditionellen Methoden ein-
deutige Vorteile:
·
Ortsunabhängigkeit,
·
überwiegend freie Zeiteinteilung,
·
mittelfristig Kosteneinsparung durch reduzierte Reise- und Arbeitsausfallzeiten
(besonders wichtig für die Unternehmen) und
·
lebendige Kommunikation zwischen Lernenden im Netz.
Zur Zeit befinden sich TeleLearning-Plattformen als Lernumgebungen in der Er-
probung. Erste Auswertungen in den konzernweiten Intranets der Deutschen Bank,
von Allianz und Siemens, aber auch in Kammern und Verbänden und an süddeutschen
Universitäten liegen bereits vor.
In den Grundzügen ähneln sich die Lernszenarien:
Zu jeder Zeit halten Computer Lernhilfen, Lernprogramme und Informationen bereit.
Telelearning und Präsenzunterricht werden sorgfältig aufeinander abgestimmt und
ergänzen sich. Die Rolle der Lehrer und Dozenten wandelt sich: Wissensvermittler
im Frontalunterricht werden zu Online-Lernbegleitern und -Beratern im Einzel- und
Gruppengespräch. Computer- Based Training (CBT) steht für Lernen mit Selbstlern-
programmen von CD-ROM. Unter Webbased Training (WBT) wird das Lernen mit
Online-Lernprogrammen verstanden. Wo Lernen ohne menschlichen Kontakt in der
Vergangenheit häufiger zu Motivationsproblemen führte, setzt das netzbasierte Ler-
nen, sog. Web-Based Training (WBT) an: hier liegt der Akzent auf kommunikativen
Formen von Lernen: verteiltes Lernen an entfernten Orten, im Kontakt mit Kollegen
als Lernpartnern, moderiert durch einen Tele-Tutor per Mail, Chat und Videokonfe-
renz.
Im Einsatz von eLearning wird darüber hinaus die Chance gesehen, offenes Lernen
zu fördern. Offenes Lernen besitzt auf der einen Seite eine pädagogisch- didaktische
Komponente. Da Lernen heute aktiver und selbstregulierender wird, tritt Lehren ge-
genüber Lernen zunehmend in den Hintergrund. Von den Schulen wird gefordert,
dass sie sich verstärkt gegenüber der Umwelt öffnen. Beispielsweise könnten sie
ihren Schülern via Internet den direkten Kontakt zu Schülern anderer Länder ermög-
lichen. In Unternehmen kann offenes Lernen bedeuten, dass sich die Arbeitnehmer
jederzeit am Arbeitsplatz oder in sogenannten Lernstudios mit Hilfe von Lernpro-
grammen fortbilden können.
Auch die deutschen Hochschulen haben die Zeichen der Zeit erkannt und die Mög-
lichkeiten des offenen Lernens für sich entdeckt. Überall wird derzeit an der Erwei-
terung der klassischen Lehre um multimediale Techniken gearbeitet, es entstehen
zahlreiche Teleteaching-Projekte, multimedial aufbereitete Lehr-/Lernsoftware wird
entwickelt.
ii
Vorwort
So soll auch diese Diplomarbeit zum weiteren Einsatz der modernen Technologien
beitragen und den Studenten des Fachbereichs Informatik an der Fachhochschule
Mannheim beim Lernen helfen.
Ich danke vor allem Herrn Prof. Bengel für die Vergabe des Themas und seiner stän-
digen Bereitschaft zur Diskussion und Hilfe während der Durchführung der Diplom-
arbeit, sowie Herrn Lukwata für seine Beratung.
Mein besonderer Dank gilt meinem Mann Martin Hawlisch für die Unterstützung
und Geduld in dieser stressigen Zeit. Des weiteren möchte ich mich bei allen be-
danken, die mir bei der Korrektur und dem Layout des Manuskriptes geholfen ha-
ben. Ohne die moralische Unterstützung durch meine Eltern wäre diese Arbeit nicht
möglich gewesen.
Überblick über die folgenden Kapitel. Die Arbeit teilt sich in vier Abschnitte
auf. Teil I Einführung liefert eine Einführung in die Thematik, indem zunächst die
Notwendigkeit eines interaktiven Lernsystems dargestellt wird und die technischen
Grundlagen der am häufigsten dafür eingesetzten Technologien zusammengefasst
werden.
Im Teil II Analyse der Problemstellung wird das Lernsystem allgemein betrachtet
und die Anforderungen an ein solches untersucht. Dann werden erste Überlegun-
gen zu der Strukturierung eines Lernsystems gemacht. Der in dieser Diplomarbeit
zu entwickelnde Kurs soll die Shell-Kommandos erklären, daher wird hier das Prin-
zip und Funktionsweise einer Shell erklärt und die wichtigsten Shell-Kommandos
aufgeführt.
Teil III Konzeptionierung und Entwurf befasst sich mit der Konzeptionierung eines
interaktiven Lernsystems. Zunächst wird die Vorgehensweise beim Entwurf aus der
Sicht des Software Engeneering betrachtet. Dann wird das Lernsystem logisch in
den Unterrichts- und Übungsbereiche aufgeteilt und diese Bereiche im einzelnen be-
trachtet. Anschließend werden zwei Beispiel-Entwürfe vorgestellt. Zum ersten mit-
tels Servlets und CORBA, wo nur das Grundgerüst aufgebaut wurde. Und zum zwei-
ten mittels XML Publishing Framework Cocoon, was letztendlich im Rahmen dieser
Diplomarbeit implementiert wurde.
Im Teil IV Implementierung wird dann auf die Implementierung des Unix-Shell-
Kurses für Anfänger eingegangen. Es wird dabei Schritt für Schritt die Vorgehens-
weise bei der Implementierung mit Hilfe des Framework Cocoon beschrieben. Zum
Schluss des Abschnitts wird die Installation von Bestandteilen, wie Apache Cocoon
2.0 mit Tomcat Servlet Engine und JavaTM Telnet Application/Applet und dessen
Konfiguration ausführlich erklärt.
iii
I. Einführung
Inhaltsverzeichnis
1. Aufgabenstellung... 1
2. Grundlagen... 2
Der erste Teil der Diplomarbeit gliedert sich in zwei Kapitel. Im ersten Kapitel wird
die Aufgabenstellung beschrieben mit dem Ausblick auf vorausgegangene Diplom-
arbeiten.
Im zweiten Kapitel, genannt Grundlagen, werden die wichtigsten Technologien be-
schrieben, die bei der Entwicklung eines interaktiven Lernsystems in Frage kommen.
Es wird ein kurzer Exkurs in die Geschichte des Internets gemacht. Dann werden die
Auszeichnungssprachen, insbesondere XML, beschrieben.
Es soll im Rahmen dieser Diplomarbeit ein Lernsystem für die Unix-Shell ent-
wickelt werden, also, wird auch kurz auf die Unix-Shell eingegangen. Entfernter
Shell-Zugriff wird auch beschrieben, weil er bei der Implementierung eventuell zum
Einsatz kommen kann. Um eine mögliche Struktur für das Lernsystem festzulegen
und implementieren zu können, sind die Grundkenntnisse über Client-Server Archi-
tekturen und Client-Server Kommunikation erforderlich. Schließlich wird es noch
auf die Programmiersprache Java und allgemeine Beschreibung von Lehr- und Lern-
systemen eingegangen.
Kapitel 1. Aufgabenstellung
Die vorliegende Diplomarbeit ist als Nachfolgearbeit im Projekt ILEX, Interaktives
LErnsystem für UniX, im Institut für Betriebssysteme der Fachhochschule Mann-
heim entstanden. Da
ilex®
eine eingetragene Marke von Silvan Kindt in Freiburg
ist, werde ich diese Bezeichnung nicht weiter verwenden. Es wurden die Diplomar-
beiten von Herrn Rebelein und Herrn Wiegmann vorausgesetzt. Herr Rebelein hat
sich hauptsächlich mit der Client-Seite und der Benutzeroberfläche auseinanderge-
setzt, der Herr Wiegmann hat sich mit der Server-Seite und den didaktischen Grund-
lagen eines Lernsystems beschäftigt.
Am Anfang war das Ziel dieser Diplomarbeit, die vom Herr Wiegmann erstellte
Datenbank mit Lerninhalten zu füllen und die Technologie des Lernservers auf den
neuesten Stand bringen (von JDK (
Java Development Kit
) 1.1.x auf JDK 1.3).
Die vorausgegangenen Diplomarbeiten liegen aber schon ein paar Jahre zurück, die
vom Herr Wiegmann wurde im Wintersemester 1997/98 abgeschlossen. Die Version
1.1.x von JDK kann man inzwischen als veraltet einstufen. Dadurch wurde es nötig,
die Aufgabenstellung abzuändern und neu zu formulieren.
Es soll nicht nur eine Konzeption von dem Lernsystem erarbeitet werden, sondern
eine lauffähige Version in Form vom UNIX-Kurs für Anfänger umgesetzt werden.
Dieser Kurs soll den Studenten beim Lernen des Faches BTS (Betriebssysteme) im
Fachbereich Informatik bei der Einführung in die Unix-Shell helfen.
1
Kapitel 2. Grundlagen
Jeder Lernsystemautor, der ein interaktives Lernsystem entwickelt, soll sich am An-
fang mit den Grundlagen auseinandersetzen. Die einwandfreie technische Ausfüh-
rung allein ist in diesem Fall nicht ausreichend. Man soll dabei auch die didaktischen
Kenntnisse über die Lernsysteme nicht außer Acht lassen.
In diesem Kapitel möchte kurz auf alle für diese Diplomarbeit wichtige Themen
eingehen.
2.1. Internet
Das Internet ist das umfangreichste Computer-Netzwerk der Welt. Es verbindet meh-
rere Millionen Computer (einschließlich PCs) und mehrere zehn Millionen Men-
schen. Der Name kommt von ,,Interconnected Networks" (verbundene Netze); das
Internet ist ein Zusammenschluss von vielen lokalen, nationalen und internationa-
len Computer-Netzen, die alle das Protokoll TCP/IP (Transmission Control Proto-
col/Internet Protocol) verwenden und die jeweils lokal, nicht über eine Welt-Zentrale,
verwaltet werden (,,Domains").
2.1.1. Die Geschichte des Internets
Im Jahre 1969 entwickelte die dem amerikanischen Verteidigungsministerium unter-
stellte Behörde DARPA (Defense Advanced Research Project Agency) zusammen
mit einigen amerikanischen Universitäten ein dezentrales Computernetzwerk mit
dem Namen ARPANET. Der ursprüngliche Zweck dieses Vorhabens war die Schaf-
fung eines möglichst ausfallsicheren Datennetzes für den militärischen Bereich. Aus
diesem Grunde wurde ARPANET, das einige Jahre später in DARPA-Internet um-
benannt wurde, von Anfang an dezentral und fehlertolerant aufgebaut. Nachdem das
DARPA-Internet in den USA ein rasches Wachstum, vor allem im universitären Be-
reich, erreicht hatte, zog sich die DARPA 1985 hauptsächlich wegen Sicherheits-
bedenken als Sponsor und Mitbetreiber zurück. Die Entwicklung des Internet hatte
aber zu diesem Zeitpunkt bereits eine so hohe Eigendynamik erreicht, so dass sich
das Netz trotz des Rückzugs der DARPA rasant weiterentwickelte.
1991 wurde in den USA die Kommerzialisierung des Internet durch die Schaffung
des sogenannten CIX (Commercial Internet Exchange), einer Verbindung zwischen
dem kommerziellen und dem akademischen Teil des Internet, eingeleitet. Der CIX
ermöglichte die kommerzielle Nutzung des Internet auch für Unternehmen, die nicht
an universitären Forschungsprojekten beteiligt waren. Mit der Entwicklung des World
Wide Web und dem Einsatz der zugehörigen Client-Software Mosaic im Jahre 1993
wurden dann die vielfältigen Anwendungsbereiche des Internet endgültig von Unter-
nehmen aller Sparten entdeckt. Heute gilt das Internet als das größte Computernetz
der Welt, sowohl im wissenschaftlichen als auch im kommerziellen Bereich.
2.1.2. Internet und seine Basis-Dienste
Das Internet hat zahlreiche sog. Dienste. Der am häufigsten benutzte ist E-Mail
(Electronic Mail). Weitere, oft genutzte Dienste sind das WWW (World Wide Web),
FTP (File Transfer Protocol) und IRC (Internet Relay Chat).
2
Kapitel 2. Grundlagen
Telnet
Mit Hilfe von Telnet, realisiert durch ein bestimmtes Softwarepaket, ist es möglich,
eine direkte Verbindung von dem PC am Schreibtisch zu einem Zielrechner herzu-
stellen, wobei sich der Arbeitsplatzrechner wie ein Terminal verhält. Über die eigene
Tastatur können Befehle an den Host eingegeben werden, die Ergebnisse sind dann
am eigenen Bildschirm zu sehen. Man gebraucht tatsächlich aber nicht die eigene
Rechenleistung, sondern benützt externe Ressourcen. So kann man z.B. statistische
Analysen am Großrechner direkt vom Computer an seinem Schreibtisch aus durch-
führen, man kann an Bibliotheken, die über elektronische Verwaltung verfügen, An-
fragen stellen etc. Voraussetzung dazu ist zum einen, dass auf beiden Rechnern ein
entsprechendes Programm läuft - Telnet. Zum anderen, dass der Benutzer eine Zu-
gangskennung, oder den Schlüssel, besitzt.
FTP
Zur Übertragung größerer Datenbestände auf den eigenen Rechner, seien es Pro-
gramme, Texte digitalisierte Bilder, Musik oder sogar Videos, gibt es im Internet die
Dienstleistung FTP. Hiermit ist ebenfalls, wie bei Telnet, ein Einloggen auf anderen
Rechner des Netzes möglich, wiederum mit den gleichen Voraussetzungen wie bei
Telnet, d.h auf dem Zielrechner muss ein entsprechendes Programm laufen, und es
muss eine Zugangskennung bestehen.
Electronic Mail
elektronische Briefpost:
·
Dient dem Versand elektronischer Nachrichten, die meist innerhalb von weni-
gen Sekunden den Empfänger erreichen.
·
Es können nicht nur Texte, sondern auch alle in digitaler Form vorliegende
Informationen übertragen werden: Bilder, Musik, Programme, Textdokumente.
·
Adressierung lehnt sich an DNS (Domain Name System) an.
·
Zahlreiche Gateways, die den Kreis der Sender und Empfänger über den Kreis
der Internetteilnehmer um Teilnehmer anderer Netzwerke wie AOL, T-Online,
CompuServe und auch Fax und Mobiltelefone erweitern.
IRC
Man kann mit IRC plaudern (engl.
chatten
) mit einzelnen Personen oder Gruppen
über Tastatur. Außerdem:
·
Beruht auf dem Client-Server-Prinzip: Es gibt mehrere IRC-Server, die unter-
einander verschiedene Netzwerke bilden und die Beiträge der einzelnen Teil-
nehmer austauschen.
·
Kommunikation zwischen den IRC-Servern erfolgt über das IRC-Protokoll, das
auf TCP/IP aufsetzt.
·
Teilnehmer bleiben anonym und geben sich ein Pseudonym (,,Nickname").
·
Dateiübertragung direkt zwischen Teilnehmern möglich (DCC - Direct Client
to Client).
3
Kapitel 2. Grundlagen
·
Das beliebteste Client-Programm, mit dessen Hilfe man mit einem IRC-Server
in Kontakt tritt, heißt
mIRC
und ist frei erhältlich.
WWW
Das WWW wurde am CERN in Genf (große Europäische Forschungseinrichtung
für Teilchenphysik) entwickelt. Die Grundlage des WWW bildet die Seitenbeschrei-
bungssprache HTML (Hypertext Markup Language), über die festgelegt wird, wie
und wo die Textelemente auf dem Browser erscheinen. Erst als es möglich war, auch
Graphikelemente und Bilder zu übertragen, wurde das WWW außerhalb der Wis-
senschaft bekannt und populär. Die wichtigsten Merkmale vom WWW kann man
folgendermaßen zusammenfassen:
·
Das WWW ist ein relativ junger Dienst (Mai 1991).
·
Große, verteilte und untereinander durch Hyperlinks verbundene Sammlung
von Einzeldokumenten (oder -objekten).
·
Basiert auf Client-Server-Prinzip.
·
Übertragung von Dokumenten über das Hypertext Transfer Protocol (HTTP),
das die Übertragung von Dokumenten zwischen Server und Client regelt und
auf TCP/IP aufsetzt.
·
Zur Beschreibung der Dokumente wird eine einheitliche Beschreibungssprache
verwendet: HTML.
·
Integration von Bild-, Ton- und Videodokumenten: Multimedia.
·
Adressierungsschema für verschiedenartige Dokumente an verschiedenen Or-
ten: Uniform Resource Locator (URL) ermöglicht die Lokalisierung eines Do-
kuments im Web und gibt das für den Zugriff nötige Übertragungsprotokoll an.
2.2. Auszeichnungssprachen (Markup Language)
Auszeichnungssprachen dienen dazu, einem elektronischen Textdokument neben den
Textdaten, die den Inhalt darstellen, zusätzliche Informationen hinzuzufügen. Geht
man der Frage nach, woraus Textdokumente bestehen, so lassen sich hauptsächlich
drei Komponenten identifizieren:
·
Textdaten. Die Textdaten enthalten den eigentlichen Inhalt des Dokumentes.
Damit ist hauptsächlich der reine Text, aber auch Bilder und Tabellen, gemeint.
·
Struktur. Jeder Text besitzt eine Struktur. Darunter versteht man die Gliede-
rung des Dokumentes in Abschnitte, aber auch z.B. Verweise auf Fußzeilen.
Diese strukturellen Elemente des Textes werden im folgenden als Textelemente
bezeichnet.
·
Formatierung. Die Formatierung eines Textes dient dazu, die Gliederung für
den Leser visuell hervorzuheben. Sie legt für jedes Textelement unter anderem
die Schriftgröße und Schriftart fest.
4
Kapitel 2. Grundlagen
Auszeichnungen (Markups)
Um Informationen über Struktur und Formatierung eines Dokumentes in die Text-
daten hinein zu codieren, werden Auszeichnungen (
Markup
) verwendet. Man unter-
scheidet Auszeichnungen nach der Art der Information, die sie beinhalten, aber zum
Teil auch danach, wie sie vom Benutzer dem Text hinzugefügt werden. Zur ersten
Art von Auszeichnungen gehört deskriptives und prozedurales Markup, während vi-
suelles Markup der zweiten Sorte zugerechnet wird.
Prozedurale Auszeichnungen, oft auch als prozedurales Markup (engl.
specific
coding
) bezeichnet, fügen dem Text Informationen über die Formatierung des Do-
kumentes hinzu. Die Struktur wird dabei nicht explizit hervorgehoben, obwohl sich
bei einigen prozeduralen Auszeichnungssprachen Informationen über die Struktur
entnehmen lassen. Prozedurale Auszeichnungen sind im Allgemeinen Steuercodes
und Makros, die direkt in die Textdaten eingefügt werden, und eine Formatierung
des nachfolgenden Textes bewirken. Ein Beispiel für eine Auszeichnungssprache,
die prozedurales Markup verwendet, ist LaTeX. Folgendes Beispiel zeigt die Aus-
zeichnung einer Überschrift mit Hilfe von LaTeX:
\section{Dies ist eine Latex-Ueberschrift}
Der
section
-Befehl bewirkt, dass bei der Kompilierung des Textes ein Makro auf-
gerufen wird, das abhängig von der Dokumentklasse die Überschrift mit einer be-
stimmten Schriftgröße und Schriftart formatiert. Das endgültige Aussehen des Do-
kumentes wird dabei vollständig durch die im Text enthaltenen Makros bestimmt.
Deskriptive Auszeichnungen, auch bekannt als generic coding, fügen dem Text In-
formationen über die Struktur des Dokumentes hinzu, sagen jedoch nichts über die
Formatierung aus. Das folgende Beispiel soll dies verdeutlichen:
<Ueberschrift> Dies ist eine Ueberschrift <\Ueberschrift>
Das Beispiel zeigt ein Textelement, das von einem Start- und einem Endtag ein-
geschlossen ist. Die Tags kennzeichnen den eingeschlossenen Text als Textelement
vom Typ
Ueberschrift
. Die Auszeichnung besagt nur, dass es sich bei der Textzei-
le um eine Überschrift handelt, jedoch nicht in welcher Schriftgröße und Schriftart
sie dargestellt werden soll.
Visuelles Markup ist häufig bei Textprogrammen mit grafischer Benutzeroberfläche
anzutreffen. Dabei wird während der Texteingabe auch das Layout des Textes vom
Benutzer festgelegt.
Metasprachen
Eine Metasprache ist eine formale Sprache zur Erzeugung (Konstruktion, Definition)
von Auszeichnungssprachen beliebigen Umfangs. Mit ihrer Hilfe lassen sich eige-
ne neue Sprachen zur Dokumentenbeschreibung erstellen. Eine Metasprache bietet
Werkzeuge und eine normierte Syntax zur Beschreibung von ,,Grammatiken".
SGML (Standard Generalized Markup Language)ist die Mutter aller Metasprachen.
Sie ermöglicht die eindeutige Trennung zwischen Struktur und Layout von Doku-
menten und damit eine zeitlose und plattformübergreifende Nutzungsmöglichkeit
von digitalen Texten.
5
Kapitel 2. Grundlagen
2.2.1. SGML
SGML ist eine herstellerunabhängige international normierte Dokumentenbeschrei-
bungssprache für die logische Struktur und den Inhalt von Dokumenten. Bereits 1986
wurde diese Spezifikation als Standard etabliert und sogar zur ISO-Norm 8897 erho-
ben. Der Gründer von SGML, Charles Goldfarb, entwickelte diese Sprachdefinition
mit dem Ziel, die logische Struktur von Textdokumenten abbilden zu können. SGML
trennt dabei strikt die eigentlichen Informationsdaten von deren Layout zur Reprä-
sentation.
Da SGML die Dokumentinhalte (Semantik) von der Information zur späteren Wei-
terverarbeitung (Syntax) der Dokumente trennt, können die Inhalte auf verschiedene
Arten wiederverwendet werden:
·
Teildokumente in unterschiedlichen Produkten,
·
datenbankbasiertes Publizieren
·
oder auch die Generierung unterschiedlicher Produkte (Print-, Online- oder CD-
ROM-Versionen) aus einem strukturierten Datenbestand.
SGML legt die Regeln fest, nach denen elektronische Dokumente aufgebaut werden.
Die Nutzung von SGML erfordert die Definition von Strukturen und Inhalten. Ei-
ne solche Definition wird als Document Type Definition (DTD) bezeichnet. Durch
die Veröffentlichung und Standardisierung von mit SGML erstellten DTD´s können
SGML-Applikationen als neue Auszeichnungssprachen wie z.B. HTML (
Hypertext
Markup Language
) definiert werden.
2.2.2. SGML-DTD
In einer Dokumenttyp-Definition (engl. Document Type Definition) werden die Struk-
tur-Merkmale für Dokumente festgelegt. Dokumente, die ähnlich strukturiert sind,
gehören demselben Dokumenttyp an. Eine Dokumenttyp-Definition ist eine Reihe
von Definitionen für
Elementtypen
,
Attributen
,
Entities
und
Notationen
.
Sie deklariert, welche davon an welchen Stellen innerhalb des Dokuments zulässig
sind. Eine DTD definiert unter anderem:
·
Die
Namen
und deren
Inhalte
für alle Elemente (textuelle Einheiten), die in
einem Dokument dieses Typs zulässig sind.
·
Wie
oft
ein Element auftreten darf.
·
Die
Reihenfolge
, in der die Elemente auftreten müssen.
·
Ob die Start- oder Endemarkierung
weggelassen
werden darf.
·
Die
Markierungsattribute
und ihre Wertebereiche.
·
Die Namen von sog.
Referenzsymbolen
und anderen
Entitäten
.
Das Inhaltsmodell der DTD ist der wichtigste Teil. Es bestimmt die strukturellen
Beziehungen der Elemente zueinander. Dazu stehen eine Reihe von Operatoren zur
Verfügung, die in Verbindung mit Klammerung beliebige Strukturen ermöglichen.
6
Kapitel 2. Grundlagen
Die Bedeutung der Operatoren lässt sich mit Hilfe folgender Tabelle anschaulich
machen:
Ordnungsoperatoren:
,
Komma
zur Definition von strikten Abfolgen von Elementen
|
Balken
zur Definition von Alternativen von Elementen
Häufigkeitsoperatoren:
?
Fragezeichen
zur Definition von optionalen Elementen
*
Stern
nullmaliges oder beliebig häufiges Auftreten von
Elementen
+
Plus
mindestens einmaliges Auftreten von Elementen
Klammerung:
(...)
Klammern
zur Darstellung von Einbettungen
Deklaration
Eine DTD wird am Anfang eines SGML-Dokuments in der sog. Document Type De-
claration untergebracht. Die DTD-Definitionen bestehen selbst aus speziellem Mar-
kup. Eine DTD kann außerhalb des Dokuments liegen. Alternativ oder zusätzlich
dazu können weitere DTD-Deklarationen im SGML-Dokument stehen.
<!-- Externe und interne Definitionen -->
<!DOCTYPE name SYSTEM "externe.dtd"
[ ... Deklarationen der internen DTD ... ]>
<!-- Externe und interne Definitionen -->
<!DOCTYPE name PUBLIC "publicid" "externe.dtd"
[ ... Deklarationen der internen DTD ... ]>
<!-- Nur externe Definitionen -->
<!DOCTYPE name SYSTEM "externe.dtd">
<!-- Nur interne Definitionen -->
<!DOCTYPE name [ ... Deklarationen der internen DTD ... ]>
Die DTD-Deklaration steht am Anfang des Dokuments und vor dem eigentlichen
Inhalt. Sie kann beliebige Kommentare und Processing Instructions (PIs) enthalten.
Externe DTD´s
Der externe Teil kann über das Schlüsselwort
SYSTEM
direkt in einer URL angege-
ben werden.
<!DOCTYPE HTML SYSTEM "http://www.w3.org/TR/html4/strict.dtd">
7
Kapitel 2. Grundlagen
Alternativ kann über das Schlüsselwort
PUBLIC
auch eine ,,öffentliche" DTD an-
gesprochen werden. Es wird dabei davon ausgegangen, dass der jeweilige Parser die
öffentliche DTD ,,kennt" bzw. eingebaut hat und ihm daher die Angabe des Namens
der öffentlichen DTD reicht. Die Benennung der PUBLIC-Namen ist nicht genormt.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
Es können auch Mischformen angegeben werden (
PUBLIC
und
SYSTEM
, wobei das
Schlüsselwort
SYSTEM
dann entfällt):
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
Interne DTD´s
Der interne Teil der DTD (also der Teil, der sich direkt im Dokument befindet) steht
in eckigen Klammern. Er ist optional. Deklarationen, die hier gemacht werden, über-
schreiben bzw. ergänzen die Deklarationen der externen DTD.
DTD-Name
Der Name der DTD steht auch für die Anwendung, für die die DTD entwickelt wird.
Er entspricht dem Element-Typ, der das ganze Dokument umschließt. Wird also z.
B. eine DTD deklariert mit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<HTML>
... hier kommt der Inhalt
</HTML>
wird das gesamte Dokument von einem
HTML
-Element umschlossen.
2.2.3. DocBook
DocBook ist eine DTD (document type definition), um strukturierte Dokumente mit-
tels SGML oder XML zu schreiben. Sie ist besonders gut geeignet für Bücher und
Artikel und sonstige technische Dokumentationen. DocBook wird momentan von
der OASIS (Organization for the Advancement of Structured Information Standards)
verwaltet.
Es wurde von Norman Walsh auch eine XML Version von DocBook entwickelt,
welche als
DocBook XML DTD
bezeichnet wird. Die aktuelle Version ist die 4.1.2
vom 27.Aug.2000. Diese XML DTD wurde im Februar 2001 zu einem offiziellen
OASIS Standard. Das Buch ,,DocBook: The Definitive Guide" [DocBook] gilt als
offizielle Dokumentation zur DocBook DTD.
DocBook weist eine hierarchische Struktur auf. Das
book
-Element ist das geläu-
figste Top-Level Element. Es kann Komponenten, wie Vorwort (
preface
), Kapi-
tel (
chapter
), Anhang (
appendix
), Glossar (
glossary
) und Artikel (
article
)
enthalten (siehe Beispiel 2-1). Diese Elemente können wiederum in verschachtelte
Abschnitte (
section
) unterteilt werden.
8
Kapitel 2. Grundlagen
Die vorliegende Diplomarbeit ist ebenfalls in DocBook geschrieben. Ausführlichere
Informationen zu DocBook findet man unter [DocBook].
Das folgende Beispiel soll den Grundaufbau einer DocBook-Datei zeigen. Wie oben
schon beschrieben, beginnt die Datei mit einer Dokumenttypdeklaration. Die Wur-
zel der Datei stellt ein
book
-Element dar. Im Buch sind die Metainformationen
(
bookinfo
) enthalten, darunter der Autor (
author
) mit dem Vor- (
firstname
)
und Nachnamen (
surname
) und das Copyright mit dem Jahr (
year
) und Inhaber
(
holder
). Des weiteren gibt es folgende Komponenten: Vorwort (
preface
), Kapi-
tel (
chapter
), Anhang (
appendix
) und Indexverzeichnis (
index
).
Beispiel 2-1. Ein einfaches DocBook-Dokument
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
<book>
<bookinfo>
<title>UNIX-Kurs für Anfänger</title>
<author>
<firstname>Evgenia</firstname>
<surname>Hawlisch</surname>
</author>
<copyright>
<year>2001</year>
<holder>Evgenia Hawlisch</holder>
</copyright>
</bookinfo>
<preface><title>Vorwort</title> ... </preface>
<chapter> ... </chapter>
<appendix> ... </appendix>
<index> ... </index>
</book>
2.2.4. HTML (Hypertext Markup Language)
HTML (HyperText Markup Language) ist der soft- und hardwareunabhängige Stan-
dard zur Verteilung, Organisation und Verbindung von Dokumenten im World Wi-
de Web. HTML ist eine SGML-Applikation, d. h. HTML hat eine eigene, mittels
SGML erstellte DTD (bzw. eine DTD pro Version) und eine festgelegte Anzahl von
Markierungen zur Modellierung von (präsentationsorientierten) Dokumentstruktu-
ren. HTML wurde 1989 von Tim Berners-Lee in Genf entwickelt.
Das folgende Beispiel soll das Grundgerüst einer HTML-Datei beschreiben. In der
ersten Zeile wird der SGML-Dokumenttyp angegeben, mit der gewünschten HTML-
Version, in diesem Fall 4.01. Die HTML-Datei ist in die Tags
<html>
bzw.
</html>
eingeschlossen. Hinter dem einleitenden HTML-Tag folgt das einleitende Tag für
den Kopf
<head>
. Zwischen diesem Tag und seinem Gegenstück
</head>
werden
allgemeine Angaben zur HTML-Datei notiert. Die wichtigste dieser Angaben ist der
Titel der HTML-Datei, markiert durch die Tags
<title>
bzw.
</title>
. Unter-
halb davon folgt der Textkörper, markiert durch die Tags
<body>
bzw.
</body>
.
Im Textkörper wird dann der eigentliche Inhalt der Datei notiert, also das, was im
Anzeigefenster des WWW-Browsers angezeigt werden soll. In diesem Beispiel sind
das ein Überschrift erster Ebene, markiert durch die Tags
<h1>
und
</h1>
, ein paar
9
Kapitel 2. Grundlagen
Absätze, beginnend mit
<p>
und eine ungeordnete Liste, eingeschlossen zwischen
den Tags
<ul>
und
</ul>
und den Einträgen, markiert durch
<li>
. Beachten Sie,
dass die Angabe der End-Tags in HTML nicht zwingend notwendig ist.
Beispiel 2-2. Ein einfaches HTML-Dokument
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>
HTML: Ein Beispiel
</title>
</head>
<body>
<h1>
HTML: Ein Beispiel
</h1>
<p>
Dies ist ein Absatz.
<p>
Wichtiges kann speziell <em>betont</em> werden.
Es gibt auch Listen:
<ul>
<li>nummerierte
<li>unnummerierte
<li>verschachtelte
</ul>
<p>
und vieles mehr
</body>
</html>
Seit HTML-Version 2.0 muss laut Spezifikation [RFC1866] der Doctype ange-
geben werden, die Webbrowser benötigen diese Angabe allerdings nicht.
2.2.5. XML
XML steht für Extensible Markup Language und ist eine Metasprache für das Defi-
nieren von Dokumenttypen. Wie HTML stammt XML von der Urmutter aller Me-
tasprachen SGML (Standard Generalized Markup Language) ab. Als Untermenge
von SGML ist XML auch eine Metasprache, die aber speziell für den Einsatz im
Web entworfen wurde. XML 1.0 wurde 1996 als Diskussionsvorschlag vom W3C
vorgestellt und 1998 als Standard verabschiedet.
Bei der Definition von XML wurde Wert darauf gelegt, den großen Umfang von
SGML auf ein Minimum zu reduzieren, um die Erlernbarkeit und damit die Ver-
breitung zu erleichtern. Während SGML Anforderungen an die strukturierten Doku-
mente stellt, sich auf die DTD's (Document Type Definition) zu stützen, um gültig
(engl. valide) zu sein, erlaubt XML auch wohlgeformte (engl. well formed) Daten
und kann somit ohne DTD verbreitet (ausgeliefert) werden. Aber jedes gültige XML-
Dokument ist zugleich ein gültiges SGML-Dokument.
10
Kapitel 2. Grundlagen
Das Thema XML ist sehr umfangreich. Außerdem ist die XML-Technologie das Ba-
siswerkzeug im praktischen Teil dieser Diplomarbeit. Beide der aufgezählten Tatsa-
chen sind Grund genug, dem Thema XML den folgenden Abschnitt 2.3 zu widmen.
2.2.6. Hierarchie der Auszeichnungssprachen
Die folgende Abbildung stellt die Hierarchie einiger wichtigen Auszeichnungsspra-
chen dar.
Metasprachen
XML
SGML
XSL
XHTML
...
...
WML
DocBookx
DocBook
HTML
DSSSL
Abbildung 2-1. Hierarchie der Auszeichnungssprachen
Daraus werden einige wichtige Abhängigkeiten klar. XML (Extensible Markup Lan-
guage) ist, ebenso wie sein Verwandter HTML (Hypertext Markup Language), eine
Auszeichnungssprache. Beide sind abgeleitet von der ,,Standard Generalized Mar-
kup Language", kurz SGML. Zu erkennen ist dies auch an ihrer ähnlichen Syntax.
Doch während XML eine Untermenge von SGML darstellt, ist HTML lediglich eine
Anwendung jener. Mit ein paar Veränderungen hat das World Wide Web Consortium
(W3C) Anfang 2000 HTML als eine Anwendung von XML umgesetzt. Dabei wurde
HTML in XML (statt SGML) neu definiert. Diese Anwendung heißt Extensible Hy-
pertext Markup Language, kurz XHTML. Auf der Abbildung sind noch DocBook
und DSSSL (Document Style Semantics and Specification Language) als Anwen-
dungen von SGML und WML (Wireless Markup Language) und XSL (Extensible
Stylesheet Language) als Anwendungen von XML zu sehen.
2.3. XML
Für den Anfang ein kleines Beispiel, das die Funktionsweise von XML verdeutlichen
soll. Es stellt eine Liste von CDs dar. In der ersten Zeile wird die XML-Version
festgelegt, mehr dazu später im Abschnitt 2.3.1. Die CD-Liste enthält einzelne CDs
mit dem Titel, Sänger (hier
interpret
genannt), dem Hersteller und dem Preis.
11
Kapitel 2. Grundlagen
Die CD seinerseits besteht aus mehreren Soundtracks (hier
track
genannt) mit dem
Titel und der Länge.
Beispiel 2-3. Ein einfaches XML-Dokument
<?xml version="1.0"?>
<!-- ein einfaches XML-Dokument -->
<cdliste>
<cd>
<titel>Music</titel>
<interpret>Madonna</interpret>
<hersteller>BMG</hersteller>
<preis>19.99</preis>
<track id="01">
<titel>Music</titel>
<laenge>4:35</laenge>
</track>
<track id="02">
<titel>Impressive Instant</titel>
<laenge>5:10</laenge>
</track>
<track id="03">
<titel>Runaway Lover</titel>
<laenge>4:20</laenge>
</track>
</cd>
<cdliste>
2.3.1. XML-Dokumente
Ein XML-Dokument besteht aus einem (optionalen) Prolog und den eigentlichen
XML-Daten. Der
Prolog
sollte die XML-Deklaration enthalten, sowie eine eventu-
elle Referenz auf ein externes
Stylesheet
und eine
Deklaration
, die den Doku-
menttyp festlegt. Die
XML-Deklaration
enthält die XML-Version, evtl. eine Co-
dierungsdeklaration (falls nicht die Unicode-Codierungen verwendet werden) und
eine Standalone-Deklaration, die darüber informiert, ob Markup-Deklarationen au-
ßerhalb des Dokumentes stehen (falls ja: standalone="no"). Ist keine Standalone-
Deklaration vorhanden, wird "no" angenommen.
Beispiel:
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
In einem Stylesheet ( i.a. CSS- oder XSL-Stylesheet) wird das Layout des XML-
Dokumentes festgelegt. Beispiel für eine solche Stylesheet-Referenz:
<?xml-stylesheet href="...\styles\muster.xsl"
type="text/xsl" ?>
12
Kapitel 2. Grundlagen
Jedem gültigen XML-Dokument muss eine DOCTYPE-Deklaration vorangehen (sie-
he SGML-DTD). Die Dokumenttyp-Deklaration beinhaltet i.a. eine Referenz auf
eine externe Dokumenttyp-Definition (DTD), kann aber auch eine interne DTD ent-
halten, die in der gleichen Einheit gespeichert ist wie die XML-Daten.
Beispiel 2-4. Ein XML-Dokument mit externer DTD:
<?xml version="1.0" ?>
<!DOCTYPE gruss SYSTEM "hallo.dtd">
<gruss>Hallo Welt!</gruss>
Beispiel 2-5. Ein XML-Dokument mit interner DTD:
<?xml version="1.0" ?>
<!DOCTYPE gruss [
<!ELEMENT gruss (#PCDATA)>
]>
<gruss>Hallo Welt!</gruss>
In einer XML-Datei können folgende Bausteine enthalten sein:
·
Elemente,
·
deren Attribute und
·
Entities (Textbausteine).
Elemente und Attribute
Die meisten Dokumente weisen eine hierarchische Struktur auf, d.h. sie können in
Komponenten aufgegliedert werden, welche ihrerseits auch wieder aus verschiede-
nen Komponenten bestehen. So sind z.B. Bücher in Kapitel unterteilt, die sich aus
Überschriften, Absätzen, Abbildungen usw. zusammensetzen. In XML nennt man
diese logischen Komponenten, in die ein Dokument zerlegt werden kann,
Elemen-
te
. Elemente können entweder andere Elemente enthalten oder den eigentlichen Text
des Dokuments, der in XML als Zeichendaten bezeichnet wird. Die Elemente sind
durch Start- und End-Tags oder durch ein Leeres-Element-Tag begrenzt.
Da dieser hierarchische Aufbau eine baumartige Struktur aufweist, wird das Ele-
ment, das alle anderen Elemente enthält (z.B. das Buch), als
Wurzelelement
oder
Dokumentelement
bezeichnet, dessen Unterelemente, wenn sie ihrerseits wieder
Unterelemente enthalten (wie z.B. Kapitel), als
Zweige
bezeichnet werden, ande-
renfalls (z.B. Überschriften) als
Blätter
(vgl. Abbildung 2-2).
Den Elementen können zusätzliche Eigenschaften oder andere charakteristische In-
formationen zugeordnet werden, die als
Attribute
bezeichnet werden. Attribute
haben Namen und Werte. Beispielsweise könnte das Attribut Schuhgröße eines Men-
schen den Wert 43 haben:
<mensch schuhgroesse="43" />
13
Kapitel 2. Grundlagen
Entities
Entities sind Textbausteine, die vom einzelnen Zeichen bis zum kompletten externen
XML-Dokument reichen können. Der Aufruf geschieht durch
&entityname;
im
Dokument. Entity-Inhalte werden in der DTD deklariert. Entities können ihrerseits
wieder Entity-Aufrufe (-Referenzen) enthalten.
Entities können also ganz unterschiedlichen Zwecken dienen, wie z.B.:
·
dem Repräsentieren von mehrfach vorkommenden Zeichenfolgen
·
dem Positionieren von Nicht-XML-Daten in einem XML-Dokument
·
der modularen Konstruktion einer DTD
·
der modularen Konstruktion eines XML-Dokumentes
·
der systemunabhängigen Repräsentanz von Zeichen
Entity-Deklarationen werden grundsätzlich durch das Literal
!ENTITY
eingeleitet.
Interne/Externe Entities
Interne Entities sind solche, bei denen die Ersetzung direkt in der Entity-Deklaration
steht. Dem gegenüber wird bei externen Entities mit dem Schlüsselwort
SYSTEM
auf
eine externe Datei verwiesen, deren Inhalt dann als Ersetzung dient. Anstelle von
SYSTEM
ist auch hier
PUBLIC
möglich, wird in der Praxis aber kaum Verwendung
finden.
Parsed/Unparsed Entities
Entities werden unterschieden in:
·
Parsed Entities. Entities, deren Ersetzungs-Text XML ist und daher als XML
geparst und interpretiert werden kann.
·
Unparsed Entities. Entities, die kein XML sind (z. B. Bilder, Videos, Grafiken,
Textverarbeitungs-Dokumente, usw.) und über einen anderen Parser/Prozessor
verarbeitet werden müssen.
Unparsed Entities bekommen immer eine Notation zugewiesen. Diese hilft der XML-
Anwendung, den passenden Prozessor für die jeweilige Notation (=Art von Unparsed
Entity) zu finden. Bei jeder Deklaration einer Unparsed Entity wird über das Schlüs-
selwort NDATA die - vorher deklarierte - Notation angegeben.
Parameter-Entities
Parameter-Entities sind ein Sonderfall der Entities. Es handelt sich dabei um spe-
zielle Entities, die nur innerhalb der DTD referenziert (aufgerufen) werden dürfen.
Dadurch können DTD-Teile deklariert werden, die an mehreren Stellen verwendet
werden können. Es können dabei keine Namenskonflikte mit General-Entities auf-
treten, denn Parameter-Entities werden immer durch ein Prozent-Zeichen eingeleitet.
Hier ein komplexes Beispiel zur Vorstellung der oben aufgezählten Arten von Enti-
ties mit entsprechenden Erläuterungen[SeminarSM]:
14
Kapitel 2. Grundlagen
Beispiel 2-6. Entities-Sammlung
<?xml version="1.0" standalone="no"?>
<!DOCTYPE Seminar PUBLIC "-//AS-Institut//DTD Seminar 1.0//DE"
"http://www.acme.com/dtds/seminar.dtd" [
<!ENTITY % x "Extensible" >
<!ENTITY XML "%x; Markup Language">
<!ENTITY GenIndex SYSTEM "GenerierterIndex.xml">
<!NOTATION GIF89A PUBLIC "-//ACME//GIF viewer pro//EN">
<!ENTITY xmlLogo SYSTEM "xmlLogo.gif" NDATA GIF89A>
]>
<Seminar>
<Titel>Seminar über &XML; </Titel>
<Kapitel> <Abbildung EntityRef="xmlLogo"/> </Kapitel>
&GenIndex;
</Seminar>
Parameter-Entity Deklaration, kann nur innerhalb der DTD referenziert wer-
den, z.B. als Abkürzung für oft wiederkehrende Zeichenfolgen
Entity Deklaration für internes Entity, die ein Parameter-Entity referenziert
Entity Deklaration für externes analysiertes Entity
Entity Deklaration für externes nicht-analysiertes Entity, hier eine binäre Bild-
datei Namens
xmlLogo.gif
Zeichendaten Referenz, der Zahlenwert entspricht einem kleinen deutschen
U-Umlaut ´ü´
interne Entity-Referenz, der Ersetzungstext entspricht der Zeichenfolge ,,Ex-
tensible Markup Language"
externe nicht-analysierte Entity in einem Attribut vom Typ Entity, bindet die
externe binäre Bilddatei namens
xmlLogo.gif
ein
externe Entity Referenz bindet die externe Entity in Form einer XML-Datei
namens
GenerierterIndex.xml
ein
Weiterführende Informationen zu Entities siehe unter [XMLUH].
Wohlgeformtheit und Gültigkeit
XML hat zwei verschiedene Vorstellungen von ,,korrekt". Ein Dokument, das nach
den gültigen XML-Regeln geschrieben ist, wird als wohlgeformtes (engl.
well for-
med
) Dokument bezeichnet. Ein Dokument ist gültig, wenn es keines der Inhalts-
modelle der entsprechenden DTD verletzt. Ein gültiges XML-Dokument enthält al-
so zusätzlich zur Wohlgeformtheit noch eine Dokumenttyp-Definition (DTD). Ein
wohlgeformtes Dokument sollte u.a .folgende Bedingungen erfüllen:
·
die XML-Version sollte deklariert sein
·
es gibt genau 1 Wurzelelement
·
innerhalb des Wurzelelementes sind alle Elemente eindeutig ineinander ver-
schachtelt
·
alle nicht-leeren Elemente sind mit Start-Tag und End-Tag markiert
15
Kapitel 2. Grundlagen
·
jeder Start-Tag beginnt mit ,,<" und schließt ab mit ,,>" und jeder End-Tag
beginnt mit ,,</" und schließt ab mit ,,>"
·
leere Elemente sind entweder mit Start- und End-Tag markiert oder beginnen
mit ,,<" und schließen ab mit ,,/>"
·
Attribute müssen einen Wert haben; dieser muss in Anführungszeichen gesetzt
sein
·
ein Attribut darf nicht zweimal im gleichen Tag vorkommen
·
verwendete Entitäten müssen vor ihrer Referenzierung deklariert worden sein
Folgendes Beispiel zeigt ein XML-Dokument, das die oben aufgezählte Regeln für
wohlgeformte XML-Dokumente erfüllt.
Beispiel 2-7. Ein wohlgeformtes XML-Dokument:
<?xml version="1.0" ?>
<eltern>
<kind>
<nachname> Meier </nachname>
<vorname> Max </vorname>
</kind>
</eltern>
Im Vergleich zum vorherigen zeigt das folgende Beispiel ein gültiges XML-Dokument,
das wohlgeformt ist und die angegebene (interne) DTD erfüllt. DTD schreibt die
Regeln für den Aufbau des Wurzelelementes
eltern
vor. Und zwar: das Element
eltern
darf beliebig viele Elemente (
*
-Zeichen) vom Typ
kind
enthalten. Das
Element
kind
muss mindestens eins (
+
-Zeichen) Element vom Typ
nachname
und
mindestens eins (
+
-Zeichen) Element vom
vorname
Typ enthalten. Elemente
nach-
name
und
vorname
beinhalten Zeichendaten.
Beispiel 2-8. Ein gültiges XML-Dokument (mit einer internen DTD)
<?xml version="1.0" standalone="yes" ?>
<!DOCTYPE eltern [
<!ELEMENT eltern (kind*)>
<!ELEMENT kind (nachname+, vorname+)*>
<!ELEMENT nachname (#PCDATA)>
<!ELEMENT vorname (#PCDATA)>
<eltern>
<kind>
<nachname> Meier </nachname>
<vorname> Max </vorname>
</kind>
</eltern>
16
Kapitel 2. Grundlagen
2.3.2. XML-Parser
Was ist ein Parser? Ein Programm, welches bestimmte syntaktische Strukturen
erkennen und nach bestimmten Regeln weiterverarbeiten kann, z.B. Compiler, Brow-
ser, Datenbanken (beim Import von ASCII-Text). XML-Parsern lesen ein XML-
Dokument ein und überprüfen es auf Wohlgeformtheit; bei nicht wohlgeformten
Dokumenten wird eine entsprechende Fehlermeldung ausgegeben.
In XML unterscheidet man zwischen einfachen und validierenden Parsern, je nach-
dem, ob sie XML-Dokumente auch auf Gültigkeit prüfen. Während ein nichtvali-
dierender Parser nur die korrekte XML-Syntax prüft und die Strukturen weiterverar-
beitet, muss ein validierender Parser ein Dokument immer in Bezug auf eine DTD
prüfen. Ein einfacher Parser muss somit nur die Wohlgeformtheit überprüfen, ein
validierender auch die Gültigkeit eines XML-Dokuments.
Ein Parser wird XML entweder in eine andere Struktur überführen (z.B. über eine
Umrechnungstabelle in HTML oder ein Satzsystem) oder für den Anwender optisch
aufbereiten (mittels Stylesheets).
Was für XML-Parser gibt es bereits? Es gibt schon einfache XML-Parser für die
meisten Programmier- und Skriptsprachen, z.B. Perl, Java, Python, C. Validierende
Parser sind seltener, da sie ungleich schwerer zu programmieren sind. Eine Übersicht
findet sich unter [XMLSOFTWARE].
Für die Programmierung haben sich inzwischen zwei API Schnittstellen etabliert:
Document Object Model (DOM) und Simple API for XML (SAX).
2.3.2.1. DOM
Das Document Object Model (DOM) ist nach [W3CDOM] ,,...ein Application Pro-
gramming Interface (API) für gültige HTML und wohlgeformte XML Dokumente.
Es legt die logische Struktur von Dokumenten fest und die Art, wie auf ein Dokument
zugegriffen bzw. wie es verändert werden kann".
Das Wort ,,Dokument" ist dabei im ,,weiteren Sinne" zu verstehen; d.h. es kann sich
dabei um jede beliebige Art von Informationen in verschiedenartigen Systemen han-
deln, die mittels XML dargestellt werden (z.B. ein in einer E-Commerce Anwen-
dung generierter, in XML formalisierter Bestellauftrag oder die Repräsentation eines
menschlichen Genoms).
Das Document Object Model (DOM) wurde vom World Wide Web Consortium
(W3C) als programmiersprachen- und plattformunabhängige Sammlung von Schnitt-
stellen und Objekten definiert. (Für Java und ECMAScript enthält die W3C Spezi-
fikation bereits Sprachbindungen für diese Schnittstellen.) Zusätzlich sind Semantik
(Verhalten und Attribute) der Schnittstellen und Objekte sowie ihre Beziehungen zu-
und Abhängigkeiten untereinander festgelegt.
Das Modell
In DOM wird zwischen der logischen Struktur eines (XML-)Dokuments und der Im-
plementierung dieser Struktur unterschieden. Damit (XML-)Dokumente mit DOM
bearbeitet werden können, müssen sie als Objektstruktur vollständig im Speicher
vorhanden sein. DOM definiert, dass ein Dokument ,,logisch" als Baumstruktur re-
präsentiert wird, die die Hierarchie der Objekte des Dokuments abbildet. Die Ele-
mente des Dokuments sind als Knoten des Baums angeordnet.
17
Kapitel 2. Grundlagen
Objekt
Objekt
Objekt
Objekt
Objekt
Objekt
Abbildung 2-2. Objekthierarchie im logischen DOM Strukturmodell
Weitere Informationen zu DOM siehe unter [SeminarGREK].
2.3.2.2. SAX
Mit SAX, der Simple API for XML, wurde der Versuch unternommen, eine API für
den einheitlichen Zugriff auf die bis zu diesem Zeitpunkt oft sehr unterschiedlichen
Parser-Schnittstellen zu definieren.
SAX [MEGSAX] ist im Gegensatz zu DOM kein offizieller Standard, sondern eine
Schnittstellen-Spezifikation für XML-Parser in der objektorientierten Programmier-
sprache Java. Die Spezifikation für SAX wurde maßgeblich von David Megginson
und der XML-Dev Newsgruppen entwickelt. Gleichzeitig mit der API Spezifikati-
on wurde eine Implementierung für Java veröffentlicht. Trotz der sprachspezifischen
Bindung ist SAX mittlerweile für die meisten gängigen Programmier- und Script-
sprachen umgesetzt. (SAX hat sich damit als ,,de-facto" Standard etabliert.)
SAX spezifiziert neben einer API für den einheitlichen Zugriff auf verschiedene Par-
ser ein Framework zur ereignisgesteuerten Verarbeitung von XML-Dokumenten. Mit
SAX wird allerdings, im Gegensatz zu DOM, nicht festgelegt, wie ein geparstes
XML-Dokument im Speicher logisch repräsentiert wird. SAX ermöglicht also nach
[Ind99] ,,den Zugriff auf die Informationen eines XML-Dokuments nicht über einen
Baum von Knoten, sondern in Form einer Reihe von Ereignissen". Diese Verarbei-
tungstechnik hat den Vorteil, dass sie schnell ist und wenig Speicher verbraucht (Do-
kumente müssen nicht erst im Speicher abgebildet werden, sondern können während
des Parse-Prozesses verarbeitet werden).
Das Konzept
Die SAX API kann abstrakt als Ebene gesehen werden, die zwischen dem eigentli-
chen XML Parser und der Anwendung angeordnet ist. Der Parser liest ein Dokument
und sendet die Daten als Ereignisse weiter an den SAX-Treiber, der sie wiederum an
die Anwendung weitergibt.
18
Kapitel 2. Grundlagen
Parser
SAX Treiber
Anwendung
Kontrollnachricht
Kontrollnachricht
Daten-Ereignisse
Daten-Ereignisse
Abbildung 2-3. Das SAX Modell
Die als SAX-Treiber bezeichnete Komponente ist die Zusammenfassung der Kern-
klassen der SAX API. Sie verhält sich dabei für den Parser wie eine Anwendung.
Der Parser implementiert die Parser-spezifischen Schnittstellen der API. Die eigent-
liche Anwendung implementiert das DocumentHandler Interface von SAX, um so
die Daten in Form von Ereignissen empfangen zu können. Weitere Informationen zu
SAX siehe unter [SeminarGREK].
2.3.3. XSL - Stylesheets in XML
Stylesheets
Aus HTML kennt man schon die Cascading Style Sheets (CSS), diese bieten aber nur
sehr eingeschränkte Möglichkeiten bei der Auswahl der zu formatierenden Elemente.
Außerdem ist die CSS-Syntax proprietär (nicht SGML-konform) und dadurch nur
innerhalb von Kommentaren verwendbar.
In SGML gibt es die Spezifikation DSSSL (Document Style Semantics and Specifi-
cation Language), diese ist wie SGML selbst sehr komplex.
Als Mittelglied zwischen diesen beiden Extremen wurde (und wird) XSL entwickelt
(XML Stylesheet Language).
XSL stellt zwei Funktionen bereit: Neben dem Transformationsmechanismus verfügt
XSL über einen Formatsprachschatz. Der bislang wichtigste Aufgabenbereich ist
die Transformation. XSL definiert hierfür die Mechanismen, wie bestehende XML-
Dokumente in neue Dokumente transformiert werden. Das transformierte Dokument
kann dabei die Markierungen und die DTD des ursprünglichen Dokuments verwen-
den oder völlig andere.
XML-
basierte
Daten
HTML, CSS oder
andere
Präsentationsform
XSL Prozessor
XSL Style
Sheet
Abbildung 2-4. Mechanismus von XSL
19
Kapitel 2. Grundlagen
Komponenten von XSL
Beim Einsatz von XSL kommen unterschiedliche Technologien zum Tragen. Bei der
Beschreibung von XSL unterscheidet man in der Regel drei Komponenten:
·
XPath (XML Path Language) dient dazu, bestimmte Dokumententeile eines
XML-Dokuments anzusprechen.
·
XSLT (XML Style Language Transformation) beschreibt, wie man die Baum-
darstellung eines XML-Dokuments in eine andere Baumdarstellung verwandelt.
·
XSL (Extensible Style Language) verfügt neben XSLT über einen Satz Forma-
tierungsobjekte samt zugehöriger Eigenschaften.
2.4. UNIX und LINUX
Was ist UNIX? Das Betriebssystem UNIX wurde ursprünglich in den Bell Labo-
ratories entwickelt, die einst Teil des Telekommunikationsgiganten AT&T waren. In
den 70er Jahren für Digital Equipment PDP-Computer entworfen, ist es zu einem
sehr populären Multiuser-/Multitasking-Betriebssystem für zahlreiche unterschied-
liche Hardwareplattformen geworden. Dies umfasst PC-Arbeitsstationen, aber auch
Multiprozessor-Server und Supercomputer.
Streng genommen ist UNIX ein Warenzeichen, das durch X/Open verwaltet wird und
sich auf ein Betriebssystem bezieht, das der X/Open-Spezifikation XPG4.2 (
X/Open
Portability Guide Version 4
) entspricht. Diese Spezifikation definiert die Na-
men, die Schnittstellen und das Verhalten aller Funktionen eines X/Open-kompatiblen
UNIX-Betriebssystems. Die übergeordnete X/Open-Spezifikation entstand größten-
teils aus früheren Spezifikationsreihen, wie z.B. den P1003- oder POSIX- Spezifi-
kationen, die aktiv durch das IEEE (Institute of Electrical and Electronic Engineers)
entwickelt wurden.
Es stehen viele UNIX-ähnliche Systeme zur Verfügung, die entweder kommerziell,
wie z.B. Sun Solaris für SPARC- und Intel-Prozessoren oder kostenlos, wie z.B.
FreeBSD und Linux, angeboten werden. Derzeit entsprechen nur wenige Systeme
der X/Open-Spezifikation. Nur diese dürfen offiziell als UNIX98 bezeichnet werden.
In der Vergangenheit ist die Kompatibilität zwischen verschiedenen UNIX-Systemen
ein Problem gewesen. Mit der Veröffentlichung der X/Open-Spezifikation besteht die
Hoffnung, dass UNIX und die vielen anderen UNIX-ähnlichen Systeme letztlich auf
einen Nenner gebracht werden können.
Was ist Linux? Linux ist ein Unix-ähnliches Betriebssystem. Es ist frei und kann
ohne Gebühren von jedem benutzt werden. Da Linux durch das UNIX-System in-
spiriert wurde, sind Linux- und UNIX-Programme sehr ähnlich. Eigentlich können
fast alle für UNIX geschriebenen Programme unter Linux kompiliert und ausgeführt
werden. Auch viele der gewerblichen Anwendungen, die für kommerzielle UNIX-
Versionen verkauft werden, können unverändert in binärer Form auf Linux-Systemen
laufen.
Sogenannte ,,Distributionen" enthalten neben Linux - dem eigentlichen Kern des
Betriebssystems - weitere freie Software, die das System um wichtige Komponenten
erweitert. Diese kann man von vielen ftp-Servern und auf CD-ROM erhalten. Zu
20
Kapitel 2. Grundlagen
den populären Distributionen zählen Slackware, SuSE, Debian, Red Hat und Turbo
Linux, doch es werden weitaus mehr angeboten.
Linux ist das Ergebnis einer internationalen Zusammenarbeit, geleitet von Linus Tor-
valds, dem ursprünglichen Autor. Da Linux unter der General Public License der
Free Software Foundation lizenziert ist, ist gesichert, dass der Linux-Quellcode im-
mer frei verfügbar sein wird und jeder Beteiligte dennoch die Urheberrechte an sei-
nem Code behält.
2.4.1. Die UNIX-Shell
Was ist eine Shell? Eine Shell ist eine ,,Arbeits-Oberfläche", die die vom Benutzer
eingegebenen Zeichenketten (i.d. Regel Betriebssystemkommandos, deren Parame-
ter, Variablen, Operatoren etc.) entgegen nimmt, interpretiert und zur Ausführung
an das jeweils gerufene (Unix-)Kommando weitergibt. Die Shells unterscheiden sich
von Umfang und Art ihrer Zeichenketten-Bearbeitung sowie von der Menge und
Komplexität ergänzender Steueranweisungen, d.h. durch die Mächtigkeit des Shell-
Interpreters.
Die Shell ist:
·
Schnittstelle zwischen Benutzer und Kernel
·
Interpretiert die Eingabe und führt Dienstprogramme aus
·
sie ist selbst ein Programm
Derzeit sind folgende Shells verbreitet:
·
sh-bourne. Bourne-shell (nach ihrem Programmierer); die erste Unix-Shell
·
ksh. Korn shell (nach ihrem Programmierer); Erweiterung der Bourne Shell
·
sh-posix. erweiterte Bourne Shell nach ,,POSIX shell"- und FIPS-Standard
·
bash. GNU-Bourne-Again-shell, erweiterte Bourne Shell
·
csh. C-shell: erste Shell mit history, Jobkontrolle und C-ähnlicher Syntax
·
tcsh. Erweiterung der C-shell
·
keysh. HP spezifische Shell mit soft-keys für Unix-Kommandos und HELP
2.4.2. Entfernter Shell-Zugriff
Einer der grundlegenden Dienste im Internet ist die Möglichkeit entfernte Rechner zu
nutzen. Telnet ist eine der ältesten (sowie FTP 1972) Dienste, die so eine Möglichkeit
bietet. Aufgrund der Sicherheitsbedenken wird Telnet in letzter Zeit immer häufiger
durch SSH (Secure Shell) ersetzt.
2.4.2.1. Telnet
Mit dem Internet-Dienst Telnet wird eine Verbindung zwischen zwei am Internet an-
geschlossenen Rechnern aufgebaut. Dies erlaubt am lokalen PC (Client) einen Dia-
21
Kapitel 2. Grundlagen
log mit dem entfernten Rechner (Server). Bei letzterem handelt es sich in der Re-
gel um einen unter Unix betriebenen Rechner, wo ein sogenannter Telnet-Daemon
(
telnetd
) laufen muss, der den Verbindungswunsch erlaubt. Für diesen muss der
Client-Benutzer eine Loginberechtigung besitzen, da Telnet nach erfolgtem Verbin-
dungsaufbau nach dem Loginnamen und dem Passwort fragt. Daten können auf dem
Server entweder mit FTP (File Transfer Protocol) oder aber über die Filesysteme
NFS (Netzwerk File System) und AFS (Andrews File System) verfügbar gemacht
werden.
Das Kommando telnet ist in der RFC 854 (Request For Comments) [RFC854] spe-
zifiziert.
In der Abbildung 2-5 wird schematisch die Telnet-Sitzung mit dem Betriebssystem
Unix dargestellt.
CLIENT
SERVER
Telnet
Telnet
Deamon
Shell
Pro-
gramm
Terminal-
Treiber
TCP/IP
TCP/IP
Pseudo-
TTY
Abbildung 2-5. Telnet-Sitzung unter Unix
2.4.2.2. SSH (Secure Shell)
Die herkömmlichen, im Internet benutzten Protokolle, wie z.B. HTTP (Hypertext
Transfer Protocol), FTP (File Transfer Protocol), Telnet, weisen zwei schwerwie-
gende Sicherheitsprobleme auf, die in letzter Zeit häufig von Angreifern ausgebeutet
werden.
Ein Problem ist die unverschlüsselte Übertragung der Daten, die es Angreifern er-
laubt, fremde Kommunikation aufzuzeichnen. Dieses Problem nutzen Angreifer mit
sogenannten Sniffern aus, die beim Login angegebene Benutzernamen und Passwor-
te aufzeichnen.
Das zweite Problem ist die fehlende Sicherung von Authentizität und Integrität der
übertragenen Daten. Angreifer können dadurch Daten mit einer fremden Identität
senden oder übertragene Daten manipulieren. Angreifbar sind insbesondere die Ser-
ver, die eine Authentisierung anhand von IP-Adressen vornehmen.
Um diese beide Probleme zu lösen, ist eine verschlüsselte Übertragung des Passwor-
tes, besser noch eine vollständig verschlüsselte Verbindung, notwendig. SSH ist da-
22
Kapitel 2. Grundlagen
bei die am weitesten verbreitete Lösung.
SSH
ersetzt direkt
Telnet
(bzw. die Unix-Kommandos rlogin, rsh bzw. remsh)
und bietet neben gleichem Komfort noch zusätzliche Dienste wie z.B. verschlüsselte
Weiterleitung von X11-Verbindungen, auch durch Firewalls hindurch.
2.5. Client-Server Architekturen
Die Client-Server-Architektur bezeichnet ein Systemdesign bei dem die Verarbei-
tung einer Anwendung in zwei separate Teile aufgespaltet wird. Ein Teil läuft auf
dem Server (Backend-Komponente), der andere Teil auf einer Workstation (Client
oder Front-End). Beide Teile werden über Netzwerke zu einem System zusammen-
gefügt. Der Client gibt auf dem Server die Bearbeitung von Daten in Auftrag und
nimmt die Leistungen des Servers in Anspruch.
Die Arbeitsteilung zwischen Client und Server kann auf sehr unterschiedlichen Ebe-
nen einer Systemanwendung erfolgen. Um die Aufgabentrennung besser beschrei-
ben zu können, wird oft versucht, verteilte Anwendungen in ein Schichtenmodell zu
unterteilen.
Je nach dem, wie und wo die Aufteilung verläuft, ergeben sich zwei- oder mehrstu-
fige Modelle, und damit die 2-Schichten- (two tier) oder mehrschichtige Architek-
turen (multi tier architecture). Die zur Zeit häufigsten 2-Schichten-Architektur und
3-Schichten-Architektur sind in den nächsten Abschnitten aufgeführt.
2.5.1. 2-Schichten-Architektur
Bei der Zwei-Schichten Architektur (Two-Tier Architectures) wird die Anwendung
auf zwei Komponenten aufgeteilt. Hier spricht man von verteilten Anwendungen
oder auch von Client/Server-Systemen. Sowohl die Bildschirmdarstellung als auch
Anwendungslogik werden vom Client übernommen. Die Datenhaltung findet zentral
auf einem Datenbankserver statt. Solche Aufgabenteilung entlastet den Server, aber
bringt auch Nachteile mit sich. Abbildung 2-6 zeigt eine typische Anwendung mit
Zwei-Ebenen Architektur:
Client
Server
Netzwerk
DB
Bildschirmdarstellung
Anwendungslogik
Datenquelle
Abbildung 2-6. Zwei-Ebenen Architektur.
23
Kapitel 2. Grundlagen
Einerseits ist die Zwei-Ebenen Architektur viel einfacher zu implementieren, als 3-
Schichten-Architektur.
Andererseits weist sie auch gewisse Nachteile auf:
Jede Anwendungsänderung führt zu einem Aufwand, der durch die Anzahl der Cli-
ents bestimmt ist. Auch die Fehlerfindung und Fehlerbehebung sind aufwendig. Die-
se Nachteile werden häufig unter dem Schlagwort Fat-Client-Problematik themati-
siert.
2.5.2. 3-Schichten-Architektur
Die Anwendung wird nach funktionalen Gesichtspunkten in drei Komponenten auf-
geteilt: Datenhaltung + Anwendungslogik + Bildschirmdarstellung. Auf dem Cli-
ent findet sich nur noch die Benutzerschnittstelle. Hier können Benutzer mit den
Elementen des grafischen Benutzer-Interfaces interagieren. Auf dem Anwendungs-
server ist die Logik der Anwendung implementiert. Dies kann von der Berechnung
betriebswirtschaftlicher Kennzahlen bis hin zur Simulation komplexer Systeme rei-
chen.
Die für die Berechnung notwendigen Daten werden vom Datenbankserver ange-
fordert und Ergebnisse, wenn notwendig, dem Datenbankserver zur Abspeicherung
übergeben.
Anwendungs- und Datenbankserver müssen nicht notwendigerweise unterschiedli-
che Computer sein. Wichtig im Sinne einer 3-Schichten Architektur ist nur, dass
zwischen Anwendungsobjekten und Datenbankzugriff eine klar definierte Schnitt-
stelle besteht. Die Hardware, auf der diese Komponenten ablaufen, ist durch die zur
Objektkommunikation eingesetzte Middleware transparent. Abbildung 2-7 zeigt eine
typische Anwendung mit Drei-Ebenen Architektur.
Netzwerk
Client
Bildschirmdarstellung
Server
Datenquelle
Netzwerk
DB
Anwendungsserver
Anwendungslogik
Abbildung 2-7. Drei-Ebenen Architektur.
Die Vorteile von 3-Ebenen Architekturen kann man folgendermaßen formulieren:
Da die drei Schichten über festgelegte Objektschnittstellen kommunizieren, bleibt
der Austausch oder die Änderung einer Schicht ohne Auswirkungen auf die anderen
Ebenen der Anwendung.
24
Kapitel 2. Grundlagen
3-Ebenen Architekturen erlauben darüber hinaus flexible Ausfallsicherheits- und Last-
verteilungskonzepte. So kann die Anwendungslast sowohl auf der Applikations- als
auch auf der Datenbankschicht auf mehrere Rechner verteilt werden. Darüber hinaus
kann die Anwendungsschicht auf mehrere Datenquellen zugreifen.
2.6. Client-Server Kommunikation
Grundsätzlich lassen sich bei dem für die Datenerfassung eingesetzten Client-Server-
System zwei verschiedene Fälle unterscheiden, die insbesondere für die Kommuni-
kation von Bedeutung sind:
1. Clients und Server laufen auf demselben Rechner.
2. Clients uns Server sind auf unterschiedlichen Rechnern aktiv.
Im ersten Fall beschränkt sich die Kommunikation auf reine Interprozesskommuni-
kation. Für ein Lernsystem ist der zweite Fall von Bedeutung. Der Lehr-Server soll
im Idealfall von überall für die Schüler erreichbar sein.
Einer von möglichen Wegen, den man gehen könnte, um den Ablauf der verteilten
Anwendungen auf den verschiedenen Rechnern zu realisieren, ist Middleware.
2.6.1. Middleware
Für den Begriff Middleware haben sich unterschiedliche Definitionen etabliert: So
definiert die Gartner Group Middleware als Systemsoftware zwischen Anwendungs-
programm und Betriebssystem während das Beratungshaus Ovum unter diesem Be-
griff jede Art von Connectivity-Software zur Steuerung des Datenflusses zwischen
Clients und Servern versteht. Im [BEN2000] wird Middleware als ,,verteilte System-
services" bezeichnet.
Middleware [BEN2000] besitzt eine Standardschnittstelle und ein Standardprotokoll.
Einige Schnittstellen sind bereits über das API (Application Programming Interface)
definiert. Im weiteren kann eine so genannte Middleware eingesetzt werden, um eine
eigene Schnittstelle zu definieren.
2.6.1.1. Sockets
TCP/IP stellt eine einfache Schnittstelle zur Anwendungskommunikation, die ,,socket
library" zur Verfügung. Auf diese Schnittstelle kann von Sprachen wie C++ oder Ja-
va zugegriffen werden.
Sockets stellen einen Mechanismus auf geringem Abstraktionsniveau bereit, um vir-
tuelle Verbindungen zwischen Prozessen aufzubauen und über diese Daten auszut-
auschen. Sie wurden erstmals 1982 mit BSD 4.113 Unix zur Verfügung gestellt.
Eine Verbindung im Internet kann durch das 5-Tupel
{ Verbindungsprotokoll, lokale Adresse, lokaler Port,
entfernte Adresse, entfernter Port}
eindeutig beschrieben werden. Adresse ist dabei die Internet-Adresse, z.B. 141.24.76.102.
25
Kapitel 2. Grundlagen
Ein Socket ist genau eine Seite einer solchen Verbindung, nämlich ein Tripel aus
{ Verbindungsprotokoll, Internet-Adresse, Portnummer}.
Sockets eignen sich sehr gut, um einfache Datentypen zwischen Prozessen auf un-
terschiedlichen Rechnern auszutauschen. Ihr Vorteil ist der sehr geringe Overhead
und die daraus resultierende schnelle Übertragung. Ein Nachteil von Sockets liegt
in der fehlenden Typsicherheit. Um Daten typsicher zu übertragen, ist ein größerer
Overhead notwendig. Außerdem muss der Anwendungsprogrammierer ein Protokoll
entwickeln, dass die Grundlage für den Datenaustausch darstellt und die Bedeutung
der übertragenen Daten festlegt.
2.6.1.2. RMI
Das Java Remote Method Invocation (RMI) ist ein Objektmodell zur Realisierung
von verteilten Systemen in der objektorientierten Sprache Java.
Verteilte Systeme im objektorientierten Umfeld erfordern ein verteiltes Objektmo-
dell und einen verteilten Nachrichtenfluss, welcher einem entfernten Methodenauf-
ruf entspricht. Der Remote Procedure Call (RPC), bekannt aus dem prozeduralen
Umfeld, ist in objektorientierten Sprachen nicht oder nur eingeschränkt verwend-
bar. Da steht mit dem RMI eine Transferierung der RPC-Konzepte zur Verfügung,
welche die besonderen Belange der objektorientierten Sicht berücksichtigt.
Die beiden wichtigsten Vorteile von RMI sind die Möglichkeit komplexe Objekte
zwischen Client und Server auszutauschen und transparent Nachrichten an entfernte
Objekte zu senden, bzw. Methoden entfernter Objekte aufzurufen.
Bei Verwendung von RMI ist keine explizite Erzeugung von Sockets notwendig, ein
entfernter Methodenaufruf ist einem normalen Methodenaufruf eines lokalen Objek-
tes syntaktisch gleich. Die Kommunikation zwischen Client und Server geschieht da-
bei mittels Stubs und Skeletons. Diese können durch einen speziellen RMI-Compiler
(rmic) erzeugt werden. Ein entfernter Methodenaufruf eines Client wird durch das
Laufzeitsystem weitergereicht an das lokale Stub-Objekt. Dieses Stub-Objekt er-
zeugt mittels des Socket-Mechanismus eine Verbindung zum Server, auf dem dann
die entsprechende Methode des Objektes aufgerufen wird. Mögliche Rückgabewerte
gehen den entgegengesetzten Weg zurück zum Client.
Der Ablauf eines Funktionsaufrufes über Java-RMI wird in der Abbildung 2-8 dar-
gestellt und läuft wie folgt ab:
26
Kapitel 2. Grundlagen
RMI-Registry
Server
Client
Stub
Server
Skeleton
1
3
2
Abbildung 2-8. Ablauf eines Java-RMI Funktionsaufrufes
1. Anmeldung des Servers beim RMI-Registry-Server. RMI bietet einen ein-
fachen, nicht persistenten Naming-Service an. Damit ist es einerseits möglich,
bestimmte Server-Objekte unter einem Namen zu registrieren und andererseits
können Clients nach diesen Namen fragen und erhalten eine Objektreferenz,
die ihnen die Nutzung dieses Objektes ermöglicht.
2. Anfrage des Clients an den RMI-Registry-Servers. Durch eine Anfrage
an den RMI-Registry-Server erhält der Client eine Objektreferenz auf das ge-
wünschte Objekt und kann somit seine Methoden aufrufen.
3. Aufbau der Verbindung zum Server und Nutzung des Objektes. Dies
geschieht im Hintergrund durch den Client-Stub und die Remote-Referenz-
Schicht. Nur wenn Fehler auftreten, wird der Client bzw. der Server benach-
richtigt.
2.6.1.3. CORBA
CORBA (Common Object Request Broker Architecture) ist die Spezifikation eines
Standards für verteilte objektorientierte Anwendungen, der von der OMG (Object
Management Group) verabschiedet wurde. Der OMG gehören z.Zt. über 900 Unter-
nehmen an.
Schnittstellen zwischen Objekten werden in der programmiersprachenneutralen Cor-
ba IDL (Interface Definition Language) implementiert. Um in einer konkreten Pro-
grammiersprache entwickelte Objekte anzusprechen, existieren Abbildungen (Map-
pings) zwischen der jeweiligen Programmiersprache und IDL (z.B. C++ IDL oder
Java IDL).
Client-Objekte rufen Methoden von Server-Objekte im CORBA-Ansatz nicht direkt
auf. Sie richten ihre Anfrage an einen sogenannten ORB (Object Request Broker).
Der ORB ermittelt über ein Implementation Repository einen geeigneten Server und
leitet die Anfrage des Clients an den Server weiter. Dabei spielt es keine Rolle, auf
welchem Rechner oder in welcher Programmiersprache der Server implementiert
wurde. Er muss nur vom ORB erreichbar sein.
Der Server arbeitet die Anfrage des Client ab. Die Resultate (
return values
und
output parameter
) oder evtl. auftretende Fehlermeldungen (
exceptions
) wer-
den vom Server über den ORB an den Client zurückgegeben.
27
Kapitel 2. Grundlagen
Client
Objekt
Implementation
Dynamic
Skeleton
Invocation
(DSI)
IDL
Skeletons
(static)
ORB
Interface
IDL
Stubs
(static)
Dynamic
Invocation
Interface
(DII)
Object Request Broker Core
Object
Adapter
Interface-
Repository
Implementation-
Repository
Abbildung 2-9. Allgemeiner Aufbau eines CORBA-ORBs
Ausführliche Darstellungen der CORBA-Technologie finden sich auf der Seite der
Object Management Group [OMG] oder im Buch [SIE96].
2.6.1.4. SOAP
SOAP (Simple Object Access Protocol) ist ein XML und HTTP basierendes Messa-
ging-Protokoll, mit dem Informationen in einer dezentralen, verteilten Umgebung
ausgetauscht werden können. SOAP 1.1 wurde von Microsoft, IBM, Lotus, Develop-
Mentor, UserLand Software und weiteren W3C-Mitgliedern entwickelt. Das Proto-
koll vereinfacht den Datentransfer, indem es ein Framework definiert, mit dem die
Inhalte einer Botschaft und deren Übertragungsart beschrieben werden. Dazu defi-
niert es im einzelnen:
1. wie Messages in XML dargestellt werden
2. wie Datentypen kodiert werden und
3. wie entfernte Funktionsaufrufe repräsentiert werden
Die Spezifikation beschreibt weiterhin, wie SOAP auf der Basis von HTTP genutzt
wird. Weitere Informationen siehe unter [SOAP].
Die Version 1.1 von SOAP wurde vor etwas mehr als einem Jahr verabschiedet und
ist noch nicht sehr weit verbreitet.
2.6.2. Web-Anwendungen
Man kann den Begriff Webanwendung wie folgt definieren: ,,eine verteilte Anwen-
dung, bei der ein Server (Webserver) mit mehreren räumlich getrennten, HTML-
fähigen Clients (Webbrowsern bzw. Browsern) über HTTP oder eine Weiterentwick-
lung davon (HTTPS, WAP, o.ä.) kommuniziert" [sota].
In diesem Abschnitt sind die wichtigsten Techniken der Webanwendungen aufge-
führt. Die Servlets und das CGI stellen ein Beispiel für die serverseitigen Anwen-
dungen dar, die Applets illustrieren die clientseitige Webanwendungen.
28
Details
- Seiten
- Erscheinungsform
- Originalausgabe
- Erscheinungsjahr
- 2001
- ISBN (eBook)
- 9783832452889
- ISBN (Paperback)
- 9783838652887
- Dateigröße
- 1.3 MB
- Sprache
- Deutsch
- Institution / Hochschule
- Hochschule Mannheim – unbekannt
- Erscheinungsdatum
- 2014 (April)
- Note
- 1,3
- Schlagworte
- unix-shell cocoon