Intelligent agents

1. Intelligent agents .

2. Definition of intelligent agent • “Intelligent agents are software entities that carry out some set of operations on behalf of a user or another program, with some degree of independence or autonomy and in so doing, employ some knowledge or representation of the user’s goals or desires.” (“The IBM Agent”)

3. . • An Intelligent agent is software that assists people and acts on their behalf. • Intelligent agents work by allowing people to delegate work that they could have done, to the agent software. • Agents can, just as assistants can, automate repetitive tasks, remember things you forgot, intelligently • summarize complex data, learn from you, and even make recommendations to you.

4. Why Intelligent Agents? Information Overload • Data doubles annually (in large enterprises (1998)) • Can analyze only about 5% • Most efforts: discover patterns, not meaning, not what to do • Reduces decision making capabilities by 50% • Much caused by the Internet/Web • How to filter data • How to identify relevant sources of data • Intelligent agents can assist searching • Save time: agents decide what is relevant to the user

5. Intelligent agent as event handler • Yet another typical problem is that events happen and no one takes action. • These events could be real world events like competitive announcements or emergencies, or they could be computer events like a • new version of a design document becoming ready. • Intelligent agents can help solve this problem by automating the handling of things you don't want to take care of yourself.

6. . Intelligent agent and Customer Help Desk • In a business who's job it is to field calls from customers and quickly find the answer to their problems, finding the right information at the right time is the name of the game! • Years ago, such calls were handled manually, with trained professionals consulting hardcopy manuals, custom online databases, and sometimes having to consult by telephone with other help desk personnel. • Computerization has improved things: many hardcopy manuals have been replaced with searchable CD-ROM collections, and some companies offer searches over the Internet. • However, applying intelligent agent technology to this problem helps even more. Imagine a help desk • where an intelligent agent takes the problem as described by the customer, automatically searches the relevant databases (whether local, CD-ROM, or via the Internet), then presents a consolidated answer with the most likely information first! • Such a solution is being built today. This is a good example of using intelligent agents to find and filter information.

7. How do you design an intelligent agent? • Definition: An intelligent agent perceives its environment via sensors and acts rationally upon that environment with its effectors. • A discrete agent receives percepts one at a time, and maps this percept sequence to a sequence of discrete actions. • Properties • Autonomous • Reactive to the environment • Pro-active (goal-directed) • Interacts with other agents via the environment

8. What do you mean, sensors/percepts and effectors/actions? • Humans • Sensors: Eyes (vision), ears (hearing), skin (touch), tongue (gustation), nose (olfaction), neuromuscular system (proprioception) • Percepts: • At the lowest level – electrical signals from these sensors • After preprocessing – objects in the visual field (location, textures, colors, …), auditory streams (pitch, loudness, direction), … • Effectors: limbs, digits, eyes, tongue, … • Actions: lift a finger, turn left, walk, run, carry an object, … • The Point: percepts and actions need to be carefully defined, possibly at different levels of abstraction

9. A more specific example: Automated taxi driving system • Percepts: Video, sonar, speedometer, odometer, engine sensors, keyboard input, microphone, GPS, … • Actions: Steer, accelerate, brake, horn, speak/display, … • Goals: Maintain safety, reach destination, maximize profits (fuel, tire wear), obey laws, provide passenger comfort, … • Environment: U.S. urban streets, freeways, traffic, pedestrians, weather, customers, … • Different aspects of driving may require different types of agent programs!

10. Autonomy • A system is autonomous to the extent that its own behavior is determined by its own experience. • Therefore, a system is not autonomous if it is guided by its designer according to a priori decisions. • To survive, agents must have: • Enough built-in knowledge to survive. • The ability to learn.

11. All agents are also goal-driven. • Agents have a purpose, and act in accordance with that purpose. • There are several ways of making goals known to an agent, however: • A rudimentary agent could be driven by a script, which pre-defines its actions. • The script would then define the agent's goals. • An agent could also be a program, as long as the program is driven by goals, and shares the other characteristics of agents. • An agent could also be driven by rules, which is a more general way of defining the agent's goals. • There are even more sophisticated ways of embedding agent goals, and in some cases, the agent may even have the flexibility to change its own goals over time. All agents are also reactive. • That is, an agent senses changes in its environment and responds in a timely fashion to these changes. • This characteristic of agents is also at the core of delegation and automation. • Just as you tell your assistant, "When x happens, do y" an agent is always waiting for x to happen! • Finally, in order to carry out the wishes of the user, all agents continue to run, even when the user is gone. • This implies than an agent may run on a server, but in fact some agents run on user systems. • The four characteristics above are always true of intelligent agents.

