The Internet and the World-Wide Web have become worldwide tools for e-commerce. However, despite their seemingly unlimited network bandwidth, ease of use, and secure means of online transactions, a shift in computing paradigm is still needed to fully exploit these features. Will mobile agents represent that shift, ultimately freeing up the Internet for its millions of netizens? The agent paradigm first needs to overcome several critical obstacles before this question can be answered. Here, we discuss why Java is such an effective implementation language for mobile agents in e-commerce.
The mobile agent concept grows out of three earlier technologies: process migration [5], remote evaluation [7], and mobile objects [3]—all developed to improve on remote procedure calling (RPC) for distributed programming. Early systems supporting process migration allowed an entire address space to be moved from one computer to another. One goal of this mechanism was to reduce network bandwidth (compared to RPC) when multiple RPC calls are needed to execute an application. While process migration allowed an entire process to be transferred to a remote host, this mechanism did not allow an easy way to return data back to the source node without the entire process returning as well (see Figure 1).
Next came remote evaluation programming, allowing one computer to send another computer a request in the form of a program (rather than an entire process address space). The remote computer receiving such a request executes the program referenced in the request within its own local address space and returns the results to the sending computer. Remote evaluation systems improved on process migration by allowing remote programming to occur without having to transmit the process control data from the source to the destination host.
Despite their help reducing network bandwidth, remote evaluation systems lacked the ability to encapsulate more state information into the executable program at the remote host. Mobile objects (based on formal object-oriented programming techniques) extended remote evaluation by capturing more program behavior within the mobile object. Such objects can migrate from node to node while carrying executable code, data in the form of object-specific properties, and potentially other embedded executable objects. A number of mobile object systems were popular in the 1980s, but the one that could be said to have led most directly to mobile agents was the Emerald system developed at the University of Washington [3].
A number of mobile agent systems have evolved from this evolutionary process [1, 4, 8, 10], most notably the Telescript language and run-time environment from General Magic [9]. But mobile agents have since improved on mobile objects in a number of ways. For example, mobile agents further reduce network traffic for applications processing large quantities of data. Some of the earlier programming paradigms were based on the client/server model as a way to offload work to a remote server. The client/server model takes the view that it is more important to ship the data to the program source, whereas mobile agents give the developer enough flexibility to extend the model by shipping the program to the data source (see Figure 2).
Mobile agents also provide some autonomy, because they themselves can decide dynamically where and when to travel to a particular destination node based on some embedded mobility metadata to perform some required work. Mobile agents improve on all these earlier technologies for distributed programming by providing a way for executable code, program state information, and other data to be transferred to whichever host the agent deems necessary to carry out the actions specified in an application. Mobile agents readily adapt to changes in both the program state and the network environment (such as network partitioning and disconnected hosts) to modify their routing behavior.
Mobile agents also give the user a natural mode of asynchronous interaction. Applications that need access to legacy applications can be packaged within the mobile agent and subsequently shipped to the remote host where the legacy code is located—while the user disconnects from the network as desired. A store-and-forward mechanism is typically employed within the mobile agent framework to support such behavior.
The autonomous and asynchronous nature of mobile agents is also especially effective in protecting mission-critical applications from failure caused by unreliable networks; agents can reroute themselves and carry the codified business logic needed to continue their tasks, even when confronted by network partitioning. This aspect of mobile agent performance makes such agents especially attractive to traveling businesspeople who regularly disconnect their mobile devices from their home office servers.
Other features, such as fault tolerance and security, were available in some of the earlier distributed programming paradigms, although mobile agents make greater use of them.
As a Language for Mobile Agent Development
Java is the language of choice for mobile agent systems. Concordia, Odyssey, and Voyager are all Java-based (see Koblick’s “Concordia” in this issue). Multiplatform support and the promise of write-once, run-anywhere operation make Java extremely well suited for mobile agent technology. Furthermore, the ubiquity of the Java virtual machine may someday facilitate dissemination of mobile agents throughout the Internet.
Java has several features not found in any other language that directly support implementation of mobile agents. For example, agent mobility requires facilities that convert an agent and its state into a form suitable for network transmission and, on the receiving end, allow the remote system to reconstruct the agent. Java’s object serialization accomplishes this conversion and reconstruction almost transparently.
Some Java-based and other mobile agent systems also provide persistent agent state information. Persistence is achieved by serializing an agent’s state, writing it to persistent storage, and later retrieving that state and using it to reconstruct the agent. After a mobile agent has been serialized, it can be transmitted to another host and reconstituted upon arrival on the other side. Java’s networking support includes sockets, URL communication, and a distributed object protocol called remote method invocation (RMI). In Java, programmatic access to distributed objects is achieved simply; RMIs are handled transparently by a local proxy or stub that interacts with the actual remote object.
Moreover, Java facilitates migration of code and state via its class-loading mechanism. Java’s class loaders dynamically load the classes included in an application either locally from the Java classpath (list of directories) or through the network. For dynamically loading mobile agent code and classes referenced by mobile agents, a specialized class loader provides several options:
- An agent’s serialized form can include its classes as well as any classes they reference.
- An agent’s classes can be loaded from a Web server or from another server.
- An agent’s classes can be loaded through the
classpath.
All code loaded by Java’s class loaders is subject to security restrictions, which are very useful for mobile agent systems that have to protect their agents (and the hosts on which they execute) from unauthorized access. Java’s security management supports development of fine-grain, highly configurable security policies. For example, agents launched by a particular user may be granted permission to write files, whereas another user’s agents may be granted only read-access, and for a third user’s agents, no file access at all.
Java also supports development of mobile agents that are tightly integrated with the Web. Applets may launch mobile agents from Web browsers and may also receive the agents they’ve launched after they complete their remote execution. Java also provides server technology akin to applets. So-called servlets function a lot like a Common Gateway Interface script and may launch and receive mobile agents. And Java’s Naming and Directory Interface (JNDI) allows seamless connectivity to business information through unified access to multiple naming and directory services. Mobile agents may, for example, use JNDI service providers to locate the services they need, then connect to legacy systems.
Generic Mobile Agent Architecture
Generic Java-based mobile agent architecture consists of six major components: an agent manager; an interagent communications manager; a security manager; a reliability manager; an application gateway; and a directory manager. Each has to support development of robust, reliable, secure, real-world agent applications (see Figure 3).
For example, the agent manager sends agents to remote hosts and receives agents for execution on the local host. Prior to transport, the agent manager serializes the agent and its state. It then passes the serialized form to its counterpart on the destination host. In a highly reliable architecture, it actually passes the agent off to the reliability manager, which ensures that the agent is received by the agent manager on the remote host.
Upon receipt of an agent, the agent manager reconstructs the agent and the objects it references, then creates its execution context. The security manager authenticates the agent before it is allowed to execute. Thereafter, the mobile agent system (actually the Java virtual machine) automatically invokes the security manager to authorize any operations using system resources (such as reading a file). When the agent is ready to migrate to another host, it requests the agent manager transport it to the correct location.
The security manager protects the host and the mobile agents against unauthorized access. All other mobile agent system components interact with it to authenticate and authorize mobile agents. The security manager also may protect agents by encrypting them before transmission and before they are saved to persistent storage. In highly secure systems, the security manager may digitally sign agents, and mobile agent systems may authenticate each other through an exchange of certificates. The security manager also allows authorized agents to pass through firewalls.
The reliability manager ensures the robustness of the mobile agent system. In highly reliable systems, it shields agents from the effects of server and system crashes. One of its main tasks is to guarantee the persistence of state associated with agents as well as with the mobile agent system. In addition, the reliability manager may use transactional queuing, possibly with a two-phase commit, to ensure agents reach their destination, even during system crashes.
The interagent communications manager in Java and other systems facilitates communication between mobile agents dispersed throughout a network. All but the simplest of applications use multiple agents to perform their computations, and the existence of multiple associated agents mandates interagent communication. Mobile agent systems typically offer messaging or distributed events. Some systems include more sophisticated forms of interagent communication, such as Concordia, which enables affiliated agents to cooperatively solve a complex problem that can be partitioned into smaller subtasks.
The application gateway serves as a secure entry point through which agents can interact with application servers (such as legacy databases). Agents may use the JNDI-based directory manager to identify the location of an application server and then migrate to the host on which the server is located. An arriving agent accesses resident servers through this gateway. The security manager has to authorize the agent’s use of the gateway and the application server.
Although this generic architecture is sufficient for most application domains, certain extensions to it and improvements in basic distributed computing technology would make mobile agents more efficient and practical for e-commerce applications. The current generation of agent frameworks implements abstractions supporting mobility and delivering on the promise of scalable, flexible distributed object systems. However, rather like early operating systems, such frameworks are each essentially a closed universe. Current ones do not interoperate on some important levels; missing are layers of abstraction allowing agents created by different users to meet, converse, and share meanings and understandings.
Many users are concerned about the overall performance of systems that are unconstrained and highly distributed. As RMI and similar efforts aimed at making the network transparent continue to mature, unresolved technical issues as mundane as distributed garbage collection and error recovery become significant. System architectures that operate predictably in a single-machine context may not operate so well once their separate elements are distributed, due to the cost of object marshalling and unmarshalling [2]. Needed is better basic distributed object technology.
Find Me a Ski Vacation
While practically all mobile agent systems available today facilitate code mobility, the “business rules” of agent and service interaction are still difficult to codify and debug. Whereas Web-enabled and networked people can act as their own travel agents, they have trouble instructing an autonomous agent to: “Find me a ski vacation for the third week in January, where there is predictably good snow, at a ski lodge where rates are less than U.S.$129 per night.” The human planner might be willing to trade off Colorado for Vermont to satisfy the constraints, but the idea is difficult to convey to an agent just about to head out into cyberspace to compete with hordes of other self-interested agents charged with the same mission. In part, the inability to convey knowledge has much to do with the need to define multiagent negotiation protocols [6].
Closely related to defining negotiation protocols, is the need for agents to encapsulate and understand commercial concepts, like place (“vacation” and “ski lodge”), calendar (“third week in January”), and price and currency (“rates less than U.S.$129”). The agent has to understand that a “ski vacation” is a variant of “vacation” that can occur only at certain places and only in the presence of “good snow.” Encapsulation of such semantically rich data exchanged between agents and legacy applications via the application gateway, agents, and the user that launched them can be addressed by the extensible markup language (XML), a new Web markup language that allows users to specify arbitrarily structured data types.
Furthermore, to provide more reliable support for Internet-based online transaction processing, more extensible transactional agent support is needed in the generic architecture for Java-based and other mobile agent systems. For example, support for transactional workflow-like semantics is required to ensure that all the work an agent performs is atomic, that is, committed, as it travels through a series of hosts. This atomicity is needed in e-commerce applications—even in a simple travel reservation application using mobile agents in which agents might travel to a number of travel agency database servers to negotiate the lowest fare and in which database updates on the various servers have to be synchronized.
Solutions to address these limitations are beginning to emerge from such sources as CommerceNet with XML and the University of Maryland, Baltimore County, with KQML. Commercially available solutions are rather rudimentary but will certainly be upgraded over time as agents move from research labs into a market in which real money is at stake for users and service providers (see Table 1).
A Killer Opp
While there is (as yet) no single killer application to propel e-commerce, almost everyone developing e-commerce software recognizes that online commerce represents a killer opportunity. Initial beneficiaries of e-commerce development will be business-to-business interchanges. Forrester Research, an information consulting firm in Cambridge, Mass., estimates that by 2001, business extranet and other electronic transaction strategies will be worth about U.S.$183 billion, while business-to-consumer transactions will be only around U.S.$17 billion. This disparity is due primarily to the fact that the vocabulary involved in business transactions is already codified for automated processing. For the foreseeable future, most interchanges will consist of dumb data transfers unaccompanied by a single line of code.
An electronic marketplace rich in killer opps—more than a shared space for simple electronic data interchange and where agents play a crucial role—will experience significant cultural, technological, and economic change. Figure 4 shows an example of an e-commerce application in which mobile agents negotiate with various providers for resources.
Social concerns are also significant, in the long run outweighing changes in technology. Mobile agents, by definition, are not tethered to specific applications and are not simply function calls but are goal-oriented and do not require user intervention. When they return to the place of their creation, users may not agree with the results or may be dissatisfied with the degree of precision in the answer. Meanwhile, the agent community has to resolve a number of technical issues:
- Deferred interaction. How frequently does the agent have to report back to the user?
- Control. How much control does the human user need? When does control begin to become costly?
- Understanding. How well can an agent really understand its human creator’s goals, intentions, and negotiating style?
- Flexibility. What accommodation does the agent have to be able to make (or perhaps be forced to make) in a marketplace populated by other (possibly smarter) self-interested agents?
- Robustness. How well does the agent have to be able to protect itself from malicious hosts and other agents?
We humans may ultimately realize we can’t dictate the mechanism, or “how I want you to work,” to an agent, but as long as we reach a reasonable agreement on interfaces, human needs may be served. Even so, given the dynamics of detached and deferred interaction, few of us anticipate designing or deploying systems without user interaction, especially when (as is likely to happen) there is a conflict in user goals. Most humans want to review and validate proposed transactions before their agents commit to them.
What’s Next?
We are already beginning to derive value from (admittedly rudimentary) Java-based and other systems of mobile agents. For example, we can create virtual assistants for ourselves that remain persistent in cyberspace and that we can access through graphical user interfaces or through voice commands. Some Web sites provide recommender agents that use simple persistence and a simple rules base to “remember” users’ contacts and activities and notify them of events of interest in specific, limited domains.
Although e-commerce will initially largely follow existing social and commercial interaction models, in a more online context, the social and commercial models will begin to drift apart. For example, the online transaction environment will begin to resemble a huge bazaar in some domains; pricing will be determined through real-time evaluation. Online auctions will closely resemble their physical counterparts; many participants will be virtual delegates exercising selfish agent strategies. Selfish agents will themselves become a cottage industry. Market imperfections that heretofore favored the seller will begin to favor the buyer’s tireless comparison-shopping agent. This buyer advantage will motivate many sellers in a given sector to hide price and feature information, but fear of lost opportunity will force sellers to raise the information content of their online offerings and express that information in a way that agents and metadata mappers (the next-generation search engines) can capture. Products will become services and vice versa.
Meanwhile, smarter companies will adopt new ways to disaggregate traditional value chains and augment the information component of their products, turning agents into welcome guests. Sellers will want agents to participate cooperatively and to succeed in the missions their creators entrust them with, codifying sufficient information to assure these agents fulfill their missions. And highly specialized agents, knowledgeable in specific domains (available for lease, purchase, or even free) will enlighten us and our agent representatives.
We are using Java mobile agent technology to deliver mobile agents to the threshold of agent-enhanced e-commerce applications, seeking technology with the potential to inspire and support mass-market e-commerce applications. Even today’s somewhat limited technology promises an e-commerce explosion in which mobile agents play a key role.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment