A Comparison of Context-Aware Application Development Infrastructures and Context Representation

1. A Comparison of Context-Aware Application Development Infrastructures and Context Representation Dev Oliver, Nikhil Yadav CISE Department, University of Florida, Gainesville, Florida, USA

2. Outline • Introduction • Problems and proposed solutions in Pervasive Computing Infrastructures • Middleware Goals • Middleware Architectures • GAIA Meta-operating System • Service-oriented Context Aware Middleware (SOCAM) • Context-Aware Middleware Utilizing Asynchronous Communication • Middleware based on Application Packages and the Kernel Runner • Comparisons • Conclusions

3. Introduction • Problems and proposed solutions in Pervasive Computing Infrastructures • Middleware Goals • Middleware Architectures • GAIA Meta-operating System • Service-oriented Context Aware Middleware (SOCAM) • Context-Aware Middleware Utilizing Asynchronous Communication • Middleware based on Application Packages and the Kernel Runner • Comparisons • Conclusions

4. Introduction • Numerous middleware infrastructures and prototype systems for developing context-aware applications • Need for Middleware and Standards for decoupling programming and application development from physical space construction and integration • TCP/IP, client-server models, distributed OS for networked computers. Similar concepts needed for Pervasive computing environments

5. Introduction • Problems and proposed solutions in Pervasive Computing Infrastructures • Middleware Goals • Middleware Architectures • GAIA Meta-operating System • Service-oriented Context Aware Middleware (SOCAM) • Context-Aware Middleware Utilizing Asynchronous Communication • Middleware based on Application Packages and the Kernel Runner • Comparisons • Conclusions

6. Problems and Proposed solutions • Problem: Non-scalable integration Low level information on sensors and actuators required. Time consuming to integrate and test for conflicts. Solution: Self Integration Allow automatic integration within the space; preferable to view elements as software services and space as runtime environment • Problem: Closed world Assumption New technologies from 3rd Party vendors cannot be added that easily as technology evolves over time. Solution: Standard Adoption Adoption of standards like OSGi and UPnP by maximum number of vendors, so addition of third party elements becomes easy

7. Problem: Obsolete Concepts Concepts become obsolete over time…e.g. context awareness and service gateways Solution: Semantic Exploitation and Intelligent Middleware design Allow added services to advertise their presence and register services. Service definition + integration are added in. Middleware for appliances e.g. smart plugs. Combining these, functionality can develop over time.

8. Introduction • Problems and proposed solutions in Pervasive Computing Infrastructures • Middleware Goals • Middleware Architectures • GAIA Meta-operating System • Service-oriented Context Aware Middleware (SOCAM) • Context-Aware Middleware Utilizing Asynchronous Communication • Middleware based on Application Packages and the Kernel Runner • Comparisons • Conclusions

9. Middleware Goals • Presenting sensors and actuators as software services in a runtime environment (Smart space) • Faster prototyping using service views and dynamic libraries • Browsing and learning support…to help in full Semantic Exploitation (aggregating context for instance) (Middleware Infrastructures follow next)

10. Introduction • Problems and proposed solutions in Pervasive Computing Infrastructures • Middleware Goals • Middleware Architectures • GAIA Meta-operating System • Service-oriented Context Aware Middleware (SOCAM) • Context-Aware Middleware Utilizing Asynchronous Communication • Middleware based on Application Packages and the Kernel Runner • Comparisons • Conclusions

11. The GAIA Meta-operating System • Features Include: • Distributed OS/ components • Decoupled communication model • Context Registry and Query services • Component presence detection • Browsing facilities • Virtual Directory Hierarchy for files • Application Partitioning among Devices

12. The GAIA Architecture

13. Distributed OS/ Components • GAIA is based ondistributed components (sensors and actuators) and applications • CMC responsible for managing these i.e. loading, unloading, transferring and creating all GAIA components

14. Decoupled Communication Model • Event Manager provides this. Based on suppliers, consumers and channels • Forwarding of supplier’s events to consumers registered with the channel • Fault tolerant: Supplier replaced with replica in case of failure

15. Context Registry and Querying services • Applications allowed to register and query a particular context service • Allows application adaption • Context registry can be looked up by applications to find out what service they require

16. Component Presence Detection • Presence Service responsible for this. • Maintains updated information about active space components i.e. devices, applications and services • Digital Entity Presence subsystem: applications and services send heartbeats…no heartbeat received => Entity has left the active space • Physical Entity presence subsystem acts as a proxy implementing a beaconing mechanism. Open Infrastructure, can employ different device drivers and algorithms

