international journal of pervasive computing and ... · international journal of pervasive...

International Journal of Pervasive Computing and CommunicationsEmerald Article: Perception framework for supporting development of context-aware web servicesEkaterina Gilman, Xiang Su, Oleg Davidyuk, Jiehan Zhou, Jukka Riekki

Article information:

To cite this document: Ekaterina Gilman, Xiang Su, Oleg Davidyuk, Jiehan Zhou, Jukka Riekki, (2011),"Perception framework for supporting development of context-aware web services", International Journal of Pervasive Computing and Communications, Vol. 7 Iss: 4 pp. 339 - 364

Permanent link to this document: http://dx.doi.org/10.1108/17427371111189665

Downloaded on: 20-12-2012

References: This document contains references to 31 other documents

Citations: This document has been cited by 1 other documents

To copy this document: [email protected]

This document has been downloaded 101 times since 2011. *

Users who downloaded this Article also downloaded: *

Ekaterina Gilman, Xiang Su, Oleg Davidyuk, Jiehan Zhou, Jukka Riekki, (2011),"Perception framework for supporting development of context-aware web services", International Journal of Pervasive Computing and Communications, Vol. 7 Iss: 4 pp. 339 - 364http://dx.doi.org/10.1108/17427371111189665



Access to this document was granted through an Emerald subscription provided by UNIVERSITY OF OULU For Authors: If you would like to write for this, or any other Emerald publication, then please use our Emerald for Authors service. Information about how to choose which publication to write for and submission guidelines are available for all. Please visit www.emeraldinsight.com/authors for more information.

About Emerald www.emeraldinsight.comWith over forty years' experience, Emerald Group Publishing is a leading independent publisher of global research with impact in business, society, public policy and education. In total, Emerald publishes over 275 journals and more than 130 book series, as well as an extensive range of online products and services. Emerald is both COUNTER 3 and TRANSFER compliant. The organization is a partner of the Committee on Publication Ethics (COPE) and also works with Portico and the LOCKSS initiative for digital archive preservation.

*Related content and download information correct at time of download.

Perception frameworkfor supporting development

of context-aware web servicesEkaterina Gilman, Xiang Su, Oleg Davidyuk,

Jiehan Zhou and Jukka RiekkiDepartment of Electrical and Information Engineering and Infotech,

University of Oulu, Oulu, Finland

Abstract

Purpose – Context-awareness is an essential property of any pervasive system perceiving itsenvironment. Such a system captures and processes context, i.e. the features describing the relevantaspects of environment state and user behaviour. However, development of these systems still requiressolving a number of research and engineering challenges. The purpose of this paper is to proposeperception framework, a RESTful middleware which simplifies and accelerates the development ofpervasive systems. Perception framework allows constructing services’ application logic using rulesand context. Moreover, it collects sensor data and produces the context information that is required forthe rules. The authors present the architecture, design, complete implementation, and prototype-basedverification of perception framework.

Design/methodology/approach – Development of context-aware services is achieved with a novelarchitecture supporting building of the logic of web services using rules which directly manipulate theavailable elementary context represented with the Web Ontology Language (OWL) ontology. Theserules are described using the Rule Interchange Format (RIF) with support for different rule languages.The implementation of this framework is aligned with RESTful principles, providing a lightweightand flexible solution for large-scale context-aware systems.

Findings – The fully implemented prototype verifies the feasibility of constructing the logic ofcontext-aware web services with the rules supported by perception framework.

Originality/value – The contributions of this paper include: the requirement specification for ageneric context-aware pervasive middleware; and the design and implementation of the framework(i.e. perception framework) supporting the development of context-aware web services. The perceptionframework includes a generic rule-based reasoner allowing developers to use several RIF-compliantrule description languages.

Keywords Internet, Programming languages, Pervasive computing, Context-aware middleware,Context modelling and reasoning, Pervasive service creation

Paper type Research paper

1. IntroductionContext-awareness is an essential feature for pervasive computing. It refers to as anability to use and manipulate the circumstantial information to detect relevant situationsand adapt behaviour accordingly (Springer et al., 2008). A context-aware system should

The current issue and full text archive of this journal is available at

www.emeraldinsight.com/1742-7371.htm

This work was carried out in the Pervasive Service Computing project funded by the UbiquitousComputing and Diversity of Communication (MOTIVE) program of the Academy of Finland. Thefirst author would like to thank GETA (Graduate School in Electronics, Telecommunications andAutomation) for funding. The second author would like to thank the Infotech Oulu GraduateSchool and NOKIA Foundation for funding.

Perceptionframework

339

Received 22 February 2011Revised 17 June 2011

Accepted 20 July 2011

International Journal of PervasiveComputing and Communications

Vol. 7 No. 4, 2011pp. 339-364

q Emerald Group Publishing Limited1742-7371

DOI 10.1108/17427371111189665

be able to capture context from heterogeneous resources and provide appropriateconclusions based on context analysis.

Designing context-aware pervasive systems is a complex task. Wei and Chan (2007)specified four basic issues the developers of context-aware systems should consider:what is the context, how to acquire it, how to represent it and how to adapt to it. Severaldefinitions of context have been presented, e.g. in Schilit (1995) and Zimmermann (2007).We consider context as:

[. . .] any information that can be used to characterize the situation of an entity. An entity is aperson, place, or object that is considered relevant to the interaction between a user and anapplication, including the user and applications themselves (Dey, 2001).

Usually, context is divided hierarchically into levels. Low-level context provideselementary context. Higher-level context is built by applying recognition schemes ordifferent reasoning techniques to the lower-level context. For example, from the low-levelcontext, such as “light is on”, “microphone is active” and “projector is active”, we caninfer a high-level context “there is a meeting in the room”, which brings more valuableinformation for users and context-aware services.

Context acquisition, context modelling, and context reasoning form how to acquireit (context), how to represent it, and how to adapt to it issues of Wei and Chan (2007).Context acquisition includes obtaining environmental (such as physical or social)information. These data are gathered by using physical sensors, services, manual input,and learning mechanisms. However, the obtained context is not always observableor correct, hence these imperfections should be addressed by system developers(Henricksen and Indulska, 2004). Context acquisition usually requires complexpre-processing of signal data (such as segmentation, feature extraction, classification,and post-processing) before meaningful low-level context can be obtained. Moreover,in order to get a meaningful context, data from several sensors should be combined, thisis called sensor data fusion (Nakamura et al., 2007). To be able to use the context, it shouldbe formally represented, that is, modelled. Wei and Chan (2007) define context modellingas “representing, structuring and organizing contextual data and relationship betweenthem, in order to facilitate the storage and operations of them”. Many studies addressdifficulties of mapping the context to the formal structures, such as ontologies(Cafezeiro et al., 2008; Segev and Gal, 2007). Context reasoning techniques help to verifyand validate context to support system consistency. They also allow discoveringknowledge from implicit context and inferring high-level context. Finally, contextreasoning can trigger system adaptation based on recognition of the context-dependentsystem behavioural patterns.

Besides these issues, other challenges need to be tackled, such as conflict resolution,robustness and consistency support. Conflict resolution support is necessary for highlydistributed systems, where each component might be used or modified by others.Various conflict resolution mechanisms have been suggested. For instance, Park et al.(2005) considered conflict resolution as a minimization problem, Chae et al. (2007)suggested to use a weight-based resolution algorithm in conflict graph model, Capra et al.(2003), in their turn, proposed a microeconomic sealed-bid auction mechanism.Robustness and consistency support are necessary to have a stable system. System anduser decisions or actions should not transfer the system in an inconsistent state. Systemmaintenance is another important issue. Users should be able to understand why

IJPCC7,4

340

a system behaves in an unexpected way and how to correct it (Zimmermann, 2007;Hardian et al., 2008; Barkhuus and Dey, 2003; Vermeulen et al., 2010).

An appropriate middleware would help to reduce the efforts for building context-awaresystems, by dealing with the underlying infrastructure (hardware, operating systems, andso on) and providing reusable software components and application interfaces forend-applications (Mahmoud, 2004). However, the distributed and mobile nature ofpervasive systems makes it difficult to develop a general and reusable middlewaresolution like that.