14. . Major Categories of Agents used in the Internetworking Systems / Applications Majority of Agents can be classified as one of the following principal categories: • Gopher Agents • Predictive Agents • Service Agents • Leader / Pro-active Agents • Adaptive Agents

15. . Examples of Intelligent Agents • Simple Gopher Agents: An intelligent interface agent that acts as appointment tracking and alerting system • Service Agents: Do specialized services • Webbots, Taskbots, Userbots, Schedulerbots etc. • Data Mining Agents and Intelligent Monitoring Agents are the examples of the Predictive and Proactive Agents

16. Attributes of an Intelligent Agent • Ability to act at its own • Capability to respond to a situation • Capability of taking Initiative • A subset of what is perceived as Human Intelligence • Goal Directed Behaviour • Network / Internetwork Mobility • A subset of what is perceived as Rationality • Selectivity and Interactivity • Fault-tolerance • Avoiding propagation of false data / information • Capability of avoiding conflicting goals of other Agents where possible

17. Intelligent agent architecture • Deliberative Architectures Agent architectures based on explicitly represented symbolic models and a well-defined course of action for each of the specified goals belong to this class. • Reactive Architectures Agent architectures not based on any explicit (primary) symbolic model and symbolic reasoning but having the capability of responding in an interactive environment belong to this class. • Hybrid Architectures These architectures inherit properties from both of the above referred classes of architecture.

18. Where do intelligent agents fit in internetworking world ? • Network / Internetwork Monitoring • Traffic Management • Security Management • Privacy Management • QoS Management • Failure Management • Response Customization • Pro-active Marketing • Access History based disaster avoidance

19. Software agents • As used here, a software agent is a program that can halt itself, ship itself to another computer on the network, and continue execution at the new computer. • An agent doesn't restart execution from the beginning at the new computer; it continues where it left off. • For example, imagine an agent that increments a counter starting with zero. • If that agent counts from zero to ten, then halts and ships itself to another computer, it will not start counting again at zero. It will continue counting starting with ten, because that was where it left off when it halted at its previous computer. • Agents are autonomous because they decide where they will go and what they will do. They control their lifetimes. They can receive requests from external sources, such as other agents, but each individual agent decides whether or not to comply with external requests. Also, agents can decide to perform actions, such as travel across a network to a new computer, independent of any external request

20. Mobile Agents “A mobile agent is a program that can migrate from machine to machine in a heterogeneous network. The program chooses when and where to migrate. It can suspend its execution at an arbitrary point, transport itself to another machine and resume execution.” Web crawlers might work like this (they don’t)

21. Old RPC-based client-server computing paradigm New mobile agent computing paradigm

22. Mobile Agent Environments A mobile agent environment is a software system which is distributed over a network of heterogeneous computers. Its primary task is to provide an environment in which mobile agents can execute. The mobile agent environment implements the majority of the models which appear in the mobile agent definition. It may also provide: support services which relate to the mobile agent environment itself, support services pertaining to the environments on which the mobile agent environment is built, services to support access to other mobile agent systems, and finally support for openness when accessing non-agent-based software environments.

23. A mobile agent is a software entity which exists in a software environment. It inherits some of the characteristics of an Agent (as defined above). A mobile agent must contain all of the following models: an agent model, a life-cycle model, a computational model, a security model, a communication model and a navigation model. Mobile Agents

24. Agent model What it does: autonomy, learning and co-operative characteristics of an agent. Additionally, it specifies the reactive and proactive nature of agents. Computational model The computational model defines how a mobile agent executes when it is in a ‘running’ state. The computation takes place in an environment and is facilitated by some form of processor. A processor could be the CPU of the a computer or a more abstract processor as can be found in the Java virtual machine.