17. Browsing Facilities • The space repository stores all HW and SW entity information e.g. by name, type, owner • Applications allowed to browse and retrieve an entity based on specific attributes • Applications can learn about entities entering and leaving the active space thru the presence service channels

18. Virtual Directory Hierarchy for Files • Context File system responsible for this. • Users given access to context whenever they need it • Makes personal data available to applications; organizes data to facilitate locating relevant material for applications and users; retrieve data based on user preferences or device characteristics • CFS Aware of different types of context defined and allows mounting of different contexts into one main application space • Virtual Directory Hierarchy: e.g. /location:/RM2401/situation:/meeting Architecture composed of mount and File servers

19. Application Partitioning among devices • Application framework responsible for this • Allows users to adapt how to input/output data to and from the application. • lets users construct, run or adapt existing applications to active spaces.

20. Introduction • Problems and proposed solutions in Pervasive Computing Infrastructures • Middleware Goals • Middleware Architectures • GAIA Meta-operating System • Service-oriented Context Aware Middleware (SOCAM) • Context-Aware Middleware Utilizing Asynchronous Communication • Middleware based on Application Packages and the Kernel Runner • Comparisons • Conclusions

21. Service Oriented Context-Aware Middleware (SOCAM) • Features Include: • OSGi based; uses JVM => platform independence • Context Registry and Query services • Service Location (component detection) • Ontology based Context reasoning • Support for multiple home networking technologies • Hosting of Multiple services from different providers on a single gateway platform • Various levels of system security, digital signing of downloaded services and object access control.

22. SOCAM Architecture

23. OSGi based • SOCAM is proposed on top of service oriented OSGi open standard. • OSGi defines a lightweight framework for delivering and executing service-oriented applications. Management functionalities include: installing, activating, deactivating, updating and removing services. • Can provide a robust and potentially interoperable infrastructure for building, provisioning and managing context-aware services in smart homes and beyond.

24. Context Registry and Query services • SLS, allows advertisement of services by CP and CI for easy location • Context Providers registers with SLS to be discovered by others. They can be either external or internal based on where context is obtained from • Context Interpreters are composed of a context reasoner and a context knowledge base. • Reasoner uses preloaded inference rules etc. to make decisions. • Context Knowledge base uses Tbox, Abox, predefined instances loaded during system initiation and sensed context instances loaded during runtime. Event triggering mechanism used to update particular context instances.

25. Context-aware services: Applications using different levels of context information, adapting their behavior according to the current context. • Queries SLS to find context it requires. A common way of developing context-aware applications is to specify actions in response to context changes. Application developers can specify rules and specify method to invoke when the condition becomes true.

26. Service Location (component detection) • SLS...wide area discovery of context providers is allowed for. Tracks and adapts to changes induced when adding/removing sensors or reconfiguring contexts. • Multi. matching mechanism allowing advertisement of context in various forms. (locatedIn John ?x) is a query example. • The service will first load the context ontologies stored in the database and the context instances advertised by different context providers, and then apply semantic matching to find out which context provider provides this information. If a match is found, it sends the application the reference to the CP.

27. Ontology based Context reasoning • Supports ontology and rule based reasoning. The OWL reasoning system supports constructs for describing properties and classes, including relationships between classes. RDF schema rules required to perform RDF schema reasoning- for example. User defined rule-based reasoning. Forward + backward chaining + hybrid execution mode to perform reasoning is used.

28. Support for multiple home networking technologies • OSGi compliant residential gateway, enabling and managing communications to and from various local networks. • Java embedded server connects both wide-area and local networks.

29. Hosting of Multiple services from different providers on a single gateway platform • Various types of networked devices, electronic appliances and sensors can be attached to the residential gateway via different home networking technologies. Hosts’ context aware services are downloaded from various context-aware service providers.

30. Various levels of system security, digital signing of downloaded services and object access control. • The gateway operator manages and maintains residential gateways and their services. • Its functionalities include monitoring the gateway to detect malfunctions and security attacks and installing services to and from gateway. Service aggregator and protection against conflicts. • Developers design a context aware application as a set of services and combine them into bundles that can be downloaded to the gateway

31. SW stack embedded in the OSGi compliant residential gateway. • Contains Service-hosting environ + common APIs to develop application bundles. SOCAM Middleware built on top of this. • Each SOCAM component can be constructed as an independent bundle i.e. SLS bundle. OSGi adopts Java 2 security model

