Swing para Servidor Tomcat, está correto assim??

This message was edited 5 times. Last update was at 28/03/2008 10:14:16

Olá.. antes de iniciar gostaria de dizer que pesquisei bem no forum e no google antes de postar, mas mesmo assim nao encontrei respostas.

Estou estudando e fazendo uma aplicacao desta forma:

CLIENTE DESKTOP --> SERVIDOR TOMCAT --> HIBERNATE --> FIREBIRD

Sendo que meu os clientes são vários (umas 8 maquinas), e mais adiante terá tambem web.
Uso no cliente o Genesis, faço pelo URLConnection para mandar para o servidor, recebo pelo Servlet e gravo com o DAO pelo hibernate.
Tudo ok e funfando....

Mas estou com dúvidas sobre a arquitetura e a forma como estou realizando. Na verdade "sinto" que tem algo errado, apesar de funcionar. Ou pelo menos incoerente. Para efetuar um cadastro de um cliente, por exemplo, faço da seguinte maneira:

A tela Swing faz o binding dos dados para um bean (POJO). Este bean é encapsulado em um List, junto com uma String indicando a operacao com ele: "gravar", "alterar" e "excluir". Entao na List terá sempre uma String operacao e um Object bean. Jogo entao a List para o stream do URLConnection.

No servidor, o servlet recebe esta List e separa a String operacao com o Object bean passado. Conforme a operação, ele "grava", "altera" ou "exclui" do Firebird pelo DAO com Hibernate. Criei classes "genéricas" (mas nao com generics do java 5) com o DAO recebendo Objects.

Como disse isso funciona. Mas a passagem dessa List do cliente para o Tomcat é trivial?? Existe algo mais simples ou correto para isso?? Falo isso para tecnologias atuais utilizadas e detrimento de outras "antigas", como EJB3.0, que ao meu ver aparenta ser mais complicado do que estou fazendo. Lembrando que o cliente é Swing. O que acham melhor para esta solução? Qual implementacao seria o ideal para passagem cliente/servidor?? Enviar objetos e/ou listas pela rede é legal?? Porque se eu enviasse os dados ao invés do objeto Cliente pronto, é pior não?

Gostaria de um cliente "magro" e tudo no servidor, mas de forma simples e atual, sem 150325487 milhoes de linhas configurações e usando Java, de forma leve. Dessa forma como faço, me aparenta mais transparência, mas está correto? Sinto "perigoso" essa forma, mas nao sei onde está o erro!!

jopss

This message was edited 1 time. Last update was at 28/03/2008 10:11:46

duplicado...

Olá

Se o banco de dados está no servidor e o cliente funciona apenas como uma camada de apresentação mais poderosa, então está como eu sempre achei que deveriam ser os sistemas desktop (sistemas que são chamados a partir do desktop como o Firefox, azureus, etc. sem misturar esta expressão com sistemas isolados como os burros da Sun fazem).

[]s
Luca

This message was edited 1 time. Last update was at 28/03/2008 10:20:41

Sim o bd está no servidor e o cliente somente serve para apresentar. Mas a forma de enviar uma List com a operacao e o objeto pelo URLConnection estaria "nos conformes" ou tem algo melhor a fazer??

jopss

Olá

jopss wrote:... a forma de enviar uma List com a operacao e o objeto pelo URLConnection estaria "nos conformes" ou tem algo melhor a fazer??

A forma de enviar e o protocolo das mensagens depende do sistema. Quando a gente tem muitos cliente como no caso do Banco Postal por exemplo com mais de 10 mil clientes swing, as mensagens precisam ser as mais simples possíveis. Mas com poucos clientes serialização dá certo. Quanto a sugestão de melhoria só posso lembrar do pacote HttpClient que faz poucas coisa a mais do que o UrlConnection mas vale a pena usar porque resolve algumas limitações da classe UrlConnection.

[]s
Luca

This message was edited 1 time. Last update was at 28/03/2008 10:32:26

opa.. vlw pela resposta... mas oq seria:

...as mensagens precisam ser as mais simples possíveis....

Nao vejo uma implementacao mais simples e rápida do que trafegar "objetos prontos" pela rede....

jopss

Olá

jopss wrote:Nao vejo uma implementacao mais simples e rápida do que trafegar "objetos prontos" pela rede....

Objetos prontos às vezes carregam informações demais. Imagine a diferença entre trafegar nome/senha recebendo resposta SIM/NÃO e trafegar classes inteiras. Se usar SSL então a demora será maior ainda.

[]s
Luca

Mas dae, por exemplo, em caso de Clientes, Funcionarios, Produtos, etc.. que possuem mais dados, trafegar as informacoes em separado não causaria aumento na rede??? (falo isso num projeto como esse meu, mas para uns 10mil usuarios, como vc mencionou).......

e pra finalizar:
E sobre o HTTPCliente, é o da apache nao? o 4.0alpha será que tem mt bug ou uso o 3.1 mesmo?

jopss

Olá

jopss wrote:Mas dae, por exemplo, em caso de Clientes, Funcionarios, Produtos, etc.. que possuem mais dados, trafegar as informacoes em separado não causaria aumento na rede??? (falo isso num projeto como esse meu, mas para uns 10mil usuarios, como vc mencionou).......

e pra finalizar:
E sobre o HTTPCliente, é o da apache nao? o 4.0alpha será que tem mt bug ou uso o 3.1 mesmo?

jopss

As informações não trafegam separado em caso nenhum. Elas poderiam ir como CSV, XML ou outro formato qualquer. Serialização é vantagem para o programador (bom) mas tem umas pequenas armadilhas no caso em que se necessita de alto throughput.

