Engenharia de software distribuído

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


– 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


• 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


– 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 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


– 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


• 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


13


14


15


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


17


• 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


20


• 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





24

• Mais simples forma da arquitetura cliente-servidor

• Um único servidor lógico

• Número indefinido de clientes


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


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


27



Arquitetura cliente-servidor de multicamadas




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


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


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


32




Arquitetura distribuída de componentes



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


35

Middleware de comunicação

Comp 1

Serviços

Comp 2

Serviços

Comp 3

Serviços

Cliente Cliente

Cliente Cliente


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


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


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


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


40





Arquitetura ponto-a-ponto


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


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


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


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

Documents

Engenharia de software distribuído