WSO2 Message Broker <Presenter Name> <Designa*on>
WSO2 Message Broker
<Presenter Name> <Designa*on>
WSO2 Message Broker
Unique distributable, fault tolerant and scalable enterprise message broker to connect, persist and reliably distribute data, event informa9on generated from mul9ple systems,
applica9ons and IoT devices.
Advantages
• Integrate easily with exis9ng IT Infrastructure .
• Select storage based on messaging demands .
• Provides op9on between strict and best effort message delivery.
• Low maintenance through minimum deployment effort.
• Highly interoperable with AMQP clients.
• Effortlessly handle large message transfer.
• Seamless feature integra9on with WSO2 ESB.
3
Supported Protocols & SpecificaAons
• Implements and supports JMS API using AMQP
• JMS (Java Message Service) • A Standard Java API for programmers to handle messaging by interac9ng
with a message broker
• AMQP (Advanced Message Queuing Protocol) • Open Standard for passing business messages between applica9ons or
organiza9ons
• MQTT (Message Queuing Telemetry Transport)
4
AMQP-‐Interoperability • Implements and supports JMS API using AMQP. • Interoperability with many languages / plaSorms via AMQP clients for • Java, • Net, • C, C++, PHP, Ruby and more.
• Advanced Message Queuing Protocol, the only industry standard protocol for interoperable reliable messaging.
• Support for JMS v1.0 and v1.1 API .
5
MQTT Support ● Lightweight pub/sub protocol implemented on top of TCP/IP to facilitate machine-‐to-‐machine (M2M) and Internet-‐of-‐Things (IoT) integra9ons
● Hierarchical topic structures and wildcard subscrip9ons
● All quality of service levels and retained messages ● At most once(0)
● At least once(1) ● Exactly one(2)
● Distributed MQTT topics (Publish to any node and receive from another)
6
Architecture
7
Design Approach • Avoid message rou9ng over the network . • Use scalable storage to share messages between nodes • High availability & fault tolerance. • Interoperability with AMQP clients. • Use distributed coordina9on to control the behavior (i.e Hazelcast). • Extend messaging to IoT.
8
Design • Cluster elects a leader(Known as Coordinator) • Coordinator keeps track of all the slots available (via Hazelcast) • Nodes with subscrip9ons acquire a slot (from Coordinator) and deliver them to subscribers
9
Performance • Based on a disruptor based model • Inbound Disruptor • All incoming events are ordered by inser9ng into a ring buffer. • Mul9ple handlers operate on ring buffer in parallel. • Stores/Deletes data through persistence layer ( extensible to more data
store types).
• Slot Delivery Worker Pool: • Reads messages from Database from MB nodes based on the
subscribers. • Keeps track of messages (re-‐) delivered, subscribers • Passes messages to outbound Disruptor
• Outbound Disruptor: • Reads messages from database in parallel • Handover messages to transport for delivery
10
Features
11
Queue, Topics • Point to Point (Queues)
• A message is delivered only once to a single consumer
• Publish/Subscribe (Topics) • Broadcast a message to all the subscribers
12
Distributed Queues • Provides strict or best effort support for in-‐order delivery. • There are no guarantee about the global order seen across subscribers.
13
Durable SubscripAon • Same topic as subscrip9on. • Subscriber offline • Message gets queued
• Subscriber back online • Messages geang delivered
• Unsubscribed needed to remove queuing
14
Shared Durable SubscripAon • Purpose of load balancing. • As an extension of jms 1.1
15
Dead LeVer Channel • Specifically designed to persist messages that are faulty or rejected by the message receivers
• MB server repeat for a maximum number of configured 9mes. Ader that it will route message to DLC.
• User can perform following ac9ons on DLC messages • Delete (discard mal-‐formaeed message) • Restore message to the original queue
• Re-‐route the message to any other exis9ng queue in MB cluster
16
Flow Control(Back Pressure) • Safeguards server from sudden bursts of message loads. • Ensures that the rate at which messages are transmieed from the
publisher to the receiver is controlled. • Back-‐pressure is exerted when the defined global memory threshold or
message count threshold per connec9on is exceeded. • Message acceptance is blocked un9l the sender is no9fied of memory
recovery. • If the memory is not recovered within a specified 9me interval all
currently publishing clients will be disconnected. • Flow control mechanisms. • Throeling based on global memory threshold
• Throeling based on message count per connec9on
17
VisualizaAon
• View ac9ve queue subscrip9ons in whole MB cluster.
• View ac9ve topic subscrip9ons in whole MB cluster.
• View inac9ve durable topic subscrip9ons specifically. • Ability to unsubscribe inac9ve durable topic subscrip9ons with UI.
• Ability to deal with messages at Dead Leeer Channel.
18
Other Features • Real-‐9me sta9s9cs • Database read/write latencies • Inbound/Outbound event rates. • Number of connec9ons/channels etc.
• Queue/Topic Permission Model • Admin can explicitly set the each permissions.
• Dynamic Queue Crea9on • Publisher client ini9ates the queue is created in the broker, even if there
are no consumers
19
Use Cases
Message Guarantee with WSO2 ESB • Guarantee message order. • Eliminates message duplica9on. • Ensure reliable messaging.
21
Rate Limits
• Some services only process messages at a specific rate
• Clients may send messages at an arbitrary rate
• Provides a virtualized service interface that stores all messages in a queue
• Services can consume messages from the queue at their own pace
• Or the broker can forward the stored messages to the actual service at a controlled rate
22
Messaging for Audit/Logging • Some9mes messages should be processed through expensive audit/logging rou9nes • To avoid high response 9mes, messages can be cloned and stored in a queue
• Audit/logging systems consume the messages off the queues
23
IoT Demo ● Acts as MQTT Broker to connect and distribute temperature and humidity sensor data published from an embedded agent in a Raspberry PI.
24
Source:hep://wso2.com/library/ar9cles/2014/09/demonstra9on-‐on-‐architecture-‐of-‐internet-‐of-‐things-‐an-‐analysis/
Extended Use Case
25
Thank You