Design of a Real-Time Trader for Mobile Objects in Open Distributed Environments

Transcription

1 Design of a Real-Time for Mobile Objects in Open Distributed Environments Song-yi Yi, Heonshik Shin Department of Computer Engineering Seoul National University Seoul , Korea fyis, shinhsg@ce2.snu.ac.kr Abstract Advances in wireless communication and distributed computing will create a new computing environment where mobile objects can work in real-time over heterogeneous systems anywhere and at any time. In this environment, real-time traders which can perform trading services under timing constraints are required. In this paper, we identify design issues of a real-time trader for mobile objects and investigate them. Our work focuses on the design of real-time trading mechanism, trading interfaces, and the interactions of interworking traders to provide real-time trading services for mobile clients and servers. 1. Introduction As computer and communication technologies evolve, it will become possible to run real-time applications in distributed environments. Moreover, future distributed realtime applications should also provide services for mobile users. The needs for information accesses for mobile users are rapidly increasing. Multimedia multiconnection conference among mobile users, remote diagnosis for mobile hosts, and supporting mobile field technicians who require real-time access to data services can be some of these examples. In this environment, real-time traders which can perform trading services under time constraints are required. A trader is an object in which servers can export their service offers and from which clients import references of servers that match clients needs[1, 2]. Trading service is necessary in open distributed systems to provide location transparency and late binding of distributed mobile entities. Any number of traders can exist in a given distributed system and these may be linked to allow access to services in different domains. This is called interworking or federation of traders. When traders interwork, the service offer space in which a search is performed to find appropriate servers is extended to the whole interworking traders. Thus, trading over interworking traders may take very long time due to the large search space as well as mobility of servers and clients. In case of real-time applications, finding appropriate servers should not cause unbounded waiting of clients. Searching an appropriate server in the trading network and delivering the reference to the mobile client should be completed within a deadline. In the real-time distributed system, the trading request has time constraints within which the trading service should be completed. Real-time trading needs to reduce searching time by traversing selected traders which may have a service instance of required service type. We have presented a real-time trader[3] which can service as many trading requests as possible within their deadlines under the premises that physical location of clients and servers are fixed and the trading network seldom changes. Also a real-time trading request scheduling algorithm has been proposed to satisfy the deadlines of as many trading requests. Since we assumed that trading network seldom changes and servers export relations were fixed once they were established, all the information for accessible services was analyzed and used for real-time scheduling of trading requests. However, to support real-time trading for mobile servers and clients, the above assumption is no longer valid and the real-time trading mechanism must be redesigned. In this paper, we will present a real-time trading mechanism for mobile clients and servers. Mobile clients and servers can be connected via wireless communication links. Since a mobile host changes its location so frequently, it is inefficient if the mobile host exports, withdraws and exports again whenever it changes its location. Some new trading interfaces are needed for a real-time trader in such a frequently changing environment. We will also describe some

