Processamento Distribuído com RPC e RMI

Prévia do material em texto

ARQUITETURA DA INFORMAÇÃO 1 
 ....................................................... 2 Aula 3: Processamento Distribuído com RPC e RMI
 ............................................................................................................................. 2 Introdução
 ................................................................................................................................ 3 Conteúdo
Processamento paralelo ................................................................................................... 3 
Processamento distribuído .............................................................................................. 5 
 ........................................................................................... 7 RPC (Remote Procedure Call)
 .................................................................................... 11 RM(Remote Method Invocation)
 .......................................................................................... 14 Marshalling e Unmarshalling
Serviços de nomes e diretórios ..................................................................................... 15 
Atividade proposta .......................................................................................................... 16 
........................................................................................................................... 16 Referências
 ......................................................................................................... 17 Exercícios de fixação
Chaves de resposta ..................................................................................................................... 21 
 
 
 ARQUITETURA DA INFORMAÇÃO 2 
Introdução 
Uma evolução natural da programação foi a utilização de processamento 
paralelo para a resolução de problemas complexos. 
 
A distribuição de processamento também é utilizada com tal finalidade, ou em 
situações nas quais os participantes de uma transação não se encontram 
fisicamente no mesmo local. 
 
Esta aula visa elucidar conceitos como processamento paralelo e distribuído, 
além de descrever tecnologias de grande aceitação na implementação de 
sistemas distribuídos, como RPC e RMI. 
 
Objetivo: 
1. Compreender o processamento distribuído e uso do RPC; 
2. Conhecer a tecnologia Java RMI. 
 
 
 
 
 
 
 
 
 
 ARQUITETURA DA INFORMAÇÃO 3 
Conteúdo 
 
Processamento paralelo 
1945 
Já em 1945, nos trabalhos de Von Neumann, as arquiteturas de processamento 
paralelo eram apresentadas como uma solução para aumento do poder de 
processamento. 
 
As técnicas de processamento paralelo sempre visaram ao melhor 
aproveitamento do tempo de CPU, particularmente quando ocorriam 
“demorados” procedimentos de Entrada e Saída. 
 
1950 a 1970 
De 1950 a 1970 era comum a utilização de computadores monoprocessados. 
Havia uma busca por processadores cada vez mais velozes, porém existiam 
barreiras físicas para essa velocidade, assim, a solução mais viável para a 
otimização do tempo consistiria posteriormente em trabalhar com máquinas 
multiprocessadas. 
 
A miniaturização proporcionada pela evolução da tecnologia de transistores 
permitiu que até mesmo bilhões deles fossem integrados em um chip, 
viabilizando a definição de arquiteturas de processadores com mais unidades 
funcionais e memória cache. 
 
Com isso, temos hoje processadores com vários núcleos, com grande poder de 
processamento, mais bem explorados pelas técnicas de programação paralela 
com multitarefa. 
 
Em linguagem Java, uma tarefa independente pode ser definida pela extensão 
da classe Thread. Outra forma seria a implementação da interface Runnable, o 
que não elimina a necessidade da chamada inicial com uma classe Thread. A 
tarefa que deverá ser executada continuamente em paralelo é definida no 
 
 ARQUITETURA DA INFORMAÇÃO 4 
método run, e quando há necessidade de sincronização utiliza-se a palavra-
chave synchronized. 
 
 
 
(imagem representativa do método run) 
 
 ARQUITETURA DA INFORMAÇÃO 5 
Processamento distribuído 
A distribuição de processamento também pode ocorrer ao longo de uma rede, 
com diferentes processos sendo executados em máquinas remotas, segundo 
protocolos específicos de comunicação. 
 
O termo DCE (Distributed Computing Environment) é comumente utilizado para 
definir esse tipo de ambiente, onde vários componentes de software, como 
serviços de diretórios, gestores de segurança, sistemas de objetos distribuídos, 
entre vários outros, trabalham em conjunto para a construção de complexos 
sistemas corporativos. 
 
Dentro de uma rede TCP-IP, a definição de um serviço distribuído de forma 
mais simples envolve a construção de um servidor, normalmente trabalhando 
com paralelismo, que seja capaz de escutar uma porta específica destinada ao 
serviço oferecido, e clientes capazes de se comunicar com esse servidor 
segundo um protocolo previamente estabelecido. 
 
Um código em linguagem Java de exemplo para a criação de um sistema 
cliente-servidor com uso de Socket. 
 
