Universal Access Architecture for Digital Libraries∗

Francisco Alvarez-Cavazos, Roberto Garcia-Sanchez, David Garza-Salazar,Juan C. Lavariega, Lorena G. Gomez, Martha Sordia

Informatics Research Center, ITESM, Campus MonterreyAv. Eugenio Garza Sada 2501, Monterrey, NL, 64849, Mexico

{franalvac,rgsipn}@gmail.com; {dgarza,lavariega,lgomez,msordia}@itesm.mx

Abstract

In this paper we present a universal access architecturefor digital libraries. Our architecture supports traditionalfixed clients and mobile clients addressing the connec-tion adaptation and limited resources challenges pre-sented by mobile devices. We describe the requirementsof universally available personal digital libraries and il-lustrate their applicability with a user scenario. Theserequirements are addressed by our universal access ar-chitecture, which targets to support multiple device ac-cess, including mobile devices. The main componentsof the architecture are the Client-Side Applications, theData Server and the Mobile Communication Middleware(MCM). Our work has focused on the mobile connec-tion support provided by the interaction of mobile clientswith the MCM, obtaining a constant response rate inspite of variability of network conditions. The architec-ture of a mobile software client that benefits from thesemechanisms is described and supplemented with imple-mentation notes showing how—in spite of the limitedcomputing resources of mobile devices—it can interactwith a data server that has not been designed to supportclient mobility via adaptation techniques implemented ina middleware.

1 Introduction

With the advent of wireless communications, userscan stay connected to the network even when theyare moving from one place to another. This para-digm is calledmobile or nomadic computing. Mo-bile computing is changing the way people inter-act, work and use technologies. This has brought

∗This work has been funded by CONACyT (grantCONACYT-2002-C01-41372), CUDI and ITESM.

Copyright c© 2005 ITESM, Campus Monterrey. Permis-sion to copy is hereby granted provided the original copyrightnotice is reproduced in copies made.

on myriad opportunities for exciting work in sys-tems that currently envision users as being static,such as [1]: (a) workflow management systems,(b) digital libraries,(c) e-commerce and(d) eventhe WWW itself! The motivation for our researchlies with digital libraries, which provide online ac-cess to distributed text and multimedia informa-tion sources in an integrated manner. Digital li-brary services have traditionally been provided viaa Web-based search interface. However, with thewidespread-use of mobile technologies, massivedigital library systems with tens of millions userswill appear in the near future. The scale of suchsystems demands changes to the traditional archi-tecture of digital libraries.

To grant digital library services to the mobileuser, we propose auniversal access architecturewhich aims to provide users with the capabilityof accessing the digital library “from anyplace atanytime” [2]. By its very nature, universal ac-cess encourages a user-centered design of applica-tions. Thus, we have extended our digital librarymotivation to realize the abstraction of personal li-braries. Personal libraries provide traditional li-brary services such as document submission, full-text and metadata indexing and document searchand retrieval; augmented with innovative servicesfor the moment to moment information manage-ment needs of the individual user. These inno-vations include provisions to customize the clas-sification of documents, interact with other digi-tal libraries and support user-to-user exchange ofgeneric digital content. Hence, the universal accessarchitecture presented herein should be suitablefor other document-based applications on whichdevice-independent access to both personal andcollective data is required.

To realize universally available personal library

services we must cope with thetechnological chal-lengesimposed by theimplementation of digital li-brary services[3]: (a) digital document creation,(b) classification and indexing,(c) search and re-trieval,(d) distribution and content delivery,(e)ad-ministration and access control,(f) non-restrictivedocuments,(g) quality of documents,(h) varietyof formats and(i) user interface and presentation;themobile environment[1] and the specificrequire-ments of personal digital libraries(see Section 2).

The main challenges imposed by mobile envi-ronments, presented in Table 1, include:

• Connection adaptation. Mobile applica-tions require a connection adaptation strategyagainst low bandwidth availability, disconnec-tions, high bandwidth variability and commu-nication asymmetry (i.e. different bandwidthin the downstream and upstream directions);

• Limited resources. Mobile systems could facea significant mismatch between:(a) the sup-ply and demand of a resource such as en-ergy, processing power, memory, small screensize, etc. in mobile units and(b) processingpower or network bandwidth in the base sta-tions, fixed hosts and database servers in orderto support a high volume of concurrent accessfrom the mobile units;

• Mobility. The location of a mobile unit isof fundamental importance to mobile datamanagement since it should be regarded as adata item whose value changes with the unit’severy move; and

• Security. Wireless mobile environments areeven more susceptible to malicious attacksthan wired distributed systems. In addition,the size of some of the portable units (e.g.handhelds) makes them prone to data loss dueto theft and accidents.

The mobile environment challenges must be ad-dressed by a universally available digital librarysystem. Perhaps the most relevant of these chal-lenges, from the digital library system point ofview, areconnection adaptationand limited re-sources, since they directly affect the communica-tion services that a digital library system must pro-vide.

In this paper, we present our universal access ar-chitecture and its proof-of-concept implementation

Connection Adaptation Limited ResourcesLow bandwidth Limited battery power

Frequent disconnections Limited processing powerHigh bandwidth variability Limited memoryPredictable disconnections Small screen sizeCommunication asymmetry Scalability

Mobility SecuritySusceptible to malicious attacks

Fast changing locations Susceptible to damaging data dueto theft and accidents

Table 1: Mobile Environment Challenges

in the context of our research testbed: thePersonalDigital Library System(PDLib for short) [4]. Weaddress the(a) low-bandwidth,(b) frequent discon-nections and(c) high bandwidth variabilitycon-nection adaptationand the(a) limited processingpower,(b) limited memory and(c) scalabilitylim-ited resourceschallenges of the mobile environ-ment with the integration of information storageand retrieval, database and mobile client technolo-gies to provide universally available personal digi-tal libraries.

The rest of this paper is organized as follows.In Section 2 we describe the concept of universalaccess. We exemplify universal access in the con-text of a library application: PDLib. Based on thisdiscussion, Section 3 describes the universal accessarchitecture in terms of PDLib’s implementation.In Section 4, we compare our universal access ar-chitecture with other work in the field. Finally, weconclude in Section 5.

2 Universally Available DigitalLibraries

