SD

Sistemas Distribuídos

Objetivos da Cadeira

• Unidade curricular obrigatória de introdução aos sistemas distribuídos.
• Introduz modelos, métodos e técnicas para desenvolvimento de sistemas distribuídos seguros.
• Alunos devem compreender:
  • Características essenciais
  • Modelos e arquiteturas dos sistemas
  • Técnicas de concepção
• Componente prática: desenvolver um sistema distribuído seguro e tolerante a falhas utilizando REST, gRPC, e OAuth.

Programa das Aulas Teóricas

1. Introdução (cap. 1)
2. Arquiteturas e modelos (cap. 2)
3. Sistemas de comunicação direta (cap. 4.1-4.3, 6.4)
4. Invocação remota (cap. 5, 4.3)
5. Invocação remota na Internet (cap. 9)
6. Avaliação de sistemas distribuídos
7. Tempo e ordenação de eventos (cap. 6.1-6.3, 15.4)
8. Introdução à replicação (cap. 12.1-12.4, 15.3, 18.4)
9. Sistemas de comunicação indireta (cap. 6.1-6.3, 15.4)
10. Segurança (cap. 11.1-11.4, 11.6)
11. Sistemas de Nomes (cap. 13)

• Tópicos avançados serão abordados em disciplinas de mestrado: Cloud Computing, Distributed Algorithms, Reliable Systems.

Programa das Aulas Práticas

• Pressupostos:
  • Conhecimento de primitivas de comunicação TCP/IP (java.net)
  • Web services REST
  • Invocação remota gRPC
• Tolerância a falhas nestes sistemas
  • REST + gRPC sobre TLS
  • REST + Oauth
• Soluções de replicação

Planeamento (Datas a Confirmar)

• Apresentação & Introdução: 10-11 Mar
• Arquiteturas: 17-18 Mar
• Comunicação Direta: 24-25 Mar
• Aula de Dúvidas: 31 Mar - 1 Abr
• Invocação Remota: 7-8 Abr
• Web Services: 14-15 Abr
• Páscoa: 22 Abr
• Suporte Trabalho: 28-29 Abr
• Tempo: 5-6 Mai
• Replicação: 12-13 Mai
• Comunicação Indireta: 19-20 Mai
• Segurança: 26-27 Mai
• Segurança: 2-3 Jun
• Trabalho: 26 Abr, 4 Jun
• Teste: 3 Mai (9h30/11h30), 9 Jun
• Práticas:
  • Docker+Descoberta
  • Web services REST
  • DB + Falhas
  • Web services gRPC
  • REST+Oauth
  • REST/SOAP + TLS
  • KAFKA + Replicação

Funcionamento das Aulas

• Aulas Teóricas:
  • Slides no CLIP (documentação -> multimédia)
• Aulas Práticas:
  • Materiais no CLIP (Slides: documentação -> multimédia)
  • Código base para aulas: documentação -> problemas

Outros Recursos

• CLIP
  • Informação acadêmica, regras, etc.
• Discord
  • Dúvidas gerais
  • Formar grupos
  • Discussões gerais

Software

• Java
• Maven
• Docker

Bibliografia

• Principal:
  • M. van Steen e A.S. Tanenbaum, Distributed Systems, 4th ed., distributed-systems.net, 2023.
    • Link: https://www.distributed-systems.net/index.php/books/ds4/
  • George Coulouris, Jean Dollimore, Tim Kindberg e Gordon Blair, “Distributed Systems - Concepts and Design,” Addison-Wesley, 5th Edition, 2011

Avaliação – Parte Prática

• Frequência:
  • Nota de frequência >= 9.0 valores
  • Nota de frequência base = 50% * trab-fase 1 + 50% * trab-fase 2
• Discussão obrigatória (presencial e individual) para alunos selecionados:
  • Alterações ao código para resolver uma variante do problema original
  • Notas da discussão:
    • 20: Alterações corretas
    • 16: Alterações confusas ou incompletas
    • 12: Alterações parcialmente corretas
    • 4: Nenhuma alteração ou alterações sem sentido
  • Nota de frequência = min(nota de frequência base, nota de discussão)
