Changes for page Overview

From version 1.1
edited by Andrea Omicini
on 08/10/2020 00:28
Change comment: Imported from XAR
To version 4.1
edited by Andrea Omicini
on 10/08/2021 16:42
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Overview
1 +ReSpecT Overview
Syntax
... ... @@ -1,1 +1,1 @@
1 -XWiki 1.0
1 +XWiki 2.1
Content
... ... @@ -1,58 +1,56 @@
1 -#includeMacros("Main.MacroSheet")
1 +{{include document="Main.MacroSheet"/}}{{velocity}}
2 +* #respect() (**Re**action **Spec**ification **T**uples) is a logic-based language for the coordination of complex software systems.
3 +* #respect() promotes a coordination model providing tuple centres as programmable, general-purpose coordination media.
4 +* the behaviour of #respect() tuple centres is programmed through the #respect() first-order logic language.
2 2  
3 -1 #respect() Overview
6 +== The #respect() Tuple Centre Coordination Model ==
4 4  
5 -#respect() (*Re*action *Spec*ification *T*uples) is a logic-based language for the coordination of complex software systems.
6 -##
7 -#respect() promotes a coordination model providing tuple centres as programmable, general-purpose coordination media.
8 -##
9 -The behaviour of #respect() tuple centres is programmed through the #respect() first-order logic language.
10 -
11 -1.1 The #respect() Tuple Centre Coordination Model
12 -
13 13  A tuple centre is a tuple space enhanced with the possibility to program its behaviour in response to interactions.
14 14  ##
15 -First of all, coordinated entities (~~#respect() agents~~, henceforth, or simply ~~agents~~) can operate on a #respect() tuple centre in the same way as on a standard Linda tuple space: by exchanging ~~tuples~~ — which are ordered collection of knowledge chunks — through a simple set of coordination primitive.
10 +First of all, coordinated entities (//#respect() agents//, henceforth, or simply //agents//) can operate on a #respect() tuple centre in the same way as on a standard Linda tuple space: by exchanging //tuples// — which are ordered collection of knowledge chunks — through a simple set of coordination primitive.
16 16  ##
17 17  So, an agent can write a tuple in a tuple centre with an #code("out") primitive; or read a tuple from a tuple centre with primitives such as #code("in"), #code("rd"), #code("inp"), #code("rdp") specifying a tuple template - that is, an identifier for a set of tuples, according to some tuple matching mechanism.
18 18  ##
19 19  Reading tuples can be
20 -* ~~destructive~~ — #code("in"), #code("inp") remove the matching tuple — or ~~non-destructive~~ — #code("rd"), #code("rdp") simply read the matching tuple
21 -* ~~suspensive~~ — #code("in"), #code("rd") wait until a matching tuple is found — or ~~non-suspensive~~ — #code("inp"), #code("rdp") immediately return either the matching tuple or a failure result
22 -but is anyway always ~~non-deterministic~~: when more than one tuple in a tuple centre are found that match a tuple template, one is non-deterministically chosen among them and returned.
23 -
15 +* //destructive// — #code("in"), #code("inp") remove the matching tuple — or //non-destructive// — #code("rd"), #code("rdp") simply read the matching tuple
16 +* //suspensive// — #code("in"), #code("rd") wait until a matching tuple is found — or //non-suspensive// — #code("inp"), #code("rdp") immediately return either the matching tuple or a failure result
17 +<p/>
18 +but is anyway always //non-deterministic//: when more than one tuple in a tuple centre are found that match a tuple template, one is non-deterministically chosen among them and returned.
19 +<p/>
24 24  Accordingly, a tuple centre enjoys all the many features of a tuple space, which can be classified along three different dimensions:
21 +
25 25  * generative communication
26 26  * associative access
27 27  * suspensive semantics
28 -
29 -The main features of ~~generative communication~~ (where information generated has an independent life with respect to the generator) are the forms of uncoupling (space, time, name) based on mediated interaction: sender and receiver do not need to know each other, to coexist in the same space or at the same time in order to communicate (to exchange a tuple, in particular), and more generally, to interact.
25 +<p/>
26 +The main features of //generative communication// (where information generated has an independent life with respect to the generator) are the forms of uncoupling (space, time, name) based on mediated interaction: sender and receiver do not need to know each other, to coexist in the same space or at the same time in order to communicate (to exchange a tuple, in particular), and more generally, to interact.
30 30  ##
31 -~~Associative access~~ (access based on structure and content of information exchanged, rather than on location, or on name) based on tuple matching promotes synchronisation based on tuple structure and content: thus, coordination is data-driven, and allows for knowledge-based coordination patterns.
28 +//Associative access// (access based on structure and content of information exchanged, rather than on location, or on name) based on tuple matching promotes synchronisation based on tuple structure and content: thus, coordination is data-driven, and allows for knowledge-based coordination patterns.
32 32  ##
33 -Finally, ~~suspensive semantics~~ promotes coordination patterns based on knowledge availability, and couples well with incomplete, partial knowledge.
34 -
35 -Even more, while the basic tuple centre model is independent of the type of tuple, #respect() tuple centres adopt logic tuples &mdash; both tuples and tuple templates are essentially Prolog ~~facts~~ &mdash; and logic ~~unification~~ is used as the tuple-matching mechanism.
30 +Finally, //suspensive semantics// promotes coordination patterns based on knowledge availability, and couples well with incomplete, partial knowledge.
31 +<p/>
32 +Even more, while the basic tuple centre model is independent of the type of tuple, #respect() tuple centres adopt logic tuples &mdash; both tuples and tuple templates are essentially Prolog //facts// &mdash; and logic //unification// is used as the tuple-matching mechanism.
36 36  ##
37 37  So, for instance, an agent #code("ag1") performing operation #code("we ? in(activity(ag1,CaseID))") on tuple centre #code("we") containing tuples #code("activity(ag1,c16)") and #code("activity(ag2,c22)") will be returned tuple #code("activity(ag1,c16)") &mdash; the one unifying with the template &mdash; removed from #code("we").
38 38  ##
39 -Since the overall content of a tuple centre is a multiset of logic facts, it has a twofold interpretation as either a collection of messages, or a (logic) ~~theory of communication~~ among agents &mdash; thus promoting in principle forms of ~~reasoning about communication~~.
40 -
41 -Finally, a tuple centre is a programmable tuple space, so as to add ~~programmability~~ of the coordination medium as a new dimension of coordination.
36 +Since the overall content of a tuple centre is a multiset of logic facts, it has a twofold interpretation as either a collection of messages, or a (logic) //theory of communication// among agents &mdash; thus promoting in principle forms of //reasoning about communication//.
37 +<p/>
38 +Finally, a tuple centre is a programmable tuple space, so as to add //programmability// of the coordination medium as a new dimension of coordination.
42 42  ##
43 43  While the behaviour of a tuple space in response to interaction events is fixed &mdash; so, the effects of coordination primitives is fixed &mdash;, the behaviour of a tuple centre can be tailored to the system needs by defining a set of specification tuples, or reactions, which determine how a tuple centre should react to incoming / outgoing events.
44 44  ##
45 45  While the basic tuple centre model is not bound to any specific language to define reactions, #respect() tuple centres are obviously programmed through the #respect() logic-based specification language.
46 46  
47 -1.1 #respect() as a Core Coordination Language
44 +== #respect() as a Core Coordination Language ==
48 48  
49 49  The original #respect() is a logic-based language for the specification of the behaviour of tuple centre.
50 50  ##
51 51  As a behaviour specification language, #respect():
52 52  
50 +
53 53  * enables the definition of computations within a tuple centre, called reactions, and
54 54  * makes it possible to associate reactions to events occurring in a tuple centre.
55 -
53 +<p/>
56 56  So, #respect() has both a declarative and a procedural part.
57 57  ##
58 58  As a specification language, it allows events to be declaratively associated to reactions by means of specific logic tuples, called specification tuples, whose form is #code("reaction(E,R)").
... ... @@ -64,7 +64,7 @@
64 64  A reaction as a whole succeeds if all its reaction goals succeed, and fails otherwise.
65 65  ##
66 66  Each reaction is executed sequentially with a transactional semantics: so, a failed reaction has no effect on the state of a logic tuple centre.
67 -
65 +<p/>
68 68  All the reactions triggered by an event are executed before serving any other event: so, agents perceive the result of serving the event and executing all the associated reactions altogether as a single transition of the tuple centre state.
69 69  ##
70 70  As a result, the effect of a coordination primitive on a logic tuple centre can be made as complex as needed by the coordination requirements of a system.
... ... @@ -72,10 +72,11 @@
72 72  Generally speaking, since #respect() has been shown to be Turing-equivalent, any computable coordination law could be in principle encapsulated into a #respect() tuple centre.
73 73  ##
74 74  This is why #respect() can be assumed as a general-purpose core language for coordination: a language that could then be used to represent and enact policies and rules for coordination systems of any sort.
75 -
76 -Adopting the declarative interpretation of logic tuples, a #respect() tuple centre has then a twofold nature a ~~theory of communication~~ (the set of the ordinary tuples) and a ~~theory of coordination~~ (the set of the specification tuples).
73 +<p/>
74 +Adopting the declarative interpretation of logic tuples, a #respect() tuple centre has then a twofold nature a //theory of communication// (the set of the ordinary tuples) and a //theory of coordination// (the set of the specification tuples).
77 77  ##
78 78  In principle, this allows intelligent agents to reason about the state of collaboration activities, and to possibly affect their dynamics.
79 79  ##
80 80  Furthermore, the twofold interpretation (either declarative or procedural) of #respect() specification tuples allows knowledge and control to be represented uniformly (as Prolog-like facts) and encapsulated within the same coordination artefact.
81 -
79 +{{/velocity}}
80 +{{include document="ReSpecT.MacroSheet"/}}

2P |  TuCSoN