- PDF Download grátis

Transcrição

1 Sistemas Distribuídos Arquitetura de Sistemas Distribuídos Aula II Prof. Rosemary Silveira F. Melo

2 Arquitetura de Sistemas Distribuídos Conceito de Arquitetura de Software Principais elementos arquiteturais Modelos Arquiteturais Evolução das Arquiteturas Estilos Arquiteturais

3 Conceito de Arquitetura de Software é a estrutura de um sistema, que consiste de componentes de software, das propriedades externamente visíveis desses componentes e dos relacionamentos entre eles. é a estrutura ou organização dos mais significativos componentes do sistema e suas interações.

4 Principais elementos arquiteturais Componentes é uma unidade modular com interfaces requeridas e fornecidas bem definidas que é substituível dentro do seu ambiente. são elementos de uma arquitetura que geralmente implementam: processamento (funcionalidade ou comportamento); estado (informação ou dados); interação ( interconexão, comunicação, coordenação e mediação).

5 Principais elementos arquiteturais Componentes pode ser uma simples operação ou complexo como um sistema inteiro. Pode ser visto pelo usuário (humano ou outro software) somente através da sua interface pública.

6 Principais elementos arquiteturais Conectores tipo de componente responsável pela interação entre componentes. em sistemas desktop convencionais os conectores são geralmente representados por simples chamadas de procedimento (procedure call) ou acesso a dados compartilhados. em sistemas complexos eles passam a ter identidades, papéis e artefatos de implementação único.

7 Modelos arquiteturais Define a forma pela qual os componentes dos sistemas interagem e a maneira pela qual eles são mapeados em uma rede de computadores subjacente (Coulouris, 2005).

8 Evolução das arquiteturas

9 Evolução das arquiteturas Arquiteturas 1 camada (Mainframes) Dominantes até década de 80 como arquitetura corporativa Terminais burros somente para apresentar as informações.

10 Evolução das arquiteturas Arquiteturas 1 camada (Mainframes) Desvantagens: Manutenção difícil e cara, proporcional a sua eficiência. Problemas de congestionamento na entrada do servidor devido a chegada de pedidos Congestionamento no tratamento da informação (sistema central responsável por tudo, até pela interface) Problema básico: interface não amigável

12 Evolução das arquiteturas Arquitetura Cliente/Servidor Vantagens: Camada de apresentação no Cliente utiliza processamento local (aproveita PCs da empresa). Oferecer sistemas com interfaces gráficas amigáveis Integrar o desktop e os dados corporativos.

13 Evolução das arquiteturas Arquitetura Cliente/Servidor Desvantagens: Escalabilidade limitada Enormes problemas de manutenção (mudanças na lógica de aplicação forçava instalações) Cada cliente uma conexão com o SGBD

15 Evolução das arquiteturas Arquitetura 3 Camadas A arquitetura cliente/servidor em 2 camadas sofria de vários problemas: Falta de escalabilidade (conexões a bancos de dados) Enormes problemas de manutenção (mudanças na lógica de aplicação forçava instalações) Dificuldade de acessar fontes heterogêneas

16 Evolução das arquiteturas Arquitetura 3 Camadas Vantagens: Perda de performance é compensada com ganho de flexibilidade. Aumento da escalabilidade e confiabilidade do sistema. Problemas de manutenção foram reduzidos, pois mudanças nas camadas de aplicação e de dados não necessitam de novas instalacões no desktop.

17 Evolução das arquiteturas Arquitetura 3 Camadas Desvantagens: Integração via Internet Problema que a maioria não foi projetada para internet Integração entre sistemas 3-tiers falta de padronização

20 Evolução das arquiteturas Arquitetura n-camadas A arquitetura em 3 camadas original sofre de problemas: A instalação inicial dos programas no desktop é cara. O problema de manutenção ainda persiste quando há mudanças na camada de apresentação. Não se pode instalar software facilmente num desktop que não está sob seu controle administrativo

21 Evolução das arquiteturas Arquitetura n-camadas Uso do Browser como Cliente Universal/Thin Client A camada de aplicação se quebra em duas: Web e Aplicação Evita-se instalar qualquer software no desktop e portanto, problemas de manutenção. Pode-se chamar de 3 camadas porque às vezes as camadas Web e Aplicação freqüentemente rodam na mesma máquina (pequenos volumes)..

22 Evolução das arquiteturas Arquitetura n-camadas Desvantagens: Complexidade Fazer aplicações distribuídas multicamadas é difícil. Tem que: Implementar tolerância a falhas Implementar gerência de transações distribuídas Implementar balanceamento de carga Implementar resource pooling Muito middleware envolvido

23 Evolução das arquiteturas Arquitetura n-camadas Desvantagens: Informação redundante Dificuldade e o custo de desenvolvimento e manutenção. Cresce exponencialmente com o número de camadas

24 Evolução das arquiteturas O truque é introduzir middleware num servidor de aplicação que ofereça esses serviços automaticamente. Além do mais, as soluções oferecidas (J2EE,. Net) são baseadas em componentes.

25 Por quê definir uma arquitetura para Sistemas Distribuídos? Sistemas distribuídos são complexas peças de software. Componentes estão espalhados por diversas máquinas. Sistemas devem ser organizados adequadamente: organização lógica do conjunto de componentes e organização física

