quarta-feira, 17 de junho de 2015

RMI - Trabalho Elaborado e Organizado por Vieira Miguel Manuel

Índice







 





“Liberdade verdadeira é aquela em que o homem no seu pensar, dizer e agir, não conhece compulsões, combinações de quem quer que seja”.





Primeiramente, agradecer a Deus, pelo dom da vida e por me conceder oportunidade de apresentar este trabalho de investigação, aos meus pais que a todos os momentos incansavelmente me apoiam, ao meu estimado professor, pelo empenho e dedicação, e todos aqueles que directa ou indirectamente contribuíram para a colaboração do presente.





Dedico este trabalho a todos os estudantes, todos os professores da UTANGA e a todos aqueles que investigaram este trabalho.







Expandir a disciplina de Sistema Distribuído Paralelo na vertente dos temas em questão.





A idéia de RPC data de 1976, quando foi descrito no RFC 707. Um dos primeiros usos comerciais da tecnologia foi feita pela Xerox no "Courier", de 1981. A primeira implementação popular para Unix foi o Sun RPC (atualmente chamado ONC RPC), usado como base do Network File System e que ainda é usada em diversas plataformas.

Outra implementação pioneira em Unix foi o Network Computing System (NCS) da Apollo Computer, que posteriormente foi usada como fundação do DCE/RPC no Distributed Computing Environment (DCE). Uma década depois a Microsoft adotou o DCE/RPC como base para a sua própria implementação de RPC, MSRPC, a DCOM foi implementada com base nesse sistema. Ainda no mesmo período da década de 1990, o ILU da Xerox PARC e o CORBA ofereciam outro paradigma de RPC baseado em objetos distribuídos, com mecanismos de herança.

De forma análoga, actualmente utiliza-se XML como linguagem de descrição de interface e HTTP como protocolo de rede para formar serviços web, cujas implementações incluem SOAP e XML-RPC.

Toda aplicação Java é construida a partir de interfaces e classes, logo, da mesma forma é uma aplicação distribuída construida com Java RMI. A interface declara métodos. As classes implementam os métodos declarados na interface e possivelmente conterá métodos adicionais. Numa aplicação distribuída, algumas implementações podem permanecer em alguma Java VM mas não em outras. Objetos com métodos que podem ser invocados entre Java VM são chamados de Objetos Remotos.

Para se tornar um Objeto Remoto, a classe deve implementar uma interface remota.





RMI

O RMI (Remote Method Invocation) é uma interface de programação que permite a execução de chamadas remotas no estilo RPC em aplicações desenvolvidas em Java. É uma das abordagens da plataforma Java para prover as funcionalidades de uma plataforma de objetos distribuídos. Esse sistema de objetos distribuídos faz parte do núcleo básico de Java desde a versão JDK 1.1, com sua API sendo especificada através do pacote java.rmi e seus subpacotes.

Através da utilização da arquitetura RMI, é possível que um objecto activo em uma máquina virtual Java possa interagir com objectos de outras máquinas virtuais Java, independentemente da localização dessas máquinas virtuais.

A API RMI fornece ferramentas para que seja possível ao programador desenvolver uma aplicação sem se preocupar com detalhes de comunicação entre os diversos possíveis elementos (hosts) de um sistema.

CORBA

CORBA (abreviado de Common Object Request Broker Architecture) é a arquitetura padrão criada pelo Object Management Group para estabelecer e simplificar a troca de dados entre sistemas distribuídos heterogêneos. Em face da diversidade de hardware e software que encontramos atualmente, a CORBA atua de modo que os objetos (componentes dos softwares) possam se comunicar de forma transparente ao usuário, mesmo que para isso seja necessário interoperar com outro software, em outro sistema operacional e em outra ferramenta de desenvolvimento. CORBA é um dos modelos mais populares de objetos distribuídos, juntamente com o DCOM, formato proprietário da Microsoft.

RPC

Chamada remota de procedimento (RPC, acrónimo de Remote Procedure Call) é uma tecnologia de comunicação entre processos que permite a um programa de computador chamar um procedimento em outro espaço de endereçamento (geralmente em outro computador, conectado por uma rede). O programador não se preocupa com detalhes de implementação dessa interação remota: do ponto de vista do código, a chamada se assemelha a chamadas de procedimentos locais.

RPC é uma tecnologia popular para a implementação do modelo cliente-servidor de computação distribuída. Uma chamada de procedimento remoto é iniciada pelo cliente enviando uma mensagem para um servidor remoto para executar um procedimento específico. Uma resposta é retornada ao cliente. Uma diferença importante entre chamadas de procedimento remotas e chamadas de procedimento locais é que, no primeiro caso, a chamada pode falhar por problemas da rede. Nesse caso, não há nem mesmo garantia de que o procedimento foi invocado.