In order to provide universal access, a system mustbe designed for mobile environments. This meansthat the system must contemplate several clientapplication types. Software clients can be clas-sified according to theirclient-side architectureinto: (a) thin clients, and(b) thick clients; andagreeing with theirmobility into: (a) fixed clients,and (b) mobile clients (Figure 1). In thin clients,the application is delivered on a browser or mi-crobrowser; while on thick clients both code anddata reside on the device. Thick and thin clientscan coexist in a single device. Mobile clients arethose with wireless connections to the system’s net-work; while fixed clients have a reliable—wiredconnection—with the network.

Figure 1 plots client-side architecture on the ver-

2

Figure 1: Mobile Environment Clients

tical axis and client mobility on the horizontal axis.The quadrants contain stereotypical protocols anddevelopment platforms for each client category.Mobile thick clients are especially important toachieve universal access since mobile applicationsshould center on mobile thick clients—a key differ-ence with Web applications, which typically focuson fixed thin clients—since thick clients make of-fline operation possible. A technological migrationtrend that goes from Web applications to mobileapplications is suggested. This trend reflects recentsoftware application development tendencies andimplies that the technologies available in an earlierstage are present in subsequent stages as well.

Personal Libraries

To realize personal digital libraries, the followingrequirements were considered:(a) Flexible collec-tion and metadata management. Collections must

Figure 2: PDLib Mobile Client:(a) Library Navi-gation,(b) Document Services.

Figure 3: PDLib Web Client

be provided as a mechanism for document classifi-cation and users should be provided with the abil-ity to define the metadata set that will be used todescribe the contents of each collection.(b) Digi-tal document submission. The user should be ableto add any digital document to a personal digital li-brary. Submission from several device types shouldbe supported. The personal digital library mustbe able to accommodate several document formatsfor the same document.(c) Search and retrieval.Search and retrieval mechanisms must adapt to thepersonalized classification schema defined by theusers of the system.(d) Administration and ac-cess control. The owner of a personal digital li-brary always has unrestricted access to her/his per-sonal digital library content. In addition, the ownershould be provided with the capability to provideother users with access to her/his personal digitallibrary content.(e) Interoperability. Interoperabil-ity with other personal library users and with othersearch and retrieval systems using well-known in-teroperability protocols.

These requirements define personal digital li-braries as composed of collections. Collectionscontain, in turn, other collections and/or docu-ments. Users can interact with personal digitallibraries by creating and deleting collections andsubmitting, moving, copying or downloading doc-uments. In addition, users can define the metadataset that will be used to describe the contents of eachcollection. These interactions allow the user to cus-tomize her/his personal library as desired.

PDLib has been designed to provide its userswith universal access to personal library contentand, in consequence, targets mobile and fixed de-vices adapting library services to client device ca-pabilities. Figure 2 shows a CLDC/MIDP J2ME

3

implementation of a mobile thick client running ina Palm Tungsten C Simulator. Figure 3 shows afixed thin client running on a desktop computer’sWeb browser.

To illustrate the concept of universally availablepersonal digital libraries, we provide a hypotheticaluser scenario. The following scenario exemplifiesuser interaction with personal libraries, emphasiz-ing the mobile connection support mechanisms al-ready available in PDLib.

Shaping and Sharing Personal Libraries with Univer-sal Access. Sarah, a visual arts undergraduate student,has been working on a two-student writing assignmentfor her Comparative Mythology class. Sarah andAidan, her team partner, have chosen the comparisonof the Norse and Greek mythological systems as theirassignment topic. Sarah is using her Personal DigitalLibrary (PDLib ) from her desktop PC to store andclassifydocumentsregarding the Norse myths. She hasdecided to arrange her documents under acollectionnamed“Norse Myths” created for this purpose. Withinthis collection, she has created other collections togroup documents under certain themes (e.g.“TheogenicMyths”, “Creation of the Universe”) or has placedthe documents directly under“Norse Myths”. She hasalso created a“Vikings Online” collection to storeuseful Internet references. In order to simplify theclassification of the“Vikings Online” collection andease its population, Sarah has customized themetadataset definition of the“Vikings Online” collection so thatit contains just a“Title” and “URL” fields. Finally,Sarah has set thepermission rights of her “NorseMyths” collection so that Aidan has access to herdocuments. Aidan, currently working on campus at theVisual Arts Center and off campus as a graphic designer,is constantly moving from one location to another. Healso changes his working computer frequently since hehas been assigned a PClaptop at the Visual Arts Centerand adesktopMacintosh at the design agency. Duringhis precious free time at both works, Aidan is able tobrowse the references found by his teammate Sarah fortheir shared homework using his PDLib to access hers.As a complement to Sarah’s research, Aidan has to finduseful information regarding Greek mythology and hasbeen storing his findings at his PDLib under a collectioncalled “Greek Myths”. On one occasion, he ran into hisfriend Matthew at the campus walkways. After briefingeach other on their latest doings, they found out thatMatthew—who is working on an essay for his ClassicalMythology class—could use one of Aidan’s references.Since Matthew does not have a PDLib, Aidan uses theemail document feature of his PDLib from hismobilephone to send Matthew a copy of the reference. A fewdays before the due date of his written assignment with

Sarah, Aidan bought himself aPDA. Having writtenthe joint essay and stored a copy of both the finishedessay and its related presentation in their PDLibs, Sarahand Aidan decide toretrieve the presentation usingPDLib in preparation for their in-class lecture. Later,at the lecture’s Q&A section, both Sarah and Aidanwere able to access their PDLibs tosearch, retrieveand display some of the documents quoted in theirwork from Aidan’s PDA. After being praised for thequality of their presentation, Sarah and Aidan wereable to send the essay via PDLib to their professorand classmates. Shortly after learning about Sarahand Aidan’s success, Matthew acquired a PDA and hasobtained a PDLib. Having spent some time last nightcreating and populating several collections in his PDLibfrom his home desktop computer, he uses his PDA toaccess his PDLib through the campus wireless network.While walking across campus as he experiments withhis PDLib, he discovers that he cannavigate smoothlythrough his library despite connection variability.Matthew is pleased to find out that PDLib answershis requestsat an apparently constant rate. After acloser observation, he realizes that when he retraces hisnavigation steps, theresponsesfrom his PDLibcomeeven faster! Matthew also noticies that while retrievingdocuments from his PDLib to his PDA,documenttransfers are successfully completedafter losingconnection with the network—or even after turning offhis PDA—once the wireless connection is resumed.

