Advanced Coordination Techniques: Experiments with TuCSoN and ReSpecT

Advanced Coordination Techniques
Experiments with TuCSoN and ReSpecT
Stefano Mariani Andrea Omicini
{s.mariani, andrea.omicini}@unibo.it
Dipartimento di Informatica – Scienza e Ingegneria (DISI)
Alma Mater Studiorum – Università di Bologna
Faculté d’informatique – Université de Namur
Thursday, April 28th, 2016
Mariani & Omicini (DISI, Univ. Bologna) Coordination with TuCSoN Namur, 28/04/2016 1 / 225

Outline
1 Interaction & Coordination in Distributed Systems
On the Interactive Nature of Distributed Systems
On the Role and Nature of Coordination Models
2 Tuple-based Coordination of Distributed Systems
On Tuple-based Coordination Models
Beyond Tuple Spaces: Tuple Centres
3 Coordination with TuCSoN: Basics
Model & Language
Technology Overview
Core API Overview
4 Coordination with ReSpecT: Basics
Model & Virtual Machine
Language Overview
Core API Overview
5 Tuple-based Coordination of Situated Systems
Coordination in the Spatio-Temporal Fabric
Coordination in the Computational / Physical Environment
6 Tuple-based Coordination of Stochastic Systems
Uniform Primitives
7 TuCSoN: Advanced
Model & Language
Advanced Features
Agent Development Frameworks Integration
8 ReSpecT: Advanced
Towards ReSpecTX

Interaction & Coordination in Distributed Systems
Outline
7 TuCSoN: Advanced
8 ReSpecT: Advanced

Interaction & Coordination in Distributed Systems On the Interactive Nature of Distributed Systems
Outline
Model & Language
Technology Overview
Core API Overview
Language Overview
Core API Overview
Uniform Primitives
7 TuCSoN: Advanced
Model & Language
Advanced Features
8 ReSpecT: Advanced
Towards ReSpecTX

Issues in Concurrent / Distributed Systems
Concurrency / Parallelism
multiple independent activities / loci of control
active simultaneously
processes, threads, actors, active objects, agents, . . .
Distribution
activities running on diﬀerent and heterogeneous execution contexts
(virtual machines, devices, . . . )
Social interaction
dependencies among activities
collective goals involving activities coordination / cooperation
Situated interaction
interaction with environmental resources (computational or physical)
interaction within the time-space fabric

(Non) Algorithmic Computation
What is a component in a distributed system?
A computational abstraction characterised by
an independent computational activity
I/O capabilities
⇒ Two orthogonal dimensions
computation
interaction
Beyond Turing Machines
Turing’s choice machines and unorganised machines [WG03]
Wegner’s Interaction Machines [GSW06]

Compositionality vs. Non-compositionality
Compositionality
Sequential composition P1; P2
behaviour(P1; P2) = behaviour(P1) + behaviour(P2)
Non-compositionality
Interactive composition P1 | P2
behaviour(P1 | P2) = behaviour(P1) + behaviour(P2) + interaction(P1, P2)
⇒ Interactive composition is more than the sum of its parts

Non-compositionality: Issues
Compositionality vs. formalisability
a formal model is required for stating any compositional property
however, formalisability does not require compositionality, and does not
imply predictability
partial formalisability may allow for proof of properties, and for partial
predictability
Emergent behaviours
fully-predictable / formalisable systems do not allow by deﬁnition for
emergent behaviours
Formalisability vs. expressiveness
Less / more formalisable systems are (respectively) more / less
expressive in terms of potential behaviours

Basic Engineering Principles
Abstraction
problems should be represented / faced at the right level of abstraction
resulting abstractions should be expressive enough to capture the most
relevant problems
conceptual integrity
Locality & encapsulation
design abstractions should embody the solutions corresponding to the
domain entities they represent
Run-time vs. design-time abstractions
incremental change / evolution
on-line engineering [FG04]
(cognitive) self-organising systems [Omi12a]

Interaction & Coordination in Distributed Systems On the Role and Nature of Coordination Models
Outline
Model & Language
Technology Overview
Core API Overview
Language Overview
Core API Overview
Uniform Primitives
7 TuCSoN: Advanced
Model & Language
Advanced Features
8 ReSpecT: Advanced
Towards ReSpecTX

What is a Coordination Model?
Coordination model as a glue
“A coordination model is the glue that binds separate activities
into an ensemble” [GC92]
Coordination model as an agent interaction framework
“A coordination model provides a framework in which the
interaction of active and independent entities called agents can
be expressed” [Cia96]

Coordination: Sketching a Meta-model [Cia96]
The medium of coordination
“Fills” the interaction space
enables / promotes / governs the
admissible / desirable / required
interactions among the interacting
entities (coordinables)
according to coordination laws
enacted by the behaviour of
the medium
deﬁning the semantics of
coordination coordinables
coordination
medium

Requirements for a Coordination Model
What do we ask to a coordination model?
To provide high-level abstractions and suitably expressive mechanisms
for distributed system engineering
To intrinsically add properties to systems independently of
components
e.g. robustness, ﬂexibility, control, intelligence, adaptiveness,
self-organisation, . . .

Classes of Coordination Models
Control-oriented vs. Data-oriented Models [PA98]
Control-oriented Focus on the acts of communication
Data-oriented Focus on the information exchanged during communication
Several surveys, no time enough here
Are these really classes?
actually, better to take this as a criterion to observe coordination
models, rather than to separate them

Control-oriented Models
Which abstractions?
Producer-consumer pattern
Point-to-point communication
Coordinator as the ruler of the space of interactions
Coordination as conﬁguration of topology
Which systems?
Fine-grained granularity
Fine-tuned control
Good for small-scale, closed systems

Data-oriented Models
Information-based design & interaction (thus, coordination)
Possible spatio-temporal uncoupling
Diﬀerent sort of control over interacting components (governing vs.
commanding)
Examples
Gamma / chemical coordination
Linda & friends / tuple-based coordination

An Evolutionary Pattern?
Paradigms of sequential programming
1 Imperative programming with “goto”
2 Structured programming (procedure-oriented)
3 Object-oriented programming (data-oriented)
Paradigms of coordination programming
1 Message-passing coordination
2 Control-oriented coordination
3 Data-oriented coordination

Tuple-based Coordination of Distributed Systems
Outline
7 TuCSoN: Advanced
8 ReSpecT: Advanced

Tuple-based Coordination of Distributed Systems On Tuple-based Coordination Models
Outline
Model & Language
Technology Overview
Core API Overview
Language Overview
Core API Overview
Uniform Primitives
7 TuCSoN: Advanced
Model & Language
Advanced Features
8 ReSpecT: Advanced
Towards ReSpecTX

Linda [Gel85]: Main Features
tuples ordered collection of information chunks, possibly
heterogeneous in sort
generative communication until explicitly withdrawn, tuples live
independently w.r.t. their producers, and are equally
accessible to all the coordinables, but are bound to none
associative access tuples are accessed based on their content & structure,
rather than by name, address, or location
suspensive semantics coordination operations (e.g., out, in, rd) may be
suspended based on unavailability of matching tuples, and be
woken up when such tuples become available

Linda: Associative Access
Synchronisation based on tuple content & structure
absence / presence of tuples with a given (partial) content / structure
determines the behaviour of the coordinables (then, of the system)
based on tuple templates & matching mechanism
⇒ Information-driven coordination
patterns of coordination based on data / information availability
Reiﬁcation
making events become tuples
grouping classes of events with tuple syntax, and accessing them via
tuple templates

