Arquiteturas de Sistemas Distribuídos

Prévia do material em texto

A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 1 Hélio Crestana Guardia - 2013 
•  Arquitetura de software trata da organização lógica do 
software: como os componentes interagem, de que modo são 
estruturados, questões de independência, etc. 
•  Arquitetura de um sistema trata de como são posicionados os 
componentes de software, suas instanciações, e como ocorrem 
suas interações 
Arquiteturas de Sistemas Distribuídos 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 2 Hélio Crestana Guardia - 2013 
Arquiteturas de Sistemas Distribuídos 
•  Sistemas Distribuídos são comumente partes complexas de software 
dispersas por múltiplas máquinas. 
•  Organização do sistema é fundamental para controlar complexidade. 
•  Possível distinção entre a organização lógica e a implementação física. 
•  Arquiteturas de software tratam de como os componentes são organizados 
e devem interagir. 
•  Diferentes formas de organização possíveis: centralizadas, distribuídas e 
híbridas. 
•  É também possível ter sistemas que monitoram seus próprios 
comportamentos e fazem adequações necessárias, caracterizando sistemas 
autonômicos. 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 3 Hélio Crestana Guardia - 2013 
Estilos Arquitetônicos 
•  Estilo arquitetônico é definido em termos de componentes, de como os 
componentes são interconectados, dos dados trocados entre componentes, e 
de como os elementos são agrupados para formar um sistema. 
•  Componente é uma entidade modular com interface bem definida, que pode ser 
substituído dentro do seu ambiente. 
•  Conector é um mecanismo que serve de mediador da comunicação ou da 
cooperação entre componentes. 
–  Conector pode ser formado, por exemplo, por mecanismos para chamadas de 
procedimentos (remotos), para passagem de mensagem ou streaming de dados. 
•  Principais estilos arquitetônicos para sistemas distribuídos: 
–  Arquitetura em camadas 
–  Arquitetura baseada em objetos 
–  Arquitetura centrada em dados (data-centered) 
–  Arquitetura baseada em eventos (event-based) 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 4 Hélio Crestana Guardia - 2013 
Estilos Arquitetônicos 
Organização em camadas 
•  Componentes são organizados em camadas 
•  Componente na camada Li tem permissão de chamar componentes na 
camada subjacente Li-1, mas não o contrário 
•  Requisições descem pela hierarquia e resultados fluem p/ cima 
Arquiteturas baseadas em objetos 
•  Objetos correspondem aos componentes 
•  Objetos conectados por meio de chamadas de procedimentos (remotos) 
 
Arquiteturas em camadas e baseadas em objetos ainda são os estilos mais 
usuais em sistemas de software de grande porte. 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 5 Hélio Crestana Guardia - 2013 
Estilos Arquitetônicos 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 6 Hélio Crestana Guardia - 2013 
Estilos Arquitetônicos 
Arquiteturas centradas em dados 
•  Processos se comunicam por meio de repositório comum 
•  Podem ser baseadas na comunicação utilizando arquivos de um sistema de arquivos 
distribuídos compartilhados 
•  Sistemas distribuídos baseados na Web são outra abordagem em que processos se 
comunicam através de serviços de dados 
Arquiteturas baseadas em eventos 
•  Nesse caso, processos se comunicam por meio da propagação de eventos que, 
opcionalmente, também transportam dados 
•  Propagação de eventos está associada com sistemas publicar/subscrever (publish/
subscribe) 
•  Processos publicam eventos; middleware assegura que somente processos que se 
subscreveram para eventos receberão as notificações apropriadas 
•  Vantagem: processos fracamente acoplados, que não precisam se referir 
explicitamente uns aos outros (desacoplados no espaço, ou referencialmente 
desacoplados) 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 7 Hélio Crestana Guardia - 2013 
Estilos Arquitetônicos 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 8 Hélio Crestana Guardia - 2013 
Estilos Arquitetônicos 
•  Arquiteturas baseadas em eventos podem ser combinadas com arquiteturas 
centradas em dados, resultando em espaços compartilhados de dados. 
•  Com isso, processos também são desacoplados no tempo e não precisam 
estar ambos ativos quando ocorre a comunicação. 
•  Acesso aos dados no repositório compartilhado também pode ocorrer através 
de interfaces semelhantes à SQL, através de uma descrição em vez de uma 
referência explícita. 
•  Nenhuma solução única prevalece para todos os casos. 
 
 Decoupling processes in space (“anonymous”) and also time (“asynchronous”) has led to 
 alternative styles: 
 (a) Publish/subscribe [decoupled in space] 
 (b) Shared dataspace [decoupled in space and time] 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 9 Hélio Crestana Guardia - 2013 
