Toward a Distributed Data Flow Platform for the Web of Things
(Distributed Node-RED)Michael Blackstock, Rodger Lea
Human Communication Technologies Lab Electrical and Computer Engineering Department
University of British Columbia
Motivation• Common IoT scenarios require real time interaction between
things, but application development can be difficult:
• integration, variety of protocols and APIs and programming environments.
• New web-based tools and platforms have emerged for rapid development e.g. WoTKit and Node-RED
• Current platforms host applications on a single device/server.
• Exploration of distributed data flow for the Web of Things
2
Data Flow Architectures• Initially to support massive parallelism, then
software engineering
• natural visual representation: nodes and arcs. • move more easily between design and
implementation • can reduce development time • some evidence that they are easier for non-
programmers
3
Server
Presence Sensor
TV Controller
Distributed Data Flow
4
Presence MonitorUser Sensor
Text Filter
TV Controller
Twitter Input Command Parser
Command Receiver
WoTKit Processor• Multi user service, bundled
with WoTKit platform* • Real time data processing,
alerting • Browser-based visual pipe
editor: modules are connected by wires to form pipes
• Pipe management page to manage execution.
• Separate script editor window for creating new modules.
5
* Blackstock, M.; Lea, R., "IoT mashups with the WoTKit," Internet of Things (IOT) Conference, 2012, 24-26 Oct. 2012, Wuxi, China
WoTKit Processor• Input modules
• Sensor, Twitter inputs • Functions
• Threshold, Scripting • Outputs
• Debugging/Monitoring • Email, Actuator control
• Script modules interact with flow using input, output and module state dictionaries.
6
Processor Architecture• ‘Pipes’ are stored as JSON in database
associated with users.
• On ‘start’, JSON pipe is parsed, module instances (beans) are created in memory, wires added to global Routing Table.
• Input modules add messages to execution queue.
• Scheduler looks up downstream module endpoint from endpoint ‘Routing Table’.
• Creates task using module (bean) and message for execution using thread pool.
• Pipes from multiple users can be added or removed from scheduler and routing table any time without restarting.
7
Node-RED
Nodes
Node RED Architecture• Single flow stored per instance in file
system
• On deploy, JSON flow is parsed, nodes instantiated and wired up directly.
• Each node has a connection to downstream nodes. Node.js EventEmitter API to manage listeners.
• By calling EventEmitter API, rather than downstream node directly, uses Node.js’ single threaded Event Loop.
• Worker threads are created for long running async operations (e.g. I/O).
• All ‘tabs’ are part of a single flow.
9
Based on http://www.aaronstannard.com/post/2011/12/14/Intro-to-NodeJS-for-NET-Developers.aspx
Nodes
Event Loop (single thread)
Non-blocking worker threads
5. return results
Nodes
2. emit events
4. return results
1. lookup next
node(s)
3. do work
AnalysisUser Interface!
• Both have an easy to use web based visual programming environment • Multi-user system separates pipe/flow management from editor. • Both use monitor nodes to view execution
Architecture!• Need a way to manage, stop and start pipes in a multi-user system. • Need system that is suitably ‘light weight’ for small devices. • nodes may have state; Node-RED supports global flow state. • Neither are distributed
Extensibility/Community/Sharing!• should be easy to extend. • Sharing pipes/flows and modules/nodes is critical to support
community of users
10
Distributed Data Flow Model• Multi-user system - flows and devices need ‘owners’ to be
managed separately, especially in shared cloud services.
• Should be able to associate sub flows with devices.
• ‘Server’ nodes must run on a server, ‘Device’ nodes on a specific device, ‘Mobile’ nodes on most appropriate device.
• Local wires for nodes on same device, remote wires between devices.
• Need easy way to distribute (sub)flows between devices.
• Ideally, should be able to visualize these extensions and execution.
11
Work To Date
12
Device boxes visualize device
association
Device Selector to specify device sub flows Import Flow from
Master Device
Extend all nodes with deviceId.
Extend flow parser to insert ‘remote wires’
between devices
Flow Deployment
13
MQTT BrokerServer
send to ‘remote wire’ topic
Presence Sensor send to ‘remote wire’ topic
TV Controller
listen on ‘remote wire’ Node topic
remote wire topic is generated using connected node ids
Conclusions• Processor, Node-RED and others demonstrate that
visual data flows are a useful programming model for developing IoT applications.
• Web based distributed data flow promising for coordinating multiple ‘things’.
• Raises many questions around programming model, implementation, security and heuristics.
• Looking for collaborators!
14
Thanks• Code: https://github.com/mblackstock/node-red
(default experimental branch)
• Node-RED: IBM and authors/contributors ! ! ! http://nodered.org/!
• WoTKit Processor: Sense Tecnic Systems ! ! ! http://sensetecnic.com
15