Introduction

At the level of individual computers, operating systems shield applications from system details by providing direct access to general system services. In the same way, middleware supports transparency in remote services provided over networked information systems. In the realm of electronic commerce, the role of middleware is to support the basic operations that might take place within a commercial interaction. Although the varieties of commerce activities are legion, as long as they share some fundamental components, reusable middleware services can offer substantial leverage. For example, the fundamental step of executing an exchange transaction is common to many contexts, and so general infrastructure supporting this operation will have many uses.

A significant burden of middleware, however, is to support a diversity of commercial communities--equity and commodity markets, manufacturing supplier chains, mail-order retail, and publishing, just to name a few. Each such community comes with its own particular vocabularies, institutions, and conventions, evolved for its own purposes and entrenched to varying degrees. This suggests that despite any fundamental commonalities, commerce middleware services need to be flexible and extensible to support (at least) the range of practices we find in the natural commercial world.

An agent wishing to participate in a commercial interaction (an exchange of some good or service, which we generically call a good ) must face each of the following questions on entry to a commerce environment:

1.

How can I describe what I want to exchange?

2.

Where can I exchange the good and under what terms?

3.

Who can I exchange with?

4.

How can we execute the transaction?

Addressing each of these questions constitutes a step in a comprehensive commerce process. More specialized commerce environments, such as business-to-consumer commerce, might include additional steps such as promotion. The role of commerce middleware is to serve agents taking these steps. One can conceive of reusable support services targeted at individual steps (or parts of steps), or those spanning multiple steps [9].

Probably the most well-defined of these steps is the fourth--executing the transaction--and indeed, the largest share of middleware services termed ``electronic commerce'' primarily address this step. Early payment protocols, such as those developed by First Virtual (https://www.firstvirtual.com/) and Digicash (https://www.digicash.com/), as well as proposed generic frameworks [11], clearly fall in this category. As pointed out by MacKie-Mason and White [14], even this relatively circumscribed step presents interesting design choices along many dimensions.

Probably the least well-defined step is the first--describing the good. Ongoing work in developing descriptive metadata for e-commerce ranges from formalizing license terms descriptions [19] to more ad hoc discussions of XML-based content definitions such as CommerceNet's XML exchange (https://www.xmlx.com).

In this paper, we focus on middleware services for step two. However, we build on the growing presence and increasing understanding of the value of on-line auctions [20] for step three--setting the terms of an agreement and matching buyers with sellers.

We describe here an Auction Manager , a commerce middleware component designed to simplify and automate both the creation of new markets and the matching of agents to existing markets. Some standalone products aim to provide some of this function. For example, shopping agents, such as Bargain Finder (https://bf.cstar.ac.com/bf) and Jango [6] (https://www.jango.com), provide consumers with compilations of Internet vendors' prices for products such as music CDs or software. In contrast, middleware for this type of task is more infrastructural, serving individual functions as generally as possible, in the context of supporting an overall commerce process. In particular, generic infrastructure for step two could not assume a market model where vendors announce a fixed price for consumers to take or leave. Rather, there might be many modes of negotiation, which market-matching services should take into account in identifying potential matches.

The Auction Manager operates within a dynamic environment, by matching descriptions of goods to existing markets and, when appropriate, creating new markets. While market is often used as a non-technical term, we use it here to refer specifically to an auction and its authorized types of participating agents (e.g., stock markets permit only certain authorized broker agent types to participate).

Implicit in the Auction Manager's support for market-matching operations are questions of market policy. For example, when and for what goods should new markets be started? How does the system account for market creation costs? How are community rules, norms, and objectives (if any) expressed--through regulations or incentives?

The Auction Manager was built as part of the University of Michigan Digital Library [2] (UMDL) commerce infrastructure. Whereas UMDL's goal is the provision of library services to library users, the explict realization of that goal is to provide a commerce infrastructure that supports the process of describing, locating, and negotiating for a wide variety of information services.

However, this commerce infrastructure is not restricted or specific to digital libraries. Since UMDL cannot know at design-time what services will be available in the future or what the best negotiation mechanisms are for any given situation, its languages and protocols have been designed for flexibility and extensibility. One of the advantages of this flexibility is that UMDL provides a testbed, allowing us to experiment with different mechanisms in different contexts.

Within the UMDL, library exchanges focus on a particular kind of good--information services. Therefore, in the next sections we often refer to goods when describing abstract exchanges, while referring to particular information services in our more concrete examples.

In the next section, we describe our generic commerce infrastructure. Our main aim is not to describe the existing UMDL architecture in detail, but to give an overview of the context in which the Auction Manager operates. In Sections 3 and 4, we focus on the commerce middleware services of the Auction Manager.