Grupo de Procesado de Datos y Simulación                                         ETSI de Telecomunicación                 ...
presentation content                   context-aware platforms review                   general design principles       ...
context-aware platforms - review                   Context Toolkit                                                 CoBrA •...
context-aware platforms - review                   Context Toolkit                                                 CoBrA •...
context-aware platforms - review                   Context Toolkit                                                 CoBrA •...
context-aware platforms - review                   Context Toolkit                                                 CoBrA •...
general design principles         layered approach                     decoupling:                                        ...
general design principles         layered approach                   formal (semantic) service description               ...
general design principles         layered approach     service management                       common                    ...
general design principles         layered approach     service management            interoperability                     ...
general design principles         layered approach     service management            interoperability          context ret...
general design principles         layered approach     service management            interoperability                     ...
general design principles         layered approach     service management            interoperability          context ret...
[functionalities] architecture                                        servlets           messaging                        ...
[functionalities] architecture                                        servlets           messaging                     web...
[functionalities] architecture                                        servlets           messaging                     web...
[functionalities] messaging                                        socket           messaging                    end poin...
[functionalities] messaging                                        socket                                          XML/HTT...
[functionalities] messaging                                        socket                                          XML/HTT...
[functionalities] context modeling                                        key-value            messaging                  ...
[functionalities] context modeling                                        key-value            messaging                  ...
[functionalities] context modeling                                        key-value            messaging                  ...
[functionalities] reasoning                                        rule-based reasoning            messaging              ...
[functionalities] reasoning                                        rule-based reasoning            messaging              ...
architecture proposalmain objective context acquisition –  context-aware applications  decoupling  (standardized APIs)   ...
architecture proposalmain objective                                     sensors                                services c...
conclusions and future work                                                                             conclusions 1. in ...
any question?Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es Prototyping of contex...
context reasoning techniques      Approach                      Advantages/Disadvantages                                  ...
messaging tecniques     Technology                         Description                                           Advantage...
examples                                 geo-referenced messagingDesigning a framework to handle context information – MAD...
examples                             contextual                                agenda                                     ...
Upcoming SlideShare
Loading in...5
×

[MADRINET'09] Designing a framework to handle context information

356

Published on

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
356
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 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?
  • [MADRINET'09] Designing a framework to handle context information

    1. 1. Grupo de Procesado de Datos y Simulación ETSI de Telecomunicación Universidad Politécnica de MadridDesigning 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. 2. presentation content  context-aware platforms review  general design principles  functionalities & technologies  architecture proposal  conclusions  future workDesigning 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. 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 engineDesigning 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. 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 engineDesigning 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. 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 engineDesigning 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. 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 engineDesigning 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. 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-centeredDesigning 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. 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 retrievalquality of context (QoC) scalability user-centeredDesigning 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. 9. general design principles layered approach service management common  service interfaces interoperability  modelling languages  communication protocols context retrieval motivate service integration  inside enterprises architecturequality of context (QoC)  on the Internet scalability user-centeredDesigning 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. 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 retrievalDesigning 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. 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-centeredDesigning 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. 12. general design principles layered approach service management interoperability to maintain response times in terms of  number of users context retrieval  operation loadquality 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. 13. general design principles layered approach service management interoperability context retrievalquality of context (QoC) scalability  user does not adapt to the system  system transparently adjust to the user behaviour and preferences user-centered  privacy constraintsDesigning 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. 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  reusabilityDesigning 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. 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  reusabilityDesigning 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. 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 discoveryDesigning 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. 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  speedDesigning 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. 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  speedDesigning 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. 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  speedDesigning 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. 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  reuseDesigning 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. 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  reuseDesigning 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. 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 complexityDesigning 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. 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. 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. 25. architecture proposalmain objective context acquisition – context-aware applications decoupling (standardized APIs) web browser / Java application context provider encapsulates sensor data acquisition processes HTTP XMLmessaging servlets sockets (raw data) XML/HTTParchitecture servlets web browser or Java sockets [raw data] applications key-value modelcontext modelling key-valuecontext 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. 26. architecture proposalmain 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 processesmessaging sockets (raw data) XML/HTTParchitecture servlets web browser or Java applicationscontext modelling key-valuecontext 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. 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. 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. 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 forreasoning 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 packageNetworks 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. 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 communicationService 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 firewallsInvocation 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 remoteProtocol) 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. 31. examples geo-referenced messagingDesigning 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. 32. examples contextual agenda finderDesigning 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

    ×