This paper presents perception framework, a service-oriented middleware forcontext-aware pervasive services, facilitating their development, deployment, andmaintenance. We define a pervasive service as an atomic web service, which utilizescontext to provide certain functionality or response that may affect its environment. Thefocus of perception framework is above the low-level issues, such as hardwareand technologies. That is, we assume that an underlying infrastructure, such as networkconnectivity and servers, already exists, so that the components of perceptionframework can be deployed and interact with each other.

Our framework is inspired by Kim and Choi’s (2007) research. In comparison to theirwork, we introduce new design solutions and components. As Kim and Choi’s work, ourperception framework allows constructing services’ application logic using rules andcontext. That is, it supports context-based service creation, rather than interface-based.Developers operate with elementary contexts of context ontology and create rule filesdescribing the service logic, instead of dealing with a set of programming interfaces.Isolation of rules from compiled services allows more flexible service management,because rules can be modified without system recompilation. We do not restrict userswith our own artificial language for writing rules, but use the Rule Interchange Format(RIF)[1]. Hence, there are more opportunities for service development. In other words,we provide a general reasoner. Currently, our framework supports two reasoningapproaches: logic programming and production rule systems.

The contribution of our paper is two-fold: first, we introduce requirements for a genericcontext-aware middleware. Second, we present conceptual design, implementation, andverification of a context-aware framework, i.e. perception framework, which includes newcomponents and simplifies the development of pervasive services. We implement ourframework using RESTful approach, which enables a flexible and lightweight solutionfor large-scale context-aware systems.

The rest of the paper is organized as follows: Section 2 discusses related work andSection 3 presents requirements for a context-aware middleware. Section 4 describes anarchitecture and context model for perception framework, and the following sectionpresents the design of the perception framework. Implementation and verification areprovided in Section 6, and we conclude the article with discussion in Section 7.

2. Related workA considerable effort has been made to support the development of context-awareapplications. Different design and technology approaches have been utilized. We startour analyses from solutions implemented without using web services.

Context Toolkit (Dey, 2000) is one of the most cited works on context-aware applicationsdevelopment support. The toolkit consists of widgets, interpreters, aggregators andservices. Widgets collect information from the environment, hiding the complexity

Perceptionframework

341

of gathering and managing context. Interpreters abstract low-level context into higherlevel forms. Aggregators collect all the context about a given entity. Services realizechanges to the environment using actuators. Newberger and Dey (2003) enrich the toolkitwith monitoring and control facilities. Later et al. (2005) try to overcome context ambiguityvia mediation, that is, a dialogue between a user and the system. Although Context Toolkitis applicable for a wide variety of the applications, it lacks some features the large systemsshould possess, for instance, conflict resolution support and a formal context model.

Gaia (Roman et al., 2002) is a metaoperating system, built as a distributed middlewareinfrastructure that coordinates software entities and heterogeneous networked devicesof a physical space. Gaia supports the development and execution of applications foractive spaces – ubiquitous computing environments in which users interact withdevices and services. Gaia’s context infrastructure consists of the following components:context provider gets context from sensors or other data sources, context synthesizerobtains context from context providers and derives higher-level contexts to applications– context consumers, context provider lookup service is used by context providers toadvertise the context they provide, and context history component stores historicalcontexts.

Schmidt (2002) proposes a layered architecture to synthesize context fromheterogeneous sensors and equip mobile devices and surrounding environments withcontext-awareness. The sensor layer gathers low-level data from heterogeneous sensors.The cue layer produces cues, a cue is an abstraction from the output of a single sensorand represents a feature extracted from the sensor’s data stream. The context layeraggregates the data from sensors and transforms these data into context. The scriptinglayer provides mechanisms to use context, by reacting to entering, leaving, and being ina context. Schmidt’s research is more concentrated on low-level issues, such as contextacquisition.

Mitchell’s (2002) work concentrates on supporting the development of mobilecontext-aware systems. The key concept of her framework is the context service,representing any entity that is capable of providing context to the rest of the system andrepresents an abstraction over the underlying infrastructure. Mitchel considers usermobility, as well as conflict resolution support, but no intelligent components for contextinformation, like reasoners, are built in her work. Instead, she uses context translatorservice for transferring the context from low to high level.

Shehzad et al. (2005) propose a middleware architecture for context-aware ubiquitouscomputing systems (CAMUS). CAMUS supports gathering context from sensors,incorporates different reasoning mechanisms for deriving the higher-level context, anddelivers the appropriate contexts (or notifies about their changes) to applications. The corecomponent of their architecture is feature extraction agent, which is a softwareabstraction, hiding all physical devices’ communication details, specific output formatsand algorithms for data processing, providing a unified manner to work with physicalsensors. Context is stored in a relational DBMS. A reasoning module includes severalreasoners, such as description logics, neural nets, Bayesian nets, HTN planning and fuzzylogic, which handle the facts of the repository and produce high-level contexts. CAMUS isa solid middleware, supporting basic context-awareness; however, conflict resolution anduser support are not considered by this research.

Korpipaa (2005) presents a blackboard-based software framework for context-awaremobile systems. Context manager is the central node of this framework: it stores context

IJPCC7,4

342

received from any source, and serves it to clients. Clients can query data directly or theycan subscribe to various context changes. Context source connects to a data sourceand delivers context data to context manager. Context abstractor performs a patternrecognition process and includes either the feature extraction or the classification phase,producing human-understandable, easy to use descriptions of raw data. Change detectortransforms the measured signals to events that can be utilized by applications.Application controller encapsulates the inference and activates application actions andgenerates system events based on the context events on behalf of applications.It subscribes from the context manager to indications about context changes. Withcustomizer, the user can define the context-based actions a mobile application shouldrealize at run time. In contrast to others, Korpipaa presents the blackboard-basedframework: components communicate via a common message board, acting like acentralized knowledge base.

Bardram (2005) suggests the Java Context Awareness Framework (JCAF), which isan event-based infrastructure, where components cooperate in a loosely coupledpeer-to-peer fashion. JCAF consists of the following components: context services handlethe context in a specific environment, such as operating room. Context clients arecontext-aware applications, which access entities’ context, either following therequest-response schema or by subscribing as an entity listener, listening to changesof specific entities. Context monitor provides the context information by cooperatingwith some kinds of sensing devices. Context actuator works together with one or moreactuators to affect or change the context. Remote communication is implemented withJava RMI. JCAF handles security issues.

Zimmermann (2007) emphasizes the importance of end-user involvementin maintanance of ubiquitous systems, such as how to correct system behaviour ifsomething goes wrong. His architecture is layered: sensor layer is responsible for rawdata acquisition from distributed sensors, abstraction and fusion; semantic layer definesthe context model of an application and augments the sensor layer’s value vectors withapplication semantics; control layer encodes the behaviour of a context-awareapplication. Application adaptation is realized by triggering, filtering, and executionengines; actuator layer handles the connection back to the environment by mapping thedecisions taken by the control layer to real-world actions.

Also some web service-oriented systems have been proposed for pervasiveapplications development. Keidl and Kemper (2004) present a context framework,facilitating the development and deployment of context-aware adaptable web services.They suggest to exchange context information within SOAP message headers. Althoughthe framework does not address issues discussed above, it provides a stable solution forcontext exchange.

CoWSAMI middleware facilitates context-awareness in open ambient intelligenceenvironments (Athanasopoulos et al., 2008). This middleware facilitates the provisionof context sources dynamically as they become available, for instance, when a userchanges the location. This work utilizes web services as the interfaces to context sourcesand dynamically updatable relational views for storing, aggregating and interpretingcontext. Context rules provide mappings specifying how to populate context relationswith respect to different context sources.

Kim and Choi (2007) present SOA middleware to context-aware applications foracquiring, interpreting, processing and transferring context. Their framework consists

Perceptionframework

343

of context provider services, context aggregator service, context observer service,context discovery service, context ontology reasoner service and context query service.The context model is presented as an ontology and communication between componentshas context-oriented nature, rather than interface-based. This middleware seems to begeneral and suitable for a wide variety of applications.

