Download - Entwurf und Implementierung des ETHOC-Systems · Every thing has online content Diplomarbeit Entwurf und Implementierung des ETHOC-Systems Nikolaos Kaintantzis [email protected]

Every thing has online content

Diplomarbeit

Entwurf und Implementierungdes ETHOC-Systems

Nikolaos [email protected]

Betreut von: Jurgen Bohn und Michael RohsUnter der Aufsicht von Prof. Dr. Friedemann Mattern

Institut fur Informationssysteme, Fachgruppe Verteilte Systeme

Abgabe: 4. Marz 2002

Inhaltsverzeichnis

Zusammenfassung xi

1 Einleitung 11.1 Ubiquitous Computing . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Ziel dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Kapitelubersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Motivation 52.1 Beispiele fur online erweiterte Dokumente . . . . . . . . . . . . . 5

2.1.1 Veranstaltungshinweise . . . . . . . . . . . . . . . . . . . 62.1.2 Ankundigungen . . . . . . . . . . . . . . . . . . . . . . . . 72.1.3 Unterrichtsbezogene Dokumente . . . . . . . . . . . . . . 92.1.4 Weitere Dokumente . . . . . . . . . . . . . . . . . . . . . 10

2.2 Verallgemeinerung auf beliebige Gegenstande . . . . . . . . . . . 10

3 Technologien und Plattformen 133.1 Identifikationstechnologien . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1 Barcodes . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.1.2 Weitere Tagging-Systeme . . . . . . . . . . . . . . . . . . 16

3.2 Barcode-Leser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3 Klienten-Plattformen . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3.1 PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.2 Laptop . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.3 PDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.4 Mobiltelefon . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 Systemanalyse und -Anforderungen 214.1 Benutzungsszenarien . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1.1 Filmveranstaltung und drahtlose Kommunikation . . . . . 214.1.2 Vorlesung und Studenten-Raum . . . . . . . . . . . . . . . 224.1.3 Aktionen auf Kleinstrechner . . . . . . . . . . . . . . . . . 224.1.4 Annonce und Mobiltelefon . . . . . . . . . . . . . . . . . . 23

4.2 Autorenunterstutzung . . . . . . . . . . . . . . . . . . . . . . . . 234.2.1 Erstellungsprozess . . . . . . . . . . . . . . . . . . . . . . 234.2.2 Anderungsprozess . . . . . . . . . . . . . . . . . . . . . . 244.2.3 Autorbezogene Systemkomponenten . . . . . . . . . . . . 24

4.3 Benutzerunterstutzung . . . . . . . . . . . . . . . . . . . . . . . . 264.3.1 Vermittlungsprozess . . . . . . . . . . . . . . . . . . . . . 26

iii

iv INHALTSVERZEICHNIS

4.3.2 Benutzerbezogene Systemkomponenten . . . . . . . . . . 274.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5 Konzepte fur das ETHOC-System 315.1 Barcode-Erstellung . . . . . . . . . . . . . . . . . . . . . . . . . . 315.2 Objekt-ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.2.1 Hashwert als ID . . . . . . . . . . . . . . . . . . . . . . . 325.2.2 Globaler Zahler als ID . . . . . . . . . . . . . . . . . . . . 325.2.3 Tag-URI als ID . . . . . . . . . . . . . . . . . . . . . . . . 325.2.4 ETHOC-Tag als ID . . . . . . . . . . . . . . . . . . . . . 33

5.3 Varianten im Erstellungsprozess . . . . . . . . . . . . . . . . . . . 345.3.1 Webservice . . . . . . . . . . . . . . . . . . . . . . . . . . 345.3.2 Logischer lokaler Drucker . . . . . . . . . . . . . . . . . . 375.3.3 Logischer Online-Drucker . . . . . . . . . . . . . . . . . . 395.3.4 Varianten-Evaluation . . . . . . . . . . . . . . . . . . . . . 41

5.4 Varianten im Vermittlungsprozess . . . . . . . . . . . . . . . . . . 435.4.1 Online ID-Manager . . . . . . . . . . . . . . . . . . . . . . 435.4.2 Variante ID-Manager mit lokaler Komponente . . . . . . . 455.4.3 Variantenvergleich . . . . . . . . . . . . . . . . . . . . . . 47

5.5 Meta-Informationen . . . . . . . . . . . . . . . . . . . . . . . . . 475.5.1 Aktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.5.2 Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6 Design des ETHOC-Systems 516.1 XML-Strukturen und -Verarbeitung . . . . . . . . . . . . . . . . 516.2 Barcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526.3 ETHOC-Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526.4 Autoren-Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.4.1 Einstiegsseite . . . . . . . . . . . . . . . . . . . . . . . . . 536.4.2 Objekt-Erstellung und -Anderung . . . . . . . . . . . . . 546.4.3 Abstrakte Servlets . . . . . . . . . . . . . . . . . . . . . . 566.4.4 Servlet-Hierarchien . . . . . . . . . . . . . . . . . . . . . . 57

6.5 Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586.5.1 Zugriff auf die Datenbank . . . . . . . . . . . . . . . . . . 59

6.6 Benutzerseite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606.6.1 Lokale Komponenten . . . . . . . . . . . . . . . . . . . . . 616.6.2 Online-Komponenten . . . . . . . . . . . . . . . . . . . . 62

7 Implementierung 657.1 XML-Strukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.1.1 Virtuelle Gegenstucke . . . . . . . . . . . . . . . . . . . . 657.1.2 Modulkonfiguration . . . . . . . . . . . . . . . . . . . . . 667.1.3 Autoren-Werkzeuge . . . . . . . . . . . . . . . . . . . . . 66

7.2 Autorenportal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677.2.1 Einstiegsseite . . . . . . . . . . . . . . . . . . . . . . . . . 677.2.2 Autoren-Identifikation . . . . . . . . . . . . . . . . . . . . 677.2.3 Virtuelle Gegenstucke erstellen und andern . . . . . . . . 677.2.4 Datei-Upload . . . . . . . . . . . . . . . . . . . . . . . . . 687.2.5 Barcode-Erzeugung . . . . . . . . . . . . . . . . . . . . . . 68

INHALTSVERZEICHNIS v

7.3 Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687.4 Email-Verkehr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697.5 Benutzerportal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707.6 ETHOC-Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . 717.7 Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727.8 Aspekte der Verteiltheit . . . . . . . . . . . . . . . . . . . . . . . 747.9 Sicherheitsaspekte . . . . . . . . . . . . . . . . . . . . . . . . . . 75

7.9.1 Ausgezeichnete Benutzerrechte . . . . . . . . . . . . . . . 757.9.2 Datenubertragung . . . . . . . . . . . . . . . . . . . . . . 757.9.3 Passworter . . . . . . . . . . . . . . . . . . . . . . . . . . 76

8 Erweiterung des ETHOC-Systems 798.1 Neue Module einbinden . . . . . . . . . . . . . . . . . . . . . . . 798.2 Erweiterung auf Gegenstande . . . . . . . . . . . . . . . . . . . . 808.3 Neue ETHOC-Typen . . . . . . . . . . . . . . . . . . . . . . . . . 81

8.3.1 Autorenseitig . . . . . . . . . . . . . . . . . . . . . . . . . 818.3.2 Benutzerseitig . . . . . . . . . . . . . . . . . . . . . . . . . 82

8.4 Einbinden neuer Barcode-Leser . . . . . . . . . . . . . . . . . . . 828.4.1 Serverseitige Anbindung . . . . . . . . . . . . . . . . . . . 828.4.2 Anbindung im ETHOC-Browser . . . . . . . . . . . . . . 83

9 Diskussion und Ausblick 859.1 Erfullung der Aufgabenstellung . . . . . . . . . . . . . . . . . . . 859.2 Bewertung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . 869.3 Verifikation der Benutzungsszenarien . . . . . . . . . . . . . . . . 86

9.3.1 Filmveranstaltung und drahtlose Kommunikation . . . . . 869.3.2 Vorlesung und Studenten-Raum . . . . . . . . . . . . . . . 879.3.3 Aktionen auf Kleinstrechner . . . . . . . . . . . . . . . . . 879.3.4 Annonce und Mobiltelefon . . . . . . . . . . . . . . . . . . 87

9.4 Vorschlage fur weiterfuhrende Arbeiten . . . . . . . . . . . . . . . 889.4.1 Modifizierende Arbeiten . . . . . . . . . . . . . . . . . . . 889.4.2 Erweiternde Arbeiten . . . . . . . . . . . . . . . . . . . . 88

A Aufgabenstellung 91

B Glossar 95

C Eingesetzte Softwareprodukte 97C.1 Windows 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97C.2 JAVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97C.3 Jakarta Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97C.4 XALAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98C.5 XERCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98C.6 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98C.7 MM.MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98C.8 COS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99C.9 SUNs JPEG-API . . . . . . . . . . . . . . . . . . . . . . . . . . . 99C.10 Acme Labs GIFEncoder . . . . . . . . . . . . . . . . . . . . . . . 99C.11 SmtpClient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

vi INHALTSVERZEICHNIS

D XML-Definitionen 101D.1 doc.dtd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101D.2 modules.dtd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103D.3 authoringtools.dtd . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Abbildungsverzeichnis

3.1 Beispiele zweidimensionaler Barcodes . . . . . . . . . . . . . . . . 143.2 UPC Version A und EAN13 . . . . . . . . . . . . . . . . . . . . . 153.3 Aufbau eines Code 128 Barcodes . . . . . . . . . . . . . . . . . . 163.4 Beispiel eines Code 39 Barcodes . . . . . . . . . . . . . . . . . . . 16

4.1 Prinzip des Erstellungsprozesses . . . . . . . . . . . . . . . . . . . 234.2 Zusammenspiel der autorbezogenen Systemkomponenten . . . . . 244.3 Prinzip des Vermittlungsprozesses . . . . . . . . . . . . . . . . . 264.4 Zusammenspiel der benutzerbezogenen Systemkomponenten . . . 27

5.1 Code 39 vs. Code 128 . . . . . . . . . . . . . . . . . . . . . . . . 315.2 Variante Webservice . . . . . . . . . . . . . . . . . . . . . . . . . 345.3 Variante logischer lokaler Drucker . . . . . . . . . . . . . . . . . . 375.4 Variante logischer Online-Drucker . . . . . . . . . . . . . . . . . . 395.5 Variante Online-ID-Manager . . . . . . . . . . . . . . . . . . . . . 435.6 ID-Manager mit lokaler Komponente . . . . . . . . . . . . . . . . 45

6.1 Besipiel eines ETHOC-Barcodes . . . . . . . . . . . . . . . . . . 526.2 Einstieg ins Autorenportal . . . . . . . . . . . . . . . . . . . . . . 536.3 Ablauf der Objekt-Erstellung und -Anderung . . . . . . . . . . . 546.4 Methoden des abstrakten ETHOC-Servlets . . . . . . . . . . . . 566.5 Methoden des abstrakten ETHOC-XML-Servlets . . . . . . . . . 566.6 Methoden des abstrakten ETHOC-Service-Servlets . . . . . . . . 576.7 Servlet-Hierarchie im Autorenbereich . . . . . . . . . . . . . . . . 586.8 Zugriff auf Informationen in der Datenbank . . . . . . . . . . . . 596.9 Benutzungsmoglichkeiten des ETHOC-Systems . . . . . . . . . . 606.10 Umgang mit der zentralen Historie . . . . . . . . . . . . . . . . . 61

7.1 Klassen und Navigation im Benutzerportal . . . . . . . . . . . . . 697.2 Hauptklassen des ETHOC-Browsers . . . . . . . . . . . . . . . . 71

vii

viii ABBILDUNGSVERZEICHNIS

Tabellenverzeichnis

3.1 Vergleich Barcode vs. RFID-Marken . . . . . . . . . . . . . . . . 13

5.1 Evaluation Webservice . . . . . . . . . . . . . . . . . . . . . . . . 415.2 Evaluation lokaler Druckertreiber . . . . . . . . . . . . . . . . . . 415.3 Evaluation Online-Drucker . . . . . . . . . . . . . . . . . . . . . . 425.4 Meta-Informationen eines Dokumentes . . . . . . . . . . . . . . . 485.5 Aktionen eines Dokumentes . . . . . . . . . . . . . . . . . . . . . 49

7.1 Definition der MySQL-Tabelle “IdCoord” . . . . . . . . . . . . . 73

ix

x TABELLENVERZEICHNIS

Zusammenfassung

Abstract

In a ubiquitous world physical objects (like paper documents) possess an elec-tronic representation, so-called virtual counterparts, which supply additionalfunctionality and resources. Various mobile devices allow an interaction withsuch virtual counterparts.

The subject of this work is the design and implementation of a basic service forthe linkage of physical documents with on-line resources and functions. Bar co-des and mobile bar code readers are used as the linking technology to access vir-tual resources as well as additional functions of printed documents. The ETHOCsystem makes an infrastructure available, which supports the production, admi-nistration and intermediation of on-line resources. To authors of documents, thesystem supplies an XML and Web-based portal. On the user side different entrypossibilities exist to access virtually extended documents: the ETHOC browserfor Java enabled devices, e.g. PDAs or laptops, a WML interface for mobiletelephones, as well as a Web portal for access over conventional Web browser.The information is displayed according to the capabilities of the devices used.The personal history of earlier accesses is also available. The user can accessthe respective on-line resources and/or makes use of additional functions of thedocument, for example the automatic creation of calendar entries. Furthermore,the ETHOC browser allows a local caching of on-line resources, so that dataremain available in an off-line operation later on.

Special attention in the design of the ETHOC System has been paid to flexibilityand extensibility. The function range on client and server side can be simplyextended by modules and new object types. In particular, a further developmentof the ETHOC system is intended to support any objects, so that the vision“every thing has on-line content” will come true!

xi

xii ZUSAMMENFASSUNG

Zusammenfassung

In einer ubiqitaren Welt besitzen physische Objekte (wie z.B. Papierdokumente)elektronische Reprasentationen, sogenannte virtuelle Gegenstucke, die weiterge-hende Funktionalitat und Ressourcen bereitstellen. Eine Interaktion mit solchenvirtuellen Gegenstucken wird durch verschiedenste mobile Gerate ermoglicht.

Gegenstand dieser Arbeit ist die Konzeption und praktische Verwirklichung ei-nes Basisdienstes zur Verknupfung physischer Dokumente mit Online-Ressour-cen und -Funktionen. Fur den Zugriff auf virtuelle Ressourcen und Zusatzfunk-tionen gedruckter Dokumente werden Barcodes und mobile Barcode-Lesegerateals Verknupfungstechnologie verwendet. Mit dem ETHOC-System wird daruberhinaus eine Infrastruktur bereitgestellt, welche die Erzeugung, Verwaltung undVermittlung von Online-Ressourcen unterstutzt. Das System stellt den Autorenvon Dokumenten dazu ein XML- und Web-basiertes Autorenportal bereit. Aufder Benutzerseite existieren verschiedene Zugangsmoglichkeiten zu virtuell er-weiterten Dokumenten: der ETHOC-Browser fur Java-fahige Gerate, wie z.B.PDAs oder Laptops, ein WML-Interface fur Mobiltelefone, sowie ein Web-Portalfur den Zugriff uber herkommliche Web-Browser. Dabei werden die Informatio-nen angepasst an die Leistungsmerkmale der jeweiligen Gerate dargestellt. Diepersonliche Historie fruherer Zugriffe kann eingesehen und auf die jeweiligenOnline-Ressourcen zugegriffen bzw. zusatzliche Funktionen zum Dokument auf-gerufen werden, wie beispielsweise die automatische Erstellung von Kalender-eintragen. Der ETHOC-Browser ermoglicht desweiteren ein lokales Caching vonOnline-Ressourcen, so dass einmal eingelesene Daten auch in einem spaterenOffline-Betrieb verfugbar bleiben.

Bei der Konzeption des ETHOC-System wurde besonderes Augenmerk auf Fle-xibilitat und Erweiterbarkeit gelegt, damit sich der Funktionsumfang auf Client-und Serverseite mit Hilfe von Modulen und neuen Objekt-Typen nachtraglicheinfach erweitern lasst. Insbesondere ist eine Weiterentwicklung des ETHOC-Systems zur Unterstutzung beliebiger Objekte vorgesehen, so dass sich die Vi-sion “Every thing has online content” erfulle.

Kapitel 1

Einleitung

ETHOC steht fur “every thing has online content”. Dieses Kapitel motiviert dieIdee dieser Arbeit und ordnet sie in bestehende Konzepte ein. Es zeigt auch auf,wie das ETHOC-System in den Alltag einbezogen werden kann.

1.1 Ubiquitous Computing

Durch den technischen Fortschritt werden Prozessoren immer kleiner und ko-stengunstiger. Die Miniaturisierung wird in naher Zukunft dazu fuhren, dass sieindustriell in Alltagsgegenstande eingebaut werden konnen. Erweitert mit Sen-soren und drahtlosen Kommunikationsmoglichkeiten werden diese Prozessorenuntereinander Informationen austauschen. Die Computer sind allgegenwartig –ubiquitar. Mattern schreibt in seinem Artikel [1]: “Von einem technikzentriertenStandpunkt kann ‘ubiquitous computing’ als die Aussicht, die restlichen Dingeder Welt ans Internet anzuschliessen, bezeichnet werden”.

Vergleich man mit fruher, so hat das Netzwerk an Wert gewonnen. So werdenheute Computer gekauft, um ans Internet angeschlossen zu werden. Oder wieMattern in seinem Artikel [2] schreibt: “Es ist nicht mehr der PC, der im Mit-telpunkt steht und an den man die Netzperipherie anschliesst, sondern das Netzals solches hat eine unabhangige, dauerhafte Existenz angenommen.”

Dinge konnen also mittels in ihnen versteckten Prozessoren Daten verarbeitenund miteinander und dem Internet kommunizieren; sie werden smart. Smar-te Gegenstande verlangen im Gegensatz zu den komplexen PCs dem Benutzernicht viel Aufmerksamkeit ab. Sie erledigen ihre Aufgabe (z.B. das Bewasserndes Rasens unter Zuhilfenahme von Feuchtigkeitssensoren im Boden und Wet-terberichten aus dem Internet) und unterstutzen den Benutzer (z.B. indem beiabsehbarem Regenrisiko dem Benutzer mitgeteilt wird, den Schirm mitzuneh-men). Sie konnen sich ihren Aufenthaltsort und nahe Gegenstande merken; ken-nen also ihre Geschichte. Dadurch ist es moglich, sich z.B. beim Schreibtisch zuerkundigen, wo die aktuellen Aufenthaltstorte jener Bucher sind, die am Tagzuvor auf ihm lagen. Sie erkennen ausserdem ihre Benutzer. Dadurch kann aufPraferenzen implizit zuruckgegriffen werden, statt sie explizit zu erfragen. Sokonnte der Kaffee-Automat automatisch die Zuckermenge ermitteln, die jemand

1

2 KAPITEL 1. EINLEITUNG

fur gewohnlich im Kaffee wunscht oder das Auto die Sitz- und Spiegeleinstellun-gen automatisch an die letzten Einstellungen des Fahrers anpassen. Durch dieKooperation mit anderen Objekten und Diensten erzeugen die Objekte einenMehrwert, indem sie ihre eigene Arbeit besser automatisieren oder zusatzlicheInformation anbieten.

Doch wie konnen Dinge so viel Informationen behalten und wie konnen sieInformationen aus dem Web aufbereiten? Mehr und mehr Alltagsobjekte er-halten eine Reprasentation in einer Datenbank oder im Internet. Dies stellenauch Langheinrich et al. in [3] fest. Die Objekte besitzen also virtuelle Ge-genstucke oder virtuelle Proxies. Nicht das Objekt selber, sondern sein virtuel-les Gegenstuck verwaltet die Daten und Beziehungen zu anderen Objekten. DasObjekt realisiert uber Sensoren Anderungen in seiner Umgebung und teilt sieseinem virtuellen Gegenstuck mit.

Das eindeutige Identifizieren ist die Minimalvoraussetzung fur die Verbindungzwischen physischen “Objekten” und virtuellen “Gegenstucken”. Erhalten All-tagsgegenstande eine elektronische Identitat, konnen diese mit ihrem virtuellenGegenstuck verknupft werden. Bohn und Rohs bezeichnen in [4] einen solchenVermittler als eine symbolische Lupe. Wie die optische Lupe ermoglich die sym-bolische Lupe das nahere Betrachten eines Details. Mit dem Unterschied, dasshier die Details mit blossem Auge nicht erkennbar sind, sondern nur mit Hilfeder symbolische Lupe. Die symbolische Lupe ermoglicht den Eintritt in einevirtuelle Welt, wie z.B. dem Internet, ausgehend von einem physischen Objekt.Sie nimmt die ID auf und kontaktiert das virtuelle Gegenstuck.

1.2 Ziel dieser Arbeit

Ziel dieser Arbeit ist die Zuordnung von Online-Ressourcen zu gedruckten Do-kumenten, sowie die Untersuchung von Interaktionsmoglichkeiten mir diesenRessourcen, ausgehend vom physischen Dokument.

Dokumente erhalten also ein virtuelles Gegenstuck. Der Autor wird beim Er-stellen und Verwalten des virtuellen Gegenstuckes durch die zu schaffende In-frastruktur unterstutzt. Der Benutzer erhalt durch die Vermittlung der Infra-struktur Zugriff auf das virtuelle Gegenstuck und somit einen Mehrwert, da dasvirtuelle Gegenstuck dem Leser des Dokumentes erganzend digitale Informa-tionen und Aktionen anbietet. Es konnen Aktionen angeboten werden, die aufdem physischen Dokument nicht moglich sind, z.B. das Nachfuhren der Agen-da des Benutzers durch das virtuelle Gegenstuck eines Plakates, welches eineVeranstaltung ankundigt. Dabei gilt es, auf unterschiedliche Plattformen undBenutzungsszenarien einzugehen. Detailliertere Szenarien werden im Kapitel 4.1besprochen.

Die Dokumente selbst mussen nicht smart sein. D.h. sie mussen ihre Umweltnicht wahrnehmen konnen. Sie sollen lediglich eine Schnittstelle zum Interneterhalten. Dadurch konnen die virtuellen Gegenstucke mit den Geraten des Be-nutzers kommunizieren. Dies geschieht dann, wenn jemand die elektronische IDdes Dokumentes aufsammelt und im Internet das virtuelle Gegenstuck kontak-tiert.

1.3. KAPITELUBERSICHT 3

Jedes Objekt existiert einmalig und hat eine eigene elektronische ID. Dies be-schreiben auch Bohn und Rohs in [4]. Dokumente aber konnen vervielfaltigt odermehrfach gedruckt werden, was durchaus wunschenswert sein kann. Die Kopiender Dokumente sollen denselben Einstiegspunkt ins Internet, also dasselbe vir-tuelle Dokument haben, wie das Original. Die IDs der Dokumente haben hiereine ahnliche Funktionalitat wie die Produkt-Kodes im Laden, welche nicht dieindividuellen Produkte, sondern Produkttypen bezeichnen.

Die Aufgabenstellung (siehe Anhang A) verlangt explizit die Benutzung vonBarcodes. Dieser Entscheid ist fur dieses Projekt angemessen, denn die ID kannsomit direkt in die Druckvorlage einfliessen. Zur Anbringung der ID wird alsokeine zusatzliche Infrastruktur benotigt, sie wird elektronisch durchgefuhrt. DieVervielfaltigung von Dokumenten mit Barcodes ist ebenfalls ohne zusatzlichenAufwand resp. ohne Verlust der ID moglich. Wurde man z.B. RFID-Tags denBarcodes vorziehen, so waren sicherlich einige weitergehende Szenarien denkbar(zum Beispiel konnte ermittelt werden, wieviele Leute vorbeilaufen und wievieleeinen Aushang betrachten), doch waren der Aufwand und die Materialkosten furdie Autoren hoher. Wenn zum Beispiel ein Professor sein Vorlesungsskript miteinem Tag versehen will, so musste er (oder seine Assistenten) einige hundertRFID-Tags anbringen. Jedes einzelne Tag musste programmiert werden. DieserAufwand ist einzig durch den Kauf zusatzlicher Gerate reduzierbar. Denkbarware zum Beispiel eine Art Frankiermaschine, welche die Tags anbringt undgleich programmiert. Ein weiteres Problem der RFID-Tags ist das exakte Aus-machen von Dokumenten. Stunde der Benutzer vor einer Plakatwand, konntenplotzlich alle Dokumente sich angesprochen fuhlen und ihre ID zum Leser derBenutzers schicken. Ein Vergleich der Technologien Barcode und RFID-Tags istim Kapitel 3 zu finden.

1.3 Kapitelubersicht

Im weiteren ist der Bericht wie folgt gegliedert: Kapitel 2 motiviert den Ein-satz von ETHOC, indem ausfuhrliche Anwendungsbeispiele aufzeigt werden.Diese Beispiele bringen erste Anforderungen zu Tage, die in der Konzeptionberucksichtigt werden. Die Technologien, die heute zur automatischen Identifi-kation zur Verfugung stehen, werden in Kapitel 3 beschrieben und verglichen.Des weiteren wird auf die Kombinationsmoglichkeiten dieser Technologien mitKlienten-Plattformen eingegangen. Kapitel 4 beschreibt vier typische Einsatz-szenarien, die durch das ETHOC-System untertutzt werden sollen. Diese Szena-rien implizieren Anforderungen an das System, welche analysiert und System-komponenten zugeordnet werden. In Kapitel 5 werden verschiedene Variantenzur Realisierung dieser Komponenten vorgestellt und bewertet. Die ausgewahlteVariante wird in Kapitel 6 ausgearbeitet. Details der Implementierung folgen inKapitel 7. Kapitel 8 zeigt auf, wie das ETHOC-System durch neue Module undTypen nachtraglich erweitert werden kann. Abschliessend wird in Kapitel 9 einFazit gezogen, und es werden Vorschlage fur weiterfuhrende Arbeiten vorgestellt.Im Anhang finden sich die Aufgabenstellung, ein Glossar, eine Ubersicht der ein-gesetzten Softwareprodukte mit Installationshinweisen, sowie die Quelltexte derim ETHOC-System verwendeten XML-Definitionen.

4 KAPITEL 1. EINLEITUNG

Kapitel 2

Motivation

In diesem Kapitel werden Beispiele fur mogliche Erweiterungen durch Online-Ressourcen vorgestellt und somit der Einsatz von ETHOC motiviert. Dieses Ka-pitel soll den Leser inspirieren, eigene Ideen oder Einsatzgebiete zu entwickeln.

2.1 Beispiele fur online erweiterte Dokumente

Dieser Abschnitt illustriert wunschbare Aktionen fur mogliche Dokument-Ty-pen. (Alle moglichen Aktionen unabhangig vom Dokumententyp sind im Ab-schnitt 5.5.1 zusammengefasst.) Naturlich ist es moglich, zu jedem Dokumentals virtuelles Gegenstuck nur einen Link auf eine Internetseite vorzusehen, aufwelcher ein HTML-Designer im Auftrag des Autors alle relevanten Informatio-nen zum Anschauen und Runterladen anbietet. Dieses Projekt will aber Autorenohne HTML-Kenntnisse oder ohne Zeit, einen Internet-Auftritt zu organisieren,helfen, ein virtuelles Gegenstuck ihres Dokumentes in kurzer Zeit zu erstellen.

Die Basis-Funktionalitat von virtuellen Dokumenten wird im Kern des Systemsverwirklicht. Es wird aber eine Schnittstelle geben, um weitere Funktionen undDienste, sogenannte Module, in ETHOC einzubauen. Module verwirklichen wei-tere Dienste, die sich Autoren fur virtuelle Dokumente wunschen, die aber imETHOC-System nicht verwirklicht worden sind, sei es, um die grundsatzlicheBenutzerfuhrung einfach zu halten oder weil der Zeitrahmen dieser Diplomar-beit es nicht erlaubt hatte. Dank Modulen sind Erweiterungen ohne Anpassungdes bestehenden Kodes moglich. Es konnen beliebige Dienste und Funktioneneingebaut werden, die der Autor bei Bedarf auswahlen kann. Eine zu klarendeFrage wird sein, ob alle folgenden Dienste im ETHOC-System als Module an-geboten werden sollen oder ob sie Links zu bestehenden Diensten sein sollen,welche der Autor selbst finden und einrichten muss. Zum Beispiel soll die Fra-ge beantwortet werden, ob das ETHOC-System Diskussionsforen anbieten oderlediglich auf Foren im Internet verweisen soll.

5

6 KAPITEL 2. MOTIVATION

2.1.1 Veranstaltungshinweise

Veranstaltungen finden an einem bestimmten Ort wahrend einer gewissen Zeit-periode statt. Wurden Veranstaltungshinweise mit einem Barcode versehen, sokonnte das virtuelle Gegenstuck mit folgenden Aktionen einen Komfort bieten:

• Termin automatisch in den Kalender eintragen

• Dokument herunterladen

• Wegbeschreibung oder Gebaudeplan anzeigen

• Diverse Links zum Thema anzeigen

• Themenrelevante Dokumente herunterladen

Filmvorfuhrung

An der ETH werden von Studenten-Vereinen (z.B.: VIS oder SOS-ETH) Filma-bende organisiert. Die Studenten werden mit Plakaten auf diese Filme aufmerk-sam gemacht. Eine virtuelles Gegenstuck konnte folgende Aktionen anbieten:

• Filmkritik anzeigen

• Plakat herunterladen

• Trailer anzeigen

• Link zum Reservationssystem des Veranstalters anzeigen

• Link zur Homepage des Films anzeigen

Vortrag

An der ETH sowie an anderen Hochschulen werden regelmassig Vortrage – seies durch Angehorige der Hochschule oder durch Vertreter aus der Wirtschaft –gehalten. Eine virtuelles Gegenstuck konnte folgende Aktionen anbieten:

• Portrat der Referenten herunterladen

• Folien herunterladen

• Abstrakt herunterladen

• Link zum Anmeldeformular, falls Platzzahl beschrankt oder Vortrag ko-stenpflichtig

• Link zu relevanten Publikationen anzeigen

• Link zu Feedbackformular anzeigen

2.1. BEISPIELE FUR ONLINE ERWEITERTE DOKUMENTE 7

Einfuhrungsvorlesung

Neue Professoren halten in der Regel kurz nach ihrem Eintritt eine Einfuhrungs-vorlesung, in welcher sie ihr Forschungsgebiet vorstellen. Zusatzlich zu einemnormalen Vortrag bieten sich folgende Aktionen fur ein virtuelles Gegenstuckan.

• Lebenslauf des Professors herunterladen

• Link zur Instituts-Homepage des Professors anzeigen

• Link zur Homepage des Professors anzeigen

Seminar

Eine Ankundigung fur ein Seminar besteht in der Regel aus einer Reihe vonTerminen, in welchen pro Termin ein Thema behandelt wird. Der erste Terminist meistens eine Vororientierung. In der Regel wird das Leitthema vorgestelltund Beispielthemen fur Vortrage geschildert. Eine virtuelles Gegenstuck konnteeinen Link zum Registrierungsformular (inkl. Themenvergabe) als Aktion an-bieten.

2.1.2 Ankundigungen

Ankundigungen informieren uber Geschehnisse rund um den Alltag. VirtuelleGegenstucke zu Ankundigungen konnen folgende Aktionen beinhalten:

• Kontakt zum Autor

• Kontakt zur zustandigen Person (z.B. Sekretariat)

• Dokument herunterladen

Semester- und Diplomarbeiten

Ein grosser Teil der Aushange im Informatik-Gebaude der ETH sind Beschrei-bungen von Semester- und Diplomarbeiten. Sie skizzieren im Groben die Auf-gabenstellung, verweisen auf andere Arbeiten und nennen Kontaktadressen furweitere Informationen. Eine virtuelles Gegenstuck konnte Links zu Vorarbeiten(evtl. Demoversionen von Vorarbeiten) und Links zu anderen Semester- undDiplomarbeiten des selben Instituts anbieten.

