AN INTELLIGENT MARKETPLACE - ERNETlcm.csa.iisc.ernet.in/hari/all-publications/research-reports... · His rational thinking and fast grasping power of the students psychic health is

IMAGINE: AN INTELLIGENT

ELECTRONIC MARKETPLACE

A Thesis

Submitted for the Degree of

Wtaster o f Gcience (Engineering)

in the Faculty of Engineering

by

A. RAJAGOPAL

Department of Computer Science and Automation Indian Institute of Science

Bangalore - 560 012

FEBRUARY 2001

Dedicated t o

My Amma and

My Sister, Subhashini

Twinkle, twinkle, l i t t l e s t a r ,

How I wonder who you are.

Then the t r a v ' l l e r i n the l i f e ,

The imagination i n IMAGINE,

Mummy f o r your spark,

I could not see which way t o go,

I f you d id not twinkle so.

When the b laz ing sun i s up, or

When he nothing shines upon,

I know your love i s there ,

For you never shut your care,

Twinkle, twinkle, a l l my l i f e .

Twinkle, twinkle, l i t t l e star,

How I wonder what you are.

I owe you up above the world so high,

For you ever giving love,

With an proud smiling face.

In f ron t of your e t e rna l affect ion,

Do I not fade i n t o insignificance ? !

Your e te rna l tenderness and ever g iv ing love!

How I wonder what you are.

Your perseverance i n caring, . Should it not i n sp i r e me in to

being a source of love, tremendous energy and unmovable f a i t h ? !

Let my l i f e be a sincere e f for t t o l e a r n and prac t ice va lues ,

With compassion and determination.

- A proud son Rajagopal, on a mission in life, that arises from my devotion to my mother

Acknowledgements

No acknowledgments can record my appreciation and my indebtedness for my research

advisor, Prof. Y-Narahari. His unassuming and friendly approach t o students, his worldly-

wise approaches are only a few of the many appealing qualities which made my association

with him an extremely useful and valuable experience to learn from and trans'form myself.

Truly by demonstration, he was not only my research guide, but also a mentor of my life.

I still remember the first time I met him, his advice tha t I need not be stopped by my

little prior knowledge of computer engg. (and my worries about my mistakes in my life). I am grateful to him for introducing me to the best practices in software development (and

life), and to emerging fields of e-business (and good olden principles of life). Many a time

he rose above mere patience when faced with my plain insincerity t o follow his sincere

and golden advices. No words can describe his relentless effort in coming u p with this

thesis (and evolving my concept of life). His dedication in helping each and elvery time

everyone (any time, any place, any where) impresses me into his value system (and the

java-jini way). By effective constructive criticisms a t the right time, in the right way, he

inspires and imbibes values. His rational thinking and fast grasping power of the students

psychic health is a boon for any student t o work with this dynamic personality. I must

say in these two years, I enjoyed the most and learnt the most till now. During this work,

I was blessed to learn that I could choose t o accept the present as t h e best.

I owe an infinite to my parents and for my sister for their love and affection. My father

Appakutty's confidence and dynamism even during my mother's health crisis inspires me

with enthusiasm and determination t o make a sincere effort t o render my service to my

fellow humans. My mother Chellam's ever giving care and love without even thinking of

returns is a quality that demonstrates t o me the power of love. T h e eternal caring nature

of mother inspires t o live life for ideals like peace and compassion and be joy for others

and do whatever little I can do to serve them achieve their dreams of success. It is my

dad's goodwill and mothers blessing t o come up in life tha t is powering my creativity and

quest for the truth, imbibing within me the joy t o explore and invent science and humane

technologies and discover myself; and enjoy the process.

... Acknowledgements 111

My cute sister Subhashini is my symbol of innocence powered with maturity. Each time I think of her, I am filled with joy and happiness. Her sincerity in practicing togetherness and accepting others inspires me into realizing that the way is more important than the goal itself in each and every action including the search for truth. My family is my source of immovable faith and tremendous energy.

No words can describe my gratitude and appreciation for the help rendered by my

relatives during mothers ill health, tha t gave me confidence t o work on this thesis, my work of course being a fraction of what Prof. Narahari (who I consider my close family member) is doing for this thesis. My aunt Anandavalli, uncle KrishnaSwami demonstrating their. affection by their actions, my aunt TamilSelvi is no less in her commitment. Without my

kid cousin Gausika's support, things could not have moved so smoothly during medical emergencies. With cousins holding each other, the strength of ever growihg family is increasing with the latest new born Meghna. Cousin Senthil's great help, the two Ramesh

annas support, kids ChandraKanth and Prajaktha, uncle RajaPandian, uncle Murugan, uncle Thangapandian and aunty, my grandpa and two grandmas are just to name a few of those great family members. Unless I choose to stop listing at this arbitrarily point,

the list will overshoot and the laser printer may run out of toner ink. It is the blessing of nature that IMAGINE is a reality now. I am grateful to nature

as whenever I see the harmony and beauty of amazing and splendid nature, I wonder about the infinite supernatural. T h e day my friend gifted me the book "Work and its Secrets", I started getting inspired with values from Swami Vivekananda. The day I attended the seminar on "Bridging Science to humanity", T have been impressed with

Ramana Maharishi's concept of our illusive perceptions. When I remember of Mahatma Gandhiji I inspired to practice these golden values.

With both tangible and intangible help from many people, this thesis becomes a reality. I thank reviewers of this thesis, and my friends: mathematician Kamesh, land markian Biswas, little hari Dinesh, Sanjay and Kartik for providing valuable feedback on

the thesis. I thank Mrs. Mary Azariah, cheer inducing Shivasankari, selfless Ravi, mature

and caring Raju, Chandrasekar and Sourav providing critical value addition in preparing

this document. With sweet dishes with Raju and Tanuja, and sweet wishes by Dinesh, I am running out of rhyming words t o acknowledge many others.

With a daily corridor smile by the faculty-on-walk put my mood upbeat with har- monious confidence disproving energy conservation theory as the total joy multifolds and spreads. Dr Narahari with his cheerful standard "hello rajagopal", "how axe you" ques-

tions make a upset mind cheer up and reply "I am fine", Dr Srikant, while architecting both software and the department doesn't forget to wish and bless proactively as an software agent, which interests Dr Vijay Chandru powered by a humble energetic wish, Dr

Acknowledgemen t s i v

Srinivas Raghavan, Dr Swami hqanohar, Dr Ramesh just t o name a few people for mak-

ing the department a nice place for a nice corridor walk. I am thankful to all the faculty

members for their support and encouragement. I express my sincere gratitude to all staff'

members of the department for their cheerful help and co-operation a t all times.

My stay a t IISc has been a memorable one with delightful company of numerous loving friends. I find it ap t to be crisp here, because I know that my friends will always forgive

me for any mistakes I do including this random sequence of ordering names and missing

numerous names. Socialist and calm Anand, whom I consider a real source of morale,

confidence and someone t o lean upon; helping and internally sentimental Stalin: well

wishing and ever caring senthil and Velan; selfless, humble and compassionate Rajasekar

and Sashi; remotely wishing Raj Kumar and Yogesh; caring Viji: who rose to heights by lending her cheerful and caring smile even after testing her beyond limits although by my

unintended actions; warmthful Shivi, Kavitha, Komala; the victorious Vijis, the young

sisters KrishnaKala, Madurima, Neela; caring brothers Rajiv, Sudharshan.. the list goes

on endlessly. I t is a great pleasure t o realize how my friends have not only helped me

voluntarily and generously, but also acknowledged my gregarious demands for help that

arose from my assumption of rights over them.

Let me not forget to mention my countless dad's friends for their timely help during

medical emergencjr, and let me pray for sistel Sindhiya, the nurse who I started sponth- neously loving when I noticed her praying for my mother while we were inside a ambulance.

These volunteered and dedicated help gave me the confidence to come back and work on

this thesis.

I feel proud t o be a son of mother India, and thank Govt. of India for actively

supporting this research by scholarship. I t is my duty t o work for India's progress and

contribute myself as an atom towards the achieving the goal of India being a Knowledge

superpower as per the India Vision 2020 project.

Unless I choose to stop listing at this arbitrarily point, I can keep just listing names

who have contributed towards this work and end up typing whole of my lifetime.

I am looking for ways to express my thankfulness those who have helped me. Let me

consider that by taking these commitments and standing by them is one of the ways to express my gratitude. Being blessed with the immovable faith t h a t I can learn to accept

and enjoy any situation and convert any problem as an opportunity t o test myself and learn, Let me make a sincere and conscious effort to remember the lessons I learn and

practice these principles with infinite determination. I consider working with enthusiasm,

with a stand for being love and compassion towards as many fellow human as possible of our world community; and learning t o accept and enjoy challenges; all these thoughts

realized with energetic actions; while continuing to experiment with new values as one of

Acknowledgements v

the ways to express my gratitude. Let me sincerely practice this realization (may be a

fascinating illusion and "IMAGINE"ation), thus letting this work as just the beginning of a whole new realm of possibilities.

I wish to thank the reader of this thesis, for accepting the current form of the thesis and being patient to the verbose description and all those mistakes. We wish the reader is able to grasp the overall idea presented here and use this to create new ideas and

applications. A kind request to the reader : will you please let us know the mistakes in

this work so that we can improve this thesis.

Arise, awake, and stop not till the goal is reached - Swami Vivekananda

Abstract

In recent times, the Internet revolution has spawned numerous innovative enterprises. virtual companies, and electronic markets. Electronic markets (or digital markets) are

scalable web-based platforms for buyers, sellers, marketmakers, and brokers t o carry out business transactions. Over the last two years, there has been a proliferation of such

E-Markets on the web, I n this thesis, we develop an Emarketplace, which we call IMAGINE (Intelligent

Market with AGents and Integrative NEgotiations) t h a t improves upon the existing stat,e-

of-the-art in several non-trivial ways. Ih4AGINE combines the best features of existing E-marketplaces with several innovations. The thesis describes the conceptualization, anal-

ysis, and design of IMAGINE and provides details of implementation of a prototype of

IMAGINE at the Electronic Enterprises Laboratory, Department of Computer Science

and Automation, Indian Institute of Science. IMAGINE is a collaborative, co-operative, intelligent E-Market tha t maximizes the

combined utility value of the all traders involved. IMAGINE has several distinctive feal

tures:

It uses an innovative business model, which is intelligent in the sense of perceiving

the nature of the market and market forces a n d using this market intelligence in

matching buyers with sellers and in determining the prices.

It uses integrative negotiations. which make it attractive for buyers and sellers to

reveal their true business interests and valuations.

A sound and robust software architecture for a web-based implementation using

best practices in object technology.

Implementation of a prototype of IMAGINE has been carried out using leading edge

Internet technologies such as multi-agent technology, Jini, and Javaspaces.

Contents

Acknowledgements ii

Abstract vi

1 INTRODUCTION 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Motivation 1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 &levant Work 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Contributions 4

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Outline of the Thesis 5 . . . . . . . . . . . . . . . . . . . . 1.4.1 Chapter 2: Survey of E-Markets 5

1.4.2 Chapter 3: Business Model of IMAGINE . . . . . . . . . . . . . . . 5 . . . . . . . . . 1.4.3 Chapter 4: Object Oriented Modeling of IMAGINE .5

. . . . . . . . . . . 1.4.4 Chapter 5: Software Architecture of IMAGINE 6 . . . . . . . . . . . . . . 1.4.5 Chapter 6: Implementation of a Prototype 6

. . . . . . . . . . . . . . . . 1.4.6 Chapter 7: Summary and Future Work 6

2 ELECTRONIC MARKETS 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Introduction 7

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Categories of EMarkets 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Benefits of EMarkets 10

. . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Benefits to Businesses 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Benefits to Buyers 10

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3 Benefits to Sellers 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Electronic Brokerage 11

. . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Some Examples of Emarkets 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6 &Markets: Design Issues 14

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.1 Negotiations 14 . . . . . . . . . . . . . . . . . . 2.6.2 Business Model and Business Logic 15

. . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.3 Software Architecture 16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7 Summary 17

3 IMAGINE: BUSINESS MODEL 18 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Introduction 18

3.2 Motivating Factors for the Business Model . . . . . . . . . . . . . . . . . . 19

... CONTENTS ~ 1 1 1

3.2.1 Expectations of Players in the Market . . . . . . . . . . . . . . . . 19 . 3.2.2 Substitutability of Products . . . . . . . . . . . . . . . . . . . . . . 19 3.2.3 Creating Value out of Co-operation between Traders . . . . . . . . 22 3.2.4 Use of Agents and Integrative Negotiations . . . . . . . . . . . . . . 23

3.3 Business Model Description . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.3.1 IMAGINE Market . Dynamics . . . . . . . . . . . . . . . . . . . . . . 26 3.3.2 A Typical Cycle of Transactions in IMAGINE . . . . . . . . . . . . 30 3.3.3 Equilibrium: Existence and Convergence . . . . . . . . . . . . . . . 32

3.4 Conceptual Architecture of IMAGINE . . . . . . . . . . . . . . . . . . . . 32 3.4.1 Elements of IMAGINE . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.4.2 IMAGINE Buyers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.4.3 IMAGINE Sellers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.4.4 IMAGINE Market . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.5 Comparison with Related Market Models . . . . . . . . . . . . . . . . . . . 40 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 MART 40

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.2 Auctions 41 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.3 Priceline.com 41

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.4 Tete-a-Tete 41 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Summary 42

4 IMAGINE: ANALYSIS 43 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.1.1 Software Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2 Requirements Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.2.1 Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.2.2 Interactions during Deployment Phase . . . . . . . . . . . . . . . . 46 4.2.3 Interactions During Operational Phase . . . . . . . . . . . . . . . . 46 4.2.4 Different Views of IMAGINE . . . . . . . . . . . . . . . . . . . . . 46

. . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.5 Use Case Analysis 53 4.3 Domain Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Class Diagram 5'7 4.3.2 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.3.3 Interaction Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5 IMAGINE: SOFTWARE ARCHITECTURE 66 5.1 Agent Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.2 Jini and Javaspace Technology . . . . . . . . . . . . . . . . . . . . . . . . 69

5.2.1 Jini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.2.2 Javaspaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.3 IMAGINE: Architecture and Technology Choice . . . . . . . . . . . . . . . 70 5.3.1 Choice of Jini Technology for Interfacing IM-4GINE with the Envi-

ronment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 . . . 5.3.2 Choice of Javaspaces Architecture for Implementing IMAGINE '73

CONTENTS .. 1s

. . 5.4 Design Patterns in IMAGINE . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 .. 5.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i i

6 IMAGINE: IMPLEMENTATION 78 6.1 Description of Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 6.2 Detailed Design of the Prototype . . . . . . . . . . . . . . . . . . . . . . . 80 6.3 Experimentation with the Prototype . . . . . . . . . . . . . . . . . . . . . 88

7 SUMMARY AND FUTURE WORK 9 0 7.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 7.2 Futurework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

7.2.1 Business Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 7.2.2 Implementation of Business Model . . . . . . . . . . . . . . . . . . 91 7.2.3 Framework for E-Markets . . . . . . . . . . . . . . . . . . . . . . . 92 7.2.4 Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 7.2.5 Interop erability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 7.2.6 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Bibliography 9 2

A UML Notation: A Quick Summary 101

List of Figures

. . . . . . . . . 3.1 Motivation and basis for the IMAGINE market mechanism 20 . . . . . . . . . . . . . . . . . . . . . . 3.2 A setting for the IMAGINE market 24

. . . . . . . . . . . . . . . . . . . . . . . . 3.3 Business activities in IMAGINE 25 . . . . . . . . . . . . . . . . . . . . . . 3.4 Overall business logic of IMAGINE 27

. . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Business logic of a seller agent 28

. . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Business logic of a buyer agent 29 . . . . . . . . . . . 3.7 Conceptual architecture of the IMAGINE marketplace 33

. . . . . . . . . . . 4.1 First level use case diagram for IMAGINE marketplace . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Usecases of Marketmaker actor

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Usecases of Buyer actor

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Usecases of Seller actor . . . . . . . . . . . . . . . . . . . . . 4.5 Domain class diagram for IMAGINE . . . . . . . . . . . . . . . . . . . . . 4.6 Activity diagram for buyer activities

. . . . . . . . . . . 4.7 Sequence diagram to describe interactions in IMAGINE 4.8 Sequence diagram depicting iterative adjustment of prices by a selling agent

. . . . 4.9 Collaboration diagram depicting generic collaboration in IMAGINE 4.10 Collaboration between selling agents to determine price equilibrium . . . .

. . . . . . . . . . . . . . . . . . . . . . 5.1 Software Architecture of IMAGINE 67

. . . . . . . . . . . 6.1 Design of relations between main objects in IMAGINE 81 . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Detailed design of selling agent 82 . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Detailed design of buying agent 83

. . . . . . . . . . . . . 6.4 Implementation of a buying agent by market maker 84 . . . . . . . . . . . . . . . . . . . . . 6.5 Detailed design of counting assistant 85

. . . . . . . . . . . . . . . . 6.6 Component diagram for IMAGINE prototype 86

. . . . . . . . . . . . . . . . 6.7 Deployment diagram for IMAGINE prototype 87

. . . . . . . . . . . . . . . . . . . . . . A.1 Relevant UML Notation (first part) 102 . . . . . . . . . . . . . . . . . . . . A.2 Relevant UML Notation (second part) 103

. . . . . . . . . . . . . . . . . . . . . A . 3 Relevant UML Notation (third part) 104

Chapter 1

INTRODUCTION

1 . Motivation

In recent times, the Internet revolution has spawned numerous innovative enterprises, vir-

tual companies, and electronic markets. Electxonic markets a re scalable web-based plat-

forms for buyers, sellers, marketmakers, and brokers to carry out business transactions.

h'Iany synonyms are in vogue for the phrase electronic ma,rkets: E-markets, eMarkets,

digital markets, electronic marketplaces, Internet marketplaces, and digital marketplaces.

Most often, we use the phrase E-markets or E-marketplaces.

Over the last two years, there has been a proliferation of such EMarkets on the web.

Several examples of these are provided in our survey of E-markets in Chapter 2.

Our interest in this thesis is to create the next generation Emarketplace. Existing

E-marketplaces fall short of expectations on the following counts:

The business model usually favors buyers or sellers or a section of players in the

market and does not encourage the traders Do reveal their true business interests

and valuations

Many existing marketplaces use negotiations based on the popular auctions, which

is a type of distributive negotiation that causes hostility in the market environment

The software architecture of the E-market applications is not as robust as it should

be

The primary motivation for this work comes from the need t o create an E-marketplace

that (1) has a business model which is equally attractive t o all the players; (2) uses

negotiations tha t promote cooperation rather than conflict among participants; and (3) has a software architecture embodying all the desirable attributes such as robustness,

Chapter 1. INTRODUCTION 2

flexibility, extensibility, etc. IMAGINE, the E-market that is originated in this thesis,

fulfills the above aspirations in a sound way. We provide below only tn-o of numerous settings in which such an Emarketplace becomes immediately applicable:

Airlines /Train ticket Reservation

- Consider two buyers X, Y; X is a price sensitive buyer, with equal preferences

across two different flights with slightly different departure timings; and buyer

Y is desperate about a particular departure timing and is willing to pay more for

that particular flight. In the usual e-market business models, it is likely that the

buyer X arrives and buys away the ticket that Y wants at any cost. IMAGINE aims to conquer such resource allocation problems. A two dimensional perfectly

competitive e-market with passengers specifying preferences across ticket fair, and departure timing of the airlines, and determining various airlines prices

dynamically based upon the criticality and scarcity for each airline.

- In a train ticket E-market, when the global welfare of the market can be in-

creased by dynamically adjusting the departure timings of trains, the IMAG- INE mechanism can be used to determine the departure timings of trains and

