Programação Distribuída Arquiteturas
Programação Distribuída A arquitetura de um Sistema Distribuído diferencia entre a organização de componentes de software e a realização física. A organização de sistema distribuídos trata em grande parte dos componentes de software que constituem o sistema (Arquitetura de Software). Um sistema distribuído deve especificar e colocar componentes de software em máquinas reais. A especificação final de um sistema distribuído é chamada de Arquitetura de Sistema.
Arquiteturas de Sistema Estilos Arquitetônicos São formulados em termos de componentes, do modo como esses componentes estão conectados uns aos outros, dos dados trocados entre componentes e, por fim da maneira como esses elementos são configurados em conjunto para formar um sistema. Um componente é uma unidade modular com interfaces requeridas e fornecidas bem definidas que é substituível dentro do seu ambiente.
Arquitetura de Sistema Conector É um mecanismo que serve de mediador de comunicação ou da cooperação entre componentes. Usando componentes e conectores podemos chegar a várias configurações que foram classificadas em estilos arquitetônicos. Os estilos mais importantes para SD são: Arquiteturas em camadas Arquiteturas baseadas em objetos Arquiteturas centradas em dados Arquiteturas baseadas em eventos
Arquitetura de Sistema Arquiteturas em Camadas A ideia é que um componente na camada L i tem permissão de acessar componentes na camada L i-1, mas não o contrário. O controle flui de camada para camada: Requisições descem pela hierarquia, Resultados fluem de baixo para cima Arquiteturas baseadas em objetos Cada componente é representada por um objeto A conexão é feita por chamadas de procedimentos(remotas).
Arquitetura de Sistema Arquiteturas Centradas em Dados São aquelas cuja a ideia é de que processos se comunicam por meio de um repositório de dados comum (ativo ou passivo) Arquiteturas Baseadas em Eventos Processos se comunicam, em essência, por meio da propagação de eventos que, opcionalmente, transportam dados. No caso de sd, a propagação de eventos tem sido associada a arquiteturas centradas em dados, o que denominamos sistemas publicar/subescrever, onde processos publiquem eventos após os quais o middleware assegura que somente processos que se subescrevem a esses eventos o receberão.
Arquitetura de Sistema Arquiteturas baseadas em eventos podem ser combinadas com arquiteturas baseadas em dados, resultando no que também é conhecido como espaços compartilhados de dados.
Arquitetura de Sistema As arquiteturas de sistemas podem ser do tipo: Centralizada Cliente-Servidor Multidivididas Descentralizada Peer-to-peer estruturada Peer-to-peer não -estruturada Gerenciamento de topologia de redes de sobreposição Superpares Híbridas Sistemas de servidor de borda Sistemas distribuídos colaborativos
Arquitetura de Sistema Arquiteturas Centralizadas No modelo cliente-servidor básico, processos são divididos em 2 grupos, com possível sobreposição. Um servidor é um processo que implementa um serviço específico. Um 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. Esta interação é conhecida como comportamento de requisição - resposta.
Comunicação Arquitetura de Sistemas Arquiteturas Centralizadas Protocolo simples sem conexão com a rede subjacente O cliente requisita um serviço empacotando junto em uma mensagem os dados pertinentes e envia ao servidor O servidor sempre espera por uma mensagem, a desempacota, processa, empacota o resultado e envia a resposta. Se as mensagens não se perderem o protocolo requisição/resposta funciona bem, caso contrário a solução se torna difícil. Se o cliente não receber uma resposta enviar novamente a requisição pode trazer problemas se a requisição não for idempotente (quando pode ser enviada repetidamente). Pois o problema pode ter ocorrido na resposta.
Arquiteturas Centralizadas Protocolo confiável orientado a conexão Não é inteiramente adequada para conexões locais por ser muito lenta Funciona perfeitamente em conexões de longa distância. Praticamente todos os protocolos de aplicação da internet são baseados em conexões TCP/IP confiáveis. Quando um cliente requisita um serviço, primeiro é estabelecida uma conexão com o servidor e depois envia a requisição. Estabelecer uma conexão confiável TCP/IP é muito cara se as mensagens trocadas forem muito pequenas.
Arquiteturas Centralizadas Camadas de Aplicação Considerando que muitas aplicações clienteservidor visam a dar suporte ao acesso de usuários ao banco de dados, muitos implementam o estilo arquitetônico em camadas: Camada de Interface de usuário; Camada de processamento; e Camada de dados.
Arquiteturas Centralizadas Arquiteturas Multidivididas A distinção entre 3 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. A organização mais simples é ter dois tipos de máquinas: 1 Uma máquina cliente que contém apenas a camada de interface do usuário. 2 Uma máquina servidor que contém a camada de processamento e a camada de dados
Arquiteturas Descentralizadas Arquiteturas centralizadas, como a cliente-servidor, fazem uma distribuição vertical. Ou seja, tem seus componentes logicamente diferentes em máquinas diferentes. Em arquiteturas modernas, em muitas vezes, é a distribuição dos clientes e dos servidores que conta. O que chamamos de distribuição horizontal. Nesse tipo de distribuição, um cliente ou servidor pode ser fisicamente subdividido em partes logicamente equivalentes, mas cada parte opera sobre sua porção de dados completa.
Arquiteturas peer-to-peer Em alto nível, os processos que constituem um sistema peer-to-peer são todos iguais, ou seja, todas as funções que precisam ser realizadas estão em cada processo que constitui o sistema distribuído. Como consequência todo processo agirá como cliente e como servidor ao mesmo tempo, o que se denomina agir como servente. A maioria das interações entre processos então se tornam simétricas Esse comportamento simétrico determina que arquiteturas peer-to-peer concentram-se em como organizar os processos em uma rede de sobreposição, na qual os nós são os processos e as conexões são os canais de comunicação possíveis (geralmente conexões TCP) Como um processo não pode comunicar-se diretamente com um outro processo arbitrário, ele envia mensagens pelos canais de comunicação disponíveis.
Arquiteturas peer-to-peer Existem dois tipos de redes de sobreposição: Estruturadas; e Não Estruturadas
Arquiteturas peer-to-peer Arquiteturas peer-to-peer estruturadas A rede de sobreposição é construída de forma determinística. O procedimento mais utilizado é organizar os processos por meio de uma tabela de hash distribuída (DHT Distributed Hash-Table). No sistema DHT, os itens de dados recebem uma chave aleatória como identificador. Da mesma forma os nós do sistema também recebem uma chave aleatória. Portanto, o ponto crucial de todo sistema DHT é implementar um esquema eficiente e determinístico que mapeie exclusivamente a chave de um item de dado para o identificador de algum nó. O mais importante é que, ao consultar um item de dado, o endereço de rede do nó responsável por aquele item de dado é retornado.
Arquiteturas peer-to-peer Arquiteturas peer-to-peer não estruturada Dependem em grande parte de algoritmos aleatórios para construir um rede de sobreposição. A ideia principal é que cada nó mantenha uma lista de vizinhos mas que essa lista seja construída de modo mais ou menos aleatório. Da mesma maneira, admite-se que itens de dados sejam colocados aleatoriamente em nós. Consequentemente, uma busca por um item de dados deve inundar a rede com uma consulta de busca.
Arquiteturas peer-to-peer Uma das metas da arquitetura peer-to-peer não estruturada é construir uma rede de sobreposição parecida com um gráfico aleatório, onde o modelo básico é que cada nó mantenha uma lista com c vizinhos que, de preferência, cada um dos vizinhos represente um nó escolhido aleatoriamente no conjunto de nós vigentes no momento. A lista de vizinhos é também chamada de visão parcial. Nessa estrutura a premissa adotada é que nós troquem regularmente entradas da sua visão parcial, onde cada entrada identifica um outro nó na rede e tem uma idade associada que indica a antiguidade das referências àquele nó.
Arquiteturas Híbridas Existem classes específicas de sistemas distribuídos nas quais soluções cliente-servidor são combinadas com arquiteturas descentralizadas. Sistemas de servidor de borda Sistemas Distribuídos Coloborativos
Arquiteturas Híbridas Servidor de Borda São sistemas disponibilizados na Internet onde servidores são colocados na borda da rede. Essa 'borda' é formada pela fronteira entre a rede corporativa e a Internet. Um provedor de serviço de Internet (ISP Internet service provider) é um exemplo. Os usuários finais só acessam a Internet pelo servidor de borda, o provedor.
Arquiteturas Híbridas Sistemas Distribuídos Colaborativos Muitas vezes um sistema distribuído é disponibilizado como clienteservidor, porém, tão logo um nó se conecte na rede ele pode usar um esquema totalmente descentralizado para colaboração. Um exemplo é o sistema para compartilhamento de arquivos (download) BitTorrent. O BitTorrent é um sistema peer-to-peer que funciona da seguinte maneira: Um nó cliente solicita uma pesquisa por F, por exemplo; A solicitação chega a um Servidor Web que reporta-se a um servidor de arquivos, do tipo.torrent para F ; que Solicita a um nó rastreador, que contém uma lista de nós que armazenam F, cada nó com uma porção do arquivo, que Ordena o download a esses nós, que começam a transferência para o cliente
Arquitetura x Middleware O middleware é uma camada de software entre aplicações e plataformas distribuídas. O que se vê normalmente na prática é que sistemas de middleware seguem um estilo arquitetônico específico. Por exemplo, muitos sistemas adotaram um estilo arquitetônico baseado em objetos, como CORBA. Outros, como o TIB/Rendezvous, que proporciona um estilo baseado em eventos.
Arquitetura x Middleware Moldar o middleware de acordo com um estilo arquitetônico específico tem como benefício a simplificação do projeto de aplicações. Contudo, uma desvantagem óbvia é que o middleware pode não ser o mais ideal para aquilo que um desenvolvedor tinha em mente. Uma abordagem geral considerada melhor é fazer sistemas de middleware de modo que sejam simples de configurar, adaptar e personalizar conforme for a necessidade da aplicação.
Autogerenciamento de sistemas distribuídos SDs e em especial seu middleware associado precisam fornecer soluções gerais de blindagem contra aspectos indesejáveis inerentes à redes, de modo que possam suportar o maior número possível de aplicações. Quando a adaptação precisa ser automática, observa-se um forte intercâmbio entre arquiteturas de sistemas e arquiteturas de software.
Autogerenciamento de sistemas distribuídos A organização de sistemas distribuídos de realimentação de controle de alto nível que permitam a adaptação automática a mudanças é chamada de Computação Autonômica ou Sistemas Autos *. O último nome indica a variedade de modos de adaptação automática que estão sendo englobados: autogerenciador, auto-reparador, autoconfigurador, auto-otimizador e assim por diante.