Aula 3 2 - Estilos Arquitetônicos

Prévia do material em texto

Arquiteturas
CURSO DE CIÊNCIA DA COMPUTAÇÃO
DISCIPLINA DE SISTEMAS DISTRIBUÍDOS
PROF. MESSIAS R. BATISTA
Estilos 
Arquitetônicos
2
Introdução
▫ Como é organizado um sistema 
distribuído?
▪ Distinguir organização lógica dos 
componentes de software;
▪ Realização física;
▫ Sistemas distribuídos
▪ Componentes de software
▫ Arquitetura de software
3
Introdução
▫ Arquitetura de software (ou 
de sistema)
▪ Arquiteturas centralizadas
▪ Arquiteturas 
descentralizadas
4
▫ Arquiteturas centralizadas
Tradicionais. Um único servidor implementa a 
maioria dos componentes;
▫ Arquiteturas descentralizadas
As máquina desempenham papéis mais ou 
menos iguais, bem como organizações híbridas.
“
[...] uma meta importante de 
sistemas distribuídos é 
separar aplicações das 
plataformas subjacentes 
provendo uma camada de 
middleware.
5
6
Middleware
▫ É necessário conseguir um
middleware adaptativo;
▫ Sistemas distribuídos devem
monitorar seu funcionamento
▪ Sistemas autonômicos
7
Estilos 
Arquitetônicos
8
9
O quanto é crucial adotar uma 
arquitetura de
software para um projeto?
Estilo 
Arquitetônico
10
▫ Formulado com base nos componentes que o
compõe;
▫ A forma de conexão dos componentes
também é importante;
▫ Os dados trocados entre os componentes;
▫ A forma de configuração desse conjunto de
elementos;
Composição do 
Sistema 
Distribuído com 
base no estilo 
arquitetônico
“
Um componente é uma 
unidade modular com 
interfaces requeridas e 
fornecidas bem definidas que 
é substituível dentro de seu 
ambiente
11
Componente
12
▫ É passível de substituição;
▫ Necessário respeitar as interfaces;
E os conectores?
“
Conector [...] é descrito como 
um mecanismo que serve de 
mediador da comunicação ou 
da cooperação entre 
componentes
13
Componentes e 
Conectores
14
Importantes 
Estilos 
Arquitetônicos
15
1. Arquiteturas em camadas;
2. Arquiteturas baseadas em objetos;
3. Arquiteturas centradas em dados;
4. Arquiteturas baseadas em eventos;
Configurações a 
partir de 
Componentes e 
Conectores
Arquiteturas 
em camadas
16
▫ Componentes são organizados em camadas;
▫ O componente da camada Li pode chamar 
um componente subjacente Li-1;
▫ Modelo amplamente adotado pela 
comunidade de redes;
▫ Requisições descem pela hierarquia;
▫ Resultados (respostas) fluem para cima;
Arquiteturas 
em camadas
17
Arquiteturas 
em camadas
18
Arquitetura 
baseada em 
objetos
19
▫ Cada objeto corresponde a definição de um 
componente;
▫ Os componentes são conectados por uma 
chamada de procedimento remoto;
▫ É um modelo de arquitetura que se ajusta ao 
sistema cliente-servidor;
▫ Configuram-se em um estilo importante para 
sistemas de software de grande porte.
Arquitetura 
baseada em 
objetos
20
Arquitetura 
centrada em 
dados
21
▫ Processos se comunicam por meio de um
repositório comum;
▫ Tem grau de importância similar as baseadas em
camadas e objetos;
▫ Funcionamento:
Trabalha com o compartilhamento de arquivos.
Arquitetura 
centrada em 
dados
22
Arquitetura 
baseada em 
eventos
23
▫ Processos se comunicam por meio da propagação 
de eventos;
▫ Podem também transportar dados;
▫ Associa-se a sistemas publica/subscrever;
▫ Processos fracamente acoplados;
▪ Podem ser desacoplados;
▪ Ou, referencialmente desacoplados.
“
A ideia básica é que processos 
publiquem eventos após os 
quais o middleware assegura 
que somente os processos 
que se subscreveram para 
esses eventos os receberão.
24
Arquitetura 
baseada em 
eventos
25
Arquiteturas baseadas em eventos, podem se 
complementar com arquiteturas baseadas em dados
Espaços compartilhados
de Dados
▫ Os processos são desacoplados no 
tempo;
▪ Não precisa que ambos estejam 
ativos para haver comunicação;
▫ Utilizam interfaces semelhantes à SQL;
▪ Os dados são acessados por 
descrição;
▫ Não precisam ser acessados 
por referência explícita.
26
“
O que torna essas arquitetura 
de software importantes para 
sistemas distribuídos é que 
todas elas visam obter 
transparência de distribuição, 
em um nível razoável.
27
Arquiteturas de 
Sistemas
Arquiteturas
28
“
Decidir a respeito de 
componentes de software, sua 
interação e sua colocação leva a 
um exemplo de uma 
arquitetura de software 
também denominada 
arquitetura de sistema.
29
Arquiteturas 
Centralizadas
Arquiteturas
Arquiteturas de Sistemas
30
“
[...] pensar em termos de 
clientes que requisitam 
serviços de servidores nos 
ajuda a entender e gerenciar 
a complexidade de sistemas 
distribuídos [...]
31
Servidor e 
Cliente
32
▫ Servidor
▪ É um processo que implementa um
serviço específico;
▫ Cliente
▪ É um processo que requisita um serviço
de um servidor enviando-lhe uma
requisição e, na sequência, esperando
pela resposta do servidor.
Comportamento
Comportamento de 
requisição-resposta
33
34
Fases da 
Requisição-
Resposta
35
1. Um cliente requisita um serviço;
▪ Empacota uma mensagem para o
servidor identificando o serviço que quer,
junto com os dados necessários.
2. O servidor sempre vai esperar a chegada de
uma requisição;
▪ Processará e empacotará os resultados
em uma mensagem de resposta que é
enviado ao cliente;
Cuidados!
36
▫ Protocolos que não exigem conexão são mais
eficientes;
▪ Eficiência: Faz a tarefa designa da maneira
menos custosa;
▫ Problema:
▪ as mensagens não podem se perder ou serem
corrompidas;
▫ Dificuldade:
▪ desenvolver um protocolo que seja resistente
a ocasionais falhas de transmissão.
37
E se o cliente não receber a 
mensagem de resposta o 
que fazer neste caso?
Analisando...
38
Transfira $10.000 de 
minha conta
Reenviar a 
resposta
Analisando...
39
Informe quanto dinheiro 
ainda tenho.
Reenviar a 
resposta
Soluções?
40
▫ Operações que podem ser repetidas várias vezes
sem causar dano são chamadas de idempotente;
▫ Não existe soluções únicas para tratamento de
mensagens perdida;
▫ Alternativa é a utilização de protocolos confiáveis
orientados a conexão;
▫ Garantindo que sempre que um cliente requisitou
um serviços, antes ele estabeleceu uma conexão
com o servidor e só em seguida enviou a
requisição.
Não há!
Camadas de Aplicação
41
Camadas de 
Aplicação
42
▫ Como estabelecer uma distinção clara entre
um cliente um servidor?
▪ Um servidor para um banco de dados
distribuídos pode agir continuamente como
um cliente porque está repassando
requisições para diferentes servidores de
arquivos responsáveis pela implementação
das tabelas do banco de dados.
▪ Processa consultas;
Abordagem 1
Camadas de 
Aplicação
43
É possível analisar criando uma distinção 
entre três níveis, seguindo o estilo 
arquitetônico em camadas.
1. Nível de interface de usuário
2. Nível de processamento
3. Nível de dados
Abordagem 1
Camadas
1. Nível de interface de usuário
2. Nível de processamento
3. Nível de dados
44
45
“
O nível de interface de 
usuário conteúdo que é 
necessário para fazer 
interface diretamente com o 
usuário como gerenciamento 
de exibição.
46
“
O nível de processamento
normalmente contem as 
aplicações.
47
“
O nível de dados gerencia os 
dados propriamente ditos 
sobre os quais está sendo 
executada alguma ação.
48
Conclusão
1. Manipula a interação com o
usuário;
2. Intermediária. Mantém a
funcionalidade central da
aplicação;
3. Age sobre o banco de dados
ou sistema de arquivos;
49
50
Palavras-
chave
Busca no 
banco de 
Dados
51
Nível de Dados
52
▫ Os dados costumam ser persistentes, e isso é
uma propriedade importante desse nível;
▫ Quando não aplicações utilizando esse nível, os
dados continuam armazenados aguardando a
próxima utilização;
▫ “O nível de dados consiste em um sistema de
arquivo, porém é mais comum utilizar um banco
de dados plenamente capacitado”;
▫ É implementado no lado do servidor;
Importante!
Nível de Dados
53
▫ É responsável por manter a consistência dos
dados em diferentes aplicações;
▫ Podeutilizar recursos como triggers para
manipular disparos de informação;
▫ Ambientes orientados a negócios utilizam bancos
de dados relacionais;
▫ A organização dos dados é independente das
aplicações;
Importante!
Nível de Dados
54
“[...] nem sempre bancos de dados relacionais
são a opção ideal. Um aspecto característico de
muitas aplicações é que elas operam sobre
tipos de dados complexos cuja modelagem é
mais fácil em termos de objetos do que em
termos de relações”
Conhecem o termo
Persistência Poliglota?
Importante!
(Detalhe)
55
56
Arquiteturas Multidivididas
57
“
A distinção entre três níveis 
lógicos [...], sugere várias 
possibilidades para a 
distribuição física de uma 
aplicação cliente-servidor por 
várias máquinas.
58
Cliente-
Servidor
59
▫ Máquina cliente
▪ Contém apenas os programas que
implementam o nível (parte do nível) de
interface de usuário.
▫ Máquina do servidor
▪ Contém o resto, ou seja, os programas
que implementam o nível de
processamento e de dados.
De fato, o que 
temos?
“
Nessa organização, tudo é 
manipulado pelo servidor, ao 
passo que, em essência, o 
cliente nada mais é do que um 
terminal burro, possivelmente 
com uma interface gráfica 
bonitinha.
60
61
62
Consideramos o fato de 
que o servidor pode ser 
um cliente também?
É possível? Exemplifique.
63
“
Clientes gordos
X
Clientes Magros
64
Distribuição 
vertical
65
“[...] da perspectiva e gerenciamento de
sistema, ter uma distribuição vertical pode
ajudar: funções são subdivididas lógica e
fisicamente por várias máquinas, e cada
máquina é projetada para um grupo específico
de funções”
Arquiteturas 
Descentralizadas
Arquiteturas
Arquiteturas de Sistemas
66
Distribuição 
horizontal
67
“Em arquiteturas modernas, muitas vezes é a
distribuição dos clientes dos servidores que conta à
qual nos referimos como distribuição horizontal”
▫ O cliente ou o servidor podem ser subdivididos
fisicamente em partes logicamente equivalentes;
▪ Cada parte opera em sua própria porção do
conjunto;
▪ Busca-se o equilíbrio da carga;
▫ Exemplo: peer-to-peer
Peer-to-peer
68
“De uma perspectiva de alto nível, os processos
que constituem um sistemas peer-to-peer são
todos iguais, o que significa que as funções que
precisam ser realizadas são representadas por
todo processo que constitui o sistema
distribuído”
Peer-to-peer
69
▫ Organizam os processos por meio de uma
tabela de hash distribuída (Distributed Hash
Table – DHT);
▫ DHT implementa um mapeamento de chave
do item para um nó baseando por distâncias
métricas;
Redes 
Estruturadas
Sistema Chord
70
Peer-to-peer
Redes 
Estruturadas
71
Peer-to-peer
72
▫ Dependem de algoritmos aleatórios para
construir uma rede de sobreposição;
▫ Cada nó mantém uma lista de vizinhos, que
é construída de modo aleatório;
▫ Admite-se que itens de dados sejam
colocados aleatoriamente em nós;
▫ A busca de um item de dado na rede é
realizada por uma consulta em toda a rede;
Redes Não-
Estruturadas
Peer-to-peer
73
▫ O grande foco desta arquitetura é o
gerenciamento de associação ao grupo;
▫ Sua estrutura é similar a um gráfico
aleatório;
▫ Cada nó mantém um lista de vizinhos, nós
vivos;
▫ A lista de vizinhos é denominada visão
parcial;
Redes Não-
Estruturadas
Peer-to-peer
74
▫ A construção de uma nova visão:
▪ Os nós descartam as entradas criadas
entre eles;
▪ Ou, os nós descartam o maior número
possível de entradas velhas;
Redes Não-
Estruturadas
“
[...] quando um nó quer se 
juntar ao grupo, ele contata 
um outro nó arbitrário, 
possivelmente de uma lista 
de pontos de acesso bem 
conhecidos.
75
Problema!
76
Gargalo criado em 
apenas um nó!
Gerenciamento de 
Topologia de Redes de 
Sobreposição
77
“
Embora possa parecer que 
sistemas peer-to-peer
estruturados e não 
estruturados formem classes 
estritamente independentes, na 
verdade pode não ser esse o 
caso.
78
79
Superpares (superpeers)
80
Superpares
81
▫ P2P não estruturados podem se tornar 
problemáticos à medida que crescem;
▫ Problema de escalabilidade:
▪ Não roteamento da requisição de pesquisa até 
um item de dado específico;
▪ Única técnica é enviar a pesquisa para toda a 
rede;
▫ Solução (possível):
▪ Nós intermediários, ou superpares;
Superpares
82
▫ Superpares:
▪ São organizados em redes P2P;
▪ Resultam em organização hierárquica;
▫ Todo par comum estará conectado como um 
cliente a um superpar;
▫ A relação cliente-superpar é fixa;
▪ Sempre que um cliente se junta à rede, ele se 
liga a um dos superpares e continua até sair 
da rede;
83
Arquiteturas 
Híbridas
Arquiteturas
Arquiteturas de Sistemas
84
“
[...] soluções cliente-
servidor são combinadas 
com arquiteturas 
descentralizadas.
85
Sistemas de servidor de 
borda
86
Sistemas de 
Servidor de 
Borda
87
▫ São sistemas disponibilizados na internet onde 
servidores são colocados “na borda” da rede;
▫ Usuários finais, ou clientes em geral, se conectam 
com a Internet por meio de um servidor de borda;
▫ Sua finalidade é servir conteúdo;
▫ Um conjunto de servidores de borda podem ser 
usados para otimizar distribuição de conteúdo e 
de aplicação;
88
Sistemas Distribuídos 
Colaborativos
89
“
Estruturas híbridas são 
disponibilizadas notavelmente em 
sistemas distribuídos colaborativos. 
A questão principal em muitos 
desses sistemas é conseguir dar a 
partida, para o que muitas vezes é 
disponibilizado um esquema cliente-
servidor tradicional.
90
BitTorrent
91
▫ Quando um usuário final estiver procurando um
arquivo, ele também possa transferir porções
para outros usuários;
▫ Assim, cria-se um conjunto de porções sendo
transferidas;
▫ A importância do projeto está na colaboração;
▫ Problema: quando existe grande quantidade de
usuários objetivando apenas obter os arquivos;
▫ Portanto, “um arquivo só pode ser transferido
quando o cliente que está transferindo estiver
fornecendo conteúdo a mais alguém”;
92
Arquiteturas 
versus
Middleware
Arquiteturas
93
94
Falamos sobre 
middelware?
Onde eles se encaixam?
“
[...] o middleware forma uma 
camada entre aplicações e 
plataformas distribuídas
95
Lembrando
Middleware
96
▫ Finalidade: proporcionar um grau de
transparência de distribuição;
▫ Seguem um estilo arquitetônico específico;
▫ A especificidade do estilo arquitetônico é para
simplificar projetos de aplicações;
▫ Apesar de sua finalidade, considera-se tê-lo para
ser mais adaptável as requisições de aplicação;
Middleware
97
“Uma abordagem geral considera
melhor é fazer sistemas de middleware
de modo que sejam simples de
configurar, adaptar e personalizar
conforme necessário para uma
aplicação.”
Interceptadores
98
Interceptador
99
▫ É um constructo de software que interromperá o
fluxo de controle usual e permitirá que seja
executado um outro código;
▫ Funciona com alto suporte em sistemas
distribuídos orientado à objetos;
▫ Um objeto A pode chamar um método que
pertence a um objeto B enquanto este residir em
uma máquina diferente de A.
Interceptador
100
A invocação remoto é realizada em três etapas:
1. É oferecida ao objeto A uma interface local que é
exatamente a mesma oferecida pelo objeto B. A
simplesmente chama o método disponível naquela
interface;
2. A chamada por A é transformada em uma invocação a
objeto genérico, possibilitada por meio de uma
interface geral de invocação de objeto oferecida pelo
middelware na máquina em que A reside;
3. Por fim, a invocação a objeto genérico é transformada
em uma mensagem que é enviada por meio de uma
interface de rede de nível de transporte como oferecida
pelo sistema operacional local de A.
101
Abordagens gerais para o 
software adaptativo
102
Software 
Adaptativo
103
▫ Interceptadores oferecem um meio de adaptar o
middleware;
▫ A necessidade de adaptação surge do ambiente
das aplicações distribuídos, que estão sempre
mudando;
▪ O middleware retira da aplicação a reação a
mudanças;
▫ Projetistasde middleware passam a considerar a
construção de software adaptativo;
Abordagens gerais
104
E como podemos chegar ao 
software adaptativo?
Software 
Adaptativo
105
1. Separação de interesses;
2. Reflexão computacional;
3. Projeto baseado em componente;
Três técnicas
Software 
Adaptativo
106
▫ Separar as partes que implementam funcionalidade das
que cuidam de outras coisas;
▫ Neste contexto:
▪ Desenvolver um middleware para aplicações
distribuídas é o mesmo que manipular
funcionalidades extras independentemente de
aplicações;
▫ A dificuldade está na modularização;
▫ Modularizar e depois entrelaçar interesses cruzados é o
mesmo tema trabalhado por desenvolvimento de
software orientado a aspecto;
Três técnicas
1. Separação de 
Interesses
Software 
Adaptativo
107
▫ Pode ser compreendida como à capacidade de um
programa inspecionar-se, e adaptar-se quando
necessário;
▫ As linguagens de programações modernos, como o
Java, permitem modificações em tempo de execução;
▫ Em sistemas distribuídos essa técnica ainda é um
desafio;
▪ Aplicar a técnica de reflexão a um extenso domínio
de aplicação ainda está por acontecer;
Três técnicas
2. Reflexão 
Computacional
Software 
Adaptativo
108
▫ É o suporte dado a adaptação por meio de composição;
▫ Sistemas que são configurados dinamicamente em
tempo de execução suportam ligação tardia;
▪ Ligação tardia: técnica que tem sido aplicada com
sucesso em ambientes que são necessário carregar
e descarregar módulos;
▫ A dificuldade está quando precisa existir a substituição
de um componente e não é possível mapear os efeitos
que haverá em outros componentes;
Três técnicas
3. Projeto Baseado 
em Componente
Discussão
109
Discussão
110
▫ Situação: Requisitos extrafuncionais conflitam com a
meta de transparência;
▫ Resultado: Middlewares com alta flexibilidade;
▫ “[...] assuntos como abertura são de igual importância,
mas a necessidade de flexibilidade nunca foi tão
predominante como no caso do middleware”
▫ Assim, a necessidade se torna uma premissa:
▪ São necessárias softwares adaptativos no sentido de
que permitir mudança à medida que o ambiente se
altera;
Discussão
111
Qual o argumento que sugere a
existência de um software adaptativo
no middleware de sistemas
distribuídos?
Discussão
112
“O argumento mais forte e por certo o
mais válido para suporte software
adaptativo é que muitos sistemas
distribuídos não podem ser desligados”
Discussão
113
▫ Sistemas distribuídos devem ser capazes de reagir
a mudanças em seu ambiente;
▪ Exemplo: trocar de políticas de alocação de
recursos;
▫ O desafio conclusivo é deixar este
comportamento reativo e sem a necessidade de
intervenção humana;
Portanto...
Autogerenciamento 
em Sistemas 
Distribuídos
Arquiteturas
114
“
Sistemas distribuídos – e em especial 
seu middleware associado – precisam 
fornecer soluções gerais de blindagem 
contra aspectos indesejáveis inerentes 
a redes, de modo que possam suportar 
o maior número possível de aplicações.
115
Autogerenciamento
116
▫ Transparência de distribuição total não é foco
principal da maioria das aplicações;
▫ Existe portanto um foco no conceito de software
adaptativo;
▫ Quando a adaptação precisa ser automática:
1. Precisa-se organizar os componentes do sistemas
distribuído de modo a promover monitoramento e
ajustes;
2. Necessário decidir onde devem ser executados os
processos que manipulam a adaptação;
Sistemas 
Distribuídos
Computação 
Autonômica
117
São sistemas de realimentação de
controle de alto nível que permitam
adaptação automática a mudanças.
Ou Sistemas Auto
O modelo de realimentação 
de controle
118
Modelo de 
Realimentação 
de Controle
119 ▫ Premissa: adaptações ocorrem por meio de um ou mais
laços de realimentação de controle;
▫ Sistemas organizados por meios de laços são
conhecidos como sistemas de realimentação de
controle;
▫ O núcleo de um sistema de realimentação de
controle é formado pelos componentes que precisam
ser gerenciados;
▫ O laço de realimentação de controle é formado por três
elementos:
▪ Componente de estimativa de medição;
▪ Componente de análise de realimentação;
▪ Medidas de ajustes (conjunto de componentes).
120
Resumo
121
Resumo
122
▫ Sistemas Distribuídos podem ser organizados de
modos diferentes;
▫ Existe distinção entre arquitetura de software e
arquitetura de sistema;
▪ Arquitetura de sistemas: os componentes
que compõem o sistemas distribuídos estão
colocados nas várias máquinas;
▪ Arquitetura de software: preocupa-se com a
organização lógica. Como é realizada a
interação e como são estruturados dos
componentes.
Importante!
Resumo
123
▫ Estilo arquitetônico reflete a interação e
organização dos componentes que integram um
sistema distribuído;
▫ Organização cliente e servido como importante
estrutura de um sistemas distribuído;
▫ Arquiteturas descentralizadas como a peer-to-peer;
▫ Sistemas autogerenciadores aumenta a
capacidade de adaptação do sistema e minimizam
a intervenção humana;
Importante!
Referências
124
TANENBAUM, A. S.; STEEN, M. V. Sistemas
Distribuídos: princípios e paradigmas. 2.ed. São
Paulo, SP: Pearson Prentice Hall, 2008
Arquiteturas:
Estilos Arquitetônicos
CURSO DE CIÊNCIA DA COMPUTAÇÃO
DISCIPLINA DE SISTEMAS DISTRIBUÍDOS
PROF. MESSIAS R. BATISTA