C3Grid-INAD: towards an INfrastructure for general Access to climate Data. D4.1.2 B: Realisierung des Publishing

Transkript

1 C3Grid-INAD: towards an INfrastructure for general Access to climate Data D4.1.2 B: Realisierung des Publishing Author(s): Markus Kemmerling, Jörg Bachmann, Benny Bräuer, Carsten Ehbrecht, Tassilo Galonska, Ulrike Golas Editor: Markus Kemmerling Partner(s): AWI, DKRZ, TUDo, ZIB Lead Partner: TU Dortmund Workpackage: AP4.1: Workflows Deliverable: D4.1.2 Version Identifier: 1.0 Date: 28. September 2012 Document Classification: Public

2

3 Project: C3-INAD: Towards an INfrastructure for general Access to climate Data Gefördert vom BMBF, Förderkennzeichen: 01LG1004A-I Laufzeit: Oktober 2010 September 2013 Abstract Dieses Dokument beschäftigt sich mit der Realisierung des Publising-Konzepts. Ziel ist es, das Publising-Konzept im C3Grid umzusetzen und für den Klimaforscher nutzbar zu machen. Es wird dokumentiert, welche Arbeiten zur Erfüllung dieses Ziels bereits durchgeführt wurden und welche noch zu erledigen sind. Änderungen Version Date Name Brief summary M. Kemmerling Initiales Dokument M. Kemmerling Restrukturierung, Einführung U. Golas Stand DMS, VolD, Zugriffsrechte C. Ehbrecht Stand Metadatengenerierung T. Galonska Stand WSS / WSL C. Ehbrecht Bibtexeinträge B. Bräuer Stand / Ausblick Portal C. Ehbrecht Aussicht Metadatengenerierung M. Kemmerling Abstract, Tippfehler korrigiert und diverse kleinere Ergänzungen U. Golas, J. Bachmann Publishing-Site, Rechtesystem M. Kemmerling Ergänzungen zu Publishing-Site wie mit J. Bachmann besprochen, Zusammenführen der Texte von U. Golas und J. Bachmann, Tippfehler korrigiert C. Ehbrecht Kleine Änderungen bei Metadatengenerierung B. Bräuer Ergänzungen Publishing-Site, div. Tippfehler korrigiert M. Kemmerling Kleinigkeiten korrigiert M. Kemmerling

4 Inhaltsverzeichnis 1 Einführung Veröffentlichung der Daten Stand der Arbeiten Portal WSL WSS DMS VolD/ADiS Publishing-Site Metadatengenerierung Ausblick Portal User Interface Syntaktische Prüfung der Metadaten Publishing-Site Metadatengenerierung Zugriffsrechte

5 1 Einführung Das Publishing-Konzept wurde im Rahmen von Deliverable D4.1.1 [2] ausgearbeitet und dokumentiert. Die folgenden Konzeptbeschreibung ist größtenteils aus dem genannten Dokument entnommen. 1.1 Veröffentlichung der Daten 1. Jeder Workflow erzeugt Metadaten zu den produzierten Ergebnissen. Daten und Metadaten werden zum Datenserver des AWI exportiert (normaler Datenexport im Workflow). 2. Der Benutzer kann die Daten in den nächsten 24h über das Portal herunterladen oder die Dateien für einen anderen Workflow (z.b.: Visualisierungsworkflow) als Eingabe verwenden. Der Datenserver des AWI ist keine Publishing-Site, sondern dient nur als kurzzeitiger Ablageort für Datenexporte. Die 24h, die eine Datei beim Datenserver des AWI verfügbar ist, dürfen nicht mit der Gültigkeitsdauer der veröffentlichten Daten verwechselt werden. 3. Der Benutzer muss die Daten prüfen. a) Der Benutzer muss die Daten visualisieren und auf Plausibilität prüfen. Die Visualisierung erfolgt über den Visualisierungsworkflow oder nach dem Download am Arbeitsplatzrecher. b) Sind die Daten plausibel, kann er sie veröffentlichen. c) Sind die Daten nicht plausibel, muss der Benutzer die Daten herunterladen und statistische Tests durchführen. d) Ergeben die statistischen Tests, dass die Daten korrekt sind, kann er sie veröffentlichen. 4. Wenn der Benutzer sich für eine Veröffentlichung entscheidet, klickt er den Veröffentlichungsbutton im Portal, der sich auf der Downloadseite neben den Daten befindet. 5. Zuerst werden die beiliegenden Metadaten syntaktisch geprüft, ob sie valide sind. Die Prüfung erfolgt automatisch (ohne Interaktion mit dem Benutzer). Sind die Metadaten nicht korrekt, erfolgt eine Meldung an den Nutzer Metadaten entsprechen leider nicht den C3-Konventionen. Bitte wenden Sie sich an den Verantwortlichen Ihres zuvor genutzten Workflows, damit zukünftig die Metadaten korrekt erzeugt werden. 5

