Java Desktop com cliente magro

Lauro, até hoje não vi muito interesse em implementar um thin client com swing (são vários os motivos por preferirem web). Mas o conceito pode ser aplicado da mesma forma. Você passaria a deixar as regras de negócio no servidor e acessa-las por objetos remotos com a tecnologia de sua preferência ou mais adequada para o seu caso (spring, ejb, rmi mesmo, etc). Ou seja, o seu cliente swing seria apenas uma forma de apresentação para o seu sistema, que conteria apenas regrinhas de validação de tela, preenchimento dos DTOs (ou quem sabe acesso remoto das entidades), enfim, tela.

Você pode instanciar os seus EJBs do servidor atraves de RMI, assim como qualquer cliente web.

ok… mas seria possivel por exemplo… eu passar um objeto instranciado para do cliente para o servidor, e nao passar parameters como se faz no jsp… com request e response…
queria saber assim… se dava pra eu passar um objeto instanciado pra um metodo do servidor e ele me retornar um boolean… + - isso?

Pode passar o objeto como parâmetro de um método no EJB por exemplo.
Mas o problema é que todo objeto que você precisa instanciar na camada Swing, vai ter de ser empacotado junto com o jar do cliente.

entendi… entao eu tenho que ter a classe so meu objeto tanto no cliente como no servidor

ainda estou desenvolvendo sistemas relativamente pequenos… no servidor fica apenas o banco de dados…( ultimamente o firebird ) e cada cliente tem um .jar com a aplicacao completa…
isso é errado?

Lauro. Aqui desenvolvemos aplicações swing que acessam um servidor de aplicação através disso
http://static.springframework.org/spring/docs/2.5.x/reference/remoting.html

Funciona blz. Como o rafael falou, todo objeto que trafega entre o servidor e o cliente deverá estar num
jar dentro do classpath do cliente.

mas o que eu disse acima é correto? ou não é correto nem incorreto?

opa!! então cara, se precisasse do objeto também no cliente seria osso neh… hehehehe ai não teria o porque fazer distribuido

no cliente você soh precisa dos “stubs”, que são apenas as interfaces dos seus EJB… os EJBs propriamente ditos, apenas no server.

quanto ao sistema que vc descreveu, poderia deixar TUDO referente a regras de negocio no server, e nos clients deixar apenas a camada de apresentação (o swingão).

Olá

Não usem RMI para comunicação entre o cliente e o servidor se pretendem que sua aplicação cresça muito

fabiofalci:

Lauro. Aqui desenvolvemos aplicações swing que acessam um servidor de aplicação através disso

http://static.springframework.org/spring/docs/2.5.x/reference/remoting.html

Funciona blz. Como o rafael falou, todo objeto que trafega entre o servidor e o cliente deverá estar num
jar dentro do classpath do cliente.

Porque optaram por fazer RPC ao invés de apenas trocar mensagens usando um simples servlet? A simples troca de mensagens escala muito melhor.

[]s
Luca

Olá

Não faça isto. A vida pode ser muito mais simples do que isto.

Use EJBs 3.0 no servidor mas nunca no cliente.

[]s
Luca

A troca de mensagens pelo servlet eu nunca utilizei, mas acredito que seria através de sockets se comunicando via GET certo ?

Se for isso cara, pode ateh ter mais escalabilidade, mas a manutenabilidade piora bastante… o codigo fica maior e mais complexo, tem q trabalhar com multithreading no socket, etc…

Acho que o RMI não foi criado a toa

Como disse o luca num post

“Sistema que o cliente acessa direto o bando de dados está obsoleto desde o milênio passado.”

apenas complementando oq o fabiofalci falou, fazendo isso voce perde toda a razão de existir dos EJBs, pois tudo aquilo que o container ejb faz pra você de controle de transação, e entidades jpa não serão utilizados.

Olá

gibaholms:

A troca de mensagens pelo servlet eu nunca utilizei, mas acredito que seria através de sockets se comunicando via GET certo ?

Se for isso cara, pode ateh ter mais escalabilidade, mas a manutenabilidade piora bastante… o codigo fica maior e mais complexo, tem q trabalhar com multithreading no socket, etc…

Acho que o RMI não foi criado a toa

Errado, o código fica MUITO mais simples, a manutenção é MUITO mais simples, não usa socket (diretamente, é claro que se usa por debaixo dos panos - o tomcat usa, o JBoss usa, etc.), quem cuida do multi threading é o servidor e o RMI foi criado para isto em uma época em que a Microsoft criou DCOM e era a solução RPC do Java. RPC é lixo. RMI só deve ser usado dentro do lado servidor junto com JMX.