Linda: Suspensive Semantics
in & rd primitives have a suspensive semantics
the coordination medium makes the primitive wait in case a matching
tuple is not found, and wakes it up when such a tuple is found
the coordinable invoking the suspensive primitive is expected to wait
for its successful completion
⇒ Twofold wait
in the coordination medium the operation is ﬁrst (possibly)
suspended, then (possibly) served
in the coordinated entity the invocation may cause a wait-state in the
invoker ⇒ hypothesis on the internal behaviour of the
coordinable

Dining Philos in Linda
Philosopher using chopstick pairs: chops(I,J)
philosopher(I,J) :-
think, % thinking
in(chops(I,J)), % waiting to eat
eat, % eating
out(chops(I,J)), % waiting to think
!, philosopher(I,J).
Issues
+ fairness, no deadlock
+ trivial philosopher’s interaction protocol
– shared resources not handled properly (chops should be independent)
– starvation still possible (eating forever)

Dining Philos in Linda: Where is the Problem?
The behaviour of the coordination medium is fixed once and for all
⇒ coordination problems that fits it are solved satisfactorily, those that do
not fit are not
Introducing novel primitives, e.g., bulk primitives (e.g., in all,
rd all), is not a general-purpose solution
⇒ adding ad hoc primitives does not solve the problem once and for all
As a result, the coordination load is typically charged upon
coordination entities
⇒ this does not follow basic software engineering principles, like
encapsulation, locality, separation of concerns
Mariani Omicini (DISI, Univ. Bologna) Coordination with TuCSoN Namur, 28/04/2016 24 / 225

Dining Philos in Linda: Solution?
Making the behaviour of the coordination medium adaptable to the
coordination problem at hand
⇒ in principle, all coordination problems may fit some admissible
behaviour of the coordination medium
⇒ no need to either add new ad hoc primitives, or change the semantics
of the old ones
⇒ This way, coordination media could encapsulate solutions to
coordination problems
represented in terms of coordination policies
enacted in terms of coordinative behaviour (of the coordination media)
! What is needed is a way to define the behaviour of a coordination
medium
⇒ a general computational model for coordination media
⇒ along with a suitably expressive programming language to define their
behaviour

Hybrid Coordination Models
In a sense, we need to add a control-driven layer to a data-oriented
coordination model
? Why not purely control driven, then?
! control-driven coordination does not ﬁt information-driven contexts,
e.g., Web-based ones — quite obviously
! they also have diﬃculties in dealing with autonomy [DAdB05], a
fundamental feature of, e.g., multi-agent systems
⇒ We need hybrid coordination models

Towards Tuple Centres
What should be added to a tuple-based model to make it hybrid, and
how?
What should be left unchanged?
no new primitives
basic Linda primitives are preserved, both syntax and semantics
matching mechanism preserved, still depending on the communication
language of choice
multiple tuple spaces, ﬂat name space
Which new features?
ability to deﬁne new coordinative behaviours embodying required
coordination policies
ability to associate coordinative behaviours to coordination events

Tuple-based Coordination of Distributed Systems Beyond Tuple Spaces: Tuple Centres
Outline
1 Interaction Coordination in Distributed Systems
Model Language
Technology Overview
Core API Overview
Model Virtual Machine
Language Overview
Core API Overview
Uniform Primitives
7 TuCSoN: Advanced
Model Language
Advanced Features
8 ReSpecT: Advanced
Towards ReSpecTX

Tuple Centres
Definition
A tuple centre is a tuple space enhanced with a behaviour specification,
defining the behaviour of a tuple centre in response to coordination events
[OD01a]
The behaviour specification of a tuple centre
is expressed in terms of a reaction specification language, and
associates any tuple centre event to a (possibly empty) set of
computational activities, called reactions
A reaction specification language, thus
enables definition of reactions. . .
. . . and makes it possible to associate them to the events occurring in a
tuple centre

Reactions
Each reaction can
access and modify the current tuple centre state — e.g., adding or
removing tuples
access the information related to the triggering event – e.g., the
performing process, the primitive invoked, the tuple involved, etc. –
which is made completely observable
invoke link primitives — coordination primitives whose target is another
(remote) tuple centre
⇒ As a result, the semantics of the traditional coordination primitives –
e.g., out, rd, in – is no longer constrained to be as simple as in the
Linda model
instead, it can be made as complex as required by the speciﬁc
application needs

Tuple Centre Working Cycle I
The main cycle of a tuple centre works as follows
1 when a primitive invocation reaches a tuple centre, all the
corresponding reactions (if any) are triggered, and then executed
atomically and transactionally in a non-deterministic order
2 once all the reactions have been executed, the primitive is served in
the same way as in standard Linda
3 upon completion of the invocation, the corresponding reactions (if
any) are triggered, and then executed according to the
aforementioned semantic
4 once all the reactions have been executed, the main cycle of a tuple
centre may go on possibly serving another invocation

Tuple Centre Working Cycle II
As a result, tuple centres exhibit a couple of fundamental features
Tuple spaces as “empty” tuple centres
An empty behaviour specification defaults the behaviour of a tuple centre
to that of a tuple space
Tuple centres still are tuple spaces
From the process’ perspective, the result of the invocation of a tuple
centre primitive is the sum of
the effects of the primitive itself
the effects of all the reactions it triggers
perceived altogether as a single-step transition of the tuple centre state

Tuple Centre’s State vs. Process’ Perception
The observable behaviour of a tuple centre in response to a
communication event is still perceived by processes as a single-step
transition of the tuple-centre state
as in the case of tuple spaces
thanks to atomic and transactional semantic of reactions execution
Unlike a standard tuple space, the perceived transition of a tuple
centre state can be made as complex as needed
⇒ this enables a novel form of decoupling: the process’ view of a tuple
centre may be diﬀerent from the actual state of the same tuple centre

Tuple Centres Hybrid Coordination
Tuple centres promote a form of hybrid coordination
aimed at preserving the advantages of data-driven models
while addressing their limitations in terms of control capabilities
On the one hand, a tuple centre is basically an information-driven
coordination medium, which is perceived as such by processes
On the other hand, a tuple centre also features some capabilities
which are typical of action-driven models, like
full observability of events
the ability to selectively react to events
the ability to program coordination rules by manipulating the
interaction space

Coordination with TuCSoN: Basics
Outline
7 TuCSoN: Advanced
8 ReSpecT: Advanced

Coordination with TuCSoN: Basics Model Language
Outline
Model Language
Technology Overview
Core API Overview
Language Overview
Core API Overview
Uniform Primitives
7 TuCSoN: Advanced
Model Language
Advanced Features
8 ReSpecT: Advanced
Towards ReSpecTX

Tuple Centres Spread over the Network (TuCSoN)
TuCSoN is a model for the coordination of distributed processes, as well
as of autonomous agents [OZ99]
References
main page http://tucson.unibo.it/
Bitbucket http://bitbucket.org/smariani/tucson/
FaceBook http://www.facebook.com/TuCSoNCoordinationTechnology

Core Abstractions I
TuCSoN agents are the coordinables
ReSpecT tuple centres are the programmable coordination media
[OD01b]
TuCSoN nodes represent the basic topological abstraction, which
host the tuple centres
⇒ agents, tuple centres, and nodes have unique identities within a
TuCSoN system
Agents act on tuple centres by means of coordination operations,
built out of the TuCSoN coordination language, as deﬁned by the
collection of TuCSoN coordination primitives

