21st Australian Software Engineering Conference

Middleware for Social Networking on Mobile Devices Daniel Brooker, Thomas Carey Department of Electrical and Computer Engineering University of Auckland Auckland, New Zealand Email: dbro147,[email protected]

resourced in terms of processing power, memory, screen estate, and network connectivity, than their predecessors. Furthermore, smart phones often have extra hardware, like cameras, GPS, and compasses, built in. Concerning network access, multihoming is now commonplace, allowing a smart phone to connect to multiple networks, including 3G, WiFi and Bluetooth. With multihoming, a smart phone has many ways of connecting to the Internet and peripheral devices. Interest in social networking and smart phones has largely been orthogonal. In this paper, we are concerned with developing middleware that allows applications of a social networking style to run on smart phones. Without additional infrastructure, smart phone features are redundant since users fall back on conventional calling and texting. While calling offers real-time communication, it is necessarily synchronous – requiring participation of two users at the same time. Calling is also relatively expensive, being dependent on the use of a cellular network. Texting offers support for asynchronous communication, but lacks guarantees for timely communication. Both calling and texting offer limited forms of communication that do not exploit the potential of smart-phones as pocket computers. To help motivate the use of smart phones in a social networking setting, consider an application to support a community of friends – raising awareness of group activities, user activities and locations. A user might, for example, suggest that the group meet for lunch. In proposing a date and time, the user might use knowledge of what individuals are doing and where they are. If such knowledge is not certain, the application might infer individuals’ likely availability. Using the application, the lunch proposal is broadcast to all members and individuals may indicate their interest in the event, with this being made known to other group members. At the lunch destination, those who arrive are able to see who else has arrived, how far others are from the venue and whether they are traveling in the direction of the venue. The above example illustrates the need for context awareness, timely communication and accessibility of information relating to individuals. Meeting these requirements is challenging where smart phones are being used. Smart phones have a limited power supply that rapidly diminishes with use; once exhausted, the device is unable to represent its user

Abstract—Two significant but independent trends in recent years are the popularity of social networking applications and the adoption of mobile devices, notably smart phones. The current generation of smart phones are pocket computers that, compared to their predecessors, are relatively well resourced. Existing support for social networking tends to take the form of Web-based applications that are accessed from the desktop. Our interests are in leveraging today’s smart phone as a platform for hosting social networking applications. To this end we have developed a middleware solution that includes i) communication and service hosting infrastructure and ii) a context-aware framework. The infrastructure resolves challenges encountered when hosting services on 3G networks offered by mobile network operators. In addition, the middleware includes mechanisms to promote application scalability, availability, and responsiveness – and generally conserves smart phone resources such as power supply and network bandwidth. The context-aware framework is extensible and allows an open-ended set of context items and context sources to be managed. This framework allows context data, such as user location and activity, to be propagated around a user community. Performance experiments have validated the middleware, demonstrating that it can satisfy the requirements for scalability, availability, and responsiveness. A small user study has confirmed interest in the use of mobile devices to deliver social networking services; the study has also raised concerns – in particular security and privacy – relating to the platform. Keywords-social networking, smart phones, middleware, context-awareness.

I. I NTRODUCTION Social networking is concerned with building online communities of people engaged in common interests and activities. Well-known social network services, for example Facebook, Flickr and Twitter, tend to be Web-based and accessed using desktop technology. Using such services, people have become much more open to sharing information with friends and increasingly the world at large. In parallel with the emergence of social networking services, there has been increasing adoption of mobile devices, in particular “smart phones”. Smart phones have freely available SDKs that promote third-party application development. Notable examples of smart phone operating systems with such APIs include Google’s Android, Symbian OS, and Apple’s iPhone OS. Today’s smart phones are much better 1530-0803/10 $25.00 © 2010 IEEE DOI 10.1109/ASWEC.2010.13

Ian Warren Department of Computer Science University of Auckland Auckland, New Zealand Email: [email protected]

202

in a social network. For much of the time, a smart phone’s connectivity will be through a cellular network, which offers relatively low bandwidth and is prone to intermittent connectivity. Such connectivity may affect the rate at which information can be communicated with the group. While smart phones have considerably more processing resources than their earlier counterparts, these resources nevertheless remain limited. As a group expands its membership, more work may be generated for individuals’ devices. This paper is organised as follows. In Section II, we briefly review existing applications that offer support for social networking. In Section III, we present an overview of our base middleware for developing and hosting mobileservice applications. The work we focus on in this paper, and described in Section IV, builds on the base middleware by i) enhancing the middleware to better meet the needs of social networking applications and ii) introducing a context-aware framework for gathering, processing and disseminating context data. In Section V we report on an application developed to demonstrate the new middleware, in addition to a performance evaluation and a small user study concerned with determining interest in mobile social networking. Finally, in Section VI, we conclude and identify avenues for further work.

