DISTRIBUTED AGENTBASED ONLINE REALTIME AUCTION SYSTEM WITH INSTANT MESSAGING

89590 DISTRIBUTED SYSTEMS WHY DISTRIBUTED SYSTEMS?
!doctype Html html Langenus head meta Charsetutf8script Typetextjavascript(windownreum||(nreum{}))init{privacy{cookiesenabledtrue}ajax{denylist[bamnrdatanet]}distributedtracing{enabledtrue}}(windownreum||(nreum{}))loaderconfig{}! for
1 CS451 INTRODUCTION TO PARALLEL AND DISTRIBUTED COMPUTING

1 FM 92XII GRIB GENERAL REGULARLYDISTRIBUTED INFORMATION IN
13 DISTRIBUTED BY VERITAS VERITAS MAKES EVERY EFFORT TO
15 DISTRIBUTED BY VERITAS VERITAS MAKES EVERY EFFORT TO

Agent-Based Online Auction System

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


1Objective

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).


2Description

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.


3Matchmaker Agent

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:

  1. Add new items to the knowledge base

  2. Delete sold products

  3. Keep track of bidders

  4. Determine matches between bidders and sellers

  5. Send messages to sellers

4Product Ontology

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.


5Item Descriptions

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”) )




6Instant Messaging

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.


7Graphical User Interface (GUI)

The DABORAS graphical user interface must have or perform the following:

  1. Specify a complete item description to advertise for sale to the facilitator agent.

  2. Convert the item description specified using the GUI to a KQML message.

  3. Send the item advertisement via CORBA in a KQML message to the facilitator agent.

  4. Specify a desired item using a valid product type.

  5. Convert the desired item description specified using the GUI to a KQML message.

  6. Send the desired item description to the facilitator message.

  7. Provide a user interface for a user to type, send, receive, and display messages between two users to negotiate a price.

  8. Provide the seller with the ability to alert the Matchmaker that the item has been sold (i.e. unadvertise).

  9. Must have a scrollable list box that will display the agents that are currently online.


8Common Object Request Broker Architecture or .NET

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.

8.1Communication Layer

8.1.1Agents

  1. Constructed as software processes residing on a computing device(s).

  2. Must use an object-oriented language for agent implementation.

  3. Each agent must be associated with a name and an IP address.

  4. Must be able to query the name server to list and display all of the currently online agents.

8.1.2Communication Channel

  1. Use IIOP via TCP/IP.

  2. Use the Java 1.3 version of CORBA as the distributed object platform. (Can use newer version.

8.2Message Layer

8.2.1Message Passing

  1. 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.

  2. Peer to peer messages sent between the seller and buyer (or bidder) using instant messaging does not have to be formatted as KQML messages.

  3. Agent must be able to specify the name/address of the agent(s) to send the message to.

8.2.2Agent Communication Language

  1. Use KQML as the primary agent communication language.

8.2.3KQML Performatives

Be able to parse and extract the following KQML performatives:

  1. tell

  2. ask-if

  3. ask-one

  4. ask-all

  5. advertise

  6. unadvertise

  7. sorry

  8. recommend-one

  9. recommend-all

  10. broadcast


8.2.4KQML Fields

Be able to parse and extract the values for at least the following KQML fields:

  1. :sender

  2. :receiver

  3. :reply-with

  4. :in-reply-to

  5. :language

  6. :ontology

  7. :content


9Deliverables

9.1Design Document

  1. Deadline: April 4, 2001 @ 5:00pm

Submit an electronic copy of the design document via e-mail to TA

  1. Two page minimum

  2. Basic design approach

  3. Describe high level architecture (text and diagram)

  4. Specify distributed object platform and implementation language(s)

  5. Basic GUI description

9.2Software Demo

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.

9.3Source Code

  1. Provide clear documentation within your source code.

  2. Submit source code with Web page report

9.4Web Page Report

  1. Due date: April 11 @ 5:00 pm.

  2. Provide a final report on the design, implementation, and evaluation of your MACS using HTML files.

  3. Include a user manual section that includes a brief and clear explanation on how to load, compile, and run your DABORAS.

  4. Bundle the final report, class files, and source code as a Java jar file.

  5. Send this jar file to TA via e-mail.

  6. The jar file should be extractable and loadable to the class Web page for public display.

10References

11Disclaimer

Professor Williams reserves the right to adjust these specifications as needed.



A.B. Willliams page 5 of 5 3/13/3003


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