Arquiteturas de sistemas 
•  Arquitetura de um sistema trata de como são posicionados os 
componentes de software, nos diferentes estilos arquiteturais, e 
como ocorrem suas interações 
•  Sistemas Distribuídos são comumente pensados em termos de 
clientes que requisitam serviços de servidores 
•  Arquiteturas podem ser centralizadas, descentralizadas ou 
híbridas 
 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 10 Hélio Crestana Guardia - 2013 
Arquiteturas centralizadas 
Modelo cliente-servidor básico 
•  Processo Servidor implementa serviço específico. 
•  Comportamento de requisição-resposta (request-reply). 
•  Processo Cliente requisita serviço do servidor enviando requisição e, em seguida 
espera resposta. 
•  Comunicação pode ocorrer por meio de protocolo simples, sem conexão, quando rede 
é confiável (tipicamente em redes locais). 
•  Requisição de serviço: mensagem para servidor com identificação do serviço 
solicitado mais os dados de entrada necessários. 
•  Servidor espera chegada de requisição, processa-a e empacota os resultados em 
mensagem de resposta. 
•  Equilíbrio entre desempenho e confiabilidade em comunicações com conexão. 
•  Comunicações comumente ocorrem com TCP/IP, usando a mesma conexão para 
envio da requisição e da resposta. 
•  Falhas de comunicação podem gerar retransmissões ou apenas identificação de erro. 
•  Operações que podem ser repetidas sem gerar erros são ditas idempotentes. 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 11 Hélio Crestana Guardia - 2013 
Interação entre cliente e servidor 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 12 Hélio Crestana Guardia - 2013 
Organizaç ão da aplicação em camadas 
•  Distinção clara entre servidor e cliente pode não existir 
•  Servidores também podem ser clientes (e.g.: BDs → Sist. Arq.) 
•  Cenário comum levou à distinção em 3 níveis (three-layered view): 
–  Nível de interface de usuário 
–  Nível de processamento 
–  Nível de dados 
•  Nível de interface de usuário contém tudo que é necessário para permitir aos 
usuários finais interagir com aplicações, como o gerenciamento de exibição. 
–  Diferentes níveis de interfaces: de telas simples em modo texto a ambientes 
gráficos com janelas 
•  Clientes implementam o nível de interface de usuário 
•  Nível de processamento contém as aplicações (funções, sem dados) 
•  Nível de dados gerencia dados sobre os quais é aplicada alguma ação 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 13 HélioCrestana Guardia - 2013 
Camadas em aplicações. Ex: Busca na Web 
•  Outros exemplos: sistema de suporte à decisão para corretora de valores; 
ambiente de escritório com arquivos armazenados em servidor; etc. 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 14 Hélio Crestana Guardia - 2013 
Arquiteturas Multidivididas (multitiered) 
Implementação de aplicação cliente-servidor prevê 2 tipos de máquinas: 
•  Cliente: contém apenas programas que implementam o nível de interface de 
usuário. 
•  Servidor: contém programas que implementam o nível de processamento de 
dados 
•  Arquiteturas: 
–  Uma divisão (single-tiered): configuração de terminal (burro) e 
mainframe 
–  Duas divisões (two-tiered): configuração cliente servidor único (single 
server) 
–  Três divisões (three-tiered): cada nível numa máquina separada 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 15 Hélio Crestana Guardia - 2013 
Arquiteturas Multidivididas (multitiered) 
Exemplos de arquitetura de duas divisões (two-tiered): 
•  Abordagens (d) e (e) são mais complexas de gerenciar 
•  Tendência atual recai sobre abordagens (a-c) (c)? 
•  Servidor único sendo substituído por vários, executados em máquinas diferentes 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 16 Hélio Crestana Guardia - 2013 
Arquiteturas Multidivididas (multitiered) 
Exemplo de arquitetura de três divisões (three-tiered): 
•  Servidor age como cliente 
•  Programas do nível de processamento residem em servidor separado mas podem 
também ser parcialmente distribuídos pelas máquinas cliente e servidora 
Ex.: Processamento de transações – monitor de processamento de transações coordena 
transações em servidores de dados possivelmente diferentes; servidor Web age como 
ponto de entrada para site, repassado requisições para servidor de aplicação, que 
interage com servidor de banco de dados. 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 17 Hélio Crestana Guardia - 2013 
Arquiteturas descentralizadas 
Descentralização do processamento: 
•  Distribuição vertical: alocação dos componentes logicamente diferentes em 
máquinas diferentes. Associada ao conceito de fragmentação vertical em bancos de 
dados relacionais distribuídos. 
•  Distribuição horizontal: foco na distribuição dos clientes e servidores. Cliente ou 
servidor pode ser fisicamente subdividido em partes logicamente equivalentes, cada 
uma operando em sua própria porção do conjunto completo de dados. Favorece o 
balanceamento da carga. Ex.: arquiteturas peer-to-peer. 
 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 18 Hélio Crestana Guardia - 2013 