Bestandenen-Liste

Viele Departemente der ETH hangen nach den Prufungen Listen mit den Na-men oder Leginummern der Studierenden aus, welche die Prufungen bestandenhaben. Eine Notenubersicht der einzelne Prufungen kann beim Studiensekre-tariat abgeholt oder per Post zugestellt werden. Zudem hat jeder Student dasRecht, seine Prufungen anzuschauen und die Korrektur mit einem Assistenten


zu besprechen. Wo und wann diese Besprechungen stattfinden, wird spater noch-mals separat angeschlagen. Eine virtuelles Gegenstuck konnte folgende Aktionenanbieten:

• Nach der Notenkonferenz die Verfugung mit den Noten herunterladen

• Informationen downloaden, wo welche Prufungen einsehbar sind

• Termine und Beschreibung fur weiteres Vorgehen herunterladen

Aus Datenschutzgrunden sollte die Bestandenenliste auf keinen Fall herunter-geladen werden konnen. Das virtuelle Gegenstuck darf also in diesem Szanarionur die Aktionen beinhalten und nicht die Online-Kopie des ausgehangten Do-kuments.

Aktualisierung des Vorlesungsverzeichnisses

Das Vorlesungsverzeichnis wird an der ETH so fruh gedruckt, dass Vorlesungenvon neuen Dozenten nicht aufgefuhrt sind und erst nach dem Druck gemeldetwerden konnen. Dadurch wird jedes Semester eine Ankundigung mit den nichterfassten Vorlesungen ausgehangt. Wurde dieser Aushang mit einem Barcodeversehen, konnte dieser auf eine stets aktualisierte Ubersichtseite aller Veran-staltungen verweisen.Wenn mehrere Barcodes pro Dokument erlaubt sind, konnte jede Veranstaltungmit einem Barcode versehen werden, der auf die Homepage der Veranstaltungenfuhrt.

Wohnungsvermittlung

Eine virtuelles Gegenstuck konnte folgende Aktionen anbieten:

• Bilder der Wohnung und Umgebung anzeigen

• Grundriss der Wohnung anzeigen

• Anzeige des Wohnstandortes im Stadtplan

• Kontakt zum Vermieter

Probandensuche

Diplomanden im Sport- oder Psychologiebereich suchen fur Studien Probanden,die gewisse Voraussetzungen erfullen mussen. Durch einen Online-Fragebogenkonnte das virtuelles Gegenstuck helfen, ungeeignete Probanden auszuschlies-sen.

2.1. BEISPIELE FUR ONLINE ERWEITERTE DOKUMENTE 9

2.1.3 Unterrichtsbezogene Dokumente

Vorlesungsskripte

Jedes Vorlesungsskript konnte mit einem Barcode versehen werden, der auf dieelektronische Version verweist. Alternativ konnte fur jedes Skript einer Vorle-sungsstunde der gleiche Barcode verwendet werden. Dann musste das ETHOC-System eine Historie der Online-Kopien verwalten konnen, damit altere Kapitelndes Skripts uber ihren aufgedruckten Barcode noch erreichbar sind. Wird dasSkript um Kapitel erganzt, konnen die alten Versionen geloscht werden. DieWahl liegt beim Autor.

Das aktuelle Vorlesungsskript konnte auf einzelne multimediale Dokumente deraktuellen Vorlesung verweisen. So konnte wahrend dem Unterricht jeder Studentdie Folien runterladen und sein personliches Exemplar erganzen oder allfalligeFehler korrigieren. Mathematische Vorlesung konnte als Beilage eine Maple-Datei enthalten und dadurch Studierende animieren, eigene Ideen und Losungs-vorschlage auszuprobieren.

Ubungen

Praktische Ubungen mussen in einer bestimmten Software-Umgebung absolviertwerden. Hierfur mussen bestimmte Programme und Bibliotheken installiert sein.In den Aufgabenblattern steht, welche Befehle eingegeben werden mussen, damitdie Umgebung richtig konfiguriert wird. Zu Programmieraufgaben gibt es haufigvorgegebenen Kode, der erganzt werden muss. Zu einem bestimmten Punkt er-scheint dann auch die Musterlosung. Eine virtuelles Gegenstuck konnte folgendeAktionen anbieten:

• Download der Konfigurationsskripte

• Download bestehender Kode-Fragmente

• Verknupfung mit der Musterlosung, die erst ab einem gewissen Zeitpunktzuganglich ist

• Link zur Testatubersicht fur einen Studenten

Letzterer Punkt ist ein Beispiel fur eine benutzerabhangige Aktion. Alle Stu-denten haben dasselbe Ubungsblatt vor sich, sprich, denselben Barcode. Den-noch konnte es moglich sein, dass jeder Student nur seine Testate sieht. DasAuthentifizieren konnte dadurch geschehen, dass beim Auflosen der Barcode-ID benutzerspezifische oder Barcode-Leser-spezifische Daten, wie z.B. Serien-nummer, geschickt werden. Sie konnte aber auch via einen Login auf der Te-statsubersichtsseite erfolgen.

Einschreibebogen

Vor jedem Semester erhalt jeder Student seinen Einschreibebogen, den er zukontrollieren, gegebenenfalls zu korrigieren und ihn an die Schulleitung zuruck-zusenden hat. Ein Barcode auf dem Einschreibebogen konnte den Studentenaufs Online-Verwaltungssystem der ETH fuhren.


2.1.4 Weitere Dokumente

Abstimmung

Wenn mehrere Barcodes pro Dokument unterstutzt werden, konnten Umfra-gen direkt uber das Auflosen eines Barcodes ausgefuhrt werden. Das ETHOC-System musste einerseits sicherstellen, dass kein Benutzer mehrmals teilnehmenkann andererseits aber auch, dass keine Ruckschlusse zur Person gezogen wer-den konnen, falls die Abstimmung anonym verlauft. Ebenfalls erkannt werden,musste das Erfassthaben von mehreren Kodes, die zur gleichen Abstimmunggehoren.

Bucher

Jedes Buch besitzt einen EAN13-Barcode, der im wesentlichen seiner ISBN-Nummer entspricht. Obwohl diese Kodes nicht den Aufbau der Barcodes dieserArbeit haben, wurde ein Einbezug der EAN13-Barcodes einen Mehrwert schaf-fen.

In Vorlesungen oder Ubungen empfehlen Professoren oder Assistenten oft be-stimmte Bucher als weiterfuhrende Literatur. Meistens nehmen sie ein Exemplarmit, in welchem die Studenten wahrend der Pause blattern konnen, um selbsteinen Eindruck zu erhalten. Das ETHOC-System konnte EAN13-Barcodes un-terstutzen, indem es die Benutzer automatisch zur Seite der ETH-Bibliothekumleitet, wo sie das Buch reservieren konnten. Eine andere Umleitung warezu einer Buchhandlung, wo das Buch gekauft werden kann. Werden EAN13-Barcodes unterstutzt, so muss uberlegt werden, ob nicht der Benutzer selbstbestimmen kann, was mit dem eingelesenen Barcode geschieht, resp. welche Bi-bliothek, Buchhandlung oder allgemein: welche Internetseite die aus dem Bar-code geschlossene ISBN-Nummer weiterbearbeiten soll.

2.2 Verallgemeinerung auf beliebige Gegenstan-de

Nicht nur Dokumente, sondern auch Gegenstande konnen virtuelle Gegenstuckeaufweisen.

Zum Beispiel konnte ein Raum via virtuellem Gegenstuck von einem Benutzeronline reserviert werden. Das virtuelle Gegenstuck eines elektronischen Gerateskonnte fur Benutzer eine Bedienungsanleitung oder eine Liste der haufigstenProbleme samt Antworten anbieten. Fur spezielle Benutzer (z.B. Servicean-gestellte) konnte es die letzten Reparaturen und Inspektionen anzeigen. Ver-brauchsprodukte konnten nachbestellt werden.

Die Frage ist, wie die Gegenstande mit der ID versehen werden konnen. DasDrucken des Barcodes auf eine selbstklebende Etikette ware eine MoglichkeitEs muss aber geklart werden, wie man diese IDs vor Manipulation schutzt. BeiDokumenten, fallt eine Manipulation an der ID optisch auf, da der Barcode aufdem Dokument gedruckt ist. Wird der Barcode auf ein Objekt nach dessen Her-stellung aufgebracht, kann man diesen Barcode leicht entfernen und durch einen

2.2. VERALLGEMEINERUNG AUF BELIEBIGE GEGENSTANDE 11

anderen ersetzen. Das Problem des nachtraglichen Anbringen von Barcodes falltbei kleinen Gegenstanden ins Gewicht, bei denen die Anbringflache sehr geringist.

Kapitel 3

Technologien undPlattformen

Dieses Kapitel befasst sich mit den heute vorhandenen Technologien zur au-tomatischen Identifikation von Objekten mit Fokus auf Barcodes, da diese indieser Arbeit verwendet werden. Es werden die Lesegerate und die Kombinati-onsmoglichkeiten mit Klienten-Plattformen aufgezeigt.

3.1 Identifikationstechnologien

Anglin schreibt in [5], dass die Absicht der mobilen Barcode-Leser das Ver-knupfen von gedrucktem Material zum Internet sei. Barcodes stellen also eineTechnologie dar, um Objekte mit einem virtuellen Gegenstuck zu verbinden. Siewird in Abschnitt 3.1.1 behandelt. Alternative Moglichkeiten, wie z.B. RFID-Marken, werden im Abschnitt 3.1.2 vorgestellt. Barcodes und RFID-Markenwerden in Tabelle 3.1 verglichen.

Eigenschaft Barcode RFIDKosten pro Marke gratis 0.5 bis 1 EuroSichtkontakt beim Erfassen notwendig nicht notwendigGleichzeitig lesbare Marken 1 leserabhangigSchreiben von Information nicht moglich beschreibbare Mar-

ke teurerErstellung auf Objekt drucken programmieren und

anbringenInfrastruktur fur Dokumente Buro-Drucker und

PapierSpezialdrucker, derMarke program-miert

Tabelle 3.1: Vergleich Barcode vs. RFID-Marken

13

14 KAPITEL 3. TECHNOLOGIEN UND PLATTFORMEN

Abbildung 3.1: Beispiele zweidimensionaler Barcodes

3.1.1 Barcodes

Barcodes sind Zahlen- und Zeichenfolgen, welche in Form von Streifen aufge-druckt und somit maschinell lesbar werden. Sie werden mit speziellen Lesernerfasst, die zur Abtastung eine Lichtquelle verwenden. Dabei gibt es lineare undzweidimensionale Barcodes. Die Abbildung 3.1 (Quelle: [6]) zeigt Beispiele furzweidimensionale Barcodes. Am weitesten verbreitet sind die linearen Barcodes.Sie sind heute standardisiert auf kommerziellen Produkten zu finden.

Lineare Barcodes werden eindimensional von rechts nach links oder links nachrechts eingelesen. Zweidimensionale Barcodes sind rechteckige oder quadrati-schen Muster und mussen gleichzeitig in zwei Dimensionen gelesen werden. Da-durch konnen auf der gleichen Flache bis zu 50 mal mehr Daten gespeichertwerden als mit linearen Barcodes. Fur die zweidimensionalen Barcodes brauchtes teurere Lesegerate und teilweise spezielle Druckertechnik.

Geschichte des Barcodes

Nach Russ [7] war der erste Barcode eine Entwicklung von Norman JosephWoodland und Bernard Silver. Er besteht aus weissen Linien auf schwarzemGrund, welche einen festen Abstand zueinander haben. Information wird durchdie An- oder Abwesenheit der Linien kodiert. Diese Idee floss 1952 in ein US-Patent ein.

1969 bat die NAFC (National Association of Food Chains) die Firma LogiconInc., einen industrieweiten Standard fur Barcode-Systeme zu entwickeln. Derentwickelte Standard hiess Universal Product Code (UPC). 1974 wurde der ersteUPC-Scanner in Betrieb genommen. Das UPC-System ist in den USA immernoch im Einsatz.

3.1. IDENTIFIKATIONSTECHNOLOGIEN 15

Abbildung 3.2: UPC Version A und EAN13

Universal Product Code

UPC Version A besteht aus zwolf Ziffern (siehe Abbildung 3.2 links). Die ersteZiffer bestimmt das Nummernsystem. So steht die Zwei fur gewogene Ware (wieFruchte in der Selbstbedienung), die Drei fur pharmazeutische Produkte unddie Null, Sechs und Sieben sind Standard-UPC-Codes. Die nachsten funf Zifferndienen zur Herstelleridentifizierung. Sie werden durch das Uniform Code Concil(UCC) vergeben. Fur den Hersteller ist dies mit einem Jahresbeitrag verbunden.Die nachsten funf Ziffern konnen durch den Hersteller selbst vergeben werdenund bezeichnen das Produkt. Es ist Sache des Herstellers sicherzustellen, dasskeine zwei verschiedene Produkte den selben Barcode tragen. Die letzte Zifferist eine Prufsumme. Einzelne Details beschreibt Brain in [8]. Die Spezifikationist in [7] zu finden.

European Article Numbering System

Der Wunsch nach einer Zusatzziffer im UPC zur Identifikation von Staatenwurde in der EAN13-Symbolik umgesetzt. Entgegen dem Wort “European” inseinem Namen kommt EAN13 weltweit zum Einsatz. Zum Beispiel haben ISBN-Nummern den Landerkode 978. Dadurch besitzen auch amerikanische BucherEAN-Barcodes. (Weitere Informationen zu den Landerkodes sind unter [7] auf-gefuhrt.)

EAN und UPC besitzen eine unterschiedliche Kodierung der Ziffern. Auch dieDarstellung fur das manuelle Lesen ist unterschiedlich angebracht (siehe Abbil-dung 3.2). EAN ist in [7] spezifiziert.

Barcodes-Kodierungsformen

Nebst den obigen Standards kann jeder eigene Barcodes beliebiger Lange gene-rieren. Beliebig heisst, dass die Lange bis zu einem im entsprechenden Standardfestgehaltenem Maximum gewahlt werden kann. Es gibt Kodierungen, die dasAlphabet oder den ganzen ASCII-Zeichensatz umfassen.

Der Code 128, ist laut [7] ein Code mit sehr hoher Dichte, der fahig ist, 128ASCII-Zeichen zu kodieren, und beliebige Lange besitzen kann. Am Ende derDaten (siehe Abbildung 3.3 (Quelle: [7])) ist eine Prufsumme vorgesehen. Esgibt drei unterschiedliche Start-Zeichen: Start-Kode A kodiert alle standardi-sierten alphanumerischen Tastatur-, Sonder- und Kontrollzeichen. Start-Kode


Abbildung 3.3: Aufbau eines Code 128 Barcodes

Abbildung 3.4: Beispiel eines Code 39 Barcodes

B kodiert alle standardisierten alphanumerischen Tastatur- und Sonderzeichenund unterscheidet zwischen Gross- und Kleinschreibweise. Start-Kode C kodiertnur Ziffern. Hierfur verwendet er fur zwei Ziffern ein Barcode-Zeichen. Inner-halb des Datenbereichs kann durch Verwendung der Zeichen CODE und SHIFTzwischen den Kode-Arten gewechselt werden. Code 128 ist ebenfalls in [7] spe-zifiziert.

Code 39 ist laut [7] ein alphanumerischer Barcode, der 26 Grossbuchstaben 10Ziffern und sieben Sonderzeichen kodieren kann. Ein Sonderzeichen ist der Stern“*” welcher den Anfang und das Ende des Barcodes markiert (siehe Abbildung3.4). Der Stern dient lediglich diesem Zweck und kann somit nicht in den Datenauftreten. Eine Prufsumme ist nicht verlangt, kann aber von Applikation zuApplikation selbst eingefuhrt werden. Code 39 ist ebenfalls in [7] spezifiziert.

3.1.2 Weitere Tagging-Systeme

Barcodes werden auf Dinge oder Dokumente aufgedruckt. Sind sie einmal aufge-druckt, reprasentieren sie die in ihnen kodierte Zeichenfolge. Diese Zeichenfolgewird von Lesegeraten ausgelesen. Barcodes sind demzufolge passiv. Es gibt aberandere Technologien, die ihre gespeicherte Information anpassen und diese selbstaktiv kommunizieren konnen.

In diesem Abschnitt werden die heute bestehenden Technologien aufgefuhrt.Auf die RFID-Tags wird spezieller eingegangen, da sie in der Literatur [2, 10]teilweise als Nachfolger der Barcodes gehandelt werden.

3.2. BARCODE-LESER 17

RFID-Tags

RFID steht fur Radio Frequency Identification. Ein RFID-Tag ist ein Prozessormit einen Speicher und einer Antenne zur Kommunikation. Es wird zwischenpassiven und aktiven RFID-Tags unterschieden. Die aktiven Tags besitzen eineBatterie, die sie mit Energie speist. Sie sind machtiger (konnen z.B. als portableDatenbank benutzt werden), aber auch teurer und grosser. Die passiven RFID-Tags beziehen ihren Strom durch das elektromagnetische Feld, welches ein Le-segerat erzeugt, das mit ihnen kommuniziert. Sie sind heutzutage so flach, dasssie z.B. in Papier einlaminiert werden konnen. Gewisse RFID-Tags konnen nichtnur ausgelesen, sondern auch beschrieben werden. Dies ist ein Grund weshalbBoonsor [10] glaubt, dass die RFID-Tags die Barcodes ablosen werden. Ein we-sentlicher Vorteil ist, dass keine Sichtverbindung zwischen Lesegerat und RFID-Tag bestehen muss. Darin und in den standig sinkenden Preisen der RFID-Tagssieht Mattern in [2] das Potential zur Ablosung von Barcodes. Trotz den Vortei-len, die RFIDs bringen, haben sie auch Nachteile. Deshalb schreibt Donalies inseinem Kommentar [9], dass RFID und Barcodes keine konkurrierenden Tech-niken sind, sondern sich in idealer Weise erganzen.

RFID-Tags gibt es in unterschiedlichster Form, als selbstklebende Etikette odereingepackt in einer Glashulle, welche das Anbringen an metallische Gegenstandeoder das Implantieren unter der Haut von Tieren ermoglicht. (Siehe auch Lang-heinrich et al. [3] auf Seite drei und zehn). Die selbstklebenden Etiketten sindheute zu einem Preis von 0.5 bis einem Euro pro Stuck erhaltlich – mit fallenderTendenz.

Infrarot-Beacons

Im CoolTown-Projekt [11] sorgen Infrarot-Beacons fur die Vermittlung der Web-prasenz eines physischen Objektes. Die Beacons werden in der Nahe des Ob-jektes platziert und verbreiten in einem Intervall von wenigen Sekunden viaBroadcast und Infrarottechnologie die in ihnen gespeicherte Zeichenkette. DieWahl Infrarot-Technologie zu benutzen, wird durch die eingebauten Infrarot-Kommunikationsmoglichkeiten vieler Kleinstrechner, wie z.B. den PDAs, ge-rechtfertigt.

Ultraschall

Die Identifizierung ist auch via Ultraschall und Ultraschall-Beacons moglich.Auf der Homepage [12] wird ein Versuch erlautert, in welchem Fische ein Ul-traschall-Beacon implantiert erhielten, um ihr Verhalten bezuglich kunstlichenRiffs zu untersuchen.

3.2 Barcode-Leser

Die einfache Handhabung der Erstellung von Barcodes fur normale Benutzerhat zu einem breiten Einsatz dieser gunstigen Technologie gefuhrt. Aufgrunddieser Verbreitung sind verschiedene Typen von Barcode-Lesegeraten auf demMarkt.


Ein Typ sind die Leser, welche mehrere Barcodes speichern konnen und diesespater auf den Rechner ubertragen. Diese Leser werden uber ein Kabel (z.B. USBoder seriell) an den Rechner angeschlossen. Die Kodes werden uber eine mitge-lieferte Software ausgelesen. Es konnen auch eigene Applikationen geschriebenwerden. Zu diesem Zweck sind die Schnittstellen zum Leser dokumentiert.

Andere Leser kommunizieren drahtlos (z.B. uber Bluetooth) mit dem Rechner.Barcodes konnen so direkt an der Rechner geschickt werden. Gewisse Leserwiederum sind fur spezielle Rechner gebaut. Sie konnen uber Steckplatze anLaptops, Kleinstrechner oder Mobiltelefone angeschlossen werden. Es kommenmittlerweile immer mehr Kleinstrechner mit integriertem Barcode-Leser auf denMarkt.

Betrachtet man die Vielfalt der Barcode-Leser und deren unterschiedliche Artdie Barcodes zu ubermitteln, stellen sich wichtige konzeptuelle Fragen fursETHOC-System. Die Integration unterschiedlicher Barcode-Leser soll moglichsein, ohne regelmassig das ETHOC-System anpassen zu mussen.

3.3 Klienten-Plattformen

Nicht nur die Barcode-Leser sondern auch die Betriebssysteme und die Rech-ner, die benutzt werden, konnen unterschiedlich sein. Fur einige Plattformensind wiederum nur bestimmte Barcode-Leser moglich. Dieser Abschnitt zeigtKombinationsmoglichkeiten, die mit den Scannern moglich sind. Nicht alle Ope-rationen, die ein virtuelles Gegenstuck eines Dokumentes anbietet, konnen aufjedem Gerat und Betriebssystem ausgefuhrt werden. Es muss ein Weg gefundenwerden, dass einem Benutzer nur jene Operationen angezeigt werden, die aufseinem Rechner funktionieren.

3.3.1 PC

Da der PC grossenbedingt stationar ist, kombiniert man ihn am besten miteinem Barcode-Leser, der Barcodes sammelt und spater zum PC ubermittelt.Der PC muss einen Internetanschluss besitzen. Das virtuelle Gegenstuck kannaufgrund der Rechenleistung des PCs alle Aktionen durchfuhren. Lediglich feh-lende Hardware konnten Aktionen verhindert. Zum Beispiel kann man nicht mitjedem PC telefonieren.

3.3.2 Laptop

Die optimale Kombination ware das Zusammenspiel des Laptops mit Zugangzum Wireless-LAN und einem drahtlos kommunizierenden Scanner. Wie beimPC sind hier ebenfalls aufgrund der Rechenleistung (fast) alle Aktionen durch-fuhrbar.

3.3.3 PDA

Fur den PDA gibt es zwei mogliche Einsatzgebiete. Ist nicht schon bereits einBarcode-Leser eingebaut, kann entweder ein drahtloser verwendet oder einer

3.3. KLIENTEN-PLATTFORMEN 19

aufs Gerat aufgesteckt werden. Der PDA muss Zugang zum Internet haben. Esgilt abzuklaren, welche Aktionen auf einem PDA funktionieren konnen und obdies fur alle PDAs identisch oder abhangig vom PDA-Hersteller ist. Ist letzteresder Falls, muss abgeklart werden, wie die Gerate von ETHOC-System erkanntwerden konnen, damit sie nur diese Aktionen angeboten bekommen, die sie auchausfuhren konnen.

3.3.4 Mobiltelefon

Fur die neuesten Ericsson-Modelle gibt es seit Winter 2001 einen Steckaufsatzder Firma AirClic. Da die Rechenleistung eines Mobiltelefons stark begrenztist, stellt sich hier die Frage, ob uberhaupt auf den Mobiltelefonen Software-Komponenten des ETHOC-Systems laufen konnen. Eventuell muss hier allesonline uber WML-Seiten abgewickelt werden. (Bei AirClic wird dies so ver-langt.) Neuerdings verstehen einige Mobiltelefone auch HTML. Es muss abge-klart werden, ob das ETHOC-System die Mobiltelefone unterscheiden konnenmuss oder generell WML-Seiten generieren soll.

Kapitel 4

Systemanalyse und-Anforderungen

Dieses Kapitel beginnt mit Szenarien fur die Benutzer des Systems. Dadurchwerden die Kernanforderungen an das System offensichtlich. Die Anforderungenziehen benotigte Systemkomponenten nach sich. Somit wird das System alsGanzes und auf Stufe seiner Komponenten analysiert. Es sollen hier weitereProblemfelder erlautert und in den folgenden Kapiteln diskutiert und umgesetztwerden.

4.1 Benutzungsszenarien

Dieser Abschnitt illustriert Musterbeispiele fur Handlungsablaufe fur die Be-nutzer des ETHOC-Systems. Diese Beispiele zeigen die Benutzerbedurfnisse ansSystem und konnen spater zur Verifikation des Systems herangezogen werden.

4.1.1 Filmveranstaltung und drahtlose Kommunikation

Dieses Benutzungskonzept sieht vor, dass der Benutzer uber einen Laptop mitAnschluss ans Internet verfugt. Im Rahmen des Projektes “Neptun” werdenStudierende an der ETH mit personlichen Laptops mit Zugang zum Wireless-LAN der ETH ausgerustet. Mit Hilfe eines Barcode-Lesers der drahtlos mit demNotebook kommuniziert, sieht ein mogliches Szenario wie folgt aus:

Ein Student sieht auf einem Plakat, dass demnachst ein Film vorgefuhrt wird,den er im Kino leider verpasst hat. Er mochte diese Chance nutzen und un-bedingt hingehen. Er liesst den Barcode mit seinem Leser ein, welcher sofortzum Computer ubertragen wird. Es wird die Applikation gestartet, welche dievirtuellen Gegenstucke anzeigt. Als vorsichtiger Mensch hat er als Standarde-instellung alle automatischen Aktionen unterbunden. Somit sieht er in einemFenster der Applikation, weitere Angaben zum Plakat selber, sowie welche Ak-tionen mit diesem Plakat verbunden sind. Dort sieht er die Funktion, welche ihmerlaubt, den Termin in seine Agenda einzutragen. Er klickt auf diese Funktion

21

22 KAPITEL 4. SYSTEMANALYSE UND -ANFORDERUNGEN

und der Filmbesuch ist eingetragen. Da er den Film kennt, interessieren ihndie anderen Funktionen, wie Zusammenfassung des Inhalts, Trailer und Linkzur Filmhomepage nicht. Er loscht nun den Barcode aus der Applikation undschliesst diese.

4.1.2 Vorlesung und Studenten-Raum

Da nicht alle Studenten uber einen Laptop verfugen, konzentriert sich diesesSzenario auf den PC in den Ubungsraumen der ETH resp. dem eigenen Rechnerzuhause und einen Barcode-Leser, der Barcodes zwischenspeichern kann.

Ein Student, der zu spat zur Vorlesung erschienen ist, hat kein Skript mehrerwischt. Um es nachtraglich selber ausdrucken zu konnen, liest er mit seinenBarcode-Leser den Barcode vom Skript seines Bank-Nachbarn ein. Auf demUbungsblatt, das gleichzeitig verteilt wurde, sieht er, dass man ein Kode-Gerustals Ausgangslage benutzen kann. Um sich nicht die URL merken zu mussen, liester auch hier den Barcode ein.

Nach dem Mittagessen geht er in einen Studentenraum und schliesst seinenBarcode-Leser an den neben dem PC zur Verfugung stehenden Steckplatz an. Eswird automatisch die Applikation gestartet, welche die virtuellen Gegenstuckeanzeigt. Die Barcodes werden zu ihr transferiert und vom Barcode-Leser ge-loscht. Er sieht im Fenster der Applikation untereinander alle Barcodes, die erseit dem letzen Benutzen der Applikation gesammelt hat (in diesem Fall zwei).Die Barcodes werden durch weitere Angaben erganzt resp. ersetzt. Er sieht furjedes Objekt alle Aktionen, die moglich sind. Da er standardmassig angegebenhat, alle Aktionen, die Downloads beinhalten, automatisch ausfuhren zu lassen,werden das Skript, die Aufgabenstellung und das Kode-Gerust zur Aufgabe oh-ne sein Zutun in ein bei der Konfiguration angegebenes Zielverzeichnis kopiert.Beim Barcode des Vorlesungsskriptes sieht er noch einen Link zur Vorlesungs-homepage. Beim Barcode der Ubung sieht er, dass es noch eine Musterlosunggibt. Dieser Download ist aber als noch nicht freigegeben markiert. Da er diesespater downloaden will, loscht er diesen Barcode nicht resp. speichert ihn.

Wenn er das nachste Mal die Applikation startet, sieht er alle gespeicherten Bar-codes wieder. Beim Programmstart wird nachgepruft, ob und wenn ja welcheUpdates fur die alten Barcodes bereitstehen. Gibt es neue Aktionen, so wirdder Benutzer darauf hingewiesen. Bei der Ubung hat das System festgestellt,dass eine neue Version der Aufgabenbeschreibung online ist. Da war also docheine falsche Beschreibung abgedruckt. Die neue Version wird automatisch her-untergeladen, da ja die Applikation von Studenten so konfiguriert wurde, dassalle Downloads ausgefuhrt werden. Die Musterlosung ist naturlich noch nichtonline, doch sobald dies der Fall sein wird, wird sie automatisch heruntergeladenwerden.

4.1.3 Aktionen auf Kleinstrechner

Dieses Szenario sieht vor, dass der Benutzer einen Kleinstrechner (z.B. PDA)hat, welcher mangels Rechenleistung nicht alle Aktionen durchfuhren kann.(Z.B. gibt es nicht fur alle PDAs Software, um PDF-Dokumente anzuzeigen.)

4.2. AUTORENUNTERSTUTZUNG 23

Abbildung 4.1: Prinzip des Erstellungsprozesses

Viele vorhandene Produkte benotigen heute viel Rechenleistung, was sie nichtauf jedem Gerat einsetzbar macht. Ein Student mochte einen Talk besuchen, andem sein Lieblingsprofessor referiert. Er liest mit seinem PDA den Barcode undes wird die Applikation gestartet, welche die Barcodes verwaltet. Der Studentsieht auch hier alle Aktionen, die zum Barcode gehoren. Einige Aktionen sindnicht aktivierbar. Er kann sie nicht ausfuhren, da sein Gerat diese nicht un-terstutzt. Zum Beispiel kann sein PDA keine PDF-Dokumente anzeigen, jedochdie Veranstaltung in seine Agenda einfugen.

4.1.4 Annonce und Mobiltelefon

In diesem Szenario hat ein Student eine Wohnungsanzeige gesehen. Das Einlesendes Barcodes zeigt ihm eine WML-Seite an. Alle moglichen Aktionen sind Links.Da ein Mobiltelefon keine Dokumente runterladen und auch keine PDF-Dateienanzeigen kann, kann der Student leider nicht die Grundrisse sehen. Er sieht aber,dass es diese Dateien gibt und dass der sie z.B. mit dem PC betrachten kann.Das sein Mobiltelefon das WTA-Interface (Wireless Telephony Application) un-terstutzt, kann er die Telefonnummer der Vermieterin, welche als Kontaktpersonangegeben ist, anklicken und sein Mobiltelefon wahlt die Nummer automatisch.Des weiteren kann er den Orientierungs-Termin, der fur alle Interessenten gilt,in seine Agenda eintragen.

4.2 Autorenunterstutzung

Dieser Abschnitt beschaftigt sich mit den Autoren von Dokumenten und denDiensten der Infrastruktur, die diesen zur Verfugung gestellt werden muss.

4.2.1 Erstellungsprozess

Im Erstellungsprozess (siehe Abbildung 4.1) mochte der Autor sein Dokument,das er in einer Software seiner Wahl erstellt hat, um ein virtuelles Gegenstuckaufwerten, welches auf sein Dokument zugeschnittene Zusatzinformationen oderAktionen anbietet. Den Umfang des virtuellen Gegenstucks (Zusatzdateien, Ter-mine fur Agenden, Links etc.) kann er selbst bestimmen. Welche Aktion fur wel-che Dokumente sinnvoll ist, ist in Abschnitt 2.1 untersucht worden. Am Endedes Prozesses ist sein physisches Dokument um einen Barcode erweitert. Dieser


Abbildung 4.2: Zusammenspiel der autorbezogenen Systemkomponenten

