-Social expectations and social dependencies are a key characteristic of interaction, which should be explicitly accounted for by the agent platform, supporting the coordination of the involved autonomous peers. To this aim, it is necessary to provide a normative characterization of coordination and give a social meaning to the agents' actions. We focus on one of the best-known agent platforms, Jade, and show that it is possible to account for the social layer of interaction by exploiting commitment-based protocols, by modifying the Jade Methodology so as to include the new features in a seamless way, and by relying on the notion of artifact, along the direction outlined in the Mercurio proposal.
Interaction creates social expectations and dependencies in the involved partners [38], [18], [34], [23]. These should be explicitly accounted for by the agent platform to allow the coordination of autonomous entities. In order to create social expectations on the agents’ behavior, it is necessary to introduce a normative characterization of coordination and give a social meaning to the agents’ actions. An agent that understands such a specification and that publicly accepts it (i.e. that declares it will behave according to it) allows reasoning about its behavior [21]. This is the key to the development of open environment systems, made of autonomous and heterogeneous components.
By not supplying such abstractions, current platforms do not supply agents the means for observing or reasoning about the social expectations involved by interaction, and do not supply the designers the means to explicitly express and characterize them when developing an interaction model. An important example is JADE [10], [11], which is a wellestablished development environment for multi-agent systems, FIPA-compliant, actually used for industrial applications, and which notoriously does not provide of a social and observational semantics.
One proposal for filling this gap is provided by the Mercurio framework [4], [3], where commitments and commitmentbased protocols, which are well-known for featuring a social and observational semantics [34], [35], [41], are introduced in JADE. Mercurio, however, is an abstract proposal. In this work, we describe an implementation of a system along the lines proposed in Mercurio. Our starting point for introducing commitment-based protocols inside JADE is the JADE Methodology [30]. This methodology is particularly interesting because it is intrinsically agent-oriented – it is not the adaptation of an object-oriented methodology, and it combines a topdown approach with a bottom-up one, allowing the integration with legacy, non agent-based systems. It concerns two of the four main phases of the standard software development cycle: the analysis phase and the design phase.
Following [4], we rely on a form of indirect communication among agents that envisages the use of artifacts: commitmentbased communication artifacts implement interaction protocols as well as monitoring functionalities for the verification that the on-going interaction respects the protocol, for detecting violations and violators, and so forth. Artifacts, therefore, encode the social layer of the multi-agent system: as a programmable communication channel an artifact contains what in the terminology of commitment protocols is called “the social state”, and captures it as an interaction session among the parties. Artifacts also supply agents the social actions that are necessary to the interaction – that is, actions that allow agents to enter into and to comply with commitments – together with their social meaning. As a consequence, they capture the coordination rules of the protocol. The reification of commitment protocols allows agents to act on them, e.g. to examine them (for instance, to decide whether to play one of the foreseen roles), use them (which entails that they explicitly accept the corresponding regulation), negotiate their construction, specialize them, and compose them. The advantage of relying on indirect communication is that it allows more variegated ways of interacting, not hindering message exchange when necessary.
In this paper we show that our proposal can be integrated seamlessly within the JADE Methodology, simply by substituting the selection of JADE FIPA protocols with the selection/construction of appropriate communication artifacts. We also use the methodology to show the differences between these two alternatives with the help of an example from a financial setting.
Section II reports the relevant background, necessary to understand the proposal. Section III is the core of the paper, containing the original proposal. Section IV applies the concepts to an illustrative example, from a financial setting. A discussion also involving related works ends the paper.
II.
We briefly report the technical, methodological and theoretical background required for our work. We use the proposal in [4] as a high-level reference architecture. In this work, the authors outline the basic ideas for an interaction-oriented agent framework, grounding the social semantics of interaction on commitments, and proposing the A&A (Agents and Artifacts) Metamodel as a means to obtain a form of indirect, observable communication. Let us, then, explain the fundamental bricks to build our architecture, whose overview is reported in Figure 1.
a) JADE framework.: JADE is a popular and
industry adopted agent framework. It offers to developers a Java
middleware 100% FIPA-compliant (Foundation for Intelligent
Physical Agents, [
b) Commitment Protocols.: Agents share a social state that contains commitments and other literals that are relevant to their interaction. A commitment C(x; y; r; p) denotes a contractual relationship between a debtor x and a creditor y: x commits to y to bring about the consequent condition p when the antecedent condition r holds. A commitment, when active, functions as a directed obligation from a debtor to a creditor. However, unlike a traditional obligation, a commitment may be manipulated, e.g., delegated, assigned, or released [37]. Importantly, commitments have a regulative value: the social expectation is that agents respect the commitments which involve them and, in particular, the debtor is considered responsible of realizing the consequent condition. Thus, the agents’ behavior is affected by the commitments that are present in the social state. A commitment protocol usually consists of a set of actions, whose semantics is shared (and agreed upon) by all of the interacting agents [41], [40], [20]. The semantics of the social actions is given in terms of operations which modify the social state by, e.g., adding a new commitment, releasing another agent from some commitment, satisfying a commitment, see [41].
c) CArtAgO.: CArtAgO is a framework based on the A&A model. It extends the agent programming paradigm with the first-class entity of artifact: a resource that an agent can use, and that models working environments ([32]). In order to properly model a MAS, CArtAgO proposes to explicitly model the environment where pro-active agents live, work, act and communicate. It provides a way to define and organize workspaces, logical groups of artifacts, that can be joined by agents at runtime and where agents can create, use, share and compose artifacts to support individual and collective, cooperative or antagonistic activities. The environment is itself programmable as a dynamic first class abstraction, it is an active part of a MAS, encapsulating services and functionalities. The A&A model decouples the notion of agent from the notion of environment. The overall engineering of the MAS results more flexible, easy to understand, modular and reusable. CArtAgO provides an API to program artifacts that agents can use, regardless of the agent programming language or the agent framework used. This is possible by means of the agent body metaphor: CArtAgO provides a native agent entity, which allows using the framework as a complete MAS platform as well as it allows mapping the agents of some platform onto the CArtAgO agents, which, in this way, becomes a kind of “proxy” in the artifacts workspace. The developed agent is the mind, that uses the CArtAgO agent as a body, interacting with artifacts and sensing the environment. An agent interacts with an artifact by means of public operations. An operation can be equipped with a guard: a condition that must hold so that the operation will produce its effects. It is not an execution condition: when the guard does not hold the action is performed anyhow but without consequences.
III.
ARTIFACTS
Artifacts naturally lend themselves to provide a suitable means for realizing mediated communication channels among agents. To this aim, it is necessary to encode inside a communication artifact a normative characterization to the actions it offers to agents and that allow them to interact. We propose to interpret commitment protocols as environments, within which agents interact. The public interface of artifacts allows agents to examine the encoded interaction protocol. As a consequence, the act of using an artifact can be interpreted as a declaration of acceptance of the coordination rules. This will generate social expectations about the agent’s behavior and agrees with the characterization of norms in [21]. Moreover, the fact that the behavior of agents on artifacts is observable and that interaction only occurs through artifacts, agrees with the view that regulations can only concern observable behavior [22]. The resulting programmable environment provides a flexible communication channel that is suitable for realizing open systems. Notice that the use of a programmable environment does not entail that the social state will be centralized because an artifact can be composed by a distributed network of artifacts.
Figure 1 sketches the way in which we propose to use CArtAgO so as to account also for social commitments inside JADE. We named this first realization of the Mercurio architecture 2COMM (standing for “Communication & Commitment”)1. 2COMM realizes mediated interaction by means of communication artifacts, which, in our proposal, replace the JADE-based FIPA protocols and which reify commitmentbased protocols [4]. At the bottom level, the JADE framework supplies standard agent services: message passing, distributed containers, naming and yellow pages services, agent mobility. When needed, an agent can enact a certain protocol role, thus using a communication artifact by CArtAgO. This provides a set of operations by means of which agents participate in a mediated interaction session. Each artifact (protocol enactment) maintains a social state, that is, a collection of social facts and commitments involving the roles of the corresponding protocol, following Yolum and Singh’s commitment protocol model [40].
1The source files of the system and examples are available at the URL http://di.unito.it/2COMM.
Commitments
[1…*] Social Facts
[0…*] CommitmentProtocol
ARTIFACT C Role m
Role n
Fig. 1. A sketch of 2COMM.
<< Artifact >>
CommitmentCommunicationArtifact Observable Properties socialState: SocialState enactedRoles: Role [1…*] Artifact Operations + send(message: Message): void + receive(): Message # create (commit: Commitment) # discharge (commit: Commitment) # cancel (commit: Commitment) # release (commit: Commitment) # assign (commit: Commitment, role: Role) # delegate (commit: Commitment, role: Role) # assertFact (fact: LogicalExpression) 1
1 1
SocialState commitments: Commitment [0…*] facts: SocialFact [0…*] context: CommitmentCommunicationArtifact + getFacts () + getCommitments() + addFact (fact: SocialFact) + addCommitment (commit: Commitment) + removeFact (fact: SocialFact) + removeCommitment (commit: Commitment) + getContext() 1 1
Role * # id: RoleId # agent: AID # artid: ArtifactId + createArtifact (artifactName: String, artifactClass: Class<? extends Artifact) : void + enact (roleName: String, artifact: ArtifactID, agent: AID) : Role + deact (role: RoleId, artifact: ArtifactID, agent: AID) : void
SocialFact 0…* predicate: String arguments: Object [0…*] + getPredicate () + setPredicate (pred: String) + getArguments () + setArguments (list: Object [1…*] ) + getFact ()
1…* 0…1
Commitment creditor: Role debtor: Role antecedent: SocialFact [1…*] consequent: SocialFact [1…*] status : enum {created, discharged, ...} + getCreditor() 0…* ++ sgeettCDreebdtiotorr()(role: Role) + setDebtor (role: Role) + getStatus () + setStatus (status: enum) Fig. 2. The UML Class diagram for the core of 2COMM.
A. Communication Artifact
We follow the ontological model for organizational roles proposed in [13], [14], which is characterized by three aspects: (1) Foundation: a role must always be associated with an institution it belongs to and with its player; (2) Definitional dependence: the definition of the role must be given inside the definition of the institution it belongs to; (3) Institutional empowerment: the actions defined for the role in the definition of the institution have access to the state of the institution and of the other roles, thus, they are called powers; instead, the actions that a player must offer for playing a role are called Communication artifacts realize a kind of mediated interaction that is guided by commitment-based protocols. Figure 2 shows the UML schema of the super-type of communication artifacts implementing specific interaction protocols (e.g., Contract Net, Net Bill, Brokering): the CommitmentCommunicationArtifact. We call an instance of an artifact of type CommitmentCommunicationArtifact an interaction session. It represents an on-going protocol interaction, with a specific social state that is observable by the interacting agents, that play the protocol roles. The CommitmentCommunicationArtifact presents an observable property, enactedRoles, that is the collection of the roles of the protocol (definitional dependence [13], [14]). Actions have a social effect only when they are executed by the role they are assigned to, but actions are not defined at this super level, rather they are provided by the instantiations of the CommitmentCommunicationArtifact, i.e. by artifacts implementing specific protocols. Each protocol action is implemented as a public operation, which is associated to a specific role (institutional empowerment [13], [14]): the fact that the action was executed is registered in the social state together with its meaning. An action can have some additional guards, implementing context preconditions: such a condition specifies the context in which it makes sense that the action produces the described social effect. An artifact can be monitored by an observer agent, who, following the CArtAgO terminology, is focusing on that artifact, particularly on one or more public properties. A change of one of these properties causes a signal, from the artifact to the observer agents, about the property that changed: the agents perceive the new artifact state. In particular, when the creation of a commitment, involving an agent as a debtor, is signaled to it, this agent is expected to behave so as to satisfy the commitment. The agent is free to decide how (and if) it will handle the satisfaction of its commitments. Therefore, the requirement is that an agent has the capability to behave so as to achieve the involved conditions [13], [14]. An agent who does not show such capabilities is bound to violate its commitments.
CommitmentCommunicationArtifact provides a property, tracking the identity of the agents actually playing the various role. Two operations are provided, by class Role, in order to manage the association between an agent’s identity and a role: enact and deact, by means of which an agent can explicitly assume/cease a protocol role (foundation [13], [14]). After enacting a role, the use of the associated operations on the artifact will have social consequences.
The communication artifact has an observable property, social state, that is a set of zero or more elements of type Commitment or Social Fact. As we can see in Figure 2, these structures are simple Java objects, representing the actual social state. The artifact is responsible to manage the Social State structure, i.e. the Commitments life-cycle, as well as the assertion or retraction of social facts, via methods called on commitment and on social fact objects. For Commitment management, we refer to the basic operations of commitment manipulation [40]: create, discharge, cancel, release, assign, delegate. The operations regarding the commitments life-cycle are implemented as artifact internal operations, therefore, the agents cannot modify commitments explicitly. The communication artifact exposes the social state, whose evolution is controlled by the agents via the protocol-provided actions. Finally, communication artifacts provide service operations, which can be performed only by the ArtifactManager Agent (see below) for managing the protocol roles and the identities of their players.
When the social state property changes, due to the execution of a protocol action (an artifact operation) on the communication artifact, all of the agents using the artifact will be notified, allowing them to react (or not) to the evolution of the interaction. This mechanism is a core part of the CArtAgO framework.
The ArtifactManager Agent plays the role of a Yellow Pages Agent for communication artifacts, or, in other terms, of an artifact broker. It has a crucial role: it is a “communication channel” broker, gathering requests for both focused or broadcasting calls for interaction. As such, it provides a collection of utility services. It supplies information about the interaction protocols (e.g. it provides the XML describing a given protocol, it allows a search for a protocol, a list of active communication channels, a list of interacting agents); it answers to requests about the status of an existing interaction session; it notifies the subscriber agents a particular session availability, and so on. Its main purpose is to prepare the communication artifact among the interacting agents, and to supply it to the requesting agents. It can also enable other interested agents to monitor, audit, or, more generally, observe the social state evolution. The communications between the ArtifactManager Agent and the requesting agents is realized via FIPA-ACL messages: when a requester sends a request ACL message to the ArtifactManager Agent, specifying the protocol and the role it wants to enact, the latter will do the following steps: 1) 2) 3) 4) 5) 6)
Check if the requested role is foreseen by the protocol; Create/retrieve a communication artifact of the requested type; Set the requested artifact role field to the agent identifier (AID) of the requester; Respond to the requester with the artifact’s reference; Possibly inform other interested agents of the availability of the communication artifact.
The initialization procedure is modeled as a simple FIPA Request Interaction Protocol, where the content of messages consists of the communication artifact request parameters. After this phase, the agent can use the enact operation to start playing the requested role. The use of an agent does not necessarily imply a centralization of the yellow pages: agents may directly create communication artifacts; yellow pages can be federated.
B. Using Mediated Communication at Design Time
We assume that MAS designers know a collection of communication artifacts, each representing a commitmentbased protocol. Each protocol is enriched with an XMLbased description of it, a Protocol Manual, available both at design- and at run-time. It is an add-on to the CArtAgO artifact manual, with orthogonal scopes and purposes. It can be used by MAS and agent designers as a guideline for understanding whether an agent is suitable for a protocol role as well as for understanding whether a protocol role suits the purposes of an agent. From a methodological point of view, the designer needs the Protocol Manual to know the social consequences of the actions supplied by an artifact, in terms of social facts and commitments, so he/she can design agent behaviors accordingly. Then, depending on the implemented behavior, the agent will decide how to use information about the social state evolution, how to fulfill commitments, which social action (i.e. a public artifact operation) to execute and when. Ideally, the designer should equip the agent with the behaviors that are necessary to bring about the conditions of the commitments it will possibly take. This protocol-centric design, jointly with the commitment nature of protocols, avoids a critical facet of JADE protocols. Here, a pattern of interaction is projected on a set of JADE behaviors, one for each role, thus making a global view of the protocol and its maintenance difficult, and binding the very interaction to ad-hoc behaviors. Consequently, the risk of conflicting behaviors, not devised at design time, increases. This way, the designer can leverage a library of programmable communication artifacts, focusing on the internal agent behavior without being concerned about ad-hoc shaped communication behaviors.
The JADE Methodology is a JADE founded agent-oriented software engineering methodology. It proposes a fully agentbased approach, instead of adapting Object-Oriented techniques (like MASE [39], Adelfe [12] or MESSAGE [16]). It concerns the analysis and the design phases of the software development life cycle. The methodology considers agents as “pieces of autonomous code, able to communicate with each other” [30], thus following a weak notion of agency; it does not account for mentalistic/humanistic agents properties.
In the analysis phase, the first step is the identification of use cases, i.e. functional requirements of the overall system, which are captured as standard Use-cases UML Diagrams. Starting from this, the designer can point out an initial set of agent types: an agent type for each user/device and for each resource. The agent paradigm foresees that even external devices and software/hardware resources (e.g. legacy systems, databases, external data sources) are represented with an agent. The designer, then, identifies responsibilities, i.e. the activities provided by system each agent is responsible for; and acquaintances, that is relationships between agents aimed at fulfilling some responsibility. The results are a Responsibility table and an Agent diagram with initial acquaintances. No distinction is made between acquaintances and responsibilities: in fact, the mentioned table will contain both. The analysis is completed by executing activities related to agents/acquaintances refinement, to define discover services and to add management/deployment information. The design phase starts with the interaction specification step, where an interaction table is produced. It refers to the responsibility table in order to define interactions between JADE agents, specifying the interacting agents, the protocol and protocol role (e.g. Initiator or Responder), the reference responsibility, and a triggering condition.
It is suggested to use, when possible, standard JADE projade.core.Agent
JADE jade.corJeA.BDeEhaviour
<<plays>> Agent1
Agent1Behaviour <<Satisfies: C1>> Agent2
Agent2Behaviour <<Satisfies: C2>> jade.core.Agent
JADE jade.core.Behaviour
ContractNetInitiatorBehaviour +prepareCfps(ACLMessage cfp) +handlePropose() +handleRefuse() +handleInform() +handleFailure()
Agent1Behaviour +prepareCfps(ACLMessage cfp) +handlePropose() +handleRefuse() +handleInform() +handleFailure() <<hasBehaviour>>
Contract Net Protocol ContractNetParticipantBehaviour +handleCfp(ACLMessage cfp) +handleAcceptProposal() +handleRejectProposal() +prepareResultNotification()
Agent2Behaviour ++hhaannddlleeACcfpc(eApCtPLrMopeosssaagl()e cfp) +handleRejectProposal() +prepareResultNotification() tocol behaviors, that must be added to an agent’s behavior set to implement the corresponding protocol role. The subsequent steps focus on the specification of agent interactions with users and resources; the definition of a yellow page services, using the JADE Directory Facilitator; the implementation of agent behaviors, starting from JADE protocol behaviors related to responsibilities. A last effort is the definition of a shared, system-wide ontology.
We show how it is possible to integrate, within the JADE Methodology [30], an account of commitment-based protocols with the help of a real-world scenario, we call FinancialMAS. For brevity, we show only the fundamental steps needed to draft the system and to highlight the benefits of reifying commitment-based protocols by means of artifacts, and thus based on mediated interaction. By applying the steps of the methodology, we obtained an initial design prototype for FinancialMAS, concerning an initial set of agents and the so called responsibility table (Table I). In the terminology of the JADE Methodology, responsibilities amount to functional duties, agents are responsible for, from an overall MAS point of view. To handle them, agents possibly need to interact with one another. The result of this analysis is an Interaction table (Table II). At this point, instead of realizing protocols via distributed JADE behaviors, we implement them via commitmentbased communication artifacts. We assume to have already designed artifacts for common interaction protocols, like the Contract Net Protocol, the Query Protocol, and the Request Protocol. The resulting model is depicted in Figure 3. For the sake of comparison, in Figure 4 we zoomed into the one of the commitment artifacts, the Contract Net Protocol artifact, reported as a UML diagram, while in Figure 5 we highlight the very same protocol, implemented via pure JADE behaviors.
2COMM proposes a clear notion of Role that an agent must enact to participate in an interaction session, so the designer must only implement the behaviors for fulfilling the commitments caused by the execution of a protocol actions. We refer to the following description of CNP based on commitment protocols (this is just an example, alternatives and variants can be found in papers like [42], [24]): cfp means create(C(i, p, propose, accept _ reject)) accept means none reject means release(C(p, i, accept, done _ failure)) 2COMM aa###+++ArgIiaacdetDdeirfrgen:)aneteaaiRtcda::ncct:tvoCAttteAo:l((AIelAirrarDdIootrsIdit)fDlliseeaf:a::NcRcCtRaItodloma(lealseersIt:di<fSa,?tcaRreitrnNotxigfltaaee,mcnatder:ts:AifSaArtctirrfttiai:nfcaAgtcr,ItDti)f,a:acvtgoIDeidn,t: s####e#++OonbrccadrscaeersaeisiscelcaesnnectCaelircedaSghvtioed(vsenatammlaeeRrb(((tg(ecolccem()eeco:sool:eosimMPmm(Stsacmmr:omemmogomcRsemeipiitisttnao:i:e::<tmatl:lMCrCC<eSgCtCiitoeeooteAo:[aom1smmsCmtrm…setmmmoaimmfm*giaiit]ttuimemmctmmn)te:eeiit>encvnnmn>toatt),)etit)dirnootnl)eA:rRtioflaec)t # delegate (commit: Commitment, role: Role) # assertFact (fact: LogicalExpression)
Contract Net Protocol +++ rcaefcpjce(etc<ape<stt((kR)):::eTvvIqanoousiiidtdikira)e:tsov:orCid1>> + +++Arrcateifcfpjacece(cptptrOt(o)(p:p)evo:rosvaiadotlii:odPn<sr<opAoCrstaNiflaP)c:tv>o>id <<plays>> ++++ frpdaeroifolnuupesroee()s((:)et<:av(<vsopRkoirdPo:iedpaTqoarutssiiackre)li:p:sPva:ornCoitdp2o>s>al): void +++++ frpdaeroifolnuupesroe(e)s((:)et:av(vsopokirdo:idpToassak)l::Pvoroidposal): void Fig. 4. The UML diagram for the 2COMM implementation of CNP.
Agent1
Agent2 <<hasBehaviour>> propose means create(C(p, i, accept, done _ failure)) refuse means release(C(i, p, propose, accept _ reject)) done means none failure means none In the case of CNP, two roles are foreseen, Initiator (i) and Participant (p). Playing a role gives an agent powers, in terms of social state modification (i.e. the state of the interaction session) as a consequence of its actions, and the agent designer can use them if, when and how he/she wants. For instance, for what concerns the update of the social state, when an agent playing the role Initiator executes the artifact action cfp, the social state is modified by creating the commitment C(i, p, propose, accept _ reject). On the one hand, this change binds i to either accept or reject a proposal, if one is received; the agent is free to decide not only which course of action to take but also how to realize acceptance or rejection. On the other hand, this change is signaled to the agent playing the role Participant, who will handle it in some manner (depending on its behaviors) and decide whether sending a proposal. Instead, when a accept is executed the raised event automatically discharges a commitment created by a cfp.
This approach is illustrated in Figure 4. We modeled CNP as a Commitment Communication Artifact. Roles are inner classes within the artifacts, allowing JADE agents to use them. The protocol consists of a set of social actions, each of which has both an impact on the social state of the interaction and on the communication between agents. Actions are attributed to roles. For instance, action cfp is attributed to the role Initiator. For what concerns communication, the execution of a social action amounts to sending the content to be communicated through the tuple space provided by CArtAgO. This result is obtained by exploiting the method send of the CommitmentCommunicationArtifact. Commitments are handled as an instance of the class SocialState which is part of the CommitmentCommunicationArtifact. For example, consider the social action cfp, whose execution creates a commitment. This result is achieved through the execution of the following artifact operation: @OPERATION public void cfp(Task task, Role initiator, Role participant) {
Message cfp = new Message(); // setting of cfp parameters send(cfp); create(new Commitment(initiator, participant, new Fact(‘‘propose’’), new CompositeExpression(
} FP FP BA BA IA IA FV IA IA FP
LogicalOperatorType.OR, new Fact(‘‘accept’’), new Fact(‘‘reject’’))));
The first part of the operation manages the communication level, while the latter manages the creation of the commitment. The action cfp attributed to the role Initiator merely calls the described artifact operation.
An agent that will to play as a certain role can inspect the commitments that are required by the role itself, which are the commitments it will possibly be involved in as a debtor. In order to be able to satisfy them, the agent needs to have appropriate behaviors, otherwise its role execution is bound to fail. Notice that the agent is autonomous in selecting which social actions to execute and when as well as how to behave in order to satisfy its commitments.
Looking at Figure 5, the reader can perceive a major drawback of the original JADE approach: being part of an interaction protocol entails the adoption of an entire behavior, that must be added to the set of the internal agent behaviors. The resulting agent design breaks the autonomy of the agent, since the agent has an additional behavior for each role of each interaction it takes part to, increasing the possibility of conflicts between behaviors, and increasing the overall agent design complexity. In fact, being such behaviors FSMBehaviors, they implement Finite State Machines, i.e. they rigidly prescribe the sequences of actions that the agent is allowed to execute without any flexibility. Thus, it is not possible to intervene on the logic by which actions are sequentialized but only to realize the methods that the predefined behavior requires to redefine, which roughly correspond to decision points. Furthermore, this approach hinders the observability of the interaction, unless the designer adds specific sniffing or audit agents to log every message passed. In performance-critical applications, having more agents and producing a message overhead can produce undesirable scenarios.
RELATED WORKS, DISCUSSION AND FUTURE WORK 2COMM is a first step towards the implementation of the Mercurio architecture, proposed in [3], [4]. It realizes a programmable communication channel by means of artifacts, which is interaction-centric, exploits the social meaning of interaction supplied by commitment protocols, and enables the development of monitoring functionalities. The realization of roles is inspired by [8], [9]. The use of commitments gives a normative value to the encoded protocol, while the act of using a communication artifact amounts to the explicit acceptance, by the agent, of the rules of the protocol. This makes the current proposal very different from [7], whose aim was the introduction of the notion of role, as in [8], [9], inside JADE. The proposal conjugates the flexibility and the openness that are typical of MAS with the need of modularity and compositionality that are typical of design and development methodologies. The realization of commitment protocols as artifacts is an advancement of research on commitment-based approaches, w.r.t. approaches like [19], where commitment management resides in a middleware which, in turn, relies on a message-exchange communication infrastructure. Even though the function of the middleware recalls that of our artifacts, artifacts are, by their nature, distributed (and not centralized), they can be the result of the composition of other artifacts, can be manipulated and customized by the agents themselves. Moreover, the adoption of tuple spaces allows more variegated forms of communication where communication actions are not limited to utterances.
We believe that a commitment approach brings relevant advantages in terms of design and modeling flexibility, modularity and traceability. The resulting artifact explicitly provides a notion of Role that is decoupled from the interacting agent, instead of cabling it into an agent behavior (as in the JADE Methodology) or of composing different atomic roles to build an agent type (as in the GAIA Methodology [43]). Both approaches break into inner agent definitions, hindering the agent autonomy and the openness of the system. The artifact entity supplies a natural way for logging and audit purposes, leveraging the concept of social state (and its evolution). In a pure agent environment (like JADE), a similar result is obtained via a massive use of either message-sniffing agents and/or auditing agents, with a consequent overhead of the number of messages that are passed. This is, for example, the case of the proposal in [29]. By being an observable property, the social state provides the agent society a clear vision of who is responsible of what, in which protocol interaction, and when an agent acted so as to fulfill its commitments.
2COMM focuses on the interaction protocol layer, leaving
aside issues concerning the society of agents in which the
interaction takes place. Thus, it does not, for instance, tackle how
to deal with violations of commitments. In order to properly
handle these aspects it would be interesting to combine its
use with proposals from the area of e-institutions. Concerning
this field 2COMM would provide an improvement in that it
would introduce the possibility to account for indirect forms of
communication. As [25] witness, there is an emerging need of
defining a more abstract notion of action, which is not limited
to direct speech acts, whose use is not always natural. Along
this direction, it is relevant to mention the OCeAN meta-model
for artificial institutions [26], which encompasses a notion of
commitment, and for which a possible architecture is discussed
in [31]. For what concerns organizations, instead, there are
some attempts to integrate them with artifacts, e.g. ORA4MAS
[
Finally, we think that our proposal can give significant contributions in industrial applicative contexts, for the realization of business processes and, in particular, of humanoriented workflows, whose nature is intrinsically social and where the notion of commitment plays a fundamental role [28]. In [36], the authors present LoST, a commitment-based model for the definition of declarative protocols, which is based on local history vectors of sent/received messages, associated to each of the interacting agents. LoST enables the representation and monitoring of (business) protocols when it is necessary to transfer local knowledge about occurring interactions between the agents. It works as an adapter for message transfer between agents. 2COMM, instead, provides agents an environment by which they communicate and, if this is requested, they can perform actions which do not amount to utterances but still entail social effects.
As a future work, we devise an extension of 2COMM for tackling a more expressive protocol language, with support for temporal constraints, see also [2]. This goal can easily be achieved by defining new artifact types that provide developers the appropriate protocol language primitives, such as those offered by 2CL [6][5].
Acknowledgments.: The authors would like to thank the reviewers for their comments and the participants to the EMAS 2013 workshop for the discussions.
M. Dastani, D. Grossi, Meyer. J.-J. Ch., and N. A. M. Tinnemeier.
Mohamed El-Menshawy, Jamal Bentahar, and Rachida Dssouli. Symbolic model checking commitment protocols using reduction. In DALT, volume 6619 of Lecture Notes in Computer Science, pages 185–203. Springer, 2010.