Ein Internetarchiv für elektronische Dokumente: Entwurf und Implementierung

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

Glossar

1 Einleitung

2 Aufgabenstellung

3 Vorhandene Systeme
3.1 ROA - Rutgers Optimality Archive
3.2 Der ROA-Spiegel in Marburg
3.3 Andere Archive
3.4 CMS - Content-Management Systeme
3.5 PCA im Vergleich zu den betrachteten Systemen

4 Auswahl der verwendeten Basistechnologien
4.1 Entwurfsmethodik
4.2 Generelle Ziele
4.3 Rahmenbedingungen
4.4 Anforderungen an den Webserver
4.5 Datenhaltung
4.5.1 SQL-Datenbanken
4.5.2 DBM-Dateien
4.5.3 XML-Dateien
4.5.4 Text-Dateien
4.5.5 Die Entscheidung
4.6 Programmiersprache
4.6.1 Perl
4.6.2 Python
4.6.3 PHP
4.6.4 Java
4.7 HTML
4.8 CGI
4.8.1 Forms
4.8.2 HTTP-Request
4.8.3 CGI-Programme

5 Konkrete Planung
5.1 Das Datenmodell
5.2 Die Verzeichnisstruktur
5.3 Vorlagen
5.4 Anmeldung
5.5 Verwaltung
5.6 Auflisten und Anbieten der Arbeiten
5.7 Suchfunktion
5.8 Volltextsuche
5.9 Newsletter
5.10 Korrektheit und Fehler-Benachrichtigung
5.11 Vitalitäts-Überprüfung
5.12 Backups
5.13 Sicherheit
5.13.1 Code-, HTML- und SQL-Injection
5.13.2 Unix-Zugriffsrechte und ihre Folgen
5.13.3 CGI-Programme und Sicherheit
5.13.4 Spezielle Angriffszenarien
5.13.5 Zusammenfassung
5.14 Diverses

6 Implementierung
6.1 Technische Informationen
6.2 Modularisierung
6.3 CGI-Parameter und Verteilerfunktionen
6.4 Exempel: Die Suchfunktion
6.5 Qualitätssicherung
6.6 Dokumentation
6.7 Komplexität
6.8 Verwendete Software
6.9 Diverses

7 Schlussbemerkungen
7.1 Das Ergebnis
7.2 Nicht erreichte Ziele und Änderungen der Aufgabenstellung
7.3 Erweiterungen und die nächste Zukunft
7.4 Alternative Vorgehensweisen

Abbildungsverzeichnis

4.1 Programmiersprachen der iX-Leser (entnommen aus [heise2002a])

4.2 Formular-Elemente

5.1 Anmeldungsschritte und zentrale Vorlage

5.2 Anmeldung als Automat

5.3 Verwaltung Hauptfenster

5.4 Verwaltung der Anmeldungen

5.5 HTML-Liste von Arbeiten

5.6 Darstellung einer einzelnen Arbeit

5.7 Suchmaske mit Ergebnis

6.1 Die eigenen Module von PCA

Tabellenverzeichnis

4.1 DBM-Systeme (nach perldoc AnyDBM_File)

4.2 HTML-Quelltext zu Abb. 4.2 (S. 30)

4.3 Aufrufabstand bei exemplarischer Suchmaschine

5.1 Metadaten zu PCA-Nummer

5.2 Verzeichnisstruktur von PCA

5.3 Dimensionen von Volltextsuchsystemen

5.4 User-Datei von PCA

5.5 CGI-Formular zum Umbenennen

5.6 Konfigurationseinstellungen für incoming_dir

6.1 Die Module von PCA

6.2 Token in reguläre Ausdrücke wandeln

6.3 Erzeugung des Parser-Objektes

6.4 Parsen und Auswerten

6.5 Baum zu ’( a OR NOT b )’

6.6 Selber installierte Software

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Glossar

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Professor Plag von der Anglistik der Uni- versität Siegen wünschte sich ein System mit dem er wissenschaftliche Arbeiten sei- nes Fachgebietes für Interessierte zugäng- lich im Internet archivieren konnte. Mit die- sem Anliegen wandte er sich an die Infor- matik der Universität Siegen und daraus ent- stand diese Arbeit. Die Implementierung ist als PCA („Pidgins and Creoles Archive“) un- ter http://www.pca.uni-siegen.de [pca] erreichbar.

Im nächsten Kapitel (2, S. 3) wird die Auf- gabenstellung beschrieben. In Kapitel 3 (S. 7) werden vorhandene Systeme für diese Auf- gabe dargestellt. Nach der Auswahl der Ba- sistechnologien (4, S. 11) werden konkretere Planungen (5, S. 39) ausgeführt. Ein Schwer- punkt liegt hierbei auf Sicherheitsfragen und konkreten Lösungen. Anschließend (6, S. 69) wird auf die Implementierung eingegangen und in den Schlussbemerkungen (7, S. 82) folgt eine Bewertung des Ergebnisses, ein Ausblick mit Erweiterungsmöglichkeiten und ein Vorschlag für eine alternative Vorgehens- weise.

Nun einige Bemerkungen zu formalen Aspekten dieses Textes: Männliche Bezeich- nungen wurden wertfrei stellvertretend für weibliche und männliche Personen benutzt. Referenzen werden großzügig gesetzt um schnelles Navigieren in der PDF-Version die- ser Arbeit zu ermöglichen. Oft stehen diese einfach am Ende eines Satzes um den Lese- fluss nicht durch lange Formulierungen („wie in Kapitel 123 Seite 234 für den interes- sierten Leser beschrieben wird“) zu unterbre- chen. Gelegentlich wird hier auf Dokumentationen wie die Perl-Anleitungen oder Unix man-P ages verwiesen oder daraus zitiert. Da- bei wird die Form perldoc -f delete benutzt damit das nicht erst im Literaturver- zeichnis nachgeschlagen werden muss. Die meisten Literaturstellen sind URLs welche aufgrund ihrer Länge und den damit ver- bundenen Trenn- und Darstellungsproblemen meist nicht im Text sondern im Literaturver- zeichnis ausgeführt werden. Über den Sei- tenrand herausragende Code- und Daten- Schnipsel wurden hingegen in Kauf genom- men. Wenn die Aussagen problemlos mit Google [google] im Internet nachgeschlagen werden können und dort in mehreren Quel- len vorliegen, werden sie als Allgemeinwis- sen betrachtet und nicht, oder nur selten mit Quellen belegt. Beispiel: „Apache ist neben IIS der am häufigsten eingesetzte Webserver.“

Deutsche Bezeichnungen werden engli- schen Bezeichnungen meist vorgezogen. Eng- lische Begriffe verwende ich wenn Sie zum allgemeinem Sprachgebrauch gehören („In- ternet-Browser“) oder bestimmte (meist tech- nische) Dinge bezeichnen deren Übersetzung mir nicht passend erscheint. Beispiele sind Indexer statt „Indizierungssysteme“ (5.8, S. 49) oder Abstract statt „Zusammenfassung einer wissenschaftlichen Arbeit“ oder einfach nur „Zusammenfassung“. Diese Bezeichnun- gen werden oft optisch anders dargestellt. Englische Zitate wurden nicht übersetzt. Bei- spiele für verdeutlichte Sachverhalte sind zur verkürzten Darstellung häufig nur eingeklam- mert im Satz untergebracht oder als „Beispiel:

...“ hinter der Erläuterung.

In einer streng wissenschaftlichen Arbeit ist die Verwendung von „ich“ verpönt. Hier geht es aber nicht um den möglichst unum- stößlichen Nachweis von Hypothesen sondern um die Konstruktion eines Systems. Dazu wa- ren viele Einzelentscheidungen zu treffen und oft aus Alternativen auszuwählen. Ein Bei- spiel von Vielen: Macht man die Datenhal- tung in Text-Dateien, XML-Dateien, DBM- Datenbanken oder SQL-Datenbanken (4.5, S. 17) ? Ich hätte die meisten oder sogar je- de der Alternativen implementieren können. Meist habe ich diejenige bevorzugt bei der ich am sichersten war das ich das geforderte Ergebnis korrekt und mit geringem Aufwand erhalte. Diese Überlegungen sind dokumen- tiert und da ich diese Entscheidungen getrof- fen habe und dazu stehe und auch weiß das es mehr als einen Weg gab habe ich das gele- gentlich mit „ich“ kenntlich gemacht. Dassel- be gilt für die Auswahlkriterien der verwende- ten Software. Es handelt sich hier nicht um ei- ne Doktorarbeit bei der vom Doktoranden zu erwarten ist das er alle Forscher die so etwas ähnliches machen persönlich kennt und über alle aktuellen Entwicklungen informiert ist. Um meinen eingeschränkten Überblick über die vorhandenen Angebote darzustellen wur- de auch in diesen Fällen gelegentlich die Ich- Form gewählt.

Wie in 4 (S. 11) und 5 (S. 39) erläutert wird, ist eine lineare Darstellung des Themas nicht ganz einfach. Daher werden gelegentlich Din- ge wiederholt um den Zusammenhang zu ver- deutlichen oder es sich bei Betrachtung aus ei- nem anderen Blickwinkel ergibt.

Danken möchte ich Professor Plag für die konstruktive Zusammenarbeit. Er hatte klare, nicht überzogene Zielvorstellungen und woll- te ein einfaches, funktionierendes und zweck- mäßig ausgerichtetes System. Das erleichter- te die Planung und spätere Arbeit deutlich. Weiterhin danke ich Professor Merzenich für die Betreuung der Arbeit. Er ließ mir freie Hand bei der Realisierung und ich wurde nicht durch Vorgaben der Art “das wird mit XML/XSLT/Java/... gemacht weil das der ak- tuelle Hype ist“ eingeschränkt. Zu guter Letzt geht mein Dank an das AVMZ und speziell Volker Hess der unbürokratisch und kurzfris- tig den Zugang einrichtete unter dem PCA jetzt läuft. Bei Problemen reagierte er immer schnell und wirkte an der Lösung mit. Negati- ve Äußerungen bezüglich Administratoren in diesem Text sind ausdrücklich nicht auf ihn und das AVMZ-System bezogen.