2 design issues for a real-time trader to support real-time properties and mobility of clients and servers. This paper is organized as follows: Section 2 describes design issues of real-time trader for mobile hosts. In Section 3, a real-time trading mechanism and real-time trading interfaces are presented. Finally, Section 4 presents some concluding remarks. Real-Time Export Real-Time Import Within a deadline Real-Time Binding 2. Design Issues of a Real-Time 2.1. Trading model Our trading model is based on the RM-ODP[2]. The Reference Model of Open Distributed Processing was a joint effort by the international standards bodies, ISO and ITU-T, to develop a coordinating framework for the standardization of open distributed processing. The model describes an architecture within which support of distribution, interworking, interoperability and portability can be integrated. The ODP provides dynamic binding by allowing services to be discovered at run-time. The trader is a repository of services advertisement. Server objects advertise their services through a trader; the service advertisement specifies the interface type and service attributes. Servers manipulate their service advertisements by using the export operations provided by the trader. Clients choose services by specifying the required type, attributes and related constraints of services in import operations. In addition, any number of traders can exist in a given distributed system, and they are linked by exporting their trading services to other traders. Figure 1 shows a simple real-time trading process. The trader is an object in which servers can export their service offers, and from which clients import references of servers that match clients needs within a deadline. A service offer which a server exports is considered a service instance. Many service instances for the same service type exist if more than one server have exported the service instances of the same type. By providing many service instances of the required service type, a trader enables clients to choose appropriate servers dynamically. A real-time trader also provides location transparency of servers, and late binding of a client with server. We assume that servers and clients are mobile, and each trading request for an import has a deadline. In our mobile environment, the system consists of a fixed information network extended with wireless components. These components include wireless mobile hosts, base stations, and switches. Mobile hosts are connected to fixed part of the network via base stations, and the area covered by a base station is called a cell[4]. Clients can be located at mobile hosts or fixed hosts, and issue trading requests. After a server(client) exports(imports) a service offer to(from) a trader, it can change Client Server Client Server Client Figure 1. Trading process Server its physical location. This makes the exported information such as the address field in the interface reference become incorrect after the server has moved. Also, a mobile client will wake up in a different trading environment after it changes its physical location. The imported service offer may be unreachable in the new environment Design issues of a real-time trader for mobile clients and servers Davies et al.[5] built an experimental advanced mobile application, Geographical Information Systems for mobile users, on the RM-ODP platform. Although the open distributed system architecture does not impose any constraints on the pattern of interconnection, most conventional distributed systems such as RM-ODP and ANSAware organize interworking traders in a hierarchical structure. According to their study, while possibly adequate for fixed networks, the hierarchical arrangement is inappropriate for mobile systems where each mobile host is likely to have its own trader in order that it can continue operation during periods of disconnection. Moreover, given the nature of the communications network, a link scheme that requires traversal up and down a hierarchy is clearly unsuitable for real-time trading. The design issues of real-time trader for mobile hosts are as follows: Where to place traders: In the fixed part of the network or inside mobile hosts. s can be placed at fixed locations such as base stations, location servers, or fixed hosts. If this is the case, trading requests from mobile clients are forwarded to traders at fixed location. Mobile hosts must find out the location of the nearest trader for each trading request at the new location. s also can be placed inside the mobile hosts. When a mobile client needs a trading service, it searches its own local trader first. If it fails, it contacts interworking traders. Since there is no communication delay in contacting the local trader, it is more likely

3 to finish the search within a deadline. When a mobile server exports a service offer, it also contacts the local trader first. Then, the exported service is usually propagated to interworking traders which are located at the fixed part of the network. Our real-time trading mechanism is based on the second approach. However, the local trader in a mobile host has some limits in size and processing speed. Due to its limitations, traders in mobile hosts keep information only for a few service instances which are time critical. How to organize interworking traders: This is important in the sense that the organization of interworking traders affects the search time. s in AN- SAware are organized into two-level hierarchy, master and local[1]. If there is a strict rule in interconnecting traders, the search time can be easily bounded by the length or size of the interconnection network of traders. However, to support the mobility of users, the interconnection among traders should be allowed in any structure and can be dynamically changed. Searching policy: To find service offers that match a client s request, interconnected traders must be accessed in a certain order. Most commonly used form of a search is DFS(Depth First Search) or BFS(Breadth First Search). Service offers can be found by the first hit or the best hit policy, or till the specified number of service instances is reached. Since there is a deadline in searching a service offer, at least the first hit must be found within a deadline. If service instances in the local trader match the client s request, a search is not needed. In most cases, however, due to the characteristics of a local trader in a mobile host, the federated traders need to be contacted. After a search at the local trader of a mobile host fails, the trader located in base station of the current cell is searched. Scheduling policy: Import trading requests have deadlines. There are many import trading requests pending at a trader at one time. These requests were submitted from its clients and interworking traders. They should be scheduled by the real-time scheduling policies[6] such as Earliest Deadline First. To satisfy as many clients request as possible within their deadlines, the search time required for each client s import trading request must be limited as well as the number of service instances to be searched. In the next section, we will describe our real-time trading mechanism more precisely. 3. Real-Time Trading Mechanism 3.1. Real-time trading and interworking mechanism In this section, we provide a trading mechanism which can support both mobility and real-time properties for trading operations. We assume that there are deadlines only for the import trading requests. According to our assumptions, export trading operations are not time-critical. However, conventional export trading operation should be also modified to support the real-time import trading operation. trading requests from clients DB User interface manager if found Directory Server Real-time scheduler of trading requests Worst case searching time of adjacent interworking traders trading requests from other traders interface Manager Queue Search local trader database (if not found or to find other available sevices) and the deadline has not been reached yet Compute the new deadline Select the next trader to be searched among interworking traders Request Generator generate a trading request to the next trader Figure 2. Functional Architecture of a Realtime Figure 2 shows the functional structure of our trading

