Use A Cabeça Java

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.

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() {

Barb=newBar();

b.doStuff();

}

public static void main (String[] args) {

Foof=newFoo();

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?