|
|
1 |
= Overview =
|
|
|
2 |
|
|
|
3 |
* {{respect/}} (**Re**action **Spec**ification **T**uples) is a logic-based language for the coordination of complex software systems
|
|
|
4 |
* {{respect/}} promotes a coordination model providing tuple centres as programmable, general-purpose coordination media
|
|
|
5 |
* the behaviour of {{respect/}} tuple centres is programmed through the {{respect/}} first-order logic language
|
|
|
6 |
|
|
|
7 |
== The {{respect/}} Tuple Centre Coordination Model ==
|
|
|
8 |
|
|
|
9 |
A tuple centre is a tuple space enhanced with the possibility to program its behaviour in response to interactions.
|
|
|
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.
|
|
|
11 |
So, an agent can write a tuple in a tuple centre with an {{code language="none"}}out{{/code}} primitive; or read a tuple from a tuple centre with primitives such as {{code language="none"}}in{{/code}}, {{code language="none"}}rd{{/code}}, {{code language="none"}}inp{{/code}}, {{code language="none"}}rdp{{/code}} specifying a tuple template - that is, an identifier for a set of tuples, according to some tuple matching mechanism
|
|
|
12 |
Reading tuples can be
|
|
|
13 |
* //destructive// — {{code language="none"}}in{{/code}}, {{code language="none"}}inp{{/code}} remove the matching tuple – or //non-destructive//– {{code language="none"}}rd{{/code}}, {{code language="none"}}rdp{{/code}} simply read the matching tuple
|
|
|
14 |
* //suspensive// — {{code language="none"}}in{{/code}}, {{code language="none"}}rd{{/code}} wait until a matching tuple is found – or //non-suspensive//– {{code language="none"}}inp{{/code}}, {{code language="none"}}rdp{{/code}} immediately return either the matching tuple or a failure result
|
|
|
15 |
|
|
|
16 |
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.
|
|
|
17 |
|
|
|
18 |
Accordingly, a tuple centre enjoys all the many features of a tuple space, which can be classified along three different dimensions:
|
|
|
19 |
* generative communication
|
|
|
20 |
* associative access
|
|
|
21 |
* suspensive semantics
|
|
|
22 |
|
|
|
23 |
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.
|
|
|
24 |
##
|
|
|
25 |
//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. Finally, //suspensive semantics// promotes coordination patterns based on knowledge availability, and couples well with incomplete, partial knowledge.
|
|
|
26 |
|
|
|
27 |
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.
|
|
|
28 |
So, for instance, an agent {{code language="none"}}ag1{{/code}} performing operation {{code language="none"}}we ? in(activity(ag1,CaseID)){{/code}} on tuple centre {{code language="none"}}we{{/code}} containing tuples {{code language="none"}}activity(ag1,c16){{/code}} and {{code language="none"}}activity(ag2,c22){{/code}} will be returned tuple {{code language="none"}}activity(ag1,c16){{/code}}—the one unifying with the template—removed from {{code language="none"}}we{{/code}}. 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//.
|
|
|
29 |
|
|
|
30 |
Finally, a tuple centre is a programmable tuple space, so as to add //programmability// of the coordination medium as a new dimension of coordination. 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. 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.
|
|
|
31 |
|
|
|
32 |
== {{respect/}} as a Core Coordination Language ==
|
|
|
33 |
|
|
|
34 |
The original {{respect/}} is a logic-based language for the specification of the behaviour of tuple centre. As a behaviour specification language, #respect():
|
|
|
35 |
* enables the definition of computations within a tuple centre, called reactions, and
|
|
|
36 |
* makes it possible to associate reactions to events occurring in a tuple centre.
|
|
|
37 |
|
|
|
38 |
So, {{respect/}} has both a declarative and a procedural part. 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 language="none"}}reaction(E,R){{/code}}. In short, given a event {{code language="none"}}Ev{{/code}}, a specification tuple {{code language="none"}}reaction(E,R){{/code}} associates a reaction {{code language="none"}}Rtheta{{/code}} to {{code language="none"}}Ev{{/code}} if {{code language="none"}}theta{{/code}} = mgu({{code language="none"}}E,Ev{{/code}}). As a reaction language, {{respect/}} enables reactions to be procedurally defined in terms of sequences of logic reaction goals, each one either succeeding or failing. A reaction as a whole succeeds if all its reaction goals succeed, and fails otherwise. Each reaction is executed sequentially with a transactional semantics: so, a failed reaction has no effect on the state of a logic tuple centre.
|
|
|
39 |
|
|
|
40 |
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. 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. 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. 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.
|
|
|
41 |
|
|
|
42 |
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). In principle, this allows intelligent agents to reason about the state of collaboration activities, and to possibly affect their dynamics. 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.
|
|
|
43 |
|
|
|
44 |
{{include reference="Environment" excludeFirstHeading="yes"/}} |
