Resource and Service Trading in a Heterogeneous Large Distributed

Transcription

1 Resource and Service Trading in a Heterogeneous Large Distributed ying@deakin.edu.au Y. Ni School of Computing and Mathematics Deakin University Geelong, Victoria 3217, Australia ang@deakin.edu.au Abstract This paper describes a new class of name and resource management facility a trading service which allows users of a heterogeneous large distributed system to share resources and services (resources) which are not available in their local systems. A distributed implementation of a trading service which provides name and location transparency to users is presented. This trading service is based on both attribute names and mutual cooperation of a number of independent trading servers (traders). We demonstrate that resource sharing among heterogeneous local systems can be achieved by introducing the concepts of export and import of resources to/from different local systems, and that a trading service based on attribute names can easily deal with name heterogeneity problems resulting from the different name schemes used by underlying local operating systems. 1 Genesis and goal Homogeneous distributed systems have been developed and studied extensively because they allow users to share 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 are similar in their hardware and software and are under the control of a distributed operating system. As in any real environment, users of these systems have limits on the types of resources which they can access. The need to use a variety of resources, and the increase of diversity of computing hardware and software have *This work was partly supported by Australian Research Council under Grants A , A and the Deakin University Research Grants and made heterogeneity a fact of life. If individual users are connected to a heterogeneous environment, they can access significantly more resources than are available on their local networks (e.g., the special databases, file systems, directory services, supercomputers and other specialized hardware). Thus, by connecting local distributed systems and special computers, a heterogeneous large distributed computer system can be formed. This large distributed system is managed by an open operating system [2] [3]. Despite the above advantages and potentials, distributed systems generate some serious problems. First, a user of a distributed system loses the autonomy experienced within stand-alone personal computer environments, and the need for providing security becomes a real challenge. Furthermore, heterogeneity stops the direct accessing of a resource. Thus, the main concern here is how to resolve all these contradictory management problems. Because the methods and algorithms used in traditional operating systems cannot be used to solve these problems, a new class of name servers and resource managers known as traders has been proposed [3] [8]. The work that has been carried out in the RHODOS project has proved that it is possible to create a trader within a local homogeneous distributed system [6]. A prototype of such a trader, which provides the maximum possible autonomy and flexibility to users, yet at the same time allows them to share accessible resources, has been developed for a distributed system supported by an attribute naming facility [5]. This trader is based on the concepts of user and system domains and the operations of resource export, withdrawal, and import. The attribute names which support the trader provide users a comprehensive view of shared resources, as a RHODOS attribute name is the combination of syntactical and semantic representation of named entities in the system. These original concepts and operations allow both a user to export a resource in order to make it visible to other users and to make it sharable subject to export conditions, and other specified users to import this resource in order to

