Use and Reuse of Multi-Agent Models and Techniques in a Distributed Systems Development Framework

Transcription

1 Use and Reuse of Multi-Agent Models and Techniques in a Distributed Systems Development Framework Agostino Poggi, Michele Tomaiuolo Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Viale G.P. Usberti 181A I Parma, Italy {Agostio.Poggi, Michele.Tomaiuolo}@unipr.it Abstract In this paper, we present a software framework, called HDS, that tries to simplify the realization of distributed applications by merging the client-server and the peer-to-peer paradigms and by implementing all the interactions among all the processes of a system through the exchange of typed messages. Typed messages are the element that mainly characterized such a software framework. In fact, they can be considered an object-oriented implementation of an agent communication language message and so they are means that makes HDS a suitable software framework both for the realization of multi-agent systems and for the reuse of multi-agent model and techniques in non-agent based systems. 1 Introduction In the early 1990s, Multi-Agent Systems (MAS) were put forward as a promising paradigm for the realization of complex distributed systems. Over the years, MAS researchers have developed a wide body of models, techniques and methodologies for developing complex distributed systems, have realized several effective software development tools, and have contributed to the realization of several successful applications. However, even if today s software systems are more and more characterized by a distributed and multi-actor nature, that lends itself to be modeled and realized taking advantage of MAS techniques and technologies, very few space in software development. It is due for several reasons [Maříka and Lažanský, 2007; [McKean et al., 2008; DeLoach, 2009; Weyns et al, 2009]. One of the most important reasons is that the large part of software developers have few knowledge about MAS technologies and solutions mainly because of the lack of references to the results of MAS research outside the MAS community. Moreover, even when there is a good knowledge about MAS, software developers do not evaluate the possibility of their use because: i) they believe that multi-agent approaches are not technically superior to traditional approaches (i.e., there are not problems where a MAS approach cannot be replaced by a non-agent approach), and ii) they consider MAS approaches too sophisticated and hard to understand to be used outside the research community. Therefore, it is possible to state that the MAS community has yet to demonstrate the significant benefits of using agent-oriented approaches to solve complex problems, but also that some efforts should be done for making easier the use and the integration of MAS technologies and solutions in mainstream software development technologies and solutions. In particular, MAS developers should avoid to consider MAS solutions a panacea for all the kinds of system. Therefore, a MAS should be realized only when its components must express the typical features (i.e., proactiveness, sociality and goal) that distinguish a software agent from another software component. Moreover, when a new MAS is realized and must be embedded and integrated with an existing software environment where other software systems are running and interact with each other. In this case, MAS developers usually try to propose, as most effective integration solution, the agentification of the other software systems even if this kind of integration, besides requiring the burden of encapsulating the interface of a nonagent-based system with a code that generates and processes messages of the agent communication language (ACL) used by the MAS, often might not guarantee the level of performance, security and transactionality required in such a software environment. It is because the majority of the MAS community has still the belief that agents are the best means for supporting software interoperability. This belief comes from the first important works on multi-agent systems [Genesereth and Ketchpel, 1994; Bradshaw, 1997] and was partially supported by the specifications for [FIPA, 2001]; however, in the last ten years the advent and the success of Web services and service-oriented architecture have shown that what software customers and developers want solutions that simply renew the traditional ways of integrating systems avoiding any solution that might be considered too complex or that might reduce the quality of the system.

