Abstract: This study presents a novel framework for developing an agent-mediated E-commerce environment for the mobile shopper. Intelligent agents represent both shoppers and the store to negotiate for desired products based on shopper preferences. In this system, buyer and seller agents are created to simulate the e-market. Seller agents advertise his products to sell and buyer agents search the products to buy. The seller and buyer agent paradigm is gaining in importance and visibility as a programming paradigm for several classes of agent-based system. Its inherent advantages, such as communicative with others, less time consuming, dynamic service updates etc. make it an attractive alternative to the traditional paradigm communication-agent system. In addition, the proposed system integrates the computing advantages of mobile agents with several improved agent-mediated algorithms to enhance system robustness. Preliminary experimental results demonstrate the advantages and potentialities of the approach for the mobile shopper on the e-market.

INTRODUCTION

A vision of the not so distant future serves as the impetus for research activities collectively known as the EMARKET project. The fundamental assumptions are that: the distinction between the physical world and the virtual world (Internet) will be blurred as electronic presence for people, places and things (Kindberg et al., 2002) becomes commonplace, accessing the virtual world from a desktop or laptop computer will partially give way to access via a variety of mobile appliances such as the PDA’s of today, user context and preferences are vital considerations for delivery of electronic content, services and support.

The distributed nature of the virtual world requires software to operate in a heterogeneous and dynamic environment composed of many components that must communicate with one another (Qiming et al., 2000), software agents promise to offer the programming paradigm necessary to enable intelligent, dynamic and heterogeneous component interaction, future generations of E-commerce should employ agent technology (Maes et al., 1999) to realize and benefit from dynamic pricing, access to worldwide markets and flexible partnership formation (Griss and Letsinger, 2000). An E-commerce, mobile appliance testbed was created to study these topics individually while also looking at their integration.

The research began by developing general scenarios outlining a vision of how users could benefit from emerging mobile appliance and software agent technology. The original project motivations and objectives are discussed. Included in this section is a high-level description of the implemented shopping mall scenario.

MATERIALS AND METHODS

Motivating vision
People, places and things: The Cooltown project (Caswell and Debaty, 2000) provides one of two visions motivating the EMARKET project. It is believed that given the maturation of Internet protocols, wireless networking and mobile electronics, future generations of people will want and can benefit from remaining regularly connected to the World Wide Web. Further, the relationship between the physical world and virtual world will be melded together by these enabling technologies. First, all people, places and things will have a virtual presence (an online representation). Because people have simultaneous access to both the physical entity and its virtual presence, new opportunities for interaction become possible and desirable. Consider a bookstore with customers that are physically present also having access to the store’s virtual representation. If a book is out of stock, it can be ordered and shipped immediately without waiting in line for a store clerk to help. It can give suggestions of related books depending on the section of the bookstore where the user is physically (Caswell and Debaty, 2000). In this scenario, the shopping experience of a customer is improved by using a web-enabled appliance, wireless network, Internet protocols and by utilizing contextual information provided by physical location.

Agent based electronic commerce: There are currently only a small number of distinct examples of agent technology being applied to the electronic commerce domain, primarily price comparisons and aggressive buying agents (pricebots and shopbots). What is more common is the tedious and time-consuming process that consumers go through when shopping over the Internet. The process might start with a search for a particular product from which several links to stores are returned. The consumer typically must visit each website to check pricing and additional terms. This could involve considering alternate products from an online catalog, product availability, delivery options, return policy or payment methods. After all relevant information is gathered the consumer then purchases the product using a credit card.

In the future, it is envisioned that software agents can be made responsible for autonomously mediating purchases for both businesses and consumers. An agent can handle all of the information gathering, decision-making and payment processes. More importantly, companies will have instant access to unbounded, world-wide markets; prices and product packaging can be determined dynamically through negotiation on a per transaction basis many short-lived, task-specific collaborations between companies will replace the more expensive, long-lasting partnerships and contracts common today (Griss and Letsinger, 2000).

Project elements: The EMARKET project was rich with opportunities to learn and evaluate existing technologies and standards, gain experience with agents and appliances in the electronic commerce domain and study the concept and implications of context-aware computing.