Arquiteturas descentralizadas: peer-to-peer 
•  Processos que constituem o sistema peer-to-peer (P2P) são todos iguais 
•  Funções que precisam ser realizadas estão representadas em todos os processos 
•  Interação entre processos é simétrica: cada processo age como cliente e servidor ao 
mesmo tempo, sendo denominado servente (servent) 
•  Questão principal da arquitetura: como organizar os processos em uma rede de 
sobreposição (overlay network)? 
•  nós correspondem a processos; enlaces representam canais de comunicação possíveis 
•  Em geral, um processo não pode se comunicar diretamente com outro qualquer, mas 
deve enviar mensagens por meio dos canais de comunicação disponíveis. 
•  Dados são encaminhados sobre as conexões estabelecidas entre os nós (application-
level multicasting) 
•  Redes overlay podem ser estruturadas ou não: 
–  Structured P2P: nós organizados de acordo com estrutura de dados distribuída 
–  Unstructured P2P: nós têm vizinhos selecionados aleatoriamente 
–  Hybrid P2P: alguns nós possuem funções especiais em estrutura bem organizada 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 19 Hélio Crestana Guardia - 2013 
Arquiteturas P2P estruturadas 
•  Overlay network é formada através de procedimento determinístico. 
•  Estrutura comum: tabela hash distribuída (Distributed Hash Table – DHT) 
•  Itens de dados recebem chave aleatória, como um identificador de 128 ou 
160 bits dentro de um grande espaço de identificadores. 
•  Nós do sistema também recebem um número aleatório do mesmo espaço de 
identificadores . 
•  DHT: esquema eficiente e determinístico, baseado em métrica, que mapeie 
exclusivamente chave de um item de dado para identificador de um nó. 
•  Ao consultar item de dado identificador do nó responsável é obtido. 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 20 Hélio Crestana Guardia - 2013 
Arquiteturas P2P estruturadas 
Gerenciamento de associação ao grupo 
•  Cada nó mantém atalhos para outros nós 
•  Consultas podem tipicamente ser feitas em O(log(N)) etapas; N=num nós 
•  Nó juntando-se ao grupo gera identificador aleatório (id) e obtém succ(id) 
•  Nó interage com succ(id) e com seu predecessor para inserir-se no anel 
•  Itens de dado cuja chave está associada a id devem ser transferidos de 
succ(id) para nó ingressante 
•  Para sair, nó informa partida a predecessor e sucessor e transfere dados para 
succ(id) 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 21 Hélio Crestana Guardia - 2013 
Arquiteturas P2P estruturadas: Chord (DHT) 
•  Nós organizados em anel 
•  Item de dado com chave k é mapeado para o nó que possua o menor identificador 
(id >= k), denominado nó sucessor de k – succ(k) 
•  Operação lógica LOOKUP(key) retorna o endereço de succ(key) 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 22 Hélio Crestana Guardia - 2013 
Arquiteturas P2P estruturadas: CAN (DHT) 
Content Addressable Network – CAN 
•  Espaço de coordenadas cartesisanas de d dimensões particionado entre os nós 
•  Quando um nó é admitido, divide-se uma região 
•  Saída de um nó gera junção de regiões 
•  Rebalanceamento periódico procura manter áreas equilibradas 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 23 Hélio Crestana Guardia - 2013 
Arquiteturas P2P não estruturadas 
•  Muitos sistemas P2P procuram manter grafos aleatórios 
•  Algoritmos aleatórios são usados para construir rede de sobreposição 
(overlay) 
•  Cada nó deve manter lista de vizinhos, denominada visão parcial (partial 
view), que é construída de modo mais ou menos aleatório 
•  Nós trocam informações sobre suas visões parciais periodicamente 
•  Entradas nas visões contêm valor da antiguidade das referências aos nós 
•  Itens de dados podem ser posicionados de maneira aleatória nos nós 
•  Quando um nó precisa localizar um item de dado específico, inunda a rede 
com consulta de busca 
•  Manutenção das informações de localização geralmente tratada por 2 
threads: ativa e passiva, encarregadas de propagar e de receber 
informações sobre a rede 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 24 Hélio Crestana Guardia - 2013 
Arquiteturas P2P não estruturadas 
•  Thread ativa (active) toma a iniciativa de comunicar-se com outro nó para 
propagação de sua visão parcial; thread também pode receber visão do nó 
para o qual está propagando informações 
–  Thread ativa no nó P seleciona algum outro nó Q de maneira aleatória, a partir de sua visão 
parcial atual, que contém c outros nós 
–  Buffer é preenchido com informações de c/2+1 nós, incluindo nó atual 
–  Nós P e Q trocam informações sobre os membros de suas visões parciais 
–  Diferentes algoritmos podem ser usados para elaborar a nova visão parcial, descartando 
parte das informações existentes para incorporação dasnovas 
•  Thread passiva (passive) também troca visão parcial dos nós mas não toma a 
inciativa de contatar outros nós 
•  Balanceamento da rede é obtido ao descentralizar informações sobre nós, 
evitando sobrecarregar nós com alto grau interno (indegree, que são 
referenciados em muitas visões parciais) 
•  Nós podem simplesmente deixar a rede; informações sobre nós inatingíveis 
(selecionados para interação, mas não responsivos) são descartadas 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 25 Hélio Crestana Guardia - 2013 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 26 Hélio Crestana Guardia - 2013 
Gerenciamento de topologia em redes overlay 
•  Gerenciamento das visões parciais em sistemas P2P permite manter 
topologias específicas 
•  Tratamento das informações pode ocorrer em abordagem em duas camadas: 
–  Camada mais baixa constitui sistema P2P não estruturado, no qual nós trocam 
informações periodicamente para manter gráfico aleatório preciso (contendo 
informações apenas de nós vivos) 
–  Camada mais alta realiza seleção adicional das entradas fornecidas pela camada 
mais baixa, resultando numa segunda lista de vizinhos, de acordo com a 
topologia desejada 
•  Nós podem ser ordenados de acordo com critério de interesse para um nó 
•  Ordenação pode ocorrer por distância em relação a um dado nó 
•  Outra forma de ordenação pode ser a proximidade semântica de itens de 
dados armazenados em um nó, dando origem a redes overlay semânticas 
Semantic similarity, or semantic relatedness, is a concept whereby a set of documents or terms within 
term lists are assigned a metric based on the likeness of their meaning / semantic content [wikipedia] 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 27 Hélio Crestana Guardia - 2013 
Gerenciamento de topologia em redes overlay 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 28 Hélio Crestana Guardia - 2013 
Gerenciamento de topologia em redes overlay 
Ex. Grade lógica de tamanho N x N, com um nó em cada ponto da grade 
•  Todo nó mantém apenas lista de c vizinhos mais próximos 
•  Distância de (a1,a2) a (b1,b2) dada por: ∥ (a1,a2)−(b1,b2) ∥= d1 +d2 
 di = min{N −|ai −bi|,|ai −bi|} 
