Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

S-CUBE LP: Chemical Modeling: Workflow Enactment based on the Chemical Metaphor

608 views

Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

S-CUBE LP: Chemical Modeling: Workflow Enactment based on the Chemical Metaphor

  1. 1. S-Cube Learning PackageChemical Modeling: Workflow Enactment based on the Chemical Metaphor INRIA, CNR, SZTAKI Zsolt Németh, SZTAKI www.s-cube-network.eu
  2. 2. Learning Package Categorization S-Cube Service Infrastructure Multi-level and self-adaptation Supporting adaptation of service-based applications
  3. 3. Learning Package Overview Workflow, workflow management Problem and requirement analysis – enactment in large-scale heterogeneous environments A chemical metaphor for workflow enactment A coordination model for workflow enactment formalized in the -calculus Further challenges
  4. 4. This talk is about workflow but… Workflow is just an example – It is a common programming model for grids – Features many coordination problems Focus: coordination – Large-scale distributed, dynamic, error prone environment and applications – Some degree of autonomy, adaptability, self-* must be provided
  5. 5. Workflow  “The computerized facilitation or automation of a business process in whole or in part” – The Workflow Management Coalition  a collection of activities that are processed in some order and where both data-flow and control-flow relationships may be present
  6. 6. The workflow Management ReferenceModel (Workflow Management Coalition) Process Design Process Analysis, Modeling & Definition Tools & Definition Process Definition Build time Run time Process Instantiation Workflow Enactment Service & Control Interaction with User (human) Applications & Users & Application Tools Tools
  7. 7. Scope of enactment  Abstract workflow Problem  standalone application components  the order in which they are executed  names, references, etc. are logical Abstract workflow  Represented by a graph  typically: DAG Concrete workflow Physical environment
  8. 8. Scope of enactment  Concrete workflow Problem  standalone application components  the order in which they are executed  selected resources, services Abstract workflow  additional activities (e.g. file transfer, staging, etc.)  all names, references, etc. are physical Concrete workflow Physical environment
  9. 9. Learning Package Overview Workflow, workflow management Problem and requirement analysis – enactment in large-scale heterogeneous environments A chemical metaphor for workflow enactment A coordination model for workflow enactment formalized in the -calculus Further challenges
  10. 10. A common scenario(e.g. grid workflow) Abstract workflow Workflow engine Resources
  11. 11. A common scenario(e.g. grid workflow) Abstract workflow Information system Workflow engine Resources
  12. 12. A common scenario(e.g. grid workflow) Abstract workflow Information system Workflow engine Resources
  13. 13. A common scenario(e.g. grid workflow) Abstract workflow Information system Workflow engineConcrete workflow Resources
  14. 14. A common scenario(e.g. grid workflow) Abstract workflow Information system Workflow engineConcrete workflow Resources
  15. 15. Problem analysis (current approaches) The abstract workflow is static (Typically) no advanced control structures A priori mapping/ partly a priori mapping Mapping based on stored information A priori simulation/ a priori test/ a priori optimisation Centralised engine Human interaction Limited autonomy, limited ability for adaptation Overall lack of any high level model
  16. 16. Requirement analysis  Workflow enactment in large-scale heterogeneous environments – should provide a higher level of autonomy – should be able to adapt to changing conditions – should be distributed – should be able to make decisions on partial and actual information – should support arbitrarily complex control structures  Often a complex problem can be solved in a more simple way using nature inspired models
  17. 17. Learning Package Overview Workflow, workflow management Problem and requirement analysis – enactment in large-scale heterogeneous environments A chemical metaphor for workflow enactment A coordination model for workflow enactment formalized in the -calculus Further challenges
  18. 18. This talk is about a chemicalmetaphor but…  It is just an example – Chemical reactions are reasonably similar to workflow enactment – It has a well established formalism  Generally: nature inspiration for solving complex problems – Simple, primitive parts behave “intelligently” as a whole – Ants, termites, cells, molecules, etc.
  19. 19. A chemical metaphor Reactions are – autonomous – distributed – concurrent – depending on local conditions – depending on actual conditions – not following any a priori pattern – evolving in time
  20. 20. A chemical metaphor  Reactions are  Workflow enactment should  autonomous  provide a higher level of  distributed autonomy  concurrent  be able to adapt to changing conditions  depending on local conditions  be distributed  depending on actual  be able to make decisions on conditions partial and actual information  not following any a priori support arbitrarily complex  pattern control structures  evolving in time
  21. 21. A vision of chemical enactment  Resources
  22. 22. A vision of chemical enactment  Resources  Activities
  23. 23. A vision of chemical enactment  Resources  Activities  Control
  24. 24. A vision of chemical enactment  React
  25. 25. Learning Package Overview Workflow, workflow management Problem and requirement analysis – enactment in large-scale heterogeneous environments A chemical metaphor for workflow enactment A coordination model for workflow enactment formalized in the -calculus Further challenges
  26. 26. From a vision to a model  Materialize information: resource quantums  Define an abstract chemical coordination model – independent from actual technical realizations – provide a high-level abstract framework for refinement – formalism: -calculus  Advance, refine: find chemical examples for – Complex control – Fault tolerance – Resource management – Optimization – etc
  27. 27. Resource quantums  The usual solutions P4 P6 P1P2 P5 P3 • stored information may be time sensitive
  28. 28. Resource quantums  The usual solutions P4 P2 P1 P6 P3 P5
  29. 29. Resource quantums(« materialization of information ») resources are represented as tickets P4 P6 P1P2 P5 P3• tickets represent a guaranteed service
  30. 30. Resource quantums(« materialization of information ») P2 P6 P5 P4 P1 P3
  31. 31. The -calculus a declarative, functional formalism inherently concurrent model of computation basic data structure: multiset (chemical solution) – passive molecules: booleans, integers, tuples, naming molecules – active molecules: -abstraction reaction: active molecules capture other molecules – x.M, N → M[x:=N] execution: perform reactions until a stable (inert) chemical solution is resulted
  32. 32. The -calculus: -abstraction Active molecules: -abstraction: PC.M – P is a pattern that selects elements for the reaction – C is a condition; the reaction takes place if C is true – M is the action Example:  i:x, j:y i≤j, x>y. (j+1):x, j:y Semantics: capture i:x and j:y and replace them by (j+1):x, j:y if i≤j, x>y -abstraction is one-shot Universal matching symbol: 
  33. 33. The -calculus -terms are – Commutative: M1,M2≡M2,M1 – Associative: (M1,M2),M3≡M1,(M2,M3) – Realize Brownian motion Reactions – Locality: if M1→M2, then M,M1→M,M2 – Solution: if M1→M2, then <M1>→<M2> Conditional reactions –  xC.M Atomic capture –  x1,x2,…xn.M
  34. 34. Resources a resource quantum is modeled as a sub-solution – recall: chemical solutions can be nested elements in the solution are inert attribute:value pairs there are mandatory attributes otherwise, the format is felxible <id:R1, type:comp, proc:16, OS:Linux, …> <id:N1, type:net, bandwidth:23, …> <id:R3, type:comp, proc:1, installed:equsolver, network:N1 …>
  35. 35. Elementary activities the chemical model does not execute an activity, just enacts it – execution is external exit from the chemical world: – execute activity on resource using parameter – a symbolic notation that can be realised in many ways return to the chemical world – the execution produces some result or error put back in form of a solution (control molecule) – <ActivityID:result> – <ActivityID:result, error:errorcode, …> – <ActivityID:result, executed:R1, …> execute A on R→ <A:result…>,<id:R,…>
  36. 36. Resource dependency activity A needs a resource <id:r, type:comp, proc:1, >. execute A on r < id:R2, type:comp, proc:1,…>< id:R1, type:comp,proc:16, OS:Linux, …> < id:R3, type:comp, proc:1, OS:SunOS, …> <id:r, type:comp, proc:1, >. execute A on r < id:R4, type:comp, < id:R5, type:comp, proc:1, memory:23, …> proc:1, disk:12, …>
  37. 37. Resource dependency <id:r, type:comp, proc:1, >. execute A on r Captured a matching resource < id:R2, type:comp, proc:1,…> < id:R1, type:comp, proc:16, OS:Linux, …> execute A on R3 < id:R4, type:comp, < id:R5, type:comp, proc:1, memory:23, …> proc:1, disk:12, …>
  38. 38. Resource dependency Both the resource and the activity are replaced by a control molecule < id:R2, type:comp, proc:1,…> < id:R1, type:comp, proc:16, OS:Linux, …> < id:R3, type:comp, proc:1, OS:SunOS, …> <A:12, error:0, executed:R3> < id:R4, type:comp, < id:R5, type:comp, proc:1, memory:23, …> proc:1, disk:12, …>
  39. 39. Data and control dependency activity A waits a result from activity B <B:x, >. execute A using x <C:0, error:5> <B:18>  <B:x, >. execute A using x <D:42> <H:apple>
  40. 40. Data and control dependency <B:x, >. execute A using x Captured a corresponding control molecule <C:0, error:5> execute A using 18 <D:42> <H:apple>
  41. 41. Data and control dependency Replaced by the result <C:0, error:5> <A:2, error:0,...> <D:42> <H:apple>
  42. 42. Complex dependencies An activity needs both input from another activity and resources – <id:r, 1>, <B:x, 2>. execute A on r using x Dependencies can be arbitrarily combined – find a resource r1 for activity A and a resource r2 for B so that r1 and r2 have the same operating system – <id:r1, OS:x, 1>, <id:r2, OS:x, 2> . execute A on r1, execute B on r2 Conditions can be added as well – <id:r, disk:x, memory:y, > x>30, y>12. execute A on r
  43. 43. Workflow patterns  Sequence  Conditional  Split  Synchronizing merge  P-split – p-out-of-n activities follow A  P-merge – p-out-of-n results trigger activity A  Loop
  44. 44. Learning Package Overview Workflow, workflow management Problem and requirement analysis – enactment in large-scale heterogeneous environments A chemical metaphor for workflow enactment A coordination model for workflow enactment formalized in the -calculus Further challenges
  45. 45. Challenges  What we have so far is a framework – Principles of a chemical coordination model – It is just the beginning!  Let’s explore and advance – Solve further aspects of workflow enactment: fault tolerance, optimization, resource control, complex workflow structures, constraints, co-allocation, compensation, etc. – Find further nature analogon within the chemical model: temperature, weight, magnetic properties, size, gravity, catalysts, membranes, etc.
  46. 46. Challenges (examples) Resource control by chemical agents – withdraw, modify, block, accept, reject, group, etc. Assert a neutralization agent: <id:r1, >. Replace a molecule: <id:r1, proc:1, OS:x, >.<id:r1, proc:1, OS:Linux, > Combine two molecules: (<id:r1, proc:1, >, <id:r1, proc:1, >). <id:r1, proc:2, >
  47. 47. Challenges (examples) Fault-tolerance by chemical agents – error molecules, retry, rollback, redundancy, compensation, etc. Assert an error handling molecule that reactivates in case of error (<Ai:x, >, <Aj:y, >, <id:r, R, >). (execute A on r using x y, (<A:errork, >,<id:r’, R, >).execute A on r’ using x y))
  48. 48. Challenges (examples) Complex resource allocation and co-llocation scenarios by molecules – e.g. reserve r1 and r2 so that there is a network link between them – (<id:r1, proc:1, network:n, >, <id:r2, proc:4, network:n, >, <id:n, type:net, >). (execute A on r1, (<A:x, >.execute B on r2 using x))
  49. 49. Conclusion The chemical metaphor: autonomous, adapting, distributed, actual The nature inspired coordination model – activities, resources and control are modeled using the same formalism – -calculus is not just description but defines execution semantics as well – workflow structure, resources and control can be added/withdrawn/modified in a fully dynamic and adaptive way
  50. 50. Connections to other teaching units Foundations – The Chemical Computing model and HOCL Programming Applications – Dynamic Adaptation with the Chemical Model © S-Cube – 50/<Max>
  51. 51. References Zsolt Németh, Christian Pérez, Thierry Priol: Distributed workflow coordination: molecules and reactions. IPDPS 2006 Zsolt Németh, Christian Pérez, Thierry Priol: Workflow Enactment Based on a Chemical Metaphor. SEFM 2005: 127-136 Manuel Caeiro, Zsolt Németh, Thierry Priol: A Chemical Model for Dynamic Workflow Coordination. PDP 2011: 215-222
  52. 52. Acknowledgements The research leading to these results has received funding from the European Community’s Seventh Framework Programme [FP7/2007-2013] under grant agreement 215483 (S-Cube).

×