Prévia do material em texto

Prof. Me. Michel Fernandes
UNIDADE I
Desenvolvimento de 
Sistemas Distribuídos
 Um Sistema Distribuído é um conjunto de computadores interligados via rede, mas, para o 
usuário final das aplicações executadas por meio desse sistema, aparenta ser um 
sistema único. 
 Sistemas que não dependem apenas de uma máquina.
 Definem a forma como os diversos objetos distribuídos se comunicam e interagem entre si.
Dois aspectos:
 Computadores independentes.
 Um único sistema middleware.
Sistemas distribuídos – Definição
A internet é formada por:
 Backbones (espinha dorsal da internet). 
 Redes de provedores (ISP).
 Redes de clientes (redes na borda da internet).
Estrutura da internet atual
Fonte: Fouruzan e Mousharraf (2013, p. 7).
Várias formas de conectividade sem fio ou wireless
 Tecnologias de conexão, como bluetooth, wi-fi, 3G, NFC. 
Especificações de cada tecnologia variam em: 
 largura de banda; 
 latência ou atrasos de comunicação; 
 custos de energia; e 
 existência de custos financeiros na comunicação. 
 Característica comum às redes móveis: a volatilidade 
da conectividade.
 A variação do estado da conexão ou desconexão entre os 
dispositivos em tempo de execução e a qualidade de serviços 
oferecido por eles.
Conectividade móvel
 Disponibilidade alta e facilidade de acesso ao sistema e a todos os seus recursos.
 Importante: O usuário deve desconhecer a distribuição de recursos do sistema.
 O sistema deve ser aberto e heterogêneo.
Fazer o link entre usuários e recursos:
 Compartilhamento de recursos.
 Segurança.
 Reduzir a comunicação indesejada.
Sistemas distribuídos – Objetivos
 Propriedade que mede a capacidade do sistema em lidar facilmente com uma quantidade 
crescente de trabalho. 
Três medidas para medir a escalabilidade:
 Número de processos e/ou usuários (escalabilidade de tamanho).
 Distância máxima entre os nós (escalabilidade geográfica).
 Número de domínios administrativos (escalabilidade administrativa).
Sistemas distribuídos – Escalabilidade
 Formas de ocultação para os usuários e desenvolvedores de aplicação. 
 Deseja-se que o sistema seja percebido como único, em vez de uma coleção de 
partes independentes.
 É uma das métricas de sucesso
de um SD.
 7 formas de transparência.
Sistemas distribuídos – Transparência
Fonte: Tanenbaum; Steen, 2007, p. 3.
Transparência Descrição
Acesso
Oculta diferenças na representação de dados e 
no modo de acesso a um recurso.
Localização Oculta o lugar em que um recurso está localizado.
Migração
Oculta que um recurso pode ser
movido para outra localização.
Relocação
Oculta que um recurso pode ser movido para uma 
outra localização enquanto uso.
Replicação Oculta que um recurso é replicado.
Concorrência
Oculta que um recurso pode ser compartilhado 
por diversos usuários concorrentes.
Falha Oculta a falha e a recuperação de um recurso.
 Jogos on-line
 Vários tipos de “computadores”.
 Vários tipos de papel (role).
 Várias formas de comunicação.
 Várias camadas
lógicas (abstrações).
Sistemas distribuídos – Exemplos
Fonte: adaptado de: https://cloud.google.com/files/DedicatedGameServerSolution.pdf
 Jogos on-line.
 Pesquisas na web (Google).
 Serviços de streaming (YouTube, Netflix, Amazon Prime).
 Bancos de dados distribuídos.
 Cloud computing.
 WhatsApp.
 Redes sociais.
 Diversas aplicações pela web.
Sistemas distribuídos – Exemplos
 Nenhuma máquina tem informação completa do estado do sistema.
 As máquinas tomam decisões com as informações locais.
 A falha no algoritmo não “quebra” todo o sistema.
 Não existe uma suposição de um relógio global.
Sistemas distribuídos – Algoritmos 
 Aumenta a disponibilidade dos recursos.
 Balanceamento de carga.
 Oculta a latência de comunicação caso haja grande dispersão geográfica.
