Dokumentation der Workflow Specification Language (WSL)

Transkript

1 Dokumentation der Workflow Specification Language (WSL) Christian Grimme Alexander Papaspyrou Tassilo Galonska Markus Kemmerling Institut für Roboterforschung Technische Universität Dortmund

2 Einleitung Das C3Grid hat bisher ausschließlich Nutzer-Workflows als Use-Cases identifiziert, die durch einen gerichteten Abhängigkeitsgraphen zwischen atomaren Tasks beschrieben werden können. Dabei kann die Klasse der betrachteten Graphen so eingeschränkt werden, dass keine Bedingungs- oder Schleifenkonstrukte benötigt werden. Dies hat zu der Formulierung einer entsprechenden Beschreibungssprache für die Workflows geführt: die Workflow Specification Language (WSL). Diese XMLbasierte Sprache wird vom Workflowschedulingdienst verstanden und interpretiert, um abhängige Aufgaben geordnet auszuführen. Die vorliegende Dokumentation gibt zuerst einen kurzen Einblick in die Architektur des Workflowschedulingdienstes und erklärt anschließend den Aufbau und die Benutzung der WSL für die Beschreibung eines C3Grid Workflows. Architekturüberblick Der C3Grid-Dienst zum Management und zur Planung von Workflows basiert auf einem Service-orientierten Ansatz. Dabei wir ein einzelner Workflow als Kette atomarer aber durch Abhängigkeiten verbundener Einzelaufgaben (Tasks) betrachtet. Diese Sichtweise spiegelt sich auch in der Architektur des Schedulingdienstes wider. So wird jeder einzelne eingereichte Workflow von einem eigenständigen Dienst überwacht und ebenso jeder einzelne Task des Workflows. Eine schematische Darstellung der Architektur findet sich in Abbildung 1 Abbildung 1. Die Einreichung eines Workflows über die zur Verfügung gestellte Schnittstelle führt zur Erzeugung einer Management Instanz, die ausschließlich den eingereichten Workflow bearbeitet und seine Ausführung steuert und Submission API and Service Management Workflow Management Service Execution Service Data Extraction Service Tranfer Service Underlying Value-Added Services (DMS, WS-GRAM) Abbildung 1: Schematische Darstellung der Architektur des Workflowschedulingdienstes, eingebettet in die Abstraktionsschichten des C3Grids.

3 überwacht. Diese Instanz greift zur Ausführung auf spezifische Dienste zurück, die sich um die Ausführung der atomaren Teilaufgaben kümmern. Auch hier wird für jede Teilaufgabe eine eigene Instanz des speziellen Dienste (z.b. Datenextraktion/Staging, Programmausführung oder Datentransfer) erzeugt. Damit bildet jeder Workflow eine unabhängige verwaltete und nach Außen abgeschlossene Einheit. Workflowsbeschreibung Die Beschreibung eines Workflows richtet sich stark nach der Repräsentation durch einen azyklischen Graphen. Dabei sind die Knoten des Graphens als atomare Task, die Verbindungen einerseits als Abhängigkeiten und gleichzeitig als potentieller Transfer zu interpretieren. Im Folgenden ist die XML-Schemadefinition der Workflowbeschreibungssprache abgebildet. <?xml version="1.0" encoding="utf-8"?> <xsd:schema elementformdefault="qualified" targetnamespace=" xmlns:acst=" xmlns:wsl=" xmlns:xsd=" <xsd:import namespace=" schemalocation="state-0.1.xsd" /> <xsd:simpletype name="dependencyoperatorenumeration"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="and" /> <xsd:enumeration value="or" /> </xsd:restriction> </xsd:simpletype> <xsd:complextype name="dependencytype"> <xsd:element name="parent" type="xsd:idref" minoccurs="1" maxoccurs="unbounded" /> <xsd:attribute name="operator" type="wsl:dependencyoperatorenumeration" /> <xsd:complextype name="tasktype"> <xsd:any namespace="##other" processcontents="lax" /> <xsd:element minoccurs="0" name="dependency" type="wsl:dependencytype" /> <xsd:attribute name="identifier" type="xsd:id" /> <xsd:complextype name="workflowtype"> <xsd:element name="task" type="wsl:tasktype" minoccurs="1" maxoccurs="unbounded" /> <xsd:attribute name="securityidentifier" type="xsd:string"/> <xsd:element name="workflow" type="wsl:workflowtype" /> </xsd:schema>

