Padroes de Projeto AJUDA - discussao... Help

Buenas galera.
Tou precisando de uma ajuda.
Seguinte, vou tentar simplificar meu dilema.

Minha aplicação Cliente pode ser tanto por RMI quanto por XML-RPC.
Ela acessa a aplicação Servidora, e depois a aplicação servidora tem que guardar o tipo de conexao para poder chamar de volta.

tenho um Objeto Jogador.
Este tem nick, senha, tipo_conexao

tenho meu objeto Servidor

neste, tenho um método chamado Login(nick, senha, tipo);

Meu cliente RMI
chama remotamente uma classe que interceptaria… faria a comunicaçao do cliente com o servidor por RMI,
ou seja.
Ela tem uma interface remota(que extends Remote), e seus métodos tem que declarar throws RemoteException.

o objeto Interceptador…
seria um objeto chamado ServidorRmi


O cliente acessaria um método Login(nick, senha);

O ServidorRmi pega o Servidor
e repassa o método… chamando Login(nick,senha,tipo_conexao_rmi);

e o inverso com o Objeto ServidorXml que passaria conexao_xml …

isto seria um adapter…
da minha classe que mantem o contato com o cliente… que sabe qual seu tipo de conexao, e repassa para o método do Servidor…

Eu poderia considerar que meus objetos de comunicação com os clientes… sao Proxys do Servidor ??

eles nao implementam a mesma interface…mas teriam as mesmas funcionalidades…

Muitos vao dizer que é apenas o padrao adapter… nao é proxie…

vamos ver…

agora,
se eu tivesse a mesma situação, so que sem o método login ser adaptado…
Seria praticamente a mesma assinatura, mas porem, entretanto,

Os comunicadores com o cliente e o Servidor propriamente dito… nao implementariam a mesma interface…
pois is métodos de comunicao por ex do rmi… tem que dar throws RemoteException… e do servidor NAO…
apesar de ser o mesmo nome de método e mesmos parametros…
esta mudança no throws RemoteException , e a nao implementaçao realmente da mesma interface para os objetos…
iria descaracterizar a definição de Proxy … feita pelos comunicadores ServidorXml e ServidorRmi

???

Acho que podemos melhorar um pouco isso…

  1. Por que você precisa guardar o tipo de conexão no servidor?
  2. Você tem 2 interfaces diferentes para seu cliente se comunicar. Na primeira ele acessa por RMI e trafega objetos serializados da maneira tradicional do Java. Na segunda interface ele acessa por XML-RPC e trafega XML (e.g objetos serializados em XML ou XML montado que seja).
  3. Solução. Faça dessas interfaces sua camada de apresentação. Crie uma camada de aplicação que vai ser comum. Dai pra baixo fica a teu critério, mas isso já resolve o problema de duplicação.

[]s

R: Nao sao os clientes que ficam perguntando de temo em tempo se algo aconteceu. O servidor comunica aos clientes sobre os eventos ocorridos. .
Entao tenho que guardar o tipo de conexao para saber diferencia-los, e uma referencia…
no caso RMI uma interface proxy que o meu cliente envia em um método.
no caso XML-RPC o ip e porta do servidor. para que eu possa instanciar um WebServer do cliente…

Resumindo o cliente tambem é um servidor.

Queria saber se por meu objeto digamos “procurador” , nao implementar a mesma interface do objeto procurado.
ou até em alguns casos usar do adapter para acessar um método do procurado…

anularia a definição de Proxy do meu objeto “procurador”.

Eu não to conseguindo entender ao certo o que você quer fazer mas ta parecendo que você tem escolhas melhores para isso tipo o protocolo XMPP. Já de uma olhada?

ola,
nao conheço este protocolo ainda
vou ver se encontro algo…
se tiver algum material ou referencia…

mas, a minha duvida nao é quanto a implementação da comunicação…
e sim quanto a definição do padrao de projeto.

a minha aplicação eh um servidor de jogo…
o servidor eh feito em java…
e ha principio os clientes podem ser ou rmi… ou xml-rpc

inicialmente tinha duas opçoes…
os clientes ficavam perguntando ao servidor o que estava acontecendo…
com threads…
“tem mensagem?” , “tem mensagem?”, “aconteceu algo?”

ou os meus clientes seriam tambem servidores…
e ficariam como listeneres do servidor…

o servidor mantem uma referencia para o servidor do cliente
quando acontece algo
o servidor percorre todos os clientes conectados… avisando do evento…