6 Es erfolgt keine Korrektur der Metadaten. Weder automatisch noch durch den Benutzer. 6. Sind die Metadaten korrekt wird ein Publishing-Workflow ausgeführt 7. Hat der Nutzer keine Publishing-Site bestimmt, wählt der WSS eine passende aus. 8. Bei der Publishing-Site werden die Metadaten um zusätzliche Informationen, wie der ObjectID, ergänzt. Das passiert im Publishing-Taskflow des DMS 9. Bei der Publishing-Site werden die Metadaten regelmäßig im OAI-Server indexiert. 10. Die Metadaten werden viermal am Tag vom Portal geharvestet. Das bedeutet, dass es 6h dauern kann, bis die veröffentlichten Daten über das Portal such- und auffindbar sind. In der Zwischenzeit können sie jedoch vom Nutzer mit dem Verfahren Publishing-Light (einfacher Datenimport) verwendet werden. 11. Die Resultatdaten haben eine Haltbarkeit von 30 Tagen. Nach dieser Zeit können die Daten automatisch von der Publishing-Site gelöscht und die Metadaten im OAI-Server als deleted markiert werden. 6

7 2 Stand der Arbeiten In diesem Abschnitt werden der Stand der Arbeiten und die dabei gesammelten Erfahrungen diskutiert. 2.1 Portal Mit dem Wechsel der Portalsoftware von GridSphere zu Liferay wurden die bisherigen Erfahrungen zum Publishing Light übernommen. Dabei wurde ein Workflow (QFlux) mit der Möglichkeit ausgestattet, durch Angabe eines bereits auf einer GridRessource befindlichen Datensatzes (d.h. der vollständigen gridftp-adresse) den Workflow mit diesem Datensatz auszuführen. Der vorbereitete Datensatz musste dabei den Bedingungen des Workflows genügen. Die gemachten Erfahrungen fließen in das neue Portal mit ein. Zur Zeit wird die Anbindung des Dateninformationsdienstes (DIS) an das neue Portal entwickelt, damit neben den ESGF-Daten auch C3-Daten wieder bereitstehen. Mit der DIS-Anbindung wird gewährleistet, dass künftig im Grid erzeugte und veröffentlichte Daten (bzw. deren Metadaten) auch wieder im Portal gesucht und weiterverwendet werden können. 2.2 WSL Das Datenmanagement-System des C3Grid verlangt für Publishing-Operationen die Angabe einer Datenquelle (Slice-URL) und die Angabe des Namens einer Datei mit Metainformationen über die zu veröffentlichenden Daten. Da die bestehenden Tasktypen für die Definition eines Publishings ungeeignet waren, wurde für die Workflow Specification Language (WSL) ein neuer Tasktyp definiert, der die oben genannten Parameter als Eingabe unterstützt. Das Schema für den neu definierten Publishing-Task ist in dem Dokument [1] dokumentiert. Der Datenexport und -import ( Publishing Light ) ist bereits seit längerem Teil der WSL. Neu hinzugekommen ist die Möglichkeiten Dateien, z.b. Fehlermeldungen, auch im Fehlerfall zu exportieren. 2.3 WSS Der neu definierte Publishing-Task wird vom Workflow Scheduling Service (WSS) bereits unterstützt. Durch die Angabe eines Publishing-Tasks wird veranlasst, dass der WSS eine der verfügbaren DMS-Instanzen auswählt und die Daten der Quell-Slice dort publizieren. Im Detail bedeutet dies, dass die Daten aus der Quell-Slice zunächst zu 7

