ABSTRACT

A software framework of reusable Enterprise Java Beans (EJB 1.1) and Java Server Pages (JSP 1.1) for developing online auction applications is described. This software was developed at OMIX over the past two years and has been generalized to allow for the rapid development of a wide range of auction types including English Outcry Auction, Dutch Auction and Reverse Auction. The software framework runs on a Java 2 Enterprise Edition (J2EE) standard based application server.

INTRODUCTION

New life has been bred into auctions with the advent of the Internet. Big players in the online auction world like eBay and Yahoo are giving millions of people easy and instant access to standard consumer auctions. In industries and businesses where auctions have been the standard means of conducting transactions, online systems have sped up and generalized the process. In general, the Internet auction has become a popular way to enhance the mode of handling transactions whether between individuals or businesses.

The typical reason to go online with an auction include:

• Advertising, reaching a broader audience and removing geographical limitations
• Tracking for buyers and sellers
• Security of transactions
• Automate bid checking and auction awarding
• Efficient managing and recording of bid transactions
• Ease of modifying auction rules

As more B2B transactions are processed electronically over the web auctions will be an important step in determining a fair market price. A report from Forrester Research predicts that B2B transactions will grow to 200 billion dollars by 2002, much of this will be conducted through auction. (Forrester Research, www.forrester.com.)

AUCTION TYPES

Auctions come in many forms. The most popular of which include the English Auction, the Dutch Auction, the Vickery Auction and the Yankee Auction.

• English Auctions are the most popular for commodity items where users continue to bid up the price for an item. Typically the auction closes after a set time period or when all bidding activity is complete. The highest bidder wins the auction.
• Dutch Auctions are used to sell multiple identical items. The seller sets the minimum price and quantity at the start of the auction and bidders bid at or above that price. The highest bidder gets the right to buy the items at the price of the minimum successful bid.
• Vickery Auctions are a variant on the English Auction where the second highest bid is accepted as the price to the winning bidder. This auction is used to set market value for the commodities sold.
• Yankee Auctions are a variant of the Dutch Auction where winning bidders pay the amount of their bid and not the price of the minimum winning bid.

Auctions can be grouped by the roles users play:

• Consumer to Consumer, C2C, describes the model where end users place items for auction on a large site where other consumers can register and make bids. These systems are usually set up in custom environments where a large range of items can be accommodated. eBay and Yahoo have been very successful establishing a business around this model.
• Business to Consumer, B2C, describes an auction market where companies setup auctions to sell off excess inventory and product.
• Business to Business, B2B, where companies use the auction to source supplies, parts and raw materials. The generation of an RFP is generally part of the auction process. In the case of multiple suppliers a Reverse Auction may be used.

BACKGROUND

Several attempts have been made to develop generalized online auctions. This has been achieved to different degrees of success. Kumar and Feldman [Kumar98] developed a system at IBM that covered both English and Dutch Auctions. Their conclusions were that online auctions are a very viable means to transacting the sale of items, however significant infrastructure is needed to properly administer auctions and maintain security before widespread acceptance can be expected in the business community.

Currently several commercial offerings are available claiming ease of installation and use. Among those products are: Auctioneer, Beyond Solutions, C-U-S Business Solutions, Emaze Auction, Merkatum, IbidU.com, Auction-USA, and Auction Broke Software. All of these products are limited in the types of auction that can be run, particularly when it comes to specifying the deployment system and changing aspects of the auction rules. Out of the box solutions tend not to have full configuration support and secure administration without significant infrastructure added. These systems provide solutions that work for common auctions but fail to deliver the flexibility and security required for commercial B2B auctions.

One product from MOAI Solutions has deployed their auction software on a Java 2 Enterprise Edition (J2EE) compliant application server and has the promise of providing flexibility, scalability and security through it extensible architecture. One drawback to their system is the use of proprietary languages for building the auction website. MOAI uses templates called MSP and NCML to build the front end to their auctions.

