Citation
Context-Aware, Ubiquitous Service Discovery and Delivery for Mobile Clients

Material Information

Title:
Context-Aware, Ubiquitous Service Discovery and Delivery for Mobile Clients
Creator:
LEE, CHOONHWA ( Author, Primary )
Copyright Date:
2008

Subjects

Subjects / Keywords:
Centroids ( jstor )
Ice ( jstor )
Leases ( jstor )
Mobile devices ( jstor )
Munchausen syndrome by proxy ( jstor )
Preliminary proxy material ( jstor )
Proxy reporting ( jstor )
Proxy statements ( jstor )
Registry ( jstor )
Ubiquitous computing ( jstor )

Record Information

Source Institution:
University of Florida
Holding Location:
University of Florida
Rights Management:
Copyright Choonhwa Lee. Permission granted to the University of Florida to digitize, archive and distribute this item for non-profit research and educational purposes. Any reuse of this item in excess of fair use or other copyright exemptions requires permission of the copyright holder.
Embargo Date:
8/1/2007
Resource Identifier:
1111630319 ( OCLC )

Downloads

This item is only available as the following downloads:


Full Text

PAGE 1

CONTEXT-AWARE, UBIQUITOUS SERV ICE DISCOVERY AND DELIVERY FOR MOBILE CLIENTS By CHOONHWA LEE A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLOR IDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY UNIVERSITY OF FLORIDA 2003

PAGE 2

Copyright 2003 by Choonhwa Lee

PAGE 3

To my family

PAGE 4

iv ACKNOWLEDGMENTS First and foremost, I would like to express my deepest gratitude to my advisor, Dr. Abdelsalam (“Sumi”) Helal, for giving me the opportunity to work with him and to study under his guidance. Without his continuous inspiration, support, and encouragement during my years of doctoral stud y, this research would not be complete. I would also like to offer my sincere appreci ation to my supervisory committee members, Dr. Stanley Y. W. Su, Dr. Joachim Hammer , Dr. Michael P. Frank, and Dr. Alan D. George, for their precious time and advice. This work was supported in part by Moto rola, Inc. and by the Department of Education to whom I am grateful. Also, I appreciate the friendship and enc ouragement of all the colleagues at the Harris Mobile Networking and Communicati on Laboratory while working and studying together in the lab. My thanks should also go to many friends who shared all the happy moments and wonderful memories during my stay in Gainesville. I owe great love to my parents who have always supported and cared for me. I am also grateful to my parents-in-law, my si sters, and my brothe r for their continuous encouragement. Last, but not least, I w ould like to thank my wife, Soyoun, and son, Jongmin, for their love and patien ce throughout my doctorate program.

PAGE 5

v TABLE OF CONTENTS Page ACKNOWLEDGMENTS.................................................................................................iv LIST OF TABLES...........................................................................................................viii LIST OF FIGURES...........................................................................................................ix ABSTRACT....................................................................................................................... xi CHAPTER 1 INTRODUCTION........................................................................................................1 Mobile Service Discovery Scenarios............................................................................1 Context-aware Service Discovery................................................................................2 Context-aware Computing.....................................................................................2 Context-awareness for Service Discovery.............................................................3 Main Contributions.......................................................................................................4 Organization of the Dissertation...................................................................................7 2 RELATED RESEARCH..............................................................................................9 Service Discovery.........................................................................................................9 Service Discovery Protocols..................................................................................9 IETF SLP......................................................................................................10 Sun Jini.........................................................................................................11 Microsoft UPnP............................................................................................14 Other service discovery protocols................................................................16 Comparison of service discovery protocols.................................................17 Ad hoc Service Discovery...................................................................................18 Wide-area Service Discovery..............................................................................20 Server Selection Mechanisms.....................................................................................21 Server-side Approach..........................................................................................21 Network-side Approach.......................................................................................21 Client-side Approach...........................................................................................23 Service Delivery Technologies...................................................................................23 Jini ServiceUI project..........................................................................................24 XML-based approach..........................................................................................24 Template-based approach....................................................................................25

PAGE 6

vi 3 MOBILE SERVICE DISC OVERY FRAMEWORK................................................26 Overall Architecture...................................................................................................26 Three-tier Service Discovery Architecture.................................................................29 Proximity-based Service Discovery....................................................................30 Domain Service Discovery..................................................................................30 Advertisement of domain services...............................................................32 Domain query routing..................................................................................33 Promotion to global services........................................................................33 Global Service Discovery....................................................................................34 Context Awareness Support.......................................................................................36 Context-aware Service Advertisement................................................................36 Context-aware Service Discovery.......................................................................37 Device Capability Context Information..............................................................38 User Mobility Support.........................................................................................39 4 CONTEXT-AWARE SERVICE DISCOVERY........................................................40 Context Attribute and Scenario..................................................................................41 Context Attribute.................................................................................................41 Context-aware Service Discovery Scenario........................................................43 Guide service................................................................................................43 Movie preview service.................................................................................44 Movie theater service...................................................................................45 Printer service...............................................................................................45 Bus schedule service....................................................................................46 Context-Aware Service Discovery Implementation...................................................46 Definition of Context Attribute...........................................................................47 Context Attribute Processing...............................................................................50 Implementation of Domain Service Discovery Subsystem Prototype................52 Domain service discovery............................................................................52 Domain service advertisement.....................................................................52 Implementation details.................................................................................53 Experiments................................................................................................................55 Context-awareness for Service Discovery..................................................................62 5 GLOBAL SERVICE DISCOVERY PROTOCOL....................................................64 Centroid......................................................................................................................6 4 Class-based Service Pr opagation Protocol.................................................................66 CSP Query Routing....................................................................................................71 Simulation of CSP Protocol........................................................................................72 Workload Analysis..............................................................................................72 Simulation Results...............................................................................................76

PAGE 7

vii 6 SERVICE DELIVERY...............................................................................................81 Thin-client Approach to Service Delivery..................................................................81 Jini Proxy System Architecture................................................................................83 Jini Protocol......................................................................................................84 Resident Client....................................................................................................85 VTC Client..........................................................................................................85 Jini Proxy..........................................................................................................86 Dispatcher.....................................................................................................86 Proxy shell....................................................................................................87 Jini manager.................................................................................................87 Verifier.........................................................................................................87 Adapter.........................................................................................................88 VTC manager...............................................................................................88 MIDlet emulator...........................................................................................88 Performance Measurements........................................................................................91 7 SUMMARY AND FUTURE RESEARCH................................................................93 Summary of Contributions.........................................................................................93 Future Research..........................................................................................................94 LIST OF REFERENCES...................................................................................................96 BIOGRAPHICAL SKETCH...........................................................................................102

PAGE 8

viii LIST OF TABLES Table page 2-1. Comparison of major serv ice discovery protocols.....................................................18 3-1. Service classification by coverage..............................................................................27 4-1. Static attributes ve rsus context attributes...................................................................43 5-1. CD database word length distribution........................................................................75

PAGE 9

ix LIST OF FIGURES Figure page 1-1. Layers of discovery.....................................................................................................3 1-2. Service Discovery and Delivery Diagram....................................................................8 2-1. Service location protocol............................................................................................11 2-2. Jini discovery and lookup protocols...........................................................................12 2-3. UPnP Protocol Stack..................................................................................................15 3-1. Conceptual model of contextaware service discovery system..................................28 3-2. An example of domain registry tree...........................................................................32 3-3. Integration of domain and gl obal service discovery framework................................35 3-4. Evaluation of context attributes..................................................................................37 4-1. Service record a nd context attribute...........................................................................41 4-2. Java interface definitions of lo cal and remote context attribute.................................47 4-3. Java class definition of context evaluation result.......................................................47 4-4. Base class definitions for local and remote context attribute.....................................49 4-5. A sample ServerLoad context attribute......................................................................50 4-6. Context attribute processing.......................................................................................51 4-7. Reggie implementation architecture...........................................................................54 4-8. Jini lookup service performance.................................................................................57 4-9. Composition of lookup service CPU time..................................................................58 4-10. Client lookup time....................................................................................................60 4-11. Service time experienced by client...........................................................................61

PAGE 10

x 5-1. A Centroid example....................................................................................................64 5-2. Zero degradation of the first class..............................................................................68 5-3. TTL-based degradation of the first class....................................................................69 5-4. An example of service information attenuation........................................................70 5-5. An example of query routing......................................................................................71 5-6. CD database word distribution...................................................................................74 5-7. Service database si ze reduction by splits....................................................................75 5-8. Database size at each layer.........................................................................................76 5-9. Query cost versus syllable length...............................................................................78 5-10. General-to-specific query ratio versus cost..............................................................79 5-11. Update traffic at each layer.......................................................................................80 6-1. Overall Jini system architecture...............................................................................84 6-2. Components of Jini proxy........................................................................................86 6-3. MIDlet emulator.........................................................................................................89 6-4. Service startup time comparison.................................................................................92

PAGE 11

xi Abstract of Dissertation Pres ented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy CONTEXT-AWARE, UBIQUITOUS SERV ICE DISCOVERY AND DELIVERY FOR MOBILE CLIENTS By Choonhwa Lee August 2003 Chair: Abdelsalam (“Sumi”) Helal Major Department: Computer and In formation Science and Engineering Service discovery and delivery problems have recently been drawing much attention from researchers and practitioners. The SLP, Jini, and UPnP are some of the front-runners in this area. Although they seem to provide a good solution to the problem, there is an unaddressed need for more sophi sticated mobile, locationand context-aware service selection and mobile device support for service delivery as well as service discovery. In this dissertation, we introduce a multitiered mobile service discovery architecture that addresses the dynamics a nd the added requirements of mobility. We introduce the concept of context attribute as an effective, flexible means to exploit relevant context information during the serv ice discovery process. We also present a Class-based Service Propaga tion protocol (CSP) for gl obal service discovery and advertisement. The CSP protocol guarantee s better overall query performance without requiring excessive resource use. Combine d, context attributes and CSP protocol

PAGE 12

xii guarantee the scalability and e ffectiveness of service discove ry in the presence of popular services (services with a very large number of instances). We describe our architecture, concepts, and protocols, and present a perf ormance scalability study of global service discovery. Service delivery takes place following the service discovery phase to complete the dynamic service acquisition process. The two phases should be bridged by the client device capability information. As a proof-o f-concept prototype, we developed the Jini proxy system that allows a service to be discovered by and presented to any class of target devices using a virtua l thin-client architecture.

PAGE 13

1 CHAPTER 1 INTRODUCTION Since ubiquitous computing was envisioned by Mark Weiser [Wei91] in the early 1990s, it has been widely accepted as the ultimate technology for the post-PC era. Although it has often been quoted as “pervasi ve computing,” “invisi ble computing,” or “anytime, anywhere, any device computing,” depending on people and their orientations, these terms all largely have the same meaning: computation embedded in the environment is available everywhere to assist use rs in accomplishing their daily tasks. Interactions in that ubiquitous world are envisioned to be m odeled as service transa ctions. This includes service discovery, selection, leasing, and rende ring. Interactions may also entail the composition of basic services into newer, va lue-added ones. To realize this vision, an infrastructure should be in place to effec tively support service di scovery during user mobility and from a wide range of mobile devices. Mobile Service Discovery Scenarios The very first step toward the mobile a nd further ubiquitous co mputing vision is to enable dynamic service discovery. Mobile a nd wireless computing is permeating the globe, affecting the way we live and conduct bus iness using portable computers such as laptops, personal digital assistants (PDAs), smartphones, and even wearable computers. In becoming mobile, users innocently expect and demand the same computing luxury they used to (and still) enj oy in the fixed computing environment. Unfortunately, network resources (for example, printers, fax mach ines, and file systems) and applications, collectively called services , do not follow the mobile users when they leave their offices

PAGE 14

2 or homes, or when they relocate to another site. Impromptu access to the services in the new environment is enabled by dynamic service discovery protocols, as illustrated by the following classical scenarios [Hel03]. You are sitting in an airport lounge when you realize you need to print a document urgently. You use your laptop with a wireless card to search for a nearby printer. You get a response from some nearby printer, and fire a print command to that printer. Then you walk up to it and pick up your printout. You are in a mall in a new city and y ou feel like having some Chinese food. You use your wireless enabled PDA to look for “Chinese Food.” You get back a response from the server in some nearby Chinese restaurant. You are allowed to reserve a table and also order your Pe cking duck before you walk into the restaurant 15 minutes later. Context-aware Service Discovery Context-aware Computing In the last decade, enormous research e fforts have been concentrated on contextaware computing, now being considered as yet another key tec hnology to cope with challenges brought forth by the ubiquitous co mputing vision. According to Dey et al., context is “any information that can be used to characterize the situation of an entity, where an entity can be a person, place, or phys ical or computational object” [Dey99a, p. 114]. A good survey on how context can be be neficial in the ubiquitous environment is given by Chen et al. [Che00]. The authors classify context into the following four categories, extending the context defi nition of Schilit et al. [Sch94]. Computing context, such as network connectivity, communication costs, and communication bandwidth, and nearby resource s, such as printers, displays, and workstations User context, such as the user’s profil e, location, people nearby, even the current social situation Physical context, such as lighting, noise levels, traffi c conditions, and temperature Time context, such as time of a day, week, month, and season of the year

PAGE 15

3 Enabling context-awareness means to be able to infer usersÂ’ situations. By capturing implicit user intentions, it helps to prevent the users from being unnecessarily distracted from their task in the computationrich environment. Therefore, the benefit of context-awareness becomes more remarkable when it comes to components related to user interaction, including service discover y, delivery, composition, and user interface. Context-awareness for Service Discovery As in the general context-aw are computing research, context information is the key to the ubiquitous service di scovery problem. In other word s, context-awareness enables the right services to be delivered to the ri ght users (for example, at the right time and place, in the form and delivery mode most appr opriate to the mobile device, and so forth). The usersÂ’ intention is implicitly understood in the situations in a non-obtrusive manner by the effective interpretation of context. We envision the ubiquitous service discovery process to consist of four phases, capture d by the four layers shown in Figure 1-1. Figure 1-1. Layers of discovery The four phases are infrastructure discove ry, context discovery, service discovery, and subsequent service delivery phase. The in frastructure discovery cares about lowerlevel resource discovery, such as system or network resource acquisition. One example is for mobile devices to obtain their IP addresse s by stateful DHCP or stateless allocation Service Delivery & Interaction Service Discovery Context Discovery Infrastructure Discovery Context

PAGE 16

4 [Che02, Tho96]. Another example is Blue tooth SDP (Service Discovery Protocol) [Blu99], which is designed to discover lo wer-level services, for instance, LAN access points within range. Although the context disc overy and the service discovery are shown as logically separate layers, our view is th at the two layers are closely coupled, as the latter uses the service of the former. Client queries are resolved into references to services, considering their contexts capture d by the context discove ry layer. Finally, a discovered service is delivered to the client in an appropriate form and mode with regard to the combined context of the service and clie nts. For instance, a lig htweight version of a service can be selected for delivery into a less powerful device, or a thin-client adaptor can be used to deliver a heavyweight se rvice to a resource-poor device [Hel02]. Main Contributions As far as a small, proximity-based serv ice discovery system is concerned, the context-awareness problem has been well addr essed by several early research prototypes [Dey99b, Wan92, Wan95], where individual phases are somewhat separately performed. The prototypes have demonstrat ed particular applications ru nning in small, closed (that is, preprovisioned) environments, where much of the context is primarily derived from the proximity of services and users. Thes e prototypes, however, left other important aspects of the ubiquitous serv ice discovery unaddressed. Most critically, they provided no support for wide-area coverage and did not su fficiently exploit the use of context in dynamic service discovery. Although these limitations are to so me extent alleviated in general service discovery frameworks [G ut99a, Sun01b, UPn00], they are not sufficient for the ubiquitous computing vision. Recognizing this opportunity, we developed a novel approach to service discovery in which we provided support for mobility (l ocal and wide-area c overage) and context

PAGE 17

5 awareness. Our principal goal is to enable se rvices most appropriate for a given context to be discovered by the noma dic or mobile user, in his home network or any foreign roaming network; on a desktop environment or off a mobile device. This goal can be effectively achieved by adopting a new multilayer discovery paradigm that is more suitable for the dynamic and context-sensitiv e ubiquitous computing world. The four layers of the service discovery process s hown in Figure 1-1 need to be formally established and tightly coupl ed to better serve the user sÂ’ needs of dynamic service discovery. Implicitly captured context inform ation plays a pivotal role to glue these layers together and foster their cooperat ion toward successfully delivering the most appropriate service to the userÂ’s device. To pursue our vision of a multilayer service discovery paradigm, we implemented a protot ype of a context-awar e service discovery and delivery system, and conducted a simulati on study to evaluate a new global service discovery protocol. Our main contribu tions can be summarized as follows: Integrated service discovery framework . Several service discovery frameworks already exist that are diversified on grounds of different target device s, target application domains, and underlying networ ks. One of the most differe ntiating resultant features among them is their coverage. For example, one discovery protocol is specialized in local services, while another is dedicated to global services. The diversity requires clients who wish to access services anywhere to unders tand multiple service discovery technologies, but the resource-poor mobile devices cannot afford to host and accommodate multiple heterogeneous and fragmented service discove ry protocols. Theref ore, we developed a multitiered service discovery architecture th at incorporates proximity, domain, and global

PAGE 18

