8/7/2019 paper519_519

1/14

Coalition: A Platform for Context-Aware Mobile Application Development

Jian Zhu, PengHe Chen, HungKeng Pung, Mohammad Oliya, Shubhabrata Sen, and WaiChoong Wong

National University of Singapore, Singapore

{g0500652, g0901858, dcsphk, oliya, g0701139, elewwcl}@nus.edu.sg

ABSTRACT

Context-awareness, as one of the key concept to achieve ubiquitous computing,has been widely applied in various mobile applications. The resulting adaptability,along with the usage of ubiquitous technologies, makes IT invisible and yet evercloser and seamless to peoples daily living. However, context-aware computinghas not yet found large success in the commercial area so far, and existing context-aware mobile applications are mostly sensor-based. We argue that a contextmiddleware is indeed necessary to help development and deployment of mobileapplications as well as managing the heterogeneous context data. In this paper, wepropose such a middleware named Coalition. More specifically, we demonstrate

how Coalition (i) facilitates mobility issues during mobile application execution;(ii) manages large number of application services as utilized or developed bymobile applications. The two features are explained through a case studySharingOf Living Experience (SOLE). In the end of the paper, we show the experimentalresults obtained from the prototype testing and simulation study.

Keywords: context middleware, mobile application, context data management,mobile space, mobile service mangament, experience sharing.

1 INTRODUCTIONThe rapid advances in the technologies of mobile

computing and wireless communications havebrought opportunities for various mobile applicationsrunning on handheld devices. Through enablingtechnologies (e.g. WiFi and 3G), mobile applicationusers may access services (e.g. mobile payment) andshare information at anywhere, anytime. Furthermore,along with the marked improvement in mobiledevice capabilities (e.g. CPU and memory), theprovision of services by these devices is promising.For instance, interactive photography can beachieved by requesting the mobile device (withcamera) owner to take a photo at real time. Theresulted mobile hosted application services (mobileservices for short) would potentially change thecurrent mobile application development landscape,by including the role of mobile service provider inthe provisioning of these mobile services.

To be more effective, applications running onmobile platforms should be aware of the user contextand adapt to any change occurred, e.g. in thesurrounding environment. For instance, consider ataxi booking application that filters search resultsbased on the user location and returns only therelevant results. Fortunately, the recent success ofubiquitous technologies, such as RFID tagging, GPSand wireless sensors, enables the detection andmonitoring of such contextual information. Context-awareness, as one of the key concept to achieve

ubiquitous computing [1], would make IT invisibleand yet seamlessly integrated with our daily living.

Our early work in this area include context

modeling and reasoning techniques [2], while ourrecent effort focuses on the development of a contextmiddleware known as Coalition to support context-aware (mobile) application development. Through itscontext data management layer, Coalition is capableof locating and extracting relevant context data fromlarge number heterogeneous data sources distributedover many different operating environments [3].Above the data management layer is its servicemanagement layer, which facilitates the organizationand discovery of services [4] via a method known as

Location Aware Service Organization and Discovery

(LASOD). Applications access the functions of datamanagement layer through its SQL-like context dataquery interfaces. Coalition supports the notion of

physical spaces. Each space has various affiliateddata sources (e.g. sensors and computing devices)whose contextual information, described by a contextdata model, could be accessed through a PhysicalSpace Gateway (PSG). A physical space can eitherbe static (such as a home) or mobile (such as aperson wearing body sensors and a mobile phone).With the use of mobile phones as PSGs, we caneffectively create a realistic large scale and yet lowcost testbed for further research in the field ofcontext-aware ubiquitous computing.

In this paper, we first investigate the design,integration and deployment issues of mobile

8/7/2019 paper519_519

2/14

applications in the Coalition environment. Morespecifically, we demonstrate how Coalition can beused as a platform to: (1) help the development ofcontext-aware mobile applications; (2) facilitatemobility issues during the application execution; (3)manage large number of (mobile) services as utilized

or developed by applications. In the second part ofthe paper, we will use Sharing Of Living Experience(SOLE) as a case study. SOLE will have real mobileusers playing the roles ofMobile Service Providers(MSPs) andMobile Service Consumers (MSCs). TheMSPs share experiences regarding real-world entities,while MSCs can access this information ubiquitously.The usage of Coalition for realization of context-awareness in SOLE is emphasized. In the end of thepaper, the performance of Coalition in supportingmobile application development is learnt throughsimulation studies and real-time tests.

The rest of this paper is organized as follows:

Section 2 presents the related work done in this area.Section 3 provides an overview of Coalitionmiddleware. Section 4 describes the extendedfeatures of Coalition to support context-awaremobile application development. Section 5 discussesour SOLE and its relationship with Coalition.Section 6 shows the performance measurement ofCoalition. Finally, Section 7 concludes the paper andhighlights our future work plan.

2 RELATED WORKAccording to a study commissioned by mobile

application store operator GetJar [5], the mobileapplication market will reach $17.5 billion by 2012.Besides the traditional mobile network operators andphone manufacturers, more and more independentand freelance developers are being involved in thedevelopment of mobile applications. Though thereare many mobile platforms (e.g. Symbian [6], iOS[7] and Android [8]) in the mass market, context-aware mobile computing has not yet found largesuccess in the industrial and commercial area. Thereare many reasons, and the two major ones include (1)the lack of effective and agreed methods or platformsfor seamless exchange and intelligent processing of

data among the heterogeneous context informationsources; (2) the under development of softwareengineering methodology for the management ofubiquitous applications and their related services.

Many context middleware systems have beenproposed in the last two decades, but there is verylittle discussion on context modeling and managingfor mobile entities. HiCon [9] is a hierarchicalcontext middleware with good scalability, whichcreates PocketMon to model and manage the usercontext through their mobile devices. However,HiCon does not provide a general context modelingand managing solution for mobile entities. Gaia [10]

is a distributed context middleware that coordinates

software entities and network devices in a physicalspace. By defining active space, Gaia suppliesservices to manage context of entities inside thespace. However, most context entities involved inactive spaces are static. Though services related to amoving person have been developed, no clear and

detailed description of data management for mobileentities has been given. CoBra [11] is an agent basedmiddleware to support context-aware services inintelligent spaces that embeds intelligent systemsinto physical spaces to provide pervasive computingservices to users. CoBra uses context broker toacquire and fuse context from heterogeneous sourcesinto a coherent model which is shared with allcontext entities inside the smart space. However,CoBra does not consider the specialties of mobileentities for context data management and focuses ona single space without the discussion on relationsamong different spaces.

For mobile application development, the currentlandscape mostly prospects the mobile device as agateway for the user to acquire outside worldinformation. Nevertheless, existing mobile devicesgain the capability to run business logics andprovision them as services. With these mobileservices, future devices will play a more active roleby interacting with each other in the ubiquitousenvironments. This vision is also realized in Nokiasmobile web server concept [12]. However, weanticipate the efficiency for discovering these mobileservices will be the main concern of usage if theseservices are not deployed in a well coordinated