2 access it according to an agreement between the resource exporter and the user who wants to use it. It is the task of a trader to provide all these services. The original concept of a trader providing user autonomy and resource sharing has been extended in order to allow users to access resources which are not available in their local distributed systems, but are in use in other local distributed systems [7]. These connected distributed systems are homogeneous and form a homogeneous large distributed system. The extended trading service consists of a set of cooperating traders, each of which works within a local distributed system. However, as we indicated above, users wish to access a greater variety of objects in order to improve the quality of work and performance; besides, those resource owners want to keep maximum autonomy in controlling of their resources such that they are not abused by unexpected users. This has generated the need to extend our initial concepts of trading among homogeneous local distributed system to a heterogeneous environment. The goal of our current research is to develop a prototype of a trading service in a heterogeneous distributed environment, and to gain experience with this new class of resource naming and management facilities. We propose that a trading service should be built in a distributed fashion, which means that each local system should have its trader and that those traders should cooperate with each other. The aim of the paper is to present the design and the implementation of a prototype of a trading facility for a heterogeneous large distributed system. This prototype has been built in a heterogeneous environment consisting of a group of RHODOS distributed systems [1] supported by attribute naming, and a Unix system supported by partitioned naming. 2 Trading and heterogeneous distributed systems A heterogeneous large distributed system consists of a number of disparate local computer systems, under the control of (possibly) dissimilar operating systems. The entire heterogeneous large distributed system is managed by an open operating system. Trading is a new concept of resource naming and management, and it can be applied in an open operating system. The trading model is based on the concepts of resource export and resource import [5]. It is assumed that a single operating system supports a number of users who have their own private resources and keep exclusive control of them. The resource export is performed by resource owners who wish their private resources to be made available for use by other users subject to specified export conditions. Another user who wishes to use the resource imports the resource following the export conditions. Importing users should be able to select the resources that best suits their needs. Trading is thus defined as an activity of exporting and importing. This activity is aimed at choosing and sharing resources such that they match some specific requirements. The choice is based on the comparison of a user requirement specification and resource descriptions which are supplied by a resource exporter. The sharing is subject to the export conditions provided by the exporter and agreed to by an importer. A trader is a software entity which provides a trading service to both resource exporters and importers. This implies that a resource must be described by a suitable name scheme and that the resource descriptions must be known to the traders. The problem is that in a heterogeneous large distributed system each local system uses its naming scheme. The name heterogeneity results form two facts. First, the naming of resources suggested in literatures falls into two categories: partitioned and attributed [4]. Partitioned name schemes have been used in most existing operating systems. A Unix path-name is an example of a partitioned name. An attributed name, e.g., an X.500 attributed name or a RHODOS attributed name [6], is a set of attributes that uniquely identify a resource in a system in which it is administrated. Second, though most existing operating systems use partitioned names, the name conventions are different, e.g., /home/ying/file.dat.a and [home.ying]file.dat;1. A trader has to be able to deal with the name heterogeneity problem and to provide name and location transparency to users. It means that users should have a uniform view of both local and remote resources, and that they need not be aware of the location where their jobs are executed the local system or a remote system. A trading service in an open operating system can be implemented by a number of cooperating traders, with one in each local system, as shown in Figure 1. This approach leads to a distributed trading service which allows each local system to be independent, and preserves autonomy for each local system. This implies that each trader is responsible for local sharable resources. With this distributed approach to a trading service, a user needs only to contact the local trader when exporting or importing a resource. By cooperating with remote traders, the local trader is able to locate a resource which is not available in the local system, to import it, and to make is accessible to a requesting user.

3 user 1 user n user 1 user m TS 1 TS 2 server agent server agent distributed system 1 distributed system 2 name server trader name server trader communication super computer system distributed system 3 TS 4 TS 3 naming and trading database naming and trading database RHODOS trader 1 RHODOS trader 2 Figure 1: An example of a trading service in a large distributed computer system., TS trading server (trader) user 1 user l trader agent UNIX trader 3 The architecture of the trading service export/import database The architecture of a prototype trading service for a heterogeneous large distributed system, consisting of two distributed systems controlled by the RHODOS distributed operating system [1] and a centralized system controlled by the Unix operating system, is shown in Figure 2. The trading service is based on an attributed naming scheme which can precisely describe properties of resources, and is built as a set of local cooperating traders. Each RHODOS trader is such a component of the RHODOS distributed operating system [5] which: preserves user autonomy as in a centralized environment; supports sharing both by allowing resources either to be exported to other domains or to be withdrawn from service, and by allowing resources which have been exported by users from other domains to be imported; is based on attribute names, in order to improve userfriendliness and to provide a semantic-based interface to users. Each local RHODOS naming and trading facility which trades resources within a local RHODOS system [6] consists of two servers which perform two distinctive sets of functions: Figure 2: The architecture of the trading service. a name server which provides the conventional naming operations, such as creating a file, changing a file name, deleting a file, changing a resource attribute, etc., and a trader which provides trading operations, i.e., exporting, importing, and withdrawing of resources. These traders have been extended in order to support sharing in both heterogeneous and heterogeneous large distributed systems [7]. As a result of this extension, these traders can cooperate with traders which support dissimilar local systems, e.g., a Unix system, and can deal with the name heterogeneity arising from different name conventions supported by these local systems. The Unix trader, in contrast with the RHODOS trader, runs on top of the Unix operating system as an application program. In a Unix system, resources are managed by the Unix file system based on path-names. The sharing of resources within the Unix system is carried out in terms of access rights. An owner can change a file s access rights to make it sharable to other users of the system. To be able to access a sharable file, other users have to know the pathname of the file. However, a path-name poorly describes the properties or quality of a resource that it identifies; it is hard to carry out the trader process based on path-names. To cooperate with the RHODOS traders and to precisely describe shared resources, the Unix trader supports attribute names which are used to name resources