Sistemas distribuídos – Técnicas de escalabilidade 
Uma característica fundamental dos sistemas distribuídos é a transparência, que é uma forma 
de ocultar para usuários e desenvolvedores de aplicação a localização de um recurso.
Qual tipo de transparência ocorre quando o sistema oculta a falha e a recuperação de 
um recurso? 
a) Transparência de acesso.
b) Transparência de localização.
c) Transparência de migração.
d) Transparência de falha.
e) Transparência de concorrência.
Interatividade
Uma característica fundamental dos sistemas distribuídos é a transparência, que é uma forma 
de ocultar para usuários e desenvolvedores de aplicação a localização de um recurso.
Qual tipo de transparência ocorre quando o sistema oculta a falha e a recuperação de 
um recurso? 
a) Transparência de acesso.
b) Transparência de localização.
c) Transparência de migração.
d) Transparência de falha.
e) Transparência de concorrência.
Resposta
 Middleware funciona como uma camada de tradução para interligar o sistema operacional 
com os programas.
 Fator essencial para o bom funcionamento de aplicações distribuídas.
Exemplos de middleware: 
 Os Serviços Web ou Web Services. 
 RMI Java.
 CORBA. 
Sistemas distribuídos – Camadas
Fonte: Tanenbaum; Steen, 2007, p. 4.
Computador 1 Computador 2 Computador 3 Computador 4
Apl. A Apl. CAplicação B
Camada do sistema distribuído (middleware)
SO Local 1 SO Local 2 SO Local 3 SO Local 4
Um estilo arquitetônico é determinado por meio dos:
 Componentes: unidade modular com interfaces requeridas e fornecidas bem definidas, que 
é substituível dentro de seu ambiente.
 Conexões: o modo como os componentes estão ligados.
 Dados intercambiados: forma da troca dos dados entre componentes 
(repositório compartilhado?).
 Formas de configuração: maneiras como os componentes são configurados (em tempo 
de execução?).
Estilos arquitetônicos
 Arquiteturas de camadas.
 Arquiteturas baseadas em objetos.
 Arquiteturas centradas em dados.
 Arquiteturas baseadas em eventos.
Tipos de estilos arquitetônicos
 Ideia semelhante à estrutura de redes TCP/IP. 
 Componentes são organizados em camadas.
 Componente da camada N tem permissão para chamar componentes da camada N-1.
Arquitetura em camadas
Fonte: Tanenbaum; Steen, 2007, p. 21.
Camada N
Camada N-1
Camada 2
Camada 1
Fluxo de
requisição
Fluxo de
resposta
 Objetos são os componentes.
 Objetos são conectados a outros por chamada remota.
 Amplamente explorado em sistemas cliente-servidor.
Arquitetura baseada em objetos
Fonte: Tanenbaum; Steen, 2007, p. 21.
ObjetoObjeto
Objeto
Objeto
Objeto
Chamada de
método
 Componentes se comunicam por meio de um repositório comum, como se fosse uma 
“caixa postal”.
 Fracamente acoplado.
Arquitetura centrada em dados
Fonte: Tanenbaum; Steen, 2007, p. 21.
Componente Componente
Entrega de dados
Espaço de dados (persistente)
compartilhado.
 Sistema publicar/subscrever (publish/subscribe).
 Componentes publicam eventos e certificam que somente os que subscreveram recebam 
esses eventos.
 Fracamente acoplados: não invocam explicitamente um ao outro. 
 Exemplo: Apache Kafka. 
Arquitetura baseada em eventos
Fonte: Tanenbaum; Steen, 2007, p. 21.
Componente Componente
Entrega de dados
Barramento de eventos
Publicar
Componente
Perguntas importantes para definição da arquitetura:
 Como os sistemas distribuídos são organizados na prática?
 Onde são executados os componentes de software?
 Como eles se comunicam?
 Há um elemento central?
Arquiteturas de sistemas
 Arquiteturas centralizadas
 Cliente-servidor: Netflix, site de notícias, mobile banking etc.
 Arquiteturas descentralizadas
 Sistemas peer-to-peer, como o Chord.
 Arquiteturas híbridas
 Sistemas peer-to-peer, como o BitTorrent, Skype e WhatsApp.
Arquiteturas de sistemas
Processos são divididos em dois grupos
 Servidor: processo que implementa um serviço específico.
 Cliente: processo que requisita um serviço ao servidor.
 Forma de interação: requisição-resposta.