Core Abstractions II
Agents may live anywhere on the network, and may interact with
tuple centres hosted by any reachable TuCSoN node
Agents can move independently of the device where they execute
[OZ98], while tuple centres’ mobility depends on their hosting device
moving abilities
System view
Roughly speaking, a TuCSoN system is a collection of (mobile) agents and
tuple centres, hosted on possibly mobile devices, coordinating in a
(distributed) set of nodes

Nodes
Each node within a TuCSoN system is univocally identiﬁed by the
pair NetworkId, PortNo , where
NetworkId is the IP number of the device hosting the node
PortNo is the TCP port number where the TuCSoN coordination
service listens to incoming requests
⇒ Correspondingly, the abstract syntax1 of TuCSoN nodes identiﬁers is
netid : portno
(localhost : 20504)
1
Actually, this is also the concrete syntax used by TuCSoN to parse nodes’ IDs

Tuple Centres
An admissible name for a tuple centre is any Prolog-like, first-order
logic ground term2 [Llo84]
Each tuple centre is uniquely identified by its admissible name
associated to the node identifier
⇒ Hence the TuCSoN full name of a tuple centre tname on a node
netid : portno is
tname @ netid : portno
(default @ localhost : 20504)
2
Ground roughly means “no variables”

Agents
An admissible name for an agent is any Prolog-like, ﬁrst-order logic
ground term too
When it enters a TuCSoN system, an agent is assigned a universally
unique identiﬁer (UUID)3
⇒ If an agent aname is assigned UUID uuid , its full name is
aname : uuid
(stefano : 4baad505-ad2f-4ac4-b30b-bc3705a2c87a)
3
http://docs.oracle.com/javase/7/docs/api/java/util/UUID.html

Coordination Language
TuCSoN coordination operations are built out of coordination
primitives and of the communication languages:
the tuple language
the tuple template language
In TuCSoN, both the tuple and the tuple template languages are
logic-based, too
any ﬁrst-order logic Prolog atom is an admissible TuCSoN tuple. . .
. . . and an admissible TuCSoN tuple template
⇒ the two languages coincide, thus

Coordination Operations
Any TuCSoN coordination operation is invoked by a source agent on
a target tuple centre, which is in charge of its execution
invocation phase — the request of the agent reaches the tuple
centre, decorated with information about the invocation
completion phase — the response of the tuple centre goes back to
the agent, including information about operation
execution outcome
The abstract syntax4 of a coordination operation op invoked on a
target tuple centre tcid is
tcid ? op
tname @ netid : portno ? op
(default @ localhost : 20504 ? out(t(hi)))
4
Actually, this is also the concrete syntax used by TuCSoN to parse coordination
operations, even inside ReSpecT reactions

Coordination Primitives
The TuCSoN coordination language provides the following 9 coordination
primitives to build coordination operations:
out to put a tuple in the target tuple centre
rd, rdp to read a tuple matching a given tuple template in the target
tuple centre
in, inp to withdraw a tuple matching a given tuple template from
the target tuple centre
no, nop to check absence of tuples matching a given tuple template
in the target tuple centre
get to read all the tuples in the target tuple centre
set to overwrite the set of tuples in the target tuple centre

Coordination with TuCSoN: Basics Technology Overview
Outline
Model Language
Technology Overview
Core API Overview
Language Overview
Core API Overview
Uniform Primitives
7 TuCSoN: Advanced
Model Language
Advanced Features
8 ReSpecT: Advanced
Towards ReSpecTX

Defaults I
Many TuCSoN nodes can run on the same networked device, as long
as each one is listening on a diﬀerent TCP port
The default TCP port number of TuCSoN is 20504
⇒ so, agents can invoke operations of the form
tname @ netid ? op
(default @ localhost ? out(t(hi)))
Any other port can be used for a TuCSoN node (we will see how to
change it in a few slides)
The default tuple centre of a TuCSoN node is named default
⇒ so, agents can invoke operations of the form
@ netid : portno ? op
(@ localhost : 20504 ? out(t(hi)))

Defaults II
By combining defaults, the following invocations are also admissible
for any TuCSoN agent running on a device netid :
: portno ? op
invoking operation op on the default tuple centre of node
netid : portno
tname ? op
invoking operation op on the tname tuple centre of default node
netid : 20504
op
invoking operation op on the default tuple centre of default node
netid : 20504

Global vs. Local Coordination Space
TuCSoN global coordination space is defined by the collection of all
the tuple centres available on the network, identified by their full
name
⇒ a TuCSoN agent running on any networked device has the whole
TuCSoN global coordination space available for its coordination
operations through invocations of the form
tname @ netid : portno ? op
TuCSoN local coordination space is defined by the collection of all
the tuple centres available on all the TuCSoN nodes hosted by the
local device — let netid be its network address
⇒ a TuCSoN agent running on the same device (netid) can access the
local coordination space by invoking operations of the form
tname : portno ? op

Agent Coordination Context I
An Agent Coordination Context (ACC) [Omi02] is a runtime and stateful
interface
enabling an agent to execute coordination operations on the tuple
centres of a speciﬁc organisation– -e.g., TuCSoN system
constraining its admissible interactions
modelling RBAC in TuCSoN [ORV05a] — more on this in slide 193
Role of ACC
Along with tuple centres, ACC are the run-time abstraction that allows
TuCSoN to uniformly handle coordination, organisation, and security issues

Agent Coordination Context II
OrdinarySynchACC enables interaction with the ordinary tuple space
supporting a synchronous invocation semantics: whichever
the coordination operation invoked (either suspensive or
predicative), the agent blocks waiting for its completion
SpecificationAsynchACC enables interaction with the (ReSpecT)
speciﬁcation tuple space supporting an asynchronous
invocation semantics: whichever the coordination operation
invoked (either suspensive or predicative), the agent is
asynchronously notiﬁed upon completion
. . . . . .

Overview of TuCSoN ACCs

TuCSoN Middleware Overview
TuCSoN is a Java-based middleware (Java 7 is enough)
TuCSoN is also Prolog-based5: it is based on the tuProlog [DOR01]
Java-based technology for
first-order logic tuples
primitives identifiers
ReSpecT specification language virtual machine
TuCSoN middleware provides:
Java API for using TuCSoN coordination services from Java programs
package alice.tucson.api.* (mostly)
Prolog API for using TuCSoN coordination services from tuProlog
programs
5
Last digits in TuCSoN version number (TuCSoN-1.12.0.0301) are for the tuProlog
version, hence tuProlog version 3.0.1 atm

TuCSoN Service
A TuCSoN node can be started from a command prompt with:
java -cp tucson.jar:2p.jar alice.tucson.service.TucsonNodeService
[-port portno ]
The node is in charge of
listening to incoming invocations of coordination operations
dispatching them to the target tuple centre
returning the operations completion to the source agent
Let’s try!
1 Open a console, position yourself into the folder where tucson and 2p jars
are, then type the command above — on Windows, replace “:” with “;”
2 Try to launch another TuCSoN node on a diﬀerent portno

TuCSoN CLI I
The Command Line Interpreter is a shell interface for humans
java -cp tucson.jar:2p.jar
alice.tucson.service.tools.CommandLineInterpreter
[-netid netid ] [-port portno ] [-aid CLIname ]
Let’s try!
In the console, type the command above giving the same [-port portno ]
given for TuCSoN installation — on Windows, replace “:” with “;”

TuCSoN CLI II

