introduction to architectural patterns

30
Introduc)on to architectural pa1erns Georgiy Podsvetov [email protected]

Upload: georgy-podsvetov

Post on 16-Jul-2015

369 views

Category:

Software


0 download

TRANSCRIPT

Introduc)on  to  architectural  pa1erns  

Georgiy  Podsvetov  [email protected]  

Layered  architecture  

Presenta)on  layer  

Business  layer  

Persistence  layer  

Database  layer  2  

Layered  architecture  

closed   • Presenta)on  layer  

closed   • Business  layer  

closed   • Persistence  layer  

Closed   • Database  layer  

•  Layers  communicate  from  top  to  down  only  •  To  get  layer  below,  you  have  to  go  through  all  in  the  middle  

3  

What  if  we  have  some  kind  of  shared  services?  

closed   • Presenta)on  layer  

closed   • Business  layer  

closed   • Services  layer  

closed   • Persistence  layer  

Closed   • Database  layer  

Do  we  s)ll  need  pass  all  request  throw  this  layer?  

4  

Open  layered  architecture  

closed   • Presenta)on  layer  

closed   •     Business  layer  

open   •     Services  layer  

closed   • Persistence  layer  

Closed   • Database  layer  

Some  layers  might  be  open.    

5  

Layered  architecture  

•  Good  general  purpose  architecture  •  Easy  to  implement,  test,  and  govern  •  Good  star)ng  point  for  most  systems  •  Not  always  op)mized  for  specific  business  drivers  

closed   •  Presenta)on  layer  

closed   •  Business  layer  

closed   •  Services  layer  

closed   •  Persistence  layer  

Closed   •  Database  layer  

closed   •  Presenta)on  layer  

closed   •     Business  layer  

open   •     Services  layer  

closed   •  Persistence  layer  

Closed   •  Database  layer  

6  

Event-­‐driven  architecture  

•  Event  processor  topology  •  Broker  topology  •  Broker-­‐less  topology  

7  

Event  processor  topology  

Event  queue  

Event  processor  

Event  topic  

Event  topic  

processor   processor   processor   processor   processor  

Event  orchestra)on  

8  

Broker  topology  

Event  topic  

Event  topic  

processor  

processor  

processor  processor  

processor  

Event  topic  

Event  

processor  

processor  

processor  

media)on  

9  

Event  

process   process   process  

Broker-­‐less  topology  

Event  process  

process  

process  

10  

Event-­‐driven  architecture  

•  Highly  decoupled  and  distributed  •  Highly  scalable  •  High  degree  of  complexity  •  Good  for  event-­‐based  business  models  and  business  processes  

•  Not  good  for  processes  which  require  a  high  degree  of  data  sharing,  orchestra)on,  and  reuse  

11  

Service-­‐oriented  architecture  Business  services  

Enterprise  services  

Applica)on  services   Infrastructure  services  

Message  bus  

BS   BS   BS   BS   BS  

ES   ES   ES   ES   ES  

AS   IS  

Process  choreographer  

Service  orchestrator  

12  

Business  services  

Abstract  service  used  to  represent  a  business  process  or  func)on  independent  of  the  underlying  technology  or  pa1ern    •  Сan  be  derived  from  use  cases,  user  

stories,  user  scenarios  •  Contains  a  service  name,  input  

specifica)on,  and  output  specifica)on  •  Course-­‐grained  •  Shared  across  the  enterprise  

Business  services  

Enterprise  services  

Applica)on  services   Infrastructure  services  

Message  bus  

BS   BS   BS   BS   BS  

ES   ES   ES   ES   ES  

AS   IS  

Process  choreographer  Service  orchestrator  

13  

Enterprise  services  

Concrete  services  that  implement  Business  Services  

Business  services  

Enterprise  services  

Applica)on  services   Infrastructure  services  

Message  bus  

BS   BS   BS   BS   BS  

ES   ES   ES   ES   ES  

AS   IS  

Process  choreographer  Service  orchestrator  

•  The  rela)onship  between  an  Enterprise  Service  and  a  Business  Service  is  either  a  one-­‐to-­‐one  or  many-­‐to-­‐one  rela)onship  

•  Course-­‐grained  •  Represent  ac)ons  against  major  data  

en))es  •  Usually  require  some  sort  of  service  

orchestra)on  •  Shared  across  the  enterprise     14  

Applica)on  services  

Implementa)on  of  applica)on-­‐specific    func)ons,  such  as  database  querying,  valida)on,  etc.  

Business  services  

Enterprise  services  

Applica)on  services   Infrastructure  services  

Message  bus  

BS   BS   BS   BS   BS  

ES   ES   ES   ES   ES  

AS   IS  

Process  choreographer  Service  orchestrator  

•  Concrete  defini)on  •  Defined  by  applica)on  developers  •  Fine-­‐grained  •  Tightly  bound  to  a  specific  applica)on  

context  •  Generally  not  shared  across  the  

enterprise    

15  

Infrastructure  services  

Implementa)on  of  the  non-­‐business  related  func)ons,  like  logging,  error  handling,  single  sign  on,  etc.  

Business  services  

Enterprise  services  

Applica)on  services   Infrastructure  services  

Message  bus  

BS   BS   BS   BS   BS  

ES   ES   ES   ES   ES  

AS   IS  

Process  choreographer  Service  orchestrator  

•  Concrete  defini)on  •  Defined  by  applica)on  or  system  

