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
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
IoT Messaging Infrastructure
Task • Provides connec>vity between devices and backend systems Challenges • Interoperability • Deployment environment • High Availability • Scalability
IoT connectivity patterns
• IoT Communica>on PaCerns
• Telemetry, Command & Control, Enquiry, No>fica>ons • Protocols and Technologies
• JMS • MQTT • AMQP
Command and Control
• Service → Device • Two way (Req/Resp) • Less, more important data • 1 → 1 and 1 → many
• grouping
Requirements on the transport
• Communica>on from/to devices • 1 → 1
• Device Addressing • 1 → Many
• Group Addressing • Push • Request → Response
IoT Networks
• Unreliable • Handle network failures
• Expensive and Constrained • Low network overhead
IoT Devices
• Limited Resources • Low processing overhead
• Large scale and varied • Inter-‐operable
• BaCery powered • Work offline
IoT Environment Challenges
• Interoperable • Connec>on Failure Handling • Offline • Low network overhead • Low Processing overhead
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
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
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
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
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
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
QoS Guarantees
Quality of Service guarantees • At most once
• Fire and Forget • At least once
• Retry • Exactly once
• 3 Way Ack
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
Symmetrical Protocol
• Client -‐> Broker • Broker less message
• Client -‐> Client • Client -‐> Router
• Interes>ng features • Smart rou>ng
Flow control and Mul> Channels
• Limit producer and consumer flow • Each channel (link) can be controlled individually • Limit telemetry flow for command messages
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
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
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
Apache ActiveMQ
• Benefits
• Feature rich • BaCle-‐tested in many produc>on environments • Good security support • Flexible • Configurable • Embeddable
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
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
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
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
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….
IoT Messaging Scaling
• Ver>cal and Horizontal scaling of Brokers • Qpid Dispatch Router • Scalable Deployment
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
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
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
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
Qpid Dispatch Router
• It can be deployed in mul>ple router-‐broker-‐endpoint topology • Redundant paths
Router
Broker
Router
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
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
Scalable deployments
• Smarter scaling techniques using routers
• Connec>ons concentra>on • Des>na>ons concentra>on • Des>na>on sharding • Smart rou>ng
Destination Concentration
Router
Broker
/building1/room1
/building1
/building1/room2
/building1/room2
• Challenge: Reduce the number of des>na>ons on the broker
Destination Sharding
Router
Broker
Queue.A
Broker
Queue.B
• Challenge: Distribute des>na>ons across brokers
Deployments – Smart Routing
Router
Broker
QoS 0
• Challenge: Decrease the load of messages on the broker
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
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/