These frameworks provided by the research community are starting to provide alsohigh-level functionality, such as consistency support and control and manipulation toolsfor users (Dey and Mankoff, 2005; Korpipaa, 2005; Zimmermann, 2007). Moreover, theyare becoming more loosely coupled. Both our system and the systems described in thissection provide the support to build pervasive systems. Some research works providestronger support for low-level context acquisition tasks, such as Schmidt (2002), othersmore concentrate on user support like Zimmermann (2007). However, some suggestions(Dey, 2000; Bardram, 2005) lack essential functionality, such as conflict resolution supportor history management. Conceptually, perception framework resembles these solutions.However, to the best of our knowledge, only in perception framework, a service developercan define service-specific adaptation in several RIF compliant rule languages. Contextreasoning has very advanced support in Shehzad et al. (2005) and Athanasopoulos et al.(2008). Perception framework does not yet provide such a variety of reasoningfunctionality; currently, it implements only a rule-based inference. Related work proposesdifferent approaches to context modelling, such as first-order logic (Roman et al., 2002),ontology modelling (Kim and Choi, 2007; Shehzad et al., 2005; Korpipaa, 2005),object-oriented approach (Mitchell, 2002; Bardram, 2005), and descriptive attributes orkey-value pairs approach (Zimmermann, 2007; Dey, 2000; Schmidt, 2002; Keidl andKemper, 2004). Perception framework utilizes the ontology context model approach.As Zimmermann (2007), we address maintenance issues as well, although at the currentstage, our framework provides no complete support. Currently, only service developerscan modify the behavior of their services by looking at their reasoning behavior.

Our work is inspired by Kim and Choi (2007) research and the architectural solutionfor perception framework resembles theirs. However, the implementation andinterpretation of components differs. Also, our framework provides conflict resolution,robustness and consistency support, clear separation between sensors and actuators,and a general reasoner. Hence, we claim that perception framework provides moreadvanced support for pervasive service developers. In addition, the context model isdifferent. Perception framework, as middleware of Kim and Choi’s, emphasizescontext-based atomic service development, rather than interface based, found in mostother works. We are not aware of any related work suggesting the same set offunctionality as perception framework provides.

3. Requirements overviewPerception framework aims to provide a generic middleware solution for pervasiveapplication development across various application domains. After analyzing therelated work, we specified the following requirements perception framework shouldfulfil in order to provide sufficient support for developing pervasive services.

Clear separation of concernsThe framework should provide a clear decomposition between the pervasive servicephases, such as context acquisition, context modelling, context management and servicecontrol to provide structured and easy development support.

IJPCC7,4

344

Loosely coupled distributed architectureThis allows building pervasive services from a set of reusable software components. Weargue that web services-based implementation is an appropriate solution, becausesystem components can be easily deployed, reused and shared.

Flexible communication modelsLoosely coupled service-oriented structure enables flexible communication modelsbetween system components. Framework components should provide means for bothsynchronous and asynchronous interaction. Synchronous communication supplies basicinteraction between components of the framework, and asynchronous communicationsupports the dynamic nature of context-aware systems, allowing notificationmechanisms, for example.

Support for proactive and reactive awarenessThe framework should provide for services means to specify proactive and reactiveadaptation to environmental and user’s context changes. In addition, the frameworkshould allow users to change manually to the behaviour of the service.

Conflict resolution supportWe require a highly distributed loosely coupled architecture. Hence, discovery andcomposition mechanisms should be able to resolve conflicts, in the case of resource orexecution flow dependencies. In addition, when a pervasive service changes the state ofthe context model, the conflict resolution mechanism guarantees system stability.

Sharable, scalable, and consistent context modelThe context model allows sharing of concepts between the components of theframework and different services. Moreover, the context model should be scalable, thatis, necessary concepts could be easily added to the model. To achieve this, a hierarchicalcontext model design should be considered, so that the most general concepts form thebasis of the model. The service-specific concepts are inherited from these. Anotherimportant characteristic is the consistency of the context model, because inconsistencyintroduces barriers to efficient reasoning.

Storage supportStorage support is needed for different purposes. First, a storage mechanism canfacilitate system recovery: in case of failure, the previous states can be recovered fromthe storage. Second, storage allows users making observations of the system behaviour.This enables users to make corrections when they are unsatisfied with the decisions orbehaviour of the system. Third, a storage supports analyzing context history.

Some requirements are more critical than others. For instance, conflict resolutionsupport is necessary if a framework allows pervasive services to use sharedcomponents. On the other hand, some provide more a convenient environment to workwith, like loosely coupled distributed architecture and storage support. We analyze inthe “Discussion” section how perception framework fulfills these requirements.

Perceptionframework

345

4. Perception framework overviewIn this section, we introduce the architecture design of perception framework andpresent the low-level context model which is used by developers when they constructadaptation rules for their pervasive services.

4.1 Architecture designPerception framework is functionally divided into three main layers (Figure 1). Thelowest, sensing layer, provides mechanisms to retrieve environmental data by usingsensors and manual input. The semantic layer offers mechanisms for context modellingand context reasoning. In other words, it is responsible for annotating data withsemantics and inferring new knowledge. The highest, control layer, offers maintanancefunctionality for perception framework, such as resolving possible conflicts. Data flowsmostly in a bottom-up fashion: each layer delivers its output as input to the layer above it.

Sensing layer. This layer consists of sensors. We classify sensors into physical andlogical sensors. Physical sensors are physical devices, monitoring the environment andmeasuring parameters, such as temperature and lightness. Logical sensors are software

Figure 1.The conceptualarchitecture and interplayof the components ofperception framework

Contextprovider

Context actuator

Contextprovider

Context actuator

Contextprovider

S S S

Context discoverer

1. registering(context, address)Sensor

and low-levelcontext

Database

Context observer

12. subscribe(condition)

Pervasiveservice

2. register(requirements)

RawData RawData RawData

PServicemanager

3. create(ID)

4. contextRulesRequest()

11. listen(context,address, condition)

5. contextRules(rules)

Context reasoner

18. getContextActuator(actuator)

19. changeBehavior(value)

21. reportStatus()

Physical Sensor Logical Sensor Physical Sensor

Historymanager

Conflictresolver

Sensing layer

Semantic layer

20. subscribe(context)

Control layer

17. resolveConflict(actuator)

22. save(result)

24. manageHistory(ID)

23. contextHistoryManagement

8. getContext()

6. contextRequest(context)

10. assignObserver(context,condition)

15. actuatorRequest(actuator,value)

Pervasiveservice

PervasiveservicePervasive services

Servicehandler

16. checkConflict(actuator)

7. getContextProvider(context)

9. contextValue(context,value)

13. result(result)

14. result(result)

Communication(commands,

responses, etc.)

Database

Servicerequirements

database

IJPCC7,4

346

components or services, which provide such information as user profiles and calendars.Sensors can either provide information continuously or on demand.

Semantic layer. This layer consists of sensor database, context providers, contextactuators, low-level context ontology, context reasoner, context observer, and contextdiscoverer. Sensor database provides all information about the sensors utilized in perceptionframework, such as manufacturer, properties they measure, and measurement frequency.

Context provider is a sensor wrapper that relates raw data to concepts of the contextmodel. In Schmidt’s (2002) terminology, it corresponds to the Cue concept. For instance,the accelerometer provides raw acceleration data to activity context provider, whichanalyzes these data and provides “activity” context information, such as walking,running, etc. In other words, Context providers extract features from sensor data andlabel them with concepts. Each sensor can have several context providers, for instanceorientation context provider can be assigned to the same accelerometer, supplying theorientation of the sensor as elementary context.

Context actuator is a communication channel to a sensor. The task of context actuatoris to control the sensor behaviour (e.g. start/stop sensing, increasing volume). Becauseeach actuator performs certain behavioural change, a sensor can have zero, one orseveral associated actuators.

Low-level context ontology contains the low-level contexts corresponding to featuresof sensors. Each context provider and context actuator directly provide context to thislow-level context storage. Service developer builds its service-specific logic flow andhigh-level contexts by utilizing these low-level contexts.

Context reasoner is responsible for executing the logic of pervasive services.It retrieves rule files from the pervasive services. Such a file contains logical operationsusing the low-level context instances, specified in low-level context ontology. Contextreasoner fires rules; however, if some instances are unknown, context reasoner asksthis information from service handler.

Context observer monitors context values and notifies when the required conditionsare met. For instance, context observer can notify service handler when a temperaturevalue becomes equal to ten degrees. Service handler can assign several contextobservers for a certain context provider.