The convenience of universal access is portrayedin the scenario. Despite moving from one place toanother or changing computing devices, Aidan wasable to reach his documents wherever and when-ever he needed to. This was possible since PDLib’sarchitecture can provide digital library services tomost computing devices with an Internet connec-tion by contemplating several client applicationtypes to address the host diversity of the mobileenvironment. Mobile thick client applications alsoadapt to the limitations of the mobile environment.Specialized connection middleware is used to sup-port the adaptation measures undertaken by mobilethick clients. Client applications can be used tobrowse the contents of other digital library systems.Interoperability has been made possible by the in-clusion of modules compliant with the Protocol forMetadata Harvesting of the Open Archives Initia-tive (OAI-PMH [5]) in our personal library system.

The final part of the scenario describes the userexperience provided by our personal digital librarywith universal access infrastructure by means ofmobile thick clients. The infrastructure includes a

4

mobile connection middleware that interacts withmobile thick clients in order to provide users with:

• Constant Navigation Rate. Provides the userwith the maximum number of data records in arelatively constant, user-modifiable, responsetime. The maximum number of records is de-rived from an estimation of current networkstate. In practice, this feature favors responsetime out from a trade-off with data transferthroughput.

• Connection Aware Document Transfers.The user can transfer documents betweenhis mobile device and his PDLib regardlessof disconnections and/or turning the device’spower off. Document transfers are connectionaware in the sense that:(a) transfers are re-sumed when connectivity is established and(b) transfer rate is adjusted according to net-work state estimation. Since document trans-fers persist across disconnections, the usermust be provided with a cancelation mecha-nism.

• Navigation Speed Up via Caching. Allowsthe user to speedily retrace his navigationsteps. The increase in back navigation speedis obtained by using navigation caching mech-anisms.

3 Universal Access Architec-ture

To provide universally available digital librarieswe have developed an architecture and a prototypethat provide library services to several device types(e.g. desktop, laptop, PDA and mobile phone) withmultiple operating systems (e.g. Windows, Linux,Mac OS, Palm Os and Windows CE). The drivingidea behind this architecture is to provide each de-vice with the best way to interact with the servicesoffered by the data server. In the remainder of thissection, we elaborate in our universal access archi-tecture in the context of PDLib with support of Fig-ure 4—an overview of PDLib—and Figure 5—itsdetailed architecture.

PDLib is composed of three layers:

1. Client Tier . Includes the variety of devices withwhich a user can interact with PDLib;

Figure 4: PDLib Overview

2. Server Tier. Shows the server system in-frastructure that provide services to clients:(a) Data Server,(b) Mobile Connection Middl-ware (MCM) and(c) Web Front-end.

3. Interoperability Tier . Includes other (PDLib)data servers and OAI-PMH [5] compliant digitallibrary systems.

The devices of the client tier communicate withthe server tier to access PDLib digital library ser-vices. The access type of the client tier with theserver tier varies according to the client device’scapabilities. The architecture of PDLib reflects thefollowing access types:

• Middleware Access. Supports mobile devices,especially those with limited computing re-sources (e.g. HTTP-enabled mobile phones,PDA).

• Web Access. Provides HTTP-access to anydevice that includes a Web browser.

• Direct Access. Applications with very partic-ular requirements can access the data serverdirectly. In Section 3 we provide an exampleof such an application.

The following sections describe the componentsof PDLib, their interaction and prototype imple-mentations.

3.1 Clients

As mentioned before, the software clients of a mo-bile environment can be classified according to

5

Figure 5: PDLib Architecture

their client-side architecture and mobility. We elab-orate on this classification with support of Figure 1,Figure 4 and Figure 5.

It is possible to map the mobile client applicationtypes to the devices supported by PDLib as follows:

• According to client-side architecture. Thinclient applications connect to the Data Serverthrough the Web Front-end while thickclient applications communicate with the DataServer via the Mobile Connection Middle-ware.

• According to mobility. Mobile applicationsconnect to the server tier via unreliable wire-less connections while fixed applications con-nect to the server tier via a reliable wired con-nections. Figure 4 shows wireless connectionsas dashed lines and wired connections as solidlines.

With the objective of providing an accessmedium appropriate to the devices shown in Fig-ure 4, the following client application types weredefined (see Figure 5):

• Mobile clients(mobile thick clients). Mobileclients were designed to cope with the limita-tions of the mobile environment. This meansthat mobile clients redefine the functionalityprovided by PDLib’s fixed clients to provide

the abstraction of a personal digital library ona mobile device. A middleware is required tohelp mobile clients achieve their mobile con-nection adaptation goals.

• Web clients(fixed and mobile thin clients).This category includes those devices with abrowser or microbrowser capable of display-ing HTML, as shown in Figure 3, or WMLpages. Despite the fact that Web clients do nothave all the features available in thick clients,they provide basic interaction support withPDLib. Web clients connect with PDLib’sWeb Front-end.

• Application clients(fixed thick clients). Ap-plication clients are intended to run in desk-top and laptop devices with few computingresources constraints. Application clients aredesirable because they provide a richer inter-face than Web clients. In addition, applicationclients can communicate directly with the dataserver, which leads to a more efficient com-munication of fixed clients.

The previous client types were defined becauseeach type has very particular characteristics. Ap-plication clients are intended to run on resourceunconstrained devices such as desktop or laptop.On the other hand, a mobile user can interact withPDLib using a mobile client. Mobile clients allow

6

Figure 6: Mobile Client Architecture

the interaction with the personal library offering asubset of the functionality provided by fixed thickclients. Web clients, on the other hand, were de-signed to endow the user with access to their librarywithout the prerequisite of a client application in-stalled on a computing device. One of the mainchallenges is in mobile clients, since they have todeal with the limitations of the mobile environ-ment. To accomplish their task, mobile clients per-form the following functions:

• Local Storage Mechanism. Store documentsin the mobile device for offline viewing.

• Connection Adaptation Mechanism. Thismechanism provides a constant response timedespite the connection variability of wirelessconnections, by interacting with the MCM.A constant response time can be achieved bycalculating the size of the data-transfer win-dow and predicting network state [6]. Sincemost connection adaptation work is performedin the MCM, more detail is provided in Sec-tion 3.3.

• User Interaction Support. Graphical inter-face that allows the user to manage the per-sonal digital library content from its mobiledevice. Mobile clients read results receivedfrom the MCM and display them on screen.

Mobile clients provide a simple and friendly in-terface in order to let users to get an easy interac-tion through their navigation on this application.This graphical interface allows a user to managethe personal digital library content from its mobile

device. Mobile clients read results received fromthe MCM and display them on screen.

The architecture of user-interaction support inthe mobile client prototype includes (Figure 6):

