Title: Programming Pervasive and Mobile Computing Applications: The TOTA Approach
1Programming Pervasive and MobileComputing
Applications The TOTA Approach
- Presented By Hector M Lugo-Cordero, MS
- EEL 6883
2Full 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
3Agenda
- Introduction
- Essentials
- Programming
- Evaluation
- Conclusions
- References
4Agenda
- Introduction
- Essentials
- Programming
- Evaluation
- Conclusions
- References
5The 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
6TOTA
- A tupple oriented middleware
- Tuples are injected into the network
- No central common space
7Case 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
8Current 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)
9Agenda
- Introduction
- Essentials
- Programming
- Evaluation
- Conclusions
- References
10The 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
11TOTA Example (Information)
12TOTA 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
13Solutions (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
14TOTA Example (Meeting)
15Solution (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
16TOTA Architecture
17Agenda
- Introduction
- Essentials
- Programming
- Evaluation
- Conclusions
- References
18TOTA 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)
19TOTA 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?
20TotaTuple
public class MyTuple extends TotaTuple,
implements ReactiveComponent //ReactiveComponent
exposes the react() method TotaTuple myTuple
new MyTuple(new ObjectHello)
21Tota API
22TOTA Predefined Tuples
23Programming ArtAgent1
24Programming TouristAgent1
25Programming ArtAgent2
26Programming TouristAgent2
27Programming MeetingAgent
28Agenda
- Introduction
- Essentials
- Programming
- Evaluation
- Conclusions
- References
29Software 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
30Tuple 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
31Tuple Propagation/Deletion Evaluation (cont.)
- For X hops TXU XTU
- In practice is a little more (1020 from mean)
- Only HotTuples/MetricTuples and SpaceTuples were
affected by topology
32Load 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
33Agenda
- Introduction
- Essentials
- Programming
- Evaluation
- Conclusions
- References
34Conclusions
- 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 arent very supported
35My 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
36Agenda
- Introduction
- Essentials
- Programming
- Evaluation
- Conclusions
- References
37References
- http//www.wikipedia.org
- http//www.agentgroup.unimo.it/wiki/index.php/TOTA
- http//www.agentgroup.unimo.it/wiki/images/2/21/Tu
torial.pdf - http//www.agentgroup.unimo.it/wiki/images/8/8b/To
ta.zip
38Questions