An Alternative Approach To Building Agent Itineraries

Transcription

1 An Alternative Approach To Building Agent Itineraries Russell P. Lentini, Goutham P. Rao, Jon N. Thies Programmers use commercially available agent systems, such as Voyager and Concordia, to tailor specific agent applications. The reusability of these architectures comes from the generic nature in which a programmer can define or describe an agent. These architectures differ in how they allow a user to create and program an agent. We describe how easy it is to build agent architectures by using a few simple concepts. Our goal is to enhance agent architectures by concentrating on a critical data structure called the itinerary. We claim that a flexible, generic, itinerary data structure allows greater expressive power to define application-specific agents. Looking at Agents and Itineraries The concept of itineraries is popular among many successful agent architectures. Agent architectures like IBM-Aglets, Voyager, and Oddessey use this approach. These architectures describe an itinerary as an enumeration or a list of tasks that an agent performs. We take a different approach and describe an itinerary as a meta-program: a way of programming an agent and, consequently, its goal. Overviewing a Finite State Itinerary Our concept of an agent itinerary borrows ideas from the Finite State machineña fundamental computing model. Theoretically, a Finite State machine attempts to capture the general nature of computation performed by a digital computer. Conceptually, the machine has a finite set of states, finite alphabet, and finite set of instructions. Visualize it as a simplified modern computer. It has storage that remembers its current state, and it is capable of reading input and computing the following two functions: Next State Function, which determines the next state based on current state, input symbol and simple set of instructions to map input signals, and state pairs to a new state. Output Function, which determines the machineõs output alphabet for a state. Formally, a Finite State machine is a sextuple (Fig. 1): M = [K,, O, δ s, δ o, s] Where: K is a finite set of states in which the machine can reside. is a finite set of input symbols. O is a finite set of output symbols. s is the initial state. Figure 1. The Finite State machine computes the operating program symbol based on the input symbol being scanned and the current state. The next state function, the transition function, δ s : K K is the program to the Finite State machine. It specifies for each combination of current state s K and current symbol; i, a new state; and s K: δ s (s, i) = s Finally, δ o : K O, the output function, specifies the output symbol for each state. A configuration of a Finite State machine is an instantaneous description of the machine in its computation path. A configuration specifies the current state, current input symbol the machine is scanning, and the output symbol. See references 1 and 2 for detailed information. How does a Finite State machine apply to agent itineraries? Programmers can use the machine to simulate certain computational procedures. It is a good tool to describe the general control of an algorithm responding to input. The implicitly generic nature of the transition function provides much of this power. At the same time, we describe an agentõs itinerary as a meta-language, as a way of programming an agent.

2 Meta-language is a set of commands to control an agent by specifying tasks to be performed under certain conditions. Building Agent Itineraries We start by borrowing concepts of a Finite State machine with the expectation that our meta-language has the flexibility and expressive power to describe complicated itineraries. Formally, we define a Finite State itinerary as a quadruple: I=[K,, δ, c] Where: K is a set of states in which an agent resides. The state describes the task or program that the agent executes. is a set of conditions that triggers an agent act, much like a Finite State machineõs computation path, depending on the input alphabet. The result of the evaluation of a condition occurring in real-time causes an agent to enter a state, executing the program represented by that state. c is the initial configuration of the Finite State itinerary, where a configuration is a state-condition pair (k K, σ ). In other words, a configuration is the current state of the agent and the most recent condition evaluated by the Finite State itinerary. Configurations arising during execution of the itinerary are generated in real-time. This allows the agent to react to real-time situations. δ, the transition function, is the meta-program for the agentõs itinerary, describing the transition from current to next configuration. This function is a way to program an agent to execute certain programs (specified by a state) under certain conditions. Subsequent configurations are obtained by examining the current configurationõs state and by evaluating its corresponding condition at run time. This is the fundamental difference between the Finite-State-itinerary approach and that taken by existing agent systems that use the itinerary concept. The Finite State itinerary is a data structure capable of storing a set of instructions (the transition function) that describe to the agent how to move from one configuration to another. The data structure is similar to a Finite State machine (Fig. 2). Figure 2. The program to be executed depends on the current configuration and the current real-time conditions. Any particular instance of an agent will define the following to its Finite State itinerary: The meta-program, or transition function, that will navigate the agent through various configurations. The initial configuration. The initial state of the initial configuration is spurious and not the result of any condition. The Finite State itinerary starts with the initial configuration and evaluates the initial condition specification. Evaluating a condition specification depends on real-time conditions existing around the agent (analogous to input symbols to a finite state machine). The result of the evaluation indicates current conditions. Once current conditions have been evaluated, the Finite State itinerary invokes the transition function to retrieve the next configuration in which to move. Depending on current conditions and state of the agent, the transition function returns a new state-condition specification pair. The new state configuration indicates the new state for the agent and the Finite State itinerary executes the program associated with this state. The Finite State itinerary again evaluates the condition specification of the new configuration and so continues to execute the meta-program of the agent until it reaches a final (halting) configuration. Building an Agent Framework From a Layered Architecture The following layered architecture implements an agent system (Fig. 3). Figure 3. Take a layered approach when building agent architectures.