TuCSoN CLI III
Let’s try!
1 Try out coordination operations
2 Try to suspend the CLI. . .
3 . . . and to resume it =)
4 Try to access each other TuCSoN nodes tuple centres — the global
coordination space
5 Try to spot invocation and completion phase of operations — look at
TuCSoN node console log

TuCSoN Inspector
GUI tool to monitor the TuCSoN coordination space ReSpecT VM
to launch the Inspector
java -cp tucson.jar:2p.jar alice.tucson.introspection.tools.InspectorGUI
available options are (also available from the GUI)
-aid — the name to assign to the inspector
-netid — the IP address where the TuCSoN node to inspect is
reachable. . .
-portno — . . . and its TCP listening port. . .
-tcname — . . . and the name of the tuple centre to monitor

Using TuCSoN Inspector I
Using the Inspector Tool I
If you launched it without specifying the full name of the target tuple
centre to inspect, do it from in the GUI

Using TuCSoN Inspector II
Using the Inspector Tool II
If you launched it giving the full name of the target tuple centre to
inspect, choose what to inspect

Using TuCSoN Inspector III
Monitoring of the coordination space is available through the Sets tab:
Sets tab
Tuple Space — the ordinary tuples space state
Specification Space — the (ReSpecT) specification tuples space state
Pending Ops — the pending TuCSoN operations set, that is, the set of
the operations already issued but currently suspended
(waiting for completion)
ReSpecT Reactions — the triggered (ReSpecT) reactions set, that is, the
set of those specification tuples triggered by the TuCSoN
operations issued

Using TuCSoN Inspector IV
Tuple Space view
Proactively observe the space state, thus getting any change of state,
or reactively do so, thus getting updates only when requested
Filter displayed tuples according to a given template — Filter tab
Log (ﬁltered) observations on a given log ﬁle — Log tab

Using TuCSoN Inspector V

Using TuCSoN Inspector VI
Specification Space view
Load a ReSpecT specification from a file. . .
. . . Edit Set it to the current tuple centre
Get the ReSpecT specification from the current tuple centre. . .
. . . Save it to a given file (or to the default one named default.rsp)

Using TuCSoN Inspector VII

Using TuCSoN Inspector VIII
Pending Ops view
Proactively or reactively observe pending TuCSoN operations
Filter displayed TuCSoN operations according to a given template —
Filter tab
Log (ﬁltered) observations on a given log ﬁle — Log tab

Using TuCSoN Inspector IX

Using TuCSoN Inspector X
ReSpecT Reactions view
In the ReSpecT Reactions view you are notified on the outcome of any
ReSpecT reaction triggered in the observed tuple centre, and can log such
notifications on a given log file

Using TuCSoN Inspector XI
Interaction with the ReSpecT VM is available through the StepMode tab:
StepMode tab
The tuple centre working cycle is paused
No further processing of incoming events, pending queries, triggering
reactions is done
ReSpecT VM performs transitions between its states only upon
pressing of the Next Step button
! one ReSpecT event is processed at each step

Using TuCSoN Inspector XII

Using TuCSoN Inspector XIII
The radio buttons under the Next Step button let the inspector
choose which point of view to keep while inspecting the tuple centre:
while adopting the tuple centre standpoint, all the Inspector views are
updated at each state transition — e.g., in the middle of a reaction
execution
while adopting the agents standpoint, Inspector views are updated only
when a complete VM cycle has been done — that is, from “idle” state
back into it

Coordination with TuCSoN: Basics Core API Overview
Outline
Model Language
Technology Overview
Core API Overview
Language Overview
Core API Overview
Uniform Primitives
7 TuCSoN: Advanced
Model Language
Advanced Features
8 ReSpecT: Advanced
Towards ReSpecTX

Use TuCSoN as a Library
To enable a Java application to use the TuCSoN technology:
1 build a TucsonAgentId to be identiﬁed by the TuCSoN system
2 get a TuCSoN ACC to enable interaction with the TuCSoN system
3 deﬁne the tuple centre target of your coordination operations
4 build a tuple using the communication language
5 perform the coordination operation using a coordination primitive
6 check requested operation success
7 get requested operation result
Let’s try!
Launch Java class HelloWorld in package alice.tucson.examples.helloWorld
within TuCSoN distribution and check out code comments

Use TuCSoN as a Framework
To create a TuCSoN agent, do the following:
1 extend alice.tucson.api.TucsonAgent base class
2 choose one of the given constructors
3 override the main() method with your agent business logic
4 get your ACC from the super-class
5 do what you want to do following steps 3 − 7 from previous slide
6 instantiate your agent and start its execution cycle (main()) by using
method go()
Let’s try!
Launch Java class HelloWorldAgent in package
alice.tucson.examples.helloWorld within TuCSoN distribution and check
out code comments

API Walkthrough I
Package alice.tucson.api
Most of the API is made available through package alice.tucson.api
TucsonAgentId — exposes methods to build a TuCSoN agent ID, and
to access its fields. Required to obtain an ACC
getAgentName(): String — to get the local agent name
TucsonMetaACC — provides TuCSoN agents with a meta-ACC,
necessary to acquire an ACC, which in turn is mandatory to interact
with a TuCSoN tuple centre
getAdminContext(TucsonAgentId, String, int, String, String): AdminACC —
to get an administrator ACC from the (specified) TuCSoN node
getNegotiationContext(TucsonAgentId, String, int): NegotiationACC — to get
a negotiation ACC from the (specified) TuCSoN node

API Walkthrough II
TucsonTupleCentreId — exposes methods to build a TuCSoN tuple
centre ID, and to access its ﬁelds. Required to perform TuCSoN
operations on the ACC
getName(): String — to get the tuple centre local name
getNode(): String — to get the tuple centre host’s (TuCSoN node) IP number
getPort(): int — to get the tuple centre host’s (TuCSoN node) TCP port number
ITucsonOperation — exposes methods to access the result of a
TuCSoN operation
isResultSuccess(): boolean — to check operation success
getLogicTupleResult(): LogicTuple — to get operation result

API Walkthrough III
AbstractTucsonAgent — base abstract class for user-defined TuCSoN
agents. Automatically builds the TucsonAgentId and gets an the
EnhancedACC
main(): void — to be overridden with the agent’s business logic
getContext(): EnhancedACC — to get the ACC for the user-defined agent
go(): void — to start main execution of the user-defined agent
AbstractSpawnActivity — base abstract class for user-defined
activities to be spawned by a spawn operation — more on this in
slide 177. Provides a simplified syntax for TuCSoN operation
invocations
doActivity(): void — to override with the spawned activity’s business logic
out(LogicTuple): LogicTuple — out TuCSoN operation bound to local tuple centre
. . . . . .

API Walkthrough IV
Tucson2PLibrary — allows tuProlog agents to access the TuCSoN
platform by exposing methods to manage ACC, and to invoke
TuCSoN operations
acquire acc 1(Struct): boolean — to get an ACC for the tuProlog agent
out 2(Term, Term): boolean — out TuCSoN operation
. . . . . .
Furthermore. . .
Package alice.tucson.api contains also all the ACC provided by the
TuCSoN platform, among which EnhancedACC — those depicted in slide 52

API Walkthrough V
Package alice.logictuple
The part of TuCSoN API concerned with managing tuples is made
available through package alice.logictuple
LogicTuple — exposes methods to build a TuCSoN tuple/template
and to get its arguments
parse(String): LogicTuple — to encode a given string into a TuCSoN
tuple/template
getName(): String — to get the functor name of the tuple
getArg(int): TupleArgument — to get the tuple argument at given position