• Image Set. Images play an important appli-cation role, since representative images (e.g.folder or document thumbnails) enhance userexperience. However, images do add an over-head to application size both in permanentstorage and memory. In order to reduce run-time memory demands, images are retrievedfrom permanent storage on a per screen ba-sis, as requested by user interaction. Oncerecalled from permanent storage, images willremain in memory, for later use.

• Library Services. Library services are madeavailable through user-interface items (e.g.combo boxes, lists, menus and buttons). Sim-ilarly to image retrieval from permanent stor-age, interface items are also generated as de-manded by user interaction. The services pro-vided by the mobile client to the user are:(a) Glance through the contents of his/her per-sonal digital library (Figure 2 (a));(b) Re-trieve and store a local copy of selected dig-ital library documents on the mobile device;(c) Manage her/his personal digital library by:i. Moving/copying documents or collectionsand ii. Setting access rights to documents orcollections (Figure 2 (b));(d) Share their dig-ital library content by:i. Sending documentsvia email andii. Sending a document to an-other PDLib user (Figure 2 (b));(e) Searchfor documents in her/his personal digital li-brary (Figure 7 (c));(f) View and edit docu-ment metadata (Figure 7 (d)); and(g) Browsethe contents of other users’ personal digital li-braries.

• Library Navigation . The mobile client easesthe interaction between users and the digitallibrary with a navigation interface similar tothe interface provided by folder-based file sys-tems to access library collections and docu-ments (Figure 2 (a)).

3.2 Web Front-end

The Web Front-end transforms personal digital li-brary services into a web application. In order

7

Figure 7: PDLib Mobile Client: (c) Search,(d) Document Metadata.

to support fixed and mobile thin clients, the WebFront-end is capable of delivering WML or HTMLaccording to the requesting device (i.e. browser ormicrobrowser). The Web Front-end provides thefollowing functionality:

• Session Handling. Session handling is usedto maintain the interaction of a thin client withthe Web Front-end beyond a single HTTP re-quest.

• Browser Markup Language Support. Veri-fies the markup languages supported by the re-questing browser and serves HTML or WMLaccordingly.

3.3 Mobile Connection Middleware

One of the main problems to solve in order to pro-vide the data server services to mobile clients isthe fact the data server was designed to supportfixed devices (e.g. desktop computers). Thereis a remarkable difference in computing resourcesbetween mobile (e.g. mobile phones, PDAs) andfixed devices (e.g. desktop computers). This com-puting resource disparity makes difficult to adaptthe data server to the capabilities of mobile devicesand signals the need of a middleware componentto mediate the interaction of mobile devices withthe data server. Our design of such a middleware iscalled theMobile Connection Middleware(MCMfor short).

The MCM is designed to provide followingfunctionality:

• Connection Support. Required by mobileclients in order to perform adaptation to thebandwidth variability of the mobile environ-ment and to cope with the frequent disconnec-tions of mobile devices.

• Process Delegation. Executes functions thatwould demand an excessive (and quite pos-sible, unavailable) amount of computing re-sources to the mobile device.

• Mobility Support . Performs operations in or-der to speed up document retrieval from thedata server to store them incacheservers thatare closer to the user. When the user changeslocation, it would be necessary to support mi-gration of the information between differentinstances of the MCM.

• Device Interaction Support. Performs adap-tation of content according to the character-istics of the device on which it is desired todisplay the information.

Current work has focused on mobile connec-tion support and has produced the architecture andprototype implementation of the following mecha-nisms (Figure 8):

• Session Handling. Maintains knowledge ofconnection state in order to simulate a perma-nent communication and also keeps recordsof the mobile client’s device characteristics.Conceptually, this mechanism is analogous tothe session handling mechanism of the WebFront-end, yet their implementation vastly dif-fers. In the Web Front-end, session handlingis realized with standard HTTP sessions whilethe MCM session mechanism is custom-madeand both application and device-oriented (seebelow);

• Pagination Mechanism. Provides the mobileclient with a subset (page) of the original dataserver response for:(a) its display on the mo-bile device screen or(b) transfers of documentsegments;

• Caching Mechanism. Stores query responsesreceived from the data server in order to ac-celerate the responses it serves to the mobileclient; and

8

Figure 8: MCM Architecture

• Connection Adaptation. Adjusts the rate ofdata exchange (e.g. data records, documentsegments) between the MCM and the mobileclient according to connection state.

Connection support is accomplished by the jointwork of these mechanisms with mobile thickclients. The MCM prototype provides the follow-ing connection support services to mobile clients:(a) Session handling over the stateless XML-RPCprotocol. Since our session mechanism is device-oriented, currently we do not support changingdevices in the middle of a session;(b) A con-stant collection navigation response time despitethe connection variability of wireless connections;(c) Partition document transfers and disconnectionsupport while transferring documents. In addi-tion to providing connection adaptation, the MCMalso stores query responses received from the dataserver in order to accelerate the responses it servesto the Mobile Client.

In the remainder of this section, we elaborate inthe implementation of the mobile connection sup-port mechanisms of the MCM, with support of Fig-ure 8.

The MCM’s session handlingmechanism pre-serves connection state and simulates a persistentconnection over the stateless XML-RPC protocol.Session support begins with the mobile client mak-ing a service request to the MCM. The MCM, afterverifying that there is no active session for the user-mobile client combination requesting the service,generates a unique session identifier and sends it

back to the client. The session identifier is thenstored in the session handling mechanism. After-wards, the mobile client will use the session iden-tifiers to interact with the MCM in the context ofa single session. Session identifiers have a Time-to-Live (TTL) and can be renewed (effectively, bygranting a new identifier) if required.

Mobile devices have limited screen, processing,memory and communication resources. A segmen-tation of personal library objects may be desired toimprove user experience. For example, a mobileuser wants to visualize all the documents locatedin a personal library collection. The resulting re-quest could generate a large amount of records thatmay, for example, fit in the mobile device screen.The limited computing resources of mobile devicesmay lead to the following cases:

• An answer that is too large to be handled dueto limited communication capacity of the mo-bile device (e.g. overload of the incomingbuffer).

• The device can handle the reply and is able toshow it, but its size can lead to an unpleasantuser experience (e.g. when presenting 100 ormore data records in a PDA screen).

• Mobile users are faced with variable connec-tion quality. An uncertain wireless networkstate introduces varying response times for thesame request.

These technical challenges can be solved with apagination mechanism. Where apageis a subsetof a library object (e.g. a collection or documentformat) to be presented in the mobile client.