4 model. User Interface Manager receives trading requests from clients, and sends real-time import requests to the realtime scheduler. User Interface Manager identifies the trading service type and checks the clients authorizations. If a request is for an import, it is sent to the real-time scheduler with its deadline. Import trading requests can be also issued from its interworking traders. Interface Manger receives the import trading requests and sends it to the realtime scheduler. The real-time scheduler schedules these import trading requests according to their deadlines. The real-time scheduling policies such as Earliest Deadline First or priority scheduling can be used based on the characteristics of trading requests. For example, a client can issue import request to a real-time trader periodically. If this is the case, the real-time scheduler should schedule the requests by realtime scheduling mechanism of periodic tasks[7]. Finding appropriate servers for an import request is continued until its deadline is reached. When there are many requests in the queue, the trader can limit the search time for each request or the number of service instances to be searched even though the deadline for the request has not been reached yet. To find service instances for each trading request, the trader searches its local data base, first. If a service instance of desired type is not found in the trader s local database, the import request is sent to the interworking trader. An import request is also forwarded to adjacent traders if the client gives the option to specify the number of service instances or the trading domains. When an import request is forwarded to one of its adjacent traders, the new deadline of the import request is computed. The search time at the local trader is subtracted from the given deadline. Since traders keep track of trading results and the worst case searching time for interworking traders, the next trader to be searched is decided based on this information. The table which stores all the worst case searching time of adjacent traders are updated when an export relation is newly established or some attributes are changed. This will be explained at the section In our model, each mobile host has its own local trader to speed up some real-time trading operations and to reduce communication traffic. Due to the characteristics of a mobile host[8, 4], its local trader is very limited in size and speed compared to the ordinary trader in a fixed location. Thus, the trader in a mobile host usually interworks with a trader at the nearest fixed location(i.e., a base station under which it is currently resides). In our mobile environment, there are three different types of interworking relations. 1. Trading between a mobile host and a fixed host. s in mobile hosts are federated into the trader in the nearest base station. The trader at the base station is regarded as a prime trader, and traders in mobile hosts as local traders. Prime traders collect services from fixed hosts and mobile hosts. It can also broadcast this information periodically to the mobile hosts. This will greatly reduce searching time of import requests from mobile hosts. Especially, if some import requests from mobile hosts arrive periodically and are time-critical, the base station can broadcast its available service instances to mobile hosts in advance. When a mobile host leaves its current cell, an export or import relation with a trader at base station is maintained, and the fact the mobile host has left is notified. After some time later, when the mobile host comes back to the cell, it doesn t need to establish export or import relation again. It only notifies its arrival to the base station. 2. Trading between mobile hosts. High cost of using a wireless channel would prevent this interworking relation from occurring frequently. 3. Trading between fixed hosts. s in the fixed part of the network can be federated in any form. The reasons are that trading relations in the fixed part seldom change, and that search paths or their search times are fixed most of the time. All the necessary information such as worst case searching time for the exported services is computed and stored when a trader is exported to another trader. Real-time scheduling of import trading requests is based on this information Real-time trading interfaces The interfaces described in this section are based on the DPE(Distributed Processing Environment) s trading interfaces[9]. To support mobility and real-time properties, DPE s Export Interface and Search Interface should be modified. Additionally, the Notification of Leave/Arrival interface is added Export operation The following interfaces are provided for the export operation. Servers export, modify, or withdraw services via following interfaces. When a server is mobile, additional information such as its mobility pattern and its previous base station is exported. Notification of Leave/Arrival is needed only for mobile servers when its move causes a change of the current cell, that is, its prime trader. Whenever an export relation is established or destroyed between two traders, the tables which keep the worst case searching time of interworking traders are modified.

