Erstellung des Datenübertragungsmoduls - RWTH
Werbung
Erstellung des Datenübertragungsmoduls „send2plotter“ zum Projekt CW-Plot-Service Seminararbeit Katinka Roosen, Matr.-Nr. 842942 Fachbereich 9, Scientific Programming Fachhochschule Aachen 1.Betreuer: Prof.Dr. Jörg Höttges 2. Betreuer: Günter Ermer Aachen, den 8.11.2012 2 Erstellung eines Datenübertragungsmoduls zum Projekt CW-Plot-Server Inhaltsverzeichnis 1. Überblick.......................................................................................................................................3 1.1. Problemstellung und Situation……………………............……………………………....3 1.2. Ziel………………………………………………............………………………………..3 2. Grundlagen/Werkzeuge/Konzepte……………………………............…………………………4 2.1. Programmiersprachen/Bibliotheken/DBMS……………………………...........…………...4 2.1.1. Python………………………………………………………............……………….4 2.1.2. Datenbanken……………………………………………………............…………...4 2.1.2.1. Allgemein…………………………………………………...........…………….4 2.1.2.2. PostgreSQL/psycopg2.py………...…………………...…............…………….5 2.1.3. ftplib.py………………………………………………………...........……………...6 2.2. Prozesse/Protokolle…………………...……………………………............……………….7 2.2.1. Daemon……………………….…...……………………………...........……….…..7 2.2.2. mk.daemon………………...……....……………………………............………….7 2.2.3. File Transfer Protocol…………...………………………………............………….9 2.3. Modularisierung………………………………………………………............………....12 2.3.1. Allgemein………………………………………………………..............………..12 2.3.2. Modul Webinterface…………………………………………...………………….12 2.3.3. Modul pdf2tiff………………………………………….…...……….......………..13 2.3.4. Modul send2plotter……………………………………………………...………...13 3. Modul send2plotter……………………………………………………………………….........14 3.1. FTP-Verbindung/Schnittstelle des Plotters...………………………………………...........14 3.2. Schnittstelle Datenbank……………...…………………............……………………........14 3.3. Algorithmen…………….……………..……………………………………………..........17 3.3.1. Vergabe von Jobtickets………...………...……......……………………................17 3.3.2. Ausgabereihenfolge……...…...…......……...…........………………………..........18 3.3.3. Warteschlangen……....……....……....…………….…...…………………........…19 3.4. Übersicht Programmablauf……...…...…….…………………………………………...…21 4. Fazit…………………………………………………………………………………............…22 5. Ausblick…………………………………………………………………………………..........22 6. Eidesstattliche Erklärung……………………………………………….........………………...24 7. Quellenverzeichnis…………………………………………………………………….............25 8. Abbildungs- und Tabellenverzeichnis…………………………………....……………...........27 3 Erstellung eines Datenübertragungsmoduls zum Projekt CW-Plot-Server 1. Überblick 1.1. Problemstellung und Situation Der IT-Service der Fachbereiche Bauingenieurwesen und Architektur der FH Aachen bietet den Studierenden dieser Studiengänge die Möglichkeit, Pläne und Zeichnungen im Gebäude der Bayernallee mittels des Plotters Océ ColorWave 600 zu plotten. Dies lief bisher so ab, dass die Studierenden in vorgegebenen Zeitfenstern mit Plottaufträgen beim IT-Service erscheinen und mit einem Mitarbeiter des IT-Services die im Laufwerk „exchange“ abgelegten Pläne kontrollieren. Anschließend schickt der zuständige Mitarbeiter die plt- oder pdf-Dateien mittels der OcéSoftware an den Plotter, welcher die Pläne dann ausgibt. Da das Plotten für Studierende nur zu bestimmten Zeiten möglich war, gab es an Tagen, an denen mehrere Abgabetermine angesetzt waren, große Anstürme von Studierenden, sodass oft Unzufriedenheit bei den Studierenden über Wartezeiten und somit verzögerte Abgaben herrschte. Zudem kam es im Plotter zu enormen Rechenzeiten, wenn dieser große pdf-Dateien verarbeiten musste. Die Studierenden reichen die Zeichnungen als plt- oder pdf-Dateien ein, welche jedoch dann von der Software des Plotter intern aufgerastert werden. Muss eine A0-Zeichnung mit vielen Elementen zudem nun auch gedreht werden, können die Umwandlung und das Drehen bis ca. 10 Minuten dauern. Bei dem tiff-Format handelt es sich ebenfalls um ein Rasterformat. 1.2. Ziel Um die Zeiten für die Studierenden zu entzerren, den Aufwand für die Mitarbeiter vom IT-Service zu verringern und um der Plottersoftware Rechenarbeit abzunehmen, ist es das Ziel ein Tool zu entwickeln, was alle diese Probleme vermeidet. Das heißt, es soll ein Werkzeug erarbeitet werden, sodass die Studierenden möglichst eigenständig ihre Zeichnungen an den Plotter senden können. Bevor die Zeichnungen aber letztendlich an den Plotter geschickt werden, sollten diese von einer Komponente der Software auf verschiedene Fehler überprüft und in tiff-Format umgewandelt werden. Das ausgemachte Ziel dieser Projektarbeit ist also eine aus drei Modulen bestehende Software. Das erste Modul wird durch ein Webinterface für die Studierenden realisiert. Dort können sie Dateien hochladen und deren Status einsehen. Bei dem zweiten Modul handelt es sich um eine tiff-Engine. Das heißt, dort werden die hochgeladenen pdf-Dateien auf verschiedene Eigenschaften geprüft, falls nötig gedreht und schlussendlich in eine tiffDatei umgewandelt. Bei dem letzten Modul, dem Ausgabe-Modul, werden die Ausgabereihenfolge bestimmt und die tiff-Dateien über eine FTP-Verbindung zum Plotter gesendet. Die Schnittstelle, mit der alle drei Module arbeiten und aus welcher sie ihre Daten beziehen, ist eine Datenbank. 4 Erstellung eines Datenübertragungsmoduls zum Projekt CW-Plot-Server 2. Grundlagen/Werkzeuge/Konzepte 2.1. Programmiersprachen/Bibliotheken/DBMS 2.1.1. Python Die Anfang der 1990er von Guido van Rossum entwickelte Programmiersprache Python wird zu den höheren Programmiersprachen gezählt, kann jedoch auch als Skriptsprache benutzt werden.1 Python berücksichtigt jeweils objektorientierte, aspektorientierte und funktionale Programmierung. Bei der Entwicklung wurde von van Rossum sehr viel Wert auf die Lesbarkeit des Programmcodes gelegt, was dadurch erkennbar wird, dass der Code in Blöcken organisiert ist, statt einer Strukturierung durch Klammern oder Schlüsselwörter.1 Python ist sehr dynamisch; es besitzt viele Interpreter für andere Programmiersprachen, sodass Module aus anderen Sprachen problemlos eingebettet werden können.2 Da Python auch als Skriptsprache eingesetzt werden kann, ist zu erkennen, wie vielseitig einsetzbar diese Sprache ist. In Python wird der geschriebene Code direkt interpretiert, und nicht zuvor kompiliert, was viel Zeit sparen kann und es möglich macht, Code zur Laufzeit zu verändern.3 Datentypen werden in Python ebenso dynamisch verwaltet; das heißt, ein Objekt definiert sich durch seine Attribute und Funktionen, und nicht durch die Zuordnung einer bestimmten Klasse. Dies nennt man „Ducktyping“. Python liefert eine sehr große Standardbibliothek, wie z.B. die von mir im Zuge dieses Projektes genutzte Bibliothek „ftplib.py“, sodass man die Möglichkeit hat, mit vielen Anwendungen zu arbeiten.1 „Das offene, gemeinschaftsbasierte Entwicklungsmodell“1 wird durch die Python Software Foundation unterstützt. So befindet sich die Programmiersprache Python momentan in der Version 3.3.0(29. September 2012). Die in diesem Projekt genutzte Version ist 2.6.6. 2.1.2. Datenbanken 2.1.2.1. Allgemein "Eine Datenbank (auch Datenbanksystem) ist ein System zur Beschreibung, Speicherung und Wiedergewinnung umfangreicher Datenmengen, die von mehreren Anwendungsprogrammen oder Anwendern benutzt werden. Es besteht aus einer Datenbasis, in der die Daten abgelegt werden und 1 de.wikipedia.org/wiki/Python_(Programmiersprache) Folien zur Vorlesung „Skriptprogrammierung“ WS 2011/2012: http://www.rz.rwthaachen.de/aw/cms/rz/Zielgruppen/rz_auszubildende/veranstaltungen/informatik/Wahlpflichtkurse/~qwj/skriptprogram mierung_php_mysql_/?lang=de 3 „Einstieg in Python“ von Thomas Theis, 3.aktualisierte Auflage, erschienen 2011 im Verlag „Galileo Computing“ 2 5 Erstellung eines Datenübertragungsmoduls zum Projekt CW-Plot-Server dem Verwaltungsprogramm (Datenbasismanagement), das die Daten entsprechend der vorgegebenen Beschreibung abspeichern, auffinden oder weitere Operationen durchführen kann."4 Wichtig dabei ist, dass eine Datenbank effizient, konsistent und dauerhaft ist und dass es möglich ist, dass mehrere Benutzer und Anwendungen gleichzeitig auf diese zugreifen können. Man versucht mit diesem System unnötige Datenredundanz zu verhindern und Daten für verschiedenste Nutzer brauchbar zu machen. Das Datenbankmanagementsystem(DBMS) besteht, wie zuvor angedeutet, aus zwei Teilen; dem Datenbankmanagementsystem und den eigentlichen Daten. Das DBMS organisiert den Zugriff auf Daten und dessen Struktur. Um die Informationen für Anwendungen und Nutzer zugänglich zu machen, ist eine Datenbanksprache festgelegt. Die standardisierte am weitesten verbreitete Sprache ist SQL5, die Structured Query Language. Mithilfe dieser Sprache lässt sich eine Datenbank sowohl einrichten, als auch manipulieren. Kennzeichnend für diese Sprache ist, dass sie der Datenbank nur angibt, welche Ergebnisse man sucht und nicht, wie die Datenbank diese finden soll. Das hier verwendete Schema ist das einer relationalen Datenbank, was bedeutet, dass die Grundlage des Konzepts die mathematische Relation ist. So kann eine Tabelle in einer Datenbank mathematisch beschrieben werden und mithilfe der relationalen Algebra manipuliert oder gelesen werden. Neben dem relationalen Konzept existieren noch die Konzepte einer hierarchischen, netzwerkartigen, objektorientierten und dokumentenartigen Datenbank, jedoch ist die relationale Datenbank bis heute trotz einiger Kritikpunkte die meist verwendete Version. 2.1.2.2. PostgreSQL/psycopg2.py PostgreSQL ist ein Datenbankmanagmentsystem, welches vor 1996 unter dem Namen POSTGRES als universitäres Projekt an der University of California at Berkeley Computer Science Department bekannt war.6 Dieses DBMS hält sich sehr an den SQL-Standard, jedoch gibt es einige PostgreSQL-spezifische Funktionalitäten. Die aktuelle Version ist 9.2.1 und von uns wird Version 8.4.9 genutzt. Ein Datenbankmanagmentsystem ist ein System, welches innerhalb einer Datenbank Redundanz und Inkonsistenz vermeidet, den Mehrbenutzerbetrieb unterstützt, Datenverlust vermeidet, und die Integrität des Systems sichert.7 Also schlussendlich ein System, dass es möglich macht, mit mehreren Benutzern die Datenbank zu manipulieren und zu lesen, ohne dass diese in ihrer Form gegen jegliche Integritätsbedingungen verstößt. PostgreSQL zählt zu den objektrelationalen DBMS, welches als Open-Source-Programm frei verfügbar ist.8 Dieses DBMS unterstützt die SQL92 und SQL99 Standards, bietet jedoch eine Reihe zusätzlicher Erweiterungen an. 4 Zitiert nach http://www2.cs.uni-paderborn.de/cs/agengels/ag_dt/Courses/Lehrveranstaltungen/WS0001/TSEII/Begleitunterlagen/Kap1.2S-SW.pdf Seite 2 5 http://www.wirtschaftslexikon24.net/d/sql/sql.htm 6 http://www.postgresql.de/index.whtml#pg 7 „Datenbanksysteme“ von A.Kemper/A.Eickler, 6. aktualisierte und erweiterte Auflage, erschienen 2006 im Verlag „Oldenburg“, S.17ff 8 Verfügbar unter http://www.postgresql.org 6 Erstellung eines Datenübertragungsmoduls zum Projekt CW-Plot-Server Basierend auf einem Client-Server-Modell verwaltet ein Prozess des Servers, der sogenannte „postmaster“, die Datenbankdateien und die Verbindungen zu verschiedenen Clients. Zusätzlich verarbeitet dieser Prozess auch die Anfragen, die von den Client-Programmen gestellt werden. Bei jeder neuen Verbindung von einem Client zum Server wird von dem Serverporzess ein neuer Prozess gestartet.9 Client und Server kommunizieren mittels TCP/IP-Verbindungen übers Netz, da Client und Server sich in den seltensten Fällen auf einem Host befinden. PostgreSQL ist in den meisten Linuxdistributionen standardmäßig enthalten; Apple enthält diese seit Version MAC OS X v10.7 als Standardbibliothek.10 Um PostgreSQL aus Python heraus benutzen zu können, verwende ich psycopg2.py; eine Bibliothek, die die Python DB API 2.0 Spezifikation vollkommen implementiert und zusätzlich Besonderheiten von PostgreSQL unterstützt.11 Mithilfe dieser Bibliothek kann man aus einem Python-Programm heraus, Datenbankabfragen starten und die Ergebnisse im Programm verwenden. 2.1.3. ftplib.py Die Klasse „ftplib.py“ ist eine Python-Bibliothek, um mittels Python eine FTP-Verbindung zu einem anderen Host herstellen zu können. FTP(File Transfer Protocol) ist ein Protokoll zur Datenübertragung und wird in Kapitel 2.2.3. genauer erläutert. Mittels dieser Python-Klasse ist es möglich, ein FTP-Objekt zu erstellen, welches eine Verbindung zum Host mit der gegebenen IP herstellt. So ist es möglich, zwischen verschiedenen Verzeichnissen auf dem Zielhost zu wechseln, Listen über Verzeichnisinhalte zu erstellen und Dateien auszutauschen. Bei dem einfachen FTPProtokoll hält sich der Umfang der Befehle in Grenzen. Codebeispiel: Abbildung 1 „sample session using the ftplib module“ 12 9 http://www.postgresql.de/index.whtml#pg http://de.wikipedia.org/wiki/PostgreSQL 11 http://www.initd.org/psycopg/ 12 http://docs.python.org/library/ftplib.html 10 7 Erstellung eines Datenübertragungsmoduls zum Projekt CW-Plot-Server Die Benutzung dieser Klasse ist sehr intuitiv, wenn man sich zuvor bereits ein wenig mit FTP beschäftigt hat, da einerseits FTP ein sehr einfaches und wenig kompliziertes Protokoll ist und zudem die Befehle in ftplib.py den „Original“-FTP-Befehlen sehr ähnlich sind. Somit ist es sehr einfach, eine FTP-Verbindung innerhalb eines Python-Skriptes aufzubauen und diese für den Datentransfer zu benutzen. 2.2. Prozesse/Protokolle 2.2.1. Daemon Daemon ist ein Unix-spezifischer Begriff, der einen Prozess beschreibt, der im Hintergrund eines Systems läuft und bestimmte Dienste zur Verfügung stellt. In Windows-Betriebssystemen nennt man solche Prozesse „services“ oder „Systemdienste“. Ein Daemon zeichnet sich dadurch aus, dass er nicht in direkte Benutzerinteraktion tritt. Die Kommunikation eines Daemon findet viel eher über bestimmte Signale, Pipes oder Sockets statt. So wird ein Daemon auch sehr selten von einem Benutzer bewusst gestartet, sondern er wird durch das Wechseln eines Runlevels in einen anderen oder beim Systemstart gestartet. Typische Daemons sind Netzwerkdienste, Druck- und Datenbankserver, Hardwareüberwachungsdaemons. Daemons erfüllen meist periodische Aufgaben, wie zum Beispiel in diesem Projekt.13 Ein Runlevel bezeichnet einen Betriebszustand eines Computers. Beim Systemstart startet das System in einem bestimmten Runlevel, d.h. je nach Runlevel werden verschiedene Systemdienste in einer festgelegten Reihenfolge gestartet. So wird der Computer stufenweise in Betrieb genommen. Auf diese Weise kann auch gewährleistet werden, dass ein Dienst, der von anderen abhängig ist, erst dann gestartet wird, wenn die Dienste gestartet wurden, von welchen er abhängig ist. Beim Herunterfahren des Computers werden die verschiedenen Dienste üblicherweise in genau umgekehrter Reihenfolge beendet, wie sie gestartet wurden.14 Ein Daemon zeichnet sich des Weiteren dadurch aus, dass er ein direkter Kindprozess des initProzesses, also des Hauptprozesses, ist. Der init-Prozess ist der Hauptprozess in unixartigen Systemen, welcher üblicherweise alle anderen Prozesse startet. Er besitzt meist die Process-ID 1. Ihn zu stoppen, bedeutet das System herunter zu fahren. Über den init-Prozess werden die verschiedenen Runlevel verwaltet. 2.2.2. mk.daemon Mk.daemon ist ein in der Skriptsprache Perl geschriebenes Programm. Es wurde ca. 2005 von Herrn Günter Ermer geschrieben, um aus einem einfachen Skript einen Daemon zu erstellen. Der Programmablauf sieht so aus, dass zunächst eine log-Datei benannt wird, in welche die Fehlermeldungen und Standardausgaben des Programms umgeleitet werden. Dies ist notwendig, 13 14 http://de.wikipedia.org/wiki/Daemon http://de.wikipedia.org/wiki/Runlevel 8 Erstellung eines Datenübertragungsmoduls zum Projekt CW-Plot-Server um Fehlermeldungen und Ausgaben überhaupt betrachten zu können, da diese weder auf einer Konsole angezeigt werden, noch sonst irgendwo auftauchen. Anschließend werden bis zu 100 Parameter, die beim Programmaufruf aufgelistet werden, eingelesen, wobei es sich bei dem ersten Parameter immer um das zu dämonisierende Programm handelt. Der zweite bis n-te Parameter sind Parameter, die für das Programm, welches als Daemon gestartet werden soll, als Übergabeparameter genutzt werden. Im Anschluss wird das Programm mk.daemon gestartet und das zu dämonisierende Programm gestartet. Forken bedeutet, dass eine identische Kopie eines Programms erzeugt wird. Dieser Kindprozess übernimmt also die Daten, den Maschinencode und den Befehlszähler des Vaterprozesses, ist aber ab diesem Zeitpunkt eigenständig und erhält eine eigene Process-ID (PID). Dieses Verhalten ist zum Beispiel sehr nützlich, wenn ein Serverprozess auf Anfragen wartet. Erhält er eine Anfrage, teilt sich der Prozess. Durch das forken, besitzt der Kindprozess die gleichen Informationen wie der Vaterprozess und kann nun die Anfrage abarbeiten, während der Vaterprozess auf weitere Anfragen warten kann.15 Ist der fork()-Aufruf erfolgreich, wird dem Vaterprozess die PID des Kindprozesses wiedergegeben und dem Kindprozess die PID 0. So sind die beiden Prozess auch zu unterscheiden. Bei einem auftretenden Fehler wird dem Vaterprozess der undefinierte Wert zurückgegeben und der Kindprozess existiert dementsprechend nicht.16 In dem vorliegenden Programm wird der fork(2)-Aufruf benutzt, was bedeutet, dass der Kindprozess nicht Kindprozess des Vaterprozesses ist, sondern ein Kindprozess des init-Prozesses. Im Programm wird über den Rückgabewert nun geprüft, ob es sich um den Prozess handelt, der geforked wurde, der der Daemon ist oder ob der Fork-Versuch fehlgeschlagen ist. Wenn aus irgendeinem Grund nicht geforked werden kann, wird 5 Sekunden später erneut ein Versuch unternommen. Im Idealfall beendet sich der Vaterprozess und nur der Daemon läuft weiter. Zusätzlich enthält das Programm noch zwei weitere Funktionen, um einen formatierten Zeitstempel mit dem Fehler in lesbarer Form zu generieren. 15 http://openbook.galileocomputing.de/unix_guru/node389.html „Programmieren mit Pearl“ von Larry Wall, Tom Christiansen und Randal L. Schwartz, 1. Auflage erschienen 1997 im O’Reilly Verlag 16 9 Erstellung eines Datenübertragungsmoduls zum Projekt CW-Plot-Server 2.2.3. File Transfer Protocol Das File Transfer Protocol ist ein recht altes und einfaches Protokoll der Anwendungsschicht nach dem ISO/OSI-Referenzmodell. Abbildung 2 „ISO/OSI-Referenzmodell“ 17 Das ISO/OSI-Referenzmodell ist ein sehr bedeutendes Modell zur Entwicklung der Struktur des Internets. Jedoch ist es nie zu einer sinnvollen Implementierung dieses Modells gekommen, da durch die vielen Schichten zu viel Overhead für jede einzelne Schicht entstehen würde. Die Idee hinter diesem Modell jedoch ist in den heutigen Strukturen des Internets deutlich zu erkennen. Diese ist es, verschiedene Aufgaben in Schichten aufzuteilen, sodass sie von unterschiedlichen Protokollen erledigt werden können. Nur die Schnittstellen sind wohldefiniert; die konkrete Implementation einer Aufgabe jedoch kann auf unterschiedliche Wege gelöst werden. Die einzige Bedingung ist, dass die Schnittstellen zu der Schicht darüber und derjenigen darunter passen müssen. So erhält man ein flexibles Gesamtmodell. 17 http://www.windows-netzwerk-hilfe.de/netzwerk-grundlagen/osi-referenzmodell.html 10 Erstellung eines Datenübertragungsmoduls zum Projekt CW-Plot-Server Um das Prinzip, welches hinter diesem Modell steckt, nochmals zu verdeutlichen, kann die folgende Abbildung heran gezogen werden: Abbildung 3 „Gedankenaustausch von Philosophen“ 18 Die Abbildung stellt dar, wie zwei Philosophen ihre Gedanken zur Weltpolitik austauschen. Dabei sprechen sie nicht die gleiche Sprache und befinden sich an unterschiedlichen Orten. Deshalb müssen sie Dolmetscher benutzen und ihr Gespräch auf irgendeine Weise übertragen lassen. Diese Dolmetscher können die jeweilige Sprache des Philosophen verstehen und zusätzlich die englische Sprache, haben aber kein Verständnis von den Dingen, worüber die Philosophen reden. Ähnlich verhält es sich mit den Technikern, die die Kommunikation übertragen sollen. Sie verstehen vielleicht noch nicht einmal die Sprache, die sie übertragen, wissen aber trotzdem wie sie einzelne Zeichen kodieren müssen. Die Schnittstellen zwischen den Personen sind damit wohldefiniert und die Gedanken des einen Philosophen kommen bei dem anderen an. Jeder dieser Personen in der Kommunikationskette erfüllt eine bestimmte Aufgabe, ohne dass er Kenntnis vom Gesamtbild oder dem Inhalt der Kommunikation hat. Protokolle der Anwendungsschicht müssen immer die Eigenschaften erfüllen, Typen der verschickten Nachrichten, Syntax der Nachrichtentypen und die Semantik der Nachrichtentypen zu definieren. In dem heute gebräuchlichen TCP/IP-Referenzmodell, welches die sieben Schichten des ISO/OSI-Referenzmodells zu vieren zusammenfasst, besitzen Anwendungsprotokolle zudem 18 Vorlesung Rechnernetze SS12 http://www.comsys.rwth-aachen.de/teaching/rechnernetze-fuer-matse/ 11 Erstellung eines Datenübertragungsmoduls zum Projekt CW-Plot-Server noch Eigenschaften der Sitzungsschicht. Dies bedeutet, dass in diesen Protokollen auch festgelegt wird, wann und wer senden darf, sodass eindeutige Dialoge festgelegt sind. Das File Transfer Protocol wurde bereits 1985 im RFC95919 spezifiziert und ist zur Übertragung von Daten und Auflistung von Verzeichnisinhalten in IP-Netzwerken gedacht. Es benutzt die TCPPorts 20 und 21, wobei es sich bei dem einem um den DATA Port und bei letzterem um den Control Port handelt.20 Anhand der Benutzung zweier Ports kann man gut erkennen, dass Kommunikation und wirkliche Datenübertragung getrennt werden und sozusagen im Grunde zwei Verbindungen bestehen, wenn ein Client und ein Server eine FTP-Verbindung aufbauen. Die Kommunikation läuft standardmäßig so ab, dass der Client eine Anfrage stellt und der Server mit einem Statuscode21 und einem dazugehörigen Text antwortet. Je nach Konfiguration des Servers sind manche Befehle erst nach einer erfolgreichen Authentifizierung des Clients möglich. Man unterscheidet zwischen passivem und aktivem FTP, die sich darin unterscheiden, dass im aktiven Modus der Client den Datenport wählt und diesen dem Server mitsamt seiner IP-Adresse mitteilt, und im passivem Modus, der Server den Port wählt und diesen an den Client schickt, ebenfalls mit seiner IP-Adresse. Der übliche Weg ist der, aktives FTP zu nutzen, jedoch ist passives FTP nötig, wenn ein Client für den Server scheinbar nicht zu erreichen ist( z.B. durch NAT-Gateway oder Firewall).19 Um FTP-Verbindungen nutzen zu können, befindet sich auf fast jedem Betriebssystem standardmäßig ein ftp-Terminal-Client. So ist es möglich über die Kommandozeile eine Verbindung zu einem FTP-Server aufzubauen und sich mit diesem auszutauschen.22 Außerdem besitzen die meisten aktuellen Browser ebenfalls einen FTP-Client, sodass ein Server über die Adresszeile des Browsers angesteuert werden kann. Des Weiteren gibt es unzählige Softwareprodukte von unterschiedlichen Herstellern mit denen es möglich ist FTP-Verbindungen zu Servern aufzubauen, die zudem auch eine grafische Oberfläche besitzen. Die Mehrheit der heutigen FTP-Server ist öffentlich zugänglich, sodass es möglich ist, sich mit dem sogenannten „anonymous“-User anzumelden. Dabei kann ein leeres oder beliebiges Passwort gewählt werden. Heute gibt es viele weitere Varianten von FTP(z.B. SFTP, TFTP, BFTP,…), da FTP ein sehr einfaches und altes Protokoll ist, trotzdem aber gut zur simplen Dateiübertragung geeignet ist. 19 RFC959 http://tools.ietf.org/html/rfc959 http://de.wikipedia.org/wiki/File_Transfer_Protocol 21 Auflistung aller Statuscodes http://www.iana.org/assignments/http-status-codes/http-status-codes.xml 22 Liste von Befehlen: http://www.cs.colostate.edu/helpdocs/ftp.html 20 12 Erstellung eines Datenübertragungsmoduls zum Projekt CW-Plot-Server 2.3. Modularisierung 2.3.1. Allgemein Der Begriff der Modularisierung steht im Gegensatz zu einem vollkommenen Gesamtsystem. In der Softwareentwicklung wird Modularisierung genutzt, um ein System flexibler und anpassbarer zu machen. Es werden Bausteine gebildet, die beliebig kombiniert werden können. Jeder Baustein ist austauschbar und erfüllt eine Teilaufgabe der Problemstellung.23 Nur die Schnittstellen zwischen Bausteinen müssen wohldefiniert sein; die Umsetzung einer Aufgabe in einem Modul ist unabhängig von den anderen Modulen und kann beliebig geändert werden, ohne Einfluss auf die anderen Bausteine zu nehmen. Bei einer modularisierten Software ist die Arbeitsaufteilung auch einfacher umzusetzen, da nicht mehrere Entwickler gleichzeitig an einem Modul arbeiten, sondern kleinere Gruppen oder Einzelpersonen an je einem Modul arbeiten können. 2.3.2. Webinterface Das Webinterface ist das Eingabemodul. Über den Browser können die Benutzer dieses aufrufen, sich über ihre FH-Kennung anmelden und dort ihre zu plottenden Dateien hochladen und deren Status abrufen. Die Anmelde-Daten werden über einen LDAP-Server abgefragt. Bei den Benutzern handelt es sich hauptsächlich um die Studierenden der Fachbereiche Bauingenieurwesen und Architektur der FH-Aachen und eventuell um einige Mitarbeiter dieser Fachbereiche, da die Kosten des Plotters durch eine Einrichtung dieser beiden Fachbereiche finanziert wird.24 Über das Eingabemodul werden die hochgeladenen Dateien auf einem Server gespeichert und wichtige Informationen über diese, zum Beispiel von wem und wann eine Datei hochgeladen wurde, in eine Datenbank eingespeist. Hier findet auch die Vergabe von JobIDs statt, die einen entscheidenden Teil zur Abarbeitungsreihenfolge der Plots beiträgt. Die Endbenutzer können nach dem Hochladen einsehen, inwieweit die Bearbeitung der Datei fortgeschritten ist. So wird angezeigt, wann die Datei hochgeladen wurde, ob die Bearbeitung durch die tiff-Engine abgeschlossen ist und wann die Datei zum Plotter gesendet wurde. Treten Fehler in der Bearbeitung der Datei auf, werden auch diese dem Benutzer auf dieser Statusseite angezeigt, sodass dieser die Möglichkeit hat, bei Komplikationen den IT-Service rechtzeitig zu kontaktieren und den Fehler zu beheben, sodass der Plot im erwarteten Zeitfenster fertig gestellt wird. Es werden nur noch pdf-Dateien im Eingabemodul akzeptiert. Wenn ein Benutzer eine Datei mit einer anderen Endung oder mit der falschen Papiergröße hochzuladen versucht, wird diese nicht akzeptiert und der Benutzer darauf hingewiesen. Die Seite ist vorerst nur aus dem FH-Netz zu erreichen.25 23 http://wirtschaftslexikon.gabler.de/Definition/modularisierung.html http://www.sw-bh.fh-aachen.de/ 25 http://www.plotservice.fh-aachen.de 24 13 Erstellung eines Datenübertragungsmoduls zum Projekt CW-Plot-Server Zudem gibt es eine erste Administrationsoberfläche, die aber nicht als eigenes Modul fungiert, sondern noch Teil der Weboberfläche für die Nutzer ist. Dabei handelt es sich um eine erste Lösung, um Dateien und ihre Status betrachten zu können und gegebenenfalls die Warteschlange anhalten zu können.26 2.3.3. pdf2tiff Die sogenannte tiff-Engine bereitet die hochgeladenen Dateien auf, sodass diese für den Plotter schneller und einfacher ab zu arbeiten sind und führt Prüfungen durch, wie zum Beispiel, ob es sich um das richtige Dateiformat handelt. Zunächst wird die Datei mittels eines pdf-Readers geöffnet. Tritt dabei ein Fehler auf, so handelt es sich zum Beispiel nicht um eine richtige pdf-Datei. Es wird die Anzahl der Seiten ausgelesen, anschließend die Papiergröße bestimmt. Für die späteren Berechnungen wird die Größe von Punkten in Millimeter umgerechnet. Da nur bestimmte DIN-Größen von dem System akzeptiert werden, wird mit einer Toleranz von 10 mm(variabel einstellbar in der Datenbank) geprüft, ob es sich um eine gültige Größe handelt. Zu guter Letzt wird die pdf-Datei in eine tiff-Datei umgewandelt. Das heißt, dass eine neue tiff-Datei entsteht und die Originaldatei erhalten bleibt. Diese tiff-Datei ist diejenige, die im nächsten Modul zum Plotter geschickt wird. In den letzten Schritten wird die tiff-Datei noch bei Bedarf auf die passende Rollenbreite des Plotters gedreht und in der Datenbank als vom Umwandlungsmodul bearbeitet gekennzeichnet. Die tiff-Engine fragt die Informationen, die sie zur Verarbeitung der Dateien braucht, aus der Datenbank ab. Die Dateien werden in der Reihenfolge in der tiff-Engine verarbeitet, wie sie hochgeladen wurden. Die Information, ob eine Datei bearbeitet wurde und ob Fehler bei der Verarbeitung aufgetreten sind, wird ebenfalls wieder in der Datenbank gespeichert. 2.3.4. send2plotter Dieses Modul ist das Datenausgabemodul der gesamten Konstruktion. Hier werden die ungeplotteten, fehlerfrei bearbeiteten Dateien in einer Reihenfolge, die mehreren Regeln folgt, an den Plotter ausgegeben. Auch hier ist die Schnittstelle zu den anderen Modulen wieder die Datenbank. Anhand der Informationen in dieser, kann dieses Modul entscheiden, welche Dateien an den Plotter gesendet werden und welche nicht. Ebenso gibt es Regelungen, um den Plotter nicht mit Dateien zu überfluten, sondern kontrolliert Daten an den Plotter zu senden. Wurde eine Datei erfolgreich über die FTP-Verbindung dieses Moduls zum Plotter versendet, wird diese Information in der Datenbank gespeichert. Diese Information wird dem Benutzer im Webinterface dargestellt, sodass er weiß, wann er sich zum Plotter begeben kann, um seinen fertigen Plot entgegen zu nehmen. 26 http://www.plotservice.fh-aachen.de/cw-plot/hdjkfhdjkgfv894z48bhjsdh78fd 14 Erstellung eines Datenübertragungsmoduls zum Projekt CW-Plot-Server 3. Modul send2plotter 3.1. FTP-Verbindung/Schnittstelle zum Plotter Der Plotter Océ ColorWave 600 hat standardmäßig einen FTP-Server implementiert. Zudem handelt es sich dabei, um einen öffentlichen FTP-Anschluss. Dies bedeutet, dass es einfach ist, eine Verbindung zum Datenaustausch zum Plotter aufzubauen, da man den sogenannten Benutzer „anonymous“ benutzen kann. Dabei braucht man beim Login keinen Benutzernamen und kein bzw. ein beliebiges Passwort anzugeben, besitzt aber die Berechtigung, diesem Server Daten zu senden und Daten von diesem abzurufen. Die Information, dass es möglich ist, den Plotter über eine FTP-Verbindung anzusprechen, habe ich in einem Online-Handbuch von Océ für mehrere Reihen von Plottern gefunden.27 Dort war genau beschrieben, wie man über eine Konsole eine Verbindung zum Plotter aufbaut. Da jedoch die gesamte Software mit der Programmiersprache Python realisiert wurde, musste diese Logik noch in Python übertragen werden. Zudem besitzt der Plotter Océ ColorWave 600 eine weitere Schnittstelle. Die sogenannte LPD/LPR-Schnittstelle ist jedoch nicht gut geeignet für die vorliegende Problemstellung, da es über diese Schnittstelle nicht möglich ist, eine gewisse Staukontrolle zu realisieren.27 Zudem wäre hierfür in Python eine nicht in der Standardbibliothek enthaltene Bibliothek nötig gewesen. 3.2. Schnittstelle Datenbank Da die Datenbank eine zentrale Rolle in der entwickelten Software und für die Kommunikation zwischen den Modulen spielt, sind die Tabellen der Datenbank anschließend im Einzelnen aufgeführt. config maxsize tolerancesize numeric integer maxemptyspace integer currentjobid plotqueuestopped integer boolean 27 maximale Größe einer Datei Toleranz für die DIN-Größe des pdfs in mm max. Leerfläche, die ein Dokument beinhalten darf( in %) fortlaufende JobID true: der Plotter erhält keine Aufträge vom Ausgabemodul; http://okb.oceusa.com/English_ext/WFPS/SysAd_Arc/cw_pw_tcs_tds/ConM_cwpctcstds_2012_03/M088395.html 15 Erstellung eines Datenübertragungsmoduls zum Projekt CW-Plot-Server plotteravailable boolean maxplotsinqueue integer timeout integer maxplottries integer totalplots integer false: der Plotter erhält Aufträge vom Ausgabemodul false: Ausgabemodul stellt fest, dass der Plotter nicht erreichbar ist(z.B. Plotter ausgeschaltet) max. Anzahl an Plots, die in der Warteschlange des Plotter zugelassen sind Zeit, zwischen upload und Absenden zum Plotter(in Sekunden) max. Anzahl an Versuchen, einen Plot erfolglos zum Plotter zu senden Gesamtanzahl der Plots Abbildung 4 „Tabelle config“ Die Tabelle config enthält Konfigurationseinstellungen, die für den Ablauf wichtig sind. Über das Flag „plotqueuestopped“ kann zum Beispiel die Ausgabe an den Plotter angehalten werden und über „totalplots“ wird die Gesamtanzahl aller hochgeladenen Dateien mitgezählt. In dieser Tabelle gibt es nur einen Datensatz, da es sinnlos wäre, mehrere zu erstellen, da sonst so mehrere Informationen darüber vorhanden sein könnten, ob der Plotter erreichbar ist oder nicht. Bei widersprüchlichen Informationen, wäre keine Aussage mehr möglich. Auch manche Einstellungen, die die Module im Programmablauf benutzen, dürfen nicht mehrmals vorkommen, da sie so uneindeutig werden. file name fileid PRIMARY KEY text text path loginname FOREIGN KEY text text statusmessage filelocktiff errorlocktiff text boolean boolean donetiff boolean jobid integer Originalname der Datei geänderter Name der Datei/ID der Datei Dateipfad Name des Users, der die Datei hochgeladen hat Statusnachricht einer Datei Dateisperre für die tiff-Engine true: tiff-Engine hat bei der Verarbeitung einen Fehler festgestellt true: pdf2tiff hat die Bearbeitung abgeschlossen Plots eines Studierenden, die 16 Erstellung eines Datenübertragungsmoduls zum Projekt CW-Plot-Server upload double precision doneplotmodule double precision errorplot integer gsmessage text gleichzeitig an den Plotter geschickt werden, besitzen die gleiche JobID Zeitangabe(in Sekunden seit 1.1.1970) des Datei-Uploads Zeitangabe(in Sekunden seit 1.1.1970) des Versendens an den Plotter Wert x: Datei konnte x mal nicht an den Plotter gesendet werden Ghostscript Ausgabe des pdf2tiff Prozesses Abbildung 5 „Tabelle file“ Die Tabelle „file“ beinhaltet Informationen über die einzelnen Dateien, die von den Usern hochgeladen wurden. Das heißt, diese Tabelle enthält immer so viele Datensätze, wie Dateien hochgeladen wurden. Es werden die verschiedensten Informationen über die Datei gespeichert. Einerseits existieren statische Informationen, wie zum Beispiel der Originalname, der technische Name oder der User, der die Datei hochgeladen hat. Andererseits gibt es aber auch Einträge, die für die Bearbeitung durch die Module sehr wichtig sind und im Laufe der Abarbeitung verändert werden. Das Eingabemodul erstellt den Datenbankeintrag in dieser Tabelle, deshalb ist durch das Vorhanden sein des Eintrags klar, dass das Eingabemodul mit dieser Datei abgeschlossen hat. Zudem wird durch das Eingabemodul die Zeit des Uploads gespeichert. Das Modul pdf2tiff wiederum setzt das Flag „donetiff“ um zu signalisieren, dass es eine Datei bearbeitet hat - ob erfolgreich oder nicht ist an dem Flag „errorlocktiff“ zu erkennen. So kann das nächste Modul, also das Ausgabemodul, anhand dieser Flags feststellen, ob es eine Datei ausgeben darf oder nicht. So wird verhindert, dass auf eine Datei von zwei Modulen zeitgleich zu gegriffen wird und somit Fehler auftreten. users loginname PRIMARY KEY countplots maxplots text integer double precision locked boolean faculty integer status matrnr text text Name des Users zählt Plots pro User zur Verfügung stehende Ploteinheiten in A0 true: User ist fürs Plotten gesperrt Fachbereichsnummer des Users s:student;e:employee;a:admin Matrikelnummer, falls vorhanden 17 Erstellung eines Datenübertragungsmoduls zum Projekt CW-Plot-Server Abbildung 6 „Tabelle users“ Die Tabelle “users” hält Informationen über die Benutzer des Systems bereit. So steht in dieser Tabelle wie ein User heißt, ob er gesperrt ist, wie viele Dateien er schon hochgeladen hat oder wie viele A0-Einheiten ihm noch zur Verfügung stehen. Einige dieser Daten sind auch wichtig zur Findung des technischen Namens einer Datei, da darin die Matrikelnummer des Users, der Fachbereich und die laufende Nummer jedes Users eine Rolle spielen. Dieser wird für die Abrechnung der Kosten für die einzelnen Fachbereiche benötigt. Über diese Tabelle können Nutzer auch gesperrt werden. So sind zum Beispiel alle User aus anderen Fachbereichen als 1 und 2 für das Plotten gesperrt. Auch kann bei Missbrauch eine Sperre für einen Benutzer gesetzt werden. Anhand dieses Aufbaus erkennt man bereits, was für eine wichtige Rolle die Datenbank in der Verarbeitung der Dateien spielt. Sie dient nicht nur als Datenverwaltungssystem, sondern nimmt durch die Modularisierung eine ganz besondere Rolle ein; sie ist die Schnittstelle zwischen allen Modulen und macht die Modularisierung in dem Sinne erst möglich, da für diese wohldefinierte Schnittstellen existieren müssen, welches hier die Datenbank ist. Zwischen den einzelnen Modulen besteht keine direkte Verbindung, sodass bei Ausfall eines Moduls, die anderen nicht beeinträchtigt werden. Wird eine Datei von der tiff-Engine nicht bearbeitet, weil diese ausgefallen ist, stellt dies kein Problem für die anderen Module dar, da das Ausgabemodul nicht von der tiffEngine aufgerufen wird, sondern über die Datenbank erfragt, welche Dateien zur Ausgabe bereit sind. Durch das Entwickeln von einzelnen Modulen wird die gesamte Software flexibler und die einzelnen Module sind einfach austauschbar, da sie nicht voneinander abhängig sind. So kann zum Beispiel jedes Modul einzeln abgeschaltet werden, ohne die Funktionalität der anderen Module zu beeinflussen. Ebenso können einfach neue Module entwickelt und dazu geschaltet werden, ohne dass alle Module dafür in einer neuen Version erscheinen oder angehalten werden müssen. Um die Leistungsfähigkeit zu steigern könnte man auch problemlos die Module „pdf2tiff“ und/oder „send2plotter“ doppeln, um Skalierbarkeit zu erreichen. Man kann die Datenbank sozusagen als Dreh- und Angelpunkt des Konzepts bezeichnen, da alle Informationen über sie gespeichert und auch über sie kommuniziert werden. 3.3. Algorithmen 3.3.1. Vergabe von Jobtickets Die Jobtickets werden zwar im Eingabemodul erstellt, sind aber entscheidend für die Ausgabereihenfolge der Dateien, deshalb werden sie hier auch erwähnt, erklärt und ihre Bedeutung für die Ausgabe deutlich gemacht. Jeder Datei wird ein Jobticket zugewiesen. Dabei können mehrere Dateien dasselbe Jobticket besitzen. In der Tabelle „config“ wird nachgehalten, welche Nummer das nächste Jobticket ist. Lädt nun ein Benutzer Dateien hoch, erscheint nach jeder hochgeladenen Datei ein Timer. Lädt der Benutzer innerhalb der Zeit des Timers noch eine weitere Datei hoch, erhält diese Datei die 18 Erstellung eines Datenübertragungsmoduls zum Projekt CW-Plot-Server gleiche JobID wie die vorherige Datei. Der zeitliche Abstand zwischen zwei Hochladevorgängen darf nicht größer als der Timer sein, damit die beiden Dateien die gleiche JobID erhalten und somit zusammen ausgegeben werden. In dem Ausgabemodul werden Dateien ihrer JobID nach ausgegeben. Existiert nun ein Job, in dem sich zum Beispiel fünf Dateien befinden, und zwei davon sind noch nicht komplett von der tiffEngine bearbeitet worden, dann wird keine von den fünf Dateien ausgegeben, da sie nur zusammen ausgegeben werden sollen. Sind alle Dateien eines Jobs von der tiff-Engine bearbeitet worden, und eine Datei ist fehlerhaft, werden die anderen vier ausgegeben, da sonst dieser Job nicht ausgegeben werden würde, nur weil eine einzige Datei fehlerhaft ist. Jobtickets erfüllen keinen technischen Zweck und sind im Grunde nicht notwendig. Bei ihrer Verwendung geht es nur darum, den Benutzern, also hauptsächlich Studierende, den Ablauf nachvollziehbar zu machen und ihnen die Nutzung der Software möglichst angenehm zu machen. Würden keine Jobtickets verwendet werden, würden die Plots von Studierenden, die in überschneidenden Zeitfenstern Dateien hoch geladen wurden, zeitlich geordnet ausgegeben werden. Dies bedeutet für den einzelnen im schlimmsten Fall, das zwischen seinen Dateien, viele Dateien anderer Benutzer geplottet werden und der Student somit nicht nur die Zeit am Plotter steht, die seine Dateien zur Ausgabe benötigen, sondern auch die Zeit, die benötigt wird, um die Dateien anderer auszugeben. Dies bedeutet zusätzlichen Stress für den Studierenden, da für ihn nicht absehbar ist, wann seine Plots fertig sind, selbst wenn einige schon geplottet wurden. Dieser kann nicht nachvollziehen, wann die nächste Zeichnung fertig ist. Um Unzufriedenheit bei den Benutzern zu vermeiden, benutzen wir die Jobtickets. 3.3.2. Ausgabereihenfolge Die Ausgabereihenfolge der Dateien wird von mehreren Faktoren beeinflusst, welche hier nun erklärt werden. Zunächst werden aus der Datenbank die Informationen „fileid“, „path“ und „jobid“ der Dateien geholt, die das Flag „donetiff“ als „true“ gesetzt haben - also die schon von der tiff-Engine bearbeitet wurden - und deren JobID komplett erledigt ist. Das heißt, es werden nicht die Daten von Dateien bezogen, die eine JobID besitzen, welche weitere Dateien besitzen, die aber nicht vollends oder gar nicht von der tiff-Engine bearbeitet wurden. Wenn eine Datei nach der Bearbeitung fehlerhaft ist, wird die zugehörige JobID nicht geblockt, sondern alle fehlerfrei bearbeiteten Dateien werden ausgegeben. So wird garantiert, dass Dateien eines Jobs auch zusammen ausgegeben werden. Aus dieser Liste von Dateien, welche nach den JobIDs in absteigender Reihenfolge und innerhalb dessen nach jüngster Uploadzeit sortiert sind, wird nun der erste Treffer gesucht. Dies bedeutet, dass die erste Datei eines Jobs daraufhin geprüft wird, ob der in der Datenbank vorgegebene Timer bereits abgelaufen ist. Dies wird geprüft, indem die aktuelle Zeit mit der Hochladezeit verglichen wird. 19 Erstellung eines Datenübertragungsmoduls zum Projekt CW-Plot-Server Liegt die Datei außerhalb der eingestellten Zeit, wird eine neue Abfrage an die Datenbank gestartet mit dem Hintergrund, alle die Dateien aus der Datenbank zu holen, die die gleiche JobID haben wie der Treffer. Dabei werden nur fehlerfrei bearbeitete Dateien zugelassen. Diese werden nun der „fileid“ nach sortiert. Dabei handelt es sich um den technischen Namen, sodass die Sortierung nach Namen einer Sortierung nach Papiergröße gleich kommt. Aus der neuen Liste wird nun die Datei zum Plotter gesendet, wenn sie nicht bereits mehrmals erfolglos zum Plotter gesendet wurde. Wurde die Datei erfolgreich mittels der FTP-Verbindung an den Plotter gesendet, wird in der Datenbank das Flag „doneplotmodule“ mit einem Zeitstempel versehen. Misslingt die Übertragung wird „errorplot“ um eins erhöht. In der Tabelle „config“ ist festgelegt, wie hoch dieser Wert maximal sein darf. Ob das Senden der Datei nun misslingt oder glückt, ist unabhängig davon, dass ein Programmdurchlauf damit beendet ist. Das Programm ist so aufgebaut, dass immer nur höchstens eine Datei in einem Durchgang abgeschickt wird, damit keine endlosen Schleifen entstehen. Die Logik des Programms garantiert aber, dass die Ausgabereihenfolge durch einen erneuten Durchlauf nicht verändert wird. Die Vermeidung von Schleifen liegt darin begründet, dass das Programm als Daemon ausgeführt werden soll. Die Programmstruktur sollte möglichst linear sein, um das System nicht zu überlasten, da der Daemon endlos laufen soll. So wird zum Beispiel am Ende des Programms auch ein zehn-sekündiger Sleep-Befehl aufgerufen, um das System nicht mit einem Daemon zu belasten, der in einer Endlosschleife hängt. Für die Ausgabereihenfolge sind also entscheidend die Hochladezeit, die Bearbeitung durch die tiff-Engine und die JobID. Diese drei Komponenten entscheiden darüber, wann und ob eine Datei an den Plotter gesendet wird. 3.3.3. Warteschlangen Um den Plotter nicht zu überlasten, muss auch eine gewisse Kontrolle über die Warteschlangen im Plotter bestehen. Um den Plotter als Administrator anhalten zu können, falls händisch Dateien eingeschleust werden sollen oder die Ausgabe an den Plotter aus einem anderen Grund gestoppt werden soll, gibt es ein Flag in der Datenbank mit dem Namen „plotqueuestopped“. Ist dieses auf „true“ gesetzt, springt das Programm direkt zum Ende und macht gar nichts. Dieser Wert wird jedes Mal zu Anfang der Programm-Routine abgefragt. Der Wert kann mittels einer einfachen Oberfläche durch einen Administrator verändert werden.28 Zudem prüft das Ausgabemodul vor jeder Übertragung an den Plotter, wie viele Dateien sich in dem Ordner, in welches dieses die Daten überträgt, befinden. Sind es mehr als ein bestimmter Wert, welcher in der Datenbank in der „config“-Tabelle festgelegt wird, so wird an den Plotter keine neue Datei übertragen. Dies hat den Vorteil, dass, falls der Plotter einmal ausfallen sollte, nur die angegebene Anzahl an Dateien verloren geht und nicht zum Beispiel zwanzig Dateien auf einmal. 28 http://149.201.63.98/cw-plot/hdjkfhdjkgfv894z48bhjsdh78fd 20 Erstellung eines Datenübertragungsmoduls zum Projekt CW-Plot-Server Das System und die Datenbank haben nur Kontrolle über das Senden an den Plotter. Was dieser damit tut und ob er diese wirklich ausgibt, kann von der von uns entwickelten Software nicht nachvollzogen werden. Deshalb liegt momentan die Anzahl der Dateien, die sich in der Warteschlange des Plotters befinden dürfen, bei drei Stück. 21 Erstellung eines Datenübertragungsmoduls zum Projekt CW-Plot-Server 3.4. Übersicht Programmablauf Abbildung 7 „Programmablauf send2plotterdaemon.py“ 22 Erstellung eines Datenübertragungsmoduls zum Projekt CW-Plot-Server 4. Fazit Bei der Entwicklung einer solchen modularisierten Software ist es wichtig, sich zuvor über die gemeinsame Schnittstelle(hier: Datenbank) einig zu werden und möglichst genau zu definieren. Zwar gibt es in der Entwicklungsphase natürlich Änderungen, das entscheidende dabei jedoch ist, dies mit den Kollegen abzusprechen und im Hinterkopf zu behalten, wie sich solche Änderungen auf andere Teile der Software auswirken können. Bei dieser Arbeit habe ich zudem gelernt, wie wichtig es ist, die Kunden und Endbenutzer möglichst gut zu kennen und einschätzen zu können, um ein Produkt zu entwickeln, was auch einen guten Eindruck auf die Endbenutzer macht. Viele Aspekte, die innerhalb dieses Projektes berücksichtigt wurden, bezogen sich ausschließlich darauf, wie man den Studierenden, den Umgang mit dem Plotservice möglichst einfach und komfortabel gestalten kann. Das Modul send2plotter erfüllt grundlegend alle zu Beginn gestellten Anforderungen; die Dateien werden in einer bestimmten Reihenfolge an den Plotter gesendet, der Plotter erhält dabei nie mehr als eine bestimmte Anzahl Dateien, die Warteschlange ist abschaltbar. Auch die gewählten Werkzeuge erfüllen ihren grundlegenden Zweck; die Verbindung zur und die Manipulation der Datenbank funktionieren einwandfrei, lediglich die Übertragungsrate befindet sich noch nicht im gewünschten Bereich. Hier muss noch Ursachenforschung betrieben werden. 5. Ausblick Da die wie im Vorherigen beschriebene Version bereits im Einsatz ist und für die Benutzer schon zur Verfügung steht, werden weitere Entwicklungen, Verbesserungen und Fehlerbehebungen erst in der nächsten Version erscheinen. Dazu gehört eine Verbesserung der Jobticketvergabe. Das heißt, dass ein Benutzer Dateien zunächst hoch lädt, diese von der tiff-Engine bearbeitet werden und der Benutzer dann die Möglichkeit hat, selber aus zu wählen, welche Dateien zusammen abgeschickt werden und somit eine JobID erhalten. So wird vermieden, dass Dateien ausgegeben werden, die ein Student nur auf Richtigkeit prüfen will, aber noch nicht plotten lassen möchte. Außerdem ist es geplant, Océ Job Tickets zu nutzen. Das Clienttool des Herstellers arbeitet auch mit sogenannten Job Tickets, die hier aber eine andere Bedeutung haben als die von uns verwendeten Jobtickets. Diese Job Tickets sind Konfigurationseinstellungen für den Plotter. Über sie kann zum Beispiel eine bestimmte Rolle des Plotters angesprochen, die Qualität eingestellt und eine Anzahl der Ausgabeplots definiert werden.29 Auf diese Weise kann ein Benutzer einstellen, in welcher Qualität und wie oft eine Datei ausgegeben werden soll. Intern soll geregelt werden, auf welche Rolle eine Datei ausgegeben wird, damit keine unnötigen und zeitaufwändigen Rollenwechsel stattfinden. Momentan werden beim Versenden an den Plotter 29 http://www.oceusa.com/main/view_media.jsp?CONTENT%3C%3Ecnt_id=10134198673382561&FOLDER%3C%3E folder_id=9852723696638963&bmUID=1255064863110 23 Erstellung eines Datenübertragungsmoduls zum Projekt CW-Plot-Server keine Konfigurations-Einstellungen mitgeschickt, sodass dieser seine Default-Einstellungen verwendet. Des Weiteren gibt es im Modul send2plotter noch das Problem, dass zwar Fehler des Hauptprogramms wie gewünscht mit Zeitstempel versehen in der Log-Datei aufgeführt sind, Fehler des Datenbankhandlers jedoch unformatiert in die Log-Datei geschrieben werden. Dies sollte zum einfacheren Debugging noch behoben werden. Dann sollte es noch für den Administrator die Möglichkeit geben, zu sehen, wann die Übertragung einer Datei zum Plotter gestartet ist. In der jetzigen Version ist nur sichtbar, wann die Übertragung erfolgreich abgeschlossen wurde. Kann eine Datei nicht gänzlich zum Plotter übertragen werden, ist für den Administrator nur sichtbar, wie oft dies versucht wurde, aber nicht wann. Außerdem ist nicht erkennbar, wie lange die Übertragung einer Datei dauert. Bei der momentanen Administrationsoberfläche handelt es sich noch nicht um ein eigenes Modul. Zusätzlich sind weitere Module in Planung. Dazu gehört ein Modul, welches bereits verarbeitete und ausgegebene Dateien aus der Datenbank und aus dem Cache löscht, wenn sie eine bestimmte Zeit nicht mehr verwendet wurden. Des Weiteren sind zwei Administrations-Module in Planung. Eines ist nötig, um User und Jobs des Systems zu verwalten. Es muss möglich sein, Dateien und Jobs während der Laufzeit zu löschen, User, die Missbrauch mit dem Service betreiben, zu sperren, A0-Einheiten zu verändern und bestimmte Jobs und Dateien betrachten zu können. Das zweite Administrations-Modul bezieht sich mehr auf das Starten und Stoppen der einzelnen Module, um zum Beispiel neue Versionen oder ähnliches einspielen zu können. Dann müssen die für die Studierenden verfügbaren A0-Einheiten in regelmäßigen Abständen wieder hoch gesetzt werden durch ein eigenständiges Modul. Im Zuge dessen kam die Überlegung auf, zum gleichen Zeitpunkt, ungenutzte User-Accounts ebenfalls zu löschen. Es steht fest, dass es sich hier um eine Software handelt, die noch sehr lange Arbeit liefern wird, weil oft erst während der Nutzung neue Bedürfnisse und Ziele entstehen. 24 Erstellung eines Datenübertragungsmoduls zum Projekt CW-Plot-Server 6. Eidesstattliche Erklärung Hiermit versichere ich, dass ich die Seminararbeit mit dem Thema „Erstellung eines Datenübertragungsmoduls zum Projekt CW-Plot-Service“ selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe, alle Ausführungen, die anderen Schriften wörtlich oder sinngemäß entnommen wurden, kenntlich gemacht sind und die Arbeit in gleicher oder ähnlicher Fassung noch nicht Bestandteil einer Studien- und Prüfungsleistung war. Name: Katinka Roosen Aachen, den 08.11.2012 _______________________________________________ Unterschrift der Studentin/ des Studenten 25 Erstellung eines Datenübertragungsmoduls zum Projekt CW-Plot-Server 7. Quellenverzeichnis RFC765: File Transfer Protocol. (Oktober 1985). Abgerufen am 13. Oktober 2012 von http://tools.ietf.org/html/rfc959 Galileo Computing: Prozesse. (2003). Abgerufen am 2. Oktober 2012 von http://openbook.galileocomputing.de/unix_guru/node389.html Windows-Netzwerk-Hilfe: ISO-/OSI-Referenzmodell. (2010). Abgerufen am 9. Oktober 2012 von http://www.windows-netzwerk-hilfe.de/netzwerk-grundlagen/osi-referenzmodell.html Sozialwerk Bauhütte e.V. (2012). Abgerufen am 16. Oktober 2012 von http://www.sw-bh.fhaachen.de/ Wikipedia: Daemon. (26. September 2012). Abgerufen am 1. Oktober 2012 von http://de.wikipedia.org/wiki/Daemon Wikipedia: File Transfer Protocol. (27. September 2012). Abgerufen am 28. September 2012 von http://de.wikipedia.org/wiki/File_Transfer_Protocol Wikipedia: PostgreSQL. (24. September 2012). Abgerufen am 1. Oktober 2012 von http://de.wikipedia.org/wiki/PostgreSQL Wikipedia: Python. (5. Oktober 2012). Abgerufen am 6. Oktober 2012 von http://de.wikipedia.org/wiki/Python_%28Programmiersprache%29 Wikipedia: Runlevel. (21. März 2012). Abgerufen am 29. September 2012 von http://de.wikipedia.org/wiki/Runlevel Authority, Internet Assigned NUmers. (1. Mai 2012). iana: Hypertext Transfer Protocol Status Code Registry. Abgerufen am 4. Oktober 2012 von http://www.iana.org/assignments/httpstatus-codes/http-status-codes.xml Boenigk, C., & Burger, R. (2011). postgresql.de. Abgerufen am 5. Oktober 2012 von http://www.postgresql.de/index.whtml#pg Colorado, College of Natural Science. (2011). colostate: basic FTP Commands. Abgerufen am 14. Oktober 2012 von http://www.cs.colostate.edu/helpdocs/ftp.html Eickler, A., & Kemper, A. (2006). Datenbanksysteme. München: Oldenburg. Engels, G. (2000/2001). Einführung in Datenbanken. Abgerufen am 4. Oktober 2012 von http://www2.cs.uni-paderborn.de/cs/agengels/ag_dt/Courses/Lehrveranstaltungen/WS0001/TSEII/Begleitunterlagen/Kap1.2SSW.pdf 26 Erstellung eines Datenübertragungsmoduls zum Projekt CW-Plot-Server Océ-Technologies. (2006). Océ Job Ticket 2.4. Abgerufen am 14. Oktober 2012 von http://www.oceusa.com/main/view_media.jsp?CONTENT%3C%3Ecnt_id=101341986733 82561&FOLDER%3C%3Efolder_id=9852723696638963&bmUID=1255064863110 Océ-Technologies. (2008). Océ User Manual: Print using a DOS command line interface. Abgerufen am 17. September 2012 von http://okb.oceusa.com/English_ext/WFPS/SysAd_Arc/cw_pw_tcs_tds/ConM_cwpctcstds_ 2012_03/M088395.html Politze, M. (14. Februar 2012). Skriptprogrammierung (PHP MySQL). Abgerufen am 5. 10 2012 von http://www.rz.rwthaachen.de/aw/cms/rz/Zielgruppen/rz_auszubildende/veranstaltungen/informatik/Wahlpflich tkurse/~qwj/skriptprogrammierung_php_mysql_/?lang=de Python Software Foundation. (1990-2012). Python: ftplib. Abgerufen am 30. September 2012 von http://docs.python.org/library/ftplib.html Springer Fachmedien Wiesbaden GmbH. (2012). Gabler Wirschaftslexikon. Abgerufen am 17. Oktober 2012 von http://wirtschaftslexikon.gabler.de/Definition/modularisierung.html Theis, T. (2011). Einstieg in Python. Bonn: Galileo Computing. Thissen, D. (28. März 2012). comsys: Rechnernetze für mathematisch-technische SoftwareEntwickler. Abgerufen am 30. September 2012 von http://www.comsys.rwthaachen.de/teaching/rechnernetze-fuer-matse/ Varrazzo, D. (2010). initd: psycopg. Abgerufen am 10. Oktober 2012 von http://www.initd.org/psycopg/ Wall, L., Christiansen, T., & Schwartz, R. (1997). Programmieren mit Pearl. Köln: O'Reilly Verlag. Witherton Jones Publishing Ltd. (2005-2009). Wirtschaftslexikon24. Abgerufen am 8. Oktober 2012 von http://www.wirtschaftslexikon24.net/d/sql/sql.htm 27 Erstellung eines Datenübertragungsmoduls zum Projekt CW-Plot-Server 8. Abbildungs- und Tabellenverzeichnis Abbildung 1 „sample session using the ftplib module“ ..................................................................... 6 Abbildung 2 „ISO/OSI-Referenzmodell“ .......................................................................................... 9 Abbildung 3 „Gedankenaustausch von Philosophen“...................................................................... 10 Abbildung 4 „Tabelle config“ .......................................................................................................... 15 Abbildung 5 „Tabelle file“ ............................................................................................................... 16 Abbildung 6 „Tabelle users“ ............................................................................................................ 17 Abbildung 7 „Programmablauf send2plotterdaemon.py“ ................................................................ 21