The MCM pagination mechanism works as fol-lows: First the MCM receives a mobile client re-quest, processes it, and request the library objectimplied to the data server, if needed (i.e. if a cachemiss occurs). The data server replies the petitionto the MCM, which stores the library object in itscache, and divides the object into pages of a sizedependent on network state which are then pulledby the client. In order to pull the pages of the li-brary object, the client stores the indexes of the re-ceived pages so it can request the remaining pages.Thus, enabling the mobile client to:(a) reconstructlibrary objects after retrieving all their pages (e.g.document formats) and(b) present the individualpages of library objects to the user (e.g. collectioncontents).

9

A response time delay is introduced when theMCM forwards mobile client requests to the dataserver. Consequently, acaching mechanismwasdeveloped to reduce this delay. The MCM’scaching mechanism stores library objects receivedfrom the data server. Library objects are assigned aparticular TTL within the cache.

When a mobile client requests a digital objectthrough a personal library service, the MCM veri-fies if a session has been previously established. Ifa session exists, the MCM’s cache is checked fora copy of the digital object. If the cache containsthe object (cache hit), the object format is adaptedfor its transferral to the mobile client and handedover to the pagination mechanism, which interactswith the mobile client to transfer records or seg-ments (i.e. pages) of the object adjusting the rateof data exchange according to the wireless networkstate. If the MCM’s cache does not contain the ob-ject (cache miss), the MCM forwards the requestto the data server, caches the response, converts thedigital object to the format expected by the mobileclient and sends the requested object to the clientat transfer rate dynamically adjusted after wirelessnetwork state.

Although the MCM pagination and cachingmechanisms improve the interaction between mo-bile clients and the data server, wireless networkvariability must be considered to enhance user ex-perience. For this purpose, aconnection adapta-tion mechanism to dynamically adjust the size ofpage requests according to connection bandwidthwas implemented on the client side. The connec-tion adaptation mechanism is largely based on thecaching and pagination mechanisms. The purposeof connection adaptation is to vary the size of re-quested page according to network state to obtainan Expected Response Time (ERT). The result ofthis mechanism is a constant navigation rate andconnection aware document retrievals.

Connection adaptation is achieved by weightingcurrent network state (i.e. the response time of thelast page request) against a moving average of pre-vious requests. To perform connection adaptation,we use the exponentially-weighted moving average(EWMA) [7] formula:

τi+1 = αti + (1− α) τi (1)

Where:

• τi+1 is the newly estimated page size.

• α, calledgain, is the importance of the currentnetwork state,0 < α ≤ 1.

• ti is the current page size observation.

• τi is the prior page size estimate.

In order to estimate mobile network state, it isnecessary to define a unit of measurement for pagesize. The current prototype considers two page sizeunits according to the library objects under pagina-tion: (a) collectionpage size is measured in contentrecords (i.e. references to child collections and/ordocuments); and(b) document formatpages aremeasured in bytes.

In order to maintain a constant response time,page size is estimated using Equation 2:

Ri+1 =ERT ∗Ri

ti(2)

Where:

• Ri+1 is the page size to be sent in requesti+1.

• ERT is the Expected Response Time.

• Ri is the page size of requesti.

• ti is the time it took to receive a page of sizeRi.

The result of Equation 2 is used as theti of Equa-tion 1 in order to calculate the page size of thenext page request of collection objects. In docu-ment object retrievals,Ri represents the amount ofbytes that were transmitted in timeti, andRi+1

is the number of characters that will be requestedin the next petition. The knowledge of receivedpage indexes allows the mobile client to resumethe retrieval of document objects despite mobileclient disconnections. To accomplish dynamic ad-justment of document page size, the MCM issues aping request to the data server and measures returntime to estimate connection status. Once this sam-pling is done, the MCM requests the document tothe data server, stores the document into its cacheand lastly, the MCM sends the document to themobile client through the pagination mechanism.Document retrieval is performed in a low prioritythread.

The performance of connection adaptation in oursystem was tested in the context of two experimen-tal environments:

10

Figure 9: MCM Connection Adaptation

1. Controlled environment. The amount of mo-bile devices in the wireless network is limitedand well known. The experiments in this envi-ronment were made in an office with five de-vices sharing the same communication chan-nel simultaneously.

2. Uncontrolled environment. The amount ofmobile devices in the wireless network is un-controlled. The experiments were made in awireless campus network where most usersare students, faculty, and staff using Wi-Ficonnectivity from wireless laptops, handheldcomputers, and other wireless devices.

Experimentation results are summarized in Fig-ure 9, which shows that page size varies accordingto network state (topmost series) while preservinga constant response rate (lowermost series). Fig-ure 9 is the result of an experiment which con-sisted of ten requests. Each request obtained thenext page of the digital object. Experiments be-gan with a5 record page size and fixed values ofERT = 2 seconds andα = 0.5. The fixed valueof the ERT allows the mechanism to estimate thepage size which is required to preserve the ERT,using Equation 2. The value ofα was chosen af-ter experiments performed in [6] which show thata fixed value ofα = 0.5 minimizes the time differ-ence between request response time and the ERT.

Figure 9 presents the behavior of the mechanismin both experimental environments. In the con-

trolled environment (dashed lines), the page size islarger than in the uncontrolled environment (solidlines). Thus, reflecting that network capacity is be-ing exploited by the connection adaptation mech-anism, achieving a constant response time in spiteof network conditions. Figure 9 shows that, in boththe controlled and the uncontrolled environment,a similar constant response time is obtained (thisparticular experiment reported a0.02 cumulativedifference between the two environment responsetimes). Therefore proving that a constant responsetime is effectively preserved by the connectionadaptation mechanism in both environments. Inaddition, observed response times present a slightvariation from the reference ERT.

3.4 Data Server

The data server provides the services of a personaldigital library, stores personal digital library dataand supports interoperability via the OAI-PMH [5].The data server provides the following functional-ity:

• Personal Library Services. The data serveroffers creation, retrieval, update and deletionoperations over the library objects stored inthe personal data storage (collections, docu-ments and metadata). The data server alsoprovides services to copy and move docu-ments or collections, search for documents in

11

a personal library, send documents to the per-sonal library of other users, email documentsto any user with an email account, performdocument format conversion, change collec-tion metadata sets, edit document metadataand grant or revoke permission rights overpersonal library content.