•  Figura resultante = torus 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 29 Hélio Crestana Guardia - 2013 
Superpares (superpeers) 
•  Localização de nós relevantes em sistemas P2P não estruturados torna-se 
crítica com o crescimento da rede 
•  Não há mecanismo determinístico para rotear requisição até item de dado 
específico 
•  Descobertas são feitas via consulta a todos os nós, mas inundações podem ser 
limitadas 
•  Sistemas P2P propuseram uso de nós especiais, que mantêm índices de itens 
de dados → superpares (superpeers) 
•  Superpeers mantêm índices ou agem como intermediários 
•  Superpeers podem ser organizados em uma rede peer-to-peer, dando origem 
a uma organização hierárquica 
•  Exemplos de uso de superpeers: 
•  peers que mantêm um índice de busca; 
•  peers que monitoram o estado da rede; 
•  rede colaborativa de entrega de conteúdo (Content Distribution Network – CDN) 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 30 Hélio Crestana Guardia - 2013 
Superpares (superpeers) 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 31 Hélio Crestana Guardia - 2013 
Superpares (superpeers) 
•  Relação cliente-superpar pode ser fixa, permanecendo o cliente em contato 
com o mesmo nó inicial 
•  Superpeers devem ser processos de vida longa e grande capacidade 
•  Estruturas redundantes para a identificação dos peers pode ser estabelecida 
•  Relação cliente-superpeer pode mudar à medida que clientes descobrem 
superpeers melhores para conectar-se 
•  Organização requer mecanismo apropriado para a seleção dos nós que irão 
tornar-se superpeers 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 32 Hélio Crestana Guardia - 2013 
Arquiteturas híbridas de sistemas distribuídos 
Muitos sistemas distribuídos combinam soluções cliente-servidor com 
arquiteturas descentralizadas (P2P) 
 
