wso2-esb.pdf



Comments



Description

Prabath SiriwardenaDirector, Security Architecture •  A  design  paradigm  and  discipline  -­‐  used  by  IT  to  improve   its  ability  to  quickly  and  efficiently  meet  business   demands.   •  A  style  of  software  architecture  that  is  modular,   distributed  and  loosely  coupled.   •  Componentization  –  The  main  driver  of  SOA  Business   Functionalities  are  implemented  in  different  Business   •  Components   •  Business  Components  provide  their  functionality  to  its   consumers  as  a  ‘Service’  with  the  well-­‐defined  service   interfaces.   Modern  Enterprises     Comprised  of  so  many  Systems  and  Services  built  based  on   open  standards,  custom-­‐built,  acquired  from  a    third  party,   part  of  a  legacy  system  or  any  such  combination       Integration     Organizations  move  away  from  monolithic  systems   Multiple  Systems  connected  via  SOA  as  the  blue  print     .  The  ESB  makes  the  service  accessible  to   other  applications  via  one  or  more  middleware  protocols.  the  ESB   provides  an  abstraction  layer  that  virtualizes  the  service  and  separates  it   from  infrastructure  concerns.  An  ESB   models  an  application  endpoint  as  a  service.  As  a  general   rule.  In  both  cases.  The  ESB  may  host  the  service   agent  locally.  one  of  the  protocols  that  an  ESB  supports  is  Simple  Object  Access   Protocol  (SOAP).  but  it  doesn't  require  all  services  to  communicate  via   SOAP.  The  ESB  mediates  interactions  between  service  endpoints  and   enables  dissimilar  systems  to  interoperate.     .An  ESB  is  a  middleware  solution  that  enables  interoperability  among   heterogeneous  environments  using  a  service-­‐oriented  model.  or  the  service  may  execute  remotely. Message  Routing.     ESB  performs  message  routing  either  based  on   predefined/derived  paths  or  based  on  the  content  of   the  incoming  message.   .     This  could  be  from  HTTP/  HTTPS  to  FTP  or  SMTP  or   any  other  protocol.Protocol  Switching.   .     The  backend  SOAP  services  can  be  exposed  to  REST/ JSON  clients  and  the  ESB  will  take  care  of  the   message  transformation.Message  Transformations.   .     We  may  need  to  develop  adaptors  and  plug  those   into  the  ESB  while  exposing  legacy  systems  as   standard  services  to  the  outside.   .Expose  legacy  systems  through  a  standard   interface.  The  adaptors  will   take  care  of  transforming  the  incoming  messages  to   the  message  formats  expected  by  the  legacy   systems.     ESB  should  be  able  to  expose  proxy  services  to  cater   some  business  functionalities  by  wrapping  some   concrete  backend  services.Expose  business  functionalities  through  service   orchestration.   .  which  could   possibly  break  the  service  contract  with  old  clients.   the  EBS  can  still  transform  the  requests  from  old   clients  into  the  new  format.     By  decoupling  the  service  from  the  client  and   exposing  it  through  an  ESB  allows  handling   versioning  at  the  perimeter  level.Handling  Versioning.  When  a  new  version   of  a  service  been  added  to  the  system.   .     .  authorization  and  throttling.Centralized  policy  enforcement  point  for   authentication.     Security  can  be  enforced  at  the  ESB  while  the   concrete  backend  services  either  could  be  secured  or   non-­‐secured.  In   case  of  WSO2  ESB.     .     As  all  the  messages  pass  through  the  ESB.Centralized  auditing  and  monitoring.  this  is  one   of  the  best  places  to  do  auditing  and  monitoring.  it  can  be  easily  integrated  with   WSO2  BAM  (Business  Activity  Monitor).   Hence  lowering  the  chances  for  a  Denial  of  Service   attack.Message  screening  and  schema  validation.     Doing  message  screening  and  schema  validation  at   the  perimeter  level  could  help  to  drop  invalid   messages  as  early  as  in  the  message  processing  flow.   .     .     In  addition  to  all  the  above  functionalities.  Also.  the  Service   Gateway  also  could  act  as  a  reliable  message  store.  the  message   store  can  be  used  to  match  the  rate  limits  expected   by  backend  services.Reliable  message  store.  It   can  persist  messages  and  deliver  those  to  backend   services  when  they  are  available. :  FIX.g.   .  high  performance  ESB     •  Feature  rich  and  standards  compliant      –  SOAP  and  WS-­‐*  standards    –  REST  support    –  Domain  specific  protocol  support  (e.  HL7)     •  User  friendly  and  highly  extensible   •  100%  free  and  open  source  with  commercial  support.•  A  lightweight.   •  Built  on  top  of  WSO2  Carbon.  remove  and  customize  features  –  Similar  to   Eclipse  plug-­‐ins     •  Easily  deploy  third  party  libraries  and  custom  code  into   the  server  runtime     •  Web  based  management  console   .•  An  OSGi  based  components  framework  for  SOA     •  Extensive  modularity  and  reusability     •  Easily  add. . . . . •  •  •  •  •  •  •  Mediator     Sequence   Endpoint   Proxy  Service   REST  API     Topics   Message  Stores/Processors     •  •  •  •  •  •  Templates     Tasks     Local  Entries     Priority  Executors     Transport  Receivers/Senders   Message  Builders/Formatters   •  Mediator  is  the  smallest  functional  unit  in  WSO2   ESB.     •  A  mediator  is  granular  enough  to  perform  a  given   specific  task.     •  WSO2  ESB  comes  with  a  rich  collection  of   mediators  addressing  most  of  the  common   integration  problems.      -­‐  Log  mediator  can  be  used  to  log  any  incoming/outgoing  messages.      -­‐  The  DBLookup  mediator  can  be  used  to  retrieve  information  from  a        database.      -­‐  Header  mediator  can  be  used  to  add  or  remove  SOAP  headers.     .  it  does  not   limit  the  user  to  those.     •  If  you  want  to  extend  the  functionality   of  WSO2  ESB  you  can  simply  do  it  by   writing  your  own  mediator.     •  Using  a  Class  mediator  is  one  of  the   easiest  and  the  mostly  used  way  of   extending  the  ESB’s  functionality.•  Although  WSO2  ESB  comes  with  a  rich   collection  of  mediators.   .     .  In  a  way  it  organizes  mediators  to   form  Pipes  and  Filters  pattern.A  sequence  is  a  logical  grouping  of  set  of   mediators. •  An  end  point  is  a  logical  abstraction  over  an  external   destination  where  WSO2  ESB  has  to  deliver  the   message.   .   •  The  end  point  defined  in  WSO2  ESB  can  also  take  care   of  quality  of  service  aspects  like  security.  reliability   corresponding  to  the  external  destination.     Having  support  for  load-­‐balancing  endpoints   you  can  also  use  WSO2  ESB  as  a  load   balancer.     .     By  default  WSO2  ESB  supports  round-­‐robin   load-­‐balancing  algorithm.•  •  •  Load-­‐balancing  endpoint  is  an  abstraction   over  a  set  of  endpoints  that  you  want  to   distribute  the  incoming  load.  but  it  does  not   prevent  you  from  having  your  own.   The  default  fail  over  behaviour  is  dynamic  fail-­‐ over  and  it  will  fall  back  to  the  primary   endpoint  as  soon  as  it  is  available.     •  If  the  primary  endpoint  fails  then  ESB  will  start   sending  messages  to  the  next  available  one.   .  it  will  mark  it  as  inactive.•  Fail-­‐over  endpoint  is  an  abstraction  over  a  set   of  endpoints  where  you  can  define  the  fail-­‐ over  behaviour.     •  Whenever  the  ESB  discovers  a  given  endpoint   is  down.     •  In  WSO2  ESB.     •  In  most  of  the  cases  a  proxy  service  as  its  name  implies   proxies  a  real.  It  can  simply  provide  a   level  abstraction  over  one  concrete  service  or  many   other  business  services.•  A  proxy  service  provides  a  well-­‐defined  SOAP  endpoint   to  the  outside.   •  A  proxy  service  may  or  may  not  have  a  one  to  one   mapping  to  a  business  service.  concrete  business  service.   .  a  proxy  service  is  built  with  a  collection   sequences.   .  which  you  can  override.     •  WSO2  ESB  comes  with  a  default  main   sequence.     •  Any  message  that  is  not  directed  to  a   proxy  service  or  an  API  will  hit  the   main  sequence.•  Main  sequence  is  a  pre-­‐defined  named   sequence.  This   sequence  won’t  get  executed  for  the  exceptions   thrown  from  the  backend  business  services.   Those  will  still  go  through  the  Out-­‐Sequence.   You  can  also  associate  a  Fault-­‐Sequence  with  a   proxy  service  and  it  will  get  executed  when  an   exception  happens  in  a  proxy  operation.   A  response  message  comes  from  a  concrete  or  a   business  service  will  go  through  the  Out-­‐ Sequence  defined  for  the  corresponding  proxy   service.•  •  •  A  request  message  comes  in  to  a  given  proxy   service  will  hit  the  In-­‐Sequence  defined  for  that   proxy  service.   . .   .   •  Can  be  even  configured  using  the  CRONTAB  Simple   API  to  develop  custom  tasks  syntax.   •  Frequency  (time  interval  between  two  executions)  and   the  number  of  times  to  run  the  task  is  configurable.•  A  programmed  activity  configured  to  run  periodically.   •  Based  on  the  Quartz  job  scheduler  for  Java. . . SAPTransportLi stener"/>   .sap.wso2.<transportSender  name=”idoc”   class="org.SAPTransportS ender"/>       <transportReceiver  name=”idoc”   class="org.transports.transports.wso2.sap.carbon.carbon. messaging.carbon.hl7.HL7TransportSender"/>   .transp ort.messaging.HL7    <transportReceiver  name="hl7"   class="org.business.HL7TransportListener"/>            <transportSender  name="hl7"   class="org.carbon.wso2.wso2.transp ort.hl7.business. FIXTransportLi stener"/>            <transportSender  name="fix"   class="org.FIXTransportS ender"/>   .transport.transport.fix.fix.FIX    <transportReceiver  name="fix"   class="org.synapse.apache.apache.synapse. jms.apache.jms.JMS   <transportReceiver  name="jms"   class="org.transport.JMSListener">   </transportReceiver>       <transportSender  name="jms"   class="org.apache.JMSSender"/>   .axis2.axis2.transport.  again  based  on  the  output  content  type.•  Message  Builder  :  When  a  message  comes  through  a   given  transport(HTTP)  to  the  WSO2  ESB  we  need  to   build  a  SOAP  message  out  of  that  (e.:  SOAP  to  JSON)   .  the   message  should  be  converted  to  the  required  format.   •  Message  Formatter  :  When  a  message  goes  out  from   ESB.g.   (e.g.  convert  JSON   to  SOAP/XML)  based  on  the  message's  content  type.. hl7.messaging.business.carbon.messa ge.wso2.business.hl7.carbon.HL7    <messageFormatter  contentType="application/edi-­‐hl7"         class="org.messaging.wso2.HL7MessageFormatter"/>            <messageBuilder  contentType="application/edi-­‐hl7"                   class="org.HL7MessageBuilder"/>   .messa ge. Synapse Incoming req Thread1 Request processing Socket open Socket open Thread2 Outgoing resp Outgoing req Response processing Incoming resp .     •  Incoming  message  content  was  placed  in  a   SharedInputBuffer  and  the  outgoing  message  content   was  placed  in  a  SharedOutputBuffer.     .•  NHTTP  transport  was  based  on  a  dual  buffer  model.  reading   from  the  input  buffer  and  writing  to  the  output  buffer.     •  Apache  Axiom.  Apache  Axis2  and  the  Synapse   mediation  engine  sit  between  the  two  buffers.     •  The  main  downside  is  every  message  happens  to  go   through  the  Axiom  layer.  which  is  not  really  necessary  in   cases  like  HTTP  load  balancing  and  HTTP  header-­‐based   routing.•  The  key  advantage  of  this  architecture  is  that  it  enables   the  ESB  (mediators)  to  intercept  all  the  messages  and   manipulate  them  in  any  way  necessary.   •  The  default  HTTP/HTTPS  transport  prior  to  ESB  4.6.0     .     •  Also  the  overhead  of  moving  data  from  one  buffer  to   another  was  not  always  justifiable  in  this  model. 6.0.•  Based  on  a  single  buffer  model  and  completely  bypassed   the  Axiom  layer.   •  The  default  HTTP/HTTPS  transport  since  ESB  4.   •  On-­‐demand  message  parsing  in  the  mediation  engine.     . •  A  Message  Builder.  and  a   Message  Formatter  that  takes  the  input  stream  and   writes  it  directly  to  a  output  stream.wso2.BinaryRelayBuilder   •  Formatter  :org.relay.     .     •  Builder  :  org.wso2.relay.  that  takes  the  input  stream  and  hides   it  inside  a  fake  SOAP  message  without  reading  it.carbon.ExpandingMessageFor matter   •  The  Builder  Mediator  can  be  used  to  build  the  actual   SOAP  message  from  a  message  coming  in  to  ESB  through   the  Message  Relay.carbon. •  Message  Mediation   •  Service  Mediation   •  Priority  Mediation   . . •  In  service  mediation.     •  In  this  mode.     •  Typically.  that  accepts  messages  from  clients.  the  ESB  exposes  a  service  endpoint   on  the  ESB.  the  WSO2  ESB  could  expose  a  service   already  available  in  one  transport.  and  the  role  of  the  ESB  would  be  to   "mediate"  these  messages  before  they  are  proxied  to  the   actual  service.  over  a  different   transport  or  expose  a  service  that  uses  one  schema  or   WSDL  as  a  service  that  uses  a  different  schema  or  WSDL   etc.   .  these  services  act  as  proxies  for  existing   (external)  services.    Message  mediation  level  -­‐  If  users  use  ESB  for  heavy    processing  like  XSLT  and  XQuery.   •  Uses  Enqueue  mediator  to  priority  based  mediation  at   the  mediation  level.   .•  The  priority  based  mediation  is  implemented  in  two   levels  in  WSO2  ESB:    HTTP  transport  level  -­‐  If  users  would  like  to  use  the    ESB  as  a  pure  router.     .  Enterprise  Integration  Pattern   explains  how  to  handle  a  scenario  where  a  single  logical   function  being  implemented  across  multiple  different   systems.•  Content-­‐Based  Router. •  •  •  The  Dynamic  Router.     The  Dynamic  router  can  be  self-­‐configured  based  on  special  configuration   messages  from  participating  destinations.     Each  business  service  has  to  announce  their  capabilities  and  Dynamic  Router  will   maintain  a  list  of  them.     .  Enterprise  Integration  Pattern  explains  how  to  avoid   dependency  of  the  router  on  all  possible  destinations  /  business  services  while   maintaining  its  efficiency.  Enterprise  Integration  Pattern  explains  how  to   handle  a  scenario  where  the  incoming  request  brings   multiple  elements  in  it  and  each  element  needs  to  be   handled  in  a  separate  manner     .•  Splitter.  so  the  result  can  be   processed  as  a  whole.     .•  Aggregator  EIP  talks  about  combining  the  results  of   individual  but  related  messages. •  Scatter  and  Gather  Enterprise  Integration  Pattern   explains  how  to  handle  a  scenario  where  the  incoming   request  has  to  be  handled  by  multiple  recipients  and  each   recipient  will  reply  back  to  form  an  aggregated  response.   . •  Service  Chaining  Enterprise  Integration  Pattern  explains   how  to  handle  a  scenario  where  the  incoming  request  has   to  be  orchestrated  through  multiple  business  services  in   an  order.   .  Enterprise  Integration  Pattern   explains  how  to  handle  a  scenario  where  one  needs  to   publish  events  to  all  the  interested  parties  without   maintaining  any  hard  coupling  between  those.   .•  Publish  &  Subscribe. •  The  Message  Store  Enterprise  Integration  Pattern   explains  how  to  capture  information  about  each  message   in  a  central  location.  Also.     .  the  Message  Store  can  be  used   to  match  the  rate  limits  expected  by  backend  services.   •  It's  required  to  have  transaction  manager  to  handle   distributed  transactions.blogspot.html   .   •  Supports  distributed  transactions  through  XA.com/2012/11/distributed-­‐transactions-­‐with-­‐wso2-­‐esb.   http://dinushasblog.   •  Transaction  Mediator  supports  distributed  transactions   using  JTA.•  Supports  JDBC/JMS  local  transactions.     •  WSO2  ESB  has  integrated  the  "Atomikos"  transaction   manager  which  is  a  implementation  of  Java  Transaction   API  (JTA).
Copyright © 2024 DOKUMEN.SITE Inc.