dient als Verbindung zum virtuellen Gegenstuck. Dazu gilt es diesen Prozess derErstellung eines virtuellen Dokumentes fur den Autor so einfach wie moglich zugestalten.

4.2.2 Anderungsprozess

Ein weiteres Werkzeug fur den Autor ist die Moglichkeit, das virtuelle Ge-genstuck an neue Bedurfnisse anpassen zu konnen. Doch auch das physischeDokument kann sich andern. Dabei kann es erwunscht sein, dass trotz derAnderungen am physischen Dokument, das virtuelle Gegenstuck nicht verlo-ren geht. Sprich, das geanderte physische Dokument soll die gleiche ID habenwie das ursprungliche. Dies ist z.B. dann wunschenswert, wenn Rechtschreib-fehler bemerkt wurden. Im diesem Prozess wird der Autor bei den Anderungendes virtuellen Gegenstuckes oder bei einer Verknupfung eines neuen physischenDokuments mit einem vorhandenen virtuellen Gegenstuck, das auf eine altereVersion zeigt, unterstutzt.

4.2.3 Autorbezogene Systemkomponenten

Die obigen Prozesse haben einige Aufgabenfelder des Systems angeschnitten. Indiesem Abschnitt werden die Aufgaben mit Systemkomponenten in Verbindunggebracht, die diese Aufgabe losen. Das Zusammenspiel dieser Komponenten istder Abbildung 4.2 zu entnehmen. Welche Varianten es pro Systemkomponentegibt, wird in Kapitel 5 behandelt.

Autoren-Identifikation

Die Systemkomponente Autoren-Identifikation kann als Tursteher betrachtetwerden, welcher den Zutritt zur Autoren-Software regelt. Diese wird gegenuber

4.2. AUTORENUNTERSTUTZUNG 25

den Autoren als Autoren-Portal bezeichnet. Hier geschieht eine allfallige Au-thentisierung und Autorisierung. Zudem dient diese Komponente als Eintritts-punkt zu den Autoren-Werkzeuge. Bei der Konzeption muss geklart werden, obder Autorenkreis eingeschrankt werden soll oder ob es jedem freisteht, Doku-mente zu publizieren und anzupassen.

Objekt-Erstellung

Diese Systemkomponente ermoglicht dem Autor, uber Eingabemasken das vir-tuelle Gegenstuck zu erzeugen. Das virtuelle Gegenstuck besteht aus Meta-Inforationen, d.h. aus Hintergrunds- und weiterfuhrende Informationen, welchebeim Benutzer als Text, Dateien, Links oder Aktionen ihre Form annehmen, dieelektronisch verwaltet werden.

Hier geschieht also die Eingabe der Meta-Informationen. Denkbar ware auch eineautomatische Extraktion vom Meta-Informationen aus dem Dokument. Dies istjedoch nicht Gegenstand dieser Arbeit. Die Meta-Informationen mussen durchden Autor eingegeben werden. Die Objekt-Erzeugung kontaktiert im Hinter-grund alle benotigten Systemkomponenten, um die Verwaltung der Daten si-cherzustellen. Der (Funktions-)Umfang eines minimalen Gegenstuckes muss indieser Komponente bekannt sein.

ID-Koordinator

Der ID-Koordinator stellt sicher, dass jede ID nur einmal vergeben wird unddass alle vergebenen IDs verwaltet werden, so dass dem Benutzer die dazu-gehorenden virtuellen Gegenstucke angezeigt werden konnen. Dabei muss dieKonsistenz auch bei einem Absturz dieser Komponente und einem spaterenNeustart garantiert werden. Die Eindeutigkeit der IDs muss erhalten werden,wenn diese Komponente zwecks Leistungssteigerung repliziert wird.

Barcode-Erzeugung

Diese Komponente erzeugt aus der ID einen Barcode. Es muss abgeklart werden,welche Symbolik verwendet werden soll und ob unterhalb des Barcodes die ID ineine fur den Menschen lesbaren Form angebracht sein soll. Ebenfalls gilt es beider Konzeption die Frage zu beantworten, wie der Barcode auf ein physischesDokument kommt und wie flexibel dessen Positionierung ist.

Datenhaltung

Diese Komponente verwaltet die Meta-Informationen und Online-Ressourcenund garantiert die Datenhaltung auch bei einem vollstandigen Systemabsturz.Sie sorgt dafur, dass jede vergebene ID mit einem virtuellen Gegenstuck ver-knupft ist, oder als ungultig resp. geloscht markiert ist. Mit zunehmender Le-bensdauer des Systems stellt sich die Frage, wie lange die zu den IDs gehorendevirtuelle Gegenstucke verwaltet werden sollen. Es wird deshalb ein Ablaufda-tum fur IDs geben, welches der Autor bestimmen und gegebenenfalls verlangern


Abbildung 4.3: Prinzip des Vermittlungsprozesses

kann. Diese Komponente ist somit auch fur das Loschen nicht mehr gebrauchterDaten verantwortlich.

Autoren-Notifikation

Dies Komponente informiert den Autor uber Ereignisse, die das virtuelle Ge-genstuck seines Dokumentes betreffen. Droht die Gultigkeitsdauer von IDs baldabzulaufen, so ist es Aufgabe dieser Komponenten, den Autor z.B. via Emaildarauf hinzuweisen. Ein weiteres Tatigkeitsfeld dieser Komponente konnte dasFuhren einer Log-Datei sein, welche die Anzahl Kontaktierungen verwaltet undso dem Autor die Erstellung von Zugriffsstatistiken ermoglicht.

Objekt-Anderung

Diese Komponente ermoglicht Anderungen an den Meta-Informationen einesvirtuellen Gegenstuckes. Via Eingabe-Masken unterstutzt es den Autor im An-derungsprozess und kontaktiert im Hintergrund die benotigten Systemkompo-nenten. Eine neue physische Version eines Dokumentes erhalt dabei die selbe IDwie die Vorgangerversion Diese Komponente ubernimmt auch die Verwaltungder Historie von elektronischen Kopien des physischen Dokumentes, sofern esvom Autor gewunscht wird.

4.3 Benutzerunterstutzung

4.3.1 Vermittlungsprozess

Das Prinzip des Vermittlungsprozesses (siehe Abbildung auch 4.3) besteht dar-in, anhand des gedruckten Dokumentes das virtuelle Gegenstuck mit seinenKomponenten und Aktionen zu vermitteln. Ein Benutzer liest hierfur den Bar-code mit seinem Barcode-Leser ein. Auf seinem Rechner (PC, Laptop, PDA,Mobiltelefon etc) sieht er das virtuelle Gegenstuck und seine Komponenten.

Wie dieser Prozess im Detail funktioniert hangt von den beteiligten Barcode-Lesern und Rechnern ab. Die auf dem Markt erhaltlichen Barcode-Leser bietenunterschiedliche Funktionalitaten an (siehe Abschnitt 3.2). Kombiniert mit den

4.3. BENUTZERUNTERSTUTZUNG 27

Abbildung 4.4: Zusammenspiel der benutzerbezogenen Systemkomponenten

unterschiedlichen Klienten-Plattformen (siehe Abschnitt 3.3) ergeben sich un-terschiedliche Szenarien fur diesen Prozess (siehe Abschnitt 4.1).

4.3.2 Benutzerbezogene Systemkomponenten

ID-Einleser

Diese Komponente liest alle IDs vom Barcode-Leser des Benutzers ein, die diesergespeichert hat. (Kann der Barcode-Leser keine IDs speichern, so wird die aktu-ell gelesene ID ubertragen.) Diese Komponente ist abhangig von Barcode-Leser-Typ und von der Plattform des Klienten-Rechners. Das Realisierungskonzept imAbschnitt 5.4 wird auf diese Schwierigkeit eingehen.

ID-Prufer

Die weite Verbreitung der Barcodes ist auch deshalb moglich gewesen, weil je-der fur eigene Anwendungen, ohne Kenntnisse der Standards, Barcodes erstellenkann. Ein ETHOC-Benutzer kann relativ leicht an einen fremden Barcode kom-men und somit dem ETHOC-System unbekannte Barcodes einlesen.

Der ID-Prufer hat festzustellen, ob eine ID zum ETHOC-System gehoren kann.Indem er die Struktur der ID mit den Eigenschaften einer ETHOC-ID vergleicht.Es konnte aber auch notig sein, dass bei den fremden IDs, die standardisierten,wie UPC und EAN13, erkannt werden mussen, um z.B. auf spezielle Internetsei-ten zu linken. Sollen fremde IDs unterstutzt werden (z.B. EAN13-Barocdes, wiesie auf Bucher zu finden sind), so ist es Aufgabe des Prufers, eine sinnvolleUmleitung auf Internetseiten zu organisieren.

ID-Auflosung

Die Datenverknupfungskomponente hat dafur gesorgt, dass es zu jeder ID einvirtuelles Objekt oder eine Markierung, dass die ID ungultig ist, existiert. Der


ID-Prufer hat sichergestellt, dass keine ID einen falschen Aufbau hat. Aufgabedieser Komponente ist es das virtuelle Objekt zu vermitteln oder gegebenenfallseine Fehlermeldung anzuzeigen.

Personalisierung

Die Praferenzen des Benutzers sollen ebenfalls verwaltet werden. So kann einBenutzer Aktionen automatisch ablaufen lassen. Die Praferenzen zu speichern,ist Aufgabe der Personalisierung-Komponente.

Anzeige und Aktionenstart

Diese Komponente stellt sicher, dass das virtuelle Gegenstuck der Klienten-Plattform entsprechend angezeigt wird. Wie sichergestellt werden kann, dass nurdie Aktionen angezeigt werden, die auch auf der Klienten-Plattform ausfuhrbarsind, muss bei der Konzeption behandelt werden. Des weiteren sollen Aktionen,die der Benutzer als automatisch ablaufend deklariert hat, ohne weiteres Zutungestartet werden. Ob und wie dies gehen kann, soll ebenfalls bei der Konzeptiongeklart werden. Ebenfalls gilt es zu klaren, dass der Benutzer sicher sein kann,dass keine verborgenen Aktionen ablaufen konnen

ID-Verwaltung

In gewissen Szenarien kann es wunschenswert sein, eine ID fur den spaterenGerauch aufzubewahren. Zum Beispiel, weil weitere Informationen fur einenspateren Zeitpunkt angekundigt worden sind (etwa eine Musterlosung zu ei-ner Ubung). Eine gespeicherte ID soll auf Wunsch des Benutzer sofort nach-prufen, ob das virtuelle Gegenstuck sich verandert hat. Andernfalls stellt dieID-Verwaltung beim Start automatisch fest, welche IDs neuere Inhalte aufwei-sen als die lokal gespeicherten. Bei einem solchen Update soll nach Moglichkeitdie exakte Veranderungen angezeigt werden. Benutzer welche sich entschiedenhaben, eine ID verwalteten zu lassen, werden also von Anderungen am virtuellenGegenstuck in Kenntnis gesetzt, alle anderen nicht.

Eine Frage die es zu beantworten gilt, ist, ob die Verwaltung lokal oder globalsein soll. In der globalen Variante verfugt der Benutzer von jedem Gerat aus dieselben Barcodes. In der lokalen hat er pro Gerat eine eigene Verwaltung.

Benutzer-Notifikation

Auch auf Benutzerseite gibt es eine Notifikation, in welcher sich ein Benutzerfur ein virtuelles Gegenstuck einschreiben kann, um sich uber Anderungen z.B.via SMS oder Email informieren zu lassen.

4.4 Zusammenfassung

Bis anhin wurden die wesentlichen Anforderungen furs ETHOC-System zusam-mengestellt. Es wurden auch Fragen aufgeworfen, die zum Teil bereits beantwor-

4.4. ZUSAMMENFASSUNG 29

tet werden konnten oder in den nachsten Kapiteln noch zu beantworten sind.Dieser Abschnitt fasst die Fragen und bissherige Erkenntnisse zusammen.

1. Es muss noch geklart werden, ob es eine Registrierungspflicht fur Autorengeben soll oder ob jeder direkt publizieren kann. Eine Eingrenzung derAnzahl ETHOC-Autoren auf bestimmte Endungen in der Email-Adresseist ebenfalls denkbar.

2. Jede vergebene ID verweist auf ein virtuelles Gegenstuck oder ist als un-gultig markiert. Die Eindeutigkeit der ID eines Barcodes wird selbst beieinem Absturz der Komponente ID-Koordinator resp. des Gesamtsystemsgarantiert.

3. Die Online-Kopien mussen nicht identisch zu den physischen Dokumentensein. Im Falle der Bestandenen-Liste im Abschnitt 2.1.2 sind sogar Online-Kopien unerwunscht.

4. Der Autor hat die Wahl, ob bei einer Anderung des physischen Doku-mentes die gleiche oder eine neue ID vergeben werden soll. Allfallige ver-schiedene Versionen der physischen Dokumente konnen als elektronischeKopien in einer Historie verwaltet werden. Ergeben sich Anderungen amvirtuellen Gegenstuck, so fallen diese nur jenen Benutzern auf, welche dieID noch nicht geloscht oder die sich bei der Benutzer-Notifikation einge-tragen haben.

5. Die virtuellen Gegenstucke verfugen uber ein Ablaufdatum, um der Spei-cherlast des ETHOC-Systems entgegenzuwirken. Die Autoren konnen be-stimmen, wie viele Tage vor dem Verfallsdatum sie via Email kontaktiertwerden sollen, um zum Beispiel die Gultigkeit zu verandern. Abgelau-fenen Barcodes werden von der Komponente ID-Auflosung erkannt. DieBehandlung fremder Barcodes geschieht in der ID-Prufer-Komponente.

6. Das Aussehen und die Funktionalitat eines minimalen virtuelles Gegen-stuckes muss ebenfalls geklart werden. Aber auch Fragen zum physischenDokument gilt es zu klaren. Wie kommt der Barcode zum Dokument undwie flexibel ist die Positionierung? Soll zusatzlich zum Barcode eine furden Menschen lesbaren Form der ID angebracht werden? Nach welchemKodierungsstandard sollen die ETHOC-Barcodes kodiert werden?

7. Das Management der unterschiedlichen Betriebssysteme der Klienten wirdin der ID-Lese-Komponente behandelt. Welche Klienten unterstutzt wer-den sollen, wird ebenfalls in der Komponente ID-Leser behandelt. DieAnzeige-Komponente sorgt dafur, dass nur diejenigen Aktionen anzeigtwerden, die auch auf der Klienten-Plattform ausfuhrbar sind. Dabei kon-nen die Benutzer des Systems unterscheiden, ob eine Aktion moglich,(noch) nicht moglich oder neu ist. Aktionen sind auf spater verschiebbar,falls IDs verwaltet werden konnen. Mobiltelefone konnen Telefonnummernals Links anbieten, sofern sie das WTA-Interface unterstutzen.

8. Auf Benutzerseite sind weitere Fragen offen. Die ID-Verwaltung kann glo-bal mittels eines Profils oder lokal organisiert werden. Es gilt zu klaren,welche zu einer ID gehorenden Aktionen automatisiert ablaufen. Dabei


muss darauf geachtet werden, dass keine verborgenen Aktionen ablaufenkonnen. Das Andern von Terminen in virtuellen Gegenstucken fuhrt da-zu, dass Eintrage in den Kalendern und Agenden geandert werden. Esmuss abgeklart werden, ob der vCalendar-Standard, ein Standard zumAustausch von elektronischen Terminen, ein Verschieben von Terminenerlaubt. Wenn nicht, muss eine andere benutzerfreundliche Losung gefun-den werden.

Kapitel 5

Konzepte fur dasETHOC-System

In diesem Kapitel werden mehrere Varianten zur Losung von Problemen desETHOC-Systems erarbeitet, bewertet und diskutiert. Am Ende dieses Kapitelswird zusammengefasst und entschieden, welche Varianten ins ETHOC-Systemeinfliessen sollen.

5.1 Barcode-Erstellung

In Abschnitt 3.1.1 sind die beiden am haufigsten verwendeten Kodierungsformenfur Barcodes vorgestellt worden. In dieser Arbeit wird der Code 128 verwendet,da er aufgrund seiner hohen Dichte weniger Platz als ein 39-Code in Anspruchnimmt. Zudem sieht dieser Standard eine Prufsumme vor. Eine noch hohereDichte ist zu erreichen, wenn nur Ziffern kodiert werden (siehe Abbildung 5.1).Auf zweidimensionale Barcodes wird verzichtet, weil die Lesegerate teurer sind.

Die maximale Anzahl der Nutzdatenzeichen in einem 128er Strichkodesymbolbetragt 48 Zeichen (siehe z.B. EAN Schweiz [14]). Allerdings haben Tests miteinem Symbol-CS-2000-Barcode-Leser ergeben, dass dieser 20 Zeichen problem-los verarbeitet. Ab 21 Zeichen muss der Leser sehr prazise ausgerichtet werden,und selbst dann geht das Lesen erst nach mehrmaligen Versuchen. Die maxi-male ID-Lange fur dieses Gerat darf 20 Zeichen nicht uberschreiten. Es ist aberanzunehmen, dass andere Gerate ahnliche Schwierigkeiten haben. Aus diesem

Abbildung 5.1: Code 39 vs. Code 128

31

32 KAPITEL 5. KONZEPTE FUR DAS ETHOC-SYSTEM

Grund ist beim Bestimmen der maximalen ID-Lange in Abschnitt 5.2 noch einSicherheitsabstand einzurechnen.

5.2 Objekt-ID

Um ein virtuelles Gegenstuck zu einem Dokument resp. Objekt zu vermitteln,mussen beide uber eine gemeinsame ID verknupft sein. Der ID-Koordinatordes ETHOC-Systems muss garantieren, dass keine zwei physischen Objekte diegleiche ID haben konnen. Trotz allfalligen Absturzen oder Duplizierungen zurLeistungssteigerung der fur die ID-Generierung verantwortlichen Komponentenmuss die Eindeutigkeit gewahrleistet bleiben.

5.2.1 Hashwert als ID

Die erste Variante spielt mit dem Gedanken, dass jeder Autor ohne Verbindungzum Internet (z.B. uber eine lokale Software) in der Lage ist, einen Barcode zubeziehen. Hierzu wird ein Hashwert uber das ganze Dokument gebildet, demer als ID dient. Wenn der Funktionswert-Raum genugend gross ist, wird eskeine Kollisionen geben, d.h. ist der Hashwert genugend gross, wird die Wahr-scheinlichkeit, dass zwei Dokumente dieselbe ID haben, ausserst gering sein.Dennoch ist diese Moglichkeit vorhanden. Eine Anderung am physischen Doku-ment wurde zudem zwangslaufig zu einer neuen ID und somit zum Verlust desvirtuellen Gegenstuckes fuhren. Deshalb wird diese Variante nicht in Betrachtgezogen.

5.2.2 Globaler Zahler als ID

Die Idee hinter dieser Variante ist, dass global eine laufende Nummer als IDvergeben wird. Bei einem Absturz des ID-Koordinators ist sichergestellt, dasskeine ID doppelt vergeben wird. Es muss lediglich nach dem Neustart die Da-tenhaltung nach der letzten eingetragenen ID befragt werden.

Dies funktioniert gut, solange das ETHOC-System nur auf einem Server lauft.Wird spater aber entschieden, aufgrund der Lastverteilung mehrere ID-Koordi-natoren zu installieren, so mussen diese mit dem Augenmerk auf gegenseitigenAusschluss neu geschrieben werden. Die ID-Vergabe musste sogar neu konzep-tioniert werden, da ein globaler Zahler fur verteilte Applikationen einen zu hohenAufwand und ein zu hohes Verkehrsaufkommen zur Folge hatte. Mit Hinblickauf eine zukunftige Verteiltheit wird diese Variante nicht weiter in Betrachtgezogen.

5.2.3 Tag-URI als ID

Tim Kindberg und Sandro Hawke beschreiben in ihrem Internet-Draft [13] eineURI (Uniform Ressource Identifier) namens “tag”, der die Eindeutigkeit derIdentitat ohne zusatzliche Registrierungskosten uber Raum und Zeit garantiert.Der erste Teil der Tag-URI beginnt mit dem Schlusselwort “tag:” gefolgt von

5.2. OBJEKT-ID 33

der sogenannten Tag-Autoritat – einer Domain oder Email-Adresse. Nach einemKomma folgt das Datum, an dem die Tag-URI bezogen worden ist. Dieser ersteTeil stellt sicher, dass sich zwei Parteien nicht in die Quere kommen. Denn jederbesitzt zu einem gewissen Zeitpunkt eindeutig eine Domain oder zumindest eineEmail-Adresse. Den zweiten Teil vergibt jede Tag-Autoritat autonom. Sie mussselbst sicherstellen, dass ihre Dokumente eine noch nicht vergeben ID erhalten.Hierfur sind jegliche gultigen URI-Zeichen erlaubt. Beispiele solcher Tag-URIssind:tag:vis.ethz.ch,2001-10-23:filmplakattag:[email protected],2001-11-01:123456789

Das Problem der Tag-URIs ist ihre Lange. Barcode-Leser konnen nach Typ nureine beschrankte Barcodelange lesen (siehe Abschnitt 5.1). Im letzten Beispielsind 28 Zeichen allein fur die Tag-Autoritat verbraucht. Dies ist die Standard-Lange fur Studenten-Email-Adressen an der ETH. Weitere 11 Zeichen sind furdas Datum bestimmt. Mochte also ein ETH-Student ein eindeutiges Dokumentveroffentlichen mussen mindestens 41 (28 + 11 + 2) alphanumerische Zeichenkodiert werden.

Die Tag-URIs gehen fur ETHOC zu weit. Es muss nicht jeder Autor eineneigenen ID-Koordinator haben. Es genugt wenn einige wenige ID-Koordinato-ren im Web vorhanden sind. Es ist auch anzunehmen, das die URLs der ID-Koordinatoren langlebiger sein werden als die virtuellen Gegenstucke. Also waredie Kodierung der Zeit in die Tag-URI Platzverschwendung.

5.2.4 ETHOC-Tag als ID

In diesem Abschnitt wird eine Variante vorgestellt, welche die Vorteile der vor-herigen Losungen kombiniert. Das Hauptproblem bei den Tag-URIs ist, dasszu viele Zeichen verbraucht werden, um die Tag-Autoritat zu bestimmen. InETHOC sind die ID-Koordinatoren die Tag-Autoritaten. Die Anzahl kann vomETHOC-System kontrolliert werden. Also kann jeder ID-Koordinator eine ein-deutige ID vom ETHOC-System erhalten (z.B. aufsteigend durchnummeriert).Innerhalb seines Kontextes (seiner Koordinator-ID) kann jeder ID-Koordinatorselber eindeutige IDs vergeben, indem er z.B. die Anfragen aufsteigend num-meriert. Fallt ein ID-Koordinator aus, so erfragt er beim Neustart seine eigeneID und die letzte ID, die er vergeben hat. Da die Datenhaltung persistent ist,kann er sicher sein, dass keine ID doppelt vergeben worden ist. Ist der ID-Koordinator nicht registriert, so erhalt er eine neue ID und kann die Anfragenbei null beginnend durchnummerieren. Das Identifizieren des ID-Koordinatorkann aufgrund seiner IP-Adresse erfolgen. Deshalb muss sichergestellt werden,dass pro Rechner keine zwei ID-Koordinatoren gleichzeitig laufen.

Ein ETHOC-Tag wird festgelegt als eine Zahlenfolge bestehend aus der Ko-ordinator-ID (z.B. vierstellig) und der Zahl, welche der ID-Koordinator zuge-wiesen hat (z.B. sechsstellig). Durch eine feste Stelligkeit, sind alle Barcodesgleich lang und es kann einfacher unterschieden werden, ob der Barcode zumETHOC-System gehort. Alle Barcodes mit einer Lange gleich zehn sind potenti-elle ETHOC-IDs und mussen aufgelost werden, um festzustellen, ob es wirklichein virtuelles Objekt gibt. Hat ein ID-Koordinator sein Kontingent erschopft,so kann er eine neue Koordinator-ID verlangen und von vorne beginnen.


Abbildung 5.2: Variante Webservice

Die fixe Stelligkeit schafft aber ein neues Problem ahnlich der fixen IP-Adressen-Lange oder der fixen UPC-Lange; Irgendwann sind alle IDs vergeben. Eine ma-ximale Barcode-Lange muss aber vorgegeben werden, denn die Leser konnennicht beliebig lange Barcodes lesen. Im Kapitel 5.1 ist die maximale ID-Langediskutiert worden. Eine Lange von zwanzig Ziffern erlaubt 1020 IDs. Dies genugt,um die Erdoberflache 12’228 Mal mit A4-Dokumenten zu bedecken. Wurde proSekunde eine Million Dokumente registriert, wurde die Nummerierung fur 3.2Millionen Jahre reichen. In diesem Projekt ist die Lebensdauer des Systems nichtvon hoher Prioritat. Es soll ein Prototyp, zu Demonstrationszwecken sein. Ausdiesem Grund wurde die Lange der IDs auf zehn Stellen festgelegt. Wenn proSekunde zehn Dokumente registriert wurden, reichte die Nummerierung immernoch fur 3 Jahre. Sollte das System spater zum produktiven Einsatz kommen,kann eine grossere Lange festgelegt werden. Ruckwartskompatibilitat ware ein-fach realisierbar. Das System wurde dann zwei Barcode-Langen als seine eigenenakzeptieren.

5.3 Varianten im Erstellungsprozess

In diesem Abschnitt werden drei Varianten fur den Erstellungsprozess vorgestelltund die jeweiligen Konsequenzen fur die System-Komponenten erlautert. DieVarianten werden evaluiert und es wird eine Variante fur die Implementierungausgewahlt.

5.3.1 Webservice

In der Webservice-Variante (siehe Abbildung 5.2) ist das ETHOC-System kom-plett online. Nachdem der Autor sein Dokument, das er mit einem Barcode ver-sehen mochte, fertiggestellt hat, kontaktiert er das Autoren-Portal im Internet.Er gibt seine Autoren-ID und sein Passwort ein und wird zur Objekterstellungweitergeleitet, in welcher er Angaben zu seiner Person und zum Dokument –sogenannten Meta-Informationen – machen soll. (Im Abschnitt 5.5 werden die

5.3. VARIANTEN IM ERSTELLUNGSPROZESS 35

moglichen Metadaten und Aktionen diskutiert.) Des weiteren kann der Autorzusatzlich relevante Dokumente hochladen. Der Autor erhalt einen Barcode ineinem Bild-Format seiner Wahl zuruck, welchen er nun in sein Dokument aneine beliebige Position zu platzieren hat, bevor er das Dokument druckt undveroffentlicht. Wunscht der Autor, dass sein Dokument auch elektronisch ver-waltet werden soll, so muss er es, nachdem er es mit dem Barcode erganzt hat,hochladen. Dazu benutzt er wieder die URL des Autoren-Portals.


Die Autorenidentifikation ist fur das Erstellen eines neuen virtuellen Gegen-stuckes nicht zwingend notwendig. Doch spatestens, wenn ein Autor ein be-stehendes virtuelles Gegenstuck andern will, muss er sich als Autor ausweisenkonnen. Durch die Authentifizierung kann dem Autor auch Arbeit abgenommenwerden, in dem zum Beispiel die Autorenangaben automatisch beim Erstelleneines neuen virtuellen Gegenstuckes eingefugt werden.

Die weitere Aufgabe dieser Komponente, dem Autor die vorhandenen Werkzeu-ge zu prasentieren und ihn an das Werkzeug seiner Wahl weiterzuleiten, kannkombiniert werden mit der Bestatigung des erfolgreichen Logins.

Objekt-Erstellung

In dieser Variante ist diese Komponente ein HTML-Formular, welches Benut-zereingaben entgegennimmt. Das minimale Dokument besteht hier aus den An-gaben zum Autor und zum Dokument. Eine Online-Kopie des Dokumentes kannveroffentlicht werden. Dies sollte aber erst geschehen, wenn das Dokument vomAutor mit dem Barcode versehen worden ist.

ID-Koordinator

Der ID-Koordinator wird Tags, wie in Abschnitt 5.2 besprochen, vergeben. Erist Teil des Autoren-Portals und somit online.

Barcode-Erzeugung

Es wird der Code 128 nach Abschnitt 5.1 verwendet. Ebenfalls sinnvoll ist denBarcode in eine fur den Menschen lesbaren Kodierung zu erganzen. In dieserVariante wird der Barcode als Bild dem Autor ubergeben. Dieser hat ihn andie Stelle seiner Wahl im richtigen Dokument zu platzieren. Eine Gefahr dieserUmsetzung, ist, dass der Autor die Barcodes vertauscht und in die falschenDokumente einpflanzt. Dies sollte ihm aber nach einem Test auffallen. Der Testkann nicht automatisiert werden, da der Autor bei einem Scann-Vorgang nichtvon einem normalen Benutzer unterschieden werden kann. Sobald der Autorim Besitz des Barcodes ist, kann er vom System nicht zu weiteren Tatigkeitengezwungen werden, also auch nicht zu einem Test.

Dadurch, dass Barcodes als Bilder ubergeben werden und der Autor das Bildselber ins Dokument einbaut, ist es moglich, mehrere Barcodes in ein Dokument


einzubauen. Es kann somit moglich fur jeden Abschnitt in einem Dokumentein eigenes virtuelles Gegenstuck erstellt werden. Es wird also weiterhin provirtuelles Gegenstuck nur einen Barcode geben. Wunscht also der Autor mehrereBarcodes fur ein physisches Dokument, so muss er pro Barcode ein virtuellesGegenstuck einrichten, dass das gewunschte Verhalten modelliert.

Datenhaltung

Die Datenhaltung wird als Datenbank umgesetzt, welche auf Transaktionsbasisalle Angaben persistent speichert. Ein weiterer Teil der Datenhaltung ist dasLoschen von abgelaufenen IDs und damit verknupfter Dokumente. Dies kann inder Datenbank als zeitgesteuerter Trigger oder als eigenstandiger Java-Threadimplementiert werden. Im letzten Fall muss die Datenbank eine Schnittstellezum Loschen nach aussen anbieten.

Die Angaben des Autors (zu seiner Person und zum Dokument) mussen mitder ID verknupft werden. Diese Informationen werden strukturiert in einemXML-Dokument abgelegt, welches mit der ID verknupft in der Datenbank ab-gespeichert wird. Hochgeladene Dateien werden ebenfalls im XML-Dokumentvermerkt und in der Datenbank gespeichert. Das XML-Dokument bildet dieStruktur des virtuellen Gegenstuckes. Die genaue XML-Struktur wird im Ab-schnitt 7.1 erlautert. Um Angaben, die regelmassig vom System benotigt werden(wie z.B. Dokumenttitel und Ablaufdatum) schneller zur Hand zu haben, wer-den diese zusatzlich auch als Attribute in Tabellen der Datenbank gespeichert.Will das ETHOC-System nach abgelaufenen Dokumenten suchen, genugt nunein Nachschauen in der Tabelle. Ohne Redundante Speicherung mussten alleXML-Strukturen nach der Informationen einzeln durchsucht werden, was sehrzeitintensiv ware.


Diese Komponente wird als Thread implementiert und pruft in regelmassigenZeitintervallen nach virtuellen Gegenstucken, die bald ablaufen. Entdeckt siesolche, kontaktiert sie die Autoren z.B. via Email mit einem entsprechendenHinweis.

Objekt-Anderung

Diese Komponente besteht aus Eingabefeldern fur den Autor, in welchem diebereits von ihm getatigten Eingaben vorgegeben sind. Hierfur bedient sie sich desXML-Dokumentes und transformiert es anhand eines XSLT-Dokumentes in dasHTML-Formular, das der Autor sieht. Anderungen werden im XML-Dokumentvollzogen und die entsprechenden Dateien in die Datenbank geschrieben, resp.von der Datenbank entfernt.