2) Loopt: Loopt is a US-based mobile application. Similarly to Latitude, Loopt allows users to see friends’ locations on a map or as a list. Loopt maintains a diary-like “whereabouts” journal [1] that tracks users’ locations over time. Loopt also has features for synchronising users’ locations with Facebook and Twitter. Similarly to Latitude, users must take responsibility for manually updating their location and must have the Loopt application open in order to do so. To request that a particular user updates their location, Loopt allows some other user to do so with the result that a text message is sent to the user whose locations is required. This user may or may not act on the request. Also like Latitude, Loopt allows users to conceal their location – simply by choosing not to publish it – or to restrict their location to specified friends. 3) Whrrl: Whrrl, similarly to Loopt, is based on a whereabouts journal. With Whrrl, all journal entries are manual; users can set their location, take a picture, write a note, and set a privacy level. Users can also upload entries to Facebook, Twitter, or whrrl.com., where others can view the user’s “story”. Whrrl is distinguished from Latitude and Loopt in that with Whrrl, users can see, on a map, what is happening as it happens around them. In this way, Whrrl allows context data other than location to be made available. III. M IDDLEWARE FOR MOBILE SERVICES

II. E XISTING APPLICATIONS FOR SOCIAL NETWORKING

Mobile service provisioning is concerned with hosting services on mobile devices. Such mobile services can be consumed by clients, mobile or otherwise. The transformation of mobile devices from simple clients that access services on the fixed network to servers that host services is significant. Mobile services can offer new kinds of services that exploit the inherent mobility of the host device. For social networking, an application running on a smart phone can be exposed as service. The service can then make available to any interested parties context information on demand. Our solution [2], [3] to mobile service provisioning is based on the Jini Surrogate Architecture (JSA) specification [4], shown in Figure 1. The JSA was developed to allow resource-constrained devices to participate in a Jini federation – a system of clients and services in a distributed network. Jini is a Java-based service-oriented middleware that provides infrastructure for service registration, discovery, and consumption. Without the JSA, many small devices are unable to participate in a Jini federation since they have insufficient local resources to run the Jini software. Using the JSA, a device-service, written in any convenient programming language, can be hosted on a device and exposed to the federation as a regular Jini service. A surrogate host (SH) plays the role of the intermediary and may contain many surrogate (proxy) entities, each representing a particular device-service. A device-service sends its surrogate to a SH as part of the surrogate registration protocol. Once the

Three current applications1 , which have some overlap with the kind of applications that we are interested in facilitating on mobile devices, are Google Latitude, Loopt, and Whrrl. While these applications offer support for some social networking features, they have in common that they lack mechanisms for propagating updates and the type of context information they tend to focus on is user location. 1) Google Latitude: Google Latitude is a Website that provides users with a Google Maps view that is annotated with markers. A marker indicates the last known location of a user’s friend. Using Google Latitude, users, with Google accounts, allow their location to be recorded. The recorded location can either be volunteered by the user or automatically detected, where possible. Google Latitude offers some support for privacy in that a user can restrict access to their location to a closed group of friends. In addition, a user can hide their location – and since a user can specify their location it is permissible for a user to provide deliberately false location. While Web-based, there are a number of smart phone applications that provide access to Latitude. In all cases, however, location updates are not propagated to interested users. Such updates are presented only when a Web page is (re)loaded or, in the case of smart phone applications when the application is initially opened. 1 The

survey of existing applications was conducted in May 2009.

203

Figure 1.