2 In this paper, a software framework, called HDS, whose goal is to simplify the realization of distributed applications taking advantage of multi-agent model and techniques and providing an easy way for the integration between MAS and non-agent based systems. The next section describes the main features of the HDS software framework. Section three discusses about the experimentation of such a framework both in using agent techniques inside non-agent based systems and in the realization of MAS. Finally section fours concludes the paper sketching some future research directions. 2 HDS HDS (Heterogeneous Distributed System), is a software framework that has the goal of simplifying the realization of distributed applications by merging the client-server and the peer-to-peer paradigms and by implementing all the interactions among all the processes of a system through the exchange of typed messages. In particular, HDS provides both active and passive processes (respectively called actors and servers) and an application can be distributed on a (heterogeneous) network of computational nodes (from now called runtime nodes). Figure 1 shows the architecture of an HDS distributed system. runtime node actor HDS middleware server Figure 1. The architecture of an HDS distributed system HDS is implemented by using the Java language and takes advantage of preexistent Java software libraries and solutions for managing concurrency and distribution. This implementation, besides realizing the HDS middleware components, provides some components (i.e., interfaces, concrete and abstract classes) to simplify the realization of applications taking also advantages of multi-agent models and techniques. The design of the software has been planned with the goal of guaranteeing an easy realization of several implementations of the HDS middleware taking advantages of different technologies and algorithms without the need of remarkable modifications both on the HDS middleware and on the application code when the application is deployed with a different implementation of the HDS middleware. This feature is important for enabling the use of different solutions for the management of the execution of the processes running inside the same runtime node (i.e., the same Java Virtual Machine), but also for supporting the communication among processes of different runtime nodes. Therefore, while, on the one hand, the HDS framework can be used for the study and the development of new algorithms and software for the management of concurrency and distribution, on the other hand, different concurrent and distribution software libraries can be integrated in such a middleware for obtaining the best implementation of an application also on the basis of the features of the environment where it should be executed. In particular, each node of an application can use a different implementation of the concurrency support and different distribution supports can be used in the same application. To cope with the previous goal the HDS middleware was completely modeled through Java interfaces and then a first implementation was realized by using the concurrent support provided by the standard Java runtime environment and on the distribution support provided by Java RMI [Pitt and McNiff, 2001] and JMS [Monson-Haefel and Chappell, 2000]. In particular, this implementation was modularized to maintain a strong separation between the code that should be reused by all the possible implementations and the code that any different implementation must certainly rewrite. Moreover, the components provided by the HDS framework to simplify the realization of applications (e.g.,, the abstract classes for realizing actors and servers) do not refer to a specific implementation of the HDS middleware, but to its model; therefore, an application can be deployed and executed with one of the available implementations of the HDS middleware by taking advantages of a launching tool, provided by the HDS framework that customizes the application code to a specific middleware implementation by simply injecting very few objects at the startup of each runtime node [Fowler, 2004]. The model and the implementation of the HDS middleware can be divided in three main modules respectively called concurrency, runtime and distribution modules. 2.1 Concurrency Module The concurrency module defines the computational entities that concurrently act inside a runtime node and provides the means for supporting their interaction. These computational entities are called processes and are divided in actors and servers. Actors are active processes that can have a proactive behavior and so can start the execution of some tasks without the request of other processes. Servers are passive processes that are only able to perform tasks in response of the request of other processes. Moreover, while both servers and actors may directly take advantage of the services provided by other kinds of application, only the servers can provide services to external applications by simply providing one or more public interfaces. A process can interact with the other processes through the exchange of messages based on one of the following three types of communication: synchronous communication, the process sends a message to another process and waits for its answer;

3 asynchronous communication, the process sends a message to another process, performs some actions and then waits for its answer; one-way communication, the process sends a message to another process, but it does not wait for an answer. In particular, while actors can start synchronous, asynchronous and one-way communication with all the processes, servers can only starts synchronous communication.. The exchange of messages between two processes is possible thanks to the use a reference. A reference is a proxy of the process that makes transparent the communication respect to the location of the process. Therefore, when a process wants to send a message to another process, it must obtain the reference to the other process and it can be done by taking advantage of the lookup service provided by the runtime module. 2.2 Runtime Module The runtime module defines and implements the basic services that the HDS middleware provides to the processes of an application. This module is based on three main objects respectively called registry, lookup, filterer and factory. The registry and the lookup objects cooperate for guaranteeing the access of a process to the references of the other processes. In fact, while the registry object provides the binding and unbinding of the identifiers of the processes with their reference, the lookup object provides the listing of the identifiers of the processes and the retrieval of a process reference on the basis of the identifier of the process. The filterer object allows the customization of the communication among processes. Normally, a process can communicate with all the other processes of the application and the exchange of messages does not involve any operation that is not related to deliver the message to the destination. However, the filterer object can modify it by dynamically associating additional services (e.g., security, debugging and logging) with the exchange of messages. applied to the input messages and the others are applied to the output messages (Figure 2 shows the flow of messages from the process reference to the output message filters). The primary scope of a message filter is to disable the reception / sending of some messages, but they can be used for performing operations on messages (e.g., encryption and decryption). Finally, the factory object has the duty of creating the processes. This object performs the most important tasks for customizing the application code to a specific middleware implementation. In fact, when it creates a new process, it binds the application code encoded into such a process with the middleware components providing the concurrent support that is necessary for the execution and the exchange of messages of the process. 2.3 Distribution Module The distribution module has the goal of supporting the communication of the processes of a runtime node to the processes of the other nodes of the application possibly through different types of communication supports (Figure 3 shows an application whose runtime nodes are connected through two different type of communication technology). This module is based on: a distributor object, some connector objects and some connection objects. The distributor object has the duty of managing the connections of a runtime node towards the other runtime nodes of the application. The distributor object does it through a set of connector objects. A connector object is a connections handler that manages the connections of a runtime node realized with a specific communication technology. A connector object does it through a set of connection objects. distributor connection process input filters output filters... mailer... reference Figure 2. Flow of the messages from the process reference to the output message filters. In fact, the filterer object can associate two lists of compositional filters [Bergmans & Aksit, 2001] with each process. These compositional filters (from now called message filters) are applied to the message exchanged by the process: the ones of the first list are RMI connectors Figure 3. A distributed application based on three run time nodes connected through the use of RMI and JMS communication technologies. A connection object manage a mono-directional communication channel from/to another runtime node of the application. In particular, a connection provides a remote lookup service that provides the listing of the remote processes and the access to their references. 2.4 Typed Messages JMS connectors Processes interact through messages that can considered typed because of their content. In fact, the content of a message is represent by an object whose type in-

