Criando aplicações desktop cliente / servidor, sem programação no cliente

10 respostas
P

Olá.

Tenho a seguinte situação.

Desejo fazer uma aplicação desktop cliente / servidor, porém toda a programação, ficaria no servidor. Explicando melhor.

No servidor, são criadas as telas em Swing, a programação e os eventos.

No cliente, haverá apenas uma API genérica para tratar as solicitações recebidas, de forma, que a aplicação cliente não precise ser atualizada se alguma tela for adicionada na aplicação servidor, ou qualquer outro componente e afins.

Comecei a fazer alguns testes utilizando conexão via Socket. Quanto a conexão, sem problemas, porém o complicado é fazer todos estes tratamentos.

A minha dúvida seria se existe alguma API para ajudar neste processo, algo que implementasse algo similar a isto?
Ou se existe algum framework que implemente ou auxilie esta situação?
Devo utilizar J2EE para fazer uma aplicação assim? Por onde começar?

Desde já, agradeco qualquer ajuda.

Valew!

10 Respostas

L

Porque vc não faz uma aplicação J2EE??? bem mais em conta…

R

Você quer fazer uma aplicação desktop, porém com tudo no servidor apenas executá-la no cliente?

Caso seja isso, Java Web Start seria uma boa opção.

B

Ola,

Bom, vamos lá, vc quer criar uma aplicação total só server-side, e o cliente, toda vez que executar irá ter que fazer o download dela, isto é, telas, eventos… e tudo o mais…

Meu, seguinte, isto será muito custoso, em relação a tráfego de rede, trabalhoso em relação a serialização de objetos, e usar socket??? recomendo fortemente usar RMI, mais rápido e parudo pra isto, e outra, pq vc não junta a idéia do colega e faz tudo como manda o figurino em uma aplicação cliente/servidor, crie sua camada de negocio e afins, persistencia no servidor e no cliente os caras para cuidar da view, e crie uma camada de comunicação entre os dois… e para gerenciar atualizações e afins coloque ele em JWS, é tranquilo de fazer…

P

leopoldof, esta era exatamente uma das minhas dúvidas, se eu deveria usar J2EE para fazer uma aplicação assim. Creio que seja a melhor solução realmente.

RicardoLuis, o JWS não seria apenas para eu controlar a versão utilizada pelo cliente? No caso, toda vez que ele rodar, ele irá verificar se há uma nova versão e baixar esta nova versão, correto? Porém, a implementação ainda estaria no lado cliente… Se o JWS for realmente somente para isto, já está implementado.

BrunoCarlo, para eu utilizar o RMI, eu precisaria ter no caso a classe criada no lado cliente, com os stubs e skeletons, correto? No caso, eu não teria esta classe criada no cliente, apenas uma classe genérica para processar as telas enviadas pelo servidor…

No caso, o que dizes fazer tudo como o figurino manda, seria utilizar o J2EE para fazer isto?

Agradeço as respostas de todos! Valew!

B

Sim, vc teria as classes trafegando pela rede, mas isto não é ruim, em termos de segurança, se for a sua preocupação.

Bom, para fazer “tudo como manda o figurino” vc pode usar diversas coisas… ou só o JSE, não é tão necessário usar JEE, sabendo que:
RMI, Swing, JDBC, e afins faz parte do JSE.

P

A escolha do RMI ao invés de Socket, seria por ele ser mais rápido, mais eficiente ou por trabalhar em mais alto nível?

Posso usar o RMI tanto para internet quanto para redes internas?

Estava testando via socket porque esta aplicação iria ficaria disponível para uso na internet também.

Att,

Puri

B

Puri:
A escolha do RMI ao invés de Socket, seria por ele ser mais rápido, mais eficiente ou por trabalhar em mais alto nível?
Posso usar o RMI tanto para internet quanto para redes internas?
Estava testando via socket porque esta aplicação iria ficaria disponível para uso na internet também.

Pois é, o RMI trabalha mais em alto nível, de forma a facilitar MUITO o trabalho do desenvolvedor, a manutenção, arquitetura do projeto, e ele trabalha tranquilamente em redes internas e internet…

P

BrunoCarlo:
Puri:
A escolha do RMI ao invés de Socket, seria por ele ser mais rápido, mais eficiente ou por trabalhar em mais alto nível?
Posso usar o RMI tanto para internet quanto para redes internas?
Estava testando via socket porque esta aplicação iria ficaria disponível para uso na internet também.

Pois é, o RMI trabalha mais em alto nível, de forma a facilitar MUITO o trabalho do desenvolvedor, a manutenção, arquitetura do projeto, e ele trabalha tranquilamente em redes internas e internet…

Entendi.
Muito obrigado a todos, vou testar mais sobre o RMI e as sugestões dadas.

Valew!

O

A sua proposta original é mais ou menos como funciona a arquitetura do Oracle Forms via Web:
http://www.oracle.com/technology/products/forms/pdf/275632.pdf

Ele instala um applet que é um runtime que se comunica com o servidor para obter o código e os dados.

Usando a idéia de Java Web Start, existe uma API (JNLP API) que pode auxiliar na parte de sincronização de código com o servidor. Eu nunca usei isto e não entendi bem como funciona.

S

O JWS é uma forma de vc mandar a aplicação cliente para o lado do cliente quando necessário mas ele está no servidor.
Se vc precisa alterar vc altera e coloca no servidor, o JSW irá atualizar de forma que o cliente sempre usa a versão mais recente.
Esta é a solução correta para aquilo que vc quer. Outra opção é usar Applets que dá no mesmo mas a apliação fica dentro do browser embutida em uma página html.

Não. Com o JWS todas as classes estão no servidor. Todas elas são enviadas ao cliente. Portanto fazer RMI instá incluso porque o escopo das classes é único. O ponto é que RMI não é bom para fazer comunicação swing. Use (webservices) REST que é mais fácil.
Vc simplesmente manda xml (ou outro formato) com os dados e interpreta no cliente ( que vc ppr fez)

Em JEE vc faria o cliente em Swing, usaria o JWS para o deploy e EJB Session Stateless para a comunicação ( que usam RMI por baixo dos panos sem nenhum trabalho para si). Isso é a forma JEE , mas existem problemas usando EJB remotos, por isso o REST é melhor. ( o serviço REST pode usar os Session Beans localmente se necessário)

Criado 9 de setembro de 2008
Ultima resposta 9 de set. de 2008
Respostas 10
Participantes 6