You are on page 1of 22

 

 
 

Architecture  Design  
Concept  Catalog  V2.0  
for  Augmented  Attribute-­Driven  Design  (ADD)  
 
 
 
 
Humberto  Cervantes  (hcm@xanum.uam.mx)  
Rick  Kazman  (kazman@hawaii.edu)  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
   

 
Architecture  Design  Concept  Catalog  V2.0  
1  
 
 
 

 
Changes  
 
Version   Date   Summary  of  changes  

1.0   May  2013   Initial  version  produced  for  the  SATURN  tutorial  ADD  in  
the  Real  World  

2.0   February  2014   Added  reference  architectures  and  deployment  patterns  


 
 
Table  of  contents  
Introduction  ………….………….…………….………….………….………….……….  4  
Reference  Architectures………….………………….………….………….…………...6  
Web  Applications………….…………………….………….………….…………...6  
Rich  Client  Applications………….………….………….………….………….…...7  
Rich  Internet  Applications………….………….………….………….……………..9  
Mobile  Applications………….………………….………….………….……….….11  
Service  Applications………….…………………….………….………….……….13  
Deployment  Patterns………….………….………….………….………….………….15  
Non-­distributed  Deployment………….………………….………….…………….15  
Distributed  Deployment………….…………………….………….………….…...15  
Client-­server  deployment………….…………………….………….………...16  
2-­Tier  deployment………….…………………….………….………….……..16  
3-­Tier  Deployment………….…………………….………….………….…….17  
4-­Tier  Deployment………….…………………….………….………….…....17  
Performance  Patterns:  Load-­balanced  cluster…………………….…………...18  
Reliability  Patterns:  Failover  Cluster………….…………………….…………...18  
Security  Patterns………….…………………...………….………….…………..19  
Impersonation  /  Delegation…………………….………….………….……..19  
Trusted  subsystem………….…………………….………….………….…..20  
Multiple  Trusted  Service  Identities………….………….………….………..21  
Scalability  Patterns………….………….………………….………….………….21  
Design  Patterns………….………….………….…………………….………….…….23  
From  Mud  to  Structure  (structuring  the  system)…………………….………...23  
Layers………….………….………….…………………….………….……...23  
Model  View  Controller  (MVC)………….…………………….………….…..23  
Presentation-­Abstraction-­Control  (PAC)…………………….………….….24  
Microkernel………….………….………….………….………….…………..25  
Pipes  and  Filters………….………….…………………….………….……..26  
Domain  Object………….………….………….………….………….……….26  
Distribution  infrastructure………….………….………….………….…………...27  
Messaging………….………….………….………….………….…………...27  
Publisher-­Subscriber………….………….………….………….…………...28  
Broker………….………….………….………….………….………….……..29  
Interface  Partitioning………….………….………….………….………….……..30  

 
Architecture  Design  Concept  Catalog  V2.0  
2  
 
 
 

Explicit  Interface…………………….………….………….…….………….30  
Proxy………….………….…………….………….………….…….……….30  
Concurrency………….………….……………….………….………….……….31  
Half-­Sync/Half-­Async………….……………….………….……………….31  
Leader-­Followers………….……………….………….………….…..…….32  
Object  interaction………….………….…………………….………….………..33  
Observer………….………….…………………….………….………….….33  
Command………….………….…………………….………….…………...34  
Data  Transfer  Object………….…………………….………….…………..35  
Resource  Management………….…………………….………….…………....35  
Lazy  Acquisition………….………….…………………….………….…...35  
Database  Access………….………….…………………….………….……....36  
Database  Access  Layer………….…………………….………….……...36  
Data  Mapper  (aka  Data  Access  Object  -­  DAO)…………………….…..37  
Tactics………….………….………….………….…………………….………….…39  
Availability  Tactics………….………….………….…………………….……...39  
Interoperability  Tactics………….………….…………………….…………....41  
Modifiability  Tactics………….………….…………………….………….…….42  
Performance  Tactics………….………….…………………….……………....43  
Security  Tactics………….………….………….………………….……….…..44  
Testability  Tactics………….………….………….………………….………...45  
Usability  Tactics………….………….………….………….……………….….47  
Frameworks………….………….………….………….………….……………..….48  
Structuring  the  system  +  supporting  quality  concerns………………….….48  
Spring  framework………….………….………….………………….…….48  
User  interface………….………….………….………….………………….….49  
Java  Server  Faces  framework………….………….……………………..49  
Swing  Framework………….………….………….……………………....50  
OO-­Relational  Mapping………….………….………….……………………..51  
Hibernate  Framework………….………….………….…………………..51  
MyBatis  Framework………….………….………….…………………....52  
Remote  communication………….………….………….…………………….53  
RMI  Application  Programming  Interface………….…………………….53  
Axis2  Web  Services  Framework………….………….………………....54  
JMS  Framework………….………….………….…………………….…..55  
Deployment………….………….………….………….…………………...….56  
Java  Web  Start  Framework………….………….……………………....56  
 

   

 
Architecture  Design  Concept  Catalog  V2.0  
3  
 
 
 

