WebMart Overview

What is WebMart and What Does it Do?

WebMart is a software framework, written in Java, for creating automated electronic businesses. Its reusable components, based on a secure architecture, can be used to automate business processes from online purchases to royalties, auctions, escrow, reservations, discounts, and negotiations. WebMart's framework lets you create secure online businesses quickly and easily. This document is for the development manager or designer who needs to evaluate the tools available for developing complex e-business applications. It is an overview of the basic ideas behind WebMart and a summary description of the components in the WebMart packages.

The WebMart Package

WebMart applications use a set of programming objects patterned after the rich complexity of conventional markets and commerce. By using distributed objects, the software components of a transaction can be anywhere on the net, spread out across multiple machines and platforms.

One of the core insights that led to the development of WebMart is the observation that conventions common to most economies map to object-oriented programming concepts (See Figure 1 below). For example, a property right is like an object pointer; they both represent the authority to use (invoke the public methods) and transfer (pass as an argument) a resource. Similarly, rights transfer, exchanges, and the function of Escrow Agents can be accomplished electronically by using patterns of messages sent between objects.

FIGURE 1. How business/exchange concepts map to object-oriented programming

WebMart is a set of Java packages. A Java package is a collection of related Java classes that implement particular components. The objects created by the WebMart packages fall into two categories: "Application-Specific Components" and "Market Institutions."

Application-Specific Components

These software components define core protocols that must be implemented in subclasses specific to a given use or business. Examples include policies and descriptions of application-specific goods.

Market Institutions

These are reusable software components that automate complex business processes such as auctions. They also perform the functions of real world financial institutions such as banks and escrow agents.

These categories are explained in greater detail below.

Application-Specific Components Overview

The Application-Specific Components are fundamental reusable components of commerce. These objects represent the basic components common to any market transaction, namely the items exchanged, the processing of offers, and the transfer of goods that closes the transaction. The Application-Specific Components are:

• GoodsDescriptions
• Offers
• OfferEvaluator
• OfferCombiners
• Factories
• Reactors

GoodsDescriptions

GoodsDescriptions function as descriptions of what the application’s users wish to exchange. The simplest form of a GoodsDescription would be a simple string such as “one play of ‘Blue Suede Shoes’" or “$1,000.00,” or “1964 T-Bird Convertible.” Unfortunately, these kinds of descriptions do not lend themselves well to an electronic economy. WebMart GoodsDescriptions form a taxonomy implemented as a Java inheritance hierarchy. This taxonomy enables the WebMart Market Institutions to evaluate and categorize goods. The structure of a GoodsDescription is specific to the application and will reflect properties of the goods offered, for example, a GoodsDescription for a computer sales business might include processor, display size, memory, etc. Once the GoodsDescription is in place, WebMart Market Institutions can organize and manipulate these items as required.

Offers

An Offer consists of a GoodsDescription plus the terms of the exchange. For example, a jukebox might have the option of playing “Let It Be” by the Beatles for 25 cents. Offers also form a taxonomy similar to GoodsDescriptions.

These are specialized for the specific terms of the business. The simplest is an exchange offer (something for something else). A seller of network bandwidth might instead have an offer for bandwidth to be delivered over time.

OfferEvaluator

As the name suggests, an OfferEvaluator evaluates incoming Offers, and then chooses the best one. Sometimes this requires nothing more than a simple comparison. However, in other instances it can be less straightforward. For example, suppose you have eleven items for sale, and you receive two Offers; one to buy nine of them for $4.00 each, and another to buy four for $5.00. Only one offer can be satisfied, one for more total sales, the other for a higher price on lower sales. The Offer Evaluator for a given business embodies the business' policies and knowledge about which is preferred. These policies are used by the Market Institutions to decide, for example, which of many offers to accept in an auction.

OfferCombiners

Sometimes a business will receive several offers for the same item. Depending on the nature of the item, it can be advantageous for the business to combine these offers in a way that will benefit all of the potential buyers. A good example of this involves the jukebox. If several clients pay to put the same song in the queue, an OfferCombiner can combine the multiple offers into a single play, but use the extra money to place the song closer to the top of the queue. OfferCombiners are frequently used in conjunction with BidPriorityQueues, which are discussed below.

Factories

The term ”factory” is a concept found in object-oriented programming. Factories make objects according to a pattern built into the factory. In addition, WebMart factories have security features that can verify or vouch for the authenticity of the objects they create. This assures the user that the object they are dealing with and its authority have not been forged. Application-specific Factories are used by the Market Institutions to create and validate business-specific GoodsDescriptions, Offers, etc.

Reactors

Reactors are a generic call-back mechanism. Reactors are objects, similar to Observer design patterns, for interfacing between Market Institutions and Application-Specific code. Each Market Institution defines a reactor type with messages that reflect changes to the state of the Market Institution, e.g., the reception of a new bid in an auction. By implementing such a reactor type and registering an instance with the Market Institution, business-specific code will be invoked; for example to start playing a song on a jukebox.

Market Institutions Overview

The WebMart Market Institutions are reusable software packages that automate business processes between market participants. Most Market Institutions are built using and extending other basic WebMart packages. Some of the Market Institutions in WebMart are:

• eBank
• EscrowAgents
• Auctions
• Futures Markets
• Bid Priority Queue
• Purchase Applets
• Active Price Sheets

