architectural patterns aima 2 may16

8/16/2019 Architectural Patterns Aima 2 May16

1/59


2/59

Three-tier Architecture


3/59

• Comparison to MVC (Model View

Control) – Not a triangle, but linear.

• Uses – eb applications.

• Ad!antages – Modular

– "nterdependent o# other components(reduce coupling)

– $as great control o# permissions.


4/59

"nterpreter

%o#tware ArchitectureVladimir %oto

Veronica Valen&uela


5/59

hat is it'

• i!en a language, dene arepresentation #or its grammar alongwith an interpreter that uses therepresentation to interpret sentencesin the language.

• Map a domain to a language, the

language to a grammar, and thegrammar to a hierarchical ob*ect-oriented design.


6/59

hat does it sol!e'

• A class o# problems occursrepeatedl+ in a well-dened and well-understood domain. "# the domainwere characteri&ed with alanguage, then problems could beeasil+ sol!ed with an interpretation

engine.


7/59

ample


8/59

Conclusion

• This pattern can be applied #or parsinglight epressions dened in simplegrammars and sometimes in simple rule

engines.• The "nterpreter pattern has a limited areawhere it can be applied.

• e can discuss the "nterpreter pattern

onl+ in terms o# #ormal grammars but inthis area there are better solutions andthis is the reason wh+ this pattern is not so#re/uentl+ used.


9/59

0e#erences

• http122www.!incehuston.org2dp2interpreter.html

• http122sourcema3ing.com2design4patterns2interpreter

• http122www.oodesign.com2interpreter-pattern.html

http://www.vincehuston.org/dp/interpreter.htmlhttp://www.vincehuston.org/dp/interpreter.htmlhttp://sourcemaking.com/design_patterns/interpreterhttp://sourcemaking.com/design_patterns/interpreterhttp://www.oodesign.com/interpreter-pattern.htmlhttp://www.oodesign.com/interpreter-pattern.htmlhttp://www.oodesign.com/interpreter-pattern.htmlhttp://www.oodesign.com/interpreter-pattern.htmlhttp://sourcemaking.com/design_patterns/interpreterhttp://sourcemaking.com/design_patterns/interpreterhttp://www.vincehuston.org/dp/interpreter.htmlhttp://www.vincehuston.org/dp/interpreter.html


10/59

5+ 0ic3 6awler 7 0a+ 8ia&

Client-%er!er Model


11/59

hat is a client'

• An+ computer or program thatma3es a re/uest to a ser!er


12/59

hat is a ser!er'

• An+ computer or program thatprocesses the re/uests o# multiplecomputers or programs (clients).

• T+picall+, the ser!er is alwa+s on andwaits #or client re/uests


13/59

hat is the client ser!ermodel'

Client %er!ermodel is therelationshipbetween the clientand the ser!er.


14/59

amples o# client-ser!er

• 9nline aming

• %urng the internet


15/59

9nline gaming

• ame console (client)

• Central %er!er


16/59

"nternet browsing

• Machine 2browser (client)

• Machine hosting the site (ser!er)


17/59

8istributed Architecture

• 9rti&

• Montgomer+


18/59

8"%T0"5UT8 C9M:UT"N-$ardware and so#tware s+stemscontaining more than one processingelement or storage element, concurrent

processes, or multiple programs, runningunder a loosel+ or tightl+ controlledregime.

- A #orm o# parallel computing- 8istributed programs o#ten must deal withheterogeneous en!ironments, networ3 lin3so# !ar+ing latencies, and unpredictable#ailures in the networ3 or the computers.


19/59

8istributed programming t+picall+ #allsinto one o# se!eral basic architectures orcategories1

8"%T0"5UT8 C9M:UT"N

- Client-server

-

3-tier architecture- N-tier architecture

- Tight coupling


20/59


8"%T0"5UT8 C9M:UT"N

- Client-server

•

Contacts the server for data, then formats anddisplays it to the user. Input at the client is