Introduction  
This  catalog  lists  several  types  of  design  concepts  that  are  to  be  used  in  the  design  of  a  software  
architecture.  These  design  concepts  are  primitives  or  building  blocks  that  include:  
● Reference  Architectures  
● Deployment  Patterns  
● Architectural  design  patterns  
● Architectural  Tactics  
● Frameworks.  
 
The  different  types  of  design  concepts  are  used  at  different  moments  of  the  design  process.  A  suggested  
roadmap  for  their  use  in  the  development  of  a  greenfield  system  is  shown  in  figure  1.  
 

 
Figure  1.  Suggested  roadmap  for  the  use  of  design  concepts  along  different  moments  of  architectural  design  
 
In  this  suggested  roadmap,  Reference  Architectures  and  Deployment  Patterns  are  initially  used  to  establish  
an  overall  structure  for  the  system.  Once  this  overall  structure  has  been  established,  functional  modules  
(Domain  Objects)  within  the  reference  architecture  are  identified  to  support  the  system’s  functionality.  These  
modules  are  useful  for  work  assignment  and  estimation  purposes.    Later  in  the  design  process,  other  design  
concepts  including  architectural  patterns,  tactics  and  frameworks  are  used  to  refine  the  initial  design  to  
support  the  quality  attributes  associated  to  the  system  under  development.  
 
When  designing  an  architecture  using  the  Attribute  Driven  Design  Method,  one  or  more  of  these  design  
concepts  must  be  selected  in  step  4  to  satisfy  the  architectural  drivers  or  architectural  issues  that  are  being  
addressed  in  a  particular  iteration:  
 

 
Architecture  Design  Concept  Catalog  V2.0  
4  
 
 
 

 
Figure.  Process  steps  for  Augmented  Attribute  Driven  Design  (ADD)  
 
The  selection  of  the  design  concepts  in  step  4  and  the  way  these  design  concepts  are  “instantiated”,  that  is  
adjusted  to  the  design  being  created,  are  design  decisions  that  need  to  be  recorded.  
 
 
The  design  concepts  that  are  presented  in  this  catalog  are  taken  from  various  sources  including:  
● Microsoft,  Application  Architecture  Guide,  2nd  Edition  -­  Octobre  2009  
● Bass,  L.,  Clements,  P.,  Kazman,  R.,  Software  Architecture  In  Practice,  3d  Edition,  2012  
● Buschmann,  F.,  Henney,  K.,  Schmidt,  D.  Pattern-­Oriented  Software  Architecture,  Volume  4,  Wiley,  
2007  

   

 
Architecture  Design  Concept  Catalog  V2.0  
5  
 
 
 

Reference  Architectures  
Reference  architectures  provide  a  blueprint  for  structuring  an  application.  This  section  is  a  summary  from  the  
Microsoft  Application  Architecture  Guide.  

Web  Applications  
 
