Creating Electronic Markets

Ming is a doctoral student at the University of Texas at Austin and can be reached at [email protected]. Jan is an assistant professor of information systems and can be contacted at [email protected]. Andrew is director of the Center for Research in Electronic Commerce. He can be reached at [email protected].

Consider the following scenario: A regional utility company has forecast an increase in demand for power in the coming season. To meet the demand, the company needs to buy a large quantity of gas. But buying and receiving gas is a complex process -- buyers not only need to find sellers who have gas to sell, but also must ensure the gas can be delivered. Therefore, after buying the gas, buyers have to lease a sequence of long distance and intrastate pipelines to transport gas from origin to destination.

Currently, there are no efficient markets to handle this type of trade, except brokers who charge fat premiums for bundling all this together. However, the Federal Energy Regulatory Commission recently began pushing the industry to adopt the Internet as a universal commerce platform to help cope with the increased volumes of trade that ongoing deregulation is bound to produce. In short, the FERC is promoting electronic trading markets. In this article, we'll take this idea of an e-market one step further by trading commodities (such as gas and pipelines) in bundles.

Bundle trading lets buyers acquire a combination of resources in a specified proportion. (Bundle trading is a market-clearing system that matches orders and provides price discovery for the traded assets. This is not the same as the basket/bundle trading services provided by Accutrade or other brokerages, which provide convenient order entry, having nothing to do with market clearing.) If one or more resources are excluded from the combination, then the bundle will have significantly less or no value. For example, in gas trading, if the pipeline is not available, then there is no need for the buyer to purchase gas. Bundle trading also simplifies the complex trading process. In our current market system, buyers may demand a bundle of resources that cannot be matched with any single seller. Bundle trading solves this problem by recombining resources from different sellers to satisfy the request for a specific buyer. Bundle trading uses a sophisticated computational procedure which is too complicated to handle in traditional market settings, but can be carried out efficiently in an e-market. It is poised to have a tremendous impact on the way we do business in the future.

The bundle-trading mechanism we present here can be used for trading not only commodities such as gas or oil, but also financial instruments such as stocks, bonds, futures, options, and foreign currencies. In this article, we'll describe a web-based Financial Bundle Trading System (FBTS), developed at the Center for Research in Electronic Commerce at the University of Texas at Austin (http://cism.bus.utexas.edu/). FBTS lets you access financial markets using Java applets embedded in web browsers. You can, therefore, access the financial market through the Internet from anywhere at any time. The FBTS middleware takes orders, automatically finds matches, calculates execution prices, and clears the market.

Implemented using the Java Remote Method Invocation (RMI), communication between traders and the market is dynamic and interactive. Additionally, multithreaded Java server applications let the FBTS middleware handle an ultra-large-scale e-market application in an efficient manner. FBTS clearly has an edge over traditional marketplaces. FBTS not only takes advantage of the Web and Java's innovative features to create a large-scale distributed system, but also demonstrates the power of using these technologies to implement a complex trading mechanism in the virtual marketplace, providing a better solution to existing business problems.

Web-Based Distributed Computing as the Platform

For new e-markets to function, we need web-based distributed-computing environments where agents from virtually anywhere can conduct businesses interactively and dynamically. The convergence of the Internet and distributed-object technologies are the building blocks for the e-market platform. In an electronic marketplace, both human agents and intelligent software agents interact with each other through some kind of market intermediary. Our e-market concept should also provide a unified marketplace that can be accessed by agents from anywhere at any time. Therefore, the adoption of proprietary platforms and applications is inappropriate because they constrain access to the market. The technological infrastructure for e-markets should be open and ensure universal access. The web is the ideal platform for such e-markets.

Earlier web-based applications predominantly used a server-centric model based heavily on CGI scripts which degrades system performance. For example, communications between clients and web server cannot be interactive. For complicated applications in e-markets, agents must continuously reload web pages to get updates from servers.

In contrast, Java/CORBA-based applications are well suited for interactive and dynamic applications of e-markets. First, Java can be compiled into platform-independent bytecode, which can run on any system with a Java run time. This guarantees that e-market applications can be deployed without additional efforts in different platforms. Second, Java applets can be seamlessly integrated in a web page. Therefore, traders in the marketplace can interact with the market maker using Java applets and web browsers. They are guaranteed universal access to e-markets. Third, Java/CORBA provides a distributed-computing framework that allows agents to interact with the market dynamically and interactively. Java fits well with CORBA. In fact Java itself also provides a distributed application model -- RMI.

