A Chemical Approach to Distributed Computing

1. A Chemical Approach to Distributed Computing Zsolt Németh MTA SZTAKI Computer and Automation Research Institute/CoreGrid Christian Pérez, Thierry Priol IRISA-INRIA/CoreGrid Manuel Caeiro University of Vigo

2. Overview • A highly abstract coordination model for workflow enactment is sought • Abstraction is based on a nature metaphor: chemical analogy • An appropriate modeling framework: the -calculus • Quest: • vision: idea of chemical coordination • methods for transforming the vision into a model • model: a coordination framework formalizd in the -calculus

3. Motivation • Large-scale heterogeneous distributed systems • Adaptability, flexibility, dynamic behaviour • Applications, platforms, services, etc. • Self-* properties • Human in the loop should be eliminated • Intelligence is pushed into the systems • That formerly resided in outside entities • What is intelligence, how it can be simulated • Nature metaphors

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 must be provided

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. The workflow management reference model (Workflow Management Coalition) Process Design & Definition Process Analysis, Modeling & Definition Tools Build time Process Definition Run time Process Instantiation & Control Workflow Enactment Service Interaction with Users & Application Tools Applications & Tools User (human)

7. Scope of enactment • Abstract workflow • standalone application components • the order in which they are executed • names, references, etc. are logical • Represented by a graph • typically: DAG Problem Abstract workflow Concrete workflow Physical environment

8. Scope of enactment • Concrete workflow • standalone application components • the order in which they are executed • selected resources, services • additional activities (e.g. file transfer, staging, etc.) • all names, references, etc. are physical Problem Abstract workflow Concrete workflow Physical environment

9. Abstract workflow A common scenario(e.g. grid workflow) Workflow engine Resources

10. Information system Abstract workflow A common scenario(e.g. grid workflow) Workflow engine Resources

11. Information system Abstract workflow A common scenario (e.g. grid workflow) Workflow engine Resources

12. Information system Abstract workflow A common scenario(e.g. grid workflow) Workflow engine Resources Concrete workflow

13. Information system Abstract workflow A common scenario(e.g. grid workflow) Workflow engine Resources Concrete workflow

14. 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

15. Enactment as a coordination procedure • Workflow enactment in large-scale heterogeneous environments • should provide a higher level of autonomy • should be able toadapt 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

16. This talk is about a chemical metaphor 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.

17. Reactions are autonomous distributed concurrent depending on local conditions depending on actual conditions not following any a priori pattern evolving in time A chemical metaphor

18. Reactions are autonomous distributed concurrent depending on local conditions depending on actual conditions not following any a priori pattern evolving in time Workflow enactment should provide a higher level of autonomy be able to adapt to changing conditions be distributed be able to make decisions on partial and actual information support arbitrarily complex control structures evolve in time A chemical metaphor

19. A vision

20. A vision of chemical enactment Chemical solution • Resources Resources

21. A vision of chemical enactment • Resources • Activities Activities Resources

22. A vision of chemical enactment Chemical solution • Resources • Activities • Control Activities Resources Control

23. A vision of chemical enactment Chemical solution • React Activities Resources

24. Key elements of the chemical metaphor • Resources and activities are autonomous entities modeled as molecules • The enactment is realised by a series of independent reactions • Reactions are governed by the properties of resources and activities and actual conditions • The state of the computation is a chemical solution

25. From a vision to a model • Materialize information: resource quantums • Define an abstract chemical coordination model using the -calculus

26. Resource quantums • The usual solutions P4 P6 P2 P1 P3 P5 • stored information may be time sensitive

27. Resource quantums(« materialization of information ») resources represented as quantums P4 P6 P2 P1 P3 P5 quantums represent a guaranteed service

28. Resource quantums • The usual solutions P4 P2 P1 P6 P3 P5

29. P2 P5 P6 P4 P1 P3 Resource quantums(« materialization of information ») Processes compete for the quantums Processes holding a quantum access the resources in a controlled way

30. 2 4 2 2 4 3 3 2 4 2 5 The -calculus • captures the chemical notion • a declarative, functional formalism • inherently concurrent, indeterministic model of computation • basic data structure: multiset (chemical solution) • passive molecules: booleans, integers, tuples, naming molecules • active molecules: -abstraction • reaction: an active molecule captures others and transforms • execution: perform reactions until a stable (inert) chemical solution is resulted x,y.x+y 1 x,y.x+y 1 1