Arquitetura cliente-servidor
Fonte:Tanenbaum; Steen, 2007, p. 21.
Espera Resultado
Cliente
Fornece serviço
Servidor
Tempo
Requisição Resposta
Considerando muitas aplicações e a sua escalabilidade:
 Nível de interface de usuário.
 Nível de processamento.
 Nível de dados.
Arquitetura centralizada com camadas de aplicação
Fonte: Tanenbaum; Steen, 2007, p. 24.
Interface de Usuário
Expressão da
palavra-chave
Gerador de
Consultas
Consultas ao banco 
de dados
Banco de dados
com páginas web
Títulos de páginas web
com metainformação
Algoritmo
de Ordenação
Página HTML que
contém a lista
Lista ordenada
de títulos de
páginas
Nível de
interface de
usuário
Nível de
processamento
Nível de
dados
Gerador de
HTML
Gerenciamento de sistema:
 Clientes gordos (fat clients).
 Clientes magros (thin clients).
Distinção clara:
 Arquitetura de duas divisões
(cliente e servidor).
Arquitetura centralizada com arquiteturas multidivididas
Fonte: adaptado de: Tanenbaum; Steen, 2007, p. 25.
Clientes 
“Magros”
Clientes 
“Gordos”
Arquitetura de três divisões:
1. Cliente.
2. Servidor.
3. Servidor que pode agir como cliente.
 Recebe e faz a requisição.
Arquitetura centralizada com arquiteturas multidivididas
Fonte: Monteiro et al, 2020, p. 65.
Servidor
Servidor
Cliente
Cliente
Solicita
Responde
Responde
Solicita
Solicita
Responde
Na arquitetura cliente-servidor, qual é o modelo de interação entre os componentes? 
a) Chamadas de sistemas.
b) Chamadas de métodos remotos.
c) Solicitação e resposta.
d) Comunicação aleatória.
e) Publicação e subscrição.
Interatividade
Na arquitetura cliente-servidor, qual é o modelo de interação entre os componentes?
a) Chamadas de sistemas.
b) Chamadas de métodos remotos.
c) Solicitação e resposta.
d) Comunicação aleatória.
e) Publicação e subscrição.
Resposta
 Cliente-servidor possui duas distribuições: vertical e horizontal.
 Distribuição vertical
 Componentes logicamente diferentes em máquinas diferentes.
 Cada máquina vai executar um conjunto específico e predeterminado de funções.
 As funções de cada um são bem definidas.
Arquiteturas descentralizadas
 Cliente-servidor possui duas distribuições: vertical e horizontal.
 Distribuição horizontal
 Cliente ou servidor pode ser fisicamente subdividido em partes logicamente equivalentes.
 Pode possuir porção própria de dados.
 Balanceamento de carga.
 Papéis não muito bem definidos.
 Exemplo: compartilhamento de arquivos peer-to-peer, em que cada nó envia uma parte de 
um arquivo.
Arquiteturas descentralizadas
 Par a par.
 Processos são todos iguais e flat.
 Cada processo age ao mesmo tempo como cliente e servidor (servente).
 O cliente é quem inicia a requisição. 
 Rede de sobreposição: rede onde os nós são formados pelos processos e os enlaces 
denotam os canais de comunicação.
 Arquiteturas estruturadas e não estruturadas.
Arquiteturas descentralizadas: peer-to-peer
Fonte: adaptado de: Fouruzan; Mosharraf, 2013, p. 37.
 A rede de sobreposição é construída usando um mecanismo determinístico e “estruturado”.
 Mecanismo usado comumente: DHT (Distributed Hash Table).
 Dados e nós recebem uma chave aleatória (128~160 bits).
 Desafio: Dada uma chave de um dado, mapear para o identificador de um nó. 
 Nesse caso, a requisição é roteada entre os nós até alcançar o nó com o dado solicitado.
Arquiteturas descentralizadas: peer-to-peer estruturada 
 Chord: implementação de um DHT para redes peer-to-peer.
 Nós estão logicamente organizados em um anel.
 Cada nó recebe um identificador aleatório (semelhante a um RG).