• Personal Data Storage. It provides struc-tured storage with scalable information re-trieval capabilities for personal digital li-braries. An information retrieval (IR) tool(a.k.a. search engine) is used to index per-sonal digital library content. A database isused to store the objects of the personal digitallibraries since we require a structured modelto represent personal library objects and therelations among them. The IR tool indices al-low fast random access to words within theindexed content and are used to find informa-tion stored in the database. The usage of a textsearch engine and a database in the data serverpermit the combined use of text-based queriesand SQL datatype-based queries to supportthe hierarchical classification of personal li-brary content. The hierarchical classificationcan greatly improve query performance sinceit allows queries to be specified against docu-ments contained in individual collections withor without the inclusion of their nested collec-tions to the scope of the query.

• Communication Backbone. Establishes acommunication backbone with other dataservers.

• OAI-PMH Support . The data server exposesthe metadata of the personal digital librarydocuments via the OAI-PMH [5]. In addi-tion, the data server harvests metadata of otherOAI-PMH compliant library systems to pro-vide users with a subset of the personal digi-tal library services to interact with other (OAI-PMH compliant) library systems.

3.5 Implementation

One of the most significant problems discussedwhile deciding which technologies were to be usedin the implementation of PDLib, was deciding onusing platform independent technologies againstplatform specific technologies. The selection of

platform independent technologies allowed us toconcentrate development efforts in a single lan-guage prototype implementation. For this reason,we decided to use Java as the programming lan-guage and platform. There are Java virtual ma-chines available for most desktop (e.g. Linux, Win-dows, Macintosh) and (e.g. Palm, Windows CE)mobile platforms. In addition, the availability ofdevelopment APIs written in Java helped the imple-mentation of the PDLib prototype. Consequently,PDLib mobile clients were developed using J2MEwhile the data server, MCM and application clientswere developed using J2SE.

The mobile client was developed using theCLDC/MIDP stack of the J2ME platform. In par-ticular, we use IBM’s J9 virtual machine [8]. TheJ9 virtual machine is available for a great diversityof mobile platforms (Palm OS, Windows CE, Sym-bian, Linux) with which we hope to cover a major-ity of the devices that are on the market.

The data server, the MCM and our applicationclients have been developed using J2SE and there-fore can run in any operating system that has animplementation of the Java Virtual Machine.

As of the writing of this paper, the following pro-totype implementations of PDLib components havebeen developed:

• A mobile thick client application: PDLib Mo-bile Client. TheMobile Clientapplication al-lows the user to:1. Glance through the con-tents of his/her personal digital library (Fig-ure 2 (a));2.Retrieve and store a local copy ofselected digital library documents on the mo-bile device;3.Manage her/his personal digitallibrary by: i. Moving/copying documents orcollections andii. Setting access rights to doc-uments or collections (Figure 2 (b));4. Sharetheir digital library content by: i. Sendingdocuments via email andii. Sending a doc-ument to another PDLib user (Figure 2 (b));5. Search for documents in her/his personaldigital library (Figure 2 (c)); 6. View andedit document metadata (Figure 2 (d)); and7. Browse the contents of other users’ per-sonal digital libraries. The prototype imple-mentation of PDLib’s Mobile Client has beendeveloped using CLDC/MIDP J2ME (Fig-ure 2) The mobile client communicates withthe MCM via the XML-RPC protocol librariesof the Java/XML Enhydra Application Server.

12

• Web Front-end. (a.k.a. PDLib Web Client)The Web Front-end was developed usingJava Servlets, Cascading Style Sheets (CSS),HTML and WML. The Web Front-end veri-fies the display capabilities of the requestingbrowser and answers accordingly (e.g. serv-ing a WML page instead of HTML if the re-questing browser is incapable of displayingHTML) (Figure 3). The Web Front-end runson the Tomcat servlet container.

• MCM (Mobile Connection Middleware). TheMCM interacts with the Mobile Client to pro-vide the following connection support ser-vices: (a) Session handling over the statelessXML-RPC protocol; (b) A constant collec-tion navigation response time despite the con-nection variability of wireless connections;(c) Back navigation speed up thanks to thecaching of query responses received from thedata server; and(d) Reliable document trans-fers over the mobile network through:1. Con-nection aware document partitioning,2. in-dependent transfers of document segmentsand 3. session support for document trans-fers. In the current implementation, the MCMservices are accessed via XML-RPC. TheApache XML-RPC implementation is used toprovide the services.

• Data Server. PDLib’s Data Serverprovidespersonal digital library content storage andretrieval services. The prototype implemen-tation of the Data Server supports the cre-ation, retrieval, update and deletion opera-tions over the library objects stored in the per-sonal data storage (collections, documents andmetadata). The data server also provides ser-vices to copy and move documents or col-lections, search for documents in a personallibrary, send documents to the personal li-brary of other users, email documents to anyuser with an email account, change collec-tion metadata sets and edit document meta-data. The data server implementation ex-poses the metadata of the personal digital li-brary documents via the OAI-PMH [5] andharvests metadata of other OAI-PMH compli-ant library systems in order to allow PDLibclients to browse their contents. The prototypeimplementation of the data server has beencreated using J2SE. MySQL is used to store

all personal digital library data [9]. We arecurrently working to incorporate the Lucenefull-text search engine [10] to improve perfor-mance and reduce index storage requirements.

• A fixed client application: The PDLib BeUp!Bin. TheBeUp! Bin is a prototype client ap-plication that uploads files to a special col-lection where all unclassified documents arestored. The current implementation of thisapplication supports the addition of files via“drag-and-drop” operations, the queueing ofupload requests and direct file selection. TheBeUp! Bin is an example of an applicationclient with direct access to the Data Server(as explained earlier in this section). Theapplication communicates directly with thePDLib Data Server using the Apache XML-RPC client library.

4 Related Work

This section compares our universal access archi-tecture for digital libraries with other architecturalapproaches used by search and retrieval systems.In addition, a comparison of our mobile connec-tion support mechanisms with related work in thefield is provided.

Our universal access architecture for digital li-braries can be roughly described in terms of its dis-tribution architecture as a client/server architecturewith two novel features:1. Support for multipledevice access in the client side; and2. Inter-serverdata communication. According to their distrib-ution architecture, present distribution approachesof search and retrieval systems could be classifiedas: A. Client-side Systems. Provide personaliza-tion services to the user’s interface (i.e. the clientside) with the system.Personalization servicesinthe client-side allow users to tailor their interactionwith distributed search and retrieval systems and/orthe WWW Some examples of client-side systemsare found in [11, 12, 13, 14, 15, 16]. The imple-mentation of client-side personalization services isnot restricted to the user’s local system.B. Peer-to-peer Systems. Search and retrieval services areprovided by the client/server nodes of a distributedpeer-to-peer network. All nodes run an identicalsoftware implementation. A Web-based peer-to-peer digital library design and prototype implemen-tation for desktop computers is provided in [17].