A  Web  application  is  an  application  that  can  be  accessed  by  the  users  through  a  Web  browser  or  a  
specialized  user  agent.  The  browser  creates  HTTP  requests  for  specific  URLs  that  map  to  resources  on  a  
Web  server.  The  server  renders  and  returns  HTML  pages  to  the  client,  which  the  browser  can  display.  The  
core  of  a  Web  application  is  its  server-­side  logic.  The  application  can  contain  several  distinct  layers.  The  
typical  example  is  a  three-­layered  architecture  comprised  of  presentation,  business,  and  data  layers.  The  
Figure  illustrates  a  typical  Web  application  architecture  with  common  components  grouped  by  different  
areas  of  concern.  The  presentation  layer  usually  includes  UI  and  presentation  logic  components;;  the  
business  layer  usually  includes  business  logic,  business  workflow  and  business  entities  components,  and  
optionally  a  façade;;  and  the  data  layer  usually  includes  data  access  and  service  agent  components.  

 
Architecture  Design  Concept  Catalog  V2.0  
6  
 
 
 

 
 
Summary   Applications  of  this  type  typically  support  connected  scenarios  and  can  support  
different  browsers  running  on  a  range  of  operating  systems  and  platforms.  

Benefits   Broad  reach  and  a  standards-­based  UI  across  multiple  platforms.  


Ease  of  deployment  and  change  management.  

Considerations   Dependent  on  continual  network  connectivity.  


Difficult  to  provide  a  rich  user  interface.  
 
 

Rich  Client  Applications  


Rich  client  UIs  can  provide  high  performance,  interactive,  and  rich  user  experiences  for  applications  that  
must  operate  in  stand-­alone,  connected,  occasionally  connected,  and  disconnected  scenarios.  Windows  
Forms,  Windows  Presentation  Foundation  (WPF),  and  Microsoft  Office  Business  Application  (OBA)  
development  environments  and  tools  are  available  that  allow  developers  to  quickly  and  easily  build  rich  client  

 
Architecture  Design  Concept  Catalog  V2.0  
7  
 
 
 

applications.  
 
While  these  technologies  can  be  used  to  create  stand-­alone  applications,  they  can  also  be  used  to  create  
applications  that  run  on  the  client  machine  but  communicate  with  services  exposed  by  other  layers  (both  
logical  and  physical)  and  other  applications  that  expose  operations  the  client  requires.  These  operations  
may  include  data  access,  information  retrieval,  searching,  sending  information  to  other  systems,  back  up,  
and  related  activities.  Figure  shows  an  overall  view  of  typical  rich  client  architecture,  and  identifies  the  
components  usually  found  in  each  layer.  
 

 
A  typical  rich  client  application  is  decomposed  into  three  layers:  the  presentation  layer,  business  layer  and  
data  layer.  The  presentation  layer  usually  contains  UI  and  presentation  logic  components;;  the  business  
layer  usually  contains  business  logic,  business  workflow  and  business  entity  components;;  and  the  data  
layer  usually  contains  data  access  and  service  agent  components.    
 
Rich  client  applications  may  be  fairly  thin  applications  consisting  of  mainly  a  presentation  layer,  which  
access  a  remote  business  layer  hosted  on  server  machines  through  services.  An  example  of  this  is  a  data  
entry  application  that  sends  all  of  the  data  to  the  server  for  processing  and  storage.  
 
At  the  other  end  of  the  scale,  they  may  be  complex  applications  that  perform  most  of  the  processing  
themselves  and  only  communicate  with  other  services  and  data  stores  to  consume  or  send  back  
information.  An  example  of  this  is  an  application  such  as  Microsoft  Excel®  spreadsheet  software  that  

 
Architecture  Design  Concept  Catalog  V2.0  
8  
 
 
 

performs  complex  local  tasks,  stores  state  and  data  locally  and  only  communicates  with  remote  servers  to  
fetch  and  update  linked  data.  These  types  of  rich  clients  may  contain  their  own  business  layers  and  data  
access  layers.  The  guidelines  for  the  business  and  data  layers  in  such  applications  are  the  same  as  those  
discussed  generally  for  all  applications.  
 
Summary   Applications  of  this  type  are  usually  developed  as  stand-­alone  applications  with  a  
graphical  user  interface  that  displays  data  using  a  range  of  controls.  Rich  client  
applications  can  be  designed  for  disconnected  and  occasionally  connected  
scenarios  if  they  need  to  access  remote  data  or  functionality.  

Benefits   Ability  to  leverage  client  resources.  