Using distributed objects models from either RMI or CORBA, we developed a distributed agent system where agents and middleware can invoke each other's methods and pass messages around interactively, which is fundamental to distributed computing and e-market applications.

How FBTS Works

FBTS is a continuous electronic market that handles bundle trading and can be accessed through the Internet. As Figure 1 illustrates, FBTS includes trader-host applications, a middleware application, a monitor application, and a communication model between trader and middleware. Applications and market activities are distributed at both the trader and middleware side via an open network. The trader host application provides an interface for traders to enter orders and view trade information. We implemented order error checking based on the FBTS trading rules so that invalid orders are caught before they reach the middleware. This helps reduce server workload and minimizes network communication.

The TradeApplet has an open-order table implemented in a Java Frame. The table opens as soon as traders have an open order and dynamically updates as trading goes on. The middleware contains a web server and a CORBA/RMI server. The web server is responsible for publishing HTML pages and the TradeApplet to traders. Therefore, traders only need to access FBTS's homepage through a web browser and the TradeApplet executes within the browser's Java run time. This simplifies the task of distributing and deploying trader applications throughout the market. The CORBA/RMI server serves as the "Market Maker" for bundle trading and has two major components -- a limit-order database and order-matching program. Market administrators can monitor market operations and performance remotely using the monitor applet. To ensure two-way communication between agents and market middleware, CORBA/RMI method invocations and callbacks are used as the communication model.

At the opening of the market, FBTS middleware starts and interacts with traders. Orders submitted by traders are stored in the limit-order database. The automated matching program starts the matching process as soon as there are two or more orders in the limit-order database. While FBTS middleware is operating, traders can submit orders. First, traders open the client TradeApplet through a browser. After they log into the system, the applet finds the FBTS middleware based on its URL, and sets up RMI and callback connections with the RMI server. Then, the trading window opens, where traders can submit orders. Traders are not limited to trade-only equities. Bundles can be made up of bonds, futures, options, and foreign currencies, so that traders can use bundle trading to effectively construct a portfolio according to investment objectives. A bundle is, in effect, a portfolio. Often, trading portfolios is more efficient than trading individual financial instruments.

To trade bundles, traders define the proportion in the bundle, and enter the price for each bundle and the amount he wants to trade. In Figure 2, for instance, the trader wants to buy a bundle with one unit for each of the first three assets, the price he wants to pay is $5 per bundle, and the amount he wants to buy is 10 bundles. The trader can mix buy-and-sell orders within the bundle. For example, if the trader wants to buy two units of asset 3 and one unit of asset 4, and sell one unit of security 2, he just needs to enter 0, -1, 2, 1, and 0 for the five assets, respectively. He has to specify the bundle price based on his valuation of the bundle. A positive price signals a willingness to pay for trading the bundle, while a negative price signals a willingness to trade the bundle for a gain.

After the trader presses the Submit Order button, the order is sent to the FBTS middleware, and the trader gets a confirmation message from the Market Maker. Then the TradeApplet automatically opens an open-order window displaying a table with the following information: order ID, bundle proportion, offer price, real transaction price, order shares, outstanding shares, accumulated transaction cost. As shown in Figure 3, the limit price for the order with order ID 100 is $5 and Trader a01 wants to buy 10 shares of the bundle. There are four shares left unmatched. Six shares have already being executed at a price of $4.5 with a total transaction cost of $27. As trading goes on, this table is being updated dynamically using the live data feeds from the middleware. The trader can see dynamically how his orders are being executed. It is impossible to achieve this kind of functionality using traditional CGI implementation. In addition, traders are trading in the market directly with the Market Maker without the need of going through brokers. This helps cut transaction costs and expedite transactions.

On the middleware side, when traders submit orders, the order is stored in the limit-order database. Then the Market Maker immediately sends a confirmation message to the trader who just submitted the order. The "monitor" thread starts with FBTS middleware and continuously monitors the order database to see if there are outstanding orders. As long as there is more than one outstanding order, the monitor thread routes orders to the order-matching program. FBTS implements an automated order matching program using a novel bundle-trading mechanism we developed. The order-matching program finds matches by solving a mathematical programming problem. If the program finds a match, it also calculates the transaction price and the transaction amount, and updates the limit-order database by decreasing the outstanding shares for the matched orders. For example, if a buy order with 10 shares is completely matched, then the order-matching program decreases the outstanding shares for the buy order to zero.

Implementing Distributed Objects