to be hidden from the clients. In addition to the HTTP interconnect, our middleware also includes a Bluetooth-based interconnect. The HTTP interconnect can be used over any TCP/IP network interface, such as Wi-Fi or 3G. The Bluetooth interconnect supports both the L2CAP and RFCOMM protocols, which are nonIP based, and can be used when a mobile device is within proximity of a Bluetooth-enabled SH. Presence of Bluetooth interconnect benefits mobile service provisioning in several ways. Though it has a lower bandwidth compared to WiFi/3G, it uses less power and thus enables mobile devices to be alive for longer periods of time [6]. In addition, it provides an alternate means of communication between device and its SH, thus improving service availability. All interconnects implement a uniform interface and provide a range of programming abstractions that include asynchronous messaging, synchronous method invocation and streaming [2]. To cater for typical use cases with mobile devices – involving intermittent and variable network connectivity – the middleware supports both proactive and reactive vertical handover between heterogeneous (for example Bluetooth and IP) interconnects [2]. Proactive handover is used to switch from one interconnect to another, with the intention that the new interconnect is preferable for reasons such as it offering increased bandwidth or reduced power consumption. Reactive handover is used to automatically switch to an alternative interconnect when the current one fails unexpectedly. In both cases, vertical handover preserves consistency by ensuring no loss or duplication of data. An emerging approach to mobile service provisiong being explored by others, for example Srirama et al. [7], involves the use of enterprise service bus (ESB) technology. An ESB is conceptually similar to an intermediary in our approach and both have the potential to address issues such as mobile service reachability, scalability and security. We direct the interested reader to Srirama’s work.

Jini Surrogate Architecture

SH activates the surrogate, it registers a service-object with Jini’s decentralised lookup service (LUS). Clients discover the service-object and use this to invoke the remote service; requests are actually sent to the surrogate, which may, depending on the request, communicate with the deviceservice. Communication between a device-service and its surrogate is handled via an interconnect. An interconnect may be implemented using any network protocol, such as IP, HTTP or Bluetooth. The JSA specifies how a device and a SH can discover each other, the surrogate registration process and how to determine liveliness between the SH and device. Liveliness is typically checked using a periodic heart-beat exchanged between the two parties. The JSA only describes the basic infrastructure and components necessary to enable resource constrained devices to expose Jini services. The reachability problem [5], which is fundamental to mobile service provisioning, is solved by an HTTP-based interconnect. Reachability covers both addressability and accessibility, the former being concerned with how to specify a mobile service as the destination for a service request, while accessibility deals with routing a request to a mobile service. Addressability is a non-trivial problem given the inherent mobility of services. Accessibility is difficult in practice when a service is hosted by a mobile network operator (MNO), since mobile networks generally block (client) traffic sent from outside of the network. Using our HTTP interconnect (illustrated in Figure 2), a device-service initiates a connection with its surrogate and periodically sends a heartbeat (keep-alive) message. The surrogate responds to the HTTP request by sending any pending client requests for processing. The results of the client requests are transmitted with the next heartbeat message. Hence, addressability is solved since the device-service is responsible for service/surrogate communication, and accessibility is no longer an issue because the communication, being initiated from within a MNO’s network, is not blocked. Therefore, use of HTTP interconnect enables devices to partake in mobile service provisioning independent of their MNOs. The SH and adherence to JSA protocols enable device mobility

IV. M IDDLEWARE FOR MOBILE SOCIAL NETWORKING Mobile social networking applications introduce additional requirements that can, in part, be appropriately met by an underlying middleware solution. We now articulate the requirements and then proceed with an overview of enhanced middleware that aims to satisfy these requirements. A. Requirements A mobile social networking application should generally be: • Available. Availability is a measure of the proportion of time that a system is able to provide service to users. Any infrastructure for mobile social networking should promote system availability and mitigate the problems associated with individual device availability.

204

•

•

•

•

•

Scalable. Scalability is concerned with a system being able to manage increases in users and resources. Infrastructure in support of social networking applications should manage groups of increasing size and associated information exchanges. The limited processing and networking resources of smart phones needs to be taken into account when considering scalability. Relevant. Context information, such as a user’s location, is subject to change, hence the value of a particular context item diminishes over time. In propagating context across a social networking application, changes in context information should be disseminated in a timely fashion. Furthermore, particular context items should only be presented to users who have an interest in that type of context information. Responsive. In addition to the need for timely propagation of context changes, social networking applications are also associated with soft real-time requirements concerning communication within a group. Responses to requests, for example, should be delivered without undue delay – despite the transient availability and connectivity of devices that may be involved in servicing requests. More generally, communication over a social network should be timely. Secure. Social networking is concerned with sharing information, but it may be that restrictions on who can see what should be supported. For example, a user may be agreeable for particular friends to see precisely where (s)he is, but other users should see only an approximation of the user’s location. Similarly, rather than presenting the particular activity a user is engaged in, they may prefer that their activity status is simply shown as “busy” [8]. Resource conserving. For much of the time, a smart phone participating in a social networking application will be connected over a 3G network. It is important that an underlying infrastructure recognises the monetary costs associated with such connections, and endeavours to conserve bandwidth use. Similarly, other resources of a smart phone, such as power supply, should be conserved.

Figure 2.