Da der Autor den Barcode als Bild in sein Dokument integriert, sind Anderungenam physischen Dokument ohne Aufwand moglich, weil das Bild dabei nichtverandert werden muss. Es bleibt aber in der Verantwortung des Autors, beisubstantiellen Anderungen das virtuelle Gegenstuck anzupassen.


Abbildung 5.3: Variante logischer lokaler Drucker

Diese Komponente sollte, sofern es der Autor wunscht, in der Lage sein, eineHistorie aller hochgeladenen elektronischen Kopien des physischen Dokumenteszu verwalten. Der Autor soll in der Lage sein, auszuwahlen, welche Online-Kopien Teil der Historie sein sollen.

5.3.2 Logischer lokaler Drucker

In dieser Variante besteht das ETHOC-System aus zwei Komponenten – ei-nem logischen lokalen Drucker, welcher eine lokale Autoren-Identifikation, dieObjekt-Erstellung, die Barcode-Erzeugung und einen Proxy des ID-Koordina-tors umfasst und einem reduzierten Autoren-Portal, das aus online Autoren-I-dentifikation und Objekt-Anderung besteht(siehe Abbildung 5.3).

Ein Autor installiert den logischen lokalen Drucker als Druckertreiber auf sei-nem Rechner. Uber den Drucken-Befehl jeder Software wird das zu druckendeDokument an den logischen lokalen Drucker weitergeleitet, der dem Benutzereine Vorschau anzeigt und ihn um weitere Eingaben, wie freie Positionierungdes Barcodes und Meta-Informationen, bittet. Ist alles erledigt, kann der Autoreinen anderen Druckertreiber seines Systems auswahlen, um zum Beispiel dasmittlerweile um den Barcode erweiterte Dokument zu drucken oder um es in einePDF-Datei zu transformieren. (Eine Software, die als Drucker-Treiber installiertwird, ist FinePrint[15]. Sie bietet eine Vorschau-Funktion der zu druckenden Da-tei(en) an. Der Benutzer kann z.B. mehrere Seiten auf eine A4-Seite verkleinernund das neue Dokument an seinen Drucker senden. Die hier vorgeschlagene Va-riante hatte fur den Autor einen ahnlichen Benutzerkomfort.) Der logische lokaleDrucker kommuniziert im Hintergrund mit dem ID-Koordinator, der weiterhinfur die eindeutige Generierung der ID und Ablage der Daten in der Datenbankzustandig ist.

Bei dieser Variante muss der Benutzer wahrend dem “Drucken” online sein.Wurde man darauf verzichten und den Proxy intelligenter machen (z.B. in-dem er selbst IDs vergibt und die Informationen bis zu einer spateren Online-


Verbindung verwaltet), hatte man die Gefahr von Inkonsistenzen. So konnteein Dokument ausgehangt werden, dass vom ETHOC-System noch nicht erfasstworden ist. Die Bandbreite des Internetanschlusses spielt keine Rolle, wenn da-von ausgegangen wird, dass das Dokument nicht zwingend auch elektronischverfugbar sein muss.

Will der Autor Anderungen am virtuellen Dokument durchfuhren, so muss ersich eines anderen Mechanismus als des Druckens annehmen. Eine Idee ware,im Internet ein Werkzeug zum Andern und Erganzen von Meta-Informationenanzubieten.


Fur die Komponenten Objekt-Erstellung und Objekt-Anderung sind zwei unter-schiedliche Autoren-Identifikationen notig. Fur ersteren lokal und fur letzterenonline. Somit existieren zwei Einstiegspunkte. Die Autorenidentifikation fur dieErstellung eines virtuellen Dokumentes muss nicht mit einem Einloggen verbun-den sein. Die Daten wurden bei der Installation des logischen lokalen Druckerserhoben. Der logische lokale Drucker kann auf diese Informationen zugreifen undsomit die Eingabefelder fur den Autor automatisch ausfullen. In dieser Varianteist der Autorenkreis auf diejenigen eingeschrankt, die den Drucker installierthaben.

Objekt-Erstellung

Die Erstellung der Meta-Informationen findet teilweise im logischen lokalenDrucker und teilweise online statt. Die Angaben werden im logischen loka-len Drucker erhoben. Die Koordination der beteiligten Komponenten, wie ID-Vergabe Datenverknupfung und -Ablage geschieht online. Der Barcode kannlokal oder online erzeugt werden. Die Einbettung ins Dokument geschieht lokal.

Das minimale Dokument besteht aus den Angaben zum Autor und zum Do-kument. Eine Online-Kopie des Dokumentes kann aber sofort ubermittelt wer-den, da der Einbau des Barcodes im lokalen Drucker geschieht. Eine allfalligeUbermittlung des Dokumentes inkl. Barcode setzt eine ausreichende Bandbreitevoraus.

ID-Koordinator

Der ID-Koordinator wird Tags, wie in Abschnitt 5.2 diskutiert, vergeben. Er istTeil des Autorenportals und somit online.

Barcode-Erzeugung

Die Barcode-Erzeugung geschieht wie in Abschnitt 5.1 beschrieben. Auch hierwird zusatzlich eine fur den Menschen lesbaren Kodierung angebracht.

In dieser Variante wird der Barcode vom lokalen Drucker direkt ins Dokumenteingebaut. Die Positionierung ist per Drag-and-Drop flexibel. Es ist aber nichtmoglich, mehrere Barcodes in ein Dokument einzubauen.


Abbildung 5.4: Variante logischer Online-Drucker

Datenhaltung

Die Datenhaltung ist, wie in der Variante zuvor (siehe Abschnitt 5.3.1), alsDatenbank umgesetzt.


Ist wie in der ersten Variante (siehe Abschnitt 5.3.1) zu implementieren.

Objekt-Anderung

Anderungen am virtuellen Dokument mussen uber eine Internet-Schnittstelleerfolgen. Das Andern des physischen Dokumentes erfordert eine Erweiterungdes logischen lokalen Druckers. Es darf nicht immer automatisch eine neue IDvergeben werden. Es muss gefragt werden, ob der Autor eine neue ID wunschtoder ob eine an ihn vergeben ID verwendet werden soll. Hierbei muss der Autorvorsichtig sein, um nicht versehentlich den falschen Barcode in sein Dokumenteinzubauen.

Wie in der ersten Variante soll diese Komponente in der Lage sei, eine Histo-rie aller hochgeladenen elektronischen Kopien des physischen Dokumentes zuverwalten. Der Autor soll in der Lage sein, auszuwahlen, welche Online-KopienTeil der Historie sein sollen.

5.3.3 Logischer Online-Drucker

Die Variante Online-Drucker sieht vor, dass der Autor zuerst eine Postscript-oder PDF-Datei erstellt. Diese kann uber den Drucken-Befehl und einem geeig-neten Druckertreiber geschehen. Diese Datei ladt er via eine Web-Schnittstellezum Autoren-Portal hoch und gib die Meta-Informationen ein.

Der Barcode wird in sein Postscript-Dokument eingebaut. Der Autor kann diePosition des Barcodes durch die Angabe der Ecke oder Kante (evtl. exakt unter


Eingabe von Koordinaten) beeinflussen. Er erhalt das Dokument nach Auswahlentweder als PDF- oder als PS-Datei zuruck. Auf Wunsch kann das Dokumentgleich online hinterlegt werden.


In dieser Variante wird, wie in der ersten Variante (siehe Abschnitt 5.3.1) vor-geschlagen, die Autorenidentifikation via Login implementiert.

Objekt-Erstellung

Wie in der ersten Variante (siehe Abschnitt 5.3.1) ist diese Komponente einHTML-Formular, welches Benutzereingaben entgegennimmt.

Das minimale Dokument besteht hier ebenfalls aus den Angaben zum Autor undzum Dokument. Eine Online-Kopie des Dokumentes kann aber sofort eingebautwerden, da es sich bereits online befindet und online um den Barcode erganztwird.

ID-Koordinator

Der ID-Koordinator wird ETH-Tags, analog zu Abschnitt 5.2 vergeben.

Barcode-Erzeugung

Die Barcode-Erzeugung geschieht wie in Abschnitt 5.1 beschrieben. Auch hierwird zusatzlich eine fur den Menschen lesbaren Kodierung angebracht.

In dieser Variante wird der Barcode online ins hochgeladene Dokument einge-baut. Die Positionierung kann grob via Angabe von Ecken, Kanten und Seitendes Dokumentes erfolgen oder evtl. flexibel via Eingabe von Koordinaten undSeitennummer. Es ist nicht moglich, mehrere Barcodes in ein Dokument einzu-bauen.

Datenhaltung

Die Datenhaltung ist wie in den Varianten zuvor (siehe Abschnitt 5.3.1 und5.3.2) als Datenbank umgesetzt.


Ist wie in den ersten beiden Varianten (siehe Abschnitt 5.3.1 und 5.3.2) zuimplementieren.


Webservice⊕ Einfache Handhabung: Barcode manuell als Bild in der Anwendung des

Autors positionierbar.⊕ Physisches Dokument kann vom Autor ohne zusatzliches Werkzeug

geandert werden.⊕ Beliebig viele Barcodes in ein Dokument einbaubar.� Barcodes losgelost von Dokumenten moglich. D.h. sie konnen auf Eti-

ketten gedruckt werden und an Objekte angebracht werden. Verwechslungsgefahr von Barcodes: Barcode wird als Abbildung durch

den Autor eingebaut. Nicht jede Anwendung erlaubt das Einbetten von Bildern (z.B. reine

Text-Datei).

Tabelle 5.1: Evaluation Webservice

Logischer lokaler Drucker⊕ Einfache Handhabung: Autor muss nur drucken.⊕ Einfache exakte Positionierung mittels Drag-and-Drop. ID-Verschwendung durch unachtsame Benutzer. (Das selbe Dokument

mehrmals drucken.) Anbringen falscher Barcodes durch unachtsame Benutzer im Falle einer

Anderung Kein gemeinsamer Einstiegspunkt fur die Autoren-Werkzeuge. (Der Me-

chanismus, um Metadaten einer bestehenden Registrierung zu andern,kann nicht uber das Ducker-Paradigma erledigt werden.)

� Drag-and-Drop-Positionierung des Barcodes zu aufwendig als Bestand-teil dieser Diplomarbeit.

� grobe Positionierung durch Verwendung des Fine-Print-API moglich,aber dann muss eine lizenzierte Version bei jedem Klienten installiertwerden (nur unter Windows moglich).

Tabelle 5.2: Evaluation lokaler Druckertreiber

Objekt-Anderung

Diese Komponente ist, wie in der ersten Variante (siehe Abschnitt 5.3.1), einHTML-Formular, um Anderungen am virtuellen Dokument auszufuhren. Diealten Online-Kopien der physischen Dokumente konnen auf Wunsch des Autorsin einer Historie verwaltet werden. Der Autor soll in der Lage sein, auszuwahlen,welche Online-Kopien Teil der Historie sein sollen.

5.3.4 Varianten-Evaluation

Die Starken und Schwachen der einzelnen Varianten sind in den Tabellen 5.1,5.2 und 5.3 festgehalten.

Der Vorteil des einfachen Druckerparadigmas der Variante logischer lokalerDrucker und den damit verbundenen hohen Benutzerkomfort erweist sich als


Logischer Online-Drucker⊕ Einheitliche Benutzerschnittstelle zum Erfassen und zum Andern von

Metadaten.⊕ Kein “Vertauschen” von Barcodes moglich.⊕ Maschinelle Positionierung. Das Dokument muss vom Autor in eine PS- oder PDF-Datei transfor-

miert werden. Entsprechender Treiber muss installiert sein. Positionierung uber Koordinatenangaben (alternativ Angabe von Ecken

oder Kanten). Hohe Bandbreite im Moment der Barcode-Vergabe notig: Dokument

wird zum Autoren-Portal und wieder zuruck geschickt.

Tabelle 5.3: Evaluation Online-Drucker

Nachteil, wenn die Autorenwerkzeuge als ganzes betrachtet werden. Es ist nichtmoglich, alle Werkzeuge ins Druckerparadigma einzubauen. Somit gibt es meh-rere Einstiegspunkte fur den Autor. Beide Werkzeuge haben zudem ein un-terschiedliches Aussehen. Aus ergonomischer Sicht gesehen sind diese Punkteschwerwiegende Nachteile. Der Realisierungsaufwand fur die freie Positionie-rung via Drag-and-Drop durfte den Rahmen dieser Diplomarbeit sprengen, daes mit der Programmierung eines Druckertreibers und einer Applikation zurPositionierung verbunden ware. Das Einbinden von FinePrint erlaubt nur ei-ne grobe Positionierung. Zudem musste bei jedem Klienten (eingeschrankt aufWindows-Rechner) eine lizenzierte Version von FinePrint installiert sein.

Das Andern des physischen Dokuments fuhrt ohne weiteres Zutun zum Verlustdes Barcodes und des virtuellen Gegenstuckes. Da dies nicht immer erwunschtist (z.B. bei Korrektur von Rechtschreibfehlern), muss eine entsprechende Er-weiterung beim logischen lokalen Drucker erstellt werden, die es erlaubt, einenbestehenden Barcode erneut zu beziehen. Allerdings sind dann Verwechslungenmoglich, wenn ein Barcode z.B. anhand des Titels des Dokumentes ausgewahltwird. Aus diesen Grunden wird der logische Online-Drucker dem logischen lo-kalen Drucker vorgezogen. Dieser sieht fur das Erstellen und das Andern eineeinheitliche Benutzerschnittstelle vor. Zudem ist ein Verwechseln der Barcodesnicht mehr so einfach moglich. Der logische lokale Drucker kann aber spater alszusatzliches Werkzeug erstellt werden, der das ETHOC-Portal erganzt.

Setzt man voraus, dass die Studenten und Mitarbeiter der ETH einheitlicheUmgebungen haben und die Arbeit an der ETH erledigt wird, fallen die bei-den Negativ-Punkte “PS/PDF-Transformierung” und “hohe Bandbreite” derVariante logischer Online-Drucker weg. Es gilt also noch abzuwagen, ob die Ge-fahr einer Barcode-Verwechslung zugunsten der beliebigen Positionierung desBarcodes in der Applikation des Autor statt durch Koordinatenangaben resp.grobe Positionierung in Kauf genommen werden soll. Da es anzunehmen ist,dass die Autoren gerne die Kontrolle uber das Layout ihrer Dokumente behal-ten, ist die Variante Web-Service vorzuziehen. Es ist aber auch moglich denlogischen Online-Drucker als Bestandteil des ETHOC-Autoren-Portals zu im-plementieren. Als eigenstandiges Werkzeug ist dies aber nicht zu empfehlen,da das Portal mit zu ahnlichen Werkzeugen den Autor verwirren und er es alsuberladen empfinden konnte .

5.4. VARIANTEN IM VERMITTLUNGSPROZESS 43

Abbildung 5.5: Variante Online-ID-Manager

In allen drei Fallen besteht das minimal mogliche virtuelle Dokument aus denMeta-Informationen. In der Variante Online-Drucker ist das Hinzufugen desDokumentes als Online-Kopie ohne zusatzlichen Mehraufwand moglich. In kei-ner Variante ist es moglich, Barcodes zu beziehen, die nicht auf ein virtuellesGegenstuck verweisen.

Nach Abwagen aller Vor- und Nachteile wird die Variante Web-Service imple-mentiert. Sei erlaubt eine freie Positionierung sowie zusatzlich Barcodes proAbsatze und sogar Barcodes losgelost von Dokumenten.

5.4 Varianten im Vermittlungsprozess

Auch im Vermittlungsprozess sind mehrere Varianten zur Umsetzung moglich.Dieser Abschnitt vergleicht sie und stellt die Konsequenzen fur die System-Komponenten dar.

Die Varianten haben gemeinsam, dass die Komponente “ID-Einleser” von derKlienten-Plattform und noch starker vom Barcode-Leser abhangig ist, da nichtmit jedem Barcode-Leser auf die gleiche Weise kommuniziert werden kann. DerID-Einleser muss fur jeden Barcode-Leser-Typ neu geschrieben werden. Somitwird er nicht als Bestandteil des ETHOC-Systems deklariert. In dieser Ar-beit wird diese Komponente exemplarisch fur einige Leser geschrieben werden.Das ETHOC-System gibt eine Schnittstelle vor, die beschreibt, wie die IDsubergeben werden. Durch dieses Vorgehen ist es moglich, ohne grosseren Pro-grammieraufwand einen Barcode-Leser ins System einzubauen. Der ETHOC-Kode bleibt davon unberuhrt.

5.4.1 Online ID-Manager

In dieser Variante befindet sich der ID-Manager online (siehe Abbildung 5.5).Der ID-Manager umfasst die Komponenten ID-Prufer, ID-Verwaltung und An-zeige, setzt einen Browser beim Klienten voraus und verbraucht sonst keine


eigenen Ressourcen. Er ist somit ideal fur leistungsschwache Gerate. Fur Mobil-telefone ist er sogar zwingend, da auf diesen zur Zeit keine Programme installiertwerden konnen. Mit dem Online-ID-Manager hat jedes Dokument automatischeine eigene Homepage im Netz.

ID-Verwaltung

Neue IDs werden der ID-Verwaltung ubergeben. Die ID-Verwaltung sorgt dafur,dass der Inhalt der neuen und der Inhalt von aktualisierten IDs beim Benutzerangezeigt werden kann. Die Aufgabe, zu einer ID einen passenden Inhalt zu fin-den, uberlasst sie dem ID-Prufer. Jede ID ubergibt sie einzeln an den ID-Pruferund erwartet einen Zeichenstrom in Form von HTML resp. WML, welchen siezur Anzeige-Komponente weiterleitet.

Die Verwaltung der IDs ist lokal oder global moglich.Global bedeutet: Will man Barcodes speichern, um spater darauf zuzugreifen,mussten die Informationen zentral in der Datenbank abgespeichert werden. Eswurde also ein Benutzerprofil erstellt. Bei jedem Auflosen einer ID musste derBenutzer authentifiziert werden, um die Datenbank auf den neuesten Stand zubringen oder um die Daten aus der Datenbank zu lesen. Das Abspeichern vonBenutzerdaten in der Datenbank hat den Vorteil, dass Benutzer, die uber meh-rere Endgerate verfugen, von allen Geraten aus auf ihre Barcodes Zugriff haben.Andererseits konnte das standige Einloggen als Plage empfunden werden. Diesmuss entscharft werden. Die Authentifizierung kann implizit ohne Eingreifen desBenutzers geschehen, indem Klienten-System-abhangige Daten ubertragen wer-den (z.B. Seriennummer des Lesers, wie es bei AirClic der Fall ist) oder indemBenutzername und Passwort lokal gespeichert werden (z.B. Konfigurationsdateioder Cookies). Im ersten Fall muss eine Neukonfiguration durch den Benutzermoglich sein, falls er Hardware wegen Verlust oder Defekt ersetzt. Der Nachteilder globalen Variante ist, dass der Benutzer glasern wird; es kann ein Benutzer-profil erstellt werden.Eine lokale Verwaltung benotigt kein zentrales Benutzerprofil und ist zum Bei-spiel mittels Cookies moglich. So konnten bis zu 20 IDs (so viele Cookies stehenlaut Spezifikation [18] und [19] einem Server pro Klient zur Verfugung) samtDatum der letzten Anderung lokal gespeichert werden und bei jedem Kontak-tieren des Online-ID-Managers neu resolviert werden, um Veranderungen amvirtuellen Dokument festzustellen. Der Nachteil der lokalen Variante ist, dassnicht gesagt werden kann, welcher Bereich des virtuellen Dokumentes sich ge-nau geandert hat. Dies ware nur moglich, wenn man die alte XML-Struktur imCookie abgespeichert hatte. Cookies haben aber laut Spezifikation [18, 19] eineMaximalgrosse von 4’000 Zeichen (Byte).

ID-Prufer

Der ID-Prufer eruiert, ob die ID dem ETHOC-Format entspricht. Auf die Uber-prufung, ob es ein anderer Standardcode ware, wird verzichtet. Alles was vomAufbau her keine ETHOC-ID sein kann, wird als nicht auflosbar angezeigt. D.h.es wird eine Fehlermeldung in HTML oder WML erzeugt. Plausible IDs werdendem ID-Aufloser ubergeben, dessen Antwort, eine XML- und eine XSL-Datei,werden transformiert und das Ergebnis an die ID-Verwaltung weitergeleitet.

5.4. VARIANTEN IM VERMITTLUNGSPROZESS 45

Abbildung 5.6: ID-Manager mit lokaler Komponente

Somit kann fur jeden Klienten-Typen das Ausgabeformat optimiert werden. ImFalle von Mobiltelefonen ware dies WML, in anderen Fallen z.B. HTML. Mitdieser Technologie konnen Aktionen, die nicht auf dem Klienten laufen konnen,ausgeblendet werden.

ID-Aufloser

Diese Komponente besorgt sich aufgrund der ID die XML-Struktur des virtuel-len Gegenstuckes aus der Datenhaltung und ubergibt sie dem Prufer. In jedemHTTP-Request wird der Browser-Typ anhand des User-Agents mitubertragen.Dies kann ausgenutzt werden, um die Ausgabe den Klienten anzupassen. In die-ser Variante wird aufgrund des Agententyps und der ETHOC-ID eine passendeXSL-Datei aus der Datenbank besorgt werden.

Personalisierung

In dieser Variante wird alles im Browser des Benutzers dargestellt. Somit konnenInformationen und Aktionen entweder als Links oder als Text dargestellt wer-den. Die Standard-Sicherheitseinstellung der Browser verbieten automatischeDownloads und den Start von Programmen. Somit ist eine Personalisierung indieser Variante nicht moglich.


Die anzuzeigende Ausgabe wurde bereits durch den ID-Prufer in der Form(HTML oder WML), die der Browser versteht, generiert. Da im Browser alleAktionen uber Links explizit aufgerufen werden mussen, konnen keine verbor-genen Aktionen ausgefuhrt werden.

5.4.2 Variante ID-Manager mit lokaler Komponente

Bei dieser Variante befindet sich der Hauptteil des ID-Managers auf der loka-len Klienten-Plattform, d.h. er muss dort installiert werden. Dies wurde aber


bedeuten, dass keine Mobiltelefone unterstutzt werden konnen, da auf vielenMobiltelefonen keine Software installiert werden kann. Aus diesem Grund be-steht in dieser Variante der ID-Manager nebst der lokalen auch aus einer Online-Komponente. Der ID-Prufer und ein Teil der Anzeige-Komponente befindet sichonline. Die globale ID-Verwaltung ist ebenfalls online. Lokale ID-Verwaltung,Personalisierung und der restliche Teil der Anzeige-Komponente sind Bestand-teil des lokalen ID-Managers.

Neue IDs werden der lokalen ID-Verwaltung ubergeben. Diese synchronisiertsich mit der globalen ID-Verwaltung. Insbesondere werden alle neuen IDs wei-tergeleitet und Updates von verwalteten virtuellen Gegenstucken erkannt. Neueund zu aktualisierende IDs werden einzeln dem ID-Prufer weitergeleitet, welchereine XML-Antwort zuruckgibt. Diese besteht aus der Struktur des virtuellen Do-kumentes ohne jene Angaben, die der Autor nicht publizieren mochte oder auseiner Fehlermeldung, falls die ID nicht aufgelost werden kann. Das Resultat wirddirekt zur Anzeige-Komponente weitergeleitet.

Wird ein Klient benutzt, auf dem keine lokale Software installiert ist, so wirddie ID direkt der globalenVerwaltung zugeschickt. Diese leitet die ID weiter undgibt die HTML/WML-Antwort an die online Anzeige-Komponente weiter.

ID-Verwaltung

Die ubermittelten XML-Dateien konnen gespeichert und bei einem Updatedurch diese Komponente auf Veranderungen verglichen werden. Somit ist esmoglich, genaue Anderungen auszumachen. Die lokale Verwaltung wird mit derzentralen Historie der globalen ID-Verwaltung abgeglichen, um alle IDs auf allenGeraten zu haben. Die globale ID-Verwaltung speichert lediglich die IDs ohneXML-Inhalt.

ID-Prufer

Der ID-Prufer ist identisch mit dem der ersten Variante (siehe Abschnitt 5.4.1).Hinzu kommt lediglich, dass es einen neuen Agenten-Typ, den ETHOC-Browser,gibt, der als Resultat seiner Anfrage XML erwartet.

ID-Aufloser

Diese Komponente ist ebenfalls identisch mit derjenigen aus der ersten Variante(siehe Abschnitt 5.4.1).


Der Online-Teil dieser Komponente ist identisch mit der ersten Variante (sieheAbschnitt 5.4.1). Im lokalen Teil wird die ubermittelten XML-Struktur in eineinterne Java-Struktur umgewandelt und daraus ein Layout erstellt, welches imKlienten angezeigt wird. Abhangig von der Personalisierung konnen Aktionenautomatisch gestartet werden. Es konnen nur Aktionen ablaufen, die in den Au-torenwerkzeugen angeboten wurden. Somit gibt es keine verborgenen Aktionen.

5.5. META-INFORMATIONEN 47

Personalisierung

In dieser Variante wird die Personalisierung umgesetzt. Sie ist Teil der lokalenSoftware und wird lokal gehalten. Mogliche Automatismen sind: Alle Dateieinrunterladen, Kalenderantrage automatisch offnen, bestimmte Dateitypen direktoffnen, Barcodes nach beenden der lokalen Applikation sofort loschen sowie dieAngabe eines Zielverzeichnises fur die Ablage aller automatisch runtergeladenenDokumenten.

5.4.3 Variantenvergleich

Beide Varianten bieten eine hohe Flexibilitat bei der Klientenauswahl. Fur je-den Klienten-Typ muss lediglich ein XSLT-Dokument als Konfiguration ange-fertigt werden. Fur jedes Gerat kann direkt bestimmt werden, welche Aktio-nen ausfuhrbar sind und welche nicht, indem es entweder die Darstellung lokalausfuhrt oder der Server es mit einer XSLT-Struktur verknupfen kann.

Beim Online-ID-Manager ist das Layout auf XML (also HTML und WML)festgelegt. Bei der lokalen Variante ist das Layout machtiger, dafur werden abermehr Ressourcen beim Klienten benotigt. Die Erstellung eines Benutzerprofilsbei der Datenbank des Online-ID-Managers kann sowohl als Vorteil (von jedemGerat aus dieselben IDs) oder als Nachteil (Privatsphare) ausgelegt werden. Aufjeden Fall ein Vorteil ist, dass die XML-Strukturen der IDs verwaltet werden.Dadurch kann bei einem allfalligen Update des virtuellen Gegenstuckes, dieexakte Veranderung angezeigt werden. Es mussen lediglich neue und alte XML-Struktur verglichen werden.

Ein grosser Nachteil der Online-Variante ist, dass keine Aktionen automatischablaufen konnen. Dafur muss ausser der Barcode-Leser-Software (Komponen-te ID-Einleser) nichts installiert werden. Ein Nachteil der Offline-Variante istdie benotigte Rechenleistung auf der Klienten-Seite. Die XML-Struktur mussbearbeitet werden, um dargestellt werden zu konnen.

In dieser Arbeit wird der ID-Koordinator mit lokaler und online Komponenterealisiert.

5.5 Meta-Informationen

Ein elektronisches Dokument besitzt immer zusatzliche Hintergrund-Informatio-nen (wie Titel und Autor), sogenannte Meta-Informationen, die uber spezielleBefehle sichtbar gemacht werden konnen. Ahnlich hierzu sollen die virtuellenGegenstucke zusatzliche Informationen verwalten. Aktionen sind Funktionen,die auf dem Rechner eines ETHOC-Benutzers ausgefuhrt werden. Das virtuelleGegenstuck verwaltet diese Aktionen.

Die Tabelle 5.4 listet alle im ETHOC-System verwendeten Metadaten auf. In-formationen konnen dokumentspezifisch oder generisch sein. Zudem konnen sieteilweise automatisch erhoben werden. Einige Angaben sind zwingend, z.B. derName des Autors. Die Angaben des Autors zu seiner Person konnen von Do-kument zu Dokument variieren. Aus diesem Grund kann er entscheiden, wel-che Angaben von ihm fur ein Dokument publiziert werden sollen und welche


Meta-Information dok.abh. automatisch zwingendName des Autors X XOrganisationseinheit des Autors XEmailadresse des Autors XHomepage des Autors XTelefonummer des Autors XFaxnummer des Autors XAdresse (Ort, Strasse, Nummer) XBuro des Autors XWas soll publiziert werden? X X XKontaktadressen XTitel des Dokumentes X XStichworte zum Dokument XDokument-Kurzbeschreibung XDokument gultig bis X XOnline Kopie des Dokumentes XHistorie des Dokumentes X XAktionen des Dokumentes X

Tabelle 5.4: Meta-Informationen eines Dokumentes

nicht. Dazu gibt es fur jede Meta-Information, die den Autor betrifft, ein Flag,das er setzten kann, damit die Angabe publiziert wird. Alle erhobenen Meta-Informationen werden in einer XML-Struktur verwaltet. (siehe Abschnitt 7.1).

5.5.1 Aktionen

Die in Abschnitt 2.1 beschriebenen Aktionen sind in der Tabelle 5.5 zu wenigenAktions-Typen zusammengefasst. Zum Beispiel sind Filmkritiken, Lebenslaufe,Portraits, Folien, Abstracts, Bilder und Musterlosung aus Abschnitt 2.1 normalezusatzliche Dateien, und Reservationssysteme, Anmeldeformulare, Testatuber-sicht, Feedbackformulare, Abstimmungen und Fragebogen aus Abschnitt 2.1sind normale Links zu Fremdseiten oder zu Modulen des Systems.

Aktionen sind auch automatisierbar. So konnen automatisch Online-Kopie her-untergeladen, zusatzliche Dateien abhangig vom Typ geoffnet oder herunterge-laden oder Termine direkt mit dem Kalender-Programm geoffnet werden.

5.5.2 Module

ETHOC-Module sollen dem Autor helfen, zusatzliche Funktionalitat in die vir-tuellen Gegenstucke seiner Dokumente zu bringen. Sie sind nichts anderes alsServlets im Internet, die aber zum ETHOC-System gehoren. So konnten z.B.Veranstaltungen um Anmeldeformulare oder Vorlesungsskripte um Feedback-Formulare erganzt werden. Auch Abstimmungen sind moglich, denn die Benut-zer sind aufgrund der globalen ID-Verwaltung eingeloggt und somit dem Systembekannt. Dadurch kann auch pro Benutzer-ID nur einmal abgestimmt werden.

5.6. ZUSAMMENFASSUNG 49

Typ AktionOnline-Kopie HerunterladenTermin Start (Datum und Zeit), Ende (Datum und Zeit),

Adresse (Ort, Strasse und Nummer) Titel und Be-schreibung in Kalender eintragen

Links Weiterleitung zur URLZusatzliche Datei Ab Zugangsdatum, fur Benutzer herunterladbar oder

offnenBenutzer-Kontakt Email, Telefon, AdresseHistorie Dokumente auflisten und Selektion zum Download

Tabelle 5.5: Aktionen eines Dokumentes

Dies wurde aber auch eine eingehende Uberprufung des Sicherheitskonzeptes imETHOC-System erfordern.

Durch die Modularitat kann das ETHOC-System flexibel erweitert werden, oh-ne das Grundgerust, wie die XML-Struktur des virtuellen Gegenstuckes, andernzu mussen. Die Modul-Anbindung ist so konzeptioniert, dass Entwickler vonModulen keinen bestehenden Kode des ETHOC-Systems anpassen mussen. Furden Benutzer sind Module normale Links ins Internet, welche ihm eine Funk-tionalitat zum Dokument bieten. Module sollen Funktionen anbieten, die nichteinfach anderswo im Internet mit besserem Leistungsumfang gefunden und kon-figuriert werden konnen. Diskussionsforen z.B. konnen bei einem anderen Anbie-ter ausgewahlt und als Link in einem Dokument integriert werden. Im Rahmendieser Arbeit sind exemplarisch das Feedback- und das Autorennotifikationsmo-dul programmiert worden, um zu zeigen, wie neue Module eingebunden werdenkonnen.