3 At the very core is the Finite State itinerary, and functionality is added in layers. The agent layer provides an interface around the underlying system to the agent applications. A good design for the agent layer shields the application programmer from the intricacies of mobility and state transitions. Using Java to Implement the Architecture Refer to listings 1 through 6 (end of article). The listings represent the Java package finitestateitinerary. The package defines the following six components that comprise the Finite State itinerary block: The State Component: Refer to listing 1. This component generically represents the program that the itinerary executes when it reaches this state. This component is a Java abstract class; its functionality is defined in the run() method; and it is application dependent. This is consistent with the java.lan.runnable interface, which allows the program to run as a thread. It also declares states INIT and HALT, which are standard to any agent meta-program. The Condition Component: This component generically represents a condition that the agent application is configured to encounter. Its implementation is application dependent. The evaluate() method is responsible for evaluating run-time conditions and for optionally storing the current condition in the result field of this class. Listing 2 shows the Java abstract class for the condition object. In listing 7, we define a mobility condition in a separate mobile package. This is the first building block of agent mobility, and it is a good example of a condition object. The purpose of the condition is to evaluate if the agent is currently on the desired machine and to store the result of the evaluation in the result field (as java.lang.boolean). Listing 8 defines a migrate state class. The run() implementation of this class migrates the Finite State itinerary to the desired machine. The combined effect of the mobility condition and the migrate state causes the state object to run at a specified machine when the mobility condition is associated with that state object. Note that the migrate state class actually migrates the entire Finite State itinerary to the destination machine. This gives it the mobile-agent characteristic. Migration requires network communication with a machine, and this requires a daemon process at the receiving host. We defined a communication link object (listing 9). This class defines a startservice() method, which creates a server socket that is monitored for incoming connection requests. For brevity, we omitted the socket code. The methodõs implementation would receive an object using java.io ObjectInputStream. readobject(), which would read a Finite State itinerary class from another machine and then proceed to execute the Finite State itinerary from its current configuration (Java object serialization maintains state of an object). The migrate() method of this class contains code to connect with the startservice() method on another machine and then transmits a Finite State itinerary class using java.io.object OutputStream.writeObject(). See reference 9 for detailed information on object-serialization. Configuration Component: This component is a place-holder for the state and condition objects and is represented by listing 3. Transition Function Component: This component generically represents the meta-program. The actual implementation may choose a number of ways to specify a transition. This component need only return the next configuration, given the current configuration of the Finite State itinerary. The nextconfiguration() method, defined in the Transition Function interface of listing 4, does just this. This method is passed to the current configuration and is required to return the next configuration. The details of the implementation for computing the next configuration are left to the programmer. In listing 10, we define a class Simple Transition Function, which implements the interface finitestateitinerary.transition Function in a separate extensions package.

