Arquitetura de sistemas distribuidos

Prévia do material em texto

- -1
ARQUITETURA DE SISTEMAS 
DISTRIBUÍDOS
EVOLUÇÃO DA COMPUTAÇÃO E 
INTRODUÇÃO AOS SISTEMAS 
DISTRIBUÍDOS
- -2
Olá!
Objetivo desta aula
Ao final desta aula, o aluno será capaz de:
1- Entender as características da computação centralizada e da computação distribuida;
2- Conhecer as vantagens e desvantagens de cada arquitetura e a motivação para esta evolução
3- Identificar o conceito de sistemas distribuídos.
Introdução
O profissional da área de tecnologia da informação atua diretamente no planejamento, na implementação e na
implantação de soluções de TI nas organizações. Dessa forma, é importante que compreenda os conceitos, os
benefícios, as características e as restrições de cada arquitetura. Nesta aula abordaremos esses tópicos, com
alguns exemplos.
1 Histórico
Primeiros computadores: grandes e caros.
Anos 50-60: spooling, multiprogramação.
Início dos anos 60: sistemas time sharing.
Final dos anos 60 e início dos anos 70: surgimento de redes de computadores.
A partir dos anos 70: inicia-se a pesquisa em sistemas distribuídos.
Desde seu início, a indústria de computadores tem se voltado para uma pesquisa interminável, em busca de
ampliar, cada vez mais, seu poder no âmbito computacional. O Eniac podia executar 300 operações por segundo,
sendo, tranquilamente, mil vezes mais rápido do que qualquer calculadora anterior a ele, e, mesmo assim, as
pessoas ainda não estavam satisfeitas. Hoje temos máquinas um milhão de vezes mais rápidas do que o Eniac e,
contudo, existe demanda para um poder computacional maior.
Não importa quanto poder computacional exista: ele nunca será suficiente.
No passado, a solução era fazer com que o relógio do processador fosse executado mais rápido (overclocking).
Infelizmente, estamos começando a atingir alguns limites fundamentais na frequência do clock. De acordo com a
teoria da relatividade de Einstein, nenhum sinal elétrico pode propagar mais rápido do que a velocidade da luz.
Construir computadores com tamanho reduzido pode ser possível, mas, logo surge outro problema fundamental:
a dissipação de calor. Quanto maior a frequência do relógio do processador, maior será a produção de calor
- -3
produzida por ele; e quanto menor o computador, maiores serão os problemas associados à dissipação desse
calor.
Uma maneira de aumentar a velocidade é fazer uso de computadores altamente paralelos. Essas máquinas são
construídas com muitas CPUs (unidade central de processamento), objetivando processar, coletivamente, com
muito mais poder computacional do que com apenas uma única CPU.
Por outro lado, com a evolução da internet, podemos analisar que um sistema com centenas de computadores
espalhados pelo mundo não difere de um sistema de centenas de computadores em uma única sala, embora a
latência e outras características técnicas sejam diferentes.
Neste contexto, colocar uma quantidade representativa de computadores em uma sala é até fácil, desde que se
tenham recursos financeiros, espaço físico e uma infraestrutura mínima. O espaço deixará de ser um problema,
se esses computadores estiverem espalhados ao redor do mundo. A preocupação surge quando queremos que
eles se comuniquem uns com os outros para trabalhar em conjunto na solução de um único problema.
Os sistemas com múltiplos processadores caracterizam-se por possuir mais de uma CPU, interligadas,
trabalhando em conjunto. Múltiplos processadores podem ser utilizados, simultaneamente, por diversos
processos diferentes, e, com eles, novos problemas de concorrência são introduzidos, porque vários processos
podem querer acessar um dispositivo ao mesmo tempo.
Esses sistemas podem ser divididos em:
Fortemente acoplados - quando os processadores compartilham uma mesma memória principal.
Fracamente acoplados – os diversos processadores/estações presentes no sistema utilizam sua memória local
individualmente.
Sistemas centralizados - Multiprocessador de memória compartilhada é um sistema de computador no qual
duas ou mais CPUs compartilham acesso total a uma memória principal comum. Multiprocessadores são
populares e atrativos, porque oferecem um modelo de comunicação simples, e a sincronização é possível
mediante o emprego de diversas técnicas bem definidas. Uma desvantagem é que os multiprocessadores de
grande porte são difíceis de construir e, por isso, são caros.
Sistemas distribuídos - Uma solução alternativa que tem sido empregada com sucesso para solucionar esse
problema é a utilização de multicomputadores, que são CPUs que não compartilham memória principal. Cada
CPU tem sua própria memória e é gerenciada por um sistema operacional individualmente. Esses sistemas
também são conhecidos como cluster – COWS (cluster of workstations - aglomerados de estações de trabalho).
- -4
2 POR QUE COMPUTAÇÃO DISTRIBUÍDA?
Com a melhoria das tecnologias, o que se conseguia executar, algumas décadas atrás, somente com
computadores que custavam milhões de dólares, hoje se consegue executar com computadores de baixo custo.
O segundo fator é o surgimento de redes de computadores de alta velocidade, em que informações podem ser
transferidas entre computadores na faixa de microssegundos.
Como resultado, é possível conectar diversos computadores por meio de uma rede de alta velocidade para
executar um sistema de computação colaborativo. Estes sistemas são geralmente chamados de sistemas
distribuídos (SD).
•Sistema distribuído permite uma nova forma de fazer ciência
–Teoria -> experimentos
–Teoria -> simulações
•Computação usada para modelar sistemas físicos
•Vantagens
–Possibilidade de repetição de eventos
–Manipulação de parâmetros
–Estudo de sistemas onde não há teorias exatas
•Problemas
– modelagem da terra/clima, simulações de reservatórios de petróleo, problemas com grandesMuito grandes:
escalas (cosmologia).
– : projeto de remédios, projetos de chips, biologia estrutural, física de partículas.Muito pequenos
– física de partículas, dinâmica de fluidos, modelagem de comportamento de pessoas.Muito complexos:
– produção e exploração de petróleo, simulação de acidentes.Muito caros:
– tolerância a falhas em aviões, teste de dispositivos nucleares, simulação de estratégias deMuito perigosos:
defesa.
•Problemas que requerem alto desempenho computacional
Modelagem climática
Mapeamento do genoma
Modelagem de semicondutores
Dispersão de poluição
Projetos farmacêuticos
- -5
Modelagem de reatores nucleares
Renderização de imagem
Aumento de desempenho
• Limites físicos
–Velocidade da luz.
–Miniaturização dos componentes.
–Isolamento e dissipação de calor.
Até meados de 1965 não havia nenhuma previsão real sobre o futuro do hardware, quando o então presidente
da Intel, Gordon E. Moore, fez sua profecia, na qual o número de transistores dos chips teria um aumento de
100%, pelo mesmo custo, a cada período de 18 meses. Essa profecia tornou-se realidade e acabou ganhando o
nome de Lei de Moore.
• Solução: Paralelismo
– Execução simultânea de operações.
– Solução com melhor custo/benefício.
3 EVOLUÇÃO DO PROCESSAMENTO
Anos 70
Primeiras máquinas paralelas - Illiac IV (64 processadores) foi um supercomputador construído pela
Universidade de
Hlinois e financiado pelo governo dos EUA, Sua construção custou US$ 31 milhões.
- -6
Fonte: Illiac IV Fonte: htttp://pt.wikipedia.org/wiki/Ficheiro:ILLIAC_4_ parallel_computer.Jpg
Anos 80
-computadores vetoriais (Cray);
- máquinas paralelas comerciais para aplicações científicas (meteorologia, petróleo...);
-Alto custo de desenvolvimento;
- pequena escala, dificuldade de programação.
Fonte: Cray 1 - A Cray Research, empresa de Seymour Cray, o primeiro supercomputador vetorial (Cray), com 
altíssima velocidade de processamento e grande capacidade de memória, empregado em pesquisas cientificas e 
militares. Fonte: http://museudoscomputadores.blogspot.com/
- -7
Anos 90 dias de hoje
-multiprocessadores escaláveis;
-redes de estações de trabalho;
-computação distribuída;
-aplicaçõescliente/servidor;
-objetos distribuídos;
-clusters;
-grids.
Com o surgimento de malhas computacionais (grids), em que as aplicações executam em ambientes distribuídos,
compostos por um grande número de máquinas heterogêneas, administradas por diferentes instituições e
conectadas à internet.
Fonte: Computação em grade (grid computing) Fonte: http://www.adarshpatil.com/newsite/grid.htm
4 PARALELISMO X COMPUTAÇÃO PARALELA
Paralelismo
–Projeto de uma CPU
–Projeto de uma arquitetura paralela
–E/S sobreposta ao processamento
Computação paralela
- -8
–Coleção de elementos de processamento
–Trabalhando em conjunto para a realização de uma tarefa
Paralelismo
Dentro de um processador
Figura 1 - Arquiteturas sequenciais
- -9
Figura 2 - Arquiteturas pipeline
Figura 3 - Arquiteturas superescalares
- -10
Figura 4 - Arquiteturas VLIW
Arquiteturas SMT
· SMT = Simultaneous Multithreading
· Múltiplos threads despacham múltiplas instruções no mesmo ciclo
· Aumenta a possibilidade de manter todas as unidades funcionais ocupadas
Por que clusters?
· Custo/benefício - redução de custo para se obter processamento de alto desempenho, utilizando máquinas de
baixo custo.
- -11
· Escalabilidade - possibilidade de inclusão de novos componentes, que sejam adicionados à medida que cresça a
carga de trabalho.
· Alto desempenho - possibilidade de resolver problemas complexos através de programação e processamento
paralelo, reduzindo o tempo para a solução do problema.
· Independência de fornecedores - utilização de hardware aberto, software de uso livre e independência de
fabricantes e licenças de uso.
· Tolerância a falhas - o aumento de confiabilidade do sistema como um todo, caso alguma parte falhe.
Cluster Beowulf
· Em 1994, o Projeto Earth and Space Sciences (ESS) da NASA construiu o primeiro cluster paraBeowulf
fornecer computação paralela com o intuito de resolver problemas envolvidos em aplicações da ESS.
· Uma característica desta arquitetura é que é constituída por diversos nós escravos e gerenciada por um só
computador.
O primeiro cluster de PC's (Beowulf) foi construído em 1994 por dois pesquisadores do Goddard Space Flight
Center (NASA) Thomas Sterling e Don Becker. Naquele momento esses pesquisadores necessitavam de uma
solução de baixo custo e que processasse na ordem de 1 Gflop, o que significa um bilhão de operações em ponto
flutuante por segundo, já que preço de um supercomputador com este nível de desempenho era de
aproximadamente um milhão de dólares. A idéia original era utilizar processadores mais baratos, para tanto,
este cluster foi configurado inicialmente com 16 máquinas utilizando processadores 486DX4, placas de rede
- -12
Ethernet e sistema operacional Linux. Este primeiro cluster atingiu a marca de 70 Mflops, com um custo
estimado em 10% do valor de mercado para uma máquina de desempenho similar. Este projeto obteve tanto
sucesso que o termo Beowulf é utilizado até hoje como uma classe de clusters.
Estas máquinas foram montadas e programadas de forma que possibilitassem a paralelização/ divisão das
tarefas, buscando atingir um poder de processamento equivalente a um supercomputador da época, por uma
fração do preço. Este primeiro cluster chegou 70 Mflops, com um custo estimado em 1/10 do valor cobrado pelo
mercado para um sistema de desempenho similar. Tal projeto fez tanto sucesso que o termo Beowulf foi
estendido a uma classe de clusters que são utilizados ainda hoje.
- -13
1.Computação centralizada
– Mainframe: termo utilizado para se referenciar a um grande computador, normalmente produzido por uma
grande empresa. O nome tem origem na forma com que estes computadores eram construídos. Todos os
componentes (processador, memória...) do computador principal (main) são colocados em uma única estrutura
(frame).
– Características
– Sistemas multiusuários
– Sistemas proprietários -> hardware, software, rede
– Instalação e manutenção feita pelo fabricante -> confiabilidade X custo
2.Microcomputadores e redes de computadores
Ampliação do parque computacional, em função de:
• Processadores mais rápidos e mais baratos.
• Redes mais rápidas e acessíveis.
• Liberdade de escolha.
• Menor custo de manutenção.
• Necessidade inerente de conectividade.
• Aplicação básica: compartilhamento de recursos.
Evolução: Os terminais foram sendo substituídos pelos primeiros microcomputadores que começavam a ficar
obsoletos. Em geral, o uso de um programa emulador de terminais e de uma unidade de disquete era suficiente
para que um simples PC-XT executasse essa tarefa, uma vez que só precisaria executar o emulador. A partir deste
ponto, o micro passaria a se comportar como um terminal. Em alguns casos, era necessário o uso de uma placa
que compatibilizasse a forma de comunicação serial entre os dois computadores.
3.Sistemas distribuídos
Utilização das redes de computadores (locais e de longa distância) para execução colaborativa e cooperativa de
aplicações e não somente para compartilhamento de recursos.
Sistema distribuído = computadores + rede + aplicação
Conceito: É um sistema em que os computadores estão conectados em rede e coordenam suas ações através de
troca de mensagens.
- Definições de sistemas distribuídos
Colouris: “Um sistema no qual os componentes de hardware ou software, localizados em computadores
interligados em rede, se comunicam e coordenam suas ações apenas enviando mensagens entre si,”
- -14
Tanenbaum: “Um sistema distribuído é um conjunto de computadores independentes que se apresenta a seus
usuários como um sistema único e coerente.”
Silberschatz: “Coleção de processadores que não compartilham memória ou relógio.”
4.Comparação com sistemas centralizados
Vantagens:
• Melhor relação preço/desempenho
• Capacidade de crescimento incremental (escalabilidade)
• Tolerância a falhas
Desvantagens:
• Falta de padronização para desenvolvimento de software
• Falta de uma divisão clara entre sistema/aplicação
• Latência e possibilidade de congestionamento na rede
• Redução da segurança
5.Desafios da computação distribuida
· Ausência de fonte comum de tempo (relógio global)
· Ausência de memória compartilhada
· Compartilhamento de recursos
O que vem na próxima aula
Na próxima aula, você vai estudar:
· Identificar o uso de aplicações distribuídas;
· Conhecer as principais aplicações atuais;
· Compreender como a computação distribuída pode contribuir para TI verde.
CONCLUSÃO
Nesta aula, você:
• Entendeu a necessidade da utilização da computação de alto desempenho nos ambientes corporativos;
• Conheceu as características da computação centralizada e da computação distribuída;
• Identificou as vantagens e desvantagens de cada arquitetura e a motivação para esta evolução.
•
•
•
- -1
ARQUITETURA DE SISTEMAS 
DISTRIBUÍDOS
APLICAÇÕES DISTRIBUÍDAS E TI VERDE
- -2
Olá!
Objetivo desta aula
Ao final desta aula, o aluno será capaz de:
1- Identificar o uso de aplicações distribuídas;
2- Reconhecer as principais aplicações atuais;
3- Avaliar a contribuição da computação distribuída para a TI verde.
Introdução
Nesta aula, você estudará a importância das aplicações distribuídas e da TI verde.
Para as empresas, o valor da informação é considerado, na atualidade, como algo imensurável, e a velocidade
para adquiri-la têm fomentado investimentos no desenvolvimento da computação de alto desempenho.
Para compreendermos melhor essa questão, vamos ampliar nosso estudo sobre a necessidade e as dificuldades
de se implementar um sistema distribuído.
1 Surgimento dos sistemas distribuídos
À medida que a velocidade e a confiabilidade das redes de computadores aumentam, computadores do mundo
inteiro estão cada vez mais interconectados.
A comunicação remota via rede, originalmente reservada para grandes instalações de computadores e ambientes
acadêmicos, tem sido amplamente empregada.
Em sistemas distribuídos, computadores remotos trabalham cooperativamente por meio da rede, de modoque
seja visto como uma única máquina local.
As aplicações de sistemas distribuídos podem ser executadas em máquinas locais e remotas, além de permitir o
compartilhamento de dados, arquivos e outros recursos entre diversas máquinas.
Os sistemas distribuídos quase sempre surgem da necessidade de melhorar a capacidade e a confiabilidade de
uma única máquina (como, por exemplo, a capacidade de processamento e o tamanho de armazenamento dessa
máquina).
2 Limitação das Máquinas
Fatores econômicos podem limitar a capacidade de um sistema!
- -3
Sendo assim, ao implementar um sistema com máquinas de baixo custo, é possível projetar um poderoso sistema
sem a utilização de equipamentos dispendiosos.
Embora ofereçam muitas vantagens em relação a sistemas centralizados, os sistemas distribuídos podem ser
complexos e de difícil implementação e gerenciamento.
Por exemplo, os sistemas distribuídos têm de manipular atrasos de comunicação e problemas de confiabilidade.
É muito difícil gerenciar falhas de máquinas!
Mais difícil ainda é gerenciar sistemas distribuídos compostos por diversas máquinas, já que estão mais
propensos a sofrer queda de sistema do que os sistemas de apenas uma única máquina.
Concorrência
A execução concorrente é uma característica intrínseca de um sistema distribuído, na qual os processos
disputam pelos recursos compartilhados.
Inexistência de relógio global
A coordenação dos processos depende de uma noção compartilhada do tempo em que as ações dos programas
ocorrem.
Falhas independentes
Falhas na rede, nos sistemas ou nos processos demoram a ser percebidas nos sistemas distribuídos.
(COULOURIS; DOLLIMORE; KINDBERG, 2007).
Falácias da computação distribuída
Os sistemas distribuídos são diferentes dos softwares tradicionais, porque seus componentes estão dispersos em
uma rede.
Não levar essa dispersão em conta durante o projeto torna muitos sistemas desnecessariamente complexos, o
que resulta em erros que precisam ser corrigidos mais tarde (o que chamamos de retrabalho).
Peter Deustch formulou esses erros como as seguintes premissas falsas que todos adotam ao desenvolver uma
aplicação distribuída pela primeira vez:
· A rede é confiável
· A rede é segura
· A rede é homogênea
· A topologia não muda
· A latência é zero
· A largura de banda é infinita
· O custo do transporte é zero
· Há somente um administrador
- -4
Atributos dos Sistemas Distribuídos
Vamos conhecer alguns atributos dos sistemas distribuídos:
Latência – Tempo decorrido entre o início de uma operação e seu término. O termo latência é usado,
normalmente, para comunicações entre partes de um sistema.
Taxa de transmissão – Taxa que mede a capacidade de transmissão/recepção de informações por unidade de
tempo.
Speedup – Termo que significa ganho relativo de velocidade ou desempenho. Como exemplo de, speedup
podemos citar a razão dos tempos de execução sequencial e o paralelo.
Bottleneck – Termo que significa (um elemento de um sistema é o gargalo quando limita seugargalo 
desempenho, embora o resto do sistema ainda tenha folga para trabalhar. É desejável que não haja gargalos no
sistema e que todos os elementos alcancem seus limites juntos.
Escalabilidade – Capacidade de melhoria do desempenho do sistema distribuído conforme cresce o número de
elementos processadores (de acordo com Neuman (1994), a escalabilidade pode ser medida, a princípio, por três
dimensões, quais sejam: – o que significa que é fácil adicionar mais usuários eEm relação a seu tamanho
recursos ao sistema; – trata-se de um sistema nos quais usuários e recursos podemEm termos geográficos
estar longe uns dos outros; – o que significa que o sistema ainda pode ser fácil deEm termos administrativos
gerenciar, mesmo que seja abrangente).
Balanceamento de Carga – Característica que permite ao sistema distribuído dividir, adequadamente, suas
tarefas, de modoque um elemento processador não fique mais sobrecarregado que os outros.
Throughput – Medida de produtividade de um sistema. Essa medida exprime, por unidade de tempo, a
produção efetiva do sistema em termos de tarefas, transações, operações, etc.
Confiabilidade – Característica do sistema que dá maior ou menor certeza de que vai funcionar a contento.
Tolerância a falhas – Capacidade de o sistema sobreviver à falha de alguns de seus elementos. 
Disponibilidade – Característica que indica quanto tempo o sistema funcionará ininterruptamente sem ser
afetado por falhas, manutenção preventiva ou corretiva, etc.
Segurança – Garantia de o sistema fazer, de maneira correta e para os usuários corretos, aquilo para o qual foi
projetado (em outras palavras, usuários ou programas não autorizados não devem ter acesso aos recursos do
sistema. O sistema deve ser capaz de garantir que essa diretriz seja cumprida. Caso contrário, esse mesmo
sistema deve detectar como, quando e por que não se cumpriu o estabelecido).
Migração de tarefas – Transferência de responsabilidade de execução de uma tarefa de um elemento para
outro. A migração de tarefas de ser de processos ou de computação.
Migração de dados – Transferência de dados de um elemento processador para outro.
- -5
Replicação- Duplicação de recursos de um elemento processador em outro.
Transparência – Característica que esconde de usuários ou aplicativos detalhes de funcionamento do sistema
distribuído, de tal forma que se tenha a impressão de que esse sistema é centralizado .
Veja agora alguns aspectos de transparência (ISO, 1995):
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 outra localização durante o 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.
Imagem Única do Sistema (SSI)
Um Sistema de Imagem Única (SS!) é a propriedade de se ocultar a complexidade envolvida em uma natureza
distribuida e heterogênea de recursos disponíveis para os usuários e aplicações, de tal forma que estes
visualizem o sistema como um recurso único. (PITANGA, 2004)
Veja, a seguir, alguns beneficios do SSI:
Os serviços podem ser requisitados a partir de qualquer nó do sistema;· 
A localização de dispositivos fisicos pode ser totalmente transparente para o usuário;· 
O sistema apresenta disponibilidade em seus serviços;· 
O sistema permite ao usuário trabalhar com uma interface simplificada, com comandos que ajudem a· 
administrar o cluster por inteiro, como se fosse uma única máquina;
O sistema reduz riscos em erros operacionais e apresenta maior disponibilidade;· 
O sistema permite a localização independente para a comunicação das mensagens, unificando o espaço de· 
comunicação entre processos;
O sistema permite um modelo de processos com espaço globalizado para balanceamento de carga;· 
O sistema permite que diversos componentes de uma aplicação trabalhem, de forma cooperativa, para criar a· 
imagem de uma única aplicação no sistema;
Quanto à concorrência, os usuários não devem notar que existem outras pessoas utilizando o sistema.· 
- -6
3 Máquinas mais velozes
Desde 1993, o site publica, semestralmente, um ranking dos 500 computadores com maior TOP500
desempenho no mundo.
Na lista do , são obtidos pelo benchmark os seguintes resultados: ranking*
Rmax – performance para o maior problema executado em uma máquina (em Gflop/s);
Nmax – tamanho do maior problema executado em uma máquina;
N1/2 – tamanho quando metade de Rmax é executado;
Rpeak – pico de performance teórico para a máquina (em Gflop/s).
https://top500.org
*Esse ranking é baseado nas informações do programa utilizado para a análise de performance: o LINPACK
benchmark. Sua atualização ocorre no mês de junho, coincidindo com a InternationalSupercomputer
Conference, e no mês de novembro, na IEEE Supercomputer Conferente.
Um computador japonês conquistou o 1º lugar no ranking de junho de 2011, com desempenho medido em 8.16
petaflops.
O K computer é mais poderoso que os próximos cinco sistemas da lista combinados.
O desempenho foi medido com 68.554 processadores SPARC64VIIIfx, cada um com oito núcleos, em um total de
548.352 núcleos (quase o dobro de qualquer outro sistema dessa lista).
Até sua conclusão, essa máquina terá mais de 80.000 processadores!
3.1 Brasil no ranking das máquinas mais velozes
O Brasil tem dois supercomputadores na lista do ranking dos computadores mais velozes do mundo:
Tupi - Operado pelo Instituto Nacional de Pesquisas Espaciais (INPE) – ocupa a 34ª posição, com 30.270
processadores AMD Opteron de 12 núcleos, cada um rodando a 2.1 GHz e com desempenho de 205.1 teraflops.
Galileu - Operado pelo Núcleo de Atendimento em Computação de Alto Desempenho (NACAD/COPPE), da
Universidade Federal do Rio de Janeiro (UFRJ) – ocupa a 167ª posição, com 6.464 processadores Intel Xeon
Nehalem de 2.8 GHz cada, e desempenho de 64.6 teraflops.
Gráfico do ranking TOP500
Veja, a seguir, gráficos fornecidos pelo ranking TOP500 que apresentam o desenvolvimento da performance dos
supercomputadores, de 1993 a 2011, e sua projeção:
https://top500.org/
https://top500.org
- -7
4 Intranet
De acordo com Marcelo (2002), a intranet consiste em:
“[...] redes corporativas que se utilizam de tecnologia e de infraestrutura de comunicação de dados da internet.
Essas redes são utilizadas na comunicação interna da própria empresa e também na comunicação com outras
empresas. [...]
Portanto, a intranet é o uso da tecnologia da internet na rede corporativa da empresa. Ela facilita a distribuição
de documentos, a transferência de arquivos, a consulta à informação e muitas outras aplicações.”
Diagrama da intranet
Veja, a seguir, um diagrama esquemático de uma intranet.
- -8
5 Computação em grade (grid computing)
A tecnologia por trás da computação em grade é um conjunto de que gerenciamsoftwares middleware*
recursos distribuidos e espalhados pela organização, disponibilizando os servidores e, eventualmente, os
desktops da empresa.
A ideia básica é combinar os recursos disponíveis com as demandas computacionais das empresas.(CHEDE,
2004, p. 16)
Computação em grade é uma maneira bastante eficiente de maximizar recursos computacionais.
Trata-se de uma consolidação virtual de servidores. (CHEDE, 2004).
*Designação utilizada para se referir ao software executado entre as aplicações distribuídas e o sistema
operacional. O middleware ajuda a fornecer portabilidade, transparência e interoperabilidade entre sistemas
distribuídos.
Exemplo de grid computing
Veja, a seguir, o Worldwide LHC Computing Grid (CERN) – uma computação em grade:
- -9
Fonte: Imagens disponíveis no link http://michaelgr.com/2008/10/03/cern-unveils-the-worldwide-lhc-
computing-grid
6 Computação oportunista - projeto SETIG
O conceito de computação oportunista consiste em usar redes de computadores para resolver problemas
computacionais. Esse conceito se popularizou com o sucesso do projeto SETIe, baseado na ideia do voluntariado,
em que um usuário toma a decisão de ceder ciclos ociosos de seu computador para contribuir com uma
determinada organização para a execução de alguma tarefa. (CHEDE, 2004, p. 57)
Veja, a seguir, figuras do projeto SETI@home:
Fonte: Imagens disponíveis nos links #1 e #2 #1 https://pt.wikipedia.org/wiki/SETI#SETI.40HOME #2 
https://boinc.berkeley.edu
- -10
7 Computação oportunista - projeto BOINC
Outro projeto que pode ser citado no campo da computação oportunista é o Berkeley Infraestructure for
Network Computing (BOINC), que tem como proposta permitir que o usuário possa operar simultaneamente
diversos projetos desse tipo de computação.
Veja, a seguir, a realização de uma previsão de clima, utilizando o projeto BOINC:
8 Sistemas distribuídos e TI verde
A virtualização é a camada de abstração entre sistemas de hardware de computador e do software que roda
nesses sistemas, proporcionando uma visão lógica dos recursos de computação.
Trata-se de uma das formas de economizar recursos e praticar TI verde!
A virtualização trata de estender ou substituir uma interface existente, de modo a imitar o comportamento de
outro sistema.
Uma das razões mais importantes para introduzir a virtualização na década de 1970 foi permitir que softwares
herdados (aplicações e sistemas operacionais) executassem em hardwares de mainframe. (TANENBAUM, 2007)
Procure, por exemplo, comparar o que é real e o que é virtual!
- -11
Algo real possui características físicas; já o virtual está vinculado à simulação.
Sendo assim, a virtualização pode ser definida como uma simulação de um ambiente real.
Virtualização e o sistema de conectividade
Atualmente, grande parte dos computadores está conectada por redes de computadores!
Essa conectividade exige dos administradores que um conjunto grande e heterogêneo de computadores
servidores execute (cada um) diferentes aplicações utilizando diferentes recursos, que podem ser acessadas por
diversos clientes.
A virtualização pode contribuir muito nesse sentido!
Em primeiro lugar, porque a diversidade de plataformas e máquinas pode ser reduzida.
Em segundo lugar, porque cada aplicação pode executar em sua própria máquina virtual, incluindo,
possivelmente, suas bibliotecas e o sistema operacional (ambos relacionados), que estariam executando em uma
plataforma comum.
Diagrama esquemático da máquina virtual
Veja, a seguir, um diagrama esquemático de uma máquina virtual:
Supercomputadores e TI verde
- -12
Desde abril de 2005, o site Green500 fornece um ranking dos mais eficientes supercomputadores do mundo em
termos energéticos. Por décadas, a noção de performance tem sido sinônimo de velocidade.
Esse enfoque especial levou ao surgimento de supercomputadores que consomem grandes quantidades de
energia elétrica e produzem tanto calor que exigem enormes instalações de refrigeração.
Alguns supercomputadores têm liderado essas listas que são publicadas semestralmente, como as do ranking
TOP500. Um deles aparece no ranking Green500 de junho de 2011: o Cluster DEGIMA, da Universidade de
Nagasaki, no Japão. Outro máquina que obteve destaque no mesmo mês e ano é o IBM Blue Gene (protótipo/Q),
que possui eficiência energética de 2097 MFLOPS/watt. Esse supercomputador aparece como o número 1 do
ranking Green500. Veja:
O que vem na próxima aula
Na próxima aula, você estudará sobre os seguintes assuntos:
•Tratamento de falhas;
•Métodos de tratamento de falhas em sistemas distribuídos.
CONCLUSÃO
Nesta aula, você:
• Conheceu as falácias da computação distribuída;•
- -13
• Conheceu as falácias da computação distribuída;
• Identificou os atributos dos sistemas distribuídos;
• Identificou o uso de algumas aplicações distribuídas;
• Identificou os maiores computadores com desempenho no mundo;
• Compreendeu a necessidade de se tratar o uso consciente da eficiência energética em máquinas 
multiprocessadas.
•
•
•
•
•
- -1
ARQUITETURA DE SISTEMAS 
DISTRIBUÍDOS
TRATAMENTO DE FALHAS
- -2
Olá!
Nesta aula, você irá:
1) Reconhecer alguns dos métodos de tratamento de falhas em sistemas distribuídos.
Introdução
O profissional da área de Tecnologia da Informação atua diretamente no planejamento, na implementação e na
implantação de soluções de TI nas organizações.
Dessa forma, é importante que sejam compreendidos os conceitos, os benefícios, as características e as restrições
dos sistemas tolerantes a falhas e com alta disponibilidade. Tais sistemas devem ser confiáveis!
1 Falhas Parciais
Uma característica dos sistemas distribuídos que os distingue de sistemas centralizados é a noção de falha
parcial.
A falha parcial pode acontecer quando um componente em um sistema distribuído não funciona. Essa falha pode
afetar a operação adequada de outros componentese, ao mesmo tempo, deixar outros totalmente ilesos.
A falha em sistemas não distribuídos quase sempre é total, no sentido de que afeta todos os componentes e pode,
facilmente, fazer o sistema inteiro cair.
Um objetivo importante do projeto de sistemas distribuídos é construir o sistema de tal modo que possa se
recuperar automaticamente de falhas parciais, sem afetar, seriamente, seu desempenho global.
Em particular, sempre que ocorrer uma falha, o sistema distribuído deve continuar a funcionar de maneira
aceitável enquanto o sistema estiver em conserto.
Em outras palavras, o sistema distribuído deve tolerar falhas e continuar a funcionar até certo ponto, mesmo na
presença dessas falhas.
2 Tolerância a falhas
Para entendermos o papel da tolerância a falhas em sistemas distribuídos, em primeiro lugar, precisamos
entender o que significa tolerar falhas para esse sistema.
Existe uma forte relação entre ser tolerante a falhas e sistemas confiáveis. De acordo com Kopetz e Verissimo
 Kopetz, H e Veríssimo, P. . Em Mullender (ed.), Distributed(1993)( Real Time and Dependability Concepts
- -3
Systems, 2ª ed. Addison-Wesley. 1993), a confiabilidade abrange uma série de requisitos úteis para sistemas
distribuídos, tais como:
Disponibilidade
A disponibilidade consiste na propriedade de um sistema estar pronto para ser usado imediatamente. Trata-se
da probabilidade de o sistema funcionar corretamente em qualquer momento determinado e estar disponível
para executar suas funções em nome de seus usuários.
A alta disponibilidade, por sua vez, representa o que provavelmente funcionará em dado instante de tempo.
Por exemplo, se um sistema nunca cai, mas é desligado por duas semanas em um determinado mês, todos os
anos, tem alta confiabilidade, mas somente 96% de disponibilidade.
Confiabilidade
A confiabilidade consiste na propriedade de um sistema poder funcionar continuamente sem falhas.
Essa confiabilidade é definida em termos de um intervalo de tempo, e não de um instante de tempo.
A alta confiabilidade, por sua vez, representa o que provavelmente continuará a funcionar, sem interrupção,
durante um período de tempo relativamente longo.
Por exemplo, se um sistema ficar fora do ar por um milissegundo a cada hora, terá uma disponibilidade de mais
de 99,99%, mas sua confiabilidade ainda será muito baixa.
Segurança
Se um sistema deixar de funcionar corretamente durante certo tempo, nada de catastrófico acontecerá.
É o que acontece, por exemplo, com sistemas de controle de processos usados em usinas de energia nuclear ou
sistemas para enviar pessoas ao espaço.
Capacidade de manutenção
À capacidade de manutenção consiste na facilidade com que um sistema que falhou pode ser consertado.
Sistemas de alta capacidade de manutenção também podem mostrar alto grau de disponibilidade, em especial se
as falhas puderem ser detectadas e reparadas automaticamente.
3 Falha, erro e defeito
O defeito acontece quando o sistema não pode cumprir o que foi especificado ou prometido.
Em particular, se um sistema distribuído é projetado para oferecer a seus usuários uma série de serviços, o
sistema falha quando um ou mais desses serviços não podem ser fornecidos completamente.
O erro, por sua vez, representa o estado de um sistema que pode levar a uma (a causa de um erro éfalha
denominada falha).
- -4
É o caso da transmissão de pacotes por uma rede. Espera-se que alguns pacotes estejam danificados quando
chegam ao receptor. Meios de transmissão com problemas podem facilmente danificar pacotes.
Os erros de transmissão também podem ser causados por más condições atmosféricas, como ocorre com redes
sem fio.
4 Tipos de falhas
As falhas são classificadas como:
Transientes
As falhas transientes ocorrem uma vez e, depois, desaparecem. Se a operação for repetida, a falha não acontecerá
novamente.
Por exemplo, um pássaro voando pelo feixe de um transmissor de microondas pode causar perda de bits em
alguma rede.
Intermitentes
As falhas intermitentes ocorrem e desaparecem por sua própria vontade. Depois, essas falhas reaparecem e
assim por diante.
Por exemplo, um conector com um contato frouxo causará, muitas vezes, uma falha intermitente.
Permanentes
As falhas permanentes continuarão a existir até que o componente faltoso seja substituído.
É o caso dos chips queimados e dos bugs de software.
5 Modelos de falha
Um sistema falha quando não fornece, adequadamente, os serviços para os quais foi projetado.
Se considerarmos um sistema distribuído como um conjunto de servidores que se comunicam entre si e com
seus clientes, esse fornecimento inadequado de serviços significa que servidores, canais de comunicação ou,
possivelmente, ambos não estão fazendo o que deveriam fazer.
Contudo, nem sempre um servidor que funciona mal representa a falha que estamos procurando. Se tal servidor
depender de outros servidores para prestar seus serviços adequadamente, é possivel que a causa de um erro
tenha de ser procurada em algum outro lugar.
Para que tivéssemos uma ideia melhor da real seriedade de uma falha, foram desenvolvidos diversos esquemas
de classificação.
- -5
Um desses esquemas é descrito em (Cristian, F.-Understanding Fault-Tolerant DistributedCristian (1991)
Systems. Communnications of the ACM Vol 34, No 2, pp 56-78, 1991) e (Hadzilacos, Hadzilacos e Toueg (1993)
V. and Toueg, S. A Modular Approach to Fault-tolerant Broadcasts and Related Problems, Technical report, Dept.
of Computer Science, University of Toronto, 1994) da seguinte forma:
Veja a seguir, um modelo de falhas em sistemas distribuídos:
6 Técnicas de tratamento
Veja, a seguir, algumas técnicas de tratamento:
- -6
1. Mascaramento de falha por redundância;
2. Mascaramento de falhas e replicação;
3. Acordo em sistemas com falha;
4. Detecção de falha;
5. Recuperação
Mascaramento de falha por redundância
Se um sistema deve ser tolerante a falhas, o melhor que ele pode fazer é tentar ocultar de outros processos a
ocorrência de falhas. À técnica fundamental para mascarar falhas é usar redundância.
Avance e conheça os três tipos possíveis de redundância.
Redundância de Informação
Na redundância de informação, os bits extras são adicionados para permitir recuperação de bits deteriorados.
Por exemplo, um código de pode ser adicionado a dados transmitidos para recuperá-los de ruído naHampming
linha de transmissão.
Redundância de Tempo
Na redundância de tempo, uma ação é realizada e, se for preciso, essa ação será executada novamente.
Transações (banco de dados usam essa abordagem. Se uma transação for abortada, ela pode ser refeita sem
causar nenhum dano.
A redundância de tempo tem especial utilidade quando as talhas são transientes ou intermitentes.
Redundância Física
Na *, são adicionados equipamentos ou processos extras para possibilitar que q sistemaredundância física
como um todo tolere a perda ou o mau funcionamento de alguns componentes. A redundância física pode ser
feita em hardware ou em .software
Por exemplo, processos extras podem ser adicionados ao sistema, de modo que, se uma pequena quantidade
deles cair, o sistema ainda possa funcionar corretamente.
Em outras palavras, replicando processos, podemos conseguir alto grau de tolerância à talha.
*A redundância física é uma técnica bem conhecida para prover tolerância à falha. Essa técnica é usada em:
Biologia – mamíferos têm dois olhos, dois ouvidos, dois pulmões e assim por diante;
Aeronaves – aviões 747 têm quatro motores, mas podem voar com três;
Esportes – com a utilização de vários juízes, caso algum deles não perceba um evento.
A referida técnica também vem sendo usada, há anos, para tolerância à falha em circuitos eletrônicos.
Mascaramento de falhas e replicação
Grupos de processos fazem parte da solução para construir sistemas tolerantes à falha.
- -7
Em particular, ter um grupo de processos idênticos permite-nos mascarar um ou mais processos faltosos àquele
grupo. Podemos replicar processos e organizá-losem um grupo para substituir um único processo (vulnerável)
por um grupo (tolerante à falha).
De modo geral, em casos de tolerância à falha, a replicação é baseada na forma de um
protocolo de primário e backup.
Nesse caso, um grupo de processos é organizado de modo hierárquico, no qual um servidor primário coordena
todas as operações de escrita.
Na prática, o servidor primário é fixo, embora seu papel possa ser assumido por um dos backups (caso
necessário).
Na verdade, quando um servidor primário cai, os backups executam algum algoritmo de
eleição para escolher um novo servidor primário.
Acordo em Sistemas com Falha
Organizar processos replicados em um grupo ajuda a aumentar a tolerância à falha.
Em geral, as coisas tornam-se mais complicadas se exigirmos que um grupo de processos
chegue a um acordo, o que é necessário em muitos casos, tais como:
· Eleger um coordenador;
· Decidir a validação ou não de uma transação;
· Repartir tarefas entre operários;
· Sincronização.
Quando a comunicação e os processos são todos perfeitos, chegar a tal acordo costuma
acontecer de forma direta, mas, quando não o são, surgem problemas.
O objetivo geral de algoritmos de acordo distribuído é que todos os processos que não
apresentam falha cheguem a um consenso sobre alguma questão e estabeleçam esse consenso dentro de um
número finito de etapas.
O problema é complicado pelo fato de que premissas diferentes sobre o sistema subjacente requerem soluções
diferentes, considerando que existam soluções para as mesmas.
Detecção de falha
Para mascarar falhas adequadamente, em geral, também é necessário detectá-las!
A detecção de falhas é uma das bases da tolerância à falha em sistemas distribuídos.
No caso de um grupo de processos, os sistemas devem ser capazes de decidir quem ainda é um membro e quem
não é, isto é, o sistema deve ser capaz de detectar quando um membro de um grupo falhou.
Quando se trata de detectar falhas de processos, há, essencialmente, dois mecanismos:
- -8
1. Os processos enviam as mensagens ativamente uns aos outros;
2. Os processos esperam passivamente pela entrada de mensagens de processos diferentes.
Há várias questões que precisam ser levadas em conta no projeto de um subsistema de detecção de falha.
A (Por exemplo, a detecção de falha pode ocorrer por gossiping, no qual cada nó anuncia,detecção de falha 
periodicamente, a seus vizinhos que ainda está vivo e funcionando) também pode ser realizada como resultado
da troca regular de informações com vizinhos, como acontece na disseminação de informações baseada em
gossiping.
Em determinado momento, todo processo saberá da existência de cada um dos outros processos. Entretanto, o
mais importante é que o referido processo terá informações disponíveis suficientes para decidir se outro
processo falhou ou não.
Um membro cuja informação de disponibilidade é antiga presumivelmente falhará!
Detecção de falha – exemplo
Podemos também nos deparar com a seguinte situação:
um subsistema de detecção de falhas que não consegue distinguir falhas de rede de falhas de nós.
Um modo de lidar com esse problema é não permitir que um único nó decida se um de seus vizinhos caiu.
Em vez disso, ao perceber que a temporização de uma mensagem se esgotou, um nó requisita a outrosping
vizinhos que verifiquem se podem alcançar o nó que, presumivelmente, falhou.
Certamente, informações positivas também podem ser compartilhadas: se um nó ainda estiver vivo, essa
informação poderá ser transmitida para outras partes interessadas (que podem detectar uma falha de enlace
com o nó suspeito).
Recuperação
Uma vez ocorrida a falha, é essencial que o processo em que a mesma aconteceu se possa recuperar para um
estado correto.
A recuperação de um erro é fundamental para a tolerância à falha!
Atenção!
É bom lembrar que um erro é parte de um sistema que pode levar a uma falha. A ideia geral de recuperação de
erro é substituir um estado errôneo por um estado livre de erro.
7 Formas de Recuperação de Erro
Essencialmente, existem duas formas de recuperação de erro, quais sejam:
Recuperação Retroativa
- -9
A questão principal da é trazer o sistema de seu estado com o erro presente para umrecuperação retroativa*
estado anterior, que estava correto.
Para fazer isso, é necessário registrar o estado do sistema de tempos em tempos e restaurar tal estado registrado
quando ocorrer o erro.
Toda a vez que o estado presente de um sistema (ou parte dele) é registrado, dizemos que foi realizado um
ponto de verificação (check-point).
* De modo geral, técnicas retroativas de recuperação de erro são amplamente aplicadas como um mecanismo
geral para recuperação de falhas em sistemas distribuídos.
O principal benefício da recuperação retroativa de erro é que esse método pode ser aplicado de modo geral,
independentemente de qualquer sistema ou processo especifico (TANENBAUM, 2007).
Em outras palavras, a recuperação retroativa pode ser integrada a um sistema distribuído (camada de
middleware) como um serviço de uso geral.
Recuperação para a Frente
Quando o sistema entra em um estado de erro, em vez de retroagir para um estado anterior correspondente a
um ponto de verificação, realiza-se uma tentativa para levar o sistema a um novo estado correto, a partir do qual
ele possa continuar a executar.
O principal problema dos * é que precisamos saber, de antemão,mecanismos de recuperação para a frente
quais erros podem ocorrer. Só assim, é possível corrigir esses erros e passar para um novo estado.
* Para distinguirmos recuperação de erro retroativa e para a frente, basta considerarmos a imple-mentação da
comunicação confiável.
A abordagem comum para se recuperar um pacote perdido é permitir que o remetente retransmita esse pacote.
Na verdade, a retransmissão de pacotes determina que tentamos voltar a um estado anterior correto, ou seja, ao
estado no qual o pacote que foi perdido está sendo enviado.
Portanto, a comunicação confiável por meio de retransmissão de pacote é um exemplo de aplicação de técnicas
retroativas de recuperação de erro.
O que vem na próxima aula
Na próxima aula, você vai estudar:
•Classificação de Flynn;
•Modelos de Programação;
•Implementações da arquitetura MIMD;
- -10
•Características de desenvolvimento de aplicações para as arquiteturas MIMD.
CONCLUSÃO
Nesta aula, você:
• Conheceu os conceitos sobre falhas, defeitos e erros em sistemas distribuídos;
• Conheceu os conceitos sobre falhas parciais;
• Conheceu os métodos de tratamento de falhas em sistemas distribuídos.
•
•
•
- -1
ARQUITETURA DE SISTEMAS 
DISTRIBUÍDOS
CLASSIFICAÇÃO DE FLYNN E MODELOS DE 
PROGRAMAÇÃO
- -2
Olá!
Objetivo desta aula
Nesta aula, você irá:
1-Definir a classificação de Flynn;
2-Reconhecer as implementações da arquitetura MIMD e as características de desenvolvimento de aplicações
para essa arquitetura;
3-Descrever a motivação a partir de alguns modelos de programação paralela.
Introdução
Nesta aula, estudaremos a classificação de multiprocessadores em relação à quantidade de fluxo de dados e
instruções, e em relação ao acesso à memória.
Conheceremos, também, algumas características de desenvolvimento de aplicações para as arquiteturas MIMD.
1 Taxonomia de Flynn
Em 1966, Michael J. Flynn propôs uma taxonomia: o primeiro esquema para classificar computadores em
configurações de paralelismo crescente.
O esquema consistia de quatro categorias baseadas em tipos diferentes de fluxos usados por processadores.
Um processador aceita dois fluxos: um fluxo de instruções e um fluxo de dados.
Veja, a seguir, uma tabela que apresenta a classificação de Flynn para os computadores:
- -3
Trata-se da classificação do tipo mais simples: são os monoprocessadores tradicionais, nos quais um único
processador busca uma instrução por vez e a executa sobre um único item de dado.
Como exemplos dessa classificação, podemos citar a arquitetura sequencial e a máquina de Von-Neumann.
Técnicas como a de , a da -pipelinepalavra de instrução muito longa - Very Long Instruction Word (VLIW)
e a do projeto superescalar podem introduzir paralelismo em computadores SISD.
Além disso, a tecnologia Hyper-Threading da Intel introduz paralelismo, criando dois processadores virtuais por
meio de um único processador físico, o que dá a um sistema operacional habilitado a multiprocessador a
impressão de que esteja executando em dois processadores (um a um) com pouco menos da metade da
velocidade do processador físico.
Pipeline - Na técnica de pipeline, o caminho de execução de uma instrução é dividido em estágios discretos, o 
que permite que o processador processe várias instruções simultaneamente, contanto que, no máximo, uma
instrução ocupe cada estágio durante um ciclo de relógio.
palavra de instrução muito longa - Very Long Instruction Word (VLIW) - As técnicas VLIW e superescalar
emitem, simultaneamente, várias instruções independentes (de um fluxo de instruções), que executam em
diferentes unidades de execução.
A VLIW depende de um compilador para determinar quais instruções emitir a qualquer ciclo de relógio,
enquanto um projeto superescalar requer que um processador tome essa decisão.
Computadores de fluxo múltiplo de instruções e fluxo único de dados - Multiple-Instruction-Stream,
Single-Data-Stream (MISD)
Esses tipos de computadores não são usados. Uma arquitetura MISD teria várias unidades de processamento que
agiriam sobre um fluxo único de dados. Cada unidade executaria uma instrução diferente nos dados e passaria o
resultado para a próxima unidade.
Computadores de fluxo único de instruções e fluxo múltiplo de dados - Single-instruction-Stream,
Multiple-Data-Stream (SIMD)
Esses computadores emitem instruções que agem sobre vários itens de dados. Um computador SIMD consiste
em uma ou mais unidades de processamento.
Um processador executa uma instrução SIMD processando-a em um bloco de dados (por exemplo, adicionando
esse bloco a todos os elementos de um arranjo). Se houver mais elementos de dados do que unidades de
processamento, essas unidades buscarão elementos de dados adicionais para o ciclo seguinte.
- -4
Isso pode melhorar o desempenho da arquitetura SIMD em relação às arquiteturas SISD, que exigiriam um laço
para realizar a mesma operação em um elemento de dados por vez. Um laço contém muitos testes condicionais e
requer que o processador SISD decodifique a mesma instrução várias vezes, além de exigir que o processador
SISD leia os dados uma palavra por vez.
Ao contrário, arquiteturas SIMD leem um bloco de dados por vez, reduzindo dispendiosas transferências da
memória para o registrador. Por isso, arquiteturas SIMD são mais efetivas em ambientes em que um sistema
aplica a mesma instrução a grandes conjuntos de dados.
Como exemplos de computadores que usam uma arquitetura SIMD, podemos citar os processadores vetoriais e
os processadores matriciais.
Processadores vetoriais – Processadores vetoriais contêm uma unidade de processamento que executa cada
instrução vetorial em um conjunto de dados, processando a mesma operação em cada elemento de dado. Esses
processadores dependem de pipelines profundose de altas velocidades de clock.
Pipelines profundos permitem que o processador realize trabalho em diversas instruções por vez, de modo que
muitos elementos de dados possam ser manipulados de uma só vez.
Processadores matriciais – Processadores matriciais (também denominados processadores maciçamente
paralelos) contêm diversas unidades de processamento que executam a mesma instrução em paralelo sobre
muitos elementos de dados.
Os processadores matriciais podem contem dezenas de milhares de elementos de processamento. Portanto,
esses processadores são mais eficientes quando manipulam grandes conjuntos de dados.
Computadores de fluxo múltiplo de instruções e fluxo múltiplo de dados - Multiple-instruction-Stream,
Multiple-Data-Stream (MIMD)
Trata-se de multiprocessadores, nos quais as unidades processadoras são completamente independentes e
operam sobre fluxos de instruções separados.
Entretanto, esses sistemas normalmente contêm hardware que permite que os processadores se sincronizem
uns com os outros quando necessário, como no caso de acessarem um dispositivo periférico compartilhado.
Essa classe foi subdividida em sistemas fortemente acoplados e fracamente acoplados.
2 Esquemas de interconexão de processadores
O esquema de interconexão de um sistema multiprocessador descreve de que modo os componentes do sistema
(como, por exemplo, um processador e módulos de memória) são conectados fisicamente.
- -5
O esquema de interconexão é uma questão fundamental para projetistas de multiprocessadores, porque afeta o
desempenho, a confiabilidade e o custo do sistema. Um sistema de interconexão consiste de e .nós enlaces
Em muitos sistemas, um único nó pode conter um ou mais processadores, seus caches associados, um módulo de
memória e uma chave. Em multiprocessadores de grande escala, às vezes, abstraímos o conceito de nó e
indicamos um grupo de nós como um único supernó.
Nós – os nós são compostos de componentes do sistema ou de chaves que fazem o roteamento das mensagens
entre componentes.
Enlaces – o enlace é uma conexão entre dois nós.
Uma técnica para medir a tolerância à falha de um esquema de interconexão é contar o número de enlaces de
comunicação que devem falhar antes que a rede não possa mais funcionar adequadamente. Isso pode ser
quantificado por meio da largura de (número mínimo de enlaces que precisam ser cortados parabisseção
dividir a rede em duas metades não conectadas).
Sistemas que têm larguras de bisseção maiores são mais tolerantes à falha do que aqueles que têm larguras de
bisseção menores, pois mais componentes têm de falhar antes que o sistema inteiro tenha problemas.
O desempenho de um esquema de interconexão depende, em grande parte, da latência de comunicação entre
nós, que pode ser medida de várias maneiras, como, por exemplo, por meio da latência média.
Outra medição de desempenho é o (distância mais curta entre os dois nós mais remotos dodiâmetro da rede
esquema de interconexão). Para determiná-lo, você deve considerar todos os pares de nós da rede e identificar o
caminho de comprimento mais curto para cada par - calculado pela soma do número de enlaces percorridos. Só
então, você identificará o maior desses caminhos.
Um diâmetro de rede pequeno indica baixa latência de comunicação e desempenho mais alto.
Por fim, arquitetos de sistemas tentam minimizar o custo de um esquema de interconexão, semelhante ao
número total de enlaces de uma rede.
3 Arquiteturas de acesso à memória
Veja, a seguir, uma figura que representa a classificação das arquiteturas segundo o acesso à memória:
- -6
Acesso uniforme à memória - UMA
Arquiteturas de multiprocessadores com acesso uniforme à memória - Uniform Memory Access multiprocessor
(UMA) - requerem que todos os processadores compartilhem a memória principal do sistema. Essa é uma
extensão direta da arquitetura de memória de um monoprocessador, mas com vários processadores e módulos
de memória.
O tempo de acesso à memória é uniforme para qualquer processador que acessar qualquer item de dado, exceto
quando esse estiver armazenado no cache de um processador ou quando houver contenção no barramento.
Acesso não uniforme à memória - NUMA
Arquiteturas de multiprocessador de acesso não uniforme à memória - NonUniform Memory Áccess (NUMA) -
mantêm uma memória global compartilhada, que pode ser acessada por todos os processadores.
A memória global é fracionada em módulos, e cada nó usa um desses módulos de memória como a memória local
do processador. Cada nó contém um processador, mas isso não é uma exigência.
Embora a implementação do esquema de interconexão possa variar, os processadores são conectados
diretamente a seus módulos de memória local e conectados indiretamente ao restante da memória global. Esse
arranjo proporciona acesso mais rápido à memória localdo que ao restante da memória global, porque o acesso
à memória global requer que se percorra a rede de interconexão.
Sem acesso à memória remota - NORMA
Multiprocessadores sem acesso à memória remota - No Remote Memory Access (NORMA) - são
multiprocessadores fracamente acoplados que não fornecem nenhuma memória global compartilhada. Cada nó
mantém sua própria memória local, e multiprocessadores NORMA implementam, frequentemente, uma memória
virtual compartilhada comum – Shared Virtual Memory (SVM).
NUMA com cache coerente (CC-NUMA)
- -7
NUMAs com cache coerente - Cache Coherent NUMAs (CC-NUMAs) - são multiprocessadores NUMA que im-põem
coerência de cache. Em uma arquitetura CC-NUMA típica, cada endereço de memória física está associado a um 
 (muitas vezes, o nó nativo é simplesmente determinado pelos bits de ordem mais alta do endereço),nó nativo
responsável por armazenar o item de dado com aquele endereço de memória principal.
Arquitetura de memória somente de cache - COMA
Em um sistema NUMA, cada nó mantém sua própria memória local, cujo acesso pode ser feito por processadores
de outros nós. Muitas vezes, o acesso à memória local é radicalmente mais rápido do que o acesso à memória
global (ou seja, o acesso a outro nó da memória local).
A latência de falta de (tempo requerido para recuperar dados que não estão nocache (cache-miss tatency)
cache) pode ser significativa quando o dado requisitado não estiver presente na memória local. Um modo de
reduzir a latência de falta de cache é reduzir o número de requisições de memória atendidas por nós remotos.
Os multiprocessadores de arquitetura de memória somente de cache - Cache Only Memory Architecture (COMA)
- usam uma ligeira variação da NUMA para abordar essa questão do posicionamento da memória.
4 Programação distribuída
A programação distribuída pode ser:
Sequencial – Composta por um conjunto de instruções que são executadas sequencialmente.
Concorrente – Permite execução concorrente de tarefas dentro de um mesmo processo ou entre processos que
compartilham recursos.
Paralela – Pressupõe a existência de mais de uma CPU, pois é destinada à execução simultânea de tarefas de um
mesmo processo.
5 Execução de uma tarefa
Existem três maneiras de executar uma tarefa de forma mais rápida, quais sejam:
Aumento da velocidade da CPU
Algumas limitações estão associadas à aquisição de CPUs com maior poder de processamento, como o aumento
de seu custo e a previsão para a velocidade dos processadores duplicarem a cada 18 meses (Lei de Moore), que
tem sido mantida até os dias atuais.
Mesmo com o aumento da frequência das CPUs, há a possibilidade de essas não atenderem à solução de alguns
problemas.
Otimização do Algoritmo
- -8
Geralmente, conseguimos aumentar o desempenho de um sistema com a melhora do algoritmo. Entretanto, esse
sistema pode ser comprometido quando não há uma solução determinística para o problema.
Colaboração
Quando pensamos em trabalhar com colaboração, devemos atentar para a diferença entre paralelismo e
concorrência. Veja:
• Paralelismo - Execução de uma tarefa em mais de uma CPU (os processadores colaboram para execução dessa
tarefa);
• Concorrência – Os processos disputam CPUs (uma ou mais).
6 Aspectos técnicos da programação distribuída
Veja alguns aspectos técnicos da programação distribuída:
Interação da aplicação e do usuário com o ambiente distribuído em níveis diferentes;
Suporte a plataformas heterogêneas através de uma camada de entre o e a aplicaçãosoftware kernel
(middleware);
Problemas como custo e carência de produtos de adequados;software
Programação paralela, utilizando bibliotecas de troca de mensagem (como, por exemplo, o MPI e o PVM) ou
bibliotecas baseadas em memória compartilhada (como, por exemplo, Pthreads).
A troca de mensagens (message passing) é o método de comunicação baseada no envio e recebimento de
mensagens através de uma rede de computadores, seguindo regras de protocolo de comunicação entre vários
processadores que possuam memória própria.
Os processos possuem acesso à memória local. As informações, por sua vez, são enviadas da memória local do
processo à memória local do processo remoto. Nesse modelo, o programador é responsável pela sincronização
de tarefas.
O que vem na próxima aula
Na próxima aula, você vai estudar:
•Introdução aos modelos de comunicação e a arquitetura cliente/servidor;
•O que é um modelo e quais são as características dos modelos arquitetural e fundamental;
•Fundamentos e características de cada componente do modelo cliente/servidor.
- -9
CONCLUSÃO
Nesta aula, você:
• Conheceu a classificação de multiprocessadores em relação à quantidade de fluxo de dados e instruções, 
e em relação ao acesso à memória;
• Verificou o desenvolvimento de aplicações para as arquiteturas MIMD.
•
•
- -1
ARQUITETURA DE SISTEMAS 
DISTRIBUÍDOS
INTRODUÇÃO AOS MODELOS DE 
COMUNICAÇÃO E A ARQUITETURA 
CLIENTE/SERVIDOR
- -2
Olá!
Objetivo desta Aula
Nesta aula, você irá:
1. Reconhecer um modelo de comunicação;
2. Identificar os modelos arquitetural e fundamental e suas características;
3. Descrever os fundamentos e as características de cada componente do modelo cliente/servidor.
Introdução
Nesta aula, você entenderá o que é um modelo de comunicação. Em seguida, você conhecerá as características
dos modelos arquitetural e fundamental e saberá como pode implementá-los.
Por fim, você conhecerá as principais características e os componentes da arquitetura cliente/servidor.
1 Introdução aos modelos de comunicação
Os sistemas desenvolvidos para a utilização em ambientes do mundo real devem ser projetados para funcionar
corretamente na maior variedade possível de circunstâncias e frente às dificuldades e ameaças.
Os modelos de sistemas distribuídos podem ser classificados como:
Arquiteturais
Aqueles que definem a forma como os componentes dos sistemas interagem.
Fundamentais
Aqueles que definem o comportamento e as propriedades dos componentes.
2 Modelos de Arquitetura de Sistemas Distribuídos
A arquitetura ou organização de um sistema representa sua estrutura em termos de componentes especificados
separadamente. Essa estrutura deve atender às demandas atuais e futuras impostas sobre ela.
A maior preocupação é tornar o sistema:
· Confiável
· Gerencial
· Adaptável
· Rentável
- -3
O modelo de arquitetura de um sistema distribuído primeiramente simplifica e abstrai as funções dos
componentes individuais desse sistema.
3 Características dos modelos de arquitetura
Os modelos de arquitetura de um sistema distribuído apresentam estrutura em camadas de software de
diferentes níveis de abstração, quais sejam: (denominação frequente para as camadas de plataforma hardware
e de nível mais baixo) e (camada de que tem como objetivo mascarar asoftware middleware software
heterogeneidade e fornecer um modelo de programação conveniente para os desenvolvedores de aplicações
distribuídas).
Para definir o padrão de distribuição, devemos considerar o posicionamento e a carga de trabalho de cada
componente. Além disso, as tarefas devem ser alinhadas de forma a atender aos requisitos de desempenho e
confiabilidade.
Os modelos de arquitetura classificam-se como:
• Cliente/servidor;
• Peer-to-peer;
• De (utilização de serviços oferecidos por diversos servidores). variações
Nesta aula, estudaremos mais especificamente o modelo cliente/servidor.
Requisitos de projeto dos modelos de arquitetura
Veja, a seguir, quais são os requisitos de projeto dos modelos de arquitetura!
Desempenho
- -4
Os desafios decorrentes da distribuição de recursos excedem a necessidade de gerenciamento das atualizações
concorrentes.
Os principais problemas associados à limitação finita da capacidade de recursos de processamento e de
comunicação são: reatividade, throughput e balanceamento de carga.
Qualidade de serviço
As principais propriedades não funcionais dos sistemas que afetam a qualidade dos serviços fornecidosaos
clientes são:
• Confiabilidade;
· Segurança;
· Desempenho;
· Adaptabilidade;
· Disponibilidade.
Replicação
Os problemas de desempenho podem ser (em parte) solucionados através do uso de replicação de dados.
Dependabilidade
A dependabilidade pode ser definida como correção, segurança e confiabilidade.
Trata-se de um requisito necessário à maior parte dos dominios da aplicação, o que significa que é crucial não
apenas nas atividades de comando e controle, mas também em muitas aplicações comerciais.
Como um par de programas pode-se encontrar em uma rede tão larga quanto a internet?
Modelo cliente/servidor
Como a maioria das redes, a internet utiliza um mecanismo simples: um aplicativo é ligado primeiro e espera que
o outro aplicativo faça contato. O segundo aplicativo, por sua vez, precisa conhecer a localização na qual o
primeiro aplicativo espera contato.
O acordo no qual um aplicativo de rede espera pelo contato de outro é conhecido como paradigma cliente-
servidor ou arquitetura cliente-servidor.
O programa que espera pelo contato é chamado de servidor, e o que inicia o contato é conhecido co-mo cliente.
Para iniciar contato, o cliente precisa saber onde o servidor está rodando e especificar a localização para o
software de rede.
Mas, como um cliente especifica a localização de um servidor?
Por exemplo, na Internet, a localização é dada por um par de identificadores. Conceitualmente, o par consiste
em: (o termo computador identifica a máquina na qual o servidor está rodando) e (ocomputador aplicativo 
aplicativo identifica um programa aplicativo em particular naquele computador).
- -5
4 Modelos de Arquitetura de Sistemas Distribuídos
Geralmente, os aplicativos desenvolvidos para a internet seguem o mesmo paradigma básico quando se
comunicam. Dois aplicativos estabelecem comunicação, trocam mensagens e, só então, finalizam a comunicação.
Sendo assim, para fins de comunicação, os aplicativos seguem os seguintes passos:
O aplicativo servidor é ativado e aguarda o contato de um cliente.
O cliente especifica a localização do servidor e solicita o estabelecimento de uma conexão.
Após o estabelecimento da conexão, cliente e servidor estão aptos a trocar mensagens.
Com a conclusão da transmissão, cliente e servidor enviam um fim de arquivo (end-of-file), e a conexão é
encerrada.
Application Program Interface (API)
vários desenvolvedores utilizam a expressão Application Program Interface (API) para descrever o conjunto de
aplicativos disponiveis a um programador.
A API especifica os parâmetros para cada operação bem como suas semânticas.
Application Program Interface (API)
Como exemplo, veja a tabela a seguir que lista as sete funções de uma API simples para a comunicação em uma
rede:
- -6
Um servidor inicia a aplicação chamando a função await contact para esperar pelo contato de um cliente. O
cliente, por sua vez, inicia a aplicação chamando a função make. contact para estabelecer contato.
Uma vez que o cliente te-nha contatado o servidor, eles podem trocar mensagens com send e recv. Os dois
aplicativos devem ser programados para saber se devem enviar ou receber se ambos tentarem receber sem
enviar, ficarão bloqueados para sempre.
Após o término do envio de dados, um aplicativo chama a função send eof para enviar a condição de fim de
arquivo (end-of-file). Do outro lado, a função recv retorna um valor zero para indicar que o fim de arquivo foi
alcançado.
Por exemplo, se o cliente executa a função send eof, o servidor vai encontrar um valor zero de retorno para sua
chamada à função recv. Uma vez que ambos os lados tenham invocado a função send eof, a comunicação é
encerrada.
Veja, a seguir, uma ilustração das chamadas API usadas para uma interação trivial, na qual o cliente envia um
pedido e recebe uma resposta:
- -7
5 Características dos modelos de arquitetura
Para manter a API exemplo, independente de algum sistema operacional e software de rede em particular, são
definidos três tipos de dados. Esses tipos são utilizados através de códigos.
A tabela a seguir lista os nomes e os significados de cada (em um dado computador, esses tipostipo de dados
são definidos como inteiros e de tamanho específico) usados na API exemplo:
6 O paradigma cliente-servidor
O paradigma de organizar uma aplicação que espera passivamente por outro aplicati-vo para iniciar a
comunicação está tão presente na computação distribuída que recebeu um nome: pa-radigma de interação
cliente-servidor.
Os termos cliente e servidor referem- se aos dois aplicativos envolvidos em uma comunicação. O aplicativo que
começa ativamente o contato é chamado de cliente, enquanto o aplicativo que espera passivamente por contato é
denominado servidor.
Veja, a seguir, uma figura que representa o paradigma cliente-servidor:
- -8
Fonte: Figura disponível no link. Acesso em: 29 fev. 2012. http://arqsystemsarmtecseduc.blogspot.com/2011/08
/aplicacao-cliente-servidor.html
7 Características de clientes e servidores
Embora existam variações, em geral, a interação cliente-servidor tem as mesmas características.
O software cliente é uma aplicação qualquer arbitrária que se torna um cliente temporariamente, quando o
acesso remoto for necessário, mas pode executar, também, outro processamento local.
Esse software é diretamente invocado por um usuário e executa somente para uma sessão. Essa execução ocorre
localmente no computador pessoal de um usuário.
O software cliente inicia ativamente o contato com um servidor e, quando necessário, pode acessar múltiplos
serviços, mas contata, de forma ativa, um servidor remo-to de cada vez. O referido software não exige hardware
especial ou sistema operacional sofisticado.
Em contraste, o software servidor é um programa privilegiado, de propósito especial, dedicado a fornecer um
serviço, mas pode tra-tar, simultaneamente, de múltiplos clientes remotos.
Esse programa é automaticamente invocado quando um sistema inicializa (boot) e continua a executar por mui-
tas sessões.
O software servidor executa em um computador compartilhado, e não em um computador pessoal de um
usuário, esperando, passivamente, pelo contato de clientes remotos arbitrários. O referido programa aceita o
contato de clientes arbitrários, mas oferece um único serviço.
Diferentemente do software cliente, o servidor exige hardware poderoso e um sistema operacional
sofisticado.
- -9
8 Requisições, Respostas e Direção do Fluxo de Dados
A comunicação entre cliente e servidor pode ser realizada em uma ou ambas as direções.
Um cliente envia uma requisição para um servidor; este, por sua vez, devolve uma resposta para o cliente. Em
alguns casos, um cliente envia uma série de requisições, e o servidor emite uma série de respostas.
Como exemplo, podemos citar um cliente de uma base de dados que poderia permitir a um usuário a consulta de
mais de um item por vez.
Em outros casos, o servidor fornece saída continua sem qualquer requisição assim que o cliente contata o
servidor, este começa a enviar-lhe dados.
Como exemplo, podemos citar um servidor local de dados climáticos, que poderia enviar, com frequência,
relatórios sobre os valores de tempo, com temperatura e pressão barométrica atualizadas continuamente.
Veja, a seguir, uma figura que representa o processo de comunicação realizado entre cliente e servidor:
9 Protocolos de transporte e interação cliente-servidor
Como a maioria dos programas aplicativos, cliente e servidor usam um protocolo de transporte para se
comunicar.
Como exemplo, podemos citar um cliente e um servidor que usam a pilha do TCP/IP. Um aplicativo cliente ou
servidor interage diretamente com um protocolo da camada de transporte para estabelecer uma comunicação e
enviar ou receber informações.
O protocolo de transporte usa, então, os protocolos das camadas mais baixas para enviar e receber mensagens
individuais. Desse modo, um computador necessita de uma pilha completa de protocolos para executar um
cliente ou um servidor.- -10
10 Múltiplos serviços em um computador
Um sistema suficientemente poderoso pode gerenciar a execução de múltiplos clientes e servidores ao mesmo
tempo.
Entretanto, para isso, algumas características são necessárias, quais sejam:
Primeiro
O computador deve ter recursos de suficientes;hardware
Segundo
O computador deve ter um sistema operacional que permita que múltiplos programas aplicativos executem de
modo concorrente (como, por exemplo, os sistemas UNIX, Linux ou Windows).
11 Identificando um serviço particular
Os protocolos de transporte fornecem um mecanismo que permite a um cliente especificar, de forma não
ambígua, qual o serviço desejado. Esse mecanismo designa cada serviço com um identificador único, e exige que
o servidor e o cliente usem esse identificador.
Múltiplas cópias de um servidor para um único serviço
Quando um sistema permite que múltiplos aplicativos estejam ativos ao mesmo tempo, podemos afirmar que
esse sistema suporta concorrência.
Portanto, um programa que tem mais de um thread de controle é chamado de programa concorrente.
A concorrência é fundamental para o modelo cliente-servidor de interação, porque um servidor concorrente
oferece serviço para múltiplos clientes ao mesmo tempo, sem exigir que cada cliente espere os clientes
anteriores terminarem a operação.
O que vem na próxima aula
Na próxima aula, você vai estudar:
· Comunicação a partir da utilização de sockets e Chamada a Procedimento Remoto (RPC);
· Como uma aplicação é desenvolvida;
· Como funciona a programação com socket;
· O funcionamento e a forma de geração de uma Chamada a Procedimento Remoto (RPC).
- -11
CONCLUSÃO
Nesta aula, você:
• Conheceu as características dos modelos arquitetural e fundamental;
• Conheceu as principais características e os componentes da arquitetura cliente/servidor.
•
•
- -1
ARQUITETURA DE SISTEMAS 
DISTRIBUÍDOS
COMUNICAÇÃO USANDO SOCKETS E 
CHAMADA A PROCEDIMENTO REMOTO 
(RPC)
- -2
Olá!
Objetivo desta Aula
Ao final desta aula, o aluno será capaz de:
1- Reconhecer como uma aplicação é desenvolvida;
2- Identificar como funciona a programação com socket;
3- Estabelecer o funcionamento e a forma de geração de uma Chamada a Procedimento Remoto (RPC).
Introdução
Nesta aula, você entenderá como funciona a programação com sockets e conhecerá o funcionamento de uma
Chamada a Procedimento Remoto (RPC).
1 Comunicação utilizando sockets
A comunicação realizada a partir da utilização de sockets é um mecanismo de comunicação entre processos –
Inter Process Comunication (IPC) – através da rede, que pode ser utilizado em processos na mesma máquina.
Interface de Programa Aplicativo – Application Program Interface (API)
As aplicações cliente e servidor utilizam protocolos de transporte para se comunicar. Para tal, essas aplicações
devem especificar detalhes. Por exemplo, o remetente deve especificar os dados a serem enviados, e o receptor,
onde esses dados recebidos devem
ser colocados.
Como uma API define um conjunto de operações que um aplicativo pode executar quando interage com o
software de protocolo, essa interface determina a funcionalidade que está disponível.
2 A API de sockets
Os protocolos de comunicação geralmente não especificam a API que as aplicações devem utilizar. Ao contrário
disso, os protocolos especificam quais são as operações que devem ser fornecidas e permitem que cada sistema
operacional defina a API específica que uma aplicação deve usar para executar suas operações.
A API de sockets (ou somente sockets) originou-se como parte do sistema operacional
BSD UNIX (University of California - Berkeley). Tanto neste quanto nos sistemas que dele derivaram, as funções
de sockets são parte do próprio sistema operacional.
- -3
Para um programador, seu programa chama procedimentos de sockets, que são, então, providos por
procedimentos do sistema operacional ou por rotinas de biblioteca.
Desse modo, um aplicativo que usa sockets pode ser copiado para um novo computador, compilado, carregado
junto com a biblioteca de sockets do computador e, então, executado.
3 Comunicação de socket e entrada e saída do UNIX
Originalmente, os sockets foram desenvolvidos como parte do sistema operacional UNIX e utilizam diversos
conceitos que são implementados em outras partes desse sistema.
Um programa vê os sockets como um mecanismo de entrada e saída de dados, pois eles seguem o paradigma
open-read-write-close, usado pela maioria das operações de entrada e saída.
Sendo assim, um socket deve ser criado, usado e, só então, destruído. Por isso, quando uma aplicação se
comunica através de uma rotina similar ao socket, forma um caminho para a aplicação transferir dados a um
arquivo. Dessa forma, a compreensão dos sockets exige o entendimento das características de entrada e saída do
UNIX.
Por exemplo, um aplicativo deve primeiro chamar open para preparar um arquivo para acesso. O aplicativo
chama, então, ou para recuperar ou armazenar dados no arquivo. Finalmente, o aplicativo chama read write
 para especificar que terminou de usar o arquivo.close
A figura a seguir representa uma conexão por sockets:
- -4
4 Sockets e descritores
A comunicação através de sockets utiliza também a abordagem de descritor. Quando a aplicação solicitar ao
sistema operacional para criar um socket, o aplicativo passará o descritor como um argumento para a chamada
de procedimentos na (não é necessário que a aplicação especifique detalhes sobre otransferência de dados
destino para cada transferência de dados) através da rede.
O sistema operacional fornece um único conjunto de descritores para arquivos, dispositivos, comunicação entre
processos e comunicação de rede. Como resultado, procedimentos como são bem gerais - umaread e write
aplicação pode usar o mesmo procedimento para enviar dados para outro programa ou um arquivo através de
uma rede.
Em terminologia corrente, o descritor representa um objeto e o procedimento write, o método aplicado àquele
objeto.
Parâmetros e a API de sockets
A programação por difere da entrada e saída convencional de dados porque um aplicativo devesocket
especificar diversos detalhes para utilizar um socket.
Por exemplo, um aplicativo deve escolher um protocolo de transporte em particular, fornecer o endereço de
protocolo de uma máquina remota e especificar se o aplicativo é cliente ou servidor.
Para acomodar todos os detalhes, cada socket tem diversos parâmetros e opções - um aplicativo pode fornecer
valores para cada um deles.
Para evitar que exista uma única função de socket com argumentos separados para cada opção, os
desenvolvedores das APIs de sockets definiram diversas funções. Essencialmente, um aplicativo cria um socket
e, então, invoca funções para especificar, em detalhes, como ele será usado.
A vantagem da abordagem de sockets respalda-se no fato de que a maioria das funções tem três ou menos
argumentos.
A desvantagem, por sua vez, indica que um programador deve lembrar-se de chamar múltiplas funções sockets.
Procedimentos que implementam a API de sockets
Conheça, agora, os procedimentos que implementam a API de sockets:
Procedimento socket
O procedimento socket cria um socket e retorna um descritor inteiro.
Conheça o procedimento socket:
sockfd = socket (protofamity, type, protocol);
São argumentos desse procedimento:
- -5
protofamity - especifica a familia de protocolos a ser usada com o socket;
type - especifica o que o socket usará;tipo de comunicação
protocol - especifica um protocolo de transporte particular usado com o socket.
Tipo de comunicação – Os tipos mais comuns são (transferência de stream orientada à conexão)sock_stream
e (transferência sem conexão orientada a mensagens).sock_dgram
Procedimento bind
Uma vez que tenha um socket, você deve associá-lo a uma porta em sua máquina.
Um servidor usa o procedimento bind para prover um número de porta de protocolo em que o servidor esperará
por contato.
Conheça o procedimento bind:bind (sockfd, localaddr, addrten);
São argumentos desse procedimento:
sockfd - descritor de socket retornado por socket);
tocataddr - estrutura que especifica o endereço local a ser designado ao socket;
addrten - inteiro que especifica o comprimento do endereço.
Os sockets podem ser utilizados com diferentes protocolos, e o formato de um endereço depende de cada
protocolo.
O formato genérico para representar um endereço é definido como estrutura sockaddr.
Embora várias versões tenham sido liberadas, o código de Berkeley mais recente define uma estrutura sockaddr
com três campos, quais sejam:
struct sockaddr {
u_char as_len; /* comprimento total do endereço */
u_char sa_family; /* família do endereço */
char sa_data [14]; /* o endereço propriamente dito */
Os referidos campos indicam o seguinte:
sa ten campo de um único bit, que especifica o comprimento do endereço;
sa famity campo que especifica a família à qual um endereço pertence (a constante simbólica af. inet é usada
para endereços TCP/IP);
sa data campo que contém o endereço.
Cada familia de protocolos define o formato exato dos endereços usados com o campo sa data de uma estrutura
sockaddr. Por exemplo, protocolos TCP/IP usam a para definir um endereço. Veja:estrutura sockaddr_in
struct sockaddr_in {
- -6
u_char sin_len; /* comprimento total do endereço */
u_char sin_family; /* familia do endereço */
u_short sin_port; /* número de porta de protocolo */
struct in_addr sin_addr; /* endereço IP de computador */
Procedimento connect
Os clientes usam o procedimento para estabelecer uma conexão com um servidor específico.connect
Conheça o procedimento :connect
connect (sockfd, saddress, saddressten);
São argumentos desse procedimento:
sockfd - descritor de socket retornado pela chamada socket() no computador do cliente, que é utilizado para a
conexão;
saddress - estrutura sockaddr que especifica o endereço do servidor e o número de porta de protocolo;
saddresslen - especifica o comprimento do endereço do servidor medido em bytes.
O procedimento connect, que é chamado por clientes, pode ser usado de duas formas. Quando usado com
transporte orientado
à conexão, o connect estabelece uma conexão de transporte com um servidor especificado. Quando usado com
transporte sem
conexão, o connect registra o endereço do servidor no socket, permitindo ao cliente enviar muitas mensagens
para o mesmo
servidor, sem exigir que especifique o endereço de destino em cada uma.
Procedimento listen
Depois de especificar uma porta de protocolo, o servidor deve instruir o sistema operacional para colocar um
socket em modo passivo, para que este possa ser usado para esperar pelo contato de clientes.
Para fazer isso, um servidor chama o procedimento , indicando ao kernet que está apto a receber conexões.listen
Conheça o procedimento listen:
listen (sockfd, backiog);
São argumentos desse procedimento:
sockfd - descritor de um socket criado e amarrado a um endereço local;
backtog - especifica o número de conexões permitidas, isto é, um comprimento para a fila de requisição do
socket.
Procedimento accept
- -7
Os servidores iniciam-se chamando socket (para criar um socket) e bind (para especificar um número de porta
de protocolo).
Após executar as duas chamadas, o servidor que usa um protocolo de transporte sem conexão está pronto para
aceitar mensagens.
No caso de o servidor utilizar um protocolo de transporte orientado à conexão, é necessário chamar o
procedimento tisten para colocar o socket em modo passivo e, então, aceitar uma requisição de conexão.
Quando a conexão for aceita, o servidor poderá utilizá-la para se comunicar com um cliente.
O servidor que usa transporte orientado à conexão deve chamar o procedimento accept para aceitar a próxima
requisição de conexão. Se uma requisição está presente na fila, o accept retorna imediatamente; se nenhuma
requisição chegou, o sistema boqueia o servidor até que um cliente forme uma conexão.
Conheça o procedimento :accept
accept (sockfd, caddress, caddressten);
São argumentos desse procedimento:
sockfd - descritor de um socket a uma por-ta de protocolo especifica;
caddress - endereço de uma estrutura do tipo ;sockaddr ou sockaddr_in
caddressten - variável inteira local.
O cria um novo socket para a conexão e retorna o descritor do novo socket para quem o chamou. Oaccept 
servidor usa o novo socket para se comunicar com o cliente e, quando termina, fecha-o.
Enquanto isso, o socket original do servidor permanece inalterado - após o término da comunicação com o
cliente, o servidor
Procedimentos send, sendto e sendmsg
Os clientes e servidores precisam enviar informações. Geralmente, um cliente envia uma requisição e um
servidor envia uma resposta.
Se o socket está conectado, o procedimento pode ser usado para transferir dados.send
Conheça o procedimento : send
send (sockfd, data, length, flags);
São argumentos desse procedimento:
sockfd - descritor do socket a ser usado;
data - ponteiro para os dados que se deseja enviar;
length - tamanho dos dados em bytes;
flags - contém bits que requisitam opções especiais.
- -8
Os procedimentos sendto e sendmsg permitem que o cliente ou o servidor envie uma mensagem usando um
socket não conectado, mas ambos exigem que um destino seja especificado. O sendto possui o endereço de
destino como argumento.
Conheça o procedimento sendto:
sendto (sockfd, data, length, flags, destaddress, addresslen);
São argumentos desse procedimento:
Os primeiros quatro argumentos correspondem aos quatro argumentos do procedimento send;
Os dois últimos argumentos especificam o de um destino e seu comprimento.endereço 
O procedimento executa a mesma operação que o procedimento , mas abrevia os argumentos,sendmsg sendto
definindo uma estrutura. A lista de argumentos mais curta pode tornar os programas que usam sendmsg mais
fáceis de serem lidos.
Conheça o procedimento sendmsg:
sendmsg(sockfd, msgstruct, flags);
O argumento desse procedimento é o msgstruct, uma estrutura que contém:
As informações sobre o endereço de destino;
O comprimento do endereço;
A mensagem a ser enviada;
O comprimento da mensagem.
Veja:
struct msgstruct { /* estrutura usada por sendmsg */
struct sockaddr*m_saddr; /* ponteiro para endereço de destino */
struct datavec *m_dvec; /* ponteiro para mensagem (vetor) */
int m_dvlength; /* número de itens no vetor */
struct access *m_rights; /* ponteiro para acessar lista de direitos */
int m_alength; /* número de itens na lista */
Procedimentos recv, recvfrom e recvmsg
O cliente e o servidor precisam receber dados enviados pelo outro. Para tal, a API de sockets fornece vários
procedimentos que podem ser usados. Por exemplo, um aplicativo pode chamar para receber dados de umrecv
socket conectado.
Conheça o procedimento recv:
recv (sockfd, buffer, length, flags)
São argumentos desse procedimento:
- -9
sockfd descritor de um socket, a partir do qual os dados devem ser recebidos;
buffer especifica o endereço em memória no qual a mensagem recebida deve ser colocada;
tength especifica o tamanho do buffer;
flags permite que se (por exemplo, o argumento flags possibilita a um aplicativoextrair umacontrolem detalhes 
cópia de uma mensagem recebida sem remover a mensagem do socket).
Se um socket não está conectado, ele pode ser usado para receber mensagens de um conjunto arbitrário de
clientes. Em tais casos, o sistema retorna o endereço do remetente junto com cada mensagem recebida.
Os aplicativos usam o procedimento para receber uma mensagem e q endereço de seu remetente.recvfrom
Conheça o procedimento :recvfrom
recvfrom (sockfd, buffer, length, flags, sndraddr, saddrten)
São argumentos desse procedimento:
Os primeiros quatro argumentos correspondem aos argumentos de recv;
sndraddr e saddrien usados para registrar o endereço IP do remetente;
sndraddr ponteiro para uma estrutura sockaddr em que o sistema escreve q endereço do remetente;
saddrlen ponteiro para um inteirousado pelo sistema para registrar o comprimento do endereço.
O recvfrom registra o endereço do remetente exatamente da mesma forma que sendto espera.
A API de sockets inclui um procedimento de entrada equivalente ao procedimento de saida sendmsg. O
procedimento recymsg opera como recvfrom, mas exige menos argumentos.
Conheça o procedimento :recyvmsg
recvmsg(sockfd, msgstruct, flags)
O argumento desse procedimento é o msgstruct, que dá ao endereço de uma estrutura que possui o endereço
para uma mensagem recebida, bem como posições para o endereço IP do remetente.
O msgstruct registrado por recvmsg usa exatamente o mesmo formato que a estrutura esperada por sendmsg.
Desse modo, os dois procedimentos funcionam bem para receber uma mensagem e enviar uma resposta.
Procedimento close
O procedimento close informa ao sistema para finalizar o uso de um socket.
Conheça o procedimento close:
close (sockfd);
O argumento desse procedimento é o sockfd: o descritor para um socket que está sendo fechado. Se o socket está
usando um protocolo de transporte orientado à conexão, o close termina a conexão antes de fechar o socket.
- -10
O fechamento de um socket finaliza imediatamente seu uso o descritor é liberado, impedindo que o aplicativo
envie mais dados, e o protocolo de transporte para de aceitar mensagens recebidas direcionadas para o socket,
impedindo que o aplicativo receba mais dados.
Comunicação por sockets com TCP
Veja como acontece a comunicação por sockets com TCP:
Servidor
socket ()
Criação de um socket com
Domínio: Internet
Tipo: stream
Protocolo: TCP
bind ()
Atribuição ao socket
Endereço porta de comunicação
listen ()
Declaração
Está apto a receber conexões
Tamanho da fila
Accept ()
Bloqueio até que haja a solicitação de conexão
Cliente
Socket ()
Criação de um socket idêntico ao servidor (mesmo domínio e tipo)
Connect ()
Solicita uma conexão ao servidor
Bloqueio ou retorno do erro
Caso seja aceito, fecha a conexão
Send ()
Envio de uma sequência de bytes
Recebimento da mensagem enviada pelo send
Recv ()
Close ()
- -11
Transmissão ou confirmação de mensagens faltantes
Encerramento da conexão
Fechamento do socket
Comunicação por sockets com UDP
Agora veja como acontece a comunicação por com UDP:sockets 
Criação dos sockets pelo Cliente e Servidor
Definição dos endereços pelo Cliente e Servidor
Recebimento do pacote enviado ou será bloqueado se não houver.
Envio do pacote para o endereço informado
- -12
5 Comunicação utilizando Chamada a Procedimento 
Remoto (RPC)
Além das tarefas habituais, o programador que constrói qualquer aplicação cliente-servidor deve, também, lidar
com os detalhes complexos de comunicação.
Mesmo que muitas das funções necessárias sejam fornecidas por uma API padrão (como a interface de socket,
por exemplo), é necessário que sejam especificados os nomes, os endereços, os protocolos e as portas, entre
outros detalhes.
O ponto positivo é que muitos sistemas cliente-servidor seguem uma mesma lógica de arquitetura básica e usam
a API de sockets para comunicação.
As similaridades entre as aplicações permitiram que um conjunto de ferramentas de software fosse criado para
gerar, automaticamente, o código para muitas das tarefas de comunicação, deixando o programador livre para se
concentrar em partes da programação que não podem ser automatizadas.
Paradigma de Chamada Remota de Procedimento – Remote Procedure Call (RPC)
Muitos sistemas distribuídos são baseados em troca explícita de mensagens entre processos. Contudo, os
procedimentos send e receive não escondem absolutamente nada da comunicação, o que é importante para
obter transparência de acesso em sistemas distribuídos.
Esse problema é conhecido há muito tempo, mas pouco tinha sido feito para resolvê-lo, até que um artigo de
autoria de (Birrel, A. D. and Nelson, B. J. (1984). Implementing remote procedure calls.Birrell e Nelson (1984)
ACM Transactions on Computer Systems, 2(1):39-59) propôs um modo completamente diferente de manipular a
comunicação. A proposta foi permitir que programas fossem capazes de chamar procedimentos localizados em
outras CPUs.
Quando um processo em uma máquina chama um procedimento em uma máquina remota, o processo chamador
(cliente) é suspenso, e a execução do procedimento chamado (servidor) ocorre na máquina remota.
A informação pode ser transportada, nos parâmetros, do cliente para o servidor e pode voltar no resultado do
procedimento. Nenhuma troca de mensagem ou entrada e saída é visível ao programador e tem servido de base
a muitos softwares para multicomputadores.
Em sua forma mais simples, para chamar um procedimento remoto, o programa cliente deve ser ligado a um
pequeno procedimento de biblioteca chamado de do cliente, que representa o procedimento servidor nostub
espaço de endereçamento do cliente. Da mesma maneira, o servidor é ligado a um procedimento denominado 
 do servidor.stub
- -13
Esses procedimentos escondem o fato de uma chamada de procedimento do cliente para o servidor não ser local.
Componentes da RPC
São componentes da RPC:
Cliente
Faz a chamada ao procedimento remoto.
Stud do cliente
Faz a interface com o runtime system (esconde chamadas de baixo nível da aplicação)
RPC Runtime
Comunicação entre dois computadores, que esconde os detalhes da comunicação de rede, transmissões,
confirmações, etc.
Servidor
Faz o atendimento da requisição.
Stud do servidor
Faz o mesmo que o stud do cliente.
Esquema de realização da RPC
Os passos para a realização de uma RPC são representados nesta figura, quais sejam:
- -14
A – O cliente chama o cliente – trata-se de uma chamada local, com os parâmetros colocados na pilha de umstub
modo convencional.
B – O do cliente empacota os parâmetros – o empacotamento dos parâmetros é chamado de marshalingstub
(preparação) – em uma mensagem e faz uma chamada de sistema para enviar essa mensagem.
C – O (núcleo) envia uma mensagem da máquina com o processo cliente para a máquina com o processokernel
servidor.
D – O passa o pacote recebido para o do servidor.kernel stub
E – O servidor chama o procedimento servidor.stub
ATENÇÃO!
A questão principal a ser notada é que o procedimento cliente, escrito pelo usuário, apenas faz uma chamada
normal de procedimento (local) para o stub do cliente.
Da mesma maneira, o procedimento servidor é chamado por uma rotina em seu espaço de endereçamento.
6 Tratamento de falhas com RPC
Para o tratamento de falhas com a RPC, devemos levar em consideração os seguintes aspectos:
O cliente não é capaz de localizar o servidor:
isso ocorre devido a uma falha de hardware e em função de o servidor não estar efetivamente disponível. O
tratamento específico desse erro elimina a transparência;
Perda de mensagem solicitando serviço:
nesse caso, devemos usar um contador de tempo; se o tempo expirar e a resposta não chegar, retransmita a
mensagem.
- -15
Perda de mensagem com resposta:
o que torna a mensagem idempotente
Quedas do servidor:
definir semântica - mínimo uma vez que garante que a chamada remota ao procedimento será executada no
mínimo uma vez ou no máximo uma vez que garante que a chamada remota foi executada no máximo uma única
vez.
Queda do cliente:
trata-se da situação em que o cliente manda uma requisição e, antes de receber a resposta, sai do ar. Essa
situação causa dois problemas: a geração de processos órfãos (zombie) e o tempo de CPU gasto
desnecessariamente pelo servidor.
O que vem na próxima aula
Na próxima aula, você vai estudar:
· Modelo Peer-to-Peer (P2P);
· Os componentes de comunicação e seus diferentes tipos de implementação.
CONCLUSÃO
Nesta aula, você:
• Conheceu as características da comunicação através de sockets e RPC;
• Identificou os principais componentes para a implementação da API de sockets.
•
•
- -1
ARQUITETURA DE SISTEMAS 
DISTRIBUÍDOS
MODELO PEER-TO-PEER (P2P)
- -2
Olá!
Objetivo desta Aula
Ao final desta aula, o aluno será capazde:
1- Reconhecer o modelo Peer-to-Peer (P2P) e seus componentes de comunicação;
2- Identificar os diferentes tipos de implementação desse modelo.
Introdução
Nesta aula, você estudará a importância e as características de algumas das aplicações do modelo Peer-to-Peer
(P2P).
O acesso à informação correta é considerado imensurável. Para compreendermos melhor essa questão, vamos
ampliar nosso estudo sobre as vantagens do uso de redes P2P no meio coorporativo.
Boa aula!
1 Comunicação P2P
O modelo de comunicação Peer-to-Peer (P2P) é implementado em uma rede de computadores cuja comunicação
não está baseada em servidores dedicados – como no modelo cliente-servidor –, e sim na comunicação direta
entre cada nó da rede (peers).
Cada computador conectado tem a capacidade de atuar como servidor – realizando tarefas para outros usuários
da rede – ou como cliente – requisitando a realização dessas tarefas.
Na comunicação P2P, indivíduos que constituem um grupo livre podem comunicar-se com outros participantes
do grupo. Em princípio, toda pessoa pode se comunicar com uma ou mais pessoas – não existe qualquer divisão
estrita entre clientes e servidores.
Veja, ao lado, uma figura de um sistema não hierárquico, em que não existem clientes e servidores estritos.
- -3
Fonte: Imagem disponível em: http://cefiosi1011.wikidot.com/icorli-david. Acesso em: 14 mar. 2012.
Diversos sistemas P2P – como o BitTorrent (COHEN, 2003) – não possuem qualquer informação centralizada. Ao
contrário, esses sistemas mantêm suas informações locais e compartilham uma lista dos peers vizinhos que os
compõem.
Quando uma nova consulta é realizada a um membro do sistema, é possível retornar com os nomes de seus
outros membros, para que a busca por mais conteúdo e mais nomes seja possível. Esse processo de pesquisa
pode ser repetido indefinidamente, até que se crie um grande banco de dados.
Normalmente, a comunicação P2P é usada para compartilhar diferentes tipos de arquivos. Essa comunicação
alcançou o auge por volta do ano 2000, com a criação do Napster por Shawn Fanning para o compartilhamento
de músicas entre amigos da faculdade.
Esse serviço foi encerrado depois daquilo que, provavelmente, foi a maior exposição sobre a violação de direitos
autorais em toda a história da tecnologia.
2 Redes P2P
Há uma grande dificuldade em montar uma rede de entrega de conteúdo – Content Delivery Networks (CDN) –
de 1000 nós no mundo inteiro para distribui-lo.
Na verdade, não é difícil alugar 1000 máquinas virtuais no mundo inteiro, devido à indústria de hospedagem
bem desenvolvida e altamente competitiva. Entretanto, conseguir os nós é só o início da montagem de uma CDN.
Mas, felizmente, existe uma alternativa para o restante de nós, que é simples de usar e pode distribuir uma
quantidade tremenda de conteúdo com uma rede P2P.
- -4
Uma vantagem é que a tecnologia P2P pode ser usada de diversas maneiras. Com seu desenvolvimento e grande
interesse por parte dos usuários, o tráfego P2P tornou-se, rapidamente, responsável por uma grande fração de
todo o tráfego na internet.
A ideia básica de uma rede de compartilhamento de arquivos P2P é que muitos computadores se juntem e
compartilhem seus recursos para formar um sistema de distribuição de conteúdo.
Normalmente, os computadores são apenas domésticos e chamados de peers (pares) porque cada um pode,
altemadamente, atuar como cliente para outro peer — buscando seu conteúdo — e como servidor — fornecendo
conteúdo para outros peers.
O que toma os sistemas P2P interessantes é o fato de que, diferente de uma CDN, não há, neles, uma
infraestrutura dedicada. Qualquer um participa da tarefa de distribuir conteúdo. Normalmente, também não há
um ponto de controle central nos sistemas P2P.
As redes P2P são autoescaláveis, e sua capacidade de upload útil cresce em conjunto com as demandas de
download que podem ser feitas por seus usuários. Em certo sentido, essas redes sempre são grandes o suficiente,
sem a necessidade de alguma infraestrutura dedicada.
Ao contrário disso, a capacidade até mesmo de um site Web grande é fixa e será ora muito grande ora muito
pequena.
Considere, por exemplo, um site com apenas 100 clusters, cada um capaz de trabalhar a 10 Gbps. Essa
capacidade enorme não ajuda quando existe um pequeno número de usuários. O site não pode receber
informações de N usuários em uma taxa mais rápida que N Mbps, pois o limite está nos usuários, e NÃO no site.
Quando existe mais de 1.000.000 de usuários a 1 Mbps, o site Web não pode bombear dados com rapidez
suficiente para manter todos ocupados fazendo download. Esse pode parecer um número considerável de
usuários, mas grandes redes BitTorrent (como, por exemplo, o Pirate Bay) afirmam ter mais de 10 milhões de
usuários. De acordo com essa abordagem, isso significa algo em torno de 10 terabits/s.
Uma curiosidade é que os sistemas P2P estão sendo explorados para serviços além do compartilhamento de
arquivos (como, por exemplo, para armazenamento e streaming). Os sistemas mais conhecidos são baseados no
protocolo BitTorrent.
Em um foco mais acadêmico, há um grande interesse nos algoritmos Distributed Hash Table (DHT), que
permitem aos sistemas P2P atuarem como um todo, embora não haja qualquer componente centralizado.
- -5
3 BitTorrent
O protocolo BitTorrent foi desenvolvido por Brahm Cohen, em 2001, para permitir que um conjunto de peers
compartilhasse arquivos rápida e facilmente. Existem dezenas de clientes disponíveis gratuitamente que
entendem esse protocolo.
Em um sistema P2P típico, como o BitTorrent, cada um dos usuários tem a mesma informação, que pode ser de
interesse de outros usuários. Essa informação pode ser um software gratuito, uma música, vídeos, fotografias
etc.
4 O surgimento dos sistemas P2P
O surgimento das redes de compartilhamento de arquivos P2P motivou a comunidade de pesquisa. A essência
dos sistemas P2P está no fato de que evitam as estruturas gerenciadas, de forma central, das CDNs e de outros
sistemas. Essa pode ser uma vantagem significativa.
Quando o sistema fica muito grande, os (os componentes centraiscomponentes gerenciados de forma central
também podem ser usados como um ponto de controle (por exemplo, para encerrar a rede P2P) tornam-se um
gargalo e correspondem a um ponto de falha isolado. Contudo, os primeiros sistemas P2P eram apenas
parcialmente descentralizados – se fossem totalmente descentralizados, seriam ineficazes.
Distributed Hash Tables (DHTs)
Em sua forma tradicional, o BitTorrent utiliza transferências P2P e um tracker centralizado para cada swarm.
Um dos problemas principais é como descobrir quais peers possuem o conteúdo específico que está sendo
procurado, já que cada peer poderia ter um ou mais itens de dados que outros usuários poderiam querer ler.
Mas como os outros usuários os encontram?
Distributed Hash Tables (DHTs)
Criar um índice de posse de cada um é simples, mas é centralizado. Fazer com que cada par mantenha seu
próprio índice também não soluciona o problema. Entretanto, exige bastante trabalho para manter atualizados
os índices de todos os peers – pois o conteúdo é movimentado pelo sistema –, o que não compensa o esforço.
A principal questão a ser respondida pela comunidade de pesquisa foi: seria possível criar índices P2P que
fossem totalmente distribuídos, mas que possibilitassem um bom desempenho?
O bom desempenho pode ser interpretado da seguinte forma:
Cada nó mantém apenas uma pequena quantidade de informação sobre outros nós, o que significa que não será
caro manter o índice atualizado.
- -6
Cada nó pode pesquisar, rapidamente, entradas no índice. Caso contrário, esse não será um índice muito útil.
Cada nó pode usar o índice ao mesmo tempo, ainda que outros nós apareçam e desapareçam. Essa pro-priedade
indica que o desempenho do índice aumenta com o número de nós.
A resposta para essa pergunta foi SIM. Para tal, foram desenvolvidas, em 2001, quatro soluções. São elas:
 (STOICA etal., 2001)(STOICA et al., 2001 – STOICA, I., MORRIS, R. KARGER, D., KAASHOEK, M.F eChord
BALAKRISSHNAN, H. – Chrord: A Scalable Peer-to-Peer Lookup Service for Internet Applications, Proc. SIGCOMM
2001 Conference, ACM p. 149-160, 2001.);
 (RATNASAMY et al., 2001)(RATNASAMY et al., 2001 – RATNASAMY S., FRANCIS, P., HANDLEY, M., KARP, E eCan
SHENKER, S. – A Scalable Content—Addresable Network, Proc. SIGCOMM 2001 Conference, ACM, p. 161 – 172,
2001.);
 (ROWSTRON; DRUSCHEL, 2001)(ROWSTRON; DRUSCHEL, 2001 – ROWSTRON, A. e DRUSCHEL, P. –Pastry
Pastry: Scalable Distributed Object Location and Routing for Large-Scale Peer-to-Peer Torage Utility, Proc. 18th
International Conference on Distributed Systems Platforms, Londres,: Springer-Verlag LNCS 2218, p. 329 – 350,
2001.);
 (ZHAO et al., 2004)(ZHAO et al., 2004 – ZHAO, B., LING, H., STRIBILING., J., RHEA., JOSEPH; A. eTapestry
KUBIATOWISCZ, J. – Tapestry: A resilient Global-Scale Overlay for Service Deployment, IEEE Journal, on Selected
Areas in Commum, vol. 22, p 41 – 53, january, 2004.).
Essas soluções são conhecidas como Distributed Hash Tables (DHTs), pois a funcionalidade básica de um índice é
mapear uma chave a um valor. Isso representa uma tabela de , e, naturalmente, as soluções são versõeshash
distribuídas.
As DHTs realizam seu trabalho impondo uma estrutura regular sobre a comunicação entre os nós. Esse
comportamento é muito diferente daquele das redes P2P tradicionais, que usam quaisquer conexões que os
peers façam.
Por esse motivo, as DHTs são chamadas de redes P2P estruturadas. Os protocolos P2P tradicionais montam
redes P2P desestruturadas (ou não estruturadas).
Como exemplo, utilizaremos a solução DHT Chord. Vamos conhecê-la?
5 Solução DHT Chord – Introdução
Pensando em um cenário, considere como substituir o tracker centralizado tradicionalmente – usado no
BitTorrent – por um tracker totalmente distribuído. A solução DHT Chord pode ser usada para resolver esse
problema.
- -7
Nesse cenário, o índice geral é uma listagem de todos os swarms aos quais o computador pode-se juntar para
baixar conteúdo. A chave usada para pesquisar o índice é a descrição do conteúdo pela torrent. Ela identifica um 
 exclusivamente, do qual o conteúdo pode ser baixado como os hashes de todos os de conteúdo.swarm chunks 
O valor armazenado no índice para cada chave é a lista de peers que compreendem o swarm. Esses peers são os
computadores que entram em contato para baixar o conteúdo. Uma pessoa que espera baixar conteúdo (como
um filme, por exemplo) tem apenas a descrição da torrent.
A pergunta que a DHT precisa responder é: como, sem um banco de dados central, uma pessoa descobre de quais 
(entre os milhões de nós BitTorrent) ela deve copiar o conteúdo?peers 
6 Solução DHT Chord – Nós
Uma DHT Chord consiste em N nós participantes. Eles são nós que executam BitTorrent em nosso cenário. Cada
nó tem um endereço IP pelo qual pode ser comunicado.
O índice geral está espalhado pelos nós. Isso significa que cada um armazena bits e pedaços do índice para uso
por outros. A parte central da Chord navega pelo índice usando (conceitualmente, osidentificadores 
identificadores são simplesmente números de M bits que podem ser arrumados em ordem crescente, em um
anel) em um espaço virtual, e não os endereços IP dos nós ou os nomes de conteúdo.
Para transformar um endereço de nó em um identificador, ele é mapeado para um número de M bits, usando
uma (função que captura uma sequeência de bytes de tamanho variável como argumento efunção de hash 
produz um número altamente aleatório de 160 bits). Sendo assim, podemos usá-lo para converter qualquer
endereço IP em um número de 160 bits – chamado de identificador de nó.
A figura abaixo representa um conjunto de 32 identificadores de nós organizados em um anel.
- -8
Os nós sombreados representam máquinas reais. Os arcos, por sua vez, mostram os fingers dos nós 1, 4 e 12.
Os rótulos nos arcos são os índices das seguintes tabelas de fingers:
Na figura, é representado o anel identificador de nó para M = 5. Nesse exemplo, os nós com identificadores 1, 4,
7, 12, 15, 20 e 27 estão sombreados e correspondem aos nós reais. O restante não existe.
Prosseguindo com nosso modelo, vamos definir a função sucessor (k) como identificador de nó do primeiro nó
real, após k, ao redor do anel (no sentido horário).
Por exemplo:
Sucessor (6) = 7;
Sucessor (8) = 12;
Sucessor (22) = 27.
- -9
7 Solução DHT Chord – Chave
Uma chave também é produzida pela execução do hashing de um nome de conteúdo com hash para gerar um
número de 160 bits (nome = torrent). Sendo assim, para converter o arquivo de descrição de torrent para sua
chave, calculamos: (esse cálculo é simplesmente uma chamada de procedimento localchave = hash(torrent)
para ).hash
Para iniciar um novo swarm, um nó precisa inserir um novo par chave-valor, que consiste no índice (torrent,
meu-endereço-IP). Para conseguir isso, o nó pede ao sucessor – hash(torrent) – para armazenar meu-endereço-
IP. Desse modo, o índice é distribuído pelos nós aleatoriamente.
Com a DHT construída, quando outro nó desejar encontrar uma torrent de modo a se juntar ao swarm e baixar o
conteúdo, um nó pesquisará a torrent primeiro, calculando seu hash para obter a chave. Depois, esse nó usará o
sucessor(chave) para encontrar o endereço IP do nó que armazena o (o valor é a lista de peers do .valor swarm
O nó pode acrescentar seu endereço de IP nessa lista e fazer contato com os outros peers para baixar o conteúdo
com o protocolo ) correspondente.BitTorrent
Solução DHT Chord IP
Para possibilitar a localização do endereço IP do nó correspondente a certa chave, cada nó precisa manter
determinadas estruturas de dados administrativas. Uma delas é o endereço IP de seu nó sucessor junto ao anel
identificador de nó. Por exemplo, na apresentada anteriormente, o sucessor do nó 4 é 7, e o sucessor do nó 7 é
12.
Agora, a pesquisa pode prosseguir da seguinte forma:
O nó solicitante envia um pacote a seu sucessor, contendo seu endereço IP e a chave que está procurando. O
pacote é propagado pelo anel até que localize o sucessor do identificador de nó procurado. Esse nó verifica se
possui qualquer informação que combine com a chave; caso haja, ele retorna a informação diretamente ao nó
solicitante, cujo endereço IP possui.
Entretanto, a busca linear de todos os nós é ineficaz com um grande sistema P2P, pois o número médio de nós
exigido por consulta é N/2. Para agilizar a busca, cada nó também mantém o que a Chord chama de tabela de
fingers, que contém M entradas, indexadas de 0 até M - l, cada uma apontando para um nó real diferente.
Cada uma das entradas tem dois campos; o início e o endereço ip do sucessor (início), como apresentado para
três nós no exemplo das tabelas de fingers.
Os valores dos campos para entrada / e um nó com indicador K são:
Início = K + 2º (módolu 2")
enderço IP do sucessor (inicio[i])
- -10
Cada nó armazena os endereços IP de um número relativamente pequeno de nós; a maioria desses nós é muito
próxima em termos de identificador de nó.
Usando as tablas de fingers, a pesquisa da chave no nó k prossegue da seguinte forma:
Se a chave ficar entre k e sucessor (k), O nó que mantém as informações sobre a chave será o sucessor(k), e a
busca terminará. Caso contrário, as tavelas de fingers serão varridas para que se encontre a entrada cujo campo
início é o predecessor mais próximo da chave.
Uma solicitação é, então, enviada diretamente ao endereço IP nessas tabelas de fingers, para pedir que a busca
continue. Por estar mais próxima da chave – mas ainda abaixo dela, há boa chance de que ela seja capaz de
retornar a resposta com apenas um pequeno número de consultas adicionais.
De fato, como cada pesquisa divide ao meio a distância restante até o destino, pode-se mostrar que o número
médio de pesquisas é Logan.
Exemplo 1
Considere a pesquisa da chave = 3 no nó 1. Como o nó 1 sabe que 3 se encontra entre ele e seusucessor (4), o nó
desejado é 4. Sendo assim, a busca termina, retornando o endereço IP de 4.
Exemplo 2
Considere a pesquisa da chave = 16 no nó 1. Como 16 não se encontra entre 1 e 4, as tabelas de fingers serão
consultadas. O predecessor mais próximo de 16 é 9, de modo que a solicitação é encaminhada para o endereço IP
da entrada 9 — aquela do nó 12.
O nó 12 também não sabe a resposta. Dessa forma, ele procura o nó mais próximo anterior a 16 e encontra 14,
que fornece o endereço IP do nó 15. Uma consulta é, então, enviada a esse endereço.
O nó 15 observa que 16 se encontra entre ele e seu su-cessor (20), de modo que retorna o endereço IP de 20
para quem o chamou. Esse, por sua vez, segue seu caminho de volta até o nó 1.
8 Solução DHT Chord – Considerações Finais
Visto que os nós entram e saem o tempo todo, o DHT Chord precisa de uma forma de lidar com essas operações.
Assumimos que, quando o sistema iniciou sua operação, ele era pequeno o suficiente para que os nós pudessem
apenas trocar informações diretamente para criar o primeiro anel e tabelas de fingers.
Depois disso, um procedimento automatizado é necessário.
Quando um novo nó (r) deseja-se conectar, ele precisa entrar em contato com um nó existente e pedir que este
pesquise o endereço IP do sucessor(r) para ele. Em seguida, o novo nó pede o predecessor do sucessor(r). Por
fim, o novo nó pede a ambos para inserir r entre eles e o anel.
- -11
Contudo, muitas tabelas de fingers podem estar erradas. Para corrigi-las, cada nó executa um processo em
segundo plano que recalcula, periodicamente, cada finger, chamando o sucessor. Quando uma dessas consultas
alcança um novo nó, a entrada de finger correspondente é atualizada.
Quando um nó sai de modo controlado, ele entrega suas chaves a seu sucessor e informa a seu predecessor sobre
sua saída, para que ele possa se vincular ao sucessor do nó que está saindo.
Quando um nó falha, surge um problema, pois seu predecessor não tem mais um sucessor válido. Para aliviar
esse problema, cada nó registra não apenas seu sucessor direto mas também seus sucessores diretos, para
permitir que ele pule até s - l nós consecutivos (com falhas) e reconecte o anel – em caso de queda
Alguns clientes BitTorrent utilizam DHTs para fornecer um tracker totalmente distribuído do tipo que
descrevemos. Grandes serviços de computação em nuvem, como o Dynamo da Amazon, por exemplo, também
incorporam técnicas de DHT (DECANDIA et al., 2007 – DECANDIA, G., HASTORIN, D.,(DECANDIA et al., 2007)
JAMPANI, M., KAKULAPATI, G., LAKSHMAN, A., PIL-CHIN, A., SIVASUBRAMANIAN, S., VOSSHALL, P. e VOGELS, W.
– Dynamo: Amazon’s Highly Available Key-value Store, Proc. 19th, Symposium on Operating Systems Prin., ACM,
p.205 – 220, december, 2007).
9 Exemplos de Redes P2P
Napster
O Napster usava um servidor central com replicação na realização da busca de arquivos em rede. Toda a
transferência de arquivos era realizada, de forma direta, entre os peers.
Kazaa
O Kazaa é uma aplicação híbrida entre a Gnutella e aplicações centralizadas. Nesse caso, um servidor autentica os
usuários.
Alguns nós servem como hubs de busca. As transferências, por sua vez, são realizadas entre pares e permitem a
cópia de partes dos arquivos.
eMule
O eMule utilizava servidores centrais na realização da indexação dos arquivos compartilhados pelos peers.
Todos os nós possuíam a permissão de conexão a diversos servidores durante o procedimento de buscas.
Toda a transferência de arquivos era feita, de forma direta, entre os peers, com a possibilidade de realização de
cópias, a partir de diferentes origens, em partes dos arquivos.
JXTA
- -12
O JXTA é uma aplicação criada pela Sun Microsystems. Trata-se de uma infraestrutura de rede P2P sobre a qual
podem ser criadas aplicações que independem de plataforma e linguagem.
Essa aplicação utiliza grupos de pares com interesses comuns, e suas mensagens são codificadas em XML.
Gnutella
Na Gnutella, o nó conecta-se à rede contactando qualquer nó que faça parte da rede que já existe. Todos os nós
são servidores e clientes; não há um servidor central.
Um protocolo determina quais as mensagens que podem ser transmitidas na rede.
O que vem na próxima aula
Na próxima aula, você vai estudar:
· Conceitos de sistemas de arquivos distribuídos;
· Semânticas de compartilhamento;
· Mecanismos de replicação.
CONCLUSÃO
Nesta aula, você:
• Conheceu os conceitos do modelo P2P;
• Conheceu detalhes de algumas aplicações P2P – entre elas, a BitTorrent e o DHT.
•
•
- -1
ARQUITETURA DE SISTEMAS 
DISTRIBUÍDOS
SISTEMAS DE ARQUIVOS DISTRIBUÍDOS
- -2
Olá!
Objetivo desta Aula
Ao final desta aula, o aluno será capaz de:
1- Descrever os conceitos de Sistemas de Arquivos Distribuídos;
2- Identificar as semânticas de compartilhamento e dos mecanismos de replicação.
Introdução
O acesso à informação correta é considerado como algo imensurável.
Para compreendermos melhor essa questão, nesta aula, vamos ampliar nosso estudo sobre as vantagens do uso
de Sistemas de Arquivos Distribuídos.
1 Distributed Files System (DFS)
Compartilhar dados é fundamental para sistemas distribuídos!
Os Sistemas de Arquivos Distribuídos Distributed File System (DFS) são a base para muitas aplicações
distribuídas, já que permitem que vários processos compartilhem dados, de modo seguro e confiável, por longos
períodos.
Por isso, esses sistemas têm sido usados como a camada básica para sistemas e aplicações distribuídas.
(TANENBAUM; STEEN, 2007).
Um sistema de arquivos fornece serviços de arquivo para (a interface cliente de um serviço de arquivo éclientes
formada por um conjunto de operações primitivas de arquivo, tais como criar, apagar, ler e gravar um arquivo).
O componente primário de hardware que um servidor de arquivos controla é um conjunto de dispositivos locais
de armazenamento secundário (geralmente, discos magnéticos), nos quais arquivos são armazenados e
recuperados, de acordo com as solicitações dos clientes.
Em um DFS, a atividade de serviço deve ser realizada através da rede.
Esse sistema pode ser implementado como parte de um sistema operacional distribuído ou, alternativamente,
por uma camada de software, cuja tarefa é gerenciar a comunicação entre sistemas operacionais convencionais e
sistemas de arquivos.
As características que diferenciam um DFS são a multiplicidade e a autonomia de clientes e servidores no
sistema.
- -3
1.1 Funções do DFS
O DFS deve aparecer para seus clientes como um sistema de arquivos convencional centralizado. Portanto, é de
sua responsabilidade localizar os arquivos e providenciar o transporte dos dados.
Essa transparência facilita a mobilidade do usuário, trazendo seu ambiente para onde quer que ele se conecte.
O referido sistema também possui, como importante medida de desempenho, a quantidade de tempo necessária
para o atendimento das requisições de serviço.
Em sistemas convencionais, esse tempo consiste no tempo de acesso ao disco e em um pequeno intervalo de
tempo de processamento da CPU.
Entretanto, em um DFS, um acesso remoto possui o (esse overhead inclui o tempo para liberar aoverhead
solicitação para um servidor bem como o tempo para retornar a resposta ao cliente através da rede) adicional
atribuído à estrutura distribuída.
Por fim, o DFS gerencia um conjunto de dispositivos de (o espaço total de armazenamento éarmazenamento 
composto por espaços menores, diferentes e localizados remotamente) dispersos.
1.2 Tipos de serviços
Serviço de armazenamento
Serviço relacionado à alocação e ao gerenciamento de espaço e operações para armazenamento e recuperação
de dados.
Serviço de arquivo
Serviço que trata das operações com arquivos independentes, incluindo:
· Modos de acesso;
· Políticas de caching;
· Semântica de compartilhamento;
· Replicação;
· Controle de concorrência;
· Consistência dos dados etc.
Serviço de nomeação
Serviço que fornece mapeamento entre nomes de arquivos e seus identificadores.
- -41.3 Nomeação e transparência
Em DFS, a nomeação é um mapeamento entre objetos lógicos e físicos. Já a transparência oculta o local em que o
arquivo está localizado na rede.
Dado um nome de arquivo, o mapeamento retorna um conjunto de localizações dessas réplicas do arquivo.
Nessa abstração, ficam ocultas tanto a existência de múltiplas cópias quanto sua localização.
Estruturas de nomeação
Veja, a seguir, as noções relacionadas aos mapeamentos de nomes em um DFS:
Transparência de localização (por exemplo: /Server X/dir y / dir w/arquivo Z) – nesse caso, o nome de um
arquivo não revela qualquer indicação de sua localização física de armazenamento;
Independência de localização – nesse caso, o nome de um arquivo não precisa ser alterado quando da
mudança de sua localização física de armazenamento.
Um esquema de nomeação independente de localização é um mapeamento dinâmico, já que se pode mapear o
mesmo nome de arquivo para diferentes locais em dois momentos distintos.
Portanto, a independência de localização é uma propriedade mais forte do que a transparência de localização.
Na prática, a maioria dos DFS atuais fornece um mapeamento estático e transparente de localização para nomes
no nível do usuário. Entretanto, esses sistemas não suportam a migração de arquivos. Em outras palavras, a
mudança automática da localização de um arquivo é impossível. Portanto, a noção de independência de
localização é irrelevante para esses sistemas.
Os arquivos são associados permanentemente a um conjunto específico de blocos de disco. Arquivos e discos
podem ser manualmente movimentados entre máquinas, mas a migração de arquivos implica uma ação
automática iniciada pelo sistema operacional.
Esquemas de nomeação
Abordagem mais simples
Nesse tipo de abordagem, o arquivo é identificado com alguma combinação de seu nome de host e seu nome
local, o que garante um nome exclusivo em todo o sistema.
Esse esquema de nomeação não é transparente quanto à localização nem independente de localização.
Entretanto, as mesmas operações de arquivo podem ser utilizadas tanto para arquivos locais quanto para
arquivos remotos.
Abordagem popularizada pelo Network File System (NFS)
- -5
O (sistema de arquivos de rede da Sun Microsystems. Trata-se de um componente do sistema de arquivos NFS
do ONC+: um pacote de rede suportado por muitos fornecedores da UNIX) fornece um meio de anexar diretórios
remotos a diretórios locais, dando, assim, a aparência de uma árvore de diretórios coerente.
Abordagem de única estrutura global de nomes
Nesta abordagem, uma única estrutura global de nomes abrange todos os arquivos do sistema.
A estrutura de sistema de arquivos composta é igual à estrutura de um sistema de arquivos convencional.
Entretanto, na prática, os diversos (por exemplo: arquivos de dispositivos do UNIX earquivos especiais
diretórios binários específicos de máquinas) tornam esse objetivo difícil de ser atingido.
2 Modelos de acesso
A forma como uma requisição será tratada dependerá do modelo de acesso do sistema de arquivos que será
dado aos arquivos.
Em um DFS, dois modelos de acesso podem ser utilizados:
2.1 Modelo de serviço remoto
Quando um usuário solicitar acesso a um arquivo remoto, o servidor que armazena o arquivo será localizado
pelo esquema de nomeação e, então, realizará a transferência dos dados.
Uma das maneiras mais comuns para implementar o serviço remoto é o paradigma da Chamada de
Procedimento Remoto (RPC).
Para garantir o desempenho razoável de um mecanismo de serviço remoto, podemos utilizar uma forma de
armazenamento em cache.
Em sistemas de arquivos convencionais, o motivo para o armazenamento em caches é reduzir o |/O de disco
(aumentando, portanto, o desempenho). Já nos DFS, o objetivo é
reduzir tanto o tráfego de rede quanto o I/O de disco.
2.2 Modelo de caching: esquema básico de armazenamento em cache
Se os dados necessários para atender à solicitação de acesso ainda não estiverem armazenados em cache, uma
cópia desses dados do servidor será trazida para o sistema cliente. Dessa forma, seus acessos serão executados
na cópia do cache. A ideia é reter no cache blocos de disco recentemente acessados, de modo que acessos
repetidos às mesmas informações possam ser manipulados localmente, sem tráfego de rede adicional.
- -6
Os arquivos ainda são identificados com uma cópia-mestra residindo na máquina do servidor e mais cópias (ou
partes) do arquivo disseminadas em diferentes caches.
Quando uma cópia do cache for modificada, as mudanças precisarão se refletir na cópia- mestra para preservar a
semântica de consistência relevante.
A granularidade dos dados do cache de um DFS pode variar de blocos de um arquivo a um arquivo inteiro.
3 Comparação entre armazenamento em cache e serviço 
remoto
Quando o armazenamento em cache é utilizado, o cache local pode manipular eficientemente um número
substancial dos acessos remotos.
O aproveitamento da localidade nos padrões do acesso a arquivos torna o armazenamento em cache ainda mais
atraente.
A maioria dos acessos remotos será atendida tão rapidamente quanto os acessos locais. Além disso, os
servidores são contatados apenas ocasionalmente. Consequentemente, a carga no servidor e o tráfego na rede
são reduzidos, e a possibilidade para a escalabilidade aumenta.
Por outro lado, quando o método de serviço remoto é utilizado, cada acesso remoto é manipulado através da
rede. O prejuízo é associado ao aumento de tráfego na rede, à carga no servidor e à redução no desempenho.
Quando transmitimos grandes porções de dados (conforme é feito no armazenamento em cache), o overhead
total da rede é mais baixo do que quando transmitimos séries de respostas a solicitações específicas (como no
método de serviço remoto).
Além disso, as rotinas de acesso a disco no servidor podem ser mais otimizadas quando sabemos que as
solicitações envolverão sempre grandes segmentos de dados contíguos – em vez de blocos aleatórios de disco.
O problema da consistência do cache é a principal desvantagem do armazenamento em cache. Quando os
padrões de acesso exibem gravações não frequentes, o armazenamento em cache é superior.
Entretanto, quando as gravações são frequentes, os mecanismos empregados para resolver o problema da
consistência incorrem em overhead significativo em termos de desempenho, tráfego na rede e carga no servidor.
Para que o armazenamento em cache traga benefícios, a execução deve ser levada a efeito em máquinas que
tenham discos locais ou memórias principais de grande capacidade. O acesso remoto em máquinas com memória
de pouca capacidade e sem discos deve ser realizado por meio do método de serviço remoto.
- -7
No armazenamento em cache, como os dados são transferidos em massa entre o servidor e o cliente – em vez de
em resposta às necessidades específicas de uma operação de arquivo -, a interface de mais baixo nível entre
máquinas é diferente da interface de mais alto nível do usuário.
Por outro lado, o modelo do serviço remoto é apenas uma extensão da interface local do sistema de arquivos
através da rede. Sendo assim, a interface entre máquinas espelha a interface do usuário.
4 Stateful (serviço com estado) versus stateless (serviço 
sem estado)
Existem duas abordagens para o armazenamento de informações no lado do servidor, quando um cliente acessa
arquivos remotos, quais sejam:
· O servidor busca cada arquivo que estiver sendo acessado pelo cliente; ou
· O servidor simplesmente fornece blocos conforme são solicitados pelo cliente, sem saber como esses blocos
estão sendo utilizados.
No primeiro caso, o serviço fornecido tem estado (stateful); no outro, o serviço não tem estado (stateless).
4.1 Stateful (serviço com estado)
No (conexão entre o cliente e o servidor durante uma sessão, tanto ao fechar oserviço de arquivos com estado
arquivo quanto por intermédio de um mecanismo de coleta de lixo (garbage-collection), um cliente deve
executar uma operação sobre um arquivo antes de acessá-lo.O servidor, então, extrai informações sobreopen ()
o arquivo em seu disco, armazena essas informações em memória e fornece ao cliente um (esseidentificador
identificador é utilizado para acessos subsequentes até que a sessão termine) de conexão único para o cliente e o
arquivo aberto.
Em termos do UNIX, o servidor extrai o I-node e fornece ao cliente um descritor de arquivo, que serve como um
índice para a tabela de inodes em memória.
No , o servidor deve reclamar o espaço de memória principal utilizado pelos clientes que não estão maisstateful
ativos.
O ponto chave relacionado à tolerância a falhas em uma abordagem de serviço com estado é que o servidor
mantém informações sobre seus clientes na memória principal.
- -8
4.2 Stateless (serviço sem estado)
O serviço de arquivos sem estado evita informações de estado, tornando cada solicitação autossuficiente. Em
outras palavras, cada solicitação identifica completamente o arquivo e sua posição no arquivo (para acessos de
leitura e gravação).
No stateless, o servidor não precisa manter uma tabela de arquivos abertos na memória principal. Além disso,
não há necessidade de estabelecer e terminar uma conexão por operações .open () e close ()
Um processo-cliente abre um arquivo, e essa abertura não resulta no envio de uma mensagem remota.
Leituras e gravações são realizadas como mensagens remotas (ou consultas ao cache). O fechamento final pelo
cliente, por sua vez, resulta novamente em apenas uma operação local.
4.3 Vantagens e distinção entre satateful e stateless
VANTAGENS
A vantagem de um serviço com estado sobre um serviço sem estado é o aumento do desempenho. Informações
de arquivo são armazenadas em cache na memória principal e podem ser facilmente acessadas via identificador
de conexão, evitando, assim, acessos ao disco.
Além disso, um servidor com estado sabe se um arquivo está aberto para acesso sequencial e pode, portanto, ler
os próximos blocos à frente. Servidores sem estado não podem fazer isso, pois não conhecem o objetivo das
solicitações do cliente.
DISTINÇÃO
A distinção entre stateful e stateless torna-se mais evidente quando consideramos os efeitos de uma queda
durante uma atividade de serviço. Nessa situação, um servidor com estado perde todos os seus estados voláteis.
A garantia de recuperação sem prejuízo desse servidor implica a restauração de seu estado, normalmente
realizada por um protocolo de recuperação baseado em um diálogo com os clientes.
Stateful x Stateless
Do ponto de vista do cliente, não há diferença entre um servidor lento e um servidor em recuperação. Se não
receber resposta, o cliente continuará a retransmitir sua solicitação.
Em alguns ambientes, o stateful é uma necessidade. Se o servidor empregar o método iniciado para validação do
cache, não poderá oferecer serviço sem estado, pois deverá manter um registro dos arquivos que foram
armazenados em cache e dos clientes que os armazenaram.
Um problema diferente é causado por falhas dos clientes. O servidor precisa tornar-se consciente dessas falhas,
de modo que possa reclamar o espaço alocado para registrar o estado dos processos-clientes que falharam.
- -9
O stateless evita esses problemas, pois um servidor recentemente recuperado pode responder a uma solicitação
autossuficiente sem qualquer dificuldade. Portanto, os efeitos de falhas e de recuperações do servidor são quase
imperceptíveis.
4.4 Replicação de arquivos
Em um DFS, a replicação de arquivos em diferentes máquinas é uma redundância útil para melhorar a
disponibilidade.
A replicação multimáquinas pode também beneficiar o desempenho: a seleção de uma réplica vizinha para o
atendimento de uma solicitação de acesso resulta em tempo de serviço mais curto.
Replicação explícita
Quando a responsabilidade fica a cargo do programador. Nesse caso, o serviço de diretórios pode permitir
diversos índices de arquivos para cada arquivo.
Esse tipo de replicação é de difícil implementação e não permite a aplicação da transparência.
Replicação atrasada (lasy)
Quando apenas uma cópia é realizada em um servidor. Nesse caso, o servidor possui a responsabilidade de
propagar as atualizações e de garantir que outro servidor responda no caso de sua impossibilidade.
Replicação em grupos
Quando a operação de escrita é realizada em todos os arquivos ao mesmo tempo (multicast atômico).
5 SEMÂNTICA DE COMPARTILHAMENTO
Quando dois ou mais usuários compartilham o mesmo arquivo ao mesmo tempo, é necessário definir, com
exatidão, a semântica de leitura e de escrita para evitar problemas.
Vamos conhecer essas semânticas?
Semântica UNIX
Na semântica Unix, as alterações são visíveis instantaneamente.
Em (sistemas que permitem que processos compartilhem arquivos (comosistemas de um único processador
o Unix, por exemplo), normalmente, a semântica declara que, quando uma operação read vem depois de uma
operação write, aquela retorna o valor que acabou de ser escrito. Veja, a seguir, uma figura que representa uma
semântica Unix:
- -10
De maneira semelhante, quando duas operações write ocorrem em rápida sucessão, seguidas por uma , oread
valor lido é o valor armazenado pela última . Na verdade, o sistema impõe uma ordenação de tempowrite
absoluto a todas as operações e sempre retorna o valor mais recente.
Em um sistema distribuído, a semântica Unix pode ser alcançada com facilidade, contanto que haja somente um
servidor de arquivos e que os clientes não os armazenem.
Todas as operações e vão diretamente para o servidor de arquivos, que as processa estritamente emread write
sequência. Essa abordagem gera a semântica Unix, exceto pelo pequeno problema de que atrasos de rede podem
fazer com que uma read que ocorreu em um microssegundo após uma chegue antes ao servidor e, por isso,write
obtenha o valor antigo.
O desempenho de um sistema distribuído, no qual todas as requisições de arquivos devem ir para um único
servidor, costuma ser fraco. Muitas vezes, esse problema é resolvido com a permissão de que clientes
mantenham cópias locais de arquivos muito utilizados em suas caches (locais) privadas.
Se um cliente modifica localmente um arquivo em cache e, logo depois, outro cliente lê o arquivo no servidor,
este obtém um arquivo obsoleto.
SEMÂNTICA DE SESSÃO
Uma solução alternativa à semântica Unix é relaxar a semântica de compartilhamento de arquivos.
Em vez de requerer que uma read veja os efeitos de todas as operações write anteriores, podemos estabelecer
uma nova regra, em que:
· As alterações em um arquivo aberto sejam inicialmente visíveis apenas para o processo ou, possivelmente,
máquina que modificou o arquivo;
· As alterações devam ficar visíveis para outros processos ou máquinas somente quando o arquivo for fechado.
Grande parte dos sistemas de arquivos distribuídos implementa a semântica de sessão. Contudo, ainda resta a
questão do que ocorre quando dois ou mais clientes armazenam e modificam o mesmo arquivo
simultaneamente.
- -11
Uma solução é dizer que, à medida que cada arquivo for fechado por vez, seu valor será enviado de volta ao
servidor, de modo que o resultado final dependerá da requisição de fechamento mais recentemente processada
pelo servidor.
Uma alternativa menos agradável - porém, mais fácil de implementar é dizer que o resultado final será um dos
candidatos, mas não especificar o escolhido.
6 Arquivos imutáveis
Em um sistema distribuído, uma abordagem completamente diferente da semântica de compartilhamento de
arquivos é tornar imutáveis todos eles.
Dessa forma, não existe nenhum modo de abrir um arquivo para escrita. Na verdade, as únicas operações em
arquivos são e .create read
O que se permite é criar um arquivo inteiramente novo e passá-lo para o sistema de diretório sob o nome de um
arquivo previamente existente, que, agora, se tornará inacessível (ao menos sob esse nome).
Uma vez decidido que os arquivos não podem ser alterados de jeito algum, o problema de como lidar com dois
processos – como escreverem um arquivo e ler esse arquivo – simplesmente desaparece, o que simplifica,
consideravelmente, o projeto.
Resta, então, o problema que ocorre quando dois processos tentam substituir o mesmo arquivo
simultaneamente. Como acontece com a semântica de sessão, a melhor solução para esse caso seria permitir que
um dos novos arquivos substituísse o antigo – seja este o último, seja a substituição não determinística.
Por isso, embora seja impossível modificar o arquivo específico, continua possível substituir, atomicamente, esse
arquivo por um novo. Em outras palavras, embora arquivos não possam ser atualizados, os diretórios podem.
Um problema um pouco mais desagradável diz respeito a como prosseguir se um arquivo for substituído
enquanto outro processo estiver ocupado, lendo esse mesmo arquivo.
Uma solução é dar um jeito de o processo leitor continuar usando o arquivo antigo, mesmo que este não esteja
mais em nenhum diretório, comparado ao modo como o Unix permite a um processo que tenha um arquivo
aberto continuar a usá-lo, mesmo depois de esse arquivo ter sido apagado de todos os diretórios.
Outra solução é detectar se o arquivo foi alterado e fazer com que as tentativas subsequentes de ler esse arquivo
falhem.
- -12
7 Network File System (NFS)
O padrão NFS mais recente é a Versão 4 que difere fundamentalmente das versões anteriores. Essa versão
apresenta uma mudança significativa, em que o protocolo tem estado, o que significa que o servidor mantém o
estado da sessão do cliente do momento em que o arquivo remoto é aberto até que ele seja fechado.
Sendo assim, o protocolo NFS fornece operações e . As versões anteriores do NFS – que não têmopen() close()
estado – não fornecem tais operações.
Além disso, as versões anteriores especificam protocolos separados para a montagem de sistemas de arquivos
remotos e para o trancamento ( ) desses arquivos. Em particular, o protocolo de montagem foi eliminado,lookup
permitindo que o NFS funcionasse com de rede.firewalls
A Versão 4 do NFS aprimorou a capacidade de os clientes armazenarem em cache local os dados dos arquivos,
melhorando o desempenho do DFS, já que os clientes são capazes de resolver mais acessos a arquivos a partir do 
 local do que passando pelo servidor.cache
Outro benefício dessa versão permite que os clientes solicitem locks de arquivos aos servidores. Se o servidor
atender à solicitação, o cliente manterá o lock até que ele seja liberado ou que sua (os clientesconcessão
também são autorizados a renovar concessões existentes) expire.
Tradicionalmente, os sistemas baseados no Unix oferecem trancamento aconselhável de arquivos, enquanto os
sistemas operacionais Windows utilizam o trancamento obrigatório.
Para permitir que o NFS funcione bem com sistemas não Unix, ele também fornece trancamento obrigatório.
Os novos mecanismos de trancamento e armazenamento em cache são baseados no conceito de delegação
(quando o servidor delega responsabilidades pelo e pelo conteúdo de um arquivo ao cliente que solicitou o lock
). O cliente delegado mantém em cache a versão corrente do arquivo, e outros clientes podem solicitar a ele olock
acesso ao lock e o conteúdo do arquivo, até que o cliente delegado desista do lock e da delegação.
Finalmente, enquanto as versões anteriores do NFS são baseadas no protocolo de rede UDP, a Versão 4 é
baseada no TCP, que permite melhor adaptação a cargas variadas de tráfego na rede. A delegação dessas
responsabilidades aos clientes reduz a carga no servidor e melhora a coerência do cache.
É desejável ocultar os detalhes de replicação dos usuários. O mapeamento de um nome de arquivo copiado em
uma réplica específica é tarefa do esquema de nomeação.
A existência de réplicas deve ser invisível aos níveis mais altos. Nos níveis mais baixos, entretanto, as réplicas
devem ser diferenciadas umas das outras por distintos nomes de mais baixo nível.
- -13
Outro requisito de transparência é fornecer (esse controle inclui a determinação docontrole de replicação
grau de replicação e da localização das réplicas) nos níveis mais altos.
Veja, a seguir, uma figura que representa um sistema NFS
O que vem na próxima aula
Na próxima aula, você vai estudar:
· Componentes utilizados para desenvolvimento dos serviços Web.
CONCLUSÃO
Nesta aula, você:
• Conheceu os mecanismos de nomeação que fornecem transparência e independência às localizações;
• Conheceu diversos métodos de acesso a arquivos distribuídos;
• Identificou que a replicação de arquivos em diferentes máquinas em um DFS é uma redundância útil 
para melhorar a disponibilidade;
• Aprendeu a comparar servidores com estado e sem estado;
• Identificou a importância das semânticas de compartilhamento de arquivos.
•
•
•
•
•
- -1
ARQUITETURA DE SISTEMAS 
DISTRIBUÍDOS
SERVIÇOS WEB
- -2
Olá!
Objetivo desta Aula
Ao final desta aula, o aluno será capaz de:
1- Definir o conceito de serviços web;
2- Identificar os componentes utilizados para o desenvolvimento desses serviços;
Introdução
Nas últimas décadas, a computação evoluiu a uma velocidade sem precedentes. Esse progresso causou
significativos impactos nas organizações, forçando gerentes e desenvolvedores de TI a aceitarem novos para-
digmas de computação.
As inovações na programação e no hardware levaram a tecnologias mais poderosas e úteis, entre elas: a
Programação Orientada a Objeto, a computação distribuída, os protocolos da internet e o XML.
Ao mesmo tempo, as organizações aprenderam a alavancar a capacidade de suas redes e da internet para obter
vantagens competitivas. Entre essas tecnologias, podemos citar os serviços web, que representam a integração
de diversas aplicações através da internet.
1 Noções introdutórias
Os serviços web ( (de acordo com o World Wide Web Consortium W3C): “um web servisse define-web services 
se como um sistema de foftware projetado para suportar a interoperabilidade entre máquinas sobre a rede”)
abrangem um conjunto de padrões relacionados que podem habilitar quaisquer duas aplicações de computador
a se comunicarem e a trocarem dados, via internet, por meio de protocolos padrões.
Para um sistema distribuído funcionar corretamente, componentes de aplicações que executam em
computadores diferentes por toda a rede devem poder comunicar-se.
Tecnologias como DCOM e CORBA habilitam a comunicação entre componentes distribuídos. Entretanto,
impõem um custo para viabilizar essa comunicação. Muitas vezes, seus componentes se comunicam via uma
ponte entre COM e CORBA.
Se os protocolos que atuam abaixo do DCOM e do CORBA mudarem, os programadores terão de modificar essa
ponte para refletir tais mudanças.
Esses problemas têm impedido que a capacidade da computação distribuída aumentasse a integração e a
automação de processos de negócios.
- -3
2 FUNCIONAMENTO
Os serviços web funcionam a partir do uso de padrões abertos (não proprietários).
Em outras palavras, teoricamente, esses serviços podem habilitar a comunicação entre quaisquer dois
componentes de software – independentemente das tecnologias utilizadas para criar os componentes ou as
plataformas nas quais residem (interoperabilidade).
Os web services fornecem, de forma mais genérica, uma interface de serviços para a interação com os servidores.
Sendo assim, as aplicações podem utilizar sua própria linguagem, que será traduzida para uma linguagem
comum: o (o padrão usado nos serviços web é a Extensible Markup Language (XML) – umaformato XML
linguagem utilizada para a marcação de dados, de modo que a informação possa ser trocada entre aplicações e
plataformas).
A experiência com problemas de interoperabilidade levaram ao desenvolvimento de padrões abertos para
tecnologias de serviços web, em um esforço para habilitar a comunicação interplataformas.
Padrões abertos capacitam empresas (que executam plataformas diferentes) a se comunicarem e a transferirem
dados sem ter de projetarem softwares específicos para determinada plataforma a um custo alto.3 Utilização
Os serviços web melhoram o desenvolvimento de software colaborativo, permitindo que desenvolvedores criem
aplicações combinando códigos escritos em qualquer linguagem de qualquer plataforma.
Esses serviços também promovem (a modularização é menos propensa a erros eprogramação modular
promove a reutilização de ). Cada função específica de uma aplicação pode ser apresentada como umsoftware
serviço web separado.
Indivíduos ou empresas podem criar suas próprias aplicações exclusivas, mesclando e compatibilizando os web
services que fornecem a funcionalidade de que precisam.
Para ilustrar a utilização de web services em uma situação real, imaginemos um site de vendas pela internet que
necessita validar o crédito do comprador antes de proceder com a venda.
O sistema acessa um serviço ( ) que cuida de todos os passos necessários à verificação de crédito, taisweb service
como:
· Checar o histórico das compras efetuadas pelo consumidor na empresa;
· Checar a situação de crédito do consumidor no sistema público etc.
O obtém esses dados e retorna a situação de crédito desse consumidor para o site.web service
- -4
4 Arquitetura
Os serviços web são descritos, em um ambiente distribuido, como uma arquitetura denominada Service Oriented
Architecture (SOA).
Normalmente, essa arquitetura é caracterizada pelas seguintes propriedades:
Visão lógica
O serviço é uma visão abstrata e lógica de programas reais, bases de dados, processos de negócio etc., definidos
em termos do que faz.
Orientação à mensagem
O serviço é formalmente definido em função das mensagens trocadas entre os agentes prestadores e solicitantes,
e não entre as propriedades dos próprios agentes.
A estrutura interna de um agente – que inclui características como sua linguagem de implementação, sua
estrutura, seu processo e até mesmo a estrutura de banco de dados – é deliberadamente abstraída na SOA
Orientação à descrição
Um serviço é descrito por dados processáveis via meta-máquina. A descrição apoia a natureza pública da SOA.
Granularidade
Os serviços tendem a utilizar um pequeno número de operações com mensagens relativamente grandes e
complexas.
Orientação à rede
Os serviços tendem a ser orientados para uso em rede, embora este não seja um requisito absoluto.
Plataforma neutra
As mensagens são enviadas em uma plataforma neutra, de formato padronizado e fornecido através das
interfaces.
4.1 Componentes da arquitetura SOA
Os componentes da arquitetura SOA representam uma coleção de serviços que se comunicam através da troca de
mensagens XML.
Esses componentes possuem os seguintes papéis que (a interação entre os três papeis envolve: aatuam entre si 
publicação da informação sobre determinado serviço; a descoberta dos serviços disponíveis; a ligação entre
esses serviços.):
Provedor de serviço web
- -5
Responsável pela descrição das informações de conexão na chamada ao serviço e pela publicação e descrição do 
 no registro dos serviços.web service
Registro dos serviços
Manutenção de diretório com as informações sobre os serviços. Na SOA, o padrão adotado para registro é o
Universal Description, Discovery and Integration (UDDI).
Consumidor do serviço
Responsável pela descoberta de um serviço, pelo recebimento de sua descrição e por sua utilização para a
conexão a um provedor. Seu objetivo é chamar um serviço web.
Classificação dos serviços web
Curbera, Mukhi e Weerawarana (2001) classificam os serviços web segundo a funcionalidade de suas
especificações.
Essa classificação é dividida em quatro conjuntos de especificações que têm em comum o uso da linguagem XML.
São eles:
Descrição de serviços
Utilizada para definir as operações, as mensagens e os tipos de dados de um serviço. Essa descrição também
mantém as informações sobre como acessar os serviços.
Publicação e descoberta de serviços
Contém os protocolos que possibilitam a localização da descrição dos serviços.
- -6
Descrição de composição de serviços
Contém os modelos e linguagens utilizadas para descrever como se dará a interação dos serviços.
Protocolos de comunicação
Utilizados para definir, estabelecer e manter a comunicação entre as aplicações. Esses protocolos também
contém a descrição dos formatos das mensagens utilizadas no estabelecimento da comunicação entre aplicações.
Comunicação entre web services
À comunicação entre serviços web é separada em quatro camadas que tratam da requisição e da resposta entre o
cliente e o servidor, conforme apresenta a figura a seguir:
5 Universal Description, Discovery and integration (UDDI)
O UDDI é o diretório de busca de web services. Sua função é definir as regras baseadas em XML
para construir diretórios nos quais as empresas disponibilizam seus serviços web.
A especificação UDDI aponta as formas para a publicação, a descoberta e a integração de serviços.
Sendo assim, o registro de serviços UDDI possui dois tipos de clientes, quais sejam:
· Aplicações que desejam publicar serviços e suas interfaces;
· Aqueles que desejam obter serviços web e se conectar a eles.
O protocolo UDDI apresenta três papéis, representados sob a forma de XML Schemas. São eles:
· Páginas brancas - Contêm identificadores sobre o contato técnico do serviço oferecido;
· Páginas amarelas - Contêm informações genéricas sobre os tipos e a localização dos serviços disponíveis;
· Páginas verdes Contêm informações técnicas sobre determinado serviço web.
As principais funções do UDDI são:
· Publicação Permite a divulgação dos serviços;
· Descoberta Habilita a busca sobre um serviço específico;
· Ligação (bind) Trata do estabelecimento da conexão e da interação com o serviço.
Alguns sites de e-commerce permitem que desenvolvedores independentes aproveitem a capacidade das
tecnolo-gias de seus endereços eletrônicos, expondo certas funções como serviços web.
Por exemplo, a Amazon.com possibilita que desenvolvedores montem lojas online que pesquisem seus bancos de
dados de produtos e exibam informações detalhadas sobre eles via web services Amazon.com.
A ferramenta de busca Google também pode ser integrada a outra funcionalidade através das APIs web, que se
conectam aos indices de sites do Google que usam serviços web.
- -7
Em troca de maior exposição, a Amazon.com e o Google fornecem acesso às características de seus sites por meio
do SOAP e de outros protocolos padronizados.
6 Web Services Description Language (WSDL)
O WSDL é a interface para o uso de um web service, que fornece um método padronizado para descrever
serviços web e suas capacidades especificas.
Em sua especificação, trata-se de uma linguagem baseada em XML que descreve, de forma padronizada e
independente de plataforma, como e onde os serviços podem ser conectados e utilizados através da rede.
Os documentos WSDL representam um acordo entre o provedor de serviços e seus clientes e definem os serviços
como uma coleção de portas na rede. Esses documentos também apresentam uma relação entre a definição da
mensagem e sua implementação, o que permite o reúso das definições das mensagens e port types.
O WSDL descreve os serviços disponibilizados à rede através de uma semântica XML, que providencia a
documentação necessária para a chamada do sistema distribuído e o procedimento essencial para que essa
comunicação se estabeleça.
Enquanto o SOAP especifica a comunicação entre um cliente e um servidor, o WSDL descreve os serviços
oferecidos.
Um documento WSDL é composto por elementos XML, tais como:
Tipo - Fornece a definição dos tipos de dados para descrever as mensagens trocadas entre aplicações
normalmente representadas por um documento XML Schema Definition (XSD);
Mensagem - Representa a informação que será trocada através das definições dos tipos de dados;
Tipo de porta - Conjunto de operações que podem ser suportadas por um ou mais end points, em que cada
operação refere-se a uma mensagem de entrada, saida ou erro;
Operação - Descreve a ação suportada pelo serviço.
7 Simple Object Access Protocol(SOAP)
SOAP é um protocolo para troca de informações, composto por um conjunto de regras de como utilizar o XML e
pela definição do formato de mensagem para representar as Remote Procedure Calis (RPCs) ou trocas de
mensagens.
Essa troca ocorre em um ambiente independente de plataforma e linguagem de programação, associado ao
HTTP ou outro protocolo como, por exemplo, o SMTP.
- -8
O SOAP permite que os documentos XML de envio e de recepção sobre a web suportem um protocolo comum de
transferência de dados para uma comunicação de rede eficaz.
Em outras palavras, o SOAP providencia o transporte de dados para os web services e fornece algumas
convenções - como cabeçalhos, estrutura e corpo em uma mensagem XML.
As principais partes da especificação SOAP 1.2 são:
Envelope SOAP (empacotamento) - Define o conteúdo da mensagem SOAP;
Regras de codificação (serialização) - Especificam os tipos de dados utilizados na aplicação;
Convenção (comunicação) - Especifica as chamadas/respostas através de procedimentos remotos.
8 Extensible Markup Language (XML)
O XML é uma linguagem de marcação de dados extensível que permite que o usuário defina suas próprias
linguagens de marcação para atender a inúmeras classes de documentos diferentes.
Essa linguagem é a base dos serviços web, que fornece a descrição, o armazenamento e o formato na troca de
dados.
A sintaxe do XML especifica a representação dos dados, define sua transmissão e detalha como os serviços serão
publicados e descobertos.
A construção de web services é baseada nos padrões XML e SOAP. O transporte dos dados, por sua vez, é
realizado através do protocolo HTTP ou HTTPS.
Por fim, a transferência dos dados ocorre no formato XML, e esses dados são encapsulados pelo protocolo SOAP.
9 A plataforma .NET da Microsoft
A iniciativa .NET inclui o ambiente de desenvolvimento integrado Visual Studio .NET, que habilita
programadores a desenvolverem serviços web em uma variedade de linguagens – incluindo C++, C# e Visual
Basic .NET.
Os serviços web .NET (a Microsoft introduziu a expressão serviços web durante o lançamento do .NET.
Atualmente, essa é uma das empresas dominantes no mercado de web services)– fundamentais da iniciativa .
NET – estendem o conceito de reutilização de software à internet, permitindo que desenvolvedores reutilizem
componentes de software que residam em outras máquinas ou plataformas.
Empregando serviços web como blocos de construção reutilizáveis, os programadores podem-se concentrar em
suas especialidades, sem ter de implementar cada componente de uma aplicação.
- -9
Por exemplo, uma empresa que está desenvolvendo uma aplicação de e-commerce pode assinar serviços web
que processam pagamentos e autenticam usuários, o que habilita o programador a se concentrar em outros
aspectos mais exclusivos daquela aplicação.
Em .NET, um serviço web é uma aplicação armazenada em uma máquina que pode ser acessada por uma outra
através de uma rede.
Em sua forma mais simples, um serviço web criado em .NET é uma classe – ou um agrupamento lógico – de 
 (os métodos são definidos dentro de uma classe para realizar tarefas e desenvolvermétodos de dados
informações quando suas tarefas estão concluídas) que simplificam a organização do programa.
As classes de serviço web da .NET contêm certos métodos – denominados métodos de serviços web – que são
especificados como parte do web service. Esses métodos podem ser invocados remotamente, usando RPC.
10 Sun Microsystems e a plataforma Sun ONE
A estratégia de serviços web da Sun Microsystems é baseada no Sun Open Net Environment (Sun ONE), que
consiste em três
componentes conceituais uma visualização, uma arquitetura e um modelo para desenvolver softwares baseados
em padrões.
Veja, a seguir, as características desses componentes:
Visualização
A visualização Sun ONE incorpora um modelo para desenvolvimento de software, no qual informações e
aplicações comerciais críticas estão disponíveis, a qualquer instante, para qualquer tipo de dispositivo incluindo
telefones celulares e PDAs.
Seu objetivo é ajudar desenvolvedores a criarem redes de aplicações distribuídas ou serviços web altamente
confiáveis e a promoverem a reutilização de componentes e serviços.
Arquitetura
A arquitetura Sun ONE é projetada para ser (a escalabilidade é crucial: à medida que novas tecnologiasescalável 
e novos componentes são adicionados a sistemas, há maior demanda pelos recursos desses sistemas, o que,
potencialmente, degrada o serviço), para assegurar acesso confiável a serviços.
A plataforma Sun ONE é composta por três produtos, quais sejam:
· Solaris Operating Environment;
- -10
· Infrastructure Software (o Infrastructure Software inclui o Sun ONE Directory Server e o Sun ONE Portal
Server, que oferecem autenticação e personalização de usuário. Entre outras capacidades desse produto, estão o
gerenciamento de de escalonamento, a cobrança e a comunicação);
· Sun ONE Studio.
O Sun ONE permite que programadores desenvolvam serviços web usando produtos de terceiros. Integrando
produtos diferentes, eles podem desenvolver infraestruturas de web services que melhor atendam aos
requisitos de suas empresas.
Modelo
O Sun ONE também incorpora suporte para padrões abertos incluindo XML, SOAP, UDDI e WSDL para ajudar a
assegurar altos niveis de interoperabilidade e integração de sistema.
O Sun ONE promove o conceito de que os dados, as aplicações, os relatórios e as transações de uma empresa que
compõem o modelo conceitual DART podem ser publicados como serviços online.
Por meio do modelo DART, as empresas podem organizar aplicações e processos de negócios que envolvem
dados, aplicações, relatórios e transações, para que os programadores possam mapear elementos de negócios
para serviços correspondentes.
O que vem na próxima aula
Na próxima aula, você vai estudar:
· Novas tecnologias em sistemas distribuídos;
· Computação ubíqua, com foco nas operações voltadas para a tarefa (e não para a ferramenta), a partir da
inovação em interfaces;
· Computação nas nuvens, com a utilização de recursos de processamento e armazenamento de computadores
compartilhados e interligados por meio da internet;
· Os moldes da computação em grid, com acesso aos dados e às aplicações a partir de qualquer computador que
tenha acesso à internet, independente de sua plataforma.
CONCLUSÃO
Nesta aula, você:
• Conheceu o conceito de serviços web;
• Identificou os componentes utilizados para o desenvolvimento de um serviço web.
•
•
- -1
ARQUITETURA DE SISTEMAS 
DISTRIBUÍDOS
COMPUTAÇÃO UBÍQUA E COMPUTAÇÃO 
NAS NUVENS
- -2
Olá!
Objetivo desta Aula
Ao final desta aula, o aluno será capaz de:
1- Identificar novas tecnologias em sistemas distribuídos (computação ubíqua e computação em nuvens);
2- Definir o foco da computação ubíqua;
3- Descrever os recursos utilizados no processamento e armazenamento de computadores compartilhados na
computação em nuvens.
Introdução
Um sistema ubíquo é capaz de utilizar como entrada informações relevantes sobre as entidades relacionadas à
aplicação.
Esse sistema pode prover serviços de maneira mais precisa, dinâmica e otimizada, aumentando a satisfação dos
usuários e minimizando o consumo de recursos, tais como: energia, processamento, comunicação, entre outros.
Já a computação em nuvem possui um longo histórico, mas surgiu na área da telefonia. Seu conceito foi criado
por John McCarthy, na década de 1960.
Comercialmente, essa expressão começou a ser utilizada na década de 1990 para descrever um ambiente
baseado em redes massivas de servidores – virtuais ou físicos.
Tanto a computação em nuvem quanto a computação ubíqua são tendências já em grande expansão que têm
como objetivo proporcionar serviços de tecnologia, extrapolando os limites de infraestrutura tanto física quanto
virtual.
1 COMPUTAÇÃO UBÍQUA
Em 1991, Mark Weiser publicou o artigo O computador do século 21 (The computer for the 21st century).
A partir desse momento, surgiua expressão computação (o termo ubíquo significa estar ao mesmoubíqua 
tempo em toda a parte), que tem como foco operações voltadas para a tarefa, e não para a ferramenta. Nesse
caso, a computação está embutida em nosso dia a dia.
Diversos locais já possuem sistemas de segurança que incluem sensores em portas e janelas.
Dessa forma, também é possível que muitos outros sensores possam ser embutidos em monitores inteligentes, o
que permite o uso desses dispositivos para diferentes aplicações.
- -3
À medida que o custo dos sensores e da comunicação é reduzido, mais aplicações de medição e de envio de
informação são disponibilizadas pelas redes.
Com o aumento do acesso à internet, houve o crescimento da computação móvel e da facilidade de uso do
sistema de computação por qualquer pessoa através de um software ou de uma interface associados a novas
tecnologias.
Nesse sentido, podemos identificar a tendência ao uso da computação ubíqua.
Clique aqui para conhecer a definição de computação ubíqua de Loureiro et al (2009).
De acordo com Loureiro et al (2009)
A computação ubíqua é um novo paradigma no qual dispositivos com capacidade de processamento e
comunicação são embutidos nos elementos do dia a dia, provendo serviços de forma transparente aos usuários.
2 CONCEITOS DA COMPUTAÇÃO UBÍQUA
A computação ubíqua está posicionada entre a (são características da computação móvel:computação móvel 
capacidade de mobilidade de um dispositivo computacional e seus serviços; capadidade de estar conectada à
internet ou a alguma rede; redes sem fio; acesso à internet através de dispositivos celulares; aplicações bluetooth
) e a (são características da computação pervasiva: equipamentos portáteis; conexãocomputação pervasiva 
sem fio; ausência de controle administrativo humano; adaptação automática a seu ambiente), conforme
apresenta a figura ao lado:
Nesse tipo de computação, há:
· Integração entre mobilidade e presença distribuída;
· Inovação em interfaces – tendência para as interfaces naturais;
· Determinados problemas, tais como de segurança, complexidade e privacidade.
Clique aqui para saber mais sobre o tema segurança.
A segurança é um tema de pesquisa considerado atual e de grande importância para diversas áreas da
computação, inclusive para a computação ubíqua.
Isso se deve ao fato de que os dispositivos, as aplicações, as redes de comunicação etc. são bastante específicos e,
em geral, diferentes da computação tradicional.
Além disso, os dados compartilhados por sistemas ubíquos são bastante sensíveis, uma vez que refletem o
estado corrente de pessoas, lugares e objetos.
- -4
3 APLICAÇÕES DA COMPUTAÇÃO UBÍQUA
· A computação ubiqua pode ser aplicada nos seguintes sistemas:
· Ambientes inteligentes;
· Interfaces hands-free (sem as mãos) - reconhecimento de voz, tiveboards, pads e tabs;
· Consciência de contexto - além da interação fisica do usuário a partir da utilização de sensores;
· Computação de vestir (wearable) tecnologia que utiliza acessórios como interfaces;
· Computação sensivel à posição;
· Computação desagregada reconfiguração automática;
· Realidade aumentada - combinação de computadores wearabte com informações de sensores de posição;
· Interfaces sensíveis a objeto - Radio-Frequency IDentification (RFID).
EXEMPLOS
Veja um exemplo de aplicação da computação ubíqua:
A DroidGuide utiliza uma arquitetura cliente-servidor (composta de clientes móveis) na plataforma de software
e sistema operacional Android, e um servidor de dados remoto na plataforma de desenvolvimento de aplicações
Web App Engine (GAE) também da Google , executando sobre o ambiente de execução Python.
Clientes móveis comunicam com o servidor através de mensagens de requisição/resposta sobre o protocolo
HTTP.
Os dados, por sua vez, são enviados do cliente para o servidor através de requisições do tipo GET. Ao receber
essas requisições, o servidor as processa e responde para o cliente através do envio de documentos XML sobre
HTTP.
A figura abaixo representa a arquitetura do servidor de eventos para aplicações ubíquas.
- -5
Fonte: LOUREIRO, A. A. F. et al. Computação ubíqua ciente de contexto: desafios e tendências. In: Simpósio 
Brasileiro de Redes de Computadores e Sistemas Distribuídos, 2009.
4 COMPUTAÇÃO EM NUVENS ( )CLOUD COMPUTING
A computação em nuvens consiste na utilização de recursos de processamento e armazenamento de
computadores compartilhados e interligados por meio da internet.
A cloud computing segue os moldes da computação em grid. Nesse caso, o acesso aos dados e às aplicações é
permitido a partir de qualquer computador que tenha conexão com a internet, independente de sua plataforma.
Características da Cloud Computing
Veja a seguir, algumas características da :Cloud Computing
Serviços sob demanda
Os recursos podem ser adquiridos conforme a necessidade.
Virtualização
Os recursos podem ser acessados pela internet.
Alta escalabilidade
As alocações de recursos são dinâmicas, conforme a demanda.
Independência de plataformas
Não há a necessidade de vínculos entre hardwares e softwares.
- -6
Compartilhamento de recursos
Há disponibilidade de uso compartilhado para e arquivos.hardwares, softwares
Tolerância a falhas
Em caso de falhas, há maiores possibilidades de recuperação na computação em nuvens do que em máquinas
locais.
Otimização de custos na aquisição de e .softwares hardwares
Implementação de transparência
Para o usuário, não há a necessidade de conhecer toda a estrutura que está por trás da nuvem.
5 SERVIÇOS DA COMPUTAÇÃO EM NUVENS
Os tipos de serviços em podem ser classificados nos seguintes modelos:cloud computing
Software as a Service (SaaS) – Software como Serviço
Trata-se do uso de um software através da internet. Em outras palavras, o usuário utiliza o software como
serviço sem a necessidade de aquisição ou instalação local.
São exemplos do modelo SaaS:
· Google Docs;
· HP SaaS;
· Microsoft Sharepoint Online;
· IBM SaaS.
Os tipos de serviços em cloud computing podem ser classificados nos seguintes modelos:
Platform as a Service (PaaS) – Plataforma como Serviço
Trata-se da utilização apenas da plataforma como:
· Um banco de dados;
· Um web service;
· Serviços para desenvolvimento, testes etc.
Normalmente, as aplicações desenvolvidas em uma PaaS ficam vinculadas ao fornecedor.
São exemplos do modelo PaaS: Windows Azure e Google App Engine.
Os tipos de serviços em cloud computing podem ser classificados nos seguintes modelos:
Development as a Service (DaaS) – Desenvolvimento como Serviço
Trata-se de ferramentas de desenvolvimento utilizadas como:
· Ferramentas compartilhadas;
- -7
· Ferramentas de desenvolvimento web-based;
· Serviços baseados em mashup.
Os tipos de serviços em cloud computing podem ser classificados nos seguintes modelos:
Infrastructure as a Service (IaaS) – Infraestrutura como Serviço
Trata-se da entrega de infraestrutura como serviço.
Em outras palavras, o foco está na estrutura do hardware ou de máquinas virtuais, no armazenamento, o que
permite uma ampla diversidade de softwares.
São exemplos do modelo IaaS:
· Amazon EC2;
· GoGrid.
Os tipos de serviços em cloud computing podem ser classificados nos seguintes modelos:
Communication as a Service (CaaS) – Comunicação como Serviço
Trata-se da solução terceirizada em comunicação.
Os fornecedores desse tipo de serviço são responsáveis pelo gerenciamento de hardwares e softwares,
entregando serviços como VoIP e serviços de mensagens instantâneas, além da capacidade de gerenciar
videoconferências.
Um exemplo do modelo CaaS é o Microsoft Lync.v
6 MODELOS DE IMPLANTAÇÃO DA CLOUD COMPUTING
Existem quatro tipos de implementação em cloud computing, quais sejam:
Nuvem comunitária (Community cloud)
A nuvem comunitária compartilha infraestrutura com um grupo de organizações específicas que tenham
interesses e missão em comum.
A community cloud pode ser administrada internamente ou por terceiros.
Esse tipo de implementaçãoda cloud computing é similar à nuvem privada, mas suas informações são
disponibilizadas para a comunidade.
Nuvem privada (Private cloud)
A nuvem privada apresenta infraestrutura e serviço dedicados.
Dentre os diversos tipos de nuvem, a private cloud apresenta o menor risco em relação à segurança.
Entretanto, quando comparada a uma nuvem pública, não é possível garantir a escalabilidade e a agilidade na
nuvem privada.
- -8
Nuvem pública (Public cloud)
Na public ctoud, a infraestrutura é de uso público.
Essa computação em nuvem possui larga escalabilidade e maior risco de segurança, pois a organização não
detém ciência ou controle sobre o armazenamento de suas informações.
Nuvem hibrida (Hybrid cloud)
A nuvem hibrida apresenta infraestrutura composta pelos modelos de nuvem privada e pública.
A hybrid cloud permite que haja a expansão dos recursos da nuvem privada a partir da reserva de uma nuvem
pública.
Gerenciamento da segurança da informação na nuvem
De acordo com o artigo da Computeworld (2008), há sete princípios de segurança em uma rede em nuvem. São
eles:
Acesso privilegiado de usuários
A sensibilidade de informações confidenciais nas empresas as obriga a controlar o acesso dos usuários e a
informação bem específica de quem terá privilégio de administrador.
O objetivo é que esse administrador possa controlar os referidos acessos.
Compliance com regulamentação
As empresas são responsáveis pela segurança, pela integridade e pela confidencialidade de seus próprios dados.
Sendo assim, os fornecedores de cloud computing devem estar preparados para auditorias externas e
certificações de segurança.
Localização dos dados
A empresa que usa cloud provavelmente não sabe onde os dados estão, de fato, armazenados – talvez nem o país
no qual as informações estejam guardadas.
Portanto, o fornecedor deve estar disposto a se comprometer a armazenar e a processar dados em jurisdições
específicas, assumindo um compromisso – em contrato – de obedecer aos requerimentos de privacidade que o
país de origem da empresa exige.
Segregação dos dados
Geralmente, uma empresa divide um ambiente com dados de diversos clientes.
Nesse caso, precisamos entender o que é feito para a separação de dados e que tipo de criptografia é seguro o
suficiente para o funcionamento correto da aplicação.
Recuperação dos dados
O fornecedor em cloud deve saber onde estão os dados da empresa e o que é preciso para recuperá-los em caso
de catástrofe.
- -9
Qualquer aplicação que não faça réplica dos dados e da infraestrutura em diversas localidades estará vulnerável
à falha completa.
Por isso, é importante ter um plano de recuperação completo e um tempo estimado para esse plano.
Apoio à investigação
A auditabilidade de atividades ilegais pode-se tornar impossível em , uma vez que há umacloud computing
variação de servidores em função do tempo em que estão localizados os acessos e os dados dos usuários.
Diante disso, é importante obter um compromisso contratual com a empresa fornecedora do serviço e uma
evidência de sucesso no passado para esse tipo de investigação.
Viabilidade em longo prazo
No mundo ideal, o fornecedor de jamais vai falir ou ser adquirido por uma empresa maior.cloud computing
Por isso, a empresa precisa garantir que seus dados estarão disponíveis caso o fornecedor de cloud computing
deixe de existir, ou seja, caso seja migrado para uma empresa maior.
Nesse sentido, é importante haver um plano de recuperação de dados e um formato específico para que esse
plano possa ser utilizado em uma aplicação substituta.
CONCLUSÃO
Nesta aula, você:
• Conheceu os conceitos de computação ubíqua e computação em nuvem;
• Conheceu os tipos de serviços disponibilizados em nuvem;
• Conheceu as aplicações pervasivas e móveis aplicadas na computação ubíqua;
• Conheceu os modelos de implementação em nuvem;
• Conheceu as aplicações em computação em nuvem.
Referências
Conheça sete dos riscos de segurança em cloud computing. Network World, Estados Unidos, 11 jul. 2008.
Disponível em: http://computerworld.uol.com.br/negocios/2008/07/11/conheca-os-sete-riscos-de-seguranca-
em-cloud-computing/
LOUREIRO, A. A. F. et al. Computação ubíqua ciente de contexto: desafios e tendências. In: Simpósio Brasileiro de
Redes de Computadores e Sistemas Distribuídos, 2009, p. 99-149
•
•
•
•
•
http://computerworld.uol.com.br/negocios/2008/07/11/conheca-os-sete-riscos-de-seguranca-em-cloud-computing/
http://computerworld.uol.com.br/negocios/2008/07/11/conheca-os-sete-riscos-de-seguranca-em-cloud-computing/
http://computerworld.uol.com.br/negocios/2008/07/11/conheca-os-sete-riscos-de-seguranca-em-cloud-computing/