Aula 02

• Arquiteturas
– Introdução
– Estilos Arquitetônicos
– Arquiteturas de Sistemas
 Introdução
• SDs são complexas peças de software cujos componentes estão
espalhados por várias máquinas.

• Arquitetura de software nos diz como vários componentes de

software devem ser organizados e como devem interagir.

• A especificação final de uma arquitetura de software é

denominada arquitetura de sistema.
 Introdução
• Arquiteturas Centralizadas Tradicionais
– Há um único servidor que implementa a maioria dos
componentes de software, enquanto clientes remotos o
acessam usando comunicação simples.

• Arquiteturas Descentralizadas
– Máquinas desempenham papéis mais ou menos iguais.

• Arquiteturas Híbridas
 Introdução
• Meta importante dos SDs
– Separar aplicações das plataformas subjacentes provendo uma
camada de Middleware.

• Middleware
– Adotar tal camada é uma decisão arquitetônica importante;
– A principal finalidade e proporcionar transparência de
distribuição para o cliente;
 Estilos Arquitetônicos
• Componente é uma unidade modular com interfaces requeridas
e fornecidas bem definidas que é substituível dentro de seu
ambiente.
• Estilo Arquitetônico é formulado em termos de componentes:
– do modo como esses componentes estão conectados uns aos outros;
– dos dados trocados entre componentes;
– da maneira como esses elementos são configurados em conjunto para
formar um sistema.
• Conector é um mecanismo mediador da comunicação ou da
cooperação entre componentes.
– RPC, Passagem de Mensagens, etc.
 Estilos Arquitetônicos
• Usando componentes e conectores, podemos chegar a várias
configurações, que foram classificadas em estilos arquitetônicos.
– Arquitetura em camadas
– Arquitetura baseada em objetos
– Arquitetura centrada em dados
– Arquitetura baseada em eventos
 Estilos Arquitetônicos
Arquitetura em camadas
– Componentes organizados em camadas
– Modelo amplamente adotado pela comunidade de redes
– O controle flui de camada para camada

• As requisições descem pela hierarquia

• Os resultados fluem para cima

 Estilos Arquitetônicos
Arquitetura em camadas
 Estilos Arquitetônicos
Arquiteturas baseadas em objetos
– Nessa arquitetura, cada objeto corresponde ao que definimos
como componente, e esses componentes são conectados por
meio de uma chamada de procedimento (remota).

– Podem formar os estilos mais importantes para sistemas de

softwares de grande porte.
 Estilos Arquitetônicos
Arquiteturas centradas em dados
– Se desenvolvem em torno da ideia de que processos se
comunicam por meio de um repositório comum.

– Processos se comunicação por meio da utilização de serviços

de dados baseados na Web.
 Estilos Arquitetônicos
• Arquiteturas centradas em dados
 Estilos Arquitetônicos
Arquiteturas baseadas em eventos
– Processos se comunicam por meio de propagação de eventos

• Opcionalmente podem transportar dados;

– Sistemas Publicar/Subscrever;

• Processos publicam eventos, e o middleware repassa-os somente

para os processos que subscreveram esses eventos.
 Estilos Arquitetônicos
Arquiteturas baseadas em eventos
 Estilos Arquitetônicos
• Estilos podem ser híbridos, como arquiteturas baseadas em
eventos juntamente com arquiteturas centradas em dados

• O que torna essas arquiteturas de software importante para

sistemas distribuídos é que todas elas visam obter transparência
de distribuição
 Arquiteturas de Sistemas
Arquiteturas Centralizadas

• Modelo Cliente-Servidor
– Pensar em termos de cliente que requisitam serviços de
servidores nos ajudam a entender e gerenciar a complexidade
dos SDs.
– Processos são divididos em 2 grupos
 Arquiteturas de Sistemas
• Modelo Cliente-Servidor
– Processo Servidor
• Implementa o um serviço específico.
• Ex: Serviço de Sistema de Arquivos, Serviço de BD.

– Processo Cliente
• Requisita um serviço de um servidor
• Envia um requisição e espera uma resposta.
 Arquiteturas de Sistemas
• Modelo Cliente-Servidor
 Arquiteturas de Sistemas
Modelo Cliente-Servidor
– Orientado ou não-orientado a conexão (TCP ou UDP)?

• Protocolos sem conexão são mais eficientes.

• Protocolos com conexão são mais seguros contra falhas.

– Reenvio de requisições há outras implicações além do tempo?
– O que falhou? A requisição ou resposta?
 Arquiteturas de Sistemas
Modelo Cliente-Servidor

• Não orientado a conexão (UDP)

– Rede subjacente razoavelmente confiável, como em redes
locais

• Orientado a conexão (TCP)

– Desempenho lento.
– Solução indicada em sistemas de longa distância, onde a
comunicação é inerentemente não confiável.
 Arquiteturas de Sistemas