Communication between a pair of smart phones

1) Inter-surrogate communication and event mechanism: With the base middleware, surrogates are independent entities. Surrogates may be co-located within the same surrogate host or distributed. For social networking applications, where each surrogate represents a particular user, there is a need for the collection of surrogates that represent the community as a whole to discover and communicate with one another. The middleware has been enhanced with a discovery mechanism and a surrogate-to-surrogate communication protocol that allows the exchange of messages useful to support social networking applications. Part of the new protocol offers a publish/subscribe mechanism whereby surrogates can subscribe to events that may be generated by other surrogates. For example, where one user requests the location of another, the surrogate for the requesting user will subscribe to the other surrogate for location change events. Hence, for a maps application, for example, only one location request need be made and subsequent location changes will be reported automatically. This publish/subscribe mechanism serves to promote system responsiveness by avoiding alternative techniques, such as polling, that are also wasteful of (scarce) resources.

B. Middleware enhancement The base middleware, introduced in Section III, offers a solid foundation for addressing the above requirements. Fundamentally, and as discussed in Section III, the middleware solves the reachability problem. Figure 2 illustrates the exchange of messages in order for one smart phone (D1) to make a request of another (D2), with communication necessarily being routed through the requester device’s surrogate (S1) and the requestee’s (S2). In support of the requirements for social networking, the base layer has been enhanced in three ways.

2) Caching: The use of a surrogate offers a natural opportunity to introduce caching. Having surrogates maintain a cache, a copy of frequently accessed data, promotes availability in the event of i) loss of connectivity between a

205

smart phone and its surrogate, and ii) loss of operation of the smart phone – due to either the device being switched off by its user or the device’s power supply being exhausted. The introduction of caching means that if a surrogate is unable to contact the smart phone, the surrogate may be able to processing incoming client requests by drawing on cached data. Caching also brings benefit in terms of scalability. Where a smart phone is repeatedly sent similar requests from clients, the device’s surrogate need only send the first request to the device. The surrogate caches the reply that it receives from the device before relaying it to the requesting client. Subsequently, similar requests are processed directly by the surrogate based on cached data without the need to communicate with the device. This has the potential to offload much processing from the device, thereby conserving its processing, power, and bandwidth resources. Moreover, using the relatively well resourced surrogate, the system’s responsiveness and throughput can be enhanced.

C. Context framework The context framework, as shown in Figure 3, forms part of the middleware and is organised into a layered collection of modules. Each module exposes extensibility points in the form of interfaces. In addition, modules offer publish/subscribe interfaces allowing higher-level modules and application code to receive notifications.

3) Adaptive heartbeat mechanism: Where a smart phone is required to process a request (i.e. in the case where its surrogate’s cache lacks sufficient data to do so), the request is sent from the surrogate to the smart phone with the reply to the next heartbeat message sent by the device (as described earlier and shown in Figure 2). Hence, the responsiveness of processing the request is related to the frequency at which the heartbeat messages are transmitted. This is a configurable property of the base middleware. To conserve bandwidth and processing resources, the heartbeat frequency might be set at 3 minutes – and in the worst case processing of a client’s request would thus take 3 minutes with this setting. For social networking applications, a single fixed value for the heartbeat frequency is inappropriate – if too short, the device will drain it’s power supply prematurely, and if too long the device will not be responsive. An adaptive heartbeat mechanism has been developed that basically adjusts the heartbeat frequency according to the level of interest or activity in the device. In cases where a device is expecting notification or request messages to arrive, for example having just subscribed to context change events, the device’s middleware increases the rate at which heartbeat messages are sent. Similarly, once a device has received one or more messages over a short period, in anticipation of further messages the device again sends heartbeat messages at a relatively fast rate. The frequency of heartbeat messages ranges from 3 to 180 seconds. The delay in sending heartbeat messages doubles, until the upper bound is reached, with each second that no messages are expected/received; the delay drops to the lower bound after a message has been sent or received. The adaptive heartbeat mechanism aims to provide an effective compromise between responsiveness and resource consumption.

Figure 3.

Layered context framework

