Clique aqui para baixar a versão em PDF

Transcrição

Sistemas Distribuídos
Arquitetura de Sistemas Distribuídos
Aula II
Prof. Rosemary Silveira F. Melo
Arquitetura de Sistemas Distribuídos
• Conceito de Arquitetura de Software
• Principais elementos arquiteturais
• Modelos Arquiteturais
• Evolução das Arquiteturas
• Estilos Arquiteturais
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.
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).
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.
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.
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).
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.
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
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.
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
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
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.
Desvantagens:
• Integração via Internet
– Problema que a maioria não foi projetada
para internet
• Integração entre sistemas 33-tiers
– falta de padronização
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
• Uso do Browser como Cliente Universal/Thin
Client
• A camada de aplicação se quebra em duas: Web
e Aplicação
• Evita
Evita--se instalar qualquer software no desktop e
portanto, problemas de manutenção.
• Pode
Pode--se chamar de 3 camadas porque às vezes
as camadas Web e Aplicação freqüentemente
rodam na mesma máquina (pequenos volumes)..
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
Desvantagens:
• Informação redundante
• Dificuldade e o custo de desenvolvimento e
manutenção.
• Cresce exponencialmente com o número de
camadas
• 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.
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
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áadaptá-las para o
contexto específico de uma aplicação em
particular.
• Estilos em Camada
• Estilos com Memória Compartilhada
• Estilos Baseados em Evento
• PeerPeer-to
to--Peer
•
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
Client--Server - duas camadas com conexões
em rede
• Estilos em Camada - Virtual Machine
•
Estilos em Camada – ClientClient-Server
– 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..
blackboard
Exemplo: conjunto de ferramentas CASE integrada
•
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.
•
– 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.
•
•
Peer-to
Peerto--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.
•
Peer-to
Peerto--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.
•
Peer-toPeerto-Peer (P2P)
– 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.
•
Peer--to
Peer
to--Peer (P2P)
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 ?
Arquiteturas de Sistemas
• Arquiteturas Centralizadas
– Cliente
Cliente--Servidor: terminais bancários
• Arquiteturas Descentralizada
– Peer
Peer--to
to--Peer (P2P): EE-Chords
• Arquiteturas Híbridas
– Peer
Peer--to
to--Peer (P2P): BitTorrent, PPLive
Arquiteturas Centralizadas
• Modelo ClienteCliente-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
•
•
•
•
•
•
Modelo ClienteCliente-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)?
● Considerando aplicações clientecliente-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
Com a distinção entre três níveis lógicos, como
distribuir fisicamente uma aplicação
cliente--servidor por várias máquinas?
cliente
– Arquitetura de duas divisões físicas
– Arquitetura de três divisões físicas
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.
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?

Clique aqui para baixar a versão em PDF

Transcrição

Documentos relacionados

arquitetura avançada de sistemas

prova f - joaoricardao

documento PDF

plano de curso - Faculdade de Arquitetura - UFBA

PNL 3D - Programação Neuro – Linguística a 3 dimensões

Texto - NUPEA - Núcleo de Pesquisa em Ensino de Arte

Estilos Parentais

Matéria para o jornal de junho / 2006

Baixar

Headline slide, text in two lines