Disciplina ministrada no Curso de Ciência da Computação da Faculdade ASPER.

1. Arquiteturas
CURSO DE CIÊNCIA DA COMPUTAÇÃO
DISCIPLINA DE SISTEMAS DISTRIBUÍDOS
PROF. MESSIAS R. BATISTA

2. Estilos
Arquitetônicos
2

3. 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

4. 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.

5. “
[...] uma meta importante de
sistemas distribuídos é
separar aplicações das
plataformas subjacentes
provendo uma camada de
middleware.
5

6. 6

7. Middleware
▫ É necessário conseguir um
middleware adaptativo;
▫ Sistemas distribuídos devem
monitorar seu funcionamento
▪ Sistemas autonômicos
7

8. Estilos
Arquitetônicos
8

9. 9
O quanto é crucial adotar uma
arquitetura de
software para um projeto?

10. 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

11. “
Um componente é uma
unidade modular com
interfaces requeridas e
fornecidas bem definidas que
é substituível dentro de seu
ambiente
11

12. Componente
12
▫ É passível de substituição;
▫ Necessário respeitar as interfaces;
E os conectores?

13. “
Conector [...] é descrito como
um mecanismo que serve de
mediador da comunicação ou
da cooperação entre
componentes
13

14. Componentes e
Conectores
14

15. 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

16. 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;

17. Arquiteturas
em camadas
17

18. Arquiteturas
em camadas
18

19. 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.

20. Arquitetura
baseada em
objetos
20

21. 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.

22. Arquitetura
centrada em
dados
22

23. 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.

24. “
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

25. Arquitetura
baseada em
eventos
25
Arquiteturas baseadas em eventos, podem se
complementar com arquiteturas baseadas em dados

26. 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

27. “
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

28. Arquiteturas de
Sistemas
Arquiteturas
28

29. “
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

30. Arquiteturas
Centralizadas
Arquiteturas
Arquiteturas de Sistemas
30

31. “
[...] pensar em termos de
clientes que requisitam
serviços de servidores nos
ajuda a entender e gerenciar
a complexidade de sistemas
distribuídos [...]
31

32. 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.

33. Comportamento
Comportamento de
requisição-resposta
33

34. 34

35. 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;

36. 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. 37
E se o cliente não receber a
mensagem de resposta o
que fazer neste caso?

38. Analisando...
38
Transfira $10.000 de
minha conta
Reenviar a
resposta

39. Analisando...
39
Informe quanto dinheiro
ainda tenho.
Reenviar a
resposta

40. 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á!

41. Camadas de Aplicação
41

42. 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

43. 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

44. Camadas
1. Nível de interface de usuário
2. Nível de processamento
3. Nível de dados
44

45. 45

46. “
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

47. “
O nível de processamento
normalmente contem as
aplicações.
47

48. “
O nível de dados gerencia os
dados propriamente ditos
sobre os quais está sendo
executada alguma ação.
48

49. 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. 50
Palavras-
chave
Busca no
banco de
Dados

51. 51

52. 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!

53. Nível de Dados
53
▫ É responsável por manter a consistência dos
dados em diferentes aplicações;
▫ Pode utilizar 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!

54. 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. 55

56. 56

57. Arquiteturas Multidivididas
57

58. “
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

59. 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?

60. “
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. 61

62. 62
Consideramos o fato de
que o servidor pode ser
um cliente também?
É possível? Exemplifique.

63. 63

64. “
Clientes gordos
X
Clientes Magros
64

65. 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”

66. Arquiteturas
Descentralizadas
Arquiteturas
Arquiteturas de Sistemas
66

67. 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

68. 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”

69. 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

70. Sistema Chord
70
Peer-to-peer
Redes
Estruturadas

71. 71

72. 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

73. 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

74. 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

75. “
[...] 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

76. Problema!
76
Gargalo criado em
apenas um nó!

77. Gerenciamento de
Topologia de Redes de
Sobreposição
77

78. “
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. 79

80. Superpares (superpeers)
80

81. 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;

82. 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. 83

84. Arquiteturas
Híbridas
Arquiteturas
Arquiteturas de Sistemas
84

85. “
[...] soluções cliente-
servidor são combinadas
com arquiteturas
descentralizadas.
85

86. Sistemas de servidor de
borda
86

87. 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. 88

89. Sistemas Distribuídos
Colaborativos
89

90. “
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

91. 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. 92

93. Arquiteturas
versus
Middleware
Arquiteturas
93

94. 94
Falamos sobre
middelware?
Onde eles se encaixam?

95. “
[...] o middleware forma uma
camada entre aplicações e
plataformas distribuídas
95
Lembrando

96. 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;

97. 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.”

98. Interceptadores
98

99. 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.

100. 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. 101

102. Abordagens gerais para o
software adaptativo
102

103. 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;
▫ Projetistas de middleware passam a considerar a
construção de software adaptativo;
Abordagens gerais

104. 104
E como podemos chegar ao
software adaptativo?

105. Software
Adaptativo
105
1. Separação de interesses;
2. Reflexão computacional;
3. Projeto baseado em componente;
Três técnicas

106. 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

107. 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

108. 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

109. Discussão
109

110. 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;

111. Discussão
111
Qual o argumento que sugere a
existência de um software adaptativo
no middleware de sistemas
distribuídos?

112. 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”

113. 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...

114. Autogerenciamento
em Sistemas
Distribuídos
Arquiteturas
114

115. “
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

116. 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

117. 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

118. O modelo de realimentação
de controle
118

119. 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. 120

121. Resumo
121

122. 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!

123. 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!

124. 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

125. Arquiteturas:
Estilos Arquitetônicos
CURSO DE CIÊNCIA DA COMPUTAÇÃO
DISCIPLINA DE SISTEMAS DISTRIBUÍDOS
PROF. MESSIAS R. BATISTA