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