committed bac to the server !hen it represents a

permanent change.

-


- Tight coupling


21/59


8"%T0"5UT8 C9M:UT"N

- Client-server

-

3-tier architecture• "ove the client intelligence to a middle tier so that

stateless clients can be used.

- N-tier architecture

- Tight coupling


22/59


8"%T0"5UT8 C9M:UT"N

- Client-server

-


• #eb applications !hich further for!ard their

re$uests to other enterprise services

- Tight coupling


23/59


8"%T0"5UT8 C9M:UT"N

- Client-server

-


- Tight Coupling

•

% cluster of machines that closely !or together,running a shared process in parallel.


24/59

5atch-%e/uential %o#tware

Architecture

8a!id Mireles;ris Villanue!a


25/59

• Used #or o


26/59

5atch %e/uentialArchitectures

• Are a sub-set o# 8ata =lowArchitectures – :ipes and lters eecutes in parallel

– 5atch se/uential does not

• amples1 – 6egac+ main#rame s+stems

– Compilers – Compression


27/59

hen to use 5% Architecture

• All data is alread+ gi!en.

• :rocesses can be completel+modulari&ed.

• There are no bac3ward dependenciesbetween processes.

• :ipelining the main processes isunnecessar+, impossible, orundesireable.


28/59

5lac3board

• 8a!id ome&-6eon9scar A. 9li!as


29/59

5lac3board

• This architecture is composed o#3nowledge sources (;%s) and a singleblac3board – ;%s are programs that create, modi#+, or

remo!e messages #rom the blac3board.

– The blac3board is a single repositor+ o#

messages and is the onl+ mean o#communication between ;%s.

• "n general, a message ma+ representan+ #orm o# input2output between the;%s.


30/59

5lac3board

• :ros – ;%s are completel+ independent #rom

each other and thus are eas+ to

maintain. – The most optimal ;% can be selected #or

an+ specic message.

• Cons – Compleit+ in!ol!ed with

communication within the blac3board

– Compleit+ in!ol!ed with which ;% toselect.


31/59

8abase-centric

• 8el $o+o

• Cha!e&


32/59

Database-centricArchitecture8atabase-centric is anarchitecture in which databasespla+ a crucial role


33/59

Characteristics:

Could be a combination o#1

• Use relational 85M s+stem

• Using d+namic table dri!en logic• Using stored procedures that run on

database ser!ers

• using a shared database as the basis#or communicating between parallelprocesses in distributed computingapplications


34/59

Characteristics:

• 8istribution1 8atabase 7 U" :ortions

• :rotocol needed

• All interaction is accomplished

through database !iews or A:"s.

• Nearl+ all application beha!ior

(including screen na!igation) is


35/59

Benefts

• 0educed the total amount o#code

• 0educed de!elopment time• "mpro!ed per#ormance

• 0educed networ3 tra?c• 0educed the compleit+ o#the application


36/59

:@:

• %aucedo


37/59

&$ual nodes that act as clients and servers at

the same time.

'ometimes there can e(ist a central server

!hich assists in the communication bet!eenpeers.

)*) uses connectivity to bet!een many

computers in a net!or and the collective

band!idth of all partaers rather than a central

resource such as a server.

%n important goal in )*) net!ors is that all

clients provide resources, including

band!idth, storage space, and computing

po!er.

"any )*) systems use stronger peers +super-peers, super-nodes as servers and client-

peers are connected in a star-lie fashion to a

single super-peer.


38/59

PLUG-IN

ARCHITECTUREValeria =ierroNeith strada


39/59


40/59

PLUG-IN ARCHITECTURE

• Use#ul when +ou are designingetensible so#tware.

=or eample, Notepad has a plug-in architecture where +ou place a .dllle in the plugins #older, and it adds#unctionalit+ to the application that

