Distributed Agent-Based Online Realtime Auction System
with Instant Messaging
55:195 Distributed Intelligent Agents for Internet and Engineering Systems
Group Project 2
Demo Due Date: April 11
Prof. Andrew B. Williams
To design and implement a distributed agent-based online “realtime” auction system using the Common Object Request Broker Archtecture (CORBA) or .NET, the Knowledge Query and Manipulation Language (KQML), and the Java Expert System Shell (JESS).
The Distributed Agent-Based Online Realtime Auction System (DABORAS) with Instant Messaging will enable sellers to place items up for action, find buyers who want to buy the items, and negotiate the price using instant messaging. DABORAS will use a matchmaker facilitator agent to match up the buyers and sellers and then allow them to negotiate in realtime using instant messaging.
The Matchmaker will be a facilitator agent implemented as a CORBA server that will accept KQML messages from CORBA clients, or seller agents. The Matchmaker should be able to use the matchmaking recommend mode. The seller agents will act on behalf of their users to send KQML messages with the advertise performative to give the name and type of product the seller wishes to sell. Also, the name of the seller will be given as the name of the seller agent. The seller agents will also send in their initial bid to the Matchmaker. The sellers need to send unadvertise messages as soon as the item is no longer up for bid.
The Matchmaker will use JESS for an embedded inference engine and knowledge base to keep track of who has what products to sell. The Matchmaker will also accept KQML messages from buyers to answer queries about products of interest. Specifically, the Matchmaker has to be able to process messages from and to a buyer containing the following performatives: advertise, recommend-all, recommend-one, reply, ask-if, ask-one, ask-all. If the buyer sends a recommend-one message, the Matchmaker should send the lowest priced product that will satisfy the users query. The Matchmaker should be able to respond to queries using the tell or sorry performatives.
In summary, the Matchmaker must reason about matches between the seller and buyers, or bidders:
Add new items to the knowledge base
Delete sold products
Keep track of bidders
Determine matches between bidders and sellers
Send messages to sellers
The seller agents, buyer agents, and matchmaker agent will all use the same product ontology written in the JESS language. (For extra credit, the DABORAS design team can use XML to construct ontologies but must translate them to JESS). At a minimum, DABORAS must be able to use the following simple, non-relational product ontology constructed using JESS (i.e. these should be asserted into the knowledge base as JESS facts):
(deffacts product-ontology “Valid item types that can be auctioned”
(valid-product-type Antiques) (valid-product-type Art) (valid-product-type Books) (valid-product-type Computers) (valid-product-type Jewelry) (valid-product-type Movies) (valid-product-type Music) (valid-product-type Ticket) (valid-product-type Toys) )
The name of this ontology is product-ontology.
Each item to be sold should be represented as a JESS fact using the deftemplate construct. That is, an item to be sold should be represented using the following deftemplate:
(deftemplate item “An item to be sold or bought”
(slot item-name)
(slot product-type)
(slot owner)
(slot initial-bid (default 0))
(slot description) (type STRING))
The deftemplate for item must be used before items can be defined and used in JESS. For example, a seller can define a handheld computer and a toy train to be sold by declaring the following item fact in JESS:
(deffacts products “An item to be sold or bought”
(item (item-name HandheldPC)
(owner MichaelJordan)
(product-type Computers)
( initial-bid (default 0))
(description “HP Jornada 720”) )
(item (item-name TycoTrain)
(owner JackWelch)
(product-type Toy)
( initial-bid (default 0))
(description “My favorite Tyco choo-choo train”) )
Once the Matchmaker has found a match(es) between the seller and the buyer, it will inform the seller of the items. The seller can then send instant messages in reply to the bid and the buyer can negotiate with the buyer using instant message.
The DABORAS graphical user interface must have or perform the following:
Specify a complete item description to advertise for sale to the facilitator agent.
Convert the item description specified using the GUI to a KQML message.
Send the item advertisement via CORBA in a KQML message to the facilitator agent.
Specify a desired item using a valid product type.
Convert the desired item description specified using the GUI to a KQML message.
Send the desired item description to the facilitator message.
Provide a user interface for a user to type, send, receive, and display messages between two users to negotiate a price.
Provide the seller with the ability to alert the Matchmaker that the item has been sold (i.e. unadvertise).
Must have a scrollable list box that will display the agents that are currently online.
CORBA will be used as the primary mechanism for communicating between seller agents, bidder agents and the facilitator agent (i.e. the matchmaker agent). .NET is also a valid option for this project.
Constructed as software processes residing on a computing device(s).
Must use an object-oriented language for agent implementation.
Each agent must be associated with a name and an IP address.
Must be able to query the name server to list and display all of the currently online agents.
Use IIOP via TCP/IP.
Use the Java 1.3 version of CORBA as the distributed object platform. (Can use newer version.
Each agent must be able to send and receive text, or string, or object KQML messages between itself and the facilitator agent. Message may be passed as XML or distributed object.
Peer to peer messages sent between the seller and buyer (or bidder) using instant messaging does not have to be formatted as KQML messages.
Agent must be able to specify the name/address of the agent(s) to send the message to.
Use KQML as the primary agent communication language.
Be able to parse and extract the following KQML performatives:
tell
ask-if
ask-one
ask-all
advertise
unadvertise
sorry
recommend-one
recommend-all
broadcast
Be able to parse and extract the values for at least the following KQML fields:
:sender
:receiver
:reply-with
:in-reply-to
:language
:ontology
:content
Deadline: April 4, 2001 @ 5:00pm
Submit an electronic copy of the design document via e-mail to TA
Two page minimum
Basic design approach
Describe high level architecture (text and diagram)
Specify distributed object platform and implementation language(s)
Basic GUI description
Must schedule a live 5-minute demo before April 11 with TA to be run on a Windows platform in the CSS labs. Demonstrate how the agent code can be downloaded from your Web page and run successfully.
Provide clear documentation within your source code.
Submit source code with Web page report
Due date: April 11 @ 5:00 pm.
Provide a final report on the design, implementation, and evaluation of your MACS using HTML files.
Include a user manual section that includes a brief and clear explanation on how to load, compile, and run your DABORAS.
Bundle the final report, class files, and source code as a Java jar file.
Send this jar file to TA via e-mail.
The jar file should be extractable and loadable to the class Web page for public display.
Labrou, Y. and Finin, T. 1997. A Proposal for a New KQML Specification, Technical Report, CS-97-03.
JESS, Java Expert System Shell, http://herzberg.ca.sandia.gov/jess/
Java IDL, http://java.sun.com/products/jdk/idl/index.html
Professor Williams reserves the right to adjust these specifications as needed.
A.B. Willliams page
30 GUIDE TO NOTES OVERVIEW MULTISTEP AND DISTRIBUTED PROCESSING
39 DISTRIBUTED BY VERITAS VERITAS MAKES EVERY EFFORT TO
6 DISTRIBUTED BY VERITAS TRUST TEL [263] [4] 794478
Tags: realtime, system, messaging, distributed, online, auction, instant, agentbased