13

A peer-to-peer digital library initiative that seeksto provide an alternative to centralized search andretrieval systems can be found in [18].C. Mid-dleware Systems. Under this approach, search,retrieval and storage services are provided to theuser by a mediation environment. The actual dataof the individual user comes from heterogeneousdata sources registered at the mediation environ-ment. The mediation environment maps the con-tent of heterogeneous data sources to a user-definedschema [19]. D. Server-side Libraries. Search,retrieval and storage are provided by the serverinfrastructure of the system. The server-side ap-proach is specially suited to support access frommultiple device types. PDLib [4, 20], the testbedof this research, provides server-side personal dig-ital libraries.

Next, we compare the mobile connection sup-port provided by the Mobile Connection Middle-ware (MCM) of our universal access architecturewith other work in mobility support:A. Trans-action Support. Works such as CODA [21],Bayou [22], DAgora [23] and Rover [24] fall withinthis category. Both the MCM’s connection sup-port mechanisms and the mentioned work all striveto preserve transaction/operation state while pro-viding temporary storage for offline operation, theMCM’s connection support approach differs fromprevious transaction support approaches in the factthat it was designed for devices with limited re-sources and low memory availability (e.g. mo-bile phones, PDAs), whereas the mentioned workwas intended for devices without stringent com-puting resources limitations (e.g. desktop comput-ers). B. Adaptation Middleware. Works such asOdyssey [25] and iMASH [26] fall within this cat-egory. Odyssey presents a middleware for dynamicadaptation of communication between mobile de-vices and data servers. However, Odyssey’s com-munication adaptation is based in the fidelity of adigital file to perform connection adaptation whileMCM’s connection adaptation mechanism followsa connection aware pagination strategy. iMASHwas designed as a transaction manager for mobiledevices. Conversely, our approach is to store in-complete transactions in the mobile client, whichis responsible for resuming them once connectiv-ity is regained.C. Data Access from Mobile De-vices. Prior work in this area includes PoP’s [27].PoP’s presents a model with which a mobile deviceis capable of accessing the information of a digital

library via a Web browser. However, the thin clientarchitecture of Web browsers is incapable of per-forming mobile connection adaptation as requiredby the mobile user.

5 Conclusions andFuture Directions

We have presented a universal access architecturefor digital libraries. We have implemented ourapproach to universal access in our testbed sys-tem: PDLib. The main components of the archi-tecture are the Client-Side Applications, the DataServer and the Mobile Communication Middle-ware (MCM). The Client-Side Applications targetmobile and fixed devices and depending on thedevice digital library services are adapted. TheData Server supports the services for data storage,indexing and retrieval of information from users.The MCM is an intermediary between mobile de-vices and the Data Server and provides functional-ity for mobile connection support, such as:(a) Ses-sion support over the stateless XML-RPC proto-col, (b) pagination of query responses and docu-ment transfers,(c) query result caching and(d) au-tomatic connection adaptation. Regarding auto-matic connection adaptation, we have obtained aneffective constant response rate regardless of net-work conditions. A mobile software client thatbenefits from these mechanisms was described andsupplemented with implementation notes showinghow—despite the limited computing resources ofmobile devices—it can interact with a data serverthat has not been designed to support client mo-bility via adaptation techniques implemented in amiddleware. A proof-of-concept prototype imple-mentation that exemplifies these concepts has beendeveloped. Furthermore, we consider that our uni-versal access architecture could be considered asa reference for other universal access applicationswhere(a) distributed and efficient access to data,(b) device independence,(c) distributed search ca-pabilities and(d) interoperability with other sys-tems are required.

PDLib is an ongoing research and developmenteffort where interesting challenges related to dig-ital libraries and mobile computing are presentedand is being extended and improved towards anopen-source release. We are currently workingon the following research topics:(a) Scalability.

14

A personal digital library system must cope withan increasing number of mobile users that willdemand a large amount of distributed storage re-sources to hold an even greater quantity of per-sonal data objects (e.g. documents);(b) Mobileperformance and availability. We are conduct-ing efforts to support digital library services dur-ing offline operation in mobile clients. In addi-tion, caching and prefetching techniques that canimprove performance of mobile devices accessingdigital library objects are also topics of interest forour work;(c) Content adaptation. Content summa-rization and visualization methods of digital libraryinformation on limited screen size devices are be-ing explored could provide an added value to mo-bile clients of our personal digital library system;and(d) Interoperability. In addition to the currentfunctionality there is the opportunity for exploringfurther interoperability with the OAI-PMH [5] andother search and retrieval systems like web searchengines.

Acknowledgements

We would like to thank Adan Salinas, Luis Hur-tado, Miguel Escoffie, Eugenio Flores, MiguelArellano, Marcos Guevara, Manuel Deschamps,Eduardo Álvarez and Andrés Ornelas for their sup-port in the elaboration of this paper. To all of themour most sincere gratitude.

About the Authors

Francisco Álvarez Cavazos is currently a Ph.D.candidate studying at ITESM, Campus Monterrey.He holds a B.Eng. (Hons) in Systems Adminis-tration from FIME-UANL and an M.Sc. (Hons)in Information Technology from ITESM. Hisresearch interests include object-oriented softwareengineering, distributed databases and informationretrieval. He is particularly interested in scalabledistributed storage and efficient retrieval of per-sonal library content.

Roberto García Sánchez is currently an Analyst Sr.for GE Transportation as part of the AircraftEngines RTS support team. He holds a B.Sc. inComputing from ESIME-IPN and an M.Sc. inInformation Technology from ITESM. His mainresearch interest is in distributed systems and

mobile computing.

David A. Garza-Salazar received his B.Sc. (Hons)in Computer Science from ITESM, Campus Mon-terrey. He received his Ph.D. degree in ComputerScience from Colorado State University. Currently,he is a Full Professor and Director of Research andGraduate Program in Information and ElectronicTechnologies at ITESM, Campus Monterrey. Hisresearch interests include parallel computing,compilers, distributed systems, operating systems,digital libraries and mobile computing. He is amember of the ACM, the IEEE Computer Societyand the Phi Kappa Phi Honor Society.

Juan C. Lavariega received his Ph.D. degree inComputer Science from Arizona State University.Currently, he is an Associate Professor at theInformatics Research Center at ITESM, CampusMonterrey. His research interests include specifi-cation methods in software engineering, databasessystems, object-oriented databases, web servicesand mobile computing. He is member of theMexican National Researchers System, the ACM,the IEEE Computer Society and the Upsilon PiEpsilon Honor Society.