We take a general view of context, and define a context item to be any information that is relevant to the user. Typical context items include one’s location, the location of one’s friends, work schedules, events, time and even habits. Being extensible, developers can add new context items, for example movie schedules and photos taken by a camera-enabled device, as and when necessary. The current implementation of the framework includes context items relating to location and activity. For detecting user location, a number of techniques can be implemented. Within a wireless network environment, Kaasinen et al. [9] describe an approach based on tagging access points with GPS coordinates. If a user is using a particular access point, the GPS value of the access point gives a close approximation to the user’s actual location. Zu et al. [10] outline a scheme whereby a user’s location can be inferred from their calendar. In this case, if a user is expected to be in a meeting whose location is known, the user’s location can thus be inferred as that of the meeting venue. As Dey et al. [11] note, inference-based approaches naturally incur some ambiguity and so are generally associated with reduced confidence. We naturally detect location using the smart phone’s inbuilt assisted GPS capability. Essentially, this relies on a combination of cell tower triangulation, to initially gain an approximate position, and GPS, to obtain a more accurate location value. As Gupta et al. [12] point out, a raw context value often has to be abstracted in order to provide meaningful and relevant information to a user. A GPS coordinate, for example, is such a raw value that is unlikely to mean very much to a user. We offer two location abstractions – street

206

addresses and regions. Street addresses and building names are found, based on a GPS coordinate, through use of a reverse geo-coding algorithm. Regions are discussed shortly. 1) Context module: The Context module is essentially a repository for all contextual information. Plug-in components representing context sources generate context items and have them stored by the Context module. The Context module is also responsible for generating context events when the value of a context item changes. For example, when the user’s location changes an event is pushed upwards to all modules and applications that have registered interest in location changes. To process raw data, for example to translate a GPS coordinate item into a street address item, further plug-ins are used to manage such transformations. Yet more extension of the context module allows context data to be filtered for relevancy. 2) Social module: The Social module accesses the user’s address book, provided by the host device, and finds all of the users that are members of particular social networks. The Social module looks up each participant and queries their surrogate for information. Once the information has been received the Social module then provides the Context module with context information, such as location, relating to the participant. Essentially, the Social module serves as a context source for a user’s friends. 3) UI modules: The UI modules simply provide the application developer with standard user interface components that they can use to display contextual information. They serve both to demonstrate how to retrieve and present information from the context framework and, more importantly, as modules that can be reused to rapidly develop applications. 4) User Maps module: The User Maps module allows users to work with higher-level context items concerning location. A location region is a programmer- or userdefined abstraction of an area on a map. Location regions are currently rectangular areas that can be associated with meaningful names, such as home, work, and more generally activity venues. When a user is located within a particular location region, his/her location is reported using the meaningful name associated with the region. Furthermore, as a user changes his/her location within a region, location update events need not be propagated. As Tummala et al. [13] note, it is unnecessary to disseminate context updates where they are irrelevant or add no value. In the case of the User Maps module, this behaviour also contributes to resource conservation. Maps and location regions can be stored persistently on host devices, for user convenience and to conserve resources. 5) Maps UI: The Maps UI module provides a standard way of viewing and editing the location regions stored in the User Maps module. Application developers can use this module to create map regions or further extend the module for more refined Map Region input. Maps UI provides a

demonstration of how to actually interface with the User Maps Module if the application developer would prefer to create their own user interfaces. We note here for interest that current work by Acharya et al. [14] in context-based systems involves collecting and disseminating context data such that flexible user-defined queries can be constructed over aggregated data from different sources. Acharya et al.’s work is based on a presence virtualisation architecture where servers process customisable queries; in doing so context data is retrieved from an arbitrary number of servers and processed accordingly. D. Implementation As discussed in Section III, the fixed-network middleware is an implementation of the Jini Surrogate Architecture, and hence written in Java. For the smart-phone, we selected Apple’s iPhone, largely because of its availability and affordability. An existing device-side implementation of the JSA in Java was automatically translated into Objective-C, the programming language used to develop iPhone software, using a custom translator developed as part of our work. Currently, the iPhone imposes restrictions on how it can be used by application developers. One such restriction prevents use of background processes – necessary to implement the device-side middleware. A technique known as “jail breaking” is used to remove such restrictions. Maps downloaded to the Maps UI are from OpenStreetMap and are processed using an open-source library called RouteMe. Reverse geocoding uses the Google Maps API. The UI modules conform to Apple’s design principles for promoting usability and aesthetically pleasing user interfaces. V. E VALUATION Our approach to evaluating the middleware involved three activities. First, we developed applications to determine how easy the framework is to use and how effective it is in supporting rapid application development. Second, using a prototype application we conducted some experiments to help assess the extent to which the requirements, stated in Section IV are met. Third, we conducted a small user study to determine interest in social networking applications on mobile devices. A. Application prototype One of the applications developed, based on the motivating scenario of Section I, demonstrates a number of features required in a stereotypical social networking application. Figure 4 shows the application. Figure 4(a) shows that the application presents a list of context information that is implicitly ordered with the most recently updated information given at the top of the list. As context changes occur, being tracked and processed automatically by the underlying middleware, the list is shuffled accordingly. Each row presented can be selected to reveal more information about the entry.