6 service discovery. The clients are provided with a single view of the integrated service discovery framework. Context-aware service discovery . A superabundance of services in the future ubiquitous computing world requires that service discovery be refined by means of context-awareness. Going beyond local areas , the importance of selecting the most appropriate service(s) gets magnified. This is because users will likely experience a much broader range of service quality in wide-area networks. Wit hout this screening, the users with resource-constrained mobile devices wi ll be easily overwhelmed by a large number of discovered services of unacceptable quali ty. Current server selection research addresses this issue (for example, the best service instance selection among identical service replicas). Current service selecti on mechanisms, however, require the selection process to be applied as a second step, occu rring after the service discovery phase, in a service-specific channel separate from the general service discovery network. We have integrated service discovery w ith service selection into a si ngle protocol. Our protocol uses a novel concept we call “context attribute” to enable the distri buted (network-based) and efficient on-the-fly selec tion. Also, we showed its effectiveness by developing and demonstrating a prototype of the cont ext-aware service discovery framework. Global service discovery protocol . A global service discovery network is the last resort, as service search space is gradually expa nded (it implies, in general, that proximity or domain services are preferable to the global ones, as long as they match the query.) Although a few systems have already been proposed that suppor t wide-area service discovery, their scalabilities are questionable or they do not address the need of ubiquitous, dynamic service discovery very well . We developed a new protocol to exploit

PAGE 19

7 the idiosyncrasy of service ubi quity and skewed query pattern in the future. Our protocol ensures efficient resource use by control ling the entire global service advertisement traffic. Thin-client-based service delivery . Context plays a key role in the service delivery phase as well. A service should be delivered in the most appropriate manner to client devices as a continuing process of the service discovery. However, current technologies focus on either the service disc overy or delivery pr oblem. For instance, current service discovery pr otocols, W3C Device Indepe ndence WG [Gim01], and W3C CC/PP WG [Kly02] are the separa te nonintegrated efforts. We demonstrated the benefits of gluing service discovery and delivery in the course of deve loping a new service delivery mechanism. Specifically, we have deve loped a thin-client adaptation architecture to deliver a range of lightto heavyweight services to resource-constrained devices. Organization of the Dissertation The diagram in Figure 1-2 illustrates enti ties involved in the dynamic service discovery and delivery scenario. It also indicates the scope of this dissertation. First, a service needs to be advertised to potential clients in local, doma in, and further global networks. The advertisement message may c ontain the service itself and associated descriptive information, includi ng static and context attributes ; the context attribute is our new approach to enable context awareness in a service discovery framework. Then, the advertisement is kept by a service director y through which a client can discover desired services. Services cached by the directory are narrowed down to those that satisfy not only a user query (specified explicitly by a client) but also device profile (probably appended to the query by default, that is , no user intervention) . Finally, the client accesses discovered services by connecti ng to corresponding service providers.

PAGE 20

8 Figure 1-2. Service Discove ry and Delivery Diagram This dissertation is organized into the following sections. Chapter 2 surveys related research, such as service disc overy protocols, server sel ection mechanisms, and service delivery methods. Chapter 3 introduces our inte grated service discove ry architecture. In Chapter 4, we describe how and what context information can be exploited in the course of dynamic service discovery. Context attr ibute is our proposal to embody context awareness in the service discovery framewor k. Chapter 5 presents our global service discovery protocol, which achieves efficient services advertisement and discovery in a wide-area network. A simulation study to comp are it with previous protocols is also included. Chapter 6 presents a prototype im plementation of our thin-client adaptation architecture to deliver a range of lightto heavyweight services to a resource-poor device. Finally, Chapter 7 summarizes the dissertat ion and suggests future research tasks. Context Static Servic Context Static Servic Device p rofile Context attr. Static attr. User query Service Discover y Service Advertisemen t Service Invocation Service directory Client Service provider Service Static/Context attr. Service

PAGE 21

9 CHAPTER 2 RELATED RESEARCH Our work on designing and developing a pr ototype for the context-aware service discovery framework has been influenced by several research projects and emerging technologies. The key technologies that have motivated us to pursue this research are service discovery and subsequent delive ry, server selection, and context-aware computing technology. The server selection prob lem is concerned with selecting service instances of a particular type , for example, selecting the be st Web server among identical replicas. In contrast, the se rvice discovery problem focuse s on locating instances of all possible service types. One of the major goals of our work is to augment the service discovery framework by incorporating se rver selection schemes through context information. Service Discovery There have recently been enormous research efforts from industry and academia for the service discovery problem. SunÂ’s Jini [Sun01b], IETF Service Location Protocol (SLP) [Gut99a], Universal Plug and Play (U PnP) [UPn00], and Salutation [Sal99] are some of the front-runners in this area (most of them are for service discovery in local area networks). There are also other protocols design ed for small, ad hoc networks as well as wide-area networks. Service Discovery Protocols Most service discovery protocols are ba sed on the announce-listen model in which periodic multicast is used for service announcement and discovery [Hel02b]. This soft-

PAGE 22

10 state model is employed for the robustness to fa ilure that is likely to happen in wireless, mobile environments. Starting off from the sa me goal, they diverge to various protocols with different flavors, features, and audience. IETF SLP Service Location Protocol (SLP) [Gut99a, Gut99b] is an effort of the IETF SVRLOC working group to standardize the di scovery and selection of network services on IP networks. The SLP defines Service: URL, which specifies a service type, address, and a set of attribute-value pairs. For example, “ service:printer:lpr://hostname;ppm=12 ” is the Service: URL for a line printer service capab le of 12 ppm and available on hostname . Using the Service: URL s, a user can browse services available at his site and make use of selected services to perform certain tasks. As shown in Figure 2-1, ther e are three agents in SLP: User Agent (UA), Service Agent (SA), and Directory Agent (DA) . A UA is a software entity that sends service discovery requests on behalf of a user application. An SA is an entity that advertises service on behalf of a service. As a cent ralized service inform ation repository, a DA caches advertisements from SAs to respond to requests from UAs later on. An SA advertises itself by register ing with DA(s). This registra tion message contains the URL for the service, lifetime for th e service advertisement, and a set of descriptive attributes. The SA should periodically refr esh the registration with DA(s) before it expires. The advertisement lifetime is to prevent the network from being left in a transient state, which leads to a robust discovery framework. A UA se nds a service request message to a DA to discover the location of a serv ice. Then the DA responds with a service reply message, including the URLs of services matched ag ainst the UA’s query. Finally, the UA accesses instances pointed by the returned Service: URL s. It is worth noting that the DA is

PAGE 23

11 optional. In this case, service request me ssages from UAs are directly sent to SAs listening to the SLP multicast channel. Small ne tworks may be configured to operate in the DA-less mode. Service Agent Directory Agent (DA)Intranet User Agent (UA) Service Agent (SA) Service Agent Application Service Service Service Agent Â…. Figure 2-1. Service loca tion protocol [Per02] The SLP supports string-based service br owsing and query, usi ng service type and descriptive attributes, to help UAs to discover the most a ppropriate ones. In fact, the service query syntax is a subset of the LDAPv3 search filter, which means better interoperability with other IETF Internet protocols. Sun Jini The purpose of Jini arch itecture is to federate groups of devices and software components into a single, dynamic distri buted system. Jini technology provides mechanisms for service construction, l ookup, communication, and us e in a distributed system. The heart of the Jini syst em is a trio of protocols called discovery , join , and lookup [Sun99]. The discovery occurs when a service is l ooking for a loo kup service with

PAGE 24

12 which to register itself. A pair of wellknown multicast channels are used during the discovery process. The join takes place when the servic e has successfully located a lookup service and wishes to join it. The lookup occurs when a client needs to locate and invoke a service described by its interface t ype (written in the Java programming language) and possibly other auxilliary attribut es. Figure 2-2 illustrates each step of the interactions among a client, a service provider, and a lookup se rvice in a Jini community. Figure 2-2. Jini discovery and lookup protocols [Sun99] Jini connection technology c onsists of an infrastructu re (discovery, join, and lookup protocol) and a programming model (l easing, transactions, and events), which address the fundamental issues of how devi ces connect with each other to form an impromptu community. These are built on top of Java objects and Java RMI system. (a) Discovery (b) Join (c) Lookup (d) Service invocation

PAGE 25

13 Lookup service. Jini lookup service can be viewed as a directory service in that services are discovered and resolved through it . In a Jini communit y, services register their proxy objects with a lookup service through discovery and join processes, and clients query the lookup service to find servic es they need. But the Jini lookup service is much more than a simple name server. Clie nts see a service as an interface, including methods that they will invoke to execute the service, along with a ssociated descriptive attributes. The lookup service maps the interface exposed to the clients to a set of service proxy objects. More specifically, performing a lookup by an interface results in service proxy object(s) being downloaded to the clients, which are actually RMI stubs that can communicate back with the servers. This proxy object enables clients to use the service without knowing anything about it beforeha nd. Although the service proxy object is a typical scenario of service invocation, that is, accessing services through RMI method invocation, the downloaded service object can be the service itself or a smart object capable of speaking any priv ate communication protocol. Leasing. Access to services in the Jini system is granted on a lease basis: A service is requested for a certain time period and then granted for a negotiated period between the service user and provider. This lease must be renewed before its expiration. Otherwise the resources associated with the service ar e released. For example, a Jini lookup service grants a lease to a service registration, and th e service should conti nue to renew the lease because a device may leave the community or fail abruptly without having a chance to deregister itself. Against this anomaly, th e leasing keeps the Jini system robust and maintenance-free.

PAGE 26

14 Remote events and transactions. Besides the basic service discovery/join and lookup mechanism, Jini supports remote events and transactions that help programmers write distributed programs in reliable and sc alable fashion. Remote events enable an object to be notified when desired changes occur in the system. These events can be triggered by newly published services or some state changes of services. For example, a Jini palmtop that registered its interest in printers can be notified by its lookup service when a printer becomes available. Moreover, Jini supports the two-phase commit (2PC) protocol, which makes Jini a perfect fram ework to build distributed systems where reliability and robustness are otherwise likel y to get impaired by partial failures and recovery. Microsoft UPnP Universal Plug and Play (UPnP) is an architecture for peer-to-peer network connectivity of intelligent appliances, wireless devices, and PCs of all form factors. In UPnP, there is no central service registry. Services multicast their presence announcements periodically, while control points l earn services of intere st to them either by passively listening to thos e advertisements or by ac tively multicasting discovery request messages searching for devices or se rvices. The advertising message contains a few essential specifics about the service a nd URLs for more detailed information. By following these URLs, a control point can re trieve XML descript ions that provide detailed information for four subsequent steps: description, co ntrol, event, and presentation. The UPnPÂ’s service discovery protocol is called Simple Servi ce Discovery Protocol (SSDP). As shown in Figure 2-3, it uses H TTP over multicast and unicast UDP which are referred to as HTTPMU and HTTPU, respectively.

PAGE 27

15 UPnP vendor UPnP Forum UPnP Device Architecture SOAP HTTPMU (multicast) HTTPU (unicast) HTTP HTTP UDP TCP IP Figure 2-3. UPnP Protocol Stack [UPn00] According to the latest specification, UP nP features can be summarized in the following five steps that make use of the pr otocol stack shown in Figure 2-3. These steps are copied verbatim from UPnP specification [UPn00]. 1. Discovery: The UPnP discovery protocol is based on SSDP. When a device is added to the network, the device advertises its services to the control points on the network by multicasting advertisement (ssd p:alive) message. Similarly, when a control point is added to the network, the UPnP allows that control point to search for devices of interest on the networ k by sending out search (ssdp:discover) multicast message. The fundamental exchange in both cases is a discovery message containing a few, essential sp ecifics about the device or on e of its services, e.g., its type, identifier, and a pointer to more detailed information. 2. Description: After a control point has di scovered a device, the control point still knows very little about the device. For the control point to learn more about the device and its capabilities, or to interact with the devi ce, the control point must retrieve the deviceÂ’s de scription from the URL pr ovided by the device in the discovery message. The UPnP description for a device is expressed in XML and includes a list of any embedded devices or service, as well as URLs for control, eventing, and presentation. 3. Control: After a control point has retrieved a description of the device, the control point can send actions to the deviceÂ’s servic e(s). To do this, the control point sends a suitable control message to the control URL for the service. Control messages are also expressed in XML using the Simple Object Access Protocol (SOAP). Like function calls, in response to the contro l message, the service returns any actionspecific values. GENA GENA SSDP SSDP

PAGE 28

16 4. Eventing: A UPnP description for a service includes a list of actions the service responds to and a list of variables that m odel the state of the service at run time. The service publishes updates when these variables change, and a control point may subscribe to receive this information. The service publishes updates by sending event messages. Event messages contain the names of one or more state variables and the current value of those variables. These messages are also expressed in XML and formatted using th e General Event Notification Architecture (GENA). 5. Presentation: If a device has a URL for presentation, then th e control point can retrieve a page from this URL, load the page into a browser, and depending on the capabilities of the page, allow a user to control the device and/or view device status. The absence of a service registry attest s that UPnP has been designed for small networks. (A control point may cache services available in the network for its own use later on, but it is not a central registry to re spond to service queries from others.) It enables seamless proximity networking in addi tion to control and data transfer among networked devices in the home or office environment. Other service discovery protocols There are more service discovery protocol s worthy of notice, such as Salutation [Sal99], MIT INS (Intentional Naming System ) [Adj99], and Bluetooth SDP (Service Discovery Protocol) [Blu99]. The core of the Salutation architecture is a collection of Salutation Managers distributed over the network, which forms a distributed service registry. A service provider registers itself with its local Saluta tion Manager. When a client asks its local Manager for services, the discovery is perf ormed by the cooperation of the distributed Salutation Managers. The MIT INS implements a late-binding mechanism to resolve an intentional name, that is, a service name, to network location(s). The INS resolvers form an applicationlevel overlay network throughout which a se rvice announcement propagates. Eventually,

PAGE 29

17 all resolvers see the announcement and keep it to route future requests for the name. A client sends its local INS resolver a message consisting of an intentional name and data. Then the message routing is performed by th e INS resolvers according to the service information they keep, hence the late-binding. Designed for Bluetooth environments, Blue tooth SDP is a protocol to discover lower-level services, for instance, Bluetoot h LAN access points within range. It provides a minimal set of service discovery features , and it defines service query and response processes but no service registration process. Comparison of service discovery protocols The UPnP is designed to accommodate home network or small office network environments, whereas SLP and Jini can cover larger size networks, that is, enterprise networks. This limitation comes from UPnP Â’s heavy use of multicast, which can be avoided by the service registry in SLP a nd Jini. The UPnP leverages IP and Web technologies, including TCP/ IP, HTTP, and XML. The absence of a central service registry and adopting Web technologies ma ke UPnP more suitable for peer-to-peer network connectivity of intel ligent appliances, wireless devi ces, and PCs. On the opposite side of the coverage lies SLP, which achie ves much wider coverage by minimizing the use of multicast through servic e registry. Also, SLP is well aligned to other Internet technologies in that SLP serv ices are described by the service: URL and service queries are expressed by an LDAPv3 search filter. Each service discovery protocol has chos en different query language: Java class hierarchy and assistant service attribute objects in Jini, text-based (attribute-value pair based) query in SLP, and XML description in case of UPnP. Although there are pros and cons of their design decisions, for example, th eir query efficiency ve rsus expressiveness,

PAGE 30

18 their service advertisement and query are able to capture only static aspects of context. For example, the server-load service attribute can indicate th e server machine load at the moment of service announcem ent. But it cannot do so at the time of query later on because it is dynamically changing. Table 2-1 co mpares the main features of SLP, Jini, UPnP, and Salutation. Table 2-1. Comparison of major service discovery protocols SLP Jini UPnP Salutation Home Page www.svrloc.org www.sun. com/jini www.upnp.org www.salutation.org Main Entities Directory Agent (DA), Service Agent (SA), and User Agent (UA) Jini Lookup Service (JLS), client, and service Control point and devices (services) Salutation Manager (SLM), Transport Manager (TM), client, and server Service Repository DA JLS No A set of SLMs Service Announcement Service registration Discovery/Join protocol Periodic advertisement Registration with a local SLM Service Discovery Resolved by DA Resolved by JLS Active discovery request or passively listening to advertisements Query to a local SLM is resolved by cooperation among SLMs Access to Service Service type (service protocol and server information) Service proxy object based on RMI SOAP action and state variable query Service session Management Service Description and Scoping Text-based service type and attribute matching Java interface type and attribute matching XML description ISO 8824 ASN.1 description of Service, Functional Unit, and Attributes Service Registration Lifetime Lifetime in service registration message Leasing mechanism CACHE-CONTROL header field in alive message No Service grouping Scope Group No No Event notification No Remote Events GENA Availability checking (periodic & automatic) Note Authentication security feature Java-centric architecture IP/HTTP/XML based Tr ansport independence Ad hoc Service Discovery The extreme of impromptu peer-to-peer connectivity support is found at ad hoc service discovery protocols, such as DEAPspace [Nid01], Service gossip protocol

PAGE 31

19 [Lee03], and MOCA [Bec99], where each m obile device maintains its own service registry. They facilitate ad hoc collaborat ion on the spot without any infrastructure support, thereby making them an ideal c hoice for highly dynamic, small wireless networks. The IBM DEAPspace [Nid01] addresses the se rvice discovery problem in wireless single-hop ad hoc networks. Each device in DEAPspace maintains a view of all the services present in the networ k, and periodically exchanges it s view of the world, that is, the full list of its service database entries with its neighbors. The periodic broadcast is scheduled in a proactive way: When a device finds its own services absent in messages broadcast by its neighbors or a bout to expire, it schedules its broadcast sooner than usual. This way it achieves prompt re sponsiveness to changes in the environments, that is, timely service discovery. Designed for wireless multihop ad hoc ne twork, the Service gossip protocol [Lee03] attempts to reach the convergence of service information propagation. It does this by multicasting delta messages containing differences between se rvices that a node knows and the ones others seem to know. In other words, each node gossips what it knows, more specifically its knowledge a bout the services minus the networkÂ’s knowledge. So the individual nodes compleme nt one anotherÂ’s lim ited knowledge to attain the global view of the whole network. By suppressing repeated gossips of the same information, the incremental advertisement algorithm is able to effectively reduce network traffic for service discovery. The di stributed and cooperat ive mechanism of the Service gossip protocol enables the efficiency and robustness that a discovery system for a highly dynamic ad hoc network requires.

