Programming Pervasive and Mobile Computing Applications: The TOTA Approach

Programming Pervasive and MobileComputing Applications: The TOTA Approach Presented By: Hector M Lugo-Cordero, MS EEL 6883

Full Citation • Authors: Marco Mamei and Franco Zambonelli • From: Università di Modena e Reggio Emilia • Title: Programming pervasive and mobile computing applications: The TOTA approach • Published at: ACM Transactions on Software Engineering and Methodology (TOSEM), vol. 18, issue 4, July 2009

Agenda • Introduction • Essentials • Programming • Evaluation • Conclusions • References

The Problem • Information processing is incorporated into everyday objects • Agents can come and leave at any time • Information is context (environment) dependent • Need for a simple programming framework

TOTA • A tupple oriented middleware • Tuples are injected into the network • No central common space

Case Study Scenario • Imagine a huge museum like Le Louvre on France • Many tourists come per day • Makes hard for the management of services and information • Assume every user has a wireless-enabled computer • Museum layout can change over time and people come and go as they want

Current Approaches • Direct communication • Communicate with other agents is direct (i.e. hardcoded) • Not very dynamic • Shared data-space • Hard coordination • Event base • Notifications needed • These are general (no context awareness)

The TOTA Approach • Gathers elements from both tuple-based and event-base models • Distributed tuples injected to the network are cloned and propagated across the network • A peer-to-peer network, each node running TOTA is the space with limited neighbors • Tuples structure: • T = (C, P, M) • C = content, P = propagation, M = maintenance

TOTA Example (Information)

TOTA in Le Louvre • Assumption that there is a large wireless network, with a backbone • How to provide information and planning to avoid queues • ArtPiece • C = (description, location, distance) • P = Propagate to all peers increasing distance • M = update if topology changes

Solutions (Information) • Solution 1 • Art pieces propagate tuples • Tourists query for the one with lower distance value • Solution 2 • Art pieces do not propagate tuples • Users query for information • Art pieces reply

TOTA Example (Meeting)

Solution (Meeting) • Meeting • C = (tourist_name, distance) • P = propagate to all peers, increase distance by one • M = update the distance tuple upon tourist move • Tourist are guided with a GUI to the same place • using the highest distance • recursive process • No coordination is specified by TOTA

TOTA Architecture

TOTA Implementation • Java based • Using 802.11b broadcast • Avoid unicast handshake • Deployed emulator to increase network size • Only 16 PDAs and some laptops were used • The same code of the emulator could be used on devices • Emulator ran in mixed modes (real and emulated devices)

TOTA Requirements • What are the primitives that interact with the middleware? • How to specify tuples T = (C, P, M)? • How to code coordinated and context-aware activities?

TotaTuple public class MyTuple extends TotaTuple, implements ReactiveComponent{ //ReactiveComponent exposes the react() method } TotaTuple myTuple = new MyTuple(new Object[]{“Hello”});

Tota API

TOTA Predefined Tuples

Programming ArtAgent1

Programming TouristAgent1

Programming ArtAgent2

Programming TouristAgent2

Programming MeetingAgent

Software Engineering Analysis • Context information makes TOTA general but more difficult for agents to react • Separation of tuples (context) and agents (logic) however simplify this • Incorporation of command and template design patterns facilitate tuple programming

Tuple Propagation/Deletion Evaluation • Highly scalable since only propagate to its immediate neighbors • Tu = Trcv + Tprop + Tsend + Ttravel • Propagation Time on a WiFi PDA (IPAQ 400 MHz) • Tprop 99.7 ms • Tsend 67.2 ms • Ttravel 0 ms • Trcv 21.2 ms • Tu 188.1 ms

Tuple Propagation/Deletion Evaluation (cont.) • For X hops TXU = X*TU • In practice is a little more (10–20% from mean) • Only HotTuples/MetricTuples and SpaceTuples were affected by topology

Load and Memory Evaluation • Load is accounted to local agent execution and propagation/maintenance rules • Storage is small enough for micro-sensors, but requires each one to store it • Java implementation leaves TOTA opened for improvements in an optimized C version

Conclusions • TOTA support pervasive and mobile applications • By using distributed tuples so agents can • Extract contextual information • Coordinate each other • Dynamically adjusts as topology changes • TOTA weaknesses • Strict structure (hard mapping) • Security and privacy issues • Complex operations aren’t very supported

My Thoughts • Strengths: • TOTA seems like a powerful, portable API • Weaknesses: • Authors claimed that it is context independent but only the museum scenario was used • Unclear mapping on how to transform real problems to TOTA tuples • Suggestions: • Adding flow of traffic by layer to see how to interpret the pool of tuples over the network • Demonstrate the application on different domains, and give a clearer mapping • Implementation in C for devices that do not posses a JVM • Include wired backbone

References • http://www.wikipedia.org • http://www.agentgroup.unimo.it/wiki/index.php/TOTA • http://www.agentgroup.unimo.it/wiki/images/2/21/Tutorial.pdf • http://www.agentgroup.unimo.it/wiki/images/8/8b/Tota.zip

Questions

Programming Pervasive and Mobile Computing Applications: The TOTA Approach