Java Desktop com cliente magro

To com um pouco de dúvida em relação a aplicacoes cliente/servidor em swing.... ja trabalhei com jsp e servidor de aplicações...

mas comecei a desenvolver em swing ha algum tempo... sistemas pequenos...
mas agora fiquei curioso... como funciona um servidor de aplicações para clientes que usamm swing??
o que preciso saber para desenvolver tal solução? É possível passar objetos, como uma Session do Hibernate, so serv para o cliente?

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 wrote: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á

gibaholms wrote:no cliente você soh precisa dos "stubs", que são apenas as interfaces dos seus EJB... os EJBs propriamente ditos, apenas no server.

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

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

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.

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