API Walkthrough VI
TupleArgument — represents TuCSoN tuples arguments (tuProlog
terms), and provides the means to access them
parse(String): TupleArgument — to encode the given string into a tuProlog tuple
argument
getArg(int): TupleArgument — to get the tuple argument at given position
isVar(): boolean — to test if the tuple argument is a tuProlog Var
intValue(): int — to get the int value of the tuple argument — if admissible
. . . . . .

API Walkthrough VII
Package alice.tucson.service
The API to programatically boot kill a TuCSoN service is provided by
class TucsonNodeService in package alice.tucson.service
constructors to set-up the TuCSoN service
methods to install, shutdown, and test installation of the TuCSoN
service
install(): void
shutdown(): void
isInstalled(String, int, int): boolean
entry point to launch a TuCSoN node from the command line

The API in Practice
Package alice.tucson.examples.*
.helloWorld package
.messagePassing package
.rpc package
.masterWorkers package

Coordination with ReSpecT: Basics
Outline
7 TuCSoN: Advanced
8 ReSpecT: Advanced

Coordination with ReSpecT: Basics Model Virtual Machine
Outline
Model Language
Technology Overview
Core API Overview
Language Overview
Core API Overview
Uniform Primitives
7 TuCSoN: Advanced
Model Language
Advanced Features
8 ReSpecT: Advanced
Towards ReSpecTX

Meta-Coordination Language
TuCSoN meta-coordination operations are built out of
meta-coordination primitives and of ReSpecT specification languages
the specification language
the specification template language
In TuCSoN, both the specification and the specification template
languages are logic-based, and defined by ReSpecT
any ReSpecT reaction is an admissible TuCSoN specification tuple. . .
. . . and an admissible TuCSoN specification template
⇒ the two languages coincide

Meta-Coordination Operations
Any TuCSoN meta-coordination operation is invoked by a source
agent on a target tuple centre, which is in charge of its execution
invocation phase — the request of the agent reaches the tuple
centre, decorated with information about the invocation
completion phase — the response of the tuple centre goes back to
the agent, including information about operation
execution outcome
The abstract syntax of a meta-coordination operation op s invoked
on a target tuple centre tcid is
tcid ? op s
tname @ netid : portno ? op s
default @ localhost : 20504 ? out s(E ,G ,R )

Meta-Coordination Primitives
The TuCSoN meta-coordination language provides the following
meta-coordination primitives to build meta-coordination operations:
out s to put a specification tuple in the specification space of the
target tuple centre (tc)
rd s, rdp s to read a specification tuple matching a given specification
template from the target tc
in s, inp s to withdraw a specification tuple matching a given
specification template from the target tc
no s, nop s to check absence of a specification tuple matching a given
specification template in the target tc
get s to read all the specification tuples in the target tc
set s to overwrite the set of specification tuples in the target tc

Reaction Specification Tuples (ReSpecT)
As a behaviour specification language, ReSpecT
enables definition of computations within a tuple centre (reactions)
! sequences of logic predicates and functions, and ReSpecT primitives,
executing (as a whole) atomically and transactionally, with a global
success/failure semantics
enables association of reactions to events occurring in a tuple centre
⇒ given a ReSpecT event Ev , a specification tuple reaction(E ,G ,R )
associates a reaction Rθ to Ev if and only if θ = mgu(E,Ev )6
and
guard predicate G evaluates to true [Omi07]
ReSpecT twofold interpretation
So, ReSpecT has both a declarative and a procedural part
6
Where mgu is the most general unifier, as defined in logic programming

Reactions Semantics
A ReSpecT reaction succeeds if and only if all its reaction goals
succeed, and fails otherwise
Each reaction is executed with a transactional semantics
⇒ hence, a failed reaction has no eﬀect on the state of the tuple centre
Sequences of reactions are executed sequentially, according to a
non-deterministic order,
(Sequences of) reactions are executed atomically, that is, before
serving other ReSpecT events
⇒ thus, agents are transparent both to reactions chaining, and to multiple
reactions triggering for the same event

ReSpecT VM Execution Cycle I
Whenever the invocation of a primitive by either an agent or a tuple centre
is performed
Invocation
1 an (admissible) ReSpecT event is generated and. . .
2 . . . reaches its (the primitive) target tuple centre. . .
3 . . . where it is orderly inserted in a sort of input queue (InQ)

ReSpecT VM Execution Cycle II
When the tuple centre is idle, that is, no reaction is executing
Triggering
1 the ﬁrst event in InQ, according to a FIFO policy, is moved to the
multiset Op of the pending requests
2 consequently, reactions to the invocation phase of are triggered by
adding them to the multiset Re of the triggered reactions
3 then, those reactions whose guard predicates evaluate to true are
scheduled for execution, while others are removed from Re
4 ﬁnally, reactions still in Re are executed — sequentially,
non-deterministic order

ReSpecT VM Execution Cycle III
Chaining linking
Each reaction may trigger
further reactions, orderly added to Re
output events, representing link invocations, which are
1 added to the multiset Out of the outgoing events
2 then moved to the output queue (OutQ) of the tuple centre — if and
only if reaction execution is successful

ReSpecT VM Execution Cycle IV
Completion
Only when Re is empty
1 pending requests in Op are (possibly) executed
2 operation/link completions are sent back to invokers
[!] Further reactions may be raised accordingly, associated to the
completion phase of the original invocation, and executed with the same
semantics speciﬁed above for the invocation phase.

Familiarise with ReSpecT I
Let’s try!
1 Launch a TuCSoN node on default port
2 Launch TuCSoN Inspector tool — that is, class InspectorGUI in
package alice.tucson.introspection.tools
3 Inspect the bagoftask tuple centre on the node
4 Activate “Step Mode” in the “StepMode” tab
5 Launch class BagOfTaskTest in package
alice.tucson.examples.respect.bagOfTask
6 Click “Next Step” on the Inspector to proceed through ReSpecT
VM’s execution cycle

Malleability of ReSpecT Tuple Centres
The behaviour of a ReSpecT tuple centre is thus defined by the
ReSpecT tuples in the specification space
and it can be adapted by changing its ReSpecT specification at
run-time
⇒ ReSpecT tuple centres are thus malleable
by engineers, via TuCSoN tools — CLI Inspector
by processes, via in s out s primitives
in out for the tuple space; in s out s for the specification space
through either an agent coordination primitive, or another tuple centre
link operation

Familiarise with ReSpecT II
Let’s try!
Look into the code of the Master class in package
alice.tucson.examples.respect.bagOfTask to see
usage of meta-coordination operations (therefore, primitives) at
run-time
structure of ReSpecT speciﬁcation tuples
If you wish, change / add / remove invocations and see what happens
:)

Linkability of ReSpecT Tuple Centres
Every tuple centre coordination primitive is also a ReSpecT primitive
for reaction goals (“internal”), and a primitive for linking, too
all primitives could be executed within a ReSpecT reaction
as either an internal primitive on the same tuple centre
or as a link primitive invoked upon another tuple centre
linking primitives are asynchronous — as agent ones
⇒ so they do not aﬀect the transactional semantics of reactions
reactions can handle both primitive invocations completions
ReSpecT tuple centres are linkable
by using tuple centre identiﬁers within ReSpecT reactions. . .
. . . any ReSpecT reaction can invoke any coordination primitive upon
any tuple centre in the network7
Hold on
Examples showcasing ReSpecT linkability feature are available later on :)
7
The TuCSoN infrastructure is used for distributing ReSpecT tuple centres