Fig. 1:	EMARKET project elements

Six project elements summarizing the main topics of research are shared and their scope for the EMARKET project is defined (Fig. 1).

Domain: The application of software agent technology to the electronic commerce and personal assistant domains serve as the backdrop for the EMARKET project. Characteristic of agents in the electronic commerce domain are their understanding of commerce related concepts including buying and selling, ability to negotiate and responsibility for handling payment and goods exchange. A more sophisticated personal assistants also has the ability to learn from interactions with their owner thereby offering better support over time. The EMARKET project operated at the intersection of these two domains. An electronic commerce agent was developed that also took user preferences into account, while providing a web based interface with which to control the agent.

Context: Context is an important consideration that should serve as an input to the decision making process of an agent. Contextual information can be extracted from the environment of the agent (virtual context) or the user’s immediate physical surroundings (physical context). Virtual contextual elements might include the availability of services or infrastructure agents, while user location or hardware availability are examples of physical contextual elements. Additionally, user preferences also help establish what might be collectively called the operating context of the agent and user. A simplified operating context was established for the EMARKET project that included virtual and physical contextual elements. To a more limited extent, user preferences were also considered.

Distributed intelligence: A main objective of the EMARKET project was to gain experience creating software agents for electronic commerce. Agents were created for this domain and a personal assistant agent was also created. These agents and services were deployed on multiple hosts within the Hewlett Packard Intranet. A direction lookup capability was implemented both as an agent and as a service. The service had an object-oriented interface; the object’s methods were invoked to query for and receive directions. More generally, agents are autonomous software components that are personalized to a particular user, while services are web accessible computing resources.

Appliances: The term appliance is loosely meant to describe user-oriented devices capable of communicating with the surrounding environment. Being mobile and having a built-in ability to connect to a centralized/established communication channel often further characterize appliances. These devices are usually good at providing a few specialized capabilities to the user but often do not offer a comprehensive suite of features. During the EMARKET project, the limitations of appliances were considered, as were best methods for choosing from multiple appliances to communicate most effectively.

Standards: The Zeus agent building toolkit, developed by British Telecommunications was used to implement all of the agents for the EMARKET project. At the time Zeus was written, the Foundation for Intelligent Physical Agents (FIPA) was beginning to develop specifications for multi-agent system development, agent-to-agent communication and domain specific application of agents. The Zeus communication subsystem was written to conform to what are presently the ACL Message Structure and Communicate Act Library specifications. The infrastructure agents provided by Zeus speak the FIPA Agent Communication Language (ACL) and parsing classes are available to decode messages following the FIPA performative syntax.

Additional infrastructure and personal agents developed for the EMARKET project were required to speak the FIPA ACL because they had to interface with the nameserver agent (ANS) and the Directory Facilitator (DF) provided by the Zeus toolkit. Efforts were also made to conform to the FIPA ACL for conversations between agents written solely for the EMARKET project.

Zeus was chosen because it was available in JAVA, opensource and integrated a complete set of intelligent multi-agent capabilities into a single, uniform package: FIPA agents, rules, facts, protocols, facilitation, etc. Each Zeus agent runs in a single Java virtual machine. Agents communicate via sockets. Agents do not use HTTP or XML and Zeus does not provide a web interface.

Tools and technology: The EMARKET project was rich with opportunities to evaluate current technology and tools for building agents, dynamic and customized display of information over the Internet (web servers and content API’s), databases, distributed programming API’s, information representation and communication protocols. One of the goals was to have agents provide web based interfaces, rather than use only local GUI’s. The specific tools and technologies used include the Zeus Agent Toolkit (Nwana et al., 1999), XML, RMI, JSP, E-squirt, Apache server, HTTP and SQL. Integrating these technologies for the EMARKET project proved to be a challenge.

Software engineering: Managing the EMARKET project required incrementally evolving the agent infrastructure by organizing contributions from 13 researchers over the course of a summer. To facilitate development, Visual Source Safe was used for version control and file sharing, a standard environment was established and local build and execution scripts were used. A nightly build process supported the goal for incremental development. Using Visual Source Safe required researchers to communicate such things as code changes, current work in progress, and source code organization. Missing but needed was an established agent development process and techniques for communicating agent and multi-agent system design.