fashion. The unreliable availability of mobile serviceproviders, due to reasons such as mobility, wouldfurther complicate the discovery process. Moreover,issues such as security, privacy, and serviceadministration should also be considered. Existingapproaches for service provision and discoverymainly fall into two groups: centralized anddecentralized. The centralized ones (e.g. UDDI [13]and Jini [14]) were popular in the early days due tothe simplicity in their implementations and ease ofadministration; however, they do not scale well. Inthe decentralized approach, scalable Peer-to-Peer(P2P) techniques such as Chord [15] and CAN [16]

are often used. Nevertheless, portable devices likesmart phones can barely maintain P2P connections,due to their resource and communication constraints.Besides, data locality is often not maintained in mostof these approaches, which makes them unsuitablefor range queries, e.g. proximity-based search.

We are proposing a context middleware Coalition in handling all the above issues in thedevelopment of context-aware mobile applications.More specifically, the two layers in Coalition:Context Data Management Layer and Service

Management Layerhandle the management ofcontext information from heterogeneous sources

(including mobile devices), as well as the provision

8/7/2019 paper519_519

3/14

and discovery of mobile services. Besides, our newlyproposed mobility support function would helpapplication development in mobile environments inan easy and efficient manner. In the followingsection, we will briefly introduce Coalition and itskey characteristics proposed in our previous work.

3 COALITION OVERVIEWCoalition, previously known as CAMPH [3], is a

context middleware designed for pervasive homecare.The design goal of Coalition is not just to be part of aparticular homecare application, but rather to be anopen, programmable and reusable infrastructure. Byconsidering this, it is designed as a service-orientedarchitecture: the various system functionalities suchas context data acquisition and reasoning, serviceregistration and discovery, are all designed anddeployed as system services for developers and end-

users to access. The middleware architecture consistsof four logical layers as shown in Figure 1.

Physical Space Layer. This layer consists ofreal-world physical spaces that represent thevarious context data sources. Aphysical space isan operating environment (e.g. peoples homesand offices) that provides context data from itsattached entities such as sensors, actuators andcomputing devices. It mandates all theinteractions of its entities with the outside worldthrough a designated gateway known asPhysical Space Gateway (PSG). Moreover, aPSG can be static (e.g. at home) or mobile (e.g.

worn by a person). We use a simple andpragmatic attribute-value approach to contextmodeling at the physical spaces and define acontext attribute as a specific kind of contextdata, e.g. location.

Context Data Management Layer. To efficientlymanage physical spaces and support context datalookup, we further define the concept of contextspace in this layer. A context space can bethought of an abstraction of a collection ofphysical spaces having similar attributes.Examples of context spaces are OFFICE, SHOPand PERSON, as depicted in Figure 1. The

physical spaces in a context space are organizedas peers in several semantic clusters (eachcluster represents a particular context attribute),over which the context queries for dataacquisition are processed [17]. On top of thislayer, a declarative, SQL-based context queryinterface is implemented for services andapplications to acquire context data or subscribeto event notifications.

Service Management Layer. This layer considersthe organization and discovery of services,including both system services and third-partyservices. In many of real-world application

scenarios, the geographical location of a

requester with respect to that of the serviceprovider can greatly affect the relevance of thediscovered services. This observation hasmotivated us to take aLocation-Aware approach

for Service Organization and Discovery

(LASOD). The location information of servicepeers is preserved using the locality preservingHilbert Space Filling Curve (SFC) [18]. Besides,

the Small World Model [19] is applied in ournovel Source Sampling method to make theresulting network adaptable and navigable. Tofurther enhance the context-aware capabilityduring service organization and discovery, thecontext data may be queried and utilized fromthe context data management layer.

Application Layer. Context-aware applicationslie on top of the service management layer. Theycan interact with middleware services to retrievecontextual information, use third-party services,or orchestrate services to fulfill tasks requiringthe collaboration of multiple services. The queryinterface for service discovery is both keyword-based and location-based. In the latter case, theapplications can limit the search scope to an areaor to a geographical range. We will use SharingOf Living Experience (SOLE) as a case study inthe second part of this paper.

In the following, we highlight the mechanismsused for context data and service management.Section 4 will discuss the extra features developedfor context-aware mobile application development.For the other mechanisms of Coalition such ascontext space schema matching, activity recognition,interested readers may refer to [3] for details.

Figure 1.Implementation architecture of Coalition.

8/7/2019 paper519_519

4/14

3.1 Context Data ManagementAs mentioned before, we apply the concept of

physical space to manage context data fromheterogeneous sources, as this approach providesscalability and flexibility while reducing complexityfor applications to utilize. An application (e.g.

Healthcare) may rely on one or more physical spaces(e.g. the person, his home and the hospital) to finishits desired tasks such as remote monitoring and thesephysical spaces may again be utilized by otherapplications to achieve reusability. Each physicalspace defines a set of context attributes, where someof them are directly derived from the sensors of thattype and some are based on context reasoning overthe data collected from multiple sensors. To allowapplications or other spaces to access and acquirecontext data from local sensors or other computingdevices, each physical space is associated with aPhysical Space Gateway(PSG). The PSG is a logical

software module that can be deployed at anycomputer of choice in the physical space. Forexample, the PSG of a person can be the persons

PDA or smart phone, and a home PSG can be adedicated PC at the persons home. Figure 2 showsthe functional components of a PSG.

To efficiently locate and acquire context datafrom the desired physical space, the contextmanagement layer of Coalition manages all physicalspaces (PSGs) using semantic P2P overlays. Morespecifically, all physical spaces are first mapped totheir conceptual context spaces by using therespective context schema that specifies all the

context attributes within the space. In Coalition, eachcontext space has a space schema that describes thecharacteristics of the physical spaces it prototypes.As an example, the space schema in PERSONembodies the properties of all physical spacesrepresenting persons in the real world, and it has

attributes such as name, age and location etc. Themapping is thus done between the context schema ofthe physical space and the space schema of the targetcontext space. Of course, in reality different physicalspaces may have different properties or differentnames for the same space schema attribute. Coalitionallows such heterogeneity by providing the matching

between context schema with the space schema inthe middleware, and if there are additional attributes

that need to be defined, the space schema will also bedynamically updated so to provide a unified view forall physical spaces within the same context space.The detailed schema matching mechanism isdiscussed in [20]. Once the physical space is mappedto the corresponding context space, the associated

PSG will join the semantic overlay created byCoalition. Each context space is mapped to a logical,one-dimensional ring network of semantic clusters,where each semantic cluster corresponds to a contextattribute in the space and is implemented as a P2Pnetwork by PSGs. As a physical space may notprovide all current attributes in the correspondingspace schema, its PSG will only join those clustersfor the attributes it has. The rings for all contextspaces are created and maintained by the contextspace managers at the system servers. A ContextSpace Gateway(CSG) is created as a special clusterin each ring to serve as the entrance for routing of

