A Context-Oriented System For Mobile Devices

A CONTEXT-ÜRIENTED SYSTEM FOR MOBILE DEVICES Ismael Cuadrado Cordero1, Luis Miguel Soria Morillo 1, Juan Antonio Ortega Ramírez1 and Luis González-Abril2 1: Dept. ofComputer Languages and Systems oflJniversity ofSeville, 2: Dept. of Applied Economic I oflJniversity of Seville ABSTRACT Our work provides developers of context-based application for mobile devices a framcwork for developing comprehensive and adaptable solutions that can interacts each other through a set of functionalities aJl(I interaction methods for building secure applications easily. On the other hand, our work provides a platform to reduce the energy consumption ofthe devices; due to the reuse offunctionalities. To do this, we have designed a layered architecture that allows interaction between applications a.nd context oriented services transparently to users. The main !ayer of our architecture (Core !ayer) provides a too] that allows communication between adjacent layers. Moreover, using our architecture, developers can design context-based applications in a simpler way, a very important goal in order to increa.sing nwnber a.nd functionalities of this kind of applications on mobile devices. Furthermore, our architecture allows the reuse ofknowledge bet\veen developers. During our work, OSGi technology has been used in mobile phones, cutting-edge research in the field. l. INTRODUCCIÓN Everyday, we see that the development of mobile device technology has been increased with the aim of improving the user experience. Thus, ali progress of thcse technologies is focused on offering more and more features that are, in most cases, und';:rused. This is because most users do not have the experience and skills necessary to improve the use of the system. For this reason, there is a large segment of population without access to these new technologies. Is in that point when software should offer users the ahilitv to irnprove the use of those advances. The goaÍ of sotlware technologies for mobile devices must be not interactive -highly functional systems, so user obtains more functionalitics with little interaction as possiblc. Today's users are looking for a system that can be used in their daily lives without an active control. That's the main reason for thc cmergence of context-oriented applications. This kind of application is booming a.nd there are a lot of developers specialize in these. The disadvantage of these applications lies that their development is too complex for the average developer. That means that only a small set of applications ma.kes good use of resources. In addition, a user wishing to use severa] context-based applications should install ali these different appl ications 011 the same device. That affects the user cxpcrience, which should set different front-ends for clifferent applications. Our architecture is designed with the goal of solvi.ng these problems. lt can improve system performance and simplifies development. Furthermore, the use of architecture offers great potential for future applications. This is because an applica.tion developer can reuse the code generated by a.nother developer, with its layered architecture. For these reasons, we believe that our architecture is importan! for research in the field of context-orientes systems on mobile devices. II. RELATEDWORK There are context-oriented systems that use property hardware ((1), [2] and [5]) a.nd those that use general purpose hardware ([3], (4] and [6]). We will focus on the second kind of devices, due to its versatilitv and price. In the other hand, general purpose systemi have the handicap of limitations on data rccovery. Our software must wrestle with this handicap. History ofthe context-oriented systems begins at year 1991. 0n this year, Mark Weisser used on the first time the word 'pervasivc', meaning the integration of a device in the daily life of users. Following the above definition, Want, Hopper et Al., describe context oriented systems like "a strong part into 'pervasive' systems". At the same time, they present their application for loca.tion 'Active Badge Location System' (18). This is considered the first context oriented application. Middle in the '90s, operating the boom of context-oriented systems, thanks to applications like [12], [16] and ( 17). The most extended classification of these systems is what Chen [7] made: Á ,l Direct Access to Sensors. Middleware based: Layered architecture. Generally, this typology only handles a kind of context. Context server: Can handle more than a context, reusing generated data and code. Independent of the architecture, it is necessary to define an ontology. This is important for applications can access to data context. According to Korpipfüi and Mantyjarvi [20], most important goals on an ontology definition must follow four dictates: simplicity, flexibility and extensibility, generic and expressive. Most used ontologies are RFD (used in (8], [9] and [I O]) and OWL (used in [ 11], [! 3], [14] a.nd [15]). Hl. OSGI Layers communication is possible thanks to OSGi technology. This technology is far used in lots of different fields. However, OSGi has not been regularly 1? IIH d In mobile devices. Integration of this technology t II lhl íleld is a bet on modernity and future. 'I h llrRl problem of this technology on mobile 11 vi ' H Is because the a.rchitecture of these devices is 11dl ully difforent to PCs. Java virtual machine in PCs 11 0111111011 to ali applications, that is, there is only one 1111101 machine. However, smartphoncs virtual 111 •hlnc bchnvior is not the same. In this case, each ¡ ¡111 ·ut Ion is running on a different virtual machine, so 11 d ulvik for Android operating system. Thus, due t S I communication protocol needs to share 111 A8 ¡¡ s between applications, is required that ali 1¡ rll otlon nm in the sa.me environment. To solve this th uwbuck, there are three altematives: ),, OSGi Alliance standard. In this case, we must solve the communication problem by using logs file interconnection. ;. OSGi alternative protoco/s. There are severa! parallel protocols to the original created by OSGi Alliance. The problem of these protocols is that haven't a common architecture and functionality. OSGi proprietal)' implementations. Sorne enterprises have developed OSGi implementations, creating its specific environments. The main problem of these solutions is that applications must be run over a proprietary platfom1 and not directly over the.NM. Wc was choice Apache Felix, an OSGi lmplcmcntation that can be modified for its use on rnohile devices. IV. ARCHITECTURE Wc have defined a layercd architecture based in a ontcxt scrver. The mainly purpose of the architecture 1 to reuse data provide by embedded sensors in smurtphones, and avoid the computational cost derived from the processing of these data. lt mea.ns that d vclopcrs can build applications more complex in an usier way lid, of course, reduce the computational ·ost and hence, the energy expenditure associated. lJslng this architecture we expect that more uprlications can use the device, improving its behavior, by using ali its resources. On this way, we have defined thc íollowing layered architecture: Figure l: General architecture structurc V. CONTEXT PROVTDER Toe context providers' layer is designed to store ali objects which goal is to recover ali context data provides by the device. When a developer wants to det.ermine a contcxt, firstly it must install a 'context provider' which will recover ali context information data. When a 'context provider' determines a new context, it will send to the next ]ayer. This communication between layers is established using an Ontology defined for ihe purpose. An exa.mple for a context provider is an object that sniffs the location sensors: looking for the cu1Tent Iocation. This can be the definition of a location context. This hypothetical object is developed to compute prox1mlly to a specific location and determines a context based in the distance to the location (High, medium or low). The development of context providers must follow an established structure. This structure is defined in order to improving the operation ofthe system. VI. CORE On this architecture, the harder computing is processed in the core layer. This !ayer is in charge of data processing and store. When a context provider sends new data to the core !ayer, it applies a set of preprocessing steps. Then, it stores those data. At the end, it processes ali data and sends a message to the application !ayer ifneccssary. r e v r e 3 3 3 n . e 3 — o f - t - o | ^ ^ r e " - J - r e r e ; ^ ^ " s E . g - o c t q a r e S r e 2 3 . o '