Konzeption und Implementierung eines Prototyps eines interaktiven Lernsytems für die UNIX-Shell

Hawlisch, Evgenia

Konzeption und Implementierung eines Prototyps eines interaktiven Lernsytems für die UNIX-Shell

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 […]

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

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

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

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.

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.

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).

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).

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.

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.

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.

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.

<!DOCTYPE name SYSTEM "externe.dtd"

[ ... Deklarationen der internen DTD ... ]>

<!DOCTYPE name PUBLIC "publicid" "externe.dtd"

[ ... Deklarationen der internen DTD ... ]>

<!DOCTYPE name SYSTEM "externe.dtd">

<!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">

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.

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>

<title>UNIX-Kurs für Anfänger</title>

<firstname>Evgenia</firstname>

<surname>Hawlisch</surname>

</author>

<holder>Evgenia Hawlisch</holder>

</copyright>

</bookinfo>

<preface><title>Vorwort</title> ... </preface>

</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

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.

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.

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"?>

<cd>

<titel>Music</titel>

<interpret>Madonna</interpret>

<titel>Music</titel>

</track>

<titel>Impressive Instant</titel>

</track>

<titel>Runaway Lover</titel>

</track>

</cd>

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" ?>

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-

. 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:

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;

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]:

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>

<Titel>Seminar über &XML; </Titel>

&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

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" ?>

<kind>

<nachname> Meier </nachname>

</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)>

<kind>

<nachname> Meier </nachname>

</kind>

</eltern>

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.

Kapitel 2. Grundlagen

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.

Kapitel 2. Grundlagen

Parser

SAX Treiber

Anwendung

Kontrollnachricht

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

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

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-

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

Deamon

Shell

Pro-

gramm

Terminal-

Treiber

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-

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

Bildschirmdarstellung

Anwendungslogik

Datenquelle

Abbildung 2-6. Zwei-Ebenen Architektur.

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

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.

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.

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:

Kapitel 2. Grundlagen

RMI-Registry

Server

Client

Stub

Server

Skeleton

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.

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.

Details

Seiten
Erscheinungsform: Originalausgabe
Jahr: 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

Autor

Evgenia Hawlisch (Autor:in)

Konzeption und Implementierung eines Prototyps eines interaktiven Lernsytems für die UNIX-Shell

Zusammenfassung

Leseprobe

Inhaltsverzeichnis

Details

Autor

Evgenia Hawlisch (Autor:in)