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
[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
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á
[quote=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[/quote]
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á
[quote=gibaholms]cara, não consegui entender como seria isso… como que o cliente receberia as respostas do servlet ??
explique melhor essa solução[/quote]
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
[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]
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á
[quote=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.[/quote]
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