Embora qualquer sistema cliente-servidor possa atuar dessa forma, algumas 
arquiteturas próprias foram definidas para a formalização dos serviços 
distribuídos, como o RPC e o RMI. 
 
 
 ARQUITETURA DA INFORMAÇÃO 6 
 
 
 
 
 
 ARQUITETURA DA INFORMAÇÃO 7 
 
(imagem representativa de um código em linguagem Java) 
 
RPC (Remote Procedure Call) 
A chamada remota de procedimento (RPC) trata de um modelo de comunicação 
entre processos que viabiliza a chamada de um procedimento em outro espaço 
de endereçamento, normalmente em outro computador da rede, sem que o 
programador tenha que se preocupar com detalhes dessa interação remota, 
assemelhando-se a chamadas locais em termos de código. 
 
Com isso, o uso de RPC simplifica a criação de sistemas distribuídos deixando a 
comunicação transparente para o programador. 
 
Essa é uma ideia antiga, datando de 1976, quando foi descrita na RFC 707. Foi 
utilizada de maneira comercial inicialmente pela Xerox, em 1981, sendo a 
primeira implementação popular efetuada para UNIX com o Sun RPC, usado 
como base para o NFS (Network File System). 
 
Várias extensões da comunicação remota para ambientes de objetos 
distribuídos, como CORBA e DCOM, são baseadas em diferentes 
implementações do RPC. As ferramentas para criação de aplicativos RPC 
cuidam da geração dos stubs para garantir essa transparência. 
 
 ARQUITETURA DA INFORMAÇÃO 8 
A ideia fundamental é a de que o servidor exporta apenas a interface de 
procedimentos e funções, da mesma forma que ocorreria com uma API ou 
biblioteca. 
 
O programa cliente faz a chamada ao procedimento remoto, com a passagem 
dos parâmetros necessários, e recebe a resposta, como se estivesse chamando 
um simples método local. 
 
O par de stubs faz a transformação de chamadas e respostas nas mensagens 
necessárias para a comunicação em rede. Em termos do servidor, esse 
elemento responsável pela interceptação das chamadas é comumente 
denominado skeleton, e deve receber a chamada, ativar o componente de 
software responsável pelo processamento do pedido, e retornar com a resposta 
solicitada. 
 
Com todas essas características, o único vínculo real entre o código do cliente e 
o do servidor é a interface de exposição de serviços, a qual segue uma sintaxe 
bastante simples. 
 
Um exemplo de sistema com uso de RPC na sintaxe C, bem como a interface de 
exposição dos serviços: 
 
/* addsub.x : definição da interface */ 
#define PROGRAM_NUMBER 12345678 
#define VERSION_NUMBER 1 
 
/*tipo de dado que será passado aos procedimentos remotos */ 
 
struct operands 
{ 
 int x; 
 int y; 
 
 ARQUITETURA DA INFORMAÇÃO 9 
}; 
 
/* Definição da interface que será oferecida aos clientes */ 
 
program ADDSUB_PROG 
{ 
 version ADDSUB_VERSION 
 { 
 int ADD (operands) = 1; 
 int SUB (operands) = 2; 
 } 
 = VERSION_NUMBER; 
} 
= PROGRAM_NUMBER; 
 
Com o uso do utilitário rpcgen são gerados vários arquivos a partir desse 
arquivo de interface, compreendendo toda a parte de comunicação e oferta de 
serviços, o que deixará para o programador a simples tarefa de implementar as 
regras de negócios do aplicativo, sem se desgastar com a comunicação e 
distribuição. 
 
/* Arquivo server.c: um servidor RPC simples */ 
#include <stdio.h> 
#include "addsub.h" 
 
/* implementação da função add */ 
int * add_1_svc (operands *argp, struct svc_req *rqstp) 
{ 
 static int result; 
 
 printf ("Recebi chamado: add %d %d\n", argp->x, argp->y); 
 result = argp->x + argp->y; 
 return (&result); 
} 
 
/* implementação da função sub */ 
 
 ARQUITETURA DA INFORMAÇÃO 10 
int * sub_1_svc (operands *argp, struct svc_req *rqstp) 
{ 
 static int result; 
 
 printf ("Recebi chamado: sub %d %d\n", argp->x, argp->y); 
 result = argp->x - argp->y; 
 return (&result); 
} 
 
O código do cliente é um pouco mais complexo que o do servidor, mas é fácil 
observar como a chamada remota assemelha-se a uma simples chamada de 
função local. 
/* Arquivo client.c: um cliente RPC simples */ 
 