Arquiteturas descentralizadas: peer-to-peer estruturada 
Fonte: Tanenbaum; Steen, 2007, p. 27.
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{13,14,15} {0,1}
{2,3,4}
{5,6,7}
{8,9,10,11,12}
Chaves de dados
associadas
Nó real
 Algoritmos aleatórios são utilizados para construir a rede de sobreposição.
 Cada nó mantém uma lista de nós vizinhos.
 Dados são também armazenados aleatoriamente.
Como é realizada a busca?
 Inunda toda a rede. Tempestade de broadcast.
Arquiteturas descentralizadas: peer-to-peer não estruturada 
 Com o crescimento da rede, localizar itens de dados em sistemas P2P não estruturados 
pode ser problemático.
 Nós “diretórios” e/ou intermediários.
 Sempre que um nó comum se junta à rede, liga-se a um dos superpares.
 Dificuldade: Seleção do líder.
 Os superpares devem ter vida longa e alta disponibilidade.
Arquiteturas descentralizadas: peer-to-peer superpares
Fonte: Tanenbaum; Steen, 2007, p. 30.
 Soluções de cliente-servidor são combinadas com a forma de funcionamento da 
arquitetura descentralizada.
 Híbrida = centralizada + descentralizada.
 Centralizada: Serviço de diretório.
 Descentralizada: Distribuição do conteúdo. 
 Exemplos: Skype, BitTorrent, WhatsApp.
Arquiteturas híbridas
 Sistemas distribuídos colaborativos.
 Inicialmente, um esquema de procura pelo cliente-servidor tradicional.
 Subsequentemente, o nó junta-se para dar um mecanismo descentralizado de colaboração.
Sistemas distribuídos colaborativos
Fonte: Tanenbaum; Steen, 2007, p. 25.
 Os middlewares como CORBA eram todos baseados em objetos.
 É simples e específico para aplicações com objetos remotos, porém, não é trivial criar ou 
estender para outros tipos de aplicações.
 Necessidade de reconfiguração dinâmica em tempo de execução.
Arquitetura vs. middleware
Uma solução para reconfigurar a necessidade da aplicação?
 Interceptadores.
 É uma construção de software que 
interromperá o fluxo de controle usual 
de execução.
 Em uma chamada, desvia para 
outra chamada.
 Em tempo de execução.
Interceptadores
Fonte: Tanenbaum; Steen, 2007, p. 34.
Em arquiteturas descentralizadas estruturadas, um desafio é o mapeamento do identificador de um 
nó, conhecendo a chave de um dado. Qual é o mecanismo para identificar os nós que contêm os 
dados procurados? 
a) Chave primária.
b) Superpares.
c) Servidor de nomeação.
d) Protocolo de comunicação TCP.
e) Tabela de Hash distribuída (DHT).
Interatividade
Em arquiteturas descentralizadas estruturadas, um desafio é o mapeamento do identificador de um 
nó, conhecendo a chave de um dado. Qual é o mecanismo para identificar os nós que contêm os 
dados procurados? 
a) Chave primária
b) Superpares.
c) Servidor de nomeação.
d) Protocolo de comunicação TCP.
e) Tabela de Hash distribuída (DHT).
Resposta
 eXtensible Markup Language (XML) é uma linguagem de marcação que foi padronizada para 
a internet pelo World Wide Web Consortium (W3C).
Características: 
 Criação de marcas, ou tags, que delimitam os dados.
 Projetada para ser lida por humanos e máquinas.
 Permite que usuários criem suas próprias tags.
 Objetivo da XML: transferência de documentos por meio da web, independentemente do 
formato de arquivos e sistemas operacionais. 
 HTML: representação de páginas web.
Linguagem XML
 É um middleware de comunicação que ‘’permite a processos chamar procedimentos 
localizados em outras máquinas” (Birrell e Nelson, 1984).
 A ideia é fazer com que uma chamada de procedimento remoto pareça com uma chamada 
local (transparência).
 Problemas: passar parâmetros em espaços de endereçamento diferentes, “queda da 
máquina” etc.
Chamada de Procedimento Remoto (RPC)
A transparência é alcançada por meio dos stubs (apêndices):
 Stub do cliente: empacota os parâmetros em uma mensagem e a envia para a máquina
do servidor.
 Desempacota e compatibiliza a arquitetura.
 Stub do servidor: desempacota os parâmetros e invoca o procedimento do servidor.
 Empacota os parâmetros na mensagem de resposta.
 Ambos são compilados antes.
