Apresentação - Software distribuído - Livia e Artur

Prévia do material em texto

1 
Engenharia de software 
distribuído 
Artur Sampaio 
Lívia Castro Degrossi 
• O que é um sistema distribuído; 
• Questões sobre sistemas distribuídos; 
• Computação cliente-servidor; 
• Padrões de arquitetura para sistemas 
distribuídos; 
• Software como serviço. 
2 
Roteiro 
• “...uma coleção de computadores independentes que 
aparece para o usuário como um único sistema 
coerente” (Tanenbaum, 2007). 
 
• Um sistema distribuído é aquele no qual os 
componentes estão localizados em computadores 
interligados em rede se comunicam e coordenam 
suas ações apenas passando mensagens. 
 
3 
Introdução 
• Vantagens de um sistema distribuído: 
– Compartilhamento de recursos: permite o compartilhamento 
de recursos de hardware e software; 
– Abertura: permite que os equipamentos e softwares de diferentes 
fornecedores sejam combinados; 
– Concorrência: vários processos podem operar simultaneamente 
em computadores separados; 
– Escalabilidade: os sistemas distribuídos são escaláveis, ou 
seja, é possível que os recursos do sistema sejam aumentados; 
– Tolerância a defeitos: a disponibilidade de vários 
computadores e o potencial para replicar as informações significa 
que os sistemas distribuídos podem ser tolerantes com algumas 
falhas de hardware e software. 
4 
Introdução 
• São mais complexos do que os executados em um 
único processador. Essa complexidade surge porque é 
praticamente impossível ter um modelo de controle top-
down desses sistemas. 
 
• O desempenho de um sistema distribuído depende da 
largura da banda de rede, da carga de rede e da 
velocidade de todos os computadores que fazem parte 
do sistema. 
 
• O tempo de resposta depende da carga geral sobre o 
sistema, sua arquitetura e a carga de rede. 
5 
Questões sobre sistemas distribuídos 
• Questões de projeto: 
 
– Transparência: em que medida o sistema distribuído deve 
aparecer para o usuário como um único sistema? 
 
– Abertura: deve ser utilizado protocolo padrão ou protocolos 
mais especializados que restrinjam a liberdade do projetista? 
 
– Escalabilidade: como o sistema pode ser construído para 
que seja escalável? 
 
 
 6 
Questões sobre sistemas distribuídos 
– Proteção: como podem ser definidas e implementadas as 
políticas de proteção que se aplicam a um conjunto de sistemas 
gerenciados independentemente? 
 
– Qualidade de serviço: como a qualidade do serviço que é 
entregue aos usuários do sistema deve ser especificada e como 
o sistema deve ser implementado para oferecer essa qualidade 
a todos os usuários? 
 
– Gerenciamento de falhas: como as falhas do sistema 
podem ser detectadas, contidas (para que elas tenham efeitos 
mínimos em outros componentes do sistema) e reparadas? 
 
7 
Questões sobre sistemas distribuídos 
• A escalabilidade de um sistema reflete sua 
capacidade de oferecer um serviço de alta 
qualidade. 
• Propriedades: 
– Tamanho: deve ser possível adicionar mais 
recursos ao sistema. 
 
• Escalamento para cima: substituição de recursos; 
• Escalamento para fora: adicionar recursos ao 
sistema; 
8 
Questões sobre sistemas distribuídos 
– Distribuição: Deve ser possível dispersar 
geograficamente os componentes de um sistema 
sem comprometer seu desempenho; 
 
– Capacidade de gerenciamento: é possível 
gerenciar um sistema à medida que ele aumenta 
de tamanho, mesmo que partes dele estejam 
localizadas em organizações independentes. 
 
9 
Questões sobre sistemas distribuídos 
• Questões de proteção em sistemas 
distribuídos; 
 
• Tipos de ataques: 
 
– Intercepção: as comunicações entre as partes do 
sistema são interceptadas por um invasor de tal 
modo que haja uma perda de confiabilidade; 
 
– Interrupção: os serviços de sistema são atacados e 
não podem ser entregues conforme o esperado; 
10 
Questões sobre sistemas distribuídos 
– Modificação: os dados ou serviços no sistema são 
alterados por um invasor; 
 