2 Aufgabenstellung

Die Aufgabe bestand darin eine Web-Site zu schaffen in der wissenschaftliche Arbei- ten hochgeladen werden können. Diese soll- ten nach Freigabe öffentlich zugänglich und im Archiv einsortiert sein. Professor Plag wünschte sich im Wesentlichen so etwas wie ROA welches in 3.1 (S. 7) ausführlicher be- schrieben wird.

Er lieferte in den ersten Besprechungen ei- ne Liste seiner Wünsche und unterteilte das System schon aus seiner Sicht in eine Service , Upload- und Downloadkomponente. Dies diente als Grundlage für die Aufgabenstel- lung. Die drei Komponenten wären in be- triebswirtschaftlichen Systemen als Teile des Hauptprozesses (Arbeiten anbieten) definiert und daran alles aufgehängt worden. Da die Aufgabenstellung übersichtlich war und es nicht um die Modellierung eines Betriebes, einer Abteilung oder eines mehrstufigen Pro- zesses geht, wurden hier jedoch keine Mo- dellierungswerkzeuge, Use Cases oder Ähn- liches benutzt. Stattdessen führe ich im fol- genden die Aufgaben und die Personengrup- pen in Form von Rollen auf die diese Aufga- ben systemunterstützt ausführen wollen. Den Kapiteln über die Architektur (4, S. 11 und 5, S. 39) und Implementierung (6, S. 69) wird meist nicht vorgegriffen sondern darauf verwiesen. Manche technische Rahmenbedin- gungen und auch Konzepte die eher in Pla- nung und Architektur gehören, wurden vorher abgesprochen und erscheinen daher hier. Da- bei handelt es sich oft auch nur um erste Ideen und keine endgültigen Entscheidungen.

Arbeit anmelden und hochladen: Autoren müssen ihre Arbeiten anmelden. Dazu sind Daten wie der Titel, die Autoren- Namen, die Anzahl der Seiten und das Erscheinungsdatum einzugeben. Auch ein Abstract sowie die Dokumente sind hochzuladen. Bei den Dokumenten han- delt es sich überwiegend um PDF- und Word-Dateien, andere Formate sollten aber nicht verboten sein. Nach der An- meldung erhalten die PCA-Mitarbeiter eine Email damit sie wissen das ei- ne neue Arbeit bearbeitet werden muss. Auch der Anmelder bekommt eine Email zur Bestätigung. (5.4, S. 44)

Arbeit überprüfen und freigeben: Die Ar- beiten sollen von Verwaltern (Professor Plag und seine Mitarbeiter) technisch und inhaltlich auf Eignung zur Veröf- fentlichung im Archiv geprüft werden. Die inhaltliche Überprüfung kann nur von Menschen vorgenommen werden. Bei der technischen Überprüfung treten folgende Punkte auf: Die Anmeldung ist auf Vollständigkeit zu überprüfen: Titel, Autoren und andere Dinge müssen an- gegeben sein. Dies lässt sich von den CGI-Programmen noch erledigen. Eben- so können diese eine grobe Plausibili- tätskontrolle der Daten vornehmen. Bei- spiel: Email-Adressen müssen ein „@“ enthalten bevor die Anmeldung abge- schickt wird. Ob der Titel der Arbeit korrekt ist und zum hochgeladenen Ab- stract und Word- oder PDF-Dokumenten passt kann nur von Menschen überprüft werden. Ebenso ist eine Kontrolle ob das Dokument vollständig hochgeladen wurde bei verschiedenen und sich u.U. auch noch ändernden Dokumentenfor- maten (PDF, Word, Powerpoint, ...) wenn überhaupt nur sehr aufwendig möglich.

Das Überprüfen besteht also darin das die Verwalter die Dokumente herunterla- den, durchsehen, evtl. die Anmeldungs- daten überarbeiten und bei positivem Be- fund die Arbeit freigeben. Da es sich teil- weise um Word-Dokumente handelt soll- ten diese auf Viren überprüft werden. Die Daten zu einer Arbeit und die Dokumen- te sind schlussendlich von den Verwal- tern manuell einzustellen.

Selbstbedienung in dem Sinne das je- der, bestimmte Gruppen oder Perso- nen Arbeiten ohne Kontrolle einstellen entsprach nicht den Zielvorstellungen. Ebenso sollte das System nicht koopera- tiv sein: Jemand stellt seine Arbeit ein. Alle oder bestimmte Gruppen bewerten diese Arbeit und schalten diese nach ei- nem festzulegenden System frei. (5.5, S. 45)

Newsletter: Auf neue Arbeiten soll per Email hingewiesen werden. Interessiere müssen sich dazu in einer Liste eintra- gen was relativ einfach durch ein HTML- Interface bewerkstelligt werden kann. (5.9, S. 54)

Arbeiten anbieten: Die Informationen zu den Arbeiten sollen über Webseiten angebo- ten werden und Besucher die Möglich- keit haben, die Dokumente herunterzula- den. Dazu bietet es sich an, pro Arbeit ei- ne Web-Seite mit allen Daten anzubieten über die auf die Download-Dateien zu- gegriffen werden kann. Beschränkungen in der Art der Daten („nur Word“) sollte es nicht geben. D.h. es werden „beliebi- ge“ Dateien angeboten und das Format ist dem System egal. Die Daten sollten auch komprimiert als ZIP-Dateien ange- boten werden.

Arbeiten auflisten: Die Arbeiten sollen den Besuchern nach ihren Nummern auf- gelistet werden. Listen nach Autoren- Namen wurden nicht gewünscht. Die Ar- beiten nach Titel zu sortieren bringt kei- nen Vorteil da dies keine semantische Anordnung der Arbeiten bewirken wür- de. Das wäre dann sinnvoll wenn die Ti- tel strukturiert wären („HP 123 - Hand- buch“, „HP 123 - Users Guide“, „HP 123 - Technical Guide“, ...) was es er- möglicht, die Arbeiten in Gruppen ein- zuordnen. Dies ist bei PCA nicht der Fall weswegen keine Listen nach Titel im- plementiert wurden. Bei Sites mit aktu- ellen Berichten ist das Datum die gän- gige Sortierung. Bei PCA ist das nicht so interessant also gibt es keine Lis- ten nach Datum. Höhere PCA-Nummern (in der nächsten Aufzählung näher erläu- tert) stehen meist auch für neuere Arbei- ten. Allerdings können auch alte Arbei- ten aufgenommen werden weswegen die Nummern nur mit einem Eingangsstem- pel vergleichbar sind aber keine chrono- logische Reihenfolge darstellen.

Suchfunktionen: Die Besucher sollen in den Daten (Titel, Autoren, Abstracts,...) su- chen können. Eine Volltextsuche wurde nicht gewünscht. (5.7, S. 48)

Seiten ändern: Professor Plag oder Mitarbei- ter sollen das Aussehen der Seiten än- dern können. (5.3, S. 42)

In den Vorbesprechungen mit Professor Plag ergaben sich noch folgende Randbedin- gungen:

- Die technische Ausstattung der Forscher in seinem Fachgebiet reicht von modern

bis alt. Also sollten die Seiten auch mit alten Browsern lesbar sein. Daraus er- gab sich das einfaches HTML ausgege- ben wird und kein Javascript, Java, Flash oder Frames benutzt werden.

Daher wurde auch nicht weiter erwogen eine „Applikation“ innerhalb des Brow- sers anzubieten. Das ist heute für grö- ßere Software (SAP, Oracle Enterpri- se Applications, Siebel) üblich benötigt aber oft Plugins für die Browser und so- mit eine einmalige Installation beim Be- nutzer. Der Softwareanbieter kommt da- durch vom Windows-GUI los und ist zu- kunfstsicherer. Erfolgt der Zugriff über den Web-Browser reicht es, Updates zen- tral einzuspielen und alle Benutzer ha- ben beim nächsten Start die neue Ap- plikation. Java-Applets fallen auch unter dieses Konzept. Diese laufen zwar auf vielen Rechnern aber immer noch auf weniger Rechnern als normale HTML- Seiten. Da die gewünschten Inhalte auch mit normalen HTML darstellbar sind und Applets ohne Mehraufwand keine we- sentlich bessere Funktionalität für PCA bieten würden, wurde über Applets für die Besucher-Seiten nicht weiter nachge- dacht.

- In dem von ROA abgedeckten Fachge- biet ist es gängig die ROA-Nummer als Referenz zu benutzen („Meine Arbeit liegt bei ROA als 123-1102“). Daraus ergibt sich die Bevorzugung der Num- mern gegenüber den Autoren, Titeln oder Erscheinungsdaten bei den Auflistungen. ROA benutzt zweigliedrige Nummern der Form „NUMMER-DATUM“. Wenn Arbeit 123 im November 2002 erschie- nen ist, wird daraus „123-1102“. Bei PCA sollten einfache Zahlen ohne zwei- ten Teil benutzt werden.

Die Gespräche enthielten auch Beratungs- anteile in denen unter anderem folgende Din- ge besprochen wurden:

