Programming the Grid Workflows (nicht nur) mit Petrinetzen Andreas Hoheisel
Inhalt Motivation: Wieso Workflows? Konzept: Prozessmodellierung mit High-Level-Petrinetzen Interoperabilität: t: Konvertierung von Prozessbeschreibungen Implementierung: Fraunhofer Process Converter (ProConv) Grid Workflow Execution Service (GWES) Aktuelle Anwendungen in D-Grid MediGRID (Services@MediGRID, MedInfoGrid) PneumoGRID BauVOGrid TextGrid Morgen 11:00 11:30 (M. Haase) Seite 2
Motivation Wieso Workflows? Seite 3
Programmierung verteilter Systeme mit Workflows Workflows = Automatisierung von IT-Prozessen Beschleunigung von IT-Prozessen (z.b. durch Verteilung nebenläufiger Aufgaben auf viele Ressourcen und Optimierung der Daten- und Kontrollflüsse) Vereinfachung der Erstellung und Abarbeitung von IT- Prozessen Wiederverwendbarkeit von IT-Prozessen erhöhen (z.b. ähnliche Prozesse auf unterschiedlichen Systemen und Infrastrukturen realisieren) Mehr Fehlertoleranz und Zuverlässigkeit für IT-Prozesse Schnelle Realisierung und Anpassung von Geschäftsprozessen durch einfache Abbildung auf IT-Prozesse Seite 4
Vision Von der Orchestrierung von einzelnen Diensten und Softwaremodulen hin zu autonomen Verhalten basierend auf der Modellierung und Automatisierung von Prozessen Ziel: Lösen komplexer Probleme Seite 5
Konzept Prozessmodellierung mit High-Level-Petrinetzen Seite 6
Prozessbeschreibungssprachen Web Services BPEL4WS (IBM, BEA Systems, Microsoft) SCUFL (Taverna mygrid) Geschäftsprozesse Ereignisgesteuerte Prozessketten (AML, EPML) XPDL (Wf Management Coalition) BPMN Grid Condor DAGman, UNICORE, GSFL Unsere Lösung: GWorkflowDL Vereinigt Ansätze aus Web-Services, Geschäftsprozessen und Grid in einer einzigen (aber sehr einfachen!) Sprache Basiert auf High-Level-Petrinetzen Seite 7
Modellierung von Prozessen mit GWorkflowDL Zustand und Aktionen werden modelliert Kontroll- und Datenfluss können modelliert werden Einfach und ausdrucksstark Besonders geeignet zur Beschreibung von verteilten und nebenläufigen Prozessen Umfangreiche Theorie verfügbar Intuitive Visualisierung möglich Kompatibel zu internationalem Standard: ISO/IEC 15909-1 Konvertierung von anderen Prozessbeschreibungssprachen möglich (z.b. BPEL, ARIS, EPK, PNML, DAGman,...) Seite 8
GWorkflowDL High-Level Petri Nets (HLPN) Stellen Repräsentieren Platzhalter für Daten oder Marken, Transitionen Repräsentieren (abstrakte) Operationen; abzubilden auf Methodenaufrufe, Programmausführungen oder Unterprozesse Kanten von Stellen nach Transitionen (Flussrelation) n Kanten von Transitionen nach Stellen (Flussrelation) Kapazität Maximale Anzahl von Marken auf einer Stelle x < y p1 x Bedingungen Prioritäten ten Aktivierte Transitionen schalten nur, wenn alle Bedingungen erfüllt sind (XPath) Bei mehreren aktivierten Transitionen schaltet die mit der höheren Priorität zuerst Unterscheidbare Marken Beinhalten reale Daten (Parameter), Referenzen auf Daten oder Zustände (z.b. done, failed, Seiteneffekte) Seite 9 Kantenanschrift Repräsentiert Variablennamen der Operationen oder XPath- Ausdrücke
Einfache (sequentielle) Workflow-Muster Sequenz Exklusive Auswahl (XOR-Split) Mehrfaches Zusammenführen (XOR-Join) Seite 10
Einfache (nebenläufige) Workflow-Muster Parallele Aufteilung (AND-Split) Synchronisierung (AND-Join) Seite 11
Komplexere Workflow-Muster Einer von M (1-out-of-M) Seite 12
Iterative (sequentielle) Workflow-Muster Strukturierte Schleife: for( i=0; i<99; i++ ) {} Strukturierte Schleife mit Aufruf der Funktion x(i) for( i=0; i<99; i++ ) { x(i); } Seite 13
Nebenläufige Workflow-Muster Möglichkeiten zur Modellierung von Nebenläufigkeit mit GWorkflowDL: i 3 i x(i) Nebenläufige Workflows: Mehrere Workflows werden nebenläufig bearbeitet j 3 j y(j) Nebenläufige Transitionen: Mehrere Transitionen, die zur gleichen Zeit aktiviert sind, werden nebenläufig bearbeitet 0 1 i0 3 i1 3 i i x(i) y(i) Nebenläufige Marken: Mehrere Marken auf den Eingabestellen einer aktivierten Transition lösen mehrere nebenläufige Workflow-Aktivitäten aus ( Parameterstudie ) i 3 1 i x(i) Seite 14
Interoperabilität Konvertierung von Prozessbeschreibungen Seite 15
Konvertierung von Prozessbeschreibungen Motivation Verwendung geeigneter (domänenspezifischer) Workflow- Editoren und Prozessbeschreibungen bei der Erstellung von Workflows Bessere Wiederverwendbarkeit von Workflows Einfache Abbildung von Geschäftsprozessen auf IT- Prozesse Bislang von uns untersucht und (prototypisch) implementiert: SCUFL GWorkflowDL BPEL PNML GWorkflowDL AML EPML GWorkflowDL Kleiner Exkurs auf den nächsten Folien Seite 16
EPML GWorkflowDL: Sequenz EPML (Ereignisgesteuerte Prozessketten) GWorkflowDL (High-Level Petrinetze) Seite 17
EPML GWorkflowDL: Parallele Aufteilung AND AND Seite 18
EPML GWorkflowDL: Exklusive Auswahl XOR XOR Seite 19
EPML GWorkflowDL: Schachtelung von Mustern XOR AND AND XOR Seite 20
Implementierung Fraunhofer Process Converter (ProConv) Grid Workflow Execution Service (GWES) Seite 21
Fraunhofer Process Converter Services Dienste zur Konvertierung von Prozessbeschreibungssprachen Schnittstellen: Web-Service (SOAP) Browser (Zertifikat/Smartcard) Kommandozeilen-Client Client-Java-API Bisher realisiert BPEL PNML Verwendet GNU BPEL2oWFN der HU-Berlin PNML GWorkflowDL XSLT von Fraunhofer FIRST EPML GWorkflowDL XSLT von Fraunhofer FIRST AML EPML XSLT von Jan Mendling / Uni-Wien SCUFL GWorkflowDL XSLT (basiert auf XSLT von Simone Pellegrini) Seite 22
Grid Workflow Execution Service (GWES) Automatisierung von IT-Prozessen Ermöglicht gemischte Workflows von traditionellen Batch-Prozessen (u.a. GT4) und Web-Service-Methodenaufrufen (SOA) Automatische Abbildung von abstrakten Workflows auf jeweils geeignete und verfügbare Ressourcen Einfache Integration in vorhandene IT- Infrastrukturen und Geschäftsprozesse Anwendungsbereiche: Medizin, Verkehrsmanagement, Flutvorhersage, Risikoanalyse, Warenwirtschaft, Bauindustrie, Medien, Und jetzt auch mit grafischen (Ajax-)Editor! Seite 23
Geschichte (und Zukunft) des Grid Workflow Execution Service Fraunhofer Resource Grid Since 2001: Erster Prototyp einer Petri-Netz-basierten Workflow-Engine auf Basis von Globus Toolkit 2.4 K-Wf Grid (EU) 2004 2007: 2007: Automatische Erstellung und Ausführung von Workflows, Redesign und Portierung des GWES auf Web-Services + Globus Toolkit 4 CoreGrid (EU) 2004 2008: 2008: Standardisierung der GWorkflowDL, Interoperabilität mit anderen Systemen (z.b. LCG, glite) Instant-Grid (BMBF) 2005 2007: 2007: Betriebssystem + Grid-Middleware + Workflow-Management + Anwendungen = Knoppix-CD Enterprise Grids (Fraunhofer) 2005 2008: 2008: Anpassung für industriellen Einsatz MediGRID (D-Grid) 2005 2009: 2009: Workflows für die medizinische Forschung, Anpassung an D-Grid, Meta-Scheduling TextGrid (D-Grid) 2005-2008: 2008: Erweiterungen für document-style SOAP BauVOGrid (D-Grid) 2007 2010: 2010: Workflows für die Bauindustrie (z.b. Mängelerfassung) D-Grid 2009 2012: 2012: {PneumoGrid (Audit-Trail),, WissGrid (Coaching),, DGSI (Interoperabilität)} Seite 24
Aktuelle Anwendungen in D-Grid MediGRID (Services@MediGRID, MedInfoGrid) PneumoGRID BauVOGrid TextGrid Seite 25
Medizinische Bildbearbeitung mit > 4200 CPUs Ziel Beschleunigung und Vereinfachung von Prozessen in der medizinischen Bildverarbeitung über Unternehmensgrenzen hinweg Ansatz Formal korrekte Modellierung von medizinischen IT- Prozessen Integration unterschiedlicher Datenformate und Standards (DICOM, HL7, PACS) Ausführung von Workflows unter Berücksichtigung der Fehlertoleranz und Ausfallsicherheit Anwendungen Auswertung von 3D-Ultraschall-Daten (Prostata- Biopsie) Charité Berlin Virtuelle Gefäßchirurgie funktionelle Hirnbilddaten (fmri) Seite 26
IT-Prozesse ausführen IT-Prozesse erstellen & überwachen Nutzer Spezifische medizinische Anwendungen durchführen (z.b. für Diagnose oder klinische Studien) Portal Anwendungs-Nutzerschnittstellen Workflow-Nutzerschnittstelle Workflow-Beschreibungssprache (GWorkflowDL) Web Services Audit-Trail Workflow-Management (GWES) Ressourcen-Management WS-GRAM, RFT, SOAP, CLI Med. Geräte Klinik-PACS Grid-PACS RDT Ressourcenüberwachung Globus Toolkit 4 Seite 27 DICOM securedicom
BauVOGrid-Beispiel: Mangelzuordnung per Barcode 1. 2. 3. 4. 5. 6. 12345 Seite 28
BauVOGrid 1. Modellierung Erfassung und Verwaltung von (Referenz-)Prozessen 2. Analyse und Planung Suche, Komposition und Validierung auf der Basis von Prozessbausteinen 3. Ausführung Grid-Workflow t1 Prozess (EPK) t2 Prozess BPO Ontologie (EPK) (OWL) (OWL) Prozess (EPML mit Attributen) t4 Prozess (GWDL) t3 Modellierungs- Werkzeug Analyse- u. Planungs- Werkzeug Grid Services tx = Transformation von Prozessmodelldaten = Datenfluss zwischen Werkzeugen = Input für Prozessausführung im Grid Seite 29
Demonstration Grid Workflow Execution Service Fraunhofer Resource Grid ( DMZ, FhRG-VPN, FhRG-Portal) MediGRID ( portal1, MediGRID-Portal) Grid-Workflow-Forum ( DMZ) Fraunhofer FIRST (quadro) ( FIRST-LAN, FhRG-VPN) Movie Store ( DMZ, FhRG-VPN, FIRST-LAN) Workflow Editor ( DMZ, FhRG-VPN, FIRST-LAN) Fraunhofer Process Converter Services ( DMZ, FIRST-LAN) Seite 30
Vielen Dank für Ihre Aufmerksamkeit! Kontakt andreas.hoheisel@first.fraunhofer.de http://www.first.fraunhofer.de/ http://www.andreas-hoheisel.de/ Download Grid Workflow Execution Service: http://www.gridworkflow.org/gwes/ Seite 31
Backup Slides Seite 32
Classes of Computing Grids Resource / Hardware Grid Typical applications: Simulations, parameter studies, rendering farms, Example climateprediction.net: > 100,000 CPUs Data Grid / Information Grid Huge data volumes, distributed databases Typical applications: Data archives, post processing Example LHC Grid (CERN): 15 Petabyte/Year Source: climateprediction.net Service Grid / Software Grid Convergence with the paradigm of the Service Oriented Architecture (SOA) Source: CERN Seite 33
Grid Computing vs. Computing Cloud Grid Computing: Distributed computing whereby a "super and virtual computer" is composed of a cluster of networked, loosely-coupled computers, acting in concert to perform very large tasks Concept for distributed applications Computing Cloud: Abstraction layer for software resources using the paradigm of software as a service (SaaS) Concept for big resource providers (Google, Amazon, IBM, SUN, ) Computing Clouds can be used as resources within Grid Computing Seite 34
Technical issues Resource Matching and Scheduling Seite 35
Resource Matching and Scheduling Resources are dynamic: resources can fail, new resources may appear and active resources may be removed at any time Therefore abstract (infrastructure-independent) workflows should be composed These abstract workflows are mapped onto available resources during runtime Seite 36
Simple Workflow Scheduler (alias Resource Selector) Objective: Simple and robust optimization of the resource selection that works with a minimum of information Maximize the capacity utilization of available computing nodes/cores (independent from their performance) Equivalent to the optimization of the global efficiency (=throughput) of all computing resources Time sharing is allowed (when using fork) Concept: All matching resources with a quality greater than a threshold are randomly mapped onto queued workflow activities, beginning with high priority activities Current and future work: Optimization of the execution time of single activities and/or whole workflows joint work with Dietmar Sommerfeld/GWDG Seite 37
Example Workflows Activities Resources 1 2 3 4 5 6 high priority Activity 5 Activity 6 Activity 1 Activity 2 Activity 3 Activity 4 R9 R1 R4 R5 quality > 0.8 R2 R6 Activity 7 R7 7 8 low priority Activity 8 R8 R3 Seite 38
Fault-Tolerant Workflows In collaboration with University Potsdam Bettina Schnor, Matthias Schulz Seite 39
Example of explicitly modeled fault tolerance Workflow without fault tolerance Workflow with fault tolerance: If failure exit code=147 occurs, then the license server is started and the activity is repeated Seite 40
Statistics: Fault tolerance in medical workflows Distribution of workflow states in a Grid testbed (October 2007): Due to the fault tolerance mechanisms, 20% of the workflows have been completed successfully although one ore more activities failed (source: Schulz, 2007) Seite 41
Secure Workflows In collaboration with University Potsdam Bettina Schnor, Stephan Müller Seite 42
Security Infrastructure Yagsi Security for SOAs existing Web Service architectures Grid services Support of virtual organizations Fine-grained and role-based authorization Restricted delegation of privileges Support of legacy Web Services Seite 43