The WSO2 Message Broker is a scalable and fault-tolerant enterprise message broker designed to seamlessly integrate with existing IT infrastructure, supporting multiple protocols including JMS, AMQP, and MQTT. Key features include various message delivery options, durable subscriptions, flow control, and visualization tools for monitoring active subscriptions. It caters to applications in IoT and supports efficient message handling across diverse platforms while ensuring message guarantees and audit logging capabilities.

1.
WSO2
Message
Broker
<Presenter
Name>
<Designa*on>

2. 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.

3. 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

4. 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

5. 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

6. 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

7. Architecture
7

8. 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

9. 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

10. 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

11. Features
11

12. 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

13. Distributed
Queues
• Provides
strict
or
best
effort
support
for
in-­‐order
delivery.
• There
are
no
guarantee
about
the
global
order
seen
across
subscribers.
13

14. Durable
SubscripAon
• Same
topic
as
subscrip9on.
• Subscriber
offline
• Message
gets
queued
• Subscriber
back
online
• Messages
geang
delivered
• Unsubscribed
needed
to
remove
queuing
14

15. Shared
Durable
SubscripAon
• Purpose
of
load
balancing.
• As
an
extension
of
jms
1.1
15

16. 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

17. 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

18. 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

19. 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

20. Use
Cases

21. Message
Guarantee
with
WSO2
ESB
• Guarantee
message
order.
• Eliminates
message
duplica9on.
• Ensure
reliable
messaging.
21

22. 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

23. 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

24. 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/

25. Extended
Use
Case
25

26. Thank
You