Technisch wäre es möglich einen Webser- ver auf einem PC mit Windows anzubieten. Der Rechner müsste dann aber immer einge- schaltet sein und das Webserverprogramm im- mer laufen um Anfragen beantworten zu kön- nen. Das ist bei einem Büro-PC normalerwei- se nicht der Fall. Betreibt man einen eige- nen Server wird immer ein Techniker benö- tigt welcher sich im Notfall darum kümmert. Webserver sind von außen erreichbar und da- her dauernden Portscans und anschließenden Angriffsversuchen ausgesetzt. Also müssen regelmäßig und bei Bedarf Sicherheitsaktua- lisierungen an Servern vorgenommen werden. Einfacher wäre es daher, einen vorhandenen Server mit zu benutzen. Professor Plag orga- nisierte einen virtuellen Server beim AVMZ und auch den Domain-Namen „www.pca.uni- siegen.de“. Damit ergaben sich auch die tech- nischen Rahmenbedingungen (Linux-Server, Apache-Webserver) die in 4.3 (S. 15) un- ter bestimmten Gesichtspunkten genauer be- leuchtet werden.

Es sollten einige selten veränderte Websei- ten im Archiv vorhanden sein. Dazu gehör- ten Anleitungen wie Arbeiten hochzuladen sind, Links auf Tools wie ZIP-Programme und PDF-Viewer oder Verwendungsrichtlini- en. Nach der Erstinstallation hat Professor Plag diese Seiten selber erstellt und eingebun- den.

Von den anderen Archiven im Internet sind nur die Funktionen für Benutzer und teilwei- se die Anmeldeprozedur sichtbar. Die Verwal- tung der Arbeiten bekommen nur die Mit- arbeiter zu sehen. Daher bestanden diesbe- züglich keine Vorgaben. Dafür hätte man z. B. Office- oder Windows-Scripting-Host- Makros schreiben und die Verwaltung auf lo- kalen PCs durchführen können. Auch wä- re es möglich gewesen eine Java-Applikation

dafür zu schreiben. Der Einfachheit halber und Konsistenz wegen wurde dasselbe CGI- System wie für die Anmeldungen und Such- funktionen benutzt. Ein Gruppensystem für die Benutzer mit genauen Richtlinien wer, was, wann, wo ändern oder hinzufügen darf, wurde nicht gefordert und somit auch nicht implementiert.

Eine rechtliche Beratung fand in Ermange- lung der nötigen Kenntnisse nicht statt. Fol- gende Fragen wären zu klären: Datenschutz der Verwalter und Besucher durch Speiche- rung von IP-Nummern in Log-Files oder Ver- wendung von Cookies. Bei PCA werden keine Daten aktiv gesammelt. Nur die Logfiles des AVMZ existieren. So lange es keine Recht- sprechung diesbezüglich gibt und alle Ser- ver Logfiles speichern [heise2000a] also al- le das so machen ist das eher ein theoreti- sches Problem. Copyright- und Meinungsäu- ßerungsprobleme durch die angebotenen Sei- ten und Arbeiten könnten auch möglich sein. Zunächst einmal wird unterstellt das die Au- toren ihre Einwilligung zur Veröffentlichung geben und in ihren Arbeiten keine illega- len oder beleidigenden Dinge von sich ge- ben. Dann könnte es immer noch passieren das ein Verlag seine Rechte durch öffentli- ches Anbieten einer Arbeit gefährdet sieht [heise2002c,heise2002d]. Das Risiko effekti- ver Sanktionen dürfte gering sein so lange der Verlag nicht in Deutschland oder der EU be- heimatet ist. Auch wird unterstellt das die Au- toren das vorher abgeklärt haben. Momentan besteht die größte rechtliche Bedrohung ins- besondere von privaten Websites in Abmahn- anwälten. Webseitenbetreiber sollten sich ge- gen so etwas durch dauernde Beobachtung (Heise Newsticker [heisenews] oder speziel- lere Rechtsseiten lesen) schützen. So lange auf PCA nichts getan wird was die anderen nicht auch machen ist die rechtliche Situati- on zwar (mangels umfangreicher Rechtspre- chung) nicht eindeutig geklärt aber große Risiken sollte der Betrieb nicht darstellen.

Eine Teilname an DINI [dini] bzw. der Open Archives Initiative [oai] war nicht be- absichtigt.

Die hier aufgeführten Anforderungen wur- den im wesentlichen erfüllt. Abweichungen von den anfänglichen Planungen werden in 7.2 (S. 82) aufgeführt.

3 Vorhandene Systeme

In einer mehr theoretisch ausgerichteten Arbeit wäre jetzt der Zeitpunkt gekommen den aktuellen Stand der Forschung darzustel- len. Da der Schwerpunkt dieser Arbeit auf dem Entwickeln einer Lösung lag werden stattdessen vorhandene Archive für wissen- schaftliche Arbeiten dargestellt.

Dieses und das vorhergehende Kapitel hän- gen insoweit zusammen als das die Wünsche an ein neues System oft auch durch Kennt- nis über vorhandene Systeme beeinflusst wer- den. Aus der Aufgabenstellung ergeben sich oft relativ naheliegend bestimmte Überlegun- gen über die man teilweise nicht weiter reflek- tiert, die aber vielleicht nur daher rühren das alle anderen Webseiten das auch so machen.

Eine Einordnung in die Schubladen „das haben wir uns selber ausgedacht“ bzw. „das haben wir bei den anderen abgeschaut“ ist nur für die Verwaltungsfunktionen möglich. Kei- nes dieser Systeme (und auch PCA nicht) bie- ten einen Blick auf ihr Verwaltungssystem. Also wurde die Verwaltung von PCA ohne jegliche Kenntnisse über die Administrations- oberflächen fremder Systeme entworfen.

Daher werden in diesem Kapitel nur die für die Besucher öffentlich zugänglichen Funk- tionen betrachtet. Dieses Wissen ist in die Pla- nungen eingeflossen und manche Funktionali- tät wurde auch so erwartet.

Zuerst wird ROA vorgestallt (3.1, S. 7), dann der Marburger Spiegel von ROA (3.2, S. 8) und anschließend kurz auf die Archive ein- gegangen die über die Bibliothek der Univer- sität Siegen erreichbar sind (3.3, S. 9). Dann folgt eine Beschreibung von CMS (3.4, S. 9) und zum Schluss wird ROA mit PCA verglichen.

3.1 ROA - Rutgers Optimality Archive

Das ROA [roa] diente als Hauptvorlage für die Funktionalität welche PCA anbieten soll- te. Während der Planung und Implementie- rung von PCA wurde auch ROA erneuert. Es wird hier der aktuelle Zustand beschrieben auch wenn die Technik und das Design beim Start von PCA andere waren.

Die Startseite ist recht einfach und bietet Links auf Benutzungsregeln, Tools (Anzeige- programme für die verschiedenen Dokumen- tenformate), eine Suchfunktion, Listen und Anmeldung an. Die normalen Listen ließen sich beim letzten Besuch nicht aufrufen, daher werden diese hier nicht beschrieben. Die Liste mit den neuesten Einsendungen funktionierte jedoch und darüber ließen sich in frei wählbar großen Segmenten (4, 7, 10, 13, 16, 19 Ein- träge pro Seite) die Nummernbereiche durch- blättern. Bei der kompakten Ansicht werden die Nummer, Titel, Autoren und die Doku- mente als Links angeboten. Die Nummer, der Titel und der Abstract führen auf eine HTML- Seite mit den ausführlichen Informationen zu der Arbeit. Autoren-Namen sind mit einem mailto:-Link auf deren Email-Adressen hin- terlegt. Die ausführliche Listen-Ansicht blen- det zusätzlich Bemerkungen, die Anzahl der Seiten, die Keywords und das Fachgebiet ein. Die gängigsten Dokumenttypen sind PDF, Word und Postscript. Seltener treten Wordper- fect, RTF oder HTML auf. Dokumente zu ei ner Arbeit werden oft in mehreren Formaten angeboten und praktisch immer ist PDF da- bei. Oft gibt es mehrteilige Arbeiten bei denen dann die Kapitel als einzelne Dateien unter derselben ROA-Nummer vorliegen. Alle Da- teien werden auch im GNU gzip-Format an- geboten.

Die Suchfunktion ist in kleiner Form auf jeder Seite untergebracht aber es gibt auch eine eigene Suchseite. Die Suchsprache um- fasst die logischen Operatoren (AND, OR, NOT) und greift auf Attribute über Anhäng- sel an den Suchworten zu. Dadurch kann die Suche auf Abstract, Autor, Dateiformat, Vorname, Nachname Titel oder Kommentar eingeschränkt werden. Um nach einem Au- tor mit Nachnamen „Meier“ zu suchen wählt man in der Schnellsuche das Autor-Feld und trägt „Meier“ ein. Die Autoren-Suche erzeugt automatisch eine Abfrage {{meier}.ln} OR {meier}.fn für den last name bzw. first name. Alternativ schreibt man direkt{meier}.ln. Suche nach Phrasen und die Wildcards ’*’ und ’?’ sind auch vorhanden. Die ausführliche Suchseite lässt in einem Feld direkte Anfragen in der Suchsprache zu, bietet aber auch eine vereinfachte Version in der die Besucher bis zu vier Begriffe in ein Formular eintragen können.

Die Anmeldung einer Arbeit fragt die Din- ge ab die dann auch in den Auflistungen ste- hen: Titel, Bemerkungen, Autoren und deren Email-Adressen, Seitenzahl, Keywords und Untergebiet. Der Abstract kann dort direkt in ein Textfeld eingegeben werden. Bei der An- meldung muss angegeben werden wie viele Dokumente hochgeladen werden sollen. Da es als unhöflich gelten dürfte, mit sinnlosen Da- ten eine Anmeldung vorzutäuschen um her- auszufinden was nach dem Absenden der An- meldung folgt, endete die Erforschung von ROA damit.

