Introduction to Mule

Introduction to Mule

Transcript

10. MuleSo1  leads  the  market  in  connec=ng  applica=ons  on-­‐ premise  and  in  the  cloud.  [CLICK]     There  are  over  3,500  on-­‐premise  deployments  of  our   solu=ons.  [CLICK]   And  there  are  over  25,000  deployments  of  our  cloud   solu=ons  [CLICK]   Over  35%  of  the  Global  500  uses  our  solu=ons  [CLICK]   We  are  a  global  business,  headquartered  in  Silicon  Valley   with  offices  throughout  the  US,  Europe,  La=n  America   and  Asia.          
13. •  Here,  complexity  arises  naturally  from  common  varia%on  in  basic  aspects  of   integra=on,  including:  transport  protocols;  data  formats;  execu=on  (or  invoca=on)   styles  (e.g.  synchronous  vs.  asynchronous,  batch,  etc.);  data  (i.e.  object)  and   executable  lifecycles  .   •  Without  architecture  and  framework  –  and  general  support  for  good  object-­‐ oriented  design  (OOD)  -­‐  such  as  provided  by  Mule  ESB,  this  complexity  results  in   repe,,on  of  code     •  Reuse  of  code,  clarity  (or  exposure)  of  design  and  separa,on  of  concerns  are  all   key  benefits  of  good  object-­‐oriented  design  (OOD)  and  implementa=on,  which  are   fully  supported  by  Mule  ESB  and  Mule  Studio.   •  Separa=on  of  concerns  generally  means  separa=ng  into  system  vs.  applica=on   layers,  or  into  independently-­‐varying  par%%ons  (such  as  MVC)  of  an  applica=on.   •  With  Mule  ESB,  there  is  no  repe==on  of  code  due  to  complex  varia=on  or  lack  of   separa=on  of  concerns.    Basic  aspects  such  as  transport  protocols  are  managed  by   ESB,  so  that  there  is  separa=on  between  system  and  applica=on  layers.    There  is   further  separa=on  of  concerns  between  different  basic  aspects  common  to   applica=ons,  such  as  security,  audi=ng  and  rou=ng.       •  Robustness  here  means  the  ability  of  an  applica=on  to  con=nue  func=oning   through  a  broad  range  of  condi=ons,  including  some  types  or  degrees  of  failure  in   applica=on  processing  such  as  transac=ons,  etc.    It  connotes  the  opposite  of   fragility  in  an  applica=on.    This  depends  on  good  excep=on  or  error  handling,     13