#include <stdio.h> 
#include "addsub.h" 
 
/* função que chama a RPC add_1 */ 
int add (CLIENT *clnt, int x, int y) 
{ 
 operands ops; 
 int *result; 
 
 /* junta os parâmetros em um struct */ 
 ops.x = x; 
 ops.y = y; 
 
 /* chama a função remota */ 
 result = add_1 (&ops,clnt); 
 if (result == NULL) 
 { 
 printf ("Problemas ao chamar a função remota\n"); 
 exit (1); 
 } 
 
 return (*result); 
} 
 
int main( int argc, char *argv[]) 
{ 
 CLIENT *clnt; 
 int x,y; 
 
 
 ARQUITETURA DA INFORMAÇÃO 11 
 /* verifica se o cliente foi chamado corretamente */ 
 if (argc!=4) 
 { 
 fprintf (stderr,"Usage: %s hostname num1 num2\n",argv[0]); 
 exit (1); 
 } 
 
 /* cria uma struct CLIENT que referencia uma interface RPC */ 
 clnt = clnt_create (argv[1], ADDSUB_PROG, ADDSUB_VERSION, "udp"); 
 
 /* verifica se a referência foi criada */ 
 if (clnt == (CLIENT *) NULL) 
 { 
 clnt_pcreateerror (argv[1]); 
 exit(1); 
 } 
 
 /* obtém os dois inteiros que serão passados via RPC */ 
 x = atoi (argv[2]); 
 y = atoi (argv[3]); 
 
 /* executa um procedimento remoto */ 
 printf ("%d + %d = %d\n", x, y, add (clnt,x,y)); 
 
 return (0); 
} 
(imagens representativas de Interface para definição dos serviços (IDL).) 
 
RM(Remote Method Invocation) 
A tecnologia RMI pode ser considerada como a versão orientada a objetos do 
RPC, disponível para a linguagem Java. 
 
Nesse modelo o que temos é um objeto hospedado e executado em 
determinado servidor, registrado via RMI Registry, e que disponibiliza métodos 
para acesso remoto. 
 
A arquitetura de comunicação do RMI pode ser observada no desenho seguinte, 
onde pode ser vista a presença dos stubs nos clientes e do skeleton no 
servidor. 
 
 ARQUITETURA DA INFORMAÇÃO 12 
 
 
(imagem representativa da tecnologia RMI) 
 
O passo inicial para o desenvolvimento de um sistema com uso de RMI é a 
definição da interface remota, o que equivaleria à definição da IDL utilizada no 
RPC, porém restrita ao universo Java. 
 
 
Essa interface deverá ser descendente da interface Remote e cada método dela 
deverá considerar a ocorrência da exceção RemoteException, como pode ser 
observado no exemplo seguinte: 
 
 
 ARQUITETURA DA INFORMAÇÃO 13 
 
 
Criada a interface, deve ser definido um objeto servidor que a implementa, 
criando assim os métodos do serviço. 
 
Esse objeto também deve ser descendente de UnicastRemoteObject. 
 
Um objeto da classe CalcRemote deve ser instanciado e registrado pelo 
programa servidor, ficando disponível para os clientes através da escuta 
efetuada pelo RMI Registry. 
 
 
 
 
 ARQUITETURA DA INFORMAÇÃO 14 
 
 
Com relação ao cliente, este deverá localizar o objeto servidor através do 
protocolo gerenciado pelo RMI Registry, efetuando a chamada aos métodos 
remotos, segundo o que foi definido em ICalcRemote. 
 
O uso de RMI permite a definição de um DCE de grande simplicidade de uso 
para a linguagem Java, permitindo a passagem de informações através de 
objetos serializáveis mais complexos, segundo um padrão Proxy, diminuindo 
muito o esforço de programação. 
 
No entanto, quando são tratados os sistemas corporativos, vários requisitos, 
como transações, pooling e autenticação, podem não ser oferecidos de forma 
simples pelo RMI. Para satisfazer a esse tipo de necessidade são utilizados 
ambientes de objetos distribuídos. 
 
Marshalling e Unmarshalling 
Um conceito comum em termos de programação orientada a objetos é a 
serialização de objetos. 
 
A serialização é a transformação de dados em geral, que estejam em memória, 
para um formato adequado em array de bytes, pronto para armazenagem ou 
transferência do mesmo. 
 
 
 ARQUITETURA DA INFORMAÇÃO 15 
Em outro momento o processo inverso (desserialização) pode ser efetuado, 
partindo do array de bytes e montando a estrutura novamente em memória, 
claro que ocupando locais diferentes da mesma. 
 