5.6 Zusammenfassung

Dieser Abschnitt fasst zusammen, welche Varianten umgesetzt werden und wiedie Probleme aus den Kapiteln zuvor gelost wurden.

1. Fur die Erstellung von virtuellen Gegenstucken wird die Variante Web-service realisiert. Ein Autor muss sich zuvor im Autoren-Portal auswei-sen. Dies geschieht mittels Autoren-ID und Passwort. Die Grundfunktio-nalitaten der virtuellen Gegenstucke werden durch Module erweitert. Indieser Arbeit wird exemplarisch das Feedbackmodul umgesetzt.

2. Als ID-Manager wird die Variante mit lokaler und Online-Komponenteimplementiert. Es konnen potentiell alle Kliententypen unterstutzt wer-den. Dabei sind die Fahigkeiten der Klientengerate in XSLT-Dateien aufdem Server festgehalten. Den Mobiltelefonen z.B. werden WML-Seiten an-geboten, hierfur wird die zugehorige XSLT-Datei aus der Datenbank aus-gelesen. Neue Barcode-Lesermodelle konnen ohne Anderung des ETHOC-Systems eingebunden werden – es muss lediglich eine auf den Barcode-Leser zugeschnittene ID-Leser-Komponente geschrieben werden.


3. Die ETHOC-IDs haben eine feste Stelligkeit (vier Stellen fur die Koordi-nator-ID und sechs Stellen fur die Rest-ID) und werden mittels Code 128kodiert. Fremde IDs konnen durch die abweichende ID-Lange erkannt wer-den. EAN-Barcodes fur Bucher oder UPC-Barcodes fur Produkte werdenvorerst nicht unterstutzt.

4. Es wird ein zentrales Benutzerprofil in der Datenbank gefuhrt. Ein gean-dertes virtuelles Gegenstuck wird im Benutzerprofil ebenfalls als geandertmarkiert. In der lokalen Applikation wird die XML-Struktur gespeichert,um bei einer Aktualisierung die Anderungen lokalisieren zu konnen. Eswurde geklart, welche Aktionen automatisch ablaufen konnen und dasskeine ungewollte, verborgenen Aktionen moglich sind.

5. Der vCalendar-Standard [20] erlaubt keine Verschiebungen von Terminen.D.h. hat ein Benutzer einen Termin in die Agenda eingetragen und wirddieser spater durch den Autor geandert, so muss der Benutzer daran den-ken, den alten Eintrag zu entfernen. Vergisst er dies, so ist der Eintragdoppelt vorhanden. Es liegt also auch am Autor, dafur zu sorgen, dass beieiner Terminanderung z.B. im Begleittext des Termins die Verschiebungdes Termins beschrieben ist, damit ein Benutzer mit zwei Kalenderein-tragen weiss, welches der korrekte ist. Dieses Vorgehen ist aquivalent zumheutigen vorgehen. Erfahrt jemand, dass sich ein Termin geandert hat, somuss er den alten Termin selbst austragen.

Zusatzlich werden im Design-Kapitel folgende Probleme gelost:

• Die genauen Fahigkeiten der Klienten-Typen ist Teil des XSLT-Designsresp. des Designs der beiden ID-Manager.

• Das Anzeigen der genauen Anderungen eines virtuellen Gegenstuckes istSache des lokalen ID-Managers und somit Teil seines Designs.

Kapitel 6

Design desETHOC-Systems

Dieses Kapitel beschreibt detailliert die im Kapitel 5 gewahlten Varianten undlegt die Grundlagen fur die Implementation des ETHOC-Systems.

6.1 XML-Strukturen und -Verarbeitung

Das ETHOC-System und die virtuellen Gegenstucke sind sehr flexibel aufgebautund konnen leicht erweitert werden. Diese Flexibilitat muss verwaltet werden.Hier bietet sich XML an, da strukturgestutzte Informationen und der Inhaltgemeinsam abgespeichert werden. ETHOC benutzt XML fur zwei Zwecke. ZurModellierung virtueller Gegenstucke und zur Konfiguration des Systems. UmETHOC einfach erweitern zu konnen, werden die Anzahl der Module und Werk-zeuge nicht fest im Programm kodiert, sondern uber Konfigurationsdateien inXML-Form dynamisch eingelesen. Soll zu einem spateren Zeitpunkt ETHOC umneue Werkzeuge oder Module erweitert werden, so muss kein Kode verandertwerden. Lediglich die Konfigurationsdateien mussen angepasst werden. Der Auf-bau der XML-Strukturen wird im Abschnitt 7.1 naher erlautert. Die Verarbei-tung der XML-Strukturen tritt also in folgenden Orten im ETHOC-System auf:

• Nach erfolgreicher ID-Auflosung wird eine XSL-Transformation durch-gefuhrt, um die Ausgabe fur den Klienten zu erzeugen.

• In den Prozessen der Objekt-Erstellung und -Anderung wird aus den Ein-gaben des Autors die XML-Struktur erzeugt oder erweitert. Zur Anzeigeder bereits getatigten Angaben wird die XML-Struktur in ein HTML-Formular transformiert.

• Beim Erstellen oder beim Andern eines virtuellen Dokumentes wird dieaktuelle Konfiguration der Module ausgelesen.

• Nach erfolgreichem Login werden die aktuell angebotenen Werkzeuge aus-gelesen, um dem Autor das Weiterarbeiten zu ermoglichen.

51

52 KAPITEL 6. DESIGN DES ETHOC-SYSTEMS

Abbildung 6.1: Besipiel eines ETHOC-Barcodes

• Der lokale ID-Manager (die lokale Applikation wird gegenuber dem Benut-zer als ETHOC-Browser bezeichnet) pruft nach, welche ETHOC-Typenzugelassen sind. In dieser Arbeit gibt es den Typ “doc” und “err”. DieXML-Objektstruktur der virtuellen Gegenstucke wird verwendet, um eineJava-Objektstruktur zu erstellen.

Die XML-Strukturen werden also gelesen, erzeugt oder transformiert. Hierfurwerden Java-Bibliotheken verwendet. Zur Transformation wird XALAN [25] ver-wendet. Zum Parsen eines XML-Dokuments stehen zwei APIs zur VerfugungDOM und SAX, welche durch Parser wie XERCES [26] zur Verfugung gestelltwerden. Bei DOM wird das XML-Dokument in eine Baumstruktur ubersetzt.Dieser Baum kann traversiert und die Informationen extrahiert und manipu-liert werden. DOM empfiehlt sich nur, wenn ein Dokument manipuliert odermehrmals geparst werden muss. Zudem wird viel Speicher verbraucht, da dasganze Dokument als Baum verwaltet wird. Beim Parsen des Dokumentes miteinem SAX-Paser werden Events wie “start-Element” oder “endElement” aus-gelost, auf welche reagiert werden kann. Fur das einmalige Auslesen einer XML-Struktur empfiehlt sich somit der SAX-Parser. Zum Erzeugen und Manipuliereneiner XML-Struktur lassen sich nur die DOM-Schnittstellen verwenden. Da esaber relativ aufwendig ist, einen generischen DOM-Baum zu manipulieren undmit anderen Baumen zu vergleichen, wird in ETHOC ein anderer Weg beschrit-ten. Zu jedem Element in der XML-Struktur des virtuellen Gegenstuckes gibtes eine Java-Klasse. Diese Klasse enthalt, die in der Struktur definierten Instan-zen und Elemente und bietet Methoden, wie z.B. die Serialisierung der internenStruktur zu einem XML-String. Weitere Infomationen zu DOM und SAX sind[16] und [17] zu entnehmen.

6.2 Barcode

Die ID eines Dokumentes ist zehnstellig und wird als Barcode mittels Code128 kodiert. Es wird ein Bild der Grosse 29x110 Pixel erstellt (siehe Abbildung6.1). Unterhalb des Barcodes befindet sich, in fur den Menschen lesbaren Form,die Aufschrift ETHOC gefolgt von der ID in Dezimalschreibweise. Diese Auf-schrift ermoglicht dem Benutzer, den Barcode zuzuordnen und die ID von Handeinzugeben.

6.3 ETHOC-Portal

Da auf Seiten des Autors und auf Seiten des Benutzers eine Losung mit Online-Komponente zum tragen kommt, bietet es sich an, fur das ganze ETHOC-

6.4. AUTOREN-PORTAL 53

Abbildung 6.2: Einstieg ins Autorenportal

System eine Einstiegsseite in HTML zu entwickeln. Diese kann spater im Pro-totypen z.B. unter www.ethoc.ethz.ch veroffentlicht werden. Die Grundfunktio-nalitat, die das Portal anbietet, ist die Verzweigung zum Autoren-Portal undzur Benutzer-Online-Komponente, in welcher die ETHOC-ID im Browser vonHand eingegeben werden kann. Eine Seite, auf welcher das ETHOC-Projekt demBenutzer vorgestellt wird, ist ebenfalls in Planung.

6.4 Autoren-Portal

Das Autoren-Portal bietet einem Autor nach erfolgreicher Anmeldung verschie-dene Werkzeuge an. Innerhalb eines Werkzeuges wird der Autor in seinen In-teraktionsmoglichkeiten gefuhrt. Ein Werkzeug besteht also aus einer Reihe vonHTML-Seiten, welche dynamisch aus Java-Servlets erstellt werden.

Die Java-Klassen des Autoren-Portals gehoren ins Paket “Ethoc.Authoring”.Klassen, die sowohl beim Autor als auch beim Benutzer gebraucht werden, fin-den ihren Platz unter “Ethoc.System”. Die Klassen, die nur beim Benutzerbenotigt werden, sind unter “Ethoc.Browser” untergebracht. Die Klassen desBenutzer-Portals sind im Paket “Ethoc.Resolving” zu finden. Wird das Autoren-Portal zu einem spateren Zeitpunkt um weitere Werkzeuge erweitert, so muss le-diglich die XML-Datei “authoringtools.xml” angepasst werden. Die zusatzlichenServlets mussen selbstverstandlich noch hochgeladen werden. Dem Entwicklerneuer Werkzeuge steht frei, neue Java-Pakete zu verwenden.

6.4.1 Einstiegsseite

Das Autorenportal beginnt mit einer HTML-Seite, in welcher der Benutzer fol-gende Moglichkeiten hat (siehe Abbildung 6.2):

1. Einloggen mittels Autoren-ID und Passwort (Authentisierung).

2. Link zur Erstellung einer neuen Autoren-ID (Registrierung).

3. Link zu Passworterzeugung, falls Passwort vergessen worden ist.


Abbildung 6.3: Ablauf der Objekt-Erstellung und -Anderung

Der erste Fall ist die haufigste Benutzungsform. Nach der Eingabe von ID undPasswort erhalt der Autor, sofern seine Angaben korrekt waren, die Ubersichtuber alle Autoren-Werkzeuge. Von diesem Zeitpunkt an hat der Autor einepersonliche Session, die ihn uber alle Seiten hinweg begleitet. In dieser Sessionist seine Autoren-ID vermerkt. An die Session konnen spater weitere Parameter,wie die ID des gerade bearbeiteten virtuellen Gegenstuckes, angefugt werden.Fehlt die Session, handelt es sich entweder um einen Manipulationsversuch, eineabgelaufene Session oder um einen Browser, der keine Cookies unterstutzt. Dieswird dem Benutzer mittels einer Exception in HTML-Form angezeigt.

Im zweiten Fall wird ein Formular angezeigt, in welchem sich der Autor registrie-ren kann und seine ID bestimmt. Das Passwort wird automatisch erzeugt undihm an die angegebene Email-Adresse gesendet. Dadurch wird sichergestellt,dass der Autor Zugang zum Email-Konto hat, welches er bei der Anmeldung alssein eigenes ausgibt. Es kann aber nicht verhindert werden, dass die weiterenAngaben falsch sind. Sein Passwort resp. sein ganzes Profil kann er, sobald ereingeloggt ist, andern.

Falls der Autor sein Passwort vergessen hat, kann er im dritten Fall ein neuesPasswort beantragen, welches automatisch erstellt und an seine Email-Adressegeschickt wird. Hierfur muss er entweder seinen Login oder die Email-Adresse,mit der er sich registriert hat, wissen. Es kann nicht sein altes Passwort zuge-schickt werden, da es in der Datenbank mit einer Einwegfunktion verschlusseltabgelegt worden ist.

6.4.2 Objekt-Erstellung und -Anderung

Objekt-Erstellung und -Anderung haben beide eine sehr ahnliche Benutzerfuh-rung (siehe Abbildung 6.3). Hat sich der Autor nach dem Login entschieden,ein neues Dokument mit Online-Ressourcen zu verknupfen, so reserviert daserste Servlet eine eindeutige ID und verbindet sie mit der Session. Es generiertein minimales XML-Dokument, das die Angaben zum Autor berucksichtigt undspeichert es in der Datenbank mit dem Vermerk “invalid” ab. Dies bedeutet,dass die XML-Struktur durch den Autor nicht vollstandig durchgearbeitet istund es somit noch kein virtuelles Dokument zur ID gibt. Hat sich der Autornach dem Login entschieden, ein bestehendes virtuelles Dokument zu andern,wird dessen Dokumenten-ID mit der Session verknupft und das erste Servlet,welches das virtuelle Dokument bearbeitet, aufgerufen.

Um die Eingabeseite nicht zu uberladen, werden die Benutzereingaben zum vir-tuellen Dokument uber mehrere Formulare, erzeugt durch Servlets, verteilt. Da


die XML-Struktur aus vier Hauptkomponenten besteht – Angaben zum Autor,zum Dokument, zu den Kontaktpersonen und Aktionen – bietet sich eine Auf-teilung der Eingabeformulare nach dieser Hauptstruktur an. (In Abbildung 6.3als Formular Teil 1 bis n dargestellt).

Ein an der Generierung des virtuellen Gegenstuckes beteiligtes Servlet zeigteinen Teil der Angaben in der XML-Struktur als Formular an. Die XML-Struk-tur wird aus der Datenbank gelesen und zusammen mit einem XSL-Dokumentzu einer HTML-Seite transformiert. Uber Schaltflachen kann der Benutzer neueFelder anfordern (z.B. einen weiteren Kontakt hinzufugen), Felder loschen oderzum nachsten Servlet navigieren. In allen Fallen werden die getatigten Angabenin der Datenbank abgespeichert.

Die Gultigkeitsdauer der Verknupfung zwischen Dokument und virtuellem Ge-genstuck muss ebenfalls erfragt werden. Wird dieser Zeitpunkt uberschritten, sowird die Dokumenten-ID als geloscht markiert. Bei einer spateren Referenzie-rung wird dem Benutzer die erfolgte Loschung mitgeteilt. Somit lasst sich einegeloschte ID von einer ungultigen Referenz unterscheiden. Die Konfiguration derAutoren-Notifikation kann in diesem Servlet vollzogen werden. Der Autor kannbestimmen, wie viele Tage er vor Ablauf seines Dokumentes informiert werdensoll. Diese Funktionalitat ist in den Formularen 1 bis n integriert worden.

Die ETHOC-Module, die Bestandteil des virtuellen Dokumentes sind, werdenzwar in den Aktionen ausgewahlt, die Konfiguration geschieht aber unabhangigvon der Generierung der XML-Struktur. D.h. in der XML-Struktur wird ver-merkt, dass Module hinzugefugt worden sind, der Inhalt der Module wird in denentsprechenden Modulen selbst erzeugt und verwaltet. Ob hierfur die Datenbankerweitert wird, oder die Informationen anderweitig verwaltet werden, ist Sachedes Modul-Entwicklers. Dieses Vorgehen erlaubt neue Module einzubinden, ohneden Erstellungsprozess nach jedem neuen Modul anpassen zu mussen.

Die Module mussen durch den Autor konfiguriert werden. Dazu werden Links zuden Konfigurations-Seiten angeboten. Benutzt der Autor diese Links nicht, sosieht ein spaterer Benutzer entweder das Modul in seinem minimalen Zustand(z.B. das Feedback-Modul hat nur Felder fur Name, Kommentar und Email-Adresse aber keine weiterfuhrenden Fragen) oder eine Mitteilung, dass diesesModul durch den Autor nicht konfiguriert worden ist. Wenn immer moglich,sollte ein Modul-Entwickler die erste Losung ins Auge fassen. Welche Moduleexistieren, wird in der Modul-Konfigurationsdatei festgehalten. Die Selektion derModule und die Links zu deren Konfigurationsseiten sind im Formular integriertworden, das fur die Aktionen zustandig ist.

Das letzte Servlet im Prozess uberpruft, ob das XML-Dokument alle notigenAngaben enthalt. Ist dies nicht der Fall wird erklart, welche Angaben nochgetatigt werden mussen. Erfullt das Dokument die DTD, so zeigt das Servletden Barcode an und ubergibt ihn als Bild dem Autor zwecks Einbindung insDokument. Zugleich vermerkt es in der Datenbank, dass die ID ab sofort gultigist.

Der Autor kann die Navigation durch die Komponenten selbst bestimmen. Erkann auch zuruck navigieren, um Eingaben zu andern. Die Servlets sind sogeordnet, dass bereits nach Bearbeitung des ersten Formulars eine syntaktischkorrekte XML-Struktur gebildet werden kann.


Abbildung 6.4: Methoden des abstrakten ETHOC-Servlets

Abbildung 6.5: Methoden des abstrakten ETHOC-XML-Servlets

6.4.3 Abstrakte Servlets

Alle ETHOC-Servlets haben gemeinsame Funktionalitaten. Zum Beispiel mussjedes Servlet prufen, ob der Autor korrekt authentifiziert worden ist. Dadurchwird verhindert, dass ein Autor sich mittels Manipulation Zugriff zu einem frem-den virtuellen Gegenstuck verschafft.

Abstraktes ETHOC-Servlet

Das abstrakte ETHOC-Servlet im Paket “Ethoc.Authoring” (siehe Abbildung6.4) weist konkrete Methoden auf, um die HTTP-Anfrage zu analysieren undzwecks Bearbeitung der Anfrage, entsprechende Funktionen innerhalb des Serv-lets aufzurufen. Dies geschieht in der Methode “doPost” resp. “doGet”. (“do-Post” wird bei einem HTTP-POST-Request und “doGet” bei einem HTTP-GET-Request aufgerufen. Beim ersteren werden allfallige Parameter innerhalbdes HTTP-Headers, beim letzteren mit der URL ubergeben.)

In diesen Methoden muss in allen Servlets gepruft werden, ob die Session nochgultig ist (Methode “getSession”) und abhangig von den Parametern Operatio-nen ausgefuhrt werden (Methode “doOP”). “GetSession” ist bereits im ETHOC-Servlet ausprogrammiert. “DoOP bleibt” abstrakt. Die Methode “go” leitet zueiner URL weiter.


Abbildung 6.6: Methoden des abstrakten ETHOC-Service-Servlets

Abstraktes ETHOC-XML-Servlet

Alle Servlets, welche ihre Ausgaben aufgrund einer XML-Transformation er-zeugen, erhalten diese Funktionalitat in der abstrakten Klasse EthocXMLServ-let (siehe Abbildung 6.5). Diese Funktionalitat ist in der Methode “makeOut-put” festgehalten, welche die Transformation aufgrund der beiden Parameterdurchfuhrt.

Abstraktes ETHOC-Service-Servlet

In den beiden Diensten/Werkzeugen “Registrierung eines neuen Dokumentes”und “Anderungen eines bestehenden Dokumentes” kommen ebenfalls eine Rei-he von Servlets zum Zuge. Dies Servlets haben eine starke Gemeinsamkeit: Siegreifen aufs virtuelle Dokument und die Datenhaltung zu. Aus diesem Grundwerden alle vom Servlet “EthocServiceServlet” abgeleitet, welches die gemein-same Funktionalitat zur Verfugung stellt (siehe Abbildung 6.6).

Alle Service-Servlets bieten drei Operationen an: Die XML-Struktur erweitern(Methode “more”), reduzieren (Methode “delete”) oder zum nachsten Servletgehen, um einen anderen Bereich der XML-Struktur zu bearbeiten (Methode“next”, mit Parameter die Identifikation des Ziel-Servlet). In diesen Operationenwerden alle getatigten Anderungen abgespeichert. Aus diesem Grund wird dieMethode “doOP” bereits im abstrakten Servlet implementiert.

Ebenfalls implementiert sind die beiden Methoden zum Lesen von XML(“readXML”) und XSL (“readXSL”). Erstere liest die XML-Struktur des vir-tuellen Gegenstuckes aus der Datenerhaltung und letztere liest die zum Servletpassende XSL-Datei ein.

6.4.4 Servlet-Hierarchien

Dieser Abschnitt befasst sich mit der Frage, wie die in den vorhergehendenAbschnitten betrachteten Servlets eingebunden und organisiert werden. Es ist


Abbildung 6.7: Servlet-Hierarchie im Autorenbereich

festgestellt worden, dass die Servlets 1 bis n zur Generierung der virtuellen Ge-genstucke identische Funktonalitat, wie die Servlets 1 bis n zum Update einesvirtuellen Gegenstuckes bieten. D.h. es konnen die gleichen Servlet-Klassen ver-wendet werden. Die Servlets mussen nur wissen, welche Dokumenten-ID geradebearbeitet wird, und dies ist in der Session festgehalten. Dadurch ergibt sich diein Abbildung 6.7 festgehaltene Servlet-Hierarchie.

Alle Servlets, welche die Session verfolgen mussen, sind eine Ableitung von“EthocServlet”. Alle Servlets, die ihre Ausgabe mittels XML und einer XSL-Transformation erstellen, sind Subklassen von “EthocXMLServlet”. Wie bereitsbehandelt, sind alle Servlets, die als XML-Dokument die Struktur des virtuellenGegenstuckes lesen, von “EthocServiceServlet” abgeleitet. Damit jenes Servlet,welches sich um die Anzeige der Auswahl der Module kummert, nicht speziellbehandelt werden muss, wird das Servlet, das den Update-Service initiiert, er-weitert. Nachdem es die XML-Struktur eines zu aktualisierenden virtuellen Ge-genstuckes aus der Datenbank gelesen hat, vergleicht es die Modul-Eintrage mitder Konfigurationsdatei. Gibt es neue Module, die nicht in der XML-Strukturdes virtuellen Gegenstuckes festgehalten sind, werden die neuen Module in dieXML-Struktur des virtuellen Gegenstuckes eingefugt.

6.5 Datenbank

Viele Freeware-Datenbanken bieten nur eine eingeschrankte Funktionalitat. ZumBeispiel fehlen haufig Trigger und/oder Stored Procedures. Aus diesem Grundwird im Design eine Losung entwickelt, welche diese Tatsache berucksichtigt,um bei der Wahl der Datenbank nicht eingeschrankt zu sein.

6.5. DATENBANK 59

Abbildung 6.8: Zugriff auf Informationen in der Datenbank

6.5.1 Zugriff auf die Datenbank

Die Servlets mussen unabhangig von ihrer Position in der Hierarchie auf die Da-tenbank zugreifen konnen. Hinzu kommen Module, die ebenfalls auf ihre eigenenund auf die Daten der virtuellen Gegenstucke zugreifen wollen. Dabei muss dieURI der Datenbank bekannt sein, sowie die technische Benutzer-ID1 und dasdazugehorende Passwort. Auch auf Benutzerseite muss auf die Datenbank zuge-griffen werden. Die Funktionalitat des Datenbankzugriffes gilt es abzukapseln,damit nicht in jedem Programm das Passwort zum Datenbankzugriff bekanntsein muss und damit nicht standig der gleiche Kode geschrieben werden muss.

Die Abkapselung geschieht uber mehrere Stufen (siehe Abbildung 6.8). Auf dieDatenbank direkt greift nur der “DBManager” – der Datenbank-Manager – zu.Er verwaltet eine Verbindung zur Datenbank und bietet eine einfache Schnitt-stelle, um auf der Datenbank zu arbeiten. Dies geschieht uber die Abfragespra-che der Datenbank, z.B. SQL. Der DB-Manager ist als Singleton implementiert.Dadurch wird sichergestellt, dass in jeder ETHOC-Installation diese Klasse ein-malig existiert. Somit kann z.B. spater zwecks Leistungssteigerung ein Cache-Management im DB-Manager eingefuhrt werden. Der Einsatz eines Cache durftehier zu einem Performanzgewinn fuhren, da anzunehmen ist, dass ein Autor, dergerade eine XML-Struktur bearbeitet, diese regelmassig benotigt. Dadurch er-spart sich das System zeitintensive Datenbankanfragen. Auf die Aspekte derVerteiltheit wird in Abschnitt 7.8 genauer eingegangen.

Auf den DB-Manager greifen ausschliesslich Daten-Manager (“DataManager”)zu. Von diesen kann es mehrer Implementierungen geben. So konnen Modu-le auf ihre Daten uber ihre eigenen Daten-Manager zugreifen. Wollen sie aufDaten, die das virtuelle Gegenstuck betreffen zugreifen, so bedienen sie sichdes Daten-Managers im Authoring-Paket. Die Aufgabe eines Daten-Managersist es die Abfragesprache der Datenbank abzukapseln. Uber logische Methodenwie “getDoc(id)”, “getDocContent(id)” oder “getAuthor(authorID)” operiertdas ETHOC-System mit dem Daten-Manager und erhalt die Daten in einemDatenbank-unabhangigen Format, wie “Ethoc.System.Doc”, “java.lang.String”

1Eine technische Benutzer-ID wird nicht von Personen, sondern von Programmen resp.Prozessen benutzt. Auf die ETHOC-Datenbank greifen die Servlets mit einer speziellen –eben der technischen – Benutzer-ID und nicht mit der jeweiligen ID der Autoren zu.


Abbildung 6.9: Benutzungsmoglichkeiten des ETHOC-Systems

oder “Ethoc.System.Author”. Der Daten-Manager organisiert also die Daten inder gewunschten Form (Java-Objekte, XML etc.). Dadurch kann spater die Da-tenbank ausgetauscht werden, ohne dass das ETHOC-System von der Anderungbetroffen ist.

Ein kleines Beispiel um die Aufteilung naher zu erlautern: Die “getDoc(id)”-Methode im “DataManager” generiert eine SQL-Query mit welcher die Metho-de “executeQuery(query)” im DB-Manager aufgerufen wird. Der DB-Managerliefert ein “ResultSet” aus dem Paket “java.sql”, welches das gewunschte Resul-tat beinhaltet. Der “DatenManager” extrahiert die Daten aus dem “ResultSet”und benutzt diese, um ein “Ethoc.System.Doc”-Objekt zu generieren, welcheser als Resultat zuruckgibt.

Der Ethoc-Browser greift uber das Servlet “DBServlet” auf den DataManagerzu. Ware der DB-Manager Teil des Ethoc-Browsers, so konnte ein versierter Be-nutzer leicht eigene Java-Programme schreiben, die direkt auf den DB-Managerzugreifen und uber diesen beliebige SQL-Befehle ausfuhren. Ebenfalls konntedurch eine Dekompilierung das Passwort des technischen Benutzers herausge-funden werden und somit direkt auf der Datenbank gearbeitet werden.

6.6 Benutzerseite

Fur den Benutzer gibt es vier Wege, um an ein virtuelles Dokument zu gelan-gen (siehe Abbildung 6.9). Der erste Weg (in der Abbildung unten links) ist viaBarcode-Leser und dem lokal installierten ETHOC-Browser. Die Wege zwei unddrei (in der Abbildung oben rechts) fuhren uber einen Browser ohne vorhande-

6.6. BENUTZERSEITE 61

Abbildung 6.10: Umgang mit der zentralen Historie

nen Barcode-Leser. Die ID wird dabei von Hand eingegeben. Der vierte Weg (inder Abbildung oben rechts) fuhrt uber einen AirClic-Leser am Mobiltelefon.

6.6.1 Lokale Komponenten

Der ETHOC-Browser besteht aus den in Abbildung 6.9 dargestellten lokalenKomponente, die in diesem Abschnitt naher erlautert werden.

ID-Reader

Fur jeden Barcode-Leser-Typ muss ein Treiber (In Abbildung 6.9 als “IDRea-derX” bezeichnet) geschrieben werden. Dieser erweitert die Schnittstelle “IDRea-der”, kommuniziert mit dem Barcode-Leser und ubergibt dem lokalen ID-Ma-nager die IDs.

ID-Manager

Der ID-Manager synchronisiert sich, sofern eine Internet-Verbindung vorhandenist, mit der Online-Historie (siehe Abbildung 6.10). Dabei wird festgestellt, wel-che IDs von den Autoren aktualisiert worden sind. Die neuen IDs werden in dieVerwaltung aufgenommen und aufgelost. Die IDs der Verwaltung konnen von al-len lokalen Komponenten und dem Benutzer ausgetauscht und geloscht werden.Bei Veranderung der lokalen Historie wird die Online-Historie nachfuhrt.


Model-Objekte

Ein Model-Objekt ist die Reprasentation der XML-Struktur eines virtuellenDokumentes in Form eines Java-Objekts. Ein Model kennt seine ID und seineXML-Struktur und hat eine Referenz zu einer View-Klasse, die es darstellt.

Ein Model-Objekt hat Zugriff auf die lokale Historie. Dadurch sind Objektedenkbar, die mit der Historie arbeiten. Zum Beispiel konnte so ein Drucker-Model automatisch das zuvor eingelesene Dokument ausdrucken. Das Model-Objekt wird wie zuvor beschrieben, in die Verwaltung aufgenommen und zeigtim oberen Teil des ETHOC-Browser-Fensters unter Zuhilfename seiner View-Klasse eine Vorschau seines Inhaltes. Wird das Objekt selektiert, so ruft eseine weitere Methode seiner View-Klasse auf und veranlasst seine vollstandigeAusgabe im unteren Teil des ETHOC-Browser-Fensters.

HistoryView

Die “HistoryView” stellt die Verwaltung grafisch dar. Jede ID beansprucht eineZeile. Es konnen IDs entfernt und alle IDs nach neuen Inhalten pruft werden.Entfernt der Benutzer eine ID, so wird sie auch in der Online-Historie geloscht.Ist gerade keine Online-Verbindung vorhanden, so werden die zu loschenden IDsbis zur nachsten Verbindung speziell verwaltet.

Transformator

Jede neue ID wird mit Hilfe der Klasse “Transform” aufgelost. Wird eine IDbereits verwaltet, so wird das Model-Objekt mit der selben ID befragt, ob essinnvoll ist, mehrfach verwaltet zu werden. Ist dies der Fall, so wird das Objektdupliziert; andernfalls, wie z.B. bei Dokumenten, wird das Datum des letztenEinlesens aktualisiert.

Die Klasse Transform organisiert die XML-Reprasentation der ETHOC-ID. Ausder XML-Antwort generiert sie ein passendes Model-Objekt. Ist das Typ-Attri-but des ETHOC-Elementes – das erste Tag aller virtuellen Dokumente – gleichder Zeichenkette “doc” so handelt es sich um ein Dokument, und es kann einDokumenten-Model generiert werden. Fehlermeldungen vom Server erhalten alsTyp-Attribut den Wert “err”. Die Klasse “Transform” wird also benotigt, umaus IDs Model-Objekte zu generieren. Welcher XML-Typ welche Model-Klasseentspricht, wird anhand von Namenskonvention gelost.

6.6.2 Online-Komponenten

“ShowID” wird bei allen vier Zugriffsmoglichkeiten immer kontaktiert (sieheAbbildung 6.9). Beim ersten Weg geschieht dies uber die Transform-Klasse. ImWeg zwei und drei wird die Adresse der Redirector-Klassen uber einen Browserangewahlt. Diese fragen beim Benutzer nach der ETHOC-ID. Gibt der Benut-zer gleich seinen Benutzernamen und das Passwort an (evtl. sind diese Angabenbereits in Cookies oder in anderer Form gespeichert, dann entfallt die wiederhol-te Eingabe), hat er auch Zugriff auf seine Historie. Mit der ID kontaktieren sie