Context discoverer implements a discovery mechanism for context actuators andcontext providers. Its task is to locate the context providers and context actuatorsproducing the requested low-level context or behavioural patterns. Each contextprovider and context actuator must register to the context discoverer. This is done inorder to guarantee that context providers and context actuators are consistent with theLow-level context ontology and can be easily used by service developers. In this versionof perception framework, the discoverer is centralized.

Control layer. Control layer consists of pervasive service manager (pservicemanager),service handler, conflict resolver, and history manager.

All pervasive services communicate with the pervasive service manager. Othercomponents, except service handler, are invisible to pervasive services. Pervasiveservice manager registers all pervasive services and all context providers and actuatorsthe services use. For each registered pervasive service, it creates a personal Servicehandler, which plays the role of the main communication gateway. Service handleris responsible for communication coordination between all framework components usedby one service.

Perceptionframework

347

Conflict resolver is responsible for managing possible conflicts. We define a conflictas a situation facing a collision of pervasive services’ interests. For instance, severalpervasive services may attempt to change the behaviour of a common sensor. Conflictresolver decides if the operation can be performed. Each pervasive service registers thecontexts and actuators it uses to the requirements database, which is used by conflictresolver to make decisions.

History manager keeps track of all obtained context and enables analyzing systembehaviour. History manager allows backtracking and analyzing the context retrieved bythe context reasoner. In the case of incorrect behaviour, a developer can study how such abehavioural pattern was obtained and correct the corresponding rule, if needed. Anotherimportant issue to have the history manager is the analysis of context history.

Behavioural patterns. We explain behavioural patterns with the numbered operationsof Figure 1 in parenthesis. Perception framework is ready to be used when both contextproviders and context actuators have provided their contextual information to thelow-level context ontology and registered to context discoverer (see operation 1 inFigure 1). A service developer utilizes the low-level context ontology to constructbehaviour of his pervasive service. This behaviour is written in the form of rules, such as“If temperature is greater than ten degrees, then set the alarm on”. When the service isdeployed, it registers itself to the pservicemanager (2). Service reports all contextproviders and actuators it uses, together with their priority information. Then,pservicemanager registers the service and its priority information to conflict resolver andcreates a service handler for the service (3). After that, the service handler queriespervasive service for its rules and sends them to the context reasoner (4,5). The contextreasoner analyzes the rules and decides which engine (Jess or Win-Prolog) has to belaunched. Then, it reads the rule file and makes inferences. That is, the reasoning enginefires the rules with satisfied conditions. If context reasoner meets context the value ofwhich it does not know, it asks the service handler to get it (6). The service handler queriesthe context discoverer for the address of the needed context provider, after that, it directlyrequests the value from this context provider (7,8) and delivers this value to the contextreasoner (9). The context reasoner can also ask the service handler to assign the contextobserver for a certain context provider (10,7,11,12). The context reasoner delivers resultsto pervasive service via the service handler (13,14).

This part of framework functionality is close to Kim and Choi’s (2007) work; however,the functional roles of some components are different, for instance pservicemanager andcontext reasoner. Also, perception framework allows to change the behaviour of contextprovider, hence, often the value of context. When context reasoner encounters a ruleabout context actuator in a rule file, it asks the service handler to check if the action ofthis actuator can be performed (15). The service handler sends a request to thepservicemanager to check for all possible conflicts (16). The pservicemanager checks therequirements database. If conflicts exist, the conflict resolver service is requested tomake a decision (17). After the decision has been made, perception framework continuesexecuting as described above, but the context discoverer gives address informationabout the corresponding context actuator (18,19). There are also additional features thatperception framework provides. For example, the service handler can subscribe toa certain context and be notified when it can be provided to subscribers (20). Thecontext discoverer periodically checks if context providers are available (21). Moreover,the history manager saves all reasoning results, hence, this information can

IJPCC7,4

348

be retrieved for the service behaviour analysis (22-24). We give more details aboutcomponents in Section 5.

As can be seen, components of perception framework have clearly defined roles andthe behavior of these components is general, in the sense that it does not depend on anyindividual pervasive service and context changes it may cause. Context changesinfluence only pervasive service behavior, because the context reasoner executes rulesonly when rule conditions are satisfied.

4.2 Context modelPerception framework operates with context and provides facilities for pervasive servicedevelopers to construct high-level context and behavioural patterns by using low-levelcontexts. For perception framework, we consider low-level context as information,characterizing an entity (Dey, 2001). A piece of such information can determine a valuefor an entity’s property. This value is measured by physical or logical sensors orobtained by processing the measurements. Perception framework needs an adequatemodel to label these entity’s property values with concepts, that is, to describe context.

There are many potential knowledge representation approaches to contextmodelling, all with their characteristic strengths and weaknesses. There are differenttypes of context models, such as key-value models, mark-up scheme models, graphicalmodels, logic-based models, etc. We selected the ontology-based context modelrepresentation, because it allows building a scalable and structured vocabulary tree withsemantic support.

In perception framework, each context provider specifies an elementary context aboutan entity, the form of the elementary context, and parameters needed to obtain a value forthat context in the low-level context ontology. For instance, a sensor box mightcontain temperature and acceleration sensors and supply their raw data tocontext providers. Temperature sensor gives data to temperature context providerwhich announces “temperature” elementary context, and accelerometer supplies data toactivity context provider, producing recognized “activity” elementary context, such aswalking, running, etc. The ontology is designed as a well-known two-layered architecture.The upper layer describes the general concepts and their relations, when the lower layerpresents the concrete domain instances. This ontology architecture allows having clearstructure and ability to scale. The ontology is created with Web Ontology Language[2]and is partly shown in Figure 2.

Currently, the ontology consists of five main concepts: sensor, context, actuator,parameter and value. The sensor concept describes the actual physical or logicalsensor, which gives its data to a certain context provider. For instance, the GoogleCalendar service can be used as a logical sensor in our framework. The logical sensorconcept has a set of descriptive properties, e.g. URL. The physical sensor concept isdescribed using an existing sensor ontology (Russomanno et al., 2005). The sensorconcept has mainly informative purposes, specifying which sensor supplies raw data tofeed elementary context. The context concept names the conceptual information that acertain context provider produces. Like in the previous example, calendar can be seen asthe context instance. Each instance of this class has the following data and objectproperties: hasName (a unique name, which is used by framework components to identifythe context), hasDescription (a context description that is mainly provided for the users ofthe ontology), hasParameter (parameters are needed to obtain certain context values),

Perceptionframework

349

hasContextValue (the context value returned by the sensor), hasSource (the instance ofthe sensor which provides this context). The actuator concept describes the behaviouraland contextual changes, linked with the sensor of the corresponding context. Parameterclass describes the parameters that are needed to obtain data from the sensor (e.g. loginand calendar name for calendar). The value concept is used for the context data a certaincontext provider supplies. Value instances can have different properties depending onapplication domain. However, each value should have hasExpirationInterval property,which describes how long this value data are valid for. This guarantees that only validand relevant data are considered by the framework. Some data may be highly dynamic,like weather temperature, while other data are more constant, like names of humans. Anevent can be considered as an instance of value class for the calendar context example.Low-level context ontology is detailed to support a large variety of behavioural patterns.

Figure 2.Simplified low-levelcontext ontology

Context SensorParameter Value

Bus

Weather

Map

Calendar

DateTime

Location

BusValue

DistanceValue

WeatherValue

PhysicalSensor

LogicalSensor

TemperatureValue

HumidityValue

WindSpeedValue

AirPressureValue

CityLocation

GeoLocation

StreetLocation

BusSensor

WeatherSensor

MapSensor

CalendarSensor

GoogleCalendar

CalendarName

UserName

NextEvent

CurrentEvent

GoogleCalendarService

UserPassword

UserParameter

CalendarValue

EventLocation

hasNamehasDescriptionhasURLhasWorkin gMode

hasEventNamehasEventDescriptionhasStartTimehasEndTimehasExpirationInterval

hasNamehasDescription

hasTypehasDescription

hasName

hasCountryNamehasCityNamehasPOST/ZIPCodehasStreetNamehasHouseNamehasRoomName

hasParameter

hasEventLocation

hasContextValue

hasSource

Instances’example

Actuator

CalendarActuator

Class

Legend

Named Individual

Type Of

