eAgents: An Approach for Modeling and Simulating Multi-Agent Systems
چکیده
The shift from traditional store-and-catalogue business transactions to internet-enabled e-commerce promises to change the way businesses interact with each other and with their customers in several fundamental ways. It has also been claimed that e-commerce has the potential to create an environment where companies will be at their most agile and marketplaces will approach perfect efficiency. Hence it is worthwhile to investigate how useful e-commerce would truly be. In other words, we would need to ask (and obtain answers for) questions such as: how to prevent decision-makers from being overwhelmed with too much information, how to efficiently build and manage certain kinds of e-commerce environments, etc. Many researchers are turning to architectures of collaborating agents to provide answers to these and other questions, since agents and multiagent systems seem to be highly promising technologies for e-commerce applications. However, before we build and deploy multi-agent systems on a large scale, we need to be sure that they deliver as promised, and we need to determine this at minimal cost. Hence there is a need for modeling and simulating such systems. In this paper, we first present a lifecycle-based approach to simulating multi-agent systems borrowing from ideas developed in Software Process Modeling research. We then present a reference architecture for multiagent systems called eAgents. Using the eAgent architecture as a building block, we show how large multiagent systems can be simulated, and their behavior observed and measured for different e-commerce models and situations. Introduction and Motivation The advent of e-commerce has revolutionized typically store-and-catalogue business transactions to such an extent, that it has been claimed that e-commerce will maximize the agility of businesses. Hence there is a need to investigate how true this claim would be. In other words, we need to investigate and answer questions such as: how to prevent decision-makers from being overwhelmed with too much information, how to efficiently build and manage certain kinds of e-commerce environments, etc. Many researchers are turning to architectures of collaborating agents to provide answers to these and other questions, since agents and multi-agent systems seem to be highly promising technologies for e-commerce applications. However, before we build and deploy multi-agent systems on a large scale, we need to be sure that they deliver as promised, and we need to determine this at minimal cost. Hence there is a need for modeling and simulating such systems. To that end, in this paper, we first present a lifecycle-based approach to simulating multi-agent systems borrowing from ideas developed in Software Process Modeling research. We then present a reference architecture for multi-agent systems called eAgents. Using the eAgent architecture as a building block, we show how large multi-agent systems can be simulated, and their behavior observed and measured for different e-commerce conditions and situations. The rest of this paper is structured in two parts. The first part of the paper discusses our approach to lifecycle-based multi-agent system simulation. In the third section, we introduce the reader to Software Process modeling, and our simulation approach. The fourth section discusses two well-known approaches to multi-agent system simulation. The fifth and sixth section s describe our simulation approach in greater detail. Intelligent Agent and Multi-Agent Systems 1844 2003 — Ninth Americas Conference on Information Systems The second part of the paper describes our eAgent reference architecture in the seventh section, which we propose as a means to model and represent agents for multi-agent simulation. In the eighth section, we show how our simulation approach is different from the other work in this area. The ninth section concludes with directions for further research in this area. Introduction to Agents and Workflow Currently, there is not much consensus on what an “agent” is, and many definitions abound. For our purposes, we will adopt the following one-line definition [MASIF]: “ An agent is a computer program that acts autonomously on behalf of a person or organization”. To this we add another definition, which is “an autonomous software component that interacts with its environment and with other agents” (Griss, 2000). Hence we define an agent as “a software component that acts autonomously on behalf of a person or organization, and is also able to interact with its environment and with other agents”. We also require our agent to possess the following characteristics: autonomous (able to function by itself without direct user intervention), pro-active (capable of adjusting its behaviour on its own in response to changing stimuli), reactive (capable of reacting to external stimuli), and social (capable of negotiating with other agents) Agents can be characterized as “weak” or “strong” agents (Wooldridge and Jennings, 1995). “Weak” agents possess the characteristics described above, whereas “strong” agents possess the following additional characteristics: mentalistic notions (they have Beliefs, Desires & Intentions [BDI]), rationality (capable of reasoning about their actions and perform actions in line with their BDI), and learning (capable of learning from their actions and the external environment). In this paper, we will restrict our attention primarily to weak agents. Another (7-axis) characterization of agents can be found in (Griss 2000): adaptability (the degree to which an agent’s behavior can be changed), autonomy (the degree to which agents are able to pursue their goals independently), collaboration (the degree to which agents work cooperatively), intelligence (the degree to which agents display knowledge and understanding), mobility (the ability for an agent to move from place to place), persistence (the degree to which agents retain knowledge and state over periods of time), personality/sociability (the degree to which agents exhibit a pleasant style – this also relates to customization, perhaps by learning) If we map this characterization to our definition of (“weak”) agents, we see that that the following axes are relevant for us: autonomy, collaboration, persistence, and, to a certain extent, adaptability. The Foundation for Intelligent and Physical Agents (FIPA) is one of the standards bodies working towards developing standards for agent modeling and interaction (see http://www.fipa.org/). FIPA has developed a reference model, consisting of the following components: • Agent Management System (AMS) controls creation, deletion, suspension, resumption, authentication and migration of agents. Also provides local “white pages” service (roaming and locating) of agents • Agent Communication Channel (ACC) routes messages between local and remote FIPA agents, realizing messages using FIPA’s Agent Communication Language (ACL). • Directory Facilitator (DF) provides “Yellow Pages” service for FIPA agents; they register some agent capabilities so an appropriate task-specific agent to handle the task can be found. • Agent Platform (AP) provides communication and naming infrastructure, using the Internal Platform Message Transport. Interesting linkages between workflow and agents have been described in (Griss, 2000): • Agents can collaborate to perform a workflow, e.g., telecom provisioning, service provisioning, scheduling, ... • Agents can be used to make workflow more intelligent, e.g., by adding negotiation, reasoning or decision points • Workflow can be used to choreograph a set of agents, e.g., application management, ... Narendra/Modeling and Simulating Multi-Agent Systems 2003 — Ninth Americas Conference on Information Systems 1845 • Workflow can be used to coordinate interaction between people and agents, having agents delegate to people or other agents, e.g., telecom management system alerting a human operator, or assigning a repair or provisioning engineer We recognize that the first two linkages represent agent-enhanced workflow (i.e., using agents to enhance workflow systems also known as “macro workflow”) and the last two represent agent conversations (i.e., using “choreographing workflow processes” to model agent interactions and conversations in multi-agent systems also known as “micro workflow”). Micro workflows can be modeled as single tasks within macro workflows. We have achieved some preliminary results in expanding on this idea in (Narendra 2002, Narendra 2003). Part I: Lifecycle-Based Multi-Agent Simulation Introduction to Software Process Modeling From the section above, we see that multi-agent systems can be modeled as agent-oriented workflow systems, using macroand micro-workflow concepts. This naturally raises the question of whether workflow and process modeling techniques can be used for modeling and simulating their behavior. To that end, we propose using Software Process Modeling (SPM) techniques. There are several reasons for this: firstly, both software process systems on the one hand, and multi-agent systems on the other, use similar process-based ideas; secondly, both the techniques are lifecycle-based, i.e., a definite start-execute-end cycle can be noticed; thirdly, SPM is a well-researched area with significant technical results which can be leveraged for modeling and simulating multi-agent systems. Interest in the SPM area has grown ever since the publication of Leon Osterweil’s landmark paper titled “Software Processes are Software Too” (Osterweil, 1987). Osterweil’s basic idea was that software processes are also software artifacts, and can be modeled like any other artifact, in computer-representable form. This idea has enabled SPM to become a fertile area for research. However, SPM has not really had much success within the software industry itself, largely due to the dynamic and semi-chaotic nature of software development. There was also a perception among most software project managers that the value addition from SPM would not be sufficient to justify investments in SPM research or tools. From the point of view of multi-agent system simulation, however, we can leverage off the extensive research work in SPM for modeling and simulating agent interactions as processes and workflows, especially since managing multi-agent systems should be a better value proposition for e-commerce system managers. The ATRIUM Approach to Software Process Modeling and Enactment One of the most significant research contributions to SPM to date, has been the ATRIUM project (http://www.usc.edu/ ept/ATRIUM/). The key idea behind ATRIUM, is that SPM has to follow a lifecycle-based approach (Scacchi and Mi, 1997). In other words, SPM should be done as per the steps in the lifecycle listed in the Table below. The Table also shows how each of the process steps can be modeled and simulated in a multi-agent simulation. Hence it describes how SPM can be effectively used for modeling and simulating multi-agent systems. It also shows that a life-cycle based approach is needed for effectively modeling and simulating multi-agent systems. Current Approaches to Multi-Agent System Simulation Although the field of multi-agent system simulation is vast and growing (see, for example, http://jasss.soc.surrey.ac.uk/ JASSS.html), we feel that there are two significant research contributions that are most relevant for our purposes. Intelligent Agent and Multi-Agent Systems 1846 2003 — Ninth Americas Conference on Information Systems Table 1. ATRIUM Lifecycle Process Step in Lifecycle Description Mapping to Multi-Agent Simulation Metamodeling Define process models and process instances from the models As in (Griss, 2000), defining ontologies for agent interactions and also workflow and multi-agent conversation models Modeling Capturing and representing process instances formally and representing them in computerunderstandable form Capturing and representing the choreographing workflow models/instances and agent conversations, in computerunderstandable form Analysis Evaluating static and dynamic properties of a process model, such as consistency, completeness, internal correctness, traceability as well as other semantic checks Defining and modeling static and dynamic (including semantic) properties of agent interactions/conversations Simulation Symbolically executing process models in order to observe their behavior Symbolically executing the workflow models and agent conversations in order to observe their behavior Redesign Redesigning process models and process instances based on results of simulation Redesigning workflows and agent conversations based on results of simulation Visualization Graphical visualizations of process models and instances Graphical visualizations of workflow execution and agent conversations Prototyping, walkthrough and performance support Incremental enactment of process instances in order to perform a thorough evaluation Incremental enactment of workflows and agent conversations for evaluation purposes Administration User monitoring of the simulation system As per (Griss and Letsinger, 2000), user monitoring of the simulation system Integration Simulating the integration of external systems and repositories Simulation of external tools/services into the system, and how they would integrate with each other Monitoring, recording and auditing Collecting and measuring process enactment data needed to improve subsequent process enactment iterations Collecting and measuring execution data History capture and replay Recording the enactment history and graphically simulating the re-enactment of a process, in order to analyze the enacted process in greater detail Recording the enactment history of the transactions, in order to analyze them either wholly or in part Articulation Diagnosing, repairing and rescheduling actual or simulated process enactments that have unexpectedly broken down Diagnosing, repairing and rescheduling transactions that have broken down Evolution Incrementally adapting or reengineering process models to more effectively meet emerging user requirements Using performance data to incrementally and iteratively enhance and restructure workflow definitions and agent conversation models Process asset management Organizing and managing the collection of meta-models, models and instances of processes, products, tools, documents and organizational structures/roles for engineering, redesign and reuse activities Organizing and managing the collection of workflow definitions, agent conversations, and instances of executions. Narendra/Modeling and Simulating Multi-Agent Systems 2003 — Ninth Americas Conference on Information Systems 1847 TAEMS from University of Massachusetts, Amherst In this approach (Horling, et. al., 2000), the behavior of each agent is controlled by a simple simulation script. Each script is composed of three parts: • The script this checks the Assertions and realizes the Reactions when the Assertions hold • One or more Assertions these are basically conditions that must hold if the Reactions have to be executed • One or more Reactions these are executed provided the Assertions hold An example script is: Script AndScript Assertions Time > 5 ExecuteEventActiveMethod-4 Reactions QuitSim This is an AND script, which means that all the Assertions must be ANDed in other words, all Assertions must be true for the Reactions to be executed. Hence in the above example, if time is greater than 5 and if the currently active method is method-4, then the QuitSim reaction will be executed. In other words, the simulation will end. Similarly, OR scripts and EXPRESSION scripts can be defined. In this manner, a multi-agent system can be simulated by defining such agent behaviors in a modular and extensible way. When the agents are put together, it is possible to synthesize highly interesting behaviors for the multi-agent system from the simple behaviors of an agent, where each behavior is modeled as a simulation script like the one described above. SWARM from Santa Fe Institute The SWARM (Minar, et. al., 2002) approach provides a different way of simulating multi-agent systems. Here, the basic unit of simulation is the swarm, a collection of agents executing a schedule of actions. SWARM supports hierarchical modeling approaches whereby agents can be composed of swarms of other agents in nested structures. However, SWARM does not include the notion of lifecycle-based simulation of the workflow processes executed by agents. Our Lifecycle-Based Simulation Approach Briefly, our proposed approach for modeling and simulating multi-agent systems is as follows: • Hierarchical Modeling: Workflows can be represented hierarchically see the subsection below as instantiations of a particular workflow definition. • Simulation Scripts: The simulation script idea from TAEMS can be used to define rules for the execution of each activity in the workflows and agent conversations. • Goals and Performance Measures: We can define goals for the multi-agent system that we are simulating. Based on these goals, we can derive performance metrics that tell us the extent to which the goals are being met. • Life-Cycle Based Modeling: The life-cycle approach from ATRIUM can be used to model and create the workflows and agent conversations. This can then be viewed at a lower level of abstraction using the Modeling and Visualization features described in earlier. Intelligent Agent and Multi-Agent Systems 1848 2003 — Ninth Americas Conference on Information Systems Buying Transaction (decomposed into) Customer Request Portal Searches Customer selection Delivery Process Buying Transaction (specialized to)