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

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

20

public class MyTuple extends TotaTuple, implements ReactiveComponent{//ReactiveComponent exposes the react() method

}

TotaTuple myTuple = new MyTuple(new Object[]{“Hello”});

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.)

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

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.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

Questions

38