WebSphere Extended Deployment Compute Grid, Version 6.1.1
             Betriebssysteme: AIX, HP-UX, Linux, Solaris, Windows,


Integration eines externen Workload-Schedulers und WebSphere Extended Deployment

Viele Kunden verwenden bereits einen externen Workload-Scheduler, um Stapel-Workloads unter z/OS zu verwalten. Obwohl die Ausführung von Java-Stapeljobs in einer Umgebung von WebSphere Application Server attraktiv ist, ist eine Methode für die Steuerung von WebSphere-Compute-Grid-Jobs über einen externen Workload-Scheduler wichtig.

Informationen zum Verständnis von Compute-Grid-Anwendungen

Compute Grid ist eine Komponente von WebSphere Extended Deployment Version 6.1, die eine vollständige Unternehmenslösung für die Programmierung von Java-Stapeljobs darstellt. Compute Grid enthält ein präzises, aber leistungsstarkes POJO-basiertes (Plain Old Java Object) Programmiermodell, ein einfaches Pack- und Implementierungsmodell, eine Jobsteuersprache mit vollständigem Funktionsumfang, einen hoch entwickelten Job-Scheduler, eine stabile Ausführungsumgebung und umfassende Workload-Management- und Verwaltungstools. All dies macht aus WebSphere Extended Deployment Compute Grid die vollständigste Java-Lösung für Stapelverarbeitung, die derzeit verfügbar ist.

Wie die folgende Abbildung zeigt, setzt sich ein Stapeljob aus einer Reihe von Programmen zusammen, die im Hintergrund unter der Steuerung eines Jobmanagers ausgeführt werden. Jedes Programm verwendet keine, eine oder mehrere Eingabedatenquellen und erzeugt keine, eine oder mehrere Ausgabedatensenken. Das Betriebssystem z/OS ist ein Beispiel für eine ausgereifte Verarbeitungsumgebung für Stapeljobs. WebSphere Extended Deployment Compute Grid generalisiert dieses Verarbeitungsmodell und macht es in einer WebSphere/J2EE-Umgebung verfügbar.


Jobprozess

Eine Anwendung von WebSphere Extended Deployment Compute Grid ist eine POJO-Klasse, die eine Stapelschnittstelle implementiert, und wird vom Stapelcontainer von WebSphere Extended Deployment aufgerufen. Sie hat Zugriff auf Containerservices, die Stapeldatenströme, die die Datenquellen und Datensenken darstellen, bereitstellen. Der Zweck einer solchen Anwendung ist gewöhnlich die Ausführung von Massenoperationen für eine große Menge von Datensätzen. Eine Jobdefinition beschreibt eine Reihe von Schritten, von denen jeder ein Stapel-POJO aufruft. Die Jobdefinition beschreibt sowohl die Reihenfolge der Schrittausführung als auch die Stapeldatenströme, die Eingaben und Ausgaben sind und von jedem Schritt verwendet werden.

Ein Compute-Grid-Job wird in einem WebSphere Application Server in einem speziellen Container, dem so genannten Stapelcontainer ausgeführt, wie die folgende Abbildung zeigt:


Stapelcontainer

xJCL-Datei - Jobdefinition

Die Jobdefinition wird in einer speziellen xJCL-Datei beschrieben. xJCL ist eine XML-basierte Jobsteuersprache. Eine xJCL-Datei wird an den Job-Scheduler von WebSphere Extended Deployment übergeben, der den Job, den diese xJCL-Datei darstellt, anschließend an einen WebSphere Application Server sendet, der die POJOs enthält, aus denen sich die Zielanwendung zusammensetzt. In WebSphere Application Server erstellt der Stapelcontainer einen verwalteten Thread, eine so genannte asynchrone Bean, für die Verarbeitung des Jobs. Die asynchrone Bean verarbeitet den Job, indem sie das im ersten Jobabschnitt angegebene POJO, dann das im zweiten Abschnitt angegebene POJO usw. aufruft. Das in jedem Abschnitt aufgerufene POJO hat Zugriff auf die Eingabe- und Ausgabestapeldatenströme, die in der Jobdefinition (der xJCL-Datei) beschrieben sind.

Gewöhnlich verarbeitet das POJO viele Eingabedatensätze und erzeugt viele Ausgabedatensätze. Da das POJO in WebSphere Application Server ausgeführt wird, hat es vollständigen Zugriff auf das J2EE-Programmiermodell und alle Services von WebSphere Application Server, wie z. B. die Transaktions- und Verbindungsverwaltung. Aus Effizienzgründen kann es weitere Web- und J2EE-Services aufrufen.

Integration externer Scheduler