4 Die Sprache enthält verschiedene Elemente, die hier im Einzelnen aufgelistet und erklärt werden. Als Anhaltspunkt wird auf die in Abbildung 2 abgebildete Skizze eines einfachen Workflows bestehend aus drei Tasks Bezug genommen. Task 1 Task 3 Task 2 Abhängigkeit / pot. Transfer Abbildung 2: Darstellung eines einfachen Beispiel-Workflows. Die Elemente der Workflowbeschreibungssprache WSL sind ausschließlich zur Kapselung von in anderen Spezifikationssprachen beschriebenen Tasks und zur Definition der Abhängigkeiten zwischen diesen Tasks gedacht. Im C3Grid-Kontext wird die Beschreibungssprache JSDL benutzt. Element Workflow Task any##other (unterhalb von Task) Parent (unterhalb von Task) Beschreibung Kapselt die Beschreibung eines vollständigen Workflows. Zusätzlich kann für einen Workflow ein securityidentifier angegeben werden (eine Zeichenkette), die für die weitere Delegation des Jobs angaben über den Submittierenden enthält. Dies kann etwa genutzt werden, um den DN eines Nutzer-Zertifikats an unterliegende Dienste weiterzureichen. Kapselt die Definition eines einzelnen Tasks einschließlich der Abhängigkeiten von anderen Tasks. Gleichzeitig wird hier einem Task ein eindeutiger Name zugeordnet (identifier), der für die Angabe von Abhängigkeiten von Bedeutung ist. An dieser Stelle kann eine beliebige Taskdefinition eingefügt werden. Der Workflow-Schedulingdienst unterstützt derzeit nur die Einbettung von JSDL-Beschreibungen. Mit diesem Element kann die Abhängigkeit eines Tasks von einem oder mehreren vorangehenden Task(s) beschrieben werden. Dabei kann ein Operator als Parameter angegeben werden, der bestimmt, wann mit der Ausführung des Tasks begonnen wir. Momentan stehen zwei Werte ( and und or ) zur Verfügung, die angeben, dass auf die Fertigstellung aller vorangehenden Tasks bzw. nur auf einen einzigen vorangehenden Task gewartet werden muss.

5 Das in der obigen Abbildung gezeigte Teil eines Abhängigkeitsgraphen würde in WSL auf die folgende Art ausgedrückt: <Workflow> <Task identifier="task1"> <jsdl:jobdefinition>... </jsdl:jobdefinition> </Task> <Task identifier="task2"> <jsdl:jobdefinition>... </jsdl:jobdefinition> </Task> <Task identifier="task3"> <Dependency operator="and"> <Parent> Task1 </Parent> <Parent> Task2 </Parent> </Dependency> <jsdl:jobdefinition>... </jsdl:jobdefinition> </Task> </Workflow> Es ist zu beachten, dass das hier gezeigt Beispiel den Aufbau einer Workflowbeschreibung nur schematisch und etwas vereinfacht darstellt. Die konkrete Umsetzung eines Workflows ist in einem späteren Abschnitt dieser Dokumentation zu finden. Beschreibung eines C3Grid Workflows Im C3Grid gibt es generell zwei unterschiedliche Arten von atomaren Tasks, die Bestandteil des Workflows sein können. Abbildung 3 zeigt schematisch die einzelnen Komponenten eines Workflows. ExecutionTasks sind Tasks, die eine datenbezogene oder rechenintensive Aufgabe ausführen. Im C3Grid-Kontext beinhaltet diese Art der Tasks sowohl das Datenstaging wie auch die Ausführung von Analyse- und Visualisierungsaufgaben. TransferTasks sind Aufgaben, die den Transfer von Daten von einem Ort zum anderen betreffen. Dabei kann der allgemeine Transfer in drei Unterarten klassifiziert werden: Intermediärer Transfer: diese Art des Transfers muss jedes Mal durchgeführt werden, wenn Daten zwischen zwei Tasks transportiert werden sollen. Dies betrifft Daten, die Ausgabe eines Tasks sind und als Eingabe für einen nachfolgenden Task benötigt werden. Diese Art der Transfers ist im Workflow implizit durch die Abhängigkeitsdefinition zwischen zwei Tasks und den korrespondierenden DataStaging-Blöcken gegeben. Import: mit dieser Art des Transfers werden Daten in den virtuellen Workspace des C3Grids eingefügt und für Tasks als Eingabedaten verfügbar gemacht. Dabei ist vom Nutzer eine explizite Quelle für die Daten anzugeben. Der Zielort des Importes wird erneut transparent vom Scheduler ermittelt.

