Java Desktop com cliente magro

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á

[quote=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![/quote]

  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.”[/quote]

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 ?

[quote=Luca]Olá

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

[quote=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.[/quote]

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[/quote]

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

[quote=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![/quote]

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[/quote]

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á

[quote=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?[/quote]

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.”[/quote]

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 ?[/quote]

Alguém ?

Olá

[quote=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…[/quote]

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)

[quote=Luca]Olá

[quote=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…[/quote]

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

Se fosse eu, refatoraria o sistema todo

[]s
Luca[/quote]

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.

[quote=sergiotaborda]
Por outro lado, fazer thin-clients em swing é uma como matar uma mosca com uma bomba nuclear. [/quote]

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