In this position paper, we discuss our experiences with a lightweight Web of Things (WoT) toolkit and use those experiences to explore what an effective WoT toolkit looks like. We argue that while the WoT community has experimented, like us, with a variety of toolkits, it hasn’t yet found one that appeals sufficiently to a broad range of developers. This failure, we believe, is hindering the adoption of the WoT and the growth of the community. We conclude the paper with a set of open questions, which, although not exhaustive, are aimed at opening up a community discussion on the needs of developers and how best the community can meet those needs and so further the adoption of the WoT. In essence, we believe that the time may be right to begin to agree on some basic functionality and approaches to WoT toolkits.

1. The WoTKit
A Lightweight Tookit for the Web of Things
Mike Blackstock, Rodger Lea
Media and Graphics Interdisciplinary Centre
University of British Columbia
Vancouver, Canada

2. Position Overview
• Lack of effective toolkits is a significant barrier to
adoption of the web of things
• Balance between functionality and simplicity
• Context
• WoTKit and application experience
• Raised questions related to approach and
features
• Goal: guidelines for WoT toolkit developers
toward basic requirements and approaches

3. Many Other Toolkits
• High end M2M systems
• Custom solutions
• Not focused on web, sharing
• Similar web-centric toolkits
• Key differences
• what is included
• how services are delivered

4. Experience
• Remote monitor of pulse oximeter
• Transport and air quality mobile
apps
• Social sustainability applications
• Phidget, Arduino integration
• Zigbee gateways
• CPU monitors
• Power monitoring
• Social network integration

5. Toolkit Requirements

6. Toolkit Requirements
• Integration

7. Toolkit Requirements
• Integration
• Sharing

8. Toolkit Requirements
• Integration
• Sharing
• Visualizations 100
75
50
25
0
12:05 12:10 12:15 12:20

9. Toolkit Requirements
• Integration
• Sharing
• Visualizations 100
75
• Processing 50
25
0
12:05 12:10 12:15 12:20

10. Toolkit Requirements
• Integration
• Sharing
• Visualizations 100
75
• Processing 50
25
• RESTful APIs 0
12:05 12:10 12:15 12:20

11. Integration
• Basic function of all toolkits
• Easy thing-integration using web servers
and clients
• Toolkit acts as aggregator for thing (meta)
data
• Relay for for actuator control
• Gateways, often simple scripts, update
toolkit with state, connect actuators

12. Sharing
• Sharing things, data
and components
• Saves integration task
for others
• Allows easy creation
of mashups
• Most existing systems

13. Visualizations
• Often first task after integration:
see your data
• Sen.se dashboards
• Google Charts, Maps
• ThingSpeak iFrames
• Pachube graphs

14. Processing
• Pachube triggers
• Sen.se applications
• Paraimpu
connections and
filters
• Pipes and modules

15. RESTful APIs
• Allows developers to
process and visualize
data in new ways
• incorporate into
complex applications
• integrate “non-thing”
data sources

16. WoTKit
• Data model: sensors (actuators) with meta data:
• owner
• id, names
• location
• description
• field schema
• Sensor data
• named fields (some defaults)
• server timestamp
• client timestamp

17. Architecture
• Management and
visualization
• Processing engine
• RESTful API
• Shared data model
• Database and message
broker
• Google Charts, jQuery
UI, Flot, Spring
Framework, ActiveMQ,
MySQL

18. Processing Engine
• Pipes consist of linked stateful
modules
• Routing table of connected
modules from pipe descriptions.
• Dispatcher thread gets next
task from queue
• Multithreaded executor
performs tasks
• Tasks may add new tasks to the
queue

19. Open Questions
• Given other emerging systems, and WoTKit
experience
• What are the key requirements for WoT
Toolkits?
• How should these requirements be met?

20. Thing Model
• Naming things
• human readable names (dns)?
• hierarchical or flat namespace?
• tagging, searching
• Thing representations and schema
• What meta data is shared by things?
• What types of data can they emit and receive?
• what control messages can be sent?

21. Integration Points
• Sensor data input and output API
• Actuator control API: URL callbacks, long polling, WebSockets
• Visualizations & widgets
• dashboards & widgets?
• apps?
• simple line charts?
• Data processing integration
• apps?
• pipe modules?
• connectors?

22. Processing and Interaction
• Push or Pull?
• Push: firewall friendly, but events no one is interested in
• Pull: infrastructure polling for unnecessary updates
• Current state and stream of historical values?
• Processing Model
• Event based: alerting and filtering, but no historical data
access
• Query based: historical data, but need to check for change
regularly
• What are the appropriate programming approaches and
APIs? Simple alerts, filters, apps, pipes?

23. Sharing and Interoperability
• Sharing
• Share via social networks, or do things
have other relationships?
• Toolkit Integration and Standards
• Should we be working for toolkit
interoperability?
• What is the fundamental programming
model and services for all WoT toolkits?

24. Conclusions
• Exposing things to the web allows
developers to more quickly build IoT
applications.
• Experience with WoTKit has allowed us to
explore toolkit requirements.
• What does it mean to “include batteries”
for a WoT toolkit for rapid mashup
development?