•  Sistemas de servidor de borda (edge-server systems) 
–  Sistemas disponibilizados na Internet, onde servidores são posicionados 
na fronteira entre redes corporativas e a Internet 
–  Típico em rede de provedor de acesso à Internet (Internet Service 
Provider – ISP) 
–  Servidores utilizados para otimizar a distribuição de conteúdo e de 
aplicação 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 33 Hélio Crestana Guardia - 2013 
Arquiteturas híbridas 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 34 Hélio Crestana Guardia - 2013 
Arquiteturas híbridas 
Sistemas Distribuídos colaborativos 
•  Sistemas de distribuição de conteúdo com P2P 
•  Ex. BitTorrent: sistema P2P de transferência de conteúdo 
•  Usuário buscando arquivo transfere porções dos dados a partir de outros usuários até 
que porções possam ser montadas em conjunto, resultando no arquivo completo 
•  Clientes comumente procuram limitar-se a obter arquivos, com colaboração quase 
nula 
•  Para incentivar colaboração, cliente só pode transferir (obter) arquivo quando também 
estiver fornecendo conteúdo a mais alguém 
•  Comportamento tit-for-tat (equivalent retaliation) 
 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 35 Hélio Crestana Guardia - 2013 
BitTorrent 
•  Para obter arquivo, usuário precisa acessar diretório global entre sites conhecidos 
•  Diretório contém referências a arquivos .torrent, que contêm informações de tracker 
(rastreador) que mantém contabilidade dos nós ativos que têm o arquivo buscado 
•  Diversos trackers podem existir mas, em geral há um único para cada arquivo 
•  Uma vez identificado de onde obter um arquivo, cliente se une a 'enxame' de usuários, 
copiando a partir da fonte mas também distribuindo as partes já obtidas entre si 
•  Usuário é forçado a colaborar provendo partes do arquivo que está copiando para 
outros nós que ainda não o têm 
•  Nós podem reduzir a taxa de fornecimento de dados para outros com quem fazem 
uma troca desbalanceada 
•  Gargalo do sistema são os trackers 
•  Questões: 
•  Como manter lista atualizada dos repositórios das informações? 
•  Como controlar o balanceamento das transferências nos nós (download x upload)? 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 36 Hélio Crestana Guardia - 2013 
BitTorrent 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 37 Hélio Crestana Guardia - 2013 
Arquiteturas versus Middleware 
•  Middleware forma camada entre aplicações e plataformas distribuídas 
•  Sistemas de middleware seguem estilo arquitetônico específico 
•  Finalidade inclui prover transparência, ocultando das aplicações (até certo 
ponto) questões de distribuição de dados, de processamento e de controle 
•  Muitas soluções de middleware adotaram estilo arquitetônico baseado em 
objetos, como CORBA. 
•  Outros, como TIB/Rendezvous, são baseados em eventos 
•  Moldar middleware de acordo com estilo arquitetônico simplifica o projeto, 
mas limita o desenvolvimento de aplicações 
•  Várias versões de um mesmo middleware podem existir, com suporte para 
classes de aplicações específicas 
•  Middleware deve idealmente ser simples de configurar e adaptar, de acordo 
com necessidades da aplicação 
•  Resultado são sistemas com separação entre políticase mecanismos, que 
permitem modificar o comportamento do middleware 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 38 Hélio Crestana Guardia - 2013 
Interceptadores 
l  Interceptadores permitem modificar o comportamento do 
middleware 
l  Um interceptador é uma construção de software que interrompe o 
fluxo normal de controle e permite que outro código específico da 
aplicação seja executado 
l  Interceptadores permitem a um objeto A chamar um método de um 
objeto B que reside em uma máquina remota 
l  Invocação remota é realizada em 3 etapas: 
l  Interface idêntica à oferecida por objeto remoto B é oferecida localmente em A 
l  Chamada feita por A é transformada em uma invocação genérica a objeto 
através de uma interface de chamada oferecida pelo middleware em A 
l  Invocação a objeto genérico é transformada em mensagem que é enviada pelo 
suporte da camada de transporte provido pelo SO local 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 39 Hélio Crestana Guardia - 2013 
Interceptadores 
invoke(B, &faz-alguma-coisa, valor) 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 40 Hélio Crestana Guardia - 2013 
Middleware adaptativo 
•  Interceptadores oferecem uma forma de adaptar o middleware 
•  Adaptações se devem às mudanças constantes do ambiente em que as 
aplicações distribuídas são executadas 
•  Mudanças são necessárias devido à mobilidade, a alterações significativas na 
QoS de redes, a falhas de hardware, à exaustão da carga da bateria, etc. 
•  Ideias deram origem ao conceito de software adaptativo, mas conceito não 
obteve o sucesso esperado 
•  Adaptação às mudanças é realizada pelo middleware ao invés de deixar 
isso para as aplicações 
•  Técnicas para a adaptação de software: 
–  Separação de interesses 
–  Reflexão computacional 
–  Projeto baseado em componente 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 41 Hélio Crestana Guardia - 2013 
Middleware adaptativo 
l  Separação de interesses: modo tradicional de modularizar sistemas 
l  Separar partes que implementam funcionalidades das partes que cuidam de funções 
adicionais, como confiabilidade, segurança, desempenho, etc. 
l  Separação de funcionalidades extras não é facilmente obtida. 
l  Separação e posterior interligação desses aspectos em sistemas distribuídos é o foco da área 
de desenvolvimento de software orientado a aspecto. 
l  Orientação a aspecto ainda não (?) tem sido bem sucedida no desenvolvimento de sistemas 
distribuídos de grande escala 
l  Reflexão computacional: refere-se à capacidade de um programa 
inspecionar-se a si mesmo e, se necessário, adaptar seu comportamento 
–  Presente em java e outras linguagens, suporta modificações em tempo de execução 
–  Ainda não tem (?) sido bem sucedida no desenvolvimento de SD de grande escala 
l  Projeto baseado em componente: suporta adaptação por meio de 
composição. 
–  Sistema pode ser configurado estaticamente, durante a elaboração do projeto, ou 
dinamicamente, em tempo de execução (late binding). 
–  Componentes podem ser substituídos dinamicamente, sob demanda (estratégia complexa...) 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 42 Hélio Crestana Guardia - 2013 
Middleware adaptativo 
l  Argumento mais forte para suportar software adaptativo é que muitos 
sistemas distribuídos não podem ser desligados. 
l  Essa restrição exige soluções para substituir e atualizar componentes durante 
o funcionamento do sistema. 
l  De maneira geral, sistemas distribuídos devem ser capazes de reagir a 
mudanças no ambiente. 
l  Comportamento reativo deve ocorrer ser intervenção humana 
l  Melhor abordagem para adaptação ainda não está definida 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 43 Hélio Crestana Guardia - 2013 
Auto-gerenciamento em SDs 
l  Middleware de SDs pode oferecer tratamento contra aspectos indesejáveis 
da operação da rede para viabilizar maior variedade de aplicações 
l  Adaptação provida pelo middleware deve referir-se ao comportamento de 
execução e não de seus componentes 
l  Na adaptação automática, componentes do SD devem poder ser 
monitorados e ajustados 
l  Localização dos processos que realizam a adaptação é importante 
l  Sistemas Distribuídos podem ser organizados como sistemas com 
realimentação de controle (feedback-control systems) que permitem 
adaptação automática 
l  Fenômeno (realimentação de controle e adaptação) é conhecido como 
computação autonômica (autonomic computing), ou sistemas auto* (self-
star systems). Comumente, chamado de autogerenciador (self-managing). 
 *: autogerenciador, auto-reparador, autoconfigurador, auto-otimizador, … (self-
 configuration, self-managing, self-healing, self-optimizing, self-*) 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 44 Hélio Crestana Guardia - 2013 