6.6. BENUTZERSEITE 63

“ShowID”. Im Hintergrund sorgen die Redirector-Klassen dafur, dass die soebenaufgeloste ID auch in die Historie eingetragen wird (siehe Abbildung 6.10).

In der HTTP-Anfrage ist immer der “user agent” angegeben, d.h. es kann aufden Browser-Typ geschlossen werden, sofern dieser bekannt ist. Da die Benut-zer aber entweder uber die Redirectoren-Klassen oder den Transformator zu“ShowID” gelangen, ist bereits bekannt, ob die Klienten-Applikation HTML,WML oder XML versteht. Fur jeden ETHOC-Typ wird deshalb fur HTML,WML und XML eine eine XSLT-Datei in der Datenbank hinterlegt. Die Ant-wort des Servlets “ShowID” ist eine Transformation der XML-Struktur des zurID gehorenden virtuellen Gegenstuckes mit einem XSLT-Dokument, welcheszum virtuellen Gegenstuck und zur Klienten-Applikation passt. Im Fall einesWML-Browsers ist es WML, im Fall des HTML-Browsers ist es HTML und imFall der Transformer-Klasse ist es ein XML-Dokument.

Auch der vierte Weg (das Benutzen eines AirClicLesers) fuhrt uber “ShowID”.Der Benutzer wird zum “Redirector” umgeleitet. Dieser extrahiert die Barcode-ID und die AirClic-Benutzerkennung und leitet die Anfrage mit der ID als Pa-rameter an “ShowID”. weiter. Auf die besprochen Art und Weise wird eineWML-Datei generiert, welche ans Mobiltelefon retourniert wird. Auch der Re-director von AirClic sorgt im Hintergrund dafur, dass die ID in die Historiehinzugefugt wird. Anhand der Serienummer des AirClic-Barcode-Lesers kannbei der Datenhaltung der Benutzername und das Passwort erfragt werden. Mitdiesen Angaben wird die ID hinzugefugt. Die Sicherheitsprobleme, die dieseLosung mit sich bringt, wird im Abschnitt 7.9 behandelt.

Um die Historie zu besichtigen, bietet jedes virtuelle Dokument, das zu WMLoder HTML transformiert worden ist, einen Link zum Servlet “HistoryShow”.Gegebenenfalls muss der Benutzer sich wieder einloggen. Jeder Eintrag wirdals Link angezeigt, der zur Ansicht des virtuellen Gegenstuckes fuhrt. Bei derDarstellung als WML muss darauf geachtet werden, dass die maximale Grosseeines Decks beschrankt ist. Diese Beschrankung variert von Geratehersteller zuGeratehersteller. Laut [30] betragt diese Grosse bei einem Nokia 7110 1397 Byteund bei einem Ericsson R320 3000 Byte. Aus diesem Grund wird empfohlen, dasLimit von 1.3 Kilobyte nicht zu uberschreiten. Es empfiehlt sich aber auch vonder ergonomischen Seite aus, nicht mehr als zehn IDs auf einmal anzuzeigen.Ahnlich wie bei Suchmaschinen, werden Links zu den nachsten und vorherigenzehn IDs fuhren.

Die Aufgabe des DB-Managers wurde in Abschnitt 6.8 behandelt.

Kapitel 7

Implementierung

In diesem Kapitel wird die Implementierung naher erlautert. Insbesondere wer-den spezielle Konzepte, Schnittstellen und Strukturen hervorgehoben, die imDesign nur kurz behandelt oder offen gelassen worden sind. Des weiteren wer-den Schwierigkeiten erlautert, die mit den verwendeten Bibliotheken aufgetretensind.

7.1 XML-Strukturen

Dieser Abschnitt erklart den Aufbau der XML-Strukturen in ETHOC. Die Do-cument Type Definition der Strukturen ist im Anhang D vollstandig spezifiziert.

7.1.1 Virtuelle Gegenstucke

Die Struktur der virtuellen Gegenstucke beginnt mit dem Element (XML-Tag)“ethoc”. Es besitzt ein Attribut “type”, welches bei Dokumenten den Wert“doc” haben muss. Wird das ETHOC-System spater um andere Typen erwei-tert, so wird eine neue Struktur benotigt, welche mit dem Element “ethoc” be-ginnt und im Attribut “type” den neuen Typ aufweist. Innerhalb des Elements“ethoc” befindet sich das Element “virt doc” mit den Attributen “id” – die IDdes Dokumentes und “last change” – das Datum der letzten Anderung. Inner-halb des Elemtens virt doc finden die Elemente “author”, “doc info”, “contacts”und “extend” ihren Platz. “Extend” sind die Aktionen des virtuellen Dokumen-tes.

Einige Elemente verfugen uber das Attribut “last change”. Dadurch kann schnellherausgefunden werden, wann welche Komponenten geandert worden sind. Esist somit moglich, einen Benutzer genau zu informieren, was sich seit seinemletzten Kontakt verandert hat, sofern eine altere XML-Struktur zum Vergleichvorhanden ist. Uberall, wo kein Attribut “last change” vorhanden ist, wird aufdie Lokalisierung des Updates verzichtet. Sie ist aber dennoch moglich, da zweiXML-Strukturen verglichen werden konnen. Bei den Modulen ist via Attribut“last config” vermerkt, welche Version die Konfigurationsdatei hatte, als dasvirtuelle Gegenstuck erstellt wurde. Ist die Versionsnummer der Module des

65

66 KAPITEL 7. IMPLEMENTIERUNG

virtuellen Dokumentes von der Nummer der aktuellen Konfigurationsdatei ver-schieden, so gibt es neue Module. Die neuen Module werden eingefugt und derAutor wird beim Bearbeiten seines Dokumentes die neuen Module zur Auswahlvorfinden.

Diese XML-Struktur wird verwendet, um zusammen mit einem XSLT-Doku-ment die HTML-Formulare zu generieren, in welchen ein Autor seine Datenandern kann. Mit weiteren XSLT-Dateien werden eine Ubersicht fur den Autor,eine HTML-Ansicht fur die Internet-Benutzer, eine WML-Ansicht fur Mobilte-lefonbenutzer und eine XML-Struktur fur den ETHOC-Browser erstellt.

7.1.2 Modulkonfiguration

In der XML-basierten Modulkonfiguration werden alle Module mit dem Zeit-punkt ihres individuellen Einbindens in ETHOC (Version der Konfigurationsda-tei zu diesem Zeitpunkt) und weiteren Angaben festgehalten. Das Wurzelementheisst “modules”. Sein Attribut “last config” ist die aktuelle Versionsnummerder Konfigurationsdatei. Innerhalb des Wurzelelementes befinden sich einzelneElemente namens “module”. Als Attribute erhalten sie den Einfugezeitpunktund die Email-Adresse der Person, die das betreffende Modul eingefuhrt hat. Zu-dem ist angegeben, ob das Modul standardmassig aktiviert oder deaktiviert seinsoll. Jedes Modul hat einen Eintrag “name”, “label” und “entry point config”.Der Name identifiziert das Modul innerhalb von ETHOC und muss eineindeu-tig sein, das Label dient zur Benennung des Modules gegenuber dem Benutzerund “entry point config” ist eine URL – vorzugsweise die Adresse eines Serv-lets – welche als Einstiegspunkt zur Konfiguration des Moduls durch den Autordient. Die Elemente “entry point use” und “notifier” sind optional. Erstes istdie Internet-Adresse (auch hier ublicherweise die URL eines Serlvets), an welcheder Benutzer umgeleitet wird, wenn er das Modul auswahlt. Letztere ist eineJava-Klasse, welche durch das ETHOC-System aufgerufen wird, wenn virtuelleGegenstucke erzeugt oder geandert werden. Dadurch bekommt ein Modul al-le Anderungen mit. Die unter “notifier” aufgefuhrte Klasse implementiert dasInterface “Ethoc.System.ModuleNotifier”.

7.1.3 Autoren-Werkzeuge

Die Anzahl Autoren-Werkzeuge ist ebenfalls flexibel. Um spateren Entwicklerneine leichte Verwaltung der Werkzeuge zu ermoglichen, werden alle vorhandenenAutoren-Werkzeuge in einer XML-Datei aufgelistet. Diese Datei wird auch ver-wendet, um dem Autor ein Auswahl-Menu der Werkzeuge anzuzeigen. Innerhalbdes Wurzel-Elements “authoring” befinden sich Elemente namens “tool”, die einWerkzeug umfassen. Darin wird die Text-Anzeige an den Autor spezifiziert unddas erste Servlet, welches den Eingabeprozess beginnt, angegeben.

7.2. AUTORENPORTAL 67

7.2 Autorenportal

7.2.1 Einstiegsseite

Das Autorenportal wird vom Autor mittels eines HTML-Browsers bedient. Nichtalle Browser sind gleich machtig. Versierte Internetbenutzer schalten oft Funk-tionen des Browsers ab, weil sie mit diesen Fuktionen schlechte Erfahrungengemacht haben oder die Befurchtung haben, ihre Privatsphare konnte durchdas Eingeschaltetlassen ausspioniert werden.

ETHOC benutzt Sessions, um sich zu merken, welcher Autor gerade welchesDokument bearbeitet. Der von der Java-Servlet-API zur Verfugung gestellteMechanismus benutzt dazu Cookies. Die Navigation und die Fehleruberprufungnutzen JavaScript. um ETHOC benutzen zu konnen, mussen demzufolge Coo-kies und JavaScript eingeschaltet sein. Die Aufgabe der Einstiegsseite ist, dieszu uberprufen. Unterstutzt der Browser die beiden Funktionalitaten, so wird erzu einem Login-Fenster umgeleitet. Ist dies nicht der Fall, so wird ein Hinweis,dass die entsprechende Funktionalitat im Browser aktiviert werden sollte, umETHOC benutzen zu konnen, angezeigt. Um unerfahrenen Benutzer allfalligeVorbehalte betreffend JavaScript oder Cookies zu nehmen, werden Links mitweiteren Informationen zu JavaScript und Cookies aufgefuhrt.

Es wird in diesem Projekt davon ausgegangen, dass ein Autor nicht mitten inder Bedienung die Konfiguration des Browsers andert. Tut er dies, indem er z.B.JavaScript ausschaltet, so funktioniert die Navigation nicht mehr und er kannnicht mehr weiternavigieren, sprich keine Daten speichern. Schaltet er Cookiesab, so finden die Servlets die Session nicht mehr und reagieren mit einer Excepti-on. Ebenfalls wird davon ausgegangen, dass der Benutzer nicht boswillig ist undversucht mit selbst generierten Formularen unerlaubte Eingaben zu erreichen.Diese Annahme ist deshalb gerechtfertigt, weil ein Autor dadurch dennoch nurseine eigenen Dokumente verandern konnte.

7.2.2 Autoren-Identifikation

Die Autoren-Identifikation ist wie im Design (siehe Abschnitt 6.4.1) beschrieben,realisiert worden. Beim Service fur “vergessliche” Benutzer wurde nebst derPasswortgenerierung, die Moglichkeit geschaffen, auch die Autoren-ID anhandder Email-Adresse(n) zu erfragen.

7.2.3 Virtuelle Gegenstucke erstellen und andern

Ein Autor muss maximal vier Formularseiten bearbeiten, in denen Angabenzum Dokument (wie Titel und Gultigkeit), zum Autor, zu den Kontaktperso-nen und zu den Aktionen gemacht werden. Nicht im Design vorgesehen aberimplementiert worden, ist eine Abschlussseite, die das ganze Dokument anzeigtund den Autor ausloggen oder andere Werkzeuge wahlen lasst. Ein neues Doku-ment ist bereits nach dem ersten Servlet gultig, d.h. es kann sofort der Barcodebezogen und dann ausgeloggt werden. Die Autorennotifikation ist als Modul,das standardmassig aktiviert ist und ohne Konfiguration den Autor sieben Tage


und ein zweites Mal einen Tag vor Ablauf der Gultigkeitsperiode benachrich-tigt, realisiert worden. Das Feedback-Formular ist standardmassig deaktiviert.Ohne Konfiguration wird ein minimales Formular generiert, das einen Standard-Begrussungstext und Felder fur Name, Vorname, Email-Adresse und Kommen-tar des Benutzers enthalt.

7.2.4 Datei-Upload

Eine zu Beginn nicht erwartete Schwierigkeit stellte sich mit dem Datei-Upload.Um Dateien via HTTP zum Server hochzuladen, erhalt das “form”-Elementin einer HTML-Seite das Attribut “enctype” mit dem Wert “multipart/form-data”. Dadurch aber werden alle Parameter vollstandig neu kodiert ubergebenund die Get-Methoden in “ServletRequest”, mit welchen normalerweise aufServlet-Seite die Parameter extrahiert werden, finden keine Parameter mehr.Es muss entweder der Request selbst geparst werden, indem der Standard ana-lysiert und befolgt wird, oder ein Java-Paket verwenden werden, dass diese Auf-gabe ubernimmt. In dieser Arbeit wurde letzteres gewahlt und die BibliothekCOS [21] verwendet. Es wurde ein Wrapper geschrieben, der einige Funktioneneines “ServletRequest” anbietet, aber im Hintergrund COS benutzt. Aufgrundeines Fehlverhaltens von COS musste die Klasse dennoch leicht umgeschriebenwerden (siehe Anhang C.8). Das Verwenden dieses Paketes hat auch zur Folge,dass der Header maximal 1GB gross sein darf. Im Header befinden sich die Na-men der Parameter und deren Werte, sowie Metadaten zu den hochgeladenenDateien inklusive des ganzen Dateiinhalts.

7.2.5 Barcode-Erzeugung

Barcodes werden im JPG- und GIF-Format erzeugt. Um JPGs zu erzeugen,wird das Paket “com.sun.image.codec.jpeg” [22] verwendet, welches schon stan-dardmassig in JDK 1.2 vorhanden ist. Um GIFs zu erzeugen, wurde Acme LabsGIFEncoder [23] verwendet.

7.3 Module

Die Module werden beim Start des ETHOC-Systems dynamisch eingebunden(siehe Abschnitt 7.1.2). Sie besitzen zwei Einstiegspunkte. Einen zur Konfigura-tion des Moduls durch den Autor und einen zur Bedienung durch den Benutzer.Die Autoren-Notifikation hat keinen Einstiegspunkt fur den Benutzer. D.h. esist ein Modul, das der Benutzer nicht wahrnimmt. Das Feedback-Formular hathingegen einen Einstiegspunkt fur den Benutzer, um diesen zu weiteren Servlets,die eine kliententypische Ausgabe, wie HTML und WML erzeugen, umzuleiten.

Beide Module benutzen resp. erweitern Klassen, welche die ETHOC-Infrastruk-tur zur Verfugung stellt. Die Einstiegspunkte fur den Autor sind Erweiterungender Klasse “Ethoc.Authoring.EthocServlet”. Der Einstiegpunkt fur Benutzerbedient sich der Klasse “Ethoc.System.AgentChecker”, um den Klienten wei-terzuleiten. Diese Klasse bestimmt anhand des User-Agents, ob der BrowserWML oder HTML versteht.

7.4. EMAIL-VERKEHR 69

Abbildung 7.1: Klassen und Navigation im Benutzerportal

Uber Anderungen an virtuellen Gegenstucken wird ein Modul durch seinenModul-Notifier, welcher das Interface “Ethoc.System.ModuleNotifier” imple-mentiert, informiert. Das ETHOC-System verwaltet die Notifier aller Module.Tritt eine Aktion ein, die ein bestimmtes Dokument oder ein Modul betrifft,ruft es Methoden, die im Interface “Ethoc.System.ModuleNotifier” definiertsind, auf. Auf diese Weise kann jedes Modul individuell reagieren und eigeneAktionen veranlassen. Zum Beispiel passt das Autoren-Notifikations-Modul dieNotifikationsdaten an, wenn die Gultigkeit eines Dokumentes verandert wird.

7.4 Email-Verkehr

Das ETHOC-System sendet Emails an die Autoren und an die Benutzer, z.B. umdie Passworte zu ubermitteln oder als Funktionalitat in den Modulen. Hierfurwird die Klasse “sun.net.smtp.SmtpClient”, mit “[email protected]” als Absender-adresse verwendet. Diese Klasse genugt den momentanen Anforderungen vonETHOC, ist aber keine Standardbibliothek. Es wird von Sun nicht garantiert,dass es die Bibliothek auch in spateren Versionen in dieser Form gibt. Sollenspater auch Attachements versendet werden, so muss ein machtigeres Paketwie z.B. Suns JavaMail [24] verwendet werden. Dies kann einfach durchgefuhrtwerden, da die Funktionalitat des Email-Versendens durch eine ETHOC-eigeneKlasse abgekapselt wird.


7.5 Benutzerportal

In diesem Anschnitt wird das Benutzerportal – die Online-Komponenten der Be-nutzerseite, detailierter als im Design-Abschnitt 6.6.2 beschrieben. In Abbildung7.1 sind die an einer Abfrage beteiligten Java-Klassen abgebildet. Der Benutzerhat von der Einstiegsseite aus die Wahl, entweder seine Online-Historie zu be-trachten resp. zu bearbeiten oder eine neue ETHOC-ID anzuschauen. Es gibtfur HTML und WML separate Einstiegsseiten. Das System erfahrt somit, obder Browser WML oder HTML versteht. Die weitere Navigation erfolgt durchKlassen, welche die gewunschte Ausgaben erzeugen. Meist sind die Klassen soorganisiert, dass abstrakte Klassen die Funktionalitat sicherstellen und die kon-kreten Klassen die Ausgabe darstellen.

Entscheidet sich ein Benutzer fur eine neue ID, so wird er vom ID-Eingabe-Servlet aufgefordert, die ID von Hand einzugeben. Die eingegebene ID wird imnachsten Servlet auf ihre Gultigkeit gepruft. Ist die ID korrekt, so wird der Be-nutzer aufgefordert sich einzuloggen, sofern er die ID in seine Historie einfugenwill. “AddID” pruft aufgrund der Ableitung von “CheckUser” ob der Benutzerkorrekt eingeloggt ist und uberlasst das Einfugen der ID in die Benutzerhi-storie der Klasse “HistoryAdder”. Ist dies geschehen, wird der Benutzer zumServlet “ShowID” weitergeleitet, welches die ETHOC-ID anzeigt. Hierfur wirdeine XSL-Transfomation durchgefuhrt. Bei WML und HTML hat es einen Linkzur personlichen Historie des Benutzers. Entscheidet sich ein Benutzer, seineHistorie zu betrachten, so wird er uber den Login zur Historie weitergeleitet.Sind ID und Passwort nicht gespeichert (in HTML werden Cookies benutzt undin WML Variablen), muss er sich erneut einloggen. Auf Seiten der Benutzerwird ein anderer Weg beschritten als auf Seiten der Autoren. Das Benutzer-Portal kann auch ohne Cookies und Java-Script benutzt werden. Aus diesemGrund kann keine Session verwendet werden. Die Benutzerkennung ohne Coo-kies ist lediglich bis zum nachsten Servlet nach dem Login verfugbar. Wirddie Benutzer-Authentifikation in einem Modul benotigt (z.B. in einem spaterenAbstimmungsmodul) so muss der Benutzer uber den Login gefuhrt werden. ImFeedback-Modul wurde darauf verzichtet, weil auch Benutzer ohne Historie dasModul benutzen konnen sollen.

Ein weiterer Einstiegspunkt im Benutzer-Portal sind auf Barcode-Leser ausge-richtete Servlets. Der “AirClicResolver” nimmt die Anfrage so entgegen, wievon der Firma AirClic spezifiziert und wandelt sie in eine gerateunabhangigeAnfrage um, welche zum Servlet “BCReaderEntryWML” weitergereicht wird.Jenes Servlet organisert anhand Barcode-Leser-Typ und Identifizierung (im Fal-le von AirClic die Serienummer des Lesers) ID und Passwort des Benutzers undspeichert die Daten als WML-Variablen. Dadurch muss der Benutzer sich nichtausweisen. Um andere Leser ans ETHOC-Benutzer-Portal anzuschliessen musstepro Gerat eine Klasse der Art “AirClicResolver” geschrieben werden. Das Er-mitteln der Benutzerdaten anhand der Seriennummer eines Barcode-Lesers birgtpotentielle Sicherheitsrisiken (siehe Abschnitt 7.9). Wunschenswert ware, wennder Barcode-Leser weitere Angaben zur Authentifizierung ubermitteln konnte.Dies ist aber bei AirClic nicht der Fall. Fur machtigere Barcode-Leser wird emp-fohlen, einen anderen Einstiegspunkt zu programmieren oder den Weg uber denlokalen ETHOC-Browser zu verwenden.

Der ETHOC-Browser kontaktiert das “DBServlet” um sich mit der Historie zu

7.6. ETHOC-BROWSER 71

Abbildung 7.2: Hauptklassen des ETHOC-Browsers

synchronisieren. Benotigt er die XML-Struktur einer ID, so wendet er sich direktan “ShowIDXML”.

7.6 ETHOC-Browser

Der ETHOC-Browser wird unter Windows mit einer Batch-Datei gestartet.Es wird die Main-Methode der Klasse “Browser” aufgerufen. Diese erstellt ei-ne neue Instanz “Browser”. Als erstes wird ein Fenster angezeigt in welchemsich der Benutzer einzuloggen hat. Ist dies geschehen, werden die Daten on-line verifiziert. Existiert keine Verbindung ins Internet, werden die Daten imlokalen Profil des Benutzers verifiziert, sofern eines existiert. Das lokale Profilder Benutzer befindet sich im Ordner “User” und besteht aus einem seriali-sierten “UserData”-Objekt. Als Dateinamen wird die Benutzer-ID mit der En-dung “.dat” verwendet. War der Login erfolgreich, wird die Datei in ein Objektzurucktransformiert und mit dem Browser referenziert. In einem “UserData”-Objekt sind die Praferenzen eines Benutzer und seine Historie abgespeichert.Die Historie besteht aus einem “HistoryTableModel”, welches in einem Daten-Vektor Objekte vom Typ “Model” verwaltet. Diese konnen Aufgrund ihrer Viewim ETHOC-Browser dargestellt werden. Ein genau Erklarung der Model-View-Idee ist in Abschnitt 6.6.1 vorzufinden. Model-Objekte erhalten eine Referenzzum “UserData”-Objekt (siehe Abbildung 7.2), um die Benutzerdaten bei Be-darf andern zu konnen.

Der Dateien-Cache ist fur alle Benutzer gemeinsam organisiert. D.h. ladt einBenutzer Dateien einer ETHOC-ID in den Cache herunter, so stehen sie denanderen Benutzern ebenfalls zur Verfugung und mussen nicht erneut herunterge-laden werden. Pro ETHOC-ID wird innerhalb des Ordners “Cache” ein Ordner


erstellt, der die Nummer der ETHOC-ID tragt. Innerhalb dieses Ordners hat esdie Unterordner “Docs” und “Files”, in welche die Dokument-Kopien und diezusatzlichen Dateien gespeichert werden. Die Dateinamen bestehen aus einemZeitstempel dem “@”-Zeichen und dem Dateinamen, den der Autor gewahlthat. Dadurch kann der Browser herausfinden, ob es auf dem Server mittler-weile aktuellere Versionen von Dateien gibt. Die Dateien sind im Cache miteinem Schreibschutz abgelegt. Sie konnen nur lesend geoffnet werden. Der Be-nutzer kann wahlen, ob er Dateien anschauen oder speichern will. Soll eine Dateigeoffnet werden, wird sie direkt aus dem Cache geoffnet. Will der Benutzer dieDatei speichern, wird die Datei von Cache kopiert, wobei als Dateiname dervom Autor gewunschte Name als Vorschlag erscheint. In beiden Fallen wird ei-ne Datei zuerst in den Cache heruntergeladen, falls sie dort nicht vorhandenist.

Im ETHOC-Browser wird der Web-Browser benotigt, um Dateien oder Linkszu offnen. Doch das Aufrufen des Browsers ist betriebssystemabhangig. Es wur-de eine Klasse verwendet, die je nach zugrundeliegendem Betriebssystem undStandard-Browser den passenden Startbefehl ausfuhrt. Dieses Vorgehen hat aberden Nachteil, dass wenn das System nicht erkannt werden kann oder der Brow-ser nicht existiert, das Offnen von Dateien und Links nicht funktioniert. Ausdiesem Grund werden im ETHOC-Browser auch die URLs angezeigt und dieDateien konnen gespeichert werden, um spater von Hand geoffnet zu werden.

7.7 Datenbank

Es wird die Open-Source-Datenbank MySQL [27] benutzt. In der aktuellen Ver-sion (3.32.46a) werden leider keine Triggers und Stored Procedures unterstutzt.Sie sind erst fur Version 4.1 angekundigt. Auf MySQL wird uber JDBC zuge-griffen. Hierfur wird der MM.MySQL-Treiber [29] in der Version 2.0.8 benutzt.Dieser Abschnitt erklart, wie die Informationen in der Datenbank abgespeichertwerden. Es wird ebenfalls darauf eingegangen, was die Einschrankungen derDatenbank sind.

Die vergebenen Koordinator-IDs (der Aufbau der ETHOC-ID wird im Abschnitt5.2.4 erklart) werden in der Tabelle “IdCoord” festgehalten (siehe Tabelle 7.1).Im Feld “host” steht die IP-Adresse des ETHOC-Servers und in “id” die anihn vergebenen Koordinatoren-IDs. Jeweils die grosste ID eines ETHOC-Hostsist seine aktuelle Koordinatoren-ID. In “last id” steht die zuletzt vergebene IDinnerhalb des Kontextes der Koordinator-ID. Ein ID-Koordinator hat in der mo-mentanen Version keine eigene persistente Speicherung der vergebenen IDs, des-halb muss er bei jeder ID-Vergabe die letzte ID in der Datenbank nachfuhren. Esist auch Sache des ID-Koordinators zu uberprufen, ob sein ID-Vorrat erschopftist. Die Datenbank ist nicht auf eine fixe ID-Stelligkeit beschrankt. Wird spaterdie ID-Lange vergrossert tangiert es die Datenbank nicht, resp. nur dann, wenndie ID das Speichervermogen einer INT uberschreitet (siehe MySQL-Manual[28]).

Die Angaben, die ein Autor bei der Registrierung angeben hat, sind in derTabelle “Author” festgehalten. Bei der ID und dem Passwort des Autors ist dieGross-/Kleinschreibweise wichtig. Der DB-Manager verschlusselt das Passwort

7.7. DATENBANK 73

Field Type Null Key Defaulthost varchar(16) PRIid int(11) PRI 0last id int(11) YES NULL

Tabelle 7.1: Definition der MySQL-Tabelle “IdCoord”

mit der MySQL-eigenen Einwegfunktion “PASSWORD”. D.h. der Test, ob eineingegebenes Passwort korrekt ist, geschieht in der Datenbank.

Die virtuellen Gegenstucke werden in der Tabelle namens “Doc” gespeichert.Haufig benotigte Daten der XML-Struktur, wie z.B. Titel und Autor, sindzusatzlich redundant in der Tabelle gespeichert. Die Redundanz wurde aus Per-formanzgrunden eingefuhrt, um ein haufiges Parsen der XML-Strukturen zuumgehen. Die Maximalgrosse der XML-Struktur betragt 16 Megabyte. Dies istgemass MySQL-Manual [28] die Grosse eines BLOB- resp. TEXT-Feldes.

Die Dokumenten-Historie wird in der Tabelle “DocHistory” verwaltet. Die Do-kumenten-ID und das Einfugedatum dienen als Schlussel. Das Einfugedatum istals INT gespeichert und bestimmt die Anzahl Sekunden, die seit dem Jahr 2000vergangen sind. Der Inhalt einer Datei wird als LONGBLOB ebenfalls in derDatenbank gespeichert und darf gemass MySQL-Manual [28] 4 Gigabytes nichtuberschreiten. Allerdings kann diese Kapazitat bei weitem nicht ausgenutzt wer-den, denn das MySQL-interne Protokoll erlaubt eine maximale Paketgrosse von16 MByte. Standardmassig lauft MySQL sogar mit einer Paketgrosse von nur 1MByte. Damit grossere Pakete verwendet werden, musste der Parameter fur diePaketgrosse geandert werden (siehe Abschnitt C.6). Somit konnen Dateien uber16 MByte nicht gespeichert werden. Mit MySQL 4.0 wird diese Schranke abge-baut und die maximale Paketgrosse auf 4 GByte erhoht (siehe MySQL-Manual[28]). (Zur Erinnerung: Eine weitere Schranke befindet sich auf Servlet-Seite imCOS-Paket, welches einen HTTP-Header von maximal 1GB erlaubt.)

MySQL speichert jede einzelne ihrer Tabellen als Datei ab. Die Tabelle “Doc-History” kann aber eine gewaltige Grosse annehmen, wenn man bedenkt, dasshier alle Dokumente abgespeichert werden. Die Maximalgrosse einer MyISAM-Tabelle, welche standardmassig in MySQL zur Anwendung kommen, betragtacht Millionen Terabytes (=263 Bytes). Eine weitere Hurde, die normalerweisefruher greift, ist die des Betriebssystems. In der Windows-Welt gilt fur FAT-Dateien eine Obergrenze von 2 GB, fur FAT32-Dateien eine Obergrenze von 4GBund fur NTFS-Dateien eine Obergrenze, die identisch mit der Festplattengrosseist. In der Entwicklungsumgebung wurde Windows 2000 eingesetzt, welches alsDateisystem NTFS hatte. Wird in der produktiven Umgebung ein anderes Be-triebssystem eingesetzt, muss auf dieses Limit geachtet werden. MySQL mussdann gegebenenfalls anders konfiguriert werden (siehe MySQL-Manual [28]).Ahnlich zur Dokumenten-Historie werden die zusatzlich hochgeladenen Dateienverwaltet. Als Schlussel dienen die Dokumenten-ID und der Dateiname.

Um die Anbindung der Module zu demonstrieren, sind zwei Module entwickeltworden: Die Autoren-Notifikation und das Feedback-Formular. Beide besitzeneigene Tabellen in der Datenbank. Die Autoren-Notifikation speichert pro ID dieAnzahl Tage, die ein Autor vor Ablauf des Dokumentes benachrichtigt werden


will. Dazu ist redundant das Datum eingetragen, zu dem der Autor benachrich-tigt wird, um dem Prozess, welcher nach Notifikationszeitpunkte sucht, Rechen-arbeit zu ersparen. Andert ein Autor das Gultigkeitsdatum seines Dokumentes,so bleiben die Anzahl Tage fix und die Notifikationszeitpunkte werden neu be-rechnet. Bei der Notifikation wird immer das alteste Datum aus der Datenbankentfernt. Wird ein neues virtuelles Gegenstuck erstellt, so werden automatischdie Werte ein Tag und sieben Tage eingetragen. Dadurch erhalt der Autor siebenund einen Tag vor Ablauf seines Dokumentes eine Mitteilung, wann sein Doku-ment geloscht wird. Anders verhalt sich das Feedback-Formular. Das Erstellenneuer virtueller Gegenstucke wird vom Modul nicht behandelt. Wird aber einFeedback-Formular fur ein Dokument angefordert, das keine Eintrage in denFeedback-Tabellen hat, so wird das Standardformular dynamisch erstellt.