6 Export: hier werden umgekehrt zum Import Daten aus dem C3Grid herausgenommen und können zu einem explizit angegebenen Ort transportiert werden. Hier wird die Quelle der Daten transparent vom Scheduler bestimmt. Import Export Task1 Task2 intermed. Transfer Abbildung 3: Darstellung der Taskarten in einem Workflow. Beschreibung von Execution Tasks Die Beschreibung eines Execution Tasks ist generell mit einer beliebigen Jobbeschreibungssprache innerhalb der WSL möglich. Die aktuelle Implementierung des Workflowschedulingdienstes setzt jedoch für die Beschreibung von Execution Tasks den Einsatz der vom OGF standardisierten Job Submission Description Language (JSDL) voraus. Diese wird dabei immer in Kombination mit einer spezifischen Erweiterung (Extension) eingesetzt, um einen C3-Grid-spezifischen Task zu beschreiben. Die genutzten Erweiterungen werden in der folgenden Tabelle dargestellt. Erweiterung Beschreibung jsdl-posix-erweiterung Die POSIX Erweiterung für JSDL wird ebenfalls standardisiert vom OGF zur Verfügung gestellt. Mithilfe dieser Spezifikation ist es möglich die Ausführung und Randbedingungen für eine POSIX- Applikation zu beschreiben. So können etwa die ausführbare Datei, Argumente, In-, Output und Error- Files, Umgebungsvariablen und Batchsystem- Parameter angegeben werden. Eine genauere Beschreibung dieses Standards findet sich in der JSDL-Spezifikation. jsdl-c3dataextraction jsdl-c3esgfextraction Mithilfe des C3Grid-spezifischen Schemas lassen sich räumliche und zeitliche Einschränkungen für den zu erstellenden Datenausschnitt formulieren. Zusätzlich können Einschränkungen bezüglich verschiedener Parameter (CF Variablen) eintragen werden. Hinzu kommen Parameter mit denen die Staging-Quelle und Extraktionsziel angegeben werden können. Das Schema dieser Erweiterung ist im Anhang dieses Dokumentes zu finden. Die ESGF-Erweiterung ermöglicht dem C3-Grid den

7 Zugriff auf Klimadaten der Earth System Grid Federation (ESGF). Für die Verwendung von ESGF- Daten innerhalb eines Workflows muss eine Quelladresse und die Checksumme der zu beziehenden Datei bekannt sein. Das Schema der ESGF-Erweiterung ist im Anhang zu finden. jsdl-c3publishing Mit der Publishing-Erweiterung lassen sich die Ergebnisse einer Berechnung oder Datenextraktion innerhalb des C3-Grids veröffentlichen. Das Publishing von Daten ermöglicht anderen Nutzern des C3-Grids die Resultate eines Workflows für weiterführende Analysen zu verwenden, da veröffentliche Datensätze innerhalb des C3-Grids sehr einfach in einen nachfolgenden Workflow importiert werden können. Das Schema der Publishing-Erweiterung ist ebenfalls im Anhang zu finden. Beschreibung von Transfer Tasks Dieser Abschnitt geht auf die notwendigen Voraussetzungen ein, um einen Transfer zwischen zwei Tasks, bzw. um einen Import oder Export zu definieren. Für die Definition von Transfers wird generell das DataStaging-Element der JSDL- Definition benutzt. Hier sind die folgenden Elemente und Attribute von Bedeutung: Element/Attribut DataStaging/name FileName FilesystemName Source Target Aufgabe/Beschreibung Identifikator für einen Transfer. Dieser muss in den Staging-Elementen beider Tasks auftreten, die von dem Transfer betroffen sind. Dadurch ist die Unabhängigkeit des Transfers vom Dateinamen gegeben. Name der zu transportierenden Datei. Pfad, in dem die Datei liegt. Damit kann ein gemeinsamer Workspace angenommen werden. Momentan ist die Konstante JSDL_FILESYSTEM_C3GRID_DMS_WORKSPACE für den Workspace einer Ressource festgelegt. Der Scheduler spezifiziert den absoluten Pfad abhängig von der Ressource auf dem ein Job tatsächlich ausgeführt wird. Hier kann für einen Import die Quelle für den Transport explizit angegeben werden. Dieser Wert darf ausschließlich beim Import gesetzt werden (siehe Tabelle unten). Hier kann für einen Export ein Ziel explizit angegeben werden. Dieser Wert ist ausschließlich für die Beschreibung eines Exportes zu setzen (siehe Tabelle unten).

