SISTEMAS DISTRIBUDOS Comunicao interprocessos RPC e RMI Bacharelado
SISTEMAS DISTRIBUÍDOS Comunicação inter-processos RPC e RMI Bacharelado em Ciência da Computação IFCE - Campus Aracati - Semestre 2018. 1 Prof. Érica Gallindo - erica. gallindo@ifce. edu. br
Assuntos Abordados 1. Conceitos Básicos a. b. c. d. Troca de mensagens (message passing) Invocação remota de procedimentos Invocação remota de métodos Semântica de invocação remota 2. Implementações de RMI/RPC 1. RPC 2. RMI 3. CORBA
Modelos de invocação de operações remotas Procedural Chamada de funções ⇒ chamada remota de funções (RPC) Orientado a objetos Invocação de métodos ⇒ invocação remota de métodos (RMI)
RPC Remote Procedure Call
Troca de Mensagens (Message Passing ) É uma forma de comunicação simples e antiga utilizada em sistemas distribuídos. Neste modelo, o emissor empacota dados (mensagem) e a envia ao receptor que a decodifica para tomar alguma ação. O formato da mensagem e a maneira como ela será processada pelo receptor são dependentes da aplicação. Em algumas aplicações o receptor pode responder enviando uma mensagem de volta; em outros casos pode não haver respostas. As mensagens contém apenas dados e não são padrão – tipicamente apenas o emissor e o receptor conhecem sua representação. Há ainda problemas relacionados a diferenças de representação dos dados nos computadores envolvidos (ex: big-endian x littleendian) que dificulta a interoperabilidade entre plataformas. Por fim, o reuso de componentes de um sistema distribuído em outro fica comprometido pela ausência de uma biblioteca comum – tudo é feito “na mão”.
RPC (Remote Procedure Calls ) RPC prove um mecanismo mais uniforme, reutilizável e amigável de comunicação entre processos. A comunicação vai além trocas independentes de dados Em programação tradicional, o serviço de um sistema é decomposto em procedimentos que recebem informações, executam alguma operação e devolve algum resultado. A abstração RPC estende estes paradigma aos sistemas distribuídos Um sistema provê RPC para que outros sistemas utilizem Do ponto de vista das aplicações, as chamadas remotas podem ser usadas de forma similar às locais O mecanismo de RPC conecta ao host remoto, envia os parâmetros, executa a operação no host remoto e retorna os resultados.
RPC (Remote Procedure Calls ) Similar ao message passing A invocação da função remota é uma mensagem do cliente para o servidor A mensagem envia contém a função e os parâmetros a serem executados Depois de receber a mensagem, o servidor executa a operação e envia uma mensagem de volta ao cliente com o resultado O cliente trata o resultado da mesma forma que trataria o retorno de um procedimento local
Principais Características da RPC Provê uma interface familiar para o desenvolvedor da aplicação Uso de linguagens de definição de interfaces (IDLs); IDLs são projetadas para permitir que procedimentos implementados em diferentes linguagens invoquem uns aos outros; Ex: OMG IDL, WSDL, JSON O formato das mensagens é padrão; não depende da aplicação Torna fácil o reuso de código, visto que possuem uma interface padrão Simplifica a comunicação entre processos, ocultando detalhes de implementação
Principais Características da RPC Simplifica a comunicação entre processos, ocultando detalhes de implementação Objetivo Básico do RPC: Chamada Local = Chamada Remota; Uma série de ações transparentes ao Programador (empacotar/desempacotar, trocas de mensagens, etc); Transparência de localização e de acesso, ocultando o local físico do procedimento; Perigoso: chamadas de procedimentos remotos são mais vulneráveis a falhas (envolvem rede, outro computador, outro processo);
Marshalling e Stubs O processo de preparer e empacotar a informação para transmissão é conhecida como marshaling Com frequencia isso envolve traduzir representações em uma forma canônia. Ex: A implementação de RPC da Sun usa um conjunto de convencições conhecida como e. Xternal Data Representation (XDR). Para ocultar este processo do programador, ele é implementado usando stubs automaticamente gerados. O programador desenvolve a interface para a RPC O gerador de stub pega esta definição de interface e cria stubs cliente e servidor Os stubs cuidam do marshaling e unmarshaling dos parâmetros como também da comunicação e das invocações de procedimentos. O programador pode então construir as RPCs e a aplicação.
Marshalling e Stubs
RPC e falhas Os modos de falhas de RPCs são distintos daqueles das chamadas a funções locais As falhas ocorrem com frequência usando RPCs; diferente do que ocorre nos sistemas convencionais Em um sistema distribuído, a comunicação com a RPC pode falhar. A resposta do servidor RPC pode falhar. O servidor pode falhar. O cliente pode falhar.
RPC e falhas
RPC e falhas Estes modos de falhas levam a diferentes semânticas de falha para RPCs: exactly once – a RPC executará exatamente uma vez – nem mais, nem menos. Cara de ser implementada at most once – se tudo correu bem, ótimo. Se não, não é um grande problema. A operação nunca é repetida at least once -- se tudo correu bem, ótimo. Se não, mantem-se repetindo a operação. A operação é repetida mesmo havendo o risco de já ter sido executada (Ex: lost ACK) idempotente – A operação que pode ser repetida sem problemas.
Semântica de Falha – Exactly once Ao receber uma resposta, o invocador tem certeza que o método remoto foi executado somente uma vez Ao receber exceção (resposta não chegou, logo timeout), o invocador não saberá se o método foi executado ou não, pois: Falha do servidor Request chega, mas servidor cai antes ou durante a execução do método Request chega, servidor executa o método e falha em seguida Falha no canal de comunicação Request não chega no servidor Resposta não chega: servidor executa o método, envia resposta, mas resposta não chega no cliente ou chega depois do timeout
Semântica de Falha – At Most Once Ao receber uma resposta, o invocador sabe que o método remoto foi executado ao menos uma vez, pois: Falha do canal de comunicação Request chega, servidor executa o método e envia resposta. Resposta não chega, request é retransmitido Servidor executa o método e envia resposta, . . . até que a resposta chegue! (1 ou +) Ao receber exceção, o invocador não saberá se o método foi executado ou não, pois: Falha do servidor Request chega, mas servidor cai antes ou durante a execução do método, retransmissões do request, . . . , exceção! Request chega, servidor executa o método e falha em seguida, retransmissões do request, . . . , exceção! Falha no canal de comunicação Request não chega no servidor, retransmissões do request, . . . , exceção! (0) Resposta não chega: servidor executa o método, envia resposta, mas resposta não chega no cliente, retransmissão do request, servidor executa método, envia resposta, mas resposta não chega. . . exceção! (1 ou +)
Semântica de Falha – At Least Once Ao receber uma resposta, o invocador sabe que o método foi executado uma só vez, pois: Falha do canal de comunicação Request chega no servidor Servidor executa o método Servidor envia resposta. Resposta não chega. . . Retransmissão do request Servidor detecta que o request já foi executado e retorna a resposta com resultado anterior Se a resposta chegar no cliente Método terá sido executado uma só vez Se não Após um certo número de retransmissões, uma exceção será gerada Ao receber exceção, o invocador sabe que o método não foi executado ou foi executado somente uma vez Semântica utilizada em JRMI e CORBA
Localizando uma RPCs estão em um host específico e em uma porta específica. O port mapper no host faz o mapeamento do nome RPC para o número da porta. Tipicamente quando um servidor é inicializado ele registra suas RPCs e seus úmeros de versão junto ao port mapper. Um cliente primeiro se conecta ao port mapper para obter o identificador do RPC. A chamada RPC pode ser feita conectando-se a esta porta.
Portmapper The rpcinfo tool, can be used to find all the RPC services registered on a specified host and to report their universal addresses and the transports for which they are registered. Following example shows all of the RPC services registered on the local machine :
Exemplo de uso do RPC: Hello. World O servidor possui uma função que retorna a string "Hello World!". O cliente invoca esta função remotamente e então imprime o string recebido. O rpcgen produziu os stubs servidor (helloworld_svc. c) e cliente (helloworld_clnt. c) e o arquivo de cabeçalho comum (helloworld. h) a partir do arquivo helloworld. x: O arquivo de definição de interface informado ao rpcgen helloworld_client. c: O programa fonte do cliente helloworld_server. c: O programa fonte do servidor helloworld. h: O arquivo de cabeçalho gerado pelo rpcgen helloworld_clnt. c: O stub cliente produzido pelo rpcgen a partir do arquivo helloworld. x helloworld_svc. c: O stub servidor produzido pelo rpcgen a partir do arquivo helloworld. x
Exemplo de uso do RPC: Hello. World helloworld. x program HELLOWORLDPROG { version HELLOWORLDVERS { string HELLOWORLD(void) = 1; } = 0 x 30000498; Código-fonte completo: https: //cseweb. ucsd. edu/classes/sp 16/cse 291 e/applications/ln/lecture 3. html
JAVA RMI Remote Method Invocation
Java RMI RPC provê facilidades para chamadas de procedimentos remotos através de plataformas. RPC é uma coleção de procedimentos Não provê suporte para a abstração “objeto”; não há como representar um programa com estado privado interno usando RPC JAVA RMI provê um modelo transparente para invocação métodos remotos. Suporta a abstração de “objetos” Provê suporte para interoperabilidade por meio da JNI; Java Native Interface (JNI) - programadores escrevem métodos em outras linguagens ára manipular situações nas quais a aplicação não pode ser escrita completamente em Java CORBA, a ser discutido adiante, é uma solução para objetos remotos que foi projetada especificamente com o objetivo da interoperabilidade.
Semelhanças com RPC Suporta a programação com interfaces; Construída sobre protocolos de requisiçãoresposta; Oferecem o mesmo nível de transparência (as interfaces ocultam complexidade distribuída do RMI); Diferença: Permite o uso do poder de descrição da orientação a objetos (objetos, classes, heranças, etc);
Arquitetura Geral do JAVA RMI
Objetos Remotos e Referências Objetos remotos em Java são exatamente os mesmos objetos locais. Objetos que implementam a interface Remote podem ser usados remotamente Java identifica objetos usando referências. Referências são nomes para objetos Tipicamente são locais; são capazes de nomear objetos dentro de uma única JVM Java também implementa referência a objetos remotos; objetos em uma JVM podem referenciar objetos em outra JVM Do ponto de vista prático, o programador só precisa interagir com o stub do objeto, como se o stub fosse o objeto remoto. O objeto stub e o objeto remoto são classes tecnicamente distintas mas implementam a mesma interface
Client-side stubs Os programadores não possuem uma referência para um objeto remoto de fato. Java representa o objeto remoto por meio de um objeto proxy chamado stub. Responsabilidade do Stub: marshalling da invocação do método em uma mensagem entrega da mensagem ao modulo de comunicação todo o caminho até o retorno do método ao objeto cliente. Instâncias da classe stub Existe no mínimo um objeto stub para cada objeto remoto em uso na JVM, mesmo que os objetos remotos sejam do mesmo tipo. Cada instância da classe stub contém a referência para o objeto remoto que ela representa.
Server-side skeletons Na versão original do RMI, existia do lado servidor um complemento ao stub, chamado skeleton. O skeleton, assim como o stub, era o responsável pelo marshalling do lado servidor. Java 2 eliminou a necessidade de server-side skeletons. Foi criado o componente proxy dispatcher que ficou responsável por fazer o unmarshalling para todos os objetos. Proxy Dispatcher Funcionamento é possível porque nenhuma parte do processo é dependente de um objeto em particular O processo de invocar um método usando uma referência local é o mesmo para todos os objetos
Stubs and Skeletons Quando um método de um objeto stub é invocado, as seguintes ações são realizadas: 1. Inicia a conexão com a JVM remota (contendo o objeto remoto); 2. marshals (escreve e transmite) os parâmetros para a JVM remota; 3. Espera pelo resultado da invocação do método; 4. unmarshals (lê) o valor ou exceção de retorno e retorna o valor para o cliente (caller) O stub esconde a serialização dos parãmetros e o nível da comunicação em a fim de apresentar ao cliente (caller) um simples mecanismo de invocação de método
O compilador de stubs Em versões anteriores do Java, os stubs e skeletons eram gerados com a ferramenta rmic está para RMI assim como rpcgen está para RPC rmic ainda é fornecida com o Java Atualmente não é necessário que o programador execute rmic explicitamente Esta funcionalidade foi inclusa na cadeia de ações da ferrameta javac. Ao compilar com javac, ela procura por código RMI e, se existir, executa um segundo passo para gerar stubs e skeletons (como o rmic fazia)
Falhas e exceções Ao contrário de chamadas de métodos locais, chamadas remotas de métodos podem falhar: Ex: queda da rede de comunicação Java RMI manipula isso ao requere que todos os métodos remotos lancem a exceção Remote. Exception. Como consequência, há a necessidade de que todo uso de um método remoto realize o tratamento da exceção Remote. Exception.
Localizando objetos remotos Java localiza objetos remotos utilizando um programa servidor conhecido como RMIregistry. Servidores que criam objetos remotos podem registrá-los usando bind() ou rebind() da Class Naming Registry registry = Locate. Registry. get. Registry(); registry. bind("Hello", stub); Prrâmetros: Nome com o qual o serviço será identificado no RMIRegistry Referência para o objeto local. Uma vez o objeto tenha sido registrado, um cliente pode ser conectar ao RMIregistry naquele servidor e obter uma referência ao objeto usando o nome. Um cliente também pode invocar o método list() no RMIregistryque retornará com os nomes dos objetos registrados. O registro não é global; existe um por servidor Cliente precisam conectar ao registro deum servidor em particular para obter os objetos nele registrados.
Objetos distribuídos Os sistemas de objetos distribuídos podem adotar o modelo cliente-servidor; Os objetos são gerenciados pelo servidor e os clientes invocam seus métodos usando RMI; Podem existir encadeamento de invocações (objetos servidores podem se tornar clientes de objetos em outros servidores); O acesso direto aos estados de um objeto é proibido (encapsulamento);
Invocações de métodos (locais e remotas) Invocações de métodos locais: ocorrem em um mesmo processos Invocações de métodos remotos: ocorrem em processos distintos ( em hosts distintos ou no mesmo host)
Interfaces Remotas A classe de um objeto remoto implementa os métodos de sua interface remota Objetos em outros processos só podem invocar os métodos pertencentes à interface remota. Objetos locais podem invocar qualquer método (local ou remoto).
Exemplo de uso do RMI: Hello. World Funcionamento 1. 2. 3. 4. O cliente obtém um string que representa o primeiro nome de uma pessoa. O cliente envia o nome como parâmetro à instância remota do objeto Hello. O objeto Hello retorna então um string da forma "Hello World! Hello Greg". O cliente então imprime esta string. Códigos 1. 2. Notas Hello. java (o objeto remoto) Hello. Client. java (o cliente Ambos compilados com "javac“; as classes stub foram geradas; para ilustração a classe stub (Hello_Stub. java) foi decompilada com DJ Java Decompiler (Hello_Stub. class)
Exemplo de uso do RMI: Hello. World
Exemplo de uso do RMI: Hello. World Para testar os códigos fontes disponíveis, deve-se: Compilar todos os fontes javac *. java Iniciar o RMIRegistry no servidor rmiregistry & Iniciar o servidor: java Hello & Iniciar o cliente java Hello. Client Bob
Exercício RMI 1 Utilizando o programa Hello. World como exemplo, construa um serviço remoto que implemente a seguinterface: int Somar(int x, int y) que retorna x * y int Multiplicar (int x, int y) que retorna x * y Construa um cliente que: Localize o serviço no registro Chame os dois métodos acima para dois valores inseridos pelo usuário da aplicação Documentação: https: //docs. oracle. com/javase/7/docs/technotes/guid es/rmi/hello-world. html#define%60
Exercício RMI 2 O Our. Grid, apresentado de talhadamente na aula passada, utiliza RMI para comunicação entre as entidades envolvidas: mygrid, peer e user agent. Com base no funcionamento apresentado, descreva como estas entidades provavelmente foram implementadas e como possivelmente poderia se dar a comunicação entre elas utilizando RMI. Inclua o RMIRegistry na resposta. Questão chave: se você fosse o desenvolvedor, como você teria utilizado RMI no projeto?
CORBA Common Object Request Broker Architecture http: //www. corba. org/
CORBA Solução aberta para o desenvolvimento de aplicações distribuídas em ambientes heterogêneos. OMG: Object Management Group Mais de 700 membros atualmente (desde 1989). Tem o objetivo de desenvolver, adotar e promover padrões para o desenvolvimento de aplicações em ambientes heterogêneos distribuídos. Contribuições dos seus membros através de RFPs (Requests for Proposals)
CORBA Arquitetura aberta, independente de fornecedor e infraestrutura que aplicações computacionais utilizam para trabalhar em conjunto através de uma rede de computadores. Usando o protocolo padrão IIOP, um programa CORBAbased de quase qualquer fornecedor, em qualquer computador, sistema operacional, linguagem de programação e rede pode interoperar com um outro programa CORBA-based do mesmo ou de outro fabricante, em quase qualquer computador, Sistema operacional, linguagem de computador e rede. ”
Principais uso de CORBA Um dos usos mais frequentes é em servidores que precisam manipular um grande número de clientes, com alta confiabilidade. CORBA trabalha por trás das cenas de muitas salas de computação de muitos dos maiores websites do mundo; aqueles que provavelmente usamos todos os dias. Provê escalabilidade e tolerância a falhas Usado não apenas para aplicações de larga escala Há versões especializadas de CORBA que rodam sistemas de tempo real e sistemas embarcados.
Objetos CORBA Aplicações CORBA são compostas de objetos, unidades individuais de software em execução que combinam funcionalidade e dados Para cada tipo de objeto se define uma interface Interface é a a parte sintática do contrato que o objeto do servidor oferece ao cliente que o invoca Cliente usam a interface IDL para especificar a operação que desejam executar A interface IDL é independente de linguagem de programação OMG padronizou os mapeamentos de IDL para C, C++11, Java, Ruby, COBOL, Smalltalk, Ada, Lisp, Python, and IDLscript.
Como funciona? A partir da IDL são gerados os objetos stubs e skeletons A implementação do objeto e um cliente para ele são escritos Stubs and skeletons servem como proxies para clientes e servidores, respectivamente. Devido à definição rigorosa das interfaces, o stub do lado cliente casa perfeitamente com o skeleton do lado servidor, mesmo que tenham sido escritos em linguagens distintas ou que executem em diferentes ORBs de diferentes fornecedores.
Invocação Remota Antes de invocar um objeto remoto, o cliente primeiro obtém uma referência para ele. Para fazer a invocação remota, o cliente usa o mesmo código da invocação local descrita anteriormente Referência do objeto é substituída Quando o ORB examina a referência e descobre que o alvo é um objeto remoto, ele roteia a invocação, através da rede, ao ORB do objeto remoto. for load balanced servers, this is an oversimplification.
CORBA Os aspectos estudados aqui foram apenas para entender a arquitetura geral do CORBA Mecanismos complexos existentes não foram apresentados para manter a simplicidade da explicação. Sugere-se ler sobre: Mecanismos para balancemento de carga Controle de recursos Tolerância a falhas do lado do servidor.
Slides disponíveis em: http: //ericagallindo. com. br
- Slides: 49