– Fabricação: um invasor gera informações que não 
deveriam existir e, em seguida, usa-as para obter 
alguns privilégios; 
 
• A grande dificuldade em sistemas 
distribuídos é estabelecer uma política de 
proteção que possa ser fielmente aplicada a 
todos os componentes de um sistema. 
 
11 
Questões sobre sistemas distribuídos 
• Modelos de interação: 
 
– Interação procedural: envolve um computador 
que chama um serviço conhecido oferecido por 
algum outro computador e (normalmente) 
esperando que esse serviço seja fornecido. 
 
– Interação baseada em mensagens: envolve 
o computador ‘que envia’ que define as 
informações sobre o que é requerido em uma 
mensagem, que são, então, enviadas para outro 
computador. 
12 
Questões sobre sistemas distribuídos 
13 
Questões sobre sistemas distribuídos 
14 
Questões sobre sistemas distribuídos 
15 
Questões sobre sistemas distribuídos 
Middleware 
Componente 1 Componente 2 
• Um sistema distribuído requer um software que 
possa gerenciar as diversas partes pertencentes ao 
sistema e assegurar que elas podem se comunicar 
e trocar dados. 
 
• Middleware: o termo é usado para referir ao software 
que fica no meio entre os componentes distribuídos do 
sistema. 
 
• Exemplos de middleware: o software para gerenciamento de 
comunicações com bancos de dados, gerenciadores de transações, 
conversores de dados e controladores de comunicação. 
 
 
16 
Questões sobre sistemas distribuídos 
17 
Questões sobre sistemas distribuídos 
• Computação Cliente-servidor: 
 
– Uma aplicação é modelada como um conjunto de 
serviços que são fornecidos por servidores. Os 
clientes podem acessar esses serviços e apresentar 
os resultados para os usuários finais (Orfali e Harkey, 
1998). 
 
– Os clientes precisam estar cientes dos servidores 
que estão disponíveis, mas não devem saber da 
existência de outros clientes. 
 
18 
Computação cliente-servidor 
19 
Computação cliente-servidor 
20 
Computação cliente-servidor 
• Organizar projetos de sistema para ter 
equilíbrio entre desempenho, confiança, 
proteção e capacidade de gerenciamento. 
• Não existe modelo universal para todas as 
circunstâncias, então surgiram vários estilos 
• Escolher de acordo com o suporte aos 
requisitos não funcionais críticos 
Padrões de arquitetura para sistemas 
distribuídos 
21 
Arquitetura de mestre-escravo 
• Arquitetura cliente-servidor de 2 camadas 
• Arquitetura cliente-servidor de multicamadas 
• Arquitetura distribuída de componentes 
• Arquitetura ponto-a-ponto 
Estilos de arquitetura 
22 
• Sistemas de tempo real 
• Processadores separados 
– Aquisição de dados do ambiente 
– Processamento de dados 
– Gerenciamento de atuadores 
• Processo mestre: responsável pelo 
processamento, coordenação e comunicações 
• Processos escravos: dedicados a ações 
específicas, como aquisição de dados 
Arquitetura mestre-escravo 
23 
• Arquitetura de mestre-escravo 
Arquitetura cliente-servidor de 2 camadas 
• Arquitetura cliente-servidor de multicamadas 
• Arquitetura distribuída de componentes 
• Arquitetura ponto-a-ponto 
Estilos de arquitetura 
24 
• Mais simples forma da arquitetura cliente-
servidor 
• Um único servidor lógico 
• Número indefinido de clientes 
 