Interna sind bei ROA wenige zu entdecken. Auf einer Informations-Seite über das Archiv wird gesagt das es mit PHP4 und MySQL läuft [roaa]. Wird ein Name nicht gefunden („meier“) wird nicht die erfolglose Anfrage der Suchsprache sondern der WHERE-Teil der SQL-Anweisung ausgegeben.

3.2 Der ROA-Spiegel in Marburg

Von ROA gibt es an der Universität von Mar- burg einen Spiegel [roamarburg]. Dieser bie- tet nicht dieselbe Funktionalität von ROA sondern die Dokumente mit einem vollständig eigenen Interface an. Der Grund dürfte dar- in liegen das ROA für seine Applikation Geld bezahlt hat und die Software nicht weiterge- ben darf oder will.

Die Listen bestehen aus einer Seite in der alle Nummern als Ordner aufgeführt sind. Das erinnert optisch an den Zugriff auf FTP- Server über einen Web-Browser. Über die Ordner-Symbole erreicht man die Beschrei- bungsseite zu der Arbeit welche die Doku- mente in ihren verschiedenen Ausprägungen und auch immer als gzip-Dateien verlinkt.

Die Suchfunktion beschränkt sich auf Au- toren, Titel, den Abstract und die Nummer.

Arbeiten können auf dem Spiegel nicht an- gemeldet werden. Also fehlt dieser Punkt. Es werden noch Links auf Hilfsprogramme und ein Hilfetext angeboten.

ROA oder der Spiegel scheinen Probleme zu haben da der Spiegel mit ROA-Nummer 438 endet wohingegen auf ROA schon über 500 Arbeiten liegen.

Interna sind nur bei der Suche aufgefal- len: Die URL enthält „config=htdig“ und im HTML-Text kommt „htdig“ vor. Das ist zwar kein Beweis aber ein Indiz, das htdig als Such- maschine benutzt wird.

3.3 Andere Archive

Es gibt noch weitere Archive mit wissen- schaftlichen Arbeiten. Die Homepages von Professoren sind wegen der geringen Zahl von Arbeiten keine gute Vorlage und wurden we- gen der geringen Erfolgsaussichten dort inter- essante Dinge für den Entwurf von PCA zu finden nicht untersucht. Auch handelt es sich dabei meist um Seiten die mit der Hand er- gänzt werden.

Stattdessen wurde das Angebot der Zeit- schriften die elektronisch über die Webseiten der Universitätsbibliothek [unibibz] zugreif- bar sind oberflächlich betrachtet. Dort werden den Universitätsangehörigen Teile oder das Gesamtangebot von zwanzig Verlagen elek- tronisch zugänglich gemacht.

Die meisten dieser Sites benötigen Javas- cript. Welche Möglichkeiten einem Besu- cher ohne Javascript entgehen (was nicht so schlimm wäre) oder nicht funktionieren (was der Normalfall ist) wird hier nicht weiter er- örtert. Die Beschreibung ist kurz und ober- flächlich weil sich die Sites doch schon ein- mal ändern (z. B. durch Verlagsübernahmen) und diese Sites eine Klasse größer als PCA bzw. ROA sind.

Organisiert sind die meisten Sites nach Themengebieten und darin dann nach den Zeitschriften, also hierarchisch. Suchfunktio- nen gibt es immer. Diese unterscheiden sich aber genauso wie das Design von Site zu Site. Suche über den kompletten Bestand ist üblich. Einschränkungen auf Themen oder Zeitschrif- ten werden auch oft angeboten, hierbei sind dann unterschiedlich gute Ansätze der Benut- zerführung zu erkennen.

Da es sich um elektronische Versionen von Zeitschriften handelt, sind diese wieder- um nach Ausgaben angeordnet. Thematische Sammlungen zu bestimmten Gebieten gibt es nicht, diese könnte man sich aber über Suche in Keywords selber generieren.

Die Dokumente liegen meist als PDF vor, Metadaten und Abstracts oder kurze Be- schreibungen werden über HTML und die Suchfunktionen angeboten. Auf eine Auflis- tung von Spezialitäten jeder Site wird verzich- tet.

3.4 CMS - Content-Management Systeme

PCA wurde in Gesprächen gelegentlich als CMS eingeordnet. Daher folgt hier eine Er- läuterung zu CMS.

Bei Websites die ständigen, relativ unifor- men Änderungen unterworfen sind, wird das einzelne Ändern von Seiten schnell aufwen- dig. Ein erster Schritt besteht darin, nur die Kerne der Seiten zu ändern und immer glei- che Dinge wie Rahmen, Kopf und Fußele- mente beispielsweise mit SSI-Anweisungen durch den Server einbinden zu lassen (4.4, S. 16). Sind viele Personen (Redakteure) betei- ligt bietet es sich an, diesen Prozess weiter zu automatisieren und zum Beispiel um Be- rechtigungssysteme zu erweitern und man er- hält ein Content-Management-System. Sites welche Nachrichten (Heise Newsticker [hei- senews]), oder andere gleichförmige, manuell zu pflegende Informationen anbieten arbeiten üblicherweise mit solchen Systemen. Damit können Redakteure Artikel oder Nachrichten Verwalten, per Web-Frontend eingeben oder hochladen. Diese Artikel werden dann auto- matisch in das vorhandene System eingebun- den und z.B. Auflistungen (neueste Nachrich- ten, neueste Testberichte) um den neuen Arti- kel oder um eine Headline und einen Link auf den Volltext ergänzt.

Bei PCA sind die zu verwaltenden Inhal- te einerseits die zu archivierenden Dokumen- te, andererseits die Metadaten die den Inhalt der anzubietenden Seiten darstellen. Bei CMS sind die zu verwaltenden Inhalte meist nur Texte und deren Metadaten. Dokumente zum Download sind damit eher selten gemeint. Die Suchfunktionen sind nach den Inhalten des CMS ausgerichtet. Nachrichten-CMS durch- suchen meist den Volltext der Nachrichten. Bei IMDB [imdb] kann nach Regisseuren, Schauspielern, Filmtitel usw. gesucht werden. Die der Aufgabenstellung von PCA ähn- lichsten CMS sind Download-Archive wie beispielsweise Tucows.com [tucows] oder das Heise-Shareware-Archiv [heisesoft]. Dort sind Programme in Kategorien eingeordnet und mit kurzen Beschreibungen versehen. In 7.4 (S. 84) wird eine alternative Implemen- tierung von PCA mittels CMS vorgeschlagen. Für wissenschaftliche Arbeiten ist mir kein frei erhältliches Archivsystem bekannt aber das man nichts findet heißt nicht das es nichts gibt.

3.5 PCA im Vergleich zu den betrachteten Systemen

Die statischen HTML-Seiten von PCA ähneln ROA von Struktur und Inhalt. Diese wurden von Professor Plag zur Verfügung gestellt.

Die Suchfunktionen wurden einfacher ge- staltet (5.7, S. 48). Die Auflistungen sind ähnlich. Eine Kompression der Daten wur- de als wünschenswert angesehen jedoch nicht durchgeführt (7.2, S. 83).

Der Marburger Spiegel ist nicht sinnvoll mit PCA vergleichbar. Dasselbe gilt für die Zeitschriften-Archive welche in einer größe- ren Liga spielen und anders strukturiert sind. Bei PCA ist eine übergeordnete Struktur noch nicht nötig. Bei ROA könnte das angesichts 500 Arbeiten Sinn machen.

4 Auswahl der verwendeten Basistechnologien

Im Kapitel 2 ging es darum, was vom Auftraggeber gewünscht war. Dort wurden technische Dinge meist nur enthalten wenn deswegen der Auftraggeber gefragt werden musste oder gefragt wurde um potentiell über- flüssige Arbeit zu vermeiden.

Dieses Kapitel stellt die Entwurfs-Ebene zwischen Aufgabenstellung und Detailpla- nung dar. Hier geht es um die Entscheidungen die (meist) vor der Implementierung getrof- fen wurden und alle, viele oder zentrale Teile des Systems betreffen und damit einen großen Einfluss auf die weitere Planung haben.

Zunächst werden Entwurfsmethodiken be- handelt und danach allgemeine Ziele für die Entwicklung dargelegt. Anschließend folgen Architekturen für oder betreffend den Web- server, die Datenhaltung (4.5, S. 17) und die verwendete Programmiersprache (4.6, S. 21).

In den Abschnitten 4.7 (S. 28) und 4.8 (S. 28) gibt es keine Basistechnologien auszuwählen. CGI (4.8, S. 28) wird ausführlicher dargestellt da es zur Interaktion zwischen dem Benut- zer (Besucher, Verwalter und Anmelder) und dem System dient und auf die Programmie- rung entscheidenden Einfluss hat.

In dieser Arbeit wird darauf verzichtet so zu tun als wäre das Resultat hier noch nicht bekannt. Daher wird, wo es passend erschien, gelegentlich auch mit ein paar Worten auf die Realisierung eingegangen. Auch werden Tei- le der Aufgabenstellung (2, S. 3) kurz wieder- holt anstatt mit dauernden Verweisen die Les- barkeit und das Verständnis zu erschweren.

Bei der Planung konnte aus einem großen Reservoir von Möglichkeiten ausgewählt wer- den weil einerseits keine Vorgaben bestanden und andererseits das Angebot recht groß ist. Auch wenn dieses Kapitel einige Möglichkei- ten für bestimmte Zwecke vorstellt gibt es oft noch weitere wie z. B. kommerzielle CMS- Systeme oder andere Skript-Sprachen und Möglichkeiten die aus irgendwelchen Grün- den nicht allgemein bekannt sind und somit aus Unkenntnis nicht in Planungen einbezo- gen wurden.