PAGE 32

20 Wide-area Service Discovery The applicability of the aforementioned se rvice discovery protocols is limited to enterprise size networks because of their adoption of the administratively scoped IP multicast [Mey98]. Wide-area se rvice location is a challenging problem. Not much has been done to extend the utility of service discovery into th e global Internet. Even though a few protocols for wide-area service discovery have alr eady been proposed, including the wide-area extension to SLP [Ros97], Berkeley SSDS (Secure Service Discovery Service) [Cze99], and the Centroid [Wei96], none of them provides a clean solution to the problem. The wide-area extension to SLP, called WASRV, attempts to solve the problem by introducing BA (Brokering Agen t) and AA (Advertising Agent) . Wide-area services are advertised by AAs on service-specific global multicast channels. It is a BA that caches these advertisements to resolve requests from its local clients. However, its scalability is questionable since the global multicast channel is not available, and, ev en if available, it would be easily flooded with global advertisement traffic. Berkeley SSDS [Cze99] supports wide-ar ea service discovery through a hierarchy of SDS servers (that is, thei r service registries) and lo ssy aggregation of service descriptions. Service advertisements are aggr egated by the Bloom filter [Blo70], as they propagate up along the hierarchy. Alt hough their aggregatio n method provides good global scalability, the SSDS imposes limitations on service descriptions that are to be aggregated. More specifically, it restricts the number of serv ice attributes to a few to which the aggregation process is applied. The Centroid, an aggregation method us ed for Whois++ index service [Fal96, Wei96], is a collection of every word that app ears at least once in a service description. It

PAGE 33

21 is propagated up along the hierarchical tree of index servers to guide a query toward services. The Centroid at the top layers even tually converges to a large, fixed set of words to achieve the global scalability. Bu t the convergence will not occur until the very top layer of the tree, which means litt le gain from the aggregation method. Server Selection Mechanisms With the explosive growth of the Internet , the server selecti on problem has become a popular research topic to sel ect the best among replicated se rvers. To enable properties required for Internet services, such as scalab ility, load-balance, and fault-tolerance, the servers are usually placed on geographically re plicated locations, especially on strategic points of the network. The server selection pr oblem is to select th e best replica among those, and the selection should be made transparently to clie nts, that is, ideally without involving the users with it. Even though, b ecause of the popularity of the Web, most works in this research area are focused on th e best Web server selection problem, various approaches show a full spectrum, ranging from server-side to network-side and to clientside approaches in terms of the selecti on places. With respect to layers where the selection is made, they can be classified as DNS, network routing layer, and applicationlayer approaches. Server-side Approach The HTTP redirect [Fie97] is a simple load-balancing mechanism. When a Web server is heavily loaded, client requests are redirected to more available Web servers that provide identical contents using HTTP redirect command. Network-side Approach According to the DNS round-robin scheme [Bri95], a FQDN (Fully Qualified Domain Name) is mapped to a set of IP a ddresses, which results in a load-balancing

PAGE 34

22 effect among them. However, a selected IP address does not necessarily mean the most available server since the mapping is performed in round-robin fashion. DNS name to IP address resolution phase is a perfect place to implement server selection logic since it can be hidden from clients and doe s not require any change to client programs. Among DNS geographical proximity proposals are SONAR service [Moo98], DNS LOC resource record [Dav96] , and GL resource record [Cos01]. Cisco DistributedDirector r outers [Cis02] keep track of a set of server replica addresses that provide an identical service. They achieve the geogr aphical locality of service requests by resolving a client request to the IP address of the closest server. The idea of anycasting and its netw ork-layer support was original ly proposed by Partridge et al. [Par93], and it was officially adopted by IPv6 [Hin98]. In Application-layer anycast [B ha97], a resolver keeps track of the status of a set of servers. When a client presents a URL to it, it returns the IP address of the best server, based on the current load and network characteristics to the servers. Although the Application-laye r anycast mechanism enables sophisticated server selection, it is likely fine-tune d to a specific type of serv ice. As a result, it lacks generality to be shared by a variety of applications. To overcome this limitation, the server selection schemes are being generali zed by recent RSerPool (Reliable Server Pooling) IETF drafts [Tue01a][Tue01b]. A client requests a service by sending its corresponding name to a name resolution serv er residing somewhere on the network. The name resolver translates the name to IP addr ess(es) and returns the list of appropriate services registered by that name. Then the clie nt connects to one of the returned services. The name-to-service translation and server status monitoring are performed by the

PAGE 35

23 RSerPool framework for reliable server pooling. It is more concerned with common communication-oriented aspects rather than particular appl ication-specific aspects. Client-side Approach The Smart client [Yos97] provides an in terface to a generic networked service. When a client connects to a network service, an applet to mediate an access to the service is downloaded to the client. Th e applet includes references to mirror sites and connects to the best server based on current load and network latency to replicated servers. Various server proximity metrics have been proposed to select the nearest server [Dyk00]. The proximity of a server and a client can be define d by network hop-count, geographical proximity, round-trip time, band width, or other networ k characteristics. Service Delivery Technologies A wide spectrum of client devices, ra nging from tiny, resource-poor devices to powerful workstations, are usually involved in the ubiquitous computing environments. It naturally follows that a dynamically discove red service should be accessible from across diverse target devices, wh ich is often termed as service mobility . Furthermore, it must be represented in the most appropriate way for th e device that a user happens to use at the moment. Representing services across an array of user devices, which have heterogeneous rendering capability and interf ace modality, is no less important than an effective service discovery mechanism. Bickmore et al. summ arized four classifications of possible approaches to displaying WWW page s on small screen devices [Bic97]: device-specific authoring, multiple-device authoring, client-s ide navigation, and automatic re-authoring. The device-specific authoring approach is to author a set of Web pages for each target device class. The Jini ServiceUI project [Ve n01] can be seen as one example of this

PAGE 36

24 category. In multiple-device authoring, a service GUI is described by some general, intermediate language from which mappings to specific target device classes are defined. “Device Independence Principles” W3C draft [Gim01], “A Device-Independent Representation for Services” [Rom00], a nd UIML [Abr99] belong to this category. According to the client-side navigation a pproach, small screen users zoom and pan around a service GUI that does not fit into their displays. Our Jini system, a Jini proxy system presented in Chapter 6, also suppor ts panning of a smartphone display over service GUIs. But our approach is different from others in that client devices are shielded from service implementation details as well as rendering details, as services are executed on the network-side proxy and provided to th e client devices via VNC [ATT02]. Finally, the automatic re-authoring approach tries to re-author the document pages for a given target device through a series of transformations. Jini ServiceUI project A Jini client downloads the front-end of a service implementation that includes the service proxy and GUI. In the Jini ServiceU I project [Ven01], more than one GUI object is attached to a service in the form of servi ce attributes, so that th e most appropriate one can be selected, according to the rendering ca pability of client devices. For example, a Swing GUI implementation would be select ed for a desktop user and a Java AWT implementation for a PDA user. XML-based approach Roman et al. [Rom00] propose a way to repr esent a service in a device-independent way using XML. In their approach, a serv ice is described by an XML document in a device-independent way, while the device-speci fic presentation style is specified in an XSL file. This XSL file is associated w ith a class of client devices to map GUI

PAGE 37

25 components to specific graphical component s on the devices. By combining service descriptions in XML and device-capability in an XSL file, UI objects, for example, HTML pages, are generated to achieve th e device-independent service representation. The same approach has been taken by W3C for device-independent Web access and single authoring [Gim01]. Similar to this, UI ML [Abr99] is an app liance-independent UI language, which uses style sheets to map user interfaces described in XML to appliancespecific markup languages. Template-based approach Icrafter [Pon01] proposes an infrastructu re to enable serv ice UI selection, generation, and/or adaptation, based on service and device cap ability. It uses abstract, declarative markup languages, such as HTML, VoiceXML, MoDAL, and SUIML for GUI representation. When a service descripti on is discovered, the most suitable service template is selected from potential candida tes out of a template database. From this template, a UI object is crea ted based on the service description and devices information.

PAGE 38

26 CHAPTER 3 MOBILE SERVICE DISCOVERY FRAMEWORK In the era of ubiquitous computing, com puting devices are everywhere. They are interconnected through a ubiquitous computing in frastructure to help users perform their everyday tasks. Interactions be tween them are modeled as services. Each of those devices provides services to others so that more value-added services can be composed from primitive ones. In short, our vision is that ubiquitous computing will flourish by enabling the scalable and manageable explosion of se rvices, and therefore the effective service discovery framework is the fi rst step toward this vision. Overall Architecture One of the most important criteria to be met by the effective service discovery framework is intelligence to provide the mo st appropriate service to mobile users by exploiting any meaningful contextual inform ation. User mobility commands support for wide-area service discovery as well as local service discovery, whic h sets our horizontal coverage to be the Internet. With respect to the layers our proposed architecture relates to, its focus is placed on lower layers, for exampl e, nonapplication-specific context, such as user location, server load, device capabil ity, and network condition. In contrast, Web service discovery is more concerned with hi gh-level, application-related aspects, for example, finding a supplier offering the best price. Table 3-1 shows three categories of servic es according to their intended coverage: proximity service, domain service, and global service . The proximity services mean services found through the closes t service registry, while th e domain services are ones

PAGE 39

27 discovered within an admini strative domain boundary. The gl obal services include any other services from the Internet. Notice that the relevant context fo r service discovery and selection varies across the th ree classes. In the case of proximity services, physical location or distance will likely be of a pr imary concern to client s, while communication or computation-oriented context is usually key to effective glob al service discovery. Table 3-1. Service classification by coverage Service class Coverage Primary selection criteria Example Proximity service Local area Proximity Nearby printer Domain service Domain Proximity and service features Area guide service Global service Global area Service quality, user memory, or availability Media service Storage service As users search for services, their quer ies would end up with many more services than they can manage or need except for the proximity service case. This is because in the future ubiquitous computing world wh ere services are to be discovered from anywhere, there would be an abundance of ma tched service instances beyond local areas. We argue that this deluge of services must be dealt with by the infrastructure since user devicesÂ’ limited resources will be easily overwhelmed by those services. The users first connect to a nearby proximity service registry to make their service discovery requests. As described in detail later, an impo rtant component of the registry is BA (Brokering Agent) that functions as a broker to match and recommend appropriate services among a possibly large set of service instances. We not e that the proximity service registry is the base-level component of our discovery system, which is a contact point for the users. Domain service registries are organized in a hierarchical fashion for beyond-the-

PAGE 40

28 proximity service discovery. One node of the domain hierarchy (typical ly the root node) is designated as the GSR (Global Service Registry) node that comprises a global hierarchical tree. It is an entry point to the global hierarchy through which some proximity/domain services are exported to the globe and global services may be imported for local clients. In other words, it is a ga teway to a wide-area se rvice discovery network. Figure 3-1. Conceptual model of cont ext-aware service discovery system Figure 3-1 shows the overall view of our context-aware, integrated service discovery architecture. Proximity services are cl osest to a user in the figure, indicating, if there exist services that satisfy the userÂ’s query, that they are the most likely candidate services, unless explicitly specified otherwise. Domain services would be the next choice, in case the query is not satisfied by services from the proximity. And finally the global service discovery tree is explored. The design decision of the three-tier architecture has Service Profile Device Description Other Contex t Information Global Services Domain Services Proximity Services Profile Serve r at home BA GSR Services Contexts

PAGE 41

29 been made from our understanding that the prim ary, relevant context in the three classes is largely determined by the coverage. Howeve r, the three discrete classes are hidden from the user, since he interacts with our service discovery framework via the BA. Factors concerning the discove ry include various contexts , such as location, network condition, server computing load, user device profile, user servi ce profile, and userspecified query. It is also shown that some of the proximity and domain services may be promoted to global services through a GSR node. Our architecture is refined by adding c ontext-awareness support to the multitier service discovery framework. Context-awar eness is enabled via context attribute evaluation by the BA. The context attribute is a special kind of service attribute, as described in Chapter 4. It provides a flexible , general way to expl oit relevant context information, including spatial and temporal context of all partie s involved, such as clients, servers, and network condition. In s hort, the framework makes use of various but relevant contextual information during th e discovery process for qualified discovery results. Three-tier Service Discovery Architecture Suppose that a mobile user visiting a new place needs a service on that local network. First, the user will attempt to discov er it using a small-area service discovery protocol such as Bluetooth SDP, since servi ces found nearby are likely to be superior to distant ones in most cases. If not found, the us er has to search bigger areas and may end up with a global discovery network as a fina l resort. Currently, little well-established infrastructure support exists for this expandi ng discovery scenario. That is, the user is being left directly exposed to more than one service discovery prot ocol. He must deal with multiple discovery protocols, which is not usually possible on small mobile devices.

PAGE 42

30 Recognizing this problem, we have devel oped a system architect ure that provides a unified view of the multiple service discoveries. Our service discovery subsystems for each coverage class are described below. Proximity-based Service Discovery A constituent element of our discovery system is the proximity-based service discovery framework that typically consists of a service registry, services, and clients. They are within the reach of one another, and service discovery act ivities are centered on the service registry. Based on general service-repository-based discovery architecture, our model introduces a brokering entity called a BA, which is added to the service registry. It can be either a component of the registry or a sepa rate but co-located entity. The BA handles inter-registry communication and context attrib ute evaluation. The former is for domain and global service discovery, as further explai ned in the following s ections, and the latter is to filter disqualified servi ces considering relevant context. Since the BA takes care of all of these, the clie nt does not need to know what is happening behind the scene, while benefiting from seamless discove ry and context-awareness. Finally, we note that the proximity service registry becomes a node of the hierarchy of domain service registries. Domain Service Discovery Although a proximal community is often self-s ufficing so the need for services may be satisfied by the community itself, that is, a group of service provide rs in close vicinity, it is not always the case; nonlocal services ma y be either necessary or more desirable in some cases. As an example, assume that serv ices in a room area ar e registered with the roomÂ’s service registry. A printe r in the next room might be the choice of a visitor in case

PAGE 43

31 there is no printer service in the current room. This example clearly illustrates the need of intercommunication of service registries. The coverage limitation of the proximity-b ased service discovery can be overcome by forming a hierarchy of serv ice registries, which is typi cally based on location context [Jos99]. An administrative authority is usuall y in charge of setting up the hierarchy of service registries within its jurisdiction. More specifically, each site maintains a service registry serving the area, and the registry b ecomes a child of the parent registry whose jurisdiction subsumes the child Â’s. A portion of local services may propagate up along the tree, thereby being advertised beyond thei r home registryÂ’s coverage to a larger organizational domain or area. All the servi ces need to do for the upward propagation is to register themselves with their service re gistry node and to declare themselves as a domain service. On a discovery request from c lients, a local proximity service registry is first searched. Its parent registry is then tr ied, which is repeated until the search request reaches the root registry for the administra tion domain. By this search scheme, some contextual information related to the client and desired services may lose accuracy to a certain extent as it travels up beyond their origin sites. But this incremental search scheme ensures that discovered services will be the best among services available in the client situations, if they ar e not absolutely ideal ones. Figure 3-2 illustrates a sample hierarchy of on-campus service registries. Suppose that each (sub-)domain has an area guide servi ce for visitors. When a visitor on the fourth floor of the CSE building makes a discovery re quest for a guide service, it is implied from his location context that he seeks a fl oor map service for the fourth floor, unless stated otherwise. If available, it would be able to provide the be st guidance service. A

PAGE 44

32 CSE building guide service found in the parent node may otherwise be somewhat helpful. The last resort would be th e campus node. A service discovered there may not provide any map for the fourth floor, but some ot her useful information regarding the CSE building and its neighborhood may be provide d. This way the accuracy of context information is gradually lost as it gets away from the origin in which the request was made. These kinds of services are termed domain services in that they are intended to be visible within a certain domain. Service adve rtisement and query routing for them should be properly handled by the tree itself to provide the view of domain coverage. Figure 3-2. An example of a domain registry tree Advertisement of domain services Once a service provider indicates that it is intended to be used by clients within a domain, the service advertisement is propagate d up the domain registry tree. It continues up to the root, unless it is prohi bited by the evaluation of the context attribute , as described in Chapter 4. The service may be published to the world at the root node, if 4th floor E 467 CSE bldg. 3rd floor Campus MSL bldg. Â… Â… Â… E 451

PAGE 45

33 allowed, as explained in the “Promotion to gl obal services” section. Suppose that a guide service is being registered with the fourth floor service registry in Figure 3-2, and it is marked as a domain service. (It could be a globa l service. In this case, it is handled in the same way as domain service propagation.) The advertisement will be forwarded to the campus registry via the CSE Bld registry. Every registry on the path from the fourth floor to the campus registry caches it for the purpose of resolving queries from local clients or its sub-tree later on. One may raise a con cern that upper nodes will be flooded with services from lower nodes. But it would not be so severe since only a portion of services is to be designated as domain or global serv ices. More importantly, we expect the domain size to be kept to a proper extent. A huge dom ain will be divided into several manageable subdomains to be beneficial from the incremental domain search scenario. Domain query routing Service query routing is stra ightforward since a query will run into services on its way upwards that have been cached as a result of prior domain (and global) service advertisements. A service registry forwards to its parent the queries that are not resolved by itself. Services discovered from upper node s are copied to the cl ient registry which will finally return them to the clients. Th e cached services can then be shared among other local clients. Also, it makes the client s see a uniform interface regardless of whether the services come from a proximity, domain, or global discovery network. Promotion to global services Both domain and global service advertisements propagate toward the root node of the domain registry hierarchy, starting off a ba se proximity registry. It is further exported to a global discovery network from the root, if it is marked to be a global service. This promotion is handled by a GSR entity residing at the root node. To the domain, it is

PAGE 46

