SISTEMAS_DISTRIBUIDOS

Prévia do material em texto

Arquitetura de 
Sistemas Distribuído
Material Teórico
Responsável pelo Conteúdo:
Prof. Me. Max D’Angelo Pereira
Revisão Textual:
Prof. Me. Luciano Vieira Francisco
Arquitetura dos Sistemas Distribuídos
• Introdução;
• Conceitos de Sistemas Distribuídos;
• Modelos de Sistemas Distribuídos;
• Arquiteturas Distribuídas.
• Entender os conceitos básicos de sistemas distribuídos, as diferenças entre os modelos e 
as arquiteturas.
OBJETIVO DE APRENDIZADO
Arquitetura dos Sistemas Distribuídos
Introdução
Durante o período de 1965 a 1980 os computadores começaram a fazer parte 
da rotina das empresas, auxiliando nas tarefas de processamento de dados. Nessa 
época os computadores eram de grande porte, conhecidos como mainframes. 
Todo o processamento ocorria de forma centralizada e as redes de computadores 
ainda estavam em seus estágios iniciais e eram pouco adotadas fora de ambientes 
acadêmicos e militares. 
Figura 1 – Mainframe IBM 360
Fonte: Wikimedia Commons
Leia sobre os cem anos da IBM em: http://tinyurl.com/y3fdcq6e
Ex
pl
or
Importante!
Que durante anos a IBM dominou o mercado de computadores, sendo que o IBM 
System 360 é considerado por muitos autores como um marco no processamento de 
dados empresariais?
Desde então, os mainframes passaram por muitas evoluções, mas ainda são largamente 
utilizados no setor bancário.
Você Sabia?
Com a popularização dos computadores de grande porte, as empresas come-
çaram a sentir a necessidade de compartilhar dados e recursos, de modo que a 
resposta para esse problema foi a adoção das redes de computadores, as quais 
permitiam que hardwares e softwares fossem compartilhados.
Diante do avanço tecnológico nas redes de computadores e na transmissão de 
dados, o processamento, que antes era centralizado, passou a ser distribuído entre 
vários sistemas computacionais distintos.
Figura 2 – Exemplo de sistema com processamento centralizado
Fonte: Acervo do Conteudista
Figura 3 – Exemplo de sistema com processamento distribuído
Fonte: Acervo do Conteudista
O processamento de uma aplicação é uma das características que diferenciam os 
sistemas distribuídos dos centralizados. Quando o processamento ocorre exclusiva-
mente em um servidor e os terminais ficam responsáveis somente pelas operações 
de entradas e saídas, temos claramente um sistema centralizado (Figura 2). Por outro 
lado, se o processamento de uma aplicação ocorre em dispositivos distintos – e não 
apenas em um servidor –, caracteriza-se como um sistema distribuído (Figura 3).
O compartilhamento de memória principal (RAM) é outra característica que 
diferencia sistemas centralizados de distribuídos: em sistemas centralizados as apli-
cações compartilham a capacidade da memória principal entre si; por sua vez, em 
sistemas distribuídos as aplicações podem utilizar a memória principal de acordo 
com o dispositivo ou nó no qual a aplicação está alocada.
Qual tipo de sistema é mais comum em seu dia a dia? 
Ex
pl
or
A partir da década de 1980 a computação avançou de forma radical com os 
microprocessadores e com as redes locais. A capacidade de processamento dos 
microprocessadores aumentou vertiginosamente e os preços diminuíram na mes-
ma proporção; enquanto isso, as redes de computadores ficaram mais rápidas e 
estáveis. Essa Revolução Tecnológica permitiu a criação de ambientes favoráveis 
aos sistemas distribuídos e o resultado permitiu montar sistemas distribuídos mais 
facilmente e com menor custo – comparativamente aos sistemas centralizados de 
grande porte. 
Conceitos de Sistemas Distribuídos
Existem diversas definições para sistemas distribuídos, porém, os autores utili-
zam, em suas conceituações, algumas características comuns aos sistemas distri-
buídos, vejamos:
Tanenbaum e Van Steen (2007) resumiram o conceito de sistemas distribuídos 
como um conjunto de computadores independentes que se apresenta aos seus usuá-
rios como um sistema único. De maneira complementar, Coulouris e colaboradores 
(2013) acrescentam que um sistema distribuído é aquele no qual os componentes de 
hardware ou software comunicam-se de forma coordenada através de uma rede.
Sistemas distribuídos:
• Consistem de componentes;
• Os componentes podem ser hardware ou software;
• Os usuários percebem os componentes como um único sistema;
• Os componentes se comunicam através de uma rede;
• O processamento ocorre de modo concorrente entre os componentes que fazem 
parte da rede.
Sistemas distribuídos não são o mesmo que redes de comunicação: as redes 
preocupam-se com o envio de mensagens de um ponto A para outro B – e não 
com o que se faz com a mensagem. Um sistema distribuído assume que existe 
alguma forma de enviar a mensagem e preocupa-se com as propriedades dessas 
mensagens e como processar e devolver a mensagem ao sistema.
Importante!
O transporte da mensagem é assegurado pela rede de comunicação.
Importante!
A forma como as falhas são tratadas pode ser outro aspecto para diferenciar um 
sistema centralizado de um sistema distribuído: em sistemas centralizados quando 
ocorre uma falha, esta compromete todo o sistema, possibilitando identificar a sua 
ocorrência e reiniciar o sistema como forma de lidar com as falhas detectadas. Em 
um sistema distribuído a falha pode ser parcial – apenas em alguns elementos –, 
não ser conhecida e/ou identificada, de modo que a estratégia de reiniciar o sistema 
não funcionará, uma vez que o sistema distribuído é composto de muitos elemen-
tos computacionais.
Exemplos
Agora que já entendemos o conceito de sistemas distribuídos, analisaremos al-
guns exemplos que estão presentes em nosso dia a dia para facilitar a compreensão 
e contextualizar a teoria com a prática.
• Sistema de buscas na web: Atualmente é comum utilizarmos várias vezes ao 
dia buscas através do Google. Fazemos procuras por meio do navegador do 
computador, smartphone, por textos, áudio de voz e até mesmo por imagem. 
O que não paramos para pensar é que para indexar as mais de 63 bilhões de 
páginas e retornar as pesquisas em milésimos de segundos, o Google cons-
truiu uma das mais complexas instalações de sistemas distribuídos da história 
da computação (COULOURIS et al., 2013); 
• Jogos on-line multiplayer: Os jogos – games – com vários jogadores on-line – 
multiplayer – são exemplos de sistemas distribuídos de alta complexidade. Se ana-
lisarmos que em um jogo on-line a sincronização de tempo entre os vários 
jogadores conectados é uma questão primordial na imersão e no contexto do 
jogo, o processamento da aplicação do game é comumente executado em 
hardwares diferentes, em redes com variação de latência e geograficamente 
distantes; perceberemos que tais sistemas de entretenimento são grandes desa-
fios do ponto de vista computacional;
• Streaming de filmes: Os serviços de assinatura de filmes sob demanda fazem 
grande sucesso pela sua praticidade e adequação ao usuário, que pode assistir 
aos seus filmes em plataformas variadas, tais como computador, telefone celu-
lar, tablet, console de videogame, televisão etc. A aplicação adequa o conteúdo 
aos variados dispositivos utilizados pelo usuário, ajustando também a qualidade 
da transmissão dos dados à velocidade da conexão de rede;
• Aplicativos de transporte por carros: Outro atual exemplo de sistemas dis-
tribuídos corresponde aos aplicativos de transporte por carros, táxis e caronas. 
Tais sistemas possuem aplicações que estão preparadas para lidar com enorme 
variação de dados e responder satisfatoriamente aos usuários de modo on-line, 
independentemente da plataforma e do aparelho utilizado para rodar o aplicativo.
Internet e Intranet
A internet é um grande sistema distribuído, conectando usuários através de 
sites, e-mails, transferências de arquivos, chats etc. Esses serviços estão localiza-
dos fisicamente em computadores dispersos, os quais conectados por algum tipo 
de rede. Inúmeras aplicações e serviços se comunicam através da rede, trocando 
mensagens em diferentes meios de comunicação. A definiçãode um padrão entre 
aplicações e serviços em plataformas diversas permite que a comunicação seja rea-
lizada – padrões estes chamados de protocolos.
Já a intranet é uma parte da internet administrada separadamente por uma or-
ganização. Uma intranet é composta de várias redes locais – Local Area Network 
(LAN) – interligadas. A configuração de rede de uma intranet pode variar desde 
uma LAN em um único site até um conjunto de LAN interconectadas e geografica-
mente distantes entre si. 
Importante!
Uma intranet pode ser conectada à internet; igualmente é possível que uma intranet se 
conecte a outras intranets.
Importante!
Modelos de Sistemas Distribuídos
Antes de começarmos a avançar no conteúdo sobre sistemas distribuídos, exami-
naremos com atenção os vários modelos de sistemas distribuídos. A seguir faremos 
a diferenciação entre sistemas de computação distribuídos, sistemas de informação 
distribuídos e sistemas embutidos distribuídos.
Sistemas de Computação Distribuídos
Estes sistemas distribuídos são utilizados para aplicações de alto desempenho 
computacional. Podemos encontrar dois subgrupos: computação de cluster e 
computação em grade.
A computação em cluster basicamente se resume a conectar vários computa-
dores ou estações de trabalho – nós – semelhantes a uma rede de alta velocidade. 
Dessa forma é possível criar supercomputadores utilizando apenas tecnologias dis-
poníveis para usuários comuns, tornando-os mais acessíveis em termos de custo e 
disponibilidade. Vale lembrar que em sistemas em cluster cada nó executa o mes-
mo sistema operacional.
A situação da computação em grade é diferente, principalmente porque os 
sistemas costumam ser montados como grupos independentes, inclusive com varia-
ção no hardware e software utilizados. Podemos afirmar que em sistemas em grade 
há alta taxa de heterogeneidade. A vantagem desse tipo de sistema distribuído é 
permitir que distintas organizações possam colaborar na execução de aplicações, 
compartilhar os recursos e distribuir a carga de processamento.
Importante!
Que o seu computador ou telefone celular pode ajudar nas pesquisas para a cura de do-
enças como câncer, síndrome da imunodeficiência adquirida (Aids), Zika e tuberculose?
Graças à computação em grade você pode doar um pouco da capacidade de processa-
mento de seu dispositivo para que pesquisas possam ser executadas. 
Você Sabia?
Sistemas de Informação Distribuídos
Os primeiros sistemas distribuídos foram alternativas aos sistemas centralizados. 
Esses pioneiros se baseavam no modelo conhecido como cliente-servidor, onde 
as aplicações ficavam com as suas regras e os seus dados restritos ao(s) servidor(es) 
e este(s) respondia(m) às requisições feitas pelos clientes.
Definiremos cliente como a parte da aplicação onde o usuário efetua as suas interações e 
solicitações, de modo que comumente o lado cliente possuía a interface e o lado servidor as 
regras e o banco de dados. 
Ex
pl
or
O modelo cliente-servidor vigorou durante um período baseado em sistema de 
transações de banco de dados. O sistema transacional tem como característica 
permitir que as transações sejam tratadas de forma atômica, consistente, isolada e 
durável (TANENBAUM; VAN STEEN, 2007).
• Atômica: Pois uma transação não será dividida;
• Consistente: Pois não interfere no sistema;
• Isolada: Uma transação não interfere na outra;
• Durável: Uma transação produz efeito permanente após a sua execução. 
Importante!
Que os comandos utilizados em sistemas gerenciadores de banco de dados Begin, 
Commit e Rollback são formas de aplicar o uso de transações em sistemas de informa-
ção distribuídos? 
Você Sabia?
Sistemas Distribuídos Pervasivos
Os sistemas pervasivos são assim chamados por estarem em todos os lugares ao 
mesmo tempo, tal característica é possível graças ao uso da computação móvel. 
Nessa categoria temos os notebooks, tablets, telefones celulares, relógios e ou-
tros dispositivos inteligentes e/ou vestíveis. Atualmente, tais dispositivos podem 
executar aplicações e fazer chamadas e consultas a servidores e outros clientes sem 
a necessidade de administração central. Esses aparelhos possuem em sua mobili-
dade uma característica distributiva, mas é a capacidade de interagirem entre si que 
torna tal categoria de dispositivos diferente dos modelos anteriores.
Figura 4 – Internet of Things (IoT) é um grande exemplo de sistemas distribuídos pervasivos
Fonte: Getty Images
Veja como funciona a internet das coisas em: https://youtu.be/O8-oiSsZl1Y
Ex
pl
or
Arquiteturas Distribuídas
Quando mencionamos sistemas distribuídos não podemos deixar de abordar a 
arquitetura desses sistemas; afinal, os sistemas distribuídos podem ter diferentes 
tipos de arquitetura, conforme a necessidade do projeto. Por sua vez, a arquitetura 
de um sistema distribuído tem relação com a forma como são organizados e como 
interagem logicamente os componentes de software.
Pode envolver as arquiteturas do software e sistema, que são conceitos diferen-
tes, uma vez que a arquitetura do:
• Software preocupa-se da estrutura e organização dos componentes lógicos – 
serviços, páginas, scripts etc.;
• Sistema é responsável pela estrutura e organização dos componentes físicos – 
servidores, roteadores, terminais etc.
Apesar de serem conceitos diferentes, existe uma relação entre os quais.
Importante!
A arquitetura do sistema sempre dependerá da arquitetura do software.
Importante!
Cada componente é uma unidade modular – hardware ou software – com in-
terfaces requeridas e fornecidas bem definidas. Os componentes geralmente imple-
mentam uma das três seguintes funções em um sistema distribuído:
1. Processamento: oferecem as funcionalidades ou serviços do sistema dis-
tribuído – comportamento; 
2. Estado: mantém informação ou dados do sistema distribuído; 
3. Comunicação: realizam a interconexão com os demais componentes, 
possibilitando a comunicação entre os quais.
Como São Configurados os Componentes Lógicos e Físicos?
Os componentes são configurados em conjunto para formar a arquitetura do 
sistema. Existem basicamente componentes e conectores.
• Componentes: São elementos modulares que integram o sistema de software;
• Conectores: São elementos que estabelecem a comunicação entre os componentes den-
tro da arquitetura. 
Ex
pl
or
O conceito de arquitetura tem relação com a organização da estrutura de um 
sistema de software. Trata-se da estrutura de um sistema, que consiste em compo-
nentes de software, das propriedades externamente visíveis desses componentes 
e dos relacionamentos entre tais componentes, ou seja, da forma de comunicação 
dos componentes de software que compõem o sistema distribuído.
A forma como os componentes são configurados é o que define o estilo arquite-
tural do sistema. Alguns dos estilos possíveis dizem respeito à arquitetura:
• Cliente-servidor;
• De objetos;
• Em camadas;
• Peer to peer.
Desafios das Arquiteturas de Sistemas Distribuídos 
Você deve ter percebido que os sistemas distribuídos possuem uma abrangência 
consideravelmente grande. Notou, então, como temos diversos exemplos de aplica-
ções dos sistemas distribuídos? 
Importante!
Veja quais são os principais desafios na configuração de arquiteturas de sistemas distribuídos.
Importante!
Heterogeneidade
Entenda heterogeneidade como a variedade e diferença dos vários componentes 
que podem fazer parte de uma arquitetura de sistemas distribuídos. Por exemplo, 
um sistema distribuído necessita conseguir lidar com diferentes sistemas operacio-
nais. Uma chamada para a troca de mensagens em Windows é diferente de Linux, 
MacOS ou Android.
Importante!
A solução para esse desafio é a implementação e o uso de uma camada de software deno-
minada middleware. 
Importante!
Middleware será responsável por fazer com que os diferentes sistemas opera-
cionais se comuniquem com a aplicação – você aprenderá mais sobre esse assunto 
durante a Disciplina.
Sistemas Abertos
Os sistemas desenvolvidos a partirde padrões públicos são chamados de sistemas 
distribuídos abertos, demonstrando que podem ser ampliados por novos hardwa-
res, tal como o acréscimo de computadores em uma rede e por softwares, como 
a entrada de novos serviços ou aplicações, permitindo aos programas aplicativos 
compartilharem os seus recursos. Uma vantagem adicional, frequentemente men-
cionada para sistemas abertos, é sua independência de organizações individuais 
(COULOURIS et al., 2013).
Importante!
Por que quanto mais aberto for um sistema, maior será o desafio de implementá-lo 
e gerenciá-lo?
Trocando ideias...
Segurança
Neste ponto você já deve ter compreendido que uma arquitetura de sistemas que 
possui muitos componentes variados – heterogeneidade – e pode ser aberta para 
a entrada de novos componentes – sistemas abertos – será um desafio na questão 
da segurança.
Escalabilidade
Uma arquitetura de sistemas distribuídos poderá variar de tamanho dependendo 
da aplicação executada – desde uma aplicação restrita a uma pequena empresa, ou 
uma aplicação de larga escala global, tal como um serviço de streaming de filmes. 
Aumentar ou diminuir conforme a necessidade da aplicação é o que chamamos 
de sistema escalável, de modo que um bom projeto de arquitetura permitirá essa 
manobra – quando necessária.
Concorrência
Tanto os serviços como aplicativos fornecem recursos que podem ser compar-
tilhados pelos clientes em uma arquitetura de sistema distribuído. Portanto, existe 
a possibilidade de que vários clientes tentem acessar um recurso compartilhado ao 
mesmo tempo. Por exemplo, um banco de dados que registra a venda de ingressos 
para um show pode ser acessado simultaneamente por diversos usuários quando 
as vendas são divulgadas.
O que você deve saber sobre concorrência é que qualquer objeto que represente 
um recurso compartilhado em um sistema distribuído deve garantir que funcione 
corretamente em um ambiente concorrente (COULOURIS et al., 2013).
Importante!
Durante a Disciplina de Arquitetura de Sistemas Distribuídos você conhecerá em de-
talhes tais arquiteturas, analisará as vantagens e desvantagens e reconhecerá aplicações 
que fazem uso dessas arquiteturas.
Bom estudo!
Em Síntese
• Introdução;
• Modelos de Arquitetura;
• Cliente-Servidor;
• Peer-to-Peer.
• Diferenciar os principais modelos de aplicação e contextualizar os mesmos em situa-
ções práticas.
OBJETIVO DE APRENDIZADO
Modelos de Aplicação
Introdução
Na Unidade anterior você aprendeu que um sistema distribuído, em sua defini-
ção mais simples, é um grupo de computadores trabalhando juntos para funcio-
nar como um único computador ao usuário final. Essas máquinas têm um estado 
compartilhado, operam simultaneamente e podem falhar independentemente, sem 
afetar o tempo de atividade de todo o sistema.
Você já entendeu os conceitos básicos de sistemas distribuídos, agora, contudo, 
examinaremos a perspectiva de forma incremental, de modo a conhecer os mode-
los de sistemas distribuídos e, por meio de exemplos de aplicações, enriquecer o 
nosso conhecimento.
Será que todo sistema distribuído pode ser implementado da mesma forma? Ou existem 
diferentes modelos de sistemas distribuídos? Ex
pl
or
Figura 1
Fonte: Getty Images
Ao longo desta Unidade você será capaz de compreender os diferentes modelos 
de arquitetura de um sistema distribuído e relacionar com aplicações existentes em 
seu dia a dia. Além disso, conhecerá o conceito de middleware e as principais solu-
ções existentes para esse importante componente de sistemas distribuídos.
Modelos de Arquitetura
O modelo de arquitetura de um sistema distribuído envolve o posicionamento de 
suas partes e os relacionamentos entre as quais. Cada tipo de modelo é destinado 
a fornecer uma descrição abstrata e simplificada, mas consistente, de um aspecto 
relevante do projeto de um sistema distribuído.
Você deve entender os modelos de arquitetura como as referências para o projeto 
de software, aplicação ou sistema. Então, você poderá concluir que a escolha do 
modelo de arquitetura mais adequado ao seu sistema ou à sua aplicação será aquele 
que conseguir cumprir os atributos de qualidade e atender aos requisitos de software. 
Importante!
Não existe uma “receita” para definir o modelo a ser adotado; o importante é que você 
conheça as diferenças e características dos modelos arquitetônicos. 
Importante!
Quando um sistema de software é projetado, deve garantir que a arquitetura do 
sistema atenda à sua atual e futura demanda em termos de atributos de qualidade 
e requisitos do software.
A ISO/IEC 25010:2011 é uma norma ISO para a qualidade de produto de software, definindo 
um conjunto de parâmetros com o objetivo de padronizar a avaliação da qualidade de software. 
Essa norma substituiu a antiga ISO/IEC 9126.
Ex
pl
or
Figura 2 – Atributos de qualidade de software (ISO/IEC 9126)
Fonte: Wikimedia Commons
Especificação de requisitos de software: uma especificação de requisitos de software é uma 
descrição de um sistema de software a ser desenvolvido. A especificação de requisitos de 
software estabelece requisitos funcionais e não funcionais, podendo incluir um conjun-
to de casos de uso que descrevem as interações do usuário que o software deve fornecer. 
A especificação de requisitos de software estabelece a base para um acordo entre clientes e 
contratados – ou fornecedores – sobre como o produto de software deve funcionar.
Ex
pl
or
Esses modelos de arquitetura apresentam um sistema em função das tarefas e 
dos objetivos computacionais e de comunicação realizados por seus componentes. 
Pense que aqui o foco será a divisão de responsabilidades entre os componentes do 
sistema e a alocação física desses componentes à infraestrutura de rede.
Conceitos Básicos
Rede de Comunicação: um sistema que conecta componentes finais, intermediários e ou-
tros dispositivos que permitem a troca de informações. Uma rede pode ser de qualquer ta-
manho, desde apenas dois componentes a muitos dispositivos;
Componente ou Sistema Intermediário: um dispositivo que opera como um elemento de 
ligação entre dois ou mais componentes finais – por exemplo, roteador, switch, repetidor; 
Componente ou Sistema Final: um dispositivo que utiliza ou fornece aplicação ou serviços 
de rede para usuários finais – por exemplo, uma estação de trabalho, um smartphone, um 
servidor web, um servidor DNS. 
Ex
pl
or
São rotulados como sistemas finais porque ficam nas extremidades de uma 
rede. Os sistemas finais conectados à internet também são chamados de hosts – 
porque podem ser hospedeiros (hosts) de aplicações para a internet.
Pense que os sistemas finais podem ser posicionados em uma rede de maneiras 
diferentes em relação aos outros. Ou seja, podem se comunicar e compartilhar 
recursos de acordo com específicos modelos de interação.
Segundo Coulouris e colaboradores (2013), os modelos de arquitetura podem 
ser classificados em dois estilos básicos de interação: 
• Cliente-servidor – client-server;
• Ponto a ponto – Peer-to-Peer (P2P).
Você verá que atualmente é comum encontrar modelos que são variações ou 
combinações dos dois modelos básicos, vejamos:
Figura 3 – Exemplos de modelo de arquitetura client-server
Figura 4 – Exemplos de modelo de arquitetura peer-to-peer
Importante!
Neste ponto você deve fazer uma relação com outras disciplinas de redes de computado-
res. Os modelos cliente-servidor e P2P operam na camada de aplicação do modelo TCP/IP. 
Trocando ideias...
Figura 5 – Camadas de redes
Você pode verificar um resumo do modelo de camadas de redes, igualmente conhecido 
como modelo OSI. Disponível em: http://bit.ly/326li4cEx
pl
or
Os sistemas cliente-servidor e P2P são implementados como redes virtuais, com 
nós e links lógicos, construídos sobre uma rede existente – comumente a internet 
ou redes locais (LAN).
Essas redes virtuais são chamadas de redes de sobreposição – overlay network.
A sobreposição é uma exibição lógica que pode não refletir diretamente a topologia derede física.
Figura 6 – Rede de sobreposição versus rede física
Os modelos de arquitetura que você aprenderá na sequência são relativos às redes de sobre-
posição – overlay network. Ex
pl
or
Middleware 
Para sustentar computadores e redes variadas e, ao mesmo tempo, oferecer uma 
visão de sistema único, os sistemas distribuídos costumam ser organizados por meio 
de uma camada de software, comumente chamada de middleware (TANENBAUM; 
VAN STEEN, 2007).
A camada de middleware é situada logicamente entre uma camada de nível mais 
alto – composta de aplicações – e uma camada abaixo, que consiste em sistemas ope-
racionais e componentes básicos de comunicação – veja uma ilustração deste conceito:
Figura 7 – Exemplo de camadas entre o middleware
Fonte: Coulouris e colaboradores, 2013
Middleware pode ser entendido como uma camada de software que não é uma 
aplicação propriamente dita e que não faz parte do sistema operacional. Essa ca-
mada esconde detalhes de dispositivos de hardware e software para fornecer uma 
interface mais simples de programar as aplicações.
Middleware: Camada de software que permite a comunicação entre aplicações distribuídas;
Um conjunto de serviços que fornece comunicação de forma transparente à aplicação.E
xp
lo
r
Middleware simplesmente torna mais fácil a construção das aplicações à medida que o de-
senvolvimento pode se focar no propósito específico das aplicações.Ex
pl
or
Figura 8 – Esquema conceitual de interação do middleware com o sistema operacional
Fonte: Silva, 2017
Middleware pode ser definido como os serviços encontrados acima da camada 
de transporte – ou seja, sobre TCP/IP –, mas abaixo da aplicação – logo, abaixo 
das API, no nível do aplicativo.
API: é um conjunto de rotinas e padrões de programação ao acesso a um aplicativo de software. 
A sigla API refere-se ao termo, em inglês, Application Programming Interface – em português, 
interface de programação de aplicativos.
Ex
pl
or
Cliente-Servidor
O modelo cliente-servidor deve ser entendido por meio da divisão das responsabi-
lidades entre os componentes do sistema e de acordo com dois papéis bem definidos:
• Servidores – Servers: responsáveis por gerenciar e controlar o acesso aos 
recursos do sistema; 
 » Têm papéis passivos;
 » Respondem aos seus clientes agindo em cada solicitação e retornando resultados;
 » Geralmente suportam vários clientes.