[]s
Luca

cara, não consegui entender como seria isso… como que o cliente receberia as respostas do servlet ??

explique melhor essa solução

Olá

gibaholms:

cara, não consegui entender como seria isso… como que o cliente receberia as respostas do servlet ??

explique melhor essa solução

Como já disse em outro tópico: usando URLConnection diretamente ou embutido dentro de HttpClient (serve para facilitar). As mensagens podem ser qualquer coisa: XML, CSV, etc. Mas o ideal é que sejam o mais simples possível. Se precisar elas podem trafegar criptografadas usando SSL.

[]s
Luca

Luca:

Olá

Não usem RMI para comunicação entre o cliente e o servidor se pretendem que sua aplicação cresça muito

fabiofalci:

Lauro. Aqui desenvolvemos aplicações swing que acessam um servidor de aplicação através disso

http://static.springframework.org/spring/docs/2.5.x/reference/remoting.html

Funciona blz. Como o rafael falou, todo objeto que trafega entre o servidor e o cliente deverá estar num
jar dentro do classpath do cliente.

Porque optaram por fazer RPC ao invés de apenas trocar mensagens usando um simples servlet? A simples troca de mensagens escala muito melhor.

[]s
Luca

Pois é Luca.
Estamos estudando outras formas de fazer essa comunicação.

Hoje esta aplicação que fica no servidor de aplicação também é usada por uma
view jsp! Inclusive a camada controller é compartilhada, o swing e o jsp usam a mesma. A diferença
é que no swing a camada controller é executa no cliente.

Então o swing executa a controller e os facades pra acessar o model são remotos, usando o spring-remoting.

Olá

fabiofalci:

Hoje esta aplicação que fica no servidor de aplicação também é usada por uma
view jsp! Inclusive a camada controller é compartilhada, o swing e o jsp usam a mesma. A diferença
é que no swing a camada controller é executa no cliente.

Então o swing executa a controller e os facades pra acessar o model são remotos, usando o spring-remoting.

Caso mais do que perfeito para usar tudo igual no servidor e no cliente swing enviar os POSTs via UrlConnection. O sistema como um todo ficaria mais simples e mais fácil de manter.

Uma observação: no cliente swing se pode fazer e se deve fazer validação mas no servidor as validações devem ser repetidas do mesmo jeito do que para os clientes JSP para evitar problemas com clientes fakes.

[]s
Luca

humm, verdade… eh legal essa solução, mas desculpa cara, aí vai de opinião pra opinião, mas particularmente eu não usaria.

Aliás, poderia ser criado um tópico só pra isso, pois acredito que eu não seja o único a defender o RMI.

Mas num ambito mais global, dexa eu ver se entendi. Você defende fazer um sistema distribuído SEM ejb, usando apenas servlets ?

Ou existiriam os EJBs, e os servlets seriam uma camada de serviço para acesso remoto ?

Cara, eu não vejo isso com bons olhos. Se fosse pra fazer assim, usaria webservices!

Olá

gibaholms:

humm, verdade… eh legal essa solução, mas desculpa cara, aí vai de opinião pra opinião, mas particularmente eu não usaria.

Aliás, poderia ser criado um tópico só pra isso, pois acredito que eu não seja o único a defender o RMI.

Mas num ambito mais global, dexa eu ver se entendi. Você defende fazer um sistema distribuído SEM ejb, usando apenas servlets ?

Ou existiriam os EJBs, e os servlets seriam uma camada de serviço para acesso remoto ?

Cara, eu não vejo isso com bons olhos. Se fosse pra fazer assim, usaria webservices!

1. RMI em 2008? Dificil defender mas você pode tentar Comece defendendo as vantagens do uso de RPC nos dias de hoje mas antes estude um pouco da hstória e veja quando este conceito surgiu e para que era usado. Pode acreditar mas RPC também é coisa do milênio passado ainda do tempo dos objetos COM/DCOM da falecida arquitetura DNA da Microsoft.

2. Ninguém tocou neste assunto aqui mas sistema distribuído não tem nada a ver com o que se usa no cliente. Sistemas realmente distribuídos são raríssimos. Nas raras ocasiões em que são necessários, o que se distribui é o que está no servidor. Podem ser feitos sem EJBs 3.0 mas podem também ser feitos com EJBs 3.0. (tem gente por aí que usou EJBs anteriores ao 3.0 mas na minha opinião, EJBs anteriores ao 3.0 foram a maior tolice já inventada desde que comecei com informática em 1968 )

