Last Updated: Jan. 2014

Director  –  Solu-ons  Architecture  Manoj  Fernando  

SOA  Pa/erns  Webinar  Series  Reliable  Messaging  /Guaranteed  delivery  

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  

What  WSO2  delivers  

4  

Business  Model  

5  

About  the  Presenter  

Manoj  Fernando    (Director  -­‐  SoluQons  Architecture  @  WSO2)  Email  :  manojf@wso2.com    Blog  :  h/p://manoj-­‐fernando.blogspot.com/  

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  

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  

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  

WS-­‐RM  Core  Model  

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  

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  

SoluQon  

   

An  intermediate  reliability  mechanism  is  introduced  into  the  inventory  architecture,  ensuring  that  message  

delivery  is  guaranteed.    

Source  :  h/p://soapa/erns.org/  

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  

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

Acc

ept

Send Deliver

Application Source

Application Destination

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

Acc

ept

Send Deliver

16  

ImplemenQng  RM  using  WSO2  plaIorm  

Service Consumer Service

(ACK) (ACK)

(B)

Message send / retry

Message Store

(REQ) (REQ)

Message Processor

Queue

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  

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  

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  

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/> </proxy>

<messageStore class="org.apache.synapse.message.store.impl.jms.JmsStore" name="JMSMS"> <parameter name="java.naming.factory.initial">org.wso2.andes.jndi.PropertiesFileInitialContextFactory</parameter> <parameter name="java.naming.provider.url">repository/conf/jndi.properties</parameter> <parameter name="store.jms.destination">JMSMS</parameter> </messageStore>

Sample Proxy Configuration

MessageStore Configuration

21  

ESB  Config  

<messageProcessor class="org.apache.synapse.message.processor.impl.forwarder.ScheduledMessageForwardingProcessor" 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  

TesQng  the  sample  scenario  

JAX-WS Service

Service Consumer Service

(ACK)

(B)

Message send / retry

Message Store

(REQ)

(REQ)

Message Processor

Queue

23  

Demo  &  Q&A  

Contact  us  !