-Current agent platforms do not provide agents the means for reasoning about expected behaviours during interactions. This lack is due to the absence of design primitives to explicitly shape interaction patterns as first-class resources. This work presents 2COMM4JADE, a framework based on JADE and CArtAgO platforms that allows definition of social relationships among parties, represented by social commitments, decoupled from the agent design itself.
I. INTRODUCTION AND MOTIVATION
Multi-Agent Systems (MAS) represent a preferred choice for building complex systems, where the autonomy of each component represent a major requirement. Agent-oriented software engineers can choose from a substantial number of agent platforms [19], [8], [14], [5]. Platforms and frameworks like JADE [6], TuCSoN [22], DESIRE [9], JIAC [27], all provide coordination mechanisms and communication infrastructures [8]. We claim, however, that none of the current infrastructures for MAS is adequate to really preserving autonomy, and do not fit the high degree of decoupling often required by such systems. This can be obtained only via a clear separation of the agent specification from the coordination specification, that avoids any “hard-coding” of the regulations of the system inside the activities of the participants. To this aim, we propose to explicitly represent interaction patterns among agents in terms of normatively defined social relationships; the normative characterization is grounded on commitments, which feature a social and observational semantics [25]; in order to represent the coordination requirements we propose to rely on commitment-based protocols [29].
The framework we propose, 2COMM4JADE, uses JADE as basic agent platform, which provides a FIPA compliant communication framework and an agent-developing middleware. JADE does not offer an agent programming language, but it is a sound, well-established and industry-adopted agent framework. Although the first release was presented in 2007, a dynamic community helps developers in updating and evolving the platform, providing new functionalities and capabilities.
Thus, it supplies a valuable starting ground.
In order to reify the social relationships we rely on the Agents & Artifacts meta-model (A&A) [28], [21], which provides abstractions for environments and artifacts, that can be acted upon, observed, perceived, notified, and so on. When embodied inside artifacts, social relationships can be examined by the agents (to take decisions about their behavior), as advised in [11], used (which entails that agents accept the corresponding regulations), constructed, e.g., by negotiation, specialized, composed, and so forth. Last but not least, the use of artifacts enables the implementation of monitoring functionalities for verifying that the on-going interactions respect the commitments and for detecting violations and violators.
Summarizing, this work proposes to introduce in MAS an explicit notion of social relationships, captured as commitments (Section II). Social relationships are actual resources, implemented through artifacts, that are made available to the agents, and are first-class entities of the model, as well as agents. The framework 2COMM4JADE (Section III) realizes the proposal based on an extension of JADE and of CArtAgO.
We show the impact of the proposal on programming by means of an example (Section IV).
II.
MODELING SOCIAL RELATIONSHIPS
We propose to explicitly represent social relationships among the agents. By social relationships we mean normatively defined relationships, and the expected patterns of interaction, between two or more agents, resulting from the enactment of roles, and subject to social control. We envisage both agents and social relationships as first-class entities that interact in a bi-directional manner. Social relationships are created by the execution of interaction protocols and provide expectations on the agents’ behaviour. It is, therefore, necessary to provide the agents the means to create and to manipulate, and to observe, to monitor, to reason and to deliberate on social relationships so to take proper decisions about their behaviour. We do so by exploiting properly defined artifacts, that reify both interaction protocols, defined in terms of social relationships, and the sets of social relationships, created during protocol execution. Such artifacts are made available to agents as resources.
The aim of our proposal is to clearly decouple the interaction design from the agent design, using artifacts to encode the coordination logic. Commitment-based protocols provide a means of coordination, based on the notification of social events, e.g. the creation of a commitment. Interacting agents use artifacts to coordinate and interact, depending on the roles they play and on their objectives. Such a decoupling avoids interaction logics hard–coded in agent programs, that can lead to an increasing developing effort and a difficult maintenance of the system, especially when it constitutes a society of autonomous entities belonging to different organizations. Instead, relying on commitment-based protocols allows a modular definition of components of the system and of how they interact, using the notion of commitment to define the shape and the evolution of interaction patterns.
A commitment [24] is represented with the notation C(x; y; r; p), capturing that the agent x commits to the agent y to bring about the consequent condition p when the antecedent condition r holds. Antecedent and consequent conditions generally are conjunctions or disjunctions of events and commitments. When r equals >, we use the short notation C(x; y; p) and the commitment is said to be active. Commitments have a regulative nature, in that debtors are expected to behave so as to satisfy the engagements they have taken. This practically means that an agent is expected to behave so as to achieve the consequent conditions of the active commitments of which it is the debtor.
Agents share a social state that contains commitments, and update it as a result of performing their activities. Specifically, the manipulation of commitments is done by means of the standard operations create, cancel, release, discharge, assign, delegate. As in [24], we postulate that discharge is performed concurrently with the actions that lead to the given condition being satisfied and causes the commitment to not hold.
Delegate and assign transfer commitments respectively to a different debtor and to a different creditor. For details see [24], [29], [10].
The next question to answer is how to integrate, inside the outlined agent and artifact setting, the rules that regulate the process by which social relationships are created and manipulated. In our proposal, this is done by relying on the notion of commitment-based interaction protocol. This kind of protocol consists of a set of actions (process activities), whose semantics is shared, and agreed upon, by all of the participants to the interaction [29], [10]. The semantics of the social actions is given in terms of the operations which allow the modification of the social state and that have already been described.
From an organizational perspective, a protocol is structured
into a set of roles. Roles and agents are different entities,
and we assume that roles cannot live autonomously: they exist
in the system in view of the interaction, because agents, for
interacting, use artifacts and execute actions on them. We
follow the ontological model for roles proposed in [7], and
brought inside the object-oriented paradigm in [4], which is
characterized by three aspects: (
Following [12], we need social relationships to be recognized as having a normative force (so that they will provide social expectations on the stakeholders’ behaviour), to be accepted explicitly by the participants to the interaction, to be inspected so as to allow stakeholders to decide whether conforming to them. To this aim, we propose to explicitly model social relationships as resources, that are made available to the interacting peers, in the very same way as other kinds of resources; a resource that has to be inspectable, and therefore can not be modeled as an agent. To solve this issue, we adopt the Agents and Artifacts (A&A) meta-model [28], [21], that extends the agent paradigm with another primitive abstraction, the artifact. An artifact is a computational, programmable system resource, that can be manipulated by agents, residing at the same abstraction level of the agent abstraction class. For their very nature, artifacts can encode a mediated, programmable and observable means of communication and coordination between agents.
We interpret the fact that an agent uses an artifact as the explicit acceptance, by the agent, of the regulation encoded by that artifact, and modeled by the interaction protocol that the artifact reifies. This is an important aspect because it allows the interacting parties to perform practical reasoning, based on expectations: participants expect that the debtors of commitments behave so as to satisfy the corresponding consequent conditions; when this does not happen, a violation is raised. Relying on artifacts allows also other kinds of manipulation, including (but not limited to) an agent playing a role in the interaction, and an agent observing the interaction that is being carried on.
Summarizing, we claim that an agent-based framework should satisfy the following requirements: 1) Explicit representation of the social relationships, created and evolving along the interaction. 2) Social relationships should be firstclass objects, which can be used for programming the agent behavior. 2COMM4JADE fulfills both.
III. 2COMM4JADE: A COMMITMENT-BASED
INFRASTRUCTURE FOR SOCIAL RELATIONSHIPS
After providing the background, we describe the developed implementation framework, that we named 2COMM4JADE.
The focus is to provide adequate support for programming social relationships by exploiting a declarative, interactioncentric approach and by relying on existing technologies as far as possible. Specifically, the implementation framework combines two well-known platforms: JADE [6] and CArtAgO [23]. JADE agents represent stakeholders, commitment-based interaction protocols are realized as CArtAgO artifacts.
JADE is a popular and industry-adopted agent framework. It offers to developers a Java middleware that is FIPA-compliant [17]. Its robustness and well-proven reliability makes JADE a preferred choice in developing MAS. A JADEbased system is composed of one or more containers, each grouping a set of agents in a logical node and representing a single JADE runtime. The overall set of containers is called a platform, and can spread across various physical hosts. The resulting architecture hides the underlying layer, allowing support for different low-level frameworks (JEE, JSE, JME, etc.). JADE provides communication and infrastructure services, allowing agents, that have been deployed in different containers, to discover and interact with each other.
CArtAgO is a framework based on the A&A meta-model [28], [21]. 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. It provides a way to define and organize workspaces, that are logical groups of artifacts, that can be joined by agents at runtime. The environment is itself programmable and encapsulates services and functionalities. 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 former 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, which can be equipped with guards: conditions that must hold in order for operations to produce their effects. When guards do not hold, actions can still be performed but without consequences.
Agent Platform
A&A Platform
Artifact
CArtAgO
Agent
2COMM4JADE is organized as follows. JADE supplies standard agent services, i.e. message passing, distributed containers, naming and yellow pages services, agent mobility.
When needed, an agent can enact a protocol role, which provides a set of operations by means of which agents participate in a mediated interaction session. Protocol roles are provided by communication artifacts, that are implemented by means of CArtAgO. Each communication artifact corresponds to a
Agent ACLMessage
Behaviour
1...n << Artifact >>
CommunicationArtifact Observable Properties enactedRoles: Role [1…*] tset: TupleSet Artifact Operations + in(message: RoleMessage): void + out(): RoleMessage #checkRoleRequirements(roleName: String, offeredBehaviour:Behaviour) << Artifact >>
ProtocolArtifact Observable Properties socialState: SocialState Artifact Operations # 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)
SocialState commitments: Commitment [0…*] facts: SocialFact [0…*] context: CommitmentCommunicationArtifact + getFacts (): SocialFact[ ] + getCommitments(): Commitment [ ] + addFact (fact: SocialFact) + addCommitment (commit: Commitment) + removeFact (fact: SocialFact) + removeCommitment (commit: Commitment) + getContext(): CommitmentCommunicationArtifact + + << Role >>
CARole + send(message: RoleMessage) + receive(): RoleMessage << Role >>
PARole + hasCommitmentInvolving(c: Commitment): boolean + socialFactExists(f: + SocialFact): boolean ...query operations on SocialState ...
SocialFact predicate: String arguments: Object [0…*] + getPredicate (): String + setPredicate (pred: String) 0…* ++ sgeettAArrgguummeennttss ((l)i:stO: bOjebcjetc[t][1…*] )
1…*
Commitment creditor: Role debtor: Role antecedent: SocialFact [1…*] consequent: SocialFact [1…*] status : enum {created, discharged, ...} 0…* ++ sgeettCCrreeddiittoorr(()r:oRleo:leRole) + getDebtor (): Role + setDebtor (role: Role) + getStatus (): Role + setStatus (status: enum)
2COMM4JADE
Role # id: RoleId # agent: AID # artid: ArtifactId # player: Behaviour + createArtifact (artifactName: String, artifactClass: Class<? extends Artifact>) : void + enact (roleName: String, artifact: ArtifactID, agent: AID, offeredPlayerBehaviour: Behaviour) : Role + deact (role: RoleId, artifact: ArtifactID, agent: AID, offeredPlayerBehaviour: Behaviour) : void << interface >>
ProtocolObserver + handleEvent (event: SocialEvent, args: Object[ ]) specific protocol enactment and maintains an own social state and an own communication state.
Figure 1 reports an excerpt of the 2COMM4JADE UML class diagram1. Let us get into the depths of the implementation:
CommunicationArtifact (CA for short) provides the basic communication operations in and out for allowing mediated communication. CA extends an abstract version of the TupleSpace CArtAgO artifact: briefly, a blackboard that agents use as a tuple-based coordination means. In and out are, then, operations on the tuple space. CA also traces who is playing which role by using the property enactedRoles.
Class Role extends the CArtAgO class Agent, and contains the basic manipulation logic of CArtAgO artifacts. Thus, any specific role, extending this supertype, will be able to perform operations on artifacts, whenever its player will decide to do so. Role provides static methods for creating artifacts and for enacting/deacting roles. This is done by passing a reference to the JADE agent behaviour that will actually play the role.
The class CARole is an inner class of CA and extends the Role class. It provides the send and receive primitives, by which agents can exchange messages. Send and receive are implemented based on the in and out primitives provided by CA.
ProtocolArtifact (PA for short) extends CA and allows modeling the social layer with the help of commitments. It maintains the state of the on-going protocol interaction, via the property socialState, a store of social facts and commitments, that is managed only by its container artifact. This artifact implements the operations needed to manage commitments (create, discharge, cancel, release, assign, delegate). PA realizes the commitment life-cycle and for the assertion/retraction of facts. Operations on commitments are realized as internal operations, that is, they are not invokable directly: the protocol social actions will use them as primitives to modify the social state. We refer to modifications occurred to the social state as social events. Being an extension of CA, PA maintains two levels of interaction: the social one (based on commitments), and the communication one (based on message exchange).
The class PARole is an inner class of PA and extends the CARole class. It provides the primitives for querying the social state, e.g. for asking the commitments in which a certain agent is involved, and the primitives that allow an agent to become, through its role, an observer of the events occurring in the social state. For example, an agent can query the social state to verify if it contains a commitment with a specific condition as consequent, via the method existsCommitmentWithConsequent (InteractionStateElement el).
1The source files of the system and examples are available at the URL http://di.unito.it/2COMM.
Alternatively, an agent can be notified about the occurrence of a social event, provided that it implements the inner interface ProtocolObserver.
Afterwards, it can start observing the social state.
PARole also inherits the communication primitives defined in CARole.
The class SocialFact represents a fact of some relevance for the ongoing interaction, that holds in the current state of interaction. A social fact is asserted for tracking the execution of a protocol action. Actions can have additional effects on the social state; in this case, corresponding social facts are added to it.
In order to specify a commitment-based interaction protocol, it is necessary to extend PA by defining the proper social and communicative actions as operations on the artifact itself. Actions can have guards that correspond to context preconditions: each such condition specifies the context in which the respective action produces the described social effect. Since we want agents to act on artifacts only through their respective roles, when defining a protocol it is also necessary to create the roles. We do so by creating as many extensions of PARole as protocol roles. These extensions are realized as inner classes of the protocol: each such class will specify, as methods, the powers of a role. Powers allow agents who play roles to actually execute artifact operations. The typical schema will be: g / / MY PROTOCOL ARTIFACT OPERATIONS @OPERATION p u b l i c v o i d op1 ( . . . ) f / / p r e p a r e a message , i f n e e d e d ; i n t h a t c a s e , s e n d ( message ) ; / / modify t h e s o c i a l s t a t e , / / e . g . c r e a t e commitment , u p d a t e commitment 1 p u b l i c c l a s s M y P r o t o c o l A r t i f a c t 2 e x t e n d s P r o t o c o l A r t i f a c t f 3 / / . . . 4 s t a t i c f 5 a d d E n a b l e d R o l e ( "Role1" , Role1 . c l a s s ) ; 6 a d d E n a b l e d R o l e ( "Role2" , Role2 . c l a s s ) ; 7 / / . . . 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 g 23 / / d e f i n e s o c i a l a c t i o n s f o r Role1 24 p u b l i c v o i d a c t i o n 1 ( . . . ) f 25 d o A c t i o n ( t h i s . g e t A r t i f a c t I d ( ) , 26 new Op( "op1" , . . . , g e t R o l e I d ( ) ) ) ; 27 g 28 / / . . . 29 g 30 p u b l i c c l a s s Role2 e x t e n d s PARole f 31 / / . . . 32 g 33 / / . . . 34 g g / / . . . / / INNER CLASSES f o r ROLES p u b l i c c l a s s Role1 e x t e n d s PARole f p u b l i c Role1 ( B e h a v i o u r p l a y e r , AID a g e n t ) f
s u p e r ( "Role1" , p l a y e r , a g e n t ) ;
Let us, now, consider Figure 2, which sketches how the agent model reacts to a new social event occurrence. For a JADE agent to play a role, one of its behaviours must implement the method handleEvent, which receives the event just occurred in the social state. The agent programmer <<interface>>
ProtocolObserver + handleEvent(SocialEvent e, Object … args)
RoleBehaviour + handleEvent(SocialEvent e, Object … args) 2. activate behaviors according to social events <<behaviour for event a >> + action() <<behaviour for event b >> + action() . . . . <<behaviour for event n >> + action()
JADE Agent 1. sense the social state 3. schedule behavior execution Behaviour Repository Social CommStuantiecation
State will simply implement the logic for handling that event, adding proper behaviour(s) to the agent’s behaviour repository. When scheduled, the behaviour will be executed, and the event handled. A methodological schema for handling a social event follows.
Algorithm 1: Methodological Schema for Handling Social Events.
Data: Social event se notified to agent a Data: Set S of social events of interest Result: Add a behaviour to the behaviour set of a Check whether se involves a commitment c which has a as debtor or creditor; if se 2 S then b = behaviour that handles the occurred modification of c; add b to the set of behaviours of a; end
The proposed algorithm explains how to use the notifications performed by the protocol artifact to the agent. Depending on which social event occurs, i.e. on which commitment is modified and how (e.g. added, discharged, detached), a specific behaviour is added and scheduled for execution, competing with others already present in the behaviour set. The agent designer can choose which social events are to be tackled by the agent. The following is the pseudo-code of an example implementation that agrees with the schema: 1 p u b l i c c l a s s MyBehaviour e x t e n d s 2 S o m e J a d e B e h a v i o u r i m p l e m e n t s P r o t o c o l O b s e r v e r f 3 [ . . . ] 4 p u b l i c v o i d a c t i o n ( ) f 5 A r t i f a c t I d a r t = Role . c r e a t e A r t i f a c t 6 ( myArtifactName , M y A r t i f a c t . c l a s s ) ; 7 myRole = ( SomeRole ) ( Role . e n a c t 8 ( M y A r t i f a c t . ROLE NAME, a r t , t h i s , 9 myAgent . getAID ( ) ) ) ; 10 myRole . s t a r t O b s e r v i n g ( t h i s ) ; 11 / / add t h e i n i t i a l b e h a v i o u r o f t h e a g e n t 12 g 13 p u b l i c v o i d h a n d l e E v e n t ( S o c i a l E v e n t e , 14 O b j e c t . . . a r g s ) f 15 SETemplate t = new SETemplate ( 16 myRole . g e t R o l e I d ( ) ) ; 17 SETemplate t 2 = new SETemplate ( 18 myRole . g e t R o l e I d ( ) ) ; 19 t . iAmDebtor ( ) . c o m m i t I s D e t a c h e d ( ) The agent behaviour implements ProtocolObserver, thus allowing the agent to be notified about social events. This will be done after the agent executes the method startObserving, specifying which artifact it requires to observe. The implementation of ProtocolObserver requires, in turn, the implementation of the method handleEvent. Here, it is possible to test the kind of event that was notified. If it is a commitment, it is possible to further check specific conditions of interest on it, including its state, the identity of its debtor and/or creditor, the antecedent or consequent condition (lines 19-22). The agent will, then, add appropriate behaviours to handle the detected situation. A template-based matching mechanism for social events is provided (class SETemplate, lines 15–18) used by programmer in order to specify matching conditions. Each template class method returns this, thus compacting the code for construction of complex conditions simply using the standard method dot notation.
The handler represents the classical agent sense-plan-act cycle, rephrased into “sense the social state”, “activate behaviors according to social events”, “schedule behavior execution”. Notice that this mechanism represents an agent-oriented declination of callbacks. The agent paradigm forbids to make use of pure method invocation on the agent, that is autonomous by definition. Instead, the agent designer provides a collection of behaviours in charge for handling the different, possible evolutions of the social state, that are scheduled for execution when the corresponding condition happens. For example, a specific behaviour can be added when a new commitment is added, and the creditor of that commitment is the agent; or when a social event is added to the social state. This way, an intuitive and social-based programming schema is provided to agent developers.
IV. PROGRAMMING SOCIAL RELATIONSHIPS: AN
EXAMPLE
FinancialMAS is an example application of
2COMM4JADE. Inspired by [13], it allows financial
interactions between three categories of stakeholders: (
Let us focus on the Contract Net Protocol (CNP for short) [17], which is used inside FinancialMAS to manage the interaction between the Investor and the Financial Promoter when the former looks for some investment. We adopt the following CNP formulation: cfp causes create(C(i, p, propose, accept _ reject)) accept causes none reject causes release(C(p, i, accept, done _ failure)) propose causes create(C(p, i, accept, done _ failure)) refuse causes release(C(i, p, propose, accept _ reject)) done causes none failure causes none where i stands for the role Initiator and p for Participant.
The instance used by FinancialMAS will tie the Investor to the i and the Financial Promoter to p. Initiator supplies its player the powers cfp (call for proposal), accept, and reject.
The first allows the initiator to ask participants for proposals for solving a task of interest. If a proposal is chosen, action accept notifies the winner and all other proposals are rejected.
The role participant supplies its player the powers propose, refuse, done, and failure. Action propose allows a participant to supply a solution for a task, action refuse allows declining the invitation to send a proposal. If a proposal is accepted, the winning participant is expected to execute the task and either provide the result by means of the action done or communicate its failure. Powers allow agents to affect the social state. For instance, when an agent playing the role Initiator executes cfp, the social state is modified by creating the commitment C(i, p, propose, accept _ reject). This addition 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.
Let us see how CNP is realized in 2COMM4JADE. The class CNP extends ProtocolArtifact and implements as artifact operations all the protocol actions. In the sketch below we detail, for the sake of brevity, only the action cfp. Lines 6–10 represent the construction and sending of a call for proposals, which will be inserted in the blackboard and made available to participants. The recipient of the message is left generic because the Initiator may not know its peers, who may join even later in the future. Lines 15–19 modify the social state by adding commitments and by stating that the event cfp has occurred. Lines 27–42 defines the role in terms of its powers.
Here (lines 30–33), in fact, the power cfp is defined in terms of the homonym artifact operation. 1 p u b l i c c l a s s CNP e x t e n d s P r o t o c o l A r t i f a c t f 2 / / . . . 3 @OPERATION 4 p u b l i c v o i d c f p ( Task t a s k , R o l e I d i n i t i a t o r ) f 5 / / s e n d message w i t h t h e t a s k 6 RoleMessage c f p = new RoleMessage ( ) ; 7 R o l e I d d e s t = new R o l e I d ( PARTICIPANT ROLE , 8 R o l e I d . GENERIC ROLE ) ; 9 c f p . s e t C o n t e n t ( t a s k ) ; 10 c f p . s e t R o l e S e n d e r ( i n i t i a t o r ) ; 11 c f p . s e t R o l e R e c e i v e r ( d e s t ) ; 12 c f p . s e t P e r f o r m a t i v e ( ACLMessage . CFP ) ; 13 s e n d ( c f p ) ; 14 / / u p d a t e t h e s o c i a l s t a t e 15 c r e a t e A l l C o m m i t m e n t s ( new Commitment 16 ( i n i t i a t o r , d e s t , "propose" , 17 new C o m p o s i t e E x p r e s s i o n ( L o g i c a l O p e r a t o r T y p e .OR, 18 new F a c t ( "accept" ) , new F a c t ( "reject" ) ) ) ) ; 19 a s s e r t F a c t ( new F a c t ( "cfp" , i n i t i a t o r , t a s k ) ) ; 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 g g / / . . . g g / / . . . @OPERATION p u b l i c v o i d p r o p o s e ( P r o p o s a l prop ,
R o l e I d p a r t i c i p a n t , R o l e I d i n i t i a t o r ) f / / . . . g / / . . . / / Role c l a s s e s p u b l i c c l a s s I n i t i a t o r e x t e n d s PARole f / / . . . p u b l i c v o i d c f p ( Task t a s k ) f d o A c t i o n ( t h i s . g e t A r t i f a c t I d ( ) ,
new Op( "cfp" , t a s k , g e t R o l e I d ( ) ) ) ; g p u b l i c c l a s s P a r t i c i p a n t e x t e n d s PARole f p u b l i c v o i d p r o p o s e ( P r o p o s a l p r o p o s a l ,
R o l e I d p r o p o s a l S e n d e r ) f / / . . .
The following, instead, is a sketch of the definition of a JADE agent, playing the role Initiator by using 2COMM4JADE. In this example, the artifact is created by the agent which, then, enacts the role of interest. At line 12, the agent uses the power cfp through the role it plays. Finally, at line 14, it inspects if someone committed to accomplish the task, and reads the proposals in the tuple space in order to make a choice.
More interesting is to exploit the feature of 2COMM4JADE, which allows roles to register for the notification of social events. Thanks to the event handler, modifications to the social state will add specific behaviours to the agents, aimed at tackling the case. The code is organized by following the schema described in Algorithm 1. Figure 3 contains the UML diagram for this solution.
1 p u b l i c a b s t r a c t c l a s s I n i t i a t o r B e h a v i o u r 2 e x t e n d s O n e S h o t B e h a v i o u r 3 i m p l e m e n t s P r o t o c o l O b s e r v e r f 4 p u b l i c S t r i n g a r t i f a c t N a m e ; 5 p r o t e c t e d I n i t i a t o r i n i t i a t o r ; 6 p u b l i c a b s t r a c t B e h a v i o u r 7 c o m m i t T o A c c e p t O r R e j e c t I f P r o p o s e ( ) ; 8 p u b l i c a b s t r a c t B e h a v i o u r 9 s a t i s f y C o m m i t T o A c c e p t O r R e j e c t ( ) ; jade.core.Agent
JADE jade.corJeA.BDeEhaviour Agent1
Agent2
InitiatorBehaviour +commitToAcceptOrRejectIf Propose():Behaviour +satisfyCommitToAccept +OfruRlfieljeedctC()o:mBmehitaTvoiDouorneOr Failure():Behaviour +handleEvent(event: SocialEvent,args:Object[])
<<plays>> CommitToAcceptOr RejectIfPropose +action():void SatisfyCommitTo AcceptOrReject +action():void FulfiledCommitTo DoneOrFailure +action():void Agent1Behaviours
ParticipantBehaviour +commitToDoneOrFailure IfAccept():Behaviour +fulfiledCommitToAcceptOr Reject():Behaviour +handleEvent(event: SocialEvent,args:Object[])
<<plays>> CommFiatTilouDreoneOr +action():void FulfiledCommitTo AcceptOrReject +action():void
Agent2Behaviours <<implements>> <<Artifact>>
ProtocolArtifact ObservableProperties socialState:SocialState ArtifactOperations #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)
+ <<interface>>
ProtocolObserver +handleEvent(event: SocialEvent,args:Object[ ]) After line 21, all events occurring in the social state are notified to the role Initiator, which will handle them by executing handleEvent after a callback. The above abstract behaviour is extended by the concrete behaviour of the agent that plays the role Initiator. In particular, here we find the methods that create the actual behaviours for managing the social events. 1 p u b l i c c l a s s I n i t i a t o r A g e n t e x t e n d s Agent f 2 / / . . . 3 p u b l i c c l a s s I n i t i a t o r B e h a v i o u r I m p l 4 e x t e n d s I n i t i a t o r B e h a v i o u r f 5 p u b l i c f i n a l S t r i n g ARTIFACT NAME = "CNP-1" ; 6 p u b l i c I n i t i a t o r B e h a v i o u r I m p l ( ) f 7 s u p e r (ARTIFACT NAME ) ; 8 p u b l i c B e h a v i o u r c o m m i t T o A c c e p t O r R e j e c t I f P r o p o s e ( ) f The proposal is characterized, on the one hand, by the r e t u r n new C o m m i t T o A c c e p t O r R e j e c t I f P r o p o s e ( flexibility and the openness that are typical of MAS, and, i n i t i a t o r ) ; on the other, by the modularity and the compositionality that gp u b l i c B e h a v i o u r s a t i s f y C o m m i t T o A c c e p t O r R e j e c t ( ) f are typical requirements of the methodologies for design and r e t u r n new S a t i s f y C o m m i t T o A c c e p t O r R e j e c t ( development. One of the strong points of the proposal is the i n i t i a t o r ) ; decoupling between the design of the agents and the design g of the interaction, that builds on the decoupling between comp u b l i c B e h a v i o u r f u l f i l l e d C o m m i t T o D o n e O r F a i l u r e ( ) f putation and coordination done by coordination models, like r e t u r n new F u l f i l l e d C o m m i t T o D o n e O r F a i l u r e (
i n i t i a t o r ) ; As an example, we describe the behaviour SatisfyCommitToAcceptOrReject, which gathers proposals and selects the one to accept.
In 2COMM4JADE, an agent consists of a set of behaviours aimed at accomplishing given social relationships: such behaviours depend neither on when nor on how the social relationships of interest are created inside the social state.
These aspects are, in fact, encoded in the protocol artifact that creates them based on the actions the agents perform. As a consequence, modifying how or when a social relationship is created does not have any impact on the agent implementation.
In this work, we have proposed 2COMM4JADE, an infrastructure for allowing actors to behave following an accepted set of regulations, in a self-governance context. 2COMM4JADE is based on JADE, for what concerns the support to the realization of interacting agents, and integrates self-governance mechanisms by relying on the reification of commitments and of commitment-based protocols. These are, at all respects, resources that are made available to stakeholders and that are realized by means of artifacts. We are working on an extension for Jason too, called 2COMM4Jason; details in [1]. Recently, we developed on top of 2COMM4JADE a commitment-based typing system [2]. Such typing includes a notion of compatibility, based on subtyping, which allows for the safe substitution of agents to roles along an interaction that is ruled by a commitment-based protocol. Type checking can be done dynamically when an agent enacts a role. tuple spaces. This is a difference with respect to JADE where no decoupling occurs: a pattern of interaction is projected into a set of JADE behaviours, one for each role. Binding the interaction to ad-hoc behaviours does not allow having a global view of the protocol and complicates its maintenance.
Decoupling is an effect of explicitly representing social relationships as resources: agent behaviour is, thus, defined based on the existing social relationships and not on the process by which they are created. For instance, in CNP the initiator becomes active when the commitments that involve it as a debtor, and which bind it to accept or reject the proposals, are detached. It is not necessary to specify nor to manage, inside the agent, such things as deadlines or counting the received proposals: the artifact is in charge of these aspects.
The difference with tuple spaces and CArtAgO itself is that 2COMM4JADE artifacts reify social relationships as commitments, giving them that normative value that, jointly with the fact that by using an artifact an agent explicitly accepts the regulations encoded by it, enables the generation of expectations about the agents behaviour (as advised in [11]).
As such, it allows agents to reason and take decision also based on the others’ expected behaviour. For instance, the presence of a commitment C(i, p, propose, accept _ reject) grants the participant that its proposal will receive a feedback (it will either be accepted or rejected); if not, the initiator will be liable of a violation. In a tuple space, instead, agents can just read or write the shared blackboard but cannot have expectations on the behaviour of their parties.
This work has also relationships with works concerning e-institutions, like [15], [16], [20]. E-institutions introduce a normative aspect that lies on a different level with respect to the one we capture with commitments. Indeed, in our proposal the normative layer stands in the observational semantics of the social actions. We mean to extend the regulative aspects, as a first step, by enriching commitment protocols as proposed in [18], [3]. More in general, we mean to move towards a representation of business processes as suggested in the Comma methodology [26], where commitment patterns regulate activities instead of being used for giving the action semantics. Another advantage is that artifacts are an actual system for implementing mediated interaction, they supply efficient, simple, and direct means for checking the powers for performing institutional actions, and they offer runtime mechanisms for letting the agents perceive the state of the interaction.