In dieser Arbeit geht es auch im die Be- gründung der Entscheidungen zur Konstruk- tion eines guten Systems was aus Aufwands- gründen aber oft nicht immer möglich ist. Im Rahmen von Begründungen werden Sachver- halte und andere Dinge oft durch Zusatzinfor- mationen im Zusammenhang dargestellt auch wenn diese dann doch nicht für PCA ausge- wählt wurden.

Meist nicht dargelegt werden build-or-buy - Entscheidungen: Wenn selber programmiert wurde (b uild), war kein passendes Angebot bekannt, wenn vorhandene Systeme benutzt wurden (b uy) wurde selber Programmieren als zu aufwendig angesehen. Beispiel: Ver- wendung von Parse::RecDescent in 6.4 (S. 73).

4.1 Entwurfsmethodik

Nachdem man weiß, was man machen soll, sollte man bei komplexeren Projekten ent- scheiden nach welcher Methode man vorgehen will.

Das Phasenmodell (Wasserfallmodell) der klassischen Software-Technik besteht aus den Phasen Analyse und Definition, Entwurf, Ko- dierung und Modultest, Integration sowie Ein- satz sowie Wartung und Pflege wobei War- tung und Pflege in der Praxis den größten An- teil der Arbeit darstellt, in den Darstellungen aber unter „sonstiges“ läuft (weiteres in [kel- ter2001a]).

Die Anforderungen wurden in 2 (S. 3) be- sprochen. Die Definition erfordert oft schon eine grobe Systemarchitektur da für den Ver- trag mit dem Kunden eine Kalkulation zu er- stellen ist und dazu die Aufwände schon abge- schätzt werden müssen. Die Festlegung die- ser groben Systemarchitektur erfolgt in die- sem Kapitel durch die Auswahl der zu ver- wendenden Technologien. Daher der Name dieses Kapitels. Beim Entwurf wird eine Ar- chitektur entwickelt und das System in Mo- dule und deren Schnittstellen zerlegt. Module sollen von einer Person in unter einem Monat erstellt werden können.

Auch wird in [kelter2001b] darauf hinge- wiesen das diese Stufen nicht klar zu trennen sind und das Phasenmodell nicht strikt nach Lehrbuch durchzuhalten ist. Argumentationen der Form „X machen wir so, deswegen wur- de so implementiert woraus sich ergab das für Teilfunktion Y folgendes entschieden werden musste ...“ sind im Phasenmodell nicht mög- lich da streng Top-Down geplant wird. Sol- che Argumentationen und gegenseitige Inter- dependenzen tieferer Teilsysteme und deren Auswirkungen auf höhere Systeme wären bei einer korrekten Dokumentation der Beweg- gründe für die konkrete Implementierung nö- tig. Anders gesagt: Die Aspekte aus 5 (S. 39) und der Implementierung (6, S. 69) sind sehr engmaschig verzahnt und gehen fließend in- einander über.

Das Phasenmodell unterstellt das nach der ersten Aufgabenbeschreibung das Problem analysiert wird (Analyse beim Kunden und Gespräche mit dessen Mitarbeitern), nach Auftragserteilung alles klar ist und losgelegt werden kann. Das über das System nachge- dacht wird und dem Auftraggeber dann Al- ternativen vorgestellt werden dürfte bei klei- nen Systemen eher der Realität entsprechen. Auch wissen Kunden nicht immer genau was sie wollen und die Aufgabenstellung muss angepasst werden. Speziell bei stark inter- aktiven Systemen (Online-Shops) ist direktes Feed-Back produktiver als sklavisches Fest- halten am Phasenmodell. Bei großen Syste- men sind viele Dinge von außen festgelegt wodurch beispielsweise eine Auswahl einer Datenbank gar nicht erst erfolgen muss. Man- che Dinge werden auch durch die Entwick- ler festgelegt die oft nicht alle Möglichkeiten in Betracht ziehen sondern einen engeren Fo- kus beispielsweise bei der Auswahl von Da- tenbankherstellern^[1] haben.

Korrekterweise müsste ein Teil der Software-Projekte unter Wartung und Pflege eingestuft werden. Auch wenn „Planung eines Onlineshops“ den Eindruck eines neuen Projektes macht, ist es in Wirklichkeit

„nur“ die Anbindung an die vorhandenen Systeme (Lagerverwaltung, Bestellwesen, Kundendaten) und Erweiterung derselben (Produktinformationen und Bilder für den Onlineshop). Ein anderer Teil der Projekte wäre besser mit „Konfiguration“ existierender Produkte beschrieben. Alles neu zu Program- mieren ist meist zu aufwendig, also werden beispielsweise Teile des Onlineshops für den

letzten Kunden auch beim nächsten Kunden mitbenutzt und ggf. erweitert. Bei größeren Systemen (SAP, Navision, Oracle eBusiness Suite, Siebel und anderen) wird hauptsächlich konfiguriert und nur fehlende Funktionen werden durch eigene Entwicklungen ergänzt. Der letzten Teil des üblichen Produkt- Lebenszyklus, nämlich die Beseitigung von Software, kommt im Wasserfallmodell nicht einmal vor. Um ein neues System zu installie- ren sind aus den alten Systemen die wertvol- len Daten (Kundendaten, Inventarlisten und alles was nicht so einfach neu eingegeben werden kann) zu entnehmen und vielleicht auch im System definierte Arbeitsabläufe zu übernehmen.

Inzwischen gibt es andere Modelle die evo- lutionäres Vorgehen, kurze Entwicklungszy- klen oder schrittweise Entwicklung von Tei- len zusammen mit dem Auftraggeber bes- ser unterstützen sollen. Wenn man es in ei- ne Schublade einordnen müsste, wäre kom- ponentenbasierte Entwicklung eine passende Bezeichnung da gezielt ausgesucht wurde was verwendet werden kann und wie es zusam- mengebaut werden soll. Der Eigenanteil der Programmierung war trotzdem sehr hoch.

Das Phasenmodell ist gut für Batch- Aufgaben: Input einlesen, transformieren, Output ausgeben. Dort sind die klassischen Tätigkeiten eines Programmierers (Daten- strukturen entwickeln, geschickte Program- mierung) angesiedelt. Als nächstes kommen interaktive Anwendungen die gerne objektori- entiert entwickelt werden. Dabei entsteht oft ein Netzwerk von Objekten die miteinander kommunizieren. UML ist zum Entwurf von so etwas ausgelegt. Bei Web-Applikationen (und auch schon im Intranet) dürfen diese Objekte einander nicht mehr trauen da sie auf verschiedenen Rechnern laufen. Das wirkt sich auf das gesamte System und dessen Pla- nung aus und wird vermutlich noch nicht aus- reichend in Entwicklungsmodellen beachtet.

Diese Problematik wird noch einmal in 5.13 (S. 57) dargelegt.

Nachdem klar war, was gewünscht wurde, wurden die Dinge die im Rest dieses Kapitels erläutert werden geplant. Anschließend fand die Entwicklung aber evolutionär unter Ein- beziehung des Auftraggebers und ohne kon- krete Entwurfsmethodik statt. Das System ist so klein das dies (und speziell stark bürokra- tisierte Methoden) einen unnötigen Verwal- tungsaufwand bewirkt hätten. In kommerzi- ellen Projekten wo man sich beispielsweise rechtlich absichern muss und auf Entwickler- und Kundenseite vorhandene Netzwerke von Systemen und Know-how existieren, hätte die Entwicklung anders ausgesehen.

4.2 Generelle Ziele

Knapp zusammengefasst waren generelle Vorgaben Korrektheit, Vollständigkeit, Si- cherheit und Zukunftssicherheit.

„Korrektheit“ bedeutet hier, korrekten Co- de zu schreiben womit meist die Implemen- tierung gemeint wird, aber auch, keine Ein- schränkungen zu machen oder Scheinlösun- gen zu implementieren die erst bei einer grö- ßeren Anzahl eingestellter Arbeiten oder hö- heren Besucherzahlen auffallen. „Mehr als 99 Arbeiten geht nicht und muss extra bezahlt werden“ sollte es bei PCA nicht geben und es sollte keine unnötigen Einschränkungen ge- ben. Bei Planung der Vorlagen (5.3, S. 42) und spezieller der Anmeldeformulare sowie der Speicherung der Metadaten ist man schnell versucht, die Anzahl von Elementen zu be- schränken indem beispielsweise fest fünf Au- torenfelder in das Anmeldeformular eingetra- gen werden. In Anlehnung an Forrest Gump:

„Beschränkt ist, wer beschränkte Arrays be- nutzt“. Skriptsprachen wie Perl allozieren Da- ten sowieso dynamisch und Arrays können dynamisch wachsen und schrumpfen. Aber auch in C ist es beispielsweise problemlos möglich mit realloc() Arrays dynamisch zu erweitern^[2]. Ob Array-Grenzen dynamisch sind oder fest einkompiliert sind ist für die Überprüfung derselben egal. Ein wesentliches Hindernis bei der Erweiterung von Softwa- re dürften einprogrammierte Beschränkungen sein die oft nicht nötig sind. PCA hat keine Beschränkungen dieser Art.

„Robustheit“ ist ein spezieller Aspekt der Korrektheit. Abstrakt formuliert geht es dar- um das das System noch läuft, wenn sich die Umgebung (in weitestem Sinne) ändert. Wenn ein Programm heute läuft, tut es das morgen oder in zwanzig Jahren vielleicht nicht kor- rekt. Ebenso läuft es vielleicht nur am 29. Fe- bruar nicht korrekt weil der Februar mit 28 Tagen in irgendeiner statischen Tabelle steht. Diese Beispiele sind klar als Fehler einzustu- fen. Zur Vermeidung von Fehlern ist es sinn- voll, vorhandene Module zu benutzen wenn diese gängig genug sind, um annehmen zu können das sie besser sind als selbstgeschrie- bener Code für diesen Zweck.

