This month's Under the Hood is the second in a two-part series of articles about aglets, an innovation developed by IBM Japan. Last month I described the inner workings of aglets, this month I'll discuss the ways in which mobile agent technologies, such as aglets, might fit into the Java developer's toolbox.
Aglets: A refresher
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.
At heart, aglets are mobile
People use the term "software agent" to talk about more than just mobile agents. Two other meanings of the term are intelligent agents and representatives. Intelligent agents are endowed to some degree with artificial intelligence. They may be mobile as well as intelligent, but they don't have to be mobile. A representative is a piece of software that represents you, like an attorney or an assistant. Representatives stand in for you in your absence. Depending on your instructions to them, representatives can make decisions or even consummate deals on your behalf. Representative agents can be mobile or intelligent or both, but they don't have to be mobile.
Aglets can potentially be endowed with artificial intelligence or serve as representatives, but they need not be either. Fundamentally, they are mobile agents: Java programs that can halt execution, travel across the network (with both code and state in tact), and continue execution at another host.
If you build it, they will come: Using mobile agents
Once an infrastructure of mobile agent hosts is established, mobile agents undoubtedly will be built to populate the infrastructure. But what will those mobile agents do? What will justify building the infrastructure in the first place?
Imagine for a moment that a widespread infrastructure of mobile agent hosts has been established on a network near you. How might you use it?
There are many applications for which mobile agents are claimed to be well-suited. Most of these applications tend to involve searching for information on behalf of a user and possibly performing some kind of transaction when appropriate information is encountered.
Here is a list of some of the more commonly mentioned applications for mobile agents:
- 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.
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.
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.
Targeted information dissemination
Another potential use of mobile agents is to distribute interactive news or advertising to interested parties. Unfortunately, this means mobile agents, like e-mail, can be used for spam -- indiscriminate distribution of information, usually advertising. (There will likely be a market for agents that filter the spam out of incoming mobile agents.)
Besides searching databases and files, agents can gain information by interacting with other agents. If, for example, you want to schedule a meeting with several other people, you could send a mobile agent to interact with the representative agents of each of the people you want to invite to your meeting. The agents could negotiate and establish a meeting time.
In this case, each agent contains information about its user's schedule. To agree upon a meeting time, the agents exchange information.
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.
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.
One last example of a potential application for mobile agents is entertainment. In this scenario, agents represent game players. The agents compete with one another on behalf of the players. Each player would program an agent with a strategy, then send the agent to a game host. If the game host is executing on a computer in Las Vegas, then perhaps the agents could play for real money.
The security challenge
Although there is no shortage of potential applications for mobile agents, the technology raises a few concerns -- probably the biggest being security. With an established infrastructure of mobile agent hosts that give agents access to local resources, virus writers and other rogue programmers could have a lot of fun.
Although host security is a prime concern, it is likely a solvable problem. Using existing security mechanisms, such as those offered by Java, it should be possible to achieve acceptable levels of security to protect hosts from malicious agents.
Another side to mobile agent security, which may not be as straightforward to solve, is protecting agents from malicious hosts. If you are planning to send out agents that have your credit card numbers or some form of e-cash embedded in their state, you need to worry about pickpockets. Because a host uploads the class files and state for your aglets, they (or anyone sniffing the network during transit) could potentially read private information or even alter your aglet's code and state.
Why mobile agents?
Assuming the security issues surrounding mobile agents can be adequately addressed, why would you choose a mobile agent solution over more traditional client/server models? Why would you choose mobile agents over mobile code, such as applets or servlets?
In a world in which you have proven distributed processing models, including mobile code, what is the point of mobile agents?
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.
A higher level of abstraction
Another perspective comes from Danny Lange, the inventor of the aglet, who had this to say about aglets:
When I invented the aglet, I was searching for a higher abstraction for network computing. To me the aglet was an answer to some 15-year-old questions I had: What comes after object-oriented programming? What is the next paradigm shift?
The aglet is my key abstraction for "network computing"; not the applet, not the servlet, not RPC, but the aglet. The aglet allows me to think in terms of the "network computer"; not the NC, but all the NCs, PCs, workstations, and mainframes in one space. I don't care where the aglet is running, nor does the aglet care. As we say about the aglet: "Create once, go anywhere".
So mobile agents provide a way to think about solving software problems in a networked environment that fits more naturally with the real world. In the real world, people and objects move from place to place. If you want to get some work done, sometimes you make a phone call, sometimes you send an assistant to the work site, and sometimes you just go yourself.
Concluding thoughts: Object-orientation and mobile agents
Object-oriented programming represented a higher level of abstraction than procedural programming. Early proponents of object-oriented programming promised that this higher level of abstraction would make programmers more productive, code easier to understand and maintain, and make possible better development tools. Although opinions may vary as to the extent to which these promises have been fulfilled, for the most part, the software development community has embraced the object-oriented approach.
Mobile agents may simply represent another step in the evolution of the object-oriented paradigm. Aglets are Java objects that can autonomously move from host to host. Like a traditional object, an aglet has state, behavior, and identity. Unlike a traditional object, however, an aglet also has location.
Next month will be the final article in my long series that covers Java bytecodes. It will discuss the various ways the Java virtual machine invokes methods.
Learn more about this topic
- The aglets home page is here:
- IBM's Massively Distributed Systems research page has several interesting agent-related links:
- Servlets are code that can be sent in the reverse direction from applets, from a client to a server. This model enables a client to execute a script on a server without requiring that the script already be present at the server. There are many servlet-related links at the bottom of Phil Chang's servlets article from last month's JavaWorld:
- The IBM research paper titled "Mobile AgentsAre they a good idea?" by Harrison, Chess, and Kershenbaum is available for download in PostScript format here:
- For aglet code samples and another perspective on Java aglets, check out this article by Bret Sommers, in last month's JavaWorld, "AgentsNot just for Bond anymore":
- Previous Under The Hood articles:
- The lean, mean virtual machine -- Gives an introduction to the Java virtual machine.
- The Java class file lifestyle -- Gives an overview to the Java class file, the file format into which all Java programs are compiled.
- Java's garbage-collected heap -- Gives an overview of garbage collection in general and the garbage-collected heap of the Java virtual machine in particular.
- Bytecode basics -- Introduces the bytecodes of the Java virtual machine, and discusses primitive types, conversion operations, and stack operations in particular.
- Floating Point Arithmetic -- Describes the Java virtual machine's floating-point support and the bytecodes that perform floating point operations.
- Logic and Arithmetic -- Describes the Java virtual machine's support for logical and integer arithmetic, and the related bytecodes.
- Objects and Arrays -- Describes how the Java virtual machine deals with objects and arrays, and discusses the relevant bytecodes.
- Exceptions -- Describes how the Java virtual machine deals with exceptions, and discusses the relevant bytecodes.
- Try-Finally -- Describes how the Java virtual machine implements try-finally clauses, and discusses the relevant bytecodes.
- Control Flow -- Describes how the Java virtual machine implements control flow and discusses the relevant bytecodes.
- The Architecture of Aglets-- Describes the inner workings of Aglets, IBM's autonomous Java-based software agent technology.