[MADRINET'09] Designing a framework to handle context information
•
1 gefällt mir•543 views
The document discusses the design of a framework for handling context information. It first reviews existing context-aware platforms and their approaches to context modeling, reasoning, and other features. It then outlines some general design principles for the framework, including layered architecture, service management, interoperability, and support for context retrieval, quality of context, scalability and user-centered design. Finally, it examines potential technologies and functionalities for the framework, comparing options for messaging, context modeling, and system architecture.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (14)
Ähnlich wie [MADRINET'09] Designing a framework to handle context information
Ähnlich wie [MADRINET'09] Designing a framework to handle context information (20)
Mehr von Josué Freelance
Mehr von Josué Freelance (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
[MADRINET'09] Designing a framework to handle context information
- 1. Grupo de Procesado de Datos y Simulación ETSI de Telecomunicación Universidad Politécnica de Madrid Designing a framework to handle context information MADRINET’09 Ana Hristova, Josué Iglesias, Ana M. Bernardos, José R. Casar {ana.hristova, josue, abernardos, jramon}@grpss.ssr.upm.es
- 2. presentation content context-aware platforms review general design principles functionalities & technologies architecture proposal conclusions future work Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 2 / 13 2
- 3. context-aware platforms - review Context Toolkit CoBrA • widget paradigm • agent-based architecture • new concepts: discoverer, • context modeling: aggregators, interpreters, ... ontologies (OWL – SOUPA) • context modeling: key-value • rule-based inference engine • no reason engine • policies / security / privacy SOCAM Gaia & CMF • service-oriented • uncertainty support architecture (OSGi) • rule-based & probabilistic • context modeling: reasoning (integrated with ontologies (OWL) ontologies) • rule-based reasoning engine Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 3 / 13 3
- 4. context-aware platforms - review Context Toolkit CoBrA • widget paradigm • agent-based architecture • new concepts: discoverer, • context modeling: aggregators, interpreters, ... ontologies (OWL – SOUPA) • context modeling: key-value • rule-based inference engine • no reason engine • policies / security / privacy SOCAM Gaia & CMF • service-oriented • uncertainty support architecture (OSGi) • rule-based & probabilistic • context modeling: reasoning (integrated with ontologies (OWL) ontologies) • rule-based reasoning engine Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 4 / 13 4
- 5. context-aware platforms - review Context Toolkit CoBrA • widget paradigm • agent-based architecture • new concepts: discoverer, • context modeling: aggregators, interpreters, ... ontologies (OWL – SOUPA) • context modeling: key-value • rule-based inference engine • no reason engine • policies / security / privacy SOCAM Gaia & CMF • service-oriented • uncertainty support architecture (OSGi) • rule-based & probabilistic • context modeling: reasoning (integrated with ontologies (OWL) ontologies) • rule-based reasoning engine Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 5 / 13 5
- 6. context-aware platforms - review Context Toolkit CoBrA • widget paradigm • agent-based architecture • new concepts: discoverer, • context modeling: aggregators, interpreters, ... ontologies (OWL – SOUPA) • context modeling: key-value • rule-based inference engine • no reason engine • policies / security / privacy SOCAM Gaia & CMF • service-oriented • uncertainty support architecture (OSGi) • rule-based & probabilistic • context modeling: reasoning (integrated with ontologies (OWL) ontologies) • rule-based reasoning engine Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 6 / 13 6
- 7. general design principles layered approach decoupling: sensing / acquisition infrastructure processing mechanisms service management application logic interoperability to get: reusability extendibility context retrieval etc. quality of context (QoC) scalability user-centered Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 7 / 13 7
- 8. general design principles layered approach formal (semantic) service description services discovery mechanisms service management to keep track of available resources dynamic sources of context information interoperability context retrieval quality of context (QoC) scalability user-centered Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 8 / 13 8
- 9. general design principles layered approach service management common service interfaces interoperability modelling languages communication protocols context retrieval motivate service integration inside enterprises architecture quality of context (QoC) on the Internet scalability user-centered Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 9 / 13 9
- 10. general design principles layered approach service management interoperability delivery of context data from acquisition platform to upper layers context retrieval (processing and final applications) quality of context (QoC) two basic modes of context retrieval: scalability PUSH: enables automatic context delivery (continuous, periodic, event-based, etc.) user-centered PULL: enables on demand context retrieval Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 10 / 13 10
- 11. general design principles layered approach service management interoperability context retrieval QoC context-aware applications quality of context (QoC) user experience scalability context-information + QoC-information user-centered Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 11 / 13 11
- 12. general design principles layered approach service management interoperability to maintain response times in terms of number of users context retrieval operation load quality of context (QoC) able to dynamically add: new sensors new algorithms (inference, scalability discovery, etc.) new client applications user-centered etc. Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 12 / 13 12
- 13. general design principles layered approach service management interoperability context retrieval quality of context (QoC) scalability user does not adapt to the system system transparently adjust to the user behaviour and preferences user-centered privacy constraints Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 13 / 13 13
- 14. [functionalities] architecture servlets messaging Java classes dynamically process HTTP requests context context construct XML responses modeling reasoning easy to implement architecture universal client (just http, no matter implementation) architecture no service registry or discovery technological platform service-oriented approach input parameters unknown scalability interoperability number of users response times reusability Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 14 / 13 14
- 15. [functionalities] architecture servlets messaging web services Java classes dynamically process HTTP requests machine – machine interaction over context context construct XML responses networks modeling reasoning well-established standards: XML, SOAP, easy to implement WSDL and UDDI architecture universal client (just http, no matter implementation)from language and platform independent architecture description language: WSDL no service registry or discovery dynamic service discovery: UDDI technological platform service-oriented approach no automatic context data aggregation scalability XML-HTTP are not most appropriate for interoperability number of users real-time applications response times reusability Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 15 / 13 15
- 16. [functionalities] architecture servlets messaging web services Java classes OSGi dynamically process HTTP requests machine – machine interaction over context context construct XML responses networks component framework for Java dynamic modeling reasoning well-established standards: unit SOAP, XML, bundle: reusable software easy to implement WSDL and UDDI architecture universal client (just http, no matter reusability of components implementation)from language and platform independent (bundles/services) description language: WSDL architecture aggregation of context data no service registry or discovery dynamic service discovery: UDDI technological platform service-oriented approach HW platform independence (Java-based) no automatic context data aggregation scalability service discovery in framework no automatic context data aggregation interoperability number of users specific client for testingother non-Java not interoperable with purposes response times frameworks reusability no remote service discovery Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 16 / 13 16
- 17. [functionalities] messaging socket messaging end point of a communication link IP-based networks context context easy implementation modeling reasoning low network traffic no client or server language restrictions architecture no standardized message format raw data packets client/server messaging context data access process (on-demand, subscription, etc.) PUSH paradigm API technologies scalability interoperability speed Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 17 / 13 17
- 18. [functionalities] messaging socket XML/HTTP messaging end point of a communication link IP-based networksquery HTTP web server XML web server response context context easy implementation modeling reasoning low network traffic platform-independent no client choice of XML tags restrictions flexible or server language architecture security already implemented (HTTPs) no standardized message format XML advantages (flexibility, validation, ...) raw dataHTTP & XML management tools several packets client/server messaging context data access process (on-demand, subscription, etc.) HTTP not the fastest protocol PUSH paradigm API technologies XML itself lacks semantic scalability no intrinsic data type support interoperability speed Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 18 / 13 18
- 19. [functionalities] messaging socket XML/HTTP messaging end point of a communication link SOAP IP-based networksquery HTTP web server XML web server typed data exchange structured and response context context easy implementation modeling reasoning operates in decentralized and distributed low network traffic platform-independent environments no client choice of XML tags restrictions flexible or server language architecture security already implemented (HTTPs) platform & language independent no standardized message format XML advantages (flexibility, validation, ...) based on XML raw dataHTTP & XML management tools several packets client/server (HTTP, messaging transport protocol independent context data access process SMTP, etc.) (on-demand, subscription, etc.) HTTP not the fastest protocol PUSH paradigm API technologies XMLmention of semantic no itself lacks security mechanism scalability no intrinsic data type support objects no state reference to remote interoperability speed Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 19 / 13 19
- 20. [functionalities] context modeling key-value messaging low complexity easy to manage context context high applicability to existing modeling reasoning environments architecture lack of formality no algorithms to support efficient access to information context modeling no validation possible context data integration from multiple heterogeneous difficult to add meta information to sources context information (quality, etc.) structured information store & retrieved compute share reuse Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 20 / 13 20
- 21. [functionalities] context modeling key-value messaging mark-up schemes low complexity easy to manage can be partially validated context context high applicability to existing several management tools exist modeling reasoning environments to existing infrastructures applicability based on mark-up languages (as web architecture lack of formality services) no algorithms to support efficient access to information ambiguity to be incompleteness and context modeling no validation possible context data integration from handled on the application level multiple heterogeneous difficult to add meta information to not fully scalable (hierarchical structure sources context information (quality, etc.) but not inherence) structured information store & retrieved compute share reuse Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 21 / 13 21
- 22. [functionalities] context modeling key-value messaging mark-up schemes low complexity ontologies easy to manage can be partially validatedobjects, concepts and context context addsapplicability to existing high semantics when defining several management tools exist their properties and relations modeling reasoning environments to existing infrastructures applicability combine object-oriented and logic-based models advantages based on mark-up languages (as web architecture not of formality to model context data, but also lack only applicable services)sensors, etc. services, no algorithms to support efficient access to information formal descriptions incompleteness and ambiguity to be structured, explicit and context modeling high scalable possible no validation context data integration from handled on the application level multiple heterogeneous knowledge share meta information to difficult to add & reuse not fully scalable (hierarchical structure partial validation sources context information (quality, etc.) but not inherence) meta-information integration structured information able to infer new information (logic) store & retrieved compute share high design complexity reuse high reasoning complexity Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 22 / 13 22
- 23. [functionalities] reasoning rule-based reasoning messaging to reason about policies, restrictions, preferences, alarms, etc. context context modeling reasoning scalable (easy to add/change rules) simple and human-understandable architecture complements other types of reasoning no uncertainty support context reasoning difficult automatic rules acquisition context data relevant information pre-processing rules definition languages: SWRL, sensor data fusion RuleML, etc. inference monitoring (decision making) rule engines: Jess, Pellet, FaCT, etc. etc. Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 23 / 13 23
- 24. [functionalities] reasoning rule-based reasoning messaging bayesian networks to define policies, restrictions, preferences, alarms, etc. combine probability & graph theory context context different approaches: DBN, scalable (easy to add/changeHMM, etc. modeling reasoning rules) simple and human-understandable consistent mathematical complements other types tool (probability) architecture of reasoning able to handle uncertainty and incompleteness no uncertainty support context reasoning can be difficult automatically created from automatic rules acquisition context data relevant observation information pre-processing rules definition languages: SWRL, need to be sensor data fusion RuleML, etc. trained inference often not practical for large systems rule engines: Jess, Pellet, FaCT, etc. monitoring (decision making) etc. several tools: BNT(Matlab), MSBNx, etc. Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 24 / 13 24
- 25. architecture proposal main objective context acquisition – context-aware applications decoupling (standardized APIs) web browser / Java application context provider encapsulates sensor data acquisition processes HTTP XML messaging servlets sockets (raw data) XML/HTTP architecture servlets web browser or Java sockets [raw data] applications key-value model context modelling key-value context reasoning rule-based (applications) Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 25 / 13 25
- 26. architecture proposal main objective sensors services context acquisition – WiFi heartrate location services presence context-aware applications Bluetooth Zigbee registry activity recognition decoupling accelerometers etc. ambiental monitoring (ºC,light,...) (standardized APIs) context provider encapsulates sensor data acquisition processes messaging sockets (raw data) XML/HTTP architecture servlets web browser or Java applications context modelling key-value context reasoning rule-based (applications) Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 26 / 13 26
- 27. conclusions and future work conclusions 1. in spite of the various proposals presented to date, there is not an agreed methodology to cope with context information and to easily develop context-aware applications 2. the variety of sensors types, with different specifications and interfaces, claim for the development of new or existing sensor modelling standards future work 1. improve proposed platform architecture: service-oriented, based on OSGi context modelling: ontologies context reasoning: from application to context platform probabilistic reasoning (bayesian networks) 2. Quality of Context management 3. Design of a lightweight context management platform for mobile devices (mobile OSGi?) Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 27 / 13 27
- 28. any question? Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 28 / 13 28
- 29. context reasoning techniques Approach Advantages/Disadvantages Tools Rule-based + New rules can be added in a simple, incremental fashion, - Bossam: inference engine with native support for reasoning without rewriting the whole system reasoning over OWL ontologies and SWRL/RuleML + Knowledge is represented in an explicit and intelligible rules [19] way - Jess: small, light and fast rule engine for the Java + Easy to integrate with other reasoning methods (as platform where rules can be defined in XML [20] ontologies) - Other tools: Pellet, FaCT, RacerPro, etc. - Contextual information can’t be effectively managed - Automatic rules acquisition is difficult Bayesian + Are based on probability theory, a consistent mathematical - Bayes Net Toolbox: open source Matlab package Networks tool for directed graphical models that supports + Can readily handle incomplete data sets probability distributions, inference and structure + Able to build complex systems from simpler ones learning [26]. + The belief is automatically kept updating when new data - MSBNx (Microsoft Bayesian Network Editor): a item arrives component-based application for creating, assessing, + Learning about causal relationships and evaluating Bayesian Networks [25]. - Bayesian networks need to be trained - WEKA: a collection of machine learning - Highly dependent on prior knowledge reliability algorithms for data mining tasks [24]. - No universally accepted method for constructing a network - Other tools: BNJ, JavaBayes, BayesiaLab, BUGS, from data etc [27]. - Often not practical for large systems Fuzzy Logic + Mimic human decision-making to handle vague concepts - Matlab’s Fuzzy Logic Toolbox: extends the + Ability to deal with imprecise or imperfect information Matlab computing environment with tools for + Improved knowledge representation and uncertainty designing systems based on fuzzy logic [28]. reasoning - Other tools: FuzzyCOPE, fuzzyTECH, etc [29]. - Highly abstract and heuristic Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 29 / 13 29
- 30. messaging tecniques Technology Description Advantages Disadvantages XML/HTTP One of the simplest ways of - Platform-independent and standard – based - There exist fasters protocols than HTTP messaging: Internet HTTP protocol is technologies - XML itself lacks semantic used to query web servers, getting back - Flexible choice of XML tags and structure - No intrinsic data type support server information in XML format - HTTP itself offers security mechanisms - XML allows validation using DTD or XML-Schemas - Many tools for HTTP and XML management already developed for almost every platform Java Message Java Message Service is a JAVA - Asynchronous sending and receiving data -Slower communication Service messaging standard that allows -Supports point-to point and publish and subscribe -Increased network traffic due to sending header and other applications to create, send, receive, and mechanism information together with the message content read messages [12] - Provides different levels of message delivery reliability - Provides standard message formats - Loose coupling - Can be used by non-JMS clients Sockets A socket is an end point of a - Easy implementation -No standardized message format communication link between two - Low network traffic -Send only packets of raw data, that should further on be programs in an IP based network - Client and server can be written in different languages handled on the client and server-side Pushlet Pushlet is a servlet-based JAVA -Continuous sending of new HTML content - The client has to be a web browser mechanism that enables pushing content -Small protocol overhead; -Scalability: As the number of users increases, the number of from server-side JAVA objects to a client -Uses standard HTTP ports and protocols resources that are hold increases (threads, sockets etc) browser [11] -Light-weight client side (no need for browser plug-ins) -A web server is not designed for long-lived connections -DHTML is not compatible across browsers Remote Method Remote Method Invocation is a - Handles threads and sockets -Uses non standard ports that might be blocked by firewalls Invocation distributed Java technology that enables - Its communication falls back to sockets and if restricted -Requires a dedicated server executing computations remotely [13] by a firewall, falls back into HTTP communication -It can be only used by JAVA clients -Supports distributed architectures for context acquisition -Vulnerable security and reasoning, as it allows communicating different -Tightly coupled. Requires that the client has a pre- virtual machines knowledge of the methods to be called - It is supported in few browsers SOAP SOAP provides mechanisms for - Simple and extensible - SOAP contains no mention of security facilities (Simple Object Access exchanging structured and typed - Platform and language independent - SOAP clients do not hold any stateful reference to remote Protocol) information between peers in a - Based on XML objects decentralized, distributed environment -Transport protocol independent (HTTP, SMTP, etc.) [14] - SOAP allows you to get around firewalls Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 30 / 13 30
- 31. examples geo-referenced messaging Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 31 / 13 31
- 32. examples contextual agenda finder Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 32 / 13 32
Hinweis der Redaktion
- Hello, good morning. I’m Josué Iglesias, I work for the GPDS group in the UPM, there in Madrid, and I’m going to talk about the designing of context aware platforms.
- After going over (=reviewing) some of the most important context-aware frameworks, i want to focus this presentation FIRST on the main design principles, functionalities and technologies applying to context-aware platforms, and LATER on our own architecture proposal, FINISHING with some conclusions and future works.
- We have selected 4 of the most important and well-known context-aware platforms and here I just want to highlight, very quickly, some of their key contributions. Context Toolkit is one of the first proposals in this regard. It introduces the concept of widget , as a software component that encapsulates sensors specific details, offering a common way of accessing sensor data. It also develops some general concepts related with context-aware frameworks, as discoverers, aggregators, etc. CoBrA implements an inference engine based on rules (ContextToolkit didn’t implement any engine), modelling context data using ontologies . SOCAM maintain some of the characteristics of CoBrA, but applying a service-oriented architecture based. and finally Gaia and CMF contribute with uncertainty support using also probabilistic reasoning. ---------------------------------------------------------------------------------------------------------------------------------------------- Well/OK, now, after this review, we are going to try to draw some general principles that should be taken into account when designing this kind of platforms.
- First, it is necessary and architecture able to separate the sensing infrastructure from the processing mechanisms and the final applications. In this way we can get reusability of software blocks and an extendible system. Inside of each of the different layers defined, a formal description of services together with discovery mechanisms permit to use dynamic sources of context information and to maintain registries of available resources. This service-oriented approach, using common services interfaces, modelling languages and communication protocols, are nowadays motivating interoperability, that is, service integration, inside the enterprises architecture and also between enterprises over the Internet. Due to the heterogeneous kind of final applications, the delivery of context information from lower to upper layers should be enough flexible and several modes of context retrieval should be supported, permitting PUSH and PULL context retrieval. The quality of the context information obtained affects directly to the performance of final context-aware applications (and, of course, user experience), so it is necessary to calculate the correctness of the acquired and the inferred information in order to ensure the expected quality of service. In order to maintain the response times in terms of number of users or operation load, these context-aware platforms should be able to dynamically add new sensors, algorithms or client applications. Finally, they should be designed thinking in the final user. Users don’t adapt to the system, but the system to them, adjusting the user’s behaviour and preferences, and always taking into account their privacy.
- First, it is necessary and architecture able to separate the sensing infrastructure from the processing mechanisms and the final applications. In this way we can get reusability of software blocks and an extendible system. Inside of each of the different layers defined, a formal description of services together with discovery mechanisms permit to maintain registries of available resources and to use dynamic sources of context information. This service-oriented approach, using common services interfaces, modelling languages and communication protocols, are nowadays motivating interoperability, that is, service integration, inside the enterprises architecture and also between enterprises over the Internet. Due to the heterogeneous kind of final applications, the delivery of context information from lower to upper layers should be enough flexible and several modes of context retrieval should be supported, permitting PUSH and PULL context retrieval. The quality of the context information obtained affects directly to the performance of final context-aware applications (and, of course, user experience), so it is necessary to calculate the correctness of the acquired and the inferred information in order to ensure the expected quality of service. In order to maintain the response times in terms of number of users or operation load, these context-aware platforms should be able to dynamically add new sensors, algorithms or client applications. Finally, they should be designed thinking in the final user. Users don’t adapt to the system, but the system to them, adjusting the user’s behaviour and preferences, and always taking into account their privacy.
- First, it is necessary and architecture able to decouple the sensing infrastructure from the processing mechanisms and the final applications. In this way we can get reusability of software blocks and an extendible system. Inside of each of the different layers defined, a formal description of services together with discovery mechanisms permit to use dynamic sources of context information and to maintain registries of available resources. This service-oriented approach, using common services interfaces, modelling languages and communication protocols, are nowadays motivating interoperability, that is, service integration, inside the enterprises architecture and also between enterprises over the Internet. Due to the heterogeneous kind of final applications, the delivery of context information from lower to upper layers should be enough flexible and several modes of context retrieval should be supported, permitting PUSH and PULL context retrieval. The quality of the context information obtained affects directly to the performance of final context-aware applications (and, of course, user experience), so it is necessary to calculate the correctness of the acquired and the inferred information in order to ensure the expected quality of service. In order to maintain the response times in terms of number of users or operation load, these context-aware platforms should be able to dynamically add new sensors, algorithms or client applications. Finally, they should be designed thinking in the final user. Users don’t adapt to the system, but the system to them, adjusting the user’s behaviour and preferences, and always taking into account their privacy.
- First, it is necessary and architecture able to decouple the sensing infrastructure from the processing mechanisms and the final applications. In this way we can get reusability of software blocks and an extendible system. Inside of each of the different layers defined, a formal description of services together with discovery mechanisms permit to use dynamic sources of context information and to maintain registries of available resources. This service-oriented approach, using common services interfaces, modelling languages and communication protocols, are nowadays motivating interoperability, that is, service integration, inside the enterprises architecture and also between enterprises over the Internet. Due to the heterogeneity of final applications, the delivery of context information from lower to upper layers should be enough flexible and several modes of context retrieval should be supported, permitting PUSH and PULL context retrieval. The quality of the context information obtained affects directly to the performance of final context-aware applications (and, of course, user experience), so it is necessary to calculate the correctness of the acquired and the inferred information in order to ensure the expected quality of service. In order to maintain the response times in terms of number of users or operation load, these context-aware platforms should be able to dynamically add new sensors, algorithms or client applications. Finally, they should be designed thinking in the final user. Users don’t adapt to the system, but the system to them, adjusting the user’s behaviour and preferences, and always taking into account their privacy.
- First, it is necessary and architecture able to decouple the sensing infrastructure from the processing mechanisms and the final applications. In this way we can get reusability of software blocks and an extendible system. Inside of each of the different layers defined, a formal description of services together with discovery mechanisms permit to use dynamic sources of context information and to maintain registries of available resources. This service-oriented approach, using common services interfaces, modelling languages and communication protocols, are nowadays motivating interoperability, that is, service integration, inside the enterprises architecture and also between enterprises over the Internet. Due to the heterogeneous kind of final applications, the delivery of context information from lower to upper layers should be enough flexible and several modes of context retrieval should be supported, permitting PUSH and PULL context retrieval. The quality of the context information obtained affects directly to the performance of final context-aware applications (and, of course, user experience), so it is necessary to calculate the correctness of the acquired and the inferred information in order to ensure the expected quality of service. In order to maintain the response times in terms of number of users or operation load, these context-aware platforms should be able to dynamically add new sensors, algorithms or client applications. Finally, they should be designed thinking in the final user. Users don’t adapt to the system, but the system to them, adjusting the user’s behaviour and preferences, and always taking into account their privacy.
- First, it is necessary and architecture able to decouple the sensing infrastructure from the processing mechanisms and the final applications. In this way we can get reusability of software blocks and an extendible system. Inside of each of the different layers defined, a formal description of services together with discovery mechanisms permit to use dynamic sources of context information and to maintain registries of available resources. This service-oriented approach, using common services interfaces, modelling languages and communication protocols, are nowadays motivating interoperability, that is, service integration, inside the enterprises architecture and also between enterprises over the Internet. Due to the heterogeneous kind of final applications, the delivery of context information from lower to upper layers should be enough flexible and several modes of context retrieval should be supported, permitting PUSH and PULL context retrieval. The quality of the context information obtained affects directly to the performance of final context-aware applications (and, of course, user experience), so it is necessary to calculate the correctness of the acquired and the inferred information in order to ensure the expected quality of service. In order to maintain the response times in terms of number of users or operation load, these context-aware platforms should be able to dynamically add new sensors, algorithms or client applications. Finally, they should be designed thinking in the final user. Users don’t adapt to the system, but the system to them, adjusting the user’s behaviour and preferences, and always taking into account their privacy.
- First, it is necessary and architecture able to separate the sensing infrastructure from the processing mechanisms and the final applications. In this way we can get reusability of software blocks and an extendible system. Inside of each of the different layers defined, a formal description of services together with discovery mechanisms permit to use dynamic sources of context information and to maintain registries of available resources. This service-oriented approach, using common services interfaces, modelling languages and communication protocols, are nowadays motivating interoperability, that is, service integration, inside the enterprises architecture and also between enterprises over the Internet. Due to the heterogeneous kind of final applications, the delivery of context information from lower to upper layers should be enough flexible and several modes of context retrieval should be supported, permitting PUSH and PULL context retrieval. The quality of the context information obtained affects directly to the performance of final context-aware applications (and, of course, user experience), so it is necessary to calculate the correctness of the acquired and the inferred information in order to ensure the expected quality of service. In order to maintain the response times in terms of number of users or operation load, these context-aware platforms should be able to dynamically add new sensors, algorithms or client applications. Finally, they should be designed thinking in the final user. Users don’t adapt to the system, but the system to them, adjusting the user’s behaviour and preferences, and always taking into account their privacy. -------------------------------------------------------------------------------------------------------------------------------------- And NEXT, we are going to identify some alternatives to implement context-aware systems that follow these principles.
- Talking about architecture, there exist several technological platforms that implements a service-oriented approach: servlets are java classes, that process dynamically HTTP returning XML code. They are easy to implement and can be used from any client, just implementing HTTP. But, on the other hand, they do not implement services registry or discovery mechanisms so the input parameters are initially unknown
- Talking about architecture, there exist several technological platforms that implements a service-oriented approach: servlets are java classes, that process dynamically HTTP returning XML code. They are easy to implement and can be used from any client, just implementing HTTP. But, on the other hand, they do not implement services registry or discovery mechanisms so the input parameters are initially unknown web services allow machine-machine interaction over networks using well-established standards. They are independent from the programming language and platform. Services are formally described using WSDL and can be discovered using UDDI ( Universal Description, Discovery and Integration ).
- Talking about architecture, there exist several technological platforms that implements a service-oriented approach: servlets are java classes, that process dynamically HTTP returning XML code. They are easy to implement and can be used from any client, just implementing HTTP. But, on the other hand, they do not implement services registry or discovery mechanisms so the input parameters are initially unknown. web services allow machine-machine interaction over networks using well-established standards. They are independent from the programming language and platform. Services are formally described using WSDL and can be discovered using UDDI ( Universal Description, Discovery and Integration ). OSGi is a dynamic framework for Java that uses “bundles” as software unit. One or several bundles conform a service, and both, bundles and services, can be easily shared and reused. It is platform independent and it offers several service-management mechanisms. One of the main drawback of OSGi is that the service management mechanisms just work locally.
- As we said before, there’s a need of exchanging context data from lower to upper levels, so here we present several technologies that ca be used to handle messaging between components of context-aware systems. sockets are easy to implement, generate low network traffic and have no client or server language or platforms restrictions. On the other hand, they don’t specify an standard message format so clients and servers should process raw data packets.
- As we said before, there’s a need of exchanging context data from lower to upper levels, so here we present several technologies that ca be used to handle messaging between components of context-aware systems. sockets are easy to implement, generate low network traffic and have no client or server language or platforms restrictions. On the other hand, they don’t specify an standard message format so clients and servers should process raw data packets. XML/HTTP Another technique is to user HTTP and XML as query and response to a web server. It is also platform independent. XML has several advantages as flexibility or partial validation. Security can be partially supported using HTTPs. An there exist a lot of HTTP & XML management tools. As drawbacks we can say that: HTTP is not the fastest protocol XML lacks semantics.
- As we said before, there’s a need of exchanging context data from lower to upper levels, so here we present several technologies that ca be used to handle messaging between components of context-aware systems. sockets are easy to implement, generate low network traffic and have no client or server language or platforms restrictions. On the other hand, they don’t specify an standard message format so clients and servers need to process raw data packets. XML/HTTP Another technique is to user HTTP and XML as query and response to a web server. It is also platform independent. XML has several advantages as flexibility or partial validation. Security can be partially supported using HTTPs. An there exist a lot of HTTP & XML management tools. As drawbacks we can say that: HTTP is not the fastest protocol XML lacks semantics. SOAP Allow to exchange data in a structured way. It is also platform and language independent based on XML and also independent of the transport protocol (HTTP, SMTP, etc.) However, it doesn’t mention any security mechanism.
- A context modelling is also needed in order to integrate context data from multiple sources. The key-value model is the easiest way to model context information but, on the other hand, it doesn’t offer mechanisms to manage the information.
- A context modelling is also needed in order to integrate context data from multiple sources. The key-value model is the easiest way to model context information but, on the other hand, it doesn’t offer mechanisms to manage the information. Mark-up schemes models do offer several tools manage information, and are used in many architectures but still cannot deal with incompleteness or ambiguity, that has to be handle at application level. Also it is not totally scalable.
- A context modelling is also needed in order to integrate context data from multiple sources. The key-value model is the easiest way to model context information but, on the other hand, it doesn’t offer mechanisms to manage the information. Mark-up schemes models do offer several tools manage information, and are used in many architectures but still cannot deal with incompleteness or ambiguity, that has to be handle at application level. Also it is not totally scalable. Ontologies combine the advantages of object-oriented and logic-based models adding semantic when defining objects, concepts and their relations. This definitions are done in a structured, explicit and forma way being highly scalable allowing knowledge share and reuse partial validation of the model the inference of new information The main disadvantage of ontologies is their high complexity
- The context-reasoning functionality is in charge of inferring new relevant information from the acquired context data. One of the most used method is the rule-based reasoning mainly used to reason about policies, restriction, alarms, etc. here it is easy to add or change rules rules are in general simple and understandable this kind of reasoning is usually used to complement other kinds of reasoning However, it does not support uncertainty modelling and it’s quite difficult to learn rules automatically. There exist several rules definitions languages and rules engines.
- The context-reasoning functionality is in charge of inferring new relevant information from the acquired context data. One of the most used method is the rule-based reasoning mainly used to reason about policies, restriction, alarms, etc. here it is easy to add or change rules rules are in general simple and understandable this kind of reasoning is usually used to complement other kinds of reasoning However, it does not support uncertainty modelling and it’s quite difficult to learn rules automatically. There exist several rules definitions languages and rules engines. To finish with this section, bayesian networks , are able to handle uncertainty, ambiguity and incompleteness combining probability and graph theory these kind of models can be created automatically from observations so the need to be trained before being operational and are not practical for large systems. --------------------------------------------------------------------------------------------------------------------------- Well, then now we have translate these general principles, these functionalities and technologies into our own architecture proposal.
- The main objective of the proposal is to decouple the context acquisition part from the context-aware applications. This is done by this middle layer called “Context Provider”, that encapsulates sensor data acquisition processes. For messaging we have used sockets, between sensor level and context provider and HTTP/XML between context provider and final applications The architecture is built over servlets, using web browsers or java applications as clients. Context modelling is stored in a database following a key-value model. Context reasoning is based on rules, but no inference engine is used, rules are defined at application level.
- With this architecture, and using as sensors: WiFi and Bluetooth access points Zigbee motes accelerometers or heartrate monitors we are now able to develop -location or presence services -services of ambiental monitoring or -of activity recognition, for example
- That’s all. Any question?