Scale changes everything. Number of connections and destinations went from dozen to thousands, number of messages increased by order of magnitude. What once was quite adequate for enterprise messaging can't scale to support "Internet of Things". We need new protocols, patterns and architectures to support this new world. This session will start with basic introduction to the concept of Internet of things. Next it will discuss general technical challenges involved with the concept and explain why it is becoming mainstream now. Now we're ready to start talking about solutions. We will introduce some messaging patterns (like telemetry and command/control) and protocols (such as MQTT and AMQP) used in these scenarios. Finally we will see how Apache ActiveMQ is gearing up for this race. We will show tips for horizontal and vertical scaling of the broker, related projects that can help with deployments and what the future development road map looks like.

1. Messaging for IoT
October 2015
Martyn
Taylor,
Dejan
Bosanac

2. Presenters
Martyn
Taylor
• Senior
So4ware
Engineer
at
Red
Hat
• Apache
Ac>veMQ
CommiCer
• Mainly
working
on
Apache
Artemis
• Keen
interest
in
IoT
Bosanac
Dejan
• Senior
So4ware
Engineer
at
Red
Hat
• Apache
Ac>veMQ
commiCer
and
PMC
member
• Co-­‐author
of
Ac>veMQ
in
Ac>on

3. Agenda
• IoT
messaging
basics
• Tasks
and
challenges
• PaCerns
and
protocols
• IoT
messaging
brokers
• Apache
Ac>veMQ
• Ac>veMQ
Artemis
• IoT
messaging
scaling
• Ver>cal
and
horizontal
• Qpid
Dispatch
Router
• Scalable
deployments

4. IoT Messaging Basics
• IoT
Topology
• Messaging
tasks
• Messaging
challenges

5. IoT Topology
Big
Data
Messaging
Infrastructure
Analy>cs
Enterprise
Middleware
Devices

6. IoT Messaging Infrastructure
Task
• Provides
connec>vity
between
devices
and
backend
systems
Challenges
• Interoperability
• Deployment
environment
• High
Availability
• Scalability

7. IoT connectivity patterns
• IoT
Communica>on
PaCerns
• Telemetry,
Command
&
Control,
Enquiry,
No>fica>ons
• Protocols
and
Technologies
• JMS
• MQTT
• AMQP

8. Telemetry
• Device
→
Service
• One
way
(push)
• Failures
tolerable
• Lots
of
small
data

9. Command
and
Control
• Service
→
Device
• Two
way
(Req/Resp)
• Less,
more
important
data
• 1
→
1
and
1
→
many
• grouping

10. Enquiry
• Device
→
Service
• 1
→
1
• Two
way
(Req/Resp)

11. No>fica>on
• Service
→
Device
• One
Way
(push)
• 1
→
Many
• Grouping

12. Requirements
on
the
transport
• Communica>on
from/to
devices
• 1
→
1
• Device
Addressing
• 1
→
Many
• Group
Addressing
• Push
• Request
→
Response

13. IoT
Networks
• Unreliable
• Handle
network
failures
• Expensive
and
Constrained
• Low
network
overhead

14. IoT
Devices
• Limited
Resources
• Low
processing
overhead
• Large
scale
and
varied
• Inter-­‐operable
• BaCery
powered
• Work
offline

15. IoT
Environment
Challenges
• Interoperable
• Connec>on
Failure
Handling
• Offline
• Low
network
overhead
• Low
Processing
overhead

16. JMS
• Addresses
majority
of
requirements
• 1-­‐1,
1-­‐Many,Grouping,Device
address
• Queues,
Topics,
Message
Selectors
• Push
• Req/Resp
• Reply
to
queues
• Inter-­‐operable
• JVM
• Connec>on
failures
• Durable
Messages
and
Various
ACK
Modes

17. JMS
• Inter-­‐operability
• Java
Run>me
only
• Protocol
vs
API
• Vendor
specific
• Rich
feature
set
• Complexity
on
the
client
• Large
footprint
• Vendor
protocols
• High
network
overhead

18. MQTT
• OASIS
standard
(v3.1.1)
• Created
by
IBM
• Light
weight
• Low
network
message
• Simple
protocol
• Pub
/
Sub
• Quality
of
Service
• Connec>on
failures
• Very
popular
in
IoT
scenarios

19. QoS
Levels