• Clientes – Clients: são as interfaces por onde os usuários interagem com os 
servidores de modo a terem acesso aos recursos que estes gerenciam.
 » Têm funções ativas e iniciam cada sessão de comunicação enviando solicita-
ções para servidores;
 » Devem ter conhecimento dos servidores disponíveis e serviços que estes fornecem;
 » Comunicam-se apenas com os servidores;
 » Não podem comunicar-se entre si.
Funções de Hardware
Os termos cliente e servidor geralmente se referem às funções primárias desem-
penhadas pelo hardware em rede.
Um cliente geralmente é algo como um computador pessoal (PC), notebook ou 
smartphone utilizado por um indivíduo e de maneira geral inicia conversas envian-
do solicitações.
 
Figura 9 – Exemplos de dispositivos comuns no papel de cliente
Fonte: Getty Images
Um servidor é, geralmente, uma máquina poderosa dedicada a responder a solicita-
ções de clientes; localizado, na maioria das vezes, geograficamente distante do cliente.
Figura 10 – Exemplo de um data center comum no papel de servidor
Fonte: Getty Images
Funções de Software
O TCP/IP utiliza diferentes partes de software para muitos protocolos a fim de 
implementar funções de cliente e servidor. O software do cliente é comumente encon-
trado no hardware do cliente; o software do servidor será encontrado no hardware 
do servidor.
 
