Event-Driven Programming for Situated MAS with ReSpecT Tuple ...

Event-Driven Programming for Situated MAS with ReSpecT Tuple Centres Stefano Mariani and Andrea Omicini DISI, Alma Mater Studiorum–Universit` a di Bologna via Sacchi 3, 47521 Cesena, Italy {s.mariani,andrea.omicini}@unibo.it

Abstract. We advocate the role of tuple-based coordination languages as effective tools for event-driven programming of situated multi-agent systems (MAS). By focussing on logic-based coordination artefacts, we discuss the benefits of exploiting ReSpecT tuple centres as event-driven abstractions for MAS coordination.

1

Introduction

The role of the environment in multi-agent systems (MAS) is nowadays widely recognised: as a foremost source of complexity, environment should be handled as a first-class entity in MAS modelling and engineering [1]. This requires suitable abstractions, technologies, and methodologies, which are typically provided by agent middleware [2]—from JADE services [3] to CArtAgO artefacts [4]. The Agent & Artefact (A&A) meta-model adopts agents and artefacts as the basic bricks for MAS. There, artefacts are first-class abstractions to model and engineer general-purpose computational MAS environments [5]. In particular, environment artefacts (also called resource artefacts) are in charge to mediate between MAS and the resources in the virtual and physical environment [6]. Therefore, environment artefacts are the fundamental abstractions to deal with agent and MAS situatedness, as the property of being immersed in the environment, that is, capable to perceive and produce environment change, by suitably dealing with environment events. Agent-oriented event-driven programming models and languages are then required to design and implement situated MAS —such as pervasive, adaptive, and self-organising MAS [7]. Accordingly, in this paper we focus on the TuCSoN coordination middleware for MAS [8], and show how its coordination artefacts [9] – that is, ReSpecT tuple centres [10] – provide the required event-driven model and technology for programming situated MAS. To this end, Section 2 shortly discusses the notion of artefact in the A&A meta-model, the notion of coordination artefact, and its relation with tuple-based coordination models. Then, Section 3 describes ReSpecT tuple centres as providers of an event-driven model and technology for programming fully situated MAS. Finally, Section 4 discusses some examples of MAS event-driven programming in ReSpecT. M. Klusch, M. Thimm, and M. Paprzycki (Eds.): MATES 2013, LNAI 8076, pp. 306–319, 2013. c Springer-Verlag Berlin Heidelberg 2013 

Event-Driven Programming for Situated MAS with ReSpecT

2

307

Artefacts, Coordination and Tuple Centres

Given the ever-growing relevance of MAS abstractions and technologies in the engineering of pervasive [11,12], adaptive [13,14], and self-organising systems [15,16] – where the environment works as the main source of system complexity –, the issue of MAS environment engineering is nowadays of paramount importance [1,2]. Accordingly, the property of individual agents and of the MAS as a whole to be immersed into the environment, perceiving any relevant environment change, and interacting effectively with environment resources – in one word, MAS situatedness – should definitely play a key role in MAS models and technologies. In particular, one of the main issues here is how agents and MAS are expected to properly deal with possibly unpredictable and unstructured environment events of any sort. Along this line, the Agent & Artefact (A&A) meta-model adopts artefacts as the main abstraction for modelling and engineering general-purpose computational MAS environments [5]. As depicted in Fig. 1, in A&A individual artefacts rule interaction between individual agents and MAS, social artefacts embody and enact social policies to govern inter-agent interaction, environment artefact (also called resource artefacts) are in charge to mediate between MAS and the resources in the virtual and physical environment [6]. Then, environment artefacts are the fundamental abstractions to deal with MAS situatedness, in charge of suitably dealing with environment events: however, as a meta-model, A&A does not directly provide neither the required computational model nor the technology to build environment artefacts. On the other hand, the notion of coordination artefacts aims at generally systematising implicit communication and environment-based coordination for heterogeneous, possibly intelligent agents in MAS, by providing MAS engineers with a class of abstractions capable of dealing with general-purpose coordination events in a MAS [9]. Among the many available sources for coordination artefacts, tuple-based coordination models already proved their effectiveness in coping with complex MAS engineering [17], mostly due to the following features:














  


Fig. 1. Class of artefacts according to the A&A meta-model: I are individual artefacts, S are social artefacts, R are environment, (or, resource) artefacts [6]

308

S. Mariani and A. Omicini

Generative Communication — Information exchanged among agents, recorded in the tuple space in terms of tuples, has an independent life with respect to its “generator” agent, thus promoting full communication uncoupling (space, time, name) among agents. If tuples represent events, then events inherit such features, promoting full uncoupling from their source. Associative Access — Information retrieval is based on tuple structure and content, rather than on name, or location, thanks to the tuple matching mechanism, thus allowing for knowledge-based coordination patterns. Again, when tuples reify events, then any event is available to any agent able to associatively access to it. Suspensive Semantics — Agents block on tuple space operations if the information they look for is missing, thus enabling coordination policies in incomplete or partial knowledge scenarios. Also, reactive behaviours, which are desirable in event-based systems, are thus naturally supported by simply requesting the expected event-tuple and relying on Linda semantics. Nevertheless, the most relevant drawback of such models lies in their lack of expressiveness: possible coordination policies are determined by the available coordination primitives – e.g. out, in, rd in Linda [18] –, along with the corresponding behaviour of the tuple space, set once and for all by the model [19]. Any coordination requirement not directly reducible to the available coordination primitives should then be faced by charging coordination upon the agents: which is acceptable for individual coordination issues, not for social ones [20]. This is the main motivation behind the definition of tuple centres as a programmable extension of tuple spaces [10]. Along with the communication space, represented by the tuples exchanged by agents, a tuple centre provides a coordination space, storing a behaviour specification written in terms of specification tuples, that sets the coordinative behaviour of the coordination media. Each tuple centre can be programmed so as to perform some computational activity in response to events involving the coordination medium. In this way, the behaviour of a tuple centre – and so, the MAS coordination policies it can handle – can be made as complex as needed by the application at hand. As a result, coordination issues in a MAS can be faced according to basic engineering principles: individual ones within individual abstractions (agents), social ones within social abstractions (tuple centres) [20]. Once re-casted as (coordination) artefacts [21], tuple centres exhibit the following artefact features: Inspectability — The capability of artefact state and behaviour to be observed at runtime, thus supporting their on-line management in terms of diagnosing, debugging, testing. When tuple centres are event mediators, this actually means making any event occurring there observable. Forgeability — The capability of artefact function to be adapted at runtime according to changing requirements or unpredictable events occurring in an open environment. This makes it possible to change the way in which events are produced, managed, and consumed according to the application needs.

Event-Driven Programming for Situated MAS with ReSpecT

309

Linkability — The capability of distinct artefacts to work together at runtime as a form of dynamic composition, e.g., to scale up with the complexity of the computational load. This is essential to make the architecture in Fig. 1 feasible, allowing any event to be arbitrarily and seamlessly spread within the MAS at hand, building event chains. Therefore, any MAS event has both a prime cause and a direct cause: the prime cause is always an agent or the environment, whereas the direct cause may also be another tuple centre [21]. Situatedness — The property of being immersed in the environment, perceiving and reacting to environment events and changes: essential in complex software systems such as pervasive, adaptive and self-organising ones [7]. In particular, situatedness is the tuple centre property required to address the issue of agent-environment coordination as the last fundamental MAS coordination issue, after individual and social ones [22]. As sketched in Fig. 1, the A&A meta-model promotes an event-driven view of MAS: thus, a MAS coordination model exploiting event-driven coordination media is apparently a fit solution for addressing the issue of MAS situatedness, suitably governing interaction between agents, MAS, and environment. Along this line, in the following we focus on the TuCSoN middleware for MAS coordination [8], and investigate how the features of ReSpecT tuple centres – TuCSoN coordination artefacts – can be effectively exploited to build an event-driven model for MAS situated coordination, by exploiting ReSpecT as an event-driven programming language.

3 3.1

ReSpecT Tuple Centres for Event-Driven Coordination ReSpecT Event Model

In ReSpecT, a general tuple centre event is either an operation event, an environment event, or a spatio-temporal event: Event  ::= OpEvent  | EnvEvent  | STEvent 

Operation Events An operation event is any event whose prime cause is an agent (coordination) operation. Inspectability is exploited by making observable (i) the primitive invoked along with its argument, (ii) the “source” agent who issued it, and (iii) the tuple centre target of such operation: PrimeCause ::= CoordOp, AgentId , TCId

Due to linkability, the direct cause can instead be either a coordination operation or a linking primitive invoked within a ReSpecT reaction—thus executed by another ReSpecT tuple centre: DirectCause ::= CoordOp | LinkOp, AgentId | TCId, TCId 

Finally, the completion of any operation invocation typically has some effect on the tuple centre, namely, the tuple inserted/collected. Hence, operation events have roughly the following structure in ReSpecT: OpEvent  ::= PrimeCause, DirectCause , Tuple

310

S. Mariani and A. Omicini

Environment Events. According to the A&A metamodel, environment artefacts are required to mediate between agents of a MAS and their environment. In TuCSoN, this role is played by ReSpecT tuple centres through (event) transducers [22], that is, components able to bring environment-generated events within a tuple centre, suitably translated according to its event model. As a result, from the tuple centre viewpoint, a transducer is technically both the prime and direct cause of any environment event, working as a sort of proxy for an environment resource, which represents the actual source of the event. So, in the very end, an environmental event for a tuple centre has basically the following structure (more on this in [22,23]): EnvEvent  ::= EnvCause, EnvCause, env(Key, Value) EnvCause ::=  env(Key, Value), EnvResId , TCId

Space-Time Events. By adopting the same approach of [22], events related to the flow of time or to motion in space could be interpreted as being generated by the MAS environment. Along this line, we could model them, too, as environmental events, leaving their management to properly designed transducers. However, this approach falls short in recognising a fundamental difference between an event generated by the environmental resources and one related to the space-time fabric: whereas any resource may or may not be represented as part of the environment of a MAS, time flows, and space may change, within any MAS. So, spatial events [23] and time events [24] both mandate for a first-class status in event-driven programming for MAS coordination. On the one hand, the flow of time is something not an agent neither a coordination artefact can control, hence the only time event to consider is the ever-changing current time. On the other hand, the space where a MAS tuple centre is executing can be perceived, but also changed through appropriate motion actions. Furthermore, perception and action over the space fabric can be described at two different levels, at least: the physical and the virtual one. The physical level is that of the physical world we live in, made up of physical places and physical distances detected through GPS services. The physical level is, e.g., that of a swarm of robots who need to coordinate themselves to explore an unknown area as best as they can, hence transducers capable of both perceiving GPS/accelerometer data and of issuing motion commands to such devices may be available. The virtual level is that of the virtual world the digital era brought us, made up of virtual places and virtual distances defined by network services and protocols such as the TCP/IP for the Internet. The virtual level is, e.g., that of a swarm of software agents who need to coordinate themselves to collect hyperlinking information in a pool of web sites as fast as they can, hence they could need to relocate network resources as a consequence to their mobility. Accordingly, a space-time event for a tuple centre has the following structure: STEvent  ::= STCause, STCause, SOp | TOp STCause ::= SOp | TOp, time | space, TCId SOp ::= from(Place) | to(Place) | node(Node) TOp ::= time(Time)

Event-Driven Programming for Situated MAS with ReSpecT

311

where Time is the current time of the tuple centre execution environment, Place represent the current GPS coordinates – hence physical, absolute and global to all the networked tuple centres – and Node is some identifier of the tuple centre network node, making it reachable from remote devices—e.g. its IP address, or the identifier of the 3G cell. Operation & Environmental Events in the Space-Time Fabric. If the tuple centre is spatio-temporally situated – that is, able to recognise events occurring in the space-time fabric, and to properly react –, then any event it generates, manages, and consumes should be spatio-temporally situated as well. Therefore, both operation events and environmental events need to be refined so as to add space-time fabric properties and spatio-temporal events should be properly completed, too. In particular, all “cause” specifications defined above should be extended by adding the following information: Time, Place, Node

Such information may be available or not depending on the computational device hosting the tuple centre: in the case it is not, a “null” value is stored (⊥). 3.2

Events in the

ReSpecT Language

As both a first-order logic (FOL) and an event-driven language, ReSpecT has both a declarative and a procedural part. As a specification language, it allows events of any sort to be declaratively associated to computational activities called reaction goals (reactions, often, in short) by means of specific logic tuples of the form reaction(E, G, R), called specification tuples. In short, given a tuple centre event e, a specification tuple reaction(E, G, R) associates a reaction Rθ to event e if θ = mgu(E, e) – where mgu is the firstorder logic most general unifier – and guard Gθ holds. Formally, the semantics of ReSpecT is defined in terms of the two functions Z and E. Z (Reaction Specification Function). Z defines how ReSpecT associates events to reactions. If e is an event occurring in a tuple centre whose behaviour specification σ (a ReSpecT program) contains reactions r of the form reaction(E, G, R), then the reaction goals to be executed are defined by Z as follows:  e  Rθ if θ = mgu(E, e) ∧ Gθ Zσ (e) ::= r∈σ z(e, r), where z(e, r) ::= ∅ otherwise that is, collecting all reactions goals e Rθ whose triggering event E matches the specific event e modulo unification (θ), provided that guard Gθ holds. Triggered reaction goals are then executed following the reaction evaluation function E. E (Reaction Evaluation Function). E encapsulates ReSpecT conceptual machinery for reaction execution, which is essentially an event-driven virtual machine collecting events and properly reacting according to a ReSpecT program.

312

S. Mariani and A. Omicini

In short – more details in [25,21,26,22,23] –, the state of a ReSpecT tuple centre is formally expressed by the labelled quadruple InQ ,EnvQ

T , σ, R, OOutQ

where T is the set of tuples, σ the set of specification tuples (the behaviour specification), R the set of triggered reaction goals to be executed, O the set of operations waiting to be served, whereas InQ, EnvQ , OutQ are event queues containing input and output events. In particular, InQ contains OpEvent s representing coordination primitives invoked either by agents (operations) or tuple centres (links); EnvQ contains both EnvEvent s and STEvent s – so, environment events in the most general acceptation of the term –; OutQ contains all kinds of output events generated by reaction execution within a tuple centre. Basically, the main cycle of a tuple centre work as follows—formally, four transition rules drive ReSpecT machinery, as originally described in [26] where the only environment event modelled was time: 1. When a tuple centre primitive is invoked by either an agent (operation) or an artefact (link), a ReSpecT event is generated, and reaches its target tuple centre, where it is automatically and orderly inserted in its InQ queue. 2. When the tuple centre is idle (that is, no reaction is currently being executed), the first event in InQ (according to a FIFO policy) is logged, and moved to the set O of the requests to be served: this stage is called the request phase of the event. This corresponds to the log transition rule, firing when R = EnvQ = ∅, O contains no satisfiable requests, and InQ = ∅. 3. Consequently, reactions to the request phase of the event are triggered by adding them to the set R of the triggered reactions waiting to be executed. 4. All triggered reactions in R are then executed in a non-deterministic order. Each reaction is executed sequentially, with a transactional semantics, and may trigger further reactions, to be added to R, and new output events, representing link invocations: such events are added to the queue OutQ of output events, and released at the end of reaction execution—if successful. This phase is driven by the reaction transition rule, firing when R = ∅. 5. Only when R is finally empty, requests waiting to be served in O are possibly executed by the tuple centre, and operation/link completions are sent back to invokers. The corresponding transition rule is the service transition, firing when R = EnvQ = ∅ and O contains at least one satisfiable request. 6. This may give raise to further reactions, associated to the response phase (completion) of the original invocation, and executed again with the same semantics specified above for the request phase. Whereas InQ is fed by coordination primitives, EnvQ is added new environment events by the associated transducers translating environment events into ReSpecT events, as well as by the flow of time, and by motion in space [26,22]. The transition rule responsible of this is the environment transition, firing when R = ∅ and EnvQ = ∅. Since the full definition of the ReSpecT syntax and semantics falls out of the scope of this paper, we forward the interested reader to [25,21,26,22,23].

Event-Driven Programming for Situated MAS with ReSpecT

313

As a last note, it is indeed useful to highlight once more a crucial feature of the ReSpecT virtual machine: decoupling in control. Whereas TuCSoN agents can autonomously decide wether to suspend themselves waiting for the outcome of an issued operation – following Linda suspensive semantics –, ReSpecT tuple centres linkability service is always asynchronous. This means that the invocation phase (point 1 in previous list) and the completion phase (point 5) are always handled asynchronously by ReSpecT virtual machine: – once linking invocations are sent out – put in the target tuple centre InQ –, ReSpecT tuple centre machinery continues onward to step 3, without waiting for the linking completion; – when linking completions have to be sent back by the target tuple centre, they are simply inserted into the InQ of the source tuple centre, and processed asynchronously. This kind of uncoupling enables scaling with the size and complexity of the MAS at hand, because the programmer is guaranteed by the ReSpecT language that neither interference or deadlock can happen between linking operations.

4

Event-Driven Programming in ReSpecT: Examples

In the following, we discuss some examples of MAS event-driven programming in ReSpecT, with the twofold goal of showing: (i) how ReSpecT logic tuple centres can be programmed – exploiting their A&A features – by mapping events into computations; (ii) how ReSpecT event model and language constructs can help the process of developing a situated MAS. 4.1

Generative Communication, Associative Access and Inspectability

Generative communication, associative access, and inspectability features exhibited by ReSpecT tuple centres can be easily highlighted through the following ReSpecT specification snippet. 1 reaction ( in ( Tuple ) , 2 ( operation, invocation ) , 3 ( start_source ( Src ) , % Prime Cause inspection 4 start_target ( Trg ) , 5 event_time ( T ) , % Direct Cause inspection 6 event_node ( N ) , 7 out ( event ( req ( in ( Tuple )) ,from ( Src ) ,to ( Trg ) ,at ( T ) ,on ( N )) ) 8 ) ).

% Reification

The above ReSpecT specification transparently – from the agents’ standpoint – encapsulates situated inspection & reification of an operation request (invocation guard) performed by an agent (operation). In fact, the operation request (in the example, in(Tuple)) is augmented with contextual information taken from the generated ReSpecT event – who was the original requestor (observation predicate start source) and the original destination (start target) of the operation,

314

S. Mariani and A. Omicini

at what time (event time) and on which host (event node) such event was generated – without no need for the agent to be aware of it. Then, the situated event is stored in the tuple centre (line 7), made available for inspection and usage to anyone, being decoupled in time, space, and reference from its prime cause. The integration of inspection and reification – and, obviously, forgeability – enables event-based situated coordination in an open environment: for instance, an agent may become aware of the existence of other agents (“social awareness”) by collecting the Src info, as well as of the availability of other coordination abstractions by recording the Trg info (“environment awareness”). 4.2

Logic and Associative Access

The following ReSpecT specification snippet is meant to highlight the gain in expressiveness given by logic tuples over other possible kind of tuples. 1 2 3 4 5 6 7 8 9 10 11 12 13 14

reaction ( out ( Tuple ) , ( operation, completion ) , ( start_source ( Src ) , start_target ( Trg ) , ( causalCheck ( event ( out ( Tuple ) ,from ( Src ) ,to ( Trg )) ) ; % ’ if-then-else ’ in ( Tuple ) % Resolve inconsistency ) ) ). causalCheck ( event ( Op, F, T ) ): findall ( B, clause ( Op, B ) , L ) , % Consult theory causalCheck ( F, T, L ). causalCheck ( _, _, [] ). causalCheck ( F, T, [ H | Tail ] ): rd ( event ( H, F, T )) , % Check consistency causalCheck ( F, T, Tail ).

% Prolog invocation

Here, we suppose to have a MAS where logical consistency must be enforced between (inter)actions performed by agents—e.g., insertion of some information is allowed only if other “causal” information exists. So, the goal of the ReSpecT specification above – along with the auxiliary Prolog predicates (lines 8-14) – is to verify such kind of “logical implication”, allowing insertion of a tuple if and only if all “precondition tuples” have been already stored. Knowledge about causal relationships is shipped as a logic theory – here, a Prolog one, encapsulated in the tuple centre, thus seamlessly integrated with ReSpecT – in which the head of a clause is a ReSpecT operation and its body a single precondition to be checked. If and only if all logic preconditions (findall/3) are actually found in the tuple centre, the insertion operation triggering the ReSpecT computation is allowed. The snippet works as follows. Once an out(Tuple) operation has been completed (lines 1-2), the prime cause and the target of such event are inspected (line 3) to be used in the subsequent Prolog predicate invocation (line 4). Then, if Prolog evaluation succeeds, nothing is done, whereas if such evaluation fails, the inserted tuple is removed (line 6)—atomically deleting the effect of the triggering event, source of the inconsistency. The Prolog predicate responsible for consistency check (causalCheck/1) works as follows: it (i) collects all the preconditions to be checked, by retrieving all the clauses whose head matches the ReSpecT operation causing the event (line 9), then (ii) tests non-destructively

Event-Driven Programming for Situated MAS with ReSpecT

315

the existence of each precondition (only the body B of the clause is collected) in the tuple centre (lines 12-14). The logical nature of ReSpecT tuples – along with inspectability and forgeability, as usual – enables “intelligent” agents to perform logical reasoning upon coordination events, leveraging a simple data store (a tuple space) to a logic theory about coordination events (a ReSpecT tuple centre). In fact, with just a slight modification to the ReSpecT specification sketched above – e.g., by reifying Prolog clauses as tuples –, an agent may even learn at run-time which kind of coordination operations it is supposed to carry out before others, by performing inference on the logical (event-driven) coordination theory. 4.3

Situatedness and Linkability

The following ReSpecT code snippet sketches a ReSpecT program meant to coordinate the motion of robot swarms so as to reach a “uniform” distribution in space, in which each robot is equidistant from its neighbours—modulo small fluctuations due to the local and distributed nature of the proposed solution. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

reaction ( out ( moved ( NewPos )) , ( link_in , completion ) , % Incoming link ( in ( moved ( NewPos )) , event_source ( Who ) , % Direct cause inspection in ( nbr ( Who, Pos )) , out ( nbr ( Who, NewPos )) , rd_all ( nbr ( _, _ ) , Nbrs ) , c o m p u t e B a r i c e n t e r ( Nbrs, B ) , % Prolog invocation current_node ( Host ) , % Inspect actual host steering_engine @ Host