Messaging has been used widely by enterprise architects to reliably integrate and scale systems. Commonly used messaging patterns include distributed queues/topics and dead letter channels with varied quality of service levels. When adopting a message broker, architects not only need to look at features but also at the deployment and maintenance complexity, internal architecture and surrounding concepts. This session will discuss the internal architecture of WSO2 Message Broker (WSO2 MB) and focus on Improved performance with optimized message dissemination model Ease of use and reliability with a message persistence layer backed by RDBMS Simplified deployment layout and less operational complexity with Hazelcast based clustering scheme New features and the future road map

1. Rethinking Message Brokering with
WSO2 Message Broker
Ramith Jayasinghe
Senior Technical Lead
WSO2

2. Overview
• Messaging Concepts
• MB Features, Roadmap
• Q/A

3. What is Messaging ?
• We oEen design distributed systems with RPC style
communicaIon
(E.g. Web Services, ThriE, REST)
• RPC communicaIon is,
Request/Response (there is always a response)
Synchronous (client waits for response)
Non-persistent (message is lost if something failed)
• But there are other 7 possibiliIes. Under messaging we
support those.

4. Messaging Concepts - Queues
• Verify the Order
• Ship to Address
• Update Stocks
• Acknowledge Message

5. Messaging Concepts- Publish/Subscribe

6. Messaging Concepts – Durable SubscripIons
Same as topic subscripIons
Subscriber offline - Messages get queued
Subscriber back online - Messages get delivered
Un-subscrip7on needed to remove queuing
Online Store
Topic Name: Orders
Order Processor 3 Order Processor 2 Order Processor 1Warehouse
Durable Subscription
Subscription 1
(nondurable)
Subscription 2
(nondurable)
Data Archives
Analytics System

7. Messaging Concepts – Delivery & Acknowledgements
At most once: Messages could be lost. Higher Performance
At least once: Receiver acknowledge messages.
Exactly once: Very hard to implement. Consider making messages
idempotent ( or systems can handle message duplicaIons)
Online Store
Topic Name: Orders
Order Processor 3 Order Processor 2 Order Processor 1Warehouse
At least once
At most once
At least once
Data Archives
Analytics System
Transactional

8. Messaging Concepts – Dead LeYer Channel
Receiver rejects message ( e.g. invalid order, out of stock, broken hardware)
Dead LeIer Channel – broker keep problemaIc messages in this Queue.
Poison Message – Message has exceeded the maximum number
of delivery aYempts.
Warehouse Order Processor 3 Order Processor 2 Order Processor 1
Analytics System
Data Archives
Invalid Order è
Order Rejected è
Send to DLC after
maximum delivery
attempts è
Dead Letter Channel (DLC)
è

9. Messaging Concepts – Hierarchical Topics
• Map relaIonships between data
being published onto different
topics.
• Can subscribe to part of the
hierarchy.

10. Messaging Concepts – Distributed Queues
• Provides strict or best
effort support for in order
delivery
• There are no guarantee
about the global order seen
across subscribers

11. Messaging Concepts – Distributed Queues
Order Processor 3 Order Processor 2 Order Processor 1
Online Store
Warehouse
Broker 1
Broker 2Broker 3
M1 M2 M3
M1
M2
M3
A1 A2 A3
A1
A2
A3
Distributed
Queue
• Provides strict or best
effort support for in order
delivery
• There are no guarantee
about the global order seen
across subscribers

12. Messaging Concepts – Shared SubscripIons
Extension to JMS 1.1, unIl JMS 2.0 support is
released.
Purpose: Ability to load balance with in consumer
clusters.

13. Messaging Concepts – Shared SubscripIons
Shared Subscrip7on !
• ‘Order processors’ in each warehouse share a single subscripIon.
• Any message will be delivered to a single order processor.
Shared Subscrip7on Online Store
Order Processor 3 Order Processor 2 Order Processor 1
Warehouse: London
Shared Subscription
( orders.*.london)
Shared
Subscription
Shared
Subscription
Data Archives
Analytics System
M1 M2 M3
M2M1 M3
M2M1 M3
M2M1 M3

14. Use Case –WSO2 ESB + MB
• Guarantees In-Order Delivery.
• ThroYle messages ( for slow consumers/systems).
• Ensure reliable messaging

15. WSO2 Message Broker (Design)
• Avoid rouIng messages over the network mulIple hops
• Use storage to share messages between nodes.
• Use distributed coordinaIon to control the behavior (i.e. Hazelcast)
• Leaner deployment layout ( and clustering story)

16. WSO2 Message Broker (Features)
• Protocols/SpecificaIons : JMS 1.1, AMQP 0-9-1, MQTT 3.1.1
• Simplified Clustering Story (and related concepts)
• Databases : MySQL, MSSQL, Oracle, PostgreSQL, H2
• Real Ime staIsIcs
- Quickly figure out boYlenecks in a producIon deployments.
- Database read/write latencies
- Inbound/Outbound event rates
- Number of ConnecIons/Channels etc.

17. Roadmap
• Support for AMQP 1.0 and JMS 2.0
• Improvements to Storage Scheme, Performance improvements
• AnalyIcs for MB
• Move Carbon 5
• Improved GUI
• MQTT + Websockets

18. WSO2 MB differenIator
• Simplified clustering story (- Queues/Topics)
– Users don’t have to worry about how brokers transmit messages in
the cluster.
• RDBMS for persistence →Easy to manage and use
• Simpler Cluster deployments → Minimum deployment effort +
maintenance.

19. Thank You!
#WSO2ConEU
Share your feedback for this session
wso2con.com/app