Check out the new USENIX Web site. next up previous
Next: The CosTrading Service Up: TORBA: Trading Contracts for Previous: Abstract

Introduction

Nowadays, building, deploying, and running distributed applications rely on a set of services/functions offered by standard middleware like the Common Object Request Broker Architecture [19] (CORBA) of the Object Management Group (OMG), the Distributed Component Object Model [8] (DCOM) of Microsoft, and more recently the Java Remote Method Invocation [24] (RMI) of Sun Microsystems. The main functions of such middleware solutions are synchronous communication using operation invocation, asynchronous communication through message or event passing, transaction monitors, security, persistence, and resource trading. This paper proposes an innovative framework named Trader Oriented Request Broker Architecture (TORBA) to trade distributed objects over CORBA.

A middleware trading function tends to provide a means to discover resources available in a distributed system, in order to dynamically interconnect at runtime the various components of an application. For example, it allows a client to find back its associated server. Such a search may be based upon various criteria, like the physical location of the resource (e.g. to find the printer service of the third floor), the symbolic name of the resource (e.g. to find the BestPrint printer), or the characterization of the resource using its properties (e.g. find a color printer faster than ten pages per minute). The conceptual contribution of this paper is to define the concept of trading contract in order to characterize both the resource properties, and the search operations used by client applications.

The trading function has been studied both in academic projects and industrial products. Some projects have focussed on the interest of using such a function in a large scale context in order to share resources [16]. In 1993, the ANSA consortium has discussed what the trading function should be [7]. More recently, Sun Microsystems has defined a trading function, included in the Jini environment [1]. Based on the easiness with Java to serialize objects, this trading function allows applications to retrieve serialized objects (like network stubs or complete services). Other research works have focussed on traders federations [5], performance [6], and scalability [26]. In the context of object trading, the first technical contribution of this paper is an innovative approach that simplifies and types the use of a trading function.

In order to standardize middleware trading function, the International Standardization Organization (ISO) in its Open Distributed Processing [11] (ODP) activity and the Object Management Group (OMG) have defined a specification of the functional interfaces of such a function [17] using the OMG Interface Definition Language (OMG IDL). This specification is mainly based on the work previously performed by the ANSA consortium [7] and the DSTC [28]. It defines a set of generic APIs for applications to export and search CORBA object references in a standard and portable way, whatever the underlying implementation. Unfortunately, these APIs are quite complex to use and very technical. Moreover, using these APIs does not provide trading request type checking at compilation time, but only at runtime. Thus, the second technical contribution of this paper is to perform trading request type checking at compilation time, improving software quality and reliability.

The objective of our work is to define and to offer a typed trading environment being easy to use from CORBA applications. In that, we have defined the trading contract concept used to describe typed properties (object characterizations) as well as query operations to be used by applications. The TORBA Definition Language (TDL) is used to define these contracts. Then, it is compiled to generate trading proxies offering simple specialized interfaces to be used from client applications. The use of these interfaces is checked at compilation time, based on their types (i.e. operation synopsis). Furthermore, these proxy implementations completely hide the technical complexity of the ODP/OMG trader interfaces. In the meantime, TDL contracts could be stored in a TDL repository, like OMG IDL definitions are stored in CORBA's Interface Repository. Then, this repository could be used dynamically from a graphical console to discover available trading offers and to use defined query operations.

Section 2 of this paper presents an overview of the ODP/OMG CosTrading service. This overview focuses on trading offer typing and use of the query operation, in order to outline their drawbacks: technical complexity and lack of type checking. Section 3 discusses the trading contract concept, the TDL language, the proxy generation and execution process, as well as the dynamic approach. It also presents the implementation of TORBA, using a printer service as example to underline the benefits of our approach. Since TORBA use has only been performed using simple examples, section 4 presents some empirical results. Section 5 discusses the related work in middleware that are used in TORBA: the proxy concept, the structure of ORBs, and the component-oriented approach. Finally, section 6 summarizes this paper, in progress, as well as fore-coming work directions.


next up previous
Next: The CosTrading Service Up: TORBA: Trading Contracts for Previous: Abstract
Raphael Marvie
2000-12-05