developers  •  Fine-­‐grained  •  Supports  the  system  or  enterprise  

infrastructure  •  Shared  across  the  enterprise    

16  

Message  Bus  

Coordinates  services  and  processes,  it’s  a  glue  for  SOA  components  

Business  services  

Enterprise  services  

Applica)on  services   Infrastructure  services  

Message  bus  

BS   BS   BS   BS   BS  

ES   ES   ES   ES   ES  

AS   IS  

Process  choreographer  Service  orchestrator  

•  Process  choreography  •  Service  orchestra)on  •  Service  registry  •  Protocol  transforma)on  •  Message  enhancement  and  

transforma)on  

17  

Service-­‐oriented  architecture  

•  Good  pa1ern  for  understanding  and  implemen)ng  business  processes  and  services  

•  Very  high  level  of  complexity  •  Difficult  to  implement  due  to  complex  tools,  hype,  misconcep)ons,  and  heavy  business  user  involvement  

•  Good  pa1ern  for  large,  complex,  heterogeneous  businesses  that  have  a  large  number  of  common  services  

18  

Pipeline  architecture  

Producer   Transformer   Transformer  

Tester  Consumer  

pipe   pipe  

pipe  

pipe  

19  

Pipes  and  filters  

•  Uni-­‐direc)onal  only  •  Usually  point-­‐to-­‐point  for  high  performance,  but  could  be  message-­‐based  for  scalability  

•  Payload  can  be  any  type  

pipe  

filter  •  Self-­‐contained  and  independent  from  other  filters  

•  Usually  designed  to  perform  a  single  specific  task  

20  

Filter  types  

Producer  

Tester  

Consumer  

pipe  

pipe  

Transformer  pipe   pipe  

pipe   pipe  

Star)ng  point,  outbound  only  

Input,  processing,  output  

Input,  discard  or  pass-­‐thru  

Endpoint,  inbound  only    

21  

Pipeline  architecture  

•  Useful  for  smaller  determinis)c  systems  with  a  dis)nct  processing  flow  

•  Filters  can  easily  be  added  and  removed  •  Provides  for  a  high  level  of  decoupling  •  Supports  evolu)onary  design  •  Able  to  easily  adapt  to  changing  requirements  •  Can  be  easily  incorporated  into  another  pa1ern   Producer   Transformer   Transformer  

Tester  Consumer  

pipe   pipe  

pipe  

pipe  

22  

Microkernel  architecture  

Core  

Plug-­‐in  module  

Plug-­‐in  module  

Plug-­‐in  module  

Plug-­‐in  module  

Plug-­‐in  module  

23  

Microkernel  architecture  

•  Minimal  func)onality  to  run  system  •  General    business  rules  and  logic  •  Doesn’t  contain  custom  processing  

Core  

Plug-­‐in  module  

•  Standalone  independent  module  •  Specific  addi)onal  rules  or  logic  

Core  

Plug-­‐in  module  

Plug-­‐in  module  

Plug-­‐in  module  

Plug-­‐in  module  

Plug-­‐in  module  

24  

Microkernel  architecture  

•  Useful  for  systems  that  have  custom  processing  or  processing  is  suscep)ble  to  change  

•  Plug-­‐in  modules  can  be  easily  added  and  removed  

•  Supports  evolu)onary  design  •  Able  to  easily  adapt  to  changing  requirements    •  Can  easily  be  incorporated  into  another  pa1ern    

Core  

Plug-­‐in  module  

Plug-­‐in  module  

Plug-­‐in  module  

Plug-­‐in  module  

Plug-­‐in  module  

25  

Space-­‐based  architecture  

Virtualized  middleware  

Messaging  grid   Data  grid   Processing  grid   Deployment  manager  

Processing  unit  

-­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐    

Processing  unit  

-­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐    

Processing  unit  

-­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐    

26  

Processing  unit  

Module   Module   Module  

DB   In-­‐memory  data  

Data  replica)on  engine  

In  fact  it  is  standalone  version  of  yours  applica)on  

27  

Virtualized  middleware  

Manages  input  request  and  session    

Messaging  grid  

Data  grid  

Processing  grid  

Deployment  manager  

Manages  data  replica)on  between  processing  units    

Manages  parallel  request  processing    

Manages  dynamic  processing  unit  deployment    

28  

Space-­‐based  architecture  

•  Good  for  applica)ons  that  have  variable  load  or  inconsistent  peak  )mes  

•  Not  good  fit  for  tradi)onal  large-­‐scale  rela)onal  database  systems  

•  Rela)vely  complex  and  expensive  pa1ern  to  implement    

Virtualized  middleware  

Messaging  grid   Data  grid   Processing  

grid  Deployment  manager  

Processing  unit  

-­‐  -­‐  -­‐  -­‐  -­‐    

Processing  unit  

-­‐    -­‐    -­‐  -­‐    

Processing  unit  

-­‐  -­‐  -­‐  -­‐  -­‐    

29  

h1p://goo.gl/BiV940  

h1p://goo.gl/vmv0Ww  

h1p://goo.gl/NI6uE2  

h1p://goo.gl/XEw0JB  

Ques)ons?  

Georgiy  Podsvetov  [email protected]  

Recommended  reading:  

h1p://ua.linkedin.com/pub/georgiy-­‐podsvetov/45/989/868  

h1ps://www.facebook.com/GeorgiyPodsvetov   30