8 dem ausgewählten DMS-Server kopiert und anschließend durch das DMS veröffentlicht werden. Die Nutzung des Publishing-Tasks ist in dem Dokument [3] definiert. Die Anbindung des WSS an VolD/ADiS zur Abfrage der verfügbaren Publishing-Sites sowie die Anbindung zum DMS zur Ausführung der Taskflows sind implementiert und wurden im Rahmen einer prototypischen Integration des WSS und des DMS erfolgreich getestet. Die Implementierung des Datenexports und Datenimports ( Publishing Light ) erfolgte schon vor längerer Zeit. Durch den generischen Aufbau des Konzepts und der Implementierung kann diese Funktionalität für beliebige Workflows genutzt werden. 2.4 DMS Das zentrale DMS muss für das Publishing keine zusätzliche Funktionalität beinhalten. Die Workflows werden vom WSS als entsprechende Order beim DMS eingereicht und abgearbeitet, um die angeforderten Daten bereit zu stellen. Dabei kommen, abhängig von der konkreten Anforderung, die bereits für die Standard-Workflows implementierten Taskflows zu Ausführung. 2.5 VolD/ADiS Die Implementierung des VolD ist abgeschlossen. In ADiS steht die Methode public boolean setpublisher( String name, String subspace ) zum registrieren einer Publishing Site sowie die Methode public Map<String, String> listpublisher() zum Abrufen aller Publishing Sites zur Verfügung. 2.6 Publishing-Site Eine Publishing-Site muss eine Instanz des DMS installiert haben. Dann wird das Publishing-Plugin eingebunden, wodurch die Publishing-Site automatisch bei VolD angemeldet wird und zum Publishen zur Verfügung steht. Zum Publishen von Daten benötigt das GNDMS ausschließlich die beiden Informationen, welche Metadatei in welcher Slice (manipuliert und) veröffentlicht werden soll. Das Publishing besteht aus zwei Schritten, die vom WSS hintereinander angestoßen werden. Zuerst wird ein entsprechender Interslice-Transfer ausgeführt, bei dem die angeforderten Daten zur Publishing Site transportiert werden. Anschließend manipuliert der Publishing Taskflow die Metadaten für diese Daten (derzeit wird eine neue OID 1 gesetzt) und veröffentlicht sie im Slicekind-Verzeichnis (in der Verzeichnisstruktur auf der Festplatte eine Ebene höher als die Slice), so dass sie vom Harvester gefunden werden können. Beide Taskflows sind implementiert und getestet. 1 Die neue OID besteht aus einem von Administrator zu konfigurierenden Präfix, der Slice- ID und dem Dateinamen der Metadaten ohne der Endung.xml: <Präfix>.<Slice- ID>.<Metadatendateiname> 8

9 Die veröffentlichte Slice besitzt eine Lebensdauer. Bei jedem Zugriff auf die Slice wird die weitere Lebensdauer auf einen Monat gesetzt, wenn die zuvor aktuelle Lebensdauer nicht länger ist. Wird eine Slice gelöscht (explizit von Außen oder durch Ablauf der Lebensdauer), werden automatisch auch die zugehörigen Metadaten eine Ebene höher gelöscht. Nach dem nächsten Harvesten durch das Portal (alle 6 Stunden) werden die Daten nicht mehr angezeigt. 2.7 Metadatengenerierung Im C3Grid werden die Metadaten im ISO XML Format [5] beschrieben. Für alle im C3Grid verfügbaren Daten Experimente wird ein ISO XML Dokument auf einem OAI Metadaten-Server [8] bereit gestellt. Als Eingabe erhalten die Workflows ein oder auch mehrere Daten, die über die Datenprovider-Schnittstelle des DMS geliefert werden. Diese Daten sind i.a. Teilmengen eines Experiments, also ein oder mehrere Klimavariablen und ein bestimmter zeitlicher und räumlicher Ausschnitt. Zusammen mit diesen Daten wird auch jeweils ein zugehöriges Metadaten Dokument geliefert, dass die ausgeschnittenen Daten beschreibt. In der Lineage Information [4] im Metadaten Dokument wird beschrieben, welche Ausschneideoperationen durchgeführt wurden. Nachdem der Workflow auf die Daten angewendet wurde, wird wieder ein ISO Metadaten Dokument generiert, dass das Ergebnis des Workflows beschreibt. In der Lineage Information wird die Verarbeitung durch den Workflow beschrieben mit der Referenz auf die Quelldaten. Zur Zeit ist jeder Workflow Entwickler selber dafür verantwortlich, dass die ISO Metadaten ausgewertet und neue Metadaten als Ergebnis generiert werden. Hierfür können XSLT Skripte und auch XML Bibliotheken verwendet werden (z.b. Python lxml). Es wäre wünschenswert, wenn es ein gemeinsames Tool für die Verarbeitung von ISO XML Metadaten geben würde, um doppelte Arbeit zu vermeiden und um zu garantieren, dass die Metadaten auch dem C3Grid Metadaten Profil entsprechen. 9