4 The implementation stores mapping that uses a java.util. Hashtable class. Refer to listing 11, where we extend the Configuration class to include a unique configuration identifier parameter. We need this identifier because we use the same State and Condition class pairs in different configurations; we need a way to distinguish among them. Our implementation of the SimpleTransitionFunction creates a unique configuration key from the current configuration identifier and the results of the current condition. This function, then, uses this key as a Hashtable key to retrieve subsequent configurations. Finite State Itinerary Component: This is the actual data structure that executes the itinerary; see listing 5 for details. During construction, it requires a transition function component and an initial configuration. The run() follows a simple logic: 1. Instruct the current configurationõs condition object to evaluate current conditions [go to step 2]. 2. Retrieve the next configuration from the transition function. Execute the program associated with the state object of this new configuration [go to step 3]. 3. Set the current configuration to be equal to the next configuration returned by the transition function [go to step 1]. Halt Component: At any point during the execution of the itinerary, a finitestateitinerary. Halt (listing 6) may be thrown, causing the itinerary to stop execution. Compare step 1 with the MobileCondition object that we defined. The evaluate() method sets its result field to false when invoked at a machine that is not the destination machine. This causes nextconfiguration() to return a configuration containing the migrate state, which causes the itinerary to be transmitted to the correct machine, where it will resume execution from its current configuration. This ensures that all states execute at the correct destination machines. The current configuration is automatically maintained because we use Java Object Serialization in CommunicationLink. Agent Component: We did not list the agent component because it is fairly straightforward to visualize an agent wrapper around the finitestateitinerary package. The finitestateitinerary.agent package would at the very least contain an agent class that encapsulates the Finite State itinerary, mobility conditions, and a custom transition function. Such a package corresponds with the notional concept of the agent paradigm, while providing a uniform and consistent interface into the underlying packages. The example we present in the next paragraph is simple and does not require this special agent class; however, building such a wrapper is essential to a complete mobile agent package. Illustrating the Finite State Itinerary To illustrate the Finite State itinerary, we show an example meta-program (listing 12). The program defines the initial configuration and the transition function necessary to implement the flow chart of the agent in Fig. 4. Figure 4. The action taken by the agent corresponds to this figure. With the power of the Finite State Itinerary, we can construct contingency plans at each step along the way. We see in Fig. 4 that the initial condition requires an itinerary to execute on ENIAC if the itinerary is to continue execution. If the itinerary is at another machine, then it migrates to ENIAC to meet the mobility condition. On ENIAC, the itinerary performs a database query. If the query is successful, then it migrates to machine HOME to report ÒSuccessful.Ó If the query is unsuccessful, then it migrates to machine HOME to report ÒFailed.Ó This meta-program has a direct mapping to the finite state automaton shown in Fig. 5. Figure 5. This finite state automaton corresponds to the meta-program of listing 12.

5 Although the program exhibits a very simple task list with simple contingencies, arbitrarily large metaprograms could be built in this fashion to map directly to their own finite state automaton. Concluding Remarks The goal of this article was to describe a new itinerary for agent-based applications. We described the itinerary as a meta-language and we defined a simple data structure to interpret the agentsõ itinerary program in terms of a transition function. An important detail left unmentioned in our example is that the communication link service (startservice()) must have already been started on the machines that the agent will visit. An enhancement would add the capability of the transition function to return more than one configuration on a call to the nextconfiguration() method. This would require a change in the run() method of the Finite State itinerary class to handle an enumeration of configurations to be returned from the nextconfiguration() method. This change represents the spawning of multiple Finite State itinerary evaluations for a given configuration, and it allows states to execute in parallel, a powerful addition to the implementation shown. In our implementation and example, we used only one condition object per configuration. However, more than one condition object could be applied to a configuration.

6 // Listing 1 FILE Condition.java * The Turing Itinerary calls upon this class. On reaching a * particular configuration, the Turing Itinerary will execute the code * in the associated Condition so that the Condition is satisfied. public abstract class Condition { /* This will hold the value of the result of evaluating this condition public Object result = null; * This method causes an evaluation of the current conditions. The * result of the evaluation is critical in selecting the current state * from the transition function. It is similar to a finite state * machine reading in the current input symbol. It returns true if * the finite state itinerary is to continue running the meta-program * or false if a final or unsatisfiable condition has been reached. public abstract void evaluate() throws Halt; // Listing 2 FILE State.java * This class is an encapsulation of the program that must be run by * the Turing Itinerary when it is in a particular configuration and the * configuration's condition has been satisfied. The entry point is the * run method. The application may chose to run as a thread. public abstract class State { /* INIT state is the initial state representation of the finite * state machine. public static final State INIT = new State() { public void run() { ; /* HALT state is the final state representation of the finite * state machine public static final State HALT = new State() { public void run() throws Halt { throw new Halt(); ; /* Applications must implement this method for functionality public abstract void run() throws Halt; // Listing 3 FILE Configuration.java * This class defines the state and condition objects of any particular * configuration of the machine. public class Configuration { public State state; public Condition condition;

