STD29006 Sistemas Distribuídos

Transcrição

1 STD29006 Sistemas Distribuídos Comunicação II Prof. Emerson Ribeiro de Mello Instituto Federal de Santa Catarina IFSC campus São José 05 de setembro de /29

2 Revisão das aulas anteriores 2/29

3 Alguns pontos na comunicação cliente/servidor Protocolo de comunicação Podem ser definidos como acordos/regras para comunicação Podem ser orientados a conexão ou não (Ex: TCP x UDP) Modelo de comunicação cliente/servidor Servidores oferecem serviços aos clientes Paradigma pedido e resposta Implementação: Socket, RPC e RMI 2/29

4 Alguns pontos na comunicação cliente/servidor Endereçamento Como localizar o servidor? Conhecimento prévio, broadcast ou serviço de nomes Bloqueante x não bloqueante Síncrono emissor/receptor fica bloqueado até enviar/receber mensagem Assíncrono emissor não fica bloqueado e o retorno também não bloqueia Área de armazenamento temporário (buffer) - com x sem Servidor precisa ficar esperando uma mensagem antes que o cliente possa enviá-la (consumo imediato) Cliente envia para uma área de armazenamento temporário e o servidor depois consulta esta área 3/29

5 Alguns pontos na comunicação cliente/servidor Confiável x não confiável Canal não confiável: exige confirmação de todas mensagens (pedido e resposta) aplicação fica responsável Canal confiável: a resposta pode atuar como uma confirmação do pedido Comunicação confiável pode delegar para os mecanismos de transporte lidarem com mensagens perdidas Servidor concorrente x sequencial Sequencial: servidor atende um pedido por vez Concorrente: servidor dispara uma thread ou processo filho para lidar com cada pedido que chega 4/29

6 Receber (pull) ou enviar (push) Cliente: modelo pull (receber) Cliente responsável por obter dados do servidor (envia pedido) Ex: HTTP Vantagem: servidor não precisa manter estado Dificuldade: escalabilidade limitada Servidor: modelo push (enviar) Servidor envia dados para o cliente Ex: Streaming de vídeo Vantagem: mais escalável Dificuldade: servidor precisa manter estado 5/29

7 Comunicação em grupo: um para muitos Algumas características Características de um grupo estáticos ou dinâmicos abertos ou fechados Endereçamento de um grupo Multicast, broadcast Multicast na camada da aplicação (unicast) Atomicidade, ordenação de mensagens e escalabilidade 6/29

8 Objetos distribuídos e invocação de métodos remotos 7/29

9 Objetos distribuídos e invocação de métodos remotos Chamada Remota de Procedimento RPC Permite que processos locais realizem chamadas de procedimentos que estão localizados em outras máquinas 7/29

10 Objetos distribuídos e invocação de métodos remotos Chamada Remota de Procedimento RPC Permite que processos locais realizem chamadas de procedimentos que estão localizados em outras máquinas Invocação de Métodos Remotos RMI Semelhante ao RPC, porém voltado para objetos distribuídos Usufrui do paradigma da programação orientada a objetos Estende o conceito de referência de objetos para um ambiente global distribuído Objeto residente em um processo pode invocar métodos de um objeto residente em um outro processo 7/29

11 RPC vs RMI Semelhanças entre RPC e RMI Diferenças entre RCP e RMI 8/29

12 RPC vs RMI Semelhanças entre RPC e RMI Fazem uso de linguagem de descrição de interfaces (IDL) São construídos sobre protocolos pedido e resposta Oferecem o mesmo nível de transparência ao desenvolvedor Diferenças entre RCP e RMI 8/29

13 RPC vs RMI Semelhanças entre RPC e RMI Fazem uso de linguagem de descrição de interfaces (IDL) São construídos sobre protocolos pedido e resposta Oferecem o mesmo nível de transparência ao desenvolvedor Diferenças entre RCP e RMI Com o RMI o desenvolvedor poderá usufruir das facilidades da POO objetos, classes, herança,... Objetos possuem uma referência única em todo o sistema Oferece maior riqueza na semântica quando passados como parâmetros Objetos podem ser passados nos parâmetros por referência (e não somente por valor) 8/29

14 RMI Modelo orientado a objeto Atributos de objetos são acessados por meio de seus métodos Interfaces Provê a definição de um conjunto de métodos, sem no entanto prover implementação para os mesmos Arquiteturas de sistemas de objetos distribuídos Cliente e servidor um objeto ao invocar um método de um objeto distribuído resulta em enviar uma mensagem pela rede e aguardar por uma resposta Replicação Um mesmo objeto pode ser replicado em todas as máquinas do SD, trazendo benefícios de desempenho e propiciando uma tolerância a faltas 9/29

