Introdução ao RMI

Java Eldar Membro desde: 02/08/2002 12:27:02 Mensagens: 0 Offline

Assunto: Conheça a arquitetura e desenvolva a sua primeira aplicação distribuída.

Você pode ler este tutorial na íntegra <a href="http://www.guj.com.br/servlet/guj?PARSE=true&MAMUTE_ACTION=br.com.guj.action.ListTutorial&MAMUTE_TEMPLATE=ShowTutorial&LIST_TUTORIAL=single&PAGE=1&TutorialId=37">aqui</a>

Por favor, coloque as suas dúvidas e seus comentários sobre este tutorial aqui.
Sinta-se livre para fazer qualquer tipo de pergunta, desta maneira você estará nos ajudando e aos outros usuários!

Muito bom o tutorial. Testei e funcionou ok! Parabéns!
Agora, gostaria de que fosse feito um comparativo paralelo entre o uso do RMI assim como foi apresentado e de um servidor tipo JBoss (prós, contras etc...). Apreciaria muito se alguém podesse comentar isto.
Um abraço à todos.

Não entendi direito o que você quer. Poderia, por favor, especificar melhor?

Obrigado!

Prezado Daniel!
Vamos ver se consigo me expressar adequadamente.
É que eu nunca trabalhei com nenhuma destas tecnologias.
A questão é, eu consigo ter a mesma coisa tanto com uma quanto com outra, certo? (instanciar métodos remotos no 'midlleware', EJB é isto, não é.)
A colocação vai no sentido de, o que se perde/se ganha usando uma ou outra. Quais as vantagens ou desvantagens (gerenciamento, performance, deployment, etc...)
(acho que agora deu ...

)
Um abraço.

Régis,

seu raciocinio esta correto, tanto RMI, EJBs, CORBA, DCOM etc sao frameworks de programação distribuida.

A chamada remota de metodos do ejb possui uma compatibilidade com a chamada de metodos de RMI, por isso dessa confusao.

Na verdade o framework RMI esta presente na j2SE, vc pode fazer aplicacoes utilizando RMI com java standard, o que acontece eh que RMI eh extremamente simples, nao lhe oferece nenhum tipo de servico, ele apenas possibilita que vc crie objetos para serem acessados remotamente.

O CORBA ja possui mais servicos, como transacoes e persistencia, mas esses servicos sao opcionais ao servidor instalado, logo antes de usa-los seu codigo devera ver se estao disponiveis.

O J2ee possui inumeros servicos (persistencia, seguranca, transacoes, relacionamento, clustering, etc) coisas que em RMI puro deverão ser implementadas na mao (fala serio!) e que diferente de CORBA estao sempre presentes, e a maioria delas pode ser feita de forma declarativa (via deploy descriptor) .

Entendeu porque j2ee eh muito melhor?

Abraco,

Prezado Cláudio,

Obrigado pelas tuas colocações. Foram muito claras e vieram de encontro ao que eu estava pensando.
Bom, mais uma, pode ser ? (não querendo abusar da paciência do amigo...)
É o seguinte:
Session beans com JDBC, ou Entity beans com CMP?
O que você acha?
Eu particularmente me sinto muito confortável utilizando SQL puro (uma linguagem que domino a muitos anos), por isto a pergunta.
Funciona legal Session bean com JDBC como framework de persistência ou tem que ser Entity bean com a quele sql maluco lá da Sun???

Um abraço.

Ola Régis,

vc nao abusa da minha paciencia nao, uma vez que sou instrutor aprendo com as duvidas dos outros

, pode ficar a vontade!

Bom quanto a persistencia em J2ee, a coisa eh mais em baixo! Nossas possibilidades sao basicamente 3:

Session + DAO
Entity BMP + DAO
Entity CMP + EJB QL

A escolha pela utilização de qualquer tipo de Entity (CMP ou BMP) se da por varios fatores, vale um estudo mais profundo, mas por exemplo: concorrencia nos dados (o container sincroniza o acesso aos entitys automaticamente), transação (o proprios metodos demarcam transacoes)

Agora a utilização de CMP ou BMP levanta outras questoes como portabilidade do seu SQL e principalmente velocidade de desenvolvimento.

Na verdade a resposta da sua perguta seria: Todos os 3 ao mesmo tempo, como assim? Simples:

-para persistencia simples de dados com relacionamentos dentro de um mesmo subsistema vc da preferencia por cmp;
-para um persistencia mais complexa, com relacionamento entre subsistemas diferentes use entity bmp;
-para pesquisas que utilizam muitos dados e/ou de muitos subsistemas utilize Session Beans com DAO;

Isso eh o que fazemos por aqui!

