Í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.
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)
Nenhum comentário:
Postar um comentário