The CORBA/RMI distributed-object model ensures a dynamic and interactive agents-to-middleware connection. CORBA provides an infrastructure that allows objects to communicate independent of the specific platforms and techniques used to implement the addressed objects. Using CORBA, we create object interfaces and implement objects using different programming languages. Once these objects are implemented and registered with the system, they can be invoked in the network environment.

RMI, on the other hand, is a significantly easier and lighter-weight approach to developing distributed objects. If web-based applications are implemented in a pure Java environment, it is efficient to implement distributed-object models using RMI. Since our FBTS is operating in a pure Java environment, we used RMI for distributed-object applications. We implemented the Market Maker, for instance, as an RMI remote-object server. Additionally, we built callback functions on the client side for the RMI server to contact clients or push information to clients.

First, we defined a remote interface called MarketMakerInterface, which tells the TradeApplet which method can be invoked on the Market Maker. We then created the MarketMakerImpl class (see Listing One; located at the end of this article), a subclass of UnicastRemoteObject. The MarketMakerImpl class implements methods that are advertised in the MarketMakerInterface: methods SendOrder() and pass(). For remote clients such as the TradeApplet to invoke methods on the Market Maker, the Market Maker registers itself with the RMI registry (see Listing Two). The RMI registry is a Java application that provides a simple naming service through which clients can find RMI server applications. As in Listing Three, the TradeApplet locates the Market Maker based on its URL and registered name, and invokes the Market Maker's method SendOrder() and sends the object order to the Market Maker.

However, we have only established a one-way communication by letting the TradeApplet send orders to the Market Maker. For the Market Maker to push information such as executed orders to the TradeApplet, we have to implement RMI callbacks on the applet. The steps for implementing callbacks on the TradeApplet are:

1. Create a remote interface for the TradeApplet and define a method receive(), which can be invoked by the Market Maker by sending a vector to the TradeApplet. The vector could contain trading information such as number of shares and executed prices for the trade. Using this information, the TradeApplet can update its open-order table.

2. Implement the receive() method defined in the interface for the TradeApplet (see Listing Three).

3. Before contacting the RMI server, the TradeApplet must export itself by implementing UnicastRemoteObject.exportObject(this), where this is the TradeApplet object (Listing Three). By exporting itself, the TradeApplet makes itself available to receive remote calls.

4. While contacting the Market Maker by invoking remote method pass(this) (Listing Three), the TradeApplet passes itself using object serialization to the Market Maker, which puts the TradeApplet object in the Vector tradeClients (Listing One). The Market Maker can then callback the TradeApplet by invoking method receive() and send a vector to the TradeApplet (Listing One).

The client and server distinction has blurred in the RMI framework. When the TradeApplet exports itself as a remote object to the Market Maker, it actually becomes a remote server that can implement remote methods just like an object that extends UnicastRemoteObject. Meanwhile, the Market Maker acts like a client by invoking methods on the TradeApplet. Therefore, TradeApplet and Market Maker are acting as both clients and servers. Client-to-server communication thus becomes more like a peer-to-peer interaction. This reflects a true nature of distributed computing in which an agent can be both a client and a server supporting an interactive application in the network. In terms of information flow, the TradeApplet can pull information from the Market Maker while the Market Maker can also push information dynamically to the TradeApplet.

Web-based distributed applications based on the Java/CORBA framework demonstrate tremendous advantages over applications based on the traditional CGI approach. First, we can implement two-way communications between applets and the middleware using Java/CORBA model. In contrast, CGI can only be invoked on the server. If CGI were used for the trading application, to get open-order tables updated, traders have to resubmit requests to the CGI script on the server. The server does not have a mechanism to push information to the trader. Secondly, information transmission between client and server is not efficient using the CGI approach. Using the Java/CORBA approach, only the values of variables are passed between applet and the middleware while the CGI on the server needs to recreate a web page and send a whole HTML file back to the browser every time the server receives a request. It not only adds more workload on the server, but also increases unnecessary network traffic. We believe as the paradigm of computing is moving toward interactive and dynamic network computing applications, web-based applications are likewise shifting from the CGI approach to Java/CORBA frameworks.

Implementing Asynchronous Trading Processes

Multiple processes go on simultaneously and asynchronously in financial trading. For example, traders send new orders to markets, and the middleware monitors the limit-order database and routes open orders to the automated matching program that is continuously conducting matches. If matches are found, the monitor program updates the limit-order database, notifies corresponding traders, and updates the trader's open-order table. Traders can cancel an open order for any reason. All these processes can happen at the same time, which makes it challenging to implement the processes asynchronously while carrying out the matching in real time.