Better  responsiveness,  rich  UI  functionality,  and  improved  user  experience.  
Highly  dynamic  and  responsive  interaction.  
Support  for  offline  and  occasionally  connected  scenarios.  
 

Considerations   Deployment  complexity;;  however,  a  range  of  installation  options  such  as  
ClickOnce,  Windows  Installer,  and  XCOPY  (.NET)  or  Java  Web  Start  are  
available.  
Challenging  to  version  over  time.  
Platform  specific.  
 
 
 
 

Rich  Internet  Applications  


RIAs  support  rich  graphics  and  streaming  media  scenarios,  while  providing  most  of  the  deployment  and  
maintainability  benefits  of  a  Web  application.  RIAs  may  run  inside  a  browser  plug-­in,  such  as  Microsoft®  
Silverlight®,  as  opposed  to  extensions  that  utilize  browser  code,  such  as  Asynchronous  JavaScript  and  
XML  (AJAX).  A  typical  RIA  implementation  utilizes  a  Web  infrastructure  combined  with  a  client-­side  
application  that  handles  the  presentation.  The  plug-­in  provides  library  routines  for  rich  graphics  support  as  
well  as  a  container  that  limits  access  to  local  resources  for  security  purposes.  RIAs  have  the  ability  to  run  
more  extensive  and  complex  client-­side  code  than  possible  in  a  normal  Web  application,  thus  providing  the  
opportunity  to  reduce  the  load  on  the  Web  server.  
 
 

 
Architecture  Design  Concept  Catalog  V2.0  
9  
 
 
 

 
 
A  typical  Rich  Internet  Application  is  decomposed  into  three  layers:  the  presentation  layer,  business  layer,  
and  data  layer.  The  presentation  layer  usually  contains  UI  and  presentation  logic  components;;  the  business  
layer  usually  contains  business  logic,  business  workflow  and  business  entities  components;;  the  data  layer  
usually  contains  data  access  and  service  agent  components.  It  is  common  in  RIAs  to  move  some  of  
business  processing  and  even  the  data  access  code  to  the  client.  Therefore,  the  client  may  in  fact  contain  
some  or  all  of  the  functionality  of  the  business  and  data  layers,  depending  on  the  application  scenario.  
 
RIAs  can  range  from  thin  interfaces  that  overlay  back  end  business  services,  to  complex  applications  that  
perform  most  of  the  processes  themselves  and  only  communicate  with  back  end  services  to  consume  or  
send  back  information.  Therefore,  the  design  and  implementation  varies.  However,  in  terms  of  the  
presentation  layer  and  the  way  that  it  communicates  with  back  end  services,  there  are  some  common  
approaches  to  good  architectural  design.  Most  of  these  are  based  on  well-­known  design  patterns  that  
encourage  the  use  of  separate  components  within  the  application  to  reduce  dependencies,  make  
maintenance  and  testing  easier,  and  promote  reusability.  
 
 

 
Architecture  Design  Concept  Catalog  V2.0  
10  
 
 
 

Summary   Applications  of  this  type  can  be  developed  to  support  multiple  platforms  and  
multiple  browsers,  displaying  rich  media  or  graphical  content.  Rich  Internet  
applications  run  in  a  browser  sandbox  that  restricts  access  to  some  features  of  
the  client.  

Benefits   The  same  rich  user  interface  capability  as  rich  clients.  
Support  for  rich  and  streaming  media  and  graphical  display.  
Simple  deployment  with  the  same  distribution  capabilities  (reach)  as  Web  clients.  
Simple  upgrade  and  version  updating.  
Cross-­platform  and  cross-­browser  support.  

Considerations   Larger  application  footprint  on  the  client  compared  to  a  Web  application.  
Restrictions  on  leveraging  client  resources  compared  to  a  rich  client  application.  
Requires  deployment  of  a  suitable  runtime  framework  on  the  client.  
 
 
 

