RHODOS
March 15, 1993
Trader Cooperation to Enable Object Sharing among Users of Homogenous Distributed Systems* Y. Ni and A. Goscinski (
[email protected],
[email protected] )
School of Computing and Mathematics Deakin University Geelong, Victoria 3217
Abstract This paper demonstrates that it is possible to build a trading service which allows users to access objects of remote distributed systems. This service is an extension to an original RHODOS trader which provides the maximum possible autonomy and flexibility to users yet at the same time allows them to share all accessible objects (resource, service) within a local distributed computer system. We demonstrated that concepts, such as attribute names, name domains, the operations of object export, import and withdrawal, are necessary to achieving object sharing among a number of users of independent homogeneous distributed computer systems which form together a large heterogeneous distributed system. We also show how location transparency can be achieved by the cooperation between traders based on attribute names and that the use of attributes has the potential to make resource sharing effective and efficient.
* This work was partly supported by Australian Research Council under Grant A48831034 and the Deakin University Research Grant 0504054151.
RHODOS
1
March 15, 1993
Introduction
Homogeneous distributed systems have been developed and extensively studied because they allow users to share objects: computational and peripheral resources, services and information. These systems, referred to in this paper as local distributed systems, consist of a number of individual workstations and peripheral resources (e.g., disks, printers, plotters) connected by a local area network. These computers and resources are controlled by a distributed operating system which supports object sharing within the local distributed system. Because of the object distribution complexities which are inherent in a distributed computer system, and the lack of full information about all objects in the system, the methods and algorithms developed for object sharing in centralized operating systems cannot be used. This has led to the need to find new methods to manage objects in the system. As suggested in [Goscinski and Bearman 1990], [van der Linden 1990] and [van der Linden and Sventek 1992], this problem can be solved by providing a new class of naming servers and object managers called traders. The work that has been carried out in the RHODOS project has proved that it is possible to create a trader based on a naming facility within a local homogeneous distributed system ([Goscinski and Indulska 1992, Haddock and Goscinski 1991]). The prototype of a trader, which provides the maximum possible autonomy and flexibility to users, yet at the same time allows them to share all accessible objects, has been developed for a distributed system supported by an attribute naming facility [Goscinski 1993]. It is based on the concepts of user and system domains, the concept of a context, and explores the operations of object export, withdrawal, and import. These original concepts and operations allow a user to export an object in order to make it visible to other users, sharable subject to export conditions, and to import this object by other specified users in order to access it according to an agreement between the object exporter and the user who wants to use it. It is the task of a trader to provide all these services. In many cases, some institutions using distributed systems cannot afford to purchase special peripheral devices or software. However, users of these system may want to use such devices to improve their performance and to achieve better quality. These special objects (resources, services) are affordable or have already been bought by other institutions thus they are available in some local distributed systems. By connecting a number of similar local distributed systems to form a homogeneous large distributed system, users of each local system should be able to share those objects which are not available in their local systems. An extension to the initially-implemented RHODOS trader has been made, which allows trading to be provided to two or more homogeneous local distributed systems. Thus, the extension to the RHODOS trader allows an object to be exported from one RHODOS system to another or imported from a remote RHODOS system into the local one. This gives users of the RHODOS system the potential to access more objects than those which are available on their local system. The aim of the paper is to present the design and the implementation of a prototype of a trading facility for a homogeneous large distributed system built from homogeneous independent local distributed systems. Such a facility has been built in a homogeneous environment consisting of a group of RHODOS distributed systems supported by an attribute naming facility. The paper also discusses the experience gained from the work. This paper is organized in the following way. Section 2 deals with object trading among users of connected homogeneous distributed systems. In Section 3, the logical design of the RHODOS trader is presented, including the trading operations and trading databases. Section 4 contains the implementation aspects of the prototype, i.e., traders and their components, cooperation between traders and the algorithms of trading operations. Finally, a summary of results achieved and the scope of future work are given in the Conclusion section.
1
RHODOS
2
March 15, 1993
Trading between homogeneous distributed systems
The trading model is based on the concepts of object export and object import. It is assumed that a single distributed operating system supports a number of users who have their own private objects and keep exclusive control of them. The object export is performed by objects owners who wish their private objects to be made available for use by other users. An object owner exports an object and provides specified export conditions. Another user who wishes to use the object imports the object and following the export conditions. Importing users should be able to select those objects that best suit their needs. Trading is then defined as an activity of exporting and importing. This activity is aimed at choosing and sharing objects such that they match some specific requirements. The choice is based on the comparison of a user requirement specification and object descriptions which are supplied by an object exporter. The sharing is subject to the export conditions provided by an exporter and agreed to by an importer. A trader is a software entity which provides a trading service to both object exporters and importers. This implies that an object must be described by a suitable name scheme and that the object descriptions must be known by traders. By connecting a number of homogeneous local distributed systems, a homogeneous large distributed sytem can be formed (see Fig. 1). The term homogeneous referred to in this paper is in the sense that each local system is under the control of an identical distributed operating system. This implies: firstly, all local systems follow the same naming conventions; secondly, the user/system interfaces provided by each local operating system are identical; thirdly, all local systems have similar system/system communication interfaces and the transport protocols. However, the possibility that the peripheral devices and software services of local systems are heterogeneous and, moreover, the architectures of local systems or processors of local systems are diverse, is not excluded.
local distributed system 1
local distributed system 2
TS1
TS2
local distributed system 3
TS3
communication system
TS —Trading Server (Trader) Figure 1: A distributed trading service in a large homogeneous distributed system. One of the fundamental features of a distributed operating system is transparency [Goscinski 1991]. Thus, a trading service in a homogeneous large distributed system should also provide location transparency to users. This means that users should have a uniform view of both local and remote objects and they need not be aware of the location where their jobs are executed the local system or a remote system. Location transparency can be achieved by building a trading service which is implemented by a number of cooperating traders, with one in each local system, as shown in Figure 1. Each trader is responsible for local sharable objects. With this distributed implementation of a trading service, a user need only contact the local trader when exporting or importing an object. By cooperating with remote traders, the local trader is able to locate an object which is not
2
RHODOS
March 15, 1993
available in the local system, import it and enable a requesting user to access the object. As objects in a large homogeneous distributed system are named using the same name conventions, there is a requirement for a trader to distinguish objects in different local systems. This can be done by introducing the concept of a naming domain. A naming domain is a set of objects in which objects are administrated by one operating system following one naming convention.
3
The architecture of the trading facility
The architecture of a trading service for a large homogeneous system consisting of distributed systems controlled by the RHODOS distributed operating systems [Gerrity et al., 1991] is shown in Figure 2. The trading service is of a distributed nature built as a set of local cooperating traders. Each local trader is such a part of the RHODOS distributed operating system [Goscinski, 1993], which: • preserves user autonomy as in a centralized environment; • supports sharing both by allowing objects either to be exported to other domains or to be withdrawn from service, and by allowing objects which have been exported by users from other domains to be imported; • is based on attribute names, in order to improve user-friendliness and to easily access the objects and service in a distributed environment; • provides a conventional mapping of user names to system names, an enquiry service which allows a user to obtain information about an object, and a selection service which allows an object to be accessed by a process based on a set of attributes. The RHODOS naming and trading facility which trades objects within a local RHODOS system [Haddock and Goscinski, 1991, 1993] consists of two servers which perform two distinctive sets of functions: • a name server which provides the conventional naming operations, such as creating an object, changing an object name, deleting an object, changing an object attribute, etc., and • a trader which provides trading operations, i.e., exporting, importing, and withdrawing of objects.
user 1
•••
user n
user 1
server agent
name server
user m
•••
server agent
trader
name server
naming and trading database
trader
naming and trading database
RHODOS trader 1
RHODOS trader 2
Figure 2: The architecture of the trading service.
3
RHODOS
March 15, 1993
The traders presented in this paper are extensions to the initially-implemented RHODOS trader. These new traders can cooperate with each other to allow users to access objects which are managed by other RHODOS systems.
3.1 Trading domains A trader is responsible for managing sharable objects: those which have been exported to other domains by their owners in the local system, and those which have been imported form remote system by local users. The RHODOS trader distinguishes these sharable objects from ordinary RHODOS objects by means of domains; in particular, a trading domain. All objects of the RHODOS operating system belong to the RHODOS naming domain. These objects can be grouped into three classes: • private objects those owned by individual users, • system objects those owned by the RHODOS operating system, and • shared objects those exported by their owners or a system administrator working on behalf of the operating system and which can be imported by other users. Consequently, these objects belong to three subdomains of the RHODOS domain: user subdomains, a system/administrator subdomain and a trading subdomain, respectively. The structure of the RHODOS naming domain is shown in Figure 3. Thus, objects in the RHODOS sytem belong either to a given user domain or to the administrator domain. A user or the administrator is the owner of objects in his/her domain and controls access to objects in his/her domain.
RHODOS domain
••• system/ administrator subdomian
user subdomain
user subdomain
trading subdmain
Figure 3: Structure of the RHODOS domain Belonging to the subdomain implies that each RHODOS object can be: • invisible to all users except the owner, if it is only in a user or the system/administrator domain, • visible to users in other user domains specified by the owner after exporting to the trading domain but not accessible by them, or • visible and accessible by those users who imported it. In the latter two cases, the object belongs to both the trading and the owner’s domains (Fig. 4). Note that though an exported object is ‘seen’ and accessible after the completion of the import operation by other users, the exporter is still responsible for the exported object. This implies that only the exporter can carry out operations on the object in order to change its attributes, access rights, etc.
4
RHODOS
March 15, 1993
administrator domain Trading domain
user domain
Figure 4: Sharable objects in name domains. The RHODOS naming domain consists of a number of disjoint subsets of the RHODOS objects (Fig. 5). This separation provides autonomy to users and the system. The RHODOS trading domain is a union of private and system objects exported by their users and the system administrator, respectively. However, objects which are in the trading domain are still in their owners’ domain. The creation of the trading domain makes sharing between different autonomous users possible.
user domain user domain
user domain
trading domain
user domain
system/ administrator domain
user domain
user domain
RHODOS domains Figure 5: Logical structure of RHODOS domains By connecting the RHODOS systems together, both users of the local system and users of the remote system can share the objects in a RHODOS trading domain via the RHODOS traders.
3.2 Trading service operations There are three basic operations that are provided by a trading service: export, import and withdrawal.
3.2.1
Export
The owner of an object registers the object to the local trader through an export operation. After successful completion of the export operation, the object becomes visible in the domain(s) to which it has been exported. The export primitive is defined as follows: export attribute [, attribute]; domain [, domain]; export conditions; When exporting an object, the exporter invokes an export primitive operation with three parameters. The parameters passed to the export operation are:
5
RHODOS
March 15, 1993 • attribute list a sequence of the object attributes specified by the exporter. This sequence should be an evaluable RHODOS attribute name; • domain list a list of the name(s) of the domain(s) to which the object is to be exported; • export conditions a list of conditions specified by the owner, including the time period during which the object will be available, the cost of using the object and the conditions under which the object may be withdrawn.
There are no restrictions on the domains to which objects can be exported. It can be another user domain in the RHODOS domain or another RHODOS domain. After execution of the export primitive, an entry about the exported object is placed in the local trading database.
3.2.2
Import
An exported object must be imported before a user in another system can access it. To import an object, a user issues an import operation with the specifications of a required object. This specification is in the form of an attribute name. The definition of the import operation is as follows: import attribute [, attribute]; The result of the import operation is that an entry about the imported object is plsced in the importer’s naming database. In many cases, a user who wishes to import an object does not know all of the attributes which are necessary to identify it. In these cases, the parameter attribute list can be a sequence of attributes that does not contain all attributes necessary to evaluate the name. The trader which performs the import operation matches these attributes to objects in its trading domain. In the case where a number of objects match the list of attributes, the trader will provide the importer with a list of optional objects. It also can happen that the attribute list does not match any object in the trading domain, resulting in the failure of the import operation.
3.2.3
Withdrawal
A previously-exported object can be withdrawn from the trader if the owner does not want it to be shared any more. The exporter can initiate the object-withdrawal operation according to the export conditions specified at the export operation stage. The withdrawal operation is defined as follows: withdraw attribute [, attribute]; domain [, domain]; Here, the attribute list is the same as that in the export primitive and the domain list is a list of the name(s) of the domain(s) from which the object should be withdrawn. As a result of the withdraw operation, the withdrawn object no longer exists in specified trading domain.
3.3 Trading databases The information necessary to map attribute names onto objects in a local distributed system is held in a naming database. The information about the objects’ export/import status the export conditions, the name of the importer, etc. necessary to allow users to share objects, is kept in the trading database. Thus, there are two groups of distinct data to be maintained by the name server and the trader respectively: • data needed to manage private objects, which are in the user and system/administrator domains, and • data needed to support trading operations.
6
RHODOS
March 15, 1993
Hence, there are two logically-separated databases, the naming database and the trading database, maintained by the RHODOS naming and trading facility. Note that the system/administrator and each user have their own logical naming sub-databases in the naming database to store their private objects in order to keep exclusive control of them (Fig. 6).
RHODOS databases trading database RHODOS trader
RHODOS name server
naming database system/ administrator
user 1
user 2
Figure 6: RHODOS naming and trading databases The RHODOS trading database contains trading information. It also records the details of various import and export operations which have been performed on an object. Each object in the RHODOS trading domain has an entry in the RHODOS trading database. The trading database entry for an object has three logical sections. The first section is related to the shared object itself. The second section relates to the export/import of the object. The third section records the details about the object import. Figure 7 shows two RHODOS trading database entries, one for a local object which belongs to one of the local RHODOS user or system/administrator domains, and another for an imported remote object which belongs to another domain (a remote system). There are distinctions in the data recorded in these two kinds of entries. The data which are relevant to a local object and should be put into the entry are (Fig. 7 a)): • When an object is exported, a reference to the object system name is placed into the first section of the entry along with its attribute name, its owner, and the access rights required for the object. • The name(s) of the domain(s) to which the object is exported and the export conditions are placed into the second section of the entry. The export conditions include the time period for which the objects are currently being made available, the cost of usage and the conditions under which the object may be withdrawn. The owner is able to change the conditions later via the trader. • When the object has been imported, the importer’s domain name and the import conditions are placed in the third section of the entry. These import conditions are a copy of the export conditions which were applicable and agreed to by the trader and the importer at the time of import. The data which are relevant to an imported remote object and should be put into the entry are (Fig. 7 b)): • When the object has been imported, a reference to the entry in the remote trading database is placed into the first section of the entry. The attribute name of the object is copied from the remote trading database into the first section. • The names of the users who imported this object are recorded in the second section. These data enable the trader to keep track of local importers. • The name of the domain from which the object is imported, and the import conditions, are placed in the third section of the entry. The import conditions may be referenced later during a withdrawal operation.
7
RHODOS
March 15, 1993
Section 1
Section 2
Section 3
attribute name
exported to
imported by
•
export conditions 1
import conditions 1
•
•
•
•
•
•
access rights
•
•
owner domain
exported to
imported by
reference to a system name
export conditions n
import conditions m
a) A trading database entry for a local object Section 1
Section 2
Section 3
attribute name
import user 1
imported from
•
•
•
•
•
•
access rights
import user n
import conditions
reference to a database entry b) A trading database entry for an imported remote object Figure 7: RHODOS trading database entries The three sections mentioned above are combined into a single entry data structure in the trading database for logical integrity of the entry, although not all sections will contain valid data at all times. For example, there is no valid information in the third section of a local object entry until the object has been imported by other users.
3.4 Attributed names and location transparency The operation of the RHODOS trader is based on attributed names. Each object managed by the RHODOS system has an attribute name which describes the properties of the object and uniquely defines the object. For example, an attribute name of a file object is a sequence of attributes as follow: {type = file, file type = source code, language = C, compiler = gcc, owner = Ni, name = trading}. A detailed discussion and definition of the attribute name supported by RHODOS traders is given in [Goscinski and Haddock 1993]. RHODOS attribute names are user-oriented object names for which there is no location-oriented information given. However, there are some hints about the location of the object. For example, a file object attribute name can be: domain = RHODOS-1, owner = ying, type = file, file_type = text, name = report;
where the attribute, domain=RHODOS-1, implies the origin domain to which the object belongs. It is not necessary for users to specify the location of the object that they wish to import. Users can issue an import operation to the local trader in the following way. import type=file, file_type=text, name=report;
By default, the domain name to which the importer belongs is known to the local trader.
8
RHODOS
March 15, 1993
To resolve and evaluate the object attribute name given in the import primitive shown above, the local trader first searches its trading database (See Fig. 8 a)) (1). If there is no matched object in the local trading domain, the local trader forwards the request with attributes to a remote trader (2). The remote trader searches its trading database (3). If the object is found in a remote domain, the local trader imports (See Fig. 8 b)) it into the local trading domain (4), then performs a local import operation for the user (5). After the completion of the import operation, the user is able to access the object in the same way as a local object is accessed (6).
importer
trader
import
(1)
request with attributes (2)
owner
trader (3) export
importer’s domain trading domain
trading domain
RHODOS 1
owner’s domain
RHODOS 2 a) Looking for a remote object.
importer
trader
owner
trader
(6) import (5)
import
importer’s domain trading domain
(4) trading domain
RHODOS 1
owner’s domain
RHODOS 2
b) The importer’s view of the remote object Figure 8: Importing a remote object.
4
The trading service implementation
The currently-implemented trading-facility prototype runs in a simulated homogeneous environment consisting of two RHODOS distributed systems. In this section, the detailed implementation of the RHODOS traders is presented.
4.1 Traders and their components The trading service functionality is provided by the mutual cooperation of the traders. The individual trader functionality is provided in the interactions of its underlying functional components. The traders have been developed on the basis of the client-server model and the modular structure of their architecture enables their functional components to be distributed if necessary. There are a number of major components within the RHODOS trader, as shown in Figure 9. This figure shows that all major parts can run on separate workstations, as no assumptions are made and no restrictions are placed on the distribution of the RHODOS trader functional components.
9
RHODOS
March 15, 1993
The diagram shows that RHODOS users access the RHODOS trader via a number of user agents which provide RHODOS users with an interface to perform naming and trading operations. The functions performed by the major components are: • user agent there are a number of user agent processes running on each workstation in the RHODOS distributed system, which directly communicate with the user process. The user agent receives requests from a local user and passes them to the request manager, obtains replies from the request manager and returns the result to the user;
user process
user process
user process
user agent
user agent
user agent
request manager
naming manager
communication manager
trading manager
database manager
user 1 naming database
•••
user n naming database
trading database
admin naming database
Naming database Figure 9: The RHODOS trader components • communication manager receives messages/requests from remote traders, passes them to the request manager, obtains a reply from the request manager and returns the result to the sender. • request manager handles requests passed by user agents and the communication manager and processes them by: • interpreting a request and selecting an appropriate manager to process the request: if it is a naming operation, the request manager invokes the naming manager; if it is a trading operation, the request manager invokes the trading manager; • returning the result to the user agent or the communication manager; • naming manager handles all naming-related operations (see [Haddock 1991]), such as: • operations on contexts, attributes or objects, and • name evaluation operations; • trading manager handles all trading-related operations, including: • exporting or importing an object,
10
RHODOS
March 15, 1993
• withdrawing an exported object, and • enquiring about exported objects; • database manager handles all manipulations of the naming databases and trading database, including: • creation, deletion or modification of database entries, and • searching of databases.
4.2 The cooperation between traders As we described earlier, our trading service is implemented as a set of distributed traders, with each trader running on a local distributed system. Each trader keeps information about objects in its local trading domain. This means that no global information about exported objects is stored by any trader. There is a requirement for cooperation between traders when a trading operation is being performed. The general form of cooperation is as follow: • the export operation is carried out locally by the local trader; the information about exported objects is stored in the local trading database; • the import operation is carried out locally first by the local trader searching its local database to find if it already has that object; if the object is not found, it forwards the request to another trader, starting a remote import procedure. As there is an entry for an imported remote object in the local trading database, the local trader can find it by searching the database. In this case, the import operation is carried out locally. An example of cooperation between the RHODOS traders is shown in Figure 10. In the case of export: 1.
A RHODOS-1 user issues an export operation request (1) to a RHODOS-1 trader user agent.
2.
The user agent passes the request to the RHODOS-1 trader (2).
3.
After receiving the request, the RHODOS-1 trader creates an entry in the trading database and registers the parameters received in the export operation into the entry (3).
In the case of import, the following steps are taken: 1.
A RHODOS-1 user issues an import operation and the request is passed to the RHODOS1 trader (1), (2).
2.
The RHODOS-1 trader searches the RHODOS-1 trading database, according to the parameters given in the import operation primitive (4).
3.
If that object is found, the RHODOS-1 trader returns the name of the object and the import conditions to the calling user, via the user agent (5), (6), (7).
4.
If not found, the RHODOS-1 trader passes the import request to the RHODOS-2 trader (8).
5.
The RHODOS-2 trader searches the RHODOS-2 trading database with the parameters passed by the RHODOS-2 trader (9).
6.
If the object is found, the RHODOS-2 trader returns the name of the object and the import conditions associated with it to the RHODOS-1 trader (10). The RHODOS-1 trader then creates an entry in the RHODOS-1 trading database with the information received. Otherwise, the RHODOS-2 trader returns an error message (10).
7.
The RHODOS-1 trader informs the calling user about the import result (11), (12).
11
RHODOS
March 15, 1993
RHODOS-1
RHODOS-2
User
User (7) Yes (12) Yes/No
(1) user agent
user agent (6) Yes (11) Yes/No (8)
(2)
RHODOS-1 Trader
RHODOS-2 Trader (10) Yes/No
(4)
(5) Yes/No
(3)
(9)
RHODOS-1 Trading database
(10) Yes/No
RHODOS-2 Trading database
Figure 10: Cooperation between RHODOS traders At this stage, we are dealing with the cooperation between two traders. We believe the same conceptual design can be used in the case there are multiple traders within one large distributed system [Ni and Goscinski, 1993]. In the further research, a general approach to trader resolution presented in [Goscinski 1991] will be used.
4.3 Algorithms The three most important algorithms which relate to the trading service are search, export and import. This section provides a brief description of the main points applicable to each of these algorithms.
4.3.1
Searching algorithm
The search function is a fundamental function which finds an object in a trading database using given attributes. It is therefore used by several other functions in export and import operations. For example, when exporting an object, the naming database needs to be searched first to ensure that the object to be exported exists: when importing an object, the trading database needs to be searched to find the required object(s). The search algorithm used in the RHODOS trader uses the search function implemented in the initial RHODOS trading facility prototype. The search algorithm performs an exhaustive search based on the hierarchical structure of the RHODOS naming contexts. The detail of the search function is presented in [Haddock and Goscinski, 1991].
4.3.2
Export algorithm
The export operation implementation is designed to prove the correctness of the conceptual design of the
12
RHODOS
March 15, 1993
export operation, and is not intended to be an elegant solution to be used in a final version of the traders. Figure 11 outlines the algorithm which is executed by the RHODOS trader. A detailed description of the algorithm is given in [Goscinski and Haddock, 1993]. It is assumed that an exporter specifies the evaluable attribute name of the object to be exported in the export primitive, in order to enable the trader to uniquely identify the object. The evaluable attribute name is placed into the new entry of the trading database.
get the attribute name from the server agent; pass the name to Naming Manager to locate the object in the Naming Database; if (object is exported) { query if user wants to change the export conditions; if (response == yes) { get the changes; consistency check on proposed changes; if (consistent with existing conditions) { locate the object in Trading Database; change the conditions; } else { error message to user; exit; } } } else { ask for the target export domain; add an object entry into Trading Database; ask for export conditions; create import/export sections for the object entry; }
Figure 11: Export Algorithm in the RHODOS Trader
4.3.3
Import algorithms
The algorithms for the import operation are also designed to prove the correctness of the conceptual design of the import concept and the cooperating between traders. There are two separate functions required when performing an import operation, one is executed by the local trader, as outlined in Figure 12, and another executed by the remote trader, as summarized in Figure 13. The implementation of the RHODOS trader prototype follows these algorithms closely. The implemented import primitive allows the user to use any attribute names and, via the enquiry mechanism, one or more objects can be identified depending the precision of the name given. In this way, the user is relieved of the requirement to provide the evaluable attribute names. This approach takes advantage of attribute-based naming to provide maximum flexibility to users. The significant item missing from the prototype implementation is a section to deal with the situation in
13
RHODOS
March 15, 1993
which a user provides an imprecise specification and the trader finds a set of objects which partly match the user’s specifications. It is a likely case that there might be hundreds of objects which partly satisfy the original request. Thus, it is desired that the trader be able to reduce the number of objects that will be offered to the user. The main point of interest here is how to select objects from the set and what policies should be employed by the trader. A simple approach that seems appropriate is that the trader be able to negotiate with the user in some form during the import operation, in order to make an agreement with the user on his/her requests. It is required that an interactive user/trader interface be provided by the trading service. This is an important research aspect of attribute naming and trading. We are dealing with this issue in another project.
get the attribute name from the server agent; pass the name to the Database Manager to locate the object in the Trading Database; if (object is already imported) inform the user; else if (object is found in Trading Database) /* There is a local object available */ { show the export conditions to importer; query if importer agrees to the conditions; if (response == yes) { add an object entry into user’s Naming Database; update the import/export sections of the object entry in Trading Database; } } else if (object is not found in Trading Database) { send the attribute name to other traders; wait for reply; if (reply == yes) { get the attribute name of the remote object; get the export conditions from remote trader; add the object entry into Trading Database; show the export conditions to importer; query if importer agree the conditions; if (response == yes) { create the import/export sections for the object entry; add an object entry into user’s Naming Database; } } else error message to user; }
Figure 12: Import algorithm in the RHODOS trader.
14
RHODOS
March 15, 1993
read the message from an other trader; locate the object in the Trading Database; if (the object is found in the Trading Database) { send the attribute name of the object; send the export conditions of the object; } else if (the object is not found in the Trading Database) send an error message;
Figure 13: Import algorithm executed by the remote trader
4.4 Interactive user/trader interface The interface provided in the trading facility prototype inherits the initial user/RHODOS name server interface, which is a very simple multi-level menu system. It allows a user to select one of the following options: export an object, import an object, withdraw an object, enquire about an exported object, display the trading databases or exit the program (see [Haddock 1991]).
4.5 Experiments with the prototype trading service To demonstrate the functionality of the trading operations and the trader cooperation discussed in this paper, the following examples have been extracted from a set of runs. There are two RHODOS systems (RHODOS-1 and RHODOS-2) running simultaneously and two traders (Trader-1 and Trader-2) cooperating with each other to perform the trading operations on remote objects. Figure 14* shows that by selecting the ‘Export Object’ menu option from Trader-1’s Export/Import submenu, an export operation initiated in the RHODOS-1 domain exports an object to the RHODOS-2 domain. In the example, the user is prompted to provide the object attribute name, the details of the export conditions and the domain to export to. When all of these conditions have been entered, the export operation is complete. Figure 15* shows the view of the RHODOS-1 trading database in which the object which has been exported in Figure 14 is visible. All these objects shown in the RHODOS-1 trading database can be imported by RHODOS-2 users. Figure 16* shows an exported object of the RHODOS-1 domain being imported by a RHODOS-2 user. The user specified the attributes of an object which he/she wants to import without the location information. The Trader-2 found there was no such object in its local trading database, then asked Trader-1 and imported it from the RHODOS-1 domain. Figure 17* then shows the result of this import operation by viewing the RHODOS-2 naming database. These examples show how location transparency can be achieved by cooperation between Trader-1 and Trader-2.
* The input data given by the usr and the output data given by the prototype are separated by the space between lines.
15
RHODOS
March 15, 1993
RHODOS1 Naming Facility Prototype: Version 2 Import/Export/Withdrawal Menu 1. 2. 3. 4.
Export Object Import Object Withdraw Object return to Main Menu.
Enter Option: 1 Please enter the name of the object to be exported: UNAME = YING; FOUND OBJECT : YING THE FOLLOWING FULL ATTRIBUTE NAME(S) WAS/WERE FOUND name = RHODOS1 type = f ile f ile_type = text UNAME = YING Export Visibility = FALSE Please enter export conditions: Your userid :ying Start date for export : 21/1/93 End date for export : 31/12/93 Usage cost : 50cent Conditions of Withdrawal : weeknotice Domain object is to be exported to : RHODOS2 Hit any key to continue...
Figure 14: Exporting an object to RHODOS2 Domain
RHODOS1 Naming Facility Prototype: Version 2 Main Menu 1. 2. 3. 4. 5. 6.
Add an object or context Make an Enquiry Display the Naming Database Display the Export Database Import/Export or Withdraw an Object Exit Program.
Enter Option: 4 Object 1 : laser_1 printer laser1 printer 1235 printer hana4 12Mar92 13Dec92 50cph whenever 34 UNIX parent is type = f ile context is f ile_type = text brother is f ile_type = p_f ile Object 1 : YING file 0 file ying 21/1/93 31/12/93 50cent weeknotice RHODOS2 parent is type = f ile context is Object 1 : MICK file RAJ file 12345 f ile hadan4 1Jul91 31Dec91 Object 2 : WARREN file 12345 f ile hadan4 1Jul91 31Dec91 Object 3 : ANDY file JAGA file 12345 f ile hadan4 1Jul91 31Dec91
f ile_type = p_f ile 50centsperhour almostany 99 UNIX 50centsperhour almostany 99 RD1 50centsperhour almostany 99 RD2
Figure 15: Viewing RHODOS1 trading database
16
RHODOS
March 15, 1993
RHODOS2 Naming Facility Prototype: Version 2 Import/Export/Withdrawal Menu 1. 2. 3. 4.
Export Object Import Object Withdraw Object Return to Main Menu.
Enter Option: 2 Please enter the name of the object to be imported: type = f ile, f ile_type = text, UNAME = YING; FOUND CONTEXT : type = f ile ERROR : That context/object cannot be found FOUND CONTEXT : type = f ile FOUND CONTEXT : f ile_type = text FOUND OBJECT : YING THE FOLLOWING FULL ATTRIBUTE NAME(S) WAS/WERE FOUND name = RHODOS1 type = f ile f ile_type = text UNAME = YING Export Visibility = TRUE 0 file ying 21/1/93 31/12/93 50cent weeknotice RHODOS2 The export conditions are: 21/1/93 31/12/93 50cent weeknotice Hit any key to continue...
Figure 16: Importing an object from RHODOS1 Domain
RHODOS2 Naming Facility Prototype: Version 2 Enquiry Menu 1. 2. 3. 4. 5.
Find Context in Naming Database Find Object in Naming Database Find Context in Export Database Find Object in Export Database Return to Main Menu.
Enter Option: 2 Enter Object to f ind:UNAME = YING; FOUND OBJECT : YING THE FOLLOWING FULL ATTRIBUTE NAME(S) WAS/WERE FOUND name = RHODOS1 type = f ile f ile_type = text UNAME = YING Export Visibility = TRUE 9999 f ile RHODOS2 21/1/93 31/12/93 50cent weeknotice (null) Hit any key to continue...
Figure 17: View an imported object from RHODOS2 Domain
17
RHODOS
5
March 15, 1993
Conclusion
In this paper, we have described a distributed trading service which is an extension to the original trading service for the RHODOS distributed operating system. We have demonstrated that it is possible to build a trading service which provides object sharing in a homogeneous large distributed system by the means of the cooperation of traders in each local system. We have proved that object sharing between homogeneous operating systems can be achieved by introducing the concept of exporting and importing objects to/from different system naming domains. We have shown that exported objects are visible to users outside the local name domain via the local trader, so that a user can share objects which are not available in the user’s local system domain by importing them into his/her local system domain. We have also shown that the object location problem rising from the lack of full information about all objects in a large distributed system can be solved by cooperation between the traders. Another major result is a demonstration that the attribute name scheme is a suitable name scheme for a trading service. It has been shown that a trading service based on attribute names provides users with location transparency to view and access remote objects. We have also shown that the use of attributes has the potential to make resource sharing very effective and efficient.
6
Acknowledgement
The authors would like to thank Dr. George Gerrity for reading the draft of this paper and his helpful comments.
18
RHODOS
March 15, 1993
References [Bach 1986] Maurice Bach, The Design of the UNIX Operating System. Prentice-Hall. [Gerrity et al. 1991] G. Gerrity, A. Goscinski, J. Indulska, W. Toomey, and W. Zhu. Can We Study Design Issues of Distributed Operating Systems in a Generalized Way? - RHODOS. Proceedings of the 2nd Symposium on Experiences with Distributed and Multiprocessor Systems (SEDMS II), March. [Goscinski 1991] A. Goscinski, Distributed Operating Systems: The Logical Design. Addition-Wesley. [Goscinski 1993] A. Goscinski. Supporting User Autonomy and Object Sharing in Distributed Systems: The RHODOS Trading Service. Proceedings of the International Symposium on Autonomous Decentralized Systems ISADS’93. [Goscinski and Bearman 1990] A. Goscinski and M. Bearman. Resource Management in Large Distributed Systems. Operating System Review, October. [Goscinski and Haddock 1993] A. Goscinski and A. Haddock, The Development of a Prototype Attributed Naming and Trading Facility Supporting User Autonomy and Object Sharing, Submitted to Software Practice and Experience. [Goscinski and Indulska 1992] A. Goscinski and J. Indulska, The RHODOS Naming Facility, IEEE Distributed Processing Technical Committee Newsletter, Vol. 14, No. 1. [Haddock and Goscinski, 1991] A. Haddock and A. Goscinski, The Development and Experiences With the RHODOS Naming Facility, Technical Report CS37/91, Department of Computer Science, University College, ADFA, UNSW, September. [Haddock, 1991] A. N. Haddock, Selected Aspects of the Development of the RHODOS Naming Facility. MInfSc Thesis, Department of Computer Science, University College, ADFA, UNSW, November. [Ni and Goscinski 1993] Y. Ni and A. Goscinski, Trading of Objects in a Heterogeneous Large Distributed System, Technical Report in processing, School of Computing and Mathematics, Deakin University. [van der Linden 1990] R. van der Linden, ISA Project. Federated Naming Model. Advanced Network System Architecture. Architecture Projects Management Limited. [van der Linden and Sventek 1992] R. van der Linden and J. Sventek, The ANSA Trading Service. IEEE Distributed Processing Technical Committee Newsletter, Vol. 14, No.1.
19