207

For example, in Figure 4(b) further information about the last entry in Figure 4(a) is presented. To illustrate the maps and location region functionality, Figure 4(c) shows how individuals’ locations are presented to users. Location regions are created by pinching with two fingers the screen creating a rectangular region using the touch points as opposite corners of the rectangle. While the map is in “new region” mode, the map itself cannot be manipulated until a new region has been constructed. Any new region is then named and rendered as a semi-transparent red overlay. For added usability, regions can be selected with a single tap. This turns the region blue, and displays the region’s name in the top of the window. Subsequent to a region being created, any users detected within this region appearing on the context pages will have their locations named according to the region.

The results of this experiment are shown in Figure 5. Where the number of concurrent users is relatively small, below 200, caching has a positive impact on response time. Up to 200 users, use of the surrogate’s cache – instead of having to access the smart phone – reduces the response time significantly initially. As the number of concurrent users rises, the cache has a reduced impact and beyond 200 users response time increases in proportion to the number of concurrent clients. Cached
vs
Non‐Cached
Data
Response
Time


Time
(s)


Non‐Cached
Data


B. Performance

Cached
Data


45
 40
 35
 30
 25
 20
 15
 10
 5
 0
 0


100


200


300


400


500


600


700


120


140


Number
of
Concurrent
Users


In determining the effectiveness of the middleware, we ran three experiments. The first experiment was concerned with establishing a benchmark for service hosting, and involved hosting a service directly on a smart phone – without middleware support. The second and third experiments aimed to assess the value of the middleware in meeting some of the non-functional requirements. 1) Direct service hosting: An iPhone was set up to host a HTTP server running a simple Web application acquired from the iTunes store. To simulate load, JMeter, an established load testing tool, was used to generate an increasing volume of client requests. Since the MNO being used blocks all incoming connection requests over a 3G connection, a WiFi link was used to connect the device with JMeter. As the rate of connection requests approached 200 per minute, 51% of the requests were dropped. A similar test was conducted using a Powerbook G4 to run the Web application. In this case, the server successfully handled 93% of connections with connection requests coming in at a rate of 200 per minute. While the Powerbook scaled much better than the iPhone, the Powerbook is actually a low-end machine; dedicated Web servers can achieve significantly higher throughput still. In terms of hosting services using smart phones, the experiement shows that middleware is necessary to help satisfy the requirement for scalability. 2) Middleware performance: An experiment involved a single iPhone and a corresponding surrogate. Clients were simulated and each made different requests of the surrogate. Initially, the surrogate’s cache was empty, requiring the surrogate to communicate with the iPhone. Once all the clients had received responses, the test was repeated to determine the impact of caching. We ran this experiment several times, in each case with an increasing number of clients.

Figure 5.

Effect of caching on response time

JSA‐Server
CPU
Usage
 400
Users


200
Users


100
Users


100
 90


Percentage


80
 70
 60
 50
 40
 30
 20
 10
 0
 0


20


40


60


80


100


Time
(s)


Figure 6.

Load generated by surrogate creation and use

Beyond the clear benefits of availability, scalability and responsiveness that caching contributes to, caching also has a positive effect on a mobile device’s resources. At the load of 600 concurrent users making similar requests of the same surrogate for example, the surrogate would require service from its device once only. This saves bandwidth and conserves the device’s power supply but not having to route the other 599 requests to the device and their corresponding responses back to the surrogate. There are several reasons for the behaviour shown in Figure 5. First, the current implementation of the cache uses a mutually exclusive access scheme, effectively serialising client access. Second, the client load was simulated using one machine. Use of a single machine is not representative of realistic conditions since the arrival rate of client requests is reduced by the amount of context switching between client threads. Third, the surrogate implementation is a prototype that makes frequent disk access to log run-time information.

208

(a) Relevant context items

(b) Detailed view of an upcoming event

(d) Social network participants Figure 4.

(c) Map user interface

(e) Detailed view of a participant

Social networking prototype application

209

