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
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
| |||
| 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. | |||
| Anforderung | Realisierung | ||
| |||
| 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 Systemschnittstellen unterscheiden sich. Nennenswerter Portierungsaufwand entsteht in der Regel nur bei neuen Systemaufrufen. | ||
| |||
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. | ||
| |||
| Nutzung verschiedener Datenbank-Management-Systeme wie
| Weitgehende Verwendung standardisierter SQL. Die Datenbankschicht passt syntaktische Eigenarten an. Nur beim automatischen Anlegen der Tabellen wird auf die verschiedenenen DBMS stärker eingegangen. | ||
| |||
| Anforderung | Realisierung | ||
| |||
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. | ||
| |||
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. | ||
| |||
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 | ||
| |||
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 ( | Als Schnittstelle zum Modul wird wieder Microsofts | ||
| |||
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. | ||
| |||
| 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. | ||
| Anforderung | Realisierung | ||
| |||
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. | ||
| |||
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. | ||
| |||
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. | ||
| |||
| Anforderung | Realisierung | ||
| |||
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. | ||
| |||
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. | ||
| |||
| Anforderung | Realisierung | ||
| |||
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. | ||
| |||
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. | ||
| |||
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. | ||
| |||
Nur geänderte Dateien sollen übertragen werden | Der anfordernde Rechner überträgt Prüfsummen seiner Konfigurationsdateien. Der Server antwortet nur mit den geänderten, hinzugefügten und gelöschten Dateien. | ||
| |||
| Anforderung | Realisierung | ||
| |||
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. | ||
| |||
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. | ||
| |||
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. | ||
| |||
| Der Scheduler nimmt über TCP, HTTP und die API Kommandos in XML an, führt sie aus und liefert eine XML-Antwort. | |||