![](/api/v2/epubs/9788576081739/files/bg1c6.png)
implantação remota com o RMI
425
você está aquieste é um novo capítulo
Computação
Distribuída
18 implantação remota com o RMI
Trabalhar remotamente não precisa ser ruim. Certo,
as coisas são mais fáceis quando todas as partes do aplicativo
estão em um mesmo local, em um acervo, com uma JVM para
regular tudo. Mas nem sempre isso é possível. Ou desejável. E se
seu aplicativo manipular cálculos poderosos, porém os usuários
nais estiverem usando um pequeno dispositivo habilitado com
Java? E se ele precisar de dados de um banco de dados, mas por
razões de segurança, só códigos em seu servidor possam acessar
o banco de dados? Consegue imaginar um grande back-end de
comércio eletrônico, que tenha que ser executado dentro de um
sistema de gerenciamento de transações? Em algumas situações,
parte de seu aplicativo terá que ser executada em um servidor,
enquanto outra parte (geralmente um cliente) será executada em
uma máquina diferente. Neste capítulo, aprenderemos a usar a
surpreendentemente simples tecnologia Remote Method Invocation
(RMI) da Java. Também examinaremos rapidamente os Servlets, os
Enterprise Java Beans (EJB) e o Jini, e veremos como o EJB e o
JINI podem depender do RMI. Terminaremos o livro criando uma das
coisas mais interessantes que você poderia desenvolver em Java,
um navegador universal de serviços.
Todos dizem que relacionamentos à
distância são difíceis, mas com o RMI,
é fácil. Independentemente de o quanto
estivermos distantes, o RMI fará parecer
que estamos juntos.
![](/api/v2/epubs/9788576081739/files/bg1c7.png)
426 capítulo 18
quantos acervos?
Arquivo jar
executável
100% local Combinação 100% remota
Web Start
Aplicativo
RMI
Servlets
As chamadas de método ocorrem sempre entre dois objetos
do mesmo acervo.
Até agora neste livro, todos os métodos que chamamos se encontravam
em um objeto sendo executado na mesma máquina virtual de quem os
chamou. Em outras palavras, o objeto que chamou e o que foi chamado
(o objeto em que chamamos o método) residiam no mesmo acervo.
class Foo {
void go() {
Barb=newBar();
b.doStuff();
}
public static void main (String[] args) {
Foof=newFoo();
f.go();
}
}
No código anterior, sabemos que a instância de Foo referenciada por f e o
objeto Bar referenciado por b estão no mesmo acervo, sendo executados
pela mesma JVM. Lembre-se de que a JVM sempre sabe onde está cada
objeto e como chegar até ele. Mas ela só consegue obter informações
sobre referências de seu próprio acervo! Você não pode, por exemplo,
fazer uma JVM sendo executada em uma máquina ter informações sobre
o espaço do acervo de uma JVM sendo executada em uma máquina
diferente. Na verdade, uma JVM sendo executada em uma máquina
não consegue saber nada sobre uma JVM diferente sendo executada na
mesma máquina. Não faz diferença se as JVMs estão na mesma ou em
máquinas físicas diferentes; a única coisa que importa é se as duas JVMs
são, bem, duas chamadas diferentes da JVM.
um acervo, dois objetos
doStuff()
Na maioria dos aplicativos,
quando um objeto chama um
método em outro, os dois
objetos se encontram no mesmo
acervo. Em outras palavras,
ambos estão sendo executados
dentro da mesma JVM.
E se você quiser chamar um método em um
objeto sendo executado em outra máquina?
Sabemos como capturar informações de uma
máquina para outra — através de soquetes
e uxos de E/S. Abrimos uma conexão de
soquete com outra máquina, capturamos
um objeto OutputSream e gravamos alguns
dados nele.
Mas e se quisermos chamar um método
em algo que estiver sendo executado em
outra máquina... Outra JVM? É claro que
poderíamos construir nosso próprio protocolo
e quando você enviasse dados para um
ServerSocket o servidor poderia analisá-lo,
descobrir o que você quer, executar a tarefa e
retornar o resultado em outro uxo. Mas isso
dá muito trabalho. Não seria muito melhor
apenas capturar uma referência do objeto na
outra máquina e chamar um método?
Imagine dois computadores...
JVM
JVM
minúsculo, irregular,
muito lento em cálculos
poderoso, rápido,
satisfatório em
grandes cálculos
Pequeno
Grande
grandes cálculos
O dispositivos Grande tem algo que o Pequeno quer.
Poder de computação.
O dispositivo Pequeno quer enviar alguns dados para o Grande,
para que esse possa fazer cálculos pesados.
O dispositivo Pequeno quer simplesmente chamar um método...
double doCalcUsingDatabase(CalcNumbers numbers)
e obter o resultado.
Mas como o dispositivo Pequeno capturará uma referência de um
objeto que se encontra no dispositivo Grande?
Get Use A Cabeça Java now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.