20. Overheads
• Sending
/
Receiving
messages
• QoS
0
=
8
bytes
• QoS
1
=
min
12
bytes
• QoS
2
=
min
20
bytes
• Clients
have
small
code
foot
print
• Simple
protocol
• Burden
on
the
broker

21. Failures

22. Reconnects

23. Subscrip>ons
• Topics
• Hierarchical
addresses
• e.g.
building/core/floor/2/office/1
• Supports
wild
cards
• building/core/floor/#
• building/core/floor/+/toilet/+
• QoS
per
topic
• Outlives
a
connec>on

24. AMQP
1.0
• Interna>onal
Standard
(ISO/IEC
ISO
19464)
• Binary
Protocol
• Rich
feature
set:
• conversa>on
mul>plexing
• advanced
flow
control
• Type
system
• QoS
Guarantees
• Symmetrical
message
exchange
• No
Broker
required

25. QoS
Guarantees
Quality
of
Service
guarantees
• At
most
once
• Fire
and
Forget
• At
least
once
• Retry
• Exactly
once
• 3
Way
Ack

26. Type
System
• Highly
Interoperable
• Rich
Type
Set
• Primi>ves
• integer,
long
• lists,
maps
• Descrip>ve
types
• Allow
applica>on
defined
types
• Mappings
in
most
languages

27. Symmetrical
Protocol
• Client
-­‐>
Broker
• Broker
less
message
• Client
-­‐>
Client
• Client
-­‐>
Router
• Interes>ng
features
• Smart
rou>ng

28. Flow
control
and
Mul>
Channels
• Limit
producer
and
consumer
flow
• Each
channel
(link)
can
be
controlled
individually
• Limit
telemetry
flow
for
command
messages

29. Protocols
Overview
• Lots
of
IoT
protocol
choices
including
several
not
discussed
here
• The
right
choice
depends
of
the
scenario
• Scenarios
may
combine
protocols
CoAP
Target
usecase Long-­‐haul
(&
local)
Long-­‐haul Local
(&
long-­‐
haul)
Long-­‐haul
Compactness High Medium Highest Verbose
Security SSL SSL DTLS SSL
Flow
control No Yes No No
Structured
message
No Yes No Yes
Complexity Medium High Low Lowest

30. IoT Messaging Brokers
• Apache
Ac>veMQ
• Ac>veMQ
Artemis

31. Apache ActiveMQ
• Apache
Ac>veMQ
is
a
high-­‐performance,
scalable
messaging
broker
• Started
as
an
open
source
JMS
broker
• Moved
to
Apache
So4ware
Founda>on
in
2006
• Now
widely
used
open
source
messaging
system

32. Apache ActiveMQ
• Mul>-­‐Protocol/Mul>-­‐Language
Support
• Invented
Stomp
protocol
in
2006
• Now
supports
AMQP
1.0,
MQTT
3.1.1,
HTTP,
STOMP
protocols
• Broad
range
of
supported
client
libraries
for
all
kinds
of
device
hardware

33. Apache ActiveMQ
• Benefits
• Feature
rich
• BaCle-­‐tested
in
many
produc>on
environments
• Good
security
support
• Flexible
• Configurable
• Embeddable

34. Apache ActiveMQ
• Limita>ons
• Broker
core
gepng
old
• WriCen
using
synchronous
thread-­‐locking
model
• It
limits
ver>cal
scalability
of
the
broker
• Number
of
threads
raise
with
number
of
connec>ons
and
des>na>ons

35. Ac>veMQ
Artemis
• Mul>
Protocol
Broker
• AMQP,
MQTT,
STOMP,
OpenWire,
Artemis
Core
• JMS
(API)
• Started
as
HornetQ
JBoss
project
in
2009
• Embedded
WildFly
(JBoss
AS)
JMS
messaging
service
• In
2014
donated
to
Apache
Ac>veMQ
• Sub
project
Ac>veMQ
Artemis.
• Latest
Release
1.1.0

36. Ac>veMQ
Artemis:
Core
• Contains
Broker
Business
logic
• Core
maintains
a
>ght
scope
• Message
Rou>ng
• Persistence
• Protocol
u>lity
API
• HA
and
Scaling
• Highly
Performance
• Protocols
are
plugged
in

37. Ac>veMQ
Artemis:
Architecture
Artemis
Core

38. Apache
Artemis
Summary
• Great
performance
due
to
• Reac>ve
Architecture
• Efficient
Append
only
Journal
• Mul>
-­‐
Protocol
Broker
• AMQP,
MQTT,
STOMP,
CORE,
OpenWire
• JMS
• HA
and
Scalability
built
in