Mobile  Applications  
A  mobile  application  will  normally  be  structured  as  a  multilayered  application  consisting  of  presentation,  
business,  and  data  layers.  When  developing  a  mobile  application,  you  may  choose  to  develop  a  thin  
Web-­based  client  or  a  rich  client.  If  you  are  building  a  rich  client,  the  business  and  data  services  layers  are  
likely  to  be  located  on  the  device  itself.  If  you  are  building  a  thin  client,  all  of  the  layers  will  be  located  on  the  
server.  Figure    illustrates  common  rich  client  mobile  application  architecture  with  components  grouped  by  
areas  of  concern.  

 
Architecture  Design  Concept  Catalog  V2.0  
11  
 
 
 

 
 
A  mobile  application  generally  contains  user  interface  components  in  the  presentation  layer,  and  perhaps  
may  include  presentation  logic  components.  The  business  layer,  if  it  exists,  will  usually  contain  business  
logic  components,  any  business  workflow  and  business  entity  components  that  are  required  by  the  
application,  and,  optionally,  a  façade.  The  data  layer  will  usually  include  data  access  and  service  agent  
components.  In  order  to  minimize  the  footprint  on  the  device,  mobile  applications  generally  use  less  rigid  
layering  approaches  and  fewer  discrete  components.  
 

Summary   Applications  of  this  type  can  be  developed  as  thin  client  or  rich  client  applications.  
Rich  client  mobile  applications  can  support  disconnected  or  occasionally  
connected  scenarios.  Web  or  thin  client  applications  support  connected  
scenarios  only.  Device  resources  may  prove  to  be  a  constraint  when  designing  
mobile  applications.  

Benefits   Support  for  handheld  devices.  


Availability  and  ease  of  use  for  out  of  office  users.  
Support  for  offline  and  occasionally-­connected  scenarios.  

 
Architecture  Design  Concept  Catalog  V2.0  
12  
 
 
 

Considerations   Input  and  navigation  limitations.  


Limited  screen  display  area.  
 
 

Service  Applications  
A  service  is  a  public  interface  that  provides  access  to  a  unit  of  functionality.  Services  literally  provide  some  
programmatic  service  to  the  caller,  who  consumes  the  service.  Services  are  loosely  coupled  and  can  be  
combined  within  a  client,  or  combined  within  other  services,  to  provide  functionality  that  is  more  complex.  
Services  are  distributable  and  can  be  accessed  from  a  remote  machine  as  well  as  from  the  machine  on  
which  they  are  running.  Services  are  message-­oriented,  meaning  that  service  interfaces  are  defined  by  a  
Web  Services  Description  Language  (WSDL)  file,  and  operations  are  called  using  Extensible  Markup  
Language  (XML)-­based  message  schemas  that  are  passed  over  a  transport  channel.  Services  support  a  
heterogeneous  environment  by  focusing  interoperability  at  the  message/interface  definition.  If  components  
can  understand  the  message  and  interface  definition,  they  can  use  the  service  regardless  of  their  base  
technology.    

 
 
A  typical  services  application  is  composed  of  three  layers:  the  service  layer,  business  layer,  and  data  layer.  
The  service  layer  may  include  service  interfaces,  message  types,  and  data  types  components;;  the  business  

 
Architecture  Design  Concept  Catalog  V2.0  
13  
 
 
 

layer  may  include  business  logic,  business  workflow,  and  business  entity  components;;  and  the  data  layer  
may  include  data  access  and  service  agent  components  
 
Summary   Services  expose  shared  business  functionality  and  allow  clients  to  access  them  
from  a  local  or  a  remote  system.  Service  operations  are  called  using  messages,  
based  on  XML  schemas,  passed  over  a  transport  channel.  The  goal  of  this  type  of  
application  is  to  achieve  loose  coupling  between  the  client  and  the  server.  

Benefits   Loosely  coupled  interactions  between  client  and  server.  


Can  be  consumed  by  different  and  unrelated  applications.  
Support  for  interoperability.  

Considerations   No  UI  support.  


Dependent  on  network  connectivity.  
 
 
 
 
 
   

 
Architecture  Design  Concept  Catalog  V2.0  
14  
 
 
 

Deployment  Patterns  
Deployment  patterns  provide  guidance  on  how  to  structure  the  system  from  a  physical  standpoint.  Good  
decision  with  respect  to  the  deployment  of  the  software  system  are  essential  to  achieve  quality  attributes.  
This  section  is  a  summary  from  the  Microsoft  Application  Architecture  Guide.  