Arquitetura cliente-servidor de 2 
camadas 
25 
• Cliente magro 
– Cliente: só apresentação de dados 
– Servidor: todas as outras camadas (gerenciamento 
de dados, processamento de aplicação e banco de 
dados) 
– Web browser ou para apresentar os dados 
• Vantagem: simplicidade em gerenciar clientes 
• Desvantagem: tráfego de rede e peso 
computacional 
Arquitetura cliente-servidor de 2 
camadas 
26 
• Cliente gordo 
– Cliente: realiza parte ou todo o processamento 
– Servidor: bancos de dados e gerenciamento 
• Vantagem: distribui peso computacional 
– Processamento nos clientes 
– Servidor gerencia transações do banco de dados 
• Desvantagem: gerenciamento de clientes 
Arquiteturacliente-servidor de 2 
camadas 
27 
• Arquitetura de mestre-escravo 
• Arquitetura cliente-servidor de 2 camadas 
Arquitetura cliente-servidor de multicamadas 
• Arquitetura distribuída de componentes 
• Arquitetura ponto-a-ponto 
Estilos de arquitetura 
28 
• Dificuldade das 2 camadas: 
 
 
 
 
 
• Cliente magro: problemas de escalabilidade e 
desempenho 
• Cliente gordo: problemas de gerenciamento 
 
Apresentação 
 
Processamento de app 
 
Gerenciamento de dados 
Cliente 
 
Servidor 
Arquiteturas cliente-servidor 
multicamadas 
29 
• Diferentes camadas do sistema executados em 
diferentes processadores 
– Apresentação 
– Gerenciamento de dados 
– Processamento de aplicação 
– Banco de dados 
Arquiteturas cliente-servidor 
multicamadas 
30 
• Internet Banking – exemplo de 3 camadas 
– Banco de dados, geralmente em mainframe 
– Servidor web, gerenciamento de dados e serviços 
de aplicação (transferir dinheiro, gerar extratos, 
pagar contas, etc) 
– Computador do usuário + web browser = cliente 
• Escalável, pois é fácil adicionar clientes 
• Comunicação otimizada entre servidor web e 
banco de dados 
 
Arquiteturas cliente-servidor 
multicamadas 
31 
• Multicamadas 
• Servidores adicionais 
– Servidor web gerenciando dados 
– Servidores separados para processamento de 
aplicação e banco de dados 
• Diferentes bancos de dados 
– Servidor de integração: coleta dados distribuídos e 
apresenta ao servidor de aplicação 
Arquiteturas cliente-servidor 
multicamadas 
32 
• Arquitetura de mestre-escravo 
• Arquitetura cliente-servidor de 2 camadas 
• Arquitetura cliente-servidor de multicamadas 
Arquitetura distribuída de componentes 
• Arquitetura ponto-a-ponto 
Estilos de arquitetura 
33 
• Organização de sistemas em camadas exige: 
 
• Decidir quais serviços em quais camadas 
• Decidir se um serviço é de gerenciamento de 
dados, de aplicação ou de banco de dados 
• Planejar escalabilidade, através da replicação 
de servidores 
Arquiteturas de 
componentes distribuídos 
34 
• Projetar o sistema como um conjunto de 
serviços 
• Implementar cada serviço ou grupo de 
serviços como um componente separado 
• Todos os componentes oferecem interface 
para os serviços 
• Outros componentes usam os serviços, 
através do middleware 
 
Arquiteturas de 
componentes distribuídos 
35 
 
Middleware de comunicação 
Comp 1 
 
Serviços 
Comp 2 
 
Serviços 
Comp 3 
 
Serviços 
Cliente 
Cliente 
Cliente 
Cliente 
Arquiteturas de 
componentes distribuídos 
36 
• Dependentes do middleware 
– Gerencia interações de componentes 
– Reconcilia diferenças entre parâmetros 
– Fornece conjunto de serviços comuns 
 
• Exemplos de middleware 
– CORBA – foi um dos primeiros 
– EJB ou .NET – tem ganhado espaço 
Arquiteturas de 
componentes distribuídos 
37 
• Mineração de dados 
– Extrai informações vindas de vários bancos 
separados 
– Processamento computacional intensivo 
– Exibição de dados em gráficos 
 