eBank

The eBank is a package that contains and manages Payments and their associated Accounts.

The Account Manager is an object for managing a hierarchy of accounts.

The Account is an object that maintains a balance and supports auditing and tracking of Payments made as part of transactions. An Account can instantiate Payment objects or create new Accounts to support other payment mechanisms.

A Payment represents the transfer of money, and the record of the transaction. More specifically, a Payment is the mechanism for transferring value between two Accounts.

EscrowAgent

The EscrowAgent in WebMart acts as a trusted third party. It holds in escrow goods from each party to a transaction until all sides have met the conditions for the transaction to be completed. The EscrowAgent also checks the goods it holds in escrow to see if they meet the specified conditions. An EscrowAgent also provides a record of the state of the transaction in progress, and thus can provide basic real-time or historical tracking information.

There are three parts to an EscrowAgent. The LiveReceipt is a read-only user interface through which the state of a transaction is visible. It also allows one to attach a business-specific Reactor to respond to changes in the state of the transaction. The LiveReceipt can be stored in an Account for later auditing.

The second and third parts of the EscrowAgent are two instances of an EscrowClerk, one for each of the parties to the transaction. The EscrowClerk serves as a means for the parties to exchange information and conclude the transaction when it is complete or cancel it if one party does not want to continue.

Auctions

WebMart Auctions are general mechanisms for automatically consummating the sale of a scarce resource. More specialized Auctions include Futures Markets and Bid Priority Queues (see below). They provide a means of handling and evaluating competing Offers. This can take the form of an auction such as you might find at Southby’s, or bids placed on transportation resources such as airline tickets.

There are many kinds of auctions to meet diverse real-world needs. Different advantages and disadvantages become even more apparent when one compares various auction formats from a computing perspective. Although such a comparison may be of interest to the application designer, they are beyond the scope of this document. For more detailed studies on this subject refer to the paper “Going, Going Gone!”, available on the Agorics web site. Another useful document is “Real-Time Video Delivery with Market-Based Resource Allocation,” Agorics Technical Report ADd004P.

Futures Markets

The FuturesMarket facilitates selling the use of a serially reusable resource. For example, someone can call an airline and charge a ticket for a particular future time period. Another example is that one might purchase a song to be played on a jukebox during an upcoming party. Likewise a company VP can purchase a four-hour block of satellite bandwidth to ensure that the quarterly video-conference with his counterpart in Japan goes through without interruption. If the call only lasts half an hour, the remaining time can be sold back to the market by the buyer.

Bid Priority Queue

Some goods are sold on a per-use basis. A BidPriorityQueue is a spot market for a serially reusable resource. One familiar example is a song played on a jukebox. You put money into the jukebox in order to hear a particular song once. If others have already made selections ahead of yours, you must wait until their songs have finished playing before your song plays. The BidPriorityQueue allows bidders to bid for faster service.

BidPriorityQueues let you bid a premium to move up in the delivery queue. In the case of our jukebox, if more than one person asks for the same song, the bid priority queue can combine their Payments and move one play of the song up the queue accordingly. Another example of this practice is paying premium rates for overnight delivery of a package versus a low price for 3rd class book rate delivery.

Purchase Applets

A Purchase Applet is a user interface used to disburse payments. It is a part of the buyer’s (client’s) program that handles messages to and from the eBank. It also acts as an agent working for the seller that goes to an eBank (or other purchase mechanism) and gets money. The eBank uses the Purchase Applet to let the users pay service applet user interfaces for requesting services (i.e., Active Price Sheets - see below).

Active Price Sheets

Active Price Sheets are a design pattern for presenting GoodsDescriptions and Offers in a dynamic, interactive user interface. The Active Price Sheet is a user interface for the options the business is providing. Active Price Sheets are “composable.” This means that an Active Price Sheet incorporates and tracks all the composite factors that influence the price of something. These factors are immediately reflected in the current price. For example, a user could see the price of a custom sofa made with different fabrics or in different sizes and models. When the customer decides on the purchase, the Active Price Sheet can set in motion all of the associated actions that accompany a purchase, such as the creation of an invoice, or telling a sales representative to call and confirm the order. In addition, the Active Price Sheet can accept the customer’s authorization to make the purchase.

Active Price Sheets confer even greater advantages when the prices are more dynamic than the price of upholstery or lumber. Suppose a California fisherman wants to sell the morning’s catch in San Francisco. The active price sheet can reflect the kind of fish, how large they are, and the overall demand for that species. But since fish is a very perishable commodity, an active price sheet can reflect the declining value of the catch as the day wears on as well as the evolving inventory balance. Likewise, a jukebox might charge extra for a song that is on Billboard’s Top Ten list, or for a play during the hours when the jukebox sees the heaviest use.

Another advantage of active price sheets is that they can manage “fine-grained” charges or “micropayments,” that is, charges that are too small for current commercial practices to resolve. For example, a heavily-used service might only charge $.0001 per time unit of use. Fine-grained assessments are impractical for most material world transactions, especially if they are dynamic. But they become both practicable and useful in an electronic economy.

Conclusion

With the WebMart framework, components and market institutions businesses can build complex, secure, on-line ecommerce solutions which are designed to scale with market success. This proven design and tested modules lower development risk, and saves time and money for companies that are taking advantage of the Internet business opportunities or real-time transactions such as bandwidth management.