Non-­distributed  Deployment  
In  a  non-­distributed  deployment,  all  of  the  functionality  and  layers  reside  on  a  single  server  except  for  data  
storage  functionality.    

 
 
This  approach  has  the  advantage  of  simplicity  and  minimizes  the  number  of  physical  servers  required.  It  also  
minimizes  the  performance  impact  inherent  when  communication  between  layers  must  cross  physical  
boundaries  between  servers  or  server  clusters.  Keep  in  mind  that  by  using  a  single  server,  even  though  you  
minimize  communication  performance  overhead,  you  can  hamper  performance  in  other  ways.  Because  all  of  
your  layers  share  resources,  one  layer  can  negatively  affect  all  of  the  other  layers  when  it  is  under  heavy  
utilization.  In  addition,  the  servers  must  be  generically  configured  and  designed  around  the  strictest  of  
operational  requirements,  and  must  support  the  peak  usage  of  the  largest  consumers  of  system  resources.  
The  use  of  a  single  tier  reduces  your  overall  scalability  and  maintainability  because  all  the  layers  share  the  
same  physical  hardware.  

Distributed  Deployment  
In  a  distributed  deployment,  the  layers  of  the  application  reside  on  separate  physical  tiers.  Tiered  
distribution  organizes  the  system  infrastructure  into  a  set  of  physical  tiers  to  provide  specific  server  
environments  optimized  for  specific  operational  requirements  and  system  resource  usage.  It  allows  you  to  
separate  the  layers  of  an  application  on  different  physical  tiers.  
 

 
 

 
Architecture  Design  Concept  Catalog  V2.0  
15  
 
 
 

 
A  distributed  approach  allows  you  to  configure  the  application  servers  that  host  the  various  layers  in  order  to  
best  meet  the  requirements  of  each  layer.  However,  because  the  primary  driver  for  optimizing  component  
deployment  is  to  match  a  component's  resource  consumption  profile  to  an  appropriate  server,  this  implies  
that  a  direct  mapping  of  layers  to  tiers  is  often  not  the  ideal  distribution  strategy.  
Multiple  tiers  enable  multiple  environments.  You  can  optimize  each  environment  for  a  specific  set  of  
operational  requirements  and  system  resource  usage.  You  can  then  deploy  components  onto  the  tier  that  
most  closely  matches  their  resource  needs  to  maximize  operational  performance  and  behavior.  The  more  
tiers  you  use,  the  more  deployment  options  you  have  for  each  component.  Distributed  deployment  provides  
a  more  flexible  environment  where  you  can  more  easily  scale  out  or  scale  up  each  physical  tier  as  
performance  limitations  arise,  and  when  processing  demands  increase.  However,  keep  in  mind  that  adding  
more  tiers  adds  complexity,  deployment  effort,  and  cost.  
Another  reason  for  adding  tiers  is  to  apply  specific  security  policies.  Distributed  deployment  allows  you  to  
apply  more  stringent  security  to  the  application  servers;;  for  example,  by  adding  a  firewall  between  the  Web  
server  and  the  application  servers,  and  by  using  different  authentication  and  authorization  options.  
 

Client-­server  deployment  
This  pattern  represents  a  basic  structure  with  two  main  components:  a  client  and  a  server.  In  this  scenario,  
the  client  and  server  will  usually  be  located  on  two  separate  tiers.  The  following  Figure  represents  a  common  
Web  application  scenario  where  the  client  interacts  with  a  Web  server.  Consider  the  client/server  pattern  if  
you  are  developing  a  client  that  will  access  an  application  server,  or  a  stand-­alone  client  that  will  access  a  
separate  database  server.  
 

 
 

2-­Tier  deployment  
Effectively  this  is  the  same  physical  layout  as  the  client/server  pattern.  It  differs  mainly  on  the  ways  that  the  
components  on  the  tiers  communicate.  In  some  cases,  as  shown  in  the  following  Figure,  all  of  the  
application  code  is  located  on  the  client,  and  the  database  is  located  on  a  separate  server.  The  client  
makes  use  of  stored  procedures  or  minimal  data  access  functionality  on  the  database  server.  Consider  the  
2-­tier  pattern  if  you  are  developing  a  client  that  will  access  an  application  server,  or  a  stand-­alone  client  that  
will  access  a  separate  database  server.  

 
Architecture  Design  Concept  Catalog  V2.0  
16  
 
 
 

 
 