In the face of so many systems available to provide auction functionality it may seem that OMIX would have many options to choose from. However to meet customer requests in both the B2B and C2C arenas, where particular features were deemed essential, it was necessary to develop our own auction management code base. Key requirements included the following:

• Deploy the auction on a J2EE application server where security and scalability issues could be easily addressed
• Develop to a J2EE standard giving ease of portability between platforms
• Implement complex algorithms around rules for auction closing
• Complex RFP creation involving volumes, time periods and pricing mechanisms which could only be represented in multiple spreadsheets
• Allow Administration to switch between automatic and manual auction award

These and several other minor requirements meant that it became necessary to develop the OMIX Auction Framework.

REQUIREMENTS

Basic requirements of the OMIX Auction Framework were broken into three sets. The first requirements were applied to all types of auctions. They were as follows:

• All Java implementation meeting J2EE standard, deployable on Windows NT or Unix Sun Solaris
• Implemented in a 3-tier architecture with scalability for web servers and application servers.
• Security, including encryption for bids, user passwords and user authentication
• Registration and authentication for Buyers, Sellers, Dealers, Clients, Suppliers and Administrators

The next set of requirements applied to C2C and B2C auctions:

• English Auction for individual items
• Bidding can be incremental or detrimental
• Reservation Price set by the seller (set as an auction rule)
• Open bid, maximum/minimum bid and proxy bid
• Setting up of auction rules
• Setting the start time, close time and cancel of auction
• Changing the reservation price
• Timers for the start of auction, and timers for the end of auction
• Auction administration handled by the auction manager
• Limited auction administration by the seller: change reservation price, extend auction and cancel auction
• Auction award made via email
• Automatic setting of auction increment for proxy bidding. Auction wide setting
• Automatic extension of the auction close time while active bids are received
• Email notification of the auction rules change and auction close
• Advertising auctions via email and watch lists

Lastly, a set of requirements was adopted to cover B2B auctions:

• Reverse Dutch Auction
• Setting up complex multidimensional datasets as part of an RFP
• Associating contracts with RFP's
• Scheduling and advertising auctions via email and watch lists
• Support for open and sealed bids
• Auctions can be open to all registered bidders
• Auctions can be closed to all, except for a pre-selected set of bidders
• Auctions cover multiple term periods and volume type for each of those periods
• Auction administration is handled by the auction manager
• Limited auction administration by the buyer (client)
• Auction reporting is made to the buyer (client) in the form of bid history
• Users are associated with companies and make bids on behalf of companies (B2B scenario)
• Proxy bidding support
• Manual or automatic setting of the bid increment

A requirement throughout all the auction types was strict tracking and monitoring of all activity online activities. Logging and pattern tracking could be used to fight collaboration conspiracy and thus avoiding fraud on the auction site.

DESIGN

The OMIX Auction Framework was designed using Object Oriented Analysis and Design techniques. The design was documented in UML using Rational Rose. Figure 1 shows graphically the general use cases that were developed.

Figure 1. Use case diagram for basic auction foundation

Sequence diagrams and Class diagrams were developed from this initial analysis. Generic classes were picked to cover basic functions of the entities in the system. Since several types of users could use the bidding process, a base class of user was developed. Extensions on the user include bidder, seller, dealer, supplier and client. Similarly, the bid include classes that cover single value bids and multiple value bids that apply over a time period as in the case of auctioning a service or supply. As an example of one of the sequence diagrams, figure 2 shows the case of making a bid.

Figure 2. Sequence diagram for bidder

A package diagram showing the basic groupings of classes for the C2C type auction is shown in figure 3.

Figure 3. Class diagram for EJB Implementation of C2C auction

All auctions have complex rule sets that interact as auctions are played out. In the case of the C2C auction figure 4 shows the flow of control for the bidder making a bid in a particular instance.

Figure 4. Flow of control of bidding in a complexC2C auction

Glossary for Bidding Algorithm

