From Agentgroup
Jump to: navigation, search

Overview

Rolesystem is an interaction infrastructure that implements the interaction model of BRAIN. It is completely written in Java to grant high portability and to be associated with the main agent platforms. The concrete platform we chose to implement Rolesystem is Jade, a FIPA compliant agent platform, which allows also mobility of agents. As shown in Figure 1, the Rolesystem infrastructure is divided into two parts: the upper one is independent of the agent platform, while the lower part is bound to the chosen agent platform, in this case Jade. We remark that it is not possible to have a complete independent implementation, but our effort was in the direction of reducing the platform-dependent part. In applications exploiting the Rolesystem infrastructure, agents can be seen by two points of view: they are both subjects of the role system and agents of agent platform (e.g., Jade). Accordingly, an agent is composed by two layers: the subject layer, representing the subject of the role system independent of the platform, and the wrapper layer, which is the implementation entity (e.g., the Jade agent) in charge of supporting the subject layer. A specific agent for each interaction context, called server agent, is in charge of managing roles and their interactions. It interacts with the wrapper layer of agents by exchanging, in the Jade case, ACL messages formatted in an appropriate way.

Figure 1. Domain separation in the Rolesystem infrastructure

Therefore, the current implementation consists of several Java classes, both platform-independent and related to Jade. The main platform-independent classes are reported in the UML class diagram of Figure 2. Such classes have been grouped in the rolesystem.core and rolesystem.roles packages.

Figure 2. The diagrams of rolesystem.core and rolesystem.roles packages


The connection between the subject layer and the wrapper layer is granted by two Java objects, instances of classes implementing respectively the RoleSystem and RoleRegistration interfaces, which provide methods to register the associations between agents and roles, to search for agents playing a given role, to listen for events and to perform actions. Such interfaces are described in detail in the next subsection.

RoleSystem and RoleRegistration Interfaces

The RoleSystem interface enables agents to perform preliminary operations needed to assume a role; since agents do not play roles yet, such operations are called "anonymous". The following methods are available:

  • reqRegistration, to register an agent in the system with a specified role. The server agent of the local interaction context registers the requiring agent (or, better, the subject); this method returns a Java object that implements the RoleRegistration interface, detailed later, which enables the use of the role.
  • searchForRoleAgent, with and without timeout, to search for agents playing a given role. In the case of blocking operation, the method returns if there is a matching registration or as soon as an agent performs a corresponding registration. In any case, the methods return an array (possibly empty) of registrations.

Note that, when an agent asks for registration, it already knows the class implementing the role; the registration is needed by the role system to know which role such agent plays. With regard to the presented application example, Figure 3 shows the request for registration of an agent A that wants to assume, for instance, the participant role. The request is made by invoking the reqRegistration method, supplying as parameter the name of the role (the static field ROLE_ID of the Participant class). This invocation occurs in the code of the class that implements the subject layer of the agent A.



...
RoleRegistration registration;
try
{ registration=roleSystem.reqRegistration(Participant.ROLE_ID); }
catch(RoleException re)
 System.err.println(re);
return;
}

(Figure 3. Example of registration request)

  • The latter interface is RoleRegistration, which enables agents to perform operations on the system via a specific registration (i.e., after that the agent has assumed a role). The following methods are defined:
  • listen, with and without timeout, to listen for occurring events. The operation without timeout is blocking, and returns as soon as an event occurs. The methods return an object of event class, or null.
  • doAction, to perform a given action; this method will be detailed later.
  • whoAmI, to know the identifier associated to the role registration.
  • dismiss, to cancel the registration and leave the corresponding role.

To play a role, the first step to be performed by an agent (in its subject layer) is to obtain an object that implements the RoleRegistration interface, by the invocation of the reqRegistration method. The returned object represents the association between the agent and a specific role, i.e., the role assumed. Then, such object can be exploited to perform actions and manage events, as better described in the next subsection. As soon as an agent does not need to play the assumed role any more, it releases the role registration via the dismiss method. If the agent wants to assume a role again (the same or another one), it has to require another registration via the reqRegistration method.

Roles, Actions and Events

In Rolesystem, a role is implemented by an abstract class, where the features of the role are expressed by static fields and static methods. A role class can be easily derived from a XRole document, by means of an appropriate XSL document. Figure 4 reports the UML class diagram that explains the relationships among the classes that represent roles, actions and events.

Figure 4. The diagram of an example of role packages

The class that implements a role has the same name of the role, and is part of a package that represents the application scenario for such role. A static and final field called ROLE_ID, of type String, is exploited to identify the role; to avoid name conflicts, the value of this field is the concatenation of the name of the package with the name of the role, in the form package.Role. In the following, we report some code fragments of the classes belonging to the conference application example. Each action defined in a role is built by a static method, which is in charge of creating an appropriate instance of the class RoleAction and returning it to the caller. Such a static method has the same name of the corresponding action and one or two parameters: the former one is the agent addressee of the event corresponding to the action; the optional latter parameter is the information content to perform the action. To perform an action, an agent playing a given role must obtain the appropriate RoleAction instance, invoking the corresponding static method of the role class. Then, it has to invoke the doAction method of RoleRegistration to actually perform the action, supplying the previously created instance of RoleAction. Then, when the server agent receives the request to perform the action via the wrapper layer, translates it into a known event, and sends it to the addressee agent. To find partners to interact with (i.e., addressee agents), agents can exploit the searchForRoleAgent methods made available by the RoleSystem interface, by which an agent can get a list of the registrations related to a specific role, each one specified by an identifier. An (addressee) agent waits for incoming events by invoking the listen method of the RoleRegistration interface. When an event for this agent arrives, the listen method returns an instance of the class RoleEvent, and then the agent can evaluate whether the incoming event is among the recognized ones, which are defined in the role class as instances of the class KnownEvent. This class describes the name of the event, the role assumed by the sender of the event, and the class of the information content of the event. Thanks to the match method of the known event class, agents can compare the known events (instances of KnownEvent) with the occurred event (instance of RoleEvent); this method returns true if and only if:

  • the name of the occurred event is the same of that of the known event, and
  • the role of the sender agent is the same of that of the known event, and
  • both the events are without any information content; otherwise the information content of the occurred event can be casted to the class of the information content of the known event.

The names of the KnownEvent instances correspond to the names of the events they represent, preceded by the prefix "KE_".

Interactions

An interaction between two agents occurs when the former one performs an action (chosen among the available to the role it plays) and such action is translated into an event that is notified to the latter agent that exhibits the specific behavior. The Rolesystem infrastructure provides for the translation from actions into events. The administrator of a site can enforce local interaction laws, by defining which interactions are allowed in the site. In particular, she can set a grid of permissions, which tells who can interact with who, and each interaction permission must specify the sender and the addressee; since the interactions in Rolesystem are asymmetric, it may happen that a role A can interact with role B, but role B cannot interact with role A. An appropriate GUI can be exploited to set permissions.

Download

Download the Rolesystme code (for the Jade platform):

You can also download the Jade 2.4 platform:

or find the last version of Jade in the Jade web site