The RoleX Environment for Multi-Agent Cooperation
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
The RoleX Environment for Multi-Agent Cooperation
Giacomo Cabri, Luca Ferrari, Letizia Leonardi
Dipartimento di Ingegneria dell’Informazione
Università di Modena e Reggio Emilia
Via Vignolese, 905 – 41100 Modena – ITALY
{cabri.giacomo, ferrari.luca, leonardi.letizia}@unimo.it
Abstract. In this paper we present the RoleX environment for multi-agent systems.
Born to support the management of role-based interactions, Rolex provides different
services, in particular to support open and flexible cooperation. To this purpose,
RoleX exploits an event-based communication mechanism and adopts SOAP as
message encoding. Such features make RoleX well suit dynamic and unpredictable
scenarios such as the Internet.
1 Introduction
Cooperation in multi-agent application requires an appropriate support for the interaction
occurring between agents. BRAIN [10] is a role-based framework for supporting the
development of interactions in multi-agent applications. We have based this framework
on roles to exploit the related advantages. First, roles enable a separation of concerns
between the different issues in developing agent-based applications [8]. Second, they
permit the reuse of solutions and experiences; in fact, roles are related to an application
scenario, and designers can exploit roles previously defined for similar applications.
Therefore, roles can also be seen as a sort of design patterns [20]: a set of related roles
along with the definition of the way they interact can be considered as a well-defined
cooperation pattern that can be reused in different but similar situations.
Inside BRAIN, we have developed an environment, called RoleX, which supports the
dynamic assumption of roles by agents [4], through the runtime manipulation of the agent
code. In addition, RoleX provides services related to openness and interoperability, and
aims at making agents interact in a flexible and interoperable way. To this purpose, we
exploit the event-based communication, which well suits dynamic and unpredictable
situations and makes the RoleX environment an active entity in interactions. Moreover,
the adoption of the SOAP protocol enables agents to interact with a variety of other kinds
of entities and in particular information sources. In this paper we report on the design and
the implementation of the RoleX environment, explaining the services that it makes
available. RoleX takes into account also mobile agents, which grant further flexibility andincrease the dynamism of applications. Interested readers can find more information about the adopted model in [10]. This paper is organized as follows. Section 2 sketches an overview of the BRAIN framework. Section 3 explains the design of the RoleX environment, reporting our choices; an application example in the field of e-democracy is exploited to make the concepts concrete. Section 4 shows some details about the implementation of RoleX. Section 5 reports some related work and, finally, Section 6 concludes the paper. 2 Overview of the BRAIN Framework The BRAIN framework [10] aims at supporting the development of interactions in multi- agent applications and is composed of (i) a well-defined model for roles, (ii) XRole, an XML-based notation for agent roles, and (iii) possibly several environments which implement the previous model and exploit the XRole notation. A role can be considered as a stereotype of behavior common to different agents in a given situation. Such a behavior is exhibited by agents, but is also expected by other entities, mainly other agents, organizations [31] and environments. It is useful to deal with roles separately from the agents. In our approach a role is modeled as a set of capabilities and an expected behavior, both applied to the agent that plays such role. This model of role leads to a twofold viewpoint of the role: from the application point of view, the role allows a set of capabilities, which can be exploited by agents to carry out their tasks; from the environment point of view, the role imposes a defined behavior to the entities that assumes it. The former point is that a role is a set of capabilities that agents playing a given role can perform. This takes into account the proactiveness feature of agents, since they have to perform actions to carry out their tasks, and so, they must be enabled to do it. The latter point is that an agent playing a given role is expected to exhibit a specific behavior. This accounts for the agent’s reactivity, since they are sensible to what happens in the environment where they live. The “expected behavior” is constituted by the reactions to external stimuli. The notation proposed by BRAIN, called XRole [7], enables the definition of roles by means of XML documents; this grants interoperability and allows different representations tailored on the needs of the different phases of the application development. It is worth noting that each different representation derives from the same information, so the different phases of the development of applications rely on the same information, granting continuity during the entire development. For instance, during the analysis phase, the analysts create XRole documents following the appropriate XML Schema, which guides them in the definition of the role features. These XRole documents can be translated into HTML documents to provide high-level descriptions also for further uses. In the design phase, the same XRole documents can be translated into more detailed HTML documents to suggest functionalities of the involved entities. Finally, at the
implementation phase, again the same XRole documents can be exploited to obtain Java
classes that implement the role properties.
3 Design of the RoleX Environment
RoleX is one of the possible environments implemented to support the BRAIN
framework. So, it adopts the BRAIN role model and exploits the XRole notation. In
RoleX, capabilities are represented by actions that agents playing such role can perform;
the expected behavior is represented by the management of incoming events. In RoleX, an
interaction between two agents occurs when one agent performs an action (chosen among
the set of capabilities belonging to the role it plays) that is translated into an event that is
notified to another agent that exhibits the specific behavior (see Figure 1). This approach
allows the environment to be considered as an interacting entity in an uniform way:
appropriate actions can be dealt with directly by the environment, which in turn can send
appropriate events to agents in order to notify environment-related information. The
RoleX environment provides for the translation from actions into events, playing actively
over communications and, in the case, applying local policy to interactions. Further
motivations of adopting an event-based approach are reported in the following of this
section.
agent A agent B
capabilities action capabilities
RoleX environment
behavior event behavior
role A role B
Figure 1. How an interaction occurs
3.1 Role Meaning
RoleX exploits roles and concretely uses an approach inspired by the real life: since
agents can act on behalf of a real user, their roles must be “played” as users do. This
mainly requires two features: dynamism and external visibility.
The dynamic role assumption of RoleX allows an agent to assume at runtime a set of
capabilities needed to perform its tasks via a role. The agent external visibility of RoleX,
coherent with the assumed role, implies that the way other agents see it must be changed
accordingly; this allows other agents to recognize the above one as playing the assumed
role.Our role approach is more oriented to agents than other role approaches that exploit Object-Oriented paradigm or Aspect Oriented Programming [29, 18]. In those cases, roles are conceived as entities separated from agents and directly used by them. Instead, our approach is centered on roles, which are dealt with in a new way: each role is conceived as a first-class entity, but it becomes a single thing with the agent that has assumed it by extending its code. This way is more similar to the human real life, where people do not simple “have” roles, but “play” them. Developing roles as first class entities allows developers to work in a modular and scalable way. There could be the role developers, on one side, and the agent developers on the other side. The latter exploit roles provided by the formers. In this way there is a real separation of concern without requiring a double effort in development (role developer and agent developer can coincide). Furthermore, in this way the role can be developed in a totally separated way from the agent, reducing the effect on specific application details. In this case, roles must be carefully managed, since they are becoming more like components, and developers must agree to avoid misunderstanding and misuse of roles. The comparison with real life leads also to another consideration: the fact that a person can be recognized also via her role requires a high degree of dynamism; in fact a person assumes/releases roles depending on what she wants to do. The same must happen in the agents’ world: the agents must feel free to assume/release roles in a dynamic way. 3.2 Role Description To grant a high level of abstraction in deciding which role to play, and to cope with dynamic situations, it is important to uncouple roles from their implementation; this allows agents to focus on the semantics of the roles, rather than their code. To this purpose RoleX uses descriptors for roles, actions and events. A descriptor is an entity that describes a role, an action or an event, for example by means of information such as keywords, a contest, an aim, a version, a creation date and any further needed piece of information. An action descriptor describes what a particular action does (i.e. what is its aim) and which information its execution requires. An event descriptor describes the kind and the context of the occurred event. A role descriptor describes what such role does, but not how (i.e., by which operations) it is done. It includes also the descriptors of the corresponding actions and events. For instance, if an agent must assume a speaker role, the programmer could write code that requires not directly a speaker role but a role with a speaker description, for instance by means of appropriate keywords. The agent can further verify the retrieved descriptor to be sure that the role is the right one for its purposes. Descriptors are defined by XML documents written exploiting the XRole notation of BRAIN. Besides relieving programmers of the knowledge of role implementation, the descriptors are useful also to hide to the agent the physical location of the role implementation, to enable role composition, to change role implementation in a transparent way, and to allow the agent programmers to disregard about the work of role programmers and viceversa.
3.3 Events
RoleX adopts an event-based approach to enable interactions between agents. Assuming a
role gives the possibility of interacting with other agents and in general other entities.
Such interactions occur by exchanging appropriate events. Roles are exploited to manage
the sending and the receiving of events.
In general, events grant a high degree of uncoupling between interacting entities. In
fact, events allow the uncoupling among: (i) service identities and (ii) entity identities.
The former way of uncoupling works as follows: agents interacting through events are
in charge to exchange only events, without needing to know details about related services.
For instance, to require a service, an agent A needs only to send the right event to B,
without worrying about which method will be actually invoked by B. Even if the agent B
undergoes code refactoring, A will be able to request a service to B without needing
changes, since it needs only to know the right event to send, which is supposed to not
change. This is a very expressive characteristic of events: agents involved in
communications need only to know events and the send/receive mechanism, without the
need of knowing details about the other entities involved.
The latter uncoupling relies on the event system implementation. In the most complete
implementation the sender agent can simply put the message in an event queue, without
addressing agents in charge of receiving that event. The queue is in charge of notifying
the event to all interested agents through a queue manager, which is often called event
dispatcher (simply dispatcher in the following) [14].
Please note that, while the service uncoupling is always granted by event-based
systems, the entity uncoupling is not. In particular, the latter kind of uncoupling depends
on the specific event system implementation, and specifically by the event dispatching.
Our approach focuses mainly on the service uncoupling in order to grant scalability in
communications.
3.4 An Application example
In this subsection we propose an application example of the use of the RoleX
environment. We exploit an application in the field of e-democracy [1], which enables
citizens to attend a convention1. During the execution, the user is allowed to listen to a
candidate’s speech and to perform her own speech (if she is a candidate). This application
works exploiting mobile agents, each one representing and supporting its user and
executing in a virtual e-democracy room: such an agent will be called user agent in the
following. The user agent can cooperate with other agents and/or with the e-room itself to
complete the user’s task(s). In this particular application, the user’s task(s) are strictly tied
to the convention, so that they can be for example performing the speech or listening to
1 Our application enables other e-democracy services, such as voting, which are not reported in this
paper, since less interesting with regard to cooperation issues.other speeches. The user is kept informed by its agent, which provides the user with
information about carried out task(s).
Since our approach is role-based, appropriate roles should exist, in the e-room, to help
agents performing their task(s). We have identified three roles: participant, which
supports its user in attend the convention, speaker, which supports its user in performing
its speech, and chair, which supports the manager of the convention. All these roles
provide the corresponding capabilities to agents playing them. For instance, the
participant role provides for the capability of accessing the current presentation; the
speaker role enables the access to the microphone, the visualization of presentations, and
so on; the chair role keeps a list of the speakers and notifies the speaker turns.
Figure 2 shows the XML document related to the role descriptor of a participant role
expressed by the XRole notation. As shown in that figure, the role provides two
operations: listen, which is used to listen to other agents’ speeches, and
searchSpeechBySubject, which is used to get credentials of a speaker that has performed a
speak with a determined subject. Accordingly to the RoleX design, both the above
operations work by mean of events, either outgoing (sendingEvent) or incoming
(receivingEvent).
convention participant
participant
participant
convention
…
listen
listen to a speech
…
conference.TalkEvent
searchSpeechBySubject
search for a previous speaker by the subject of the speech
conference.SearchBySubjectEvent
conference.SearchResult
true
Figure 2. XML role descriptor of the participant role.As a detailed example of cooperation, let us suppose that a user joins an already-started
convention, and wants to know about previous speeches on a particular subject. Its user
agent, after assuming the participant role, can ask the chair agent2 which speeches have
been performed about the interesting subject. The chair agent replies a list of agents that
have the speeches about the indicated subject. This request-response is managed by the
two roles, participant and chair. The user agent starts the interaction with an action that
causes a related event to be delivered to the chair agent, which in turn manage the
incoming event by searching for subject in its speech list; then it performs an action that is
translated into an event for the user agent, which receives the list of agents. After that, the
user agent can contact the agents to have the speeches. Of course, the user agent can ask
the current speaker agent information about the current speech.
public void listen(TalkEvent event){
// manage the event, for example print the speech on the stdout
System.out.println(“Received a new speech fragment:”);
System.out.println(event.getContent());
}
public Channel[] searchSpeechBySubject(Channel chairChannel, String subject){
// ask the chair for the speech of the passed subject
SearchBySubjectEvent event=new SearchBySubjectEvent(subject);
chairChannel.sendEvent(event);
// the chair agent will send the SearchResult event
}
Figure 3. A fragment of the Java code of the participant role.
Figure 3 shows a fragment of the Java implementation of the participant role, related to
the role descriptor shown in Figure 2. Accordingly to the role description, the first
method, listen, is invoked every time a new TalkEvent is delivered to the listening agent.
The agent, when assuming the participant role, asks to the chair agent to register it as an
agent playing the above role. The chair will inform every speaker in the room, at the time
of the speech, of which agents are currently listening, thus the agent playing the speaker
role will send events to them. These events are to be instances of the TalkEvent, which
contain the speech itself. As shown in the Figure 3, the agent playing the participant role
simply prints the speech content on its screen.
The second method, searchSpeechBySubject, accordingly to the role descriptor of
Figure 2, sends an event of kind SearchBySubjectEvent to the chair agent. To deliver this
event it is exploited a particular object, chairChannel, which is a RoleX channel bound to
the agent playing the chair role, thus other agents can queue events to the former. The
channel is an abstraction over the event delivering system, which, as shown in section 4.3,
can be implemented even using XML based systems such as SOAP.
Once the chair agent has received the SearchBySubjectEvent event, it will search for all
agents with a speech related to the specified subject. When it finds, it sends back an event
2 Here and in the following we say the “X agent” to mean “the agent playing the X role”.to the requesting agent with the found agent list. One more time, accordingly to the descriptor of Figure 2, the reply event is a SearchResult, which contains channels that the agent can use to communicate with the found agents. When the reply event (SearchResult) is delivered to the requesting agent, an appropriate role method will be in charge of managing it. In this paper we do not address how an agent chooses its role(s). This is left to the intelligence of the agent and to the way it decides to carry out its task(s). The application scenario can help the agent choosing the role by means of information: the agent can query role descriptor database in order to understand what role is the most suitable for its task. On the other hand, the capability to rightly select the role starting from the role descriptors must belong to the agent itself. There are also situations where the role assumption can be driven by roles themselves. For example, in the above application a participant agent can obtain information about another role (in the same context) that can grant better capabilities to it, and this can be the speaker role. In general, the choice of role(s) depends both on the application scenario and on the initial capabilities of the agent itself. 4 RoleX Implementation The RoleX environment has been implemented in pure Java. This choice has been supported by different motivations: (i) Java is the language used by most of the agent platforms, particularly those for mobile agents; (ii) Java has important features such as network-orientedness, safety, security and portability; (iii) being based on a bytecode, Java allows us to manipulate agent classes in order to add/remove roles. Our aim was not to develop another agent platform from scratch, but instead to make available an environment that can be associated to different agent platforms. To this purpose, most of the code of RoleX is independent of the chosen agent platform, while only three classes must be specialized for the specific platforms. Moreover, we have defined Java interfaces for agents, so that existing agent classes (even of different platforms) can be adapted to our environment by creating a subclass that implements the appropriate interface. Currently, we have mainly exploited RoleX with the IBM Aglets system [19], but we are studying also the association with Jade [3]. 4.1 Role Management Since the agents are developed using Java, our implementation enables automatically the translation from the XRole documents representing descriptors to a set of Java classes. In this way, an agent can directly access the descriptors without needing an XML-parser. In particular, there is a Java class for every descriptor type, so the RoleX environment will
have one object for each role descriptor, one for each action descriptor and one for each
event descriptor.
The Java implementation of a role is composed of two parts: a Java interface (role
interface) and a Java class (role implementation); the interface provides external visibility
(simulating multiple inheritance) while the class provides the effective role behavior.
A role assumption means that the RoleX system performs run-time bytecode
manipulation, and in particular (i) adds each role class member (both methods and fields)
to the agent class, in order to add the set of capabilities of the role and, at the same time,
(ii) forces the agent class to implement the role interface, in order to modify its
appearance and to allow other agents to recognize it as playing that role.
Since the above mechanism must result in the definition of a new class, our approach
exploits a special class loader, called RoleLoader, that can change the agent behavior and
the external appearance. It is a subclass of SecureClassLoader, which allows us to work in
compliance with the Java Security Manager. After the RoleLoader has successfully carried
out the role assumption process (i.e., the addition of the members and the interface), it can
reload the agent restarting it. The assumption process can be briefly described by Figure
4, where the agent searches a role repository for an appropriate role descriptor, for
example by using keywords, and then asks the RoleLoader to reload itself with the chosen
role among the retrieved ones. The RoleLoader retrieves the implementation corresponding
to the role descriptor and adds it to the agent. If everything goes right, the RoleLoader
sends the new agent an event (called reload event) to indicate that the agent has been
reloaded. After the reload event, the agent can resume its execution. Releasing a role is
similar to the above process, but this time the RoleLoader removes each role member and
the role interface, reloading the agent without them.
Original 1 - search for role descriptors
agent
2 - found descriptors
Role Descriptor
3 - request to 6b - loading exception repository
load the role
4 - ask for role implementation
Role Loader
Manipulated
agent
5 - role implementation Role Implementation
repository
6a - agent reloaded
with role
Figure 4. The assumption process
Our implementation of the RoleLoader is based on the Javassist bytecode manipulation
engine [28], even if the simple use of such engine alone is not enough to completelysatisfy our goals. In fact, our approach takes into consideration role code reusability and
separation of concerns; to these purposes, we take into account not only the classes of the
agent and of the role, but also their superclasses, as explained in the following. For this
reasons the RoleLoader performs several steps:
1. the RoleLoader calculates the inheritance stack for the role class and the agent class
(i.e., it calculates all superclasses of both);
2. for each level of the inheritance stack, the RoleLoader copies all the members from the
role implementation to the agent class (see Figure 5); then the loader adds the role
interface to the implemented interface list of the agent class;
3. a new agent instance is created from the manipulated class;
4. each field value is copied into the agent class so that it does not loose its current state.
Through these steps, even if one agent and the assumed role have been developed
separately, they dynamically become a single entity with the correct external visibility.
Interested readers can find more details in [4].
java.lang.Object
Member copy
starts at this TOP
level of the of the
agent chain. inheritance
... chains
agent_level2 java.lang.Object
agent_level1 role_level1
Member copy
Member copy BOTTOM
Original_agent role_implementation «interface»
ends at this of the
role_interface
level of the inheritance
agent chain. Member copy chains
Interface copy
Figure 5. How the member copy works
As readers can see, the assumption process in RoleX is quite complex and involves
several activities (inheritance chain computation, bytecode manipulation, etc.), leading to
a slower process than other implementations (see for example [9]). From a performance
point of view, our tests have demonstrated that the role assumption time is directly
dependent on the total bytecode size of the role (see [6]). We are evaluating some caching
mechanisms that, combined with a massive use of Java factories, can improve
performances.4.2 Event Dispatching Instead of using a single event dispatcher, which can lead to several problems especially related to reliability and performance, our approach exploits a peer-to-peer mechanism to deliver events. Since we do not rely on a centralized dispatcher, the sender agent is in charge of addressing each receiver agent to which it wants to send an event. The use of a peer-to-peer approach avoids the problem of a single point of failure. In fact, even if the dispatcher is not overloaded, it can crash implying the impossibility for agents to communicate. Even if there are event systems that allow the use of multiple dispatchers, such as Jedi [14], they partially solve the above problem, since each dispatcher can be a single point of failure. Moreover, the use of peer-to-peer solves also the possible bottleneck that each dispatcher represents. While a dispatcher can introduce a delay in event delivering, due to its overload, in our approach delays are due exclusively to the sender agent. Of course, while some agents can be overloaded depending on the number of exchanging events, other agents can be free to communicate as usual, since each communication does not depend on a centralized component. Note that a peer-to- peer approach can also be used to implement solutions where a receiver agent acts as dispatcher/forwarder for other agents. Our approach allows both synchronous and asynchronous dispatching of events; the former is totally in charge of the sender agent, while the latter relies on an environment support. In particular, the environment provides a dispatching thread per agent, created on demand, to queue and deliver asynchronous events. Note that even this approach can be considered peer-to-peer since there is not a centralized dispatcher in charge of serving more than one agent. 4.3 Exploiting SOAP In order to grant a high degree of openness to interactions, our approach adopts the SOAP (Simple Object Access Protocol) protocol, standardized by the W3C [22]. Thanks to its interoperability, SOAP enables any kind of entities to interact inside the RoleX environment, no matter which technologies have been exploited to develop them. In particular, agents can bid information sources that make their services available via a SOAP interface [17, 21]. This approach allows also the collaboration between humans and agents; in fact, humans can view agent events for instance through a Web browser and can interact with agents thanks to programs in charge of translating human commands into SOAP documents. Moreover, the use of an XML-based protocol, such as SOAP, grants the capability of extending our system to collaboration between agents (and other entities) based on future technologies or with different needs. Our approach exploits the SOAP-RPC capabilities [23] to perform remote method invocation; the agent invocation is translated into a SOAP-RPC call, and delivered to the receiver, where is translated into a call to the Java event-listener interface’s method, for
instance called notify, supplying the event as parameter. Such a parameter contains also the information about the sender, so no other parameters are needed. The SOAP specification does not tie the transport layer to a specific protocol, which means that a SOAP document can be sent by HTTP, SMTP or something else [24, 25, 26]. These protocols are useful when the entities involved in the communication are really different, and they are suitable to scenarios like those for e-business or enterprise systems, but for the agents’ world they are too heavy, so we exploit a simpler protocol, defined inside RoleX. Moreover, the return value of the notify method is always void, and this further simplifies the communication system. We apply event communications whenever there is no needing of a direct reply. The fact that the return type of the above method is void emphasizes this concept: the caller (i.e., the event sender) does not require a return value, so no request-response [27] mechanism must be implemented. This consideration implies that a simple transmission protocol can be used in SOAP-based agent communications: the sender agent simply writes a character-based representation of the SOAP document to a stream (e.g. a socket). At the other end of the stream, the destination agent reads the chars and translates them from SOAP into Java, without needing to send a reply to the sender. 5 Related Work To our knowledge, there are no environments with the features of RoleX. In this section we report some related work in two main fields: role-based and event-based approaches for agents. 5.1 Role-based Approaches E. Kendall well describes the importance of modeling roles for agent systems [18], and she exploits the AOP to concretely implement the concept of role in agent applications. Another interesting approach is AALAADIN [15], a meta-model to define models of organizations. It is based on three core concepts: agent, group and role. The ROPE project [2] addresses the collaboration issues and recognizes the importance of defining roles as first-class entities, which can be assumed dynamically by agents. Yu and Schmid [30] exploit roles assigned to agents to manage workflow processes. They traditionally model a role as a collection of rights (activities an agent is permitted on a set of resources) and duties (activities an agent must perform). An interesting issue of this approach is that it aims to cover different phases of the application development, proposing a role-based analysis phase, an agent-oriented design phase, and an agent-oriented implementation phase. TRANS is a multi-agent system that provides for role and group behaviors, and takes into consideration mobile agents. An interesting feature of TRANS is the capability
of defining rules on the role assumption by agents, such as priority, exclusivity, compatibility and the distinction between permanent and temporary roles. In our opinion, the above-mentioned approaches lack in allowing openness and interoperability at different levels of abstraction, unlikely from our RoleX environment, which implements the advantages of BRAIN and provides open interaction mechanisms. 5.2 Event-based Approaches Jedi [14] is a famous event-based system, which differs with regard to the RoleX one for several issues. First of all it redefines the concept of events (a set of string) and listener, in a quite different way from the usual Java event and listeners, and this leads to an incompatibility between the Jedi event system and the Java one. As second issue it relies on a centralized component, called Event Dispatcher, which is in charge of delivering each event to each entity. Even if it is possible to aggregate multiple Event Dispatchers to produce a distributed system, the centralized nature of each single dispatcher can result in a bottleneck and in a single point of failure. Finally, Jedi allows the use of synchronous transmission only to take back computation results, but it does not consider possible errors (exceptions), leading to a less Java oriented solution. In the proposal of [12], agent messages are stored in a private mailbox, which the agent owner queries periodically. Even if this approach allows agents to easily communicate with other remote agents, since they only need to deliver the message to a private mailbox, it implies that the addressee agent performs continuous receiving operations. This means that queued messages are not delivered until the agent gets them from the mailbox. The JADE framework discarded the use of SOAP [11], preferring an RMI-based protocol [13]. The main motivation is that JADE’s authors do not think that XML can be suitable for mobile agents, particularly when dealing with mobile devices such as PDA or phones. Of course parsing large XML documents can require a lot of time and resources, but using an event driven model, such as the one of our approach, will always produce small documents. Furthermore our approach does not use HTTP, so the SOAP document is not an HTTP-payload, and this implies that there is no additional header to parse. Our approach, exploiting a peer-to-peer architecture results more scalable than the previous ones, especially if the number of transmissions grows up. In addition, it is more flexible since each queued event is delivered to the agent by a thread that runs in the environment. Finally, using SOAP, it is possible to exploit the environment asynchronous dispatching to embed both the XML translation and event delivering in the same layer, leading to more transparency.
6 Conclusions and Future Work
This paper has presented the RoleX environment to support the cooperation in multi-agent
systems.
It was developed inside the BRAIN framework starting from a role-based approach, to
provide all the advantages of roles in terms of separation of concerns, reusability, and so
on; RoleX provides features that take into account also other needs: the adoption of the
event-based communication makes RoleX flexible, while the support of SOAP provides a
high degree of openness and interoperability also with entities different from agents.
With regard to future work we highlight some directions. First, security is an important
issue that we are considering in RoleX. We have explored the chance of exploiting JAAS
[16], a standard, Java-based architecture to manage authentication in distributed systems;
its adoption in RoleX enables a fine-grain control not only over the role assumption, but
also over the actions agents can performs [5]. Second, we are testing the RoleX
environment with different applications. We have implemented applications in the fields
of service management and e-democracy, but the use of our environment must be
investigated also in other scenarios, to validate its effectiveness. Finally, the environment
must be fine tuned to grant also a good performance, which is fundamental to use RoleX
in real applications.
Acknowledgments
Work supported by the Italian MIUR and CNR within the project "IS-MANET,
Infrastructures for Mobile ad-hoc Networks", and by the MIUR within the project "Trust
and law in the Information Society. Fostering and protecting trust in the market, in the
institutions and in the technological infrastructure".
References
1. A. Veikko Anttiroiko, “Virtual extension: Building Strong E-Democracy – The Role of
Technology in Developing Democracy for the Information Age”, Communications of the
ACM, vol.46 No. 9, September 2003
2. M. Becht, T. Gurzki, J. Klarmann, M. Muscholl, “ROPE: Role Oriented Programming
Environment for Multiagent Systems”, Proceedings of the Fourth IFCIS Conference on
Cooperative Information Systems (CoopIS'99), Edinburgh, Scotland, September 1999.
3. F. Bellifemine, G. Caire, T. Trucco, G. Rimassa, “JADE Programmer’s Guide”, JADE 2.4, 4
September 2001.
4. G. Cabri, L. Ferrari, L. Leonardi, “Manipulation of Java Agent Bytecode to Add Roles”, The
2nd International Conference on the Principles and Practice of Programming in Java (PPPJ
2003), Kilkenny City, Ireland, June 20035. G. Cabri, L. Ferrari, L. Leonardi, “Embedding JAAS In Agent Roles To Apply Local Security
Policies”, The 3rd International Conference on the Principles and Practice of Programming in
Java (PPPJ 2004), Las Vegas, USA, June 2004
6. G. Cabri, L. Ferrari, L. Leonardi, “Exploiting Run-Time Bytecode Manipulation to Add Roles
to Java Agents”, Science of Computer Programming, 2004.
7. G. Cabri, L. Leonardi, F. Zambonelli, “XRole: XML Roles for Agent Interaction”, in
Proceedings of the 3rd International Symposium “From Agent Theory to Agent
Implementation”, at the 16th European Meeting on Cybernetics and Systems Research
(EMCSR 2002), Wien, April 2002.
8. G. Cabri, L. Leonardi, F. Zambonelli, “Separation of Concerns in Agent Applications by
Roles”, the 2nd International Workshop on Aspect Oriented Programming for Distributed
Computing Systems (AOPDCS 2002), Wien, July 2002
9. G. Cabri, L. Leonardi, F. Zambonelli, “Implementing Role-based Interactions for Internet
Agents”, The 2003 International Symposium on Applications and the Internet (SAINT 2003),
Orlando, Florida, USA, January 2003.
10. G. Cabri, L. Leonardi, F. Zambonelli, “BRAIN: a Framework for Flexible Role-based
Interactions in Multiagent Systems”, The 2003 Conference on Cooperative Information
Systems (CoopIS), Catania, Italy, November 2003
11. G. Caire, N. Lhuillier, G. Rimassa, “A Communication Protocol for Agents on Handheld
Devices”, AAMAS Workshop on Ubiquitous Agents on embedded, wearable and mobile
devices, Bologna, July 2002.
12. J. Cao, X. Feng, J. Lu, S.K. Das, “Design of Adaptive and Reliable Mobile Agent
Communication Protocols”, in Proceedings of the 22nd International Conference on Distributed
Computing Systems (ICDCS 02), Vienna, 2-5 July 2002.
13. E. Cortese, F. Quarta, G. Vitaglione, “Scalability and Performance of JADE Message
Transport System”, AAMAS Workshop on Agenticies, Bologna, July 2002.
14. G. Cugola, E. Di Nitto, A. Fuggetta, “The JEDI Event-Based Infrastructure and Its Application
to the Development of the OPSS WFMS”, IEEE Transactions on Software Engineering,
September 2001 (Vol. 27, No. 9), pp.827-850
15. J. Ferber and O. Gutknecht, “AALAADIN: A meta-model for the analysis and design of
organizations in multi-agent systems”, in Proceedings of the Third International Conference on
Multi-Agent Systems (ICMAS'98), 1998.
16. SUN Microsystems, “Java Authentication and Authorization Service (JAAS)”, available
material at http://java.sun.com/products/jaas/
17. Kai-Shin Lu, Yong-Feng Lin, Chen, J.J.-Y. , “Using mobile agent and SOAP-RPC in an
advanced traveler information system”, in Proceedings of Intelligent Transportation Systems,
October 2003.
18. E. A. Kendall, “Role Modelling for Agent Systems Analysis, Design and Implementation”,
IEEE Concurrency, Vol. 8, No. 2, pp. 34-41, April-June 2000.
19. D. B. Lange, M. Oshima, Programming and Deploying Java™ Mobile Agents with Aglets™,
Addison-Wesley, Reading (MA), August 1998.
20. J. Lind, “Patterns in Agent-Oriented Software Engineering”, in Proceedings of the Third
International Workshop on Agent Oriented Software Engineering (AOSE), Bologna (I), July
2002.
21. Nakamur, Y., Hada, S., Neyama, R., “Towards the integration of Web services security on
enterprise environments”, in Proceedings of 2002 Symposium on Applications and the Internet,
Nara, Japan, January 2002.22. W3C XML Protocol WG, “SOAP Version 1.2 Part 1: Messaging framework”,
http://www.w3c.org/TR/2003/REC-222-part1-20030624
23. W3C XML Protocol WG, “SOAP Version 1.2 Part 2: Adjuncts”,
http://www.w3c.org/TR/2003/REC-222-part2-20030624
24. W3C XML Protocol WG, “Default HTTP Binding”,
http://www.w3c.org/xp/Group/1/10/11/2001-10-11_Framework_HTTP_Binding
25. W3C XML Protocol WG, “SOAP Underlying Protocol Binding Framework”,
http://www.w3c.org/xp/Group/1/10/12/Binding_Framework_Proposal
26. W3C XML Protocol WG, “SOAP v1.2 Email Binding”, http://www.w3c.org/TR/2002/NOTE-
222-email-20020626
27. W3C XML Protocol WG, “Transport Message Exchange Pattern: Single-Request-Response”,
http://www.w3c.org/2000/xp/Group/1/10/11/2001-10-11-SRR-Transport_MEP
28. M. Tatsubori, T. Sasaki, S. Chiba, K. Itano, “A Bytecode Translator for Distributed Execution
of "Legacy" Java Software”, in Proceedings of ECOOP 2001, LNCS 2072, Springer Verlag,
2001.
29. N. Ubayashi, T. Tamai, “RoleEP: role based evolutionary programming for cooperative mobile
agent applications”, Proceedings of the International Symposium on Principles of Software
Evolution, 2000.
30. L. Yu, B.F. Schmid, “A conceptual framework for agent-oriented and role-based workflow
modelling”, in Proceedings of the 1st International Workshop on Agent-Oriented Information
Systems, G. Wagner and E. Yu eds., Heidelberg, June 1999.
31. F. Zambonelli, N. R. Jennings, M. Wooldridge, “Organizational Rules as an Abstraction for the
Analysis and Design of Multi-agent Systems”, International Journal of Software Engineering
and Knowledge Engineering, Vol. 11, No. 3, pp. 303-328, 2001.You can also read