context queries (see Figure 1). The CSG connects tothe ring as any other cluster while it is actually asubcomponent of the physical space manager ratherthan a P2P network. It maintains the ring topologyand creates new semantic clusters when the contextspace evolves during the process of schema matching.A PSG can leave the semantic clusters it joins at anytime. The leaving is automatically detected by theP2P protocol at the neighboring peers. The PSG mustsend a new registration request in order to rejoin theinfrastructure.

Through the context management layer,Coalition provides a declarative, SQL-based query

language interface for applications to acquire contextdata from physical spaces. Two classes of contextqueries are supported: data collection queries andevent subscription queries. The following twoqueries exemplify the two query classes.

QUERY 1:SELECT temperature, heartbeatFROM PERSONWHERE name = Jennifer

QUERY 2:SUBSCRIBE isVacantFROM HOMEWHERE location = ION Orchard

We have also extended the default SQL querylanguage by supporting new keywords. For instance,a CONT keyword can be used to specify a dataacquisition query that is continuous and push-based;the SAMPLE INTERVAL and LIFETIME clausesare designed to indicate the sampling interval andduration of the continuous data acquisition. Inaddition, Coalition has proposed a hierarchicalreasoning scheme from the low-level sensor datareasoning at PSG to high-level physical space datareasoning at the context space. Applications mayalso have their own reasoning scheme designed inthe application level. The interested readers may

refer to [3] for details.Figure 2. Functional components of a PSG.

8/7/2019 paper519_519

5/14

3.2 Service ManagementAbove the context data management layer is the

service management layer, which facilitates serviceorganization and discovery for both system servicesand third-party services. Applications may utilizeany service in this layer during their development or

execution time. The detailed service management isvia a scheme known as Location-Aware ServiceOrganization and Discovery (LASOD) [4]. LASODorganizes areas and the service providers within eacharea in two distinct tiers for local administration andscalability purposes.

1st Tier (Area Organization). In this tier,administrative areas are organized based on apredefined geographical tree. It specifies thesemantic name and the geographical boundaryof each area. The tree also specifies if an area iscontained by another one, i.e. area hierarchy. Allthe service providers are assumed to reside in

one of the specified areas, as illustrated inFigure 3. The complete specification of eacharea is maintained in a special peer node knownas a superpeer. It represents the geographicalcenter of the area, although it may be physicallylocated anywhere. Each superpeer performssome fundamental operations: it helps newservice providers to join the area and facilitatescross-area queries by maintaining links withsuperpeers of neighboring areas. The role of asuperpeer can be played by a dedicated server or

by any of the service providers servers withinthe area. While the former may have full

administrative and management controls, thelatter may only perform the mentionedfundamental operations.

2nd Tier (Local Area Service Organization).After dealing with the area organization, theactual service providers within a specific areaare managed in the second tier. In this tier, P2Pconcepts are applied to achieve scalability and tomitigate the negative effects of joining andleaving of (mobile) service providers. We referto all service providers in this tier as service

peers which share common computation taskssuch as service indexing and query routing. Note

that the superpeers are also service peers.

To enable location-aware service discovery, wederive the identifier for each service based on itsgeographical location. The identifier is represented ina binary form and composed of two parts: areaID

peerID. As an example, the identifier for service peerc in Figure 3 is 1110 1001. The areaID is determined

by the area position in the geographical tree. Figure 4illustrates the allocation of areaID for the areas in thefirst tier of Figure 3. Once the areaID is determined,each superpeer is connected to the first superpeerwhose areaID is greater than that of its own in termsof decimal value. While the areaID reflects thecoarse-grained location information of a service peer,the peerID is supposed to contain the fine-grainedlocation information. For this purpose, we deploy theHilbert Space Filling Curve (Hilbert SFC) [21] foreach local area. For instance, consider Figure 5 (top)for an area consisting of seven service peers. Initially,the curve consists of lines which lay over few coarse-

grained regions; then it is recursively refined untilonly one service peer remains in each cell (in twoiterations for this case). The peerID of a service peerwill then be the ID of the cell it resides in. The set ofcell IDs generated in different iterations can berepresented in a hierarchy which we call Hilbertconstruction tree (Figure 5 bottom). In practice, wetarget a predefined cell size of 1m2 to determine thenumber of iterations required, as we assume adensity of one service peer per square meter isdeemed acceptable for most applications. Afterassigning identifiers, if two service peers follow eachother on the curve, they are supposed to maintain a

connection to each other.Root Area

Area A0000

Area B0100

Area C1000

Area D

Subarea D11100

Subarea D21101

Subarea D31110

Unclassified1111

Figure 3.The two-tier service organization architecture.

Figure 5. Using Hilbert SFC for assigning identifiersto service peers (top). The IDs generated in different

iterations form Hilbert construction tree (bottom).

Figure 4. Labeling areaIDs for a geographical tree.

8/7/2019 paper519_519

6/14

To make the network adaptable and navigable,LASOD adapts the Small World Model [19] in ournovel Source Sampling method. The methodgenerates long-range links (i.e. shortcuts) betweenpeers in a probabilistic manner along with theprocess of query routing. To do so, each service peer

is augmented with knumber of long-range links forgreedy routing. During a query routing, every servicepeer that receives the query will perform a samplingprocess for the creation of long-range link, i.e. fromthe service peer where the query originated to itself.The sampling is based on our modified Kleinbergshierarchical model and the probability is derivedfrom the identifiers of the two service peers. Usingthe method, the routing efficiency is improved, whencompared with early approaches. Besides, we havealso made use of long-range link indexing [4] toimprove the fault resilience of the framework. Theindexing scheme takes advantage of the long-range

links created during the source sampling process andis used for cross-area routing, which helps to relievethe routing efforts imposed on superpeers. In Section6, we show through experiments the benefits of usingthe scheme. As the network model and routingmechanism are not the main focus of this paper, theinterested readers may refer to [4] for details.

4 COALITION FOR MOBILE APPLICATIONSTwo main issues arise when dealing with

applications on mobile devices:

Mobility. When using mobile devices, theconnection or the session required by theapplication will be inevitably lost during theuser movement. The nave way to work aroundthis problem is to let the user or the applicationre-initiate the connection or session. A muchpreferred solution deals with the issuetransparently.

Resource Constraints. When services are hostedby personal mobile devices, we need todistinguish the limitations of mobile devices ascompared to the conventional desktop, as mobiledevices have limited memory, processing powerand battery life, and their availability may be

intermittent.

We have devised features to make Coalition anapplication-independent platform to support mobilityand service provision on low-end devices. Mobileapplications are only required to utilize the APIsprovided by Coalition to handle tasks such asmobility callback, mobile service registration anddiscovery. In the following, we will discuss the twofeatures in detail.

4.1 Mobility Support4.1.1Mobile Space

To support context-aware applications for

mobile entities, we define mobile spaces to modeland manage context data pertaining to mobiledevices. More specifically, for any mobile physicalspace (e.g. a person), if its PSG (e.g. the smart phonecarried by him) is mobile, we call this physical spacemobile physical space, the corresponding context

space mobile context space, and the PSG mobile PSG(M-PSG).

4.1.2Availability Management for Mobile SpacesBecause a physical space may lose its network

connectivity due to mobility or poor networkcoverage, availability must be properly managed tosupport context data management and context awareapplications. We define the availability of a physicalspace (including M-PSG) as the ability of reaching-out to other PSGs through communication networkssuch as the Internet. Additionally, we define theconcept of callback as a service that provides a

notification for any change about availability statusof a particular MPSG. Two new system services areintroduced to Coalition to handle availabilitymanagement for a mobile space: AvailabilityUpdating Service (AUS) and Application CallbackService (ACS). AUS handles the reachability of amobile space for context data acquisition vianetworks. Each MPSG creates a session withCoalition during registration defined as MiddlewareSession ID (MSID) which is recorded by a MSIDTable with availability information. As a result, anyvariation about availability status of a specific MPSGcan be updated automatically and benefit other

services accordingly. ACS handles the disruption andresumption of any application due to the availabilityissue of MPSGs. Each application launch is given an

Application Session ID (ASID) by its respective host(i.e. MPSG). By combining MSID and ASID, aunique Session ID (SID) is generated to identify aparticular application running in a specific MPSG.By using this ACS, an application in a MPSG canregister a callback upon the availability change ofone particular MPSG. Whenever a MPSG issuesupdating through AUS, all callbacks registered uponthat particular MPSG are retrieved as a list. With theavailability information stored in middleware,

application callback notifications are sent to allMPSGs in the list. In the following we will discussthe two services in details.

4.1.2.1Availability Updating Service (AUS)

Each MSID is a named pair identifier: contextdomain indicator showing the context domain thatthe MPSG belongs to, and counterusing a numericalvalue to uniquely identify each MPSG. The entireAUS can be divided into two parts: MiddlewareSession Processor inside Coalition server and

Availability Updating Processorinside each MPSG(Figure 6).

Middleware Session Processor. It generates the

8/7/2019 paper519_519

7/14

MSID information for each MPSG duringregistration, and manages it through the lifecycle of the MPSG. This component containstwo sub-components: MSID Table and Query

Handler. MSID Table records availabilityinformation of each MPSG with respect toMSID. It contains two information fields: MSID

and Availability Information which contains theIP address and port number of a MPSG. Toincrease the scalability, many MSID Tables arecreated and distributed into different CSGs, andeach CSG maintains its own MSID table for theregistered MPSGs. Query Handler handlesdifferent kinds of MSID related queries fromMPSGs including following operations: insert,update, retrieve and delete. MSID can beutilized to identify its CSG information to routeits related queries to the correct place.

Availability Updating Processor. It detects anyavailability change of a MPSG, and updates it

with Middleware Session Processor. Thiscomponent contains two sub-components:

Network Monitorand Availability Updater. Network Monitorcollects the availabilityinformation of a MPSG persistently. If a changeis detected, an availability updating alert isgenerated and forwarded toAvailability Updaterwhich contains the MSID information of thisMPSG. Subsequently, Availability Updatercommunicates with middleware to update theavailability information.

4.1.2.2Application Callback Service (ACS)

ACS resumes halted application sessions causedby any unforeseen availability problem of relatedMPSGs. Based on the previous definition of callback,we further define the MPSG requesting the callbackas a Callback Caller and the MPSG for which thecallback is issued upon as a Callback Callee. Theentire ACS can be divided into two parts:

Application Callback Processorinside Coalition andApplication Callback Handlerinside each MPSG orapplication server (Figure 7).

Application Callback Processor. It managesapplication callbacks, handles callback queriesand distributes application callback notifications.This component contains three sub-components:

Callback Table, Query Handler and CallbackNotifier. Callback Table records all applicationcallbacks issued by applications residing indifferent MPSGs. A callback table containsmany named pairs: Callback Callee andCallback Caller. Similar with MSID Tables,many Callback Tables are distributed to

different CSGs to achieve scalability. QueryHandler processes callback queries fromdifferent MPSGs such as callback registrationand deletion. Fired by AUS, Callback Notifierreceives a callee MSID and searches callbackcallers with respect to this callee fromcorresponding Callback Table. After obtainingthe caller list, it retrieves availabilityinformation of all callers from middleware, andthen generates and distributes applicationcallback notifications to all caller MPSGs.

Application Callback Handler. It issues callbackqueries to Application Callback Processor as

well as processing received application callbacknotifications to resume previously haltedapplications. This component contains three sub-components: Query Controller, NotificationController and Network Controller. QueryControllerreceives a message from an arbitraryapplication, generates and issues one callbackquery to Application Callback Processor.

Notification Controllerreceives and analyzeseach application callback notification on behalfof the halted applications. Whenever receivingan application callback notification, it parses theASID, MSID and availability information of thecallee, and then interprets the ASID and passesthe MSID and availability information to thecorresponding application to resume previouslyaffected session. Network Controllerdeliverseach query to as well as receiving applicationcallback notifications fromApplication CallbackProcessor.

4.1.3APIs for Mobility SupportTo give a more concrete idea for application

developers to utilize the mobility support services ofCoalition, Figure 8 shows the APIs for mobilitysupport and their usage flow.

During the normal operating of a MPSG (Figure

Figure 6. Availability Updating Service architecture. Figure 7. Availability Callback Service architecture.

8/7/2019 paper519_519

8/14

8 top), Network Monitorperiodically collects theavailability information with getIP(). ItsupdatingAlert() checks and detects any change ofavailability information, and then forwards anupdating message to Availability Updaterin whichavailabilityUpdatingPSG() activates ACS and

AUS. Each new availability information with MSIDis sent to both Application Callback Processorand Middleware Session Processor. Inside MiddlewareSession Processor, availabilityUpdate() usesMSID

Analyzerto get context domain information (namelyCSG) by analyzerCSG(). Subsequently, newavailability information is updated with thecorrespondingMSID table by put(MSID, IPPort).

ACS is activated by receiving an updatingmessage from Availability Updater(Figure 8bottom). Availability Updating ProcessorutilizesavailabilityUpdating() to send a messagecontaining MSID and new availability information to

Callback Notifier in which callbackNotification()initializes the ACS and validMSID() checks thevalidity of coming MSID. Only a valid MSID isforwarded to Caller Searcher component in whichgetCallers() retrieves the caller list from CallbackTables with respect to this MSID. Meanwhile, thiscomponent also gets availability information of allcallers from the Netinfor Retrieverby getIPPort().Consequently, it sends a message to Notification

Manager in which notification() andnotificationDistribution() to generate and distributeapplication callback notifications. ApplicationCallback Handler uses notificationReceiver() to

receive each application callback notification frommiddleware, and then leverages on NotificationControllerto serve applications.

4.2 Mobile Service Provision4.2.1Three-tier Service Provision Architecture

LASOD is designed as a platform for anyapplication to leverage on so to publish and discoverservices. To utilize the functions of LASOD, threelogical software components are defined for theapplication (as represented in the ApplicationComponents of Figure 9), which includes (1) userinterface specific which interacts with the user toallow functions of the application to be invoked; (2)application specific which performs application-specific logic; and (3) service management specificwhich interacts with the underlying servicemanagement functions of LASOD to complete taskssuch as service registration and query routing. The

first two components should be designed by theapplication itself; while the last component is createdby LASOD, which we name as Service Mediator(SM). More specifically, it mediates the applicationwith the LASOD functions: on one hand, SM allowsapplications to utilize the indexing and routingmechanisms of LASOD to publish their applicationservices or discover available ones (e.g. for dynamicservice composition); on the other hand, SM keepsthe service information of each application so that ithelps LASOD to direct any application-specificquery to the responsible application service. Indeed,the above three components defined may reside in

one or be distributed to more than one computingdevices. This allows applications to utilize thefunctions of LASOD without actually deployingLASOD components (e.g. indexing and routing). Atypical example is for mobile service provision,where it may not be feasible for mobile devices toperform the peer operations as expected in LASOD,such as facilitating P2P connectivity and routing ofqueries. By distributing the SM component to a morecapable machine (e.g. a desktop), this machine canhandle the communications between the mobileservice and LASOD. Besides, with the help of SM, itmaximizes the flexibility of LASOD, as the service

Area A

Area B Area C

Area D

Subarea D3

Subarea D2 Subarea D1

Unclassified

2nd Tier

Local-Area ServiceOrganization

Hilbert SpaceFilling Curve

Superpeer A

B C

D

Superpeer

1st

TierArea

Organization

PersonalDevices

WiFi 3rd

TierMobile Serviceorganization

GPRS

PersonalDevices

Proxy

PersonalDevices

3G

ProxyProxy

cb

Service Peer

a

e f

d

Service PeerModel

UI specific

Applicationspecific

Serivcemanagement

specific

ApplicationComponents

LASODComponents (e.g.service indexing,

query routing)

SOLEApp.

OtherApp.

Figure 9. The three-tier service organization anddiscovery architecture. The 3rd tier is extended tosupport mobile service provisioning.

Figure 8. Illustration of API usage for mobility support.

8/7/2019 paper519_519

9/14

Figure 10. Service peer functional componentsand its support for service provision.

registration does not need to differentiate betweenlocal service and mobile service provisioning.

To cater for resource constraints of MobileService Providers (MSPs), the service managementlayer of Coalition organizes the service providerswithin each area according to their capabilities. More

specifically, relatively powerful service providerscan take the role of aproxy to host services delegatedby the resource-constrained mobile devices, i.e. byrunning the respective SM component. This resultsin a three-tier architecture for service organization inFigure 9, as compared to the two-tier architecture inFigure 3. The third tier is for MSPs via less capablemobile devices. We assume they can connect to theInternet in one or more ways, such as via GPRS,WiFi, or 3G. Each device in this tier shares itsservice through aproxy in the second tier, which is aservice peer with supposedly higher availability andresources. For instance, if a doctor wishes to provide

an emergency care service anytime anywhere, he canrun a mobile care application in his mobile phonewhich announces his presence. When entering aspecific area, the mobile care application will lookfor a proxy that will in turn register the mobileservice in LASOD for discovery and invocation.

4.2.2Service Peer ModelingFigure 10 shows the new functional model of a

service peer in LASOD. Each service peer canperform two basic tasks: service provision andservice discovery. The service provision relates topublication and indexing of services; while the

service discovery deals with lookup and invocationof the desired services. As a service peer may hostmultiple services, local service management isessential: it controls the start/termination of a serviceand may support service migration. The serviceregistration component handles service registrationand publication. In the case there are servicesdelegated by MSPs, the service peer acts as a proxy.To enable efficient service discovery, registeredservice information such as name and description areindexed using the DHT technique over the respectiveP2P network for each local area. The range linkindexing component is to relieve the workload of a

superpeer and also improve the network resilience.The peer link maintenance component is for linkmonitoring among service peers. In case there is apeer link failure, the corresponding link repairfunction will be triggered. The rest of componentsperform tasks related to query generation, routing

and processing which are necessary for servicediscovery and they were discussed in [4]. Once thedesired service is looked up, the requester mayinvoke the service directly through LASOD.

The software architecture of a service peer hasbeen implemented in the Coalition toolkit. Localapplications can simply rely on the followingstatements to get their services published; assumingthe local service peer sp (on the same machine) hasbeen started.

ServiceData service = new ServiceData(name,address,type,description,reference);

SM mediator= sp.registerService(service);

mediator.publishService();In the above statements, the ServiceData service

is used to describe the registered service, includingits name, address, type, description and reference.The type indicates the category of the service so theapplication-specific query received by the sp can bedirected to the correct service. The description of theservice is utilized for service matching. Applicationdevelopers may use richer descriptions such as thoseparsed by WSDL file to support Web servicefunction discovery. The reference refers to the meanto trigger the service in case it is a software service.It can be a function reference, a Web service URL or

a TCP/IP socket. For local service registration, thereference to the newly created SM object is returnedback to the application, so application can publish itsassociated service using the mediator. Note that oncethe application service is bound to a particular SMinstance, it may utilize the functions provided by theSM instance to communicate with LASOD and touse its resources and functions. Figure 11 illustratesthe relationships and interactions among the softwarecomponents Application, ApplicationService,ServicePeerand ServiceMediator.

+addConnection() : void

+routeQuery() : void

+registerAS() : ServiceMediator+removeAS() : void

-ip : string

-port : int-address : string

-areaID : int-peerID : int

-leftNeighbor : ServicePeer

-rightNeighbor : ServicePeer

ServicePeer

+publishAS() : bool-subscribeAS() : bool

+receiveQuery() : Result

-serviceName : string-serviceType : string

-serviceReference : URL

ServiceMediator

Application

ApplicationService

+register

1..*

+host

1..*

+create1

+referencedBy1..*

+consist1

+containedBy1..*

+invoke

1

+callback

1

Figure 11. The interactions of software componentbetween the application and the service peer.

8/7/2019 paper519_519

10/14

4.2.3Mobile Service ProvisionAs mentioned before, the application service is

not necessarily hosted on the same machine as wherethe service peer is running. When services aresupposed to be provisioned on a separate machine(e.g. for mobile service provision), the responsible

service peer is acting as a proxy. In this case, twoissues must be resolved: (1) the discovery of theproxy and (2) the communication method. For (1),we have designated a port for each service peercapable of being a proxy to listen on, so that if theMSP and the proxy are in close proximity, the proxycan be discovered via WiFi broadcast. In this case,the MSP does not necessarily possess a public IP forits service provision. Alternatively, a list identifyingthe address of potential proxies can be retrieved fromour dedicated Web server. For (2), all kinds ofinvocations are through the Web service mechanisms.Therefore, the Web service URL of the mediator will