• Procura relacionamentos entre os dados de 
uma série de bancos de dados 
Arquiteturas de 
componentes distribuídos 
38 
• Benefícios: 
• Flexibilidade sobre onde e como os serviços 
serão prestados 
• Adição de novos recursos conforme 
necessário 
• Escalável – novos componentes podem ser 
adicionados sob demanda 
• Reconfigurar o sistema dinamicamente 
Arquiteturas de 
componentes distribuídos 
39 
• Desvantagens: 
– Complexas para projetar. Não intuitivas. 
– Middleware não padronizado. Diferentes 
fabricantes disputam com produtos diferentes e 
incompatíveis. 
• Arquiteturas orientadas a serviços tem sido 
mais adotadas, mas as de componentes 
distribuídos tem melhor desempenho 
Arquiteturas de 
componentes distribuídos 
40 
• Arquitetura de mestre-escravo 
• Arquitetura cliente-servidor de 2 camadas 
• Arquitetura cliente-servidor de multicamadas 
• Arquitetura distribuída de componentes 
Arquitetura ponto-a-ponto 
Estilos de arquitetura 
41 
• P2P 
• Descentralizados 
• Processamento realizado por qualquer nó da 
rede 
• Sem distinções entre clientes e servidores 
• Utiliza todo o poder computacional e 
armazenamento de uma rede grande 
• Cada nó executa uma cópia da aplicação 
Arquiteturas ponto a ponto 
42 
• Usadas principalmente em sistemas pessoais 
– Gnutella e BitTorrent – troca de arquivos 
– ICQ e Jabber – comunicação direta 
– SETI@Home – processamento doméstico de 
radiotelescópios 
• Uso em empresas 
– Intel e Boeing usam sistemas P2P para aproveitar 
processamento de micros ociosos 
– VOIP 
Arquiteturas ponto a ponto 
43 
• Adequado quando: 
• Computacionalmente intensivo e é possível 
separar o processamento em partes 
independentes 
• Envolver troca de informações entre 
computadores individuais sem 
armazenamento ou gerenciamento central 
Arquiteturas ponto a ponto 
44 
• Vantagens: 
– Altamente redundante 
– Tolerante a defeitos e desconexão de nós 
• Desvantagens: 
– Muitos nós diferentes podem processar a mesma 
pesquisa 
– Overhead em comunicações de pontos replicados 
Arquiteturas ponto a ponto 
45 
• Cliente-servidor 
– Instalar programa no computador cliente 
– Reduzir processamento no servidor (problema de 
cliente-magro) 
• Browser moderno 
– Gerenciamento de apresentação 
– Computação local por meio de scripts 
– Software se torna um serviço, para qualquer 
dispositivo com browser 
SaaS 
46 
• Hospedagem remota do software 
– Um ou mais servidores 
– Acessado através de browser 
• Propriedade e gerenciamento do fornecedor, 
não do cliente 
• Cobrança por assinatura mensal, anual ou 
quantidade de uso 
SaaS 
47 
• Vantagens: 
– Provedor responsável por manutenção do 
sistema, capacidade de hardware, licenças, etc 
– Ocasionalmente, pagar pelo uso é mais barato do 
que comprar licença 
• Desvantagens: 
– Transferência de dados 
– Falta de controle sobre a evolução do sistema 
– Problemas legais 
SaaS 
48 
• SaaS não é SOA: 
 
• SaaS fornece funcionalidades em um servidor 
por meio de browser. Servidor mantém dados 
e estado do usuário 
• SOA estrutura sistema como um conjunto de 
serviços separados, sem estado. Transações 
curtas, de chamada e resposta 
SaaS 
49 
 
• SaaS é uma maneira de entregar a 
funcionalidade de aplicação para os usuários 
 
• SOA é uma tecnologia de implementação para 
sistemas de aplicações 
SaaS 
50 
• Se SaaS é implementado usando SOA, 
aplicações podem usar suas API´s de serviços 
em outras aplicações 
• Essas aplicações podem ser integradas em 
sistemas mais complexos. 
• Mashups representam outra abordagem para 
reuso de software e desenvolvimento rápido 
de software 
SaaS 
51 
• Para construir uma aplicação SaaS, deve-se 
considerar usuários de várias organizações 
• 3 fatores devem ser considerados: 
– Configurabilidade: configurar o software para cada 
organização 
– Multilocação: causar a impressão de que cada 
usuário tem sua cópia do sistema 
– Escalabilidade: projetar o sistema para acomodar 
um número imprevisível de usuários 
SaaS 
52