Use a versão estável do HttpClient.

[]s
Luca

This message was edited 4 times. Last update was at 28/03/2008 14:16:23

No projeto que trabalho atualmente usamos uma arquitetura parecida: cliente em Swing - também usamos Genesis; acessando uma aplicação web - usamos JPA/Hibernate.

A grande diferença fica no fato que não temos servlets no nosso projeto. Usamos o Spring, tanto no cliente quanto no servidor, e disponibilizamos serviços usando o Spring Remoting. Veja: http://static.springframework.org/spring/docs/2.5.x/reference/remoting.html#remoting-httpinvoker.

Dessa forma, a arquitetura fica bem parecida com o que seria usado com EJB 3. Seria algo como RMI/RPC via http.
No servidor temos o modelo com a lógica de negócio, os DAOs e os serviços - que recebem os DAOs por injeção de dependências. Os serviços apenas delegam as chamadas para o modelo e os DAOs.

Só pra ter uma idéia, vou colocar alguns trechos de código para ilustrar melhor como fazemos:

No servidor:

No cliente:

Lembrando que os códigos são apenas de exemplo por isso não coloquei a implementação da interface.

Também não sei se é a melhor opção, mas tem funcionado bem para o nosso projeto.

[edit]
Esqueci de comentar: o Spring no servidor também nos dá outras vantagens como controle de transações declarativo e suporte para JMS.
[/edit]

Olá

Matheus Tardivo wrote: Seria algo como RMI/RPC via http.

Me considero experiente neste tipo de arquitetura e também com boas noções de rede e de integração de sistemas. Feito este preâmbulo, quero dizer que só em condiçoes muito especiais esta arquitetura pode ser melhor do que usar servlets ou outra solução mais desacoplada ainda como JMS.

Só de passagem gostaria que estudassem um pouco de história e verificassem sob quais circunstâncias e para quais aplicações RMI foi desenvolvido. Sei que aqui tem muitos fãs de RMI mas eu, que sou mais velho, não vejo porque adotar uma solução antiga quando hoje em dia temos muitas outras coisas melhores. Fora o fato de que RPC deve ser evitado ao máximo em qualquer sisteminha que a gente faça.

[]s
Luca (gosto do Spring mas Spring Remoting não foi feito para usar na camda de apresentação)

gosto do Spring mas Spring Remoting não foi feito para usar na camada de apresentação

É... assim.... por que?? (não conheço Spring Remoting)
Matheus Tardivo, tenho umas duvidas sobre o Genesis... poderia me dah um help?? Se puder add meu email que é meu msn....

jopss

Olá

jopss wrote:É... assim.... por que??

Para mim a camada de apresentação deve ser a mais leve possível e eu só admitiria usar RPC quando não tivesse outra alternativa e mesmo assim só se for um sistema muito pequeno que não vai crescer nunca tanto em número de usuários como em termos de serem incluídas novas facilidades no futuro.

Este papo só está acontecendo porque o Genesis induz o usuário a adotar esta arquitetura engrunvinhada, acoplada, pesada, enxuriçada, etc. e tal que para mim não faz sentido. Já comentei isto com o Michael e ele respondeu que esta não é a única arquitetura do Genesis e que só usa quem quer. Para mim seria melhor que o Genesis não admitisse esta arquitetura com EJBs/RMI/etc. no cliente.

[]s
Luca

Luca wrote:Este papo só está acontecendo porque o Genesis induz o usuário a adotar esta arquitetura engrunvinhada, acoplada, pesada, enxuriçada, etc. e tal que para mim não faz sentido. Já comentei isto com o Michael e ele respondeu que esta não é a única arquitetura do Genesis e que só usa quem quer. Para mim seria melhor que o Genesis não admitisse esta arquitetura com EJBs/RMI/etc. no cliente.

Olá Luca.

Só pra entender melhor: qual problema você vê no cliente usando RPC? Estou perguntando isso pra entender melhor mesmo, não estou defendendo o meu ponto de vista.

Por que o cliente usar HttpClient enviando e recebendo objetos serializados é melhor?

Usando RPC, no caso do Spring Remoting, você executa um método remoto, através de um proxy via http, que pode enviar e receber objetos serializados. Qual seria a diferença do HttpClient? O proxy no cliente?

Desculpe a quantidade de perguntas (ainda tinha outras), mas realmente quero entender melhor o seu ponto.

Olá

Matheus Tardivo wrote:Só pra entender melhor: qual problema você vê no cliente usando RPC? Estou perguntando isso pra entender melhor mesmo, não estou defendendo o meu ponto de vista.

Por que o cliente usar HttpClient enviando e recebendo objetos serializados é melhor?

Usando RPC, no caso do Spring Remoting, você executa um método remoto, através de um proxy via http, que pode enviar e receber objetos serializados. Qual seria a diferença do HttpClient? O proxy no cliente?.

Executar um método remoto é exatamente o problema do RPC. Acopla os 2 sistemas. O ideal é que as partes do sistema troquem mensagens e de preferência de forma assíncrona sem que nenhum dos lados exponha sua API. Sem expor a API, a gente no futuro pode alterar a classe, o método e trocar tudo, inclusive a API.

Quero deixar claro que ainda acho que RMI e RPC podem ser usados em um sistema. Quer saber onde? Com JMX por exemplo porque JMX é acessado por pouca gente aom mesmo tempo e porque o RMI é apenas um conector fácil de usar. Mas na arquitetura de negócio do sistema só se for um programinha muito simples do tipo bacalhau para quebrar um galho isolado.

[]s
Luca

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