Programming Pervasive and Mobile
Computing 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
Agenda
•
•
•
•
•
•
Introduction
Essentials
Programming
Evaluation
Conclusions
References
3
Agenda
•
•
•
•
•
•
Introduction
Essentials
Programming
Evaluation
Conclusions
References
4
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
Agenda
•
•
•
•
•
•
Introduction
Essentials
Programming
Evaluation
Conclusions
References
9
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 Example (Information)
11
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
TOTA Example (Meeting)
14
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 Architecture
16
Agenda
•
•
•
•
•
•
Introduction
Essentials
Programming
Evaluation
Conclusions
References
17
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
public class MyTuple extends TotaTuple, implements ReactiveComponent{
//ReactiveComponent exposes the react() method
}
TotaTuple myTuple = new MyTuple(new Object[]{“Hello”});
20
Tota API
21
TOTA Predefined Tuples
22
Programming ArtAgent1
23
Programming TouristAgent1
24
Programming ArtAgent2
25
Programming TouristAgent2
26
Programming MeetingAgent
27
Agenda
•
•
•
•
•
•
Introduction
Essentials
Programming
Evaluation
Conclusions
References
28
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.)
• 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
31
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
Agenda
•
•
•
•
•
•
Introduction
Essentials
Programming
Evaluation
Conclusions
References
33
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
Agenda
•
•
•
•
•
•
Introduction
Essentials
Programming
Evaluation
Conclusions
References
36
References
• http://www.wikipedia.org
• http://www.agentgroup.unimo.it/wiki/index.ph
p/TOTA
• http://www.agentgroup.unimo.it/wiki/images/
2/21/Tutorial.pdf
• http://www.agentgroup.unimo.it/wiki/images/
8/8b/Tota.zip
37
Questions
38