O documento discute os principais aspectos que devem ser considerados em projetos de sistemas distribuídos, incluindo heterogeneidade, flexibilidade, segurança, escalabilidade, confiabilidade, disponibilidade, concorrência, desempenho e transparência.

1. Sumário
1. Aspectos gerais de um projecto de sistemas distribuído (que devem ser
considerados) ...................................................................................................................... 2
1.1. Heterogeneidade ................................................................................................. 2
1.2. Flexibilidade ....................................................................................................... 3
1.3. Segurança............................................................................................................ 3
1.4. Escalabilidade ..................................................................................................... 3
1.5. Confiabilidade..................................................................................................... 4
1.6. Disponibilidade ................................................................................................... 5
1.7. Concorrência ....................................................................................................... 5
1.8. Desempenho........................................................................................................ 5
1.9. Transparência...................................................................................................... 6
Página 1 de 6

2. 1. Aspectos gerais de um projecto de sistemas
distribuído (que devem ser considerados)
1.1. Heterogeneidade
• Capacidade do SD ser utilizado com diversos tipos de redes, hardware, sistema
operacional, linguagem de programação e implementação.
o Redes: utilização de protocolos que são utilizados em diversos tipos de
redes (Por exemplo, a comunicação na Internet é realizada através de
protocolos da Internet).
o Hardware: diferentes arquitecturas representam tipos de dados de formas
diferentes (Por exemplo, representação do inteiro apresentam "byte
orderings" diferentes em arquitecturas diferentes).
o Sistema operacional: as APIs (Appication Programming Interface –
Interface de Programação de Aplicativos) dos sistemas operacionais
existentes para os protocolos da Internet podem ser bem diferentes (Por
exemplo, chamadas para troca de mensagens UNIX versus Windows).
o Linguagem de Programação: as linguagens possuem diferentes
representações para as suas estruturas de dados (Por exemplo, tipo char
nas linguagens Java e ANSI C)
o Implementação: implementações realizadas por programadores diferentes
necessitam respeitar um padrão comum para representação das
mensagens, a fim de que seja possível a comunicação entre os processos.
(Por exemplo, Web Servers e browsers)
o Middleware: camada de software que provê uma abstracção na
programação, pois "mascara" a heterogeneidade do sistema. Por exemplo,
Java RMI.
o Código-móvel: código que é enviado a outro computador e executado no
destino. Por exemplo, Java Applets.
Página 2 de 6

3. 1.2. Flexibilidade
o Possibilidade de estender e/ou reimplementar um sistema possibilitando a
inclusão de novos serviços
o Necessidade de documentação, utilização de padrões, interfaces abertas,
documentos técnicos
o Acordo entre desenvolvedores
o Permite a integração de sistemas desenvolvidos por vendedores diferentes
seguindo um padrão
o Permitir implementação de novo serviço (futuro)
1.3. Segurança
o Baseado no "valor" das informações/recursos aos usuários.
o Componentes:
Confidencialidade: protecção contra acesso de pessoas não
autorizadas
Integridade: protecção contra alterações, corrupção
Disponibilidade: protecção contra interferência no acesso
Utilização de técnicas de criptografia para garantir a identificação
do emissor/receptor.
o Outros desafios:
DOS (denial of service attack): ataque que tem como objetivo tirar
um serviço do ar "bombardeando-o" com requisições.
Segurança em código-móvel: execução de programas impróprios;
pode abrir brechas para invasão (vírus).
1.4. Escalabilidade
o Capacidade de um sistema continuar operando após o aumento do número
de recursos e/ou usuários.
o Prevê que o custo de adição de um usuário seja proporcional a adição de
recursos
Página 3 de 6

4. 1.5. Confiabilidade
o O SD deve ser projectado para aumentar a confiabilidade do sistema
utilizando de forma adequada os recursos disponíveis
o A existência de diversos recursos não garante a confiabilidade em um SD
o Falha – defeito mecânico ou algorítmico que pode gerar um erro
ocasionando a falha do sistema
fail-stop: após a falha o sistema para de funcionar
Byzantine: após a falha o sistema gera resultados incorrectos (mais
complicado para tratar!)
o SD deve ser projectado para
Evitar falhas: minimizar falhas
Utilização de componentes altamente confiáveis (testes)
Tolerar falhas: sistema continua operando corretamente, mesmo
com menor desempenho, após uma falha parcial
• Técnicas de redundância: replicação de componentes
• Mecanismos de controle distribuído: servidores
independentes provendo o mesmo serviço
• Objetivo principal: evitar ponto único de falha!
Detectar e recuperar falhas: existem diversas técnicas para tornar a
recuperação de falhas mais simples:
• Transacções atómicas: colecção de operações indivisíveis,
isto é, tudo acontece ou nada acontece
• Servidores stateless: servidor não armazena informações
históricas sobre as operações dos clientes
• Acknowledgements e retransmissões baseadas em timeout:
o Detecção de perda de mensagens (timeout para
receber ack) e retransmissão; é necessário um
mecanismo de detecção e tratamento de mensagens
duplicadas
Página 4 de 6

5. 1.6. Disponibilidade
o Fracção de tempo no qual o sistema distribuído está disponível para ser
utilizado. Por exemplo:
4 Servidores – disponibilidade 95% cada
Probabilidade dos 4 estarem parados
• 0.054 = 0.000006
• Probabilidade de pelo menos 1 estar disponível 1 – (0.054)
= 0.999994
Exercício: 1 servidor – disponibilidade 75%. Quantos servidores
para disponibilidade de pelo menos 99%?
1.7. Concorrência
o Possibilidade de diversos clientes acederem simultaneamente um serviço
ou recurso em um SD.
o Serviços e aplicações aceitam diversos usuários por vez, e devem garantir
que os recursos compartilhados sejam operados correctamente no
ambiente concorrente.
o Sincronização de estruturas de dados e objectos
1.8. Desempenho
o O sistema deve ter maior desempenho do que se executado em uma única
máquina.
o Utilização de métricas de desempenho
o Benchmarks – são testes padronizados que são usados para medir a
performance de diferentes processadores em tipos específicos de
aplicação. Tipicamente, os benchmarks medem a performance em tarefas
como: produtividade, Internet, codificação de vídeo e edição de imagens,
jogos e processamento intensivo.
Página 5 de 6

6. 1.9. Transparência
Existem cinco tipos de transparência em sistemas distribuídos:
1. Transparência à localização – os usuários não devem saber onde os recursos se
encontram;
2. Transparência à replicação – os usuários não devem saber quantas cópias existem;
3. Transparência à concorrência – vários usuários podem compartilhar
automaticamente os recursos; e
4. Transparência ao paralelismo – podem ocorrer actividades paralelas sem que os
usuários venham a saber.
Página 6 de 6