34 viewed as a proxy that publishes services to a global area on its behalf. Yet another important reason to distinguish domain and glob al services in our ar chitecture is service mobility. Since service itself could also be mobile, service mobility across service registries will cause frequent service advertisement updates. Our domain hierarchy (and GSR entity together) contains the frequent updates by intradomain movements within the domain, which generates no update traffic in a global service discovery network. The GSR entity also translates service descrip tions between the two hierarchies if they employed different languages for service description. Global Service Discovery Previous efforts for wide-area service disc overy can be classified into two groups. The first approach is to extend the general se rvice discovery protocol to build a certain form of a global discovery network. Berk eley Secure SDS [Cze99] and SLP WASRV [Ros97] fall into the first group. We have developed a new global service discovery protocol, the Class-based Servi ce Propagation (CSP) protocol, that belongs to this group. One basic assumption is that there would be a morass of services everywhere in the future ubiquitous computing world, and gene ral queries looking for anonymous services with certain functionalities would predominate over specif ic queries (for example, a general query specified in popul ar terms versus a specific que ry with unique service id). Accordingly, the emphasis is placed on the aggregation ratio of service information, which ensures the improvement of overall syst em performance. A detailed description of the CSP protocol is given in Chapter 5. Th e second group builds on the existing directory systems, whether centralized or distri buted, which includes UDDI [UDD02] for Web services, an LDAP-based system such as Jipang [Suz01], and USDP [Bis01]. Although their architecture can rely on th e strength of the existing directory systems, for example,

PAGE 47

35 LDAP [Hod02b], service replica tion and update protocol among directories are yet to be defined and evaluated. Figure 3-3 illustrates how the components de scribed thus far are threaded together to provide a single, unified view of the disi ntegrated service discovery hierarchies. We note that a domain hierarchy comprises base proximity service registries, while the global hierarchy is made up of root nodes of domain trees. Global se rvices are advertised into the global discovery network by GSR-capable domain roots. The GSR-capable root means a root node augmented with a GSR entity to import and export global services on behalf of the domain. Although a GSR entity is typically hosted by the domain root, multiple GSR entities can be deployed at st rategic points of the hierarchy where the demand for global services is high, es pecially for big domain networks. Figure 3-3. Integration of domain a nd global service discovery framework UA BA user GSR Â… Domain hierarchy GSR-capable registry BA-capable registry Â… GSR BA BA BA service

PAGE 48

36 Every service registry is basically BA-capab le, meaning that it is capable of sensing and processing relevant contex t to refine service discove ry results. The figure also indicates that a user interact s with the closest service registry through a UA, and services may propagate up the domain hierarchy or even up along the global hierarchy. Context Awareness Support As previously discussed, context capturi ng and processing should be handled by a service discovery infrastructure without invol ving mobile devices and users. A context attribute, which is a viable solution to the context-awareness problem, is a special kind of attribute that is part of service announ cement messages. It is also called a dynamic attribute in that its actual value is dynam ically determined at the time of evaluation, compared to a static attribute that has a fi xed value, as in curre nt service discovery protocols. Containing logic to capture context information specific to a particular service type, the context attribute can be used for th e purpose of service advertisement as well as service discovery. Context-aware Service Advertisement Context attributes can be used to indicat e service providersÂ’ intentions as to the boundary to which their services are to be adve rtised. This type of context attributes is evaluated at the time of service registration. On registration requests from a service, our domain service registry passes the service advertisement on to the parent registry, if it has an attached advertisement context attribut e. Depending on the evaluation result by the parent, the service may be further propagated or dropped at that point. In other words, the context attributes prescribe prec onditions that must be met to further propagate. This way service providers can control the reach of their service advertisements so that their resources can be dedicated to the target ed clients by avoiding being disturbed by

PAGE 49

37 unintended customers. Otherwise, clients canno t find that the services are not for them until they are somehow rejected by service access control logic. Context-aware Service Discovery In a domain or especially in a global serv ice discovery subsystem, it is likely for a site to be inundated with a la rge number of service instance s of the same type from the globe. Although they can first be screened by user-specified static attribute matching, a user query will end up with still many unmanag eable candidate instances. Therefore, it is imperative that a service discovery framework be able to support an intelligent brokering mechanism for further winnow. The need is amp lified in the case of resource-constrained mobile devices since it is too painful for su ch devices to go through all candidate services to find usable ones. Figure 3-4. Evaluation of context attributes Serve r network Server Servers Clien t network Mobile clients GSR GSR stat i c attrs contex t attrs Contex t evaluation GSR entries UA BA Global service discovery network GSR Serve r network

PAGE 50

38 Figure 3-4 shows how the context attributes are used in connection with a global service discovery scenario. At a server site, a GSR entity responsible for global service import and export publishes services to a wide-area discovery network. The advertisement messages include text-based se rvice descriptions, su ch as service type, server address, and static attr ibutes. On the other end, they are retrieved by the client-side GSR. Upon service requests fr om clients through their UA, the associated BA searches the global discovery network for services sa tisfying a static-attri bute-based query made by the clients. This search is performe d through the GSR. Using candidate service information by the static attribute matching, the BA downloads associated objects, such as service proxy and context attribute objects, from source GSRs. Then the candidates are ranked and further screened through the evaluati on of associated context attributes. Since this two-step discovery by st atic attributes and then c ontext attributes introduces nonnegligent cost, the downloaded objects (and evaluation result ) are cached in GSRs for future requests from other clients at the site . We note that context attributes for domain services are processed in much the same way. Device Capability Context Information A full array of devices, including powerful workstations, PCs, PDAs, smartphones, and wearable computers, usually lives in the mobile computing environments. It enriches services available to mobile users but, at th e same time, their disparate capability brings a new challenge to light: Mobile users should be able to use any type of devices that they happen to carry at the moment. Client device capability is yet another invaluable context information to be considered in the process of mobile service discovery. The device capability is presented to the client BA through his UA along with service queries. The device capability

PAGE 51

39 description may include device classes, com puting and communication resources, and I/O devices. Then the BA attempts to match the cap ability as well as the query itself. As a result, mobile users may see a different set of service instances even with the same service query, as they switch to a different device. The importance and effectiveness of device capability, as context information for successful service discovery and delivery, are attested by our prototype of a thin-clientbased service delivery system presented in Chapter 6. User Mobility Support Mobile clients use their desktop computer s at work, car navigation systems while driving, and smartphones while walking. They will expect virtually the same set of their favorite services, regardless of wherever they are with whatever devices. But they must not be bothered to specify all the detailed qu ery terms to make a di scovery of services that they once used. Our user service profile enables this service mobility. It consists of a set of frequently used services (that is, an active service set) and associated rules to reevaluate the list in a forei gn network. The usersÂ’ UA re-e valuates the service list downloaded from their home profile service by the help of the associated BA to ensure that they are presented with th e best service instances available in the new environments.

PAGE 52

40 CHAPTER 4 CONTEXT-AWARE SERVICE DISCOVERY Although existing servic e discovery protocols have adopted different service description models, their service advertisements and queries are largely limited to capture only static aspects of co ntext. For example, a server load attribute can indicate the server machine load at the moment of service announc ement but not at the time of service query later on because it is dynami cally changing. Service matching, based on the declarative, static service descriptions, provides minimal service discove ry and filtering, leaving the rest of the work to usersÂ’ manual selec tion. Users have to blindly try discovered candidate instances one-by-one until they find an instance wi th satisfactory quality of service. It would be a painful process if their mobile devices do not have enough computing and network resources needed fo r the manual selection. The problem gets even worse when a global service discovery ne twork is searched. It is quite possible for them to be stormed by an unmanageably large number of service instances returned as a result of their queries, most of which turn out to be useless. Existing service discovery frameworks do not sufficiently exploit context information for dynamic service discovery. Some information, such as service quality involving several factors, is inappropriate or impossible to be handled by the static, declarative service descriptions. For example, it is difficult for the static descriptions to express how far away service providers and clients are. How can the discovery framework tell if a particular service instance is better than any others in a particular location at the moment?

PAGE 53

41 We introduce the concept of context attribute to incor porate the context-awareness into a general service discovery framework. It allows us to benefit from implicitly captured context information wh ich is currently underutilized. Context Attribute and Scenario Context Attribute The context attribute is a special kind of attrib ute that is part of service announcements. It is also called a dynamic attribute in that its actual value is dynamically determined at the time of lookups, compared to a static attribute that keeps a fixed value set at the time of announcements. Figure 4-1 shows the context attribute for a Jini-based context-aware service discovery system. Figure 4-1. Service record and context attribute Services are first matched against a user query, based on the static attributes, which produces a candidate service set. Then th rough the context attribute evaluation, the candidates are refined to a smalle r set of qualified services to be returned to clients. In other words, services are ranked according to the evaluation results to ensure that the clients are given the best service instance(s). The context attribute draws from client-side server selection mechanisms, for example, Sm art client [Yos97], but it is generalized for service discovery in our architecture. The context attribute embodi es service-specific selection logic hidden from clients. Also, it may prescribe conditions that should be met to further propagate throughout the service discovery network. Some examples of the context attribute are as follows: service proxy object static static contex t attribute attribute attribute Â…

PAGE 54

42 Distance to server: The context attribute could describe different metrics depending on specific service implementati ons, for example, geographical distance to the servers, distance in logical, orga nizational view, or network distance. The network distance may be measured in terms of hop-count, round-trip time, bandwidth, and so forth. Server load: Server load could be advertised as a static load attribute. But it requires too frequent updates to keep up with the load changes on the server machine, which may be problematic in a wide-area discovery network. Service channel: The context attribute may examine service channel conditions to recommend better service instan ces with respect to QoS. Service advertisement constraint: Some services may set a certain range within our domain hierarchy for their advertisem ents to be propagated. For example, a service wants to serve foo.com domain and to remain unknown beyond that to avoid being bothered by unintended clients. It should be noted that client s are unaware of the existen ce of context attributes so they are not at all i nvolved in the context evaluation. Service author s provide appropriate context attributes for their se rvices, and our context-aware se rvice registryÂ’s BA simply evaluates them without any knowledge of their internals. (Context attribute is required to implement a predefined Java in terface, as explained later.) The rationale behind this is that the service authors know what selection criteria matter the most to their services. Also, the BA can be relieved of the burden to know the selection crit eria of all types of services. The usefulness of the context attributes is highlight ed especially for domain and global service discovery, since gain by the choi ce of the right servi ce is magnified due to the diversity of service implementations, de vices, and networks and network uncertainty. The context-attribute evaluation is usually a c ooperative effort of the servers and clients, which may cause communication in between them during the evaluation process. Benefits from exploiting context information for service discovery through the context attribute, which is a key feature of our context-awar e, enhanced service discovery architecture, are summarized as follows:

PAGE 55

43 The context attribute provides a general, flexible means to enable sophisticated service selection. Service au thors are allowed full flexib ility to express selection criteria specific to their own services. The context attribute is an effective indicat or of service quality that is able to capture various kinds of service qual ities, including communi cation-related and application-related aspects. The evaluation cost of context attributes is amortized over multiple clients. To justify the non-negligible overhead of la te evaluation, the evaluation result is cached so that it can be reused for futu re requests for the same service made by other clients. The context attribute is transparent to clients. Its existence and evaluation happening behind the scenes are comple tely hidden from the clients. Context-aware Service Discovery Scenario In this section, we present one service discovery scenar io on a new studentÂ’s first day on the University of Florida (UF) campus to illustrate the merit of context attributes over static attributes. Table 41 summarizes five example services used in the scenario. Table 4-1. Static attributes versus context attributes Service Static attribute Context attribute Guide Manual selection Closeness detection based on domain name Movie preview Manual selection Network bandwidth and delay detection Movie theater Random selection Physical distance understanding Printer Constant load information pushing Load information pulling when necessary Bus schedule Flag attribute Advertisement controlled by time of day Guide service A new student arrives on the UF campus to start his studies. At the entrance of a residence hall, he picks up his PDA to discove r area guide services. Assume that there are

PAGE 56

44 three guide services register ed with a service registry: dorm guide , campus guide , and Gainesville city guide . Context attribute . A domain context attribute attached to the guide services determines the closeness between the service registry and service instances based on the DNS domain name. Since the se rvice registry is in the dorm.ufl.edu domain, the dorm guide is given the highest score as a result of the evaluation. The student gets back a service instance list sorted in the order of dorm guide , campus guide , and city guide service. Static attribute . The user has to browse the li st to figure out which service instance he needs, relying on descriptive static attributes. Unfortunately, it may take too long to find that it does not provi de detailed information about the residence hall, if he first chooses the campus guide service. Movie preview service. He finished his check-in process. Now he wants a movie for the rest of the day. He needs to check movie previews from moviead sites, using a MPEG player program. They are likely out-of-state sites (that is , remote services) maintained by nationwide movie distributors. Context attribute . The best site in terms of ne twork bandwidth and delay can be determined by ping context attributes, which check th e network condition to advertised sites. Static attribute . He will pick up one at random. If he selects a service with intolerable QoS, he will have a long delay and the jitters.

PAGE 57

45 Movie theater service At last, he made up his mind as to what movie to watch. Now he needs to search for local theaters that advertise th emselves to the service registry. Context attribute . The nearest one is recommended by a location context attribute based on ZIP codes. Assume that the registry is preconfigured with its own ZIP code, or the context attribute can someho w acquire it. Then the service registry, more specifically the location context attribute, will be able to figure out approximate distances to the theaters from its own ZIP code and the theatersÂ’ ZIP codes. Static attribute . He has to make a random selection of ZIP codes (that is, part of service descriptions displaye d on his PDA). But he does not know what his ZIP code is since it is his first day on campus. Printer service The student wants to print out the directi on to the theater usi ng a nearby printer. Note that some printers are being heavily used by housing st affs to process student checkins. According to the movie schedule from th e theater service, he knows that he does not have much time for the movie. He needs to rush. Context attribute . A load context attribute is used to figure out which printer is least loaded. The load attribute connects b ack to its service for current queue length, which returns up-to-date load information in resp onse. Then the service registry is able to present to the user the list of printer services sorted in the ascending order of queue lengths. Static attribute . A declarative, static load attrib ute is associated with a printer service. The attribute should be updated immedi ately as soon as the printer load changes although nobody requests the service. This resu lts in the waste of valuable network

PAGE 58

46 resource and processing power. Also, the user has to make a manual selection based on the advertised load information. Bus schedule service The student decides to take a bus. The acces s point device at a bus stop in front of his residence hall hosts a service regist ry. Each bus running through the bus stop advertises itself to the registry. Context attribute . The registered bus services are either shown or hidden, depending on the evaluation results of their in-service context attributes. In other words, buses will not be returned to the user accordi ng to the context attribute evaluation results if they already stopped running for the day. Static attribute . Each bus service may have an in-service flag attribute to indicate whether or not the bus is stil l in service for the day, and th e attribute is to be changed every night and every morning. Context-Aware Service Discovery Implementation Jini is chosen as a base system to build and demonstrate our context-aware service discovery system, more specifically SunÂ’ s Jini reference implementation, named reggie , version 1.2. As with other service discovery protocols, it does not do much for contextawareness support. As to where to put the in telligence to capture context information, we made a decision that context-awareness should be supported by the infr astructure (that is, the BAs associated with service registries), since it is often the case in which resourceconstrained mobile devices cannot afford it. A basic assumption of our approach, therefore, is that a client in teracts with the closest service registry so that the context captured by the registry can appr oximate that of the client.

PAGE 59

