Protocolo de remoting

Fala Urubatan,

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!

Problema de SSL ??? O HttpClient tem https!

Se eu viajei pode falar…

Sergio Oliveira
http://www.smartjava.com.br

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.

Pessoal,

Ando sumido, ranzinza e anti-social total mas esta eu não resisto :

http://www.caucho.com/hessian/index.xtp

Abraços a todos !

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

valeu pelas respostas galera …

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í.

Sergio Oliveira
http://www.smartjava.com.br

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.

vou testar estas opções (provavelmente só la por terça ou quarta feira)
e posto aqui os resultados

valeu galera …

Usar serialização não te prende ao java! Apenas torna necessario entender um formato binario razoavelmente cabeludo.

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.

[folgado mode-on]
Cadê?Posta aí para gente brincar…
[/folgado mode-off]

Nota:aproveito e comparo com o q fiz aqui,pois não tah funcionando 100%… 8)

Postar o quê? O código? Ahh, este aí eu não po$$o, $abe?
Mas encham meu saco (email) para que eu escreva algum artigo para o GUJ a respeito.

p.s.: não levem a idéia de me floodarem por email a sério, senão… :twisted:

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 .

Qual a diferença do XStream para o java.beans.XMLEncoder ?

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…

Fallow

Sem feira-livre. Ted, posta o código aí, se não houver restrições

É mais simples, é mais bonito e costuma ser mais rápido.

É mais simples, é mais bonito e costuma ser mais rápido.

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.