SchedulerAdapter

Der SchedulerAdapter bildet die Schnittstelle zwischen der Welt der Administrations-Tools und der Management Schicht des Batch Programms.

Die grundsätzlichen Funktionen der Scheduler Adapter Schnittstelle sind:

• Jobs erzeugen und die Job Parameter setzen
• Jobs starten, verfolgen sowie Exit- und Reason-Codes als auch Reason-Text zurückliefern
• Aktuellen Job-Status und Progress beobachten

In der Entwicklungsumgebung erfolgt die Auslösung der Jobs manuell, in der Testumgebung kommen Testdriver zum Einsatz und in der Produktion wird die Steuerung höchstwahrscheinlich durch den Enterprise Scheduler sichergestellt.

Der Enterprise Scheduler ist dabei eine vom Batch Framework unabhängige Komponente und steuert die zeitliche und örtliche Abhängigkeiten für die Job Ausführung so, dass eine optimale Auslastung über verschiedene Plattformen sichergestellt und die Kontrolle der Batch-Umgebung gewährleistet werden kann.

JobController

Der JobController hat die direkte Steuerung der Batch Jobs zur Aufgabe.

Beim Job-Controller handelt es sich um ein JMX Bean oder um ein Servlet, welches die Befehle des Schedulers vom Scheduler Adapter entgegennimmt. Im Gegenzug versorgt der Controller den SchedulerAdapter wiederum mit Status- und Progressinfos.

Falls ein Batch Repository vorhanden ist, holt der Job-Controller Planungsinfos wie beispielsweise die Job Parameter aus dem Repository und schreibt Statusinfos wieder dorthin zurück.

Coupler

Der Coupler ermöglicht die Kommunikation der Processing Komponenten mit der Management Schicht.

Einerseits erhält der Coupler Runtime Artefakte wie fachliche Fehlermeldungen oder Recap-Informationen von den Processing Komponenten und leitet Runtime Artefakte an JobController & Repository weiter. Andererseites gibt er aber auch Management Befehle wie beispielsweise einen Abort Request an die Processing Schicht weiter.

Im JEE Umfeld ist der Coupler zudem dafür verantwortlich, die Transaktionskontrolle gegenüber dem Repository sicherzustellen, wenn Runtime Artefakte ins Repository geschrieben werden müssen.

Repository

Das Repository stellt die Persistenz-Schicht des Batch Frameworks zur Verfügung.

Es enthält einerseits geplante Jobs und persistiert andererseit die Runtime Artefakte während der Progammausführung.

Der Zugriff für die Planung sowie die Auswertung der Jobs erfolgt per Webadmin GUI. Weitere Informationen dazu sind bei Xinventa erhältlich.

BusinessLogicService

Der BusinessLogicService gehört nicht mehr zum eigentlichen Teil des Batch Frameworks, sondern er ist der Teil der BusinessLogic, auf welchem die BTP Architektur aufsetzt (siehe Grundlagen ).

Nicht performancekritische Anwendungen können direkt die für das OLTP vorgesehenen Funktionen verwenden. Sobald die Laufzeit jedoch ein entscheidender Faktor wird, muss der BusinessLogic Layer sehr wahrscheinlich um Funktionen für die Massenselektion und den Massenupdate erweitert werden.

Bei einfachen Batch Programmen kann es aus Effizienzgründen durchaus auch Sinn machen, direkt auf die Funktionen der Persistenz-Schicht zuzugreifen, ohne dass diese zusätzlich durch die BusinessLogic Schicht gekapselt sind.

WorkManager

Der Workmanager spielt die zentrale Rolle im WorkManager-Only Pattern, indem er die Datenselektion durchführt und die Arbeit an den Record-Processor delegiert.

Im Java EE Umfeld handelt es sich beim WorkManager mit Vorteil um ein Stateless Session Bean, welches im Normalfall ohne Transaktion läuft, um potentielle Probleme mit allfälligen Transaktions-Timeouts zu umgehen, falls etwas längere Laufzeiten zu erwarten sind oder das Batch Programm "suspendable" gemacht werden soll.

Der WorkManager selektiert die zu bearbeitenden Records über die BusinessLogic und ruft den RecordProcessor mit der optimalen Anzahl Records auf.

RecordProcessor

Der RecordProcessor verarbeitet einen oder mehrere Records über Funktionen der BusinessLogic Schicht.

Wie der WorkManager ist auch der RecordProcessor ein Stateless Session Bean. Dadurch kann durch Transaktionalität die Datenkonsistenz einfach gewährleistet werden.

Werden nur einfache Manipulationen auf den Records ausgeführt, wird vielfach kein expliziter RecordProcessor benötigt, sondern es kann direkt aus dem WorkManager auf BusinessLogic oder Persistence Layer zugegriffen werden.