8 Any Das Any-Element des DataStaging-Blocks kann derzeit nur bei Datenexports verwendet werden. Durch das Eintragen des Conditional-Tags (siehe Anhang) kann es genutzt werden, um festzulegen, unter welchen Bedingungen ein Datenexport ausgeführt werden soll. Der finale Status des vorhergehenden Execution-Tasks bestimmt, ob die Ausführungsbedingung erfüllt ist. Die verschiedenen Transportarten werden über die Belegung der Source und Target Elemente bestimmt. Die folgende Wahrheitstabelle gibt an, welche Elemente für welche Art des Transfers benötigt werden. Import Export intermed. Transfer Source Target Dabei ist zu beachten, dass diese Belegung verpflichtend für eine korrekte Interpretation der Angaben durch den Scheduler ist. Eine Kombination der Fälle ist nicht möglich. Beispiel für die Formulierung eines Workflows Im Folgenden wird exemplarisch ein Workflow aus dem C3Grid-Kontext dargestellt (Chemical Weather Forecast, CWF). Eine Skizze des Abhängigkeitsgraphen ist in Abbildung 4 dargestellt: Transfer Metadaten Staging von Daten Visualisierung Export Transfer Daten Abbildung 4: Darstellung des CWF-Workflows als gerichteten Graphen im Sinne der WSL- Der abgebildete Workflow beginnt mit einem Staging-Aufruf, bei dem die benötigten Daten entsprechend den in der Taskdefinition gegebenen Parametern ausgeschnitten werden. Dieser Vorgang generiert zwei Ausgabedateien, einerseits

9 die Daten selbst, wie auch eine Metadatenbeschreibung des Ausschnittes. Diese Daten werden benötigt um eine Visualisierung durchzuführen. Das während der Visualisierung produzierte Bild wird schließlich zu einem vorgegebenen Ort exportiert. Umschlossen wird die gesamte Beschreibung von dem Workflow-Element. Ein Task wird darin in einem Task-Element gekapselt. <wsl:workflowtype xsi:type="wsl:workflowtype" xmlns:jms=" xmlns:xsi=" xmlns:wsl= securityidentifier="test"> <wsl:task identifier="datastaging" xsi:type="ns2:tasktype"> Die Taskbeschreibung ist entsprechend der JSDL-Definition durchzuführen. Unter CandidateHost können die Resource-Provider angegeben werden, die der Scheduler für die Ausführung des Jobs nutzen kann. Abhängig von dem aktuellen Zustand des Grids wählt der Scheduler daraus einen Provider aus. Im Beispiel ist hier der Datenprovider des ZIB in Berlin als einzige Möglichkeit angegeben. <jsdl:jobdefinition id="datastaging_job" xmlns:jsdl=" xmlns:xsi=" xsi:type="jsdl:jobdefinition_type" xmlns:xsd=" <jsdl:jobdescription xsi:type="jsdl:jobdescription_type" xmlns:jsdl=" <jsdl:resources xsi:type="jsdl:resources_type"> <jsdl:candidatehosts xsi:type="jsdl:candidatehosts_type"> <jsdl:hostname xmlns:xsd=" xsi:type="xsd:string">zib.dp.c3grid.de</jsdl:hostname> </jsdl:candidatehosts> </jsdl:resources> Im Staging-Block werden die Transfers definiert, die vom Task produzierte Ausgaben betreffen und für einen abhängigen Task benötigt werden, also für einen anderen Task zur Verfügung stehen sollen. Jeder Staging Block bezieht sich auf eine Datei und spezifiziert zuerst einen dokumentweit eindeutigen Namen, über den die gekapselte Datei später zugegriffen werden kann. Neben dem Dateinamen ist hier das standardisierte Dateisystem angegeben, das den allgemeinen Workspace im C3Grid angibt.. <jsdl:datastaging name="staged_data_file" xsi:type="jsdl:datastaging_type"> <jsdl:filename xmlns:xsd=" xsi:type="xsd:string">test_cwf_01.nc</jsdl:filename> <jsdl:filesystemname xmlns:xsd=" xsi:type="xsd:ncname">c3grid_dms_workspace</jsdl:filesystemname> </jsdl:datastaging> <jsdl:datastaging name="staged_meta_file" xsi:type="jsdl:datastaging_type"> <jsdl:filename xmlns:xsd=" xsi:type="xsd:string">test_cwf_01.xml</jsdl:filename> <jsdl:filesystemname xmlns:xsd=" xsi:type="xsd:ncname">c3grid_dms_workspace</jsdl:filesystemname> </jsdl:datastaging> Hier beginnt die spezifische C3Grid-Dataextraction Applikation. Es werden spezifische Parameter bezüglich Raum und Zeit angegeben, die eine spezielle Partition des Datensatz zurückliefern. In der aktuellen Beschreibung werden die Zieldateien angegeben. Das sind jene, die bereits im Staging-Block für den Transfer annotiert wurden. <c3grid:dataextractionapplication xmlns:c3grid=" xmlns:xsd=" xmlns:xsi=" xsi:type="c3grid:dataextractionapplicationtype"> <c3grid:extractionsources