• Trabalhos práticos em grupos de 2 alunos (preferencialmente do mesmo turno).

Avaliação – Trabalhos Práticos (2)

• Definição no enunciado de cada fase:
  • Funcionalidades mínimas
  • Funcionalidades opcionais e sua valorização
• Bateria de testes fornecida.
• Alunos que não compareçam à discussão sem justificação perdem a frequência.
• Uso de ferramentas de IA generativa é permitido (informar como foi utilizado).
• Testes teóricos/exame cobrem também a parte prática.

Avaliação

• Componentes: teste 1 (30%), teste 2 (30%), freq (40%)
  • Todas as notas intermédias aproximadas às décimas.
  • Média(teste 1, teste 2) >= 9,5
• Nota com exame: exame (60%), freq (40%)
  • exame >= 9,0
• Melhorias de nota ou alunos com frequência positiva:
  • A nota de frequência obtida é válida e será usada no cálculo da nota final, substituindo a nota dos trabalhos.
• Testes e exames sem consulta.

Equipa Docente e Horários de Atendimento

• João Leitão (Teóricas & 1 Turno Prático):
  • Segunda-Feira 10am-11am (P2.41 ou P2.7)
  • Terça-Feira 5pm-6pm (P2.41 ou P2.7)
  • Quinta-Feira 6pm-7pm (P2.41 ou P2.7)
• Sérgio Duarte (4 Turnos Práticos):
  • Terça-Feira 10am-11am (P3.1)
  • Sexta-Feira 6pm-8pm (zoom, link no clip)
• Pedro Componês (2 Turnos Práticos):
  • Terça-Feira 6pm-7pm (Lab 121-A)
  • Quinta-Feira 6pm-8pm (zoom: TBA)

Dúvidas sobre Funcionamento de SD

Aula 1: Introdução aos Sistemas Distribuídos

• Apresentação baseada no livro:
  • G. Coulouris, J. Dollimore and T. Kindberg, Distributed Systems - Concepts and Design, Addison-Wesley, 5th Edition, 2011

Organização do Capítulo

• Definição, exemplos
• Características essenciais dos sistemas distribuídos.
• Desafios Principais:
  • Heterogeneidade
  • Abertura
  • Segurança
  • Escala
  • Falhas
  • Concorrência
  • Transparência

Sistemas Distribuídos: Exemplos

• Serviços web – redes sociais, e-commerce, jogo multi-utilizador, etc.
• Email
• Multibanco
• Etc.
• Essencial num sistema distribuído:
  • Conjunto de nós / máquinas
  • Rede de comunicações para troca de mensagens

O Que É Um Sistema Distribuído?

• Conjunto de componentes hardware e software interligados por uma infraestrutura de comunicações.
• Cooperam e coordenam-se pela troca de mensagens para executar aplicações distribuídas.
• Não inclui sistemas que cooperam por partilha de memória física comum ou programas em GPUs.

Exemplo: Serviços na Internet

• Web (HTTP), E-mail (SMTP), Audio/video-conf (e.g., Zoom, Skype), streaming (e.g., Netflix), multi-player games (e.g., Pokémon Go) etc.

Exemplo: Cloud Computing

• Serviços disponibilizados através de infraestrutura distribuída globalmente.
  • IaaS (Infrastructure as a Service): AWS EC2 (máquinas virtuais)
  • PaaS (Platform as a Service): Google App Engine
  • SaaS (Software as a Service): Google Docs

Cloud Computing: Algumas Tendências

• Crescimento do mercado de infraestrutura de cloud IT.
• Aumento das receitas da Microsoft com serviços de cloud.
• Crescimento do mercado de nuvem pública em relação à nuvem privada.

Exemplo: Facebook/Meta

• Utilização de diversas tecnologias para processamento de dados, armazenamento e monitorização.

Exemplo: Facebook Haystack

• Arquitetura para armazenamento e distribuição de fotos.

Exemplo: Netflix

• Utilização de micro serviços, filas de mensagens e outras tecnologias para streaming de vídeo.

Exemplo: Serviços em Intranets