4 exported/imported to/from the Unix system. Both attribute names and Unix path-names are supported by the Unix trader. The former are used by the Unix trader when it performs the trading operations. The latter are used by the Unix trader to locate exported Unix resources in the Unix file system and by Unix users to refer to imported RHODOS resources. The Unix trader translates an imported resource s attribute name to a Unix path-name, so that Unix users are able to access it with a path-name. For an exported Unix resource, the Unix trader assigns an attribute name to it according to the description given by the exporter, while retaining its path-name as one of the attributes in its attribute name. 4 Trading domains Traders distinguish the sharable resources from ordinary local resources by means of domains; in particular, trading domains. Due to the different way in which resources are managed in their local systems, i.e., distributed and centralized, the naming domains are formed differently in RHODOS and Unix. All resources of the RHODOS operating system belong to the RHODOS naming domain. These resources can be grouped into three classes: private resources those owned by individual users, system resources those owned by the RHODOS operating system, and shared resources 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 resources belong to three subdomains of the RHODOS domain: user subdomains, a system/administrator subdomain and a trading subdomain, respectively. Thus, resources in the RHODOS system belong either to a given user domain or to the administrator domain. A user or the administrator is the owner of resources in their domain and controls access to resources in their domain. Belonging to the subdomain implies that each RHODOS resource 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 import it. In the Unix system, all resources belong to the Unix system domain. Each resource in the Unix system domain has a path-name based on the existing Unix directory. In other words, these resources are represented to Unix users as ordinary Unix resources and are accessed normally by Unix users. Following our trader approach, we propose the establishment of two subdomains of the Unix system domain: a users and administrator subdomain, which is equivalent to the ordinary Unix domain, and a trading subdomain, to be used to support both export and import of Unix resources, and to access resources from remote systems. In summary, those resources which are not allowed to be accessed by users of other local systems belong to the user and administrator domain. Those resources which have been exported to other system domains, and which have been imported by Unix users from other systems, belong to the trading domain. Therefore, each Unix resource can be: visible and sharable with users outside the Unix system if the resource is in the trading domain, or invisible to outside users if it is not in the trading domain. By logically separating sharable resources from ordinary Unix resources, the Unix system autonomy and security are enhanced when the system connects to a heterogeneous large distributed system. 5 Trading service operations There are three basic operations that are provided by the trading service: export, import, and withdrawal. The owner of a resource registers the resource with the local trader through an export operation. After successful completion of the export operation, the resource becomes visible in the domain(s) to which it has been exported. When exporting a resource, the exporter invokes an export primitive operation with three parameters: attribute list a sequence of the resource attributes specified by the exporter. This sequence should be an evaluable RHODOS attribute name, if the resource is a RHODOS resource, or a sequence of properties of the resource, in the form of resource attributes, specified by the Unix exporter; domain list a list of the name(s) of the domain(s) to which the resource is to be exported; export conditions a list of conditions specified by the owner, including the time period during which the resource will be available, the cost of using the resource and the conditions under which the resource may be withdrawn. An exported resource must be imported before a user in another system can access it. To import a resource, a user issues an import operation with the specification of a required resource. This specification is in the form of an attribute name. The result of the import operation is: in the RHODOS system, an entry about the imported

