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 ummiddleware adaptativo;

▫ Sistemas distribuídos devemmonitorar seu funcionamento

▪ Sistemas autonômicos

7

Estilos Arquitetônicos

8

9

O quanto é crucial adotar uma

arquitetura desoftware para um projeto?

Estilo Arquitetônico

10

▫ Formulado com base nos componentes que ocompõe;

▫ A forma de conexão dos componentestambém é importante;

▫ Os dados trocados entre os componentes;

▫ A forma de configuração desse conjunto deelementos;

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 umrepositório comum;

▫ Tem grau de importância similar as baseadas emcamadas 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 compartilhadosde 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

ArquiteturasArquiteturas 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 umserviço específico;

▫ Cliente

▪ É um processo que requisita um serviçode um servidor enviando-lhe umarequisição e, na sequência, esperandopela 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 oservidor identificando o serviço que quer,junto com os dados necessários.

2. O servidor sempre vai esperar a chegada deuma requisição;

▪ Processará e empacotará os resultadosem 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 maneiramenos custosa;

▫ Problema:

▪ as mensagens não podem se perder ou seremcorrompidas;

▫ Dificuldade:

▪ desenvolver um protocolo que seja resistentea 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 vezessem causar dano são chamadas de idempotente;

▫ Não existe soluções únicas para tratamento demensagens perdida;

▫ Alternativa é a utilização de protocolos confiáveisorientados a conexão;

▫ Garantindo que sempre que um cliente requisitouum serviços, antes ele estabeleceu uma conexãocom o servidor e só em seguida enviou arequisição.

Não há!

Camadas de Aplicação

41

Camadas de Aplicação

42

▫ Como estabelecer uma distinção clara entreum cliente um servidor?

▪ Um servidor para um banco de dadosdistribuídos pode agir continuamente comoum cliente porque está repassandorequisições para diferentes servidores dearquivos responsáveis pela implementaçãodas 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 processamentonormalmente 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 ousuário;

2. Intermediária. Mantém afuncionalidade central daaplicação;

3. Age sobre o banco de dadosou 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, osdados continuam armazenados aguardando apróxima utilização;

▫ “O nível de dados consiste em um sistema dearquivo, porém é mais comum utilizar um bancode dados plenamente capacitado”;

▫ É implementado no lado do servidor;

Importante!

Nível de Dados

53

▫ É responsável por manter a consistência dosdados em diferentes aplicações;

▫ Pode utilizar recursos como triggers paramanipular disparos de informação;

▫ Ambientes orientados a negócios utilizam bancosde dados relacionais;

▫ A organização dos dados é independente dasaplicações;

Importante!

Nível de Dados

54

“[...] nem sempre bancos de dados relacionaissão a opção ideal. Um aspecto característico demuitas aplicações é que elas operam sobretipos de dados complexos cuja modelagem émais fácil em termos de objetos do que emtermos de relações”

Conhecem o termoPersistê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 queimplementam o nível (parte do nível) deinterface de usuário.

▫ Máquina do servidor

▪ Contém o resto, ou seja, os programasque implementam o nível deprocessamento 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 gordosX

Clientes Magros

64

Distribuição vertical

65

“[...] da perspectiva e gerenciamento desistema, ter uma distribuição vertical podeajudar: funções são subdivididas lógica efisicamente por várias máquinas, e cadamáquina é projetada para um grupo específicode funções”

Arquiteturas Descentralizadas

ArquiteturasArquiteturas de Sistemas

66

Distribuição horizontal

67

“Em arquiteturas modernas, muitas vezes é adistribuição dos clientes dos servidores que conta àqual nos referimos como distribuição horizontal”

▫ O cliente ou o servidor podem ser subdivididosfisicamente em partes logicamente equivalentes;

▪ Cada parte opera em sua própria porção doconjunto;

▪ Busca-se o equilíbrio da carga;

▫ Exemplo: peer-to-peer

Peer-to-peer

68

“De uma perspectiva de alto nível, os processosque constituem um sistemas peer-to-peer sãotodos iguais, o que significa que as funções queprecisam ser realizadas são representadas portodo processo que constitui o sistemadistribuído”

Peer-to-peer

69

▫ Organizam os processos por meio de umatabela de hash distribuída (Distributed HashTable – DHT);

▫ DHT implementa um mapeamento de chavedo item para um nó baseando por distânciasmétricas;

Redes Estruturadas

Sistema Chord

70

Peer-to-peerRedes Estruturadas

71

Peer-to-peer

72

▫ Dependem de algoritmos aleatórios paraconstruir 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 sejamcolocados 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 é ogerenciamento de associação ao grupo;

▫ Sua estrutura é similar a um gráficoaleatório;

▫ Cada nó mantém um lista de vizinhos, nósvivos;

▫ A lista de vizinhos é denominada visãoparcial;

Redes Não-Estruturadas

Peer-to-peer

74

▫ A construção de uma nova visão:

▪ Os nós descartam as entradas criadasentre eles;

▪ Ou, os nós descartam o maior númeropossí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-peerestruturados 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

ArquiteturasArquiteturas 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çõespara outros usuários;

▫ Assim, cria-se um conjunto de porções sendotransferidas;

▫ A importância do projeto está na colaboração;

▫ Problema: quando existe grande quantidade deusuários objetivando apenas obter os arquivos;

▫ Portanto, “um arquivo só pode ser transferidoquando o cliente que está transferindo estiverfornecendo conteúdo a mais alguém”;

92

Arquiteturas versusMiddleware

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 detransparência de distribuição;