39. Apache
Artemis
Next
Steps
• Take
features
from
Ac>veMQ
• Enhance
OpenWire
support
for
Ac>veMQ
compa>bility
• JDBC
Journal
implementa>on
• More
protocols
• CoAP
• Your
protocol
here….

40. IoT Messaging Scaling
• Ver>cal
and
Horizontal
scaling
of
Brokers
• Qpid
Dispatch
Router
• Scalable
Deployment

41. Broker – Vertical Scaling
• Give
broker
enough
resources
• Reduce
thread
usage
• NIO
transport
• Reac>ve
architecture
• Improve
monitoring
under
stress
• Advisory
messages
• Selec>ve
Mbean
registra>on

42. Broker – Horizontal Scaling
• One
broker
can
only
do
so
much
• Horizontal
scaling
by
using
networks
of
brokers
• Load
balance
connec>ons
• Limita>ons
• All
des>na>ons
on
all
brokers
• Broker
network
is
the
boCleneck

43. Qpid Dispatch Router
• Lightweight
AMQP
1.0
message
router
wriCen
in
C
• hCp://qpid.apache.org/components/dispatch-­‐router/
• Provides
flexible
and
scalable
interconnect
between
AMQP
endpoints

44. Qpid Dispatch Router
• It
is
not
a
broker
• It
never
owns
a
message
• It
propagates
AMQP
transfer,
seClement
and
disposi>on
frames
between
endpoints
• Message
based
or
link
based
rou>ng
Router/device1
/device2

45. Qpid Dispatch Router
• It
can
be
deployed
in
mul>ple
router-­‐broker-­‐endpoint
topology
• Redundant
paths
Router
Broker
Router

46. Qpid Dispatch Router
• Cost-­‐based
route
computa>on
Router
Broker
Router

47. Qpid Dispatch Router
• Automa>c
re-­‐rou>ng
on
failure
Router
Broker
Router

48. Qpid dispatch router
• Benefits
• BeCer
scaling
due
to
more
focused
tasks
• Smart
rou>ng
can
be
used
to
par>>on
the
traffic
• Ideal
candidate
for
gateway
into
the
system

49. Scalable deployments
• Combina>on
of
brokers
and
routers
provides
powerful
tool
box
• Brokers
should
focus
on
storing
messages
• Routers
should
do
the
rest
• Allows
for
horizontal
scaling
topologies
that
can
solve
IoT
challenges

50. Scalable deployments
• Smarter
scaling
techniques
using
routers
• Connec>ons
concentra>on
• Des>na>ons
concentra>on
• Des>na>on
sharding
• Smart
rou>ng

51. Connection Concentration
Router
Broker
• Challenge:
Reduce
the
number
of
connec>ons
on
the
broker

52. Destination Concentration
Router
Broker
/building1/room1
/building1
/building1/room2
/building1/room2
• Challenge:
Reduce
the
number
of
des>na>ons
on
the
broker

53. Destination Sharding
Router
Broker
Queue.A
Broker
Queue.B
• Challenge:
Distribute
des>na>ons
across
brokers

54. Deployments – Smart Routing
Router
Broker
QoS
0
• Challenge:
Decrease
the
load
of
messages
on
the
broker

55. Deployments – Smart Routing
Router
Broker
QoS
1

56. Summary
• IoT
offers
a
new
set
of
problems
for
communica>on
• Messaging
is
a
good
fit
• We
need
new
tools
and
technologies
to
help
• Protocols
such
as
AMQP
and
MQTT
help
address
some
of
these
problems
• Ac>veMQ
and
Artemis
are
evolving
to
meet
IoT
demands
• New
tools
such
as
Apache
Dispatch
Router
allow
us
to
do
some
novel
things
to
help
scale
to
really
high
numbers

57. Resources
• Slides
• hCp://hCp://www.slideshare.net/dejanb/messaging-­‐for-­‐iot
• MQTT
• Spec:
hCp://www.mqC.org
• Libraries
and
tutorials:
hCp://www.eclipse.org/paho/
• AMQP
• Spec:
hCp://www.amqp.org/
• Libraries
and
tutorials:
hCp://qpid.apache.org/
• Ac>veMQ
and
Artemis
• hCp://ac>vemq.apache.org/
• Dispatch
Router
• hCp://qpid.apache.org/components/dispatch-­‐router/