Lorena G. Gómez received her Ph.D. degree inComputer Science from Arizona State University.She is an Assistant Professor at the InformaticsResearch Center at ITESM, Campus Monterrey.Her general areas of research are databases andsoftware engineering. She is currently teachingcourses in data warehousing, databases and object-oriented analysis and design.

Martha Sordia Salinas is an Assistant ResearchProfessor and Industrial Consultant at the Informat-ics Research Center at ITESM, Campus Monterrey.Her research interests include information retrievalsystems, digital libraries, data bases, software en-gineering and programming languages.

References[1] S. K. Madria, M. Mohania, S. S. Bhowmick, and B. Bhar-

gava, “Mobile data and transaction management,”Infor-mation Sciences—Informatics and Computer Science: AnInternational Journal, vol. 141, no. 3–4, pp. 279–309,2002.

15

[2] E. Pitoura and G. Samaras,Data Management for MobileComputing, vol. 10. Kluwer Academic Publishers, 1998.

[3] D. A. Garza-Salazar, J. C. Lavariega Jarquín, andM. Sordia-Salinas, “Information retrieval and administra-tion of distributed documents in internet. the phronesisdigital library project,” inKnowledge Based InformationRetrieval and Filtering from the Web(W. Abramowicz,ed.), ch. 3, pp. 53–73, Boston, MA: Kluwer AcademicPublishers, November 2003.

[4] F. Alvarez-Cavazos, D. A. Garza-Salazar, J. C. Lavariega-Jarquin, L. G. Gomez, and M. Sordia, “Pdlib: Personaldigital libraries with universal access,” inJCDL ’05: Pro-ceedings of the 5th ACM/IEEE-CS joint conference onDigital libraries, (Denver, CO, USA), pp. 365–365, ACMPress, New York, NY, USA, July 07–11, 2005.

[5] OAI, “The open archives initiative.” Website, October2004. URLwww.openarchives.org/ , accessed Oc-tober, 2004.

[6] R. Garcia-Sanchez, “Connection adaptation techniquesfor mobile clients that access digital library services,”Master’s thesis, ITESM, Campus Monterrey, December2004. Available in Spanish.

[7] M. Kim and B. Noble, “Mobile network estimation,” inProceedings of the Seventh Annual Conference on MobileComputing and Networking, pp. 298–309, July 2001.

[8] K. Gilhooly, Using WebSpere Studio Device Developer toBuild Embedded Java Applications. ibm.com/reedbooks,first ed., April 2004.

[9] MySQL, “The world’s most popular open source data-base.” Website, 2004. URLwww.mysql.com/ , ac-cessed October, 2004.

[10] Lucene, “Jakarta lucene is an open source project avail-able for free download from apache jakarta.” Website,2004. URL jakarta.apache.org/lucene/ , ac-cessed October, 2004.

[11] M. Theobald and C.-P. Klas, “BINGO! and Daffodil: Per-sonalized exploration of digital libraries and web sources,”in In 7th International Conference on Computer-AssistedInformation Retrieval (RIAO 2004), Test, 2004.

[12] W. C. Janssen and K. Popat, “Uplib: a universal personaldigital library system,” inProceedings of the 2003 ACMsymposium on Document engineering, pp. 234–242, ACMPress, 2003.

[13] D. L. Hicks and K. Tochtermann, “Towards support forpersonalization in distributed digital library settings.,” inDELOS Workshop: Personalisation and RecommenderSystems in Digital Libraries, 2001.

[14] M. D. Giacomo, D. Mahoney, J. Bollen, A. Monroy-Hernandez, and C. M. R. Meraz, “Mylibrary, a person-alization service for digital library environments,” inDE-LOS Workshop: Personalisation and Recommender Sys-tems in Digital Libraries, 2001.

[15] L. N. Cassel and U. Wolz, “Client side personalization.,”in DELOS Workshop: Personalisation and RecommenderSystems in Digital Libraries, 2001.

[16] C.-C. Hsu, F.-C. Tseng, J.-M. Chen, and C.-H. Chang,“Constructing personal digital library by multi-search andcustomized category,” inProceedings of the Tenth IEEEInternational Conference on Tools with Artificial Intelli-gence, pp. 148–155, November 1998.

[17] S.-U. Guan and X. Zhang, “Design and implementation ofa web-based personal digital library,”Journal of the Insti-tution of Engineers Singapore, vol. 44, no. 3, pp. 59–77,2004.

[18] Old Dominion University Digital Library Group, “Freelib:Peer-to-peer digital library.” Website, March 2005.p2pdl.cs.odu.edu/ .

[19] D. O. Briukhov, L. A. Kalinichenko, and N. A. Skvortsov,“Personalization through specification refinement andcomposition,” inDELOS Workshop: Personalisation andRecommender Systems in Digital Libraries, 2001.

[20] PDLib, “The personal digital li-brary project.” Website, August 2005.URL copernico.mty.itesm.mx/pdlib/ , ac-cessed August, 2005.

[21] M. Satyanarayanan, “The evolution of coda,”ACM Trans-actions on Computer Systems, vol. 20, pp. 85–124, May2002.

[22] A. Demers, K. Petersen, M. Spreitzer, D. Terry,M. Theimer, and D. Welch, “The Bayou Architecture:Support for Datra Sharing Among Mobile Users.,”In Pro-ceedings of IEEE Workshop on Mobile Computing Sys-tems and Applications, pp. 2–7, December 1994.

[23] N. Perguiça, L. Martins, J. Domingos, and J. Simão,“Flexible data storage for mobile computing,”ACM SAC’99, 1999.

[24] A. Joseph, J. Tauber, and M. Kaashoek, “Mobile comput-ing with the rover toolkit,”IEEE Transactions on Comput-ers, February 1997.

[25] B. D. Noble, M. Satyanarayanan, D. Narayanan, J. E.Tilton, J. Flinn, and K. R. Walker, “Agile application-aware adaptation for mobility,” inProceedings of the six-teenth ACM symposium on Operating systems principles,pp. 276–287, ACM Press, 1997.

[26] R. Bagrodia, T. Phan, and R. Guy, “A scalable, distribuitedmiddleware service architecture to support mobile inter-net applications,”Wireless Networks, vol. 9, pp. 311–320,2003.

[27] N. Castellanos and J. Sánchez, “Pops: mobile access todigital library resources,”Proceedings. 2003 Joint Con-ference on Digital Libraries, 2003.

16