O funcionamento de RMI consiste basicamente em dois programas, segundo a arquitetura cliente-servidor, onde um seria o cliente e outro o servidor. O servidor instancia objetos remotos, o referencia com um nome e faz um "BIND" dele numa porta, onde este objeto espera por clientes que invoquem seus métodos. Já o cliente referencia remotamente um ou mais métodos de um objeto remoto. RMI fornece os mecanismos para que a comunicação entre cliente e servidor seja possível. Esse tipo de aplicação geralmente é denominada como Aplicação de Objeto Distribuído.

Aplicações distribuídas precisam, portanto, executar as seguintes ações:

Localizar Objetos Remotos - Uma aplicação pode usar dois mecanismos para obter referências de objetos remotos. Ela pode registrar o objeto remoto com a ferramenta de nomes do RMI, que se chama "rmiregistry", ou ela pode passar e retornar referências aos objetos remotos como parte de sua operação normal.

Se Comunicar com Objetos Remotos - Os detalhes de comunicação entre objetos remotos são tratados pelo RMI, ou seja, para o programador, a comunicação remota é semelhante a uma chamada ao método localmente.

Carregar "bytecodes" de objetos móveis - Como o RMI permite que objetos remotos sejam passados como parâmetros numa função, ele fornece os mecanismos necessários para carregar o código dos objetos remotos.


Para permitir que os servidores sejam acessados por diferentes clientes, diversos sistemas padronizados de RPC foram criados. A maioria deles usa uma linguagem de descrição de interface (IDL) para que diferentes plataformas possam chamar procedimentos. Fazendo uso de uma ferramenta como o RPCGEN, pode-se gerar interfaces entre cliente e servidor a partir de um arquivo IDL, os chamados stubs. Como os stubs são embarcados nas aplicações cliente e servidor, a RPC não é uma camada de middleware.1

Na codificação, o procedimento remoto do cliente chama o stub cliente como qualquer outro procedimento local, e a implementação interna do stub cliente é responsável por iniciar o processo de transmissão para stub servidor, empacotando a chamada numa mensagem. Ao chegar, o stub servidor desempacota a mensagem e invoca localmente o procedimento, aguardando o retorno. Quando a chamada local retorna, o stub servidor é responsável por iniciar o processo de transmissão para o stub cliente, empacotando a resposta numa mensagem. Chegando, a resposta é desempacotada pelo stub cliente, sendo retornada localmente para o procedimento que realizou a chamada remota.

Ao invocar o procedimento remoto, deve-se atentar que cliente e servidor podem ser plataformas diferentes, que representam dados de forma diferente. Nesse caso é preciso um protocolo comum de representação dos dados, como o XDR, ou a garantia de que ambas as partes saibam converter os dados para tipos de dado suportados. Por ser uma chamada remota, noutro espaço de endereçamento, deve-se atentar também o desafio de passar um ponteiro. Nesse caso, a implementação interna do RPC deve passar o conteúdo do ponteiro por cópia e restaurar a área de memória no retorno do procedimento.


O modelo de Chamada Remota de Procedimento é similar ao modelo de chamadas locais de procedimentos, no qual a rotina que invoca o procedimento coloca os argumentos em uma área de memória bem conhecida e transfere o controle para o procedimento em execução, que lê os argumentos e os processa. Em algum momento, a rotina retoma o controle, extraindo o resultado da execução de uma área bem conhecida da memória. Após isso, a rotina prossegue com a execução normal.

No modelo RPC, o processo de invocação ocorre de maneira similar. Uma Thread é responsável pelo controle de dois processos: invocador e servidor. O processo invocador primeiro manda uma mensagem para o processo servidor e aguarda (bloqueia) uma mensagem de resposta. A mensagem de invocação contém os parâmetros do procedimento e a mensagem de resposta contém o resultado da execução do procedimento. Uma vez que a mensagem de resposta é recebida, os resultados da execução do procedimento são coletados e a execução do invocador prossegue.

Do lado do servidor, um processo permanece em espera até a chegada de uma mensagem de invocação. Quando uma mensagem de invocação é recebida, o servidor extrai os parâmetros, processa-os e produz os resultados, que são enviados na mensagem de resposta. O servidor, então, volta a esperar por uma nova mensagem de invocação.

http://upload.wikimedia.org/wikipedia/commons/9/97/ChamadaRemotaDeProcedimentoPassos.png

Nesse modelo, apenas um dos dois processos permanece ativo, em um dado instante de tempo. No entanto, esse modelo serve apenas de ilustração. O protocolo ONC RPC não faz restrições à implementações que permitam concorrência entre esses processos. Por exemplo, uma implementação poderia optar por chamadas assíncronas, que permitiriam ao cliente continuar com o trabalho útil, enquanto estivesse aguardando a mensagem de resposta.