be returned when registering application services tothe service peer.

5 CASE STUDYTo demonstrate the design, integration and

deployment of mobile applications in the Coalitionenvironment, we have chosen Sharing Of Living

Experience (SOLE) as the case study because of itsrichness in application and user behaviors. Moreover,we can easily extend SOLE to support other types ofapplications such as service recommendation basedon peoples experience rating. Our SOLE application

framework will be differentiated from the existinginformation sharing work (e.g. RevisiTour [22],Sentient Graffiti [23], foursquare [24] and Gowalla[25]) in the following aspects: (1) it is generic andscalable, by not assuming a specific applicationscenario, e.g. museum or tourism. It allows users toshare and retrieve experiences about any entity atanywhere, anytime (without requiring RFID tags);(2) it is flexible, by allowing the user to choosewhere to store the experience data and to specify hisaudience. When the data is stored on mobile devices,it could be offered through mobile services fromthese devices; (3) it is context-aware by considering

the location, time, and preferences of the user indiscovery and delivery of experience information. Inthis section we will briefly explain the design ofSOLE, but with special emphasis on Coalition as aplatform to help make SOLE development moreefficient and effective.

5.1 SOLE OverviewThe detailed description of SOLE application

can be found in [26]. The application consists ofthree participants, which we call them as SOLE

Application Server (SOLE-AS), SOLE ApplicationService Provider (SOLE-ASP) and SOLE Application

Service Consumer (SOLE-ASC). The main task of

the SOLE-AS is to maintain an index to the shareddata of experiences. The index key represents theentity of interest (such as a shop), and the valuedescribes certain aspects of the experience, e.g. whoshared it, when and where it was shared. SOLEfacilitates sharing of experiences through distributed

SOLE-ASs. Each SOLE-AS has an ID and isresponsible for a part of the keyword space based onthe Distributed Hash Table (DHT) technique: forstoring the index of the experience data, the name ofthe entity of interest is hashed to a key and isassigned to the first SOLE-AS whose ID is equal toor greater than the key value.

Users use SOLE-ASP/ASC to share or retrieveexperience information. As SOLE allows the actualexperience to be stored on the mobile device, whenretrieving data from the device, the respectiveSOLE-ASP is also considered as a Mobile ServiceProvider (MSP). In the current design of SOLE-ASP,

the functions to support experience retrieval on theSOLE-ASP's mobile device are all exposed as Webservices, which is similar to the case for the SOLE-AS. The interactions among SOLE components forexperience retrieval are illustrated in Figure 12.

5.2 SOLE Application Service in CoalitionWith Coalition, SOLE can rely on the service

management layer (i.e. LASOD) for the organizationand discovery of its services. There are two majortypes of services in SOLE: (1) services provisionedby SOLE-ASs; (2) services provisioned by SOLE-ASPs. The former represents the conventional client-

server model where SOLE-ASPs/ASCs share orretrieve experience through dedicated SOLE-ASs;while the latter considers peer-peer model andSOLE-ASC could directly retrieve data from SOLE-ASP. Figure 13 shows the two service provisioningmodels for SOLE in LASOD. Sample service datafor SOLE-AS service is shown as follows:

