-Open distributed multi-agent systems featuring autonomous components demand coordination mechanisms for both functional and non-functional properties. Heterogeneity of requirements regarding interaction means and paradigms, stemming from the diverse nature of components, should not affect the effectiveness of coordination. Along this line, in this paper we share our pragmatical experience in the integration of objective and subjective, synchronous and asynchronous, reactive and proactive coordination approaches within two widely-adopted agentoriented technologies (JADE and Jason), enabling coordinating components to dynamically adapt their interaction means based on static preference or run-time contingencies.
Open and distributed multi-agent systems (MAS) featuring autonomous components demand efficient coordination mechanisms for both functional and non-functional properties. Heterogeneity of requirements regarding interaction means and paradigms – e.g. message-passing vs. shared space, synchronous vs. asynchronous, proactive vs. reactive, etc. – stemming from the heterogeneous nature of components – e.g. software agents vs. physical devices – implies that coordination should be effective despite heterogeneity.
Coordination approaches in the literature can be classified according to diverse criteria, such as the means through which interaction happens – e.g. messages vs. tuples –, synchronism of interaction primitives, enforced programming style—e.g. reactive, such as with actors, vs. pro-active, such as with agents. The most general classification distinguishes coordination approaches as either objective or subjective [1], depending on who is responsible for the ”burden of coordination”: the coordinable, or the coordination medium—following the metamodel and the terminology proposed in [2].
Objective coordination [1] refers to the approach – typically stemming from the software engineering research field – where coordination-related concerns are encapsulated within dedicated abstractions, such as coordination artefacts [3] (the medium), offering coordination as a service to coordinables [4]. Thus, coordination abstractions take responsibility for coordination, by steering agent societies – that is, ensemble of cooperating/competing agents – towards the achievement of social (shared) goals, through the suitable management of the dependencies between agents’ activities [5], [6]—despite agent’s individual goals, yet without harming their autonomy.
Subjective coordination [1] represents instead the dual approach – typically adopted in the (distributed) artificial intelligence field [7] – where coordination issues are directly tackled by the agents themselves, determining their best course of (inter-)action in the attempt to achieve their own goals. Thus, the burden of coordination is here distributed among coordinables, expressing their autonomy w.r.t. coordination commitments through their own deliberation process.
Clearly, respecting agents’ autonomy is a foremost issue in the design of coordination models for MAS, be them objective or subjective. Also, the issue of autonomy emerges while designing other facets of coordination model and technologies, corresponding to the aforementioned classification criteria.
Enforcing a reactive programming style for handling interactions – as typically done in the context of event-based systems and actor-based frameworks – often leads to the problem of inversion of control—namely, the fact that the flow of interactions determines when the interacting components should act and what they should do, thus definitely wipe out pro-activeness of components. Also, on a lower level, the management of the component control flow is taken out from the programmers’ hands, and left to the framework. In the overall, inversion of control results in a blatant example of violation of the component autonomy.
Adopting a synchronous semantics for interaction primitives invocation, without adequate mediating abstractions uncoupling the invoker flow of control from the (possibly) suspensive semantics of the primitive, is another way to violate the components autonomy. A typical example can be observed in any LINDA-like coordination model [8], where interacting components are usually bound to withstand the outcomes of the coordination process—e.g. getting stuck whenever a getter primitive finds no matching tuple in the shared space.
Accordingly, in this paper we share our pragmatical experience in integrating objective and subjective, synchronous and asynchronous, reactive and pro-active coordination approaches, enabling participating components to (deliberatively) dynamically adapt their interaction means based on static preference or run-time contingencies – while still having their autonomy preserved –, in the context of two widely adopted agent-oriented technologies, that is, JADE [9] and Jason [10], featuring their own subjective coordination mechanisms, and adopting the TuCSoN middleware as the provider of objective coordination. The goal is to provide MAS designers and programmers with a flexible development framework capable of seamlessly supporting multi-paradigm coordination, where agents deliberatively choose which coordination paradigm and interaction means to adopt for the current interactions—and, more importantly, where such a choice does not affect negatively the other interactive, or non-interactive, activities they are (possibly, concurrently) undertaking.
The remainder of the paper is organised as follows. Section II describes how the subjective coordination paradigm may be instantiated within a message-based setting, also wr.t. synchronism and programming style, by discussing the concrete cases of JADE (Subsection II-A) and Jason (Subsection II-B). Section III describes how the objective coordination paradigm may be implemented within a tuple-based setting, by discussing the TuCSoN approach (Subsection III-A). Section IV describes our solution for enabling multi-paradigm coordination, by briefly describing TuCSoN4JADE (Subsection IV-A) – already presented in [11], but useful here for comparison and generalisation purposes – and by thoroughly discussing TuCSoN4Jason (Subsection IV-B)—also, an example showcasing effectiveness of multi-paradigm coordination is provided in Subsection IV-C. Finally, Section V briefly reports on some similar works by fellow researchers, while Section VI summarises the work, and outlines future improvements.
In this section we briefly describe the approach to subjective coordination adopted by two agent development frameworks well-known within the MAS community: JADE (Subsection II-A) and Jason (Subsection II-B).
JADE (Java Agent DEvelopment Framework) [9] is a Javabased framework and infrastructure to develop and deploy open, distributed, agent-based applications in compliance with FIPA standard specifications for interoperable intelligent MAS. In JADE, autonomy of agents is supported by the behaviour abstraction, whereas coordination adopts the subjective paradigm thanks to an asynchronous message-passing layer – the Agent Communication Channel (ACC) – on top of which FIPA interaction protocols are implemented and provided to developers— as a callbacks framework.
A behaviour can be logically interpreted as “an activity to perform with the goal of accomplishing a task”. Thus, different courses of actions of a JADE agent are encapsulated into distinct behaviours the agent executes simultaneously. More technically, JADE behaviours are Java objects, which are executed pseudo-concurrently within a single Java thread by a built-in non-preemptive round-robin scheduler. During JADE agent initialisation, behaviours are added to the ready queue, ready to be scheduled. Then, method action() of the first behaviour – implementing one of the agent’s course of action – is executed. Behaviours switch occurs only when the method returns; hence, in the meanwhile no other behaviour can start execution (non-preemptive scheduler). Behaviours removal from the ready queue occurs only when the done() method returns true; otherwise, the behaviour is re-scheduled at the end of the queue (round-robin scheduler). It is worth • • • • noting that method action() is executed from the beginning every time: there is no way to “stop-then-resume” a behaviour during its execution.
The ACC is the middleware service in charge of asynchronous message passing among agents: each agent has its own mailbox where incoming communications are silently put, waiting to be explictly (pro-actively) considered by the receiving agent—for the sake of preserving its autonomy. When and how to process the mailbox is up to the agent’s own deliberation: method receive() attempts to asynchronously retrieve the first message, or a message compliant with a given message template, from the mailbox—returning nothing in case no message is found method blockingReceive(), as the name suggests, attempts to synchronously retrieve the first message, or a message compliant with a given message template, from the mailbox— waiting until a message is eventually found Clearly, the first method preserves the autonomy of the agent no matter what. The same does not hold for the second one, because deciding to wait for a specific interaction potentially hinders the ability of the agent to remain responsive to other interactions—although based on a deliberate choice of the agent itself.
The reason is that method blockingReceive() suspends the agent as a whole, not only the calling behaviour. Thus, the JADE Programmers Guide itself [12] suggests the adoption of the following programming pattern: call receive() instead of blockingReceive(), then call method block() – of the Behaviour class – if no message is found, so as to suspend only the calling behaviour—which will be automatically resumed by JADE upon reception of any message. Therefore, if programmers want their agents’ autonomy preserved while subjectively coordinating, they should abide to the “block-then-resume” pattern just described.
Besides plain message passing, JADE provides to programmers a number of ready-to-use FIPA interaction protocols, such as the Contract Net [13] and the general-purpose Achieve Rational Effect [14], in the form of a callbacks framework: programmers declare which FIPA protocol their interacting agents should commit to, by instantiating the corresponding Java object then, they implement the actual body of the callback methods corresponding to each interaction (message to be received or sent) as expected according to the specific FIPA protocol adopted As any other framework adopting a callback scheme, JADE FIPA protocols promote a reactive programming style, where agents synchronously wait for messages to advance through the protocol stages. Agents’ pro-activeness – so, their autonomy – is thus limited. Nevertheless, JADE internally implements FIPA protocols abiding to the block-then-resume pattern, so that interacting agents stay responsive to concurrent interactions while subjectively coordinating—besides being able to carry out non-interactive activities through concurrent behaviours.
Summing up, JADE support to subjective coordination is provided through asynchronous message passing – respecting agents’ autonomy thanks to the block-then-resume pattern – and built-in FIPA protocols—limiting instead autonomy due to reactiveness enforced by the callbacks framework.
Jason [10] is both an agent language and an agent runtime system. As a language, it implements a dialect of AgentSpeak [15]; as a run-time system, it provides some services needed to execute a MAS—e.g. agents’ reasoning engine and a nondistributed execution platform. Although Jason is entirely programmed in Java, it features BDI agents, so a higherlevel language (the Jason language) is used to program Jason agents using BDI abstractions. In Jason, autonomy of agents is supported by plan/intention concurrent execution machinery, whereas coordination adopts the subjective paradigm1 thanks to the asynchronous message passing layer.
Similarly to JADE behaviours, a Jason plan can be conceptually interpreted as a course of action to be performed to accomplish a task. Technically, a Jason plan differs considerably from JADE behaviours: (i) it is scheduled for execution as soon as a triggering event occurs, (ii) it is not directly executed “as is” (in general), but is instantiated as an intention, then executed, (iii) intentions are pseudo-concurrently executed one action each, according to a round-robin scheduler. Therefore, whereas in JADE the behaviour is the basic execution step, in Jason the same role is played by the single action, not by the plan/intention as a whole. Intentions may be suspended – either by the programmer or by the Jason reasoning engine – for a number of reasons—e.g. because the agent needs to wait for a message, or an environmental event.
Jason agents can in fact exchange beliefs (but also plans and goals), both synchronously and asynchronously through the same .send() internal action, in the form of messages encoded in a KQML-like language, with a very similar semantics. Depending on the illocutionary force determining the meaning of messages (e.g., askOne vs. tell), their reception causes different events (e.g., test-goal addition vs. belief addition) automatically triggering execution of the correspondent plans. It is worth noting that there is no explicit receive communication primitive involved, here, nor a mailbox to explicitly monitor2. The basic illocutionary forces concerned with exchanging beliefs are: • • tell, to share a (list of) belief(s) with a target (list of) agent(s). Addition of the communicated information to the belief base of the receiver agent, where it waits to be pro-actively considered, causes a belief addition event, handled by plans starting with the +b clause askOne to query another agent’s belief base—sort of a “remote test-goal” 3. The internal action askOne comes in three flavours: 1While objective coordination could in principle be implemented on top of Jason Environment Java API for programming MAS (computational) environments, it is not considered here since no first-class support for environment abstractions is provided.
2Actually, a mailbox exists, but the Jason agent is completely unaware of it.
3Actually, a test-goal is executed on the receiver agent side, thus, if plans starting with the +?b clause exist, they are triggered to handle the request. ◦ ◦ ◦ asynchronous, where the caller intention never gets suspended, and the query result has to be handled reactively through a proper plan handling the belief addition event +b synchronous, where the caller intention gets suspendend until the receiver’s reply becomes available—that is, a matching belief appears in its belief base timed synchronous, where the synchronism is limited by a finite upper bound on waiting time, whose expiration causes the intention to be resumed—and labelled with a timeout outcome It is worth noting that intentions only (not the whole Jason agent) are automatically suspended whenever they perform a (communication) action which cannot complete – e.g. the request for information following a test-goal attempt –, to be resumed as soon as the action obtains its “completion feedback” (see [10], page 86)—e.g. the message conveying the requested information. This mechanism may be interpreted as the equivalent of JADE block-then-resume pattern, which is automatically handled here by the Jason runtime.
Summing up, Jason support to subjective coordination is provided through both asynchronous and synchronous message passing, respecting agents’ autonomy thanks to the intention suspension mechanism—unlike J ADE, where blockingReceive() suspends the agent as a whole.
III.
In this section we briefly describe the approach to objective coordination adopted by the TuCSoN coordination model and technology, taken as a reference for artefact-based coordination and exploited in Section IV as the provider of objective coordination services.
TuCSoN [16] is a Java-based, (logic) tuple-based coordination model and infrastructure for open, distributed MAS. It provides objective coordination as service by implementing and extending the LINDA model [8] with ReSpecT tuple centres [17], the coordination artefacts [3] encapsulating coordination mechanisms and policies, distributed over a network of TuCSoN nodes.
TuCSoN preserves interacting agents’ autonomy through the Agent Coordination Context (ACC) [18] abstraction— mainly; TuCSoN architecture also contributes, as clarified below by describing TuCSoN “two-steps” execution. ACC are assigned to agents as they enter a TuCSoN-coordinated MAS, with the responsibility, among the many others, to uncouple the synchronism of a coordination operation invocation from the suspensive semantics of the coordination primitive used – e.g. LINDA in –, by mapping operations to events asynchronously dispatched to the coordination media (ReSpecT tuple centres).
More precisely, the suspensive semantics of getter primitives, as inherited by the LINDA model, implies that if no matching tuple is found the operation waits indefinitely until it becomes available. This semantics does not depend on agent own deliberation: it is set by the coordination model at hand, and is what enables distributed synchronisation and coordination, in the very hand. The synchronism of invocation instead, couples (or uncouples) the fate of a coordination operation with that of the invoker agent, and is subject to the agent own deliberation. This means that: in case the agent chooses the synchronous invocation mode, it gets suspended, too, if the operation gets suspended if the asynchronous invocation mode is used, instead, suspension policy is confined to the operation, whereas the invoker agent can continue performing its activities, pro-actively inspecting the status of the operation when preferred—and eventually getting the result In order to do so, the execution of any TuCSoN operation follows two steps: the request to carry out a given coordination operation is performed by the agent through its ACC, which then dispatches the corresponding operation event to the target tuple centre— invocation step the response to the coordination operation invoked is sent back to the requesting agent by the tuple centre through its ACC, as soon as the response is available— completion step • • • • Put in other terms, any coordination service provided by TuCSoN is asynchronous by default; nevertheless, interacting agents may deliberately choose the invocation synchronism of each coordination operation—potentially limiting their autonomy: either synchronous or asynchronous.
Summing up, TuCSoN coordination model preserves agent autonomy by uncoupling the suspensive semantics of coordination operations from their invocation semantics (synchronism) – actually promoting pro-activeness over reactiveness – thanks to the ACC architectural abstraction.
In this section we describe two software modules enabling TuCSoN-based multi-paradigm coordination for JADE and Jason agents, namely, TuCSoN4JADE (Subsection IV-A) and TuCSoN4Jason (Subsection IV-B) respectively, emphasising the technical solutions adopted to preserve conceptual integrity of the resulting development framework—especially, w.r.t. autonomy of agents. Subsection IV-C provides an example about how a widely spread and well-known coordination scenario, that is, a Contract Net Protocol based interaction, may benefit from a multi-paradigm coordination approach.
An autonomy preserving integration of JADE and TuCSoN was already presented in [11], with an emphasis on the impact that technical choices regarding concurrency and communication aspects have on the opportunities for objective and subjective coordination integration—also accounting for the conceptual issues of autonomy of interacting agents. There, the main issue was making TuCSoN synchronous invocation semantics compatible with JADE concurrency model based on behaviours.
The simplest and most straightforward solution would be letting JADE agents directly access TuCSoN services, requiring nothing more than a correct usage of TuCSoN API—since both technologies are implemented on top of Java. Nevertheless, direct API access would inevitably hinder JADE agents autonomy while resorting to objective coordination synchronously: their control flow would be coupled to that of the coordination operation requested, so that in case of suspension the whole agent would get stuck, not just the invoker behaviour. This way, roughly speaking, agents’ deliberate choice to exploit objective coordination could negatively affect their ongoing subjective coordination activities, as well as any other non-interactive activity in process. This would represent a glaring example of an artificial dependency (unintentionally) created by a “non-autonomy-preserving” approach to multiparadigm coordination.
Instead, an appropriate integration between TuCSoN and JADE was achieved in [11] by developing a bridge component in charge of suitably suspending and resuming JADE behaviours depending on the outcome of the requested TuCSoN coordination operation—besides providing a suitable API wrapping TuCSoN services to JADE agents: the TuCSoN4JADE bridge4.
In particular, the bridge is based on the fact that whenever any JADE behaviour is re-scheduled its action() method is re-started, thus the synchronous invocation of TuCSoN coordination operation is repeated. The whole TuCSoN4JADE machinery works because the invocation – through TuCSoN4JADE API method synchronousInvocation() – transparently checks whether the operation just invoked can be completed: in case the operation result is not available, yet, the request is actually dispatched by TuCSoN ACC to the target tuple centre, and the invoker behaviour is suspended by calling method block(). As soon as the operation result becomes available, the bridge component resumes the suspended behaviour and hands off the completion event—so that the second invocation, due to behaviour restart, immediately succeeds.
Summing up, TuCSoN4JADE lets JADE agents free to choose, for every single interaction event, which coordination paradigm suits their needs best, based on both design-time preference and run-time contingencies, without possibly hindering other ongoing coordination activities.
In the case of Jason, the main integration issue is to make TuCSoN synchronous invocation semantics compatible with Jason concurrency model based on intentions. In fact, simply wrapping the TuCSoN API into suitable Jason abstractions, such as internal actions, would inevitably hinder Jason agents autonomy while resorting to objective coordination synchronously: their control flow would be coupled to that of the coordination operation requested, thus in case of suspension the whole agent would get stuck, not only the invoker intention.
Yet again, agent deliberate choice to exploit objective coordination negatively affects their ongoing subjective coordination activities, thus resulting in another failed attempt
to fully enable multi-paradigm coordination. Thus, an adequate integration between TuCSoN and Jason requires a finegrained integration of TuCSoN two-steps execution mechanism with Jason intention suspension mechanism, properly suspending/resuming intentions based on coordination operations outcome: the TuCSoN4Jason bridge is the Java library providing such integration5.
First of all, we analyse the integration solution provided by TuCSoN4Jason from the architectural point of view, highlighting its main components—Figure 1: • • • a custom agent architecture enabling customisation of each Jason agent inner reasoning engine an operation completion listener enabling TuCSoN to couple Jason intention suspension mechanism with its invocation semantics a set of custom internal actions enabling Jason agents to request TuCSoN coordination services and inspect operations outcome The custom agent architecture, implemented by class T4JnArchImpl, is responsible for dispatching coordination operation requests from Jason agents to the TuCSoN service, keeping track of pending as well as completed operations (in collaboration with the other components), and coordinating the other TuCSoN4Jason components.
The operation completion listener, implemented by class TucsonResultsHandler, is responsible for handling notifications of operations completion coming from TuCSoN, for tracking them within the custom agent architecture, (automatically) resuming suspended intentions when their result becomes available, and unifying TuCSoN tuples (the operation results) with Jason variables.
The set of internal actions, implemented by the public classes within package t4jn.api extending TucsonInternalActionImpl, is responsible for providing Jason agents with the means to request TuCSoN coordination services, that is, basically, the set of available coordination primitives. Besides the usual tuple space primitives such as out, rd, and in, primitive getResult deserves special attention: it is responsible for uncoupling the request of a coordination operation from its completion, handling (automatic) intention suspension when the result of a getter primitive (such as in) is not yet available. 8 9
Whenever a TuCSoN operation is requested (message 1), 10 through Jason custom internal actions, the bridge component 11
12 – in particular, the custom agent architecture represented by 13 interface T4JnArch – takes care of asynchronously dispatch- 14 ing the request to TuCSoN (message 1.1) by exploiting TuC- 1156 } SoN services devoted to asynchronous operation invocation— 17 ... not depicted to keep the picture simple. Then it tracks the pending state of the requested operation (message 1.2) and spawns a dedicated handler for its completion (message 1.3)— TucsonResultsHandler. As soon as the operation is ready to be completed, the handler is notified by TuCSoN with the result (message 2), so that the state of the corresponding operation can be changed from “pending” to “completed” 21 /./..corresponding action caused suspension (message 2.1), and, if needed, resume the suspended intention 3 if (this.suspendedIntentions.containsKey(this.actionId)) { within which TuCSoN4Jason getResult() internal action 4 Intention suspendedIntention = this.suspendedIntentions was called (message 2.3, Figure 4). 56 this..rmeumtoevxe.(utnhliosck.(a)c;ti/o/nItdh)r;ead-safety
It is worth noting that the notification may happen at any- 87 C.i.r.cu//mstpaanrcsee cre=sultthis.ts.getC(); time, without prior knowledge on whether getResult() has 9 // scan pending intentions epiotihnetr, tbheeerne icsanlloedproiorrn(odte.sDiguna-ltliym, ef)rokmnotwheledJagseoonnawgehnetthsetra nthde- 111021 Iwtheirlae.tio(trie<krS.athtraoisrnN(ge)>x;ti(k))={c.getPendingIntentions().keySet() operation succeeded until getResult() is (synchronously) 13 String k = ik.next(); called. 1154 if (Ikn.tsetnatritosnWiith=(scu.sgpeetnPde.nSdUiSnPgEINnDtEeDn_tIiNoTn)s)(){.get(k);
In fact, any Jason custom internal action has an asyn- 1167 /i/f f(iin.deqcuoarlrse(sspuosnpdeinndgediInntteennttiioonn)) { chronous invocation semantics, that is, it does not wait for 18 i.setSuspended(false); operation completion, so that the agent is free to choose when 19 ik.remove(); to ask for it whenever it pleases (message 3)—deliberatively. 2210 c...r.es/u/meoItnhteerntreiaosno(in)e;r-related stuff When doing so, the TuCSoN4Jason bridge checks if the 22 } operation result is available (message 3.1): if it is, the agent 2234 } } gets it and the current intention can proceed (message 3.2); 25 } otherwise, the calling intention gets suspended (message 3.3, 26 ...
Figure 3), until the result becomes available.
Figure 3 shows a code excerpt taken from the getResult() custom internal action implementation. There, TuCSoN4Jason manipulates the state of the Jason reasoner behind any Jason agent – thanks to T4JnArchImpl extending Jason AgArch – so as to make it suspend the intention within which getResult() was called, in case no result is available yet. In particular, line 4 retrieves from the reasoner the current execution context (Circumstance), line 6 gets the current intention (the one where getResult() was called), lines 8 − 13 actually suspend the intention.
Figure 4, instead, shows a code excerpt taken from the TucsonResultsHandler() component implementation.
There, TuCSoN4Jason manipulates the state of the Jason reasoner so as to make it resume the intention within which getResult() was called, as soon as its result becomes available. In particular, line 4 tracks that such an intention is no longer pending, line 8 retrieves from the reasoner the current execution context, lines 10 − 15 iterate over pending intentions according to the reasoner state, line 17 finds the intention to be resumed among the ones being iterated over, lines 18 − 21 actually resume the intention.
Summing up, TuCSoN4Jason lets Jason agents free to choose, for every single interaction event, the coordination paradigm that best suits their needs, based on both designtime preference and run-time contingencies, without hindering any other ongoing coordination activities.
Subjective coordination based on asynchronous message passing, handled with a reactive programming style based on belief addition events (+b), can be seamlessly and simultaneously exploited by Jason agents while they are objectively coordinating based on either • • synchronous TuCSoN operations, emulated by following an operation invocation – asynchronous by deafult – with an immediate call to getResult() asynchronous TuCSoN operations handled adopting a pro-active programming style, e.g. calling getResult() as part of the Jason plan when the information is actually needed asynchronous TuCSoN operations handled adopting a reactive programming style, e.g. calling getResult() in a separate parallel plan dedicated solely to handling the operation result—e.g. storing it as a belief, thus triggering belief addition plans, or explicitly triggering dedicated plans processing the result
As a simple yet expressive example of multi-paradigm coordination, we describe a book trading scenario implemented as a Jason MAS—the example is included in TuCSoN4Jason distribution. In particular, we re-interpret the well-known Contract Net Protocol (CNP) [13] in a multi-paradigm coordination setting, where part of the protocol relies on synchronous tuplebased objective coordination – delivered by TuCSoN – and part on asynchronous message-based subjective coordination— built-in in Jason.
In short, n seller agents advertise their catalogue of books, whereas m buyer agents browse such catalogues looking for books. The whole interaction chain naturally follows FIPA Contract Net Interaction Protocol [20]: buyers start a call-forproposals, sellers reply with actual proposals, buyers choose which one to accept, the purchase is carried out. A fundamental requirement – called concurrency property in the following – is that sellers should stay reactive to call-for-proposals even in the middle of a purchase transaction—otherwise they could lose potential revenues. The book trading scenario is thus taken here as a paradigmatic example of the practical relevance of preserving autonomy while enabling multi-paradigm coordination.
Accordingly, we re-think the CNP by integrating objective and subjective coordination approaches: tuple-based call-forproposals with message-based purchase. In fact, since the callfor-proposals should reach all the sellers, putting a single callfor-proposals tuple in a shared contract-net space is more efficient than messaging each seller individually. On the contrary, since the purchase is typically a 1-to-1 interaction, messaging can efficiently do the job. As a result, this approach is not just conceptually correct, but also more efficient—less messages, less network operations, etc.
For the purpose of comparison, we first attempt to implement the MAS without exploiting TuCSoN4JADE, just directly calling TuCSoN API from within Jason with Jason internal actions without further concerns (Figure 5); then we repeat the same exercise by relying on TuCSoN4Jason (Figure 6). As one could expect, the result is that in the former case the concurrency property – thus, agent autonomy – is lost, whereas it is preserved as expected in the latter.
Figure 5 depicts one possible instance of the run-time interactions between a given seller and a given buyer. In particular, the seller is replying to a previous call-for-proposals (message 3b). Meanwhile, it is also ready to serve new incoming call-for-proposals (3a). Here is the problem: the suspensive coordination operation rd gets stuck until a callfor-proposals is issued by a buyer. This is fine: it is exactly for this suspensive semantics that the LINDA model works. What is not-so-fine is that the rd is stuck on a network-level call and no “defensive” programming mechanism has been implemented to shield the caller intention. Thus it is stuck too, hindering the caller agent from scheduling other intentions in the meanwhile—in particular, the “purchase” interaction chain (4b-5b) cannot carry on until a new call-for-proposals is issued.
The wide applicability of the CNP, as well as its suitability for implementation as a multi-paradigm coordination protocol – drawing from both objective and subjective, synchronous, and asynchronous approaches – makes the concept of multiparadigm coordination quite relevant in the context of agent development frameworks and coordination technologies—also making the need for suitable middleware components such as TuCSoN4Jason quite apparent.
In [21], CArtAgO [22] is integrated with three different agent development frameworks: Jason, 2APL [23], and simpA [24]. The approach taken is an example of autonomypreserving integration: e.g., in the case of Jason-CArtAgO, Jason intentions suspension mechanism is successfully integrated with CArtAgO artefacts by exploiting CArtAgO agent body abstraction. In particular, whenever a Jason agent requests execution of an operation on a CArtAgO artefact, the caller intention is automatically suspended until the “effector feedback” is received. Thus, nothing can hinder Jason agent autonomy if they simultaneously operate on artefacts while exchanging messages with other agents.
In [19], integration between JADE and TuCSoN technologies is successfully achieved, allowing JADE agents to exploit TuCSoN coordination services as part of the JADE platform. However, without preserving autonomy. JADE model of autonomy and TuCSoN model of coordination [11] were not considered: in fact, if a coordination operation gets suspended, the caller behaviour is unavoidably suspended, too, because of its single thread of control being stuck waiting for operation completion. This inevitably leads to the suspension of all other behaviours the agent is (possibly) concurrently executing. Roughly speaking, the agent choice to rely on objective coordination may affect its ongoing subjective coordination activities. This is a clear example of an artificial dependency (unintentionally) created by a “non autonomypreserving” approach.
VI.
Enabling multi-paradigm coordination along a number of orthogonal dimensions of coordination – such as objective vs. subjective stance, synchronism of coordination primitive invocation, reactiveness of the programming style promoted by the API – potentially brings about a wide range of communication, synchronisation, namely, coordination-related requirements to be satisfied, whenever the coordinables are provided with the ability to change the way they exploit coordination services at run-time, depending on preference or ever-changing, unpredictable contingencies.
For these reasons, technologies like TuCSoN4Jason and TuCSoN4JADE may be key-enablers in all those application scenarios featuring distributed and heterogeneous components which, on the one hand, heavily depends on communication and coordination to carry out their duties, on the other hand, may need to adopt diverse coordination paradigms depending on both their own capabilities and run-time contingencies. Such a sort of scenarios are usually dealt with by pervasive MAS [25], where, besides distribution and heterogeneity, also autonomy and (situated) intelligence typically play a key role: autonomy, for infusing the system with non-functional properties such as tolerance to failures, situated intelligence for improving the system effectiveness by leveraging reasoning over, e.g., contextual information.
The fact that Jason adopts the BDI model for agents, coupled with TuCSoN choice of working with first-order logic tuples, makes TuCSoN4Jason even more relevant for the aforementioned class of systems.
In the near future, we plan to further strengthen integration between TuCSoN and both Jason and JADE: for the former, private tuple spaces as belief bases and shared tuple spaces as environmental resources are both directions we wish to explore; for the latter, we envision automatic translation back and forth FIPA ACL messages and first-order logic tuples, as well as support for tuple-based FIPA interaction protocols.