Object propertyData property

SubClass Of

IJPCC7,4

350

5. Perception framework design5.1 General reasonerThe general reasoner is a rule-based system that enables building service logic byconstructing rules which rely on available low-level context. Service developers are ableto define contextual dependencies and actions according to context changes. perceptionframework supports both forward chaining and backward chaining inferenceapproaches. Forward chaining starts with available data and extracts more data byapplying rules until a goal is reached. In backward chaining, the aim is to determine ifdata supporting the assumed conclusions can be found.

Service developers are required to write service logic rules using the RIF. RIF definesan XML-based specific syntax for describing rules. Hence, it allows transferring rulesbetween different systems utilizing different rule languages. That is, a service developercan use any rule language he/she likes as long as rules can be transferred into the RIFformat. We implement the support for two RIF dialects, RIF production rule dialect(RIF-PRD)[3] and RIF basic logic dialect (RIF-BLD)[4].

We define a compulsory vocabulary service developers must utilize in order to informthe context reasoner about certain dependencies and events. For instance, the contextreasoner cannot implicitly know which context providers need to be observed for a certainchange. For this reason, the rule file must contain a specific marker OBSERVER(context,condition, value) which indicates the context entity that the observer should be assignedto. For instance, a statement OBSERVER(temperature,EQUAL,10) means that theobserver should be assigned to the temperature context and it should inform when thetemperature value equals to ten units. Table I lists all items of the compulsory vocabulary.

The logic flow of the context reasoner is shown in Figure 3. The context reasonerloads the rules from the client service and analyzes them. In the case of any inconsistencyor a problem, the corresponding HTTP response is forwarded to the client service. First,the context reasoner checks the type of rules, backward chaining or forward chaining,and translates these rules into a corresponding engine language. Win-Prolog[5] is usedfor backward chaining and Jess[6] for production rules. Then, all explicitly defined factsand rules are loaded into the engine’s working memory, observers are assigned tocontexts and the engine starts reasoning execution. When the context reasoner does notknow a value of some context, it requests the service handler to provide it. Whenreasoning is completed, the corresponding RESULT message is delivered to the clientservice. The reasoning cycle is restarted when new information is received from thecontext observer, that is, when context changed. Inference proceeds according to servicerules, hence it is static in the sense that the logic flow cannot be modified on the fly, it isonly determined by rules. However, rules execution depends on context only.

5.2 Conflict resolverThe context actuators of perception framework are able to change behaviour ofassociated sensors or state of the environment (for instance switching lights off). Hence,this can affect a pervasive service using the same sensor. Moreover, multiple servicescan try to change the behaviour of the same context actuator. We call these situationsconflicts. The conflict resolver component was designed to handle them.

Two types of conflicts are possible in our perception framework: multiple requestsand multiple usage conflict. Multiple request conflict takes place, when several servicesattempt to access the same context actuator. A multiple usage conflict happens when

Perceptionframework

351

one service accesses a context actuator to change behaviour of a sensor used by one ormore other services.

Our strategy for conflict resolutions is as follows: when registering, each pervasiveservice provides to the pservicemanager the priority information for each contextactuator and context provider it uses. Hence, conflict resolution is centralized inperception framework. The multiple requests conflict can be addressed as a mutualexclusion issue, where a request for some specific context actuator can be considered asentering into a critical section. We avoid the multiple requests conflict with a binarysemaphore solution. The conflict resolver utilizes a first in, first out queue for requests.At any moment, only one service can query a certain context actuator. Each contextactuator has a state variable, a binary semaphore, that has the value “free” when thecontext actuator can be queried and “handling” when the context actuator performs thedecision-making process; hence, it cannot be queried by any other services.

Figure 4 shows the flowchart of the conflict resolver. When the conflict resolverreceives a request for a context actuator, it checks the actuator’s state. If the state ofthe context actuator is “handling” for request, the “handling” message goes to the servicehandler, thus notifying to retry the request later. Otherwise, when the state is “free”,

Item Description Example

FACT (context, value) If the contextual information isknown and it is static, then itshould be presented using thisstatement

FACT (temperature,10) –a temperature value equalsto ten units

PARAMETER (context,contextparameter)

This specifies the datadependencies. For example, whenone context uses another as aparameter

PARAMETER (weather, city)– The weather context uses thecity context as a parameter

RESULT (X) If X is a string, then this string willbe returned as a reasoning result

RESULT (foot)RESULT (WeatherContext)

If X is a context name, then thecontextual value will be returnedas a reasoning result

Specifies for the client servicethe result provided by thecontext reasoner

OBSERVER(context,condition,value)

This indicates the context entitythe observer should be assigned to

OBSERVER (temperature,EQUAL,10)

OBSERVER (context)Condition:{EQUAL, NOT_EQUAL, LESS,LESS_OR_EQUAL,GREATER,GREATER_OR_EQUAL}

If it is used without condition andvalue parameters, the observershould notify whenever the contextchanges

The observer is assigned to thetemperature context and itinforms when the temperaturevalue equals ten units

ACTUATOR(actuator,newvalue)

This indicates that a new valuemust be applied for a givenactuator. Usually, it means that theaction is addressed by the sensorsupporting the correspondingcontext

ACTUATOR(lightActuator,off) – meansthat lightActuator has tomodify the behaviour of thecorresponding sensor andswitch it off

MAIN (for RIF-BLD dialetct) The main rule must be named asthe MAIN. This way, the reasonerknows where to start reasoningfrom

Table I.Compulsory vocabularyfor context reasoner

IJPCC7,4

352

the conflict resolver changes it to “handling”. If the requested action is allowed for thiscontext actuator, the conflict resolver sends an “allow” message to the service handlerand waits for a reply. After receiving a reply, the conflict resolver sets the state to “free”.If the requested action is not allowed, the conflict resolver sends a “reject” message to theservice handler and sets the state to “free”. This simple technique is natural forcentralized conflict management which we use in our framework. Because bothrequesting and requested sites have the time to live policies, this technique mostly worksfine. However, theoretically, there might be a problem when one service endlessly tries togain an access to a certain context actuator. This issue can be then solved by settinga limited number of continuous requests, and when this number is reached, the action isconsidered as “rejected”.

To resolve multiple usage conflicts, we utilize priority policies. All context actuatorsand context providers used by a service are assigned with priority information. For acontext actuator, a priority means a need for a service to access the context actuator.This priority information is a real value in [0,1]; zero means that a service does not needto access the actuator and one means the highest priority, that is, it is very importantfor the service to access the actuator. For the context provider, the priority means thedegree a service depends on a certain context provider. In this case, zero means no

Figure 3.Context reasoner

flowchart

ANALYZE RULES

LOGICPROGRAMMING

(RIF-BLD)?

TRANSFORM TOWIN-PROLOG

ANALYZE CODE,BUILD INTERNAL

CONTEXTREPRESENTATION

START REASONING(FROM MAIN

METHOD IN WIN-PROLOG/FROM

FIRING MATCHINGRULES IN JESS)

YES

NO TRANSFORM TOJESS

RIF RULES FROMSERVICE

QUERY SERVICEHANDLER ABOUT

OBSERVERS,IF ANY

IS CONTEXTVALUE KNOWN?

CONTINUEREASONING

QUERY SERVICEHANDLER TO

PROVIDE CONTEXTVALUE OR FOR

PERMISSION TO USEACTUATOR

YES

NO

IS CONTEXTACTUATOR

REQUESTED?

CONTINUEREASONING

YES

NO

REASONINGCOMPLETED?

NO

YES

REACTION TOCHANGED

CONTEXT: SENDCORRESPONDING

MESSAGE TOSERVICE

END

CONTEXT CHANGED: NEW VALUEFROM CONTEXT OBSERVER

Perceptionframework

353

dependency and one the strongest dependency. Actuator and provider priority valuesusually (but not always) correlate: when a service needs to access an actuator, ingeneral, the corresponding provider has a high dependency value as well.

For each request to access a context actuator, the conflict resolver checks the active(i.e. currently running) services and their context provider dependency values. If one ofthe active services has a higher dependency value for the corresponding contextprovider, the request is rejected. This is because there is another service that dependsmore on the corresponding contextual value. If no other services depend on thecorresponding context provider, the request is accepted. If there are services which havetheir dependency value equal or smaller than the requesting service has, the need forthe context actuator is checked. In this case, the conflict resolver calculates the relativepriority for the requesting service’s Context actuator using equation (1):

