Object Trading in Open Systems* A. Goscinski and Y. Ni (
[email protected] [email protected] ) School of Computing and Mathematics, Deakin University, Geelong, Abstract In this paper we demonstrate that a new class of name and object a trading service allows users of an open system to share objects which are not their local systems. We propose a distributed implementation of a service is based on both attribute names and mutual cooperation of trading servers (traders). We demonstrate that object sharing geneous local systems can be achieved by introducing the concepts objects to/from different local systems, and that a trading easily deal with name heterogeneity problems resulting from the by underlying local operating systems. We show that the proposed name and location transparency to users, and that the use of object sharing effective in an open operating system. Keyword Codes: C.2.4; D.4 Keywords: Distributed Systems; Operating Systems 1. INTRODUCTION The future of computing lies in distributed and open systems. systems have been developed and studied extensively because they objects: computational and peripheral resources, services and referred to in this paper as local distributed systems, consist of tions and peripheral resources (e.g., disks, printers, plotters) These computers are similar in their hardware and software and are tributed operating system. As in any real environment, users of the types of objects which they can access. However, users of such devices to improve their performance and to achieve better are only available in some local distributed systems. By distributed systems to form a homogeneous large distributed tem should be able to share those objects which are not available The need to use a variety of objects, and the increase of and software have made heterogeneity a fact of life. If individual erogeneous environment, they can access significantly more objects local networks (e.g., the special databases, file systems, other specialized hardware). Thus, by connecting local distributed puters, a heterogeneous large distributed computer system (open open system is managed by an open operating system ([3], [4]). Despite the above advantages and potential, distributed systems problems. First, a user of a distributed system loses the autonomy alone personal computer environments, and the need for providing challenge. Furthermore, heterogeneity stops the direct accessing to allow other users to access and use their objects, these ing to specified and agreed conditions. Thus, the main * T h is w o r k w a s p a rt l y s u p p o r t e d b y A u s t ra li a n R e s e a r ch C o u n c il D e a k in U n iv e r s it y R e s e a r c h G r a n t s 0 5 0 4 0 5 4 1 5 1 and 0504010151.
concern contradictory management problems. As suggested in [4] and [9], these problems can be solved by providing a new class of name servers and object The work that has been carried out in the RHODOS project has create a trader based on a naming facility within a local [7]. A prototype of such a trader, which provides the maximum bility to users, yet at the same time allows them to share for a distributed system supported by an attribute naming facility the concepts of user and system domains, the concept of a context, export, withdrawal, and import. These original concepts and export an object in order to make it visible to other users, and this object in order to access it according to an agreement user who wants to use it. It is the task of a trader to provide The goal of our current research is to develop a prototype of a environment, and to gain experience with this new class of object facilities. We propose that a trading service should be built in a means that each local system should have its trader and that those with each other. The aim of the paper is to present the development of a prototype open system. This prototype has been built in a heterogeneous group of RHODOS distributed systems [2], which are homogeneous, supported by an attribute naming facility, and a Unix system supported by a partitioned 2. TRADING IN AN OPEN SYSTEM An open system consists of a number of local computer systems, geneous and some of which are heterogeneous. The term homogeneous paper is in the sense that each local system is under the control ating system. This implies: firstly, all local systems follow the ondly, the user/system interfaces provided by each local operating all local systems have similar system/ system communication tocols. The term heterogeneous means the individual local systems (possibly) dissimilar operating systems, which themselves may be The heterogeneity which is inherent in the open system results in of new methods and algorithms for object sharing. Trading is a new and management, and it can be applied in an open operating system. The trading model is based on the concepts of object export and export is performed by object owners who wish their private use by other users. An object owner exports an object and provides Another user who wishes to use the object imports the object Importing users should be able to select the objects that best defined as an activity of exporting and importing. This activity ing objects such that they match some specific requirements. The parison of a user requirement specification and object object exporter. The sharing is subject to the export conditions agreed to by an importer. A trader is a software entity which object exporters and importers. This implies that an object must name scheme and that the object descriptions must be known to the Accessing an object requires a knowledge of its name; however, are heterogeneous. The name heterogeneity results from two facts. suggested in literatures falls into two categories: partitioned Partitioned name schemes have been used in most existing operating attributed name, e.g., an X.500 name [1] or a RHODOS name [7], is a set of attributes that uniquely identify an object in a system in which it is operating systems use partitioned names, the name conventions are ying/file.dat.a and [home.ying]file.dat.A trader has to be able to deal with the name problems and to provide name and location transparency to
distributed system 2
distributed system 1 TS 2
TS 1
TS 4
communication system TS 3
super computer
distributed system 3
Figure 1: A trading service in a large distributed system. (TS —Trading Server) Furthermore, a name of an object may carry information about involved in using the object — the computational view of the object. An attribute name, due to its much richer form of identification than a partitioned name, is information of the object it names. A trading service in an open operating system can be implemented ating traders, with one in each local system (Fig. 1). This approach leads to a distributed trading service which allows each local system to be independent, and each local system. This implies that each trader is responsible this distributed approach to a trading service, a user need only exporting or importing an object. By cooperating with remote locate an object which is not available in the local system, user to access the object. 3. THE ARCHITECTURE OF THE TRADING SERVICE The architecture of a prototype trading service for an open uted systems controlled by the RHODOS distributed operating system system controlled by the Unix operating system is depicted in Figure 2. The trading service is based on an attributed naming scheme which can precisely describe is built as a set of local cooperating traders.
user 1
user n
•••
user 1
server agent name server
server agent name server
trader
trader
naming and trading database RHODOS trader 2
naming and trading database RHODOS trader 1 user 1 • • • user l
user m
•••
trader agent
UNIX trader
export/import database
Figure 2: The architecture of the trading service. Each RHODOS trader is such a component of the RHODOS system [6] which: • preserves user autonomy as in a centralized environment; • supports sharing both by allowing objects either to be exported to withdrawn from service, and by allowing objects which have been other domains to be imported; • is based on attribute names, in order to allow users to access the their precise name. This trader has been extended in order to support sharing in both ogeneous large distributed systems. As a result of this extension, with traders which support similar local systems, e.g., RHODOS, e.g., a Unix, and can deal with the name heterogeneity arising supported by these local systems. The Unix trader, in contrast with the RHODOS trader, runs on top system as an application program. In a Unix system, objects are names. However, a path-name poorly describes the properties of an out the trader process based on path-names. To cooperate with the precisely describe shared objects, the Unix trader supports name objects exported/imported to/from the Unix system. Both names are supported by the Unix trader. The Unix trader translates attribute name to a Unix path-name, so that Unix users are able to For an exported Unix object, the Unix trader assigns an attribute description given by the exporter, while retaining its path-name attribute name. 3.1. Trading domains A trader is responsible for managing sharable objects; those which other domains by their owners in the local system, and those which remote system by local users. Traders distinguish these sharable objects by means of domains; in particular, trading domains. All objects of the RHODOS operating system belong to the RHODOS 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 behalf of the operating system, and which can be imported by other
Consequently, these objects belong to three subdomains of the domains, a system subdomain and a trading subdomain, respectively. domain implies that each RHODOS object can be: • invisible to all users except the owner, if it is only in a user • visible to users in other user domains specified by the owner domain but not accessible by them, or • visible and accessible by those users who import it. Note that though an exported object is ‘seen’ and operation by other users, the exporter is still responsible for that only the exporter can carry out operations on the object in access rights, etc. In the Unix system, all objects belong to the Unix system domain. system domain has a path-name based on the existing Unix approach, we propose the establishment of two subdomains of the users and administrator subdomain, which is equivalent to the trading subdomain, to be used to support both export and import of those objects which are not allowed to be accessed by users of the user and administrator domain. Those objects which have been domains and which have been imported by Unix users from other ing domain. Therefore, each Unix object can be: visible and Unix system if the object is in the trading domain, or invisible trading domain. The RHODOS naming domain consists of a number of disjoint subsets objects. This separation provides autonomy to users and the domain is a union of private and system objects exported by their administrator, respectively. The creation of the trading domain ent autonomous users possible. The Unix domain reflects the centralized control of the Unix separate user subdomains. The Unix trading domain is a subset of those Unix objects which have been made available to users outside management of these objects is beyond the capability of the Unix of these objects from ordinary local Unix objects enables local to remote systems and to share via the Unix trader objects which system. 3.2. Trading service operations 3.2.1. Export The owner of an object registers the object with the local trader The export primitive is defined as follows: export attribute [, attribute]; domain [, domain]; export conditions; The exporter invokes an export primitive operation with three • attribute list a sequence of the object attributes specified by the exporter. should be an evaluable RHODOS attribute name, if the object is a sequence of object attributes, specified by the Unix exporter; • domain list a list of the name(s) of the domain(s) to which the object is to • export conditions a list of conditions specified by the owner (the time period which the object will be available, the cost of using the object which the object may be withdrawn). After execution of the export primitive, an entry about the local trading database. 3.2.2. Import An exported object must be imported before a user in another import an object, a user issues an import operation with the The definition of the import operation is as follows:
import attribute [, attribute]; The result of the import operation is: • in the RHODOS system, an entry about the imported object is placed naming database, or • in the Unix system, an entry about the imported object is placed database and a Unix pathname of the imported object, which is a imported object in the Unix trading database, is placed in the directory. In many cases, a user who wishes to import an object does not know which are necessary to identify it. In these cases, the attribute attributes which does not contain all the attributes necessary to which performs the import operation matches these attributes to In the case where a number of objects match the list of importer with a list of optional objects. It can also happen that any object in the trading domain, resulting in the failure of the 3.2.3. Withdrawal A previously-exported object can be withdrawn from the trader if it to be shared any more. The exporter can initiate the to the export conditions specified at the export operation stage. defined as follows: withdraw attribute [, attribute]; domain [, domain]; Here, the attribute list is the same as that in the export of the name(s) of the domain(s) from which the object should be withdraw operation, the withdrawn object no longer exists in the 3.3. Trading databases To manage a shared object requires information about the the export conditions, the name of the importer, etc. This maintained by traders. 3.3.1. The RHODOS trading database The information necessary to map attribute names onto RHODOS system is held in a naming database. The information about RHODOS status is kept in a trading database. The data which are relevant to a local object and should be put • A reference to the object system name is placed into the first its attribute name, its owner, and the access rights required for when an object is exported. • The name(s) of the domain(s) to which the object is exported and placed into the second section of the entry. The owner is able to via the trader. • If the object has been imported by another user, the importer’conditions are placed in the third section of the entry. These the export conditions which were applicable and agreed to by the the time of import. The data which are relevant to an imported remote object and are: • A reference to the entry in the remote trading database is placed entry. The attribute name of the object is copied from the remote first section. • The names of the users who imported this object are recorded in data enable the trader to keep track of local importers. • The name of the domain from which the object is imported, and the placed in the third section of the entry. The import conditions a withdrawal operation. 3.3.2. The Unix trading database Each object in the Unix trading domain can be viewed and accessed name and a Unix pathname. The Unix trading database contains the map an attribute name onto the Unix path-name
or vice versa, and sharing, such as export/import conditions. The database has two and import database. The export database stores data which are Unix users. The import database stores data which are relevant to remote operating system domains. When a Unix object is exported, an entry is created in the export base. The exporter is required to specify the attributes of the tions. These specifications are placed into the entry in the form the export conditions. The object full path-name is recorded into attribute name. In the import part of the trading database, each entry corresponds entry records the attribute name of the object, the import of the object in its original trading database and the path-name Unix trader. With this path-name, Unix users can access the object access ordinary Unix objects. 4. THE TRADING SERVICE IMPLEMENTATION The currently-implemented trading-service prototype runs in a environment consisting of two RHODOS distributed systems and a 4.1. Traders and their components The trading service functionality is provided by the mutual individual trader functionality is provided in the interactions of ponents. There are a number of major components within the RHODOS trader, user process
user process
user process
user agent
user agent
user agent
request manager naming manager
trading manager
communication and name conversion manager
database manager
user 1’s user n’s trading admin naming • • • naming database naming database database database Naming database a) The RHODOS trader
user process
user process
user process
trader agent communication and name conversion manager
trading manager database manager
searching manager
export part of database
import part of database
Trading database b) The Unix trader
Figure 3: The RHODOS and Unix traders • user agent receives requests from local users and passes them to the request obtains replies from the request manager and returns the result to • communication and name conversion manager receives messages/requests from remote traders, translates them into RHODOS name format, passes them to obtains a reply from the request manager and returns the result to • request manager handles requests passed by user agents, and the communication and
name conversion manager; • trading manager handles all trading-related operations, including: exporting or an object; withdrawing an exported object; enquiring about • database manager handles all manipulations of the naming database and trading database, including: creation, deletion or modification of databases. The Unix trader runs on top of the Unix operating system as an functions performed by the major components of the Unix trader • trader agent receives trading requests from Unix users and passes them to the manager, obtains the reply from the trading manager and returns • communication and name conversion manager receives massages/requests from remote traders, translates them into Unix trader attribute name format, manager, obtains a reply from the trading manager and returns the • trading manager is responsible for all trading operations, i.e., export, import withdrawal; • database manager is responsible for all operations on the export database and database, including: creating an entry, deleting an entry and • searching manager is responsible for searching for objects in the export database import database. 4.2. Cooperation among traders As we described earlier, our trading service is implemented as a with each trader running on a local distributed and/or centralized information about objects in its local trading domain. This means about exported objects is stored by any trader. There is a traders when a trading operation is being performed. There are rectness of the distributed implementation of trading service, resolution, the guarantee of the quality of aspects, etc., which will be the subjects of our future study. The general form of cooperation is as follow: • the export operation is carried out locally by the local trader; objects is stored in the local trading database; • the import operation is carried out first locally by the local database to find if it already has that object; if the object is to another trader, starting a remote import procedure; • the trader resolution, the purpose of which is to locate the of interest to the importer, is currently implemented as a passes the request to a remote trader, then waits for the result trader. An example of cooperation between the RHODOS trader and the Unix Figure 4. In the case of export: 1. A RHODOS user issues an export operation request (1) to a RHODOS 2. The user agent passes the request to the RHODOS trader (2). 3. After receiving the request, the RHODOS trader creates an entry in registers the parameters received in the export operation into the In the case of import, the following steps are taken (Fig. 4): 1. A RHODOS user issues an import operation and the request is passed trader (1), (2). 2. The RHODOS trader searches the RHODOS trading database according given in the import operation (4). 3. If that object is found, the RHODOS trader returns the name of the conditions to the calling user, via the user agent (5), (6), (7). 4. If not found, the RHODOS trader passes the import request to the for the reply.
RHODOS
User (1)
user agent (2)
(7) Yes (12) Yes/No (6) Yes (11) Yes/No (8)
RHODOS Trader (3)
(4)
(5) Yes/No
RHODOS Trading database
5. 6. 7.
8.
Unix Unix Trader
(10) Yes/No
(9)
(10) Yes/No
Unix Trading database
Figure 4: Cooperation between RHODOS and Unix traders The Unix trader searches the Unix trading database with the RHODOS trader (9). If the object is found, the Unix trader returns the name of the conditions associated with it to the RHODOS trader. Otherwise, the error message (10). If the reply from the Unix trader is positive, the RHODOS trader RHODOS trading database with the information received. If the RHODOS trader passes the import request to another trader (repeats receives a positive reply or all known remote traders have been The RHODOS trader informs the calling user about the import result
4.3. Algorithms The three most important algorithms which relate to the trading and import. The search function is a fundamental function which finds an using given attributes. It is therefore used by several other ations. Due to the differences in the architectures of the RHODOS bases, different searching algorithms are applied to the RHODOS The search algorithm performs an exhaustive search based on the the RHODOS naming contexts [7]. The search algorithm used in the Unix trader is based on the all entries in the Unix trading database are organized in the form object which is the first matching object in the database if the The export algorithms used in both the RHODOS trader and the Unix except that the Unix export routine does not have a function for of an exported object. The detailed description of the export It is assumed that an RHODOS exporter specifies the evaluable to be exported in the export primitive. The evaluable attribute entry of the RHODOS trading database. In the case of the export by the Unix trader, it is required that Unix exporters specify the be exported in the form of an attribute name as well as the full uses this full path-name to locate the exporting object in the There are two separate functions required when performing an cuted by the local trader, and another is executed by the remote The implemented import primitive allows RHODOS users to use any via the enquiry mechanism, one or more objects can be identified of the name given. In this way, a user is relieved
from the attribute names. The implementation of the Unix trader prototype demonstrates a DOS import algorithm. The point is that the Unix trader checks the ensure that the same object will not be imported again. It is has access to the directory. Hence, as long as an object has been allow all Unix users to access it. Moreover, the Searching Manager algorithm allows an object to be located in the import database by path-name. This approach provides users with maximum flexibility operation. The significant item missing from the prototype implementation is situation in which a user provides an imprecise specification and objects which partly match the user’s specifications. It is hundreds of objects which partly satisfy the original request. able to reduce the range of objects that will be offered to the issue in another project. 4.4. Attribute names of shared objects The prototype initially was implemented to deal with two files and printers. Two examples of these objects’ attribute These two objects are shared objects, which means that they are in and the Unix domain. Each of them has a RHODOS attribute name and 5. CONCLUSION In this paper, we have described a new class of name service and trading service and demonstrated the feasibility of the basic trading concepts ical design. We have shown that it is possible to build a trading sharing in an open environment. We have proved that object sharing heterogeneous operating systems can be achieved by introducing the import objects to/from different naming domains. We showed that objects in the trading domain, are visible to users outside the trader. A user can access objects which are not available in the importing them into the local system domain. Another major result is a demonstration that the attribute name scheme for a trading service. It has been shown that with resulting from different name schemes used by underlying local ily resolved. A trading service based on attribute names provides transparency to view and access remote objects. We have also shown has the potential to make object sharing very effective in an open Names in RHODOS trading database
Names in UNIX trading database
domain = RHODOS, owner = ying, type = file, file_type = text, name = report;
type = file, file_type = text, path_name = /trading/import/ report;
a) A text file imported by the Unix trader from the RHODOS Domain
domain = UNIX, type = compiler, comp_type = C, name = /usr/bin/cc;
type = compiler, comp_type = C, path_name = /usr/bin/cc;
b) A compiler package imported by the RHODOS trader from the Unix
Figure 5: Shared object attribute names in trading databases
6. ACKNOWLEGEMENT The authors would like to thank Dr. George Gerrity for reading the his helpful comments. REFERENCES [1] CCITT. 1988. CCITT - X.500. [2] G. Gerrity, A. Goscinski, J. Indulska, W. Toomey, and W. Zhu. Issues of Distributed Operating Systems in a Generalized Way? - the 2nd Symposium on Experiences with Distributed and II), Atlanta, March. 268-274. [3] A. Goscinski. 1990. Design Issues of Operating Systems for Open Distributed Processing. Proceedings of the ACUS and BASSER Workshop on Open Distributed January. 1-14. [4] A. Goscinski and M. Bearman. 1990. Resource Management in Large Distributed Systems. Operating System Review, October. 7-25. [5] A. Goscinski. 1991. Distributed Operating Systems: The Logical Design. Addition-Wesley. [6] A. Goscinski. 1993. Supporting User Autonomy and Object Sharing in Distributed Systems: The RHODOS Trading Service. Proceedings of the International Symposium on Autonomous Decentralized Systems ISADS’93. March 30 - April 1, Kawasaki, Japan, 100-106. [7] A. Goscinski and A. Haddock. 1993. The Development of a Prototype Attributed Naming Facility Supporting User Autonomy and Object Sharing, Submitted to Computer Journal, May. [8] L. Peterson. 1989. An Overview of UNP, Operating System Review, Vol. 21, No. 5, 21-62. [9] R. van der Linden and J. Sventek. 1992. The ANSA Trading Service. IEEE Distributed Processing Technical Committee Newsletter, Vol. 14, No.1, 28-34.