Keine „richtigen“ Fehler sind Dinge wie der Wechsel des Betriebssystems, eine neue Version der verwendeten Skriptsprache oder der Umzug in ein neues Home-Verzeichnis. Das ließe sich als Robustheit gegen Änderun- gen bezeichnen. Um diese Robustheit zu erhö- hen sollten möglichst wenige Annahmen über das verwendete System fest im Code stehen, und wenn dann sollten diese zentral zu än- dern sein. Die Lage von beispielsweise den HTML-Seiten, Dateiordnern und anderer Pfa- de ist konfigurierbar und an einer zentralen Stelle abgelegt um bei Änderungen nicht im Quelltext Pfadnamen suchen zu müssen. Ei- ne zentrale Funktion baut Pfadnamen zusam- men und liefert diese zurück(6.9, S. 80). Das erhöht durch die eingezogene Abstraktions- schicht die Wartbarkeit und Kontrolle deutlich und führt auch dazu das ein System ein- facher bei anderen Kunden installiert wer- den könnte. Dieses Dokument ist relativ lang. Das rührt teilweise daher das viele Alterna- tiven beschrieben werden in denen ein CGI- Skript leben kann auch wenn PCA momen- tan in einer anders konfigurierten Umgebung läuft. Man kann sich auf nichts verlassen und muss mit allem rechnen. Morgen könnte der Webserver anders konfiguriert sein oder PCA muss aus irgendeinem Grunde umziehen. Es war nicht Sinn der Entwicklung, ein System zu konstruieren das bei kleinsten Änderungen weitere Programmierung erfordert.

Eine andere Form von Robustheit betrifft das Verhalten wenn Dinge nicht korrekt vor- gefunden werden (Dateien fehlen, Ordner sind nicht vorhanden). Sollen diese korrigiert werden oder das System abbrechen oder der Verwalter beispielsweise per Email informiert werden? So etwas wurde im Einzelfall ent- schieden.

„Vollständigkeit“ bedeutet, die geforderten Anforderungen zu erfüllen, sinnvoll zu erwei- tern oder, wo nötig, anzupassen. Was nicht er- füllt wurde findet sich in 7.2 (S. 82).

Meist geht es darum was man will (2, S. 3), welche Möglichkeiten man dazu hat und welche Einschränkungen diese Möglichkei- ten mit sich bringen und danach erst darum, es skalierbar, effizient und sicher zu machen. Viele Projekte beschränken sich vermutlich darauf etwas abzuliefern das so aussieht als ob es das tut was der Kunde will und es meist wohl auch halbwegs tut. Effizienz und Sicher- heit kommen nachrangig und werden oft nur hinzugeflickt wenn es Probleme gibt. Wer ein System schlecht geplant hat, wird auch Repa- raturen nicht korrekt durchführen und häufig nur die Symptome bekämpfen und das Pro- blem nur scheinbar lösen. Sicherheit erfordert einerseits exaktes Wissen über das was im System abläuft und wie es abläuft um das Sys- tem in sich sicher zu halten (5.13, S. 57) aber auch Fachwissen und Beobachtung der aktu- ellen Sicherheitslücken („Apache 1.xx hat ein Sicherheitsloch“) um nicht durch die benutz- te Software Löcher einzubauen. Auf Ersteres wurde geachtet, Zweiteres unterliegt im We- sentlichen den Administratoren des Systems wird aber durch Verwendung selber instal- lierter Software unterminiert die wiederum schnellere Implementierung und meist auch höhere Qualität vielleicht aber keine höhere Sicherheit mit sich bringt.

„Zukunftssicherheit“ bezieht sich auf die Robustheit gegen Änderungen aber auch auf Wachstum. Beim gesamten Projekt wurde immer an Effizienz im Sinne von „schnell und einfach zu Programmieren“ aber auch

„schnelles Programm“ gedacht. Das System soll höhere Besucherzahlen wegstecken kön- nen ohne neu geschrieben werden zu müssen. Da ROA das Vorbild war wurde mit 500 Ar- beiten geplant.

Erweiterbarkeit oder offene Schnittstellen sind bei so einem kleinen System nicht nötig. Trotzdem wurde nichts getan um bewusst Er- weiterungen zu erschweren oder den Zugriff auf die Daten zu erschweren. In einem kon- kreten Fall hängt es aber immer von den neu- en Wünschen ab wie gut und einfach das Sys- tem anzupassen ist. Wenn beispielsweise die Daten genau anders organisiert sind als wie sie für eine schnelle Erweiterung gebraucht werden ist das zwar unschön, kann im Voraus aber schlecht vorausgesehen werden.

4.3 Rahmenbedingungen

Die personellen Rahmenbedingungen sind schnell beschrieben: Jeder sollte Arbeiten an- melden und hochladen können. Die Verwal- ter sollten die Arbeiten dann einstellen. Vom Informatik-Aspekt haben Personen hier nichts verloren. Für eine korrekte Planung sind aber die Kenntnisse und die Motivation der Benutzer einzubeziehen um beispielsweise die In- teraktionen planen zu können. Trotzdem wird dieser Aspekt im weiteren nicht beleuchtet. Bei den Verwaltern wurde unterstellt das die- se ein Interesse haben, das System effizient zu benutzen und auch bereit sind, Anleitungen zu lesen. Bei Besuchern können keine Vorkennt- nisse vorausgesetzt werden. Anmelder haben ein Interesse an der Anmeldung, kennen das System aber nicht und sollten daher gut bei der Anmeldung unterstützt werden. Beispiel: Die Fehlermeldungen bei fehlenden Anmel- dedaten sollten so sein das der Anmelder da- mit etwas anfangen kann und nicht darauf ver- zichtet, seine Arbeit zur Verfügung zu stellen. Die technischen Rahmenbedingungen wa- ren zu Beginn der Arbeit nicht klar. Daher wurde so geplant das keine hohen Anforde- rungen an den Webserver gestellt wurden. Un- terstellt wurde von Anfang an das der Ser- ver unter Unix laufen würde aber nichts getan um eine Implementierung unter Windows zu erschweren. Das System läuft jetzt auch un- ter Windows XP in Verbindung mit Cygwin, Windows Apache und Perl.

Im Laufe der Planungen bekam PCA einen Webserver beim AVMZ. Es handelte sich um einen normalen Apache-Webserver mit dem Perl-CGIs und PHP möglich sind. Es ist ein shell-Account vorhanden d.h. man kann vor Ort arbeiten, testen, Perl-Module oder Skripte installieren und schreiben. Bei vielen Provi- dern lassen sich nur per FTP Skripte hochla- den. Diese können auch getestet werden, das ist aber umständlicher.

Einschränkungen bezüglich des Platten- platzes gab es nicht. Es gibt einen Zugang per FTP welcher von den Verwaltern zum Hochladen der überprüften Arbeiten, Vorla- gen und geänderter HTML-Seiten benutzt werden kann. Bei dem Server handelt es sich um einen virtuellen Webserver d. h. der Web- server liefert in Abhängigkeit von der ange- forderten URL auf derselben(oder verschie denen) IP-Nummer auf einer Maschine unter- schiedliche Seiten aus.

CGI-mäßig ist eine Konfiguration anzutref- fen die bei Universitäten oder innerhalb von Firmen, bei kommerziellen Providern so aber nur selten oder mit weiteren Einschränkun- gen anzutreffen sein dürfte: Der Server startet jedes CGI unter derselben Unix-UserID. Das wird in 5.13.2 (S. 60) weiter ausgeführt.

4.4 Anforderungen an den Webserver

Auf eine allgemeine Beschreibung was ein Webserver tut wird hier verzichtet sondern nur speziellere Dinge beschrieben. Auch wird im- plizit immer Apache als Webserver unterstellt wenn nichts anderes da steht.

Da keine Java-Applikationen gewünscht waren und die Inhalte in Webbrowsern dar- stellbar sein sollten ergab sich das die Kom- munikation mit den Besuchern über HTML bzw. CGI erfolgen sollte. Einige Seiten sollten statisch sein und würden nur gelegentlich ge- ändert werden. Andere Seiten jedoch sind bei Einstellen einer neuen Arbeit zu aktualisieren. Das Aktualisierungsintervall hat eine Auswir- kung darauf ob die Seiten statisch auf dem Server liegen können oder bei jedem Aufruf neu generiert werden sollen oder müssen. Da- bei sind die Grenzen fließend. Mögliche Ab- stufungen und die dafür nötigen technischen Mindestvoraussetzungen sind beispielsweise: Statische Seite die sich selten ändert und mit der Hand aktualisiert wird (kann jeder Web- server), Seite die nur einheitliche Elemen- te (Header, Footer, Datum der letzten Ände- rung) immer an denselben Stellen einbindet (.shtml-Dateien, SSI) und personalisierte Sei- ten oder Seiten welche interaktiv Inhalte er- zeugen (PHP, JSP, CGI, ASP).

Die Suchfunktionen müssen interaktiv aufgrund der Suchanfrage zusammengestellt werden. Ebenso ist die Anmeldung einer Ar- beit ein interaktiver Prozess wenn die Daten interaktiv überprüft werden sollen. Das gän- gige System dazu ist CGI welches ausführ- licher in 4.8 (S. 28) erklärt wird. Eine ein- fachere Implementierung hätte sich ergeben wenn man einfach die Anmeldedaten per For- mular abgefragt und mit einem Mail-CGI wie formmail.pl (oder besser dessen sicheren Alternativen) an die Verwalter schicken wür- de. Diese könnten lokal auf einem Windows- PC die Daten in z. B. Excel eintragen und per VisualBasic oder Windows Scripting Host die HTML-Seiten erzeugen und hochladen. Auch dies war nur ein Beispiel um die zahlreichen Möglichkeiten. anzudeuten.