3-­Tier  Deployment  
In  a  3-­tier  design,  the  client  interacts  with  application  software  deployed  on  a  separate  server,  and  the  
application  server  interacts  with  a  database  that  is  located  on  another  server,  as  shown  in  the  following  
Figure.  This  is  a  very  common  pattern  for  most  Web  applications  and  Web  services,  and  sufficient  for  most  
general  scenarios.  You  might  implement  a  firewall  between  the  client  and  the  Web/App  tier,  and  another  
firewall  between  the  Web/App  tier  and  the  database  tier.  Consider  the  3-­tier  pattern  if  you  are  developing  an  
Intranet-­based  application  where  all  servers  are  located  within  the  private  network  or  an  Internet  based  
application  and  security  requirements  do  not  prevent  you  from  implementing  business  logic  on  the  public  
facing  Web  or  application  server.  
 

 
 

4-­Tier  Deployment  
In  this  scenario,  shown  in  the  following  Figure,  the  Web  server  is  physically  separated  from  the  application  
server.  This  is  often  done  for  security  reasons,  where  the  Web  server  is  deployed  into  a  perimeter  network  
and  accesses  the  application  server  located  on  a  different  subnet.  In  this  scenario,  you  might  implement  a  
firewall  between  the  client  and  the  Web  tier,  and  another  firewall  between  the  Web  tier  and  the  application  or  
business  logic  tier.  Consider  the  4-­tier  pattern  if  security  requirements  dictate  that  business  logic  cannot  be  
deployed  to  the  perimeter  network,  or  you  have  application  code  that  makes  heavy  use  of  resources  on  the  
server  and  you  want  to  offload  that  functionality  to  another  server.  
 

 
Architecture  Design  Concept  Catalog  V2.0  
17  
 
 
 

Performance  Patterns:  Load-­balanced  cluster  


You  can  install  your  service  or  application  onto  multiple  servers  that  are  configured  to  share  the  workload.    

 
Load  balancing  scales  the  performance  of  server-­based  programs,  such  as  a  Web  server,  by  distributing  
client  requests  across  multiple  servers.  Load-­balancing  technologies,  commonly  referred  to  as  load  
balancers,  receive  incoming  requests  and  redirect  them  to  a  specific  host  if  necessary.  The  load-­balanced  
hosts  concurrently  respond  to  different  client  requests,  even  multiple  requests  from  the  same  client.  For  
example,  a  Web  browser  might  obtain  the  multiple  images  within  a  single  Web  page  from  different  hosts  in  
the  cluster.  This  distributes  the  load,  speeds  up  processing,  and  reduces  the  response  time.  
 

Reliability  Patterns:  Failover  Cluster  


A  failover  cluster  is  a  set  of  servers  that  are  configured  in  such  a  way  that  if  one  server  becomes  unavailable,  
another  server  automatically  takes  over  for  the  failed  server  and  continues  processing.    
 

 
Architecture  Design  Concept  Catalog  V2.0  
18  
 
 
 

 
 
   
Install  your  application  or  service  on  multiple  servers  that  are  configured  to  take  over  for  one  another  when  a  
failure  occurs.  The  process  of  one  server  taking  over  for  a  failed  server  is  commonly  known  as  failover.  Each  
server  in  the  cluster  has  at  least  one  other  server  in  the  cluster  identified  as  its  standby  server.  

Security  Patterns  

Impersonation  /  Delegation  
The  impersonation/delegation  approach  is  a  good  solution  when  you  must  flow  the  context  of  the  original  
caller  to  downstream  layers  or  components  in  your  application.  

 
Architecture  Design  Concept  Catalog  V2.0  
19  
 
 
 

 
In  the  impersonation/delegation  authorization  model,  resources  and  the  types  of  operations  (such  as  read,  
write,  and  delete)  permitted  for  each  one  are  secured  using  Access  Control  Lists  (ACLs)  or  the  equivalent  
security  features  of  the  targeted  resource  (such  as  tables  and  procedures  in  SQL  Server).  Users  access  the  
resources  using  their  original  identity  through  impersonation.  