ServiceData service = new ServiceData(SOLE-AS,41.03497,29.03015,SOLE,

SOLE Application Server,http://192.168.1.101:8080/services/sole.wsdl);

SOLE-AS Cloud inLASODSOLE-ASP

1. Indicate entity of interest

2.LocateSOLE-ASusing

entitynamekey

3.InvokeSOLE-ASWeb

service

4.InvokeSOLE-ASP

Webservice

SOLE-ASC

CoffeeShop

Keyword Space

Figure 12. Illustration of experience retrieval bySOLE-ASC. Step 4 is involved when the experience

data is stored on the SOLE-ASP.

8/7/2019 paper519_519

11/14

Indeed, when SOLE is integrated with LASOD,it can use the service browsing and discoveryfeatures of LASOD. More specifically, if an entity ofinterest has a corresponding service registered with

LASOD, the service is visible on the map and userscan associate their experience with the representativeservice. Similarly, to retrieve the experienceinformation, the users can select a service to checkwhether the corresponding entity has any experienceinformation associated with it or not. SOLE caneasily support proximity accessing (or sharing) ofexperiences or a range-based access by SOLE-ASCsdue to the location-awareness of LASOD.

5.3 SOLE MobilityIf the experience data is stored on a mobile

device (instead of a distributed server), efficiently

locating the device by the SOLE-AS/ASC can bechallenging. In Coalition, such a problem can behandled in two phases: (1) retrieving the currentlocation of the SOLE-ASP by issuing the querySELECT location FROM PERSON WHERE id =

asp_id, where asp_id is the SOLE-ASPs ID; (2)sending a service discovery query to LASODlimiting the search scope to the proximity of SOLE-ASPs location. Once the reference of the SOLE-ASP is retrieved, its service can be invoked, but ifthe reference corresponds to a proxy, the proxy willinstead direct the query t to the right SOLE-ASP.

However, the SOLE service can be continuous

sometimes, e.g. streaming for sharing a video. As aresult, the transaction can be affected by themovement from SOLE-ASP/ASC. How to make themobility influence transparently for users is anotherchallenging task. As mentioned in Section 4.1,Coalition creates two special system services to solvethis problem: Availability Updating Service (AUS)and Application Callback Service (ACS). On onehand, AUS helps a user detect availability (namelynetwork connection) changes and update the changeswith middleware. On the other hand, ACSmemorizes previous halted application sessions andactivated by AUS to generate and distribute

application callback notifications on behalf of the

halted applications. As a result, previously haltedsessions can be resumed and proceeded. In addition,the above two services can work automatically sothat users will not be disturbed by mobility effect.

5.4 SOLE Context-AwarenessLocation, as a relevant context, is alreadyembedded in SOLE by leveraging on LASOD. More

specifically, the SOLE-ASC/ASP may browse forentities within the local range or issue keyword-based queries to select an entity of interest.

The context of a SOLE-ASC can be exploitedfor pushing relevant experience information. Thepushing of information can also be personalized bytaking the person's preference into consideration. Forinstance, the SOLE-AS can subscribe with Coalitionto detect the event of users entering a mall, e.g.SELECT name FROM PERSON WHENLocationChange WHERE new_location = ION

Orchard. Later when the LocationChange eventoccurs, Coalition will notify the SOLE-AS with thename of the person and then the SOLE-AS can getthe preferences of the mobile users by issuinganother query SELECT preference FROMPERSON WHERE name = person_name ANDapp_type = SOLE.

Finally, the experience meta-data can be used ina number of ways. For instance, Time can be usedto filter old experience data; Friend List can be

used to filter irrelevant SOLE-ASCs. Note that theproposed data schema is extensible so thatapplications may define their own attributes to be

matched in the SOLE-AS.

6 EXPERIMENTAL RESULTS AND PROTOTYPEIMPLEMENTATION

We present our current performance evaluationresults on the Coalition middleware for the supportof mobile application development. This sectionincludes three major parts: the experimental resultsfor mobility support in the context managementlayer; the simulation studies for routing behaviorsand service provision in the service managementlayer; and the prototype implementation for real-time

tests of the SOLE mobile application.

6.1 Mobility Support6.1.1Mobile PSG Registration and Deletion

We first studied the overheads introduced by thesession id during registration process. PSGregistration time is defined as the time intervalbetween the submission of the registration requestand the reception of the registration reply. The PSGregistration time was measured and compared fortwo middleware versions one using the session idand the earlier version without session id. Figure 14shows the measurements carried out using PSGs for

PERSON context domain. The results indicate that

Figure 13. Two types of service provisioningmodels for SOLE when deployed in LASOD.

createexperience

retrieveexpe

rience

SOLE-AS

SOLE-SM

SOLE-ASP

SOLE-ASC

SOLE-ASP

SOLE-ASC

SOLE-AS

create

experience

retrieve experience

client-servermodel

peer-peermodel

ServiceManagemen

tLayerofCoalition(LASOD)

publish

SOLE-SM

register

Proxy

publish

8/7/2019 paper519_519

12/14

a small overhead is introduced in the registrationprocess due to the introduction of the session idmechanism. However, the observed overhead is notvery significant compared with the entire registrationtime, so it can be safely concluded that theintroduction of session id mechanism does not causean appreciable change in the registration process.

6.1.2Callback Registration and DeletionWe next analyzed the time required for callbackregistrations and deregistration for all the possiblescenarios. Table 1 outlines the four different testcases we considered for the experimentalmeasurements. The results in figure 15 indicate thatthe registration time for the first and second cases arelarger than the time required for the third and fourthcases. This is expected as the creation of newcallback instances should take more time than justappending the new callback information to theexisting instance. Also, comparing the first and third

case to the second and fourth case clearly shows thatthe registration time increases when the pair of callerand callee belongs to different context domains. Thisincrease is due to the processing time required totransfer information between two different contextdomains. The results also indicate that the callbackregistration process does not incur any significantadditional processing overhead.

Table 1. Cases for Callback registration and deletion.

Case Explanation

1 Both the caller and callee belong to the same

context domain2 The caller and callee belong to different context

domains

3 Same as case 1, a callback has already registeredupon the callee

4 Same as case 2, a callback has already registeredupon the callee

6.1.3Availability Updating and CallbackNotification Management

We next studied the overheads incurred in theprocesses of availability updating and the callbacknotification distributions. We measure the overheadas the total time taken for the middleware to receivea mobility update and distribute the notifications to

the registered callers. The measurements are carriedout by varying the size of the callback list and theresults obtained are shown in figure 16. The resultsindicate that there is an increase in the time requiredfor the availability updating and the callbacknotification distribution as the size of the callbacklist increases. This is intuitive as an increase in thecallback list size will also require more processing todistribute the callback notifications. However, it canbe observed that the increase curve becomes smoothafter the initial increase. This indicates that theproposed callback mechanism does not create anylarge additional overhead and is stable with respectto the increase in the callback list size.

6.2 Service ManagementIn [4], we have demonstrated the network

navigability and framework resilience by usingSource Sampling and the long-range link indexingmechanism. The simulation is carried out on a1024m*1024m map with the geographical treegenerated randomly. In a trial run, the depth of thetree is 6and the number of tree nodes (i.e. areas) is364. The service peers are randomly distributed onthe map (certain areas may be empty if having a low-density distribution of service peers) and for eachround of query routing, two service peers arerandomly selected as the source and the target of thequery. In this paper, we further study the effect oflong-range link indexing mechanism in affecting thenetwork routing behavior. More specifically, the

routing efforts imposed on superpeers and servicepeers are compared. The routing effort is defined as

Figure 14. PSG registration and deregistration. Figure 15. Callback registration and deregistration.

Figure 16. Availability updating andnotification management.

8/7/2019 paper519_519

13/14

the average number of peers (superpeers/servicepeers) involved in the routing of a single query, andit reflects the required processing workload. Figure17 presents the results. We observe that in ourapproach (Figure 17(a) and 17(c)), the routing effortrequired on superpeers decreases as the number of

queries routed increases. This is because the morethe number of queries, the more long-range indexesare created. It justifies that the superpeer function inLASPD can be performed by any non-dedicatedserver and the failure of a superpeer will not affectcross-area routing severely [4]). We also note thatwith larger k value (i.e. number of long-range linksaugmented for each service peer), it requires lessnumber of queries to achieve the same effect inreducing the routing effort. The reason is simply dueto the fact that more long-range links are allowed tobe created with the same number of queries routed.However, the performance gain becomes smaller

when k increases. This is also observed in thenavigability test in our previous paper, where k=3 isthe optimal value. For the conventional hierarchicalrouting approach (Figure 17(b) and 17(d)), therouting effort required on superpeers does not changeconsiderably. Figure 17(b) shows that for the case oflow-density distribution of service peers (212 servicepeers), superpeers play a more critical role in cross-area routing, e.g. the routing effort imposed onsuperpeers is almost twice as that on service peerswhen k=1. Note that overall our approach imposes ahigher routing effort on service peers; for instance,when k=1 an average of 26 service peers after 106

queries (Figure 17(c)) as compared to 15 in theconventional approach (Figure 17(d)). Nevertheless,the routing path-length does not differ much, i.e.1+26 versus 13+15 after 106 queries.

We also measured processing overhead onproxies using a sample Web service which accepts anumber of parameters (words) as input and echoesthem to the client. We used the kSOAP2 library [27]

for generation and processing of SOAP messages.The processing overhead on the proxy is mainly dueto the direction of a SOAP message to thecorresponding mobile device. Note that the timeremains almost constant (around 100 ms) eventhough the number of Web service parameters

increases.

6.3 SOLE Mobile ApplicationWe have developed a prototype of SOLE in our

laboratory to emulate the scenario illustrated inFigure 12. Figure 18 presents the user interface forthe SOLE-ASP/ASC. For evaluation of SOLEperformance, we have run the SOLE-AS on bothdesktop PC (Intel Dual-Core E8400) and a mobiledevice (HTC Hero) to emulate the scenarios forclient-server and peer-peer models (Figure 13).Several metrics based on real-time evaluation arecompared and shown in Table 2.

Table 2. Performance comparisons for SOLE.

Metric Time (Milliseconds)

Desktop Mobile Device

SOAP Deserialization 12 132

SOAP Serialization 5 45

Application Execution

Experience Insertion 17 62

Experience Deletion 2 12

Experience Search 4 14

7 CONCLUSION AND FUTURE WORKIn this paper, we present the design and

implementation of a service-oriented contextmiddleware Coalition to support context-awaremobile application development. The middleware isextended from our previous work for pervasivehomecare with two additional features: the mobilitysupport and the service management for mobileapplication services. The fundamental goal ofCoalition is to introduce an open, programmable and