7 // Listing 4 FILE TransitionFunction.java * The application must implement the TransitionFunction class to return * the next configuration. public interface TransitionFunction { public Configuration nextconfiguration(configuration configuration); // Listing 5 FILE FiniteStateItinerary.java * The run method of this class actually starts running the meta-program. * It begins with the initial configuration, calls the evaluate method, * and depending on the result, either continues execution of the * meta-program or terminates. The initial state is a spurious state * and is never executed by the itinerary. public class FiniteStateItinerary implements Serializable { public FiniteStateItinerary(TransitionFunction transitionfunction, Configuration configuration) { this.transitionfunction = transitionfunction; this.configuration = configuration; public void run() { try { /* Loop while the current condition specifies that the itinerary * should continue evaluation. while (true) { if (configuration.condition!= null) { configuration.condition.evaluate(); /* Get the next configuration and hence the corresponding * state to move into. configuration = transitionfunction. nextconfiguration(configuration); /* Run the program associated with the state object. configuration.state.run(); catch (Halt halt) { /* At this point, either final condition or an unsatisfiable * condition has been encountered, or the machine was halted. // Listing 6 FILE Halt.java public class Halt extends Throwable {

8 // Listing 7 FILE finitestateitinerary/mobility/mobilecondition.java package finitestateitinerary.mobility; * This implementation of the Condition object provides the mobile nature * to agent applications. When executed by the Finite State itinerary, this * condition compares the machine that it is executing on to the required machine. * If they are the same, it stores a TRUE in the result field, otherwise it stores * a FALSE. The meta-program uses this result to decide if a migration is required. public class MobileCondition extends Condition implements Serializable { public MobileCondition(InetAddress destination, FiniteStateItinerary itinerary) { this.destination = destination; public void evaluate() { if (InetAddress.getLocalHost().equals(destination)) { result = new Boolean(true); else { result = new Boolean(false); // Listing 8 FILE finitestateitinerary/mobility/migratetask.java package finitestateitinerary.mobility; * This state causes the entire finite state itinerary to be sent to the * destination machine via the CommunicationLink, where the finite state * itinerary will resume execution. This state then halts the execution of * the itinerary on the current machine by halting the current thread. public class MigrateState extends State { public MigrateState(InetAddress destination, FiniteStateItinerary fsitinerary) { this.destination = destination; this.fsitinerary = fsitinerary; * This run method is implemented to migrate the finitestateitinerary * that owns this state, to a new machine public void run() throws Halt { /* Migrate this instance of finitestateitinerary. CommunicationLink.migrate(destination, fsitinerary); /* Stop the local execution of this instance of finitestateitinerary * since it is now running on a new machine throw new Halt(); // Listing 9 FILE finitestateitinerary/mobility/communicationlink.java package finitestateitinerary.mobility; * For a machine to be able to write a serialized object over a socket to * another machine, we need a daemon process running at that (receiving) * machine. This class provides the essentials to start the daemon process * to receive Finite State itineraries and execute them from whatever state they * are currently in. It also provides the service to send itineraries to a * receiving process. public class CommunicationLink { public static void startservice() { /* communication details to create a server socket wait for * connection requests. For every request, launch a thread that * reads the incoming FiniteStateItinerary object and runs it. public static void migrate(inetaddress destination, FiniteStateItinerary fsitinerary) { /* Communication details for 'writing' an itinerary to a machine. * This code requires making a socket connection with the destination * daemon process, started by the startservice method on destination

9 // Listing 10 FILE finitestateitinerary/extensions/simpletransitionfunction.java package finitestateitinerary.extensions; * This class implements a very simple transition function. The user of this * class explicitly specifies the next configuration for each configuration * object. The mappings are stored in a hashtable. When the finite state * itinerary requests the next transition, it computes a Hashtable key by * using the current configurationõs unique identifier (SimpleConfiguration.uniqueID) * and the current condition's result (Condition.result). This class then computes * the next configuration by keying into a hashtable using this newly computed key. public class SimpleTransitionFunction implements TransitionFunction { public void addtransition(configuration from, Configuration to) { transitionmap.put(from, to); public Configuration nextconfiguration(configuration currentconfiguration) { String key = ((SimpleConfiguration)currentConfiguration).uniqueID + "_" + ((currentconfiguration.condition == null)? null : currentconfiguration.condition.result); return (Configuration) transitionmap.get(key); // Listing 11 FILE finitestateitinerary/extensions/simpleconfiguration.java package finitestateitinerary.extensions; * An extension to the Configuration class is needed because we will be * using the same states in many different configurations in our example * application. We will need to be able to distinguish between configurations * that use the same state and condition objects. This can be done by * introducing a unique identifier in every configuration class public class SimpleConfiguration extends Configuration { /* A unique ID for every state is required so that two configurations * that use the same state class do not interfere in the * TransitionFunction class public Object uniqueid = null; public SimpleConfiguration(String uniqueid, State state, Condition condition) { this.uniqueid = uniqueid; this.state = state; this.condition = condition;