25. This model defines the different execution states of a mobile agent and the events that cause the movement from one state to another. Life-cycle model

26. Security model Mobile agent security can be split into two broad areas: Protection of hosts from malicious agents Leakage: acquisition of data by an unauthorised party. Tampering: alteration of data by an unauthorised party. Resource stealing: use of facilities by an unauthorised party. Vandalism: malicious interference with a hosts data or facilities with no clear profit to the perpetrator. Protection of agents from malicious hosts Difficult to do anything about this

27. Communication model • Mobile agents would be little use if they were unable to communicate with other entities in a computing environment. These entities include users, other agents (static or mobile), the host mobile agent environment and other systems such as CORBA based distributed systems.

28. Navigation model This model concerns itself with all aspects of agent mobility from the discovery and resolution of destination hosts to the manner in which a mobile agent is transported. • Naming conventions for all entities in the mobile agent system (agents, hosts, services etc.). • Access to information regarding a remote mobile agent environment. • The ability to move a mobile agent into a ‘suspended’ life-cycle state ready for transportation to a remote host. • The ability to transport a mobile agent, which is in the ‘suspended’ state, to a remote mobile agent environment. • The ability to receive a suspended mobile agent from a remote host and reconstitute it in a new environment.

29. Aglets versus Applets • The Java aglet extends the model of network-mobile code made famous by Java applets. • Like an applet, the class files for an aglet can migrate across a network. But unlike applets, when an aglet migrates it also carries its state. An applet is code that can move across a network from a server to a client. An aglet is a running Java program (code and state) that can move from one host to another on a network. In addition, because an aglet carries its state wherever it goes, it can travel sequentially to many destinations on a network, including eventually returning back to its original host. • A Java aglet is similar to an applet in that it runs as a thread (or multiple threads) inside the context of a host Java application. To run applets, a Web browser fires off a Java application to host any applets it may encounter as the user browses from page to page. That application installs a security manager to enforce restrictions on the activities of any untrusted applets. To download an applet's class files, the application creates class loaders that know how to request class files from an HTTP server. • Likewise, an aglet requires a host Java application, an "aglet host," to be running on a computer before it can visit that computer. When aglets travel across a network, they migrate from one aglet host to another. Each aglet host installs a security manager to enforce restrictions on the activities of untrusted aglets. Hosts upload aglets through class loaders that know how to retrieve the class files and state of an aglet from a remote aglet host.

30. . • The aglet lifestyle An aglet can experience many events in its life. It can be: • Created: a brand new aglet is born -- its state is initialized, its main thread starts executingCloned: a twin aglet is born -- the current state of the original is duplicated in the cloneDispatched: an aglet travels to a new host -- the state goes with itRetracted: an aglet, previously dispatched, is brought back from a remote host -- its state comes back with itDeactivated: an aglet is put to sleep -- its state is stored on a disk somewhereActivated: a deactivated aglet is brought back to life -- its state is restored from diskDisposed of: an aglet dies -- its state is lost forever • Note that every activity besides creation and disposal involve either duplication, transmission across a network, or persistent storage of the aglet's state. Each of these activities uses the same process to get the state out of an aglet: serialization.

31. . • The process of writing an aglet is in many ways similar to the process of writing an applet. • To create an applet, you subclass class Applet. To initialize an applet, you override the init() method, the starting point for any applet. You can use init() to build the user interface of the applet. If you wish, you can fire off other threads from init(). If you do this, you also may override stop() and start() to stop and restart your threads when the browser leaves and returns to the Web page. If you don't create any threads in init(), your applet likely will get at least one thread just because class Applet descends from class Panel. The AWT user-interface library of which Panel is a part will provide whatever threads are needed to run the user interface you create in init(). • The aglet development and run-time environments provide a library of Java classes that support the creation and running of aglets. To create an aglet, you must subclass class Aglet, which includes several methods you can override to customize the behavior of your aglet. The aglet's counterpart to the init() method of applets is the onCreation() method. To initialize an aglet, you override onCreation(). The onCreation() method is invoked only once in an aglet's lifetime and should be used only for initialization.