Modelo Cliente-Servidor
• O que é realmente um cliente e um servidor?
– Ex: Um servidor de BD Distribuído pode agir como cliente
porque está repassando requisições para diferentes servidores
de arquivos.

• Considerando que muitas aplicações cliente-servidor, visam dar

suporte ao acesso do usuário a banco de dados, criou-se o
seguinte estilo arquitetônico em 3 camadas.
 Arquiteturas Centralizadas
Camadas de Aplicação
• Divididas em 3 níveis:
1. Nível de interface de usuário
– Contém tudo o que é necessário para fazer interface com o
usuário
2. Nível de processamento
– Contém as aplicações
3. Nível de dados
– Gerencia os dados propriamente ditos
 Organização em 3 Camadas de Aplicação
• Um mecanismo de busca da Internet
 Questão 2
• O que é uma arquitetura cliente-servidor de três níveis?
 Resposta Questão 2
• Uma arquitetura cliente-servidor de três níveis é constituída
por três camadas lógicas, onde cada camada é, em
princípio, implementada em uma máquina separada. A
camada superior consiste de uma interface de utilização do
cliente, a camada do meio contém a aplicação real (regras
de negócio) e, a camada inferior implementa os dados que
estão sendo utilizados.
 Arquiteturas Centralizadas
Arquiteturas multidivididas
• Com base na organização de três níveis lógicos apresentadas
anteriormente, é necessária a distribuição física.

• A maneira mais simples, denominada arquitetura de duas

divisões (físicas) é distribuída da seguinte forma:
– Parte lógica do lado cliente
– Parte lógica do lado servidor
 Arquiteturas Centralizadas
Arquiteturas multidivididas
• Alternativas de distribuição
 Arquiteturas Centralizadas
Arquiteturas multidivididas
Divisão da Interface do Usuário
• Ter na máquina do cliente somente a interface
do usuário que é dependente do dispositivo.

• As aplicações tem controle remoto sobre a

apresentação dos seus dados.
– Sistemas de adaptação de conteúdo
baseados em contexto
 Arquiteturas Centralizadas
Arquiteturas multidivididas
Divisão da Extremidade Frontal Gráfica
• Uma máquina cliente que contém apenas
os programas que implementam o nível
(ou parte do nível) de interface de usuário.

• Uma máquina do servidor que contém

todo o resto, ou seja, os níveis de
processamento e de dados.
 Arquiteturas Centralizadas
Arquiteturas multidivididas
Divisão da Aplicação
• Há parte do processamento no cliente

• Ex: A verificação da consistência e correção

dos dados preenchidos são verificados no
cliente, antes de serem processado .
 Arquiteturas Centralizadas
Arquiteturas multidivididas
Divisão da Extremidade da Aplicação
• Quando grande parte da aplicação executa na
máquina cliente, mas todas as operações com
arquivos e entradas em banco de dados vão
para o servidor.
 Arquiteturas Centralizadas
Arquiteturas multidivididas
Divisão do Banco de Dados
• Situação em que o disco local do cliente
contém parte dos dados.

• Ao consultar páginas web por exemplo, o

cliente pode gradativamente construir uma
enorme cache em disco local com páginas web
mais recentemente consultadas.
 Perspectiva do Gerenciamento de Sistemas
• Clientes gordos (fat clients)
– Imagens (d) e (e)
– Não é ótimo, pois máquinas clientes são difíceis de gerenciar
– Máquinas clientes são mais problemáticas.
– Torna o software mais propenso a erros.
– Mais dependente da plataforma subjacente.

• Clientes magros (thin clients)

– De imagens (a) a (c) são mais fáceis de gerenciar.
 Arquiteturas Centralizadas
Arquiteturas multidivididas
• Arquitetura de três divisões (físicas)
– Servidor as vezes pode agir como cliente.
 Arquitetura de sistemas
• A arquitetura de um sistema representa a estrutura desse sistema
com relação aos seus diferentes componentes

• O objetivo é garantir que a estrutura atenda às demandas atuais e

futuras

• Se preocupando em manter o sistema: confiável, gerenciável,

adaptável e rentável
 Modelos de arquitetura de sistemas
distribuídos
• Inicialmente: simplifica e abstrai as funções dos componentes
individuais de um sistema

• Em seguida, considera:
– O posicionamento dos componentes em uma rede

• Visando a distribuição de dados e carga

– Os inter-relacionamentos entre os componentes

• Seus papéis funcionais e padrões de comunicação

 Arquitetura de sistemas distribuídos
• Aspectos de projeto importantes:
– Divisão de responsabilidades entre os componentes de um
sistema
– Alocação dos componentes nos diversos computadores de
uma rede

• Implicações importantes:
– Desempenho
– Confiabilidade
– Segurança
 Arquitetura: cliente-servidor
• Clientes requisitam serviço de um servidor
• Exemplos: bancos de dados clássicos, NFS, ...
 Requisitos de projeto para arquiteturas
