Achieving Interoperability through ODP Trading Function

Lea Kutvonen

Department of Computer Science

University of Helsinki

P.O. Box 26 (Teollisuuskatu 23), FIN-00014 University of Helsinki, Finland

Abstract

Interoperability between autonomous decentralized systems needs support of an information service that can provide dynamic knowledge about available service providers within the network. In this paper, we describe trading service. Trading is an essential infrastructure function indicated by ODP (Open Distributed Processing) reference model, a metamodel of heterogeneous distributed processing. The purpose of trading is to support location transparency of services: it hides the location of service providers, even if they are located in separate, autonomous domains. Cooperation between trading service providers (traders) supports federation transparency, i.e. hides differences of technology used in separate domains. In cooperation, the traders have to mediate service type differences, negotiate policy differences and tolerate technology differences between domains. Together with other fundamental functions trading offers a platform for open distributed computing between autonomous subsystems.

1 Introduction

ODP (Open Distributed Processing) is a framework for systems that support heterogeneous distributed processing [5], [10]. This framework has been under development since the late 1980's within ISO and ITU as a joint effort. The standardization effort produces a reference model that organizes the discussion about distributed systems. It supports the design process of new standards and real systems by dividing the complex tasks into viewpoints. It also defines new service functions to be used within the viewpoints.

The goal of the ODP framework is to provide a distribution transparent environment for software components to interwork, despite they are supported by heterogeneous, autonomous platforms. Achievement of distribution transparency requires hiding of failures, locations and implementation technologies of service providers.

In the ODP framework, software components (and hardware, as well) are modeled as objects that request services (defined actions) from their environment (other objects). These requests, interactions, take place via interfaces. An object can initiate operations at another object by binding itself into an interface at the target object. Objects willing to interact may be located at distinct nodes, they may use dif-

ferent representation of operations and they may be introduced to the global system independently. For example, in a system, two authors might work on a shared document with differing tools, each from their own computers in their organizational networks. The considered objects in this example are the editing tools and the shared document file itself. Operations offered at the document object interface are reading, writing and locking of the whole document or well defined parts of it. Other examples of objects are representations of telephone switches, operating systems, and employees.

The key problems are, how the objects know, where the possible interfaces are located, how to choose between them, and how to transform between different task representations. Especially in decentralized environments, a supporting service is needed for objects to locate each other. The objects need a logically centralized location at which they may request information about the available interfaces. This supporting service is called the trading function. It is a general tool for flexible discovery of targets in a dynamic network environment. Targets are addressed by property descriptions that constrain the set of potential targets to a set that contains only the most suitable ones. The trading service can be considered as an advanced directory service which allows attribute-based search. The attributes can be evaluated at search time, and hence, the trader is able to check the availability or reachability of each purported target.

Trading service facilitates late binding of objects. Late binding means that an initiating object may invoke an operation at another object, whose identity or location it did not know before the invocation actually happened. An object can even use the services of an object created later than the initiating object itself. Late binding has the benefit of allowing flexible system evolution. It also helps to achieve improved availability and fault tolerance within the system, as objects may dynamically change the service provider they choose to interact with. For instance, if the client has statically bound itself to a name server or to a research database in a computer A that fails, it can not work until the computer A is brought up again. However, if the client utilizes the trading services, it can rebind itself to a similar server in a computer B instead, and obtain the required information there.

The foreseen usage of the trading function in the ODP framework is to support inter-object communication via interrogations and announcements [5]. The