32. . • The aglet also has a run() method, which represents the entry point for the aglet's main thread. This is similar to the main() method of a Java application, except that run() is invoked each time an aglet arrives at a new aglet host. • For example, if you designed a CatAglet that visits nine different aglet hosts looking for MouseAglets, onCreation() would be invoked only once, when the CatAglet was first instantiated at its first host.  • Once onCreation() completed, run() would be invoked. Each time the CatAglet arrived at a new host, a method called onArrival() would be invoked to perform any initialization. Once onArrival() completed, run() would be invoked to get the aglet started again at the new host. • Starting run() again each time an aglet is brought to life illustrates the inability of aglets to transmit the state of their execution stacks. For example, imagine a HealthyAglet whose run() method periodically invokes a method named walk(). If, as it is walking, the HealthyAglet is serialized and transmitted to another host, it wouldn't by default continue executing where it left off in walk(). It would start over again at the beginning of run(). Thus, when the aglet is informed that it is about to be serialized, it would need to record on the heap that it is walking -- perhaps in an instance variable of HealthyAglet. That instance variable would be serialized and would migrate with the aglet. When run() is invoked to start the aglet's new life, the run() method would check the instance variable, see it was walking beforehand, and call walk().

33. . • The callback model Before any major event in an aglet's life, a "callback" method is invoked to allow the aglet to prepare for (or refuse to partake in) the event. This is how an aglet learns that it is about to be serialized. For example, before an aglet is dispatched to a new location, the aglet's onDispatch() is invoked. This method indicates to an aglet that it is about to be sent to a new host, the URL of which is specified as a parameter to onDispatch(). In the body of onDispatch(), the aglet must decide whether or not to go. If the aglet decides it doesn't want to go, it throws an exception. If it decides to go, it must complete any unfinished business and prepare its state for serialization. When it returns from onDispatch(), its state will be serialized and all its threads terminated. The class files and serialized state will then be sent to the new host, where the aglet will be resurrected. • The method onDispatch() is a "callback" method because the aglet host invokes it some time after another method, dispatch(), is invoked. An aglet can invoke dispatch() on itself or on another aglet. This callback model for aglets is similar to that of windowing user interfaces. To repaint an AWT component, for example, you invoke the component's repaint() method. At some point later, the system calls back the component's update() method, which in turn calls paint().

34. . • Interaction between aglet and host An aglet interacts with its environment (its aglet host) through an AgletContext object. An aglet can obtain a handle to its context by invoking getAgletContext(), a method it inherits from base class Aglet. • The aglet context has methods such as createAglet() and retractAglet(), which allow an aglet to add new aglets (or get an old aglet back) to its local host.

35. . • Interaction between aglets • To interact with each other, aglets do not normally invoke each other's methods directly. Instead they go through AgletProxy objects, which serve as aglet representatives. For example, if a BossAglet wishes to make a request of an EmployeeAglet, the BossAglet obtains a handle to a proxy object that "represents" the EmployeeAglet. The BossAglet then makes a request by invoking a method in the EmployeeAglet's proxy, which in turn forwards the request to the actual EmployeeAglet. • The AgletProxy class contains methods that allow aglets to request other aglets to take actions, such as dispatch(), clone(), deactivate(), and dispose(). The aglet that has been requested to take an action can comply, refuse to comply, or decide to comply later.