10 // Listing 12 FILE meta-program.pgm // This is the finite state itinerary meta program for performing a persistent // database query on a machine named ENIAC and reporting the results // to a machine named HOME. The initial configuration is listed first, // followed by the transition function. // It is assumed that this file will be processed by the application to // produce the corresponding itinerary using the SimpleTransitionFunction. // The following meta-program uses a notation where the left hand side // of a rule indicates the current configuration and the right hand side // indicates the parameters to the constructor of the SimpleConfiguration // class. In this way, this meta-program describes the transition function // to create to the application that is parsing this file. // INIT initial_configuration = ("INIT", finitestateitinerary.init(), finitestateitinerary.mobility.mobilitycondition(eniac)) transition_function = { // We are already on ENIAC from the initial state, so move to the // query configuration. ("INIT_TRUE") => ("CONFIG_0", application.query(), application.querycondition()) // We are on the wrong machine, so migrate to ENIAC. ("INIT_FALSE") => ("CONFIG_1", finitestateitinerary.mobility.migratestate(eniac), finitestateitinerary.mobility.mobilitycondition(eniac)) // If we were able to migrate to ENIAC, perform the query ("CONFIG_1_TRUE") => ("CONFIG_0", application.query(), application.querycondition()) // Try to migrate to ENIAC persistently ("CONFIG_1_FALSE") => ("CONFIG_1", finitestateitinerary.mobility.migratestate(eniac), finitestateitinerary.mobility.mobilitycondition(eniac)) // If the results of the query are ok, then migrate to HOME to // report a successful operation. ("CONFIG_0_TRUE") => ("CONFIG_2", finitestateitinerary.mobility.migratestate(home), finitestateitinerary.mobility.mobilitycondition(home)) // If the results of the query are not ok, then migrate to HOME to // report a failed operation. ("CONFIG_0_FALSE") => ("CONFIG_3", finitestateitinerary.mobility.migratestate(home), finitestateitinerary.mobility.mobilitycondition(home)) // If we are at HOME from CONFIG_2, report a successful operation ("CONFIG_2_TRUE") => ("CONFIG_4", application.reportresult("success"), null) // Try to migrate to HOME persistently from CONFIG_2 ("CONFIG_2_FALSE" => ("CONFIG_2", finitestateitinerary.mobility.migratestate(home), finitestateitinerary.mobility.mobilitycondition(home)) // If we are at HOME from CONFIG_3, report a successful operation ("CONFIG_3_TRUE") => ("CONFIG_5", application.reportresult("failed"), null) // Try to migrate to HOME persistently from CONFIG_3 ("CONFIG_3_FALSE" => ("CONFIG_3", finitestateitinerary.mobility.migratestate(home), finitestateitinerary.mobility.mobilitycondition(home)) // HALT ("CONFIG_4_null") // HALT ("CONFIG_5_null") => ("HALT", finitestateitinerary.halt(), null) => ("HALT", finitestateitinerary.halt(), null)

11 References 1. Papadimitrou, Christos M., Computational Complexity, ISBN , Gersting, Judith L,. Mathematical Structures For Computer Science, ISBN , Gamma, E., Helm, R., Johnson, R., and Vlissides, J Design Patterns: Elements of Reusable Object-Oriented Software Reading, Mass.: Addison Wesley Longman, Inc. 4. Mitsubishi Electric Information Technology Center America, Horizon Systems Laboratory. Concordia White Paper IBM Tokyo Research Lab. Aglets API ObjectSpace, Inc., Voyager White Paper Lentini, R., Rao, G., Thies, J., Kay, J., EMAA: An Extendable Mobile Agent Architecture. Fifteenth National Conference on Artificial Intelligence (AAAI-98) Workshop on Software Tools for Developing Agents, Technical Report WS July 27, Madison, WI. 8. Bigus, J. Constructing Intelligent Agents with Java. Wiley Computer Publishing Java Object Serialization Specification