10 xsi:type="c3grid:extractionsourcestype"> <c3grid:item xmlns:xsd=" xsi:type="xsd:string">de.dlr.ipa.cwf</c3grid:item> </c3grid:extractionsources> <c3grid:cfvariables xsi:type="c3grid:cfvariablestype"> <c3grid:cfitem xmlns:xsd=" xsi:type="xsd:string">geopotential</c3grid:cfitem> </c3grid:cfvariables> <c3grid:spaceconstraints xsi:type="c3grid:spaceconstraintstype"> <c3grid:longitude xsi:type="c3grid:minmaxvaluetype"> <c3grid:min xmlns:xsd=" xsi:type="xsd:double">0.0</c3grid:min> <c3grid:max xmlns:xsd=" xsi:type="xsd:double">360.0</c3grid:max> </c3grid:longitude> <c3grid:latitude xsi:type="c3grid:minmaxvaluetype"> <c3grid:min xmlns:xsd=" xsi:type="xsd:double">-90.0</c3grid:min> <c3grid:max xmlns:xsd=" xsi:type="xsd:double">90.0</c3grid:max> </c3grid:latitude> <c3grid:altitude xsi:type="c3grid:levelrangetype"> <c3grid:min xsi:type="c3grid:altitudetype"> <c3grid:numeric> <c3grid:value xmlns:xsd=" xsi:type="xsd:double">100.0</c3grid:value> <c3grid:unit xsi:type="c3grid:altitudeunitenumerationtype">hpa</c3grid:unit> </c3grid:numeric> </c3grid:min> <c3grid:max xsi:type="c3grid:altitudetype"> <c3grid:numeric> <c3grid:value xmlns:xsd=" xsi:type="xsd:d ouble">100.0</c3grid:value> <c3grid:unit xsi:type="c3grid:altitudeunitenumerationtype">hpa</c3grid:unit> </c3grid:numeric> </c3grid:max> <c3grid:verticalcrs xmlns:xsd=" xsi:type="xsd:string" /> </c3grid:altitude> </c3grid:spaceconstraints> <c3grid:timeconstraints xsi:type="c3grid:timeconstraintstype"> <c3grid:mintime xmlns:xsd=" xsi:type="xsd:string"> t00:00:00z</c3grid:mintime> <c3grid:maxtime xmlns:xsd=" xsi:type="xsd:string"> t02:59:59z</c3grid:maxtime> </c3grid:timeconstraints> <c3grid:providerconstraints xsi:type="c3grid:providerconstraintstype"> <c3grid:item xsi:type="c3grid:keyvaluepairtype"> <c3grid:key xmlns:xsd=" xsi:type="xsd:string">emptykey</c3grid:key> <c3grid:value xmlns:xsd=" xsi:type="xsd:string">emtyvalue</c3grid:value> </c3grid:item> </c3grid:providerconstraints> <c3grid:output filesystemname="c3grid_dms_workspace" format="nc" xsi:type="c3grid:outputtype"> <c3grid:basedata xmlns:xsd=" xsi:type="xsd:string">test_cwf_01.nc</c3grid:basedata> <c3grid:metadata xmlns:xsd=" xsi:type="xsd:string">test_cwf_01.xml</c3grid:metadata> </c3grid:output> </c3grid:dataextractionapplication> </jsdl:jobdescription> </jsdl:jobdefinition> </wsl:task> An dieser Stelle beginnt der nächste Task. Dieser enthält die Visualisierung der Daten und den anschließenden Export der Bilddatei. <wsl:task identifier="preprocessing" xsi:type="wsl:tasktype">

