Anne Nguyen, Ian Stewart and Xinfeng Yang
School of Information Technology
Griffith University
PMB 50 Gold Coast Mail Centre QLD 9726
E-mail: A.Nguyen@gu.edu.au
Mobile agents have the potential to radically change the way people conduct business via e-commerce. From a resource management perspective, they can perform many repetitive, time-consuming tasks, thus freeing up human labour for more strategic work. From a technology point of view, they can help to meet the exploding need for more bandwidth. They can even operate in conditions where Internet connections are only intermittently reliable.
This paper presents a simple mobile agent model, and reviews applications of the technology in e-commerce. It also considers a number of important security issues that must be addressed before mobile agents can become widely accepted.
Keywords
system model, mobile agent, e-commerce application, network security
Mobile agents have the potential to radically change the way people conduct business via e-commerce. From a resource management perspective, they can perform many repetitive, time-consuming tasks, thus freeing up human labour for more strategic work. From a technology point of view, they can help to meet the exploding need for more bandwidth. They can even operate in conditions where Internet connections are only intermittently reliable.
This paper presents a simple mobile agent model, and reviews applications of the technology in e-commerce. It also considers a number of important security issues that must be addressed before mobile agents can become widely accepted.
Mobile Agent Technologies have the promise of changing the way the Internet and other networks function due to their advantages over earlier technologies in remote programming such as process migration and (traditional) remote procedure calling
In the typical client/server model, there are two separate components, a client and a server. They communicate over a network through a "handshake" paradigm. The client requests information, while the server responds. Each request/response is a complete round trip on the network.
In the mobile agent model, when the client in the mobile agent needs access to a resource that the server provides, the client actually migrates to the server’s machine, and makes its requests to the server directly. When the entire transaction is complete, the mobile agent returns home with the results. Some of advantages of this model are better bandwidth usage, reliable network connection and reduced design work.
Gray et al. (2000) succinctly define a mobile agent thus:
A mobile agent is an executing program that can migrate, at times of its own choosing, from machine to machine in a heterogeneous network. On each machine, the agent interacts with stationary service agents and other resources to accomplish its task
Kalchuk and Karmouch (1997) further extend the definition by stipulating that the agent decides when and where it will migrate, and may interrupt its own execution and continue elsewhere on the network.
Thus the definition excludes web spiders, robots and crawlers, such as Lycos and WebCrawler, for example.
Gray et al. (2000), Conde (1998) concur that there are several prerequisites for constructing a mobile agent. The essential requirements are:
The emergence of Java has enabled a common execution language across heterogeneous networks, platforms and machine architectures.
Additionally, development of the CORBA specification has further enabled this aspect, with the ability of objects to be coded in virtually any language. This is made possible by CORBA locating and executing modules in a form not necessarily supported natively by the client.
Less sophisticated implementations of mobile agents can be written as CGI scripts executing scripts in Perl or Python, or fully compiled programs written in C/C++.
Persistence involves converting the object's state, such as data variables, program stack, and possibly even the point of execution of the code, and converting it into a data form suitable for transmission over a network.
There must be some communication mechanism must exist to transfer agents across networks. An agent might be transferred using TCP/IP, or by using a higher level of communication such as RMI, IIOP, SMTP or even HTTP. Mobile agent architectures may even use a variety of transport mechanisms, giving greater flexibility.
An agent's executable code must be transferred, which may consume a large amount of network bandwidth, unless shared code is located at the agent host. Techniques such as shared libraries of code, or caching, may be of benefit. In addition, the persistent state of the agent must be transferred.
As observed by Gray et al (2000), security is critical when executable code is transferred across a network. Malicious or badly written code could wreak havoc when unleashed upon an unsuspecting host, and agents themselves need protection against hostile hosts that would seek to dissect or modify them.
Agents may protect their data and information through encryption techniques. Security can be implemented on the host side through the use of digital signatures, which can validate the user and the agent to the host. However, many agent operations need to be conducted in an untrusted mode, so digital signatures may not provide an overall solution. Further, the operations of an agent executing on a remote machine consume memory and CPU time on the host – malicious code could effectively result in a denial of service.
While e-commerce presents a lot of opportunities for businesses, it may require new business models and processes in order to realise its potential and be cost effective. E-commerce purchases are still mostly unautomated, involving human decisions in all stages, adding to transaction cost. The emergence of dynamic markets, supply chains and distribution channels employing new intelligent distributed computational processes called mobile agents aim at providing an appealing solution. E-commerce vendors will no longer have to integrate with network services such as America Online to conduct transactions over the Internet. New, open electronic markets (Chan et al., 1999) are represented by selling agents displaying goods and services. The buyers side is composed of buying agents which scan the markets for information gathering, negotiation, and finally purchasing. In this new model, decision making time and human involvement, which are typically most time consuming, are minimised. Other advantages include less network connections and the ability of mobile agents to travel and execute in heterogeneous widespread locations.
Figure 1 : Mobile Agent model
(Wong et al, 1999)
A mobile agent is really an entity composed of two different parts. One part is the code itself, which consists of the instructions that define the behaviour of the agent. The second part is the current state of execution of the agent.
A mobile agent brings the two parts together. When the agent migrates to a new host, both its code and its state are transferred. Thus, the agent not only remembers what to do and how to do it, it also remembers what it has done before.
Figure 2 : Proposed E-Commerce Agent System using Mobile Agent
Based on the mobile agent model, the proposed e-commerce system consists of two major modules:
Selling agents represent the goods and services provided by vendors. These software modules are static and reside on the vendors’ sites.
The buying agents have to collect information from selling agents. They have mobility to migrate from one vendor’s site to another’s. Additionally, the buying agents possess the ability to communicate with the selling agents via SQL query of backend database using say, a JDBC interface.
The buyer sub-system consists of two agents, the buyer agent and the buyer controller agent. The buyer controller agent dispatches its mobile buying agents to the Internet and they in turn visit several selling agents in order to conduct their buying activity.
The seller sub-system only consists of one stationary agent, the seller agent. This agent is a software module that executes on the seller hosts, listening for buying agents and giving the information they need.
Each time a buying agent reaches an electronic vendor, via their web site, it opens a dialogue with the selling agent. When the selling agent determines what the buying agent wants, it contacts the backend database, which in turn passes the information to the buying agent.
After the buying agent has achieved all its goals, it leaves the site of the seller agent and moves to another electronic vendor. Once it has visited all the accessible vendors, it returns to the buying host with all the information it has collected. A comparison based on time or cost facility, for example, is now possible.
The buyer sub-system is following the classic master/slave configuration (Lange and Oshima 1998). This means the activity of the slave process is controlled by master process. The buyer controller has complete control over the lifecycle of the buyer agent while it is travelling from one electronic vendor to the next.
At first, the buyer controller creates a buyer agent, initialising it with the source code to be executed, and the constraints on the search in the form of data, and obtains its proxy. Using this proxy the buyer controller agent dispatches this buyer agent to the first address on its itinerary, and has command over the buyer agent at all time. Each time the buyer agent finishes its task at a remote host it is dispatched to the next host on the buyer controller itinerary with the help of the proxy.
In this way the buyer controller keeps sending the buyer to all the hosts on its itinerary. After the itinerary comes to an end it recalls the buying agent to the buying host where it displays all the information it has gathered.
When the buyer agent arrived at a selling agent host, it passes on the information regarding the search to the seller agent and waits for the results. The seller agent gets all the possible deals available from the backend database and passes this information to the buyer agent. The buyer agent stores this information in a data vector, which is a persistent data structure the buyer agent carries with it to be able to display all the results when it returns.
For the negotiation function, the buyer maintains a persistent variable, which keeps track of the lowest price, for example, offered by any electronic vendor so far. When it receives a new quote it compares all the deals obtained with the lowest deal it has. If it still has a lower quote it asks the seller agent to give it a better price. When the seller agent comes up with another price, the buyer agent compares it to the lowest price again. If the price is better, it writes that data to its data vector.
For the seller sub-system, the seller agent contacts the backend database using SQL query through JDBC interface. The backend database consists of one normal price table and a negotiated price table. After getting related information, it passes them back to the buyer agent through message passing.
Aglets are a pure Java mobile agent technology developed by IBM at their Tokyo Research Laboratory. Aglets are Java objects that can move from one host to another. IBM has developed a platform-independent API to support development of aglets. The API requires the JDK1.1 or later to run.
Conde (1998) recognises that Java addresses the requirements for mobile agent implementation. He notes the strengths of Java being in three key areas:
This was General Magic’s first mobile agent platform. It is Java based. Odyssey utilises Java RMI and also supports CORBA and DCOM protocols for agent transport.
Concordia is a full-featured framework for the development and management of network efficient mobile agent applications that extend to any device supporting Java. It is developed by the Mitsubishi Corporation.
The Tacoma Project is a collaboration between the Department of Computer Science, University of Tromsø, Norway, the Department of Computer Science, Cornell University, Ithaca, New York, USA and the Department of Computer Science, University of California, San Diego, USA. Most of the software used in the TACOMA Project is written using Tcl/Tk and C.
From Oracle, this agent is client/agents/server software for extending information to a mobile workforce.
Agents are ideal for situations such as these. Concurrent agents can be despatched to search for specific information, either on the Internet, or on an organisation’s departmental servers. As opposed to conventional data gathering, agents reduce network traffic because the agents do all the data processing locally before either moving on or returning to the user machine. Further, the model is useable in an unreliable network environment as the agents can continue to process locally despite broken network connections.
Single or multiple agents can be sent to remote hosts to gather the best prices or to negotiate/bid on the sender's behalf.
Agents can be used effectively in CRM by notifying customers of news, product updates and sales. Inventories can be linked to agent monitoring to facilitate "just in time" stock management.
Products subject to supply and demand pricing, such as most commodities, can be monitored by an organisation’s buying agent. Pre-determined buy or sell variables can be used to trigger the appropriate action. For example, an organisation may release an agent programmed to initiate a transaction for a specified quantity when a seller offers it at a certain threshold price.
This level of automation may lead to some trepidation by regulatory authorities. The automatic "stop losses" programs used by some stock trading firms exemplify these concerns.
One of the great strengths of agent technology is their capacity for concurrency. Many agents may be released simultaneously, searching various subsets of a large network such as the Internet. Results may be categorised by location or by cost, for example.
Thus, a large task may be performed in a surprising short amount of time.
Mobile agents are ideally suited to distribution of digital services and software, either as product, or patches and updates. A database registry of buyers or users can be used to provide the itinerary for the agent/s, and the agents despatched to perform the necessary operations at a time convenient to the end user. For example, a notification could be sent, requesting that the end user notify of a suitable time for an update to be delivered and installed. The agent can then reside on the host until the specified time, for instance 2 am, and then proceed with the update automatically during the end user’s down time.
The typical client/server relies on a "pull" technology, whereby the user (client) must contact the host (server) to establish communication. Mobile agents enable the concept of "push" whereby the agent is deployed and will send data and information to the client when it becomes appropriate or timely.
Because the agent resides and executes on the host machine, it is independent of the network once resident. A communication connection only needs to be established when the agent decides to move on. It is this aspect of their operation that most researchers refer to when bandwidth minimisation is mentioned. Lange and Oshima (1999) more correctly identify this feature as network traffic reduction.
Mobile agents, unlike client/server operations, do not rely on a communication channel being maintained for operation. Once resident on a host, an agent may continue to execute. Should its operations be complete, it can simply wait for the restoration of the network connection to continue on its itinerary, or return to its issuer.
When a mobile agent moves, the whole object is passed. This means that its entire presence, or footprint (code, data, execution state, and travel itinerary) leaves the host machine. Some operating systems are capable of capturing some information about the agent’s activities through environment variables, and if Web based, through cookies not discarded on exit.
The mobile agent contains sufficient information to decide what to do, where to go, and when to go. This is often termed its itinerary.
Mobile agents have their own threads of execution and can execute asynchronously. In an asynchronous architecture, the mobile agents have a single communication point (the issuer’s computer) and limited intelligence. In general, asynchronous architectures result in thin agents with higher mobility.
A mobile agent can perform its tasks whether the network connection is open or closed. As mentioned above, ff the network connection is closed and it needs to move, it can simply wait until the connection is reopened.
More than one mobile agent can be dispatched to different sites to perform tasks in parallel.
The principal impediment to adoption is the possibility of security breaches by malicious code, although this can be minimised by Java agents executing in their own virtual environment. This, however, is only satisfactory if the host environment is free of security holes. Many hosts, for a variety of reasons such as misconfiguration, are not optimal in their support of a secure environment.
The ability of mobile agents to replicate can lead to serious denial of service attacks simply by overwhelming the CPU of a host server. As observed by Johansen (1999), the major security problems stem from the possibility of denial of service, and the integrity of the agents themselves.
Corradi et al. (1999) identify the lack of a comprehensive security framework as being a major obstacle in the deployment of mobile agents for e-commerce. This problem is still to be adequately overcome. Protection against the possibility of malicious code, for both execution on host sites and against tampering with the data and information contained in mobile agents is essential for the implementation of mobile agents in the electronic market.
Mobile agents' ability to execute and gather information from hosts opens up several areas of security threats. These may come from malicious agents, hosts or unauthorised third parties. Strict security procedures must be implemented to protect agents and hosts from malicious activities.
Authorisation and Authentication: All users, agents, and hosts must be authorised and authenticated to verify their identities. In addition to password access, digital signatures may be required.
Confidentiality: Confidential data needs to be kept away from agents, other hosts and unauthorised third parties by using separate servers.
Non-Repudiation: Important communication exchanges must be logged to prevent later denials by any parties to a transaction.
Audit Trail: Security related activities must be recorded for auditing and tracing purposes.
Low bandwidth and unreliable network connection have been persistent impediments to the successful conduct of e-commerce over the Internet. The proposed agent model discussed above overcomes these problems by having the agent reside and execute on local machines and networks. Further, re-engineering of present business and system processes must be addressed by organisations if they wish to survive in the contemporary market. The proposed retail model using mobile agent provides one of the solutions.
Chan, A. P., Steinfield, C. W. and Kraut, R. E. (1999) "Do Open Networks Favor Electronic Markets?", Information Impacts Magazine, April 1999.
Conde, J. (1998) "Mobile Agents in Java", CERN Particle Physics Laboratory, Technical Report CERN/IT/ASD/RD45/98/12.
Corradi, A., Montanari, R. and Stefanelli, C. (1999) "Mobile Agents Integrity in E-Commerce Applications", Proceedings of the 1999 ICDCS Workshop on Electronic Commerce and Web-Based Applications, Institute of Electrical and Electronics Engineers.
Gray, R. S., Cybenko, G., Kotz, D. and Rus, D. (2000) "Mobile agents: Motivations and State of the Art", Technical Report TR2000-365, Dept. of Computer Science, Dartmouth College.
Johansen, D. (1999) "Trend Wars: Mobile Agent Applications", IEEE Concurrency, Pp 80 – 90 July-September Issue, 1999, IEEE Press.
Kalchuk, B. and Karmouch, A. (1997) "A Mobile Agent Prototype for Autonomous Multimedia Information Access, Interaction and Retrieval", Proceedings of Multimedia Modelling ‘97, Singapore, 1997.
Lange, D.B. and Oshima, M (1998) Programming and deploying Java mobile agents with Aglets. Addison-Wesley.
Lange, D. B. and Oshima, M. (1999) "Seven good reasons for mobile agents", Communications of the ACM Volume 42 , Number 3 , pp. 88-89.
Wong, D, Paciorek, N and Moore, D (1999) "Java-based mobile agents", Communications of the ACM, Volume 42, Number 3, pp 92-102
Anne Nguyen, Ian Stewart and Xinfeng Yang © 2000. The authors assign to Southern Cross University and other educational and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The authors also grant a non-exclusive licence to Southern Cross University to publish this document in full on the World Wide Web and on CD-ROM and in printed form with the conference papers and for the document to be published on mirrors on the World Wide Web.