• Serviços da Internet + impressão, sistemas de ficheiros, etc.

Outros Exemplos: Carros

• Dispositivos controlados por computadores embebidos.

Outros Exemplos

• Sistemas de controlo de processos industriais.
• Clusters de computadores para cálculo paralelo.

Porque Dominar Sistemas Distribuídos?

• Estão em todo o lado.
  • Entretenimento, serviços sociais, produtividade, colaboração, AI, etc.
• Mercado em expansão com necessidade de engenheiros qualificados.
• Inovação constante no domínio de Sistemas Distribuídos.
• Competências valorizadas no mercado.

Aula 2

Na Aula 1

• O que é um sistema distribuído
  • Conjunto de componentes hardware e software interligados por uma infraestrutura de comunicações, que cooperam e se coordenam entre si apenas pela troca de mensagens, para execução de aplicações distribuídas
• Exemplos de sistemas distribuídos
  • Serviços na Internet, cloud computing
  • Sistemas de controlo (e.g. fábricas)
  • Sistemas embebidos e de tempo-real (e.g. carros, aviões)

Nesta Aula

• Características essenciais dos sistemas distribuídos
• Desafios na conceção de sistemas distribuídos

Motivações dos Sistemas Distribuídos

• Acesso generalizado sem restrições de localização.
  • Acessibilidade ubíqua (suporte para utilizadores fixos, móveis)
• Partilha dos recursos distribuídos pelos diferentes utilizadores.
  • Exemplos: impressores, ficheiros
• Distribuição da carga – melhoria do desempenho
• Tolerância a falhas – melhoria da disponibilidade
• Flexibilidade e adaptabilidade.
  • Decomposição de um sistema complexo num conjunto de sistemas mais simples

Características Fundamentais

• Componentes do sistema executam de forma concorrente – paralelismo real.
  • Necessidade de coordenação entre os vários componentes
• Falhas independentes das componentes e das comunicações.
  • Impossível determinar se existe uma falha dum componente ou do sistema de comunicações
  • Necessidade de tratar as falhas
• Ausência de relógio global – existem limites para a precisão da sincronização dos relógios locais.
  • Impossível usar relógios locais para ordenar globalmente todos os eventos

Implicações

• Nenhum componente tem uma visão exata instantânea do estado global de todo o sistema.
• Os componentes têm uma visão parcial do estado global do sistema.
  • Os componentes do sistemas estão distribuídos e só podem cooperar através da troca de mensagens, as quais levam um tempo não nulo a propagarem-se
• Na presença de falhas, o estado global pode tornar-se incoerente, i.e., as visões parciais do estado global podem tornar-se incoerentes.
  • Por exemplo, réplicas de um objeto podem ficar incoerentes

Desafios

• Heterogeneidade
• Abertura
• Transparência
• Segurança
• Escala
• Tratamento das falhas

Heterogeneidade

• Hardware: smartphones, tablets, portáteis, servidores, clusters, …
  • Diferentes características dos processadores, da memória, da representação dos dados, dos códigos de caracteres,…
• Redes de interligação e protocolos de transporte: Redes móveis (5G, 4G, 3G, GSM), WLANs, wired LANs,…, TCP/IP, ….
• Sistema de operação: Windows, MacOS, iOS, Android,…
  • Diferentes interfaces para as mesmas funcionalidades
• Linguagens de programação…
• Lidar com esta heterogeneidade é muito complexo
• As seguintes soluções podem ajudar:
  • Sistemas de Middleware
  • Máquinas Virtuais
  • Containers

Middleware

• Sistema middleware Interface homogénea
• Serviços mais complexos (invocação remota: Web-services; message-queue: *MQ, etc)
• Verdadeira interoperabilidade requer idênticos interface e protocolos

Máquina Virtual

• Objetivo: permitir executar os mesmos programas em máquinas com diferentes características
• Máquina virtual aplicação: virtualiza ambiente de execução independentemente do sistema de operação
  • E.g.: programas escritos numa única linguagem (JavaVM) ou em múltiplas linguagens (Microsoft CLR)