Importante!
A regra mencionada não vale para 100% dos casos! Afinal, alguns dispositivos podem 
executar software cliente e servidor ao mesmo tempo – por exemplo, quando você 
desenvolve aplicações e realiza os testes localmente.
Clientes Web: Mozilla Firefox, Internet Explorer, Google Chrome etc.
Servidores Web: Apache, Microsoft IIS, Sun, Google Web Server etc.
Importante!
Veja as estatísticas dos navegadores mais utilizados para acesso ao site da W3Schools.
Disponível em: http://bit.ly/2Nshveh
Veja as estatísticas dos servidores web mais utilizados segundo a pesquisa da Netcraft.
Disponível em: http://bit.ly/2NuG1M1
Ex
pl
or
Camadas Lógicas 
Agora você será apresentado(a) ao conceito de camadas – tiers – de aplicação. 
Uma aplicação cliente-servidor possui, pelo menos, duas camadas lógicas: a camada 
de software que fica no cliente e a camada de software que está no servidor.
Em geral, os sistemas de software são implementados com uma terceira camada, 
representação que damos o nome de modelo em três camadas – 3 logical tiers.
As camadas são partes de software, cada qual responsável por uma tarefa es-
pecífica na aplicação. Essa estratificação é um modelo de referência; na prática, os 
limites podem não ser tão nítidos.
Figura 11 – Representação conceitual do modelo de três camadas
Fonte: Acervo do Conteudista
Importante!
A divisão em camadas lógicas de software não necessita seguir a mesma divisão em ca-
madas físicas do hardware.
Importante!
A camada de apresentação é responsável por exibir as informações e interagir 
com o usuário. Deve disponibilizar as informações de forma adequada e responder 
apropriadamente à entrada do usuário.
Já a camada de aplicação processa comandos, toma decisões lógicas, executa cál-
culos e coordena o sistema; ademais, move e processa dados entre as camadas de apre-
sentação e de dados – é nesta camada que as regras de negócio serão implementadas.
A camada de dados é responsável por gerenciar o banco de dados, ou os 
arquivos utilizados pela aplicação. Nessa camada é comum o uso de um Sistema 
Gerenciador de Banco de Dados (SGBD) – por exemplo, MySQL, Oracle, DB2 etc.
Arquitetura em três camadas é um termo utilizado para descrever as camadas 
físicas do modelo.
Figura 12 – As três camadas físicas
Importante!
Caso você encontre uma aplicação que possui, em sua implementação, mais do que três 
camadas físicas, saiba que são conhecidas como arquiteturas N camadas – multi-tier.
Importante!
A separação em camadas lógicas e físicas torna cada sistema mais flexível, possi-
bilitando que as alterações possam ser realizadas de modo independente. O desem-
penho também pode ser melhorado com a adição de novas camadas físicas para 
balancear o tráfego e dividir o processamento. 
Peer-to-Peer
O modelo Peer-to-Peer (P2P) caracteriza-se pelo fato de os componentes finais 
terem capacidades e responsabilidades equivalentes em qualquer uma das partes, po-
dendo, por exemplo, iniciar uma sessão de comunicação sem a necessidade de um 
servidor. Os participantes de uma rede P2P compartilham uma parte de seus próprios 
recursos de hardware, tais como as capacidades de armazenamento, processamento 
etc. Esses recursos compartilhados são necessários para fornecer o serviço ou conte-
údo oferecido pela rede P2P.
Importante!
Os participantes de uma rede P2P são provedores de recursos e, ao mesmo tempo, soli-
citantes de recursos. 
Importante!
Figura 13 – Um sistema P2P sem uma infraestrutura central
Fonte: Wikimedia Commons
Em redes P2P, os fluxos de dados recebidos e enviados tendem a ser simétricos; 
isso ocorre porque cada host conectado opera simultaneamente como cliente e servi-
dor, recebendo e transmitindo, em média, a mesma quantidade de dados.
Importante!
O modelo P2P não possui a noção de clientes e servidores, pois todos os participantes da 
rede são pares – peers.
Em Síntese
Benefícios e Deficiências 
Benefícios do P2P:
• Não há necessidade de aplicações dedicadas e servidores de banco de dados;
• Aumenta a possibilidade de escalabilidade e confiabilidade, pois não há um 
único ponto de falha.
Deficiências do P2P:
• Mais difícil de implementar políticas de segurança;
• Falta de controle centralizado;
• Computadores com recursos compartilhadostendem a ter desempenho pior 
que servidores dedicados. 
Um exemplo de transmissão de dados via peer-to-peer corresponde aos torrents, 
em que você pode encontrar arquivos compartilhados, inclusive, que possuem di-
reitos autorais. No Brasil, a Lei dos direitos autorais (Art. 105) proíbe qualquer tipo 
de reprodução de conteúdo protegido que não seja autorizado.
Na sua opinião, o fato de as redes P2P permitirem acesso a conteúdo protegido por direitos 
autorais – filmes, músicas, livros, softwares etc. – é uma vantagem ou deficiência? Ex
pl
or
Leia sobre o caso Napster em – http://bit.ly/320QstX
Ex
pl
or
Exemplos de Aplicações do Modelo P2P
• Comunicação: Skype;
• Bases de Dados: DNS, NTP;
• Jogos on-line: Counter Strike, Unreal;
• Compartilhamento: eMule, BitTorrent, Gnutella;
• Computação em grid: WCGrid;
• Content Delivery Networks (CDN): Amazon WS, Azure;
• Redes anônimas: Tor;
• Criptomoedas: Bitcoin, Ether;
• Outros: blockchain, JXTA.
• Introdução;
• Conceitos de Redes;
• Chamadas Remotas;
• Corba;
• Web Services.
• Apresentar as Tecnologias de Comunicação mais utilizadas para Aplicações Distribuídas.
OBJETIVO DE APRENDIZADO
Comunicação em
Sistemas Distribuídos
Introdução
Nesta Unidade, você será apresentado(a) às Tecnologias mais utilizadas na co-
municação para Aplicações Distribuídas. 
Você irá conhecer os conceitos e o funcionamento das soluções existentes para 
implementação de aplicações que se comuniquem por meio de um modelo de ar-
quitetura distribuída.
Atualmente, é comum encontrarmos aplicações que possuam seus recursos de 
software espalhados, fisicamente, em diferentes computadores. Por exemplo, um 
Caixa Eletrônico possui uma parte de software instalado fisicamente no hardware 
do próprio Caixa Eletrônico, porém ele depende de comunicação com um servidor 
que atenda às suas solicitações.
Figura 1
Fonte: Getty Images
Então, pense em uma operação de saque. Essa funcionalidade depende da camada 
de apresentação (telas), que está fisicamente instalada e processa no hardware 
do Caixa Eletrônico.
Quando um cliente interage com as telas e sua senha é solicitada, essa senha pre-
cisa ser validada pelo servidor, pois, por questões de segurança, não se armazena 
o Banco de Dados de senhas localmente em cada Caixa Eletrônico. Então, precisa 
existir um ou mais Protocolos de comunicação que permitam que o Caixa Eletrôni-
co se comunique com o(s) servidor(es) e solicite a validação da senha.
O servidor irá processar a solicitação e devolver o resultado para o Caixa Ele-
trônico (neste caso, no papel de cliente). Se a senha estiver correta, permite-se que 
a operação de senha prossiga; caso contrário, uma mensagem informativa será 
exibida na tela do Caixa Eletrônico e a operação se encerra.
Como aplicações em Computadores com Sistemas Operacionais e hardwares heterogêneos 
conseguem comunicar-se?Ex
pl
or
E se você estivesse em uma situação na qual pre-
cisa falar com outra pessoa que não entende o idio-
ma Português – digamos que ela só fale Alemão e 
você só fale Português, mas um amigo em comum 
compreende os dois idiomas?
A solução mais simples parece ser pedir ao amigo 
em comum que faça a tradução para vocês. Bem, 
de certo modo, as Tecnologias que estudaremos a 
seguir são Protocolos que irão realizar a função de 
tradutor para as aplicações de softwares que preci-
sam estabelecer uma Comunicação.
Conceitos de Redes
Quando você pensar em Sistemas Distribuídos, é importante que tenha em 
mente que a comunicação é a chave para esse tipo de Sistema.
O processamento, memória e demais recursos computacionais utilizados pelas 
Aplicações Distribuídas estão “espalhados”, sendo que a comunicação entre eles 
permite que troquem informações e compartilhem recursos.
Antes de iniciar o entendimento das tecnologias que permitem que as aplicações 
sejam implementadas sob uma arquitetura ou modelo distribuído, você precisa re-
cordar alguns conceitos fundamentais de Comunicação de Redes de Computadores.
Redes de Computadores
A Comunicação de Rede, ou Interligação de Rede, define um conjunto de Pro-
tocolos (isto é, regras e padrões) que permitem que os Programas de Aplicativos 
conversem entre si sem considerar o hardware e os sistemas operacionais em que 
são executados. A Comunicação de Rede permite que os programas aplicativos se 
comuniquem independentemente de suas conexões físicas de Rede.
A tecnologia de interligação de Redes, denominada TCP/IP, recebe o nome de seus 
dois principais Protocolos: TCP (Transmission Control Protocol) e IP (Internet Protocol). 
Para entender o TCP/IP, você deve estar familiarizado com os seguintes termos:
• Host: é um computador ou outro dispositivo conectado a uma Rede;
• Cliente: um processo que solicita serviços na Rede;
Figura 2
Fonte: Getty Images
• Servidor: um processo que responde a uma solicitação de serviço de um cliente;
• Datagrama: unidade básica de informações, consistindo de um ou mais paco-
tes de dados, que são transmitidos pela Internet no nível de transporte;
• Pacote: Unidade ou Bloco de uma transação de dados entre um computador e 
sua Rede. Um pacote, geralmente, contém um cabeçalho de Rede, pelo menos 
um cabeçalho de Protocolo de alto nível e blocos de dados. Geralmente, o for-
mato dos Blocos de Dados não afeta o modo como os pacotes são manipulados. 
Pacotes são o meio de troca usado 
na camada comunicação de Rede.
Protocolos
Um Protocolo é um conjunto de regras ou padrões que cada host deve seguir para 
permitir que outros hosts recebam e interpretem mensagens enviadas para eles.
Existem dois tipos gerais de Protocolos de transporte, apresentados a seguir.
Protocolo não orientado à conexão
Um Protocolo não orientado à conexão é um Protocolo que trata cada datagrama
como independente de todos os outros. Cada datagrama deve conter todas as in-
formações necessárias para sua entrega. Um exemplo de tal Protocolo é o User 
Datagram Protocol (UDP). 
O UDP é um Protocolo da camada de transporte criado diretamente na camada 
IP e usado para envio de um datagrama diretamente de uma aplicação para aplica-
ção que estejam em hosts baseados em TCP/IP. 
O UDP não garante a entrega de dados e, portanto, é considerado não confiável. 
Aplicações que exigem entrega confiável de fluxos de dados devem usar o TCP. 
Protocolo orientado à conexão
Um Protocolo orientado à conexão requer que os hosts estabeleçam uma co-
nexão lógica entre si antes que a comunicação possa ocorrer. Uma troca orientada 
por conexão inclui três fases: 
• Iniciar a conexão;
• Transferir dados;
• Finalizar a conexão.
Um exemplo de um Protocolo desse tipo é o Transmission Control Protocol (TCP). 
O TCP fornece um meio confiável para a entrega de pacotes entre hosts em 
uma Internet. TCP divide um fluxo de dados em datagramas, envia cada um
individualmente usando IP e remonta os datagramas no nó de destino. Se algum 
datagrama for perdido ou danificado durante a transmissão, o TCP detecta isso e 
retransmite os datagramas ausentes. O fluxo de dados recebido é, portanto, uma 
cópia confiável do original.
A Internet e a Web funcionam graças ao TCP. Ele é complementado pelo Internet 
Protocol (IP), sendo normalmente chamado de TCP/IP. O TCP é um Protocolo da 
Camada de Transporte e muitas Aplicações Distribuídas são implementadas com o 
uso do TCP.
Portas TCP/IP e Soquetes
Em uma Rede TCP/IP, todos os dispositivos devem ter um endereço IP. O en-
dereço IP identifica o dispositivo, por exemplo, o computador. No entanto, um 
endereço IP sozinho não é suficiente para executar aplicativos de Rede, pois um 
computador pode executar vários aplicativos e ou serviços. Assim como o endereço 
IP identifica o computador, a porta de Rede identifica o aplicativo ou o serviço em 
execução no computador.
O uso de portas permite que os 
Computadores/Dispositivos execu-
tem vários serviços / aplicativos.
Se você usar uma analogia de um prédio de apartamentos, o endereço IP cor-
responde ao endereço da rua. Todos os apartamentoscompartilham o mesmo en-
dereço. No entanto, cada apartamento também tem um número que corresponde 
ao número da porta.
Soquete
Um soquete é a combinação de endereço IP mais porta utilizada em uma cone-
xão entre dois computadores. Com um soquete, é possível identificar unicamente 
um aplicativo na Rede de comunicação IP.
Chamadas Remotas
RPC
RPC (Remote Procedure Call) ou Chamada de Procedimento Remoto define 
um Protocolo que permite que um Programa solicite a execução de uma rotina de 
outro programa por meio de uma Rede de Computadores. 
Além de permitir que seja executado uma rotina que se encontra em outro 
computador, um servidor, por exemplo, o programador não precisa codificar em
detalhes como essa comunicação deve ocorrer, pois esses detalhes ficam encapsu-
lados pelo próprio Protocolo RPC.
O Protocolo RPC pode ser implementado sobre diferentes Protocolos de trans-
porte. Não cabe ao RPC especificar como a mensagem é enviada de um processo 
para outro, mas somente especificá-la e interpretá-la. A sua implementação depen-
de, portanto, de sobre qual Protocolo de Transporte vai operar.
Uma chamada de procedimento remoto é uma técnica de comunicação entre 
processos utilizada para aplicativos baseados em cliente/servidor. Também é co-
nhecido como chamada de sub-rotina ou chamada de função.
Um cliente tem uma mensagem de solicitação que o RPC traduz e envia para o 
servidor. Essa solicitação pode ser um procedimento ou uma chamada de função 
para um servidor remoto. Quando o servidor recebe a solicitação, ele envia a res-
posta necessária de volta para o cliente.
A sequência de eventos em uma chamada de procedimento remoto acontece da 
seguinte maneira:
• A aplicação do cliente efetua uma chamada remota;
• O RPC do cliente se encarrega de enviar a mensagem ao servidor e coloca os 
parâmetros na mensagem;
• A mensagem é enviada do cliente para o servidor pelo Sistema Operacional 
do cliente;
• O Sistema Operacional do servidor recebe e repassa a mensagem para o RPC 
do servidor;
• Os parâmetros são removidos da mensagem pelo RPC do servidor;
• Em seguida, a rotina da aplicação do servidor é chamada pelo RPC do servidor.
Figura 3 – Esquema de funcionamento de uma chamada remota com RPC
Fonte: Acervo do Conteudista
Vantagens
Algumas das vantagens do RPC são as seguintes:
• Suportam modelos orientados a processos e orientados a threads;
• O mecanismo interno de passagem de mensagens do RPC está oculto para o usuário;
• Pouco esforço é necessário para escrever o código em RPC;
• Podem ser usadas no ambiente distribuído, bem como no ambiente local.
Desvantagens
Algumas das desvantagens do RPC são as seguintes:
• A chamada de procedimento remoto é um conceito que pode ser implementado
de diferentes maneiras. Não é um padrão;
• Não há flexibilidade no RPC para arquitetura de hardware;
• Há um aumento nos custos de processamento;
• As RPCs são nomeadas por meio de interfaces. Uma interface descreve e 
identifica exclusivamente uma rotina específica, informando seus parâmetros e 
tipos de argumentos. Dessa forma, o cliente precisa conhecer a interface antes 
de usá-la.
RMI
O RMI (Remote Method Invocation) é uma Tecnologia suportada pela platafor-
ma Java que auxilia o desenvolvimento de Aplicações Distribuídas. O RMI permite 
ao programador chamar métodos de objetos remotos, ou seja, que estão alocados 
em Máquinas Virtuais Java (JVM), distintas sem necessidade de codificação de 
detalhes de comunicação de Rede, tornando o processo muito semelhante às invo-
cações de objetos locais (mesma JVM).
Importante!
RMI é uma interface de programação que permite a execução de chamadas remotas no 
estilo RPC, porém o RPC é para Linguagens Procedurais e o RMI é para Linguagem Java 
e orientado a objetos.
Importante!
Figura 4 – Arquitetura de uma aplicação cliente/servidor com RMI
Fonte: Acervo do Conteudista
Veja a explicação de cada componente separadamente:
• Transport Layer: Esta camada conecta o cliente e o servidor. Ela gerencia a 
conexão existente e configura novas conexões;
• Stub: Um stub é uma representação (proxy) do objeto remoto no cliente. 
Ele reside no Sistema do cliente e age como um gateway para o programa cliente;
• Skeleton: Este é o objeto que reside no lado do servidor. O stub se comunica 
com o skeleton para passar a solicitação para o objeto remoto;
• RRL (Remote Reference Layer): É a camada que gerencia as referências 
feitas pelo cliente para o objeto remoto.
Corba
O CORBA (Common Object Request Broker Architecture) é um padrão pro-
posto pelo OMG (Object Management Group), em 1991. É um consórcio de mais 
de 800 Empresas que trabalham em um padrão independente de Plataforma e 
Linguagem para Programação Distribuída. 
CORBA não é uma Linguagem de Programação, nem é uma ferramenta de 
software. É uma especificação para integrar componentes de aplicativos distribuí-
dos. Ele define os métodos padrão para acessar objetos remotos e para comuni-
cação entre eles, independentemente do Sistema Operacional ou da Linguagem 
de Programação.
Um Sistema baseado em CORBA é um conjunto de objetos que separam servi-
dores de clientes com uma interface de programador bem definida.
Eles fornecem vários serviços, como localizar um servidor pelo nome e facilitar a 
comunicação entre um servidor e um cliente, incluindo a passagem de argumentos 
para os métodos e obter resultados de suas chamadas remotas.
Uma implementação específica do ambiente CORBA, bem como objetos 
que fornecem serviços e clientes, pode ser feita em uma das várias linguagens 
de programação. Para garantir sua interoperabilidade, eles devem estar em 
conformidade com a especificação definida na Linguagem específica e universal – 
o IDL (Interface Definition Language).
A especificação é usada para gerar vários arquivos de origem na Linguagem de 
Programação de destino, usada para implementar objetos CORBA.
Existem várias implementações do ambiente CORBA disponíveis no Mercado. 
Eles são mais ou menos compatíveis devido às diferenças nas versões da especifica-
ção CORBA. O Java SDK forneceu essa implementação desde a versão 1.3.
O ORB (Object Request Broker) é uma parte fundamental da implementação 
do CORBA.
É um software projetado para garantir a comunicação entre objetos na Rede. 
Em particular, permite a localização de objetos remotos, passando argumentos 
para métodos e retornando os resultados de chamadas remotas. Pode redirecionar 
uma solicitação para outro agente do ORB. 
O CORBA define regras gerais para a comunicação entre agentes de maneira 
independente da Linguagem, já que todos os Protocolos são definidos na Lingua-
gem IDL.
Figura 5 – Um cliente envia uma solicitação para um servidor através da ORB
Fonte: Acervo do Conteudista
Importante!
Existem Tecnologias que podem ser utilizadas como alternativa ao CORBA.
Você Sabia?
 