Em termos de comunicação remota, um conceito similar é o de Marshalling e 
Unmarshalling, pois trata da transformação dos dados estruturados segundo 
uma determinada tecnologia, como Java ou C#, em formato compatível com as 
mensagens que são trafegadas entre os stubs (Marshalling), bem como o 
processo inverso, para a recuperação dos dados a partir da mensagem 
(Unmarshalling), lembrando que nas duas pontas as linguagens podem ser 
distintas. 
 
Serviços de nomes e diretórios 
A chamada remota de procedimento (RPC) trata de um modelo de comunicação 
entre processos que viabiliza a chamada de um procedimento em outro espaço 
de endereçamento, normalmente em outro computador da rede, sem que o 
programador tenha que se preocupar com detalhes dessa interação remota, 
assemelhando-se a chamadas locais em termos de código. 
 
 Associam nomes a recursos computacionais em rede; 
 
 Funcionam como “diretórios” compartilhados; 
 
 Envolvem funções de localização e registro de elementos; 
 
 Permitem armazenar objetos, certificados digitais e outros elementos 
serializáveis. 
 
Amplamente utilizados pelas instituições bancárias, DAP (Directory Access 
Protocol) e LDAP (Lightweight Directory Access Protocol) são exemplos desse 
tipo de serviço. No caso da tecnologia Java, as ações de registro e localização 
são feitas pelo JNDI (Java Naming and Directory Interface), o qual apresenta 
 
 ARQUITETURA DA INFORMAÇÃO 16 
uma interface única entre os diversos serviços de diretório, gerenciando 
inclusive o acesso a recursos como RMI, CORBA, DAP, LDAP e JEE. 
 
Atividade proposta 
Implemente um serviço RMI que receba o valor de dois catetos de um triângulo 
retângulo e retorne o valor da hipotenusa. 
Parâmetros de entrada: double cateto1, double cateto2 
Retorno: double 
Cálculo: hipotenusa = Math.sqrt(Math.pow(cateto1,2)+Math.pow(cateto2,2))Referências 
Silva, F. Sistemas Distribuídos: Conceitos e Projeto RPC e RMI, UFMA, 2013 
http://www.deinf.ufma.br/~fssilva/graduacao/sd/aulas/rpc_rmi.pdf 
 
Grosso, W. Java RMI (Java Series), O’Reilly, 2001. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 ARQUITETURA DA INFORMAÇÃO 17 
Exercícios de fixação 
Questão 1 
Quando trabalhamos com processamento paralelo, um problema comum é a 
utilização de recursos compartilhados que podem ser lidos ou escritos de forma 
errônea devido à preempção. Para resolver isso deve ocorrer um 
sequenciamento no acesso ao recurso, o que é obtido no Java com o uso da 
palavra reservada: 
a) static 
b) volatile 
c) synchronized 
d) abstract 
e) final 
 
Questão 2 
Uma classe ServerSocket deve escutar uma porta especificada e aceitar 
conexões solicitadas pelos clientes, repassando as mesmas para objetos Socket 
locais, o que define o circuito virtual entre cliente e servidor. Qual o método 
utilizado para aceitar uma conexão? 
a) start 
b) accept 
c) getInputStream 
d) getOutputStream 
e) close 
 
Questão 3 
A utilização de RPC viabiliza a construção de sistemas de processamento 
distribuído com um formato de comunicação transparente para o programador. 
Quem permite esta transparência são os _______________ definidos para o 
padrão Proxy. 
a) senders 
b) idles 
c) clients 
 
 ARQUITETURA DA INFORMAÇÃO 18 
d) stubs 
e) publishers 
 
Questão 4 
Na arquitetura do RPC, o elemento responsável por tratar as chamadas no 
servidor é denominado: 
a) IDL 
b) stub 
c) skeleton 
d) Socket 
e) ServerSocket 
 
Questão 5 
O elemento na arquitetura do RPC que permite a geração automática de todo o 
aparato de comunicação em rede, de forma automatizada, por ferramentas 
como o rpcgen é: 
a) IDL 
b) stub 
c) skeleton 
d) Socket 
e) ServerSocket 
 
Questão 6 
Em sistemas de processamento distribuído ocorre a necessidade de registrar e 
localizar componentes disponibilizados remotamente. O componente de 
software responsável por executar esta função seria: 
a) Interface de Descrição de Serviços 
b) Serviço de Nomes e Diretórios 
c) Temporizador 
d) Protocolo de Comunicação 
e) Gerenciador do Banco de Dados 
 
 
 ARQUITETURA DA INFORMAÇÃO 19 
