Zschimmer GmbH Impressum und Kontakt
Diplom-Informatiker  Joacim Zschimmer
Einige Projekt-Beispiele Techniken
                                                                                                                                                                                                       

Job-Scheduler

Der Scheduler wird angewendet für die zuverlässige Steuerung und Überwachung von Jobs, die sich zu auftragsgesteuerten Jobketten wie zu einem Fließband zusammenfassen lassen, beispielsweise

  • zum Durchschleusen von Bestellungen durch die verschiedenen Arbeitsschritte bis zur Erledigung,
  • zur automatischen Replikation von Dateien, z.B. Lagerbestandsdaten von Konzernunternehmen,
  • zur massenhaften Erzeugung von PDF-Dateien, z.B. Rechnungen, oder
  • zur Generierung und zum Druck großer Mengen von Briefen, z.B. in Versicherungen.

Der in C++ und Java realisierte Scheduler überwacht Jobs, die zeitgesteuert, durch einen Auftrag, beim Eintreffen einer Datei oder auf Kommando gestartet werden. Ausfallsicherer, auf mehrere Rechner verteilter Betrieb ist möglich. Der Scheduler verfügt über eine API, nimmt über TCP und HTTP XML-Kommandos entgegen und lässt sich über die integrierte Browser-Schnittstelle überwachen.

Der Scheduler wird seit 2001 vollständig hier entwickelt und angepasst – im Auftrag der Software- und Organisations-Service GmbH, die ihn mit einer umfangreichen Software-Umgebung als Open Source Job Scheduler liefert.

Weitere Informationen in der Dokumentation, bei SourceForge und in der Wikipedia

Implementierung

Der erste Einsatzzweck war die Steuerung der massenhaften Aufbereitung von Dokumenten (Briefen) mit dem RTF-Prozessor und des Drucks. Der Scheduler führte Jobschritte verzahnt, aber noch nicht nebenläufig aus.
AnforderungRealisierung

C++

2001–2008

Für Windows, Linux, Solarix, HP-UX und AIX, gleiches Verhalten unter allen Betriebssystemen

Zu Beginn 2001 haben wir uns für C++ entschieden. Die Software wird mit der Standard Template Library STL in Microsoft Visual Studio 2008 und GNU GCC entwickelt. Der Code ist für alle Systeme derselbe, nur die Implementierungen der System­schnittstellen unterscheiden sich. Nennens­werter Portierungs­aufwand entsteht in der Regel nur bei neuen System­aufrufen.

  

Datenbankzugriff (API)

2003

Nutzung der JDBC-Treiber für den Datenbankzugriff zur Ablage der Historien

Die nativen JDBC-Treiber laufen umstandslos auf allen Plattformen. Sie werden über eine Datenbankschicht und eine Java-Kopplung über Java Native Interface JNI eingebunden.

Betrieb über ODBC ist weiterhin möglich.

  

DBMS-Abstraktion (SQL)

2001–2008

Nutzung verschiedener Datenbank-Management-Systeme wie

  • Oracle,
  • IBM DB2,
  • Microsoft SQLServer,
  • Sybase Adaptive Server Enterprise ASE,
  • PostgresQL,
  • MySQL und
  • Firebird

Weitgehende Verwendung standardisierter SQL. Die Datenbankschicht passt syntaktische Eigenarten an.

Nur beim automatischen Anlegen der Tabellen wird auf die verschiedenenen DBMS stärker eingegangen.

Scheduler-API für JavaScript, Perl und Java

2001–2008
AnforderungRealisierung

Scheduler-API

2001

Die Scheduler-API stellt den Jobs Objekte und Methoden für Protokollierung, Job-Start, Auftragsbearbeitung u.v.m. bereit.

Damit die API für unterschiedliche Sprachen bereitgestellt werden kann, ist sie mit COM-Klassen umhüllt, die mit ODL schematisch beschrieben sind.

Für Unix-Betriebssysteme ist der COM-Mechanismus neu implementiert worden.

  

Einbindung der Microsoft-Skriptsprachen JScript und VBScript in C++

2001

Die ersten Jobs des Scheduler werden in VBScript geschrieben.

Microsofts Skriptsprachen JScript und VBScript werden über die einheitliche Schnittstelle Scripting Engine angesprochen.

Ebenso später PerlScript von ActiveState.

  

Einbindung von Perl

2002

Für den Betrieb unter Unix-Betriebssystemen soll Perl als Skriptsprache eingesetzt werden.

Perl wird über das Perl-API eingebunden und dem Scheduler über die Schnittstelle IActiveScript (scripting engine) als nachladbares Modul (shared object) bereitgestellt.

  