Trusted  subsystem  
In  the  trusted  subsystem  (or  trusted  server)  model,  users  are  partitioned  into  application  defined,  logical  
roles.  Members  of  a  particular  role  share  the  same  privileges  within  the  application.  Access  to  operations  
(typically  expressed  by  method  calls)  is  authorized  based  on  the  role  membership  of  the  caller.  With  this  
role-­based  (or  operations-­based)  approach  to  security,  access  to  operations  (not  networked  resources)  is  
authorized  based  on  the  role  membership  of  the  caller.  Roles,  analyzed  and  defined  at  application  design  
time,  are  used  as  logical  containers  that  group  together  users  who  share  the  same  security  privileges  or  
capabilities  within  the  application.  The  middle-­tier  service  uses  a  fixed  identity  to  access  downstream  
services  and  resources.  

 
Architecture  Design  Concept  Catalog  V2.0  
20  
 
 
 

Multiple  Trusted  Service  Identities  


In  some  situations,  you  might  require  more  than  one  trusted  identity.  For  example,  you  might  have  two  
groups  of  users,  one  who  should  be  authorized  to  perform  read/write  operations  and  the  other  read-­only  
operations.  The  use  of  multiple  trusted  service  identities  provides  the  ability  to  exert  more  granular  control  
over  resource  access  and  auditing,  without  having  a  large  impact  on  scalability.  

 
 

Scalability  Patterns  
Your  approach  to  scaling  is  a  critical  design  consideration.  Whether  you  plan  to  scale  out  your  solution  
through  a  load-­balanced  cluster  or  a  partitioned  database,  you  must  ensure  that  your  design  supports  the  
option  you  choose.  In  general  cases,  when  you  scale  your  application,  you  can  choose  from  and  combine  
two  basic  choices:  scale  up  (get  a  bigger  box)  and  scale  out  (get  more  boxes).  
 
With  the  scale  up  approach,  you  add  hardware  such  as  processors,  RAM,  and  network  interface  cards  
(NICs)  to  your  existing  servers  to  support  increased  capacity.  This  is  a  simple  option  and  can  be  
cost-­effective  up  to  a  certain  level  because  it  does  not  introduce  additional  maintenance  and  support  costs.  
However,  any  single  points  of  failure  remain,  which  is  a  risk.  In  addition,  beyond  a  certain  threshold,  adding  
more  hardware  to  the  existing  servers  may  not  produce  the  desired  results,  and  getting  the  last  10%  of  
theoretical  performance  from  a  single  machine  though  upgrades  can  be  very  expensive.  
 
For  an  application  to  scale  up  effectively,  the  underlying  framework,  runtime,  and  computer  architecture  
must  scale  up  as  well.  When  scaling  up,  consider  which  resources  are  limiting  application  performance.  For  
example,  if  it  is  memory  bound  or  network  bound,  adding  CPU  resources  will  not  help.  
 
With  the  scale  out  approach,  you  add  more  servers  and  use  load  balancing  and  clustering  solutions.  In  
addition  to  handling  additional  load,  the  scale  out  scenario  also  mitigates  hardware  failures.  If  one  server  

 
Architecture  Design  Concept  Catalog  V2.0  
21  
 
 
 

fails,  there  are  additional  servers  in  the  cluster  that  can  take  over  the  load.  For  example,  you  might  have  
multiple  load-­balanced  Web  servers  in  a  Web  farm  that  host  the  presentation  and  business  layers.  
Alternatively,  you  might  physically  partition  your  application’s  business  logic,  and  use  a  separate  
load-­balanced  middle  tier  for  that  logic  while  hosting  the  presentation  layer  on  a  load-­balanced  front  tier.  If  
your  application  is  I/O  constrained  and  you  must  support  an  extremely  large  database,  you  might  partition  
your  database  across  multiple  database  servers.  In  general,  the  ability  of  an  application  to  scale  out  
depends  more  on  its  architecture  than  on  the  underlying  infrastructure.  
 
 

 
 

   

 
Architecture  Design  Concept  Catalog  V2.0  
22