Die Benutzerdaten werden in der Tabelle “user” gespeichert. Es werden dieBenutzer-ID, das Passwort als Hashwert und die Email-Adresse abgelegt. Wiebei den Autoren ist die Gross-/Kleinschreibweise von ID und Passwort wichtig.Das Passwort wird mit der MySQL-eigenen Einwegfunktion “PASSWORD” ge-hasht und ist nicht rekonstruierbar. Besitzt ein Benutzer einen Barcode-Leser,der ihn identifiziert, wie z.B. bei AirClic uber die Seriennummer, so hat jederBarcode-Leser eine eigene Tabelle, mit deren Hilfe auf den Benutzer geschlos-sen werden kann. Im Falle von AirClic muss aus der Seriennummer auf dieBenutzer-ID und das Passwort geschlossen werden. Aus diesem Grund speichertdie Tabelle “AirClic” diese drei Werte. Das Passwort muss nochmals abgespei-chert werden, weil es aus der “user”-Tabelle nicht rekonstruiert werden kann. Esdarf nicht gehasht werden, sondern muss in Java ver- und entschlusselt werdenkonnen. Die Benutzer-Historie wird in der Tabelle “History” gespeichert.

Die Tabelle “xsl” bestimmt fur welchen ETHOC-Typ und welche Markup-Sprache welche XSLT-Datei(en) benutzt werden soll(en). In der Datenbank istnicht der Dateiinhalt, sondern die URI der Datei ohne “.xsl”-Endung gespei-chert. Der vollstandige Dateinamen wird im Servlet (siehe Abschnitt 7.5 und8.3.2), welches auf die Tabelle zugreift, zusammengestellt.

7.8 Aspekte der Verteiltheit

ETHOC wurde von Beginn an mit Blick auf eine spatere Verteiltheit konzi-piert und umgesetzt. Alle Daten inkl. Dateien betreffend virtuelle Gegenstuckewerden in der Datenbank gespeichert. Somit sind die Daten losgelost von derAnzahl der Installationen und dem Ort der ETHOC-Server. Die URI der Da-tenbank wird einem ETHOC-Server uber eine Konfigurationsdatei bekanntge-macht. D.h. die ETHOC-Java-Pakete konnen auf mehrere Rechner installiertwerden und alle wurden auf die gleiche Datenbank zugreifen. Kritische Ope-rationen, wie das Vergeben der Koordinatoren-IDs, operieren mit Datenbank-Locks auf den entsprechende Tabellen. Ebenfalls in einer Konfigurationsdateibefindet sich der Namen des SMTP-Servers. Bei einer spateren Verteiltheit derETHOC-Server muss bedacht werden, dass diverse Dispatcher fur die Zugriffeder ETHOC-Browser benotigt werden. Der ETHOC-Browser adressiert gewisseServlets, die er benotigt, direkt. Welche Servlets betroffen sind, ist im Javadocder Klasse “Ethoc.System.Constants” beschrieben.

7.9. SICHERHEITSASPEKTE 75

Die Datenbank selbst konnte spater ebenfalls verteilt organisiert werden. DieseAnderung betrifft aber die Applikations-Seite nicht (oder nur den Datanbank-Manager). Auf die Datenbank greift die Applikation immer uber eine Klasse,den Datenbank-Manager, zu (Erklarung siehe Abschnitt 6.5.1). Dieser ist ausPerformanzgrunden als Singleton implementiert. Der Aufbau einer Verbindungzur Datenbank ist sehr zeitintensiv. Wird immer der gleiche Datenbank-Managerbenutzt, was bei einem Singleton der Fall ist, entfallt diese Wartezeit. Da derDatenbank-Manager nur vom Server aus benutzt wird, spielt die Bandbreite derInternetanbindung der Klienten keine Rolle. Die Tatsache, dass der Datenbank-Manager als Singleton implementiert worden ist, impliziert keine Einschrankungauf eine spatere Verteiltheit, denn er ist pro ETHOC-Server einmalig.

7.9 Sicherheitsaspekte

Ziel dieser Arbeit ist, einen Prototyp zu erstellen, der die gewunschte Funktiona-litat sicherstellt und die Benutzbarkeit des Systems demonstriert. Sicherheits-aspekte spielen eine sekundare Rolle. Dennoch wurde darauf geachtet, grosseSicherheitslucken zu vermeiden.

7.9.1 Ausgezeichnete Benutzerrechte

Alle Daten befinden sich in der Datenbank. Der Zugriff auf die Datenbank istauf drei Benutzer reduziert worden. Dies sind “root”, welcher alle Rechte hat,“ethocTRX”, welcher schreibend auf die ETHOC-Datenbank zugreifen darf und“ethocSEL”, welcher nur ETHOC-Daten lesen darf. Alle anderen in MySQLstandardmassig definierten Benutzer sind entfernt worden.

Der Benutzer “root” wird vom Datanbankadministator benutzt und wird imNormalbetrieb nicht benotig. Der technischen Benutzer “ethocTRX” wird vomDatanbank-Manager benotigt (siehe Abschnitt 6.5.1). “EthocSEL” wird im Mo-ment nicht benutzt.

7.9.2 Datenubertragung

Im Prototypen werden alle Daten unverschlusselt ubers Internet zum Web-Server und zur Datenbank ubertragen. Im Benutzer-Portal werden im Falle einesHTML-Browsers Benutzer-ID und Passwort in Cookies, im Falle eines WML-Browsers als WML-Variablen gespeichert. Letztere haben aber einen globalenSichtbarkeitsbereich, d.h. sie sind uber Domain-Grenzen hinweg auslesbar.

Die Navigation innerhalb der Benutzer-Historie geschieht in WML mittels GET-Anfragen, indem auf einen Link geklickt wird. Dabei wird Benutzer-ID undPasswort im Klartext innerhalb der URL ubergeben. Der Grund liegt darin,dass diese Art der Navigation benutzerfreundlicher ist, als die Angaben ubereine POST-Anfrage zu senden. Bei POST-Anfragen geschieht die Navigationuber das Menu oder der Options-Taste und dem Suchen nach dem gewunschtenBefehl.

Der ETHOC-Browser ubertragt ebenfalls Benutzer-ID und Passwort zum Ser-ver. Dies bei allen Operationen, welche die Synchronisation der Online-Historie


und der lokalen Historie betreffen. Momentan werden fur die Kommunikati-on zwischen ETHOC-Browser und ETHOC-Server GET-Requests verwendetund die Parameter in der URL kodiert. Ursprunglich wurden POST-Requestsverwendet. Doch bei vielen schnellen Request hintereinander tauchte ein Fehl-verhalten auf. Nach etwa vier Anfragen blockierte der Server und nahm kei-ne Anfragen mehr an. POST-Requests funktionierten nur dann einwandfrei,wenn kleine Pausen dazwischen geschaltet wurden. Gemass den Bug-Reportsvon SUN bei ahnlichen Beobachtungen konnte das Fehlverhalten auf die Web-Server zuruckgefuhrt werden. Es konnte sich hier also um einen Bug in Jakartahandeln. Nach der Umstellung auf GET-Requests funktionierte alles einwand-frei. Dadurch entstand aber das erwahnte Sicherheitsproblem.

7.9.3 Passworter

Die Passworter der Autoren und der Benutzer des ETHOC-Systems werden alsHashwert (siehe Abschnitt 7.7) in der Datenbank abgelegt, so dass es nicht ein-mal dem Datenbank-Administrator moglich ist, Passworter zu rekonstruieren.Die Passworter dienen zur Identifikation und nicht als Zugriffmechanismus aufdie Datenbank. ETHOC-Programme greifen mit einer technischen Benutzer-IDauf die Datenbank zu (siehe Ausfuhrungen in Abschnitt 6.5.1), deren Passwortnur dem Datenbank-Manager bekannt ist. Der Grund, weshalb die Passwor-te nicht in der Klasse “Constants” sind, liegt darin, dass sie dort nicht privatsondern protected waren. Da das System-Paket auch Bestandteil des ETHOC-Browsers ist, der lokal installiert ist, konnte ein versierter Benutzer das Passwortherausfinden, um auf die Datenbank schreibend zuzugreifen, und so beliebigeDaten verandern.

Wird ein AircClic-Leser verwendet, so wird das Benutzer-Passwort nochmals ab-gespeichert. Diesmal geschieht die Verschlusselung in Java. Das Passwort mussin Java auch entschlusselt werden konnen. Nur dadurch kann der Benutzer auto-matisch eingeloggt werden. Im Prototyp ist das Passwort im Klartext abgelegt.Wunschenswert ware, wenn die Benutzerdaten auf eine andere Weise organi-siert werden konnten, zum Beispiel, indem sie vom Leser verschlusselt mitge-liefert wurden. Doch AirClic ubertragt lediglich die Seriennummer des Geratesund den eingelesenen Barcode. Dies geschieht sogar mittels einer GET-Anfrage,d.h. die Parameter werden in der URL ubertragen. Somit ist es ein leichtesSpiel, die Seriennummer abzuhoren oder zu erraten und sich unerlabterweise als“boswilliger” Benutzer mit dieser Seriennummer manuell anzumelden.Sobald ETHOC uber einen Prototypen hinausgeht, muss sich uberlegt werden,ob Anbindungen, von Barcode-Lesern wie AirClic, die zu wenig Informatio-nen ubertragen, auf diese Art unterstutzt werden soll. Im Moment wurden sichzwei Losungsansatze anbieten. Man verzichtet auf die implizite Authentifizie-rung durch Serienummern, oder man versucht auf personliche Daten auf demMobiltelefon, wie SIM-Card oder bestimmte Eintrage im Telefonbuch (die z.B.die Zugangsdaten erhalten) zuzugreifen und dadurch die Authentifizierung zuermoglichen. Beides scheint zum heutigen Zeitpunkt aufgrund fehlender Schnitt-stellen nur eingeschrankt realisierbar.

Im lokalen ETHOC-Browser wird das Objekt “UserData”, welches die Prafe-renzen des Benutzers und seine Daten enthalt, serialisiert, sobald der Browser

7.9. SICHERHEITSASPEKTE 77

geschlossen wird. Beim nachsten Start wird das serialisierte Objekt wieder in denBrowser eingebunden. Somit wird der Browser beim Neustart so eingerichtet,wie er zuvor verlassen wurde (siehe Abschnitt 7.6). Eine Variable in “UserData”ist das Passwort des Benutzers. Diese wird verwendet, um den Benutzer zu ve-rifizieren, falls eine Online-Verbindung fehlt und um ihn automatisch gegenuberdem ETHOC-Server auszuweisen, wenn die Online-Historie verandert wird. DasPasswort wird also mitserialisiert. Hat jemand Zugriff auf die Datei, kann er dasPasswort mit geeigneten Werkzeugen extrahieren. Dieses Sicherheitsloch kannspater wie folgt behoben werden: Vor dem Serialisieren wird ein Hashwert desPasswortes gespeichert und das richtige Passwort geloscht. Bei erfolgreichemLogin kann dann das Passwort wieder eingetragen werden.

Kapitel 8

Erweiterung desETHOC-Systems

Das ETHOC-System kann auf mehrere Arten erweitert werden. Zum Beispielkonnte mehr Funktionalitat fur virtuelle Dokumente implementiert werden. Ab-schnitt 8.1 erklart, wie neue Module, die diese Funktionalitat bieten, in ETHOCintegriert werden konnen. Ein anderer Ansatz ist, das Prinzip auf Gegenstandeauszuweiten, also ETHOC konzeptionell zu erweitern. Abschnitt 8.2 diskutiert,inwieweit die vorhandene Implementierung dies ermoglicht. Abschnitt 8.3 er-klart, wie allfallige neue Typen von virtuellen Gegenstucken in ETHOC in-tegriert werden konnen. Im Abschnitt 8.4 wird gezeigt, wie neue Typen vonBarcode-Leser eingebunden werden konnen.

8.1 Neue Module einbinden

ETHOC-Dokumente mit neuen Funktionen fur Autor und Benutzer erweitern,geschieht am einfachsten uber die Implementierung neuer Module. Hierfur mussder ETHOC-Kode nicht angepasst werden. Ein Modul-Entwickler muss eineInternet-Seite programmieren, die der Autor eines virtuellen Gegenstuckes be-nutzt, um das Modul fur sein Dokument zu konfigurieren. Diese muss nicht ge-zwungenermassen uber Java-Servlets geschehen, erleichtert aber die Arbeit, dadie Servlets von “Ethoc.Authoring.EthocServlet” abgeleitet werden konnen. Dieganze Infrastruktur zum Speichern der modulbezogenen Daten muss ebenfallsentwickelt werden. Dabei gilt es zu beachten, dass ein Autor nicht gezwungenwerden kann, ein Modul zu konfigurieren. Er kann es einfach nur aktivieren undnichts eingeben. Der Entwickler eines Moduls muss sicherstellen, dass sein Modulfur diesen Fall ebenfalls eine sinnvolle Handlung durchfuhrt resp. den Benutzerneine sinnvolle Ausgabe anzeigt, sofern das Modul auch einen Einstiegspunkt furBenutzer besitzt.

Beim Einstiegspunkt fur die Benutzer muss daran gedacht werden, dass nicht nurHTML-Browser, sondern auch WML-Browser Kundenapplikationen sind undnach Moglichkeit beide unterstutzt werden sollen. Um den Benutzer zu einem

79

80 KAPITEL 8. ERWEITERUNG DES ETHOC-SYSTEMS

HTML- resp. WML-Servlet umzuleiten, kann die Klasse “Ethoc.System.Agent-Checker” verwendet werden. Diese Analysiert den User-Agent und gibt zuruck,ob der Browser HTML oder WML versteht.

Soll ein Modul informiert werden, wenn es ein- oder ausgeschaltet wird, oderwenn sich ein virtuelles Gegenstuck andert, so muss eine Klasse geschrieben wer-den, die das Interface “Ethoc.System.ModulNotifier” implementiert. Alternativkann die Klasse “Ethoc.System.ModulNotifierImpl” erweitert werden und dortnur die Methoden uberschrieben werden, die auch benotigt werden. Ein Modul-Notifier wird beim Start des Systems instanziert und vom System verwaltet.Ein allfalliges Starten von benotigten Hintergrundsprozessen soll deshalb imKonstruktor des Notifiers erfolgen.

Das neue Modul und sein Notifier werden dem System durch einen Eintrag inder Datei “modules.xml” bekantgemacht (siehe Abschnitt 7.1.2). Es darf nichtvergessen werden, die Versionsnummer des Wurzel-Elementes hochzuzahlen,sonst werden die neuen Module beim Andern von bestehenden virtuellen Ge-genstucken nicht eingebunden. Es wird namlich aus Performance-Grunden nurdas Attribut “last config” verglichen (siehe Abschnitt 6.4.4).

8.2 Erweiterung auf Gegenstande

Die virtuellen Gegenstucke der ETHOC-Dokumente haben den Typ “doc”, undin diesem Bericht ist des offteren von virtuellen Dokumenten die Rede. Dochdie in dieser Arbeit erstellten virtuellen Gegenstucke lassen sich auch fur anderephysische Objekte verwenden. Dabei erweist sich die gewahlte und implemen-tierte Variante des Autorenportals als Vorteil. Es werden Barcodes als Bildzuruckgegeben, und somit sind die ETHOC-IDs losgelost von physischen Do-kument. Die Barcodes konnen direkt auf Etiketten gedruckt und an Objekteangebracht werden. Dabei gilt es aber das Problem zu losen, dass Vandalen dieBarcodes entfernen oder eigene anbringen konnen.

Ein Sitzungsraum, der mit einer ETHOC-ID verknupft ist, konnte in seinemvirtuellen Gegenstuck einen Link auf das Reservationssystem anbieten. Somitmusste ein Benutzer nichts anderes tun als den Barcode einzuscannen und aufden Link zu klicken. Alternativ konnte ein Reservationsmodul implementiertwerden. Von diesem Modul konnten z.B. neben der Raumbewirtschaftung auchdie Bibliotheken Gebrauch machen.

Ein virtuelles Gegenstuck eines Kopierers konnte zum Beispiel fur die BenutzerLinks zu einer kurzen Bedienungsanleitung oder zu einem interaktiven Fuhreranbieten. Fur den Service-Monteur konnte ein Link zur passwortgeschutztenRevisionsseite und zum Ersatzteillager angebracht sein.

Doch dem “doc”-Typ sind Grenzen bei der Modellierung von Objekten gesetzt.Dies soll am Beispiel eines Druckers mit virtuellem Gegenstuck erlautert wer-den. An einer Hochschule wie der ETH stehen zahlreiche Drucker, verteilt uberviele Gebaude. Angenommen ein Student befindet sich vor einem Drucker, dener nie zuvor benutzt hat und mochte ein Dokument drucken. Das virtuellesGegenstuck konnte die Druckparameter mitteilen oder den Druckertreiber zumDownload anbieten. Dies ist problemlos mit dem “doc”-Typ moglich. An derETH konnen Dateien uber eine Web-Schnittstelle an jeden offentlichen Drucker

8.3. NEUE ETHOC-TYPEN 81