• Máquina virtual sistema: virtualiza máquina física
  • E.g.: VmWare, VirtualBox, etc.

Container

• Objetivo: permitir executar aplicações, incluindo todas as suas dependências

Container (Cont.)

• Um container utiliza o sistema operativo subjacente do sistema (ou VM) onde está a ser executado…
  • O sistema operativo é partilhado entre todos os containers em execução.
• Mas os containers estão isolados uns dos outros com recursos exclusivos atribuídos, incluindo CPU, memória, rede, disco, etc.
• Isto faz com que um container funcione como uma máquina independente, com o seu próprio IP.

Abertura

• Abertura de um sistema indica como pode ser estendido e re-implementado.
• Sistemas abertos:
  • Interfaces e modelo (incluindo protocolos de comunicação) conhecidos
  • Evolução controlada por organismos de normalização independentes ou consórcios industriais
  • Permite a interoperação de componentes com diferentes implementações
• Sistemas proprietários:
  • Podem ser modificados pelo seu “dono”

Abertura e Open-Source

• Aplicação de código aberto (open source): código fonte disponível.
• Utilização regida por uma licença (tipicamente distribuída com o código).
• Tipos de licença:
  • Public domain – todos os direitos são transferidos.
  • Permissive licence (e.g. MIT, Apache) – oferece direito de utilização (incluindo relicenciar código derivado).
  • Copyleft (e.g. GPL) – oferece direito de utilização, proíbe tornar código proprietário (pode obrigar que todo o código que usa a aplicação tenha a mesma licença).
  • Noncommercial licence – oferece direito de utilização para utilização não comercial.
  • Proprietary licence – oferece direito de utilização em troca dum pagamento (utilização normal do copyright).

Transparência

• Propriedade relativa a esconder ao utilizador e ao programador das aplicações a separação física dos elementos que compõem um sistema distribuído.
• Simplicidade e flexibilidade são objetivos
• Em certas circunstâncias, a transparência total é indesejável.
• Que fazer em caso de falha?

Segurança

• Necessidade de proteger os recursos e informação gerida num sistema distribuído.
  • Recursos têm valor para os seus utilizadores
• Segurança tem três componentes:
  • Confidencialidade: indivíduos não autorizados não podem obter informação
  • Integridade: dados não podem ser alterados ou corrompidos
  • Disponibilidade: acesso aos dados deve continuar disponível
• Aspetos envolvidos
  • Autenticação dos parceiros
  • Canais seguros
  • Prevenção de ataques de “negação de serviço” (denial of service attacks)

Segurança - RGPD

• O Regulamento Geral sobre a Proteção de Dados (RGPD) (UE) 2016/679 regula a privacidade e proteção de dados pessoais, aplicável a todos os indivíduos na UE e Espaço Económico Europeu (EEU).
• É aplicável a todas as empresas que operem no Espaço Económico Europeu, independentemente do seu país de origem.
• Pretende garantir que:
  • Não se podem guardar e disponibilizar dados sem consentimento explícito;
  • Os dados guardados não podem ser utilizados sem que o proprietário tenha dado consentimento explícito;
  • O proprietário tem o direito de revogar as permissões em qualquer momento.

Escala

• A escala de um sistema distribuído é o âmbito que o mesmo abrange assim como o número de componentes.
• A escala de um sistema tem várias facetas:
  • recursos e utilizadores
  • âmbito geográfico (rede local, país, mundo, …)
  • âmbito administrativo (uma organização, inter-organizações)
• Um sistema capaz de escalar (escalável) é um sistema que continua eficaz quando há um aumento significativo do número de recursos e utilizadores
  • i.e., em que não é necessário alterar a implementação dos componentes e da forma de interacção dos mesmos

Como Lidar com a Escala?

• Para reduzir o número de pedidos tratados por cada componente
  • Divisão de um componente em partes e sua distribuição
  • Replicação e caching (problema da consistência entre réplicas e caches)
• Para reduzir o tempo de acesso de clientes distribuídos geograficamente?
  • Geo-replicação – replicar as aplicações (e dados) em diferentes locais geográficos
  • Replicação na edge – replicar as aplicações ou dados na periferia da rede (e.g. CDN)