Coordination with ReSpecT: Basics Language Overview
Outline
Model Language
Technology Overview
Core API Overview
Language Overview
Core API Overview
Uniform Primitives
7 TuCSoN: Advanced
Model Language
Advanced Features
8 ReSpecT: Advanced
Towards ReSpecTX

ReSpecT Syntax: Basics
ReSpecT tuple centres adopt logic tuples for both ordinary tuples and
specification tuples
Ordinary tuples are simple first-order logic (FOL) facts, written with a
Prolog syntax
Specification tuples are logic tuples of the form reaction(E,G,R)
if event Ev occurs in the tuple centre
if Ev matches event descriptor E such that θ = mgu(E,Ev)
if guard G evaluates to true
⇒ reaction Rθ is triggered for execution

ReSpecT Syntax: Behaviour Specification
Reference example
We use table.rsp ReSpecT specification in package
alice.tucson.examples.diningPhilos as our running example to back up
description of the ReSpecT language following in next slides
Specification ::= { SpecificationTuple .}
SpecificationTuple ::= reaction( Event , Guard , ReactionBody )
Guard ::= GuardPredicate | ( GuardPredicate {, GuardPredicate } )
ReactionBody ::= ReactionGoal | ( ReactionGoal {, ReactionGoal } )
A behaviour specification Specification is a logic theory of FOL
tuples reaction/3
A specification tuple contains an event descriptor Event , a guard
Guard , and a sequence ReactionBody of ReactionGoal s

ReSpecT Syntax: Event Descriptor
Event ::= Predicate ( Tuple ) | . . .
The simplest event descriptor Event is the invocation of a primitive
Predicate ( Tuple )
An event descriptor Event works as a event template for matching
with admissible events

ReSpecT Syntax: Admissible Events
TCEvent ::= OpEvent | . . .
OpEvent ::= OpStartCause , OpEventCause , OpResult
OpStartCause ::= CoordOp , AgentId , TCId
OpEventCause ::= OpStartCause | LinkOp , TCId , TCId
OpResult ::= Tuple , . . .
A ReSpecT admissible event includes its prime cause StartCause , its direct cause
EventCause , and the Result of the tuple centre activity
prime and direct cause may coincide — such as when a process invocation reaches
its target tuple centre
or, they might be different — such as when a link primitive is invoked by a tuple
centre reacting to a process’ primitive invocation upon another tuple centre
the result is undefined in the invocation stage: it is defined in the completion stage
A reaction(E,G,R) and an admissible event match if E unifies with the
CoordOp | LinkOp part of . OpEventCause

Event Model vs. Event Representation
Notice
Understanding the diﬀerence between admissible events TCEvent and
event descriptors Event is essential to understand the main issues of
pervasive systems
admissible events are how we capture and model relevant events: essentially, our
ontology for events
event descriptors are how we write about events: essentially, our language for
events
Role of Coordination Media
The ReSpecT VM is where the two things clash, and is exactly based on
that: it’s how we capture and observe events, and how we react to them
! this is an essential point in any technology dealing with situated
computations!

ReSpecT Syntax: Guards
Guard ::= GuardPredicate |
( GuardPredicate {, GuardPredicate } )
GuardPredicate ::= request | response | success | failure
endo | exo | intra | inter
from_agent | to_agent | from_tc | to_tc | . . .
A triggered reaction is actually executed only if its guard evaluates to true
All guard predicates are ground ones
Guard predicates concern properties of the triggering event, so they enable
ﬁne-grained selection of events

ReSpecT Syntax: Reactions Body II
A reaction goal is either a primitive invocation – possibly, a link –, a
predicate recovering properties of the event, or some logic-based
computation
! Sequences of reaction goals are executed atomically and
transactionally, with an overall success / failure semantics
Tuple centre predicates are uniformly used for agent invocations,
internal operations, and link invocations
Similar predicates are used for changing the specification state
pred s invocations affect the specification state, and can be used
within reactions, also as links

ReSpecT Syntax: Observation Predicates I
ObservationPredicate ::= EventView _ EventInformation
EventView ::= current | event | start
EventInformation ::= predicate | tuple | source | target | . . .
event start refer to direct and prime cause, respectively
current refers to what is currently happening, whenever this means
something useful — e.g., current predicate is not so useful =)

ReSpecT Syntax: Observation Predicates II
Any combination of the following is admissible in ReSpecT
EventView — allow to inspect the events chain triggering the executing
reaction:
current — access the ReSpecT event currently under processing
event — access the ReSpecT event which is the direct cause
of the event triggering the reaction
start — access the ReSpecT event which is the prime cause
of the event triggering the reaction
EventInformation — allow to inspect all the data ReSpecT events make
observable:
predicate — the ReSpecT primitive causing the event
tuple — the logic tuple argument of the predicate
source — who performed the predicate
target — who is directed to the predicate
time — when the predicate was issued

Usage Example: Dining Philos I
philosopher(I,J) :-
think, % thinking
table ? in(chops(I,J)), % waiting to eat
eat, % eating
table ? out(chops(I,J)), % waiting to think
Results
+ fairness, no deadlock
+ trivial philosopher’s interaction protocol
? shared resources handled properly?
? starvation still possible?

Usage Example: Dining Philos II
reaction( out(chops(C1,C2)), (operation, completion), ( % (1)
in(chops(C1,C2)), out(chop(C1)), out(chop(C2)) )).
reaction( in(chops(C1,C2)), (operation, invocation), ( % (2)
out(required(C1,C2)) )).
reaction( in(chops(C1,C2)), (operation, completion), ( % (3)
in(required(C1,C2)) )).
reaction( out(required(C1,C2)), internal, ( % (4)
in(chop(C1)), in(chop(C2)), out(chops(C1,C2)) )).
reaction( out(chop(C)), internal, ( % (5)
rd(required(C,C2)), in(chop(C)), in(chop(C2)),
out(chops(C,C2)) )).
reaction( out(chop(C)), internal, ( % (5’)
rd(required(C1,C)), in(chop(C1)), in(chop(C)),
out(chops(C1,C)) )).

Usage Example: Dining Philos III
Results
protocol no deadlock
protocol fairness
protocol trivial philosopher’s interaction protocol
tuple centre shared resources handled properly
:( starvation still possible
Keep starvation in mind. . .
. . . later on we will ﬁx the issue, using ReSpecT :)

Coordination with ReSpecT: Basics Core API Overview
Outline
Model Language
Technology Overview
Core API Overview
Language Overview
Core API Overview
Uniform Primitives
7 TuCSoN: Advanced
Model Language
Advanced Features
8 ReSpecT: Advanced
Towards ReSpecTX

TuCSoN API for ReSpecT
Uniform w.r.t. TuCSoN API to access the ordinary tuple space:
1 build a TucsonAgentId
2 get a TuCSoN ACC enabling access to ReSpecT specification space
3 define the tuple centre target of your meta-coordination operations
4 build a specification tuple using the meta-communication language
LogicTuple event = LogicTuple.parse(out(t(X)));
LogicTuple guards = LogicTuple.parse((completion, success));
LogicTuple reaction = LogicTuple.parse((in(t(X)),
out(tt(X))));
5 perform the meta-coordination operation using a meta-coordination
primitive
ITucsonOperation op = acc.out s(tcid, event, guards, reaction,
null);
6 check requested operation success
7 get requested operation result

