JNDI e RMI

Programação Arquitetura
#1

E aew pessoal.

Bom, estou aprendendo agora sobre essas tecnologias, e não achei muito material de base por aí.
No caso, o JNDI seria um servidor de nomes para objetos, correto? e o RMI é o responsável pela comunicação dos objetos em servidores diferentes.
Então, pelo o que eu entendi, por exemplo, em uma aplicação WEB, a requisição procura pelo nome padrão de um objeto no JNDI, e através do RMI, a comunicação entre os objetos em servidores diferentes é feita.
Mas, como essa distribuição de objetos em vários servidores funciona? O JAR ou o WAR são distribuidos em várias maquinas?

#2

Bom posso te dizer sobre o RMI que eu já usei…
A idéia dele é que vc tenha uma interface no cliente e a implementação dessa interface no servidor, assim quando o cliente precisar ele consegue invocar o método declarado na interface direto no servidor.
Por tanto nesse caso você precisa mesmo dos dois jars…

Se eu errei em alguma coisa alguém por favor me corrija

Abraços
Vinícius

#3

Fala Jaba ,

Seu pensamento está na linha certa cara. Imagine que, por questão de balanceamento de carga, você possui uma mesma aplicação rodando em um cluster de três máquinas. Ainda, imagine que uma delas é mais potente que as outras duas. Se um usuário se loga na aplicação e tenta executar uma operação que é muito pesada, você pode querer executar tal processo na máquina mais “poderosa” (independente da maquina em que o usuario caiu ao se logar). É neste momento que entra a chamada RMI (Remote method Invocation). No momento que você for fazer o lookup da classe que executa o tal processo, você o faria remotamente, passando o ip/nome da maquina em que deseja executar a tarefa. Lembrando que o tal lookup (ação de encontrar a classe no container) é realizado via o JNDI Name da classe, do qual você mencionou em sua mensagem.

Qualquer dúvida estou a disposição.

[]'s

#4

[quote=ViniMunhoz]A idéia dele é que vc tenha uma interface no cliente e a implementação dessa interface no servidor, assim quando o cliente precisar ele consegue invocar o método declarado na interface direto no servidor.
Por tanto nesse caso você precisa mesmo dos dois jars…[/quote]

Como assim no “cliente”? Cliente é o browser, correto?

#5

[quote=Jaba][quote=ViniMunhoz]A idéia dele é que vc tenha uma interface no cliente e a implementação dessa interface no servidor, assim quando o cliente precisar ele consegue invocar o método declarado na interface direto no servidor.
Por tanto nesse caso você precisa mesmo dos dois jars…[/quote]

Como assim no “cliente”? Cliente é o browser, correto?[/quote]

Não. Cliente é o usuário desse serviço remoto. Pode ser uma aplicação web, desktop, ou até uma aplicação feita em outra linguagem.

Aliás, já me intrometendo na seu questionamento, JNDI não está amarrado a RMI. É verdade, a imensa maioria do que é exposto pelo servidor JNDI está, de alguma forma, ligado a JNDI (EJB, que trafega dados usando RMI/IIOP; JCA, que é implementação “enterprise” pra RMI, etc.).

Tudo isso acontece por debaixo dos panos usando o conceito stub/skeleton, que, pra simplificar BEM, são as partes que são conscientes dessa comunicação remota e mandam os dados de um lado pro outro. A idéia é que você exponha o serviço RMI usando uma interface. Essa interface vai num JAR que é conhecido pelo cliente e pelo servidor. A implementação não precisa ser conhecida pelo cliente (já que ele não vai usar a implementação, mas sim, o stub, ou seja, a classe responsável por fazer a invocação remota).

Bom, espero ter ajudado. Qualquer coisa, só perguntar.

[]´s

#6

Certo, entao eu vou ter um cliente com uma Interface, e os servicos remotos com a Implementacao.
Entao, com o cliente, eu posso invocar metodos em objetos remotos em outras VM’s. E como voce citou, asaudate, JNDI pode ate ser usado, mais dei uma pesquisada e vi tambem que o proprio RMI possui um meio de guardar o endereco dos objetos remotos.

Bom, eu nao sei se eu tenho um conceito errado, mas na minha ideia, RMI era pra fazer balanco de carga da seguinte maneira: tenho 3 servidores, com a mesma aplicacao, e o RMI “balancea” automaticamente isso pra mim, por exemplo: tem muita requisicao no servidor 1, entao vamos passar essas requisicoes pro servidor 2, e assim vai. Mas a visao que eu estou tendo disso e que voce tem um servico especifico em um servidor, e voce redireciona o servico para um servidor remoto manualmente, apenas recebendo o retorno final de um determinado metodo.

Entao, qual seria o real proposito? Redirecionar requisicoes que eu sei que sao pesadas para um servidor que eu “configurei”?

#7

Sim Jaba,

O grande propósito de RMI(remote method invocation) é, como o nome mesmo diz, executar métodos, processos, tasks, whatever em uma outra máquina (daí o remoto da coisa). Você pode usufruir deste tipo de chamada em várias situações como: uma aplicação cliente chamando um método em uma aplicação servidor, uma aplicação chamando um método da mesma aplicação em uma máquina mais parruda, e outras mais que sua criatividade possa associar.

No caso de um balanceamento de carga que você mencionou são usadas ferramentas como mod_jk caso queira este serviço vinculado à um servidor web, ou um nginx para demais propósitos.

[]'s

#8

Então, mas algum de vocês já tiveram a real necessidade de usar isso?

#9

[quote=Jaba]Certo, entao eu vou ter um cliente com uma Interface, e os servicos remotos com a Implementacao.
Entao, com o cliente, eu posso invocar metodos em objetos remotos em outras VM’s. E como voce citou, asaudate, JNDI pode ate ser usado, mais dei uma pesquisada e vi tambem que o proprio RMI possui um meio de guardar o endereco dos objetos remotos.

Bom, eu nao sei se eu tenho um conceito errado, mas na minha ideia, RMI era pra fazer balanco de carga da seguinte maneira: tenho 3 servidores, com a mesma aplicacao, e o RMI “balancea” automaticamente isso pra mim, por exemplo: tem muita requisicao no servidor 1, entao vamos passar essas requisicoes pro servidor 2, e assim vai. Mas a visao que eu estou tendo disso e que voce tem um servico especifico em um servidor, e voce redireciona o servico para um servidor remoto manualmente, apenas recebendo o retorno final de um determinado metodo.

Entao, qual seria o real proposito? Redirecionar requisicoes que eu sei que sao pesadas para um servidor que eu “configurei”?[/quote]

Então, acho que você foi um pouco “longe demais” com o conceito =)

RMI é someeeente pra invocação remota de métodos. A parte de balanceamento de carga, assim como outras features, ficam delegadas a APIs que operam com RMI, mas não somente com isso.

E, quanto à necessidade real… é bem raro, mas pode acontecer. Por exemplo, alguns recursos mais “antigos” são acessados via JNI (invocação para DLL´s e afins). A maneira “enterprise” de usar JNI é usando JCA. Que usa, adivinhe o que? Sim, RMI.

Além do que, como eu mencionei antes, EJB opera sobre RMI. Assim, toda vez que você usa EJB, é como se você estivesse usando RMI. Tá certo, exemplo meio forçado, mas só pra mostrar que não é uma tecnologia inútil. =)

[]´s

#10

RMI definitivamente não é inutil… trabalho em um projeto onde grande parte das coisas acontecem com RMI
e o projeto é realmente grande…

#11