Das Hochladen der Arbeiten sollte anfangs über einen anonymen FTP-Zugang erfolgen. Da es aber per CGI implementiert werden konnte, wurde darauf verzichtet.

Für die Webseiten wurde beschlossen, die- se statisch auf dem Server liegen zu lassen und nur bei Bedarf, also dem Einstellen ei- ner neuen Arbeit, neu auszurechnen. Die Sei- ten ändern sich nicht häufig genug das sie bei jedem Zugriff neu berechnet werden müss- ten. Statische Seiten benötigen keine zusätz- liche Rechenzeit für Berechnungen oder das Einbinden weiterer Dateien so das sie kein li- mitierender Faktor für höhere Besucherzahlen sind.

Mit der konkreten Implementierung könn- ten auch .shtml- oder PHP-Seiten erzeugt und abgelegt werden. .shtml-Seiten bezeich- nen üblicherweise SSI-Seiten welche Anwei- sungen enthalten um beispielsweise das aktu- elle Datum, die aktuelle Seite oder das letzte Änderungsdatum einer Webseite dynamisch anzuzeigen. Auf dem Server liegen die Sei- ten mit den SSI-Anweisungen welche durch den Server ausgewertet werden und der Besu- cher erhält dann die verarbeiteten Seiten. Die mächtigeren Möglichkeiten von SSI sind das Einbinden von HTML-Schnipseln um bei- spielsweise einheitliche Header und Footer auf jeder Seite anzuzeigen oder auch das Ausführen von CGI-Skripten und Einbinden deren Output. Durch Verwendung von #if erhöhen sich die Möglichkeiten noch ein- mal deutlich: In Abhängigkeit aller bekann- ten Daten (Referer, Browser-Name, Aktuel- le Seite, CGI-Parameter,...) können die Sei- ten auf unterschiedliche Weise zusammen- gestellt werden. Das System ist somit sehr mächtig [ct2001a] was aber wenig bekannt ist. [selfhtml] beispielsweise kennt nur die #include-Anweisung und „unterschlägt“ die Möglichkeiten durch #if.

Client-Side-Includes wären beispielsweise sehr nützlich um immer gleichartige Elemen- te nicht ständig neu laden zu müssen und so- mit die Ladezeiten sowie die vom Server ver- sandte Datenmenge (und damit den dafür zu zahlenden Betrag) zu verringern. Daran hat bei der HTML-Definition allerdings niemand gedacht weswegen Modem-Benutzer sich oft mit langen Ladezeiten herumärgern müssen. Teilweise ließe sich das mit XML und XSLT und/oder Javascript simulieren. Das erfordert aber von den Besuchern neuere Browser. Da PCA explizit auch für ältere Systeme erreich- bar sein sollte, wurde darauf verzichtet.

Zur Zeit werden oft noch Frames für so etwas wie Client-Side-Includes benutzt wel- che den Nachteil haben das die aktuelle Kom- bination von Frame-Elementen nicht als Le- sezeichen abgelegt werden kann. Daher wer- den Webseiten die Frames verwenden nicht oder nur eingeschränkt auch nicht von Such- maschinen indiziert werden [heise2002e]. Da PCA keine große Website mit vielen Unter

4.5 Datenhaltung

Die Daten für die einzelnen Arbeiten bestehen aus den Metadaten (Titel, Autoren, ...), dem Abstract und den Dokumenten.

Die Dokumente könnten als BLOB in ei- ner SQL-Datenbank gehalten und per CGI bei Anfrage den Besuchern ausgeliefert (zum Download angeboten) werden. Wesentlich einfacher ist es, die Dateien ganz normal in Verzeichnissen zu halten. Der Webserver be- arbeitet dann die Zugriffe und liefert die Do- kumente genauso wie HTML-Seiten aus.

Das gleiche gilt für die Abstracts. Aller- dings sollten diese auch als Inhalte in den Seiten zu den einzelnen Arbeiten stehen wes- halb die Abstracts eine hybride Stellung als Download-Dokumente und Daten einnehmen können. Bei ROA hingegen führen die mit

„abstract“ bezeichneten Links auf die Über- sichtsseite der jeweiligen Arbeit (3.1, S. 7).

Die Metadaten zu einer Arbeit sind der Titel, die Seitenzahl, die Autorennamen und deren Email-Adressen, das Erscheinungsda- tum, Bemerkungen und Keywords (Tabelle 5.1, S. 42). Die PCA-Nummer identifiziert die Arbeiten eindeutig. Es folgt ein Überblick über die verwendbaren Datenspeichermetho- den. Die folgenden Möglichkeiten beschrei- ben gängige Verfahren. Kombinationen da- von oder andere Methoden sind auch möglich. Nicht diskutiert werden Objektorientierte und weitere Nicht-relationale Datenbanksysteme.

4.5.1 SQL-Datenbanken

SQL ist der gängige Standard zur Abfrage re- lationaler Datenbanken. Ein RDBMS verwal- tet mehrere^[3] Datenbanken, diese wiederum enthalten mehrere Tabellen. Ergebnisse von Abfragen sind immer Tabellen welche aus Se- lektion von Spalten und Zeilen von Tabellen seiten darstellt wurde über solche Dinge nicht

weiter nachgedacht.

3„mehrere“ bedeutet hier „eine, mehrere oder keine“.

und Kombination mit anderen Tabellen ent- stehen. In statischen Tabellen können Zeilen eingefügt, gelöscht oder abgeändert werden. Tabellen haben Zeilen und Spalten die für je- des Element gleich definiert sind (VARIANTs oder UNIONs wie in Pascal oder C gibt es nicht). Da die Daten pro Spalte einheitlich sind, kann über Indizes effizient darauf zuge- griffen und auch Kombinationsabfragen (Alle Kunden die Weihnachten für mehr als 200 Eu- ro bestellt haben) über Tabellen hinweg sind für große Datenmengen möglich.

Vorteile:

- Bei vorausschauender Programmierung kann das RDBMS ohne Änderungen in den SQL-Anweisungen ausgetauscht werden. Das klappt nur bei Verwen- dung „normaler“ SELECT-, INSERT- und UPDATE-Anweisungen. CREATE TABLE und andere administrative Be- fehle sind bei jedem RDBMS anders sobald unübliche Datentypen (Bitfelder, Boolesche Werte, BLOBs ) verwen- det werden sollen. Für Kundendaten, Adressen und Bestellinformationen rei- chen die einheitlichen Datentypen aber aus. Dadurch können Server ersetzt wer- den oder Test- und Entwicklungssysteme mit einem Server eines anderen Herstel- lers kommunizieren als das Produktiv- System.
- Das RDBMS koordiniert parallele Zu- griffe. Transaktionen ermöglichen kor- rektes „gleichzeitiges“ Ändern und Le- sen mehrerer Tabellen ohne das ande- re Prozesse auf inkorrekten Zwischen- zuständen arbeiten. CGI-Skripte welche SQL-Server benutzen unterliegen damit nicht dem technischen sondern „nur“ dem semantischen Parallelitätsproblem (4.8.3, S. 36). Alle anderen hier vor- gestellten Systeme müssen gleichzeiti- gen Zugriff einplanen und selber durch Locking der Dateien oder sonst irgend- wie organisieren.
- Für die gängigen RDBMS gibt es für die gängigen Programmiersprachen Zu- griffs- und Abfragemöglichkeiten auf die Daten. Beispiele: DBI bei Perl, JDBC bei Java, ODBC bei Windows. Meist wird mit einem Handle auf die Datenbank ge- arbeitet über den SQL-Abfragen an das RDBMS gesendet werden. Das Ergebnis sind Tabellen die dann zeilenweise abge- arbeitet werden können.
- Mit MySQL [mysql], PostgreSQL [post- gresql] und SAP DB [sapdb] existie- ren nicht nur für den privaten sondern auch für kommerziellen Einsatz kosten- lose SQL-RDBMS die für kleinere und große Projekte ausreichen. Oracle ist nur für den privaten Gebrauch kostenlos.
- Normale Dateien können durch einfa- ches Kopieren gesichert werden. Bei SQL hingegen muss der Datenbankin- halt extrahiert, gespeichert und im Not- fall wieder eingespielt werden. Mit shell- Skripten ist dies für MySQL möglich und daher als Vorteil aufgeführt. Die Mechanismen für anderen Datenbanken sind mir nicht bekannt.
- Zugriffe könnten über Usernamen und Benutzerpassworte gesichert werden. Mysql erlaubt es Rechte benutzerab- hängig auf Spalten einzuschränken. Andere Datenbanken können zusätz- lich zeilenorientiert Berechtigungen verwalten. CGI-Skripte enthalten meist nur einen Usernamen und Passwort da der Zugriff von aussen anonym erfolgt. Diese Eigenschaft ist eher für Unter- nehmensanwendungen in Intranets von Interesse.

Nachteile:

