Programming the Grid. Workflows (nicht nur) mit Petrinetzen. Andreas Hoheisel

Transkript

1 Programming the Grid Workflows (nicht nur) mit Petrinetzen Andreas Hoheisel

2 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 MedInfoGrid) PneumoGRID BauVOGrid TextGrid Morgen 11:00 11:30 (M. Haase) Seite 2

3 Motivation Wieso Workflows? Seite 3

4 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

5 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

6 Konzept Prozessmodellierung mit High-Level-Petrinetzen Seite 6

7 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

8 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 Konvertierung von anderen Prozessbeschreibungssprachen möglich (z.b. BPEL, ARIS, EPK, PNML, DAGman,...) Seite 8

9 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

10 Einfache (sequentielle) Workflow-Muster Sequenz Exklusive Auswahl (XOR-Split) Mehrfaches Zusammenführen (XOR-Join) Seite 10

11 Einfache (nebenläufige) Workflow-Muster Parallele Aufteilung (AND-Split) Synchronisierung (AND-Join) Seite 11

12 Komplexere Workflow-Muster Einer von M (1-out-of-M) Seite 12

13 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

14 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

15 Interoperabilität Konvertierung von Prozessbeschreibungen Seite 15

16 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

17 EPML GWorkflowDL: Sequenz EPML (Ereignisgesteuerte Prozessketten) GWorkflowDL (High-Level Petrinetze) Seite 17

18 EPML GWorkflowDL: Parallele Aufteilung AND AND Seite 18

19 EPML GWorkflowDL: Exklusive Auswahl XOR XOR Seite 19

20 EPML GWorkflowDL: Schachtelung von Mustern XOR AND AND XOR Seite 20

21 Implementierung Fraunhofer Process Converter (ProConv) Grid Workflow Execution Service (GWES) Seite 21

22 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

23 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

24 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) : 2007: Automatische Erstellung und Ausführung von Workflows, Redesign und Portierung des GWES auf Web-Services + Globus Toolkit 4 CoreGrid (EU) : 2008: Standardisierung der GWorkflowDL, Interoperabilität mit anderen Systemen (z.b. LCG, glite) Instant-Grid (BMBF) : 2007: Betriebssystem + Grid-Middleware + Workflow-Management + Anwendungen = Knoppix-CD Enterprise Grids (Fraunhofer) : 2008: Anpassung für industriellen Einsatz MediGRID (D-Grid) : 2009: Workflows für die medizinische Forschung, Anpassung an D-Grid, Meta-Scheduling TextGrid (D-Grid) : 2008: Erweiterungen für document-style SOAP BauVOGrid (D-Grid) : 2010: Workflows für die Bauindustrie (z.b. Mängelerfassung) D-Grid : 2012: {PneumoGrid (Audit-Trail),, WissGrid (Coaching),, DGSI (Interoperabilität)} Seite 24

25 Aktuelle Anwendungen in D-Grid MediGRID MedInfoGrid) PneumoGRID BauVOGrid TextGrid Seite 25

26 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

27 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

28 BauVOGrid-Beispiel: Mangelzuordnung per Barcode Seite 28

29 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

30 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

31 Vielen Dank für Ihre Aufmerksamkeit! Kontakt Download Grid Workflow Execution Service: Seite 31

32 Backup Slides Seite 32

33 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

34 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

35 Technical issues Resource Matching and Scheduling Seite 35

36 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

37 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

38 Example Workflows Activities Resources 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

39 Fault-Tolerant Workflows In collaboration with University Potsdam Bettina Schnor, Matthias Schulz Seite 39

40 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

41 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

42 Secure Workflows In collaboration with University Potsdam Bettina Schnor, Stephan Müller Seite 42

43 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