10 3 Ausblick In diesem Abschnitt werden die noch nicht abgeschlossenen Arbeiten zur Realisierung des Publishings aufgeführt und eine zeitliche Abschätzung präsentiert. 3.1 Portal Das Portal stellt nicht nur die Nutzerschnittstelle dar, sondern wird auch die Generierung des Publishing-Workflows und die dafür notwendigen Vorarbeiten übernehmen User Interface Wie in Abschnitt 2.1 erwähnt, können die Daten via DIS ins Portal integriert werden. Auch die Daten des Publishing werden sich nahtlos in den bestehenden Katalog einfügen. Es wird eine Kennzeichnung dieser Daten geben, um sie entsprechenden abzugrenzen, da z.b. diese Daten nicht für jeden Nutzer zur Verfügung stehen werden. Des Weiteren werden Vorbereitungen für die Oberflächenänderungen getroffen, damit beim Einreichen eines Jobs bzw. nachträglich nach der Begutachtung des Ergebnisses dieser als zu publishen markiert und der entsprechende Prozess im Grid in Gang gesetzt wird Syntaktische Prüfung der Metadaten Die syntaktische Prüfung (Validierung) erfolgt beim Harvesting-Vorgang durch das DIS. Dabei wird geprüft, ob die Metadaten dem ISO-Schema genügen. Tun sie dies nicht, wird das Portal dafür Sorge tragen, dass der Nutzer sowie der die Metadaten erzeugende Provider über den Fehler informiert werden, damit dieser behoben werden kann. Aufgrund der Komplexität der Metadaten ist ein manuelles Ändern der Daten nicht vorgesehen. Zusätzlich soll eine weitere Validierung der Metadaten stattfinden, bevor der Publishing- Workflow generiert und beim WSS eingereicht wird. Fehler können so frühzeitig erkannt und der Nutzer darüber informiert werden. 3.2 Publishing-Site Das Publishing-Plugin des DMS hat die lokalen Tests erfolgreich durchlaufen, es fehlt aber noch die Anbindung an das Gesamtsystem. Hierzu muss eine PublishingSite installiert werden und ein OAI-Harvester zur Verfügung stehen, der die Metadaten einsammelt, so dass diese dann im Portal bei der Suche zur Verfügung stehen. Beim AWI wird eine erste Publishing-Site eingerichtet, die dann ausgiebig getestet werden muss. Dabei handelt es sich um eine leistungsfähige Maschine, die mit ca. 25 TB Plattenplatz (RAID-1) ausgestattet ist und den aktuellen Anforderungen an das Publishing gerecht 10