Einbindung von JavaScript

2004, 2008

Auswahl einer ausgereiften Implementierung von JavaScript

Die Wahl fällt auf Mozillas JavaScript-Implementierung Spidermonkey. 2008 ist eine neue Version von Spidermonkey nach dem Standard JavaScript 1.7 übernommen worden. Mozilla plant weitere Versionen.

JavaScript soll als nachladbares Modul (.dll bzw. .so) bereitgestellt werden.

Als Schnittstelle zum Modul wird wieder Microsofts IActiveScript verwendet.

  

Einbindung von Java

2002, 2007

Jobs, die die Scheduler-API nutzen, sollen auch in Java geschrieben werden können.

Java ist über JNI eingebunden. Der Job implementiert die Methoden einer vom Scheduler vorgegebenen Oberklasse. Die Objekte des Schedulers sind über Java-Proxy-Klassen ansprechbar, die die Aufrufe über JNI an C++ weitergeleiten.

Besondere Vorkehrungen zur Freigabe von Objekten für Javas garbage collector.

  

API für Jobs in separaten Prozessen (marshalling)

2003

Die Jobs sollen nebenläufig und in eigenen Prozessen laufen, damit sie nicht den Betrieb des Schedulers beeinträchtigen können.

Sie sollen weiterhin die Scheduler-API nutzen können.

Die Aufrufe der mit COM umhüllten Objekte werden zu einem Byte-Strom serialisiert und über eine Pipe oder TCP-Verbindung gesendet (marshalling). Der Empfänger ruft die verlangte Methode auf und übergibt typgerecht mit C++-Mitteln die Parameter. Anschließend wird der Rückgabewert oder die Exception zurückgesendet. Objekt-Referenzen werden mit Proxys realisiert. Der Vorgang ist für den Anwender transparent.

Jobs können auch auf einem anderen Rechner laufen.

Implementierung ohne Threads, mit asynchronen Objekten.

AnforderungRealisierung

Auftragsbearbeitung in Jobketten

Wie auf einem Fließband durchlaufen Aufträge eine Kette von Jobs.

Die Jobkette ordnet jedem Zustand des Auftrags einen Job zu. Jeder Job einer Jobkette stellt eine Methode zur Verarbeitung eines Auftrags bereit und kann damit mehrere Aufträge nacheinander bearbeiten. Er kann den Zustand des Auftrags (dessen Position in der Jobkette) ändern oder den Auftrag für eine Weile zurückstellen.

In einer Jobkette können mehrere Aufträge, die über ihre Kennung unterschieden werden, parallel bearbeitet werden.

Wenn eine Jobkette nur einen Auftrag kennt, kann dieser als Staffelstab (token) benutzt werden, der für die richtige Reihenfolge der Ausführung der Jobs sorgt.

Aufträge können eine Startzeit haben und periodisch oder nach einem Kalender wiederholt werden.

Jobketten lassen sich verschachteln.

  

Verzeichnisüberwachung und dateigesteuerte Aufträge

2002

Eine Jobkette soll immer dann gestartet werden, wenn einem Verzeichnis eine Datei hinzugefügt worden ist.

Windows: Die Funktion des Betriebssystem wird genutzt.

Unix: Periodische Prüfung des Verzeichnisses auf Veränderung.

Für jede im überwachten Verzeichnis vorhandene oder neu eintreffende Datei erzeugt der Scheduler einen Auftrag. Der Auftrag lebt solange, wie die Datei vorhanden ist. Die Jobkette arbeitet mit der Datei, bis sie sie nach Erledigung des Auftrags entfernt. Mehrere Dateien können parallel verarbeitet werden.

  

Web-Services

Anpassbare Web-Service-Schnittstelle für Kommandos

Die Kommandos des Scheduler sind als Web-Service zugänglich. Dabei kann die Schnittstelle über XSLT angepasst werden, sodass zum Beispiel SOAP-Anfragen möglich sind.

Web-Service-Schnittstelle für Jobs

Jobketten lassen sich als Web-Service einrichten. Eine Aufruf eines Web-Service führt zu einem Auftrag, der die Jobkette durchläuft und am Ende eine Antwort erzeugt.

Die Jobs greifen über die API auf die Web-Service-Anforderung zu.

Ausfallsicherer, redundanter Betrieb des Schedulers

2007
AnforderungRealisierung

Verteilte, ausfallsichere und skalierbare Auftragsbearbeitung