Da ein externer Scheduler nicht weiß, wie Jobs von WebSphere Extended Deployment direkt verwaltet werden, wird ein Proxy-Modell verwendet. Das Proxy-Modell verwendet einen regulären JCL-Job, um den Job von WebSphere Extended Deployment zu übergeben und/oder zu überwachen. Der JCL-Jobabschnitt ruft ein spezielles Programm mit dem Namen "WSGRID" auf, das von WebSphere Extended Deployment bereitgestellt wird. Die Anwendung "WSGRID" übergibt und überwacht einen angegebenen Job von WebSphere Extended Deployment. WSGRID schreibt temporäre Ergebnisse des Jobs in das Jobprotokoll des JCL-Jobs. WSGRID kehrt erst zurück, wenn der zugrunde liegende Job abgeschlossen ist, und unterstützt damit ein synchrones Ausführungsmodell. Da der externe Scheduler JCL-Jobs verwalten kann, kann er auch einen JCL-Job verwalten, der WSGRID aufruft. Unter Verwendung dieses Musters kann der externe Scheduler einen Job indirekt verwalten. Über eine optionale Plug-in-Schnittstelle im Job-Scheduler kann ein Benutzer Code hinzufügen, der den Durchführungsplan des externen Schedulers aktualisiert, um den eindeutigen Status des zugrunde liegenden Jobs, z. B. Job gestartet, Abschnitt gestartet, Abschnitt beendet, Job beendet, anzuzeigen. Das Programm "WSGRID" enthält Code für eine spezielle Wiederherstellungsverarbeitung, so dass beim Abbruch des JCL-Jobs auch der zugrunde liegende Job abgebrochen wird, um die Synchronisation der Lebenszyklen beider Jobs zu gewährleisten.


Jobsteuerung auf der z/OS-Plattform durch einen externen Workload-Scheduler

[For distributed platforms] Die Jobsteuerung für verteilte Plattformen ist ähnlich, wie in der folgenden Abbildung dargestellt, mit der Ausnahme, dass das Jobeingabesubsystem (JES) für die verteilten Plattformen nicht erforderlich ist.


Jobsteuerung für die verteilten Plattformen durch einen externen Workload-Scheduler

Viele Kunden verwenden bereits TWS, um Stapel-Workloads auf der z/OS-Plattform zu verwalten. Obwohl die Ausführung von Java-Stapeljobs in einer Umgebung von WebSphere Application Server attraktiv ist, ist eine Methode für die Steuerung von Jobs von WebSphere Extended Deployment Compute Grid über TWS erforderlich. Da TWS nicht weiß, wie Jobs von WebSphere Extended Deployment direkt verwaltet werden, wird ein Proxy-Modell verwendet. Das Proxy-Modell verwendet einen regulären JCL-Job, um den Job von WebSphere Extended Deployment zu übergeben und/oder zu überwachen. Der JCL-Jobabschnitt ruft ein spezielles Programm mit dem Namen "WSGrid" auf, das von WebSphere Extended Deployment bereitgestellt wird. Weitere Informationen hierzu finden Sie im Artikel Befehlszeilendienstprogramm "WSGrid" .

Die Anwendung "WSGrid" übergibt und überwacht einen angegebenen Job von WebSphere Extended Deployment. WSGrid schreibt temporäre Ergebnisse des Jobs in das Jobprotokoll des JCL-Jobs. WSGrid kehrt erst zurück, wenn der zugrunde liegende Job abgeschlossen ist, und unterstützt damit ein synchrones Ausführungsmodell. Da TWS JCL-Jobs verwalten kann, kann er auch einen JCL-Job verwalten, der WSGrid aufruft. Mit diesem Muster kann TWS einen Job von WebSphere Extended Deployment indirekt verwalten.

Über eine optionale Plug-in-Schnittstelle im Job-Scheduler von WebSphere Extended Deployment kann ein Benutzer Code hinzufügen, der den Durchführungsplan von TWS aktualisiert, um den eindeutigen Status des zugrunde liegenden Jobs, z. B. "Job gestartet", "Abschnitt gestartet", "Abschnitt beendet", "Job beendet", anzuzeigen. Das Programm WSGrid enthält Code für eine spezielle Wiederherstellungsverarbeitung, so dass beim Abbruch des JCL-Jobs auch der zugrunde liegende Job von WebSphere Extended Deployment abgebrochen wird, um die Synchronisation der Lebenszyklen beider Jobs zu gewährleisten.




Zugehörige Konzepte
Job-Scheduler mit externen Schedulern integrieren
Compute-Grid-Jobs und ihre Umgebung verwalten
Befehlszeilendienstprogramm "WSGrid"
Zugehörige Tasks
Job-Scheduler konfigurieren
Konzeptartikel    

Nutzungsbedingungen | Feedback

Letzte Aktualisierung: 24.09.2009 16.46 Uhr EDT
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r1m1/index.jsp?topic=/com.ibm.websphere.gridmgr.doc/info/scheduler/ccgtws.html