UNIVERSIDADE ESTADUAL DO PIAUÍ - UESPI

CAMPUS PROFESSOR ANTÔNIO GIOVANNE ALVES DE SOUSA

CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO

SISTEMAS DISTRIBUÍDOS - MODELOS

Msc. PATRÍCIA DAYANA DE ARAÚJO SOUZA

Material Adaptado
Conteúdo

Modelos Físicos

Modelos Arquiteturais

Modelos Fundamentais
 Visão Geral dos Modelos

Modelos Fundamentais: Interação, falhas e segurança

Modelos Arquiteturais: entidades, paradigmas e responsabilidades

Modelos Físicos: Rede cabeada, WIFI, sensores, etc

 Modelos físicos
Consideram tipos de hardware/dispositivos conectados e suas
conexões.

No início Depois Atualmente

▪ Redes Locais;
▪ Poucos dispositivos: 10 a
100;
▪ Somente computadores
“desktops”;
▪ Ambientes específicos:
universidades e centros de
pesquisas;
▪ Internet;
▪ Muitos dispositivos;
▪ Alguma heterogeneidade;
▪ Ambientes diversos: casas,
empresas, universidades,
etc
▪ Computação móvel
▪ Ubiquidade
▪ Comunicação sem fio
▪ Alta heterogeneidade
▪ Nuvem
 Introdução
❑ Sistemas distribuídos muitas vezes são complexas peças de
software cujos componentes estão, por definição, espalhados
por várias máquinas.
❑ Para controlar sua complexidade, é crucial que esses sistemas
sejam organizados adequadamente.
❑ A arquitetura de um sistema distribuído trata em grande parte
dos componentes de software que compõe o sistema;
• Essa arquitetura de software nos diz como os vários componentes de
software são organizados e como devem interagir;
 Estilos Arquitetônicos
❑ Um estilo arquitetônico é formulado em termos de:
❑ Componentes: unidade modular com interfaces requeridas e fornecidas
bem definidas e que podem ser substituível dentro de seu ambiente;
❑ Conexões: o modo como esses componentes estão conectados uns aos
outros;
❑ Dos dados trocados entre componentes e;
❑ Da maneira como esses elementos são configurados em conjunto para
formar um sistema.

Módulos de código-> c1 c2 <-Módulos de código

Aplicação

c3
Módulos de código->
 Modelos de sistemas distribuídos
• Modelos de arquitetura
– Um modelo de arquitetura de um sistema
distribuído envolve o posicionamento de suas
partes e os relacionamentos entre elas;
• Modelos fundamentais
– Os modelos fundamentais envolvem uma descrição
mais formal das propriedades comuns a todos os
modelos de arquitetura (Ausência de um relógio global; A
comunicação entre processos por troca de mensagens; Atrasos e
vulnerabilidade devido a rede de comunicação.).
 Modelos de sistemas distribuídos
• Modelo fundamental se dividem em três principais tipos:
• Modelo de interação
– Lida com questões de desempenho e limites de tempo.
• Modelo de falhas
– Busca definir as principais falhas que podem ocorrer em um
sistema e fornecer mecanismos de comunicação confiáveis
• Modelo de segurança
– Define as principais falhas ameaças para um sistema e como lidar
com elas
MODELOS DE ARQUITETURAS
DE SISTEMAS DISTRIBUÍDOS
 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.
• Classificação dos processos:
• Processos cliente.
• Processos servidor.
• Processos peer-to-peer.
 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.
 Arquitetura de sistemas
❑ Principais Modelos:
❑ Arquiteturas em camadas;
❑ Arquiteturas baseada em objetos;
❑ Arquitetura centrada em dados;
❑ Arquitetura baseada em eventos /publish-subscribe.
Arquitetura Baseada em Camadas
Arquitetura Baseada em Camadas
 Arquiteturas Baseadas em Objetos

-Cada objeto corresponde ao que definimos como componente, e esses

componentes são conectados por meio de uma chamada de procedimento
(remota).
-Bastante exploradas em arquiteturas cliente-servidor.
 Arquiteturas Centradas em Dados
Arquiteturas centrada em dados se desenvolvem em torno da ideia
de que processos se comunicam por meio de um repositório comum
(passivo ou ativo).
 Arquitetura Baseada em Eventos