Figure 4.Conflict resolverbasic flowchart

CHECK THE STATESTATE(A)

STATE(A) =FREE

STATE(A) =HANDLING

ALLOW(A) = YES

SEND ALLOWMESSAGE AND

SET TTL

APPROVE ORTTL PASSED

STATE(A) = FREE

YES

NO SEND HANDLINGMESSAGE

SEND REJECT MESSAGE

NO

YES

STATE(A) = FREE

CHECKDEPENDENCYVALUE DEP(A)

DOES ANYOTHER

SERVICE HAVEDEP>0?

DOES ANYOTHER

SERVICE HAVEDEP>DEP(A)?

CALCULATE PR,SEE EQUATION (1)

DOES ANYOTHER

SERVICE HAVEHIGHER PR

VALUE?

YES

NOALLOW(A) = YES

ALLOW(A) = NO

NO

YES

ALLOW(A) = NOYES

NO

DECIDE IFACTION ISALLOWEDALLOW(A)

REQUEST FOR CONTEXTACTUATOR A

YES

NO

FOR ANYOTHER

SERVICE k ANDVALUE L

|PRk – PR|<L?

ALLOW(A) = NO

ALLOW(A) = YES

NO

YES

IJPCC7,4

354

PRij ¼ Aij þ Pij 2

PNk¼1ðAkj þ PkjÞ2 Aij 2 Pij

N 2 1ð1Þ

wherePRij is the priority value for the service i and the corresponding actuator j.Aij is theservice i’s priority for the context actuator j. Pij is the dependency value for thecorresponding context provider j of the service i. N is the number of active services ofperception framework for whichAijþ Pij . 0. With this priority estimation, the conflictresolver can get an approximate numeric estimation of the consensus between need anddependency for a certain context actuator. If PRij has the highest value among otheractive services and for the defined value l and there is no other active service k for whichPRkj 2 PRij

��

�� # l, then the action is allowed, otherwise rejected. Actually, this relative

priority calculation PR can be used to resolve multiple request conflicts. The requestqueue can be sorted according to their PR values and the context resolver chooses thefirst one. Currently, perception framework does not support dynamic conflict-resolving;therefore, the priority values are static.

5.3 History managerThe history manager component is needed for several reasons. First, it allows makingbackups and recovery. Perception framework is based on RESTful web services andhence relies on the stateless HTTP protocol. The history manager saves each successfulinference cycle. Hence, the last consistent state can be obtained in every situation.Second, the history manager enables behaviour tracing: this component supportsdevelopers in observing the behaviour of developed services. In the case of incorrectbehaviour, developers can find out why the reasoning engine came up with somedecision and correct the service rules, if needed.

Currently, the history manager stores the data in a file. Every time the reasoning cycleends, the context reasoner provides the history manager a service identification numberand rules with utilized context values. The history manager stores these values with atimestamp in the file.

6. Implementation and validationPerception framework is based on a service-oriented design and implementationapproach. Hence, all its components are web services and communication proceeds overHTTP. We have selected the REST approach (Richardson and Ruby, 2007; Fielding,2000) for building the framework. In contrast, Kim and Choi’s (2007) middleware isimplemented with SOAP-based services. We find RESTful design more general, flexibleand lightweight. We use JSON[7] as HTTP payload format. All components of theframework have been developed in Java and deployed on Glassfish application server[8].

To validate the framework, we have built the transport assistant service prototypeusing perception framework. The following scenario describes this service:

Alice is a product distributer and her working days are full of meetings. She has a GoogleCalendar account where she marks all her events carefully. She likes to be informed aboutpossible means of transport to the next meeting, according to her weather preferences andmeeting location. She started to use the Transport Assistant Service. This service receivesinformation from context providers and based on user-specific rules informs the user aboutthe possible transport means via email.

Perceptionframework

355

According to the scenario, there are four logical sensors, which provide events,bus schedule, distance between two locations, and current weather. Hence, we havedesigned four context providers: Calendar, Bus, Map, and Weather. All of them utilizecorresponding third party services to access context values. These context providerssupply their low-level context into low-level context ontology. All context providersexcept weather need parameters to provide context. Moreover, all of them have specificContextValues. Figure 2 shows a part of the low-level context ontology for this scenario.Contextual dependencies are shown in Figure 5.

Rules specify user preferences for transport means and constitute the serviceapplication logic. By utilizing a specific vocabulary, the developer can define contextualdependencies. Figure 6 shows a simplified RIF representation syntax for the transportassistant service. Corresponding Win-Prolog code is shown in Figure 7. We emphasizethe specific vocabulary (Table I) in Figures 6 and 7 with bold text.

When the Context reasoner receives service rules, it builds an internal representationof contexts, their known facts and dependencies, and assigns the observers andactuators. As can be seen from Figures 6 and 7, an observer is assigned to calendarcontext. Hence, the observer will inform the reasoner (through the service handler)always when the value of calendar’s context provider sensor changes. As a result, whena new value becomes available, the context reasoner executes a reasoning cycle. Thetransport assistant service can also notify the context reasoner to cancel the calendarobserver.

Reasoning starts from the main method. The first execution line of the main method(Figures 6 and 7) contains Map.Distance, which is unknown to the reasoner. The contextreasoner can solve this problem by analyzing the known dependencies and low-levelcontext ontology to retrieve the required parameters and context from the service handler.

Figure 5.Context dependenciesfor the Transportassistant service

CALENDAR

MAP BUS WEATHER

USERNAME

USERPASSWORD

EVENTLOCATION

CALENDARNAME

TEMPERATUREDISTANCE HUMIDITY

CURRENTEVENT

NEXTEVENT

EVENTSTARTTIME

EVENTEND TIME EVENT

LOCATION

EVENTSTARTTIME

EVENTEND TIME

EVENTNAME

ROUTE

EVENTNAME

INPUT PARAMETER

LEGEND

CONTEXT

DEPENDENCY

CONTEXT VALUE

...

...

IJPCC7,4

356

In this case, map depends on the calendar event locations. Hence, event locations should beobtained first. The context reasoner checks if it knows all needed parameters to query theservice handler about the calendar events. When events are retrieved, the context reasonercan continue with the map context. In this way, the context reasoner builds a completestructure of the contexts used in rules. Then, the inference process continues with theWin-Prolog engine, in this case. The reasoning result is placed within the result operand,which can be an ordinary string or a context value request. In the latter case, the contextreasoner returns the corresponding context value. Figures 6 and 7 show examples of bothcases. The result is returned to the client service. In our case, the context reasoner returnsthe result to the transport assistant service, which formats it for easy reading and deliversthe message to Alice via e-mail.

Figure 6.Simplified RIF

representation syntax forthe Transport

assistant service

Perceptionframework

357

In order to validate whether perception framework simplifies the development ofpervasive web services, we implemented a RESTful web sevice, doing the same task asdescribed in the scenario, but without using perception framework. This pervasive webservice realizes the whole application logic and communication functionality. Wecompared both services with respect to the overall number of source lines of code (SLOC)and network communication overhead, measured as the total number of exchangednetwork packets, their sizes and time delays.

The manually created web service utilizes the same web services to retrieveinformation about user calendar events, weather, distance between events and busschedule to make the decision based on user preferences. As can be seen from Figure 8,the number of SLOC of the manually created web service is approximately three timeslarger than the code of the service created with perception framework.

We also measured the number of network packets sent between the initial webservice and different components of perception framework during the whole lifecycle ofthe service, that is from service registration, till reply confirmation receiving. For themanually created web service, we measured the number of network packets it exchangeswith other participating services. This way we evaluated the communication overheadcaused by deploying web service into perception framework in comparison to themanually created web service. Measurements were conducted with Wireshark[9] analyzeron Windows XP SP3 PCs with Intel(R) Core(TM) 2CPU 6600 2.40 GHz and 2 GB of RAM.

Figure 9(a) shows the total number of exchanged packets for different parts ofthe service lifecycle. Generally, our web services lifecycle consists of registration

Figure 7.CorrespondingWin-Prolog code forthe TransportAssistant Service

Figure 8.Length comparison of webservices’ code bases