Value: There was a strong belief in the group that agent technology, with its promise of agents as flexible, autonomous, loosely coupled components would be ideal for building complex e-commerce systems (Griss, 2001). This in turn would allow much more customized application systems to grow dynamically.

RESULTS

EMARKET shoping mall
Implementation objectives: In a single sentence, the objective of the EMARKET project was to build a testbed for studying agents, appliances and their relationship in the electronic commerce and personal assistant domains. From an implementation standpoint, the main objective was to provide the hardware and software support necessary to integrate appliances and agents into a test platform.

This platform, built incrementally would enable experimenting with agent technology (negotiation, roles, decision making, etc.), agent-based electronic commerce economics (market stability, fairness, efficiency etc.), mobile appliances and user context. Many more requirements for the experimental test platform were pursued including ease of agent configuration, support for agent plug-and-play behavior, a web-based agent interface, dynamic and customized web page display, initialization software, support for visualization of agent interaction and additional debugging tools necessary for development.

High-level scenario description: To build the EMARKET experimental test platform, a shopping experience of the future was developed.

The implemented scenario finds a person named Josh arriving at a shopping mall. Here, the stores are physically present, like conventional malls but they also have a virtual web presence that can facilitate interaction. Josh brought his HP Jornada; a personal digital assistant running Windows CE.

It also has a wireless LAN card to connect to the Internet and an infrared port to communicate with other IrDA capable devices that Josh might encounter, while shopping, in accord with the CoolTown vission. Josh uses his Jornada to interact with stores in the mall and also to gain access to the services provided by his personal assistant agent. The personal assistant is able to communicate with mall infrastructure agents and other software agents representing the stores.

The mall entrance, like every other physical location, has a beacon that connects physical locations with their virtual presence. The mall direction service to provide directions to the store of the choice. The web-based interface allows him to choose the type, quantity and maximum price he is will to pay for each product. This information is sent to his personal assistant who consults with the mall yellow pages (facilitator) agent to locate store agents (Fig. 2).

Instead of being paired with a store agent directly, Josh’s personal assistant is given contact information for an English auction agent. This agent holds auctions on behalf of store agents for the requested products.

Fig. 2:	The shoping mall scenario

It allows any number of bidding agents to participate in an English auction of fixed length.

EMARKET, the first iteration: To complement the high-level description of the implemented shopping scenario that was given in the previous section, the step-by-step details of purchasing a product are provided below. It is important to note that initialization of the EMARKET infrastructure is not described. This is deferred until the next section. The agents that are active when Josh arrives at the mall include A Name Server (ANS), Directory Facilitator (DF), Direction Agent (DA), Personal Agent (PA), Store Agent (SA), English Auction Agent (EAA), and Bidder Agents (BA). The role and interactions of each agent are described here.

Mall arrival, product search, direction query: The DF is used to determine what stores are selling the selected product. The DF is a mall infrastructure agent that maintains a list of all the products that are for sale in the mall (SA’s register products with the DF). The DF returns the list of stores currently selling the product to the PA. Two versions of this process were coded. In the demonstration version of the shopping mall scenario, a look-up object returns directions. In the experimental version, the PA requests directions from the DA. The DA returns textual instructions for navigating from any two points in the mall. For demonstration purposes, cubicles were assigned store names thus introducing the notion of physical location coupled with virtual representation.

Store login, select product to purchase, register for an english auction: The EAA’s responsibility is to hold English auctions for stores in the mall. When a request to sell a product comes in, the EAA contacts the DF to inform all agents in the mall that a product is being auctioned. Then when a PA makes a purchase request, the DF is queried to see if auctions are currently open. The DF returns the name of the auction to the PA who can then register with the EAA to compete.

