1. S-Cube Learning Package
Chemical Modeling: Workflow Enactment
based on the Chemical Metaphor
INRIA, CNR, SZTAKI
Zsolt Németh, SZTAKI
www.s-cube-network.eu

2. Learning Package Categorization
S-Cube
Service Infrastructure
Multi-level and self-adaptation
Supporting adaptation of
service-based applications

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. 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. 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 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. 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. 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. 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. A common scenario
(e.g. grid workflow)
Abstract workflow
Workflow engine
Resources

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

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

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

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

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

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. 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. A vision of chemical enactment
 Resources

22. A vision of chemical enactment
 Resources
 Activities

23. A vision of chemical enactment
 Resources
 Activities
 Control

24. A vision of chemical enactment
 React

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. 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. Resource quantums
 The usual solutions
P4 P6
P1P2
P5 P3
• stored information may be time sensitive

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

29. Resource quantums
(« materialization of information »)
 resources are represented as tickets
P4 P6
P1P2
P5 P3
• tickets represent a guaranteed service

30. Resource quantums
(« materialization of information »)
P2
P6 P5
P4
P1
P3

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