Reliable Messaging /Guaranteed delivery

1,790 views

Published on

Published in: Technology, Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,790
On SlideShare
0
From Embeds
0
Number of Embeds
27
Actions
Shares
0
Downloads
45
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Reliable Messaging /Guaranteed delivery

  1. 1. Last Updated: Jan. 2014 Director  –  Solu-ons  Architecture   Manoj  Fernando   SOA  Pa/erns  Webinar  Series   Reliable  Messaging  /Guaranteed  delivery  
  2. 2. 2   About  WSO2   ๏  Global  enterprise,  founded  in  2005   by  acknowledged  leaders  in  XML,   web  services    technologies,   standards    and  open  source   ๏  Provides  only  open  source   plaIorm-­‐as-­‐a-­‐service  for  private,   public  and  hybrid  cloud   deployments   ๏  All  WSO2  products  are  100%  open   source  and  released  under  the   Apache  License  Version  2.0.   ๏  Is  an  AcQve  Member  of  OASIS,   Cloud  Security  Alliance,  OSGi   Alliance,  AMQP  Working  Group,   OpenID  FoundaQon  and  W3C.   ๏  Driven  by  InnovaQon   ๏  Launched  first  open  source  API   Management  soluQon  in  2012   ๏  Launched  App  Factory  in  2Q  2013   ๏  Launched  Enterprise  Store  and   first  open  source  Mobile  soluQon   in  4Q  2013  
  3. 3. 3   What  WSO2  delivers  
  4. 4. 4   Business  Model  
  5. 5. 5   About  the  Presenter   Manoj  Fernando     (Director  -­‐  SoluQons  Architecture  @  WSO2)   Email  :  manojf@wso2.com     Blog  :  h/p://manoj-­‐fernando.blogspot.com/  
  6. 6. 6   Problem       Service  communicaQon  cannot  be  guaranteed  when   using  unreliable  messaging  protocols  or  when   dependent  on  an  otherwise  unreliable  environment.     Source  :  h/p://soapa/erns.org/  
  7. 7. 7   Need  for  reliability   §  Guaranteed  message  delivery  is  a  guaranteed  requirement  in   Distributed  and  Service  Oriented  Architectures.   §  ApplicaQons  usually  depend  on  middleware  +  infrastructure  for   making  sure  that  messages  are  delivered…   §  Just  Once  (Avoiding  duplicaQons)   §  Accurately  (In  full  and  uncorrupted)   §  On  Qme  (In  order  and  as  soon  as  possible)   §  Resilience  over  transport  and  system  failures.  
  8. 8. 8   EvoluQon   §  Various  a/empts  to  handle  reliability  using  addiQonal  message   exchanges.   §  WS-­‐RM  specificaQon  aimed  at  delivering  messages   Exactly  Once   and  In  Order  which  was  the  primary  moQve.   §  SpecificaQon  also  aimed  at  keeping   Composability  intact  with   other  specificaQons  and  standards  (i.e.  WS-­‐RM s  dependency  on   WS-­‐Addressing).   §  WS-­‐Reliability  -­‐  an  alternaQve  specificaQon  (implementaQon  :     RM4GS)  submi/ed  and  standardized  in  parallel  to  WS-­‐RM.  
  9. 9. 9   WS-­‐RM  Core  Model  
  10. 10. 10   So…where  does  WS-­‐RM  currently  stand?   §  Various  vendors  have  adapted  the  standard  and  have  come  up   with  their  different  implementaQons.   §  SQll  in  use,  but  not  as  much  as  it  should  have  been.   §  Dependency  on  addiQonal  service  and  client  level  configuraQons   were  probably  a  key  reason  behind  its  less  adaptability.   §  Some  of  these  drawbacks  have  led  for  applicaQon  designers  to  look   for  alternaQve  means  to  achieve  reliable  delivery.  
  11. 11. 11   Key  CharacterisQcs  of  Reliability   IrrespecQve  of  the  specificaQon,  standard  or  implementaQon…  the   objecQves  are  clear!     § Resilience  and  Delivery  Assurance  (Transport/Component)   § Must  be  transparent  to  sender  and  ulQmate  receiver   § AutomaQc  retying  over  failure  a/empts.   § IdenQficaQon  and  Sequencing  (Avoid  duplicaQons)   § Order  needs  to  be  maintained.   § Acknowledged  and  noQfied.  
  12. 12. 12   SoluQon       An  intermediate  reliability  mechanism  is  introduced   into  the  inventory  architecture,  ensuring  that  message   delivery  is  guaranteed.     Source  :  h/p://soapa/erns.org/  
  13. 13. 13   Service  Pa/ern   §  Service  consumers  depends  on  an  intermediate  reliability  mechanism  to   reliably  deliver  the  messages  to  the  backend  service.   intermediate reliability mechanism Service Consumer Backend Service (A) (A) (ACK) (ACK) (B) (A) – Message Delivery flow (B) – Persistence Repo Message send and retry
  14. 14. 14   Sample  Scenario   An  account  holder  makes  a  credit  card  repayment  at  an  ATM,   and  the  transacQon  must  update  the  account  balance  upon   confirmaQon.     Transaction Creation Transaction Dispatch Card Repayment Workflow Transaction Processor RM Source RM Destination Transmit Acknowledge Accept Accept Send Deliver Application Source Application Destination
  15. 15. 15   CriQcal  Success  Factors  for  this  model  to  work   §  RM  Source  must  persist  the  message  immediately  aner  accepQng   §  RM  Source  has  to  asynchronously  deliver  the  message  not  leong   the  applicaQon  source  to  wait.   §  Message  has  to  be  delivered  iteraQvely  (with  configurable  wait   Qmes,  and  number  of  retries)  and  the  delivery  process  should  only   end  aner  the  acknowledgement  is  received  back  from  RM   desQnaQon.   §  The  ApplicaQon  source  needs  to  be  noQfied  (opQonal)   RM Source RM Destination Transmit Acknowledge Accept Accept Send Deliver
  16. 16. 16   ImplemenQng  RM  using  WSO2  plaIorm   Service Consumer Service (ACK) (ACK) (B) Message send / retry Message Store (REQ) (REQ) Message Processor Queue
  17. 17. 17   Use  Case  :  Scenario  A   §  The  client  sends  requests  to  a   proxy  service.   §  The  proxy  service  immediately   stores  the  messages  to  a  JMS   message  store.     §  The  back-­‐end  service  is  invoked   by  a  message  forwarding   processor,  which  picks  stored   messages  in  the  JMS  message   store.   §  Message  is  removed  from  the   store  upon  acknowledgement   by  the  backend  service.       Proxy Message Store Message Forwarding Processor Backend Service Reliable In Only Invocation
  18. 18. 18   Use  Case  :  Scenario  B   §  Extension  to  Scenario  A   §   Service  invocaQon  places   the  response  on  to  a  reply   sequence.   §  Can  use  a  callback  URL  to   noQfy  the  ApplicaQon   source.     Proxy Message Store Message Forwarding Processor Backend Service Reliable Invocation Reply Sequence Callback URL to Notify
  19. 19. 19   What  makes  a  Message  Broker  a  good  candidate?   §  Message  Autonomy    Messages  are  self-­‐contained  autonomous  entries  and  can  be  sent    and  re-­‐sent  many  Qmes  across  its  lifecycle.   §  Store  and  Forward  nature    Once  marked  as  persisted,  it  is  the  responsibility  of  the  JMS    provider  to  deliver  to  the  desQnaQon.   §  Message  Acknowledgements    Message  Acknowledgement  is  an  in-­‐built  feature  of  JMS.    
  20. 20. 20   ESB  Config   <proxy …> <target> <inSequence> <log/> <property name="FORCE_SC_ACCEPTED" value="true" scope="axis2"/> <property name="OUT_ONLY" value="true"/ > <property name="target.endpoint" value="AccountCreditEP"/> <log level="full"/> <store messageStore="JMSMS"/> </inSequence> <outSequence> <log/> </outSequence> </target> <publishWSDL uri="http://10.100.0.134:9764/ services/AccountCreditService?wsdl"/> <description/> <messageStore class="org.apache.synapse.message.st ore.impl.jms.JmsStore" name="JMSMS"> <parameter name="java.naming.factory.initial">org. wso2.andes.jndi.PropertiesFileInitialCon textFactory</parameter> <parameter name="java.naming.provider.url">reposi tory/conf/jndi.properties</parameter> <parameter name="store.jms.destination">JMSMS</ parameter> </messageStore> Sample Proxy Configuration MessageStore Configuration
  21. 21. 21   ESB  Config   <messageProcessor class="org.apache.synapse.message.processor.impl.forwarder.ScheduledMess ageForwardingProcessor" name="AccountCreditMessageProcessor" targetEndpoint="AccountCreditEP" messageStore="JMSMS"> <parameter name="max.delivery.attempts">4</parameter> <parameter name="client.retry.interval">6000</parameter> <parameter name="interval">5000</parameter> <parameter name="is.active">true</parameter> <parameter name="message.processor.reply.sequence">replySequence</ parameter> </messageProcessor> Message Processor Configuration
  22. 22. 22   TesQng  the  sample  scenario   JAX-WS Service Service Consumer Service (ACK) (B) Message send / retry Message Store (REQ) (REQ) Message Processor Queue
  23. 23. 23   Demo  &  Q&A  
  24. 24. Contact  us  !  

×