32. Introduction • Problems and proposed solutions in Pervasive Computing Infrastructures • Middleware Goals • Middleware Architectures • GAIA Meta-operating System • Service-oriented Context Aware Middleware (SOCAM) • Context-Aware Middleware Utilizing Asynchronous Communication • Middleware based on Application Packages and the Kernel Runner • Comparisons • Conclusions

33. Context-Aware Middleware Utilizing Asynchronous Communication • Features include: • OSGI based • Uses asynchronous communication • Proactive and reactive context introspection • Tracking and selection of resources • Introspection of the local system • Introspection of the network neighborhood

34. Asynchronous Communication • Messages stored temporarily on certain hosts while being routed • Forwarded later when circumstances permit • Any message sent in the network should be maintained as long as possible in a local cache by as many devices as possible • So it can remain available for those devices that could not receive it at the time it was originally sent • Implemented in Java as an OSGI service

35. Asynchronous Communication • Messages are sent over the network either as serialized Java objects or as formatted XML • Message dissemination is performed by broadcasting UDP data grams

36. Proactive and reactive context introspection • Achieved by abstracting resources in network via object oriented model • Three abstractions made: • Resources • Resource descriptors • Resource observation reports

37. Proactive and reactive context introspection • Resource object implements functionalities to use and control the resource it defines • Resource descriptor provides static information about the resource • Resource observation report gives information about the current state of the resource

38. Object-oriented modeling of resources

39. Tracking and selection of resources • Resources can appear and disappear frequently in the environment • necessary to have a means by which to keep track of currently available resources • Accomplished through resource objects and a resource register • All resources are designed to register a description of themselves with the register at creation time • Possible for an adaptive service deployed on a mobile device to obtain information about its local execution context by polling the register periodically

40. Tracking and selection of resources • Occasionally necessary to focus only on specific resources in the system at certain times • E.g. when a given service is awaiting the appearance of another service on the network • Requires the middleware to select resources based on pre-defined criteria • Achieved by resource pattern • Implements a function isMatchedBy() that takes a resource descriptor object as a parameter and returns a boolean indicating whether this object satisfies the predefined criteria or not

41. Introspection of the local system • Services should have information about the local devices on which they are running • Achieved by obtaining a description of the local resources from the resource register and by monitoring the local resources • Resources are monitored both synchronously and asynchronously

42. Introspection of the local system • Synchronous monitoring refers to the implementation of a callback mechanism in resource objects • Each resource can admit several listeners • When a variation occurs the resource can detect it based on the registered listeners • Unfortunately, all resources cannot be monitored using this synchronous approach • E.g. access to the CPU is not achieved by calling methods directly

43. Introspection of the local system • Asynchronous approach deals with CPU resources such as system memory and network interfaces • Achieved by checking the state of a given resource explicitly every now and then in such a way that the time of the observation does not coincide with the time of an attempt in resource utilization

44. Introspection of the network neighborhood • Discover what resources are available in the physical environment • More complicated mechanism by which to automatically discover available resources • E.g. discovering close wireless networks, configuring the wireless communication interface of mobile devices automatically and identifying what hosts can be reached on these networks

45. Introspection of the network neighborhood • In current implementation of this middleware, this service relies on the system commands of the Linux operating system (wireless tools) • Asynchronous communication is used to discover neighboring hosts and remote services • Discovery of resources can be made: • Proactively by sending requests in the network • Reactively by analyzing unsolicited advertisements sent by other devices in the network

46. Introspection of the network neighborhood • Discovery of remote services: • Proactively • Middleware sends XML document containing service request described by a resource pattern • Service providers who have matching services whose descriptor fits the pattern that the request specifies respond with an XML document containing a description of the services they can offer • Reactively • Service providers send unsolicited advertisements or service descriptors.

47. Introduction • Problems and proposed solutions in Pervasive Computing Infrastructures • Middleware Goals • Middleware Architectures • GAIA Meta-operating System • Service-oriented Context Aware Middleware (SOCAM) • Context-Aware Middleware Utilizing Asynchronous Communication • Middleware based on Application Packages and the Kernel Runner • Comparisons • Conclusions

48. A Middleware based on Application Packages and the Kernel Runner • Features include: • Kernel Runner • Application Packages • Several useful components for providing common functionalities

49. Kernel Runner • Handles the mobility and adaptation of applications in the system • Enables loading, execution, updating and stopping of applications or components • Platform-dependant • Components executed in the kernel runner are also platform-dependant

50. Kernel Runner Architecture