Engenharia de Software - Arquitetura de Sistemas Distribuídos

Prévia do material em texto

Arquitetura de Sistemas 
Distribuídos
Idarlan Machado
Prof. Vander Alves
Supervisor
 
Introdução
Atualmente, virtualmente, os grandes sistemas 
baseados em computadores são sistemas 
distribuídos
“... uma coleção de computadores 
independentes que aparecem para o usuário 
como um único sistema coerente”
 
Características
● Compartilhamento de recursos - hardware e 
software
● Abertura – permite diferentes fornecedores
● Concorrência – processamento concorrente 
para melhorar desempenho
● Escalabilidade – Aumentar capacidade do 
sistema pela adição de mais recursos
● Tolerância a defeitos – habilidade de continuar 
operando após ocorrência de defeitos 
 
Questões de Sistemas Distribuídos
● Mais complexos do que sistemas rodando em 
único processador
● Complexidade aumenta por causa de 
diferentes partes do sistema são gerenciadas 
independemente
● Não há um único responsável pelo sistema, por 
isso, gerenciamento de cima-para-baixo é 
impossível
 
Questões Arquiteturais
● Transparência – Para qual extensão o sistema distribuído deve 
aparecer para o usuário como um único sistema?
● Abertura – O sistema deve ser implementado para utilizar protocolos-
padrão que suportam interoperabilidade?
● Escalabilidade – Como o sistema deve ser construído para ser 
escalável?
● Segurança – Como políticas de segurança disponíveis podem ser 
definidas e implementadas?
● Qualidade do serviço – Como a qualidade do serviço pode ser 
especificada?
● Gerenciamento de falha – Como as falhas do sistema podem ser 
detectadas e reparadas?
 
Formas de Interação
● Procedural – um computador solicita um 
serviço conhecido provido por outro 
computador e espera até que ele responda 
● Por meio de mensagens – um computador 
envia uma informações sobre o que é solicitado 
ao outro computador. Não há necessidade de 
esperar.
Procedural interaction between a diner and a waiter 
Message-based interaction between a waiter and the kitchen 
<starter><dish name = “soup” type = “tomato” /> <dish name = “soup” type = “fish” /><dish name = “pigeon salad” /></starter><main course><dish name = “steak” type = “sirloin” cooking = “medium” /><dish name = “steak” type = “fillet” cooking = “rare” /><dish name = “sea bass”></main><accompaniment><dish name = “french fries” portions = “2” /><dish name = “salad” portions = “1” /></accompaniment>
Middleware
Camada de aplicações que permite a 
comunicação entre processos (procedurais 
ou mensagens) implementados em diferentes 
linguagens, estrutura de dados e protocolos 
de comunicação
Sua missão é gerenciar esses diferentes 
componentes envolvidos e garantir que eles 
possam se comunicar e trocar dados
Middleware in a distributed system 
Client–server interaction 
Mapping of clients and servers to networked computers 
Layered architectural model for client–server application 
A traffic management system with a master-slave architecture 
Thin- and fat-client architectural models 
A fat-client architecture for an ATM system 
Three-tier architecture for an Internet banking system 
Use of client–server architectural patterns 
Architecture Applications
 Two-tier client–server architecture 
with thin clients
Legacy system applications that are used when separating application 
processing and data management is impractical. Clients may access 
these as services, as discussed in Section 18.4.
Computationally intensive applications such as compilers with little or no 
data management.
Data-intensive applications (browsing and querying) with nonintensive 
application processing. Browsing the Web is the most common example 
of a situation where this architecture is used.
Two-tier client-server architecture 
with fat clients
Applications where application processing is provided by off-the-shelf 
software (e.g., Microsoft Excel) on the client.
Applications where computationally intensive processing of data (e.g., 
data visualization) is required.
Mobile applications where internet connectivity cannot be guaranteed. 
Some local processing using cached information from the database is 
therefore possible.
Multi-tier client–server architecture Large-scale applications with hundreds or thousands of clients.
Applications where both the data and the application are volatile. 
Applications where data from multiple sources are integrated.
A distributed component architecture 
A distributed component architecture for a data mining system 
A decentralized p2p architecture 
A semicentralized p2p architecture 
Configuration of a software system offered as a service 
A multitenant database 
	Slide 1
	Slide 2
	Slide 3
	Slide 4
	Slide 5
	Slide 6
	Slide 7
	Slide 8
	Slide 9
	Figure 18.3 Middleware in a distributed system
	Figure 18.4 Client–server interaction
	Slide 12
	Slide 13
	Slide 14
	Figure 18.8 Thin- and fat-client architectural models
	Figure 18.9 A fat-client architecture for an ATM system
	Slide 17
	Figure 18.11 Use of client–server architectural patterns
	Figure 18.12 A distributed component architecture
	Slide 20
	Figure 18.14 A decentralized p2p architecture
	Figure 18.15 A semicentralized p2p architecture
	Slide 23
	Figure 18.17 A multitenant database