5 Export Interface: When a service offer is registered, service constraints, export constraints, and service attributes are registered. For a mobile server, its mobile pattern, if known, is registered, too. When the export occurs between traders(when a trader is federated to another trader), additional information is required. For example, if trader A exports its services to trader B, trader A registers its database size, the number of service offers, the average number of trading requests pending at A, the number of interworking traders, and the communication time including communication delay. Then, trader B computes and stores worst case searching time of A. B serves its import trading requests by forwarding the requests to A or other interworking traders based on the above information. Modify Service Attributes: Service attributes can be changed after the service is exported. Changes in service attributes can cause recomputation of worst case searching time. The table which trader keeps worst case searching time tries to maintain up-to-date value by adapting this information. Withdraw Service Offer: A server can remove a service offer from the trader to which it exported its service. In case of a mobile server, it sends a withdrawal offer to the current prime trader, then, the current prime trader will send a withdrawal offer to the original trader to which the mobile server exported the service. Notification of Leave/Arrival: When a mobile server changes its location, instead of withdrawal of its service, it sends Notification of Leave to the prime trader with which it has interworked. By using this interface, unnecessary withdrawal and export operations are reduced Import operation Import operation should be served in real-time, which means that each import request has its deadline. The deadline is given by the client of the real-time trader and recomputed when the import trading request is forwarded to another trader. Search Interface: Search Interface contains search predicates, search constraints, and a deadline within which the search must be completed Select Interface: Select Interface selects a service offer among service instances produced by Search Interface. If only one service offer is found within a deadline, Select Interface is not needed. In case of a mobile client which searches services from its local trader first, the local trader keeps information about time-critical service instances. If an import trading request is forwarded to a prime trader and the mobile client leaves its prime trader after that, the import request can miss its deadline even though the service instance of desired type is found at the prime trader within a deadline. By notifying its leave and leaving forwarding pointers to a new location, the service instance found can be forwarded to the new prime trader within the deadline. We assume, however, that this rarely occurs. Once the import trading request is sent, the mobile client does not leave its current cell until it receives the reply. Moreover, after a mobile client changes its cell, its imported services can be no longer accessible and the information the local trader hold can be useless in the new environment. In this case, the new prime trader is searched first for an import trading request. 4. Concluding Remarks Real-time traders are needed to support real-time applications in open distributed environments. As clients and servers move, the trading operations become more time-critical due to their mobility. However, supporting both mobility and real-time properties is not easy. To support real-time properties, the distributed system should analyze and properly schedule traders behavior and their available resources in advance, while to support mobility, it should not damage the dynamic nature of mobile hosts. In this paper, we have described real-time trading services for mobile clients and servers, and identified some design issues of a real-time trader. We also presented some trading interfaces which support the real-time trading mechanism we proposed. The real-time trader we proposed aims to serve as many trading requests as possible within their deadlines. Our realtime trader schedules trading requests based on the worst case searching time of interworking traders. This is not optimal for systems which have parallel execution paths: A worst case scheduling algorithm can cause a deadline miss even if the schedule is feasible based on real search time. However, the worst case searching time is deemed a safe criterion in scheduling trading requests of mobile objects. An attempt to bound this worst case searching time more tightly by taking into account timing characteristics with mobile pattern of mobile objects remains as a further research topic. References [1] J. P. Deshrevel, A. Watson, A brief overview of the

6 ANSA Trading service, Architecture Project Management, UK, Feb [2] M. Y. Bearman, ODP-trader, Intl. Conf. on Open Distributed Processing, Berlin, Sept [15] G. H. Forman, J. Zahorjan, The challenge of mobile computing, University of Washington, TR # , 1994 [3] S-y. Yi, J. Lee, H. Shin, Operating system support for the trader in distributed real-time environments, Proc. of the 5th IEEE Workshop on Future Trends of Distributed Computing Systems, pp , Aug [4] T. Imielinski, B. R. Badrinath, Mobile wireless computing: Solutions and challenges in data management, DCS-TR-296/WINLAB-TR-49, 1994 [5] N. Davies, G. S. Blair et al., Experiences of using RM-ODP to build advanced mobile applications, Distributed Systems Engineering, vol.2, no.3, pp , Sept [6] A. Burns, Scheduling hard real-time systems: A review, Software Engineering Journal, vol.6, no.3, pp , 1991 [7] L. Sha, S. Sathaye, A systematic approach to designing distributed real-time systems, IEEE Computer, vol.26, no.9, pp.68-78, Sept [8] B. R. Badrinath, A. Acharya, T. Imielinski, Designing distributed algorithms for mobile computing networks, pp.21-28, Proc. of the 14th Intl. Conf. on Distributed Computing Systems, May 1994 [9] F. Dupuy et al., DPE Phase 0.1 Specification, TINA Consortium, Dec [10] K. Arvind, K. Ramaritham et al., A local area network architecture for distributed real-time systems, Journal of Real-Time Systems, vol.3, May 1991 [11] A. M. van Tilborg, G. M. Koob, Foundations of realtime computing scheduling and resource management, pp.31-62, Kluwer academic publishers, 1991 [12] C. L. Liu, Fundamentals of real-time scheduling, Proc. of the NATO Advanced Study Institute on Real- Time Computing, Oct [13] A. Bondavall, L. Simoncini, C. Bernardeshi Distributed, dependable real-time systems using a functional paradigm, Proc. of the NATO Advanced Study Institute on Real-Time Computing, Oct [14] A. Schill, B. Bellman et al., System support for mobile distributed applications, Proc. of 2nd Intl. Workshop on Services in Distributed Network Environments, pp , June 1995