gesendet werden. (siehe http://vpp-router1.ethz.ch/vpp.html). Das virtuelle Ge-genstuck konnte dann einen Link auf diese Seite anbieten und seine Parametergleich selbst eintragen. Auch dies ware mit dem “doc”-Typ moglich. Folgen-des Szenario ist aber nicht moglich: Angenommen der Student hat zuvor einenETHOC-Barcode von einem Dokument eingescannt und mochte dieses auf demDrucker ausdrucken. Der aufmerksame Leser wurde jetzt fragen, wo das Pro-blem liege, man konne doch die Online-Kopie runterladen und dann das Do-kument mit den oben beschriebenen Mechanismen ausdrucken. Dies ist richtig,doch was passiert, wenn der Barcode-Leser nicht mit einem PC, sondern einemMobiltelefon kommuniziert? Auf einem Mobiltelefon konnen keine Dateien her-untergeladen werden (oder zumindest noch nicht). Das virtuelle Gegenstuck desDruckers musste also auf die Historie des Benutzers zuruckgreifen und fragen,welche Dateien gedruckt werden sollen. (Eine Variante ware, dass bei einemzweifachen Einscannen des Druckerbarcodes automatisch das letzte Dokumentaus der Historie gedruckt wurde.) Der “doc”-Typ kann dies aber nicht leisten.Fur dieses Szenario musste ein neuer ETHOC-Typ entwickelt werden, genauerein Typ der mit der Historie des Benutzers arbeitet.

Es mag auf den ersten Blick etwas aufwendig klingen, fur diesen kleinen Sonder-fall gleich einen neuen Typ zu definieren. Doch vielleicht ware ETHOC mit demDrucker-Typ zusammen sogar die Killerapplikation im Bereich des Verknupfensvon Alltagsgegenstande mit dem Internet. Man stelle sich vor, es stehen zweiPersonen im Gang und diskutieren uber ein Paper der ersten Person. Die zweitePerson mochte gerne eine Kopie davon. Also scannt sie mit ihrem Mobiltelefondie ETHOC-ID des Papers geht zum Drucker und scannt dessen ID zweimalein, und schon ist das Dokument gedruckt.

Zusammengefasst kann gesagt werden, dass mit dem “Doc”-Typ auch Objek-te sehr gut modelliert werden konnen. Doch zusatzliche Typen, wie der obi-ge Drucker-Typ, wurden weiterfuhrende Szenarien erlauben. Der folgende Ab-schnitt erklart nun, wie neue ETHOC-Typen ins System eingebaut werdenkonnen.

8.3 Neue ETHOC-Typen

8.3.1 Autorenseitig

Wie in Abschnitt 7.1.1 erklart, beginnt die XML-Definition des virtuelle Ge-genstuck mit dem Wurzelement “ethoc”, welches ein Attribut “type” besitzt.Es muss nun eine neue Struktur erstellt werden, die “ethoc” als Wurzelementund einen neuen noch nicht verwendeten Wert im Attribut “type” besitzt. Dazumussen passende Werkzeuge entwickelt werden, um die virtuellen Gegenstuckedes neuen Typs zu erstellen resp. zu andern. Dem Entwickler neuer Werkzeugesteht frei, neue Java-Pakete oder sogar eine andere Programmiersprache zu ver-wenden. Die neuen Werkzeuge werden dem System bekannt gemacht, indem ihreEinstiegspunkte und Namen in der Datei “authoringtools.xml” notiert werdenAlle ETHOC-Typen werden in der Datenbank in der Tabelle “doc” gespeichert,in welcher nebst der XML-Struktur noch redundante Informationen abgelegtwerden (siehe Abschnitt 7.7).


8.3.2 Benutzerseitig

Greifen Benutzer uber das Benutzer-Portal zu und fugen dort neue ETHOC-IDs in ihre Historie ein, so muss das Verhalten beim Auftreten von Duplika-te modelliert werden. Zum Beispiel macht es fur IDs vom Typ “doc” keinenSinn, mehrfach in die Historie aufgenommen zu werden, fur den oben skiz-zierten Drucker-Typ aber vielleicht schon. Zweimal die selbe Drucker-ID hin-tereinander konnte bedeuten, dass der Benutzer das letzte Dokument automa-tisch drucken lassen will, wahrend ein einmaliges Einlesen der Drucker-ID, dasDrucken eines auszuwahlenden Dokumentes innerhalb der Historie symbolisie-ren mag. Das gewunschte Verhalten beim Einfugen in die Benutzer-Historie wirddurch Klassen modelliert, die die abstrakte Klasse “HistoryAdder” erweitern.Anhand des ETHOC-Typs ruft das System den zugehorigen “HistoryAdder”auf. Dieser wird uber Namenskonvention bestimmt. Der Name besteht darin,dass der Typ in Grossbuchstaben an “HistoryAdder” angefugt wird. Wird al-so ein neuer ETHOC-Typ namens “xyz” eingefuhrt, so muss es eine Klasse“HistoryAdderXYZ” mit den oben beschriebenen Eigenschaften implementiertwerden.

Das Resultat der ID-Auflosung ist ein XML-, WML- oder HTML-String. Diesgeschieht durch eine XSL-Transformation. Fur jeden ETHOC-Typ und jedeMarkup-Sprache mussen ein oder mehrere XSLT-Dokumente erstellt werden.In der Datenbank wird die URI der Dateien (ohne Endung “.xsl”) eingetragen.Gibt es fur eine Markup-Sprache mehrere XSLT-Dateien (wie z.B. WML imTyp “doc”), die je einen speziellen Teil anzeigen und zwischen deren Ausgabennavigiert werden kann, sollten sie einen gemeinsamen Stamm im Dateinamenhaben. Als URI in die Datenbank wird der Pfad plus der Stamm eingetragen.Erhalt das Servlet “ShowID” den Parameter “part”, so wird an die URI derParameter und die Endung “.xsl” konkateniert und so der Dateiname konstru-iert. Existiert kein Parameter namens “part”, so wird lediglich die XSL-Endungangefugt.

Fur den ETHOC-Browser mussen Model- und View-Objekt geschrieben wer-den. Die neuen Klassen werden uber Namenskonvention vom Browser gefunden.Heisst der neue ETHOC-Typ “xyz”, so mussen die Klassen “ModelXYZ” und“ViewXYZ” benannt werden.

8.4 Einbinden neuer Barcode-Leser

Wird der Barcode-Leser auf einem System betrieben, auf dem der ETHOC-Browser nicht installiert werden kann, z.B. weil keine Java-Edition fur dasSystem existiert, so muss der Barcode-Leser den HTML- oder WML-Browseroffnen und den eingelesenen Barcode mit weiteren Parametern einem Servletubergeben. Es gibt also eine serverseitige Anbindung und eine Anbindung imETHOC-Browser.

8.4.1 Serverseitige Anbindung

Am einfachsten ist es, den HTML-Browser des Benutzers zu offnen, und dasServlet “Ethoc.Resolving.LoginHTML” zu adressieren. Dabei muss der Parame-

8.4. EINBINDEN NEUER BARCODE-LESER 83

ter “next” den Wert “Ethoc.Resolving.AddIDHTML” und “docID” den Wertder ETHOC-ID enthalten. Weitere optionale Parameter sind “anonymus”, wel-cher dem Benutzer erlaubt auf einen Login zu verzichten, und “intro”, wel-cher eine Erklarung einblendet, dass ein Login zur Verwaltung der personlichenOnline-Historie erforderlich ist. Analog kann ein WML-Browser benutzt wer-den. Fur HTML-Browser besteht alternativ die Moglichkeit, das Servlet “Ethoc.Resolving.AddIDHTML” mit den Parametern “docID” (der ETHOC-ID), “id”(der Benutzer-ID) und “pass” (dem Benutzer-Passwort) zu adressieren. Wirdder Parameter “cookies” mit dem Wert “on” ubergeben und der Browser un-terstutzt Cookies, so werden die Benutzerdaten in Cookies gespeichert und derBenutzer muss sich fur weitere Zugriffe nicht mehr ausweisen.

Ein aufwendigerer Weg besteht darin ein eigenes Servlet zu programmieren, dasVorarbeit leistet. Zum Beispiel indem es den Benutzer automatisch authenti-siert, die Angaben in Cookies oder WML-Variablen speichert und dann erstzum Login-Servlet umleitet. Wird eine indirekte Authentisierung gewahlt, wiez.B. in AirClic uber die Seriennummer (siehe Abschnitt 7.5), muss ein Matchingzwischen propriaterer Authentisierung und ETHOC-Benutzer-ID mit Passwortumgesetzt werden. Hierfur muss eine Tabelle in der Datenbank erstellt werden,welche das Attribut “user” mit dem Inhalt die ETHOC-Benutzer-IDs enthalt.Der Name der neuen Tabelle muss in der Konfigurationsdatei “BCReader.cfg”auf dem Server eingetragen werden. Dadurch kann der Benutzer beim Bearbei-ten seines Profils Eintrage von Barcode-Leser, die ihn indirekt authentisieren,loschen, z.B. wenn die entsprechenden Barcode-Leser sich nicht mehr in seinemBesitz befinden.

8.4.2 Anbindung im ETHOC-Browser

Wird der Barcode-Leser uber den ETHOC-Browser verwendet, so muss lediglicheine Klasse geschrieben werden, die das Interface “Ethoc.Browser.IDReader”implementiert. Der Benutzer kann den Barcode-Leser verwenden, wenn er imKonfigurationsfenster den Namen der neuen Klasse (inkl. Paket) eingibt.

Kapitel 9

Diskussion und Ausblick

Dieses Kapitel fasst die Arbeit zusammen. Die Arbeit wird bewertet und alsAusblick weitere Arbeiten vorgeschlagen.

9.1 Erfullung der Aufgabenstellung

Die Ziele der Diplomarbeit (siehe Anhang A) sind erreicht worden.

1. Autorenseite: Fur die Autoren wurde als webbasiertes Werkzeug das Auto-renportal erstellt. Der Druckertreiber wurde nach der Analysephase wegendes immensen erwarteten Implementierungsaufwandes auf eine spatere Ar-beit verschoben.

2. XML-Schema: Die virtuellen Gegenstucke werden in XML-Form verwaltet(siehe Anhang D.1).

3. Zuordnung Dokument und Funktionen: Mogliche Online-Funktionalitatenwerden innerhalb der XML-Struktur verwaltet (siehe Abschnitt 5.5.1).Um neue Funktionalitaten, die es zum heutigen Zeitpunkt nicht gibt, zuermoglichen, wurde die Idee von Modulen umgesetzt (siehe Abschnitte5.5.2, 7.3 und 8.1).

4. Verwaltung: Zur Verwaltung der Online-Ressourcen zu gedruckten Doku-mente dient die Datenbank.

5. Mapping-Service: Das Mapping von ID zur XML-Struktur geschieht ineinem Servlet, das die Datenbank zu Hilfe nimmt.

6. Benutzungskonzepte: In Abschnitt 2.1 sind motivierende Szenarien vorzu-finden. Zur Verifikation der Implementierung sind Szenarien in Abschnitt4.1 aufgestellt worden, die anschliessend in Abschnitt 9.3 diskutiert wer-den. Sie sind mit dem ETHOC-System alle realisierbar.

7. Skizzierung einer Erweiterung: Die vorliegende Implementierung eignetsich nicht nur fur gedruckte Dokumente, sondern auch fur andere physischeObjekte (siehe Abschnitt 8.2). Genugen die bereitgestellten Mechanismen

85

86 KAPITEL 9. DISKUSSION UND AUSBLICK

den Anforderungen nicht, kann ETHOC um neue Typen erweitert werden(siehe Abschnitt 8.3).

9.2 Bewertung der Arbeit

Mit dieser Arbeit ist als Grundgerust ein System entstanden, welches das Ver-walten und Vermitteln von beliebigen virtuellen Gegenstucken ermoglicht. Alseine Auspragung von virtuellen Gegenstucken wurde der Dokument-Typ im-plementiert. Der Dokument-Typ selbst besitzt als weitere Flexibilitat die An-bindung von Modulen. Module konnen aber bei Bedarf auch fur andere Typeneingesetzt werden. Das Einbinden neuer Typen oder Module geschieht uber Na-menskonventionen und Konfigurationsdateien (siehe Kapitel 8).

Das System ist plattformunabhangig, da die Java-Technolgie verwendet wordenist. Klienten, fur die keine Java-Edition existiert, konnen uber eine WML- oderHTML-Schnittstelle auf die virtuellen Gegenstucke zugreifen. Ein Benutzer hateine globale Historie. IDs, die er z.B. mit dem Mobiltelefon eingelesen hat, stehenihm spater auch im ETHOC-Browser oder im HTML-Portal zur Verfugung.

Der lokale ETHOC-Browser besitzt einen Cache, in welchen die Dokumente undDateien heruntergeladen werden. Der Cache ist fur alle Benutzer eines Rechnersgemeinsam. D.h. wenn jemand eine Datei heruntergeladen hat, steht sie allenzur Verfugung. Jeder Benutzer des ETHOC-Browsers kann eigene Kommentarean ein virtuelles Gegenstuck anbringen, die vom ETHOC-Browser verwaltetwerden und die fur die anderen Benutzer naturlich nicht sichtbar sind.

Zu Beginn der Arbeit, war ein Schlagwort “automatische Aktionen”. Der Be-nutzer liest einen Barcode ein und es geschieht etwas automatisch auf seinemGerat. Dies funktioniert nicht fur HTML- und WML-Browser, da diese keineautomatischen Aktionen erlauben (siehe Abschnitt 5.4). Einzig fur den ETHOC-Browser waren automatische Aktionen moglich. Statt Dateien automatisch zuoffnen und Kalendereintrage einzutragen, wurde als einziger Automatismus,nebst der XML-Verwaltung der IDs, ein Dateien-Cache eingerichtet. Dateien,die eine vom Benutzer festgelegte Grosse nicht ubersteigen, werden automa-tisch heruntergeladen. Erst auf Verlangen des Benutzers werden sie geoffnetoder in ein gewunschtes Zielverzeichnis kopiert. Kalendereintrage sind Bestand-teil der XML-Struktur. Auch sie werden erst auf Verlangen hin extrahiert undeingetragen resp. gespeichert.

9.3 Verifikation der Benutzungsszenarien

In Abschnitt 4.1 sind Benutzungsszenarien aufgestellt worden, mit dem Zweckdie Arbeit spater an diesen zu verifizieren – was der Inhalt dieses Abschnittesist.

9.3.1 Filmveranstaltung und drahtlose Kommunikation

Dieses Szenario (siehe Abschnitt 4.1.1) kann wie folgt mit ETHOC umgesetztwerden: Der Student hat auf seinem Laptop den ETHOC-Browser und den

9.3. VERIFIKATION DER BENUTZUNGSSZENARIEN 87

Treiber fur seinen Barcode-Leser installiert. Der Aufruf zwischen Treiber undETHOC-Browser wurde bereits im Design anders konzipiert, als es im Szenariovorgestellt wurde. Es ist nicht der Treiber, der den ETHOC-Browser aufruft,sondern umgekehrt. Dadruch werden die IDs nur dann ubertragen, wenn derETHOC-Browser bereits gestartet ist. Diese Art der Kommunikation erlaubtdem Benutzer seinen Barcode-Leser mit anderen Applikationen zu benutzen,falls er andere Barcodes einliesst.

9.3.2 Vorlesung und Studenten-Raum

Auch dieses Szenario (siehe Abschnitt 4.1.2) ist in ETHOC moglich: In diesemFall ist der ETHOC-Browser auf den PC installiert und der Student hat denrichtigen Treiber installiert. Der Aufruf zwischen Barcode-Leser und ETHOC-Browser ist, wie im Abschnitt zuvor erwahnt, in der anderen Richtung im-plementiert worden. Im Gegensatz zum ursprunglichen Szenario besitzt derETHOC-Browser einen Cache. Die Dateien werden also nicht in ein vom Be-nutzer gewahltes Verzeichnis kopiert, sondern in den Cache. Der Benutzer kanndann die Dateien direkt offnen oder sie zur Bearbeitung in ein Verzeichnis seinerWahl kopieren lassen.

Anderungen an einem virtuellen Gegenstuck werden einem Benutzer durch dieMeldung “update” in der ID-Ubersicht im oberen Breich des ETHOC-Browsersangezeigt. Im Falle von Dokumenten, Dateien, Kalendereintragen, Modulen undLinks wird bei einer Anderung angezeigt, welches Element sich verandert hat,oder hinzugekommen ist. Somit ist ein Benutzer leicht uber Anderungen in-formiert. Dateien, die nicht veroffentlich sind (wie in diesem Szenario die Mu-sterlosung), befinden sich weder im Cache, noch kann eine Interaktion mit ih-nen gestartet werden. Erst ab dem vom Autor festgelegten Publikationszeit-punkt werden sie, sofern sie die vom Benutzer festgelegte Maximalgrosse nichtuberschreiteen, heruntergeladen.

9.3.3 Aktionen auf Kleinstrechner

Dieses Szenario (siehe Abschnitt 4.1.3) wurde ebenfalls realisiert: Es wurdemit einem Rechner gearbeitet, auf dem der ETHOC-Browser nicht installiertwerden kann, weil keine Java-Edition verfugbar ist. Allerdings existiert einHTML-Browser. Somit startet der Barcode-Leser den Browser mit der URL desBenutzer-Portals gemass Abschnitt 8.4.1. Da es sich, um einen HTML-Browserhandelt, werden die PDF-Dateien zum Downlaod angeboten, unabhangig da-von, ob der Rechner die Datei offnen kann oder nicht. Die Unterscheidung derKlienten wurde also grob, aber fur die Praxis einsatztauglich, umgesetzt. Wiein Abschnitt 7.5 besprochen, werden die Klienten nach den Sprachen XML,HTML und WML kategorisiert. Nur den WML-Klienten steht der Downloadvon Dateien generell nicht zur Verfugung.

9.3.4 Annonce und Mobiltelefon

Das Szenario ist wie in Abschnitt 4.1.4 beschrieben mit ETHOC realisierbar.


9.4 Vorschlage fur weiterfuhrende Arbeiten

Mit dieser Arbeit ist ETHOC nicht abgeschlossen. Es sind einige interessanteArbeiten moglich, die auf diese Arbeit aufbauen.

9.4.1 Modifizierende Arbeiten

Diese Arbeiten umfassen das Studium und das Abandern von bestehendemKode.

• Die Kalendereintrage werden im Moment uber Eingabefelder vom Autorabgefragt und dann in die XML-Struktur eingebaut. Ein anderer Ansatzware, dem Autor zusatzlich zu ermoglichen, vCalendar-Dateien (*.vcs)hochzuladen. Diese wurden durch das System geparst und dann in dieXML-Struktur integriert.

• Als Online-Kopien der Dateien werden im Moment alle Formate unter-stutzt. Im Hinblick auf spatere Drucker-Objekte ware eine Einschrankungauf PDF und PostScript denkbar. Hierfur musste dem Autor ein Werkzeugzur Verfugung gestellt werden, mit welchem seine Dokumente automatischkonvertiert werden.

• Der logische Online-Drucker (siehe Abschnitt 5.3.3) konnte in dasjenigeServlet eingebaut werden, das den Barcode anzeigt. Somit konnte ein Au-tor wahlen, ob er den Barcode selbst in seine Applikation einfugen will,oder ob das System dies fur ihn machen soll.

• Unterstutzung standardisierter Barcodes, wie EAN13.

9.4.2 Erweiternde Arbeiten

Diese Arbeiten setzen die Kenntnis der Namenskonventionen und der Strukturder Konfigurationsdateien voraus. Der ETHOC-Kode wird dabei nicht veran-dert.

• Der lokale logische Drucker (siehe Abschnitt 5.3.2) konnte als zusatzlicheslokales Werkzeug implementiert werden. Dabei wurden nur die minimalnotwendigen Eingaben vom Autor erfragt und dieser dann aufs Autoren-Portal verwiesen werden.

• Entwicklung weiterer Typen, wie der in Abschnitt 8.2 erwahnte Drucker-Typ, einen Link-Typ, welcher einen Barcode mit einer Internet-Seite ver-bindet, oder einen Visitenkarten-Typ, der die Person ins Adress- oderTelefonbuch eintragt.

• Entwicklung weiterer Module fur den Dokumenten-Typ, wie z.B. ein Mo-dul, das die Anzeige eines bestimmten Dokumentes auf einen zu bestim-menden Benutzerkreis limitiert oder ein Modul, das die Anmeldung anVeranstaltungen ermoglicht.

• Verteilte Organisation der Datenbank umsetzen.

Danksagung

Am Ende der Diplomarbeit und somit meines Studiums angelangt, widme ichdiese Arbeit meiner Mutter und meinen Grosseltern, die mir das Studium er-moglicht haben.

Ich bedanke mich bei meinen Betreuern Jurgen Bohn und Michael Rohs furdie fruchtbaren inhaltlichen Diskussionen, das Zurverfugungstellen der fur dieseArbeit benotigten Infrastruktur und fur das Korrekturlesen dieses Berichtes.

Herzlichen Dank an alle.

89

Anhang A

Aufgabenstellung

Thema dieser Diplomarbeit ist die Erweiterung von gedruckten Dokumenten –wie z. B. Postern, Veranstaltungshinweisen, Zeitschriftenartikeln oder Lehrma-terialien – um Online-Informationen und Online-Funktionalitat. Als Informati-onsanker vom physischen Dokument zur virtuellen Erweiterung sollen Barcodesverwendet werden. Diese haben den Vorteil, dass sie sich mit herkommlicherTechnik einfach ausdrucken und kopieren lassen und weder spezielle Hardware,noch spezielle Printmedien erfordern. Die Kosten fur diese Art von “physischenHyperlinks” sind also sehr gering. Wesentliche Bestandteile der Arbeit sind Kon-zepte fur das Auflosen der gelesenen Identifikationsnummer, das Anzeigen unddie Interaktion mit den zugeordneten Daten und Operationen, die Verknupfungvon Online-Inhalten und deren Verwaltung und die Ausarbeitung von einigenexemplarischen Benutzungsszenarien. Durch die zu entwickelnde Infrastruktursoll einerseits der Autor beim Erstellen eines Dokumentes und der zugehorigenFunktionalitat, andererseits der Leser, der ausgehend vom ausgedruckten Do-kument auf dessen Online-Reprasentation oder weitere zugeordnete Ressourcenzugreifen will, unterstutzt werden.

Szenarien

Ein Anwendungsszenario konnte wie folgt aussehen: Aushange, Plakate undFlyer werden mit Barcodes versehen. Diese lassen sich mit einem mobilen Gerat,wie einem PDA, einem Mobiltelefon oder einem am Schlusselbund befestigten –eventuell drahtlos kommunizierenden – Barcodescanner lesen. Das Ubermittelnder gelesenen Identifikationsnummer lost dann bestimmte Aktionen in der zuentwickelnden Infrastruktur und auf dem Gerat des Benutzers aus. So konntenReservierungen vorgenommen, Kalendereintrage erstellt und Detailinformatio-nen abgerufen werden. Hierbei bestehen kaum Beschrankungen bezuglich derArt der gelieferten Informationen oder der ausgelosten Aktionen. Sowohl textu-elle, als auch auditive und grafische Ausgaben sind denkbar.

Ein zweites Szenario ist durch die Einbettung von Barcodes in Zeitschriftenar-tikeln oder wissenschaftlichen Publikationen gegeben. Der Barcode konnte zueinem vom System verwalteten “Portal” fur den Artikel fuhren, auf dem eine

91

92 ANHANG A. AUFGABENSTELLUNG

elektronische Version verfugbar ist, auf dem uber den Artikel diskutiert wirdoder auf dem auf thematisch verwandten Arbeiten verwiesen wird. Hierbei soll-te der Autor steuern konnen, welche Aktionen mit seinem Dokument verknupftsind, bzw. welche weiteren Aktionen und Inhalte Leser hinzufugen durfen.

Der Lehrbetrieb der ETH bietet weitere Anwendungsmoglichkeiten, z.B. dasAnknupfen von Online-Inhalten an Vorlesungs-, Ubungs- und Praktikumsun-terlagen. So konnte ein auf dem Ubungsblatt aufgedruckter Barcode den Zugriffauf Beispiellosungen ermoglichen. Die Infrastruktur wurde dabei sicherstellen,dass die Losungen erst ab einem bestimmten Zeitpunkt freigegeben werden. InVorlesungsunterlagen liessen sich multimediale Lehrinhalte einbauen, die durchdas Scannen des entsprechenden Barcodes abgerufen und auf einem PDA oderLaptopbildschirm angezeigt werden.

Bestandteile der Arbeit

Ein System, das die genannten Szenarien ermoglicht, muss sowohl Autoren, beider Zuordnung der Online-Ressourcen zu einem Dokument, als auch Leser, beider Abbildung von Identifikationsnummern auf Online-Inhalte, von Dokumentenunterstutzen.

Ein elementarer Dienst zur Unterstutzung des Autors konnte als Druckertreiberrealisiert sein, der beim Drucken eines Dokumentes automatisch eine Online-Version zusammen mit Metainformationen, wie Angaben zu Verfasser oderDruckzeitpunkt, erstellt und einen Barcode in das zu druckende Dokument ein-bettet. Dieser Minimalansatz kommt weitgehend ohne Eingreifen des Autorsaus und stellt damit sicher, dass auch Informatik-Laien das System benutzenkonnen und dass die Benutzung keinen Mehraufwand erfordert.

Fur spezielle Metainformationen, wie der Gultigkeitsdauer eines Dokumentesoder bestimmten Aktionen, die beim Scannen der Markierung ausgefuhrt werdensollen, soll zusatzlich ein webbasiertes Werkzeug angeboten werden, das die Ein-gabe einer Dokumentbeschreibung und der dazugehorigen Online-Ressourcenermoglicht. Dieser Dienst gibt daraufhin einen Barcode in verschiedenen For-maten zuruck und legt die Dokumentbeschreibung in strukturierter Form, z.B.als XML-Dokument, ab.

Fur die Leser von Dokumenten soll eine Infrastruktur entwickelt werden, wel-che die Abbildung von gelesenen Barcodes auf virtuelle Inhalte und Aktionenermoglicht. Nach dem Einlesen der Barcodes konnen die damit verknupftenOnline-Ressourcen eingesehen und entsprechende Aktionen auf dem Gerat desBenutzers (z.B. Anzeigen von Metainformationen, Erstellen von Kalenderein-tragen) ausgelost werden. Optional sollen auch die Leser eines Dokuments inder Lage sein, eigene Online-Inhalte zu erganzen.

Ziele

• Entwicklung eines Dienstes zur Einbettung von Barcodes in Dokumente(a) als Druckertreiber und (b) als webbasiertes Werkzeug (“Tag Creation-Service”)

93

• Erstellung eines XML-Schemas fur verknupfte Informationsinhalte undMetainformationen zu gedruckten Dokumenten

• Konzeption eines flexiblen Zuordnungsschemas von Online-Funktionalitatzu Dokumenten

• Verwaltung der Online-Ressourcen zu gedruckten Dokumenten

• Umsetzung von gescannten Identifikationsnummern auf Online-Inhalte(“Mapping-Service”)

• Benutzungskonzepte fur das “Einsammeln” von Identifikationsnummernund der Anzeige von Inhalten auf Client-Geraten unter Berucksichtigungvon verschiedenen zugrundeliegenden Hardwareplattformen (Memory-Bar-codescanner, drahtlos kommunizierende Barcodescanner, PDAs, Worksta-tions)

• Prototypische Erprobung einfacher Szenarien

• Skizzierung einer Erweiterung auf beliebige physische Objekte

Betreuung

Die Arbeit wird von Jurgen Bohn <[email protected]> und Michael Rohs<[email protected]> betreut und steht unter der Aufsicht von Prof. Dr. Frie-demann Mattern.

Termine

Beginn der Diplomarbeit ist Montag, der 5. November 2001. Die schriftlicheAusarbeitung muss bis Montag, den 4. Marz 2002 eingereicht werden.

Prof. Dr. F.MatternFachgruppe Verteilte SystemeETH Zurich

94 ANHANG A. AUFGABENSTELLUNG

Anhang B

Glossar

DOM Document Object Model ist eine plattformneutrale und sprachenun-abhangige Schnittstelle, um dynamisch auf (XML-)Dokumente zuzugrei-fen und deren Struktur und Inhalt zu andern. Es ist eine offizielle Empfeh-lung des World Wide Web Consortiums (W3C). Ein DOM-Parser wandeltein Dokument in eine Baumstruktur um und traversiert resp. manipuliertsie.

DTD Document Type Definition beschreibt, wie (XML-)Dokumente aussehenmussen, um gultig zu sein. Es beschreibt die Reihenfolge, Art, Kardinalitatund Wertebereich von (XML-)Elementen des Dokuments.

EAN Das European Article Numbering System ist der internationale Barcode-Standard fur Produkte.

HTML HyperText Markup Language ist eine auszeichnende Beschreibungs-sprache fur Dokumente. Dokumente im HTML-Format werden in Brow-sern im vom Autor gewunschten Erscheinungsbild angezeigt.

RFID Radio Frequency IDentification ist eine Form der drahtlosen Identi-fikation. RFID-Tags werden an Objekte angebracht, um sie dadurch zuidentifizieren.

SAX steht fur Simple API for XML. Beim Parsen eines XML-Dokuments mit-tels SAX treten Events auf, die von einer Applikation verarbeitet werdenkonnen. SAX ist ein De-facto-Standard und eine alternative Moglichkeit,mit Inhalten eines XML-Dokuments zu arbeiten.

UPC ist ein Barcode-Typ und steht fur Universal Product Code. Er wur-de ursprunglich entwickelt um die Lagerbewirtschaftung zu beschleunigenund Prozessflusse besser beobachten zu konnen. UPC wird in den USAeingesetzt.

XML EXtensible Markup Language ist eine Strukturbeschreibungssprache auflogischer nicht auszeichnender Ebene und eignet sich deshalb sehr gut furDatenaustausch und -abgleich. XML ist eine Empfehlung des World WideWeb Consortiums (W3C).

95

96 ANHANG B. GLOSSAR

XSLT EXtensible Stylesheet Language Transformations ist ein standardisier-ter Mechanismust, wie ein XML-Dokument in ein anderes Dokument mitneuer Struktur umgewandelt werden kann. XSLT ist eine Empfehlung desWorld Wide Web Consortiums (W3C).

Anhang C

EingesetzteSoftwareprodukte

Dieser Anhang beschreibt die eingesetzten Programme, deren Konfiguration undallfallige Bugs, die gefunden wurden. Alle Softwareprodukte mit Ausnahme desBetriebssystems und der Programmiersprache befinden sich im Ordner “da-deploy” auf der Diplomarbeits-CD.

C.1 Windows 2000

Es wurde auf einem Windows 2000-Rechner gearbeitet. Als Dateieinsystem wur-de NTFS benutzt, was wichtig fur den Betrieb der Datenbank ist (siehe Ab-schnitt 7.7).

C.2 JAVA

Fur den Betrieb von ETHOC muss Java auf Server-Seite als auch auf Klienten-Seite, sofern der ETHOC-Browser erwunscht ist, installiert sein. Fur diese Di-plomarbeit wurde JDK 1.3.1 01 eingesetzt.

C.3 Jakarta Tomcat

Als Serlvet-Engine wurde Jakarta Tomcat 4.0.1 [31] eingesetzt. Die Zip-Dateiwurde ins Verzeichnis “C:\jakarta-tomcat-4.0.1” entpackt. Die Umgebungsva-riable “CATALINA HOME” wurde auf “C:\jakarta-tomcat-4.0.1” und die Um-gebungsvariable“JAVA HOME” auf “C:\dev\jdk1.3.1 01”, den Pfad des JavaDeveloper Kits, gesetzt.

Jakarta Tomcat wird mit dem Befehl “startup” gestartet. Die entsprechendeBatch-Datei befindet sich unter “C:\jakarta-tomcat-4.0.1\bin\”. Ist Tomcat Ja-karta gestartet, konnen keine Java-Klassen mehr ausgetauscht oder eingefugt

97

98 ANHANG C. EINGESETZTE SOFTWAREPRODUKTE

werden. Die Installation der ETHOC-Distribution muss also vor dem Start er-folgen. Dies geschieht indem der Ordner “ethoc” (auf der CD im Ordner “da-deploy\webapps”) nach “C:\jakarta-tomcat-4.0.1\webapps\” kopiert wird.

Bugs

In dieser Arbeit wird WMLScript benutzt. WMLScript hat den Content-Typ“vnd.wap.wmlscript” Leider ist dieser Content-Typ in jakarta falsch gesetzt,was viele Mobiltelefone zum Abbrechen bewegt. Im Ordner “C:\jakarta-tomcat-4.0.1\conf\” befindet sich die Datei “web.xml”. Diese bestimmt unter anderem,welche Datei-Endungen welchen Content-Typ haben. Es muss “vnd.wap.wmls”durch“vnd.wap.wmlscript” ersetzt werden.

C.4 XALAN

Zur XSL-Transformation wurde XALAN [25] eingesetzt. Die entsprechende Bi-bliothek “xalan.jar” befindet sich im Ordner “da-deploy” und muss ins Verzeich-nis C:\jakarta-tomcat-4.0.1\common\lib kopiert werden.

C.5 XERCES

Xerces [26] ist ein XML-Parser und bereits in Jakarta Tomcat vorhanden. Esmuss somit nichts installiert werden.

C.6 MySQL

Als Datanbank wurde MySQL [27] in der Version 3.23.46a verwendet. In derZip-Datei befindet sich “Setup.exe”. Das Programm startet die Installation.MySQL wurde direkt unter dem Laufwerk C installiert. Die Datenbank wurdeangepasst und um die ETHOC-Tabellen erweitert, indem MySQL mit dem Be-fehl “C:\mysql\bin\mysql -u root -p < install.sql.txt” gestartet wurde. Dabeiwird auch das Root-Passwort gesetzt, welches zuvor leer war und einige Benutzerentfernt, die in der Standard-Konfiguration praktisch Root-Rechte haben.

MySQL muss mit der Option --set-variable max allowed packet=16M gestartetwerden. 16 MByte ist laut MSQL-Manual [28] die maximale Paketgrosse desMySQL-Protokolls. Fur die Version 4.0 ist eine Grosse von 4 GByte vorgesehen.

C.7 MM.MySQL

Fur MySQL stehen zwei JDBC-Bibliotheken zur Verfugung. In dieser Arbeitwird die freie Bibliothek MM.MySQL [29] verwendet.

C.8. COS 99

Bugs

Folgendes Fehlverhalten wurde bei der Abfrage “SELECT MAX(id) FROMIdCoord” festegestellt. Ist die Tabelle leer liefert die Methode “getInt()” derKlasse “ResultSet” die Zahl 0. Dies ist legitim, wenn anschliessend die Methode“wasNull()” den Wert “true” zuruckgibt. Leider wird “false” zuruckgegeben.Aus diesem Grund kann nicht unterschieden werden, ob das Maximum 0 oderleer (null) ist. Das Problem wurde in dieser Arbeit umgangen, indem zuerstuberpruft wird, ob die Tabelle leer ist und dann die eigentliche Anfrage durch-gefuhrt wird.

C.8 COS

COS steht fur com.oreilly.servlet und ist eine Bibliothek, die den Umgang mitDatei-Uploads via Servlets erleichtert. In dieser Arbeit wurde die Version vom19. Juni 2001 benutzt.

Bugs und Einschrankungen

Ein Bug (oder Feature?) der Bibliothek ist, dass der Header, der die Dateienund die Parameter enthalt, nur einmal geparst werden kann und bei einem zwei-ten Versuch eine Exception auslost. Aus diesem Grund mussten das ETHOC-Servlet, welches fur die Aktionen verantwortlich ist, leicht abgeandert werden,damit es einen zweiten Aufruf vermeidet.

Die maximale Grosse des ganzen Headers inkl. Dateien, die ubertragen werden,muss beim Aufruf der Bibliothek bestimmt werden. Ist diese grosser als 230 Bytealso grosser als 1GB, wird eine Exception geworfen.

C.9 SUNs JPEG-API

JPEG-Dateien werden mittels dem Paket “com.sun.image.codec.jpeg” [22] er-zeugt. Da es Bestandteil von Java ist, muss es nicht extra installiert werden.

C.10 Acme Labs GIFEncoder

GIF-Dateien werden mit Hilfe der Klasse “Acme.JPM.Encoders.GifEncoder”[23] erzeugt. Um nicht das ganze Paket von Acme Labs zu installieren, wur-den die verwendeten Klassen in die ETHOC-Hierarchie eingebaut und befindensich unter “Ethoc.Authoring.Encoder”. Somit sind die Klassen Bestandteil vonETHOC und mussen nicht speziell installiert werden.

100 ANHANG C. EINGESETZTE SOFTWAREPRODUKTE

C.11 SmtpClient

“sun.net.smtp.SmtpClient” ist Bestandteil aber keine Standard-Bibliothek vonJava. Wird ein anderes Betriebssystem fur ETHOC verwendet, muss die Funk-tionalitat dieser Klasse zuerst uberpruft werden, denn SUN gibt keine Garanti-en, dass die Klasse auf allen Plattformen existiert und funktioniert. Um Emailszu senden, muss unter anderem ein SMTP-Server angegeben werden. Es wirdder SMTP-Server des Departements Informatik benutzt. Bei einer Installationmuss beachtet werden, dass ein Server genommen wird, der die Anfragen vonETHOC akzeptiert.

Anhang D

XML-Definitionen

D.1 doc.dtd

In diesem Abschnitt wird die Document Type Definition eines virtuellen Doku-mentes spezifiziert

<!ELEMENT ethoc (virt_doc)>

<!ATTLIST ethoc type (doc) #REQUIRED>

<!ELEMENT virt_doc (author, doc_info, contacts?, extend)>

<!ATTLIST virt_doc

id CDATA #REQUIRED

last_change CDATA #REQUIRED>

<!ELEMENT author (name, unit, office, email, phone, fax, homepage)>

<!ELEMENT name (#PCDATA)>

<!ATTLIST name visible (y | n) #REQUIRED>

<!ELEMENT unit (#PCDATA)>

<!ATTLIST unit visible (y | n) #REQUIRED>

<!ELEMENT office (#PCDATA)>

<!ATTLIST office visible (y | n) #REQUIRED>

<!ELEMENT email (#PCDATA)>

<!ATTLIST email visible (y | n) #REQUIRED>

<!ELEMENT phone (#PCDATA)>

<!ATTLIST phone visible (y | n) #REQUIRED>

<!ELEMENT fax (#PCDATA)>

<!ATTLIST fax visible (y | n) #REQUIRED>

<!ELEMENT homepage (#PCDATA)>

<!ATTLIST homepage visible (y | n) #REQUIRED>

101

102 ANHANG D. XML-DEFINITIONEN

<!ELEMENT contacts (contact+)>

<!ELEMENT contact (name, unit, office, email, phone, fax, homepage)>

<!ELEMENT doc_info (title, keywords?, intro?, valid_until )>

<!ELEMENT title (#PCDATA)>

<!ELEMENT keywords (#PCDATA)>

<!ELEMENT intro (#PCDATA|br)*>

<!ELEMENT valid_until (year, month, day)>

<!ELEMENT extend (online_copy?, calendar?, modules, links?, files?)>

<!ELEMENT online_copy (doc_copy+)>

<!ELEMENT doc_copy (#PCDATA)>

<!ATTLIST doc_copy

type CDATA #REQUIRED

size CDATA #REQUIRED


<!ELEMENT calendar (event+)>

<!ELEMENT event (summary, start, end, location, description)>

<!ATTLIST event

last_change CDATA #REQUIRED

time_zone CDATA #REQUIRED>

<!ELEMENT summary (#PCDATA)>

<!ELEMENT start (year, month, day, hour, min, sec)>

<!ELEMENT end (year, month, day, hour, min, sec)>

<!ELEMENT year (#PCDATA)>

<!ELEMENT month (#PCDATA)>

<!ELEMENT day (#PCDATA)>

<!ELEMENT hour (#PCDATA)>

<!ELEMENT min (#PCDATA)>

<!ELEMENT sec (#PCDATA)>

<!ELEMENT location (#PCDATA)>

<!ELEMENT description (#PCDATA|br)*>

<!ELEMENT modules (module+)>

<!ATTLIST modules last_config CDATA #REQUIRED>

<!ELEMENT module EMPTY>

<!ATTLIST module

name CDATA #REQUIRED

label CDATA #REQUIRED

id CDATA #REQUIRED

enabled (y | n) #REQUIRED

link CDATA #IMPLIED


<!ELEMENT links (link+)>

D.2. MODULES.DTD 103

<!ELEMENT link (url, label)>

<!ATTLIST link last_change CDATA #REQUIRED>

<!ELEMENT url (#PCDATA)>

<!ELEMENT label (#PCDATA)>

<!ELEMENT files (file+)>

<!ELEMENT file (fname, label, publish_date)>

<!ATTLIST file

type CDATA #REQUIRED

size CDATA #REQUIRED


<!ELEMENT publish_date (year, month, day)>

<!ELEMENT fname (#PCDATA)>

<!ELEMENT br EMPTY >

D.2 modules.dtd

Welche Module dem System zur Verfugung stehen, wird in der Datei “modu-les.xml” festgehalten, welche folgender Definition entsprechen muss:

<!ELEMENT modules (module+)>

<!ATTLIST modules last_config CDATA #REQUIRED>

<!ELEMENT module (name, label, entry_point_config, entry_point_use?,

notifier?)>

<!ATTLIST module

default_enabled (y | n) #REQUIRED

inserted_by CDATA #REQUIRED>


<!ELEMENT label (#PCDATA)>

<!ELEMENT entry_point_config (#PCDATA)>

<!ELEMENT entry_point_use (#PCDATA)>

<!ELEMENT notifier (#PCDATA)>

D.3 authoringtools.dtd

Welche Autorenwerkzeuge vorhanden sind, wird in der Konfigurationsdatei “au-thoringtools.xml” festgehalten, welche folgende Struktur aufweisen muss:

<!ELEMENT authoring (tool+)>

<!ELEMENT tool (name, entry_point)>


<!ELEMENT entry_point (#PCDATA)>

104 ANHANG D. XML-DEFINITIONEN

Literaturverzeichnis

[1] Friedemann Mattern, The Vision and Technical Foundations of UbiquitousComputing, October 2001,http://www.inf.ethz.ch/vs/publ/papers/ubicompvision.pdf

[2] Friedemann Mattern, Ubiquitous Computing – Der Trend zur Informati-sierung und Vernetzung aller Dinge, In: Gerhard Rossbach (Hrsg.): Mobi-le Internet, Tagungsband 6. Deutscher Internet-Kongress, dpunkt-Verlag,September 2001, pp. 107-119http://www.inf.ethz.ch/vs/publ/papers/Internetkongress.pdf

[3] Marc Langheinrich, Friedemann Mattern, Kay Romer, Harald Vogt, FirstSteps Towards an Event-Based Infrastructure for Smart Things, UbiquitousComputing Workshop (PACT 2000), October 15-19, 2000, Philadelphia,PA.http://www.inf.ethz.ch/vs/publ/papers/firststeps.pdf

[4] Jurgen Bohn, Michael Rohs, Klicken in der realen Welt, Konferenz Menschund Computer 2001, Workshop Mensch-Computer-Interaktion in allge-genwartigen Informationssystemen, Bad Honnef, 5.-8. Marz 2001http://www.inf.ethz.ch/vs/publ/papers/mc2001.pdf

[5] Deborah Anglin, Code Scanners and the Web,http://www.personal.psu.edu/users/a/a/aad152/6742/emerging.html

[6] T.L. Ashford, Barcode Symbologies –http://www.zebra.com/about/aboutbar.htm

[7] Russ Adams BarCode 1 – A Web Of Information About Bar Code,http://www.adams1.com/pub/russadam/

[8] Marshall Brain, How UPC Bar Codes Work,http://www.howstuffworks.com/upc.htm/printable

[9] Gerhard Donalies, Die Zukunft der automatischen Identifikation,Fraunhofer-Magazin 2.1999,http://www.fraunhofer.de/german/publications/df/df1999/299-11.htm

[10] Kevin Bonsor, How Smart Labels Will Work,http://www.howstuffworks.com/smart-label.htm/printable

[11] CollTown-Projekt,http://cooltown.hp.com

105

106 LITERATURVERZEICHNIS

[12] AAES Research Studying Effects of Artificial Reefs on Marine Life,http://www.ag.auburn.edu/aaes/information/highlights/summer00/reef.html

[13] Tim Kindberg, Sandro Hawke, The ‘tag’ URI scheme and URN namespace,September 2001,http://search.ietf.org/internet-drafts/draft-kindberg-tag-uri-01.txt

[14] EAN Scheiz (www.ean.ch), Barcoding: Technologien: UCC/EAN-128,http://194.209.37.59/deutsch/04 Komponenten/01 Barcoding/04-ean128.html

[15] FinePrint,http://www.context-gmbh.de/fineprint.htm

[16] Doug Tidwell: Introduction to XML, Tutorial, Juli 1999http://www.ibm.com/developerworks/education/xmlintro/

[17] Doug Tidwell: XML programming in Java, Tutorial, September 1999http://www.ibm.com/developerworks/education/xmljava/

[18] Netscape, Persistent Client State – HTTP Cookies, Preliminary Specifica-tion, 1999,http://home.netscape.com/newsref/std/cookie spec.html

[19] D. Kristol, L. Montulli HTTP State Management Mechanism, Februar1997,http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2109.html

[20] Versit Consortium, vCalendar – The Electronic Calendaring and SchedulingExchange Format, Version 1.0, September 1996,http://www.imc.org/pdi/vcal-10.ps

[21] Jason Hunter, COS-Bibliothek, Juni 2001http://www.servlets.com/cos/index.html

[22] Sun Microsystems, JPEG API,http://java.sun.com/products/jdk/1.2/docs/guide/2d/api-jpeg/

[23] Acme Labs, GIF Encoder,http://www.acme.com/java/software/Acme.JPM.Encoders.GifEncoder.html

[24] Sun Microsystems, JavaMail(TM) API, Dezember 2000http://java.sun.com/products/javamail/

[25] XALAN-Homepage,http://xml.apache.org/xalan-j/index.html

[26] XERCES-Homepage,http://xml.apache.org/xerces2-j/index.html

[27] MySQL-Downloadseite,http://www.mysql.org/downloads/index.html

LITERATURVERZEICHNIS 107

[28] MySQL Reference Manual,http://www.mysql.org/Downloads/Manual/manual.pdf

[29] MM.MySQL-Homepage, A Type IV JDBC driver for MySQL,http://mmmysql.sourceforge.net/

[30] Mobileinfo, Wireless Application Protocol - WAP,http://www.mobileinfo.com/WAP/components.htm

[31] Homepage Jakarta Tomcat,http://jakarta.apache.org/tomcat/index.html

Download - Entwurf und Implementierung des ETHOC-Systems · Every thing has online content Diplomarbeit Entwurf und Implementierung des ETHOC-Systems Nikolaos Kaintantzis [email protected]

Top Related