Como Lidar com a Escala?

• Para reduzir dependências entre componentes
  • Meios de comunicação assíncronos
• Para simplificar o sistema
  • Uniformidade de acesso aos recursos e dos mecanismos de cooperação, sincronização, etc.
  • Meios de designação universais (independentes da localização e dos recursos)

Avarias, Erros e Falhas

• Os componentes de um sistema podem falhar, i.e., comportar-se de forma não prevista e não de acordo com a especificação devido a erros (por exemplo a presença de ruído num canal de comunicação ou um erro de software) ou avarias (mecanismo que que entra em mau funcionamento)
• Num sistema distribuído, as falhas são geralmente parciais (num componente do sistema) e independentes
  • Um componente em falha pode induzir uma mudança de estado incorreta noutro componente, levando eventualmente o sistema a falhar, i.e., a ter um comportamento não de acordo com a sua especificação.

Como Lidar com as Falhas

• Detetar falhas
  • Possível: e.g.: mensagens corrompidas através de checksums
  • Pode ser impossível: Falha (crash) num computador remoto
  • Desafio: Funcionar através da suspeição das falhas
• Mascarar falhas (após a sua detecção)
  • Exemplos: retransmissão de mensagens, redundância
• Tolerar falhas
  • Definição do comportamento na presença de falhas
  • Parar até falhas serem resolvidas; recorrer a componentes redundantes para continuar a funcionar
• Recuperação de falhas
  • Mesmo num sistema que tolere falhas é necessário recuperar os componentes falhados. Porquê?
  • Problema: recuperar estado do serviço

Para Saber Mais

• G. Coulouris, J. Dollimore and T. Kindberg, Distributed Systems – Concepts and Design, Addison-Wesley, 5th Edition, 2011
  • Capítulo 1.

Aula 3: Capítulo 3 Comunicação Direta

Nota Prévia

• Apresentação semelhante e utiliza figuras do livro de base:
  • G. Coulouris, J. Dollimore and T. Kindberg, Distributed Systems - Concepts and Design, Addison-Wesley, 4th Edition, 2005

Comunicação Num Sistema Distribuído

• Sistemas de comunicação de base
• Sistemas de comunicação middleware
• Applications, services. Computer and network hardware. Platform Operating system Middleware

Sistemas de Comunicação de Base

• Sistemas de operação podem suportar comunicação de dados entre computadores num sistema distribuído.
• Protocolos populares:
  • TPC/IP
  • HTTP

TCP/IP: UDP

• Comunicação por mensagens. Mensagens podem-se perder, duplicar e chegar fora de ordem.
• Código Java para enviar e receber mensagens UDP.

TCP/IP: IP Multicast

• Comunicação por mensagens com múltiplos recetores. Cliente envia mensagem para endereço do grupo. Qualquer processo se pode juntar ao grupo para receber mensagens.
• Mensagens podem-se perder, duplicar e chegar fora de ordem.
• Exemplo de código Java para multicast.

TCP/IP: TCP

• Dados transmitidos como fluxo contínuo. Dados chegam de forma confiável a menos que o stream seja quebrado.
• Exemplo de código Java para comunicação TCP.

HTTP

• Comunicação pedido/resposta sobre TCP, invocando URL. Dados chegam de forma confiável a menos que o stream seja quebrado.
• Exemplo de código Java para HTTP.

HTTP Assíncrono

• Comunicação pedido/resposta, com resposta a ser recebida de forma assíncrona.
  • Qual o interesse?
• Solução adotada nos browser: JavaScript nativo ou bibliotecas JavaScript (e.g. Jquery)
• Exemplo de como fazer chamadas assíncronas em JavaScript. "readyState" indica o estado da resposta (se já foi enviada a resposta, se está a processar…).

Web Sockets

• Comunicação full-duplex sobre TCP entre clientes e servidores Web.
  • Permite notificações dos servidores, streaming.
  • Suporte generalizado nos browsers.
• Exemplo de código JavaScript para Web Sockets.

HTTP/3 E QUIC