Notwithstanding these factors, the caching mechanism offers benefit for networks involving under 200 peers – and this is likely to be the case for many social networking applications. Furthermore, addressing the above factors would likely improve the effect of caching. The remaining experiment was concerned with measuring the processing required of a surrogate host to manage multiple surrogates. The experiment involved simulating batches of 100, 200 and 400 clients making requests of several surrogates residing in a single surrogate host. Figure 6 shows the results of this experiment. For each client batch, the graph shows a high rate of processor utilisation. This is accounted for by the need to create device surrogates prior to processing requests. Following surrogate creation, processor utilisation drops and often falls to near zero for all batches in between request processing. Hence, where a surrogate host supports surrogates that may be inactive for some of the time, it can host several surrogates simultaneously. For surrogates that place heavy load on their hosts, they can be distributed across multiple surrogate hosts.

One question we asked our participants was if they thought that a “location prediction” function would be useful. We explained location prediction with a simple example. Bob has been at work every Monday. On this particular Monday, the system could not get in touch with Bob’s mobile device. So the system examines historic context data maintained by Bob’s surrogate and is able to infer that Bob will likely be at work. The participants of the survey stated that this sort of prediction would be useful – but only if they were aware that the information was actually a prediction. This clearly indicates the need to have some sort of mechanism for showing the source and/or confidence of the information presented. From the survey we also found that people are willing to share contextual information provided that they have full control over privacy settings. Two users also highlighted the need for an ability to revoke the information rights of their peers, including the ability to remotely delete contextual information.

C. User Evaluation

In this paper, we have presented an overview of a middleware platform to support the development of social networking applications on smart phone devices. The middleware enables a smart phone to host a mobile service that provides service to both its local user and other participants of a social network. Each participant is represented by a readily accessible surrogate on the fixed network. Connectivity between a host device and its surrogate is realised using a HTTP interconnect, which overcomes the reachability problem associated with communicating with devices on mobile (3G) networks. The middleware has been specialised to suit applications of a social network style. Specifically, to strike a compromise between resource consumption and responsiveness, an adaptive heartbeat mechanism has been implemented. Over the HTTP interconnect, periodic heart beating is necessary for surrogate-to-device communication. The adaptive mechanism increases the rate of heart beating when there is greater ongoing activity in the device or when there is more (anticipated) interest in the device. The adaptive mechanism essentially improves application responsiveness. In addition, a caching mechanism has been added to the middleware, increasing scalability and availability. With caching, a surrogate caches data received from its smart phone. Caching contributes to increased scalability since many simultaneous client requests can be served by the cache – as opposed to burdening the smart phone and waiting for a response from this relatively poorly resourced device. For availability, caching masks the transient connectivity of smart phones. To propagate data, particularly context changes, across a social network, surrogates have been augmented with a distributed event mechanism. This contributes to responsiveness in that context changes can be communicated as they happen.

VI. C ONCLUSIONS AND FURTHER WORK

Our user study was centered around use of the application described above and a questionnaire whose aim was to gauge interest in mobile social networking. The study involved ten final year students. Initially, the participants were introduced to the application, running on an iPhone, and shown its functionality. For part of the demonstration, a separate client, representing some other user, was simulated on a laptop. The effect of the simulated client was to feed context data, namely changes in the simulated user’s location, into the system as a whole. The iPhone application subscribed to location change events of the simulating user and hence it updated its display. Study participants were also shown how to work with maps and how to create location regions. After experimenting with the application themselves, and working through some simple scenarios, participants were invited to complete a questionnaire. All participants said that they would like to be able to share different context items to different people. In addition, half of the participants said that they would share their precise location (such as ‘Room 303.279’) to selected people, while preferring to share only a rough location (such as Uni, or a suburb) with others. Interestingly, 40% of participants said that they would like to be able to share a false location to some contacts. These findings confirm the need for many levels of customization of the system. An interesting result from the survey was that students would find knowing the user’s last known location useful if, and only if, they were told that this was the case. In addition, the information was only considered useful if it was also coupled with its age, confirming that contextual information loses relevancy with time.

210