• Opening Bid: It is the amount the bid has started with.
• High Bid: The highest bid so far on the auction.
• Current Bid: It is the minimum amount the user has to bid.
• Maximum Bid: It is the amount bid by the user.
• Top Bid: It is the highest of the maximum bids bid so far.
• Bid Increment: It is the minimum amount the bid has to be increased.
• Reservation Price: It is the minimum amount for which the seller wants to sell an item in the auction.

IMPLEMENTATION

A high level representation of the typical site implemented using the OMIX Auction Framework is represented in figure 5.

Figure 5. Using a 3 tier architecture

All database connections are managed through DBUtilities classes that wrap the JDBC calls and the SQL code, isolating the databases from the rest of the application. The business logic of the application is written as a set of classes that reside in the container of the application server. The classes that need transaction support are written as either session or entity beans. Helper classes are written to provide service to JSP pages that display to the client dynamic data related to the auctions. Configuration of the site is controlled using XML.

EXAMPLE 1: BESTOFFER.COM

The auction for the BestOffer site was developed using Enterprise Java Beans and Java Server Pages. The implementation provided a particular type of auction containing proxy bidding, close time extensions and auction rules. The system has been used to auction second hand automobiles. A typical use is as follows: The automobile seller has an opportunity to place a vehicle in auction; An administrator for the site is responsible to add certain reports and static data to the information describing the vehicle; Then the administrator will advertise the vehicle as available for auction; Buyers on the site can search the database for vehicles currently in auction; Buyers can then make bids on a particular auction.

The Best Offer module was responsible for implementing the rules used for Best Offer car auctions. The parameters for the auction, include:

• Opening Price
• Reservation Price
• Auction Close Date and Time
• Email Notification

These parameters are established by the seller, using the Option Rules interface, in the Seller's section of the site.

Reservation Price Rule: If the auction has progressed such that there is less than 24 hours remaining in the auction and the high bid is still less than the reservation price, then the value of the current bid (for new bids) will be set to the reservation price.

Email Notification: The auction component will automatically generate the email notifications described in the following sections:

• Auction Ending Notification: When an auction has 24 hours left, an email notification will be sent to all users that have the auctioned vehicle in their Watch List.
• Outbid Notification: When a top bidder on an auction, is outbid by another bidder, the system will automatically send email notification to the buyer that has been outbid.
• High Bid Notification: The auction component will automatically send a notification to the seller whenever a new bid becomes the high bid on the seller's auctioned vehicle.
• End Auction Notification: The auction component will automatically send email notification to the seller and winning bidder when the auction ends.

Proxy Bidding: Sets the maximum amount a bidder is willing to pay. The Best Offer system makes automatic bids as other bidders increase the bid price. This amount is kept secret and is referred to as the PROXY bid. If a maximum bid is outbid by another bidder, notification is sent by email.

EXAMPLE 2 : KIMBALL RESOURCES INC.

The Kimball website supports the running of auctions for the supply of natural gas to companies in the car industry. The site allows users to self-register, followed by a Kimball representative assigning them the privilege to enter relevant parts of the site. The Kimball representative can also enter an RFP on behalf of a client and have an auction automatically start at the specified date and time. Auction bids are placed by suppliers. Auction bids are monitored by the client who can choose to change auction rules. At the completion time of an auction, the client awards the contract to one or more suppliers.

RESULTS

OMIX has gained the experience of building a basic framework to support auctions. We have developed our code base to an industry-wide recognized standard by using the specifications of J2EE. The code has been build onto a general infrastructure supplied by an application server giving scalability, security and portability.

The current code base will not cover all auctions, however the framework is flexible enough to be easily adopted for demanding requirements.

CONCLUSION

Auctions continue to be a challenge for online implementation. Many auctions have very particular rules that need to be met. Scalability and security issues require that auctions be implemented in a predictable framework such as a J2EE application server. Development in Java, using J2EE standards, insure portability between platforms and application servers.