• A combinação HTTP/TLS/TCP tem alguns problemas:
  • Criação de conexões lenta – handshake TCP + TLS;
  • TCP slow start;
  • Caso haja um erro na propagação dum pacote, esse erro tem impacto na conexão – se uma conexão estiver a ser usada para propagar vários streams (como e.g. quando se vão buscar múltiplas imagens duma página web), todos são afetados.

QUIC

• QUIC é um novo protocolo de transporte, contruído usando UDP, com suporte para múltiplos fluxos (streams) dentro da mesma conexão; integração com TLS; rápido início de conexão.

HTTP/3

• HTTP/3 é a nova versão do HTTP, que integra diretamente com o QUIC.
• Suportado pelos browsers mais usados.

Comunicação no Nível Middleware

• Implementa sistema de comunicação recorrendo às primitivas de comunicação base.
• Fornece propriedades adicionais, atrasando a entrega das mensagens
  • Definição: Entrega de uma mensagem num sistema de comunicação representa a ação do sistema disponibilizar a mensagem para ser lida (i.e., observada) pelas aplicações
  • Porque é que pode ser útil atrasar a entrega de uma mensagem?
  • Atrasar a entrega de uma mensagem pode, por exemplo, permitir que a ordem de entrega das mensagens seja diferente da ordem de chegada.

Facetas da Comunicação

• Forma da interação: Streams; Mensagens. Ordem das mensagens
• Número de destinatários: Ponto-a-ponto; Multi-ponto (estudado mais tarde); Um-de-muitos (anycast)
• Direção de interação: Uni-direcional; Bi-direcional
• Tipo de sincronização: Comunicação síncrona; Comunicação assíncrona
• Persistência: Comunicação persistente; Comunicação volátil
• Fiabilidade (modelo de falhas)

Forma de Interação: Streams

• Emissor e recetor estabelecem um fluxo contínuo de dados
• Ordem dos dados enviados é mantida; Fronteira das escritas dos dados não é preservada.
• Exemplos de situações em que é apropriado?
• NOTA: poderíamos implementar sobre UDP… QUIC faz isso.

Forma de Interação: Mensagens

• Emissor e recetor comunicam trocando mensagens
• Cada mensagem tem um limite (e dimensão) bem-definida.
• Exemplos de situações em que é apropriado?
• Como implementar sobre TCP?

Forma de Interação: Mensagens (Cont.)

• Emissor e recetor comunicam trocando mensagens
• Cada mensagem tem um limite (e dimensão) bem-definida.
• Exemplos de situações em que é apropriado?
• Como implementar sobre TCP?
  • vantagens? desvantagens de cada opção?

Forma de Interação: Ordenação das Mensagens

• Sem garantias de ordem
  • Sistema não garante que as mensagens são entregues pela ordem que foram enviadas
• Entrega pela mesma ordem da emissão – FIFO (first in first out)
  • Sistema garante que as mensagens dum emissor são entregues pela mesma ordem que foram enviadas.
  • Como implementar em TCP/UDP?
  • Haverá outras garantias de ordem?

Número de Destinatários

• Comunicação ponto-a-ponto
  • Comunicação entre um emissor e um recetor
• Comunicação multi-ponto
  • Comunicação entre um emissor e um conjunto de recetores
  • Broadcast: envio de 1 emissor para todos os recetores
  • Multicast: envio de 1 emissor para todos os recetors de um grupo
  • Anycast: envio de 1 emissor para um recetor de um grupo

Direção de Interação

• Comunicação uni-direccional:
  • Comunicação apenas num sentido: emissor->recetor
• Comunicação bi-direccional:
  • Comunicação nos dois sentidos

Sincronização

• Comunicação assíncrona:
  • o emissor só fica bloqueado até o seu pedido de envio ser tomado em consideração
  • o recetor fica bloqueado até ser possível receber dados
  • Em geral, o sistema de comunicação do receptor armazena (algumas) mensagens caso não exista nenhum recetor bloqueado no momento da sua recepção. Assim, funciona como um buffer entre o emissor e o recetor
  • É possível variante em que o recetor não fica bloqueado e devolve erro ou a receção é efectuada em background