36. . • Serializing the state... Aglet hosts use object serialization, available in JDK 1.1 or with the RMI (remote method invocation) add-on to JDK 1.0.2, to export the state of an aglet object to a stream of bytes. • . An object is serializable if it implements either the Serializable or the Externalizable interface. In a reverse process, the state of the aglet can be reconstructed from the stream of bytes. Serialization allows an image of the heap (the heap's state) to be exported to a byte stream (such as a file) and then reconstructed from that byte stream.

37. . • An aglet is a Java-based autonomous software agent. (For more information, see Bret Sommers's explanation of agents.) As used here, a software agent is a program that can halt itself, ship itself to another computer on the network, and continue execution at the new computer. The key feature of this kind of software agent is that both its code and state are mobile. • Aglets are autonomous because once you start them, they decide where they will go and what they will do. They can receive requests from external sources, but each individual aglet decides whether or not to comply with external requests. Also, aglets can decide to perform actions, such as travel across a network to a new computer, independent of any external request.

38. . • Data collection from many places • One of the main differences between mobile code, such as applets, and mobile agents is itinerary. Whereas mobile code usually travels just from point A to point B, mobile agents have an itinerary and can travel sequentially to many sites. • One natural application of mobile agents, therefore, is collecting information spread across many computers hooked to a network. • An example of this kind of application is a network backup tool that periodically must look at every disk attached to every computer hooked to a network. Here, a mobile agent could roam the network, collecting information about the backup status of each disk. It could then return to its point of origin and make a report.

39. . • Searching and filtering • Given the ever increasing amount of information available on the Internet and other networks, the activity of collecting information from a network often amounts to searching through vast amounts of data for a few relevant pieces of information. • Filtering out the irrelevant information can be a very time-consuming and frustrating process. • On behalf of a user, a mobile agent could visit many sites, search through the information available at each site, and build an index of links to pieces of information that match a search criterion. • Searching and filtering exhibits an attribute common to many potential applications of mobile agents: knowledge of user preferences. Although mobile agents do not have to be "representative" or "intelligent," they often are. Here, an agent is given knowledge of user preferences in terms of a search criterion and an itinerary, and sent out into the network on the user's behalf. • It sifts through huge amounts of data for those pieces of information of particular interest to the user. At some point, it returns to the user to report its findings.

40. . • Monitoring • Sometimes information is not spread out across space (on the disks of many different computers hooked to the same network), but across time. • New information constantly is being produced and published on the network. Agents can be sent out to wait for certain kinds of information to become available. • For example, an agent could go to a stock market host, wait for a certain stock to hit a certain price, then buy some of it on behalf of its user. Another example is personalized news gathering. An agent could monitor various sources of news for particular kinds of information of interest to its user, then report back when relevant information becomes available. • This kind of application highlights the asynchronous nature of mobile agents. If you send out an agent, you needn't sit and wait for the results of its information gathering. You can program an agent to wait as long as it takes for certain information to become available. Also, you needn't stay connected to the network until an agent returns. An agent can wait until you reconnect to the network before making its report to you.

41. . • Bartering • Electronic commerce is another good fit for mobile agent technology. A mobile agent could do your shopping for you, including making orders and potentially even paying. • For example, if you wanted to fly from Silicon Valley to an island in the South Pacific, an agent could visit databases of flight schedules and prices for various airlines, find the best price and time, make reservations for you, and pay with your credit card number. • Electronic commerce also can take place between agents. • For example, there could be an agent host dedicated to the buying and selling of automobiles. If you wanted to buy a car, you could give an agent knowledge of your preferences, including a price range and potentially a negotiation strategy. You would send your agent to the dedicated host, where it would mingle and haggle with agents seeking to sell a car. • If a potential match were found, your agent could report back to you, and you could contact each other in person to make the final arrangements. Alternatively, your agent potentially could consummate the deal on your behalf. If the opportunity is a good one, your agent may have only a few microseconds to act before someone else's agent buys the car.

42. Parallel processing • Given that mobile agents can move from node to node and can spawn subagents, one potential use of mobile agent technology is as a way to administer a parallel processing job. If a computation requires so much CPU time as to require breaking up across multiple processors, an infrastructure of mobile agent hosts could be an easy way to get the processes out there

43. One perspective is put forth by Harrison, Chess, and Kershenbaum in their IBM research paper titled "Mobile Agents: Are they a good idea?" (See Resources below.) Here is a short quote from their paper: • While none of the individual advantages of mobile agents...is overwhelmingly strong, we believe that the aggregate advantages of mobile agents is overwhelmingly strong, because: a. They can provide a pervasive, open, generalized framework for the development and personalization of network services. • b. While alternatives to mobile agents can be advanced for each of the individual advantages, there is no single alternative to all of the functionality supported by a mobile agent framework. • In other words, the point of mobile agents may not be any individual potential application, each of which could alternatively be implemented using a more traditional distributed processing scheme. Rather, the point may be that mobile agents have so many potential applications. They give you a single, flexible way to implement and reap the benefits of the traditional distributed processing, client/server, and mobile code models.