26 Estilos arquiteturais Estilos arquiteturais definem decisões gerais de projeto que impõem restrições e que podem precisar ser detalhadas em decisões mais específicas para o sistema em questão. Não são definidos detalhes acerca de componentes utilizados, suas interfaces e seus mecanismos de interação. O arquiteto deve detalhar estas decisões e adaptá-las para o contexto específico de uma aplicação em particular.

27 Estilos em Camada Estilos arquiteturais Estilos com Memória Compartilhada Estilos Baseados em Evento Peer-to to-peer

28 Estilos arquiteturais Estilos em Camada a arquitetura é separada em camadas ordenadas, onde um programa de uma camada pode solicitar serviços de uma camada inferior. Virtual Machines várias camadas Client-Server - duas camadas com conexões em rede

29 Estilos arquiteturais Estilos em Camada - Virtual Machine

30 Estilos arquiteturais Estilos em Camada Client-Server

31 Estilos arquiteturais Estilos com Memória Compartilhada caracterizado pela presença de múltiplos componentes que acessam o mesmo repositório de dados e se comunicam através deste repositório. - programas independentes acessam e se comunicam exclusivamente através de um repositório global, conhecido como blackboard.

32 Estilos arquiteturais Estilos com Memória Compartilhada Exemplo: conjunto de ferramentas CASE integrada

33 Estilos arquiteturais Estilos com Memória Compartilhada

34 Estilos arquiteturais Estilos Baseados em Evento caracterizados por componentes independentes que se comunicam somente através de eventos transmitidos por um barramento (conector). altamente indicado para sistemas com componentes concorrentes altamente desacoplados onde, em um determinado momento, um componente pode estar ou criando ou consumindo informação.

35 Estilos arquiteturais Estilos Baseados em Evento Nesta arquitetura, processos demonstram o interesse por um evento ou conjunto de eventos (processo se subscreve) e esperam pela notificação de qualquer um desses eventos, gerados por um processo notificador. O produtor publica uma informação em um gerenciador de eventos (middleware) e os consumidores se subscresvem para receber as informações deste gerenciador. Eventos e notificações.

36 Estilos arquiteturais Estilos Baseados em Evento

37 Estilos arquiteturais Peer-to-Peer (P2P) consiste em uma rede de peers autônomos fracamente acoplados. cada peer atua como um cliente e como um servidor. peers se comunicam utilizando protocolo de rede (ex.: napster, gnutella, emule, PPLive) descentraliza tanto a informação quanto o controle, fazendo com que a descoberta de recursos seja um aspecto importante.

38 Estilos arquiteturais Peer-to-Peer (P2P) na descoberta de recursos em sistemas P2P puro: a solicitação é lançada na rede como um todo a requisição se propaga até que a informação seja descoberta se a informação é encontrada o peer obtém o endereço direto do outro peer e contacta diretamente.

39 Peer-to-Peer (P2P) Estilos arquiteturais na descoberta de recursos em sistemas P2P híbrido: processo é otimizado por a presença de peers especiais, especializados na localização de outros peers ou disponibilização de diretórios que localizam as informações. Ex.: napster (utiliza um servidor central para indexação das músicas e localização de outros peers). estilo popular nas aplicações de compartilhamento de arquivos, utilizado também B2B commerce, chat, redes de sensores.

40 Estilos arquiteturais Peer-to-Peer (P2P)

41 Arquiteturas de Sistemas Como diversos sistemas distribuídos são realmente organizados? Onde são colocados os componentes de software? Onde é estabelecida a interação entre as peças de software?

42 Arquiteturas de Sistemas Arquiteturas Centralizadas Cliente-Servidor: terminais bancários Arquiteturas Descentralizada Peer-to-Peer (P2P): E-Chords Arquiteturas Híbridas Peer-to-Peer (P2P): BitTorrent, PPLive

43 Arquiteturas Centralizadas Modelo Cliente-Servidor processos são divididos em dois grupos Servidor: processo que implementa um serviço específico Cliente: processo que requisita um serviço ao servidor Requisição -> Resposta

44 Arquiteturas Centralizadas

46 Arquiteturas Centralizadas Modelo Cliente-Servidor: questões, questões!! Clientes e Servidores multithreads? Comunicação??? Qual o tipo de aplicação? Sem conexão, não confiável (UDP)? Com conexão, confiável (TCP)?

47 Arquiteturas Centralizadas Considerando aplicações cliente-servidor que visam dar suporte ao acesso de usuários a banco de dados: Nível de interface Nível de processamento Nível de dados

49 Arquiteturas Centralizadas Com a distinção entre três níveis lógicos, como distribuir fisicamente uma aplicação cliente-servidor por várias máquinas? Arquitetura de duas divisões físicas Arquitetura de três divisões físicas

56 Arquiteturas Descentralizadas Clientes e servidores são fisicamente subdivididos em partes logicamente equivalentes, mas cada parte está operando em sua própria porção do conjunto completo de dados, o que equilibra a carga!!!! Interação entre os processos é simétrica: cada processo agirá como um cliente e um servidor ao mesmo tempo.

57 Arquiteturas Descentralizadas Sistemas P2P questões, questões, questões!! Como organizar os peers em uma rede de sobreposição? Como difundir o conteúdo? Como incentivar os peers a colaborarem?

58 Arquiteturas Descentralizadas