[Glossario]
DAO - Desing Pattern para persistencia, utiliza um factory para que a caso haja mudanca de servico de persistencia (de Oracle para cache ou para DB2 por exemplo) a mudanca seja transparente;

Entity CMP - EJB para persistencia com todas as querys autogeradas pelo container, customizacoes com EJB-QL e metodos ejbSelect;

Entity BMP - EJB para persistencia que se utiliza de um BMP, pode aplicar estrategias de atualizar ou nao o db para melhorar a performance;

Abraco,

Smalltalk Membro desde: 08/04/2003 14:32:56 Mensagens: 2 Offline

Olá a todos,
como têm passado ?

seguinte:
Estava lendo no guj a matéria sobre RMI, e estou com uma dúvida:
RMI mantém o mesmo objeto entre uma chamada e outra de métodos (statefull) ?
Ou é como os webservices, que são stateless, (ou seja, a cada chamada de método uma nova instância do objeto é criada) ?

obrigado
Alessandro

Alessandro,

rmi mantem estado entre as chamadas mas:

no rmi a coisa ta toda na sua mao, na verdade, quando algum cliente faz lookup sempre recebe O MESMO objeto, logo se vc alterar o estado do objeto todos clientes irao ver as alteracoes (como nas servlets).

Em RMI nao tem essa historia de interface home com metodo create, se vc quiser vc pode criar algo parecido com isso, ou seja, criar uma factory que cria um objeto remoto para cada cliente novo (cada cliente tem seu objeto e nao ve as alteracoes dos outros), mas infelizmente nao tem nada pronto!

Abraco,

Oi Cláudio.
Beleza de exposição.
Ainda sobre esta questão. (e ainda abusando... :lol

Se eu gostasse tanto de SQL puro que resolvesse utilizar apenas Session Bean com JDO, por exemplo, eu teria como demarcar minhas transações? E mais, estaria fazendo a coisa corretamente escolhendo esta opção?
Quer dizer, do seu ponto de vista, não utilizar Entity (BMP ou CMP) seria um pecado mortal em termos de projeto???

Um abraço.

Régis Steigleder wrote:
Se eu gostasse tanto de SQL puro que resolvesse utilizar apenas Session Bean com JDO, por exemplo, eu teria como demarcar minhas transações? E mais, estaria fazendo a coisa corretamente escolhendo esta opção?
Quer dizer, do seu ponto de vista, não utilizar Entity (BMP ou CMP) seria um pecado mortal em termos de projeto???
Um abraço.

Po, se vc gostasse tanto de SQL puro, vc usaria JDBC, não JDO

Creio que seria impossível, ou bem complicado, o controle transacional dos SFSBs... Uma opção mais viável seria usar SFSBs+SLSBs+Hibernate (hibernate.sf.net). Tem até uns tutoriais sobre isso, e sobre como funciona o controle transacional no site do Hibernate.

Sobre ser um "pecado" ou não, bem, isso quem vai dizer é o sucesso do seu projeto (tanto em implementação quanto em tempo de manutenção)

... adiantando a resposta: não é pecado, e é bem útil em alguns casos raros, mas fazer isso "por esporte" é burrada

Bom amigo, seguindo a resposta do irmao Villela (fala carlao!),

na verdade realmente acredito que seja um erro de design, uma vez que o gerenciamento de recursos com Entity eh incomparavel com collections de vos/tos, se vc levar em consideracao que um entity na memoria sera compartilhado, e que podera ser passivado localmente o ganho de performance/escalabilidade eh realmente consideravel.

Mas caso vc ame realmente o SQL/jdo

vc pode demarcar suas transacoes sim, so que o driver do datasource utilizado devera ser XA, senao ele nao podera fazer parte de uma transacao distribuida.

Abraco,

Pessoal.
Sou um principiante empolgado com a plataforma Java.
Entretando gosto de ver as coisas funcionando na prática.
Esse exemplo do tutorial RMI foi realmente muito didático e simples de ser entendido. Agora gostaria de saber como rodá-lo em um servidor real, usando a Internet como meio de comunicação...
Valeu..
Mauricio Moraes

Se você seguir o tutorial mesmo, você pode rodar o aplicativo cliente em uma máquina e o servidor em outra....

Não há a necessidade de todas as classes estarem nos dois ambientes. Apenas as classes relacionadas (cliente/servidor).

Só tome cuidado e altere no código o endereço do servidor (localhost pelo ip ou nome da máquina na rede). Tente customizar isso usando parâmetros externos (properties ou parametros do console).

Abraços

Fala galera,

bao, se vai rodar na Internet se ligue tb nos firewalls (se vc usa firewall na sua maquina tambem), a porta devera estar liberada.

Abraco,

Claudio

Notícias, artigos e o maior fórum brasileiro sobre Java