distribuídas
• Desempenho
– Reatividade
– Vazão (throughput)
– Balanceamento de carga
• Qualidade de serviço (QoS)
– Confiabilidade
– Segurança
– Desempenho
– Adaptabilidade
– Disponibilidade
 Requisitos de projeto para arquiteturas
distribuídas
• Uso de cache e replicação

• Dependabilidade
– Corretude
– Tolerância a falhas
– Segurança
 Modelos Fundamentais de Sistemas
Distribuídos
• Um modelo contém apenas o essencial para que possamos
entender e raciocinar a respeito de aspectos do comportamento
de um sistema

• Questões importantes na modelagem:

– Quais são as principais entidades do sistema?
– Como elas interagem?
– Quais são as características que afetam seu comportamento
individual e coletivo?
 Modelos Fundamentais de Sistemas
Distribuídos
• Objetivos
– Tornar explícitas todas as suposições relevantes sobre os
sistemas que estamos modelando
– Fazer generalizações a respeito do que é possível ou
impossível, dadas essas suposições
 Modelos fundamentais: Aspectos
considerados
• Interação: deve refletir o fato de que a comunicação ocorre com
atrasos, que, frequentemente, têm duração considerável

• Falha: define e classifica as formas pelas quais o sistema pode

falhar

• Segurança: define e classifica as formas de ataque que podem

comprometer o sistema
 Modelo de interação
• Sistemas distribuídos são compostos por vários processos que
interagem entre si.

• Exemplos:
– Vários processos servidores podem cooperar entre si para
fornecer um serviço
– Um conjunto de processos peer-to-peer pode cooperar entre
si para atingir um objetivo comum
 Fatores que afetam a interação
• Desempenho dos canais de comunicação
– Latência: tempo entre o início da transmissão de uma
mensagem do processo de origem até o início da recepção
pelo processo de destino
– Largura de banda: volume total de dados que podem ser
transmitidos em um certo tempo
– Jitter: variação no tempo de transmissão de uma série de
mensagens
 Fatores que afetam a interação
• Relógios e temporização de eventos
– Cada computador possui seu próprio relógio
– Processos em máquinas diferentes podem associar tempos
diferentes aos seus eventos, mesmo lendo seus relógios ao
mesmo tempo
– drift ou taxa de desvio do tempo real faz os relógios
divergirem
– Como saber qual evento aconteceu primeiro em um sistema
distribuído?
 Modelo de falhas
• Em um sistema distribuído, tanto os processos como os canais
de comunicação podem falhar
– Falha: sair do comportamento esperado

• Tipos de falha:
– Omissão
– Tempo
– Arbitrária
 Falhas por omissão
• Em processos:
– Crash: parar para sempre, outros não notam
– Fail-stop: parar para sempre, perceptível
• Exemplo: timeout em sistema

• Em canais de comunicação:
– Mensagem enviada não chega ao destino
• Exemplo: drop no roteador

• Ambas são consideradas falhas “benignas” e são as mais

frequentes
 Falhas arbitrárias (ou Bizantinas)
• Qualquer tipo de erro pode ocorrer
– Ex: processos respondem com valores incorretos

• Em processos:
– Processo omite passos esperados do processamento ou
realiza passos indesejados

• Em canais de comunicação:
– Mensagens corrompidas, envio de mensagens inexistentes,
vários envios da mesma mensagem
 Falhas de tempo
• Acontecem quando limites de tempo são desrespeitados em
sistemas síncronos
– Falha de relógio: o relógio local do processo ultrapassa os
limites de sua taxa de desvio em relação ao tempo real
– Falha de desempenho (processo): o processo ultrapassa os
limites de tempo entre duas etapas
– Falha de desempenho (canal): a transmissão de uma
mensagem demora mais do que o limite definido
 Modelo de segurança
• Normalmente modelamos um adversário (ou inimigo), suas
capacidades e seus recursos

• A partir dele, fazemos um modelo de ameaças

 Ameaça aos processos
• O adversário é capaz de fazer requisições não-autorizadas
– Conexão sem SSL
– Serviços sem senha

• É necessário que o serviço seja capaz de verificar a identidade do

requisitante

• E o mesmo vale se o adversário puder se passar pelo servidor

– O cliente deve conseguir verificar a identidade do servidor
 Lidando com ameaças
• Criptografia: ciência de manter mensagens seguras
– Criptografar = embaralhar de forma a só ser desembaralhado
por quem conhece uma chave
– É possível perceber se alguém alterou uma mensagem
criptografada
• Autenticação: prova uma identidade usando criptografia
• Autorização: define que identidades podem fazer o que
• Com autenticação + criptografia temos canais seguros:
– Partes sabem a identidade do outro lado do canal
– Esses canais provêm confidencialidade e integridade
– SSL provê essa abstração para um desenvolvedor
 Trabalho
• Exercício de aula:
• Procurar sobre a Falha bizantina
– Explicar o que é?
– Como está relacionada a Sistemas Distribuídos?

– Iremos conversar sobre o assunto após a pesquisa