❑ Os processos de comunicam, em essência, por meio de
propagação de eventos, opcionalmente, também
transportam dados;
❑ Sistemas Publicar/Escrever;
❑Processos publicam eventos onde o middleware assegura
que somente os processos que subscreveram nesse evento o
receberão;
❑Processos fracamente acoplados referencialmente;
Arquitetura Baseada em Eventos
Arquiteturas de Sistema
❑Estilos arquitetônicos:
;
❑Centralizadas
▪ Cliente-Servidor
▪ Camadas de Aplicação
▪ Arquiteturas Multidivididas
❑Descentralizadas
▪ Peer-to-peer
❑Híbridas
▪ Sistemas de Servidor de Borda
▪ Sistemas Distribuídos Colaborativos
 Arquitetura de Sistemas Centralizadas
Pensar em termos de clientes que requisitam serviços de
servidores ajuda a entender e gerenciar a complexidade de
sistemas distribuídos;

Servidor é um processo que implementa um serviço específico.

Cliente é um processo que requisita um serviço de um servidor utilizando uma
requisição e, aguarda pela resposta do servidor.
-Essa interação é conhecida como comportamento requisição-resposta.
Arquitetura centralizada com
camadas de aplicação
 Camadas de Aplicação
• Nível de Interface do usuário;
• Contém tudo que é necessário para interagir com o usuário;
• Softwares criados para interagir com as aplicações;
• Ex: Tela baseada em caracteres;
• Nível de processamento;
• Contém as aplicações (funcionalidade central);
• Ex: O núcleo de um Sistema de busca.
• Nível de dados;
• Formado pelos programas que mantêm os dados; Dados persistentes
• Mesmo que nenhuma aplicação esteja sendo executada, os dados
estarão armazenados em algum lugar para próxima aplicação;
 Arquiteturas Multidivididas

Figura – Alternativas de organizações cliente-servidor (duas divisões)

Arquiteturas Multidivididas
 Arquiteturas Multidivididas
• A distinção entre três níveis lógicos sugere várias
possibilidade para a distribuição física de uma aplicação
cliente-servidor por várias máquinas;
• Organização mais simples é ter só dois tipos de
máquinas (arquitetura de duas divisões físicas);
1 – Uma máquina cliente que contém apenas os
programas que implementam o nível (parte do nível) de
interface de usuário;
2 – Uma máquina do servidor que contém o resto, ou
seja, o nível de processamento e de dados;
 Arquiteturas Multidivididas
• Arquiteturas cliente-servidor multidivididas são uma
consequência direta da divisão de aplicações em uma
interface de usuários em componentes de
processamento e em um nível de dados;
• Este tipo de distribuição é denominada distribuição
vertical que é obtida ao se colocar componentes
logicamente diferentes em máquinas diferentes;
 Arquiteturas Descentralizadas
• O cliente-servidor possuem duas distribuições:
• A distribuição vertical:
• Componentes logicamente diferentes em máquinas diferentes;
• Cada máquina vai executar um conjunto especifico e pré-determinado
de funções (onde essas são bem definidas).
• Servidor de arquivos, servidor Web....
• Distribuição horizontal:
• Um cliente ou servidor pode ser fisicamente subdividido em partes
logicamente equivalentes, mas cada parte está operando em sua
própria porção do conjunto completo de dados (ou seja, várias
máquinas podem implementar o mesmo serviço);
• Resulta em um equilíbrio de carga; Ex: Peer-to-Peer;
 Arquiteturas Descentralizadas
• Em alto nível, os processos que compõe um sistemas peer-
to-peer são todos iguais e “flat”;
• Como consequência, grande parte da interação entre
processos é simétrica: cada processo agirá como um cliente e
um servidor ao mesmo tempo (servente);
• Para diferenciar quem é o cliente e quem é o servidor: o
cliente é quem inicia a requisição.
• Rede de sobreposição: rede na qual os nós são formados
pelos processos e os enlaces representam os canais de
comunicação possíveis;
 Arquiteturas Descentralizadas
• A rede de sobreposição pode ser:
• Redes Peer-to-Peer Estruturadas;
• A rede de sobreposição é construída com utilização
de um procedimento determinístico;
• Tabela Hash Distribuída (DHT – Dsitributed Hash Table);
• Redes Peer-to-Peer Não Estruturadas;
• Dependem, em grande parte, de algoritmos
aleatórios para construir uma rede de sobreposição;
• Cada nó mantem uma lista de vizinhos, mas a lista
é construída de forma aleatória;
• Quando necessário buscar um item de dado, é feito
por inundação;
 Arquiteturas Descentralizadas
• Redes Peer-to-Peer Estruturadas;
• A rede de sobreposição é construída com utilização de um
procedimento determinístico;
• Tabela Hash Distribuída (DHT – Dsitributed Hash Table);
 Arquiteturas Descentralizadas
