page 1  (13 pages)
2to next section

Overview of the DRYAD trading

system implementation

Lea Kutvonen

Department of Computer Science, University of Helsinki

P.O. Box 26, FIN-00014 University of Helsinki, FINLAND

[email protected]

Abstract
The Open Distributed Processing Reference Model (ODP-RM) of ISO and ITU defines a set of basic services which every open system has to support and use. One of such services is the trading function. The purpose of the trading function is to help objects, for example application program components, to discover target objects in a dynamic network environment. In this paper, we introduce trading as means to establish contracts between objects. Contract establishment facilitates distribution transparent access of services over autonomously administered subsystems. We also discuss an experimental prototype of an ODP like trading system. The platform for the DRYAD trader is a UNIX environment supplemented with a special-purpose database management system.

Keywords
Open Distributed Processing, trading, contract

1 INTRODUCTION

Interworking between autonomous systems relies on support from an information service that can provide dynamic knowledge about available service providers within the network. The trading service (ISO, 1994), as described by the Open Distributed Processing Reference Model (ODP-RM) (ISO, 1995), offers such a service.

In the DRYAD project we have studied the ODP infrastructure model and implemented prototypes of some ODP services. Figure 1 illustrates the components addressed: service invocation, binding, trading, and type and policy repositories. The communication layer is realized by the operating systems facilities. We consider these as the fundamental functions needed for distribution transparent service interoperation in heterogeneous environment.

The service invocations cover the announcements and the interrogations as they are described in the ODP-RM (Kutvonen, Feb. 1995). Service invocation relies on implicit binding services. Each object in the system (e.g., a component object of an application system) has one or more server role interfaces offering operations for other objects to invoke. Also, each object has client role interfaces that represent views to the used services. The infrastructure services support these views. The type repository functions verify