Uma das principais vantagens do RMI é sua capacidade de baixar o código de um objeto, caso a classe desse objeto não seja definida máquina virtual do receptor. Os tipos e o comportamento de um objeto, previamente disponíveis apenas em uma máquina virtual, agora podem ser transmitidos para outra máquina virtual, possivelmente remota. Essa funcionalidade do RMI permite que o código da aplicação seja atualizado dinamicamente, sem a necessidade de recompilar o código.


Os clientes acham os serviços remotos usando o serviço de nomeação ou diretório (naming or directory). Isso parece um pouco redundante, mas o serviço de nomeação ou diretório roda como um endereço bem formado (host:port). O RMI pode usar diferentes tipos de serviços de diretório, incluindo o JNDI. O próprio RMI inclui um simples serviço, chamado de RMI Registry. O RMI Registry roda em cada maquina que hospeda o serviço remoto, por definição na porta 1099. Numa máquina host, um programa servidor cria um serviço remoto, primeiramente criando o objeto que implemente aquele serviço. Em seguida ele exporta aquele objeto para o RMI. Quando o objeto é exportado o RMI cria um serviço que aguarda as conexões do cliente. O servidor registra o objeto no RMI Registry, com um nome público. No lado do cliente o RMI Registry é acessado através da classe estática Naming. Ela provém o método lookup( ), que o cliente usa para requisitar o registro. Esse método aceita a URL que especifica o nome do servidor e o nome do serviço desejado. O método retorna uma referência remota para o objeto do serviço. A URL é formada como seguinte:

rmi://[host_name]:[port_number]/[service_name]

Serialização

A capacidade de armazenar e recuperar objetos em JAVA é essencial quando se fala de RMI. A maneira encontrada para armazenar esses objetos em uma forma serializada sem ocupar muita memória foi representar os estados do objeto suficientes para reconstruí-lo.

Objetos serializados em Java devem ser capazes de identificar e verificar a classe Java da qual eles derivam e recuperar seu conteúdo para criar uma nova instância.

Freqüentemente, objetos armazenados fazem referência a outros objetos. Esses outros objetos também devem ser armazenados e na recuperação, todos devem ser desarmazenados ao mesmo tempo, para que as relações entre ele não se percam.





O protocolo RPC pode ser implementado sobre diferentes tipos de protocolos de transporte, uma vez que é indiferente a maneira de como uma mensagem é transmitida entre os processos. É importante salientar que o protocolo RPC não implementa nenhuma forma de confiabilidade e que a aplicação precisa tomar cuidados quanto ao tipo de protocolo sobre o qual RPC opera. Caso se trate de um protocolo confiável, como TCP, as preocupações com confiabilidade já são resolvidas. Por outro lado, caso a camada de transporte seja não-confiável, como UDP, mecanismos de timeout, retransmissão e detecção de duplicatas devem ser implementados, uma vez que esses serviços não são providos por RPC.

Devido à independência da camada de transporte, o protocolo RPC não modifica a semântica das chamadas remotas, nem seus requisitos de execução. A semântica pode ser inferida a partir da camada de transporte em uso. Por exemplo, considere o caso em que RPC opera sobre uma camada de transporte não-confiável, como UDP. Se uma aplicação retransmite mensagens de invocação RPC, após timeouts, e não recebe respostas, não pode inferir o número de vezes em que o procedimento foi executado. Se uma mensagem é recebida, ela pode inferir que o procedimento foi executado, pelo menos, uma vez. O servidor pode efetuar o controle do número de execuções, simplesmente gravando o número do último procedimento executado com êxito, evitando assim reexecuções de uma mesma chamada.

Por outro lado, quando RPC opera sobre uma camada de transporte confiável, como TCP, a aplicação pode inferir, a partir de uma mensagem de resposta, que o procedimento foi executado exatamente uma vez. No entanto, se nenhuma mensagem de reposta é recebida, a aplicação não pode assumir que o procedimento não foi executado. Perceba que, mesmo usando um protocolo orientado a conexões, aplicações ainda requerem timeouts para identificar falhas do servidor.

Há, ainda, muitas outras possibilidades de transporte além de datagramas e protocolos orientados a conexão. Por exemplo, protocolos de consulta-resposta como VMTP pode ser usado por TCP.






RFC 1057 - ONC RPC versão 1
RFC 1831 - ONC RPC versão 2
Procedure Calls Tutorial (em inglês)

Patrícia Kayser Vargas. Chamada Remota de Procedimento (RPC) Notas de aula de Sistemas Operacionais Distribuídos e de Redes UFRGS. Visitado em 14 de julho de 2008.

Java RMI
An Overview of RMI Applications
Breve Introdução ao RMI - Remote Method Invocation
RMI (Remote Method Invocation)







Comente com o Facebook: