ng96.pdf. It's a snapshot of the page taken as our search engine crawled the Web.
The web site itself may have changed. You can check the current page or check for previous versions at the Internet Archive. Yahoo! is not affiliated with the authors of this page or responsible for its content.
The trading function in action

The

trading function

in action

Bruce Jacob and Trevor Mudge

Advanced Computer Architecture Lab
EECS Department, University of Michigan
{blj,tnm}@eecs.umich.edu

This paper describes a commercial software and hardware platform for telecommunications and multimedia processing. The soft-
ware architecture loosely follows the CORBA and ODP standards of distributed computing and supports a number of application
types on different hardware congurations. This paper is the result of lessons learned in the process of designing, building, and mod-
ifying an industrial telecommunications platform. In particular, the use of the trading function in the design of the system led to such
benets as support for the dynamic evolution of the system, the ability to dynamically add services and data types to a running sys-
tem, support for heterogeneous systems, and a simple design performing well enough to handle trafc in excess of 40,000 busy-hour
calls.

Introduction

This paper describes several benets of the trading function in the context of a commercial closed systemthe Telecom
Services Architecture, a commercial architecture that handles the transport and processing of several hundred concur-
rent IO streams. The software architecture of the system loosely follows the CORBA and ODP standards of distributed
computing [OMG93, ITU92] and supports a number of applications on many hardware organizations. The system is
organized around the principle of the ODP trading function. The key advantage to the trading function is the exibility
it affords a system; while exibility is desirable in an academic system, it is vital in a commercial system.
The following are a few of the realities of commercial systems.

The requirements of the system are constantly being modied, due to decisions in the marketing department, reac-
tions to market trends, or specic customer demands. This activity generally results in changes to the product speci-
cation. The changes typically occur more rapidly than the development team can nish implementing the previous
changes to the specication.

Customers frequently want special features that no other customer wants. This places demands on the exibility,
modularity, and generality of the product design. However, too much generality is bad when it results in a system
that does not perform well.

The product is occasionally blind-sided with requirements for features that were not foreseen or planned for in the
original design. For example, scalability is an obvious future requirement for a product; is it likely that customers
will want larger or faster systems in the future. By contrast, support for an Internet connection is non-obvious; sev-
eral years ago few could have predicted the rapid commercial rush to the Internet and the World-Wide Web.
The

trading function

of the CCITT ODP Recommendation [ITU92, ITU94] is a simple concept that indirectly
addresses these concerns. In the trading function, a

trader

acts as a yellow pages directory for services. Server objects
that wish to offer services advertise, or

export

, their capabilities to the trader. An advertisement consists of a description
of the service and the location of an interface providing the service. Client objects that wish to obtain services send
requests to the trader and then

import

information about servers that match their needs. A client request is a simple
description of a service desired; the trader matches client requests against the descriptions provided by the server
objects.
Though this may seem to be designed with a heterogeneous on-line marketplace in mind, it maps very well to a closed
system in which the environment is likely to change. In such a system, the less state spread around the server and client
objects (either explicitly or implicitly) the better. In live systems, for instance those handling telephone calls or monitor-
ing medical equipment, when software is upgraded it is unacceptable to restart the system software, let alone restart the
operating system or reboot the machine. However, if new data types or services are added to the system it is frequently
the case that much of the software needs to be replaced or restarted. This is necessary to let servers know about the new

In the Proceedings of the Seventh ACM SIGOPS European Workshop, Connemara Ireland, September 1996, pp. 241-247.
data types and clients know about the new services. Object-oriented designs can mitigate this problem by having self-
describing data types, but they seem to represent a smaller portion of industrial software than one would expect.
A system that is based around the trading function naturally tends toward a design where the objects involved know
very little about each other, and we have found that the amount of state in the system can be reduced to the following:

Servers need only know how to reach the trader and the names and interfaces of the services they offer.

Clients need only know how to reach the trader and the names and interfaces of the services they need,
This is very important: clients do not need to know what servers provide what services or where they are located, serv-
ers need only know the location of the trader (as well as the agreed-upon service interfaces, trivial in a closed system),
and the trader can be more or less stateless.
The following sections describe our system software and hardware, and illustrate a few of the benets of a system orga-
nized around the trading principle.

Software design

Fig 1 illustrates the software architecture at a high level of abstraction. It is an example of the

active object model

, using
a popular taxonomy [Chin88]. The system is made up of numerous interacting objects, each of which is a collection of
methods bound to service names. The service names are globally visible, and advertised through a central point. Server
objects advertise their services through the central point, and client objects obtain the services through this point.
It is a loose implementation of the trading function the ODP Recommendation, not a strict implementation, as the archi-
tecture was dened in 1991 before the ODP Trading Function draft was published (in 1994 [ITU94]). In the trading
function, exporting servers advertise their services to the trader, who retains the state and acts like a service database to
inquiring clients. Importing clients make requests of the trader of the form, give me a service which behaves like the
following ... The Telecom Services Architecture is a bit different in that since it is a closed system, a client may assume
that any service it requests is offered somewhere in the system. Therefore the trader can be stateless, as it does not need
to be able to return a message of the form, no such service exists. Clients post requests to the trader, where they are
placed on a prioritized queue from which servers pick up requests they can handle.
This is different from the ODP trading function, where servers advertise rst and then wait for client requests to arrive.
In the Telecom Services Architecture, the client objects place requests with the trader. Servers poll the trader for work to
AN OBJECT:
THE
META-CLASS
TRANSPORT LAYER
OBJECT
METHODS
bound to
SERVICE
NAMES:
:A
:B
:C
:D
Figure 1. High level software organization: Object interactions
do; when a server registers itself with the trader it is implicitly ready for work at that moment. This way the trader never
has to tell a server to wake up (and potentially block), and clients are never (or, at least

rarely

) in the position of having
to deal with defunct servers who leave stale service advertisements with the trader.
The system is comprised of two primary elements:

Distributed persistent objects.

Applications in the system are implemented as objects, all derived from a single
meta-class which provides method invocation and communication to other objects in the system, transparently to
the object itself. An object method executes when another object, or another method within the same object,
requests the service bound to that method. A method wakes up with a service request in its lap, and performs the
service. When nished processing, the method returns a service reply and exits.

The trading functiondescriptive lookup of object methods.

Objects do not reference each other or each others
methods directly. The methods are bound to global descriptive service names, such as print or fax or video.
All methods which implement the same service are bound to the same service name. An object requiring a service
therefore requests the print service or the fax service. Requests go to the central

trader

, where they are inserted
into a timeout queue similar to the callout table in Unix [Bach86]. Thus, an object needing a particular service only
needs to know the name of the service, the interface of the service, and the address of the trader.
Fig