3. Sim, apesar de neste caso não serem estritamente necessários, se poderia usar web services. As pilhas WS-* são desnecessários em 90% dos casos e hoje em dia há muitas outras alternativas. Já testou o jersey 0.6 que agora vem com a versão 1.7.2 do Grizzly?

[]s
Luca

Como disse o luca num post

“Sistema que o cliente acessa direto o bando de dados está obsoleto desde o milênio passado.”

O sisteminha que estou desenvolvendo está desta forma…

Todas as regras de negócio estão dentro do jar q estou distruibindo aos clientes…

oq eu faço ?

Luca:

Olá

Não usem RMI para comunicação entre o cliente e o servidor se pretendem que sua aplicação cresça muito

fabiofalci:

Lauro. Aqui desenvolvemos aplicações swing que acessam um servidor de aplicação através disso

http://static.springframework.org/spring/docs/2.5.x/reference/remoting.html

Funciona blz. Como o rafael falou, todo objeto que trafega entre o servidor e o cliente deverá estar num
jar dentro do classpath do cliente.

Porque optaram por fazer RPC ao invés de apenas trocar mensagens usando um simples servlet? A simples troca de mensagens escala muito melhor.

[]s
Luca

E precisa usar RMI pra usar o spring remoting? E o Spring HTTP invoker?

Não precisa.

Estou usando o Http Invoker
http://static.springframework.org/spring/docs/2.5.x/reference/remoting.html#remoting-httpinvoker

gibaholms:

humm, verdade… eh legal essa solução, mas desculpa cara, aí vai de opinião pra opinião, mas particularmente eu não usaria.

Aliás, poderia ser criado um tópico só pra isso, pois acredito que eu não seja o único a defender o RMI.

Mas num ambito mais global, dexa eu ver se entendi. Você defende fazer um sistema distribuído SEM ejb, usando apenas servlets ?

Ou existiriam os EJBs, e os servlets seriam uma camada de serviço para acesso remoto ?

Cara, eu não vejo isso com bons olhos. Se fosse pra fazer assim, usaria webservices!

Eu tenho que concordar com Luca na questão de não usar RMI.
Para começar RMI não usa a porta 80 e logo se torna um problema operacional. A solução tem que ser HTTP.
Fazer um sistema de invocação remota com HTTP é trivial (não e´trivial fazê-lo eficiente lol).
Seja com XML, CVS, Serialização de Objetos, tanto faz. A ideia é sempre: transporte o seu request para o servidor, faça ele processar e transporte a resposta de volta. No browser o request e a reposta são padrão.
Contudo, hoje em dia, com ajax , nem é mais assim tb. Existe sempre um “protocolo escondido” quando subimos un nivel e não usamos HTML directamente. Isto é uma Service Layer acoplada a uma sistema de serialização.
Funciona e é simples.

Webservices complicam demais. E a sua única utilidade é para fazer sistemas diferentes se comunicarem. Não foram desenhados para serem usados dentro do mesmo sistema. (Um cliente-servidor são o mesmo sistema.)

EJB é util localmente (na mesma jvm) ou para integração entre sistemas diferentes. contudo os web-services mataram o segundo uso e o primeiro é irrelevante já que vc pode construir os seus serviços como pojos.
Servlets é realmente a base tecnologia de uma comunicação simples entre cliente e servidor. Eu cheguei a usar JMS para mensagens de callback do servidor para o cliente, mas realmente sem usar EJB)

Por outro lado, fazer thin-clients em swing é uma como matar uma mosca com uma bomba nuclear. O browser é por definição um thin-client. Já que estamos em ambiente grafico de verdade vale fornecer interações gráficas ricas. Por exemplo, não abra reports no adobe reader como faria no borwser, abrar dentro so seu sistema com uma janela propria com opções próprias. O jasperReports tem um component para isto. É util , parece que o sistema é muito sofisticado e libera de depender do adobe reader. Claro, que existem os efeitos de luz, sombra, slide, fade, etc… mas nem precisa tanto para o sistema parece standalone.

Olá

Disse tudo e ainda lembrou do Ajax. Uma das poucas vantagens de usar clientes em Swing é poder acessar periféricos. Se o sistema não acessa periféricos ou não tem um outro motivo muito especial, não vejo porque usar Swing no cliente.

[]s
Luca (que já participou da vários projetos grandes com camada de apresentação em Swing)

Não precisa.

Estou usando o Http Invoker
http://static.springframework.org/spring/docs/2.5.x/reference/remoting.html#remoting-httpinvoker

Justamente o que eu queria dizer, RMI é UMA das opções do spring, não a única… :lol:

Luca,