8006004002000

Web service created withPerception Framework

Manually createdWeb service

Number of Source Lines ofCode (SLOC)

IJPCC7,4

358

and decision-making phases. For the manually created web service, the registrationphase includes user registration which results in two packets. For the web servicecreated with percpetion framework, the registration phase includes user registration andregistration within perception framework, including assignment of the service handler,registration to conflict manager, and rules retrieving. All these sum up to 12 packets.

The decision-making process for the manually created web service includes queryingthe services for the information and computing the result to send to the user. Thedecision process of the perception framework-based service includes many steps, as canbe seen from decision-making phases bar (Figure 9). These steps are: context retrieving(including the discovery and obtaining of context), history management, observerassignment (including discovery and assigning of observers for certain contexts), andreply handing (including sending the result and retreiving decision confirmations).Figure 9(b) shows the corresponding size of exchanged packets in bytes.

Although Figure 9(a) shows that the web service created with perception frameworkrequires more packets to be sent, most of them are sent between the components ofperception framework only. That is, the communication between the web service andperception framework results in six packets, while for the manually created webservice it equals 14.

Figure 9(c) shows the corresponding communication delays. The registration phaseof the manually created web service and the history management phase of the webservice created with perception framework take just 3 milliseconds, therefore, they arenot visible on the chart. As can be seen from Figure 9 (c), the web service created withperception framework generally requires longer delay to perform its actions, mostlydue to context retrieving which includes the discovery and obtaining of the context.

Our validation demonstrates that perception framework simplifies the developmentof pervasive services. as soon as context providers and context actuators are designedand registered in the low-level context ontology and context discoverer, servicedevelopers need only worry about careful usage of specific vocabulary when designingrules. once built, context providers and context actuators can be shared between manypervasive services. Perception framework suffers from longer communication delays;this is the cost for reducing the complexity of pervasive services design, reducing the sizeof code, the ability to reuse existing contexts within several services and conflictresolution support.

Figure 9.The transmission

parameters of scenarioweb services

0

0 0 2,000 4,000 6,0004,000 8,000 12,000



Decision making phases







10 20

(a) Number of network packets

(b) Bytes load (bytes) (c) Delay (ms)

30 40 50

Registration

Context retrieving

Observer assignment

Decision making

History management

Reply handling

Perceptionframework

359

7. DiscussionMiddleware solutions supporting the development and execution of pervasive systemsis an active research topic. The current trend is to move from traditional distributedsystem development towards a service-oriented approach, which provides additionalscalability and flexibility for the system designers. In this article, we presentedperception framework, which is a RESTful web service-based middleware forcontext-aware pervasive services. We presented requirements for such middleware, itsdetailed design and implementation, and validated the framework using the transportassistant service prototype. Perception framework provides a stable and convenientinfrastructure for development, execution, and maintanance of pervasive services.Perception framework satisfies all the requirements outlined in Section 3 as follows:

Clear separation of concernsEach component of perception framework performs its own task to achieve the overallgoal of the middleware. Perception framework provides support for all layers of thepervasive system (sensing layer, semantic layer, and control layer). Thus, theseparation of concerns is achieved.

Loosely-coupled distributed architecturePerception framework is built with a RESTful web service architecture.A resource-oriented solution allows the framework to be more flexible. The systemrelies on stateless HTTP, hence, no components track their state. However, the historymanager component keeps track of successful reasoning cycles performed for possiblefurther analyses.

Flexible communication modelsPerception framework mainly utilizes a synchronous communication model.Asynchronous communication is supported for interaction between context observerand service handler, and service handler and context discoverer interactions.

Support for proactive and reactive awarenessProactive and reactive awareness are supported with the context reasoner, which isresponsible for firing the pervasive services’ application logic rules.

Conflict resolution supportPerception framework has a specific component, Conflict resolver, which handles twopossible types of conflicts. Multiple requests conflict is handled with a binary semaphoresolution, and multiple usage conflict is resolved by utilizing priority policies.

Sharable, scalable and consistent context modelPerception framework provides the low-level context model, which is shared betweenall system components and pervasive services. The context model is presented with thehierarchical ontology.

Storage supportThe perception framework provides storage support to register the successfulreasoning in order to track the system’s behaviour. In the case of inadequate system

IJPCC7,4

360

behaviour, logical errors can be located easily. In addition, sensor data can be saved, ifneeded, for later usage.

Compared with other works, the general reasoner and conflict resolver of ourperception framework enable a flexible and intelligent way for developers to designpervasive services. The general reasoner can handle various logic approaches; thus,developers can select their preferred language to construct their rules with low-levelcontextual information. The conflict resolver guarantees consistency, as this mechanismtackles the challenge of large-scale deployment of pervasive services.

RESTful web service technology offers perception framework a lightweight,scalable and flexible solution for large-scale context-aware systems. These areimportant features in order to include resource-constrained mobile devices, which havelow processor speed, limited memory and battery life, and unreliable communication.RESTful style offers a good solution over SOAP-based web services, with smallercommunication overhead and faster response time. For the same reason, JSON is utilizedin our implementation to minimize the communication overhead in the system.

We do not address security issues in our perception framework. In the future, wecan utilize secure web service techniques, like OAuth[10]. Such techniques enableexposing protected resources in web services to unreliable clients.

In the future, we will provide the support for dynamic service composition. Moreover,we will develop a more sophisticated conflict resolver. That is, we need to address thedynamics, for example, a run-time increment or decrement of a service’s priority for acontext actuator with every reject or accept message. This can help services to avoidstarvation of resources. Owing to incompleteness and ambiguity of context, we areplanning to add more support for the reasoner, such as probabilistic reasoning modules.Also, better support is needed for the sensing layer. Finally, we will implement andvalidate perception framework with more pervasive scenarios.

Notes

1. RIF Overview, available at: www.w3.org/TR/rif-overview/ (accessed 8 July 2011).

2. OWL Web Ontology Language Overview, available at: www.w3.org/TR/owl-features/(accessed 8 July 2011).

3. RIF Production Rule Dialect, available at: www.w3.org/TR/rif-prd/ (accessed 8 July 2011).

4. RIF Basic Logic Dialect, available at: www.w3.org/TR/rif-bld/ (accessed 8 July 2011).

5. Win-Prolog, available at: www.lpa.co.uk/win.htm (accessed 8 July 2011).

6. Jess, The Rule Engine for the JavaTM Platform, available at: www.jessrules.com/ (accessed8 July 2011).

7. JSON, available at: www.json.org/ (accessed 8 July 2011).

8. Glassfish, available at: https://glassfish.dev.java.net/ (accessed 8 July 2011).

9. Wireshark, available at: www.wireshark.org/ (accessed 8 July 2011).

10. OAuth, available at: http://tools.ietf.org/html/rfc5849 (accessed 8 July 2011).

References

Athanasopoulos, D., Zarras, A.V., Issarny, V., Pitoura, E. and Vassiliadis, P. (2008), “CoWSAMI:interface-aware context gathering in ambient intelligence environments”, Pervasive andMobile Computing, Vol. 4 No. 3, pp. 360-89.

Perceptionframework

361

Bardram, J.E. (2005), “The Java Context Awareness framework – a service infrastructure andprogramming framework for context aware applications”, Proceedings of 3rdInternational Conference on Pervasive Computing (Pervasive 2005), Munich, Germany,8-13 May, Springer, Berlin, pp. 98-115.

Barkhuus, L. and Dey, A.K. (2003), “Is context-aware computing taking control away from theuser? Three levels of interactivity examined”, Proceedings of 5th International Conferenceon Ubiquitous Computing (UBICOMP 2003), Seattle, WA, USA, 12-15 October, Springer,Berlin, pp. 149-56.

Cafezeiro, I., Haeusler, E.H. and Rademaker, A. (2008), “Ontology and context”, Proceedings ofSixth Annual IEEE International Conference on Pervasive Computing andCommunications (PerCom 2008), Hong Kong, 17-21 March, IEEE Computer Society,Los Alamitos, CA, pp. 417-22.

Capra, L., Emmerich, W. and Mascolo, C. (2003), “CARISMA: context-aware reflectivemiddleware system for mobile applications”, IEEE Transactions on Software Engineering,Vol. 29 No. 10, pp. 929-45.