Figure 17. The effect of long-range link indexingmechanism in affecting the routing behavior.

Figure 18. Screenshots for SOLE-ASP/ASC: (a)Upon selecting an entity (star) on the map, the usercan share experience about the entity or retrieveexperience associated with it; (b) the user can viewthe list of experiences shared by others and he mayadd in his experience directly; (f) the details for theuser selected experience.

8/7/2019 paper519_519

14/14

reusable platform for context-aware applicationdevelopers to leverage on and effectively relieve thecomplexity and workload associated with applicationdevelopment. The detailed APIs and mechanismsthat allow such easiness by using the aforementionedtwo features are discussed in the paper. Furthermore,

the working principles of Coalition have beendemonstrated via a case study, namely Sharing OfLiving Experience (SOLE) mobile application.

So far, context-aware computing hasnt foundcommercial success and our present prototype is stillfar from usable though we have carried experimentsin the laboratory environments. However, we believethat a good initiative to advance context-awarecomputing is by having a robust and powerfulmiddleware to fulfill context related tasks. In thenext stage, we will deploy Coalition in a large fieldtrial, such as in the university campus, to do morerigorous study and evaluation of its performance. In

addition, we are currently working on the contextrealization mechanisms to further ease the utilizationof the Coalition middleware and mechanisms.

8 ACKNOWLEDGMENTSThis work is partially support by project grant

NRF2007IDM-IDM002-069 on Life Spaces fromthe IDM Project Office, Media DevelopmentAuthority of Singapore.

9 REFERENCES[1] M. Weiser, The computer for the 21st century,in Journal of ACM SIGMOBILE Mobile

Computing and Communications Review, Vol. 3,No. 3, pp. 3-11, 1999.

[2] T. Gu, D.Q. Zhang and H.K. Pung, Peer-to-peercontext reasoning in pervasive computingenvironments, in Proceedings of Workshop on

CoMoRea, pp. 406-411, 2008.[3] H.K. Pung, et al., Context-aware middleware

for pervasive elderly homecare,'' in Journal ofSelected Areas In Communications, Vol. 27, No.4, pp. 510-524, 2009.

[4] J. Zhu, M. Oliya and H.K. Pung, A pragmaticapproach to location-aware service organizationand discovery,'' in Proceedings ofIPCCC, pp.272-279, 2009.

[5] GetJar,http://www.getjar.com/.[6] Symbian,http://www.symbian.org/.[7] Apple iOS,http://www.apple.com/iphone/ios4/.[8] Google Android,http://www.android.com/.[9] K. Cho, et al., HiCon: A hierarchical context

monitoring and composition framework fornext-generation context-aware services, inJournal of IEEE Network, Vol. 22, No. 4, pp.34-42, 2008.

[10]M. Romn, C. Hess, R. Cerqueira, A.Ranganathan, R.H. Campbell and K. Nahrstedt,Gaia: A middleware platform for activespaces, in Journal ofACM SIGMOBILE Mobile

Computing and Communications Review. Vol. 6,No. 4, pp. 65-67, 2002.

[11]H. Chen, An Intelligent Broker Architecture forPervasive Context-Aware Systems, PhD thesis,Department of Computer Science, University ofMaryland, Baltimore County, 2004.

[12]Nokia Mobile Web Server,http://research.nokia.com/research/projects/mobile-web-server.

[13]UDDI,http://www.uddi.org/pubs/uddi_v3.htm.[14]Jini.org,http://www.jini.org/wiki/Main_Page.[15]I. Stoica, et al., Chord: A scalable peer-to-peer

lookup service for internet applications,'' inProceedings of ACM SIGCOMM, pp. 149-160,2001.

[16]S. Ratnasamy, et al., A scalable content-addressable network,'' in Proceedings ofACMSIGCOMM, pp. 161-172, 2001.

[17]T. Gu, H. Pung and D. Zhang, Informationretrieval in schemabasedp2p systems using one-dimensional semantic space, In Journal ofComputer Networks, Vol. 51, No. 16, pp. 45434560, 2007.

[18]D. Hilbert, Ueber die stetige Abbildung einerLine auf ein Flachenstuck,'' in Mathematische

Annalen, Vol. 38, pp. 459-460, 1891.[19]J. Kleinberg, Small-world phenomena and the

dynamics of information,'' in Advances in NIPS

14, 2001.[20]W.W. Xue, H.K. Pung, P. Palmes and T. Gu,

Schema matching for context-Awarecomputing, in Proceedings of International

Conference on Ubiquitous Computing

(UBICOMP), pp. 292-301, 2008.[21]D. Hilbert, Ueber die stetige Abbildung einer

Line auf ein Flachenstuck, in Mathematische

Annalen, Vol. 38, pp. 459--460, 1891.[22]Y. Kang, et al., RevisiTour: enriching the

tourisms experience with user-generatedcontent, in Proceedings ofENTER, pp. 59-69,2008.

[23]D. Lopez-de-Ipina, J. I. Vazquez and J. Abaitua,A web 2.0 platform to enable context-awaremobile mash-ups, in Proceedings ofAmI, pp.266-286, 2007.

[24]foursquare,http://foursquare.com/.[25]Gowalla,http://gowalla.com/.[26]J. Zhu, et al., SOLE: Context-aware sharing of

living experience in mobile environments, inProceedings ofMoMM, pp. 366-369, 2010.

[27]kSOAP2,http://ksoap2.sourceforge.net/.

http://www.getjar.com/http://www.getjar.com/http://www.getjar.com/http://www.symbian.org/http://www.symbian.org/http://www.symbian.org/http://www.apple.com/iphone/ios4/http://www.apple.com/iphone/ios4/http://www.apple.com/iphone/ios4/http://www.android.com/http://www.android.com/http://www.android.com/http://research.nokia.com/research/projects/mobile-web-serverhttp://research.nokia.com/research/projects/mobile-web-serverhttp://research.nokia.com/research/projects/mobile-web-serverhttp://www.uddi.org/pubs/uddi_v3.htmhttp://www.uddi.org/pubs/uddi_v3.htmhttp://www.uddi.org/pubs/uddi_v3.htmhttp://www.jini.org/wiki/Main_Pagehttp://www.jini.org/wiki/Main_Pagehttp://www.jini.org/wiki/Main_Pagehttp://foursquare.com/http://foursquare.com/http://foursquare.com/http://gowalla.com/http://gowalla.com/http://gowalla.com/http://ksoap2.sourceforge.net/http://ksoap2.sourceforge.net/http://ksoap2.sourceforge.net/http://ksoap2.sourceforge.net/http://gowalla.com/http://foursquare.com/http://www.jini.org/wiki/Main_Pagehttp://www.uddi.org/pubs/uddi_v3.htmhttp://research.nokia.com/research/projects/mobile-web-serverhttp://research.nokia.com/research/projects/mobile-web-serverhttp://www.android.com/http://www.apple.com/iphone/ios4/http://www.symbian.org/http://www.getjar.com/