▫ Seguem um estilo arquitetônico específico;

▫ A especificidade do estilo arquitetônico é parasimplificar projetos de aplicações;

▫ Apesar de sua finalidade, considera-se tê-lo paraser mais adaptável as requisições de aplicação;

Middleware

97

“Uma abordagem geral consideramelhor é fazer sistemas de middlewarede modo que sejam simples deconfigurar, adaptar e personalizarconforme necessário para umaaplicação.”

Interceptadores

98

Interceptador

99

▫ É um constructo de software que interromperá ofluxo de controle usual e permitirá que sejaexecutado um outro código;

▫ Funciona com alto suporte em sistemasdistribuídos orientado à objetos;

▫ Um objeto A pode chamar um método quepertence a um objeto B enquanto este residir emuma 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. Asimplesmente chama o método disponível naquelainterface;

2. A chamada por A é transformada em uma invocação aobjeto genérico, possibilitada por meio de umainterface geral de invocação de objeto oferecida pelomiddelware na máquina em que A reside;

3. Por fim, a invocação a objeto genérico é transformadaem uma mensagem que é enviada por meio de umainterface de rede de nível de transporte como oferecidapelo sistema operacional local de A.

101

Abordagens gerais para o software adaptativo

102

Software Adaptativo

103

▫ Interceptadores oferecem um meio de adaptar omiddleware;

▫ A necessidade de adaptação surge do ambientedas aplicações distribuídos, que estão sempremudando;

▪ O middleware retira da aplicação a reação amudanças;

▫ Projetistas de middleware passam a considerar aconstruçã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 dasque cuidam de outras coisas;

▫ Neste contexto:

▪ Desenvolver um middleware para aplicaçõesdistribuídas é o mesmo que manipularfuncionalidades extras independentemente deaplicações;

▫ A dificuldade está na modularização;

▫ Modularizar e depois entrelaçar interesses cruzados é omesmo tema trabalhado por desenvolvimento desoftware orientado a aspecto;

Três técnicas1. Separação de Interesses

Software Adaptativo

107

▫ Pode ser compreendida como à capacidade de umprograma inspecionar-se, e adaptar-se quandonecessário;

▫ As linguagens de programações modernos, como oJava, permitem modificações em tempo de execução;

▫ Em sistemas distribuídos essa técnica ainda é umdesafio;

▪ Aplicar a técnica de reflexão a um extenso domíniode aplicação ainda está por acontecer;

Três técnicas2. Reflexão Computacional

Software Adaptativo

108

▫ É o suporte dado a adaptação por meio de composição;

▫ Sistemas que são configurados dinamicamente emtempo de execução suportam ligação tardia;

▪ Ligação tardia: técnica que tem sido aplicada comsucesso em ambientes que são necessário carregare descarregar módulos;

▫ A dificuldade está quando precisa existir a substituiçãode um componente e não é possível mapear os efeitosque haverá em outros componentes;

Três técnicas3. Projeto Baseado em Componente

Discussão

109

Discussão

110

▫ Situação: Requisitos extrafuncionais conflitam com ameta 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ãopredominante como no caso do middleware”

▫ Assim, a necessidade se torna uma premissa:

▪ São necessárias softwares adaptativos no sentido deque permitir mudança à medida que o ambiente sealtera;

Discussão

111

Qual o argumento que sugere aexistência de um software adaptativono middleware de sistemasdistribuídos?

Discussão

112

“O argumento mais forte e por certo omais válido para suporte softwareadaptativo é que muitos sistemasdistribuídos não podem ser desligados”

Discussão

113

▫ Sistemas distribuídos devem ser capazes de reagira mudanças em seu ambiente;

▪ Exemplo: trocar de políticas de alocação derecursos;

▫ O desafio conclusivo é deixar estecomportamento reativo e sem a necessidade deintervençã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 é focoprincipal da maioria das aplicações;

▫ Existe portanto um foco no conceito de softwareadaptativo;

▫ Quando a adaptação precisa ser automática:

1. Precisa-se organizar os componentes do sistemasdistribuído de modo a promover monitoramento eajustes;

2. Necessário decidir onde devem ser executados osprocessos que manipulam a adaptação;

Sistemas Distribuídos

Computação Autonômica

117

São sistemas de realimentação decontrole de alto nível que permitamadaptaçã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 maislaços de realimentação de controle;

▫ Sistemas organizados por meios de laços sãoconhecidos como sistemas de realimentação decontrole;

▫ O núcleo de um sistema de realimentação decontrole é formado pelos componentes que precisamser gerenciados;

▫ O laço de realimentação de controle é formado por trêselementos:

▪ 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 demodos diferentes;

▫ Existe distinção entre arquitetura de software earquitetura de sistema;

▪ Arquitetura de sistemas: os componentesque compõem o sistemas distribuídos estãocolocados nas várias máquinas;

▪ Arquitetura de software: preocupa-se com aorganização lógica. Como é realizada ainteração e como são estruturados doscomponentes.

Importante!

Resumo

123

▫ Estilo arquitetônico reflete a interação eorganização dos componentes que integram umsistema distribuído;

▫ Organização cliente e servido como importanteestrutura de um sistemas distribuído;

▫ Arquiteturas descentralizadas como a peer-to-peer;

▫ Sistemas autogerenciadores aumenta acapacidade de adaptação do sistema e minimizama intervenção humana;

Importante!

Referências

124

TANENBAUM, A. S.; STEEN, M. V. SistemasDistribuídos: princípios e paradigmas. 2.ed. SãoPaulo, 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