Compete in english auction, complete fulfillment, continue shopping: Once an auction is found, the PA registers with the EAA. In the EMARKET demonstration version, BA’s serve as dummy agents that are not owned by anyone but compete with the PA during the auction. The PA is loaded with a bidding English auction protocol and accompanying strategy. The strategy is not interesting as the PA simply bids a single increment higher than the maximum bid until it wins or its maximum bid is reached. The BA’s also use the same protocol and strategy. At the conclusion of the auction, which is time bounded, the EAA informs the participants of who has won and lost. If Josh’s PA wins the auction, then it proceeds to pay the EAA. The EAA informs the SA of the sell and the SA transfers the product to the EAA.

EMARKET implementation detail: Before the shopping mall scenario can be executed, several software infrastructure components must be in place. The EMARKET infrastructure is comprised of four subsystems including an Apache web server, RMI server, SQL database (mySQL) and Zeus utility agents. The order in which these subsystems are brought-up does not matter however, all must be running before store or personal agents can be instantiated. Interaction between the subsystems shown in Fig. 3. Notice that multiple languages (RMI, HTTP, SQL and ACL) are needed to facilitate communication.

When a store or personal agent is instantiated they query (1) a database that contains configuration and personal preference information. For the PA, the database contains the shopping list that determines what products should be purchased. The store agent retrieves the store inventory from the database. In the demonstration version of EMARKET, a placeholder for personal preference information exists in the database. The only user information stores was the agent’s name for both types of agent. When a personal or store agent is brought to life, they must register with the RMI Server. This allows the web server to communicate with the agents by remotely executing their methods.

After all agents are running, the shopping mall scenario commences. Beacons broadcast XML encoded URL’s using an infrared communication. The Jornada runs e-squirt, an application that receives beacon transmissions and then creates a link for the URL. When the shopper clicks on this link, the web client running on the Jornada makes an HTTP request to the web server using its PCMCIA wireless network card. Tomcat extends this server and allows dynamic web content to be displayed using JAVA Server Page technology.

Because web pages are the primary interface to the store and personal agents, the web server must consult the RMI server to obtain references to them. After these references are obtained, the web server can execute methods provided by the agents. Once the agents have been given a task to perform, they communicate (Maes et al., 1999) directly with each other using a FIPA compliant ACL message format. The personal and store agents use this same mode of communication to interact with the Zeus Infrastructure (name server, facilitator, etc.) agents.

Fig. 3:	EMARKET communication paths

Fig. 4:	AUML sequence diagrm for the EMARKET english auction

Of all the communication between agents, the most complex series of message exchanges occurs during the English auction. As can be shown in Fig. 4, message types (inform, subscribe, etc.) are taken from the FIPA Communicate Act Library Specification. The EMARKET English auction protocol defines four roles that include a seller, facilitator, auctioneer and bidder. When the auctioneer agent is created it registers with the facilitator to inform the society that it can hold auctions. Then sellers can subscribe to the facilitator for a list of available auctioneers.

The facilitator sends the names of available auctioneers to the seller who can then request that a product be auctioned. In response to this request, the auctioneer informs the facilitator that it is selling a product. This initiates the auction. Agents wishing to purchase this product consult the facilitator who informs them of auctions that are currently open. The auctioneer waits for bidder agents to register. Once registered, bids can be placed. Whenever a new high bid is received, the auctioneer informs all registered bidder agents. Bidding continues until a fixed time has passed. At the close of the auction, the auctioneer informs the agents who has won. Though the sequence diagram does not show the payment conversation, the winning bidder and seller engage in this message exchange.

CONCLUSION

A valuable lesson learned was that MAS framework development can benefit from the first round of abstractions elicited from the multi-agent system domain. British Telecom’s main contributions are the identification of valuable agent concepts and component design for executing agent behavior using a protocol-based paradigm. Implementing an English auction protocol provided experience with agent communication languages, FIPA standards, conversation management and modeling agent communication. Also, support for communication protocols and corresponding strategies (algorithmic flexibility points) was incompletely supported. FIPA verbs were used to implement the English auction and were beneficial because of the agreed upon semantics. A standardized method for describing agent conversations would have been beneficial. Though ad hoc notes and diagrams did help facilitate design, many details needed for implementation went unspecified. Finally, better conversation management was needed.