ICT Innovations 2011 Web Proceedings ISSN 1857-7288
87
Multi context models and context-aware frameworks Goran Bakraceski1 , Vladimir Trajkovik1 1
Faculty of Computer Science and Engeneering, Skopje, Macedonia
[email protected],
[email protected]
Abstract. Context-aware computing is a mobile computing paradigm in which applications can discover and take advantage of contextual information. Context-aware applications offer a new opportunity for application developers to develop and adapt systems behavior depending on context information. In this paper we will present a short overview of different types of context modeling approaches and its characteristics. Based on these modeling approaches we present various existing context-aware frameworks that are used for developing context-aware applications. Keywords: context-awareness, context framework, context middleware, context model.
1 Introduction With the appearance of the mobile devices such as smart phones, PDAs, notebooks etc. and their huge potential of mobile processing and services that they are offering, the ubiquitous systems are becoming more and more popular. Introducing the context in the services, making them able to adapt their operations to the current context without user intervention makes their power even greater. But what does the word “context” mean? Many authors has been trying to give their own definition about the meaning of the word “context”, but the most accurate and precise definition of the word context is considered to be the following: “any information that can be used to characterize the situation of the entities (person, place or object) that are considered relevant to the interaction between the user and the application, including the application and the user themselves.” [1]. Many context-aware applications include the context by providing useful data such as location information, time information, weather information (through location and time information) etc. The modeling of these data and its usage in context-aware applications are not simple as it looks. Choosing the right context model may depend of the architecture of the system and compatibility with the context model itself. There are many standard ways of context modeling which relate to the data structure used for representing and exchanging contextual information in the respective system. There are many ways for modeling contextual information but as far as we know, following approaches are most accurate and used approaches that are used for exchanging and storing contextual information in the respective system:
L. Kocarev (Editor): ICT Innovations 2011, Web Proceedings, ISSN 1857-7288 © ICT ACT – http://ictinnovations.org, Skopje, 2012
88
ICT Innovations 2011 Web Proceedings ISSN 1857-7288
• Key – value models. The key – value model is the simplest approach of context modeling. It is easy to manage but it is not capable for sophisticated structuring for enabling context retrieval algorithms. Real usage of this method can be found in [2] where all data are stored as attribute-value pairs. • Markup scheme models. The markup models as it is well known, uses a hierarchical data structuring by use of markup tags with attributes and contents. Also, there are several profiles that are used for this kind of context modeling such as Composite Capabilities/Preference Profile (CC/PP) [3], Comprehensive Structured Context Profiles (CSCP) [4], User Agent Profile (UAProf) [5], Pervasive Profile Description Language (PPDL) [6] etc. • Graphical models. This kind of approach is most applicable and very useful when is used as structuring instrument for relational database in a context based management architectures. It uses Unified Modeling Language (UML) as modeling instrument due to its generic structure. Good example for usage of this kind of context modeling approach is [7] which is context extension to the Object-Role Modeling (ORM) [8]. As it is mentioned in [7] the basic modeling concept (fact) can be categorized according to its persistence to static or dynamic. Static entities in fact remain unchanged for a long time that is not the case with the dynamic entities. We can say that this modeling approach is sufficiently abstract which allows application developers to specify and program at a high level. • Object oriented models. This way of context modeling applies the full power of object orientation like inheritance, reusability, encapsulation etc. Use various objects for representation of different context types but access to this contextual information is provided through specific interfaces only. An interesting usage of context modeling approach is [9]. It uses general object oriented mechanism to represent knowledge about temporal, goal, spatial and global contexts in computer GO. • Ontology based models. Using ontology for context modeling allows a description of the concepts and its relationships. These models are able to apply various ontology reasoning techniques based on formal expressiveness they are using. The main advantage of this kind of context modeling is that we can use already defined core ontologies to model entities. CONON [10] defines 14 core classes to model: Person, Location, Activity or Computational Entity. Another approach for context modeling is CoDAMos [11] which points to the same direction by defining ontology to model Users, Environment, Platforms and Services. But both approaches focus on modeling of profiles for human users and applications which is some kind of limitation because nowadays everything can be declared as contextual information. It seems that the last model, the ontology based model meets all the requirements about simplicity of the relations between contexts, flexibility about adding new
L. Kocarev (Editor): ICT Innovations 2011, Web Proceedings, ISSN 1857-7288 © ICT ACT – http://ictinnovations.org, Skopje, 2012
ICT Innovations 2011 Web Proceedings ISSN 1857-7288
89
element and relation in the ontology and is not limited to special kind of context but rather support different types. This paper is structured as follows: In Section 2, we will provide overview of three types of context aware frameworks their implementation architecture and characteristics. In Section 3 we will present how these existing frameworks are similar to each other and conclude in Section 4.
2 Context aware frameworks In order to simplify the process of development of context-aware application an abstraction framework is needed. This framework should not only provide a client with access to retrieve data, but also permits simple registration of new distributed heterogeneous data sources. In this section we will describe three types of different context-aware frameworks their characteristics, approach for context modeling and architecture. 2.1 Service-oriented middleware for building context-aware services The Service-Oriented Context-Aware Middleware (SOCAM) [12] is actually a framework which includes a set of independent services that performs specific tasks to support context-aware applications. This frameworks support acquiring various contexts from different context providers and interpreting context through context reasoning. The model for modeling context data which is used in this context-aware middleware is ontology based representation of context data. The computing domain is divided in several sub-domains (home domain, office domain etc.) where for each is defined individual low-level ontologies to reduce the complexity of context processing. Each of these low-level ontologies is implemented in OWL [13]. Also, SOCAM classify contexts in two main categories: Direct Context and Indirect context, based on the means by which the context is obtained. The direct context is the context which is directly acquired from a context provider such an internal source (ex. indoor location provider) or external source (ex. weather information server). On the other hand, indirect context is derived by interpreting direct context through context reasoning. As the most common design approaches for distributed context-aware frameworks and this frameworks uses classical hierarchical infrastructure with one central server called context interpreter. As it is shown on figure 1 it consists following components which acts as independent service components: • Context providers. These providers, provides abstract useful contexts from heterogeneous sources and convert them to OWL representations so it can be shared and reused by other service components. • Context interpreter. Acts as context reasoner that do logic reasoning services on context information. • Context database. Database for storing context ontologies.
L. Kocarev (Editor): ICT Innovations 2011, Web Proceedings, ISSN 1857-7288 © ICT ACT – http://ictinnovations.org, Skopje, 2012
90
ICT Innovations 2011 Web Proceedings ISSN 1857-7288
• Context-aware services. Use different contexts and adapt the way that they behave according to the context changes. • Service locating service. Mechanism that connects context providers and context interpreters so the user can locate these services.
Fig. 1. SOCAM architecture
The technology which is used for implementation of this middleware is J2SE 1.3.1 and the context interpreter is implemented using Jena2 which is HP’s Semantic Web Toolkit. As is it said in [12] this prototype system meets the requirements of contextaware systems concerning limited memory and CPU resources in pervasive computing environments. 2.2 Context-Awareness Sub-Structure Same as previous middleware, Context-Awareness Sub-Structure (CASS) [14] is server-based middleware that support context aware applications and enables developers to overcome the common problem with memory and processors constraints of small mobile computer platforms. To support context history, as well as the need to manage data relating to multiple sensors, applications and users, the CASS middleware uses a database for persistent data storage. Also, CASS uses its database not only to save context data but also to store domain knowledge and inference rules needed for creating high-level context. The system architecture of the CASS system is presented of figure2.
L. Kocarev (Editor): ICT Innovations 2011, Web Proceedings, ISSN 1857-7288 © ICT ACT – http://ictinnovations.org, Skopje, 2012
ICT Innovations 2011 Web Proceedings ISSN 1857-7288
91
Fig. 2. CASS architecture
This middleware consist an Interpreter, ContextRetriever, RuleEngine and SensorListener. The SensorListener class is responsible for getting updates from the Sensors and store acquired context information, while the ContextRetriever class is responsible to retrieve the stored context. Both of these classes are allowed to use services from the Interpreter. The ChangeListener is the one which is responsible for communication with CASS and allow mobile device to listen for notification of context change events. Central figure to this design is the RuleEngine (shown on fig 3). The three types of RuleEngine correspond to the three types of context-aware features: Presentation, Execution and Tagging which are identified in [1].
Fig. 3. CASS design
L. Kocarev (Editor): ICT Innovations 2011, Web Proceedings, ISSN 1857-7288 © ICT ACT – http://ictinnovations.org, Skopje, 2012
92
ICT Innovations 2011 Web Proceedings ISSN 1857-7288
This middleware makes separation of context-aware application code from highlevel context reasoning and behaviors and by doing this allows an application’s context reasoning and resulting behavior to be changed without re-compilation. This separation opens the way of making context-aware applications configurable by users. 2.3 Hydrogen Another framework based on layered architecture which tries to overcome the problems with memory and processing power is the Hydrogen framework [15]. This actually is a three layered architecture that separates the concerns of interacting with physical sensors, storing and maintaining the context for the applications and those layers are: Adaptor layer, Management Layer and Application layer (figure 4).
Fig. 4. Hydrogen architecture Adaptor layer. This layer is responsible to get information from sensors about the physical context and provide this data to the upper layer. By doing this, every application from the above layers are capable to access to this context information which is not the case when the applications are trying to access the sensor data directly because of exclusive locking of sensor resources. Management layer. This is the main part of the framework which is responsible for providing and retrieving, as well as storing the context information. Also this socalled Context server offers the stored information via synchronous and asynchronous method to the client applications. Application layer. On top of this layer is the application layer, where different applications are developed to react on specific context changes reported by the context manager. To represent context information this framework uses object oriented approach (fig. 5). The superclass which is used here is the ContextObject and other specific classes inherit from it (LocationContext, DeviceContext, etc). This approach offers simple addition of other types of specific context by only implementing toXML() and fromXML() methods from ContextObject.
L. Kocarev (Editor): ICT Innovations 2011, Web Proceedings, ISSN 1857-7288 © ICT ACT – http://ictinnovations.org, Skopje, 2012
ICT Innovations 2011 Web Proceedings ISSN 1857-7288
93
Fig. 5. Context representation This framework has been developed using the PersonalJava [16] virtual machines Jeode and J2ME [17]. The applications from application layer can be developed in any other language because the communication between them and the context server is enabled by using XML-protocol. Same as other existing frameworks for development of context-aware applications, and this framework attempts to overcome the general problems with processing power and small memory.
3 Frameworks overview In previous section we gave brief overview of three different types of context-aware frameworks that tries to overcome the difficulties about context acquisition, changes, access etc. The main reason for developing such a framework is the separation of concepts between accessing the context data and user components. In Table 1 we have summarized the main aspects of discussed frameworks. Table 1. Summary of discussed frameworks Middleware SOCAM CASS Hydrogen
Architecture Centralized middleware Centralized middleware Three layered architecture
Context modeling OWL Relational data model Object-oriented
Technology J2SE/Jenna2 / PersonalJava/J2ME
As it is shown in Table 1 SOCAM and CASS middleware uses centralized approach, but the Hydrogen middleware is developed by using the advantages of three layered architecture. The context modeling approach of all middleware is different. We have mentioned before that ontologies provide a rich formalism for specifying contextual information. Based on such ontology model reasoning engines can derive new concepts to adapt the service behavior accordingly. Here, the SOCAM model uses the advantages of the
L. Kocarev (Editor): ICT Innovations 2011, Web Proceedings, ISSN 1857-7288 © ICT ACT – http://ictinnovations.org, Skopje, 2012
94
ICT Innovations 2011 Web Proceedings ISSN 1857-7288
ontology model defining domain-specific ontologies and providing very fine grained possibilities for specifying and formalizing context. The technology which is used for development of these frameworks is Java based technology that offer grate portability on different types of systems.
4 Conclusion In this paper we have described different types of context models for context-aware systems and presented three types of context-aware middleware that use these context models for context modeling. All of these frameworks meet the requirements of context aware systems concerning limited memory and CPU resources in pervasive computing environment. With the appearance of this middleware, the development of such a context-aware application is much easier.
References 1. Dey, A.K. and Abowd, G.D. "Towards a better understanding of context and contextawareness". In Proceedings of the Workshop on the What, Who, Where, When and How of Context-Awareness, ACM Press, New York (2000) 2. Henning Maass, “Location-aware mobile applications based on directory services”. In Proceedings of the Third Annual ACM/IEEE International Conference on Mobile Computing and Networking, pages 23-33, Budapest, Hungary, September (1997) 3. W3C Composite Capability/ Preference Profiles (CC/PP), http://www.w3.org/TR/2004/ REC-CCPP-struct-vocab-20040115/ 4. Held A. Buchholz S. and Schil A. “Modeling of context information for pervasive computing applications”. In Proceedings of SCI 2002/ISAS (2002) 5. User Agent Profile (UAProf) Specification, http://www.wapforum.org 6. Chtcherbina E. and Franz M. “Peer-to-peer coordination framework (p2pc): Enabler of mobile ad-hoc networking for medicine, business, and entertainment”. In Proceedings of International Conference on Advances in Infrastructure for Electronic Business, Education, Science, Medicine, and Mobile Technologies on the Internet Italy, (2003) 7. Henricksen K., Indulska J., and Rakotonirainy A. “Generating Context Management Infrastructure from High-Level Context Models”. In Industrial Track Proceedings of the 4th International Conference on Mobile Data Management, Melbourne/Australia (2003) 8. Halpin T. A. “Information Modeling and Relational Databases: From Conceptual Analysis to Logical Design”. Morgan Kaufman Publishers, San Francisco (2001). 9. Bouzy B., and Cazenave T. “Using the Object Oriented Paradigm to Model Context in Computer Go”. In Proceedings of Context’97 (Rio, Brazil, 1997) 10.X.H. Wang, D.Q. Zhang, T. Gu, and H.K. Pung. “Ontology-Based Context Modeling and Reasoning using OWL”. In Context Modeling and Reasoning Workshop (2004) 11.D. Preuveneers, J. v.d.Bergh, D. Wagelaar, A. Georges, P. Rigole, T. Clerckx, Y. Berbers, K. Coninx, V. Jonckers, and K. De Bosschere. “Towards an Extensible Context Ontology for Ambient Intelligence”. In 2nd European Symposium on Ambient Intelligence (2004) 12.T. Gu, H.K. Pung, and D.Q. Zhang, “A Service-Oriented Middleware for Building ContextAware Services”. Journal of Network and Computer Applications (2005) 13.OWL web ontology language, http://www.w3.org/TR/owl-features/
L. Kocarev (Editor): ICT Innovations 2011, Web Proceedings, ISSN 1857-7288 © ICT ACT – http://ictinnovations.org, Skopje, 2012
ICT Innovations 2011 Web Proceedings ISSN 1857-7288
95
14.Fahy P. and Clarke S. “CASS – a middleware for mobile context-aware applications”, Workshop on Context Awareness, MobiSys (2004) 15.Hofer T., Schwinger W., Pichler M., Leonhartsberger G. and Altmann J. “Contextawareness on mobile devices – the hydrogen approach”, Proceedings of the 36th Annual Hawaii International Conference on System Sciences (2002) 16.PersonalJava(TM) Application Environment description, http://www.oracle.com/technetwork/java/pjava-ds-136143.html 17.Java Mobile Edition Environment description, http://www.oracle.com/technetwork/java/javame/overview/index.html
L. Kocarev (Editor): ICT Innovations 2011, Web Proceedings, ISSN 1857-7288 © ICT ACT – http://ictinnovations.org, Skopje, 2012