11 wird. Nachfolgend ist beschrieben, welche Schritte durchgeführt werden müssen, um die Publishing-Site einzurichten: Auf der Pubishing-Site muss ein GNDMS mit dem Publishing PlugIn installiert werden. Neben dem GNDMS muss außerdem ein OAI-Server (z. B. joai) installiert sein, der die Daten einem OAI-Harvester zur Verfügung stellt. Ist dieser OAI-Server korrekt konfiguriert und beim OAI-Harvester eingetragen, so werden alle durch das Publishing PlugIn veröffentlichten Daten im Portal wieder angezeigt. Zur Vollständigkeit fehlt im Portal ein Button bzgl. der Ergebnisdaten eines Workflows, der das Veröffentlichen dieser Daten veranlasst (siehe auch Abschnitt 3.1). Dazu muss dann dem GNDMS direkt oder über das WSS der Befehle zum Veröffentlichen gegeben werden (siehe auch Abschnitt 2.2 und 2.3). Benötigt werden dazu die Kenntnis der Site, der Slice und des Dateinamen der Metadatei. Soll ein Workflow auf solche wiederveröffentlichten Daten rechnen, so muss erkannt werden, dass kein vorangehendes Staging notwendig ist, da die Daten bereits in einer Slice liegen. In diesem Fall wird direkt ein Transfer der Daten zu einem ComputeProvider ausgeführt. Dass es sich um wiederveröffentlichte Daten, sogenannten Flatfiles, handelt kann an der OID erkannt werden. Sie besteht aus einem Site-spezifischen Präfix, der Slice-ID und dem Dateinamen der Metadatei. Jede Publishing-Site registriert sich in VolD mit ihrem Präfix. So kann die Kontaktadresse der Site anhand des Präfixes über VolD ermittelt werden. 3.3 Metadatengenerierung Die ISO XML Metadaten Dokumente sind sehr umfangreich und komplex. Es wäre daher ein Tool wünschenswert, dass die Bearbeitung und Erstellung der ISO XML Metadaten vereinfacht. In der Abbildung 3.1 ist ein solches Tool skizziert. Dieses Metadaten Tool ist in Python geschrieben. Der Kern des Tools besteht aus einem Python Objektmodell, dass alle im C3Grid relevanten Metadaten Informationen beschreibt. Dieses Model ist sehr einfach gehalten. Über die Python Skriptsprache hat man einen direkten Zugriff auf diese Metadaten, sowohl zum lesen als auch um diese zu bearbeiten. Zusätzlich gibt es eine Tool Sammlung (auch in Python), die die Bearbeitung der Metadaten im Python Objektmodell weiter vereinfachen sollen. Z.B. Tools für die Validierung, Suche und Bearbeitung der Metadaten. Es gibt einen ISO XML Reader, der die ISO XML Metadaten in das Python Objektmodell überführt. Dieser Reader kann auch mit den im C3Grid vorhanden ISO XML Profilen umgehen (ISO XML mit oder auch ohne DS_Series). Das Python Metadaten Objektmodell kann mit einem ISO XML Writer dann wieder in ein ISO XML Metadaten Dokument geschrieben werden. Beim Writer werden XML Templates (Chameleon [6]) für die einzelnen ISO XML Metadaten Profile verwendet. Zusätzlich zu dem ISO XML Reader/Writer gibt es auch noch einen JSON Reader/Writer. JSON (JavaScript Object Notation) [7] ist eine einfache Key-Value Notation. Die JSON Dokumente für die Metadaten entsprechen dem Python Metadaten Objektmodell. Die JSON Dokumente sind daher leichter zu lesen und zu erstellen. Ein JSON 11

12 Abbildung 3.1: Skizzierung des C3 Metadaten Tools Dokument kann z.b. verwendet werden, um initial ein ISO XML Metadaten Dokument zu generieren. Neben den Python Modulen gibt es ein Kommandozeilen Programm, um die Funktionalität der Python Tools auch für nicht Python Programme (Java, Unix-Shell) nutzen zu können. Eine erste Version des Metadaten Tools soll Ende 2012 zur Verfügung stehen. 3.4 Zugriffsrechte Momentan können die Daten in einer Slice zwar gepublished werden, jedoch hat nur der ursprüngliche Benutzer das Recht, auf die Daten zuzugreifen. Um den Zugriff für andere Benutzer zu erlauben, fehlt ein komplexes Rechtesystem. Schematisch kann hier ein Gruppenrechtesystem, wie es z. B. in UNIX-Dateisystemen vorkommt, eingesetzt werden. Dabei werden Gruppen durch einen Gruppennamen und einer Menge von Nutzern als Mitglieder definiert. Jede Slice gehört dann einem Nutzer (als Besitzer der Slice) und einer Gruppe (die besitzende Gruppe). Anhand eines Rechtekatalogs werden dann dem Besitzer, der besitzenden Gruppe und der Öffentlichkeit eine Menge von Rechten zugesprochen. Diese Mengen von zugesprochenen Rechten seien Besitzerrechteregister, Gruppenrechteregister und Öffentlichkeitsrechteregister genannt. 12