Questão 7 
A transformação dos dados estruturados segundo uma determinada tecnologia, 
como Java ou C#, em formato compatível com as mensagens que são 
trafegadas entre os stubs é denominada: 
a) serialização 
b) unmarshalling 
c) marshalling 
d) de-serialização 
e) vetorização 
 
Questão 8 
Em termos de RMI a descrição dos serviços é feita na própria linguagem Java 
através de uma interface descendente de: 
a) Remote 
b) Runnable 
c) MessageListener 
d) Serializable 
e) CommandListener 
 
Questão 9 
Considere as afirmativas abaixo: 
I – Os métodos expostos pela interface remota do RMI devem considerar a 
ocorrência da exceção RemoteException. 
II – Criada a interface, deve ser definido uma classe que implementa a mesma 
e seja descendente de UnicastRemoteObject. 
III – Os passos I e II são necessários e suficientes para a criação de um 
servidor RMI. 
Quais as afirmativas corretas? 
a) Todas estão corretas 
b) Apenas a I está correta 
c) Apenas a II está correta 
d) As alternativas I e II estão corretas 
 
 ARQUITETURA DA INFORMAÇÃO 20 
e) Nenhuma está correta 
 
Questão 10 
No ambiente Java os serviços de nomes e diretórios são acessados através de: 
a) DAP 
b) LDAP 
c) DNS 
d) JEE 
e) JNDI 
 
 
 
 ARQUITETURA DA INFORMAÇÃO 21 
Aula 3 
Exercícios de fixação 
Questão 1 - C 
Justificativa: Em linguagem Java uma tarefa independente pode ser definida 
pela extensão da classe Thread ou pela implementação da interface Runnable, 
e quando há necessidade de sincronização utiliza-se a palavra-chave 
synchronized. 
 
Questão 2 - B 
Justificativa: Os métodos getInputStream, getOutputStream e close pertencem 
à classe Socket, enquanto start inicia uma Thread. O método accept pertence 
ao ServerSocket e serve para receber uma conexão na porta especificada na 
inicialização do mesmo. 
 
Questão 3 - D 
Justificativa: As ferramentas para criação de aplicativos RPC cuidam da geração 
dos stubs para garantir a transparência da comunicação em rede. O par de 
stubs faz a transformação de chamadas e respostas nas mensagens 
necessárias. 
 
Questão 4 - C 
Justificativa: Em termos do servidor, o elemento responsável pela interceptação 
das chamadas é comumente denominado skeleton, e deve receber a chamada, 
ativar o componente de software responsável pelo processamento do pedido, e 
retornar com a resposta solicitada. 
 
Questão 5 - A 
Justificativa: A utilização de Socket e ServerSocket de forma plana não 
constituiria um sistema RPC. Nas arquiteturas do tipo RPC deve haver uma IDL 
 
 ARQUITETURA DA INFORMAÇÃO 22 
(Interface Definition Language) que permita a aplicativos como o rpcgen gerar 
os stubs para a comunicação com o skeleton do servidor. 
 
Questão 6 - B 
Justificativa: Tanto no uso de RMI quanto no uso de CORBA, JEE, ou qualquer 
outro recurso que precise ser acessado a partir de uma localização externa ao 
programa que fornece este recurso, é comum o uso de serviços de nomes e 
diretórios. 
 
Questão 7 - C 
Justificativa: A transformação dos dados para o formato de envio é denominada 
marshalling, enquanto o processo inverso, na recepção, é denominado 
unmarshalling. 
 
Questão 8 - A 
Justificativa: O passo inicial para o desenvolvimento de um sistema com uso de 
RMI é a definição da interface remota, o que equivaleria à definição da IDL 
utilizada no RPC, porém restrita ao universo Java. Esta interface deverá ser 
descendente da interface Remote. 
 
Questão 9 - D 
Justificativa: A alternativa III está incorreta, pois seria ainda necessário criar 
um aplicativo (main) que registre uma instância da classe criada em II, bem 
como o rmiregistry deverá estar em execução para que este aplicativo consiga 
também executar. 
 
Questão 10 - E 
Justificativa: No caso do Java, as ações de registro e localização são feitas pelo 
JNDI, o qual apresenta uma interface única entre os diversos serviços de 
diretório, gerenciando inclusive o acesso a recursos como RMI, CORBA, DAP, 
LDAP e JEE.