RPC e os stubs
Passos para uma RPC
Fonte: https://www.dimap.ufrn.br/~thais/Pdist/rpc1.pdf
transporte de mensagens via rede
transporte de mensagens via rede KERNELKERNEL
Empacota
Resultados
ServidorStub do ServidorStub do ClienteCliente
Desempacota
ParâmetrosEmpacota
Parâmetros
Desempacota
Resultado
Máquina do Cliente Máquina do Servidor
 Empacotar parâmetros em uma mensagem é conhecido como marshalling de parâmetro.
RPC suporta:
 Passagem por valor.
 Passagem por referência.
Passos para RPC
Fonte: adaptado de: Tanenbaum; Steen, 2007, p. 99.
Etapas envolvidas para fazer um cálculo remoto por meio de RPC.
Máquina cliente
Processo cliente
Máquina servidora
Máquina servidora
Implementação
de add
1. Chamada
do cliente
a procedimento
2. Apêndice monta
mensagem
3. Mensagem é enviada pela rede
4. SO servidor entrega
mensagem à apêndice
de servidor
5. Apêndice desempacota
mensagem
6. Apêndice faz chamada
local a “add”
Apêndice
de servidorApêndice
de cliente
SO ServidorSO Cliente
proc: “add”
int: val (i)
int: val (j)
proc: “add”
int: val (i)
int: val (j)
proc: “add”
int: val (i)
int: val (j)
k = add(i,j) k = add(i,j)
 Linguagem de Programação de Interface (IDL).
 Interface: é um conjunto de procedimento que pode ser chamado por um cliente e 
implementado por um servidor. 
 IDL é a linguagem voltada para especificar a interface e permite definir procedimentos
como idempotentes.
 Há aplicações, como o stubgen, que geram o stub a partir da IDL (descrição própria que 
independe da linguagem).
RPC – IDL
 Possibilitar que um objeto possa invocar um método em outro objeto remoto. 
 Conceito da RMI é muito semelhante à da RPC. 
 Diferença: a RMI foca na invocação de objetos remotos (RPC: invocação de procedimentos 
remotos).
 Ferramenta nativa da linguagem Java e a noção de chamadas distribuídas de objetivos foi 
originalmente idealizada a partir do middleware Corba no meio da década de 1990. 
Inovação de Metódo Remota (RMI)
Fonte: Coulouris et al. (2013, p. 207).
A B
Invocação
remota
C E
D
Invocação
remota
F
 Possibilita invocar métodos residentes em máquinas virtuais Java, ou Java Virtual 
Machines (JVM). 
 As definições de todas as interfaces e classes para o sistema de RMI está no pacote 
java.rmi, sendo que a classe de objeto remoto implementa a interface remota.
Java RMI
Fonte: Monteiro et al. (2020, p. 72).
Máquina virtual Java #1 – X Máquina virtual Java #2 – Y
...
obj.método(p){
... 
}
...
Servidor
// Objeto remoto
metodo remoto(p){
...
}
Cliente
Chamada (parâmetros)
Retorno do resultado
 O Component Object Model (COM) foi lançado em 1993. 
 Plataforma da Microsoft para componentes de software. 
 Objetivo: possibilitar a comunicação entre processos e a criação dinâmica de objetos em 
qualquer linguagem de programação.
 Distributed Component Object Model (DCOM) lançado em 2007.
 DCOM estende a plataforma COM em uma rede ao providenciar facilidade para criação e 
ativação de objetos e para gerenciamento de referência de objetos, o ciclo de vida e a 
interface de consulta dos objetos.
Biblioteca COM e DCOM
Aplicação / Protocolo de alto nível
DCOM
RPC
Fonte: autoria própria.
 As propriedades e métodos de um objeto COM ou DCOM são armazenadas em uma 
biblioteca de tipos, um arquivo binário com extensão .tlb.
 Arquivo de definição de interface (IDL). 
 Arquivos de configuração de aplicação, ou Application Configuration File (ACF). 
 Scripts escritos na Linguagem de Definição de Interface da Microsoft, a MIDL, que é a 
