Hoje estou fazendo um sistema distribuido mas, gostaria de fazer isso de forma transparente! Nao quero programadores fique quebrando a cabeca para tratar objetos remotos de uma forma e objetos locais de outra!
Hoje tentando fazer as primeiras distribuicoes dos objetos atraves de RMI toda minha transparencia foi para o buraco! Tudo isso gracas a:
Se eu quero tornar uma interface remota todas as interfaces acima dela devem ser remotas. Com isso interfaces que eu nem usarei remotamente acabam tendo que ser, so porque esta acima de uma interface remota;
Todos os metodos que sao de uma interface QUE PODE ser usada remotamente deve gerar RemoteException. Com isso mesmo que use essa interface em um sistema nao remoto eu vou ter que tratar RemoteException mas, pra que? meu sistema nao e remoto!
RemoteException poderia pelo menos ser uma excecao nao checada, assim eu poderia marcar minhas interfaces como remotas e so tratalas como remotas onde eu quiser. Nos outros lugares eu as trataria de uma forma unica independendo elas serem remotas ou nao.
Bom solucoes que eu pensei:
Colocar minhas interfaces como remote mas em vez dos metodos lancarem RemoteException, lancar Exception. Assim eu nao preciso me preocupar se um objeto e remoto ou nao, se eu quiser trata-lo como remoto so basta eu tratar RemoteException na cadeia. O unico problema e que metodos que nao geram excecao passam a poder gerar para o caso deles serem utilizados remotamente; E vai rolar gatilho vai rolar… Gatilhoooo Gatilhooo…
Colocar uma camada de integracao onde eu tenho adaptadores de objetos locais para objetos remotos e tambem o inverso adaptadores de objetos remotos para objetos locais.
O que voces acham de tudos isso? Dos problemas? Das solucoes? Comos vcs ja fizeram?
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.
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.
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