4 dicates the use that the receiver should make of the content of the message. Perform Request Inform Query Content Figure 4. Classification of the content of the messages derive from ACL communicative acts. Typed messages allow to couples the meaning of the communicative acts of an ACL with the meaning of the concepts expressed by a domain ontology. In fact, a first hierarchy of Java interfaces can allow to split the messages on the basis the ACL communicative acts perform and then other interfaces and concrete classes can specialize such interfaces for defining the ontology of a specific application domain, i.e., the messages exchanged during the execution of the tasks of such an application domain. However, in the current implementation of the HDS framework, messages are not classified on the basis of the complete list of the communicative acts provided by an ACL (i.e., KQML [Finin et al., 1994] or FIPA ACL [FIPA, 2001]), but: i) messages are split into request and response messages, ii) request messages are split in perform, inform and query messages, and iii) and response are split into result and error messages. It can be done because from our experience and from the analysis of several real application scenarios and software implementation, what can be important (or at least can simplify the implementation) in some kinds of application is to be able to distinguish i) the requests that require a simple exchange of data (i.e., inform and query requests) from the ones that require the execution of actions (i.e., perform requests), and ii) the positive and negative responses. shows the hierarchy of interfaces classifying message content on the basis of ACL communicative acts. 2.5 Development Supports Result Response Error HDS provides some software components and tools for simplifying the development of applications. In fact, the definition of actors and servers is simplified by the availability of an actor and a server abstract class that provide the methods for getting the information about the other processes of the application and for exchanging messages with them. Moreover, the startup of an distributed application is possible through a launching tool that uses a set of configuration files for starting an initial set of process, for defining the set of rules that associate message filters with processes and for initializing the connections between the different runtime nodes of an application. Finally, the monitoring and debugging of a distributed application is simplified for a set of tools that take advantage of message filters for tracing and/or the interactions between the processes. 3 HDS and MAS The features offered by the HDS framework make possible and quite simple the extension of HDS software both for the realization of multi-agent systems and for the reuse of the typical models and techniques, that are exhibited in multi-agent systems, in other kinds of software systems. In fact, while, on the one hand, the features provided by an actor make it suitable for the realization of some processes that exhibit the typical behavior of the most known agent architectures, on the other hand, the features provided by typed messages make them suitable for implementing the usual coordination and negotiation techniques expressed by multiagent systems. Moreover, the features provided by typed messages make them suitable for implementing such coordination and negotiation techniques outside a multi-agent system and without any (or with a limited) knowledge about agent communication languages and ontologies. As a first step for taking advantage of agent models and techniques in the HDS framework, we realized some software components for simplifying the realization of BDI agents [Rao and Georgeff, 1995] and the use of the interaction protocols defined in the FIPA specifications [FIPA, 2001]. In particular, we realized an abstract implementation of a BDI agent by extending the abstract actor class with: i) a working memory, where maintaining the beliefs, desires and intentions of the agent, ii) a plan library, where maintaining the set of predefined plans and iii) an interpreter able to select the plan that must be used to achieve the current intension, and able to execute it, but without the possibility of stopping it before its complete execution. Therefore starting from this abstract implementation, a concrete BDI agent can be obtained by providing the code for initializing and updating the working memory and for filling the plan library, Moreover, we realized an abstract implementation of some interaction protocols that derive from the interaction protocols defined in the FIPA specifications. This implementation replaces the ACL messages with typed messages delegates to the application developer only the duty of writing the code processing the content of the message, selecting the the message to be sent and building its content. The use of both the BDI agent abstract class and the interaction protocols software library have been experimented in an market place application, where agents can buy and sell goods through the use of English and Dutch auctions. In particular, we realized two different implementations: the first implementation was based on the use of both the BDI agents and the interaction protocols software library, and the second implementation was based only on the use of the interaction protocols software library. This experimentation was done by two groups of master students: the students of the first group had a good knowledge about artificial intelligence and agent-based systems because they followed two courses on those topics and the student of the second group had few knowledge about such topics because they did

