[Rio-pm] SOAP::Lite - críticas e alternativas

[Marco A P D'Andrade]

Um tanto atrasada minha replica... mas :D

Concordo, que XML::RPC resolve grande parte, e por não conhecer os
outros 10%, fico em opinião mesmo ...

Uma integração tem de ser bem planejada, e hoje eu parto do principio
de que integrações externas devem seguir os melhores padrões, em
termos de prática de mercado. A exemplo, integrar Perl com Java, .Net,
etc... tende a ser SOAP::Lite.

Mas integrações internas, podem ser feitas de inumeras maneiras, uma
que ainda não pude por em prática, mas me chama a atenção, é a volta
às origens... Storable... Transferencia binaria mesmo ! Isto, é claro,
Perl x Perl !



Mas, voltando ao que me fez ressucitar esta thread...


Identifiquei o BUG que julgava ser entre S:L com KeepAlive... isto não
éra somente nesta situação, mas sempre que uma instancia S:L era
reutilizada em grande quantidade...


Fiz uma comparação entre a versão que tenho em produção, com a ultima
Stable no CPAN:

http://search.cpan.org/diff?from=SOAP-Lite-0.66&to=SOAP-Lite-0.69#lib/SOAP/Transport/HTTP.pm

Mais especificamente neste trecho:
-       $self->http_request->content_type($tmpType.'; charset=' .
lc($encoding));
+#      $self->http_request->content_type($tmpType.'; charset=' .
lc($encoding));
+        my $addition = '; charset=' . lc($encoding);
+        $self->http_request->content_type($tmpType.$addition) if
($tmpType !~ /$addition/);


O que ocorre é que em multiplas requisicoes, é acrescida a string
"charset=utf-8" a cada nova requisição, chegando a utilizar mais banda
com lixo que com seus dados propriamente (já considerando o overhead
do envelope!).

Para não ficar somente na teoria barata, estou anexando o codigo que
utilizei para depurar o problema.

Bastante "verboso", mas dá para ver em tela os acrescimos.

Eu utilizo um Ubuntu-Server, com SOAP::Lite instalado via apt-get (é
rápido tah !), e a versão do S:L é 0.66, contra 0.69. -- Nao
verifiquei em qual houve correcao.


A diferenca, em 100 requisicoes, foram 1518 bytes, na ultima,
lembrando que cresceu 14 bytes a cada requisicao.

Ok, ok... parece pouco neh! Mas no meu caso, tem momentos que faço
alterações em batch de 10.000 requisicoes, aplicadas em 3 equipamentos
(2 rio e 1 spo), e isto no mínimo consome meu tempo de cpu ;)

Para quem utiliza S:L, segue um arquivo anexo para "brincar".


Sds,
Marco Antonio



Em 12/10/07, Solli Honorio<shonorio em gmail.com> escreveu:
> Eu, particularmente, acho o S::L muito complexo e o suporte a WSDL muito
> fraco, mesmo com o SOAP::WSDL que o MDA comentou abaixo.
>
> Estou dando uma olhada no XML-RPC
> (http://www.ibm.com/developerworks/library/ws-xpc1/) que me
> parece mais simples e resolve 90 % dos problemas de comunicação entre hosts.
>
> Solli M. Honório
>
>
>
> On 10/12/07, breno <breno em rio.pm.org> wrote:
> > Opa, acabei enviando direto, mas acho que vou ser o primeiro a tentar
> > comentar/responder minhas próprias perguntas ;-)
> >
> > On 10/12/07, breno <breno em rio.pm.org> wrote:
> > >
> > > 1) Alguém pode compartilhar casos de sucesso de soluções com
> > > SOAP::Lite? Ou será que só conhecemos o lado ruim dele por aqui?
> > >
> >
> > Sei que o POE possui seus "POE::Component::Server::SOAP" e derivados,
> > mas eles aparentemente estão em cima S::L o que significa que soluções
> > usando o POE + SOAP certamente existem por aí.
> >
> >
> > > 2) Essencialmente, quais as críticas específicas ao
> > > funcionamento/comportamento/estabilidade do SOAP::Lite?
> Em outras
> > > palavras, o que ele promete mas não cumpre (ou ao menos não da melhor
> > > maneira)?
> > >
> >
> > Afinal, os maiores problemas estão na implementação do SOAP::Lite em
> > si ou na implementação de determinados (todos?) módulos do namespace
> > SOAP que o S::L usa? Ou nos dois??? Ou eu me enganei e não há problema
> > algum?
> >
> > Uma crítica que eu tenho particularmente está na ausência de suporte à
> > versão 1.2 da especificação do SOAP.
> >
> > > 3) Alguém tem/usa alternativas (i.e., outras implementações de
> > > cliente/servidor com SOAP)?
> > >
> >
> > Existe um projeto promissor, o XML::Compile, que foi até apresentado
> > no YAPC::Europe 2007 (slides em:
> >
> http://perl.overmeer.net/xml-compile/2007yapceu/index.html
> ), mas os
> > submódulos de SOAP ainda estão "em construção"
> >
> > Mas em último caso (ou até em primeiro caso, já que se trata de algo
> > rápido e eficiente), como mencionou alguém na Lisbon-PM (acho),
> > podemos sempre contar com XML::LibXML::XPathContext + LWP pois,
> > afinal, estamos falando de XML sobre HTTP, não? Talvez não seja o mais
> > portátil entre diferentes sistemas por não seguir à risca a
> > especificação, mas funciona.
> >
> >
> > []s
> >
> > -b
> > _______________________________________________
> > Rio-pm mailing list
> > Rio-pm em pm.org
> > http://mail.pm.org/mailman/listinfo/rio-pm
> >
>
>
>
> --
> "o animal satisfeito dorme". - Guimarães Rosa
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>
-------------- Próxima Parte ----------
Um anexo não texto foi limpo...
Nome  : _debug_SL.tar.gz
Tipo  : application/x-gzip
Tam   : 803 bytes
Descr.: não disponível
Url   : http://mail.pm.org/pipermail/rio-pm/attachments/20071105/eb555c70/attachment.gz