11 Die angegebene Dependency verweist auf den vorhergehenden Task (über den identifier datastaging ). Damit ist für die Abarbeitung des Workflows vorgegeben, dass zuerst der vorhergehende, dann der jetzt betrachtete Task bearbeitet wird. <wsl:dependency operator="and" xsi:type="ns2:dependencytype"> <wsl:parent xsi:type="xsd:idref" xmlns:xsd=" </wsl:dependency> <jsdl:jobdefinition id="preprocessing_job" xmlns:jsdl=" xmlns:xsi=" xsi:type="jsdl:jobdefinition_type" xmlns:xsd=" xmlns:ns4=" Hier findet sich nun drei Datastaging Blöcke, von denen zwei die Ausgabedateien des vorhergehenden Tasks behandeln und umbenennen. Der dritte Block beschreibt den Export des erzeugten Bildes, indem ein Target (aber kein Source) Element angegeben wird. Ein Export soll jedoch nur dann stattfinden, wenn die Ausführung des Visualisierungstasks erfolgreich war. <jsdl:jobdescription xsi:type="jsdl:jobdescription_type" xmlns:jsdl=" <jsdl:resources xsi:type="jsdl:resources_type"> <jsdl:candidatehosts xsi:type="jsdl:candidatehosts_type"> <jsdl:hostname xmlns:xsd=" xsi:type="xsd:string">pik.cp.c3grid.de</jsdl:hostname> </jsdl:candidatehosts> <jsdl:filesystem name="c3_tools" xsi:type="jsdl:filesystem_type"> <jsdl:mountpoint xmlns:xsd=" xsi:type="xsd:string">/home/henningb/c3/workflow/</jsdl:mountpoint> </jsdl:filesystem> </jsdl:resources> <jsdl:datastaging name="staged_data_file" xsi:type="jsdl:datastaging_type"> <jsdl:filename xmlns:xsd=" xsi:type="xsd:string">ac8a97c dd d1f6bc50229.nc</jsdl:filename> <jsdl:filesystemname xmlns:xsd=" xsi:type="xsd:ncname">c3grid_dms_workspace</jsdl:filesystemname> </jsdl:datastaging> <jsdl:datastaging name="plot_output" xsi:type="jsdl:datastaging_type"> <jsdl:filename xmlns:xsd=" xsi:type="xsd:string">ac8a97c dd d1f6bc50229.png</jsdl:filename> <jsdl:filesystemname xmlns:xsd=" xsi:type="xsd:ncname">c3grid_dms_workspace</jsdl:filesystemname> <jsdl:target xsi:type="jsdl:sourcetarget_type"> <jsdl:uri xmlns:xsd=" xsi:type="xsd:anyuri">gsiftp://c3grid-gt.e-technik.unidortmund.de/home/grimme/test/cwf_cg_test.png</jsdl:uri> </jsdl:target> <Conditional>success</Conditional> </jsdl:datastaging> Der folgende POSIX-Application-Block beschreibt nun die auszuführende Visualisierungs- Applikation einschließlich benötigter Argumente und Pfade. <jsdl-posix:posixapplication xmlns:jsdlposix=" xmlns:xsi=" xsi:type="jsdl-posix:posixapplication_type"> <jsdl-posix:executable xsi:type="jsdl:filename_type">/bin/sh</jsdlposix:executable> <jsdl-posix:argument filesystemname="c3_tools" xsi:type="jsdl-posix:argument_type">plot_netcdf.sh</jsdl-posix:argument> <jsdl-posix:argument xsi:type="jsdl-posix:argument_type">-i</jsdl-posix:argument> <jsdl-posix:argument xsi:type="jsdl-posix:argument_type" filesystemname="c3grid_dms_workspace">ac8a97c dd d1f6bc50229.nc</jsdl-posix:argument> <jsdl-posix:argument xsi:type="jsdl-posix:argument_type">-o</jsdl-posix:argument> <jsdl-posix:argument xsi:type="jsdl-posix:argument_type" filesystemname="c3grid_dms_workspace">ac8a97c dd d1f6bc50229.png</jsdl-posix:argument>