wasnDt there, such as color-pic3ing, orsnippet insertion, or man+ otherthings (a wide range o# #unctionalit+).

clipse :lug-in Architecture


41/59


42/59

%earch 9riented %o#twareArchitecture

• %earch engine is the main integrationcomponent o# the architectural la+er – As opposed to the traditional relational

database management s+stem – ;e+board search instead o# %G6 /ueries


43/59

• 5enet1 rapid response time andmore con!enient, in terms as %G6!ersus 3e+board search

• 8rawbac31 The data tier is not asorgani&ed

%earch 9riented %o#twareArchitecture


44/59

%er!ice 9riented

• Carmen AvilaLeonel Villagomez Cesar Yeep


45/59

Service-riente!

Architectureroup o# ser!ices thatcommunicate with each

other.


46/59

• "s a design #or lin3ing computationalresources (principall+ applicationsand data) on demand to achie!e thedesired results #or ser!ice consumers(either end users or other ser!ices).

Service-"riente! Architecture#S"A$


47/59

• The process o# communicationin!ol!es either simple data-passingor two or more ser!ices coordinating

some acti!it+.

• "ntercommunication implies the need

#or some means o# connecting two ormore ser!ices to each other.


48/59

A service1• "s a logical representation o# a

repeatable business acti!it+ thathas a specied outcome (e.g.,pro!ide weather data)

• "s sel#-contained• May be composed o# other ser!ices• "s a Hblac3 boI to consumers o# the

ser!ice

S"A is an architectural st+le thatsupports ser!ice orientation.

Service rientatin is a wa+ o#thin3ing in terms o# ser!ices and

ser!ice-based de!elopment and theoutcomes o# ser!ices.


49/59

• To associates indi!idual %9A ob*ectsorchestration is used.

•"rchestratin is the abilit+ tocontrol how in#ormation Jows andser!ices (beha!iors) interact to #ormsolutions.


50/59

• %9A promotes the goal o# separatingusers (consumers) #rom the ser!iceimplementations. %er!ices can

there#ore be run on !ariousdistributed plat#orms and beaccessed across networ3s. This can

also maimi&e reuse o# ser!ices

Benefts


51/59

Princi%&es ' (! service !esi(nthat are enab&e! b) S"A

Reusable Use o# %er!ice, not reuse b+ cop+ing o#code2implementation.

Abstracted %er!ice is abstracted #rom the implementation.

Published :recise, published specication #unctionalit+ o# ser!iceinter#ace, not implementation.

Formal=ormal contract between endpoints places obligations onpro!ider and consumer.

Relevant =unctionalit+ presented at a granularit+ recogni&ed b+ theuser as a meaning#ul ser!ice.


52/59

%hared Nothing

• Koshua Martine&Antonio ar&a


53/59

%hared Nothing

Architecture"n#o #rom1

i3ipedia.org

HThe Case #or %hared NothingI b+ MichaelStonebraer !niversity o" Cali"ornia


54/59

%hared Nothing

• hat1 – is a distributed computing architecture

in which each node is independent and

sel#-su?cient, and there is no singlepoint o# contention across the s+stem.

• Use#ul'

– Mostl+ used in web de!elopmentbecause o# its scalabilit+, s+stem can3eep growing *ust b+ adding nodes.


55/59

%hared Nothing

• Additional :roperties – ach node has its own pri!ate memor+,

dis3s and input2output de!ices.

– A %N s+stem ma+ assign applicationsand partition data among nodes, witheach node ha!ing responsibilit+ #or aparticular tas3.

• 8rawbac3 – Maintenance and tuning becomes reall+

hard.


56/59

%hared Nothing

• amples1 – :rocessors not sharing neither

peripherals nor memor+.

– hierarchical s+stems – 0"8 s+stems.


57/59

%pace-based

• %te!en arciaAurthor alton


58/59

%pace 5ased Architecture

Applications consisto# sel#-su?cientprocessing-units.


59/59

%pace 5ased Architecture

architectural patterns aima 2 may16

Documents