Buscar

Resumo - Arquitetura de sistemas distribuídos

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes
Você viu 3, do total de 34 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes
Você viu 6, do total de 34 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes
Você viu 9, do total de 34 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Prévia do material em texto

ARQUITETURA DE SISTEMAS DISTRIBUÍDOS
AULA 1
A evolução da computação e introdução aos 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 computacional. Uma maneira de aumentar a velocidade é
fazer uso de computadores altamente paralelos. Essas máquinas são construídas com muitas CPUs
objetivando processar coletivamente, com muito mais poder computacional do que apenas uma
única CPU. Colocar uma quantidade representativa de computadores em uma sala é fácil e 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, já que 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 2 ou mais CPUs compartilham acesso total a uma memória principal comum.
Esses multiprocessadores oferecem um modelo de comunicação simples e a sincronização é
possível através de técnicas bem definidas, mas tem a desvantagem de que os de grande porte são
difíceis de construir e por isso são caros. 
Sistemas distribuídos – 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 os
workstations – aglomerados de estações de trabalho). 
Por que computação distribuída?
Com a melhoria das tecnologias, o que se conseguia executar 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.
Como resultado, é possível conectar diversos computadores por meio de uma rede de alta
velocidade para executar um sistema de computação colaborativo. Esses sistemas são geralmente
chamados de sistemas distribuídos. 
*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:
Muito grandes – Modelagem da terra/ clima, simulações de reservatórios de petróleo, problemas
com grandes escalas (cosmologia).
Muito pequenos – Projeto de remédios, projetos de chips, biologia estrutural, física de partículas.
Muito complexos – Física de partículas, dinâmica de fluídos, modelagem de comportamento de
pessoas.
Muito caros – Produção e exploração de petróleo, simulação de acidentes.
Muito perigosos – Tolerância a falhas em aviões, teste de dispositivos nucleares, simulação de
estratégias de defesa.
*Com tudo isso, requeriu o aumento de desempenho. Solução: Paralelismo. (Execução simultânea
de operações. Solução com melhor custo benefício). 
Evolução do processamento
Anos 70 – Primeiras máquinas paralelas
Anos 80 – Computadores vetoriais. Máquinas paralelas comerciais para aplicações científicas
(metereologia / petróleo). Alto custo de desenvolvimento. Pequena escala, dificuldade de
programação.
Anos 90 até os dias de hoje – Multiprocessadores escaláveis. Redes de estações de trabalho.
Computação distribuída. Aplicações cliente/ servidor. Clusters. Grids (malhas computacionais em
que as aplicações executam em ambientes distribuídos, compostos por um grande número de
máquinas heterogêneas e administradas por diferentes instituições conectadas à internet. 
Paralelismo x computação paralela
Paralelismo:
Projeto de uma CPU
Projeto de uma arquitetura paralela
E/S sobreposta ao processamento
Computação paralela:
Coleção de elementos de processamento trabalhando em conjunto para a realização de uma tarefa
Paralelismo dentro de um processador:
Estágio 1 – Busca instrução
Estágio 2 – Decodifica instrução
Estágio 3 – Busca operandos
Estágio 4 – Executa instrução
Clusters 
Conjunto de computadores independentes interconectados, usados como recurso unificado para
computação. 
Vantagens:
Custo/benefício – Redução de custo para se obter processamento de alto desempenho, utilizando
máquinas de baixo custo.
Escalabilidade – Possibilidade de inclusão de novos componentes que podem ser adicionados
conforme a necessidade.
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 – Aumento da confiabilidade do sistema como um todo, caso alguma parte
falhe. 
Computação centralizada
Mainframe – Termo utilizado para se referenciar a um grande computador, normalmente produzido
por uma grande empresa. Todos os componentes 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
Microcomputadores e redes de computadores
Ampliação com relação a:
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
Sistemas distribuídos
Utilização de redes de computadores (locais e 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.
Para Tanenbaum: “Um sistema distribuído é um conjunto de computadores independentes que se
apresenta a seus usuários como um sistema único e coerente.”
Motivações: Necessidade de compartilhamento de recursos. O recurso pode ser um serviço,
arquivo, banco de dados, streaming de vídeo, etc.
Características:
Baixo acoplamento e atrasos na comunicação
Processos em sistemas computacionais distintos com probabilidade de falhas
Comunicação geralmente não confiável, onde há atrasos, perdas e baixa larguras de banda
Dificuldade em definir a ordem dos eventos e estado global do sistema, já que a comunicação
acontece pela troca de mensagens
Ambiente marcado pela heterogeneidade.
Comparação com sistemas centralizados
Vantagens
Melhor relação preço/desempenho
Capacidade de crescimento incremental
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
Desafios da computação distribuída
Ausência de fonte comum de tempo (relógio global)
Ausência de memória compartilhada (cada computador tem a sua)
Compartilhamento de recursos (o recurso está livre ou não?)
AULA 2
Surgimento dos sistemas distribuídos
À medida que a velocidade e confiabilidadedas redes de computadores aumentam, computadores
do mundo inteiro estão cada vez mais interconectados. A comunicação remota via rede,
originalmente reservada para instalação de computadores acadêmicos, tem sido amplamente
empregada. Em sistemas distribuídos, computadores remotos trabalham cooperativamente por meio
da rede, de modo que 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. 
Embora ofereçam muitas vantagens em relação a sistemas centralizados, os sistemas distribuídos
tem de manipular atrasos de comunicação e problemas de confiabilidade. Cabe salientar que é bem
difícil 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. 
Desafios da computação distribuída
Concorrência – A execução concorrente é uma característica intrínseca de um sistema distribuído,
na qual os processos disputam pelos recursos compartilhados. (geralmente não estão na mesma
máquina)
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. 
Falácias da computação distribuída
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
Atributos dos sistemas distribuídos
Latência – Tempo decorrido entre o início de uma operação e seu término.
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 gargalo. Um elemento de um sistema é o gargalo quando limita
seu desempenho, embora o resto do sistema ainda tenha folga para trabalhar. 
Escalabilidade – Capacidade de melhoria do desempenho do sistema distribuído conforme cresce o
número de elementos processadores. Pode ser medida por 3 dimensões:
Em relação a seu tamanho – facilidade em adicionar mais usuários e recursos ao sistema.
Em termos geográficos – Sistema no qual usuários e recursos podem estar longe uns dos outros.
Em termos administrativos – o sistema ainda pode ser fácil de gerenciar, mesmo que seja
abrangente. 
Balanceamento de carga – Característica que permite ao sistema distribuído dividir,
adequadamente, suas tarefas, de modo que um elemento processador não fique mais sobrecarregado
que 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 menos 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. Usuários ou programas não autorizados não devem ter acesso aos recursos do
sistema. Caso o sistema não seja capaz de garantir que essa diretriz seja cumprida, ele deve detectar
como, quando e por que não cumpriu o estabelecido. 
Migração de tarefas – Transferência da responsabilidade de execução de uma tarefa de um
elemento para outro. A migração de tarefas pode ser de processos ou de computação.
Migração de dados – Transferência de dados de um elemento processador para outro.
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.
Alguns aspectos da transparência (ISO, 1995):
Localização – oculta o lugar em que o 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 (SSI) é a propriedade de se ocultar a complexidade envolvida em uma
natureza distribuída e heterogênea de recursos disponíveis para usuários e aplicações, de tal forma
que estes visualizem o sistema como um único recurso. 
Benefícios do SSI:
Os serviços podem ser requisitados a partir de qualquer nó do sistema
A localização de dispositivos físicos 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. 
Máquinas mais velozes
Desde 1993, o site TOP500 publica semestralmente um ranking dos 500 computadores com maior
desempenho do mundo. Na lista do ranking, são obtidos pelo bechmark os seguintes resultados:
Rmax – performance para o maior problema executado em uma máquina (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 (Gflop/s)
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 5 sistemas da lista
combinados. 
O Brasil tem 2 supercomputadores na lista do ranking mais velozes do mundo: 
Tupi – Operado pelo Instituto Nacional de Pesquisas Espaciais (INPE) ocupa a 34° posição
Galileu – Operado pelo Núcleo de Atendimento em Computação de Alto Desempenho (NACAD/
COPPE) da Universidade Federal do RJ ocupa a 167° posição. 
Intranet
Conceito - “...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...”
Intranet então é o uso da tecnologia da internet na rede corporativa da empresa. Ela facilita a
distribuição de documentos, a transferência dr arquivos, a consulta à informação e outras
aplicações.
Computação em grade (grid computing)
Gridar = participar de um grid, colaborar.
A tecnologia por trás da computação em grade é um conjunto de softwares middleware que
gerenciam recursos distribuídos e espalhadospela organização, disponibilizando os servidores e,
eventualmente, os desktops da empresa. A idéia básica [e combinar os recursos disponíveis com as
demandas computacionais da empresa. A computação em grade é uma maneira bastante eficiente de
maximizar recursos computacionais. 
*Sofwares middleware – 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. 
Middleware – software que fornece interfaces padronizadas, de modo que computadores
heterogêneos possam comunicar-se entre si em sistemas distribuídos. 
Computação oportunista – projeto SETI
Consiste em usar redes de computadores para resolver problemas computacionais. Esse conceito se
popularizou com o sucesso do projeto SETI, baseado na idéia 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 execução de alguma tarefa. 
O Projeto SETI (Search Extraterrestrial Intelligence) é um projeto de pesquisa científica que se
propõe a detectar vida inteligente fora da Terra. Este projeto é considerado um dos mais sérios
projetos científicos desta natureza. 
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 deste tipo de computação. 
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, proporcionado 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. 
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 diferentes aplicações utilizando diferentes recursos, que podem ser acessador por
diferentes clientes. 
A virtualização pode contribuir muito nesse sentido. Primeiro porque a diversidade de plataformas e
máquinas pode ser reduzidas. Segundo 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. 
Supercomputadores e TI verde
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 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 tem liderado essas listas publicadas semestralmente, assim
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. Outra máquina que obteve destaque no mesmo
mês foi o IBM Blue Gene (protótipo/Q). 
AULA 3
Falhas em sistemas distribuídos
Uma característica dos sistemas distribuídos que os distingue dos 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 componentes e ao mesmo
tempo, deixar outros totalmente ilesos. A falha em sistemas 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 no conserto. Em outras palavras, o
sistema distribuído deve tolerar falhas e continuar a funcionar até certo ponto, mesmo na presença
dessas falhas. 
Existe uma forte relação entre ser tolerante a falhas e sistemas confiáveis. A confiabilidade
abrange uma série de requisitos:
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. A alta disponibilidade representa o que provavelmente funcionará em dado instante de
tempo. Assim, se um sistema nunca cai, mas é desligado por 2 semanas em um determinado mês
todos os anos, tem alta confiabilidade, mas somente 96% de disponibilidade. 
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 representa o que provavelmente continuará a funcionar sem
interrupção, durante um período de tempo relativamente longo. Assim, se um sistema ficar fora do
ar por 1 milissegundo a cada hora, terá disponibilidade de mais de 99,99%, mas sua confiabilidade
ainda será muito baixa.
Segurança – Consiste na propriedade de deixar de funcionar corretamente durante certo tempo e
nada de catastrófico acontecer. É o que acontece, por exemplo, com sistemas de controle de
processos usados de energia nuclear ou sistemas para enviar pessoas ao espaço. 
Capacidade de manutenção – É a facilidade com que um sistema que falhou possa ser consertado.
Sistemas de alta capacidade de manutenção também podem mostrar alto grau de disponibilidade,
em especial se as falhas puderes ser detectadas e reparadas automaticamente.
Falha, erro e defeito
Falha – físico
Erro – informação
Defeito – erro percebido pelo usuário
O defeito acontece quando o sistema não pode cumprir o que foi especificado ou prometido. 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 falha. 
Tipos de falhas
Trasientes – ocorrem uma vez e depois desaparecem. Se a operação for repetida, a falha não
acontecerá novamente. 
Intermitentes – ocorrem e desaparecem por sua própria vontade. Depois, essas falhas reaparecem e
assim por diante. Ex: Um conector com contato frouxo, pode falhar várias vezes.
Permanentes – Continuarão a existir até que o componente faltoso seja substituído. Ex: Chips
queimados, bugs de software. 
Modelos de falha 
Falha por queda – Uma vez que o servidor para, nada mais se ouve dele. Também é o caso de um
sistema operacional que para de funcionar e para o qual só há uma única solução: reiniciá-lo. 
Falha por omissão – Várias são as possibilidades de erro na falha por omissão. Podemos identificá-
la, por exemplo quando uma conexão entre um cliente e servidor foi estabelecida corretamente, mas
não havia nenhuma thread ouvindo as requisições que chegavam. 
Falha de temporização – A resposta do servidor se encontra fora do intervalo de tempo. Se o
fornecimento de dados for realizado muito cedo, poderá causar problemas para um receptor, se não
houver espaço de buffer suficiente para armazenar todos os dados recebidos. 
Falhas arbitrárias – Também conhecidas como falhas bizantinas, essas falhas são as mais sérias. Um
servidor podeestar produzindo saídas que nunca deveria ter produzido, mas que não podem ser
detectadas como incorretas. Situação pior acontece quando um servidor faltoso está trabalhando
maliciosamente em conjunto com outros servidores para produzir respostas erradas de forma
intencional. 
Falha de resposta – É um tipo sério de falha, que pode ocorrer de 2 maneiras:
Falha de valor – quando falha um mecanismo de busca que retorna sistematicamente páginas da
web não relacionadas com qualquer das palavras de busca utilizadas.
Falha de transição de estado – quando um servidor recebe uma mensagem que não pode
reconhecer. Se não for tomada nenhuma providência para manipular tal mensagem, acontecerá uma
falha de transição de estado. 
Técnicas de tratamento
1) 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. A técnica fundamental
para mascarar falhas é a redundância que pode ser de 3 tipos:
Redundância de informação – os bits extras são adicionados para permitir recuperação de bits
deteriorados.
Redundância de tempo – uma ação é realizada e, se for preciso, essa ação será executada
novamente. Ex: Transações de banco de dados. Se uma transação for abortadam ela pode ser refeita
sem causar nenhum dano. 
Redundância física – são adicionados equipamentos ou processos extras para possibilitar que o
sistema 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. Ex: Processos extras podem ser
adicionados ao sistema, de modo que se uma pequena quantidade deles cair, o sistema ainda pode
funcionar corretamente. 
Mascaramento de falhas e replicação
Grupo de processos fazem parte da solução para construir sistemas tolerantes à falha. Ter um grupo
de processos idênticos permite-nos mascarar um ou mais processos faltosos àquele grupo. Podemos
replicar processos e organizá-los em 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, onde um servidor primário coordena todas as operações de escrita. 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
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
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 um
número finito de etapas.
Detecção de falhas
Para mascarar falhas adequadamente, é preciso 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 falou. 
Quando se trata de detectar falhas de processos, há 2 mecanismos:
1) Os processos enviam as mensagens ativamente uns aos outros
2) Os processos esperam passivamente pela entrada de mensagens de processos diferentes
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 ping se esgotou, um nó requisita a outros vizinhos que verifiquem
se podem alcançar o nó que falhou. 
*A detecção de falhas é uma das bases da tolerância à falha em sistemas distribuídos.
Recuperação
Uma vez ocorrida a falha, é essencial que o processo em que a mesma aconteceu possa se recuperar.
*Um erro é parte de um sistema que pode levar a uma falha. A idéia geral de recuperação de erro é
substituir um estado errôneo por um estado livre de erro. 
Formas de recuperação de erro
Existem 2 formas:
Recuperação retroativa – Traz o sistema de seu estado com erro presente para um estado anterior
que estava correto. Pra isso, é necessário registrar o estado do sistema de tempos em tempos e
restaurar tal estado registrado quando ocorrer o erro. Toda vez que é feito um registro, se diz que foi
feito um check point (ponto de verificação). De modo geral, técnicas retroativas de recuperação de
erro são amplamente aplicadas na recuperação de falhas em sistemas distribuídos. A principal
vantagem é que esse método pode ser aplicado de modo geral, independente do sistema ou
processo.
Recuperação para a frente – Em vez de retroagir para um estado anterior, realiza-se uma tentativa
para levar o sistema a um novo estado correto, a partir do qual ele possa continuar. O principal
problema desse método é que precisamos saber de antemão quais os erros podem ocorrer. 
AULA 4
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 em 4 categorias
baseadas em tipos diferentes de fluxos usados por computadores.
*Um processador aceita 2 fluxos: 
um fluxo de instruções 
um fluxo de dados. 
Classificação:
SISD (Single instruction stream/single data stream) – computadores de fluxo único de
instruções e fluxo único de dados 
* uma instrução para um dado.
É o tipo mais simples: São os monoprocessadores tradicionais, onde um único processador buscar
uma instrução por vez e executa sobre um único item de dado. Ex: Arquitetura sequencial e
máquina de Von-Neumann. 
Técnicas como a de pipeline, a da palavra de instrução muito longa (Very Long Instruction –
VLIW) e a do projeto superescalar podem introduzir paralelismo em computadores SISD. Além
disso a tecnologia Hyper-Threading da Intel introduz paralelismo, criando processadores virtuais
por meio de um único processador físico, dando ao sistema operacional a impressão de que está
executando em 2 processadores com um pouco menos da metade da velocidade do processador
físico.
MISD (Multiple instruction stream/single data stream) – computadores de fluxo múltiplo de
instruções e fluxo único de dados
*múltiplas instruções para um dado
Esses tipos de computadores não são usados. Uma arquitetura MISD teria várias unidades de
processamento que agiriam sobre um único fluxo de dados. Cada unidade executaria uma instrução
diferente nos dados e passaria o resultado para a próxima unidade.
SIMD (Single instruction stream/multiple data stream) – Computadores de fluxo único de
instruções e fluxo múltiplo de dados.
*uma instrução pra múltiplos dados
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. Se houver mais elementos de dados do que
unidades de processamento, essas unidades buscarão elementos de dados adicionais para o ciclo
seguinte. Ao contrário da arquitetura SISD que exigiam um laço para realizar a mesma operação em
um elemento de dados por vez (requerendo que o processador SISD decodificasse a mesma
instrução várias vezes), a arquitetura SIMD lê um bloco de dados por ves, reduzindo dispendiosas
transferências da memória para o registrador. Por isso, as arquiteturas SIMD são mais efetivasem
ambientes em que um sistema aplica a mesma instrução a grandes conjuntos de dados. Ex:
processadores vetoriais e processadores matriciais.
MIMD (Multiple instruction stream/multiple data stream) – Computadores de fluxo múltiplo
de instruções e fluxo múltiplo de dados
*múltiplas instruções para múltiplos dados
Trata-se de multiprocessadores em que as unidades processadoras são completamente
independentes e operam sobre fluxos de instruções separadas. Esses sistemas normalmente contem
hardware que permite que os processadores sincronizem-se uns com os outros quando necessário,
como é o caso de acessarem um dispositivo periférico compartilhado, por exemplo. 
Essa classe foi subdividida em sistemas fortemente acoplados e fracamente acoplados. 
Esquemas de interconexão de processadores
O esquema de interconexão de um sistema multiprocessador descreve de que modo os componentes
do sistema são conectados fisicamente (por exemplo: um processador e módulos de memória). Um
sistema de interconexão consiste de nós (compostos de componentes do sistema ou de chaves que
fazem o roteamento das mensagens entre os componentes) e enlaces (conexão entre 2 nós). 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ó. 
Uma técnica para medir a tolerância à falhas de um esquema de interconexão é contar o número de
enlaces de comunicação que devem falhar antes que a rede possa não funcionar adequadamente.
Isso pode ser quantificado por meio da largura de bisseção (número mínimo de enlaces que
precisam ser cortados para dividir a rede em duas metades não conectadas). Sistemas que tem
larguras de bisseção maiores, são mais tolerantes à falha do que aqueles que tem larguras de
bisseção menores, pois mais componentes tem de falhar antes que o sistema inteiro tenha
problemas. O desempenho de um esquema de interconexão depende da latência de comunicação
entre nós, que pode ser medido de várias maneiras, como por exemplo, por meio de latência média. 
Outra medição de desempenho é o diâmetro da rede (distância mais curta entre os nós mais
remotos do esquema de interconexão). Para determiná-lo é necessário 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. Aí então, será possível identificar o maior desses caminhos. 
Arquiteturas de acesso à memória
Multiprocessadores (memória compartilhada)
UMA (acesso uniforme à memória)
*todos os processadores compartilham a mesma memória principal
Essa arquitetura requer 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.
NUMA (acesso não uniforme à memória)
*memória global compartilhada e memória local
Essa arquitetura 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 memória local do processador. 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 local do que ao restante da memória global, pois o acesso à memória global
requer que se percorra a rede de interconexão. 
CC-NUMA (NUMA com cache coerente)
São multiprocessadores NUMA que impõem coerência de cache. Cada endereço de memória física
está associado a um nó nativo, responsável por armazenar o item de dado com aquele endereço de
memória principal. 
COMA (arquitetura de memória somente de cache)
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. A latência de cache (cache miss latency) pode ser significativa quando o dado requisitado
não estiver presente na memória local. 
 
*Latência de cache = tempo requerido para recuperar dados que não estão no cache. 
Multicomputadores (memória não compartilhada, se comunicam por mensagens)
NORMA (sem acesso à memória remota)
São fracamente acoplados e não fornecem nenhuma memória global compartilhada. Cada nó
mantém sua própria memória local implementam frequentemente uma memória virtual
compartilhada comum (Shared Virtual Memory - SVM)
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.
Execução de uma tarefa
Existem 3 maneiras de executar uma tarefa de forma mais rápida:
Aumento de velocidade de CPU – Algumas limitações estão associadas à aquisição de CPUs com
maior poder de processamento. 
Otimização do algoritmo – Geralmente, conseguimos aumentar o desempenho de um sistema com
a melhora do algoritmo.
Colaboração – Quando pensamos em trabalhar com colaboração, devemos atentar para a diferença
entre paralelismo e concorrência.
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).
Aspectos técnicos da programação distribuídas:
- Interação da aplicação e do usuário com o ambiente distribuído em níveis diferentes
- Suporte á plataforma heterogêneas através de uma camada de software entre o kernel e a aplicação
(middleware)
- Problemas como custo e carência de produtos de software adequados
- Programação paralela, utilizando bibliotecas de troca de mensagem (como o MPI e PVM), ou
bibliotecas baseadas em memória compartilhada (como 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 processadores que possuam memória própria. 
Os processos possuem acesso à memória local. As informações 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.
AULA 5
Introdução aos modelos de comunicação e arquitetura cliente/servidor
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 interagem. 
Fundamentais – Aqueles que definem o comportamento e as propriedades dos componentes.
A arquitetura ou organização de um sistema representa sua estrutura em termos de componentes
especificados separadamente. A maior preocupação é tornar o sistema:
confiável
gerenciável
adaptável
rentável
*O modelo de arquitetura de um sistema distribuído primeiramente simplifica e abstrai as funções
dos componentes individuais desse sistema. Em seguida ele considera o posicionamento dos
componentes em uma rede de computadores, buscando definir padrõespara a distribuição de dados
e da carga de trabalho. Considera também os inter-relacionamentos entre os componentes, isto é,
seus papéis funcionais e os padrões de comunicação entre eles. 
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 que são: plataforma e middleware.
Plataforma – Denominação frequente para as camadas de hardware e software de nível mais baixo.
Middleware – Camada de software que tem como objetivo mascarar a 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 maneira a atender os requisitos de
desempenho e confiabilidade.
Os modelos de arquitetura são classificados como:
Cliente/servidor
Peer-to-peer
De variações (utiliza-se de serviços oferecidos por diversos servidores)
Requisitos de projeto dos modelos de arquitetura
Desempenho – Os principais problemas associados à limitação 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 fornecidos aos clientes são a confiabilidade, segurança, desempenho,
adaptabilidade e disponibilidade.
Replicação – Os problemas de desempenho podem ser solucionados em parte 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 domínios da aplicação, o que
significa que é crucial não apenas nas atividades de omando e controle mas também em aplicações
comerciais. 
Modelo cliente/servidor
Como a maioria das redes, a internet utiliza um mecanismo simples: um aplicativo é ligado no
primeiro e espera que o outro aplicativo faça contato. O segundo aplicativo 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 como cliente. Para iniciar o contato, o cliente precisa saber onde o servidor está
rodando e especificar a localização para o software de rede. 
Como um cliente especifica a localização de um servidor? Por exemplo na internet, a localização é
dada por um par de identificadores: O computador e o aplicativo. 
Geralmente os aplicativos desenvolvidos para a internet seguem o mesmo paradigma básico quando
se comunicam, Dois aplicativos estabelecem comunicação, trocam mensagens e então finalizam a
comunicação. 
Passos:
O aplicativo servidor é ativado e aguarda o contato de um cliente.
O cliente especifica a localização do servidor e solicita estabelecimento de uma conexão.
Após o estabelecimento de 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)
API – Conjunto de aplicativos disponíveis a um programador. Ela especifica os parâmetros para
cada operação, bem como suas semânticas. 
Um servidor inicia a aplicação chamando a função await-contact para esperar pelo contato de um
cliente. O cliente então inicia a aplicação chamando a função make contact para estabelecer contato.
Uma vez que o cliente tenha contatado o servidor, eles podem trocar mensagens com send e recv.
Os 2 aplicativos devem ser programados para saber se devem enviar ou receber, pois se ambos
tentarem receber sem enviar, ficarão bloqueados. Após o término de 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 do 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 sen_eof, a
comunicação é encerrada. 
Para manter a API exemplo, independente de algum sistema operacional e software de rede em
particular, são definidos 3 tipos de dados: 
Características de clientes e servidores
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 o servidor, e
quando necessário pode acessar múltiplos serviços, mas contata de forma ativa, um servidor remoto
de cada vez. O software cliente não exige hardware especial ou sistema operacional sofisticado.
Em contrapartida, o software servidor é um programa privilegiado, de propósito especial, dedicado
a fornecer um serviço, mas pode tratar simultaneamente de múltiplos clientes remotos. 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. Diferentemente do software
cliente, o servidor exige hardware poderoso e um sistema operacional sofisticado. 
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 e este 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. Em outros
casos, o servidor fornece saída contínua sem qualquer requisição e assim que o cliente contata o
servidor, este começa a enviar-lhe dados. 
Protocolos de transporte e interação cliente/servidor
Como a maioria dos aplicativos, cliente e servidor usam um protocolo de transporte para
comunicarem-se. 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 baixar para enviar e receber mensagens
individuais. Desse modo, um computador necessita de uma pilha completa de protocolos pra
executar um cliente ou um servidor. 
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. Pra isso, serão necessárias 2 características:
- O computador deve ter recursos de hardware suficientes.
- O computador deve ter um sistema operacional que permita que múltiplos aplicativos executem de
modo concorrente. (Ex: UNIX, Linux ou Windows)
*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. 
AULA 6
Comunicação utilizando sockets e Chamada a Procedimento Remoto (RPC)
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 muina.
A API de socketsOs protocolos de comunicação geralmente não especificam a API que as aplicações devem utilizar.
Eles especificam quais as operações 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
originou-se como parte do sistema operacional BSD UNIX. Tanto neste quanto nos sistemas que
dele derivam, as funções de cokets são parte do próprio sistema operacional. 
Para um programador, seu programa chama procedimentos de sockets, que são providos por
procedimentos do sistema operacional ou por rotinas de biblioteca. Assim, 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. 
Comunicação de socket e entrada/saída do UNIX
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/saída. Um socket
deve ser criado, usado e 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.
Assim, 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 read ou write para recuperar ou armazenar dados no arquivo. Por fim, o
aplicativo chama close para especificar que terminou de usar o arquivo 
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 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 read e write são bem
gerais, uma 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 sockets difere da entrada e saída convencional de dados porque um aplicativo
deve 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. Um aplicativo cria um socket e então invoca funções para especificar em detalhes como será
usado. 
A vantagem da abordagem de sockets é o fato de que a maioria das funções tem 3 ou menos
argumentos. A desvantagem indica que um programador deve lembra-se de chamar múltipĺas
funções sockets. 
Procedimentos que implementam a API de sockets
Procedimento socket – cria um socket e retorna um descritor inteiro.
Sockfd = socket (protofamily, type, protocol);
São argumentos desse procedimento:
protofamily – especifica a família de protocolos a ser usada com o socket
type – especifica o tipo de comunicação que o socket usará
Os tipos mais comuns de comunicação são: 
sock_stream (transferência de stream orientada à conexão)
sock_dgram (transferência sem conexão orientada e mensagens)
protocol – especifica um protocolo de transporte particular usado com o socket. 
Procedimento bind – Associa uma porta da máquina ao socket. 
bind (sockfd, localaddr, addrlen)
São argumentos desse procedimento:
sockfd – descritor de socket retornado por socket ();
localaddr – estrutura que especifica o endereço local a ser designado ao socket
addrlen – 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. Uma estrutura sockaddr tem 3 campos:
struct sockaddr {
u_char sa_len; (comprimento total do endereço)
u_char sa_family; (família do endereço)
char sa_data [14]; (o endereço propriamente dito)
*Cada família de protocolos define o formato exato dos endereços usados com o campo sa_data de
uma estrutura sockaddr. 
Procedimento connect – Estabelece uma conexão com um servidor específico. É chamado por
clientes.
connect (sockfd, saddress, saddresslen); 
São argumentos desse procedimento:
sockfd – descritor de socket retornado pela chamada socket ( ) no computador do cliente
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. 
Procedimento listen – Indica ao kernel que está apto a receber conexões.
listen (sockfd, backlog);
São argumentos desse procedimento:
sockfd – descritor de um socket e amarrado a um endereço local
backlog – especifica o número de conexões permitidas, isto é, o comprimento para fila de
requisição do cocket.
Procedimento accept – aceita mensagens.
accept (sockfd, caddress, caddresslen)
São argumentos desse procedimento:
sockfd – descritor de um socket a uma porta de protocolo específica
caddress – endereço de uma estrutura do tipo sockaddr ou sockaddr_in
caddresslen – varável inteira local.
*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 2 chamadas, o servidor que usa um protocolo de
transporte sem conexão está pronto para ceitar mensagens. Caso o servidor utilizar um protocolo de
transporte orientado à conexão, é necessário chamar o procedimento listen 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ópria requisição de conexão. 
*O accept cria um novo socket para a conexão e retorna o descritor do novo socket para quem o
chamou. O servidor usa o novo socket para se comunicar com o cliente e fecha-o ao terminar. 
Procedimentos send, sendto e send msg
Os clientes e servidores precisam enviar informações. Geralmente, um cliente envia uma requisição
e o servidor envia uma resposta. Se o socket está conectado, o procedimento send pode ser usado
para transferir dados. 
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. O procedimento sendmsg executa e mesma operação
que o sendto, mas abrevia os argumentos, definindo uma estrutura. A lista de argumentos mais curta
pode tornar os programas que usam sendmsg mais fáceis de serem lidos. 
Procedimentos recv, recvfrom, recvmsg
O cliente e o servidor precisam receber dados enviados pelo outro. Para tanto, a API de sockets
fornece vários procedimentos que podem ser usados. Por exemplo, um aplicativo pode chamar recv
para receber dados de um socket conectado. Se um socket não está conectado, ele pode ser usado
para receber mensagens de um conjunto arbitrário de clientes. Nesses casos, o sistema retorna o
endereço do remetente junto com cada mensagem recebida. Os aplicativos usam o procedimento
recvform para receber mensagem e o endereço do seu remetente. O recvform registra o endereço do
remetente exatamente da mesma forma que sendto espera. A API de sockets incluium procedimento
de entrada equivalente ao procedimento de saída sendmsg, que é o recvmsg. Ele opera como
recvform mas exige menos argumentos. O argumento do recvmsg é o msdgstruct.
Procedimento close – Informa ao sistema para finalizar o uso de um socket. 
close (sockfd);
Se o socket está usando um protocolo de transporte orientado à conexão, o close termina antes de
fechar o socket. 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 ao socket. 
Comunicação por sockets por TCP:
Comunicação por sockets por UDP
Comunicação utilizando Chamada a Procedimento Remoto (RPC)
Muitos sistemas distribuídos são baseados em troca explícita de mensagens entre processos.
Contudo, os procedimentos send e 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 trmpo, até que um artigo propôs um modo 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 chamados (cliente) é suspenso e a execução do procedimento
(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 cliente
deve ser ligado a um pequeno procedimento de biblioteca de stub do cliente, que representa o
procedimento servidor no espaço de endereçamento do cliente. Da mesma forma, o servidor é
ligado a um procedimento denominado stub do servidor. Esses procedimentos escondem o fato de
uma chamada de procedimento do cliente para servidor não ser local. 
Componentes da RPC (Remote Procedure Call/ Chamada a Procedimento Remoto)
Tratamento de falhas com RPC
O cliente não é capaz de localizar o servidor – Isso ocorre devido a uma falha em função do
servidor não estar disponível. O tratamento específico desse erro elimina a transparência.
Perda de mensagens solicitando serviço – Devemos usar um contador de tempo. Se o tempo
expirar e a resposta não chegar, retransmita a mensagem.
Perda de mensagem com resposta – O que torna a mensagem idempotente.
Quedas do servidor
Queda do cliente – Situação em que o cliente manda uma requisição e antes de receber a resposta,
sai do ar. Essa situação causa 2 problemas: a geração de processos órfãos (zumbis) e o tempo de
CPU gasto desnecessariamente pelo servidor. 
*Em relação à RPC, a localização física e a arquitetura do servidor são transparentes.
AULA 7
Modelo Peer-to-peer (P2P)
“Sistemas P2P são sistemas distribuídos que consistem em nós interconectados com capacidade de
auto-organização em relação à topologia da rede, com o propósito de compartilhar recursos.”
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. Toda pessoa pode se comunicar com uma
ou mais pessoas, não existe qualquer divisão estrita entre clientes e servidores. 
Diversos sistemas P2P (como o BitTorrent) não possuem informação centralizada, ao contrário
esses sistemas mantém suas informações locais e compartilham uma lista de peers vizinhos que os
compõem. Normalmente a comunicação P2P é usada para compartilhar diferentes tipos de arquivos.
A tecnologia P2P pode ser usada de diversas maneiras. O tráfego P2P tornou-se rapidamente
responsável por uma grande fração de todo o tráfego na internet. A idéia 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. Geralmente, os computadores são
apenas domésticos e chamados de peers (pares), porque cada um pode, alternadamente, atuar como
cliente para outro peer ou como servidor. 
O que torna os sistemas P2P interessantes, é 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. 
Características
- Não há coordenação central (se cair um nó, não cai tudo)
- Nenhum peer tem uma visão global do sistema, porém todos os dados e serviços são acessíveis de
qualquer peer.
- Escalabilidade (capacidade de crescer com facilidade)
- Heterogeneidade
 
Tipos de redes P2P
P2P puro – Não existe servidor centralizado. Os peers de comunicam diretamente. Exemplos:
Gnutella e FreeNet.
P2P híbrido – O servidor é conectado primeiro para obter meta informações (identidade do peer,
credenciais de segurança) e este então é redirecionado para o peer requisitado que se comunicam
diretamente. Exemplos: Naspter, Groove.
Intermediários – SuperPeers contém algumas informações que outros peers podem não ter. Os peers
procuram informações nos SuperPeers, uma vez que não conseguiram achá-las em nenhum outro
lugar. Exemplo: Kazaa.
Aplicações
Compartilhamento de recursos (processamento, hardware e arquivos)
Trabalho colaborativo (groupware)
Compartilhamento de arquivos 
Distributed Hash Tables (DHTs)
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). 
Um ID randômico é associado a cada peer que, por sua vez, conhecem um determinado número de
peers. Quando um novo documento é compartilhado, cada peer encaminha o documento ao peer
cujo ID é mais próximo ao ID do documento. Esse processo é repetido até que o ID do peer atual
seja o mais próximo do documento ou o documento seja encontrado. 
O Protocolo Bit Torrent
Existem dezenas de clientes disponíveis gratuitamente que entendem esse protocolo.
Torrent é um arquivo que contém 2 tipos de informação: o tracker e os chuncks.
Tracker – Servidor que mantém uma lista de peers que estão fazendo download/upload. (swarm)
Chucks – Lista de blocos de mesmo tamanho que compoem o conteudo do torrent.
*Swarm – Conjunto de peers ativos que entram em contato com o tracker regularmente para
informar se ainda estão ativos. Quando um novo peer entra em contato com o tracker para se juntar
ao swarm, o tracker lhe informa sobre outros peers no swarm. 
AULA 8
Sistemas de arquivos distribuídos
Os Sistemas de Arquivos Distribuídos – Distribuited File System (DFS) são a base para muitas
aplicações distribuídas, pois permitem que vários processos compartilhem dados de modo seguro e
confiável por longos períodos. Por isso, esses sistemas tem sido usados como a camada básica para
sistemas e aplicações distribuídas. 
*DFS = Sistemas de arquivos em que os clientes, servidores e dispositivos de armazenamento estão
dispersos entre as máquinas de um sistema distribuído. 
Um sistema de arquivos fornece serviço de arquivos para clientes. Umservidor de arquivos controla
um conjunto de dispositivos locais de armazenamento (geralmente discos magnéticos) em que os
arquivos são armazenados e recuperados conforme as solicitações dos clientes. Em um DFS, a
atividade de serviço deve ser realizada através da rede. A interface cliente de um serviço de arquivo
é formada por um conjunto de operações primitivas de arquivo, tais como criar, apagar, ler e
gravar um arquivo. Esse sistema pode ser implementado como parte de um sistema operacional
distribuído ou por uma camada de software cuja tarefa seja 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. 
Funções do DFS
- Aparecer para seus clientes como um sistema de arquivos convencional centralizado. Então, é
função sua a responsabilidade de localizar os arquivos e providenciar o transporte de dados. Essa
transparência facilita a mobilidade do usuário, trazendo seu ambiente para onde quer que ele se
conecte. 
- Gerenciar um conjunto de dispositivos de armazenamento dispersos. 
*O sistema possui como 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, mas em um
DFS, um acesso remoto possui um overhead adicional atribuído à estrutura distribuída. Esse
overhead inclui o tempo de liberação da solicitação para um servidor e o tempo para retornar a
resposta ao cliente pela rede. 
Serviços de um DFS 
Serviço de armazenamento
Alocação e gerenciamento de espaço
Operações para armazenamento e recuperação de dados
Serviço de arquivos
Serviço que trata das operações com arquivos independentes como:
Modos de acesso
Políticas de caching
Semântica de compartilhamento
Replicação
Controle de concorrência
Consistência de dados
Serviço de nomeação
Fornece mapeamento entre nomes de arquivos e seus identificadores.
Nomeação e transparência
Nomeação – É um mapeamento entre objetivos lógicos e físicos. 
A transparência oculta o local em que o arquivo está localizado na rede.
Operação – Dado um nome de arquivo, o mapeamento retorna um conjunto de localizações desses
réplicas do arquivo. Nessa abstração, ficam ocultas tanto a existência de múltiplas cópias quanto sua
localização. 
Transparência de localização – 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
mudar de localização física de armazenamento, No mapeamento dinâmico, se pode mapear o
mesmo nome de arquivo para diferentes locais em 2 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 fornecem um mapeamento estático e transparente de
localização para nomes no nível do usuário. No entanto, esses sistemas não suportam a migração de
arquivos, ou seja, a mudança automática da localização de um arquivo é impossível. Assim, a noção
de independência de localização é irrelevante para esses sistemas. Os arquivos são associados
permanentemente a um conjuntos específico de blocos de disco. Arquivos e disco 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 – O arquivo é identificado com alguma combinação de seu nome de host
e seu nome local, garantindo um nome exclusivo em todo o sistema. Esse esquema de nomeação
não é transparente quanto à localização e nem independente de localização, mas as mesmas
operações de arquivos podem ser utilizadas tanto para arquivos locais quanto para remotos.
Abordagem popularizada pelo Network File System (NFS) – Meio de anexar diretórios remotos
a diretórios locais, dando assim a aparência de uma árvore de diretórios coerente.
Abordagem única estrutural global de nomes – Uma única estrutura global de nomes abrange
todos os arquivos do sistema. Essa estrutura é igual à estrutura de um sistema de arquivos
convencional, mas na prática os diversos arquivos especiais tornam esse objetivo difícil de ser
atingido. 
Modelos de acesso
Modelo se 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
de dados. Uma das maneiras mais comuns para implementar o serviço remoto é o paradigma da
Chamada de Procedimento Remoto (RPC). Para garantir um desempenho razoável do mecanismo
remoto, podemos utilizar uma forma de armazenamento em cache, que reduz tanto o tráfego de rede
quanto o de entrada e saída de disco. 
Modelo de caching – 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. (redução do tráfego na
rede). Quando uma cópia do cache for modificada, as mudanças precisarão se refletir nas cópia-
mestra para preservar a semântica de consistência relevante. 
Comparação entre os 2 modelos – Quando o armazenamento em cache é utilizado, o cache local
pode manipular um bom número de acessos remotos. A maioria dos acessos remotos será atendida
rapidamente quando os acessos locais, os servidores são contatados apenas ocasionalmente e dessa
forma a carga no servidor e o tráfego na rede serão reduzidos, aumentando a escalabilidade. Já
quando o método de serviço remoto é utilizado, cada acesso remoto é manipulado através da rede,
ocasionando prejuízo do aumento de tráfego na rede, carga no servidor e redução de desempenho.
Problema do armazenamento em cache: Consistência do cache. Quando as gravações não são
frequentes, ok, o armazenamento em cache é superior, mas quando existem gravações frequentes ou
a capacidade da máquina é insuficiente, os mecanismo empregados para resolver o problema da
consistência incorrem em overhead significativo em termos de desempenho, tráfego na rede e carga
no servidor. 
Stateful (serviço com estado) X Stateless (serviço sem estado)
Existem 2 abordagens para o armazenamento de informações no servidor quando co cliente acessa
arquivos remotos:
Statetul (serviço com estado) – O servidor busca cada arquivo que estiver sendo acessado pelo
cliente.
Stateless (serviço sem estado) – O servidor simplesmente fornece blocos conforme são solicitados
pelo cliente, sem saber como esses blocos estão sendo utilizados. 
*A vantagem de um serviço com estado sobre o sem estado é o aumento do desempenho.
Informações de arquivo são armazenados 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 as solicitações do
cliente. 
Replicação de arquivos
Em um DFS, a replicação de arquivos em diferentes máquinas é uma redundância útil para melhorar
a disponibilidade. Há 3 maneiras:
Replicação explícita – Quando a responsabilidade fica a cargo do programador. O serviço pode
permitir diversos índices de arquivos para cada arquivo. Esse tipo de replicação é de difícil
implementação e não permite aplicação da transparência. (+ trabalhoso, copia individualmente)
Replicação atrasada – 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. (atualiza um servidor, que se encarrega de se replicar para
outros depois)
Replicação em grupos – Quando a operação de escrita é realizada em todos os arquivos ao mesmo
tempo (multicast atômico). (mando uma única mensagem para determinado cache e todos os
servidores daquele grupo recebe a atualização). 
Semântica de compartilhamento
Quando 2 ou mais usuários compartilham o mesmo arquivo ao mesmo tempo,é necessário definir a
semântica de leitura e de escrita para evitar problemas. 
Semântica UNIX – As alterações são visíveis instantaneamente. 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. 
Semântica de Sessão – As alterações em um arquivo aberto são inicialmente visíveis apenas para o
processo, ou possivelmente naquela máquina que modificou o arquivo. As alterações ficam visíveis
para outros processos e máquinas somente quando o arquivo for fechado. 
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, as únicas operações em arquivos são create e 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. Assim, embora seja impossível modificar o arquivo
específico, continua sendo possível substituir esse arquivo por um novo. Em outras palavras, os
arquivos não podem ser atualizados, mas os diretórios podem. 
AULA 9
Serviços Web
Os web services abrangem um conjunto de padrões relacionados que podem habilitar quaisquer 2
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 diferentes computadores devem poder comunicar-se. Tecnologias como DCOM e
CORBA habilitam a comunicação entre componentes distribuídos, mas também impõem um custo
para viabilizar essa comunicação. 
Os serviços web funcionam a partir do uso de padrões abertos (não proprietários). Permitem a
comunicação entre 2 componentes de software independentemente das tecnologias utilizadas
(interoperabilidade). Fornecem uma interface de serviços para a interação com os servidores. As
aplicações podem utilizar a sua própria linguagem, que será traduzida para XML (Extensible
Markup Language). 
*Padrões abertos permitem que empresas que utilizam plataformas diferentes se comuniquem. 
Arquitetura SOA
Os serviços web são descritos em um ambiente distribuído com uma arquitetura denominada SOA
(Service Oriented Architeture – arquitetura orientada a serviço). Essa arquitetura possui as seguintes
características:
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. 
Orientação à mensagem – O serviço é formalmente definido em função das mensagens trocadas.
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 o
requisito absoluto.
Plataforma neutra – As mensagens são enviadas em uma plataforma neutra, de formato
padronizado e fornecido através das interfaces. 
*Web service é impĺementação + usual do SOA
Componentes da arquitetura SOA
Os componentes da arquitetura SOA representam uma coleção de serviços que atuam entre si e se
comunicam através da troca de mensagens XML. São eles:
Provedor de serviço web – Responsável pela descrição das informações de conexão na chamada
ao serviço e pela publicação e descrição do web service no registro dos serviços.
Registro dos serviços – Manutenção de diretório com as informações sobre os serviços. Na SOA, o
padrão adotado para o registro é o UDDI (Universal Description and Integration)
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
Essa classificação é segundo a funcionalidade de suas especificações e é dividida em 4 conjuntos de
especificações que tem em comum o uso da linguagem XML:
Descrição de serviços – Utilizada para definir as operações, as mensagens e os tipos de dados de
um serviç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.
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.
Protocolo de comunicação – Utilizados para definir, estabelecer e manter a comunicação entre as
aplicações. 
Comunicação entre web services
A comunicação entre serviços web é separada em 4 camadas que tratam da requisição e resposta
entre o cliente e o servidor. A construção de web services é baseada nos padrões XML e SOAP. A
comunicação entre os dados, por sua vez é realizado através do protocolo HTTP ou HTTPS. 
UDDI
WSDL
SOAP
XML
UDDI (Universal Description, Discovery and Integration) – É 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. Sendo assim, o registro de serviços UDDI possui 2
tipos de clientes: 
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 3 papéis representados sob a forma de XML Schema:
Páginas brancas – Contém identificadores sobre o contato técnico do serviço oferecidos
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 do serviços
WSDL (Web Services Description Language) – É a interface para o uso de um web service, que
fornece um método padronizado para descrever serviços web e suas capacidades específicas. Trata-
se de uma linguagem baseada em XML que descreve, de forma padronizada e independente da
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. 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.
Mensagem – Informação que será trocada.
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, saída ou erro.
Operação – Ação suportada pelo serviço.
SOAP (Simple Object Access Protocol) – É 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 RPCs (Remote Procedure Calls) ou trocas de mensagens. Essa

Outros materiais