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

Marco A P D'Andrade mdacwb em gmail.com
Sexta Outubro 12 00:15:12 PDT 2007


Ih! Também perdeu o sono ;)

Em 12/10/07, breno<breno em rio.pm.org> escreveu:
> 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?
> >

Bem, me tornando repetitivo, e por favor, aos demais, citem seus cases !

O aprovisionamento do Click21 para mim é um exemplo que se mantem já a
4 anos como  um daemon puramente Perl (tá XML::Parser é em C, mas
integrado como módulo XS ;) ).

Recentemente fiz a migração de sua versão 3.0 e a única coisa que não
mudou foi a integração com SOAP::Lite.

Por sinal agora utilizando a ultima versão, com requisições com
Keep-Alive ativo entre o Configurador e os agentes destino (até são 5
servidores alvo por requisição recebida).

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

O S:L é muito extenso, e reimplementar parece um grande esforço
desnecessário. Muito melhor é participar da remodelagem do projeto,
que por sinal está ocorrendo, aparentemente com energias renovadas.


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


Em minha percepção, não tão atualizada quanto a do Tito, que
questionou compatibilidade com SOA (Service-oriented architecture -
que eu ainda conheço muito pouco do conceito), um grande problema é a
dificuldade no suporte a WSDL.

Mas valem ressalvas com relação à estas "sensações" ...


Para o lado Client existem algumas alternativas, documentadas, e pouco
conhedidas:
1. "submaker.pl" - cria um package prontinho para uso a partir do WSDL
do server;
2. módulo SOAP::WSDL - para ser utilizado quando o numero de
requisições provaveis é
*. Para integração estável, sugiro sempre utlizar chamadas definidas e
deixar a cargo do S:L fazer o baixo nivel. Evite o request+parse
desnecessários!

Mais informações:
Vide SOAP::WSDL (Why should I use this?):
   * http://search.cpan.org/~mkutter/SOAP-WSDL-1.26/lib/SOAP/WSDL.pm#Why_should_I_use_this_?


Para o Server, a disponibilização do WSDL das requisições possíveis é
critica quando vc possui um grande numero aplicações clientes, ou um
frequente desenvolvimento de novas aplicações que de alguma forma ou
em algum momento vão necessitar de integração, como em um ambientes
SOA, que é um dos focos de trabalho do Tito.


Como disponibilizar o WSDL isto não é trivial eu mesmo nunca gerei os
meus, até porque as interfaces são resumidas a poucas requisições e
tenho no maximo 3 sistemas integrando com cada configurador (tenho 2),
e uma vez que isto esteja concluido, não é mais necessário fazer este
tratamento, exceto em casos de mudanças, que sempre são trabalhosas...

Uma teoria, que desenvolvi recentemente, que ainda não tive
tempo/oportunidade de discutir isto com o Tito é de que a
criação/documentação e uso de algumas "boas praticas" resolvessem o
problema, se é que ainda não existem (TODO: revisar documentação).

A teoria consiste em criar casos de teste ou stubs para as
requisições, e a partir disto gerar "automagicamente" o WSDL...

Por sinal, esta teoria foi desenvolvida durante alguns momentos de
lucidez da ressaca do ultimo social extra/surpresa, então ainda é
muito superficial. Quem sabe conseguimos avançar no tema até/no
próximo ES!


Quando se trata de integrações S:L eu não canso de repetir... o livro
"Programming Web Services with Perl" vai economizar *muito* tempo,
vide minhas afirmações em Livros & Resenhas
(http://rio.pm.org/livros.pl). E lembre-se... a documentação é muito
extensa, e fatos importantes custumam passar despercebidos !


>
> > 3) Alguém tem/usa alternativas (i.e., outras implementações de
> > cliente/servidor com SOAP)?
> >

Como Client identifiquei uma, mas obviamente que eu não testei ;)... no CPAN.

Mas sinceramente não acho que vale a pena sair do S:L para usar outro
módulo SOAP já que o principal ganho de uma implementação WebServices,
é vc utilizar padrões, e utilizar de maneira simples. Se vc tiver que
se aprofundar, e dependendo da complexidade de seus parametros vc vai
(!), não valerá a pena utilizar tal tecnologia.

Mas não podemos esquecer, é claro que... "existe mais de uma maneira
de se fazer as coisas", e cada um excolhe a sua ;)

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


Ta.... estou a 2 horas escrevendo, revisando, alterando esta
mensagem... acho que já passei a ideia central e minhas opiniões...
desculpem os eventuais erros... o sono tá batendo ;)


Sds,
Marco Antonio


Mais detalhes sobre a lista de discussão Rio-pm