12 </jsdl-posix:posixapplication> </jsdl:jobdescription> </jsdl:jobdefinition> </wsl:task> </wsl:workflow> Wie in dem Beispiel zu erkennen ist, muss der vollständige Programmpfad in der Task-Beschreibung mit angegeben werden. Die WSL stellt jedoch eine Möglichkeit bereit, die Pfade einzelner Workflow-Module in die PATH-Variable eintragen zu lassen, wodurch die Notwendigkeit zur Verwendung absoluter Pfade entfällt. Die Verwendung des Programmnamens ist dann ausreichend. Hierfür wird das Application-Tag der JSDL verwendet. Das nachfolgende Beispiel definiert, dass "cdo" in Version "1.2" geladen werden soll. Anschließend kann bei der Definition des POSIX-Task ein cdo-aufruf ohne Angabe des vollständigen Programmpfades erfolgen. Eine ausführlichere Beschreibung zum Laden von Modulen ist in dem Dokument (Kemmerling, Winkelmann, Bräuer, Galonska, Ehbrecht, & Wahnes, 2012) zu finden. <jsdl:application xsi:type="jsdl:application_type"> <jsdl:applicationname>cdo</jsdl:applicationname> <jsdl:applicationversion>1.2</jsdl:applicationversion> <jsdl:description>loads the cdo module</jsdl:description> </jsdl:application> Die oben abgebildeten WSL-Beschreibungen zeigen den Aufbau von C3-Datenextraktionen und die Definition von POSIX-Tasks. Beispiele für die Definition von ESGF-Extraktionen und Publishings sind in Dokument (Kemmerling, Winkelmann, Bräuer, Galonska, Ehbrecht, & Wahnes, 2012) zu finden.

13 Literaturverzeichnis Kemmerling, M., Winkelmann, V., Bräuer, B., Galonska, T., Ehbrecht, C., & Wahnes, J. (2012). C3-Grid. Best Practices in Packaging and Releasing C3Grid Software Modules.

14 ANHANG In diesem Abschnitt werden die Schemata der Workflow-Beschreibungssprache und der C3Grid-spezifischen Datenextraktionsbeschreibung aufgeführt. Schema der WSL <?xml version="1.0" encoding="utf-8"?> <xsd:schema elementformdefault="qualified" targetnamespace=" xmlns:acst=" xmlns:wsl=" xmlns:xsd=" <xsd:import namespace=" schemalocation="state-0.1.xsd" /> <xsd:simpletype name="dependencyoperatorenumeration"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="and" /> <xsd:enumeration value="or" /> </xsd:restriction> </xsd:simpletype> <xsd:complextype name="dependencytype"> <xsd:element name="parent" type="xsd:idref" minoccurs="1" maxoccurs="unbounded" /> <xsd:attribute name="operator" type="wsl:dependencyoperatorenumeration" /> <xsd:complextype name="tasktype"> <xsd:any namespace="##other" processcontents="lax" /> <xsd:element minoccurs="0" name="dependency" type="wsl:dependencytype" /> <xsd:attribute name="identifier" type="xsd:id" /> <xsd:complextype name="workflowtype"> <xsd:element name="task" type="wsl:tasktype" minoccurs="1" maxoccurs="unbounded" /> <xsd:attribute name="securityidentifier" type="xsd:string"/> </xsd:schema> <xsd:element name="workflow" type="wsl:workflowtype" />

15 Schema der C3GridDataExtraction-Erweiterung <?xml version="1.0" encoding="utf-8"?> <xsd:schema elementformdefault="qualified" targetnamespace=" xmlns:tns=" xmlns:c3wp4=" xmlns:xsd=" <xsd:import namespace=" schemalocation="cfname_type.xsd" /> <xsd:complextype name="keyvaluepairtype"> <xsd:element name="key" type="xsd:string" /> <xsd:element name="value" type="xsd:string" /> <xsd:complextype name="extractionsourcestype"> <xsd:element maxoccurs="unbounded" minoccurs="0" name="item" type="xsd:string" /> <xsd:element name="extractionsources" type="tns:extractionsourcestype" /> <xsd:complextype name="cfvariablestype"> <xsd:element maxoccurs="unbounded" minoccurs="0" name="cfitem" type="xsd:string" /> <xsd:element name="cfvariables" type="tns:cfvariablestype" /> <xsd:simpletype name="altitudeunitenumerationtype"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="hpa" /> <xsd:enumeration value="m" /> <xsd:enumeration value="level" /> </xsd:restriction> </xsd:simpletype> <xsd:simpletype name="levelenumerationtype"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="surface" /> </xsd:restriction> </xsd:simpletype> <xsd:complextype name="minmaxvaluetype"> <xsd:element name="min" type="xsd:double" /> <xsd:element name="max" type="xsd:double" /> <xsd:complextype name="altitudetype"> <xsd:choice> <xsd:element name="numeric"> <xsd:complextype>