13 Einem zugreifenden Nutzer werden dann die Rechte entsprechend des Registers verteilt bzw. entzogen, das auf den Nutzer zutrifft. Ist z.b. der Nutzer nicht der Besitzer der Slice, jedoch Mitglied der besitzenden Gruppe, so wird ausschließlich das Gruppenrechteregister zur Rechtevergabe angewandt. Globale Gruppen könnten zum Beispiel kommerzielle Nutzer, Testnutzer, Administratoren und Forscher sein. Das Prinzip der Nutzer gibt es bereits im C3Grid und wird technisch durch die DN des benutzen Zertifikats eines Nutzers umgesetzt. Abstrakte Gruppen müssen noch eingeführt werden. Für die zugelassenen Nutzer wird derzeit eine Datei (gridmap-file) an alle beteiligten Knoten verteilt. Für die Gruppenzugehörigkeiten könnte man gleiches Prinzip ebenfalls anwenden, was jedoch den Nachteil der Verzögerung von Gruppenzugehörigkeitsänderungen hätte. Eine andere Variante wäre, die Gruppenzugehörigkeiten in einen zentralen Speicher (zum Beispiel in einen zentralen SAML-Server) zu legen. Die Rechteregister müssen ebenfalls gespeichert werden. Für das Speichern von Rechteregistern auf flüchtige Ressourcen wäre ein zentraler Speicher ungeeignet, da bei einem Ausfall eines Knotens mit flüchtigen Ressourcen die Gefahr bestünde, dass die entsprechenden Rechteregister nicht gelöscht werden würden und statt dessen als Leichen im System verweilten. Eher ist dabei eine Schnittstelle auf dem Knoten notwendig, die das Ändern von Rechteregistern auf einer Ressource ermöglicht. Diese Schnittstelle sollte dann für eine bestimmte Ressource nur der Besitzer der Ressource bzw. ein Administrator aufrufen dürfen. Für nicht flüchtige Ressource, wie etwa einem Workflow, wäre ein zentraler Speicher wiederum geeignet zum Speichern der entsprechenden Rechteregister. Dazu könnte ebenso der zentrale SAML-Server benutzt werden, der bereits die Gruppenzugehörigkeiten speichert. Ein Rechteregister ist dabei eine assoziative Menge, die jedem Eintrag des Rechtekatalogs einen boolschen Wert (d. h. wahr oder falsch) zuordnet. Bisher ungeklärt ist dabei der Rechtekatalog. Dabei muss beachtet werden, dass der Rechtekatalog für unterschiedliche Ressourcen auch unterschiedliche Einträge bereit hält. So kann zu einem Workflow zum Beispiel bestimmt werden, ob er ausgeführt werden darf. Zu einer Slice hingegen kann man sich Lese- und Schreibzugriffsbeschränkungen überlegen. Interessant wäre auch das Vererben von Rechten von einem Workflow auf eine Slice in GNDMS, welche die Ergebnisse des Workflows beinhaltet. So könnten Einträge eines Rechtekatalogs für Slices auch im Rechtekatalog von Workflows auftauchen. Diese Rechte bestimmen dann einschränkendere Rechte der die Ergebnisse enthaltenden Slice, womit eine einfach zu implementierende Art der Rechtevererbung gegeben wäre. Das GNDMS speichert bereits zu jeder Ressource (d. h. zu jeder Slice) den Besitzer und die besitzende Gruppe. Die Schnittstelle zum Ändern der Rechteregister ist bereits vorbereitet. Die Stelle im Code, an der Zugriffsrechte überprüft werden sollen, ist ebenso geklärt und hält bereits relevante vorhandene Informationen (d. h. den aktuellen Nutzer, den Bestzer und die besitzende Grupp) vor. Die Anbindung an SAML, sowie das Speichern der Rechteregister in der GNDMS-Datenbank muss noch implementiert werden. Im Portal wird eine Oberfläche benötigt, die das Ändern von Rechteregistern auf Nutzereigene Ressourcen ermöglicht. Je nach Anforderung fehlt auch eine Oberfläche zum Bearbeiten von Nutzereigenen Gruppen. Das WSS braucht ebenso die Anbindung an den SAML-Server um Workflowausfüh- 13

14 rungen anhand vorhandener Rechte zuzulassen oder abzulehnen. Im Fall von Rechtevererbungen von Workflows auf die Ergebnisslice (siehe oben) muss das WSS die Rechte in der Ergebnisslice anhand der Rechteregister des Workflows setzen. 14

15 Literaturverzeichnis [1] Christian Grimme, Alexander Papaspyrou, Tassilo Galonska, and Markus Kemmerling. Dokumentation der Workflow Specification language (WSL). Technical report, C3Grid-INAD, [2] Markus Kemmerling et al. D Teil B: Resultate von Worflows: Exportieren, Importieren, Veröffentlichen. Technical report, C3Grid-INAD, Deliverable D [3] Markus Kemmerling, Volker Winkelmann, Benny Bräuer, Jens Wahnes, and Tassilo Galonska. D best practices in packaging and releasing C3Grid software modules. Technical report, C3Grid-INAD, Deliverable D [4] NOAA. Iso lineage. [5] NOAA. Noaa wiki, iso [6] Chameleon Project. Chameleon xml templates. [7] JSON Project. Json homepage. [8] OAI Project. Oai metadaten server. 15