Changes for page Overview
From version 4.1
edited by Andrea Omicini
on 10/08/2021 16:42
on 10/08/2021 16:42
Change comment:
There is no comment for this version
To version 2.1
edited by Andrea Omicini
on 11/12/2020 19:35
on 11/12/2020 19:35
Change comment:
There is no comment for this version
Summary
-
Page properties (3 modified, 0 added, 0 removed)
Details
- Page properties
-
- Title
-
... ... @@ -1,1 +1,1 @@ 1 - ReSpecTOverview1 +Overview - Syntax
-
... ... @@ -1,1 +1,1 @@ 1 -XWiki 2.11 +XWiki 1.0 - Content
-
... ... @@ -1,56 +1,58 @@ 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. 1 +#includeMacros("Main.MacroSheet")#includeMacros("ReSpecT.MacroSheet") 5 5 6 - ==The#respect()TupleCentre Coordination Model ==3 +1 #respect() Overview 7 7 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 + 8 8 A tuple centre is a tuple space enhanced with the possibility to program its behaviour in response to interactions. 9 9 ## 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.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. 11 11 ## 12 12 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. 13 13 ## 14 14 Reading tuples can be 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/> 20 -Accordingly, a tuple centre enjoys all the many features of a tuple space, which can be classified along three different dimensions: 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. 21 21 24 +Accordingly, a tuple centre enjoys all the many features of a tuple space, which can be classified along three different dimensions: 22 22 * generative communication 23 23 * associative access 24 24 * suspensive semantics 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.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. 27 27 ## 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.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. 29 29 ## 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 — both tuples and tuple templates are essentially Prolog //facts//— and logic//unification//is used as the tuple-matching mechanism.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 — both tuples and tuple templates are essentially Prolog ~~facts~~ — and logic ~~unification~~ is used as the tuple-matching mechanism. 33 33 ## 34 34 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)") — the one unifying with the template — removed from #code("we"). 35 35 ## 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 — 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.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 — 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. 39 39 ## 40 40 While the behaviour of a tuple space in response to interaction events is fixed — so, the effects of coordination primitives is fixed —, 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. 41 41 ## 42 42 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. 43 43 44 - ==#respect() as a Core Coordination Language==47 +1.1 #respect() as a Core Coordination Language 45 45 46 46 The original #respect() is a logic-based language for the specification of the behaviour of tuple centre. 47 47 ## 48 48 As a behaviour specification language, #respect(): 49 49 50 - 51 51 * enables the definition of computations within a tuple centre, called reactions, and 52 52 * makes it possible to associate reactions to events occurring in a tuple centre. 53 - <p/>55 + 54 54 So, #respect() has both a declarative and a procedural part. 55 55 ## 56 56 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)"). ... ... @@ -62,7 +62,7 @@ 62 62 A reaction as a whole succeeds if all its reaction goals succeed, and fails otherwise. 63 63 ## 64 64 Each reaction is executed sequentially with a transactional semantics: so, a failed reaction has no effect on the state of a logic tuple centre. 65 - <p/>67 + 66 66 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. 67 67 ## 68 68 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. ... ... @@ -70,11 +70,10 @@ 70 70 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. 71 71 ## 72 72 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. 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).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). 75 75 ## 76 76 In principle, this allows intelligent agents to reason about the state of collaboration activities, and to possibly affect their dynamics. 77 77 ## 78 78 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. 79 -{{/velocity}} 80 -{{include document="ReSpecT.MacroSheet"/}} 81 +