RMI Transparente

Algumas considerações:

1. Transparência é uma faca de dois gumes. É bom enquanto está tudo certo (rede, servidores, etc). Na hora em que elementos do seu sistema ficam indisponíveis, o tratamento de exceções fica um tanto enrolado. Outro problema é que, se seu framework permitir objetos arbitrários, vc. corre o risco de ter chamadas RMI para simples setters/getters, com impacto direto na performance do sistema final.

2. IMO uma abordagem mais interessante é ter a possibilidade de distribuir atividades, e não diretamente objetos. Algo parecido com o modelo utilizado no Prevayler, onde o subsistema de persistência possui métodos que “executam” um objeto “transação”. Extrapolando para um cenário distribuido, o que vc teria é uma interface de execução, obtida de alguma maneira, que recebe um objeto que implementa uma atividade auto-contida - atualizar dados de um cliente, pex. A camada de execução pode executar atividade localmente ou mandá-la para outro nó para execução remota.

Bruno, primeiro que RPC é uma péssima abstração para construir sistemas distribuídos, depois que abstrair esse fato garante um problema ainda maior.

O problema de construir uma abstração para RPC é o fato de não operar de forma uniforme, ou seja, vai ser sempre ocorrer um abstraction leak quando ocorrer erros de rede.

Um sistema Java não pode ser construido de maneira igual usando RPC transparente pois o modelo de falha para elementos remotos e locais é completamente distinto. Além disso, existe o problema de gerar abuso do uso de chamadas remotas, levando seu sistema a ficar uma carroça quando entrar no ar em ambiente realmente distribuído.

O psevestre deu uma boa sugestão, prefira por particionamento por atividades e construa uma camada de integração que cuida da interação com os componentes remotos.

Caso não seja possivel fazer isso, construa então uma camada de integração que seja responsavel pela interação com os poucos elementos remotos, eles são poucos, certo?. Dessa forma você pode expor uma interface mais simples e menos sucetivel a erros para os desenvolvedores upstream.

Lembre que sistemas remotos devem expor pouquissimas interfaces, de preferencia idepotentes, que são coarse-grained - isto é, carregam muita semântica e atividades em uma única ativação.

Fala Louds, PSevestre!

Vcs querem me matar???

Pesada as respostas de vcs… Sou novato nessa historia de sistemas distribuidos! Mas to me divertindo tbem…

Escolhi minha solução numero 1!

Por enquanto esta Quase td indo bem…

Meu sistema esta permitindo o uso de objetos arbitrarios, até aqui acho que as responsabilidades estao bem definidas e a granularidade ta mediana nem grossa nem fina, isso faz com que eu não perca tanta performance assim. Eu nuca crio os objetos em uma maquina para depois transferi-lo para a maq que ele vai residir eu o crio direto na maq que ele vai residir etc…

Hj o trafego de objetos não é tao intenso assim no meu sistema acho que é por isso que ele ainda não virou uma carroça! Vamos ver para o futuro!
Olha no que o eXtreme ta me transformando, faço o mais simples que me atenda hj o futuro eu deixo para resolver no futuro! Virei quase um zeca pagodinho deixa a vida me leva vida leva eu rs…

Ficou meio enrolado na hora de tratar as exceções de forma uniforme mas acho que ficou bom por enquanto… Só há abstraction leak quando eu quero e isso na maioria das vezes é só na horar de gerar log ou mostrar msg para os usuários.

Psevestre como o seu ex: A camada de execução pode executar atividade localmente ou mandá-la para outro nó para execução remota.
Isso acontece no meu sistema só que o mais interessante é que ele não sabe a diferença de executar algo remoto de executar algo local.

Ae galera desculpe minha ignorancia mas se eu não for usar RPC o que eu vou usar?Vejo RMI como RPC tbem!

[]s

Enquanto isso vou digerindo um pouco mais das suas respostas… rs depois eu volto