Programming Pervasive and Mobile Computing Applications: The TOTA Approach
-
Upload
fidelina-catalin -
Category
Documents
-
view
30 -
download
0
description
Transcript of 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
1
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
2
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
5
TOTA
• A tupple oriented middleware• Tuples are injected into the network
– No central common space
6
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
7
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)8
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
10
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
12
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
13
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
15
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)
18
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?
19
TotaTuple
20
public class MyTuple extends TotaTuple, implements ReactiveComponent{//ReactiveComponent exposes the react() method
}
TotaTuple myTuple = new MyTuple(new Object[]{“Hello”});
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
29
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
30
Tuple Propagation/Deletion Evaluation (cont.)
31
• 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
32
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
34
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
35
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
37