Tenho uma aplicação instalada em várias filiais, que coleta uma lista de registros (em algum momento, chega até a 1000 registro de vez) e enviar para Matriz. Com a sua experiência, acredita que a solução URLConnection+Servlets dá conta do recado?

Olá

Zeovaldo:

Luca,

Tenho uma aplicação instalada em várias filiais, que coleta uma lista de registros (em algum momento, chega até a 1000 registro de vez) e enviar para Matriz. Com a sua experiência, acredita que a solução URLConnection+Servlets dá conta do recado?

Sim, dependerá mais da capacidade do servidor e do tempo de resposta previsto. É um problema para ser analisado particularmente mas de forma genérica, se é tal como entendi, acho que pode funcionar.

[]s
Luca

Valeu!

Estou fazendo alguns teste utilizando EJB 3.0 (Agora acho que dá para encarar agora). Swing+ejb(Camada de negocio)+GlassFish/JBoss

Irei também fazer os teste com uma Solução simples(a principio) Swing+URLConnection+Servlets+Tomcat6.0

Zeovaldo

Como disse o luca num post

“Sistema que o cliente acessa direto o bando de dados está obsoleto desde o milênio passado.”

O sisteminha que estou desenvolvendo está desta forma…

Todas as regras de negócio estão dentro do jar q estou distruibindo aos clientes…

oq eu faço ?

Alguém ?

Olá

thickbarney:

O sisteminha que estou desenvolvendo está desta forma…

Todas as regras de negócio estão dentro do jar q estou distruibindo aos clientes…

Se reler o tópico, verá que muitos como eu acham isto um absurdo.

Se fosse eu, refatoraria o sistema todo

[]s
Luca

Se hoje fosse desenvolver um sistema desktop, eu utilizaria até Flex/Laszlo/Silverligth ao invés de Swing.

Ao menos ficaria mais ‘bonitinho’…

Não me lembro do último cenário que passei que seria útil utilizá-lo.

Rafael Nunes,

Estou com um cenário, que acredito ser necessário uma aplicação desktop thin…

Coletor de dados…

thickbarney,

Uma das Soluções, é separar em camadas:
View (Aplicação Desktop thin)

Controller (Façade)

Model (Regra de Negócio)

Luca:

Olá

thickbarney:

O sisteminha que estou desenvolvendo está desta forma…

Todas as regras de negócio estão dentro do jar q estou distruibindo aos clientes…

Se reler o tópico, verá que muitos como eu acham isto um absurdo.

Se fosse eu, refatoraria o sistema todo

[]s
Luca

Eu li o topico todo e vi q mtos acham isso um absurdo. O problema não é refatorar todo o sistema, e sim oq fazer.

Oq eu faço ? Deixo a camada de negocios somente no servidor ? Uso RMI ? Servlet ? Hibernate ? JPA ? Era isso q eu gostaria de saber… pois nao tenho a minima ideia. Por isso fiz o programa usando JDBC puro e desse jeito…

A aplicação já está separada, porém todas as camadas estão sendo distribuidas juntas… oq eu faço pra separa-las ???

Olá

Se reler meus posts verá que minha recomendação é usar servlet e no servidor usar Hibernate (ou ActiveObjects). Apesa de saber que tem gente que usa RMI eu acho péssima solução.

Acessar a base com JDBC só em casos muito especiais por questões de performance e mesmo assim sendo feita no servidor.

[]s
Luca

thickbarney,

Veja a possibilidade de utilizar interface. Criando um pacote Service… Seguindo um pouco da filosofia adotada pelo Spring.

com.meupacote.service (Contendo por exemplo FinanceiroService
com.meupagote.business (Contendo por exemplo FinanceiroBO que implementa FinanceiroService)

Disponibilizando apenas a interface.

Att.

Zeovaldo

Eu gosto da idéia de swing + servlets inclusive estou estudando e implementando algo assim, lenta, vagarosa e dolorsamente :D. Acho que pode ser meio confuso o espaguetinho temperado com css+ajax+html+linguagem+browser diferentes… Mas posso estar errado. Não sou o mais experiente em desenvolvimento web.

Nesse post aqui no guj o cara mostrou um exemplo simples de como utlizar esse esquema.

sergiotaborda:

Por outro lado, fazer thin-clients em swing é uma como matar uma mosca com uma bomba nuclear.

E a sensação de se sentir um “Arnold ESuasNegas” fica aonde ? (Asta-la-vista-“beibe”).

Estou com duvidas parecidas… esta solucao:

Swing+Genesis+URLConnection+Servlet+Hibernate

seria uma boa escolha?? Não digo comparado se outras são melhores, mas se esta é ideal juntas.

jopss