A troca de mensagens via sockets ou utilizando RPC, RMI que possui uma res-
trição de Linguagem de implementação com Java e o DCOM que, basicamente, é 
a implementação CORBA da Microsoft.
Importante!
Quais as vantagens de CORBA em relação a abordagens mais tradicionais, como sockets 
e RPC?
Em Síntese
A comunicação em Sistemas distribuídos através de sockets ou mesmo de RPC 
é feita de forma não padronizada, sem flexibilidade na hora do endereçamento de 
objetos e de referências no servidor.
Já o CORBA disponibiliza meios de endereçamento transparentes e exatos, tor-
nando o trabalho do programador da aplicação mais simples. 
Além disso, CORBA utiliza entidades intermediárias para a comunicação dos 
seus stubs, ao contrário dos métodos tradicionais, que não possuem uma facilidade 
deste tipo.
DCOM
DCOM (Distributed Component Object Model) é a solução da Microsoft para 
computação distribuída. Ele permite que um aplicativo cliente inicie remotamente 
um objeto de servidor DCOM em outra máquina e invoque seus métodos. Então, 
funcionalmente, é semelhante ao CORBA e ao RMI. No entanto, diferentemente 
do RMI, que é dependente de Java,o DCOM é independente de Linguagem e da 
Plataforma – assim como o CORBA. 
A principal diferença entre o DCOM e o CORBA está na implementação. 
O DCOM é um padrão binário, enquanto o CORBA é apenas uma especificação: 
ele define as interfaces de como os clientes podem usar os objetos, mas não define 
a própria implementação.
Assim, diferentes fornecedores estão livres para implementar ORBs CORBA de 
muitas maneiras diferentes, o que torna o CORBA possivelmente mais flexível. 
Só porque o DCOM é um padrão binário, no entanto, não significa que não seja 
independente de plataforma. Porém o alvo do DCOM continua sendo as aplicações 
que estão sob o Sistema Operacional da Microsoft, o Windows.
CORBA x DCOM
• DCOM é um padrão binário e CORBA é uma especificação. As IDLs
são incompatíveis;
• DCOM IDL não oferece suporte a exceções, enquanto CORBA IDL oferece;
• DCOM somente permite herança de interface, enquanto CORBA permite he-
rança de implementação;
• Ambas suportam invocação de interface estática e dinâmica;
• O DCOM visa, principalmente, a PCs com soluções corporativas sendo secun-
dário, enquanto o CORBA é exatamente o oposto.
Web Services
Web Service é uma solução utilizada na integração de sistemas e na comunica-
ção entre aplicações diferentes. Web Service é baseado em padrões abertos (XML, 
SOAP, HTTP etc.) que interagem com outros aplicativos da Web com o objetivo de 
trocar dados. 
O padrão Web Service é mantido pela W3C (World Wide Web Consortium).
Um Web Service é uma entidade de software independente de Linguagem, 
baseada em padrões, que aceita solicitações formatadas de outras entidades de 
software em máquinas remotas por meio de Protocolos de comunicação e utiliza 
Protocolos neutros, sem um proprietário ou fornecedor.
Figur a 6 – Exemplo de um sistema Web Service
Fonte: Acervo do Conteudista
Na Figura acima, você pode perceber que temos uma aplicação que necessita 
realizar uma solicitação para o servidor. 
Em outras Aplicações Distribuídas, seria necessário conhecer em detalhes todo o 
formato da interface do retorno da comunicação, porém, com Web Services, os da-
dos serão comunicados por meio do formato XML (Extensible Markup Language), 
que facilita a troca de informações entre aplicações, pois é autodocumentado, o pró-
prio formato descreve a sua estrutura e nomes de campos, assim como valores válidos. 
Um Web Service pode se comunicar com outros serviços expostos ou se comu-
nicar com uma aplicação servidora (back-end) para transações com SGBD (Siste-
mas Gerenciadores de Banco de Dados).
Importante!
O XML (eXtensible Markup Language) é uma recomendação do W3C para a criação de Lin-
guagens de Marcação que permitem a estruturação, a descrição e o intercâmbio de dados.
Importante!
Benefícios 
• Fracamente acoplado: cada serviço existe independentemente dos outros 
serviços que compõem o aplicativo. Partes individuais do aplicativo podem ser 
modificadas sem afetar áreas não relacionadas;
• Facilidade de integração: permitem trocar dados entre Organizações e De-
partamentos, sem necessidade de unificar a plataforma de software (Sistemas 
Operacionais, Linguagens ou Banco de Dados);
• Reutilização de código: um serviço é codificado e pode ser usado repetida-
mente por vários aplicativos diferentes.
• Introdução;
• Sistemas de Arquivos;
• Sistemas de Arquivos Distribuídos;
• Clusters;
• Google File System.
• Compreender o funcionamento de sistemas de arquivos distribuídos e os conceitos de 
cluster, exempli� cando com o estudo de caso do Google File System.
OBJETIVO DE APRENDIZADO
Sistemas de Arquivos
Distribuídos e Clusters
Introdução
Por isso, você irá conhecer os Sistemas de Arquivos Distribuídos, que permi-
tem que dados sejam compartilhados e acessados mesmo estando distribuídos em 
múltiplos discos, em computadores diferentes, através de uma rede de computadores.
Convido você a refletir sobre o fato de que, para os sistemas distribuídos, compartilhar dados 
é fundamental.Ex
pl
or
Figura 1
Fonte: Getty Images
Sistemas de Arquivos
Os sistemas de arquivos foram originalmente desenvolvidos como um recurso do 
sistema operacional que implementa uma interface de programação para armaze-
namento e recuperação de arquivos armazenados em memória secundária (disco, 
fita, CD, pen drive etc.).
Os sistemas de arquivos são responsáveis por: organização, armazenamento, 
recuperação, atribuição de nomes, compartilhamento e proteção de arquivos.
Projetados para armazenar e gerenciar muitos arquivos, com recursos para cria-
ção, atribuição de nomes e exclusão de arquivos.
Vídeo aula sobre Introdução ao sistema de arquivos: https://youtu.be/PKox6AlVTT8.
Ex
pl
or
Atributos de Arquivo
Um arquivo possui certos atributos que variam de um sistema operacional para 
o outro, mas que normalmente são os seguintes:
Tabela 1 – Exemplos de atributos de um arquivo
Nome
Tamanho do arquivo
Data e hora de criação
Data e hora de acesso 
Data e hora de modificação
Tipo
Atributos (somente leitura, oculto, arquivo de sistema)
Proprietário
Os sistemas de arquivos geralmente possuem diretórios (também chamados de 
pastas), que permitem ao usuário agrupar arquivos em coleções separadas. Um 
diretório pode conter outros diretórios e agrupar vários arquivos, auxiliando na 
organização dos dados que serão armazenados.
Figura 2 – Listagem de diretórios em linha de comando do Windows
Caminho (path) de Arquivo
O caminho (path) de um arquivo é definido pela forma geral do nome de um 
arquivo ou diretório e determina a localização única em um sistema de arquivos. 
Um caminho aponta para uma localização do sistema de arquivo seguindo a hie-
rarquia de árvore de diretórios expressada em uma cadeia de caracteres na qual, os 
componentes do caminho, separados por um caractere delimitador, representam 
cada diretório.
Todo arquivo armazenado em um sistema de arquivos possui um nome e um 
caminho que o identifica unicamente em tal sistema. Um caminho representa uma 
estrutura de diretórios, que pode ser representada como uma árvore.
Tal árvore possui uma raiz, e cada nó pode possuir mais árvores ou arquivos. 
Dessa forma, para localizar um arquivo em uma árvore de diretórios (usados para 
agrupar arquivos) basta seguir o caminho do arquivo e, ao chegar ao diretório final, 
procurar pelo nome de tal arquivo.
Disco C:/
Carlos Ivan Paulo
Teste Pessoal Programas
Soma.exe
Figura 3 – Caminho de arquivo
Exemplo de caminho de arquivo em sistema operacional da família do Microsoft 
Windows:
�������������������������������������������������
Exemplo de caminho de arquivo em sistema operacional da família do Unix/
Linux:
���P������P��W���P�������3��W���������P��
São muito semelhantes, basicamente, com a diferença do uso da “\” ou “/” 
como separador de diretórios.
Sistemas Operacionais e Sistemas de Arquivos
Existe uma relação entre o sistema operacional e a forma como esses sistemas 
gerenciam os arquivos e diretórios. Muitos sistemas operacionais incluem suporte 
para mais de um sistema de arquivos, mas, em muitos casos, o sistema operacional 
e o sistema de arquivos estão ligados de acordo com a implementação do núcleo do 
sistema operacional, tornando difícil a tarefa de separá-los.
Veja no quadro abaixo os sistemas de arquivos suportados por cada um dos sis-
temas operacionais:
Tabela 2
Sistema operacional Tipos de sistema de arquivos suportados
Dos FAT16
Windows 95 FAT16
Windows 95 OSR2 FAT16, FAT32
Windows 98 FAT16, FAT32
Windows NT4 FAT, NTFS (versão 4)
Windows 2000/XP FAT, FAT16, FAT32, NTFS (versões 4 e 5)
Linux Ext2, Ext3, ReiserFS, Linux Swap (FAT16, FAT32, NTFS)
MacOS HFS (Hierarchical File System), MFS (Macintosh File System)
OS/2 HPFS (High Performance File System)
SGI IRIX XFS
FreeBSD, OpenBSD UFS (Unix File System)
Sun Solaris UFS (Unix File System)
IBM AIX JFS (Journaled File System)
Fonte: CCM, 2017
Sistemas de Arquivos Distribuídos
Os Sistemas de Arquivos Distribuídos são necessários para a implementação 
de aplicaçõesdistribuídas. Esses sistemas permitem que os dados sejam comparti-
lhados e fiquem acessíveis de qualquer computador conectado à rede de maneira 
segura e confiável.
Segundo Coulouris et al. (2013), os sistemas de arquivos foram originalmente 
desenvolvidos para sistemas de computadores centralizados ou desktop. 
Posteriormente, adquiriram atributos como controle de acesso e mecanismos de 
proteção de arquivos. Os Sistemas de Arquivos Distribuídos permitem o compar-
tilhamento de informações através de recursos de hardware e software. Quando 
bem projetado, um sistema de arquivo dá acesso a arquivos armazenados em um 
servidor com desempenho e confiabilidade semelhantes aos arquivos armazenados 
em discos locais.
Vejamos um estudo de caso do Networking File System (NFS).
Networking File System (NFS)
O Networking File System (NFS) foi projetado para ser um sistema de arquivos 
distribuído e transparente no acesso aos arquivos em rede. Foi o primeiro Sistema 
de Arquivos Distribuídos, inicialmente, utilizado apenas em ambiente UNIX. 
O NFS, desenvolvido inicialmente pela Sun Microsystems, é o Sistema de Ar-
quivos Distribuídos mais utilizado em sistemas Unix. Em 1985, a Sun tornou pú-
blico o protocolo do NFS, o que permitiu que outras empresas e desenvolvedores 
pudessem criar clientes e servidores NFS. Hoje em dia, já é possível encontrar 
implementações do NFS (tanto cliente como servidor) para quase todos os sistemas 
operacionais existentes, inclusive sistemas não UNIX, como o Windows. Isso tam-
bém foi facilitado pelo fato de o NFS definir uma interface RPC (Remote Procedure 
Call) que utiliza uma representação de dados independente da máquina chamada.
Cliente Servidor
Camada de chamada
de sistema
Camada de sistema
de arquivo virtual (VFS)
Interface de sistema
de arquivo local
Interface de sistema
de arquivo local
Apêndice de
cliente RPC
Camada de chamada
de sistema
Camada de sistema
de arquivo virtual (VFS)
Servidor NFS Interface de sistemade arquivo local
Apêndice de
servidor RPC
Figura 4 – Arquitetura básica do NFS
Um cliente acessa o sistema de arquivos usando as chamadas de sistema do 
sistema operacional local. A camada de sistema de arquivos virtual se encarrega de 
chamar a interface de sistema de arquivos local, ou, no caso de um arquivo locali-
zado em um dispositivo remoto, o NFS irá realizar uma chamada de procedimento 
remoto ao dispositivo que está atuando como servidor do arquivo desejado.
A vantagem do NFS é a possibilidade de tornar compatível o compartilhamento 
de arquivos independentemente do tipo de sistema de arquivos locais.
Network
File system
File system
NSF client
NSF client
NSF server File system
Figura 5 – A arquitetura cliente/servidor do NFS 
O NFS segue o modelo computacional cliente/servidor. O servidor implementa 
o sistema de arquivos e o armazenamento compartilhados aos quais os clientes se 
conectam. Os clientes implementam a interface com o usuário para o sistema de 
arquivo compartilhado, disposto no espaço no arquivo do cliente.
Clusters
Um cluster de computador é um conjunto de computadores conectados que 
trabalham juntos para que, em muitos aspectos, possam ser vistos como um único 
sistema. Ao contrário dos computadores de grade, os clusters de computadores 
têm cada nó configurado para executar a mesma tarefa, controlada e programada 
pelo software.
Os componentes de um cluster são normalmente conectados uns aos outros 
através de redes locais rápidas, com cada nó executando sua própria instância de 
um sistema operacional. Na maioria das implementações, todos os nós utilizam o 
mesmo hardware e o mesmo sistema operacional.
Geralmente, os clusters são implantados para melhorar o desempenho e a 
disponibilidade em relação a um único supercomputador, sendo normalmente mui-
to mais econômicos do que os computadores individuais com velocidade ou dispo-
nibilidade comparáveis ou até mesmo superiores.
Os clusters de computadores surgiram como resultado da convergência de 
várias tendências de computação, incluindo a disponibilidade de microprocessa-
dores de baixo custo, redes de alta velocidade e software para computação distri-
buída de alto desempenho.
É possível montar um cluster caseiro sem gastar milhares de dólares?
Em: https://youtu.be/bbUyLibNQ8M. E
xp
lo
r
Sistemas de Arquivos Distribuídos em Cluster 
Um sistema de arquivos em cluster é um sistema de arquivos que é comparti-
lhado simultaneamente em vários servidores. Os sistemas de arquivos em cluster 
podem fornecer recursos como endereçamento e redundância independentes de 
local, que melhoram a confiabilidade ou reduzem a complexidade das outras partes 
do cluster. Os sistemas de arquivos paralelos são um tipo de sistema de arquivos em 
cluster que distribui dados entre vários nós de armazenamento, geralmente para 
redundância ou desempenho.
Considerações no Projeto de Clusters
Evitando um Único Ponto de Falha
A falha de um disco ou de um determinado nó de armazenamento em um cluster 
pode criar um ponto único de falha que pode resultar em perda ou indisponibili-
dade de dados. A tolerância a falhas e a alta disponibilidade podem ser fornecidas 
por meio de replicação de dados e, assim, em caso de falha em um disco ou nó, os 
dados estarão intactos e disponíveis.
Desempenho
Uma medida de desempenho comum de um sistema de arquivos em cluster é a 
quantidade de tempo necessária para atender às solicitações de serviços. Nos sis-
temas convencionais, esse tempo consiste em um tempo de acesso ao disco e uma 
pequena quantidade de tempo de processamento da CPU. Mas, em um sistema 
de arquivos em cluster, um acesso remoto possui sobrecarga adicional devido à 
estrutura distribuída. Isso inclui o tempo para entregar a solicitação a um servidor, 
o tempo para entregar a resposta ao cliente e uma sobrecarga de CPU da execução 
do software de protocolo de comunicação.
Importante!
Em clusters, é comum o processamento paralelo para evitar perda de desempenho.
Importante!
Concorrência
O controle de concorrência torna-se um problema quando mais de uma pessoa 
ou cliente está acessando o mesmo arquivo ou bloco e deseja atualizá-lo. Portan-
to, as atualizações no arquivo de um cliente não devem interferir no acesso e nas 
atualizações de outros clientes. Esse problema geralmente é tratado pelo controle 
de concorrência ou bloqueio, que pode ser incorporado no sistema de arquivos ou 
fornecido por um protocolo de complemento.
Google File System
Um dos motivos é o desempenho do sistema de arquivos. O Google criou um 
sistema de arquivos distribuído próprio para atender à sua enorme demanda de 
armazenamento, conhecido como Google File System (GFS).
Como o Google consegue dominar o mercado de mecanismos de busca?
Ex
pl
or
O Google não lançou o GFS como software de código aberto, mas divulgou alguns detalhes técnicos, 
incluindo um documento oficial. Você pode conferir o documento neste link: http://bit.ly/2IwyeaO.Ex
pl
or
Existem duas diferenças principais entre o GFS e o sistema tradicional de ar-
quivos distribuídos. Primeiro, as falhas dos componentes são a norma, e não a 
exceção. As falhas podem ser causadas por erros de aplicativos, bugs do sistema 
operacional, erros humanos, e até mesmo problemas de hardware ou de rede. Uma 
vez que até mesmo o disco rígido não pode excluir completamente todas as falhas, 
o Google simplesmente constrói sua máquina de armazenamento contra falhas por 
meio de monitoramento constante, detecção de erros, tolerância a falhas e recupe-
ração automática do GFS.
Em segundo lugar, a maioria dos arquivos sofre mutação ao anexar novos dados 
em vez de sobrescrever ou remover dados existentes. Uma vez escritos, os dados 
geralmente precisam ser apenas “lidos”, mas não “escritos”. E a maioria das opera-
ções de leitura são de grandes quantidades de dados, as operações geralmente leem 
centenas de KBs, mais comumente 1 MB ou mais.
O GFS armazena arquivos grandes, cada arquivo com aproximadamente 100 MB ou 
mais de tamanho.O GFS suporta arquivos pequenos, mas não é otimizado para eles.
A arquitetura do GFS é semelhante à abordagem de nós mestres (master) e nós 
distribuídos (chunkservers). Os dados reais serão armazenados em chunkservers, 
que informam seu estado ao mestre periodicamente. Quando um cliente deseja 
ler um arquivo, ele consulta o mestre sobre o estado do chunkserver de destino e 
recebe a localização do chunkserver.
Figura 6 – Arquitetura do Google File System
Fonte: Wikimedia Commons
O GFS suporta o grande volume e os fluxos do mecanismo de pesquisa do Goo-
gle. Por outro lado, o BigTable, um sistema de banco de dados usado por vários 
aplicativos do Google, como o Gmail, o Google Maps, o YouTube e outros serviços 
em nuvem, também foi desenvolvido com base no GFS. Podemos dizer que o GFS é 
a tecnologia que suporta toda a geração de apps em nuvem do Google (LEE, 2011).