Beyond the middleware’s communication infrastructure, a context-aware framework has been developed. At the core of the framework is a context module that manages context items. This component is extensible with respect to context sources, context items and context processing. Currently, context sources include assisted GPS for location items, and surrogates for context information concerning other users of the social network. For context processing, we have implemented location transformation logic to present location information in a meaningful and useful form to users. A number of higher-level modules also form part of the context-aware framework; for example the Social module is concerned with identifying other participants and gathering context data concerning them. A set of reusable UI components provide for visualising context information. The middleware has been evaluated by building a number of social networking applications and through a series of performance experiments. The abstractions provided by the middleware to application developers allow applications to be constructed rapidly. User feedback supports the claim that context information is relevant and propagated sufficiently quickly. The performance experiments validate the surrogate-based middleware, particularly with regard to scalability and availability. To gauge interest in mobile social networking, we ran a small user study. Key findings from the study include that users want the ability to make available context data at different levels of granularity to different members of a social group. Users are also sensitive to the accuracy, age and source of presented data – and so users want to be aware of these attributes of context data. In terms of ongoing and future work, we intend to optimise the current middleware. The iPhone middleware implementation, being a translation of Java to Objective-C, does not exploit features of the iPhone/Objective-C platform. We believe the current implementation can be improved, for example by leveraging the iPhone’s event-driven architecture to reduce the number of threads required. An improved implementation would likely reduce power and memory consumption. The present caching mechanism can also be improved so that it continues to provide scalability benefits as the number of concurrent clients increases. Concerning context information, we are interested in adding the ability to reason about historical context data. Where this is cached in surrogates, the data can be used to make inferences when devices are unavailable and so unable to provide definitive information. In addition, we are now investigating the role of recommender systems in providing predictive capabilities, again based on analysis of historical context.

MiddleWARE, Operating Systems, and Applications. 2007, pp. 1–6.

ICST,

[2] A. Meads, A. Roughton, I. Warren, and T. Weerasinghe, “Mobile Service Provisioning Middleware for Multihomed Devices,” in Proc. 5th IEEE International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob’ 09). IEEE Computer Society, 2009. [3] T. Weerasinghe and I. Warren, “Empowering IntermediaryBased Infrastructure for Mobile Service Provisioning,” in Proc. IEEE Asia-Pacific Services Computing Conference (APSCC’ 09). IEEE Computer Society, 2009. [4] Jini Technology Surrogate Architecture Specification, Sun Microsystems Std., Rev. 1.0, 2001. [Online]. Available: https://surrogate.dev.java.net/doc/sa.pdf [5] J. Wikman and F. Dosa, “Providing HTTP Access to Web Servers Running on Mobile Phones,” Nokia Research Center, Technical Report, May 2006. [6] E. Ferro and F. Potorti, “Bluetooth and Wi-Fi wireless protocols: A survey and a comparison,” IEEE Wireless Communications, vol. 12, no. 1, pp. 12–26, 2005. [7] S. N. Srirama, M. Jarke, and W. Prinz, “MWSMF: a mediation framework realizing scalable mobile web service provisioning,” in MOBILWARE ’08: Proceedings of the 1st international conference on MOBILe Wireless MiddleWARE, Operating Systems, and Applications. ICST, 2007, pp. 1–7. [8] F. Girardin, “Bridging the social-technical gap in locationaware computing,” in CHI ’07: CHI ’07 extended abstracts on Human factors in computing systems. New York, NY, USA: ACM, 2007, pp. 1653–1656. [9] E. Kaasinen, “User needs for location-aware mobile services,” Personal Ubiquitous Comput., vol. 7, no. 1, pp. 70–79, 2003. [10] K. Xu, M. Zhu, D. Zhang, and T. Gu, “Context-aware content filtering & presentation for pervasive & mobile information systems,” in Ambi-Sys ’08: Proceedings of the 1st international conference on Ambient media and systems. ICST, 2008, pp. 1–8. [11] A. K. Dey and J. Mankoff, “Designing mediation for contextaware applications,” ACM Trans. Comput.-Hum. Interact., vol. 12, no. 1, pp. 53–80, 2005. [12] A. Gupta, A. Kalra, D. Boston, and C. Borcea, “Mobisoc: a middleware for mobile social computing applications,” Mob. Netw. Appl., vol. 14, no. 1, pp. 35–52, 2009. [13] H. Tummala and J. Jones, “Developing spatially-aware content management systems for dynamic, location-specific information in mobile environments,” in WMASH ’05: Proceedings of the 3rd ACM international workshop on Wireless mobile applications and services on WLAN hotspots. New York, NY, USA: ACM, 2005, pp. 14–22. [14] A. Acharya, N. Banerjee, D. Chakraborty, K. Dasgupta, A. Misra, S. Sharma, X. Wang, and C. P. Wright, “Programmable presence virtualization for next-generation context-based applications,” Pervasive Computing and Communications, IEEE International Conference on, vol. 0, pp. 1–10, 2009.

R EFERENCES [1] N. Bicocchi, G. Castelli, M. Mamei, A. Rosi, and F. Zambonelli, “Supporting location-aware services for mobile users with the whereabouts diary,” in MOBILWARE ’08: Proceedings of the 1st international conference on MOBILe Wireless

211