- Normalerweise muss ein SQL-Server be- trieben werden. Da die meisten Server einen Zugriff über Netzwerk erlauben, oder passend konfiguriert werden kön- nen, wäre „irgendein“ MySQL-Server auf „irgendeinem“ Rechner der Universi- tät für PCA ausreichend. Es gibt Systeme die ohne ständig laufenden SQL-Server auskommen. Ein Beispiel ist der Zugriff auf Access-Datenbanken (.mdb-Dateien) unter Windows mittels Microsoft-Jet- Treibern mit ODBC. Die Jet-Treiber können auch Excel-Dateien und ande- re Datenformate mit SQL-Befehlen bear- beiten. Das würde beispielsweise ermög- lichen die PCA-Daten in einer Excel- Tabelle zu halten, dort den Titel, die Autoren-Namen usw. einzutragen und dann mittels irgendeiner Skript-Sprache welche ODBC-Zugriffe ermöglicht die Daten weiterzuverarbeiten um z.B. die HTML-Seiten daraus zu generieren.
- Ein vorhandenes RDBMS auszutauschen erfordert einen gewissen Aufwand da jedes System für die kaum genorm- ten Verwaltungsfunktionen eigene Lö- sungen anbietet. Weil die kostenlosen RDBMS auch nicht immer den komplet- ten SQL92-Sprachumfang implementie- ren müsste man sich dann auf eine geeig- nete Schnittmenge beschränken was für SELECT, INSERT und UPDATE ein ge- ringes Problem darstellt wenn das Sys- tem nur als Datenlager für gängige SQL- Datentypen benutzt werden kann. Skrip- te können somit ohne große Änderun- gen laufen, administrative Tätigkeiten (Backups, Anlegen von Tabellen) erfor- dern Anpassungen. Wenn proprietäre Ei- genschaften eines RDBMS benutzt wur- den (Trigger, stored procedures, BLOBs, Bitfelder) oder ist der Wechsel mit hö- herem Aufwand verbunden. Auch wird für einen Wechsel Know-how über beide Datenbank-Systeme benötigt.

4.5.2 DBM-Dateien

DBM-Dateien enthalten KV-Paare und exis- tieren in verschiedenen Varianten: dbm war der Ursprung unter Unix. Dann gab es den Nachfolger ndbm, die GNU-Alternative gdbm sowie das freie BerkeleyDB (bsdDB) welches inzwischen mit den Versionen 3 und 4 eine sehr umfangreiche und über das ein- fache Abspeichern von KV-Paaren hinausge- hende Funktionalität anbietet. Eine Übersicht der Eigenschaften ist in Tabelle 4.1 (S. 20) ab- gebildet.

Nachteile von DBM-Systemen im Ver- gleich zu SQL-Datenbanken sind, das die Ver- waltung der Werte in den Zeilen dem Pro- gramm unterliegt welches das Packen und Entpacken erledigen muss. Auch sind kei- ne bequemen Zugriffsfunktionen, Selektionen und Verknüpfungen über mehrere Tabellen so wie in SQL möglich. Vorteile liegen darin das keine Server nötig sind und man alles selber in der Hand hat kann wenn man das will oder braucht. In Verbindung mit Perl lassen sich DBM-Dateien transparent als Hash anbinden (4.6.1, S. 23).

4.5.3 XML-Dateien

Wären die Daten komplizierter und hätten von vielen verschiedenen Programmen be- nutzt, im- oder exportiert werden müssen, wäre XML ein geeignetes Datenformat. Da- zu müssen Beschreibungsdateien (DTD) ge- schrieben werden was einen geringen Mehr- aufwand erfordert. Die Dateien sind von Men- schen gerade noch lesbar, sollten aber bes- ser nicht mit normalen Text-Editoren son- dern XML-Editieren bearbeitet werden um die Einhaltung des Formates nicht zu gefähr- den.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4.1: DBM-Systeme (nach perldoc AnyDBM_File)

Für alle gängigen Programmiersprachen existieren XML-Parser. Im Vergleich zu Text- Dateien bewirkt die Verwendung von Par- sern für so kleine Datenstrukturen einen deut- lich erhöhten Programmieraufwand beim Le- sen und Schreiben der Daten.

4.5.4 Text-Dateien

CSV- und XML-Dateien könnte man auch darunter fassen sind hier aber nicht damit gemeint weil das Lesen und Editieren ohne spezielle Programme potentiell fehleranfällig sind wie schon im letzten Abschnitt erläutert wurde.

CSV-Dateien enthalten einen Datensatz pro Zeile und die Elemente des Datensatzes sind durch bestimmte Trennzeichen (oft ’;’ oder Tabulator) getrennt. Beliebig viele Autoren könnten dadurch realisiert werden, das die- se am Ende der (dann beliebig viele Elemen- te haltenden) Zeilen gesammelt werden. Lan- ge Zeilen die jeweils alle Metadaten enthalten sind schlecht mit der Hand zu editieren. Daher konnten sich CSV-Dateien in den Planungen auch nicht durchsetzen. Sie wären als Trans- ferformat für den Import und Export in Excel einsetzbar aber die Planung gingen in eine an- dere Richtung.

Text-Dateien haben den Vorteil mit der Hand editierbar und bei Problemen einfach lesbar zu sein so lange die Datenformate nicht kompliziert sind. Auch erfordert dies, das die Werte mit entsprechenden Bezeichnungen versehen werden um nicht „Zeile 12 enthält den Vornamen, Zeile 13 den Nachnamen...“ als Formatbeschreibung zu haben.

Ein Nachteil ist, das komplexere Datenfor- mate und Binärdaten eher schlecht darin ab- zulegen sind oder man sich sinnvolle Mecha- nismen dafür ausdenken und vielleicht auch implementieren muss. Wenn Objekte seriali- siert und gespeichert zu werden ist auch so et- was nicht mehr editierbar und man kann ge- nauso gut oder besser noch Datenbanken oder DBM-Dateien dafür nehmen.

4.5.5 Die Entscheidung

Ein weiterer Grund gegen ODBC-Lösungen (Access, Excel, ...) unter Windows war das Ziel, Brüche beim Datenfluss (Anmeldung auf Web-Server, Daten unter Windows-Excel, HTML-Seiten auf Webserver) zu vermeiden.

Damit ergab sich dann die nachfolgen- de Entscheidung für die Datenhaltung. Wie schon in 1 (S. 2) angedeutet gab es keine Rahmenbedingungen die diese Entscheidung erzwungen hätten und die anderen Möglich- keiten wären relativ indifferent gewesen weil auch sie Vor- und Nachteile gehabt hätten.

Die Dokumente werden nicht in Daten- banken archiviert sondern liegen als norma- le Dateien in der Verzeichnisstruktur (5.2, S. 42) des Web-Servers. Die eigentlichen Daten werden als KV-Paare pro Arbeit in normalen Textdateien abgelegt (5.1, S. 41).

DBM-Dateien werden als Datenlager für die Suchfunktionen benutzt um alle Daten schnell durchsuchbar beisammen zu halten (6.4, S. 73).

4.6 Programmiersprache

Da das System vermutlich unter Unix laufen würde und das häufig für CGI-Skripte benutz- te Perl vorhanden sein würde und ich wuss- te das die Aufgabenstellung damit erreichbar war, beschloss ich, das Projekt in Perl un- ter Zuhilfenahme von shell-Skripten durchzu- führen. Eine echte Auswahl von Alternativen fand nicht statt.

Ruby [ruby] und ASP werden nicht be- trachtet. Stattdessen wird länger auf Perl und kurz auf Python, PHP und Java eingegangen. Alle genannten Sprachen außer ASP sind kos- tenlos und relativ frei auf den meisten Platt- formen (Unix-Derivate und Windows) verfüg- bar. Sie sind alle proprietär in dem Sinne das eine zentrale Stelle die Sprache definiert und weiterentwickelt ohne jemanden um Erlaub- nis fragen zu müssen. Bei C hingegen wel- ches einen Standartisierungsprozeß durchlau- fen muss, passiert nicht viel außer das alle Jahre neue Mutationen (C++, Objective C, Ja- va und jetzt neu C#) entstehen welche (von Java und C# abgesehen) dann von verschiede- nen konkurrierenden Compileranbietern um eigene proprietäre Eigenheiten ergänzt wer- den. Für Programme die auf beliebigen Platt- formen laufen sollen ist der Ansatz von Perl, Python, Ruby, PHP und Java angenehmer da es dann meist an einem selber oder den ver- wendeten Modulen liegt wenn ein Programm auf einer anderen Plattform nicht läuft. Platt- formunabhängigkeit ist für die meisten Pro- grammierer aber momentan noch kein Ziel und ändert sich vielleicht erst wenn man die Skripte auch auf dem Handy oder PDA lau- fen lassen könnte wenn man vorrausschauend programmiert hätte.

Nach [heise2002a] sind Skriptsprachen für Inhouse und Projekt-Programmierung unter den iX-Lesern beliebt (siehe Abb. 4.1, S. 22).

4.6.1 Perl

Das Perl für die Aufgaben von PCA geeignet ist wird hier nicht explizit erläutert und ergibt sich gelegentlich aus dem Kontext in der De- tailplanung (5, S. 39) und der Implementie- rung (6, S. 69). Stattdessen wird die Sprache oberflächlich vorgestellt.

Der Name steht für „Practical Extraction and Report Language“ und weist auf die Her- kunft als Alternative zu sh/awk hin. Die Spra- che ist unter der Artistic Licence [pal] frei im Quelltext verfügbar und wurde von Larry Wall entwickelt der immer noch die Fäden in der Hand hält. Perl [perl] ist eine interpretierte Skript-Sprache die ein im Vergleich zu C be- quemes Umgehen mit Zeichenketten erlaubt. In C muss um jedes Byte (und immer eines mehr für die Null am Ende) gekämpft werden.

[...]

---

^[1]Es müsste korrekterweise „Bei der Auswahl des RDBMS“ heißen. Das ist unübliche Sprechart, da- her wird hier oft vereinfacht von „Datenbank- herstellern“ gesprochen. „Datenbank“ oder „Da- tenbanksysteme“ wird in dieser Arbeit weni- ger verwendet da es auch DBM-Dateien, SQL- Datenbanken, RDBMS,... bezeichnen könnte, im normalen Sprachgebrauch aber das bezeichnet was bei genauerer Terminologie mit „SQL- Datenbankanbieter“ bezeichnet werden müsste.

² Ähnlich der vector-Container-Klasse von Java.

³ „mehrere“ bedeutet hier „eine, mehrere oder keine“.