Sponsored Link •
Mobile agents have been around for many years, but they haven't yet entered the mainstream. This article answers the question, Why would developers choose mobile agents over other software technologies, such as client/server, applets, and servlets, for solving real-world problems?
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. 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 (both code and state), and continue execution at another host.
If you build it, they will come
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:
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 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.
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.
In this case, each agent contains information about its user's schedule. To agree upon a meeting time, the agents exchange information.
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.
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?
A single, flexible solution
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.
About the author
Bill Venners has been writing software professionally for 12 years. Based in Silicon Valley, he provides software consulting and training services under the name Artima Software Company. Over the years he has developed software for the consumer electronics, education, semiconductor, and life insurance industries. He has programmed in many languages on many platforms: assembly language on various microprocessors, C on Unix, C++ on Windows, Java on the Web. He is author of the book: Inside the Java Virtual Machine, published by McGraw-Hill. You can reach him at firstname.lastname@example.org.
This article was first published under the name Under the Hood: Solve real problems with aglets, a type of mobile agent in JavaWorld, a division of Web Publishing, Inc., May 1997.