16 <xsd:element name="value" type="xsd:double"></xsd:element> <xsd:element name="unit" type="tns:altitudeunitenumerationtype"> </xsd:element> </xsd:element> <xsd:element name="namedlevel" type="xsd:string" /> </xsd:choice> <xsd:complextype name="levelrangetype"> <xsd:element name="min" type="tns:altitudetype" /> <xsd:element name="max" type="tns:altitudetype" /> <xsd:element name="verticalcrs" type="xsd:string" minoccurs="0" maxoccurs="1" /> <xsd:complextype name="spaceconstraintstype"> <xsd:element name="longitude" minoccurs="0" maxoccurs="1" type="tns:minmaxvaluetype" /> <xsd:element name="latitude" minoccurs="0" maxoccurs="1" type="tns:minmaxvaluetype" /> <xsd:element name="altitude" minoccurs="0" maxoccurs="1" type="tns:levelrangetype" /> <xsd:element name="spaceconstraints" type="tns:spaceconstraintstype" /> <xsd:complextype name="timeconstraintstype"> <xsd:element minoccurs="0" name="mintime" type="xsd:string" /> <xsd:element minoccurs="0" name="maxtime" type="xsd:string" /> <xsd:element name="timeconstraints" type="tns:timeconstraintstype" /> <xsd:complextype name="providerconstraintstype"> <xsd:element maxoccurs="unbounded" minoccurs="0" name="item" type="tns:keyvaluepairtype" /> <xsd:element name="providerconstraints" type="tns:providerconstraintstype" /> <xsd:complextype name="outputtype"> <xsd:element name="basedata" type="xsd:string" /> <xsd:element name="metadata" type="xsd:string" /> <xsd:attribute name="format" type="xsd:string" /> <xsd:attribute name="filesystemname" type="xsd:ncname" use="optional" /> <xsd:element name="output" type="tns:outputtype" /> <xsd:complextype name="dataextractionapplicationtype"> <xsd:element ref="tns:extractionsources" /> <xsd:element ref="tns:cfvariables" /> <xsd:element ref="tns:spaceconstraints" />

17 <xsd:element ref="tns:timeconstraints" /> <xsd:element ref="tns:providerconstraints" /> <xsd:element ref="tns:output" /> <xsd:element name="dataextractionapplication" type="tns:dataextractionapplicationtype" /> </xsd:schema> Schema der C3GridESGF-Erweiterung <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" targetnamespace=" xmlns:tns=" elementformdefault="qualified"> <element name="esgfextractiontype"> <complextype> <sequence> <element name="url" type="string"></element> <element name="checksum" type="string"></element> </sequence> </complextype> </element> </schema> Schema der C3GridPublishing-Erweiterung <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" targetnamespace=" xmlns:tns=" elementformdefault="qualified"> <element name="c3publishing"> <complextype> <sequence> <element name="slice" type="string"></element> <element name="metadatafilename" type="string"></element> </sequence> </complextype> </element> </schema> Schema für bedingte Datenexports <?xml version="1.0" encoding="utf-8"?> <xsd:schema elementformdefault="qualified" targetnamespace=" 7" xmlns:tns=" xmlns:xsd=" <!-- Expresses, when a data transfer should be --> <!-- invoked: always, on task's success, on task's --> <!-- failure --> <xsd:simpletype name="conditionaldatatransfertype"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="always" /> <xsd:enumeration value="success" /> <xsd:enumeration value="failure" /> </xsd:restriction> </xsd:simpletype> <xsd:element name="conditionaldatatransfer" type="tns:conditionaldatatransfertype" /> </xsd:schema>