• Redes Peer-to-Peer Não Estruturadas;
• Dependem, em grande parte, de algoritmos aleatórios
para construir uma rede de sobreposição;
• Cada nó mantem uma lista de vizinhos, mas a lista é
construída de forma aleatória;
• Quando necessário buscar um item de dado, é feito por
inundação;
• P2P não estruturados podem
se tornar problemáticos
à medida que crescem.
• Solução (possível):
Nós intermediários,
ou superpares.
 Arquiteturas Híbridas

• Soluções clientes-servidores são combinadas

com a forma de funcionamento da arquitetura
descentralizada;
 Arquiteturas Híbridas
• Sistemas Distribuídos Colaborativos
• A questão principal é conseguir dar a partida, para o que muitas
vezes é disponibilizado um esquema cliente-servidor tradicional;
• O nó junta-se ao sistema e poderá utilizar um esquema
descentralizado para colaboração;
• Ex.: Sistemas de Servidor de Borda
• Servidores são colocados na borda da rede;
• A borda é formada pelas fronteiras entre as redes corporativas e
a Internet;
• Principal função é servir conteúdo podendo ofertar
• filtragem e transcodificação;
 Arquiteturas Híbridas

Figura 04 – Visão da internet como rede composta por um conjunto de servidores de borda
 Arquiteturas Híbridas
• Ex: Sistema de Compartilhamento BitTorrent

Figura 05 – Funcionamento principal do BitTorrent

 Requisitos de projeto para
arquiteturas distribuídas
• Aspectos de projeto importantes:
– Divisão de responsabilidades entre os componentes
de um sistema;
– Alocação dos componentes nos diversos
computadores de uma rede;

• Desempenho • Qualidade de serviço (QoS)

– Reatividade – Confiabilidade
– Vazão (throughput) – Segurança
– Balanceamento de carga – Desempenho
– Adaptabilidade
– Disponibilidade
Requisitos de projeto para arquiteturas distribuídas

• Uso de cache e replicação

• Dependabilidade
– Corretude
– Tolerância a falhas
– Segurança
Arquitetura versus Middleware
Onde o middleware se encaixa?
Middleware forma uma camada entre
aplicações e plataformas distribuídas;
 Arquitetura versus Middleware
Normalmente, sistemas de middleware seguem um
estilo arquitetônico específico;
Ex: CORBA -> baseado em objetos
Moldar o middleware de acordo com um estilo
arquitetônico específico tem como benefício a
simplificação do projeto de aplicações;
Contudo, uma óbvia desvantagem é que o
middleware pode não ser o ideal para o
desenvolvimento de determinados tipos de
aplicações;
Arquitetura versus Middleware
A melhor solução é fazer sistemas de
middleware de modo que sejam simples de
configurar, adaptar e personalizar conforme a
necessidade da aplicação;
Alguns mecanismo para realização dessa tarefa
são apresentados a seguir:
Mecanismos de Middlewares: Interceptadores
Um interceptador nada mais é do que um constructo de
software que interromperá o fluxo de controle usual e
permitirá que seja executado um outro código (específico da
aplicação).
Mecanismos de Middlewares: Middlewares adaptativos
O ambiente na qual as aplicações distribuídas são
executadas está sempre mudando, seja por causa da
mobilidade dos componentes, seja por causa do sistema de
comunicação ou de problemas de hardware;

Essas características mostram a necessidade de adaptação

e em vez de fazer com que as aplicações sejam
responsáveis por agir à mudanças, essa tarefa é colocada
no middleware;
Mecanismos de Middlewares
Técnicas para adaptação de Software
Separação de Interesses;
Reflexão Computacional;
Projeto Baseado em Componentes;
Autogerenciamento.
Técnicas para adaptação de Software
Separação de Interesses
Está relacionada com o modo tradicional de
modularizar sistemas: separar as partes que
implementam funcionalidades das que cuidam
de outras coisa (funcionalidades extras)
Confiabilidade;
Desempenho;
Segurança.
Reflexão Computacional
Se refere à capacidade de um programa inspecionar
a si mesmo e, se necessário, adaptar seu
comportamento;
A reflexão foi embutida em algumas linguagens de
programação, entre elas Java.
Projeto Baseado em Componentes
Suporta adaptação por meio de composição.
Um sistema pode ser configurado
estaticamente durante a elaboração do projeto
ou dinamicamente em tempo de execução.
Autogerenciamento
O autogerenciamento consiste em ter a
organização de sistemas distribuídos como
sistemas de realimentação de controle de alto
nível que permite adaptação automática a
mudanças;
Sistemas distribuídos – e em especial seu
middleware associado – precisam fornecer soluções
gerais de blindagem de modo que possam suportar o
maior número possível de aplicações, mas com
suporte as soluções específicas e por isso necessitam
ser adaptativos;
MODELOS FUNDAMENTAIS DE
SISTEMAS DISTRIBUÍDOS
 Modelos fundamentais