the prices, such that the combined utility value of all passengers is

0 A Multi-Attribute Business-to-Business (B2B) E-Market

- A simple two dimensional business goods market (with price of the good, and

the delivery period of the good are the two dimensions) where each procuring

firm associating a value to the time-to-deliver the goods. Each industry can

maximize their broad economic goals that includes the value each firm has for

different delivery periods and price of the product and thus effectively matching buyers and sellers.

- A B2B market where value of the product depends upon delivery period of the

product, warranty period, merchant rating. IMAGINE determines the value

of the product based upon the personal value attached by each trader t o each

of these attributes.

Relevant Work

E-markets can certainly be regarded as an influential new development in Ebusiness

[I, 191. Emarkets are scalable web-based platforms for buyers, sellers, and brokers to carry out business transactions. Over the last two years, there has been a proliferation

Cha~ter 1. INTRODUCTION 3

of such E-markets on the web. The usual classification into B-to-C, B-to-B, and C-to-C

applies to E-markets also. B-to-B marketplaces have now come t o play an important role

in the E-Business space.

First generation E-markets concentrated on aggregation of information from underly-

ing electronic catalogs and information aggregation was static, i-e. the E-market gath-

ers the information to create a catalog before the user requests it. Currently, most E- markets carry out dynamic catalog aggregation where information is only gathered af-

ter having received the user request. This is an important capability. Botspot [URL:

http://www.botspot.com] gives a comprehensive listing and overview of E-markets and

shopping assistants. Bargainfinder [ URL: http://bf.cstar.ac.com/bf] of Andersen Con-

sulting is a good example of dynamic gathering of catalog information. Jango [URL:

http://www.jango.com] of Netbot is an electronic broker, which like Bargainfinder, does

dynamic gathering of catalog information. Jango searches for products that meet specified

criteria and displays hits in a table that permits extensive evaluation.

The greatest impact of E-marketplaces is in the B2B sector [31, 341. For example, hretalsite [URL: http://www.metlasite.com] is a B2B neutral market for the metal indus-

try, initiated by steel producers. It offers access to industry news and encourages visitors

to interact with one another in discussion groups and via bulletin boards. It is designed

as an electronic outlet for products and services of participating suppliers. The site offers

secure online transactions, including online auctions. Buyers submit bids for the online

offerings and the sellers subsequently notify them about the success of their bids.

The Media lab at MIT [URL:http://media.mit.edu] has spawned several generations

of E-broker and E-market ideas and systems. These include:

Kasbah [ URL: http://kasbah.media.mit.edu]

0 Tete-a-Tete [URL: http://ecommerce.media.mit.edu/tete-a-tete]

MARI [URL: http://www.media.mit.edu/gtewari/MARI/]

Kasbah [12] is an agent marketplace for buying and selling of goods. Users create autonomous agents to buy and sell goods on their behalf. Buying and selling agents meet and negotiate in the kasbah marketplace. The marketplace facilitates interaction

between the agents and matches up buying agents with selling agents and vice-versa.

Trade happens whenever there is a match between the prices quoted by a matching pair

of buying agent and selling agent. Tete-a-Tete [40] has consumer owned shopping agents

and merchant owned sales agents, which cooperatively negotiate across multiple terms of

a transaction including warranties, delivery times, service contracts, return policies, loan

options, gift services, and other value added services. In MARI (Multi-Attribute Resource


Intermediary) [75], multiple buyers and sellers meet together buy and sell heterogeneous

goods. Each buyer (seller) specifies a set of fixed attributes and a set of flexible attributes

for the product interested and also specifies preferences and utilities in the form of a rich set of functions provided by MARI. T h e MARI marketplace finds a n optimal match between buyers and sellers.

The articles by Tewari and Maes [75] and Maes et a1 [26, 401 describe several market-

places on the web.

Object and component technology is currently the best practice technology for design-

ing and implementing web-based E-commerce applications [37, 47, 48, 4, 5, 36, 64, 571. IMAGINE is also founded on this technology.

1.3 Contributions

In this thesis, we develop an E-marketplace, which we call IMAGINE (Intelligent Slar-

ket with XGents and Integrative NEgotiations) that. improves upon the existing state-

of-the-art in several non-trivial ways. IMAGINE combines the best features of existing

E-marketplaces with several innovations. T h e thesis describes the conceptualization. anal-

ysis, and design of IMAGINE and provides details of implementation of a prototype of Ih4AGINE at the Electronic Enterprises Laboratory, Department of Computer Science

and Automation, Indian Institute of Science. IMAGINE is a collaborative, co-operative, intelligent E-Market t h a t maximizes the

combined utility value (i.e. satisfaction level, welfare) of the all traders involved. IM?IG- INE has several distinctive features:

r It uses an innovative business model, which is intelligent in the sense of perceiling

the nature of the market and market forces and using this market intelligence in matching buyers with sellers and in determining t,he prices. A market transaction

in IMAGINE results in determining the prices based upon market forces, using ideas

from the economics of perfect markets, and matching multiple buyers and sellers.

r It uses integrative negotiations as opposed to distributive negotiations [24, 25,3 ] . In in-

tegrative negotiations, the negotiating parties express their internal true preferences

in a straightforward way to one another.

r IMAGINE is built on the foundation of a sound and robust software architecture

i67, 141 for a web-based implementation using best practices in object technology

[58: 71.


Implementation of a prototype of IMAGINE has been carried out using mobile soft-

ware agents [27, 461 in the technological framework of Jini [72, 163: and Javaspaces

[33l

1.4 Outline of the Thesis

This thesis is organized into seven chapters. Chapter 2 is a state-of-the-art survey of

E-marketplaces. Chapters 3, 4, 5 , and 6 address different facets of the IhIAGINE mar-

ketplace. Chapter 3 is concerned with the formulation of IMAGINE'S business model;

Chapter 4 with the object oriented modeling of IMAGINE; Chapter 5 with IMAGINE'S

software architecture; and Chapter 6 with the implementation of a prototype of IMAG-

INE.

1.4.1 Chapter 2: Survey of E-Markets

In this survey, we first bring out the distinction between traditional marketplaces and

E-marketplaces and present a classification of E-markets along several dimensions. Next

we emphasize the benefits that E-markets bring forth to sellers, buyers, marketmakers,

brokers, and other players. We then briefly describe several B2C, B2B, and experimental

marketplaces on the web, bringing out their distinctive features. We end the survey

by looking at important issues in the design of Emarketplaces, concerning negotiations,

business model, and software architecture. '

1.4.2 Chapter 3: Business Model of IMAGINE

Chapter 3 is devoted to describing the evolution of the business model of IMAGINE. First

we provide the main motivation behind the proposed business model. Next, we describe

the dynamics of the business model with an example of 3 sellers and 10 buyers. We briefly

touch upon issues of price equilibrium and convergence to this price equilibrium. Then we

offer a more detailed description of this business model, by bringing out the roles played

by all the players in this market. Finally, we present a comparison of this business model

with that of related models, such as MART [75] and Tetea-Tete [40].

1.4.3 Chapter 4: Object oriented Modeling of IMAGINE

In Chapter 4, we first provide a detailed account of the requirements analysis of IMAGINE.

To crystallize the requirements specification of IMAGINE, we broke down the require-

ments into those arising from several perspectives of the marketplace. These perspectives


or views are described. UML (Unified Modeling Language) [8] use case diagrams are pre-

sented tha t capture all the requirements of IlL4GINE. We next present a UML analysis

model of IMAGINE. First we present a domain class diagram and then present UML sequence diagrams and UML collaboration diagrams for important aspects of IMAGINE'S dynamic behavior.

1.4.4 Chapter 5: Software Architecture of IMAGINE

Jini, Agent, and Javaspace technology constitute the foundation of IMAGINE'S software

architecture. We first provide a very brief overview of Jini and Javaspace technology

and then provide a technical justification for choosing these technologies in conjunction with agent technology. We then describe the software architecture of IMAGINE. Finally, we bring out the use of design patterns in coming up with a sound and robust software architecture for IMAGINE.

1.4.5 Chapter 6: Implementation of a Prototype

A prototype of IMAGINE has been implemented at the Electronic Enterprises Laboratory, Department of Computer Science and Automation, Indian Institute of Science. This prototype is first described. Then, we present detailed UML diagrams to bring out cert,ain design decisions for the prototype. Typical experiments conducted with the prototype are

also described.

1.4.6 Chapter 7: Summary and Future Work

After presenting highlights of the research in this thesis, we provide several directions in which this research and product development effort can evolve in the immediate future.

Appendix A provides a quick summary of notation for UML (Unified Modeling Lan-

guage) diagrams [8].

Chapter 2

ELECTRONIC MARKETS

In this chapter, we provide an overview of electronic markets. The synonyms we use

for electronic markets are: E-markets, eMarkets, digital markets, electronic marketplaces,

Internet marketplaces, and digital marketplaces. Most often, we use the phrase E-markets. In this survey, we first bring out the distinction between traditional marketplaces and

E-marketplaces and present a classification of E-markets along several dimensions. Nest,

we emphasize the benefits that E-markets bring forth to sellers, buyers, marketmakers,

brokers, and other players. We then briefly describe several B2C, B2B, and experimental

marketplaces on the web, bringing out their distinctive features. We end the survey

by looking at important issues in the design of E-marketplaces, concerning negotiations,

business model, and software architecture.

Introduction

E-markets can certainly be regarded as an influential new development in E-business

[I, 691. Emarkets are scalable web-based platforms for buyers, sellers, and brokers to carry out business transactions. Over the last two years, there has been a proliferation

of such E-markets on the web. The usual classification into B-to-C, B-to-B, and C-to-C

applies to E-markets also. B-to-B marketplaces have now come to play an important role

in the EBusiness space. Markets play a central role in any economy and facilitate the exchange of informa-

tion, goods, services, and payments. They are intended to create value for buyers, sellers,

and for society at large. Markets have three main functions [4]:matching buyers to sellers; facilitating exchange of information, goods, services, and payments associated with

a market transaction; and providing an institutional infrastructure, such as a legal and

regulatory framework that enables efficient functioning of the market. Internet-based

Chapter 2. ELECTRONIC MARKETS 8

E-markets leverage information technology t o perform these functions with increased ef-

fectiveness and reduced transaction costs, leading to more efficient, friction-free market,^.

The following are examples of E-markets:

Firefly Network URL: http://wuw.firefly.com

BargainFinder URL: http://bf.cstar.ac.com/bf

Jango URL: http://www.jango.com Kasbah URL: http : //kasbah .media .mit . edu

Auct ionBot URL: http://auction.eecs.umich.edu

Fishmarket IJRL: http: //www. iiia-csic .es/Proj ects/f ishmarket/

newindex. html

Onsale URL: http://www.ebay.com/au f airMarket URL: http://www.fairmarket.com

Priceline URL: http://www.priceline.com

Tete-a-Tete URL: http : //ecomrnerce .media . m i t . edu/tete-a-tete MRO URL: http://www.mro.com

Chemdex URL: http://www.chemdex.com

Chemcomect URL: http://www.chemconnect.com

Ebizchem URL: http://www.ebizchem.com

Plastics Net URL: http://www.plasticsnet.com

CapacityWeb URL: http: //uww. capacityweb. corn

Steel Exchange URL: http://mw-e-steel.com

Paper Exchange URL http : //wvv. paperexchange. com

Energy Exchange URL http://wvv.altraenergy.com

Automotive Exchange URL http: //www. covisint .com

MAR1 Emarketplace URL http://wvv.media.mit.edu/gtewari/MARI/

Frictionless Valueshopper http://compare.frictionless.com

MySimon Buyers Guide URL http : //um .mysimon. com/consumer,resources/ Buyers,Guides/index.html

Elance URL http: //m. elance . corn

Trading Dynamics URL http: //m. tradingdynamics . corn

From an economic perspective, E-markets have certain fundamental differences t o

traditional markets:

0 Transparency: Market transparency is the ability of market participants to observe

the information in the trading process. Emarkets can be completely transparent

due to low marginal search costs.

Chapter 2. ELECTRONIC MARICETS 9

Size: E-markets are not confined to regional borders and are truly global. This con-

tributes to marked increase in the number of potential trade partners in comparison

to traditional markets.

Cost: Due to cost-effective nature of Internet transactions, the transaction costs for advertising, searching for trade partners, and subsequent coordination are typically

very low.

Categories of E-Markets

Based on focus, an E-market can b e horizontal or vertical [31]. Based on access, an

E-market can be private or public [31]. Based on the nature of purchasing (systematic sourcing or spot purchasing), it will be called an E-hub or an exchange [34].

Horizontal E-markets are organized around a non-industry specific large buyer that

offers procurement services to its customers based on its supplier relationships. It is

typically focused on nonproduction goods and services, for example corporate real estate

services, MRO (ma,intenance, repair, and operating) services, etc.

Vertical E-markets are organized around a commodity (for example, plastics, metal,

or pharmaceutical drugs), or industry (for example, retail, trucking, or travel).

Private E-markets are organized around a single buyer or a supplier. They facilitate

a many-to-many collaboration creating virtual commerce networks between a company

and its trading partners, suppliers, and customers.

Public E-markets are open t o many buyers and many suppliers, bringing together

multiple companies in an industry or across a commodity area t o provide a collaborative

network (for example, a consortium of hospitals collaborating with medical suppliers and

pharmaceutical companies).

Companies can either engage in systematic sourcing or spot purchasing. Systematic

sourcing involves negotiated contracts with qualified suppliers. Because the contracts tend

to be long term, the buyers and sellers often develop close relationships. Such E-markets

are called as EHubs [34]. In spot sourcing, the buyer's goal is t o fulfill an immediate

need a t the lowest possible cost. Commodity trading for things like oil, steel, and energy

exemplifies this approach. Spot transactions rarely involve a long-term relationship with

the supplier and in fact, buyers often may not even know who they are buying from. Such

E-markets are usually called on-line exchanges.

Chapter 2. ELECTRONIC - MARKETS

2.3 Benefits of E-Markets

An E-market enables efficiencies by providing a shared, Internet-based infrastructure for

[3 11 :

moving core commerce transactions online to streamline the requisition-to-payment

process (procurement, customer relation management, and selling processes)

delivering a collaborative infrastructure for product design, supply chain planning, and fulfillment processes

0 aggregating industry-wide product information into a common classification and catalog structure

0 enabling online sourcing, negotiations, and other trading processes to enhance buyer

and supplier interactions and overall market transparency

creating an online community for publishing and exchanging industry news, infor-

mation, and events.

2.3.1 Benefits to Businesses

E-markets extend the presence and reach of a company, by facilitating doing business

with anyone, anytime, anywhere. Aggregation of content and facilitation of workflow lead to significant reduction in transaction costs. Cycle times are reduced and deliveries are quicker. All this improves relationship with trading partners. Participating in a

community of buyers and suppliers leads t o market efficiencies, through better inventory

management and better visibility leading to predictability.

2.3.2 Benefits to Buyers

Aggregation of multiple suppliers reduces selection costs for the buyers. Buyers can capitalize on market opportunities through direct access to suppliers and through dynamic

pricing. Location and tracking of new suppliers is much easier. The web also provides . more negotiating power, ensuring that the best available price can always be obtained, More efficient supply chain processes speed time-to-market and allow buyers to act more quickly on new opportunities.


2.3.3 Benefits to Sellers

For sellers, an E-market provides reach to vast, untapped global markets. True value

of products can be realized through aggregation and participation of buyers in the ne-

gotiations. Market intelligence data will enable better prediction of customer needs and

efficient planning. Suppliers can overcome manufacturing inefficiencies through the ability

to support just-in-time inventory practices.

Electronic Brokerage

Electronic brokerage is a key enabling concept for E-markets. An E-market is essentially

an intermediary or between buyers and sellers. An E-market allows buyers and sellers

to be more focused in dealing with information about buying and selling. Searching for

products, privacy requirements, information access, contract risk, and pricing are better

managed with the help of an E-market. An electronic broker or E-market provides the

following services to buyers and sellers [4]:

I. Cost and time savings in searching for products and services. In a disintermediated

market with m buyers and n sellers, we would need m*n connections/transactions

to achieve full-scale access to information. The presence of a broker will reduce the

connections/transactions to m+n.

2. An E-market can offer a complete selection of offers and qualified information about,

products. When a user wishes t o exercise her own choice, the broker can collect more

information from other sources.

3. An Emarke t leads to better pricing when the market has better knowledge of what

a customer might be willing to pay for specific services. The consolidating capability

of the broker can lead to better bargaining positions for the customers.

4. The broker can distribute responsibility to all parties and minimize bad transactions by selecting the best providers and avoiding bad customers. This improves the

reliaibility of the system and leads to increased confidence levels of customers to

transact business.

5 . The broker can effectively ensure privacy of information when the buyer or the seller

or both wish to remain anonymous.


2.5 Some Examples of E-markets

First generation E-markets concentrated on aggregation of information from underlying electronic catalogs and information aggregation was static, i.e. the E-market gathers

the information to create a catalog before the user requests it. Currently. most E- markets carry out dynamic catalog aggregation where information is only gathered after having received the user request. This is an important capability. Botspot [URL: http://www.botspot.com] gives a comprehensive listing and overview of E-markets and

shopping assistants.

Bargainfinder [ URL: http: //bf.cstar.ac.com/bf] of Andersen Consulting is a good example of dynamic gathering of catalog information. I t was a pioneer shopping agent

for online price comparison. It requests an item's price from each of nine merchant web

sites using the request received from the consumer's web browser.

Jango [URL: http://www.jango.com] of Netbot is an electronic broker, which like Bar- gainfinder, does dynamic gathering of catalog information. Jango searches for products that meet specified criteria and displays hits in a table that permits extensive evaluation.

Clicking a n attribute there sorts the alternatives according t o that attribute, enabling an elimination by aspect approach. Hyperlinks display additional attributes and enable

more extensive evaluation within alternatives for a chosen alternative. Jango is now an

integral part of the Excite search engine.

Carpoint [URL: http://carpoint.msn.com] is a Microsoft E-broker that provides on-

line decision support in purchase of cars. Carpoint permits evaluation both within and between product alternatives and enables norm setting by using the "blue book", a guide

for used car prices, 'to establish a standard price for a particular model. All available cars for a specified make and model are displayed in a table and can be sorted according t o

several attributes.

Metalsite [URL: http://www.metalsite.com] is a B2B neutral market for the metal

industry, initiated by steel producers. I t offers access t o industry news and encourages visitors t o interact with one another in discussion groups and via bulletin boards. I t is

designed as an electronic outlet for products and services of participating suppliers. The site offers secure online transactions, including online auctions. Buyers submit bids for the online offerings and the sellers subsequently notify them about the success of their

bids.

NetBuy [UlU: http://www.netbuy.com] offers services for distribution of electronic components. NetBuy is a spot market for non-scheduled orders or unforeseen demands,

requiring immediate delivery. The online catalog of NetBuy features over 300,000 parts

from more than 50 franchised distributors, representing over 1800 manufacturers. It


provides prospective buyers with information about prices and product a~ailability for

items that they commonly procure. It also handles the purchase transactions including

order management, invoicing, and payment.

Ebizchem [URL: http://www.ebizchem.com] is a B2B electronic marketplace in the

area of chemicals. This is the first such &market set up in India. Here, buyers and suppliers post their requirements and engage in trading. -4 rich variety of chemical products

are supported here and several value added services are provided by this E-market for

buyers and sellers.

The Media lab a t MIT [URL:http://media.mit.edu] has spawned several generations

of E-broker and E-market ideas and systems. These include:

Kasbah [ URL: http://kasbah.media.mit.edu]

. Tete-a-Tete [URL: http://ecommerce.media.mit.edu/tete-a-tete]

IIARI [URL: http://www.media.mit.edu/gtewari/MARI/]

Kasbah is described as an agent marketplace for buying and selling of goods. Users

create autonomous agents to buy and sell goods on their behalf. A selling agent is created

to have the following parameters: desired date to sell the item by; desired price: lowest

acceptable price; and a price decay function that describes how the seller is prepared to

lower the expected prices as time progresses. A buying agent will be created with the

following parameters: desired date to buy the item by\-: desired price; highest acceptable

price; and a price raise function, which specifies how the buyer is willing to hike up the

price he is willing to pay as time progresses. Buying and selling agents meet and negotiate

in the kasbah marketplace. The marketplace facilitates interaction between the agents and

matches up buying agents with selling agents and vice-versa. Trade happens whenever

there is a match between the prices quoted by a matching pair of buying agent and selling

agent. Tete-a-Tete has consumer owned shopping agents and merchant owned sales agents.

which cooperatively negotiate across multiple terms of a transaction including warranties:

delivery times, service contracts, return policies, loan options, gift services, and other value

added services. Tete-a-Tete uses integrative negotiations called bilateral argumentation

. and considers product features and merchant features equally throughout the negotiations

to help the shopper simultaneously determine what to buy and who to buy from. The

integration of product and merchant brokering through integrative negotiations leads to

the benefit tha t constraints on product features can affect the decision of who to buy

from. Likewise, constraints on merchant features can affect the decision on what t o buy.

C h a ~ ter 2. ELECTRONIC MARKETS 14

In MARI (Multi-Attribute Resource Intermediary), multiple buyers and sellers meet

together buy and sell heterogeneous goods. Each buyer (seller) specifies a set of fixed

attributes and a set of flexible attributes for the product interested and also specifies

preferences and utilities in the form of a rich set of functions provided by MARI. The

M-ARI marketplace finds an optimal match between buyers and sellers, optimal in the

sense of maximizing an objective function that captures in a balanced way the satisfaction

levels of all buyers and all sellers. The matching algorithm turns out to be a linear

programming formulation.

Several other examples of E-markets and business models used in such applications

can be found in [5, 6, 13, 15, 26, 62, 63, 73, 74, 841.

E-Markets: Design Issues

Our interest is in creating the next generation E-marketplaces. In designing such systems,

t,here are many conceptual and technical issues that need t o be addressed. We emphasize

the following issues.

2.6.1 Negotiations

There are six stages in an E-market business process, as suggested by the Consumer

Buying Behavior (CBB) model [24, 251: Need identification, product brokering, merchant

brokering, negotiation, purchase and deliver, and product service and evaluation. The

negotiation stage is about how to determine the terms of the transaction. In traditional

markets, price and other aspects of trade are often fixed leaving no room for negotiation.

In E-markets, price is often the only issue for trade to happen. There are several on-line

shopping assistants that compare products through pricing information. Negotiations

are a very critical component in the Emarket process. Raiffa [55] has written a classical

treatise on negotiations. More recently, several articles have surveyed the state of practice

in this area [3, 24, 25, 39, 351.

Negotiations are of two types: distributive and integrative. Distributive negotiation is

the process of resolving a conflict involving two or more parties over a single mutually

exclusive goal. The benefit of dynamically negotiating a price for a product instead of

fixing it is that i t relieves the seller from the burden of determining the value of a good a

priori. By pushing this task to the marketplace itself, the benefit is that limited resources

are allocated fairly, i.e. to those buyers who value them most. Distributive negotiations

are very common in: stock markets, auction houses, flower auctions, etc. Software agents

can be taught distributive negotiation skills to help automate negotiations.

Chapter 2. ELECTRONIC MARKETS

Though traditional auctions are very popular and commonly used in several E-market,s.

they have certain hostile characteristics [25]. For example, first price open cry auction and

the Yankee auction, which are two of the most popularly employed mechanisms, have the

disa,dvantage that determining the optimal bidding strategy is non-trivial and moreover

financially adverse. In fact, in first price open cry auctions, the winning bid is known to be always greater than the product's market valuation (this is also known as the Winner's

curse). This is a long-term detriment to customers due to dissatisfaction of paying more

than the value of the product.

Integrative negotiation is the decision-making process of resolving a conflict involving

two or more parties over multiple, interdependent, but non-mutually exclusive goals.Multi-

attribute utility theory forms the foundation of integrative negotiations. From a mer-

chant's perspective, integrative negotiation is about tailoring i t , ~ offerings to each cus-

tomer's individual needs resulting in greater customer satisfaction. From a customer's

perspective, integrative negotiation is about conversing with merchants to help compare

merchant offerings across their full range of value resulting in mutually rewarding and

friction-less shopping experience. IMAGINE, the system originated in this thesis, uses this

type of negotiations. Often decisions have rnuItiple attributes that need to be considered. For esa.mplel

apart from the price of a product, one may be interested in delivery time, quality, after-

sales-service, warranty period, availability of updates, etc. Multi-objective decision anal-

ysis and mult,i-attribute utility theory provide a framework for decision making in such

settings.

2.6.2 Business Model and Business Logic

The business model and the business logic followed by an E-market determine the way

in which buyers and sellers are matched and the prices that t.he buyers will pay to the sellers. The business model is also concerned with how every stakeholder associated with

the E-market (traders, marketmaker, brokers, etc.) makes revenue out of the transactions

occurring in the Gmarket. The business model and logic also determine the structure of

the negotiations that will happen.

Following are some issues addressed by business model and business logic.

What do the buyers reveal to the market? This could include: products they are

interested, the maximum prices they are willing to pay, the most desirable prices

they would like to pay, the functional relationship according to which they are willing

to raise the prices they can pay, other attributes that they would expect from the


products, the degree of importance they would like to attach to these attributes, preferred sellers if they have any, preferred brands if they have any, etc.

e What do the sellers reveal to the market? This could include: products they are

interested in selling, the minimum prices they are willing to accept, the most desirable prices they would expect, the functional relationship according t o which they

are willing to decrease the prices they can offer, other attributes that their products satisfy, preferred buyers if they have any, etc.

0 Based on the information provided by the buyers and sellers, how are buyers matched to sellers? Here, various issues arise:

1. Does the E-market do buyer aggregation (which will make it attractive to buyers)?

2. Does the market do seller aggregation (which will make it attractive to the sellers)?

3. What is the objective function that the E-market optimizes, in finding a match between sellers and buyers?

4. How are the prices of products determined?

5. Are auctions used a t some or all stages of this process?

6. What kind of negotiations are allowed/entailed by the business logic?

2.6.3 Software Architecture

An E-market is ultimately a web-based, software intensive system. It is very important

t o choose a robust software architecture that makes the Emarket scalable, extensible, available, and secure. The architecture will have multiple tiers: client and presentation

tier, web server, application server, database server, etc. Optimal configuration of the software architecture is a very critical issue in the design of Emarkets. Rapid emergence of a plethora of Internet technologies makes this a challenging issue.

There are four major architectural patterns for building Emarket applications [Id]:

Thin Web Client Pattern: Here, the client is merely a forms-capable web browser and all of the business logic is executed on the server (web server and application

server)

0 Thick Web Client Pattern: In this paradigm, an architecturally significant part of

business logic is executed on the client machine

Chapter 2. ELECTRONIC - MARKETS 17

Web Delivery Pattern: The application here uses a distributed object system and

t,he web is used as a delivery mechanism to facilitate interaction among distributed objects

Hybrid Pattern: Most often, an E-market application will require to use a combi- nation of the above three patterns

In choosing the software archit.ecture and the technologies to be used, one needs sound familiarity with the following issues: authentication and security, payment, distributed

objects, components, agents, mobility, ubiquity, scalability, Interoperability: with ex-

isting best practices, with existing business processes, with existing catalogs and other

infrastructure, with ERP software, with the backend, and with other E-markets.

2.7 Summary

In this chapter, we first brought out the distinction between traditional marketplaces and E-marketplaces and presented a classification of Emarkets along several dimensions.

Next we emphasized the benefits that E-markets bring forth t.o sellers, buyers, marketmakers, brokers, and other players. We then described several B2C, B2B, and experiment,al

marketplaces on the web, bringing out their distinctive feat.ures. We also looked int,o im-

portant issues in the design of E-marketplaces, concerning negotiations, business model,

and software architecture.

In the following chapter, we describe the business model of the IMAGINE, the E- market originated in this thesis.

Chapter 3

IMAGINE: BUSINESS MODEL

This chapter is devoted to describing the evolution of the business model of IMAGISE. First we provide the main motivation behind the proposed business model. Next, we

describe the dynamics of the business model with an example of 3 sellers and 10 buyers.

We briefly touch upon issues of price equilibrium and convergence to this price equilibrium.

Then we offer a more detailed description of this business model, by bringing out t,he roles

played by all the players in this market. Finally, we present a comparison of this business model with that of related models, such as MAR1 [75] and Tete-a-Tete [40].

3.1 Introduction

IMAGINE is a co-operative, intelligent E-market which maximizes the combined utility

value of all traders involved. Initially all traders (buyers and sellers) announce their

true business interest in their participation in the market. The buyers disclose their relative preferences across various products, merchants, and prices. These are essentially

the expectations of the buyers from a market transaction and together form the value function of the buyers. The sellers reveal their profit functions which take the form of a

reserve price (least price they expect) and the number of units to be sold. The IMAGIYE business model assumes that the products are substitutable, i.e. sellers are competitors

to one another.

Through a series of rounds of negotiations, the market determines a price vector at

which all the sellers just clear the products, i.e. each seller finds a buyer for each of the

units of product that he wants to sell, no less and no more. The price vector is a vector of prices for each of the sellers at which each of their products will be sold.

Chapter 3. IMAGINE: BUSINESS -- - MODEL --

3.2 Motivating Factors for the Business Model

There are a number of factors that have motivated the development of IMAGIHE's business model.

3.2.1 Expectations of Players in the Market

Aspirations about E-marketplaces can be summarized in the following two statements:

0 The Internet will enable all buyers and sellers in a market to know each other's price positions, making possible "a new world of low-friction, low-overhead capitalism, in which market information will be plentiful and transaction costs low and society's resources would be distributed more efficiently (211".

0 "As buyers and sellers do battle in the electronic world, the struggle should result in prices that more closely reflect their true market value" [lo].

Marketmaker's view: Business requirements specified by a visionary net market maker

could read: "we need an intermediary architecture intended as a generalized dynamic pricing platform for the specification and brokering of heterogeneous goods and services based on multiple attributes."

Buyer's view: The desired system should make it possible for the buyers to holistically

and comprehensively specify relative preferences for the attributes of the product, making price just one of a multitude of possible factors influencing decision t o trade, thus helping buyers to focus on values rather than just price.

Seller's view: The desired system should help her determine the price of her product that reflects its true market value.

Market's view: The fundamental goal of the system is to process the knowledge base provided by the market players, and eventually optimize both the individual utility values

of each player and combined utility of all players in the market. All of the factors above have contributed in part to evolve the business model for

IMAGINE. Figure 3.1 articulates the principal motivating factors behind IMAGINE.

3.2.2 Substitutability of Products

IMAGINE provides an opportunity for the market maker to liquidate price dispersion

arising out of product heterogeneity: the value of unmeasured features.

0 For most purposes, a reasonable approach is to consider product heterogeneity a s relating only to the tangible or essential characteristics of the product. These char-

acteristics include differences in the product's physical characteristics or differences

Chapter 3. - IMAGINE: - BUSINESS MODEL

Perfectly Competitive Marketplace

Buyer willing to COI1Sik heterogenous products as substitutes

Tmtable Software (Personal) Agents

elasticites of demand to I agents

Periodic Market Clear Mechanism

Willing to wait before setteling for a deal

I Flexible Trader Mindset 1 Figure 3.1: Motivation and basis for the IMAGINE market mechanism

Chapter 3. IMAGINE: BUSINESS MODEL 2 1

in retailer services that must be consumed with the product (e.g., return polices.

customer service). For instance t.he price of a computer can be expressed as a function of its memory, microprocessor, disk storage and other components. Likewise.

a heterogeneous product like airline ticket can be modeled as a more generic prod-

uct (ticket to travel between two places on a weekend) by grouping products with

specific attributes of price, and arrival and departure timings.

By perceiving products at a more aggregate level or a abstract/generic level with

different attributes makes these heterogeneous products as subst,itutes for each other.

Since merchants differentiate themselves and products, the market for a particular

class of product looks fragmented and small in size, moving away from a perfect

market condition. 'le

By changing our view of heterogeneous products a s substitutes (acknowledging the

fact that they are not perfectly substitutable) the market size increases (large num-

ber of sellers and buyers), thus moving towards a perfect market setting. Viewing

a product more generically like this was difficult till now, because constraints like

high search costs, lack of perfect knowledge about the product,^, lack of normalized

market information discouraged buyers to compare their personal value of similar

products.

In a B2B setting, from the procurement viewpoint, many companies have come to

realize that factors such as quality, timing of deliveries, and customization are often

more important than price alone in determining the overall value provided by a. supplier. IMAGINE business model services the procurers to locate the product,

that the firm values higher, while viewing more comprehensively and holistically.

From a supplier's point of view, especially the high quality and innovative suppliers

don't want to be participating in ruthless price based bidding wars [81].

0 IMAGINE encourages merchant differentiation and aims to determine the true mar-

ket value for their products and services. It is important to note that IMAGINE

has almost nothing to say about income distribution or economic justice. In other

words, the price of a product, IMAGINE determines is based upon only its true

market value. For instance, a product with higher levels of customer service, ad-

vertising, longer warranty periods are likely to be valued higher. Thus IMAGINE market place promises to deliver value to those sellers who differentiate themselves.

IMAGINE also believes in serving all traders in a fair way,.and discourages misrep-

~esentation of business interests by firms, as it becomes unsustainable in the long

run for these firms.

Chapter 3. IMAGINE: BUSINESS MODEL 22

I, The truth about marketplaces: most consumers don't have brand loyalty; they simply have brand preferences. At some price, they'll sacrifice that preference and

switch brands. Most buyers are flexible [77]. IM.4GTNE recognizes this truth by

allowing customers to disclose the price at which they'll trade off their brand pref-

erence - to reveal their personal elasticity curve for a particuIar product.

I, The BuyingAgents capture the value function of each consumer. The buyer es-

presses her expectations, her likes and dislikes. She quantifies her sensitivity and

importance across attributes of the product and merchant (like price, brand, quality,

delivery time period, warranty period). Essentially, she reveals how much they will

be satisfied in case of each possible deal. In essence, the BuyingAgent now contain

this valuation of the buyer for each of various possible deals/market prices. Each

buyer has her personal elasticity curve. She has brand preferences and is sensitive

to price. She will choose to buy a brand based upon her relative preferences across

brands, and the relative prices of various brands, and her weightage to price and

brand. Each buyer discloses her value function to her personal BuyingAgent. The

value function essential encapsulates this information: given a set of substitutable

products and their prices, whether she will choose to buy, and if so which brand will

she choose to buy. The value function tells us how much the buyer (owner) d l be

satisfied in case of each possible deal.

3.2.3 Creating Value out of Co-operation between Traders

IMAGINE is founded on transforming inefficiency arising out of immediately clearing

markets into value: batch clear instead of spontaneous clear; as more resources (larger

solution space) leads to better resource allocation, in turn leading t o better match to be

found, IMAGINE recognizes the value that can be created by increasing the market clears

times. Analogy : While CDA(Continuous double auction) matches buyers and sellers

immediately, a periodic version of double auction instead collects bids over a specified

period of time, then clears the market a t the end of expiration of the bidding interval.

An example: Train ticket reservation marketplace. Consider two Buyers A, B and t-wo

different trains between Chennai and Bangalore departing at times 3.30 pm and 5.30 pm;

A having equal preference across the two trains, B being desperate about the 5.30 pm

train and is willing t o pay more for getting that particular ticket. In case of spot clear

mechanism, it is likely that the seat available in 5.30 train is alloted t o person A. and

missed by person B. By having a wait and clear mechanism and co-operative negotiations,

IMAGINE promotes better resource allocation.


A key distinguishing fact,or of an eBusiness/e-Market model is Customer affiliation

[45]: how much the business model takes side with the customer. i.e. how much the

e-Market helps the customer to determine the best deal for himself or herself.

Competitors need to partner with each other t o provide customer affiliation. If they

are not going to co-operate with each other to build a model with customer affiliation.

and then a third party might emerge and provide a meta-service; which provides customer

affiliation So Businesses need to cooperate with each other to avoid re-intermediation. So

we believe the future of eMarkets as one where sellers cooperate with each other to deliver

value to the consumer and put her in control.

3.2.4 Use of Agents and Integrative Negotiations

The agents interact with each other in a specified way t o determine the equilibrium price

of the market.

An Agent's strategy is specified by the market maker and not by the traders, these

agents behave as honest and trustable traders. IMAGINE agents engage in integrarive negotiation process, a process where the negotiation parties express their internal true preferences in a straight forward way to each other. This is different form the classical multi

agent thinking [35], where the emphasis is on the network software agents [35] providing

decision support and also trying to guess the interests of the other agents and making

an appropriate move, typically using artificial intelligence based upon the history and

earlier responses to elicit the business interests of the other trader. Since the IMAGIXE agents are true and express their Internet preferences accurately, the benefits of a mar-

ketplace with honest agents can be reaped [35]. Here is a intuitive/ philosophical way

of understanding this: negotiations honest and trustable software agents (whose strategy

is being controlled by the central market maker) can converge faster t o a good solution

than a market with human traders who fear t o express their true and exact preferences

to each other, because of the fear of getting exploited by a cunning trader. To illustrate

an example, a consumer in a bargain shop will not openly reveal her desperation to buy

an particular product, because of the possibility tha t the seller may hike its price if her

comes to know about her keen interest over that particular product.

An additional benefit of using agents is that search cost is virtually zero. Unlike

humans, the agents can search and negotiate extensively and iteratively as they do not

have any cost associated with time and resources of the agents is absolute zero. Thus by

processing the business interests of the traders, the IMAGINE system is able t o determine

and allocate globally maximal deals. At this juncture, i t is interesting to note that the

search cost associated in value comparison engines, where humans can look at the neatly


Many selim selling herergeneous products

Flenble buyers: Buyers who have b m d preference A1 same pncq they'll sanifice that p r e f m c e and switch brands. 1

Figure 3.2: A setting for the IMAGINE market

formatted results produced by a decision support system: these systems suffer if the price

of the product in question is yet to be determined based upon true market value.

3.3 Business Model Description

Figure 3.2 shows a setting of the IMAGINE market. The diagram shows a typical setting

of the IMAGINE market. To provide an analogy, a simple open cry auction business

model involves one seller and multiple buyers, the IMAGINE business model involves

multiple sellers and multiple buyers. While at an end of an auction business transaction.

a deal is settled between a seller and a winner, a t the end of an IMAGINE interaction

cycle, multiple deals will be settled simultaneously between multiple buyer and multiple

sellers.

Figure 3.3 shows the sequence of activities that happens in the market. Once the

Market Maker starts a new market cycle/transaction (analogy: an auctioneer announcing

an auction), the market starts with buyer and sellers expressing their business interests

to their respective personal agents. Once all these representative agents of the traders

Chauter 3. IMAGINE: BUSINESS MODEL 25

Sellers Buyers

create a new

transaction closed notified

equilibrium pric

1 to enter - I

equilibrium & deals 9

functions 7

Accept h e deals finalizedby the

\

exchange products w

Figure 3.3: Business activities in IMAGINE

Chapter 3. -- IMAGINE: BUSINESS MODEL 26

are launched into the system, the system begins to run the optimization algorithm. The

system is comes up with market prices based upon the true market value, and a "good"

way of allocating the market resources. Trader may be given a choice to fine-tune their

preferences before t,he system finalizes the deals. At the end of the optimization, the

system allocates the deals between multiple sellers and multiple buyers.

1. Market maker announces a new market cycle. -4 market cycle or a market trans-

action is one full market cycle starting from sellers and buyers expressing t,heir

production and consumption plans respectively and letting the market determine

equilibrium prices and determining the deals and abiding by those deals.

2. Registered seller login and register the inventory they wish to clear in this market

cycle (i.e. IMAGINE business transaction). Sellers express the attributes of the

products and attributes of merchant (like quality of their product, class of product,

and the delivery time period associated with the product, the warranty time period

of the product, and merchant rating, etc.) They also enter the no. of units of the

product and the reserve (minimum) price they are willing to accept.

3. Each buyer expresses his preferences across various attributes of the product and

merchant (like quality , warrant,y period associated with the product, her relative

preferences across various brands, her price sensitivity for each product, her impor-

tance towards delivery period of the product, etc)

4. Market processes the information and optimizes the global value function of the

market.

Figure 3.4 provides a description of the overall business logic of the IMAGINE market.

Figure 3.5 presents a flowchart for the execution logic of a selling agent while Figure 3.6

depicts the logic for a buying agent.

3.3.1 IMAGINE Market Dynamics

The market opens with an arbitrarily selected selling agent announcing a tentative market

price vector. All the buying agents interested in that product will use their utility function

to select one selling agent out of the ones in the vector. The selling agent will then count

the number of buying agents interested in its product and compare it with the number of

units i t wants to sell and accordingly changes its price according to its own function and

then announces the market price vector. The selling agent repeats this process a number

of times till the number of buying agents interested in i t exactly matches with the number

Chapter . 3. IMAGINE: BUSINESS - MODEL

A seller's phase u ) while (price vector hasn't established)

\L Half the Denominator of Currency

J/ equilibrium price has been determined

Figure 3.4: Overall business logic of IMAGINE

Chapter 3. IMAGINE: BUSINESS MODEL

Let the other Seller vary her price. Trigger the next agent to become active, and let me become passive.

v v offer a price (price Vector)

v Find out the demand for this price Vector

wait for some body else to trigger me

Figure 3.5: Business logic of a seller agent

\ 0 > Adjust my price


Decompose the Market Offer into Deals

J/

Value Function

I W, value of this Deal

J /

Choose the Deal with max. value

chosen Deal Deal, my value for this Deal]

Figure 3.6: Business logic of a buyer agent


of units it wants to sell. This selling agent now becomes passive and control passes on

to a next selling agent which again goes through this iterative process to fix its price at which it is able to attract as many buyers as the number of items it wishes to sell. This way, all the selling agents are provided one chance to adjust their prices to match demand with supply. This finishes one round of negotiations. The market carries out a s many rounds of negotiations as are required till the market situation reaches a point where all

the selling agents have exactly the number of buying agents they want and further there

is no more incentive to changing the prices. This is the equilibrium point and the value of the market price vector at this point gives the prices at which the deals are closed.

T h e business model here is based on a price-adjustment process called tatonnement, proposed in 1874 by Leon Walras [78]. In this model, the agents respond to price signals for individual goods. The interactions of the agents is coordinated by a central marketmaker who adjusts the general price levels towards a general balance, announcing a set of interim prices t o elicit responses from the agents. Starting with the first market, the marketmaker

incrementally adjusts the price to balance supply and demand in relationship to all other prices. A change in the price will normally change excess demand in other markets. Next

the marketmaker considers the second market and adjusts its price to clear and so on. At the end of each round, only the last market is guaranteed to be in equilibrium since a change of price in some markets normally destroys the equilibrium established in previous markets. According to Walras, the change in a product's price will have a more significant impact on its excess demand than it will on the change in the prices of other goods and

therefore the prices mill remain closer to general equilibrium than they were before and

converge until all markets clear.

3.3.2 A Typical Cycle of Transactions in IMAGINE

Imagine 10 buyers, each vying to buy one item of a particular type of product offered by three sellers, call them A,B, and C. Seller -4 has an inventory of 3 items of the product;

Seller B has 3 items; and Seller C has 2 items. Assume that initially seller A commences the transactions by announcing an offer of

Rs. 1024 each for the three items that he has. Let us say that the initial offers of sellers B and C are also Rs. 1024 each for the products that they possess. For this offer, the buyer agents will respond based on their parameters. Assume tha t only 2 buying agents came forward with willingness to buy at the offered price of Rs. 1024. Since seller A is looking

for three buyers, he would then have to reduce his price. At any given point of time, a seller raises the price if the number of buyers interested is equal to or greater than the number of products he wishes t o sell. Otherwise, he would decreases the price. Assume

Chapter 3. IMAGINE: --- BUSINESS - MODEL 3 1

that the amount of increment or decrement is exactly half of the previous increment or

decrement, with the first increment or decrement being half the original price. In the current scenario, since A finds only two buyers interested for his offer of b.

1024, will reduce his price to Rs 512 (which is half the original price). Assume that all the

buyers are now interested. Xow seller A would have t o increase the price to find exactly three buyers. So, he may revise his offer to Rs. 768 (which is 512 plus half of 512), at which offer only two buyers may be interested. Now seller A decreases his offer to Rs 640

and may find five buyers interested. So he increases offer to Rs 704 and now he may find three buyers interested. To see whether these three will still b e interested if he hikes the price. seller -4 might increase price to Rs. 736. Only two buyers may now be interested,

so seller A reduces the offer to Rs. 720. Now three buyers may be interested. Seller

-4 now tries the price Rs 728 and finding all three are interested, may hike the price to

Rs. 732 and later to Rs. 734 and finally t o Rs 735. Beyond this point, the increment or decrement will be less than one rupee and let us assume tha t the stopping criterion is met when this happens (that is, next increment or decrement is less than a Rupee). With

this, seller A completes a round of negotiations. We will represent this as (A "*" against

a seller indicates that the buyers are not bidding for the said seller in this round):

147th B, the following might happen:

With seller C, the situation, might be as follows:


At the end of the above three rounds (call these three rounds as a cycle, the price vector for

A, B, C. will be: (A:735:3 units, B:543:3 units, C:1407:2 units) and thus the market can lw ( . I ~ f i i l . d . However, this is not necessarily the equilibrium price so a cycle of negotiations

will happen during which A, B, and C will make fresh offers as above. The price vector

at the end of the second round may be: (A:780:3 units, B:520:3 units; C:1500:2 units). This sequence of cycles of negotiations continues until there is practically no change in

the price vector from the previous cycle to the present one. Such a price vector is called the equilibrium price vector. The social welfare of the market is maximum at this price

vector.

3.3.3 Equilibrium: Existence and Convergence

In general, there could be situations in which no equilibrium exists or the price adjust-

ment process fails to converge. These are called market failures. Failure to converge is

a consequence of the allocation process or the price adjustment process. Non-existence of equilibrium is a problem arising from the formulation of the problem as a price sys-

tem. For example, basic models of equilibrium theory assume continuous, convex. and

strongly monotone demand functions. When these conditions are violated, the existence

of equilibrium is no longer guaranteed.

It is beyond the scope of this thesis to examine deeply the technical issues of existence

of equilibrium or guarantees on convergence to equilibrium if one exists. Under certain strong assumptions such as each buyer demanding only one product and all products

offered being substitutable, there is strong evidence to suggest that not only equilibrium exists but convergence to this equilibrium is also guaranteed 1791. This is corroborated

by numerous experiments conducted with the IMAGINE prototype.

In more general situations, the use of IMAGINE will need to be supported by a

thorough investigation into the above technical issues.

3.4 Conceptual Architecture of IMAGINE

Figure 3.7 shows a conceptual view of IMAGINE. The diagram shows the logical ele-

ments of the market place. The system consists of Buyers and BuyingAgents, sellers and

Chapter -- 3. IMAGINE: BUSINESS MODEL

t Buyer I

Eenterprise i application :*

i IMAGINE System I I I I I I

I I I ~ a r k e t ( ) Ftgn , Offer

Figure 3.7: Conceptual architecture of the IMAGINE marketplace


Selling-Agents, a Market floor for interaction between these agents. The personal Buyin-

gAgents and SellingAgents capture and encapsulate the business interests (the value functions as personal elasticities of demand (for example, the brand-price trade-off) for the buyer and personal elasticity of supply (for example, the no. of units t o produce and sell at a particular profit margin for the seller) of their respective traders. The diagram also shows a open and transparent market floor where these agents interact through.

The situation can be visualized like this: a large group of trustworthy and honest buy-

ers (who know about what exactly they need and the quantitatively trade-off between the

multiple attributes (for example, price, and delivery time period) they desire to maximize) integratively negotiating by replying whether they will choose t o buy an product,, and if

so which particular product,, for a given market situation or a market offer. Note that a market offer is characterized of the prices the seller is willing to offer their products. The central market maker proposes iteratively various market offers t o locate the best market offer by looking at the demand for each market offer.

The IMAGINE system interacts with three type of players:

1. -4 market creator (or market maker) who defines the type of the ma-rket i.e. what. category of products will be traded via this market. For e-g. she could create a B2C car market or a B2B steel market.

2. Multiple sellers who wish to trade their products. A single seller can sell multiple productTypes. For example, Maruti manufacturer may trade various models like

MarutiSOOCC, MarutiZenDelux, MaruthiZenDisel, MaruthiEsteem. Typically the sellers are competitors to each other as they sell substitutable products.

3. Multiple buyers who are interested in the products offered in the market.

3.4.1 Elements of IMAGINE

The IMAGINE system consists of following logical elements:

1. Buyers

2. Sellers

4. SellingAgents


6. Mediator

7. MarketFloor

In the above, buyers and sellers are typically human actors. A11 other elements are logical or software elements.

Buyer

A buyer is a human(in case of B2C situation) or an enterprise (in case of B2B situation) who is interested in buying a unit of a product from a set of substitutable products available in the marketplace.

Product

A product is an indivisible entity from economic point of view. For clarity of communication, we introduce a term called productobject. A product is also called a productobject in Object Oriented notation [58].

ProductType

ProductType is the name for the same set of homogeneous products. A ProductType is also called productclass

Substitutable products

Set of products which are substitutable from typical buyers' point of view. In most industries this is a well known set. For example, in a motorbike market, all brands of motor vehicles with gears like Yamaha-Rx100, HeroHonda-Splendor, Bajaj-Caliber can be considered to be substitutable to each other. Note that the productsObjects are

heterogeneous in nature. Products are substitutable when buyers are flexible enough to buy one product instead of another. Note that the size of the set increases as we increase the number of dimensions that are flexible. For example, by being flexible on the option of two or four wheeled vehicle, the unified market will now contains products from both the two wheeler and four wheeler market.

Seller

An enterprise (e.g, a manufacturer of products or provider of a service) who wishes to determine the value (i.e. price) of its product in the market based upon market forces.


A software agent that encapsulates the knowledge of a buyer who wants to. The buyer

imparts his knowledge about what decision the agent shouId take in every market situa-

tion. For a given market offer, the buying agent will be able to decide whether it is worth

buying any product a t all. If so, which of those products to choose from the substitute set based upon the relative prices of these products. A market offer is composed of a set

of deal offers to choose from. A deal offer is a offer to sell a product at a particular price.

A real world analogy is a large hall where a11 sellers and buyer gather and discuss to arrive

at a consensus on the market prices at which the products and deals will.

A software agent which know the reserve price of the product and the number of units to

clear. From the market algorithm's point of view, all these selling agent's work towards

arriving at the equilibrium price.

3.4.2 IMAGINE Buyers

A buyer essentially wants to buy one or more units of the products from the set of substitutable products. The primary goals of a buyer are:

1. To find a best possible match for her expectations. She wants the product that suits

her the best. (i.e. she wants to maximize her consumer-product fit).

2. She empowers the IMAGINE system/ algorithm to determine the equilibrium price

of the market, and accepts the deal allocated by the system. Please note that, for

the modeled market setting (i-e. single unit requirement of each buying agent and

representation of utility functions in relation t o a common scale here utility), there

is a unique price equilibrium 1791, which is also the globally optimal point.

A buyer specifies the following while registering with IMAGINE:

1. The IMAGINE architecture i s generic to what the buyers specib. The core layer of the system interacts with a BuyingAgent, which in turn interacts with the human

buyer.


2. All that BuyingAgent does is to implement an interface defined by the core of

IMAGINE. The only thing required is that the Buying-Agent should agree wit,h this protocol : for a given Marketpricevector (which is composed of a set of Deals), it

has to return the best Deal. The best Deal among the offered set of Deals is the Deal which the buyer values the most among them. The best Deal in some sense

tells what the buyer will choose, given a set of options. A Deal is an offer of a particular product a t a particular price.

3. How the agent implements this interface is left to the Market maker. The behavior

of the BuyingAgent or what the BuyingAgent captures from the buyer is actually customizable by the market maker. I t is interesting to note that by customizing what

the BuyingAgent captures from the buyer, the business model can be customized.

Buying Agents

The Buyer entrusts the complete responsibility of combing up with the best deal fully to

the BuyingAgent and the IMAGINE system. After the market has achieved equilibrium,

the system allocates a deal to each buyer, and the buyer has to accept the deal and settles to the same.

The detailed design of the IMAGINE prototype allows buyers to update her agent any

time (even while the market is running i.e. when the agents are actively participating).

It is for the market maker to set an appropriate policy to control when she is allowed

to modify and what part of the data the buyer can update, so that the norms of his

tailored business model is respected.

Other Aspects of Buyers

Any buyer can register with the market. Participation of a buyer in the marketplace

begins when she launches a BuyingAgent into the system. The current implementation

allows a new buyer to enter and participate any time into the market. The Agentcontainer

dynamically loads new BuyingAgents on the fly into the system and start running it, and

thus the new agent becomes a part of the already running market algorithm. Again, it

is the responsibility of the market maker to set an appropriate policy in tune with her

business model, t o control when a new buyer can launch a BuyingAgent.

Destroying her BuyingAgent from the marketplace amounts to withdrawing. The current design allows a BuyingAgent t o be destroyed anytime. Again, the market maker

has to set an appropriate polic~.


3.4.3 IMAGINE Sellers

A seller specifies the following details at the least:

1. The reserve price of the product: The seller will not like to sell a t a price lower than this price.

2. The number of units to sell : The seller would like to sell as many units as possible as long as it can sell for a price greater than the reserve price.

3. Description of the product : The seller also specifies various attributed associated

with the product and himself. For example the seller specifies the warranty period

associated with the product, the delivery period of the product, his own merchant rating, etc.

The goals of a seller are to:

determine the value of her product based upon market forces and sell it at that price.

clear off as many units of goods as possible as long as the selling price is higher than reserve price.

Seller Agents

The SellingAgents are part of the market mechanism. The sellers just specify the above mentioned data to the system, and leaves i t to the market mechanism to take over.

The seller empowers the IMAGINE system to come up with the prices of her products. The seller accepts the equilibrium prices determined by the market, and accepts the deals the market determines.

3.4.4 IMAGINE Market

States of the Market

The design allows the system to be one of these states

1. Created: Created but not yet running

2. Running: currently the optimization algorithm is running

3. Optimized: Finished running and determined equilibrium prices and allocated deals


4. Wait: Wait for the next round of iteration to begin. The buyers can adjust the

inputs during this period. The market maker will set policy about the number of iterations.

5. Closed: Sellers and buyers accept allocated deals

Market Forces

The market forces are composed of:

0 the demand for this product in relation to other products i.e. how much the buyer likelprefer this product relative to others. Note tha t the product differentiation and merchant differentiation affects this number. Thus a merchant with a unique product which is attractive to many buyers can continue to have high demand

irrespective of what the other substitutable products.

the supply, i.e. how many units of this product is available

r the replaceable supply i.e the number of units of substitutable products available

the competition i.e. the prices of the substitutable products.

Role of Marketmaker

The marketmaker specifies:

rn The category of the market, e.g. a market for motor vehicles

0 The dimensions of the market: The attributes of the product the seller has t o necessarily specify. These are the dimensions in which buyer have flexibility t o choose from. For example, in a simple two dimensional computer hardware market, each seller must specify the CPU Megahertz and the size of the RAM of the computer. The buyer can have these dimensions of the market as her flexible dimensions. For

example, if a buyer is flexible to the amount of RAM available in the machine, then

size of RAM becomes a flexible attribute for her.

0 The Market Maker can also implement the behavior of BuyingAgents and thus control what the BuyingAgents need to capture from the Buyers. Here are some models each describing what the BuyingAgent a p t n r e s from the Buyer in a market setting where brand and price are flexible attributes of buyers; and price is a flexible

attribute of sellers.


- Model 1: The buyer specifies satisfaction-price graphs for each brand and min-

imum desired satisfaction level. The prototype uses this model.

- Model 2: The buyer specifies her valuations/preferences (as prices) for each

brand available. She doesn't specify her sensitivity across price. This is a

mapping from the factory scheduling economy problem [79].

- Model 3: In another market setting with warranty period, delivery period, and price as flexible attributes for buyers; and price as a flexible attribute for sellers, here is a model: The buyer specifies her sensitiveness to her flexible attributes

except price. This can be in form of satisfaction value - warranty period graph, and satisfaction value - delivery period graph, a weighted average of these

two satisfaction levels depending upon her importance to delivery period and

warranty period; and a specify a minimum desired value.

3.5 Comparison with Related Market Models

Among all the business model available, M.4RI [75] closely resembles IMAGINE. Like

MARI, IMAGINE is an intermediary architecture intended as a generalized platform for.

the specification and brokering of heterogeneous goods and services. MARI and IMAGINE makes it possible for both buyers and sellers alike to more holistically and comprehen-

sively specify relative preferences for the transaction partner, as well as for the attributes

of the product in question, making price just one of a multitude of possible factors influ-

encing the decision to trade. IMAGINE extends MARI by adding dynamic pricing t o the

business model in the sense that the prices of products are determined by market forces

operating in a fullest extent. MARI fixes up deals between various sellers and buyers

by minimizing the difference between expected requirements of the buyers and the at-

tributes(1ike prices, merchant rating) of the goods available. IMAGINE'S business model

goes one step ahead in determining what price should be fixed for each product so that all the sellers and buyer's welfare are maximized. The basic difference between IMAG-

INE and MARI's algorithm here : MARI operates in all 3 phases of a buying process :

product selection(what to buy), merchant selection (whom t o buy from), and negotiation (what price to settle at). MARI suffers in the negotiation phase. In-short, IMAGINE

fundamentally differs from MARI by giving importance to the point that the value of a good is determined by its scarcity and criticality .i.e. by the demand and supply for the

good, and also the relative demand and supply for competing and substitutable goods,


while MAR1 focuses on actually matching buyers and sellers

3.5.2 Auctions

Use of auctions in e-markets is quite widespread[4]. Current generation commercially operating e-markets employ typically three business models in their e-markets: fixed priced catalog model, auction model (single seller and multiple buyers per auction or vice- versa) and exchanges(mu1ti seller, multi buyer for homogeneous goods e.g. stock markets).

In market settings with multiple sellers and buyers with heterogeneous goods, separate auctions are conducted by sellers(procurers), thus causing uncertainty and speculation in

the market. Auctions enable a group of interested buyers to determine the value of a unique prod-

uct. Like auctions where the market forces determine the price of the product, in IMAG- INE the market's forces determines the price vector of the substitutable products available (the prices of the products on sale). While auctions assumes a one seller : many buyers (or vice versa) market setting, IMAGIXE assumes a many seller : many buyer market setting. At the end of an auction, a deal is struck between the seller and a single buyer. At

the end of a IMAGINE transaction, many simultaneous deals are st,oke between multiple buyers and multiple sellers.

Auctions correspond to a distributed negotiation pattern whereas IMAGINE uses integrative negotiations. An excellent comparison of auctions with integrative negotiations can be found in [24, 251. In fact, the discussion contained in these two papers is very relevant to the negotiation model of IMAGINE.

IMAGINE is inspired by the concept of flexible customers from Priceline.com [URL: http://www.priceline.com], i.e. buyers have brand preference and will switch brands if other attributes like the relative prices of the products changes. Like priceline.com, IMAGINE is a demand collection system, collecting demand curves (consumption options). IMAGINE differs from priceline.com in this : IMAGINE not only collects demand

and supply curves, but also does optimization based upon this information.

Tete-a-Tete (now frictionless.com) [24, 251 inspires IMAGINE with the concept of maximizing customer-product fit using multi-attribute decision theory. Tete-a-Tete assumes that the selling prices are static and are determined by the seller a priori. IMAGINE

Chapter --- 3. - - IMAGINE: BUSINESS MODEL 42

differs from Tete-a-Tete in the assumption that the sellers are more interested in revenue

maximization than fixing prices of their product. In other words while Tete-a-Tete assume

tha t sellers will fix the prices, IMAGINE focuses of a broader goal of maximizing sellers revenue based upon the market forces.

3.6 Summary

In this chapter, we described the evolut,ion of the business model of IMAGINE. First we

psesented the main motivation behind the proposed business model. Then we described

the dynamics of the business model with an example. W e then provided a more detailed description of this business model, by bringing out t h e roles played by all the players

in this market. Finally, we presented a comparison of this business model with tha t of

related models.

In the next chapter, we present a n object oriented analysis of the IMAGINE system.

Chapter 4

IMAGINE: ANALYSIS

In this chapter, we first provide a detailed account of the requirements analysis of IMAG- INE. To crystallize the requirements specification of IMAGINE, we broke down the requirements into those arising from several perspectives of the marketplace. These perspectives or views are described. UML (Unified Modeling Language) [8] use case diagrams are

presented that capture all the requirements of IMAGINE. We next present a UML analysis model of IMAGINE. First we present a domain class diagram and then present UML sequence diagrams and UML collaboration diagrams for important aspects of IM-4GINE's dynamic behavior.

4.1 Introduction

Object technology and component-based development constitute a sound paradigm to

economically produce enduring and resilient industrial-strength software systems [7, 58,

37, 661. Object oriented modeling is based on real world concepts and objects lead to an accurate description of real-world processes. The unified modeling language (UML) [8,59, 171 is a visual, highly expressive language for describing the constructs and relationships of a system. More recently, UML has been deployed with great success as a suitable modeling language for web-based applications [14]. By combining the most useful aspects of object oriented methods and extending the notation to cover new aspects of system development, UML provides a comprehensive notation for the full life cycle of Object

oriented development.

Chapter 4. IMAGINE: ANALYSIS 44

4.1.1 Software Process

The Rational Unified Process (RUP) [32] is the recommended software process for object

oriented product development. In designing and building IMAGIXE, we have followed RUP in spirit. The following core workflows were used in the process (see for exa.mple:

Chapter 1 2 of [I71 and [47]).

1. Requirements Analysis to come up with all important use cases, their descriptions,

and use-case diagrams.

2. Domain Analysis to discover all important abstractions for the problem domain

(classes, interfaces, collaborations, and relationships). Develop all relevant struc-

tural and behavioral models (UML structural diagrams and UML behavioral diagrams).

3. Design: This involves architectural design and detailed design. Issues t o be ad-

dressed here are: GUI design; database design; and need for technical classes. De-

sign patterns 1201 can be used here to maximum effect.

4. Implementation and Testing: Some issues to look for here are web enabling and

concurrency of transactions.

V.'h/lL was used est,ensively in all the above workflows above in an iterative way.

4.2 Requirements Analysis

Figure 4.1 shows a first level use case diagram for the IMAGINE marketplace. The

actors/players in the IMAGINE system are Buyer, Sellers, and the MarketMaker. There

are two levels of interaction between the system and these actors, one during deployment

phase and the other during operational phase of the market. The figure shows the uses

cases performed during an operation of the marketplace.

4.2.1 Actors

Traders are the participants in the IMAGINE'S market. Typically in a market for trading,

traders are of two types: sellers and buyers. In a market for B2B commerce, traders are of

two types: procuring organizations and suppliers. In a market for airlines ticket allocation.

traders are passengers and airlines operators. MaxketMaker is neutral authority in the

rnarket.


Truthful re -L'.-"-+; ' 1,, ,

I /

velation of W L ~ plans Each seller reveals her

.ch buyer revenue curves or production c w e 4 4

express exp-ns and true business interests

(from caputre expectations of all traders)

accep\ deal (from @tie)

I

determined by the market Trader business model

Process the information provided by all the traders to determine market prices and tleals that maximizes globa$utility value 4

r e * customer product fit for maximize revenue for each

each buy ex sella

(from optimize) (from optimize)

Figure 4.1 : First level use case diagram for IMAGINE marketplace


4.2.2 Interactions during Deployment Phase

This phase is characterized by deploying the Internet application by the market maker. This phase involves customization of the system, typically involving software development.

The core layer of IMAGINE system provides the strategy for SellingAgents and spec-

ifies an interface for the BuyingAgents. By providing a free pluggable interface for the BuyingAgent, the marketmaker is free to customize the business model effectively.

The Marketmaker provides implementation (i.e the strategy) for the BuyingAgents.

In addition to providing a template of various BuyingAgents, the MarketMaker may

allow the buyers t o customize these BuyingAgents further. Each buyer can choose one

of the implementation from the set of BuyingAgent implementations. It is important to

remember that the s t r a t e 0 of the selling agent is specified by the market maker and not by the seller.

Typically the buyers want to add functionality to the BuyingAgent, that allows the

agent to talk back to its owner's enterprise application. This allows the IMAGINE ma,r-

ketplace to be integrated to participating enterprise application in a elegant way: as the IMAGINE'S marketplace now seamlessly integrate with multiple enterprises application following different wire protocols (like.DCOM/ CORBA7s HOP/ JRMP / HTTP / HTTPS/ private protocol) and application interfaces (like interfaces developed based upon RMI interfaces / COM interfaces / XML-HTTP interfaces).

4.2.3 Interactions During Operational Phase

This phase is a view of the market during its operation.

The seller expresses a few details about their product into this SellingAgent supplied

by the marketmaker. The buyers begin participation by expressing their value functions reflecting their over all economic goals into BuyingAgents and launch them into the virtual marketplace. Every trader collaborates and co-operates with each other to settle at a deal that minimizes difference between her expectation and the resulting deal, for a11 the players

in the market; thus maximizing the combined happiness of the traders (all buyers and all

sellers) participating in the market

4.2.4 Different Views of IMAGINE

While discussing about E-marketplaces and the qualities such a system should possess,

one hears phrases such as: Demand collection system, collaboration, co-operation. neutral market, dynamic pricing for efficient resource allomtion, price equilibrium, globai equilibrium, personal elasticities of demand, vdue-based compasisons, dynamic pricing


for heterogeneous, automated trading, price as a common flexible attribute for both the buyer and the seller, adjust the prices to locate optimal solutions, attributes of the prod-

uct (e.g. brand). These phrases provided a set of features that IMAGINE should possess. However, to crystallize the requirements of IMAGINE, we started in an original way by defining and examining different perspectives from which one can view the system:

1. Structural view: To understand the system by finding out the setting in which the

system needs to fit in.

2. Comparison view: To understand the system through comparisons with relat,ed business models.

3. Objectives view: To understand the purpose and the objectives/ideals intended for building the system.

4. Priorities View: To understand what the factors/aspects the system architect needs

to focus on.

5. Market transactional view: To understand what constitutes a transaction of the system.

6. Customization view: To understand how the system needs to scale across business

needs.

7. Interoperability view: To understand how this component fits in with other services.

8. Technical infrastructure view: To understand the technical requirements of the de-

sired Internet application.

We provide details of these views above and describe how these views led us to the requirements analysis of IMAGINE. And then we present the use case diagrams for IMAGINE.

Structural View

From a structural point of view, the following provides an immediate specification of the market setting:

1. Neutral markets

2. Multiple buyers competing to buy from a set of products in similar category

3. Multiple sellers offering these set of products

4. Buyers have personal elasticity. Buyers have preferences over various products(brands) available, and may switch between brands.


Comparison view

Several comparisons were done with existing state of practice.

Comparison: Extending double auction concept to a heterogeneous market: The

system desired is similar t o a double auction mechanism 1481, the only difference being the products are homogeneous in the doubleauction case, while the required

system needs to support markets that have heterogeneous products, assuming the products are substitutable to some degree.

Comparison: Extending market transaction to perfom optimization: The desired

system differs from the current marketplaces in the sense that a single market transaction cycle should determine deals between multiple buyers and sellers, rather than

t,hrough a sequence of transactions that happens in the current marketplaces. While at the end of a simple open cry auction market transaction, a single seller is associ-

ated with the buyer(s); at the end of the desired market transaction, many simultaneous deals (each between a buyer and a seller) must be settled. This concept

of transaction where many deals are determined by the system allows for number

crunching and optimization to be performed by the system to transform market

inefficiencies into value.

Conlparison: Extending value comparison engines to optimization engines: While the value comparison engines like Tete-a-Tete (frictionless.com) [25] allow a buyer t o

locate a product that closely matchesi her requirements and close a deal instantly;

the desired system should not only enable a individual buyer to locate the best

possible deal, but allow allocating the resources of the market in an efficient way

by enabling co-operation among all the traders of the market, thus enabling every

buyer in the market is able to locate the best possible deal.

Comparison: Extending matching engines to indude dynamic pricing: While cur-

rent buyer and seller matching mechanisms like the MAR1 marketplace [?sf provide an infrastructure for precisely matching buyers and sellers, and maximizing the value

of market transaction (i.e. minimize the combined difference between a buyer's ex-

pectation and the allotted deal), the desired system should be similar as this in

terms of the market setting (i.e. a multidimensional heterogeneous market) and the structure of a transaction (i.e. a transaction is composed of a set of deals being

allocated, thus a single transaction finalizing deals between multiple buyers and sellers simultaneously ) and market's dgorithm (i.e. to determine a optimal match

between buyers and sellers, so that everyone's expectation is met as far as possi-

ble), the only additional factor needed in the desired system is t o support dynamic


pricing. While MARI allows both buyers and sellers to have flexible attributes,

its optimization algorithm (i.e. modeling the matching problem as a minimizing cost flow graph problem) is designed t,o run when there is no attribute, which is

flexible to both the buyer and seller. This constraint does not allow the M.4RI architecture to have price as a common flexible attribute between the buyer and the

seller. In other words, MARI assumes a marketplace where sellers will apriori fix

prices of their products before the market negotiation starts. The desired system

should not have this constraint. In other words, the desired system should allow for an attribute (an attribute that influences decision) to be flexible for both t.he seller and the buyer. One instance is that of the desired system having prices as

a common flexible attribute flexible between buyers and sellers. as in the case of

double auctions.

Objectives View

Our vision was to create a system that closely resembles a perfectly competitive market.

The desired system should be able to work in a competitive market setting and enable the same. As market makers, we extend the concept of perfectly competitive market to work in a heterogeneous environment also. We believe the computational processing

power can be leveraged to realize a perfectly competitive marketplace for heterogeneous

products.

Substitutability: Economics books state that perfect competition requires that the

product of any one seller is exactly the same as the product of any other seller,

i.e. products are homogeneous [4]. Essentially what is n d e d is substitutable

products or replaceable. So we extend the concept t o a heterogeneous market. Also note that in real world, products and merchants differentiate each other and go in

for heterogeneity. Since we have the information about the product's attributes,

and the personal elasticities of demand for each buyer, we will be able to find out

which products are substitutable for each buyer and at what trade-off they become

substitutable.

0 Large number of buyers and d e n : Perfect competition requires each participant in

the market, whether buyer or seller, to be small in relation to the entire market that

the product's price cannot be affected. As price is only one of the factors influencing

the decision to trade, suppliers who differentiate themselves by quality, reliability, merchant's ranking, etc stand to gain and thus register into the rnaket. Buyers

or procurers are able t o find the best the best deal, thus are motivated t o register.

Chapter 4. IMAGINE: ANALYSIS 5 0

Unlike markets requiring manual searches, the automated process of the desired

system reduces search costs and decision costs t o absolute zero, thus delivering

optimal results even when the search space is very large, which is difficult to achieve

with non-agent based marketplaces. And moreover, the number of participating

traders can be increased, by increasing the number of attributes/dimensions of the

marketplace.

0 Perfect competition requires that consumers, firms, and resource owners have per-

fect knowledge of relevant economical and technology data. While in real world

consumers/firms would not like to share/disclose their likes and dislikes because of

the fear of being exploited by a cunning business/firm, we believe consumers will

be willing to express their exact preferences t o a computer system, that guarantees t o protect this private information, and serves by locating optimal deals. Although

some businesses with deep pockets might provide misleading information t o gain advantage of the system, we need to note that they may not be able t o sustain in

the long run.

0 Tt requires that all resources are completely mobile and each resource is able t o enter

or leave the market.

Priorities View

The desired system focuses on these fundamental factors of the market.

Focus on richness: Richness is the depth and detail of information that the business

can give to the customer, as well as the depth and detail of information i t collects

from the customer [18].

0 Focus on reach: Reach is about access and connection. In means how many con-

sumers the business can connect with and how many products it can offer t o those

customers [18].

0 Focus on customer afliliation: Affiliation is about whose interests the business repre-

sents. E-commerce businesses are already tilting their affiliation away from suppliers

towards the consumer. I t is a natural progression for pure navigators (Le. third par-

ties who are not product manufactures) to affiliate with customers. For instance,

frictionless.com (Tete-a-Tete) is a pure navigator who takes the side of the buyers

and helps them to locate the best possible deals. Here is an explanation of how affiliation shifts: When a sales agent sells only one product line, he will push that

Chapter 4. IMAGINE: - ANALYSIS -

as aggressively as he can: he has little choice but to serve as an agent for the product supplier. Give that salesperson the whole universe of alternative products to

offer, and he is much more likely to present them neutrally. Go further and equip

the consumer with all the information she needs to compare sales agents, and the

odds are that the salesperson will try harder to please the consumer than he will to

please any single product supplier. Manufacturers are looking seriously a t alliances

to address the affiliation and reach problems: a group of suppliers may be able to

create a navigator that is more comprehensive and credible than any of its members

[18]. When an eEnterprise works to deliver what the consumer needs, it provides

competitive differentiation over other seller biased players. Thus the desired sysrem

should enable creation of e-Markets where suppliers/manufactures cooperate with

competing manufacturers to deliver value to consumers.

Focus on value creation out of co-operation: As a Net market maker's competitive

strategy is t o affiliate with as many traders as possible, the desired system should

encourage very strong co-operation among sellers as well as buyers t o provide value

to all traders. The ideal system should generate value from the customers' participa-

tion. i.e. Whenever possible, the buyers need to co-operate with each other. Here is

an illustrative example that shows how value is being created out of cooperation be-

tween buyers in a airlines ticket reservation marketplace: Consider two buyers X, Y: buyer X with equal preference across two different flights departing a t different tim-

ings but price sensitive; and the other buyer Y who is desperate about a particular

departure time. If both these buyers bought tickets without co-operation, it is likely

that buyer X would have randomly chosen to buy a ticket on the flight, which buyer

Y is desperate about. On the other hand, if both these buyers co-operate with each

other, buyer Y will get the flight he wanted, while buyer X will be allotted the less

demanded flight and given discounts as he was flexible and accommodative enough

to let other passengers choose their flight. This illustrative example showed how

a cooperation resulted in an optimal resource allocation. Thus the desired system

must enable cooperation between all traders of the markets, and derive value.

While the first two factors seem to be widely available in the currently operational

e-markets [loo, 1011, the other competitive dimensions need to be the selling points of the

desired system.

Dynamic Trading Factors in an E-market

By looking a t the history of markets, Feldman [19] emphasizes t o look at these two

parameters.


1. Frequency of dynamism: Since market prices are a reflection of supply and demands:

good markets reflect the real time supply and demands. Markets that reflect the

real time changes in the supply and demand situat,ions are preferred over static

markets. The desired marketplace should be a good 'mount of dynamism so tha,t

it the market prices reflects the true and real time market value.

2. Unit of currency/ transaction: The smaller the unit of currency in a transaction,

the lesser is the money left in table. The desired market should determine market

prices accurate to the lowest possible price denomination.

Market Transactional View

Requirements of the market transaction are in terms of the deals allocated by the opti-

mization algorithm.

1. Efficiency of the market: The ideal system should achieve globally optimal solutions

or/and Pareto efficient. A solution t o a resource allocation problem is Pareto efficient

if there is no way to make any person better off wit,hout hurting anybody else.

2. Individual utilities of each player: The resource (product) allotted to any buyer

should be the one that provides her maximum value, given the market price. At a given market prices for each resource (product), she should be able get a resource

(product) which will she values the most. In other words, given a set of offers of

deals, she should get the best deal.

The desired system should allow tailoring the application to variations of other new busi-

ness models, allow customiza,tion to various domains. Requirements for customization of

the system:

1. Core layer: The core of the system should allow for customizations and the need to

change the core layer of the system should not arise as we customize the application

to new business models and new domains.

2 . Extensions: The market maker should be able to redesign the non-core layer of the

system and still be able to plug it with the core system. In essence, the design

should allow for novel way of extending the system with as much little effort as

possible.


3. Customization of buying agents: By controlling what the BuyingAgents capture

from the buyer, and behavior of these BuyingAgents, the market maker should be

scale the application to different business needs of the buyers.

Interoperability View

Wote that the required system will be one of the components of the e-market. The required system will be one of the services of the e-market, the other services may be a

search engine, an Internet auction service, catalog management services, etc.

1. Allow for run time discovery: The desired system should expose itself as a service

that is discoverable by other application, and allow for runtime integration. The

system should enable seamless creation of Meta services (services built on top of

services, the equivalence to open source moment in the Internet world).

2. Allow BuyingAgents t o be loaded on the fly: Buyers should be free t o launch new

BuyingAgent/ replace an existing BuyingAgent into the system, even while the

system is active. The system should handle loading/replacing t h e agents as the

system is running, without shutting down the system.

3. User Accessibility via multiple devices: The service should be accessible from mul-

tiple devices, like desktop computers, Java enable Internet appliances like palm top

computers, cellular phones and personal Java devices like Java enabled television

set top boxes. The user should also be able t o switch from one device to another

seamlessly and continue t o interact for the place where he left.

Technical Infrastructure View

Technical requirements:

1. The system should be able to scale as the number of Agents per market transaction

increases.

2. The system should make use of the computational power available in multiple ma-

chines and should scale as we add more number of machines/boxes. The application

should be able t o leverage power of hundreds of machines.

4.2.5 Use Case Analysis

We capture the functionality of the system through the use cases. Firstly we identify the

actors of the system as: Buyers, Sellers, Traders, and Marketmakers.


motor vwhick dealers

Price and brands are - - - - - - - - artributes hat influtnce trade decision in the new

Define attributes of the markets

- - - - - - - - - @1, p2. p3..j prices of

Defmc what is to be detmnincd by gods sold by each manufactures are to be

thcmketmaker

Market maker

Authorisc buyers and sellers

Figure 4.2: Usecases of Marketmaker actor

Secondly we identify the use cases for each of these actors by considering:

1. Functions, the actors requires from the system.

2. Information retrieval/modification in the system (by the actor)

3. Events in the system to which the actor needs to respond / be notified about.

Figures 4.2, 4.3, and 4.4 show, respectively, the use case diagrams for the three main

actors:marketmaker, buyer, and seller. Figure 4.2: During operation of the market, the

Market Maker announces a type of the market type, the dimensions of the market, and

sets (sometimes hardcode into software) the policies of the marketplace. In addition

to operating the market, Market Maker also would be building ways of capturing and

modeling user's personal value function.

Figure 4.3 shows one way in which the buyers input their value functions to her agents.

This implementation of BuyingAgent assumes that the buyer is able to model her value

function as a weighted sum of independent utility functions. At this juncture, we need to

remember the buyer may have others way of entering her value function.

Figure 4.4 shows how a seller registers her products and then can view the market situation as the market evolves.


Registerflogin view the dimensions of the market transaction

enter uni-dbnensional utility function

for weighted average input the minimum desired

valuedsatisfaction level

YamahaModel100 for Rs.39.000: HeroHonda for Rs.45,000; BajajModel 100 for Rs.40,000;

Buyer

Query what product i will gef if any at the current market situation

View the top 7 products that i am likely to all0 ted

1 \(z2“> Fine bane value functions

valuation for these products OPTIONAL use cases may be allowed in

w c<op tional use case>> decrease my reserve value

- - - -_ - - get notified about the h a l results

of the market transaction

I market maker

I I

Congrats, you have won a HeroHonda Model ?7 for Rs.48,000. We have reserved this Deal for you. For details contact Seller Mr Y. 4

Figure 4.3: Usecases of Buyer actor


go into "Bike" section or "computer" section , - , - - - A m&et is a transactim

floor for a class of items Registerdogin

- - - - - - - - - MotorBike, Yamaha Model 100. Wananty period is 8 months.

Reserve price = Rs 10,000/ - - - - - - - - -

Change the number of units of

View market demand function for my

- - - - -

View final market prices vector

1 a - - - - - View the list of buyers who have

been alloted to trade with me

Your buyers an: --.---. ---,please contact them for delivering the order 4

figure 4.4: Usecases of Seller actor


4.3 Domain Analysis

4.3.1 Class Diagram

The information gathered during the construction of the use cases was used to perform

~ b j e c t decomposition and build the object structure of the system. The main steps in

building the class diagram were:

Object identification: The key objects identified were: Market, BuyingAgent, Sell-

ingAgent: UserPreferenceAgent, Product, MarketProductVector, MarketDemand-

Vector.

r Identification of relationships: It was realized that the relationships between major

classes may be classified as follows:

- Generalization

- Dependency

- Aggregation and Composition

r Identification of object attribut,es: We used the following strategies to discover at-

tributes. (I) Information t,o define the object. (2) Information the methods of the

object act on. (3) Information necessary to fulfill the responsibiIities of the object.

Thus we arrive a t the class diagram shown in Figure 4.5. Note from this figure that:

1. T h e SellingAgents work together to det.ermine the market equilibrium prices. The

Selling agents make an offer and elicit the market demand. By iteratively adjusting

its prices, the agent tries to locate a point where every agent has no more incentive

t o adjust its price. The Mediator waits until this point of equilibrium where market

prices between iterations stabilize.

2. BuyingAgent. encapsulates the value function (i.e. preferences or the personal elasticities of demand) of its owner. When the market offers a MarketOffer (i.e. set

of Deals): the agent chooses the best deal by identifying the deal, which has got

maximum value to the buyer.

3. A MarketOffer is a set of Deals. While a Deal is an offer from a Seller, a MarketOffer

is an offer from the market (all the sellers). The MarketOffer represents the possible

set of prices for each product. When a MarketOffer is replied by the BuyingAgents,

it represents one possible way in which deals in a market place can occur.

Chapter 4. IMAGINE: ANALYSIS

4.3.2 Activity Diagram

lye resent an activity diagram for the activities performed by a typical buyer. Figure

4.6 shows the diagram. This diagram shows the typical sequence of activities perfornled

by a buyer. Based upon the business model policy set by the market maker, the buyer be permitted to fine tune her value functions while the market is active.

4.3.3 Interaction Diagrams

A scenario is a sequence of events flowing between actors and the system for some purpose.

T h p order dependent view of how the system is expected to behave when actually used. is

captured by sequence diagrams. We present some of the sequence diagrams pertaining to IlfAGINE (Figures 4.7 and 4.8). Figure 4.7 depicts a a sequence of interactions among

a selling agent, buying agent, market, and mediator. Figure 4.8 is a lower level sequence diagram tha t shows the iterations that a selling agent goes through in adjusting its price

so that i t is able to clear its inventory. Such sequence diagrams can be written down for

all the use cases.

Figure 4.7 shows a market cycle, where all selling agents are provided an opportunity

to adjust their price once. Once a active selling agent finishes adapting its price, it triggers

the next selling agent to become active, and it go to sleep until it is triggered again.

Figure 4.8 shows the miniature transaction that happens between the agents during a Sellers phase. During a Sellers phase, only the prices of one particular product is altered

and adapted. In other words, at any instant, only one selling agent is active. This selling

agent iteratively adjusts its price by proposing offers and eliciting market demand.

A Sellers Phase is composed of many iterations of Sellers Demand Probe. During a

Sellers Demand Probe phase, the market makes an offer and probes the demand for that market situation. Here is an illustrative interaction that happens in a Sellers Demand

Probe. T h e SellingAgent (i.e. representative of the marketmaker's strategy) asks t o

the buying agents: "If the market situation is this: (Product YarnahaModellOO at Rs 44000, Product HeroHondaCaliber at Rs 54790, Product BajajModelX at Rs 46,910).

what would each one of you choose t o buy, if any". Each buying agent replies to this

market offer. The buying agent computes its valuation for each possible deal, and locates

the deal t h a t niaximum value among this set of deals, and chooses to accept that deal.

SO a buying agent internally computes like this: If I buy a YarnahaModellW at Rs 44000.

my satisfaction level is 82.5%, If I buy a HeroHondaCaliber at Rs 54790, my satisfaction level is 59.1%, If I buy a BajajModelX a t Rs 46,910, my satisfaction level is 86.4%. Since

the deal of BajajModelX at Rs 46,910 gives my good amount of satisfaction, which is well

above my mininium desired satisfaction level of 75%, this will be the reply to the market


reveal pasond value functions: - specify pgsonal elasticies of demand u

4 pause (wait till all other buyers enter and

( market determines equilibrium prices)

view msket situation, view top 7 possible deals

pomile deals?

preferences

finalizes deals)

Figure 4.6: Activity diagram for buyer activities


Selling Agent Buying Agent

I 1 I

I 1

I reply what will i buy, g i v d this price vector

I notify the demand for P C I

I I

1

I I I

triggcr the next agent tb become active A

Y I

I >

I I I I

I I

I I I I I I I 1 I I I I I 1 1 I I I

i

identify the bcst deal from the lot

Figure 4.7: Sequence diagram to describe interactions in IMAGINE


I I I I

I I 1 1

Y-'

identify best Deal C -

identify

t

! ,writc(productChosen n) \ -

5- I -

T . I

1 write (Roduct Chosen x)

I I

1 I

I I

I I

I I

I I

I I

I not;fy (~roduct~hosen) : I I

I I

1

. / L

I notify (ProductChoscn) I

> I

I

I I

I I

I I

I I

I 1 I

I I I . I write (DcmandforDeal) !

I I

\ I I

I

I t 1

I I I

T I I t

I I I I

I I I I

1 I I I

I

process Mark&csponrc() I I I I I I

1

I I 1 I

I I 1 I

I I 1 1

I

Figure 4.8: Sequence diagram depicting iterative adjustment of prices by a selling agent


1.5 : Decide whether to iterate (adjust my price) or allow the next sella 2 adjust her prices

Selling Agent l-7

1 f

Figure 4.9: Collaboration diagram depicting generic collaboration in IMAGINE

>

"Given the above market situation, I will accept BajajModelX at Rs 46,910".

Once all the buying agents ha\re replied, the helper does a head count and reports

the demand to the selling agents. The help,er reports like this "Hey selling agents, for

this particular market situation, 23 buyers have chosen to buy YarnahaModellOO at Rs 44000, 46 buyers have chosen to accept the deal of HeroHondaCaliber a t Rs 54790, and

34 buyers have chosen to accept BajajModelX a t Rs 46,910, and 43 other buyers would prefer to buy none."

The currently active selling agent looks a t the demand for her product and adapts it

price and iterates again.

Figures 4.9 and 4.10 depict collaboration diagrams which also show the interactions

among various IMAGINE objects. Figure 4.9 represents a generic collaboration among selling agents, market, mediator, and buying agents. Figure 4.10 shows collaboration

between selling agents to determine price equilibrium. Figure 4.9 basically is another vier

of the interactions discussed in Figure 4.7. The market (selling agents) keeps on adjusting

its prices to locate the point of equilibrium. Typically the market situation be@s by

offering reserve price as market prices, In response to the excess demand (caused by low

market prices), then the selling agents increase their prica. It is interesting to note that

1 : *[until your sup& f-.- equals your-make . 1.32.3.: r ly what

demand] : adjust your A 1 by,&fIXiKm t'~

Price();

prices has stabiized

s l :

SellingAgent

1 . l a o u q e new etgnces

- M ~ ~ ~ ~ :

floor

1 7 2.2 ' notif the z w pdce $or bn : Bu&Agert

Chapter 4. IMAGINE: ANALYSIS

, the market prices increase, buyers drop out.

4.4 Summary

In this chapter, we first provided a detailed account of the requirements analysis of

IMAGINE. To crystallize the requirements specification of IMAGINE, we broke down

the requirements into those arising from several perspectives of the marketplace. These

prspectives or views were described in detail. UML use case diagrams were present,ed

to show all t h e requirements of IMAGINE. We next presented a UML analysis model of

IMAGINE, in the form of a domain class diagram, sequence diagrams, and collaboration

diagrams for important aspects of IMAGINE'S dynamic behavior.

In the following chapter, we set out to develop a design model of IMAGINE. In par-

ticular, we present a robust software architecture for the IMAGINE system, which uses

technologies such as agent technology, Jini, and Javaspaces.

Chapter 4. IMAGIhX: ANALYSIS

: Mediator Selling Agent Selling Agent

idjust your prices till you c l q yJpur goods()

'I I

adjust your pricw till you clear Aur goods()

. I I I I > Has prices stabilized? I I

Figure 4.10: Collaboration between selling agents to determine price equilibrium

Chapter 5

IMAGINE: SOFTWARE ARCHITECTURE


architecture. In this chapter, we first provide a very brief overview of Jini and Javaspace

technology and then provide a technical justification for choosing these technologies in

conjunction with agent technology. We then describe the software architecture of MAG-

INE. Finally, we bring out the use of design patterns in coming up with a sound and

robust software architecture for Ih4.4GINE. A well-designed architecture is the foundation for an extensible and changeable sys-

tem [67, 141. In this phase, we come up with a high level design where subsystems (packages) are defined, including dependencies and communication mechanisms between the packages. Figure 5.1 shows a software architecture for IMAGINE marketplace. The business objects are in the package i i s c . csa . e e l . IMAGINE. Core. The behavior of the BuyingAgent that is implemented by the market maker comes under the package name i i s c - csa. ee l . IMAGINE .MarketMaker. Each buying agent can be talking to the participating' business using any private protocol using t h e connector i i s c . csa . ee l . I M A G I N E .

Traders. The packages hierarchy is:

Chapter 5. IMAGINE: SOFTWARE ARCHITECTURE 67

Businas Objects Package

, , , ---

Selling Agent BuyingAgent

'. 9 .

hanet Technology Objects Packagc

package

I

\,Visualization package

Figure 5.1: Software Architecture of IMAGINE

Chapter 5. IMAGINE: SOFTWAlRE ARCHITECTURE

Some of the external packages are net.jini.space, net.jini.core.lookup, net.jini.core.entry, corn.sun.jini, etc. Note that the dependency between the business objects and the technology objects are limited to iisc.csa.eel.IMAGINE.Core.SpaceAecessor, thus allowing for

the business layer to evolve independently from the technology and vice versa.

5.1 Agent Technology

Mobile agents is an extremely promising technology for realizing the vision of usable distributed systems in widely distributed heterogeneous open networks [27]. Their promise and potential in web-based applications in general and in E-commerce in particular h a ~ e been widely reported [46, 40, 82, 83, 84, 251.

Software agent technologies can be used to automate several of the most time-consuming stages of the buying and selling processes. Software agents are personalized, continuously running, and semiautonomous 11401. They can be used in E-commerce applications in a variety of ways:

r This example is from [403. Suppose a company wants to order paper supplies. It could use agents to monitor the quantity and usage patterns of paper within the company, launching buying agents when supplies are low. Buying agents automat,- ically collect information on vendors and products that may fit the needs of the company, evaluate the various offerings, make a decision on which merchants a,nd products to investigate, negotiate the terms of transactions with these merchants, and finally place orders and make automated payments.

Agents could be used as mediators in Ecommerce. They could be used in product brokering, merchant brokering, and negotiation phases of an &Business system [4O].

A mabile agent is a software agent which is not bound to the system on which it begins execution. It is free to travel among the hosts in the network. Lange and Oshima [46] have listed seven major reasons why mobile agents will be very useful in Ecomrnerce: (1) they reduce network load; (2) they overcome network latency; (3) they encapsulate protocols: (4) they mecute asynchronously and auto~rnously ; (5) they adapt dynamically; (6) they are naturdly heterogeneous; and (7) they are robust, anci fault-tolerant.

Chapter 5. IMAGINE: SOFTWARE ARCHITECTURE 69

IMAGINE leverages agent technology in a very effective way to carry out all the

in the IMAGINE market. This i t does in conjunction with Jini and Javaspace

technology.

5.2 Jini and Javaspace Technology

5.2.1 Jini

J ~ ~ ~ [ T M ] network technology provides a simple infrastructure for delivering services in a neturork and for creating spontaneous interaction between programs that use these services

regardless of their hardware/software implementation. Any kind of network made up of

services (applications, databases, servers, devices, information systems, mobile appliances. storage, printers, etc.) and clients (requesters of services) of those services can be easily

assembled, disassembled, and maintained on the network using Jini Technology. Services

can be added or removed from the network, and new clients can find existing services -

all without administration [72, 161.

Jini has the potential to revolutionize the way we build software. In a sense, Jini signals

a change from a world in which applications are networked (meaning that computers

simply have the ability to talk to one another) into one in which applications join together

to form a true distributed system-a collection of networked components working together. The distinction between networked systems and true distributed systems is an important

one. Simple networked systems have simple communication patterns (usually peer-to-peer

or client/server), and tend to be static, long-lived entities. Distributed systems, on the

other hand, are composed of numerous constituent pieces. Any of these pieces can come

or go without bringing down the whole system, and the system can respond to changes in its environment and its constituency in reliable and predictable ways. In a nutshell, Jini

moves us from a world in which the "system" is the individual networked application, to one in which the "system" is the collection of all these components working together [72].

Jini is a simple set of Java classes and services that allow devices and services to

interact with m h other through the Internet. It is interesting to note that Jini is based upon the concept of mobile agent technology.

JavaSpaces[TM] technology is a simple unified rn&anism for dynamic communication, coordination, and sharing of objects between Java[TM] twhnology-based netwark rq-

sources like clients and servers. In a distributed application, JavaSpaces ke&';aaIw

Chapter 5. IMAGINE: SOFTWARE ARCHITECTURE

as a virtual space between providers and requesters of network resources or objects. This allosls ~articipants in a distributed solution to exchange tasks, requests and information

in the form of Java technology-based objects. JavaSpaces technology provides developers

with the ability to create and store objects with persistence, which allows for process

integrity. JavaSpaces is a Jini service built over Jini Technology.

Tile ~avaSpaces[TM] service specification provides a distributed persistence and object

exchange mechanism for code written in the Java[TM] programming language. Objects

are written in entries that provide a typed grouping of relevant fields. Clients can perform

simple operations on a JavaSpaces service to write new entries, lookup existing entries, and remove entries from the space. Using these tools, you can write systems to store

state, and also write systems that use flow of data t o implement distributed algorithms

and let the JavaSpaces service implement distributed persistence for you.

From the design point of view, JavaSpace is a really simple interface, which allows

remote systems to collaborate via what is essentially a notice board. Java programs place

objects, examine objects, or take objects away from this board. They can also ask to be

notified when the object they're looking for appears on the board 1331.

JavaS paces[TM] technology is a simple, expressive, and powerful tool that eases the burden of creating distributed applicat,ions. Processes are loosely coupled-communicating

and synchronizing their activities using a persistent object store called a space, rather than

through direct communication. This method of coordinating distributed processes leads

to systems that are flexible, scalable, and reliable. While simple, the space-based model is

powerful enough to implement advanced distributed applications-from e-commerce sys-

tems to groupware to heavy-duty parallel computations. Space-based programming also

leverages the Jini[TM] technology's leasing, distributed event, and transaction features, making it suitable for building robust, commercial-quality distributed systems. Javas-

paces provides a necessary ubiquitous, cross-platform framework for distributed computing, emerging as a key technology in this expanding field [33].

IMAGINE: Architecture and Technology Choice

TO consider the architecture choices we made, we need t o look a t the system from two points of view: how the system interfaces to the external world, what goes inside the system, etc. Two views of the IMAGINE system:

The interface td the IMAGINE system: Exposing the IMAGINE market: This view

examines how the system (e-market) appears t o the external actors of the system-

Note that the IMAGINE market is one part of a bigger e-market and needs to talk

Chapter 5. IMAGINE: SOFTWARE ARCHITECTURE 7 1

to rnuhiple enterprises applications.

r Behind the hood: Inside the system: This view deals with how the system is imple-

mented.

nThile Section 5.3.1 analyses the technology needed for interfacing IMAGINE to the

external world, Section 5.3.2 analyses the technology needed for implementing the IM-AG- TYE system.

5.3.1 Choice of Jini Technology for Interfacing IMAGINE with the Envi-

ronment

The following discussion describes an E-market's technology needs and how Jini technology choice enables to fulfill these needs.

E-Market Business Metrics

r Seamless Application Integration: It is important to note that the entities that interact with e-market are not only humans accessing from multiple Internet appli-

ances, but increasingly software application. In future, participating components

inside a network will seamless integrate with a service of another network. For es-

ample, an agent of production planning application of an enterprise will integrate

with a speculation component of an e-market.

Tn the TM.4GTNE architecture. an enterprise can launch mobile Buying Agents into

the IMAGINE'S marketplace. This agent now residing and operating from the

IMAGINE'S system can talk back to its enterprise through any wire protocol and

via any object interfaces. All this can happen so seamlessly.

Enabling Meta-Markets: The concept of Meta-markets, which is a consortium of

markets, unified as a single market dramaticdly improves the efficiency of the marketplace. Markets will federate with each other seamlessly.

IMAGINE exposes itself as an integrateable service, thus enabling creating of bigger and unified meta-markets.

Q Reconfiguration of Senice Partners: An enterprise will need to have the technology and power to reconfigure her partners and collaborators enabling dynamic supply chains. The system needs to dynamically reconfigure the group of participating

applications in its federation.


Since IMAGINE'S interfaces are exposed as Jini interfaces. the IMAGINE markers

federate as dynamically as any other Jini service.

E-Market Technology Megics

Ease of integration with other applications: IMAGINE allows for Buying Agents to

be seamlessly launched into the IMAGINE marketplace and enables these agents to

co-operate with each other.

Protocol dependence: Unlike classical EAT which needs compliance with a particular

protocol like HTTP or IIOP, Jini architecture is the only technology available today

that lets programs use services in a network without knowing anything about the

wire protocol use by the service $21. In IMAGINE architecture, each Buying -Agents

may be talking back to its owner or its owner's enterprises system in any protocol

(any wire protocol and any APT).

* Automatic Runtime federation: Services can discover each other and join and fed-

erate with each other. IMAGITE registers itself a t Jini lookup services, making it

available for discovery by any other application. Once an application discovers the

IMAGINE service, i t can automatically download the IMAGINE service interface

and can dynamically interact with the IMAGINE system.

0 Ease of administration

* Resilience to partial failures/network failures: By running redundant IMAGIKE

e-market services concurrently, clients of IMAGINE marketpIace will experience

absolutely no glitches.

Candidate Technologies

1. N-tier architecture: CORBA/EJB: The component that wants t o integrate with the

hypothetical IMAGINE CORBA component will have t o know about the IMAG-

INE'S services when it was created, a t least to the extent of sharing IDL definitions

IMAGINE marketplace would have evolved in lock step with those applications

it is going to integrate with, because changing the stub or skeleton files requires

changing all the corresponding stub or skeleton files. This requires fairly tight Ievel

of administration.

2. Network-Network Architecture r X M k An architecture in which IMAGINE intec

grates with other enterprise application through XML will result in interactions that

Chapter 5. IMAGINE: SOFTWAFtE ARCHITECTURE 73

are very controlled, and in well-specified ways, since the level of trust bet,ween the IMAGINE network and other network is not very high.

Also exchanging XML documents, which are mere data doesn't go well with true object oriented systems, which believes on encapsulating data inside objects. Mobile agents implemented in the form of Jini entries allow for encapsulation of data, and

reduce complexity, eases development effort. Modeling as mobile agents enables one to provide a near real life object model of the integrated system.

.3. Participant- Participant Architecture: Jini: Jini is the technology of choice when

participants within a network start looking for services not just from other network, but from the participants in other networks as well [72, 161. The IMAGINE marketplace is composed of many participating agent, each representing an enterprise

in a B2B setting. The need for participant-participant interaction might arise. For example, a BuyingAgent (a participant) wants to talk to a specific component in its enterprise.

5.3.2 Choice of Javaspaces Architecture for Implementing IMAGINE

Degree of Object Orientedness

N-tier architectures with CORBGIEJBICOM : This architecture enables us to build

a system, which has 00 software architecture with 00 modules if%]. If an Object

(module) has to be invokabIe by an application in another machine, the Object has

to be wrapped as a CORBA component. In other words, Objects modules inside a component cannot talk to an Object inside another component directly. This is because the Objects model for interaction between COWA components (through

CORBA IDLs) in different from the Objects within a component (through Java Object Model). The use of two Objects Models in a system results in certain dis- advantages, that the system with single Object Model will not have 1661. While CORBA components interact via the interfaces defined in the CORBA IDL, and

EJB beans interact via the Java Remote Interface Object Model, Jini objects interact with each other via the standard Java interfaces.

Moreover CORBA doesn't allow polymorphism over the network, which constraint us from using most of the design pattern over the network-

Chapter 5. IMAGINE: SOFTWARE ARCHITECTURE

Requirement of Scalability of Computation

,AS the IMAGINE marketplace is compute intensive rather than database intensive. we

need an architecture where a group of machines can federate to share the computations. The JavaSpaces computer server distributed design pattern (Chapter 6 of 1331) came in

very handy. Moreover since each BuyingAgent in IMAGINE can be concurrently processing a Market Offer, the computer server design pattern provided a natural wa? to

implement it.

We also needed an architecture that will load balance, as the number of buying agents

is a variable.

As more agents come into the system, the JavaSpaces architecture allows for deploy-

ment of more machines and scales as the number of agents.

Architecture Fitness towards the Analysis Model

The JavaSpace Marketplace distributed design pattern (Chapter 6 of 1331) naturally fits

in with the IMAGINE analysis model. The pattern allows for a transparent marketplace

(the JavaSpaces server) with decentralized agents interacting through the space. Since

other technologies like CORBA/DCOAI doesn't allow polymorphism over the network.

most patterns cannot be applied with these technologies. Implementing the analysis model with an architecture where the selling agents are

represented as stateful EJB beans and BuyingAgents as stateless Beans could have been

done. This way of representing agents as EJB beans would:

restrict the mobility of agents

prevent the agents from spawning threads for making network connection back to

their enterprises.

prevent dynamic Launching of agents as EJB beans into the system

Broadcast Requirement

The analysis model shows the need for a Marketoffer t o be broadcasted t o all Buy-ing.4- gents. The JavaSpaces broadcast distributed design pattern (Chapter 5 of 1331) provided a natural way of implementing this broadcast.

Alternatively we could have used Java Messaging Service (JMS). It is interesting to

note that the communication patterns enabled by s p w architecture enables us to do

nluch more sophisticated communication than t h e simple publish and Subscribe paktern enabled by any messaging service like the JMS.

Chapter 5. IMAGIMC: SOFTWARE ARCHITECTUE

Loosely Coupled Architecture

.AS a JavaSpaces architecture naturally allowed for loose coupling between logical elements

of the IXIAGINE system, the quality of design of this distributed application improved.

Development Effort (Process)

Since the design is loosely coupled, during every iteration of the development process

there was little need to rework the components developed during the previous iterations. Use of Javaspaces distributed design patterns (Chapter 6 of [33]) in IMAGINE reduced

development effort reworking of code between iterations of the software process could be

minimized.

Application Services

Since the distributed component model is same as the Java programming model (i.e.

Java Object model), most of common functionality can be absorbed t o the application

service layer, that is being bought of the shelf. The JavaSpaces server provided by Sun Microsystems assumes responsibility for scalability, transactions, concurrency, atomicity.

By pushing all the functionality to the application service layer, the application logic of TMAGINE becomes simpler and cleaner and easier to develop. It also results in a

more reliable and highly scalable system, as these functionality comes with the JavaSpace serves.

Reliability

Since the JavaSpaces architecture model is loosely coupIed and since all communication

between major logical eIement so IMAGINE occur asynchronously through the JavaSpace,

the TMAGINE architecture is resilient towards applications/networks failures.

5.4 Design Patterns in IMAGINE

Design patterns are simple and elegant solutions to specific, wmrnoniy murring problem in software design [20]. It is well known that design patterns make it easier to reuse suc-

c ~ f u l designs and axhikctures of experienced and profwlond daiigners. The following design patterns axe relevant in the design of IMAGINE.

* Abstract Factory: This is useful for genierating o b j d for different market pot+ cak. Different market protocols require different sets of individual objects to be


created and used together. The use of Abstract Factory automatically enforces this

constraint.

Composite: The bid structure in markets (such as for bundles of products) can often

be complex since it. includes arbitrary combinations of products as part of a bid. If the Composite pattern is used to represent bids, then IMAGINE will be easily

extensible to any type of market mechanism.

0 Decorator: Decorate market object with multiple individual value added services

such as can be provided to sellers and buyers. Buyers and sellers may requisition

these value added services dynamically and the Decorator pattern can be used to addldelete these services at run time.

0 Iterator: To access information from the database about individual trades without knowing the type of the trade. For example, information about a seller transaction

may be stored in one way and information about a buyer transaction may be stored

in a totally different way, but by using the Iterator pattern, it is possible to extract

information without knowing the type of trader whose information is being sought.

Proxy: To provide detailed description of item. Some items in the market may

have complex images, VRML files describing them. These may be loaded only on

demand.

Observer: Automatic generation of services, notifications, etc. when designated

events happen during the negotiation process. The occurrence of such events triggers

the notifications t o be sent to all subscribers to the event.

Stmkgy: Different types of market mechanisms have different ways of determining winners, settling the trade, etc. Strategy can be used in these situations.

The use of the above design patterns lead to a highly extensible design model for IMAG- INE. Apart from the above patterns, three other application patterns form an important

part of the IMAGINE design model. These three patterns: (I) compute server distributed

pattern; (2) marketplace pattern; and (3) broadcast pattern are part of IMAGINE'S design

model as an immediate consequence of using Javaspaces architecture.

The following factors enable a high level of reusability and extensibility of the IMAG- INE design model.

Create objects indirectly and avoid creating and object by explicitly specifying a

class

Chapter 5. IMAGINE: SOFTWARE ARCHITECTURlE 77

Reduce dependence on object representation or implementation by hiding the int.er-

nals from clients

Reduce algorithmic dependencies by isolating algorithms that are likely to change

a Promote loosely coupled classes

e .&void subclassing as a means to extend functionality; use composition inst,ead

a Comprises abstract classes from which application-specific subclasses can be created

to build a particular customized application

a Design reuse and flexibility are important

5.5 Summary


architecture. In this chapter, we first provided an overview of these technologies and then

provided a technical justification for choosing these technologies. We then described the

software architecture of IMAGINE.

The next chapter describes the implementation of a prototype of IMAGIXE.

Chapter 6

IMAGINE: IMPLEMENTATION

.4 prototype of IMAGINE has been implemented a t the Electronic Enterprises Laboratory.

Department of Computer Science and Automation, Indian Institute of Science. This prototype is first described. Then, we present detailed UML diagrams t o bring out certain

design decisions for the prototype. Typical experiments conducted with the prototype are

also described in this chapter.

A wide variety of software and Internet technologies have been used in the building

of the prototype: mobile agents [40, 681; Java technology [TO, 71, 22, 28, 29, 30. 523: Jini

and Javaspaces [16, 331; and distributed objects 142, 50, 421.

6.1 Description of Prototype

Market Setting

Two-dimensional Market: Price and brand are the two dimensions of the market in

the prototype.

Sellers:

I. Seller's products: Each seller is associated with one product category. .A seller can have multiple units of perfectly substitutable products.

2. Price as a flexible dimension: T h e Seller is willing t o sell her product at the

price determined by the system.

3. Each seller gives this information to the marketplace

(a) Product description : Brand name of product

(b) Number of units to sell

Chapter 6. IMAGINE: IMPLEMENTATION

(c) Reserve price: Price below which she would not sell her product.

Buyers:

1. Price and Brand as flexible dimensions: Buyers have price and brand as their flexible attributes. They switch brands based upon their personal elasticity of

demand.

2. Single unit: Each buyer wa.nts to buy a single unit from the set of substitutable products available.

3. Each buyer r e~ea .1~ this information to his Buying4gent: (a) satisfaction-price graph; (b) minimum required satisfaction level

r Business activity of the Prototype:

1. Once all the participating sellers are known, the market is open for buyers to enter.

2. Each buyer launches a BuyingAgent

3. Once all the BuyingAgents are launched, the system runs and locates the equilibrium prices

4. T h e dynamics of the market can be viewed and visualized while the market is running.

5. Once the prices have stabilized to equilibrium, the market maker closes the

market and allocates deals.

a Business Logic Limits of the Prototype:

1. Number of dimensions of the market : The prototype has two dimensions

2. Each buyer can buy only single unit.

3. Types of BuyingAgent running in the market: Although the detailed design

allows each buyer to own different types of BuyingAgents (each with a different way of modeling and capturing the user value function), in the current prototype only one type of BuyingAgent is being used by dl buyers.

4. Sellers are neutral across buyers: The seller is willing t o trade his product without any consideration about identity of the buyer i-e. He considers selling his product between any two buyers as the m e . Sometimes the seller would like to provide service t o a buyer who has good track record, etc. The p r o t o & r n doesn't allow t h i

Chapter 6. IMAGINE: IMPLEMENTATION 8 0

. Technical Limits of the Prototype:

1. Presentation layer: The prototype assumes buyers will directly launch Buyin-

gAgents into the system. So it doesn't p r o ~ i d e any user interface for the traders

to enter their preferences into their agents. The design allows Jini Service UT to handle the human user interface.

2. Container services: In the prototype, container services are not implemented.

3. Scalability: No. Of Jini Entries in the Javaspaces are limited by the scalability

of the reference Javaspaces implementation, provided by Sun Microsystems.

Thus poses a restriction on the number of agents than can participate in system.

Although multiple spaces can be used to tackle this problem. the prototype doesn't implement this. One more way to scale is t o use commercial available

implementations from www-j-spaces.com or www.intamission.com.

4. Currently, the containers don't replace agents on the fly while the agents are participating.

5. Security: Since the market floor is fully transparent, malicious agents can find

out the value functions of other agents. While the design allows for agents to be

encrypted and stored in the space, the prototype doesn't have this functionality.

6. Authenticity: Since the market is transparent, malicious agents can place an impersonated bid. While the design allows for code signing of offers and replies

sent by selling and buying agents, the prototype is yet to implement it.

6.2 Detailed Design of the Prototype

Figure 6.1 describes the main objects in core IMAGINE system. The main elements

are the Agents, which interact with each other by exchanging MarketPriceVector and

Productchosen through the JavaSpace. As we can see most of the dependence is on the Java . pace interface.

Figure 6.2 shows the SeIlingAgent and the objects t h a t it interacts with. The SellingA- gent is a Executable Component, that can be run inside a container. The SellingAgent creates and modifies MarketPriceVector, reads DemmdForDeal to know how many buy-

ers are ready to buy its product at the given Marketpricevector. TSle arketPriceVector

is composed of a set of Deals via a hash table. The hash table helps us t o access an Deal(va1ue of the hash table) by the sellerid. Thus SellingAgent can modify their part of the price vector alone. The SeZlingAgent themselves exchnge TokenEntry via the

J a m p a c e t o trigger each other into active state in a round robin fishion.

Chapter 6. IMAGINE: IMPLEMENTATION 8 1

Deal

1

Figure 6.1: Design of relations between main objects in IMAGINE

Figure 6.3 shows the BuyingAgent and how it interacts with other objects. The

BuyingAgent is composed of an implementation of CustomerProductFitMaximizer which

enables the agent to choose the best deal out of a given set of deals. The CustomerPro-

ductFitMaxirnizer uses two objects, I'alueFunction to determine the value of a deal, and

Validator to find if a buyer would accept/reject a deal. Note that the CustomerProduct-

FitMaximizer can be implemented in many other ways.

Figure 6.4 shows the implementation of the components of a BuyingAgents. Note that

many other ways of implementing the shown interfaces could lead to vari&ions in what

is being captured from the buyer and what how it is modeled and how the best deal is located.

Figure 6.5 shows the helper services of the marketplace. The CountingAssistaat makes a head count of how many buyers are willing to purchase each product. It scans the

market floor(JavaSpace) for a particular chosen ProductEntry and counts the number of

P r ~ d u c t E n t r ~ and create a DemandforDed with the appropriate number of ProBuctEntry.

Figure 6.6 exhibits a component diagram for the IMAGINE prohtype while Figure

6.7 depicts a deployment diagram.

Chapter 6. IMAGINE: IMPLEMENTATION 82

c< entry >>

create and write to spspace".. / I

SclliigAgmt 3

, - agentid: int - sellrrId : in1

I - produci : Dcsaiption - rcssvcPria : inf - numbaONnitsToBcSdd : kt t

+ SclSigAstot(atllaid : String) I

+IUDo:vOid I

+ p l ~ m y ~ : D m o a D d f a d ) c d l ) : m v r r t c r + p~OnTdrCn0 : wid , I

1

I

8 ,

Figure 6.2: Detailed design of s~lling agent


valueOfDeal(mydeal Dul) : double

=====?=

---------.t--- 'I

+ geiSellsld0 : String'., . I

+iseq*:Deal):boo~ I

+ BuymgAgenrpuyend Srnngi

+ m-a Sinngfl, vad IFhecuthle

Figure 6.3: Detailed design of buying agent


+ vdidatc$x: Deal, value : double) : boolcn

I + vllidatc(x : Deal, value : dauble) : boolean [

+ vahrcOfDeal(mydcal: Deal] : double

I

+ SimpleBuyaVducFrmaiooDaraHdd~j + toSning() : Srring + nlueOfDca~deal: Dcal) : b b l e

Figure 6.4: Implementation of a h y & g ageBt by market &er


Deal

lavaspace

Figure 6.5: Detailed design of counting assistant

Chapter - - 6. IMAGINE: IMPLEMENTATION

Figure 6.6: Component diagram for MAGIME prolt~type

~kpter 6. IMAGINE: IMPLEMENTATION 57

Figure 6.7: Deplayment diagram for IMAGINE p t ~ t y p e


6.3 Experimentation with the Prototype

The prototype application was deployed wit.hin the laboratory's 100Mbs network across

multi machine environment (with 3-5 machines). The deployment was done like this across machines with the following run time ern+

ronment:

1) On a Windows NT, 256 MB, PI1 400 Mhz

1 . I ) A JavaSpaces Service

1.2) An HTTP server , which is used t o download code t o JavaSpaces c l i e n t s .

1.3) An RMI Activation Daemon, which talres care of managing the s t a t e s of

se rv ices , f o r instance r e s t a r t i n g crashed se rv i ces , o r deact ivat ing and

r eac t iva t ing serv ices based on whether they ' re being used or not

1 .4) A Lookup Service, which allows c l i e n t s t o look up and f i n d the J i n i

se rv ices tha t are cu r r en t ly available on t h e l o c a l network.

1 .5) A few IMAGINE Buying Agents running i n a I M A G I M E Con-cainer

1.6) The IMAGINE Mediator Visualization Console

2) On a Red Hat Linux 6.2, 256 MB, PI11 600 Mhz, dual processor board

2.1) A few I M A G I N E Buying Agents i n a IHAGIW Container

2.2) A few IMAGINE S e l l i n g Agents in a IMAGINE Container

3) On a machines with Red Hat Linux 6, 128/256 m, PI1 333Mhz

3.1) A few IMAGIME Buying Agents i n a IMAGIWE Container

3 .2) A few IMAGINE Selling Agents in a IHBGIE Container

3 .3) IHAGIE Assis t ing serv ice , the ~ t i p g A s s i a t a n t

The computatian was shared a.cr:ICeSS machines. The experiments mducteri had 2-5

Chapter 6 . IMAGINE: IMPLEMENTATION

buying agents, and 2-3 sellers each trying to sell 1-2 units of good. The typical time taken

to converge was around 1-3 minutes.

The interesting aspect was to note tha t reconfiguration of the run times in various

nodes (i.e. machines) did not involve any effort. New nodes could be added easik to the

already active system and could dynamically share the computation requirement.

Many such experiments were carried out with 111-4GINE prototype implementation

in the Electronic Enterprises Laboratory, Computer Science and Automation. Indian In-

stitute of Science.

Chapter 7

SUMMARY AND FUTURE WORK

In this chapter, we first summarize the main contributions of this work. Next, we offer several suggestions for future research and product development extensions.

7.1 Summary

Our interest in this thesis was t o create the next generation E-marketplace. IMAGINE combines the best features of existing E-marketplaces with several inriot-arions. IMAGTSE is a collaborative. co-operative, intelligent E-Market that maximizes the combined utility value (i.e. satisfaction level, welfare) of the all traders involved. A market transaction in IMAGINE results in determining the prices based upon market forces: using ideas from the economics of perfect maskets, and matching multiple buyers and sellers. IMAGINE

can be used in both B2C and B2C settings. In our view, this work has made several contributions:

T h e business model used by IMAGINE evolved after carefulIy surveying related business models and crystalIizing the requirements for a new model that makes the marketplace equally attractive to all stakeholders in the marketplace. Also, the

model makes it imperative for the traders to rev& their "true" ~ u ~ i o n s and interests to gain maximum benefit from the marketplace.

T h e system has been built following best. practices in object oriented software engineering. UML modeling and analysis, design patterns, a d a carefd'ty thought out choice of software architecture have resulted in a highly robust design miodd for the system. In our view, IMAGINE ernbodies a bendinark design rn& thak am be extended and customized in many different, ways.

Chapter 7. SUMMARY AND FUTURJ3 WORK 9 1

Implementation of a prototype of IMAGINE has been carried out using leading edge

Internet technologies such as multi-agent technology, Jini, and Javaspaces. This is one of the first working implementations utilizing all these technologies in a single

setting.

In summary, the E-marketplace IMAGINE developed in this work has improved upon t,he

existing state-of-t,he-art in several non-trivial ways.

7.2 Future Work

Research and product development of this type leave numerous avenues for extension and

enhancement. Our work can evolve in several directions.

7.2.1 Business Model

The business model proposed here has some limitations. For example, it does not allow

for bundles to be bid by the buyers. Also, existence of price equilibrium can only be established for very special cases of the business model here. Convergence of transactions to this price equilibrium can only be established for even more special settings only. A

sound theoretical investigation of technical aspects of the business model is be>-ond the

scope of the present work, but wiIl certainly lead to non-trivial research encornpassing

areas such as game theory and optimization theory.

Note that the business mode1 of IMAGINE collects enough market intelligence during

the business transactions. For example, accurate information about the value associated with individual attributes becomes avaibable to the market. Such information provides

vduable inputs to conceiving new products.

7.2.2 Implementation of Business Model

The prototype implemented makes many assumptions, such as bidding for only single

items, only one type of product per seIIer, etc. Many of these restrictive assumptions

should be avoided in the next version of the implementation. In fact, we are currently

working on this. The design model does not impose any of these restrictions and therefore building the next version of the prototype is a fairly trivial task.

Chapter 7. SUMMARY AND FUTURE WORK

7.2.3 Framework for E-Markets

The software architecture and the technologies that are part of this architecture have

been chosen after much thought. The design therefore enables creation of extensions and specializations of IMAGINE without having to go through a redesign. There is therefore tremendous potential for developing an object oriented framework for Emarkets using which IMAGINE type of marketplaces can be rapidly created, customized, and extended.

7.2.4 Design Patterns

Several design patterns have been used in the design of IMAGINE. There is however rich

scope for more comprehensive work in this direction. This will be especially important if

a framework is t o be developed.

7.2.5 Interoperability

The technologies chosen and the implementation platforms selected provide enough room for building in interoperability with other existing Emarkets. In fact, IMAGINE can be

deployed as a metamarket, where interoperability is an essential requirement. Interop- erability was however not a primary design goal of IMAGINE and there is some effort required to make IM4GINE seamlessly interoperable with arbitrary E-market platforms. The issue needs careful investigation.

7.2.6 Scalability

Like interoperability, scalability was not a primary issue that was addressed while designing TMAGINE. The architecture, as pointed out in Chapter 5, has solid scalability features. However, i t is not clear if an IMAGINE marketplace will scale to very high levels. One issue t ha t will need resolution here is the computational complexity of convergence to price equilibrium in a large market setting. This is one more issue that provides much food for thought.

Bibliography

[1] Y. Bakos. The emerging role of electronic marketplaces on the Internet. Communi-

cations of the ACM, Volume 41, Number 8, August 1998, pp.35-42.

[2] A. Barua, A. B. Whinston, and F. Win. Value and productivity in the Internet

economy. IEEE Computer, May 2000.

[3] C. Beam and A. Segev. Automated negotiations: A survey of the state-of- the-art.

Wirt.schaftsinformatik, pp. 263-267, 1997.

[4] M. Bichler, C. Beam, and A. Segev. An electronic broker for business- to-business

electronic commerce on the Internet. International Journal of Cooperative Informa-

tion Systems, Volume 7, Number 4, pp. 315-341.

[5] h?. Bichler, C. Beam, and A. Segev. OFFER: A broker centered object framework

for electronic requisitioning. Proceedings of IFIP Conference on Trends in Electronic

Commerce, Hamburg, Germany, 1998.

[6] M. Bichler and A. Segev. A brokerage framework for Internet commerce. Journal of Distributed and parallel Databases. Volume 7, Number 2, pp. 133-148, 1998.

[7] G. Booch. Object-Oriented Analysis and Design with Applications. Second Edition.

Benjamin Cummings, 1994

[8] G. Booch, J. Rumbaugh, and I. Jacobson. The Unified Modeling Language User

Guide (The Addison-Wesley Object Technology Series). Addison-Wesley Publica- tions, October 1998.

[9] F. Branco. The design of multi-dimensional auctions. RAND Journal of Economics,

Volume 28, Number 1, pp. 63-81, 1997.

[I@] Business Week. Article that appared in the issue of May 4, 1998.

BIBLIOGRAPHY 94

[11] G. Cabri, L. Leonardi and F. Zambonelli. Pvlobile-Agent coordination models for

Internet applications. IEEE Computer, February 2000.

[12] A. Chavez and P. Maes. Kasbah: An agent marketplace for buying and selling goods.

Proceedings of the First International Conference on the Practical Application of Intelligent Agents and Multi-Agent Technology, PAAM-96, London, UK, 1996.

[13] E.K. Clemons and B.MT. Weber. Restructuring institutional block trading: An overview of the Optimark system. Journal of management Information Systems. JToi- ume 15, pp. 41-60, 1998.

1141 J. Conallen. Building Web Applications with UML. Addison-Wesley, 2000.

[15] R. Doorenbos, 0 . Etzioni, and D. Weld. A scalable comparison shopping agent for the world wide web. Proceedings of the first International Conference on Autonomous Agents (AGENTS-97). Marina del b y , CA, USA, February 1997.

[16] W. K. Edwards and B. Joy. Core Jini. Prentice Hall, June 1999.

[17] H. Ericsson and M. Penker. UML Toolkit. Wiley Compukr Publishing, December 1997.

[18] P. Evans and T.S. Wurster. Getting real about virtual commerce. Harvard Business &view, November-December 1999.

[19] S. Feldman. Electronic Marketplaces. Internet computing, July/August 2000

[20] E. Gamma, R. Helm, R. Johnson, and J. Ylissides. Design Patterns - Elements of Reusable Object-Oriented Software. AddismWesley Longman, 1995.

[21] Bill Gates. The Road Ahead. Rand Publishing House, 1995.

[22] S. Gilbert, B. McCarty, and T. Cabanski. Object-Oriented Design in Java (Mitchell Waite Signature Series). Waite Group Pr, May 1998.

[23] A. GreenwaZd, J.O. Kephart, and G.J. Twlu~). Strategic pricebat dynamics. Pro- ceedings of ACM Conference on EIectronic Commerce, EG'SS, h w e r , Colorado, November 1999.

[24] R. Guttrnan and P. M a s . Agentmediated integrative n%o%i&fomt for tronic commerce. Proceedingpr of the WorJlrshop on &$at4 Et&mak %ad- ing (AMEX-%), Minnqollis, Evlinwxt& USA, N

BIBLIOGRAPHY 95

[%I R. Guttman and P. Maes. Co-operative vs competitive multi-agent negotiations in retail electronic commerce, Proceedings of the Second International Workshop on Cooperative Information Agents (CIA-%), Paris, France, July 1998.

'261 R. Guttman, A. Moukas, and P. Maes. Agent-mediated electronic commerce: A survey. Knowledge Engineering Review, Volume 13, Number 3, 1998.

[27] A. Joshi and M.P. Singh (Guest Editors). Multiagents Systems on the Net. Special

Issue of Communications of the ACM, Volume 42, Number 3, March 1999.

[28) D. Harkey and R. Orfali. Client/Server Programming with Java and CORBA, 2nd Edition. John Wiley & Sons, March 1998.

1291 C. S. Horstmann and G. Cornell. Core Java 2: Volume I and 11. Prentice Hall PTR/Sun Microsystems Press, 1999.

1303 J. Hunter, W. Crawford, and P. Ferguson. Java Servlet Programming. O'Reilly & Associates, December 1998.

[31] TBM, i 2, and Ariba. Digital Marketplaces. White paper. http://wu*w.ariba.com. 2000.

1321 I. Jacobson, G. Booch, and J. Rumbaugh. The Unified Software Development Pro- cess. Addison Wesley Longman, 1999.

[33] Eric Freeman, Susanne Hupfer, and Ken Arnold. JavaSpaces(TM) Principles, Pat- terns, and Practice (The Jini(TM) Technology Series), Addison-Wesley, June 1999

[34] S. Kaplan and M. Sawhney. EWubs: The new B2B marketplaces. Hatvard Business Rmiew, May-June 2000, pp. 97-103.

[35] G.E. Kersten and S.J. Noronha. Negcrtiations in electronic commerce: Methodological misconceptions and a resolution. Proceedings of the 29th Atlantic Schools of Business Conference, Halifax, Canada, 1999.

[36] M. Kumar and S. Feldman. Internet Auctions. Proceedings of the Third USENDC workshop on Electronic Commerce, Boston, Massachusefks* USA, 19%.

[37] G. Larsen (Guest mitor). Component Based Enterprise h m e : m b . Specid h i e of Comnwuzicatwns ofthe ACM, Volume 43, Number 110, Oebbw

I381 H.G. Lee. Do electronic mwketpkps l m the ACM, Volume 41, Number 1, pp. 73-80,Jmuq 1998.

BIBLIOGRAPHY 96

f39J G. Lo and G. E. liersten. Negotiation in electronic Commerce: Integrating nego-

tiation support and software agent technologies. Proceedings of the 29th Atlantic Schools of Business Conference, 1999 and Annual Atlantic Canadian Operational

Research Society Conference, 1999.

[40] P. Maes, R.H. Guttman, and A.G. Moukas. -4gents that buy and sell: Transforming

commerce as we know it. Communications of the ACM, Volume 42, Surnber 3, March 1999.

[41] A. McAfee. Harvard Business Review, November-December 2000.

[42] B. McCarty and L. Cassady-Dorion. Java Distributed Objects. Sams Publications,

December 1998.

(431 S. McConnell. The OMG/CommerceNet Joint Electronic Commerce White Paper.

Research Report: OMG, 1997.

1.241 R. Monson-Haefel. Enterprise Javabeans. OIReilly & Associates, hfarch 2000.

[45] J. Morris and P. Maes. Negotiating beyond the bid price. Proceedings of the Confer-

ence on Human factors in Computing Systems, CHI-2000, The Hague, The Nether- lands, April 2000.

1461 Moses Ma (Guest Editor). Agents in E-Commerce. Special Issue of Comunicatiorzs of the ACM, Volume 42, Number 3, March 1999.

[47] Y. Narahari, K.N. Rajanikanth, and Sourav Sen. WHAT: A Web-enabled Internet

Auction House. Technical Report, Electronic Enterprises Laboratory, Department of Computer Science and Automation, Indian Institute of Science, August 2000.

[48] Y. Narahari and S. Rajesh. Implementing Reverse Auctions and Double Auctions:

An Experiment in Extending an Object Oriented Auction Package. Technical Repst, Electronic Enterprises Laboratory, Department of Computer Science and Automa- tion, Indian Institute of Science, August 2303).

[49] OECD. The economic and social impacts of electronic commerce. http://www.oecd.org/sub jectf e - c o m m e r c e / s a 1999.

[50] J. O'Neill. Java Beans programming for the grown up. Tat& McGraw Hill, 199.8.

I511 R Orfali, et al. Client/Semr Survival Guide, 3rd Witilart, John January 1999.

BIBLIOGRAPHY 9 7

[52] A. Patzer and S. Li. Professional Java Server Programming: il;ith Scnrlets, JavaServer Pages (JSP), XML, Enterprise JavaBeans (EJB), JXDI, CORBX, Jini and Javaspaces. Wrox Press Inc., Auguest 1999.

[53] P. Prescod, F. Charles, and Goldfarb. The XML Handbook. Prentice Hall, 1998.

[54] T. Quatrani. Visual modelling with Rational Rose 2000 and UML. Addison-Wesley.

2000.

[55] H. Raiffa. The Art and Science of Negotiation. Cambridge:Belknap Harvard Press,

1982.

[56] F. F. Reichheld and P. Schefter. E-Loyalty. Harvard Business Review, July-August 2000.

[57] J. Rodriguez, P. Noriega, C. Sierra, and J. Padget. FM96.5: A Java-based Electronic

Auction House. Proceedings of PAAM-97, Second International Conference on the

Practical Application of Intelligent Agents and Multi-Agent Technology, London, UK, April 1997.

[58] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, J. Rumbaugh, and JV. Lorenson. Object-Oriented Modeling and Design. Prentice Hall, January, 1991.

[59] J. Rumbaugh, I. Jacobson, and G-Booch. The Unified Modeling Language Reference

Manual. Addison Wesley Longman, 1999.

[60] W. A. Sahlman. The new economy is stronger t,hat you think. Harvard Business

Review, November-December, 1999.

[61] T. Sandholm. Approaches to winner determination in combinatorial auctions. Deci- sion Support Systems. Volume 28, Number 1, pp. 165-176, 19%.

[62] T. Sandholm. eMediator: A next generation electronic commerce server. Interna- tional Conference on Autonomous Agents (AGENTS-BOO), Barcelona, Spain, June 2000.

[63] T. Sandholm and Q. Huai. Nomad: Mobile agent system for an internet based auction house.

[64] A. Segev and M. Bichler. Component based electronic commerce. Iar h4. Shaw, R Blanning, T. Strader, and A. Whinston (Editors), Handbook 5n Eteetronic Q m -

merce, New York: Springer, 1999.

[65] P. B. Seybold. Cust.orners.com, Random House, 1998.

[66] Y. Shan and R.E. Earl. Enterprise Computing With Objects: From Client/Senw Environments to the Internet. Addison-Wesley Object Technology Series, 1998.

[67] Mary Shaw and David Garlan. Software Architecture - Perspectives on an Emerging Discipline. Prentice Hall of India Eastern Economy Edition, 1999.

[68] Shobhit. ACF: Agent Communication Framework. M.E. Project Report, Electronic

Enterprises Laboratory, Department of Computer Science and Automation, Indian Institute of Science, January 2001.

[69]. M.D. Smith, J. Bailey, and E. Brynjolfsson. Understanding digital markets: Review

and assessment. In: Understanding the Digital Economy, E. BrynjoIfsson and B. Kahn (Editors), MIT Press, 1999.

[70] Sun Microsystems. The Java Tutorial. http://java.sun.com Jdacs/books/tutorial/

[71] Sun Microsystems. XML and Java. http://www.java.sun.com/xrnl

[72] Sun Microsyst,ems. Jini Network Technology: An Executive Overview. White Paper, Sun Microsystems, February 2001.

.[73] J. Teich, H. Wallenius, and J. Wallenius. Multiple-issue auction and market algu- rithms for the world wide web. Decision Support Systems. Volume 26, pp. 49-66:

1999.

[74] J. Teich, H. WaIlenius, J. Wallenius, and A. Zaitsev. A multiple unit auction algorithm: Some theory and a web implementation. Electronic Markets: International Journal of Electronic Commerce and Business Media, Volume 9, Number 3, pp. 1-7,

1999.

1751 G. Tewari and P. Maes. Design and implementation of an agent-based intermediary infrastructure for electronic markets. Proceedings of ACM Conference on EIectronic Commerce, EC-2000, Minneapolis, Minnesota, USA, October 2000.

[76] H. Varian. Economic mechanism design for computerized agents. Proceedings of the USENIX workshop on Electronic Commerce, New York, NY, USA, 19%.

[77] J. Walker. Redesigning Business. Harvard Business hviev, November-Dwemkr 1999.

[78] L. Walras. Elements of Pure Economics. Allen and Unwin, 1874.

B.IBLI0 GRAPHY 9 9

1791 W. Walsh, M. Wellrnan, P. Wurrnan, and J. MacKie-Mason. Some economics of

market-based distributed scheduling. Proceedings of 18th International Conference on Distributed Computing Systems, pp. 612-621, 1998.

[80] A. C. Weaver et al. The future of ecomrnerce. IEEE Computer, October 2000.

[81] R. Wise and D. Morrison. Beyond the Exchange: The future of B2B. Harvard Busi- ness Review. Volume 78, Number 6, November-December 2000, pp. 86-98.

[82] D. Wong, N. Paciorek, and D. Moore. Java-based Mobile .4gents. Communications of the ACM, Volume 42, Number 3, pp.92-96, March 1999.

[83] M. Wooldridge and K. Decker. Agents on the Net: Infrastructure, technology, applications. IEEE Internet Computing, March-April, 2000.

[84] P.R. Wurrnan, M.P. Wellman, and W.E. Walsh. The Michigan Auction Bot: A con- figurable auction server for human software agents. Proceedings of the Second Inter- national Conference on Autonomous Agents, AGENTS-98, Minneapolis, 1998.

1851 Amazon.com. URL: http://wu~~v.amazon.com

[86] Firefly Network. URL: http://n-ww.firefly.com

[87] Persona Logic. URL: http://n~rsw.personalogic.com

[88] BargainFinder. URL: http://bf.cstar.ac.com/bf

[89] Jango. URL: http://www.jango.com

[go] Kasbah. URL: http://kasbah.media.mit.edu

1911 AuctionBot. URL: http://auction.eecs.umich.edu

[92] Onsale. URL: http://www.ebay.com/aw

[93] Ebay Auction Site. URL: http://www.ebay.com/aw

[94] Priceline. URL: http://www.priceline.corn

[95] Tete-a-Tete. URL: http://eeammerce.media.mit.edu/tetea-t&

[96] Voyager (Object Space). U U : http://www.objectsp~tce-corn /voyager

[97] Mitsubishi Conmrdia. URL: http://www.meitca.eom/WSL/Proj~/~~~rdi~

1981 IBM -4glets. URL: http://awrv.trl.ibm.co.jp/aglets

[99] OMG Mobile Agents. URL: http://wni~~.omg.org/Iibrary/sched~1e/CF-RFP3.htr1~

[loo] Ariba. URL: ht tp://www.ariba.com

[I011 Commerce One. URL: http://www.cornmerceone.com

[lOZ] MRO. URL: http://www.rnro.corn

[I031 Chemdex. URL: http:/ /www.chemdex.eom

11041 Chemconnect. URL: http://www.chernconnect .com

[I051 Ebizchem. URL: http://www.ebizchern.com

[106] Plastics Net. URL: http://waw. plasticsnet.com

[I071 CapwityWeb. URL: http://www.capacityweb.com

[108] Steel Exchange. URL: http://www.e-steel.com

[I091 Paper Exchange. URL: http://ww.rr-.paperexchange.com

[ l l O ] Energ\. E d m g e . URL: http://ivi~\v.altraenergy.com

[Ill) Automotive Exchange. URL: http:j~ww.covisint.com

[I121 MAR1 Ernarketplace. URL: btp://www.media.mit.edu/@ewari/MARI/

[I131 Software Agents Group. URL: http://agents.media.rnit.du/goups/agents

p14) Frictionless Valueshopper. http://compare.frictioa1exj.com

1115) MySimon Buyers Guide. URL: http://www.mysimon.com/~~n~~mer-rmurces/ Buyers-Guides/index,html

[I161 Elance. URL: http://www.elance.eorn

[I171 Trading Dynamics. URL: http://www.tradingdpami~l~i~c1om

(1181 Market Design. URL: http://www.rnarleed.esign.fx1m

[US] Net Market Makers. URL: http://anuv.nmm.org

Appendix A

UML Notation: A Quick Summary

This appendix provides a quick summary of UhlL (Unified Modeling Language) notation used in the UML diagrams of Chapters 3, 4, 5, and 6.

Appendix A. UML Notation: A Quick Summary 102

Acrivity diagram

A d o n State :

Start state: .----+ Class

Association

Stop state : - Action State Transition

Concurrent action

Swimlanes

Action B a

Rule name in ~sswhio11

ClauA

Figure A. 1: Relevant Uh4L Notadon (&st pars}

Association ) I..* 0.: - CLaroB

Appendix A. UML Notation: A Quick Summary 103

Class diagram .

Gcnaalization

Interface

Coaponeni diagram

Figure A.2: Relevant U.h."IL Notation ( PW

Appendix A. UML Notation: A Quick Sununary 104

Figure A.3: Relevant UML Notation (third part)

Documents

AN INTELLIGENT MARKETPLACE - ERNETlcm.csa.iisc.ernet.in/hari/all-publications/research-reports... · His rational thinking and fast grasping power of the students psychic health is