ReSpecT API
Full ReSpecT API
Class Respect2PLibrary in package alice.respect.api implements all
predicates available within ReSpecT reactions, including observation
predicates, and also guards

API Examples
Let’s try!
Check out examples in package alice.tucson.examples.*
1 .respect.bagOfTask
2 .diningPhilos
3 .distributedDiningPhilos — linking primitives here

Tuple-based Coordination of Situated Systems
Outline
7 TuCSoN: Advanced
8 ReSpecT: Advanced

Tuple-based Coordination of Situated Systems Coordination in the Spatio-Temporal Fabric
Outline
Model Language
Technology Overview
Core API Overview
Language Overview
Core API Overview
Uniform Primitives
7 TuCSoN: Advanced
Model Language
Advanced Features
8 ReSpecT: Advanced
Towards ReSpecTX

Situatedness in the Spatio-Temporal Fabric I
What is Situatedness?
Situatedness is essentially the property of systems of being immersed
in their environment
⇒ That is, of being capable to perceive and produce environment
change, by suitably dealing with environment events
Mobile, adaptive, and pervasive computing systems have emphasised
the key role of situatedness for nowadays computational systems
[ZCF+11]

Situatedness in the Spatio-Temporal Fabric II
Situatedness of computational systems nowadays requires at least
awareness of the spatio-temporal fabric
⇒ that is, any non-trivial system needs to know where it is working, and
when, in order to eﬀectively perform its function
In its most general acceptation, then, any environment for a
computational systems is ﬁrst of all made of space and time
Space time vs. coordination
Why, and to which extent, is this a coordination issue?
Why, and to which extent, is this a tuple-based coordination issue?

Dining Philos in ReSpecT: How to Fix Starvation?
! The problem is time: no one keeps track of time here, and starvation
is a matter of time
? How can we handle time here? Is synchronisation not enough for the
purpose?
Of course not: to avoid problems like starvation, we need the ability
of deﬁning time-dependent coordination policies
What is the solution?
⇒ In order to deﬁne time-dependent coordination policies, a time-aware
coordination medium is needed

Time-aware Coordination Media I
A time-aware coordination medium should satisfy the following
requirements [ORV07]:
1 Time has to be an integral part of the ontology of a coordination
medium
2 (Physical) time has to be explicitly embedded into the coordination
medium working cycle
3 A coordination medium should allow coordination policies to talk
about time
4 A coordination medium should be able to capture time events, and to
react appropriately
5 A coordination medium should allow coordination policies to be
changed over time

Time-aware Coordination Media II
Physical time in the medium ontology working cycle (reqs. 1, 2)
1 Time has to be an integral part of the ontology of a coordination medium
2 (Physical) time has to be explicitly embedded into the coordination medium working cycle
ReSpecT admissible event model is extended to include time. For
instance, in the case of OpEvent :
OpStartCause ::= CoordOp , AgentId , TCId , Time
OpEventCause ::= OpStartCause |
LinkOp , TCId , TCId , Time
Since every ReSpecT VM executes on a sequential machine, making
an expression of physical time available. . .
⇒ . . . at every transition of the ReSpecT VM, physical time is always
available to any ReSpecT computation

Time-aware Coordination Media III
Coordination policies: talking about time (req. 3)
3 A coordination medium should allow coordination policies to talk about time
ReSpecT observation predicates are extended with time:
EventInformation ::= . . . | time | . . .
Two ReSpecT guard predicates are introduced:
GuardPredicate ::= . . . | before( Time ) | after( Time ) | . . .
along with the obvious alias
between( Time , Time )

Time-aware Coordination Media IV
Capturing time events (req. 4)
4 A coordination medium should be able to capture time events, and to react appropriately
The ReSpecT admissible event model is extended to include time
events:
TCEvent ::= OpEvent | TEvent | . . .
TEvent ::= TStartCause , TEventCause , TResult , Time
TStartCause ::= TOp ,time, TCId
TEventCause ::= TStartCause
TOp ::= time( Time )
TResult ::= TOp , . . .
Correspondingly, the ReSpecT event descriptor is extended, too:
Event ::= Predicate ( Tuple ) | time( Time ) | . . .
making it possible to specify reactions to time events:
reaction(time(@Time), Guard, Body).

Time-aware Coordination Media V
Changing coordination policies over time (req. 5)
5 A coordination medium should allow coordination policies to be changed over time
It is enough to exploit malleabilty of ReSpecT tuple centres
exploiting the same ForgePredicate s that can be used for dynamically
change tuple centre behaviour at run time
such as in_s, out_s, . . .

Timed Dining Philosophers: Philosopher
philosopher(I,J) :-
think, % thinking
table ? in(chops(I,J)), % waiting to eat
eat, % eating
table ? out(chops(I,J)), % waiting to think
With respect to Dining Philosopher’s protocol. . .
. . . this is left unchanged — and this is very convenient!

Timed Dining Philos: table ReSpecT Code
reaction( out(chops(C1,C2)), (operation, completion), ( % (1)
in(chops(C1,C2)) )).
reaction( out(chops(C1,C2)), (operation, completion), ( % (1’)
in(used(C1,C2,_)), out(chop(C1)), out(chop(C2)) )).
reaction( in(chops(C1,C2)), (operation, invocation), ( % (2)
out(required(C1,C2)) )).
in(required(C1,C2)) )).
reaction( out(required(C1,C2)), internal, ( % (4)
in(chop(C1)), in(chop(C2)), out(chops(C1,C2)) )).
reaction( out(chop(C)), internal, ( % (5)
rd(required(C,C2)), in(chop(C)), in(chop(C2)), out(chops(C,C2)) )).
reaction( out(chop(C)), internal, ( % (5’)
rd(required(C1,C)), in(chop(C1)), in(chop(C)), out(chops(C1,C)) )).
current_time(T), rd(max eating time(Max)), T1 is T + Max,
out(used(C1,C2,T)),
out_s(time(T1),(in(used(C1,C2,T)), out(chop(C1)), out(chop(C2)))) )).

Timed Dining Philosophers in ReSpecT: Results
Results
protocol no deadlock
protocol fairness
protocol trivial philosopher’s interaction protocol
tuple centre shared resources handled properly
tuple centre no starvation
Let’s try!
Checkout example TDiningPhilosophersTest in package
alice.tucson.examples.timedDiningPhilos

What About Coordination Space?
The availability of a plethora of mobile devices is pushing forward the
needs for space-awareness of computations and systems
often essential to establish which tasks to perform, which goals to
achieve, and how
More generally, spatial issues are fundamental in many sorts of
complex software systems, including adaptive, and self-organising
ones [Bea10]
Space-aware Coordination
In most of the application scenarios where situatedness plays an essential
role, computation and coordination are required to be space aware

Situatedness Awareness I
Requirements
spatial situatedness
spatial awareness
(of the coordination media)

Situatedness Awareness II
Situatedness
A space-aware coordination abstraction should at any time be associated
to an absolute positioning, both physical and virtual
In fact
software abstractions may move along a virtual space – typically, the
network – which is usually discrete
whereas hardware devices move through a physical space, which is
mostly continuous
! However, software abstractions may also be hosted by mobile physical
devices, thus share their motion