Chae, H., Kim, T.Y., Lee, D.H. and Peter, H. (2007), “Conflict resolution model based on weight insituation aware collaboration system”, Proceedings of 11th IEEE International Workshopon Future Trends of Distributed Computing Systems (FTDCS 2007), Sedona, AZ, USA,21-23 March, IEEE Computer Society, Los Alamitos, CA, pp. 99-106.

Dey, A.K. (2000), “Providing architectural support for building context-aware applications”,dissertation, Georgia Institute of Technology, Atlanta, GA.

Dey, A.K. (2001), “Understanding and using context”, Personal and Ubiquitous Computing, Vol. 5No. 1, pp. 4-7.

Dey, A.K. and Mankoff, J. (2005), “Designing mediation for context-aware applications”,ACM Transactions on Computer-Human Interaction, Vol. 12 No. 1, pp. 53-80.

Fielding, R.T. (2000), “Architectural styles and the design of network-based softwarearchitectures”, dissertation, University of California, Oakland, CA.

Hardian, B., Indulska, J. and Henricksen, K. (2008), “Exposing contextual information forbalancing software autonomy and user control in context-aware systems”, Proceedings ofthe Pervasive 2008 Workshop on Context-aware Pervasive Communities: Infrastructures,Services and Applications (CAPC 2008), Sydney, Australia, 19-22 May, pp. 253-60.

Henricksen, K. and Indulska, J. (2004), “Modelling and using imperfect context information”,Proceedings of the Second IEEE Annual Conference on Pervasive Computing andCommunications Workshops, Orlando, Florida, 14-17 March, IEEE Computer Society,Los Alamitos, CA, pp. 33-7.

Keidl, M. and Kemper, A. (2004), “A framework for context-aware adaptable web services”,Proceedings of 9th International Conference on Extending Database Technology,Heraklion, Crete, Greece, 14-18 March, Springer, Berlin, pp. 829-62.

Kim, E. and Choi, J. (2007), “A context-awareness middleware based on service-orientedarchitecture”, Proceedings of 4th International Conference on Ubiquitous Intelligence andComputing, Hong Kong, China, 11-13 July, Springer, Berlin, pp. 953-62.

Korpipaa, P. (2005), “Blackboard-based software framework and tool for mobile device contextawareness”, dissertation, VTT Publications 579, Espoo.

Mahmoud, Q. (Ed.) (2004), Middleware for Communication, Wiley, Hoboken, NJ.

Mitchell, K. (2002), “Supporting the development of mobile context-aware systems”, dissertation,Lancaster University, Lancaster.

IJPCC7,4

362

Nakamura, E.F., Loureiro, A.A.F. and Frery, A.C. (2007), “Information fusion for wireless sensornetworks: methods, models, and classifications”, ACM Computing Surveys, Vol. 39 No. 3(Article 9).

Newberger, A. and Dey, A.K. (2003), “Designer support for context monitoring and control”, IntelResearch Berkeley Technical Report IRB-TR-03-017.

Park, I., Lee, D. and Hyun, S.J. (2005), “A dynamic context-conflict management scheme forgroup-aware ubiquitous computing environments”, Proceedings of the 29th AnnualInternational Computer Software and Applications Conference (COMPSAC 2005),Edinburgh, Scotland, 26-28 July, IEEE Computer Society, Washington, DC, pp. 359-64.

Richardson, L. and Ruby, S. (2007), RESTful Web Services, O’Reilly Media, Sebastopol, CA.

Roman, M., Hess, C., Cerqueira, R., Ranganathan, A., Campbell, R.H. and Nahrstedt, K. (2002),“A middleware infrastructure for active spaces”, IEEE Pervasive Computing, Vol. 1 No. 4,pp. 74-83.

Russomanno, D.J., Kothari, C.R. and Thomas, O.A. (2005), “Building a sensor ontology: a practicalapproach leveraging ISO and OGC models”, Proceedings of the International Conferenceon Artificial Intelligence, Las Vegas, NV, pp. 637-43.

Schilit, W.N. (1995), “A system architecture for context-aware mobile computing”, Dissertation,Columbia University, New York, NY.

Schmidt, A. (2002), “Ubiquitous computing –computing in context”, dissertation, LancasterUniversity, Lancaster.

Segev, A. and Gal, A. (2007), “Putting things in context: a topological approach to mappingcontexts to ontologies”, Journal on Data Semantics, Vol. 9, pp. 113-40.

Shehzad, A., Ngo, H.Q., Lee, S.Y. and Lee, Y.-K. (2005), “comprehensive middleware architecturefor context-aware ubiquitous computing systems”, Proceedings of the Fourth AnnualACIS International Conference on Computer and Information Science (ICIS 2005),Jeju Island, South Korea, 14-16 July, IEEE Computer Society, Washington, DC, pp. 251-6.

Springer, T., Wustmann, P., Braun, I., Dargie, W. and Berger, M. (2008), “A comprehensiveapproach for situation-awareness based on sensing and reasoning about context”,Proceedings of the 5th International Conference on Ubiquitous Intelligence and Computing,Oslo, Norway, 23-25 June, Springer, Berlin, pp. 143-57.

Vermeulen, J., Vanderhulst, G., Luyten, K. and Coninx, K. (2010), “PervasiveCrystal: asking andanswering why and why not questions about pervasive computing applications”,Proceedings of the 6th International Conference on Intelligent Environments (IE‘10),Kuala Lumpur, Malaysia, 19-21 July, pp. 271-6.

Wei, E.J.Y. and Chan, T.S.A. (2007), “Towards context-awareness in ubiquitous computing”,Proceedings of International Conference on Embedded and Ubiquitous Computing, Taipei,Taiwan, 17-20 December, Springer, Berlin, pp. 706-17.

Zimmermann, A. (2007), “Context management and personalisation: a tool suite for context- anduser aware computing”, Dissertation, Fraunhofer FIT, Sankt Augustin.

About the authorsEkaterina Gilman received her Dipl.-Ing. degree from Arkhangelsk State Technical University(now Northern Arctic Federal University), Russia. Currently, she is working in the IntelligentSystems Group, University of Oulu, Finland towards her PhD degree. Her research interestsinclude context modelling and reasoning, ubiquitous computing, and middleware development.Ekaterina’s publications can be found from: www.cse.oulu.fi/EkaterinaGilman

Xiang Su received his M.Eng degree in Computer Science and Technology fromDonghua University, and he is working as a Research Scientist towards his PhD degree at the

Perceptionframework

363

University of Oulu. He has participated in research projects funded by MOTIVE Programme ofAcademy of Finland, EU Sixth Framework Programme for Research and TechnologicalDevelopment, and National Natural Science Foundation of China. His research interestsinclude lightweight data and knowledge representations, context modelling, and semantic web.Xiang’s publications can be found from: www.cse.oulu.fi/XiangSu

Oleg Davidyuk received his MSc degree in Information Technology from LappeenrantaUniversity of Technology, Finland, in 2004. He is currently working towards his PhD degree inthe MediaTeam Oulu Research Group, University of Oulu, Finland. His research interests includeapplication and service composition, user interaction design, middleware and ubiquitouscomputing. Oleg’s publications can be found from: www.cse.oulu.fi/OlegDavidyuk

Jiehan Zhou is a Research Scientist at MediaTeam and Intelligent Systems Group, ComputerScience and Engineering Laboratory, University of Oulu. He obtained his PhD from HuazhongUniversity of Science and Technology, Wuhan, China. His current research interestsinclude automatic service composition, context awareness, mobile computing, and web services.Jiehan’s publications can be found from: www.cse.oulu.fi/JiehanZhou

Jukka Riekki is a Professor in the Computer Science and Engineering Laboratory, Universityof Oulu, Finland. His main research interests are in interactive, context-aware systems servingpeople in their everyday environment. Currently he studies in several projects: physical userinterfaces, context recognition, sensor networks, and service composition. In these projectshe cooperates with research groups from China, Japan and Sweden. He is a member of IEEE.Jukka’s publications can be found from: www.cse.oulu.fi/JukkaRiekki

IJPCC7,4

364

To purchase reprints of this article please e-mail: [email protected] visit our web site for further details: www.emeraldinsight.com/reprints

international journal of pervasive computing and ... · international journal of pervasive...

Documents