5 not follow any related course. In few words, the results of the experimentation were that all the students have not difficulties to obtain a goad implementation of the version of the application without the use of the BDI agents, but while the students without any knowledge about artificial intelligence and agent-based system had very difficulties for realizing the version of the application based on the use of BDI agents obtaining some implementations that do not completely exploit BDI agent features, the other students did it obtaining more flexible implementations respect to the ones without BDI agents, but spending a lot of time in their implementation. 4 Conclusions This paper presented a software framework, called HDS, that has the goal of simplifying the realization of distributed applications by merging the client-server and the peer-to-peer paradigms and by implementing all the interactions among all the processes of a system through the exchange of typed messages. HDS can be considered a software framework for the realization of any kind of distributed system. However, some of its functionalities derive from the one offered by JADE [Bellifemine et al., 2001; Bellifemine et al., 2008] that must be considered one of the most known and use software framework for the developing of MAS. It is not depends only on that the people involved in the development of the HDS software framework was involved in the development of JADE too, but Acknowledgments. References [Bellifemine et al., 2001] Fabio Bellifemine, Agostino Poggi and Giovanni Rimassa. Developing multi agent systems with a FIPA-compliant agent framework. Software Practice & Experience, 31: , [Bellifemine et al., 2008] Fabio Bellifemine, Giovanni Caire, Agostino Poggi and Giovanni Rimassa. JADE: a Software Framework for Developing Multi- Agent Applications. Lessons Learned. Information and Software Technology Journal, 50:10-21, [Bergmans and Aksit, 2001] Lodewijk Bergmans and Mehmet Aksit. Composing crosscutting concerns using composition filters. Communications of ACM, 44(10):51-57, [Bradshaw, 1997] Jeffrey M. Bradshaw. An introduction to software agents. In, Jeffrey M. Bradshaw, editor, Software Agents, pp. 3-46, MIT Press, Cambridge, MA, [DeLoach, 2009] Scott A. DeLoach. Moving multiagent systems from research to practice. Agent- Oriented Software Engineering, 3(4): , [Finin et al., 1994] Tim Finin, Richard Fritzson, Don McKay and Robin McEntire. KQML as an agent communication language. In Proc. of the Third international Conference on information and Knowledge Management, pp , Gaithersburg, MD, [FIPA, 2001] FIPA Specifications, Available from [Fowler, 2004] Martin Fowler. Inversion of control containers and the dependency injection pattern, Available from: [Genesereth and Ketchpel, 1994] Michael R. Genesereth and Steven P. Ketchpel. Software Agenta, Communications of ACM, 37(7):48-63, [Maříka and Lažanský, 2007] Vladimír Maříka and Jiří Lažanský. Industrial applications of agent technologies. Control Engineering Practice, 15(11): , [McKean et al., 2008] Jez McKean, Hayden Shortery, Michael Luckz, Peter McBurneyxand Steven Willmott. Technology diffusion: analysing the diffusion of agent technologies, Autonomous Agents and Multi-Agent Systems, 17(2): , [Monson-Haefel and Chappell, 2000] Richard Monson-Haefel David Chappell. Java Message Service. O'Reilly & Associates, [Pitt and McNiff, 2001] Esmond Pitt and Kathy McNiff. Java.rmi: the Remote Method Invocation Guide. Addison-Wesley, [Rao and Georgeff, 1995] Anand S. Rao, Michael P. Georgeff: BDI Agents: From Theory to Practice. In Proc. of the First International Conference on Multiagent Systems, pp , San Francisco, CA, [Weyns et al, 2009] Danny Weyns, Alexander Helleboogh and Tom Holvoet. How to get multiagent systems accepted in industry? Agent-Oriented Software Engineering, 3(4): , 2009.