Dieselben Aufträge sollen von mehreren Schedulern auf eigenen Rechnern bearbeitet werden. Jeder Rechner kann jederzeit ausfallen. Weitere Rechner sind jederzeit hinzuschaltbar. Gleichberechtigtes Verhalten der Scheduler, keine zentrale Komponente außer der Datenbank.

Jeder Auftragsschritt wird unter einem verfügbaren Scheduler ausgeführt, die Verteilung über die Datenbank abgestimmt. Die Scheduler überwachen gegenseitig ihren Puls und erkennen so einen Ausfall. Nicht mehr lebendige Scheduler werden nach kurzer Frist außer Betrieb genommen und dabei abgebrochene Auftragsschritte zurückgesetzt und wiederholt.

  

Backup-Scheduler

Beim Ausfall des Schedulers soll ein Reserve-Scheduler einspringen

Der Reserve-Scheduler läuft auf einem anderen Rechner und überwacht über die gemeinsame Datenbank den Puls des ersten Schedulers. Sobald der Puls ausfällt, übernimmt der Reserve-Scheduler den Betrieb.

Zentrale Konfiguration in XML

2007
AnforderungRealisierung

Konfiguration im laufenden Betrieb

Die Konfiguration der Jobs, Jobketten usw. soll im laufenden Betrieb geändert werden können, einfach durch Änderung der jeweiligen Datei (hot folder).

Der Scheduler überwacht den Konfigurationsverzeichnisbaum auf Änderungen und übernimmt sie sobald sie stabil sind. Fehlerhafte Änderungen werden verworfen und lassen den Zustand des Schedulers unverändert. Änderungen, die wegen laufender Jobs oder anderer Abhängigkeiten nicht sofort übernommen werden können, übernimmt der Scheduler, sobald das möglich ist.

  

Zentrale Konfiguration für mehrere Scheduler

Für jeden Scheduler soll zentral eine eigene Konfiguration einstellbar sein. Daneben soll eine allgemeine Konfiguration, die für alle Rechner gilt, eingemischt werden. Außerdem gelten auch die Konfigurationen vor Ort.

Die Konfigurationen werden in eigenen Verzeichnisbäumen abgelegt, die nach den Rechnern benannt sind. Ein ausgewählter Scheduler, der Supervisor, überwacht die Verzeichnisse auf Änderungen.

  

Änderungen sollen automatisch an die teilnehmenden Rechner repliziert werden

Kein weiterer Eingriff als die Änderung einer Konfigurationsdatei selbst soll erforderlich sein.

Der Supervisor signalisiert dem betroffenen Scheduler die Änderung, der daraufhin die Differenz zu seinem bisherigen Stand anfordert. Gerade beschriebene, also noch unvollständige Dateien werden erkannt und verzögert gelesen.

  

Geringer Datenverkehr

Nur geänderte Dateien sollen übertragen werden

Der anfordernde Rechner überträgt Prüfsummen seiner Konfigurations­dateien. Der Server antwortet nur mit den geänderten, hinzugefügten und gelöschten Dateien.

Bedienung über Browser, XML-Schnittstelle

2004
AnforderungRealisierung

Interaktion mit dem Scheduler

Der Scheduler ist über eine HTTP-Adresse aus einem Browser heraus aufrufbar und zeigt seinen inneren Zustand.

Ein einfacher, im Scheduler implementierter HTTP-1.1-Server liefert die HTML-Seite und lässt den Scheduler in XML übergebene Kommandos ausführen und beantworten.

  

Bedienung mit einem Browser in Ajax-Technik

Die Oberfläche soll mit einer stehenden Seite realisiert sein, die mit aktuellen Informationen gefüllt wird.

Mit JavaScript wird eine zweite HTTP-Verbindung zum Dienst aufgebaut, die zur Ausfühung von XML-Kommandos dient. Die XML-Antworten werden über ein XSLT-Stylesheet in HTML gewandelt und ins Browser-Fenster eingefügt (DHTML). Die Technik wird 2005 als Ajax bekannt.

Der HTTP-Server arbeitet mit asynchronen Socket-Ereignissen in nur einem Thread für alle Verbindungen.

  

Fortlaufendes Protokoll

Der Scheduler schreibt ein Protokoll, das in einem Browser-Fenster fortlaufend gezeigt werden soll.

Der HTTP-Server liefert jeden neuen Abschnitt der Protokolldatei als Batzen (chunk) einer nie endenden HTTP-Antwort.

  

XML-Schnittstelle

Der Scheduler nimmt über TCP, HTTP und die API Kommandos in XML an, führt sie aus und liefert eine XML-Antwort.