Scale changes everything. 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. Martyn Taylor is a senior software engineer at Red Hat, with over 7 years’ experience working on cloud, middleware and messaging software. Martyn currently works on the Apache ActiveMQ suite of projects.

1. Messaging for IoT
JBUG November 2015
Martyn Taylor, Dejan Bosanac

2. Presenters
Martyn Taylor

Senior Software Engineer at Red Hat

Apache ActiveMQ Committer

Mainly working on Apache Artemis

Keen interest in IoT
Bosanac Dejan

Senior Software Engineer at Red Hat

Apache ActiveMQ committer and PMC member

Co-author of ActiveMQ in Action

3. Agenda

IoT messaging basics

Tasks and challenges

Patterns and protocols

IoT messaging brokers

Apache ActiveMQ

ActiveMQ Artemis

IoT messaging scaling

Vertical and horizontal

Qpid Dispatch Router

Scalable deployments

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

5. IoT Topology
Big Data
Messaging
Infrastructure
Analytics
Enterprise
Middleware
Devices

6. IoT Messaging Infrastructure
Task

Provides connectivity between devices and back end systems
Challenges

Interoperability

Deployment environment

High Availability

Scalability

7. IoT connectivity patterns

IoT Communication Patterns

Telemetry, Command & Control, Enquiry, Notifications

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. Notification
• Service → Device
• One Way (push)
• 1 → Many
• Grouping

12. Requirements on the transport

Communication 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

Battery powered

Work offline

15. IoT Environment Challenges

Interoperable

Connection 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

Connection failures

Durable Messages and Various ACK Modes

17. JMS

Inter-operability

Java Runtime 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

Connection 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. Subscriptions

Topics

Hierarchical addresses

e.g. building/core/floor/2/office/1

Supports wild cards

building/core/floor/#

building/core/floor/+/office/+

QoS per topic

Outlives a connection

24. AMQP 1.0

International Standard (ISO/IEC ISO 19464)

Binary Protocol

Rich feature set:

Conversation multiplexing

Advanced flow control

Type system

QoS Guarantees

Symmetrical message exchange

No Broker required

25. QoS Guarantees

At most once

Fire and Forget

At least once

Retry

Exactly once

3 Way Ack

26. Type System

Highly Interoperable

Rich Type Set

Primitives

integer, long

lists, maps

Descriptive types

Allow application defined types

Mappings in most languages

27. Symmetrical Protocol

Not Client -> Broker

Broker less message

Client -> Client

Client -> Router

Interesting features

Smart routing

28. Flow control & multi 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 ActiveMQ

ActiveMQ Artemis

31. Apache ActiveMQ

Apache ActiveMQ is a high-performance, scalable
messaging broker

Started as an open source JMS broker

Moved to Apache Software Foundation in 2006

Now widely used open source messaging system

32. Apache ActiveMQ

Multi-Protocol/Multi-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

Battle-tested in many production environments

Good security support

Flexible

Configurable

Embeddable

34. Apache ActiveMQ

Limitations

Broker core getting old

Written using synchronous thread-locking model

Limits vertical scalability of the broker

Number of threads raise with number of connections
and destinations

35. ActiveMQ Artemis

Multi 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 ActiveMQ

Sub project ActiveMQ Artemis.

Latest Release 1.1.0

36. ActiveMQ Artemis: Core

Contains Broker Business logic

Core maintains a tight scope

Message Routing

Persistence

Protocol utility API

HA and Scaling

Highly Performance

Protocols are plugged in

37. ActiveMQ Artemis: Architecture
Artemis
Core

38. Apache Artemis Summary

Great performance due to

Reactive Architecture

Efficient Append only Journal

Multi - Protocol Broker

AMQP, MQTT, STOMP, CORE, OpenWire, JMS

HA and Scalability built in

39. Apache Artemis Next Steps

Take features from ActiveMQ

Enhance OpenWire for ActiveMQ compatibility

JDBC Journal implementation

More protocols

CoAP

Your protocol here….

40. IoT Messaging Scaling

Broker scaling

Vertical

Horizontal

Qpid Dispatch Router

Scalable Deployment

41. Broker – Vertical Scaling

Give broker enough resources

Reduce thread usage

NIO transport

Reactive architecture

Improve monitoring under stress

Advisory messages

Selective Mbean registration

42. Broker – Horizontal Scaling

One broker can only do so much

Horizontal scaling

Networks of brokers

Load balance connections

Limitations

All destinations on all brokers

Broker network is the bottleneck

43. Qpid Dispatch Router

Lightweight AMQP 1.0 message router written in C

http://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, settlement and
disposition frames between endpoints

Message based or link based routing
Router/device1
/device2

45. Qpid Dispatch Router

Deployed in multiple router-broker-endpoint topology

Redundant paths
Router
Broker
Router

46. Qpid Dispatch Router

Cost-based route computation
Router
Broker
Router

47. Qpid Dispatch Router

Automatic re-routing on failure
Router
Broker
Router

48. Qpid dispatch router
Benefits

Better scaling due to more focused tasks

Smart routing can be used to partition the traffic

Ideal candidate for gateway into the system

49. Scalable deployments

Smarter scaling techniques using routers

Connections concentration

Destinations concentration

Destination sharding

Smart routing

50. Scalable deployments

Combination 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

51. Connection Concentration
Router
Broker
• Challenge: Reduce the number of connections on the broker

52. Destination Concentration
Router
Broker
/building1/room1
/building1
/building1/room2
/building1/room2
• Challenge: Reduce the number of destinations on the broker

53. Destination Sharding
Router
Broker
Queue.A
Broker
Queue.B

Challenge: Distribute destinations 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 communication

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

ActiveMQ 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
• http://http://www.slideshare.net/dejanb/messaging-for-iot
• MQTT
• Spec: http://www.mqtt.org
• Libraries and tutorials: http://www.eclipse.org/paho/
• AMQP
• Spec: http://www.amqp.org/
• Libraries and tutorials: http://qpid.apache.org/
• ActiveMQ and Artemis
• http://activemq.apache.org/
• Dispatch Router
• http://qpid.apache.org/components/dispatch-router/