implementação da Microsoft e a extensão da linguagem de definição de interface IDL.
 Arquivos apêndice (stub) de cliente e servidor em linguagem C/C++ e arquivo de cabeçalho 
relacionado para uma interface RPC.
Biblioteca COM e DCOM
 Commom Object Request Broker Architecture.
 Arquitetura padronizada definida pelo Grupo de Gerenciamento de Objetos (OMG).
 OMG também criou a linguagem UML.
 A versão 1.0 do CORBA foi divulgada em 1991 e dezenas de versões de atualização.
 Estabelece e simplifica a transferência entre sistemas distribuídos.
 Estruturada para permitir a integração de uma ampla variedade de sistemas objetos.
CORBA
4 componentes
 Object Request Broker (ORB): middleware da especificação CORBA.
 Objetos de serviços: serviços implementados por objetos do sistema. 
 Facilidades comuns: utilitários e interfaces no nível de aplicação. 
 Objetos da aplicação: software proprietário que controla interfaces.
CORBA
Fonte: adaptado de: OMG (2021, p. 11).
 Para fazer um pedido, a aplicação cliente pode utilizar a interface de invocação dinâmica, ou 
Dynamic Invocation Interface (DII).
 Os esqueletos (skeletons) são específicos para uma interface ou para um adaptador 
de objetos.
 Dynamic Skeleton Interface (DSI) permite o tratamento dinâmico da invocação de objetos. 
Uma requisição é composta de:
 uma referência ao objeto servidor;
 o nome da operação requisitada;
 argumentos de requisição ou parâmetros reais;
 informação de contexto.
Arquitetura do CORBA
Arquitetura do CORBA
Fonte: Nardi (2003, p. 14).
Aplicação cliente Aplicação servidora
Interface do
ORB
Esqueleto DSI
Adaptador 
de Objetos
Núcleo (core) do ORB Servidor
Rede
Núcleo (core) do ORB Cliente
Interface do
ORB
DIIStub
Depende da IDL
Comum a todas as aplicações
Pode haver vários adaptadores de objetos
 Interfaces são construídas com Interface Definition Language (IDL).
 Realiza a especificação das interfaces, mas não realiza a implementação de métodos dos 
objetos distribuídos. 
 As linguagens de programação usadas no CORBA, como Java, C, C++, Ada, Smalltalk, entre 
outras, devem possibilitar as construções utilizadas pela IDL.
CORBA – Linguagem IDL
Fonte: autoria própria.
typedef struct _Address {
string endereço;
string cep;
string cidade;
} Address;
typedef sequence AddressList;
interface Team { ... };
Tipos
estruturados
Tipo de
Objeto
Tipo
Atômicos
Na arquitetura CORBA, qual é o nome do módulo intermediário entre cliente e objeto que é 
responsável por facilitar a comunicação entre dois objetos?
a) ORB
b) IDL
c) UML
d) Objetos de aplicação
e) DCOM
Interatividade
Na arquitetura CORBA, qual é o nome do módulo intermediário entre cliente e objeto que é 
responsável por facilitar a comunicação entre dois objetos?
a) ORB
b) IDL
c) UML
d) Objetos de aplicação
e) DCOM
Resposta
 BIRRELL, Andrew D.; NELSON, Bruce Jay. Implementing remote procedure calls. Acm.
Trans. Comput. Syst., [s.l.], v. 2, n. 1, p.39-59, 1 fev. 1984.
 COULOURIS, George; DOLLIMORE, Jean; KINDBERG, Tim. Sistemas distribuídos –
conceitos e projeto. 5. ed. Porto Alegre: Bookman, 2013.
 FOROUZAN, Behrouz A.; MOSHARRAF, Firouz. Redes de computadores. Porto Alegre:
Grupo A, 2013.
 MONTEIRO, Eduarda R.; JUNIOR, Ronaldo C. M.; LIMA, Bruno Santos de; et al. Sistemas
distribuídos. Porto Alegre: Grupo A, 2020.
 TANENBAUM, Andrew S.; STEEN, Maarten van. Distributed
systems. 4. ed. Distributed-systems.net, 2023.
 TANENBAUM, Andrew S.; STEEN, Maarten van. Sistemas
distribuídos: princípios e paradigmas. 2. ed. São Paulo:
Prentice Hall Brasil, 2007.
Referências
ATÉ A PRÓXIMA!