• 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:
– 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
• 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?
Sistemas distribuídos síncronos
• Suposições de tempo:
– O tempo para executar cada etapa de um processo
tem limites inferior e superior conhecidos;
– Cada mensagem transmitida em um canal é recebida
dentro de um tempo limitado, conhecido;
– Cada processo tem um relógio local cuja taxa de
desvio de tempo real (drift) tem um limite
conhecido.

• Porém, é muito dificil chegar a valores realistas e

dar garantias dos valores escolhidos, tornando o
projeto menos confiável.
 Modelos de interação
• Sistemas distribuídos síncronos
– Possui suposições fortes a respeito do tempo de
interação;
• Sistemas distribuídos assíncronos
– Não faz suposições de tempo de interação.
Sistemas distribuídos assíncronos
• Não faz qualquer consideração sobre:
– as velocidades de execução dos processos;
– os atrasos na transmissão das mensagens;
– as taxas de desvio do tempo real dos relógios.

• Este modelo representa bem a Internet (e vários

outros sistemas distribuídos reais);
 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: Quando ocorre uma falha, para-se de responder.
– Fail-‐stop: falhas de travamento, pode detectar a falha.
• Em canais de comunicação:
– Mensagem enviada não chega ao destino
• Exemplo: drop no roteador
 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.
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.
 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
– RMI 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
Ameaça à interação dos processos
• Ataques possíveis para um adversário:
– Se passar por outro processo e enviar uma mensagem
– Escutar mensagens nos canais de comunicação e alterá--
‐las, omiti-‐las ou repeti‐las
– Enviar tantas requisições a um servidor que o paralisa (Denial
of Service)

• De quais desses ataques nosso adversário é capaz?

• De quantos recursos ele dispõe?
 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êem confidencialidade e integridade;
– SSL provê essa abstração para um desenvolvedor.
 O que vimos...
• Um modelo de arquitetura de um sistema distribuído
envolve o posicionamento de suas partes e os
relacionamentos entre elas

• Modelos de arquitetura de SD:

– Cliente-‐servidor; Peer-‐to-‐peer; Múltiplos servidores;

• Requisitos no projeto de arquiteturas distribuídas:

– Desempenho; Qualidade de serviço; Uso de caching e
replicação; Dependabilidade
 O que vimos...
• Modelos →→ ferramenta para analisar propriedades
de sistemas distribuídos
• Repertório de aspectos usados em modelos de SD:
• Aspectos de modelos de interação:
– Síncrono; Assíncrono
• Aspectos de modelos de falhas
– Nos processos; nos canais de comunicação
– De omissão, de tempo, arbitrárias
• Aspectos de modelos de segurança
– Modelos de ameaças
– Criptografia, autenticação, autorização, canal seguro
 Exercício II
1. Diferencie os tipos de arquiteturas de sistemas distribuídos, abaixo listadas, e busque
exemplos de Sistemas/Serviços/Aplicações/plataformas distribuídas que fazem uso
dessas arquiteturas.
• Arquiteturas em camadas;
• Arquiteturas baseada em objetos;
• Arquitetura centrada em dados;
• Arquitetura baseada em eventos /publish-subscribe;
• Arquitetura centralizadas(Multidivididas);
• Arquiteturas descentralizadas(Estruturadas e Não-Estruturadas)
• Arquitetura orientada a serviços;
• Arquitetura Baseada em recursos;
2. Pesquise sobre Sistemas/Serviços/Aplicações/Plataformas que implementa todos, ou
pelo menos um, dos modelos Modelos fundamentais. E como isso é implementado?
 Referência
− TANENBAUM, Andrew S.; STEEN, Maarten Van., Sistemas
Distribuídos: Princípios e Paradigmas. São Paulo: Pearson Pretice Hall,
2007. 2ed.
− LIMA, Rommel Wladimir de. Arquiteturas de sistemas distribuídos. 01 aug.
2013, 01 dec. 2103. Notas de Aula.
− COULOURIS, George; DOLLIMORE, Jean; KINDBERG, Tim. Sistemas
Distribuídos: conceitos e projeto. 4.ed. Porto Alegre: Bookman, 2007.