31. Active molecules:-abstraction • P.M • P is a pattern that selects elements for the reaction • M is the action • capture x and replace by its square: x . x*x • Conditional reactions: PC.M • C is a condition; the reaction takes place if C is true • capture x and if positive, replace by its square root: x x>0 . sqr(x) • Atomic capture:  x1,x2,…xn.M • a single reaction may capture multiple molecules • capture x,y and replace them by their sum: x,y . x+y • Reaction: active molecules capture other molecules • x.M, N → M[x:=N] • x,y . x+y, 2, 3 → 2+3

32. 2 3 2 4 2 3 2 4 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> x,y.x+y x,y.x+y

33. The coordination model

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 flexible • <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. Elementary activities • the chemical model does not execute an activity, just enacts it – execution is external • exit from the chemical world: • executeactivityonresourceusingparameter • 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. Resource dependency • activity A needs a resource • <id:r, type:comp, proc:1, >. executeAonr < 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, >. executeAonr < id:R4, type:comp, proc:1, memory:23, …> < id:R5, type:comp, proc:1, disk:12, …>

37. Resource dependency • <id:r, type:comp, proc:1, >. executeAonr • Captured a matching resource < id:R2, type:comp, proc:1,…> < id:R1, type:comp, proc:16, OS:Linux, …> executeAonR3 < id:R4, type:comp, proc:1, memory:23, …> < id:R5, type:comp, proc:1, disk:12, …>

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, proc:1, memory:23, …> < id:R5, type:comp, proc:1, disk:12, …>

39. Data and control dependency • activity A waits a result from activity B • <B:x, >. executeAusingx <C:0, error:5> <B:18>  <B:x, >. executeAusingx <D:42> <H:apple>

40. Data and control dependency • <B:x, >. executeAusingx • Captured a corresponding control molecule <C:0, error:5> executeAusing18 <D:42> <H:apple>

41. Data and control dependency • Replaced by the result <C:0, error:5> <A:2, error:0,...> <D:42> <H:apple>

42. Complex dependencies • An activity needs both input from another activity and resources • <id:r, >, <B:x, >. executeAonr usingx • 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, >, <id:r2, OS:x, > . executeAonr1, executeBonr2 • Conditions can be added as well • <id:r, disk:x, memory:y, > x>30, y>12 . executeAonr • Resource, data, control dependencies can be combined

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. An HOCL Workflow Engine • HOCL: Higher Order Chemical Language • Based on the -calculus • Molecules involved: • Tasks. They include the following elements: • A program to be executed • They need specific input data and produce output data • They need a resource or a service satisfying certain features • Connectors. They can be of several types: • Control-flow: AND-split, AND-join, XOR-split, etc. • Data-flow : one-to-one, all-to-all, data loop lists, etc. • Activators. They are used to control the execution of tasks and nodes • Data Elements. They maintain input and output data • Resources. Computational resources that can perform the tasks.

45. An HOCL Workflow Engine Input Data Execute • Disabled  Enabled  Ready  Initiated Data Elements Activators Compile Disabled Tasks Disabled Conn. Workflow Specification Enabled Task Ready Task Activator Data Element Initiated Task Chemical Solution Resource Resources

46. 3. An HOCL Workflow Engine Data Elements Activators • Connectors: AND-split Disabled Tasks Disabled Conn. T.A Act.1 Connector & & Act.2 Act.3 Act.2 Act.3 Act.1 Data Element T.B T.C T.A Resource Chemical Solution Resources

47. 3. An HOCL Workflow Engine • Data One-to-One Connector T.A T.B Data Elements Activators Act.1 Act.2 Data A.1 Disabled Tasks Disabled Conn. Data A. 1,2, …, N Data B.1,2, …, N + 1 Connector + Connector Act3.1 + 2 Connector Data B.1 + Act.1 + N Connector Data C.1 Act.3.1 … 3.N D.A.1..n Data C. 1,2, …, N Act.2 T.A D.B.1..n Resource T.C Chemical Solution T.B Resources Resource

48. Outlook • What we have so far is a framework • Principles of a chemical coordination model • Basic and most advanced workflow patterns modeled • Simple resource management strategies • 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.

49. 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, >

50. 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 onrusingx y, (<A:errork, >,<id:r’, R, >).execute A onr’usingx y))