• Comunicação síncrona:
  • o emissor fica bloqueado até:
    • o recetor “receber” os dados – comunicação síncrona unidireccional
    • receber a resposta do receptor – comunicação pedido / resposta ou cliente / servidor
  • o receptor fica bloqueado até ser possível consumir dados

Persistência

• Comunicação volátil: mensagens apenas são encaminhadas se o recetor existir e estiver a executar, caso contrário são destruídas.
  • Exemplo: ???
• Comunicação persistente: mensagens são guardadas pelo sistema de comunicação até serem consumidas pelos destinatários, que podem não estar a executar.
  • Mensagens são guardadas num receptáculo independente do recetor – mailbox, canal, porta persistente, etc.
  • Exemplo: ???

Fiabilidade

• Comunicação fiável: o sistema garante a entrega das mensagens em caso de falha temporária.
  • Como implementar?
• Comunicação não-fiável: em caso de falha, as mensagens podem-se perder

Para Saber Mais

• George Coulouris, Jean Dollimore, Tim Kindberg and Gordon Blair,
  • Distributed Systems – Concepts and Design, Addison-Wesley, 5th Edition, 2011
  • Capítulo 4.1-4.3.

Aula 4: Capítulo 4 Invocação Remota

• Apresentação semelhante e utiliza figuras do livro de base:
  • G. Coulouris, J. Dollimore and T. Kindberg, Distributed Systems - Concepts and Design, Addison-Wesley, 5th Edition, 2009
• Para saber mais:
  • RMI/RPCs - capítulo 5.
  • Representação de dados e protocolos - capítulo 4.3.
  • Web services – capítulo 9

Na Última Aula

• Mecanismos de comunicação base
  • TCP, UDP, IP multicast
  • HTTP assíncrono, Web sockets
• Propriedade dos sistemas de comunicação
  • Forma da interação: streams, mensagens
  • Número de destinatários: ponto-a-ponto, multi-ponto, um-de-muitos
  • Direção de interação: uni-directional, bi-direcional
  • Tipo de sincronização: comunicação síncrona, comunicação assíncrona
  • Persistência: comunicação persistente, comunicação volátil
  • Fiabilidade: fiável, não fiável

Motivação

• Estruturar uma aplicação distribuída com base nas mensagens trocadas pelos seus componentes é a abordagem mais óbvia, mas:
  • exige atenção a muitos detalhes de baixo nível; a estrutura dos programas espelha os padrões de comunicação, em vez da lógica da aplicação no seu todo.
  • em particular, os servidores ficam estruturados em função das mensagens que sabem tratar.

Problemas

• De aplicação para aplicação, verifica-se que muitas linhas de código são repetitivas, não contêm nenhum significado aplicacional específico e referem-se apenas à gestão e processamento das comunicações.
• Em particular, boa parte do código está dedicado a:
  • criação de communication end points e sua associação aos processos criação, preenchimento e interpretação das mensagens;
  • seleção do código a executar consoante o tipo da mensagem recebida gestão de temporizadores/tratamento das falhas

Objetivo

• Não será possível automatizar aquilo que é repetitivo?
• Não será possível que o programador apenas especifique o código aplicacional?

Invocação Remota

• Nas linguagem imperativas definem-se funções / procedimentos / métodos para executar uma dada operação.
• Num ambiente distribuído, uma extensão natural consiste em permitir que a execução ocorra noutra máquina.
• Invocação Remota de Procedimentos (RPCs), quando são executados funções/procedimentos remotamente.
  • gRPC (https://grpc.io/), ONC/RPC, DCE
• Invocação Remota de Métodos (RMI), quando são executados métodos de objetos remotos.
  • JAVA RMI, .NET Remoting, Corba.
  • Web Services (REST e SOAP)

Invocação de Procedimentos Remotos (RPCs)

• Modelo Servidor exporta interface com operações que sabe executar Cliente invoca operações que são executadas remotamente e (normalmente) aguarda pelo resultado a executar tempo, cliente, Servidor.

Invocação Remota - Propriedades

• Extensão natural do paradigma imperativo/procedimental a um ambiente distribuído