We implement these multiple trading processes using Java threads (see Figure 4). As soon as the market middleware starts in FBTS's multithreaded environment, the program launches the monitor thread, which monitors the limit-order database. Meanwhile, traders can submit orders for trade. Each time traders send a new order to the middleware, they launch a new thread on the middleware.

Listing Four is pseudocode for the SendOrder() method. The monitor thread, finding new open orders in the limit-order database, routes these orders to the order-matching program. If matches are found, it updates the limit-order table and notifies involved traders. Traders can also cancel open orders, which launches a new thread on the middleware. In FBTS, traders can send orders or cancel existing orders at any time without worry about being blocked. The monitor thread should also run continuously without the possibility of being blocked. By accessing the same database, these threads (which represent different trading processes) execute asynchronously. It is critical that we enable multiple threads to run concurrently but (at the same time) avoid possible interference between threads. Since multiple threads can access the same database, we make sure these threads are not conflicting with each other, leading to errors in the shared data set. Interference between threads could happen while multiple threads try to submit orders at the same time. As Listing Four shows, the SendOrder() method, which is not atomic, sets the order number for the new offer by assigning the current OrderID to that order, increments OrderID, and adds the order into the limit-order table.

Suppose the following occurs:

• Trader A starts to submit an order. Thread A begins to execute the method SendOrder().
• Thread A executes part 1 of the SendOrder() method and is then interrupted by Thread B.
• Trader B starts to submit an order. Thread B begins to execute SendOrder().
• Thread B executes part 1 of the SendOrder() method and is interrupted by Thread A.
• Thread A continues to finish part 2 and 3 of the method SendOrder().
• Thread B finishes part 2 and 3 of the method SendOrder().

You can see this will cause the two orders sent by Traders A and B to have the same order number. You can solve this problem by adding the synchronized keyword to SendOrder() method (see Listing One). This serves as a mutually exclusive lock for the method, allowing only one thread to call the method. Upon completion of the method, the thread automatically releases the lock and lets another thread access the method.

Conclusion

FBTS demonstrates what an e-market application can do and how it can be implemented using cutting-edge technologies. Middleware, implemented as a distributed-application server, will gain tremendous importance in future agent-oriented electronic market applications. The core technologies to build an efficient middleware are a distributed-object framework based on CORBA or RMI, and the multithreaded features of Java.

DDJ

Listing One

// Market Maker implementation. // Implements methods defined in MarketMakerInterface
public class MarketMakerImpl extends UnicastRemoteObject implements
  MarketMakerInterface {
  ...
  // implement the method SendOrder() advertised in interface
  public synchronized int SendOrder(Bundle offer) throws RemoteException {
  ...
  }
  // implement pass() advertised in interface
  public synchronized void pass(TradeAppletInterface o) 
                                                 throws RemoteException {
  ...
    // register TradeApplet in a Vector
    tradeClients.addElement(o);
  ...
  }
  ...
  // Market Maker callback TradeApplet & send it a Vector 
  // by invoking TradeApplet's method receive()
  TradeAppletInterface
               trader=(TradeAppletInterface)tradeClients.elementAt(i);
  trader.receive(somevector);
  ...
}


</p>

Back to Article

Listing Two

// Market Maker object binds itself to be "MM" public class MarketMaker {
  ...
MarketMakerImpl theServer = new MarketMakerImpl("MM"); 
Naming.rebind("MM", theServer);
}


</p>

Back to Article

Listing Three

// TradeApplet public class TradeApplet extends Applet implements TradeAppletInterface,
  java.io.Serializable {
  ... 
  // TradeApplet locate Market Maker object using its URL and registered name
  // Before this, TradeApplet needs to export itself to enable callback
  UnicastRemoteObject.exportObject(this);
  String servername = "rmi://serverURL/" + "MM";
  MarketMaker = (MarketMakerInterface)Naming.lookup(servername);
  


</p>
  // TradeApplet passes itself to Market Maker 
  //              by invoking pass() on MarketMaker
  MarketMaker.pass(this);
  ...
  // TradeApplet send the order by invoking the remote method
  feedback = MarketMaker.SendOrder(order);
  ...
  // implement receive( )
  public void receive(Vector m) {
  ...
  }
  ...
}


</p>

Back to Article

Listing Four

SendOrder (Bundle order)  {
   generate order ID for the new order based on initial order ID;
   increment order ID;
   add order to the open order Vector;
}

Back to Article