5 resource is placed in the importer s naming database, or in the Unix system, an entry about the imported resource is placed in the Unix trading database and a Unix pathname of the imported resource, which is a link to the entry of the imported resource in the Unix trading database, is placed in the Unix importer s home directory. A previously-exported resource can be withdrawn from the trader if the owner does not want it to be shared any more. The exporter can initiate the resource-withdrawal operation according to the export conditions specified at the export operation stage. As a result of the withdraw operation, the withdrawn resource no longer exists in the specified trading domain. 6 Trading databases To map an attribute name to a resource requires information about the resource. To manage a shared resource requires information about the resource s export/ import status the export conditions, the name of the importer, etc. This information is stored in databases and maintained by traders. 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 and each user have their own logical naming subdatabases in the naming database to store their private resources in order to keep exclusive control of them. The RHODOS trading database contains trading information. It also records the details of various import and export operations which have been performed on a resource. Each resource in the RHODOS trading domain has an entry in the RHODOS trading database. The trading database entry for a resource has three logical sections. The first section is related to the shared resource itself. The second section relates to the export/ import of the resource. The third section records the details about the resource import. 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 resource entry until the resource has been imported by other users. Each resource in the Unix trading domain can be viewed and accessed with both an attribute name and a Unix path-name. The Unix trading database contains the information necessary to map an attribute name onto the Unix path-name or vice versa, and the information about resource sharing, such as export/import conditions. The database has two separate parts: export database and import database. The export database stores data which are relevant to resources exported by Unix users. The import database stores data which are relevant to resources imported from remote operating system domains. 7 Traders and their components The currently-implemented trading-service prototype runs in a simulated heterogeneous environment consisting of two RHODOS distributed systems and a Unix system shown in Figure 2. 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 clientserver model and the modular structure of their architecture enables their functional components to be distributed if necessary. Due to the heterogeneity of the RHODOS operating system and the Unix operating system, their traders have different local environments and therefore the architecture of these traders are different in order to cope with their local environments. Each trader keeps information about available resources in its local trading domain. This means that the local trader knows the location of local exported resources; importing traders only know the location of the trader from which a resource has been imported. In case an imported resource migrated to another trading domain, the original trader is responsible to keep tracking of the new location of the migrated resource. This implies that no global information about exported resources is stored by any trader. There is a requirement for cooperation between traders when a trading operation is being performed upon the assumptions stated above. The general form of cooperation is as follow: the export operation is carried out locally by the local trader; the information about exported resources is stored in the local trading database; the import operation is carried out first locally by the local trader searching its local database to find if it already has that resource; if the resource is not found, it forwards the request to another trader, starting a remote import procedure. As there is an entry for an imported remote resource 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. the trader resolution, the purpose of which is to locate the remote trader managing the resource of interest to the

6 importer, is carried out in an iterative way [Goscinski 1991]. The local trader calls each remote trader while retaining control over the resolution process; each remote trader does it best to evaluate a given name locally. 8 Conclusion In this paper, we have described a new class of name service and resource management a trading service and demonstrated the feasibility of the basic trading concepts used in its logical design. We have shown that it is possible to build a trading service which provides resource sharing in a heterogeneous distributed environment. We have proved that resource sharing among heterogeneous operating systems can be achieved by introducing the concepts of export and import resources to/from different naming domains. We showed that exported resources, i.e., resources in the trading domain, are visible to users outside the local name domain via the local trader. A user can access resources which are not available in the user s local system domain by importing them into the local system domain. Another major result is a demonstration that the attribute name scheme is a suitable scheme for a trading service. It has been shown that with attribute names, name heterogeneity resulting from different name schemes used by underlying local operating systems can be easily resolved. Moreover, attribute names give users and traders a semantic view of named entities in the system. A trading service based on attribute names provides users with name and location transparency to view and access remote resources. We have also shown that the use of attributes has the potential to make resource sharing very effective in an open operating system. There are several issues which should be addressed in future research on trading. One is to find an efficient searching strategy between multiple traders. Other issues include finding an effective algorithm to match resources in a trading domain with user requirements and to define a name conversion protocol to minimize the number of name conversions needed for dealing with multiple name schemes supported by the trading service. [2] A. Goscinski Design Issues of Operating Systems for Open Distributed Processing. Proceedings of the ACUS and BASSER Workshop on Open Distributed Processing, Sydney, January. [3] A. Goscinski and M. Bearman Resource Management in Large Distributed Systems. Operating System Review, October. [4] A. Goscinski Distributed Operating Systems: The Logical Design. Addison-Wesley. [5] 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. [6] A. Goscinski and A. Haddock The Development of a Prototype Attributed Naming Facility Supporting User Autonomy and Object Sharing, Submitted to The Computer Journal. [7] Y. Ni and A. Goscinski Trader Cooperation to Enable Objects Sharing among Users of Homogenous Distributed Systems, Submitted to the Special Issue of Computer Communications. [8] R. van der Linden and J. Sventek The ANSA Trading Service. IEEE Distributed Processing Technical Committee Newsletter, Vol. 14, No.1. References [1] 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), Atlanta, March.