beleza galera?
faz tempo que não posto uma pergunta aqui então resolvi encher o saco de vcs um pouco
vou fazer uma interface desktop para um cadastro hoje que existe via web,
para isto vou utilizar o JWS para startar o formulário, e depois disto vou precisar me comunicar com a aplicação WEB de alguma maneira.
existe algum protocolo de remoting que eu possa utilizar para fazer isto, e se possivel, ainda utilizar as mesmas credenciais utilizadas na autenticação via WEB?
sei que é possivel fazer isto via webservices, mas eu estava pensando em alguma coisa que gerasse menos trafego de rede
se não for possivel, ai fico com o WS mesmo.
não vou utilizar IIOP sobre HTTP pois a aplicação roda no tomcat, sem um servidor completo J2EE, ai ficaria muito complicado ter de mudar o servidor só para ter mais este protocolo,
Hesian ou BUrlap até são opções, mas existe a possibilidade de ter muitos dados, o que pelo que o mister m falou, faz estes protocolos se perderem (eu vou realizar alguns testes com eles e coloco o resultado aqui)
estou pensando em fazer a GUI deste formulário com o thinlet mesmo
Só para eu me situar no contexto: Por que vc não pode usar o HttpClient (Jakarta) para fazer com que a sua aplicação se comunique com webserver da mesma maneira que o browser faz ???
Problema de sessão ??? O HttpClient tem cookies para criar a sessão!
Bom, se você quer reinventar a roda… Se vai usar Tomcat é bem mais fácil usar Web Services mesmo.
Você pode fazer um “web services” dos pobres, ou seja, definir uma página que retorna um resultado em um formato fixo - como um texto formatado como CSV, por exemplo, e recebe parâmetros como query string. Não é impossível fazer, mas acho que é uma coisa meio antiga.
Em termos de tráfego de rede: Se você fizer uma busca no site da Sun vai achar uma coisa chamada “Fast Web Services”, que é uma forma de minimizar o tráfego de rede ao usar Web Services.
Só que isso é um pouco complicado (em vez de usar XML usa ASN.1) e ainda não está bem definido.
Você já ouviu falar de ASN.1? Se ouviu falar, é porque você lida com criptografia - X.509 - ou com SNMP - monitoração; não é uma coisa tão complicada assim, mas é bem mais que um XML.
Você pode ler uma apresentação desse Fast Web Services no site do JavaOne, http://java.sun.com/javaone se não me engano.
Já tentou usar webservices e compressão gzip? O tomcat te permite usar isso apenas mudando 1 parâmetro do server.xml.
Eu consegui taxas boas ate, com o tamanho caindo para algo em torno de 10% e 25% do original.
rodolfo_dpk:
como eu tinha dito, vou trafegar possivelmente uma quantidade grande de dados, e segundo relatos do mister m, o hesian e o burlap se perdem com collections grandes e lazy loading, mas vou testar se o hesian resolve o meu problema
louds:
gostei da ideia, vou ver como funciona este esquema de WS com compressão gzip
thingol: valeu pela dica do Fast Web Services, vou dar uma pesquisada
saoj: valeu pela resposta, mas não curto reinventar a roda, e se eu fizer da maneira como você disse, vou me quebrar no caso de eu precisar implementar um cliente em outra linguagem no futuro, e agora mesmo vou ter mais dificuldades pois terei de implementar o parser, com qualquer protocolo de remoting pronto, eu só tenho que trabalhar de maneira puramente OO
o unico porem de WS é que eu teria que criar um proxy para os objetos que retoram coleções, e transformalas em arrays para compatibilidade com a especificação, por isto estou pendendo bastante para o lado do hesian caso este funciona bem no meu cenario
Tem razão. Pensando melhor agora, minha idéia foi péssima. Receber HTML como resposta e ter que parsear é coisa feia mesmo. Foi mal!
Eu estou meio por fora de webservices. Vc quer enviar objeto e receber objeto como resposta né?
Como não manjo das sugestões que foram dadas aqui, eu faria assim: (Veja se estou falando merda mais uma vez e me avise, ok? :roll: )
:arrow: Pegaria meu objeto
:arrow: serializaria ele para um array de bytes
:arrow: codificaria ele em hexadecimal ou base64 (texto!)
:arrow: ziparia se fosse o caso para ecomizar banda
:arrow: enviaria para o web server via HTTP mesmo
e o servidor faria a mesma coisa para me responder com um objeto.
Reinventei alguma coisa ??? O legal é que fazer isso aí em cima em Java seria bem fácil.
Agora que eu gastei tempo escrevendo tudo isso, me dei conta que vc quer independência de linguagem, e com a serialização do Java não rola!
Dá para trocar a serialização por XML com a classe java.beans.XMLEncoder bem ridicularmente, como tudo em Java. Vc passa o objeto e ela te cospe um XML do objeto.
Reinventei alguma coisa de novo ???
Bom, pelo menos acho que resolveria né, sem usar web services e essas outras coisas aí.
Uma opção bem interessante, usei e gostei, é usar uma API de mapeamento javabeans <-> xml, como castor, xml-beans, JAXB ou ate mesmo XStream. Elas suportam colections, heranças e tudo mais.
Minha experiencia foi com o castor, defini um schema pro meu XML e ele gerou os beans para transportá-los. A API é trivial e a performance não deixa a desejar.
A idéia do Louds (serialização para XML usando XStream) é realmente muito boa. Andei fazendo umas brincadeiras deste tipo dias atrás, enviando dados a partir de uma aplicação Swing para um Servlet (sobre HTTP, usando o Commons HTTP-Client) e obtendo respostas em XML (outro objeto serializado com ajuda do XStream). Ficou bem bonitinho.
Aliás, uma outra idéia beeeem legal (dica do CV, na verdade) seria, além de repassar estes XMLs para lá e para cá, usar um banco de dados xml para armazenar os dados. Daí você não precisaria criar oito-mil-quatrocentas-e-noventa-e-sete camadas para receber-desempacotar-validar-empacotar-gravar-ler-empacotar-desempacotar-renderizar .
Eu tenho em casa um exemplo que fiz, muito parecido com esse, e no meu caso, no lado web eu utilizei o webwork. Ai eu criava um arquivo xml (com o XStream) de resposta… O código não tá muito bom, pq fiz meio na pressão, mas se alguém quiser dar uma olhada… Fiz um cadastro bem simples (na verdade com um campo só, hehehe) em thinlet, enviei os dados com HttpURLConnection para uma action do webwork, e este salvava através do Hibernate…
Se alguém quiser eu posso mandar o fonte (me peçam por pm), falta muita coisa para transformar em algo utilizável, mas serve como início…
É mais simples, é mais bonito e costuma ser mais rápido.[/quote]
Alem de funcionar pra qualquer objeto, enquanto o XMLEncoder funciona so pra JavaBeans (que, no mundo magico de quem quer que seja o imbecil que escreveu essa API, implementam getters e setters bonitinhos em todos os casos, e tem sempre construtores vazios).
Javabeans é um modelo de componentes, não somente uma API! Tudo bem que todo o lançe de componentes foi pro ralo. Existem boas razões a favor de se usar getters,setter, construtores vazios e boas razões contra não usar.
Enfim, XMLEncoder não foi feito para serialização, mas para armazenamento duravel. A diferença entre as duas coisas é algo como “vomite esses objetos nesse stream!” e “crie a melhor representação para esses objetos nesse stream”.
O XmlEncoder usa um algoritmo para evitar escrever o valor padrão das propriedades e isso consume muuita cpu. Logo, o XStream, no seu modo mais lento de operação, é mais rápido que o XMLEncoder.