Auto-gerenciamento em SDs 
•  Adaptações ocorrem por um ou mais laços de realimentação de controle 
(feedback control loops) 
•  Sistemas são denominados sistemas de realimentação de controle 
(feedback control systems – FCS) 
•  Núcleo de um FCS é formado pelos componentes a serem gerenciados 
–  Componentes são guiados por parâmetros de entrada a ser controlados 
–  Comportamento pode ser influenciado por todos os tipos de entradas não controláveis 
(perturbações ou ruídos) 
•  Laço de realimentação e controle é composto de 3 elementos: 
–  Componente de estimativa de medição (metric estimation component) 
–  Componente de análise de realimentação (feedback analysis component): analisa 
medições e compara com valores de referência. Requer conhecimento dos mecanismos de 
ajustes existentes. 
–  Mecanismos para influenciar o comportamento do sistema: posicionamento de réplicas, 
mudanças de prioridade, troca dinâmica de serviços, movimentação de dados para 
disponibilidade, redirecionamento de requisições para servidores diferentes, etc. 
A. S. Tanenbaum, M. Van Steen. Sistemas Distribuídos: Princípios e paradigmas - Cap 2: Arquiteturas / 45 Hélio Crestana Guardia - 2013 
Auto-gerenciamento em SDs 
•  Organização física pode variar: 
–  Componente de análise pode ser distribuído 
–  Medições podem ser realizadas em cada nó