15 Modelo de objetos distribuídos Cada processo possui uma coleção de objetos, os quais estão aptos a receber invocações locais ou remotas Referência de objeto remoto um objeto só poderá invocar métodos de outros objetos que este possuir a referência Interface remota cada objeto remoto possui uma interface que especifica quais de seus métodos poderão ser invocados remotamente 208 CHAPTER 5 REMOTE INVOCATION Figure 5.13 objetos dentro de um mesmo processo poderão invocar os métodos remotos e também os locais A remote object and its remote interface remoteobject Data remote interface m1 m2 implementation { m3 of methods m4 m5 m6 10/29

16 Modelo de objetos distribuídos Coletor automático de lixo Se a linguagem permitir (p.e. Java), a coleta de lixo distribuída é possível através da interação entre os coletores locais Se a linguagem não permitir (p.e. C++), então cabe ao desenvolver se preocupar em liberar a memória de objetos remotos que não são mais usados Exceções Qualquer invocação remota poderá falhar e assim deverá disparar exceções servidor onde está objeto distribuído fica indisponível servidor está muito ocupado para responder resposta pode ser perdida 11/29

17 Implementação RMI Módulo de comunicação (no cliente e servidor) Responsável pela comunicação entre cliente e servidor Módulo de referência de objetos remotos (no cliente e servidor) Responsável por traduzir as referências entre objetos remotos e locais Proxy (no cliente) Faz com que as invocações remotas sejam transparentes para o cliente Ao receber uma inovação local, este encaminha uma mensagem para o objeto remoto Servants (no servidor) Instância da classe que provê o objeto remoto Responsável por receber as invocações remotas 12/29

18 Implementação RMI Skeleton (no servidor) Associado a uma classe de um objeto remoto é onde estão as implementações dos métodos da interface remota Atividades de empacotamento e desempacotamento acontecem aqui Dispatcher (no servidor) gure 5.15 Um servidor possui um skeleton e um dispatcher para cada classe de objeto remoto que prover. Responsável por: receber um pedido do módulo de comunicação; e invocar o método no skeleton 0 CHAPTER 5 REMOTE INVOCATION The role of proxy and skeleton in remote method invocation client object A proxy for B Request server skeleton & dispatcher for B s class remote object B Reply Remote Communication reference module module Communication module Remote reference module servant all the marshalling and unmarshalling are the concern of the RMI software, discussed 13/29

19 Implementações de modelos de objetos distribuídos CORBA Linguagem de Descrição de Interface: CORBA IDL Compilador IDL para diferentes linguagens de programação: Python, C++, Java Implementações: JacORB, R2CORBA, TAO, VBOrb, omniorb Java RMI Linguagem de Descrição de Interface: Interfaces Java Objetos remotos e programas clientes devem ser escritos em Java 14/29

20 Java RMI Serviço de registro pode ser iniciado na linha de comando: rmiregistry & ou dentro do código Java: 1 Registry registro = LocateRegistry.createRegistry(PORTA); 15/29

21 Exemplo RMI: Contador distribuído Interface Java que deve ser compartilhada pelo cliente e servidor 2 package std; 3 public interface ContadorDistribuido extends Remote{ 4 public void incrementa() throws RemoteException; 5 public int obtemvalor() throws RemoteException; 6 } Implementação da Interface pelo Servidor 7 package std; 8 public class Contador implements ContadorDistribuido{ 9 public int valor = 0; 10 public void incrementa() throws RemoteException { 11 this.valor++; 12 } 13 public int obtemvalor() throws RemoteException { 14 return this.valor; 15 } 16 } 16/29

22 Exemplo RMI: Contador distribuído Servidor 17 package std; 18 public class Servidor{ 19 public static void main(string[] args){ 20 try { 21 Contador c = new Contador(); System.setProperty("java.rmi.server.hostname","IP-do-servidor"); 24 ContadorDistribuido stub = 25 (ContadorDistribuido) UnicastRemoteObject.exportObject(c, 0); Registry registro = LocateRegistry.createRegistry(1234); 28 registro.bind("meucontador", stub); System.out.println("Servidor pronto!"); } catch (Exception e) { 33 System.err.println("erro: " + e.tostring()); 34 } 35 } 36 } 17/29

23 Exemplo RMI: Contador distribuído Cliente 37 package std; 38 public class Cliente{ 39 public static void main(string[] args){ 40 try { 41 Registry registro = 42 LocateRegistry.getRegistry("IP-servidor", 1234); 43 ContadorDistribuido stub = 44 (ContadorDistribuido) registro.lookup("meucontador"); System.out.println("valor: " + stub.obtemvalor()); 47 stub.incrementa(); 48 System.out.println("valor: " + stub.obtemvalor()); } catch (Exception e) { 51 System.err.println("erro: " + e.tostring()); 52 } 53 } 54 } 18/29

24 Comunicação por mensagens 19/29

25 Comunicação transitória por mensagens Embora RPC e RMI contribuam para esconder a comunicação no sistema distribuídos (transparência), estes assumem que ambas as partes estarão ativas no mesmo instante para permitir a comunicação 19/29

26 Comunicação transitória por mensagens Embora RPC e RMI contribuam para esconder a comunicação no sistema distribuídos (transparência), estes assumem que ambas as partes estarão ativas no mesmo instante para permitir a comunicação Server socket bind listen accept read write close Synchronization point Communication socket connect write read close Client 19/29

27 Comunicação persistente por mensagens Middleware orientado a mensagem (MOM) sistema de fila de mensagens Provê suporte a comunicação assíncrona e persistente Cliente e servidor não precisam estar ativos no mesmo instante para permitir a troca de mensagens Comunicação entre aplicações é feita por meio de filas de mensagens Mensagens podem ser roteadas por diversos servidores intermediários e eventualmente ser entregue ao destino 20/29

28 Comunicação persistente por mensagens Middleware orientado a mensagem (MOM) sistema de fila de mensagens Provê suporte a comunicação assíncrona e persistente Cliente e servidor não precisam estar ativos no mesmo instante para permitir a troca de mensagens Comunicação entre aplicações é feita por meio de filas de mensagens Mensagens podem ser roteadas por diversos servidores intermediários e eventualmente ser entregue ao destino Quando usar? Quando as partes estiverem interconectadas por meio de uma WAN, cuja probabilidade de desconexão temporária não for desprezível 20/29

29 Modelo de fila de mensagens Comunicação persistente e assíncrona desacoplamento temporal Mensagens ficam armazenadas até que o receptor possa consumi-las Emissor só tem garantia que a mensagem será eventualmente inserida na fila do receptor Quando a mensagem será consumida ou se será consumida, isto depende do comportamento do receptor Sender running Sender running Sender passive Sender passive Receiver running Receiver passive Receiver running Receiver passive (a) (b) (c) (d) 21/29

30 Interface básica para sistemas de filas de mensagens PUT Colocar uma mensagem em uma fila GET Se a fila estiver vazia ficará bloqueada até chegar mensagem. Remove a primeira mensagem que estiver na fila POLL Verificar se existe mensagem em uma fila específica e remover a primeira. Neste caso, não fica bloqueado NOTIFY Definir uma função que será invocada sempre que uma mensagem for inserida na fila 22/29

31 Arquitetura básica de um sistema de filas de mensagens Cada fila possui um identificador único em todo o sistema distribuído e as mensagens são destinadas para uma fila Filas são distribuídas por diversas máquinas Identificar cada fila implica em fazer um mapeamento para endereços de rede e portas Cada máquina oferece uma interface para o envio e recepção de mensagens Máquinas clientes podem estar ligadas a uma ou mais máquinas servidoras responsáveis pelo encaminhamentos de mensagens (roteamento) 23/29

32 Organização de um sistema de filas de mensagens com roteadores Sender A Application Receive queue Send queue Message R2 Application Application R1 Application Router Receiver B 24/29

33 Java Message Service JMS API que permite a criação, envio, recebimento e leitura de mensagens de forma confiável, assíncrona e com baixo acoplamento temporal Uma aplicação JMS é composta por Clientes enviam e recebem mensagens Mensagens informações a serem trocadas Objetos administrados objetos para serem usados pelos clientes Provedor é o sistema de mensagens com funções de administração e controle da aplicação Modos de operação ponto a ponto publish/subscribe 25/29

34 Modo Ponto a Ponto Mensagens são mantidas nas filas até que alguém as consuma ou até que expirem Cada mensagem possui um único consumidor 26/29

35 Modo publish/subscribe Produtores e consumidores podem publicar e assinar tópicos Quando uma mensagem é publicada em um determinado tópico, o JMS distribui esta mensagem para todos os assinantes A mensagens ficam retidas nos tópicos até serem entregues a todos os assinantes 27/29

36 Outras implementações de comunicações por mensagens Advanced Message Queuing Protocol AMQP Padrão aberto para middleware orientado à mensagens enfileiramento, roteamento ponto-a-ponto ou pub-sub, confiabilidade e segurança Apache ActiveMQ Apache Qpid RabbitMQ ZeroMQ Message Queue Telemetry Transport MQTT Padrão ISO baseado em uma versão leve do publish-subscribe para ser usado sobre TCP/IP ambientes que exigem código pequeno & taxa de transmissão baixa Mosquitto 28/29

37 Exercícios 1 Java RMI Executar o exemplo disponível em 2 RabbitMQ & Java Executar os exemplos disponíveis em 29/29