Modeling Role-based Interactions for Agents Giacomo Cabri, Letizia Leonardi Dipartimento di Ingegneria dell’Informazione Università di Modena e Reggio Emilia Via Vignolese, 905 – 41100 Modena – ITALY {giacomo.cabri, letizia.leonardi}@unimo.it Abstract Software agents, thanks to their autonomy in carrying out tasks, are fruitfully exploited in large-scale distributed environments, such as the Internet. In such a scenario, interactions among agents are an issue that must be faced in an appropriate way. This paper proposes an interaction model based on roles, being a role a set of capabilities and an expected behavior. Modeling interactions by roles can simplify the design of the agent-based applications. A notation based on XML is adopted to support the definition and the exploitation of roles at different phases of the application development. Finally, an application example shows the effectiveness of the approach.
1
Introduction
As software agents are spreading over distributed environments, and in particular over the Internet, new methodologies and tools are needed to support the development of agent-based applications. Such applications are usually composed of a multiplicity of agents, each one in charge of a small task that is part of the global goal. In this scenario, an important issue to be faced is the interaction among agents. In fact, the agents belonging to the same application need to interact and coordinate to carry out the global goal. Moreover, in an open scenario, agents belonging to different applications may need to interact, for instance, to compete for a resource. So, interactions can occur between agents of the same application, or between agents belonging to different applications, and such interactions must be modeled and managed in an appropriate way. Traditional approaches to agent interactions usually derive from adaptations of older models related to distributed systems, so they do not fit all the characteristics of the new scenario. This paper proposes a model for engineering agent interactions based on the concept of role. A role is
Franco Zambonelli Dip. di Scienze e Metodi dell’Ingegneria Università di Modena e Reggio Emilia Via Allegri 13 – 42100 Reggio Emilia – ITALY
[email protected] defined as a set of capabilities and an expected behavior. The former is a set of actions that an agent playing such role can perform to achieve its task. The latter is a set of events that an agent is expected to manage in order to “behave” as requested by the role it plays. Interactions among agents are represented by a couple action-event, whose translation is in charge of the underlying interaction system, which can enforce local policies and rules. There are different advantages in modeling interaction by roles. First, it enables a separation of concerns between the algorithmic issues and the interaction issues in developing agent-based applications. Second, it permits the reuse of solutions and experiences; in fact, roles are related to a context, and designers can exploit previously defined roles for the context their application belongs; roles can also be seen as sort of design patterns [2]: a set of related roles along with the definition of the way they interact can be considered as a solution to a well-defined problem, and reused in different similar situations. Finally, roles can be exploited to easily build agent-oriented interfaces of Internet sites [5]. The paper is organized as follows. Section 2 introduces the background and explains the motivations of our work. Section 3 presents how we model roles and their interactions, on the basis of capabilities and behavior. Section 4 presents XRole, an XML-based notation for the introduced model. In Section 5 we report an application example of the exploitation of roles. Section 6 presents some related work. Finally, Section 7 concludes the paper and sketches some future work.
2
Background and Motivations
Since the rising of distributed systems, the interaction among entities has been an issue to be faced carefully. Different approaches have been proposed, among which the most popular is the message-passing [12, 22]; it enables the exchange of messages between two entities, and it is simple and suits a wide range of application
requirements. Another interaction approach that is worth being mentioned is Linda [1], which is based on an uncoupled coordination model and relies on shared dataspaces. With the advent of agents, the problem of dealing with interactions has been more focused. In fact, one of the main features of agents is sociality, i.e., the capability of interacting each other. This feature is exploited in Multi Agent Systems, where the main task is divided into smaller tasks, each one delegated to a single agent; agents belonging to the same application have to interact in order to carry out the task [14]. Moreover, the diffusion of open systems, such as the Internet, has led to a scenario in which not only agents of the same application interact in a cooperative way, but also agents of different applications may interact in a competitive way, for example to achieve resources. The feature of mobility, which allows agents to change their execution environment, adds great flexibility at both conceptual and implementation levels, but also introduces peculiar issues in interaction that must be taken into account carefully [13]. There have been different proposals in the area of agent interaction and coordination [6]. They have concerned message passing adapted to agents, “meeting point” abstractions [23], event-channels [3], and tuple spaces [7]. Another interesting approach is the one adopted in Agentis [16], which models interactions in terms of services and tasks; it clearly points out the need of tailoring interactions on agent features. A related issue concerns the notation that can be exploited to represent agent interaction: it is likely that a notation based on the UML language will have a more widespread success than other proposals [19, 20]. From the analysis of the situation, we argue that traditional approaches to agent interactions suffer from being adaptations of older approaches in the distributed system area and do not take into account the new scenario. In particular, traditional approaches often consider agents as bare objects; this has implied that the different features of agents have been managed in different ways, leading to fragmented approaches. Moreover, several approaches focus only on one phase of the agent applications. Our aim is modeling agent interactions on the basis of the following requirements: o Agent oriented features. To overcome the limitations due to the fact that proposals are adaptations of older models, the most important requirement is that interactions are modeled following an agent-oriented approach, i.e., all the peculiar features of agents must be taken into account. o Separation of concerns. We argue that an important aspect in the development of agent applications, and
in particular of MAS, is the separation of concerns between algorithmic issues and interaction issues. This helps in developing applications because allows facing the two issues separately, leading to a more modular approach. o Independence. It is quite obvious that a model is independent of platforms and applications; moreover, we require a model that is independent of environments, and that enables a useful notation, which allows interoperability and independence. o Concrete usability. We are not interested in producing a formalism for interactions, instead, we would like to promote a way to support and simplify the development of interactions in agent-based applications. o Promotion of locality. A trend that has recently appeared and seems to be accepted in the agent area is the adoption of locality in agent interactions, i.e. the environment is modeled as a multiplicity of local interaction contexts, representing the logical place where agent interaction activities occur, which can change depending on the agents’ movement. In fact, depending on its current location, an agent is situated on a given interaction context and there will be enabled to access local resources and to interact with local executing agents [10]. As stated in the introduction, and explained in detail in the following section, we argue that interactions based on the concept of role well suit the above-sketched requirements.
3
Modeling Roles and Interactions
In this section we presents the models of roles and of interactions; in the last subsection we discuss how our approach meets the requirements presented in the previous section.
3.1
Modeling Roles
In our approach, a role is modeled as a set of the capabilities and an expected behavior, both related to the agent that plays such role (see Figure 1). Even if this definition is a little bit different from the classical one based on rights and duties, we think that it better suits the main feature of agents: proactiveness and reactivity. The former point in our model is that a role is a set of capabilities, i.e., a set of actions that agents assuming a given role can perform. Since the proactiveness feature of agents, they have to perform actions to carry out their tasks, and so, they must be enabled to do it. This has to face different issues, such as heterogeneity, complexity of interactions, presence of competitive agents, and local needs. The latter point is that an agent assuming a given role is expected to exhibit a specific behavior. Since the
agents are reactive, they are sensible to what happens in the environment where they live, no matter if it is a specific request rather than a change occurred. The “expected behavior” is the reactions to incoming events; it is “expected” because the agent is supposed, at least, to receive events. We think that a behavior in terms of managed events can well shape the reactivity feature of agents. So, in BRAIN a role is concretely represented by actions that agents can perform and by which it acts, and events that agents receive and by which perceives the world.
agent capabilities
role
behavior
the multi-agent applications and to meet all the requirements of emerging scenarios [8]. In this system structure (see Figure 2), the application level is represented by the agents; the lowest level concerns the environment, which defines its own policies to rule agentto-agent and agent-to-resources interactions. The middle level is the one focused in this paper, and enables the interactions among agents and between agents and the environment, by using the concept of role explained in the previous subsection. An interaction between two agents occurs when one agent performs an action (chosen among the set of capabilities belonging to the role it plays) and such action is translated into an event that is notified to another agent that exhibits the specific behavior. The underlying interaction infrastructure (part of the environment level) can provide for the translation from actions to events (see Figure 3).
Figure 1. The adopted role model There are some characteristics of roles that lead to deal with them separately from the concept of agent. The role is temporary, since an agent may play it in a welldefined period of time or in a well-defined context. Roles are generic, in the sense that they are not tightly bound to a specific application, but they express general properties that can be used in different applications and then for different agents. Finally, roles are related to contexts, which means that each environment can impose its own rules and can grant some local capabilities, forcing agents to assume specific roles. 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 agents that assume it. application level role level
environment level
role
role
interaction infrastructure
Figure 2. The system structure for interactions based on role
3.2
Interaction Model
To model agent interactions we propose a three-level system structure, thought to overcome the complexity of
Role A
capabilities
Role B
action
Interaction infrastructure
event
behavior
Figure 3. Interaction between two agents An interaction must not be thought as a simple “message passing”, for the following reasons. First, the description of the capabilities in terms of actions, and of the behavior in terms of events, can be exploited at the analysis and design phase of the development to describe the main features of an agent playing that role. Second, our interaction system could be an active channel, exploited to enforce local laws. Third, it is not mandatory that an action is translated into an event and an event is generated by an action. An action could be managed directly by the interaction system, for example if it relates the access to a local resource. Similarly, an event could be a “system event”, i.e. an event generated by the environment.
3.3
Discussion
The advantages we can find out in our approach are the following. o Our model enables a separation of concerns between the algorithmic issues of an agent and the interaction issues [9]. In fact, our model lets developers focus on the interaction among their agents, or, better, among the roles that agents are going to play. o Our model is agent-oriented, since it concerns the three main features of agents, reactivity, proactiveness and sociality: reactivity is dealt with by events, proactiveness is dealt with by actions, and
sociality is the possibility of translating actions in events. Moreover, this model starts from the agent scenario, and it is not an adaptation of older approaches in the distributed area. o Our model is independent of the actual implementation of agent applications, and, in particular, of the adopted communication mechanism. For instance, the interaction system can be implemented by a message-passing information channel, or can follow an uncoupled approach based on dataspaces. o Our model well fits locality in interactions, since roles are related to given contexts, and enable interactions among agents local to a given context, no matter if it is a physical or a logical context. The interaction model presented in this section can be fruitful exploited thanks to a notation that will be explained in the next section.
4
XRole
Starting from the role model of the previous section, we have developed XRole [8], a system for the definition of roles for agents. The main aim of XRole is to support the management of the interactions among agents, at the different phases of the development of agent-based applications. XRole adopt the model of role described in this paper, based on actions and events (see Figure 3). XRole exploits the XML language to build up definitions of roles. XML, representing information in a tagged form, exhibits the well-appreciated feature of human-readability and the platform-independence required for the Internet. This allows a high degree of interoperability and helps in dealing heterogeneous situations such as the ones of the Internet. By using XML, the description of each role can be presented to people via an appropriate XSL sheet that transforms the information in a human-understandable document, for instance an HTML page with the needed pieces of information. This makes designers aware about the roles defined in a given context, and let them choose the representation of the information that better suits their requirements. In addition, programmers can exploit automatic tools to search for roles matching given keywords and present the results in a tailored way. A further advantage of XML is that documents can be managed also by the agents themselves, which can be enabled to understand the content of a XML documents and exploit or manipulate it without the need of the intervention of human people. With regard to the catalogues of roles, we point out that XML carries great advantages, since the same XML document can be exploited for both the description of a role and the operative use of it. Finally, the advantage of exploiting
the XML language is that this definition of role can be extended, to meet specific requirements that will arise in the future.
Figure 4. The XML Schema followed by roles defined in XRole In XRole, roles are defined by XML documents that respect the XML Schema reported in Figure 4. The XML Schema of a role shows that there are three main parts that have to be specified in the definition of a role, following the above-described model: o The basic information. This part includes the pieces of information that are used to identify the role, and to specify a context for such role. Moreover, a highlevel description and some keyword are supplied to let developers better understand the role
functionalities. The allowed actions. Each role defines which are the allowed actions, i.e. the actions needed to carry out a task related to such role. An action is characterized by a name and a high-level description that can be useful for developers. Moreover, there are two elements that specify the addressee of the action and the content, which can be exploited for further information. o The recognized events. These are events that the agent is expected to accept and manage. An event, as an action, is characterized by a name and a highlevel description that is useful to developers. The other two elements specify who performed the related action, and the event content, which again is very general. A role is defined by an XML document that is valid with regard to the presented Schema. The content of the XRole document can be translated into appropriate representations by XSL sheet, for instance into an HTML page describing the features of the role to the designers; or in a Java interface that can be directly used by implementers. It is worth noting that each representation derives from the same information, so it is kept in the different phases of the development of applications. Putting all together, the advantages of the use of XRole are the following: o XRole enables a notation for the interaction model introduced in the previous section; thus, it derives all the related advantages, in terms of separation of concerns, agent-oriented features, independence of communication mechanisms, and promotion of locality in interactions. o XRole grants a high degree of interoperability, since it is based on XML and it is not bound to a given agent system nor to a given interaction infrastructure. For these reasons, XRole can be exploited across different platforms. o XRole supports developers in every phase of the software life cycle. Via appropriate XSL sheets, the information about a role can be represented in different ways, depending on the interests of developers. For instance, starting from the XML document can be generated an HTML page that summarizes the role features for a designer; at the implementation phase, a Java interface can be derived to write actual code; this let designers and implementer share the same information at different levels. o Roles defined by XRole can be read by human people, by automatic tools and by agents themselves. This not only enables the support in different phases of the development, but also can allow the exploitation of roles even at runtime by agents,
which can dynamically search for appropriate roles and assume them.
o
5
Example
The example we propose in this section is related to the game world. In a game there are well-defined interactions, which occur in a given order, and follow the game-specific laws. Here we do not focus on a specific game, but we show roles and interactions of a generic game, which can be adapted to specific games by defining the appropriate laws. Actually, several contexts in which agents interacts could be seen as instances of the generic game presented in the following. We have two roles in our applications: the player and the game manager. In each game there is one manager and one or more players.
5.1
The Player Role
Each agent that wants to participate to the game has to assume the role of player. The actions that can be performed by a player are: - askKind. This action is used to ask the manager what kind of game it manages. - reqPlay. The player requests the manager to play in the current game. - move. By this action, the player tells the manager the willing of making a move. The action must contain also the description of the move. - giveUp. It is used to notify the manager that the player leaves the current game. - talk. This action is exploited to communicate with another player. The events that a player must deal with are: - notifyKind. By this event, the player is notified about the kind of the current game. This event is associated to a string that contains the actual kind. - accept. The player is accepted by the manager in the current game. - refuse. The player is refused by the manager in the current game. - notifySituation. The player is told by the manager about the current situation of the game. - requestMove. The player is requested by the manager to make a move. - refuseMove. The move of the player has been refused by the manager. - gameWon. The player is notified it is the winner of the game. - gameLost. The player is notified it lost the game. - gameOver. The player is told by the manager that the game is over. - talk. Another player wants to talk.
5.2
The Manager Role
5.3
Each instance of the game is ruled by an agent playing the role of manager. The actions that can be performed by a manager are: - notifyKind. The manager notifies a player about the kind of the current game. - accept. The manager notifies a player that it has been accepted in the current game. - refuse. The manager notifies a player that it has been refused in the current game. - notifySituation. The manager tells a player the current situation. - requestMove. The manager requests a player to make a move. - refuseMove. The manager refuses a move of a player. - gameWon. The manager tells a player it has won the game. - gameLost. The manager tells a player it has lost the game. - gameOver. The manager tells a player that the game is over. The events that a manager must deal with are: - askKind. The manager is notified that a player asks for the kind of game. - reqPlay. The manager is notified that a player has requested for playing. - move. The manager is notified about a move of a player. - giveUp. The manager is notified that a player wants to leave the game. Note that the actions of the player usually correspond to the event handled by the manager, and vice versa.
Player
Manager
askKind notifyKind reqPlay accept refuse move giveUp
Figure 5. Sequence diagram of some interactions between a player and a manager
The Interactions between Roles
From the actions and events described in the previous two subsections one can find out that an event of a role corresponds to an action of the other role. For instance, the askKind action of the Player role corresponds to the askKind event of the Manager role. Besides the same name (which is not mandatory), this couple action-event shows which is the interaction The sequence diagram of Figure 5 reports some allowed interactions between a Player and a Manager. As shown, the diagram describes also more complex interactions, which involves more couples action-event. For example, the upper interaction of the diagram involves 2 actions and 2 events, because the Player role performs an askKind action that is translated into the askKind event for the Manager, which in turn replies by performing a notifyKind action that is received by the Player as a notifyKind event.
6
Related Work
Even if it has not been designed in connection with roles, Aspect Oriented Programming (AOP) seems to provide interesting mechanisms to support the management of roles for agents [11]. AOP starts from the consideration that there are behaviors and functionalities that are orthogonal to the algorithmic parts of the objects [18]. So, it proposes the separate definition of components and aspects, to be joined together by an appropriate compiler (the Aspect Waver), which produces the final program. The separation of concerns introduced by AOP permits to distinguish the algorithmic issues from the behavioral issues. Since an aspect is “a property that affects the performance or semantics of the components in systemic way”, it is evident the similarity with a role. AOP is thought to achieve performance and maintainability in software development. In our opinion, even if the AOP is very similar to our approach, one possible limitation is its lack of flexibility in the definition and usage of aspects. This is due to the fact that AOP focuses on software development rather than addressing the uncertainty and complexity issues of wide-open environments, such as the Internet. The AOP has been exploited to implement the concept of role by E. Kendall [17]. She well describes the importance of modeling roles for agent systems. Our aim is to go beyond Kendall’s considerations, and to propose roles as intermediaries for the interactions between agent applications and environments. Our concept of role is more dynamic and aims at covering different stages of the life cycle of agent-oriented applications in a more practical way, concretely supporting both the design and the implementation phases. AALAADIN [15] is a meta-model to define models of
organizations. It is based on three core concepts: agent, group and role. Even if our approach is quite similar to the AALAADIN one, it differs for some reasons. First, we disregard the concept of group, while focusing on the interactions among agents and between agents and environments. Second, AALAADIN roles are tightly bound to the notion of agent, while our aim is to describe roles in a more independent way, both of applications and environments. Third, in AALAADIN, environments are mainly modeled by service agents, which is generally acceptable, but do not cover all real situations, where also agents that play roles of “pure clients” must be taken into account. The ROPE project [4] recognizes the importance of defining roles as first-class entities, which can be assumed dynamically by agents. It proposes an integrate environment, called ROPE (Role Oriented Programming Environment), which can be exploit to develop applications composed by several cooperating agents. Rather than defining an integrated but close environment, we aim at proposing an open methodology to define agent roles. We address interoperability and also the dynamic use of roles. Moreover, our definition of roles can be exploit also for interactions among agents that do not belong to the same application (i.e., are competitive); this is a relevant aspect in the design of applications for wide-open environments, such as the Internet. Finally, the XML language has been exploited to coordinate the interactions in a workflow scenario. In particular, the Workspaces effort [21] goes in this direction, proposes the coordination of activities through the manipulation of XML documents via XSL sheets. XSL are used to define the rules to which the workflow system is subject. This approach shows the great flexibility of the XML language and the related tools. However, differently from us, it disregards roles, which can improve the flexibility of the approach.
interaction system based on the presented model. In this effort, the exploitation of roles at runtime by agents is an important issue to be faced, also related to the actual implementation of roles. In fact, it may require appropriate mechanisms and constructs, possibly provided by the implementation language. Then, even if the shown application example involves general interaction issues, other application areas must be assumed as test bed to evaluate the usability of our approach, and designers and development must be involved to evaluate our approach. Such evaluation will be better supported by the availability of an implemented interaction system. In particular, we have chosen to apply roles to mobile agents, to perform tests in a very dynamic environment.
7
[5] G. Cabri, “Role-based Infrastructures for Agents”, The 8th IEEE Workshop on Future Trends of Distributed Computing Systems (FTDCS 2001), Bologna (I), October 2001
Conclusions and future work
This paper proposes a model for the agent interactions based on the concept of role. A role is modeled as a set of capabilities (actions) and an expected behavior (events). The translation from actions to events enables interactions between agents. This model achieves several advantages in terms of separation of concerns, agentoriented features, independence of communication mechanisms, and promotion of locality in interactions. An XML-based notation, XRole, enables the concrete exploitation of interaction roles at different phases of the development of agent-based applications, from the design phase to the implementation. With regard to future work, we point out some research directions. We are currently implementing an
Acknowledgements. Work supported by the NOKIA Research Center of Boston and by the Italian MURST within the project “MUSIQUE - Multimedia Ubiquitous Service Infrastructure in a QoS Universal Environment”.
References [1] S. Ahuja, N. Carriero, and D. Gelernter, “Linda and Friends”, IEEE Computer, Vol. 19, No. 8, pp. 26-34, August 1986. [2] Y. Aridor, D. Lange, “Agent Design Pattern: Elements of Agent Application design”, International Conference on Autonomous Agents, ACM Press, 1998. [3] J. Baumann, F. Hohl, K. Rothermel, M. Straßer, “Mole Concepts of a Mobile Agent System”, The World Wide Web Journal, Vol. 1, No. 3, pp. 123-137, 1998. [4] M. Becht, T. Gurzki, J. Klarmann, M. Muscholl, “ROPE: Role Oriented Programming Environment for Multiagent Systems”, The Fourth IFCIS Conference on Cooperative Information Systems (CoopIS'99), Edinburgh, Scotland, September 1999.
[6] G. Cabri, L. Leonardi, F. Zambonelli, “Mobile-Agent Coordination Models for Internet Applications”, IEEE Computer, Vol. 33, No. 2, pp. 82-89, February 2000. [7] G. Cabri, L. Leonardi, F. Zambonelli, “MARS: a Programmable Coordination Architecture for Mobile Agents”, IEEE Internet Computing, Vol. 4, N. 4, pp. 26-35, July-August 2000. [8] G. Cabri, L. Leonardi, F. Zambonelli, “XRole: XML Roles for Agent Interaction”, 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.
[9] 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), at the International Conference on Distributed Computing Systems (ICDCS 2002), Wien, July 2002 [10] G. Cabri, L. Leonardi, F. Zambonelli, “Engineering Mobile Agent Applications via Context-dependent Coordination”, IEEE Transactions on Software Engineering, to appear. [11] Communication of the ACM, Special Issue on Aspect Oriented Programming, Vol. 33, No. 10, October 2001. [12] R. G. Chandras, “Distributed Message Passing Operating Systems”, Operating Systems Review, Vol. 24, No. 1, pp. 7-17, 1990. [13] P. Domel, A. Lingnau, O. Drobnik, “Mobile Agent Interaction in Heterogeneous Environment”, The 1st International Workshop on Mobile Agents, LNCS, Springer-Verlag (D), No. 1219, pp. 136-148, April 1997. [14] A. El Fallah-Seghrouchni, S. Haddad, H. Mazouzi, “Protocol Engineering for Multi-agent Interaction”, The 9th European Workshop on Modelling Autonomous Agents in a Multi-Agent World (MAAMAW '99), Valencia, Spain, June 1999. [15] J. Ferber and O. Gutknecht, “AALAADIN: A meta-model for the analysis and design of organizations in multi-agent systems”, The Third International Conference on MultiAgent Systems (ICMAS), Cite des Sciences - La Villette, Paris, France, July 1998. [16] M. d’Inverno, D. Kinny, M. Luck, “Interaction Protocols in Agentis”, The Third International Conference on
Multi-Agent Systems (ICMAS), Cite des Sciences - La Villette, Paris, France, July 1998. [17] E. A. Kendall, “Role Modeling for Agent Systems Analysis, Design and Implementation”, IEEE Concurrency, 8(2):34-41, April-June 2000. [18] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J. M. Loingtier, J. Irwin, “Aspect-Oriented Programming,” Xerox Corporation, 1997. http://www.parc.xerox.com/csl/projects/aop/ [19] J. Lind, “Specifying Agent Interaction Protocols with Standard UML”, The 2nd International Workshop on Agent Oriented Software Engineering (AOSE), Montreal (C), May 2001. [20] J. Odell, H. Van Dyke Parunak, B. Bauer, “Representing Agent Interaction Protocols in UML”, Agent Oriented Software Engineering, Paolo Ciancarini and Michael Wooldridge eds., Springer-Verlag, Berlin, pp. 121–140, 2001. [21] R. Tolksdorf, “Coordinating Work on the Web with Workspaces”, 9th IEEE Workshops on Enabling Technologies: Infrastructures for Collaborative Enterprises, Gaithersburg (MA), IEEE CS Press, June 2000. [22] D. W. Walker, “The Design of a Standard Message Passing Interface for Distributed Memory Concurrent Computers”, Parallel Computing Vol. 20, No. 4, pp. 657673, 1994. [23] J. White, “Mobile Agents”, in Software Agents, J. Bradshaw (Ed.), AAAI Press, pp. 437-472, 1997.