47 All changes we made are kept within the Jini lookup serv ice, and the standard Jini APIs are not affected. Our modifications are th erefore transparent to ordinary clients, and our augmented service registry can support services with either ordinary static services or with static and context attributes. Services with context attributes are given special treatments by our enhanced se rvice registry, but the client s are kept unaware of them. Definition of Context Attribute Extending the Jini naming space net.jini.lookup.entry , we added several Java classes to define the cont ext attribute, including LDContextEvaluator , RDContextEvaluator , AbstractLDContextEntry , AbstractRDContextEntry , and ContextEvaluation . Parts of these class definitions ar e shown in Figures 4-2, 4-3, and 4-4. package net.jini.lookup.entry; public interface LDContextEvaluator { ContextEvaluation evaluate(); } public interface RDContextEvaluator extends java.rmi.Remote { ContextEvaluation evaluate() throws java.rmi.RemoteException; } Figure 4-2. Java interface definitions of local and remote context attribute package net.jini.lookup.entry; import java.io.Serializable; public class ContextEvaluation implements Serializable { long validUntil; // duration + current time. long duration; // period during which this evaluation remains valid. long contextIndex; // indicates service quality. .... } Figure 4-3. Java class definition of context evaluation result

PAGE 60

48 A context attribute is either a local or remote object. The local context attribute and remote context attribute implement the LDContextEvaluator and RDContextEvaluator interface, respectively. If the ev aluation can be performed by a Jini lookup service alone, it is a local context attribute. For example, if a context attribute measures network hopcount toward its service instance, it is a local object evaluated solely by the lookup service. The evaluation process does not invol ve the corresponding se rvice instance. As an example of a remote object, we can think of a context attribute that probes the current load on the server machine. This context at tribute will be a stub object that makes an RMI call back to its service instance. All context attributes are re quired to implement either of the two interfaces, so our lookup service can evaluate them by simply invoking their evaluate() methods without understanding their internals. The evaluate() method returns a ContextEvaluation instance that contains duration , validUntil and contextIndex . The duration field indicates a time period during which the evaluation re sult is likely to remain unchanged. This allows the evaluation result to be cached in our lookup service for future requests from local clients at the site. The validUntil field is an absolute time when the cached result expires. The third field, contextIndex, represents a comparative quality index of services in question in a numeric form, for example, a normalized index out of 100. It is important to know that this normalization is defined on a service type-by-type ba sis, as each Jini service interface is autonomously defined by a community of all pa rties involved in the service type. This ensures that relative s uperiority can be indicated by a normalized number among service instances of the same t ype. Service selection criteria specific to a service type will be defined as part of th e service standardization, and the index value

PAGE 61

49 will be valid across the instances of the service type. Therefore, the definition of contextIndex frees our lookup services (more speci fically BA) from having to understand the normalization semantics of every service type for comparison. We believe that this approach is well aligned to the Jini design philosophy to foster the autonomy for individual service implementations. package net.jini.lookup.entry; import java.rmi.Remote; import java.rmi.RemoteException; import java.rmi.server.RemoteObject; import java.rmi.server.UnicastRemoteObject; import java.rmi.NoSuchObjectException; import net.jini.core.entry.Entry; import net.jini.entry.AbstractEntry; public abstract class AbstractLDCont extEntry extends AbstractEntry implements LDContextEvaluator { public ContextEvaluation val; ... } public abstract class Abstra ctRDContextEntry extends AbstractEntry implements RDContextEvaluator { public Object rObj; public ContextEvaluation val; ... public AbstractRDContextE ntry() throws RemoteException { super(); UnicastRem oteObject.exportObject(this); setStub(); } private void setStub() { try { rObj = RemoteObject.toSt ub((Remote)this); } catch (NoSuchObjectException e) { System.err.println("Â… error : " + e); } } } Figure 4-4. Base class definitions for local and remote context attribute

PAGE 62

50 Figure 4-4 shows the base clas ses for the local and remote context attributes. They extend the net.jini.entry.AbstractEntry class that is a base Entry type for Jini service attributes. By subclassing it, se rvice authors are relieved of the internal details of context attributes. Both contain a ContextEvaluation type val , which caches their previous context evaluation results. Although not shown in the figure, the constructor of the AbstractRDContextEntry class exports itself to the RMI runtime system so that a lookup service can make a connection back to it fo r context evaluation. Finally, Figure 4-5 shows a sample remote context attribute, the ServerLoad attribute. import java.rmi.RemoteException; import net.jini.lookup .entry.AbsractRD ContextEntry; import net.jini.lookup.entry.ContextEvaluation; public class ServerLoad ext ends AbstractRDContextEntry { public ServerLoad() throws RemoteException {} private long getSystemLoad() { // get current load and return it } public ContextEvaluat ion evaluate() throws RemoteException { long sysLoad = getSystemLoad(); return new ContextEvaluati on(1*60*1000, MAX_LOAD – sysLoad); } } Figure 4-5. A sample ServerLoad context attribute Context Attribute Processing The context-awareness added to the original Jini lookup se rvices is transparent to clients, since context attributes, provided by the service authors, are evaluated by our lookup service (and service providers in case of remote attributes). Therefore, the clients make a discovery request, using standard Ji ni interface and static attributes without

PAGE 63

51 worrying about whether they are seeing origin al lookup services or our enhanced lookup services. In other words, origin al Jini APIs are kept untouched. As shown in Figure 4-6, our lookup service considers CANSETSIZE times the number of service instances a client requests. The slookup() , the original reggie Â’s lookup method, is first performed based on the sta tic query. Then the method goes through each service instance to see if any context attribut e attached to it needs to be re-evaluated. Again, the previous evaluation result is cached in the val field of the attribute. A thread is assigned to each context attribute so that th e evaluations can be pe rformed in parallel. Since each attribute may take different eval uation times, we need to set a timer. When this timer expires, any ongoing evaluation is ab orted. After that, it sorts the candidate set in the descending order of the contextIndex value. Service instances with context attributes are favored over those without them . It is possible that some instances do not have any context attribute attached to them, even if they are all the same service type. Before returning top maxMatches instances to its client, c ontext attributes are removed from their Entry list to make the context awarene ss processing invisible to the client. ServiceMatches lookup(ServiceTemplate tmpl, int maxMatches) { int candidateSetSize = maxMatches * CANDSETSIZE; candidates = slookup(tmpl, candidateSetSize); for (each instance in candidates.items) { if (it has an instance of AbstractLD ContextEntry or Abst ractRDContextEntry) { if (previous evaluation expired) evaluate the context attribute; } } sort the candidate set according to contextIndex remove context attributes from each service; return top maxMatches instances; } Figure 4-6. Context attribute processing

PAGE 64

52 Implementation of Domain Serv ice Discovery Subsystem Prototype We have also developed a prototype of the domain service discovery subsystem by building a hierarchy of Jini lookup services. The context processing logic for service discovery shown in Figure 4-6 ha s to be revised to enable discovery across registries. Also, inter-registry advertisement and lease management must be supported. Domain service discovery If not enough candidate services are discove red in a local lookup service (the size of candidates is less than candidateSetSize in Figure 4-6), the lookup service continues to search its parent registry which, in turn, passes the query to the grandparent. (This upward recursive search goes on until necessary candidates are discovered.) In general, the incrementally expanding search scheme en ables the discovery subsystem to consider closer candidate services first that are more likely to share the same context with the original lookup service. Thos e services imported from ancestor nodes are stored in the local lookup service, and are processed and ranked by the same context evaluation logic for local services. They are cached in th e lookup service until their lease granted by source lookup services expires. Domain service advertisement Services should be able to propagate to parent lookup services along the hierarchy. Similar to the LDContextEvaluator and RDContextEvaluator , we introduced the LAContextEvaluator and RAContextEvaluator interface to evaluate the service advertisement context. Two corresp onding abstract base classes, AbstractLAContextEntry and AbstractRAContextEntry , were added as well. The adve rtisement context attributes are to be evaluated at the time of registrati on. After a service registers with itself, our

PAGE 65

53 service registry passes the service on to its parent registry, if it has an attached advertisement context attribute. Depending on the context attribute evaluation result by the parent, the service may be allowed to furt her propagate or get dr opped at that point. In other words, the context attr ibutes prescribe the preconditi ons that should be met to further propagate the services. This way serv ice providers can contro l the reach of their service advertisements so that their resources can be dedicated to their targeted clients by avoiding being disturbed by uni ntended customers. Otherwis e, clients will not find out that discovered services are not intended fo r them until they are later rejected by the access control logic of the services. When a service is propagated upwards, the ch ain of pointers should also be kept for the purpose of service lease management and service updates. A node has a responsibility to timely renew the lease of the services propagated to the parent. The node is the lease holder of the services from the parentÂ’s pers pective. The pointer chain formed for lease renewal and cancellation along the hierarchy is also used for service attribute modification. Implementation details Figure 4-7 depicts the architectural diagram of the reggie version 1.2. The figure also shows how a client and a lookup servic e interact with each other. The arrows indicate RMI communication. The client com ponents are dynamically downloaded to the client when a client program discovers and a ssociates itself with th e lookup service. The client sees the lookup service only vi a Jini standard interfaces, such as net.jini.core.lookup.ServiceRegistrar, net.jini.core.lookup.ServiceRegistration, net.jini.core.lease.Lease, and so on. As shown in the figure, these are implemented by client-side proxy classes ( RegistrarProxy , Registration , and ServiceLease class) that

PAGE 66

54 transform Jini API parameters ( ServiceItem, ServiceTemplate, ServiceMatches, and Entry class) into internal representations ( Item, Template, Matches, and EntryRep class) for message transfer efficiency. Also, the pr oxy classes make corres ponding method calls on the Registrar interface. The Registar interface defines a private RMI communication protocol between the various client-side proxy classes and the registration server implementation. Most of our modifications fo r context-awareness are confined to the RegistrarImpl class with an exception of the RegistrarProxy class where a few changes were made. Since none of the Jini standard AP Is that clients interf ace with was changed, our prototype is backward compatible with standard Jini implementations. Figure 4-7. Reggie implementation architecture The important changes we made to enable context-awareness for service discovery and advertisement are summarized as follows: Our changes internal to the method implementations of the ServiceRegistrar interface include: RegistrarImpl Registrar RegistrarProxy ServiceRe g istra r Registration ServiceRe g istration ServiceLease Lease Client Lookup service Class Interface Legend

PAGE 67

55 ServiceRegistration regist er(ServiceItem item, long leaseDuration) throws RemoteException, Object lookup(ServiceTemplate tm pl) throws RemoteException, and ServiceMatches lookup(ServiceTemplat e tmpl, int maxMatches) throws RemoteException For the ServiceRegistration interface, the following method implementations are changed to add, modify, or set the attributes of services th at were propagated upwards along the domain hierarchy. When a registered service itemÂ’s attri butes are updated by the service provider, the same changes are ma de to the registration with the parent by following the parent pointer. void addAttributes(Entry[ ] attrSe ts) throws UnknownLeaseException, RemoteException void modifyAttributes(Entry[ ] attrSetTemplates, Entry[ ] attrSets) throws UnknownLeaseException, RemoteException void setAttributes(Entry[ ] attrSe ts) throws UnknownLeaseException, RemoteException To properly maintain the lease chain, we had to change the following method implementations belonging to the Lease inferface. When eith er is invoked, the same method is also called at the parent along the chain. void cancel() throws UnknownL easeException, RemoteException void renew(long duration) throws LeaseDeniedException, UnknownLeaseException, RemoteException Experiments We conducted a series of experiments of our prototype context-aware lookup service based on Jini reference implementa tion version 1.2 from Sun. The experiments were designed to evaluate the prototype in terms of discovery perf ormance and benefit, which used a single lookup service and consiste d of two parts: service registry-side and

PAGE 68

56 client-side performance experiments. We us ed a Sun Ultra-60 workstation with 512M RAM, running J2SE v1.3.1_02. The benefits from the context-awareness are evident. But, at the same time, it introduces processing overhead to the lookup se rvice that must be scalable to support a large number of service registrations. Jini service attributes (that is, Entry objects) are packaged as serialized bit streams (that is, MarshalledObject ) so service matching can be made via bitwise comparison. The matching mechanism allows fast processing by lookup services without reconstituting the bit streams into real obje cts. This is why Jini can support only exact matching for service lookup. But in our case, the MarshalledObject objects for context attributes should be r econstituted back into objects to invoke evaluate() methods on them. Additional processi ng burden and network traffic will be introduced by deserializing the ma rshaled objects and the following evaluate() method calls. The first set of experiments is desi gned to address this scalability concern. Our lookup service running on a Sun Ultr a-60 machine is populated with 10,000 service instances of the same type. The servi ces used for experiments have two attributes: one is an instance of net.jini.lookup.entry.ServiceInfo class and the other is an instance of one of net.jini.lookup.entry.Location , Domain , Load , or Ping class. Note that the ServiceInfo and Location instance are static attributes and the other three are context attributes. The Domain context attribute looks into the DNS domain name of the registry, which may be checked for service providers wh o want to publish their services within a certain domain boundary. The Load attribute connects to its service provider to ask the current load on the server machine. Fina lly, round-trip time is measured by the Ping attribute that may be found useful by network latency sensitive services. The Domain and

PAGE 69

57 Ping attributes are local cont ext attributes, while the Load attribute is a remote context attribute. For each of these previous services, a client on the same machine makes four discovery requests to the lookup service with 10,000 instances of each type, asking for 1, 10, 100, and 1,000 instances each time, although th e queries are satisfied with all 10,000 instances. For each query, we measure CPU time taken by our augmented reggie using a Java profiling tool [Ejt02]. The evaluation re sult caching feature is disabled for these experiments. 1 10 100 1000 10000 100000 1101001000 Number of returned service instancesCPU time (msec) domain load location ping Figure 4-8. Jini lookup service performance Figure 4-8 plots the CPU time in logarith mic scale on both the xand y-axis for each service type. The lookup service performs well for the Location static attribute, while processing time for the three context attributes rises drastically beyond the 10 instances, as the number of returned service instances increases. But it should be noted

PAGE 70

58 that the simultaneous contex t evaluation of 100 or 1,000 inst ances is an extreme setting for scalability evaluation. Such a bursty ev aluation is unlikely to happen in a real situation unless a client brow ses the whole service in the lookup service (in this case, context attribute processing would be bypasse d) for the following reasons: Candidate services are first selected by static attribute matching, and then context attributes are evaluated for those services in the candida te set. In addition, the cache of previous evaluations will reduce the number of service in stances that need to be evaluated. Finally, as expected, the local context attributes ( Domain and Ping ) take less time than the remote attribute ( Load ). Our second experiment set is to analy ze contributions to the CPU time by the Ping context attribute. Again, caching is di sabled for these experiments. SunÂ’s reggie uses com.sun.jini.thread.TaskManager to manage a pool of thr eads for Jini discovery and event handling. We use another TaskManager instance for threads to evaluate context attributes. Figure 4-9 breaks down the CPU time for the Ping attribute evaluations. 0 10 20 30 40 50 60 70 80 90 ping-1ping-10ping-100ping-1000 Nubmer of returned service instancesCPU time (percentage) TaskThread.run() ContextTask.run() Ping.evaluate() Figure 4-9. Composition of lookup service CPU time

PAGE 71

59 The plot shows relative time spent on three methods. The TaskManager’s TaskThread calls our ContextTask.run() that, in turn, executes the Ping.evaluate() method. The TaskThread also manages other tasks, such as Jini discovery and event task. Since ContextTask time is part of TaskThread time and Ping.evaluate() time is part of the ContextTask time, each line in the graph subsumes its underlying line. As the number of returned services increases, a larger portion of the CPU time is taken up by TaskThread (62% and 85% of the CPU time at “ping100” and “ping-1000” point, respectively). ContextTask.run() uses about 58% of the CPU time for 100 instances and 35% for 1,000 instances. At the “ping-100” point , 23% of the CPU time is spent on Ping.evaluate() method, while 35% of the time is wasted main ly for thread synchronization to access the shared data structure, that is, reggie ’s service map. (It is the ti me that threads waste on the com.sun.jini.thread.ReadersWriter.writeLock() method invocation.) Less than 4% of the CPU time is used for multithread executi on and switching (that is, the time spent on the java.Object.wait() method). In the case of the “pi ng-1000” point, the numbers change to 13% and 22%. And 50% of the CPU time is used for concurrent thread execution. To measure time observed by clients, we ra n another set of experiments. For three services, including compute , dictionary , and ftp service, we measured lookup time and service time. The compute service offers a computation service that employs the Load context attribute in the previous experiments. The dictionary service returns the meaning of a word asked by clients, which is similar to dictionary Web services. Since latency is the most important criterion for this type of interactive services, it uses the Ping attribute used in the previous experiments. Finally, the ftp service uses a new Bandwidth attribute that examines available ba ndwidth between the lookup se rvice and the ftp service

PAGE 72

60 provider by rehearsing a 100K packet. For each service type, we populated 8 service instances with different service quality, ranging from 1x, 2x, 4x, 8x, 16x, 32x, 64x, to 128x . Figure 4-10 shows time for the lookup() method by a client under these experiment settings. 0 2000 4000 6000 8000 10000 12000 static attr.miss-0miss-25miss-50miss-75miss-100 Context miss ratio (percentage)Lookup time (msec) compute dictionary ftp Figure 4-10. Client lookup time The x-axis represents different context evaluation miss ratios. For example, “miss0” means that cached context evaluations are valid for all candidate services produced by static attribute matching. In addition, the case of “static a ttribute only” is shown for comparison. As the miss ratio increases, the client experiences moderate increases of lookup time for compute and dictionary services. But for ftp service, the lookup time changes drastically. This is because averag e context evaluation time and its variation differ across service types and instances of th e same type. Exercising a 100K packet over the 1x bandwidth link takes a much longer time. Th is is why we need a timer for context

PAGE 73

61 evaluation, as previously discussed. Also, we can see that links with better bandwidth for the “miss-75” case than for the “miss50” case have happened to be chosen. Figure 4-11 shows time for the first round of service uses. For example, service time for ftp service is the time to fetch 1M data . The x-axis represents how many cached evaluations are valid at the time of client requests. For example, “cand-50” means that context evaluation results are available for 4 out of 8 services. Service selection is made among those cached services without evaluating expired ones. For static attribute, the service time comes close to the average of all 1x through 128x 8 instances since the instances are selected at random fashion. Th e graph shows that service time can be dramatically reduced by service recommendati on via context attribut es at “cand-25”. The service time continues to improve as the ca ndidate set size grows toward the perfect case of “cand-100”. 0 5000 10000 15000 20000 25000 30000 static attr.cand-25cand-50cand-75cand-100 Candidate set size (percentage)Service time (msec) compute dictionary ftp Figure 4-11. Service time experienced by client

PAGE 74

62 Context-awareness for Service Discovery Various server selection mechanisms s how a full spectrum ranging from serverside to network and to client-side approach es. However, most of the mechanisms lack generality to be used by a variety of applica tions since they are fine-tuned to a specific type of service or a specifi c application domain. To overc ome this limitation, the server selection schemes are being generalized by recent RSerPool IETF drafts [Tue01a, Tue01b]. The RSerPool propos al is more concerned w ith communication-oriented aspects than service-oriented aspects, which positions itself as an additional entity separate from a general service discovery fr amework. It contrasts our approach, which is a more general service discovery framework th at is capable of s upporting various server selection mechanisms through context attribut es. By integrating the two into a single framework, our architecture provides a singl e-step service discovery and selection. Infrastructure support for a value-added service discovery is also found at the Selection and Sort extensions to SLP [Zha02]. However, their approach is to rank service instances according to a static-a ttribute-based sort key list, which is specified by clients. Clients must understand what attributes for the service type matter the most to be able to specify the selection criteria. Besides, the se lection process is performed solely by service registries without any help of services, whic h may constrain context information that can be captured. The idea of the context attribute draws from client-side server selection mechanisms, for example, Smart client [Yos97] . But it is generalized for general service discovery in our work, while the Smart client targets the Internet services hosted on a cluster of workstations. Another notewort hy work is media service discovery [Xu01] where the service discovery framework is us ed to cache end-to-end quality of services.

PAGE 75

63 Unlike others, our approach is to be able to capture dynamic aspects of context to enable much more sophisticated selection mechan isms. Consequently, our approach achieves both the specialty of server selection mechanis ms and the generality of service discovery protocols. We implemented the context-awareness support on Jini look up services with resource-constrained mobile devices in mind. However, it can be brought down to client devices if they have adequate resources to hand le the context attributes. In this case, more accurate context information would be able to be captured, and there would be no concern about lookup service scalability. But a disadvantage is that context evaluation results cannot be reused among clients.

PAGE 76

64 CHAPTER 5 GLOBAL SERVICE DISCOVERY PROTOCOL Our new global service discovery protocol, called Class-based Service Propagation (CSP) protocol, is based on the Centroid that is an aggregation method used for Whois++ index service [Fal96, Wei96]. Centroid The directory mesh for Whois++ index serv ice is composed of Whois++ servers as base nodes and index servers that summari ze their child Whois++ servers or index servers. A layer of the mesh summarizes the next lower layer. As such an aggregation method, Whois++ index se rvice introduced the Centroid , which is a collection of every word that appears at least once as attribut e values. The Centroid is propagated up along the tree to provide query routing informa tion. The Centroid at very upper layers eventually converges to a large set of words, which means global scalability. Color : Yellow Green Fruit : Banana Papaya Color : Yellow Fruit : Banana Color : Green Fruit : Banana Color : Green Fruit : Papaya Figure 5-1. A Centroid example

PAGE 77

65 Figure 5-1 shows an example of the Centroid which summarizes color and fruit attributes. The attribute values are aggregated per attribute. That is, the Centroid is generated by taking a union of all the words th at appeared as the attribute values for a trade-off between storage need and query performance. In this example, the Centroid saves one instance of Green and Banana , but it introduces false information, that is, Yellow Papaya . If the Centroid is looked up for Yellow Papaya , it will return a hit although such a record actually doe s not exist. This is called a false hit . Despite the one record saving, it does not seem cost-effective for every single word to be propagated all the way to the top layer of the mesh in the same way, regardless of how many times it appears in the sub-tree. Se ldom-used words contribute little to query routing, while taking up the same storage space as others. They need to be discriminated in favor of more frequently used ones at the upper layers of the index tree for overall system performance improvement. We envision that there would be a morass of services everywhere in the future ubiquitous computing world. In such a worl d, the efforts to update the globe on every dynamically changing service will not be paid off. In other words, it is wasteful to advertise full service information to the opposit e end of the world where it will likely not be used. Also, queries tend to be specifie d using popular, common a ttributes and their well-established values rather than specific query terms. (C lients usually do not know of all the details of services in advance accord ing to dynamic service discovery scenario.) The mobile clients will likely not seek speci fic service instances but anonymous services providing desired (perhaps standa rdized) functionalities, for ex ample, queries to look for a color ps printer rather than a printer w ith a bizarre name. Therefore, these general

PAGE 78

66 attributes need to be favored over specifi c ones to improve overall service discovery performance without generating much traffic. The vision of service ubiquity leads us to the idea of our Class-based Service Propaga tion (CSP) protocol as a new aggregation scheme. Its primary design goal is an accep table query performance without using excessive resources for service advertisemen ts and updates (a trade-off between query routing costs and service adve rtisement traffic and the storage of descriptive service information). Our new aggregation scheme forc es less-contributing words to fade faster than others, thereby enabling quick c onvergence to a manageable size set. Class-based Service Propagation Protocol It is well known that word usage in Eng lish follows Zipf distribution [Nie03]. That is, a few words are extremely often used, a me dium number of words are frequently used, and a huge number of words are rarely or almost never use d. Our CSP approach is trying to exploit this word frequency pattern. In general, to be globally scalable, information accuracy likely degrades through a certain m eans of aggregation or condensation, as it propagates further. Examples of the aggrega tion include a hierarchic al routing protocol (for example, Internet interdomain and intr adomain routing protocol) and the Bloom filter used by Berkeley Secures SDS. Noticing the Zi pf distribution of se rvice queries and the inefficiency in the Centroid indexing scheme , we devised an efficient aggregation method to employ the concept of classification, that is, different handling on the word frequency basis. Service information is classified as the first and second class. The first class information does not degrade at all or it undergoes TTL-based degradation and lazy update propagation, while the second cla ss experiences aggressive aggregation. Dominant, first-class attributes should be further propagated to attract more queries traveling on the network. In c ontrast, the protocol forces a faster convergence for the

PAGE 79

67 second-class information through attribute value string splits. To descri be our protocol in detail, we need the following parameter definitions: Class profiling threshold, denoted as pt, is the class divider to classify service information according to the number of its occurrences. Words that constitute attribute values are classified as the fi rst class, if they occurred more than pt times at a node. Otherwise, they belong to the s econd-class information. It is important to know that any node in our global service hierarchy is the root of our domain hierarchy that advertises co llectively its domain services. Minimal word length , denoted as mw , is the longest string length that is not subject to the attenuation process described below. Namely, it indicates the largest string size that is not further broken down. Attenuation unit, denoted as au, is the unit by which a string is cut off at the end as it passes through a node. It can be in the range of 1 au mw . Service attribute values, whose frequency exceeds the pt threshold value, are treated as the first class. Otherwise, th ey are classified as the second class. The second-class information undergoes fo rced aggregation through the gradual string diminution. A string, s , is split into two substrings of length |s| – au and of length au at each hop, as it propagates. This attenuation process makes the string, except for the leading mw part, gradually disappear. This way a query will be able to see more detailed information as it gets closer to potential matches. The attenuation unit parameter governs the aggregation rate of the second class. The first-class information propagates up to ward the root without any degradation or by a TTL-based lazy degrada tion scheme (that is, minor ch anges to their frequency are postponed until the accumulated changes br eak up an update barrier for further propagation). The first-class information provide s an accurate, fast path for query routing to promote the global scalability. Two possible strategies for the first-class propagation are as follows:

PAGE 80

68 Zero degradation: Once raised to the firs t class, the service information is never degraded. It makes first-class informati on updates in the middle of a propagation path unnecessary. The path can grow dow nwards or shrink upwards only at the bottom end. TTL-based degradation: The TTL value for the first-class information is defined to be ceil(log(frequency)), which detains update propagations until it becomes a new TTL value. This way frequent update tra ffic regarding the first-class information can be reduced. The TTL is decreased by one at each hop, and the first class information is downgraded to the sec ond class when the TTL value becomes zero. S1{a1=v11;a2=v21} S1{a1=v11;a2=v22} S1{a1=v11(2);a2=v21(1),v22(1)} S1{a1=v11(1)} S1{a1=v11(2)} S1{a1=v11} S1{a1=v11(2)} S1{a1=v11(2)} S1{a1=v11} S1{a1=v11} S1{a1=v11(2)} S1{a1=v11(2)} Â…Second class propagation First class propagation Figure 5-2. Zero degrada tion of the first class Figures 5-2 and 5-3 illustrate the zero degradation and TTL-based degradation propagation, where the class profiling threshold pt is 2. The notation S1{a1=v11;a2=v21} indicates an instance of service type S1 whose attribute values for a1 and a2 are v11 and v21, respectively. As shown in the figures, the fi rst-class and second-class information takes separate propagation paths. In Figure 5-2, changes to the first-class information are updated only for the ones occurring at th e bottom of the path and crossing the pt threshold value. Otherwise, they need not ta lly up. For instance, se rvice information from

PAGE 81

69 the right-most leaf node does not affect the first-class path. Figur e 5-3 shows that the first-class information is demoted to the second-class information, when it uses up its momentum for upward propagation, that is, the TTL value defined to be ceil(log(frequency)). S1{a1=v11;a2=v21} S1{a1=v11;a2=v22} S1{a1=v11(2);a2=v21(1),v22(1)} S1{a1=v11(1)} S1{a1=v11(2)}, TTL=1 S1{a1=v11} S1{a1=v11(2)} S1{a1=v11(4)}, TTL=1 S1{a1=v11} S1{a1=v11} Second class propagation First class propagation Figure 5-3. TTL-based degrada tion of the first class The second-class attributes below the profiling threshold pt value take a different propagation path. Attribute valu e strings are split into subs trings at each hop along the tree, if they are longer than the minimal word length , mw . This attenuation process forces service information to quickly converge to a much smaller size set than the original Centroid, while keeping minimal query routi ng information (that is, the fragments of au size substrings) for rarely sought services, hence global scalability. It follows that a smaller set size means less service update traffi c for the second-class attributes. While the split process allows significant gains in terms of storage and update traffic, there is a

PAGE 82

70 higher chance of false hits introduced by the attenuation. Although query performance degradation due to the false hits will be alleviated by the ubiquity and abundance of services in the future and our first-class pa th, the attenuation rate would be the most important determinant of specific query perf ormance. Therefore, attenuation parameters, such as attenuation unit ( au ) and minimal word length ( mw ), should be determined considering tolerable performance for specific queries. Figure 5-4 illustrates how st rings are aggregated by the second-class attenuation process, where mw is set to 2 and au also to 2. Strings are split off by au characters at the end, as long as they are longer than the minimal word length mw . The aggregate size is reduced from 26 at the bottom to 24 at the seco nd layer and to 16 at the next layer. We note that it is an extreme example to expl ain the attenuation process. These parameter values aggregate service information too aggr essively, and increased false hits will cause severe query performance degradation, as shown in the next simulation section. rest;strong at;ng;re;so;ss;st;stre;stro;thro sore;stress;throat at;ng;re;ro;so;ss;st;th Figure 5-4. An example of se rvice information attenuation

PAGE 83

71 CSP Query Routing Given a client query, our globa l service hierarchy routes it to service registries that contain matching service information. Servi ce information cached by each node provides an answer to which of its sub-trees leads to service in stances matching the query. For this, a registry has to keep a separate aggr egate for each link to its children. However, the service aggregates are not always able to provide the correct answers because of false hits, which require backtracki ng to the last branching node. rest;strong at;ng;re;so;ss;st;stre;stro;thro sore;stress;throat at;ng;re;ro;so;ss;st;th “sore throat” ? yes by “so;re;th;ro;at” “sore throat” ? yes by “so;re;thro;at” “sore throat” ? yes by “sore;throat” Figure 5-5. An example of query routing Figure 5-5 illustrates how cached service information is used for query routing. Service aggregates are shown to the left of corresponding nodes, and a query to the right along a query path. Suppose that we have a query looking for a service with a “sore throat” attribute string. The t op node of the sub-tree in the figure concludes that matching services may exist in its left sub-tree, sin ce the query can be covered by “so,” “re,” “th,” “ro,” and “at” from its left-child aggregate. The query is forwarded in to that direction and

PAGE 84

72 a match is eventually found at the left-botto m node. An example of a false hit is a query of “song” for which the root node will point to the left chil d. But its left child node will find that it was a false hit. Simulation of CSP Protocol We conducted a simulation study to compare the performance of our CSP protocol and the base Centroid since both are using st ring-based attribute-value pairs for service descriptions. Performance comparison, which was between the Centroid and Berkeley SSDS to employ the Bloom filter as their ag gregation method, was reported in [Hod02a]. Workload Analysis The objective of our simulation is to valid ate our design decisi on of CSP protocol. Our primary concern is a balance between que ry performance and service advertisement traffic. Through the simulation study, we tried to evaluate our CSP protocol’s gains and losses, especially to verify if it achieves an acceptable query perf ormance without using excessive resources for service advertisements. As our workload, we use the freedb CD database (http://www.freedb.org) as in [Hod02a]. The record for a CD consists of se veral text-based attri butes and associated values. Among them, YEAR and GENRE attributes are thought of as general attributes, popular for discovery queries (p erhaps standardized attribut es and their well-established values), and the rest of the attributes as speci fic ones. Examples of the specific attributes include DISCID , DISC TITLE, and SONG TITLES (TITLE0, TITLE1, TITLE2, TITLE3, TITLE4, and TITLE5) , which have unique string values. We compare our CSP performance with the Centroid’s in terms of query cost and storage used for service advertisements. We note that the storage need is proportional to the volume of information exchanged among nodes for service advertisements and updates.

PAGE 85

73 It is a well known fact that word usag e in any natural language follows Zipf distribution. Other examples of the distri bution are Web-page access and book check-out from a library [Nie03]. The distribution is a straight curve when pl otted in logarithmic scale on both the xand y-axis, which means that (1) a small number of popular words are excessively used, (2) a moderate number of words are frequen tly used, and (3) the rest of the words are rarely or almost never used. We analyzed our workload consisting of more than 4,000 CD records to find that it s hows a perfect Zipf distribution, as depicted in Figure 5-6. The graph shows curves for 0 to 4 time splits, where both CSP attenuation parameters of mw and au are set to 3. The x-axis represents word popularity, meaning word ranking according to occurrence frequenc y. For instance, the first x value is the most frequently used word, which appear s 5,935 times in the case of “no split.” The 7,536th frequently used word, that is, the last x value, appears only two times. The base straight line corresponds to th e “no split” case. As words ar e split repeatedly, the curve shifts upwards, which means a chance of a huge gain that our CSP protocol can exploit. The split will increase a false hit rate, but it does not necessarily mean the same rate of query performance degradation. A long string is likely to be made up of distinguishing and common parts. The common subs trings contribute little to query routing if they show up from a majority of child nodes. We will have to try them one by one. As an example, consider two strings, “pavement” and “m ovement,” coming from two different child nodes, and assume that “pave” and “move” are un ique. If the two are split in the middle, “pave” and “move” will be the determining elements of the query of “pavement” or

PAGE 86

74 “movement,” while the common substring, “m ent,” does not provide any guidance, as long as only the two strings are concerned. 0 1 2 3 4 5 6 7 8 9 10 0246810 Word popularityWord frequency no split 1 split 2 splits 3 splits 4 splits No Split 1 Split 3 Splits 4 splits 2 splits Figure 5-6. CD database word distribution Words used to describe the CD records are of length 1 to 71. Single character words, including alphanumeric and special characters, appear 14,039 times out of total 127,479. The most common length, 4, happens 25,872 times, which constitutes about 20% of the total. The longest of length 71 appears only once. Table 5-1 shows the word length distribution of the original workload (no split), and 95% of them are less than length 10.

PAGE 87

75 Table 5-1. CD database word length distribution Word length 1 2 3 4 5 6 7 8 9 10 71 Frequency 14039 12481 16631 25872 16853 11964 9908 9887 4352 5492 Cumulative percentage 11.01 20.80 33.84 54.14 67.36 76.74 84.52 92.27 95.69 100.00 Also, the assumption our CSP protocol ma de about the general-to-specific query ratio is shown to be true by the Zipf distri bution curves. As presented in the following section, specific query performan ce is sacrificed in favor of service advertisement traffic. However, CSP protocol achieves improved ove rall system performance in return. Figure 5-7 shows the effect of the splits in te rms of an aggregated service database size. The graph plots how much of the service aggregate of random 2,040 services can be reduced by different atte nuation rates. The legend aggregation-n indicates the case of attenuation parameters of mw = n and au = n . 0 50000 100000 150000 200000 250000 0123456 No. of splitsDatabase size aggregation-2 aggregation-3 aggregation-4 Figure 5-7. Service database size reduction by splits

PAGE 88

76 Simulation Results The global registry hierarchy for all our si mulation cases is a complete binary tree comprised of 255 nodes. In addition, the class profiling threshold pt is fixed to 16 because we need much larger scale simulation to see its effect. Figure 5-8 is a simulation result, when 2,040 services are randomly populated on the complete binary tree. 0 50000 100000 150000 200000 250000 300000 01234567 Tree depthDatabase size aggregation-2 aggregation-3 aggregation-4 centroid Figure 5-8. Database size at each layer The plot compares average service aggr egate size at each layer for different aggregation rates. (The aggregation-n indicates the case of the at tenuation parameters of mw = n and au = n .) In the case of the Centroi d, the aggregate database grows exponentially, which means that top-tier nodes of the tree will be overwhelmed by massive traffic. It may be t hought of as CSP protocol with mw = . A huge amount of storage and traffic is spent to index every wo rd appearing in the tree. However, the cost will not be paid off considering a morass of services and dominant general queries in the

PAGE 89

77 future ubiquitous computing world, as discus sed earlier. In summar y, our CSP protocol forces further service aggregation, enabling better storage efficiency. Figure 5-9 presents query performance eval uation results for different aggregation parameter values of mw and au : (a) indicates query routing performance in terms of the average number of hops that a query travels until a match; (b) shows the total space use throughout the tree; and (c) tries to compare the efficiency ac ross different settings. Total 2,040 CD information is randomly distributed over the 255-node tree, and 255 queries are also randomly fed into the network. The gene ral-to-specific query ratio is 1:1, meaning that half the queries are to look for a CD using the YEAR or GENRE attribute as a search key. The other half, that is, specific queries, are specified in the DISCID, DISC TITLE, or SONG TITLE 0 to TITLE 5 attributes. Graph (a) confirms that the minimal word size ( mw ) 2 is too short so it overly aggregates service information, resulting in severe query performance degradation for the given workload. In the upper part of the tree, query match results are almost always true, thereby forwarding the queries to every child node (becoming equivalent to an exhaustive search). But the cases of mw 3 and 4 (for both au =1 and au=mw ) achieve comparable query performance with the Ce ntroid. Graph (b) shows storag e savings by CSP protocols. Graph (c) presents protocol efficiency defined to be th e product of average hops and storage usage, a quick and rough comparison me tric. It is important to know that the protocol efficiency should be appraised from a global scalability perspective. Space usage at the upper parts of the tree s hould be considered rather than the total storage (see Figure 5-8), and traffic near the root is also an important criter ion (refer to Figure 5-11).

PAGE 90

78 0 2 4 6 8 10 12 14 16 18 mw=2mw=3mw=4centroid Minimal word lengthNubmer of hops au = 1 au = mw 0 500000 1000000 1500000 2000000 2500000 3000000 mw=2mw=3mw=4centroid Minimal word lengthTotal database size au = 1 au = mw (a) Query performance (b) Storage use 0 5000000 10000000 15000000 20000000 25000000 mw=2mw=3mw=4centroid Minimal word lengthProtocol efficiency au = 1 au = mw (c) Protocol efficiency Figure 5-9. Query cost versus syllable length Figure 5-10 compares the query performan ce of CSP protocol with that of the Centroid for different general-to-specific que ry ratios. Other simulation conditions are the same as in the previous simulations, that is, total 2,040 services populated over the 255node tree and 255 queries. Again, the aggregation-n indicates the case of the attenuation parameters of mw = n and au = n . Except for the aggretaion-2 case, the CSP protocol

PAGE 91

79 shows comparable performance with the Ce ntroidÂ’s. The CSP query takes a bit longer response time, which is attributed to th e increased false hit rate caused by CSPÂ’s attenuation. As long as query performan ce is concerned, the Centroid obviously outperforms our CSP. By using more resources to keep the service index, the Centroid can provide nearly optimal query performan ce from our CSPÂ’s point of view. However, our protocol design goal is a balance be tween query performance and storage and advertisement traffic. 0 5 10 15 20 25 ratio 2:0ratio 2:1ratio 2:2ratio 2:3ratio 2:4 General-to-specific query ratioNumber of hops aggregation-2 aggregation-3 aggregation-4 centroid Figure 5-10. General-to-specifi c query ratio versus cost We also ran additional simu lations to measure CSP query performance for different service populations of 4,080, 2,040, 1,020, 510, and 255 services. The query performance was largely consistent regardless of the service populations. (The CSP query latency slightly increased, as the service population grows.)

PAGE 92

80 To compare service update performance, 127 new service insert ion requests are issued over the 255-node tree with 2,040 servic es preloaded. As shown in Figure 5-11, CSP protocol generates much less traffic than the Centroid, especially for the top tier of the tree, which is critical to be globally scalable. Again, the aggregation-n indicates the case of the attenuation parameters of mw = n and au = n . The x-axis value d indicates the amount of update traffic between depth d and d+1 . Finally, we note that service deletion showed similar traffic usage. 0 2000 4000 6000 8000 10000 12000 14000 16000 0123456 Tree depthUpdate traffic aggregation-2 aggregation-3 aggregation-4 centroid Figure 5-11. Update traffic at each layer

PAGE 93

81 CHAPTER 6 SERVICE DELIVERY User mobility inherent in the future ubi quitous computing environments dictates service mobility support. For instance, a user should be able to access the same service on his desktop computer at work, on his auto PC on the road, or on his smartphone on the street. That is, services should be able to be presented to a variety of target devices in an appropriate way to the device capability, whic h entails service inst ance selection, service transformation, or some sort of terminal ad aptation. In addition, provided a “note-taker” service delivered to his PDA is able to support dual modalities of pen and voice interfaces, he will likely prefer the voice command interface on the street. But he will probably use the pen interface to edit his voice notes back in his office. The diverse user device capability and interface modality are a main force to drive device-independent service delivery research, and they are prim ary context information to be taken into account for service delivery. Thin-client Approach to Service Delivery To deliver services to client devices inde pendently of the target device capability, we have developed a proxy system, called the Jini proxy system [Hel02a]. This prototype is to be incorpor ated into the BA of our th ree-tiered service discovery framework presented in Chapter 3. Built on top of Sun’s Jini and AT&T’s VNC (Virtual Network Computing) [ATT02], the prototype deals with service di scovery and delivery. More specifically, it f unctions as a Jini proxy with rega rd to service discovery, and it serves client devices as VTC (Virtual Thin Client) servers for service delivery as well.

PAGE 94

82 From a service user’s perspective, our Jini architecture provides the same functionality as the combin ation of Jini surrogate ar chitecture [Sun01a] and Jini ServiceUI project [Ven01] does. Jini surroga te architecture also introduces a proxy to represent to a Jini community resource-cons trained devices that cannot afford Jini protocol. Unlike the Jini Serv iceUI project that requires multiple GUI implementations (one for every potential target device clas s), our “emulation thr ough VNC” approach is able to deliver one service running on the ne twork proxy to any type of client devices. Therefore, a single service implementation is enough for various target device classes. The Jini surrogate architecture plus the Jini ServiceUI project require that a service implementation follow the discipline of the su rrogate architecture for small, non-Jini devices with extra burden to implement a corresponding full-blow n version once again for Jini-capable devices. In contrast, our VNC emulation is an “all-in-one” approach; a single service implementation would be enough regardless of whether it is a full-blown Jini implementation or surrogate implemen tation. Also, we do not need to care about specific graphic toolkits available on target devices, as long as they meet a minimal requirement to run our VNC client program. The Jini proxy system chooses the most appropriate implementation, considering serv ice implementations and client devices altogether, when multiple choices are given. If any matching service implementation is not available, it resorts to the VNC emulation. To bring various services to resour ce-constrained mobile devices, our Jini system employs three different approaches. The simple st and most straightforward mode is to have a service code executed en tirely on the client side ( Client executable mode ). In case of fat services or if resources needed by the services are not available, we have to resort

PAGE 95

83 to two adaptation approaches. These approach es rely on the proxy to execute any kind of fat services, either MIDlets [Sun02b] or J2SE services, through th e network-side thinclient system, which sends only screen updates to the client. The first adaptation enables MIDlets to be executed by our MIDl et emulator on the proxy side ( VTC MIDlet emulation mode ), while the second is for J2SE services ( VTC J2SE emulation mode ). The client should not be involved in th e decision of the delivery methods. Our Jini system is capable of selecting the be st under the given service invocation conditions, and it minimizes the serviceÂ’s dependency on device capability to achiev e device-independent service representation. A Java interface, VTCable , must be implemented by any service object that may be invoked through the VTC emulation modes. The in terface is an empty ma rker interface to indicate that an object implemen ting it is allowed to run on the Jini proxy. Jini Proxy System Architecture As shown in Figure 6-1, the Jini proxy system architect ure is made up of four main components: Jini Protocol, Resident Client, VTC (Virtual Thin Client) Client, and Jini Proxy. The Resident Client resides on a client devi ce and takes care of interfacing between the client and the proxy server as well as handling the VT C client/server communication through a VNC channel. The Jini proxy contains many different pieces and performs the Jini service discovery on the network side for the client as well as allocating a thin-client server for the client to access to use the discovered service. The VTC is split into two pieces, VTC Client on the client side and VTC Server on the Jini proxy side. Most of the processing is pushed to the proxy server si de so the low-resource client device can

PAGE 96

84 operate more efficiently. The Jini Protocol allows the clie nt and proxy to talk using a common library, and a separate VNC channel is used for the VNC (Virtual Network Computing) server connection. The VNC is an open-source, thin-client system developed by AT&T Laboratories Cambridge [ATT02]. Verifier Adapter Jini Protocol Jini Services Dispatcher Jini Proxy Jini Lookup Services Client Device KVM CLDC MIDP Application Space ResidentClient JAM Jini Protocol VNC Channel VNC PNG Support MIDlet Emulator VTC Server VTC Client Figure 6-1. Overall Jini system architecture Jini Protocol Because small mobile devices are commonly resource-constrained, the Jini proxy has been introduced to offload heavy Jini requi rements from client de vices. Jini requires J2SE serialization and RMI, which are not supported by J2ME (CLDC/MIDP) for small devices [Sun02a, Sun02b]. We ha ve therefore defined the Jini Protocol API which allows the client device and proxy server to communicate using a co mmon set of library APIs. The protocol is simple enough to fit into small devices, but supports all necessary messages for Jini proxy discovery, Jini service discovery, service invocation, lease

PAGE 97

85 management, and client device description (t hat is, client device capability context information) passing. Its full description can be found in NordstedtÂ’s MicroJini [Nor01]. Any Jini Protocol session begins with pa ssing the client device profile to the Jini proxy, similar to CC/PP device profile passing [Kly02]. Resident Client The Resident Client is a MIDlet program, in the case of small J2ME devices, running on the client devices. It provides a graphical user interface to the user for speaking the Jini Protocol to find and request services from the Jini proxy server. It also takes care of instantiating a VTC view er and cleaning up res ources after a service session is complete. In the case of download ed services, that is, the client executable mode, the Resident Client will interact with the proxy, download the MIDlets from a specified http server, and load the code onto the client device using native operating system functions. Otherwise, it will start a VTC viewer for VTC emulation service delivery. VTC Client The VTC on the client side implements the main encoding schemes the VNC rfb protocol defines [ATT02]. These include Raw, Hextile, RRE, and CoRRE encoding schemes. In addition, we have added our own protocols to send updates as a PNG image, using the freely available PNG image form at [PNG01], since J2ME provides built-in support for PNG. We support PNG 8-bit color, PNG 8-bit grayscale, and also PNG 2-bit grayscale images.

PAGE 98

86 Jini Proxy Figure 6-2 shows the com ponents that comprise the Jini proxy. It functions as not only a Jini proxy to translate the Jini protocol to full Jini protocol, but also a thinclient adaptor that executes heavyweight servic es on behalf of the client device. Each of the components is briefly described below. Figure 6-2. Components of Jini proxy Dispatcher As shown in Figure 6-2, the Dispat cher is the central piece of the Jini proxy, which mediates all the interactions among comp onents. First of all, it communicates with client devices, speaking the Jini protocol. Upon requests fr om the clients, it performs service discovery on behalf of the Resident C lients and provides MIDl et or J2SE service emulation services though the VNC channel. More specifically, the Dispatcher contacts the Jini Manager to perform service discovery from Jini lookup services in the local Proxy Shell Jini Manager Jini Lookup Services Dispatcher VTC Verifier MIDlets/ VTC Manager uJini Protocol VNC channel Jini Services Servers Adapter

PAGE 99

87 network. Also, it makes a MIDlet or Jini serv ice emulation request to the VTC manager, if necessary. Proxy shell The Proxy shell provides a simple administrative shell interface so that administrators can check the system status, such as act ive Jini lookup services, VTC server pool usage, and current client list. Jini manager The Jini manager provides the rest of the proxy with Jini interface service. Basically, it keeps track of ac tive Jini lookup services in the local network. It translates the Jini Protocol messages into Jini repres entation to query th ese lookup services. Verifier The Verifier checks if discovered se rvice objects are MIDlets that are downloadable to a J2ME device. When it dete rmines service delivery mode, it must take into consideration the discovered service object , client device capabi lity, and the delivery mode the service provider has set. First, the Ve rifier inspects the service object to see if it is J2SE objects or MIDlet(s). In the case of MIDlets, the ve rification process proceeds to check if the delivery mode set by the service providers allows downloading to the client. Note that the service providers’ wish preced es the Verifier’s decision on delivery mode. Furthermore, it looks into program/data space on the device to ensure that there is enough room for the MIDlets. If it passes all thes e checks, the Verifier finally declares the delivery mode to be “ download ” mode. Otherwise, the delivery mode is set to “ vtc ” mode (MIDlet or J2SE service emulation mode).

PAGE 100

88 Adapter The Adapter executes the decision on the service delivery mode made by the Verifier . If the discovered serv ice turns out to be J2SE Jini objects, it should be executed on the proxy side and the client gets its disp lay through the VNC channel. If the object is MIDlets but not downloadabl e, it is executed by the MIDlet Emulator , a component of the Jini VTC server. If downloading is allo wed, the MIDlets are downloaded to the client and executed locally. A ccordingly, it provides emulation services for standard Jini services and MIDlets that do not fit into client devices. VTC manager VTC manager provides client devices with the emulation service of MIDlets and J2SE Jini services. The VTC manager mainta ins a pool of VTC servers from which one server instance is allocated to a user who needs the emulation service. When the user session is over, the server inst ance is put back to the pool. The implementation of J2SE Jini servi ce emulation is relatively easy. A VNC desktop is dedicated to a JVM on which a Jini service proxy is started. Then its display is sent to a client through a VNC channel and the, in response, user input is forwarded to the service proxy via VNC event messages. Fo r MIDlet emulation, we have developed the MIDlet emulator which is built on CLDC/MIDP reference implementations from Sun [Sun02a][Sun02b]. As described below, input even ts and output displays are intercepted and diverted to the other side. MIDlet emulator The performance of the MIDlet emulator is not a primary concern for our current proof-of-concept version. For rapid pr ototype development, we built our Jini MIDlet

PAGE 101

89 emulator on Sun CLDC/MIDP reference impl ementation and reuse them as much as possible. One of the primary design principles of our MIDlet emulator is to provide a consistent view to users regardless of whic hever mode a service is presented in. The emulator is designed to hide any difference between local execution mode and emulation modes by the proxy. However, in our current implementation, users are exposed to a long MIDlet installation phase of the local execution case, which is inevitable due to the limitation of current J2ME technology. Figure 6-3. MIDlet emulator To create an illusion that the emulated se rvice is running on the client device, the proxy intercepts and diverts input events to the emulator and output display back to the client. The user inputs are rela yed to the emulator running on the Jini proxy side, and resultant emulator display is redirected to the client devi ce through the VNC channel. The flow of user inputs and disp lay updates is as follows: (2) Jini protocol (1) VNCserve r pool X11 input event VNC desktop pool MIDle t runner KVM event(4) Display update (3) KVM event (3) KVM event Jini Proxy

PAGE 102

90 (1) VNC server pool : On startup, the Jini proxy initializes a set of VNC servers used for the emulation service, which avoids the lead-time to br ing an underlying VNC server up on receipt of client requests. (2) The Jini protocol : When a new client requests a service to be presented via the MIDlet emulation mode, the Jini proxy assigns a free VNC server to the client and starts a MIDlet emulator instance over the VNC desktop. (3) KVM event relay : The Resident Client on the phone intercepts user key strokes to send them to the Jini proxy which, in turn, passes them to a corresponding MIDlet emulator instance. The decision of the event re laying was made for the sake of easy event processing. The limitation of simultaneous sock et connections, which is 2 on the client device (Motorola i85 smartphone), is another reason for the de cision. The Resident Client needs one connection, and the other one must be given to the VNC rfb display update channel. By being able to share the Resident ClientÂ’s connection for event transfer, the client does not need to interfere with the VNC rfb protocol (that is, no need to understand VNC event representation and processi ng). Input KVM events are sent via Jini protocol messages. In the case of smartphones, only the LCD sc reen part of the emulator display is mirrored to the real phone screen through th e VNC channel. Our input event handling mechanism threads two separate pieces together , that is, the user interface part on the client device and the MIDlet service running on the network proxy side, so as to provide MIDlet emulation service. More specifically, the Resident Client in tercepts keypad input events and delivers them to the emulator in the J2ME KVM event representation. The Jini proxy simply passes incoming events on to an associated emulator through an open

PAGE 103

91 socket connection. These events are injected to the point where the or iginal emulator used to translate native operating system events (X11 mouse events in our prototype) to corresponding KVM events. (4) Display update : A MIDlet running on the emulat or reacts to the event. A resultant display update (VNC rf b update message) is sent to the VTC client on the client device. Consequently, it looks to the client as if the MIDlet is locally being executed on his device. Performance Measurements We present basic performance measuremen ts for the two delivery options of our Jini proxy system prototype implementation. Detailed experimental measurements and performance data are reported in MicroJini [Nor01]. There is a huge difference in the tim e between a downloaded service and VTC emulation service usage. A service applicati on (that is, a J2ME MIDl et) run locally must first be downloaded to the clie nt device and then installed be fore it can be executed. The low bandwidth wireless networ ks that are common today, al ong with the long process of installing an application on a resource-constr ained device, add up to a long time for the user to wait to run the service. A service application that is run as a thin-client, however, only needs to wait for the VTC server to start the service and for the client to create a connection to the server. The application can be started in seconds rather than minutes for a downloaded service. In Figure 6-4, the performance data averages are shown for the total time to start the services after discovery. We have used four J2ME MIDlets on the Motorola i85

PAGE 104

92 smartphone which are iCoffee, Shopping, PhoneClient, and MapIt . The comparison shows the large difference in time for a user to start a service when downloading compared to when using the VTC emulation mode. Comparison of Local Execution Startup and VTC Startup0 50 100 150 200 250 300 iCoffee ~35kB Jar File Shopping ~23kB Jar File PhoneClient ~24kB Jar File MapIt ~34kB Jar File MIDlet Name & SizeSeconds Local Execution VTC Figure 6-4. Service startup time comparison We have also implemented an 8-bit colo r PNG protocol, an 8-bit grayscale PNG protocol, and a 2-bit grayscale PNG protoc ol to complement existing VNC encoding schemes. These new protocols enhance the ove rall performance of the µJini proxy system when the VTC emulation mode is invoke d as the service delivery option. The performance data of the VTC MIDlet emula tion mode for standard and enhanced VNC encoding schemes can be found in MicroJini [Nor01].

PAGE 105

93 CHAPTER 7 SUMMARY AND FUTURE RESEARCH In this chapter, the main contributions of the dissertation ar e assessed along with some of the future research tasks regard ing the context-aware, ubiquitous service discovery and delivery system. Summary of Contributions The main contributions of this dissertati on are an architecture, a concept, and a protocol whose aim is to take service disc overy from the realm of enterprise networks into a ubiquitous and global scale. By mobilizing service discovery through a scalable infrastructure, a wide class of exciting pervasive computing application will be enabled. Our first contribution is a three-tiered arch itecture for service discovery that allows services defined within a proximity (a small network) to remain within the proximity boundary, to become accessible from a domain of multiple proximities (for example, an enterprise), or even to become a global “anywhere” service. The ar chitecture uses a novel concept we call context attributes and a ne w protocol that extends IETF’s Centroid indexing service to guarantee the scalability of global service advertisements while minimizing overall service query performance degradation. We introduced context attributes, which are an effective means to capture relevant, dynamic context information related to the cond ition of the mobile client, the service, and/or the end-to-end network in connecti on with dynamic servi ce discovery. Since it provides a framework for any service-specifi c selection logic, our context attribute extends the role of service discovery to in clude server selection capability. By tightly

PAGE 106

94 coupling service selection with service disc overy and advertisement, it becomes possible to easily achieve higher scalability, especially in the face of servi ce proliferation (for example, widespread popular and similar services). We have designed a Class-based Service Propagation protocol (CSP) to guarantee the efficiency of global service discovery, ba sed on the three-tiered architecture. The CSP protocol minimizes storage overhead and servic e advertisement traffic. We compared the CSP protocol for wide-area service discovery with the IETF Centroid approach through simulation. The simulation result verified th e superiority of our CSP protocol over the standard Centroid. By achieving scalable service discov ery and advertisement (through context attributes) and by minimizing th e cost of storage and global service advertisement traffic (the Centroid-based CSP protocol), it beco mes feasible to design and implement truly ubiquitous service discovery systems. Service delivery takes place following the service discovery phase to complete the dynamic service acquisition process. Since discov ered services may not fit into resourcepoor mobile devices, the two phases should be br idged by client device capability context information. Our unique approach to the proble m is a thin-client ad aptation architecture to deliver a range of lightto heavyweight service to resource-cons trained devices. As a proof-of-concept prototype, we developed the Jini proxy system that allows a service to be presented to any class of target de vices using virtual thin-client technology. Future Research It has been shown through a prototype im plementation and simulation study that our context-aware, ubiquitous service disc overy and delivery architecture properly

PAGE 107

95 addresses the needs of a future service di scovery system. However, it can be further enhanced and extended through the following planned tasks: Ad hoc service discovery proxy: To address the requirements and characteristics of mobile services in wirele ss ad hoc, peer-to-peer networ ks, we developed a new ad hoc service discovery protocol in a separate wo rk [Lee03]. A partially ad hoc network may have a few fixed nodes that are connected to the wired network in which services are advertised and discovered by the mobile se rvice discovery framework. The next step would be to bridge the two worlds via a proxy residing on the fixed nodes. CC/PP support: The Jini proxy system enables re source-constrained mobile devices to indicate their capability to a service registry. For this, we defined a set of basic device capability attributes as part of the Jini protocol. Our proprie tary device capability attributes need to be replaced with W3C CC/PP standard attributes [Kly02] (that is, CC/PP equivalent Java at tributes for service di scovery and delivery). Service matching rule for context attributes : The current context attribute can be viewed as just a container to hold service matching and recommendation logic. As a Java object, there is virtually no limit to the cap ability to express sophisticated service selection and context handling logic. It allows service providers flexibility to write their context attributes in the most appropriate way to their serv ice implementations. However, the service instance ranking through the context index normalization may not be as powerful enough to process complicated context handling as a general rule language. It is an interesting idea to adopt a rule language to describe context attribute logic to be evaluated and executed by a rule engine in service registry.

PAGE 108

96 LIST OF REFERENCES [Abr99] M. Abrams, C. Phanouriou, A. Ba tongbacal, S. Williams, and J. Shuster, “UIML: An Appliance-Independent XML User Interface Language,” Computer Networks, vol. 31, pp. 1695-1708, 1999. [Adj99] W. Adjie-Winoto, E. Schwartz, H. Balakrishnan, and J. Lilley, “The Design and Implementation of an Intentional Na ming System,” In Proceedings of the 17th ACM Symposium on Operating Systems Principles (SOSP '99), Charleston, South Carolina, USA, ACM, pp. 186-201, December 1999. [ATT02] AT&T Laboratories Cambri dge, Virtual Network Computing, http://www.uk.research.att.com/vnc, Accessed: May 20 2002. [Bec99] J. Beck, A. Gefflaut, and N. Isla m, “MOCA: A Service Framework for Mobile Computing Devices,” In Proceedings of the ACM International Workshop on Data Engineering for Wireless and Mob ile Access, Seattle, Washington, USA, ACM, pp. 62-68, August 1999. [Bha97] S. Bhattacharjee, M. Ammar, E. Zegura, V. Shah, and Z. Fei, “Applicationlayer anycasting,” In Proceedings of the IEEE INFOCOM ’97, Kobe, Japan, IEEE, pp. 1388-1396, April 1997. [Bic97] T. Bickmore and B. Schilit, “Dig estor: Device-independent Access to the World Wide Web,” Computer Networks and ISDN Systems, vol. 29, no. 8-13, pp. 1975-1082, September 1997. [Bis01] C. Bisdikian, J. Davis II, W. Jerome, and D. Sow, “Emerging Research Opportunities in Ubiquitous Service Di scovery,” In Proceedings of New York Metro-area Networking Workshop ( NYNET01), Hawthorne, New York, USA, March 2001. [Blo70] B. Bloom, “Space/Time Tradeoffs in Hash Coding with Allowable Errors,” Communications of the ACM, vol. 13, no. 7, pp. 422-426, July 1970. [Blu99] Bluetooth Consortium, “Specificatio n of the Bluetooth System Core Version 1.0 B: Part E, Service Discovery Protocol (SDP),” November 1999. [Bri95] T. Brisco, “DNS Support for Lo ad Balancing,” IETF RFC 1794, April 1995.

PAGE 109

97 [Che00] G. Chen and D. Kotz, “A Survey of Context-aware Mobile Computing Research,” Department of Computer Science, Dartmouth College, Technical Report TR2000-381, 2000. [Che02] S. Cheshire, B. Aboba, and E. Guttman, “Dynamic Configuration of IPv4 Link-Local Addresses,” IETF Internet Draft, http://www.ietf.org/internetdrafts/draft-ietf-zeroconf-ipv4linklocal-07.txt, August 2002. [Cis02] Cisco Systems, “Distributed Director,” http://www.cisco.com/warp/public/cc/ pd/cxsr/dd/index.shtml, Accessed: October 23 2002. [Cos01] A. Costanzo, “Definition of the DNS GL Resource Record used to encode Geographic Locations,” I ETF Internet Draft, http://www.botwerks.org/network-eng/bi nd/docs/draft/draft-costanzo-dns-gl03.txt, August 2001. [Cze99] S. Czerwinski, B. Zhao, T. Hodes, A. Joseph, and R. Katz, “An Architecture for a Secure Service Discovery Service, ” In Proceedings of the Fifth Annual ACM/IEEE International Conference on Mobile Computing and Networking (MobiCom ’99), Seattle, Washingt on, USA, ACM, pp. 24-35, August 1999. [Dav96] C. Davis, P. Vixie, T. Goodwin, and I. Dickinson, “A Means for Expressing Location Information in the Domain Name System,” IETF RFC 1876, January 1996. [Dey99a] A. Dey, G. Abowd, and D. Salber, “A Context-Based Infras tructure for Smart Environment,” In Proceedings of the 1st International Workshop on Managing Interactions in Smart Environments (MANSE ’99), Dublin, Ireland, SpringerVerlag, pp. 114-128, December 1999. [Dey99b] A. Dey, M. Futakawa, D. Salber, and G. Abowd, “The Conference Assistant: Combining ContextAwareness with Wearab le Computing,” In Proceedings of the 3rd International Sy mposium on Wearable Computers (ISWC '99), San Francisco, CA, USA, IEEE Computer Society Press, pp. 21-28, October 1999. [Dyk00] S. Dykes, C. Jeffery, and K. Robbins , “An Empirical Evaluation of Client-side Server Selection Algorithms,” In Pr oceedings of IEEE INFOCOM ’00, TelAviv, Israel, IEEE, pp. 1361-1370, March 2000. [Ejt02] ej-technologie s’ JProfiler, http://www.ejtechnologies.com/products/jprofiler/overview.html, Accessed: June 11 2002. [Fal96] P. Faltstrom, R. Schoultz, and C. We ider, “How to Interact with a Whois++ Mesh,” IETF RFC 1914, February 1996. [Fie97] R. Fielding, J. Gettys, J. Mogul, H. Nielsen, and T. Berners-Lee, “Hypertext Transfer Protocol--HTTP/1.1,” IETF RFC 2068, January 1997.

PAGE 110

98 [Gim01] R. Gimson, S. Finkelstein, S. Maes, and L. Suryanarayana, “Device Independence Principles,” W3C Working Draft, http://www.w3.org/TR/2001/WD-d i-princ-20010918, September 2001. [Gut99a] E. Guttman, C. Perkins, J. Veizad es, and M. Day, “Service Location Protocol, Version 2,” IETF RFC 2608, June 1999. [Gut99b] E. Guttman, C. Perkins, and J. Kempf, “Service Templates and Service: Schemes,” IETF RFC 2609, June 1999. [Hat01] M. Hattig, “Zeroconf Requirements,” IETF Internet Draft, http://www.ietf.org/proceedings/01mar /I-D/zeroconf-reqt s-07.txt, March 2001. [Hel02a] S. Helal, C. Lee, and D. Nord stedt, “Impromptu Service Discovery and Delivery for Pervasive Computing Environments,” Pending clearance from Motorola, 2002. [Hel02b] S. Helal, “Service Discovery a nd Delivery,” IEEE Pervasive Computing, vol. 1, no. 3, pp. 95-100, September 2002. [Hel03] S. Helal, N. Desai, V. Verm a, and C. Lee, “Konark–A Service Discovery and Delivery Protocol for Ad-hoc Networks ,” In Proceedings of the Third IEEE Conference on Wireless Communication Networks (WCNC), New Orleans, Louisiana, USA, March 2003. [Hin98] R. Hinden and S. Deering, “I P Version 6 Addressing Ar chitecture,” IETF RFC 2373, July 1998. [Hod02a] T. Hodes, S. Czerwinski, B. Zha o, A. Joseph, and R. Katz, “An Architecture for Secure Wide-Area Service Discover y,” ACM Wireless Networks Journal, vol. 8, no. 2/3, pp. 213-230, March/May 2002. [Hod02b] J. Hodges and J. Morgan, “Light weight Directory Access Protocol (v3): Technical Specification,” IETF RFC 3377, September 2002. [Jos99] R. Jose and N. Davies, “Scalable and Flexible Location-Based Service for Ubiquitous Information Access,” In Proceedings of First International Symposium on Handheld and Ubiquitous Computing (HUC ’99), Karlsruhe, Germany, Springer Verlag, pp. 52-66, September 1999. [Kly02] G. Klyne, F. Reynolds, C. W oodrow, H. Ohto, and M. Butler, “Composite Capabilities/Preference Profiles: Structure and Vocabularies,” http://www.w3.org/TR/2002/WD-CCPPstruct-vocab-20021108, November 2002.

PAGE 111

99 [Kum00] S. Kumar, C. Alaettinoglu, and D. Estrin, "SCalable Obje ct-tracking through Unattended Techniques (SCOUT)," In Pr oceedings of the 8th International Conference on Network Protocols, Osaka, Japan, IEEE, pp. 253-262, November 2000. [Lee03] C. Lee, S. Helal, N. Desai, V. Verma, and B. Arslan, “Konark–A System and Protocols for Device Independent Pee r-to-Peer Discovery and Delivery for Mobile Services,” Submitted for publication, March 2003. [Mey98] D. Meyer, “Administratively Scoped IP Multicast,” IETF, RFC 2365, July 1998. [Moo98] K. Moore, “SONAR-A Network Proxi mity Service,” IETF Internet Draft, http://www.globecom.net/ietf/draft/d raft-moore-sonar-03.html, August 1998. [Nid01] M. Nidd, “Service Discovery in DEAPspace,” IEEE Personal Communications, vol. 8, no. 4, pp. 39-45, August 2001. [Nie03] J. Nielsen, “Zip f Curves and Website Popularity,” http://www.useit.com/alertbox/zip f.html, Accessed: February 19 2003. [Nor01] D. Nordstedt, “MicroJini: A Servi ce Discovery and Delivery Infrastructure for Pervasive Computing,” Master's thesis, University of Florida, 2001. [Par93] C. Partridge, T. Mendez, and W. Milliken, “Host Anycasting Service,” IETF RFC 1546, November 1993. [Per02] C. Perkins, “SLP white paper,” http://playground.sun.com/srvloc/slp_white_paper.html, Accessed: December 29 2002. [PNG01] PNG Home Site, “P ortable Network Graphics,” http://www.libpng.org/pub/png/png.ht ml, Accessed: June 2 2001. [Pon01] S. Ponnekanti, B. Lee, A. Fox, P. Hanrahan, and T. Wi nograd, “ICrafter: A Service Framework for Ubiquitous Com puting Environments,” In Proceedings of Ubicomp ’01, Atlanta, Georgia, USA, Springer Verlag, pp. 56-75, September/October 2001. [Rom00] M. Roman, J. Beck, and A. Geff laut, “A Device-Independent Representation for Services,” In Proceedings of the 3rd Workshop on Mobile Computing Systems and Applications (WMCSA 2000), Monterey, California, USA, IEEE, pp. 73-82, December 2000. [Ros97] J. Rosenberg, H. Schulzrinne, and B. Suter, "Wide Area Network Service Location," IETF Internet Draft, http://www.globecom.net/ietf/draft/draft-ietfsvrloc-wasrv-01.html, November 1997.

PAGE 112

100 [Sal99] Salutation Consortium, “Salutati on Architecture Specification Version 2.0c,” http://www.salutation.org/specordr.htm , June 1999. [Sch94] B. Schilit, N. Adams, and R. Want , “Context-aware Computing Applications,” In Proceedings of IEEE Workshop on Mobile Computing Systems and Applications, Santa Cruz, Californi a, USA, IEEE, pp. 85-90, December 1994. [Sun01a] Sun Microsystems, “Jini Technolog y Surrogate Architecture Specification v1.0,” http://surroga te.jini.org/specs.html, July 2001. [Sun01b] Sun Microsystems, “Jini Specifications v1.2,” http://wwws.sun.com/software/jini/s pecs/jini1.2html/coreTOC.html, December 2001. [Sun02a] Sun Microsystems, Connected Li mited Device Configuration (CLDC), http://java.sun.com/products/cldc, Accessed: May 9 2002. [Sun02b] Sun Microsystems, Mobile In formation Device Profile (MIDP), http://java.sun.com/products/midp, Accessed: May 9 2002. [Sun99] Sun Microsystems, “Jini T echnology Architectural Overview,” http://www.sun.com/jini/whitepapers /architecture.html, January 1999. [Suz01] T. Suzumura, S. Matsuoka, and H. Nakada, “A Jini-based Computing Portal System,” In Proceedings of the 2001 ACM/IEEE Conference on Supercomputing, Denver, Colorado, USA, ACM, pp. 24-32, November 2001. [Tho96] S. Thomson and T. Narten, “IP v6 Stateless Address Autoconfiguration,” IETF RFC 1971, August 1996. [Tue01a] M. Tuexen, Q. Xie, R. Stewart, M. Shore, L. Ong, J. Loughney, and M. Stillman, “Requirements for Reliable Serv er Pooling,” IETF Internet Draft, http://www.ietf.org/proceedings/01aug/I-D /draft-ietf-rserpoo l-reqts-03.txt, May 2001. [Tue01b] M. Tuexen, Q. Xie, R. Stewart, M. Shore, L. Ong, J. Loughney, and M. Stillman, “Architecture for Reliable Serv er Pooling,” IETF Internet Draft, http://www.ietf.org/proceedings/01aug/I-D /draft-ietf-rserpoo l-arch-00.txt, April 2001. [UDD02] UDDI.org, “Universal Descrip tion, Discovery and Integration of Web Services (UDDI),” http://www .uddi.org, Accessed: December 4 2002. [UPn00] UPnP Forum, “Universal Plug and Play Device Architecture,” http://www.upnp.org/download/UPnP DA10_20000613.htm, Accessed: June 19 2000.

PAGE 113

101 [Ven01] B. Venners, “The ServiceUI Proj ect,” http://www.artima.com/jini/serviceui/, Accessed: November 8 2001. [Wan92] R. Want, A. Hopper, V. Falca o, and Jonathan Gibbons, “The Active Badge Location System,” ACM Transactions on Information Systems, vol. 10, no. 1, pp. 91-102, January 1992. [Wan95] R. Want, B. Schilit, N. Adams, R. Gold, K. Petersen, D. Goldberg, J. Ellis, and M. Weiser, “An Overview of the PARCTAB Ubiquitous Computing Experiment,” IEEE Personal Communicat ions Magazine, vol. 2, no. 6, pp. 2843, December 1995. [Wei91] M. Weiser, “The Computer for the 21st Century,” Scientific American, vol. 265, no. 3, pp. 94-104, September 1991. [Wei96] C. Weider, J. Fullton, and S. Sp ero, “Architecture of the Whois++ Index Service,” IETF RFC 1913, February 1996. [Xu01] D. Xu, K. Nahrstedt, and D. Wich adakul, “QoS-Aware Discovery of WideArea Distributed Services,” In Proc eedings of IEEE/ACM International Symposium on Cluster Computing and the Grid (CCGrid 2001), Brisbane, Australia, IEEE, pp. 92-99, May 2001. [Yos97] C. Yoshikawa, B. Chun, P. Eastham, A. Vahdat, T. Anderson, and D. Culler, “Using Smart Clients to Build Scalable Services,” In Proceedings of the 1997 USENIX Annual Technical Conference, Anaheim, California, USA, USENIX Association, pp. 105-117, January 1997. [Zha02] W. Zhao, H. Schulzrinne, E. Guttman, C. Bisdikian, and W. Jerome, “Selection and Sort Extension fo r SLP,” IETF Internet Draft, http://www.watersprings.org/pub/id/dra ft-zhao-slp-customization-05.txt, August 2002.

PAGE 114

102 BIOGRAPHICAL SKETCH Choonhwa Lee received his Bach elor of Science and Master of Science degrees in computer engineering from Seoul National University, South Korea, in 1990 and 1992, respectively. He was then employed by LG Information and Communication Ltd., South Korea, where he was involved in various computer network and telecommunication projects. In 1999, he started hi s doctoral studies in the Computer and Information Science and Engineering Department (CISE) at the Un iversity of Florida in Gainesville. His research interests include m obile computing and networks, pervasive computing, Internet protocols, and network security.