Object Frameworks for Electronic Commerce

Using Distributed Objects for Brokerage on the Web


In the call for position papers, the following questions were raised:

"Convergence of ORB and Web architectures. (Why) are both camps doing the same things differently?"

Current e-commerce infrastructure and systems provide very weak support for electronic brokerage and negotiations. In this position paper and our initial work, we use procurement as the context of such functionality. Procurement is one of the most important business functions. The proportion of income dollars spent on purchasing, especially in highly mechanized mass-production industries, is relatively high. New networking technologies have the potential to radically change the way procurement is done. However, as was mentioned above, current e-commerce systems provide only very weak support for electronic brokerage. In the next couple of paragraphs we elaborate some more on the marketplace and infrastructure requirements and limitations. Following that, we will summarize a research project that addresses the functionality of component-based commerce in the context of procurement.

Electronic commerce and the Internet will introduce a new marketspace with new methods of procurement. The ubiquity will make it possible for much larger numbers of companies to participate in the new marketspace, and the open interoperable standards will make it easier for each company to "plug in" to the marketspace. However, current Web-based e-commerce systems suffer from several shortcomings. HTTP is an insufficient protocol for the multi-step transactions needed in e-commerce; moreover, the missing interoperability between existing e-commerce systems causes serious problems. It is one of the main reasons that there is no information brokerage infrastructure on the Web. However, electronic brokers (e-brokers) are an important prerequisite for many forms of emerging electronic markets with lots of unknown participants. The establishment of a solid broker infrastructure will catalyze many of those markets.

Distributed object standards like CORBA make it much easier to achieve interoperability between software components in a heterogeneous environment. Thus, our work focuses on the establishment of a broker-based object framework called OFFER (A Broker-based Object Framework For Electronic Requisitioning). The e-broker in OFFER assists the user in his search in many, often unknown e-catalogs of suppliers and provides auction mechanisms to support the price negotiation. OFFER is a research prototype of a reusable framework for e-procurement and business-to-business e-commerce. We investigate the necessary roles, processes and functions performed in e-procurement and the components needed to support them. Its main purpose is to obtain deeper insight into the architecture of e-commerce frameworks. Moreover, the project should provide knowledge about the functionality of the required software components, their granularity and the interaction between them.

The combination of CORBA and Java has proven to be a solid platform for complex distributed applications in a number of cases (see Orfali, Harkey, 1997). Thus we use the Visigenic Visibroker for Java 3.0 and the Java language as distribution infrastructure for the OFFER framework. Moreover we use the OMG Interface Definition Language (IDL) to specify interfaces of e-commerce components. Currently OFFER is focused on the brokerage problem. The business model consists of suppliers, customers and e-brokers. Suppliers and e-brokers offer services, which can be accessed over the Internet.

Services of the OFFER Broker


Suppliers publish an e-catalog to the customer and they can also register this e-catalog with an e-broker. This enables the customer to search for an offer either directly in the e-catalog of a supplier or via the e-broker in all the registered e-catalogs. We specified a standard CORBA IDL interface for the e-catalogs of a supplier and for the e-broker. Each supplier is responsible for implementing this interface. The implementations can be in any CORBA-compliant language such as C++, Java or Smalltalk. In order to find a service with the e-broker, client issues are registered with the search() method call. The e-broker also allows CORBA clients to query which suppliers, and allows new suppliers to register their e-catalogs with the e-broker. It is easy to build new value-added services on top of those of the e-broker.

There are several advantages of using the CORBA-based search over existing CGI-based implementations (see also Schwarzhoff, 1997). First, CORBA 2.0 provides IIOP, a very efficient state-supporting protocol on the Internet. Second, CORBA separates interface from implementation and provides language-neutral data types that make it possible to call objects across language and operating system boundaries. Thus a CORBA-based e-catalog can change its implementation without requiring the e-broker to rewrite its interface. In current client/server systems, the API is often tightly bound to the implementation, which makes it very sensitive to changes. Finally, the CORBA programmer does not have to be concerned with transports of parameters across dissimilar platforms. Of course the CORBA-approach also requires, that all suppliers of a market agree on a certain interface standard of their e-catalogs.

Broker-assisted Negotiation Support

While the searching and payment functions have been relatively successfully automated in existing e-procurement systems, the automation of the negotiation is still in its infancy. There is very little bargaining successfully done automatically, and that which is done tends to be in research laboratories in extremely controlled settings. Auctions are successful where other negotiation mechanisms have failed, because they solve the ontology problem (the item is successfully described at the outset and cannot change during the course of the auction). Moreover they restrict the bargaining space to a single computer-friendly dimension: price. It is straightforward and easy to implement, and from the buyer's perspective it is relatively easily understood. Auction mechanisms can be applied as a means of distribution on the sellers' side as well as for purchasing purposes on the buyers' side.

An e-broker provides a centralized marketplace, where many buyers and suppliers meet. Hence, a broker has the necessary publicity to offer various kinds of auction mechanisms matching the requirements of buyers with the abilities of suppliers. The e-broker in OFFER implements a series of auction mechanisms to trade goods and services.

Well designed frameworks provide reusable architectures with flexibility in the right places. Since different auction mechanisms are suited for different situations, we decided to handle this as a hot spot in the OFFER e-broker. Hot spots are exchangeable components, which should guarantee the flexibility of the framework in future applications (Pree, 1997). We achieve this flexibility through abstract coupling of the e-broker class with the auction class (shown in Figure 1).

Figure 1: UML Class Diagram of the Abstract Coupling of Classes

A client can open any type of auction with the e-broker. For the start() and bid() operations this doesn't make a difference. However, each auction computest the winner in its own way. Additionally, an English Auction requires additional operations to get a market overview or to show how much time is left, until the auction closes.


"Good frameworks are usually the result of many design iterations and a lot of hard work" (Wirfs-Brock, Johnson 1990). OFFER is a good testbed to show the usefulness of distributed object technology for e-commerce. It shows how easy it is to set up and maintain e-brokers in such an environment. Moreover we show the usefulness of auction mechanisms for trading on the Internet.

In our research we address different problems within the area electronic commerce and distributed systems. In the future we will explore the role of our e-broker as trusted third party providing services like a letter of credit or contracting. We want to achieve a closer integration with existing CORBA object services like the Trader Service. We will also try to tackle the ontology issue in different ways. Moreover, we hope to achieve a closer integration with existing CORBA object services like the Trader Service. The Trader Service provides appropriate mechanisms for the discovery of resources through the issue of requests, and, given a well-defined request, can match resources. The ECDTF has also issued an RFP for a Negotiation Facility, which might bring interesting results, but the responses are still pending. Finally, we plan to derive design patterns for e-procurement frameworks. Patterns focus on the result of object-oriented analysis and design - the models themselves - and are thus well-suited for the transfer of knowledge (Fowler, 1997). The patterns shall describe the architecture of the OFFER framework to make its design decisions comparable and reusable.


Copyright 1997. A. Segev, C. Beam, M. Bichler. All rights reserved.