Situatedness Awareness III
Awareness
The position of the coordination medium should be available to the
coordination laws it contains in order to make them capable of reasoning
about space — thus, to implement space-aware coordination laws
Also, space has to be embedded into the working cycle of the coordination
medium:
a spatial event should be generated within a coordination medium,
conceptually corresponding to changes in space
then, such events should be captured by the coordination medium,
and used to activate space-aware coordination laws

Space-aware Coordination Medium: Requirements
Situatedness: Requirements
1 Space should intrinsically belong to the ontology of the coordination
medium, in terms of position and motion
2 Both virtual and physical space acceptations should be supported
3 A notion of locality should be made available
Awareness: Requirements
4 A coordination medium should allow coordination policies to talk
about space
5 A coordination medium should be able to capture spatial events, and
to react appropriately

ReSpecT Tuple Centres as Space-aware Media I
Space in medium ontology working cycle (reqs. 1, 2)
1 Space has to be an integral part of the ontology of a coordination medium
2 Both physical virtual position motion have to be explicitly embedded into the
coordination medium working cycle
ReSpecT admissible event model is extended to include space —
physical virtual. For instance, in the case of OpEvent :
OpStartCause ::= CoordOp , AgentId , TCId , Time , Space:Place
OpEventCause ::= OpStartCause |
LinkOp , TCId , TCId , Time , Space:Place
Since every ReSpecT VM executes on a physical (networked)
machinery, making an expression of positioning available. . .
→ . . . at every transition of the ReSpecT VM, physical virtual
positioning is always available to any ReSpecT computation

ReSpecT Tuple Centres as Space-aware Media II
Locality in ReSpecT (with TuCSoN) (req. 3)
3 A notion of locality should be made available
ReSpecT tuple centres have unique identities within a TuCSoN node
Any CoordOp / LinkOp can refer to a tuple centre identiﬁer,
relying on the local TuCSoN node as the default local (coordination)
space
Adding a node reference to a CoordOp / LinkOp shifts everything
to the global (coordination) space
! This, however, is just a notion of virtual locality

ReSpecT Tuple Centres as Space-aware Media III
Coordination policies: talking about space (req. 4)
4 A coordination medium should allow coordination policies to talk about space
ReSpecT observation predicates are extended with physical virtual
space:
EventInformation ::= . . . | place( Space:Place ) | . . .
Three ReSpecT guard predicates are introduced:
GuardPredicate ::= . . . | at( Space:Place ) | near( Space:Place , Radius ) | . . .

ReSpecT Tuple Centres as Space-aware Media IV
Capturing spatial events (req. 5)
5 A coordination medium should be able to capture spatial events, and to react appropriately
ReSpecT admissible event model is extended to include spatial events
TCEvent ::= OpEvent | TEvent | SEvent | . . .
SEvent ::= SStartCause , SEventCause , SResult ,
Time , Space:Place
SStartCause ::= SOp ,space, TCId
SEventCause ::= SStartCause
SOp ::= from( Space:Place ) | to( Space:Place )
SResult ::= SOp , . . .

ReSpecT Tuple Centres as Space-aware Media V
Capturing spatial events (req. 5 – contd.)
Correspondingly, ReSpecT event descriptor is extended, too
Event ::= Predicate ( Tuple ) | time( Time ) |
from( Space:Place ) | to( Space:Place ) | . . .
thus making it possible to specify reactions to the occurrence of
spatial events
reaction(from(@S,?P), Guard, Body).
reaction(to(@S,?P), Guard, Body).

Sorts of Space
It should be noted that the tuple centre position P can be specified as
either
S = ph its absolute physical position
S = ip its IP number
S = dns its domain name
S = map its geographical location — as typically defined by mapping
services like Google Maps
S = org its organisational position — that is, a location within an
application-defined virtual topology

Space-aware Middleware: TuCSoN on Android I

Space-aware Middleware: TuCSoN on Android II

Space-aware Middleware: TuCSoN on Android III

Space-aware Middleware: TuCSoN on Android IV
References
Codebase:
https://bitbucket.org/smariani/tucsonandroid/overview

Tuple-based Coordination of Situated Systems Coordination in the Computational / Physical Environment
Outline
Model Language
Technology Overview
Core API Overview
Language Overview
Core API Overview
Uniform Primitives
7 TuCSoN: Advanced
Model Language
Advanced Features
8 ReSpecT: Advanced
Towards ReSpecTX

Situatedness Coordination
Situatedness means, essentially, strict coupling with the environment
technically, the ability to properly perceive and react to changes in the
environment — possibly, aﬀecting it in turn
One of the most critical issues in distributed systems
! conceptual clash (w.r.t. autonomy) between pro-activeness in process
behaviour and reactivity w.r.t. environment change
Still a critical issue for artiﬁcial intelligence robotics [Suc87]
What about coordination?
Essentially, situatedness concerns interaction between processes and the
environment
⇒ thus, situatedness can be conceived as a coordination problem
? how to handle and govern interaction between pro-active processes and
an ever-changing environment?

Situating ReSpecT
Situating ReSpecT
Situating the ReSpecT language basically means making ReSpecT
capable of capturing environment events, and expressing general
MAS-environment interactions [CO09]
ReSpecT captures, reacts to, and observes general environment events
ReSpecT can explicitly interact with (aﬀect) the environment

ReSpecT Tuple Centres as Environment-aware Media I
Coordination policies: talking about environment
1 A coordination medium should allow coordination policies to talk about environment
ReSpecT observation predicates are extended with the environment:
EventInformation ::= . . . | env( Key , Value )
Two ReSpecT guard predicates are introduced:
GuardPredicate ::= . . . | from_env | to_env

ReSpecT Tuple Centres as Environment-aware Media II
Capturing general environment events
2 A coordination medium should be able to capture environment events, and to react
appropriately
The ReSpecT admissible event model is extended to include
environment events
TCEvent ::= OpEvent | TEvent | SEvent | EEvent . . .
EEvent ::= EStartCause , EEventCause , EResult ,
Time , Space:Place
EStartCause ::= EOp , EResId , TCId
EDirectCause ::= EStartCause
EOp ::= env( Key , Value )
EResult ::= EOp , . . .

ReSpecT Tuple Centres as Environment-aware Media III
Capturing general environment events (contd.)
Correspondingly, ReSpecT event descriptor is extended, too
Event ::= Predicate ( Tuple ) | time( Time ) |
from( Place ) | to( Place ) |
env( Key , Value )
making it possible to specify and associate reactions to the
occurrence of environment events
reaction(env(?Key,?Value), Guard, Body).

Transducers as Environment Mediators I
Source and target of a tuple centre event can be any external
resource
⇒ a suitable identiﬁcation scheme – both at the syntax and at the
infrastructure level – is introduced for environmental resources
The ReSpecT language is extended to express explicit manipulation of
environmental resources
⇒ the body of a ReSpecT reaction can contain a situation predicate of
the form
EResId ? get( Key , Value )
enabling a tuple centre to get properties of environmental resources
EResId ? set( Key , Value )
enabling a tuple centre to set properties of environmental resources

Advanced Coordination Techniques: Experiments with TuCSoN and ReSpecT

Advanced Coordination Techniques: Experiments with TuCSoN and ReSpecT

Recommended

Recommended

More Related Content

Similar to Advanced Coordination Techniques: Experiments with TuCSoN and ReSpecT

Similar to Advanced Coordination Techniques: Experiments with TuCSoN and ReSpecT (20)

More from Stefano Mariani

More from Stefano Mariani (20)

Recently uploaded

Recently uploaded (20)

Advanced Coordination Techniques: Experiments with TuCSoN and ReSpecT