|OMIX WHITE PAPER|
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.
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:
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.)
Auctions come in many forms. The most popular of which include the English Auction, the Dutch Auction, the Vickery Auction and the Yankee Auction.
Auctions can be grouped by the roles users play:
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:
These and several other minor requirements meant that it became necessary to develop the OMIX Auction Framework.
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:
The next set of requirements applied to C2C and B2C auctions:
Lastly, a set of requirements was adopted to cover B2B auctions:
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.
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
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:
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:
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.
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.
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.